RE: [v4] wlcore: add missing nvs file name info for wilink8
> -Original Message- > From: Julian Calaby [mailto:julian.cal...@gmail.com] > Sent: Saturday, August 5, 2017 8:51 AM > To: Reizer, Eyal > Cc: Kalle Valo; ,Tony Lindgren; linux-wireless@vger.kernel.org; linux- > ker...@vger.kernel.org; sebastian.reic...@collabora.co.uk > Subject: Re: [v4] wlcore: add missing nvs file name info for wilink8 > > Hi Eyal, > > On Mon, Jul 31, 2017 at 6:45 PM, Reizer, Eyal wrote: > > The following commits: > > c815fde wlcore: spi: Populate config firmware data > > d776fc8 wlcore: sdio: Populate config firmware data > > > > Populated the nvs entry for wilink6 and wilink7 only while it is > > still needed for wilink8 as well. > > This broke user space backward compatibility when upgrading from older > > kernels, as the alternate mac address would not be read from the nvs that > > is present in the file system (lib/firmware/ti-connectivity/wl1271-nvs.bin) > > causing mac address change of the wlan interface. > > > > This patch fix this and update the structure field with the same default > > nvs file name that has been used before. > > > > In addition, some distros hold a default wl1271-nvs.bin in the file > > system with a bogus mac address (deadbeef...) that for a wl18xx device > > also overrides the mac address that is stored inside the device. > > Warn users about this bogus mac address and use a random mac instead > > > > Cc: stable > > Signed-off-by: Eyal Reizer > > --- > > > > diff --git a/drivers/net/wireless/ti/wlcore/main.c > b/drivers/net/wireless/ti/wlcore/main.c > > index 60aaa85..7ce4221 100644 > > --- a/drivers/net/wireless/ti/wlcore/main.c > > +++ b/drivers/net/wireless/ti/wlcore/main.c > > @@ -5961,6 +5961,22 @@ static void wl12xx_derive_mac_addresses(struct > wl1271 *wl, u32 oui, u32 nic) > > if (nic + WLCORE_NUM_MAC_ADDRESSES - wl->num_mac_addr > > 0xff) > > wl1271_warning("NIC part of the MAC address wraps around!"); > > > > + if (oui == 0xdeadbe && nic == 0xef) { > > + wl1271_warning("Detected unconfigured mac address in nvs.\n" > > + "Using a random TI mac address instead.\n" > > + "in case of using a wl12xx device, your " > > + "device performance may not be optimized.\n" > > + "Please use the calibrator tool to > > configure " > > + "your device.\n" > > + "When using a wl18xx device the nvs file > > can " > > + "be removed as a default mac address is " > > + "stored internally.\n"); > > + > > + /* Use TI oui and a random nic */ > > + oui = 0x080028; > > Is there (or should there be) a constant for this? Thanks for the comment. Submitting v5 fixing this. Best Regards, Eyal
[v5] wlcore: add missing nvs file name info for wilink8
The following commits: c815fde wlcore: spi: Populate config firmware data d776fc8 wlcore: sdio: Populate config firmware data Populated the nvs entry for wilink6 and wilink7 only while it is still needed for wilink8 as well. This broke user space backward compatibility when upgrading from older kernels, as the alternate mac address would not be read from the nvs that is present in the file system (lib/firmware/ti-connectivity/wl1271-nvs.bin) causing mac address change of the wlan interface. This patch fix this and update the structure field with the same default nvs file name that has been used before. In addition, some distros hold a default wl1271-nvs.bin in the file system with a bogus mac address (deadbeef...) that for a wl18xx device also overrides the mac address that is stored inside the device. Warn users about this bogus mac address and use a random mac instead Cc: stable Signed-off-by: Eyal Reizer --- v2->v3: add a check for default deadbeef... mac address and warn about it v3->v4: use a random TI mac address instead of the bogus one v4->v5: add constant definition for TI oui address --- drivers/net/wireless/ti/wlcore/main.c | 16 drivers/net/wireless/ti/wlcore/sdio.c | 1 + drivers/net/wireless/ti/wlcore/spi.c| 1 + drivers/net/wireless/ti/wlcore/wlcore.h | 3 +++ 4 files changed, 21 insertions(+) diff --git a/drivers/net/wireless/ti/wlcore/main.c b/drivers/net/wireless/ti/wlcore/main.c index 60aaa85..257831a 100644 --- a/drivers/net/wireless/ti/wlcore/main.c +++ b/drivers/net/wireless/ti/wlcore/main.c @@ -5961,6 +5961,22 @@ static void wl12xx_derive_mac_addresses(struct wl1271 *wl, u32 oui, u32 nic) if (nic + WLCORE_NUM_MAC_ADDRESSES - wl->num_mac_addr > 0xff) wl1271_warning("NIC part of the MAC address wraps around!"); + if (oui == 0xdeadbe && nic == 0xef) { + wl1271_warning("Detected unconfigured mac address in nvs.\n" + "Using a random TI mac address instead.\n" + "in case of using a wl12xx device, your " + "device performance may not be optimized.\n" + "Please use the calibrator tool to configure " + "your device.\n" + "When using a wl18xx device the nvs file can " + "be removed as a default mac address is " + "stored internally.\n"); + + /* Use TI oui and a random nic */ + oui = WLCORE_TI_OUI_ADDRESS; + nic = get_random_int(); + } + for (i = 0; i < wl->num_mac_addr; i++) { wl->addresses[i].addr[0] = (u8)(oui >> 16); wl->addresses[i].addr[1] = (u8)(oui >> 8); diff --git a/drivers/net/wireless/ti/wlcore/sdio.c b/drivers/net/wireless/ti/wlcore/sdio.c index 2fb3871..f8a1fea 100644 --- a/drivers/net/wireless/ti/wlcore/sdio.c +++ b/drivers/net/wireless/ti/wlcore/sdio.c @@ -230,6 +230,7 @@ static const struct wilink_family_data wl128x_data = { static const struct wilink_family_data wl18xx_data = { .name = "wl18xx", .cfg_name = "ti-connectivity/wl18xx-conf.bin", + .nvs_name = "ti-connectivity/wl1271-nvs.bin", }; static const struct of_device_id wlcore_sdio_of_match_table[] = { diff --git a/drivers/net/wireless/ti/wlcore/spi.c b/drivers/net/wireless/ti/wlcore/spi.c index fdabb92..62ce54a 100644 --- a/drivers/net/wireless/ti/wlcore/spi.c +++ b/drivers/net/wireless/ti/wlcore/spi.c @@ -92,6 +92,7 @@ static const struct wilink_family_data wl128x_data = { static const struct wilink_family_data wl18xx_data = { .name = "wl18xx", .cfg_name = "ti-connectivity/wl18xx-conf.bin", + .nvs_name = "ti-connectivity/wl1271-nvs.bin", }; struct wl12xx_spi_glue { diff --git a/drivers/net/wireless/ti/wlcore/wlcore.h b/drivers/net/wireless/ti/wlcore/wlcore.h index 1827546..95fbedc 100644 --- a/drivers/net/wireless/ti/wlcore/wlcore.h +++ b/drivers/net/wireless/ti/wlcore/wlcore.h @@ -40,6 +40,9 @@ /* wl12xx/wl18xx maximum transmission power (in dBm) */ #define WLCORE_MAX_TXPWR25 +/* Texas Instruments pre assigned OUI */ +#define WLCORE_TI_OUI_ADDRESS 0x080028 + /* forward declaration */ struct wl1271_tx_hw_descr; enum wl_rx_buf_align; -- 2.7.4
Re: [v5] wlcore: add missing nvs file name info for wilink8
* Reizer, Eyal [170807 00:32]: > The following commits: > c815fde wlcore: spi: Populate config firmware data > d776fc8 wlcore: sdio: Populate config firmware data > > Populated the nvs entry for wilink6 and wilink7 only while it is > still needed for wilink8 as well. > This broke user space backward compatibility when upgrading from older > kernels, as the alternate mac address would not be read from the nvs that is > present in the file system (lib/firmware/ti-connectivity/wl1271-nvs.bin) > causing mac address change of the wlan interface. > > This patch fix this and update the structure field with the same default > nvs file name that has been used before. > > In addition, some distros hold a default wl1271-nvs.bin in the file > system with a bogus mac address (deadbeef...) that for a wl18xx device > also overrides the mac address that is stored inside the device. > Warn users about this bogus mac address and use a random mac instead Hmm looks pretty good to me except for one more thing I just noticed. Why don't you just use the hardware mac address instead of a random mac address on wl18xx device when you see a bogus nvs file? Regards, Tony
RE: [v5] wlcore: add missing nvs file name info for wilink8
Hi Tony, > > * Reizer, Eyal [170807 00:32]: > > The following commits: > > c815fde wlcore: spi: Populate config firmware data > > d776fc8 wlcore: sdio: Populate config firmware data > > > > Populated the nvs entry for wilink6 and wilink7 only while it is > > still needed for wilink8 as well. > > This broke user space backward compatibility when upgrading from older > > kernels, as the alternate mac address would not be read from the nvs that > is > > present in the file system (lib/firmware/ti-connectivity/wl1271-nvs.bin) > > causing mac address change of the wlan interface. > > > > This patch fix this and update the structure field with the same default > > nvs file name that has been used before. > > > > In addition, some distros hold a default wl1271-nvs.bin in the file > > system with a bogus mac address (deadbeef...) that for a wl18xx device > > also overrides the mac address that is stored inside the device. > > Warn users about this bogus mac address and use a random mac instead > > Hmm looks pretty good to me except for one more thing I just noticed. > > Why don't you just use the hardware mac address instead of a random > mac address on wl18xx device when you see a bogus nvs file? > I agree that this would have been better but the problem is that hardware mac address is available for wilink8 onlyWilink6/7 don't have one stored. The wlcore code responsible for handling mac address is common code and there is method for detecting between them in this module. Best Regards, Eyal
[PATCH] brcmfmac: add setting carrier state ON for successful roaming
From: Chung-Hsien Hsu After association, ping is not working when sweeping the channel at the AP side. It is caused by having incorrect carrier state (OFF) for the STA in successful roaming. This patch sets the carrier state ON for the case. Signed-off-by: Chung-Hsien Hsu --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c index 617199c..71f18b9 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c @@ -5552,10 +5552,13 @@ static s32 brcmf_get_assoc_ies(struct brcmf_cfg80211_info *cfg, u32 status = e->status; if (event == BRCMF_E_ROAM && status == BRCMF_E_STATUS_SUCCESS) { - if (test_bit(BRCMF_VIF_STATUS_CONNECTED, &ifp->vif->sme_state)) + if (test_bit(BRCMF_VIF_STATUS_CONNECTED, +&ifp->vif->sme_state)) { brcmf_bss_roaming_done(cfg, ifp->ndev, e); - else + } else { brcmf_bss_connect_done(cfg, ifp->ndev, e, true); + brcmf_net_setcarrier(ifp, true); + } } return 0; -- 1.9.1
[PATCH] wireless-regdb: Update regulatory rules for Singapore (SG)
2.4GHz and the lower 5GHz band can now be use with up to 23dBm. But the DFS channels in general require TPC to be usable. Only 5150 - 5250 has an exception which allows the use of it without TPC when reducing the power to 20 dBm. Signed-off-by: Sven Eckelmann --- Please check this twice because this is my first attempt in converting an official regulatory document to an wireless-regdb entry. db.txt | 15 ++- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/db.txt b/db.txt index 0bc068e..df30f37 100644 --- a/db.txt +++ b/db.txt @@ -1078,12 +1078,17 @@ country SE: DFS-ETSI # 60 GHz band channels 1-4, ref: Etsi En 302 567 (57000 - 66000 @ 2160), (40) +# Source +# https://www.imda.gov.sg/~/media/imda/files/regulation%20licensing%20and%20consultations/ict%20standards/telecommunication%20standards/radio-comms/imdatssrd.pdf?la=en +# page 12-14 +# The EIRP for 5250 – 5350 can be increased by 3dB if TPC is implemented. country SG: DFS-FCC - (2402 - 2482 @ 40), (20) - (5170 - 5250 @ 80), (17), AUTO-BW - (5250 - 5330 @ 80), (24), DFS, AUTO-BW - (5490 - 5730 @ 160), (24), DFS - (5735 - 5835 @ 80), (30) + (2400 - 2483.5 @ 40), (23) + (5150 - 5250 @ 80), (23), AUTO-BW + (5250 - 5350 @ 80), (20), DFS, AUTO-BW + # 5470 - 5725 is only allowed when TPC is implemented + # (5470 - 5725 @ 160), (30), DFS + (5725 - 5850 @ 80), (30) country SI: DFS-ETSI (2402 - 2482 @ 40), (20) -- 2.11.0
Re: [PATCH 00/10] mac80211 patches from our internal tree 2017-08-05
Luca Coelho writes: > Here are some pending mac80211 patches from our internal tree. > > The "mac80211: add api to start ba session timer expired flow" patch > is needed by an iwlwifi patch that I want to send for -fixes, so it > would have to be applied to -fixes as well. We are getting to the later stages of the release cycle and I'm raising the bar for wireless-drivers even higher. How serious iwlwifi bug is that fixing? > Should I send a separate patchset with these two so they can be both > applied at the same time (either in the mac80211 or in > wireless-drivers tree)? Now that Johannes is away and I'm taking any urgent mac80211 patches, I think the best approach is that you include mac80211 patch in the same patchset as the iwlwifi patches destined for wireless-drivers. -- Kalle Valo
Re: [PATCH 00/10] mac80211 patches from our internal tree 2017-08-05
On Mon, 2017-08-07 at 12:06 +0300, Kalle Valo wrote: > Luca Coelho writes: > > > Here are some pending mac80211 patches from our internal tree. > > > > The "mac80211: add api to start ba session timer expired flow" patch > > is needed by an iwlwifi patch that I want to send for -fixes, so it > > would have to be applied to -fixes as well. > > We are getting to the later stages of the release cycle and I'm raising > the bar for wireless-drivers even higher. How serious iwlwifi bug is > that fixing? The problem is a bad degradation in throughput with our new 9000 family of devices because when aggregation times out we stop the aggregation internally in the firmware but don't send a delba. Then on the AP side, also with our driver, we don't handle the timeout as we should, so aggregations the devices get out of sync and BA sessions are not possible anymore, limiting our throughput to ~30Mbps, in some specific internal tests. > > Should I send a separate patchset with these two so they can be both > > applied at the same time (either in the mac80211 or in > > wireless-drivers tree)? > > Now that Johannes is away and I'm taking any urgent mac80211 patches, I > think the best approach is that you include mac80211 patch in the same > patchset as the iwlwifi patches destined for wireless-drivers. Okay, if you think the (one-liner) iwlwifi driver fix is -rc'able, I'll resend this in a patchset including both changes. -- Cheers, Luca.
Assalamualikum.
Greetings from Mr. Abdul Karim. Assalamu`Alaikum. My Name is Mr. Abdul Karim I am a banker by profession. I'm from Ouagadougou, Burkina Faso, West Africa. My reason for contacting you is to transfer an abandoned $15.5M to your account. The owner of this fund died since 2004 with his Next Of Kin. I want to present you to the bank as the Next of Kin/beneficiary of this fund. Further details of the transaction shall be forwarded to you as soon as I receive your return mail indicating your interest. 1) YOUR FULL NAME... (2) YOUR AGE AND SEX (3) YOUR CONTACT ADDRESS.. (4) YOUR PRIVATE PHONE N0.. (5) FAX NUMBER.. (6) YOUR COUNTRY OF ORIGIN.. (7) YOUR OCCUPATION. Have a great day, Mr. Abdul Karim
Re: [PATCH 15/34] brcmfamc: remove unnecessary call to brcmf_sdiod_set_backplane_window()
On 7/26/2017 10:25 PM, Ian Molton wrote: All functions that might require the window address changing call brcmf_sdiod_set_backplane_window() prior to access. Thus resetting the window is not required. Acked-by: Arend van Spriel Signed-off-by: Ian Molton --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 5 - 1 file changed, 5 deletions(-)
Re: [PATCH 01/34] brcmfmac: Fix parameter order in brcmf_sdiod_f0_writeb()
Hi Ian, So it took me a while to get to this patch series. It is indeed way to big and not well structured making it difficult to review the patches on a per-patch basis. I decided to limit myself to looking at the patches involving bcmsdh.c doing a 'git log bcmsdh.c' on the applied patches. Still twenty patches to review. I reviewed the first 15 patches of the series and skipped patch [13/34] as it did not touch bcmsdh.c. A few response already slipped to the mailing list so I will post the rest shortly. Here is the first one. On 26-07-17 22:25, Ian Molton wrote: All the other IO functions are the other way round in this driver. Make this one match. Core SDIO functions are indeed the other way around, but the IO functions in this file use (addr, data) pattern. So should we aim to get it all consistent with core SDIO or just consistent on its own. Signed-off-by: Ian Molton --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c index 984c1d0560b1..f585dfd89453 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c @@ -230,8 +230,8 @@ void brcmf_sdiod_change_state(struct brcmf_sdio_dev *sdiodev, sdiodev->state = state; } -static inline int brcmf_sdiod_f0_writeb(struct sdio_func *func, - uint regaddr, u8 byte) +static inline int brcmf_sdiod_f0_writeb(struct sdio_func *func, u8 byte, + uint regaddr) The second line needs to be aligned on same column as the opening bracket. Regards, Arend
Re: [PATCH 02/34] brcmfmac: Register sizes on hardware are not dependent on compiler types
On 26-07-17 22:25, Ian Molton wrote: The 4 IO functions in this patch are incorrect as they use compiler types to determine how many bytes to send to the hardware. I see no incorrectness here. It is validating the regsz value and those compiler types are pretty well defined I would say. Anyway, I find the use of sizeof() here pretty useless so thanks for the change. Reviewed-by: Arend van Spriel Signed-off-by: Ian Molton --- .../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 22 +++--- 1 file changed, 11 insertions(+), 11 deletions(-)
Re: [PATCH 07/34] brcmfmac: Remove brcmf_sdiod_request_data()
On 26-07-17 22:25, Ian Molton wrote: This function is obfuscating how IO works on this chip. Remove it and push its logic into brcmf_sdiod_reg_{read,write}(). Handling of -ENOMEDIUM is altered, but as that's pretty much broken anyway we can ignore that. Please explain why you think it is broken. Reviewed-by: Arend van Spriel Signed-off-by: Ian Molton more comments below. # Conflicts: # drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c --- .../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 239 - .../wireless/broadcom/brcm80211/brcmfmac/sdio.h| 2 +- 2 files changed, 87 insertions(+), 154 deletions(-) diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c index d217b1281e0d..f703d7be6a85 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c [...] static int brcmf_sdiod_reg_write(struct brcmf_sdio_dev *sdiodev, u32 addr, u8 regsz, void *data) { - u8 func; - s32 retry = 0; int ret; - if (sdiodev->state == BRCMF_SDIOD_NOMEDIUM) - return -ENOMEDIUM; - /* * figure out how to read the register based on address range * 0x00 ~ 0x7FF: function 0 CCCR and FBR * 0x1 ~ 0x1: function 1 miscellaneous registers * The rest: function 1 silicon backplane core registers +* f0 writes must be bytewise */ - if ((addr & ~REG_F0_REG_MASK) == 0) - func = SDIO_FUNC_0; - else - func = SDIO_FUNC_1; - - do { - /* for retry wait for 1 ms till bus get settled down */ - if (retry) - usleep_range(1000, 2000); - ret = brcmf_sdiod_request_data(sdiodev, func, addr, regsz, - data, true); - - } while (ret != 0 && ret != -ENOMEDIUM && -retry++ < SDIOH_API_ACCESS_RETRY_LIMIT); + if ((addr & ~REG_F0_REG_MASK) == 0) { + if (WARN_ON(regsz > 1)) + return -EINVAL; + ret = brcmf_sdiod_f0_writeb(sdiodev->func[0], *(u8 *)data, addr); + } else { + switch (regsz) { + case 1: + sdio_writeb(sdiodev->func[1], *(u8 *)data, addr, &ret); + break; + case 4: + ret = brcmf_sdiod_addrprep(sdiodev, &addr); + if (ret) + goto done; - if (ret == -ENOMEDIUM) - brcmf_sdiod_change_state(sdiodev, BRCMF_SDIOD_NOMEDIUM); + sdio_writel(sdiodev->func[1], *(u32 *)data, addr, &ret); + break; + default: + BUG(); Please do not use BUG() as it simply crashes the system. You may argue that we never reach this unless a coding mistake is made, but still we prefer WARN() over BUG() in such cases. + ret = -EINVAL; + break; + } + } +done: return ret; } static int brcmf_sdiod_reg_read(struct brcmf_sdio_dev *sdiodev, u32 addr, u8 regsz, void *data) { - u8 func; - s32 retry = 0; int ret; - if (sdiodev->state == BRCMF_SDIOD_NOMEDIUM) - return -ENOMEDIUM; - /* * figure out how to read the register based on address range * 0x00 ~ 0x7FF: function 0 CCCR and FBR * 0x1 ~ 0x1: function 1 miscellaneous registers * The rest: function 1 silicon backplane core registers +* f0 reads must be bytewise */ - if ((addr & ~REG_F0_REG_MASK) == 0) - func = SDIO_FUNC_0; - else - func = SDIO_FUNC_1; - - do { - memset(data, 0, regsz); - - /* for retry wait for 1 ms till bus get settled down */ - if (retry) - usleep_range(1000, 2000); - - ret = brcmf_sdiod_request_data(sdiodev, func, addr, regsz, - data, false); - - } while (ret != 0 && ret != -ENOMEDIUM && -retry++ < SDIOH_API_ACCESS_RETRY_LIMIT); - - if (ret == -ENOMEDIUM) - brcmf_sdiod_change_state(sdiodev, BRCMF_SDIOD_NOMEDIUM); - - return ret; -} - -static int -brcmf_sdiod_set_sbaddr_window(struct brcmf_sdio_dev *sdiodev, u32 address) -{ - int err = 0, i; - u32 addr; - - if (sdiodev->state == BRCMF_SDIOD_NOMEDIUM) - return -ENOMEDIUM; - - addr = (address & SBSDIO_SBWINDOW_MASK) >> 8; - - for (i = 0 ; i < 3 && !err ; i++, addr >>= 8) - brcmf_sdiod_regwb(sdiodev, SBSDIO_FUNC1_SBADDRLOW + i, -
Re: [PATCH 05/34] brcmfmac: Remove dead IO code
On 26-07-17 22:25, Ian Molton wrote: The value passed to brcmf_sdiod_addrprep() is *always* 4 remove this parameter and the unused code to handle it. Reviewed-by: Arend van Spriel Signed-off-by: Ian Molton --- .../net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 18 -- 1 file changed, 8 insertions(+), 10 deletions(-)
Re: [PATCH 06/34] brcmfmac: Remove bandaid for SleepCSR
On 26-07-17 22:25, Ian Molton wrote: Register access code is not the place for band-aid fixes like this. If this is a genuine problem, it should be fixed further up in the driver stack. So lets make it a SDIO debug message for all register accesses getting rid of the error message. Reviewed-by: Arend van Spriel Signed-off-by: Ian Molton # Conflicts: # drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c --- .../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 28 +- 1 file changed, 1 insertion(+), 27 deletions(-)
Re: [PATCH 10/34] brcmfmac: Rename bcmerror to err
On 7/26/2017 10:25 PM, Ian Molton wrote: Trivial cleanup of nasty variable name Did not look, but here is... Acked-by: Arend van Spriel Signed-off-by: Ian Molton --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-)
Re: [PATCH 08/34] brcmfmac: Fix uninitialised variable
On 7/26/2017 10:25 PM, Ian Molton wrote: Unlikely to be a problem, but brcmf_sdiod_regrb() is not symmetric with brcmf_sdiod_regrl() in this regard. You are pretty keen on symmetry, but you could also remove the initialization in brcmf_sdiod_regrl(). As long as no -Wunitialized pops up that would have my preference. Reviewed-by: Arend van Spriel Signed-off-by: Ian Molton --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Re: [PATCH 03/34] brcmfmac: Split brcmf_sdiod_regrw_helper() up.
On 26-07-17 22:25, Ian Molton wrote: This large function is concealing a LOT of obscure logic about how the hardware functions. Time to split it up. This first patch splits the function into two pieces - read and write, doing away with the rw flag in the process. I really don't this it is all that obscure, but alas. Everything is in the eye of the beholder. The reason for having the helper was to not duplicate code for read and write and different access sizes. So now you are duplicating it. In subsequent patches you throw away pieces of this helper so duplication is not as bad in the net result. It would have been easier if those patches were done before this one. Reviewed-by: Arend van Spriel Signed-off-by: Ian Molton some minor comment below --- .../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 94 +- 1 file changed, 73 insertions(+), 21 deletions(-) diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c index 2b441ce91d5f..1ee0f91b6c50 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c @@ -302,8 +302,8 @@ static int brcmf_sdiod_request_data(struct brcmf_sdio_dev *sdiodev, u8 fn, return ret; } -static int brcmf_sdiod_regrw_helper(struct brcmf_sdio_dev *sdiodev, u32 addr, - u8 regsz, void *data, bool write) +static int brcmf_sdiod_reg_write(struct brcmf_sdio_dev *sdiodev, u32 addr, +u8 regsz, void *data) Fix the indent and column align to opening bracket. Regards, Arend
Re: [PATCH 09/34] brcmfmac: Remove noisy debugging.
On 7/26/2017 10:25 PM, Ian Molton wrote: If you need debugging this low level, you're doing something wrong. Remove these noisy debug statements so the code is more readable. Needing this debugging does not necessarily means you are doing something wrong. You may be dealing with hardware that is doing something wrong and when that happens this debug can be useful. I frankly hardly ever enable SDIO debug level unless I am in that scenario. Maybe adding a debug level for low-level access would be useful to reduce the noise for SDIO debug level. Regards, Arend Signed-off-by: Ian Molton --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-)
Re: [PATCH 11/34] brcmfmac: Split brcmf_sdiod_buffrw function up.
On 7/26/2017 10:25 PM, Ian Molton wrote: This function needs to be split up into separate read / write variants for clarity. Reviewed-by: Arend van Spriel Signed-off-by: Ian Molton more comments below... # Conflicts: # drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c --- .../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 69 +++--- 1 file changed, 47 insertions(+), 22 deletions(-) diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c index 9d5716d0ad73..858ad2d8706b 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c [...] @@ -706,10 +725,10 @@ int brcmf_sdiod_send_buf(struct brcmf_sdio_dev *sdiodev, u8 *buf, uint nbytes) err = brcmf_sdiod_addrprep(sdiodev, &addr); if (!err) - err = brcmf_sdiod_buffrw(sdiodev, SDIO_FUNC_2, true, addr, -mypkt); + err = brcmf_sdiod_buff_write(sdiodev, SDIO_FUNC_2, addr, mypkt); brcmu_pkt_buf_free_skb(mypkt); + You are keen on sprinkling whitespace here and there. Could you please use separate patches for that as much as possible. Not sure why you added this one... return err; ...and kept this one. }
Re: [PATCH 12/34] brcmfmac: Replace old IO functions with simpler ones.
On 7/26/2017 10:25 PM, Ian Molton wrote: Primarily this patch removes: brcmf_sdiod_f0_writeb() brcmf_sdiod_reg_write() brcmf_sdiod_reg_read() Having [patch 30/34] "brcmfmac: Correctly handle accesses to SDIO func0" before this patch could make this look cleaner. Since we no longer use the quirky method of deciding which function to address via the address being accessed, take the opportunity to rename some IO functions more in line with common kernel code. As mentioned here this is more a rename than a replace so please use that in the subject as well. Reviewed-by: Arend van Spriel Signed-off-by: Ian Molton --- .../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 166 +++ .../wireless/broadcom/brcm80211/brcmfmac/sdio.c| 182 ++--- .../wireless/broadcom/brcm80211/brcmfmac/sdio.h| 28 +++- 3 files changed, 132 insertions(+), 244 deletions(-)
Re: [PATCH 14/34] brcmfmac: Remove brcmf_sdiod_addrprep()
On 7/26/2017 10:25 PM, Ian Molton wrote: This function has become trivial enough that it may as well be pushed into its callers, which has the side-benefit of clarifying what's going on. Remove it, and rename brcmf_sdiod_set_sbaddr_window() to brcmf_sdiod_set_backplane_window() as it's easier to understand. Reviewed-by: Arend van Spriel Signed-off-by: Ian Molton comments below... # Conflicts: # drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c --- .../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 78 -- 1 file changed, 44 insertions(+), 34 deletions(-) diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c index b2945b463fd3..24775869aee4 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c @@ -228,41 +228,25 @@ void brcmf_sdiod_change_state(struct brcmf_sdio_dev *sdiodev, sdiodev->state = state; } -static int brcmf_sdiod_set_sbaddr_window(struct brcmf_sdio_dev *sdiodev, -u32 address) +static int +brcmf_sdiod_set_backplane_window(struct brcmf_sdio_dev *sdiodev, u32 addr) { + u32 v, bar0 = addr & SBSDIO_SBWINDOW_MASK; int err = 0, i; - u32 addr; - if (sdiodev->state == BRCMF_SDIOD_NOMEDIUM) - return -ENOMEDIUM; So now you are dropping the state check here, which seems significant enough to mention in the commit log. We need to discuss that. The idea of it was to refrain from using IO function of the MMC stack when we no there is no longer a device, ie. when stack has previously returned a -ENOMEDIUM. + if (bar0 == sdiodev->sbwad) + return 0; - addr = (address & SBSDIO_SBWINDOW_MASK) >> 8; + v = bar0 >> 8; why introducing a new variable on the stack. You actually don't need any and just mask and shift the addr variable passed to the function. - for (i = 0 ; i < 3 && !err ; i++, addr >>= 8) + for (i = 0 ; i < 3 && !err ; i++, v >>= 8) brcmf_sdiod_writeb(sdiodev, SBSDIO_FUNC1_SBADDRLOW + i, - addr & 0xff, &err); - - return err; -} - -static int brcmf_sdiod_addrprep(struct brcmf_sdio_dev *sdiodev, u32 *addr) -{ - uint bar0 = *addr & ~SBSDIO_SB_OFT_ADDR_MASK; - int err = 0; - - if (bar0 != sdiodev->sbwad) { - err = brcmf_sdiod_set_sbaddr_window(sdiodev, bar0); - if (err) - return err; + v & 0xff, &err); + if (!err) sdiodev->sbwad = bar0; - } - - *addr &= SBSDIO_SB_OFT_ADDR_MASK; - *addr |= SBSDIO_SB_ACCESS_2_4B_FLAG; - return 0; + return err; } u32 brcmf_sdiod_readl(struct brcmf_sdio_dev *sdiodev, u32 addr, int *ret) @@ -270,11 +254,17 @@ u32 brcmf_sdiod_readl(struct brcmf_sdio_dev *sdiodev, u32 addr, int *ret) u32 data = 0; int retval; - retval = brcmf_sdiod_addrprep(sdiodev, &addr); + retval = brcmf_sdiod_set_backplane_window(sdiodev, addr); + if (retval) + goto out; + + addr &= SBSDIO_SB_OFT_ADDR_MASK; + addr |= SBSDIO_SB_ACCESS_2_4B_FLAG; if (!retval) data = sdio_readl(sdiodev->func[1], addr, &retval); The if-statement is now redundant here... +out: if (ret) *ret = retval; @@ -286,11 +276,17 @@ void brcmf_sdiod_writel(struct brcmf_sdio_dev *sdiodev, u32 addr, { int retval; - retval = brcmf_sdiod_addrprep(sdiodev, &addr); + retval = brcmf_sdiod_set_backplane_window(sdiodev, addr); + if (retval) + goto out; + + addr &= SBSDIO_SB_OFT_ADDR_MASK; + addr |= SBSDIO_SB_ACCESS_2_4B_FLAG; if (!retval) sdio_writel(sdiodev->func[1], data, addr, &retval); ...and here. +out: if (ret) *ret = retval; }
Re: [PATCH 15/34] brcmfamc: remove unnecessary call to brcmf_sdiod_set_backplane_window()
On 8/7/2017 1:11 PM, Arend van Spriel wrote: On 7/26/2017 10:25 PM, Ian Molton wrote: All functions that might require the window address changing call brcmf_sdiod_set_backplane_window() prior to access. Thus resetting the window is not required. Actually noticed a minor nit. The subject says "brcmfamc". Regards, Arend Acked-by: Arend van Spriel Signed-off-by: Ian Molton --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 5 - 1 file changed, 5 deletions(-)
Re: [PATCH v2 1/3] brcmfmac: set wpa_auth to WPA_AUTH_DISABLED in AP/OPEN security mode
On 8/3/2017 11:37 AM, Wright Feng wrote: brcmfmac: set wpa_auth to WPA_AUTH_DISABLED in AP/OPEN security mode When setting wpa_auth to WPA_AUTH_NONE(1) in AP mode with WEP security, firmware will set privacy bit and add WPA OUI in VENDOR IE in beacon and probe response. The security type in softAP beacons confuse the supplicant in client side, and the user client will see [WPA-?] in supplicant scan result. So we set WPA_AUTH_DISABLED in softAP mode with OPEN security. Acked-by: Arend van Spriel Signed-off-by: Wright Feng --- v2: fix typo in commit message --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-)
Re: [PATCH v2 2/3] brcmfmac: Add support for CYW4373 SDIO/USB chipset
On 8/3/2017 11:37 AM, Wright Feng wrote: From: Chi-Hsien Lin Add support for CYW4373 SDIO/USB chipset. CYW4373 is a 1x1 dual-band 11ac chipset with 20/40/80Mhz channel support. It's a WiFi/BT combo device. Reviewed-by: Arend van Spriel Signed-off-by: Chi-Hsien Lin --- v2: add new chip(4737) info in commit message comment below... --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 1 + drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c | 2 ++ drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 4 +++- drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c| 9 - drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h | 3 +++ include/linux/mmc/sdio_ids.h | 1 + 6 files changed, 18 insertions(+), 2 deletions(-) [...] diff --git a/include/linux/mmc/sdio_ids.h b/include/linux/mmc/sdio_ids.h index b733eb4..abacd54 100644 --- a/include/linux/mmc/sdio_ids.h +++ b/include/linux/mmc/sdio_ids.h @@ -39,6 +39,7 @@ #define SDIO_DEVICE_ID_BROADCOM_43455 0xa9bf #define SDIO_DEVICE_ID_BROADCOM_4354 0x4354 #define SDIO_DEVICE_ID_BROADCOM_4356 0x4356 +#define SDIO_DEVICE_ID_CYPRESS_43730x4373 So is there no specific Cypress SDIO vendor ID? #define SDIO_VENDOR_ID_INTEL 0x0089 #define SDIO_DEVICE_ID_INTEL_IWMC3200WIMAX0x1402
Re: [PATCH 29/34] brcmfmac: stabilise the value of ->sbwad in use for some xfer routines.
So now I jump to this patch On 7/26/2017 10:25 PM, Ian Molton wrote: The IO functions operate within the Chipcommon IO window. Explicitly set this, rather than relying on the last initialisation IO access to leave it set to the right value by chance. Signed-off-by: Ian Molton --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 8 drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 5 + drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h | 1 + 3 files changed, 10 insertions(+), 4 deletions(-) [...] diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h index fb4f24dfc99d..1ab95011adb0 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h @@ -178,6 +178,7 @@ struct brcmf_sdio_dev { struct sdio_func *func[SDIO_MAX_FUNCS]; u8 num_funcs; /* Supported funcs on client */ u32 sbwad; /* Save backplane window address */ + struct brcmf_core *cc_core; /* chipcommon core info struct */ We actually just need the chipcommon base address so why not have that here, ie.: + u32 cc_base; Another option is to simple use SI_ENUM_BASE as the chipcommon base address will always be 0x1800 for the SDIO chips. struct brcmf_sdio *bus; struct device *dev; struct brcmf_bus *bus_if;
Re: [PATCH v2 3/3] brcmfmac: fix wrong num_different_channels when mchan feature enabled
On 8/3/2017 11:37 AM, Wright Feng wrote: brcmfmac: fix wrong num_different_channels when mchan feature enabled When the device/firmware supports multi-channel, it can have P2P connection and regular connection with AP simultaneous. In this case, the num_different_channels in wiphy info was not correct when firmware supports multi-channel (The iw wiphy# info showed "#channels <= 1" in interface combinations). It caused association failed and error message "CTRL-EVENT-FREQ-CONFLICT error" in wpa_supplicant when P2P GO interface was running at the same time. The root cause is that the num_different_channels was always overridden to 1 in brcmf_setup_ifmodes even multi-channel was enabled. We correct the logic by moving num_different_channels setting forward. Acked-by: Arend van Spriel Signed-off-by: Wright Feng --- v2: Describe the motivation and reason for this patch in commit message --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
Re: [v5] wlcore: add missing nvs file name info for wilink8
"Reizer, Eyal" writes: > The following commits: > c815fde wlcore: spi: Populate config firmware data > d776fc8 wlcore: sdio: Populate config firmware data It's recommended to use 12 chars when abbreviating commit ids so the format should be this: c815fdebef44 wlcore: spi: Populate config firmware data d776fc86b82f wlcore: sdio: Populate config firmware data > Populated the nvs entry for wilink6 and wilink7 only while it is > still needed for wilink8 as well. > This broke user space backward compatibility when upgrading from older > kernels, as the alternate mac address would not be read from the nvs that is > present in the file system (lib/firmware/ti-connectivity/wl1271-nvs.bin) > causing mac address change of the wlan interface. > > This patch fix this and update the structure field with the same default > nvs file name that has been used before. > > In addition, some distros hold a default wl1271-nvs.bin in the file > system with a bogus mac address (deadbeef...) that for a wl18xx device > also overrides the mac address that is stored inside the device. > Warn users about this bogus mac address and use a random mac instead > > Cc: stable > Signed-off-by: Eyal Reizer It's always good to have a fixes line(s) and specify which stable versions should have the fix. As the commit were first in v4.9-rc1 that's the first version we want this to be included: Fixes: c815fdebef44 ("wlcore: spi: Populate config firmware data") Fixes: d776fc86b82f ("wlcore: sdio: Populate config firmware data") Cc: # 4.9+ But if you don't submit a new version I can fix the commit log during commit. -- Kalle Valo
Re: [PATCH] brcmfmac: add setting carrier state ON for successful roaming
On 8/7/2017 10:16 AM, Wright Feng wrote: From: Chung-Hsien Hsu After association, ping is not working when sweeping the channel at the AP side. It is caused by having incorrect carrier state (OFF) for the STA in successful roaming. This patch sets the carrier state ON for the case. This seems a specific scenario where the initial connect attempt by the host actually results in the firmware roaming, ie. switching to another AP, before completing the connection. Still it is needed here so ... Acked-by: Arend van Spriel Signed-off-by: Chung-Hsien Hsu --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c index 617199c..71f18b9 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c @@ -5552,10 +5552,13 @@ static s32 brcmf_get_assoc_ies(struct brcmf_cfg80211_info *cfg, u32 status = e->status; if (event == BRCMF_E_ROAM && status == BRCMF_E_STATUS_SUCCESS) { - if (test_bit(BRCMF_VIF_STATUS_CONNECTED, &ifp->vif->sme_state)) + if (test_bit(BRCMF_VIF_STATUS_CONNECTED, +&ifp->vif->sme_state)) { brcmf_bss_roaming_done(cfg, ifp->ndev, e); - else + } else { brcmf_bss_connect_done(cfg, ifp->ndev, e, true); + brcmf_net_setcarrier(ifp, true); + } } return 0;
Re: [PATCH v2 09/12] qtnfmac: implement scan timeout
Sergey Matyukevich writes: >> > + if (timer_pending(&mac->scan_timeout)) >> > + del_timer_sync(&mac->scan_timeout); >> >> What if the device is removed while the timer is pending, is that >> handled? > > Good point. I took another look at this kind of corner cases. Timer is not > disabled > explicitely. But ongoing scan request is explicitely aborted in relevant > cfg80211 ops, e.g. on virtual interface change or removal. Though it looks > like > some of AP usecases are not handled: e.g. when AP is stopped while scan is > in progress. I will queue the fix into the next cleanup/bugfix patch series > if it is needed to abort scan in such a case. Good, thanks for checking. -- Kalle Valo
Re: [PATCH 1/3] iwlwifi: mvm: Fix a memory leak in an error handling path in 'iwl_mvm_sar_get_wgds_table()'
Luca Coelho writes: > From: Christophe Jaillet > > We should free 'wgds.pointer' here as done a few lines above in another > error handling path. > It was allocated within 'acpi_evaluate_object()'. > > Fixes: c52030a01ccc ("iwlwifi: mvm: add GEO_TX_POWER_LIMIT cmd for geographic > tx power table") > Signed-off-by: Christophe JAILLET > Signed-off-by: Luca Coelho > --- > drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c > b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c > index 79e7a7a285dc..82863e9273eb 100644 > --- a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c > +++ b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c > @@ -1275,8 +1275,10 @@ static int iwl_mvm_sar_get_wgds_table(struct iwl_mvm > *mvm) > > entry = &wifi_pkg->package.elements[idx++]; > if ((entry->type != ACPI_TYPE_INTEGER) || > - (entry->integer.value > U8_MAX)) > - return -EINVAL; > + (entry->integer.value > U8_MAX)) { > + ret = -EINVAL; > + goto out_free; > + } How likely is this leak to happen in real world? To me it looks like more like a theoretical issue and could have easily waited for 4.14. But it's fine this time, just something to keep in mind in the future. -- Kalle Valo
Re: [PATCH 2/3] iwlwifi: mvm: start mac queues when deferred tx frames are purged
Luca Coelho writes: > From: Avraham Stern > > Under DQA, when tx is deferred because a queue needs to be allocated, > the mac queue for that TID is stopped until the new stream is added. > If at this point the station that this stream belongs to is removed, > all the deferred tx frames are purged, but the mac queue is not > restarted. As a result, all following tx on this queue will not be > transmitted. > > Fix this by starting the relevant mac queues when the deferred tx > frames are purged. > > Fixes: 24afba7690e4 ("iwlwifi: mvm: support bss dynamic alloc/dealloc of > queues") > Signed-off-by: Avraham Stern > Signed-off-by: Luca Coelho The commit log is not really explaining the bug from user's point of view. -- Kalle Valo
Re: [PATCH 00/10] mac80211 patches from our internal tree 2017-08-05
Luca Coelho writes: > On Mon, 2017-08-07 at 12:06 +0300, Kalle Valo wrote: >> Luca Coelho writes: >> >> > Here are some pending mac80211 patches from our internal tree. >> > >> > The "mac80211: add api to start ba session timer expired flow" patch >> > is needed by an iwlwifi patch that I want to send for -fixes, so it >> > would have to be applied to -fixes as well. >> >> We are getting to the later stages of the release cycle and I'm raising >> the bar for wireless-drivers even higher. How serious iwlwifi bug is >> that fixing? > > The problem is a bad degradation in throughput with our new 9000 family > of devices because when aggregation times out we stop the aggregation > internally in the firmware but don't send a delba. Then on the AP side, > also with our driver, we don't handle the timeout as we should, so > aggregations the devices get out of sync and BA sessions are not > possible anymore, limiting our throughput to ~30Mbps, in some specific > internal tests. Ok. >> > Should I send a separate patchset with these two so they can be both >> > applied at the same time (either in the mac80211 or in >> > wireless-drivers tree)? >> >> Now that Johannes is away and I'm taking any urgent mac80211 patches, I >> think the best approach is that you include mac80211 patch in the same >> patchset as the iwlwifi patches destined for wireless-drivers. > > Okay, if you think the (one-liner) iwlwifi driver fix is -rc'able, I'll > resend this in a patchset including both changes. If the iwlwifi patch is a oneliner it doesn't sound too bad, but I reserve the right to change my mind :) But try to submit the pull request in the next few days so that I can submit the patches forward by end of this week. And I think it's easiest that you apply the mac80211 patch directly to your tree and I just pull from you. -- Kalle Valo
Re: [PATCH 04/19] iwlwifi: mvm: add debugfs to force CT-kill
Luca Coelho writes: > From: Chaya Rachel Ivgi > > In order to test the enter/exit CT-kill flow. > > Signed-off-by: Chaya Rachel Ivgi > Signed-off-by: Luca Coelho The commit log doesn't explain what's CT-kill and how/where it could be used. For example, I have no clue what this could be about. -- Kalle Valo
Re: [PATCH 1/3] iwlwifi: mvm: Fix a memory leak in an error handling path in 'iwl_mvm_sar_get_wgds_table()'
On Mon, 2017-08-07 at 15:57 +0300, Kalle Valo wrote: > Luca Coelho writes: > > > From: Christophe Jaillet > > > > We should free 'wgds.pointer' here as done a few lines above in another > > error handling path. > > It was allocated within 'acpi_evaluate_object()'. > > > > Fixes: c52030a01ccc ("iwlwifi: mvm: add GEO_TX_POWER_LIMIT cmd for > > geographic tx power table") > > Signed-off-by: Christophe JAILLET > > Signed-off-by: Luca Coelho > > --- > > drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 6 -- > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c > > b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c > > index 79e7a7a285dc..82863e9273eb 100644 > > --- a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c > > +++ b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c > > @@ -1275,8 +1275,10 @@ static int iwl_mvm_sar_get_wgds_table(struct iwl_mvm > > *mvm) > > > > entry = &wifi_pkg->package.elements[idx++]; > > if ((entry->type != ACPI_TYPE_INTEGER) || > > - (entry->integer.value > U8_MAX)) > > - return -EINVAL; > > + (entry->integer.value > U8_MAX)) { > > + ret = -EINVAL; > > + goto out_free; > > + } > > How likely is this leak to happen in real world? To me it looks like > more like a theoretical issue and could have easily waited for 4.14. But > it's fine this time, just something to keep in mind in the future. This is a one-liner fix and I consider memory leaks serious enough to deserve a fix for rc5. This bug can happen with broken ACPI tables and, trust me, broken ACPI tables are not that hard to find. But you rule here, feel free to NACK my patches whenever you see fit! :) -- Cheers, Luca.
Re: [PATCH 12/19] iwlwifi: mvm: support new beacon template command
Luca Coelho writes: > From: Haim Dreyfuss > > Support new version of beacon template command. This rplaces v8 command typo: "rplaces" -- Kalle Valo
Re: [PATCH 04/19] iwlwifi: mvm: add debugfs to force CT-kill
On Mon, 2017-08-07 at 16:11 +0300, Kalle Valo wrote: > Luca Coelho writes: > > > From: Chaya Rachel Ivgi > > > > In order to test the enter/exit CT-kill flow. > > > > Signed-off-by: Chaya Rachel Ivgi > > Signed-off-by: Luca Coelho > > The commit log doesn't explain what's CT-kill and how/where it could be > used. For example, I have no clue what this could be about. You're right, sorry for that. I'll update the commit log and submit v2. Basically CT-kill is a thermal "RF-kill". Whenever the NIC gets too hot, we shut it down to prevent further damage. This is nothing new. What this patch is adding is a fake way to simulate the NIC getting too hot by kicking off a debugfs entry, in the same way the FW would kick it off by sending a notification to the driver. This is mostly for R&D, but it's very useful for us and I we need it for our internal tests. Not that useful for non-developers but I didn't want to carry this in internal driver to avoid unnecessary conflicts when syncing it with upstream. -- Luca.
Re: [PATCH 04/19] iwlwifi: mvm: add debugfs to force CT-kill
Luca Coelho writes: > On Mon, 2017-08-07 at 16:11 +0300, Kalle Valo wrote: >> Luca Coelho writes: >> >> > From: Chaya Rachel Ivgi >> > >> > In order to test the enter/exit CT-kill flow. >> > >> > Signed-off-by: Chaya Rachel Ivgi >> > Signed-off-by: Luca Coelho >> >> The commit log doesn't explain what's CT-kill and how/where it could be >> used. For example, I have no clue what this could be about. > > You're right, sorry for that. I'll update the commit log and submit v2. > > Basically CT-kill is a thermal "RF-kill". Whenever the NIC gets too > hot, we shut it down to prevent further damage. This is nothing new. > What this patch is adding is a fake way to simulate the NIC getting too > hot by kicking off a debugfs entry, in the same way the FW would kick it > off by sending a notification to the driver. > > This is mostly for R&D, but it's very useful for us and I we need it for > our internal tests. Not that useful for non-developers but I didn't > want to carry this in internal driver to avoid unnecessary conflicts > when syncing it with upstream. Thanks, makes sense now. -- Kalle Valo
Re: [PATCH 1/3] iwlwifi: mvm: Fix a memory leak in an error handling path in 'iwl_mvm_sar_get_wgds_table()'
Luca Coelho writes: > On Mon, 2017-08-07 at 15:57 +0300, Kalle Valo wrote: >> Luca Coelho writes: >> >> > From: Christophe Jaillet >> > >> > We should free 'wgds.pointer' here as done a few lines above in another >> > error handling path. >> > It was allocated within 'acpi_evaluate_object()'. >> > >> > Fixes: c52030a01ccc ("iwlwifi: mvm: add GEO_TX_POWER_LIMIT cmd for >> > geographic tx power table") >> > Signed-off-by: Christophe JAILLET >> > Signed-off-by: Luca Coelho >> > --- >> > drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 6 -- >> > 1 file changed, 4 insertions(+), 2 deletions(-) >> > >> > diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c >> > b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c >> > index 79e7a7a285dc..82863e9273eb 100644 >> > --- a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c >> > +++ b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c >> > @@ -1275,8 +1275,10 @@ static int iwl_mvm_sar_get_wgds_table(struct >> > iwl_mvm *mvm) >> > >> >entry = &wifi_pkg->package.elements[idx++]; >> >if ((entry->type != ACPI_TYPE_INTEGER) || >> > - (entry->integer.value > U8_MAX)) >> > - return -EINVAL; >> > + (entry->integer.value > U8_MAX)) { >> > + ret = -EINVAL; >> > + goto out_free; >> > + } >> >> How likely is this leak to happen in real world? To me it looks like >> more like a theoretical issue and could have easily waited for 4.14. But >> it's fine this time, just something to keep in mind in the future. > > This is a one-liner fix and I consider memory leaks serious enough to > deserve a fix for rc5. This bug can happen with broken ACPI tables and, > trust me, broken ACPI tables are not that hard to find. Sure, anything's possible. But what I'm reading here this is still a theoretical issue, not a leak which we _know_ will happen to thousands of people. > But you rule here, feel free to NACK my patches whenever you see fit! :) I'm trying to minimise the numbers of patches going to wireless-drivers and striving for only fixes which really matter and keep the theoretical stuff for -next. The is mostly selfish reasons as wireless-drivers are a lot more work, especially if there are conflicts. But like I said in my previous mail, no need to drop this. -- Kalle Valo
Re: [PATCH 1/3] iwlwifi: mvm: Fix a memory leak in an error handling path in 'iwl_mvm_sar_get_wgds_table()'
On Mon, 2017-08-07 at 16:37 +0300, Kalle Valo wrote: > Luca Coelho writes: > > > On Mon, 2017-08-07 at 15:57 +0300, Kalle Valo wrote: > > > Luca Coelho writes: > > > > > > > From: Christophe Jaillet > > > > > > > > We should free 'wgds.pointer' here as done a few lines above in another > > > > error handling path. > > > > It was allocated within 'acpi_evaluate_object()'. > > > > > > > > Fixes: c52030a01ccc ("iwlwifi: mvm: add GEO_TX_POWER_LIMIT cmd for > > > > geographic tx power table") > > > > Signed-off-by: Christophe JAILLET > > > > Signed-off-by: Luca Coelho > > > > --- > > > > drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 6 -- > > > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c > > > > b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c > > > > index 79e7a7a285dc..82863e9273eb 100644 > > > > --- a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c > > > > +++ b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c > > > > @@ -1275,8 +1275,10 @@ static int iwl_mvm_sar_get_wgds_table(struct > > > > iwl_mvm *mvm) > > > > > > > > entry = &wifi_pkg->package.elements[idx++]; > > > > if ((entry->type != ACPI_TYPE_INTEGER) || > > > > - (entry->integer.value > U8_MAX)) > > > > - return -EINVAL; > > > > + (entry->integer.value > U8_MAX)) { > > > > + ret = -EINVAL; > > > > + goto out_free; > > > > + } > > > > > > How likely is this leak to happen in real world? To me it looks like > > > more like a theoretical issue and could have easily waited for 4.14. But > > > it's fine this time, just something to keep in mind in the future. > > > > This is a one-liner fix and I consider memory leaks serious enough to > > deserve a fix for rc5. This bug can happen with broken ACPI tables and, > > trust me, broken ACPI tables are not that hard to find. > > Sure, anything's possible. But what I'm reading here this is still a > theoretical issue, not a leak which we _know_ will happen to thousands > of people. > > > But you rule here, feel free to NACK my patches whenever you see fit! :) > > I'm trying to minimise the numbers of patches going to wireless-drivers > and striving for only fixes which really matter and keep the theoretical > stuff for -next. The is mostly selfish reasons as wireless-drivers are a > lot more work, especially if there are conflicts. I totally understand. It's a lot more work for me too, with all the reordering I need to do and the conflicts these cause. > But like I said in my previous mail, no need to drop this. Okay, thanks! -- Cheers, Luca.
pull-request: wireless-drivers-next 2017-08-07
Hi Dave, here's the first pull request to net-next for 4.14, more info in the signed tag below. This time there's a simple conflict in iwlwifi but you can fix it just like Stephen did: https://lkml.kernel.org/r/20170804120408.0d147...@canb.auug.org.au Please let me know if you have any problems. Kalle The following changes since commit 53d56f79a0b2e4bc5bbc04988e5bfde768db604f: Merge branch 'qed-next' (2017-07-27 00:05:23 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git tags/wireless-drivers-next-for-davem-2017-08-07 for you to fetch changes up to 9d546198705a79630cb29b1cc47a43e75b8afb89: rtlwifi: Replace hardcode value with macro (2017-08-03 13:20:43 +0300) wireless-drivers-next patches for 4.14 The first wireless-drivers-next pull request for 4.14. I'm submitting this unusally late in the cycle as my vacation postponed this. But even if this is late there's not still that much new features, mostly cleanup or fixes. Major changes: ath10k * preparation for wcn3990 support iwlwifi * Reorganization of the code into separate directories continues qtnfmac * regulatory support updates * add get_channel, dump_survey and channel_switch cfg80211 handlers Amitkumar Karwar (5): rsi: use BUILD_BUG_ON check for fsm_state rsi: correct the logic of deriving queue number rsi: use macro for allocating USB buffer rsi: check length before USB read/write register rsi: fix static checker warning Arvind Yadav (9): brcmfmac: constify pci_device_id rtlwifi: rtl8192de: constify pci_device_id. rtlwifi: rtl8192se: constify pci_device_id. rtlwifi: rtl8821ae: constify pci_device_id. rtlwifi: rtl8723ae: constify pci_device_id. rtlwifi: rtl8723be: constify pci_device_id. rtlwifi: rtl8188ee: constify pci_device_id. rtlwifi: rtl8192ee: constify pci_device_id. net: qtnfmac: constify pci_device_id. Brian Norris (21): mwifiex: correct channel stat buffer overflows mwifiex: reunite copy-and-pasted remove/reset code mwifiex: reset interrupt status across device reset mwifiex: pcie: don't allow cmd buffer reuse after reset mwifiex: re-register wiphy across reset mwifiex: unregister wiphy before freeing resources mwifiex: don't short-circuit netdev notifiers on interface deletion mwifiex: fixup init_channel_scan_gap error case mwifiex: ensure "disable auto DS" struct is initialized mwifiex: fix misnomers in mwifiex_free_lock_list() mwifiex: make mwifiex_free_cmd_buffer() return void mwifiex: utilize netif_tx_{wake,stop}_all_queues() mwifiex: don't open-code ARRAY_SIZE() mwifiex: drop 'add_tail' param from mwifiex_insert_cmd_to_pending_q() mwifiex: pcie: remove unnecessary masks mwifiex: pcie: unify MSI-X / non-MSI-X interrupt process mwifiex: debugfs: allow card_reset() to cancel things mwifiex: pcie: disable device DMA before unmapping/freeing buffers mwifiex: pcie: remove unnecessary 'pdev' check mwifiex: keep mwifiex_cancel_pending_ioctl() static mwifiex: drop num CPU notice Colin Ian King (5): rtlwifi: kfree entry until after entry->bssid has been accessed mwifiex: usb: fix spelling mistake: "aggreataon"-> "aggregation" mwifiex: fix spelling mistake: "Insuffient" -> "Insufficient" zd1211rw: fix spelling mistake 'hybernate' -> 'hibernate' wl3501_cs: fix spelling mistake: "Insupported" -> "Unsupported" Cong Wang (1): wl1251: add a missing spin_lock_init() Dan Carpenter (2): mwifiex: usb: unlock on error in mwifiex_usb_tx_aggr_tmo() rtlwifi: rtl8821ae: Fix HW_VAR_NAV_UPPER operation Dan Williams (1): ipw2100: don't return positive values to PCI probe on error Emmanuel Grumbach (3): iwlwifi: mvm: fix the FIFO numbers in A000 devices iwlwifi: pcie: fix A-MSDU on gen2 devices iwlwifi: mvm: don't retake the pointer to skb's CB Florian Fainelli (1): bcma: gpio: Correct number of GPIOs for BCM53573 Govind Singh (2): ath10k: make CE layer bus agnostic ath10k: add copy engine register MAP for wcn3990 target Jeffy Chen (1): mwifiex: uninit wakeup info in the error handling Johannes Berg (13): iwlwifi: refactor out paging code iwlwifi: refactor shared mem parsing iwlwifi: track current firmware image in common code iwlwifi: refactor firmware debug code iwlwifi: reorganize firmware API iwlwifi: fw api: fix various kernel-doc warnings iwlwifi: mvm: add and use iwl_mvm_has_unified_ucode() iwlwifi: mvm: check family instead of new TX API for workarounds iwlwifi: mvm: byte-swap constant instead of variable iwlwifi: pcie: rename iwl_trans_check_hw_rf_kill() to
[PATCH v3] rt2x00: Fix MMIC Countermeasures
Set RX_FLAG_DECRYPTED in case of MMIC failure so that ieee80211_rx_h_decrypt() doesnt drop the frame before getting to ieee80211_rx_h_michael_mic_verify(). Signed-off-by: Michael Skeffington --- drivers/net/wireless/ralink/rt2x00/rt2800mmio.c | 13 +++-- drivers/net/wireless/ralink/rt2x00/rt2800usb.c | 15 --- 2 files changed, 23 insertions(+), 5 deletions(-) diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800mmio.c b/drivers/net/wireless/ralink/rt2x00/rt2800mmio.c index ee5276e233fa..1123e2bed803 100644 --- a/drivers/net/wireless/ralink/rt2x00/rt2800mmio.c +++ b/drivers/net/wireless/ralink/rt2x00/rt2800mmio.c @@ -136,10 +136,19 @@ void rt2800mmio_fill_rxdone(struct queue_entry *entry, */ rxdesc->flags |= RX_FLAG_MMIC_STRIPPED; - if (rxdesc->cipher_status == RX_CRYPTO_SUCCESS) + if (rxdesc->cipher_status == RX_CRYPTO_SUCCESS) { rxdesc->flags |= RX_FLAG_DECRYPTED; - else if (rxdesc->cipher_status == RX_CRYPTO_FAIL_MIC) + } else if (rxdesc->cipher_status == RX_CRYPTO_FAIL_MIC) { + /* +* In order to check the Michael Mic, the packet must have +* been decrypted. Mac80211 doesnt check the MMIC failure +* flag to initiate MMIC countermeasures if the decoded flag +* has not been set. +*/ + rxdesc->flags |= RX_FLAG_DECRYPTED; + rxdesc->flags |= RX_FLAG_MMIC_ERROR; + } } if (rt2x00_get_field32(word, RXD_W3_MY_BSS)) diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800usb.c b/drivers/net/wireless/ralink/rt2x00/rt2800usb.c index 685b8e0cd67d..3e5d3a40d986 100644 --- a/drivers/net/wireless/ralink/rt2x00/rt2800usb.c +++ b/drivers/net/wireless/ralink/rt2x00/rt2800usb.c @@ -697,11 +697,20 @@ static void rt2800usb_fill_rxdone(struct queue_entry *entry, * stripped it from the frame. Signal this to mac80211. */ rxdesc->flags |= RX_FLAG_MMIC_STRIPPED; - - if (rxdesc->cipher_status == RX_CRYPTO_SUCCESS) + + if (rxdesc->cipher_status == RX_CRYPTO_SUCCESS) { + rxdesc->flags |= RX_FLAG_DECRYPTED; + } else if (rxdesc->cipher_status == RX_CRYPTO_FAIL_MIC) { + /* +* In order to check the Michael Mic, the packet must have +* been decrypted. Mac80211 doesnt check the MMIC failure +* flag to initiate MMIC countermeasures if the decoded flag +* has not been set. +*/ rxdesc->flags |= RX_FLAG_DECRYPTED; - else if (rxdesc->cipher_status == RX_CRYPTO_FAIL_MIC) + rxdesc->flags |= RX_FLAG_MMIC_ERROR; + } } if (rt2x00_get_field32(word, RXD_W0_MY_BSS)) -- 2.11.0
Re: [PATCH v2] rt2x00: Fix MMIC Countermeasures.
Sorry about that, I work on other projects that use spaces and I must have missed that when double checking the patch. I sent out a new patch with the correct line length, removal of trailing '.' and indentation fix. On Mon, Aug 7, 2017 at 2:31 AM, Stanislaw Gruszka wrote: > On Thu, Aug 03, 2017 at 11:31:21AM -0400, Michael Skeffingfon wrote: >> @@ -136,10 +136,19 @@ void rt2800mmio_fill_rxdone(struct queue_entry *entry, >>*/ >> rxdesc->flags |= RX_FLAG_MMIC_STRIPPED; >> >> - if (rxdesc->cipher_status == RX_CRYPTO_SUCCESS) >> + if (rxdesc->cipher_status == RX_CRYPTO_SUCCESS) { >> rxdesc->flags |= RX_FLAG_DECRYPTED; >> - else if (rxdesc->cipher_status == RX_CRYPTO_FAIL_MIC) >> +} else if (rxdesc->cipher_status == RX_CRYPTO_FAIL_MIC) { > > Not sure why this happened, but here and on some other places below, > tab was replaced by spaces resulting in wrong indent. > > Stanislaw
Re: [PATCH 03/34] brcmfmac: Split brcmf_sdiod_regrw_helper() up.
On 07/08/17 12:25, Arend van Spriel wrote: > On 26-07-17 22:25, Ian Molton wrote: >> This large function is concealing a LOT of obscure logic about >> how the hardware functions. Time to split it up. >> >> This first patch splits the function into two pieces - read and write, >> doing away with the rw flag in the process. > > I really don't this it is all that obscure, but alas. Everything is in > the eye of the beholder. The reason for having the helper was to not > duplicate code for read and write and different access sizes. So now you > are duplicating it. In subsequent patches you throw away pieces of this > helper so duplication is not as bad in the net result. It would have > been easier if those patches were done before this one. I agree, this is a big and unwieldy patchset - I've attempted to break the thing down in such a way that all the steps leading to the end result are at least sane. I initially did it all in one hit and it was utterly illegible :-( > Fix the indent and column align to opening bracket. I guess a few of these got through. I blame git rebase :) -Ian
Re: [PATCH 07/34] brcmfmac: Remove brcmf_sdiod_request_data()
On 07/08/17 12:25, Arend van Spriel wrote: >> Handling of -ENOMEDIUM is altered, but as that's pretty much broken >> anyway >> we can ignore that. > > Please explain why you think it is broken. Not got the code to hand right now, but from memory, theres a trapdoor case where the state can wind up set to something that prevents it ever being changed again. I'll dig it up when I get back from holiday (this next few days). -Ian
Re: [PATCH 12/34] brcmfmac: Replace old IO functions with simpler ones.
On 07/08/17 12:26, Arend van Spriel wrote: > On 7/26/2017 10:25 PM, Ian Molton wrote: >> Primarily this patch removes: >> >> brcmf_sdiod_f0_writeb() >> brcmf_sdiod_reg_write() >> brcmf_sdiod_reg_read() > > Having [patch 30/34] "brcmfmac: Correctly handle accesses to SDIO func0" > before this patch could make this look cleaner. This is an artifact of how I came to the realisation the code was using the obsoleted functions - it could be reordered, but it'd probably get messy... >> Since we no longer use the quirky method of deciding which function to >> address via the address being accessed, take the opportunity to rename >> some IO functions more in line with common kernel code. > > As mentioned here this is more a rename than a replace so please use > that in the subject as well. Noted. > Reviewed-by: Arend van Spriel >> Signed-off-by: Ian Molton >> --- >> .../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 166 >> +++ >> .../wireless/broadcom/brcm80211/brcmfmac/sdio.c| 182 >> ++--- >> .../wireless/broadcom/brcm80211/brcmfmac/sdio.h| 28 +++- >> 3 files changed, 132 insertions(+), 244 deletions(-) > -Ian
Re: pull-request: wireless-drivers-next 2017-08-07
From: Kalle Valo Date: Mon, 07 Aug 2017 17:55:40 +0300 > here's the first pull request to net-next for 4.14, more info in the > signed tag below. This time there's a simple conflict in iwlwifi but > you can fix it just like Stephen did: > > https://lkml.kernel.org/r/20170804120408.0d147...@canb.auug.org.au > > Please let me know if you have any problems. Pulled, thanks Kalle.
Re: [PATCH 13/34] brcmfmac: Tidy register definitions a little
On 26-07-17 22:25, Ian Molton wrote: > Trivial tidy of register definitions. Initially skipped this one, but it is indeed trivial. Reviewed-by: Arend van Spriel > Signed-off-by: Ian Molton comment below... > --- > drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h | 11 ++- > 1 file changed, 6 insertions(+), 5 deletions(-) > > diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h > b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h > index 4c81ea24d19c..fb4f24dfc99d 100644 > --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h > +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h > @@ -51,17 +51,18 @@ > > /* function 0 vendor specific CCCR registers */ > > -#define SDIO_CCCR_BRCM_CARDCAP 0xf0 > +#define SDIO_CCCR_BRCM_CARDCAP 0xf0 > #define SDIO_CCCR_BRCM_CARDCAP_CMD14_SUPPORT 0x02 > #define SDIO_CCCR_BRCM_CARDCAP_CMD14_EXT 0x04 > #define SDIO_CCCR_BRCM_CARDCAP_CMD_NODEC 0x08 > + > #define SDIO_CCCR_BRCM_CARDCTRL 0xf1 > #define SDIO_CCCR_BRCM_CARDCTRL_WLANRESET0x02 > -#define SDIO_CCCR_BRCM_SEPINT0xf2 > > -#define SDIO_SEPINT_MASK0x01 > -#define SDIO_SEPINT_OE 0x02 > -#define SDIO_SEPINT_ACT_HI 0x04 > +#define SDIO_CCCR_BRCM_SEPINT0xf2 > +#define SDIO_SEPINT_MASK 0x01 > +#define SDIO_SEPINT_OE 0x02 > +#define SDIO_SEPINT_ACT_HI 0x04 So the SEPINT definitions are not consistent with the other ones. Maybe drop the SDIO_CCCR from the other value definitions and for the SEPINT replace 'SDIO_' with 'SEPINT_'.
Re: Problem with the wifi
+ linux-wireless On 07-08-17 21:38, Paolo Bettini wrote: > Hi , i am Paolo and i installed Debian stretch on my ezbook2 . One > problem is the wifi , the card a SDIO device , seems to be 02d0:a9a6 > linux id or Broadcom AP6212 for windowsi installed deb package > firmware-brcm80211 and nvram sdio txt in /lib/firmware/brcm, reloaded > bcrmfmac module but nothing the card seems invisible or dead i don't > know if is a problem of firmware or my system cannot detect the sdio > card ...do you know something about this problematic ? As always a kernel log could help or output from dmesg command. Also can you run following commands: $ ls /sys/bus/sdio/devices $ cat /sys/bus/sdio/devices/*/modalias Regards, Arend
[PATCH v2 1/2] wireless: move prism54 out to staging
prism54 is deprecated in favor of the p54pci device driver. Although only *one soul* had reported issues with it long ago Linux most Linux distributions these days just disable the device driver given the conflicts with the PCI IDs of p54pci and the *very* unlikely situation of folks really need this driver anymore. Before trying to due away with prism54 once more stuff it into staging, which is our hospice for dying drivers. Acked-by: Kalle Valo Signed-off-by: Luis R. Rodriguez --- MAINTAINERS | 4 ++-- drivers/net/wireless/intersil/Kconfig| 20 drivers/net/wireless/intersil/Makefile | 1 - drivers/staging/Kconfig | 2 ++ drivers/staging/Makefile | 1 + .../wireless/intersil => staging}/prism54/Makefile | 0 drivers/staging/prism54/TODO | 5 + .../wireless/intersil => staging}/prism54/isl_38xx.c | 0 .../wireless/intersil => staging}/prism54/isl_38xx.h | 0 .../intersil => staging}/prism54/isl_ioctl.c | 0 .../intersil => staging}/prism54/isl_ioctl.h | 0 .../wireless/intersil => staging}/prism54/isl_oid.h | 0 .../intersil => staging}/prism54/islpci_dev.c| 0 .../intersil => staging}/prism54/islpci_dev.h| 0 .../intersil => staging}/prism54/islpci_eth.c| 0 .../intersil => staging}/prism54/islpci_eth.h| 0 .../intersil => staging}/prism54/islpci_hotplug.c| 0 .../intersil => staging}/prism54/islpci_mgt.c| 0 .../intersil => staging}/prism54/islpci_mgt.h| 0 .../wireless/intersil => staging}/prism54/oid_mgt.c | 0 .../wireless/intersil => staging}/prism54/oid_mgt.h | 0 .../intersil => staging}/prism54/prismcompat.h | 0 22 files changed, 10 insertions(+), 23 deletions(-) rename drivers/{net/wireless/intersil => staging}/prism54/Makefile (100%) create mode 100644 drivers/staging/prism54/TODO rename drivers/{net/wireless/intersil => staging}/prism54/isl_38xx.c (100%) rename drivers/{net/wireless/intersil => staging}/prism54/isl_38xx.h (100%) rename drivers/{net/wireless/intersil => staging}/prism54/isl_ioctl.c (100%) rename drivers/{net/wireless/intersil => staging}/prism54/isl_ioctl.h (100%) rename drivers/{net/wireless/intersil => staging}/prism54/isl_oid.h (100%) rename drivers/{net/wireless/intersil => staging}/prism54/islpci_dev.c (100%) rename drivers/{net/wireless/intersil => staging}/prism54/islpci_dev.h (100%) rename drivers/{net/wireless/intersil => staging}/prism54/islpci_eth.c (100%) rename drivers/{net/wireless/intersil => staging}/prism54/islpci_eth.h (100%) rename drivers/{net/wireless/intersil => staging}/prism54/islpci_hotplug.c (100%) rename drivers/{net/wireless/intersil => staging}/prism54/islpci_mgt.c (100%) rename drivers/{net/wireless/intersil => staging}/prism54/islpci_mgt.h (100%) rename drivers/{net/wireless/intersil => staging}/prism54/oid_mgt.c (100%) rename drivers/{net/wireless/intersil => staging}/prism54/oid_mgt.h (100%) rename drivers/{net/wireless/intersil => staging}/prism54/prismcompat.h (100%) diff --git a/MAINTAINERS b/MAINTAINERS index 672b5d5402f0..3deaddc8c578 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -10674,11 +10674,11 @@ F:kernel/printk/ F: include/linux/printk.h PRISM54 WIRELESS DRIVER -M: "Luis R. Rodriguez" +M: "Luis R. Rodriguez" L: linux-wireless@vger.kernel.org W: http://wireless.kernel.org/en/users/Drivers/p54 S: Obsolete -F: drivers/net/wireless/intersil/prism54/ +F: drivers/staging/prism54/ PROC SYSCTL M: "Luis R. Rodriguez" diff --git a/drivers/net/wireless/intersil/Kconfig b/drivers/net/wireless/intersil/Kconfig index 9da136049955..2b056b6daef8 100644 --- a/drivers/net/wireless/intersil/Kconfig +++ b/drivers/net/wireless/intersil/Kconfig @@ -15,24 +15,4 @@ source "drivers/net/wireless/intersil/hostap/Kconfig" source "drivers/net/wireless/intersil/orinoco/Kconfig" source "drivers/net/wireless/intersil/p54/Kconfig" -config PRISM54 - tristate 'Intersil Prism GT/Duette/Indigo PCI/Cardbus (DEPRECATED)' - depends on PCI - select WIRELESS_EXT - select WEXT_SPY - select WEXT_PRIV - select FW_LOADER - ---help--- - This enables support for FullMAC PCI/Cardbus prism54 devices. This - driver is now deprecated in favor for the SoftMAC driver, p54pci. - p54pci supports FullMAC PCI/Cardbus devices as well. - - For more information refer to the p54 wiki: - - http://wireless.kernel.org/en/users/Drivers/p54 - - Note: You need a motherboard with DMA support to use any of these cards - - When built as module you get the module prism54 - endif # WLAN_VENDOR_INTERSIL diff --git a/drivers/net/wireless/intersil/Makefile b/drivers/net/wireless/intersil/Makefile index 9a8cbfee3ea5..aedb713da746 100644 --- a/drivers/net/wi
[PATCH v2 2/2] MAINTAINERS: update email address for mcgrof for few straggling drivers
This will ensure I get emails on my work and personal email address. Signed-off-by: Luis R. Rodriguez --- MAINTAINERS | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 3deaddc8c578..997b8062397a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2212,7 +2212,7 @@ F:drivers/gpio/gpio-ath79.c F: Documentation/devicetree/bindings/gpio/gpio-ath79.txt ATHEROS ATH GENERIC UTILITIES -M: "Luis R. Rodriguez" +M: "Luis R. Rodriguez" L: linux-wireless@vger.kernel.org S: Supported F: drivers/net/wireless/ath/* @@ -2220,7 +2220,7 @@ F:drivers/net/wireless/ath/* ATHEROS ATH5K WIRELESS DRIVER M: Jiri Slaby M: Nick Kossifidis -M: "Luis R. Rodriguez" +M: "Luis R. Rodriguez" L: linux-wireless@vger.kernel.org W: http://wireless.kernel.org/en/users/Drivers/ath5k S: Maintained -- 2.11.0
[PATCH v2 0/2] prism54: move to staging
Greg, This v2 adds the TODO you requested to clarify prism54 will be removed in two kernel releases from now, and so no further cleanup is needed other than to ensure the driver compiles. This is based on linux-next tag next-20170807. Luis Luis R. Rodriguez (2): wireless: move prism54 out to staging MAINTAINERS: update email address for mcgrof for few straggling drivers Luis MAINTAINERS | 8 drivers/net/wireless/intersil/Kconfig| 20 drivers/net/wireless/intersil/Makefile | 1 - drivers/staging/Kconfig | 2 ++ drivers/staging/Makefile | 1 + .../wireless/intersil => staging}/prism54/Makefile | 0 drivers/staging/prism54/TODO | 5 + .../wireless/intersil => staging}/prism54/isl_38xx.c | 0 .../wireless/intersil => staging}/prism54/isl_38xx.h | 0 .../intersil => staging}/prism54/isl_ioctl.c | 0 .../intersil => staging}/prism54/isl_ioctl.h | 0 .../wireless/intersil => staging}/prism54/isl_oid.h | 0 .../intersil => staging}/prism54/islpci_dev.c| 0 .../intersil => staging}/prism54/islpci_dev.h| 0 .../intersil => staging}/prism54/islpci_eth.c| 0 .../intersil => staging}/prism54/islpci_eth.h| 0 .../intersil => staging}/prism54/islpci_hotplug.c| 0 .../intersil => staging}/prism54/islpci_mgt.c| 0 .../intersil => staging}/prism54/islpci_mgt.h| 0 .../wireless/intersil => staging}/prism54/oid_mgt.c | 0 .../wireless/intersil => staging}/prism54/oid_mgt.h | 0 .../intersil => staging}/prism54/prismcompat.h | 0 22 files changed, 12 insertions(+), 25 deletions(-) rename drivers/{net/wireless/intersil => staging}/prism54/Makefile (100%) create mode 100644 drivers/staging/prism54/TODO rename drivers/{net/wireless/intersil => staging}/prism54/isl_38xx.c (100%) rename drivers/{net/wireless/intersil => staging}/prism54/isl_38xx.h (100%) rename drivers/{net/wireless/intersil => staging}/prism54/isl_ioctl.c (100%) rename drivers/{net/wireless/intersil => staging}/prism54/isl_ioctl.h (100%) rename drivers/{net/wireless/intersil => staging}/prism54/isl_oid.h (100%) rename drivers/{net/wireless/intersil => staging}/prism54/islpci_dev.c (100%) rename drivers/{net/wireless/intersil => staging}/prism54/islpci_dev.h (100%) rename drivers/{net/wireless/intersil => staging}/prism54/islpci_eth.c (100%) rename drivers/{net/wireless/intersil => staging}/prism54/islpci_eth.h (100%) rename drivers/{net/wireless/intersil => staging}/prism54/islpci_hotplug.c (100%) rename drivers/{net/wireless/intersil => staging}/prism54/islpci_mgt.c (100%) rename drivers/{net/wireless/intersil => staging}/prism54/islpci_mgt.h (100%) rename drivers/{net/wireless/intersil => staging}/prism54/oid_mgt.c (100%) rename drivers/{net/wireless/intersil => staging}/prism54/oid_mgt.h (100%) rename drivers/{net/wireless/intersil => staging}/prism54/prismcompat.h (100%) -- 2.11.0
[PATCH 2/2] wireless-regdb: Add 60 GHz rule for Taiwan (TW)
The latest low power radio frequency devices technical regulations [1] released by Taiwan's regulatory body, NCC, opens up 57 GHz ~ 66 GHz to most devices, including WiGig. [1] LP0002 Low-power Radio-frequency Devices Technical Regulations 2016/8/23 http://www.ncc.gov.tw/english/show_file.aspx?table_name=news&file_sn=681 Signed-off-by: Chen-Yu Tsai --- db.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/db.txt b/db.txt index d96f00e..e48f9a6 100644 --- a/db.txt +++ b/db.txt @@ -1188,6 +1188,8 @@ country TW: DFS-FCC (5250 - 5350 @ 80), (23), DFS, AUTO-BW (5470 - 5725 @ 160), (23), DFS (5725 - 5850 @ 80), (30) + # 60g band, LP0002 section 3.13.1.1 (3)(C), EIRP=40dBm(43dBm peak) + (57000 - 66000 @ 2160), (40) country TZ: (2402 - 2482 @ 40), (20) -- 2.13.3
[PATCH 1/2] wireless-regdb: Update regulatory document references for Taiwan (TW)
Taiwan's Ministry of Transportation and Communications updated its frequency allocation rules again on 2017/02/22. The amended articles are not related to this database, but the link should be kept up to date, as the old one is no longer accessible. Taiwan's regulatory body, NCC, published its updated technical regulatory standard for low-power radio frequency devices, LP0002. The URL has not changed. The new standard opens up more bandwidth for 5g U-NII WiFi and 60g WiGig devices. Transmission power for 5.25 ~ 5.35 GHz is also increased, but this was already covered in commit 9a618d9b5fb2 ("wireless-regdb: Update 5 GHz rules for Taiwan (TW) to follow US"). This patch updates the link and comments for the rules and standards, and also adds inline comments referencing the governing section of the LP0002 standard for each band. Signed-off-by: Chen-Yu Tsai --- db.txt | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/db.txt b/db.txt index 0bc068e..d96f00e 100644 --- a/db.txt +++ b/db.txt @@ -1174,15 +1174,16 @@ country TT: DFS-FCC (5735 - 5835 @ 80), (30) # Source: -# Table of Frequency Allocations of Republic of China (Taiwan) / Nov 2014: -# http://www.motc.gov.tw/websitedowndoc?file=post/201411171137330.doc&; \ -# filedisplay=Table+of+radio+frequency+allocation.doc -# LP0002 Low-power Radio-frequency Devices Technical Regulations / 28 Jun 2011: +# Table of Frequency Allocations of Republic of China (Taiwan) / Feb 2017: +# https://www.motc.gov.tw/websitedowndoc?file=post/201702221012200.doc&; \ +# filedisplay=Table%2Bof%2Bradio%2Bfrequency%2Ballocation.doc +# LP0002 Low-power Radio-frequency Devices Technical Regulations / 23 Aug 2016: # http://www.ncc.gov.tw/english/show_file.aspx?table_name=news&file_sn=681 -# (section 3.10.1, 4.7) country TW: DFS-FCC + # 2.4g band, LP0002 section 3.10.1 (2400 - 2483.5 @ 40), (30) - # Follow US 5.15 ~ 5.25 GHz: 30 dBm for master mode, 23 dBm for clients + # 5g U-NII band, LP0002 section 4.7 + # 5.15 ~ 5.25 GHz: 30 dBm for master mode, 23 dBm for clients (5150 - 5250 @ 80), (23), AUTO-BW (5250 - 5350 @ 80), (23), DFS, AUTO-BW (5470 - 5725 @ 160), (23), DFS -- 2.13.3
Re: [v5] wlcore: add missing nvs file name info for wilink8
* Reizer, Eyal [170807 00:47]: > Hi Tony, > > > > * Reizer, Eyal [170807 00:32]: > > > The following commits: > > > c815fde wlcore: spi: Populate config firmware data > > > d776fc8 wlcore: sdio: Populate config firmware data > > > > > > Populated the nvs entry for wilink6 and wilink7 only while it is > > > still needed for wilink8 as well. > > > This broke user space backward compatibility when upgrading from older > > > kernels, as the alternate mac address would not be read from the nvs that > > is > > > present in the file system (lib/firmware/ti-connectivity/wl1271-nvs.bin) > > > causing mac address change of the wlan interface. > > > > > > This patch fix this and update the structure field with the same default > > > nvs file name that has been used before. > > > > > > In addition, some distros hold a default wl1271-nvs.bin in the file > > > system with a bogus mac address (deadbeef...) that for a wl18xx device > > > also overrides the mac address that is stored inside the device. > > > Warn users about this bogus mac address and use a random mac instead > > > > Hmm looks pretty good to me except for one more thing I just noticed. > > > > Why don't you just use the hardware mac address instead of a random > > mac address on wl18xx device when you see a bogus nvs file? > > > > I agree that this would have been better but the problem is that hardware > mac address is available for wilink8 onlyWilink6/7 don't have one stored. > The wlcore code responsible for handling mac address is common code > and there is method for detecting between them in this module. Care to clarify a bit.. Are you saying wilink8 will use the hardware mac address in case of bogus nvs file? Regards, Tony
Re: [PATCH v3] rt2x00: Fix MMIC Countermeasures
On Mon, Aug 07, 2017 at 12:47:36PM -0400, Michael Skeffingfon wrote: > Set RX_FLAG_DECRYPTED in case of MMIC failure so that > ieee80211_rx_h_decrypt() doesnt drop the frame before getting to > ieee80211_rx_h_michael_mic_verify(). > > Signed-off-by: Michael Skeffington Acked-by: Stanislaw Gruszka
Re: [PATCH v2 2/3] brcmfmac: Add support for CYW4373 SDIO/USB chipset
On 08/07/2017 8:27, Arend van Spriel wrote: On 8/3/2017 11:37 AM, Wright Feng wrote: From: Chi-Hsien Lin Add support for CYW4373 SDIO/USB chipset. CYW4373 is a 1x1 dual-band 11ac chipset with 20/40/80Mhz channel support. It's a WiFi/BT combo device. Reviewed-by: Arend van Spriel Signed-off-by: Chi-Hsien Lin --- v2: add new chip(4737) info in commit message comment below... --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 1 + drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c | 2 ++ drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 4 +++- drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c| 9 - drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h | 3 +++ include/linux/mmc/sdio_ids.h | 1 + 6 files changed, 18 insertions(+), 2 deletions(-) [...] diff --git a/include/linux/mmc/sdio_ids.h b/include/linux/mmc/sdio_ids.h index b733eb4..abacd54 100644 --- a/include/linux/mmc/sdio_ids.h +++ b/include/linux/mmc/sdio_ids.h @@ -39,6 +39,7 @@ #define SDIO_DEVICE_ID_BROADCOM_434550xa9bf #define SDIO_DEVICE_ID_BROADCOM_43540x4354 #define SDIO_DEVICE_ID_BROADCOM_43560x4356 +#define SDIO_DEVICE_ID_CYPRESS_43730x4373 So is there no specific Cypress SDIO vendor ID? There is no Cypress SDIO vid. I believe the legacy chips 4343w ...etc. shipped are still using BRCM SDIO vid. Also, 4373 project was initiated in Broadcom so the default id was set to the Broadcom id. Will it a requirement to add Cypress vid here? #define SDIO_VENDOR_ID_INTEL0x0089 #define SDIO_DEVICE_ID_INTEL_IWMC3200WIMAX0x1402 .