user/sven/linux.git/include/linux/gpio/driver.h, branch v6.16.3

gpio: Switch to irq_domain_create_*()

2025-05-16T19:06:09Z

irq_domain_add_*() interfaces are going away as being obsolete now. Switch to the preferred irq_domain_create_*() ones. Those differ in the node parameter: They take more generic struct fwnode_handle instead of struct device_node. Therefore, of_fwnode_handle() is added around the original parameter. Note some of the users can likely use dev->fwnode directly instead of indirect of_fwnode_handle(dev->of_node). But dev->fwnode is not guaranteed to be set for all, so this has to be investigated on case to case basis (by people who can actually test with the HW). [ tglx: Fix up subject prefix ] Signed-off-by: Jiri Slaby (SUSE) Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/all/20250319092951.37667-18-jirislaby@kernel.org

gpiolib: fix kerneldoc

2025-03-06T08:25:06Z

Add missing '@' to the kernel doc for the new of_node_instance_match field of struct gpio_chip. Fixes: bd3ce71078bd ("gpiolib: of: Handle threecell GPIO chips") Reported-by: Stephen Rothwell Closes: https://lore.kernel.org/all/20250305203929.70283b9b@canb.auug.org.au/ Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20250305094939.40011-1-brgl@bgdev.pl Signed-off-by: Bartosz Golaszewski

gpio: Hide valid_mask from direct assignments

2025-03-05T13:36:04Z

The valid_mask member of the struct gpio_chip is unconditionally written by the GPIO core at driver registration. Current documentation does not mention this but just says the valid_mask is used if it's not NULL. This lured me to try populating it directly in the GPIO driver probe instead of using the init_valid_mask() callback. It took some retries with different bitmaps and eventually a bit of code-reading to understand why the valid_mask was not obeyed. I could've avoided this trial and error if the valid_mask was hidden in the struct gpio_device instead of being a visible member of the struct gpio_chip. Help the next developer who decides to directly populate the valid_mask in struct gpio_chip by hiding the valid_mask in struct gpio_device and keep it internal to the GPIO core. Suggested-by: Linus Walleij Signed-off-by: Matti Vaittinen Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/4547ca90d910d60cab3d56d864d59ddde47a5e93.1741180097.git.mazziesaccount@gmail.com Signed-off-by: Bartosz Golaszewski

gpio: Add a valid_mask getter

2025-03-05T13:36:04Z

The valid_mask member of the struct gpio_chip is unconditionally written by the GPIO core at driver registration. It shouldn't be directly populated by drivers. This can be prevented by moving it from the struct gpio_chip to struct gpio_device, which is internal to the GPIO core. As a preparatory step, provide a getter function which can be used by those drivers which need the valid_mask information. Signed-off-by: Matti Vaittinen Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/026f9d78502eca883bfe3faeb684e23d5d6c5e84.1741180097.git.mazziesaccount@gmail.com Signed-off-by: Bartosz Golaszewski

gpiolib: of: Handle threecell GPIO chips

2025-03-04T10:29:04Z

When describing GPIO controllers in the device tree, the ambition of device tree to describe the hardware may require a three-cell scheme: gpios = <&gpio instance offset flags>; This implements support for this scheme in the gpiolib OF core. Drivers that want to handle multiple gpiochip instances from one OF node need to implement a callback similar to this to determine if a certain gpio chip is a pointer to the right instance (pseudo-code): struct my_gpio { struct gpio_chip gcs[MAX_CHIPS]; }; static bool my_of_node_instance_match(struct gpio_chip *gc unsigned int instance) { struct my_gpio *mg = gpiochip_get_data(gc); if (instance >= MAX_CHIPS) return false; return (gc == &mg->gcs[instance]); } probe() { struct my_gpio *mg; struct gpio_chip *gc; int i, ret; for (i = 0; i++; i < MAX_CHIPS) { gc = &mg->gcs[i]; /* This tells gpiolib we have several instances per node */ gc->of_gpio_n_cells = 3; gc->of_node_instance_match = my_of_node_instance_match; gc->base = -1; ... ret = devm_gpiochip_add_data(dev, gc, mg); if (ret) return ret; } } Rename the "simple" of_xlate function to "twocell" which is closer to what it actually does. In the device tree bindings, the provide node needs to specify #gpio-cells = <3>; where the first cell is the instance number: gpios = <&gpio instance offset flags>; Conversely ranges need to have four cells: gpio-ranges = <&pinctrl instance gpio_offset pin_offset count>; Reviewed-by: Alex Elder Tested-by: Yixun Lan Signed-off-by: Linus Walleij Reviewed-by: Rob Herring (Arm) Link: https://lore.kernel.org/r/20250225-gpio-ranges-fourcell-v3-2-860382ba4713@linaro.org Signed-off-by: Bartosz Golaszewski

gpiolib: deprecate gpio_chip::set and gpio_chip::set_multiple

2025-03-03T08:34:34Z

We now have setter callbacks that allow us to indicate success or failure using the integer return value. Deprecate the older callbacks so that no new code is tempted to use them. Link: https://lore.kernel.org/r/20250227083748.22400-1-brgl@bgdev.pl Signed-off-by: Bartosz Golaszewski

gpiolib: introduce gpio_chip setters that return values

2025-02-26T10:17:39Z

Add new variants of the set() and set_multiple() callbacks that have integer return values allowing to indicate failures to users of the GPIO consumer API. Until we convert all GPIO providers treewide to using them, they will live in parallel to the existing ones. Make sure that providers cannot define both. Prefer the new ones and only use the old ones as fallback. Reviewed-by: Linus Walleij Acked-by: Uwe Kleine-König Link: https://lore.kernel.org/r/20250220-gpio-set-retval-v2-5-bc4cfd38dae3@linaro.org Signed-off-by: Bartosz Golaszewski

gpio: mmio: Add flag for calling pinctrl back-end

2025-02-24T19:49:20Z

It turns out that with this flag we can switch over an entire driver to use gpio-mmio instead of a bunch of custom code, also providing get/set_multiple() to it in the process, so it seems like a reasonable feature to add. The generic pin control backend requires us to call the gpiochip_generic_request(), gpiochip_generic_free(), pinctrl_gpio_direction_output() and pinctrl_gpio_direction_input() callbacks, so if the new flag for a pin control back-end is set, we make sure these functions get called as expected. Signed-off-by: Linus Walleij Link: https://lore.kernel.org/r/20250219-vf610-mmio-v3-1-588b64f0b689@linaro.org Signed-off-by: Bartosz Golaszewski

gpiolib: sanitize the return value of gpio_chip::set_config()

2025-02-24T08:58:58Z

The return value of the set_config() callback may be propagated to user-space. If a bad driver returns a positive number, it may confuse user programs. Tighten the API contract and check for positive numbers returned by GPIO controllers. Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20250210-gpio-sanitize-retvals-v1-3-12ea88506cb2@linaro.org Signed-off-by: Bartosz Golaszewski

gpiolib: sanitize the return value of gpio_chip::request()

2025-02-24T08:58:58Z

The return value of the request() callback may be propagated to user-space. If a bad driver returns a positive number, it may confuse user programs. Tighten the API contract and check for positive numbers returned by GPIO controllers. Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20250210-gpio-sanitize-retvals-v1-2-12ea88506cb2@linaro.org Signed-off-by: Bartosz Golaszewski