Hi, James Addison <jay@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 Cheers, -- Cyril Brulebois (kibi@debian.org) <https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
Attachment:
signature.asc
Description: PGP signature