Hi Robert, On Fri, Jan 30, 2015 at 6:02 AM, Robert Jarzmik <robert.jarzmik@xxxxxxx> wrote: > Fabio Estevam <festevam@xxxxxxxxx> writes: > >> Why do you set it to zero independently of the GPIO active level flag? > I don't. > > Please have a look at gpiod_direction_output() first, especially : > if (test_bit(FLAG_ACTIVE_LOW, &desc->flags)) Let's look at Documentation/gpio/board.txt: " gpiod_direction_output(power, 1); 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. 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. 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 - Wait a bit - Put the GPIO out of reset. What the driver does today is: - Force the GPIO in its active reset level state - Put the GPIO out of reset. - Wait a bit ,but I can handle this one after your patch gets applied. Thanks -- 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
