Re: [PATCH 2/5] brcmfmac: remove "arp_hostip_clear" from "brcmf_netdev_stop"

[Franky Lin]

On Sun, Nov 11, 2018 at 6:10 PM Wright Feng  wrote:
>
>
>
> On 2018/11/9 上午 03:19, Franky Lin wrote:
> > On Wed, Nov 7, 2018 at 7:48 PM Chi-Hsien Lin  
> > wrote:
> >>
> >> From: Wright Feng 
> >>
> >> The firmware does not respond ARP request and causes ping failure with
> >> following steps:
> >>
> >> 1. Bring up interface
> >> ifconfig wlan0 up or start wpa_supplicant
> >> 2. Set the IP address
> >> ifconfig wlan0 192.168.100.10
> >> 3. Bring down interface or
> >> ifconfig wlan0 down or kill wpa_supplicant
> >> 4. Bring up interface again and set the same IP address
> >> 5. Connect to AP(192.168.100.1) and ping to AP will be failed.
> >>
> >> FMAC clears arp_hostip when bringing down the interface, but not set it
> >> back if setting the same IP address. We are able to see the IP address
> >> in interface info(inconfig wlan0) but the ping still cannot work because
> >> the firmware ARP offload does not respond the ARP request.
> >> Because of that, we remove "arp_hostip_clear" from function
> >> "brcmf_netdev_stop"
> >
> > Shouldn't brcmf_inetaddr_changed get called when the interface up again?
> >
> > Thanks,
> > - Franky
> >
> The brcmf_inetaddr_changed only be called in inet_del_ifa and
> inet_insert_ifa. If the IP address is not changed when the interface up
> again, the brcmf_inetaddr_changed will not be called.

Thanks, looks good to me.

>
> -Wright
> >>
> >> Signed-off-by: Wright Feng 
> >> Signed-off-by: Chi-Hsien Lin 

Reviewed-by: Franky Lin 

> >> ---
> >>   drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c | 2 --
> >>   1 file changed, 2 deletions(-)
> >>
> >> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c 
> >> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> >> index b1f702faff4f..e1666cf3801c 100644
> >> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> >> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> >> @@ -533,8 +533,6 @@ static int brcmf_netdev_stop(struct net_device *ndev)
> >>
> >>  brcmf_cfg80211_down(ndev);
> >>
> >> -   brcmf_fil_iovar_data_set(ifp, "arp_hostip_clear", NULL, 0);
> >> -
> >>  brcmf_net_setcarrier(ifp, false);
> >>
> >>  return 0;
> >> --
> >> 2.1.0
> >>
> >
> >
> > --
> >
> > You're receiving this message because you're a member of the 
> > brcm80211-dev-list group.
> >

Re: [PATCH 2/5] brcmfmac: remove "arp_hostip_clear" from "brcmf_netdev_stop"

[Franky Lin]

On Wed, Nov 7, 2018 at 7:48 PM Chi-Hsien Lin  wrote:
>
> From: Wright Feng 
>
> The firmware does not respond ARP request and causes ping failure with
> following steps:
>
> 1. Bring up interface
>ifconfig wlan0 up or start wpa_supplicant
> 2. Set the IP address
>ifconfig wlan0 192.168.100.10
> 3. Bring down interface or
>ifconfig wlan0 down or kill wpa_supplicant
> 4. Bring up interface again and set the same IP address
> 5. Connect to AP(192.168.100.1) and ping to AP will be failed.
>
> FMAC clears arp_hostip when bringing down the interface, but not set it
> back if setting the same IP address. We are able to see the IP address
> in interface info(inconfig wlan0) but the ping still cannot work because
> the firmware ARP offload does not respond the ARP request.
> Because of that, we remove "arp_hostip_clear" from function
> "brcmf_netdev_stop"

Shouldn't brcmf_inetaddr_changed get called when the interface up again?

Thanks,
- Franky

>
> Signed-off-by: Wright Feng 
> Signed-off-by: Chi-Hsien Lin 
> ---
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> index b1f702faff4f..e1666cf3801c 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> @@ -533,8 +533,6 @@ static int brcmf_netdev_stop(struct net_device *ndev)
>
> brcmf_cfg80211_down(ndev);
>
> -   brcmf_fil_iovar_data_set(ifp, "arp_hostip_clear", NULL, 0);
> -
> brcmf_net_setcarrier(ifp, false);
>
> return 0;
> --
> 2.1.0
>

Re: [PATCH 1/3] brcmfmac: calling skb_orphan before sending skb to SDIO bus

[Franky Lin]

On Thu, Nov 1, 2018 at 8:08 PM Wright Feng  wrote:
>
>
>
> On 2018/10/30 上午 02:50, Franky Lin wrote:
> > On Mon, Oct 29, 2018 at 3:27 AM Wright Feng  wrote:
> >>
> >> Linux 3.6 introduces TSQ which has a per socket threshold for TCP Tx
> >> packets to reduce latency. In fcmode 1 and fcmode 2, host driver enqueues
> >> skb in hanger and TCP doesn't push new skb until host frees the skb when
> >> receiving fwstatus event. So using skb_orphan before sending skb to bus
> >> will make the skb removing the ownership of socket. With this patch, we
> >> are able to get better throughput in fcmode 1 and fcmode 2.
> >>
> >> Tested 43455 TCP throughput in 20 MHz bandwidth with / without this patch.
> >> fcmode 0: 59.5 / 59.6 (mbps)
> >> fcmode 1: 59.3 / 23.4 (mbps)
> >> fcmode 2: 59.6 / 21.5 (mbps)
> >>
> >> Signed-off-by: Wright Feng 
> >> ---
> >>   drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 1 +
> >>   1 file changed, 1 insertion(+)
> >>
> >> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c 
> >> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> >> index b2e1ab5..519b25d 100644
> >> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> >> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> >> @@ -2298,6 +2298,7 @@ static uint brcmf_sdio_sendfromq(struct brcmf_sdio 
> >> *bus, uint maxframes)
> >>_out);
> >>  if (pkt == NULL)
> >>  break;
> >> +   skb_orphan(pkt);
> >
> > TSQ allows device driver to tweak for a deeper queue now. [1]. We
> > should use that instead of orphaning the packet before handing over to
> > firmware which would remove the bufferbloat protection by TSQ.
> >
> > Thanks,
> > -Franky
> >
> Since the aggregation problem has been fixed by setting sk_pacing_shift,
> I will submit v2 without this one.
> Thanks for the information.

No the problem is not fixed. The patch just provides an interface
sk_pacing_shift_update so the device driver can tweak the scale to
allow more packets being queued. You need to call
sk_pacing_shift_update somewhere in brcmfmac.

Thanks,
-Franky
>
> -Wright
> > [1] 
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3a9b76fd0db9f
> >
> >>  __skb_queue_tail(, pkt);
> >>  }
> >>  spin_unlock_bh(>txq_lock);
> >> --
> >> 1.9.1
> >>

Re: [PATCH 1/3] brcmfmac: calling skb_orphan before sending skb to SDIO bus

[Franky Lin]

On Mon, Oct 29, 2018 at 3:27 AM Wright Feng  wrote:
>
> Linux 3.6 introduces TSQ which has a per socket threshold for TCP Tx
> packets to reduce latency. In fcmode 1 and fcmode 2, host driver enqueues
> skb in hanger and TCP doesn't push new skb until host frees the skb when
> receiving fwstatus event. So using skb_orphan before sending skb to bus
> will make the skb removing the ownership of socket. With this patch, we
> are able to get better throughput in fcmode 1 and fcmode 2.
>
> Tested 43455 TCP throughput in 20 MHz bandwidth with / without this patch.
> fcmode 0: 59.5 / 59.6 (mbps)
> fcmode 1: 59.3 / 23.4 (mbps)
> fcmode 2: 59.6 / 21.5 (mbps)
>
> Signed-off-by: Wright Feng 
> ---
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> index b2e1ab5..519b25d 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> @@ -2298,6 +2298,7 @@ static uint brcmf_sdio_sendfromq(struct brcmf_sdio 
> *bus, uint maxframes)
>   _out);
> if (pkt == NULL)
> break;
> +   skb_orphan(pkt);

TSQ allows device driver to tweak for a deeper queue now. [1]. We
should use that instead of orphaning the packet before handing over to
firmware which would remove the bufferbloat protection by TSQ.

Thanks,
-Franky

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3a9b76fd0db9f

> __skb_queue_tail(, pkt);
> }
> spin_unlock_bh(>txq_lock);
> --
> 1.9.1
>

Re: brcmfmac with BCM4359 on arm64 (RK3399) and SDIO

[Franky Lin]

Hi Christoph,

On Tue, Oct 9, 2018 at 11:10 AM Christoph Müllner
 wrote:
>
> Hi Arend,
>
> recently I got an SDIO module, which includes a BCM4359.
> I tried to get it up and running via the SD card interface
> on a RK3399 SoC and succeeded in doing so with
> bcmdhd.1.579.77.41.x and a vendor kernel (based on Linux 4.4).
> All that was necessary was configure BCMDHD to run with
> in-band IRQs and use a GPIO as gpio_wl_reg_on.
>
> Since I can run a mainline kernel as well, I gave it a try and
> tried brcmfmac on Linux 4.19-rc7. As the BCM4359 is not in
> the list of supported SDIO devices, but is supported USB device,
> I've created a patch (attached), which adds the support for that device.
> Additionally I've patched my DTS to include the WL_REG_ON
> pin as part of mmc-pwrseq-simple's reset-gpios and added
> a bcm4329-fmac node in the mmc node.
>
> During bootup I see messages from brcmfmac, which indicate
> that the BCM4359 has been found, but loading the nvram file
> continuously fails:
>
> > [5.993741] brcmfmac: brcmf_fw_alloc_request: using 
> > brcm/brcmfmac4359-sdio for chip BCM4359/9
> > [...]
> > [7.987167] brcmfmac: brcmf_sdiod_ramrw: membytes transfer failed
> > [8.008715] brcmfmac: brcmf_sdio_verifymemory: error -84 on reading 2048 
> > membytes at 0x0025f1f0
> > [8.021182] brcmfmac: brcmf_sdio_download_firmware: dongle nvram file 
> > download failed

Does it always fail at nvram verification? If so please help to get
the address and varsz in brcmf_sdio_download_nvram. Also their
equivalent in bcmdhd which should be varaddr and varsize in
dhdsdio_write_vars.

Thanks,
--Franky

> That -84 means EILSEQ, which is the error value, which represents
> a CRC error during SDIO data exchange (returned by the function 
> dw_mci_data_complete()
> in the MMC driver).
>
> To address this, I've reduced the clock speed (in several steps) to 400 kHz
> (and verified the clock signal on an oscilloscope), but the issue persists.
> I've also tried to use Linux 4.14.74, where I see the same issue.
>
> I can confirm that the MMC interface works in general (I can use an SD card
> to host my rootfs).
>
> FWIW I'm using the same exact same firmware and nvram file for the DHD driver
> and the brcmfmac.
>
> Do you have any ideas how to debug this issue?
>
> Thanks,
> Christoph
>
>
>
> --
> Christoph Müllner
> Theobroma Systems Design und Consulting GmbH
> Seestadtstraße 27 (Aspern IQ), 1220 Wien, Austria
> Phone: +43 1 236 98 93-409, Fax: +43 1 236 98 93-9
> http://www.theobroma-systems.com
>
>
>
>

Re: [PATCH] wireless: brcmfmac: cfg80211: Fix check for ISO3166 code

[Franky Lin]

On Wed, Mar 14, 2018 at 12:02 PM, Stefan Wahren <stefan.wah...@i2se.com> wrote:
> The commit "regulatory: add NUL to request alpha2" increases the length of
> alpha2 to 3. This causes a regression on brcmfmac, because
> brcmf_cfg80211_reg_notifier() expect valid ISO3166 codes in the complete
> array. So fix this accordingly.
>
> Signed-off-by: Stefan Wahren <stefan.wah...@i2se.com>
Acked-by: Franky Lin <franky@broadcom.com>
> ---
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> index 74a8302..5ed718d 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> @@ -6805,7 +6805,7 @@ static void brcmf_cfg80211_reg_notifier(struct wiphy 
> *wiphy,
> return;
>
> /* ignore non-ISO3166 country codes */
> -   for (i = 0; i < sizeof(req->alpha2); i++)
> +   for (i = 0; i < 2; i++)
> if (req->alpha2[i] < 'A' || req->alpha2[i] > 'Z') {
> brcmf_err("not an ISO3166 code (0x%02x 0x%02x)\n",
>   req->alpha2[0], req->alpha2[1]);
> --
> 2.7.4
>

Re: [PATCH] brcmfmac: Fix glob_skb leak in brcmf_sdiod_recv_chain

[Franky Lin]

On Fri, Jun 2, 2017 at 10:22 AM, Peter S. Housel  wrote:
> An earlier change to this function (3bdae810721b) fixed a leak in the
> case of an unsuccessful call to brcmf_sdiod_buffrw(). However, the
> glob_skb buffer, used for emulating a scattering read, is never used
> or referenced after its contents are copied into the destination
> buffers, and therefore always needs to be freed by the end of the
> function.
>
> Signed-off-by: Peter S. Housel 
> ---
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> index 9b970dc..4c5064f 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> @@ -727,15 +727,16 @@ int brcmf_sdiod_recv_chain(struct brcmf_sdio_dev 
> *sdiodev,
> return -ENOMEM;
> err = brcmf_sdiod_buffrw(sdiodev, SDIO_FUNC_2, false, addr,
>  glom_skb);
> -   if (err) {
> -   brcmu_pkt_buf_free_skb(glom_skb);
> -   goto done;
> -   }
> +   if (err)
> +   goto free_glom_skb;
>
> skb_queue_walk(pktq, skb) {
> memcpy(skb->data, glom_skb->data, skb->len);
> skb_pull(glom_skb, skb->len);
> }
> +
> +free_glom_skb:
> +   brcmu_pkt_buf_free_skb(glom_skb);

What about
if (!err) {
skb_queue_walk(pktq, skb) {
memcpy(skb->data, glom_skb->data, skb->len);
skb_pull(glom_skb, skb->len);
}
}
brcmu_pkt_buf_free_skb(glom_skb);

Then no goto is needed.

Thanks,
Franky

> } else
> err = brcmf_sdiod_sglist_rw(sdiodev, SDIO_FUNC_2, false, addr,
> pktq);
> --
> 2.7.4
>

Re: [PATCH] brcmfmac: Fix kernel oops on resume when request firmware fails.

[Franky Lin]

Hi Enric,

On Tue, May 23, 2017 at 11:07 AM, Enric Balletbo i Serra
 wrote:
> When request firmware fails, brcmf_ops_sdio_remove is being called and
> brcmf_bus freed. In such circumstancies if you do a suspend/resume cycle
> the kernel hangs on resume due a NULL pointer dereference in resume
> function.
>
> Steps to reproduce the problem:
>  - modprobe brcmfmac without the firmware
>  brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac4354-sdio.bin
>  failed with error -2
>  - do a suspend/resume cycle (echo mem > /sys/power/state)
>
> Protect against the NULL pointer derefence by checking if dev_get_drvdata
> returned a valid pointer.
>
> Signed-off-by: Enric Balletbo i Serra 
> ---
> I'm not sure about if this is the correct way to fix this but at least it
> prevents the kernel to hang. From one side I'm not sure why suspend/resume
> functions are called in such case and why the device is not removed from
> the bus, from the other side I saw, that others drivers only unregisters
> from sdio when the driver is removed so I supose this is the normal behavior.
>

Thank you for reporting this. I also think these questions you listed
should be answered before putting the null check in resume routine. I
will dig deeper and share my finding on the thread.

Regards,
Franky

> Cheers,
>  Enric
>
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> index 9b970dc..aa0e7c2 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> @@ -1274,14 +1274,16 @@ static int brcmf_ops_sdio_suspend(struct device *dev)
>  static int brcmf_ops_sdio_resume(struct device *dev)
>  {
> struct brcmf_bus *bus_if = dev_get_drvdata(dev);
> -   struct brcmf_sdio_dev *sdiodev = bus_if->bus_priv.sdio;
> struct sdio_func *func = container_of(dev, struct sdio_func, dev);
>
> brcmf_dbg(SDIO, "Enter: F%d\n", func->num);
> if (func->num != SDIO_FUNC_2)
> return 0;
>
> -   brcmf_sdiod_freezer_off(sdiodev);
> +   if (!bus_if)
> +   return 0;
> +
> +   brcmf_sdiod_freezer_off(bus_if->bus_priv.sdio);
> return 0;
>  }
>
> @@ -1319,4 +1321,3 @@ void brcmf_sdio_exit(void)
>
> sdio_unregister_driver(_sdmmc_driver);
>  }
> -
> --
> 2.9.3
>

Re: brcmfmac firmware issue on NanoPi K2

[Franky Lin]

Hi Andreas,

On Sun, May 21, 2017 at 9:20 AM, Andreas Färber  wrote:
> Hello,
>
> The NanoPi K2 has an Ampak AP6212 SDIO module. brcmfmac driver loads
> brcmfmac43430-sdio.bin.
>
> When using the firmware file from linux-firmware.git that openSUSE ships
> I get the following errors on 4.11.0 and next-20170519:
>
> [ 2103.618716] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (100):
> clkctl 0x50
> [ 2104.668746] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (100):
> clkctl 0x50
> [ 2105.678677] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (100):
> clkctl 0x50
>
> If I overwrite /lib/firmware/brcm/bcm43430-sdio.bin with
> fw_bcm43438a0.bin from FriendlyARM's Android repository it suddenly works:
>
> [  +0.157738] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0:
> Jun  6 2014 14:50:39 version 7.10.226.49 (r) FWID 01-8962686a
> [  +0.160108] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code
> (0x30 0x30)
>
> I recall using the linux-firmware.git brcmfmac43430-sdio.bin file
> successfully on the Raspberry Pi 3 with a downstream (Leap 42.2) kernel.
>
> I've tested both nvram_ap6212.txt and nvram_ap6212a.txt, the latter has
> the following diff to nvram.txt:
>
> --- nvram_ap6212.txt2017-05-21 04:24:40.372113426 +0200
> +++ nvram_ap6212a.txt   2017-05-21 04:24:49.852116599 +0200
> @@ -1,4 +1,4 @@
> -#AP6212_NVRAM_V1.0_20140603
> +#AP6212_NVRAM_V1.0.1_20160606
>  # 2.4 GHz, 20 MHz BW mode
>
>  # The following parameter values are just placeholders, need to be updated.
> @@ -51,4 +51,4 @@
>  muxenab=0x10
>  # CLDO PWM voltage settings - 0x4 - 1.1 volt
>  #cldo_pwm=0x4
> -
> +glitch_based_crsmin=1
>
> https://github.com/friendlyarm/android_hardware_amlogic_wifi/tree/l-amlogic-gx-sync/bcm_ampak/config/6212
>
> * Does the linux-firmware.git brcmfmac43430-sdio.bin need a fix for AP6212?
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/brcm
>
> * Does the brcmfmac driver need to distinguish revisions in sdio.c as
> done for 43241, plus a separate firmware file?
> BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43430_CHIP_ID, 0x, 43430),

It seems we are dealing with different revisions of 43430. The
firmware file you pointed to is for 43430a0 and raspberry pi 3 is
using 43430a1. So yes brcmfmac needs to load different firmware and
nvram for them just like 43241.

Could you please help try the attached patch? I don't have the
hardware to test it. Please rename the 43438 firmware and nvram to
brcmfmac43430a0-sdio.bin/txt.

Thanks,
Franky

---

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index a999f95..1b12ccb 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -608,6 +608,7 @@ BRCMF_FW_NVRAM_DEF(43340,
"brcmfmac43340-sdio.bin", "brcmfmac43340-sdio.txt");
 BRCMF_FW_NVRAM_DEF(4335, "brcmfmac4335-sdio.bin", "brcmfmac4335-sdio.txt");
 BRCMF_FW_NVRAM_DEF(43362, "brcmfmac43362-sdio.bin", "brcmfmac43362-sdio.txt");
 BRCMF_FW_NVRAM_DEF(4339, "brcmfmac4339-sdio.bin", "brcmfmac4339-sdio.txt");
+BRCMF_FW_NVRAM_DEF(43430A0, "brcmfmac43430a0-sdio.bin",
"brcmfmac43430a0-sdio.txt");
 BRCMF_FW_NVRAM_DEF(43430, "brcmfmac43430-sdio.bin", "brcmfmac43430-sdio.txt");
 BRCMF_FW_NVRAM_DEF(43455, "brcmfmac43455-sdio.bin", "brcmfmac43455-sdio.txt");
 BRCMF_FW_NVRAM_DEF(4354, "brcmfmac4354-sdio.bin", "brcmfmac4354-sdio.txt");
@@ -626,7 +627,8 @@ static struct brcmf_firmware_mapping
brcmf_sdio_fwnames[] = {
  BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4335_CHIP_ID, 0x, 4335),
  BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43362_CHIP_ID, 0xFFFE, 43362),
  BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4339_CHIP_ID, 0x, 4339),
- BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43430_CHIP_ID, 0x, 43430),
+ BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43430_CHIP_ID, 0x0001, 43430A0),
+ BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43430_CHIP_ID, 0xFFFE, 43430),
  BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4345_CHIP_ID, 0xFFC0, 43455),
  BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4354_CHIP_ID, 0x, 4354),
  BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4356_CHIP_ID, 0x, 4356)

Re: [PATCH 4.12 V2] brcmfmac: move brcmf_txcomplete function to fwsignal.c

[Franky Lin]

Hi Rafal,

On Thu, Mar 2, 2017 at 10:38 PM, Rafał Miłecki  wrote:
> From: Rafał Miłecki 
>
> This function is called by USB and SDIO only, both using BCDC & FW
> Signalling. Move it out of core.c to make this file more generic and
> allow making fwsignal optional in the future.

Same with the brcmf_txflowblock patch, it would be better to wrap
fwsignal in bcdc
as a protocol feature. I am preparing a train to do that for these two
functions along
with others. Hopefully we will post them next week after internal review.

Again, sorry for the stall on this.

Thanks,
Franky

> Signed-off-by: Rafał Miłecki 
> ---
> V2: Make code with this patch compile when not based on top of (to be dropped)
> [PATCH 4.12] brcmfmac: get rid of brcmf_txflowblock helper function
> ---
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h |  3 ---
>  .../net/wireless/broadcom/brcm80211/brcmfmac/core.c| 18 
> --
>  .../wireless/broadcom/brcm80211/brcmfmac/fwsignal.c| 18 
> ++
>  .../wireless/broadcom/brcm80211/brcmfmac/fwsignal.h|  9 +
>  .../net/wireless/broadcom/brcm80211/brcmfmac/sdio.c|  3 ++-
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c |  3 ++-
>  6 files changed, 31 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
> index 76693df34742..059e40fdc3d5 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
> @@ -232,9 +232,6 @@ void brcmf_dev_reset(struct device *dev);
>  /* Indication from bus module to change flow-control state */
>  void brcmf_txflowblock(struct device *dev, bool state);
>
> -/* Notify the bus has transferred the tx packet to firmware */
> -void brcmf_txcomplete(struct device *dev, struct sk_buff *txp, bool success);
> -
>  /* Configure the "global" bus state used by upper layers */
>  void brcmf_bus_change_state(struct brcmf_bus *bus, enum brcmf_bus_state 
> state);
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> index 2f2f3a5ad86a..45ed24049b37 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> @@ -393,24 +393,6 @@ void brcmf_txfinalize(struct brcmf_if *ifp, struct 
> sk_buff *txp, bool success)
> brcmu_pkt_buf_free_skb(txp);
>  }
>
> -void brcmf_txcomplete(struct device *dev, struct sk_buff *txp, bool success)
> -{
> -   struct brcmf_bus *bus_if = dev_get_drvdata(dev);
> -   struct brcmf_pub *drvr = bus_if->drvr;
> -   struct brcmf_if *ifp;
> -
> -   /* await txstatus signal for firmware if active */
> -   if (brcmf_fws_fc_active(drvr->fws)) {
> -   if (!success)
> -   brcmf_fws_bustxfail(drvr->fws, txp);
> -   } else {
> -   if (brcmf_proto_hdrpull(drvr, false, txp, ))
> -   brcmu_pkt_buf_free_skb(txp);
> -   else
> -   brcmf_txfinalize(ifp, txp, success);
> -   }
> -}
> -
>  static void brcmf_ethtool_get_drvinfo(struct net_device *ndev,
> struct ethtool_drvinfo *info)
>  {
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
> index 5f1a5929cb30..07f0b3cfd59c 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
> @@ -2445,6 +2445,24 @@ bool brcmf_fws_fc_active(struct brcmf_fws_info *fws)
> return fws->fcmode != BRCMF_FWS_FCMODE_NONE;
>  }
>
> +void brcmf_fws_txcomplete(struct device *dev, struct sk_buff *txp, bool 
> success)
> +{
> +   struct brcmf_bus *bus_if = dev_get_drvdata(dev);
> +   struct brcmf_pub *drvr = bus_if->drvr;
> +   struct brcmf_if *ifp;
> +
> +   /* await txstatus signal for firmware if active */
> +   if (brcmf_fws_fc_active(drvr->fws)) {
> +   if (!success)
> +   brcmf_fws_bustxfail(drvr->fws, txp);
> +   } else {
> +   if (brcmf_proto_hdrpull(drvr, false, txp, ))
> +   brcmu_pkt_buf_free_skb(txp);
> +   else
> +   brcmf_txfinalize(ifp, txp, success);
> +   }
> +}
> +
>  void brcmf_fws_bustxfail(struct brcmf_fws_info *fws, struct sk_buff *skb)
>  {
> u32 hslot;
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.h 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.h
> index 96df66073b2a..d534164785de 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.h
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.h
> @@ -18,6 +18,10 @@
>  #ifndef FWSIGNAL_H_
>