All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Dave Airlie <airlied@gmail.com>, Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: alsa-devel@alsa-project.org,
	"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jonathan Corbet <corbet@lwn.net>,
	Linux Wireless List <linux-wireless@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-block@vger.kernel.org,
	"Luis R. Rodriguez" <mcgrof@kernel.org>,
	Daniel Vetter <daniel@ffwll.ch>,
	Network Development <netdev@vger.kernel.org>,
	"dri-devel@lists.sf.net" <dri-devel@lists.sf.net>,
	Dave Airlie <airlied@redhat.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Linux Media Mailing List <linux-media@vger.kernel.org>
Subject: Re: [PATCH] docs: driver-api: firmware: add driver firmware guidelines.
Date: Tue, 19 Jul 2022 09:49:44 -0500	[thread overview]
Message-ID: <95fc3b8f-7556-371d-2817-7e0d811de24a@linux.intel.com> (raw)
In-Reply-To: <CAPM=9tyhOfOz1tn7uNsg_0EzvrBHcSoY+8bignNb2zfgZr6iRw@mail.gmail.com>



On 7/18/22 19:29, Dave Airlie wrote:
>>> +* Firmware should be versioned with at least a major/minor version. It
>>> +  is suggested that the firmware files in linux-firmware be named with
>>> +  some device specific name, and just the major version. The
>>> +  major/minor/patch versions should be stored in a header in the
>>> +  firmware file for the driver to detect any non-ABI fixes/issues. The
>>> +  firmware files in linux-firmware should be overwritten with the newest
>>> +  compatible major version. Newer major version firmware should remain
>>> +  compatible with all kernels that load that major number.
>>
>> would symbolic links be acceptable in the linux-firmware.git where
>> the <fmw>_<major>.bin is a sym link to <fwm>_<major>.<minor>.bin
>>
>> or having the <fwm>_<major>.bin really to be the overwritten every minor
>> update?
> 
> I don't think providing multiple minor versions of fw in
> linux-firmware is that interesting.
> Like if the major is the same, surely you always want the newer ones.
> As long as the
> ABI doesn't break. Otherwise we are just wasting disk space with fws
> nobody will be using.

It was my understanding that once a firmware file is in linux-firmware
it's there forever. There are tons of existing symlinks to point to the
latest version, but the previous versions are not removed/overwritten.

see random examples:
ls -lR /lib/firmware  | grep t4fw
ls -lR /lib/firmware  | grep fw_release



WARNING: multiple messages have this Message-ID (diff)
From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Dave Airlie <airlied@gmail.com>, Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: alsa-devel@alsa-project.org, Jonathan Corbet <corbet@lwn.net>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
	Linux Wireless List <linux-wireless@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-block@vger.kernel.org,
	"Luis R. Rodriguez" <mcgrof@kernel.org>,
	Daniel Vetter <daniel@ffwll.ch>,
	Network Development <netdev@vger.kernel.org>,
	"dri-devel@lists.sf.net" <dri-devel@lists.sf.net>,
	Dave Airlie <airlied@redhat.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Linux Media Mailing List <linux-media@vger.kernel.org>
Subject: Re: [PATCH] docs: driver-api: firmware: add driver firmware guidelines.
Date: Tue, 19 Jul 2022 09:49:44 -0500	[thread overview]
Message-ID: <95fc3b8f-7556-371d-2817-7e0d811de24a@linux.intel.com> (raw)
In-Reply-To: <CAPM=9tyhOfOz1tn7uNsg_0EzvrBHcSoY+8bignNb2zfgZr6iRw@mail.gmail.com>



On 7/18/22 19:29, Dave Airlie wrote:
>>> +* Firmware should be versioned with at least a major/minor version. It
>>> +  is suggested that the firmware files in linux-firmware be named with
>>> +  some device specific name, and just the major version. The
>>> +  major/minor/patch versions should be stored in a header in the
>>> +  firmware file for the driver to detect any non-ABI fixes/issues. The
>>> +  firmware files in linux-firmware should be overwritten with the newest
>>> +  compatible major version. Newer major version firmware should remain
>>> +  compatible with all kernels that load that major number.
>>
>> would symbolic links be acceptable in the linux-firmware.git where
>> the <fmw>_<major>.bin is a sym link to <fwm>_<major>.<minor>.bin
>>
>> or having the <fwm>_<major>.bin really to be the overwritten every minor
>> update?
> 
> I don't think providing multiple minor versions of fw in
> linux-firmware is that interesting.
> Like if the major is the same, surely you always want the newer ones.
> As long as the
> ABI doesn't break. Otherwise we are just wasting disk space with fws
> nobody will be using.

It was my understanding that once a firmware file is in linux-firmware
it's there forever. There are tons of existing symlinks to point to the
latest version, but the previous versions are not removed/overwritten.

see random examples:
ls -lR /lib/firmware  | grep t4fw
ls -lR /lib/firmware  | grep fw_release



  reply	other threads:[~2022-07-19 14:50 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-18  7:21 [PATCH] docs: driver-api: firmware: add driver firmware guidelines Dave Airlie
2022-07-18  7:21 ` Dave Airlie
2022-07-18  7:21 ` Dave Airlie
2022-07-18  9:33 ` Thorsten Leemhuis
2022-07-18  9:33   ` Thorsten Leemhuis
2022-07-18 22:04   ` Jakub Kicinski
2022-07-18 22:04     ` Jakub Kicinski
2022-07-19  0:33     ` Dave Airlie
2022-07-19  0:33       ` Dave Airlie
2022-07-19  0:33       ` Dave Airlie
2022-07-18 17:54 ` Rodrigo Vivi
2022-07-18 17:54   ` Rodrigo Vivi
2022-07-19  0:29   ` Dave Airlie
2022-07-19  0:29     ` Dave Airlie
2022-07-19  0:29     ` Dave Airlie
2022-07-19 14:49     ` Pierre-Louis Bossart [this message]
2022-07-19 14:49       ` Pierre-Louis Bossart
2022-07-18 22:00 ` Luis Chamberlain
2022-07-18 22:00   ` Luis Chamberlain
  -- strict thread matches above, loose matches on Subject: below --
2022-07-18  7:05 Dave Airlie
2022-07-18  7:05 ` Dave Airlie

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=95fc3b8f-7556-371d-2817-7e0d811de24a@linux.intel.com \
    --to=pierre-louis.bossart@linux.intel.com \
    --cc=airlied@gmail.com \
    --cc=airlied@redhat.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=corbet@lwn.net \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.sf.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=rodrigo.vivi@intel.com \
    --cc=torvalds@linux-foundation.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.