Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 08 7月, 2020 1 次提交
  3. 16 4月, 2020 1 次提交
    • L
      usb: fusb302: Convert to use GPIO descriptors · 6e24826d
      由 Linus Walleij 提交于 
      This converts the FUSB302 driver to use GPIO descriptors.
The conversion to descriptors per se is pretty straight-forward.

In the process I discovered that:

1. The driver uses a completely undocumented device tree binding
   for the interrupt GPIO line, "fcs,int_n". Ooops.

2. The undocumented binding, presumably since it has not seen
   review, is just "fcs,int_n", lacking the compulsory "-gpios"
   suffix and also something that is not a good name because
   the "_n" implies the line is inverted which is something we
   handle with flags in the device tree. Ooops.

3. Possibly the driver should not be requesting the line as a
   GPIO and request the corresponding interrupt line by open
   coding, the GPIO chip is very likely doubleing as an IRQ
   controller and can probably provide an interrupt directly
   for this line with interrupts-extended = <&gpio0 ...>;

4. Possibly the IRQ should just be tagged on the I2C client node
   in the device tree like apparently ACPI does, as it overrides
   this IRQ with client->irq if that exists.

But now it is too late to do much about that and as I can see
this is used like this in the Pinebook which is a shipping product
so let'a just contain the mess and move on.

The property currently appears in:
arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts

Create a quirk in the GPIO OF library to allow this property
specifically to be specified without the "-gpios" suffix, we have
other such bindings already.

Cc: Tobias Schramm <t.schramm@manjaro.org>
Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Cc: Yueyao Zhu <yueyao@google.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: devicetree@vger.kernel.org
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20200415192448.305257-1-linus.walleij@linaro.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6e24826d
  5. 15 4月, 2020 1 次提交
  7. 22 2月, 2020 2 次提交
  9. 04 2月, 2020 1 次提交
  11. 18 12月, 2019 2 次提交
  13. 03 12月, 2019 1 次提交
  15. 28 11月, 2019 1 次提交
  17. 22 11月, 2019 1 次提交
  19. 07 11月, 2019 1 次提交
    • A
      gpiolib: No need to call gpiochip_remove_pin_ranges() twice · 2f4133bb
      由 Andy Shevchenko 提交于 
      of_gpiochip_add(), when fails, calls gpiochip_remove_pin_ranges().

ADD:
  gpiochip_add_data_with_key() ->
    of_gpiochip_add() -> (ERROR path)
      gpiochip_remove_pin_ranges()

At the same time of_gpiochip_remove() calls exactly the above mentioned
function unconditionally and so does gpiochip_remove().

REMOVE:
  gpiochip_remove() ->
    gpiochip_remove_pin_ranges()
    of_gpiochip_remove() ->
      gpiochip_remove_pin_ranges()

Since gpiochip_remove() calls gpiochip_remove_pin_ranges() unconditionally,
we have duplicate call to the same function when it's not necessary.

Move gpiochip_remove_pin_ranges() from of_gpiochip_add() to gpiochip_add()
to avoid duplicate calls and be consistent with the explicit call in
gpiochip_remove().

Fixes: e93fa3f2 ("gpiolib: remove duplicate pin range code")
Depends-on: f7299d44 ("gpio: of: Fix of_gpiochip_add() error path")
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      2f4133bb
  21. 18 10月, 2019 1 次提交
  23. 09 10月, 2019 1 次提交
  25. 01 10月, 2019 1 次提交
  27. 12 9月, 2019 1 次提交
  29. 11 9月, 2019 3 次提交
  31. 10 9月, 2019 1 次提交
  33. 04 9月, 2019 1 次提交
  35. 17 8月, 2019 1 次提交
  37. 01 8月, 2019 1 次提交
  39. 29 7月, 2019 1 次提交
  41. 16 7月, 2019 1 次提交
    • L
      Revert "gpio/spi: Fix spi-gpio regression on active high CS" · da7f1349
      由 Linus Walleij 提交于 
      This reverts commit fbbf145a.

It seems I was misguided in my fixup, which was working at the
time but did not work on the final v5.2.

The patch tried to avoid a quirk the gpiolib code not to treat
"spi-gpio" CS gpios "special" by enforcing them to be active
low, in the belief that since the "spi-gpio" driver was
parsing the device tree on its own, it did not care to inspect
the "spi-cs-high" attribute on the device nodes.

That's wrong. The SPI core was inspecting them inside the
of_spi_parse_dt() funtion and setting SPI_CS_HIGH on the
nodes, and the driver inspected this flag when driving the
line.

As of now, the core handles the GPIO and it will consistently
set the GPIO descriptor to 1 to enable CS, strictly requireing
the gpiolib to invert it. And the gpiolib should indeed
enforce active low on the CS line.

Device trees should of course put the right flag on the GPIO
handles, but it used to not matter. If we don't enforce active
low on "gpio-gpio" we may run into ABI backward compatibility
issues, so revert this.

Cc: linux-spi@vger.kernel.org
Cc: stable@vger.kernel.org
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20190715204529.9539-1-linus.walleij@linaro.org
      da7f1349
  43. 15 7月, 2019 1 次提交
  45. 03 7月, 2019 1 次提交
    • L
      gpio/spi: Fix spi-gpio regression on active high CS · fbbf145a
      由 Linus Walleij 提交于 
      I ran into an intriguing bug caused by
commit ""spi: gpio: Don't request CS GPIO in DT use-case"
affecting all SPI GPIO devices with an active high
chip select line.

The commit switches the CS gpio handling over to the GPIO
core, which will parse and handle "cs-gpios" from the OF
node without even calling down to the driver to get the
job done.

However the GPIO core handles the standard bindings in
Documentation/devicetree/bindings/spi/spi-controller.yaml
that specifies that active high CS needs to be specified
using "spi-cs-high" in the DT node.

The code in drivers/spi/spi-gpio.c never respected this
and never tried to inspect subnodes to see if they contained
"spi-cs-high" like the gpiolib OF quirks does. Instead the
only way to get an active high CS was to tag it in the
device tree using the flags cell such as
cs-gpios = <&gpio 4 GPIO_ACTIVE_HIGH>;

This alters the quirks to not inspect the subnodes of SPI
masters on "spi-gpio" for the standard attribute "spi-cs-high",
making old device trees work as expected.

This semantic is a bit ambigous, but just allowing the
flags on the GPIO descriptor to modify polarity is what
the kernel at large mostly uses so let's encourage that.

Fixes: 249e2632 ("spi: gpio: Don't request CS GPIO in DT use-case")
Cc: Andrey Smirnov <andrew.smirnov@gmail.com>
Cc: linux-gpio@vger.kernel.org
Cc: linux-spi@vger.kernel.org
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      fbbf145a
  47. 12 6月, 2019 1 次提交
    • M
      gpio: of: parse stmmac PHY reset line specific active-low property · edc1ef3f
      由 Martin Blumenstingl 提交于 
      The stmmac driver currently ignores the GPIO flags which are passed via
devicetree because it operates with legacy GPIO numbers instead of GPIO
descriptors. stmmac assumes that the GPIO is "active HIGH" by default.
This can be overwritten by setting "snps,reset-active-low" to make the
reset line "active LOW".

Recent Amlogic SoCs (G12A which includes S905X2 and S905D2 as well as
G12B which includes S922X) use GPIOZ_14 or GPIOZ_15 for the PHY reset
line. These GPIOs are special because they are marked as "3.3V input
tolerant open drain" pins which means they can only drive the pin output
LOW (to reset the PHY) or to switch to input mode (to take the PHY out
of reset).
The GPIO subsystem already supports this with the GPIO_OPEN_DRAIN and
GPIO_OPEN_SOURCE flags in the devicetree bindings.

Add the stmmac PHY reset line specific active low parsing to gpiolib-of
so stmmac can be ported to GPIO descriptors while being backwards
compatible with device trees which use the "old" way of specifying the
polarity.
Signed-off-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      edc1ef3f
  49. 31 5月, 2019 1 次提交
  51. 23 4月, 2019 2 次提交
  53. 08 4月, 2019 1 次提交
  55. 29 3月, 2019 3 次提交
  57. 21 2月, 2019 2 次提交
    • M
      gpio: of: Handle both enable-gpio{,s} · 21b4ab8f
      由 Marek Vasut 提交于 
      Handle both enable-gpio and enable-gpios properties of the GPIO
regulator in the quirk. The later is the preferred modern name
of the property.
Signed-off-by: NMarek Vasut <marek.vasut+renesas@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Jan Kotas <jank@cadence.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Mark Brown <broonie@kernel.org>
Cc: Thierry Reding <treding@nvidia.com>
Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
Cc: linux-renesas-soc@vger.kernel.org
To: linux-gpio@vger.kernel.org
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      21b4ab8f
    • T
      gpio: of: Restrict enable-gpio quirk to regulator-gpio · 692ef26e
      由 Thierry Reding 提交于 
      Commit 0e7d6f94 ("gpio: of: Apply regulator-gpio quirk only to
enable-gpios") breaks the device tree ABI specified in the device tree
bindings for fixed regulators (compatible "regulator-fixed"). According
to these bindings the polarity of the GPIO is exclusively controlled by
the presence or absence of the enable-active-high property. As such the
polarity quirk implemented in of_gpio_flags_quirks() must be applied to
the GPIO specified for fixed regulators.

However, commit 0e7d6f94 ("gpio: of: Apply regulator-gpio quirk only
to enable-gpios") restricted the quirk to the enable-gpios property for
fixed regulators as well, whereas according to the commit message itself
it should only apply to "regulator-gpio" compatible device tree nodes.

Fix this by actually implementing what the offending commit intended,
which is to ensure that the quirk is applied to the GPIO specified by
the "enable-gpio" property for the "regulator-gpio" bindings only.

This fixes a regression on Jetson TX1 where the fixed regulator for the
HDMI +5V pin relies on the flags quirk for the proper polarity.

Fixes: 0e7d6f94 ("gpio: of: Apply regulator-gpio quirk only to enable-gpios")
Signed-off-by: NThierry Reding <treding@nvidia.com>
Tested-by: NMarek Vasut <marek.vasut@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      692ef26e
  59. 18 2月, 2019 1 次提交
    • M
      gpio: of: Apply regulator-gpio quirk only to enable-gpios · 0e7d6f94
      由 Marek Vasut 提交于 
      Since commit d6cd33ad ("regulator: gpio: Convert to use descriptors")
the GPIO regulator had inverted the polarity of the control GPIO. This
problem manifested itself on systems with DT containing the following
description (snippet from salvator-common.dtsi):

	gpios = <&gpio5 1 GPIO_ACTIVE_HIGH>;
	gpios-states = <1>;
	states = <3300000 1
		  1800000 0>;

Prior to the aforementioned commit, the gpio-regulator code used
gpio_request_array() to claim the GPIO(s) specified in the "gpios"
DT node, while the commit changed that to devm_gpiod_get_index().

The legacy gpio_request_array() calls gpio_request_one() and then
gpiod_request(), which parses the DT flags of the "gpios" node and
populates the GPIO descriptor flags field accordingly.

The new devm_gpiod_get_index() calls gpiod_get_index(), then
of_find_gpio(), of_get_named_gpiod_flags() with flags != NULL,
and then of_gpio_flags_quirks(). Since commit a603a2b8
("gpio: of: Add special quirk to parse regulator flags"),
of_gpio_flags_quirks() contains a quirk for regulator-gpio
which was never triggered by the legacy gpio_request_array()
code path, but is triggered by devm_gpiod_get_index() code
path.

This quirk checks whether a GPIO is associated with a fixed
or gpio-regulator and if so, checks two additional conditions.
First, whether such GPIO is active-low, and if so, ignores the
active-low flag. Second, whether the regulator DT node does
have an "enable-active-high" property and if the property is
NOT present, sets the GPIO flags as active-low.

The second check triggers a problem, since it is applied to all
GPIOs associated with a gpio-regulator, rather than only on the
"enable" GPIOs, as the old code did. This changes the way the
gpio-regulator interprets the DT description of the control
GPIOs.

The old code using gpio_request_array() explicitly parsed the
"enable-active-high" DT property and only applied it to the
GPIOs described in the "enable-gpios" DT node, and only if
those were present.

This patch fixes the quirk code by only applying the quirk
to "enable-gpios", thus restoring the old behavior.
Signed-off-by: NMarek Vasut <marek.vasut+renesas@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Jan Kotas <jank@cadence.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Mark Brown <broonie@kernel.org>
Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
Cc: linux-renesas-soc@vger.kernel.org
To: linux-gpio@vger.kernel.org
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      0e7d6f94
  61. 13 2月, 2019 1 次提交
    • T
      gpio: add core support for pull-up/pull-down configuration · d449991c
      由 Thomas Petazzoni 提交于 
      This commit adds support for configuring the pull-up and pull-down
resistors available in some GPIO controllers. While configuring
pull-up/pull-down is already possible through the pinctrl subsystem,
some GPIO controllers, especially simple ones such as GPIO expanders
on I2C, don't have any pinmuxing capability and therefore do not use
the pinctrl subsystem.

This commit implements the GPIO_PULL_UP and GPIO_PULL_DOWN flags,
which can be used from the Device Tree, to enable a pull-up or
pull-down resistor on a given GPIO.

The flag is simply propagated all the way to the core GPIO subsystem,
where it is used to call the gpio_chip ->set_config callback with the
appropriate existing PIN_CONFIG_BIAS_* values.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      d449991c
  63. 25 1月, 2019 1 次提交