litmus-rt-budgetable-locks.git/.git/include/linux/gpio, branch update_litmus_2019

gpiolib: Initialize the hardware with a callback

2019-10-14T23:18:46+00:00

After changing the drivers to use GPIO core to add an IRQ chip
it appears that some of them requires a hardware initialization
before adding the IRQ chip.

Add an optional callback ->init_hw() to allow that drivers
to initialize hardware if needed.

This change is a part of the fix NULL pointer dereference
brought to the several drivers recently.

Cc: Hans de Goede 
Signed-off-by: Andy Shevchenko 
Signed-off-by: Linus Walleij

gpio: Initialize the irqchip valid_mask with a callback

2019-09-11T00:09:37+00:00

After changing the valid_mask for the struct gpio_chip
to detect the need and presence of a valid mask with the
presence of a .init_valid_mask() callback to fill it in,
we augment the gpio_irq_chip to use the same logic.

Switch all driver using the gpio_irq_chio valid_mask
over to this new method.

This makes sure the valid_mask for the gpio_irq_chip gets
filled in when we add the gpio_chip, which makes it a
little easier to switch over drivers using the old
way of setting up gpio_irq_chip over to the new method
of passing the gpio_irq_chip along with the gpio_chip.
(See drivers/gpio/TODO for details.)

Cc: Joel Stanley 
Cc: Thierry Reding 
Signed-off-by: Linus Walleij 
Reviewed-by: Andy Shevchenko 
Tested-by: Hans de Goede 
Reviewed-by: Andrew Jeffery 
Acked-by: Mika Westerberg 
Reviewed-by: Andrew Lunn 
Reviewed-by: Patrice Chotard 
Link: https://lore.kernel.org/r/20190904140104.32426-1-linus.walleij@linaro.org

Merge tag 'v5.3-rc7' into devel

2019-09-05T09:40:54+00:00

Linux 5.3-rc7

gpio: Fix up merge collision in include file

2019-09-05T09:20:25+00:00

The merge of two different patch sets cleaning around in the
main driver include file collided making the function
declarations for gpiochip_[un]lock_as_irq() be defined twice
when gpiolib was unselected. Fix it up.

Cc: YueHaibing 
Cc: Masahiro Yamada 
Reported-by: kbuild test robot 
Signed-off-by: Linus Walleij

Merge tag 'gpio-v5.4-updates-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux into devel

2019-09-03T14:04:19+00:00

gpio: updates for v5.4

- use a helper variable for &pdev->dev in gpio-em
- tweak the ifdefs in GPIO headers
- fix function links in HTML docs
- remove an unneeded error message from ixp4xx
- use the optional clk_get in gpio-mxc instead of checking the return value
- a couple improvements in pca953x
- allow to build gpio-lpc32xx on non-lpc32xx targets

gpio: Move gpiochip_lock/unlock_as_irq to gpio/driver.h

2019-08-23T09:59:23+00:00

If CONFIG_GPIOLIB is not, gpiochip_lock/unlock_as_irq will
conflict as this:

In file included from sound/soc/codecs/wm5100.c:18:0:
./include/linux/gpio.h:224:19: error: static declaration of gpiochip_lock_as_irq follows non-static declaration
 static inline int gpiochip_lock_as_irq(struct gpio_chip *chip,
                   ^~~~~~~~~~~~~~~~~~~~
In file included from sound/soc/codecs/wm5100.c:17:0:
./include/linux/gpio/driver.h:494:5: note: previous declaration of gpiochip_lock_as_irq was here
 int gpiochip_lock_as_irq(struct gpio_chip *chip, unsigned int offset);
     ^~~~~~~~~~~~~~~~~~~~
In file included from sound/soc/codecs/wm5100.c:18:0:
./include/linux/gpio.h:231:20: error: static declaration of gpiochip_unlock_as_irq follows non-static declaration
 static inline void gpiochip_unlock_as_irq(struct gpio_chip *chip,
                    ^~~~~~~~~~~~~~~~~~~~~~
In file included from sound/soc/codecs/wm5100.c:17:0:
./include/linux/gpio/driver.h:495:6: note: previous declaration of gpiochip_unlock_as_irq was here
 void gpiochip_unlock_as_irq(struct gpio_chip *chip, unsigned int offset);
     ^~~~~~~~~~~~~~~~~~~~~~

Move them to gpio/driver.h and use CONFIG_GPIOLIB guard this.

Reported-by: Hulk Robot 
Fixes: d74be6dfea1b ("gpio: remove gpiod_lock/unlock_as_irq()")
Signed-off-by: YueHaibing 
Link: https://lore.kernel.org/r/20190822031817.32888-1-yuehaibing@huawei.com
Signed-off-by: Linus Walleij

gpio: Use callback presence to determine need of valid_mask

2019-08-20T08:42:07+00:00

After we switched the two drivers that have .need_valid_mask
set to use the callback for setting up the .valid_mask,
we can just use the presence of the .init_valid_mask()
callback (or the OF reserved ranges, nota bene) to determine
whether to allocate the mask or not and we can drop the
.need_valid_mask field altogether.

Cc: Benjamin Gaignard 
Cc: Amelie Delaunay 
Cc: Stephen Boyd 
Cc: Bjorn Andersson 
Signed-off-by: Linus Walleij 
Link: https://lore.kernel.org/r/20190819093058.10863-1-linus.walleij@linaro.org

gpio: Pass mask and size with the init_valid_mask()

2019-08-20T08:42:07+00:00

It is more helpful for drivers to have the affected fields
directly available when we use the callback to set up the
valid mask. Change this and switch over the only user
(MSM) to use the passed parameters. If we do this we can
also move the mask out of publicly visible struct fields.

Cc: Stephen Boyd 
Cc: Bjorn Andersson 
Signed-off-by: Linus Walleij 
Link: https://lore.kernel.org/r/20190819084904.30027-1-linus.walleij@linaro.or
Reviewed-by: Stephen Boyd 
Signed-off-by: Linus Walleij

gpio: stubs in headers should be inline

2019-08-20T08:42:07+00:00

Fixes: fdd61a013a24 ("gpio: Add support for hierarchical IRQ domains")
Signed-off-by: Stephen Rothwell 
Link: https://lore.kernel.org/r/20190816213812.40a130db@canb.auug.org.au
Signed-off-by: Linus Walleij

gpio: Add support for hierarchical IRQ domains

2019-08-15T07:44:19+00:00

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 
Cc: Marc Zyngier 
Cc: Lina Iyer 
Cc: Jon Hunter 
Cc: Sowjanya Komatineni 
Cc: Bitan Biswas 
Cc: linux-tegra@vger.kernel.org
Cc: David Daney 
Cc: Masahiro Yamada 
Cc: Brian Masney 
Signed-off-by: Thierry Reding 
Signed-off-by: Brian Masney 
Co-developed-by: Brian Masney 
Signed-off-by: Linus Walleij 
Link: https://lore.kernel.org/r/20190808123242.5359-1-linus.walleij@linaro.org