Re: [PATCH v4 6/9] ACPI: APEI: EINJ: Add einjv2 extension struct

[Jonathan Cameron <Jonathan.Cameron@huawei.com>]

On Thu, 13 Mar 2025 13:06:07 -0700
Zaid Alali <zaidal@os.amperecomputing.com> wrote:

> On Thu, Mar 13, 2025 at 09:42:30AM +0000, Jonathan Cameron wrote:
> > On Thu,  6 Mar 2025 15:48:07 -0800
> > Zaid Alali <zaidal@os.amperecomputing.com> wrote:
> >   
> > > Add einjv2 extension struct and EINJv2 error types to prepare
> > > the driver for EINJv2 support. ACPI specifications(1) enables
> > > EINJv2 by extending set_error_type_with_address struct.
> > > 
> > > (1) https://bugzilla.tianocore.org/show_bug.cgi?id=4615  
> > Still seems to be down.
> > Also, we have tag for this.  
> > > 
> > > Signed-off-by: Zaid Alali <zaidal@os.amperecomputing.com>  
> > 
> > Link: https://bugzilla.tianocore.org/show_bug.cgi?id=4615 # [1]
> > 
> > 
> > One additional request inline.
> > Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>  
> > > ---
> > >  drivers/acpi/apei/einj-core.c | 23 +++++++++++++++++++++++
> > >  1 file changed, 23 insertions(+)
> > > 
> > > diff --git a/drivers/acpi/apei/einj-core.c b/drivers/acpi/apei/einj-core.c
> > > index aee9a7b17313..32b8d102f399 100644
> > > --- a/drivers/acpi/apei/einj-core.c
> > > +++ b/drivers/acpi/apei/einj-core.c
> > > @@ -50,6 +50,28 @@
> > >   */
> > >  static int acpi5;
> > >  
> > > +struct syndrome_array {
> > > +	union {
> > > +		u32	acpi_id;
> > > +		u32	device_id;
> > > +		u32	pcie_sbdf;
> > > +		u8	vendor_id[16];
> > > +	} comp_id;
> > > +	union {
> > > +		u32	proc_synd;
> > > +		u32	mem_synd;
> > > +		u32	pcie_synd;
> > > +		u8	vendor_synd[16];
> > > +	} comp_synd;
> > > +};
> > > +
> > > +struct einjv2_extension_struct {
> > > +	u32 length;
> > > +	u16 revision;
> > > +	u16 component_arr_count;
> > > +	struct syndrome_array component_arr[];  
> > 
> > __counted_by(component_arr_count);
> > should be fine and marking these is always good to do in
> > new code (and old code if you have time!)  
> 
> I am not sure if __counted_by is appropriate here. Please note that component_arr_count
> is set by the user and does NOT represent the size of the component_arr[].

Does it represent the length that should ever be accessed (which is what
the __counted_by() stuff will help us find bugs around).

If not that wins an award for misleading naming :)

Jonathan


> > 
> >   
> > > +};
> > > +
> > >  struct set_error_type_with_address {
> > >  	u32	type;
> > >  	u32	vendor_extension;
> > > @@ -58,6 +80,7 @@ struct set_error_type_with_address {
> > >  	u64	memory_address;
> > >  	u64	memory_address_range;
> > >  	u32	pcie_sbdf;
> > > +	struct	einjv2_extension_struct einjv2_struct;
> > >  };
> > >  enum {
> > >  	SETWA_FLAGS_APICID = 1,  
> >