On Fri, Apr 12, 2024 at 08:11:11PM +1000, Frank Crawford wrote: > > > > Not really. There is also the watchdog code which will happily > > disable > > SIO access after it is done, causing subsequent accesses by the hwmon > > driver to fail. The code also assumes that SIO access was not > > erroneously > > left enabled by some other code which we don't have any control over. > > And unfortunately if I can't do anything about it, I can only ignore > it. If something does come up we can see what can work out at the > time. > > > > You assume that the hwmon driver is the only driver accessing the > > chip. > > That is a wrong assumption. I understand that the underlying problem > > is really that there is no SIO access infrastructure in the kernel. > > In the absence of such an infrastructure we can not make any > > assumptions > > about SIO access control implemented by other drivers in the kernel, > > and specifically can not assume that SIO access won't be disabled by > > other drivers just because it was enabled when the hwmon driver probe > > function was running. > > In this case the fact that it is the second chip may mean it will not > come up. While I am told that the chip is fully functional with non- > hwmon functions, but currently it does look like most of those aren't > used. While this won't necessarily stay this way in the future, we > currently cannot do anything about it. This patch affects all chips, not just the second one. If any chip is in configuration mode when instantiating this driver, configuration mode won't be enabled anymore, no matter what other drivers may or may not do. That includes situations where other drivers (or the BIOS) erroneously do not disable configuration mode. I understand your reasoning about not enabling configuration mode for certain chips, but that does not explain why it would be necessary to do this for all chips all the time. Sure, there is something we can do: Unless there is a known problem that affects _all_ chips, drop this patch. Thanks, Guenter
