LinuxLists.cc - [PATCH 1/3] brcmfmac: set wpa_auth to WPA_AUTH

[permalink] [raw]

Subject: Re: [PATCH 1/3] brcmfmac: set wpa_auth to WPA_AUTH_DISABLED in AP/opensecurity mode

On 01-08-17 10:48, Wright Feng wrote:
> When setting wpa_auth to WPA_AUTH_NONE(1) in AP mode with WEP secuirty,
> firmware will set privacy bit and add WPA OUI in VENDOR IE in beacon and
> probe response. It confuses the supplicant in sation client by the
> security type from softAP beacon and we will see [WPA-?] in scan result.
> So we set WPA_AUTH_DISABLED in softAP mode with opensecurity.
>
> Signed-off-by: Wright Feng <[email protected]>
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> index a31ea10..54588d2 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> @@ -3854,6 +3854,7 @@ static s32 brcmf_cfg80211_suspend(struct wiphy *wiphy,
> static s32 brcmf_configure_opensecurity(struct brcmf_if *ifp)
> {
> s32 err;
> + s32 wpa_val;
>
> /* set auth */
> err = brcmf_fil_bsscfg_int_set(ifp, "auth", 0);
> @@ -3868,7 +3869,11 @@ static s32 brcmf_configure_opensecurity(struct brcmf_if *ifp)
> return err;
> }
> /* set upper-layer auth */
> - err = brcmf_fil_bsscfg_int_set(ifp, "wpa_auth", WPA_AUTH_NONE);
> + if (brcmf_is_ibssmode(ifp->vif))
> + wpa_val = WPA_AUTH_NONE;
> + else
> + wpa_val = WPA_AUTH_DISABLED;
> + err = brcmf_fil_bsscfg_int_set(ifp, "wpa_auth", wpa_val);

Is WPA_AUTH_NONE ok for IBSS mode? Not sure why it is handled
differently. Is it because you do not want to change things for IBSS
mode as you did not try that?

Regards,
Arend

2017-08-02 09:32:22

[permalink] [raw]

Subject: Re: [PATCH 3/3] brcmfmac: fix wrong num_different_channels when mchan feature enabled

Wright Feng <[email protected]> writes:

> The num_different_channels in wiphy info is not correct when firmware
> supports mchan. When mchan is on, num_different_channels is always
> overridden to 1 in brcmf_setup_ifmodes. Correct the logic by moving
> num_different_channels setting forward.
>
> Signed-off-by: Wright Feng <[email protected]>

Does this fix a user visible bug? If yes, it would be nice to document
that.

--
Kalle Valo

2017-08-01 09:39:34

[permalink] [raw]

Subject: [PATCH 3/3] brcmfmac: fix wrong num_different_channels when mchan feature enabled

The num_different_channels in wiphy info is not correct when firmware
supports mchan. When mchan is on, num_different_channels is always
overridden to 1 in brcmf_setup_ifmodes. Correct the logic by moving
num_different_channels setting forward.

Signed-off-by: Wright Feng <[email protected]>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 54588d2..3dcb139 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -6318,6 +6318,8 @@ static int brcmf_setup_ifmodes(struct wiphy *wiphy, struct brcmf_if *ifp)
if (p2p) {
if (brcmf_feat_is_enabled(ifp, BRCMF_FEAT_MCHAN))
combo[c].num_different_channels = 2;
+ else
+ combo[c].num_different_channels = 1;
wiphy->interface_modes |= BIT(NL80211_IFTYPE_P2P_CLIENT) |
BIT(NL80211_IFTYPE_P2P_GO) |
BIT(NL80211_IFTYPE_P2P_DEVICE);
@@ -6327,10 +6329,10 @@ static int brcmf_setup_ifmodes(struct wiphy *wiphy, struct brcmf_if *ifp)
c0_limits[i++].types = BIT(NL80211_IFTYPE_P2P_CLIENT) |
BIT(NL80211_IFTYPE_P2P_GO);
} else {
+ combo[c].num_different_channels = 1;
c0_limits[i].max = 1;
c0_limits[i++].types = BIT(NL80211_IFTYPE_AP);
}
- combo[c].num_different_channels = 1;
combo[c].max_interfaces = i;
combo[c].n_limits = i;
combo[c].limits = c0_limits;
--
1.9.1

2017-08-01 09:39:35

[permalink] [raw]

Subject: [PATCH 2/3] brcmfmac: Add support for CYW4373 SDIO/USB chipset

From: Chi-Hsien Lin <[email protected]>

These changes add support for CYW4373 SDIO/USB chipset.

Signed-off-by: Chi-Hsien Lin <[email protected]>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 1 +
drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c | 2 ++
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 4 +++-
drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c | 9 ++++++++-
drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h | 3 +++
include/linux/mmc/sdio_ids.h | 1 +
6 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
index 9b970dc..ea47f75 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
@@ -1108,6 +1108,7 @@ static int brcmf_sdiod_probe(struct brcmf_sdio_dev *sdiodev)
BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_43455),
BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_4354),
BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_4356),
+ BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_CYPRESS_4373),
{ /* 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 05f22ff..c5d1a1c 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
@@ -690,6 +690,8 @@ static u32 brcmf_chip_tcm_rambase(struct brcmf_chip_priv *ci)
case BRCM_CC_4365_CHIP_ID:
case BRCM_CC_4366_CHIP_ID:
return 0x200000;
+ case CY_CC_4373_CHIP_ID:
+ return 0x160000;
default:
brcmf_err("unknown chip: %s\n", ci->pub.name);
break;
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index 5653d6d..b1789b1 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -616,6 +616,7 @@ struct sdiod_drive_str {
BRCMF_FW_NVRAM_DEF(43455, "brcmfmac43455-sdio.bin", "brcmfmac43455-sdio.txt");
BRCMF_FW_NVRAM_DEF(4354, "brcmfmac4354-sdio.bin", "brcmfmac4354-sdio.txt");
BRCMF_FW_NVRAM_DEF(4356, "brcmfmac4356-sdio.bin", "brcmfmac4356-sdio.txt");
+BRCMF_FW_NVRAM_DEF(4373, "brcmfmac4373-sdio.bin", "brcmfmac4373-sdio.txt");

static struct brcmf_firmware_mapping brcmf_sdio_fwnames[] = {
BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43143_CHIP_ID, 0xFFFFFFFF, 43143),
@@ -633,7 +634,8 @@ struct sdiod_drive_str {
BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43430_CHIP_ID, 0xFFFFFFFF, 43430),
BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4345_CHIP_ID, 0xFFFFFFC0, 43455),
BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4354_CHIP_ID, 0xFFFFFFFF, 4354),
- BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4356_CHIP_ID, 0xFFFFFFFF, 4356)
+ BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4356_CHIP_ID, 0xFFFFFFFF, 4356),
+ BRCMF_FW_NVRAM_ENTRY(CY_CC_4373_CHIP_ID, 0xFFFFFFFF, 4373)
};

static void pkt_align(struct sk_buff *p, int len, int align)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
index 0eea48e..8f20a4b 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
@@ -50,6 +50,7 @@
BRCMF_FW_DEF(43236B, "brcmfmac43236b.bin");
BRCMF_FW_DEF(43242A, "brcmfmac43242a.bin");
BRCMF_FW_DEF(43569, "brcmfmac43569.bin");
+BRCMF_FW_DEF(4373, "brcmfmac4373.bin");

static struct brcmf_firmware_mapping brcmf_usb_fwnames[] = {
BRCMF_FW_ENTRY(BRCM_CC_43143_CHIP_ID, 0xFFFFFFFF, 43143),
@@ -58,7 +59,8 @@
BRCMF_FW_ENTRY(BRCM_CC_43238_CHIP_ID, 0x00000008, 43236B),
BRCMF_FW_ENTRY(BRCM_CC_43242_CHIP_ID, 0xFFFFFFFF, 43242A),
BRCMF_FW_ENTRY(BRCM_CC_43566_CHIP_ID, 0xFFFFFFFF, 43569),
- BRCMF_FW_ENTRY(BRCM_CC_43569_CHIP_ID, 0xFFFFFFFF, 43569)
+ BRCMF_FW_ENTRY(BRCM_CC_43569_CHIP_ID, 0xFFFFFFFF, 43569),
+ BRCMF_FW_ENTRY(CY_CC_4373_CHIP_ID, 0xFFFFFFFF, 4373)
};

#define TRX_MAGIC 0x30524448 /* "HDR0" */
@@ -1463,15 +1465,20 @@ static int brcmf_usb_reset_resume(struct usb_interface *intf)
#define LINKSYS_USB_DEVICE(dev_id) \
{ USB_DEVICE(BRCM_USB_VENDOR_ID_LINKSYS, dev_id) }

+#define CYPRESS_USB_DEVICE(dev_id) \
+ { USB_DEVICE(CY_USB_VENDOR_ID_CYPRESS, dev_id) }
+
static struct usb_device_id brcmf_usb_devid_table[] = {
BRCMF_USB_DEVICE(BRCM_USB_43143_DEVICE_ID),
BRCMF_USB_DEVICE(BRCM_USB_43236_DEVICE_ID),
BRCMF_USB_DEVICE(BRCM_USB_43242_DEVICE_ID),
BRCMF_USB_DEVICE(BRCM_USB_43569_DEVICE_ID),
LINKSYS_USB_DEVICE(BRCM_USB_43235_LINKSYS_DEVICE_ID),
+ CYPRESS_USB_DEVICE(CY_USB_4373_DEVICE_ID),
{ USB_DEVICE(BRCM_USB_VENDOR_ID_LG, BRCM_USB_43242_LG_DEVICE_ID) },
/* special entry for device with firmware loaded and running */
BRCMF_USB_DEVICE(BRCM_USB_BCMFW_DEVICE_ID),
+ CYPRESS_USB_DEVICE(BRCM_USB_BCMFW_DEVICE_ID),
{ /* end: all zeroes */ }
};

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 f1fb8a3..57544a3 100644
--- a/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
+++ b/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
@@ -23,6 +23,7 @@
#define BRCM_USB_VENDOR_ID_BROADCOM 0x0a5c
#define BRCM_USB_VENDOR_ID_LG 0x043e
#define BRCM_USB_VENDOR_ID_LINKSYS 0x13b1
+#define CY_USB_VENDOR_ID_CYPRESS 0x04b4
#define BRCM_PCIE_VENDOR_ID_BROADCOM PCI_VENDOR_ID_BROADCOM

/* Chipcommon Core Chip IDs */
@@ -57,6 +58,7 @@
#define BRCM_CC_4365_CHIP_ID 0x4365
#define BRCM_CC_4366_CHIP_ID 0x4366
#define BRCM_CC_4371_CHIP_ID 0x4371
+#define CY_CC_4373_CHIP_ID 0x4373

/* USB Device IDs */
#define BRCM_USB_43143_DEVICE_ID 0xbd1e
@@ -66,6 +68,7 @@
#define BRCM_USB_43242_LG_DEVICE_ID 0x3101
#define BRCM_USB_43569_DEVICE_ID 0xbd27
#define BRCM_USB_BCMFW_DEVICE_ID 0x0bdc
+#define CY_USB_4373_DEVICE_ID 0xbd29

/* PCIE Device IDs */
#define BRCM_PCIE_4350_DEVICE_ID 0x43a3
diff --git a/include/linux/mmc/sdio_ids.h b/include/linux/mmc/sdio_ids.h
index b733eb4..abacd54 100644
--- a/include/linux/mmc/sdio_ids.h
+++ b/include/linux/mmc/sdio_ids.h
@@ -39,6 +39,7 @@
#define SDIO_DEVICE_ID_BROADCOM_43455 0xa9bf
#define SDIO_DEVICE_ID_BROADCOM_4354 0x4354
#define SDIO_DEVICE_ID_BROADCOM_4356 0x4356
+#define SDIO_DEVICE_ID_CYPRESS_4373 0x4373

#define SDIO_VENDOR_ID_INTEL 0x0089
#define SDIO_DEVICE_ID_INTEL_IWMC3200WIMAX 0x1402
--
1.9.1

2017-08-01 12:43:04

[permalink] [raw]

Subject: Re: [PATCH 2/3] brcmfmac: Add support for CYW4373 SDIO/USB chipset

On 01-08-17 10:48, Wright Feng wrote:
> From: Chi-Hsien Lin <[email protected]>
>
> These changes add support for CYW4373 SDIO/USB chipset.

Could you summarize 4373 features, ie. is it 11n or 11ac? How much
streams does it support? That kind of stuff.

Regards,
Arend

2017-08-02 10:17:59

[permalink] [raw]

Subject: Re: [PATCH 3/3] brcmfmac: fix wrong num_different_channels when mchan feature enabled

On 8/2/2017 11:32 AM, Kalle Valo wrote:
> Wright Feng <[email protected]> writes:
>
>> The num_different_channels in wiphy info is not correct when firmware
>> supports mchan. When mchan is on, num_different_channels is always
>> overridden to 1 in brcmf_setup_ifmodes. Correct the logic by moving
>> num_different_channels setting forward.
>>
>> Signed-off-by: Wright Feng <[email protected]>
>
> Does this fix a user visible bug? If yes, it would be nice to document
> that.

Hi Kalle,

Depends on the users expectation ;-) When the device/firmware supports
multi-channel (better not use mchan abbreviation) it can have P2P
connection and regular connection with AP simultaneous. So the current
state is that this is not possible regardless whether mchan is
supported. So the device is not used to fullest extent.

Regards,
Arend

2017-08-02 09:30:47

[permalink] [raw]

Subject: Re: [PATCH 1/3] brcmfmac: set wpa_auth to WPA_AUTH_DISABLED in AP/opensecurity mode

Wright Feng <[email protected]> writes:

> When setting wpa_auth to WPA_AUTH_NONE(1) in AP mode with WEP secuirty,
> firmware will set privacy bit and add WPA OUI in VENDOR IE in beacon and
> probe response.

typo: "secuirty"

> It confuses the supplicant in sation client by the security type from
> softAP beacon and we will see [WPA-?] in scan result.

"sation"? Also the sentence is a bit unclear.

> So we set WPA_AUTH_DISABLED in softAP mode with opensecurity.

Space missing between "open" and "security".

--
Kalle Valo

2017-08-02 13:40:12

[permalink] [raw]

Subject: Re: [PATCH 3/3] brcmfmac: fix wrong num_different_channels when mchan feature enabled

Arend van Spriel <[email protected]> writes:

> On 8/2/2017 11:32 AM, Kalle Valo wrote:
>> Wright Feng <[email protected]> writes:
>>
>>> The num_different_channels in wiphy info is not correct when firmware
>>> supports mchan. When mchan is on, num_different_channels is always
>>> overridden to 1 in brcmf_setup_ifmodes. Correct the logic by moving
>>> num_different_channels setting forward.
>>>
>>> Signed-off-by: Wright Feng <[email protected]>
>>
>> Does this fix a user visible bug? If yes, it would be nice to document
>> that.
>
> Hi Kalle,
>
> Depends on the users expectation ;-) When the device/firmware supports
> multi-channel (better not use mchan abbreviation) it can have P2P
> connection and regular connection with AP simultaneous. So the current
> state is that this is not possible regardless whether mchan is
> supported. So the device is not used to fullest extent.

Thanks, I understand now and I think your description should be also in
the commit log so that others will also :)

My usual mantra: the commit log should ALWAYS answer the question "_why_
the change is made?" and describe the reason what motivated to implement
the patch. This is the most important part. It helps maintainers,
backports, distros etc to make decisions if the patch is important for
them or not.

--
Kalle Valo

2017-08-02 03:55:34

[permalink] [raw]

Subject: Re: [PATCH 1/3] brcmfmac: set wpa_auth to WPA_AUTH_DISABLED in AP/opensecurity mode

On 2017/8/1 下午 08:41, Arend van Spriel wrote:
> On 01-08-17 10:48, Wright Feng wrote:
>> When setting wpa_auth to WPA_AUTH_NONE(1) in AP mode with WEP secuirty,
>> firmware will set privacy bit and add WPA OUI in VENDOR IE in beacon and
>> probe response. It confuses the supplicant in sation client by the
>> security type from softAP beacon and we will see [WPA-?] in scan result.
>> So we set WPA_AUTH_DISABLED in softAP mode with opensecurity.
>>
>> Signed-off-by: Wright Feng <[email protected]>
>> ---
>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 7 ++++++-
>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>> index a31ea10..54588d2 100644
>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
>> @@ -3854,6 +3854,7 @@ static s32 brcmf_cfg80211_suspend(struct wiphy *wiphy,
>> static s32 brcmf_configure_opensecurity(struct brcmf_if *ifp)
>> {
>> s32 err;
>> + s32 wpa_val;
>>
>> /* set auth */
>> err = brcmf_fil_bsscfg_int_set(ifp, "auth", 0);
>> @@ -3868,7 +3869,11 @@ static s32 brcmf_configure_opensecurity(struct brcmf_if *ifp)
>> return err;
>> }
>> /* set upper-layer auth */
>> - err = brcmf_fil_bsscfg_int_set(ifp, "wpa_auth", WPA_AUTH_NONE);
>> + if (brcmf_is_ibssmode(ifp->vif))
>> + wpa_val = WPA_AUTH_NONE;
>> + else
>> + wpa_val = WPA_AUTH_DISABLED;
>> + err = brcmf_fil_bsscfg_int_set(ifp, "wpa_auth", wpa_val);
>
> Is WPA_AUTH_NONE ok for IBSS mode? Not sure why it is handled
> differently. Is it because you do not want to change things for IBSS
> mode as you did not try that?

I would like to keep WPA_AUTH_NODE for IBSS mode because the comment of
WPA_AUTH_NONE definition in brcmu_wifi.h is "none (IBSS)". It seems that
WPA_AUTH_NONE is for IBSS mode.
>
> Regards,
> Arend
>

2017-08-01 15:53:46

by Chi-Hsien Lin

[permalink] [raw]

Subject: Re: [PATCH 2/3] brcmfmac: Add support for CYW4373 SDIO/USB chipset

On 08/01/2017 8:43, Arend van Spriel wrote:
>
>
> On 01-08-17 10:48, Wright Feng wrote:
>> From: Chi-Hsien Lin <[email protected]>
>>
>> These changes add support for CYW4373 SDIO/USB chipset.
>
> Could you summarize 4373 features, ie. is it 11n or 11ac? How much
> streams does it support? That kind of stuff.
Sure. 4373 is a 1x1 dual-band 11ac chip with 20/40/80Mhz channel
support. It's a WiFi/BT combo chip with SDIO/USB bus support.

>
> Regards,
> Arend
> .
>

2017-08-03 01:57:33

[permalink] [raw]

Subject: Re: [PATCH 3/3] brcmfmac: fix wrong num_different_channels when mchan feature enabled

On 2017/8/2 下午 09:40, Kalle Valo wrote:
> Arend van Spriel <[email protected]> writes:
>
>> On 8/2/2017 11:32 AM, Kalle Valo wrote:
>>> Wright Feng <[email protected]> writes:
>>>
>>>> The num_different_channels in wiphy info is not correct when firmware
>>>> supports mchan. When mchan is on, num_different_channels is always
>>>> overridden to 1 in brcmf_setup_ifmodes. Correct the logic by moving
>>>> num_different_channels setting forward.
>>>>
>>>> Signed-off-by: Wright Feng <[email protected]>
>>>
>>> Does this fix a user visible bug? If yes, it would be nice to document
>>> that.
>>
>> Hi Kalle,
>>
>> Depends on the users expectation ;-) When the device/firmware supports
>> multi-channel (better not use mchan abbreviation) it can have P2P
>> connection and regular connection with AP simultaneous. So the current
>> state is that this is not possible regardless whether mchan is
>> supported. So the device is not used to fullest extent.
>
> Thanks, I understand now and I think your description should be also in
> the commit log so that others will also :)
>
> My usual mantra: the commit log should ALWAYS answer the question "_why_
> the change is made?" and describe the reason what motivated to implement
> the patch. This is the most important part. It helps maintainers,
> backports, distros etc to make decisions if the patch is important for
> them or not.

Hi Kalle and Arend,
Thanks for your comment and suggestion, I will put them into commit
message and resend v2 later.
>

2017-08-02 08:16:01

[permalink] [raw]

Subject: Re: [PATCH 2/3] brcmfmac: Add support for CYW4373 SDIO/USB chipset

Arend van Spriel <[email protected]> writes:

> On 01-08-17 17:10, Chi-Hsien Lin wrote:
>>
>>
>> On 08/01/2017 8:43, Arend van Spriel wrote:
>>>
>>>
>>> On 01-08-17 10:48, Wright Feng wrote:
>>>> From: Chi-Hsien Lin <[email protected]>
>>>>
>>>> These changes add support for CYW4373 SDIO/USB chipset.
>>>
>>> Could you summarize 4373 features, ie. is it 11n or 11ac? How much
>>> streams does it support? That kind of stuff.
>> Sure. 4373 is a 1x1 dual-band 11ac chip with 20/40/80Mhz channel
>> support. It's a WiFi/BT combo chip with SDIO/USB bus support.
>
> Thanks. Can you add this info to the commit message and resend a V2. I
> think Kalle prefers that all patches are resubmitted in such event.

Correct.

I now documented this also in the wiki:

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

--
Kalle Valo

2017-08-01 21:03:51

[permalink] [raw]

Subject: Re: [PATCH 2/3] brcmfmac: Add support for CYW4373 SDIO/USB chipset

On 01-08-17 17:10, Chi-Hsien Lin wrote:
>
>
> On 08/01/2017 8:43, Arend van Spriel wrote:
>>
>>
>> On 01-08-17 10:48, Wright Feng wrote:
>>> From: Chi-Hsien Lin <[email protected]>
>>>
>>> These changes add support for CYW4373 SDIO/USB chipset.
>>
>> Could you summarize 4373 features, ie. is it 11n or 11ac? How much
>> streams does it support? That kind of stuff.
> Sure. 4373 is a 1x1 dual-band 11ac chip with 20/40/80Mhz channel
> support. It's a WiFi/BT combo chip with SDIO/USB bus support.

Thanks. Can you add this info to the commit message and resend a V2. I
think Kalle prefers that all patches are resubmitted in such event.

Regards,
Arend

2017-08-01 12:44:09