| Message ID | 20170224122739.1778-1-zajec5@gmail.com (mailing list archive) |
|---|---|
| State | Rejected |
| Delegated to: | Kalle Valo |
| Headers | show |
On 24-2-2017 13:27, Rafał Miłecki wrote: > From: Rafał Miłecki <rafal@milecki.pl> > > 43602a0 uses chip revision 0 compared to 43602a1 with revision 1. In > brcmfmac there is support for 43602a1 and from what I know supporting > 43602a0 would require loading a different firmware. This is not necessarily true. It depends on whether the rom image is different or not and there is no way to tell up front. So if a0 has same rom image as a1 the firmware is compatible and no distinction is needed. This tends to be the case for chips that only change the digit and not the letter in the chip revision. Anyway, I do not know if a0 has different rom image, but the a0 was never sold so there is no harm in keeping it as is. Regards, Arend > Signed-off-by: Rafał Miłecki <rafal@milecki.pl> > --- > drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c > index 6fae4cf3f6ab..2a171479b42b 100644 > --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c > +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c > @@ -60,7 +60,7 @@ BRCMF_FW_NVRAM_DEF(4366C, "brcmfmac4366c-pcie.bin", "brcmfmac4366c-pcie.txt"); > BRCMF_FW_NVRAM_DEF(4371, "brcmfmac4371-pcie.bin", "brcmfmac4371-pcie.txt"); > > static struct brcmf_firmware_mapping brcmf_pcie_fwnames[] = { > - BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43602_CHIP_ID, 0xFFFFFFFF, 43602), > + BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43602_CHIP_ID, 0xFFFFFFFE, 43602), > BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43465_CHIP_ID, 0xFFFFFFF0, 4366C), > BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4350_CHIP_ID, 0x000000FF, 4350C), > BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4350_CHIP_ID, 0xFFFFFF00, 4350), >
On 2017-02-24 14:21, Arend Van Spriel wrote: > On 24-2-2017 13:27, Rafał Miłecki wrote: >> From: Rafał Miłecki <rafal@milecki.pl> >> >> 43602a0 uses chip revision 0 compared to 43602a1 with revision 1. In >> brcmfmac there is support for 43602a1 and from what I know supporting >> 43602a0 would require loading a different firmware. > > This is not necessarily true. It depends on whether the rom image is > different or not and there is no way to tell up front. So if a0 has > same > rom image as a1 the firmware is compatible and no distinction is > needed. > This tends to be the case for chips that only change the digit and not > the letter in the chip revision. Anyway, I do not know if a0 has > different rom image, but the a0 was never sold so there is no harm in > keeping it as is. Just to be sure (I don't have such a good hardware knowledge): 1) Does ROM image mean some code that is permanently on the device? 2) Does firmware mean code we upload from the host driver? I'm not sure if I understand the rest of your description. AFAIU first you said ROM image tends to be the same on chipset variations using the same letter. If this is so, why we need different firmware for 43602a0 and 43602a1? Or different firmware for 43570a0 and 43570a2? Also if what you said about sharing one ROM image between chip variations using the same letter was correct, shouldn't you expect the same ROM image on 43602a0 and 43602a1? Forgive me if something of this is obvious for you, I just don't have access to any Broadcom internal documentation :)
On 24-2-2017 14:43, Rafał Miłecki wrote: > On 2017-02-24 14:21, Arend Van Spriel wrote: >> On 24-2-2017 13:27, Rafał Miłecki wrote: >>> From: Rafał Miłecki <rafal@milecki.pl> >>> >>> 43602a0 uses chip revision 0 compared to 43602a1 with revision 1. In >>> brcmfmac there is support for 43602a1 and from what I know supporting >>> 43602a0 would require loading a different firmware. >> >> This is not necessarily true. It depends on whether the rom image is >> different or not and there is no way to tell up front. So if a0 has same >> rom image as a1 the firmware is compatible and no distinction is needed. >> This tends to be the case for chips that only change the digit and not >> the letter in the chip revision. Anyway, I do not know if a0 has >> different rom image, but the a0 was never sold so there is no harm in >> keeping it as is. > > Just to be sure (I don't have such a good hardware knowledge): > 1) Does ROM image mean some code that is permanently on the device? > 2) Does firmware mean code we upload from the host driver? Correct. For fullmac chips we select which functionality ends up in ROM. Together with firmware loaded in RAM it comprises the running code on the device. > I'm not sure if I understand the rest of your description. > > AFAIU first you said ROM image tends to be the same on chipset > variations using > the same letter. If this is so, why we need different firmware for > 43602a0 and > 43602a1? Or different firmware for 43570a0 and 43570a2? The "tends to" provides an escape ;-) Things do not always turn out as planned. Apart from the ROM image the differences can be due to different core revisions. > Also if what you said about sharing one ROM image between chip > variations using > the same letter was correct, shouldn't you expect the same ROM image on > 43602a0 > and 43602a1? > > Forgive me if something of this is obvious for you, I just don't have > access to > any Broadcom internal documentation :) Well, to us these things are not always obvious either :-p Regards, Arend
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c index 6fae4cf3f6ab..2a171479b42b 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c @@ -60,7 +60,7 @@ BRCMF_FW_NVRAM_DEF(4366C, "brcmfmac4366c-pcie.bin", "brcmfmac4366c-pcie.txt"); BRCMF_FW_NVRAM_DEF(4371, "brcmfmac4371-pcie.bin", "brcmfmac4371-pcie.txt"); static struct brcmf_firmware_mapping brcmf_pcie_fwnames[] = { - BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43602_CHIP_ID, 0xFFFFFFFF, 43602), + BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43602_CHIP_ID, 0xFFFFFFFE, 43602), BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43465_CHIP_ID, 0xFFFFFFF0, 4366C), BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4350_CHIP_ID, 0x000000FF, 4350C), BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4350_CHIP_ID, 0xFFFFFF00, 4350),