On 5/9/2023 8:35 PM, Luck, Tony wrote: >> If a platform supports einj v2, then the einj directory wont be needed, as per spec, >> if a non-zero Error Type value is set by EINJV2_SET_ERROR_TYPE, then any Error Type >> value set by (einj case) SET_ERROR_TYPE_WITH_ADDRESS and/or SET_ERROR_TYPE will be >> ignored. So based on einjv2 is supported or not, we can have either einjv2 or einj >> directory with the related params files in it respectively. >> Kindly let us know your thoughts. > Piyush, > > There are a lot of validation tests built on top of the EINJ v1 Linux interface and interest > in keeping them working rather than forcing a giant "change everything" when the first > EINJ V2 system arrives. > > BIOS team here thinks that the EINJ V2 spec change is (or can be) incremental. > Platform firmware can choose to continue supporting EINJ V1 while also providing > EINJ V2 actions. > > So Linux should be prepared to handle: > > 1) Legacy systems with just the V1 interface. > > 2) Incremental systems that have both V1 and V2 interfaces. > > 3) Future looking systems that only have the V2 interface. > > -Tony Hi all, It seems to me like backwards compatibility has been a big priority historically for Linux. I guess with debugfs we get more leeway to change things, however this interface seems to be present for a very long time and seems to be entrenched enough to keep backwards compatibility. Piyush, Did you make any progress on the solution ? I can offer some help if you don't have BW to work on this. Good video on the topic :) Link: https://www.youtube.com/watch?v=Nn-SGblUhi4&ab_channel=FelipeContreras > >
