GPIO core:
- remove more unused legacy interfaces (after converting the last remaining
users to better alternatives)
- update kerneldocs
- improve error handling and log messages in GPIO ACPI code
- remove dead code (always true checks) from GPIOLIB
New drivers:
- add a driver for Intel Granite Rapids-D vGPIO
Driver improvements:
- use -ENOTSUPP consistently in gpio-regmap and gpio-pcie-idio-24
- provide an ID table for gpio-cros-ec to avoid a driver name fallback check
- add support for gpio-ranges for GPIO drivers supporting multiple GPIO banks
- switch to using dynamic GPIO base in gpio-brcmstb
- fix irq handling in gpio-npcm-sgpio
- switch to memory mapped IO accessors in gpio-sch
DT bindings:
- add support for gpio-ranges to gpio-brcmstb
- add support for a new model and the gpio-line-names property to gpio-mpfs
Documentation:
- replace leading tabs with spaces in code blocks
- fix typos
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEFp3rbAvDxGAT0sefEacuoBRx13IFAmZDFa4ACgkQEacuoBRx
13IJuA//cdR+Y1xaiORhVg9gMjmeQtgP7ve6QK4p/vuwAuZJMxboc4ATPY4cBlvp
VoMFQD8FgjbxcKRLjugS0wB/5isELzo5C+q699YKY/0R07WMBiTIt6FgS4JJ1j57
RoAlLrZ7gxmJQyUWuk2dvvQ55MnCL4fzVCzCrQB+foWsZluyeQMnndFU7z+P96bK
ckvNrfFlZjaTwRBVf9MVpcNUxuk+pFKMKfXCgNCvmhToOaOM3sKkFwMMZCOVRLpJ
oCcAz6rbj+fn2x3Id2FS2R5f5GoZx31dalLnbJCY4OLgDNhjx1A7sONq+hplfO24
LXxQgCP26myaxmCFsiKqYgYzh/1bnAeCaRjy+41+RWXy7LUil6c0yP1Z3pOlOK+h
j32+/LS9aflneoxjXyAAQLAvMulDbIvKeWHUakPXk6bS/AR6zyL16rwfF9U3K795
ZGAz37xuOCpAevGnRTpPz9eCWwnNFq5v8UMjvVmoMgtbJbIwP4J3cRzj6RCiBvrq
AvveulP+oXde3vFydAf1NbjaRxf53b8vZp6DLFDqcU+76QCQwG55QqlhT4Nqm/Y4
KASQYM4vlH+96vnCMW+p2DmN92dkoadwk5pBvEaY7q7eEC2EdAMfujUZ1VdB9OZ+
FPZ6zAp6T2khVt4jzKFxbobV8xt3FznntEhbm4bo3Ugb2HRwD8g=
=mBWd
-----END PGP SIGNATURE-----
Merge tag 'gpio-updates-for-v6.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux
Pull gpio updates from Bartosz Golaszewski
"This was a quiet release cycle for the GPIO tree and so this
pull-request is relatively small.
We have one new driver, some minor improvements to the GPIO core code
and across several drivers, some DT and documentation updates but in
general nothing stands out or is controversial. All changes have spent
time in next with no reported issues (or ones that were quickly
fixed).
GPIO core:
- remove more unused legacy interfaces (after converting the last
remaining users to better alternatives)
- update kerneldocs
- improve error handling and log messages in GPIO ACPI code
- remove dead code (always true checks) from GPIOLIB
New drivers:
- add a driver for Intel Granite Rapids-D vGPIO
Driver improvements:
- use -ENOTSUPP consistently in gpio-regmap and gpio-pcie-idio-24
- provide an ID table for gpio-cros-ec to avoid a driver name
fallback check
- add support for gpio-ranges for GPIO drivers supporting multiple
GPIO banks
- switch to using dynamic GPIO base in gpio-brcmstb
- fix irq handling in gpio-npcm-sgpio
- switch to memory mapped IO accessors in gpio-sch
DT bindings:
- add support for gpio-ranges to gpio-brcmstb
- add support for a new model and the gpio-line-names property to
gpio-mpfs
Documentation:
- replace leading tabs with spaces in code blocks
- fix typos"
* tag 'gpio-updates-for-v6.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: (30 commits)
gpio: nuvoton: Fix sgpio irq handle error
gpiolib: Discourage to use formatting strings in line names
gpio: brcmstb: add support for gpio-ranges
gpio: of: support gpio-ranges for multiple gpiochip devices
dt-bindings: gpio: brcmstb: add gpio-ranges
gpio: Add Intel Granite Rapids-D vGPIO driver
gpio: brcmstb: Use dynamic GPIO base numbers
gpiolib: acpi: Set label for IRQ only lines
gpiolib: acpi: Add fwnode name to the GPIO interrupt label
gpiolib: Get rid of never false gpio_is_valid() calls
gpiolib: acpi: Pass con_id instead of property into acpi_dev_gpio_irq_get_by()
gpiolib: acpi: Move acpi_can_fallback_to_crs() out of __acpi_find_gpio()
gpiolib: acpi: Simplify error handling in __acpi_find_gpio()
gpiolib: acpi: Extract __acpi_find_gpio() helper
gpio: sch: Utilise temporary variable for struct device
gpio: sch: Switch to memory mapped IO accessors
gpio: regmap: Use -ENOTSUPP consistently
gpio: pcie-idio-24: Use -ENOTSUPP consistently
Documentation: gpio: Replace leading TABs by spaces in code blocks
gpiolib: acpi: Check for errors first in acpi_find_gpio()
...
We used a per-descriptor SRCU struct in order to not impose a wait with
synchronize_srcu() for descriptor X on read-only operations of
descriptor Y. Now that we no longer call synchronize_srcu() on
descriptor label change but only when releasing descriptor resources, we
can use a single SRCU structure for all GPIO descriptors in a given chip.
Suggested-by: "Paul E. McKenney" <paulmck@kernel.org>
Acked-by: "Paul E. McKenney" <paulmck@kernel.org>
Link: https://lore.kernel.org/r/20240507172414.28513-1-brgl@bgdev.pl
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Commit 1f2bcb8c8c ("gpio: protect the descriptor label with SRCU")
caused a massive drop in performance of requesting GPIO lines due to the
call to synchronize_srcu() on each label change. Rework the code to not
wait until all read-only users are done with reading the label but
instead atomically replace the label pointer and schedule its release
after all read-only critical sections are done.
To that end wrap the descriptor label in a struct that also contains the
rcu_head struct required for deferring tasks using call_srcu() and stop
using kstrdup_const() as we're required to allocate memory anyway. Just
allocate enough for the label string and rcu_head in one go.
Reported-by: Neil Armstrong <neil.armstrong@linaro.org>
Closes: https://lore.kernel.org/linux-gpio/CAMRc=Mfig2oooDQYTqo23W3PXSdzhVO4p=G4+P8y1ppBOrkrJQ@mail.gmail.com/
Fixes: 1f2bcb8c8c ("gpio: protect the descriptor label with SRCU")
Suggested-by: "Paul E. McKenney" <paulmck@kernel.org>
Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD
Acked-by: "Paul E. McKenney" <paulmck@kernel.org>
Link: https://lore.kernel.org/r/20240507121346.16969-1-brgl@bgdev.pl
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
In the cases when gpio_is_valid() is called with unsigned parameter
the result is always true in the GPIO library code, hence the check
for false won't ever be true. Get rid of such calls.
While at it, move GPIO device base to be unsigned to clearly show
it won't ever be negative. This requires a new definition for the
maximum GPIO number in the system.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
We are going to remove legacy API from kernel, don't mention
it in the code that does not use it already for a while.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
When a gpiochip gets added by loading a module, then another driver may
be waiting for that gpiochip to load on the deferred-probe list.
If the deferred-probe for the consumer of gpiochip then triggers between
the gpiodev_add_to_list_unlocked() calls which makes gpio_device_find()
see the chip and the gpiochip_setup_dev() later then gpio_device_find()
does a kobject_get() on an uninitialized kobject since the kobject is
initialized by gpiochip_setup_dev() calling device_initialize():
arizona spi-10WM5102:00: cannot find GPIO chip arizona, deferring
arizona spi-10WM5102:00: cannot find GPIO chip arizona, deferring
------------[ cut here ]------------
kobject: 'gpiochip5' (00000000241466f2): is not initialized, yet kobject_get() is being called.
WARNING: CPU: 3 PID: 42 at lib/kobject.c:640 kobject_get+0x43/0x70
Call Trace:
kobject_get
gpio_device_find
gpiod_find_and_request
gpiod_get
snd_byt_wm5102_mc_probe
Not only is the device not initialized yet, but when the gpio-device is
added to the list things like the irqchip also have not been initialized
yet.
So gpio_device_find() should really ignore the gpio-device until
gpiochip_add_data_with_key() is fully done. Add a device_is_registered()
check to gpio_device_find() to ignore gpio-devices on the list which are
not yet fully initialized.
Fixes: aab5c6f200 ("gpio: set device type for GPIO chips")
Suggested-by: Bartosz Golaszewski <brgl@bgdev.pl>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
[Bartosz: fix a typo in commit message]
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
When gpio-ranges property was missed to be added in the gpio node,
using dev_err() to show an error message will helping to locate issues
easier.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
When consolidating GPIO lookups in ACPI code, the debug messaging
had been reworked that the user may see
[ 13.401147] (NULL device *): using ACPI '\_SB.LEDS.led-0' for '(null)' GPIO lookup
[ 13.401378] gpio gpiochip0: Persistence not supported for GPIO 40
[ 13.401402] gpio-40 (?): no flags found for (null)
instead of
[ 14.182962] gpio gpiochip0: Persistence not supported for GPIO 40
[ 14.182994] gpio-40 (?): no flags found for gpios
The '(null)' parts are less informative and likely scare the users.
Replace them by '(default)' which can point out to the default connection
IDs, such as 'gpios'.
While at it, amend other places where con_id is used in the messages.
Reported-by: Ferry Toth <ftoth@exalondelft.nl>
Fixes: 8eb1f71e7a ("gpiolib: consolidate GPIO lookups")
Suggested-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Tested-by: Ferry Toth <ftoth@exalondelft.nl>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
There is no need to repeat for-loop twice in the error path in
gpiochip_add_data_with_key(). Deduplicate it. While at it,
rename loop variable to be more specific and avoid ambguity.
It also properly unwinds the SRCU, i.e. in reversed order of allocating.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Hogs are added *after* ACPI so should be removed *before* in error path.
Fixes: a411e81e61 ("gpiolib: add hogs support for machine code")
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Make acpi_gpio_count() take firmware node as a parameter in order
to be aligned with other functions and decouple from unused device
pointer. The latter helps to create a common fwnode_gpio_count()
in the future.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Make of_gpio_get_count() take firmware node as a parameter in order
to be aligned with other functions and decouple from unused device
pointer. The latter helps to create a common fwnode_gpio_count()
in the future.
While at it, rename to be of_gpio_count() to be aligned with the others.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
After shuffling the code, error path wasn't updated correctly.
Fix it here.
Fixes: 2f4133bb5f ("gpiolib: No need to call gpiochip_remove_pin_ranges() twice")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
This devm API takes a consumer device as an argument to setup the devm
action, but throws it away when calling further into gpiolib. This leads
to odd debug messages like this:
(NULL device *): using DT '/gpio-keys/switch-pen-insert' for '(null)' GPIO lookup
Let's pass the consumer device down, by directly calling what
fwnode_gpiod_get_index() calls but pass the device used for devm. This
changes the message to look like this instead:
gpio-keys gpio-keys: using DT '/gpio-keys/switch-pen-insert' for '(null)' GPIO lookup
Note that callers of fwnode_gpiod_get_index() will still see the NULL
device pointer debug message, but there's not much we can do about that
because the API doesn't take a struct device.
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Fixes: 8eb1f71e7a ("gpiolib: consolidate GPIO lookups")
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
With SRCU we can now correctly handle the situation when a GPIO provider
is removed while having users still holding references to GPIO
descriptors. Remove all warnings emitted in this situation.
Suggested-by: Kent Gibson <warthog618@gmail.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Herve Codina <herve.codina@bootlin.com>
Similar to gpiochip_generic_request() and gpiochip_generic_free() the
gpiochip_generic_config() function needs to handle the case where there
are no pinctrl pins mapped to the GPIOs, usually through the gpio-ranges
device tree property.
Commit f34fd6ee1b ("gpio: dwapb: Use generic request, free and
set_config") set the .set_config callback to gpiochip_generic_config()
in the dwapb GPIO driver so the GPIO API can set pinctrl configuration
for the corresponding pins. Most boards using the dwapb driver do not
set the gpio-ranges device tree property though, and in this case
gpiochip_generic_config() would return -EPROPE_DEFER rather than the
previous -ENOTSUPP return value. This in turn makes
gpio_set_config_with_argument_optional() fail and propagate the error to
any driver requesting GPIOs.
Fixes: 2956b5d94a ("pinctrl / gpio: Introduce .set_config() callback for GPIO chips")
Reported-by: Jisheng Zhang <jszhang@kernel.org>
Closes: https://lore.kernel.org/linux-gpio/ZdC_g3U4l0CJIWzh@xhacker/
Tested-by: Jisheng Zhang <jszhang@kernel.org>
Signed-off-by: Emil Renner Berthing <emil.renner.berthing@canonical.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
The opaque pointer "data" in each match function used by
gpio_device_find() is a pointer to const, thus the same argument passed
to gpio_device_find() can adjusted similarly.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
There are two legacy, deprecated functions - gpiod_to_chip() and
gpio_device_get_chip() - that still have users in tree. They return the
address of the SRCU-protected chip outside of the read-only critical
sections. They are inherently dangerous and the users should convert to
safer alternatives. Let's explicitly silence lockdep warnings by using
rcu_dereference_check(ptr, 1). While at it: reuse
gpio_device_get_chip() in gpiod_to_chip().
Fixes: d83cee3d2b ("gpio: protect the pointer to gpio_chip in gpio_device with SRCU")
Reported-by: kernel test robot <oliver.sang@intel.com>
Closes: https://lore.kernel.org/oe-lkp/202402122234.d85cca9b-lkp@intel.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Lockdep with CONFIG_PROVE_RCU enabled reports false positives about
suspicious rcu_dereference() usage. Let's silence it by using
srcu_dereference() which is the correct helper with SRCU.
Fixes: d83cee3d2b ("gpio: protect the pointer to gpio_chip in gpio_device with SRCU")
Reported-by: kernel test robot <oliver.sang@intel.com>
Closes: https://lore.kernel.org/oe-lkp/202402122234.d85cca9b-lkp@intel.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Acked-by: Paul E. McKenney <paulmck@kernel.org>
gpiod_hog() may be called without the gpio_device SRCU read lock taken
so we need to do it here as well. It's alright if someone else is
already holding the lock as SRCU read critical sections can be nested.
Fixes: d83cee3d2b ("gpio: protect the pointer to gpio_chip in gpio_device with SRCU")
Reported-by: kernel test robot <oliver.sang@intel.com>
Closes: https://lore.kernel.org/oe-lkp/202402122234.d85cca9b-lkp@intel.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Paul E. McKenney <paulmck@kernel.org>
In certain situations we may end up taking the GPIO descriptor SRCU read
lock in of_gpiochip_add() before the SRCU struct is initialized. Move
the initialization before the call to of_gpiochip_add().
Fixes: be711caa87 ("gpio: add SRCU infrastructure to struct gpio_desc")
Fixes: 1f2bcb8c8c ("gpio: protect the descriptor label with SRCU")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-lkp/202402122228.e607a080-lkp@intel.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
We still have some functions that return the address of the GPIO chip
associated with the GPIO device. This is dangerous and the users should
find a better solution. Let's add appropriate comments to the kernel
docs.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
With all accesses to gdev->chip being protected with SRCU, we can now
remove the RW-semaphore specific to the character device which
fulfilled the same role up to this point.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Ensure we cannot crash if the GPIO device gets unregistered (and the
chip pointer set to NULL) during any of the API calls.
To that end: wait for all users of gdev->chip to exit their read-only
SRCU critical sections in gpiochip_remove().
For brevity: add a guard class which can be instantiated at the top of
every function requiring read-only access to the chip pointer and use it
in all API calls taking a GPIO descriptor as argument. In places where
we only deal with the GPIO device - use regular guard() helpers and
rcu_dereference() for chip access. Do the same in API calls taking a
const pointer to gpio_desc.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Add the SRCU struct to GPIO device. It will be used to serialize access
to the GPIO chip pointer. Initialize and clean it up where applicable.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Duplicating the can_sleep value in GPIO device will allow us to not
needlessly dereference the chip pointer in several places and reduce the
number of SRCU read-only critical sections.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
We don't need to check the gdev pointer in struct gpio_desc - it's
always assigned and never cleared. It's also pointless to check
gdev->chip before we actually serialize access to it.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Checking desc->gdev->chip for NULL without holding it in place with some
serializing mechanism is pointless. Remove this check. Also don't check
desc->gdev for NULL as it can never happen. We'll be protecting
gdev->chip with SRCU soon but we will provide a dedicated, automatic
class for that.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
We don't need to dereference gdev->chip in gpiochip_setup_dev() as at
the time it's called, the label in the associated struct gpio_device is
already set.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
We now removed the gpio_lock spinlock and modified the places
previously protected by it to handle desc->flags access in a consistent
way. Let's improve other places that were previously unprotected by
reading the flags field of gpio_desc once and using the stored value for
logic consistency. If we need to modify the field, let's also write it
back once with a consistent value resulting from the function's logic.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
The "multi-function" gpio_lock is pretty much useless with how it's used
in GPIOLIB currently. Because many GPIO API calls can be called from all
contexts but may also call into sleeping driver callbacks, there are
many places with utterly broken workarounds like yielding the lock to
call a possibly sleeping function and then re-acquiring it again without
taking into account that the protected state may have changed.
It was also used to protect several unrelated things: like individual
descriptors AND the GPIO device list. We now serialize access to these
two with SRCU and so can finally remove the spinlock.
There is of course the question of consistency of lockless access to
GPIO descriptors. Because we only support exclusive access to GPIOs
(officially anyway, I'm looking at you broken
GPIOD_FLAGS_BIT_NONEXCLUSIVE bit...) and the API contract with providers
does not guarantee serialization, it's enough to ensure we cannot
accidentally dereference an invalid pointer and that the state we present
to both users and providers remains consistent. To achieve that: read the
flags field atomically except for a few special cases. Read their current
value before executing callback code and use this value for any subsequent
logic. Modifying the flags depends on the particular use-case and can
differ. For instance: when requesting a GPIO, we need to set the
REQUESTED bit immediately so that the next user trying to request the
same line sees -EBUSY.
While at it: the allocations that used GFP_ATOMIC until this point can
now switch to GFP_KERNEL.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
With the list of GPIO devices now protected with SRCU we can use
gpio_device_find() to traverse it from sysfs.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
In order to ensure that the label is not freed while it's being
accessed, let's protect it with SRCU and synchronize it everytime it's
changed.
Let's modify desc_set_label() to manage the memory used for the label as
it can only be freed once synchronize_srcu() returns.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Extend the GPIO descriptor with an SRCU structure in order to serialize
the access to the label. Initialize and clean it up where applicable.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
We will soon serialize access to the descriptor label using SRCU. The
write-side of the protection will require calling synchronize_srcu()
which must not be called from atomic context. We have two irq helpers:
gpiochip_lock_as_irq() and gpiochip_unlock_as_irq() that set the label
if the GPIO is not requested but is being used as interrupt. They are
called with a spinlock held from the interrupt subsystem.
They must not do it if we are to use SRCU so instead let's move the
special corner case to a dedicated getter.
Don't actually set the label to "interrupt" in the above case but rather
use the newly added gpiod_get_label() helper to hide the logic that
atomically checks the descriptor flags and returns the address of a
static "interrupt" string.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
We will soon serialize access to the descriptor label using SRCU. The
write-side of the protection will require calling synchronize_srcu()
which must not be called from atomic context. We have two irq helpers:
gpiochip_lock_as_irq() and gpiochip_unlock_as_irq() that set the label
if the GPIO is not requested but is being used as interrupt. They are
called with a spinlock held from the interrupt subsystem.
They must not do it if we are to use SRCU so instead let's move the
special corner case to a dedicated getter.
First: let's implement and use the getter where it's applicable.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
The device nodes representing GPIO hogs cannot be deleted without
unregistering the GPIO chip so there's no need to serialize their access.
However we must ensure that users can get the right address so write and
read it atomically.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
We're working towards removing the "multi-function" GPIO spinlock that's
implemented terribly wrong. We tried using an RW-semaphore to protect
the list of GPIO devices but it turned out that we still have old code
using legacy GPIO calls that need to translate the global GPIO number to
the address of the associated descriptor and - to that end - traverse
the list while holding the lock. If we change the spinlock to a sleeping
lock then we'll end up with "scheduling while atomic" bugs.
Let's allow lockless traversal of the list using SRCU and only use the
mutex when modyfing the list.
While at it: let's protect the period between when we start the lookup
and when we finally request the descriptor (increasing the reference
count of the GPIO device) with the SRCU read lock.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
The match function used in gpio_device_find() should not modify the
contents of passed opaque pointer, because such modification would not
be necessary for actual matching and it could lead to quite unreadable,
spaghetti code.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
[Bartosz: fix coding style in header]
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
-----BEGIN PGP SIGNATURE-----
iQFSBAABCAA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAmXJK4UeHHRvcnZhbGRz
QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiGHsYH/jKmzKXDRsBCcw/Q
HGUvFtpohWBOpN6efdf0nxilQisuyQrqKB9fnwvfcdE60VpqMJXFMdlFh/fonxPl
JMbpk9y5uw48IJZA43NwTxUrjZ4wyWzv4ZF6YWa+5WdTAJpPLEPhhnLxcHOKklMr
5Cm/7B/M7eB2BXBfc45b1pkKN22q9OXvjaKxZ+5wYmiMxS+GC8l8jiJ/WlHX78PR
eLgsa1v732f2D7YF75wVhaoYepR+QzA9wTKqhjMNCEaVc2PQhA2JRsBXEt84qEIa
FZigmf7LLc4ed9YA2XjRBZhAehe3cZVJZ1lasW37IATS921La2WfKuiysICJOtyT
bGjK8tk=
=Pt7W
-----END PGP SIGNATURE-----
Merge tag 'v6.8-rc4' into gpio/for-next
Linux 6.8-rc4
Pulling this for a bugfix upstream with which the gpio/for-next branch
conflicts.
It's useful to have the device type information for those sub-devices
that are actually GPIO chips registered with GPIOLIB. While at it: use
the device type struct to setup the release callback which is the
preferred way to use the device API.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Since commit 48e1b4d369 ("gpiolib: remove the GPIO device from the list
when it's unregistered") we remove the GPIO device entry from the global
list (used to order devices by their GPIO ranges) when unregistering the
chip, not when releasing the device. It will not happen when the last
reference is put anymore. This means, we need to remove it in error path
in gpiochip_add_data_with_key() unconditionally, without checking if the
device's .release() callback is set.
Fixes: 48e1b4d369 ("gpiolib: remove the GPIO device from the list when it's unregistered")
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Now that the driver core can properly handle constant struct bus_type,
move the gpio_bus_type variable to be a constant structure as well,
placing it into read-only memory which can not be modified at runtime.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ricardo B. Marliere <ricardo@marliere.net>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
There are no external users for the irq domain helpers so unexport them
and remove the prototypes from the driver header.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
This reverts commits 1979a28075 ("gpiolib: replace the GPIO device
mutex with a read-write semaphore") and 65a828bab1 ("gpiolib: use
a mutex to protect the list of GPIO devices").
Unfortunately the legacy GPIO API that's still used in older code has to
translate numbers from the global GPIO numberspace to descriptors. This
results in a GPIO device lookup in every call to legacy functions. Some
of those functions - like gpio_set/get_value() - can be called from
atomic context so taking a sleeping lock that is an RW semaphore results
in an error.
We'll probably have to protect this list with SRCU.
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Closes: https://lore.kernel.org/linux-wireless/f7b5ff1e-8f34-4d98-a7be-b826cb897dc8@moroto.mountain/
Fixes: 1979a28075 ("gpiolib: replace the GPIO device mutex with a read-write semaphore")
Fixes: 65a828bab1 ("gpiolib: use a mutex to protect the list of GPIO devices")
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
There are only two spots where we modify (add to or remove objects from)
the GPIO device list. Readers should be able to access it concurrently.
Replace the mutex with a read-write semaphore and adjust the locking
operations accordingly.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
If we wait until the GPIO device's .release() callback gets invoked
before we remove it from the global device list, then we risk that
someone will look it up using gpio_device_find() between where we
dropped the last reference and before .release() is done taking a
reference again to an object that's being released.
The device must be removed when it's being unregistered - just like how
we remove it from the GPIO bus.
Fixes: ff2b135922 ("gpio: make the gpiochip a real device")
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
