Re: [PATCH v2 2/2] hwmon: ltc4282: add support for the LTC4282 chip

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Dec 1, 2023 at 4:24 PM Nuno Sá <noname.nuno@xxxxxxxxx> wrote:

> > If a pins .direction_output() fails, .set_value() will not be called
> > on it either.
>
> This is where I lost you :(

devm_gpiod_get() (and similar interfaces) will set up the default mode for
the line, as input or output (with value, calling .direction_output) so most
likely it will fail already there, and the driver will not probe or
userspace client
will fail.

> So, I'm might be overcomplicating things but... Again,
> the case where someone wired up HW so that we can actually use the pin to drive the
> line high (having an external pull up). In that case, If I return error, then I won't
> be able to effectively set the line high (as you said, set_value will not be called
> on it either).
>
> Now, I do understand that if we have the line flagged as GPIO_OPEN_DRAIN, then
> gpiolib will switch the line to input which means we will set the line in high-z
> which means that if we have a pull up, then the line will be high. I mean, it works
> but it would be strange if someone wants to have the line as output high and after
> trying to set the it high, it sees the pin moving to input. But if this is how it
> should be, fine by me.

What do you mean by "sees the pin moving to input".

If you mean electrically then yes, it goes to high-Z.

If you mean logically, as seen by software and GPIO and debugfs, not
really.

I think a good exercise to see how it works is to just walk through the
code in drivers/gpio/gpiolib.c for e.g.
gpiod_set_value()
gpiod_set_value_nocheck()
gpio_set_open_drain_value_commit()

>direction_input() is indeed called, but that is just a way of using the
hardware, logically, inside gpiolib, the line is handled as high.

> Yes, that is the only thing we have. Meaning that there is no hw setting to set the
> pins to open drain. Open drain is what they are. That is why I'm not seeing the point
> in having PIN_CONFIG_DRIVE_OPEN_DRAIN implemented.

For satisfying the logic. We have several cases where callbacks are
just returning a 0 error code for such corner cases, and as Andy points
out push-pull requests should return an error.

Yours,
Linus Walleij





[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux