[PATCH] nfc: pn544: mei: constify mei_cl_device_id
mei_cl_device_id are not supposed to change at runtime.
mei driver is working with const 'id_table'. So mark
the non-const mei_cl_device_id structs as const.
Signed-off-by: Arvind Yadav
---
drivers/nfc/pn544/mei.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/nfc/pn544/mei.c b/drivers/nfc/pn544/mei.c
index ad57a8e..a6c2e9c 100644
--- a/drivers/nfc/pn544/mei.c
+++ b/drivers/nfc/pn544/mei.c
@@ -66,7 +66,7 @@ static int pn544_mei_remove(struct mei_cl_device *cldev)
return 0;
}
-static struct mei_cl_device_id pn544_mei_tbl[] = {
+static const struct mei_cl_device_id pn544_mei_tbl[] = {
{ PN544_DRIVER_NAME, MEI_NFC_UUID, MEI_CL_VERSION_ANY},
/* required last entry */
--
2.7.4
[PATCH] nfc: microread: mei: constify mei_cl_device_id
mei_cl_device_id are not supposed to change at runtime.
mei driver is working with const 'id_table'. So mark
the non-const mei_cl_device_id structs as const.
Signed-off-by: Arvind Yadav
---
drivers/nfc/microread/mei.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/nfc/microread/mei.c b/drivers/nfc/microread/mei.c
index eb5eddf..70bf7a1 100644
--- a/drivers/nfc/microread/mei.c
+++ b/drivers/nfc/microread/mei.c
@@ -66,7 +66,7 @@ static int microread_mei_remove(struct mei_cl_device *cldev)
return 0;
}
-static struct mei_cl_device_id microread_mei_tbl[] = {
+static const struct mei_cl_device_id microread_mei_tbl[] = {
{ MICROREAD_DRIVER_NAME, MEI_NFC_UUID, MEI_CL_VERSION_ANY},
/* required last entry */
--
2.7.4
Re: pull-request: wireless-drivers 2017-08-25
From: Kalle Valo Date: Fri, 25 Aug 2017 16:37:57 +0300 > here's pull request to net tree for 4.13, more info in the signed > tag below. Please let me know if there are any problems. Pulled, thanks Kalle.
Re: rtlwifi handling of sequence numbers with aggregation
On 08/25/2017 12:51 PM, Jes Sorensen wrote:
Hi,
Looking at some bits in rtlwifi I came across a discrepancy between the
PCI and USB code.
Consider the following code:
In rtl_pci_tx():
if (ieee80211_is_data_qos(fc)) {
tid = rtl_get_tid(skb);
if (sta) {
sta_entry = (struct rtl_sta_info *)sta->drv_priv;
seq_number = (le16_to_cpu(hdr->seq_ctrl) &
IEEE80211_SCTL_SEQ) >> 4;
seq_number += 1;
if (!ieee80211_has_morefrags(hdr->frame_control))
sta_entry->tids[tid].seq_number = seq_number;
}
In _rtl_usb_tx_preprocess():
if (ieee80211_is_data_qos(fc)) {
qc = ieee80211_get_qos_ctl(hdr);
tid = qc[0] & IEEE80211_QOS_CTL_TID_MASK;
seq_number = (le16_to_cpu(hdr->seq_ctrl) &
IEEE80211_SCTL_SEQ) >> 4;
seq_number += 1;
seq_number <<= 4;
}
[snip]
if (!ieee80211_has_morefrags(hdr->frame_control)) {
if (qc)
mac->tids[tid].seq_number = seq_number;
}
The seq_number is picked up from ieee80211_ops->ampdu_action()
which calls into rtl_tx_agg_start():
tid_data = &sta_entry->tids[tid];
RT_TRACE(rtlpriv, COMP_SEND, DBG_DMESG,
"on ra = %pM tid = %d seq:%d\n", sta->addr, tid,
tid_data->seq_number);
*ssn = tid_data->seq_number;
My question here is why does the USB code shift seq_number << 4 while
the PCI code doesn't? I assume one of these is wrong, but which one?
Based on my prejudices, I would suspect the USB driver before that of the PCI
version. I have BCc'd my contact at Realtek to see what he has to say on the issue.
Larry
Re: [PATCH 31/35] wireless: realtek: rtl8187: constify usb_device_id
On Tue, 8/8/17, Arvind Yadav wrote: Subject: [PATCH 31/35] wireless: realtek: rtl8187: constify usb_device_id To: kv...@codeaurora.org, her...@canonical.com, ht...@users.sourceforge.net, larry.fin...@lwfinger.net Cc: linux-ker...@vger.kernel.org, net...@vger.kernel.org, linux-wireless@vger.kernel.org Date: Tuesday, 8 August, 2017, 17:04 > usb_device_id are not supposed to change at > runtime. All functions > working with usb_device_id provided by > work with > const usb_device_id. So mark the > non-const structs as const. > Signed-off-by: Arvind Yadav Acked-by: ht...@users.sourceforge.net
Re: [PATCH v2] rt2800: fix TX_PIN_CFG setting for non MT7620 chips
On Fri, Aug 25, 2017 at 05:04:15PM +0200, Stanislaw Gruszka wrote:
> Since commit 41977e86c984 ("rt2x00: add support for MT7620") we do not
> initialize TX_PIN_CFG setting. This cause breakage at least on some
> RT3573 devices. To fix the problem patch restores previous behaviour
> for non MT7620 chips.
>
> Fixes: 41977e86c984 ("rt2x00: add support for MT7620")
> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1480829
> Reported-and-tested-by: Jussi Eloranta
> Cc: Daniel Golle
> Signed-off-by: Stanislaw Gruszka
Acked-by: Daniel Golle
> ---
> v1 -> v2: patch for updated linux version
>
> drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> index 0b75def39c6c..d2c289446c00 100644
> --- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> +++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> @@ -3702,7 +3702,10 @@ static void rt2800_config_channel(struct rt2x00_dev
> *rt2x00dev,
> if (rt2x00_rt(rt2x00dev, RT3572))
> rt2800_rfcsr_write(rt2x00dev, 8, 0);
>
> - tx_pin = rt2800_register_read(rt2x00dev, TX_PIN_CFG);
> + if (rt2x00_rt(rt2x00dev, RT6352))
> + tx_pin = rt2800_register_read(rt2x00dev, TX_PIN_CFG);
> + else
> + tx_pin = 0;
>
> switch (rt2x00dev->default_ant.tx_chain_num) {
> case 3:
> --
> 2.7.5
rtlwifi handling of sequence numbers with aggregation
Hi,
Looking at some bits in rtlwifi I came across a discrepancy between the
PCI and USB code.
Consider the following code:
In rtl_pci_tx():
if (ieee80211_is_data_qos(fc)) {
tid = rtl_get_tid(skb);
if (sta) {
sta_entry = (struct rtl_sta_info *)sta->drv_priv;
seq_number = (le16_to_cpu(hdr->seq_ctrl) &
IEEE80211_SCTL_SEQ) >> 4;
seq_number += 1;
if (!ieee80211_has_morefrags(hdr->frame_control))
sta_entry->tids[tid].seq_number = seq_number;
}
In _rtl_usb_tx_preprocess():
if (ieee80211_is_data_qos(fc)) {
qc = ieee80211_get_qos_ctl(hdr);
tid = qc[0] & IEEE80211_QOS_CTL_TID_MASK;
seq_number = (le16_to_cpu(hdr->seq_ctrl) &
IEEE80211_SCTL_SEQ) >> 4;
seq_number += 1;
seq_number <<= 4;
}
[snip]
if (!ieee80211_has_morefrags(hdr->frame_control)) {
if (qc)
mac->tids[tid].seq_number = seq_number;
}
The seq_number is picked up from ieee80211_ops->ampdu_action()
which calls into rtl_tx_agg_start():
tid_data = &sta_entry->tids[tid];
RT_TRACE(rtlpriv, COMP_SEND, DBG_DMESG,
"on ra = %pM tid = %d seq:%d\n", sta->addr, tid,
tid_data->seq_number);
*ssn = tid_data->seq_number;
My question here is why does the USB code shift seq_number << 4 while
the PCI code doesn't? I assume one of these is wrong, but which one?
Jes
Re: [PATCH 2/2] brcmfmac: Use separate firmware for revision 0 of the brcm43430 chip
Hi Hans,
On Fri, 2017-08-25 at 16:03 +0200, Hans de Goede wrote:
> Hi,
>
> On 25-08-17 15:55, Jörg Krause wrote:
> > Hi,
> >
> > On Fri, 2017-06-16 at 15:14 +0200, Hans de Goede wrote:
> > > The brcm43430 chip needs different firmware files for chip revision 0
> > > and 1. The file currently in linux-firmware is for revision 1 only.
> > >
> > > This commit makes brcmfmac request brcmfmac43430a0-sdio.bin instead
> > > of brcmfmac43430-sdio.bin for revision 0 chips.
> > >
> > > Note that the behavior for revision 1 chips is not changed, ideally those
> > > would load brcmfmac43430a1-sdio.bin, but that will break existing setups.
> > >
> > > Signed-off-by: Hans de Goede
> > > ---
> > > drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 7 +--
> > > 1 file changed, 5 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> > > b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> > > index 4ed40c94bda9..5125aeeb5310 100644
> > > --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> > > +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> > > @@ -612,7 +612,9 @@ BRCMF_FW_NVRAM_DEF(43340, "brcmfmac43340-sdio.bin",
> > > "brcmfmac43340-sdio.txt");
> > > BRCMF_FW_NVRAM_DEF(4335, "brcmfmac4335-sdio.bin",
> > > "brcmfmac4335-sdio.txt");
> > > BRCMF_FW_NVRAM_DEF(43362, "brcmfmac43362-sdio.bin",
> > > "brcmfmac43362-sdio.txt");
> > > BRCMF_FW_NVRAM_DEF(4339, "brcmfmac4339-sdio.bin",
> > > "brcmfmac4339-sdio.txt");
> > > -BRCMF_FW_NVRAM_DEF(43430, "brcmfmac43430-sdio.bin",
> > > "brcmfmac43430-sdio.txt");
> > > +BRCMF_FW_NVRAM_DEF(43430A0, "brcmfmac43430a0-sdio.bin",
> > > "brcmfmac43430a0-sdio.txt");
> > > +/* Note the names are not postfixed with a1 for backward compatibility */
> > > +BRCMF_FW_NVRAM_DEF(43430A1, "brcmfmac43430-sdio.bin",
> > > "brcmfmac43430-sdio.txt");
> > > BRCMF_FW_NVRAM_DEF(43455, "brcmfmac43455-sdio.bin",
> > > "brcmfmac43455-sdio.txt");
> > > BRCMF_FW_NVRAM_DEF(4354, "brcmfmac4354-sdio.bin",
> > > "brcmfmac4354-sdio.txt");
> > > BRCMF_FW_NVRAM_DEF(4356, "brcmfmac4356-sdio.bin",
> > > "brcmfmac4356-sdio.txt");
> > > @@ -630,7 +632,8 @@ static struct brcmf_firmware_mapping
> > > brcmf_sdio_fwnames[] = {
> > > BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4335_CHIP_ID, 0x, 4335),
> > > BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43362_CHIP_ID, 0xFFFE, 43362),
> > > BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4339_CHIP_ID, 0x, 4339),
> > > - BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43430_CHIP_ID, 0x, 43430),
> > > + BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43430_CHIP_ID, 0x0001, 43430A0),
> > > + BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43430_CHIP_ID, 0xFFFE, 43430A1),
> > > BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4345_CHIP_ID, 0xFFC0, 43455),
> > > BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4354_CHIP_ID, 0x, 4354),
> > > BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4356_CHIP_ID, 0x, 4356)
> >
> > Unfortunately, there is no "brcmfmac43430a0-sdio.bin" in linux-
> > firmware. Therefore, my custom board fails:
> >
> > # [ 24.894241] brcmfmac mmc0:0001:1: Direct firmware load for
> > brcm/brcmfmac43430a0-sdio.bin failed with error -2
> > [ 25.914322] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (100):
> > clkctl 0x50
> > [ 26.934186] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (100):
> > clkctl 0x50
> >
> > Can someone provide the firmware file, please?
>
> I've put all the versions I've been able to find here:
>
> http://jwrdegoede.danny.cz/brcm-firmware/
>
> Note that the 7.x.y.z version does not seem to have any useful meaning,
> higher is not necessarily newer :|
>
> [hans@shalem brcm-firmware]$ for i in brcmfmac43430a0-sdio.bin*; do echo $i
> && strings $i | tail -n 1; done
> brcmfmac43430a0-sdio.bin.7.10.1.244.ucode940.1020
> 43430a0-roml/sdio-g-pool-p2p-pno-pktfilter-keepalive-aoe-mchan-proptxstatus-lpc-wl11u-rcc-fmc-wepso-ccx-okc-fbt-noccxaka-txpwr-ampduhostreorder-clm_43xx_lg-ndoe
> Version: 7.10.1.244 CRC: 73c82137 Date: Fri 2016-07-01 18:03:15 KST Ucode
> Ver: 940.1020 FWID: 01-bae8afee
> brcmfmac43430a0-sdio.bin.7.10.226.49.no_ucode_version
> 43430a0-roml/sdio-g-pool-p2p-pno-pktfilter-keepalive-aoe-mchan-proptxstatus-lpc-wl11u-rcc-fmc-wepso-ccx-okc-fbt-noccxaka-txpwr-ampduhostreorder-clm_43xx_lg
> Version: 7.10.226.49 CRC: bf92cb0b Date: Fri 2014-06-06 14:55:15 KST FWID
> 01-8962686a
> brcmfmac43430a0-sdio.bin.7.10.68.5.ucode997.0
> 43430a0-roml/sdio-g-pool-p2p-pno-pktfilter-keepalive-aoe-mchan-proptxstatus-ampduhostreorder-lpc-wl11u-rcc-fmc-wepso-ccx-okc-anqpo-ltecx-sr-ndoe
> Version: 7.10.68.5 CRC: 5168922 Date: Thu 2015-04-30 04:20:43 PDT Ucode Ver:
> 997.0 FWID: 01-2bde7d77
>
> So date wise brcmfmac43430a0-sdio.bin.7.10.1.244.ucode940.1020 is the newest
> and IIRC that one works well for me.
>
> ucode version wise, brcmfmac43430a0-sdio.bin.7.10.68.5.ucode997.0 is newer,
> but the .0 in 997.0 makes it feel like an unproven release to me.
Re: [PATCH 2/2] brcmfmac: Use separate firmware for revision 0 of the brcm43430 chip
Hi,
On Fri, 2017-06-16 at 15:14 +0200, Hans de Goede wrote:
> The brcm43430 chip needs different firmware files for chip revision 0
> and 1. The file currently in linux-firmware is for revision 1 only.
>
> This commit makes brcmfmac request brcmfmac43430a0-sdio.bin instead
> of brcmfmac43430-sdio.bin for revision 0 chips.
>
> Note that the behavior for revision 1 chips is not changed, ideally those
> would load brcmfmac43430a1-sdio.bin, but that will break existing setups.
>
> Signed-off-by: Hans de Goede
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> index 4ed40c94bda9..5125aeeb5310 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> @@ -612,7 +612,9 @@ BRCMF_FW_NVRAM_DEF(43340, "brcmfmac43340-sdio.bin",
> "brcmfmac43340-sdio.txt");
> BRCMF_FW_NVRAM_DEF(4335, "brcmfmac4335-sdio.bin", "brcmfmac4335-sdio.txt");
> BRCMF_FW_NVRAM_DEF(43362, "brcmfmac43362-sdio.bin",
> "brcmfmac43362-sdio.txt");
> BRCMF_FW_NVRAM_DEF(4339, "brcmfmac4339-sdio.bin", "brcmfmac4339-sdio.txt");
> -BRCMF_FW_NVRAM_DEF(43430, "brcmfmac43430-sdio.bin",
> "brcmfmac43430-sdio.txt");
> +BRCMF_FW_NVRAM_DEF(43430A0, "brcmfmac43430a0-sdio.bin",
> "brcmfmac43430a0-sdio.txt");
> +/* Note the names are not postfixed with a1 for backward compatibility */
> +BRCMF_FW_NVRAM_DEF(43430A1, "brcmfmac43430-sdio.bin",
> "brcmfmac43430-sdio.txt");
> BRCMF_FW_NVRAM_DEF(43455, "brcmfmac43455-sdio.bin",
> "brcmfmac43455-sdio.txt");
> BRCMF_FW_NVRAM_DEF(4354, "brcmfmac4354-sdio.bin", "brcmfmac4354-sdio.txt");
> BRCMF_FW_NVRAM_DEF(4356, "brcmfmac4356-sdio.bin", "brcmfmac4356-sdio.txt");
> @@ -630,7 +632,8 @@ static struct brcmf_firmware_mapping brcmf_sdio_fwnames[]
> = {
> BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4335_CHIP_ID, 0x, 4335),
> BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43362_CHIP_ID, 0xFFFE, 43362),
> BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4339_CHIP_ID, 0x, 4339),
> - BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43430_CHIP_ID, 0x, 43430),
> + BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43430_CHIP_ID, 0x0001, 43430A0),
> + BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43430_CHIP_ID, 0xFFFE, 43430A1),
> BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4345_CHIP_ID, 0xFFC0, 43455),
> BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4354_CHIP_ID, 0x, 4354),
> BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4356_CHIP_ID, 0x, 4356)
Unfortunately, there is no "brcmfmac43430a0-sdio.bin" in linux-
firmware. Therefore, my custom board fails:
# [ 24.894241] brcmfmac mmc0:0001:1: Direct firmware load for
brcm/brcmfmac43430a0-sdio.bin failed with error -2
[ 25.914322] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (100):
clkctl 0x50
[ 26.934186] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (100):
clkctl 0x50
Can someone provide the firmware file, please?
Best regards,
Jörg Krause
Re: [PATCH 2/2] brcmfmac: Use separate firmware for revision 0 of the brcm43430 chip
Hi,
On Fri, 2017-06-16 at 15:14 +0200, Hans de Goede wrote:
> The brcm43430 chip needs different firmware files for chip revision 0
> and 1. The file currently in linux-firmware is for revision 1 only.
>
> This commit makes brcmfmac request brcmfmac43430a0-sdio.bin instead
> of brcmfmac43430-sdio.bin for revision 0 chips.
>
> Note that the behavior for revision 1 chips is not changed, ideally those
> would load brcmfmac43430a1-sdio.bin, but that will break existing setups.
>
> Signed-off-by: Hans de Goede
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> index 4ed40c94bda9..5125aeeb5310 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> @@ -612,7 +612,9 @@ BRCMF_FW_NVRAM_DEF(43340, "brcmfmac43340-sdio.bin",
> "brcmfmac43340-sdio.txt");
> BRCMF_FW_NVRAM_DEF(4335, "brcmfmac4335-sdio.bin", "brcmfmac4335-sdio.txt");
> BRCMF_FW_NVRAM_DEF(43362, "brcmfmac43362-sdio.bin",
> "brcmfmac43362-sdio.txt");
> BRCMF_FW_NVRAM_DEF(4339, "brcmfmac4339-sdio.bin", "brcmfmac4339-sdio.txt");
> -BRCMF_FW_NVRAM_DEF(43430, "brcmfmac43430-sdio.bin",
> "brcmfmac43430-sdio.txt");
> +BRCMF_FW_NVRAM_DEF(43430A0, "brcmfmac43430a0-sdio.bin",
> "brcmfmac43430a0-sdio.txt");
> +/* Note the names are not postfixed with a1 for backward compatibility */
> +BRCMF_FW_NVRAM_DEF(43430A1, "brcmfmac43430-sdio.bin",
> "brcmfmac43430-sdio.txt");
> BRCMF_FW_NVRAM_DEF(43455, "brcmfmac43455-sdio.bin",
> "brcmfmac43455-sdio.txt");
> BRCMF_FW_NVRAM_DEF(4354, "brcmfmac4354-sdio.bin", "brcmfmac4354-sdio.txt");
> BRCMF_FW_NVRAM_DEF(4356, "brcmfmac4356-sdio.bin", "brcmfmac4356-sdio.txt");
> @@ -630,7 +632,8 @@ static struct brcmf_firmware_mapping brcmf_sdio_fwnames[]
> = {
> BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4335_CHIP_ID, 0x, 4335),
> BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43362_CHIP_ID, 0xFFFE, 43362),
> BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4339_CHIP_ID, 0x, 4339),
> - BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43430_CHIP_ID, 0x, 43430),
> + BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43430_CHIP_ID, 0x0001, 43430A0),
> + BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43430_CHIP_ID, 0xFFFE, 43430A1),
> BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4345_CHIP_ID, 0xFFC0, 43455),
> BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4354_CHIP_ID, 0x, 4354),
> BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4356_CHIP_ID, 0x, 4356)
Unfortunately, there is no "brcmfmac43430a0-sdio.bin" in linux-
firmware. Therefore, my custom board fails:
# [ 24.894241] brcmfmac mmc0:0001:1: Direct firmware load for
brcm/brcmfmac43430a0-sdio.bin failed with error -2
[ 25.914322] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (100):
clkctl 0x50
[ 26.934186] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (100):
clkctl 0x50
Can someone provide the firmware file, please?
[PATCH v2] rt2800: fix TX_PIN_CFG setting for non MT7620 chips
Since commit 41977e86c984 ("rt2x00: add support for MT7620") we do not
initialize TX_PIN_CFG setting. This cause breakage at least on some
RT3573 devices. To fix the problem patch restores previous behaviour
for non MT7620 chips.
Fixes: 41977e86c984 ("rt2x00: add support for MT7620")
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1480829
Reported-and-tested-by: Jussi Eloranta
Cc: Daniel Golle
Signed-off-by: Stanislaw Gruszka
---
v1 -> v2: patch for updated linux version
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index 0b75def39c6c..d2c289446c00 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -3702,7 +3702,10 @@ static void rt2800_config_channel(struct rt2x00_dev
*rt2x00dev,
if (rt2x00_rt(rt2x00dev, RT3572))
rt2800_rfcsr_write(rt2x00dev, 8, 0);
- tx_pin = rt2800_register_read(rt2x00dev, TX_PIN_CFG);
+ if (rt2x00_rt(rt2x00dev, RT6352))
+ tx_pin = rt2800_register_read(rt2x00dev, TX_PIN_CFG);
+ else
+ tx_pin = 0;
switch (rt2x00dev->default_ant.tx_chain_num) {
case 3:
--
2.7.5
Re: [PATCH 2/2] brcmfmac: Use separate firmware for revision 0 of the brcm43430 chip
Hi, On 25-08-17 16:49, Jörg Krause wrote: Thanks for the files! I've tested with brcmfmac43430a0-sdio.bin.7.10.1.244.ucode940.1020 and brcmfmac is happy: brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Jul 1 2016 18:02:40 version 7.10.1 (A0 Station/P2P feature) FWID 01-bae8afee Where did you got the firmware files from? From various Android x86 images and from: https://android.googlesource.com/platform/hardware/broadcom/wlan/+/master/bcmdhd/firmware/ Regards, Hans
Re: [PATCH] rt2800: fix TX_PIN_CFG setting for non MT7620 chips
On Fri, Aug 25, 2017 at 02:15:08PM +0200, Daniel Golle wrote:
> Hi Stanislaw,
>
> On Fri, Aug 25, 2017 at 01:38:29PM +0200, Stanislaw Gruszka wrote:
> > Since commit 41977e86c984 ("rt2x00: add support for MT7620") we do not
> > initialize TX_PIN_CFG setting. This cause breakage at least on some
> > RT3573 devices. To fix the problem patch restores previous behaviour
> > for non MT7620 chips.
> >
> > Fixes: 41977e86c984 ("rt2x00: add support for MT7620")
> > Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1480829
> > Reported-and-tested-by: Jussi Eloranta
> > Signed-off-by: Stanislaw Gruszka
> > ---
> > drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 5 -
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> > b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> > index d11c7b2..5672aec 100644
> > --- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> > +++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> > @@ -3699,7 +3699,10 @@ static void rt2800_config_channel(struct rt2x00_dev
> > *rt2x00dev,
> > if (rt2x00_rt(rt2x00dev, RT3572))
> > rt2800_rfcsr_write(rt2x00dev, 8, 0);
> >
> > - rt2800_register_read(rt2x00dev, TX_PIN_CFG, &tx_pin);
> > + if (rt2x00_rt(rt2x00dev, RT6352))
> > + rt2800_register_read(rt2x00dev, TX_PIN_CFG, &tx_pin);
>
> should be
>
> tx_pin = rt2800_register_read(rt2x00dev, TX_PIN_CFG);
>
> since the calling convention of rt2800_register_read was changed in
> commit eebd68e782 rt2x00: convert rt2800_register_read return type.
> Probably you based the patch on an outdated tree...?
Yes, is was on 4.12. Will post v2.
Thanks
Stanislaw
[PATCH] rtlwifi: rtl8822be: Add firmware for new driver/device
A driver for the RTL8822BE has been added to staging. This commit supplies
the firmware for it.
Signed-off-by: Larry Finger
---
WHENCE | 9 +
rtlwifi/rtl8822befw.bin | Bin 0 -> 127496 bytes
2 files changed, 9 insertions(+)
create mode 100644 rtlwifi/rtl8822befw.bin
diff --git a/WHENCE b/WHENCE
index 00737d5..e062a35 100644
--- a/WHENCE
+++ b/WHENCE
@@ -2423,6 +2423,15 @@ Licence: Redistributable. See
LICENCE.rtlwifi_firmware.txt for details.
--
+Driver: rtl8822be - Realtek 802.11n WLAN driver for RTL8822BE
+
+Info: Sent to Larry Finger by Realtek engineer Ping-Ke Shih
+File: rtlwifi/rtl8822befw.bin
+
+Licence: Redistributable. See LICENCE.rtlwifi_firmware.txt for details.
+
+--
+
Driver: rtl8192ee - Realtek 802.11n WLAN driver for RTL8192EE
Info: Initial version taken from Realtek version
diff --git a/rtlwifi/rtl8822befw.bin b/rtlwifi/rtl8822befw.bin
new file mode 100644
index
..1fcdbeb2dddf300be548f219065746a90b84fa21
GIT binary patch
literal 127496
zcmd3P3w)F1z5ny((xz=%0u&mQOInH|6oD2UGL@t)P})=~7e!$s>BY3ko3<-u;D$3T
z=yWR%6ep(jETm;}pz1u^{)cUzvr^c`Q9QDXn=9;CP$nd;r1TOuo%w%%&-=bfTIyvx
z=l?nX^7-X`-{k%(05`KXvMa8_y>)ro&eP4>5V_7f5mRTXa&8
zJ`9sQcp>;7`I~Yp^IT3~9<@sNSgi(V09rr-AW``Eh3#@#nt!agmmg#vPWeBWzkY$q
z)5IQQd)c$h&pO%vVO{Jrdy8FUSD7Ff1e35>C=l)uoPtMqMtDg$CA=dr)lAi$D!b|t
z)lt=NRUfP7t2e8kP@hzPtY$1rTc*8R3qI@gNlgC({g3po=vmqi(tecoO4{CO9Z8yG
zmh$#@svsH0a+roKU^&79AxCwy5Mc{c5e5{@Q2!s>;$dFE_h1fyo&=T+U;U<~qVb!`
z(_lNc&0zaifb^Uzr>7^Szq|6Q-&_n(p7FTpUB>^+X#5X6YDYQtiU%GgeL?`NKVfJ1)1aG&%|
zVFYi;Pvv_R;vd|?JbM5K0Y3)326)p38UT~+%ySFiKEU@Pk@Vne!wsw1#v1(f-YImrx_-xQ_`mzwW*V@o1Qpf%CwnD6Em)#
z0a>ZFiAk!I)Cm(c`pHu=64KJAU9U4ty>3SGB;)j%jA?ZAmzkeE-5)hpPH7&*vz>z)6*xV>63K2#3>Wg
zl9Q9Jc_!%f2u@5)n35*NCq`4ozo8ED-+~3VFIX^p+D!bLuxMW9bklVyhS+o3bYuF2
z)R`1(oRGRGGjsav>r)M>`bG0*U-PD5OinI+MerN~eBs{&&-eaa@VtcQjd*Ic43udj
z{1?WN07y(oi11%6i{PC?D2$#FIiA&5KUnGBQc+>Aw>NAle{f5~165m=F3rs?2k)i0
zSjgMW&>z4>z-2%`U=Z*jV9qY)X`RYE&j6I?&*X3Ac~<^bo*&BJ^qgg6p4osK0rLS1
z0f(}f=U0HsfRxz?1JnTa0A2>X3HT6j@Sk8ufOi1G_kaiRO@9oYiF>E;UE{z{5Oy4}
z@LytZ2i{8nO@KcDE&^`+A@h6%K+pdGeETP`Wx&gT6M(aTi9bbs0E+PD3_>Ko*2I>+Ac_)AiPztygPy=}A*Ua-A;1R$fz#hO+z|#PgO0A;56adtlX+z92
z0gwsE1FQgCnJ##i&k#J%0ImQw%!HlIg)IR-1Z3VMcvb;Ef+PPc{#rDZ$MypD0}cS%
z06svaPGRG@dHJrAd{?J^)RT2-TNqknTgk+kjab
z#A_Jph^G$EY&<=H(^P-Gz_#NLeX$R8^~oRT%7hP)hj84>R}v3RhFL>irE7CDWD+{paQ7b2S`7m96bIJ0Frzh-(_Z&Sg+Esw@d>2wb`S_
zyNcfb>%U$}2EGTtF97I&y>-Vun&}S^zn0HJUA2KLe@g%`9=4om@SX_J0g?d802Z3S
zSZFzlp_eXVLWq4d0ZxGaganqx|CaW8xK4F3wVoA2ZmR(T$`HU?6+n%5HJ-B(z6bz3
zswH@8w23-&aoXQl9{Ff_
zqzviq2CM~`00QDv05w1hNB|@Pm;w0!YCsY|1JDBW02M$0qyiEEFhSOMZzEf^Z569u
zQO`0~WT5O&r2byKZ=-jX0Dex0eDrbT$=wFsqmTN?Z$IAo~Q6Uh35`Dci?#=()<|kuYkpX+hO}=Jf8qf-vJ2F8x`Ob%J~m~53m$v
zECSpHSO&Nqa0lQ{z;b{YkPj#X6aiKPiUB2n?Z6F&YS-ae4cHHSO8|=i*#HwgL4yg9
z1DFd~0$2oCinyhCz66pv0!KCERRe&IEU(|5x1QX2#`ZjTlf3PC;+sq;kDXA%
z|EkCbPiF#ucENx=f{MSJgt
zCm<2F@DQFm0YfN19r>pMG626r89J0Vf$ELC2LO>sSHvtZPb33A;{fw~9c69>2#8BZ
z{+$2=Kyt^CpZ_cJMj}@tRvz|nq%aBe0hZ$X3J;6Cfja)B9`7Fbf<8P!Un0Uj*n#p<
z{g00z>@W{kd5lZgF&%&b1b_-)0L;A@SyhkpjQ|tAmq5Qx^0FgWSO)wQKnKtO;Agtf
zL;~~x0ifzi;NhCCME=xuEk=2{fIPq=fN+-d%tv0J{N?05*b`WdPW|@n3-NhkydW
zLx6_?4S+WQy?}QCmjHc$5a9m+Ou(-OL?S{&i{~VS6^K>#hO&F1r;J%lr8PTB>nf{E
zmQ@9JEZQ-re4{Bpf1UJ(`25d^-?aMfk}usse|MG@-M3}+-34~Bro6%4ShZz!ZA~K|
z+B8&&b@oaVQkoj7wr&#}P32V&)HPJ)n5euRJdJftiK(&1T~)WOF*7qWnN?Pa_6N6A
z)NQM6G~Gezkc<#qlg1REhG(U8TN|tDrF=4ePG_0DvD&f)MQy3AYiy{pS3Za|b1HL8
z6p>F6i$}*Kv$%ZgHv;jN2kbTCs9a-$QJc6tYsb$sCU|rn31LH3W5a0j#)fmgjVcS|
zkIiP;vUX!h?lr;r6nt%J9vq)~Y#FQ8U7N|WW!1X)JPJFSXrPS0thVt%rL47KT3J+3v0Gs8;Gw7v!a@+}gNR&I~b8D$`m!
ze@JoyJu4a-qVENDu@5S@u6Erv;-U1u($3%E;w!2Nhaxuk@>M2|G{;oC%?+Je#T21#M!0Q+Z8R}P9-QLAcDA|@*@*v}7A;%yC7vLMe#iVE7h_OKj$r*N`2}I?
zSJlJ6#=c?8TFkhlSU
z*f-QuIg1MI+!#+KvJx**$|XF@fb@<#*TEM`p@mgzR<5L1t_Z-rmh?yRP4VWv
zws0}qP|ry$!^-v@w;~2`t>{3mhnDHVeR^c2iJnDR6TG3
zU+cCJI;7oDPhV6i9>sXtxNjc6a!h>OH*&8mi$$|CDB`j?+sOo|9I76FU%PJIYF<@h
zV2-3=tHqkq4N|epQG;y62_g&+k_aAk(u2owUtCrvirX5iDuJGr)>QJ`TqdjVYFf{o
z;2IabH}LoJ_4H1jRFePd2JRSgR!UDvo;)uX-b(%(mzB!lVTCdL3O1+}0wtc7a?6nm
zUBlDT59MNO7nw*^)~}}r;cKLqob`2$79Ozfn!G$4TiY-?UqxN*12v8<(iAJ^UhQr)
zZw*^&&`+Fu(=t<8LzQW3RbyjKtz(&~vSzEjT&yyY^EaX0H^K9p%Eh`0S2Fu7Jat#bvxwH;q%PQFLwHUV~oM
zmU8Hw!dE`Tx#s82Yxz1(-k3IHh-9*qt>!wyyOUhAKCA3yrj<14Xsk0y$W26;3F?9t
zltlaA%MWH$RoKyUG?6GtyTNp5R1L;Z4a9wt#OJK%x@{E|Ra>`yGO6))P*7ljg34Y1
z#lUU~xUrC}%tfO{*08#^@d0|mXi(Q2Se!Kax<(foVJU8mV?R}3E46ABIE3YaHoqOQwQ;UgWE1DXbS607@U6!
zwlV(aT0VXnFHBK+K&2G!j?18NEZ{Tv6R-T^h+*8KKh>_b*HkuEe~LbnHjkny&i9PU
z`}gSdC*z3nm3v3-gm@{Yx#io*6Xlrd8*1Ek%vwY})90q|@5cQP$?TKs7B9QMr+VY^
zzoOb+TU#Z5isbI#j%YmDjmi5Nk{h4D*Weh#T{+$~7gK&WeMUR-xp6&EvBi%5$p09=
z&(NXIO_ziRb5hlIG;y_cHCwB$=|{Z~jgHU;YCFSVEG1k}-SHt%6FMLf^?cwVG*?66sf$pjP2ms}`6hH91ks
zbo%5(4b!D0WA_JswQBlB8eRG%y@namCne!GJ8SwRX3EYo>ghK9BNV#~SDIJrQ3ylW+<{|
zT501?P6S^njr4_W5*q9mO3>+&lGON3PBR#_v?ED+CK=MFn`n!Z!Duugp1!k}EW@6r
zWW3E?ayz0Rh?zIv
Re: [PATCH 2/2] brcmfmac: Use separate firmware for revision 0 of the brcm43430 chip
Hi,
On 25-08-17 15:55, Jörg Krause wrote:
Hi,
On Fri, 2017-06-16 at 15:14 +0200, Hans de Goede wrote:
The brcm43430 chip needs different firmware files for chip revision 0
and 1. The file currently in linux-firmware is for revision 1 only.
This commit makes brcmfmac request brcmfmac43430a0-sdio.bin instead
of brcmfmac43430-sdio.bin for revision 0 chips.
Note that the behavior for revision 1 chips is not changed, ideally those
would load brcmfmac43430a1-sdio.bin, but that will break existing setups.
Signed-off-by: Hans de Goede
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index 4ed40c94bda9..5125aeeb5310 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -612,7 +612,9 @@ BRCMF_FW_NVRAM_DEF(43340, "brcmfmac43340-sdio.bin",
"brcmfmac43340-sdio.txt");
BRCMF_FW_NVRAM_DEF(4335, "brcmfmac4335-sdio.bin", "brcmfmac4335-sdio.txt");
BRCMF_FW_NVRAM_DEF(43362, "brcmfmac43362-sdio.bin", "brcmfmac43362-sdio.txt");
BRCMF_FW_NVRAM_DEF(4339, "brcmfmac4339-sdio.bin", "brcmfmac4339-sdio.txt");
-BRCMF_FW_NVRAM_DEF(43430, "brcmfmac43430-sdio.bin", "brcmfmac43430-sdio.txt");
+BRCMF_FW_NVRAM_DEF(43430A0, "brcmfmac43430a0-sdio.bin",
"brcmfmac43430a0-sdio.txt");
+/* Note the names are not postfixed with a1 for backward compatibility */
+BRCMF_FW_NVRAM_DEF(43430A1, "brcmfmac43430-sdio.bin",
"brcmfmac43430-sdio.txt");
BRCMF_FW_NVRAM_DEF(43455, "brcmfmac43455-sdio.bin", "brcmfmac43455-sdio.txt");
BRCMF_FW_NVRAM_DEF(4354, "brcmfmac4354-sdio.bin", "brcmfmac4354-sdio.txt");
BRCMF_FW_NVRAM_DEF(4356, "brcmfmac4356-sdio.bin", "brcmfmac4356-sdio.txt");
@@ -630,7 +632,8 @@ static struct brcmf_firmware_mapping brcmf_sdio_fwnames[] =
{
BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4335_CHIP_ID, 0x, 4335),
BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43362_CHIP_ID, 0xFFFE, 43362),
BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4339_CHIP_ID, 0x, 4339),
- BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43430_CHIP_ID, 0x, 43430),
+ BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43430_CHIP_ID, 0x0001, 43430A0),
+ BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43430_CHIP_ID, 0xFFFE, 43430A1),
BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4345_CHIP_ID, 0xFFC0, 43455),
BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4354_CHIP_ID, 0x, 4354),
BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4356_CHIP_ID, 0x, 4356)
Unfortunately, there is no "brcmfmac43430a0-sdio.bin" in linux-
firmware. Therefore, my custom board fails:
# [ 24.894241] brcmfmac mmc0:0001:1: Direct firmware load for
brcm/brcmfmac43430a0-sdio.bin failed with error -2
[ 25.914322] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (100):
clkctl 0x50
[ 26.934186] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (100):
clkctl 0x50
Can someone provide the firmware file, please?
I've put all the versions I've been able to find here:
http://jwrdegoede.danny.cz/brcm-firmware/
Note that the 7.x.y.z version does not seem to have any useful meaning,
higher is not necessarily newer :|
[hans@shalem brcm-firmware]$ for i in brcmfmac43430a0-sdio.bin*; do echo $i &&
strings $i | tail -n 1; done
brcmfmac43430a0-sdio.bin.7.10.1.244.ucode940.1020
43430a0-roml/sdio-g-pool-p2p-pno-pktfilter-keepalive-aoe-mchan-proptxstatus-lpc-wl11u-rcc-fmc-wepso-ccx-okc-fbt-noccxaka-txpwr-ampduhostreorder-clm_43xx_lg-ndoe
Version: 7.10.1.244 CRC: 73c82137 Date: Fri 2016-07-01 18:03:15 KST Ucode Ver:
940.1020 FWID: 01-bae8afee
brcmfmac43430a0-sdio.bin.7.10.226.49.no_ucode_version
43430a0-roml/sdio-g-pool-p2p-pno-pktfilter-keepalive-aoe-mchan-proptxstatus-lpc-wl11u-rcc-fmc-wepso-ccx-okc-fbt-noccxaka-txpwr-ampduhostreorder-clm_43xx_lg
Version: 7.10.226.49 CRC: bf92cb0b Date: Fri 2014-06-06 14:55:15 KST FWID
01-8962686a
brcmfmac43430a0-sdio.bin.7.10.68.5.ucode997.0
43430a0-roml/sdio-g-pool-p2p-pno-pktfilter-keepalive-aoe-mchan-proptxstatus-ampduhostreorder-lpc-wl11u-rcc-fmc-wepso-ccx-okc-anqpo-ltecx-sr-ndoe
Version: 7.10.68.5 CRC: 5168922 Date: Thu 2015-04-30 04:20:43 PDT Ucode Ver:
997.0 FWID: 01-2bde7d77
So date wise brcmfmac43430a0-sdio.bin.7.10.1.244.ucode940.1020 is the newest
and IIRC that one works well for me.
ucode version wise, brcmfmac43430a0-sdio.bin.7.10.68.5.ucode997.0 is newer,
but the .0 in 997.0 makes it feel like an unproven release to me.
Regards,
Hans
pull-request: wireless-drivers 2017-08-25
Hi Dave, here's pull request to net tree for 4.13, more info in the signed tag below. Please let me know if there are any problems. Kalle The following changes since commit e9bf53ab1ee34bb05c104bbfd2b77c844773f8e6: brcmfmac: feature check for multi-scheduled scan fails on bcm4343x devices (2017-08-14 11:09:30 +0300) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git tags/wireless-drivers-for-davem-2017-08-25 for you to fetch changes up to 10a54d8196d11f6cc0db2f71249f93854cb9fe55: iwlwifi: pcie: move rx workqueue initialization to iwl_trans_pcie_alloc() (2017-08-24 16:49:00 +0300) wireless-drivers fixes for 4.13 Only one iwlwifi patch this time. iwlwifi * fix multiple times reported lockdep warning found by new locking annotation introduced in v4.13-rc1 Luca Coelho (1): iwlwifi: pcie: move rx workqueue initialization to iwl_trans_pcie_alloc() drivers/net/wireless/intel/iwlwifi/pcie/internal.h | 2 ++ drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 10 +- drivers/net/wireless/intel/iwlwifi/pcie/trans.c| 9 + 3 files changed, 12 insertions(+), 9 deletions(-)
Re: [PATCH] rt2800: fix TX_PIN_CFG setting for non MT7620 chips
Hi Stanislaw,
On Fri, Aug 25, 2017 at 01:38:29PM +0200, Stanislaw Gruszka wrote:
> Since commit 41977e86c984 ("rt2x00: add support for MT7620") we do not
> initialize TX_PIN_CFG setting. This cause breakage at least on some
> RT3573 devices. To fix the problem patch restores previous behaviour
> for non MT7620 chips.
>
> Fixes: 41977e86c984 ("rt2x00: add support for MT7620")
> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1480829
> Reported-and-tested-by: Jussi Eloranta
> Signed-off-by: Stanislaw Gruszka
> ---
> drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> index d11c7b2..5672aec 100644
> --- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> +++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> @@ -3699,7 +3699,10 @@ static void rt2800_config_channel(struct rt2x00_dev
> *rt2x00dev,
> if (rt2x00_rt(rt2x00dev, RT3572))
> rt2800_rfcsr_write(rt2x00dev, 8, 0);
>
> - rt2800_register_read(rt2x00dev, TX_PIN_CFG, &tx_pin);
> + if (rt2x00_rt(rt2x00dev, RT6352))
> + rt2800_register_read(rt2x00dev, TX_PIN_CFG, &tx_pin);
should be
tx_pin = rt2800_register_read(rt2x00dev, TX_PIN_CFG);
since the calling convention of rt2800_register_read was changed in
commit eebd68e782 rt2x00: convert rt2800_register_read return type.
Probably you based the patch on an outdated tree...?
> + else
> + tx_pin = 0;
>
> switch (rt2x00dev->default_ant.tx_chain_num) {
> case 3:
> --
> 2.7.5
>
Submit patches for 4.14 NOW
Hi, Linus will likely release 4.13-rc7 on Sunday so we are getting very close for 4.14 merge window. So if there's something you want to have in 4.14 better submit them now or you risk missing the merge window. -- Kalle Valo
[PATCH] rt2800: fix TX_PIN_CFG setting for non MT7620 chips
Since commit 41977e86c984 ("rt2x00: add support for MT7620") we do not
initialize TX_PIN_CFG setting. This cause breakage at least on some
RT3573 devices. To fix the problem patch restores previous behaviour
for non MT7620 chips.
Fixes: 41977e86c984 ("rt2x00: add support for MT7620")
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1480829
Reported-and-tested-by: Jussi Eloranta
Signed-off-by: Stanislaw Gruszka
---
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index d11c7b2..5672aec 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -3699,7 +3699,10 @@ static void rt2800_config_channel(struct rt2x00_dev
*rt2x00dev,
if (rt2x00_rt(rt2x00dev, RT3572))
rt2800_rfcsr_write(rt2x00dev, 8, 0);
- rt2800_register_read(rt2x00dev, TX_PIN_CFG, &tx_pin);
+ if (rt2x00_rt(rt2x00dev, RT6352))
+ rt2800_register_read(rt2x00dev, TX_PIN_CFG, &tx_pin);
+ else
+ tx_pin = 0;
switch (rt2x00dev->default_ant.tx_chain_num) {
case 3:
--
2.7.5
[PATCH 1/2] rsi: missing unlocks on error paths
There is a missing unlock if rsi_find_sta() fails in
rsi_mac80211_ampdu_action() or if we hit the -EINVAL path in
rsi_mac80211_sta_add().
Fixes: 3528608f3a79 ("rsi: handle station connection in AP mode")
Signed-off-by: Dan Carpenter
diff --git a/drivers/net/wireless/rsi/rsi_91x_mac80211.c
b/drivers/net/wireless/rsi/rsi_91x_mac80211.c
index 8b983d03f2da..25331aa16e8e 100644
--- a/drivers/net/wireless/rsi/rsi_91x_mac80211.c
+++ b/drivers/net/wireless/rsi/rsi_91x_mac80211.c
@@ -906,7 +906,8 @@ static int rsi_mac80211_ampdu_action(struct ieee80211_hw
*hw,
rsta = rsi_find_sta(common, sta->addr);
if (!rsta) {
rsi_dbg(ERR_ZONE, "No station mapped\n");
- return 0;
+ status = 0;
+ goto unlock;
}
sta_id = rsta->sta_id;
}
@@ -974,6 +975,7 @@ static int rsi_mac80211_ampdu_action(struct ieee80211_hw
*hw,
break;
}
+unlock:
mutex_unlock(&common->mutex);
return status;
}
@@ -1202,6 +1204,7 @@ static int rsi_mac80211_sta_add(struct ieee80211_hw *hw,
struct rsi_common *common = adapter->priv;
bool sta_exist = false;
struct rsi_sta *rsta;
+ int status = 0;
rsi_dbg(INFO_ZONE, "Station Add: %pM\n", sta->addr);
@@ -1215,8 +1218,8 @@ static int rsi_mac80211_sta_add(struct ieee80211_hw *hw,
/* Check if max stations reached */
if (common->num_stations >= common->max_stations) {
rsi_dbg(ERR_ZONE, "Reject: Max Stations exists\n");
- mutex_unlock(&common->mutex);
- return -EOPNOTSUPP;
+ status = -EOPNOTSUPP;
+ goto unlock;
}
for (cnt = 0; cnt < common->max_stations; cnt++) {
rsta = &common->stations[cnt];
@@ -1241,7 +1244,8 @@ static int rsi_mac80211_sta_add(struct ieee80211_hw *hw,
rsi_dbg(ERR_ZONE,
"%s: Some problem reaching here...\n",
__func__);
- return -EINVAL;
+ status = -EINVAL;
+ goto unlock;
}
rsta = &common->stations[sta_idx];
rsta->sta = sta;
@@ -1289,9 +1293,10 @@ static int rsi_mac80211_sta_add(struct ieee80211_hw *hw,
}
}
+unlock:
mutex_unlock(&common->mutex);
- return 0;
+ return status;
}
/**
[PATCH 2/2] rsi: update some comments
These functions don't return -1 on failure.
Signed-off-by: Dan Carpenter
diff --git a/drivers/net/wireless/rsi/rsi_91x_mac80211.c
b/drivers/net/wireless/rsi/rsi_91x_mac80211.c
index 25331aa16e8e..e78e87e99804 100644
--- a/drivers/net/wireless/rsi/rsi_91x_mac80211.c
+++ b/drivers/net/wireless/rsi/rsi_91x_mac80211.c
@@ -754,7 +754,7 @@ static int rsi_mac80211_conf_tx(struct ieee80211_hw *hw,
* @vif: Pointer to the ieee80211_vif structure.
* @key: Pointer to the ieee80211_key_conf structure.
*
- * Return: status: 0 on success, -1 on failure.
+ * Return: status: 0 on success, negative error codes on failure.
*/
static int rsi_hal_key_config(struct ieee80211_hw *hw,
struct ieee80211_vif *vif,
@@ -1194,7 +1194,7 @@ static void rsi_set_min_rate(struct ieee80211_hw *hw,
* @vif: Pointer to the ieee80211_vif structure.
* @sta: Pointer to the ieee80211_sta structure.
*
- * Return: 0 on success, -1 on failure.
+ * Return: 0 on success, negative error codes on failure.
*/
static int rsi_mac80211_sta_add(struct ieee80211_hw *hw,
struct ieee80211_vif *vif,
@@ -1306,7 +1306,7 @@ static int rsi_mac80211_sta_add(struct ieee80211_hw *hw,
* @vif: Pointer to the ieee80211_vif structure.
* @sta: Pointer to the ieee80211_sta structure.
*
- * Return: 0 on success, -1 on failure.
+ * Return: 0 on success, negative error codes on failure.
*/
static int rsi_mac80211_sta_remove(struct ieee80211_hw *hw,
struct ieee80211_vif *vif,
@@ -1426,7 +1426,7 @@ static int rsi_mac80211_set_antenna(struct ieee80211_hw
*hw,
* @tx_ant: Bitmap for tx antenna
* @rx_ant: Bitmap for rx antenna
*
- * Return: 0 on success, -1 on failure.
+ * Return: 0 on success, negative error codes on failure.
*/
static int rsi_mac80211_get_antenna(struct ieee80211_hw *hw,
u32 *tx_ant, u32 *rx_ant)
@@ -1533,7 +1533,7 @@ static struct ieee80211_ops mac80211_ops = {
* rsi_mac80211_attach() - This function is used to initialize Mac80211 stack.
* @common: Pointer to the driver private structure.
*
- * Return: 0 on success, -1 on failure.
+ * Return: 0 on success, negative error codes on failure.
*/
int rsi_mac80211_attach(struct rsi_common *common)
{
[PATCH 0/2] iwlwifi: updates intended for v4.14 2017-08-25
From: Luca Coelho Hi, A very tiny set of patches for v4.14. :) Nothing is backlogged in our internal tree anymore and this has been a very slow week due to vacations in our team. These are the changes: * Fix a queue hang problem due to 11w behavior * Fix a warning caused by a too long debug print As usual, I'm pushing this to a pending branch, for kbuild bot, and will send a pull-request later. Please review. Cheers, Luca. David Spinadel (1): iwlwifi: mvm: Avoid deffering non bufferable frames Liad Kaufman (1): iwlwifi: fix long debug print drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c | 9 +++-- drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 9 + 2 files changed, 12 insertions(+), 6 deletions(-) -- 2.14.1
[PATCH 2/2] iwlwifi: mvm: Avoid deffering non bufferable frames
From: David Spinadel
Use bcast station for all non bufferable frames on AP and AD-HOC.
The host is no longer aware of STAs PS status because of buffer
station offload, so we can't rely on mac80211 to toggle on
IEEE80211_TX_CTL_NO_PS_BUFFER bit.
A possible issue with buffering such frames, beside the obvious spec
violation, is when a station disconnects while in PS but the AP isn't
aware of that. In such scenarios the AP won't be able to send probe
responses or auth frames so the STA won't be able to reconnect and
the AP will have a queue hang.
Fixes: 3e56eadfb6a1 ("iwlwifi: mvm: implement AP/GO uAPSD support")
Signed-off-by: David Spinadel
Signed-off-by: Luca Coelho
---
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
index d7feb1ab4dc9..15f2d826bb4b 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
@@ -810,10 +810,11 @@ static void iwl_mvm_mac_tx(struct ieee80211_hw *hw,
!test_bit(IWL_MVM_STATUS_ROC_AUX_RUNNING, &mvm->status))
goto drop;
- /* treat non-bufferable MMPDUs as broadcast if sta is sleeping */
- if (unlikely(info->flags & IEEE80211_TX_CTL_NO_PS_BUFFER &&
-ieee80211_is_mgmt(hdr->frame_control) &&
-!ieee80211_is_bufferable_mmpdu(hdr->frame_control)))
+ /* treat non-bufferable MMPDUs on AP interfaces as broadcast */
+ if ((info->control.vif->type == NL80211_IFTYPE_AP ||
+info->control.vif->type == NL80211_IFTYPE_ADHOC) &&
+ ieee80211_is_mgmt(hdr->frame_control) &&
+ !ieee80211_is_bufferable_mmpdu(hdr->frame_control))
sta = NULL;
if (sta) {
--
2.14.1
[PATCH 1/2] iwlwifi: fix long debug print
From: Liad Kaufman
There is a debug print that sometimes reaches over
110 chars, thus generating a warning in those cases.
Split the print into two to prevent these cases.
Fixes: 92b0f7b26b31 ("iwlwifi: split the regulatory rules when the bandwidth
flags require it")
Signed-off-by: Liad Kaufman
Signed-off-by: Luca Coelho
---
drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c
b/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c
index b46796944cf2..3014beef4873 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c
@@ -915,7 +915,7 @@ iwl_parse_nvm_mcc_info(struct device *dev, const struct
iwl_cfg *cfg,
prev_reg_rule_flags = reg_rule_flags;
IWL_DEBUG_DEV(dev, IWL_DL_LAR,
- "Ch. %d [%sGHz] %s%s%s%s%s%s%s%s%s%s%s%s(0x%02x)
reg_flags 0x%x: %s\n",
+ "Ch. %d [%sGHz]
%s%s%s%s%s%s%s%s%s%s%s%s(0x%02x)\n",
center_freq,
band == NL80211_BAND_5GHZ ? "5.2" : "2.4",
CHECK_AND_PRINT_I(VALID),
@@ -930,7 +930,12 @@ iwl_parse_nvm_mcc_info(struct device *dev, const struct
iwl_cfg *cfg,
CHECK_AND_PRINT_I(80MHZ),
CHECK_AND_PRINT_I(160MHZ),
CHECK_AND_PRINT_I(DC_HIGH),
- ch_flags, reg_rule_flags,
+ ch_flags);
+ IWL_DEBUG_DEV(dev, IWL_DL_LAR,
+ "Ch. %d [%sGHz] reg_flags 0x%x: %s\n",
+ center_freq,
+ band == NL80211_BAND_5GHZ ? "5.2" : "2.4",
+ reg_rule_flags,
((ch_flags & NVM_CHANNEL_ACTIVE) &&
!(ch_flags & NVM_CHANNEL_RADAR))
? "Ad-Hoc" : "");
--
2.14.1
[PATCH] mac80211: Complete ampdu work schedule during session tear down
From: Ilan Peer
Commit 7a7c0a6438b8 ("mac80211: fix TX aggregation start/stop callback race")
added a cancellation of the ampdu work after the loop that stopped the
Tx and Rx BA sessions. However, in some cases, e.g., during HW reconfig,
the low level driver might call mac80211 APIs to complete the stopping
of the BA sessions, which would queue the ampdu work to handle the actual
completion. This work needs to be performed as otherwise mac80211 data
structures would not be properly synced.
Fix this by checking if BA session STOP_CB bit is set after the BA session
cancellation and properly clean the session.
Fixes: 7a7c0a6438b8 ("mac80211: fix TX aggregation start/stop callback race")
Signed-off-by: Ilan Peer
Signed-off-by: Luca Coelho
---
net/mac80211/ht.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/net/mac80211/ht.c b/net/mac80211/ht.c
index c92df492e898..105e2802a48a 100644
--- a/net/mac80211/ht.c
+++ b/net/mac80211/ht.c
@@ -300,6 +300,21 @@ void ieee80211_sta_tear_down_BA_sessions(struct sta_info
*sta,
/* stopping might queue the work again - so cancel only afterwards */
cancel_work_sync(&sta->ampdu_mlme.work);
+
+ /* In case the tear down is part of a reconfigure due to HW restart
+* request, it is possible that the low level driver requested to stop
+* the BA session, so handle it to properly clean tid_tx data.
+*/
+ for (i = 0; i < IEEE80211_NUM_TIDS; i++) {
+ struct tid_ampdu_tx *tid_tx =
+ rcu_dereference_protected_tid_tx(sta, i);
+
+ if (!tid_tx)
+ continue;
+
+ if (test_and_clear_bit(HT_AGG_STATE_STOP_CB, &tid_tx->state))
+ ieee80211_stop_tx_ba_cb(sta, i, tid_tx);
+ }
}
void ieee80211_ba_session_work(struct work_struct *work)
--
2.14.1
