Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 6 Jan 2023 14:20:36 +0200
From:   "Ivan T. Ivanov" <iivanov@suse.de>
To:     Hector Martin <marcan@marcan.st>
Cc:     aspriel@gmail.com, franky.lin@broadcom.com,
        hante.meuleman@broadcom.com, rmk+kernel@armlinux.org.uk,
        kvalo@kernel.org, davem@davemloft.net, devicetree@vger.kernel.org,
        edumazet@google.com, krzysztof.kozlowski+dt@linaro.org,
        kuba@kernel.org, pabeni@redhat.com, robh+dt@kernel.org,
        linux-arm-kernel@lists.infradead.org,
        linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
        brcm80211-dev-list.pdl@broadcom.com,
        SHA-cyfmac-dev-list@infineon.com
Subject: Re: [PATCH] brcmfmac: of: Use board compatible string for board type
Message-ID: <20230106122036.nrx4ssodwymhao7u@suse>
References: <20230106072746.29516-1-iivanov@suse.de>
 <fc6d3c3b-1352-4f75-cbef-d29bd74c0e40@marcan.st>
 <2711b084-5937-7e0f-26d8-67510da3939c@marcan.st>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2711b084-5937-7e0f-26d8-67510da3939c@marcan.st>
Precedence: bulk

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@suse.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@vger.kernel.org to make sure this gets backported.
> > 
> > With the fixed description,
> > 
> > Reviewed-by: Hector Martin <marcan@marcan.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!