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;
Message-ID: <fc6d3c3b-1352-4f75-cbef-d29bd74c0e40@marcan.st>
Date:   Fri, 6 Jan 2023 18:27:35 +0900
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:102.0) Gecko/20100101
 Thunderbird/102.6.1
Subject: Re: [PATCH] brcmfmac: of: Use board compatible string for board type
Content-Language: en-US
To:     "Ivan T. Ivanov" <iivanov@suse.de>, aspriel@gmail.com
Cc:     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
References: <20230106072746.29516-1-iivanov@suse.de>
From:   Hector Martin <marcan@marcan.st>
In-Reply-To: <20230106072746.29516-1-iivanov@suse.de>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

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