An error occurred fetching the project authors.
- 06 Dec, 2021 2 commits
-
-
Bartosz Golaszewski authored
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>
-
Bartosz Golaszewski authored
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>
-
- 03 Dec, 2021 1 commit
-
-
Geert Uytterhoeven authored
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>
-
- 26 Oct, 2021 1 commit
-
-
Marc Zyngier authored
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 aebdc8ab 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.comSigned-off-by:
Linus Walleij <linus.walleij@linaro.org>
-
- 29 Jul, 2021 1 commit
-
-
Sergio Paracuellos authored
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>
-
- 28 May, 2021 2 commits
-
-
Andy Shevchenko authored
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>
-
Andy Shevchenko authored
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>
-
- 12 May, 2021 1 commit
-
-
Andy Shevchenko authored
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>
-
- 26 Mar, 2021 5 commits
-
-
Andy Shevchenko authored
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>
-
Andy Shevchenko authored
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>
-
Andy Shevchenko authored
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>
-
Andy Shevchenko authored
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>
-
Andy Shevchenko authored
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>
-
- 16 Mar, 2021 1 commit
-
-
Andy Shevchenko authored
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: 7cba1a4d ("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>
-
- 12 Mar, 2021 1 commit
-
-
Wei Yongjun authored
Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: 4731210c ("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>
-
- 08 Mar, 2021 3 commits
-
-
Andy Shevchenko authored
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: 7cba1a4d ("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>
-
Johan Hovold authored
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: ff2b1359 ("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>
-
Johan Hovold authored
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: 4731210c ("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>
-
- 09 Feb, 2021 1 commit
-
-
Saravana Kannan authored
Dmitry reported[1] boot error messages caused by commit 4731210c ("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: 4731210c ("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.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 01 Feb, 2021 1 commit
-
-
Wolfram Sang authored
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: d377f56f ("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>
-
- 29 Jan, 2021 1 commit
-
-
Quanyang Wang authored
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>
-
- 27 Jan, 2021 1 commit
-
-
Saravana Kannan authored
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: e5904747 ("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.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 19 Jan, 2021 1 commit
-
-
Nikita Shubin authored
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: e0d89728 ("gpio: Implement tighter IRQ chip integration") Signed-off-by:
Nikita Shubin <nikita.shubin@maquefel.me> Signed-off-by:
Bartosz Golaszewski <bgolaszewski@baylibre.com>
-
- 05 Jan, 2021 1 commit
-
-
Andy Shevchenko authored
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>
-
- 11 Dec, 2020 1 commit
-
-
Nikita Shubin authored
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: a8173820 ("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.meSigned-off-by:
Linus Walleij <linus.walleij@linaro.org>
-
- 05 Dec, 2020 1 commit
-
-
Enrico Weigelt authored
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.netSigned-off-by:
Linus Walleij <linus.walleij@linaro.org>
-
- 02 Dec, 2020 1 commit
-
-
Edmond Chung authored
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: 2ab73c6d ("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>
-
- 01 Dec, 2020 1 commit
-
-
Grygorii Strashko authored
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>
-
- 16 Nov, 2020 7 commits
-
-
Andy Shevchenko authored
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>
-
Andy Shevchenko authored
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>
-
Andy Shevchenko authored
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>
-
Andy Shevchenko authored
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>
-
Andy Shevchenko authored
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>
-
Andy Shevchenko authored
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>
-
Andy Shevchenko authored
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>
-
- 05 Nov, 2020 1 commit
-
-
Kent Gibson authored
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: d143493c (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>
-
- 28 Oct, 2020 2 commits
-
-
Linus Walleij authored
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
-
Andy Shevchenko authored
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.comSigned-off-by:
Linus Walleij <linus.walleij@linaro.org>
-
- 26 Oct, 2020 2 commits
-
-
Andy Shevchenko authored
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>
-
Andy Shevchenko authored
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>
-