* [RFC 05/15] ath9k: Fix RX crypto processing
From: Sujith Manoharan @ 2013-08-12 9:41 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
In-Reply-To: <1376300502-2741-1-git-send-email-sujith@msujith.org>
From: Sujith Manoharan <c_manoha@qca.qualcomm.com>
The keymiss events are valid only in the last descriptor
of a packet. Fix this by making sure that we return
early in case of chained descriptors.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath9k/recv.c | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index f8cc2b3..b04a971 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -785,10 +785,6 @@ static bool ath9k_rx_accept(struct ath_common *common,
!test_bit(rx_stats->rs_keyix, common->ccmp_keymap))
rx_stats->rs_status &= ~ATH9K_RXERR_KEYMISS;
- /* Only use error bits from the last fragment */
- if (rx_stats->rs_more)
- return true;
-
mic_error = is_valid_tkip && !ieee80211_is_ctl(fc) &&
!ieee80211_has_morefrags(fc) &&
!(le16_to_cpu(hdr->seq_ctrl) & IEEE80211_SCTL_FRAG) &&
@@ -959,6 +955,10 @@ static int ath9k_rx_skb_preprocess(struct ath_softc *sc,
return -EINVAL;
}
+ /* Only use status info from the last fragment */
+ if (rx_stats->rs_more)
+ return 0;
+
/*
* everything but the rate is checked here, the rate check is done
* separately to avoid doing two lookups for a rate for each frame.
@@ -966,10 +966,6 @@ static int ath9k_rx_skb_preprocess(struct ath_softc *sc,
if (!ath9k_rx_accept(common, hdr, rx_status, rx_stats, decrypt_error))
return -EINVAL;
- /* Only use status info from the last fragment */
- if (rx_stats->rs_more)
- return 0;
-
if (ath9k_process_rate(common, hw, rx_stats, rx_status))
return -EINVAL;
--
1.8.3.4
^ permalink raw reply related
* [RFC 04/15] ath9k: Discard invalid frames early
From: Sujith Manoharan @ 2013-08-12 9:41 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
In-Reply-To: <1376300502-2741-1-git-send-email-sujith@msujith.org>
From: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Frames with invalid or zero length can be discarded
early, there is no need to check the crypto bits.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath9k/recv.c | 38 ++++++++++++++++++++---------------
1 file changed, 22 insertions(+), 16 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index 83b3fc5..f8cc2b3 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -764,7 +764,6 @@ static bool ath9k_rx_accept(struct ath_common *common,
bool is_mc, is_valid_tkip, strip_mic, mic_error;
struct ath_hw *ah = common->ah;
__le16 fc;
- u8 rx_status_len = ah->caps.rx_status_len;
fc = hdr->frame_control;
@@ -786,21 +785,6 @@ static bool ath9k_rx_accept(struct ath_common *common,
!test_bit(rx_stats->rs_keyix, common->ccmp_keymap))
rx_stats->rs_status &= ~ATH9K_RXERR_KEYMISS;
- if (!rx_stats->rs_datalen) {
- RX_STAT_INC(rx_len_err);
- return false;
- }
-
- /*
- * rs_status follows rs_datalen so if rs_datalen is too large
- * we can take a hint that hardware corrupted it, so ignore
- * those frames.
- */
- if (rx_stats->rs_datalen > (common->rx_bufsize - rx_status_len)) {
- RX_STAT_INC(rx_len_err);
- return false;
- }
-
/* Only use error bits from the last fragment */
if (rx_stats->rs_more)
return true;
@@ -949,11 +933,33 @@ static int ath9k_rx_skb_preprocess(struct ath_softc *sc,
struct ath_common *common = ath9k_hw_common(ah);
bool discard_current = sc->rx.discard_next;
+ /*
+ * Discard corrupt descriptors which are marked in
+ * ath_get_next_rx_buf().
+ */
sc->rx.discard_next = rx_stats->rs_more;
if (discard_current)
return -EINVAL;
/*
+ * Discard zero-length packets.
+ */
+ if (!rx_stats->rs_datalen) {
+ RX_STAT_INC(rx_len_err);
+ return -EINVAL;
+ }
+
+ /*
+ * rs_status follows rs_datalen so if rs_datalen is too large
+ * we can take a hint that hardware corrupted it, so ignore
+ * those frames.
+ */
+ if (rx_stats->rs_datalen > (common->rx_bufsize - ah->caps.rx_status_len)) {
+ RX_STAT_INC(rx_len_err);
+ return -EINVAL;
+ }
+
+ /*
* everything but the rate is checked here, the rate check is done
* separately to avoid doing two lookups for a rate for each frame.
*/
--
1.8.3.4
^ permalink raw reply related
* [RFC 01/15] ath9k: Add MAX_AMSDU to supported HT capabilities
From: Sujith Manoharan @ 2013-08-12 9:41 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
In-Reply-To: <1376300502-2741-1-git-send-email-sujith@msujith.org>
From: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath9k/init.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
index 3b56c2e..6c1875e 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -258,7 +258,8 @@ static void setup_ht_cap(struct ath_softc *sc,
ht_info->cap = IEEE80211_HT_CAP_SUP_WIDTH_20_40 |
IEEE80211_HT_CAP_SM_PS |
IEEE80211_HT_CAP_SGI_40 |
- IEEE80211_HT_CAP_DSSSCCK40;
+ IEEE80211_HT_CAP_DSSSCCK40 |
+ IEEE80211_HT_CAP_MAX_AMSDU;
if (sc->sc_ah->caps.hw_caps & ATH9K_HW_CAP_LDPC)
ht_info->cap |= IEEE80211_HT_CAP_LDPC_CODING;
--
1.8.3.4
^ permalink raw reply related
* [RFC 02/15] ath9k: Use a subroutine to check for "mybeacon"
From: Sujith Manoharan @ 2013-08-12 9:41 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
In-Reply-To: <1376300502-2741-1-git-send-email-sujith@msujith.org>
From: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath9k/recv.c | 36 ++++++++++++++++++++++-------------
1 file changed, 23 insertions(+), 13 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index 2dd851a..0c23053 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -1160,6 +1160,24 @@ static void ath9k_apply_ampdu_details(struct ath_softc *sc,
}
}
+static bool ath9k_is_mybeacon(struct ath_softc *sc, struct sk_buff *skb)
+{
+ struct ath_hw *ah = sc->sc_ah;
+ struct ath_common *common = ath9k_hw_common(ah);
+ struct ieee80211_hdr *hdr;
+
+ hdr = (struct ieee80211_hdr *) (skb->data + ah->caps.rx_status_len);
+
+ if (ieee80211_is_beacon(hdr->frame_control)) {
+ RX_STAT_INC(rx_beacons);
+ if (!is_zero_ether_addr(common->curbssid) &&
+ ether_addr_equal(hdr->addr3, common->curbssid))
+ return true;
+ }
+
+ return false;
+}
+
int ath_rx_tasklet(struct ath_softc *sc, int flush, bool hp)
{
struct ath_buf *bf;
@@ -1175,7 +1193,6 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush, bool hp)
enum ath9k_rx_qtype qtype;
bool edma = !!(ah->caps.hw_caps & ATH9K_HW_CAP_EDMA);
int dma_type;
- u8 rx_status_len = ah->caps.rx_status_len;
u64 tsf = 0;
u32 tsf_lower = 0;
unsigned long flags;
@@ -1216,18 +1233,10 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush, bool hp)
else
hdr_skb = skb;
- hdr = (struct ieee80211_hdr *) (hdr_skb->data + rx_status_len);
- rxs = IEEE80211_SKB_RXCB(hdr_skb);
- if (ieee80211_is_beacon(hdr->frame_control)) {
- RX_STAT_INC(rx_beacons);
- if (!is_zero_ether_addr(common->curbssid) &&
- ether_addr_equal(hdr->addr3, common->curbssid))
- rs.is_mybeacon = true;
- else
- rs.is_mybeacon = false;
- }
- else
- rs.is_mybeacon = false;
+ rs.is_mybeacon = ath9k_is_mybeacon(sc, hdr_skb);
+
+ hdr = (struct ieee80211_hdr *) (hdr_skb->data +
+ ah->caps.rx_status_len);
if (ieee80211_is_data_present(hdr->frame_control) &&
!ieee80211_is_qos_nullfunc(hdr->frame_control))
@@ -1235,6 +1244,7 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush, bool hp)
ath_debug_stat_rx(sc, &rs);
+ rxs = IEEE80211_SKB_RXCB(hdr_skb);
memset(rxs, 0, sizeof(struct ieee80211_rx_status));
rxs->mactime = (tsf & ~0xffffffffULL) | rs.rs_tstamp;
--
1.8.3.4
^ permalink raw reply related
* [RFC 03/15] ath9k: Fix phy error handling for DFS
From: Sujith Manoharan @ 2013-08-12 9:41 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
In-Reply-To: <1376300502-2741-1-git-send-email-sujith@msujith.org>
From: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Since the DFS code appears to process the phy errors
ATH9K_PHYERR_RADAR and ATH9K_PHYERR_FALSE_RADAR_EXT,
check for the correct phyerr status in the main RX
tasklet routine.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath9k/recv.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index 0c23053..83b3fc5 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -1256,10 +1256,9 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush, bool hp)
unlikely(tsf_lower - rs.rs_tstamp > 0x10000000))
rxs->mactime += 0x100000000ULL;
- if (rs.rs_phyerr == ATH9K_PHYERR_RADAR)
+ if (rs.rs_status & ATH9K_RXERR_PHY) {
ath9k_dfs_process_phyerr(sc, hdr, &rs, rxs->mactime);
- if (rs.rs_status & ATH9K_RXERR_PHY) {
if (ath_process_fft(sc, hdr, &rs, rxs->mactime)) {
RX_STAT_INC(rx_spectral);
goto requeue_drop_frag;
--
1.8.3.4
^ permalink raw reply related
* [RFC 00/15] ath9k patches
From: Sujith Manoharan @ 2013-08-12 9:41 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
From: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Various fixes/cleanups for the RX path. Please review !
Sujith Manoharan (15):
ath9k: Add MAX_AMSDU to supported HT capabilities
ath9k: Use a subroutine to check for "mybeacon"
ath9k: Fix phy error handling for DFS
ath9k: Discard invalid frames early
ath9k: Fix RX crypto processing
ath9k: Fix TSF processing
ath9k: Reorder some functions
ath9k: Fix PHY error processing
ath9k: Fix RX debug statistics
ath9k: Fix RX packet counter
ath9k: Fix RX beacon processing
ath9k: Move the RX poll check to preprocess()
ath9k: Handle corrupt descriptors properly
ath9k: Fix error condition for corrupt descriptors
ath9k: Remove unused function argument
drivers/net/wireless/ath/ath9k/init.c | 3 +-
drivers/net/wireless/ath/ath9k/recv.c | 364 ++++++++++++++++++----------------
2 files changed, 200 insertions(+), 167 deletions(-)
--
1.8.3.4
^ permalink raw reply
* Re: 80211s with DFS
From: Volker von Hoesslin @ SKBX Systems @ 2013-08-12 9:27 UTC (permalink / raw)
To: Simon Wunderlich; +Cc: linux-wireless
In-Reply-To: <20130812091158.GA17024@pandem0nium>
> I'm currently working on IBSS, I don't if/who will work on
> 802.11s DFS ...
>
it is possible to speed up this work? maybe pay for it!
^ permalink raw reply
* Re: 80211s with DFS
From: Simon Wunderlich @ 2013-08-12 9:11 UTC (permalink / raw)
To: Volker von Hoesslin @ SKBX Systems; +Cc: linux-wireless
In-Reply-To: <5207FC2A.4040207@skbx.de>
[-- Attachment #1: Type: text/plain, Size: 528 bytes --]
On Sun, Aug 11, 2013 at 11:03:38PM +0200, Volker von Hoesslin @ SKBX Systems wrote:
> i think this error is from the "netlink lib(libnl genl)"...
>
> if i use a channel without DFS, it works fine (in germany channel
> like 36-48)... so how it is possible to use mesh (80211s) with DFS ?
mac80211 does not support DFS in mesh mode so far, the only DFS
support implemented is AP mode (and only with ath9k compatible chips).
I'm currently working on IBSS, I don't if/who will work on
802.11s DFS ...
Cheers,
Simon
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH v2 3.11] genetlink: fix family dump race
From: Johannes Berg @ 2013-08-12 8:54 UTC (permalink / raw)
To: David Miller
Cc: linux-wireless, netdev, tgraf, andrei.otcheretianski, ilan.peer,
stable, Pravin B Shelar
In-Reply-To: <20130811.212942.413012801159758438.davem@davemloft.net>
On Sun, 2013-08-11 at 21:29 -0700, David Miller wrote:
> > BUG: unable to handle kernel paging request at f8467360
> > IP: [<c14c56bb>] ctrl_dumpfamily+0x6b/0xe0
> > EIP: 0060:[<c14c56bb>] EFLAGS: 00210297 CPU: 2
> > EIP is at ctrl_dumpfamily+0x6b/0xe0
> > EAX: f8467378 EBX: f8467340 ECX: 00000000 EDX: ec1610c4
> > ESI: 00000001 EDI: c2077cc0 EBP: c46c3c00 ESP: c46c3bd4
> > DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
> > CR0: 80050033 CR2: f8467360 CR3: 26e54000 CR4: 001407d0
> > DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
> > DR6: ffff0ff0 DR7: 00000400
> > Process wpa_supplicant (pid: 20081, ti=c46c2000 task=c44640b0 task.ti=c46c2000)
> > Call Trace:
> > [<c14c20bc>] netlink_dump+0x5c/0x200
> > [<c14c3450>] __netlink_dump_start+0x140/0x160
> > [<c14c5172>] genl_rcv_msg+0x102/0x270
> > [<c14c4b5e>] netlink_rcv_skb+0x8e/0xb0
> > [<c14c505c>] genl_rcv+0x1c/0x30
> > [<c14c456b>] netlink_unicast+0x17b/0x1c0
> > [<c14c47d4>] netlink_sendmsg+0x224/0x370
> > [<c1485adf>] sock_sendmsg+0xff/0x120
>
> I completely agree with your analysis that we need locking here, but
> the crash OOPS backtrace doesn't make any sense to me.
>
> The bug should trigger when we enter the dump continuation path, which
> would look like:
>
> ctrl_dumpfamily()
> netlink_dump()
> netlink_recvmsg()
> ...
>
> Since this is the only way we get into ctrl_dumpfamily() without
> holding genl_lock().
>
> But in your trace we're going through genl_rcv() which means this is
> the first call of the dump, and genl_rcv() takes the necessary locks.
Huh, yes, I only looked at the crash info as far as I needed to see that
it was crashing at accessing "rt->netnsok" with a not totally invalid
pointer "rt" (it's in EBX) and then went from the code ...
Ok, I see what's going on here. The bug was reported to me against an
old kernel (3.4.47!) and that actually did an unlock in genl_rcv_msg()
before calling netlink_dump_start():
if (nlh->nlmsg_flags & NLM_F_DUMP) {
if (ops->dumpit == NULL)
return -EOPNOTSUPP;
genl_unlock();
{
struct netlink_dump_control c = {
.dump = ops->dumpit,
.done = ops->done,
};
err = netlink_dump_start(net->genl_sock, skb,
nlh, &c);
}
genl_lock();
return err;
}
That was changed in Pravin's commit
def3117493eafd9dfa1f809d861e0031b2cc8a07
"genl: Allow concurrent genl callbacks." very recently - I'm not sure if
that was intentional, it's not described in the commit log.
I think for the current code the fix would still be correct, I can
change the commit message if you like. For backporting, we'll have to
check which tree has Pravin's change and which doesn't and change this
accordingly, I suppose.
johannes
^ permalink raw reply
* RE: [PATCH] iwlwifi: mvm: make debugfs write() operations write up to count bytes
From: Berg, Johannes @ 2013-08-12 8:19 UTC (permalink / raw)
To: Djalal Harouni, Grumbach, Emmanuel, Intel Linux Wireless,
John W. Linville, linux-kernel@vger.kernel.org,
linux-wireless@vger.kernel.org
In-Reply-To: <1376267972-5636-1-git-send-email-tixxdz@opendz.org>
> Some debugfs write() operations of the MVM Firmware will ignore the count
> argument, and will copy more bytes than what was specified.
> Fix this by getting the right count of bytes.
>
> This will also honor restrictions put on the number of bytes to write.
That makes some sense.
> To be consitant this patch also switches the initializer from 'char buf[x] = {}' to
> the explicit memset() as it is done in other places of the same file.
I'd rather this (a) be done in a separate patch, and (b) the other way around, switch everything to C99.
> Cc: stable@vger.kernel.org
That doesn't really make sense for the debugfs interface.
> + memset(buf, 0, sizeof(buf));
> + if (count > sizeof(buf) - 1)
> + count = sizeof(buf) - 1;
Why -1? And why not use min()/min_t()?
johannes
--
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052
^ permalink raw reply
* Re: [patch] iwlwifi: pcie: returning positive instead of negative
From: Johannes Berg @ 2013-08-12 8:11 UTC (permalink / raw)
To: Dan Carpenter
Cc: Emmanuel Grumbach, Intel Linux Wireless, John W. Linville,
linux-wireless, kernel-janitors
In-Reply-To: <20130810230321.GA19051@elgon.mountain>
On Sun, 2013-08-11 at 02:03 +0300, Dan Carpenter wrote:
> There is a missing '-' character here so we return positive 'ENOMEM'
> instead of negative. The caller doesn't care. All non-zero returns
> are translated to '-ENOMEM' in iwl_pcie_nic_init().
>
> This is just a cleanup.
Applied, thanks.
johannes
^ permalink raw reply
* Re: FUSB200 xhci issue
From: Oleksij Rempel @ 2013-08-12 7:58 UTC (permalink / raw)
To: Alan Stern
Cc: Christian Lamparter, Sarah Sharp, Seth Forshee, ath9k_htc_fw,
USB list, linux-wireless, Sujith Manoharan
In-Reply-To: <Pine.LNX.4.44L0.1308100755250.31571-100000@netrider.rowland.org>
Am 10.08.2013 13:57, schrieb Alan Stern:
> On Sat, 10 Aug 2013, Oleksij Rempel wrote:
>
>> usb reset do not affect behaviour of firmware. At least after i remove
>> all attempts to reboot FW from driver.
>> If adapter will got reset signal, FW will be notified about it. Then FW
>> will remove reset flag and will just continue to work. After usb reset,
>> lsusb show correct, update information - EP3 and EP4 was updated from
>> INT to BULK.
>>
>> I assume, no i need to add to the driver some kind of firmware check.
>> What is the proper way to do it?
>
> The simplest way is to put a new value for the device descriptor's
> bcdDevice value in the firmware. Then all you have to do is check that
> value.
Since adding fw check will need fw version update. I would like to do
quick fix for current kernel and firmware version.
I will revert EP3 and EP4 from bulk back to interrupt. But, before
sending patch to the list i would like to know, how to reproduce the bug
which was fixed by converting this endpoints from interrupt to bulk.
--
Regards,
Oleksij
--
Regards,
Oleksij
^ permalink raw reply
* [PATCH 2/2] NFC: pn533: Staticize local symbols
From: Jingoo Han @ 2013-08-12 6:40 UTC (permalink / raw)
To: 'Lauro Ramos Venancio'
Cc: 'Aloisio Almeida Jr', 'Samuel Ortiz',
linux-wireless, linux-nfc, 'Waldemar Rymarkiewicz',
Thierry Escande, 'Olivier Guiter', Jingoo Han
These local symbols are used only in this file.
Fix the following sparse warnings:
drivers/nfc/pn533.c:2576:5: warning: symbol 'pn533_dev_up' was not declared. Should it be static?
drivers/nfc/pn533.c:2581:5: warning: symbol 'pn533_dev_down' was not declared. Should it be static?
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/nfc/pn533.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/nfc/pn533.c b/drivers/nfc/pn533.c
index daf92ac..1746225 100644
--- a/drivers/nfc/pn533.c
+++ b/drivers/nfc/pn533.c
@@ -2573,12 +2573,12 @@ static int pn533_rf_field(struct nfc_dev *nfc_dev, u8 rf)
return rc;
}
-int pn533_dev_up(struct nfc_dev *nfc_dev)
+static int pn533_dev_up(struct nfc_dev *nfc_dev)
{
return pn533_rf_field(nfc_dev, 1);
}
-int pn533_dev_down(struct nfc_dev *nfc_dev)
+static int pn533_dev_down(struct nfc_dev *nfc_dev)
{
return pn533_rf_field(nfc_dev, 0);
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/2] NFC: nfcsim: Staticize local symbols
From: Jingoo Han @ 2013-08-12 6:37 UTC (permalink / raw)
To: 'Lauro Ramos Venancio'
Cc: 'Aloisio Almeida Jr', Samuel Ortiz, linux-wireless,
linux-nfc, 'Thierry Escande', Jingoo Han
These local symbols are used only in this file.
Fix the following sparse warnings:
drivers/nfc/nfcsim.c:63:25: warning: symbol 'wq' was not declared. Should it be static?
drivers/nfc/nfcsim.c:484:12: warning: symbol 'nfcsim_init' was not declared. Should it be static?
drivers/nfc/nfcsim.c:525:13: warning: symbol 'nfcsim_exit' was not declared. Should it be static?
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/nfc/nfcsim.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/nfc/nfcsim.c b/drivers/nfc/nfcsim.c
index c5c30fb..9a53f13 100644
--- a/drivers/nfc/nfcsim.c
+++ b/drivers/nfc/nfcsim.c
@@ -60,7 +60,7 @@ struct nfcsim {
static struct nfcsim *dev0;
static struct nfcsim *dev1;
-struct workqueue_struct *wq;
+static struct workqueue_struct *wq;
static void nfcsim_cleanup_dev(struct nfcsim *dev, u8 shutdown)
{
@@ -481,7 +481,7 @@ static void nfcsim_free_device(struct nfcsim *dev)
kfree(dev);
}
-int __init nfcsim_init(void)
+static int __init nfcsim_init(void)
{
int rc;
@@ -522,7 +522,7 @@ exit:
return rc;
}
-void __exit nfcsim_exit(void)
+static void __exit nfcsim_exit(void)
{
nfcsim_cleanup_dev(dev0, 1);
nfcsim_cleanup_dev(dev1, 1);
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH v2 3.11] genetlink: fix family dump race
From: David Miller @ 2013-08-12 4:29 UTC (permalink / raw)
To: johannes
Cc: linux-wireless, netdev, tgraf, andrei.otcheretianski, ilan.peer,
johannes.berg
In-Reply-To: <1375879163-2116-1-git-send-email-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Wed, 7 Aug 2013 14:39:23 +0200
> When dumping generic netlink families, only the first dump call
> is locked with genl_lock(), which protects the list of families,
> and thus subsequent calls can access the data without locking,
> racing against family addition/removal. This can cause a crash.
> Fix it - the locking needs to be conditional because the first
> time around it's already locked.
>
> BUG: unable to handle kernel paging request at f8467360
> IP: [<c14c56bb>] ctrl_dumpfamily+0x6b/0xe0
> EIP: 0060:[<c14c56bb>] EFLAGS: 00210297 CPU: 2
> EIP is at ctrl_dumpfamily+0x6b/0xe0
> EAX: f8467378 EBX: f8467340 ECX: 00000000 EDX: ec1610c4
> ESI: 00000001 EDI: c2077cc0 EBP: c46c3c00 ESP: c46c3bd4
> DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
> CR0: 80050033 CR2: f8467360 CR3: 26e54000 CR4: 001407d0
> DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
> DR6: ffff0ff0 DR7: 00000400
> Process wpa_supplicant (pid: 20081, ti=c46c2000 task=c44640b0 task.ti=c46c2000)
> Call Trace:
> [<c14c20bc>] netlink_dump+0x5c/0x200
> [<c14c3450>] __netlink_dump_start+0x140/0x160
> [<c14c5172>] genl_rcv_msg+0x102/0x270
> [<c14c4b5e>] netlink_rcv_skb+0x8e/0xb0
> [<c14c505c>] genl_rcv+0x1c/0x30
> [<c14c456b>] netlink_unicast+0x17b/0x1c0
> [<c14c47d4>] netlink_sendmsg+0x224/0x370
> [<c1485adf>] sock_sendmsg+0xff/0x120
I completely agree with your analysis that we need locking here, but
the crash OOPS backtrace doesn't make any sense to me.
The bug should trigger when we enter the dump continuation path, which
would look like:
ctrl_dumpfamily()
netlink_dump()
netlink_recvmsg()
...
Since this is the only way we get into ctrl_dumpfamily() without
holding genl_lock().
But in your trace we're going through genl_rcv() which means this is
the first call of the dump, and genl_rcv() takes the necessary locks.
^ permalink raw reply
* 80211s with DFS
From: Volker von Hoesslin @ SKBX Systems @ 2013-08-11 21:03 UTC (permalink / raw)
To: linux-wireless
hi mailinglist!
i have a real big problem! i'm trying to implement a wireless-mesh
(80211s) with openWRT (current trunk) over 11a (5GHz) with "authSAE" for
outdoor. all works fine, mesh is runnning and all fine. but now, i'm at
germany and for the outdoor use, i have to use the channel 100-140 with
DFS & TPC. so the mesh implementation dont work in this channel? with
this error:
authSAE config:
#######################################################
authsae:
{
sae:
{
debug = 480;
password = "foobar";
group = [19, 26, 21, 25, 20];
blacklist = 5;
thresh = 5;
lifetime = 3600;
};
meshd:
{
meshid = "foobar";
interface = "mesh0";
band = "11a";
channel = 104;
htmode = "ht20";
mcast-rate = 6;
debug = 1;
};
};
#######################################################
starting mesh with "authSAE":
#######################################################
# meshd-nl80211 -c /etc/authsae.cfg
----------
nlcfg rates hexdump
00 3c 00 5a 00 78 00 b4 00 f0 01 68 01 e0 02 1c
----------
----------
mgtk: hexdump
ce 5a b3 fc 8b 76 db 62 11 c9 58 33 fa 0c 26 88
----------
----------
Fixed Information Elements in this STA hexdump
01 08 8c 12 98 24 b0 48 60 6c
----------
meshd: Starting mesh with mesh id = foobar
----------
basic rates: hexdump
8c 98 b0
----------
joining mesh foobar on freq 3443784, mode 0
nlerror, cmd 68, seq 1376254403: Invalid argument
#######################################################
and this is without "authSAE":
#######################################################
# iw mesh0 set channel 104
# iw mesh0 mesh join foobar
command failed: Invalid argument (-22)
#######################################################
but this is working with a non-DFS channel 44:
#######################################################
# iw mesh0 set channel 44
# iw mesh0 mesh join hackewrt
[21044.240000] IPv6: ADDRCONF(NETDEV_CHANGE): mesh0: link becomes ready
[21044.240000] mesh-br: port 1(vlan11) entered forwarding state
[21044.250000] mesh-br: port 1(vlan11) entered forwarding state
[21044.260000] IPv6: ADDRCONF(NETDEV_CHANGE): vlan11: link becomes ready
[21044.260000] coova-br: port 1(vlan12) entered forwarding state
[21044.270000] coova-br: port 1(vlan12) entered forwarding state
[21044.280000] IPv6: ADDRCONF(NETDEV_CHANGE): vlan12: link becomes ready
root@6470028F55A2:~#
#######################################################
i think this error is from the "netlink lib(libnl genl)"...
if i use a channel without DFS, it works fine (in germany channel like
36-48)... so how it is possible to use mesh (80211s) with DFS ?
big thx for answer,
volker...
^ permalink raw reply
* Re: [RFC] mac80211: add support for split-MAC implementations
From: Johan Almbladh @ 2013-08-11 20:19 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <CAJWpbEg74C7DYbDkWCpNJRte7X7+40UHgNAL7uWLFHJ64CApKw@mail.gmail.com>
I would prefer my original solution that puts the decryption handler
after the sta_process handler. The code is cleaner since we avoid the
extra flag and the coupling between decrypt and sta_process. My
conclusion is that the change is correct, see below.
ieee80211_rx_h_check_more_data, ieee80211_rx_h_uapsd_and_pspoll:
The MOREDATA and PM bits are not protected by the encryption MIC. It
should be valid to process those bits regardless of the decryption
outcome.
ieee80211_rx_h_sta_process:
The updating of last_rx for an IBSS STA is conditional on the STA
being AUTHORIZED. That state is the same regardless of whether the
updating is done before or after decryption.
The main argument that the MOREDATA and PM bits are not protected by
the encryption and are therefore independent. You can always send a
spoofed NULLFUNC frame to an RSN AP or STA and have the PM and
MOREDATA bits processed accordingly. My change allows data frames that
could not be decrypted to be processed similar to NULLFUNC frames.
I have run mac80211 in STA and AP mode with this change for quite some
time now without any problems. I will run it in IBSS mode also as you
suggest.
Provided that my IBSS tests pass, should I send you a final patch that
changes the RX handler order and their locations in the file?
Johan
On Sat, Aug 10, 2013 at 1:31 PM, Johan Almbladh <ja@anyfi.net> wrote:
> On Fri, Aug 9, 2013 at 3:07 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
>>
>> On Thu, 2013-08-08 at 15:21 +0200, Johan Almbladh wrote:
>> > This patch enables power save processing for encrypted frames even if the
>> > encryption key is not set. This is a requirement when implementing split-MAC
>> > systems like Anyfi.net [1] and CAPWAP [2] on mac80211 using monitor frame
>> > injection and reception.
>>
>> I have no idea what these are, nor do I actually want to care much...
>
> Anyfi.net is a dynamic split-mac system where the security part of the
> 802.11 stack is located in your home router and the realtime part is
> handled by any router or AP that happens to be near your current
> location. The two parts are connected dynamically via a UDP tunnel
> that carries raw encrypted 802.11 frames, forming a complete 802.11
> stack that provides your home Wi-Fi wherever you are. In a community
> Wi-Fi deployment, the users get secure Wi-Fi access with automatic
> sign-on via their home Wi-Fi network which is simply available
> everywhere.
>
> Should you find the concept interesting there is quite extensive
> technical documentation at http://anyfi.net/documentation#architecture
> :-)
>
>
>> You presumably use Felix's active monitor mode?
>
> I use a monitor socket in a userspace daemon. The daemon receives
> encrypted 802.11 frames with radiotap encapsulation on this monitor
> socket. It also injects encrypted 802.11 frames with radiotap
> encapsulation by transmitting them on the same socket. I believe this
> is the way hostapd used to handle transmission of management and EAPOL
> frames before they switched to nl80211.
>
>
>> > The mac80211 RX handlers are reordered slightly so
>> > that the power save handler is invoked before the decryption handler.
>> >
>> > The patch is minimal in the sense that it provides the required functionality
>> > with a minimal change, but I am open to suggestions if this change is too
>> > intrusive. Please let me know what you think.
>>
>> I think you should ask yourself if this makes sense in the normal wifi
>> context... :-)
>
> You are right about that, but I think this little feature can be added
> without affecting the normal operation :-) To be honest, mac80211 has
> all the interfaces required for any split-mac implementation, thanks
> to the mac80211/hostapd partitioning. The *only* thing missing is the
> ability to handle AP power save processing without handling the
> encryption...
>
>
>> It actually seems like it *does* make sense, so it should have an
>> appropriate description for that, but I'm a bit worried about IBSS in
>> sta_process.
>
> The patch enables power save processing even if there is no unicast
> key set, but *also* if key is set but the decryption failed. This is
> what I meant with "intrusive". The IBSS updating in sta_process will
> also run in this case, but the STA is still required to be authorized.
>
> It's possible to narrow it down to only affect the case where no
> encryption key is set:
>
> * Keep the RX handlers in their original order
> * Don't drop frames where rx->key is NULL in ieee80211_rx_h_decrypt.
> Instead, mark the frame with a flag
> * Drop any marked frames at the end of ieee80211_rx_h_sta_process with
> RX_DROP_MONITOR
>
> I can prepare a new patch if you prefer this solution.
>
>> Also I've tried to keep the code in the file sequential, so this patch
>> should be moving ieee80211_rx_h_decrypt() itself as well.
>
> I'll make sure to put them in the right order.
>
> Johan
^ permalink raw reply
* brcsmac kernel panic
From: Daniel Wagner @ 2013-08-11 16:21 UTC (permalink / raw)
To: linux-wireless; +Cc: linux-kernel, Arend van Spriel
Hi,
I just updated my laptop (MacBook Air 2012) from 3.11-rc3+ to 3.11-rc4+
and since then brcsmac crashes short after enabling it. Unfortunately, I
did also change some config flags in the area of cpufreq (enabling
p-state driver) so the configuration is not exactly the same. Before I
try to figure out what I have changed, I am posting the picture of the
crash. Maybe it is something obvious.
v3.11-rc4-197-gd92581f
http://www.monom.org/misc/brcmsmac/v3.11-rc4.config
http://www.monom.org/misc/brcmsmac/IMAG0064.jpg
hth,
daniel
^ permalink raw reply
* Re: [PATCH 12/12] brcmsmac: support 4313iPA
From: Jonas Gorski @ 2013-08-11 12:48 UTC (permalink / raw)
To: Arend van Spriel; +Cc: John W. Linville, linux-wireless, Piotr Haber
In-Reply-To: <1376130450-29746-13-git-send-email-arend@broadcom.com>
Hi,
On Sat, Aug 10, 2013 at 12:27 PM, Arend van Spriel <arend@broadcom.com> wrote:
> From: Piotr Haber <phaber@broadcom.com>
>
> Add support for 4313 iPA variant.
> It is a variant of already supported 4313 ePA,
> so this patch adds the required PHY changes to
> support it properly including an updated switch
> control table for BT-combo card variants.
Okay, I'll bite. Since this patch was already reverted once, it
warrants some additional scrutiny.
First of all, the patch is quite large, and I wonder if it couldn't be
split into smaller patches, especially as it looks like there are
additional fixes/changes merged in it.
Detailed comments below ...
> Tested-by: Maximilian Engelhardt <maxi@daemonizer.de>
> Tested-by: David Costa <david@zarel.net>
> Reviewed-by: Arend Van Spriel <arend@broadcom.com>
> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
> Signed-off-by: Piotr Haber <phaber@broadcom.com>
> Signed-off-by: Arend van Spriel <arend@broadcom.com>
> ---
This is obviously a V2 (or V(n+1) where n was the reverted version),
so there should be something describing the changes to the reverted
version. Why should we trust it now to not break things again? (Yes, I
see those Tested-bys ;-)
> .../net/wireless/brcm80211/brcmsmac/phy/phy_lcn.c | 399 +++++++++++++--------
> .../wireless/brcm80211/brcmsmac/phy/phytbl_lcn.c | 289 +++++++++------
> .../wireless/brcm80211/brcmsmac/phy/phytbl_lcn.h | 1 +
> 3 files changed, 436 insertions(+), 253 deletions(-)
>
> diff --git a/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_lcn.c b/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_lcn.c
> index 3d6b16c..b8ddaad 100644
> --- a/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_lcn.c
> +++ b/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_lcn.c
> @@ -1137,8 +1137,9 @@ wlc_lcnphy_set_rx_gain_by_distribution(struct brcms_phy *pi,
> gain0_15 = ((biq1 & 0xf) << 12) |
> ((tia & 0xf) << 8) |
> ((lna2 & 0x3) << 6) |
> - ((lna2 &
> - 0x3) << 4) | ((lna1 & 0x3) << 2) | ((lna1 & 0x3) << 0);
> + ((lna2 & 0x3) << 4) |
> + ((lna1 & 0x3) << 2) |
> + ((lna1 & 0x3) << 0);
Unrelated style change.
>
> mod_phy_reg(pi, 0x4b6, (0xffff << 0), gain0_15 << 0);
> mod_phy_reg(pi, 0x4b7, (0xf << 0), gain16_19 << 0);
> @@ -1328,6 +1329,43 @@ static u32 wlc_lcnphy_measure_digital_power(struct brcms_phy *pi, u16 nsamples)
> return (iq_est.i_pwr + iq_est.q_pwr) / nsamples;
> }
>
> +static bool wlc_lcnphy_rx_iq_cal_gain(struct brcms_phy *pi, u16 biq1_gain,
> + u16 tia_gain, u16 lna2_gain)
> +{
> + u32 i_thresh_l, q_thresh_l;
> + u32 i_thresh_h, q_thresh_h;
> + struct lcnphy_iq_est iq_est_h, iq_est_l;
> +
> + wlc_lcnphy_set_rx_gain_by_distribution(pi, 0, 0, 0, biq1_gain, tia_gain,
> + lna2_gain, 0);
> +
> + wlc_lcnphy_rx_gain_override_enable(pi, true);
> + wlc_lcnphy_start_tx_tone(pi, 2000, (40 >> 1), 0);
> + udelay(500);
> + write_radio_reg(pi, RADIO_2064_REG112, 0);
> + if (!wlc_lcnphy_rx_iq_est(pi, 1024, 32, &iq_est_l))
> + return false;
> +
> + wlc_lcnphy_start_tx_tone(pi, 2000, 40, 0);
> + udelay(500);
> + write_radio_reg(pi, RADIO_2064_REG112, 0);
> + if (!wlc_lcnphy_rx_iq_est(pi, 1024, 32, &iq_est_h))
> + return false;
> +
> + i_thresh_l = (iq_est_l.i_pwr << 1);
> + i_thresh_h = (iq_est_l.i_pwr << 2) + iq_est_l.i_pwr;
> +
> + q_thresh_l = (iq_est_l.q_pwr << 1);
> + q_thresh_h = (iq_est_l.q_pwr << 2) + iq_est_l.q_pwr;
So X_thresh_l == iq_est_l.X_pwr * 2 and X_thresh_h == iq_est_l.X_pwr *
5? Why not trust the compiler to use optimize it? It would be a bit
more readable.
> + if ((iq_est_h.i_pwr > i_thresh_l) &&
> + (iq_est_h.i_pwr < i_thresh_h) &&
> + (iq_est_h.q_pwr > q_thresh_l) &&
> + (iq_est_h.q_pwr < q_thresh_h))
> + return true;
> +
> + return false;
> +}
> +
> static bool
> wlc_lcnphy_rx_iq_cal(struct brcms_phy *pi,
> const struct lcnphy_rx_iqcomp *iqcomp,
> @@ -1342,8 +1380,8 @@ wlc_lcnphy_rx_iq_cal(struct brcms_phy *pi,
> RFOverrideVal0_old, rfoverride2_old, rfoverride2val_old,
> rfoverride3_old, rfoverride3val_old, rfoverride4_old,
> rfoverride4val_old, afectrlovr_old, afectrlovrval_old;
> - int tia_gain;
> - u32 received_power, rx_pwr_threshold;
> + int tia_gain, lna2_gain, biq1_gain;
> + bool set_gain;
> u16 old_sslpnCalibClkEnCtrl, old_sslpnRxFeClkEnCtrl;
> u16 values_to_save[11];
> s16 *ptr;
> @@ -1368,126 +1406,134 @@ wlc_lcnphy_rx_iq_cal(struct brcms_phy *pi,
> goto cal_done;
> }
>
> - if (module == 1) {
> + WARN_ON(module != 1);
> + tx_pwr_ctrl = wlc_lcnphy_get_tx_pwr_ctrl(pi);
> + wlc_lcnphy_set_tx_pwr_ctrl(pi, LCNPHY_TX_PWR_CTRL_OFF);
>
> - tx_pwr_ctrl = wlc_lcnphy_get_tx_pwr_ctrl(pi);
> - wlc_lcnphy_set_tx_pwr_ctrl(pi, LCNPHY_TX_PWR_CTRL_OFF);
This indentation change makes it a bit harder to review, but luckily
there is git show -b ...
> + for (i = 0; i < 11; i++)
> + values_to_save[i] =
> + read_radio_reg(pi, rxiq_cal_rf_reg[i]);
> + Core1TxControl_old = read_phy_reg(pi, 0x631);
> +
> + or_phy_reg(pi, 0x631, 0x0015);
> +
> + RFOverride0_old = read_phy_reg(pi, 0x44c);
> + RFOverrideVal0_old = read_phy_reg(pi, 0x44d);
> + rfoverride2_old = read_phy_reg(pi, 0x4b0);
> + rfoverride2val_old = read_phy_reg(pi, 0x4b1);
> + rfoverride3_old = read_phy_reg(pi, 0x4f9);
> + rfoverride3val_old = read_phy_reg(pi, 0x4fa);
> + rfoverride4_old = read_phy_reg(pi, 0x938);
> + rfoverride4val_old = read_phy_reg(pi, 0x939);
> + afectrlovr_old = read_phy_reg(pi, 0x43b);
> + afectrlovrval_old = read_phy_reg(pi, 0x43c);
> + old_sslpnCalibClkEnCtrl = read_phy_reg(pi, 0x6da);
> + old_sslpnRxFeClkEnCtrl = read_phy_reg(pi, 0x6db);
>
> - for (i = 0; i < 11; i++)
> - values_to_save[i] =
> - read_radio_reg(pi, rxiq_cal_rf_reg[i]);
> - Core1TxControl_old = read_phy_reg(pi, 0x631);
> -
> - or_phy_reg(pi, 0x631, 0x0015);
> -
> - RFOverride0_old = read_phy_reg(pi, 0x44c);
> - RFOverrideVal0_old = read_phy_reg(pi, 0x44d);
> - rfoverride2_old = read_phy_reg(pi, 0x4b0);
> - rfoverride2val_old = read_phy_reg(pi, 0x4b1);
> - rfoverride3_old = read_phy_reg(pi, 0x4f9);
> - rfoverride3val_old = read_phy_reg(pi, 0x4fa);
> - rfoverride4_old = read_phy_reg(pi, 0x938);
> - rfoverride4val_old = read_phy_reg(pi, 0x939);
> - afectrlovr_old = read_phy_reg(pi, 0x43b);
> - afectrlovrval_old = read_phy_reg(pi, 0x43c);
> - old_sslpnCalibClkEnCtrl = read_phy_reg(pi, 0x6da);
> - old_sslpnRxFeClkEnCtrl = read_phy_reg(pi, 0x6db);
> -
> - tx_gain_override_old = wlc_lcnphy_tx_gain_override_enabled(pi);
> - if (tx_gain_override_old) {
> - wlc_lcnphy_get_tx_gain(pi, &old_gains);
> - tx_gain_index_old = pi_lcn->lcnphy_current_index;
> - }
> + tx_gain_override_old = wlc_lcnphy_tx_gain_override_enabled(pi);
> + if (tx_gain_override_old) {
> + wlc_lcnphy_get_tx_gain(pi, &old_gains);
> + tx_gain_index_old = pi_lcn->lcnphy_current_index;
> + }
>
> - wlc_lcnphy_set_tx_pwr_by_index(pi, tx_gain_idx);
> + wlc_lcnphy_set_tx_pwr_by_index(pi, tx_gain_idx);
>
> - mod_phy_reg(pi, 0x4f9, (0x1 << 0), 1 << 0);
> - mod_phy_reg(pi, 0x4fa, (0x1 << 0), 0 << 0);
> + mod_phy_reg(pi, 0x4f9, (0x1 << 0), 1 << 0);
> + mod_phy_reg(pi, 0x4fa, (0x1 << 0), 0 << 0);
>
> - mod_phy_reg(pi, 0x43b, (0x1 << 1), 1 << 1);
> - mod_phy_reg(pi, 0x43c, (0x1 << 1), 0 << 1);
> + mod_phy_reg(pi, 0x43b, (0x1 << 1), 1 << 1);
> + mod_phy_reg(pi, 0x43c, (0x1 << 1), 0 << 1);
>
> - write_radio_reg(pi, RADIO_2064_REG116, 0x06);
> - write_radio_reg(pi, RADIO_2064_REG12C, 0x07);
> - write_radio_reg(pi, RADIO_2064_REG06A, 0xd3);
> - write_radio_reg(pi, RADIO_2064_REG098, 0x03);
> - write_radio_reg(pi, RADIO_2064_REG00B, 0x7);
> - mod_radio_reg(pi, RADIO_2064_REG113, 1 << 4, 1 << 4);
> - write_radio_reg(pi, RADIO_2064_REG01D, 0x01);
> - write_radio_reg(pi, RADIO_2064_REG114, 0x01);
> - write_radio_reg(pi, RADIO_2064_REG02E, 0x10);
> - write_radio_reg(pi, RADIO_2064_REG12A, 0x08);
> -
> - mod_phy_reg(pi, 0x938, (0x1 << 0), 1 << 0);
> - mod_phy_reg(pi, 0x939, (0x1 << 0), 0 << 0);
> - mod_phy_reg(pi, 0x938, (0x1 << 1), 1 << 1);
> - mod_phy_reg(pi, 0x939, (0x1 << 1), 1 << 1);
> - mod_phy_reg(pi, 0x938, (0x1 << 2), 1 << 2);
> - mod_phy_reg(pi, 0x939, (0x1 << 2), 1 << 2);
> - mod_phy_reg(pi, 0x938, (0x1 << 3), 1 << 3);
> - mod_phy_reg(pi, 0x939, (0x1 << 3), 1 << 3);
> - mod_phy_reg(pi, 0x938, (0x1 << 5), 1 << 5);
> - mod_phy_reg(pi, 0x939, (0x1 << 5), 0 << 5);
> -
> - mod_phy_reg(pi, 0x43b, (0x1 << 0), 1 << 0);
> - mod_phy_reg(pi, 0x43c, (0x1 << 0), 0 << 0);
> -
> - wlc_lcnphy_start_tx_tone(pi, 2000, 120, 0);
> - write_phy_reg(pi, 0x6da, 0xffff);
> - or_phy_reg(pi, 0x6db, 0x3);
> - wlc_lcnphy_set_trsw_override(pi, tx_switch, rx_switch);
> - wlc_lcnphy_rx_gain_override_enable(pi, true);
> -
> - tia_gain = 8;
> - rx_pwr_threshold = 950;
> - while (tia_gain > 0) {
> - tia_gain -= 1;
> - wlc_lcnphy_set_rx_gain_by_distribution(pi,
> - 0, 0, 2, 2,
> - (u16)
> - tia_gain, 1, 0);
> - udelay(500);
> + write_radio_reg(pi, RADIO_2064_REG116, 0x06);
> + write_radio_reg(pi, RADIO_2064_REG12C, 0x07);
> + write_radio_reg(pi, RADIO_2064_REG06A, 0xd3);
> + write_radio_reg(pi, RADIO_2064_REG098, 0x03);
> + write_radio_reg(pi, RADIO_2064_REG00B, 0x7);
> + mod_radio_reg(pi, RADIO_2064_REG113, 1 << 4, 1 << 4);
> + write_radio_reg(pi, RADIO_2064_REG01D, 0x01);
> + write_radio_reg(pi, RADIO_2064_REG114, 0x01);
> + write_radio_reg(pi, RADIO_2064_REG02E, 0x10);
> + write_radio_reg(pi, RADIO_2064_REG12A, 0x08);
> +
> + mod_phy_reg(pi, 0x938, (0x1 << 0), 1 << 0);
> + mod_phy_reg(pi, 0x939, (0x1 << 0), 0 << 0);
> + mod_phy_reg(pi, 0x938, (0x1 << 1), 1 << 1);
> + mod_phy_reg(pi, 0x939, (0x1 << 1), 1 << 1);
> + mod_phy_reg(pi, 0x938, (0x1 << 2), 1 << 2);
> + mod_phy_reg(pi, 0x939, (0x1 << 2), 1 << 2);
> + mod_phy_reg(pi, 0x938, (0x1 << 3), 1 << 3);
> + mod_phy_reg(pi, 0x939, (0x1 << 3), 1 << 3);
> + mod_phy_reg(pi, 0x938, (0x1 << 5), 1 << 5);
> + mod_phy_reg(pi, 0x939, (0x1 << 5), 0 << 5);
>
> - received_power =
> - wlc_lcnphy_measure_digital_power(pi, 2000);
> - if (received_power < rx_pwr_threshold)
> - break;
> + mod_phy_reg(pi, 0x43b, (0x1 << 0), 1 << 0);
> + mod_phy_reg(pi, 0x43c, (0x1 << 0), 0 << 0);
> +
> + write_phy_reg(pi, 0x6da, 0xffff);
> + or_phy_reg(pi, 0x6db, 0x3);
> +
> + wlc_lcnphy_set_trsw_override(pi, tx_switch, rx_switch);
> + set_gain = false;
> +
> + lna2_gain = 3;
> + while ((lna2_gain >= 0) && !set_gain) {
> + tia_gain = 4;
> +
> + while ((tia_gain >= 0) && !set_gain) {
> + biq1_gain = 6;
> +
> + while ((biq1_gain >= 0) && !set_gain) {
> + set_gain = wlc_lcnphy_rx_iq_cal_gain(pi,
> + (u16)
> + biq1_gain,
> + (u16)
> + tia_gain,
> + (u16)
> + lna2_gain);
> + biq1_gain -= 1;
> + }
> + tia_gain -= 1;
> }
> - result = wlc_lcnphy_calc_rx_iq_comp(pi, 0xffff);
> + lna2_gain -= 1;
> + }
This looks like it could be made more readable using for loops and a goto:
for (lna_gain = 3; lna_gain >= 0; lna_gain--) {
for (tia_gain = 4; tia_gain >= 0; tia_gain--) {
for (big1_gain = 6; big1_gain >= 0; big1_gain--) {
set_gain = wlc_lcnphy_rx_iq_cal_gain(...);
if (set_gain)
goto found;
}
}
}
found:
...
>
> - wlc_lcnphy_stop_tx_tone(pi);
> + if (set_gain)
> + result = wlc_lcnphy_calc_rx_iq_comp(pi, 1024);
> + else
> + result = false;
>
> - write_phy_reg(pi, 0x631, Core1TxControl_old);
> + wlc_lcnphy_stop_tx_tone(pi);
>
> - write_phy_reg(pi, 0x44c, RFOverrideVal0_old);
> - write_phy_reg(pi, 0x44d, RFOverrideVal0_old);
> - write_phy_reg(pi, 0x4b0, rfoverride2_old);
> - write_phy_reg(pi, 0x4b1, rfoverride2val_old);
> - write_phy_reg(pi, 0x4f9, rfoverride3_old);
> - write_phy_reg(pi, 0x4fa, rfoverride3val_old);
> - write_phy_reg(pi, 0x938, rfoverride4_old);
> - write_phy_reg(pi, 0x939, rfoverride4val_old);
> - write_phy_reg(pi, 0x43b, afectrlovr_old);
> - write_phy_reg(pi, 0x43c, afectrlovrval_old);
> - write_phy_reg(pi, 0x6da, old_sslpnCalibClkEnCtrl);
> - write_phy_reg(pi, 0x6db, old_sslpnRxFeClkEnCtrl);
> + write_phy_reg(pi, 0x631, Core1TxControl_old);
> +
> + write_phy_reg(pi, 0x44c, RFOverrideVal0_old);
> + write_phy_reg(pi, 0x44d, RFOverrideVal0_old);
> + write_phy_reg(pi, 0x4b0, rfoverride2_old);
> + write_phy_reg(pi, 0x4b1, rfoverride2val_old);
> + write_phy_reg(pi, 0x4f9, rfoverride3_old);
> + write_phy_reg(pi, 0x4fa, rfoverride3val_old);
> + write_phy_reg(pi, 0x938, rfoverride4_old);
> + write_phy_reg(pi, 0x939, rfoverride4val_old);
> + write_phy_reg(pi, 0x43b, afectrlovr_old);
> + write_phy_reg(pi, 0x43c, afectrlovrval_old);
> + write_phy_reg(pi, 0x6da, old_sslpnCalibClkEnCtrl);
> + write_phy_reg(pi, 0x6db, old_sslpnRxFeClkEnCtrl);
>
> - wlc_lcnphy_clear_trsw_override(pi);
> + wlc_lcnphy_clear_trsw_override(pi);
>
> - mod_phy_reg(pi, 0x44c, (0x1 << 2), 0 << 2);
> + mod_phy_reg(pi, 0x44c, (0x1 << 2), 0 << 2);
>
> - for (i = 0; i < 11; i++)
> - write_radio_reg(pi, rxiq_cal_rf_reg[i],
> - values_to_save[i]);
> + for (i = 0; i < 11; i++)
> + write_radio_reg(pi, rxiq_cal_rf_reg[i],
> + values_to_save[i]);
>
> - if (tx_gain_override_old)
> - wlc_lcnphy_set_tx_pwr_by_index(pi, tx_gain_index_old);
> - else
> - wlc_lcnphy_disable_tx_gain_override(pi);
> + if (tx_gain_override_old)
> + wlc_lcnphy_set_tx_pwr_by_index(pi, tx_gain_index_old);
> + else
> + wlc_lcnphy_disable_tx_gain_override(pi);
>
> - wlc_lcnphy_set_tx_pwr_ctrl(pi, tx_pwr_ctrl);
> - wlc_lcnphy_rx_gain_override_enable(pi, false);
> - }
> + wlc_lcnphy_set_tx_pwr_ctrl(pi, tx_pwr_ctrl);
> + wlc_lcnphy_rx_gain_override_enable(pi, false);
>
> cal_done:
> kfree(ptr);
> @@ -1789,6 +1835,17 @@ wlc_lcnphy_radio_2064_channel_tune_4313(struct brcms_phy *pi, u8 channel)
> write_radio_reg(pi, RADIO_2064_REG038, 3);
> write_radio_reg(pi, RADIO_2064_REG091, 7);
> }
> +
> + if (!(pi->sh->boardflags & BFL_FEM)) {
> + u8 reg038[14] = {0xd, 0xe, 0xd, 0xd, 0xd, 0xc,
> + 0xa, 0xb, 0xb, 0x3, 0x3, 0x2, 0x0, 0x0};
> +
> + write_radio_reg(pi, RADIO_2064_REG02A, 0xf);
> + write_radio_reg(pi, RADIO_2064_REG091, 0x3);
> + write_radio_reg(pi, RADIO_2064_REG038, 0x3);
> +
> + write_radio_reg(pi, RADIO_2064_REG038, reg038[channel - 1]);
> + }
> }
>
> static int
> @@ -1983,6 +2040,16 @@ wlc_lcnphy_set_tssi_mux(struct brcms_phy *pi, enum lcnphy_tssi_mode pos)
> } else {
> mod_radio_reg(pi, RADIO_2064_REG03A, 1, 0x1);
> mod_radio_reg(pi, RADIO_2064_REG11A, 0x8, 0x8);
> + mod_radio_reg(pi, RADIO_2064_REG028, 0x1, 0x0);
> + mod_radio_reg(pi, RADIO_2064_REG11A, 0x4, 1<<2);
> + mod_radio_reg(pi, RADIO_2064_REG036, 0x10, 0x0);
> + mod_radio_reg(pi, RADIO_2064_REG11A, 0x10, 1<<4);
> + mod_radio_reg(pi, RADIO_2064_REG036, 0x3, 0x0);
> + mod_radio_reg(pi, RADIO_2064_REG035, 0xff, 0x77);
> + mod_radio_reg(pi, RADIO_2064_REG028, 0x1e, 0xe<<1);
> + mod_radio_reg(pi, RADIO_2064_REG112, 0x80, 1<<7);
> + mod_radio_reg(pi, RADIO_2064_REG005, 0x7, 1<<1);
> + mod_radio_reg(pi, RADIO_2064_REG029, 0xf0, 0<<4);
What does this do? This seems to be applied regardless of iPA or ePA,
so I looks like it fixes something? Or is this needed for iPA and
harmless for ePA?
> }
> } else {
> mod_phy_reg(pi, 0x4d9, (0x1 << 2), (0x1) << 2);
> @@ -2069,12 +2136,14 @@ static void wlc_lcnphy_pwrctrl_rssiparams(struct brcms_phy *pi)
> (auxpga_vmid_temp << 0) | (auxpga_gain_temp << 12));
>
> mod_radio_reg(pi, RADIO_2064_REG082, (1 << 5), (1 << 5));
> + mod_radio_reg(pi, RADIO_2064_REG07C, (1 << 0), (1 << 0));
Same here.
> }
>
> static void wlc_lcnphy_tssi_setup(struct brcms_phy *pi)
> {
> struct phytbl_info tab;
> u32 rfseq, ind;
> + u8 tssi_sel;
>
> tab.tbl_id = LCNPHY_TBL_ID_TXPWRCTL;
> tab.tbl_width = 32;
> @@ -2096,7 +2165,13 @@ static void wlc_lcnphy_tssi_setup(struct brcms_phy *pi)
>
> mod_phy_reg(pi, 0x503, (0x1 << 4), (1) << 4);
>
> - wlc_lcnphy_set_tssi_mux(pi, LCNPHY_TSSI_EXT);
> + if (pi->sh->boardflags & BFL_FEM) {
> + tssi_sel = 0x1;
> + wlc_lcnphy_set_tssi_mux(pi, LCNPHY_TSSI_EXT);
> + } else {
> + tssi_sel = 0xe;
> + wlc_lcnphy_set_tssi_mux(pi, LCNPHY_TSSI_POST_PA);
> + }
Doesn't this change change tssi_sel from 0xe to 0x1 for (already
supported) ePA cards, and sets it to the old value 0xe for iPA ones? I
would have expected 0xe for BFL_FEM /ePA and 0x1 for iPA ... .
> mod_phy_reg(pi, 0x4a4, (0x1 << 14), (0) << 14);
>
> mod_phy_reg(pi, 0x4a4, (0x1 << 15), (1) << 15);
> @@ -2132,9 +2207,10 @@ static void wlc_lcnphy_tssi_setup(struct brcms_phy *pi)
> mod_phy_reg(pi, 0x49a, (0x1ff << 0), (0xff) << 0);
>
> if (LCNREV_IS(pi->pubpi.phy_rev, 2)) {
> - mod_radio_reg(pi, RADIO_2064_REG028, 0xf, 0xe);
> + mod_radio_reg(pi, RADIO_2064_REG028, 0xf, tssi_sel);
> mod_radio_reg(pi, RADIO_2064_REG086, 0x4, 0x4);
> } else {
> + mod_radio_reg(pi, RADIO_2064_REG028, 0x1e, tssi_sel << 1);
Okay, this one is new also for the ePA case, so I wonder why this
wasn't needed before?
> mod_radio_reg(pi, RADIO_2064_REG03A, 0x1, 1);
> mod_radio_reg(pi, RADIO_2064_REG11A, 0x8, 1 << 3);
> }
> @@ -2181,6 +2257,10 @@ static void wlc_lcnphy_tssi_setup(struct brcms_phy *pi)
>
> mod_phy_reg(pi, 0x4d7, (0xf << 8), (0) << 8);
>
> + mod_radio_reg(pi, RADIO_2064_REG035, 0xff, 0x0);
> + mod_radio_reg(pi, RADIO_2064_REG036, 0x3, 0x0);
> + mod_radio_reg(pi, RADIO_2064_REG11A, 0x8, 0x8);
> +
Same for these three writes.
> wlc_lcnphy_pwrctrl_rssiparams(pi);
> }
>
> @@ -2799,6 +2879,8 @@ static void wlc_lcnphy_idle_tssi_est(struct brcms_phy_pub *ppi)
> read_radio_reg(pi, RADIO_2064_REG007) & 1;
> u16 SAVE_jtag_auxpga = read_radio_reg(pi, RADIO_2064_REG0FF) & 0x10;
> u16 SAVE_iqadc_aux_en = read_radio_reg(pi, RADIO_2064_REG11F) & 4;
> + u8 SAVE_bbmult = wlc_lcnphy_get_bbmult(pi);
> +
These changes also look at a first glance unrelated to iPA, as well as ...
> idleTssi = read_phy_reg(pi, 0x4ab);
> suspend = (0 == (bcma_read32(pi->d11core, D11REGOFFS(maccontrol)) &
> MCTL_EN_MAC));
> @@ -2816,6 +2898,12 @@ static void wlc_lcnphy_idle_tssi_est(struct brcms_phy_pub *ppi)
> mod_radio_reg(pi, RADIO_2064_REG0FF, 0x10, 1 << 4);
> mod_radio_reg(pi, RADIO_2064_REG11F, 0x4, 1 << 2);
> wlc_lcnphy_tssi_setup(pi);
> +
> + mod_phy_reg(pi, 0x4d7, (0x1 << 0), (1 << 0));
> + mod_phy_reg(pi, 0x4d7, (0x1 << 6), (1 << 6));
> +
> + wlc_lcnphy_set_bbmult(pi, 0x0);
> +
These ones.
> wlc_phy_do_dummy_tx(pi, true, OFF);
> idleTssi = ((read_phy_reg(pi, 0x4ab) & (0x1ff << 0))
> >> 0);
> @@ -2837,6 +2925,7 @@ static void wlc_lcnphy_idle_tssi_est(struct brcms_phy_pub *ppi)
>
> mod_phy_reg(pi, 0x44c, (0x1 << 12), (0) << 12);
>
> + wlc_lcnphy_set_bbmult(pi, SAVE_bbmult);
> wlc_lcnphy_set_tx_gain_override(pi, tx_gain_override_old);
> wlc_lcnphy_set_tx_gain(pi, &old_gains);
> wlc_lcnphy_set_tx_pwr_ctrl(pi, SAVE_txpwrctrl);
> @@ -3050,6 +3139,11 @@ static void wlc_lcnphy_tx_pwr_ctrl_init(struct brcms_phy_pub *ppi)
> wlc_lcnphy_write_table(pi, &tab);
> tab.tbl_offset++;
> }
> + mod_phy_reg(pi, 0x4d0, (0x1 << 0), (0) << 0);
> + mod_phy_reg(pi, 0x4d3, (0xff << 0), (0) << 0);
> + mod_phy_reg(pi, 0x4d3, (0xff << 8), (0) << 8);
> + mod_phy_reg(pi, 0x4d0, (0x1 << 4), (0) << 4);
> + mod_phy_reg(pi, 0x4d0, (0x1 << 2), (0) << 2);
>
> mod_phy_reg(pi, 0x410, (0x1 << 7), (0) << 7);
>
> @@ -3851,7 +3945,6 @@ static void wlc_lcnphy_txpwrtbl_iqlo_cal(struct brcms_phy *pi)
> target_gains.pad_gain = 21;
> target_gains.dac_gain = 0;
> wlc_lcnphy_set_tx_gain(pi, &target_gains);
> - wlc_lcnphy_set_tx_pwr_by_index(pi, 16);
>
> if (LCNREV_IS(pi->pubpi.phy_rev, 1) || pi_lcn->lcnphy_hw_iqcal_en) {
>
> @@ -3862,6 +3955,7 @@ static void wlc_lcnphy_txpwrtbl_iqlo_cal(struct brcms_phy *pi)
> lcnphy_recal ? LCNPHY_CAL_RECAL :
> LCNPHY_CAL_FULL), false);
> } else {
> + wlc_lcnphy_set_tx_pwr_by_index(pi, 16);
> wlc_lcnphy_tx_iqlo_soft_cal_full(pi);
> }
>
> @@ -4286,17 +4380,22 @@ wlc_lcnphy_load_tx_gain_table(struct brcms_phy *pi,
> if (CHSPEC_IS5G(pi->radio_chanspec))
> pa_gain = 0x70;
> else
> - pa_gain = 0x70;
> + pa_gain = 0x60;
You are reducing the value for !BFL_FEM, I assume this is a fix for something?
>
> if (pi->sh->boardflags & BFL_FEM)
> pa_gain = 0x10;
> +
Unnecessary whitespace change.
> tab.tbl_id = LCNPHY_TBL_ID_TXPWRCTL;
> tab.tbl_width = 32;
> tab.tbl_len = 1;
> tab.tbl_ptr = &val;
>
> for (j = 0; j < 128; j++) {
> - gm_gain = gain_table[j].gm;
> + if (pi->sh->boardflags & BFL_FEM)
> + gm_gain = gain_table[j].gm;
> + else
> + gm_gain = 15;
> +
> val = (((u32) pa_gain << 24) |
> (gain_table[j].pad << 16) |
> (gain_table[j].pga << 8) | gm_gain);
> @@ -4507,7 +4606,10 @@ static void wlc_radio_2064_init(struct brcms_phy *pi)
>
> write_phy_reg(pi, 0x4ea, 0x4688);
>
> - mod_phy_reg(pi, 0x4eb, (0x7 << 0), 2 << 0);
> + if (pi->sh->boardflags & BFL_FEM)
> + mod_phy_reg(pi, 0x4eb, (0x7 << 0), 2 << 0);
> + else
> + mod_phy_reg(pi, 0x4eb, (0x7 << 0), 3 << 0);
>
> mod_phy_reg(pi, 0x4eb, (0x7 << 6), 0 << 6);
>
> @@ -4518,6 +4620,13 @@ static void wlc_radio_2064_init(struct brcms_phy *pi)
> wlc_lcnphy_rcal(pi);
>
> wlc_lcnphy_rc_cal(pi);
> +
> + if (!(pi->sh->boardflags & BFL_FEM)) {
> + write_radio_reg(pi, RADIO_2064_REG032, 0x6f);
> + write_radio_reg(pi, RADIO_2064_REG033, 0x19);
> + write_radio_reg(pi, RADIO_2064_REG039, 0xe);
> + }
> +
> }
>
> static void wlc_lcnphy_radio_init(struct brcms_phy *pi)
> @@ -4530,6 +4639,7 @@ static void wlc_lcnphy_tbl_init(struct brcms_phy *pi)
> uint idx;
> u8 phybw40;
> struct phytbl_info tab;
> + const struct phytbl_info *tb;
> u32 val;
>
> phybw40 = CHSPEC_IS40(pi->radio_chanspec);
> @@ -4547,22 +4657,20 @@ static void wlc_lcnphy_tbl_init(struct brcms_phy *pi)
> wlc_lcnphy_write_table(pi, &tab);
> }
>
> - tab.tbl_id = LCNPHY_TBL_ID_RFSEQ;
> - tab.tbl_width = 16;
> - tab.tbl_ptr = &val;
> - tab.tbl_len = 1;
> -
> - val = 114;
> - tab.tbl_offset = 0;
> - wlc_lcnphy_write_table(pi, &tab);
> + if (!(pi->sh->boardflags & BFL_FEM)) {
> + tab.tbl_id = LCNPHY_TBL_ID_RFSEQ;
> + tab.tbl_width = 16;
> + tab.tbl_ptr = &val;
> + tab.tbl_len = 1;
>
> - val = 130;
> - tab.tbl_offset = 1;
> - wlc_lcnphy_write_table(pi, &tab);
> + val = 150;
> + tab.tbl_offset = 0;
> + wlc_lcnphy_write_table(pi, &tab);
>
> - val = 6;
> - tab.tbl_offset = 8;
> - wlc_lcnphy_write_table(pi, &tab);
> + val = 220;
> + tab.tbl_offset = 1;
> + wlc_lcnphy_write_table(pi, &tab);
> + }
So this isn't needed anymore for ePA cards?
>
> if (CHSPEC_IS2G(pi->radio_chanspec)) {
> if (pi->sh->boardflags & BFL_FEM)
> @@ -4576,7 +4684,6 @@ static void wlc_lcnphy_tbl_init(struct brcms_phy *pi)
> }
>
> if (LCNREV_IS(pi->pubpi.phy_rev, 2)) {
> - const struct phytbl_info *tb;
> int l;
>
> if (CHSPEC_IS2G(pi->radio_chanspec)) {
> @@ -4597,21 +4704,22 @@ static void wlc_lcnphy_tbl_init(struct brcms_phy *pi)
> wlc_lcnphy_write_table(pi, &tb[idx]);
> }
>
> - if ((pi->sh->boardflags & BFL_FEM)
> - && !(pi->sh->boardflags & BFL_FEM_BT))
> - wlc_lcnphy_write_table(pi, &dot11lcn_sw_ctrl_tbl_info_4313_epa);
> - else if (pi->sh->boardflags & BFL_FEM_BT) {
> - if (pi->sh->boardrev < 0x1250)
> - wlc_lcnphy_write_table(
> - pi,
> - &dot11lcn_sw_ctrl_tbl_info_4313_bt_epa);
> + if (pi->sh->boardflags & BFL_FEM) {
> + if (pi->sh->boardflags & BFL_FEM_BT) {
> + if (pi->sh->boardrev < 0x1250)
> + tb = &dot11lcn_sw_ctrl_tbl_info_4313_bt_epa;
> + else
> + tb = &dot11lcn_sw_ctrl_tbl_info_4313_bt_epa_p250;
> + } else {
> + tb = &dot11lcn_sw_ctrl_tbl_info_4313_epa;
> + }
> + } else {
> + if (pi->sh->boardflags & BFL_FEM_BT)
> + tb = &dot11lcn_sw_ctrl_tbl_info_4313_bt_ipa;
> else
> - wlc_lcnphy_write_table(
> - pi,
> - &dot11lcn_sw_ctrl_tbl_info_4313_bt_epa_p250);
> - } else
> - wlc_lcnphy_write_table(pi, &dot11lcn_sw_ctrl_tbl_info_4313);
> -
> + tb = &dot11lcn_sw_ctrl_tbl_info_4313;
> + }
> + wlc_lcnphy_write_table(pi, tb);
> wlc_lcnphy_load_rfpower(pi);
>
> wlc_lcnphy_clear_papd_comptable(pi);
> @@ -4955,6 +5063,8 @@ void wlc_phy_chanspec_set_lcnphy(struct brcms_phy *pi, u16 chanspec)
> wlc_lcnphy_load_tx_iir_filter(pi, true, 3);
>
> mod_phy_reg(pi, 0x4eb, (0x7 << 3), (1) << 3);
> + if (wlc_lcnphy_tssi_based_pwr_ctrl_enabled(pi))
> + wlc_lcnphy_tssi_setup(pi);
> }
>
> void wlc_phy_detach_lcnphy(struct brcms_phy *pi)
> @@ -4993,8 +5103,7 @@ bool wlc_phy_attach_lcnphy(struct brcms_phy *pi)
> if (!wlc_phy_txpwr_srom_read_lcnphy(pi))
> return false;
>
> - if ((pi->sh->boardflags & BFL_FEM) &&
> - (LCNREV_IS(pi->pubpi.phy_rev, 1))) {
> + if (LCNREV_IS(pi->pubpi.phy_rev, 1)) {
> if (pi_lcn->lcnphy_tempsense_option == 3) {
> pi->hwpwrctrl = true;
> pi->hwpwrctrl_capable = true;
> diff --git a/drivers/net/wireless/brcm80211/brcmsmac/phy/phytbl_lcn.c b/drivers/net/wireless/brcm80211/brcmsmac/phy/phytbl_lcn.c
> index 622c01c..9fb0ca2 100644
> --- a/drivers/net/wireless/brcm80211/brcmsmac/phy/phytbl_lcn.c
> +++ b/drivers/net/wireless/brcm80211/brcmsmac/phy/phytbl_lcn.c
> @@ -2058,6 +2058,73 @@ static const u16 dot11lcn_sw_ctrl_tbl_4313_rev0[] = {
> 0x0005,
> };
>
> +static const u16 dot11lcn_sw_ctrl_tbl_4313_ipa_rev0_combo[] = {
> + 0x0005,
> + 0x0006,
> + 0x0009,
> + 0x000a,
> + 0x0005,
> + 0x0006,
> + 0x0009,
> + 0x000a,
> + 0x0005,
> + 0x0006,
> + 0x0009,
> + 0x000a,
> + 0x0005,
> + 0x0006,
> + 0x0009,
> + 0x000a,
> + 0x0005,
> + 0x0006,
> + 0x0009,
> + 0x000a,
> + 0x0005,
> + 0x0006,
> + 0x0009,
> + 0x000a,
> + 0x0005,
> + 0x0006,
> + 0x0009,
> + 0x000a,
> + 0x0005,
> + 0x0006,
> + 0x0009,
> + 0x000a,
> + 0x0005,
> + 0x0006,
> + 0x0009,
> + 0x000a,
> + 0x0005,
> + 0x0006,
> + 0x0009,
> + 0x000a,
> + 0x0005,
> + 0x0006,
> + 0x0009,
> + 0x000a,
> + 0x0005,
> + 0x0006,
> + 0x0009,
> + 0x000a,
> + 0x0005,
> + 0x0006,
> + 0x0009,
> + 0x000a,
> + 0x0005,
> + 0x0006,
> + 0x0009,
> + 0x000a,
> + 0x0005,
> + 0x0006,
> + 0x0009,
> + 0x000a,
> + 0x0005,
> + 0x0006,
> + 0x0009,
> + 0x000a,
> +};
> +
> static const u16 dot11lcn_sw_ctrl_tbl_rev0[] = {
> 0x0004,
> 0x0004,
> @@ -2834,6 +2901,12 @@ const struct phytbl_info dot11lcn_sw_ctrl_tbl_info_4313 = {
> sizeof(dot11lcn_sw_ctrl_tbl_4313_rev0[0]), 15, 0, 16
> };
>
> +const struct phytbl_info dot11lcn_sw_ctrl_tbl_info_4313_bt_ipa = {
> + &dot11lcn_sw_ctrl_tbl_4313_ipa_rev0_combo,
> + sizeof(dot11lcn_sw_ctrl_tbl_4313_ipa_rev0_combo) /
> + sizeof(dot11lcn_sw_ctrl_tbl_4313_ipa_rev0_combo[0]), 15, 0, 16
Not necessarily in this patch but maybe in a follow up cleanup patch:
ARRAY_SIZE() please?
I guess that's it from me.
Regards
Jonas
^ permalink raw reply
* [patch] iwlwifi: pcie: returning positive instead of negative
From: Dan Carpenter @ 2013-08-10 23:03 UTC (permalink / raw)
To: Johannes Berg
Cc: Emmanuel Grumbach, Intel Linux Wireless, John W. Linville,
linux-wireless, kernel-janitors
There is a missing '-' character here so we return positive 'ENOMEM'
instead of negative. The caller doesn't care. All non-zero returns
are translated to '-ENOMEM' in iwl_pcie_nic_init().
This is just a cleanup.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/net/wireless/iwlwifi/pcie/tx.c b/drivers/net/wireless/iwlwifi/pcie/tx.c
index 134f7a1..a81d227 100644
--- a/drivers/net/wireless/iwlwifi/pcie/tx.c
+++ b/drivers/net/wireless/iwlwifi/pcie/tx.c
@@ -829,7 +829,7 @@ static int iwl_pcie_tx_alloc(struct iwl_trans *trans)
sizeof(struct iwl_txq), GFP_KERNEL);
if (!trans_pcie->txq) {
IWL_ERR(trans, "Not enough memory for txq\n");
- ret = ENOMEM;
+ ret = -ENOMEM;
goto error;
}
^ permalink raw reply related
* Re: [PATCH] udev: fail firmware loading immediately if no search path is defined
From: Kay Sievers @ 2013-08-10 21:28 UTC (permalink / raw)
To: Tom Gundersen
Cc: Maarten Lankhorst, Linux Wireless List, Andy Lutomirski,
Intel Linux Wireless, Johannes Berg, linux-hotplug, Bryan Kadzban,
systemd Mailing List, linux-kernel
In-Reply-To: <CAG-2HqUT3hbFPSEqYnJvBOgS6p4dKf=nhqZtzqS-on8FFe9ipA@mail.gmail.com>
On Sat, Aug 10, 2013 at 11:00 PM, Tom Gundersen <teg@jklm.no> wrote:
> It would be simple enough to add an udev rule to just print 'ignoring
> firmware event' to the logs.
This and I guess:
SUBSYSTEM=="firmware", ACTION=="add", ATTR{loading}="-1"
would also just cancel the request at the same time without any other
code needed.
The udev firmware support just a configure option, just like the
kernel has them. So distributions should enable it in udev and the
kernel if they need it.
We simply cannot coordinate the defaults of systemd and the kernel
because the rules of the kernel are different. The kernel does "keep
defaults like stuff has been in the past" and udev does "make default
what makes the most sense on current systems".
> We should really ignore the event though, and
> not cancel it. Not sure if this is something we want upstream (after all,
> there are plenty of situations where we don't warn if the recommendations in
> the README file are not followed), or if distros and whoever wants it should
> ship that themselves. I'll leave that for Kay to decide.
The proper fix is that userspace firmware should be disabled in the
kernel for new systems, and kept enabled only for old systems. Old
systems need to enable a new udev version to support firmware loading.
There are currently broken in-kernel mis-users of the firmware
interface that use the firmware interface but disable uevents, they
still pull-in the user interface of the firmware loader. If nobody
wants to fix them, the code for the common users of the firmware
loader should at least get rid of the userspace fallback to call out
to userspace. At that point the udev configure option would not matter
any more.
> Lastly, note that the plan is to drop all the firmware code from udev in the
> not too distant future, so it doesn't really maker much sense to add new
> functionality to that at this point.
Right, I think all is fine. It's something that people can control
with the kernel and udev configuration options. It's just that the
defaults of the kernel and udev don't match at the moment, because
they have different policies of setting default values.
Kay
^ permalink raw reply
* rt2800usb: Kernel log spammed with TX status messages
From: Michael Büsch @ 2013-08-10 17:53 UTC (permalink / raw)
To: Ivo van Doorn, Gertjan van Wingerde, Helmut Schaa; +Cc: linux-wireless
[-- Attachment #1: Type: text/plain, Size: 7749 bytes --]
Hi,
My kernel logs are spammed with messages like the ones below.
I'm currently running latest debian sid kernel, which is based on 3.10.5.
The device is
Bus 009 Device 002: ID 148f:5370 Ralink Technology, Corp. RT5370 Wireless Adapter
Any idea on how to debug/fix this?
Aug 10 11:27:44 marge kernel: [ 5560.310989] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 11 in queue 2
Aug 10 11:27:44 marge kernel: [ 5560.311077] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 11 in queue 2
Aug 10 11:27:44 marge kernel: [ 5560.311101] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 11 in queue 2
Aug 10 11:27:44 marge kernel: [ 5560.319229] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 12 in queue 2
Aug 10 11:27:44 marge kernel: [ 5560.319271] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 12 in queue 2
Aug 10 11:27:44 marge kernel: [ 5560.319281] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 12 in queue 2
Aug 10 11:27:44 marge kernel: [ 5560.319305] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 13 in queue 2
Aug 10 11:27:44 marge kernel: [ 5560.330987] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 14 in queue 2
Aug 10 11:27:44 marge kernel: [ 5560.331107] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 14 in queue 2
Aug 10 11:27:44 marge kernel: [ 5560.331126] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 14 in queue 2
Aug 10 11:27:44 marge kernel: [ 5560.412247] ieee80211 phy0: rt2800usb_txdone: Warning - Got TX status for an empty queue 2, dropping
Aug 10 11:27:44 marge kernel: [ 5560.412364] ieee80211 phy0: rt2800usb_txdone: Warning - Got TX status for an empty queue 2, dropping
Aug 10 11:27:44 marge kernel: [ 5560.412488] ieee80211 phy0: rt2800usb_txdone: Warning - Got TX status for an empty queue 2, dropping
Aug 10 11:27:44 marge kernel: [ 5560.412612] ieee80211 phy0: rt2800usb_txdone: Warning - Got TX status for an empty queue 2, dropping
Aug 10 11:27:45 marge kernel: [ 5560.923400] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 0 in queue 2
Aug 10 11:27:45 marge kernel: [ 5560.923421] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 0 in queue 2
Aug 10 11:27:45 marge kernel: [ 5560.923424] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 0 in queue 2
Aug 10 11:27:45 marge kernel: [ 5560.927149] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 1 in queue 2
Aug 10 11:27:45 marge kernel: [ 5560.927166] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 1 in queue 2
Aug 10 11:27:45 marge kernel: [ 5560.927169] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 1 in queue 2
Aug 10 11:27:45 marge kernel: [ 5560.943279] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 2 in queue 2
Aug 10 11:27:45 marge kernel: [ 5560.943301] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 2 in queue 2
Aug 10 11:27:45 marge kernel: [ 5560.943310] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 2 in queue 2
Aug 10 11:27:45 marge kernel: [ 5560.943332] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 3 in queue 2
Aug 10 11:27:45 marge kernel: [ 5560.947404] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 4 in queue 2
Aug 10 11:27:45 marge kernel: [ 5560.947432] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 4 in queue 2
Aug 10 11:27:45 marge kernel: [ 5560.947436] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 4 in queue 2
Aug 10 11:27:45 marge kernel: [ 5560.947445] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 5 in queue 2
Aug 10 11:27:45 marge kernel: [ 5560.971166] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 6 in queue 2
Aug 10 11:27:45 marge kernel: [ 5560.971215] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 6 in queue 2
Aug 10 11:27:45 marge kernel: [ 5560.971224] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 6 in queue 2
Aug 10 11:27:45 marge kernel: [ 5560.971254] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 7 in queue 2
Aug 10 11:27:45 marge kernel: [ 5560.971264] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 8 in queue 2
Aug 10 11:27:45 marge kernel: [ 5560.979413] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 9 in queue 2
Aug 10 11:27:45 marge kernel: [ 5560.979448] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 9 in queue 2
Aug 10 11:27:45 marge kernel: [ 5560.979456] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 9 in queue 2
Aug 10 11:27:45 marge kernel: [ 5560.979476] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 10 in queue 2
Aug 10 11:27:45 marge kernel: [ 5560.987291] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 11 in queue 2
Aug 10 11:27:45 marge kernel: [ 5560.987339] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 11 in queue 2
Aug 10 11:27:45 marge kernel: [ 5560.987347] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 11 in queue 2
Aug 10 11:27:45 marge kernel: [ 5560.996550] ieee80211 phy0: rt2800usb_txdone: Warning - Got TX status for an empty queue 2, dropping
Aug 10 11:27:45 marge kernel: [ 5560.996667] ieee80211 phy0: rt2800usb_txdone: Warning - Got TX status for an empty queue 2, dropping
Aug 10 11:27:45 marge kernel: [ 5561.069806] ieee80211 phy0: rt2800usb_txdone: Warning - Got TX status for an empty queue 2, dropping
Aug 10 11:27:45 marge kernel: [ 5561.069925] ieee80211 phy0: rt2800usb_txdone: Warning - Got TX status for an empty queue 2, dropping
Aug 10 11:27:45 marge kernel: [ 5561.070048] ieee80211 phy0: rt2800usb_txdone: Warning - Got TX status for an empty queue 2, dropping
Aug 10 11:27:45 marge kernel: [ 5561.070173] ieee80211 phy0: rt2800usb_txdone: Warning - Got TX status for an empty queue 2, dropping
Aug 10 11:27:45 marge kernel: [ 5561.070298] ieee80211 phy0: rt2800usb_txdone: Warning - Got TX status for an empty queue 2, dropping
Aug 10 11:27:45 marge kernel: [ 5561.070423] ieee80211 phy0: rt2800usb_txdone: Warning - Got TX status for an empty queue 2, dropping
Aug 10 11:27:45 marge kernel: [ 5561.070547] ieee80211 phy0: rt2800usb_txdone: Warning - Got TX status for an empty queue 2, dropping
Aug 10 11:27:45 marge kernel: [ 5561.070675] ieee80211 phy0: rt2800usb_txdone: Warning - Got TX status for an empty queue 2, dropping
Aug 10 11:27:45 marge kernel: [ 5561.070798] ieee80211 phy0: rt2800usb_txdone: Warning - Got TX status for an empty queue 2, dropping
Aug 10 11:27:45 marge kernel: [ 5561.087058] ieee80211 phy0: rt2800usb_txdone: Warning - Got TX status for an empty queue 2, dropping
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [v3.10] [regression] [b43] : mac80211/minstrel: use the new rate control API
From: Ronald @ 2013-08-10 17:30 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless
In-Reply-To: <52057D86.9060500@openwrt.org>
Yes, issue fixed in v3.11-rc4. I assumed that since the regression
hopped over from v3.10 to v3.11, it got undetected. I also tested
v3.11 half way it's merge window (this kernel did boot) which
contained the regression as well.
Apparently it was noticed later and fixed later than I expected. Sorry
for the noise.
2013/8/10 Felix Fietkau <nbd@openwrt.org>:
> The fix for this issue has been merged upstream and is in the stable
> queue (so will probably be included in 3.10.6). Another way you can get
> rid of this error in your existing kernel is to enable
> CONFIG_MAC80211_RC_MINSTREL_HT in your .config
>
> - Felix
>
> On 2013-08-09 11:28 PM, Ronald wrote:
>> Excuse me, this should be a v3.10 regression.
>>
>> 2013/8/9 Ronald <ronald645@gmail.com>:
>>> [ Please cc me as I'm not subscribed ]
>>>
>>> Mentioned commit causes a regression on my box. It oopses after
>>> NetworkManager comes up and tries to use the card (I think).
>>>
>>> The card is:
>>>
>>> [ 1.220907] b43-phy0: Broadcom 4311 WLAN found (core revision 10)
>>> [ 1.230206] ata1.00: configured for UDMA/100
>>> [ 1.320018] b43-phy0: Found PHY: Analog 4, Type 2 (G), Revision 8
>>> [ 1.380120] Broadcom 43xx driver loaded [ Features: P ]
>>>
>>> I typed over the oops (first lines fell off, sorry):
>>>
>>> Workqueue: phy0 ieee80211_scan_work
>>> task: ffff880000211c20 ti: ffff880034c0c000 task.ti: ffff880034c0c000
>>> RIP: 0010:[<ffffffff81580382>] [<ffffffff81580382>] minstrel_get_rate+0x22/0x250
>>> RSP: 0018:ffff880034c0da88 EFLAGS: 00010286
>>> RAX: ffffffff81870ac0 RBX: 0000000000000000 RCX: ffff880034c0db58
>>> RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff880034c67a00
>>> RBP: ffff880034c0dac8 R08: ffff8800000863a0 R09: 0000000000000fff
>>> R10: ffffffff81856020 R11: 0000000000000000 R12: ffff880034c67a00
>>> R13: ffff880034da2740 R14: ffff880034c0db58 R15: ffff88000039f940
>>> FS: 00007fd6da002700(0000) GS:ffffffff8181e000(0000) knlGS:0000000000000000
>>> CS: 0010 DS: 0000 ES: 0000 CR0: 000000000005003b
>>> CR2: 0000000000000048 CR3: 000000003517e000 CR4: 00000000000007f0
>>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>>> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>>> Stack:
>>> 0000000000000000 ffff880034c0db28 ffff880034c0daf8 ffff88003517c330
>>> 0000000000000000 ffff880034da2740 ffff880034c0db58 ffff88000039f940
>>> ffff880034c0daf8 ffffffff815653e1 ffff880034c0dbe0 ffff88003517c300
>>> Call Trace:
>>> [<ffffffff815653e1>] rate_control_get_rate+0xa1/0xe0
>>> [<ffffffff815709e9>] invoke_tx_handlers+0x729/0x1360
>>> [<ffffffff8104bc3d>] ? sched_clock_local.constprop.1+0x1d/0x90
>>> [<ffffffff8104ce6e>] ? check_preempt_wakeup+0x11e/0x240
>>> [<ffffffff8157169d>] ieee80211_tx+0x7d/0x100
>>> [<ffffffff815717b1>] ieee80211_xmit+0x91/0xc0
>>> [<ffffffff8157307e>] __ieee80211_tx_skb_tid_band+0x6e/0x80
>>> [<ffffffff81577643>] ieee80211_send_probe_req+0x73/0xc0
>>> [<ffffffff8155a10f>] ieee80211_scan_state_send_probe+0x9f/0xe0
>>> [<ffffffff8155ad9c>] ieee80211_scan_work+0x1fc/0x440
>>> [<ffffffff8103c9ba>] process_one_work+0x13a/0x3b0
>>> [<ffffffff8103cfcb>] worker_thread+0x10b/0x350
>>> [<ffffffff8103cec0>] ? rescuer_thread+0x250/0x250
>>> [<ffffffff81042afa>] kthread+0xba/0xc0
>>> [<ffffffff81042a40>] ? __kthread_parkme+0x80/0x80
>>> [<ffffffff8158c32a>] ret_from_fork+0x7a/0xb0
>>> [<ffffffff81042a40>] ? __kthread_parkme+0x80/0x80
>>> Code: 00 00 00 00 00 0f 1f 40 00 55 48 89 e5 48 83 ec 40 48 89 5d d8
>>> 4c 89 65 e0 48 89 d3 4c 89 6d e8 4c 89 7d f8 49 89 fc 4c 89 75 f0 <44>
>>> 0f b6 f7 4c 8b 71 18 48 89 ca 48 89 de 49 89 cd
>>> RIP [<ffffffff81580382>] minstrel_get_rate+0x22/0x250
>>> RSP <ffff880034c0da88>
>>> CR2: 0000000000000048
>>> ---[ end trace 071727ab6dc6fcf3 ]---
>>> Kernel panic - not syncing: Fatal exception in interrupt
>>> drm_kms_helper: panic occurred, switching back to text console
>>
>
^ permalink raw reply
* Re: [PATCH v3] brcmsmac: Fix WARNING caused by lack of calls to dma_mapping_error()
From: Larry Finger @ 2013-08-10 15:19 UTC (permalink / raw)
To: Arend van Spriel
Cc: John W. Linville, linux-wireless, Brett Rudley,
Franky (Zhenhui) Lin, Hante Meuleman, brcm80211-dev-list, Stable
In-Reply-To: <5205F19E.6060907@broadcom.com>
On 08/10/2013 02:54 AM, Arend van Spriel wrote:
> On 08/10/13 00:05, Larry Finger wrote:
>> On 08/09/2013 12:36 PM, John W. Linville wrote:
>>> From: "John W. Linville" <linville@tuxdriver.com>
>>>
>>> The driver fails to check the results of DMA mapping in twp places,
>>> which results in the following warning:
>>>
>>> [ 28.078515] ------------[ cut here ]------------
>>> [ 28.078529] WARNING: at lib/dma-debug.c:937 check_unmap+0x47e/0x930()
>>> [ 28.078533] bcma-pci-bridge 0000:0e:00.0: DMA-API: device driver
>>> failed to check map error[device address=0x00000000b5d60d6c]
>>> [size=1876 bytes] [mapped as
>>> single]
>>> [ 28.078536] Modules linked in: bnep bluetooth vboxpci(O)
>>> vboxnetadp(O) vboxnetflt(O) vboxdrv(O) ipv6 b43 brcmsmac rtl8192cu
>>> rtl8192c_common rtlwifi mac802
>>> 11 brcmutil cfg80211 snd_hda_codec_conexant rng_core snd_hda_intel
>>> kvm_amd snd_hda_codec ssb kvm mmc_core snd_pcm snd_seq snd_timer
>>> snd_seq_device snd k8temp
>>> cordic joydev serio_raw hwmon sr_mod sg pcmcia pcmcia_core soundcore
>>> cdrom i2c_nforce2 i2c_core forcedeth bcma snd_page_alloc autofs4 ext4
>>> jbd2 mbcache crc1
>>> 6 scsi_dh_alua scsi_dh_hp_sw scsi_dh_rdac scsi_dh_emc scsi_dh
>>> ata_generic pata_amd
>>> [ 28.078602] CPU: 1 PID: 2570 Comm: NetworkManager Tainted: G O
>>> 3.10.0-rc7-wl+ #42
>>> [ 28.078605] Hardware name: Hewlett-Packard HP Pavilion dv2700
>>> Notebook PC/30D6, BIOS F.27 11/27/2008
>>> [ 28.078607] 0000000000000009 ffff8800bbb03ad8 ffffffff8144f898
>>> ffff8800bbb03b18
>>> [ 28.078612] ffffffff8103e1eb 0000000000000002 ffff8800b719f480
>>> ffff8800b7b9c010
>>> [ 28.078617] ffffffff824204c0 ffffffff81754d57 0000000000000754
>>> ffff8800bbb03b78
>>> [ 28.078622] Call Trace:
>>> [ 28.078624] <IRQ> [<ffffffff8144f898>] dump_stack+0x19/0x1b
>>> [ 28.078634] [<ffffffff8103e1eb>] warn_slowpath_common+0x6b/0xa0
>>> [ 28.078638] [<ffffffff8103e2c1>] warn_slowpath_fmt+0x41/0x50
>>> [ 28.078650] [<ffffffff8122d7ae>] check_unmap+0x47e/0x930
>>> [ 28.078655] [<ffffffff8122de4c>] debug_dma_unmap_page+0x5c/0x70
>>> [ 28.078679] [<ffffffffa04a808c>] dma64_getnextrxp+0x10c/0x190 [brcmsmac]
>>> [ 28.078691] [<ffffffffa04a9042>] dma_rx+0x62/0x240 [brcmsmac]
>>> [ 28.078707] [<ffffffffa0479101>] brcms_c_dpc+0x211/0x9d0 [brcmsmac]
>>> [ 28.078717] [<ffffffffa046d927>] ? brcms_dpc+0x27/0xf0 [brcmsmac]
>>> [ 28.078731] [<ffffffffa046d947>] brcms_dpc+0x47/0xf0 [brcmsmac]
>>> [ 28.078736] [<ffffffff81047dcc>] tasklet_action+0x6c/0xf0
>>> --snip--
>>> [ 28.078974] [<ffffffff813891bd>] SyS_sendmsg+0xd/0x20
>>> [ 28.078979] [<ffffffff81455c24>] tracesys+0xdd/0xe2
>>> [ 28.078982] ---[ end trace 6164d1a08148e9c8 ]---
>>> [ 28.078984] Mapped at:
>>> [ 28.078985] [<ffffffff8122c8fd>] debug_dma_map_page+0x9d/0x150
>>> [ 28.078989] [<ffffffffa04a9322>] dma_rxfill+0x102/0x3d0 [brcmsmac]
>>> [ 28.079001] [<ffffffffa047a13d>] brcms_c_init+0x87d/0x1100 [brcmsmac]
>>> [ 28.079010] [<ffffffffa046d851>] brcms_init+0x21/0x30 [brcmsmac]
>>> [ 28.079018] [<ffffffffa04786e0>] brcms_c_up+0x150/0x430 [brcmsmac]
>>>
>>> As the patch adds a new failure mechanism to dma_rxfill(). When I
>>> changed the
>>> comment at the start of the routine to add that information, I also
>>> polished
>>> the wording.
>>>
>>> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
>>> Cc: Stable <stable@vger.kernel.org>
>>> Cc: Brett Rudley <brudley@broadcom.com>
>>> Cc: Arend van Spriel <arend@broadcom.com>
>>> Cc: Franky (Zhenhui) Lin <frankyl@broadcom.com>
>>> Cc: Hante Meuleman <meuleman@broadcom.com>
>>> Cc: brcm80211-dev-list@broadcom.com
>>> Signed-off-by: John W. Linville <linville@tuxdriver.com>
>>> ---
>>> Did this one get lost?
>>>
>>> V2 - fixed two patch errors.
>>> V3 - address comments from Arend (linville)
>>>
>>
>> For some reason, I never got the mail containing Arend's comments, and I
>> forgot about it. If John's V3 fixes take care of them, then it should be
>> pushed.
>
> Weird as I resend the comments. Do you have me on a blacklist ;-)
No. As you can see, this message came through. I also checked to make sure that
my intermediate mailer had not put your message in its spam bucket.
Larry
^ permalink raw reply
* [PATCH 2/2] ath9k: shrink a few data structures by reordering fields
From: Felix Fietkau @ 2013-08-10 13:59 UTC (permalink / raw)
To: linux-wireless; +Cc: linville
In-Reply-To: <1376143156-74164-1-git-send-email-nbd@openwrt.org>
Also reduce the size of a few fields where possible
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
drivers/net/wireless/ath/ath9k/ath9k.h | 12 ++++++------
drivers/net/wireless/ath/ath9k/xmit.c | 16 ++++++++--------
2 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
index 0d69b13..7b1d036 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -72,7 +72,6 @@ struct ath_config {
/*************************/
#define ATH_TXBUF_RESET(_bf) do { \
- (_bf)->bf_stale = false; \
(_bf)->bf_lastbf = NULL; \
(_bf)->bf_next = NULL; \
memset(&((_bf)->bf_state), 0, \
@@ -192,10 +191,10 @@ struct ath_txq {
struct ath_atx_ac {
struct ath_txq *txq;
- int sched;
struct list_head list;
struct list_head tid_q;
bool clear_ps_filter;
+ bool sched;
};
struct ath_frame_info {
@@ -212,6 +211,7 @@ struct ath_buf_state {
u8 bf_type;
u8 bfs_paprd;
u8 ndelim;
+ bool stale;
u16 seqno;
unsigned long bfs_paprd_timestamp;
};
@@ -225,7 +225,6 @@ struct ath_buf {
void *bf_desc; /* virtual addr of desc */
dma_addr_t bf_daddr; /* physical addr of desc */
dma_addr_t bf_buf_addr; /* physical addr of data buffer, for DMA */
- bool bf_stale;
struct ieee80211_tx_rate rates[4];
struct ath_buf_state bf_state;
};
@@ -237,13 +236,14 @@ struct ath_atx_tid {
struct ath_node *an;
struct ath_atx_ac *ac;
unsigned long tx_buf[BITS_TO_LONGS(ATH_TID_MAX_BUFS)];
- int bar_index;
u16 seq_start;
u16 seq_next;
u16 baw_size;
- int tidno;
+ u8 tidno;
int baw_head; /* first un-acked tx buffer */
int baw_tail; /* next unused tx buffer slot */
+
+ s8 bar_index;
bool sched;
bool paused;
bool active;
@@ -255,10 +255,10 @@ struct ath_node {
struct ieee80211_vif *vif; /* interface with which we're associated */
struct ath_atx_tid tid[IEEE80211_NUM_TIDS];
struct ath_atx_ac ac[IEEE80211_NUM_ACS];
- int ps_key;
u16 maxampdu;
u8 mpdudensity;
+ s8 ps_key;
bool sleeping;
bool no_ps_filter;
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index d8dfb3e..4fc80e3 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -493,7 +493,7 @@ static void ath_tx_complete_aggr(struct ath_softc *sc, struct ath_txq *txq,
while (bf) {
bf_next = bf->bf_next;
- if (!bf->bf_stale || bf_next != NULL)
+ if (!bf->bf_state.stale || bf_next != NULL)
list_move_tail(&bf->list, &bf_head);
ath_tx_complete_buf(sc, bf, txq, &bf_head, ts, 0);
@@ -586,7 +586,7 @@ static void ath_tx_complete_aggr(struct ath_softc *sc, struct ath_txq *txq,
* not a holding desc.
*/
INIT_LIST_HEAD(&bf_head);
- if (bf_next != NULL || !bf_last->bf_stale)
+ if (bf_next != NULL || !bf_last->bf_state.stale)
list_move_tail(&bf->list, &bf_head);
if (!txpending) {
@@ -610,7 +610,7 @@ static void ath_tx_complete_aggr(struct ath_softc *sc, struct ath_txq *txq,
ieee80211_sta_eosp(sta);
}
/* retry the un-acked ones */
- if (bf->bf_next == NULL && bf_last->bf_stale) {
+ if (bf->bf_next == NULL && bf_last->bf_state.stale) {
struct ath_buf *tbf;
tbf = ath_clone_txbuf(sc, bf_last);
@@ -1734,7 +1734,7 @@ static void ath_drain_txq_list(struct ath_softc *sc, struct ath_txq *txq,
while (!list_empty(list)) {
bf = list_first_entry(list, struct ath_buf, list);
- if (bf->bf_stale) {
+ if (bf->bf_state.stale) {
list_del(&bf->list);
ath_tx_return_buffer(sc, bf);
@@ -2490,7 +2490,7 @@ static void ath_tx_processq(struct ath_softc *sc, struct ath_txq *txq)
* it with the STALE flag.
*/
bf_held = NULL;
- if (bf->bf_stale) {
+ if (bf->bf_state.stale) {
bf_held = bf;
if (list_is_last(&bf_held->list, &txq->axq_q))
break;
@@ -2514,7 +2514,7 @@ static void ath_tx_processq(struct ath_softc *sc, struct ath_txq *txq)
* however leave the last descriptor back as the holding
* descriptor for hw.
*/
- lastbf->bf_stale = true;
+ lastbf->bf_state.stale = true;
INIT_LIST_HEAD(&bf_head);
if (!list_is_singular(&lastbf->list))
list_cut_position(&bf_head,
@@ -2585,7 +2585,7 @@ void ath_tx_edma_tasklet(struct ath_softc *sc)
}
bf = list_first_entry(fifo_list, struct ath_buf, list);
- if (bf->bf_stale) {
+ if (bf->bf_state.stale) {
list_del(&bf->list);
ath_tx_return_buffer(sc, bf);
bf = list_first_entry(fifo_list, struct ath_buf, list);
@@ -2607,7 +2607,7 @@ void ath_tx_edma_tasklet(struct ath_softc *sc)
ath_tx_txqaddbuf(sc, txq, &bf_q, true);
}
} else {
- lastbf->bf_stale = true;
+ lastbf->bf_state.stale = true;
if (bf != lastbf)
list_cut_position(&bf_head, fifo_list,
lastbf->list.prev);
--
1.8.0.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox