On Tue, May 30, 2023 at 06:05:48PM +0200, Wilczynski, Michal wrote: > > > 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 > > > > > > Hi Michal, Tony, Thanks for your reply. I get that we have to support v1 and v2 for backward compatibility, but for the point no.2 made by Tony - "2) Incremental systems that have both V1 and V2 interfaces.", just wanted to understand if we expect any use case where if EINJ V2 is supported, both v1 and v2 interfaces shall be required at the same time for error injection, as from the spec, if V2 is supported, EINJV2_SET_ERROR_TYPE takes precedence. This seems to be similar with V1 action types - whether to go with SET_ERROR_TYPE_WITH_ADDRESS or SET_ERROR_TYPE, is based on the action entry in the EINJ table where "SET_ERROR_TYPE_WITH_ADDRESS" gets precedence. Please share your inputs. Thanks, Piyush
