[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <SJ0PR18MB4009EC646887EC524A02E62AB2BD9@SJ0PR18MB4009.namprd18.prod.outlook.com>
Date: Tue, 19 Oct 2021 17:48:19 +0000
From: "Volodymyr Mytnyk [C]" <vmytnyk@...vell.com>
To: Andrew Lunn <andrew@...n.ch>
CC: "kuba@...nel.org" <kuba@...nel.org>,
Mickey Rachamim <mickeyr@...vell.com>,
Serhiy Pshyk <serhiy.pshyk@...ision.eu>,
Taras Chornyi <taras.chornyi@...ision.eu>,
"Vadym Kochan [C]" <vkochan@...vell.com>,
Yevhen Orlov <yevhen.orlov@...ision.eu>,
"Taras Chornyi [C]" <tchornyi@...vell.com>,
"David S. Miller" <davem@...emloft.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next v2] net: marvell: prestera: add firmware v4.0
support
Hi Andrew,
> > - Major changes have been made to new v4.0 FW ABI to add support of new features,
> > introduce the stability of the FW ABI and ensure better forward compatibility
> > for the future vesrions.
>
> So this point needs bring out in the commit message. You need to explain why you think you will never need another ABI break. How your new design allows extensible, what you have fixed in your old design which has causes two ABI breaks.
With the current set of features that v4.0 FW ABI supports, we don't expect any changes because of stable ABI that was defined and tested through long period of time. Also, the ABI may be extended in case of new features, but it will not break the backward compatibility.
- Most of the changes are related to L1 ABI, where MAC and PHY API configuration are splitted.
- ACL ABI has been splitted to low-level TCAM and Counters ABI to provide more HW ACL capabilities for future driver versions.
I will update the commit message accordingly with the description as a patch-set v3.
>
> Given this is the second time you have broken the ABI, i need convincing.
>
> > - All current platforms using this driver have dedicated OOB mgmt port, thus the
> > user still be able to do upgrade of the FW. So, no "Bricks in broom closets" :).
>
> So your cabling guidelines suggest a dedicated Ethernet cable from the broom closet to the NOC for the OOB port? I suspect most users ignore this, and do management over the network. They only use the OOB port when they have bricked the device because they installed a kernel upgrade over the network, without upgrading the firmware.
>
> Andrew
Regards,
Volodymyr
Powered by blists - more mailing lists