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 Thu, Nov 30, 2023 at 4:20 PM Nuno Sá <noname.nuno@xxxxxxxxx> wrote:

> Well, I did spent some time on the gpio thing so I would like to have it in but yeah,
> no hard feelings if it does not go in.

I think it's a good idea to include it, especially if you can, in the
commit message,
illustrate how you test it with the libgpiod toolset. If you can test it all the
way such that you have real hardware connected to real electronics where
you can observe the values on these pins or read them: even better.

GPIOs tend to get used, and then we are prepared.

> So, I actually talk with some hw guys and the pull_low is not really like a pull_low
> resistor.

We usually call it pull down, so the PIN_CONFIG_BIAS_PULL_DOWN
config property.

This is vital to e.g. create a bit-banged I2C link, which is something I
suspect could be useful on this hardware.

>These pins are effectively an open drain. Which means, setting them as
> input means setting them in high-z (turning off the mosffet) - and I do have a bug in
> my code regarding this -

The gpiolib framework assumes we can do open drain emulation by
setting lines as input. It is used as fallback unless the hardware has
an explicit open drain setting.

> Or if you want them as outputs you can set the level low
> (and it will always be low - just turn on the mosffet) or you can also set high-z
> which means it will be either low or high depending on your external circuitry. The
> point is, you can still have your pin acting as a normal gpo if you accommodate your
> circuitry for it (can also use these pins for things like buses).

Yeah that is just standard open drain behaviour, by the book.
Also documented in
https://docs.kernel.org/driver-api/gpio/driver.html
under the heading "GPIO lines with open drain/source support".

> Also got me thinking if a gpi vs gpo devicetree property would make sense. But I
> would likely leave it more generic/relaxed for now (even though I think you would
> need to be creative and actually use more HW to have the possibility of using these
> pins as GPIs and GPOs at the same time).

We don't define that in the device tree currently, we just make the driver
not support output on input-only pins and vice versa, by returning error
codes on the .set_direction() callbacks.

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