Hi Miquel, On Wed, Feb 01, 2023 at 09:33:32AM +0100, Miquel Raynal wrote: > Hi Dmitry, > > dmitry.torokhov@xxxxxxxxx wrote on Tue, 31 Jan 2023 16:50:07 -0800: > > > On Tue, Jan 31, 2023 at 3:52 PM Dmitry Torokhov > > <dmitry.torokhov@xxxxxxxxx> wrote: > > > > > > Hi Arnd, > > > > > > On Thu, Jan 26, 2023 at 8:32 AM Arnd Bergmann <arnd@xxxxxxxxxx> wrote: > > > > > > > > /* Reset */ > > > > - if (gpio_is_valid(rstn)) { > > > > + if (rstn) { > > > > udelay(1); > > > > - gpio_set_value_cansleep(rstn, 0); > > > > + gpiod_set_value_cansleep(rstn, 0); > > > > udelay(1); > > > > - gpio_set_value_cansleep(rstn, 1); > > > > + gpiod_set_value_cansleep(rstn, 1); > > > > > > For gpiod conversions, if we are not willing to chase whether existing > > > DTSes specify polarities > > > properly and create workarounds in case they are wrong, we should use > > > gpiod_set_raw_value*() > > > (my preference would be to do the work and not use "raw" variants). > > > > > > In this particular case, arch/arm/boot/dts/vf610-zii-dev-rev-c.dts > > > defines reset line as active low, > > > so you are leaving the device in reset state. > > You mean the semantics of gpio_set_value() gpiod_set_value() are > different? Looking at your patch it looks like gpio_set_value() asserts > a physical line state (high or low) while gpiod_set_value() would > actually try to assert a logical state (enabled or disabled) with the > meaning of those being possibly inverted thanks to the DT polarities. > Am I getting this right? Right. If one wants to do physical levels, they need to use gpiod "raw" APIs. Thanks. -- Dmitry