Fabio Estevam <[email protected]> writes: > Since the "power" GPIO is mapped as active-low, its actual signal will be 0 > after this code. Contrary to the legacy integer GPIO interface, the active-low > property is handled during mapping and is thus transparent to GPIO consumers." > > ,which is exactly what we want in the gpio reset case: we want it to > output in its active level first. I didn't know that.
> So your patch should do like this: > > + if (nop->gpiod_reset) > + gpiod_direction_output(nop->gpiod_reset, 1); > > This will guarantee that we keep the same behaviour as we had prior to > the introduction of gpiod. That's true, the GPIOF_OUT_INIT_LOW/HIGH in the former code just struck me. > I plan to submit a separate fix on top of yours that puts the delay in > the correct position. > > This separate issue exists even prior to the gpiod api inclusion. > > What we need to do: > > - Force the GPIO in its active reset level state I will take care of that, as it's a regression introduced by my patch. > - Wait a bit > - Put the GPIO out of reset. Ah, that one will be for you :) > ,but I can handle this one after your patch gets applied. OK, let's do that. Cheers. -- Robert -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
