On Thu, Apr 11, 2024 at 09:03:06PM +1000, Frank Crawford wrote: > On Wed, 2024-04-10 at 08:10 -0700, Guenter Roeck wrote: > > On Mon, Apr 01, 2024 at 01:56:03PM +1100, Frank Crawford wrote: > > > Rename previous definitions to match the new information that they > > > are > > > preinitialised by the BIOS and should not receive codes to enter or > > > exit > > > configuration mode. > > > > > > > That is wrong. NOEXIT is needed for broken chips where two chips are > > on the > > sio bus, and disabling sio access on the broken chip results in sio > > access > > errors. The description is also wrong, because SIO mode still needs > > to be > > _entered_. > > As noted in the patch group write up, this change has come from the > technical specifications for the chips not for the board. If by SIO > mode you mean the sequence "0x87,0x01,0x55,0xAA" then it should not be > used for these chips according to people with access to the > specification documents. > > Unfortunately, I don't have direct access to these documents, so cannot > quote the full description. > > Now, the macro name may not be the best (BIOSOPEN), and I'm happy to > change it to something better, but the current name of "NOEXIT" is also > wrong. > > However, for the chips that this relates to, and are defined to use in > the it87_devices structure, you can access the chip details without the > the superio_enter sequence, as that is specifically the read that > occurs to find the chipID, and I have tested it on a number of > different chips, both of this type and older ones that do need the > entry sequence. > > What makes this a little more difficult is that the chips that it > affects also only ever appears to be the second chip on the bus, which > may be by design, or just current usage. > > I will add that the use of enter sequence has been confirmed to fail > and cause the exact chip lockup concerned about on the Gigabyte X670E > Aorus Master board. While you may say that we should only do this for > that board, the information I have received is that it is cause by > incorrect access to those chipIDs, not board specific. It looks like you fund a better source of support than me. All I ever got was "we do not support Linux". Anyway, please find a better term than BIOSOPEN. I don't really care too much what it is as long as it doesn't suggest to be related to something that it isn't. FEAT_NOCONF or something similar might do. > > > > Also, a BIOS open mode, if it indeed exists, would have to be be > > board > > specific, not chip specific. > > Now here my description may be wrong in it being BIOS related, but > rather it is specifically the chip initialisation, but the details on > access came from the chip specifications. Well, again, BIOS suggests that the BIOS is involved, which would make it board specific. Thanks, Guenter
