30 Sep, 2020
3 commits
-
There's a common pattern of dynamically allocating an array of char
pointers and then also dynamically allocating each string in this
array. Provide a helper for freeing such a string array with one call.Signed-off-by: Bartosz Golaszewski
Reviewed-by: Andy Shevchenko -
Some Layerscape/QoriQ SoCs have input buffers which needs to be enabled
first. This was done in two different ways in the driver. Unify it.This was tested on a LS1028A SoC.
Signed-off-by: Michael Walle
Signed-off-by: Bartosz Golaszewski -
If the module init function fails after creating the debugs directory,
it's never removed. Add proper cleanup calls to avoid this resource
leak.Fixes: 9202ba2397d1 ("gpio: mockup: implement event injecting over debugfs")
Cc:
Signed-off-by: Bartosz Golaszewski
Reviewed-by: Andy Shevchenko
29 Sep, 2020
7 commits
-
Change config to tristate, add module device table, module author,
description and license to support module build for i.MX GPIO driver.As this is a SoC GPIO module, it provides common functions for most
of the peripheral devices, such as GPIO pins control, secondary
interrupt controller for GPIO pins IRQ etc., without GPIO driver, most
of the peripheral devices will NOT work properly, so GPIO module is
similar with clock, pinctrl driver that should be loaded ONCE and
never unloaded.Since MXC GPIO driver needs to have init function to register syscore
ops once, here still use subsys_initcall(), NOT module_platform_driver().Signed-off-by: Anson Huang
Link: https://lore.kernel.org/r/1600320829-1453-1-git-send-email-Anson.Huang@nxp.com
Signed-off-by: Linus Walleij -
When PINCTRL_BCM2835 is enabled and GPIOLIB is disabled, it results in the
following Kbuild warning:WARNING: unmet direct dependencies detected for GPIOLIB_IRQCHIP
Depends on [n]: GPIOLIB [=n]
Selected by [y]:
- PINCTRL_BCM2835 [=y] && PINCTRL [=y] && OF [=y] && (ARCH_BCM2835 [=n] || ARCH_BRCMSTB [=n] || COMPILE_TEST [=y])The reason is that PINCTRL_BCM2835 selects GPIOLIB_IRQCHIP without
depending on or selecting GPIOLIB while GPIOLIB_IRQCHIP is subordinate to
GPIOLIB.Honor the kconfig menu hierarchy to remove kconfig dependency warnings.
Fixes: 85ae9e512f43 ("pinctrl: bcm2835: switch to GPIOLIB_IRQCHIP")
Signed-off-by: Necip Fazil Yildiran
Link: https://lore.kernel.org/r/20200914144025.371370-1-fazilyildiran@gmail.com
Signed-off-by: Linus Walleij -
Convert the Maxim MAX732x family of GPIO expanders bindings to device
tree schema by merging it with existing PCA95xx schema. These are quite
similar so merging reduces duplication.Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Rob Herring
Link: https://lore.kernel.org/r/20200916155715.21009-3-krzk@kernel.org
Signed-off-by: Linus Walleij -
Convert the NXP PCA953x family of GPIO expanders bindings to device tree
schema.Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Rob Herring
Link: https://lore.kernel.org/r/20200916155715.21009-2-krzk@kernel.org
Signed-off-by: Linus Walleij -
Describe common "gpio-line-names" property to fix dtbs_check warnings
like:arch/arm/boot/dts/imx53-m53menlo.dt.yaml: gpio@53f84000:
'gpio-line-names' does not match any of the regexes: '^(hog-[0-9]+|.+-hog(-[0-9]+)?)$', 'pinctrl-[0-9]+'Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Rob Herring
Link: https://lore.kernel.org/r/20200920195848.27075-3-krzk@kernel.org
Signed-off-by: Linus Walleij -
Several DTSes with ARMv6 and ARMv7 i.MX SoCs introduce their own
compatibles so add them to fix dtbs_check warnings like:arch/arm/boot/dts/imx35-pdk.dt.yaml: gpio@53fa4000:
compatible: ['fsl,imx35-gpio', 'fsl,imx31-gpio'] is not valid under any of the given schemasarch/arm/boot/dts/imx51-babbage.dt.yaml: gpio@73f90000:
compatible: ['fsl,imx51-gpio', 'fsl,imx35-gpio'] is not valid under any of the given schemasSigned-off-by: Krzysztof Kozlowski
Reviewed-by: Rob Herring
Link: https://lore.kernel.org/r/20200920195848.27075-2-krzk@kernel.org
Signed-off-by: Linus Walleij -
Describe common "gpio-line-names" property to fix dtbs_check warnings
like:arch/arm64/boot/dts/hisilicon/hi3670-hikey970.dt.yaml: gpio@e8a0b000:
'gpio-line-names' does not match any of the regexes: 'pinctrl-[0-9]+'Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Rob Herring
Link: https://lore.kernel.org/r/20200920195848.27075-1-krzk@kernel.org
Signed-off-by: Linus Walleij
22 Sep, 2020
1 commit
-
…ernel/git/brgl/linux into devel
gpio updates for v5.10 - part 1
- automatically drive GPHY leds in gpio-stp-xway
- refactor ->{get, set}_multiple() in gpio-aggregator
- add support for a new model in rcar-gpio DT bindings
- simplify several GPIO drivers with dev_err_probe()
- disable Direct KBD interrupts in gpio-tc35894
- use DEFINE_SEQ_ATTRIBUTE() in GPIO chardev to shrink code
- switch to using a simpler IDA API in gpiolib
- make devprop_gpiochip_set_names() more generic by using device properties
instead of using fwnode helpers
17 Sep, 2020
1 commit
-
It's possible for a GPIO chip to not have a parent device (whose
properties we inspect for 'gpio-line-names'). In this case we should
simply return from devprop_gpiochip_set_names(). Add an appropriate
check for this use-case.Fixes: 7cba1a4d5e16 ("gpiolib: generalize devprop_gpiochip_set_names() for device properties")
Reported-by: Anders Roxell
Signed-off-by: Bartosz Golaszewski
Reviewed-by: Andy Shevchenko
Tested-by: Anders Roxell
Reviewed-by: Mika Westerberg
14 Sep, 2020
4 commits
-
Now that devprop_gpiochip_set_names() is only used in a single place
inside drivers/gpio/gpiolib.c, there's no need anymore for it to be
exported or to even live in its own source file. Pull this function into
the core source file for gpiolib.Signed-off-by: Bartosz Golaszewski
Reviewed-by: Mika Westerberg
Reviewed-by: Andy Shevchenko -
devprop_gpiochip_set_names() is overly complicated with taking the
fwnode argument (which requires using dev_fwnode() & of_fwnode_handle()
in ACPI and OF GPIO code respectively). Let's just switch to using the
generic device properties.This allows us to pull the code setting line names directly into
gpiochip_add_data_with_key() instead of handling it separately for
ACPI and OF.Signed-off-by: Bartosz Golaszewski
Reviewed-by: Andy Shevchenko
Reviewed-by: Mika Westerberg -
Instead of doing the following:
count = device_property_read_string_array(dev, propname, NULL, 0);
Let's provide inline helpers with hardcoded arguments for counting
strings in property arrays.Suggested-by: Andy Shevchenko
Signed-off-by: Bartosz Golaszewski
Reviewed-by: Mika Westerberg
Reviewed-by: Andy Shevchenko -
We don't need to specify any ranges when allocating IDs so we can switch
to ida_alloc() and ida_free() instead of the ida_simple_ counterparts.ida_simple_get(ida, 0, 0, gfp) is equivalent to
ida_alloc_range(ida, 0, UINT_MAX, gfp) which is equivalent to
ida_alloc(ida, gfp). Note: IDR will never actually allocate an ID
larger than INT_MAX.Signed-off-by: Bartosz Golaszewski
Reviewed-by: Andy Shevchenko
12 Sep, 2020
1 commit
-
NXP i.MX GPIO bindings for v5.10
Few NXP i.MX GPIO controller bindings cleanup.
11 Sep, 2020
1 commit
-
Use DEFINE_SEQ_ATTRIBUTE macro to simplify the code.
Signed-off-by: Andy Shevchenko
Signed-off-by: Bartosz Golaszewski
09 Sep, 2020
1 commit
-
On tc35894, have to disable direct keypad interrupts to make
it as general purpose interrupts functionality work.
if not, after chip reset, IRQST(0x91) will always 0x20,
IRQN always low level, can't be clear.Configure DIRECTx to enable general purpose gpio mode,
else read GPIOMISx register always zero in irq routine.verified on tc35894, need more test on other tc3589x.
Signed-off-by: dillon min
Acked-by: Lee Jones
Signed-off-by: Bartosz Golaszewski
04 Sep, 2020
4 commits
-
Parse also optional power-domains property to fix dtbs_check warnings
like:arch/arm64/boot/dts/freescale/imx8qxp-ai_ml.dt.yaml: gpio@5d080000: 'power-domains' does not match any of the regexes: 'pinctrl-[0-9]+'
From schema: Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yamlSigned-off-by: Krzysztof Kozlowski
Reviewed-by: Rob Herring
Link: https://lore.kernel.org/r/20200825193536.7332-5-krzk@kernel.org -
Allow parsing GPIO controller children nodes with GPIO hogs to fix
warning:arch/arm64/boot/dts/freescale/imx8mq-evk.dt.yaml: gpio@30240000: 'wl-reg-on' does not match any of the regexes: 'pinctrl-[0-9]+'
From schema: Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yamlSigned-off-by: Krzysztof Kozlowski
Reviewed-by: Rob Herring
Link: https://lore.kernel.org/r/20200825193536.7332-4-krzk@kernel.org -
The GPIO controller node can have gpio-ranges property. This fixes
dtbs_check warnings like:arch/arm64/boot/dts/freescale/imx8mm-evk.dt.yaml: gpio@30200000: 'gpio-ranges' does not match any of the regexes: 'pinctrl-[0-9]+'
From schema: Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yamlSigned-off-by: Krzysztof Kozlowski
Reviewed-by: Rob Herring
Link: https://lore.kernel.org/r/20200825193536.7332-3-krzk@kernel.org -
DTSes with new i.MX 8 SoCs introduce their own compatibles so add them
to fix dtbs_check warnings like:arch/arm64/boot/dts/freescale/imx8mm-evk.dt.yaml: gpio@30200000:
compatible:0: 'fsl,imx8mm-gpio' is not one of ['fsl,imx1-gpio', 'fsl,imx21-gpio', 'fsl,imx31-gpio', 'fsl,imx35-gpio', 'fsl,imx7d-gpio']
From schema: Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yamlarch/arm64/boot/dts/freescale/imx8mm-evk.dt.yaml: gpio@30200000:
compatible: ['fsl,imx8mm-gpio', 'fsl,imx35-gpio'] is too longarch/arm64/boot/dts/freescale/imx8mm-evk.dt.yaml: gpio@30200000:
compatible: Additional items are not allowed ('fsl,imx35-gpio' was unexpected)Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Rob Herring
Link: https://lore.kernel.org/r/20200825193536.7332-2-krzk@kernel.org
29 Aug, 2020
7 commits
-
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Michal Simek
Reviewed-by: Andy Shevchenko
Signed-off-by: Bartosz Golaszewski -
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Andy Shevchenko
Signed-off-by: Bartosz Golaszewski -
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Andy Shevchenko
Signed-off-by: Bartosz Golaszewski -
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.Signed-off-by: Krzysztof Kozlowski
Acked-by: Grygorii Strashko
Reviewed-by: Andy Shevchenko
Signed-off-by: Bartosz Golaszewski -
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Andy Shevchenko
Signed-off-by: Bartosz Golaszewski -
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Andy Shevchenko
Acked-by: Florian Fainelli
Signed-off-by: Bartosz Golaszewski -
Document Renesas RZ/G2H (R8A774E1) GPIO blocks compatibility within the
relevant dt-bindings. R8A774E1 GPIO module is identical to R-Car Gen3
family.No driver change is needed due to the fallback compatible value
"renesas,rcar-gen3-gpio".Signed-off-by: Lad Prabhakar
Reviewed-by: Geert Uytterhoeven
Acked-by: Rob Herring
Signed-off-by: Bartosz Golaszewski
27 Aug, 2020
10 commits
-
Since the resource managed version of gpiochip_add_data() will handle the
GPIO-chip data automated cleanup we can freely remove the DW APB GPIO
driver code responsible for that. After doing so the DW APB GPIO driver
removal callback can be also fully discarded since there is nothing left
to be done for it. All the cleanups are now performed by means of the
device managed framework.Signed-off-by: Serge Semin
Reviewed-by: Andy Shevchenko
Link: https://lore.kernel.org/r/20200730152808.2955-11-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Linus Walleij -
The kernel clock framework provides the resource managed version of
the clk_bulk_get() method. The only thing which needs to be also automated
is the clocks disable/unprepare procedure executed on the device removal.
It can be implemented by means of the custom action definition. After that
the clocks acquisition and release will be purely managed by the device
resources interface.Signed-off-by: Serge Semin
Reviewed-by: Andy Shevchenko
Link: https://lore.kernel.org/r/20200730152808.2955-10-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Linus Walleij -
The reset control interface provides the resource managed version of
the reset_control_get() method. The only thing which needs to be also
automated is the reset lane assertion on the device removal. It can be
implemented by means of the custom action definition. After that the reset
control will be purely managed by the device resources interface.Signed-off-by: Serge Semin
Reviewed-by: Andy Shevchenko
Link: https://lore.kernel.org/r/20200730152808.2955-9-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Linus Walleij -
Since GPIOlib-based IRQ-chip interface is now utilized there is no need
in calling the methods acpi_gpiochip_{request,free}_interrupts() here.
They will be called from gpiochip_add_irqchip()/gpiochip_irqchip_remove()
anyway.Signed-off-by: Serge Semin
Reviewed-by: Andy Shevchenko
Link: https://lore.kernel.org/r/20200730152808.2955-8-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Linus Walleij -
Since GPIOlib-based IRQ-chip interface is now utilized there is no need in
setting up a custom GPIO-to-IRQ mapping method. GPIO-lib defines the
standard mapping method - gpiochip_to_irq(), which will be used anyway no
matter whether the custom to_irq callback is specified or not.Signed-off-by: Serge Semin
Reviewed-by: Andy Shevchenko
Link: https://lore.kernel.org/r/20200730152808.2955-7-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Linus Walleij -
GPIO-lib provides a ready-to-use interface to initialize an IRQ-chip on
top of a GPIO chip. It's better from maintainability and readability
point of view to use one instead of supporting a hand-written Generic
IRQ-chip-based implementation. Moreover the new implementation won't
cause much functional overhead but will provide a cleaner driver code.
All of that makes the DW APB GPIO driver conversion pretty much justified
especially seeing a tendency of the other GPIO drivers getting converted
too.Here is what we do in the framework of this commit to convert the driver
to using the GPIO-lib-based IRQ-chip interface:1) IRQ ack, mask and unmask callbacks are locally defined instead of
using the Generic IRQ-chip ones.2) An irq_chip structure instance is embedded into the dwapb_gpio
private data. Note we can't have a static instance of that structure since
GPIO-lib will add some hooks into it by calling gpiochip_set_irq_hooks().
A warning about that would have been printed by the GPIO-lib code if we
used a single irq_chip structure instance for multiple DW APB GPIO
controllers.3) Initialize the gpio_irq_chip structure embedded into the gpio_chip
descriptor. By default there is no IRQ enabled so any event raised will be
handled by the handle_bad_irq() IRQ flow handler. If DW APB GPIO IP-core
is synthesized to have non-shared reference IRQ-lines, then as before the
hierarchical and cascaded cases are distinguished by checking how many
parental IRQs are defined. (Note irq_set_chained_handler_and_data() won't
initialize IRQs, which descriptors couldn't be found.) If DW APB GPIO IP
is used on a platform with shared IRQ line, then we simply won't let the
GPIO-lib to initialize the parental IRQs, but will handle them locally in
the driver.4) Discard linear IRQ-domain and Generic IRQ-chip initialization, since
GPIO-lib IRQ-chip interface will create a new domain and accept a standard
IRQ-chip structure pointer based on the setting we provided in the
gpio_irq_chip structure.5) Manually select a proper IRQ flow handler directly in the
irq_set_type() callback by calling irq_set_handler_locked() method, since
an ordinary (not Generic) irq_chip descriptor is now utilized. Note this
shalln't give any regression6) Alter CONFIG_GPIO_DWAPB kernel config to select
CONFIG_GPIOLIB_IRQCHIP instead of CONFIG_GENERIC_IRQ_CHIP.Note neither 4) nor 5) shall cause a regression of commit 6a2f4b7dadd5
("gpio: dwapb: use a second irq chip"), since the later isn't properly
used here anyway.Signed-off-by: Serge Semin
Reviewed-by: Andy Shevchenko
Link: https://lore.kernel.org/r/20200730152808.2955-6-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Linus Walleij -
Add a new macro DWAPB_MAX_GPIOS which defines the maximum possible number
of GPIO lines corresponding to the maximum DW APB GPIO controller port
width. Use the new macro instead of number literal 32 where it's
applicable.Suggested-by: Andy Shevchenko
Signed-off-by: Serge Semin
Reviewed-by: Andy Shevchenko
Link: https://lore.kernel.org/r/20200730152808.2955-5-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Linus Walleij -
For better readability let's group all the IRQ handlers in a single place
of the driver instead of having them scatter around all over the file.Signed-off-by: Serge Semin
Reviewed-by: Andy Shevchenko
Link: https://lore.kernel.org/r/20200730152808.2955-4-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Linus Walleij -
Indeed generic GPIO DT-schema implies that number of GPIOs should be
described by the "ngpios" property located under a GPIO-provider DT node.
In that case it's redundant to have a vendor-specific "snps,nr-gpios"
property describing the same setting. Moreover it might be errors prone.Since commit 93d2e4322aa7 ("of: platform: Batch fwnode parsing when adding
all top level devices") the fwnode parsing is resumed after the vast
majority of the platform devices are added. Implicitly that commit
activates re-parsing of the whole device tree GPIOs-phandle properties
detected having "-gpio/-gpios" suffixes. Since the vendor-specific number
of GPIOs property is defined with "-gpios" suffix, then of_link_property()
will consider it as a suffix-property with "#gpio-cells" structure, which
obviously it doesn't have. As a result for two DW APB GPIO controllers
we'll have the next errors printed.OF: /bus@1f059000/gpio@1f044000/gpio-port@0: could not find phandle
OF: /bus@1f059000/gpio@1f045000/gpio-port@0: could not get #gpio-cells for /opp-table
OF: /bus@1f059000/gpio@1f044000/gpio-port@0: could not find phandle
OF: /bus@1f059000/gpio@1f045000/gpio-port@0: could not get #gpio-cells for /opp-tableSee, the kernel fwnode parsing procedure even tried to resolve the phandle
ID, which it thought was the opp-table DT-node, while in fact it was just
a number "32". What would happen if that magic number actually referred to
a GPIO DT-node with "#gpio-cells" property defined?..In order to fix the problem let's mark the "snps,nr-gpios" property as
deprecated and add the generic "ngpios" property support with the same
purpose as the deprecated one. That and the errors log above shall
motivate the platform developer to convert the DW APB GPIO DT-nodes to
using the standard number of GPIOs property.Signed-off-by: Serge Semin
Reviewed-by: Andy Shevchenko
Link: https://lore.kernel.org/r/20200730152808.2955-3-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Linus Walleij -
It's redundant to have a vendor-specific property describing a number of
GPIOS while there is a generic one. Let's mark the former one as
deprecated and define the "ngpios" property supported with constraints
of being within [1; 32] range.Signed-off-by: Serge Semin
Reviewed-by: Rob Herring
Link: https://lore.kernel.org/r/20200730152808.2955-2-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Linus Walleij
