Re: [PATCH v1 2/4] brcmfmac: pcie: Add IDs/properties for BCM4355

[Hector Martin]

On 04/01/2023 22.35, Arend van Spriel wrote:
> On 1/4/2023 11:01 AM, 'Hector Martin' via BRCM80211-DEV-LIST,PDL wrote:
>> This chip is present on at least these Apple T2 Macs:
>>
>> * hawaii: MacBook Air 13" (Late 2018)
>> * hawaii: MacBook Air 13" (True Tone, 2019)
>>
>> Users report seeing PCI revision ID 12 for this chip, which Arend
>> reports should be revision C2, but Apple has the firmware tagged as
>> revision C1. Assume the right cutoff point for firmware versions is
>> revision ID 11 then, and leave older revisions using the non-versioned
>> firmware filename (Apple only uses C1 firmware builds).
> 
> Reviewed-by: Arend van Spriel <arend.vanspriel@xxxxxxxxxxxx>
>> Signed-off-by: Hector Martin <marcan@xxxxxxxxx>
>> ---
>>   .../net/wireless/broadcom/brcm80211/brcmfmac/pcie.c    | 10 +++++++++-
>>   .../wireless/broadcom/brcm80211/include/brcm_hw_ids.h  |  1 +
>>   2 files changed, 10 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
>> index 3264be485e20..bb4faea0f0b6 100644
>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> 
> [...]
> 
>> @@ -1994,6 +1996,11 @@ static int brcmf_pcie_read_otp(struct brcmf_pciedev_info *devinfo)
>>   	int ret;
>>   
>>   	switch (devinfo->ci->chip) {
>> +	case BRCM_CC_4355_CHIP_ID:
>> +		coreid = BCMA_CORE_CHIPCOMMON;
>> +		base = 0x8c0;
>> +		words = 0xb2;
>> +		break;
>>   	case BRCM_CC_4378_CHIP_ID:
>>   		coreid = BCMA_CORE_GCI;
>>   		base = 0x1120;
> 
> This bit is not described in the commit message. Can you remind me why 
> the driver needs to read OTP?

Apple platforms use a vendor-specific OTP area to store identification
information used to select the right firmware/txcap/clm/nvram blobs. See
6bad3eeab6d3d (already upstream) and the immediately preceding commits
for how this all works.

In principle this should just return gracefully if that part of the OTP
is empty, though when I originally wrote this code we only knew of Apple
platforms using these chips anyway. If you think this might possibly
introduce issues to other platforms using the same chips (e.g. if
reading the OTP fails outright for some reason), we could gate it on the
presence of a valid devinfo->settings->antenna_sku, which would indicate
an Apple platform (since that property is specific to the Apple
firmware-selection process and only populated on those platforms).

- Hector