Bug#1029843: live-boot: Devices Requiring Firmware: multiple requested files in single line overlapping / special characters

[Alexander Dalm]

Package: live-boot
Severity: normal
X-Debbugs-Cc: a.dal...@googlemail.com

Dear Maintainer,

on the Devices Requiring Firmware step in the debian-installer (debian-11.6.0-amd64-netinst.iso)
multiple files are requested for my Beelink BT3:
brcmfmac43340-sdio.bin
brcmfmac43340-sdio.To be filled by O.E.M.-Z83.txt
brcmfmac43340-sdio.txt
rtl8168g-2.fw
both .txt files are requested at once and they are displayed tab-separated and overlapping:
"The missing firmware files are: brcm/brcmfmac43340-sdio.To brcm/brcmfmac43340-sdio.txt"
This makes no sense if you don't kwow which files are actually needed.
Better would be adding newlines after "The missing files" and every file.

brcmfmac43340-sdio.txt is just requested as fallback if the other file is not existing:
dmesg | grep -E 'firmware|Bluetooth|brcm'
...
brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43340-sdio.bin failed with error -2
brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43340-sdio.To be filled by O.E.M.-Z83.txt failed with error -2
brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43340-sdio.txt failed with error -2
...

After installation the brcmfmac43340-sdio.To be filled by O.E.M.-Z83.txt file is missing in the system files,
it seems like the copy process fails either due to special characters or length.
rtl8168g-2.fw is requested last if not on the usb-stick but it is copied without asking when available
(tested twice, it can be found in system files after installation)
I'm not sure if the installer is supposed to ask for every single file or
auto-copy if available when other firmware files were copied before

Wishlist: firmware-detection for the existing firmware-folder in the iso would be great.
-> flash iso to usb, add files -> done.
for me this seems like including just a additional search path for firmware detection = 1 line of code

here are the cases I've tested:

files on stick: brcmfmac43340-sdio.bin, brcmfmac43340-sdio.To be filled by O.E.M.-Z83.txt
The missing firmware files are: brcm/brcmfmac43340-sdio.bin -> Yes
The missing firmware files are: brcm/brcmfmac43340-sdio.To brcm/brcmfmac43340-sdio.txt -> Yes
Installer asks for .txt files again -> hard shutdown, no cancel installation button available

files on stick: brcmfmac43340-sdio.bin, brcmfmac43340-sdio.txt
The missing firmware files are: brcm/brcmfmac43340-sdio.bin -> Yes
The missing firmware files are: brcm/brcmfmac43340-sdio.To brcm/brcmfmac43340-sdio.txt -> Yes
The missing firmware files are: brcm/brcmfmac43340-sdio.To brcm/brcmfmac43340-sdio.clm_blob -> No (WLAN works without)
The missing firmware files are: rtl_nic/rtl8168g-2.fw -> hard shutdown, no cancel installation button available

files on stick: brcmfmac43340-sdio.bin, brcmfmac43340-sdio.txt, rtl8168g-2.fw
The missing firmware files are: brcm/brcmfmac43340-sdio.bin -> Yes
The missing firmware files are: brcm/brcmfmac43340-sdio.To brcm/brcmfmac43340-sdio.txt -> Yes
The missing firmware files are: brcm/brcmfmac43340-sdio.To brcm/brcmfmac43340-sdio.clm_blob -> No (WLAN works without)
not asked for rtl8168g-2.fw but file is after installation in /lib/firmware/rtl_nic/
(brcmfmac43340-sdio.bin and brcmfmac43340-sdio.txt are in /lib/firmware/brcm/ after installation)

files on stick: brcmfmac43340-sdio.bin, brcmfmac43340-sdio.txt, brcmfmac43340-sdio.To be filled by O.E.M.-Z83.txt, rtl8168g-2.fw
The missing firmware files are: brcm/brcmfmac43340-sdio.bin -> Yes
The missing firmware files are: brcm/brcmfmac43340-sdio.To brcm/brcmfmac43340-sdio.txt -> Yes
The missing firmware files are: brcm/brcmfmac43340-sdio.To brcm/brcmfmac43340-sdio.clm_blob -> No (WLAN works without)
not asked for rtl8168g-2.fw but file is after installation in /lib/firmware/rtl_nic/
only brcmfmac43340-sdio.bin and brcmfmac43340-sdio.txt are in /lib/firmware/brcm/ after installation


-- System Information:
Debian Release: 11.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-21-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_USER
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages live-boot depends on:
pn live-boot-initramfs-tools | live-boot-backend <none>

Versions of packages live-boot recommends:
pn live-boot-doc <none>
pn live-tools <none>
ii rsync 3.2.3-4+deb11u1
pn uuid-runtime <none>

Versions of packages live-boot suggests:
pn cryptsetup <none>
pn curlftpfs <none>
pn httpfs2 <none>
ii wget 1.21-1+deb11u1

[Alexander Dalm]

instead of the overlapping there could simply be an issue with the parsing of the "brcmfmac43340.To be filled by O.E.M.txt" file at the first space character so a .To is file requested.

"To be filled by O.E.M." is the Manufacturer Name and "Z83" the Product Name stored in my BIOS, there are some other files for devices like brcmfmac43340.meegopad-t08.txt in the package firmware-brcm80211, I simply renamed this file without any problems. Ubuntu, Linux Mint and Manjaro require even the .bin file in Manufacturer-Vendor format. Not mentioning the compressed .bin.xz and .txt.xz files with Kernel 6 in Arch Linux and RebornOS.

[James Addison]

Followup-For: Bug #1029843
X-Debbugs-Cc: a.dal...@googlemail.com, pe...@akeo.ie, debia...@lists.debian.org
Control: reassign -1 hw-detect
Control: merge -1 1030519
Control: affects -1 raspi-firmware
Control: title -1 check-missing-firmware: patch for files with space characters, mediamount and more (with code)

Hi Alexander,

Thanks for these reports - I was attempting a netboot of the Bookworm RC 2
installer on a Raspberry Pi and ran into the same problem: hw-detect attempting
to load firmware files that contain spaces in the filename.

I've added Pete on cc - he noticed this issue too a few years ago, while
documenting how to install regular Debian 11 on a RPi.

Quoting some notes from his guide[1]:

> Also, if you did install the Wifi firmware blobs, you may find that you get the following error during boot:
...
> To fix that, simply rename /lib/firmware/brcm/brcmfmac43455-sdio.Raspberry to /lib/firmware/brcm/brcmfmac43455-sdio.Raspberry Pi Foundation-Raspberry Pi 4 Model B.txt.


Let's merge this with your linked bug #1030519 - I agree that the hw-detect
package seems to be the location of the relevant scripting[2]. Do you have an
account on Salsa[3] to offer fixes back to Debian git repositories?


I have some code review / comments about the patches, focusing only on the
filename problem to begin with:

Do we _need_ to retain the vendor name and model name in the firmware filename?

My guess (without being too familiar with the firmware loading process yet)
is that it'd be easier to ship a concisely-named file that omit the vendor and
model strings, so we'd want a way to map:

brcmfmac43455-sdio.Raspberry Pi Foundation-Raspberry Pi 4 Model B.txt

To the corresponding, already-packaged[4] filename:

brcmfmac43455-sdio.txt

...while preferably avoiding adding custom scripting for too many other
firmware filenames in future. Where does the long-format filename originate
from?

It seems unlikely that this should be fixed for Bookworm, but I can offer some
assistance with further testing, and hopefully we can improve this for Trixie.

And a nitpick: the way this appears in the hw-detect prompt screen in the
installer is a bit odd, because spaces in the filenames are replaced with
newlines. That might be nice to fix at the same time if we can.

Thanks,
James

[1] - https://forums.raspberrypi.com/viewtopic.php?t=282839

[2] - https://salsa.debian.org/installer-team/hw-detect/-/blob/f76d36b65aa14a14497f5ef57c9721f313ea98e6/check-missing-firmware.sh#L154-187

[3] - https://salsa.debian.org/

[4] - https://packages.debian.org/bookworm/all/raspi-firmware/filelist

[Diederik de Haas]

On Sunday, 30 April 2023 20:25:50 CEST James Addison wrote:
> Do we _need_ to retain the vendor name and model name in the firmware
> filename?
>
> My guess (without being too familiar with the firmware loading process yet)
> is that it'd be easier to ship a concisely-named file that omit the vendor
> and model strings, so we'd want a way to map:
>
> brcmfmac43455-sdio.Raspberry Pi Foundation-Raspberry Pi 4 Model B.txt
>
> To the corresponding, already-packaged[4] filename:
>
> brcmfmac43455-sdio.txt
>
> ...while preferably avoiding adding custom scripting for too many other
> firmware filenames in future. Where does the long-format filename originate
> from?

I suggest we stick to `brcmfmac43455-sdio.raspberrypi,4-model-b.txt` as that
is its name in the upstream repo:
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git

> And a nitpick: the way this appears in the hw-detect prompt screen in the
> installer is a bit odd, because spaces in the filenames are replaced with
> newlines. That might be nice to fix at the same time if we can.

AFAIC it's a bit more then a nitpick as it identified a/several bugs in the
script. Run it through `shellcheck` and you'll see a whole bunch of*:
SC2086 (info): Double quote to prevent globbing and word splitting.
https://www.shellcheck.net/wiki/SC2086

And that's exactly what happens or will happen. Even though the RPi4 filename
doesn't contain spaces, there are several in the `brcm` directory that do.
I didn't check other directories, but I'd expect that filenames with a space is
NOT an anomaly.

*) and several other warnings/suggestions

[Cyril Brulebois]

Hi,

Diederik de Haas <didi....@cknow.org> (2023-04-30):

> I suggest we stick to `brcmfmac43455-sdio.raspberrypi,4-model-b.txt` as that
> is its name in the upstream repo:
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git

Yes please.

> > And a nitpick: the way this appears in the hw-detect prompt screen in the
> > installer is a bit odd, because spaces in the filenames are replaced with
> > newlines. That might be nice to fix at the same time if we can.
>
> AFAIC it's a bit more then a nitpick as it identified a/several bugs in the
> script. Run it through `shellcheck` and you'll see a whole bunch of*:
> SC2086 (info): Double quote to prevent globbing and word splitting.
> https://www.shellcheck.net/wiki/SC2086
>
> And that's exactly what happens or will happen. Even though the RPi4 filename
> doesn't contain spaces, there are several in the `brcm` directory that do.
> I didn't check other directories, but I'd expect that filenames with a space is
> NOT an anomaly.
>
> *) and several other warnings/suggestions

We won't rewrite hw-detect for bookworm, nor will we make it “shellcheck
compliant”. Now is definitely not the time to deal with such things, and
yes I'm going to call system files (e.g. package-shipped) with spaces an
anomaly.

People are much than welcome to put energy into making hw-detect more
robust in the future, but even knowing some bits about it, it's some
kind of a maze and I *really* don't want to lose any feature for the
generic cases (non-crazy filenames).

It's easy enough to just not use spaces in filenames in the first place.


Cheers,
--
Cyril Brulebois (ki...@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

[James Addison]

On Mon, 1 May 2023 at 03:00, Cyril Brulebois <ki...@debian.org> wrote:
> Diederik de Haas <didi....@cknow.org> (2023-04-30):
> > I suggest we stick to `brcmfmac43455-sdio.raspberrypi,4-model-b.txt` as that
> > is its name in the upstream repo:
> > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
>
> Yes please.

Agreed.

I'm trying to figure out the reason that the kernel module requests
the verbose-style firmware filename (that include spaces) in the first
place.

In the case of the RPi B, the kernel source contains a device-tree
file for the brcm2711, the relevant hardware.

The 'compatible'[1] field of the brcm2711 device-tree structure file
includes the string "raspberrypi,4-model-b" -- matching one of the
files in linux-firmware.git's brcm directory -- but the 'model'[2]
field, containing "Raspberry Pi 4 Model B", could be the one that's
used when the firmware file request is issued when the module loads
(?).

Also, the brcmfmac kernel module code mentions[3] that it can load
board-specific firmware file paths. I'm not yet sure whether that's
relevant (either now, or in future).

> Diederik de Haas <didi....@cknow.org> (2023-04-30):

> > And that's exactly what happens or will happen. Even though the RPi4 filename
> > doesn't contain spaces, there are several in the `brcm` directory that do.
> > I didn't check other directories, but I'd expect that filenames with a space is
> > NOT an anomaly.

Since more files with that pattern are appearing upstream in
linux-firmware.. yes, slightly reluctantly it does seem that this will
be needed.

On Mon, 1 May 2023 at 03:00, Cyril Brulebois <ki...@debian.org> wrote:
> We won't rewrite hw-detect for bookworm, nor will we make it “shellcheck
> compliant”. Now is definitely not the time to deal with such things, and
> yes I'm going to call system files (e.g. package-shipped) with spaces an
> anomaly.
>
> People are much than welcome to put energy into making hw-detect more
> robust in the future, but even knowing some bits about it, it's some
> kind of a maze and I *really* don't want to lose any feature for the
> generic cases (non-crazy filenames).

I'd generally agree with all that. For robustness, and when it's safe
to, it'd be nice to resolve both issues (firstly to ensure that the
correct firmware filename is being requested in these cases -- maybe
it already is, I'm still trying to determine whether that's a bug --
and secondly to support spaces in firmware filenames in hw-detect).

[1] - https://sources.debian.org/src/linux/6.1.25-1/arch/arm/boot/dts/bcm2711-rpi-4-b.dts/#L9

[2] - https://sources.debian.org/src/linux/6.1.25-1/arch/arm/boot/dts/bcm2711-rpi-4-b.dts/#L10

[3] - https://elixir.bootlin.com/linux/v6.1/source/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c#L772

[Cyril Brulebois]

Hi,

James Addison <j...@jp-hosting.net> (2023-05-01):

> Also, the brcmfmac kernel module code mentions[3] that it can load
> board-specific firmware file paths. I'm not yet sure whether that's
> relevant (either now, or in future).

Yeah, both the function you pointed to and the one handling actual
firmware requests seem to know about some alt_fw semantics, with a
fallback. But I'm not diving into that rabbit hole. :)

> Since more files with that pattern are appearing upstream in
> linux-firmware.. yes, slightly reluctantly it does seem that this will
> be needed.

[…]

> I'd generally agree with all that. For robustness, and when it's safe
> to, it'd be nice to resolve both issues (firstly to ensure that the
> correct firmware filename is being requested in these cases -- maybe
> it already is, I'm still trying to determine whether that's a bug --
> and secondly to support spaces in firmware filenames in hw-detect).

Regarding “plans for the future”, it's worth mentioning #1033921, now
cloned as #1035356. While the former is about license acceptance for
some firmware packages specifically (and about to be fixed for bookworm)
the latter is for longer term, with a proposed patch changing the logic
around iterating over firmware filenames. I'm not saying it's going to
solve spaces-in-filenames as it is, I just thought it'd make sense to
mention it as that touches one relevant part of the hw-detect code.

1. https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1035356;filename=duplicate_stdin_for_debconf.diff;msg=45
2. https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1035356;filename=0001-check-missing-firmware-Fix-firmware-license-acceptan.patch;msg=50

[James Addison]

On Mon, 1 May 2023 at 20:03, Cyril Brulebois <ki...@debian.org> wrote:
> James Addison <j...@jp-hosting.net> (2023-05-01):
> > Also, the brcmfmac kernel module code mentions[3] that it can load
> > board-specific firmware file paths. I'm not yet sure whether that's
> > relevant (either now, or in future).
>
> Yeah, both the function you pointed to and the one handling actual
> firmware requests seem to know about some alt_fw semantics, with a
> fallback. But I'm not diving into that rabbit hole. :)

That's a sensible strategy :)

Could either of you (Cyril, Diederik) recommend where I should ask
(and/or clone this bug) to follow up on the firmware filename issue,
given that the filename(s) seem to be generated from the kernel
module?

(as a recap: the brcmfmac module attempts to load a file of the format

"brcmfmac43455-sdio.Raspberry Pi Foundation-Raspberry Pi 4 Model

B.txt" instead of "brcmfmac43455-sdio.txt" -- I saw the same thing
during my install, with string adjustments for brcmfmac43456 and Pi
400)

I think that that's likely to be the cause of the firmware-not-loaded
problems in installation-reports #989593 and #1035392 (that second
report is from me, earlier today). Even with the 'Contents-firmware'
file-to-package mapping, we won't find the relevant firmware file if
the name is wrong.

> Regarding “plans for the future”, it's worth mentioning #1033921, now
> cloned as #1035356. While the former is about license acceptance for
> some firmware packages specifically (and about to be fixed for bookworm)
> the latter is for longer term, with a proposed patch changing the logic
> around iterating over firmware filenames. I'm not saying it's going to
> solve spaces-in-filenames as it is, I just thought it'd make sense to
> mention it as that touches one relevant part of the hw-detect code.

Thank you; yep, I've followed _most_ of that (and arrived back here
again). I will admit that most of what I've cognitively loaded from
it is "this script could use refactoring post-bookworm", and have not
processed the complete details.

Regards,
James

[Cyril Brulebois]

Hi James,

I've just finished a very long debugging session[1], so the following is
really best effort and probably not 100%.

1. https://lore.kernel.org/all/20230428223500.2...@gmail.com/T/#m846b07884ef687d3669654c782aa3b61216f15b7

James Addison <j...@jp-hosting.net> (2023-05-02):

> Could either of you (Cyril, Diederik) recommend where I should ask
> (and/or clone this bug) to follow up on the firmware filename issue,
> given that the filename(s) seem to be generated from the kernel
> module?

It looks to me someone should understand the Linux kernel code, and
possibly where inputs/variables come from (there might be stuff coming
from the DTB, some bootloader thing, etc.), and why spaces show up in
there. Then decide whether the “external” source (if any!) or the kernel
should be adjusted to use more straightforward names.

> Thank you; yep, I've followed _most_ of that (and arrived back here
> again). I will admit that most of what I've cognitively loaded from
> it is "this script could use refactoring post-bookworm", and have not
> processed the complete details.

Yes; my point was really to say “sorry it's _so_ not perfect yet”, but
seeing this kind of things get uncovered is definitely *not* unexpected…

Let's take a step back and check summarize where we come from, so that
the picture is not only clear in my own head. :)


During the bullseye release cycle, I've tried to deal with GPU problems
by adding modalias support (no specific modules in d-i means no messages
in dmesg, meaning we needed something else), to avoid abysmal experience
once reaching the post-install reboot. (And being able to work on that
only late in the release cycle had some impact on the release date…
which is definitely *not* a feeling I wish anyone else to experience!)

During the bookworm release cycle, getting official support for firmware
packages has been basically a solo effort in each and every component
(even if I got some help from firmware package maintainers and members
of some infrastructure teams, you know who you are <3). While Pascal has
been submitting a bunch of patches for hw-detect already, there are
still some gaps to fill. But again, I'll take *not* supporting _some_
use cases right away over risking losing support for _most_ use cases;
that's a no-brainer, especially just days away from the next RC(s), and
from the actual release.

But enough meta-talk now! :)

[James Addison]

Control: retitle -1 hw-detect: firmware file path handling is fragile
Control: clone -1 -2
Control: reassign -2 src:linux
Control: retitle -2 brcmfmac: firmware filename inconsistency with
linux-firmware.git

On Wed, 3 May 2023 at 00:34, Cyril Brulebois <ki...@debian.org> wrote:
>
> James Addison <j...@jp-hosting.net> (2023-05-02):

> It looks to me someone should understand the Linux kernel code, and
> possibly where inputs/variables come from (there might be stuff coming
> from the DTB, some bootloader thing, etc.), and why spaces show up in
> there. Then decide whether the “external” source (if any!) or the kernel
> should be adjusted to use more straightforward names.

Thanks - OK.


I think that the vendor name is coming from a DMI fallback:

https://sources.debian.org/src/linux/6.1.25-1/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c/?hl=487#L487

Whether the model name is from DMI or from the DTS file's 'model'
field is less clear to me:

https://sources.debian.org/src/linux/6.1.25-1/arch/arm/boot/dts/bcm2711-rpi-400.dts/#L7

I'll try to rebuild the kernel module and test some changes 'soon'
(within the next few days, most likely).


Also, to clarify an error/thinko in my previous message: the style of
filename we agreed to map to, and that both linux-firmware.git and the
RPi operating system distro[1] use, is
"brcmfmac43456-sdio.raspberrypi,400.txt" (not the short-format
"brcmfmac43455-sdio.txt" that I mentioned). We should include
specificity for vendor and model in the filename, all lowercased, and
without spaces.

The RPi 400 model firmware files are not yet represented in
linux-firmware.git, although they do appear in the RPi operating
system distro.

Thanks,
James

[1] - http://archive.raspberrypi.org/debian/dists/bullseye/main/binary-arm64/Packages

[Cyril Brulebois]

Hi,

James Addison <j...@jp-hosting.net> (2023-05-03):

> I think that the vendor name is coming from a DMI fallback:
> https://sources.debian.org/src/linux/6.1.25-1/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c/?hl=487#L487

I smiled. :)

The (still quick) glance I had earlier stopped when I reached “DMI”
which I wasn't sure was valid for ARM devices. :)

> Whether the model name is from DMI or from the DTS file's 'model'
> field is less clear to me:
>
> https://sources.debian.org/src/linux/6.1.25-1/arch/arm/boot/dts/bcm2711-rpi-400.dts/#L7
>
> I'll try to rebuild the kernel module and test some changes 'soon'
> (within the next few days, most likely).

I'm not sure how many things rely on this particular model field in the
DT (and how badly it could break the boot sequence among other things),
but it might be much quicker for you to confirm whether the DTB is
relevant, before thinking about patching the module, and figuring out
whether that involves vmlinuz, the initramfs, etc.

In a linux tree (maybe prepared from the src:linux git tree, cf. kernel
handbook for details), with a proper .config in place (e.g. copied from
your /boot):

# you might need some linux build-deps, but that one is for
# crossbuilding from another arch:
sudo apt-get install gcc-aarch64-linux-gnu
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- dtbs

Then make your change in the DTS, re-run, you should see only a single
file get updated, deploy it in /boot/firmware, profit (hopefully).

(Beware of the raspi-firmware hook, that will redeploy DTBs from the
linux-image packages when you least expect it; but that becomes an ally
to scratch your local test files and restore the packaged ones once you
keep its existence in mind.)

Another way can be to use device-tree-compiler's dtc to turn the DTB
into a DTS, run sed, then run dtc again to get an updated DTB from the
updated DTS.

> Also, to clarify an error/thinko in my previous message: the style of
> filename we agreed to map to, and that both linux-firmware.git and the
> RPi operating system distro[1] use, is
> "brcmfmac43456-sdio.raspberrypi,400.txt" (not the short-format
> "brcmfmac43455-sdio.txt" that I mentioned). We should include
> specificity for vendor and model in the filename, all lowercased, and
> without spaces.

I didn't comment on that part in my previous reply but that definitely
looks better (or at least what I'd naïvely expect to be needed, i.e.
supporting possible per-model settings).

> The RPi 400 model firmware files are not yet represented in
> linux-firmware.git, although they do appear in the RPi operating
> system distro.

So many things that are there and only there…

[James Addison]

On Wed, 3 May 2023 at 03:02, Cyril Brulebois <ki...@debian.org> wrote:
> James Addison <j...@jp-hosting.net> (2023-05-03):
> > I think that the vendor name is coming from a DMI fallback:
> > https://sources.debian.org/src/linux/6.1.25-1/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c/?hl=487#L487
>
> I smiled. :)
>
> The (still quick) glance I had earlier stopped when I reached “DMI”
> which I wasn't sure was valid for ARM devices. :)

Yep, it's very possible that I'm on the wrong track with that thought
(can you tell I don't know much about device drivers and hardware?
:)).

The vendor-string only appears once[1] in src:linux, and that's in a
YAML file that I don't see referenced within the build. But I suppose
there are other places (nvram?) where the value could have originated
from. My hope is that there's a relatively-hardcoded value somewhere
that we can read from, so that we don't have to worry about any
configuration changes applied locally per-system.

Either way: ignore me for a while, I'll go and use the instructions
you provided later in your message to try to figure out the source of
these values (thank you!).

[1] - https://sources.debian.org/src/linux/6.1.25-1/Documentation/devicetree/bindings/vendor-prefixes.yaml/?hl=1057#L1057

[Diederik de Haas]

On Wednesday, 3 May 2023 03:41:05 CEST James Addison wrote:
> I think that the vendor name is coming from a DMI fallback:
>
> https://sources.debian.org/src/linux/6.1.25-1/drivers/net/wireless/broadcom/
> brcm80211/brcmfmac/common.c/?hl=487#L487
>
> Whether the model name is from DMI or from the DTS file's 'model'
> field is less clear to me:
>
> https://sources.debian.org/src/linux/6.1.25-1/arch/arm/boot/dts/bcm2711-rpi-> 400.dts/#L7

AFAIK the most important thing is the "compatible" string.
Next to "DMI" there was also mention of "OF", which stand for Open Firmware
which is (essentially?) the same as Device Tree

> brcmfmac43455-sdio.Raspberry Pi Foundation-Raspberry Pi 4 Model B.txt

This looks just plain weird ... and not for the spaces.
For the healthiness of the discussion, I chose to ignore that the previous
time ;-P
I'd double check whether you actually see that line in your own dmesg output,
before spending time to find some logic in that name.

> Also, to clarify an error/thinko in my previous message: the style of
> filename we agreed to map to, and that both linux-firmware.git and the

Probably my fault, but I don't think it's relevant "what we agree to".
We need to use what the kernel uses of which I suspect there's a (strong)
correlation with what's used in the linux-firmware upstream repo.

> RPi operating system distro[1] use, is

They do their own thing which may or may not have a correlation with what the
rest of the world does.

> "brcmfmac43456-sdio.raspberrypi,400.txt" (not the short-format
> "brcmfmac43455-sdio.txt" that I mentioned). We should include
> specificity for vendor and model in the filename, all lowercased, and
> without spaces.

I realize the spaces are 'annoying' and I fully agree that it shouldn't be
tried to get fixed for Bookworm as it more likely breaks then fixes things.
But unless you/we manage to convince *upstream* that there is a bug of some
sort (and they subsequently change it), what we like/want is not important.
We need to follow what upstream does/uses.

> The RPi 400 model firmware files are not yet represented in
> linux-firmware.git, although they do appear in the RPi operating
> system distro.

I doubt they ever will be upstreamed ...

[James Addison]

Mystery may be (partially) solved. Responses inline below.

On Wed, 3 May 2023 at 15:17, Diederik de Haas <didi....@cknow.org> wrote:
>
> On Wednesday, 3 May 2023 03:41:05 CEST James Addison wrote:
> > I think that the vendor name is coming from a DMI fallback:

> > ...
> > https://sources.debian.org/src/linux/6.1.25-1/arch/arm/boot/dts/bcm2711-rpi-400.dts/#L7

>
> AFAIK the most important thing is the "compatible" string.
> Next to "DMI" there was also mention of "OF", which stand for Open Firmware
> which is (essentially?) the same as Device Tree

> ...

> I'd double check whether you actually see that line in your own dmesg output,
> before spending time to find some logic in that name.

Agreed. The 'compatible' string is what seems intended for inclusion
into the fw filename request - by the driver authors,
linux-firmware.git, ourselves, and the RPi operating system.

After editing and rebuilding the Device Tree (DTS) files, and
deploying those changes to the system, I can confirm that adjusting
the 'model' field value in there has no effect on the requested fw
filename.

The system's dmesg includes this line:

DMI: Raspberry Pi Foundation Raspberry Pi 400/Raspberry Pi 400, BIOS
UEFI Firmware v1.34 1 2/16/2022

As Cyril said though.. this can't (shouldn't) be genuine DMI. So
what's going on?

It seems that the cause may be this:

The default settings within the EDK2 UEFI, under "Device Manager" ->
"Raspberry Pi Configuration" -> "Advanced Configuration" contained a
key labeled "System Table Selection" that was set to "ACPI". Changing
that value to "Devicetree" and then booting caused the correct,
expected fw filename to be requested:

firmware: failed to load brcm/brcmfmac43456-sdio.raspberrypi,400.bin (-2)

> Probably my fault, but I don't think it's relevant "what we agree to".
> We need to use what the kernel uses of which I suspect there's a (strong)
> correlation with what's used in the linux-firmware upstream repo.

Agreed here too - we can (and should) only make adjustments that are
acceptable and compatible for adjacent components. I think we're
aligned with upstream here, it's simply that some other component --
and at the moment, that appears to me to be the EDK2 UEFI -- is
producing an unusual effect.

Cheers,
James

[Diederik de Haas]

On Wednesday, 3 May 2023 17:18:42 CEST James Addison wrote:
> The system's dmesg includes this line:
>
> DMI: Raspberry Pi Foundation Raspberry Pi 400/Raspberry Pi 400, BIOS
> UEFI Firmware v1.34 1 2/16/2022
>
> As Cyril said though.. this can't (shouldn't) be genuine DMI. So
> what's going on?
>
> It seems that the cause may be this:
>
> The default settings within the EDK2 UEFI, under "Device Manager" ->
> "Raspberry Pi Configuration" -> "Advanced Configuration" contained a
> key labeled "System Table Selection" that was set to "ACPI".

Ah, EDK2/UEFI/ACPI, that's an important piece that I didn't realize/know.

And I also don't have knowledge of or experience with.
I (therefor) also don't know if or to which extend DeviceTree plays a role
here as I _think_ you use either EDK2/ACPI *or* DeviceTree.

[Cyril Brulebois]

Hi,

James Addison <j...@jp-hosting.net> (2023-05-03):

> After editing and rebuilding the Device Tree (DTS) files, and
> deploying those changes to the system, I can confirm that adjusting
> the 'model' field value in there has no effect on the requested fw
> filename.

Did those modifications stay in place once you switched to Device Tree
in your bootloader configuration? Just wondering whether you tested two
cumulative changes (DTS tweaks + switch from ACPI), or independent ones
(DTS tweaks, then switch from ACPI but using pristine DTB files).

> The system's dmesg includes this line:
>
> DMI: Raspberry Pi Foundation Raspberry Pi 400/Raspberry Pi 400, BIOS
> UEFI Firmware v1.34 1 2/16/2022
>
> As Cyril said though.. this can't (shouldn't) be genuine DMI.

I know nothing about hardware, it only seemed like a red flag to me,
that's why I chose not to dig deeper at the time.

> The default settings within the EDK2 UEFI, under "Device Manager" ->
> "Raspberry Pi Configuration" -> "Advanced Configuration" contained a
> key labeled "System Table Selection" that was set to "ACPI". Changing
> that value to "Devicetree" and then booting caused the correct,
> expected fw filename to be requested:
>
> firmware: failed to load brcm/brcmfmac43456-sdio.raspberrypi,400.bin (-2)

I don't have any Pi 400 and haven't been following what the stock
configuration is (and sorry I didn't read the whole backstory)… if EDF2
UEFI comes by default, or is recommended, or fixes/works around bugs,
and in the end is expected to be relevant and widely used, and if ACPI
is indeed some kind of default setup, it would be best if we were to
support that.

I suppose that would mean either having the relevant files/symlinks in
the firmware package *and* d-i support for it (hw-detect limitations…);
or have some on-the-fly conversion in the Linux module so that it ends
up requesting files that are actually in the firmware package, and that
d-i can work with, without requiring any changes?

[James Addison]

On Wed, 3 May 2023 at 16:49, Cyril Brulebois <ki...@debian.org> wrote:
> James Addison <j...@jp-hosting.net> (2023-05-03):
> > After editing and rebuilding the Device Tree (DTS) files, and
> > deploying those changes to the system, I can confirm that adjusting
> > the 'model' field value in there has no effect on the requested fw
> > filename.
>
> Did those modifications stay in place once you switched to Device Tree
> in your bootloader configuration? Just wondering whether you tested two
> cumulative changes (DTS tweaks + switch from ACPI), or independent ones
> (DTS tweaks, then switch from ACPI but using pristine DTB files).

That was tested cumulatively, yep - applied the DTS tweaks, found no
change, and then updated the UEFI setting from ACPI to Devicetree,
resulting in the expected fw requests.

Since then I've reverted the DTS tweaks, and the correct behaviour continues.

After that I reverted the UEFI setting back to ACPI briefly. I forget
what I was checking, but the problem reappeared, and now I'm back to
the expected behaviour (no spaces in the fw filenames) with the
Devicetree setting.

> I don't have any Pi 400 and haven't been following what the stock
> configuration is (and sorry I didn't read the whole backstory)… if EDF2
> UEFI comes by default, or is recommended, or fixes/works around bugs,
> and in the end is expected to be relevant and widely used, and if ACPI
> is indeed some kind of default setup, it would be best if we were to
> support that.

I'd defer to people with more familiarity of the ecosystem on these
kind of questions, although am also keen to learn more.

Some thoughts:

* Maybe there's a bug to report in the upstream Linux brcmfmac
driver here; are there better alternatives than DMI that it could use
to determine fallback filenames? (again, I'm not sure, but can follow
up on that)
* Perhaps Devicetree is a better default in EDK2 for ARM systems?
(that wouldn't solve the root cause, though)
* Alternatively, if EDK2/RPI4-UEFI became Debian-packaged (excluding
the brcm firmware, because that's already in raspi-firmware), _and_
could be installed on the ESP partition by d-i (it's beyond my
experience to say whether that's a good idea...), then perhaps it
could be preconfigured (or d-i could request) Devicetree at
install-time.

If & when attempting this again - it could be a while, this took some
energy - then I would probably experiment with u-boot as a comparison.

> I suppose that would mean either having the relevant files/symlinks in
> the firmware package *and* d-i support for it (hw-detect limitations…);
> or have some on-the-fly conversion in the Linux module so that it ends
> up requesting files that are actually in the firmware package, and that
> d-i can work with, without requiring any changes?

At the moment, I think that fixing this in the brcmfmac driver would
resolve the problem in a bootloader-agnostic way, so that seems worth
exploring.

Symlinks seem like they'd be a reasonable short-term workaround in our
packaging - but likely maintainer discretion on that one, as usual (if
that were me, it would help to know that it would be a temporary
measure while other problems were being resolved).

(sorry for what I think may be an overly-large reply list here - I'd
prefer that than to have anyone miss some hopefully-relevant details)

[James Addison]

Control: unmerge 1029843 1030519
Control: reassign 1029843 src:linux
Control: retitle 1029843 brcmfmac: requested firmware filename
inconsistent with linux-firmware.git on non-devicetree systems
Control: affects 1029843 firmware-brcm80211 raspi-firmware

Dear Maintainer,

This bugreport relates to the brcmfmac kernel module and the firmware
filename that it probes for during load.

It looks like this may have been a cause of some problems reported in
bugs #989593, #1029843 (this bug) and #1035392.

The last of those three bugs is an installation-report of mine, and as
far as I can tell the problem is that when the affected system (an
RPi) was configured without devicetree support in its UEFI bootloader,
the kernel module was unable to determine a precise filename and used
some fallback logic to determine one approximately here:

https://sources.debian.org/src/linux/6.1.25-1/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c/?hl=487#L487

Please let me know if I can provide any further details to help track this down.

Thank you,
James

[James Addison]

Package: src:linux
Followup-For: Bug #1029843
X-Debbugs-Cc: pe...@akeo.ie, ki...@debian.org, didi....@cknow.org, debia...@lists.debian.org, 102...@bugs.debian.org, 103...@bugs.debian.org, 989...@bugs.debian.org, debia...@lists.debian.org
Control: retitle -1 brcmfmac: requested firmware filename inconsistent with linux-firmware.git on non-devicetree systems

Thanks, Pete.

I added a note[1] on the rpi4-uefi.dev GitHub repository, and from one of your
fellow contributors' responses, it seems that in fact the filename-with-spaces
format _is_ referenced from linux-firmware.git, in a 'WHENCE' file that is
used to create symlinks (I hadn't been aware of that previously).

As a result: I feel that maybe this bugreport is not valid.


I suppose that some of the confusion stemmed from the fact that a single binary
of a kernel module in combination with a single physical hardware device probed
different firmware filenames at runtime depending on the context (ACPI vs
Devicetree, in this case).

(it's code, so yep, I get that it's technically _possible_ for that to happen,
and perhaps it's useful to workaround limitations of existing standards, but
it's not clear to me whether that's necessary here)

> Note that, in case you think there may be something that we can improve
> in the SMBIOS data reported by the UEFI firmware (which is currently
> generated from the source code at [1], with the full output from a
> Raspberry Pi 4, from UEFI Shell's smbiosview command at [2]) we can look
> into updating the UEFI firmware to alter the data we output.

Thank you - I'll take a look at those to learn more.

[1] - https://github.com/pftf/RPi4/issues/76#issuecomment-1533295773

[Diederik de Haas]

On Thursday, 4 May 2023 01:03:08 CEST Diederik de Haas wrote:
> Control: affects -1 -raspi-firmware

That it affects a RPi device does NOT mean it affects the raspi-firmware package,
so I removed that field (hopefully)

[Diederik de Haas]

Control: reassign -1 firmware-brcm80211
Control: affects -1 -raspi-firmware
Control: retitle -1 Missing symlinks for RPi 4 (to brcmfmac43455-sdio.raspberrypi,4-model-b.txt)

On Thursday, 4 May 2023 00:21:25 CEST James Addison wrote:
> I added a note[1] on the rpi4-uefi.dev GitHub repository, and from one of
> your fellow contributors' responses, it seems that in fact the
> filename-with-spaces format _is_ referenced from linux-firmware.git, in a
> 'WHENCE' file that is used to create symlinks (I hadn't been aware of that
> previously).

And that makes it a firmware-brcm80211 issue and now it all does make sense
as it now all does tie together :-)
So while upstream does define the link from what I earlier called 'weird' name
to brcmfmac43455-sdio.raspberrypi,4-model-b.txt, the Debian firmware-brcm80211
package does not define that link and is therefor missing.

> As a result: I feel that maybe this bugreport is not valid.

It is actually a valid bug report, although the discussion got rather messy
and I've therefor dropped the whole list of other bug reports.
I'm not even sure which bug report is exactly about what, but my current
best guess is that this is the right bug for this issue.
(I was about to question why you'd reassigned it to src:linux)

> [1] - https://github.com/pftf/RPi4/issues/76#issuecomment-1533295773

[Cyril Brulebois]

Hi,

Diederik de Haas <didi....@cknow.org> (2023-05-04):

> On Thursday, 4 May 2023 00:21:25 CEST James Addison wrote:
> > I added a note[1] on the rpi4-uefi.dev GitHub repository, and from
> > one of your fellow contributors' responses, it seems that in fact
> > the filename-with-spaces format _is_ referenced from
> > linux-firmware.git, in a 'WHENCE' file that is used to create
> > symlinks (I hadn't been aware of that previously).
>
> And that makes it a firmware-brcm80211 issue and now it all does make
> sense as it now all does tie together :-)

Great, that's what it looked like to me but I was afraid I could have
misunderstood the situation and I didn't want to digress in a wrong
direction…

> So while upstream does define the link from what I earlier called
> 'weird' name to brcmfmac43455-sdio.raspberrypi,4-model-b.txt, the Debian
> firmware-brcm80211 package does not define that link and is therefor
> missing.

Adding the links will at least make those paths shows up in the
Contents-firmware indices generated by debian-cd. Those contain 3
“columns”: path, package, component (the current format string is
"%-55s %s %s\n").

Even if hw-detect didn't misbehave because of spaces in filenames (i.e.
the way the list of missing files is constructed, which I've been
assuming is one of the main issue here, but I didn't dive into it
because that's not getting rewritten for Bookworm anyway)… it wouldn't
be able to perform the required lookup, given how it extracts those
“columns” from those indices.

(Looking at regular Contents file again, I see there's nothing done
specifically — like some kind of escaping — for paths like
“/etc/testssl/DST Root CA X3.txt” in the testssl.sh package; so I guess
it wouldn't be crazy to just change nothing in debian-cd, and have
hw-detect deal with spotting package and component at the end of the
line, reading the whole beginning as a path; of course, if someone goes
as far as including spaces at the end of some firmware filename, we'll
have to just change the format… Cc-ing debian-cd@ for information.)

Anyway, you know how stupidly pragmatic I can be…

For Bookworm, given we expect the firmware package to be adjusted to
include those symlinks, what if hw-detect had some little cheatsheet,
turning the space-powered filenames into their normal counterparts right
off the bat (while going through the dmesg lines), so that hw-detect
would:
- not split those into smaller parts, therefore building a list of
paths correctly;
- additionally succeed in performing the firmware file to firmware
package (and component) lookup;
- deploy the relevant firmware package;

… while the linux kernel would ultimately request the space-powered
filenames again, this time finding the symlinks that the updated package
would ship, being happy, no longer complaining, and hw-detect would give
a green light and carry on.

Embedding a little symlinks → files mapping for one single package,
that's really not expected to change too much this close to the release…
looks like (1) a very ugly kludge, granted; but also (2) a very small
price to pay to get immediate support for that particular way of booting
Pi devices, without waiting on any major, post-release rewrite.


If that looks fine to you, feel free to clone this against hw-detect
with the symlinks → files mapping. Cc-ing debian-boot@ for information
as well.

[Diederik de Haas]

Control: block -1 1035505

On Thursday, 4 May 2023 01:41:12 CEST Cyril Brulebois wrote:
> Diederik de Haas <didi....@cknow.org> (2023-05-04):

> > And that makes it a firmware-brcm80211 issue and now it all does make
> > sense as it now all does tie together :-)
>
> Great, that's what it looked like to me but I was afraid I could have
> misunderstood the situation and I didn't want to digress in a wrong
> direction…
>
> > So while upstream does define the link from what I earlier called
> > 'weird' name to brcmfmac43455-sdio.raspberrypi,4-model-b.txt, the Debian
> > firmware-brcm80211 package does not define that link and is therefor
> > missing.
>
> Adding the links will at least make those paths shows up in the
> Contents-firmware indices generated by debian-cd. Those contain 3
> “columns”: path, package, component (the current format string is
> "%-55s %s %s\n").

Assuming the '55' stands for max 55 chars, that could be an issue?

> Even if hw-detect didn't misbehave because of spaces in filenames (i.e.

It turns out that spaces (and or backslashes to escape them) seems to be an
issue for the Debian scripts used to make the Debian firmware-nonfree packages
too. See https://bugs.debian.org/1035505 for details.
Once that is fixed, I can submit my MR to add those missing symlinks.

> For Bookworm, given we expect the firmware package to be adjusted to
> include those symlinks, what if hw-detect had some little cheatsheet,

Seems doable. I'm not going to spend time trying to make that though.
I know virtually nothing about d-i/hw-detect internals, so it seems very
unwise for me to even try it.
Given the (specific) subject at hand, you won't be surprised that there's also
a motivational issue ;-)

Cheers,
Diederik

[Cyril Brulebois]

Hi,

Diederik de Haas <didi....@cknow.org> (2023-05-04):

> Assuming the '55' stands for max 55 chars, that could be an issue?

That's not how format strings work. :)

That happily overflows:

$ printf "%-10s and the rest of the line\n" kibi
kibi and the rest of the line

$ printf "%-10s and the rest of the line\n" "Diederik de Haas"
Diederik de Haas and the rest of the line

> It turns out that spaces (and or backslashes to escape them) seems to
> be an issue for the Debian scripts used to make the Debian
> firmware-nonfree packages too. See https://bugs.debian.org/1035505 for
> details. Once that is fixed, I can submit my MR to add those missing
> symlinks.

Oh, d-i isn't the only one expecting non-crazy paths! :)

> Seems doable. I'm not going to spend time trying to make that though.
> I know virtually nothing about d-i/hw-detect internals, so it seems
> very unwise for me to even try it.
> Given the (specific) subject at hand, you won't be surprised that
> there's also a motivational issue ;-)

I was merely writing it out so that it could be sanity-checked, I wasn't
suggesting you would be the one to implement that. (Instead, I was
implicitly volunteering myself…)

[James Addison]

Package: firmware-brcm80211
Followup-For: Bug #1029843
X-Debbugs-Cc: ki...@debian.org, didi....@cknow.org, debia...@lists.debian.org, pe...@akeo.ie

On Mon, 1 May 2023 11:18:03 +0100, James Addison <j...@jp-hosting.net> wrote:
> > Diederik de Haas <didi....@cknow.org> (2023-04-30):
> > > And that's exactly what happens or will happen. Even though the RPi4 filename
> > > doesn't contain spaces, there are several in the `brcm` directory that do.
> > > I didn't check other directories, but I'd expect that filenames with a space is
> > > NOT an anomaly.
>

> Since more files with that pattern are appearing upstream in
> linux-firmware.. yes, slightly reluctantly it does seem that this will
> be needed.

FWIW: After learn the root cause of the spaces-in-filenames problem for
packages derived from linux-firmware.git -- that is, the contents of the
'WHENCE' file in linux-firmware.git -- in fact the RPi4 is the only affected[1]
firmware currently.

(that surprised me, but does seem to be the case. I'm writing to counteract
any sense that the proposed patch[2] could affect and fix many firmwares. it
won't, at least not today)

[1] - https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/WHENCE#n2708

[2] - https://salsa.debian.org/kernel-team/firmware-nonfree/-/merge_requests/65

[Diederik de Haas]

On Monday, 8 May 2023 14:08:14 CEST James Addison wrote:
> On Mon, 1 May 2023 11:18:03 +0100, James Addison <j...@jp-hosting.net> wrote:
> > > Diederik de Haas <didi....@cknow.org> (2023-04-30):
> > > > And that's exactly what happens or will happen. Even though the RPi4
> > > > filename doesn't contain spaces, there are several in the `brcm`
> > > > directory that do. I didn't check other directories, but I'd expect
> > > > that filenames with a space is NOT an anomaly.
> >
> > Since more files with that pattern are appearing upstream in
> > linux-firmware.. yes, slightly reluctantly it does seem that this will
> > be needed.
>
> FWIW: After learn the root cause of the spaces-in-filenames problem for
> packages derived from linux-firmware.git -- that is, the contents of the
> 'WHENCE' file in linux-firmware.git -- in fact the RPi4 is the only
> affected[1] firmware currently.

Triggered by your statement, I did a VERY crude search for spaces
in "File: " or "Link: " lines in the WHENCE file:

diederik@bagend:~/dev/kernel.org/linux-firmware$ grep -E "^Link: .* .* -> .*" WHENCE
Link: brcm/brcmfmac43455-sdio.Raspberry\ Pi\ Foundation-Raspberry\ Pi\ 4\ Model\ B.txt -> brcmfmac43455-sdio.raspberrypi,4-model-b.txt
Link: brcm/brcmfmac43455-sdio.Raspberry\ Pi\ Foundation-Raspberry\ Pi\ Compute\ Module\ 4.txt -> brcmfmac43455-sdio.raspberrypi,4-model-b.txt
Link: nvidia/gm206/acr/bl.bin -> ../../gm200/acr/bl.bin
diederik@bagend:~/dev/kernel.org/linux-firmware$ grep -E "^File: .* .*" WHENCE
File: "brcm/brcmfmac43241b4-sdio.Intel Corp.-VALLEYVIEW C0 PLATFORM.txt"
File: "brcm/brcmfmac43340-sdio.ASUSTeK COMPUTER INC.-TF103CE.txt"
File: "brcm/brcmfmac43430a0-sdio.ONDA-V80 PLUS.txt"
File: "brcm/brcmfmac43455-sdio.MINIX-NEO Z83-4.txt"
File: "brcm/brcmfmac4356-pcie.Intel Corporation-CHERRYVIEW D1 PLATFORM.txt"
File: "brcm/brcmfmac4356-pcie.Xiaomi Inc-Mipad2.txt"

The last "Link: " line can be ignored due to being too crude ...
but it does appear that it ONLY exists in the `brcm` directory ...

> (that surprised me, but does seem to be the case. I'm writing to counteract
> any sense that the proposed patch[2] could affect and fix many firmwares.
> it won't, at least not today)
>

> [2] -
> https://salsa.debian.org/kernel-team/firmware-nonfree/-/merge_requests/65

https://lore.kernel.org/linux-firmware/20230301-fixes-and-compr...@gmail.com/
seems related as f.e. 1 patch deals with the inconsistent " " vs "\ ".

While I was inclined based on my findings above to mark it as an anomaly,
that patch set seems to indicate that the spaces won't be removed in
the future, just that its use would probably more consistent.

[James Addison]

Ah, okie doke. Thanks for catching those.

> The last "Link: " line can be ignored due to being too crude ...
> but it does appear that it ONLY exists in the `brcm` directory ...
>
> > (that surprised me, but does seem to be the case. I'm writing to counteract
> > any sense that the proposed patch[2] could affect and fix many firmwares.
> > it won't, at least not today)
> >
> > [2] -
> > https://salsa.debian.org/kernel-team/firmware-nonfree/-/merge_requests/65
>
> https://lore.kernel.org/linux-firmware/20230301-fixes-and-compr...@gmail.com/
> seems related as f.e. 1 patch deals with the inconsistent " " vs "\ ".
>
> While I was inclined based on my findings above to mark it as an anomaly,
> that patch set seems to indicate that the spaces won't be removed in
> the future, just that its use would probably more consistent.

Ok, thanks again; perhaps it's worthwhile waiting a little longer for
upstream to decide on the preferred line format(s) they'll accept.