@@ -2326,6 +2326,10 @@ static int gpiod_request_commit(struct gpio_desc *desc, const char *label)
if (!guard.gc)
return -ENODEV;
+ offset = gpio_chip_hwgpio(desc);
+ if (!gpiochip_line_is_valid(guard.gc, offset))
+ return -EINVAL;
+
if (test_and_set_bit(FLAG_REQUESTED, &desc->flags))
return -EBUSY;
@@ -2334,11 +2338,7 @@ static int gpiod_request_commit(struct gpio_desc *desc, const char *label)
*/
if (guard.gc->request) {
- offset = gpio_chip_hwgpio(desc);
- if (gpiochip_line_is_valid(guard.gc, offset))
- ret = guard.gc->request(guard.gc, offset);
- else
- ret = -EINVAL;
+ ret = guard.gc->request(guard.gc, offset);
if (ret)
goto out_clear_bit;
}
When GPIOs were requested the validity of GPIOs were checked only when the GPIO-chip had the request -callback populated. This made using masked GPIOs possible. The GPIO chip driver authors may find it difficult to understand the relation of enforsing the GPIO validity and the 'request' -callback because the current documentation for the 'request' callback does not mention this. It only states: * @request: optional hook for chip-specific activation, such as * enabling module power and clock; may sleep The validity of the GPIO line should be checked whether the driver provides the 'request' callback or not. Unconditionally check the GPIO validity when GPIO is being requested. Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> --- Revision history: v1 => v2: - New patch (born as a spin-off from the discussion to v1: https://lore.kernel.org/all/Z71qphikHPGB0Yuv@mva-rohm/ I'm not sure if this warrants a Fixes -tag. --- drivers/gpio/gpiolib.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)