Felipe Balbi <balbi@xxxxxx> writes:
>> nop->gpiod_reset = devm_gpiod_get_optional(dev, "reset");
>> if (gpiod_is_active_low(nop->gpiod_reset))
>> gpiod_direction_output(nop->gpiod_reset, GPIOD_OUT_LOW);
>> else
>> gpiod_direction_output(nop->gpiod_reset, GPIOD_OUT_HIGH);
>
> won't the descriptor itself handle that for us ? Linus ?
>
> I want to hear from Linus W first.
Yes, so do I.
Let's add a bit of context for Linus :
1) In the past, the driver was doing a ;
gpio_request_one()
-> gpiod_direction_output_raw()
2) After the conversion to gpio descriptors, it is doing :
gpiod_get_optional(dev, "reset");
-> ...
-> __gpiod_get_index(dev, "reset", 0, 0)
-> this of course doesn't call gpiod_direction()
The problem is that we cannot call:
gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW);
because we don't know before the call if the GPIO is active high or low. The
former gpio_request_one() was clever and did a gpio_direction_output_raw(..,
(flags & GPIOF_INIT_HIGH) ? 1 : 0).
So what is the right way out ? :
- is it to call gpiod_direction_output(nop->gpiod, 0) just after
gpiod_get_optional() in probe code ?
- is it when the gpio is used to call gpiod_direction_output(gpiod, x) instead
of gpiod_set_value() ?
- is it something else ?
Cheers.
--
Robert
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
