Message ID | 20220415070710.220785-1-andrei.lalaev@emlid.com |
---|---|
State | Accepted |
Commit | e75f88efac05bf4e107e4171d8db6d8c3937252d |
Headers | show |
Series | [v2] gpiolib: of: fix bounds check for 'gpio-reserved-ranges' | expand |
On Fri, Apr 15, 2022 at 9:09 AM Andrei Lalaev <andrei.lalaev@emlid.com> wrote: > Gpiolib interprets the elements of "gpio-reserved-ranges" as "start,size" > because it clears "size" bits starting from the "start" bit in the according > bitmap. So it has to use "greater" instead of "greater or equal" when performs > bounds check to make sure that GPIOs are in the available range. > Previous implementation skipped ranges that include the last GPIO in > the range. > > Fixes: 726cb3ba4969 ("gpiolib: Support 'gpio-reserved-ranges' property") > Signed-off-by: Andrei Lalaev <andrei.lalaev@emlid.com> Nice patch! Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Yours, Linus Walleij
On Fri, Apr 15, 2022 at 9:09 AM Andrei Lalaev <andrei.lalaev@emlid.com> wrote: > > Gpiolib interprets the elements of "gpio-reserved-ranges" as "start,size" > because it clears "size" bits starting from the "start" bit in the according > bitmap. So it has to use "greater" instead of "greater or equal" when performs > bounds check to make sure that GPIOs are in the available range. > Previous implementation skipped ranges that include the last GPIO in > the range. > > Fixes: 726cb3ba4969 ("gpiolib: Support 'gpio-reserved-ranges' property") > Signed-off-by: Andrei Lalaev <andrei.lalaev@emlid.com> > --- > I wrote the mail to the maintainers > (https://lore.kernel.org/linux-gpio/20220412115554.159435-1-andrei.lalaev@emlid.com/T/#u) > of the questioned DTSes (because I couldn't understand how the maintainers > interpreted this property), but I haven't received a response. > Since the questioned DTSes use "gpio-reserved-ranges = <0 4>" > (i.e., the beginning of the range), this patch doesn't affect these DTSes at all. > TBH this patch doesn't break any existing DTSes because none of them > reserve gpios at the end of range. > --- Queued for fixes and Cc'ed stable, thanks! I also added the part below the tags to the commit message as it's important so I don't want to drop it from history. Bart > drivers/gpio/gpiolib-of.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c > index ae1ce319cd78..7e5e51d49d09 100644 > --- a/drivers/gpio/gpiolib-of.c > +++ b/drivers/gpio/gpiolib-of.c > @@ -910,7 +910,7 @@ static void of_gpiochip_init_valid_mask(struct gpio_chip *chip) > i, &start); > of_property_read_u32_index(np, "gpio-reserved-ranges", > i + 1, &count); > - if (start >= chip->ngpio || start + count >= chip->ngpio) > + if (start >= chip->ngpio || start + count > chip->ngpio) > continue; > > bitmap_clear(chip->valid_mask, start, count); > -- > 2.25.1 >
diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c index ae1ce319cd78..7e5e51d49d09 100644 --- a/drivers/gpio/gpiolib-of.c +++ b/drivers/gpio/gpiolib-of.c @@ -910,7 +910,7 @@ static void of_gpiochip_init_valid_mask(struct gpio_chip *chip) i, &start); of_property_read_u32_index(np, "gpio-reserved-ranges", i + 1, &count); - if (start >= chip->ngpio || start + count >= chip->ngpio) + if (start >= chip->ngpio || start + count > chip->ngpio) continue; bitmap_clear(chip->valid_mask, start, count);
Gpiolib interprets the elements of "gpio-reserved-ranges" as "start,size" because it clears "size" bits starting from the "start" bit in the according bitmap. So it has to use "greater" instead of "greater or equal" when performs bounds check to make sure that GPIOs are in the available range. Previous implementation skipped ranges that include the last GPIO in the range. Fixes: 726cb3ba4969 ("gpiolib: Support 'gpio-reserved-ranges' property") Signed-off-by: Andrei Lalaev <andrei.lalaev@emlid.com> --- I wrote the mail to the maintainers (https://lore.kernel.org/linux-gpio/20220412115554.159435-1-andrei.lalaev@emlid.com/T/#u) of the questioned DTSes (because I couldn't understand how the maintainers interpreted this property), but I haven't received a response. Since the questioned DTSes use "gpio-reserved-ranges = <0 4>" (i.e., the beginning of the range), this patch doesn't affect these DTSes at all. TBH this patch doesn't break any existing DTSes because none of them reserve gpios at the end of range. --- drivers/gpio/gpiolib-of.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)