Hi I understand the issue of the first come first grab but when I attempted to add this to the hwmon you insisted that that was not the correct place and to create a watchdog module so if both can not be loaded then would it have not been better to add it to the hwmon like some of the other chips. David -----Original Message----- From: Guenter Roeck <groeck7@xxxxxxxxx> On Behalf Of Guenter Roeck Sent: Saturday, February 24, 2024 11:19 AM To: Mark Pearson <mpearson-lenovo@xxxxxxxxx>; David Ober <dober6023@xxxxxxxxx>; wim@xxxxxxxxxxxxxxxxxx Cc: linux-kernel@xxxxxxxxxxxxxxx; linux-watchdog@xxxxxxxxxxxxxxx; David Ober <dober@xxxxxxxxxx> Subject: [External] Re: [PATCH v2] watchdog: add in watchdog for nct6686 On 2/23/24 11:49, Mark Pearson wrote: > Hi, > > On Tue, Dec 19, 2023, at 3:05 PM, Mark Pearson wrote: >> On Tue, Sep 12, 2023, at 7:27 AM, David Ober wrote: >>> This change adds in the watchdog timer support for the nct6686 chip >>> so that it can be used on the Lenovo m90n IOT device >>> [ ... ] > > Would it be possible to get feedback on if anything else is needed for this patch please? > We have customers wanting to use it, and we've ended up having to provide it as an out-of-tree module. Would love to get this integrated into the kernel properly. > The locking in the driver is pretty much pointless since accesses will be serialized by the watchdog core. At the same time, all driver-local locking will not prevent access to the chip from the nct6683 hwmon driver (which also supports nt6686). If both are instantiated, I don't immediately see how they would not corrupt each other. Other than that, there is unexplained code such as nct6686_wdt_set_bank(), which writes two bytes into the chip, and nct6686_wdt_reset_bank(), which only writes one byte, but only conditionally if the bank is != 0. That doesn't really "reset" the bank; at best it selects bank 0xff unless bank 0 was requested. I don't really understand how that would be "play safe" since it is not explained what that means. Besides, the hwmon driver doesn't do that, so I don't understand the implications. Actually, looking into both the this patch and the hwmon driver, it seems that they are locking out each other, with "first driver to probe wins", by reserving the access memory range for themselves. That is not acceptable. I'll have to study the chip datasheets in detail to understand if there are other potential issues, and I have not had the time to do that. Guenter
