linux-kernel - Re: [PATCH] fpga: dfl: afu: update initialization of port

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue, 30 Jan 2024 17:35:35 +0800
From: Xu Yilun <yilun.xu@...ux.intel.com>
To: matthew.gerlach@...ux.intel.com
Cc: hao.wu@...el.com, trix@...hat.com, mdf@...nel.org, yilun.xu@...el.com,
	linux-fpga@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] fpga: dfl: afu: update initialization of port_hdr driver

On Wed, Jan 24, 2024 at 11:40:05AM -0800, matthew.gerlach@...ux.intel.com wrote:
> 
> 
> On Tue, 23 Jan 2024, Xu Yilun wrote:
> 
> > On Mon, Jan 22, 2024 at 09:24:33AM -0800, Matthew Gerlach wrote:
> > > Revision 2 of the Device Feature List (DFL) Port feature has
> > > slightly different requirements than revision 1. Revision 2
> > > does not need the port to reset at driver startup. In fact,
> > 
> > Please help illustrate what's the difference between Revision 1 & 2, and
> > why revision 2 needs not.
> 
> I will update the commit message to clarify the differences between revision
> 1 and 2.
> 
> > 
> > > performing a port reset during driver initialization can cause
> > > driver race conditions when the port is connected to a different
> > 
> > Please reorganize this part, in this description there seems be a
> > software racing bug and the patch is a workaround. But the fact is port
> > reset shouldn't been done for a new HW.
> 
> Reorganizing the commit message a bit will help to clarify why port reset
> should not be performed during driver initialization with revision 2 of the
> hardware.
> 
> > 
> > BTW: Is there a way to tell whether the port is connected to a different
> > PF? Any guarantee that revision 3, 4 ... would need a port reset or not?
> 
> The use of revision 2 of the port_hdr IP block indicates that the port can
> be connected multiple PFs, but there is nothing explicitly stating which PFs

Sorry, I mean any specific indicator other than enumerate the revision
number? As you said below, checking revision number may not make further
things right, then you need to amend code each time.

Thanks,
Yilun

> the port is connected to.
> 
> It is hard to predict the requirements and implementation of a future
> revision of an IP block. If a requirement of a future revision is to work
> with existing software, then the future revision would not require a port
> reset at driver initialization.
>