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

["Nuno Sá" <noname.nuno@gmail.com>]

On Mon, 2023-12-04 at 00:03 +0100, Linus Walleij wrote:
> On Fri, Dec 1, 2023 at 4:24 PM Nuno Sá <noname.nuno@gmail.com> 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.
> 

Ohh, I know where my failure was!! I was reading gpiod_direction_output(desc, 1) and
following it only till gpiod_direction_input(desc). I was completely missing the
'set_output_flag' jump... All understood now :)

> 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()
> 

Hmm, by looking into those, it made me think that I should not even need to implement
the .set() callback...
> 

Thanks for all your help!
- Nuno Sá