#
8a7a6103 |
|
21-Feb-2024 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Get rid of never false gpio_is_valid() calls 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>
|
#
1685f72a |
|
26-Mar-2024 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Do not mention legacy GPIOF_* in the code 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>
|
#
39c90497 |
|
25-Mar-2024 |
Peng Fan <peng.fan@nxp.com> |
gpiolib: use dev_err() when gpiod_configure_flags failed 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>
|
#
7765ffed |
|
07-May-2024 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpiolib: use a single SRCU struct for all GPIO descriptors 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>
|
#
a86d2769 |
|
07-May-2024 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpiolib: fix the speed of descriptor label setting with SRCU Commit 1f2bcb8c8ccd ("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: 1f2bcb8c8ccd ("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>
|
#
e8acd2d2 |
|
02-Apr-2024 |
Hans de Goede <hdegoede@redhat.com> |
gpiolib: Fix triggering "kobject: 'gpiochipX' is not initialized, yet" kobject_get() errors 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: aab5c6f20023 ("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>
|
#
5c887b65 |
|
25-Mar-2024 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Fix debug messaging in gpiod_find_and_request() 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: 8eb1f71e7acc ("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>
|
#
8ae438f5 |
|
04-Mar-2024 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Deduplicate cleanup for-loop in gpiochip_add_data_with_key() 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>
|
#
8122c7c6 |
|
29-Feb-2024 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpio: acpi: Make acpi_gpio_count() take firmware node as a parameter 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>
|
#
adcad536 |
|
29-Feb-2024 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpio: of: Make of_gpio_get_count() take firmware node as a parameter 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>
|
#
0d776cfd |
|
22-Feb-2024 |
Stephen Boyd <swboyd@chromium.org> |
gpiolib: Pass consumer device through to core in devm_fwnode_gpiod_get_index() 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: 8eb1f71e7acc ("gpiolib: consolidate GPIO lookups") Signed-off-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
#
5d60c1e6 |
|
21-Feb-2024 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpio: don't warn about removing GPIO chips with active users anymore 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>
|
#
24ba441d |
|
17-Feb-2024 |
Xiaolei Wang <xiaolei.wang@windriver.com> |
gpio: fix memory leak in gpiod_request_commit() Since commit 1f2bcb8c8ccd ("gpio: protect the descriptor label with SRCU"), desc_set_label() already allocates memory for the label, so there is no need to allocate it again. If we do, we leak it. unreferenced object 0xffff0000c3e4d0c0 (size 32): comm "kworker/u16:4", pid 60, jiffies 4294894555 hex dump (first 32 bytes): 72 65 67 75 6c 61 74 6f 72 2d 63 61 6e 32 2d 73 regulator-can2-s 74 62 79 00 00 00 ff ff ff ff ff ff eb db ff ff tby............. backtrace (crc 2c3a0350): [<00000000e93c5cf4>] kmemleak_alloc+0x34/0x40 [<0000000097a2657f>] __kmalloc_node_track_caller+0x2c4/0x524 [<000000000dd1c057>] kstrdup+0x4c/0x98 [<00000000b513a96a>] kstrdup_const+0x34/0x40 [<000000008a7f0feb>] gpiod_request_commit+0xdc/0x358 [<00000000fc71ad64>] gpiod_request+0xd8/0x204 [<00000000fa24b091>] gpiod_find_and_request+0x170/0x780 [<0000000086ecf92d>] gpiod_get_index+0x70/0xe0 [<000000004aef97f9>] gpiod_get_optional+0x18/0x30 [<00000000312f1b25>] reg_fixed_voltage_probe+0x58c/0xad8 [<00000000e6f47635>] platform_probe+0xc4/0x198 [<00000000cf78fbdb>] really_probe+0x204/0x5a8 [<00000000e28d05ec>] __driver_probe_device+0x158/0x2c4 [<00000000e4fe452b>] driver_probe_device+0x60/0x18c [<00000000479fcf5d>] __device_attach_driver+0x168/0x208 [<000000007d389f38>] bus_for_each_drv+0x104/0x190 Fixes: 1f2bcb8c8ccd ("gpio: protect the descriptor label with SRCU") Signed-off-by: Xiaolei Wang <xiaolei.wang@windriver.com> [Bartosz: tweaked the commit message] Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
#
4a92857d |
|
16-Feb-2024 |
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> |
gpio: constify opaque pointer "data" in gpio_device_find() 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>
|
#
0d7fa0ed |
|
14-Feb-2024 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpio: don't let lockdep complain about inherently dangerous RCU usage 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: d83cee3d2bb1 ("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>
|
#
d82b9e08 |
|
14-Feb-2024 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpio: use srcu_dereference() with SRCU-protected pointers 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: d83cee3d2bb1 ("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>
|
#
815a1b5a |
|
14-Feb-2024 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpio: take the SRCU read lock in gpiod_hog() 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: d83cee3d2bb1 ("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>
|
#
ba5c5eff |
|
12-Feb-2024 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpio: initialize descriptor SRCU structure before adding OF-based chips 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: be711caa87c5 ("gpio: add SRCU infrastructure to struct gpio_desc") Fixes: 1f2bcb8c8ccd ("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>
|
#
5e628444 |
|
24-Jan-2024 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpio: mark unsafe gpio_chip manipulators as deprecated 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>
|
#
f067372c |
|
24-Jan-2024 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpio: remove the RW semaphore from the GPIO device 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>
|
#
d83cee3d |
|
22-Jan-2024 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpio: protect the pointer to gpio_chip in gpio_device with SRCU 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>
|
#
47d8b4c1 |
|
05-Jan-2024 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpio: add SRCU infrastructure to struct gpio_device 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>
|
#
8a5b477b |
|
27-Jan-2024 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpio: add the can_sleep flag to struct gpio_device 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>
|
#
c5cf334d |
|
25-Jan-2024 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpio: remove unnecessary checks from gpiod_to_chip() 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>
|
#
6c82e737 |
|
24-Jan-2024 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpio: reduce the functionality of validate_desc() 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>
|
#
7fe595b3 |
|
31-Jan-2024 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpio: don't dereference gdev->chip in gpiochip_setup_dev() 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>
|
#
b6f87adb |
|
23-Jan-2024 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpio: remove unneeded code from gpio_device_get_desc() The GPIO chip pointer is unused. Let's remove 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>
|
#
2559f2e0 |
|
23-Jan-2024 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpio: reinforce desc->flags handling 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>
|
#
35b54533 |
|
12-Jan-2024 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpio: remove gpio_lock 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>
|
#
2a9101e8 |
|
24-Jan-2024 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpio: sysfs: use gpio_device_find() to iterate over existing devices 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>
|
#
1f2bcb8c |
|
05-Jan-2024 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpio: protect the descriptor label with SRCU 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>
|
#
be711caa |
|
05-Jan-2024 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpio: add SRCU infrastructure to struct gpio_desc 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>
|
#
ccfb6ff4 |
|
29-Jan-2024 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpio: don't set label from irq helpers 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>
|
#
d23dc4a9 |
|
29-Jan-2024 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpio: provide and use gpiod_get_label() 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>
|
#
8ce6fd81 |
|
05-Jan-2024 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpio: of: assign and read the hog pointer atomically 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>
|
#
e348544f |
|
19-Jan-2024 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpio: protect the list of GPIO devices with SRCU 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>
|
#
faf6efd2 |
|
08-Feb-2024 |
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> |
gpio: constify opaque pointer in gpio_device_find() match function 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>
|
#
aab5c6f2 |
|
05-Feb-2024 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpio: set device type for GPIO chips 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>
|
#
a875746f |
|
04-Feb-2024 |
Ricardo B. Marliere <ricardo@marliere.net> |
gpio: gpiolib: make gpio_bus_type const 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>
|
#
88b70496 |
|
24-Jan-2024 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpio: unexport GPIO irq domain functions only used internally 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>
|
#
ec5c54a9 |
|
29-Feb-2024 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpio: fix resource unwinding order in error path Hogs are added *after* ACPI so should be removed *before* in error path. Fixes: a411e81e61df ("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>
|
#
e4aec4da |
|
21-Feb-2024 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Fix the error path order in gpiochip_add_data_with_key() After shuffling the code, error path wasn't updated correctly. Fix it here. Fixes: 2f4133bb5f14 ("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>
|
#
ae366ba8 |
|
19-Feb-2024 |
Emil Renner Berthing <emil.renner.berthing@canonical.com> |
gpiolib: Handle no pin_ranges in gpiochip_generic_config() 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 f34fd6ee1be8 ("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: 2956b5d94a76 ("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>
|
#
2526dffc |
|
05-Feb-2024 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpio: remove GPIO device from the list unconditionally in error path Since commit 48e1b4d369cf ("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: 48e1b4d369cf ("gpiolib: remove the GPIO device from the list when it's unregistered") Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
#
efb8235b |
|
14-Jan-2024 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpiolib: revert the attempt to protect the GPIO device list with an rwsem This reverts commits 1979a2807547 ("gpiolib: replace the GPIO device mutex with a read-write semaphore") and 65a828bab158 ("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: 1979a2807547 ("gpiolib: replace the GPIO device mutex with a read-write semaphore") Fixes: 65a828bab158 ("gpiolib: use a mutex to protect the list of GPIO devices") Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
#
1979a280 |
|
02-Jan-2024 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpiolib: replace the GPIO device mutex with a read-write semaphore 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>
|
#
48e1b4d3 |
|
02-Jan-2024 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpiolib: remove the GPIO device from the list when it's unregistered 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: ff2b13592299 ("gpio: make the gpiochip a real device") Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
|
#
0338f6a6 |
|
21-Dec-2023 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpiolib: drop tabs from local variable declarations Older code has an annoying habit of putting tabs between the type and the name of the variable. This doesn't really add to readability and newer code doesn't do it so make the entire file consistent. While at it: convert 'unsigned' to 'unsigned int'. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
#
5d5dfc50 |
|
19-Dec-2023 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpiolib: remove extra_checks extra_checks is only used in a few places. It also depends on a non-standard DEBUG define one needs to add to the source file. The overhead of removing it should be minimal (we already use pure might_sleep() in the code anyway) so drop it. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
|
#
d8543cba |
|
18-Dec-2023 |
Kent Gibson <warthog618@gmail.com> |
gpiolib: remove debounce_period_us from struct gpio_desc cdev is the only user of the debounce_period_us field in struct gpio_desc, and it no longer uses it, so remove it. Signed-off-by: Kent Gibson <warthog618@gmail.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
#
65a828ba |
|
15-Dec-2023 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpiolib: use a mutex to protect the list of GPIO devices The global list of GPIO devices is never modified or accessed from atomic context so it's fine to protect it using a mutex. Add a new global lock dedicated to the gpio_devices list and use it whenever accessing or modifying it. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
#
f95fd4ac |
|
15-Dec-2023 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpiolib: rename static functions that are called with the lock taken Rename two functions that read or modify the global GPIO device list but don't take the lock themselves (and need to be called with it already acquired). Use the _unlocked() suffix which seems to be used quite consistently across the kernel despite there also existing the _locked() suffix for the same purpose. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
#
0a10d107 |
|
12-Dec-2023 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpiolib: allocate memory atomically with a spinlock held We will eventually switch to protecting the GPIO descriptors with a mutex but until then, we need to allocate memory for the label copy atomically while we're holding the global spinlock. Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/linux-gpio/62588146-eed6-42f7-ba26-160226b109fe@moroto.mountain/T/#u Fixes: f8d05e276b45 ("gpiolib: remove gpiochip_is_requested()") Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
|
#
f8d05e27 |
|
04-Dec-2023 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpiolib: remove gpiochip_is_requested() We have no external users of gpiochip_is_requested(). Let's remove it and replace its internal calls with direct testing of the REQUESTED flag. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org>
|
#
ee25fba7 |
|
04-Dec-2023 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpiolib: provide gpiochip_dup_line_label() gpiochip_is_requested() not only has a misleading name but it returns a pointer to a string that is freed when the descriptor is released. Provide a new helper meant to replace it, which returns a copy of the label string instead. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org>
|
#
d1f77282 |
|
15-Nov-2023 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpiolib: provide gpio_device_get_label() Provide a getter for the GPIO device label string so that users don't have to dereference struct gpio_chip directly. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
#
acf2981b |
|
02-Oct-2023 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
treewide: rename pinctrl_gpio_set_config_new() Now that pinctrl_gpio_set_config() is no longer used, let's drop the '_new' suffix from its improved variant. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org>
|
#
4fccb263 |
|
03-Oct-2023 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
treewide: rename pinctrl_gpio_free_new() Now that pinctrl_gpio_free()() is no longer used, let's drop the '_new' suffix from its improved variant. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org>
|
#
acb38be6 |
|
03-Oct-2023 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
treewide: rename pinctrl_gpio_request_new() Now that pinctrl_gpio_request() is no longer used, let's drop the '_new' suffix from its improved variant. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org>
|
#
e3d3ab29 |
|
03-Oct-2023 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpiolib: generic: use new pinctrl GPIO helpers Replace the pinctrl helpers taking the global GPIO number as argument with the improved variants that instead take a pointer to the GPIO chip and the controller-relative offset. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by: Linus Walleij <linus.walleij@linaro.org>
|
#
2654521d |
|
05-Sep-2023 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpiolib: remove gpiochip_find() With all users of gpiochip_find() converted to using gpio_device_find(), we can now remove this function from the kernel. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
|
#
8c85a102 |
|
05-Sep-2023 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpiolib: provide gpio_device_get_base() Let's start adding getters for the opaque struct gpio_device. Start with a function allowing to retrieve the base GPIO number. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org>
|
#
370232d0 |
|
11-Oct-2023 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpiolib: provide gpiod_to_gpio_device() Accessing struct gpio_chip backing a GPIO device is only allowed for the actual providers of that chip. Similarly to how we introduced gpio_device_find() in order to replace the abused gpiochip_find(), let's introduce a counterpart to gpiod_to_chip() that returns a reference to the GPIO device owning the descriptor. This is done in order to later remove gpiod_to_chip() entirely. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Peter Rosin <peda@axentia.se> Acked-by: Linus Walleij <linus.walleij@linaro.org>
|
#
1559d149 |
|
11-Oct-2023 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpiolib: provide gpio_device_to_device() There are users in the kernel who need to retrieve the address of the struct device backing the GPIO device. Currently they needlessly poke in the internals of GPIOLIB. Add a dedicated getter function. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Peter Rosin <peda@axentia.se> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by: Linus Walleij <linus.walleij@linaro.org>
|
#
668706b1 |
|
11-Oct-2023 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: provide gpio_device_find_by_fwnode() One of the ways of looking up GPIO devices is using their fwnode. Provide a helper for that to avoid every user implementing their own matching function. Reviewed-by: Dipen Patel <dipenp@nvidia.com> Tested-by: Dipen Patel <dipenp@nvidia.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20231010151709.4104747-2-andriy.shevchenko@linux.intel.com Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
#
db546960 |
|
27-Sep-2023 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpiolib: replace find_chip_by_name() with gpio_device_find_by_label() Remove all remaining uses of find_chip_by_name() (and subsequently: gpiochip_find()) from gpiolib.c and use the new gpio_device_find_by_label() instead. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
|
#
9b418780 |
|
27-Sep-2023 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpiolib: reluctantly provide gpio_device_get_chip() The process of converting all unauthorized users of struct gpio_chip to using dedicated struct gpio_device function will be long so in the meantime we must provide a way of retrieving the pointer to struct gpio_chip from a GPIO device. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
|
#
93548f8b |
|
27-Sep-2023 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpiolib: provide gpio_device_get_desc() Getting the GPIO descriptor directly from the gpio_chip struct is dangerous as we don't take the reference to the underlying GPIO device. In order to start working towards removing gpiochip_get_desc(), let's provide a safer variant that works with an existing reference to struct gpio_device. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
|
#
d62fcd9f |
|
27-Sep-2023 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpiolib: provide gpio_device_find_by_label() By far the most common way of looking up GPIO devices is using their label. Provide a helpers for that to avoid every user implementing their own matching function. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
|
#
cfe102f6 |
|
27-Sep-2023 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpiolib: provide gpio_device_find() gpiochip_find() is wrong and its kernel doc is misleading as the function doesn't return a reference to the gpio_chip but just a raw pointer. The chip itself is not guaranteed to stay alive, in fact it can be deleted at any point. Also: other than GPIO drivers themselves, nobody else has any business accessing gpio_chip structs. Provide a new gpio_device_find() function that returns a real reference to the opaque gpio_device structure that is guaranteed to stay alive for as long as there are active users of it. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
|
#
36aa129f |
|
27-Sep-2023 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpiolib: make gpio_device_get() and gpio_device_put() public In order to start migrating away from accessing struct gpio_chip by users other than their owners, let's first make the reference management functions for the opaque struct gpio_device public in the driver.h header. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
#
c31071ea |
|
20-Sep-2023 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpiolib: extend the critical sections of lookup tables There are two places in the code where we retrieve a lookup table using gpiod_find_lookup_table() (which protects the table list with the lookup table lock) and then use it after the lock is released. We need to keep the lookup table mutex locked the entire time we're using the tables. Remove the locking from gpiod_find_lookup_table() and use guards to protect the code actually using the table objects. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
|
#
f42dafe3 |
|
03-Sep-2023 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpiolib: unexport gpiod_set_transitory() There are no and never have been any users of gpiod_set_transitory() outside the core GPIOLIB code. Make it private. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
|
#
9ce4ed5b |
|
21-Aug-2023 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpiolib: provide and use gpiod_line_state_notify() Wrap the calls to blocking_notifier_call_chain() for the line state notifier with a helper that allows us to use fewer lines of code and simpler syntax. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
#
a067419b |
|
17-Aug-2023 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpiolib: add a second blocking notifier to struct gpio_device Add a new blocking notifier to struct gpio_device and use it to notify subscribers about the GPIO device being unregistered from the device model. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Kent Gibson <warthog618@gmail.com>
|
#
17a7ca35 |
|
17-Aug-2023 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpiolib: rename the gpio_device notifier Change the generic "notifier" name to "line_state_notifier" in order to reflect its purpose in preparation for adding a second notifier which will be used to notify wait queues about device unregistering. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Kent Gibson <warthog618@gmail.com>
|
#
55b2395e |
|
11-Jul-2023 |
Asmaa Mnebhi <asmaa@nvidia.com> |
gpio: mmio: handle "ngpios" properly in bgpio_init() bgpio_init() uses "sz" argument to populate ngpio, which is not accurate. Instead, read the "ngpios" property from the DT and if it doesn't exist, use the "sz" argument. With this change, drivers no longer need to overwrite the ngpio variable after calling bgpio_init(). If the "ngpios" property is specified, bgpio_bits is calculated as the round up value of ngpio. At the moment, the only requirement specified is that the round up value must be a multiple of 8 but it should also be a power of 2 because we provide accessors based on the bank size in bgpio_setup_accessors(). Signed-off-by: Asmaa Mnebhi <asmaa@nvidia.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
#
eec349db |
|
21-Jun-2023 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Replace open coded gpiochip_irqchip_add_allocated_domain() Replace open coded variant of gpiochip_irqchip_add_allocated_domain() in gpiochip_add_irqchip(). 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>
|
#
081bfdb3 |
|
21-Jun-2023 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Split out gpiochip_irqchip_add_allocated_domain() helper The gpiochip_irqchip_add_allocated_domain() can be used in another place in the code. 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>
|
#
39f3ad73 |
|
21-Jun-2023 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Do not assign error pointer to the GPIO IRQ chip domain Check domain for being an error pointer before assigning it to the GPIO IRQ chip domain. 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>
|
#
1efc43de |
|
21-Jun-2023 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Factor out gpiochip_simple_create_domain() As a preparatory patch and for the sake of consistency, factor out gpiochip_simple_create_domain(). 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>
|
#
b683b487 |
|
21-Jun-2023 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Make gpiochip_hierarchy_add_domain() return domain As a preparatory patch and for the sake of consistency, make gpiochip_hierarchy_add_domain() return IRQ domain. While at it, rename it to gpiochip_hierarchy_create_domain() to show the change. 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>
|
#
daecca4b |
|
03-Jul-2023 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Do not alter GPIO chip fwnode member Ideally we should not touch data in the given GPIO chip structure. Let's become closer to it by avoiding altering fwnode member. The GPIO library must use fwnode from GPIO device and the drivers might use one from GPIO chip in case they initialized it. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Benjamin Tissoires <bentiss@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
#
3386fb86 |
|
11-Aug-2023 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpiolib: fix reference leaks when removing GPIO chips still in use After we remove a GPIO chip that still has some requested descriptors, gpiod_free_commit() will fail and we will never put the references to the GPIO device and the owning module in gpiod_free(). Rework this function to: - not warn on desc == NULL as this is a use-case on which most free functions silently return - put the references to desc->gdev and desc->gdev->owner unconditionally so that the release callback actually gets called when the remaining references are dropped by external GPIO users Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
|
#
a48b3f7b |
|
16-Jun-2023 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Drop unused domain_ops memeber of GPIO IRQ chip It seems there is no driver that requires custom IRQ chip domain options. Drop the member and respective code. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
#
ff7a1790 |
|
19-Jun-2023 |
Michael Walle <mwalle@kernel.org> |
gpiolib: Fix irq_domain resource tracking for gpiochip_irqchip_add_domain() Up until commit 6a45b0e2589f ("gpiolib: Introduce gpiochip_irqchip_add_domain()") all irq_domains were allocated by gpiolib itself and thus gpiolib also takes care of freeing it. With gpiochip_irqchip_add_domain() a user of gpiolib can associate an irq_domain with the gpio_chip. This irq_domain is not managed by gpiolib and therefore must not be freed by gpiolib. Fixes: 6a45b0e2589f ("gpiolib: Introduce gpiochip_irqchip_add_domain()") Reported-by: Jiawen Wu <jiawenwu@trustnetic.com> Signed-off-by: Michael Walle <mwalle@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
#
8c00914e |
|
07-Jun-2023 |
Jiawen Wu <jiawenwu@trustnetic.com> |
gpiolib: Fix GPIO chip IRQ initialization restriction In case of gpio-regmap, IRQ chip is added by regmap-irq and associated with GPIO chip by gpiochip_irqchip_add_domain(). The initialization flag was not added in gpiochip_irqchip_add_domain(), causing gpiochip_to_irq() to return -EPROBE_DEFER. Fixes: 5467801f1fcb ("gpio: Restrict usage of GPIO chip irq members before initialization") Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
#
b0ce9ce4 |
|
05-Jun-2023 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Do not unexport GPIO on freeing Since the legacy exporting is gone with 2f804aca4832 ("gpiolib: Kill unused GPIOF_EXPORT and Co") there is no need to unexport GPIO on freeing. Remove that call. Note, the other users of this functionality do that explicitly, except one SH and one OMAP boardfile which don't free GPIO anyways, so it is safe to drop the call. 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>
|
#
be6736cc |
|
05-Jun-2023 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpiolib: demote the hogging log messages to debug Drivers should be silent when they work correctly. There's no reason to emit info messages when GPIO lines are hogged. Demote the message to debug. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Suggested-by: Kent Gibson <warthog618@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
#
1a55fc40 |
|
27-May-2023 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Unify allocation and initialization of GPIO valid mask Now that the of_gpiochip_add() doesn't use valid mask, we may unify GPIO valid mask allocation and initialization. With this it makes a symmetry to the similar which we done for IRQ chip. 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>
|
#
05a854c5 |
|
27-May-2023 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Consolidate the allocated mask freeing APIs There is a common API to allocate a mask, but more than one duplicative counterparts. Consolidate the latter into a single common API beneath. 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>
|
#
7dd3d9bd |
|
04-May-2023 |
Andreas Kemnade <andreas@kemnade.info> |
gpiolib: fix allocation of mixed dynamic/static GPIOs If static allocation and dynamic allocation GPIOs are present, dynamic allocation pollutes the numberspace for static allocation, causing static allocation to fail. Enforce dynamic allocation above GPIO_DYNAMIC_BASE. Seen on a GTA04 when omap-gpio (static) and twl-gpio (dynamic) raced: [some successful registrations of omap_gpio instances] [ 2.553833] twl4030_gpio twl4030-gpio: gpio (irq 145) chaining IRQs 161..178 [ 2.561401] gpiochip_find_base: found new base at 160 [ 2.564392] gpio gpiochip5: (twl4030): added GPIO chardev (254:5) [ 2.564544] gpio gpiochip5: registered GPIOs 160 to 177 on twl4030 [...] [ 2.692169] omap-gpmc 6e000000.gpmc: GPMC revision 5.0 [ 2.697357] gpmc_mem_init: disabling cs 0 mapped at 0x0-0x1000000 [ 2.703643] gpiochip_find_base: found new base at 178 [ 2.704376] gpio gpiochip6: (omap-gpmc): added GPIO chardev (254:6) [ 2.704589] gpio gpiochip6: registered GPIOs 178 to 181 on omap-gpmc [...] [ 2.840393] gpio gpiochip7: Static allocation of GPIO base is deprecated, use dynamic allocation. [ 2.849365] gpio gpiochip7: (gpio-160-191): GPIO integer space overlap, cannot add chip [ 2.857513] gpiochip_add_data_with_key: GPIOs 160..191 (gpio-160-191) failed to register, -16 [ 2.866149] omap_gpio 48310000.gpio: error -EBUSY: Could not register gpio chip On that device it is fixed invasively by commit 92bf78b33b0b4 ("gpio: omap: use dynamic allocation of base") but let's also fix that for devices where there is still a mixture of static and dynamic allocation. Fixes: 7b61212f2a07 ("gpiolib: Get rid of ARCH_NR_GPIOS") Signed-off-by: Andreas Kemnade <andreas@kemnade.info> Reviewed-by: <christophe.leroy@csgroup.eu> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
#
8a4adcf6 |
|
11-Apr-2023 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: gpiolib: Simplify gpiochip_add_data_with_key() fwnode The code defaulting to the parents fwnode if no fwnode was assigned is unnecessarily convoluted, probably due to refactoring. Simplify it and make it more human-readable. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Anders Roxell <anders.roxell@linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
#
7b59bdbc |
|
21-Mar-2023 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Add gpiochip_set_data() helper There are too many 'data' parameters here and there. For the better maintenance keep access GPIO device data via getter and setter. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
#
8deb779d |
|
21-Mar-2023 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Move gpiochip_get_data() higher in the code Move gpiochip_get_data() higher in the code as a preparation for further refactoring. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> [Bartosz: tweak the commit message] Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
#
4ea0c977 |
|
21-Mar-2023 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Check array_info for NULL only once in gpiod_get_array() gpiod_get_array() has a long if-else-if branching where each of them tests for the same variable to be not NULL. Instead, check for NULL before even going to that flow. 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>
|
#
79736429 |
|
21-Mar-2023 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Replace open coded krealloc() gpiod_get_array() does a new allocation in some cases, followed by copying previously allocated placeholder for the descriptors. Replace that with krealloc(__GFP_ZERO), since it was kzalloc() originally. 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>
|
#
db4064cc |
|
09-Mar-2023 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Use IRQ hardware number getter instead of direct access IRQ framework provides special type and getter to transform the Linux IRQ to the hardware pin. Use that type and getter function instead of direct access. While at it, amend an indentation in a couple of places. 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>
|
#
c122f461 |
|
09-Mar-2023 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Remove duplicative check in gpiod_find_and_request() The gpiod_find_by_fwnode() already checks for NULL and returns correct error code in case fwnode is invalid. Drop the respective check and assignment in the gpiod_find_and_request(). 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>
|
#
7aa90f90 |
|
07-Mar-2023 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Move gpiodevice_*() to gpiodev namespace The functions that operates on the same device object would have the same namespace for better code understanding and maintenance. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
#
0c5ebb4c |
|
09-Mar-2023 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Get rid of devprop prefix in one function The devprop prefix in the devprop_gpiochip_set_names() adds confusion. Get rid of it. Note we have more than one function in the same module that handles one or more device properties. This change will unify the naming schema for all of them. 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>
|
#
c135f401 |
|
07-Mar-2023 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Get rid of gpio_bus_match() forward declaration There is nothing specific about gpio_bus_match(), so we may simply move it to the top of the file and get rid of forward declaration. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
#
67f64d15 |
|
07-Mar-2023 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Access device's fwnode via dev_fwnode() GPIO device's fwnode should be accessed via dev_fwnode(). Make sure that gpiochip_setup_dev() follows that. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
#
380c7ba3 |
|
08-Feb-2023 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Clean up headers There is a few things done: - include only the headers we are direct user of - when pointer is in use, provide a forward declaration - add missing headers - group generic headers and subsystem headers - sort each group alphabetically Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
#
38dfa56b |
|
06-Feb-2023 |
Saravana Kannan <saravanak@google.com> |
gpiolib: Clear the gpio_device's fwnode initialized flag before adding Registering an irqdomain sets the flag for the fwnode. But having the flag set when a device is added is interpreted by fw_devlink to mean the device has already been initialized and will never probe. This prevents fw_devlink from creating device links with the gpio_device as a supplier. So, clear the flag before adding the device. Signed-off-by: Saravana Kannan <saravanak@google.com> Acked-by: Bartosz Golaszewski <brgl@bgdev.pl> Tested-by: Colin Foster <colin.foster@in-advantage.com> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Douglas Anderson <dianders@chromium.org> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Luca Weiss <luca.weiss@fairphone.com> # qcom/sm7225-fairphone-fp4 Link: https://lore.kernel.org/r/20230207014207.1678715-5-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
79aabb1e |
|
28-Dec-2022 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: sort header inclusion alphabetically Sort header inclusion alphabetically. 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>
|
#
70d0fc42 |
|
28-Dec-2022 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Get rid of not used of_node member All new drivers should use fwnode and / or parent to provide the necessary information to the GPIO library. Cc: Thierry Reding <treding@nvidia.com> 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>
|
#
dc0989e3 |
|
28-Dec-2022 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Introduce gpio_device_get() and gpio_device_put() Introduce gpio_device_get() and gpio_device_put() helpers and convert existing users. 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>
|
#
908334ab |
|
13-Dec-2022 |
Johan Hovold <johan+linaro@kernel.org> |
gpiolib: use irq_domain_alloc_irqs() Use the irq_domain_alloc_irqs() wrapper instead of the full __irq_domain_alloc_irqs() interface, which was only intended for some legacy (x86) use cases. Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
#
c40aa80d |
|
13-Jan-2023 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Check "gpio-ranges" before calling ->add_pin_ranges() The ->add_pin_ranges() is supposed to be called for the backward compatiblity on Device Tree platforms or non-DT ones. Ensure that by checking presense of the "gpio-ranges" property. This allows to clean up a few existing drivers to avoid duplication of the check. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Link: https://lore.kernel.org/r/20230113215352.44272-2-andriy.shevchenko@linux.intel.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
ba2dc1cb |
|
29-Dec-2022 |
Hans de Goede <hdegoede@redhat.com> |
gpiolib: Fix using uninitialized lookup-flags on ACPI platforms Commit 8eb1f71e7acc ("gpiolib: consolidate GPIO lookups") refactors fwnode_get_named_gpiod() and gpiod_get_index() into a unified gpiod_find_and_request() helper. The old functions both initialized their local lookupflags variable to GPIO_LOOKUP_FLAGS_DEFAULT, but the new code leaves it uninitialized. This is a problem for at least ACPI platforms, where acpi_find_gpio() only does a bunch of *lookupflags |= GPIO_* statements and thus relies on the variable being initialized. The variable not being initialized leads to: 1. Potentially the wrong flags getting used 2. The check for conflicting lookup flags in gpiod_configure_flags(): "multiple pull-up, pull-down or pull-disable enabled, invalid config" sometimes triggering, making the GPIO unavailable Restore the initialization of lookupflags to GPIO_LOOKUP_FLAGS_DEFAULT to fix this. Fixes: 8eb1f71e7acc ("gpiolib: consolidate GPIO lookups") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
#
bdbbae24 |
|
05-Dec-2022 |
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> |
gpiolib: protect the GPIO device against being dropped while in use by user-space While any of the GPIO cdev syscalls is in progress, the kernel can call gpiochip_remove() (for instance, when a USB GPIO expander is disconnected) which will set gdev->chip to NULL after which any subsequent access will cause a crash. To avoid that: use an RW-semaphore in which the syscalls take it for reading (so that we don't needlessly prohibit the user-space from calling syscalls simultaneously) while gpiochip_remove() takes it for writing so that it can only happen once all syscalls return. Fixes: d7c51b47ac11 ("gpio: userspace ABI for reading/writing GPIO lines") Fixes: 3c0d9c635ae2 ("gpiolib: cdev: support GPIO_V2_GET_LINE_IOCTL and GPIO_V2_LINE_GET_VALUES_IOCTL") Fixes: aad955842d1c ("gpiolib: cdev: support GPIO_V2_GET_LINEINFO_IOCTL and GPIO_V2_GET_LINEINFO_WATCH_IOCTL") Fixes: a54756cb24ea ("gpiolib: cdev: support GPIO_V2_LINE_SET_CONFIG_IOCTL") Fixes: 7b8e00d98168 ("gpiolib: cdev: support GPIO_V2_LINE_SET_VALUES_IOCTL") Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> [Nick: fixed a build failure with CDEV_V1 disabled] Co-authored-by: Nick Hainke <vincent@systemli.org> Reviewed-by: Kent Gibson <warthog618@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
|
#
3b7c7478 |
|
28-Nov-2022 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Provide to_gpio_device() helper Provide to_gpio_device() helper which can be utilized in the existing and future code. While at it, make sure it becomes no-op at compilation time. 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>
|
#
4ef339bc |
|
16-Nov-2022 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Unify access to the device properties Some of the functions are using struct fwnode_handle, some struct device pointer. In the GPIO library the firmware node of the GPIO device is the same as GPIO node of the GPIO chip. Due to this fact we may use former to access properties everywhere in the code. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Brian Masney <bmasney@redhat.com> Tested-by: Marijn Suijten <marijn.suijten@somainline.org> [Bartosz: stick to the 80-char limit where it's not hurting readability] Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
#
24c94060 |
|
14-Nov-2022 |
Brian Masney <bmasney@redhat.com> |
gpiolib: ensure that fwnode is properly set Note that this is a RFC patch and not meant to be merged. I looked into a problem with linux-next-20221110 on the Qualcomm SA8540P automotive board (sc8280xp) where the UFS host controller would fail to probe due to repeated probe deferrals when trying to get reset-gpios via devm_gpiod_get_optional(). of_get_named_gpiod_flags() returns -EPROBE_DEFER, which is caused by of_gpiochip_match_node_and_xlate() returning 0 since the of_xlate function pointer is not set for the qcom,sc8280xp-tlmm pinctrl driver. The pinctrl driver doesn't define one, so of_gpiochip_add() should automatically setup of_gpio_simple_xlate() on it's behalf. This doesn't happen since the fwnode member on the struct gpiochip is set to null when of_gpiochip_add() is called. Let's work around this by ensuring that it's set if available. Note that this broke sometime within the last few weeks within linux-next and I haven't bisected this. I'm posting this in the hopes that someone may know offhand which patch(es) may have broken this. Signed-off-by: Brian Masney <bmasney@redhat.com> Tested-by: Marijn Suijten <marijn.suijten@somainline.org> Tested-by: Konrad Dybcio <konrad.dybcio@linaro.org> Tested-by: Steev Klimaszewski <steev@kali.org> #Lenovo Thinkpad X13s Tested-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
#
e7f9ff5d |
|
11-Nov-2022 |
Dmitry Torokhov <dmitry.torokhov@gmail.com> |
gpiolib: add support for software nodes Now that static device properties understand notion of child nodes and references, let's teach gpiolib to handle them: - GPIOs are represented as a references to software nodes representing gpiochip - references must have 2 arguments - GPIO number within the chip and GPIO flags (GPIO_ACTIVE_LOW/GPIO_ACTIVE_HIGH, etc) - a new PROPERTY_ENTRY_GPIO() macro is supplied to ensure the above - name of the software node representing gpiochip must match label of the gpiochip, as we use it to locate gpiochip structure at runtime The following illustrates use of software nodes to describe a "System" button that is currently specified via use of gpio_keys_platform_data in arch/mips/alchemy/board-mtx1.c. It follows bindings specified in Documentation/devicetree/bindings/input/gpio-keys.yaml. static const struct software_node mxt1_gpiochip2_node = { .name = "alchemy-gpio2", }; static const struct property_entry mtx1_gpio_button_props[] = { PROPERTY_ENTRY_U32("linux,code", BTN_0), PROPERTY_ENTRY_STRING("label", "System button"), PROPERTY_ENTRY_GPIO("gpios", &mxt1_gpiochip2_node, 7, GPIO_ACTIVE_LOW), { } }; Similarly, arch/arm/mach-tegra/board-paz00.c can be converted to: static const struct software_node tegra_gpiochip_node = { .name = "tegra-gpio", }; static struct property_entry wifi_rfkill_prop[] __initdata = { PROPERTY_ENTRY_STRING("name", "wifi_rfkill"), PROPERTY_ENTRY_STRING("type", "wlan"), PROPERTY_ENTRY_GPIO("reset-gpios", &tegra_gpiochip_node, 25, GPIO_ACTIVE_HIGH); PROPERTY_ENTRY_GPIO("shutdown-gpios", &tegra_gpiochip_node, 85, GPIO_ACTIVE_HIGH); { }, }; static struct platform_device wifi_rfkill_device = { .name = "rfkill_gpio", .id = -1, }; ... software_node_register(&tegra_gpiochip_node); device_create_managed_software_node(&wifi_rfkill_device.dev, wifi_rfkill_prop, NULL); Acked-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
#
8eb1f71e |
|
11-Nov-2022 |
Dmitry Torokhov <dmitry.torokhov@gmail.com> |
gpiolib: consolidate GPIO lookups Ensure that all paths to obtain/look up GPIOD from generic consumer-visible APIs go through the new gpiod_find_and_request() helper, so that we can easily extend it with support for new firmware mechanisms. The only exception is OF-specific [devm_]gpiod_get_from_of_node() API that is still being used by a couple of drivers and will be removed as soon as patches converting them to use generic fwnode/device APIs are accepted. Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
#
b7452d67 |
|
15-Nov-2022 |
Dmitry Torokhov <dmitry.torokhov@gmail.com> |
gpiolib: acpi: avoid leaking ACPI details into upper gpiolib layers There is no need for the generic parts of GPIOLIB to be aware of implementation details of ACPI-bases lookups. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
#
2b6bce80 |
|
11-Nov-2022 |
Dmitry Torokhov <dmitry.torokhov@gmail.com> |
gpiolib: acpi: change acpi_find_gpio() to accept firmware node In preparation of switching all ACPI-based GPIO lookups to go through acpi_find_gpio() let's change it to accept device node as its argument as we do not always have access to device structure. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
#
07445ae1 |
|
15-Nov-2022 |
Dmitry Torokhov <dmitry.torokhov@gmail.com> |
gpiolib: of: change of_find_gpio() to accept device node In preparation of switching all OF-based GPIO lookups to go through of_find_gpio() let's change it to accept device node as its argument as we do not always have access to device structure. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
#
27043a7d |
|
08-Nov-2022 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: of: Integrate of_gpiochip_init_valid_mask() into gpiochip_init_valid_mask() In preparation to complete fwnode switch, integrate of_gpiochip_init_valid_mask() into gpiochip_init_valid_mask(). Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
#
7b61212f |
|
02-Sep-2022 |
Christophe Leroy <christophe.leroy@csgroup.eu> |
gpiolib: Get rid of ARCH_NR_GPIOS Since commit 14e85c0e69d5 ("gpio: remove gpio_descs global array") there is no limitation on the number of GPIOs that can be allocated in the system since the allocation is fully dynamic. ARCH_NR_GPIOS is today only used in order to provide downwards gpiobase allocation from that value, while static allocation is performed upwards from 0. However that has the disadvantage of limiting the number of GPIOs that can be registered in the system. To overcome this limitation without requiring each and every platform to provide its 'best-guess' maximum number, rework the allocation to allocate upwards, allowing approx 2 millions of GPIOs. In order to still allow static allocation for legacy drivers, define GPIO_DYNAMIC_BASE with the value 512 as the start for dynamic allocation. The 512 value is chosen because it is the end of the current default range so all current static allocations are expected to be below that value. Of course that's just a rough estimate based on the default value, but assuming static allocations come first, even if there are more static allocations it should fit under the 512 value. In the future, it is expected that all static allocations go away and then dynamic allocation will be patched to start at 0. Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
#
502df79b |
|
02-Sep-2022 |
Christophe Leroy <christophe.leroy@csgroup.eu> |
gpiolib: Warn on drivers still using static gpiobase allocation In the preparation of getting completely rid of static gpiobase allocation in the future, emit a warning in drivers still doing so. Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
#
ec851b23 |
|
25-Nov-2022 |
Zeng Heng <zengheng4@huawei.com> |
gpiolib: fix memory leak in gpiochip_setup_dev() Here is a backtrace report about memory leak detected in gpiochip_setup_dev(): unreferenced object 0xffff88810b406400 (size 512): comm "python3", pid 1682, jiffies 4295346908 (age 24.090s) backtrace: kmalloc_trace device_add device_private_init at drivers/base/core.c:3361 (inlined by) device_add at drivers/base/core.c:3411 cdev_device_add gpiolib_cdev_register gpiochip_setup_dev gpiochip_add_data_with_key gcdev_register() & gcdev_unregister() would call device_add() & device_del() (no matter CONFIG_GPIO_CDEV is enabled or not) to register/unregister device. However, if device_add() succeeds, some resource (like struct device_private allocated by device_private_init()) is not released by device_del(). Therefore, after device_add() succeeds by gcdev_register(), it needs to call put_device() to release resource in the error handle path. Here we move forward the register of release function, and let it release every piece of resource by put_device() instead of kfree(). While at it, fix another subtle issue, i.e. when gc->ngpio is equal to 0, we still call kcalloc() and, in case of further error, kfree() on the ZERO_PTR pointer, which is not NULL. It's not a bug per se, but rather waste of the resources and potentially wrong expectation about contents of the gdev->descs variable. Fixes: 159f3cd92f17 ("gpiolib: Defer gpio device setup until after gpiolib initialization") Signed-off-by: Zeng Heng <zengheng4@huawei.com> Co-developed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
#
0eadd36d |
|
04-Sep-2022 |
Dmitry Torokhov <dmitry.torokhov@gmail.com> |
gpiolib: make fwnode_get_named_gpiod() static There are no external users of fwnode_get_named_gpiod() anymore, so let's stop exporting it and mark it as static. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
|
#
c269df8c |
|
13-Jul-2022 |
Nuno Sá <nuno.sa@analog.com> |
gpiolib: add support for bias pull disable This change prepares the gpio core to look at firmware flags and set 'FLAG_BIAS_DISABLE' if necessary. It works in similar way to 'GPIO_PULL_DOWN' and 'GPIO_PULL_UP'. Signed-off-by: Nuno Sá <nuno.sa@analog.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
|
#
08f12b45 |
|
07-Jul-2022 |
Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> |
gpio: gpiolib: Allow free() callback to be overridden Allow free() callback to be overridden from irq_domain_ops for hierarchical chips. This allows drivers to free up resources which are allocated during child_to_parent_hwirq()/populate_parent_alloc_arg() callbacks. On Renesas RZ/G2L platform a bitmap is maintained for TINT slots, a slot is allocated in child_to_parent_hwirq() callback which is freed up in free callback hence this override. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220707182314.66610-5-prabhakar.mahadev-lad.rj@bp.renesas.com
|
#
91a29af4 |
|
07-Jul-2022 |
Marc Zyngier <maz@kernel.org> |
gpio: Remove dynamic allocation from populate_parent_alloc_arg() The gpiolib is unique in the way it uses intermediate fwspecs when feeding an interrupt specifier to the parent domain, as it relies on the populate_parent_alloc_arg() callback to perform a dynamic allocation. This is pretty inefficient (we free the structure almost immediately), and the only reason this isn't a stack allocation is that our ThunderX friend uses MSIs rather than a FW-constructed structure. Let's solve it by providing a new type composed of the union of a struct irq_fwspec and a msi_info_t, which satisfies both requirements. This allows us to use a stack allocation, and we can move the handful of users to this new scheme. Also perform some additional cleanup, such as getting rid of the stub versions of the irq_domain_translate_*cell helpers, which are never used when CONFIG_IRQ_DOMAIN_HIERARCHY isn't selected. Tested on a Tegra186. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Cc: Daniel Palmer <daniel@thingy.jp> Cc: Romain Perier <romain.perier@gmail.com> Cc: Bartosz Golaszewski <brgl@bgdev.pl> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Jonathan Hunter <jonathanh@nvidia.com> Cc: Robert Richter <rric@kernel.org> Cc: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> Cc: Andy Gross <agross@kernel.org> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Acked-by: Bartosz Golaszewski <brgl@bgdev.pl> Link: https://lore.kernel.org/r/20220707182314.66610-2-prabhakar.mahadev-lad.rj@bp.renesas.com
|
#
42112dd7 |
|
22-Apr-2022 |
Dipen Patel <dipenp@nvidia.com> |
gpiolib: Add HTE support Some GPIO chip can provide hardware timestamp support on its GPIO lines , in order to support that, additional API needs to be added which can talk to both GPIO chip and HTE (hardware timestamping engine) providers if there is any dependencies. This patch introduces optional hooks to enable and disable hardware timestamping related features in the GPIO controller chip. Signed-off-by: Dipen Patel <dipenp@nvidia.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
|
#
234c5209 |
|
08-Apr-2022 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Extract gpio_chip_get_value() wrapper In couple of cases we are using the same code to wrap ->get() callback. Extract that code into a helper for the sake of better maintenance. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
|
#
3de69ae1 |
|
08-Apr-2022 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Refactor gpiolib_dbg_show() with help of for_each_gpio_desc() Use for_each_gpio_desc() and since we would need to touch the entire conditionals, do the following: - rename last occurrence of gdesc to desc - use short ternary operator ?: - join two seq_printf() calls into single one - fix indentation of the seq_printf() parameters Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
|
#
66f46e37 |
|
08-Apr-2022 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Split out for_each_gpio_desc() macro In some cases we want to traverse all GPIO descriptors for given chip, let's split out for_each_gpio_desc() macro for such cases. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
|
#
57017edd |
|
08-Apr-2022 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Embed iterator variable into for_each_gpio_desc_with_flag() The iterator loop is used exclusively to get a descriptor, which in its turn is what is being used by the caller. Embed the iterator variable into the loop in the for_each_gpio_desc_with_flag() macro helper. Suggested-by: Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
|
#
24a9dbb1 |
|
30-Mar-2022 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Move error message out of a spinlock An error path is a slow path, no need to block other CPUs when printing error messages. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
|
#
1cef8b50 |
|
30-Mar-2022 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Get rid of redundant 'else' In the snippets like the following if (...) return / goto / break / continue ...; else ... the 'else' is redundant. Get rid of it. In case of IOCTLs use switch-case pattern that seems the usual in such cases. While at it, clarify necessity of else in gpiod_direction_output() by attaching else if to the closing curly brace on a previous line. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
|
#
704f0875 |
|
19-Apr-2022 |
Marc Zyngier <maz@kernel.org> |
gpio: Expose the gpiochip_irq_re[ql]res helpers The GPIO subsystem has a couple of internal helpers to manage resources on behalf of the irqchip. Expose them so that GPIO drivers can use them directly. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220419141846.598305-3-maz@kernel.org
|
#
6c846d02 |
|
19-Apr-2022 |
Marc Zyngier <maz@kernel.org> |
gpio: Don't fiddle with irqchips marked as immutable In order to move away from gpiolib messing with the internals of unsuspecting irqchips, add a flag by which irqchips advertise that they are not to be messed with, and do solemnly swear that they correctly call into the gpiolib helpers when required. Also nudge the users into converting their drivers to the new model. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220419141846.598305-2-maz@kernel.org
|
#
06fb4ecf |
|
22-Apr-2022 |
Mario Limonciello <mario.limonciello@amd.com> |
gpio: Request interrupts after IRQ is initialized Commit 5467801f1fcb ("gpio: Restrict usage of GPIO chip irq members before initialization") attempted to fix a race condition that lead to a NULL pointer, but in the process caused a regression for _AEI/_EVT declared GPIOs. This manifests in messages showing deferred probing while trying to allocate IRQs like so: amd_gpio AMDI0030:00: Failed to translate GPIO pin 0x0000 to IRQ, err -517 amd_gpio AMDI0030:00: Failed to translate GPIO pin 0x002C to IRQ, err -517 amd_gpio AMDI0030:00: Failed to translate GPIO pin 0x003D to IRQ, err -517 [ .. more of the same .. ] The code for walking _AEI doesn't handle deferred probing and so this leads to non-functional GPIO interrupts. Fix this issue by moving the call to `acpi_gpiochip_request_interrupts` to occur after gc->irc.initialized is set. Fixes: 5467801f1fcb ("gpio: Restrict usage of GPIO chip irq members before initialization") Link: https://lore.kernel.org/linux-gpio/BL1PR12MB51577A77F000A008AA694675E2EF9@BL1PR12MB5157.namprd12.prod.outlook.com/ Link: https://bugzilla.suse.com/show_bug.cgi?id=1198697 Link: https://bugzilla.kernel.org/show_bug.cgi?id=215850 Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1979 Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1976 Reported-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Shreeya Patel <shreeya.patel@collabora.com> Tested-By: Samuel Čavoj <samuel@cavoj.net> Tested-By: lukeluk498@gmail.com Link: Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-and-tested-by: Takashi Iwai <tiwai@suse.de> Cc: Shreeya Patel <shreeya.patel@collabora.com> Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
5467801f |
|
21-Mar-2022 |
Shreeya Patel <shreeya.patel@collabora.com> |
gpio: Restrict usage of GPIO chip irq members before initialization 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->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 <shreeya.patel@collabora.com> Cc: stable@vger.kernel.org Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
|
#
243cfa6a |
|
06-Mar-2022 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Use list_first_entry()/list_last_entry() Use list_first_entry()/list_last_entry() instead of open coded variants. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
|
#
6105b2e3 |
|
01-Feb-2022 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Simplify error path in gpiod_get_index() when requesting GPIO Simplify error path in the gpiod_get_index() when requesting a GPIO line by: - checking for error condition first - dropping redundant 'else' As a result, decrease the indentation level for better readability. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
|
#
322b86e7 |
|
01-Feb-2022 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Use short form of ternary operator in gpiod_get_index() Instead of repeating first argument for true branch, use short form of the ternary operator, i.e. ?:. While at it, fix a typo in the comment. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
|
#
80c78fbe |
|
01-Feb-2022 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Introduce for_each_gpio_desc_with_flag() macro In a few places we are using a loop against all GPIO descriptors with a given flag for a given device. Replace it with a consolidated for_each type of macro. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
|
#
56e337f2 |
|
15-Mar-2022 |
Bartosz Golaszewski <brgl@bgdev.pl> |
Revert "gpio: Revert regression in sysfs-gpio (gpiolib.c)" This reverts commit fc328a7d1fcce263db0b046917a66f3aa6e68719. This commit - while attempting to fix a regression - has caused a number of other problems. As the fallout from it is more significant than the initial problem itself, revert it for now before we find a correct solution. Link: https://lore.kernel.org/all/20220314192522.GA3031157@roeck-us.net/ Link: https://lore.kernel.org/stable/20220314155509.552218-1-michael@walle.cc/ Link: https://lore.kernel.org/all/20211217153555.9413-1-marcelo.jimenez@gmail.com/ Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> Reported-and-bisected-by: Guenter Roeck <linux@roeck-us.net> Reported-by: Michael Walle <michael@walle.cc> Cc: Thorsten Leemhuis <linux@leemhuis.info> Cc: Marcelo Roberto Jimenez <marcelo.jimenez@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
660c619b |
|
07-Mar-2022 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: acpi: Convert ACPI value of debounce to microseconds It appears that GPIO ACPI library uses ACPI debounce values directly. However, the GPIO library APIs expect the debounce timeout to be in microseconds. Convert ACPI value of debounce to microseconds. While at it, document this detail where it is appropriate. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=215664 Reported-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Fixes: 8dcb7a15a585 ("gpiolib: acpi: Take into account debounce settings") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
|
#
fc328a7d |
|
07-Mar-2022 |
Marcelo Roberto Jimenez <marcelo.jimenez@gmail.com> |
gpio: Revert regression in sysfs-gpio (gpiolib.c) Some GPIO lines have stopped working after the patch commit 2ab73c6d8323f ("gpio: Support GPIO controllers without pin-ranges") And this has supposedly been fixed in the following patches commit 89ad556b7f96a ("gpio: Avoid using pin ranges with !PINCTRL") commit 6dbbf84603961 ("gpiolib: Don't free if pin ranges are not defined") But an erratic behavior where some GPIO lines work while others do not work has been introduced. This patch reverts those changes so that the sysfs-gpio interface works properly again. Signed-off-by: Marcelo Roberto Jimenez <marcelo.jimenez@gmail.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
|
#
ae42f928 |
|
16-Feb-2022 |
Shreeya Patel <shreeya.patel@collabora.com> |
gpio: Return EPROBE_DEFER if gc->to_irq is NULL We are racing the registering of .to_irq when probing the i2c driver. This results in random failure of touchscreen devices. Following explains the race condition better. [gpio driver] gpio driver registers gpio chip [gpio consumer] gpio is acquired [gpio consumer] gpiod_to_irq() fails with -ENXIO [gpio driver] gpio driver registers irqchip gpiod_to_irq works at this point, but -ENXIO is fatal We could see the following errors in dmesg logs when gc->to_irq is NULL [2.101857] i2c_hid i2c-FTS3528:00: HID over i2c has not been provided an Int IRQ [2.101953] i2c_hid: probe of i2c-FTS3528:00 failed with error -22 To avoid this situation, defer probing until to_irq is registered. Returning -EPROBE_DEFER would be the first step towards avoiding the failure of devices due to the race in registration of .to_irq. Final solution to this issue would be to avoid using gc irq members until they are fully initialized. This issue has been reported many times in past and people have been using workarounds like changing the pinctrl_amd to built-in instead of loading it as a module or by adding a softdep for pinctrl_amd into the config file. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=209413 Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Shreeya Patel <shreeya.patel@collabora.com> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
|
#
c73960bb |
|
14-Dec-2021 |
Peter Rosin <peda@axentia.se> |
gpiolib: allow line names from device props to override driver names Some GPIO providers set names for GPIO lines that match the names of the pins on the SoC, or variations on that theme. These names are generic more often that not, such as pioC12 in the at91 case. These generic names block the possibility to set more useful GPIO line names with device properties (i.e. gpio-line-names). Allow overriding a generic name given by the GPIO driver if there is a name given to the GPIO line using device properties, but leave the generic name alone if no better name is available. However, there is a risk. If user space is depending on the above mentioned fixed GPIO names, AND there are device properties that previously did not reach the surface, the name change might cause regressions. But hopefully this stays below the radar... Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Tested-by: Alexander Dahl <ada@thorsis.com> Signed-off-by: Peter Rosin <peda@axentia.se> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
|
#
990f6756 |
|
13-Dec-2021 |
Bartosz Golaszewski <brgl@bgdev.pl> |
gpiolib: allow to specify the firmware node in struct gpio_chip Software nodes allow us to represent hierarchies for device components that don't have their struct device representation yet - for instance: banks of GPIOs under a common GPIO expander. The core gpiolib core however doesn't offer any way of passing this information from the drivers. This extends struct gpio_chip with a pointer to fwnode that can be set by the driver and used to pass device properties for child nodes. This is similar to how we handle device-tree sub-nodes with CONFIG_OF_GPIO enabled. Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Linus Walleij <linus.walleij@linaro.org>
|
#
dd61b292 |
|
07-Dec-2021 |
Bartosz Golaszewski <brgl@bgdev.pl> |
gpiolib: provide gpiod_remove_hogs() Currently all users of gpiod_add_hogs() call it only once at system init so there never was any need for a mechanism allowing to remove them. Now the upcoming gpio-sim will need to tear down chips with hogged lines so provide a function that allows to remove hogs. Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Linus Walleij <linus.walleij@linaro.org>
|
#
9dbd1ab2 |
|
02-Dec-2021 |
Bartosz Golaszewski <brgl@bgdev.pl> |
gpiolib: check the 'ngpios' property in core gpiolib code Several drivers read the 'ngpios' device property on their own, but since it's defined as a standard GPIO property in the device tree bindings anyway, it's a good candidate for generalization. If the driver didn't set its gc->ngpio, try to read the 'ngpios' property from the GPIO device's firmware node before bailing out. Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
#
e5ab49cd |
|
02-Dec-2021 |
Bartosz Golaszewski <brgl@bgdev.pl> |
gpiolib: improve coding style for local variables Drop unneeded whitespaces and put the variables of the same type together for consistency with the rest of the code. Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
#
49fdfe66 |
|
03-Dec-2021 |
Geert Uytterhoeven <geert+renesas@glider.be> |
gpiolib: Let gpiod_add_lookup_table() call gpiod_add_lookup_tables() This saves 20 bytes on arm32, and 44 bytes on arm64. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
|
#
cfe6807d |
|
26-Oct-2021 |
Marc Zyngier <maz@kernel.org> |
gpio: Allow per-parent interrupt data 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 <maz@kernel.org> Signed-off-by: Joey Gouly <joey.gouly@arm.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20211026175815.52703-2-joey.gouly@arm.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
4e804c39 |
|
27-Jul-2021 |
Sergio Paracuellos <sergio.paracuellos@gmail.com> |
gpiolib: convert 'devprop_gpiochip_set_names' to support multiple gpiochip banks per device 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 <andy.shevchenko@gmail.com> Reviewed-by: Gregory Fong <gregory.0xf0@gmail.com> Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
c354c295 |
|
25-May-2021 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Switch to bitmap_alloc() Switch to bitmap_alloc() to show clearly what we are allocating. Besides that it returns pointer of bitmap type instead of opaque void *. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
c80c4435 |
|
25-May-2021 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Split fastpath array to two Split fastpath array to two, i.e. for mask and for bits. At the same time declare them as bitmaps. This makes code better to read and gives a clue about use of bitmap API. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
f2e03ca3 |
|
10-May-2021 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Drop duplicate offset check in gpiochip_is_requested() gpiochip_get_desc() already does the check, drop a duplicate in gpiochip_is_requested(). Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
266315fb |
|
09-Mar-2021 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Fold conditionals into a simple ternary operator It's quite spread code to initialize IRQ domain options. Let's fold it into a simple oneliner. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
5c63a9db |
|
09-Mar-2021 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Reuse device's fwnode to create IRQ domain When IRQ domain is created for an ACPI case, the name of it becomes unknown-%d since for now it utilizes of_node member only and doesn't consider fwnode case. Convert IRQ domain creation code to utilize fwnode instead. Before/After the change on Intel Galileo Gen 2 with two GPIO (IRQ) controllers: unknown-1 ==> \_SB.PCI0.GIP0.GPO unknown-2 ==> \_SB.NIO3 Due to the nature of this change we may also deduplicate the WARN():s because in either case (DT or ACPI) the fwnode will be set correctly and %pfw is an equivalent to what the current code prints as a prefix. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
515321ac |
|
09-Mar-2021 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Introduce acpi_gpio_dev_init() and call it from core In the ACPI case we may use the firmware node in the similar way as it's done for OF case. We may use that fwnode for other purposes in the future. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
1df62542 |
|
09-Mar-2021 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Move of_node operations to gpiolib-of and correct fwnode use The initial value of the OF node based on presence of parent, but at the same time this operation somehow appeared separately from others that handle the OF case. On the other hand there is no need to assign dev->fwnode in the OF case if code properly retrieves fwnode, i.e. via dev_fwnode() helper. Amend gpiolib.c and gpiolib-of.c code in order to group OF operations. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
944f4b0a |
|
09-Mar-2021 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Unify the checks on fwnode type We have (historically) different approaches how we identify the type of a given fwnode. Let's standardize them across the library code. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
6cb59afe |
|
15-Mar-2021 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Assign fwnode to parent's if no primary one provided In case when the properties are supplied in the secondary fwnode (for example, built-in device properties) the fwnode pointer left unassigned. This makes unable to retrieve them. Assign fwnode to parent's if no primary one provided. Fixes: 7cba1a4d5e16 ("gpiolib: generalize devprop_gpiochip_set_names() for device properties") Fixes: 2afa97e9868f ("gpiolib: Read "gpio-line-names" from a firmware node") Reported-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Tested-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
3875721e |
|
12-Mar-2021 |
Wei Yongjun <weiyongjun1@huawei.com> |
gpiolib: Fix error return code in gpiolib_dev_init() Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: 4731210c09f5 ("gpiolib: Bind gpio_device to a driver to enable fw_devlink=on by default") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
b41ba2ec |
|
05-Mar-2021 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Read "gpio-line-names" from a firmware node On STM32MP1, the GPIO banks are subnodes of pin-controller@50002000, see arch/arm/boot/dts/stm32mp151.dtsi. The driver for pin-controller@50002000 is in drivers/pinctrl/stm32/pinctrl-stm32.c and iterates over all of its DT subnodes when registering each GPIO bank gpiochip. Each gpiochip has: - gpio_chip.parent = dev, where dev is the device node of the pin controller - gpio_chip.of_node = np, which is the OF node of the GPIO bank Therefore, dev_fwnode(chip->parent) != of_fwnode_handle(chip.of_node), i.e. pin-controller@50002000 != pin-controller@50002000/gpio@5000*000. The original code behaved correctly, as it extracted the "gpio-line-names" from of_fwnode_handle(chip.of_node) = pin-controller@50002000/gpio@5000*000. To achieve the same behaviour, read property from the firmware node. Fixes: 7cba1a4d5e162 ("gpiolib: generalize devprop_gpiochip_set_names() for device properties") Reported-by: Marek Vasut <marex@denx.de> Reported-by: Roman Guskov <rguskov@dh-electronics.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Marek Vasut <marex@denx.de> Reviewed-by: Marek Vasut <marex@denx.de> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
cf25ef6b |
|
01-Mar-2021 |
Johan Hovold <johan@kernel.org> |
gpio: fix gpio-device list corruption Make sure to hold the gpio_lock when removing the gpio device from the gpio_devices list (when dropping the last reference) to avoid corrupting the list when there are concurrent accesses. Fixes: ff2b13592299 ("gpio: make the gpiochip a real device") Cc: stable@vger.kernel.org # 4.6 Reviewed-by: Saravana Kannan <saravanak@google.com> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
a6112998 |
|
01-Mar-2021 |
Johan Hovold <johan@kernel.org> |
gpio: fix NULL-deref-on-deregistration regression Fix a NULL-pointer deference when deregistering the gpio character device that was introduced by the recent stub-driver hack. When the new "driver" is unbound as part of deregistration, driver core clears the driver-data pointer which is used to retrieve the struct gpio_device in its release callback. Fix this by using container_of() in the release callback as should have been done all along. Fixes: 4731210c09f5 ("gpiolib: Bind gpio_device to a driver to enable fw_devlink=on by default") Cc: Saravana Kannan <saravanak@google.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reported-by: syzbot+d27b4c8adbbff70fbfde@syzkaller.appspotmail.com Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
ced2af41 |
|
04-Feb-2021 |
Saravana Kannan <saravanak@google.com> |
gpiolib: Don't probe gpio_device if it's not the primary device Dmitry reported[1] boot error messages caused by commit 4731210c09f5 ("gpiolib: Bind gpio_device to a driver to enable fw_devlink=on by default"). gpio-1022 (cpu-pwr-req-hog): hogged as input max77620-pinctrl max77620-pinctrl: pin gpio4 already requested by max77620-pinctrl; cannot claim for gpiochip1 max77620-pinctrl max77620-pinctrl: pin-4 (gpiochip1) status -22 max77620-pinctrl max77620-pinctrl: could not request pin 4 (gpio4) from group gpio4 on device max77620-pinctrl gpio_stub_drv gpiochip1: Error applying setting, reverse things back gpio_stub_drv: probe of gpiochip1 failed with error -22 This happens because when we try to probe a device, driver core calls into pinctrl to set up the pins. However, if the GPIO DT node already has a proper device created and probed, trying to probe the gpio_device with a stub driver makes the pins be claimed twice. pinctrl doesn't like this and throws an error. So, this patch makes sure the gpio_stub_drv doesn't match with a gpio_device if it's not the primary device for the fwnode. [1] - https://lore.kernel.org/lkml/544ad0e4-0954-274c-8e77-866aaa5661a8@gmail.com/ Fixes: 4731210c09f5 ("gpiolib: Bind gpio_device to a driver to enable fw_devlink=on by default") Tested-by: Dmitry Osipenko <digetx@gmail.com> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20210205020730.1746354-1-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
4731210c |
|
22-Jan-2021 |
Saravana Kannan <saravanak@google.com> |
gpiolib: Bind gpio_device to a driver to enable fw_devlink=on by default There are multiple instances of GPIO device tree nodes of the form: foo { compatible = "acme,foo"; ... gpio0: gpio0@xxxxxxxx { compatible = "acme,bar"; ... gpio-controller; }; gpio1: gpio1@xxxxxxxx { compatible = "acme,bar"; ... gpio-controller; }; ... } bazz { my-gpios = <&gpio0 ...>; } Case 1: The driver for "foo" populates struct device for these gpio* nodes and then probes them using a driver that binds with "acme,bar". This driver for "acme,bar" then registers the gpio* nodes with gpiolib. This lines up with how DT nodes with the "compatible" property are typically converted to struct devices and then registered with driver core to probe them. This also allows the gpio* devices to hook into all the driver core capabilities like runtime PM, probe deferral, suspend/resume ordering, device links, etc. Case 2: The driver for "foo" doesn't populate struct devices for these gpio* nodes before registering them with gpiolib. Instead it just loops through its child nodes and directly registers the gpio* nodes with gpiolib. Drivers that follow case 2 cause problems with fw_devlink=on. This is because fw_devlink will prevent bazz from probing until there's a struct device that has gpio0 as its fwnode (because bazz lists gpio0 as a GPIO supplier). Once the struct device is available, fw_devlink will create a device link with gpio0 device as the supplier and bazz device as the consumer. After this point, since the gpio0 device will never bind to a driver, the device link will prevent bazz device from ever probing. Finding and refactoring all the instances of drivers that follow case 2 will cause a lot of code churn and it is not something that can be done in one shot. In some instances it might not even be possible to refactor them cleanly. Examples of such instances are [1] [2]. This patch works around this problem and avoids all the code churn by simply setting the fwnode of the gpio_device and creating a stub driver to bind to the gpio_device. This allows all the consumers to continue probing when the driver follows case 2. [1] - https://lore.kernel.org/lkml/20201014191235.7f71fcb4@xhacker.debian/ [2] - https://lore.kernel.org/lkml/e28e1f38d87c12a3c714a6573beba6e1@kernel.org/ Fixes: e590474768f1 ("driver core: Set fw_devlink=on by default") Cc: Marc Zyngier <maz@kernel.org> Cc: Jisheng Zhang <Jisheng.Zhang@synaptics.com> Cc: Kever Yang <kever.yang@rock-chips.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20210122193600.1415639-1-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
d321ad12 |
|
28-Dec-2020 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Follow usual pattern for gpiod_remove_lookup_table() call The usual pattern for the remove calls, like gpiod_remove_lookup_table(), is to be NULL-aware, i.o.w. become a no-op whenever parameter is NULL. Update gpiod_remove_lookup_table() call to follow this pattern. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
|
#
c07ea8d0 |
|
05-Jan-2021 |
Wolfram Sang <wsa+renesas@sang-engineering.com> |
gpio: gpiolib: remove shadowed variable After refactoring, we had two variables for the same thing. Remove the second declaration, one is enough here. Found by cppcheck. drivers/gpio/gpiolib.c:2551:17: warning: Local variable 'ret' shadows outer variable [shadowVariable] Fixes: d377f56f34f5 ("gpio: gpiolib: Normalize return code variable name") Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
c351bb64 |
|
29-Jan-2021 |
Quanyang Wang <quanyang.wang@windriver.com> |
gpiolib: free device name on error path to fix kmemleak In gpiochip_add_data_with_key, we should check the return value of dev_set_name to ensure that device name is allocated successfully and then add a label on the error path to free device name to fix kmemleak as below: unreferenced object 0xc2d6fc40 (size 64): comm "kworker/0:1", pid 16, jiffies 4294937425 (age 65.120s) hex dump (first 32 bytes): 67 70 69 6f 63 68 69 70 30 00 1a c0 54 63 1a c0 gpiochip0...Tc.. 0c ed 84 c0 48 ed 84 c0 3c ee 84 c0 10 00 00 00 ....H...<....... backtrace: [<962810f7>] kobject_set_name_vargs+0x2c/0xa0 [<f50797e6>] dev_set_name+0x2c/0x5c [<94abbca9>] gpiochip_add_data_with_key+0xfc/0xce8 [<5c4193e0>] omap_gpio_probe+0x33c/0x68c [<3402f137>] platform_probe+0x58/0xb8 [<7421e210>] really_probe+0xec/0x3b4 [<000f8ada>] driver_probe_device+0x58/0xb4 [<67e0f7f7>] bus_for_each_drv+0x80/0xd0 [<4de545dc>] __device_attach+0xe8/0x15c [<2e4431e7>] bus_probe_device+0x84/0x8c [<c18b1de9>] device_add+0x384/0x7c0 [<5aff2995>] of_platform_device_create_pdata+0x8c/0xb8 [<061c3483>] of_platform_bus_create+0x198/0x230 [<5ee6d42a>] of_platform_populate+0x60/0xb8 [<2647300f>] sysc_probe+0xd18/0x135c [<3402f137>] platform_probe+0x58/0xb8 Signed-off-by: Quanyang Wang <quanyang.wang@windriver.com> Cc: stable@vger.kernel.org Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
ef382374 |
|
17-Jan-2021 |
Nikita Shubin <nikita.shubin@maquefel.me> |
gpiolib: add a warning on gpiochip->to_irq defined gpiochip->to_irq method is redefined in gpiochip_add_irqchip. A lot of gpiod driver's still define ->to_irq method, let's give a gentle warning that they can no longer rely on it, so they can remove it on ocassion. Fixes: e0d8972898139 ("gpio: Implement tighter IRQ chip integration") Signed-off-by: Nikita Shubin <nikita.shubin@maquefel.me> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
9d552219 |
|
10-Dec-2020 |
Nikita Shubin <nikita.shubin@maquefel.me> |
gpiolib: irq hooks: fix recursion in gpiochip_irq_unmask irqchip shared with multiple gpiochips, leads to recursive call of gpiochip_irq_mask/gpiochip_irq_unmask which was assigned to rqchip->irq_mask/irqchip->irq_unmask, these happens becouse of only irqchip->irq_enable == gpiochip_irq_enable is checked. Let's add an additional check to make sure shared irqchip is detected even if irqchip->irq_enable wasn't defined. Fixes: a8173820f441 ("gpio: gpiolib: Allow GPIO IRQs to lazy disable") Signed-off-by: Nikita Shubin <nikita.shubin@maquefel.me> Link: https://lore.kernel.org/r/20201210070514.13238-1-nikita.shubin@maquefel.me Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
c47d9e1b |
|
02-Dec-2020 |
Enrico Weigelt <info@metux.net> |
gpio: just plain warning when nonexisting gpio requested When trying to export an nonexisting gpio ID, the kernel prints out a big warning w/ stacktrace, sounding like a huge problem. In fact it's a pretty normal situation, like file or device not found. So, just print a more relaxed warning instead. changes v2: drop defining pr_fmt() Signed-off-by: Enrico Weigelt <info@metux.net> Link: https://lore.kernel.org/r/20201202133754.32045-1-info@metux.net Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
6dbbf846 |
|
30-Nov-2020 |
Edmond Chung <edmondchung@google.com> |
gpiolib: Don't free if pin ranges are not defined A similar check was added in gpiochip_generic_request, but not in free. This has caused an imbalance count of request vs. free calls to the pinctrl driver. This patch is targeted to fix that issue. Fixes: 2ab73c6d8323 ("gpio: Support GPIO controllers without pin-ranges") Signed-off-by: Edmond Chung <edmondchung@google.com> Signed-off-by: Andrew Chant <achant@google.com> Signed-off-by: Will McVicker <willmcvicker@google.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
3cc1fb73 |
|
18-Nov-2020 |
Grygorii Strashko <grygorii.strashko@ti.com> |
gpiolib: do not print err message for EPROBE_DEFER The gpiochip may have dependencies from pinmux and so got deferred. Now it will print error message every time -EPROBE_DEFER is returned which is unnecessary: "gpiochip_add_data_with_key: GPIOs 0..31 (gpio-0-31) failed to register, -517" Hence, do suppress error message for -EPROBE_DEFER case. Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
f725edd8 |
|
09-Nov-2020 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Introduce gpio_set_debounce_timeout() for internal use In some cases we would like to have debounce setter which doesn't fail when a feature is not supported by a controller. Cc: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
|
#
baca3b15 |
|
11-Nov-2020 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Extract gpio_set_config_with_argument_optional() helper This function is useful for internal use in the GPIO library. There will be new user coming, prepare a helper for the new comer and the existing ones. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
|
#
6aa32ad7 |
|
09-Nov-2020 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: move bias related code from gpio_set_config() to gpio_set_bias() Move bias related code from gpio_set_config() to gpio_set_bias(). Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
|
#
0c4d8666 |
|
09-Nov-2020 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Extract gpio_set_config_with_argument() for future use In the future we will need to have a separate function that takes an arbitrary argument value. Extract gpio_set_config_with_argument() for that purpose. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
|
#
8b69461c |
|
09-Nov-2020 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: use proper API to pack pin configuration parameters Instead of open coded macro use, call pinconf_to_config_packed(). Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
|
#
6900fad6 |
|
09-Nov-2020 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: add missed break statement It's no difference in the functionality, but after the change the code is less error prone to various checkers. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
|
#
13daf489 |
|
09-Nov-2020 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Replace unsigned by unsigned int Replace unsigned by unsigned int in GPIO library code. Note, legacy API left untouched. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
|
#
1f5eb8b1 |
|
05-Nov-2020 |
Kent Gibson <warthog618@gmail.com> |
gpiolib: fix sysfs when cdev is not selected In gpiochip_setup_dev() the call to gpiolib_cdev_register() indirectly calls device_add(). This is still required for the sysfs even when CONFIG_GPIO_CDEV is not selected in the build. Replace the stubbed functions in gpiolib-cdev.h with macros in gpiolib.c that perform the required device_add() and device_del() when CONFIG_GPIO_CDEV is not selected. Fixes: d143493c01b7 (gpiolib: make cdev a build option) Reported-by: Nicolas Schichan <nschichan@freebox.fr> Signed-off-by: Kent Gibson <warthog618@gmail.com> Tested-by: Nicolas Schichan <nschichan@freebox.fr> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
f1f37abb |
|
19-Oct-2020 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: Retire the explicit gpio irqchip code 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 <linus.walleij@linaro.org> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Thierry Reding <thierry.reding@gmail.com> Link: https://lore.kernel.org/r/20201019134046.65101-1-linus.walleij@linaro.org
|
#
9ef6293c |
|
09-Oct-2020 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Use proper type for bias enumerator in gpio_set_bias() First of all, bias has a special type as being a part of enum pin_config_param. Second, 0 is also defined bias which is equivalent to BUS_HOLD. Taking into account above, change type of bias variable and refactor gpio_set_bias() in a way that it doesn't use BUS_HOLD as a place holder. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20201009184359.16427-1-andriy.shevchenko@linux.intel.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
95d9f84f |
|
21-Oct-2020 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: split error path in gpiod_request_commit() For better maintenance and micro optimization split error path in the gpiod_request_commit(). Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
8bbff39c |
|
21-Oct-2020 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Unify expectations about ->request() returned value Half of the code in the GPIO library is written in an expectation that any non-zero value returned from the ->request() callback is an error code, while some code checks only for negative values. Unify expectations about ->request() returned value to be non-zero for an error and 0 for the success. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
7b58696d |
|
21-Oct-2020 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Extract gpiod_not_found() helper Several places in the code are using same idiom, i.e. IS_ERR(desc) && PTR_ERR(desc) == -ENOENT which meaning is GPIO description is not found. For better readability extract gpiod_not_found() helper and use it. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
65cff704 |
|
27-Sep-2020 |
Kent Gibson <warthog618@gmail.com> |
gpiolib: cdev: support setting debounce Add support for setting debounce on a line via the GPIO uAPI. Where debounce is not supported by hardware, a software debounce is provided. The implementation of the software debouncer waits for the line to be stable for the debounce period before determining if a level change, and a corresponding edge event, has occurred. This provides maximum protection against glitches, but also introduces a debounce_period latency to edge events. The software debouncer is integrated with the edge detection as it utilises the line interrupt, and integration is simpler than getting the two to interwork. Where software debounce AND edge detection is required, the debouncer provides both. Signed-off-by: Kent Gibson <warthog618@gmail.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
73e03419 |
|
27-Sep-2020 |
Kent Gibson <warthog618@gmail.com> |
gpiolib: cdev: support edge detection for uAPI v2 Add support for edge detection to lines requested using GPIO_V2_GET_LINE_IOCTL. The edge_detector implementation is based on the v1 lineevent implementation. Unlike the v1 implementation, an overflow of the event buffer results in discarding older events, rather than the most recent, so the final event in a burst will correspond to the current state of the line. Signed-off-by: Kent Gibson <warthog618@gmail.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
587823d3 |
|
17-Sep-2020 |
Bartosz Golaszewski <bgolaszewski@baylibre.com> |
gpiolib: check for parent device in devprop_gpiochip_set_names() It's possible for a GPIO chip to not have a parent device (whose properties we inspect for 'gpio-line-names'). In this case we should simply return from devprop_gpiochip_set_names(). Add an appropriate check for this use-case. Fixes: 7cba1a4d5e16 ("gpiolib: generalize devprop_gpiochip_set_names() for device properties") Reported-by: Anders Roxell <anders.roxell@linaro.org> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Anders Roxell <anders.roxell@linaro.org> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
|
#
32fc5aa2 |
|
09-Sep-2020 |
Bartosz Golaszewski <bgolaszewski@baylibre.com> |
gpiolib: unexport devprop_gpiochip_set_names() 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 <bgolaszewski@baylibre.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
#
7cba1a4d |
|
09-Sep-2020 |
Bartosz Golaszewski <bgolaszewski@baylibre.com> |
gpiolib: generalize devprop_gpiochip_set_names() for device properties devprop_gpiochip_set_names() is overly complicated with taking the fwnode argument (which requires using dev_fwnode() & 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 <bgolaszewski@baylibre.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
|
#
8d4a85b6 |
|
08-Sep-2020 |
Bartosz Golaszewski <bgolaszewski@baylibre.com> |
gpiolib: switch to simpler IDA interface We don't need to specify any ranges when allocating IDs so we can switch to ida_alloc() and ida_free() instead of the ida_simple_ counterparts. ida_simple_get(ida, 0, 0, gfp) is equivalent to ida_alloc_range(ida, 0, UINT_MAX, gfp) which is equivalent to ida_alloc(ida, gfp). Note: IDR will never actually allocate an ID larger than INT_MAX. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
#
425c5b3e |
|
10-Sep-2020 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: convert to use DEFINE_SEQ_ATTRIBUTE macro Use DEFINE_SEQ_ATTRIBUTE macro to simplify the code. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
6accc376 |
|
07-Jul-2020 |
Kent Gibson <warthog618@gmail.com> |
gpiolib: cdev: use blocking notifier call chain instead of atomic Replace usage of atomic_notifier_call_chain with blocking_notifier_call_chain as the notifier function, lineinfo_changed_notify, calls gpio_desc_to_lineinfo, which calls pinctrl_gpio_can_use_line, which can sleep. The chain isn't being called from an atomic context so the the blocking notifier is a suitable substitute. Signed-off-by: Kent Gibson <warthog618@gmail.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
ef087d8e |
|
07-Jul-2020 |
Kent Gibson <warthog618@gmail.com> |
gpiolib: move gpiolib-sysfs function declarations into their own header Move gpiolib-sysfs function declarations into their own header. These functions are in gpiolib-sysfs.c, and are only required by gpiolib.c, and so should be in a module header, not gpiolib.h. This brings gpiolib-sysfs into line with gpiolib-cdev, and is another step towards removing the sysfs inferface. Signed-off-by: Kent Gibson <warthog618@gmail.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
ae66eca0 |
|
29-Jun-2020 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Deduplicate find_first_zero_bit() call bitmap_full() is a shortcut to find_first_zero_bit(). Thus, no need to call it twice. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
925ca369 |
|
16-Jun-2020 |
Kent Gibson <warthog618@gmail.com> |
gpiolib: split character device into gpiolib-cdev Split the cdev specific functionality out of gpiolib.c and into gpiolib-cdev.c. This improves the readability and maintainability of both the cdev and core gpiolib code. Suggested-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Kent Gibson <warthog618@gmail.com> Link: https://lore.kernel.org/r/20200616093615.5167-1-warthog618@gmail.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
6a45b0e2 |
|
28-May-2020 |
Michael Walle <michael@walle.cc> |
gpiolib: Introduce gpiochip_irqchip_add_domain() The function connects an IRQ domain to a gpiochip and reuses gpiochip_to_irq() which is provided by gpiolib. gpiochip_irqchip_* and regmap_irq partially provide the same functionality. This function will help to connect just the minimal functionality of the gpiochip_irqchip which is needed to work together with regmap-irq. Signed-off-by: Michael Walle <michael@walle.cc> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20200528145845.31436-2-michael@walle.cc Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
e9bdf7e6 |
|
27-May-2020 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: fix locking open drain IRQ lines We provided the right semantics on open drain lines being by definition output but incidentally the irq set up function would only allow IRQs on lines that were "not output". Fix the semantics to allow output open drain lines to be used for IRQs. Reported-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Tested-by: Hans Verkuil <hverkuil@xs4all.nl> Cc: Russell King <linux@armlinux.org.uk> Cc: stable@vger.kernel.org # v5.3+ Link: https://lore.kernel.org/r/20200527140758.162280-1-linus.walleij@linaro.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
a8173820 |
|
23-May-2020 |
Maulik Shah <mkshah@codeaurora.org> |
gpio: gpiolib: Allow GPIO IRQs to lazy disable With 'commit 461c1a7d4733 ("gpiolib: override irq_enable/disable")' gpiolib overrides irqchip's irq_enable and irq_disable callbacks. If irq_disable callback is implemented then genirq takes unlazy path to disable irq. Underlying irqchip may not want to implement irq_disable callback to lazy disable irq when client drivers invokes disable_irq(). By overriding irq_disable callback, gpiolib ends up always unlazy disabling IRQ. Allow gpiolib to lazy disable IRQs by overriding irq_disable callback only if irqchip implemented irq_disable. In cases where irq_disable is not implemented irq_mask is overridden. Similarly override irq_enable callback only if irqchip implemented irq_enable otherwise irq_unmask is overridden. Fixes: 461c1a7d4733 ("gpiolib: override irq_enable/disable") Signed-off-by: Maulik Shah <mkshah@codeaurora.org> Tested-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Link: https://lore.kernel.org/r/1590253873-11556-2-git-send-email-mkshah@codeaurora.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
a34d5e56 |
|
25-May-2020 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Separate GPIO_GET_LINEINFO_WATCH_IOCTL conditional We already have two conditionals inside the outer one to check if the command is GPIO_GET_LINEINFO_WATCH_IOCTL. I think it's time to actually do what I have proposed in the first place, i.e. to separate GPIO_GET_LINEINFO_WATCH_IOCTL from GPIO_GET_LINEINFO_IOCTL. It's +13 LOCs, and surprisingly only +13 bytes of binary on x86_32, but for the price of much better readability. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Link: https://lore.kernel.org/r/20200525194028.74236-1-andriy.shevchenko@linux.intel.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
4c033b54 |
|
11-May-2020 |
Geert Uytterhoeven <geert+renesas@glider.be> |
gpiolib: Add support for GPIO lookup by line name Currently a GPIO lookup table can only refer to a specific GPIO by a tuple, consisting of a GPIO controller label and a GPIO offset inside the controller. However, a GPIO may also carry a line name, defined by DT or ACPI. If present, the line name is the most use-centric way to refer to a GPIO. Hence add support for looking up GPIOs by line name. Note that there is no guarantee that GPIO line names are globally unique, so this will use the first match found. Implement this by reusing the existing gpiod_lookup infrastructure. Rename gpiod_lookup.chip_label to gpiod_lookup.key, to make it clear that this field can have two meanings, and update the kerneldoc and GPIO_LOOKUP*() macros. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Eugeniu Rosca <erosca@de.adit-jv.com> Reviewed-by: Ulrich Hecht <uli+renesas@fpond.eu> Reviewed-by: Eugeniu Rosca <erosca@de.adit-jv.com> Link: https://lore.kernel.org/r/20200511145257.22970-4-geert+renesas@glider.be Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
582838ea |
|
10-May-2020 |
Geert Uytterhoeven <geert+renesas@glider.be> |
gpiolib: Document that GPIO line names are not globally unique gpiochip_set_desc_names() no longer rejects GPIO line name collisions. Hence GPIO line names are not guaranteed to be globally unique. In case of multiple GPIO lines with the same name, gpio_name_to_desc() will return the first match found. Update the comments for gpio_name_to_desc() and gpiochip_set_desc_names() to match reality. Fixes: f881bab038c9667d ("gpio: keep the GPIO line names internal") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20200511101828.30046-1-geert+renesas@glider.be Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
9fefca77 |
|
09-May-2020 |
Bartosz Golaszewski <bgolaszewski@baylibre.com> |
gpiolib: notify user-space about line status changes after flags are set Currently we emit the REQUESTED line state event after the line is requested but before the flags are configured. This is obviously wrong as we want to pass the updated lineinfo to user-space together with the event. Since the flags can be configured in different ways depending on how the line is being requested - we need to call the notifier chain in different places separately. Fixes: 51c1064e82e7 ("gpiolib: add new ioctl() for monitoring changes in line info") Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
8650b609 |
|
24-Apr-2020 |
David Gow <davidgow@google.com> |
gpio: of: Build fails if CONFIG_OF_DYNAMIC enabled without CONFIG_OF_GPIO The symbol 'gpio_of_notifier' doesn't exist without both CONFIG_OF_GPIO and CONFIG_OF_DYNAMIC enabled, but is referenced when only CONFIG_OF_DYNAMIC is enabled. This broke building with 'make ARCH=um allyesconfig': --------------- /usr/bin/ld: drivers/gpio/gpiolib.o: in function `gpiolib_dev_init': ./drivers/gpio/gpiolib.c:5293: undefined reference to `gpio_of_notifier' collect2: error: ld returned 1 exit status --------------- Fixes: 63636d956c45 ("gpio: of: Add DT overlay support for GPIO hogs") Signed-off-by: David Gow <davidgow@google.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20200425044655.166257-1-davidgow@google.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
262b9011 |
|
24-Apr-2020 |
Geert Uytterhoeven <geert+renesas@glider.be> |
gpiolib: Improve kernel messages Simplify the printing of kernel messages and make the messages more accurate by using the most appropriate {dev,chip,gpiod}_*() helpers. Sample impact: -gpiochip_setup_dev: registered GPIOs 496 to 511 on device: gpiochip0 (e6050000.gpio) +gpio gpiochip0: registered GPIOs 496 to 511 on e6050000.gpio -no flags found for gpios +gpio-953 (?): no flags found for gpios -GPIO line 355 (PCIE/SATA switch) hogged as output/low +gpio-355 (PCIE/SATA switch): hogged as output/low Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20200424141432.11400-1-geert+renesas@glider.be Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
6409d049 |
|
17-Apr-2020 |
Bartosz Golaszewski <bgolaszewski@baylibre.com> |
gpiolib: don't call sleeping functions with a spinlock taken We must not call pinctrl_gpio_can_use_line() with the gpio_lock taken as it takes a mutex internally. Let's move the call before taking the spinlock and store the return value. This isn't perfect - there's a moment between calling pinctrl_gpio_can_use_line() and taking the spinlock where the situation can change but it isn't a regression either: previously this part wasn't protected at all and it only affects the information user-space is seeing. Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Fixes: d2ac25798208 ("gpiolib: provide a dedicated function for setting lineinfo") Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Acked-by: Linus Walleij <linus.walleij@linaro.org>
|
#
4e154159 |
|
15-Apr-2020 |
Bartosz Golaszewski <bgolaszewski@baylibre.com> |
gpiolib: improve the robustness of watch/unwatch ioctl() This makes the new ioctl() a bit more robust - we now check if a line is already being watched and return -EBUSY if the user-space tries to start watching it again. Same for unwatch - return -EBUSY if user-space tries to unwatch a line that's not being watched. Fixes: 51c1064e82e7 ("gpiolib: add new ioctl() for monitoring changes in line info") Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
|
#
a0b66a73 |
|
29-Mar-2020 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: Rename variable in core APIs There is struct gpio *gc, *chip and *gpiochip, and yes I am responsible for some of the inconsistencies. I want this to be just gc everywhere for minimizing cognitive resistance when reading the code: more compact function signatures and less clutter. Purely syntactic changes intended. No semantic effects. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20200329140405.52276-1-linus.walleij@linaro.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
89ad556b |
|
30-Mar-2020 |
Thierry Reding <treding@nvidia.com> |
gpio: Avoid using pin ranges with !PINCTRL Do not use the struct gpio_device's .pin_ranges field if the PINCTRL Kconfig symbol is not selected to avoid build failures. Fixes: 2ab73c6d8323fa1e ("gpio: Support GPIO controllers without pin-ranges") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20200330090257.2332864-1-thierry.reding@gmail.com Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org> Tested-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
5f4bf171 |
|
25-Mar-2020 |
Geert Uytterhoeven <geert+renesas@glider.be> |
gpiolib: Remove unused gpio_chip parameter from gpio_set_bias() gpio_set_bias() no longer uses the passed gpio_chip pointer parameter. Remove it. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20200325100439.14000-3-geert+renesas@glider.be Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
83522358 |
|
25-Mar-2020 |
Geert Uytterhoeven <geert+renesas@glider.be> |
gpiolib: Pass gpio_desc to gpio_set_config() All callers of gpio_set_config() have to convert a gpio_desc to a gpio_chip and offset. Avoid these duplicated conversion steps by letting gpio_set_config() take a gpio_desc pointer directly. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20200325100439.14000-2-geert+renesas@glider.be Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
8ced32ff |
|
24-Mar-2020 |
Geert Uytterhoeven <geert+renesas@glider.be> |
gpiolib: Introduce gpiod_set_config() The GPIO Aggregator will need a method to forward a .set_config() call to its parent gpiochip. This requires obtaining the gpio_chip and offset for a given gpio_desc. While gpiod_to_chip() is public, gpio_chip_hwgpio() is not, so there is currently no method to obtain the needed GPIO offset parameter. Hence introduce a public gpiod_set_config() helper, which invokes the .set_config() callback through a gpio_desc pointer, like is done for most other gpio_chip callbacks. Rewrite the existing gpiod_set_debounce() helper as a wrapper around gpiod_set_config(), to avoid duplication. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20200324135653.6676-5-geert+renesas@glider.be Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
35c6cfb4 |
|
17-Mar-2020 |
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> |
gpio: gpiolib: fix a doc warning Use a different markup for the ERR_PTR, as %FOO doesn't work if there are parenthesis. So, use, instead: ``ERR_PTR(-EINVAL)`` This fixes the following warning: ./drivers/gpio/gpiolib.c:139: WARNING: Inline literal start-string without end-string. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/51197e3568f073e22c280f0584bfa20b44436708.1584456635.git.mchehab+huawei@kernel.org Reviewed-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
2ab73c6d |
|
19-Mar-2020 |
Thierry Reding <treding@nvidia.com> |
gpio: Support GPIO controllers without pin-ranges Wake gpiochip_generic_request() call into the pinctrl helpers only if a GPIO controller had any pin-ranges assigned to it. This allows a driver to unconditionally use this helper if it supports multiple devices of which only a subset have pin-ranges assigned to them. Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20200319122737.3063291-2-thierry.reding@gmail.com Tested-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
ee203bbd |
|
15-Mar-2020 |
Michał Mirosław <mirq-linux@rere.qmqm.pl> |
gpiolib: gpio_name_to_desc: factor out !name check Since name == NULL can't ever match, move the check out of IRQ-disabled region. Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
a28e1c05 |
|
13-Mar-2020 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: Move devres calls to devres file These two devres functions devm_gpiochip_[add|remove]() were in the wrong file. They should be in gpiolib-devres.c not gpiolib.c. Link: https://lore.kernel.org/r/20200313081522.35143-1-linus.walleij@linaro.org Reviewed-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
8959b304 |
|
06-Mar-2020 |
Linus Walleij <linus.walleij@linaro.org> |
gpiolib: Fix irq_disable() semantics The implementation if .irq_disable() which kicks in between the gpiolib and the driver is not properly mimicking the expected semantics of the irqchip core: the irqchip will call .irq_disable() if that exists, else it will call mask_irq() which first checks if .irq_mask() is defined before calling it. Since we are calling it unconditionally, we get this bug from drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c, as it only defines .irq_mask_ack and not .irq_mask: Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = (ptrval) (...) PC is at 0x0 LR is at gpiochip_irq_disable+0x20/0x30 Fix this by only calling .irq_mask() if it exists. Cc: Brian Masney <masneyb@onstation.org> Cc: Hans Verkuil <hans.verkuil@cisco.com> Cc: stable@vger.kernel.org Reviewed-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Fixes: 461c1a7d4733 ("gpiolib: override irq_enable/disable") Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20200306132326.1329640-1-linus.walleij@linaro.org
|
#
ca18a852 |
|
02-Mar-2020 |
Geert Uytterhoeven <geert+renesas@glider.be> |
gpiolib: Fix inverted check in gpiochip_remove() The optimization to check for requested lines actually optimized for the uncomon error case, where one of the GPIO lines is still in use. Hence the error message must be printed when the loop is terminated early, not when it went through all available GPIO lines. Fixes: 869233f81337bfb3 ("gpiolib: Optimize gpiochip_remove() when check for requested line") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20200302082448.11795-1-geert+renesas@glider.be Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
19314797 |
|
26-Feb-2020 |
Bartosz Golaszewski <bgolaszewski@baylibre.com> |
gpiolib: fix bitmap operations related to line event watching When operating on the bits of watched_lines bitmap, we're using desc_to_gpio() which returns the GPIO number from the global numberspace. This leads to all sorts of memory corruptions and invalid behavior. We should switch to using gpio_chip_hwgpio() instead. Fixes: 51c1064e82e7 ("gpiolib: add new ioctl() for monitoring changes in line info") Reported-by: Kent Gibson <warthog618@gmail.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Tested-by: Kent Gibson <warthog618@gmail.com>
|
#
48543bd8 |
|
24-Feb-2020 |
Kent Gibson <warthog618@gmail.com> |
gpiolib: fix unwatch ioctl() Fix the field having a bit cleared by the unwatch ioctl(). Fixes: 51c1064e82e7 ("gpiolib: add new ioctl() for monitoring changes in line info") Signed-off-by: Kent Gibson <warthog618@gmail.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
df2cd589 |
|
13-Feb-2020 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Rename 'event' to 'ge' to be consistent with other use Rename 'event' to 'ge' to be consistent with other use. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
869233f8 |
|
25-Feb-2020 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Optimize gpiochip_remove() when check for requested line Here are the following optimizations have been done: - break the loop after first found requested line - due to above, drop redundant boolean variable - replace open coded variant of gpiochip_is_requested() - due to above, drop redundant pointer to struct gpio_desc - use 'unsigned int' instead of 'unsigned' for loop counter Note, pointer to struct gpio_chip followed by pointer to struct gpio_device is still valid, back link is not. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20200225114725.839-1-andriy.shevchenko@linux.intel.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
97795420 |
|
25-Feb-2020 |
Marco Felsch <m.felsch@pengutronix.de> |
gpiolib: export gpiochip_get_desc The function was currently used internal by the gpiolib. Since commit 56cc3af4e8c8 ("pinctrl: da9062: add driver support") it is also used by drivers so we need to export the symbol. Signed-off-by: Marco Felsch <m.felsch@pengutronix.de> Link: https://lore.kernel.org/r/20200225093102.10964-1-m.felsch@pengutronix.de Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
63636d95 |
|
20-Feb-2020 |
Geert Uytterhoeven <geert+renesas@glider.be> |
gpio: of: Add DT overlay support for GPIO hogs As GPIO hogs are configured at GPIO controller initialization time, adding/removing GPIO hogs in DT overlays does not work. Add support for GPIO hogs described in DT overlays by registering an OF reconfiguration notifier, to handle the addition and removal of GPIO hog subnodes to/from a GPIO controller device node. Note that when a GPIO hog device node is being removed, its "gpios" properties is no longer available, so we have to keep track of which node a hog belongs to, which is done by adding a pointer to the hog's device node to struct gpio_desc. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20200220130149.26283-3-geert+renesas@glider.be Reviewed-by: Frank Rowand <frank.rowand@sony.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
f8850206 |
|
20-Feb-2020 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: Switch timestamps to ktime_get_ns() The existing use of ktime_get_real_ns() in the timestamps from the GPIO events is dubious. We have had several discussions about this timestamp, and it is unclear whether userspace has ever taken into account that a timestamp from ktime_get_real_ns() can actually move backwards in time relative the previous timetamp, and userspace is more likely to expect a monotonic counter. Background: https://lore.kernel.org/linux-gpio/CAK8P3a1Skvm48sje8FNDPLYqyz9Lf8q0qX1QETWtyZTxuX4k1g@mail.gmail.com/ https://marc.info/?l=linux-gpio&m=151661955709074&w=2 The change is ABI incompatible, but incompatible in a way that is IMO more likely to fix future bugs rather than break current userspace. To the best of my knowledge all userspace expects a monotonic timestamp and users are just lucky that they very seldom move backwards in time. Cc: Arnd Bergmann <arnd@arndb.de> Acked-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
1739a2d8 |
|
19-Feb-2020 |
Bartosz Golaszewski <bgolaszewski@baylibre.com> |
gpiolib: use gpiochip_get_desc() where applicable Whenever retrieving a descriptor from a gpiochip: use the provided helper which checks for errors. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Link: https://lore.kernel.org/r/20200219094702.6463-1-brgl@bgdev.pl Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
51c1064e |
|
22-Nov-2019 |
Bartosz Golaszewski <bgolaszewski@baylibre.com> |
gpiolib: add new ioctl() for monitoring changes in line info Currently there is no way for user-space to be informed about changes in status of GPIO lines e.g. when someone else requests the line or its config changes. We can only periodically re-read the line-info. This is fine for simple one-off user-space tools, but any daemon that provides a centralized access to GPIO chips would benefit hugely from an event driven line info synchronization. This patch adds a new ioctl() that allows user-space processes to reuse the file descriptor associated with the character device for watching any changes in line properties. Every such event contains the updated line information. Currently the events are generated on three types of status changes: when a line is requested, when it's released and when its config is changed. The first two are self-explanatory. For the third one: this will only happen when another user-space process calls the new SET_CONFIG ioctl() as any changes that can happen from within the kernel (i.e. set_transitory() or set_debounce()) are of no interest to user-space. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
|
#
d2ac2579 |
|
03-Dec-2019 |
Bartosz Golaszewski <bgolaszewski@baylibre.com> |
gpiolib: provide a dedicated function for setting lineinfo We'll soon be filling out the gpioline_info structure in multiple places. Add a separate function that given a gpio_desc sets all relevant fields. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
#
248ae175 |
|
29-Nov-2019 |
Bartosz Golaszewski <bgolaszewski@baylibre.com> |
gpiolib: emit a debug message when adding events to a full kfifo Currently if the line-event kfifo is full, we just silently drop any new events. Add a ratelimited debug message so that we at least have some trace in the kernel log of event overflow. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
dea9c80e |
|
26-Nov-2019 |
Bartosz Golaszewski <bgolaszewski@baylibre.com> |
gpiolib: rework the locking mechanism for lineevent kfifo The read_lock mutex is supposed to prevent collisions between reading and writing to the line event kfifo but it's actually only taken when the events are being read from it. Drop the mutex entirely and reuse the spinlock made available to us in the waitqueue struct. Take the lock whenever the fifo is modified or inspected. Drop the call to kfifo_to_user() and instead first extract the new element from kfifo when the lock is taken and only then pass it on to the user after the spinlock is released. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
|
#
8131b73b |
|
20-Jan-2020 |
Kent Gibson <warthog618@gmail.com> |
gpiolib: remove unnecessary argument from set_config call Remove unnecessary argument when setting PIN_CONFIG_BIAS_DISABLE. No argument is expected by pinctrl, so removing it should be harmless. Fixes: 2148ad7790ea ("gpiolib: add support for disabling line bias") Signed-off-by: Kent Gibson <warthog618@gmail.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
62adc6f3 |
|
03-Feb-2020 |
Bartosz Golaszewski <bgolaszewski@baylibre.com> |
gpiolib: fix gpio_do_set_config() Commit d90f36851d65 ("gpiolib: have a single place of calling set_config()") introduced a regression where we don't pass the right variable as argument to the set_config() callback of gpio driver from gpio_set_config(). After reverting two additional patches that came on top of it - this addresses the issue by changing the type of the last argument of gpio_do_set_config() to unsigned long and making sure the packed config variable is actually used in gpio_set_config(). Fixes: d90f36851d65 ("gpiolib: have a single place of calling set_config()") Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Tested-by: Guenter Roeck <linux@roeck-us.net>
|
#
91b4ea5f |
|
03-Feb-2020 |
Bartosz Golaszewski <bgolaszewski@baylibre.com> |
Revert "gpiolib: remove set but not used variable 'config'" This reverts commit e5e42ad224a040f93bf112e96f82b3a0ed97ffab. This patch came on top of another patch that introduced a regression. Revert it before addressing the culprit. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Tested-by: Guenter Roeck <linux@roeck-us.net>
|
#
d99f8876 |
|
03-Feb-2020 |
Bartosz Golaszewski <bgolaszewski@baylibre.com> |
Revert "gpiolib: Remove duplicated function gpio_do_set_config()" This reverts commit d18fddff061d2796525e6d4a958cb3d30aed8efd. This patch came on top of another patch that introduced a regression. Revert it before addressing the culprit. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Tested-by: Guenter Roeck <linux@roeck-us.net>
|
#
45586c70 |
|
03-Feb-2020 |
Masahiro Yamada <masahiroy@kernel.org> |
treewide: remove redundant IS_ERR() before error code check 'PTR_ERR(p) == -E*' is a stronger condition than IS_ERR(p). Hence, IS_ERR(p) is unneeded. The semantic patch that generates this commit is as follows: // <smpl> @@ expression ptr; constant error_code; @@ -IS_ERR(ptr) && (PTR_ERR(ptr) == - error_code) +PTR_ERR(ptr) == - error_code // </smpl> Link: http://lkml.kernel.org/r/20200106045833.1725-1-masahiroy@kernel.org Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Cc: Julia Lawall <julia.lawall@lip6.fr> Acked-by: Stephen Boyd <sboyd@kernel.org> [drivers/clk/clk.c] Acked-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> [GPIO] Acked-by: Wolfram Sang <wsa@the-dreams.de> [drivers/i2c] Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> [acpi/scan.c] Acked-by: Rob Herring <robh@kernel.org> Cc: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
207270dd |
|
20-Jan-2020 |
Dan Callaghan <dan.callaghan@opengear.com> |
gpiolib: hold gpio devices lock until ->descs array is initialised If a driver consuming the GPIO chip is being probed at the same time as the GPIO driver is registering the chip, it is possible for the consuming driver to see the ->descs array in an uninitialised state. For example, the gpio-keys-polled driver can fail like this: kernel: gpiod_request: invalid GPIO (no device) kernel: gpio-keys-polled PRP0001:07: failed to get gpio: -22 kernel: gpio-keys-polled: probe of PRP0001:07 failed with error -22 This patch makes gpiochip_add() hold the lock protecting gpio_devices until it has finished setting desc->gdev on the newly inserted list entry. Signed-off-by: Dan Callaghan <dan.callaghan@opengear.com> Link: https://lore.kernel.org/r/20200121001216.15964-1-dan.callaghan@opengear.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
72780ce5 |
|
13-Jan-2020 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: Drop the chained IRQ handler assign function gpiochip_set_chained_irqchip() would assign a chained handler to a GPIO chip. We now populate struct gpio_irq_chip for all chained GPIO irqchips so drop this function. Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20200113220800.77817-1-linus.walleij@linaro.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
366950ee |
|
20-Jan-2020 |
Kevin Hao <haokexin@gmail.com> |
gpiolib: Lower verbosity when allocating hierarchy irq In the current codes, the following 3 lines would be output to the console for each irq line. gpio gpiochip0: (gpio_thunderx): allocate IRQ 10, hwirq 0 gpio gpiochip0: (gpio_thunderx): found parent hwirq 245784 gpio gpiochip0: (gpio_thunderx): alloc_irqs_parent for 10 parent hwirq 245784 In general, there are about tens of irq lines for each gpio chip, and then it would emit so many insignificant log in the boot process. These infos are more suitable for the dbg purpose. So change these to the dbg level. With this change, about 200 lines are suppressed on my Marvell cn96xx board. Signed-off-by: Kevin Hao <haokexin@gmail.com> Link: https://lore.kernel.org/r/20200120095625.25164-1-haokexin@gmail.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
d18fddff |
|
16-Jan-2020 |
YueHaibing <yuehaibing@huawei.com> |
gpiolib: Remove duplicated function gpio_do_set_config() gpio_set_config() simply call gpio_do_set_config(), so remove the duplicated function. Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20200116142927.58908-1-yuehaibing@huawei.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
e5e42ad2 |
|
08-Jan-2020 |
YueHaibing <yuehaibing@huawei.com> |
gpiolib: remove set but not used variable 'config' drivers/gpio/gpiolib.c: In function gpio_set_config: drivers/gpio/gpiolib.c:3053:16: warning: variable config set but not used [-Wunused-but-set-variable] commit d90f36851d65 ("gpiolib: have a single place of calling set_config()") left behind this unused variable. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20200108121117.45060-1-yuehaibing@huawei.com Reviewed-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
c34f6dc8 |
|
14-Jan-2020 |
Stephen Boyd <swboyd@chromium.org> |
gpiolib: Set lockdep class for hierarchical irq domains I see the following lockdep splat in the qcom pinctrl driver when attempting to suspend the device. ============================================ WARNING: possible recursive locking detected 5.4.2 #2 Tainted: G S -------------------------------------------- cat/6536 is trying to acquire lock: ffffff814787ccc0 (&irq_desc_lock_class){-.-.}, at: __irq_get_desc_lock+0x64/0x94 but task is already holding lock: ffffff81436740c0 (&irq_desc_lock_class){-.-.}, at: __irq_get_desc_lock+0x64/0x94 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&irq_desc_lock_class); lock(&irq_desc_lock_class); *** DEADLOCK *** May be due to missing lock nesting notation 7 locks held by cat/6536: #0: ffffff8140e0c420 (sb_writers#7){.+.+}, at: vfs_write+0xc8/0x19c #1: ffffff8121eec480 (&of->mutex){+.+.}, at: kernfs_fop_write+0x128/0x1f4 #2: ffffff8147cad668 (kn->count#263){.+.+}, at: kernfs_fop_write+0x130/0x1f4 #3: ffffffd011446000 (system_transition_mutex){+.+.}, at: pm_suspend+0x108/0x354 #4: ffffff814302b970 (&dev->mutex){....}, at: __device_suspend+0x16c/0x420 #5: ffffff81436740c0 (&irq_desc_lock_class){-.-.}, at: __irq_get_desc_lock+0x64/0x94 #6: ffffff81479b8c10 (&pctrl->lock){....}, at: msm_gpio_irq_set_wake+0x48/0x7c stack backtrace: CPU: 4 PID: 6536 Comm: cat Tainted: G S 5.4.2 #2 Call trace: dump_backtrace+0x0/0x174 show_stack+0x20/0x2c dump_stack+0xdc/0x144 __lock_acquire+0x52c/0x2268 lock_acquire+0x1dc/0x220 _raw_spin_lock_irqsave+0x64/0x80 __irq_get_desc_lock+0x64/0x94 irq_set_irq_wake+0x40/0x144 msm_gpio_irq_set_wake+0x5c/0x7c set_irq_wake_real+0x40/0x5c irq_set_irq_wake+0x70/0x144 cros_ec_rtc_suspend+0x38/0x4c platform_pm_suspend+0x34/0x60 dpm_run_callback+0x64/0xcc __device_suspend+0x314/0x420 dpm_suspend+0xf8/0x298 dpm_suspend_start+0x84/0xb4 suspend_devices_and_enter+0xbc/0x628 pm_suspend+0x214/0x354 state_store+0xb0/0x108 kobj_attr_store+0x14/0x24 sysfs_kf_write+0x4c/0x64 kernfs_fop_write+0x158/0x1f4 __vfs_write+0x54/0x18c vfs_write+0xdc/0x19c ksys_write+0x7c/0xe4 __arm64_sys_write+0x20/0x2c el0_svc_common+0xa8/0x160 el0_svc_compat_handler+0x2c/0x38 el0_svc_compat+0x8/0x10 This is because the msm_gpio_irq_set_wake() function calls irq_set_irq_wake() as a backup in case the irq comes in during the path to idle. Given that we're calling irqchip functions from within an irqchip we need to set the lockdep class to be different for this child controller vs. the default one that the parent irqchip gets. This used to be done before this driver was converted to hierarchical irq domains in commit e35a6ae0eb3a ("pinctrl/msm: Setup GPIO chip in hierarchy") via the gpiochip_irq_map() function. With hierarchical irq domains this function has been replaced by gpiochip_hierarchy_irq_domain_alloc(). Therefore, set the lockdep class like was done previously in the irq domain path so we can avoid this lockdep warning. Fixes: fdd61a013a24 ("gpio: Add support for hierarchical IRQ domains") Cc: Thierry Reding <treding@nvidia.com> Cc: Brian Masney <masneyb@onstation.org> Cc: Lina Iyer <ilina@codeaurora.org> Cc: Marc Zyngier <maz@kernel.org> Cc: Maulik Shah <mkshah@codeaurora.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20200114231103.85641-1-swboyd@chromium.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
880b7cf2 |
|
14-Jan-2020 |
Kevin Hao <haokexin@gmail.com> |
gpiolib: Add the support for the msi parent domain If the gpio's parent irqdomain is a msi irqdomain, we should ignore the EEXIST error returned by the msi irqdomain because all the msi interrupts have already been allocated. Signed-off-by: Kevin Hao <haokexin@gmail.com> Link: https://lore.kernel.org/r/20200114082821.14015-4-haokexin@gmail.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
24258761 |
|
14-Jan-2020 |
Kevin Hao <haokexin@gmail.com> |
gpiolib: Add support for the irqdomain which doesn't use irq_fwspec as arg Some gpio's parent irqdomain may not use the struct irq_fwspec as argument, such as msi irqdomain. So rename the callback populate_parent_fwspec() to populate_parent_alloc_arg() and make it allocate and populate the specific struct which is needed by the parent irqdomain. Signed-off-by: Kevin Hao <haokexin@gmail.com> Link: https://lore.kernel.org/r/20200114082821.14015-3-haokexin@gmail.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
2a2cabd8 |
|
24-Dec-2019 |
Bartosz Golaszewski <bgolaszewski@baylibre.com> |
gpiolib: use gpiochip_get_desc() in gpio_ioctl() Unduplicate the offset check by simply calling gpiochip_get_desc() and checking its return value. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
|
#
45e23604 |
|
24-Dec-2019 |
Bartosz Golaszewski <bgolaszewski@baylibre.com> |
gpiolib: use gpiochip_get_desc() in lineevent_create() Unduplicate the ngpio check by simply calling gpiochip_get_desc() and checking its return value. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
|
#
0f41dabe |
|
24-Dec-2019 |
Bartosz Golaszewski <bgolaszewski@baylibre.com> |
gpiolib: use gpiochip_get_desc() in linehandle_create() Unduplicate the ngpio check by simply calling gpiochip_get_desc() and checking its return value. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
|
#
06863620 |
|
24-Dec-2019 |
Bartosz Golaszewski <bgolaszewski@baylibre.com> |
gpiolib: convert the type of hwnum to unsigned int in gpiochip_get_desc() gpiochip_get_desc() takes a u16 hwnum, but it turns out most users don't respect that and usually pass an unsigned int. Since implicit casting to a smaller type is dangerous - let's change the type of hwnum to unsigned int in gpiochip_get_desc() and in gpiochip_request_own_desc() where the size of hwnum is not respected either and who's a user of the former. This is safe as we then check the hwnum against the number of lines before proceeding in gpiochip_get_desc(). Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
|
#
d90f3685 |
|
24-Dec-2019 |
Bartosz Golaszewski <bgolaszewski@baylibre.com> |
gpiolib: have a single place of calling set_config() Instead of calling the gpiochip's set_config() callback directly and checking its existence every time - just add a new routine that performs this check internally. Call it in gpio_set_config() and gpiod_set_transitory(). Also call it in gpiod_set_debounce() and drop the check for chip->set() as it's irrelevant to this config option. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
|
#
a9001764 |
|
24-Dec-2019 |
Bartosz Golaszewski <bgolaszewski@baylibre.com> |
gpiolib: use 'unsigned int' instead of 'unsigned' in gpio_set_config() Checkpatch complains about using 'unsigned' instead of 'unsigned int'. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
|
#
2ddac5ae |
|
04-Jan-2020 |
Enrico Weigelt, metux IT consult <info@metux.net> |
gpio: gpiolib: fix confusing indention There's a confusing indention in gpiochip_add_data_with_key(), which could be misinterpreted on a quick walkthrough. Fixing this in order to improve code readability a bit. Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
d3a5bcb4 |
|
10-Dec-2019 |
Michał Mirosław <mirq-linux@rere.qmqm.pl> |
gpio: add gpiod_toggle_active_low() Add possibility to toggle active-low flag of a gpio descriptor. This is useful for compatibility code, where defaults are inverted vs DT gpio flags or the active-low flag is taken from elsewhere. Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Link: https://lore.kernel.org/r/7ce0338e01ad17fa5a227176813941b41a7c35c1.1576031637.git.mirq-linux@rere.qmqm.pl Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
#
4fc5bfeb |
|
04-Dec-2019 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Make use of assign_bit() API We have for some time the assign_bit() API to replace open coded if (foo) set_bit(n, bar); else clear_bit(n, bar); Use this API in GPIO library code. No functional change intended. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20191204194229.64251-2-andriy.shevchenko@linux.intel.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
ddd8891e |
|
27-Nov-2019 |
Geert Uytterhoeven <geert+renesas@glider.be> |
gpiolib: Add GPIOCHIP_NAME definition The string literal "gpiochip" is used in several places. Add a definition for it, and use it everywhere, to make sure everything stays in sync. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20191127084253.16356-2-geert+renesas@glider.be Reviewed-by: Ulrich Hecht <uli+renesas@fpond.eu> Reviewed-by: Eugeniu Rosca <erosca@de.adit-jv.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
256efaea |
|
07-Dec-2019 |
Russell King <rmk+kernel@armlinux.org.uk> |
gpiolib: fix up emulated open drain outputs gpiolib has a corner case with open drain outputs that are emulated. When such outputs are outputting a logic 1, emulation will set the hardware to input mode, which will cause gpiod_get_direction() to report that it is in input mode. This is different from the behaviour with a true open-drain output. Unify the semantics here. Cc: <stable@vger.kernel.org> Suggested-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
d935bd50 |
|
27-Nov-2019 |
Geert Uytterhoeven <geert+renesas@glider.be> |
gpio: Fix error message on out-of-range GPIO in lookup table When a GPIO offset in a lookup table is out-of-range, the printed error message (1) does not include the actual out-of-range value, and (2) contains an off-by-one error in the upper bound. Avoid user confusion by also printing the actual GPIO offset, and correcting the upper bound of the range. While at it, use "%u" for unsigned int. Sample impact: -requested GPIO 0 is out of range [0..32] for chip e6052000.gpio +requested GPIO 0 (45) is out of range [0..31] for chip e6052000.gpio Fixes: 2a3cf6a3599e9015 ("gpiolib: return -ENOENT if no GPIO mapping exists") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20191127095919.4214-1-geert+renesas@glider.be Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
51158416 |
|
20-Nov-2019 |
Geert Uytterhoeven <geert+renesas@glider.be> |
gpiolib: Grammar s/manager/managed/ Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20191120143745.1254-1-geert+renesas@glider.be Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
b27f300f |
|
13-Nov-2019 |
Bartosz Golaszewski <bgolaszewski@baylibre.com> |
gpiolib: fix coding style in gpiod_hog() There should be spaces between logical operators and their operands. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
b056ca1c |
|
04-Nov-2019 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Introduce ->add_pin_ranges() callback When IRQ chip is being added by GPIO library, the ACPI based platform expects GPIO <-> pin mapping ranges to be initialized in order to correctly initialize ACPI event mechanism on affected platforms. Unfortunately this step is missed. Introduce ->add_pin_ranges() callback to fill the above mentioned gap. 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> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Tested-by: Hans de Goede <hdegoede@redhat.com>
|
#
e588bb1e |
|
04-Nov-2019 |
Kent Gibson <warthog618@gmail.com> |
gpio: add new SET_CONFIG ioctl() to gpio chardev Add the GPIOHANDLE_SET_CONFIG_IOCTL to the gpio chardev. The ioctl allows some of the configuration of a requested handle to be changed without having to release the line. The primary use case is the changing of direction for bi-directional lines. Based on initial work by Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Kent Gibson <warthog618@gmail.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
b043ed7e |
|
04-Nov-2019 |
Kent Gibson <warthog618@gmail.com> |
gpiolib: move validation of line handle flags into helper function Move validation of line handle flags into helper function. This reduces the size and complexity of linehandle_create and allows the validation to be reused elsewhere. Signed-off-by: Kent Gibson <warthog618@gmail.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
2821ae5f |
|
04-Nov-2019 |
Kent Gibson <warthog618@gmail.com> |
gpiolib: add support for biasing output lines Allow pull up/down bias to be set on output lines. Use case is for open source or open drain applications where internal pull up/down may conflict with external biasing. Signed-off-by: Kent Gibson <warthog618@gmail.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
2148ad77 |
|
04-Nov-2019 |
Kent Gibson <warthog618@gmail.com> |
gpiolib: add support for disabling line bias Allow pull up/down bias to be disabled, allowing the line to float or to be biased only by external circuitry. Use case is for where the bias has been applied previously, either by default or by the user, but that setting may conflict with the current use of the line. Signed-off-by: Kent Gibson <warthog618@gmail.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
7b479a84 |
|
04-Nov-2019 |
Kent Gibson <warthog618@gmail.com> |
gpiolib: add support for pull up/down to lineevent_create Add support for pull up/down to lineevent_create. Use cases include receiving asynchronous presses from a push button without an external pull up/down. Signed-off-by: Kent Gibson <warthog618@gmail.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
9225d516 |
|
04-Nov-2019 |
Drew Fustini <drew@pdp7.com> |
gpio: expose pull-up/pull-down line flags to userspace Add pull-up/pull-down flags to the gpio line get and set ioctl() calls. Use cases include a push button that does not have an external resistor. Addition use cases described by Limor Fried (ladyada) of Adafruit in this PR for Adafruit_Blinka Python lib: https://github.com/adafruit/Adafruit_Blinka/pull/59 Signed-off-by: Drew Fustini <drew@pdp7.com> [Kent: added BIAS to GPIO flag names and restrict application to input lines] Signed-off-by: Kent Gibson <warthog618@gmail.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
70d97e09 |
|
08-Nov-2019 |
Linus Walleij <linus.walleij@linaro.org> |
Revert "gpio: expose pull-up/pull-down line flags to userspace" This reverts commit 8c550e94b8835170593169a45b5ba30d3fc72a70. This was prematurely applied and we need to back it out to merge a better version of the development track for this feature. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
2f4133bb |
|
05-Nov-2019 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: No need to call gpiochip_remove_pin_ranges() twice 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: e93fa3f24353 ("gpiolib: remove duplicate pin range code") Depends-on: f7299d441a4d ("gpio: of: Fix of_gpiochip_add() error path") Cc: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
504369cd |
|
30-Oct-2019 |
Linus Walleij <linus.walleij@linaro.org> |
gpiolib: Switch order of valid mask and hw init The GPIO irqchip needs to initialize the valid mask before initializing the IRQ hardware, because sometimes the latter require the former to be executed first. Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Mika Westerberg <mika.westerberg@linux.intel.com> Reported-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20191030122914.967-1-linus.walleij@linaro.org Acked-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
9411e3aa |
|
09-Oct-2019 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Initialize the hardware with a callback 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 <hdegoede@redhat.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
8c550e94 |
|
20-Sep-2019 |
Drew Fustini <drew@pdp7.com> |
gpio: expose pull-up/pull-down line flags to userspace Add pull-up/pull-down flags to the gpio line get and set ioctl() calls. Use cases include a push button that does not have an external resistor. Addition use cases described by Limor Fried (ladyada) of Adafruit in this PR for Adafruit_Blinka Python lib: https://github.com/adafruit/Adafruit_Blinka/pull/59 Signed-off-by: Drew Fustini <drew@pdp7.com> Link: https://lore.kernel.org/r/20190921102522.8970-1-drew@pdp7.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
13949fa9 |
|
12-Sep-2019 |
Dmitry Torokhov <dmitry.torokhov@gmail.com> |
gpiolib: introduce fwnode_gpiod_get_index() This introduces fwnode_gpiod_get_index() that iterates through common gpio suffixes when trying to locate a GPIO within a given firmware node. We also switch devm_fwnode_gpiod_get_index() to call fwnode_gpiod_get_index() instead of iterating through GPIO suffixes on its own. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Link: https://lore.kernel.org/r/20190913032240.50333-3-dmitry.torokhov@gmail.com Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
bcc6d99a |
|
16-Sep-2019 |
Bartosz Golaszewski <bgolaszewski@baylibre.com> |
gpiolib: sanitize flags before allocating memory in lineevent_create() Move all the flags sanitization before any memory allocation in lineevent_create() in order to remove a couple unneeded gotos. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
e735244e |
|
01-Oct-2019 |
Bartosz Golaszewski <bgolaszewski@baylibre.com> |
gpiolib: don't clear FLAG_IS_OUT when emulating open-drain/open-source When emulating open-drain/open-source by not actively driving the output lines - we're simply changing their mode to input. This is wrong as it will then make it impossible to change the value of such line - it's now considered to actually be in input mode. If we want to still use the direction_input() callback for simplicity then we need to set FLAG_IS_OUT manually in gpiod_direction_output() and not clear it in gpio_set_open_drain_value_commit() and gpio_set_open_source_value_commit(). Fixes: c663e5f56737 ("gpio: support native single-ended hardware drivers") Cc: stable@vger.kernel.org Reported-by: Kent Gibson <warthog618@gmail.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
2efc6bfa |
|
07-Sep-2019 |
Saiyam Doshi <saiyamdoshi.in@gmail.com> |
gpio: remove explicit comparison with 0 No need to compare return value with 0. In case of non-zero return value, the if condition will be true. This makes intent a bit more clear to the reader. "if (x) then", compared to "if (x is not zero) then". Signed-off-by: Saiyam Doshi <saiyamdoshi.in@gmail.com> Link: https://lore.kernel.org/r/20190907173910.GA9547@SD Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
5fbe5b58 |
|
04-Sep-2019 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: Initialize the irqchip valid_mask with a callback 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 <joel@jms.id.au> Cc: Thierry Reding <treding@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andrew Jeffery <andrew@aj.id.au> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Patrice Chotard <patrice.chotard@st.com> Link: https://lore.kernel.org/r/20190904140104.32426-1-linus.walleij@linaro.org
|
#
5ca2f54b |
|
08-Sep-2019 |
Kent Gibson <warthog618@gmail.com> |
gpio: fix line flag validation in lineevent_create lineevent_create should not allow any of GPIOHANDLE_REQUEST_OUTPUT, GPIOHANDLE_REQUEST_OPEN_DRAIN or GPIOHANDLE_REQUEST_OPEN_SOURCE to be set. Fixes: d7c51b47ac11 ("gpio: userspace ABI for reading/writing GPIO lines") Cc: stable <stable@vger.kernel.org> Signed-off-by: Kent Gibson <warthog618@gmail.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
e95fbc13 |
|
08-Sep-2019 |
Kent Gibson <warthog618@gmail.com> |
gpio: fix line flag validation in linehandle_create linehandle_create should not allow both GPIOHANDLE_REQUEST_INPUT and GPIOHANDLE_REQUEST_OUTPUT to be set. Fixes: d7c51b47ac11 ("gpio: userspace ABI for reading/writing GPIO lines") Cc: stable <stable@vger.kernel.org> Signed-off-by: Kent Gibson <warthog618@gmail.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
fbdf8d4b |
|
05-Sep-2019 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: Fix further merge errors The previous merge of v5.3-rc7 was struggle enough, now it gave rise to new errors and now I fix those too. Fixes: 151a41014bff ("Merge tag 'v5.3-rc7' into devel") Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
d377f56f |
|
16-Jul-2019 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: gpiolib: Normalize return code variable name It is confusing to name return variables mixedly "status", "err" or "ret". I just changed them all to "ret", by personal preference, to lower cognitive stress. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20190716091145.8235-1-linus.walleij@linaro.org
|
#
472a61e7 |
|
14-Aug-2019 |
Stefan Wahren <stefan.wahren@i2se.com> |
pinctrl/gpio: Take MUX usage into account The user space like gpioinfo only see the GPIO usage but not the MUX usage (e.g. I2C or SPI usage) of a pin. As a user we want to know which pin is free/safe to use. So take the MUX usage of strict pinmux controllers into account to get a more realistic view for ioctl GPIO_GET_LINEINFO_IOCTL. Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Ramon Fried <rfried.dev@gmail.com> Link: https://lore.kernel.org/r/20190814110035.13451-1-ramon.fried@linux.intel.com Acked-by: Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
48057ed1 |
|
20-Aug-2019 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: Fix irqchip initialization order The new API for registering a gpio_irq_chip along with a gpio_chip has a different semantic ordering than the old API which added the irqchip explicitly after registering the gpio_chip. Move the calls to add the gpio_irq_chip *last* in the function, so that the different hooks setting up OF and ACPI and machine gpio_chips are called *before* we try to register the interrupts, preserving the elder semantic order. This cropped up in the PL061 driver which used to work fine with no special ACPI quirks, but started to misbehave using the new API. Fixes: e0d897289813 ("gpio: Implement tighter IRQ chip integration") Cc: Thierry Reding <treding@nvidia.com> Cc: Grygorii Strashko <grygorii.strashko@ti.com> Cc: Andy Shevchenko <andy.shevchenko@gmail.com> Reported-by: Wei Xu <xuwei5@hisilicon.com> Tested-by: Wei Xu <xuwei5@hisilicon.com> Reported-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20190820080527.11796-1-linus.walleij@linaro.org
|
#
eb1e8bd6 |
|
19-Aug-2019 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: Use callback presence to determine need of valid_mask 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 <benjamin.gaignard@st.com> Cc: Amelie Delaunay <amelie.delaunay@st.com> Cc: Stephen Boyd <swboyd@chromium.org> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20190819093058.10863-1-linus.walleij@linaro.org
|
#
c9fc5aff |
|
19-Aug-2019 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: Pass mask and size with the init_valid_mask() 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 <swboyd@chromium.org> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20190819084904.30027-1-linus.walleij@linaro.or Reviewed-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
fdd61a01 |
|
08-Aug-2019 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: Add support for hierarchical IRQ domains 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: Thierry Reding <treding@nvidia.com> Signed-off-by: Brian Masney <masneyb@onstation.org> Co-developed-by: Brian Masney <masneyb@onstation.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20190808123242.5359-1-linus.walleij@linaro.org
|
#
2c60e6b5 |
|
06-Aug-2019 |
Bartosz Golaszewski <bgolaszewski@baylibre.com> |
gpiolib: never report open-drain/source lines as 'input' to user-space If the driver doesn't support open-drain/source config options, we emulate this behavior when setting the direction by calling gpiod_direction_input() if the default value is 0 (open-source) or 1 (open-drain), thus not actively driving the line in those cases. This however clears the FLAG_IS_OUT bit for the GPIO line descriptor and makes the LINEINFO ioctl() incorrectly report this line's mode as 'input' to user-space. This commit modifies the ioctl() to always set the GPIOLINE_FLAG_IS_OUT bit in the lineinfo structure's flags field. Since it's impossible to use the input mode and open-drain/source options at the same time, we can be sure the reported information will be correct. Fixes: 521a2ad6f862 ("gpio: add userspace ABI for GPIO line information") Cc: stable <stable@vger.kernel.org> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Link: https://lore.kernel.org/r/20190806114151.17652-1-brgl@bgdev.pl Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
7bdbd1ec |
|
18-Jul-2019 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
gpio: refactor gpiochip_allocate_mask() with bitmap_alloc() Refactor gpiochip_allocate_mask() slightly by using bitmap_alloc(). I used bitmap_free() for the corresponding free parts. Actually, bitmap_free() is a wrapper of kfree(), but I did this for consistency. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Link: https://lore.kernel.org/r/20190718065101.26994-1-yamada.masahiro@socionext.com Reviewed-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
49281a22 |
|
31-Jul-2019 |
Stephen Boyd <swboyd@chromium.org> |
gpio: of: Fix hard-assigned valid_mask for OF case The recent refactoring to break out OF code to its own file contained a bug letting the need_valid_mask be overridden by the need of the device tree range check, and if there were no ranges, but device tree was active and the reserved GPIO used in another way, things likely crash. Cc: Mark Brown <broonie@kernel.org> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Stephen Boyd <swboyd@chromium.org> Fixes: f626d6dfb709 ("gpio: of: Break out OF-only code") Reported-by: Mark Brown <broonie@kernel.org> Suggested-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
77cb907a |
|
30-Jul-2019 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: acpi: Split ACPI stuff to gpiolib-acpi.h This is a follow up to the commit f626d6dfb709 ("gpio: of: Break out OF-only code") which broke down OF parts of GPIO library. Here we do the similar to ACPI. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20190730104337.21235-2-andriy.shevchenko@linux.intel.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
d95da993 |
|
07-Jul-2019 |
Chris Packham <chris.packham@alliedtelesis.co.nz> |
gpiolib: Preserve desc->flags when setting state desc->flags may already have values set by of_gpiochip_add() so make sure that this isn't undone when setting the initial direction. Cc: stable@vger.kernel.org Fixes: 3edfb7bd76bd1cba ("gpiolib: Show correct direction from the beginning") Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Link: https://lore.kernel.org/r/20190707203558.10993-1-chris.packham@alliedtelesis.co.nz Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
f626d6df |
|
17-Jul-2019 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: of: Break out OF-only code The core gpiolib should not contain any OF/device tree-only code. Try to break out the main part of it and push it down into the optional gpiolib-of.c part of the library. Create a local gpiolib-of.h header and move stuff around a bit to get a clean cut. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20190717071001.3858-1-linus.walleij@linaro.org
|
#
223ecaf1 |
|
07-Jul-2019 |
Michael Wu <michael.wu@vatics.com> |
gpiolib: fix incorrect IRQ requesting of an active-low lineevent 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: Michael Wu <michael.wu@vatics.com> Tested-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
827a9b8b |
|
01-Jul-2019 |
Geert Uytterhoeven <geert+renesas@glider.be> |
gpiolib: Clarify use of non-sleeping functions Obviously functions that are safe to be called from atomic contexts, can be called from non-atomic contexts, too. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20190701142809.25308-1-geert+renesas@glider.be Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
3285170f |
|
01-Jul-2019 |
Geert Uytterhoeven <geert+renesas@glider.be> |
gpiolib: Fix references to gpiod_[gs]et_*value_cansleep() variants Commit 372e722ea4dd4ca1 ("gpiolib: use descriptors internally") renamed the functions to use a "gpiod" prefix, and commit 79a9becda8940deb ("gpiolib: export descriptor-based GPIO interface") introduced the "raw" variants, but both changes forgot to update the comments. Readd a similar reference to gpiod_set_value(), which was accidentally removed by commit 1e77fc82110ac36f ("gpio: Add missing open drain/source handling to gpiod_set_value_cansleep()"). Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20190701142738.25219-1-geert+renesas@glider.be Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
acc68b0e |
|
18-Jun-2019 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
gpio: No need to cast away return value of debugfs_create_file() It is fine to ignore the return value (and encouraged), so need to cast away the return value, you will not get a build warning at all. Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com> Cc: linux-gpio@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
025bf377 |
|
20-Jun-2019 |
Waibel Georg <Georg.Waibel@sensor-technik.de> |
gpio: Fix return value mismatch of function gpiod_get_from_of_node() 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: Georg Waibel <georg.waibel@sensor-technik.de> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
4892d3a6 |
|
14-Jun-2019 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: Drop the parent_irq from gpio_irq_chip We already have an array named "parents" so instead of letting one point to the other, simply allocate a dynamic array to hold the parents, just one if desired and drop the number of members in gpio_irq_chip by 1. Rename gpiochip to gc in the process. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
5923ea6c |
|
26-Apr-2019 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: pass lookup and descriptor flags to request_own When a gpio_chip wants to request a descriptor from itself using gpiochip_request_own_desc() it needs to be able to specify fully how to use the descriptor, notably line inversion semantics. The workaround in the gpiolib.c can be removed and cases (such as SPI CS) where we need at times to request a GPIO with line inversion semantics directly on a chip for workarounds, can be fully supported with this call. Fix up some users of the API that weren't really using the last flag to set up the line as input or output properly but instead just calling direction setting explicitly after requesting the line. Cc: Martin Sperl <kernel@martin.sperl.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
35779890 |
|
24-Apr-2019 |
Geert Uytterhoeven <geert+renesas@glider.be> |
gpio: Fix gpiochip_add_data_with_key() error path The err_remove_chip block is too coarse, and may perform cleanup that must not be done. E.g. if of_gpiochip_add() fails, of_gpiochip_remove() is still called, causing: OF: ERROR: Bad of_node_put() on /soc/gpio@e6050000 CPU: 1 PID: 20 Comm: kworker/1:1 Not tainted 5.1.0-rc2-koelsch+ #407 Hardware name: Generic R-Car Gen2 (Flattened Device Tree) Workqueue: events deferred_probe_work_func [<c020ec74>] (unwind_backtrace) from [<c020ae58>] (show_stack+0x10/0x14) [<c020ae58>] (show_stack) from [<c07c1224>] (dump_stack+0x7c/0x9c) [<c07c1224>] (dump_stack) from [<c07c5a80>] (kobject_put+0x94/0xbc) [<c07c5a80>] (kobject_put) from [<c0470420>] (gpiochip_add_data_with_key+0x8d8/0xa3c) [<c0470420>] (gpiochip_add_data_with_key) from [<c0473738>] (gpio_rcar_probe+0x1d4/0x314) [<c0473738>] (gpio_rcar_probe) from [<c052fca8>] (platform_drv_probe+0x48/0x94) and later, if a GPIO consumer tries to use a GPIO from a failed controller: WARNING: CPU: 0 PID: 1 at lib/refcount.c:156 kobject_get+0x38/0x4c refcount_t: increment on 0; use-after-free. Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.1.0-rc2-koelsch+ #407 Hardware name: Generic R-Car Gen2 (Flattened Device Tree) [<c020ec74>] (unwind_backtrace) from [<c020ae58>] (show_stack+0x10/0x14) [<c020ae58>] (show_stack) from [<c07c1224>] (dump_stack+0x7c/0x9c) [<c07c1224>] (dump_stack) from [<c0221580>] (__warn+0xd0/0xec) [<c0221580>] (__warn) from [<c02215e0>] (warn_slowpath_fmt+0x44/0x6c) [<c02215e0>] (warn_slowpath_fmt) from [<c07c58fc>] (kobject_get+0x38/0x4c) [<c07c58fc>] (kobject_get) from [<c068b3ec>] (of_node_get+0x14/0x1c) [<c068b3ec>] (of_node_get) from [<c0686f24>] (of_find_node_by_phandle+0xc0/0xf0) [<c0686f24>] (of_find_node_by_phandle) from [<c0686fbc>] (of_phandle_iterator_next+0x68/0x154) [<c0686fbc>] (of_phandle_iterator_next) from [<c0687fe4>] (__of_parse_phandle_with_args+0x40/0xd0) [<c0687fe4>] (__of_parse_phandle_with_args) from [<c0688204>] (of_parse_phandle_with_args_map+0x100/0x3ac) [<c0688204>] (of_parse_phandle_with_args_map) from [<c0471240>] (of_get_named_gpiod_flags+0x38/0x380) [<c0471240>] (of_get_named_gpiod_flags) from [<c046f864>] (gpiod_get_from_of_node+0x24/0xd8) [<c046f864>] (gpiod_get_from_of_node) from [<c0470aa4>] (devm_fwnode_get_index_gpiod_from_child+0xa0/0x144) [<c0470aa4>] (devm_fwnode_get_index_gpiod_from_child) from [<c05f425c>] (gpio_keys_probe+0x418/0x7bc) [<c05f425c>] (gpio_keys_probe) from [<c052fca8>] (platform_drv_probe+0x48/0x94) Fix this by splitting the cleanup block, and adding a missing call to gpiochip_irqchip_remove(). Fixes: 28355f81969962cf ("gpio: defer probe if pinctrl cannot be found") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Mukesh Ojha <mojha@codeaurora.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
606be344 |
|
10-Apr-2019 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: acpi: Add acpi_gpio_update_gpiod_lookup_flags() helper This helper consolidates all settings of GPIO descriptor lookup flags and quirks in the future if any. No functional change intended. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
2d6c06f5 |
|
10-Apr-2019 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Introduce GPIO_LOOKUP_FLAGS_DEFAULT Since GPIO library operates with enumerator when it's subject to handle the GPIO lookup flags, it will be better to clearly see what default means. Thus, introduce GPIO_LOOKUP_FLAGS_DEFAULT entry to describe the default assumptions. While here, replace 0 by newly introduced constant. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
fed7026a |
|
10-Apr-2019 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Make use of enum gpio_lookup_flags consistent The library uses enum gpio_lookup_flags to define the possible characteristics of GPIO pin. Since enumerator listed only individual bits the common use of it is in a form of a bitmask of gpio_lookup_flags GPIO_* values. The more correct type for this is unsigned long. Due to above convert all users to use unsigned long instead of enum gpio_lookup_flags except enumerator definition. While here, make field and parameter descriptions consistent as well. Suggested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
542f3615 |
|
14-Mar-2019 |
Maxime Ripard <mripard@kernel.org> |
gpio: Set proper argument value to set_config The gpio_set_config function creates a pinconf configuration for a given pinc_config_param. However, it always uses an arg of 0, which might not be a valid argument for a given param. A good example of that would be the bias parameters, where 0 means that the pull up or down resistor is null, and the pin is directly connected to VCC/GND. The framework uses in some other places the value 1 as a default argument to enable the pull resistor, so let's use the same one here. Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
7e9fa3c9 |
|
28-Mar-2019 |
Geert Uytterhoeven <geert+renesas@glider.be> |
gpio: Remove obsolete comment about gpiochip_free_hogs() usage gpiochip_free_hogs() was always called from gpiochip_remove(), not of_gpiochip_remove(). It is now also called from the failure patch in gpiochip_add_data_with_key(). Fixes: f625d4601759f1cf ("gpio: add GPIO hogging mechanism") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
1d7765ba |
|
26-Mar-2019 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Don't WARN on gpiod_put() for optional GPIO In case of debug and optional GPIO requested, the gpiod_put() is not aware of and will WARN, which is not the case. Make gpiod_put() NULL-aware to keep silent for optional GPIOs. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
fa59dd23 |
|
25-Mar-2019 |
Andrew Jeffery <andrew@aj.id.au> |
Revert "gpio: use new gpio_set_config() helper in more places" gpio-aspeed implements support for PIN_CONFIG_INPUT_DEBOUNCE. As of v5.1-rc1 we're seeing the following when booting a Romulus BMC kernel: > [ 21.373137] ------------[ cut here ]------------ > [ 21.374545] WARNING: CPU: 0 PID: 1 at drivers/gpio/gpio-aspeed.c:834 unregister_allocated_timer+0x38/0x94 > [ 21.376181] No timer allocated to offset 74 > [ 21.377672] CPU: 0 PID: 1 Comm: swapper Not tainted 5.1.0-rc1-dirty #6 > [ 21.378800] Hardware name: Generic DT based system > [ 21.379965] Backtrace: > [ 21.381024] [<80107d44>] (dump_backtrace) from [<80107f78>] (show_stack+0x20/0x24) > [ 21.382713] r7:8038b720 r6:00000009 r5:00000000 r4:87897c64 > [ 21.383815] [<80107f58>] (show_stack) from [<80656398>] (dump_stack+0x20/0x28) > [ 21.385042] [<80656378>] (dump_stack) from [<80115f1c>] (__warn.part.3+0xb4/0xdc) > [ 21.386253] [<80115e68>] (__warn.part.3) from [<80115fb0>] (warn_slowpath_fmt+0x6c/0x90) > [ 21.387471] r6:00000342 r5:807f8758 r4:80a07008 > [ 21.388278] [<80115f48>] (warn_slowpath_fmt) from [<8038b720>] (unregister_allocated_timer+0x38/0x94) > [ 21.389809] r3:0000004a r2:807f8774 > [ 21.390526] r7:00000000 r6:0000000a r5:60000153 r4:0000004a > [ 21.391601] [<8038b6e8>] (unregister_allocated_timer) from [<8038baac>] (aspeed_gpio_set_config+0x330/0x48c) > [ 21.393248] [<8038b77c>] (aspeed_gpio_set_config) from [<803840b0>] (gpiod_set_debounce+0xe8/0x114) > [ 21.394745] r10:82ee2248 r9:00000000 r8:87b63a00 r7:00001388 r6:87947320 r5:80729310 > [ 21.396030] r4:879f64a0 > [ 21.396499] [<80383fc8>] (gpiod_set_debounce) from [<804b4350>] (gpio_keys_probe+0x69c/0x8e0) > [ 21.397715] r7:845d94b8 r6:00000001 r5:00000000 r4:87b63a1c > [ 21.398618] [<804b3cb4>] (gpio_keys_probe) from [<8040eeec>] (platform_dev_probe+0x44/0x80) > [ 21.399834] r10:00000003 r9:80a3a8b0 r8:00000000 r7:00000000 r6:80a7f9dc r5:80a3a8b0 > [ 21.401163] r4:8796bc10 > [ 21.401634] [<8040eea8>] (platform_drv_probe) from [<8040d0d4>] (really_probe+0x208/0x3dc) > [ 21.402786] r5:80a7f8d0 r4:8796bc10 > [ 21.403547] [<8040cecc>] (really_probe) from [<8040d7a4>] (driver_probe_device+0x130/0x170) > [ 21.404744] r10:0000007b r9:8093683c r8:00000000 r7:80a07008 r6:80a3a8b0 r5:8796bc10 > [ 21.405854] r4:80a3a8b0 > [ 21.406324] [<8040d674>] (driver_probe_device) from [<8040da8c>] (device_driver_attach+0x68/0x70) > [ 21.407568] r9:8093683c r8:00000000 r7:80a07008 r6:80a3a8b0 r5:00000000 r4:8796bc10 > [ 21.408877] [<8040da24>] (device_driver_attach) from [<8040db14>] (__driver_attach+0x80/0x150) > [ 21.410327] r7:80a07008 r6:8796bc10 r5:00000001 r4:80a3a8b0 > [ 21.411294] [<8040da94>] (__driver_attach) from [<8040b20c>] (bus_for_each_dev+0x80/0xc4) > [ 21.412641] r7:80a07008 r6:8040da94 r5:80a3a8b0 r4:87966f30 > [ 21.413580] [<8040b18c>] (bus_for_each_dev) from [<8040dc0c>] (driver_attach+0x28/0x30) > [ 21.414943] r7:00000000 r6:87b411e0 r5:80a33fc8 r4:80a3a8b0 > [ 21.415927] [<8040dbe4>] (driver_attach) from [<8040bbf0>] (bus_add_driver+0x14c/0x200) > [ 21.417289] [<8040baa4>] (bus_add_driver) from [<8040e2b4>] (driver_register+0x84/0x118) > [ 21.418652] r7:80a60ae0 r6:809226b8 r5:80a07008 r4:80a3a8b0 > [ 21.419652] [<8040e230>] (driver_register) from [<8040fc28>] (__platform_driver_register+0x3c/0x50) > [ 21.421193] r5:80a07008 r4:809525f8 > [ 21.421990] [<8040fbec>] (__platform_driver_register) from [<809226d8>] (gpio_keys_init+0x20/0x28) > [ 21.423447] [<809226b8>] (gpio_keys_init) from [<8090128c>] (do_one_initcall+0x80/0x180) > [ 21.424886] [<8090120c>] (do_one_initcall) from [<80901538>] (kernel_init_freeable+0x1ac/0x26c) > [ 21.426354] r8:80a60ae0 r7:80a60ae0 r6:8093685c r5:00000008 r4:809525f8 > [ 21.427579] [<8090138c>] (kernel_init_freeable) from [<8066d9a0>] (kernel_init+0x18/0x11c) > [ 21.428819] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:8066d988 > [ 21.429947] r4:00000000 > [ 21.430415] [<8066d988>] (kernel_init) from [<801010e8>] (ret_from_fork+0x14/0x2c) > [ 21.431666] Exception stack(0x87897fb0 to 0x87897ff8) > [ 21.432877] 7fa0: 00000000 00000000 00000000 00000000 > [ 21.434446] 7fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > [ 21.436052] 7fe0: 00000000 00000000 00000000 00000000 00000013 00000000 > [ 21.437308] r5:8066d988 r4:00000000 > [ 21.438102] ---[ end trace d7d7ac3a80567d0e ]--- We only hit unregister_allocated_timer() if the argument to aspeed_gpio_set_config() is 0, but we can't be calling through gpiod_set_debounce() from gpio_keys_probe() unless the gpio-keys button has a non-zero debounce interval. Commit 6581eaf0e890 ("gpio: use new gpio_set_config() helper in more places") spreads the use of gpio_set_config() to the debounce and transitory state configuration paths. The implementation of gpio_set_config() is: > static int gpio_set_config(struct gpio_chip *gc, unsigned offset, > enum pin_config_param mode) > { > unsigned long config = { PIN_CONF_PACKED(mode, 0) }; > > return gc->set_config ? gc->set_config(gc, offset, config) : -ENOTSUPP; > } Here it packs its own config value with a fixed argument of 0; this is incorrect behaviour for implementing the debounce and transitory functions, and the debounce and transitory gpio_set_config() call-sites now have an undetected type mismatch as they both already pack their own config parameter (i.e. what gets passed is not an `enum pin_config_param`). Indeed this can be seen in the small diff for 6581eaf0e890: > diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c > index de595fa31a1a..1f239aac43df 100644 > --- a/drivers/gpio/gpiolib.c > +++ b/drivers/gpio/gpiolib.c > @@ -2725,7 +2725,7 @@ int gpiod_set_debounce(struct gpio_desc *desc, unsigned debounce) > } > > config = pinconf_to_config_packed(PIN_CONFIG_INPUT_DEBOUNCE, debounce); > - return chip->set_config(chip, gpio_chip_hwgpio(desc), config); > + return gpio_set_config(chip, gpio_chip_hwgpio(desc), config); > } > EXPORT_SYMBOL_GPL(gpiod_set_debounce); > > @@ -2762,7 +2762,7 @@ int gpiod_set_transitory(struct gpio_desc *desc, bool transitory) > packed = pinconf_to_config_packed(PIN_CONFIG_PERSIST_STATE, > !transitory); > gpio = gpio_chip_hwgpio(desc); > - rc = chip->set_config(chip, gpio, packed); > + rc = gpio_set_config(chip, gpio, packed); > if (rc == -ENOTSUPP) { > dev_dbg(&desc->gdev->dev, "Persistence not supported for GPIO %d\n", > gpio); Revert commit 6581eaf0e890 ("gpio: use new gpio_set_config() helper in more places") to restore correct behaviour for gpiod_set_debounce() and gpiod_set_transitory(). Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
d449991c |
|
07-Feb-2019 |
Thomas Petazzoni <thomas.petazzoni@bootlin.com> |
gpio: add core support for pull-up/pull-down configuration 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: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
6581eaf0 |
|
07-Feb-2019 |
Thomas Petazzoni <thomas.petazzoni@bootlin.com> |
gpio: use new gpio_set_config() helper in more places As suggested by Linus Walleij, let's use the new gpio_set_config() helper in gpiod_set_debounce() and gpiod_set_transitory(). Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
71479789 |
|
07-Feb-2019 |
Thomas Petazzoni <thomas.petazzoni@bootlin.com> |
gpio: rename gpio_set_drive_single_ended() to gpio_set_config() This commit simply renames gpio_set_drive_single_ended() to gpio_set_config(), as the function is not specific to setting the GPIO drive type, and will be used for other purposes in followup commits. In addition, it moves the function above gpiod_direction_input(), as it will be used from gpiod_direction_input(). Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
ef74f70e |
|
19-Jan-2019 |
Brian Masney <masneyb@onstation.org> |
gpio: add irq domain activate/deactivate functions This adds the two new functions gpiochip_irq_domain_activate and gpiochip_irq_domain_deactivate that can be used as the activate and deactivate functions in the struct irq_domain_ops. This is for situations where only gpiochip_{lock,unlock}_as_irq needs to be called. SPMI and SSBI GPIO are two users that will initially use these functions. Signed-off-by: Brian Masney <masneyb@onstation.org> Suggested-by: Stephen Boyd <sboyd@kernel.org> Reviewed-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
1033be58 |
|
04-Jan-2019 |
Bartosz Golaszewski <bgolaszewski@baylibre.com> |
gpiolib: fix line event timestamps for nested irqs Nested interrupts run inside the calling thread's context and the top half handler is never called which means that we never read the timestamp. This issue came up when trying to read line events from a gpiochip using regmap_irq_chip for interrupts. Fix it by reading the timestamp from the irq thread function if it's still 0 by the time the second handler is called. Fixes: d58f2bf261fd ("gpio: Timestamp events in hardirq handler") Cc: stable@vger.kernel.org Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
|
#
21abf103 |
|
04-Sep-2018 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: Pass a flag to gpiochip_request_own_desc() Before things go out of hand, make it possible to pass flags when requesting "own" descriptors from a gpio_chip. This is necessary if the chip wants to request a GPIO with active low semantics, for example. Cc: Janusz Krzysztofik <jmkrzyszt@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Roger Quadros <rogerq@ti.com> Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
ec757001 |
|
06-Dec-2018 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: Enable nonexclusive gpiods from DT nodes This makes gpiod_get_from_of_node() respect the GPIOD_FLAGS_BIT_NONEXCLUSIVE flag which is especially nice when getting regulator GPIOs right out of device tree nodes. Suggested-by: Marek Szyprowski <m.szyprowski@samsung.com> Fixes: b0ce7b29bfcd ("regulator/gpio: Allow nonexclusive GPIO access") Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
0696d794 |
|
07-Nov-2018 |
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> |
gpio: drop devm_gpio_chip_match() Commit 48207d7595d2 ("gpio: drop devm_gpiochip_remove()") dropped the last user of drop devm_gpio_chip_match(), causing a defined but not used compilation warning. Fix it by removing the function. Fixes: 48207d7595d2 ("gpio: drop devm_gpiochip_remove()") Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Olof Johansson <olof@lixom.net> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
a05a1404 |
|
02-Nov-2018 |
Vladimir Zapolskiy <vz@mleia.com> |
gpio: don't free unallocated ida on gpiochip_add_data_with_key() error path The change corrects the error path in gpiochip_add_data_with_key() by avoiding to call ida_simple_remove(), if ida_simple_get() returns an error. Note that ida_simple_remove()/ida_free() throws a BUG(), if id argument is negative, it allows to easily check the correctness of the fix by fuzzing the return value from ida_simple_get(). Fixes: ff2b13592299 ("gpio: make the gpiochip a real device") Cc: stable@vger.kernel.org # v4.6+ Signed-off-by: Vladimir Zapolskiy <vz@mleia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
18534df4 |
|
01-Nov-2018 |
Muchun Song <smuchun@gmail.com> |
gpiolib: Fix possible use after free on label gpiod_request_commit() copies the pointer to the label passed as an argument only to be used later. But there's a chance the caller could immediately free the passed string(e.g., local variable). This could trigger a use after free when we use gpio label(e.g., gpiochip_unlock_as_irq(), gpiochip_is_requested()). To be on the safe side: duplicate the string with kstrdup_const() so that if an unaware user passes an address to a stack-allocated buffer, we won't get the arbitrary label. Also fix gpiod_set_consumer_name(). Signed-off-by: Muchun Song <smuchun@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
48207d75 |
|
05-Oct-2018 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
gpio: drop devm_gpiochip_remove() There is hardly any reason to call devm_gpiochip_remove() because the driver core handles calling gpiochip_remove() automatically. To make it harder to introduce new (and probably unneeded) callers, drop the function. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
40f5ff4f |
|
08-Oct-2018 |
Stephen Boyd <swboyd@chromium.org> |
gpio: Clarify kerneldoc on gpiochip_set_chained_irqchip() This doesn't support nested anymore, so drivers shouldn't call it with the handler set to NULL. Cc: Evan Green <evgreen@chromium.org> Cc: Thierry Reding <treding@nvidia.com> Cc: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
3c1f6b2d |
|
08-Oct-2018 |
Stephen Boyd <swboyd@chromium.org> |
gpio: Remove unused 'irqchip' argument to gpiochip_set_cascaded_irqchip() This argument hasn't ever been used since it was introduced in commit 1425052097b5 ("gpio: add IRQ chip helpers in gpiolib"). Let's drop it to reduce reading confusion. Cc: Evan Green <evgreen@chromium.org> Cc: Thierry Reding <treding@nvidia.com> Cc: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
9cb7cf9c |
|
08-Oct-2018 |
Stephen Boyd <swboyd@chromium.org> |
gpio: Drop parent irq assignment during cascade setup We want to set the irq parent for interrupts that we're setting up to be cascaded from another interrupt controller, but we may or may not have already mapped the gpiochip irqs into the kernel's virtual irq number space at this point. If we have mapped irqs before calling here, then we've gone through gpiochip_irq_map() and called irq_set_parent() already. If we haven't mapped irqs, then the gpiochip is dynamically mapping irqs and we can rely on gpiochip_irq_map() or the gpio driver's irqdomain ops to setup the irq parent properly. Either way, setting the parent here when cascading the gpiochip doesn't make much sense because it should be done at irq mapping time. In the dynamic mapping case, this code is mapping virq 0 to some parent virq in a loop. While that's benign, let's drop this code to simplify. Cc: Evan Green <evgreen@chromium.org> Cc: Thierry Reding <treding@nvidia.com> Cc: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
b0ce7b29 |
|
12-Oct-2018 |
Linus Walleij <linus.walleij@linaro.org> |
regulator/gpio: Allow nonexclusive GPIO access This allows nonexclusive (simultaneous) access to a single GPIO line for the fixed regulator enable line. This happens when several regulators use the same GPIO for enabling and disabling a regulator, and all need a handle on their GPIO descriptor. This solution with a special flag is not entirely elegant and should ideally be replaced by something more careful as this makes it possible for several consumers to enable/disable the same GPIO line to the left and right without any consistency. The current use inside the regulator core should however be fine as it takes special care to handle this. For the state of the GPIO backend, this is still the lesser evil compared to going back to global GPIO numbers. Cc: Marek Szyprowski <m.szyprowski@samsung.com> Cc: Jon Hunter <jonathanh@nvidia.com> Fixes: efdfeb079cc3 ("regulator: fixed: Convert to use GPIO descriptor only") Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
|
#
767cd17a |
|
12-Oct-2018 |
Ricardo Ribalda <ribalda@kernel.org> |
gpiolib: Initialize gdev field before is used gpio_hog depends on gdev field being initialized. This patch fixes an OOPs during initialization of TI's AM335x-ICEv2. Fixes: 3edfb7bd76bd1cba ("gpiolib: Show correct direction from the beginning") Tested-by: Vignesh R <vigneshr@ti.com> Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
3e779a2e |
|
08-Oct-2018 |
Stephen Boyd <swboyd@chromium.org> |
gpio: Assign gpio_irq_chip::parents to non-stack pointer gpiochip_set_cascaded_irqchip() is passed 'parent_irq' as an argument and then the address of that argument is assigned to the gpio chips gpio_irq_chip 'parents' pointer shortly thereafter. This can't ever work, because we've just assigned some stack address to a pointer that we plan to dereference later in gpiochip_irq_map(). I ran into this issue with the KASAN report below when gpiochip_irq_map() tried to setup the parent irq with a total junk pointer for the 'parents' array. BUG: KASAN: stack-out-of-bounds in gpiochip_irq_map+0x228/0x248 Read of size 4 at addr ffffffc0dde472e0 by task swapper/0/1 CPU: 7 PID: 1 Comm: swapper/0 Not tainted 4.14.72 #34 Call trace: [<ffffff9008093638>] dump_backtrace+0x0/0x718 [<ffffff9008093da4>] show_stack+0x20/0x2c [<ffffff90096b9224>] __dump_stack+0x20/0x28 [<ffffff90096b91c8>] dump_stack+0x80/0xbc [<ffffff900845a350>] print_address_description+0x70/0x238 [<ffffff900845a8e4>] kasan_report+0x1cc/0x260 [<ffffff900845aa14>] __asan_report_load4_noabort+0x2c/0x38 [<ffffff900897e098>] gpiochip_irq_map+0x228/0x248 [<ffffff900820cc08>] irq_domain_associate+0x114/0x2ec [<ffffff900820d13c>] irq_create_mapping+0x120/0x234 [<ffffff900820da78>] irq_create_fwspec_mapping+0x4c8/0x88c [<ffffff900820e2d8>] irq_create_of_mapping+0x180/0x210 [<ffffff900917114c>] of_irq_get+0x138/0x198 [<ffffff9008dc70ac>] spi_drv_probe+0x94/0x178 [<ffffff9008ca5168>] driver_probe_device+0x51c/0x824 [<ffffff9008ca6538>] __device_attach_driver+0x148/0x20c [<ffffff9008ca14cc>] bus_for_each_drv+0x120/0x188 [<ffffff9008ca570c>] __device_attach+0x19c/0x2dc [<ffffff9008ca586c>] device_initial_probe+0x20/0x2c [<ffffff9008ca18bc>] bus_probe_device+0x80/0x154 [<ffffff9008c9b9b4>] device_add+0x9b8/0xbdc [<ffffff9008dc7640>] spi_add_device+0x1b8/0x380 [<ffffff9008dcbaf0>] spi_register_controller+0x111c/0x1378 [<ffffff9008dd6b10>] spi_geni_probe+0x4dc/0x6f8 [<ffffff9008cab058>] platform_drv_probe+0xdc/0x130 [<ffffff9008ca5168>] driver_probe_device+0x51c/0x824 [<ffffff9008ca59cc>] __driver_attach+0x100/0x194 [<ffffff9008ca0ea8>] bus_for_each_dev+0x104/0x16c [<ffffff9008ca58c0>] driver_attach+0x48/0x54 [<ffffff9008ca1edc>] bus_add_driver+0x274/0x498 [<ffffff9008ca8448>] driver_register+0x1ac/0x230 [<ffffff9008caaf6c>] __platform_driver_register+0xcc/0xdc [<ffffff9009c4b33c>] spi_geni_driver_init+0x1c/0x24 [<ffffff9008084cb8>] do_one_initcall+0x240/0x3dc [<ffffff9009c017d0>] kernel_init_freeable+0x378/0x468 [<ffffff90096e8240>] kernel_init+0x14/0x110 [<ffffff9008086fcc>] ret_from_fork+0x10/0x18 The buggy address belongs to the page: page:ffffffbf037791c0 count:0 mapcount:0 mapping: (null) index:0x0 flags: 0x4000000000000000() raw: 4000000000000000 0000000000000000 0000000000000000 00000000ffffffff raw: ffffffbf037791e0 ffffffbf037791e0 0000000000000000 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffffffc0dde47180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffffffc0dde47200: f1 f1 f1 f1 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f2 f2 >ffffffc0dde47280: f2 f2 00 00 00 00 00 00 00 00 00 00 f3 f3 f3 f3 ^ ffffffc0dde47300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffffffc0dde47380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Let's leave around one unsigned int in the gpio_irq_chip struct for the single parent irq case and repoint the 'parents' array at it. This way code is left mostly intact to setup parents and we waste an extra few bytes per structure of which there should be only a handful in a system. Cc: Evan Green <evgreen@chromium.org> Cc: Thierry Reding <treding@nvidia.com> Cc: Grygorii Strashko <grygorii.strashko@ti.com> Fixes: e0d897289813 ("gpio: Implement tighter IRQ chip integration") Signed-off-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
3925b90f |
|
08-Oct-2018 |
Uwe Kleine-König <uwe@kleine-koenig.org> |
gpio: fix doc string for devm_gpiochip_add_data() to not talk about irq_chip The function is about adding a gpio_chip so dev has to belong to this one. Fix wording to be more grammatically correct (but attention, I'm not a native speaker). Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
3edfb7bd |
|
05-Oct-2018 |
Ricardo Ribalda <ribalda@kernel.org> |
gpiolib: Show correct direction from the beginning Current code assumes that the direction is input if direction_input function is set. This might not be the case on GPIOs with programmable direction. Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Tested-by: Jeffrey Hugo <jhugo@codeaurora.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
f8ec92a9 |
|
05-Oct-2018 |
Ricardo Ribalda <ribalda@kernel.org> |
gpiolib: Add init_valid_mask exported function Add a function that allows initializing the valid_mask from gpiochip_add_data. This prevents race conditions during gpiochip initialization. If the function is not exported, then the old behaviour is respected, this is, set all gpios as valid. Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Tested-by: Jeffrey Hugo <jhugo@codeaurora.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
90fd2270 |
|
01-Oct-2018 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: Slightly more helpful debugfs This at least makes debugfs print if the line is active high or low. That is pretty helpful as what we display as "lo" or "hi" is the raw physical level of the line. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
3c940660 |
|
27-Sep-2018 |
Geert Uytterhoeven <geert+renesas@glider.be> |
gpio: Restore indentation of continued lines Fixes: 3027743f83f867d8 ("gpio: Remove VLA from gpiolib") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
cf9af0d5 |
|
27-Sep-2018 |
Geert Uytterhoeven <geert+renesas@glider.be> |
gpio: Propagate errors from gpiod_set_array_value_complex() Internal helper function gpiod_set_array_value_complex() was changed to return an error value, but not all gpiolib callers were updated to propagate the new error up. Fixes: 3027743f83f867d8 ("gpio: Remove VLA from gpiolib") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
799d5eb4 |
|
29-Sep-2018 |
Janusz Krzysztofik <jmkrzyszt@gmail.com> |
gpiolib: Fix incorrect use of find_next_zero_bit() Commit b17566a6b08b ("gpiolib: Implement fast processing path in get/set array"), already fixed to some extent with commit 5d581d7e8cdc ("gpiolib: Fix missing updates of bitmap index"), introduced a new mode of processing bitmaps where bits applicable for fast bitmap processing path are supposed to be skipped while iterating bits which don't apply. Unfortunately, find_next_zero_bit() function supposed to skip over those fast bits is always called with a 'start' argument equal to an index of last zero bit found and returns that index value again an again, causing an infinite loop. Fix it by incrementing the index uncoditionally before find_next_zero_bit() is optionally called. Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
e48d194d |
|
25-Sep-2018 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: Add comments on single direction chips A patch from Ricardo got me thinking about some gpio chip semantics so let's drop in some comments to make things more clear around that. Cc: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Cc: Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
ae9847f4 |
|
20-Sep-2018 |
Ricardo Ribalda <ribalda@kernel.org> |
gpiolib: Fix gpio_direction_* for single direction GPIOs GPIOs with no programmable direction are not required to implement direction_output nor direction_input. If we try to set an output direction on an output-only GPIO or input direction on an input-only GPIO simply return 0. This allows this single direction GPIO to be used by libgpiod. Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
dae5f0af |
|
25-Sep-2018 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: Use SPDX header for core library Use the SPDX headers and cut down on boilerplate to indicate the license in the core gpiolib implementation. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
c4c958aa |
|
23-Sep-2018 |
Janusz Krzysztofik <jmkrzyszt@gmail.com> |
gpiolib: Fix array members of same chip processed separately New code introduced by commit bf9346f5d47b ("gpiolib: Identify arrays matching GPIO hardware") forcibly tries to find an array member which has its array index number equal to its hardware pin number and set up an array info for possible fast bitmap processing of all arrray pins belonging to that chip which also satisfy that numbering rule. Depending on array content, it may happen that consecutive array members which belong to the same chip but don't have array indexes equal to their pin hardware numbers will be split into groups, some of them processed together via the fast bitmap path, and rest of them separetely. However, applications may expect all those pins being processed together with a single call to .set_multiple() chip callback, like that was done before the change. Limit applicability of fast bitmap processing path to cases where all pins of consecutive array members starting from 0 which belong to the same chip have their hardware numbers equal to their corresponding array indexes. That should still speed up processing of applications using whole GPIO banks as I/O ports, while not breaking simultaneous manipulation of consecutive pins of the same chip which don't follow the equal numbering rule. Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
35ae7f96 |
|
23-Sep-2018 |
Janusz Krzysztofik <jmkrzyszt@gmail.com> |
gpiolib: Fix missing updates of bitmap index In new code introduced by commit b17566a6b08b ("gpiolib: Implement fast processing path in get/set array"), bitmap index is not updated with next found zero bit position as it should while skipping over pins already processed via fast bitmap path, possibly resulting in an infinite loop. Fix it. Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
19a4fbff |
|
13-Sep-2018 |
Ricardo Ribalda <ribalda@kernel.org> |
gpiolib: Free the last requested descriptor The current code only frees N-1 gpios if an error occurs during gpiod_set_transitory, gpiod_direction_output or gpiod_direction_input. Leading to gpios that cannot be used by userspace nor other drivers. Cc: Timur Tabi <timur@codeaurora.org> Cc: stable@vger.kernel.org Fixes: ab3dbcf78f60f46d ("gpioib: do not free unrequested descriptors) Reported-by: Jan Lorenzen <jl@newtec.dk> Reported-by: Jim Paris <jim@jtan.com> Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
171948ea |
|
14-Sep-2018 |
Hans Verkuil <hverkuil@xs4all.nl> |
gpiolib: check if irqchip already has the irq hook replacements Some drivers use a single irqchip for multiple gpiochips. As a result the irqchip hooks are overridden for the first gpiochip that was added, but for the other gpiochip instances this should not happen again, otherwise we would go into an infinite recursion. Check for this, but also log a message that the driver should be fixed since this is bad practice. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Tested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
d0121b85 |
|
11-Jul-2018 |
Wolfram Sang <wsa+renesas@sang-engineering.com> |
gpiolib: use better errno if get_direction is not available EINVAL is very generic, use ENOTSUPP in case the gpiochip does not provide this function. While removing the assignment from the 'status' variable, use better indentation in the declaration block. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
b17566a6 |
|
05-Sep-2018 |
Janusz Krzysztofik <jmkrzyszt@gmail.com> |
gpiolib: Implement fast processing path in get/set array Certain GPIO descriptor arrays returned by gpio_get_array() may contain information on direct mapping of array members to pins of a single GPIO chip in hardware order. In such cases, bitmaps of values can be passed directly from/to the chip's .get/set_multiple() callbacks without wasting time on iterations. Add respective code to gpiod_get/set_array_bitmap_complex() functions. Pins not applicable for fast path are processed as before, skipping over the 'fast' ones. Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
77588c14 |
|
05-Sep-2018 |
Janusz Krzysztofik <jmkrzyszt@gmail.com> |
gpiolib: Pass array info to get/set array functions In order to make use of array info obtained from gpiod_get_array() and speed up processing of arrays matching single GPIO chip layout, that information must be passed to get/set array functions. Extend the functions' API with that additional parameter and update all users. Pass NULL if a user builds an array itself from single GPIOs. Cc: Jonathan Corbet <corbet@lwn.net> Cc: Miguel Ojeda Sandonis <miguel.ojeda.sandonis@gmail.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Sebastien Bourdelin <sebastien.bourdelin@savoirfairelinux.com> Cc: Lukas Wunner <lukas@wunner.de> Cc: Peter Korsgaard <peter.korsgaard@barco.com> Cc: Peter Rosin <peda@axentia.se> Cc: Andrew Lunn <andrew@lunn.ch> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Rojhalat Ibrahim <imr@rtschenk.de> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Cc: Russell King <rmk+kernel@armlinux.org.uk> Cc: Kishon Vijay Abraham I <kishon@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Michael Hennerich <Michael.Hennerich@analog.com> Cc: Jonathan Cameron <jic23@kernel.org> Cc: Hartmut Knaack <knaack.h@gmx.de> Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jiri Slaby <jslaby@suse.com> Cc: Yegor Yefremov <yegorslists@googlemail.com> Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com> Acked-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
bf9346f5 |
|
05-Sep-2018 |
Janusz Krzysztofik <jmkrzyszt@gmail.com> |
gpiolib: Identify arrays matching GPIO hardware Certain GPIO array lookup results may map directly to GPIO pins of a single GPIO chip in hardware order. If that condition is recognized and handled efficiently, significant performance gain of get/set array functions may be possible. While processing a request for an array of GPIO descriptors, identify those which represent corresponding pins of a single GPIO chip. Skip over pins which require open source or open drain special processing. Moreover, identify pins which require inversion. Pass a pointer to that information with the array to the caller so it can benefit from enhanced performance as soon as get/set array functions can accept and make efficient use of it. Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
b9762beb |
|
05-Sep-2018 |
Janusz Krzysztofik <jmkrzyszt@gmail.com> |
gpiolib: Pass bitmaps, not integer arrays, to get/set array Most users of get/set array functions iterate consecutive bits of data, usually a single integer, while processing array of results obtained from, or building an array of values to be passed to those functions. Save time wasted on those iterations by changing the functions' API to accept bitmaps. All current users are updated as well. More benefits from the change are expected as soon as planned support for accepting/passing those bitmaps directly from/to respective GPIO chip callbacks if applicable is implemented. Cc: Jonathan Corbet <corbet@lwn.net> Cc: Miguel Ojeda Sandonis <miguel.ojeda.sandonis@gmail.com> Cc: Sebastien Bourdelin <sebastien.bourdelin@savoirfairelinux.com> Cc: Lukas Wunner <lukas@wunner.de> Cc: Peter Korsgaard <peter.korsgaard@barco.com> Cc: Peter Rosin <peda@axentia.se> Cc: Andrew Lunn <andrew@lunn.ch> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Rojhalat Ibrahim <imr@rtschenk.de> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Cc: Russell King <rmk+kernel@armlinux.org.uk> Cc: Kishon Vijay Abraham I <kishon@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Michael Hennerich <Michael.Hennerich@analog.com> Cc: Jonathan Cameron <jic23@kernel.org> Cc: Hartmut Knaack <knaack.h@gmx.de> Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jiri Slaby <jslaby@suse.com> Cc: Yegor Yefremov <yegorslists@googlemail.com> Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com> Acked-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
fa38869b |
|
20-Aug-2018 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
gpiolib: Don't support irq sharing for userspace This concerns gpio edge detection for GPIO IRQs used from userspace for GPIO event listeners. Trying to work out the right event if it's not sure that the examined gpio actually moved is impossible. Consider two gpios "gpioA" and "gpioB" that share an interrupt. gpioA's irq should trigger on any edge, gpioB's on a falling edge. If now the common irq fires and both gpio lines are high, there are several possibilities that could have happend: a) gpioA just had a low-to-high edge b) gpioB just had a high-to-low-to-high spike c) a combination of both a) and b) While c) is unlikely (in most setups) a) and b) alone are bad enough. Currently the code assumes case a) unconditionally and doesn't report an event for gpioB. Note that even if there is no irq sharing involved a spike for a gpio might not result in an event if it's configured to trigger for a single edge only. The only way to improve this is to drop support for interrupt sharing. This way a spike results in an event for the right gpio at least. Note that apart from dropping IRQF_SHARED this effectively undoes commit df1e76f28ffe ("gpiolib: skip unwanted events, don't convert them to opposite edge"). This obviously breaks setups that rely on interrupt sharing, but given that this cannot be reliable, this is probably an acceptable trade-off. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> [Assuming there are no users of interrupt sharing yet] Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
461c1a7d |
|
08-Sep-2018 |
Hans Verkuil <hans.verkuil@cisco.com> |
gpiolib: override irq_enable/disable When using the gpiolib irqchip helpers install irq_enable/disable hooks for the irqchip to ensure that gpiolib knows when the irq is enabled or disabled, allowing drivers to disable the irq and then use it as an output pin, and later switch the direction to input and re-enable the irq. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
4e9439dd |
|
08-Sep-2018 |
Hans Verkuil <hans.verkuil@cisco.com> |
gpiolib: add flag to indicate if the irq is disabled GPIO drivers call gpiochip_(un)lock_as_irq whenever they want to use a gpio as an interrupt. This is done when the irq is requested and it marks the gpio as in use by an interrupt. This is problematic for cases where a gpio pin is used as an interrupt pin, then, after the irq is disabled, is used as a regular gpio pin. Currently it is not possible to do this other than by first freeing the interrupt so gpiochip_unlock_as_irq is called, since an attempt to switch the gpio direction for output will fail since gpiolib believes that the gpio is in use for an interrupt and it does not know that it the irq is actually disabled. There are currently two drivers that would like to be able to do this: the tda998x_drv.c driver where a regular gpio pin needs to be temporarily reconfigured as an interrupt pin during CEC calibration, and the cec-gpio driver where you want to configure the gpio pin as an interrupt while waiting for traffic over the CEC bus, or as a regular pin when receiving or transmitting a CEC message. The solution is to add a new flag that is set when the irq is enabled, and have gpiod_direction_output check for that flag. We also add functions that drivers that do not use GPIOLIB_IRQCHIP can call when they enable/disable the irq. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
ca620f2d |
|
08-Sep-2018 |
Hans Verkuil <hans.verkuil@cisco.com> |
gliolib: set hooks in gpiochip_set_irq_hooks() Centralize setting the irq_request/release_resources callbacks in one function since we'll be adding more callbacks to that. Also fix the removal of the callback overrides: this should only be done if we actually installed our own callback there. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
4e6b8238 |
|
08-Sep-2018 |
Hans Verkuil <hans.verkuil@cisco.com> |
gpiolib: export gpiochip_irq_reqres/relres() GPIO drivers that do not use GPIOLIB_IRQCHIP can hook these into the irq_request_resource and irq_release_resource callbacks of the irq_chip so they correctly 'get' the module and lock the gpio line for IRQ use. This will simplify driver code. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
3789f5ac |
|
07-Aug-2018 |
Biju Das <biju.das@bp.renesas.com> |
gpiolib: Avoid calling chip->request() for unused gpios Add a check for unused gpios to avoid chip->request() call to client driver for unused gpios. Signed-off-by: Biju Das <biju.das@bp.renesas.com> Reviewed-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
6ff04974 |
|
06-Aug-2018 |
Biju Das <biju.das@bp.renesas.com> |
gpiolib: Fix of_node inconsistency Some platforms are not setting of_node in the driver. On these platforms defining gpio-reserved-ranges on device tree leads to kernel crash. It is due to some parts of the gpio core relying on the driver to set up of_node,while other parts do themselves.This inconsistent behaviour leads to a crash. gpiochip_add_data_with_key() calls gpiochip_init_valid_mask() with of_node as NULL. of_gpiochip_add() fills "of_node" and calls of_gpiochip_init_valid_mask(). The fix is to move the assignment to chip->of_node from of_gpiochip_add() to gpiochip_add_data_with_key(). Signed-off-by: Biju Das <biju.das@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
3a2f335c |
|
30-Jul-2018 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Don't shadow error code of gpiochip_lock_as_irq() gpiochip_lock_as_irq() may return a few error codes, do not shadow them by -EINVAL and let caller to decide. No functional change intended. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
1777fc97 |
|
20-Jul-2018 |
Marcel Ziswiler <marcel.ziswiler@toradex.com> |
gpiolib: probe deferral error reporting Actually report the error code from devm_regulator_get() which may as well just be a probe deferral. This is e.g. what one gets upon booting a Colibri T20: gpiochip_add_data_with_key: GPIOs 0..223 (tegra-gpio) failed to register Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
2b955b34 |
|
16-Jul-2018 |
Bartosz Golaszewski <brgl@bgdev.pl> |
gpiolib: remove an unnecessary TODO It's actually fine to read values of output lines. This was also allowed by the legacy sysfs interface. Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
e5332d54 |
|
16-Jul-2018 |
Bartosz Golaszewski <brgl@bgdev.pl> |
gpiolib: don't allow userspace to set values of input lines User space can currently both read and set values of input lines using the character device. This was not allowed by the old sysfs interface nor is it a correct behavior. Check the first descriptor in the set for the OUT flag when asked to set values and return -EPERM if the line is input. Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
1c22a252 |
|
12-Jul-2018 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Join one line back for better readability One line in gpiolib_dbg_show() still fits 80 characters, so, join it to be like that in order to increase readability. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
80956790 |
|
09-Jul-2018 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Consistent use of ->get_direction() inside gpiolib Two out of three calls to ->get_direction (excluding, of course, gpiod_get_direction() itself) are using gpiod_get_direction() and one is still open coded. Replace the latter one to use same API for sake of consistency. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
8853daf3 |
|
03-Jul-2018 |
Janusz Krzysztofik <jmkrzyszt@gmail.com> |
gpiolib: Defer on non-DT find_chip_by_name() failure Avoid replication of error code conversion in non-DT GPIO consumers' code by returning -EPROBE_DEFER from gpiod_find() in case a chip identified by its label in a registered lookup table is not ready. See https://lkml.org/lkml/2018/5/30/176 for example case. Suggested-by: Boris Brezillon <boris.brezillon@bootlin.com> Signed-off-by: Janusz Krzysztofik <jmkrzyszt@gmail.com> Reviewed-by: Boris Brezillon <boris.brezillon@bootlin.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
36b31279 |
|
02-Jul-2018 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Respect error code of ->get_direction() In case we try to lock GPIO pin as IRQ when something going wrong we print a misleading message. Correct this by checking an error code from ->get_direction() in gpiochip_lock_as_irq() and printing a corresponding message. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
b1911710 |
|
02-Jul-2018 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Join string literals back For easy grepping on debug purposes join string literals back in the messages. While here, fix couple of small indentation issues. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
90b39402e |
|
01-Jun-2018 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: Add API to explicitly name a consumer The GPIO (descriptor) API registers a "label" naming what is currently using the GPIO line. Typically this is taken from things like the device tree node, so "reset-gpios" will result in he line being labeled "reset". The technical effect is pretty much zero: the use is for debug and introspection, such as "lsgpio" and debugfs files. However sometimes the user want this cuddly feeling of listing all GPIO lines and seeing exactly what they are for and it gives a very fulfilling sense of control. Especially in the cases when the device tree node doesn't provide a good name, or anonymous GPIO lines assigned just to "gpios" in the device tree because the usage is implicit. For these cases it may be nice to be able to label the line directly and explicitly. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
acafe7e3 |
|
08-May-2018 |
Kees Cook <keescook@chromium.org> |
treewide: Use struct_size() for kmalloc()-family One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct foo { int stuff; void *entry[]; }; instance = kmalloc(sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL); Instead of leaving these open-coded and prone to type mistakes, we can now use the new struct_size() helper: instance = kmalloc(struct_size(instance, entry, count), GFP_KERNEL); This patch makes the changes for kmalloc()-family (and kvmalloc()-family) uses. It was done via automatic conversion with manual review for the "CHECKME" non-standard cases noted below, using the following Coccinelle script: // pkey_cache = kmalloc(sizeof *pkey_cache + tprops->pkey_tbl_len * // sizeof *pkey_cache->table, GFP_KERNEL); @@ identifier alloc =~ "kmalloc|kzalloc|kvmalloc|kvzalloc"; expression GFP; identifier VAR, ELEMENT; expression COUNT; @@ - alloc(sizeof(*VAR) + COUNT * sizeof(*VAR->ELEMENT), GFP) + alloc(struct_size(VAR, ELEMENT, COUNT), GFP) // mr = kzalloc(sizeof(*mr) + m * sizeof(mr->map[0]), GFP_KERNEL); @@ identifier alloc =~ "kmalloc|kzalloc|kvmalloc|kvzalloc"; expression GFP; identifier VAR, ELEMENT; expression COUNT; @@ - alloc(sizeof(*VAR) + COUNT * sizeof(VAR->ELEMENT[0]), GFP) + alloc(struct_size(VAR, ELEMENT, COUNT), GFP) // Same pattern, but can't trivially locate the trailing element name, // or variable name. @@ identifier alloc =~ "kmalloc|kzalloc|kvmalloc|kvzalloc"; expression GFP; expression SOMETHING, COUNT, ELEMENT; @@ - alloc(sizeof(SOMETHING) + COUNT * sizeof(ELEMENT), GFP) + alloc(CHECKME_struct_size(&SOMETHING, ELEMENT, COUNT), GFP) Signed-off-by: Kees Cook <keescook@chromium.org>
|
#
973c1714 |
|
21-May-2018 |
Christian Lamparter <chunkeey@gmail.com> |
gpiolib: discourage gpiochip_add_pin[group]_range for DT pinctrls This patch adds the stern warning to the kerneldoc text of both gpiochip_add_pin[group]_range() functions in hope of detering developers from ever using them in their DeviceTree-supported pinctrl drivers in the future. For anyone affected: Please refer to Section 2.1 of Documentation/devicetree/bindings/gpio/gpio.txt on how to bind pinctrl and gpio drivers via the "gpio-ranges" property. Signed-off-by: Christian Lamparter <chunkeey@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
3027743f |
|
21-May-2018 |
Laura Abbott <labbott@redhat.com> |
gpio: Remove VLA from gpiolib The new challenge is to remove VLAs from the kernel (see https://lkml.org/lkml/2018/3/7/621) to eventually turn on -Wvla. Using a kmalloc array is the easy way to fix this but kmalloc is still more expensive than stack allocation. Introduce a fast path with a fixed size stack array to cover most chip with gpios below some fixed amount. The slow path dynamically allocates an array to cover those chips with a large number of gpios. Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Phil Reid <preid@electromag.com.au> Reviewed-and-tested-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Laura Abbott <labbott@redhat.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
ba3efdff |
|
01-May-2018 |
Dan Carpenter <dan.carpenter@oracle.com> |
gpiolib: fix gpiochip_machine_hog() There is a shifter vs vanilla mask bug here. We want to test if 1 << 11 is set but we're testing if 0xb is set. Fixes: 9a6c505f7df1 ("gpiolib: add hogs support for machine code") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
a411e81e |
|
10-Apr-2018 |
Bartosz Golaszewski <brgl@bgdev.pl> |
gpiolib: add hogs support for machine code Board files constitute a significant part of the users of the legacy GPIO framework. In many cases they only export a line and set its desired value. We could use GPIO hogs for that like we do for DT and ACPI but there's no support for that in machine code. This patch proposes to extend the machine.h API with support for registering hog tables in board files. Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
f001cc35 |
|
16-Apr-2018 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
gpio: fix error path in lineevent_create If gpiod_request() fails the cleanup must not call gpiod_free(). Cc: stable@vger.kernel.org Fixes: 61f922db7221 ("gpio: userspace ABI for reading GPIO line events") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
ab3dbcf7 |
|
29-Mar-2018 |
Timur Tabi <timur@codeaurora.org> |
gpioib: do not free unrequested descriptors If the main loop in linehandle_create() encounters an error, it unwinds completely by freeing all previously requested GPIO descriptors. However, if the error occurs in the beginning of the loop before that GPIO is requested, then the exit code attempts to free a null descriptor. If extrachecks is enabled, gpiod_free() triggers a WARN_ON. Instead, keep a separate count of legitimate GPIOs so that only those are freed. Cc: stable@vger.kernel.org Fixes: d7c51b47ac11 ("gpio: userspace ABI for reading/writing GPIO lines") Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Timur Tabi <timur@codeaurora.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
726cb3ba |
|
23-Mar-2018 |
Stephen Boyd <sboyd@codeaurora.org> |
gpiolib: Support 'gpio-reserved-ranges' property Some qcom platforms make some GPIOs or pins unavailable for use by non-secure operating systems, and thus reading or writing the registers for those pins will cause access control issues. Add support for a DT property to describe the set of GPIOs that are available for use so that higher level OSes are able to know what pins to avoid reading/writing. Non-DT platforms can add support by directly updating the chip->valid_mask. Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Tested-by: Timur Tabi <timur@codeaurora.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
ace56935 |
|
23-Mar-2018 |
Stephen Boyd <swboyd@chromium.org> |
gpiolib: Change bitmap allocation to kmalloc_array We don't need to clear out these bits when we set them immediately after. Use kmalloc_array() to skip clearing the bits. Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Tested-by: Timur Tabi <timur@codeaurora.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
e4371f6e |
|
23-Mar-2018 |
Stephen Boyd <swboyd@chromium.org> |
gpiolib: Extract mask allocation into subroutine We're going to use similar code to allocate and set all the bits in a mask for valid gpios to use. Extract the code from the irqchip version so it can be reused. Signed-off-by: Stephen Boyd <swboyd@chromium.org> Tested-by: Timur Tabi <timur@codeaurora.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
9d5a1f2c |
|
27-Feb-2018 |
Wang Dongsheng <dongsheng.wang@hxt-semitech.com> |
gpiolib: friendly debug information for consumer "failed" maybe makes observer confuse when a consumer can not lookup, so change to a friendly information. Signed-off-by: Wang Dongsheng <dongsheng.wang@hxt-semitech.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
a9a08845 |
|
11-Feb-2018 |
Linus Torvalds <torvalds@linux-foundation.org> |
vfs: do bulk POLL* -> EPOLL* replacement This is the mindless scripted replacement of kernel use of POLL* variables as described by Al, done by this script: for V in IN OUT PRI ERR RDNORM RDBAND WRNORM WRBAND HUP RDHUP NVAL MSG; do L=`git grep -l -w POLL$V | grep -v '^t' | grep -v /um/ | grep -v '^sa' | grep -v '/poll.h$'|grep -v '^D'` for f in $L; do sed -i "-es/^\([^\"]*\)\(\<POLL$V\>\)/\\1E\\2/" $f; done done with de-mangling cleanups yet to come. NOTE! On almost all architectures, the EPOLL* constants have the same values as the POLL* constants do. But they keyword here is "almost". For various bad reasons they aren't the same, and epoll() doesn't actually work quite correctly in some cases due to this on Sparc et al. The next patch from Al will sort out the final differences, and we should be all done. Scripted-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
d58f2bf2 |
|
30-Nov-2017 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: Timestamp events in hardirq handler Add a hardirq handler to the GPIO userspace event loop, making sure to pick up the timestamp there, as close as possible in time relative to the actual event causing the interrupt. Tested with a simple pushbutton GPIO on ux500 and seems to work fine. Cc: Bartosz Golaszewski <brgl@bgdev.pl> Reviewed-by: Felipe Balbi <felipe.balbi@linux.intel.com> Reported-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
24bd3efc |
|
22-Jan-2018 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: Fix kernel stack leak to userspace The GPIO event descriptor was leaking kernel stack to userspace because we don't zero the variable before use. Ooops. Fix this. Cc: stable@vger.kernel.org Reported-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Bartosz Golaszewski <brgl@bgdev.pl> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
40a3c9db |
|
16-Jan-2018 |
Colin Ian King <colin.king@canonical.com> |
gpiolib: remove redundant initialization of pointer desc The initialized value stored in pointer desc is never read as it is updated in the first executable statement in the function. This is therefore redundant and can be removed. Cleans up clang warning: drivers/gpio/gpiolib.c:3710:20: warning: Value stored to 'desc' during its initialization is never read Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
7d18f0a1 |
|
16-Jan-2018 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: No NULL owner Sometimes a GPIO is fetched with NULL as parent device, and that is just fine. So under these circumstances, avoid using dev_name() to provide a name for the GPIO line. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
92542edc |
|
29-Dec-2017 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: Export devm_gpiod_get_from_of_node() for consumers We have been holding back on adding an API for fetching GPIO handles directly from device nodes, strongly preferring to get it from the spawn devices instead. The fwnode interface however already contains an API for doing this, as it is used for opaque device tree nodes or ACPI nodes for getting handles to LEDs and keys that use GPIO: those are specified as one child per LED/key in the device tree and are not individual devices. However regulators present a special problem as they already have helper functions to traverse the device tree from a regulator node and two levels down to fill in data, and as it already traverses GPIO nodes in its own way, and already holds a pointer to each regulators device tree node, it makes most sense to export an API to fetch the GPIO descriptor directly from the node. We only support the devm_* version for now, hopefully no non-devres version will be needed. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
6392cca4 |
|
28-Dec-2017 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: Break out code to get a descriptor from a DT node Sometimes a GPIO needs to be taken from a node without a device associated with it. The fwnode accessor does this, let's however break out the DT code for now. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
64ff2c8e |
|
09-Jan-2018 |
Stephen Boyd <sboyd@codeaurora.org> |
gpiolib: Export gpiochip_irqchip_irq_valid() to drivers Some pinctrl drivers can use the gpiochip irq valid information to figure out if certain gpios are exposed to the kernel for usage or not. Expose this API so we can use it in the pinmux_ops::request ops. Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
1e77fc82 |
|
09-Jan-2018 |
Geert Uytterhoeven <geert+renesas@glider.be> |
gpio: Add missing open drain/source handling to gpiod_set_value_cansleep() Since commit f11a04464ae57e8d ("i2c: gpio: Enable working over slow can_sleep GPIOs"), probing the i2c RTC connected to an i2c-gpio bus on r8a7740/armadillo fails with: rtc-s35390a 0-0030: error resetting chip rtc-s35390a: probe of 0-0030 failed with error -5 More debug code reveals: i2c i2c-0: master_xfer[0] R, addr=0x30, len=1 i2c i2c-0: NAK from device addr 0x30 msg #0 s35390a_get_reg: ret = -6 Commit 02e479808b5d62f8 ("gpio: Alter semantics of *raw* operations to actually be raw") moved open drain/source handling from gpiod_set_raw_value_commit() to gpiod_set_value(), but forgot to take into account that gpiod_set_value_cansleep() also needs this handling. The i2c protocol mandates that i2c signals are open drain, hence i2c communication fails. Fix this by adding the missing handling to gpiod_set_value_cansleep(), using a new common helper gpiod_set_value_nocheck(). Fixes: 02e479808b5d62f8 ("gpio: Alter semantics of *raw* operations to actually be raw") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> [removed underscore syntax, added kerneldoc] Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
94fc7309 |
|
08-Jan-2018 |
Wolfram Sang <wsa+renesas@sang-engineering.com> |
gpio: correct docs about return value of gpiod_get_direction The use of the GPIOF_* flags is deprecated, so don't advertise them here. Document the plain numbers for now until we have a better solution. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
24e78079 |
|
04-Jan-2018 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: label descriptors using the device name Some GPIO lines appear named "?" in the lsgpio dump due to their requesting drivers not passing a reasonable label. Most typically this happens if a device tree node just defines gpios = <...> and not foo-gpios = <...>, the former gets named "foo" and the latter gets named "?". However the struct device passed in is always valid so let's just label the GPIO with dev_name() on the device if no proper label was passed. Cc: Reported-by: Jason Kridner <jkridner@beagleboard.org> Reported-by: Jason Kridner <jkridner@beagleboard.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
156dd392 |
|
21-Dec-2017 |
Vladimir Zapolskiy <vz@mleia.com> |
gpiolib: add desc validation to gpiod_set_transitory() The gpiod_set_transitory() function is publicly exported, and it is expected from it to be ready for usage with optional GPIOs on consumer's side. Signed-off-by: Vladimir Zapolskiy <vz@mleia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
dd3b9a44 |
|
21-Dec-2017 |
Vladimir Zapolskiy <vz@mleia.com> |
gpiolib: remove a redundant check in gpiod_to_chip() This non-functional change slightly simplifies the implementation of gpiod_to_chip() function. Signed-off-by: Vladimir Zapolskiy <vz@mleia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
30322bcf |
|
21-Dec-2017 |
Vladimir Zapolskiy <vz@mleia.com> |
gpiolib: don't dereference a desc before validation The fix restores a proper validation of an input gpio desc, which might be needed to deal with optional GPIOs correctly. Fixes: 02e479808b5d ("gpio: Alter semantics of *raw* operations to actually be raw") Signed-off-by: Vladimir Zapolskiy <vz@mleia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
39c3fd58 |
|
02-Dec-2017 |
Andrew Lunn <andrew@lunn.ch> |
kernel/irq: Extend lockdep class for request mutex The IRQ code already has support for lockdep class for the lock mutex in an interrupt descriptor. Extend this to add a second class for the request mutex in the descriptor. Not having a class is resulting in false positive splats in some code paths. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: linus.walleij@linaro.org Cc: grygorii.strashko@ti.com Cc: f.fainelli@gmail.com Link: https://lkml.kernel.org/r/1512234664-21555-1-git-send-email-andrew@lunn.ch
|
#
689fd02e |
|
21-Dec-2017 |
Jonathan Neuschäfer <j.neuschaefer@gmx.net> |
gpiolib: Fix typo in comment ("piochip_add_data") Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
a746a232 |
|
20-Dec-2017 |
Rasmus Villemoes <linux@rasmusvillemoes.dk> |
gpio: reduce descriptor validation code size While we do need macros to be able to return from the "calling" function, we can still factor the checks done by the VALIDATE_DESC* macros into a real helper function. This reduces the backslashtitis, avoids duplicating the logic in the two macros and saves about 1K of generated code: $ scripts/bloat-o-meter drivers/gpio/gpiolib.o.{0,1} add/remove: 1/0 grow/shrink: 0/15 up/down: 104/-1281 (-1177) Function old new delta validate_desc - 104 +104 gpiod_set_value 192 135 -57 gpiod_set_raw_value 125 67 -58 gpiod_direction_output 412 351 -61 gpiod_set_value_cansleep 150 70 -80 gpiod_set_raw_value_cansleep 132 52 -80 gpiod_get_raw_value 139 54 -85 gpiod_set_debounce 226 140 -86 gpiod_direction_output_raw 124 38 -86 gpiod_get_value 161 74 -87 gpiod_cansleep 126 39 -87 gpiod_get_raw_value_cansleep 130 39 -91 gpiod_get_value_cansleep 152 59 -93 gpiod_is_active_low 128 33 -95 gpiod_request 299 184 -115 gpiod_direction_input 386 266 -120 Total: Before=25460, After=24283, chg -4.62% Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Reviewed-by: Vladimir Zapolskiy <vz@mleia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
1ca2a92b |
|
20-Dec-2017 |
Timur Tabi <timur@codeaurora.org> |
Revert "gpio: set up initial state from .get_direction()" This reverts commit 72d3200061776264941be1b5a9bb8e926b3b30a5. We cannot blindly query the direction of all GPIOs when the pins are first registered. The get_direction callback normally triggers a read/write to hardware, but we shouldn't be touching the hardware for an individual GPIO until after it's been properly claimed. Signed-off-by: Timur Tabi <timur@codeaurora.org> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
fcf273e5 |
|
14-Dec-2017 |
Bartosz Golaszewski <brgl@bgdev.pl> |
gpiolib: use kstrdup_const() for gpio_device label Users often pass a pointer to a static string to gpiochip_add_data() family of functions. Avoid unnecessary memory allocations with the provided helper routine. While at it: use a ternary operator instead of an if else for brevity. Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
e10f72bf |
|
29-Nov-2017 |
Andrew Jeffery <andrew@aj.id.au> |
gpio: gpiolib: Generalise state persistence beyond sleep General support for state persistence is added to gpiolib with the introduction of a new pinconf parameter to propagate the request to hardware. The existing persistence support for sleep is adapted to include hardware support if the GPIO driver provides it. Persistence continues to be enabled by default; in-kernel consumers can opt out, but userspace (currently) does not have a choice. The *_SLEEP_MAY_LOSE_VALUE and *_SLEEP_MAINTAIN_VALUE symbols are renamed, dropping the SLEEP prefix to reflect that the concept is no longer sleep-specific. I feel that renaming to just *_MAY_LOSE_VALUE could initially be misinterpreted, so I've further changed the symbols to *_TRANSITORY and *_PERSISTENT to address this. The sysfs interface is modified only to keep consistency with the chardev interface in enforcing persistence for userspace exports. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
588fc3bc |
|
15-Nov-2017 |
Bartosz Golaszewski <brgl@bgdev.pl> |
gpiolib: don't allow OPEN_DRAIN & OPEN_SOURCE flags simultaneously Do not allow OPEN_SOURCE & OPEN_DRAIN flags in a single request. If the hardware actually supports enabling both at the same time the electrical result would be disastrous. Suggested-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
5c34b6c1 |
|
10-Nov-2017 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: acpi: Consolidate debug output in acpi_gpio_update_gpiod_flags() We have the duplicated debug strings printed whenever acpi_gpio_update_gpiod_flags() fails. Instead of doing this by callers, move the debug output inside function. In one case convert almost useless pr_debug() to dev_dbg() where actual consumer of GPIO resource is disclosed. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
afc9a42b |
|
03-Jul-2017 |
Al Viro <viro@zeniv.linux.org.uk> |
the rest of drivers/*: annotate ->poll() instances Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
#
ec47873e |
|
08-Nov-2017 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: Fix undefined lock_dep_class The struct is wrong, this is named lock_class_key. Cc: Thierry Reding <treding@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
959bc7b2 |
|
07-Nov-2017 |
Thierry Reding <treding@nvidia.com> |
gpio: Automatically add lockdep keys In order to avoid lockdep boilerplate in individual drivers, turn the gpiochip_add_data() function into a macro that creates a unique class key for each driver. Note that this has the slight disadvantage of adding a key for each driver registered with the system. However, these keys are 8 bytes in size, which is negligible and a small price to pay for generic infrastructure. Suggested-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Grygorii Strashko <grygorii.strashko@ti.com> [renane __gpiochip_add_data() to gpiochip_add_data_with_key] Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
8302cf58 |
|
07-Nov-2017 |
Thierry Reding <treding@nvidia.com> |
gpio: Introduce struct gpio_irq_chip.first Some GPIO chips cannot support sparse IRQ numbering and therefore need to manually allocate their interrupt descriptors statically. For these cases, a driver can pass the first allocated IRQ via the struct gpio_irq_chip's "first" field and thereby cause the IRQ domain to map all IRQs during initialization. Suggested-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
60ed54ca |
|
07-Nov-2017 |
Thierry Reding <treding@nvidia.com> |
gpio: Disambiguate struct gpio_irq_chip.nested The nested field in struct gpio_irq_chip currently has two meanings. On one hand it marks an IRQ chip as being nested (as opposed to chained), while on the other hand it also means that an IRQ chip uses nested thread handlers. However, nested IRQ chips can already be identified by the fact that they don't pass a parent handler (the driver would instead already have installed a nested handler using request_irq()). Therefore, the only use for the nested attribute is to inform gpiolib that an IRQ chip uses nested thread handlers (as opposed to regular, non-threaded handlers). To clarify its purpose, rename the field to "threaded". Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
1b95b4eb |
|
07-Nov-2017 |
Thierry Reding <treding@nvidia.com> |
gpio: Export gpiochip_irq_{map,unmap}() Export these functions so that drivers can explicitly use these when setting up their IRQ domain. Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
e0d89728 |
|
07-Nov-2017 |
Thierry Reding <treding@nvidia.com> |
gpio: Implement tighter IRQ chip integration Currently GPIO drivers are required to add the GPIO chip and its corresponding IRQ chip separately, which can result in a lot of boilerplate. Use the newly introduced struct gpio_irq_chip, embedded in struct gpio_chip, that drivers can fill in if they want the GPIO core to automatically register the IRQ chip associated with a GPIO chip. Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
ca9df053 |
|
07-Nov-2017 |
Thierry Reding <treding@nvidia.com> |
gpio: Move lock_key into struct gpio_irq_chip In order to consolidate the multiple ways to associate an IRQ chip with a GPIO chip, move more fields into the new struct gpio_irq_chip. Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
dc7b0387 |
|
07-Nov-2017 |
Thierry Reding <treding@nvidia.com> |
gpio: Move irq_valid_mask into struct gpio_irq_chip In order to consolidate the multiple ways to associate an IRQ chip with a GPIO chip, move more fields into the new struct gpio_irq_chip. Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
dc6bafee |
|
07-Nov-2017 |
Thierry Reding <treding@nvidia.com> |
gpio: Move irq_nested into struct gpio_irq_chip In order to consolidate the multiple ways to associate an IRQ chip with a GPIO chip, move more fields into the new struct gpio_irq_chip. Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
39e5f096 |
|
07-Nov-2017 |
Thierry Reding <treding@nvidia.com> |
gpio: Move irq_chained_parent to struct gpio_irq_chip In order to consolidate the multiple ways to associate an IRQ chip with a GPIO chip, move more fields into the new struct gpio_irq_chip. Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
3634eeb0 |
|
07-Nov-2017 |
Thierry Reding <treding@nvidia.com> |
gpio: Move irq_default_type to struct gpio_irq_chip In order to consolidate the multiple ways to associate an IRQ chip with a GPIO chip, move more fields into the new struct gpio_irq_chip. Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
c7a0aa59 |
|
07-Nov-2017 |
Thierry Reding <treding@nvidia.com> |
gpio: Move irq_handler to struct gpio_irq_chip In order to consolidate the multiple ways to associate an IRQ chip with a GPIO chip, move more fields into the new struct gpio_irq_chip. Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
f0fbe7bc |
|
07-Nov-2017 |
Thierry Reding <treding@nvidia.com> |
gpio: Move irqdomain into struct gpio_irq_chip In order to consolidate the multiple ways to associate an IRQ chip with a GPIO chip, move more fields into the new struct gpio_irq_chip. Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
da80ff81 |
|
07-Nov-2017 |
Thierry Reding <treding@nvidia.com> |
gpio: Move irqchip into struct gpio_irq_chip In order to consolidate the multiple ways to associate an IRQ chip with a GPIO chip, move more fields into the new struct gpio_irq_chip. Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
f926dfc1 |
|
10-Sep-2017 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: Make it possible for consumers to enforce open drain Some busses, like I2C, strictly need to have the line handled as open drain, i.e. not actively driven high. For this reason the i2c-gpio.c bit-banged I2C driver is reimplementing open drain handling outside of gpiolib. This is not very optimal. Instead make it possible for a consumer to explcitly express that the line must be handled as open drain instead of allowing local hacks papering over this issue. The descriptor tables, whether DT, ACPI or board files, should of course have flagged these lines as open drain. E.g.: enum gpio_lookup_flags GPIO_OPEN_DRAIN for a board file, or gpios = <&foo 42 GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN>; in a device tree using <dt-bindings/gpio/gpio.h> But more often than not, these descriptors are wrong. So we need to make it possible for consumers to enforce this open drain behaviour. We now have two new enumerated GPIO descriptor config flags: GPIOD_OUT_LOW_OPEN_DRAIN and GPIOD_OUT_HIGH_OPEN_DRAIN that will set up the lined enforced as open drain as output low or high, using open drain (if the driver supports it) or using open drain emulation (setting the line as input to drive it high) from the gpiolib core. Cc: linux-gpio@vger.kernel.org Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
2cbfca66 |
|
19-Oct-2017 |
Andrew Jeffery <andrew@aj.id.au> |
gpio: Fix loose spelling Literally. I expect "lose" was meant here, rather than "loose", though you could feasibly use a somewhat uncommon definition of "loose" to mean what would be meant by "lose": "Loose the hounds" for instance, as in "Release the hounds". Substituting in "value" for "hounds" gives "release the value", and makes some sense, but futher substituting back to loose gives "loose the value" which overall just seems a bit anachronistic. Instead, use modern, pragmatic English and save a character. Cc: Russell Currey <ruscur@russell.cc> Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
5048f0ae |
|
18-Oct-2017 |
Martin Kaiser <martin@kaiser.cx> |
gpiolib: clear irq handler and data in one go Replace the two separate calls for clearing the irqchip's chained handler and its data with a single irq_set_chained_handler_and_data() call. Signed-off-by: Martin Kaiser <martin@kaiser.cx> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
609aaf6a |
|
16-Oct-2017 |
Bartosz Golaszewski <brgl@bgdev.pl> |
gpiolib: don't allow OPEN_DRAIN & OPEN_SOURCE flags for input OPEN_DRAIN and OPEN_SOURCE flags only affect the way we drive a GPIO line, so they only make sense for output mode. Just as we only allow input mode for event handle requests, don't allow passing open-drain and open-source flags for any other mode than explicit output. Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
418ee8e9 |
|
16-Oct-2017 |
Bartosz Golaszewski <brgl@bgdev.pl> |
gpiolib: only check line handle flags once There's no need to check the validity of handle request flags more than once, right after copying the data from user. Move the check out of the for loop and simplify the error path by bailing out before allocating any resources. Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
eec1d566 |
|
11-Oct-2017 |
Lukas Wunner <lukas@wunner.de> |
gpio: Introduce ->get_multiple callback SPI-attached GPIO controllers typically read out all inputs in one go. If callers desire the values of multipe inputs, ideally a single readout should take place to return the desired values. However the current driver API only offers a ->get callback but no ->get_multiple (unlike ->set_multiple, which is present). Thus, to read multiple inputs, a full readout needs to be performed for every single value (barring driver-internal caching), which is inefficient. In fact, the lack of a ->get_multiple callback has been bemoaned repeatedly by the gpio subsystem maintainer: http://www.spinics.net/lists/linux-gpio/msg10571.html http://www.spinics.net/lists/devicetree/msg121734.html Introduce the missing callback. Add corresponding consumer functions such as gpiod_get_array_value(). Amend linehandle_ioctl() to take advantage of the newly added infrastructure. Update the documentation. Cc: Rojhalat Ibrahim <imr@rtschenk.de> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
02e47980 |
|
26-Sep-2017 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: Alter semantics of *raw* operations to actually be raw Currently calls to: gpiod_direction_output_raw() gpiod_set_raw_value() gpiod_set_raw_array_value() gpiod_set_raw_value_cansleep() gpiod_set_raw_array_value_cansleep() Respect that we do not want to invert the value written, but will still apply special open drain/open source semantics if the line has an open drain/open source flag. It also forbids us from driving an output marked as an interrupt line. This does not fit with the function name and expected semantics. In the w1 host driver (for example) we need to handle a line as open drain but sometimes force it to pull up, which means we should be able to use the gpiod_set_raw_value() for this, but it currently does not work. There are also use cases where users actually want to drive a line used by an interrupt. This is what they should be expected to use the *raw* accessors for. I have looked over the current users of this API and they do not seem to be using the *raw* accessors with open drain or open source so let's augment this behaviour before we have users expecting the inconsistent semantic. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
fac9d885 |
|
26-Sep-2017 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: Get rid of _prefix and __prefixes The arbitrarily marking of a function with _ or __ is taking to mean "perform some inner core of the caller" or something like that. At other times, this syntax has a totally different meaning. I don't like this since it is unambious and unhelpful to people reading the code, so replace it with _commit() suffixes. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
a9a1d2a7 |
|
22-Sep-2017 |
Linus Walleij <linus.walleij@linaro.org> |
pinctrl/gpio: Unify namespace for cross-calls The pinctrl_request_gpio() and pinctrl_free_gpio() break the nice namespacing in the other cross-calls like pinctrl_gpio_foo(). Just rename them and all references so we have one namespace with all cross-calls under pinctrl_gpio_*(). Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
9e238e38 |
|
30-Aug-2017 |
Linus Walleij <linus.walleij@linaro.org> |
Revert "gpiolib: request the gpio before querying its direction" This reverts commit 108d23e322a247d9f89ba2e2742520ead0944cc9. It turns out this causes a regression on the OMAP, Marvell and Renesas. Reported-by: Tony Lindgren <tony@atomide.com> Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reported-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
3946d187 |
|
14-Aug-2017 |
Dmitry Torokhov <dmitry.torokhov@gmail.com> |
gpio: add gpio_add_lookup_tables() to add several tables at once When converting legacy board to use gpiod API() there might be several lookup tables in board file, let's provide a way to register them all at once. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
950d55f5 |
|
24-Jul-2017 |
Thierry Reding <treding@nvidia.com> |
gpio: Cleanup kerneldoc Some kerneldoc has become stale or wasn't quite correct from the outset. Fix up the most serious issues to silence warnings when building the documentation. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
7eb6ce2f |
|
18-Jul-2017 |
Rob Herring <robh@kernel.org> |
gpio: Convert to using %pOF instead of full_name Now that we have a custom printf format specifier, convert users of full_name to use %pOF instead. This is preparation to remove storing of the full path string for each node. Signed-off-by: Rob Herring <robh@kernel.org> Cc: Tien Hock Loh <thloh@altera.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Alexandre Courbot <gnurou@gmail.com> Cc: Brian Norris <computersforpeace@gmail.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: bcm-kernel-feedback-list@broadcom.com Cc: Michal Simek <michal.simek@xilinx.com> Cc: "Sören Brinkmann" <soren.brinkmann@xilinx.com> Cc: linux-gpio@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Acked-by: Gregory Fong <gregory.0xf0@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
dc749a09 |
|
21-Jul-2017 |
Grygorii Strashko <grygorii.strashko@ti.com> |
gpiolib: allow gpio irqchip to map irqs dynamically Now IRQ mappings are always created for all (allowed) GPIOs in gpiochip in gpiochip_irqchip_add_key() which goes against the idea of SPARSE_IRQ and, as result, leads to: - increasing of memory consumption for IRQ descriptors most of which will never ever be used (espessially on platform with a high number of GPIOs). (sizeof(struct irq_desc) == 256 on my tested platforms) - imposibility to use GPIO irqchip APIs by gpio drivers when HW implements GPIO IRQ functionality as IRQ crossbar/router which has only limited number of IRQ outputs (example from [1], all GPIOs can be mapped on only 8 IRQs). Hence, remove static IRQ mapping code from gpiochip_irqchip_add_key() and instead replace irq_find_mapping() with irq_create_mapping() in gpiochip_to_irq(). Also add additional gpiochip_irqchip_irq_valid() calls in gpiochip_to_irq() and gpiochip_irq_map(). After this change gpio2irq mapping will happen the following way when GPIO irqchip APIs are used by gpio driver: - IRQ mappings will be created statically if driver passes first_irq>0 vlaue in gpiochip_irqchip_add_key(). - IRQ mappings will be created dynamically from gpio_to_irq() or of_irq_get(). Tested on am335x-evm and dra72-evm-revc. - dra72-evm-revc: number of created irq mappings decreased from 402 -> 135 Mem savings 267*256 = 68352 (66kB) - am335x-evm: number of created irq mappings decreased from 188 -> 63 Mem savings 125*256 = 32000 (31kB) [1] https://lkml.org/lkml/2017/6/15/428 Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
108d23e3 |
|
27-Jul-2017 |
Timur Tabi <timur@codeaurora.org> |
gpiolib: request the gpio before querying its direction Before querying a GPIO to determine its direction, the GPIO should be formally requested. This allows the GPIO driver to block access to unavailable GPIOs, which makes it easier for some drivers to support sparse GPIO maps. Signed-off-by: Timur Tabi <timur@codeaurora.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
df1e76f2 |
|
03-Jul-2017 |
Bartosz Golaszewski <brgl@bgdev.pl> |
gpiolib: skip unwanted events, don't convert them to opposite edge The previous fix for filtering out of unwatched events was not entirely correct. Instead of skipping the events we don't want, they are now interpreted as events with opposing edge. In order to fix it: always read the GPIO line value on interrupt and only emit the event if it corresponds with the event type we requested. Cc: stable@vger.kernel.org Fixes: ad537b822577 ("gpiolib: fix filtering out unwanted events") Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
ad537b82 |
|
23-Jun-2017 |
Bartosz Golaszewski <brgl@bgdev.pl> |
gpiolib: fix filtering out unwanted events GPIOEVENT_REQUEST_BOTH_EDGES is not a single flag, but a binary OR of GPIOEVENT_REQUEST_RISING_EDGE and GPIOEVENT_REQUEST_FALLING_EDGE. The expression 'le->eflags & GPIOEVENT_REQUEST_BOTH_EDGES' we'll get evaluated to true even if only one event type was requested. Fix it by checking both RISING & FALLING flags explicitly. Cc: stable@vger.kernel.org Fixes: 61f922db7221 ("gpio: userspace ABI for reading GPIO line events") Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
073570dc |
|
30-May-2017 |
Arnd Bergmann <arnd@arndb.de> |
gpiolib: remove unused variable This was left behind by a cleanup patch: drivers/gpio/gpiolib.c: In function 'gpiochip_irqchip_init_valid_mask': drivers/gpio/gpiolib.c:1474:6: error: unused variable 'i' [-Werror=unused-variable] Fixes: 923a654c186c ("gpiolib: Re-use bitmap_fill() instead of open coded loop") Reported-by: kbuild test robot <fengguang.wu@intel.com> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Reported-by: Colin King <colin.king@canonical.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
923a654c |
|
25-May-2017 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Re-use bitmap_fill() instead of open coded loop Re-use bitmap_fill() instead of open coded loop for setting an area of bits in a bitmap. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
a31f5c3a |
|
23-May-2017 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpio: acpi: Override GPIO initialization flags This allows ACPI GPIO code to modify flags based on ACPI GpioIo() / GpioInt() resources. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
c29fd9eb |
|
23-May-2017 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Export gpiod_configure_flags() to internal users This is preparatory patch for enabling GPIO ACPI to configure a pin accordingly. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
05f479bf |
|
23-May-2017 |
Charles Keepax <ckeepax@opensource.wolfsonmicro.com> |
gpio: Add new flags to control sleep status of GPIOs Add new flags to allow users to specify that they are not concerned with the status of GPIOs whilst in a sleep/low power state. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
226b2242 |
|
20-Apr-2017 |
Anatolij Gustschin <agust@denx.de> |
gpio: export add/remove lookup table functions For hot-pluggable devices adding GPIOs dynamically we need to assemble and add the gpio lookup tables at probe time in modules, so that requesting these GPIOs in attached drivers can work. Export lookup table functions for modules. Signed-off-by: Anatolij Gustschin <agust@denx.de> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
6f79309a |
|
03-Apr-2017 |
Thierry Reding <treding@nvidia.com> |
gpio: Use unsigned int for interrupt numbers Interrupt numbers are never negative, zero serves as the special invalid value. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
4c0facdd |
|
06-Apr-2017 |
Laxman Dewangan <ldewangan@nvidia.com> |
gpio: core: Decouple open drain/source flag with active low/high Currently, the GPIO interface is said to Open Drain if it is Single Ended and active LOW. Similarly, it is said as Open Source if it is Single Ended and active HIGH. The active HIGH/LOW is used in the interface for setting the pin state to HIGH or LOW when enabling/disabling the interface. In Open Drain interface, pin is set to HIGH by putting pin in high impedance and LOW by driving to the LOW. In Open Source interface, pin is set to HIGH by driving pin to HIGH and set to LOW by putting pin in high impedance. With above, the Open Drain/Source is unrelated to the active LOW/HIGH in interface. There is interface where the enable/disable of interface is ether active LOW or HIGH but it is Open Drain type. Hence decouple the Open Drain with Single Ended + Active LOW and Open Source with Single Ended + Active HIGH. Adding different flag for the Open Drain/Open Source which is valid only when Single ended flag is enabled. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
111379dc |
|
17-Mar-2017 |
Logan Gunthorpe <logang@deltatee.com> |
gpiolib: utilize new cdev_device_add helper function Replace the open coded registration of the cdev and dev with the new device_add_cdev() helper. The helper replaces a common pattern by taking the proper reference against the parent device and adding both the cdev and the device. Signed-off-by: Logan Gunthorpe <logang@deltatee.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
4033d4a4 |
|
20-Feb-2017 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpio: of: Don't return 0 on dt_gpio_count() It's unusual to have error checking like (ret <= 0) in cases when counting GPIO resources. In case when it's mandatory we propagate the error (-ENOENT), otherwise we don't use the result. This makes consistent behaviour across all possible variants called in gpiod_count(). Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
ff21378a |
|
28-Feb-2017 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Fix spelling of 'successful' Remove extra 'l' in "successfull". Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
537b94da |
|
02-Feb-2017 |
Boris Brezillon <bbrezillon@kernel.org> |
gpio: Add the devm_fwnode_get_index_gpiod_from_child() helper devm_fwnode_get_gpiod_from_child() currently allows GPIO users to request a GPIO that is defined in a child fwnode instead of directly in the device fwnode. Extend this API by adding the devm_fwnode_get_index_gpiod_from_child() helper which does the same except you can also specify an index in case the 'xx-gpios' property describe several GPIOs. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
3988d663 |
|
26-Jan-2017 |
Christophe JAILLET <christophe.jaillet@wanadoo.fr> |
gpiolib: Fix a WARN_ON that can never trigger "if (!x) WARN_ON(x)" can never trigger. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
2956b5d9 |
|
23-Jan-2017 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
pinctrl / gpio: Introduce .set_config() callback for GPIO chips Currently we already have two pin configuration related callbacks available for GPIO chips .set_single_ended() and .set_debounce(). In future we expect to have even more, which does not scale well if we need to add yet another callback to the GPIO chip structure for each possible configuration parameter. Better solution is to reuse what we already have available in the generic pinconf. To support this, we introduce a new .set_config() callback for GPIO chips. The callback takes a single packed pin configuration value as parameter. This can then be extended easily beyond what is currently supported by just adding new types to the generic pinconf enum. If the GPIO driver is backed up by a pinctrl driver the GPIO driver can just assign gpiochip_generic_config() (introduced in this patch) to .set_config and that will take care configuration requests are directed to the pinctrl driver. We then convert the existing drivers over .set_config() and finally remove the .set_single_ended() and .set_debounce() callbacks. Suggested-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
b2987d74 |
|
12-Jan-2017 |
Alexander Stein <alexander.stein@systec-electronic.com> |
gpio: Pass GPIO label down to gpiod_request Currently all users of fwnode_get_named_gpiod() have no way to specify a label for the GPIO. So GPIOs listed in debugfs are shown with label "?". With this change a proper label is used. Also adjust all users so they can pass a label, properly retrieved from device tree properties. Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
a264d10f |
|
09-Jan-2017 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Convert fwnode_get_named_gpiod() to configure GPIO Make fwnode_get_named_gpiod() consistent with the rest of gpiod_get() like API, i.e. configure GPIO pin immediately after request. Besides obvious clean up it will help to configure pins based on firmware provided resources. Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
739e6f59 |
|
11-Jan-2017 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: provide lockdep keys for nested/unnested irqchips The helper function for adding a GPIO chip compiles in a lockdep key for debugging, the same key is needed for nested chips as well. The macro construction is unreadable, replace this with two static inlines instead. The _gpiochip_irqchip_add prefixed function is not helpful, rename it with gpiochip_irqchip_add_key() that tell us what the function is actually doing. Fixes: d245b3f9bd36 ("gpio: simplify adding threaded interrupts") Cc: Roger Quadros <rogerq@ti.com> Reported-by: Clemens Gruber <clemens.gruber@pqgruber.com> Reported-by: Roger Quadros <rogerq@ti.com> Reported-by: Grygorii Strashko <grygorii.strashko@ti.com> Tested-by: Clemens Gruber <clemens.gruber@pqgruber.com> Tested-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
fb505747 |
|
09-Jan-2017 |
Stephen Boyd <sboyd@codeaurora.org> |
gpio: Remove impossible checks on container_of() result container_of() does pointer math on the pointer that's passed in. If it were to return a NULL pointer the value passed in would need to be perfectly offset from 0 to make that so. Remove these checks because they don't make sense. Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
5e4e6fb3 |
|
03-Jan-2017 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: Switch to for_each_set_bit() The macro for_each_set_bit() effectively looks up to the next set bit in array of bits. Instead of open coding that switch to for_each_set_bit() in gpio_chip_set_multiple(). While here, make gpio_chip_set_multiple() non-destructive against its parameters. We are safe since all callers, i.e. gpiod_set_array_value_complex(), handle that already. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
5018ada6 |
|
19-Dec-2016 |
Geert Uytterhoeven <geert@linux-m68k.org> |
gpio: Move freeing of GPIO hogs before numbing of the device When removing a gpiochip that uses GPIO hogging (e.g. by unloading the chip's DT overlay), a warning is printed: gpio gpiochip8: REMOVING GPIOCHIP WITH GPIOS STILL REQUESTED This happens because gpiochip_free_hogs() is called after the gdev->chip pointer is reset to NULL. Hence __gpiod_free() cannot determine the chip in use, and cannot clear flags nor call the optional chip-specific .free() callback. Move the call to gpiochip_free_hogs() up to fix this. Cc: stable@vger.kernel.org Fixes: ff2b135922992756 ("gpio: make the gpiochip a real device") Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
f4e81c52 |
|
30-Nov-2016 |
Lars-Peter Clausen <lars@metafoo.de> |
gpio: chardev: Return error for seek operations The GPIO chardev is used for management tasks (allocating line and event handles) and does neither support read() nor write() operations. Hence it does not make much sense to allow seek operations. Currently the chardev uses noop_llseek() for its seek implementation. This function does not move the pointer and simply returns the current position (always 0 for the GPIO chardev). noop_llseek() is primarily meant for devices that can not support seek, but where there might be a user that depends on the seek() operation succeeding. For newly added devices that can not support seek operations it is recommended to use no_llseek(), which will return an error. For more information see commit 6038f373a3dc ("llseek: automatically add .llseek fop"). Unfortunately this was overlooked when the GPIO chardev ABI was introduced. But it is highly unlikely that since then userspace applications have appeared that rely on being able to perform non-failing seek operations on a GPIO chardev file descriptor. So it should be safe to change from noop_llseel() to no_seek(). Also use nonseekable_open() in the chardev open() callback to clear the FMODE_SEEK, FMODE_PREAD and FMODE_PWRITE flags from the file. Neither of these should be set on a file that does not support seek operations. Cc: stable@vger.kernel.org Fixes: 3c702e9987e2 ("gpio: add a userspace chardev ABI for GPIOs") Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
d245b3f9 |
|
24-Nov-2016 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: simplify adding threaded interrupts This tries to simplify the use of CONFIG_GPIOLIB_IRQCHIP when using threaded interrupts: add a new call gpiochip_irqchip_add_nested() to indicate that we're dealing with a nested rather than a chained irqchip, then create a separate gpiochip_set_nested_irqchip() to mirror the gpiochip_set_chained_irqchip() call to connect the parent and child interrupts. In the nested case gpiochip_set_nested_irqchip() does nothing more than call irq_set_parent() on each valid child interrupt, which has little semantic effect in the kernel, but this is probably still formally correct. Update all drivers using nested interrupts to use gpiochip_irqchip_add_nested() so we can now see clearly which these users are. The DLN2 driver can drop its specific hack with .irq_not_threaded as we now recognize whether a chip is threaded or not from its use of gpiochip_irqchip_add_nested() signature rather than from inspecting .can_sleep. We rename the .irq_parent to .irq_chained_parent since this parent IRQ is only really kept around for the chained interrupt handlers. Cc: Lars Poeschel <poeschel@lemonage.de> Cc: Octavian Purdila <octavian.purdila@intel.com> Cc: Daniel Baluta <daniel.baluta@intel.com> Cc: Bin Gao <bin.gao@linux.intel.com> Cc: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Ajay Thomas <ajay.thomas.david.rajamanickam@intel.com> Cc: Semen Protsenko <semen.protsenko@globallogic.com> Cc: Alexander Stein <alexander.stein@systec-electronic.com> Cc: Phil Reid <preid@electromag.com.au> Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com> Cc: Patrice Chotard <patrice.chotard@st.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
3940c34a |
|
13-Nov-2016 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: tag line labels used for interrupts When a GPIO line is marked as used for an interrupt, it is helpful to set the label to "interrupt" so we know what is going on when inspecting the lines. If a GPIO is already properly named by gpiod_get*() we don't need to do this. It only happens when a line is used from the irqchip side of a GPIO driver without communicating with the GPIO side, such as when gpiochip is used as interrupt provider in the device tree. If the line is still marked as used by "interrupt" when we unmark it as used by an interrupt, also remove this label from the descriptor. Also shape up the code around unmarking IRQ lines. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
ad17731d |
|
13-Nov-2016 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: clamp values on gpio[d]_direction_output() I saw weird values != [0,1] being passed down to drivers in their .set_direction_output() callbacks. Go over the gpiolib and make sure to hammer it to [0,1] before hitting the driver to avoid undesired side effects. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
60f8339e |
|
12-Nov-2016 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: do not double-check direction on sleeping chips When locking a GPIO line as IRQ, we go to lengths to double-check that the line is really set as input before marking it as used for IRQ. This is not good on GPIO chips that can sleep, because this function is called in IRQ-safe context. Just skip this if it can't be checked quickly. Currently this happens on sleeping expanders such as STMPE or TC3589x: BUG: scheduling while atomic: swapper/1/0x00000002 Modules linked in: CPU: 0 PID: 1 Comm: swapper Not tainted 4.9.0-rc1+ #38 Hardware name: Nomadik STn8815 [<c000f2e0>] (unwind_backtrace) from [<c000d244>] (show_stack+0x10/0x14) [<c000d244>] (show_stack) from [<c0037b78>] (__schedule_bug+0x54/0x80) [<c0037b78>] (__schedule_bug) from [<c042df14>] (__schedule+0x3a0/0x460) [<c042df14>] (__schedule) from [<c042e028>] (schedule+0x54/0xb8) (...) This patch fixes that problem and relies on the direction read from the chip when it was added. Cc: stable@vger.kernel.org Fixes: 9c10280d85c1 ("gpio: flush direction status in gpiochip_lock_as_irq()") Cc: Patrice Chotard <patrice.chotard@st.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
953b956a |
|
24-Oct-2016 |
Lars-Peter Clausen <lars@metafoo.de> |
gpio: GPIO_GET_LINE{HANDLE,EVENT}_IOCTL: Fix file descriptor leak When allocating a new line handle or event a file is allocated that it is associated to. The file is attached to a file descriptor of the current process and the file descriptor is returned to userspace using copy_to_user(). If this copy operation fails the line handle or event allocation is aborted, all acquired resources are freed and an error is returned. But the file struct is not freed and left attached to the userspace application and even though the file descriptor number was not copied it is trivial to guess. If a userspace application performs a IOCTL on such a left over file descriptor it will trigger a use-after-free and if the file descriptor is closed (latest when the application exits) a double-free is triggered. anon_inode_getfd() performs 3 tasks, allocate a file struct, allocate a file descriptor for the current process and install the file struct in the file descriptor. As soon as the file struct is installed in the file descriptor it is accessible by userspace (even if the IOCTL itself hasn't completed yet), this means uninstalling the fd on the error path is not an option, since userspace might already got a reference to the file. Instead anon_inode_getfd() needs to be broken into its individual steps. The allocation of the file struct and file descriptor is done first, then the copy_to_user() is executed and only if it succeeds the file is installed. Since the file struct is reference counted it can not be just freed, but its reference needs to be dropped, which will also call the release() callback, which will free the state attached to the file. So in this case the normal error cleanup path should not be taken. Cc: stable@vger.kernel.org Fixes: d932cd49182f ("gpio: free handles in fringe cases") Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
ac7dbb99 |
|
18-Oct-2016 |
Lars-Peter Clausen <lars@metafoo.de> |
gpio: GPIO_GET_LINEEVENT_IOCTL: Reject invalid line and event flags The GPIO_GET_LINEEVENT_IOCTL currently ignores unknown or undefined linehandle and lineevent flags. From a backwards and forwards compatibility viewpoint it is highly desirable to reject unknown flags though. On one hand an application that is using newer flags and is running on an older kernel has no way to detect if the new flags were handled correctly if they are silently discarded. On the other hand an application that (accidentally) passes undefined flags will run fine on an older kernel, but may break on a newer kernel when these flags get defined. Ensure that requests that have undefined flags set are rejected with an error, rather than silently discarding the undefined flags. Cc: stable@vger.kernel.org Fixes: 61f922db7221 ("gpio: userspace ABI for reading GPIO line events") Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
e3e847c7 |
|
18-Oct-2016 |
Lars-Peter Clausen <lars@metafoo.de> |
gpio: GPIO_GET_LINEHANDLE_IOCTL: Reject invalid line flags The GPIO_GET_LINEHANDLE_IOCTL currently ignores unknown or undefined linehandle flags. From a backwards and forwards compatibility viewpoint it is highly desirable to reject unknown flags though. On one hand an application that is using newer flags and is running on an older kernel has no way to detect if the new flags were handled correctly if they are silently discarded. On the other hand an application that (accidentally) passes undefined flags will run fine on an older kernel, but may break on a newer kernel when these flags get defined. Ensure that requests that have undefined flags set are rejected with an error, rather than silently discarding the undefined flags. Cc: stable@vger.kernel.org Fixes: d7c51b47ac11 ("gpio: userspace ABI for reading/writing GPIO lines") Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
3eded5d8 |
|
18-Oct-2016 |
Lars-Peter Clausen <lars@metafoo.de> |
gpio: GPIOHANDLE_GET_LINE_VALUES_IOCTL: Fix information leak The GPIOHANDLE_GET_LINE_VALUES_IOCTL handler allocates a gpiohandle_data struct on the stack and then passes it to copy_to_user(). But depending on the number of requested line handles the struct is only partially initialized. This exposes the previous, potentially sensitive, stack content to the issuing userspace application. To avoid this make sure that the struct is fully initialized. Cc: stable@vger.kernel.org Fixes: d7c51b47ac11 ("gpio: userspace ABI for reading/writing GPIO lines") Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
b8b0e3d3 |
|
18-Oct-2016 |
Lars-Peter Clausen <lars@metafoo.de> |
gpio: GPIO_GET_LINEEVENT_IOCTL: Validate line offset The line offset that is used as an index into the descs array is provided by userspace and might go beyond the bounds of the array. If that happens undefined behavior will occur. Make sure that the offset is within the bounds of the desc array and reject any requests that specify a value outside of it. Cc: stable@vger.kernel.org Fixes: 61f922db7221 ("gpio: userspace ABI for reading GPIO line events") Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
d82aa4a8 |
|
18-Oct-2016 |
Lars-Peter Clausen <lars@metafoo.de> |
gpio: GPIOHANDLE_GET_LINE_VALUES_IOCTL: Fix information leak The GPIOHANDLE_GET_LINE_VALUES_IOCTL handler allocates a gpiohandle_data struct on the stack and then passes it to copy_to_user(). But only the first element of the values array in the struct is set, which leaves the struct partially initialized. This exposes the previous, potentially sensitive, stack content to the issuing userspace application. To avoid this make sure that the struct is fully initialized. Cc: stable@vger.kernel.org Fixes: 61f922db7221 ("gpio: userspace ABI for reading GPIO line events") Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
e405f9fc |
|
18-Oct-2016 |
Lars-Peter Clausen <lars@metafoo.de> |
gpio: GPIO_GET_LINEHANDLE_IOCTL: Validate line offset The line offset that is used as an index into the descs array is provided by userspace and might go beyond the bounds of the array. If that happens undefined behavior will occur. Make sure that the offset is within the bounds of the desc array and reject any requests that specify a value outside of it. Cc: stable@vger.kernel.org Fixes: d7c51b47ac11 ("gpio: userspace ABI for reading/writing GPIO lines") Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
0f4bbb23 |
|
18-Oct-2016 |
Lars-Peter Clausen <lars@metafoo.de> |
gpio: GPIO_GET_CHIPINFO_IOCTL: Fix information leak The GPIO_GET_CHIPINFO_IOCTL handler allocates a gpiochip_info struct on the stack and then passes it to copy_to_user(). But depending on the length of the GPIO chip name and label the struct is only partially initialized. This exposes the previous, potentially sensitive, stack content to the issuing userspace application. To avoid this make sure that the struct is fully initialized. Cc: stable@vger.kernel.org Fixes: 521a2ad6f862 ("gpio: add userspace ABI for GPIO line information") Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
1f1cc456 |
|
18-Oct-2016 |
Lars-Peter Clausen <lars@metafoo.de> |
gpio: GPIO_GET_CHIPINFO_IOCTL: Fix line offset validation The current line offset validation is off by one. Depending on the data stored behind the descs array this can either cause undefined behavior or disclose arbitrary, potentially sensitive, memory to the issuing userspace application. Make sure that offset is within the bounds of the desc array. Cc: stable@vger.kernel.org Fixes: 521a2ad6f862 ("gpio: add userspace ABI for GPIO line information") Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
031ba28a |
|
03-Oct-2016 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: acpi: separation of concerns The generic GPIO library directly implement code for acpi_find_gpio() which is only used with CONFIG_ACPI. This was probably done because OF did the same thing, but I removed that so remove this too. Rename the internal acpi_find_gpio() in gpiolib-acpi.c to acpi_populate_gpio_lookup() which seems to be more appropriate anyway so as to avoid a namespace clash with the same function. Make the stub return -ENOENT rather than -ENOSYS (as that is for syscalls!). For some reason the sunxi pin control driver was including the private gpiolib header, it works just fine without it so remove that oneliner. Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
ea713bc4 |
|
03-Oct-2016 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: OF: separation of concerns The generic GPIO library directly implement code for of_find_gpio() which is only used with CONFIG_OF and causes compilation problems on archs that do not even have stubs for OF functions, especially on UM that does not implement any IO remap functions. Move the function to gpiolib-of.c, implement a static inline stub in gpiolib.h returning PTR_ERR(-ENOENT) if CONFIG_OF_GPIO is not set and be done with it. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
79b804cb |
|
20-Sep-2016 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
gpiolib: Make it possible to exclude GPIOs from IRQ domain When using GPIO irqchip helpers to setup irqchip for a gpiolib based driver, it is not possible to select which GPIOs to add to the IRQ domain. Instead it just adds all GPIOs which is not always desired. For example there might be GPIOs that for some reason cannot generated normal interrupts at all. To support this we add a flag irq_need_valid_mask to struct gpio_chip. When this flag is set the core allocates irq_valid_mask that holds one bit for each GPIO the chip has. By default all bits are set but drivers can manipulate this using set_bit() and clear_bit() accordingly. Then when gpiochip_irqchip_add() is called, this mask is checked and all GPIOs with bit is set are added to the IRQ domain created for the GPIO chip. Suggested-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
0a1e0053 |
|
12-Sep-2016 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
gpiolib: Forbid irqchip default trigger for ACPI enumerated devices Follow DT and forbid default trigger if the GPIO irqchip device is enumerated from ACPI. Triggering for these devices will be configured automatically from ACPI interrupt resources provided by the BIOS. Suggested-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
332e99d5 |
|
07-Sep-2016 |
Marc Zyngier <maz@kernel.org> |
gpio/gpiolib: Forbid irqchip default trigger if probed over DT Using a default trigger is a bad idea if using DT to configure interrupts, as the device's interrupt specifier will always contain the trigger configuration. Let's warn about that particular situation, and revert to not having a default. Hopefully, the couple of drivers still using this feature will quickly be fixed. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
acf06ff7 |
|
11-Aug-2016 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
gpio: refactor gpiochip_find() slightly The if...else... block after the loop can be dropped with a slight refactoring. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
ee4fc401 |
|
05-Jul-2016 |
Wei Yongjun <yongjun_wei@trendmicro.com.cn> |
gpiolib: remove duplicated include from gpiolib.c Remove duplicated include. Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
78456d6f |
|
06-Jul-2016 |
Linus Walleij <linus.walleij@linaro.org> |
Revert "gpio: convince line to become input in irq helper" This reverts commit 7e7c059cb50c7c72d5a393b2c34fc57de1b01b55. I was wrong about trying to do this, as it breaks the orthogonality between gpiochips and irqchips. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
da17f8a1 |
|
01-Jul-2016 |
Lars-Peter Clausen <lars@metafoo.de> |
gpiolib: of_find_gpio(): Don't discard errors Since commit dd34c37aa3e8 ("gpio: of: Allow -gpio suffix for property names") when requesting a GPIO from the devicetree gpiolib looks for properties with both the '-gpio' and the '-gpios' suffix. This was implemented by first searching for the property with the '-gpios' suffix and if that yields an error try the '-gpio' suffix. This approach has the issue that any error returned when looking for the '-gpios' suffix is silently discarded. Commit 06fc3b70f1dc ("gpio: of: Fix handling for deferred probe for -gpio suffix") partially addressed the issue by treating the EPROBE_DEFER error as a special condition. This fixed the case when the property is specified, but the GPIO provider is not ready yet. But there are other cases in which of_get_named_gpiod_flags() returns an error even though the property is specified, e.g. if the specification is incorrect. of_find_gpio() should only try to look for the property with the '-gpio' suffix if no property with the '-gpios' suffix was found. If the property was not found of_get_named_gpiod_flags() will return -ENOENT, so update the condition to abort and propagate the error to the caller in all other cases. This is important for gpiod_get_optinal() and friends to behave correctly in case the specifier contains errors. Without this patch they'll return NULL if the property uses the '-gpios' suffix and the specifier contains errors, which falsely indicates to the caller that no GPIO was specified. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
acc6e331 |
|
05-Jul-2016 |
Thierry Reding <treding@nvidia.com> |
gpio: of: Allow overriding the device node When registering a GPIO chip, drivers can override the device tree node associated with the chip by setting the chip's ->of_node field. If set, this field is supposed to take precedence over the ->parent->of_node field, but the code doesn't actually do that. Commit 762c2e46c059 ("gpio: of: remove of_gpiochip_and_xlate() and struct gg_data") exposes this because it now no longer matches on the GPIO chip's ->of_node field, but the GPIO device's ->of_node field that is set using the procedure described above. Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
d932cd49 |
|
04-Jul-2016 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: free handles in fringe cases If we fail when copying the ioctl() struct to userspace we still need to clean up the cruft otherwise left behind or it will stay around until the issuing process terminates the file handle. Reported-by: Alexander Stein <alexander.stein@systec-electronic.com> Acked-by: Alexander Stein <alexander.stein@systec-electronic.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
85b03b30 |
|
03-Jul-2016 |
Johan Hovold <johan@kernel.org> |
Revert "gpiolib: Split GPIO flags parsing and GPIO configuration" This reverts commit 923b93e451db876d1479d3e4458fce14fec31d1c. Make sure consumers do not overwrite gpio flags for pins that have already been claimed. While adding support for gpio drivers to refuse a request using unsupported flags, the order of when the requested flag was checked and the new flags were applied was reversed to that consumers could overwrite flags for already requested gpios. This not only affects device-tree setups where two drivers could request the same gpio using conflicting configurations, but also allowed user space to clear gpio flags for already claimed pins simply by attempting to export them through the sysfs interface. By for example clearing the FLAG_ACTIVE_LOW flag this way, user space could effectively change the polarity of a signal. Reverting this change obviously prevents gpio drivers from doing sanity checks on the flags in their request callbacks. Fortunately only one recently added driver (gpio-tps65218 in v4.6) appears to do this, and a follow up patch could restore this functionality through a different interface. Cc: stable <stable@vger.kernel.org> # 4.4 Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
7e7c059c |
|
22-Jun-2016 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: convince line to become input in irq helper The generic IRQ helper library just checks if the IRQ line is set as input before activating it for interrupts. As we recently started to check things better with .get_dir() it turns out that it's good to try to convince the line to become an input before attempting to lock it as IRQ. Reviewed-by: Björn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
c0a1ecb9 |
|
16-Jun-2016 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: make library immune to error pointers Most functions that take a GPIO descriptor in need to check the descriptor for IS_ERR(). We do this mostly in the VALIDATE_DESC() macro except for the gpiod_to_irq() function which needs special handling. Cc: stable@vger.kernel.org Reported-by: Grygorii Strashko <grygorii.strashko@ti.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
39243ee7 |
|
15-Jun-2016 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: make sure gpiod_to_irq() returns negative on NULL desc commit 54d77198fdfbc4f0fe11b4252c1d9c97d51a3264 ("gpio: bail out silently on NULL descriptors") doesn't work for gpiod_to_irq(): drivers assume that NULL descriptors will give negative IRQ numbers in return. It has been pointed out that returning 0 is NO_IRQ and that drivers should be amended to treat this as an error, but that is for the longer term: now let us repair the semantics. Cc: Maxime Ripard <maxime.ripard@free-electrons.com> Reported-by: Hans de Goede <hdegoede@redhat.com> Tested-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
33265b17 |
|
17-Jun-2016 |
Ben Dooks <ben.dooks@codethink.co.uk> |
gpiolib: make lineevent_irq_thread static The lineevent_irq_thread is not exported, so make it static to fix the following warning: drivers/gpio/gpiolib.c:654:13: warning: symbol 'lineevent_irq_thread' was not declared. Should it be static? Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
e2f608be |
|
18-Jun-2016 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: make the iterator point to last handle When initializing the GPIO handles, we use the iterator (i) to back off if something goes wrong. But since the iterator is also used after we pass the loop, we must decrement by one after exiting the loop so that we point at the last element in the array. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Cc: Dan Carpenter <dan.carpenter@oracle.com> Cc: Walter Harms <wharms@bfs.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
bfbbe44d |
|
16-Jun-2016 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: make library immune to error pointers Most functions that take a GPIO descriptor in need to check the descriptor for IS_ERR(). We do this mostly in the VALIDATE_DESC() macro except for the gpiod_to_irq() function which needs special handling. Cc: stable@vger.kernel.org Reported-by: Grygorii Strashko <grygorii.strashko@ti.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
79bb71bd |
|
15-Jun-2016 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: make sure gpiod_to_irq() returns negative on NULL desc commit 54d77198fdfbc4f0fe11b4252c1d9c97d51a3264 ("gpio: bail out silently on NULL descriptors") doesn't work for gpiod_to_irq(): drivers assume that NULL descriptors will give negative IRQ numbers in return. It has been pointed out that returning 0 is NO_IRQ and that drivers should be amended to treat this as an error, but that is for the longer term: now let us repair the semantics. Cc: Maxime Ripard <maxime.ripard@free-electrons.com> Reported-by: Hans de Goede <hdegoede@redhat.com> Tested-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
bc0207a5 |
|
16-Jun-2016 |
Arnd Bergmann <arnd@arndb.de> |
gpiolib: avoid uninitialized data in gpio kfifo gcc reports a theoretical case for returning uninitialized data in the kfifo when a GPIO interrupt happens and neither GPIOEVENT_REQUEST_RISING_EDGE nor GPIOEVENT_REQUEST_FALLING_EDGE are set: drivers/gpio/gpiolib.c: In function 'lineevent_irq_thread': drivers/gpio/gpiolib.c:683:87: error: 'ge.id' may be used uninitialized in this function [-Werror=maybe-uninitialized] This case should not happen, but to be on the safe side, let's return from the irq handler without adding data to the FIFO to ensure we can never leak stack data to user space. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 61f922db7221 ("gpio: userspace ABI for reading GPIO line events") Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
61f922db |
|
02-Jun-2016 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: userspace ABI for reading GPIO line events This adds an ABI for listening to events on GPIO lines. The mechanism returns an anonymous file handle to a request to listen to a specific offset on a specific gpiochip. To fetch the stream of events from the file handle, userspace simply reads an event. - Events can be requested with the same flags as ordinary handles, i.e. open drain or open source. An ioctl() call GPIO_GET_LINEEVENT_IOCTL is issued indicating the desired line. - Events can be requested for falling edge events, rising edge events, or both. - All events are timestamped using the kernel real time nanosecond timestamp (the same as is used by IIO). - The supplied consumer label will appear in "lsgpio" listings of the lines, and in /proc/interrupts as the mechanism will request an interrupt from the gpio chip. - Events are not supported on gpiochips that do not serve interrupts (no legal .to_irq() call). The event interrupt is threaded to avoid any realtime problems. - It is possible to also directly read the current value of the registered GPIO line by issuing the same GPIOHANDLE_GET_LINE_VALUES_IOCTL as used by the line handles. Setting the value is not supported: we do not listen to events on output lines. This ABI is strongly influenced by Industrial I/O and surpasses the old sysfs ABI by providing proper precision timestamps, making it possible to set flags like open drain, and put consumer names on the GPIO lines. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
d7c51b47 |
|
26-Apr-2016 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: userspace ABI for reading/writing GPIO lines This adds a userspace ABI for reading and writing GPIO lines. The mechanism returns an anonymous file handle to a request to read/write n offsets from a gpiochip. This file handle in turn accepts two ioctl()s: one that reads and one that writes values to the selected lines. - Handles can be requested as input/output, active low, open drain, open source, however when you issue a request for n lines with GPIO_GET_LINEHANDLE_IOCTL, they must all have the same flags, i.e. all inputs or all outputs, all open drain etc. If a granular control of the flags for each line is desired, they need to be requested individually, not in a batch. - The GPIOHANDLE_GET_LINE_VALUES_IOCTL read ioctl() can be issued also to output lines to verify that the hardware is in the expected state. - It reads and writes up to GPIOHANDLES_MAX lines at once, utilizing the .set_multiple() call in the driver if possible, making the call efficient if several lines can be written with a single register update. The limitation of GPIOHANDLES_MAX to 64 lines is done under the assumption that we may expect hardware that can issue a transaction updating 64 bits at an instant but unlikely anything larger than that. ChangeLog v2->v3: - Use gpiod_get_value_cansleep() so we support also slowpath GPIO drivers. - Fix up the UAPI docs kerneldoc. - Allocate the anonymous fd last, so that the release function don't get called until that point of something fails. After this point, skip the errorpath. ChangeLog v1->v2: - Handle ioctl_compat() properly based on a similar patch to the other ioctl() handling code. - Use _IOWR() as we pass pointers both in and out of the ioctl() - Use kmalloc() and kfree() for the linehandled, do not try to be fancy with devm_* it doesn't work the way I thought. - Fix const-correctness on the linehandle name field. Acked-by: Michael Welling <mwelling@ieee.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
f4833b8c |
|
03-Jun-2016 |
Ricardo Ribalda <ribalda@kernel.org> |
gpiolib: Fix unaligned used of reference counters gpiolib relies on the reference counters to clean up the gpio_device structure. Although the number of get/put is properly aligned on gpiolib.c itself, it does not take into consideration how the referece counters are affected by other external functions such as cdev_add and device_add. Because of this, after the last call to put_device, the reference counter has a value of +3, therefore never calling gpiodevice_release. Due to the fact that some of the device has already been cleaned on gpiochip_remove, the library will end up OOPsing the kernel (e.g. a call to of_gpiochip_find_and_xlate). Cc: stable@vger.kernel.org Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
11f33a6d |
|
03-Jun-2016 |
Ricardo Ribalda <ribalda@kernel.org> |
gpiolib: Fix NULL pointer deference Under some circumstances, a gpiochip might be half cleaned from the gpio_device list. This patch makes sure that the chip pointer is still valid, before calling the match function. [ 104.088296] BUG: unable to handle kernel NULL pointer dereference at 0000000000000090 [ 104.089772] IP: [<ffffffff813d2045>] of_gpiochip_find_and_xlate+0x15/0x80 [ 104.128273] Call Trace: [ 104.129802] [<ffffffff813d2030>] ? of_parse_own_gpio+0x1f0/0x1f0 [ 104.131353] [<ffffffff813cd910>] gpiochip_find+0x60/0x90 [ 104.132868] [<ffffffff813d21ba>] of_get_named_gpiod_flags+0x9a/0x120 ... [ 104.141586] [<ffffffff8163d12b>] gpio_led_probe+0x11b/0x360 Cc: stable@vger.kernel.org Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
545ebd9a |
|
30-May-2016 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: drop lock before reading GPIO direction When adding the gpiochip, the GPIO HW drivers' callback get_direction() could get called in atomic context. Some of the GPIO HW drivers may sleep when accessing the register. Move the lock before initializing the descriptors. Reported-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
54d77198 |
|
30-May-2016 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: bail out silently on NULL descriptors In fdeb8e1547cb9dd39d5d7223b33f3565cf86c28e ("gpio: reflect base and ngpio into gpio_device") assumed that GPIO descriptors are either valid or error pointers, but gpiod_get_[index_]optional() actually return NULL descriptors and then all subsequent calls should just bail out. Cc: stable@vger.kernel.org Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: Andrew Lunn <andrew@lunn.ch> Fixes: fdeb8e1547cb ("gpio: reflect base and ngpio into gpio_device") Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
8b92e17e |
|
27-May-2016 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: handle compatible ioctl() pointers If we're using the compatible ioctl() we need to handle the argument pointer in a special way or there will be trouble. Fixes: 3c702e9987e2 ("gpio: add a userspace chardev ABI for GPIOs") Reported-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
9c10280d |
|
25-May-2016 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: flush direction status in gpiochip_lock_as_irq() As irqchip and gpiochip functions are orthogonal, the IRQ set-up or something else can have changed the direction of the GPIO line from what the GPIO descriptor knows when we get into gpiochip_lock_as_irq(). Make sure to re-read the direction setting if we have the .get_direction() callback enabled for the chip. Else we get problems like this: iio iio:device2: interrupts on the rising edge gpio gpiochip2: (8012e080.gpio): gpiochip_lock_as_irq: tried to flag a GPIO set as output for IRQ gpio gpiochip2: (8012e080.gpio): unable to lock HW IRQ 0 for IRQ genirq: Failed to request resources for l3g4200d-trigger (irq 111) on irqchip nmk1-32-63 iio iio:device2: failed to request trigger IRQ. st-gyro-i2c: probe of 2-0068 failed with error -22 Fixes: 72d320006177 ("gpio: set up initial state from .get_direction()") Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
4c37ce86 |
|
02-May-2016 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: make gpiod_to_irq() return negative for NO_IRQ If a translation returns zero, that means NO_IRQ, so we should return an error since the function is documented to return a negative code on error. Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
72d32000 |
|
28-Apr-2016 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: set up initial state from .get_direction() If the gpiochip supports the .get_direction() callback, then the initial state of the descriptor flags should be set up as output accordingly. Also put in comments explaining what is going on. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
44c7288f |
|
24-Apr-2016 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: move gpiod_set_array_value_priv() This renames gpiod_set_array_value_priv() to gpiod_set_array_value_complex() and moves it to the gpiolib.h private header file so we can reuse it in the subsystem. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
c31a571d |
|
11-Mar-2016 |
Laxman Dewangan <ldewangan@nvidia.com> |
gpio: gpiolib: Print error number if gpio hog failed Print the error number of GPIO hog failed during its configurations. This helps in identifying the failure without instrumenting the code. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
159f3cd9 |
|
31-Mar-2016 |
Guenter Roeck <linux@roeck-us.net> |
gpiolib: Defer gpio device setup until after gpiolib initialization Since commit ff2b13592299 ("gpio: make the gpiochip a real device"), attempts to add a gpio chip prior to gpiolib initialization cause the system to crash. This happens because gpio_bus_type has not been registered yet. Defer creating gpio devices until after gpiolib has been initialized to fix the problem. Cc: Greg Ungerer <gerg@uclinux.org> Cc: Alexandre Courbot <gnurou@gmail.com> Fixes: ff2b13592299 ("gpio: make the gpiochip a real device") Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
476e2fc5 |
|
31-Mar-2016 |
Guenter Roeck <linux@roeck-us.net> |
gpiolib: Do not use devm functions when registering gpio chip It is possible that a gpio chip is registered before the gpiolib initialization code has run. This means we can not use devm_ functions to allocate memory at that time. Do it the old fashioned way. Cc: Alexandre Courbot <gnurou@gmail.com> Cc: Greg Ungerer <gerg@uclinux.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
25487533 |
|
24-Mar-2016 |
Dmitry Torokhov <dtor@chromium.org> |
gpio / ACPI: ignore GpioInt() GPIOs when requesting GPIO_OUT_* When firmware does not use _DSD properties that allow properly name GPIO resources, the kernel falls back on parsing _CRS resources, and will return entries described as GpioInt() as general purpose GPIOs even though they are meant to be used simply as interrupt sources for the device: Device (ETSA) { Name (_HID, "ELAN0001") ... Method(_CRS, 0x0, NotSerialized) { Name(BUF0,ResourceTemplate () { I2CSerialBus( 0x10, /* SlaveAddress */ ControllerInitiated, /* SlaveMode */ 400000, /* ConnectionSpeed */ AddressingMode7Bit, /* AddressingMode */ "\\_SB.I2C1", /* ResourceSource */ ) GpioInt (Edge, ActiveLow, ExclusiveAndWake, PullNone,, "\\_SB.GPSW") { BOARD_TOUCH_GPIO_INDEX } } ) Return (BUF0) } ... } This gives troubles with drivers such as Elan Touchscreen driver (elants_i2c) that uses devm_gpiod_get to look up "reset" GPIO line and decide whether the driver is responsible for powering up and resetting the device, or firmware is. In the above case the lookup succeeds, we map GPIO as output and later fail to request client->irq interrupt that is mapped to the same GPIO. Let's ignore resources described as GpioInt() while parsing _CRS when requesting output GPIOs (but allow them when requesting GPIOD_ASIS or GPIOD_IN as some drivers, such as i2c-hid, do request GPIO as input and then map it to interrupt with gpiod_to_irq). Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Dmitry Torokhov <dtor@chromium.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
c663e5f5 |
|
22-Mar-2016 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: support native single-ended hardware drivers Some GPIO controllers has a special hardware bit we can flip to support open drain / source. This means that on these hardwares we do not need to emulate OD/OS by setting the line to input instead of actively driving it high/low. Add an optional vtable callback to the driver set_single_ended() so that driver can implement this in hardware if they have it. We may need a pinctrl_gpio_set_config() call at some point to propagate this down to a backing pin control device on systems with split GPIO/pin control. Reported-by: Michael Hennerich <michael.hennerich@analog.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
1cfab8f8 |
|
14-Mar-2016 |
Geert Uytterhoeven <geert+renesas@glider.be> |
gpiolib: Fix comment referring to gpio_*() in gpiod_*() Fixes: 79a9becda8940deb ("gpiolib: export descriptor-based GPIO interface") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
a961f9b4 |
|
26-Feb-2016 |
Bamvor Jian Zhang <bamvor.zhangjian@linaro.org> |
gpiolib: rewrite gpiodev_add_to_list The original code of gpiodev_add_to_list is not very clear which lead to bugs or compiling warning, reference the following patches: Bugs: 1. Commit ef7c7553039b ("gpiolib: improve overlap check of range of gpio"). 2. Commit 96098df125c0 ("gpiolib: fix chip order in gpio list") Warning: 1. Commit e28ecca6eac4 ("gpio: fix warning about iterator"). of gpio"). There is a off-list discussion about how to improve it consequently. This commit try to follow this by rewriting the whole functions. Tested pass with my gpio mockup driver and test scripts[1]. [1] http://www.spinics.net/lists/linux-gpio/msg09598.html Suggested-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Bamvor Jian Zhang <bamvor.zhangjian@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
214338e3 |
|
25-Feb-2016 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: present the consumer of a line to userspace I named the field representing the current user of GPIO line as "label" but this is too vague and ambiguous. Before anyone gets confused, rename it to "consumer" and indicate clearly in the documentation that this is a string set by the user of the line. Also clean up leftovers in the documentation. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
0cf3292c |
|
15-Feb-2016 |
Laxman Dewangan <ldewangan@nvidia.com> |
gpio: Add devm_ apis for gpiochip_add_data and gpiochip_remove Add device managed APIs devm_gpiochip_add_data() and devm_gpiochip_remove() for the APIs gpiochip_add_data() and gpiochip_remove(). This helps in reducing code in error path and sometimes removal of .remove callback for driver unbind. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
|
#
9d8cc89c |
|
22-Feb-2016 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: fixup line flags for userspace ABI This fixes the wrongly indicated lines in the userspace ABI: test for the right BITS, do not treat bit numbers as bitmasks. Reported-by: Markus Pargmann <mpa@pengutronix.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
bd203bd5 |
|
19-Feb-2016 |
Bamvor Jian Zhang <bamvor.zhangjian@linaro.org> |
gpiolib: fix crash when gpiochip removed Commit cb464a88e1ed ("gpio: make the gpiochip a real device") call gpiochip_sysfs_unregister after the gpiochip is empty. It lead to the following crash: [ 163.503994] Unable to handle kernel NULL pointer dereference at virtual address 0000007c [...] [ 163.525394] [<ffffffc0003719a0>] gpiochip_sysfs_unregister+0x44/0xa4 [ 163.525611] [<ffffffc00036f6a0>] gpiochip_remove+0x24/0x154 [ 163.525861] [<ffffffbffc00f0a4>] mockup_gpio_remove+0x38/0x64 [gpio_mockup] [ 163.526101] [<ffffffc00042b4b4>] platform_drv_remove+0x24/0x64 [ 163.526313] [<ffffffc000429cc8>] __device_release_driver+0x7c/0xfc [ 163.526525] [<ffffffc000429e54>] driver_detach+0xbc/0xc0 [ 163.526700] [<ffffffc000429014>] bus_remove_driver+0x58/0xac [ 163.526883] [<ffffffc00042a4cc>] driver_unregister+0x2c/0x4c [ 163.527067] [<ffffffc00042b5c0>] platform_driver_unregister+0x10/0x18 [ 163.527284] [<ffffffbffc00f340>] mock_device_exit+0x10/0x38 [gpio_mockup] [ 163.527593] [<ffffffc00011cefc>] SyS_delete_module+0x1b8/0x1fc [ 163.527799] [<ffffffc000085d8c>] __sys_trace_return+0x0/0x4 [ 163.528049] Code: 940d74b4 f9019abf aa1303e0 940d7439 (7940fac0) [ 163.536273] ---[ end trace 3d1329be504af609 ]--- This patch fix this by changing the code back. Signed-off-by: Bamvor Jian Zhang <bamvor.zhangjian@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
521a2ad6 |
|
12-Feb-2016 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: add userspace ABI for GPIO line information This adds a GPIO line ABI for getting name, label and a few select flags from the kernel. This hides the kernel internals and only tells userspace what it may need to know: the different in-kernel consumers are masked behind the flag "kernel" and that is all userspace needs to know. However electric characteristics like active low, open drain etc are reflected to userspace, as this is important information. We provide information on all lines on all chips, later on we will likely add a flag for the chardev consumer so we can filter and display only the lines userspace actually uses in e.g. lsgpio, but then we first need an ABI for userspace to grab and use (get/set/select direction) a GPIO line. Sample output from "lsgpio" on ux500: GPIO chip: gpiochip7, "8011e000.gpio", 32 GPIO lines line 0: unnamed unlabeled line 1: unnamed unlabeled (...) line 25: unnamed "SFH7741 Proximity Sensor" [kernel output open-drain] line 26: unnamed unlabeled (...) Tested-by: Michael Welling <mwelling@ieee.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
df4878e9 |
|
12-Feb-2016 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: store reflect the label to userspace The gpio_chip label is useful for userspace to understand what kind of GPIO chip it is dealing with. Let's store a copy of this label in the gpio_device, add it to the struct passed to userspace for GPIO_GET_CHIPINFO_IOCTL and modify lsgpio to show it. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
969f07b4 |
|
17-Feb-2016 |
Josh Cartwright <joshc@ni.com> |
gpio: use kzalloc to allocate gpio_device The use of kmalloc() to allocate the gpio_device leaves the contained struct device object in an unknown state. Calling dev_set_name() on a struct device of unknown state can trigger the free() of an invalid pointer, as seen in the following backtrace (collected by Tony Lindgren): kfree kobject_set_name_vargs dev_set_name gpiochip_add_data omap_gpio_probe platform_drv_probe ... Reported-by: Geert Uytterhoeven <geert+renesas@glider.be> Reported-by: Michael Welling <mwelling@ieee.org> Reported-by: Tony Lindgren <tony@atomide.com> Tested-by: Michael Welling <mwelling@ieee.org> Tested-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Josh Cartwright <joshc@ni.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
143b65d6 |
|
16-Feb-2016 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: create an API to detect open drain/source on lines My left hand merges code to privatize the descriptor handling while my right hand merges drivers that poke around and disrespect with the same gpiolib internals. So let's expose the proper APIs for drivers to ask the gpiolib core if a line is marked as open drain or open source and get some order around things so this driver compiles again. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Nicolas Saenz Julienne <nicolassaenzj@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
43c54eca |
|
11-Feb-2016 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: move the subdriver data pointer into gpio_device We move to manage this pointer under gpiolib control rather than leave it in the subdevice's gpio_chip. We can not NULL it after gpiochip_remove so at to keep things tight. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
20ec3e39 |
|
11-Feb-2016 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: move the pin ranges into gpio_device Instead of keeping this reference to the pin ranges in the client driver-supplied gpio_chip, move it to the internal gpio_device as the drivers have no need to inspect this. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
33a68e86 |
|
11-Feb-2016 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: reference count the gpio device for each desc Every time a descriptor is retrieved from the gpiolib, we issue module_get() to reference count the module supplying the GPIOs. We also need to call device_get() and device_put() as we also reference the backing gpio_device when doing this. Since the sysfs GPIO interface is using gpiod_get() this will also reference count the sysfs requests until all GPIOs are unexported. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
fdeb8e15 |
|
10-Feb-2016 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: reflect base and ngpio into gpio_device Some information about the GPIO chip need to stay around also after the gpio_chip has been removed and only the gpio_device persist. The base and ngpio are such things, for example we don't want a new chip arriving to overlap the number space of a dangling gpio_device, and the chardev may still query the device for the number of lines etc. Note that the code that assigns base and insert gpio_device into the global list no longer check for a missing gpio_chip: we respect the number space allocated by any other gpio_device. As a consequence of the gdev being referenced directly from the gpio_desc, we need to verify it differently from all in-kernel API calls that fall through to direct queries to the gpio_chip vtable: we first check that desc is !NULL, then that desc->gdev is !NULL, then, if desc->gdev->chip is NULL, we *BAIL OUT* without any error, so as to manage the case where operations are requested on a device that is gone. These checks were non-uniform and partly missing in the past: so to simplify: create the macros VALIDATE_DESC() that will return -EINVAL if the desc or desc->gdev is missing and just 0 if the chip is gone, and conversely VALIDATE_DESC_VOID() for the case where the function does not return an error. By using these macros, we get warning messages about missing gdev with reference to the right function in the kernel log. Despite the macro business this simplifies the code and make it more readable than if we copy/paste the same descriptor checking code into all code ABI call sites (IMHO). Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
6cee3821 |
|
11-Feb-2016 |
Linus Walleij <linus.walleij@linaro.org> |
gpio/pinctrl: sunxi: stop poking around in private vars This kind of hacks disturbs the refactoring of the gpiolib. The descriptor table belongs to the gpiolib, if we want to know something about something in it, use or define the proper accessor functions. Let's add this gpiochip_lins_is_irq() to do what the sunxi driver is trying at so we can privatize the descriptors properly. Cc: Maxime Ripard <maxime.ripard@free-electrons.com> Cc: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
1c3cdb18 |
|
09-Feb-2016 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: move descriptors into gpio_device We need gpio_device to hold the descriptors so that they can be lifecycled with the struct gpio_device held from userspace. Move the descriptor array into gpio_device. Also rename it from "desc" (singularis) to "descs" (pluralis) to reflect the fact that it is an array. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
afbc4f31 |
|
09-Feb-2016 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: move sysfs mock device to the gpio_device Since gpio_device is the struct that survives if the backing gpio_chip is removed, move the sysfs mock device to this state container so it becomes part of the dangling state of the GPIO device on removal. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
9efd9e69 |
|
09-Feb-2016 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: remember to finally free gpio_device When the device core reference count for the device goes to 0 and it calls .release() we free resources and so can also finally free up the GPIO state container, struct gpio_device. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
3c702e99 |
|
21-Oct-2015 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: add a userspace chardev ABI for GPIOs A new chardev that is to be used for userspace GPIO access is added in this patch. It is intended to gradually replace the horribly broken sysfs ABI. Using a chardev has many upsides: - All operations are per-gpiochip, which is the actual device underlying the GPIOs, making us tie in to the kernel device model properly. - Hotpluggable GPIO controllers can come and go, as this kind of problem has been know to userspace for character devices since ages, and if a gpiochip handle is held in userspace we know we will break something, whereas the sysfs is stateless. - The one-value-per-file rule of sysfs is really hard to maintain when you want to twist more than one knob at a time, for example have in-kernel APIs to switch several GPIO lines at the same time, and this will be possible to do with a single ioctl() from userspace, saving a lot of context switching. We also need to add a new bus type for GPIO. This is necessary for example for userspace coldplug, where sysfs is traversed to find the boot-time device nodes and create the character devices in /dev. This new chardev ABI is *non* *optional* and can be counted on to be present in the future, emphasizing the preference of this ABI. The ABI only implements one single ioctl() to get the name and number of GPIO lines of a chip. Even this is debatable: see it as a minimal example for review. This ABI shall be ruthlessly reviewed and etched in stone. The old /sys/class/gpio is still optional to compile in, but will be deprecated. Unique device IDs are created using IDR, which is overkill and insanely scalable, but also well tested. Cc: Johan Hovold <johan@kernel.org> Cc: Michael Welling <mwelling@ieee.org> Cc: Markus Pargmann <mpa@pengutronix.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
34ffd85d |
|
20-Oct-2015 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: refer to gpio device in prints and debugfs We use the new struct device inside gpio_chip to related debug prints and warnings, and we also add it to the debugfs dump. Cc: Johan Hovold <johan@kernel.org> Cc: Michael Welling <mwelling@ieee.org> Cc: Markus Pargmann <mpa@pengutronix.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
ff2b1359 |
|
20-Oct-2015 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: make the gpiochip a real device GPIO chips have been around for years, but were never real devices, instead they were piggy-backing on a parent device (such as a platform_device or amba_device) but this was always optional. GPIO chips could also exist without any device at all, with its struct device *parent (ex *dev) pointer being set to null. When sysfs was in use, a mock device would be created, with the optional parent assigned, or just floating orphaned with NULL as parent. If sysfs is active, it will use this device as parent. We now create a gpio_device struct containing a real struct device and move the subsystem over to using that. The list of struct gpio_chip:s is augmented to hold struct gpio_device:s and we find gpio_chips:s by first looking up the struct gpio_device. The struct gpio_device is designed to stay around even if the gpio_chip is removed, so as to satisfy users in userspace that need a backing data structure to hold the state of the session initiated with e.g. a character device even if there is no physical chip anymore. From this point on, gpiochips are devices. Cc: Johan Hovold <johan@kernel.org> Cc: Michael Welling <mwelling@ieee.org> Cc: Markus Pargmann <mpa@pengutronix.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
96098df1 |
|
07-Jan-2016 |
Julien Grossholtz <julien.grossholtz@savoirfairelinux.com> |
gpiolib: fix chip order in gpio list In some situations the gpio_list order is not correct. As a consequence gpiochip_find_base returns the same base number twice. This happens when a first ship is added with manual base number, then other ships are added using automatic base number. To prevent this behaviour, this patch add the new chip after the last element of the gpio list. Signed-off-by: Julien Grossholtz <julien.grossholtz@savoirfairelinux.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
09dd5f9e |
|
07-Dec-2015 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: fix misleading comment We are not relying on container_of() now that we have gpiochip_get_data(). Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
b08ea35a |
|
03-Dec-2015 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: add a data pointer to gpio_chip This adds a void * pointer to gpio_chip so that driver can assign and retrieve some states. This is done to get rid of container_of() calls for gpio_chips embedded inside state containers, so we can remove the need to have the gpio_chip or later (planned) struct gpio_device be dynamically allocated at registration time, so that its struct device can be properly reference counted and not bound to its parent device (e.g. a platform_device) but instead live on after unregistration if it is opened by e.g. a char device or sysfs. The data is added with the new function gpiochip_add_data() and for compatibility we add static inline wrapper function gpiochip_add() that will call gpiochip_add_data() with NULL as argument. The latter will be removed once we have exorcised gpiochip_add() from the kernel. gpiochip_get_data() is added as a static inline accessor for drivers to quickly get their data out. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
52044723 |
|
23-Dec-2015 |
Christophe Ricard <christophe.ricard@gmail.com> |
ACPI / gpio: Add irq_type when a GPIO is used as an interrupt When a GPIO is used as an interrupt in ACPI, the irq_type was not available for device driver. Make available polarity and triggering information in acpi_find_gpio by renaming acpi_gpio_info field active_low to polarity and adding triggering field (edge/level). For sanity, in gpiolib.c replace info.active_low by "info.polarity == GPIO_ACTIVE_LOW". Set the irq_type if necessary in acpi_dev_gpio_irq_get. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
e28ecca6 |
|
27-Dec-2015 |
Sudip Mukherjee <sudipm.mukherjee@gmail.com> |
gpio: fix warning about iterator We were getting build warning about "iterator" being used uninitialized. Use iterator properly to fix the build warning and in the process remove the variable "pos" which is not required now. Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
723a6303 |
|
21-Dec-2015 |
Linus Walleij <linus.walleij@linaro.org> |
Revert "gpio: revert get() to non-errorprogating behaviour" This reverts commit 45ad7db90b42555c8107f18ec6d6a1e9bce34860. We have fixed all the drivers that were returning ambious values not clamped to [0,1] or an error code, so return the error propagating behaviour of the API. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
45ad7db9 |
|
17-Dec-2015 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: revert get() to non-errorprogating behaviour commit e20538b82f1f ("gpio: Propagate errors from chip->get()") started to propagate errors from the .get() functions since we can get errors from the infrastructure of e.g. slowbus GPIO expanders. However it turns out a bunch of drivers relied on the core to clamp the value, so we need to revert to the old behaviour and go over all drivers and fix them to conform to the expectations of the core before we go back to propagating the error code. Cc: stable@vger.kernel.org # 4.3+ Cc: Bjorn Andersson <bjorn.andersson@sonymobile.com> Cc: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Fixes: e20538b82f1f ("gpio: Propagate errors from chip->get()") Reported-by: Michael Trimarchi <michael@amarulasolutions.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
10cf4899 |
|
11-Nov-2015 |
Dmitry Torokhov <dmitry.torokhov@gmail.com> |
gpiolib: tighten up ACPI legacy gpio lookups We should not fall back to the legacy unnamed gpio lookup style if the driver requests gpios with different names, because we'll give out the same gpio twice. Let's keep track of the names that were used for the device and only do the fallback for the first name used. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
c88402c2 |
|
18-Nov-2015 |
Bamvor Jian Zhang <bamvor.zhangjian@linaro.org> |
gpiolib: make comment consistent with code Commit f4d566a8a0e6 ("gpio: change member .dev to .parent") changes member of gpiochip from .dev to .parent. Update the corresponding comment. Signed-off-by: Bamvor Jian Zhang <bamvor.zhangjian@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
d06165b3 |
|
11-Nov-2015 |
Vladimir Zapolskiy <vz@mleia.com> |
gpiolib: fix oops, if gpio name is NULL Commit c0017ed71966 ("gpio: Introduce gpio descriptor 'name'") causes OOPS on boot on LPC32xx boards: Unable to handle kernel NULL pointer dereference at virtual address 00000000 CPU: 0 PID: 1 Comm: swapper Not tainted 4.3.0+ #707 Hardware name: LPC32XX SoC (Flattened Device Tree) task: c381baa0 ti: c381e000 task.ti: c381e000 PC is at strcmp+0x10/0x40 LR is at gpiochip_add+0x3d0/0x4d4 pc : [<>] lr : [<>] psr: a0000093 sp : c381fd60 ip : c381fd70 fp : c381fd6c [snip] Backtrace: [<>] (strcmp) from [<>] (gpiochip_add+0x3d0/0x4d4) [<>] (gpiochip_add) from [<>] (lpc32xx_gpio_probe+0x44/0x60) [<>] (lpc32xx_gpio_probe) from [<>] (platform_drv_probe+0x40/0x8c) [<>] (platform_drv_probe) from [<>] (driver_probe_device+0x110/0x294) [<>] (driver_probe_device) from [<>] (__driver_attach+0x70/0x94) [<>] (__driver_attach) from [<>] (bus_for_each_dev+0x74/0x98) [<>] (bus_for_each_dev) from [<>] (driver_attach+0x20/0x28) [<>] (driver_attach) from [<>] (bus_add_driver+0xd4/0x1f0) [<>] (bus_add_driver) from [<>] (driver_register+0xa4/0xe8) [<>] (driver_register) from [<>] (__platform_driver_register+0x38/0x4c) [<>] (__platform_driver_register) from [<>] (lpc32xx_gpio_driver_init+0x18/0x20) [<>] (lpc32xx_gpio_driver_init) from [<>] (do_one_initcall+0x108/0x1c8) [<>] (do_one_initcall) from [<>] (kernel_init_freeable+0x10c/0x1d4) [<>] (kernel_init_freeable) from [<>] (kernel_init+0x10/0xec) [<>] (kernel_init) from [<>] (ret_from_fork+0x14/0x24) This is caused by the fact that at the moment some GPIO names are set to NULL, there is a hole in linear representation of one GPI bank, see drivers/gpio/gpio-lpc32xx.c / gpi_p3_names[] for details. The same problem most probably affects also gpio-cs5535.c, see cs5535_gpio_names[]. Signed-off-by: Vladimir Zapolskiy <vz@mleia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
5ed41cc4 |
|
15-Nov-2015 |
Bamvor Jian Zhang <bamvor.zhangjian@linaro.org> |
gpiolib: do not allow to insert an empty gpiochip We need to check if number of gpio is positive if there is no such check in devicetree or acpi or whatever called before gpiochip_add. I suppose that devicetree and acpi do not allow insert gpiochip with zero number but I do not know if it is enough to ignore this check in gpiochip_add. Signed-off-by: Bamvor Jian Zhang <bamvor.zhangjian@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
ef7c7553 |
|
15-Nov-2015 |
Bamvor Jian Zhang <bamvor.zhangjian@linaro.org> |
gpiolib: improve overlap check of range of gpio There are limitations for the current checker: 1. Could not check the overlap if the new gpiochip is the secondly gpiochip. 2. Could not check the overlap if the new gpiochip is overlap with the left of gpiochip. E.g. if we insert [c, d] between [a,b] and [e, f], and e >= c + d, it will successful even if c < a + b. 3. Allow overlap of base of different gpiochip. This patch fix these issues by checking the overlap of both right and left gpiochip in the same loop statement. Signed-off-by: Bamvor Jian Zhang <bamvor.zhangjian@linaro.org> [Tweaked to remove unnecessary ret variable] Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
ed37915c |
|
14-Nov-2015 |
Bamvor Jian Zhang <bamvor.zhangjian@linaro.org> |
gpiolib: keep comment consistent with code The commit f881bab038c9 ("gpio: keep the GPIO line names internal") change the error to warning in gpiochip_set_desc_names. Update the comment accordingly. Signed-off-by: Bamvor Jian Zhang <bamvor.zhangjian@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
9c3c9bc9 |
|
11-Nov-2015 |
Dmitry Torokhov <dmitry.torokhov@gmail.com> |
gpiolib: tighten up ACPI legacy gpio lookups We should not fall back to the legacy unnamed gpio lookup style if the driver requests gpios with different names, because we'll give out the same gpio twice. Let's keep track of the names that were used for the device and only do the fallback for the first name used. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
58383c78 |
|
04-Nov-2015 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: change member .dev to .parent The name .dev in a struct is normally reserved for a struct device that is let us say a superclass to the thing described by the struct. struct gpio_chip stands out by confusingly using a struct device *dev to point to the parent device (such as a platform_device) that represents the hardware. As we want to give gpio_chip:s real devices, this is not working. We need to rename this member to parent. This was done by two coccinelle scripts, I guess it is possible to combine them into one, but I don't know such stuff. They look like this: @@ struct gpio_chip *var; @@ -var->dev +var->parent and: @@ struct gpio_chip var; @@ -var.dev +var.parent and: @@ struct bgpio_chip *var; @@ -var->gc.dev +var->gc.parent Plus a few instances of bgpio that I couldn't figure out how to teach Coccinelle to rewrite. This patch hits all over the place, but I *strongly* prefer this solution to any piecemal approaches that just exercise patch mechanics all over the place. It mainly hits drivers/gpio and drivers/pinctrl which is my own backyard anyway. Cc: Haavard Skinnemoen <hskinnemoen@gmail.com> Cc: Rafał Miłecki <zajec5@gmail.com> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Cc: Alek Du <alek.du@intel.com> Cc: Jaroslav Kysela <perex@perex.cz> Cc: Takashi Iwai <tiwai@suse.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Lee Jones <lee.jones@linaro.org> Acked-by: Jiri Kosina <jkosina@suse.cz> Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no> Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
90b665f6 |
|
12-Oct-2015 |
Laurent Pinchart <laurent.pinchart@ideasonboard.com> |
gpiolib: Add and use OF_GPIO_SINGLE_ENDED flag The flag matches the DT GPIO_SINGLE_ENDED flag and allows drivers to parse and use the DT flag to handle single-ended (open-drain or open-source) GPIOs. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
923b93e4 |
|
12-Oct-2015 |
Laurent Pinchart <laurent.pinchart@ideasonboard.com> |
gpiolib: Split GPIO flags parsing and GPIO configuration When requesting a GPIO through the legacy or the gpiod_* API the gpiochip request operation is first called and then the GPIO flags are parsed and the GPIO is configured. This prevents the gpiochip from rejecting the request if the flags are not supported by the device. To fix this split the parse-and-configure operation in two and parse flags before requesting the GPIO. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
c771c2f4 |
|
11-Oct-2015 |
Jonas Gorski <jogo@openwrt.org> |
gpiolib: provide generic request/free implementations Provide generic request/free implementations that pinctrl aware gpio drivers can use instead of open coding if they use a 1:1 pin to gpio signal mapping. Signed-off-by: Jonas Gorski <jogo@openwrt.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
48b5953e |
|
18-Aug-2015 |
Dirk Behme <dirk.behme@gmail.com> |
gpio: gpiolib: don't compare an unsigned for >= 0 The parameter offset is an unsigned, so it makes no sense to compare it for >= 0. Fix the compiler warning regarding this by removing this comparison. As the macro GPIO_OFFSET_VALID is only used at this single place, simplify the code by dropping the macro completely and dropping the invert, too. No functional change. Signed-off-by: Dirk Behme <dirk.behme@gmail.com> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
f881bab0 |
|
23-Sep-2015 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: keep the GPIO line names internal This refactors the changes to the GPIO line naming mechanism to not have so widespread effects, instead we conclude the patch series by having created a name attribute in the GPIO descriptor, that need not be globally unique, and it will be initialized from the old .names array in struct gpio_chip if it exists, then used in the legacy sysfs code like the array was used previously. The associated changes to name lines from the device tree are controversial and need to stand alone from this. Resulting changes: 1. Remove the export and the header for the gpio_name_to_desc() as so far the only use is inside gpiolib.c. Staticize gpio_name_to_desc() and move it above the only function using it. 2. Only print a warning if there are two GPIO lines with the same name. The reason is to preserve current behaviour: before the previous changes to the naming mechanism this would not reject probing the driver, instead the error would occur when trying to export the line in sysfs, so restore this behaviour, but print a friendly warning if names collide. Cc: Johan Hovold <johan@kernel.org> Cc: Markus Pargmann <mpa@pengutronix.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
ced433e2 |
|
14-Aug-2015 |
Markus Pargmann <mpa@pengutronix.de> |
gpiolib: Add gpio name information to /sys/kernel/debug/gpio Add some information about gpio names to the debugfs gpio file. name and label of a GPIO are then displayed next to each other. This way it is easy to see what the real name of GPIO is and what the driver requested it for. Signed-off-by: Markus Pargmann <mpa@pengutronix.de> [Dropped unsolicited sysfs ABI patch hunk] Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
5f3ca732 |
|
14-Aug-2015 |
Markus Pargmann <mpa@pengutronix.de> |
gpiolib: Use GPIO name from names array for gpio descriptor This patch adds GPIO names to the GPIO descriptors when initializing the gpiochip. It also introduces a check whether any of the new names will conflict with an existing GPIO name. Signed-off-by: Markus Pargmann <mpa@pengutronix.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
c0017ed7 |
|
14-Aug-2015 |
Markus Pargmann <mpa@pengutronix.de> |
gpio: Introduce gpio descriptor 'name' The latest gpio hogging mechanism assigns each gpio a 'line-name' in the devicetree. The 'name' field is different from the 'label' field. 'label' is only used for requested GPIOs to describe its current use by driver or userspace. The 'name' field describes the GPIO itself, not the use. This is most likely identical to the label in the schematic on the GPIO line and should help to find this particular GPIO. This is equivalent to the gpiochip->names array. However names should be stored in the GPIO descriptor. We will use gpiochip->names in the future only as initializer for the GPIO descriptors for drivers that assign GPIO names hardcoded. All other GPIO names will be parsed from DT and directly assigned to the GPIO descriptor. This patch adds a helper function to find gpio descriptors by name instead of gpio number. Signed-off-by: Markus Pargmann <mpa@pengutronix.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
504a3374 |
|
26-Aug-2015 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / property: Extend device_get_next_child_node() to data-only nodes Make device_get_next_child_node() work with ACPI data-only subnodes introduced previously. Namely, replace acpi_get_next_child() with acpi_get_next_subnode() that can handle (and return) child device objects as well as child data-only subnodes of the given device and modify the ACPI part of the GPIO subsystem to handle data-only subnodes returned by it. To that end, introduce acpi_node_get_gpiod() taking a struct fwnode_handle pointer as the first argument. That argument may point to an ACPI device object as well as to a data-only subnode and the function should do the right thing (ie. look for the matching GPIO descriptor correctly) in either case. Next, modify fwnode_get_named_gpiod() to use acpi_node_get_gpiod() instead of acpi_get_gpiod_by_index() which automatically causes devm_get_gpiod_from_child() to work with ACPI data-only subnodes that may be returned by device_get_next_child_node() which in turn is required by the users of that function (the gpio_keys_polled and gpio-leds drivers). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Linus Walleij <linus.walleij@linaro.org>
|
#
3a7a2ab8 |
|
26-Aug-2015 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / property: Extend fwnode_property_* to data-only subnodes Modify is_acpi_node() to return "true" for ACPI data-only subnodes as well as for ACPI device objects and change the name of to_acpi_node() to to_acpi_device_node() so it is clear that it covers ACPI device objects only. Accordingly, introduce to_acpi_data_node() to cover data-only subnodes in an analogous way. With that, make the fwnode_property_* family of functions work with ACPI data-only subnodes introduced previously. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
|
#
e20538b8 |
|
28-Aug-2015 |
Bjorn Andersson <bjorn.andersson@sonymobile.com> |
gpio: Propagate errors from chip->get() It's possible to have gpio chips hanging off unreliable remote buses where the get() operation will fail to acquire a readout of the current gpio state. Propagate these errors to the consumer so that they can act on, retry or ignore these failing reads, instead of treating them as the line being held high. Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
a0a8bcf4 |
|
17-Aug-2015 |
Grygorii Strashko <grygorii.strashko@ti.com> |
gpiolib: irqchip: use different lockdep class for each gpio irqchip Since IRQ chip helpers were introduced drivers lose ability to register separate lockdep classes for each registered GPIO IRQ chip and the gpiolib now is using shared lockdep class for all GPIO IRQ chips (gpiochip_irq_lock_class). As result, lockdep will produce warning when there are min two stacked GPIO chips and all of them are interrupt controllers. HW configuration which generates lockdep warning (TI dra7-evm): [SOC GPIO bankA.gpioX] <- irq - [pcf875x.gpioY] <- irq - DevZ.enable_irq_wake(pcf_gpioY_irq); The issue was reported in [1] and discussed [2]. ============================================= [ INFO: possible recursive locking detected ] 4.2.0-rc6-00013-g5d050ed-dirty #55 Not tainted --------------------------------------------- sh/63 is trying to acquire lock: (class){......}, at: [<c009b91c>] __irq_get_desc_lock+0x50/0x94 but task is already holding lock: (class){......}, at: [<c009b91c>] __irq_get_desc_lock+0x50/0x94 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(class); lock(class); *** DEADLOCK *** May be due to missing lock nesting notation 7 locks held by sh/63: #0: (sb_writers#4){.+.+.+}, at: [<c016bbb8>] vfs_write+0x13c/0x164 #1: (&of->mutex){+.+.+.}, at: [<c01debf4>] kernfs_fop_write+0x4c/0x1a0 #2: (s_active#36){.+.+.+}, at: [<c01debfc>] kernfs_fop_write+0x54/0x1a0 #3: (pm_mutex){+.+.+.}, at: [<c009758c>] pm_suspend+0xec/0x4c4 #4: (&dev->mutex){......}, at: [<c03f77f8>] __device_suspend+0xd4/0x398 #5: (&gpio->lock){+.+.+.}, at: [<c009b940>] __irq_get_desc_lock+0x74/0x94 #6: (class){......}, at: [<c009b91c>] __irq_get_desc_lock+0x50/0x94 stack backtrace: CPU: 0 PID: 63 Comm: sh Not tainted 4.2.0-rc6-00013-g5d050ed-dirty #55 Hardware name: Generic DRA74X (Flattened Device Tree) [<c0016e24>] (unwind_backtrace) from [<c0013338>] (show_stack+0x10/0x14) [<c0013338>] (show_stack) from [<c05f6b24>] (dump_stack+0x84/0x9c) [<c05f6b24>] (dump_stack) from [<c00903f4>] (__lock_acquire+0x19c0/0x1e20) [<c00903f4>] (__lock_acquire) from [<c0091098>] (lock_acquire+0xa8/0x128) [<c0091098>] (lock_acquire) from [<c05fd61c>] (_raw_spin_lock_irqsave+0x38/0x4c) [<c05fd61c>] (_raw_spin_lock_irqsave) from [<c009b91c>] (__irq_get_desc_lock+0x50/0x94) [<c009b91c>] (__irq_get_desc_lock) from [<c009c4f4>] (irq_set_irq_wake+0x20/0xfc) [<c009c4f4>] (irq_set_irq_wake) from [<c0393ac4>] (pcf857x_irq_set_wake+0x24/0x54) [<c0393ac4>] (pcf857x_irq_set_wake) from [<c009c560>] (irq_set_irq_wake+0x8c/0xfc) [<c009c560>] (irq_set_irq_wake) from [<c04a02ac>] (gpio_keys_suspend+0x70/0xd4) [<c04a02ac>] (gpio_keys_suspend) from [<c03f6a00>] (dpm_run_callback+0x50/0x124) [<c03f6a00>] (dpm_run_callback) from [<c03f7830>] (__device_suspend+0x10c/0x398) [<c03f7830>] (__device_suspend) from [<c03f90f0>] (dpm_suspend+0x134/0x2f4) [<c03f90f0>] (dpm_suspend) from [<c0096e20>] (suspend_devices_and_enter+0xa8/0x728) [<c0096e20>] (suspend_devices_and_enter) from [<c00977cc>] (pm_suspend+0x32c/0x4c4) [<c00977cc>] (pm_suspend) from [<c0096060>] (state_store+0x64/0xb8) [<c0096060>] (state_store) from [<c01dec64>] (kernfs_fop_write+0xbc/0x1a0) [<c01dec64>] (kernfs_fop_write) from [<c016b280>] (__vfs_write+0x20/0xd8) [<c016b280>] (__vfs_write) from [<c016bb0c>] (vfs_write+0x90/0x164) [<c016bb0c>] (vfs_write) from [<c016c330>] (SyS_write+0x44/0x9c) [<c016c330>] (SyS_write) from [<c000f500>] (ret_fast_syscall+0x0/0x54) Lets fix it by using separate lockdep class for each registered GPIO IRQ Chip. This is done by wrapping gpiochip_irqchip_add call into macros. The implementation of this patch inspired by solution done by Nicolas Boichat for regmap [3] [1] http://www.spinics.net/lists/linux-gpio/msg05844.html [2] http://www.spinics.net/lists/linux-gpio/msg06021.html [3] http://www.spinics.net/lists/arm-kernel/msg429834.html Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Roger Quadros <rogerq@ti.com> Reported-by: Roger Quadros <rogerq@ti.com> Tested-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
8b67a1f0 |
|
31-Jul-2015 |
Rabin Vincent <rabin@rab.in> |
gpio: don't override irq_*_resources() callbacks If the driver has specified its own irq_{request/release}_resources() functions, don't override them. The gpio-etraxfs driver will use this. Signed-off-by: Rabin Vincent <rabin@rab.in> [Added a small comment blurb] Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
28355f81 |
|
14-Jul-2015 |
Tomeu Vizoso <tomeu.vizoso@collabora.com> |
gpio: defer probe if pinctrl cannot be found When an OF node has a pin range for its GPIOs, return -EPROBE_DEFER if the pin controller isn't available. Otherwise, the GPIO range wouldn't be set at all unless the pin controller probed always before the GPIO chip. With this change, the probe of the GPIO chip will be deferred and will be retried at a later point, hopefully once the pin controller has been registered and probed already. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
23393d49 |
|
27-Jul-2015 |
Rob Herring <robh@kernel.org> |
gpio: kill off set_irq_flags usage set_irq_flags is ARM specific with custom flags which have genirq equivalents. Convert drivers to use the genirq interfaces directly, so we can kill off set_irq_flags. The translation of flags is as follows: IRQF_VALID -> !IRQ_NOREQUEST IRQF_PROBE -> !IRQ_NOPROBE IRQF_NOAUTOEN -> IRQ_NOAUTOEN For IRQs managed by an irqdomain, the irqdomain core code handles clearing and setting IRQ_NOREQUEST already, so there is no need to do this in .map() functions and we can simply remove the set_irq_flags calls. Some users also modify IRQ_NOPROBE and this has been maintained although it is not clear that is really needed as most platforms don't use probing. There appears to be a great deal of blind copy and paste of this code. Signed-off-by: Rob Herring <robh@kernel.org> Cc: Michael Hennerich <michael.hennerich@analog.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Cc: Alexandre Courbot <gnurou@gmail.com> Cc: Ray Jui <rjui@broadcom.com> Cc: Stephen Warren <swarren@wwwdotorg.org> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: linux-gpio@vger.kernel.org Cc: bcm-kernel-feedback-list@broadcom.com Cc: linux-tegra@vger.kernel.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
d1aceb80 |
|
20-Jul-2015 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
gpio: remove unneeded initializer in gpiochip_add_to_list() This variable is used as an iterator and initialized in the list_for_each() loop. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
be9015ab |
|
26-Jun-2015 |
Shobhit Kumar <shobhit.kumar@intel.com> |
gpiolib: Add support for removing registered consumer lookup table In case we unload and load a driver module again that is registering a lookup table, without this it will result in multiple entries. Provide an option to remove the lookup table on driver unload Cc: Samuel Ortiz <sameo@linux.intel.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Alexandre Courbot <gnurou@gmail.com> Cc: Thierry Reding <thierry.reding@gmail.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com> Acked-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
3726960e |
|
25-Jun-2015 |
Grygorii Strashko <grygorii.strashko@ti.com> |
gpiolib: assign chip owner to dev->driver->owner if not set Assign GPIO chip owner field to chip->dev->driver->owner if it was not configured by GPIO driver. Cc: Johan Hovold <johan@kernel.org> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
5b76e79c |
|
25-Jun-2015 |
Grygorii Strashko <grygorii.strashko@ti.com> |
gpiolib: irqchip: prevent driver unloading if gpio is used as irq only Now nothing prevents GPIO driver from being unloaded if its gpios were requested as GPIO IRQs only (without calling gpio_request()). Hence, add calls of try_module_get()/module_put() into gpiochip_irq_reqres/relres() to track such scenario properly. Cc: Johan Hovold <johan@kernel.org> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
d32651f6 |
|
17-Jun-2015 |
Tomeu Vizoso <tomeu.vizoso@collabora.com> |
gpiolib: Fix docs for gpiochip_add_pingroup_range gpiochip_add_pingroup_range() has a pctldev argument, not pinctrl. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
f7f87753 |
|
21-Jun-2015 |
Thomas Gleixner <tglx@linutronix.de> |
gpiolib: Consolidate chained IRQ handler install/remove Chained irq handlers usually set up handler data as well. We now have a function to set both under irq_desc->lock. Replace the two calls with one. Search and conversion was done with coccinelle: Reported-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Julia Lawall <Julia.Lawall@lip6.fr> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Alexandre Courbot <gnurou@gmail.com> Cc: linux-gpio@vger.kernel.org
|
#
b17d1bf1 |
|
11-Feb-2015 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
gpio: make flags mandatory for gpiod_get functions Now that all[1] users of the gpiod_get functions are converted to make use of the up to now optional flags parameter, make it mandatory which allows to remove some cpp magic. [1] all but etraxfs-uart which is broken anyhow and I'm allowed to ignore it by Jesper Nilsson :-) Acked-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
|
#
c181fb3e |
|
22-Jun-2015 |
Alexander Sverdlin <alexander.sverdlin@gmail.com> |
ACPI / OF: Rename of_node() and acpi_node() to to_of_node() and to_acpi_node() Commit 8a0662d9 introduced of_node and acpi_node symbols in global namespace but there were already ~63 of_node local variables or function parameters (no single acpi_node though, but anyway). After debugging undefined but used of_node local varible (which turned out to reference static function of_node() instead) it became clear that the names for the functions are too short and too generic for global scope. Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
38e003f4 |
|
10-Jun-2015 |
Daniel Lockyer <thisisdaniellockyer@gmail.com> |
gpio: Fix checkpatch.pl issues This patch fixes some issues given by checkpatch. Fixes include bracket placement, spacing and indenting. Signed-off-by: Daniel Lockyer <thisisdaniellockyer@gmail.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
a713890d |
|
05-Jun-2015 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: improve error reporting on own descriptors When requesting own descriptors through hogs, it is useful to get some details about what's going on if we encounter problems. Acked-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
8405f208 |
|
05-Jun-2015 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: promote own request failure to pr_err() These error messages are helpful to see that we fail to get hogs. Promote them to real errors so they appear in the boot crawl. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
3fff99bc |
|
13-May-2015 |
Rojhalat Ibrahim <imr@rtschenk.de> |
gpiolib: rename gpiod_set_array to gpiod_set_array_value There have been concerns that the function names gpiod_set_array() and gpiod_get_array() might be confusing to users. One might expect gpiod_get_array() to return array values, while it is actually the array counterpart of gpiod_get(). To be consistent with the single descriptor API we could rename gpiod_set_array() to gpiod_set_array_value(). This makes some function names a bit lengthy: gpiod_set_raw_array_value_cansleep(). Signed-off-by: Rojhalat Ibrahim <imr@rtschenk.de> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
20a8a968 |
|
18-May-2015 |
Colin Cronin <colinpatrickcronin@gmail.com> |
Drivers: gpio: Fix spelling errors Fixed several spelling errors in gpio-lynxpoint, gpio-pca953x, gpio-tegra, gpio-zynq, gpiolib-of, gpiolib. Signed-off-by: Colin Cronin <colinpatrickcronin@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
25e4fe92 |
|
12-May-2015 |
Dmitry Baryshkov <dbaryshkov@gmail.com> |
gpiolib: cleanup chained handler and data Clean up chained handler and handler data if they were set by gpiochip_set_chained_irqchip(). Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
6d86750c |
|
04-May-2015 |
Johan Hovold <johan@kernel.org> |
gpio: fix gpio leak in gpiochip_add error path Make sure to free any hogged gpios on errors in gpiochip_add. Also move all forward declarations to the top of the file. Fixes: f625d4601759 ("gpio: add GPIO hogging mechanism") Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
426577bd |
|
04-May-2015 |
Johan Hovold <johan@kernel.org> |
gpio: sysfs: rename gpiochip registration functions Rename the gpio-chip export/unexport functions to the more descriptive names gpiochip_sysfs_register and gpiochip_sysfs_unregister. Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
fab28b89 |
|
04-May-2015 |
Johan Hovold <johan@kernel.org> |
gpio: clean up gpiochip_remove Clean up gpiochip_remove somewhat and only output warning about removing chip with GPIOs requested once. Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
4d8440b9 |
|
10-Mar-2015 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
gpio / ACPI: Avoid unnecessary checks in __gpiod_get_index() If dev is NULL in __gpiod_get_index() and both ACPI and OF are enabled, it will be checked twice before the code decides to give up with DT/ACPI lookup, so avoid that. Also use the observation that ACPI_COMPANION() is much more efficient than ACPI_HANDLE(), because the latter uses the former and carries out a check and a pointer dereference on top of it, so replace the ACPI_HANDLE() check with an ACPI_COMPANION() one which does not require the additional IS_ENABLED(CONFIG_ACPI) check too. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
66858527 |
|
11-Feb-2015 |
Rojhalat Ibrahim <imr@rtschenk.de> |
gpiolib: add gpiod_get_array and gpiod_put_array functions Introduce new functions for conveniently obtaining and disposing of an entire array of GPIOs with one function call. ACPI parts tested by Mika Westerberg, DT parts tested by Rojhalat Ibrahim. Change log: v5: move the ACPI functions to gpiolib-acpi.c v4: - use shorter names for members of struct gpio_descs - rename lut_gpio_count to platform_gpio_count for clarity - add check for successful memory allocation - use ERR_CAST() v3: - rebase on current linux-gpio devel branch - fix ACPI GPIO counting - allow for zero-sized arrays - make the flags argument mandatory for the new functions - clarify documentation v2: change interface Suggested-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Rojhalat Ibrahim <imr@rtschenk.de> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Rojhalat Ibrahim <imr@rtschenk.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
7f2e553a |
|
11-Feb-2015 |
Rojhalat Ibrahim <imr@rtschenk.de> |
gpiolib: define gpio suffixes globally Avoid multiple identical definitions of the gpio suffix strings by putting them into a global constant array. Signed-off-by: Rojhalat Ibrahim <imr@rtschenk.de> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
f625d460 |
|
02-Feb-2015 |
Benoit Parrot <bparrot@ti.com> |
gpio: add GPIO hogging mechanism Based on Boris Brezillion's work this is a reworked patch of his initial GPIO hogging mechanism. This patch provides a way to initially configure specific GPIO when the GPIO controller is probed. The actual DT scanning to collect the GPIO specific data is performed as part of gpiochip_add(). The purpose of this is to allow specific GPIOs to be configured without any driver specific code. This is particularly useful because board design are getting increasingly complex and given SoC pins can now have more than 10 mux values, a lot of connections are now dependent on external IO muxes to switch various modes. Specific drivers should not necessarily need to be aware of what accounts to a specific board implementation. This board level "description" should be best kept as part of the dts file. Signed-off-by: Benoit Parrot <bparrot@ti.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
9e089246 |
|
21-Jan-2015 |
Olliver Schinagl <oliver@schinagl.nl> |
gpio: use sizeof() instead of hardcoded values gpiolib uses a fixed string for the suffixes and defines it at 32 bytes. Later in the code snprintf is used with this fixed value of 32. Using sizeof() is safer in case the size for the suffixes is ever changed. Signed-off-by: Olliver Schinagl <oliver@schinagl.nl> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
ef3b2bd6 |
|
21-Jan-2015 |
Olliver Schinagl <oliver@schinagl.nl> |
gpio: correctly use const char * const On my previous patch I was overly hasty and made the suffixes string array const char const *suffixes, instaed of const char * const suffixes. This patch corrects that Signed-off-by: Olliver Schinagl <oliver@schinagl.nl> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
b9b4d9f2 |
|
07-Jan-2015 |
Olliver Schinagl <oliver@schinagl.nl> |
gpio:gpiolib: use static const char const * for a suffixes array Checkpatch complains, and probably with good reason that we should use const char const * for the static constant array that never gets changed. Signed-off-by: Olliver Schinagl <oliver@schinagl.nl> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
01cca93a |
|
12-Jan-2015 |
Johan Hovold <johan@kernel.org> |
gpio: unregister gpiochip device before removing it Unregister gpiochip device (used to export information through sysfs) before removing it internally. This way removal will reverse addition. Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
6798acaa |
|
12-Jan-2015 |
Johan Hovold <johan@kernel.org> |
gpio: fix sleep-while-atomic in gpiochip_remove Move direct and indirect calls to gpiochip_remove_pin_ranges outside of spin lock as they can end up taking a mutex in pinctrl_remove_gpio_range. Note that the pin ranges are already added outside of the lock. Fixes: 9ef0d6f7628b ("gpiolib: call pin removal in chip removal function") Fixes: f23f1516b675 ("gpiolib: provide provision to register pin ranges") Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
00acc3dc |
|
12-Jan-2015 |
Johan Hovold <johan@kernel.org> |
gpio: fix memory leak and sleep-while-atomic Fix memory leak and sleep-while-atomic in gpiochip_remove. The memory leak was introduced by afa82fab5e13 ("gpio / ACPI: Move event handling registration to gpiolib irqchip helpers") that moved the release of acpi interrupt resources to gpiochip_irqchip_remove, but by then the resources are no longer accessible as the acpi_gpio_chip has already been freed by acpi_gpiochip_remove. Note that this also fixes a few potential sleep-while-atomics, which has been around since 1425052097b5 ("gpio: add IRQ chip helpers in gpiolib") when the call to gpiochip_irqchip_remove while holding a spinlock was added (a couple of irq-domain paths can end up grabbing mutexes). Fixes: afa82fab5e13 ("gpio / ACPI: Move event handling registration to gpiolib irqchip helpers") Fixes: 1425052097b5 ("gpio: add IRQ chip helpers in gpiolib") Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
05aa5203 |
|
12-Jan-2015 |
Johan Hovold <johan@kernel.org> |
gpio: clean up gpiochip_add error handling Clean up gpiochip_add error handling. Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
225fce83 |
|
12-Jan-2015 |
Johan Hovold <johan@kernel.org> |
gpio: fix gpio-chip list corruption Fix potential corruption of gpio-chip list due to failure to remove the chip from the list before returning in gpiochip_add error path. The chip could be long gone when the global list is next traversed, something which could lead to a null-pointer dereference. In the best case (chip not deallocated) we are just leaking the gpio range. Fixes: 14e85c0e69d5 ("gpio: remove gpio_descs global array") Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
5539b3c9 |
|
12-Jan-2015 |
Johan Hovold <johan@kernel.org> |
gpio: fix memory and reference leaks in gpiochip_add error path Memory allocated and references taken by of_gpiochip_add and acpi_gpiochip_add were never released on errors in gpiochip_add (e.g. failure to find free gpio range). Fixes: 391c970c0dd1 ("of/gpio: add default of_xlate function if device has a node pointer") Fixes: 664e3e5ac64c ("gpio / ACPI: register to ACPI events automatically") Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
0e9a5edf |
|
02-Dec-2014 |
Alexandre Courbot <acourbot@nvidia.com> |
gpio: fix deferred probe detection for legacy API Commit 14e85c0e69d5 ("gpio: remove gpio_descs global array") changed gpio_to_desc()'s behavior to return NULL not only for GPIOs numbers not in the valid range, but also for all GPIOs whose controller has not been probed yet. Although this behavior is more correct (nothing hints that these GPIO numbers will be populated later), this affects gpio_request() and gpio_request_one() which call gpiod_request() with a NULL descriptor, causing it to return -EINVAL instead of the expected -EPROBE_DEFER for a non-probed GPIO. gpiod_request() is only called with a descriptor obtained from gpio_to_desc() from these two functions, so address the issue there. Other ways to obtain GPIOs rely on well-defined mappings and can thus return -EPROBE_DEFER only for relevant GPIOs, and are thus not affected by this issue. Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
8e53b0f1 |
|
25-Nov-2014 |
Alexandre Courbot <acourbot@nvidia.com> |
gpio: remove const modifier from gpiod_get_direction() Although gpiod_get_direction() can be considered side-effect free for consumers, its internals involve setting or clearing bits in the affected GPIO descriptor, for which we need to force-cast the const descriptor variable to non-const. This could lead to incorrect behavior if the compiler decides to optimize here, so remove this const attribute. The intent is to make gpiod_get_direction() private anyway, so it does not really matter. Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
14e85c0e |
|
19-Nov-2014 |
Alexandre Courbot <acourbot@nvidia.com> |
gpio: remove gpio_descs global array Replace the ARCH_NR_GPIOS-sized static array of GPIO descriptors by dynamically-allocated arrays for each GPIO chip. This change makes gpio_to_desc() perform in O(n) (where n is the number of GPIO chips registered) instead of O(1), however since n is rarely bigger than 1 or 2 no noticeable performance issue is expected. Besides this provides more incentive for GPIO consumers to move to the gpiod interface. One could use a O(log(n)) structure to link the GPIO chips together, but considering the low limit of n the hypothetical performance benefit is probably not worth the added complexity. This patch uses kcalloc() in gpiochip_add(), which removes the ability to add a chip before kcalloc() can operate. I am not aware of such cases, but if someone bisects up to this patch then I will be proven wrong... Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
86256d1f |
|
17-Nov-2014 |
Geert Uytterhoeven <geert+renesas@glider.be> |
gpio: Check if base is positive before calling gpio_is_valid() It doesn't make much sense to make some (possible expensive) calls to gpio_is_valid() first, and to ignore the result if the base number is negative. Check for a positive base number first. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
5f424243 |
|
04-Nov-2014 |
Rojhalat Ibrahim <imr@rtschenk.de> |
gpiolib: allow simultaneous setting of multiple GPIO outputs Introduce new functions gpiod_set_array & gpiod_set_raw_array to the consumer interface which allow setting multiple outputs with just one function call. Also add an optional set_multiple function to the driver interface. Without an implementation of that function in the chip driver outputs are set sequentially. Implementing the set_multiple function in a chip driver allows for: - Improved performance for certain use cases. The original motivation for this was the task of configuring an FPGA. In that specific case, where 9 GPIO lines have to be set many times, configuration time goes down from 48 s to 20 s when using the new function. - Simultaneous glitch-free setting of multiple pins on any kind of parallel bus attached to GPIOs provided they all reside on the same chip and bank. Limitations: Performance is only improved for normal high-low outputs. Open drain and open source outputs are always set separately from each other. Those kinds of outputs could probably be accelerated in a similar way if we could forgo the error checking when setting GPIO directions. Change log: v6: - rebase on current linux-gpio devel branch v5: - check can_sleep property per chip - remove superfluous checks - supplement documentation v4: - add gpiod_set_array function for setting logical values - change interface of the set_multiple driver function to use unsigned long as type for the bit fields - use generic bitops (which also use unsigned long for bit fields) - do not use ARCH_NR_GPIOS any more v3: - add documentation - change commit message v2: - use descriptor interface - allow arbitrary groups of GPIOs spanning multiple chips Signed-off-by: Rojhalat Ibrahim <imr@rtschenk.de> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Mark Brown <broonie@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
40b73183 |
|
21-Oct-2014 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
gpio: Support for unified device properties interface Some drivers need to deal with only firmware representation of its GPIOs. An example would be a GPIO button array driver where each button is described as a separate firmware node in device tree. Typically these child nodes do not have physical representation in the Linux device model. In order to help device drivers to handle such firmware child nodes we add dev[m]_get_named_gpiod_from_child() that takes a child firmware node pointer as its second argument (the first one is the parent device itself), finds the GPIO using whatever is the underlying firmware method, and requests the GPIO properly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Acked-by: Grant Likely <grant.likely@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
0d9a693c |
|
29-Oct-2014 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
gpio / ACPI: Add support for _DSD device properties With release of ACPI 5.1 and _DSD method we can finally name GPIOs (and other things as well) returned by _CRS. Previously we were only able to use integer index to find the corresponding GPIO, which is pretty error prone if the order changes. With _DSD we can now query GPIOs using name instead of an integer index, like the below example shows: // Bluetooth device with reset and shutdown GPIOs Device (BTH) { Name (_HID, ...) Name (_CRS, ResourceTemplate () { GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly, "\\_SB.GPO0", 0, ResourceConsumer) {15} GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly, "\\_SB.GPO0", 0, ResourceConsumer) {27, 31} }) Name (_DSD, Package () { ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () { Package () {"reset-gpio", Package() {^BTH, 1, 1, 0 }}, Package () {"shutdown-gpio", Package() {^BTH, 0, 0, 0 }}, } }) } The format of the supported GPIO property is: Package () { "name", Package () { ref, index, pin, active_low }} ref - The device that has _CRS containing GpioIo()/GpioInt() resources, typically this is the device itself (BTH in our case). index - Index of the GpioIo()/GpioInt() resource in _CRS starting from zero. pin - Pin in the GpioIo()/GpioInt() resource. Typically this is zero. active_low - If 1 the GPIO is marked as active_low. Since ACPI GpioIo() resource does not have field saying whether it is active low or high, the "active_low" argument can be used here. Setting it to 1 marks the GPIO as active low. In our Bluetooth example the "reset-gpio" refers to the second GpioIo() resource, second pin in that resource with the GPIO number of 31. This patch implements necessary support to gpiolib for extracting GPIOs using _DSD device properties. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Grant Likely <grant.likely@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
e3a2e878 |
|
23-Oct-2014 |
Alexandre Courbot <acourbot@nvidia.com> |
gpio: rename gpio_lock_as_irq to gpiochip_lock_as_irq This function actually operates on a gpio_chip, so its prefix should reflect that fact for consistency with other functions defined in gpio/driver.h. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
3f97d5fc |
|
26-Sep-2014 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: handle also nested irqchips in the chained handler set-up To unify how we connect cascaded IRQ chips to parent IRQs, if NULL us passed as handler to the gpiochip_set_chained_irqchip() function, assume the chips is nested rather than chained, and we still get the parent set up correctly by way of this function call. Alter the drivers for tc3589x and stmpe to use this to set up their chained handlers as a demonstration of the usage. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
83141a77 |
|
26-Sep-2014 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: set parent irq on chained handlers If the IRQ from the parent is nested the IRQ may need to be resent under certain conditions. Currently the chained IRQ handler in gpiolib does not handle connecting nested IRQs but it is conceptually correct to indicate the actual parent IRQ. Reported-by: Grygorii Strashko <grygorii.strashko@ti.com> Reported-by: Lothar Waßmann <LW@karo-electronics.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
e3893386 |
|
25-Sep-2014 |
Grygorii Strashko <grygorii.strashko@ti.com> |
gpiolib: irqchip: use irq_find_mapping while removing irqchip There is no guarantee that VIRQs will be allocated sequentially for gpio irqchip in gpiochip_irqchip_add(). Therefore, it's unsafe to dispose VIRQ in gpiochip_irqchip_remove() basing on index relatively to stored irq_base value. Hence, use irq_find_mapping for VIRQ finding in gpiochip_irqchip_remove() instead of irq_base + index. Reported-by: Wang, Yalin <Yalin.Wang@sonymobile.com> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
295494af |
|
19-Sep-2014 |
Octavian Purdila <octavian.purdila@intel.com> |
gpiolib: add irq_not_threaded flag to gpio_chip Some GPIO chips (e.g. the DLN2 USB adapter) have blocking get/set operation but do not need a threaded irq handler. Signed-off-by: Octavian Purdila <octavian.purdila@intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
324b0398 |
|
16-Sep-2014 |
Jarkko Nikula <jarkko.nikula@linux.intel.com> |
gpio: Fix potential NULL handler data in chained irqchip handler There is possibility with misconfigured pins that interrupt occurs instantly after setting irq_set_chained_handler() in gpiochip_set_chained_irqchip(). Now if handler gets called before irq_set_handler_data() the handler gets NULL handler data. Fix this by moving irq_set_handler_data() call before irq_set_chained_handler() in gpiochip_set_chained_irqchip(). Cc: Stable <stable@vger.kernel.org> # 3.15+ Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
|
#
72f908c8 |
|
22-Sep-2014 |
Adrian Hunter <adrian.hunter@intel.com> |
gpio: Fix gpio direction flags not getting set GPIO direction flags are not getting set because an 'if' statement is the wrong way around. Cc: Stable <stable@vger.kernel.org> # 3.15+ Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
43a8785a |
|
19-Sep-2014 |
Alexander Shiyan <shc_work@mail.ru> |
GPIO: gpiolib: trivial: Add missing carriage return Signed-off-by: Alexander Shiyan <shc_work@mail.ru> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
e1db1706 |
|
05-Jul-2014 |
abdoulaye berthe <berthe.ab@gmail.com> |
gpio: gpiolib: set gpiochip_remove retval to void This avoids handling gpiochip remove error in device remove handler. Signed-off-by: Abdoulaye Berthe <berthe.ab@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
abdc08a3 |
|
19-Aug-2014 |
Alexandre Courbot <acourbot@nvidia.com> |
gpio: change gpiochip_request_own_desc() prototype The current prototype of gpiochip_request_own_desc() requires to obtain a pointer to a descriptor. This is in contradiction to all other GPIO request schemes, and imposes an extra step of obtaining a descriptor to drivers. Most drivers actually cannot even perform that step since the function that does it (gpichip_get_desc()) is gpiolib-private. Change gpiochip_request_own_desc() to return a descriptor from a (chip, hwnum) tuple and update users of this function (currently gpiolib-acpi only). Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
39b2bbe3 |
|
25-Jul-2014 |
Alexandre Courbot <acourbot@nvidia.com> |
gpio: add flags argument to gpiod_get*() functions The huge majority of GPIOs have their direction and initial value set right after being obtained by one of the gpiod_get() functions. The integer GPIO API had gpio_request_one() that took a convenience flags parameter allowing to specify an direction and value applied to the returned GPIO. This feature greatly simplifies client code and ensures errors are always handled properly. A similar feature has been requested for the gpiod API. Since setting the direction of a GPIO is so often the very next action done after obtaining its descriptor, we prefer to extend the existing functions instead of introducing new functions that would raise the number of gpiod getters to 16 (!). The drawback of this approach is that all gpiod clients need to be updated. To limit the pain, temporary macros are introduced that allow gpiod_get*() to be called with or without the extra flags argument. They will be removed once all consumer code has been updated. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Mark Brown <broonie@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
afa82fab |
|
25-Jul-2014 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
gpio / ACPI: Move event handling registration to gpiolib irqchip helpers Since now we have irqchip helpers that the GPIO chip drivers are supposed to use if possible, we can move the registration of ACPI events to happen in these helpers. This seems to be more natural place and might encourage GPIO chip driver writers to take advantage of the irqchip helpers. We make the functions available to GPIO chip drivers via private gpiolib.h, just in case generic irqchip helpers are not suitable. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
0a6d3158 |
|
24-Jul-2014 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: split gpiod board registration into machine header As per example from the regulator subsystem: put all defines and functions related to registering board info for GPIO descriptors into a separate <linux/gpio/machine.h> header. Cc: Andrew Victor <linux@maxim.org.za> Cc: Nicolas Ferre <nicolas.ferre@atmel.com> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Thierry Reding <thierry.reding@gmail.com> Acked-by: Stephen Warren <swarren@wwwdotorg.org> Reviewed-by: Alexandre Courbot <gnurou@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
f7d4ad98 |
|
22-Jul-2014 |
Guenter Roeck <linux@roeck-us.net> |
gpiolib: Export gpiochip_request_own_desc and gpiochip_free_own_desc Both functions were introduced to let gpio drivers request their own gpio pins. Without exporting the functions, this can however only be used by gpio drivers built into the kernel. Secondary impact is that the functions can not currently be used by platform initialization code associated with the gpio-pca953x driver. This code permits auto-export of gpio pins through platform data, but if this functionality is used, the module can no longer be unloaded due to the problem solved with the introduction of gpiochip_request_own_desc and gpiochip_free_own_desc. Export both function so they can be used from modules and from platform initialization code. Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
d82da797 |
|
22-Jul-2014 |
Alexandre Courbot <acourbot@nvidia.com> |
gpio: move gpio_ensure_requested() into legacy C file gpio_ensure_requested() only makes sense when using the integer-based GPIO API, so make sure it is called from there instead of the gpiod API which we know cannot be called with a non-requested GPIO anyway. The uses of gpio_ensure_requested() in the gpiod API were kind of out-of-place anyway, so putting them in gpio-legacy.c helps clearing the code. Actually, considering the time this ensure_requested mechanism has been around, maybe we should just turn this patch into "remove gpio_ensure_requested()" if we know for sure that no user depend on it anymore? Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
d74be6df |
|
22-Jul-2014 |
Alexandre Courbot <acourbot@nvidia.com> |
gpio: remove gpiod_lock/unlock_as_irq() gpio_lock/unlock_as_irq() are working with (chip, offset) arguments and are thus not using the old integer namespace. Therefore, there is no reason to have gpiod variants of these functions working with descriptors, especially since the (chip, offset) tuple is more suitable to the users of these functions (GPIO drivers, whereas GPIO descriptors are targeted at GPIO consumers). Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
1bd6b601 |
|
22-Jul-2014 |
Alexandre Courbot <acourbot@nvidia.com> |
gpio: make gpiochip_get_desc() gpiolib-private As GPIO descriptors are not going to remain unique anymore, having this function public is not safe. Restrain its use to gpiolib since we have no user outside of it. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
122c94de |
|
30-Jun-2014 |
Alexandre Courbot <acourbot@nvidia.com> |
gpio: move integer GPIO support to its own file The old integer GPIO interface is, in effect, a privileged user of the gpiod interface. Reflect this fact further by moving legacy GPIO support into its own source file. This makes the code clearer and will allow us to disable legacy GPIO support in the (far) future. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
0eb4c6c2 |
|
30-Jun-2014 |
Alexandre Courbot <acourbot@nvidia.com> |
gpio: move sysfs support to its own file sysfs support is currently entangled within the core GPIO support, while it should relly just be a (privileged) user of the integer GPIO API. This patch is a first step towards making the gpiolib code more readable by splitting it into logical parts. Move all sysfs support to their own source file, and share static members of gpiolib that need to be in the private gpiolib.h file. In the future we will want to put some of them back into gpiolib.c, but this first patch let us at least identify them. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
9c8318ff |
|
30-Jun-2014 |
Alexandre Courbot <acourbot@nvidia.com> |
gpio: always compile label support Compiling out GPIO labels results in a space gain so small that it can hardly be justified. Labels can also be useful for printing debug messages, so always keep them around. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
06fc3b70 |
|
02-Jun-2014 |
Tony Lindgren <tony@atomide.com> |
gpio: of: Fix handling for deferred probe for -gpio suffix Commit dd34c37aa3e (gpio: of: Allow -gpio suffix for property names) added parsing for both -gpio and -gpios suffix but also changed the handling for deferred probe unintentionally. Because of the looping the second name will now return -ENOENT instead of -EPROBE_DEFER. Fix the issue by breaking out of the loop if -EPROBE_DEFER is encountered. Signed-off-by: Tony Lindgren <tony@atomide.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
29a1f233 |
|
25-Apr-2014 |
Thierry Reding <treding@nvidia.com> |
gpio: Add helpers for optional GPIOs Introduce gpiod_get_optional() and gpiod_get_index_optional() helpers that make it easier for drivers to handle optional GPIOs. Currently in order to handle optional GPIOs, a driver needs to special case error handling for -ENOENT, such as this: gpio = gpiod_get(dev, "foo"); if (IS_ERR(gpio)) { if (PTR_ERR(gpio) != -ENOENT) return PTR_ERR(gpio); gpio = NULL; } if (gpio) { /* set up GPIO */ } With these new helpers the above is reduced to: gpio = gpiod_get_optional(dev, "foo"); if (IS_ERR(gpio)) return PTR_ERR(gpio); if (gpio) { /* set up GPIO */ } While at it, device-managed variants of these functions are also provided. Signed-off-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
0879162f |
|
25-Apr-2014 |
Thierry Reding <treding@nvidia.com> |
gpio: Fix gpio_get -> gpiod_get typo in kernel-doc The function is called gpiod_get(), not gpio_get(). Fix the kernel-doc comment to match the name. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
dd34c37a |
|
23-Apr-2014 |
Thierry Reding <treding@nvidia.com> |
gpio: of: Allow -gpio suffix for property names Many bindings use the -gpio suffix in property names. Support this in addition to the -gpios suffix when requesting GPIOs using the new descriptor-based API. Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
47a95fe7 |
|
23-Apr-2014 |
Thierry Reding <treding@nvidia.com> |
gpio: of: Remove unneeded dummy function of_find_gpio() is always called under an IS_ENABLED(CONFIG_OF), so the dummy implementation provided for !OF configurations is not needed. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
1333b90f |
|
23-Apr-2014 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: do not set up hardware for IRQ_TYPE_NONE Some GPIO irqchip drivers exploit the irqdomain mapping function to set up the IRQ default type in the hardware, make sure that if we pass IRQ_TYPE_NONE, no hardware setup whatsoever takes place (this should be the norm) until later when the IRQ gets utilized. Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: linux-omap <linux-omap@vger.kernel.org> Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: Javier Martinez Canillas <javier@dowhile0.org> Tested-by: Nishanth Menon <nm@ti.com> Acked-by: Nishanth Menon <nm@ti.com> Tested-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
e45d1c80 |
|
22-Apr-2014 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: put GPIO IRQs into their own lock class Another feature that is duplicated in a number of GPIO irqchips is that these cascades IRQs are assigned their own lock class so as to avoid warnings about lockdep recursions. Do this also in the generic GPIO irqchip helpers for smooth transition to this core infrastructure. Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
1c8732bb |
|
09-Apr-2014 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: support threaded interrupts in irqchip helpers Some off-chip GPIO expanders need to be communicated by I2C or SPI traffic, but may still support IRQs. By the sleeping nature of such buses, such IRQ handlers need to be threaded. Support such handlers in the gpiochip irqchip helpers by flagging IRQs as threaded if the .can_sleep property of the gpiochip is true. Helpfully deny registration of chained IRQ handlers if the .can_sleep property is set, as such chips will invariably need a nested handler rather than a chained handler. Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
7633fb95 |
|
09-Apr-2014 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: set data first, then chip and handler During irq mapping, in irq_set_chip_and_handler() the process of setting this up may incur calls to lock the irqchip, which in turn may need to dereference and use the chip data. So set the data first, then set the chip and handler. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
c3626fde |
|
28-Mar-2014 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: unmap gpio irqs properly When using the irqchip helper inside the gpiolib, make sure the IRQs are unmapped/disposed before the irqdomain is removed as part of removing the gpiochip. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
14250520 |
|
25-Mar-2014 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: add IRQ chip helpers in gpiolib This provides a function gpiochip_irqchip_add() to set up an irqchip for a GPIO controller, and a function gpiochip_set_chained_irqchip() to chain it to a parent irqchip. Most GPIOs are of the type where a number of lines form a cascaded interrupt controller chained onto the primary system interrupt controller (or further down the chain) so let's add this helper and factor the code to request the lines to be used as IRQs, the .to_irq() function and the irqdomain into the core as well. Acked-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
23600969 |
|
11-Mar-2014 |
Alexandre Courbot <acourbot@nvidia.com> |
gpio: clamp returned values to the boolean range Nothing prevents GPIO drivers from returning values outside the boolean range, and as it turns out a few drivers are actually doing so. These values were passed as-is to unsuspecting consumers and created confusion. This patch makes the internal _gpiod_get_raw_value() function return a bool, effectively clamping the GPIO value to the boolean range no matter what the driver does. While we are at it, we also change the value parameter of _gpiod_set_raw_value() to bool type before drivers start doing funny things with it as well. Another way to fix this would be to change the prototypes of the driver interface to use bool directly, but this would require a huge cross-systems patch so this simpler solution is preferred. Changes since v1: - Change local variable type to bool as well, use boolean values in code - Also change prototype of open drain/open source setting functions since they are only called from _gpiod_set_raw_value() This probably calls for a larger booleanization of gpiolib, but let's keep that for a latter change - right now we need to address the issue of non-boolean values returned by drivers. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
6072b9dc |
|
10-Mar-2014 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
gpio / ACPI: Rework ACPI GPIO event handling The current ACPI GPIO event handling code was never tested against real hardware with functioning GPIO triggered events (at the time such hardware wasn't available). Thus it misses certain things like requesting the GPIOs properly, passing correct flags to the interrupt handler and so on. This patch reworks ACPI GPIO event handling so that we: 1) Use struct acpi_gpio_event for all GPIO signaled events. 2) Switch to use GPIO descriptor API and request GPIOs by calling gpiochip_request_own_desc() that we added in a previous patch. 3) Pass proper flags from ACPI GPIO resource to request_threaded_irq(). Also instead of open-coding the _AEI iteration loop we can use acpi_walk_resources(). This simplifies the code a bit and fixes memory leak that was caused by missing kfree() for buffer returned by acpi_get_event_resources(). Since the remove path now calls gpiochip_free_own_desc() which takes GPIO spinlock we need to call acpi_gpiochip_remove() outside of that lock (analogous to acpi_gpiochip_add() path where the lock is released before those funtions are called). Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
77c2d792 |
|
10-Mar-2014 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
gpiolib: Allow GPIO chips to request their own GPIOs Sometimes it is useful to allow GPIO chips themselves to request GPIOs they own through gpiolib API. One use case is ACPI ASL code that should be able to toggle GPIOs through GPIO operation regions. We can't use gpio_request() because it will pin the module to the kernel forever (it calls try_module_get()). To solve this we move module refcount manipulation to gpiod_request() and let __gpiod_request() handle the actual request. This changes the sequence a bit as now try_module_get() is called outside of gpio_lock (I think this is safe, try_module_get() handles serialization it needs already). Then we provide gpiolib internal functions gpiochip_request/free_own_desc() that do the same as gpio_request() but don't manipulate module refrence count. This allows the GPIO chip driver to request and free descriptors it owns without being pinned to the kernel forever. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
f438acdf |
|
06-Mar-2014 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: remove misleading documentation It is currently debated where the functions to lock a certain GPIO line as used for IRQs should be called. Delete all misleading documentation. Reported-by: Thomas Gleixner <tglx@linutronix.de> Cc: Jean-Jacques Hiblot <jjhiblot@traphandler.com> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
bb1e88cc |
|
09-Feb-2014 |
Alexandre Courbot <acourbot@nvidia.com> |
gpiolib: add gpiochip_get_desc() driver function Some drivers dealing with a gpio_chip might need to act on its descriptors directly; one example is pinctrl drivers that need to lock a GPIO for being used as IRQ using gpiod_lock_as_irq(). This patch exports a gpiochip_get_desc() function that returns the GPIO descriptor at the requested index. It also sweeps the gpio_to_chip() function out of the consumer interface since any holder of a gpio_chip reference can manipulate its GPIOs way beyond what a consumer should be allowed to do. As a result, gpio_chip is not visible anymore to simple GPIO consumers. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
90df4fe0 |
|
07-Feb-2014 |
Rahul Bedarkar <rahulbedarkar89@gmail.com> |
GPIO: gpiolib: correct description of gpiod_direction_output Signed-off-by: Rahul Bedarkar <rahulbedarkar89@gmail.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
ef70bbe1 |
|
06-Jan-2014 |
Philipp Zabel <p.zabel@pengutronix.de> |
gpio: make gpiod_direction_output take a logical value The documentation was not clear about whether gpio_direction_output should take a logical value or the physical level on the output line, i.e. whether the ACTIVE_LOW status would be taken into account. This converts gpiod_direction_output to use the logical level and adds a new gpiod_direction_output_raw for the raw value. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
5ccff852 |
|
07-Jan-2014 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
gpio / ACPI: get rid of acpi_gpio.h Now that all users of acpi_gpio.h have been moved to use either the GPIO descriptor interface or to the internal gpiolib.h we can get rid of acpi_gpio.h entirely. Once this is done the only interface to get GPIOs to drivers enumerated from ACPI namespace is the descriptor based interface. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
664e3e5a |
|
07-Jan-2014 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
gpio / ACPI: register to ACPI events automatically Instead of asking each driver to register to ACPI events we can just call acpi_gpiochip_register_interrupts() for each chip that has an ACPI handle. The function checks chip->to_irq and if it is set to NULL (a GPIO driver that doesn't do interrupts) the function does nothing. We also add the a new header drivers/gpio/gpiolib.h that is used for functions internal to gpiolib and add ACPI GPIO chip registering functions to that header. Once that is done we can remove call to acpi_gpiochip_register_interrupts() from its only user, pinctrl-baytrail.c Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
2a3cf6a3 |
|
10-Dec-2013 |
Alexandre Courbot <acourbot@nvidia.com> |
gpiolib: return -ENOENT if no GPIO mapping exists Some devices drivers make use of optional GPIO parameters. For such drivers, it is important to discriminate between the case where no GPIO mapping has been defined for the function they are requesting, and the case where a mapping exists but an error occured while resolving it or when acquiring the GPIO. This patch changes the family of gpiod_get() functions such that they will return -ENOENT if and only if no GPIO mapping is defined for the requested function. Other error codes are used when an actual error occured during the GPIO resolution. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
324a56e1 |
|
11-Dec-2013 |
Tejun Heo <tj@kernel.org> |
kernfs: s/sysfs_dirent/kernfs_node/ and rename its friends accordingly kernfs has just been separated out from sysfs and we're already in full conflict mode. Nothing can make the situation any worse. Let's take the chance to name things properly. This patch performs the following renames. * s/sysfs_elem_dir/kernfs_elem_dir/ * s/sysfs_elem_symlink/kernfs_elem_symlink/ * s/sysfs_elem_attr/kernfs_elem_file/ * s/sysfs_dirent/kernfs_node/ * s/sd/kn/ in kernfs proper * s/parent_sd/parent/ * s/target_sd/target/ * s/dir_sd/parent/ * s/to_sysfs_dirent()/rb_to_kn()/ * misc renames of local vars when they conflict with the above Because md, mic and gpio dig into sysfs details, this patch ends up modifying them. All are sysfs_dirent renames and trivial. While we can avoid these by introducing a dummy wrapping struct sysfs_dirent around kernfs_node, given the limited usage outside kernfs and sysfs proper, I don't think such workaround is called for. This patch is strictly rename only and doesn't introduce any functional difference. - mic / gpio renames were missing. Spotted by kbuild test robot. Signed-off-by: Tejun Heo <tj@kernel.org> Cc: Neil Brown <neilb@suse.de> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Ashutosh Dixit <ashutosh.dixit@intel.com> Cc: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
fdd6a5fe |
|
05-Dec-2013 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: update inline documentation of gpiod_get_index() The patch just accents that @dev could be NULL. There is no functional change. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
1a2a99c6 |
|
05-Dec-2013 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: introduce chip_* to print with chip->label prefix In several places we are printing messages with prefix based on chip->label. Introduced macros help us to do this easier and in uniform way. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
7589e59f |
|
05-Dec-2013 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
gpiolib: unify pr_* messages format This patch includes the following amendments: 1) use "?" as a label when the last one is not defined in gpiod_*; 2) whenever it's possible gpiod_* are used; 3) print a function name, if it's already used in other messages. Additionally it fixes an indentation in few places. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
ad824783 |
|
02-Dec-2013 |
Alexandre Courbot <acourbot@nvidia.com> |
gpio: better lookup method for platform GPIOs Change the format of the platform GPIO lookup tables to make them less confusing and improve lookup efficiency. The previous format was a single linked-list that required to compare the device name and function ID of every single GPIO defined for each lookup. Switch that to a list of per-device tables, so that the lookup can be done in two steps, omitting the GPIOs that are not relevant for a particular device. The matching rules are now defined as follows: - The device name must match *exactly*, and can be NULL for GPIOs not assigned to a particular device, - If the function ID in the lookup table is NULL, the con_id argument of gpiod_get() will not be used for lookup. However, if it is defined, it must match exactly. - The index must always match. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
9fb1f39e |
|
04-Dec-2013 |
Linus Walleij <linus.walleij@linaro.org> |
gpio/pinctrl: make gpio_chip members typed boolean This switches the two members of struct gpio_chip that were defined as unsigned foo:1 to bool, because that is indeed what they are. Switch all users in the gpio and pinctrl subsystems to assign these values with true/false instead of 0/1. The users outside these subsystems will survive since true/false is 1/0, atleast we set some kind of more strict typing example. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
b7d0a28a |
|
02-Dec-2013 |
Alexandre Courbot <acourbot@nvidia.com> |
gpio: rewrite gpiochip_offset_to_desc() gpiochip_offset_to_desc() was using gpio_to_desc(), which directly addresses the global GPIO array we are hoping to get rid of someday. Reimplement it using the descriptor array of the chip itself, after checking the requested offset is within the valid bounds of the chip. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
351cfe0f |
|
29-Nov-2013 |
Heikki Krogerus <heikki.krogerus@linux.intel.com> |
gpiolib: change a warning to debug message when failing to get gpio It's the drivers responsibility to react on failure to get the gpio descriptors and not the frameworks. Since there are some common peripherals that may or may not have certain pins connected to gpio lines, depending on the platform, printing the warning there may end up generating useless bug reports. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
35c5d7fd |
|
23-Nov-2013 |
Alexandre Courbot <acourbot@nvidia.com> |
gpiolib: use platform GPIO mappings as fallback For platforms that use device tree or ACPI as the standard way to look GPIOs up, allow the platform-defined GPIO mappings to be used as a fallback. This may be useful for platforms that need extra GPIOs mappings not defined by the firmware. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
7cc67b9c |
|
22-Nov-2013 |
Alexandre Courbot <acourbot@nvidia.com> |
gpiolib: fix lookup of platform-mapped GPIOs A typo resulted in GPIO lookup failing unconditionally. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Reported-by: Stephen Warren <swarren@wwwdotorg.org> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
209e64f9 |
|
18-Nov-2013 |
Alexandre Courbot <acourbot@nvidia.com> |
gpiolib: fix of_find_gpio() when OF not defined The prototype for static GPIO lookup functions has been updated to use an explicit type for GPIO lookup flags. Unfortunately the definition of of_find_gpio() when CONFIG_OF is not defined has been omitted, which triggers a warning. This patch fixes this. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
61c6375d |
|
13-Nov-2013 |
Michal Nazarewicz <mina86@mina86.com> |
gpio: fix memory leak in error path Signed-off-by: Michal Nazarewicz <mina86@mina86.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
53e7cac3 |
|
16-Nov-2013 |
Alexandre Courbot <acourbot@nvidia.com> |
gpiolib: use dedicated flags for GPIO properties GPIO mapping properties were defined using the GPIOF_* flags, which are declared in linux/gpio.h. This file is not included when using the GPIO descriptor interface. This patch declares the flags that can be used as GPIO mappings properties in linux/gpio/driver.h, and uses them in gpiolib, so that no deprecated declarations are used by the GPIO descriptor interface. This patch also allows GPIO_OPEN_DRAIN and GPIO_OPEN_SOURCE to be specified as GPIO mapping properties. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
79697ef9 |
|
16-Nov-2013 |
Alexandre Courbot <acourbot@nvidia.com> |
gpiolib: fix find_chip_by_name() find_chip_by_name() was incorrectly implemented by using gpio_lookup_list instead of gpiod_chips to iterate through all the registered GPIO controllers. This patch reimplements it by using gpiochip_find() with a custom search function, which simplifies the code on top of fixing the mistake. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
7b199811 |
|
11-Nov-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / driver core: Store an ACPI device pointer in struct acpi_dev_node Modify struct acpi_dev_node to contain a pointer to struct acpi_device associated with the given device object (that is, its ACPI companion device) instead of an ACPI handle corresponding to it. Introduce two new macros for manipulating that pointer in a CONFIG_ACPI-safe way, ACPI_COMPANION() and ACPI_COMPANION_SET(), and rework the ACPI_HANDLE() macro to take the above changes into account. Drop the ACPI_HANDLE_SET() macro entirely and rework its users to use ACPI_COMPANION_SET() instead. For some of them who used to pass the result of acpi_get_child() directly to ACPI_HANDLE_SET() introduce a helper routine acpi_preset_companion() doing an equivalent thing. The main motivation for doing this is that there are things represented by struct acpi_device objects that don't have valid ACPI handles (so called fixed ACPI hardware features, such as power and sleep buttons) and we would like to create platform device objects for them and "glue" them to their ACPI companions in the usual way (which currently is impossible due to the lack of valid ACPI handles). However, there are more reasons why it may be useful. First, struct acpi_device pointers allow of much better type checking than void pointers which are ACPI handles, so it should be more difficult to write buggy code using modified struct acpi_dev_node and the new macros. Second, the change should help to reduce (over time) the number of places in which the result of ACPI_HANDLE() is passed to acpi_bus_get_device() in order to obtain a pointer to the struct acpi_device associated with the given "physical" device, because now that pointer is returned by ACPI_COMPANION() directly. Finally, the change should make it easier to write generic code that will build both for CONFIG_ACPI set and unset without adding explicit compiler directives to it. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> # on Haswell Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Aaron Lu <aaron.lu@intel.com> # for ATA and SDIO part
|
#
e01f440a |
|
10-Oct-2013 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
gpiolib / ACPI: allow passing GPIOF_ACTIVE_LOW for GpioInt resources The ACPI GpioInt resources contain polarity field that is used to specify whether the interrupt is active high or low. Since gpiolib supports GPIOF_ACTIVE_LOW we can pass this information in the flags field in acpi_find_gpio(), analogous to the DeviceTree version. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
81f59e9d |
|
10-Oct-2013 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
gpiolib / ACPI: add ACPI support for gpiod_get_index() gpiod_get_index() and gpiod_get() are now the new preferred way to request GPIOs. Add support for finding the corresponding GPIO descriptor from ACPI namespace. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
bae48da2 |
|
17-Oct-2013 |
Alexandre Courbot <acourbot@nvidia.com> |
gpiolib: add gpiod_get() and gpiod_put() functions Add gpiod_get(), gpiod_get_index() and gpiod_put() functions that provide safer management of GPIOs. These functions put the GPIO framework in line with the conventions of other frameworks in the kernel, and help ensure every GPIO is declared properly and valid while it is used. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
79a9becd |
|
17-Oct-2013 |
Alexandre Courbot <acourbot@nvidia.com> |
gpiolib: export descriptor-based GPIO interface This patch exports the gpiod_* family of API functions, a safer alternative to the legacy GPIO interface. Differences between the gpiod and legacy gpio APIs are: - gpio works with integers, whereas gpiod operates on opaque handlers which cannot be forged or used before proper acquisition - gpiod get/set functions are aware of the active low state of a GPIO - gpio consumers should now include <linux/gpio/consumer.h> to access the new interface, whereas chips drivers will use <linux/gpio/driver.h> The legacy gpio API is now built as inline functions on top of gpiod. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
586a87e6 |
|
15-Oct-2013 |
Christian Ruppert <christian.ruppert@abilis.com> |
pinctrl/gpio: non-linear GPIO ranges accesible from gpiolib This patch adds the infrastructure required to register non-linear gpio ranges through gpiolib and the standard GPIO device tree bindings. Signed-off-by: Christian Ruppert <christian.ruppert@abilis.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
d468bf9e |
|
24-Sep-2013 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: add API to be strict about GPIO IRQ usage It is currently often possible in many GPIO drivers to request a GPIO line to be used as IRQ after calling gpio_to_irq() and, as the gpiolib is not aware of this, set the same line to output and start driving it, with undesired side effects. As it is a bogus usage scenario to request a line flagged as output to used as IRQ, we introduce APIs to let gpiolib track the use of a line as IRQ, and also set this flag from the userspace ABI. The API is symmetric so that lines can also be flagged from .irq_enable() and unflagged from IRQ by .irq_disable(). The debugfs file is altered so that we see if a line is reserved for IRQ. Cc: Enric Balletbo i Serra <eballetbo@gmail.com> Cc: Grant Likely <grant.likely@linaro.org> Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
0204df47 |
|
04-Oct-2013 |
Alexandre Courbot <acourbot@nvidia.com> |
gpiolib: let gpiod_request() return -EPROBE_DEFER Patch be1a4b brought some improvements to the GPIO error handling code, but also changed the return value of gpiod_request() when called on a not yet initialized GPIO descriptor: it now returns -EINVAL instead of -EPROBE_DEFER, and this affects some drivers. This patch restores the original behavior for gpiod_request(). It is safe to do so now that desc_to_gpio() does not rely on the GPIO descriptor to be initialized. Other functions changed by patch be1a4b do not see their return value affected, so these are not reverted. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Reported-by: Dr. H. Nikolaus Schaller <hns@goldelico.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
8c0fca81 |
|
04-Oct-2013 |
Alexandre Courbot <acourbot@nvidia.com> |
gpiolib: safer implementation of desc_to_gpio() The current implementation of desc_to_gpio() relies on the chip pointer to be set to a valid value in order to compute the GPIO number. This was done in the hope that we can get rid of the gpio_desc global array, but this is not happening anytime soon. This patch reimplements desc_to_gpio() in a fashion similar to that of gpio_to_desc(). As a result, desc_to_gpio(gpio_to_desc(gpio)) == gpio is now always true. This allows to call desc_to_gpio() on non-initialized descriptors as some error-handling code currently does. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Reported-by: Dr. H. Nikolaus Schaller <hns@goldelico.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
388975cc |
|
11-Sep-2013 |
Tejun Heo <tj@kernel.org> |
sysfs: clean up sysfs_get_dirent() The pre-existing sysfs interfaces which take explicit namespace argument are weird in that they place the optional @ns in front of @name which is contrary to the established convention. For example, we end up forcing vast majority of sysfs_get_dirent() users to do sysfs_get_dirent(parent, NULL, name), which is silly and error-prone especially as @ns and @name may be interchanged without causing compilation warning. This renames sysfs_get_dirent() to sysfs_get_dirent_ns() and swap the positions of @name and @ns, and sysfs_get_dirent() is now a wrapper around sysfs_get_dirent_ns(). This makes confusions a lot less likely. There are other interfaces which take @ns before @name. They'll be updated by following patches. This patch doesn't introduce any functional changes. v2: EXPORT_SYMBOL_GPL() wasn't updated leading to undefined symbol error on module builds. Reported by build test robot. Fixed. Signed-off-by: Tejun Heo <tj@kernel.org> Cc: Eric W. Biederman <ebiederm@xmission.com> Cc: Kay Sievers <kay@vrfy.org> Cc: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
d8e0ac08 |
|
04-Sep-2013 |
Alexandre Courbot <acourbot@nvidia.com> |
gpiolib: factorize gpiod_get/set functions gpiod_get/set functions share common code between their regular and cansleep variants. The exporting of the gpiod interface will make the situation worse. This patch factorizes the common code to avoid code redundancy. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
7b17b59f |
|
09-Sep-2013 |
Mark Brown <broonie@linaro.org> |
gpiolib: Include GPIO label in log messages for GPIOs Provide the human readable label for the GPIO as well as the number when we are recording it in order to improve the readability of log messages. Signed-off-by: Mark Brown <broonie@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
6424de5a |
|
09-Sep-2013 |
Mark Brown <broonie@linaro.org> |
gpiolib: Provide helper macros for logging of GPIO events Currently many but not all GPIO log messages log the GPIO number and the formats vary. Ensure that this is done consistently by defining logging helpers which take the GPIO descriptor. The will help people pattern matching on logs and providing the number makes the log messages that omitted it more useful. Signed-off-by: Mark Brown <broonie@linaro.org> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
65d87656 |
|
04-Sep-2013 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: return -ENOTSUPP if debounce cannot be set It appears some drivers are using gpio_set_debounce() opportunistically, i.e. without knowing whether it works or not. (Example: input/keyboard/gpio_keys.c) to account for this use case, return -ENOTSUPP and do not print any warnings in this case. Took a round over the other gpio_set_debounce() consumers to make sure that none of them are relying on the returned error code to be something specific. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
be1a4b13 |
|
30-Aug-2013 |
Linus Walleij <linus.walleij@linaro.org> |
gpio: improve error path in gpiolib At several places the gpiolib will proceed to handle a GPIO descriptor even if it's ->chip member is NULL and no gpiochip is associated. Fix this by checking that both the descriptor cookie *and* the chip pointer are valid. Also bail out earlier with more specific diagnostic messages on missing operations for setting as input/output or debounce. ChangeLog v1->v2: - Also return -EIO on gpiod_set_debounce() with missing operations in the vtable - Fix indentations. Suggested-by: Alexandre Courbot <acourbot@nvidia.com> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Frank Rowand <frank.rowand@sonymobile.com> Cc: Tim Bird <tim.bird@sonymobile.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
a3d88c92 |
|
19-Jul-2013 |
Jingoo Han <jg1.han@samsung.com> |
gpiolib: replace strict_strtol() with kstrtol() The usage of strict_strtol() is not preferred, because strict_strtol() is obsolete. Thus, kstrtol() should be used. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
3bae4811 |
|
08-Jun-2013 |
Zhangfei Gao <zhangfei.gao@linaro.org> |
gpiolib: remove warnning of allocations with IRQs disabled Move of_gpiochip_add outof spin_lock, since kzalloc inside of_gpiochip_add -> of_gpiochip_add_pin_range -> gpiochip_add_pin_range -> kzalloc WARNING: at kernel/lockdep.c:2740 lockdep_trace_alloc+0xf8/0xfc() DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags)) Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
24d7628f |
|
14-Feb-2013 |
Alexandre Courbot <acourbot@nvidia.com> |
gpiolib: move comment to right function This comment applies to gpio_to_chip(), not gpiod_to_chip(). Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
#
def63433 |
|
14-Feb-2013 |
Alexandre Courbot <acourbot@nvidia.com> |
gpiolib: use const parameters when possible Constify descriptor parameter of gpiod_* functions for those that should obviously not modify it. This includes value or direction get, cansleep, and IRQ number query. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
#
bcabdef1 |
|
14-Feb-2013 |
Alexandre Courbot <acourbot@nvidia.com> |
gpiolib: check descriptors validity before use Some functions dereferenced their GPIO descriptor argument without checking its validity first, potentially leading to an oops when given an invalid argument. This patch also makes gpio_get_value() more resilient when given an invalid GPIO, returning 0 instead of silently crashing. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Cc: Ryan Mallon <rmallon@gmail.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
#
62f516b8 |
|
27-Feb-2013 |
Tejun Heo <tj@kernel.org> |
gpio: convert to idr_alloc() Convert to the much saner new idr interface. Signed-off-by: Tejun Heo <tj@kernel.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Cc: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
362432ae |
|
09-Feb-2013 |
Grant Likely <grant.likely@secretlab.ca> |
gpiolib: Fix locking on gpio debugfs files The debugfs files really need to hold the gpiolib spinlock before accessing the list. Otherwise chip addition/removal will cause an oops. Cc: Alexandre Courbot <acourbot@nvidia.com> Cc: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
#
6c0b4e6c |
|
02-Feb-2013 |
Alexandre Courbot <acourbot@nvidia.com> |
gpiolib: let gpio_chip reference its descriptors Add a pointer to the gpio_chip structure that references the array of GPIO descriptors belonging to the chip, and update gpiolib code to use this pointer instead of the global gpio_desc[] array. This is another step towards the removal of the gpio_desc[] global array. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.orh> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
#
372e722e |
|
02-Feb-2013 |
Alexandre Courbot <acourbot@nvidia.com> |
gpiolib: use descriptors internally Make sure gpiolib works internally with descriptors and (chip, offset) pairs instead of using the global integer namespace. This prepares the ground for the removal of the global gpio_desc[] array and the introduction of the descriptor-based GPIO API. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> [grant.likely: Squash in fix for link error when CONFIG_SYSFS=n] Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
#
83cabe33 |
|
02-Feb-2013 |
Alexandre Courbot <acourbot@nvidia.com> |
gpiolib: use gpio_chips list in gpiochip_find_base Re-implement gpiochip_find_base using the list of chips instead of the global gpio_desc[] array. This makes it both simpler and more efficient, and is needed to remove the global descriptors array. The new code should preserve the exact same GPIO number assignment policy as the code it is replacing. There shouldn't be any visible change to the assigned GPIO numbers. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> [grant.likely: Added comment about assignment policy] Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
#
cb1650d4 |
|
02-Feb-2013 |
Alexandre Courbot <acourbot@nvidia.com> |
gpiolib: use gpio_chips list in sysfs ops This makes the code both simpler and faster compared to parsing the GPIO number space. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
#
125eef96 |
|
02-Feb-2013 |
Alexandre Courbot <acourbot@nvidia.com> |
gpiolib: use gpio_chips list in gpiochip_find Using the GPIO chips list is much faster than parsing the entire GPIO number space. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
#
65493e3a |
|
02-Feb-2013 |
Alexandre Courbot <acourbot@nvidia.com> |
gpiolib: use gpio_chips list in gpiolib_sysfs_init Use the small list of GPIO chips instead of parsing the whole GPIO number space. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
#
1a989d0f |
|
02-Feb-2013 |
Alexandre Courbot <acourbot@nvidia.com> |
gpiolib: link all gpio_chips using a list Add a list member to gpio_chip that allows all chips to be parsed quickly. The current method requires parsing the entire GPIO integer space, which is painfully slow. Using a list makes many chip operations that involve lookup or parsing faster, and also simplifies the code. It is also necessary to eventually get rid of the global gpio_desc[] array. The list of gpio_chips is always ordered by base GPIO number to ensure chips traversal is done in the right order. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
#
9f3b795a |
|
01-Feb-2013 |
Michał Mirosław <mirq-linux@rere.qmqm.pl> |
driver-core: constify data for class_find_device() All in-kernel users of class_find_device() don't really need mutable data for match callback. In two places (kernel/power/suspend_test.c, drivers/scsi/osd/osd_uld.c) this patch changes match callbacks to use const search data. The const is propagated to rtc_class_open() and power_supply_get_by_name() parameters. Note that there's a dev reference leak in suspend_test.c that's not touched in this patch. Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Acked-by: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
476171ce |
|
04-Feb-2013 |
Alexandre Courbot <acourbot@nvidia.com> |
gpiolib: add missing braces in gpio_direction_show Add missing braces in an if..else condition. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
710b40ea |
|
02-Feb-2013 |
Alexandre Courbot <acourbot@nvidia.com> |
gpiolib: remove gpiochip_reserve() gpiochip_reserve() has no user and stands in the way of the removal of the static gpio_desc[] array. Remove this function as well as the now unneeded RESERVED flag of struct gpio_desc. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
b4d4b1f0 |
|
20-Nov-2012 |
Axel Lin <axel.lin@ingics.com> |
gpiolib: Fix use after free in gpiochip_add_pin_range This is introduced by commit 9ab6e988 "gpiolib: return any error code from range creation". Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
316511c0 |
|
21-Nov-2012 |
Linus Walleij <linus.walleij@linaro.org> |
gpiolib: rename pin range arguments To be crystal clear on what the arguments mean in this funtion dealing with both GPIO and PIN ranges with confusing naming, we now have gpio_offset and pin_offset and we are on the clear that these are offsets into the specific GPIO and pin controller respectively. The GPIO chip itself will of course keep track of the base offset into the global GPIO number space. Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
8f23ca1a |
|
20-Nov-2012 |
Linus Walleij <linus.walleij@linaro.org> |
gpiolib: return any error code from range creation If we try to create a range for a certain GPIO chip and the target pin controller is not yet available it may return a probe deferral error code, so handle this all the way our by checking the error code. Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
192c369c |
|
20-Nov-2012 |
Linus Walleij <linus.walleij@linaro.org> |
gpiolib: rename find_pinctrl_* Rename the function find_pinctrl_and_add_gpio_range() to pinctrl_find_and_add_gpio_range() so as to be consistent with the rest of the functions. Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
3f0f8670 |
|
19-Nov-2012 |
Linus Walleij <linus.walleij@linaro.org> |
gpiolib: let gpiochip_add_pin_range() specify offset Like with commit 3c739ad0df5eb41cd7adad879eda6aa09879eb76 it is not always enough to specify all the pins of a gpio_chip from offset zero to be added to a pin map range, since the mapping from GPIO to pin controller may not be linear at all, but need to be broken into a few consecutive sub-ranges or 1-pin entries for complicated cases. The ranges may also be sparse. This alters the signature of the function to accept offsets into both the GPIO-chip local pinspace and the pin controller local pinspace. Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
1e63d7b9 |
|
06-Nov-2012 |
Linus Walleij <linus.walleij@linaro.org> |
gpiolib: separation of pin concerns The fact that of_gpiochip_add_pin_range() and gpiochip_add_pin_range() share too much code is fragile and will invariably mean that bugs need to be fixed in two places instead of one. So separate the concerns of gpiolib.c and gpiolib-of.c and have the latter call the former as back-end. This is necessary also when going forward with other device descriptions such as ACPI. This is done by: - Adding a return code to gpiochip_add_pin_range() so we can reliably check whether this succeeds. - Get rid of the custom of_pinctrl_add_gpio_range() from pinctrl. Instead create of_pinctrl_get() to just retrive the pin controller per se from an OF node. This composite function was just begging to be deleted, it was way to purpose-specific. - Use pinctrl_dev_get_name() to get the name of the retrieved pin controller and use that to call back into the generic gpiochip_add_pin_range(). Now the pin range is only allocated and tied to a pin controller from the core implementation in gpiolib.c. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
9ef0d6f7 |
|
06-Nov-2012 |
Linus Walleij <linus.walleij@linaro.org> |
gpiolib: call pin removal in chip removal function This makes us call gpiochio_remove_pin_ranges() in the gpiochip_remove() function, so we get rid of ranges when freeing the chip. Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
165adc9c |
|
06-Nov-2012 |
Linus Walleij <linus.walleij@linaro.org> |
gpiolib: fix up function prototypes etc Commit 69e1601bca88809dc118abd1becb02c15a02ec71 "gpiolib: provide provision to register pin ranges" Got most of it's function prototypes wrong, so fix this up by: - Moving the void declarations into static inlines in <linux/gpio.h> (previously the actual prototypes were declared here...) - Declare the gpiochip_add_pin_range() and gpiochip_remove_pin_ranges() functions in <asm-generic/gpio.h> together with the pin range struct declaration itself. - Actually only implement these very functions in gpiolib.c if CONFIG_PINCTRL is set. - Additionally export the symbols since modules will need to be able to do this. Reviewed-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
f23f1516 |
|
27-Oct-2012 |
Shiraz Hashim <shiraz.linux.kernel@gmail.com> |
gpiolib: provide provision to register pin ranges pinctrl subsystem needs gpio chip base to prepare set of gpio pin ranges, which a given pinctrl driver can handle. This is important to handle pinctrl gpio request calls in order to program a given pin properly for gpio operation. As gpio base is allocated dynamically during gpiochip registration, presently there exists no clean way to pass this information to the pinctrl subsystem. After few discussions from [1], it was concluded that may be gpio controller reporting the pin range it supports, is a better way than pinctrl subsystem directly registering it. [1] http://comments.gmane.org/gmane.linux.ports.arm.kernel/184816 Cc: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Shiraz Hashim <shiraz.hashim@st.com> [Edited documentation a bit] Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
529f2ad5 |
|
26-Oct-2012 |
Dan Carpenter <dan.carpenter@oracle.com> |
gpiolib: unlock on error in gpio_export() We need to unlock here before returning. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
ad2fab36 |
|
25-Oct-2012 |
Mathias Nyman <mathias.nyman@linux.intel.com> |
gpiolib: Don't return -EPROBE_DEFER to sysfs, or for invalid gpios gpios requested with invalid numbers, or gpios requested from userspace via sysfs should not try to be deferred on failure. Cc: stable@kernel.org Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
80b0a602 |
|
24-Oct-2012 |
Mathias Nyman <mathias.nyman@linux.intel.com> |
gpiolib: add gpio get direction callback support Add .get_direction callback to gpio_chip. This allows gpiolib to check the current direction of a gpio. Used to show the correct gpio direction in sysfs and debug entries. If callback is not set then gpiolib will work as previously; e.g. guessing everything is input until a direction is set. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
fc4e2514 |
|
21-Oct-2012 |
Ryan Mallon <rmallon@gmail.com> |
gpiolib: Refactor gpio_export The gpio_export function uses nested if statements and the status variable to handle the failure cases. This makes the function logic difficult to follow. Refactor the code to abort immediately on failure using goto. This makes the code slightly longer, but significantly reduces the nesting and number of split lines and makes the code easier to read. Signed-off-by: Ryan Mallon <rmallon@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
f9c4a31f |
|
12-Apr-2012 |
Thierry Reding <thierry.reding@avionic-design.de> |
gpiolib: Use seq_file's iterator interface When dumping a collection of items via seq_file, it is recommended to use the iterator interface. For the gpiolib debugfs interface this can be done to dump each GPIO chip in turn. Note that for gpiolib this is a little cumbersome because it does not provide a list of registered GPIO chips and the only way to iterate is over each GPIO individually. Once a chip is found, the number of GPIOs it provides can be skipped as a small optimization. This patch was requested by Arnd Bergmann here: http://article.gmane.org/gmane.linux.ports.tegra/3535 Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de> Cc: Linus Walleij <linus.walleij@stericsson.com> Cc: Grant Likely <grant.likely@secretlab.ca> Cc: linux-kernel@vger.kernel.org Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
e9354576 |
|
08-Jul-2012 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
gpiolib: Defer failed gpio requests by default Since users must be explicitly provided with a GPIO number in order to request one the overwhelmingly common case for failing to request will be that the required GPIO driver has not yet registered and we should therefore defer until it has registered. In order to avoid having to code this logic in individual drivers have gpio_request() return -EPROBE_DEFER when failing to look up the GPIO. Drivers which don't want this behaviour can override it if they desire. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
#
07ce8ec7 |
|
18-May-2012 |
Grant Likely <grant.likely@secretlab.ca> |
gpiolib: Remove 'const' from data argument of gpiochip_find() Commit 3d0f7cf0 "gpio: Adjust of_xlate API to support multiple GPIO chips" changed the api of gpiochip_find to drop const from the data parameter of the match hook, but didn't also drop const from data causing a build warning. Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
#
ee1c1e7d |
|
11-May-2012 |
H Hartley Sweeten <hartleys@visionengravers.com> |
gpiolib: quiet gpiochip_add boot message noise The pr_info message in gpiochip_add gets displayed for every gpiochip registered. When first bringing up a system this information could be helpful but for normal use it's just a bunch of noise. Change the message to a pr_debug. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
#
3d0f7cf0 |
|
17-May-2012 |
Grant Likely <grant.likely@secretlab.ca> |
gpio: Adjust of_xlate API to support multiple GPIO chips This patch changes the of_xlate API to make it possible for multiple gpio_chips to refer to the same device tree node. This is useful for banked GPIO controllers that use multiple gpio_chips for a single device. With this change the core code will try calling of_xlate on each gpio_chip that references the device_node and will return the gpio number for the first one to return 'true'. Tested-by: Roland Stigge <stigge@antcom.de> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
#
fc3a1f04 |
|
13-Dec-2011 |
Wolfram Sang <wsa@kernel.org> |
gpio: add flags to export GPIOs when requesting Introduce new flags to automatically export GPIOs when using the convenience functions gpio_request_one() or gpio_request_array(). This eases support for custom boards where lots of GPIOs need to be exported for customer applications. Signed-off-by: Wolfram Sang <w.sang@pengutronix.de> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
#
e4e449e8 |
|
17-Feb-2012 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
gpiolib: Add comments explaining the _cansleep() WARN_ON()s I've seen users getting very confused by the WARN_ON()s for can_sleep GPIOs in the atomic-safe paths, the discoverability of the non-atomic version of the API seems to be hampered by the fact that it's defined in a header file not the .c file where the warnings are. Add a couple of comments next to the warnings to help people on their way. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Reviwed-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
#
25553ff0 |
|
17-Feb-2012 |
Laxman Dewangan <ldewangan@nvidia.com> |
gpio: gpiolib: Support for open source/emitter gpios Adding support for the open source gpio on which client can specify the open source property through GPIO flag GPIOF_OPEN_SOURCE at the time of gpio request. The open source pins are normally pulled low and it cannot be driven to output with value of 0 and so when client request for setting the pin to LOW, the gpio will be set to input direction to make pin in tristate and hence PULL-DOWN on pins will make the state to LOW. The open source pin can be driven to HIGH by setting output with value of 1. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Reviwed-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
#
aca5ce14 |
|
17-Feb-2012 |
Laxman Dewangan <ldewangan@nvidia.com> |
gpio: gpiolib: Support for open drain/collector gpios Adding support for the open drain gpio on which client can specify the open drain property through GPIO flag GPIOF_OPEN_DRAIN at the time of gpio request. The open drain pins are normally pulled high and it cannot be driven to output with value of 1 and so when client request for setting the pin to HIGH, the gpio will be set to input direction to make pin in tristate and hence PULL-UP on pins will make the state to HIGH. The open drain pin can be driven to LOW by setting output with value of 0. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Reviwed-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
#
6e2cf651 |
|
02-Mar-2012 |
Grant Likely <grant.likely@secretlab.ca> |
gpio: constify the data parameter to gpiochip_find() Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
#
864533ce |
|
13-Feb-2012 |
Ming Lei <tom.leiming@gmail.com> |
Fix circular locking dependency (3.3-rc2) Hi, On Wed, Feb 8, 2012 at 8:41 PM, Felipe Balbi <balbi@ti.com> wrote: > Hi guys, > > I have just triggered the folllowing: > > [ 84.860321] ====================================================== > [ 84.860321] [ INFO: possible circular locking dependency detected ] > [ 84.860321] 3.3.0-rc2-00026-ge4e8a39 #474 Not tainted > [ 84.860321] ------------------------------------------------------- > [ 84.860321] bash/949 is trying to acquire lock: > [ 84.860321] (sysfs_lock){+.+.+.}, at: [<c0275358>] gpio_value_store+0x24/0xcc > [ 84.860321] > [ 84.860321] but task is already holding lock: > [ 84.860321] (s_active#22){++++.+}, at: [<c016996c>] sysfs_write_file+0xdc/0x184 > [ 84.911468] > [ 84.911468] which lock already depends on the new lock. > [ 84.911468] > [ 84.920043] > [ 84.920043] the existing dependency chain (in reverse order) is: > [ 84.920043] > [ 84.927886] -> #1 (s_active#22){++++.+}: > [ 84.927886] [<c008f640>] check_prevs_add+0xdc/0x150 > [ 84.927886] [<c008fc18>] validate_chain.clone.24+0x564/0x694 > [ 84.927886] [<c0090cdc>] __lock_acquire+0x49c/0x980 > [ 84.951660] [<c0091838>] lock_acquire+0x98/0x100 > [ 84.951660] [<c016a8e8>] sysfs_deactivate+0xb0/0x100 > [ 84.962982] [<c016b1b4>] sysfs_addrm_finish+0x2c/0x6c > [ 84.962982] [<c016b8bc>] sysfs_remove_dir+0x84/0x98 > [ 84.962982] [<c02590d8>] kobject_del+0x10/0x78 > [ 84.974670] [<c02c29e8>] device_del+0x140/0x170 > [ 84.974670] [<c02c2a24>] device_unregister+0xc/0x18 > [ 84.985382] [<c0276894>] gpio_unexport+0xbc/0xdc > [ 84.985382] [<c02768c8>] gpio_free+0x14/0xfc > [ 85.001708] [<c0276a28>] unexport_store+0x78/0x8c > [ 85.001708] [<c02c5af8>] class_attr_store+0x18/0x24 > [ 85.007293] [<c0169990>] sysfs_write_file+0x100/0x184 > [ 85.018981] [<c0109d48>] vfs_write+0xb4/0x148 > [ 85.018981] [<c0109fd0>] sys_write+0x40/0x70 > [ 85.018981] [<c0013cc0>] ret_fast_syscall+0x0/0x3c > [ 85.035003] > [ 85.035003] -> #0 (sysfs_lock){+.+.+.}: > [ 85.035003] [<c008f54c>] check_prev_add+0x680/0x698 > [ 85.035003] [<c008f640>] check_prevs_add+0xdc/0x150 > [ 85.052093] [<c008fc18>] validate_chain.clone.24+0x564/0x694 > [ 85.052093] [<c0090cdc>] __lock_acquire+0x49c/0x980 > [ 85.052093] [<c0091838>] lock_acquire+0x98/0x100 > [ 85.069885] [<c047e280>] mutex_lock_nested+0x3c/0x2f4 > [ 85.069885] [<c0275358>] gpio_value_store+0x24/0xcc > [ 85.069885] [<c02c18dc>] dev_attr_store+0x18/0x24 > [ 85.087158] [<c0169990>] sysfs_write_file+0x100/0x184 > [ 85.087158] [<c0109d48>] vfs_write+0xb4/0x148 > [ 85.098297] [<c0109fd0>] sys_write+0x40/0x70 > [ 85.098297] [<c0013cc0>] ret_fast_syscall+0x0/0x3c > [ 85.109069] > [ 85.109069] other info that might help us debug this: > [ 85.109069] > [ 85.117462] Possible unsafe locking scenario: > [ 85.117462] > [ 85.117462] CPU0 CPU1 > [ 85.128417] ---- ---- > [ 85.128417] lock(s_active#22); > [ 85.128417] lock(sysfs_lock); > [ 85.128417] lock(s_active#22); > [ 85.142486] lock(sysfs_lock); > [ 85.151794] > [ 85.151794] *** DEADLOCK *** > [ 85.151794] > [ 85.151794] 2 locks held by bash/949: > [ 85.158020] #0: (&buffer->mutex){+.+.+.}, at: [<c01698b8>] sysfs_write_file+0x28/0x184 > [ 85.170349] #1: (s_active#22){++++.+}, at: [<c016996c>] sysfs_write_file+0xdc/0x184 > [ 85.170349] > [ 85.178588] stack backtrace: > [ 85.178588] [<c001b824>] (unwind_backtrace+0x0/0xf0) from [<c008de64>] (print_circular_bug+0x100/0x114) > [ 85.193023] [<c008de64>] (print_circular_bug+0x100/0x114) from [<c008f54c>] (check_prev_add+0x680/0x698) > [ 85.193023] [<c008f54c>] (check_prev_add+0x680/0x698) from [<c008f640>] (check_prevs_add+0xdc/0x150) > [ 85.212524] [<c008f640>] (check_prevs_add+0xdc/0x150) from [<c008fc18>] (validate_chain.clone.24+0x564/0x694) > [ 85.212524] [<c008fc18>] (validate_chain.clone.24+0x564/0x694) from [<c0090cdc>] (__lock_acquire+0x49c/0x980) > [ 85.233306] [<c0090cdc>] (__lock_acquire+0x49c/0x980) from [<c0091838>] (lock_acquire+0x98/0x100) > [ 85.233306] [<c0091838>] (lock_acquire+0x98/0x100) from [<c047e280>] (mutex_lock_nested+0x3c/0x2f4) > [ 85.242614] [<c047e280>] (mutex_lock_nested+0x3c/0x2f4) from [<c0275358>] (gpio_value_store+0x24/0xcc) > [ 85.261840] [<c0275358>] (gpio_value_store+0x24/0xcc) from [<c02c18dc>] (dev_attr_store+0x18/0x24) > [ 85.261840] [<c02c18dc>] (dev_attr_store+0x18/0x24) from [<c0169990>] (sysfs_write_file+0x100/0x184) > [ 85.271240] [<c0169990>] (sysfs_write_file+0x100/0x184) from [<c0109d48>] (vfs_write+0xb4/0x148) > [ 85.290008] [<c0109d48>] (vfs_write+0xb4/0x148) from [<c0109fd0>] (sys_write+0x40/0x70) > [ 85.298400] [<c0109fd0>] (sys_write+0x40/0x70) from [<c0013cc0>] (ret_fast_syscall+0x0/0x3c) > -bash: echo: write error: Operation not permitted > > the way to trigger is: > > root@legolas:~# cd /sys/class/gpio/ > root@legolas:/sys/class/gpio# echo 2 > export > root@legolas:/sys/class/gpio# echo 2 > unexport > root@legolas:/sys/class/gpio# echo 2 > export > root@legolas:/sys/class/gpio# cd gpio2/ > root@legolas:/sys/class/gpio/gpio2# echo 1 > value Looks 'sysfs_lock' needn't to be held for unregister, so the patch below may fix the problem. Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
#
1a2d397a |
|
12-Dec-2011 |
Grant Likely <grant.likely@secretlab.ca> |
gpio/powerpc: Eliminate duplication of of_get_named_gpio_flags() A large chunk of qe_pin_request() is unnecessarily cut-and-paste directly from of_get_named_gpio_flags(). This patch cuts out the duplicate code and replaces it with a call to of_get_gpio(). v2: fixed compile error due to missing gpio_to_chip() Signed-off-by: Grant Likely <grant.likely@secretlab.ca> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Kumar Gala <galak@kernel.crashing.org>
|
#
64842aad |
|
06-Nov-2011 |
Grant Likely <grant.likely@secretlab.ca> |
gpiolib: output basic details and consolidate gpio device drivers This patch adds a kernel message, containing GPIO range and device name on successful device registration, and removes duplicate messages from the following drivers: * gpio-adp5588 * gpio-bt8xx * gpio-cs5535 * gpio-janz-ttl * gpio-nomadik * gpio-pcf857x * gpio-xilinx * drivers/of/gpio.c Signed-off-by: Hartmut Knaack <knaack.h@gmx.de> [grant.likely@secretlab.ca: squashed 2 patches together] Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
#
7c295975 |
|
25-May-2011 |
Lars-Peter Clausen <lars@metafoo.de> |
gpio: make gpio_{request,free}_array gpio array parameter const gpio_{request,free}_array should not (and do not) modify the passed gpio array, so make the parameter const. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Acked-by: Eric Miao <eric.y.miao@gmail.com> Acked-by: Wolfram Sang <w.sang@pengutronix.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
#
3f397c21 |
|
20-May-2011 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
gpio: add trace events for setting direction and value This patch allows to trace gpio operations using ftrace Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
#
8fa0c9bf |
|
20-May-2011 |
Jean Delvare <khali@linux-fr.org> |
gpiolib: export gpiochip_find Export function gpiochip_find so that modules can use it. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
#
b15f052c |
|
24-Mar-2011 |
Thomas Gleixner <tglx@linutronix.de> |
arm/gpio: Remove three copies of broken and racy debug code gpiolib plus two gpio implementations in arm fiddle in the guts of irq_desc in a racy and buggy way. Remove the stuff. I already told the gpio folks that we can provide that information in a proper way if necessary. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Grant Likely <grant.likely@secretlab.ca> LKML-Reference: <20110324212508.931638262@linutronix.de>
|
#
e254811c |
|
21-Dec-2010 |
Aaro Koskinen <aaro.koskinen@nokia.com> |
gpiolib: gpio_request_one(): add missing gpio_free() If GPIO request succeeds, but configuration fails, it should be released. Signed-off-by: Aaro Koskinen <aaro.koskinen@nokia.com> Acked-by: Eric Miao <eric.miao@canonical.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
364fadb3 |
|
10-Aug-2010 |
Daniel Gl?ckner <dg@emlix.com> |
gpiolib: allow nested threaded irqs for poll(2) The pca953x driver requires the use of threaded irqs as its irq demultiplexer can sleep. Our irq handler can be called from any context, so use request_any_context_irq to allow threaded irqs as well. Signed-off-by: Daniel Gl?ckner <dg@emlix.com> Reported-by: Ian Jeffray <ian@jeffray.co.uk> Cc: David Brownell <david-b@pacbell.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
5ba1821d |
|
10-Aug-2010 |
Daniel Gl?ckner <dg@emlix.com> |
gpiolib: get rid of struct poll_desc and worklet As sysfs_notify_dirent has been made irq safe, there is no reason to not call it directly from irq. With the work_struct removed, the remaining element in poll_desc is a sysfs_dirent pointer which may not be NULL. We can therefore store it directly in the idr and pass it as context to the irq handler. Most part of the patch deals with renaming defines and variables to reflect their new use without functional change. I also took the opportunity to initialize the idr statically. Signed-off-by: Daniel Gl?ckner <dg@emlix.com> Cc: David Brownell <david-b@pacbell.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
9c4ba946 |
|
10-Aug-2010 |
David Brownell <dbrownell@users.sourceforge.net> |
gpiolib: decouple might_sleep_if() from DEBUG Be more consistent about runtime programming interface abuse warnings, which can reduce some confusion and trigger bugfixes. Based on an observation and patch from Jani Nikula. Also update doc to highlight some sleeping-call issues and to match some recent changes. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Cc: Jani Nikula <ext-jani.1.nikula@nokia.com> Cc: "Ryan Mallon" <ryan@bluewatersys.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
6a99ad4a |
|
27-Jul-2010 |
Jon Povey <jon.povey@racelogic.co.uk> |
gpio: fix spurious printk when freeing a gpio When freeing a gpio that has not been exported, gpio_unexport() prints a debug message when it should just fall through silently. Example spurious message: gpio_unexport: gpio0 status -22 Signed-off-by: Jon Povey <jon.povey@racelogic.co.uk> Cc: David Brownell <david-b@pacbell.net> Acked-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de> Cc: Gregory Bean <gbean@codeaurora.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
391c970c |
|
08-Jun-2010 |
Anton Vorontsov <avorontsov@ru.mvista.com> |
of/gpio: add default of_xlate function if device has a node pointer Implement generic OF gpio hooks and thus make device-enabled GPIO chips (i.e. the ones that have gpio_chip->dev specified) automatically attach to the OpenFirmware subsystem. Which means that now we can handle I2C and SPI GPIO chips almost* transparently. * "Almost" because some chips still require platform data, and for these chips OF-glue is still needed, though with this change the glue will be much smaller. Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca> Cc: David Brownell <dbrownell@users.sourceforge.net> Cc: Bill Gatliff <bgat@billgatliff.com> Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Jean Delvare <khali@linux-fr.org> Cc: Andrew Morton <akpm@linux-foundation.org> CC: linux-kernel@vger.kernel.org CC: devicetree-discuss@lists.ozlabs.org
|
#
594fa265 |
|
08-Jun-2010 |
Grant Likely <grant.likely@secretlab.ca> |
of/gpio: stop using device_node data pointer to find gpio_chip Currently the kernel uses the struct device_node.data pointer to resolve a struct gpio_chip pointer from a device tree node. However, the .data member doesn't provide any type checking and there aren't any rules enforced on what it should be used for. There's no guarantee that the data stored in it actually points to an gpio_chip pointer. Instead of relying on the .data pointer, this patch modifies the code to add a lookup function which scans through the registered gpio_chips and returns the gpio_chip that has a pointer to the specified device_node. Signed-off-by: Grant Likely <grant.likely@secretlab.ca> CC: Andrew Morton <akpm@linux-foundation.org> CC: Anton Vorontsov <avorontsov@ru.mvista.com> CC: Grant Likely <grant.likely@secretlab.ca> CC: David Brownell <dbrownell@users.sourceforge.net> CC: Bill Gatliff <bgat@billgatliff.com> CC: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org> CC: Jean Delvare <khali@linux-fr.org> CC: linux-kernel@vger.kernel.org CC: devicetree-discuss@lists.ozlabs.org
|
#
cedb1881 |
|
08-Jun-2010 |
Anton Vorontsov <avorontsov@ru.mvista.com> |
gpiolib: cosmetic improvements for error handling in gpiochip_add() Hopefully it makes the code look nicer and makes it easier to extend this function. Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Grant Likely <grant.likely@secretlab.ca> CC: devicetree-discuss@lists.ozlabs.org CC: linux-kernel@vger.kernel.org
|
#
c4b5be98 |
|
26-May-2010 |
Felipe Balbi <felipe.balbi@nokia.com> |
gpiolib: introduce set_debounce method A few architectures, like OMAP, allow you to set a debouncing time for the gpio before generating the IRQ. Teach gpiolib about that. Mark said: : This would be generally useful for embedded systems, especially where : the interrupt concerned is a wake source. It allows drivers to avoid : spurious interrupts from noisy sources so if the hardware supports it : the driver can avoid having to explicitly wait for the signal to become : stable and software has to cope with fewer events. We've lived without : it for quite some time, though. David said: : I looked at adding debounce support to the generic GPIO calls (and thus : gpiolib) some time back, but decided against it. I forget why at this : time (check list archives) but it wasn't because of lack of utility in : certain contexts. : : One thing to watch out for is just how variable the hardware capabilities : are. Atmel GPIOs have something like a fixed number of 32K clock cycles : for debounce, twl4030 had something odd, OMAPs were more like the Atmel : chips but with a different clock. In some cases debouncing had to be : ganged, not per-GPIO. And so forth. Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com> Cc: Tony Lindgren <tony@atomide.com> Cc: David Brownell <david-b@pacbell.net> Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
796a8e42 |
|
26-May-2010 |
Ben Dooks <ben-linux@fluff.org> |
gpiolib: make gpiochip_add() show a better error message The current message, 'not registered' is confusing as it implies it was not registered with something, whereas printing 'failed to register' implies it was the gpiochip_add() call that did not work correctly. Signed-off-by: Ben Dooks <ben-linux@fluff.org> Cc: David Brownell <david-b@pacbell.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
7cfe1395 |
|
26-May-2010 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
gpiolib: a gpio is unsigned, so use %u to print it Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Cc: David Brownell <david-b@pacbell.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
62154991 |
|
26-May-2010 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
gpiolib: make names array and its values const gpiolib doesn't need to modify the names and I assume most initializers use string constants that shouldn't be modified anyhow. [akpm@linux-foundation.org: fix drivers/gpio/cs5535-gpio.c] Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Cc: Kevin Wells <kevin.wells@nxp.com> Cc: David Brownell <david-b@pacbell.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
3ff195b0 |
|
30-Mar-2010 |
Eric W. Biederman <ebiederm@xmission.com> |
sysfs: Implement sysfs tagged directory support. The problem. When implementing a network namespace I need to be able to have multiple network devices with the same name. Currently this is a problem for /sys/class/net/*, /sys/devices/virtual/net/*, and potentially a few other directories of the form /sys/ ... /net/*. What this patch does is to add an additional tag field to the sysfs dirent structure. For directories that should show different contents depending on the context such as /sys/class/net/, and /sys/devices/virtual/net/ this tag field is used to specify the context in which those directories should be visible. Effectively this is the same as creating multiple distinct directories with the same name but internally to sysfs the result is nicer. I am calling the concept of a single directory that looks like multiple directories all at the same path in the filesystem tagged directories. For the networking namespace the set of directories whose contents I need to filter with tags can depend on the presence or absence of hotplug hardware or which modules are currently loaded. Which means I need a simple race free way to setup those directories as tagged. To achieve a reace free design all tagged directories are created and managed by sysfs itself. Users of this interface: - define a type in the sysfs_tag_type enumeration. - call sysfs_register_ns_types with the type and it's operations - sysfs_exit_ns when an individual tag is no longer valid - Implement mount_ns() which returns the ns of the calling process so we can attach it to a sysfs superblock. - Implement ktype.namespace() which returns the ns of a syfs kobject. Everything else is left up to sysfs and the driver layer. For the network namespace mount_ns and namespace() are essentially one line functions, and look to remain that. Tags are currently represented a const void * pointers as that is both generic, prevides enough information for equality comparisons, and is trivial to create for current users, as it is just the existing namespace pointer. The work needed in sysfs is more extensive. At each directory or symlink creating I need to check if the directory it is being created in is a tagged directory and if so generate the appropriate tag to place on the sysfs_dirent. Likewise at each symlink or directory removal I need to check if the sysfs directory it is being removed from is a tagged directory and if so figure out which tag goes along with the name I am deleting. Currently only directories which hold kobjects, and symlinks are supported. There is not enough information in the current file attribute interfaces to give us anything to discriminate on which makes it useless, and there are no potential users which makes it an uninteresting problem to solve. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Benjamin Thery <benjamin.thery@bull.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
3913fd5e |
|
27-Apr-2010 |
Dan Carpenter <error27@gmail.com> |
gpio: potential null dereference Smatch found a potential null dereference in gpio_setup_irq(). The "pdesc" variable is allocated with idr_find() that can return NULL. If gpio_setup_irq() is called with 0 as gpio_flags and "pdesc" is null, it would OOPs here. Signed-off-by: Dan Carpenter <error27@gmail.com> Cc: David Brownell <david-b@pacbell.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
#
5a0e3ad6 |
|
24-Mar-2010 |
Tejun Heo <tj@kernel.org> |
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: Tejun Heo <tj@kernel.org> Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
|
#
28812fe1 |
|
04-Jan-2010 |
Andi Kleen <andi@firstfloor.org> |
driver-core: Add attribute argument to class_attribute show/store Passing the attribute to the low level IO functions allows all kinds of cleanups, by sharing low level IO code without requiring an own function for every piece of data. Also drivers can extend the attributes with own data fields and use that in the low level function. This makes the class attributes the same as sysdev_class attributes and plain attributes. This will allow further cleanups in drivers. Full tree sweep converting all users. Signed-off-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
3e45f1d1 |
|
05-Mar-2010 |
Eric Miao <eric.y.miao@gmail.com> |
gpio: introduce gpio_request_one() and friends gpio_request() without initial configuration of the GPIO is normally useless, introduce gpio_request_one() together with GPIOF_ flags for input/output direction and initial output level. gpio_{request,free}_array() for multiple GPIOs. Signed-off-by: Eric Miao <eric.y.miao@gmail.com> Cc: David Brownell <dbrownell@users.sourceforge.net> Cc: Ben Nizette <bn@niasdigital.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
24f3c59e |
|
08-Jan-2010 |
Jani Nikula <ext-jani.1.nikula@nokia.com> |
gpiolib: fix poll(2) support reconfigure on sysfs polarity change Previously enabled poll(2) support on one edge was never reconfigured when sysfs polarity change was triggered from kernel, because 'struct device *dev' shadowed an earlier definition. Found by sparse, which I should've run much earlier. Signed-off-by: Jani Nikula <ext-jani.1.nikula@nokia.com> Cc: David Brownell <david-b@pacbell.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
07697461 |
|
15-Dec-2009 |
Jani Nikula <ext-jani.1.nikula@nokia.com> |
gpiolib: add support for changing value polarity in sysfs Drivers may use gpiolib sysfs as part of their public user space interface. The GPIO number and polarity might change from board to board. The gpio_export_link() call can be used to hide the GPIO number from user space. Add support for also hiding the GPIO line polarity changes from user space. Signed-off-by: Jani Nikula <ext-jani.1.nikula@nokia.com> Cc: David Brownell <david-b@pacbell.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
d62668e1 |
|
11-Nov-2009 |
Sergei Shtylyov <sshtylyov@ru.mvista.com> |
gpiolib: fix device_create() result check In case of failure, device_create() returns not NULL but the error code. The current code checks for non-NULL though which causes kernel oops in sysfs_create_group() when device_create() fails. Check for error using IS_ERR() and propagate the error value using PTR_ERR() instead of fixed -ENODEV code returned now... Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> Cc: David Brownell <david-b@pacbell.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
828c0950 |
|
01-Oct-2009 |
Alexey Dobriyan <adobriyan@gmail.com> |
const: constify remaining file_operations [akpm@linux-foundation.org: fix KVM] Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Acked-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
ff77c352 |
|
22-Sep-2009 |
Daniel Glöckner <dg@emlix.com> |
gpiolib: allow poll() on value Many gpio chips allow to generate interrupts when the value of a pin changes. This patch gives usermode application the opportunity to make use of this feature by calling poll(2) on the /sys/class/gpio/gpioN/value sysfs file. The edge to trigger can be set in the edge file in the same directory. Possible values are "none", "rising", "falling", and "both". Using level triggers is not possible with current sysfs since nothing changes the GPIO value (and the IRQ keeps triggering). Edge triggering will "just work". Note that if there was an event between read() and poll(), the poll() returns immediately. Also note that this version only supports true GPIO interrupts. Some later patch might be able to synthesize this behavior by timer-driven polling; some systems seem to need that. [dbrownell@users.sourceforge.net: align ids to 16 bit ids; whitespace] Signed-off-by: Daniel Glöckner <dg@emlix.com> Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
a4177ee7 |
|
22-Sep-2009 |
Jani Nikula <ext-jani.1.nikula@nokia.com> |
gpiolib: allow exported GPIO nodes to be named using sysfs links Commit 926b663ce8215ba448960e1ff6e58b67a2c3b99b (gpiolib: allow GPIOs to be named) already provides naming on the chip level. This patch provides more flexibility by allowing multiple names where ever in sysfs on a per GPIO basis. Adapted from David Brownell's comments on a similar concept: http://lkml.org/lkml/2009/4/20/203. [randy.dunlap@oracle.com: fix build for CONFIG_GENERIC_GPIO=n] Signed-off-by: Jani Nikula <ext-jani.1.nikula@nokia.com> Acked-by: David Brownell <david-b@pacbell.net> Cc: Daniel Silverstone <dsilvers@simtec.co.uk> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
8a0cecff |
|
02-Apr-2009 |
David Brownell <dbrownell@users.sourceforge.net> |
gpio: gpio_{request,free}() now required (feature removal) We want to phase out the GPIO "autorequest" mechanism in gpiolib and require all callers to use gpio_request(). - Update feature-removal-schedule - Update the documentation now - Convert the relevant pr_warning() in gpiolib to a WARN() so folk using this mechanism get a noisy stack dump Some drivers and board init code will probably need to change. Implementations not using gpiolib will still be fine; they are already required to implement gpio_{request,free}() stubs. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
926b663c |
|
02-Apr-2009 |
Daniel Silverstone <dsilvers@simtec.co.uk> |
gpiolib: allow GPIOs to be named Allow GPIOs in GPIOLIB chips to be named. This name is then used when the GPIO is exported to sysfs, although it could be used elsewhere if deemed useful. Signed-off-by: Daniel Silverstone <dsilvers@simtec.co.uk> Cc: David Brownell <david-b@pacbell.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
7460db56 |
|
29-Jan-2009 |
Magnus Damm <damm@igel.co.jp> |
gpiolib: fix request related issue Fix request-already-requested handling in gpio_request(). Signed-off-by: Magnus Damm <damm@igel.co.jp> Acked-by: David Brownell <dbrownell@users.sourceforge.net> Cc: <stable@kernel.org> [2.6.28.x] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
14ab309d |
|
06-Jan-2009 |
Kay Sievers <kay.sievers@vrfy.org> |
gpio: struct device - replace bus_id with dev_name(), dev_set_name() Signed-off-by: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
6e8ba729 |
|
19-Nov-2008 |
Jarkko Nikula <jarkko.nikula@nokia.com> |
gpiolib: extend gpio label column width in debugfs file There are already various drivers having bigger label than 12 bytes. Most of them fit well under 20 bytes but make column width exact so that oversized labels don't mess up output alignment. Signed-off-by: Jarkko Nikula <jarkko.nikula@nokia.com> Acked-by: David Brownell <david-b@pacbell.net> Cc: <stable@kernel.org> [2.6.26.x, 2.6.26.x, 2.6.27.x] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
978ccaa8 |
|
18-Oct-2008 |
David Brownell <dbrownell@users.sourceforge.net> |
gpiolib: fix oops in gpio_get_value_cansleep() We can get the following oops from gpio_get_value_cansleep() when a GPIO controller doesn't provide a get() callback: Unable to handle kernel paging request for instruction fetch Faulting instruction address: 0x00000000 Oops: Kernel access of bad area, sig: 11 [#1] [...] NIP [00000000] 0x0 LR [c0182fb0] gpio_get_value_cansleep+0x40/0x50 Call Trace: [c7b79e80] [c0183f28] gpio_value_show+0x5c/0x94 [c7b79ea0] [c01a584c] dev_attr_show+0x30/0x7c [c7b79eb0] [c00d6b48] fill_read_buffer+0x68/0xe0 [c7b79ed0] [c00d6c54] sysfs_read_file+0x94/0xbc [c7b79ef0] [c008f24c] vfs_read+0xb4/0x16c [c7b79f10] [c008f580] sys_read+0x4c/0x90 [c7b79f40] [c0013a14] ret_from_syscall+0x0/0x38 It's OK to request the value of *any* GPIO; most GPIOs are bidirectional, so configuring them as outputs just enables an output driver and doesn't disable the input logic. So the problem is that gpio_get_value_cansleep() isn't making the same sanity check that gpio_get_value() does: making sure this GPIO isn't one of the atypical "no input logic" cases. Reported-by: Anton Vorontsov <avorontsov@ru.mvista.com> Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Cc: <stable@kernel.org> [2.6.27.x, 2.6.26.x, 2.6.25.x] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
e3274e91 |
|
18-Oct-2008 |
Steven A. Falco <sfalco@harris.com> |
gpio: modify sysfs gpio export so that "value" displays as 0 or 1 gpiolib can export GPIOs to userspace via sysfs. This patch modifies the gpio_value_show() so that any non-zero value is explicitly printed as "1", rather than whatever numerical value the lower-level driver returns. Signed-off-by: Steve Falco <sfalco@harris.com> Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
35e8bb51 |
|
15-Oct-2008 |
David Brownell <dbrownell@users.sourceforge.net> |
gpiolib: request/free hooks Add a new internal mechanism to gpiolib to support low power operations by letting gpio_chip instances see when their GPIOs are in use. When no GPIOs are active, chips may be able to enter lower powered runtime states by disabling clocks and/or power domains. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Cc: "Magnus Damm" <magnus.damm@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
0f6d504e |
|
15-Oct-2008 |
David Brownell <dbrownell@users.sourceforge.net> |
gpiolib: gpio_to_irq() hooks Add a new gpiolib mechanism: gpio_chip instances can provide mappings between their (input) GPIOs and any associated IRQs. This makes it easier for platforms to support IRQs that are provided by board-specific external chips instead of as part of their core (such as SOC-integrated GPIOs). Also update the irq_to_gpio() description, saying to avoid it because it's not always supported. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
3d599d1c |
|
15-Oct-2008 |
Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de> |
gpio_free might sleep, generic part According to the documentation gpio_free should only be called from task context only. To make this more explicit add a might sleep to all implementations. This is the generic part which changes gpiolib and the fallback implementation only. Signed-off-by: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de> Cc: David Brownell <david-b@pacbell.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
08678b08 |
|
19-Aug-2008 |
Yinghai Lu <yhlu.kernel@gmail.com> |
generic: sparse irqs: use irq_desc() together with dyn_array, instead of irq_desc[] add CONFIG_HAVE_SPARSE_IRQ to for use condensed array. Get rid of irq_desc[] array assumptions. Preallocate 32 irq_desc, and irq_desc() will try to get more. ( No change in functionality is expected anywhere, except the odd build failure where we missed a code site or where a crossing commit itroduces new irq_desc[] usage. ) v2: according to Eric, change get_irq_desc() to irq_desc() Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
#
d8f388d8 |
|
25-Jul-2008 |
David Brownell <dbrownell@users.sourceforge.net> |
gpio: sysfs interface This adds a simple sysfs interface for GPIOs. /sys/class/gpio /export ... asks the kernel to export a GPIO to userspace /unexport ... to return a GPIO to the kernel /gpioN ... for each exported GPIO #N /value ... always readable, writes fail for input GPIOs /direction ... r/w as: in, out (default low); write high, low /gpiochipN ... for each gpiochip; #N is its first GPIO /base ... (r/o) same as N /label ... (r/o) descriptive, not necessarily unique /ngpio ... (r/o) number of GPIOs; numbered N .. N+(ngpio - 1) GPIOs claimed by kernel code may be exported by its owner using a new gpio_export() call, which should be most useful for driver debugging. Such exports may optionally be done without a "direction" attribute. Userspace may ask to take over a GPIO by writing to a sysfs control file, helping to cope with incomplete board support or other "one-off" requirements that don't merit full kernel support: echo 23 > /sys/class/gpio/export ... will gpio_request(23, "sysfs") and gpio_export(23); use /sys/class/gpio/gpio-23/direction to (re)configure it, when that GPIO can be used as both input and output. echo 23 > /sys/class/gpio/unexport ... will gpio_free(23), when it was exported as above The extra D-space footprint is a few hundred bytes, except for the sysfs resources associated with each exported GPIO. The additional I-space footprint is about two thirds of the current size of gpiolib (!). Since no /dev node creation is involved, no "udev" support is needed. Related changes: * This adds a device pointer to "struct gpio_chip". When GPIO providers initialize that, sysfs gpio class devices become children of that device instead of being "virtual" devices. * The (few) gpio_chip providers which have such a device node have been updated. * Some gpio_chip drivers also needed to update their module "owner" field ... for which missing kerneldoc was added. * Some gpio_chips don't support input GPIOs. Those GPIOs are now flagged appropriately when the chip is registered. Based on previous patches, and discussion both on and off LKML. A Documentation/ABI/testing/sysfs-gpio update is ready to submit once this merges to mainline. [akpm@linux-foundation.org: a few maintenance build fixes] Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Cc: Guennadi Liakhovetski <g.liakhovetski@pengutronix.de> Cc: Greg KH <greg@kroah.com> Cc: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
bff5fda9 |
|
23-May-2008 |
Trent Piepho <xyzzy@speakeasy.org> |
gpiolib: fix off by one errors The last gpio belonging to a chip is chip->base + chip->ngpios - 1. Some places in the code, but not all, forgot the critical minus one. Signed-off-by: Trent Piepho <xyzzy@speakeasy.org> Acked-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
145980a0 |
|
30-Apr-2008 |
Harvey Harrison <harvey.harrison@gmail.com> |
drivers: replace remaining __FUNCTION__ occurrences __FUNCTION__ is gcc-specific, use __func__ Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Cc: Ben Dooks <ben-linux@fluff.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
169b6a7a |
|
28-Apr-2008 |
Anton Vorontsov <avorontsov@ru.mvista.com> |
gpiochip_reserve() Add a new function gpiochip_reserve() to reserve ranges of gpios that platform code has pre-allocated. That is, this marks gpio numbers which will be claimed by drivers that haven't yet been loaded, and thus are not available for dynamic gpio number allocation. [akpm@linux-foundation.org: remove unneeded __must_check] [david-b@pacbell.net: don't export gpiochip_reserve (section fix)] Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com> Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
8d0aab2f |
|
28-Apr-2008 |
Anton Vorontsov <avorontsov@ru.mvista.com> |
gpiolib: dynamic gpio number allocation If gpio_chip->base is negative during registration, gpiolib performs dynamic base allocation. This is useful for devices that aren't always present, such as GPIOs on hotplugged devices rather than mainboards. (This behavior was previously specified but not implemented.) To avoid using any numbers that may have been explicitly assigned but not yet registered, this dynamic allocation assigns GPIO numbers from the biggest number on down, instead of from the smallest on up. Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com> Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
e6de1808 |
|
28-Apr-2008 |
Guennadi Liakhovetski <g.liakhovetski@pengutronix.de> |
gpio: define gpio_is_valid() Introduce a gpio_is_valid() predicate; use it in gpiolib. Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@pengutronix.de> [ use inline function; follow the gpio_* naming convention; work without gpiolib; all programming interfaces need docs ] Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
438d8908 |
|
28-Apr-2008 |
Guennadi Liakhovetski <g.liakhovetski@pengutronix.de> |
gpiolib: better rmmod infrastructure As long as one or more GPIOs on a gpio chip are used its driver should not be unloaded. The existing mechanism (gpiochip_remove failure) doesn't address that, since rmmod can no longer be made to fail by having the cleanup code report errors. Module usecounts are the solution. Assuming standard "initialize struct to zero" policies, this change won't affect SOC platform drivers. However, drivers for external chips (on I2C and SPI busses) should be updated if they can be built as modules. Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@pengutronix.de> [ gpio_ensure_requested() needs to update module usecounts too ] Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
d2876d08 |
|
04-Feb-2008 |
David Brownell <dbrownell@users.sourceforge.net> |
gpiolib: add gpio provider infrastructure Provide new implementation infrastructure that platforms may choose to use when implementing the GPIO programming interface. Platforms can update their GPIO support to use this. In many cases the incremental cost to access a non-inlined GPIO should be less than a dozen instructions, with the memory cost being about a page (total) of extra data and code. The upside is: * Providing two features which were "want to have (but OK to defer)" when GPIO interfaces were first discussed in November 2006: - A "struct gpio_chip" to plug in GPIOs that aren't directly supported by SOC platforms, but come from FPGAs or other multifunction devices using conventional device registers (like UCB-1x00 or SM501 GPIOs, and southbridges in PCs with more open specs than usual). - Full support for message-based GPIO expanders, where registers are accessed through sleeping I/O calls. Previous support for these "cansleep" calls was just stubs. (One example: the widely used pcf8574 I2C chips, with 8 GPIOs each.) * Including a non-stub implementation of the gpio_{request,free}() calls, making those calls much more useful. The diagnostic labels are also recorded given DEBUG_FS, so /sys/kernel/debug/gpio can show a snapshot of all GPIOs known to this infrastructure. The driver programming interfaces introduced in 2.6.21 do not change at all; this infrastructure is entirely below those covers. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Jean Delvare <khali@linux-fr.org> Cc: Eric Miao <eric.miao@marvell.com> Cc: Haavard Skinnemoen <hskinnemoen@atmel.com> Cc: Philipp Zabel <philipp.zabel@gmail.com> Cc: Russell King <rmk@arm.linux.org.uk> Cc: Ben Gardner <bgardner@wabtec.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|