On 9/23/24 21:17, Chanh Nguyen wrote:
On 24/09/2024 04:23, Conor Dooley wrote:
On Mon, Sep 23, 2024 at 09:38:00AM +0000, Chanh Nguyen wrote:
The adt7462 supports monitoring and controlling up to
four PWM Fan drive outputs and eight TACH inputs measures.
The adt7462 supports reading a single on chip temperature
sensor and three remote temperature sensors. There are up
to 13 voltage monitoring inputs.
Add device tree bindings for the adt7462 device.
Signed-off-by: Chanh Nguyen <chanh@xxxxxxxxxxxxxxxxxxxxxx>
---
Change in v2:
- Add onnn,adt7462 to the list of trivial devices [Guenter]
Is this really a trivial device? If it monitors and controls fans, how
come those do not need to be represented in the devicetree? How is it
possible to tell the difference between monitoring 1 and 4 fans without
the extra detail?
Hi Conor, Thank you for your comments!
The chip is old. The driver was added back in 2008.
Really, this is such an old chip that it would make more sense to just leave its driver alone unless there is a problem with it; this is viewpoint from Guenter.
I'm using the driver and the device tree with only the "compatible" and "reg" properties; now it's being good for me without any extra detail.
Guenter, Rob, Krzysztof, and I discussed making the decision to add this device to the list of trivial devices. You can get more information at thread https://lore.kernel.org/lkml/20240918220553.GA2216504-robh@xxxxxxxxxx/T/ (Because the commit title changed between v1 and v2, it's so hard for everyone to find it. Sorry! I missed mentioning the link to pacth v1).
Guenter, who supported the driver development before, he suggested me add this device to the list of trivial devices.
Historically it was ok to add an entry into trivial devices and extending
it later if/when needed. That was still widely done at least until very
recently. Maybe that changed recently. If so, sorry for bringing up the idea.
I did not envision that this might be a problem.
Can you live with no devicetree entry at all for the chip ? That is of
course less than perfect, but it seems better than trying to design a
devicetree description for the chip only to never implement it.
Thanks,
Guenter
