From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1EDC2C48BE8 for ; Fri, 18 Jun 2021 13:41:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0258C611CC for ; Fri, 18 Jun 2021 13:41:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233935AbhFRNny (ORCPT ); Fri, 18 Jun 2021 09:43:54 -0400 Received: from vps0.lunn.ch ([185.16.172.187]:44546 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233904AbhFRNnv (ORCPT ); Fri, 18 Jun 2021 09:43:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:From:Sender:Reply-To:Subject: Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:Content-Disposition:In-Reply-To:References; bh=78qpKeNOzP/NAiEhB003K9aO28jOhCI8hGIf6ql5ius=; b=NzC8w6hiC2xjfYYW9YbyuUHhXq zVLU0VY8iMe3blpC9TTcef5XD5TdYf/gBOYyVgS/hRWlKlud97SvoZnR4uePoO6t67cO1NhbjVk6g JuuBeRME8DpU/cD0Z8eDTbdmoWxOLUov6rwmvU9uP2o9cgvTGaOjd8t3t1F8mpaWkgKA=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1luEkd-00A4hL-T6; Fri, 18 Jun 2021 15:41:39 +0200 Date: Fri, 18 Jun 2021 15:41:39 +0200 From: Andrew Lunn To: Vadym Kochan List-Id: Cc: linux-firmware@kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Oleksandr Mazur , Serhiy Boiko , Serhiy Pshyk , Volodymyr Mytnyk , Taras Chornyi , Mickey Rachamim Subject: Re: [GIT PULL] linux-firmware: mrvl: prestera: Update Marvell Prestera Switchdev v3.0 with policer support Message-ID: References: <20210617154206.GA17555@plvision.eu> <20210617165824.GA5220@plvision.eu> <20210618095824.GA21805@plvision.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210618095824.GA21805@plvision.eu> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > 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