Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 22 11月, 2019 1 次提交
  3. 14 11月, 2019 1 次提交
  5. 13 11月, 2019 1 次提交
  7. 12 11月, 2019 6 次提交
  9. 08 11月, 2019 1 次提交
  11. 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
  13. 05 11月, 2019 1 次提交
  15. 15 10月, 2019 1 次提交
  17. 06 10月, 2019 1 次提交
  19. 03 10月, 2019 1 次提交
  21. 01 10月, 2019 2 次提交
  23. 12 9月, 2019 1 次提交
  25. 11 9月, 2019 1 次提交
  27. 09 9月, 2019 2 次提交
  29. 06 9月, 2019 1 次提交
  31. 04 9月, 2019 1 次提交
  33. 23 8月, 2019 2 次提交
  35. 20 8月, 2019 2 次提交
  37. 15 8月, 2019 1 次提交
    • L
      gpio: Add support for hierarchical IRQ domains · fdd61a01
      由 Linus Walleij 提交于 
      Hierarchical IRQ domains can be used to stack different IRQ
controllers on top of each other.

Bring hierarchical IRQ domains into the GPIOLIB core with the
following basic idea:

Drivers that need their interrupts handled hierarchically
specify a callback to translate the child hardware IRQ and
IRQ type for each GPIO offset to a parent hardware IRQ and
parent hardware IRQ type.

Users have to pass the callback, fwnode, and parent irqdomain
before calling gpiochip_irqchip_add().

We use the new method of just filling in the struct
gpio_irq_chip before adding the gpiochip for all hierarchical
irqchips of this type.

The code path for device tree is pretty straight-forward,
while the code path for old boardfiles or anything else will
be more convoluted requireing upfront allocation of the
interrupts when adding the chip.

One specific use-case where this can be useful is if a power
management controller has top-level controls for wakeup
interrupts. In such cases, the power management controller can
be a parent to other interrupt controllers and program
additional registers when an IRQ has its wake capability
enabled or disabled.

The hierarchical irqchip helper code will only be available
when IRQ_DOMAIN_HIERARCHY is selected to GPIO chips using
this should select or depend on that symbol. When using
hierarchical IRQs, the parent interrupt controller must
also be hierarchical all the way up to the top interrupt
controller wireing directly into the CPU, so on systems
that do not have this we can get rid of all the extra
code for supporting hierarchical irqs.

Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Lina Iyer <ilina@codeaurora.org>
Cc: Jon Hunter <jonathanh@nvidia.com>
Cc: Sowjanya Komatineni <skomatineni@nvidia.com>
Cc: Bitan Biswas <bbiswas@nvidia.com>
Cc: linux-tegra@vger.kernel.org
Cc: David Daney <david.daney@cavium.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Brian Masney <masneyb@onstation.org>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NBrian Masney <masneyb@onstation.org>
Co-developed-by: NBrian Masney <masneyb@onstation.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20190808123242.5359-1-linus.walleij@linaro.org
      fdd61a01
  39. 14 8月, 2019 1 次提交
  41. 03 8月, 2019 1 次提交
  43. 01 8月, 2019 1 次提交
  45. 31 7月, 2019 1 次提交
  47. 29 7月, 2019 2 次提交
  49. 22 7月, 2019 1 次提交
    • M
      gpiolib: fix incorrect IRQ requesting of an active-low lineevent · 223ecaf1
      由 Michael Wu 提交于 
      When a pin is active-low, logical trigger edge should be inverted to match
the same interrupt opportunity.

For example, a button pushed triggers falling edge in ACTIVE_HIGH case; in
ACTIVE_LOW case, the button pushed triggers rising edge. For user space the
IRQ requesting doesn't need to do any modification except to configuring
GPIOHANDLE_REQUEST_ACTIVE_LOW.

For example, we want to catch the event when the button is pushed. The
button on the original board drives level to be low when it is pushed, and
drives level to be high when it is released.

In user space we can do:

	req.handleflags = GPIOHANDLE_REQUEST_INPUT;
	req.eventflags = GPIOEVENT_REQUEST_FALLING_EDGE;

	while (1) {
		read(fd, &dat, sizeof(dat));
		if (dat.id == GPIOEVENT_EVENT_FALLING_EDGE)
			printf("button pushed\n");
	}

Run the same logic on another board which the polarity of the button is
inverted; it drives level to be high when pushed, and level to be low when
released. For this inversion we add flag GPIOHANDLE_REQUEST_ACTIVE_LOW:

	req.handleflags = GPIOHANDLE_REQUEST_INPUT |
		GPIOHANDLE_REQUEST_ACTIVE_LOW;
	req.eventflags = GPIOEVENT_REQUEST_FALLING_EDGE;

At the result, there are no any events caught when the button is pushed.
By the way, button releasing will emit a "falling" event. The timing of
"falling" catching is not expected.

Cc: stable@vger.kernel.org
Signed-off-by: NMichael Wu <michael.wu@vatics.com>
Tested-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
      223ecaf1
  51. 04 7月, 2019 2 次提交
  53. 27 6月, 2019 1 次提交
  55. 25 6月, 2019 1 次提交
    • W
      gpio: Fix return value mismatch of function gpiod_get_from_of_node() · 025bf377
      由 Waibel Georg 提交于 
      In case the requested gpio property is not found in the device tree, some
callers of gpiod_get_from_of_node() expect a return value of NULL, others
expect -ENOENT.
In particular devm_fwnode_get_index_gpiod_from_child() expects -ENOENT.
Currently it gets a NULL, which breaks the loop that tries all
gpio_suffixes. The result is that a gpio property is not found, even
though it is there.

This patch changes gpiod_get_from_of_node() to return -ENOENT instead
of NULL when the requested gpio property is not found in the device
tree. Additionally it modifies all calling functions to properly
evaluate the return value.

Another approach would be to leave the return value of
gpiod_get_from_of_node() as is and fix the bug in
devm_fwnode_get_index_gpiod_from_child(). Other callers would still need
to be reworked. The effort would be the same as with the chosen solution.
Signed-off-by: NGeorg Waibel <georg.waibel@sensor-technik.de>
Reviewed-by: NKrzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>
      025bf377
  57. 14 6月, 2019 1 次提交