CC: Geert (because, I think he was asked about the Rcar GPIO check before).
On 28/02/2025 10:23, Linus Walleij wrote:
On Thu, Feb 27, 2025 at 9:24 AM Matti Vaittinen
<mazziesaccount@xxxxxxxxx> wrote:
> >> I did some quick testing. I used:
(...)
which left GPIO0 ... GPIO6 masked (pins used for ADC) and only GPIO7
unmasked.
Then I added:
gpiotst {
compatible = "rohm,foo-bd72720-gpio";
rohm,dvs-vsel-gpios = <&adc 5 0>, <&adc 6 0>;
};
and a dummy driver which does:
gpio_array = devm_gpiod_get_array(&pdev->dev, "rohm,dvs-vsel",
GPIOD_OUT_LOW);
...
ret = gpiod_set_array_value_cansleep(gpio_array->ndescs,
gpio_array->desc, gpio_array->info, values);
As a result the bd79124 gpio driver got it's set_multiple called with
masked pins. (Oh, and I had accidentally prepared to handle this as I
had added a sanity check for pinmux register in the set_multiple()).
But... how did you mask of the pins 0..5 in valid_mask in this
example?
If this is device tree, I would expect that at least you set up
gpio-reserved-ranges = <0 5>; which will initialize the valid_mask.
You still need to tell the gpiolib that they are taken for other
purposes somehow.
I think devm_gpiod_get_array() should have failed in that case.
The call graph should look like this:
devm_gpiod_get_array()
gpiod_get_array()
gpiod_get_index(0...n)
gpiod_find_and_request()
gpiod_request()
gpiod_request_commit()
Here in my setup the guard.gc->request == NULL. Thus the code never goes
to the branch with the validation. And just before you ask me why the
guard.gc->request is NULL - what do you call a blind bambi? :)
- No idea.
gpiochip_line_is_valid()
Eg, This is never called.
Yours,
-- Matti
