netdev - Re: [GIT PULL] linux-firmware: mrvl: prestera: Update Marvell Prestera Switchdev v3.0 with policer 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] [day] [month] [year] [list]

Message-ID: <20210622114401.GA32650@plvision.eu>
Date:   Tue, 22 Jun 2021 14:44:01 +0300
From:   Vadym Kochan <vadym.kochan@...ision.eu>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     linux-firmware@...nel.org, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Oleksandr Mazur <oleksandr.mazur@...ision.eu>,
        Serhiy Boiko <serhiy.boiko@...ision.eu>,
        Serhiy Pshyk <serhiy.pshyk@...ision.eu>,
        Volodymyr Mytnyk <volodymyr.mytnyk@...ision.eu>,
        Taras Chornyi <taras.chornyi@...ision.eu>,
        Mickey Rachamim <mickeyr@...vell.com>
Subject: Re: [GIT PULL] linux-firmware: mrvl: prestera: Update Marvell
 Prestera Switchdev v3.0 with policer support

Hi Andrew,

On Fri, Jun 18, 2021 at 03:41:39PM +0200, Andrew Lunn wrote:
> > I just picked some from the git log:
> > 
> >     48237834129d ("QCA: Update Bluetooth firmware for QCA6174")
> > 
> > this just updates the binary and description says that it updates
> > to v26.
> > 
> > Not sure if it is good example.
> 
> The filename is qca/rampatch_usb_00000302.bin. If you look at
> drivers/bluetooth/btusb.c you can see that 00000302 is the version of
> the ROM in the device which is being patched. So there is no
> expectation of knowing the firmware version from the firmware
> filename.
> 
> > But anyway, I agree with you that better if new changes also reflects
> > the FW binary name (version) so it will be easy to find out which FW binary
> > have or not particular features.
> > 
> > So I think better to add new FW 3.1 binary ?
> 
> Probably. But please consider your whole upgrade story. You are
> changing the firmware version quite frequently. How do end users cope
> with this? Is the driver going to support 3.1, 3.0 and 2.0? Or just
> 3.1 and 2.0?

I think 3.1, 3.0 (still need to check about this) and 2.0, and the
driver need to be changed to use array of versions rather the previous
hardcoded value.

> 
> Do you have more features in firmware 3.1 you need to add driver
> support for? Or can we expect a 3.2 in a few weeks time? What are your
> users expectations at the moment? It could be, you don't consider the
> driver has enough features at the moment that anybody other than early
> adopters playing with it would consider using it. That you don't
> expect real use of it for another six months, or a year. If that is
> true, you probably can be a bit more disruptive at the moment. But
> when you have a production ready driver, you really do need to
> consider how your users deal with upgrades, keeping the firmware
> version stable for a longer period of time.

Thats, actually true, at this stage the FW can be updated frequently
because of bringing new offloading support. And you are right that
currently this driver is mostly in the sandbox mode. But even for the
earlier adopters looks like it is good to keep the version consistency.

For this particular update it has missing small changes for policer and
routing offloading (so it is kind of fix for 3.0 version). So, for
easiness it would be good to just replace the current 3.0 version, but
for consistency - better to use some extra version.

> 
> 	Andrew