netdev - Re: [PATCH] brcmfmac: of: Use board compatible string for board type

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Fri, 6 Jan 2023 14:20:36 +0200
From:   "Ivan T. Ivanov" <iivanov@...e.de>
To:     Hector Martin <marcan@...can.st>
Cc:     aspriel@...il.com, franky.lin@...adcom.com,
        hante.meuleman@...adcom.com, rmk+kernel@...linux.org.uk,
        kvalo@...nel.org, davem@...emloft.net, devicetree@...r.kernel.org,
        edumazet@...gle.com, krzysztof.kozlowski+dt@...aro.org,
        kuba@...nel.org, pabeni@...hat.com, robh+dt@...nel.org,
        linux-arm-kernel@...ts.infradead.org,
        linux-wireless@...r.kernel.org, netdev@...r.kernel.org,
        brcm80211-dev-list.pdl@...adcom.com,
        SHA-cyfmac-dev-list@...ineon.com
Subject: Re: [PATCH] brcmfmac: of: Use board compatible string for board type

On 01-06 21:13, Hector Martin wrote:

> 
> On 2023/01/06 18:27, Hector Martin wrote:
> > On 2023/01/06 16:27, Ivan T. Ivanov wrote:
> >> When "brcm,board-type" is not explicitly set in devicetree
> >> fallback to board compatible string for board type.
> >>
> >> Some of the existing devices rely on the most compatible device
> >> string to find best firmware files, including Raspberry PI's[1].
> >>
> >> Fixes: 7682de8b3351 ("wifi: brcmfmac: of: Fetch Apple properties")
> >>
> >> [1] https://bugzilla.opensuse.org/show_bug.cgi?id=1206697#c13
> >>
> >> Signed-off-by: Ivan T. Ivanov <iivanov@...e.de>
> > 
> > The existing code already falls back to the compatible string, *as long
> > as there is no board_type set already*.
> > 
> > As far as I can tell, the only way the board_type can get another value
> > first is if it comes from DMI. This behavior was inadvertently changed
> > by commit 7682de8b3351 (since I was not expecting platforms to have
> > *both* DT and DMI information).
> > 
> > I'm guessing the Raspberry Pi is one such platform, and
> > `/sys/devices/virtual/dmi` exists? Hybrid UEFI+ACPI+DT platform I take it?
> > 
> > If so, your commit description should probably be something like:
> > 
> > ===
> > brcmfmac: Prefer DT board type over DMI board type
> > 
> > The introduction of support for Apple board types inadvertently changed
> > the precedence order, causing hybrid ACPI+DT platforms to look up the
> > firmware using the DMI information instead of the device tree compatible
> > to generate the board type. Revert back to the old behavior,
> > as affected platforms use firmwares named after the DT compatible.
> > 
> > Fixes: 7682de8b3351 ("wifi: brcmfmac: of: Fetch Apple properties")
> > ===
> > 
> > An also add a Cc: stable@...r.kernel.org to make sure this gets backported.
> > 
> > With the fixed description,
> > 
> > Reviewed-by: Hector Martin <marcan@...can.st>
> > 
> > - Hector
> 
> Looking into this a bit more from what was mentioned in the linked bug,
> the DMI data comes from the SMBIOS table. We don't have that on Apple
> platforms even though we also boot via U-Boot+EFI, but I'm guessing you
> build U-Boot with CONFIG_GENERATE_SMBIOS_TABLE and provide that stuff in
> the DT?

Yes, that is the way in openSUSE case.

> So s/ACPI/SMBIOS/ would be more accurate in the commit message.

Sure, I will rewrite commit message and repost.

Thanks!