Hi Miquel,

On Wed, Feb 01, 2023 at 09:33:32AM +0100, Miquel Raynal wrote:

Hi Dmitry,

dmitry.torokhov@gmail.com wrote on Tue, 31 Jan 2023 16:50:07 -0800:

quoted

On Tue, Jan 31, 2023 at 3:52 PM Dmitry Torokhov
[off-list ref] wrote:

quoted

Hi Arnd,

On Thu, Jan 26, 2023 at 8:32 AM Arnd Bergmann [off-list ref] wrote:  

quoted

        /* 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