* [PATCH 4.12 1/2] brcmfmac: don't use 43602a1 firmware for 43602a0 chipset @ 2017-02-24 12:27 Rafał Miłecki 2017-02-24 12:27 ` [PATCH 4.12 2/2] brcmfmac: use more accurate PCIe chip names in fw table Rafał Miłecki 2017-02-24 13:21 ` [PATCH 4.12 1/2] brcmfmac: don't use 43602a1 firmware for 43602a0 chipset Arend Van Spriel 0 siblings, 2 replies; 6+ messages in thread From: Rafał Miłecki @ 2017-02-24 12:27 UTC (permalink / raw) To: Kalle Valo Cc: Arend van Spriel, Franky Lin, Hante Meuleman, Pieter-Paul Giesberts, Franky Lin, linux-wireless, brcm80211-dev-list.pdl, Rafał Miłecki 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. 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), -- 2.11.0 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* [PATCH 4.12 2/2] brcmfmac: use more accurate PCIe chip names in fw table 2017-02-24 12:27 [PATCH 4.12 1/2] brcmfmac: don't use 43602a1 firmware for 43602a0 chipset Rafał Miłecki @ 2017-02-24 12:27 ` Rafał Miłecki 2017-02-24 13:28 ` Arend Van Spriel 2017-02-24 13:21 ` [PATCH 4.12 1/2] brcmfmac: don't use 43602a1 firmware for 43602a0 chipset Arend Van Spriel 1 sibling, 1 reply; 6+ messages in thread From: Rafał Miłecki @ 2017-02-24 12:27 UTC (permalink / raw) To: Kalle Valo Cc: Arend van Spriel, Franky Lin, Hante Meuleman, Pieter-Paul Giesberts, Franky Lin, linux-wireless, brcm80211-dev-list.pdl, Rafał Miłecki From: Rafał Miłecki <rafal@milecki.pl> Many chips have few variants/versions, e.g. BCM4366 can be 4366b1 or 4366c0. Cutting name at the letter isn't a good idea as sometimes we may have e.g. a0 and a1. This is just a cosmetic change, a trivial cleanup. It obviously doesn't change fw filenames as we don't want to break user space. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c index 2a171479b42b..7039f7f09653 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c @@ -46,7 +46,7 @@ enum brcmf_pcie_state { BRCMFMAC_PCIE_STATE_UP }; -BRCMF_FW_NVRAM_DEF(43602, "brcmfmac43602-pcie.bin", "brcmfmac43602-pcie.txt"); +BRCMF_FW_NVRAM_DEF(43602a1, "brcmfmac43602-pcie.bin", "brcmfmac43602-pcie.txt"); BRCMF_FW_NVRAM_DEF(4350, "brcmfmac4350-pcie.bin", "brcmfmac4350-pcie.txt"); BRCMF_FW_NVRAM_DEF(4350C, "brcmfmac4350c2-pcie.bin", "brcmfmac4350c2-pcie.txt"); BRCMF_FW_NVRAM_DEF(4356, "brcmfmac4356-pcie.bin", "brcmfmac4356-pcie.txt"); @@ -55,13 +55,13 @@ BRCMF_FW_NVRAM_DEF(4358, "brcmfmac4358-pcie.bin", "brcmfmac4358-pcie.txt"); BRCMF_FW_NVRAM_DEF(4359, "brcmfmac4359-pcie.bin", "brcmfmac4359-pcie.txt"); BRCMF_FW_NVRAM_DEF(4365B, "brcmfmac4365b-pcie.bin", "brcmfmac4365b-pcie.txt"); BRCMF_FW_NVRAM_DEF(4365C, "brcmfmac4365c-pcie.bin", "brcmfmac4365c-pcie.txt"); -BRCMF_FW_NVRAM_DEF(4366B, "brcmfmac4366b-pcie.bin", "brcmfmac4366b-pcie.txt"); -BRCMF_FW_NVRAM_DEF(4366C, "brcmfmac4366c-pcie.bin", "brcmfmac4366c-pcie.txt"); +BRCMF_FW_NVRAM_DEF(4366b1, "brcmfmac4366b-pcie.bin", "brcmfmac4366b-pcie.txt"); +BRCMF_FW_NVRAM_DEF(4366c0, "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, 0xFFFFFFFE, 43602), - BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43465_CHIP_ID, 0xFFFFFFF0, 4366C), + BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43602_CHIP_ID, 0xFFFFFFFE, 43602a1), + BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43465_CHIP_ID, 0xFFFFFFF0, 4366c0), BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4350_CHIP_ID, 0x000000FF, 4350C), BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4350_CHIP_ID, 0xFFFFFF00, 4350), BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43525_CHIP_ID, 0xFFFFFFF0, 4365C), @@ -73,8 +73,8 @@ static struct brcmf_firmware_mapping brcmf_pcie_fwnames[] = { BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4359_CHIP_ID, 0xFFFFFFFF, 4359), BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4365_CHIP_ID, 0x0000000F, 4365B), BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4365_CHIP_ID, 0xFFFFFFF0, 4365C), - BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4366_CHIP_ID, 0x0000000F, 4366B), - BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4366_CHIP_ID, 0xFFFFFFF0, 4366C), + BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4366_CHIP_ID, 0x0000000F, 4366b1), + BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4366_CHIP_ID, 0xFFFFFFF0, 4366c0), BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4371_CHIP_ID, 0xFFFFFFFF, 4371), }; -- 2.11.0 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH 4.12 2/2] brcmfmac: use more accurate PCIe chip names in fw table 2017-02-24 12:27 ` [PATCH 4.12 2/2] brcmfmac: use more accurate PCIe chip names in fw table Rafał Miłecki @ 2017-02-24 13:28 ` Arend Van Spriel 0 siblings, 0 replies; 6+ messages in thread From: Arend Van Spriel @ 2017-02-24 13:28 UTC (permalink / raw) To: Rafał Miłecki, Kalle Valo Cc: Franky Lin, Hante Meuleman, Pieter-Paul Giesberts, Franky Lin, linux-wireless, brcm80211-dev-list.pdl, Rafał Miłecki On 24-2-2017 13:27, Rafał Miłecki wrote: > From: Rafał Miłecki <rafal@milecki.pl> > > Many chips have few variants/versions, e.g. BCM4366 can be 4366b1 or > 4366c0. Cutting name at the letter isn't a good idea as sometimes we may > have e.g. a0 and a1. As explained in 1/2, the revision may change but if rom image is unchanged the firmware stays compatible. As predicting chip development is impossible initially we choose a common name as entry ID. So if there would come a 4366c1 with incompatible rom image it would be time to change the entry ID. Regards, Arend > This is just a cosmetic change, a trivial cleanup. It obviously doesn't > change fw filenames as we don't want to break user space. > > Signed-off-by: Rafał Miłecki <rafal@milecki.pl> > --- > drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 14 +++++++------- > 1 file changed, 7 insertions(+), 7 deletions(-) > > diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c > index 2a171479b42b..7039f7f09653 100644 > --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c > +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c > @@ -46,7 +46,7 @@ enum brcmf_pcie_state { > BRCMFMAC_PCIE_STATE_UP > }; > > -BRCMF_FW_NVRAM_DEF(43602, "brcmfmac43602-pcie.bin", "brcmfmac43602-pcie.txt"); > +BRCMF_FW_NVRAM_DEF(43602a1, "brcmfmac43602-pcie.bin", "brcmfmac43602-pcie.txt"); > BRCMF_FW_NVRAM_DEF(4350, "brcmfmac4350-pcie.bin", "brcmfmac4350-pcie.txt"); > BRCMF_FW_NVRAM_DEF(4350C, "brcmfmac4350c2-pcie.bin", "brcmfmac4350c2-pcie.txt"); > BRCMF_FW_NVRAM_DEF(4356, "brcmfmac4356-pcie.bin", "brcmfmac4356-pcie.txt"); > @@ -55,13 +55,13 @@ BRCMF_FW_NVRAM_DEF(4358, "brcmfmac4358-pcie.bin", "brcmfmac4358-pcie.txt"); > BRCMF_FW_NVRAM_DEF(4359, "brcmfmac4359-pcie.bin", "brcmfmac4359-pcie.txt"); > BRCMF_FW_NVRAM_DEF(4365B, "brcmfmac4365b-pcie.bin", "brcmfmac4365b-pcie.txt"); > BRCMF_FW_NVRAM_DEF(4365C, "brcmfmac4365c-pcie.bin", "brcmfmac4365c-pcie.txt"); > -BRCMF_FW_NVRAM_DEF(4366B, "brcmfmac4366b-pcie.bin", "brcmfmac4366b-pcie.txt"); > -BRCMF_FW_NVRAM_DEF(4366C, "brcmfmac4366c-pcie.bin", "brcmfmac4366c-pcie.txt"); > +BRCMF_FW_NVRAM_DEF(4366b1, "brcmfmac4366b-pcie.bin", "brcmfmac4366b-pcie.txt"); > +BRCMF_FW_NVRAM_DEF(4366c0, "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, 0xFFFFFFFE, 43602), > - BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43465_CHIP_ID, 0xFFFFFFF0, 4366C), > + BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43602_CHIP_ID, 0xFFFFFFFE, 43602a1), > + BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43465_CHIP_ID, 0xFFFFFFF0, 4366c0), > BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4350_CHIP_ID, 0x000000FF, 4350C), > BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4350_CHIP_ID, 0xFFFFFF00, 4350), > BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43525_CHIP_ID, 0xFFFFFFF0, 4365C), > @@ -73,8 +73,8 @@ static struct brcmf_firmware_mapping brcmf_pcie_fwnames[] = { > BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4359_CHIP_ID, 0xFFFFFFFF, 4359), > BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4365_CHIP_ID, 0x0000000F, 4365B), > BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4365_CHIP_ID, 0xFFFFFFF0, 4365C), > - BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4366_CHIP_ID, 0x0000000F, 4366B), > - BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4366_CHIP_ID, 0xFFFFFFF0, 4366C), > + BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4366_CHIP_ID, 0x0000000F, 4366b1), > + BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4366_CHIP_ID, 0xFFFFFFF0, 4366c0), > BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4371_CHIP_ID, 0xFFFFFFFF, 4371), > }; > > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 4.12 1/2] brcmfmac: don't use 43602a1 firmware for 43602a0 chipset 2017-02-24 12:27 [PATCH 4.12 1/2] brcmfmac: don't use 43602a1 firmware for 43602a0 chipset Rafał Miłecki 2017-02-24 12:27 ` [PATCH 4.12 2/2] brcmfmac: use more accurate PCIe chip names in fw table Rafał Miłecki @ 2017-02-24 13:21 ` Arend Van Spriel 2017-02-24 13:43 ` Rafał Miłecki 1 sibling, 1 reply; 6+ messages in thread From: Arend Van Spriel @ 2017-02-24 13:21 UTC (permalink / raw) To: Rafał Miłecki, Kalle Valo Cc: Franky Lin, Hante Meuleman, Pieter-Paul Giesberts, Franky Lin, linux-wireless, brcm80211-dev-list.pdl, Rafał Miłecki 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), > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 4.12 1/2] brcmfmac: don't use 43602a1 firmware for 43602a0 chipset 2017-02-24 13:21 ` [PATCH 4.12 1/2] brcmfmac: don't use 43602a1 firmware for 43602a0 chipset Arend Van Spriel @ 2017-02-24 13:43 ` Rafał Miłecki 2017-02-28 9:23 ` Arend Van Spriel 0 siblings, 1 reply; 6+ messages in thread From: Rafał Miłecki @ 2017-02-24 13:43 UTC (permalink / raw) To: Arend Van Spriel Cc: Rafał Miłecki, Kalle Valo, Franky Lin, Hante Meuleman, Pieter-Paul Giesberts, Franky Lin, linux-wireless, brcm80211-dev-list.pdl 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 :) ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 4.12 1/2] brcmfmac: don't use 43602a1 firmware for 43602a0 chipset 2017-02-24 13:43 ` Rafał Miłecki @ 2017-02-28 9:23 ` Arend Van Spriel 0 siblings, 0 replies; 6+ messages in thread From: Arend Van Spriel @ 2017-02-28 9:23 UTC (permalink / raw) To: Rafał Miłecki Cc: Rafał Miłecki, Kalle Valo, Franky Lin, Hante Meuleman, Pieter-Paul Giesberts, Franky Lin, linux-wireless, brcm80211-dev-list.pdl 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-02-28 9:31 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-02-24 12:27 [PATCH 4.12 1/2] brcmfmac: don't use 43602a1 firmware for 43602a0 chipset Rafał Miłecki 2017-02-24 12:27 ` [PATCH 4.12 2/2] brcmfmac: use more accurate PCIe chip names in fw table Rafał Miłecki 2017-02-24 13:28 ` Arend Van Spriel 2017-02-24 13:21 ` [PATCH 4.12 1/2] brcmfmac: don't use 43602a1 firmware for 43602a0 chipset Arend Van Spriel 2017-02-24 13:43 ` Rafał Miłecki 2017-02-28 9:23 ` Arend Van Spriel
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox