From: Yibo Dong <dong100@mucse.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, horms@kernel.org,
corbet@lwn.net, gur.stavi@huawei.com, maddy@linux.ibm.com,
mpe@ellerman.id.au, danishanwar@ti.com, lee@trager.us,
gongfan1@huawei.com, lorenzo@kernel.org, geert+renesas@glider.be,
Parthiban.Veerasooran@microchip.com, lukas.bulwahn@redhat.com,
alexanderduyck@fb.com, richardcochran@gmail.com,
netdev@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 2/5] net: rnpgbe: Add n500/n210 chip support
Date: Fri, 15 Aug 2025 15:21:03 +0800 [thread overview]
Message-ID: <67844B7C9238FBFB+20250815072103.GC1148411@nic-Precision-5820-Tower> (raw)
In-Reply-To: <63af9ff7-0008-4795-a78b-9bed84d75ae0@lunn.ch>
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.
next prev parent reply other threads:[~2025-08-15 7:22 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-14 7:38 [PATCH v4 0/5] Add driver for 1Gbe network chips from MUCSE Dong Yibo
2025-08-14 7:38 ` [PATCH v4 1/5] net: rnpgbe: Add build support for rnpgbe Dong Yibo
2025-08-15 1:58 ` Andrew Lunn
2025-08-14 7:38 ` [PATCH v4 2/5] net: rnpgbe: Add n500/n210 chip support Dong Yibo
2025-08-14 12:07 ` MD Danish Anwar
2025-08-14 13:52 ` Yibo Dong
2025-08-15 2:07 ` Andrew Lunn
2025-08-15 2:05 ` Andrew Lunn
2025-08-15 2:38 ` Yibo Dong
2025-08-15 3:56 ` Andrew Lunn
2025-08-15 7:21 ` Yibo Dong [this message]
2025-08-15 13:36 ` Andrew Lunn
2025-08-18 1:14 ` Yibo Dong
2025-08-14 7:38 ` [PATCH v4 3/5] net: rnpgbe: Add basic mbx ops support Dong Yibo
2025-08-15 2:13 ` Andrew Lunn
2025-08-15 2:43 ` Yibo Dong
2025-08-15 3:59 ` Andrew Lunn
2025-08-15 7:22 ` Yibo Dong
2025-08-15 2:29 ` Andrew Lunn
2025-08-15 3:15 ` Yibo Dong
2025-08-14 7:38 ` [PATCH v4 4/5] net: rnpgbe: Add basic mbx_fw support Dong Yibo
2025-08-14 12:10 ` MD Danish Anwar
2025-08-14 13:54 ` Yibo Dong
2025-08-15 3:27 ` Andrew Lunn
2025-08-15 6:36 ` Yibo Dong
2025-08-15 13:21 ` Andrew Lunn
2025-08-18 2:14 ` Yibo Dong
2025-08-14 7:38 ` [PATCH v4 5/5] net: rnpgbe: Add register_netdev Dong Yibo
2025-08-14 12:14 ` MD Danish Anwar
2025-08-14 13:59 ` Yibo Dong
2025-08-15 2:28 ` Yibo Dong
2025-08-15 3:42 ` Andrew Lunn
2025-08-15 6:44 ` Yibo Dong
2025-08-15 18:06 ` Andrew Lunn
2025-08-18 1:21 ` Yibo Dong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=67844B7C9238FBFB+20250815072103.GC1148411@nic-Precision-5820-Tower \
--to=dong100@mucse.com \
--cc=Parthiban.Veerasooran@microchip.com \
--cc=alexanderduyck@fb.com \
--cc=andrew+netdev@lunn.ch \
--cc=andrew@lunn.ch \
--cc=corbet@lwn.net \
--cc=danishanwar@ti.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=geert+renesas@glider.be \
--cc=gongfan1@huawei.com \
--cc=gur.stavi@huawei.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=lee@trager.us \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lorenzo@kernel.org \
--cc=lukas.bulwahn@redhat.com \
--cc=maddy@linux.ibm.com \
--cc=mpe@ellerman.id.au \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=richardcochran@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).