Messages in this thread | | | From | "Manne, Nava kishore" <> | Subject | RE: [PATCH v2 1/3] fpga: manager: change status api prototype, don't use older | Date | Wed, 17 Aug 2022 11:16:14 +0000 |
| |
Hi Yilun,
Please find my response inline.
> -----Original Message----- > From: Xu Yilun <yilun.xu@intel.com> > Sent: Tuesday, June 28, 2022 2:02 PM > To: Nava kishore Manne <nava.manne@xilinx.com> > Cc: michal.simek@xilinx.com; hao.wu@intel.com; trix@redhat.com; > mdf@kernel.org; gregkh@linuxfoundation.org; ronak.jain@xilinx.com; > rajan.vaja@xilinx.com; abhyuday.godhasara@xilinx.com; > piyush.mehta@xilinx.com; harsha.harsha@xilinx.com; > lakshmi.sai.krishna.potthuri@xilinx.com; linux-arm- > kernel@lists.infradead.org; linux-kernel@vger.kernel.org; linux- > fpga@vger.kernel.org; git@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
| |