On Thu, 2024-04-11 at 05:20 -0700, Guenter Roeck wrote: > On Thu, Apr 11, 2024 at 09:08:19PM +1000, Frank Crawford wrote: > > On Wed, 2024-04-10 at 08:17 -0700, Guenter Roeck wrote: > > > On Mon, Apr 01, 2024 at 01:56:05PM +1100, Frank Crawford wrote: > > > > Major part of the change for the new method to avoid chipset > > > > issues. > > > > > > > > Perform an intial test if the chip ID can be read without > > > > entering > > > > configuration mode, if so, do not enter configuration mode and > > > > continue > > > > as is. > > > > > > > > If chip ID cannot be read, enter configuration mode, and > > > > continue > > > > with > > > > previous code. > > > > > > > > Also update exit code to take account of if we entered > > > > configuration > > > > mode or not. > > > > > > > > > > You describe the changes, but you don't describe the problem you > > > are > > > trying to solve. Even if configuration mode was already entered, > > > that > > > is not a reason to keep it active. We don't _know_ what is going > > > on > > > outside the driver and can not make assumptions. For changes like > > > this > > > you really need to explain the problem you are trying to solve, > > > and > > > the > > > reasoning behind the changes. Just assuming that a set of chips > > > would > > > have its SIO mode enabled by the BIOS is just wrong. We don't > > > know > > > what if anything the BIOS is doing. > > > > In this regard, it is no different to the current code, which runs > > SIO > > mode enable, but does not ever run the SIO mode disable code. > > > > In fact this code is actually safer than the previous code in that > > it > > acts similar to the chip not being enabled or disabled, which would > > happen if no driver existed. > > 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. > > Guenter Regards Frank
