- 04 7月, 2016 1 次提交
-
-
由 Johan Hovold 提交于
This reverts commit 923b93e4. 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: NJohan Hovold <johan@kernel.org> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 23 6月, 2016 2 次提交
-
-
由 Linus Walleij 提交于
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: NGrygorii Strashko <grygorii.strashko@ti.com> Reviewed-by: NGrygorii Strashko <grygorii.strashko@ti.com> Acked-by: NAlexandre Courbot <acourbot@nvidia.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
commit 54d77198 ("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: NHans de Goede <hdegoede@redhat.com> Tested-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 18 6月, 2016 2 次提交
-
-
由 Linus Walleij 提交于
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: NGrygorii Strashko <grygorii.strashko@ti.com> Reviewed-by: NGrygorii Strashko <grygorii.strashko@ti.com> Acked-by: NAlexandre Courbot <acourbot@nvidia.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
commit 54d77198 ("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: NHans de Goede <hdegoede@redhat.com> Tested-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 08 6月, 2016 2 次提交
-
-
由 Ricardo Ribalda Delgado 提交于
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: NRicardo Ribalda Delgado <ricardo.ribalda@gmail.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Ricardo Ribalda Delgado 提交于
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: NRicardo Ribalda Delgado <ricardo.ribalda@gmail.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 30 5月, 2016 4 次提交
-
-
由 Linus Walleij 提交于
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: NLaxman Dewangan <ldewangan@nvidia.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
In fdeb8e15 ("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: fdeb8e15 ("gpio: reflect base and ngpio into gpio_device") Reported-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
If we're using the compatible ioctl() we need to handle the argument pointer in a special way or there will be trouble. Fixes: 3c702e99 ("gpio: add a userspace chardev ABI for GPIOs") Reported-by: NDmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: NDmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
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: 72d32000 ("gpio: set up initial state from .get_direction()") Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 02 5月, 2016 1 次提交
-
-
由 Linus Walleij 提交于
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: NGeert Uytterhoeven <geert@linux-m68k.org> Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 30 4月, 2016 1 次提交
-
-
由 Linus Walleij 提交于
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: NLinus Walleij <linus.walleij@linaro.org>
-
- 26 4月, 2016 1 次提交
-
-
由 Linus Walleij 提交于
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: NLinus Walleij <linus.walleij@linaro.org>
-
- 14 4月, 2016 1 次提交
-
-
由 Laxman Dewangan 提交于
Print the error number of GPIO hog failed during its configurations. This helps in identifying the failure without instrumenting the code. Signed-off-by: NLaxman Dewangan <ldewangan@nvidia.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 08 4月, 2016 3 次提交
-
-
由 Guenter Roeck 提交于
Since commit ff2b1359 ("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: ff2b1359 ("gpio: make the gpiochip a real device") Signed-off-by: NGuenter Roeck <linux@roeck-us.net> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Guenter Roeck 提交于
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: NGuenter Roeck <linux@roeck-us.net> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Dmitry Torokhov 提交于
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: NMika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: NDmitry Torokhov <dtor@chromium.org> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 05 4月, 2016 1 次提交
-
-
由 Linus Walleij 提交于
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: NMichael Hennerich <michael.hennerich@analog.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 16 3月, 2016 1 次提交
-
-
由 Geert Uytterhoeven 提交于
Fixes: 79a9becd ("gpiolib: export descriptor-based GPIO interface") Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 07 3月, 2016 1 次提交
-
-
由 Bamvor Jian Zhang 提交于
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 ef7c7553 ("gpiolib: improve overlap check of range of gpio"). 2. Commit 96098df1 ("gpiolib: fix chip order in gpio list") Warning: 1. Commit e28ecca6 ("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.htmlSuggested-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NBamvor Jian Zhang <bamvor.zhangjian@linaro.org> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 26 2月, 2016 1 次提交
-
-
由 Linus Walleij 提交于
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: NLinus Walleij <linus.walleij@linaro.org>
-
- 23 2月, 2016 1 次提交
-
-
由 Laxman Dewangan 提交于
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: NLaxman Dewangan <ldewangan@nvidia.com>
-
- 22 2月, 2016 1 次提交
-
-
由 Linus Walleij 提交于
This fixes the wrongly indicated lines in the userspace ABI: test for the right BITS, do not treat bit numbers as bitmasks. Reported-by: NMarkus Pargmann <mpa@pengutronix.de> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 20 2月, 2016 1 次提交
-
-
由 Bamvor Jian Zhang 提交于
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: NBamvor Jian Zhang <bamvor.zhangjian@linaro.org> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 19 2月, 2016 3 次提交
-
-
由 Linus Walleij 提交于
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: NMichael Welling <mwelling@ieee.org> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
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: NLinus Walleij <linus.walleij@linaro.org>
-
由 Josh Cartwright 提交于
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: NGeert Uytterhoeven <geert+renesas@glider.be> Reported-by: NMichael Welling <mwelling@ieee.org> Reported-by: NTony Lindgren <tony@atomide.com> Tested-by: NMichael Welling <mwelling@ieee.org> Tested-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NJosh Cartwright <joshc@ni.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 16 2月, 2016 3 次提交
-
-
由 Linus Walleij 提交于
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: NStephen Rothwell <sfr@canb.auug.org.au> Cc: Nicolas Saenz Julienne <nicolassaenzj@gmail.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
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: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
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: NLinus Walleij <linus.walleij@linaro.org>
-
- 12 2月, 2016 6 次提交
-
-
由 Linus Walleij 提交于
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: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
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: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
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: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
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: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
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: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
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: NLinus Walleij <linus.walleij@linaro.org>
-
- 09 2月, 2016 3 次提交
-
-
由 Linus Walleij 提交于
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: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
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: NLinus Walleij <linus.walleij@linaro.org>
-
由 Linus Walleij 提交于
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: NLinus Walleij <linus.walleij@linaro.org>
-