On Thu, 2024-04-11 at 05:31 -0700, Guenter Roeck wrote: > 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". Yes, although they do have a commercial arrangement with Gigabyte, so they cannot release too much specific information without risking their agreement. > > 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. Okay, I will update the macro name and work on making the descriptions better, and then submit an updated patch set. > > > > > > > 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. Yes, I'll correct that issue in the description. > > Thanks, > Guenter Regards Frank
