linux-kernel - Re: [PATCH v4 2/5] net: rnpgbe: Add n500/n210 chip support

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: <67844B7C9238FBFB+20250815072103.GC1148411@nic-Precision-5820-Tower>
Date: Fri, 15 Aug 2025 15:21:03 +0800
From: Yibo Dong <dong100@...se.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: andrew+netdev@...n.ch, davem@...emloft.net, edumazet@...gle.com,
	kuba@...nel.org, pabeni@...hat.com, horms@...nel.org,
	corbet@....net, gur.stavi@...wei.com, maddy@...ux.ibm.com,
	mpe@...erman.id.au, danishanwar@...com, lee@...ger.us,
	gongfan1@...wei.com, lorenzo@...nel.org, geert+renesas@...der.be,
	Parthiban.Veerasooran@...rochip.com, lukas.bulwahn@...hat.com,
	alexanderduyck@...com, richardcochran@...il.com,
	netdev@...r.kernel.org, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 2/5] net: rnpgbe: Add n500/n210 chip support

On Fri, Aug 15, 2025 at 05:56:30AM +0200, Andrew Lunn wrote:
> > It means driver version 0.2.4.16.
> 
> And what does that mean?
> 
> > I used it in 'mucse_mbx_ifinsmod'(patch4, I will move this to that patch),
> > to echo 'driver version' to FW. FW reply different command for different driver.
> 
> There only is one driver. This driver.
> 
> This all sounds backwards around. Normally the driver asks the
> firmware what version it is. From that, it knows what operations the
> firmware supports, and hence what it can offer to user space.
> 
> So what is your long terms plan? How do you keep backwards
> compatibility between the driver and the firmware?
> 
> 	Andrew
> 

To the driver, it is the only driver. It get the fw version and do
interactive with fw, this is ok.
But to the fw, I think it is not interactive with only 'this driver'?
Chips has been provided to various customers with different driver
version......

More specific, our FW can report link state with 2 version:
a: without pause status (to driver < 0.2.1.0)
b: with pause status (driver >= 0.2.1.0)

Then the driver update the status to reg to confirm info to fw.
fw check reg status to decide whether report state again or not.

'Driver < 0.2.1.0' only support 'version a', it will not update
pause status to reg. Then, fw will report status again, again...

So, I add 'echo driver version to fw in driver 0.2.1.0' to solve
this condition. fw consider it an old driver if driver not 'echo
version to it'.

1. Old driver with old fw, it works fine.
2. Old driver with new fw, fw knows the driver is old, it works fine with
version a.
3. New driver with new fw, fw knows the driver is new, it works fine with
version b.
4. New driver with old fw, fw echo state without pause, and it never check
it in reg, it also works fine.

And I think it is a way to make compatibility more easy. Driver know fw
version, and fw also know driver version. Fw can easy edit existing cmd,
not only add new ones since it can support old cmd for old driver,
'edited cmd' to new driver.

Also, hw->driver_version is not useful to driver. I can use a macro in
mucse_mbx_ifinsmod.

Thanks for your feedback.