From: Andrew Lunn <andrew@lunn.ch>
To: Vadym Kochan <vadym.kochan@plvision.eu>
Cc: linux-firmware@kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
Oleksandr Mazur <oleksandr.mazur@plvision.eu>,
Serhiy Boiko <serhiy.boiko@plvision.eu>,
Serhiy Pshyk <serhiy.pshyk@plvision.eu>,
Volodymyr Mytnyk <volodymyr.mytnyk@plvision.eu>,
Taras Chornyi <taras.chornyi@plvision.eu>,
Mickey Rachamim <mickeyr@marvell.com>
Subject: Re: [GIT PULL] linux-firmware: mrvl: prestera: Update Marvell Prestera Switchdev v3.0 with policer support
Date: Fri, 18 Jun 2021 15:41:39 +0200 [thread overview]
Message-ID: <YMyikxsdqNi8V5zG@lunn.ch> (raw)
In-Reply-To: <20210618095824.GA21805@plvision.eu>
> 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?
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.
Andrew
next prev parent reply other threads:[~2021-06-18 13:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-17 15:42 [GIT PULL] linux-firmware: mrvl: prestera: Update Marvell Prestera Switchdev v3.0 with policer support Vadym Kochan
2021-06-17 16:45 ` Andrew Lunn
2021-06-17 16:58 ` Vadym Kochan
2021-06-18 1:18 ` Andrew Lunn
2021-06-18 9:58 ` Vadym Kochan
2021-06-18 13:41 ` Andrew Lunn [this message]
2021-06-22 11:44 ` Vadym Kochan
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=YMyikxsdqNi8V5zG@lunn.ch \
--to=andrew@lunn.ch \
--cc=linux-firmware@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mickeyr@marvell.com \
--cc=netdev@vger.kernel.org \
--cc=oleksandr.mazur@plvision.eu \
--cc=serhiy.boiko@plvision.eu \
--cc=serhiy.pshyk@plvision.eu \
--cc=taras.chornyi@plvision.eu \
--cc=vadym.kochan@plvision.eu \
--cc=volodymyr.mytnyk@plvision.eu \
/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).