The Aspeed pinctrl bindings are missing an additionalProperties/
unevaluatedProperties schemas on the child pin mux nodes which means any
undefined properties are allowed. In addition, using
'additionalProperties' for child nodes with any name works better than a
pattern matching everything with an if/then schema to select nodes only.
With 'additionalProperties' added, 'pins' and 'bias-disable'
properties need to be added as they were not defined. A $ref to
pinmux-node.yaml which defines the common property types was also
missing.
Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230819010907.916061-1-robh@kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Qualcomm pinctrl changes for v6.6
1. Add support for the SM6115 and SM8350 LPASS (Low Power Audio
SubSystem) TLMM pin controllers.
2. Add bindings for the Qualcomm PMC8180 and PMC8180C PMICs GPIO pin
controllers.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
In atmel_conf_pin_config_dbg_show(), checking atmel_pioctrl->pins[pin_id]
against being NULL doesn't make any sense as it gets derefenced first and
the driver's probe() method immediately returns -ENOMEM when devm_kzalloc()
returns NULL for any atmel_pioctrl->pins[] element anyway, thus failing to
register the device...
Found by Linux Verification Center (linuxtesting.org) with the Svace static
analysis tool.
Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
Link: https://lore.kernel.org/r/4ab2f59f-45c1-76a2-94da-3331e8ec4e35@omp.ru
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Update binding for yaml and remove the old related txt bindings. Note that
we are also adding the undocumented pinctrl-single,slew-rate property. And
we only use the first example from the old binding.
As we are mostly using a generic compatible across various SoCs, let's not
start adding matches for random pin group node naming. Let's standardize on
pin group node name ending in -pins with an optional instance number
suffix.
As a pin group may have additional pins added to it later on, let's always
use -pins rather than -pin for the gropu name.
Most of the dts files have been updated already for the pin group node
names with a few changes still pending.
Cc: Nishanth Menon <nm@ti.com>
Cc: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20230721082654.27036-1-tony@atomide.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Add support to handle 'output-enable' and 'bias-high-impedance'
configurations.
Using these pinctrl properties observed hang issues with older PMUFW(Xilinx
ZynqMP Platform Management Firmware), hence reverted the patch.
Commit 9989bc33c4 ("Revert "pinctrl: pinctrl-zynqmp: Add support
for output-enable and bias-high-impedance"").
Support for configuring these properties added in PMUFW Configuration Set
version 2.0. When there is a request for these configurations from pinctrl
driver for ZynqMP platform, xilinx firmware driver checks for this version
before configuring these properties to avoid the hang issue and proceeds
further only when firmware version is >=2 otherwise it returns error.
Signed-off-by: Sai Krishna Potthuri <sai.krishna.potthuri@amd.com>
Reviewed-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/20230731095026.3766675-5-sai.krishna.potthuri@amd.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Add 'output-enable' configuration parameter to the properties list.
Using these pinctrl properties observed hang issues with older Xilinx
ZynqMP Platform Management Firmware, hence reverted the patch previously.
Commit ff8356060e ("Revert "dt-bindings: pinctrl-zynqmp: Add
output-enable configuration"").
Support for configuring these properties added in Xilinx ZynqMP Platform
Management firmware(PMUFW) Configuration Set version 2.0. Linux firmware
driver checks if the configuration is supported by the PMUFW when it gets
request for TRISTATE configuration from pinctrl driver. If it supports,
then calls will be made otherwise it returns error.
Signed-off-by: Sai Krishna Potthuri <sai.krishna.potthuri@amd.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20230731095026.3766675-4-sai.krishna.potthuri@amd.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
pinctrl_generic_add_function() doesn't check result of radix_tree_insert()
despite they both may return a negative error code. Linus Walleij said he
has copied the radix tree code from kernel/irq/ where the functions calling
radix_tree_insert() are *void* themselves; I think it makes more sense to
propagate the errors from radix_tree_insert() upstream if we can do that...
Found by Linux Verification Center (linuxtesting.org) with the Svace static
analysis tool.
Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
Link: https://lore.kernel.org/r/20230719202253.13469-4-s.shtylyov@omp.ru
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
pinctrl_register_one_pin() doesn't check the result of radix_tree_insert()
despite they both may return a negative error code. Linus Walleij said he
has copied the radix tree code from kernel/irq/ where the functions calling
radix_tree_insert() are *void* themselves; I think it makes more sense to
propagate the errors from radix_tree_insert() upstream if we can do that...
Found by Linux Verification Center (linuxtesting.org) with the Svace static
analysis tool.
Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
Link: https://lore.kernel.org/r/20230719202253.13469-3-s.shtylyov@omp.ru
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
pinctrl_generic_add_group() doesn't check the result of radix_tree_insert()
despite they both may return a negative error code. Linus Walleij said he
has copied the radix tree code from kernel/irq/ where the functions calling
radix_tree_insert() are *void* themselves; I think it makes more sense to
propagate the errors from radix_tree_insert() upstream if we can do that...
Found by Linux Verification Center (linuxtesting.org) with the Svace static
analysis tool.
Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
Link: https://lore.kernel.org/r/20230719202253.13469-2-s.shtylyov@omp.ru
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. As a result, there's a pretty much random mix of those include
files used throughout the tree. In order to detangle these headers and
replace the implicit includes with struct declarations, users need to
explicitly include the correct includes.
Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
Acked-by: Emil Renner Berthing <emil.renner.berthing@canonical.com>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20230714174901.4062397-1-robh@kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The sunxi pinctrl has a fixed size array it uses to store regulators used
in the driver. There is currently nothing that ensures that the number of
elements in the array is large enough to map the regulators defined by the
individual SoCs. While this is currently the case having an explicit check
in there will make life easier for anyone debugging memory issues that
manifest in the driver so let's add one.
Signed-off-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Link: https://lore.kernel.org/r/20230712-pinctrl-sunxi-boudns-v1-1-85f37de79b9f@kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This patch adds support for an optional "reset" GPIO pin in the cy8c95x0
pinctrl driver. On probe, the reset pin is pulled low to bring chip out
of reset. The reset pin has an internal pull-down and can be left
floating if not required.
The datasheet doesn't mention any timing related to the reset pin.
Based on empirical tests, it was found that the chip requires a
delay of 250 milliseconds before accepting I2C transfers after driving
the reset pin low. Therefore, a delay of 250ms is added before
proceeding with I2C transfers.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Signed-off-by: Naresh Solanki <Naresh.Solanki@9elements.com>
Link: https://lore.kernel.org/r/20230714081902.2621771-2-Naresh.Solanki@9elements.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
