netdev - RE: [PATCH net-next v3] net: txgbe: change LAN reset mode

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]

Message-ID: <001101d9b5f7$df93df60$9ebb9e20$@trustnetic.com>
Date: Fri, 14 Jul 2023 10:06:59 +0800
From: Jiawen Wu <jiawenwu@...stnetic.com>
To: "'Paolo Abeni'" <pabeni@...hat.com>,
	<netdev@...r.kernel.org>
Cc: <mengyuanlou@...-swift.com>
Subject: RE: [PATCH net-next v3] net: txgbe: change LAN reset mode

On Thursday, July 13, 2023 8:49 PM, Paolo Abeni wrote:
> Hi,
> 
> On Tue, 2023-07-11 at 14:26 +0800, Jiawen Wu wrote:
> > The old way to do LAN reset is sending reset command to firmware. Once
> > firmware performs reset, it reconfigures what it needs.
> >
> > In the new firmware versions, veto bit is introduced for NCSI/LLDP to
> > block PHY domain in LAN reset. At this point, writing register of LAN
> > reset directly makes the same effect as the old way. And it does not
> > reset MNG domain, so that veto bit does not change.
> >
> > And this change is compatible with old firmware versions, since veto
> > bit was never used.
> 
> As the current commit message wording still raises questions, could you
> please explicitly the level of compatibility of both the old and new
> firmware pre/after this change?

The old firmware is compatible with the driver before and after this
change. The new firmware needs to use with the driver after this change if
it wants to implement the new feature, otherwise it is the same as the old
firmware.

Does this explain make sense?

> 
> And please drop the fixes tag, thanks!
>