On Tue, 30 Jan 2024, Xu Yilun wrote:
On Wed, Jan 24, 2024 at 11:40:05AM -0800, matthew.gerlach@xxxxxxxxxxxxxxx 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.
Using a revision number to indicate the level of functionality for a
particular IP block seems to be a widely used approach. What other
indicator of functionality level did you have in mind?
The revision number of an IP block would change when new functionality is
added to an IP block or the behavior of the IP block changes. It would be
expected that SW might need to change in order to use the new functionality
or to handle the change in behavior of the IP block. Ideally the
new revision of an IP block would be compatible with existing SW, but that
cannot be guaranteed.
Thanks,
Matthew
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.
