netdev - Re: [PATCH net-next 1/3] net: marvell: prestera: bump supported firmware version to 3.0

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]

Date:   Wed, 28 Apr 2021 16:47:24 +0300
From:   Vadym Kochan <vadym.kochan@...ision.eu>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
        Taras Chornyi <tchornyi@...vell.com>,
        linux-kernel@...r.kernel.org,
        Mickey Rachamim <mickeyr@...vell.com>,
        Vadym Kochan <vkochan@...vell.com>
Subject: Re: [PATCH net-next 1/3] net: marvell: prestera: bump supported
 firmware version to 3.0

Hi Andrew,

On Fri, Apr 23, 2021 at 08:01:22PM +0200, Andrew Lunn wrote:
> On Fri, Apr 23, 2021 at 08:04:37PM +0300, Vadym Kochan wrote:
> > Hi Andrew,
> > 
> > On Fri, Apr 23, 2021 at 06:49:01PM +0200, Andrew Lunn wrote:
> > > On Fri, Apr 23, 2021 at 06:59:31PM +0300, Vadym Kochan wrote:
> > > > From: Vadym Kochan <vkochan@...vell.com>
> > > > 
> > > > New firmware version has some ABI and feature changes like:
> > > > 
> > > >     - LAG support
> > > >     - initial L3 support
> > > >     - changed events handling logic
> > > > 
> > > > Signed-off-by: Vadym Kochan <vkochan@...vell.com>
> > > > ---
> > > >  drivers/net/ethernet/marvell/prestera/prestera_pci.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/net/ethernet/marvell/prestera/prestera_pci.c b/drivers/net/ethernet/marvell/prestera/prestera_pci.c
> > > > index 298110119272..80fb5daf1da8 100644
> > > > --- a/drivers/net/ethernet/marvell/prestera/prestera_pci.c
> > > > +++ b/drivers/net/ethernet/marvell/prestera/prestera_pci.c
> > > > @@ -13,7 +13,7 @@
> > > >  
> > > >  #define PRESTERA_MSG_MAX_SIZE 1500
> > > >  
> > > > -#define PRESTERA_SUPP_FW_MAJ_VER	2
> > > > +#define PRESTERA_SUPP_FW_MAJ_VER	3
> > > >  #define PRESTERA_SUPP_FW_MIN_VER	0
> > > 
> > > I could be reading the code wrong, but it looks like anybody with
> > > firmware version 2 on their machine and this new driver version
> > > results in the switch not probing? And if the switch does not probe,
> > > do they have any networking to go get the new firmware version?
> > > 
> > 
> > Existing boards have management port which is separated from the PP.
> 
> I don't think that is enough. You have strongly tied the kernel
> version to the firmware version. Upgrade the kernel without first
> upgrading linux-firmware, and things break. In Linux distributions
> these are separate packages, each with their own life cycle. There is
> no guarantee they will be upgraded together.
> 
> > > I think you need to provide some degree of backwards compatibly to
> > > older firmware. Support version 2 and 3. When version 4 comes out,
> > > drop support for version 2 in the driver etc.
> 
> The wifi driver i have for my laptop does something like this. It
> first tries to load the latest version of the firmware the driver
> supports, and if that fails, it goes back to older versions until it
> finds a version it can load, or gives up, saying they are all too old.
> 
>       Andrew

Your comment is right in cases when there's no management port.
However, the all current designs use management port connected directly
to the CPU and not via the PP. This promises the Network connectivity
will remain functional all the time. As for your comment, we have a
plan of designing basic PP ports configuration that will enable
recovering the PP ports connectivity in case backward compatibility
issue will happen.

Regarding the distribution issue when the driver version might be released
earlier than the firmware, it looks like that the probability of such
case is very low because the distributor of the target Linux system will
keep track (actually this is how I see it) that driver and firmware
versions are aligned.

Thanks,
Vadym Kochan