linux-toradex.git/drivers/pinctrl/qcom, branch v4.19 Linux kernel for Apalis and Colibri modules pinctrl: msm: Really mask level interrupts to prevent latching 2018-08-29T07:38:50+00:00 Stephen Boyd swboyd@chromium.org 2018-08-16T20:06:46+00:00 b55326dc969ea2d704a008d9a97583b128f54f4f The interrupt controller hardware in this pin controller has two status enable bits. The first "normal" status enable bit enables or disables the summary interrupt line being raised when a gpio interrupt triggers and the "raw" status enable bit allows or prevents the hardware from latching an interrupt into the status register for a gpio interrupt. Currently we just toggle the "normal" status enable bit in the mask and unmask ops so that the summary irq interrupt going to the CPU's interrupt controller doesn't trigger for the masked gpio interrupt. For a level triggered interrupt, the flow would be as follows: the pin controller sees the interrupt, latches the status into the status register, raises the summary irq to the CPU, summary irq handler runs and calls handle_level_irq(), handle_level_irq() masks and acks the gpio interrupt, the interrupt handler runs, and finally unmask the interrupt. When the interrupt handler completes, we expect that the interrupt line level will go back to the deasserted state so the genirq code can unmask the interrupt without it triggering again. If we only mask the interrupt by clearing the "normal" status enable bit then we'll ack the interrupt but it will continue to show up as pending in the status register because the raw status bit is enabled, the hardware hasn't deasserted the line, and thus the asserted state latches into the status register again. When the hardware deasserts the interrupt the pin controller still thinks there is a pending unserviced level interrupt because it latched it earlier. This behavior causes software to see an extra interrupt for level type interrupts each time the interrupt is handled. Let's fix this by clearing the raw status enable bit for level type interrupts so that the hardware stops latching the status of the interrupt after we ack it. We don't do this for edge type interrupts because it seems that toggling the raw status enable bit for edge type interrupts causes spurious edge interrupts. Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> 
The interrupt controller hardware in this pin controller has two status
enable bits. The first "normal" status enable bit enables or disables
the summary interrupt line being raised when a gpio interrupt triggers
and the "raw" status enable bit allows or prevents the hardware from
latching an interrupt into the status register for a gpio interrupt.
Currently we just toggle the "normal" status enable bit in the mask and
unmask ops so that the summary irq interrupt going to the CPU's
interrupt controller doesn't trigger for the masked gpio interrupt.

For a level triggered interrupt, the flow would be as follows: the pin
controller sees the interrupt, latches the status into the status
register, raises the summary irq to the CPU, summary irq handler runs
and calls handle_level_irq(), handle_level_irq() masks and acks the gpio
interrupt, the interrupt handler runs, and finally unmask the interrupt.
When the interrupt handler completes, we expect that the interrupt line
level will go back to the deasserted state so the genirq code can unmask
the interrupt without it triggering again.

If we only mask the interrupt by clearing the "normal" status enable bit
then we'll ack the interrupt but it will continue to show up as pending
in the status register because the raw status bit is enabled, the
hardware hasn't deasserted the line, and thus the asserted state latches
into the status register again. When the hardware deasserts the
interrupt the pin controller still thinks there is a pending unserviced
level interrupt because it latched it earlier. This behavior causes
software to see an extra interrupt for level type interrupts each time
the interrupt is handled.

Let's fix this by clearing the raw status enable bit for level type
interrupts so that the hardware stops latching the status of the
interrupt after we ack it. We don't do this for edge type interrupts
because it seems that toggling the raw status enable bit for edge type
interrupts causes spurious edge interrupts.

Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
pinctrl: qcom: spmi-gpio: Fix pmic_gpio_config_get() to be compliant 2018-07-09T11:16:01+00:00 Douglas Anderson dianders@chromium.org 2018-07-02T22:59:39+00:00 1cf86bc21257a330e3af51f2a4e885f1a705f6a5 If you do this on an sdm845 board: grep "" /sys/kernel/debug/pinctrl/*spmi:pmic*/pinconf-groups ...it looks like nonsense. For every pin you see listed: input bias disabled, input bias high impedance, input bias pull down, input bias pull up, ... That's because pmic_gpio_config_get() isn't complying with the rules that pinconf_generic_dump_one() expects. Specifically for boolean parameters (anything with a "struct pin_config_item" where has_arg is false) the function expects that the function should return its value not through the "config" parameter but should return "0" if the value is set and "-EINVAL" if the value isn't set. Let's fix this. From a quick sample of other pinctrl drivers, it appears to be tradition to also return 1 through the config parameter for these boolean parameters when they exist. I'm not one to knock tradition, so I'll follow tradition and return 1 in these cases. While I'm at it, I'll also continue searching for four leaf clovers, kocking on wood three times, and trying not to break mirrors. NOTE: This also fixes an apparent typo for reading PIN_CONFIG_BIAS_DISABLE where the old driver was accidentally using "=" instead of "==" and thus was setting some internal state when you tried to query PIN_CONFIG_BIAS_DISABLE. Oops. Fixes: eadff3024472 ("pinctrl: Qualcomm SPMI PMIC GPIO pin controller driver") Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> 
If you do this on an sdm845 board:
  grep "" /sys/kernel/debug/pinctrl/*spmi:pmic*/pinconf-groups

...it looks like nonsense.  For every pin you see listed:
  input bias disabled, input bias high impedance, input bias pull down, input bias pull up, ...

That's because pmic_gpio_config_get() isn't complying with the rules
that pinconf_generic_dump_one() expects.  Specifically for boolean
parameters (anything with a "struct pin_config_item" where has_arg is
false) the function expects that the function should return its value
not through the "config" parameter but should return "0" if the value
is set and "-EINVAL" if the value isn't set.

Let's fix this.

From a quick sample of other pinctrl drivers, it appears to be
tradition to also return 1 through the config parameter for these
boolean parameters when they exist.  I'm not one to knock tradition,
so I'll follow tradition and return 1 in these cases.  While I'm at
it, I'll also continue searching for four leaf clovers, kocking on
wood three times, and trying not to break mirrors.

NOTE: This also fixes an apparent typo for reading
PIN_CONFIG_BIAS_DISABLE where the old driver was accidentally
using "=" instead of "==" and thus was setting some internal
state when you tried to query PIN_CONFIG_BIAS_DISABLE.  Oops.

Fixes: eadff3024472 ("pinctrl: Qualcomm SPMI PMIC GPIO pin controller driver")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
pinctrl: msm: Fix msm_config_group_get() to be compliant 2018-07-09T11:14:09+00:00 Douglas Anderson dianders@chromium.org 2018-07-02T22:59:38+00:00 05e0c828955c1cab58dd71a04539442e5375d917 If you do this on an sdm845 board: cat /sys/kernel/debug/pinctrl/3400000.pinctrl/pinconf-groups ...it looks like nonsense. For every pin you see listed: input bias bus hold, input bias disabled, input bias pull down, input bias pull up That's because msm_config_group_get() isn't complying with the rules that pinconf_generic_dump_one() expects. Specifically for boolean parameters (anything with a "struct pin_config_item" where has_arg is false) the function expects that the function should return its value not through the "config" parameter but should return "0" if the value is set and "-EINVAL" if the value isn't set. Let's fix this. From a quick sample of other pinctrl drivers, it appears to be tradition to also return 1 through the config parameter for these boolean parameters when they exist. I'm not one to knock tradition, so I'll follow tradition and return 1 in these cases. While I'm at it, I'll also continue searching for four leaf clovers, kocking on wood three times, and trying not to break mirrors. Fixes: f365be092572 ("pinctrl: Add Qualcomm TLMM driver") Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> 
If you do this on an sdm845 board:
  cat /sys/kernel/debug/pinctrl/3400000.pinctrl/pinconf-groups

...it looks like nonsense.  For every pin you see listed:
  input bias bus hold, input bias disabled, input bias pull down, input bias pull up

That's because msm_config_group_get() isn't complying with the rules
that pinconf_generic_dump_one() expects.  Specifically for boolean
parameters (anything with a "struct pin_config_item" where has_arg is
false) the function expects that the function should return its value
not through the "config" parameter but should return "0" if the value
is set and "-EINVAL" if the value isn't set.

Let's fix this.

From a quick sample of other pinctrl drivers, it appears to be
tradition to also return 1 through the config parameter for these
boolean parameters when they exist.  I'm not one to knock tradition,
so I'll follow tradition and return 1 in these cases.  While I'm at
it, I'll also continue searching for four leaf clovers, kocking on
wood three times, and trying not to break mirrors.

Fixes: f365be092572 ("pinctrl: Add Qualcomm TLMM driver")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
pinctrl: msm: fix gpio-hog related boot issues 2018-05-24T08:03:51+00:00 Christian Lamparter chunkeey@gmail.com 2018-05-21T20:57:37+00:00 a86caa9ba5d70696ceb35d1d39caa20d8b641387 Sven Eckelmann reported an issue with the current IPQ4019 pinctrl. Setting up any gpio-hog in the device-tree for his device would "kill the bootup completely": | [ 0.477838] msm_serial 78af000.serial: could not find pctldev for node /soc/pinctrl@1000000/serial_pinmux, deferring probe | [ 0.499828] spi_qup 78b5000.spi: could not find pctldev for node /soc/pinctrl@1000000/spi_0_pinmux, deferring probe | [ 1.298883] requesting hog GPIO enable USB2 power (chip 1000000.pinctrl, offset 58) failed, -517 | [ 1.299609] gpiochip_add_data: GPIOs 0..99 (1000000.pinctrl) failed to register | [ 1.308589] ipq4019-pinctrl 1000000.pinctrl: Failed register gpiochip | [ 1.316586] msm_serial 78af000.serial: could not find pctldev for node /soc/pinctrl@1000000/serial_pinmux, deferring probe | [ 1.322415] spi_qup 78b5000.spi: could not find pctldev for node /soc/pinctrl@1000000/spi_0_pinmux, deferri This was also verified on a RT-AC58U (IPQ4018) which would no longer boot, if a gpio-hog was specified. (Tried forcing the USB LED PIN (GPIO0) to high.). The problem is that Pinctrl+GPIO registration is currently peformed in the following order in pinctrl-msm.c: 1. pinctrl_register() 2. gpiochip_add() 3. gpiochip_add_pin_range() The actual error code -517 == -EPROBE_DEFER is coming from pinctrl_get_device_gpio_range(), which is called through: gpiochip_add of_gpiochip_add of_gpiochip_scan_gpios gpiod_hog gpiochip_request_own_desc __gpiod_request chip->request gpiochip_generic_request pinctrl_gpio_request pinctrl_get_device_gpio_range pinctrl_get_device_gpio_range() is unable to find any valid pin ranges, since nothing has been added to the pinctrldev_list yet. so the range can't be found, and the operation fails with -EPROBE_DEFER. This patch fixes the issue by adding the "gpio-ranges" property to the pinctrl device node of all upstream Qcom SoC. The pin ranges are then added by the gpio core. In order to remain compatible with older, existing DTs (and ACPI) a check for the "gpio-ranges" property has been added to msm_gpio_init(). This prevents the driver of adding the same entry to the pinctrldev_list twice. Reported-by: Sven Eckelmann <sven.eckelmann@openmesh.com> Tested-by: Sven Eckelmann <sven.eckelmann@openmesh.com> [ipq4019] Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Christian Lamparter <chunkeey@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> 
Sven Eckelmann reported an issue with the current IPQ4019 pinctrl.
Setting up any gpio-hog in the device-tree for his device would
"kill the bootup completely":

| [    0.477838] msm_serial 78af000.serial: could not find pctldev for node /soc/pinctrl@1000000/serial_pinmux, deferring probe
| [    0.499828] spi_qup 78b5000.spi: could not find pctldev for node /soc/pinctrl@1000000/spi_0_pinmux, deferring probe
| [    1.298883] requesting hog GPIO enable USB2 power (chip 1000000.pinctrl, offset 58) failed, -517
| [    1.299609] gpiochip_add_data: GPIOs 0..99 (1000000.pinctrl) failed to register
| [    1.308589] ipq4019-pinctrl 1000000.pinctrl: Failed register gpiochip
| [    1.316586] msm_serial 78af000.serial: could not find pctldev for node /soc/pinctrl@1000000/serial_pinmux, deferring probe
| [    1.322415] spi_qup 78b5000.spi: could not find pctldev for node /soc/pinctrl@1000000/spi_0_pinmux, deferri

This was also verified on a RT-AC58U (IPQ4018) which would
no longer boot, if a gpio-hog was specified. (Tried forcing
the USB LED PIN (GPIO0) to high.).

The problem is that Pinctrl+GPIO registration is currently
peformed in the following order in pinctrl-msm.c:
	1. pinctrl_register()
	2. gpiochip_add()
	3. gpiochip_add_pin_range()

The actual error code -517 == -EPROBE_DEFER is coming from
pinctrl_get_device_gpio_range(), which is called through:
        gpiochip_add
            of_gpiochip_add
                of_gpiochip_scan_gpios
                    gpiod_hog
                        gpiochip_request_own_desc
                            __gpiod_request
                                chip->request
                                    gpiochip_generic_request
                                       pinctrl_gpio_request
                                          pinctrl_get_device_gpio_range

pinctrl_get_device_gpio_range() is unable to find any valid
pin ranges, since nothing has been added to the pinctrldev_list yet.
so the range can't be found, and the operation fails with -EPROBE_DEFER.

This patch fixes the issue by adding the "gpio-ranges" property to
the pinctrl device node of all upstream Qcom SoC. The pin ranges are
then added by the gpio core.

In order to remain compatible with older, existing DTs (and ACPI)
a check for the "gpio-ranges" property has been added to
msm_gpio_init(). This prevents the driver of adding the same entry
to the pinctrldev_list twice.

Reported-by: Sven Eckelmann <sven.eckelmann@openmesh.com>
Tested-by: Sven Eckelmann <sven.eckelmann@openmesh.com> [ipq4019]
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
pinctrl: qcom: Print high/low status of gpios in debugfs 2018-05-16T13:44:49+00:00 Stephen Boyd swboyd@chromium.org 2018-05-08T00:15:23+00:00 59a18c24ba4d7bc555e4d8327f26943309f51fa0 I was debugging some gpio issues and I thought that the output of gpio debugfs was telling me the high or low level of the gpios with a '1' or a '0'. We saw a line like this though: gpio93 : in 4 2mA pull down and I started to think that there may be a gas leak in the building because '4' doesn't mean high or low, and other pins said '0' or '1'. It turns out, '4' is the function selection for the pinmux of the gpio and not the value on the pin. Reading code helps decipher what debugfs is actually saying. Add support to read the input or output pin depending on how the pin is configured so we can easily see the high or low value of the pin in debugfs. Now the output looks like gpio93 : in low func4 2mA pull down which clearly shows that the pin is an input, low, with function 4 and a 2mA drive strength plus a pull down. Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Alexandru M Stan <amstan@chromium.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> 
I was debugging some gpio issues and I thought that the output of gpio
debugfs was telling me the high or low level of the gpios with a '1' or
a '0'. We saw a line like this though:

 gpio93  : in 4 2mA pull down

and I started to think that there may be a gas leak in the building
because '4' doesn't mean high or low, and other pins said '0' or '1'. It
turns out, '4' is the function selection for the pinmux of the gpio and
not the value on the pin. Reading code helps decipher what debugfs is
actually saying.

Add support to read the input or output pin depending on how the pin is
configured so we can easily see the high or low value of the pin in
debugfs. Now the output looks like

 gpio93  : in   low  func4 2mA pull down

which clearly shows that the pin is an input, low, with function 4 and a
2mA drive strength plus a pull down.

Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Alexandru M Stan <amstan@chromium.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
pinctrl: qcom: fix wrong pull status display for no_keeper SoC 2018-05-16T12:52:03+00:00 Clément Péron peron.clem@gmail.com 2018-05-04T23:57:28+00:00 53e73a28aa90a23f60ce8467bf57f214f4f11547 DebugFS strings about pin pull status for no_keeper SoC are wrong Fix this by adding a different string array for no_keeper SoC Signed-off-by: Clément Péron <peron.clem@gmail.com> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> 
DebugFS strings about pin pull status for no_keeper SoC are wrong

Fix this by adding a different string array for no_keeper SoC

Signed-off-by: Clément Péron <peron.clem@gmail.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
pinctrl: qcom: qdf2xxx: add support for new ACPI HID QCOM8002 2018-05-02T12:36:08+00:00 Timur Tabi timur@codeaurora.org 2018-04-25T22:43:27+00:00 e5080990849954aaba0e19bf6220b9855faef3b4 Newer versions of the firmware for the Qualcomm Datacenter Technologies QDF2400 restricts access to a subset of the GPIOs on the TLMM. To prevent older kernels from accidentally accessing the restricted GPIOs, we change the ACPI HID for the TLMM block from QCOM8001 to QCOM8002, and introduce a new property "gpios". This property is an array of specific GPIOs that are accessible. When an older kernel boots on newer (restricted) firmware, it will fail to probe. To implement the sparse GPIO map, we register all of the GPIOs, but fill in the data only for available GPIOs. This ensures that the driver cannot accidentally access an unavailable GPIO. The pinctrl-msm driver also scans the "gpios" property to determine which pins are available, and ensure that only those can be registered. Support for QCOM8001 is removed as there is no longer any firmware that implements it. Signed-off-by: Timur Tabi <timur@codeaurora.org> Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> 
Newer versions of the firmware for the Qualcomm Datacenter Technologies
QDF2400 restricts access to a subset of the GPIOs on the TLMM.  To
prevent older kernels from accidentally accessing the restricted GPIOs,
we change the ACPI HID for the TLMM block from QCOM8001 to QCOM8002,
and introduce a new property "gpios".  This property is an array of
specific GPIOs that are accessible.  When an older kernel boots on
newer (restricted) firmware, it will fail to probe.

To implement the sparse GPIO map, we register all of the GPIOs, but
fill in the data only for available GPIOs.  This ensures that the driver
cannot accidentally access an unavailable GPIO.

The pinctrl-msm driver also scans the "gpios" property to determine
which pins are available, and ensure that only those can be registered.

Support for QCOM8001 is removed as there is no longer any firmware that
implements it.

Signed-off-by: Timur Tabi <timur@codeaurora.org>
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
pinctrl: qcom: remove static globals to allow multiple TLMMs 2018-05-02T12:36:08+00:00 Timur Tabi timur@codeaurora.org 2018-04-25T22:43:26+00:00 f265e8b91bb50c7a732a171ddaeb0eef143bacd9 Two data structures are declared as static globals but are intended to be per-TLMM. Move them into the msm_pinctrl structure and initialize them at runtime. Signed-off-by: Timur Tabi <timur@codeaurora.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> 
Two data structures are declared as static globals but are intended to
be per-TLMM.  Move them into the msm_pinctrl structure and initialize
them at runtime.

Signed-off-by: Timur Tabi <timur@codeaurora.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Merge tag 'gpio-v4.17-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio 2018-04-05T16:51:41+00:00 Linus Torvalds torvalds@linux-foundation.org 2018-04-05T16:51:41+00:00 1b2951dd99af3970c1c1a8385a12b90236b837de Pull GPIO updates from Linus Walleij: "This is the bulk of GPIO changes for the v4.17 kernel cycle: New drivers: - Nintendo Wii GameCube GPIO, known as "Hollywood" - Raspberry Pi mailbox service GPIO expander - Spreadtrum main SC9860 SoC and IEC GPIO controllers. Improvements: - Implemented .get_multiple() callback for most of the high-performance industrial GPIO cards for the ISA bus. - ISA GPIO drivers now select the ISA_BUS_API instead of depending on it. This is merged with the same pattern for all the ISA drivers and some other Kconfig cleanups related to this. Cleanup: - Delete the TZ1090 GPIO drivers following the deletion of this SoC from the ARM tree. - Move the documentation over to driver-api to conform with the rest of the kernel documentation build. - Continue to make the GPIO drivers include only <linux/gpio/driver.h> and not the too broad <linux/gpio.h> that we want to get rid of. - Managed to remove VLA allocation from two drivers pending more fixes in this area for the next merge window. - Misc janitorial fixes" * tag 'gpio-v4.17-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (77 commits) gpio: Add Spreadtrum PMIC EIC driver support gpio: Add Spreadtrum EIC driver support dt-bindings: gpio: Add Spreadtrum EIC controller documentation gpio: ath79: Fix potential NULL dereference in ath79_gpio_probe() pinctrl: qcom: Don't allow protected pins to be requested gpiolib: Support 'gpio-reserved-ranges' property gpiolib: Change bitmap allocation to kmalloc_array gpiolib: Extract mask allocation into subroutine dt-bindings: gpio: Add a gpio-reserved-ranges property gpio: mockup: fix a potential crash when creating debugfs entries gpio: pca953x: add compatibility for pcal6524 and pcal9555a gpio: dwapb: Add support for a bus clock gpio: Remove VLA from xra1403 driver gpio: Remove VLA from MAX3191X driver gpio: ws16c48: Implement get_multiple callback gpio: gpio-mm: Implement get_multiple callback gpio: 104-idi-48: Implement get_multiple callback gpio: 104-dio-48e: Implement get_multiple callback gpio: pcie-idio-24: Implement get_multiple/set_multiple callbacks gpio: pci-idio-16: Implement get_multiple callback ... 
Pull GPIO updates from Linus Walleij:
 "This is the bulk of GPIO changes for the v4.17 kernel cycle:

  New drivers:

   - Nintendo Wii GameCube GPIO, known as "Hollywood"

   - Raspberry Pi mailbox service GPIO expander

   - Spreadtrum main SC9860 SoC and IEC GPIO controllers.

  Improvements:

   - Implemented .get_multiple() callback for most of the
     high-performance industrial GPIO cards for the ISA bus.

   - ISA GPIO drivers now select the ISA_BUS_API instead of depending on
     it. This is merged with the same pattern for all the ISA drivers
     and some other Kconfig cleanups related to this.

  Cleanup:

   - Delete the TZ1090 GPIO drivers following the deletion of this SoC
     from the ARM tree.

   - Move the documentation over to driver-api to conform with the rest
     of the kernel documentation build.

   - Continue to make the GPIO drivers include only
     <linux/gpio/driver.h> and not the too broad <linux/gpio.h> that we
     want to get rid of.

   - Managed to remove VLA allocation from two drivers pending more
     fixes in this area for the next merge window.

   - Misc janitorial fixes"

* tag 'gpio-v4.17-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (77 commits)
  gpio: Add Spreadtrum PMIC EIC driver support
  gpio: Add Spreadtrum EIC driver support
  dt-bindings: gpio: Add Spreadtrum EIC controller documentation
  gpio: ath79: Fix potential NULL dereference in ath79_gpio_probe()
  pinctrl: qcom: Don't allow protected pins to be requested
  gpiolib: Support 'gpio-reserved-ranges' property
  gpiolib: Change bitmap allocation to kmalloc_array
  gpiolib: Extract mask allocation into subroutine
  dt-bindings: gpio: Add a gpio-reserved-ranges property
  gpio: mockup: fix a potential crash when creating debugfs entries
  gpio: pca953x: add compatibility for pcal6524 and pcal9555a
  gpio: dwapb: Add support for a bus clock
  gpio: Remove VLA from xra1403 driver
  gpio: Remove VLA from MAX3191X driver
  gpio: ws16c48: Implement get_multiple callback
  gpio: gpio-mm: Implement get_multiple callback
  gpio: 104-idi-48: Implement get_multiple callback
  gpio: 104-dio-48e: Implement get_multiple callback
  gpio: pcie-idio-24: Implement get_multiple/set_multiple callbacks
  gpio: pci-idio-16: Implement get_multiple callback
  ...
pinctrl: qcom: Don't allow protected pins to be requested 2018-03-27T13:34:25+00:00 Stephen Boyd sboyd@codeaurora.org 2018-03-23T16:34:53+00:00 691bf5d5a7bfedc60b7218f4d9b915bf356df767 Some qcom platforms make some GPIOs or pins unavailable for use by non-secure operating systems, and thus reading or writing the registers for those pins will cause access control issues and reset the device. With a DT/ACPI property to describe the set of pins that are available for use, parse the available pins and set the irq valid bits for gpiolib to know what to consider 'valid'. This should avoid any issues with gpiolib. Furthermore, implement the pinmux_ops::request function so that pinmux can also make sure to not use pins that are unavailable. Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Tested-by: Timur Tabi <timur@codeaurora.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> 
Some qcom platforms make some GPIOs or pins unavailable for use
by non-secure operating systems, and thus reading or writing the
registers for those pins will cause access control issues and
reset the device. With a DT/ACPI property to describe the set of
pins that are available for use, parse the available pins and set
the irq valid bits for gpiolib to know what to consider 'valid'.
This should avoid any issues with gpiolib. Furthermore, implement
the pinmux_ops::request function so that pinmux can also make
sure to not use pins that are unavailable.

Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Tested-by: Timur Tabi <timur@codeaurora.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>