mbox series

[0/2] Add support for LTC4282

Message ID 20231110151905.1659873-1-nuno.sa@analog.com (mailing list archive)
Headers show
Series Add support for LTC4282 | expand

Message

Nuno Sa Nov. 10, 2023, 3:18 p.m. UTC
Hi all,

The LTC4282 hot swap controller allows a board to be safely inserted and
removed from a live backplane. Using one or more external N-channel pass
transistors, board supply voltage and inrush current are ramped up at an
adjustable rate. An I2C interface and onboard ADC allows for monitoring
of board current, voltage, power, energy and fault status.

I'm aware that there are ABI in the driver that will surely raise questions.
So, I'll try to add some comments about those:

- For the fault_log stuff please see the comment in the code. There might be
some scenarios where one might really want to latch off the device until a
fault is manually cleared.
- I also see value in the FET interfaces as they are real faults but maybe
the naming is poor.
- I'm not so sure about the power1_good and the power1_fault_log. The
power1_good is more of a real status bit. If the bit is 0, it does not
necessarily means that there's something wrong. If someone removed
(on purpose) the "load", then this will be 0 and there's nothing wrong.
The fault_log is also not one of those bits that will keep the device to
latch on again. However, they might really indicate some misbehave. But,
OTOH (again :)), maybe the GPIO support for this is enough...
- There's also the handling for the overflow bits. I don't think it makes
much sense to export those so I tried to be clever and automatically handle
it the driver. The power_average is the thing making the whole thing more
complicated. If it was only the energy, we could defer it completely to
userspace...
- And there's also the rsense as a mandatory property. Designs like this
completely depend on the calculated rsense so I have no idea (and if it
makes sense) what default should I use if the property is not given.

I'm also cc'ing the GPIO folks for the GPIO bits. And I'm also not so sure
about it. I'm just treating the pins as if I can set value + direction. However,
the only thing that we can do is to PULL_LOW and set the pins in HIGH_Z. So,
I dunno I'm doing the right thing. I wonder if I should just give the ability
to configure the pins through FW with the .set_config hook and then just
allow to read the pin level? The GPIO1 is also odd since is only the one
that directly allows you to control the direction but then, again, you
can just pull it low or high-z.

One last comment is about lines length. I know some maintainer still want
the 80 col limit but since I'm not so sure on the policy in hwmon I just
went for 100. I'm pretty sure I'll need more iterations to get the driver
in, so I'm happy to change it to 80 if required.

Nuno Sa (2):
  dt-bindings: hwmon: Add LTC4282 bindings
  hwmon: ltc4282: add support for the LTC4282 chip

 .../bindings/hwmon/adi,ltc4282.yaml           |  228 +++
 Documentation/hwmon/ltc4282.rst               |  101 ++
 MAINTAINERS                                   |    8 +
 drivers/hwmon/Kconfig                         |   11 +
 drivers/hwmon/Makefile                        |    1 +
 drivers/hwmon/ltc4282.c                       | 1518 +++++++++++++++++
 6 files changed, 1867 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/adi,ltc4282.yaml
 create mode 100644 Documentation/hwmon/ltc4282.rst
 create mode 100644 drivers/hwmon/ltc4282.c