Bug#1029843: live-boot: Devices Requiring Firmware: multiple requested files in single line overlapping / special characters
On Mon, 1 May 2023 at 03:00, Cyril Brulebois <kibi@debian.org> wrote:
> Diederik de Haas <didi.debian@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.debian@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 <kibi@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
Reply to: