kernel/linux.git/drivers/pinctrl/core.h, branch v4.17.1

pinctrl/gpio: Unify namespace for cross-calls

2017-09-22T09:02:10+00:00

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

pinctrl: move const qualifier before struct

2017-08-14T13:01:02+00:00

Update subsystem wide for consistency. Signed-off-by: Masahiro Yamada Signed-off-by: Linus Walleij

pinctrl: core: Fix regression caused by delayed work for hogs

2017-01-13T15:25:17+00:00

Commit df61b366af26 ("pinctrl: core: Use delayed work for hogs") caused a regression at least with sh-pfc that is also a GPIO controller as noted by Geert Uytterhoeven . As the original pinctrl_register() has issues calling pin controller driver functions early before the controller has finished registering, we can't just revert commit df61b366af26. That would break the drivers using GENERIC_PINCTRL_GROUPS or GENERIC_PINMUX_FUNCTIONS. So let's fix the issue with the following steps as a single patch: 1. Revert the late_init parts of commit df61b366af26. The late_init clearly won't work and we have to just give up on fixing pinctrl_register() for GENERIC_PINCTRL_GROUPS and GENERIC_PINMUX_FUNCTIONS. 2. Split pinctrl_register() into two parts By splitting pinctrl_register() into pinctrl_init_controller() and pinctrl_create_and_start() we have better control over when it's safe to call pinctrl_create(). 3. Introduce a new pinctrl_register_and_init() function As suggested by Linus Walleij , we can just introduce a new function for the controllers that need pinctrl_create() called later. 4. Convert the four known problem cases to use new function Let's convert pinctrl-imx, pinctrl-single, sh-pfc and ti-iodelay to use the new function to fix the issues. The rest of the drivers can be converted later. Let's also update Documentation/pinctrl.txt accordingly because of the known issues with pinctrl_register(). Fixes: df61b366af26 ("pinctrl: core: Use delayed work for hogs") Reported-by: Geert Uytterhoeven Cc: Gary Bisson Signed-off-by: Tony Lindgren Tested-by: Geert Uytterhoeven Signed-off-by: Linus Walleij

pinctrl: core: Add generic pinctrl functions for managing groups

2017-01-03T08:26:18+00:00

We can add generic helpers for function handling for cases where the pin controller driver does not need to use static arrays. Signed-off-by: Tony Lindgren [Renamed the Kconfig item and moved things around] Signed-off-by: Linus Walleij

pinctrl: stricten up generic group code

2017-01-03T08:26:18+00:00

Rename the symbol PINCTRL_GENERIC to PINCTRL_GENERIC_GROUPS since it all pertains to groups. Replace everywhere. ifdef out the radix tree and the struct when not using the generic groups. Cc: Tony Lindgren Signed-off-by: Linus Walleij

pinctrl: core: Add generic pinctrl functions for managing groups

2017-01-03T08:26:17+00:00

We can add generic helpers for pin group handling for cases where the pin controller driver does not need to use static arrays. Signed-off-by: Tony Lindgren Signed-off-by: Linus Walleij

pinctrl: core: Use delayed work for hogs

2017-01-03T08:26:16+00:00

Having the pin control framework call pin controller functions before it's probe has finished is not nice as the pin controller device driver does not yet have struct pinctrl_dev handle. Let's fix this issue by adding deferred work for late init. This is needed to be able to add pinctrl generic helper functions that expect to know struct pinctrl_dev handle. Note that we now need to call create_pinctrl() directly as we don't want to add the pin controller to the list of controllers until the hogs are claimed. We also need to pass the pinctrl_dev to the device tree parser functions as they otherwise won't find the right controller at this point. Signed-off-by: Tony Lindgren Signed-off-by: Linus Walleij

pinctrl: copy per-pin driver private data to struct pin_desc

2016-05-31T08:27:19+00:00

Currently, struct pinctrl_pin_desc can have per-pin driver private data, but it is not copied to struct pin_desc. For a driver with sparse pin space, for-loop search like below would be necessary in order to get the driver-specific data for a desired pin number. for (i = 0; i < pctldev->desc->npins; i++) if (pin_number == pctldev->desc->pins[i].number) return pctldev->desc->pins[i].drv_data; This is not efficient for a driver with a large number of pins. So, copy the data to struct pin_desc when each pin is registered for the faster radix tree lookup. Signed-off-by: Masahiro Yamada Signed-off-by: Linus Walleij

pinctrl: core: create nolock version of pinctrl_find_gpio_range_from_pin

2016-03-07T03:41:20+00:00

pinctrl_find_gpio_range_from_pin takes the pctldev->mutex but so does pinconf_pins_show and this will cause a deadlock if pinctrl_find_gpio_range_from_pin is used in .pin_config_get callback. Create a nolock version of pinctrl_find_gpio_range_from_pin to allow pin to gpio lookup to be used from pinconf_pins_show. Signed-off-by: Joachim Eastwood Signed-off-by: Linus Walleij

pinctrl: Don't just pretend to protect pinctrl_maps, do it for real

2015-05-06T14:24:28+00:00

Way back, when the world was a simpler place and there was no war, no evil, and no kernel bugs, there was just a single pinctrl lock. That was how the world was when (57291ce pinctrl: core device tree mapping table parsing support) was written. In that case, there were instances where the pinctrl mutex was already held when pinctrl_register_map() was called, hence a "locked" parameter was passed to the function to indicate that the mutex was already locked (so we shouldn't lock it again). A few years ago in (42fed7b pinctrl: move subsystem mutex to pinctrl_dev struct), we switched to a separate pinctrl_maps_mutex. ...but (oops) we forgot to re-think about the whole "locked" parameter for pinctrl_register_map(). Basically the "locked" parameter appears to still refer to whether the bigger pinctrl_dev mutex is locked, but we're using it to skip locks of our (now separate) pinctrl_maps_mutex. That's kind of a bad thing(TM). Probably nobody noticed because most of the calls to pinctrl_register_map happen at boot time and we've got synchronous device probing. ...and even cases where we're asynchronous don't end up actually hitting the race too often. ...but after banging my head against the wall for a bug that reproduced 1 out of 1000 reboots and lots of looking through kgdb, I finally noticed this. Anyway, we can now safely remove the "locked" parameter and go back to a war-free, evil-free, and kernel-bug-free world. Fixes: 42fed7ba44e4 ("pinctrl: move subsystem mutex to pinctrl_dev struct") Signed-off-by: Doug Anderson Signed-off-by: Linus Walleij