Hi Yilun, Please find my response inline. > -----Original Message----- > From: Xu Yilun <yilun.xu@xxxxxxxxx> > Sent: Tuesday, June 28, 2022 2:02 PM > To: Nava kishore Manne <nava.manne@xxxxxxxxxx> > Cc: michal.simek@xxxxxxxxxx; hao.wu@xxxxxxxxx; trix@xxxxxxxxxx; > mdf@xxxxxxxxxx; gregkh@xxxxxxxxxxxxxxxxxxx; ronak.jain@xxxxxxxxxx; > rajan.vaja@xxxxxxxxxx; abhyuday.godhasara@xxxxxxxxxx; > piyush.mehta@xxxxxxxxxx; harsha.harsha@xxxxxxxxxx; > lakshmi.sai.krishna.potthuri@xxxxxxxxxx; linux-arm- > kernel@xxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; linux- > fpga@xxxxxxxxxxxxxxx; git@xxxxxxxxxx > 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
