<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/include/linux/gpio/driver.h, branch linux-5.16.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-5.16.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-5.16.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2022-04-13T18:03:21Z</updated>
<entry>
<title>gpio: Restrict usage of GPIO chip irq members before initialization</title>
<updated>2022-04-13T18:03:21Z</updated>
<author>
<name>Shreeya Patel</name>
<email>shreeya.patel@collabora.com</email>
</author>
<published>2022-03-21T13:32:41Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=2c1fa3614795e2b24da1ba95de0b27b8f6ea4537'/>
<id>urn:sha1:2c1fa3614795e2b24da1ba95de0b27b8f6ea4537</id>
<content type='text'>
commit 5467801f1fcbdc46bc7298a84dbf3ca1ff2a7320 upstream.

GPIO chip irq members are exposed before they could be completely
initialized and this leads to race conditions.

One such issue was observed for the gc-&gt;irq.domain variable which
was accessed through the I2C interface in gpiochip_to_irq() before
it could be initialized by gpiochip_add_irqchip(). This resulted in
Kernel NULL pointer dereference.

Following are the logs for reference :-

kernel: Call Trace:
kernel:  gpiod_to_irq+0x53/0x70
kernel:  acpi_dev_gpio_irq_get_by+0x113/0x1f0
kernel:  i2c_acpi_get_irq+0xc0/0xd0
kernel:  i2c_device_probe+0x28a/0x2a0
kernel:  really_probe+0xf2/0x460
kernel: RIP: 0010:gpiochip_to_irq+0x47/0xc0

To avoid such scenarios, restrict usage of GPIO chip irq members before
they are completely initialized.

Signed-off-by: Shreeya Patel &lt;shreeya.patel@collabora.com&gt;
Cc: stable@vger.kernel.org
Reviewed-by: Andy Shevchenko &lt;andy.shevchenko@gmail.com&gt;
Reviewed-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Bartosz Golaszewski &lt;brgl@bgdev.pl&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>gpio: Allow per-parent interrupt data</title>
<updated>2021-10-26T22:16:00Z</updated>
<author>
<name>Marc Zyngier</name>
<email>maz@kernel.org</email>
</author>
<published>2021-10-26T17:58:11Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=cfe6807d82e97e81c3209dca9448f091e1448a57'/>
<id>urn:sha1:cfe6807d82e97e81c3209dca9448f091e1448a57</id>
<content type='text'>
The core gpiolib code is able to deal with multiple interrupt parents
for a single gpio irqchip. It however only allows a single piece
of data to be conveyed to all flow handlers (either the gpio_chip
or some other, driver-specific data).

This means that drivers have to go through some interesting dance
to find the correct context, something that isn't great in interrupt
context (see aebdc8abc9db86e2bd33070fc2f961012fff74b4 for a prime
example).

Instead, offer an optional way for a pinctrl/gpio driver to provide
an array of pointers which gets used to provide the correct context
to the flow handler.

Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Signed-off-by: Joey Gouly &lt;joey.gouly@arm.com&gt;
Reviewed-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Link: https://lore.kernel.org/r/20211026175815.52703-2-joey.gouly@arm.com
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
</content>
</entry>
<entry>
<title>gpiolib: convert 'devprop_gpiochip_set_names' to support multiple gpiochip banks per device</title>
<updated>2021-07-29T17:41:12Z</updated>
<author>
<name>Sergio Paracuellos</name>
<email>sergio.paracuellos@gmail.com</email>
</author>
<published>2021-07-28T04:12:51Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=4e804c39f1be4498d80f379e5b7bc6d4f80f813c'/>
<id>urn:sha1:4e804c39f1be4498d80f379e5b7bc6d4f80f813c</id>
<content type='text'>
The default gpiolib-of implementation does not work with the multiple
gpiochip banks per device structure used for example by the gpio-mt7621
and gpio-brcmstb drivers. To fix these kind of situations driver code
is forced to fill the names to avoid the gpiolib code to set names
repeated along the banks. Instead of continue with that antipattern
fix the gpiolib core function to get expected behaviour for every
single situation adding a field 'offset' in the gpiochip structure.
Doing in this way, we can assume this offset will be zero for normal
driver code where only one gpiochip bank per device is used but
can be set explicitly in those drivers that really need more than
one gpiochip.

Reviewed-by: Andy Shevchenko &lt;andy.shevchenko@gmail.com&gt;
Reviewed-by: Gregory Fong &lt;gregory.0xf0@gmail.com&gt;
Signed-off-by: Sergio Paracuellos &lt;sergio.paracuellos@gmail.com&gt;
Signed-off-by: Bartosz Golaszewski &lt;bgolaszewski@baylibre.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'gpio-updates-for-v5.13-v2' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux</title>
<updated>2021-05-05T19:39:29Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2021-05-05T19:39:29Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=5d6a1b84e07607bc282ed2ed8e2f128c73697d5c'/>
<id>urn:sha1:5d6a1b84e07607bc282ed2ed8e2f128c73697d5c</id>
<content type='text'>
Pull gpio updates from Bartosz Golaszewski:

 - new driver for the Realtek Otto GPIO controller

 - ACPI support for gpio-mpc8xxx

 - edge event support for gpio-sch (+ Kconfig fixes)

 - Kconfig improvements in gpio-ich

 - fixes to older issues in gpio-mockup

 - ACPI quirk for ignoring EC wakeups on Dell Venue 10 Pro 5055

 - improve the GPIO aggregator code by using more generic interfaces
   instead of reimplementing them in the driver

 - convert the DT bindings for gpio-74x164 to yaml

 - documentation improvements

 - a slew of other minor fixes and improvements to GPIO drivers

* tag 'gpio-updates-for-v5.13-v2' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: (34 commits)
  dt-bindings: gpio: add YAML description for rockchip,gpio-bank
  gpio: mxs: remove useless function
  dt-bindings: gpio: fairchild,74hc595: Convert to json-schema
  gpio: it87: remove unused code
  gpio: 104-dio-48e: Fix coding style issues
  gpio: mpc8xxx: Add ACPI support
  gpio: ich: Switch to be dependent on LPC_ICH
  gpio: sch: Drop MFD_CORE selection
  gpio: sch: depends on LPC_SCH
  gpiolib: acpi: Add quirk to ignore EC wakeups on Dell Venue 10 Pro 5055
  gpio: sch: Hook into ACPI GPE handler to catch GPIO edge events
  gpio: sch: Add edge event support
  gpio: aggregator: Replace custom get_arg() with a generic next_arg()
  lib/cmdline: Export next_arg() for being used in modules
  gpio: omap: Use device_get_match_data() helper
  gpio: Add Realtek Otto GPIO support
  dt-bindings: gpio: Binding for Realtek Otto GPIO
  docs: kernel-parameters: Add gpio_mockup_named_lines
  docs: kernel-parameters: Move gpio-mockup for alphabetic order
  lib: bitmap: provide devm_bitmap_alloc() and devm_bitmap_zalloc()
  ...
</content>
</entry>
<entry>
<title>gpio: guard gpiochip_irqchip_add_domain() with GPIOLIB_IRQCHIP</title>
<updated>2021-03-29T10:20:07Z</updated>
<author>
<name>Álvaro Fernández Rojas</name>
<email>noltari@gmail.com</email>
</author>
<published>2021-03-24T08:19:02Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=9c7d24693d864f90b27aad5d15fbfe226c02898b'/>
<id>urn:sha1:9c7d24693d864f90b27aad5d15fbfe226c02898b</id>
<content type='text'>
The current code doesn't check if GPIOLIB_IRQCHIP is enabled, which results in
a compilation error when trying to build gpio-regmap if CONFIG_GPIOLIB_IRQCHIP
isn't enabled.

Fixes: 6a45b0e2589f ("gpiolib: Introduce gpiochip_irqchip_add_domain()")
Suggested-by: Michael Walle &lt;michael@walle.cc&gt;
Signed-off-by: Álvaro Fernández Rojas &lt;noltari@gmail.com&gt;
Reviewed-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Reviewed-by: Michael Walle &lt;michael@walle.cc&gt;
Acked-by: Bartosz Golaszewski &lt;bgolaszewski@baylibre.com&gt;
Link: https://lore.kernel.org/r/20210324081923.20379-2-noltari@gmail.com
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
</content>
</entry>
<entry>
<title>gpiolib: some edits of kernel docs for clarity</title>
<updated>2021-03-26T13:56:19Z</updated>
<author>
<name>Randy Dunlap</name>
<email>rdunlap@infradead.org</email>
</author>
<published>2021-03-23T22:19:05Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=2d93018fe67d42c44d65a898da2a6a5a0209b9ee'/>
<id>urn:sha1:2d93018fe67d42c44d65a898da2a6a5a0209b9ee</id>
<content type='text'>
Fix a few typos and some punctuation. Also, change CONFIG_OF to
CONFIG_OF_GPIO in one comment.

Signed-off-by: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Cc: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Cc: Bartosz Golaszewski &lt;bgolaszewski@baylibre.com&gt;
Cc: linux-gpio@vger.kernel.org
Reviewed-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
[Bartosz: tweaked the commit message]
Signed-off-by: Bartosz Golaszewski &lt;bgolaszewski@baylibre.com&gt;
</content>
</entry>
<entry>
<title>gpio: Retire the explicit gpio irqchip code</title>
<updated>2020-10-28T14:50:06Z</updated>
<author>
<name>Linus Walleij</name>
<email>linus.walleij@linaro.org</email>
</author>
<published>2020-10-19T13:40:46Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=f1f37abbe6fc2b1242f78157db76e48dbf9518ee'/>
<id>urn:sha1:f1f37abbe6fc2b1242f78157db76e48dbf9518ee</id>
<content type='text'>
Now that all gpiolib irqchip users have been over to use
the irqchip template, we can finally retire the old code
path and leave just one way in to the irqchip: set up the
template when registering the gpio_chip. For a while
we had two code paths for this which was a bit confusing.

This brings this work to a conclusion, there is now one
way of doing this.

Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Reviewed-by: Andy Shevchenko &lt;andy.shevchenko@gmail.com&gt;
Cc: Thierry Reding &lt;thierry.reding@gmail.com&gt;
Link: https://lore.kernel.org/r/20201019134046.65101-1-linus.walleij@linaro.org
</content>
</entry>
<entry>
<title>gpiolib: unexport devprop_gpiochip_set_names()</title>
<updated>2020-09-14T08:54:42Z</updated>
<author>
<name>Bartosz Golaszewski</name>
<email>bgolaszewski@baylibre.com</email>
</author>
<published>2020-09-09T08:54:26Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=32fc5aa2df12c7a95dbd1c2c9ee3eb8d7f920d9e'/>
<id>urn:sha1:32fc5aa2df12c7a95dbd1c2c9ee3eb8d7f920d9e</id>
<content type='text'>
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 &lt;bgolaszewski@baylibre.com&gt;
Reviewed-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Reviewed-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
</content>
</entry>
<entry>
<title>gpiolib: generalize devprop_gpiochip_set_names() for device properties</title>
<updated>2020-09-14T08:54:01Z</updated>
<author>
<name>Bartosz Golaszewski</name>
<email>bgolaszewski@baylibre.com</email>
</author>
<published>2020-09-09T08:54:25Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=7cba1a4d5e1628e099728d849918de50dab2e24e'/>
<id>urn:sha1:7cba1a4d5e1628e099728d849918de50dab2e24e</id>
<content type='text'>
devprop_gpiochip_set_names() is overly complicated with taking the
fwnode argument (which requires using dev_fwnode() &amp; 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 &lt;bgolaszewski@baylibre.com&gt;
Reviewed-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Reviewed-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
</content>
</entry>
<entry>
<title>gpio: don't use same lockdep class for all devm_gpiochip_add_data users</title>
<updated>2020-08-03T23:22:02Z</updated>
<author>
<name>Ahmad Fatoum</name>
<email>a.fatoum@pengutronix.de</email>
</author>
<published>2020-07-31T12:38:36Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=5f402bb17533113c21d61c2d4bc4ef4a6fa1c9a5'/>
<id>urn:sha1:5f402bb17533113c21d61c2d4bc4ef4a6fa1c9a5</id>
<content type='text'>
Commit 959bc7b22bd2 ("gpio: Automatically add lockdep keys") documents
in its commits message its intention to "create a unique class key for
each driver".

It does so by having gpiochip_add_data add in-place the definition of
two static lockdep classes for LOCKDEP use. That way, every caller of
the macro adds their gpiochip with unique lockdep classes.

There are many indirect callers of gpiochip_add_data, however, via
use of devm_gpiochip_add_data. devm_gpiochip_add_data has external
linkage and all its users will share the same lockdep classes, which
probably is not intended.

Fix this by replicating the gpio_chip_add_data statics-in-macro for
the devm_ version as well.

Fixes: 959bc7b22bd2 ("gpio: Automatically add lockdep keys")
Signed-off-by: Ahmad Fatoum &lt;a.fatoum@pengutronix.de&gt;
Reviewed-by: Andy Shevchenko &lt;andy.shevchenko@gmail.com&gt;
Reviewed-by: Bartosz Golaszewski &lt;bgolaszewski@baylibre.com&gt;
Link: https://lore.kernel.org/r/20200731123835.8003-1-a.fatoum@pengutronix.de
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
</content>
</entry>
</feed>
