Hi Tony, Thanks for the review comments. On Thu, May 04, 2023 at 09:00:51PM +0000, Luck, Tony wrote: > > +An error injection example:: > > + > > + # cd /sys/kernel/debug/apei/einj > > + # cat available_error_type # See which errors can be injected > > + 0x00000001 EINJV2 Processor Error > > + 0x00000002 EINJV2 Memory Error > > + 0x00000004 EINJV2 PCI Express Error > > + # echo 0x2 > error_type > > + # echo 0x5 > flags > > + # echo 0x12345000 > param1 > > + # echo 0x2 > param5 > > + # echo 1 > error_inject > > > > Is the expectation that platforms that implement EINJV2 will not include legacy > > EINJ support? > > I spoke to some BIOS folks here. They said that the ACPI 6.5 change is an > extension to the action table with new opcodes for GET/SET when EINJV2 > is supported. The legacy actions are not deprecated. So platform firmware could > support both old and new injection formats. > > So I'm going to double down on this: > > > Maybe it would be better to change the top-level directory to: > > > > /sys/kernel/debug/apei/einjv2 > > and say this isn't a "maybe". The EINJV2 interface files should go > in a new directory. The old files should continue to work (assuming > firmware still enumerates the old available types). > > Simplifying the interface for EINJV2 in the new directory is an option. > I think we should take it ... the "paramN" files that mean different > things for different injection types were an evolution rather than a design. > > -Tony > > > > 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. Thanks, Piyush
