[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20230106122036.nrx4ssodwymhao7u@suse>
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!
Powered by blists - more mailing lists