2022-09-21 04:41:51

by Hector Martin

[permalink] [raw]
Subject: Re: [PATCH v2] brcmfmac: Add support for BCM43596 PCIe Wi-Fi

On 21/09/2022 09.16, Konrad Dybcio wrote:
> Add support for BCM43596 dual-band AC chip, found in
> SONY Xperia X Performance, XZ and XZs smartphones (and
> *possibly* other devices from other manufacturers).
> The chip doesn't require any special handling and seems to work
> just fine OOTB.
>
> PCIe IDs taken from: https://github.com/sonyxperiadev/kernel/commit/9e43fefbac8e43c3d7792e73ca52a052dd86d7e3.patch
>
> Signed-off-by: Konrad Dybcio <[email protected]>
> ---
> Changes since v1:
> - rebased the patch against -next
>
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c | 2 ++
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 4 ++++
> drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h | 4 ++++
> 3 files changed, 10 insertions(+)
>
[...]
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> index f98641bb1528..2e7fc66adf31 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> @@ -81,6 +81,7 @@ static const struct brcmf_firmware_mapping brcmf_pcie_fwnames[] = {
> BRCMF_FW_ENTRY(BRCM_CC_43570_CHIP_ID, 0xFFFFFFFF, 43570),
> BRCMF_FW_ENTRY(BRCM_CC_4358_CHIP_ID, 0xFFFFFFFF, 4358),
> BRCMF_FW_ENTRY(BRCM_CC_4359_CHIP_ID, 0xFFFFFFFF, 4359),
> + BRCMF_FW_ENTRY(BRCM_CC_43596_CHIP_ID, 0xFFFFFFFF, 4359),

So this works with the same firmware as 4359? That sounds a bit off. Is
that really the case?

brcmfmac4359-pcie isn't in linux-firmware, but presumably there is
*some* semi-canonical firmware you can find for that chip that other
people are already using. If that works on 43596 *and* you plan on using
that firmware or some other firmware marked 4359, then this is fine. If
you are using separate firmware that shipped with a 43596 device and
isn't itself marked 4359, please make it a separate firmware entry. We
can always symlink the firmwares if it later turns out there is no
reason to have different ones for each chip.

- Hector


2022-09-21 21:37:13

by Konrad Dybcio

[permalink] [raw]
Subject: Re: [PATCH v2] brcmfmac: Add support for BCM43596 PCIe Wi-Fi



On 21.09.2022 06:37, Hector Martin wrote:
> On 21/09/2022 09.16, Konrad Dybcio wrote:
>> Add support for BCM43596 dual-band AC chip, found in
>> SONY Xperia X Performance, XZ and XZs smartphones (and
>> *possibly* other devices from other manufacturers).
>> The chip doesn't require any special handling and seems to work
>> just fine OOTB.
>>
>> PCIe IDs taken from: https://github.com/sonyxperiadev/kernel/commit/9e43fefbac8e43c3d7792e73ca52a052dd86d7e3.patch
>>
>> Signed-off-by: Konrad Dybcio <[email protected]>
>> ---
>> Changes since v1:
>> - rebased the patch against -next
>>
>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c | 2 ++
>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 4 ++++
>> drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h | 4 ++++
>> 3 files changed, 10 insertions(+)
>>
> [...]
>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
>> index f98641bb1528..2e7fc66adf31 100644
>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
>> @@ -81,6 +81,7 @@ static const struct brcmf_firmware_mapping brcmf_pcie_fwnames[] = {
>> BRCMF_FW_ENTRY(BRCM_CC_43570_CHIP_ID, 0xFFFFFFFF, 43570),
>> BRCMF_FW_ENTRY(BRCM_CC_4358_CHIP_ID, 0xFFFFFFFF, 4358),
>> BRCMF_FW_ENTRY(BRCM_CC_4359_CHIP_ID, 0xFFFFFFFF, 4359),
>> + BRCMF_FW_ENTRY(BRCM_CC_43596_CHIP_ID, 0xFFFFFFFF, 4359),
>
> So this works with the same firmware as 4359? That sounds a bit off. Is
> that really the case?
>
> brcmfmac4359-pcie isn't in linux-firmware, but presumably there is
> *some* semi-canonical firmware you can find for that chip that other
> people are already using. If that works on 43596 *and* you plan on using
> that firmware or some other firmware marked 4359, then this is fine. If
> you are using separate firmware that shipped with a 43596 device and
> isn't itself marked 4359, please make it a separate firmware entry. We
> can always symlink the firmwares if it later turns out there is no
> reason to have different ones for each chip.
The firmware that SONY originally gave us for the devices that we know use
this chip seems to be marked 4359 [1]. That said, I have no other info
about the relation between the two models.

[1] https://github.com/sonyxperiadev/device-sony-kagura/tree/q-mr1/rootdir/vendor/firmware

Konrad
>
> - Hector

2022-09-22 06:57:38

by Hector Martin

[permalink] [raw]
Subject: Re: [PATCH v2] brcmfmac: Add support for BCM43596 PCIe Wi-Fi

On 22/09/2022 06.26, Konrad Dybcio wrote:
>
>
> On 21.09.2022 06:37, Hector Martin wrote:
>> On 21/09/2022 09.16, Konrad Dybcio wrote:
>>> Add support for BCM43596 dual-band AC chip, found in
>>> SONY Xperia X Performance, XZ and XZs smartphones (and
>>> *possibly* other devices from other manufacturers).
>>> The chip doesn't require any special handling and seems to work
>>> just fine OOTB.
>>>
>>> PCIe IDs taken from: https://github.com/sonyxperiadev/kernel/commit/9e43fefbac8e43c3d7792e73ca52a052dd86d7e3.patch
>>>
>>> Signed-off-by: Konrad Dybcio <[email protected]>
>>> ---
>>> Changes since v1:
>>> - rebased the patch against -next
>>>
>>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c | 2 ++
>>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 4 ++++
>>> drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h | 4 ++++
>>> 3 files changed, 10 insertions(+)
>>>
>> [...]
>>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
>>> index f98641bb1528..2e7fc66adf31 100644
>>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
>>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
>>> @@ -81,6 +81,7 @@ static const struct brcmf_firmware_mapping brcmf_pcie_fwnames[] = {
>>> BRCMF_FW_ENTRY(BRCM_CC_43570_CHIP_ID, 0xFFFFFFFF, 43570),
>>> BRCMF_FW_ENTRY(BRCM_CC_4358_CHIP_ID, 0xFFFFFFFF, 4358),
>>> BRCMF_FW_ENTRY(BRCM_CC_4359_CHIP_ID, 0xFFFFFFFF, 4359),
>>> + BRCMF_FW_ENTRY(BRCM_CC_43596_CHIP_ID, 0xFFFFFFFF, 4359),
>>
>> So this works with the same firmware as 4359? That sounds a bit off. Is
>> that really the case?
>>
>> brcmfmac4359-pcie isn't in linux-firmware, but presumably there is
>> *some* semi-canonical firmware you can find for that chip that other
>> people are already using. If that works on 43596 *and* you plan on using
>> that firmware or some other firmware marked 4359, then this is fine. If
>> you are using separate firmware that shipped with a 43596 device and
>> isn't itself marked 4359, please make it a separate firmware entry. We
>> can always symlink the firmwares if it later turns out there is no
>> reason to have different ones for each chip.
> The firmware that SONY originally gave us for the devices that we know use
> this chip seems to be marked 4359 [1]. That said, I have no other info
> about the relation between the two models.
>
> [1] https://github.com/sonyxperiadev/device-sony-kagura/tree/q-mr1/rootdir/vendor/firmware

That link seems to have the nvram file and Bluetooth firmware, but not
WLAN firmware. I think if you run `strings` on the WLAN firmware you'll
get a build ID with the chip name in it, that might be a good indication
of what the firmware name should be.

I would suggest trying to find some other 4359 firmware and testing your
device with it. If it works, then it's definitely fine to use the same
firmware name. If it doesn't, then you might need different firmware
names, or it might just be a case for board-specific firmwares.

- Hector

2022-09-22 10:38:39

by Konrad Dybcio

[permalink] [raw]
Subject: Re: [PATCH v2] brcmfmac: Add support for BCM43596 PCIe Wi-Fi



On 22.09.2022 08:40, Hector Martin wrote:
> On 22/09/2022 06.26, Konrad Dybcio wrote:
>>
>>
>> On 21.09.2022 06:37, Hector Martin wrote:
>>> On 21/09/2022 09.16, Konrad Dybcio wrote:
>>>> Add support for BCM43596 dual-band AC chip, found in
>>>> SONY Xperia X Performance, XZ and XZs smartphones (and
>>>> *possibly* other devices from other manufacturers).
>>>> The chip doesn't require any special handling and seems to work
>>>> just fine OOTB.
>>>>
>>>> PCIe IDs taken from: https://github.com/sonyxperiadev/kernel/commit/9e43fefbac8e43c3d7792e73ca52a052dd86d7e3.patch
>>>>
>>>> Signed-off-by: Konrad Dybcio <[email protected]>
>>>> ---
>>>> Changes since v1:
>>>> - rebased the patch against -next
>>>>
>>>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c | 2 ++
>>>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 4 ++++
>>>> drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h | 4 ++++
>>>> 3 files changed, 10 insertions(+)
>>>>
>>> [...]
>>>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
>>>> index f98641bb1528..2e7fc66adf31 100644
>>>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
>>>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
>>>> @@ -81,6 +81,7 @@ static const struct brcmf_firmware_mapping brcmf_pcie_fwnames[] = {
>>>> BRCMF_FW_ENTRY(BRCM_CC_43570_CHIP_ID, 0xFFFFFFFF, 43570),
>>>> BRCMF_FW_ENTRY(BRCM_CC_4358_CHIP_ID, 0xFFFFFFFF, 4358),
>>>> BRCMF_FW_ENTRY(BRCM_CC_4359_CHIP_ID, 0xFFFFFFFF, 4359),
>>>> + BRCMF_FW_ENTRY(BRCM_CC_43596_CHIP_ID, 0xFFFFFFFF, 4359),
>>>
>>> So this works with the same firmware as 4359? That sounds a bit off. Is
>>> that really the case?
>>>
>>> brcmfmac4359-pcie isn't in linux-firmware, but presumably there is
>>> *some* semi-canonical firmware you can find for that chip that other
>>> people are already using. If that works on 43596 *and* you plan on using
>>> that firmware or some other firmware marked 4359, then this is fine. If
>>> you are using separate firmware that shipped with a 43596 device and
>>> isn't itself marked 4359, please make it a separate firmware entry. We
>>> can always symlink the firmwares if it later turns out there is no
>>> reason to have different ones for each chip.
>> The firmware that SONY originally gave us for the devices that we know use
>> this chip seems to be marked 4359 [1]. That said, I have no other info
>> about the relation between the two models.
>>
>> [1] https://github.com/sonyxperiadev/device-sony-kagura/tree/q-mr1/rootdir/vendor/firmware
>
> That link seems to have the nvram file and Bluetooth firmware, but not
> WLAN firmware. I think if you run `strings` on the WLAN firmware you'll
> get a build ID with the chip name in it, that might be a good indication
> of what the firmware name should be.
Riight, sorry about that.. This is the correct link [1]

Running strings on fw_bcmdhd.bin (which I renamed to brcmfmac4359-pcie.bin for
mainline firwmare name matching purposes) outputs:

43596a0-roml/pcie-wl11u-ve-mfp-tdls-sr-die3-wepso-wnm-pfn-olpc-mobfd-rcc-ccx-noccxaka-clm_43xx_somc_mimo-fmc-phyflags-rscanf-murx-ltecx-rpi-txpwrctrls-dpo-proxd-hs20sta-linkstat-gscan-rmon-pfnanqpo-dpm Version: 9.75.119.15 (r691661) CRC: 46ae3900 Date: Fri 2017-03-24 13:22:28 KST Ucode Ver: 1060.20542 FWID: 01-a0d2ee7a

However, as you can see, the directory is named bcm4359 and not bcm43596, so my
best guess is that it's probably part of the same chip family with minor
differences.

Also worth noting is the 'somc' bit, meaning there are probably *some* SONY
customizations, but that's also just a guess.


I did also find this [2] fw for 4359 which contains:

4359b1-roml/pcie-wl11u-mfp-nvramadj-sr-die3-pwrofs-wnm-pfn-pwrstats-olpc-mobfd-txbf-mimopscan-slna-wapi-nsslimit-lpc-wepso-pspretend-apbs-apcs-spurcan-clm_min-obss-fbt-idsup-idauth Version: 9.40.109 (r710128 CY) CRC: e4b3d019 Date: Wed 2019-02-20 18:09:51 PST Ucode Ver: 1043.20426 FWID 01-848095d2

So I suppose I will respin this series to make 43596 use its own fw, since - while
probably similar - the two are in fact distinct.

Konrad

[1] https://github.com/sonyxperiadev/vendor-broadcom-wlan/tree/master/bcmdhd/firmware/bcm4359
[2] https://github.com/NXP/imx-firmware/tree/master/cyw-wifi-bt/1FD_CYW4359
>
> I would suggest trying to find some other 4359 firmware and testing your
> device with it. If it works, then it's definitely fine to use the same
> firmware name. If it doesn't, then you might need different firmware
> names, or it might just be a case for board-specific firmwares.
>
> - Hector

2022-09-22 13:17:13

by Linus Walleij

[permalink] [raw]
Subject: Re: [PATCH v2] brcmfmac: Add support for BCM43596 PCIe Wi-Fi

On Thu, Sep 22, 2022 at 12:21 PM Konrad Dybcio
<[email protected]> wrote:

> Also worth noting is the 'somc' bit, meaning there are probably *some* SONY
> customizations, but that's also just a guess.

What I have seen from BRCM customizations on Samsung phones is that
the per-device customization of firmware seems to involve the set-up of
some GPIO and power management pins. For example if integrated with
an SoC that has autonomous system resume, or if some GPIO line has
to be pulled to enable an external regulator or PA.

To the best of my knowledge that customization is done by consultants
from Broadcom when working with the device manufacturer, and
eventually they roll a unique firmware for the device. Probably because
the firmware can only be signed for execution by Broadcom?

Yours,
Linus Walleij

2022-09-22 13:18:33

by Hector Martin

[permalink] [raw]
Subject: Re: [PATCH v2] brcmfmac: Add support for BCM43596 PCIe Wi-Fi

On 22/09/2022 22.02, Linus Walleij wrote:
> On Thu, Sep 22, 2022 at 12:21 PM Konrad Dybcio
> <[email protected]> wrote:
>
>> Also worth noting is the 'somc' bit, meaning there are probably *some* SONY
>> customizations, but that's also just a guess.
>
> What I have seen from BRCM customizations on Samsung phones is that
> the per-device customization of firmware seems to involve the set-up of
> some GPIO and power management pins. For example if integrated with
> an SoC that has autonomous system resume, or if some GPIO line has
> to be pulled to enable an external regulator or PA.
>
> To the best of my knowledge that customization is done by consultants
> from Broadcom when working with the device manufacturer, and
> eventually they roll a unique firmware for the device. Probably because
> the firmware can only be signed for execution by Broadcom?

I don't think the firmware is signed, they probably just don't want to
share the source code with most customers? (Except Apple maybe, but
Apple gets custom silicon too...).

- Hector

2022-09-22 13:38:20

by Alvin Šipraga

[permalink] [raw]
Subject: Re: [PATCH v2] brcmfmac: Add support for BCM43596 PCIe Wi-Fi

On Thu, Sep 22, 2022 at 03:02:12PM +0200, Linus Walleij wrote:
> On Thu, Sep 22, 2022 at 12:21 PM Konrad Dybcio
> <[email protected]> wrote:
>
> > Also worth noting is the 'somc' bit, meaning there are probably *some* SONY
> > customizations, but that's also just a guess.
>
> What I have seen from BRCM customizations on Samsung phones is that
> the per-device customization of firmware seems to involve the set-up of
> some GPIO and power management pins. For example if integrated with
> an SoC that has autonomous system resume, or if some GPIO line has
> to be pulled to enable an external regulator or PA.

At least with Infineon (formerly Cypress), as a customer you might get a
private firmware and this will be maintained internally by them on a
separate customer branch. Any subsequent bugfixes or feature requests
will usually be applied to that customer branch and a new firmware built
from it. I think their internal "mainline" branch might get merged into
the customer branches from time to time, but this seems to be done on an
ad-hoc basis. This is our experience at least.

I would also point out that the BCM4359 is equivalent to the
CYW88359/CYW89359 chipset, which we are using in some of our
products. Note that this is a Cypress chipset (identifiable by the
Version: ... (... CY) tag in the version string). But the FW Konrad is
linking appears to be for a Broadcom chipset.

FYI, here's a publicly available set of firmware files for the '4359:

https://github.com/NXP/imx-firmware/tree/master/cyw-wifi-bt/1FD_CYW4359

Anyway, I would second Hector's suggestion and make this a separate FW.

>
> To the best of my knowledge that customization is done by consultants
> from Broadcom when working with the device manufacturer, and
> eventually they roll a unique firmware for the device. Probably because
> the firmware can only be signed for execution by Broadcom?

Kind regards,
Alvin

>
> Yours,
> Linus Walleij

2022-09-22 20:21:34

by Linus Walleij

[permalink] [raw]
Subject: Re: [PATCH v2] brcmfmac: Add support for BCM43596 PCIe Wi-Fi

On Thu, Sep 22, 2022 at 3:31 PM Alvin Šipraga <[email protected]> wrote:

> I would also point out that the BCM4359 is equivalent to the
> CYW88359/CYW89359 chipset, which we are using in some of our
> products. Note that this is a Cypress chipset (identifiable by the
> Version: ... (... CY) tag in the version string). But the FW Konrad is
> linking appears to be for a Broadcom chipset.

This just makes me think about Peter Robinsons seminar at
LPC last week...
"All types of wireless in Linux are terrible and why the vendors
should feel bad"
https://lpc.events/event/16/contributions/1278/attachments/1120/2153/wireless-issues.pdf

Yours,
Linus Walleij

2022-09-26 08:29:48

by Kalle Valo

[permalink] [raw]
Subject: Stockholm syndrome with Linux wireless?

(changing the subject as this has nothing to do with brcmfmac)

Linus Walleij <[email protected]> writes:

> On Thu, Sep 22, 2022 at 3:31 PM Alvin Šipraga <[email protected]> wrote:
>
>> I would also point out that the BCM4359 is equivalent to the
>> CYW88359/CYW89359 chipset, which we are using in some of our
>> products. Note that this is a Cypress chipset (identifiable by the
>> Version: ... (... CY) tag in the version string). But the FW Konrad is
>> linking appears to be for a Broadcom chipset.
>
> This just makes me think about Peter Robinsons seminar at
> LPC last week...
> "All types of wireless in Linux are terrible and why the vendors
> should feel bad"
> https://lpc.events/event/16/contributions/1278/attachments/1120/2153/wireless-issues.pdf

Thanks, this was a good read! I'm always interested about user and
downstream feedback, both good and bad :) But I didn't get the Stockholm
syndrome comment in the end, what does he mean with that?

BTW we have a wireless workshop in netdevconf 0x16, it would be great to
have there a this kind of session discussing user pain points:

https://netdevconf.info/0x16/session.html?Wireless-Workshop

--
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

2022-09-26 09:03:15

by Russell King (Oracle)

[permalink] [raw]
Subject: Re: Stockholm syndrome with Linux wireless?

On Mon, Sep 26, 2022 at 11:20:18AM +0300, Kalle Valo wrote:
> (changing the subject as this has nothing to do with brcmfmac)
>
> Linus Walleij <[email protected]> writes:
>
> > On Thu, Sep 22, 2022 at 3:31 PM Alvin Šipraga <[email protected]> wrote:
> >
> >> I would also point out that the BCM4359 is equivalent to the
> >> CYW88359/CYW89359 chipset, which we are using in some of our
> >> products. Note that this is a Cypress chipset (identifiable by the
> >> Version: ... (... CY) tag in the version string). But the FW Konrad is
> >> linking appears to be for a Broadcom chipset.
> >
> > This just makes me think about Peter Robinsons seminar at
> > LPC last week...
> > "All types of wireless in Linux are terrible and why the vendors
> > should feel bad"
> > https://lpc.events/event/16/contributions/1278/attachments/1120/2153/wireless-issues.pdf
>
> Thanks, this was a good read! I'm always interested about user and
> downstream feedback, both good and bad :) But I didn't get the Stockholm
> syndrome comment in the end, what does he mean with that?
>
> BTW we have a wireless workshop in netdevconf 0x16, it would be great to
> have there a this kind of session discussing user pain points:
>
> https://netdevconf.info/0x16/session.html?Wireless-Workshop

You asked. :)

It's probably outside of your control as it's probably firmware issues
is when using Broadcom or TI WiFi in AP mode, and the resulting
instability.

Over the years, SolidRun have used Broadcom 4329 and 4330 chipsets on
their iMX6 products, and then switched to using a TI WL18xx chipset.
I forget what the issues were with the Broadcom chipsets, as I'm
currently using the TI variants.

In order to keep the WiFi network stable, I implemented a userspace
program that polls the WL18xx statistics in debugfs every 100ms, and
when it seems the adapter has got stuck, it takes the interface down
and brings it back up again to reset stuff. This seems to improve the
overall stability, but it's still far from perfect as one regularly
sees latency go through the roof.

I recently noticed (earlier this month) a bigger problem with it -
I had one laptop running zoom, another laptop running interactive
stuff, and while zoom was running, the other laptop basically lost
network access - which came back when zoom was stopped. I'm not
sure what was going on there, because if you don't have the ability
to do interactive stuff it's pretty hard to debug what's going on
at the machine with the AP.

I've just looked at that machine, which has been mostly idle (as in
no clients connected) and I see:

[271559.346460] wlcore: ERROR Tx stuck (in FW) for 5000 ms. Starting recovery
[271559.353395] WARNING: CPU: 1 PID: 6395 at drivers/net/wireless/ti/wlcore/main.c:803 wl12xx_queue_recovery_work.part.0+0x50/0x54 [wlcore]

with the resutling entirely useless backtrace - that's 3 days, 3 hours
and 25 minutes ago, which would make it Friday 6:25am when nothing
was connected to the wifi network.

I've turned off all the runtime PM for the hardware path for wifi
conenctivity (every single power/control file is forced to "on") so
it isn't being triggered by some runtime PM behaviour.

Like I think many, I've come to the conclusion that WiFi is just a
completely unstable medium, and wired networking is just far superior,
even though it comes with the nusience of needing wires.

I don't think this is the fault of the Linux WiFi core code, I think
this is down to vendors, and vendors just do not want to know about
problems.

That said, running this stuff in AP mode isn't vendors primary goal,
since that isn't what most users want to do, so it's probably
understandable that AP mode tends to be flakey.

--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

2022-09-26 09:30:27

by Kalle Valo

[permalink] [raw]
Subject: Re: [PATCH v2] brcmfmac: Add support for BCM43596 PCIe Wi-Fi

Alvin Šipraga <[email protected]> writes:

> On Thu, Sep 22, 2022 at 03:02:12PM +0200, Linus Walleij wrote:
>> On Thu, Sep 22, 2022 at 12:21 PM Konrad Dybcio
>> <[email protected]> wrote:
>>
>> > Also worth noting is the 'somc' bit, meaning there are probably *some* SONY
>> > customizations, but that's also just a guess.
>>
>> What I have seen from BRCM customizations on Samsung phones is that
>> the per-device customization of firmware seems to involve the set-up of
>> some GPIO and power management pins. For example if integrated with
>> an SoC that has autonomous system resume, or if some GPIO line has
>> to be pulled to enable an external regulator or PA.
>
> At least with Infineon (formerly Cypress), as a customer you might get a
> private firmware and this will be maintained internally by them on a
> separate customer branch. Any subsequent bugfixes or feature requests
> will usually be applied to that customer branch and a new firmware built
> from it. I think their internal "mainline" branch might get merged into
> the customer branches from time to time, but this seems to be done on an
> ad-hoc basis. This is our experience at least.
>
> I would also point out that the BCM4359 is equivalent to the
> CYW88359/CYW89359 chipset, which we are using in some of our
> products. Note that this is a Cypress chipset (identifiable by the
> Version: ... (... CY) tag in the version string). But the FW Konrad is
> linking appears to be for a Broadcom chipset.
>
> FYI, here's a publicly available set of firmware files for the '4359:
>
> https://github.com/NXP/imx-firmware/tree/master/cyw-wifi-bt/1FD_CYW4359
>
> Anyway, I would second Hector's suggestion and make this a separate FW.

I also recommend having a separate firmware filename. Like Hector said,
it's easy to have a symlink in userspace if same binary can be used.

--
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches