Re: [PATCH 4/8] staging: wilc1000: avoid line over 80 chars in wilc_parse_network_info()

2018-11-05 Thread Ajay.Kathat

On 11/5/2018 9:27 PM, Joe Perches wrote:
> On Mon, 2018-11-05 at 12:18 +, ajay.kat...@microchip.com wrote:
>> Hi Joe,
>>
>> On 11/5/2018 4:27 PM, Joe Perches wrote:
>>> On Thu, 2018-11-01 at 16:45 +, ajay.kat...@microchip.com wrote:
 From: Ajay Singh 

 Use shorter name for 'network_info' variable to avoid line over 80 chars
 issue.
>>> I suppose this is OK, though perhaps unnecessary.
>>>
>>> As well, perhaps there are defects in the original code
>>> in a couple places.
>>>
 diff --git a/drivers/staging/wilc1000/coreconfigurator.c 
 b/drivers/staging/wilc1000/coreconfigurator.c
>>> []
 -  network_info->tsf_hi = le64_to_cpu(mgt->u.beacon.timestamp);
 -  network_info->tsf_lo = (u32)network_info->tsf_hi;
>>> Perhaps there is a defect for both tsf_hi assignments
>>> as it appears as if both are missing ">> 32"
>> Actually, 'tsf_hi' is used to store the complete tsf value as its data
>> type is u64.  This value is pass to the cfg80211_inform_bss() as it is.
>> So the conversion of 'tsf_hi' to 32 bit  is not required in this case.
> Antipattern naming generally warrants a rename.
>
Thanks Joe.
Sure, I will rename tsf_hi in future patch to have clear meaning.

Regards,
Ajay


Re: [PATCH] staging: wilc1000: update wilc1000 driver maintainer ids

2018-11-05 Thread Ajay.Kathat
Hi Greg,

On 11/5/2018 7:46 PM, Greg KH wrote:
> On Tue, Oct 30, 2018 at 05:53:40AM +, ajay.kat...@microchip.com wrote:
>> From: Ajay Singh 
>>
>> We would like to update the maintainer email id's for wilc1000 driver.
>>
>> Signed-off-by: Ajay Singh 
>> Signed-off-by: Adham Abozaeid 
> It would be good to get the current maintainer's signed off by on this
> so I know that they also agree with this change.

Sure, I have submitted this patch with current maintainer's agreement.
As suggested, I will send the updated patch by including current
maintainers signed off tag.

Regards,
Ajay



[PATCH 03/11] brcmfmac: set SDIO F1 MesBusyCtrl for CYW4373

2018-11-05 Thread Chi-Hsien Lin
From: Madhan Mohan R 

Along with F2 watermark (existing) configuration, F1 MesBusyCtrl
should be enabled & configured to avoid overflow errors.

Signed-off-by: Madhan Mohan R 
Signed-off-by: Chi-Hsien Lin 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 3 +++
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index 541d54661c9e..34a838fcc319 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -51,6 +51,7 @@
 
 #define DEFAULT_F2_WATERMARK0x8
 #define CY_4373_F2_WATERMARK0x40
+#define CY_4373_F1_MESBUSYCTRL  (CY_4373_F2_WATERMARK | 
SBSDIO_MESBUSYCTRL_ENAB)
 
 #ifdef DEBUG
 
@@ -4118,6 +4119,8 @@ static void brcmf_sdio_firmware_callback(struct device 
*dev, int err,
devctl |= SBSDIO_DEVCTL_F2WM_ENAB;
brcmf_sdiod_writeb(sdiod, SBSDIO_DEVICE_CTL, devctl,
   );
+   brcmf_sdiod_writeb(sdiod, SBSDIO_FUNC1_MESBUSYCTRL,
+  CY_4373_F1_MESBUSYCTRL, );
break;
default:
brcmf_sdiod_writeb(sdiod, SBSDIO_WATERMARK,
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h
index 7faed831f07d..8aaabca1eb0e 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h
@@ -104,6 +104,9 @@
 #define SBSDIO_FUNC1_RFRAMEBCHI0x1001C
 /* MesBusyCtl (rev 11) */
 #define SBSDIO_FUNC1_MESBUSYCTRL   0x1001D
+/* Enable busy capability for MES access */
+#define SBSDIO_MESBUSYCTRL_ENAB 0x80
+
 /* Sdio Core Rev 12 */
 #define SBSDIO_FUNC1_WAKEUPCTRL0x1001E
 #define SBSDIO_FUNC1_WCTRL_ALPWAIT_MASK0x1
-- 
2.1.0



[PATCH 01/11] brcmfmac: add 4354 raw pcie device id

2018-11-05 Thread Chi-Hsien Lin
From: Winnie Chang 

Add the raw 4354 PCIe device ID.

Signed-off-by: Winnie Chang 
Signed-off-by: Chi-Hsien Lin 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c   | 1 +
 drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
index 5dea569d63ed..8887bbc0084f 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -2018,6 +2018,7 @@ static const struct dev_pm_ops brcmf_pciedrvr_pm = {
 static const struct pci_device_id brcmf_pcie_devid_table[] = {
BRCMF_PCIE_DEVICE(BRCM_PCIE_4350_DEVICE_ID),
BRCMF_PCIE_DEVICE_SUB(0x4355, BRCM_PCIE_VENDOR_ID_BROADCOM, 0x4355),
+   BRCMF_PCIE_DEVICE(BRCM_PCIE_4354_RAW_DEVICE_ID),
BRCMF_PCIE_DEVICE(BRCM_PCIE_4356_DEVICE_ID),
BRCMF_PCIE_DEVICE(BRCM_PCIE_43567_DEVICE_ID),
BRCMF_PCIE_DEVICE(BRCM_PCIE_43570_DEVICE_ID),
diff --git a/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h 
b/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
index 686f7a85a045..acb87238922f 100644
--- a/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
+++ b/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
@@ -74,6 +74,7 @@
 /* PCIE Device IDs */
 #define BRCM_PCIE_4350_DEVICE_ID   0x43a3
 #define BRCM_PCIE_4354_DEVICE_ID   0x43df
+#define BRCM_PCIE_4354_RAW_DEVICE_ID   0x4354
 #define BRCM_PCIE_4356_DEVICE_ID   0x43ec
 #define BRCM_PCIE_43567_DEVICE_ID  0x43d3
 #define BRCM_PCIE_43570_DEVICE_ID  0x43d9
-- 
2.1.0



[PATCH 00/11] chip related changes

2018-11-05 Thread Chi-Hsien Lin
This patch series includes various chip-related changes:
* 43012 support
* 4373 saverestore support
* SDIO bus settings
* 4354 raw chipid

Chi-Hsien Lin (3):
  brcmfmac: add support for CYW43012 SDIO chipset
  brcmfmac: allow GCI core enumuration
  brcmfmac: 4373 save-restore support

Double Lo (1):
  brcmfmac: disable command decode in sdio_aos for 4354

Madhan Mohan R (2):
  brcmfmac: set SDIO F1 MesBusyCtrl for CYW4373
  brcmfmac: disable command decode in sdio_aos for 4373

Naveen Gupta (1):
  brcmfmac: update 43012 F2 watermark setting to fix DMA Error during
UDP RX Traffic

Praveen Babu C (1):
  brcmfmac: saverestore support changes for 43012

Winnie Chang (1):
  brcmfmac: add 4354 raw pcie device id

Wright Feng (2):
  brcmfmac: set F2 watermark to 256 for 4373
  brcmfmac: disable command decode in sdio_aos for 43012/4339/4345

 .../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c  |   1 +
 .../wireless/broadcom/brcm80211/brcmfmac/chip.c|  36 +--
 .../wireless/broadcom/brcm80211/brcmfmac/pcie.c|   1 +
 .../wireless/broadcom/brcm80211/brcmfmac/sdio.c| 110 ++---
 .../wireless/broadcom/brcm80211/brcmfmac/sdio.h|   3 +
 .../broadcom/brcm80211/include/brcm_hw_ids.h   |   2 +
 include/linux/mmc/sdio_ids.h   |   1 +
 7 files changed, 133 insertions(+), 21 deletions(-)

-- 
2.1.0



[PATCH 11/11] brcmfmac: disable command decode in sdio_aos for 4373

2018-11-05 Thread Chi-Hsien Lin
From: Madhan Mohan R 

By disabling command decode, sdiod_aos module supports
the detection of sdio command line toggle only and
generates a wakeup request to PMU and to sdiod core.
It does not decode any sdio command and generates no
response to any command.

Signed-off-by: Madhan Mohan R 
Signed-off-by: Chi-Hsien Lin 
---
 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 337e72b7787c..e8a8037be82c 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -3370,6 +3370,7 @@ static void brcmf_sdio_sr_init(struct brcmf_sdio *bus)
}
 
if (bus->ci->chip == CY_CC_43012_CHIP_ID ||
+   bus->ci->chip == CY_CC_4373_CHIP_ID ||
bus->ci->chip == BRCM_CC_4339_CHIP_ID ||
bus->ci->chip == BRCM_CC_4345_CHIP_ID ||
bus->ci->chip == BRCM_CC_4354_CHIP_ID) {
-- 
2.1.0



[PATCH 06/11] brcmfmac: saverestore support changes for 43012

2018-11-05 Thread Chi-Hsien Lin
From: Praveen Babu C 

Add saverestore register settings for 43012.

Signed-off-by: Praveen Babu C 
Signed-off-by: Chi-Hsien Lin 
---
 .../wireless/broadcom/brcm80211/brcmfmac/chip.c|  5 +
 .../wireless/broadcom/brcm80211/brcmfmac/sdio.c| 22 +-
 2 files changed, 22 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
index 7d5005d75e01..a8d3b96b727f 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
@@ -1365,6 +1365,11 @@ bool brcmf_chip_sr_capable(struct brcmf_chip *pub)
addr = CORE_CC_REG(base, sr_control1);
reg = chip->ops->read32(chip->ctx, addr);
return reg != 0;
+   case CY_CC_43012_CHIP_ID:
+   addr = CORE_CC_REG(pmu->base, retention_ctl);
+   reg = chip->ops->read32(chip->ctx, addr);
+   return (reg & (PMU_RCTL_MACPHY_DISABLE_MASK |
+  PMU_RCTL_LOGIC_DISABLE_MASK)) == 0;
default:
addr = CORE_CC_REG(pmu->base, pmucapabilities_ext);
reg = chip->ops->read32(chip->ctx, addr);
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index 299f59f58d8c..a32eb5f868b5 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -3354,16 +3354,29 @@ static void brcmf_sdio_sr_init(struct brcmf_sdio *bus)
 {
int err = 0;
u8 val;
+   u8 wakeupctrl;
+   u8 cardcap;
+   u8 chipclkcsr;
 
brcmf_dbg(TRACE, "Enter\n");
 
+   if (bus->ci->chip == CY_CC_43012_CHIP_ID) {
+   wakeupctrl = SBSDIO_FUNC1_WCTRL_ALPWAIT_SHIFT;
+   cardcap = SDIO_CCCR_BRCM_CARDCAP_CMD_NODEC;
+   chipclkcsr = SBSDIO_HT_AVAIL_REQ;
+   } else {
+   wakeupctrl = SBSDIO_FUNC1_WCTRL_HTWAIT_SHIFT;
+   cardcap = (SDIO_CCCR_BRCM_CARDCAP_CMD14_SUPPORT |
+  SDIO_CCCR_BRCM_CARDCAP_CMD14_EXT);
+   chipclkcsr = SBSDIO_FORCE_HT;
+   }
+
val = brcmf_sdiod_readb(bus->sdiodev, SBSDIO_FUNC1_WAKEUPCTRL, );
if (err) {
brcmf_err("error reading SBSDIO_FUNC1_WAKEUPCTRL\n");
return;
}
-
-   val |= 1 << SBSDIO_FUNC1_WCTRL_HTWAIT_SHIFT;
+   val |= 1 << wakeupctrl;
brcmf_sdiod_writeb(bus->sdiodev, SBSDIO_FUNC1_WAKEUPCTRL, val, );
if (err) {
brcmf_err("error writing SBSDIO_FUNC1_WAKEUPCTRL\n");
@@ -3372,8 +3385,7 @@ static void brcmf_sdio_sr_init(struct brcmf_sdio *bus)
 
/* Add CMD14 Support */
brcmf_sdiod_func0_wb(bus->sdiodev, SDIO_CCCR_BRCM_CARDCAP,
-(SDIO_CCCR_BRCM_CARDCAP_CMD14_SUPPORT |
- SDIO_CCCR_BRCM_CARDCAP_CMD14_EXT),
+cardcap,
 );
if (err) {
brcmf_err("error writing SDIO_CCCR_BRCM_CARDCAP\n");
@@ -3381,7 +3393,7 @@ static void brcmf_sdio_sr_init(struct brcmf_sdio *bus)
}
 
brcmf_sdiod_writeb(bus->sdiodev, SBSDIO_FUNC1_CHIPCLKCSR,
-  SBSDIO_FORCE_HT, );
+  chipclkcsr, );
if (err) {
brcmf_err("error writing SBSDIO_FUNC1_CHIPCLKCSR\n");
return;
-- 
2.1.0



[PATCH 05/11] brcmfmac: allow GCI core enumuration

2018-11-05 Thread Chi-Hsien Lin
GCI core is needed for ULP operation. Allow GCI core enumuration with
below changes:
 - Allow GCI to be added to core list even when it doesn't have a wrapper.
 - Allow 8K address space size.
 - Don't overwrite the address value when an additional size descriptor
   is in place.

Signed-off-by: Chi-Hsien Lin 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
index 60fd3018534e..7d5005d75e01 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
@@ -786,7 +786,7 @@ static int brcmf_chip_dmp_get_regaddr(struct 
brcmf_chip_priv *ci, u32 *eromaddr,
  u32 *regbase, u32 *wrapbase)
 {
u8 desc;
-   u32 val;
+   u32 val, szdesc;
u8 mpnum = 0;
u8 stype, sztype, wraptype;
 
@@ -832,14 +832,15 @@ static int brcmf_chip_dmp_get_regaddr(struct 
brcmf_chip_priv *ci, u32 *eromaddr,
 
/* next size descriptor can be skipped */
if (sztype == DMP_SLAVE_SIZE_DESC) {
-   val = brcmf_chip_dmp_get_desc(ci, eromaddr, NULL);
+   szdesc = brcmf_chip_dmp_get_desc(ci, eromaddr, NULL);
/* skip upper size descriptor if present */
-   if (val & DMP_DESC_ADDRSIZE_GT32)
+   if (szdesc & DMP_DESC_ADDRSIZE_GT32)
brcmf_chip_dmp_get_desc(ci, eromaddr, NULL);
}
 
-   /* only look for 4K register regions */
-   if (sztype != DMP_SLAVE_SIZE_4K)
+   /* look for 4K or 8K register regions */
+   if (sztype != DMP_SLAVE_SIZE_4K &&
+   sztype != DMP_SLAVE_SIZE_8K)
continue;
 
stype = (val & DMP_SLAVE_TYPE) >> DMP_SLAVE_TYPE_S;
@@ -896,7 +897,8 @@ int brcmf_chip_dmp_erom_scan(struct brcmf_chip_priv *ci)
 
/* need core with ports */
if (nmw + nsw == 0 &&
-   id != BCMA_CORE_PMU)
+   id != BCMA_CORE_PMU &&
+   id != BCMA_CORE_GCI)
continue;
 
/* try to obtain register address info */
-- 
2.1.0



[PATCH 09/11] brcmfmac: disable command decode in sdio_aos for 43012/4339/4345

2018-11-05 Thread Chi-Hsien Lin
From: Wright Feng 

Transaction between AOS and SDIOD is not protected, and if cmd 52
received in AOS and in the middle of response state changed from AOS to
SDIOD, response is corrupted and it causes to SDIO Host controller to
hang.

Signed-off-by: Wright Feng 
Signed-off-by: Chi-Hsien Lin 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index e7ee144dc5dd..d507d8f15e48 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -3363,15 +3363,21 @@ static void brcmf_sdio_sr_init(struct brcmf_sdio *bus)
 
if (bus->ci->chip == CY_CC_43012_CHIP_ID) {
wakeupctrl = SBSDIO_FUNC1_WCTRL_ALPWAIT_SHIFT;
-   cardcap = SDIO_CCCR_BRCM_CARDCAP_CMD_NODEC;
chipclkcsr = SBSDIO_HT_AVAIL_REQ;
} else {
wakeupctrl = SBSDIO_FUNC1_WCTRL_HTWAIT_SHIFT;
-   cardcap = (SDIO_CCCR_BRCM_CARDCAP_CMD14_SUPPORT |
-  SDIO_CCCR_BRCM_CARDCAP_CMD14_EXT);
chipclkcsr = SBSDIO_FORCE_HT;
}
 
+   if (bus->ci->chip == CY_CC_43012_CHIP_ID ||
+   bus->ci->chip == BRCM_CC_4339_CHIP_ID ||
+   bus->ci->chip == BRCM_CC_4345_CHIP_ID) {
+   cardcap = SDIO_CCCR_BRCM_CARDCAP_CMD_NODEC;
+   } else {
+   cardcap = (SDIO_CCCR_BRCM_CARDCAP_CMD14_SUPPORT |
+  SDIO_CCCR_BRCM_CARDCAP_CMD14_EXT);
+   }
+
val = brcmf_sdiod_readb(bus->sdiodev, SBSDIO_FUNC1_WAKEUPCTRL, );
if (err) {
brcmf_err("error reading SBSDIO_FUNC1_WAKEUPCTRL\n");
-- 
2.1.0



[PATCH 04/11] brcmfmac: add support for CYW43012 SDIO chipset

2018-11-05 Thread Chi-Hsien Lin
CYW43012 is a 1x1 802.11a/b/g/n Dual-Band HT20, 256-QAM/Turbo QAM. It
is an Ultra Low Power WLAN+BT combo chip.

Signed-off-by: Chi-Hsien Lin 
---
 .../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c  |  1 +
 .../wireless/broadcom/brcm80211/brcmfmac/chip.c|  9 -
 .../wireless/broadcom/brcm80211/brcmfmac/sdio.c| 40 ++
 .../broadcom/brcm80211/include/brcm_hw_ids.h   |  1 +
 include/linux/mmc/sdio_ids.h   |  1 +
 5 files changed, 45 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
index 3e37c8cf82c6..c1d4f93f7347 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
@@ -972,6 +972,7 @@ static const struct sdio_device_id brcmf_sdmmc_ids[] = {
BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_4354),
BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_4356),
BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_CYPRESS_4373),
+   BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_CYPRESS_43012),
{ /* end: all zeroes */ }
 };
 MODULE_DEVICE_TABLE(sdio, brcmf_sdmmc_ids);
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
index 927d62b3d41b..60fd3018534e 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
@@ -165,6 +165,7 @@ struct sbconfig {
 #define SRCI_LSS_MASK  0x00f0
 #define SRCI_LSS_SHIFT 20
 #defineSRCI_SRNB_MASK  0xf0
+#defineSRCI_SRNB_MASK_EXT  0x100
 #defineSRCI_SRNB_SHIFT 4
 #defineSRCI_SRBSZ_MASK 0xf
 #defineSRCI_SRBSZ_SHIFT0
@@ -592,7 +593,13 @@ static void brcmf_chip_socram_ramsize(struct 
brcmf_core_priv *sr, u32 *ramsize,
if (lss != 0)
*ramsize += (1 << ((lss - 1) + SR_BSZ_BASE));
} else {
-   nb = (coreinfo & SRCI_SRNB_MASK) >> SRCI_SRNB_SHIFT;
+   /* length of SRAM Banks increased for corerev greater than 23 */
+   if (sr->pub.rev >= 23) {
+   nb = (coreinfo & (SRCI_SRNB_MASK | SRCI_SRNB_MASK_EXT))
+   >> SRCI_SRNB_SHIFT;
+   } else {
+   nb = (coreinfo & SRCI_SRNB_MASK) >> SRCI_SRNB_SHIFT;
+   }
for (i = 0; i < nb; i++) {
retent = brcmf_chip_socram_banksize(sr, i, );
*ramsize += banksize;
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index 34a838fcc319..299f59f58d8c 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -624,6 +624,7 @@ BRCMF_FW_DEF(43455, "brcmfmac43455-sdio");
 BRCMF_FW_DEF(4354, "brcmfmac4354-sdio");
 BRCMF_FW_DEF(4356, "brcmfmac4356-sdio");
 BRCMF_FW_DEF(4373, "brcmfmac4373-sdio");
+BRCMF_FW_DEF(43012, "brcmfmac43012-sdio");
 
 static const struct brcmf_firmware_mapping brcmf_sdio_fwnames[] = {
BRCMF_FW_ENTRY(BRCM_CC_43143_CHIP_ID, 0x, 43143),
@@ -643,7 +644,8 @@ static const struct brcmf_firmware_mapping 
brcmf_sdio_fwnames[] = {
BRCMF_FW_ENTRY(BRCM_CC_4345_CHIP_ID, 0xFFC0, 43455),
BRCMF_FW_ENTRY(BRCM_CC_4354_CHIP_ID, 0x, 4354),
BRCMF_FW_ENTRY(BRCM_CC_4356_CHIP_ID, 0x, 4356),
-   BRCMF_FW_ENTRY(CY_CC_4373_CHIP_ID, 0x, 4373)
+   BRCMF_FW_ENTRY(CY_CC_4373_CHIP_ID, 0x, 4373),
+   BRCMF_FW_ENTRY(CY_CC_43012_CHIP_ID, 0x, 43012)
 };
 
 static void pkt_align(struct sk_buff *p, int len, int align)
@@ -677,6 +679,15 @@ brcmf_sdio_kso_control(struct brcmf_sdio *bus, bool on)
/* 1st KSO write goes to AOS wake up core if device is asleep  */
brcmf_sdiod_writeb(bus->sdiodev, SBSDIO_FUNC1_SLEEPCSR, wr_val, );
 
+   /* In case of 43012 chip, the chip could go down immediately after
+* KSO bit is cleared. So the further reads of KSO register could
+* fail. Thereby just bailing out immediately after clearing KSO
+* bit, to avoid polling of KSO bit.
+*/
+   if (!on && bus->ci->chip == CY_CC_43012_CHIP_ID) {
+   return err;
+   }
+
if (on) {
/* device WAKEUP through KSO:
 * write bit 0 & read back until
@@ -2436,9 +2447,20 @@ static void brcmf_sdio_bus_stop(struct device *dev)
/* Force backplane clocks to assure F2 interrupt propagates */
saveclk = brcmf_sdiod_readb(sdiodev, SBSDIO_FUNC1_CHIPCLKCSR,
);
-   if (!err)
-   brcmf_sdiod_writeb(sdiodev, SBSDIO_FUNC1_CHIPCLKCSR,
-  

[PATCH 10/11] brcmfmac: disable command decode in sdio_aos for 4354

2018-11-05 Thread Chi-Hsien Lin
From: Double Lo 

Transaction between AOS and SDIOD is not protected, and if cmd 52
received in AOS and in the middle of response state changed from AOS to
SDIOD, response is corrupted and it causes to SDIO Host controller to
hang.

Signed-off-by: Double Lo 
Signed-off-by: Chi-Hsien Lin 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index d507d8f15e48..337e72b7787c 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -3371,7 +3371,8 @@ static void brcmf_sdio_sr_init(struct brcmf_sdio *bus)
 
if (bus->ci->chip == CY_CC_43012_CHIP_ID ||
bus->ci->chip == BRCM_CC_4339_CHIP_ID ||
-   bus->ci->chip == BRCM_CC_4345_CHIP_ID) {
+   bus->ci->chip == BRCM_CC_4345_CHIP_ID ||
+   bus->ci->chip == BRCM_CC_4354_CHIP_ID) {
cardcap = SDIO_CCCR_BRCM_CARDCAP_CMD_NODEC;
} else {
cardcap = (SDIO_CCCR_BRCM_CARDCAP_CMD14_SUPPORT |
-- 
2.1.0



[PATCH 02/11] brcmfmac: set F2 watermark to 256 for 4373

2018-11-05 Thread Chi-Hsien Lin
From: Wright Feng 

We got SDIO_CRC_ERROR with 4373 on SDR104 when doing bi-directional
throughput test. Enable watermark to 256 to guarantee the operation
stability.

Signed-off-by: Wright Feng 
Signed-off-by: Chi-Hsien Lin 
---
 .../wireless/broadcom/brcm80211/brcmfmac/sdio.c| 25 --
 1 file changed, 23 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index b2e1ab5adb64..541d54661c9e 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -49,6 +49,9 @@
 #define DCMD_RESP_TIMEOUT  msecs_to_jiffies(2500)
 #define CTL_DONE_TIMEOUT   msecs_to_jiffies(2500)
 
+#define DEFAULT_F2_WATERMARK0x8
+#define CY_4373_F2_WATERMARK0x40
+
 #ifdef DEBUG
 
 #define BRCMF_TRAP_INFO_SIZE   80
@@ -138,6 +141,8 @@ struct rte_console {
 /* 1: isolate internal sdio signals, put external pads in tri-state; requires
  * sdio bus power cycle to clear (rev 9) */
 #define SBSDIO_DEVCTL_PADS_ISO 0x08
+/* 1: enable F2 Watermark */
+#define SBSDIO_DEVCTL_F2WM_ENAB0x10
 /* Force SD->SB reset mapping (rev 11) */
 #define SBSDIO_DEVCTL_SB_RST_CTL   0x30
 /*   Determined by CoreControl bit */
@@ -4046,6 +4051,7 @@ static void brcmf_sdio_firmware_callback(struct device 
*dev, int err,
void *nvram;
u32 nvram_len;
u8 saveclk;
+   u8 devctl;
 
brcmf_dbg(TRACE, "Enter: dev=%s, err=%d\n", dev_name(dev), err);
 
@@ -4101,8 +4107,23 @@ static void brcmf_sdio_firmware_callback(struct device 
*dev, int err,
brcmf_sdiod_writel(sdiod, core->base + SD_REG(hostintmask),
   bus->hostintmask, NULL);
 
-
-   brcmf_sdiod_writeb(sdiod, SBSDIO_WATERMARK, 8, );
+   switch (sdiod->func1->device) {
+   case SDIO_DEVICE_ID_CYPRESS_4373:
+   brcmf_dbg(INFO, "set F2 watermark to 0x%x*4 bytes\n",
+ CY_4373_F2_WATERMARK);
+   brcmf_sdiod_writeb(sdiod, SBSDIO_WATERMARK,
+  CY_4373_F2_WATERMARK, );
+   devctl = brcmf_sdiod_readb(sdiod, SBSDIO_DEVICE_CTL,
+  );
+   devctl |= SBSDIO_DEVCTL_F2WM_ENAB;
+   brcmf_sdiod_writeb(sdiod, SBSDIO_DEVICE_CTL, devctl,
+  );
+   break;
+   default:
+   brcmf_sdiod_writeb(sdiod, SBSDIO_WATERMARK,
+  DEFAULT_F2_WATERMARK, );
+   break;
+   }
} else {
/* Disable F2 again */
sdio_disable_func(sdiod->func2);
-- 
2.1.0



[PATCH 08/11] brcmfmac: 4373 save-restore support

2018-11-05 Thread Chi-Hsien Lin
Use sr_eng_en bit to check 4373 sr support.

Signed-off-by: Chi-Hsien Lin 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
index a8d3b96b727f..dfc2af943bff 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
@@ -1332,7 +1332,7 @@ bool brcmf_chip_set_active(struct brcmf_chip *pub, u32 
rstvec)
 
 bool brcmf_chip_sr_capable(struct brcmf_chip *pub)
 {
-   u32 base, addr, reg, pmu_cc3_mask = ~0;
+   u32 base, addr, reg, sr_eng_en, pmu_cc3_mask = ~0;
struct brcmf_chip_priv *chip;
struct brcmf_core *pmu = brcmf_chip_get_pmu(pub);
 
@@ -1365,6 +1365,12 @@ bool brcmf_chip_sr_capable(struct brcmf_chip *pub)
addr = CORE_CC_REG(base, sr_control1);
reg = chip->ops->read32(chip->ctx, addr);
return reg != 0;
+   case CY_CC_4373_CHIP_ID:
+   /* explicitly check SR engine enable bit */
+   sr_eng_en = BIT(0);
+   addr = CORE_CC_REG(base, sr_control0);
+   reg = chip->ops->read32(chip->ctx, addr);
+   return (reg & sr_eng_en) != 0;
case CY_CC_43012_CHIP_ID:
addr = CORE_CC_REG(pmu->base, retention_ctl);
reg = chip->ops->read32(chip->ctx, addr);
-- 
2.1.0



[PATCH 07/11] brcmfmac: update 43012 F2 watermark setting to fix DMA Error during UDP RX Traffic

2018-11-05 Thread Chi-Hsien Lin
From: Naveen Gupta 

The number of words that the read FIFO has to contain except
the end of frame before sends data back to the host.
Max watermark = (512B - 2* (BurstLength))/4 =
(512 - 128)/4 = 384/4 = 0x60
so if burst length (i.e. BurstLength = 64) is increased,
watermark has to be reduced. This is the optimal setting for this chip.

Signed-off-by: Naveen Gupta 
Signed-off-by: Chi-Hsien Lin 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index a32eb5f868b5..e7ee144dc5dd 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -52,6 +52,7 @@
 #define DEFAULT_F2_WATERMARK0x8
 #define CY_4373_F2_WATERMARK0x40
 #define CY_4373_F1_MESBUSYCTRL  (CY_4373_F2_WATERMARK | 
SBSDIO_MESBUSYCTRL_ENAB)
+#define CY_43012_F2_WATERMARK0x60
 
 #ifdef DEBUG
 
@@ -4162,6 +4163,17 @@ static void brcmf_sdio_firmware_callback(struct device 
*dev, int err,
brcmf_sdiod_writeb(sdiod, SBSDIO_FUNC1_MESBUSYCTRL,
   CY_4373_F1_MESBUSYCTRL, );
break;
+   case SDIO_DEVICE_ID_CYPRESS_43012:
+   brcmf_dbg(INFO, "set F2 watermark to 0x%x*4 bytes\n",
+ CY_43012_F2_WATERMARK);
+   brcmf_sdiod_writeb(sdiod, SBSDIO_WATERMARK,
+  CY_43012_F2_WATERMARK, );
+   devctl = brcmf_sdiod_readb(sdiod, SBSDIO_DEVICE_CTL,
+  );
+   devctl |= SBSDIO_DEVCTL_F2WM_ENAB;
+   brcmf_sdiod_writeb(sdiod, SBSDIO_DEVICE_CTL, devctl,
+  );
+   break;
default:
brcmf_sdiod_writeb(sdiod, SBSDIO_WATERMARK,
   DEFAULT_F2_WATERMARK, );
-- 
2.1.0



Re: RTL8188EUS support

2018-11-05 Thread Larry Finger

On 11/5/18 5:37 AM, Menion wrote:

Hi all
I have a question about the support of RTL8188EUS chipset (which I
have in a TpLink 0bda:8179 usb dongle)
This dongle works with the wext staging driver r8188eu driver. Is it
meant to be supported in the rtl2xxx driver?


Assuming that you mean rtl8xxxu, the answer is no. I have no idea what rtl2xxx 
is.

If you want a cfg80211/nl80211 driver rather than the wext-based one, I am 
currently cleaning up a new driver from Realtek with the possibility of 
replacing the one now in staging with a new version. It can be obtained with the 
following command:


git clone https://github.com/lwfinger/rtl8188eu.git -b v5.2.2.4

This driver will definitely handle your device and has pretty good performance. 
Using a local speedtest.net-type web server, I get up to 50 Mbps down and 45 
Mbps up.


The driver is undergoing fairly rapid change, but mostly to remove lots of dead 
code, thus you will not need to pull that often. It will build on any kernel 
from 4.20 back to at least 2.6.13. I am only testing on 4.20-rc1.


Larry



Re: [PATCH] rtlwifi: rtl8192de: Fix misleading REG_MCUFWDL information

2018-11-05 Thread Pkshih
On Mon, 2018-11-05 at 19:25 +0800, Shaokun Zhang wrote:
> RT_TRACE shows REG_MCUFWDL value as a decimal value with a '0x'
> prefix, which is somewhat misleading.
> 
> Fix it to print hexadecimal, as was intended.
> 
> Cc: Ping-Ke Shih 
> Cc: Kalle Valo 
> Signed-off-by: Shaokun Zhang 
> ---
>  drivers/net/wireless/realtek/rtlwifi/rtl8192de/fw.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192de/fw.c
> b/drivers/net/wireless/realtek/rtlwifi/rtl8192de/fw.c
> index 85cedd0..75bfa9d 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/rtl8192de/fw.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192de/fw.c
> @@ -173,7 +173,7 @@ static int _rtl92d_fw_init(struct ieee80211_hw *hw)
>    rtl_read_byte(rtlpriv, FW_MAC1_READY));
>   }
>   RT_TRACE(rtlpriv, COMP_FW, DBG_DMESG,
> -  "Polling FW ready fail!! REG_MCUFWDL:0x%08ul\n",
> +  "Polling FW ready fail!! REG_MCUFWDL:0x%08x\n",
>    rtl_read_dword(rtlpriv, REG_MCUFWDL));
>   return -1;
>  }

Acked-by: Ping-Ke Shih 

Thanks for your fix.



[PATCH v3 1/4] staging: wilc1000: remove unused flags in handle_cfg_param()

2018-11-05 Thread Adham.Abozaeid
From: Adham Abozaeid 

handle_cfg_param() receives a bit map that describes what to be changed.
Some of these bits flags aren't referred to from elsewhere and can be
removed.

Signed-off-by: Adham Abozaeid 
---
 drivers/staging/wilc1000/host_interface.c | 216 --
 drivers/staging/wilc1000/host_interface.h |  29 ---
 drivers/staging/wilc1000/wilc_wlan_if.h   |   9 -
 3 files changed, 254 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index c4f858b22914..b89116c57064 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -374,64 +374,6 @@ static void handle_cfg_param(struct work_struct *work)
 
mutex_lock(_drv->cfg_values_lock);
 
-   if (param->flag & BSS_TYPE) {
-   u8 bss_type = param->bss_type;
-
-   if (bss_type < 6) {
-   wid_list[i].id = WID_BSS_TYPE;
-   wid_list[i].val = (s8 *)>bss_type;
-   wid_list[i].type = WID_CHAR;
-   wid_list[i].size = sizeof(char);
-   hif_drv->cfg_values.bss_type = bss_type;
-   } else {
-   netdev_err(vif->ndev, "check value 6 over\n");
-   goto unlock;
-   }
-   i++;
-   }
-   if (param->flag & AUTH_TYPE) {
-   u8 auth_type = param->auth_type;
-
-   if (auth_type == 1 || auth_type == 2 || auth_type == 5) {
-   wid_list[i].id = WID_AUTH_TYPE;
-   wid_list[i].val = (s8 *)>auth_type;
-   wid_list[i].type = WID_CHAR;
-   wid_list[i].size = sizeof(char);
-   hif_drv->cfg_values.auth_type = auth_type;
-   } else {
-   netdev_err(vif->ndev, "Impossible value\n");
-   goto unlock;
-   }
-   i++;
-   }
-   if (param->flag & AUTHEN_TIMEOUT) {
-   if (param->auth_timeout > 0) {
-   wid_list[i].id = WID_AUTH_TIMEOUT;
-   wid_list[i].val = (s8 *)>auth_timeout;
-   wid_list[i].type = WID_SHORT;
-   wid_list[i].size = sizeof(u16);
-   hif_drv->cfg_values.auth_timeout = param->auth_timeout;
-   } else {
-   netdev_err(vif->ndev, "Range(1 ~ 65535) over\n");
-   goto unlock;
-   }
-   i++;
-   }
-   if (param->flag & POWER_MANAGEMENT) {
-   u8 pm_mode = param->power_mgmt_mode;
-
-   if (pm_mode < 5) {
-   wid_list[i].id = WID_POWER_MANAGEMENT;
-   wid_list[i].val = (s8 *)>power_mgmt_mode;
-   wid_list[i].type = WID_CHAR;
-   wid_list[i].size = sizeof(char);
-   hif_drv->cfg_values.power_mgmt_mode = pm_mode;
-   } else {
-   netdev_err(vif->ndev, "Invalid power mode\n");
-   goto unlock;
-   }
-   i++;
-   }
if (param->flag & RETRY_SHORT) {
u16 retry_limit = param->short_retry_limit;
 
@@ -492,160 +434,6 @@ static void handle_cfg_param(struct work_struct *work)
}
i++;
}
-   if (param->flag & PREAMBLE) {
-   u16 preamble_type = param->preamble_type;
-
-   if (param->preamble_type < 3) {
-   wid_list[i].id = WID_PREAMBLE;
-   wid_list[i].val = (s8 *)>preamble_type;
-   wid_list[i].type = WID_CHAR;
-   wid_list[i].size = sizeof(char);
-   hif_drv->cfg_values.preamble_type = preamble_type;
-   } else {
-   netdev_err(vif->ndev, "Preamble Range(0~2) over\n");
-   goto unlock;
-   }
-   i++;
-   }
-   if (param->flag & SHORT_SLOT_ALLOWED) {
-   u8 slot_allowed = param->short_slot_allowed;
-
-   if (slot_allowed < 2) {
-   wid_list[i].id = WID_SHORT_SLOT_ALLOWED;
-   wid_list[i].val = (s8 *)>short_slot_allowed;
-   wid_list[i].type = WID_CHAR;
-   wid_list[i].size = sizeof(char);
-   hif_drv->cfg_values.short_slot_allowed = slot_allowed;
-   } else {
-   netdev_err(vif->ndev, "Short slot(2) over\n");
-   goto unlock;
-   }
-   i++;
-   }
-   if (param->flag & TXOP_PROT_DISABLE) {
-   u8 prot_disabled = param->txop_prot_disabled;
-
-   if (param->txop_prot_disabled < 2) {
-   wid_list[i].id = WID_11N_TXOP_PROT_DISABLE;
-  

[PATCH v3 4/4] staging: wilc1000: Remove unused mutex cfg_values_lock

2018-11-05 Thread Adham.Abozaeid
From: Adham Abozaeid 

After removing cfg_values member, cfg_values_lock that was used to protect
it can also be removed.

Signed-off-by: Adham Abozaeid 
---
 drivers/staging/wilc1000/host_interface.c | 9 -
 drivers/staging/wilc1000/host_interface.h | 2 --
 2 files changed, 11 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index 8d1142776310..2bf91df1ded1 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -369,11 +369,8 @@ static void handle_cfg_param(struct work_struct *work)
struct cfg_param_attr *param = >body.cfg_info;
int ret;
struct wid wid_list[32];
-   struct host_if_drv *hif_drv = vif->hif_drv;
int i = 0;
 
-   mutex_lock(_drv->cfg_values_lock);
-
if (param->flag & RETRY_SHORT) {
wid_list[i].id = WID_SHORT_RETRY_LIMIT;
wid_list[i].val = (s8 *)>short_retry_limit;
@@ -409,7 +406,6 @@ static void handle_cfg_param(struct work_struct *work)
if (ret)
netdev_err(vif->ndev, "Error in setting CFG params\n");
 
-   mutex_unlock(_drv->cfg_values_lock);
kfree(msg);
 }
 
@@ -3240,15 +3236,10 @@ int wilc_init(struct net_device *dev, struct 
host_if_drv **hif_drv_handler)
timer_setup(_drv->connect_timer, timer_connect_cb, 0);
timer_setup(_drv->remain_on_ch_timer, listen_timer_cb, 0);
 
-   mutex_init(_drv->cfg_values_lock);
-   mutex_lock(_drv->cfg_values_lock);
-
hif_drv->hif_state = HOST_IF_IDLE;
 
hif_drv->p2p_timeout = 0;
 
-   mutex_unlock(_drv->cfg_values_lock);
-
wilc->clients_count++;
 
return 0;
diff --git a/drivers/staging/wilc1000/host_interface.h 
b/drivers/staging/wilc1000/host_interface.h
index 1e2e50e91f76..523b46bfb488 100644
--- a/drivers/staging/wilc1000/host_interface.h
+++ b/drivers/staging/wilc1000/host_interface.h
@@ -293,8 +293,6 @@ struct host_if_drv {
enum host_if_state hif_state;
 
u8 assoc_bssid[ETH_ALEN];
-   /*lock to protect concurrent setting of cfg params*/
-   struct mutex cfg_values_lock;
 
struct timer_list scan_timer;
struct wilc_vif *scan_timer_vif;
-- 
2.17.1



[PATCH v3 3/4] staging: wilc1000: Don't keep a copy of wiphy parameters in the driver

2018-11-05 Thread Adham.Abozaeid
From: Adham Abozaeid 

host_if_drv.cfg_values is a write only member, and can be removed

Signed-off-by: Adham Abozaeid 
---
 drivers/staging/wilc1000/host_interface.c | 13 -
 drivers/staging/wilc1000/host_interface.h |  1 -
 2 files changed, 14 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index c1215c194907..8d1142776310 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -375,43 +375,31 @@ static void handle_cfg_param(struct work_struct *work)
mutex_lock(_drv->cfg_values_lock);
 
if (param->flag & RETRY_SHORT) {
-   u16 retry_limit = param->short_retry_limit;
-
wid_list[i].id = WID_SHORT_RETRY_LIMIT;
wid_list[i].val = (s8 *)>short_retry_limit;
wid_list[i].type = WID_SHORT;
wid_list[i].size = sizeof(u16);
-   hif_drv->cfg_values.short_retry_limit = retry_limit;
i++;
}
if (param->flag & RETRY_LONG) {
-   u16 limit = param->long_retry_limit;
-
wid_list[i].id = WID_LONG_RETRY_LIMIT;
wid_list[i].val = (s8 *)>long_retry_limit;
wid_list[i].type = WID_SHORT;
wid_list[i].size = sizeof(u16);
-   hif_drv->cfg_values.long_retry_limit = limit;
i++;
}
if (param->flag & FRAG_THRESHOLD) {
-   u16 frag_th = param->frag_threshold;
-
wid_list[i].id = WID_FRAG_THRESHOLD;
wid_list[i].val = (s8 *)>frag_threshold;
wid_list[i].type = WID_SHORT;
wid_list[i].size = sizeof(u16);
-   hif_drv->cfg_values.frag_threshold = frag_th;
i++;
}
if (param->flag & RTS_THRESHOLD) {
-   u16 rts_th = param->rts_threshold;
-
wid_list[i].id = WID_RTS_THRESHOLD;
wid_list[i].val = (s8 *)>rts_threshold;
wid_list[i].type = WID_SHORT;
wid_list[i].size = sizeof(u16);
-   hif_drv->cfg_values.rts_threshold = rts_th;
i++;
}
 
@@ -3256,7 +3244,6 @@ int wilc_init(struct net_device *dev, struct host_if_drv 
**hif_drv_handler)
mutex_lock(_drv->cfg_values_lock);
 
hif_drv->hif_state = HOST_IF_IDLE;
-   hif_drv->cfg_values.scan_source = DEFAULT_SCAN;
 
hif_drv->p2p_timeout = 0;
 
diff --git a/drivers/staging/wilc1000/host_interface.h 
b/drivers/staging/wilc1000/host_interface.h
index df9fc33be094..1e2e50e91f76 100644
--- a/drivers/staging/wilc1000/host_interface.h
+++ b/drivers/staging/wilc1000/host_interface.h
@@ -293,7 +293,6 @@ struct host_if_drv {
enum host_if_state hif_state;
 
u8 assoc_bssid[ETH_ALEN];
-   struct cfg_param_attr cfg_values;
/*lock to protect concurrent setting of cfg params*/
struct mutex cfg_values_lock;
 
-- 
2.17.1



[PATCH v3 2/4] staging: wilc1000: validate cfg parameters before scheduling the work

2018-11-05 Thread Adham.Abozaeid
From: Adham Abozaeid 

Validate cfg parameters after being called by cfg80211 in set_wiphy_params
before scheduling the work executed in handle_cfg_param

Signed-off-by: Adham Abozaeid 
---
 drivers/staging/wilc1000/host_interface.c | 61 ++-
 .../staging/wilc1000/wilc_wfi_cfgoperations.c | 50 ---
 2 files changed, 62 insertions(+), 49 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index b89116c57064..c1215c194907 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -377,61 +377,41 @@ static void handle_cfg_param(struct work_struct *work)
if (param->flag & RETRY_SHORT) {
u16 retry_limit = param->short_retry_limit;
 
-   if (retry_limit > 0 && retry_limit < 256) {
-   wid_list[i].id = WID_SHORT_RETRY_LIMIT;
-   wid_list[i].val = (s8 *)>short_retry_limit;
-   wid_list[i].type = WID_SHORT;
-   wid_list[i].size = sizeof(u16);
-   hif_drv->cfg_values.short_retry_limit = retry_limit;
-   } else {
-   netdev_err(vif->ndev, "Range(1~256) over\n");
-   goto unlock;
-   }
+   wid_list[i].id = WID_SHORT_RETRY_LIMIT;
+   wid_list[i].val = (s8 *)>short_retry_limit;
+   wid_list[i].type = WID_SHORT;
+   wid_list[i].size = sizeof(u16);
+   hif_drv->cfg_values.short_retry_limit = retry_limit;
i++;
}
if (param->flag & RETRY_LONG) {
u16 limit = param->long_retry_limit;
 
-   if (limit > 0 && limit < 256) {
-   wid_list[i].id = WID_LONG_RETRY_LIMIT;
-   wid_list[i].val = (s8 *)>long_retry_limit;
-   wid_list[i].type = WID_SHORT;
-   wid_list[i].size = sizeof(u16);
-   hif_drv->cfg_values.long_retry_limit = limit;
-   } else {
-   netdev_err(vif->ndev, "Range(1~256) over\n");
-   goto unlock;
-   }
+   wid_list[i].id = WID_LONG_RETRY_LIMIT;
+   wid_list[i].val = (s8 *)>long_retry_limit;
+   wid_list[i].type = WID_SHORT;
+   wid_list[i].size = sizeof(u16);
+   hif_drv->cfg_values.long_retry_limit = limit;
i++;
}
if (param->flag & FRAG_THRESHOLD) {
u16 frag_th = param->frag_threshold;
 
-   if (frag_th > 255 && frag_th < 7937) {
-   wid_list[i].id = WID_FRAG_THRESHOLD;
-   wid_list[i].val = (s8 *)>frag_threshold;
-   wid_list[i].type = WID_SHORT;
-   wid_list[i].size = sizeof(u16);
-   hif_drv->cfg_values.frag_threshold = frag_th;
-   } else {
-   netdev_err(vif->ndev, "Threshold Range fail\n");
-   goto unlock;
-   }
+   wid_list[i].id = WID_FRAG_THRESHOLD;
+   wid_list[i].val = (s8 *)>frag_threshold;
+   wid_list[i].type = WID_SHORT;
+   wid_list[i].size = sizeof(u16);
+   hif_drv->cfg_values.frag_threshold = frag_th;
i++;
}
if (param->flag & RTS_THRESHOLD) {
u16 rts_th = param->rts_threshold;
 
-   if (rts_th > 255) {
-   wid_list[i].id = WID_RTS_THRESHOLD;
-   wid_list[i].val = (s8 *)>rts_threshold;
-   wid_list[i].type = WID_SHORT;
-   wid_list[i].size = sizeof(u16);
-   hif_drv->cfg_values.rts_threshold = rts_th;
-   } else {
-   netdev_err(vif->ndev, "Threshold Range fail\n");
-   goto unlock;
-   }
+   wid_list[i].id = WID_RTS_THRESHOLD;
+   wid_list[i].val = (s8 *)>rts_threshold;
+   wid_list[i].type = WID_SHORT;
+   wid_list[i].size = sizeof(u16);
+   hif_drv->cfg_values.rts_threshold = rts_th;
i++;
}
 
@@ -441,7 +421,6 @@ static void handle_cfg_param(struct work_struct *work)
if (ret)
netdev_err(vif->ndev, "Error in setting CFG params\n");
 
-unlock:
mutex_unlock(_drv->cfg_values_lock);
kfree(msg);
 }
diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c 
b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index 4fd5a64b..26bb78a49d81 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -1149,21 +1149,55 @@ static int set_wiphy_params(struct wiphy *wiphy, u32 
changed)
cfg_param_val.flag = 0;
 
if (changed & 

[PATCH v3 0/4] staging: wilc1000: validate input to set_wiphy_param and return proper errors

2018-11-05 Thread Adham.Abozaeid
From: Adham Abozaeid 

Validate input parameters to set_wiphy_param before scheduling
handle_cfg_param() to validate them.
This way proper errors can be returned to caller.
Also cleaned up unused code in handle_cfg_param.

Changes since v1:
- Correction spelling in subject of patch#2
- Added From: tag to have correct email from value

Changes since v2:
- Reverted unnecessary file permission changes

Adham Abozaeid (4):
  staging: wilc1000: remove unused flags in handle_cfg_param()
  staging: wilc1000: validate cfg parameters before scheduling the work
  staging: wilc1000: Don't keep a copy of wiphy parameters in the driver
  staging: wilc1000: Remove unused mutex cfg_values_lock

 drivers/staging/wilc1000/host_interface.c | 291 +-
 drivers/staging/wilc1000/host_interface.h |  32 --
 .../staging/wilc1000/wilc_wfi_cfgoperations.c |  50 ++-
 drivers/staging/wilc1000/wilc_wlan_if.h   |   9 -
 4 files changed, 58 insertions(+), 324 deletions(-)

-- 
2.17.1



Re: [RFC 0/3] cfg80211/nl80211/iw: add basic AMPDU/AMSDU controls

2018-11-05 Thread Ben Greear

On 11/05/2018 02:49 PM, Igor Mitsyanko wrote:

On 11/05/2018 12:45 PM, Ben Greear wrote:


I see you don't implement it this way in the driver, but wouldn't it
make more sense to have this as a per-STA (RA) setting? That's really
the granularity it can be done on, I think?

Arguably even per-RA/TID, though that seems a little excessive?


I like the idea of providing this API per peer/tid.  And, just allow
peer == -1, tid == -1 or similar to mean 'all' so that you can still set
the entire device
to one particular setting w/out having to iterate through all peers if you
don't want to iterate...


Maye I'm wrong, but isn't the setting we're discussing are for the
device itself, not for its peers? I mean, disabling AMSDU, AMPDU implies
we need to update capabilities advertised in our information elements,
which are common for all devices, and it affects both Tx and Rx.

And per-node/per-TID aggregation settings are a separate configuration
option related to rate adaptation on Tx path only..


You can advertise your maximum capabilities, but just because you advertise
that you can do large AMPDU chains doesn't mean you are required to send
them.

So, to advertise stuff, it is per vdev (not per radio), but once you associate
a peer, you might decide to configure it so that you always send no more than 5
frames in an AMPDU chain, for instance.

And, you might decide that BE gets up to 32 AMPDU chain, but VI should be 
limitted to 16
to decrease latency just a bit.

Thanks,
Ben


--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com



Re: [RFC 0/3] cfg80211/nl80211/iw: add basic AMPDU/AMSDU controls

2018-11-05 Thread Igor Mitsyanko
On 11/05/2018 12:45 PM, Ben Greear wrote:
>>
>> I see you don't implement it this way in the driver, but wouldn't it
>> make more sense to have this as a per-STA (RA) setting? That's really
>> the granularity it can be done on, I think?
>>
>> Arguably even per-RA/TID, though that seems a little excessive?
> 
> I like the idea of providing this API per peer/tid.  And, just allow
> peer == -1, tid == -1 or similar to mean 'all' so that you can still set 
> the entire device
> to one particular setting w/out having to iterate through all peers if you
> don't want to iterate...

Maybe I'm wrong, but isn't the setting we're discussing are for the 
device itself, not for its peers? I mean, disabling AMSDU, AMPDU implies 
we need to update capabilities advertised in our information elements, 
which are common for all devices, and it affects both Tx and Rx.

And per-node/per-TID aggregation settings are a separate configuration 
option related to rate adaptation on Tx path only..


Re: [RFC 0/3] cfg80211/nl80211/iw: add basic AMPDU/AMSDU controls

2018-11-05 Thread Igor Mitsyanko
On 11/05/2018 12:45 PM, Ben Greear wrote:
>>
>> I see you don't implement it this way in the driver, but wouldn't it
>> make more sense to have this as a per-STA (RA) setting? That's really
>> the granularity it can be done on, I think?
>>
>> Arguably even per-RA/TID, though that seems a little excessive?
> 
> I like the idea of providing this API per peer/tid.  And, just allow
> peer == -1, tid == -1 or similar to mean 'all' so that you can still set 
> the entire device
> to one particular setting w/out having to iterate through all peers if you
> don't want to iterate...

Maye I'm wrong, but isn't the setting we're discussing are for the 
device itself, not for its peers? I mean, disabling AMSDU, AMPDU implies 
we need to update capabilities advertised in our information elements, 
which are common for all devices, and it affects both Tx and Rx.

And per-node/per-TID aggregation settings are a separate configuration 
option related to rate adaptation on Tx path only..


Re: [RFC 0/3] cfg80211/nl80211/iw: add basic AMPDU/AMSDU controls

2018-11-05 Thread Ben Greear

On 11/05/2018 12:32 PM, Johannes Berg wrote:

Hi,


Here are several RFC patches providing simple high-level controls of AMSDU/AMPDU
aggregation. The primary purpose of this functionality is an attempt to fill
missing gaps in nl80211 interface for basic WFA certification tests.


I see you don't implement it this way in the driver, but wouldn't it
make more sense to have this as a per-STA (RA) setting? That's really
the granularity it can be done on, I think?

Arguably even per-RA/TID, though that seems a little excessive?


I like the idea of providing this API per peer/tid.  And, just allow
peer == -1, tid == -1 or similar to mean 'all' so that you can still set the 
entire device
to one particular setting w/out having to iterate through all peers if you
don't want to iterate...


We experimented with QCA sigma-dut tool: https://github.com/qca/sigma-dut.
The purpose was to cover basic HT/VHT WFA STA tests for cfg80211 driver
controlled by wpa_supplicant  w/o adding any vendor specific commands.
Multiple WFA test parameters (e.g. STBC, NSS, SGI, LDPC) can be configured
by overriding HT/VHT capabilities in wpa_supplicant and applying them on
connect in cfg80211_connect callback. Others (e.g. RTS params) can be
configured using iw tool or NL80211_CMD_SET_WIPHY directly. These patches
implement simpe high-level switches for AMSDU/AMPDU aggregation.

It would be interesting to collect comments/concerns regarding this approach.
Does it make sense to enhance nl80211 in order to cover all the missing pieces
required for WFA certification tests ? Or maybe it makes sense to use
NL80211_TESTMODE subcommands for this kind of testing.


Honestly, I don't really know.

I think other tests, e.g. noack, we used to just have debugfs files for,
and then we got NL80211_CMD_SET_NOACK_MAP (which *is* per TID, btw)

Perhaps if we really don't see any value beyond the testing, keeping it
in debugfs would make sense, until we have more use cases and understand
the granularity we should support?

Clearly this is enough for the testing you refer to, but other use cases
might actually need more fine-grained control (in the future), possibly
down to the RA/TID level?


At least with ath10k, it seems to be a common struggle for AP manufacturers
to do regulatory testing.  I would image that is true for other chipsets
as well, so it seems like it might be worth adding to the official API.

Thanks,
Ben

--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com



Re: [RFC 0/3] cfg80211/nl80211/iw: add basic AMPDU/AMSDU controls

2018-11-05 Thread Johannes Berg
Hi,

> Here are several RFC patches providing simple high-level controls of 
> AMSDU/AMPDU
> aggregation. The primary purpose of this functionality is an attempt to fill
> missing gaps in nl80211 interface for basic WFA certification tests.

I see you don't implement it this way in the driver, but wouldn't it
make more sense to have this as a per-STA (RA) setting? That's really
the granularity it can be done on, I think?

Arguably even per-RA/TID, though that seems a little excessive?

> We experimented with QCA sigma-dut tool: https://github.com/qca/sigma-dut.
> The purpose was to cover basic HT/VHT WFA STA tests for cfg80211 driver
> controlled by wpa_supplicant  w/o adding any vendor specific commands.
> Multiple WFA test parameters (e.g. STBC, NSS, SGI, LDPC) can be configured
> by overriding HT/VHT capabilities in wpa_supplicant and applying them on
> connect in cfg80211_connect callback. Others (e.g. RTS params) can be
> configured using iw tool or NL80211_CMD_SET_WIPHY directly. These patches
> implement simpe high-level switches for AMSDU/AMPDU aggregation.
> 
> It would be interesting to collect comments/concerns regarding this approach.
> Does it make sense to enhance nl80211 in order to cover all the missing pieces
> required for WFA certification tests ? Or maybe it makes sense to use
> NL80211_TESTMODE subcommands for this kind of testing.

Honestly, I don't really know.

I think other tests, e.g. noack, we used to just have debugfs files for,
and then we got NL80211_CMD_SET_NOACK_MAP (which *is* per TID, btw)

Perhaps if we really don't see any value beyond the testing, keeping it
in debugfs would make sense, until we have more use cases and understand
the granularity we should support?

Clearly this is enough for the testing you refer to, but other use cases
might actually need more fine-grained control (in the future), possibly
down to the RA/TID level?

johannes



rtl8814au

2018-11-05 Thread Peter Carlson
We are planning on spinning up a 4x4 mimo mini pcie card using the 
Realtek chip similar to rtl8814au except not usb.  I didn't see anything 
in rtlwifi_new showing support for this chip.  Is this chip going to be 
supported in rtlwifi_new?  Can we provide any help in the development?  
We are looking to combine this with gateworks newport arm64 SBCs.


Peter

PS I'd be glad to take this off list if needed



Re: [PATCH v3 1/2] mt76x02: run calibration after scanning

2018-11-05 Thread Felix Fietkau
On 2018-11-01 16:35, Stanislaw Gruszka wrote:
> If we are associated and scanning is performed, sw_scan_complete callback
> is done after we get back to operating channel, so we do not perform
> queue cal work. Fix this queue cal work from sw_scan_complete().
> 
> On mt76x0 we have to restore gain in MT_BBP(AGC, 8) register after
> scanning, as it was multiple times modified by channel switch code.
> So queue cal work without any delay to set AGC gain value.
> 
> Similar like in mt76x2 init AGC gain only when set operating channel
> and just check before queuing cal work in sw_scan_complete() if 
> initialization was already done.
> 
> Fixes: bbd10586f0df ("mt76x0: phy: do not run calibration during channel 
> switch")
> Signed-off-by: Stanislaw Gruszka 
Applied both patches, thanks.

- Felix


Re: [PATCH] mt76x0: use band parameter for LC calibration

2018-11-05 Thread Felix Fietkau
On 2018-10-25 18:18, Stanislaw Gruszka wrote:
> We use always 1 as band parameter for MCU_CAL_LC, this break 2GHz,
> we should use 0 for this band instead.
> 
> Patch fixes problems happened sometimes when try to associate with 2GHz
> AP and manifest by errors like below:
> 
> [14680.920823] wlan0: authenticate with 18:31:bf:c0:51:b0
> [14681.109506] wlan0: send auth to 18:31:bf:c0:51:b0 (try 1/3)
> [14681.310454] wlan0: send auth to 18:31:bf:c0:51:b0 (try 2/3)
> [14681.518469] wlan0: send auth to 18:31:bf:c0:51:b0 (try 3/3)
> [14681.726499] wlan0: authentication with 18:31:bf:c0:51:b0 timed out
> 
> Fixes: 9aec146d0f6b ("mt76x0: pci: introduce mt76x0_phy_calirate routine")
> Signed-off-by: Stanislaw Gruszka 
Applied, thanks.

- Felix


Re: [PATCH] mt76x0: dfs: fix IBI_R11 configuration on non-radar channels

2018-11-05 Thread Felix Fietkau
On 2018-11-05 00:18, Lorenzo Bianconi wrote:
> Fix IBI_R11 configuration on non-radar channels for mt76x0e
> driver. This patch improve system stability under heavy load.
> Moreover use IBI_R11 name and remove magic numbers for
> 0x212c register
> 
> Fixes: 0c3b3abc9251 ("mt76x0: pci: add DFS support")
> Signed-off-by: Lorenzo Bianconi 
Applied, thanks.

- Felix


Re: [PATCH 0/3] mt76x0: add tssi calibration support

2018-11-05 Thread Felix Fietkau
On 2018-10-29 22:31, Lorenzo Bianconi wrote:
> Introduce tssi calibration support in mt76x0 driver.
> Configure tx power gain according to tssi calibrated value
> if available
Applied, thanks.

- Felix


Re: [PATCH] mt76x2u: init: use common routines for wcid/key initialization

2018-11-05 Thread Felix Fietkau
On 2018-10-29 22:16, Lorenzo Bianconi wrote:
> Use mt76x02_mac_wcid_setup and mt76x02_mac_shared_key_setup for
> shared keys and wcid table initialization and remove duplicated
> code
> 
> Signed-off-by: Lorenzo Bianconi 
Applied, thanks.

- Felix


Re: [PATCH] mt76x2u: init: remove not useful configuration

2018-11-05 Thread Felix Fietkau
On 2018-10-29 15:12, Lorenzo Bianconi wrote:
> Remove MT_TSO_CTRL and MT_HEADER_TRANS_CTRL_REG initialization since
> it is already done in mt76_write_mac_initvals routine
> 
> Signed-off-by: Lorenzo Bianconi 
Applied, thanks.

- Felix


Re: [PATCH] mt76x0: init: use mt76x02_mac_shared_key_setup in mt76x0_init_hardware

2018-11-05 Thread Felix Fietkau
On 2018-10-28 23:54, Lorenzo Bianconi wrote:
> Use mt76x02_mac_shared_key_setup utility routine for shared key
> initialization and remove duplicated code
> 
> Signed-off-by: Lorenzo Bianconi 
Applied, thanks.

- Felix


Re: [PATCH 0/2] mt76x0: fix hw key table initialization

2018-11-05 Thread Felix Fietkau
On 2018-10-29 01:36, Lorenzo Bianconi wrote:
> Fix wrong mt76x0 hw key table initialization in AP mode.
> Remove duplicated code.
> 
> This patchset is based on top of 'mt76x0: init: use
> mt76x02_mac_shared_key_setup in mt76x0_init_hardware'
> https://patchwork.kernel.org/patch/10658721/
Applied, thanks.

- Felix


Re: [PATCH 0/4] mt76: mcu api clenups

2018-11-05 Thread Felix Fietkau
On 2018-10-26 14:00, Stanislaw Gruszka wrote:
> Simplify mcu api and wait for response for mcu commands the same
> as vendor driver.
> 
> This is on top of:
> [PATCH] mt76x0: use band parameter for LC calibration
> 
> Stanislaw Gruszka (4):
>   mt76: remove mcu_msg_alloc
>   mt76: remove wait argument from mt76x02_mcu_calibrate
>   mt76: remove wait argument from mt76x02_mcu_function_select
>   mt76: remove wait argument from mt76x02_mcu_set_radio_state
Applied patches 1,3,4.

Thanks,

- Felix


Re: [PATCH] mt76x0: phy: use mt76_poll_msec in mt76x0_phy_temp_sensor

2018-11-05 Thread Felix Fietkau
On 2018-10-27 21:06, Lorenzo Bianconi wrote:
> Use mt76_poll_msec utility routine for CORE_R34 register polling
> instead of mt76_poll in order to allow the hw to complete requested
> calibration since on slow devices (e.g. mt7620 based boards) calibration
> takes longer than 2ms
> 
> Fixes: 66a34c66e0cb ("mt76x0: phy: add phy/vco temperature compensation")
> Signed-off-by: Lorenzo Bianconi 
Applied, thanks.

- Felix


Re: [PATCH 4/8] staging: wilc1000: avoid line over 80 chars in wilc_parse_network_info()

2018-11-05 Thread Joe Perches
On Mon, 2018-11-05 at 12:18 +, ajay.kat...@microchip.com wrote:
> Hi Joe,
> 
> On 11/5/2018 4:27 PM, Joe Perches wrote:
> > On Thu, 2018-11-01 at 16:45 +, ajay.kat...@microchip.com wrote:
> > > From: Ajay Singh 
> > > 
> > > Use shorter name for 'network_info' variable to avoid line over 80 chars
> > > issue.
> > 
> > I suppose this is OK, though perhaps unnecessary.
> > 
> > As well, perhaps there are defects in the original code
> > in a couple places.
> > 
> > > diff --git a/drivers/staging/wilc1000/coreconfigurator.c 
> > > b/drivers/staging/wilc1000/coreconfigurator.c
> > []
> > > - network_info->tsf_hi = le64_to_cpu(mgt->u.beacon.timestamp);
> > > - network_info->tsf_lo = (u32)network_info->tsf_hi;
> > Perhaps there is a defect for both tsf_hi assignments
> > as it appears as if both are missing ">> 32"
> 
> Actually, 'tsf_hi' is used to store the complete tsf value as its data
> type is u64.  This value is pass to the cfg80211_inform_bss() as it is.
> So the conversion of 'tsf_hi' to 32 bit  is not required in this case.

Antipattern naming generally warrants a rename.




[PATCH v2] mt76: fix building without CONFIG_LEDS_CLASS

2018-11-05 Thread Lorenzo Bianconi
From: Arnd Bergmann 

When CONFIG_LEDS_CLASS is disabled, or it is a loadable module while
mt76 is built-in, we run into a link error:

drivers/net/wireless/mediatek/mt76/mac80211.o: In function 
`mt76_register_device':
mac80211.c:(.text+0xb78): relocation truncated to fit: R_AARCH64_CALL26 against 
undefined symbol `devm_of_led_classdev_register'

We don't really need a hard dependency here as the driver can presumably
work just fine without LEDs, so this follows the iwlwifi example and
adds a separate Kconfig option for the LED support, this will be available
whenever it will link, and otherwise the respective code gets left out from
the driver object.

Fixes: 17f1de56df05 ("mt76: add common code shared between multiple chipsets")
Signed-off-by: Arnd Bergmann 
Signed-off-by: Lorenzo Bianconi 
---
Changes since v1:
- rebased on top of wireless-drivers repository
---
 drivers/net/wireless/mediatek/mt76/Kconfig   | 6 ++
 drivers/net/wireless/mediatek/mt76/mac80211.c| 8 +---
 drivers/net/wireless/mediatek/mt76/mt76x2/pci_init.c | 6 --
 3 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/Kconfig 
b/drivers/net/wireless/mediatek/mt76/Kconfig
index 0ccbcd7e887d..c30d8f5bbf2a 100644
--- a/drivers/net/wireless/mediatek/mt76/Kconfig
+++ b/drivers/net/wireless/mediatek/mt76/Kconfig
@@ -1,6 +1,12 @@
 config MT76_CORE
tristate
 
+config MT76_LEDS
+   bool
+   depends on MT76_CORE
+   depends on LEDS_CLASS=y || MT76_CORE=LEDS_CLASS
+   default y
+
 config MT76_USB
tristate
depends on MT76_CORE
diff --git a/drivers/net/wireless/mediatek/mt76/mac80211.c 
b/drivers/net/wireless/mediatek/mt76/mac80211.c
index 2a699e8b79bf..7d219ff2d480 100644
--- a/drivers/net/wireless/mediatek/mt76/mac80211.c
+++ b/drivers/net/wireless/mediatek/mt76/mac80211.c
@@ -345,9 +345,11 @@ int mt76_register_device(struct mt76_dev *dev, bool vht,
mt76_check_sband(dev, NL80211_BAND_2GHZ);
mt76_check_sband(dev, NL80211_BAND_5GHZ);
 
-   ret = mt76_led_init(dev);
-   if (ret)
-   return ret;
+   if (IS_ENABLED(CONFIG_MT76_LEDS)) {
+   ret = mt76_led_init(dev);
+   if (ret)
+   return ret;
+   }
 
return ieee80211_register_hw(hw);
 }
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2/pci_init.c 
b/drivers/net/wireless/mediatek/mt76/mt76x2/pci_init.c
index 3824290b219d..fd125722d1fb 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x2/pci_init.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x2/pci_init.c
@@ -507,8 +507,10 @@ int mt76x2_register_device(struct mt76x02_dev *dev)
mt76x2_dfs_init_detector(dev);
 
/* init led callbacks */
-   dev->mt76.led_cdev.brightness_set = mt76x2_led_set_brightness;
-   dev->mt76.led_cdev.blink_set = mt76x2_led_set_blink;
+   if (IS_ENABLED(CONFIG_MT76_LEDS)) {
+   dev->mt76.led_cdev.brightness_set = mt76x2_led_set_brightness;
+   dev->mt76.led_cdev.blink_set = mt76x2_led_set_blink;
+   }
 
ret = mt76_register_device(>mt76, true, mt76x02_rates,
   ARRAY_SIZE(mt76x02_rates));
-- 
2.17.2



Re: [PATCH 1/6] brcmfmac: Remove firmware-loading code duplication

2018-11-05 Thread Hans de Goede

Hi,

On 05-11-18 16:05, Kalle Valo wrote:

Arend van Spriel  writes:


On 10/9/2018 2:47 PM, Hans de Goede wrote:

brcmf_fw_request_next_item and brcmf_fw_request_done both have identical
code to complete the fw-request depending on the item-type.

This commit adds a new brcmf_fw_complete_request helper removing this code
duplication.


Reviewed-by: Arend van Spriel 


For some reason you commented on v1 but there was v2 posted already:

https://patchwork.kernel.org/patch/10634355/

I guess I can take v2 still?


Yes the only thing different in v2 was dropping the SPDX license header
for the new drivers/net/wireless/broadcom/brcm80211/brcmfmac/dmi.c
file and replacing it with the full ISC license text as seen in other
brcmfmac files. Nothing else was changed, so the review of v1 is
valid for v2 too.

Arend had one very minor comment on the name of a variable in the fifth
patch, but that is not important so if you want to pick up v2 as is
go for it.

Note the ISC license text is now in Torvald's tree as:
LICENSES/other/ISC

So could even go with v1, but I guess you prefer to move all files of
a driver over to the SPDX headers in one go ...

Regards,

Hans


Re: [PATCH 1/6] brcmfmac: Remove firmware-loading code duplication

2018-11-05 Thread Kalle Valo
Arend van Spriel  writes:

> On 10/9/2018 2:47 PM, Hans de Goede wrote:
>> brcmf_fw_request_next_item and brcmf_fw_request_done both have identical
>> code to complete the fw-request depending on the item-type.
>>
>> This commit adds a new brcmf_fw_complete_request helper removing this code
>> duplication.
>
> Reviewed-by: Arend van Spriel 

For some reason you commented on v1 but there was v2 posted already:

https://patchwork.kernel.org/patch/10634355/

I guess I can take v2 still?

-- 
Kalle Valo


Re: [PATCH] mt76x0: use band parameter for LC calibration

2018-11-05 Thread Felix Fietkau
On 2018-11-05 15:58, Kalle Valo wrote:
> Stanislaw Gruszka  writes:
> 
>> On Thu, Oct 25, 2018 at 06:18:33PM +0200, Stanislaw Gruszka wrote:
>>> We use always 1 as band parameter for MCU_CAL_LC, this break 2GHz,
>>> we should use 0 for this band instead.
>>> 
>>> Patch fixes problems happened sometimes when try to associate with 2GHz
>>> AP and manifest by errors like below:
>>> 
>>> [14680.920823] wlan0: authenticate with 18:31:bf:c0:51:b0
>>> [14681.109506] wlan0: send auth to 18:31:bf:c0:51:b0 (try 1/3)
>>> [14681.310454] wlan0: send auth to 18:31:bf:c0:51:b0 (try 2/3)
>>> [14681.518469] wlan0: send auth to 18:31:bf:c0:51:b0 (try 3/3)
>>> [14681.726499] wlan0: authentication with 18:31:bf:c0:51:b0 timed out
>>> 
>>> Fixes: 9aec146d0f6b ("mt76x0: pci: introduce mt76x0_phy_calirate routine")
>>> Signed-off-by: Stanislaw Gruszka 
>>> ---
>>> This is for 4.20.
>>
>> Actually it is not needed for 4.20, bacause the new calibrate code is
>> not use for USB in 4.20. It start to be used since:
>>
>> commit e868a944c55b1f42303ab2941dc1aaada9a3570c
>> Author: Lorenzo Bianconi 
>> Date:   Mon Oct 15 14:18:05 2018 +0200
>>
>> mt76x0: phy: unify calibration between mt76x0u and mt76x0e
> 
> So what should happen to this patch? Will Felix take it?
Yes, I will take it.

- Felix


Re: [PATCH] mt76x0: use band parameter for LC calibration

2018-11-05 Thread Kalle Valo
Stanislaw Gruszka  writes:

> On Thu, Oct 25, 2018 at 06:18:33PM +0200, Stanislaw Gruszka wrote:
>> We use always 1 as band parameter for MCU_CAL_LC, this break 2GHz,
>> we should use 0 for this band instead.
>> 
>> Patch fixes problems happened sometimes when try to associate with 2GHz
>> AP and manifest by errors like below:
>> 
>> [14680.920823] wlan0: authenticate with 18:31:bf:c0:51:b0
>> [14681.109506] wlan0: send auth to 18:31:bf:c0:51:b0 (try 1/3)
>> [14681.310454] wlan0: send auth to 18:31:bf:c0:51:b0 (try 2/3)
>> [14681.518469] wlan0: send auth to 18:31:bf:c0:51:b0 (try 3/3)
>> [14681.726499] wlan0: authentication with 18:31:bf:c0:51:b0 timed out
>> 
>> Fixes: 9aec146d0f6b ("mt76x0: pci: introduce mt76x0_phy_calirate routine")
>> Signed-off-by: Stanislaw Gruszka 
>> ---
>> This is for 4.20.
>
> Actually it is not needed for 4.20, bacause the new calibrate code is
> not use for USB in 4.20. It start to be used since:
>
> commit e868a944c55b1f42303ab2941dc1aaada9a3570c
> Author: Lorenzo Bianconi 
> Date:   Mon Oct 15 14:18:05 2018 +0200
>
> mt76x0: phy: unify calibration between mt76x0u and mt76x0e

So what should happen to this patch? Will Felix take it?

-- 
Kalle Valo


Re: [PATCH] mt76: fix building without CONFIG_LEDS_CLASS

2018-11-05 Thread Kalle Valo
Lorenzo Bianconi  writes:

>> Lorenzo Bianconi  writes:
>> 
>> > From: Arnd Bergmann 
>> >
>> > When CONFIG_LEDS_CLASS is disabled, or it is a loadable module while
>> > mt76 is built-in, we run into a link error:
>> >
>> > drivers/net/wireless/mediatek/mt76/mac80211.o: In function 
>> > `mt76_register_device':
>> > mac80211.c:(.text+0xb78): relocation truncated to fit:
>> > R_AARCH64_CALL26 against undefined symbol
>> > `devm_of_led_classdev_register'
>> >
>> > We don't really need a hard dependency here as the driver can presumably
>> > work just fine without LEDs, so this follows the iwlwifi example and
>> > adds a separate Kconfig option for the LED support, this will be available
>> > whenever it will link, and otherwise the respective code gets left out from
>> > the driver object.
>> >
>> > Fixes: 17f1de56df05 ("mt76: add common code shared between multiple 
>> > chipsets")
>> > Signed-off-by: Arnd Bergmann 
>> > Signed-off-by: Lorenzo Bianconi 
>> 
>> Should this go to 4.20? A linker error is pretty bad, even though I
>> think this is few months old issue already.
>
>  I guess so. The patch is based on top of Felix's repository so it apply with 
> a
>  'fuzz' on net-next/wireless-drivers-next but the patch is ok. Do I need to
>  resend or it is ok?

Doesn't seem to apply to wireless-drivers (which I fast forwarded to
v4.20-rc1 today):

Failed to apply the patch: ['git', 'am', '-s', '-3'] failed: 128
fatal: sha1 information is lacking or useless 
(drivers/net/wireless/mediatek/mt76/mt76x2/pci_init.c).
error: could not build fake ancestor

So please rebase and resend.

-- 
Kalle Valo


Re: [PATCH 5/6] brcmfmac: Set board_type from DMI on x86 based machines

2018-11-05 Thread Hans de Goede

Hi,

On 05-11-18 12:41, Arend van Spriel wrote:

On 10/9/2018 2:47 PM, Hans de Goede wrote:

For x86 based machines, set the board_type used for nvram file selection
based on the DMI sys-vendor and product-name strings.

Since on some models these strings are too generic, this commit also adds
a quirk table overriding the strings for models listed in that table.

The board_type setting is used to load the board-specific nvram file with
a board-specific name so that we can ship files for each supported board
in linux-firmware.


some comments below

Reviewed-by: Arend van Spriel 

Signed-off-by: Hans de Goede 
---
 .../broadcom/brcm80211/brcmfmac/Makefile  |   2 +
 .../broadcom/brcm80211/brcmfmac/common.c  |   3 +-
 .../broadcom/brcm80211/brcmfmac/common.h  |   7 ++
 .../broadcom/brcm80211/brcmfmac/dmi.c | 104 ++
 4 files changed, 115 insertions(+), 1 deletion(-)
 create mode 100644 drivers/net/wireless/broadcom/brcm80211/brcmfmac/dmi.c

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile
index 1f5a9b948abf..22fd95a736a8 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile
@@ -54,3 +54,5 @@ brcmfmac-$(CONFIG_BRCM_TRACING) += \
 tracepoint.o
 brcmfmac-$(CONFIG_OF) += \
 of.o
+brcmfmac-$(CONFIG_DMI) += \
+    dmi.o


Assuming OF and DMI are mutual exclusive, right?


Not necessarily ACPI tables can embed of/devicetree data now, so an x86
machine could have of-data, but having both compiled in is not an issue
I would expect only one of them to actually be present (so either of-data
or an entry in the DMI platform-data table).



diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/dmi.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/dmi.c
new file mode 100644
index ..fadc0ec745b8
--- /dev/null
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/dmi.c


[...]


+static const struct dmi_system_id dmi_platform_data[] = {


maybe call this dmi_platform_quirk as in brcmf_dmi_probe() you call this a "quirk 
table".


OK, will fix for v3. I will also switch back to the SPDX license header
for v3, since the ISC license text is now in Linus' tree.

Regards,

Hans


Re: [PATCH 6/6] brcmfmac: Cleanup brcmf_fw_request_done()

2018-11-05 Thread Hans de Goede

Hi,

On 05-11-18 12:42, Arend van Spriel wrote:

On 10/9/2018 2:47 PM, Hans de Goede wrote:

The "cur" variable is now only used for a debug print and we already
print the same info from brcmf_fw_complete_request(), so the debug print
does not provide any extra info and we can remove it.


I guess this could have been collapsed in the first patch introducing 
brcmf_fw_complete_request(). All-in-all a nice cleanup. Thanks.


The idea of doing this in 2 separate patches is to make the first
patch (which is non trivial) easier to review.

Regards,

Hans




Reviewed-by: Arend van Spriel 

Signed-off-by: Hans de Goede 
---
 .../net/wireless/broadcom/brcm80211/brcmfmac/firmware.c   | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)




Re: [PATCH 3/6] brcmfmac: Add support for first trying to get a board specific nvram file

2018-11-05 Thread Hans de Goede

Hi,

Thank you for the reviews.

On 05-11-18 12:41, Arend van Spriel wrote:

On 10/9/2018 2:47 PM, Hans de Goede wrote:

The nvram files which some brcmfmac chips need are board-specific. To be
able to distribute these as part of linux-firmware, so that devices with
such a wifi chip will work OOTB, multiple (one per board) versions must
co-exist under /lib/firmware.

This commit adds support for callers of the brcmfmac/firmware.c code to
pass in a board_type parameter through the request structure.

If that parameter is set then the code will first try to load
chipmodel.board_type.txt before falling back to the old chipmodel.txt name.


minor comment below...

Reviewed-by: Arend van Spriel 

Signed-off-by: Hans de Goede 
---
 .../broadcom/brcm80211/brcmfmac/firmware.c    | 27 ++-
 .../broadcom/brcm80211/brcmfmac/firmware.h    |  1 +
 2 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
index 08aaf99fee34..6755b2388fbc 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
@@ -532,6 +532,31 @@ static int brcmf_fw_complete_request(const struct firmware 
*fw,
 return (cur->flags & BRCMF_FW_REQF_OPTIONAL) ? 0 : ret;
 }

+static int brcmf_fw_request_firmware(const struct firmware **fw,
+ struct brcmf_fw *fwctx)
+{
+    struct brcmf_fw_item *cur = >req->items[fwctx->curpos];
+    int ret;
+
+    /* nvram files are board-specific, first try a board-specific path */
+    if (cur->type == BRCMF_FW_TYPE_NVRAM && fwctx->req->board_type) {
+    char alt_path[BRCMF_FW_NAME_LEN];
+
+    strlcpy(alt_path, cur->path, BRCMF_FW_NAME_LEN);
+    /* strip .txt at the end */
+    alt_path[strlen(alt_path) - 4] = 0;
+    strlcat(alt_path, ".", BRCMF_FW_NAME_LEN);


why not string just "txt"?


I'm not entirely sure what your question exactly is here?

Regards,

Hans





+    strlcat(alt_path, fwctx->req->board_type, BRCMF_FW_NAME_LEN);
+    strlcat(alt_path, ".txt", BRCMF_FW_NAME_LEN);
+
+    ret = request_firmware(fw, alt_path, fwctx->dev);
+    if (ret == 0)
+    return ret;
+    }
+
+    return request_firmware(fw, cur->path, fwctx->dev);
+}
+
 static void brcmf_fw_request_done(const struct firmware *fw, void *ctx)
 {
 struct brcmf_fw *fwctx = ctx;
@@ -544,7 +569,7 @@ static void brcmf_fw_request_done(const struct firmware 
*fw, void *ctx)

 while (ret == 0 && ++fwctx->curpos < fwctx->req->n_items) {
 cur = >req->items[fwctx->curpos];
-    request_firmware(, cur->path, fwctx->dev);
+    brcmf_fw_request_firmware(, fwctx);
 ret = brcmf_fw_complete_request(fw, ctx);
 }

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h
index 2893e56910f0..a0834be8864e 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h
@@ -70,6 +70,7 @@ struct brcmf_fw_request {
 u16 domain_nr;
 u16 bus_nr;
 u32 n_items;
+    const char *board_type;
 struct brcmf_fw_item items[0];
 };






[RFC 2/3] iw: add phy subcommands to configure aggregation

2018-11-05 Thread Sergey Matyukevich
Add phy subcommands to enable/disable AMPDU/AMSDU aggregation.

Signed-off-by: Sergey Matyukevich 
---
 nl80211.h |  6 ++
 phy.c | 60 
 2 files changed, 66 insertions(+)

diff --git a/nl80211.h b/nl80211.h
index 1766a12..41eec4a 100644
--- a/nl80211.h
+++ b/nl80211.h
@@ -2241,6 +2241,9 @@ enum nl80211_commands {
  * association request when used with NL80211_CMD_NEW_STATION). Can be set
  * only if %NL80211_STA_FLAG_WME is set.
  *
+ * @NL80211_ATTR_WIPHY_AMPDU_ENABLED: enable/disable AMPDU aggregation.
+ * @NL80211_ATTR_WIPHY_AMSDU_ENABLED: enable/disable AMSDU aggregation.
+ *
  * @NUM_NL80211_ATTR: total number of nl80211_attrs available
  * @NL80211_ATTR_MAX: highest attribute number currently defined
  * @__NL80211_ATTR_AFTER_LAST: internal use
@@ -2682,6 +2685,9 @@ enum nl80211_attrs {
 
NL80211_ATTR_HE_CAPABILITY,
 
+   NL80211_ATTR_WIPHY_AMPDU_ENABLED,
+   NL80211_ATTR_WIPHY_AMSDU_ENABLED,
+
/* add attributes here, update the policy in nl80211.c */
 
__NL80211_ATTR_AFTER_LAST,
diff --git a/phy.c b/phy.c
index 77df7a7..be949e7 100644
--- a/phy.c
+++ b/phy.c
@@ -843,3 +843,63 @@ static int handle_get_txq(struct nl80211_state *state,
 COMMAND(get, txq, "",
NL80211_CMD_GET_WIPHY, 0, CIB_PHY, handle_get_txq,
"Get TXQ parameters.");
+
+static int handle_ampdu(struct nl80211_state *state,
+   struct nl_msg *msg,
+   int argc, char **argv,
+   enum id_input id)
+{
+   unsigned int ampdu;
+
+   if (argc != 1)
+   return 1;
+
+   if (strcmp(argv[0], "on") == 0)
+   ampdu = 1;
+   else if (strcmp(argv[0], "off") == 0)
+   ampdu = 0;
+   else {
+   printf("Invalid parameter: %s\n", argv[0]);
+   return 2;
+   }
+
+   NLA_PUT_U8(msg, NL80211_ATTR_WIPHY_AMPDU_ENABLED, ampdu);
+
+   return 0;
+
+ nla_put_failure:
+   return -ENOBUFS;
+}
+COMMAND(set, ampdu, "",
+   NL80211_CMD_SET_WIPHY, 0, CIB_PHY, handle_ampdu,
+   "Enable/disable AMPDU aggregation.");
+
+static int handle_amsdu(struct nl80211_state *state,
+   struct nl_msg *msg,
+   int argc, char **argv,
+   enum id_input id)
+{
+   unsigned int amsdu;
+
+   if (argc != 1)
+   return 1;
+
+   if (strcmp(argv[0], "on") == 0)
+   amsdu = 1;
+   else if (strcmp(argv[0], "off") == 0)
+   amsdu = 0;
+   else {
+   printf("Invalid parameter: %s\n", argv[0]);
+   return 2;
+   }
+
+   NLA_PUT_U8(msg, NL80211_ATTR_WIPHY_AMSDU_ENABLED, amsdu);
+
+   return 0;
+
+ nla_put_failure:
+   return -ENOBUFS;
+}
+COMMAND(set, amsdu, "",
+   NL80211_CMD_SET_WIPHY, 0, CIB_PHY, handle_amsdu,
+   "Enable/disable AMSDU aggregation.");
-- 
2.11.0



[RFC 3/3] qtnfmac: add support for basic aggregation control

2018-11-05 Thread Sergey Matyukevich
Add support for basic AMPDU/AMSDU aggregation control:
- report initial aggregation configuration to cfg80211 core
- pass AMPDU/AMSDU aggregation changes to wireless card
  using set_wiphy_params cfg80211 callback

Signed-off-by: Sergey Matyukevich 
---
 drivers/net/wireless/quantenna/qtnfmac/cfg80211.c |  2 ++
 drivers/net/wireless/quantenna/qtnfmac/commands.c | 17 +
 drivers/net/wireless/quantenna/qtnfmac/core.h |  2 ++
 drivers/net/wireless/quantenna/qtnfmac/qlink.h|  7 +++
 4 files changed, 28 insertions(+)

diff --git a/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c 
b/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
index 51b33ec78fac..98bd0a3d29db 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/cfg80211.c
@@ -1087,6 +1087,8 @@ int qtnf_wiphy_register(struct qtnf_hw_info *hw_info, 
struct qtnf_wmac *mac)
wiphy->retry_short = macinfo->sretry_limit;
wiphy->retry_long = macinfo->lretry_limit;
wiphy->coverage_class = macinfo->coverage_class;
+   wiphy->ampdu_enabled = macinfo->ampdu_enabled;
+   wiphy->amsdu_enabled = macinfo->amsdu_enabled;
 
wiphy->max_scan_ssids =
(hw_info->max_scan_ssids) ? hw_info->max_scan_ssids : 1;
diff --git a/drivers/net/wireless/quantenna/qtnfmac/commands.c 
b/drivers/net/wireless/quantenna/qtnfmac/commands.c
index bfdc1ad30c13..6ab0a25b917f 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/commands.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/commands.c
@@ -1531,6 +1531,7 @@ static int qtnf_cmd_resp_proc_phy_params(struct qtnf_wmac 
*mac,
struct qlink_tlv_frag_rts_thr *phy_thr;
struct qlink_tlv_rlimit *limit;
struct qlink_tlv_cclass *class;
+   struct qlink_tlv_aggr *aggr;
u16 tlv_type;
u16 tlv_value_len;
size_t tlv_full_len;
@@ -1571,6 +1572,14 @@ static int qtnf_cmd_resp_proc_phy_params(struct 
qtnf_wmac *mac,
class = (void *)tlv;
mac_info->coverage_class = class->cclass;
break;
+   case QTN_TLV_ID_AMPDU_ENABLED:
+   aggr = (void *)tlv;
+   mac_info->ampdu_enabled = aggr->aggr;
+   break;
+   case QTN_TLV_ID_AMSDU_ENABLED:
+   aggr = (void *)tlv;
+   mac_info->amsdu_enabled = aggr->aggr;
+   break;
default:
pr_err("MAC%u: Unknown TLV type: %#x\n", mac->macid,
   le16_to_cpu(tlv->type));
@@ -1814,6 +1823,14 @@ int qtnf_cmd_send_update_phy_params(struct qtnf_wmac 
*mac, u32 changed)
qtnf_cmd_skb_put_tlv_u8(cmd_skb, QTN_TLV_ID_COVERAGE_CLASS,
wiphy->coverage_class);
 
+   if (changed & WIPHY_PARAM_AMPDU_ENABLED)
+   qtnf_cmd_skb_put_tlv_u8(cmd_skb, QTN_TLV_ID_AMPDU_ENABLED,
+   wiphy->ampdu_enabled);
+
+   if (changed & WIPHY_PARAM_AMSDU_ENABLED)
+   qtnf_cmd_skb_put_tlv_u8(cmd_skb, QTN_TLV_ID_AMSDU_ENABLED,
+   wiphy->amsdu_enabled);
+
ret = qtnf_cmd_send(mac->bus, cmd_skb);
if (ret)
goto out;
diff --git a/drivers/net/wireless/quantenna/qtnfmac/core.h 
b/drivers/net/wireless/quantenna/qtnfmac/core.h
index 293055049caa..e6752faf0f50 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/core.h
+++ b/drivers/net/wireless/quantenna/qtnfmac/core.h
@@ -94,6 +94,8 @@ struct qtnf_mac_info {
u8 lretry_limit;
u8 sretry_limit;
u8 coverage_class;
+   u8 amsdu_enabled;
+   u8 ampdu_enabled;
u8 radar_detect_widths;
u32 max_acl_mac_addrs;
struct ieee80211_ht_cap ht_cap_mod_mask;
diff --git a/drivers/net/wireless/quantenna/qtnfmac/qlink.h 
b/drivers/net/wireless/quantenna/qtnfmac/qlink.h
index 8d62addea895..7dede44c75d7 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/qlink.h
+++ b/drivers/net/wireless/quantenna/qtnfmac/qlink.h
@@ -1154,6 +1154,8 @@ enum qlink_tlv_id {
QTN_TLV_ID_WOWLAN_PATTERN   = 0x0411,
QTN_TLV_ID_SCAN_FLUSH   = 0x0412,
QTN_TLV_ID_SCAN_DWELL   = 0x0413,
+   QTN_TLV_ID_AMPDU_ENABLED= 0x0414,
+   QTN_TLV_ID_AMSDU_ENABLED= 0x0415,
 };
 
 struct qlink_tlv_hdr {
@@ -1195,6 +1197,11 @@ struct qlink_tlv_cclass {
u8 cclass;
 } __packed;
 
+struct qlink_tlv_aggr {
+   struct qlink_tlv_hdr hdr;
+   u8 aggr;
+} __packed;
+
 /**
  * enum qlink_reg_rule_flags - regulatory rule flags
  *
-- 
2.11.0



[RFC 0/3] cfg80211/nl80211/iw: add basic AMPDU/AMSDU controls

2018-11-05 Thread Sergey Matyukevich
Hello Johannes and all, 

Here are several RFC patches providing simple high-level controls of AMSDU/AMPDU
aggregation. The primary purpose of this functionality is an attempt to fill
missing gaps in nl80211 interface for basic WFA certification tests.

We experimented with QCA sigma-dut tool: https://github.com/qca/sigma-dut.
The purpose was to cover basic HT/VHT WFA STA tests for cfg80211 driver
controlled by wpa_supplicant  w/o adding any vendor specific commands.
Multiple WFA test parameters (e.g. STBC, NSS, SGI, LDPC) can be configured
by overriding HT/VHT capabilities in wpa_supplicant and applying them on
connect in cfg80211_connect callback. Others (e.g. RTS params) can be
configured using iw tool or NL80211_CMD_SET_WIPHY directly. These patches
implement simpe high-level switches for AMSDU/AMPDU aggregation.

It would be interesting to collect comments/concerns regarding this approach.
Does it make sense to enhance nl80211 in order to cover all the missing pieces
required for WFA certification tests ? Or maybe it makes sense to use
NL80211_TESTMODE subcommands for this kind of testing.


The summary of changes is as follows:
- nl80211/cfg80211: new wiphy flags and minimal set_wiphy/get_wiphy changes
- iw: new phy subcommands to enable/disable aggregation
- qtnfmac: minimal driver example - get/set aggregation

Regards,
Sergey


kernel:
 drivers/net/wireless/quantenna/qtnfmac/cfg80211.c |2 +
 drivers/net/wireless/quantenna/qtnfmac/commands.c |   17 
 drivers/net/wireless/quantenna/qtnfmac/core.h |2 +
 drivers/net/wireless/quantenna/qtnfmac/qlink.h|7 
 include/net/cfg80211.h|7 
 include/uapi/linux/nl80211.h  |6 
 net/wireless/core.c   |3 ++
 net/wireless/nl80211.c|   31 ++
 9 files changed, 76 insertions(+), 1 deletion(-)

iw:
 nl80211.h |6 ++
 phy.c |   60 
 2 files changed, 66 insertions(+)


[RFC 1/3] cfg80211/nl80211: add wiphy flags to control aggregation

2018-11-05 Thread Sergey Matyukevich
Add two top-level switches to wiphy structure to control AMSDU and AMPDU
aggregation. Enable read/update of AMSDU and AMPDU aggregation from
the userspace using set_wiphy/get_wiphy commands.

Signed-off-by: Sergey Matyukevich 
---
 include/net/cfg80211.h   |  7 +++
 include/uapi/linux/nl80211.h |  6 ++
 net/wireless/core.c  |  3 +++
 net/wireless/nl80211.c   | 31 +++
 4 files changed, 47 insertions(+)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 1fa41b7a1be3..fbf01d156069 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -2368,6 +2368,8 @@ enum cfg80211_connect_params_changed {
  * @WIPHY_PARAM_TXQ_LIMIT: TXQ packet limit has been changed
  * @WIPHY_PARAM_TXQ_MEMORY_LIMIT: TXQ memory limit has been changed
  * @WIPHY_PARAM_TXQ_QUANTUM: TXQ scheduler quantum
+ * @WIPHY_PARAM_AMPDU_ENABLED: wiphy->ampdu_enabled has changed
+ * @WIPHY_PARAM_AMSDU_ENABLED: wiphy->amsdu_enabled has changed
  */
 enum wiphy_params_flags {
WIPHY_PARAM_RETRY_SHORT = 1 << 0,
@@ -2379,6 +2381,8 @@ enum wiphy_params_flags {
WIPHY_PARAM_TXQ_LIMIT   = 1 << 6,
WIPHY_PARAM_TXQ_MEMORY_LIMIT= 1 << 7,
WIPHY_PARAM_TXQ_QUANTUM = 1 << 8,
+   WIPHY_PARAM_AMPDU_ENABLED   = 1 << 9,
+   WIPHY_PARAM_AMSDU_ENABLED   = 1 << 10,
 };
 
 /**
@@ -4163,6 +4167,9 @@ struct wiphy {
u32 txq_memory_limit;
u32 txq_quantum;
 
+   u8 ampdu_enabled;
+   u8 amsdu_enabled;
+
char priv[0] __aligned(NETDEV_ALIGN);
 };
 
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 6d610bae30a9..a9f8fa814ecd 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -2254,6 +2254,9 @@ enum nl80211_commands {
  * @NL80211_ATTR_FTM_RESPONDER_STATS: Nested attribute with FTM responder
  * statistics, see  nl80211_ftm_responder_stats.
  *
+ * @NL80211_ATTR_WIPHY_AMPDU_ENABLED: enable/disable AMPDU aggregation.
+ * @NL80211_ATTR_WIPHY_AMSDU_ENABLED: enable/disable AMSDU aggregation.
+ *
  * @NUM_NL80211_ATTR: total number of nl80211_attrs available
  * @NL80211_ATTR_MAX: highest attribute number currently defined
  * @__NL80211_ATTR_AFTER_LAST: internal use
@@ -2699,6 +2702,9 @@ enum nl80211_attrs {
 
NL80211_ATTR_FTM_RESPONDER_STATS,
 
+   NL80211_ATTR_WIPHY_AMPDU_ENABLED,
+   NL80211_ATTR_WIPHY_AMSDU_ENABLED,
+
/* add attributes here, update the policy in nl80211.c */
 
__NL80211_ATTR_AFTER_LAST,
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 5bd01058b9e6..182f8f04166d 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -524,6 +524,9 @@ struct wiphy *wiphy_new_nm(const struct cfg80211_ops *ops, 
int sizeof_priv,
rdev->wiphy.max_sched_scan_plans = 1;
rdev->wiphy.max_sched_scan_plan_interval = U32_MAX;
 
+   rdev->wiphy.ampdu_enabled = 1;
+   rdev->wiphy.amsdu_enabled = 1;
+
return >wiphy;
 }
 EXPORT_SYMBOL(wiphy_new_nm);
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 744b5851bbf9..5c04b6996e64 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -497,6 +497,9 @@ static const struct nla_policy 
nl80211_policy[NUM_NL80211_ATTR] = {
.type = NLA_NESTED,
.validation_data = nl80211_ftm_responder_policy,
},
+
+   [NL80211_ATTR_WIPHY_AMPDU_ENABLED] = { .type = NLA_U8 },
+   [NL80211_ATTR_WIPHY_AMSDU_ENABLED] = { .type = NLA_U8 },
 };
 
 /* policy for the key attributes */
@@ -2118,6 +2121,14 @@ static int nl80211_send_wiphy(struct 
cfg80211_registered_device *rdev,
goto nla_put_failure;
}
 
+   if (nla_put_u8(msg, NL80211_ATTR_WIPHY_AMPDU_ENABLED,
+  rdev->wiphy.ampdu_enabled))
+   goto nla_put_failure;
+
+   if (nla_put_u8(msg, NL80211_ATTR_WIPHY_AMSDU_ENABLED,
+  rdev->wiphy.amsdu_enabled))
+   goto nla_put_failure;
+
/* done */
state->split_start = 0;
break;
@@ -2514,6 +2525,7 @@ static int nl80211_set_wiphy(struct sk_buff *skb, struct 
genl_info *info)
u32 frag_threshold = 0, rts_threshold = 0;
u8 coverage_class = 0;
u32 txq_limit = 0, txq_memory_limit = 0, txq_quantum = 0;
+   u8 amsdu = 0, ampdu = 0;
 
ASSERT_RTNL();
 
@@ -2743,11 +2755,22 @@ static int nl80211_set_wiphy(struct sk_buff *skb, 
struct genl_info *info)
changed |= WIPHY_PARAM_TXQ_QUANTUM;
}
 
+   if (info->attrs[NL80211_ATTR_WIPHY_AMPDU_ENABLED]) {
+   ampdu = 
nla_get_u8(info->attrs[NL80211_ATTR_WIPHY_AMPDU_ENABLED]);
+   changed |= WIPHY_PARAM_AMPDU_ENABLED;
+   }
+
+   if (info->attrs[NL80211_ATTR_WIPHY_AMSDU_ENABLED]) {
+   amsdu = 

Re: [PATCH v2 1/4] staging: wilc1000: remove unused flags in handle_cfg_param()

2018-11-05 Thread Greg KH
On Tue, Oct 30, 2018 at 04:22:55AM +, adham.aboza...@microchip.com wrote:
> From: Adham Abozaeid 
> 
> handle_cfg_param() receives a bit map that describes what to be changed.
> Some of these bits flags aren't referred to from elsewhere and can be
> removed.
> 
> Signed-off-by: Adham Abozaeid 
> ---
>  drivers/staging/wilc1000/host_interface.c | 216 --
>  drivers/staging/wilc1000/host_interface.h |  29 ---
>  drivers/staging/wilc1000/wilc_wlan_if.h   |   9 -
>  3 files changed, 254 deletions(-)
>  mode change 100644 => 100755 drivers/staging/wilc1000/host_interface.c
>  mode change 100644 => 100755 drivers/staging/wilc1000/host_interface.h
>  mode change 100644 => 100755 drivers/staging/wilc1000/wilc_wlan_if.h

Do not do Linux kernel testing on filesystems on windows machines :(

You just changed the permissions on these files for no reason, which
isn't ok at all :(

Dropping this series from my queue.

greg k-h


Re: [PATCH] staging: wilc1000: update wilc1000 driver maintainer ids

2018-11-05 Thread Greg KH
On Tue, Oct 30, 2018 at 05:53:40AM +, ajay.kat...@microchip.com wrote:
> From: Ajay Singh 
> 
> We would like to update the maintainer email id's for wilc1000 driver.
> 
> Signed-off-by: Ajay Singh 
> Signed-off-by: Adham Abozaeid 

It would be good to get the current maintainer's signed off by on this
so I know that they also agree with this change.

thanks,

greg k-h


Re: [PATCH 4/8] staging: wilc1000: avoid line over 80 chars in wilc_parse_network_info()

2018-11-05 Thread Ajay.Kathat
Hi Joe,

On 11/5/2018 4:27 PM, Joe Perches wrote:
> On Thu, 2018-11-01 at 16:45 +, ajay.kat...@microchip.com wrote:
>> From: Ajay Singh 
>>
>> Use shorter name for 'network_info' variable to avoid line over 80 chars
>> issue.
>
> I suppose this is OK, though perhaps unnecessary.
>
> As well, perhaps there are defects in the original code
> in a couple places.
>
>> diff --git a/drivers/staging/wilc1000/coreconfigurator.c 
>> b/drivers/staging/wilc1000/coreconfigurator.c
> []
>> -network_info->tsf_hi = le64_to_cpu(mgt->u.beacon.timestamp);
>> -network_info->tsf_lo = (u32)network_info->tsf_hi;
> Perhaps there is a defect for both tsf_hi assignments
> as it appears as if both are missing ">> 32"

Actually, 'tsf_hi' is used to store the complete tsf value as its data
type is u64.  This value is pass to the cfg80211_inform_bss() as it is.
So the conversion of 'tsf_hi' to 32 bit  is not required in this case.

>> +info->cap_info = le16_to_cpu(mgt->u.beacon.capab_info);
>> +info->beacon_period = le16_to_cpu(mgt->u.beacon.beacon_int);
>> +info->tsf_hi = le64_to_cpu(mgt->u.beacon.timestamp);
>> +info->tsf_lo = (u32)info->tsf_hi;
> Perhaps this should be 
>
>   network_info->tsf_hi = le64_to_cpu(mgt->u.beacon.timestamp) >> 
> 32;
>
> or
>
>   network_info->tsf_hi = upper_32_bits(le64_to_cpu(...));
>   network_info->tsf_lo = lower_32_bits(le64_to_cpu(...));
>
>


Re: [PATCH 0/5] rt2800mmio txdone/interrupts/flush rework

2018-11-05 Thread Tom Psyborg
On 05/11/2018, Craig Matsuura  wrote:
> Tom,
>
>
> I see my name and email in some urls but could not see what you are
> referring too?
>
>
> Craig
>
>
> Craig Matsuura • Technical Director, Embedded Software Architecture
>
> cmatsu...@vivint.com • P: 801.229.6005
>
>
>
> simply smarter • vivint.com
>
> 3401 N Ashton Blvd. Lehi, UT 84043
>
>
>
> [1497369905956_vivint-logo-orange.png]
>
> 
> From: linux-wireless-ow...@vger.kernel.org
>  on behalf of Tomislav Požega
> 
> Sent: Thursday, October 4, 2018 5:51:42 PM
> To: sgrus...@redhat.com
> Cc: linux-wireless@vger.kernel.org
> Subject: Re: [PATCH 0/5] rt2800mmio txdone/interrupts/flush rework
>
> Hi
>
> As suspected this changeset causes throughput regression.
>
> Below screenshots show iperf test from MS150N (RF5370) device connected to
> RT3070 adapter running AP mode:
>
> This is with standard openwrt build without any rt2x00 changes:
>
> [url=https://postimg.cc/BtYQLf6r][img]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fi.postimg.cc%2FBtYQLf6r%2Fshot-2018-10-04_17-23-56.jpg%5B%2Fimg%5D%5B%2Furldata=01%7C01%7Ccmatsuura%40vivint.com%7C4b957a380bc24ebda1f708d62a546496%7C54cc98ca024a470185483741e3b8d59d%7C0sdata=Fsq5PtjbTx3vuXrNyicoVMVyk59dlXin0SecZTKCcOY%3Dreserved=0]
>
> And this printscreen show iperf test with your changes:
>
> [url=https://postimg.cc/D8Sf1p48][img]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fi.postimg.cc%2FD8Sf1p48%2Fshot-2018-10-04_17-42-09.jpg%5B%2Fimg%5D%5B%2Furldata=01%7C01%7Ccmatsuura%40vivint.com%7C4b957a380bc24ebda1f708d62a546496%7C54cc98ca024a470185483741e3b8d59d%7C0sdata=w9eslvFB%2F13VBHGG7n48C2KH4ceyk1Acb5G3wEoPdEc%3Dreserved=0]
>
> Atheros card connected to RT3070 iperf test difference was negligible (1Mbps
> or less) on bodhi system, but
> it started to throw out reorder messages on my standard ubuntu after your
> changes:
>
> [url=https://postimg.cc/SjJbP2SP][img]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fi.postimg.cc%2FSjJbP2SP%2FScreenshot.png%5B%2Fimg%5D%5B%2Furldata=01%7C01%7Ccmatsuura%40vivint.com%7C4b957a380bc24ebda1f708d62a546496%7C54cc98ca024a470185483741e3b8d59d%7C0sdata=7AfQGKReywwEYrVZzYOxpLqbmg8kBdCbNE6Mj0%2BmGRM%3Dreserved=0]
>
> My advice: stop sending low-quality patches and do some testing before
> submission.
>

Hi

No idea where did you got that message from, some safelink protection
seem to be added somewhere in the mailing process. You can check my
original mail here:
https://www.mail-archive.com/linux-wireless@vger.kernel.org/msg49652.html
. If interested in links you should open them manually as the URL
formating seems inappropriate.


Re: [PATCH 6/6] brcmfmac: Cleanup brcmf_fw_request_done()

2018-11-05 Thread Arend van Spriel

On 10/9/2018 2:47 PM, Hans de Goede wrote:

The "cur" variable is now only used for a debug print and we already
print the same info from brcmf_fw_complete_request(), so the debug print
does not provide any extra info and we can remove it.


I guess this could have been collapsed in the first patch introducing 
brcmf_fw_complete_request(). All-in-all a nice cleanup. Thanks.


Reviewed-by: Arend van Spriel 

Signed-off-by: Hans de Goede 
---
 .../net/wireless/broadcom/brcm80211/brcmfmac/firmware.c   | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)




Re: [PATCH 4/6] brcmfmac: Set board_type used for nvram file selection to machine-compatible

2018-11-05 Thread Arend van Spriel

On 10/9/2018 2:47 PM, Hans de Goede wrote:

For of/devicetree using machines, set the board_type used for nvram file
selection to the first string listed in the top-level's node compatible
string, aka the machine-compatible as used by of_machine_is_compatible().

The board_type setting is used to load the board-specific nvram file with
a board-specific name so that we can ship files for each supported board
in linux-firmware.


Reviewed-by: Arend van Spriel 

Signed-off-by: Hans de Goede 
---
 .../net/wireless/broadcom/brcm80211/brcmfmac/common.h |  1 +
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c | 11 ++-
 .../net/wireless/broadcom/brcm80211/brcmfmac/pcie.c   |  1 +
 .../net/wireless/broadcom/brcm80211/brcmfmac/sdio.c   |  1 +
 4 files changed, 13 insertions(+), 1 deletion(-)




Re: [PATCH 5/6] brcmfmac: Set board_type from DMI on x86 based machines

2018-11-05 Thread Arend van Spriel

On 10/9/2018 2:47 PM, Hans de Goede wrote:

For x86 based machines, set the board_type used for nvram file selection
based on the DMI sys-vendor and product-name strings.

Since on some models these strings are too generic, this commit also adds
a quirk table overriding the strings for models listed in that table.

The board_type setting is used to load the board-specific nvram file with
a board-specific name so that we can ship files for each supported board
in linux-firmware.


some comments below

Reviewed-by: Arend van Spriel 

Signed-off-by: Hans de Goede 
---
 .../broadcom/brcm80211/brcmfmac/Makefile  |   2 +
 .../broadcom/brcm80211/brcmfmac/common.c  |   3 +-
 .../broadcom/brcm80211/brcmfmac/common.h  |   7 ++
 .../broadcom/brcm80211/brcmfmac/dmi.c | 104 ++
 4 files changed, 115 insertions(+), 1 deletion(-)
 create mode 100644 drivers/net/wireless/broadcom/brcm80211/brcmfmac/dmi.c

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile
index 1f5a9b948abf..22fd95a736a8 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile
@@ -54,3 +54,5 @@ brcmfmac-$(CONFIG_BRCM_TRACING) += \
tracepoint.o
 brcmfmac-$(CONFIG_OF) += \
of.o
+brcmfmac-$(CONFIG_DMI) += \
+   dmi.o


Assuming OF and DMI are mutual exclusive, right?


diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/dmi.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/dmi.c
new file mode 100644
index ..fadc0ec745b8
--- /dev/null
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/dmi.c


[...]


+static const struct dmi_system_id dmi_platform_data[] = {


maybe call this dmi_platform_quirk as in brcmf_dmi_probe() you call this 
a "quirk table".


Re: [PATCH 3/6] brcmfmac: Add support for first trying to get a board specific nvram file

2018-11-05 Thread Arend van Spriel

On 10/9/2018 2:47 PM, Hans de Goede wrote:

The nvram files which some brcmfmac chips need are board-specific. To be
able to distribute these as part of linux-firmware, so that devices with
such a wifi chip will work OOTB, multiple (one per board) versions must
co-exist under /lib/firmware.

This commit adds support for callers of the brcmfmac/firmware.c code to
pass in a board_type parameter through the request structure.

If that parameter is set then the code will first try to load
chipmodel.board_type.txt before falling back to the old chipmodel.txt name.


minor comment below...

Reviewed-by: Arend van Spriel 

Signed-off-by: Hans de Goede 
---
 .../broadcom/brcm80211/brcmfmac/firmware.c| 27 ++-
 .../broadcom/brcm80211/brcmfmac/firmware.h|  1 +
 2 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
index 08aaf99fee34..6755b2388fbc 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
@@ -532,6 +532,31 @@ static int brcmf_fw_complete_request(const struct firmware 
*fw,
return (cur->flags & BRCMF_FW_REQF_OPTIONAL) ? 0 : ret;
 }

+static int brcmf_fw_request_firmware(const struct firmware **fw,
+struct brcmf_fw *fwctx)
+{
+   struct brcmf_fw_item *cur = >req->items[fwctx->curpos];
+   int ret;
+
+   /* nvram files are board-specific, first try a board-specific path */
+   if (cur->type == BRCMF_FW_TYPE_NVRAM && fwctx->req->board_type) {
+   char alt_path[BRCMF_FW_NAME_LEN];
+
+   strlcpy(alt_path, cur->path, BRCMF_FW_NAME_LEN);
+   /* strip .txt at the end */
+   alt_path[strlen(alt_path) - 4] = 0;
+   strlcat(alt_path, ".", BRCMF_FW_NAME_LEN);


why not string just "txt"?


+   strlcat(alt_path, fwctx->req->board_type, BRCMF_FW_NAME_LEN);
+   strlcat(alt_path, ".txt", BRCMF_FW_NAME_LEN);
+
+   ret = request_firmware(fw, alt_path, fwctx->dev);
+   if (ret == 0)
+   return ret;
+   }
+
+   return request_firmware(fw, cur->path, fwctx->dev);
+}
+
 static void brcmf_fw_request_done(const struct firmware *fw, void *ctx)
 {
struct brcmf_fw *fwctx = ctx;
@@ -544,7 +569,7 @@ static void brcmf_fw_request_done(const struct firmware 
*fw, void *ctx)

while (ret == 0 && ++fwctx->curpos < fwctx->req->n_items) {
cur = >req->items[fwctx->curpos];
-   request_firmware(, cur->path, fwctx->dev);
+   brcmf_fw_request_firmware(, fwctx);
ret = brcmf_fw_complete_request(fw, ctx);
}

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h
index 2893e56910f0..a0834be8864e 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h
@@ -70,6 +70,7 @@ struct brcmf_fw_request {
u16 domain_nr;
u16 bus_nr;
u32 n_items;
+   const char *board_type;
struct brcmf_fw_item items[0];
 };






Re: [PATCH 2/6] brcmfmac: Remove recursion from firmware load error handling

2018-11-05 Thread Arend van Spriel

On 10/9/2018 2:47 PM, Hans de Goede wrote:

Before this commit brcmf_fw_request_done would call
brcmf_fw_request_next_item to load the next item, which on an error would
call brcmf_fw_request_done, which if the error is recoverable (*) will
then continue calling brcmf_fw_request_next_item for the next item again
which on an error will call brcmf_fw_request_done again...

This does not blow up because we only have a limited number of items so
we never recurse too deep. But the recursion is still quite ugly and
frankly is giving me a headache, so lets fix this.

This commit fixes this by removing brcmf_fw_request_next_item and by
making brcmf_fw_get_firmwares and brcmf_fw_request_done directly call
firmware_request_nowait resp. firmware_request themselves.

*) brcmf_fw_request_nvram_done fallback path succeeds or
   BRCMF_FW_REQF_OPTIONAL is set


Reviewed-by: Arend van Spriel 

Signed-off-by: Hans de Goede 
---
 .../broadcom/brcm80211/brcmfmac/firmware.c| 65 ++-
 1 file changed, 19 insertions(+), 46 deletions(-)




Re: [PATCH 1/6] brcmfmac: Remove firmware-loading code duplication

2018-11-05 Thread Arend van Spriel

On 10/9/2018 2:47 PM, Hans de Goede wrote:

brcmf_fw_request_next_item and brcmf_fw_request_done both have identical
code to complete the fw-request depending on the item-type.

This commit adds a new brcmf_fw_complete_request helper removing this code
duplication.


Reviewed-by: Arend van Spriel 

Signed-off-by: Hans de Goede 
---
 .../broadcom/brcm80211/brcmfmac/firmware.c| 62 +--
 1 file changed, 31 insertions(+), 31 deletions(-)




RTL8188EUS support

2018-11-05 Thread Menion
Hi all
I have a question about the support of RTL8188EUS chipset (which I
have in a TpLink 0bda:8179 usb dongle)
This dongle works with the wext staging driver r8188eu driver. Is it
meant to be supported in the rtl2xxx driver?
Bye


[PATCH] rtlwifi: rtl8192de: Fix misleading REG_MCUFWDL information

2018-11-05 Thread Shaokun Zhang
RT_TRACE shows REG_MCUFWDL value as a decimal value with a '0x'
prefix, which is somewhat misleading.

Fix it to print hexadecimal, as was intended.

Cc: Ping-Ke Shih 
Cc: Kalle Valo 
Signed-off-by: Shaokun Zhang 
---
 drivers/net/wireless/realtek/rtlwifi/rtl8192de/fw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192de/fw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192de/fw.c
index 85cedd0..75bfa9d 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192de/fw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192de/fw.c
@@ -173,7 +173,7 @@ static int _rtl92d_fw_init(struct ieee80211_hw *hw)
 rtl_read_byte(rtlpriv, FW_MAC1_READY));
}
RT_TRACE(rtlpriv, COMP_FW, DBG_DMESG,
-"Polling FW ready fail!! REG_MCUFWDL:0x%08ul\n",
+"Polling FW ready fail!! REG_MCUFWDL:0x%08x\n",
 rtl_read_dword(rtlpriv, REG_MCUFWDL));
return -1;
 }
-- 
2.7.4



Re: [PATCH 4/8] staging: wilc1000: avoid line over 80 chars in wilc_parse_network_info()

2018-11-05 Thread Joe Perches
On Thu, 2018-11-01 at 16:45 +, ajay.kat...@microchip.com wrote:
> From: Ajay Singh 
> 
> Use shorter name for 'network_info' variable to avoid line over 80 chars
> issue.


I suppose this is OK, though perhaps unnecessary.

As well, perhaps there are defects in the original code
in a couple places.

> diff --git a/drivers/staging/wilc1000/coreconfigurator.c 
> b/drivers/staging/wilc1000/coreconfigurator.c
[]
> - network_info->tsf_hi = le64_to_cpu(mgt->u.beacon.timestamp);
> - network_info->tsf_lo = (u32)network_info->tsf_hi;

Perhaps there is a defect for both tsf_hi assignments
as it appears as if both are missing ">> 32"

> + info->cap_info = le16_to_cpu(mgt->u.beacon.capab_info);
> + info->beacon_period = le16_to_cpu(mgt->u.beacon.beacon_int);
> + info->tsf_hi = le64_to_cpu(mgt->u.beacon.timestamp);
> + info->tsf_lo = (u32)info->tsf_hi;

Perhaps this should be 

network_info->tsf_hi = le64_to_cpu(mgt->u.beacon.timestamp) >> 
32;

or

network_info->tsf_hi = upper_32_bits(le64_to_cpu(...));
network_info->tsf_lo = lower_32_bits(le64_to_cpu(...));




Re: [PATCH 5/6] brcmfmac: Set board_type from DMI on x86 based machines

2018-11-05 Thread Hans de Goede

Hi,

On 10-10-18 10:15, Arend van Spriel wrote:

On 10/10/2018 9:59 AM, Hans de Goede wrote:



Any chance you could do a patch-review of this series?


Yup and test for regressions with some of the chipsets I have here.


Have you gotten around to review and testing this series yet?
it would be nice to get this upstream.

Also a review of the 2 patch series starting with:
"brcmfmac: Add support for getting nvram contents from EFI variables"
would be appreciated.

Regards,

Hans


Re: 7f9a3e150ec7d breaks brcmfmac with modparam roamoff=1

2018-11-05 Thread Arend van Spriel

On 11/4/2018 8:04 PM, Stijn Tintel wrote:

[  259.240131] WARNING: CPU: 0 PID: 50 at
/home/build/lede/build_dir/target-arm_arm1176jzf-s+vfp_musl_eabi/linux-brcm2708_bcm2708/backports-4.19-rc5-1/net/wireless/core.c:736
wiphy_register+0x280/0xa58 [cfg80211]
[  259.274067] Modules linked in: brcmfmac(+) pppoe ppp_async pppox


Hi Stijn,

Thanks for the report. The code fails on the check below:

diff --git a/net/wireless/core.c b/net/wireless/core.c
index c0fd8a85e7f7..5fe35aafdd9c 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -725,6 +725,10 @@ int wiphy_register(struct wiphy *wiphy)
(!rdev->ops->set_pmk || !rdev->ops->del_pmk)))
return -EINVAL;

+   if (WARN_ON(!(rdev->wiphy.flags & WIPHY_FLAG_SUPPORTS_FW_ROAM) &&
+   rdev->ops->update_connect_params))
+   return -EINVAL;
+
if (wiphy->addresses)
memcpy(wiphy->perm_addr, wiphy->addresses[0].addr, ETH_ALEN);

It seemed to makes sense to me at the time to have this check and I 
would say it still does. So I probably need to fix brcmfmac for this.


Regards,
Arend