[PATCH v2 1/3] fpga: manager: change status api prototype, don't use older

[Manne, Nava kishore]

Hi Yilun,

	Please find my response inline.

> -----Original Message-----
> From: Xu Yilun <yilun.xu at intel.com>
> Sent: Tuesday, June 28, 2022 2:02 PM
> To: Nava kishore Manne <nava.manne at xilinx.com>
> Cc: michal.simek at xilinx.com; hao.wu at intel.com; trix at redhat.com;
> mdf at kernel.org; gregkh at linuxfoundation.org; ronak.jain at xilinx.com;
> rajan.vaja at xilinx.com; abhyuday.godhasara at xilinx.com;
> piyush.mehta at xilinx.com; harsha.harsha at xilinx.com;
> lakshmi.sai.krishna.potthuri at xilinx.com; linux-arm-
> kernel at lists.infradead.org; linux-kernel at vger.kernel.org; linux-
> fpga at vger.kernel.org; git at xilinx.com
> Subject: Re: [PATCH v2 1/3] fpga: manager: change status api prototype,
> don't use older
> 
> CAUTION: This message has originated from an External Source. Please use
> proper judgment and caution when opening attachments, clicking links, or
> responding to this email.
> 
> 
> On Tue, Jun 21, 2022 at 02:58:31PM +0530, Nava kishore Manne wrote:
> > Different vendors have different error sets defined by Hardware.
> > If we always define the new bits when we cannot find an exact 1:1
> > mapping in the core the 64 bits would soon be used out. Also, it's
> > hard to understand the mixture of different error sets.
> >
> > To address these issues updated the status interface to handle the
> > vendor-specific messages in a generic way. With the updated status
> > interface the vendor-specific driver files can independently handle
> > the error messages.
> 
> I think we don't have to provide the vendor specific HW errors in a generic
> way, maybe the vendor specific drivers could handle them by its own device
> attributes.
> 
> Since the output value set of the interface is specific to each driver, users
> should still interpret them in specific manners. So doesn't see much value for
> a class interface.
>

Agree,  vendor specific drivers could handle them by its own device attributes.
If it is the case, can we remove the existing status interface relevant changes from the core?

Regards,
Navakishore