* Re: [ath9k-devel] [PATCH] ath10k: Fix crash when using v1 hardware.
From: Ben Greear @ 2013-07-11 15:05 UTC (permalink / raw)
To: Kalle Valo; +Cc: ath10k, linux-wireless
In-Reply-To: <87y59d5tgu.fsf@kamboji.qca.qualcomm.com>
On 07/11/2013 02:36 AM, Kalle Valo wrote:
> greearb@candelatech.com writes:
>
>> From: Ben Greear <greearb@candelatech.com>
>>
>> I put a v1 NIC from an TP-LINK AC 1750 AP in
>> a 64-bit PC, and the OS crashes on bootup. I'm not
>> sure how broken my hardware is (possibly completely non
>> functional), but at least with this patch it will no longer
>> crash the OS. Not sure it ever got far enough to try,
>> but I also do not have firmware for the NIC.
>>
>> With this patch I get this info on module load:
>>
>> ath10k_pci 0000:05:00.0: BAR 0: assigned [mem 0xf4400000-0xf45fffff 64bit]
>> ath10k_pci 0000:05:00.0: BAR 0: error updating (0xf4400004 != 0xffffffff)
>> ath10k_pci 0000:05:00.0: BAR 0: error updating (high 0x000000 != 0xffffffff)
>> ath10k_pci 0000:05:00.0: Refused to change power state, currently in D3
>> ath10k: MSI-X interrupt handling (8 intrs)
>> ath10k: Unable to wakeup target
>> ath10k: target takes too long to wake up (awake count 1)
>> ath10k: src_ring ffff88020c0d0a00: write_index is out of bounds: 4294967295 nentries_mask: 15.
>> ath10k: dest_ring ffff88020db2c000: write_index is out of bounds: 4294967295 nentries_mask: 511.
>> ath10k: dest_ring ffff880210d56400: write_index is out of bounds: 4294967295 nentries_mask: 31.
>> ath10k: src_ring ffff880210d57600: write_index is out of bounds: 4294967295 nentries_mask: 31.
>> ath10k: src_ring ffff88020fe70000: write_index is out of bounds: 4294967295 nentries_mask: 2047.
>> ath10k: src_ring ffff880212989b40: write_index is out of bounds: 4294967295 nentries_mask: 1.
>> ath10k: dest_ring ffff880212989960: write_index is out of bounds: 4294967295 nentries_mask: 1.
>> ath10k: Failed to get pcie state addr: -5
>> ath10k: early firmware event indicated
>> ------------[ cut here ]------------
>> WARNING: at /home/greearb/git/linux.wireless-testing/drivers/net/wireless/ath/ath10k/ce.c:771 ath10k_ce_per_engine_service+0x53/0x1b4 [ath10k_pci]()
>> ....
>> (it hits the warning case about 5-6 times and then seems to quiesce OK).
>
> I haven't seen this myself so it might be a hw problem, but difficult to
> say.
>
>> + /* On v1 hardware at least, setup can fail, causing ce_id_state to
>> + * be cleaned up, but this method is still called a few times. Check
>> + * for NULL here so we don't crash. Probably a better fix is to stop
>> + * the ath10k_pci_ce_tasklet sooner.
>> + */
>> + if (WARN_ONCE(!ce_state, "ce_id_to_state[%i] is NULL\n", ce_id))
>> + return;
>> +
>> + ctrl_addr = ce_state->ctrl_addr;
>> +
>
> The tests you add look like workarounds. I would prefer to try fix these
> by going to the source of the problem. Maybe we should add
> ath10k_pci_wake() and ath10k_do_pci_wake()?
These are work-arounds, but you should not let a bad piece of hardware/firmware crash
the entire OS just because you don't want to do sanity checking on the
values you get from the firmware. Perhaps there is a better fix for the
code above, but the warning splat should still provide incentive to get
it right, while not crashing the OS in the meantime.
> Can you enable few debug logs, like ATH10K_DBG_PCI, and post them? That
> would give more hint there things are going wrong.
Yes, I can do that.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [ath9k-devel] [PATCH] ath10k: Fix crash when using v1 hardware.
From: Ben Greear @ 2013-07-11 15:06 UTC (permalink / raw)
To: Kalle Valo; +Cc: ath10k, linux-wireless
In-Reply-To: <87txk15te4.fsf@kamboji.qca.qualcomm.com>
On 07/11/2013 02:37 AM, Kalle Valo wrote:
> Ben Greear <greearb@candelatech.com> writes:
>
>> Actually, I have no idea what type of hardware this is. It was
>> suggested earlier to me that this AP had a v1 hardware in it, but
>> lspci shows this fairly unpromising thing, and the ath10k driver
>> appears to call 003c the V2 hardware....
>>
>> 05:00.0 Network controller: Atheros Communications Inc. Device 003c (rev ff) (prog-if ff)
>> !!! Unknown header type 7f
>> Kernel modules: ath10k_pci
>
> That unknown header type looks scary. I'm starting to suspect even more
> that you have a hw problem of some sort.
I tried two different NICS extracted from two different APs and the behaviour
is the same, so it is probably not just a manufacturing error.
Please note that I do NOT have v1 firmware, though from what I could tell,
this NIC was showing up as v2 hardware anyway...
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* [PATCH 1/5] wil6210: Align WMI header with latest FW
From: Vladimir Kondratiev @ 2013-07-11 15:03 UTC (permalink / raw)
To: John W . Linville
Cc: Kirshenbaum Erez, Vladimir Kondratiev, linux-wireless,
Luis R . Rodriguez
In-Reply-To: <1373555021-11763-1-git-send-email-qca_vkondrat@qca.qualcomm.com>
FW guys changed header structure; align driver code
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
---
drivers/net/wireless/ath/wil6210/trace.h | 22 +++++++++++++---------
drivers/net/wireless/ath/wil6210/wil6210.h | 17 ++++++++++++++---
drivers/net/wireless/ath/wil6210/wmi.c | 14 +++++++++-----
3 files changed, 36 insertions(+), 17 deletions(-)
diff --git a/drivers/net/wireless/ath/wil6210/trace.h b/drivers/net/wireless/ath/wil6210/trace.h
index eff1239..e59239d 100644
--- a/drivers/net/wireless/ath/wil6210/trace.h
+++ b/drivers/net/wireless/ath/wil6210/trace.h
@@ -37,36 +37,40 @@ static inline void trace_ ## name(proto) {}
#endif /* !CONFIG_WIL6210_TRACING || defined(__CHECKER__) */
DECLARE_EVENT_CLASS(wil6210_wmi,
- TP_PROTO(u16 id, void *buf, u16 buf_len),
+ TP_PROTO(struct wil6210_mbox_hdr_wmi *wmi, void *buf, u16 buf_len),
- TP_ARGS(id, buf, buf_len),
+ TP_ARGS(wmi, buf, buf_len),
TP_STRUCT__entry(
+ __field(u8, mid)
__field(u16, id)
+ __field(u32, timestamp)
__field(u16, buf_len)
__dynamic_array(u8, buf, buf_len)
),
TP_fast_assign(
- __entry->id = id;
+ __entry->mid = wmi->mid;
+ __entry->id = le16_to_cpu(wmi->id);
+ __entry->timestamp = le32_to_cpu(wmi->timestamp);
__entry->buf_len = buf_len;
memcpy(__get_dynamic_array(buf), buf, buf_len);
),
TP_printk(
- "id 0x%04x len %d",
- __entry->id, __entry->buf_len
+ "MID %d id 0x%04x len %d timestamp %d",
+ __entry->mid, __entry->id, __entry->buf_len, __entry->timestamp
)
);
DEFINE_EVENT(wil6210_wmi, wil6210_wmi_cmd,
- TP_PROTO(u16 id, void *buf, u16 buf_len),
- TP_ARGS(id, buf, buf_len)
+ TP_PROTO(struct wil6210_mbox_hdr_wmi *wmi, void *buf, u16 buf_len),
+ TP_ARGS(wmi, buf, buf_len)
);
DEFINE_EVENT(wil6210_wmi, wil6210_wmi_event,
- TP_PROTO(u16 id, void *buf, u16 buf_len),
- TP_ARGS(id, buf, buf_len)
+ TP_PROTO(struct wil6210_mbox_hdr_wmi *wmi, void *buf, u16 buf_len),
+ TP_ARGS(wmi, buf, buf_len)
);
#define WIL6210_MSG_MAX (200)
diff --git a/drivers/net/wireless/ath/wil6210/wil6210.h b/drivers/net/wireless/ath/wil6210/wil6210.h
index 44fdab5..129c480 100644
--- a/drivers/net/wireless/ath/wil6210/wil6210.h
+++ b/drivers/net/wireless/ath/wil6210/wil6210.h
@@ -156,11 +156,22 @@ struct wil6210_mbox_hdr {
/* max. value for wil6210_mbox_hdr.len */
#define MAX_MBOXITEM_SIZE (240)
+/**
+ * struct wil6210_mbox_hdr_wmi - WMI header
+ *
+ * @mid: MAC ID
+ * 00 - default, created by FW
+ * 01..0f - WiFi ports, driver to create
+ * 10..fe - debug
+ * ff - broadcast
+ * @id: command/event ID
+ * @timestamp: FW fills for events, free-running msec timer
+ */
struct wil6210_mbox_hdr_wmi {
- u8 reserved0[2];
+ u8 mid;
+ u8 reserved;
__le16 id;
- __le16 info1; /* bits [0..3] - device_id, rest - unused */
- u8 reserved1[2];
+ __le32 timestamp;
} __packed;
struct pending_wmi_event {
diff --git a/drivers/net/wireless/ath/wil6210/wmi.c b/drivers/net/wireless/ath/wil6210/wmi.c
index dc8059a..a62511a 100644
--- a/drivers/net/wireless/ath/wil6210/wmi.c
+++ b/drivers/net/wireless/ath/wil6210/wmi.c
@@ -172,8 +172,8 @@ static int __wmi_send(struct wil6210_priv *wil, u16 cmdid, void *buf, u16 len)
.len = cpu_to_le16(sizeof(cmd.wmi) + len),
},
.wmi = {
+ .mid = 0,
.id = cpu_to_le16(cmdid),
- .info1 = 0,
},
};
struct wil6210_mbox_ring *r = &wil->mbox_ctl.tx;
@@ -248,7 +248,7 @@ static int __wmi_send(struct wil6210_priv *wil, u16 cmdid, void *buf, u16 len)
iowrite32(r->head = next_head, wil->csr + HOST_MBOX +
offsetof(struct wil6210_mbox_ctl, tx.head));
- trace_wil6210_wmi_cmd(cmdid, buf, len);
+ trace_wil6210_wmi_cmd(&cmd.wmi, buf, len);
/* interrupt to FW */
iowrite32(SW_INT_MBOX, wil->csr + HOST_SW_INT);
@@ -640,9 +640,13 @@ void wmi_recv_cmd(struct wil6210_priv *wil)
hdr.flags);
if ((hdr.type == WIL_MBOX_HDR_TYPE_WMI) &&
(len >= sizeof(struct wil6210_mbox_hdr_wmi))) {
- u16 id = le16_to_cpu(evt->event.wmi.id);
- wil_dbg_wmi(wil, "WMI event 0x%04x\n", id);
- trace_wil6210_wmi_event(id, &evt->event.wmi, len);
+ struct wil6210_mbox_hdr_wmi *wmi = &evt->event.wmi;
+ u16 id = le16_to_cpu(wmi->id);
+ u32 tstamp = le32_to_cpu(wmi->timestamp);
+ wil_dbg_wmi(wil, "WMI event 0x%04x MID %d @%d msec\n",
+ id, wmi->mid, tstamp);
+ trace_wil6210_wmi_event(wmi, &wmi[1],
+ len - sizeof(*wmi));
}
wil_hex_dump_wmi("evt ", DUMP_PREFIX_OFFSET, 16, 1,
&evt->event.hdr, sizeof(hdr) + len, true);
--
1.8.1.2
^ permalink raw reply related
* Re: [WT PATCH 6/6] mac80211: Tell user why beacons fail to parse.
From: Ben Greear @ 2013-07-11 15:10 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1373533184.8201.8.camel@jlt4.sipsolutions.net>
On 07/11/2013 01:59 AM, Johannes Berg wrote:
> On Sat, 2013-06-29 at 15:58 -0700, greearb@candelatech.com wrote:
>> From: Ben Greear <greearb@candelatech.com>
>>
>> Should help better debug dodgy APs and such.
>
> This isn't a bad idea, but I think instead of storing the message:
>
>> @@ -110,6 +110,7 @@ struct ieee80211_bss {
>>
>> /* Keep track of what bits of information we have valid info for. */
>> u8 valid_data;
>> + char corrupt_elems_msg[80];
>
> you should store a "what's bad" type field and the broken IE number or
> so, to reduce memory usage
I thought of this, but the problem is then you cannot tell the details
(for instance the actual lengths when length is bad, the ID that is duplicated, etc).
I figure if we are going to provide the info to the user, we might as well
be specific about it.
>> + snprintf(elems->parse_err_msg,
>> + sizeof(elems->parse_err_msg),
>> + "seen id: %i already", id);
>
> Your snprintf() usage is also unsafe.
What is unsafe about it?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [WT PATCH 6/6] mac80211: Tell user why beacons fail to parse.
From: Johannes Berg @ 2013-07-11 15:17 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless
In-Reply-To: <51DECAFD.8070608@candelatech.com>
On Thu, 2013-07-11 at 08:10 -0700, Ben Greear wrote:
> >> /* Keep track of what bits of information we have valid info for. */
> >> u8 valid_data;
> >> + char corrupt_elems_msg[80];
> >
> > you should store a "what's bad" type field and the broken IE number or
> > so, to reduce memory usage
>
> I thought of this, but the problem is then you cannot tell the details
> (for instance the actual lengths when length is bad, the ID that is duplicated, etc).
> I figure if we are going to provide the info to the user, we might as well
> be specific about it.
It doesn't seem so difficult?
enum ies_parse_error {
NO_ERROR,
BAD_IE_LEN, // uses eid+len
DUPLICATE_IE, // uses eid
...
} parse_error;
int parse_error_eid, parse_error_len;
> >> + snprintf(elems->parse_err_msg,
> >> + sizeof(elems->parse_err_msg),
> >> + "seen id: %i already", id);
> >
> > Your snprintf() usage is also unsafe.
>
> What is unsafe about it?
using printk("%s", result) is unsafe due to potentially missing
NUL-termination.
johannes
^ permalink raw reply
* Re: [WT PATCH 4/6] mac80211: Add per-sdata station hash, and sdata hash.
From: Ben Greear @ 2013-07-11 15:29 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1373532936.8201.5.camel@jlt4.sipsolutions.net>
On 07/11/2013 01:55 AM, Johannes Berg wrote:
> On Sat, 2013-06-29 at 15:58 -0700, greearb@candelatech.com wrote:
>> From: Ben Greear <greearb@candelatech.com>
>>
>> Add sdata hash (based on sdata->vif.addr) to local
>> structure.
>>
>> Add sta_vhash (based on sta->sta.addr) to sdata struct.
>>
>> Make STA_HASH give a better hash spread more often.
>>
>> Use new hashes where we can. Might be able to completely
>> get rid of the local->sta_hash, but didn't want to try that
>> quite yet.
>>
>> This significantly improves performance when using lots
>> of station VIFs connected to the same AP. It will likely
>> help other cases where the old hash logic failed to create
>> a decent spread.
>
> I think this is too much code for a corner case unlikely to happen
> outside of your specific scenario, so I'm not taking this either.
>
> I also don't like maintaining two separate hash tables and all that.
>
> I'd reconsider if you actually remove the hash entirely, but that'll be
> tricky to walk the station list and will quite possibly make the RX path
> there more expensive?
Remove local->sta_hash ?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* [PATCH] mac80211: fix regression when initializing ibss wmm params
From: Simon Wunderlich @ 2013-07-11 16:07 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Simon Wunderlich
There appear to be two regressions in ibss.c when calling
ieee80211_sta_def_wmm_params():
* the second argument should be a rate length, not a rate array. This
was introduced by my commit "mac80211: select and adjust bitrates
according to channel mode"
* the third argument is not initialized (anymore), making further
checks within this function useless.
Since ieee80211_sta_def_wmm_params() is only used by ibss anyway,
remove the function entirely and handle the operating mode decision
immediately.
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
---
net/mac80211/ibss.c | 12 ++++++++++--
net/mac80211/ieee80211_i.h | 3 ---
net/mac80211/util.c | 26 --------------------------
3 files changed, 10 insertions(+), 31 deletions(-)
diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
index 449702d..83197c3 100644
--- a/net/mac80211/ibss.c
+++ b/net/mac80211/ibss.c
@@ -49,9 +49,9 @@ static void __ieee80211_sta_join_ibss(struct ieee80211_sub_if_data *sdata,
struct ieee80211_supported_band *sband;
struct cfg80211_bss *bss;
u32 bss_change, rate_flags, rates = 0, rates_added = 0;
- u8 supp_rates[IEEE80211_MAX_SUPP_RATES];
struct cfg80211_chan_def chandef;
enum nl80211_bss_scan_width scan_width;
+ bool have_higher_than_11mbit = false;
struct beacon_data *presp;
int frame_len;
int shift;
@@ -149,6 +149,8 @@ static void __ieee80211_sta_join_ibss(struct ieee80211_sub_if_data *sdata,
for (i = 0; i < sband->n_bitrates; i++) {
if ((rate_flags & sband->bitrates[i].flags) != rate_flags)
continue;
+ if (sband->bitrates[i].bitrate > 110)
+ have_higher_than_11mbit = true;
rates |= BIT(i);
rates_n++;
@@ -270,11 +272,17 @@ static void __ieee80211_sta_join_ibss(struct ieee80211_sub_if_data *sdata,
sdata->vif.bss_conf.use_short_slot = chan->band == IEEE80211_BAND_5GHZ;
bss_change |= BSS_CHANGED_ERP_SLOT;
+ /* cf. IEEE 802.11 9.2.12 */
+ if (chan->band == IEEE80211_BAND_2GHZ && have_higher_than_11mbit)
+ sdata->flags |= IEEE80211_SDATA_OPERATING_GMODE;
+ else
+ sdata->flags &= ~IEEE80211_SDATA_OPERATING_GMODE;
+
sdata->vif.bss_conf.ibss_joined = true;
sdata->vif.bss_conf.ibss_creator = creator;
ieee80211_bss_info_change_notify(sdata, bss_change);
- ieee80211_sta_def_wmm_params(sdata, rates, supp_rates);
+ ieee80211_set_wmm_default(sdata, true);
ifibss->state = IEEE80211_IBSS_MLME_JOINED;
mod_timer(&ifibss->timer,
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 23a191b..3d32df1 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1615,9 +1615,6 @@ void ieee80211_send_probe_req(struct ieee80211_sub_if_data *sdata, u8 *dst,
u32 ratemask, bool directed, u32 tx_flags,
struct ieee80211_channel *channel, bool scan);
-void ieee80211_sta_def_wmm_params(struct ieee80211_sub_if_data *sdata,
- const size_t supp_rates_len,
- const u8 *supp_rates);
u32 ieee80211_sta_get_rates(struct ieee80211_sub_if_data *sdata,
struct ieee802_11_elems *elems,
enum ieee80211_band band, u32 *basic_rates);
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 1e45891c..d23c5a7 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -1073,32 +1073,6 @@ void ieee80211_set_wmm_default(struct ieee80211_sub_if_data *sdata,
}
}
-void ieee80211_sta_def_wmm_params(struct ieee80211_sub_if_data *sdata,
- const size_t supp_rates_len,
- const u8 *supp_rates)
-{
- struct ieee80211_chanctx_conf *chanctx_conf;
- int i, have_higher_than_11mbit = 0;
-
- /* cf. IEEE 802.11 9.2.12 */
- for (i = 0; i < supp_rates_len; i++)
- if ((supp_rates[i] & 0x7f) * 5 > 110)
- have_higher_than_11mbit = 1;
-
- rcu_read_lock();
- chanctx_conf = rcu_dereference(sdata->vif.chanctx_conf);
-
- if (chanctx_conf &&
- chanctx_conf->def.chan->band == IEEE80211_BAND_2GHZ &&
- have_higher_than_11mbit)
- sdata->flags |= IEEE80211_SDATA_OPERATING_GMODE;
- else
- sdata->flags &= ~IEEE80211_SDATA_OPERATING_GMODE;
- rcu_read_unlock();
-
- ieee80211_set_wmm_default(sdata, true);
-}
-
void ieee80211_send_auth(struct ieee80211_sub_if_data *sdata,
u16 transaction, u16 auth_alg, u16 status,
const u8 *extra, size_t extra_len, const u8 *da,
--
1.7.10.4
^ permalink raw reply related
* Help adding trace events to xHCI
From: Sarah Sharp @ 2013-07-11 16:20 UTC (permalink / raw)
To: Xenia Ragiadakou
Cc: OPW Kernel Interns List, linux-usb, linux-wireless, Kalle Valo
In-Reply-To: <51DB0257.1010709@gmail.com>
On Mon, Jul 08, 2013 at 09:17:59PM +0300, Xenia Ragiadakou wrote:
> Hi Sarah,
Hi Xenia,
Comments below.
(Mentors and wireless folks, we're struggling a bit with adding trace
events to the xHCI USB host controller driver. I'm trying to look at
the ath6kl driver trace events as an example. We could use some help
and/or advice.)
> lets say that we want the tracepoint function to have the prototype:
>
> void trace_cmd_address_device(const char *fmt, ...).
>
> That internally will be implemented as:
>
> void trace_cmd_address_device(const char *fmt, ...)
> {
> if (trace event cmd_address_device is enabled) do {
> [...some other code will run here]
> (void(*)(const char *fmt, ...)) callback (fmt, '
> ' <-- we need to pass args here);
> }
> }
>
> callback will be the function that we actually intend to run and
> which we define when we define the trace_event. This function
> we want to create a string from fmt and the args and copy it
> into the ring buffer.
>
> The only way to pass the args into this function is by doing
> the following:
>
> Note: remember that the callback and tracepoint functions must
> have the same prototype.
>
> void trace_cmd_address_device(void *ptr, const char *fmt, ...)
> {
> if (trace event cmd_address_device is enabled) do {
> [...some other code will run here]
> va_list args;
> va_start(args, fmt);
> (void(*)(void *ptr, const char *fmt, ...))
> callback (args, fmt);
> va_end(args);
> }
> }
Right, that looks pretty similar to what's defined in
drivers/net/wireless/ath/ath6kl/trace.h. (Note that I'm working on the
very latest Linux kernel, so you may need to `git fetch` Greg KH's USB
tree, and rebase against the usb-next branch.)
> But, that cannot be done because the current tracing framework does not
> give a means to add code outside the callback.
I'm confused about why you need to add more code. Here's how I
understand the code works, so please correct me if I misinterpreted the
code.
The ath driver defines a new trace event class, ath6kl_log_event.
Various types of tracepoints, like trace_ath6kl_log_warn, use that event
class. Wrappers like ath6kl_warn() call those trace points, passing it
a struct va_format on the stack:
int ath6kl_warn(const char *fmt, ...)
{
struct va_format vaf = {
.fmt = fmt,
};
va_list args;
int ret;
va_start(args, fmt);
vaf.va = &args;
ret = ath6kl_printk(KERN_WARNING, "%pV", &vaf);
trace_ath6kl_log_warn(&vaf);
va_end(args);
return ret;
}
EXPORT_SYMBOL(ath6kl_warn);
trace_ath6kl_log_warn() uses the log event class:
DEFINE_EVENT(ath6kl_log_event, ath6kl_log_warn,
TP_PROTO(struct va_format *vaf),
TP_ARGS(vaf)
);
DECLARE_EVENT_CLASS(ath6kl_log_event,
TP_PROTO(struct va_format *vaf),
TP_ARGS(vaf),
TP_STRUCT__entry(
__dynamic_array(char, msg, ATH6KL_MSG_MAX)
),
TP_fast_assign(
WARN_ON_ONCE(vsnprintf(__get_dynamic_array(msg),
ATH6KL_MSG_MAX,
vaf->fmt,
*vaf->va) >= ATH6KL_MSG_MAX);
),
TP_printk("%s", __get_str(msg))
);
And then the code in files like drivers/net/wireless/ath6kl/cfg80211.c
can simply make what look like printk calls to ath6kl_warn:
ath6kl_warn("clear wmi ctrl data failed: %d\n", left);
I think that we can apply a similar technique to define trace events for
the xhci debugging that's printed when we're issuing a Set Address
command. Something like:
int xhci_debug_address(const char *fmt, ...)
{
struct va_format vaf = {
.fmt = fmt,
};
va_list args;
int ret;
va_start(args, fmt);
vaf.va = &args;
ret = xhci_printk(KERN_WARNING, "%pV", &vaf);
trace_xhci_dbg_address(&vaf);
va_end(args);
return ret;
}
EXPORT_SYMBOL(xhci_debug_address);
DEFINE_EVENT(xhci_log_event, xhci_dbg_address,
TP_PROTO(struct va_format *vaf),
TP_ARGS(vaf)
);
DECLARE_EVENT_CLASS(xhci_log_event,
TP_PROTO(struct va_format *vaf),
TP_ARGS(vaf),
TP_STRUCT__entry(
__dynamic_array(char, msg, ATH6KL_MSG_MAX)
),
TP_fast_assign(
WARN_ON_ONCE(vsnprintf(__get_dynamic_array(msg),
ATH6KL_MSG_MAX,
vaf->fmt,
*vaf->va) >= ATH6KL_MSG_MAX);
),
TP_printk("%s", __get_str(msg))
);
And then code in xhci_address_device() in drivers/usb/host/xhci.c can do
things like:
xhci_debug_address(xhci, "Bad Slot ID %d\n", udev->slot_id);
And we can define similar trace event classes for the various xHCI
commands or ring debugging, so that we can enable or disable trace
points individually for different parts of the xHCI driver.
Xenia, if this all something you've tried already, I apologize. :) I'm
just trying to understand how the trace event system works, and figure
out what the code should look like for the xHCI driver.
> The thing that i was trying to do, was to pass the pointer to the
> fmt on the stack.
> Something, like:
>
> void trace_cmd_address_device(const char *fmt, ...)
> {
> if (trace event cmd_address_device is enabled) do {
> [...some other code will run here]
> (void(*)(const char *fmt, ...)) callback ((const
> char *)&fmt);
> }
> }
>
> and then inside the callback to do:
>
> va_list args;
> va_start(args, *(char **)fmt);
> vsnprintf(msg_string, mesg_max_len, *(char **)fmt, args);
> va_end(args);
>
> That would have worked if the tracepoint was just :
>
> void trace_cmd_address_device(const char *fmt, ...)
> {
> if (trace event cmd_address_device is enabled) do {
> (void(*)(const char *fmt, ...)) callback ((const
> char *)&fmt);
> }
> }
>
> But when there are other function calls before the callback call, I don't
> no why but i cannot track anymore the position of the args following the
> fmt argumenent in the stack with the pointer to fmt.
I'm actually wondering if the call to ath6kl_printk is somehow necessary
in order to be able to pass arguments on the stack. Perhaps you should
try defining a similar function for xHCI and see if that helps?
int ath6kl_printk(const char *level, const char *fmt, ...)
{
struct va_format vaf;
va_list args;
int rtn;
va_start(args, fmt);
vaf.fmt = fmt;
vaf.va = &args;
rtn = printk("%sath6kl: %pV", level, &vaf);
va_end(args);
return rtn;
}
EXPORT_SYMBOL(ath6kl_printk);
> Anyway, something dirty like that will not enter the kernel but i will try
> to do stack debugging on an example program to see why that happens.
I would suggest just copy-pasting parts of the ath6kl trace code into
the xHCI driver, and changing one of the xhci_dbg() calls to use that
code, and see if it works. If it doesn't work, send out an RFC patch
(using the Cc list I've used), and we'll try to figure out what's going
wrong.
Sarah Sharp
^ permalink raw reply
* Re: Help adding trace events to xHCI
From: Arend van Spriel @ 2013-07-11 17:08 UTC (permalink / raw)
To: Sarah Sharp
Cc: Xenia Ragiadakou, OPW Kernel Interns List, linux-usb,
linux-wireless, Kalle Valo
In-Reply-To: <20130711162002.GA5240@xanatos>
On 07/11/2013 06:20 PM, Sarah Sharp wrote:
> On Mon, Jul 08, 2013 at 09:17:59PM +0300, Xenia Ragiadakou wrote:
>> But when there are other function calls before the callback call, I don't
>> no why but i cannot track anymore the position of the args following the
>> fmt argumenent in the stack with the pointer to fmt.
>
> I'm actually wondering if the call to ath6kl_printk is somehow necessary
> in order to be able to pass arguments on the stack. Perhaps you should
> try defining a similar function for xHCI and see if that helps?
The ath6klk_printk() is not related to the trace function. It is a
separate code path to get the message in the kernel log. I have seen
these constructs before (and implemented it in brcmfmac) but it seems
not very efficient when tracing as the printk can affect run-time behaviour.
> int ath6kl_printk(const char *level, const char *fmt, ...)
> {
> struct va_format vaf;
> va_list args;
> int rtn;
>
> va_start(args, fmt);
>
> vaf.fmt = fmt;
> vaf.va = &args;
>
> rtn = printk("%sath6kl: %pV", level, &vaf);
>
> va_end(args);
>
> return rtn;
> }
> EXPORT_SYMBOL(ath6kl_printk);
>
>> Anyway, something dirty like that will not enter the kernel but i will try
>> to do stack debugging on an example program to see why that happens.
>
> I would suggest just copy-pasting parts of the ath6kl trace code into
> the xHCI driver, and changing one of the xhci_dbg() calls to use that
> code, and see if it works. If it doesn't work, send out an RFC patch
> (using the Cc list I've used), and we'll try to figure out what's going
> wrong.
The biggest challenge in adding tracepoints is identifying what you want
to trace. While tracing debug messages can be convenient the real
strength is in tracing code artifacts like for USB the thing that comes
to my mind first is defining tracepoint for the urb and there are
probably other internals that are informational.
Regards,
Arend
^ permalink raw reply
* Re: Help adding trace events to xHCI
From: Johannes Berg @ 2013-07-11 17:08 UTC (permalink / raw)
To: Sarah Sharp
Cc: Xenia Ragiadakou, OPW Kernel Interns List, linux-usb,
linux-wireless, Kalle Valo, Steven Rostedt
In-Reply-To: <20130711162002.GA5240@xanatos>
[also adding Steven, he's the tracing expert after all :-)]
Hi Xenia, Sarah, all,
> (Mentors and wireless folks, we're struggling a bit with adding trace
> events to the xHCI USB host controller driver. I'm trying to look at
> the ath6kl driver trace events as an example. We could use some help
> and/or advice.)
Those were in turn modelled on mac80211, cfg80211 and/or iwlwifi, I
think; might be worth also looking there. In general though, it's all
pretty similar.
> > lets say that we want the tracepoint function to have the prototype:
> >
> > void trace_cmd_address_device(const char *fmt, ...).
I'm not sure this is possible. I think we (wireless) do this with
void trace_cmd_address_device(struct va_format *vaf)
instead only.
Note that there's no easy way to dynamically allocate the right amount
of space in the ringbuffer, or at least I haven't found one. We
therefore have a static size, which is somewhat inefficient.
> The ath driver defines a new trace event class, ath6kl_log_event.
> Various types of tracepoints, like trace_ath6kl_log_warn, use that event
> class. Wrappers like ath6kl_warn() call those trace points, passing it
> a struct va_format on the stack:
>
> int ath6kl_warn(const char *fmt, ...)
> {
> struct va_format vaf = {
> .fmt = fmt,
> };
> va_list args;
> int ret;
>
> va_start(args, fmt);
> vaf.va = &args;
> ret = ath6kl_printk(KERN_WARNING, "%pV", &vaf);
Note also on older kernels you used to have to do va_copy() here because
"%pV" didn't do it by itself. Guess you don't care though, but I
sometimes have to worry about backporting :-)
> int xhci_debug_address(const char *fmt, ...)
This confuses me somewhat -- why is it called "xhci_debug_address()"
when it takes arbitrary parameters? Where's the "address" part?
> DEFINE_EVENT(xhci_log_event, xhci_dbg_address,
> TP_PROTO(struct va_format *vaf),
> TP_ARGS(vaf)
> );
>
> DECLARE_EVENT_CLASS(xhci_log_event,
> TP_PROTO(struct va_format *vaf),
> TP_ARGS(vaf),
> TP_STRUCT__entry(
> __dynamic_array(char, msg, ATH6KL_MSG_MAX)
Should probably not be ATH6KL_MSG_MAX :-)
And this is what I talked about before -- it always allocates the max in
the ringbuffer even for really short messages.
> And then code in xhci_address_device() in drivers/usb/host/xhci.c can do
> things like:
>
> xhci_debug_address(xhci, "Bad Slot ID %d\n", udev->slot_id);
Otherwise this looks about right (you have an xhci argument you didn't
declare above, but this is obviously pseudo-code only)
> And we can define similar trace event classes for the various xHCI
> commands or ring debugging, so that we can enable or disable trace
> points individually for different parts of the xHCI driver.
I think it'd be worth (also) doing more specific tracepoints instead
though.
I don't really know what xhci does, but I suppose it has register
read/write, maybe packet (urb?) submissions etc. so something like the
iwlwifi_io system in drivers/net/wireless/iwlwifi/iwl-devtrace.h might
(also) be (more) useful. In iwlwifi I have tracing for
* IO accesses & interrupt notifications/reasons
* commands and TX packets submitted to the device
* notifications/RX packets received from the device
* previously existing debug messages
The message tracing was really more of an after-thought in iwlwifi (and
ath6kl as well I guess) because we already had a lot of debug messages
and capturing it all together can be useful.
However, tracing all the debug messages is actually fairly expensive, I
think in part because of the string formatting and in part because of
the always-max allocations in the ringbuffer.
> > That would have worked if the tracepoint was just :
> >
> > void trace_cmd_address_device(const char *fmt, ...)
> > {
> > if (trace event cmd_address_device is enabled) do {
> > (void(*)(const char *fmt, ...)) callback ((const
> > char *)&fmt);
> > }
> > }
I'm not really sure what the whole "callback()" part is about?
Are you trying to use the "tracepoint is enabled" to do something
unrelated to the tracing? I'm guessing that's _possible_, but I wouldn't
recommend it.
> I'm actually wondering if the call to ath6kl_printk is somehow necessary
> in order to be able to pass arguments on the stack.
I don't think it is, but formatting the messages *only* for tracing
seems a bit odd?
Hth,
johannes
^ permalink raw reply
* Re: [RFC]: vlan priority handling in WMM
From: Ben Hutchings @ 2013-07-11 17:17 UTC (permalink / raw)
To: Cedric Debarge; +Cc: netdev, linux-wireless
In-Reply-To: <773DB8A82AB6A046AE0195C68612A319015E05AD@sbs2003.acksys.local>
On Thu, 2013-07-11 at 09:45 +0200, Cedric Debarge wrote:
> Dear mailing list,
>
> I would like to manage the VLAN priority in Wireless QOS (WMM).
>
> I get the VLAN tag from skb->vlan_tci and I extract the VLAN priority.
>
> How I should handle the priority value 0.
> - Handle this value as no priority request, In this case the frame will
> sent with the DSCP priority or default (Best effort)
> - Handle this value as a lowest priority, in this case I Map it to the WMM.
[...]
IEEE 802.1q refers to the definition in 802.1d:
> The user_priority parameter is the priority requested by the
> originating service user. The value of this parameter is in the range
> 0 through 7.
>
> NOTE—The default user_priority value is 0. Values 1 through 7 form an
> ordered sequence of user_priorities, with 1 being the lowest value and
> 7 the highest. See 7.7.3 and Annex G (informative) for further
> explanation of the use of user_priority values.
So a value of 0 should be treated as no priority request, same as for an
untagged frame.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: wl127x: Unable to associate with a WPA2-PSK AP
From: José Miguel Gonçalves @ 2013-07-11 17:34 UTC (permalink / raw)
To: Luciano Coelho; +Cc: Arik Nemtsov, linux-wireless
In-Reply-To: <1373551187.8385.44.camel@cumari.coelho.fi>
On 11-07-2013 14:59, Luciano Coelho wrote:
> It seems that the wl1273 is not receiving the frames correctly. What
> happens in the first 3 frames is all normal, but we keep retransmitting
> the auth frame as if the AP hadn't sent us an ACK.
>
> 1. wl1273 sends auth to the AP
> 2. the AP acks the frame
> 3. the AP sends an auth back to us
> 4. we should send an ACK and continue, but instead we retransmit
> And from then on everything is screwed up.
>
> You could try to use the calibrator's RX statistics commands to see if
> you're getting lots of bad frames and such.
>
> This could be a problem in the firmware, but my hunch is that it's RF.
> What kind of antenna are you using?
A standard omni-directional antenna with a 4dBi gain. After I've read your email I
tried to change the antenna and immediately I got associated with the AP! But it
was only from a brief period. After that I've made some more tests and I was not
able to associate again. So it really seems that I've some kind of RF problem with
my module :-( BTW, my module has dual-band and I've tested in both 2.4 GHz and 5
GHz bands (with appropriate antennas), both without success.
>
> BTW, you should set a proper MAC address in your NVS too (calibrator's
> set_mac command). You could first try to set it to 00:00:00:00:00:00,
> which will check if the chip has a MAC in the Fuse ROM and use it from
> there. If that doesn't work, create your own and set it in the NVS.
I've already verified that the module doen not have a MAC built in. So I leaved
the "DE:AD:BE:EF:00:00" MAC set, which is as good as another one (for tests), and
a good reminder that I must add an EEPROM with a MAC address built in to my design.
>
> The TP-Link log is "too clean", missing some frames, we don't see most
> of the ACKs and we don't see the auth frame being sent back from the AP.
>
>
I've captured both files with display filter "wlan.addr == <MAC>". For instance,
for the log with the wl1273 based module, I used "wlan.addr == DE:AD:BE:EF:00:00".
It seemed to me the appropriate filter to extract all the traffic related with
that station, don't you agree?
José Gonçalves
^ permalink raw reply
* Re: wl127x: Unable to associate with a WPA2-PSK AP
From: José Miguel Gonçalves @ 2013-07-11 18:26 UTC (permalink / raw)
To: Luciano Coelho; +Cc: Arik Nemtsov, linux-wireless
In-Reply-To: <1373448177.8385.22.camel@cumari.coelho.fi>
On 10-07-2013 10:22, Luciano Coelho wrote:
> I'm not sure which FEM Jorjin's module use. Can you ask them?
>
> I found this on github (Dick Chiang appears to work for Jorjin):
> https://github.com/dickychiang/compat-wireless-r5/blob/master/jorjin/ini_files/TQS_D_1.7_WG7350_NLCP.ini
>
> DISCLAIMER: I have no clue whether this is the correct INI file or not
> and I'm not claiming it's associated with TI in any way, so use it at
> your own risk.
>
Just for the record, I got the information from my contact that the indicated INI
file is the proper one for Jorjin's WG7350 module.
José Gonçalves
^ permalink raw reply
* [PATCH] mac80211: fix off-by-one regression in ibss beacon generation
From: Simon Wunderlich @ 2013-07-11 18:29 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Simon Wunderlich
There is an off-by-one error in the beacon generation for the ibss mode,
falsely a rate the extended supported rates which was already added to
supported rates, messing up the beacon. This was introduced by commit
"mac80211: select and adjust bitrates according to channel mode".
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
---
I obviously missed that, sorry. :( This was not visible in 5/10 MHz as
CCK rates are missing in this mode. You might want to squash this one
...
---
net/mac80211/ibss.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
index 83197c3..5e6836c 100644
--- a/net/mac80211/ibss.c
+++ b/net/mac80211/ibss.c
@@ -168,8 +168,10 @@ static void __ieee80211_sta_join_ibss(struct ieee80211_sub_if_data *sdata,
if (basic_rates & BIT(ri))
basic = 0x80;
*pos++ = basic | (u8) rate;
- if (++rates_added == 8)
+ if (++rates_added == 8) {
+ ri++; /* continue at next rate for EXT_SUPP_RATES */
break;
+ }
}
if (sband->band == IEEE80211_BAND_2GHZ) {
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] mwifiex: don't ignore SDIO interrupts during shutdown
From: Daniel Drake @ 2013-07-11 18:43 UTC (permalink / raw)
To: Amitkumar Karwar; +Cc: Bing Zhao, linux-wireless@vger.kernel.org
In-Reply-To: <CAMLZHHQUghAsT8AM2to2rNJ3nwCfYEvPaqTcEk_7GmPWTOpQyQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 673 bytes --]
On Thu, Jul 11, 2013 at 8:38 AM, Daniel Drake <dsd@laptop.org> wrote:
> On Thu, Jul 11, 2013 at 8:17 AM, Amitkumar Karwar <akarwar@marvell.com> wrote:
>> Hi Daniel,
>>
>> Thanks for your elaborative comments. We can go with your patch which fixes the issue in a cleaner way. I ran some tests and verified remove path with it.
>
> Hmm. Now that I heard back from you and Bing, that interrupts at this
> point are totally unexpected, I would prefer to see the interrupt
> handler being disabled at the appropriate time, I think we can do
> better than my original patch. Let me see if I can find some time
> today/tomorrow to explore a better approach.
What about this one?
[-- Attachment #2: 0001-mwifiex-fix-IRQ-enable-disable.patch --]
[-- Type: application/octet-stream, Size: 9916 bytes --]
From f046af0b3142ecc4dabedbc8cc32d582e0204143 Mon Sep 17 00:00:00 2001
From: Daniel Drake <dsd@laptop.org>
Date: Thu, 11 Jul 2013 10:48:28 -0600
Subject: [PATCH] mwifiex: fix IRQ enable/disable
During tear down (e.g. mwifiex_sdio_remove during system suspend),
mwifiex left IRQs enabled for a significant period of time when it was
unable to handle them correctly. This caused interrupt storms and
interfered with the bluetooth interface on the same SDIO card.
Solve this by disabling interrupts at the point when they can no longer
be handled correctly, which is at the start of mwifiex_remove_card().
For cleanliness, we now enable interrupts in the mwifiex_add_card() path,
to be symmetrical with the disabling of interrupts. We also couple the
registration of the sdio IRQ handler with the actual enable/disable of
interrupts at the hardware level.
I also removed a write to this register in mwifiex_init_sdio which seemed
pointless and won't cause any ill effects now that we only register
the SDIO IRQ handler when we are ready to accept interrupts.
Signed-off-by: Daniel Drake <dsd@laptop.org>
---
drivers/net/wireless/mwifiex/init.c | 10 +---
drivers/net/wireless/mwifiex/main.c | 11 ++++-
drivers/net/wireless/mwifiex/main.h | 1 +
drivers/net/wireless/mwifiex/sdio.c | 91 +++++++++++++++++--------------------
4 files changed, 55 insertions(+), 58 deletions(-)
diff --git a/drivers/net/wireless/mwifiex/init.c b/drivers/net/wireless/mwifiex/init.c
index caaf4bd..2cf8b96 100644
--- a/drivers/net/wireless/mwifiex/init.c
+++ b/drivers/net/wireless/mwifiex/init.c
@@ -693,7 +693,7 @@ int mwifiex_dnld_fw(struct mwifiex_adapter *adapter,
if (!ret) {
dev_notice(adapter->dev,
"WLAN FW already running! Skip FW dnld\n");
- goto done;
+ return 0;
}
poll_num = MAX_FIRMWARE_POLL_TRIES;
@@ -719,14 +719,8 @@ int mwifiex_dnld_fw(struct mwifiex_adapter *adapter,
poll_fw:
/* Check if the firmware is downloaded successfully or not */
ret = adapter->if_ops.check_fw_status(adapter, poll_num);
- if (ret) {
+ if (ret)
dev_err(adapter->dev, "FW failed to be active in time\n");
- return -1;
- }
-done:
- /* re-enable host interrupt for mwifiex after fw dnld is successful */
- if (adapter->if_ops.enable_int)
- adapter->if_ops.enable_int(adapter);
return ret;
}
diff --git a/drivers/net/wireless/mwifiex/main.c b/drivers/net/wireless/mwifiex/main.c
index e15ab72..2083cf8 100644
--- a/drivers/net/wireless/mwifiex/main.c
+++ b/drivers/net/wireless/mwifiex/main.c
@@ -427,6 +427,10 @@ static void mwifiex_fw_dpc(const struct firmware *firmware, void *context)
"Cal data request_firmware() failed\n");
}
+ /* enable host interrupt after fw dnld is successful */
+ if (adapter->if_ops.enable_int)
+ adapter->if_ops.enable_int(adapter);
+
adapter->init_wait_q_woken = false;
ret = mwifiex_init_fw(adapter);
if (ret == -1) {
@@ -855,7 +859,7 @@ mwifiex_add_card(void *card, struct semaphore *sem,
INIT_WORK(&adapter->main_work, mwifiex_main_work_queue);
/* Register the device. Fill up the private data structure with relevant
- information from the card and request for the required IRQ. */
+ information from the card. */
if (adapter->if_ops.register_dev(adapter)) {
pr_err("%s: failed to register mwifiex device\n", __func__);
goto err_registerdev;
@@ -919,6 +923,11 @@ int mwifiex_remove_card(struct mwifiex_adapter *adapter, struct semaphore *sem)
if (!adapter)
goto exit_remove;
+ /* We can no longer handle interrupts once we start doing the teardown
+ * below. */
+ if (adapter->if_ops.disable_int)
+ adapter->if_ops.disable_int(adapter);
+
adapter->surprise_removed = true;
/* Stop data */
diff --git a/drivers/net/wireless/mwifiex/main.h b/drivers/net/wireless/mwifiex/main.h
index 3da73d3..253e0bd 100644
--- a/drivers/net/wireless/mwifiex/main.h
+++ b/drivers/net/wireless/mwifiex/main.h
@@ -601,6 +601,7 @@ struct mwifiex_if_ops {
int (*register_dev) (struct mwifiex_adapter *);
void (*unregister_dev) (struct mwifiex_adapter *);
int (*enable_int) (struct mwifiex_adapter *);
+ void (*disable_int) (struct mwifiex_adapter *);
int (*process_int_status) (struct mwifiex_adapter *);
int (*host_to_card) (struct mwifiex_adapter *, u8, struct sk_buff *,
struct mwifiex_tx_param *);
diff --git a/drivers/net/wireless/mwifiex/sdio.c b/drivers/net/wireless/mwifiex/sdio.c
index 5ee5ed0..5ef49f2 100644
--- a/drivers/net/wireless/mwifiex/sdio.c
+++ b/drivers/net/wireless/mwifiex/sdio.c
@@ -51,6 +51,7 @@ static struct mwifiex_if_ops sdio_ops;
static struct semaphore add_remove_card_sem;
static int mwifiex_sdio_resume(struct device *dev);
+static void mwifiex_sdio_interrupt(struct sdio_func *func);
/*
* SDIO probe.
@@ -296,6 +297,15 @@ static struct sdio_driver mwifiex_sdio = {
}
};
+/* Write data into SDIO card register. Caller claims SDIO device. */
+static int
+mwifiex_write_reg_locked(struct sdio_func *func, u32 reg, u8 data)
+{
+ int ret = -1;
+ sdio_writeb(func, data, reg, &ret);
+ return ret;
+}
+
/*
* This function writes data into SDIO card register.
*/
@@ -303,10 +313,10 @@ static int
mwifiex_write_reg(struct mwifiex_adapter *adapter, u32 reg, u8 data)
{
struct sdio_mmc_card *card = adapter->card;
- int ret = -1;
+ int ret;
sdio_claim_host(card->func);
- sdio_writeb(card->func, data, reg, &ret);
+ ret = mwifiex_write_reg_locked(card->func, reg, data);
sdio_release_host(card->func);
return ret;
@@ -685,23 +695,15 @@ mwifiex_sdio_read_fw_status(struct mwifiex_adapter *adapter, u16 *dat)
* The host interrupt mask is read, the disable bit is reset and
* written back to the card host interrupt mask register.
*/
-static int mwifiex_sdio_disable_host_int(struct mwifiex_adapter *adapter)
+static void mwifiex_sdio_disable_host_int(struct mwifiex_adapter *adapter)
{
- u8 host_int_mask, host_int_disable = HOST_INT_DISABLE;
-
- /* Read back the host_int_mask register */
- if (mwifiex_read_reg(adapter, HOST_INT_MASK_REG, &host_int_mask))
- return -1;
-
- /* Update with the mask and write back to the register */
- host_int_mask &= ~host_int_disable;
-
- if (mwifiex_write_reg(adapter, HOST_INT_MASK_REG, host_int_mask)) {
- dev_err(adapter->dev, "disable host interrupt failed\n");
- return -1;
- }
+ struct sdio_mmc_card *card = adapter->card;
+ struct sdio_func *func = card->func;
- return 0;
+ sdio_claim_host(func);
+ mwifiex_write_reg_locked(func, HOST_INT_MASK_REG, 0);
+ sdio_release_irq(func);
+ sdio_release_host(func);
}
/*
@@ -713,14 +715,29 @@ static int mwifiex_sdio_disable_host_int(struct mwifiex_adapter *adapter)
static int mwifiex_sdio_enable_host_int(struct mwifiex_adapter *adapter)
{
struct sdio_mmc_card *card = adapter->card;
+ struct sdio_func *func = card->func;
+ int ret;
+
+ sdio_claim_host(func);
+
+ /* Request the SDIO IRQ */
+ ret = sdio_claim_irq(func, mwifiex_sdio_interrupt);
+ if (ret) {
+ dev_err(adapter->dev, "claim irq failed: ret=%d\n", ret);
+ goto out;
+ }
/* Simply write the mask to the register */
- if (mwifiex_write_reg(adapter, HOST_INT_MASK_REG,
- card->reg->host_int_enable)) {
+ ret = mwifiex_write_reg_locked(func, HOST_INT_MASK_REG,
+ card->reg->host_int_enable);
+ if (ret) {
dev_err(adapter->dev, "enable host interrupt failed\n");
- return -1;
+ sdio_release_irq(func);
}
- return 0;
+
+out:
+ sdio_release_host(func);
+ return ret;
}
/*
@@ -997,9 +1014,6 @@ mwifiex_sdio_interrupt(struct sdio_func *func)
}
adapter = card->adapter;
- if (adapter->surprise_removed)
- return;
-
if (!adapter->pps_uapsd_mode && adapter->ps_state == PS_STATE_SLEEP)
adapter->ps_state = PS_STATE_AWAKE;
@@ -1728,9 +1742,7 @@ mwifiex_unregister_dev(struct mwifiex_adapter *adapter)
struct sdio_mmc_card *card = adapter->card;
if (adapter->card) {
- /* Release the SDIO IRQ */
sdio_claim_host(card->func);
- sdio_release_irq(card->func);
sdio_disable_func(card->func);
sdio_release_host(card->func);
sdio_set_drvdata(card->func, NULL);
@@ -1744,7 +1756,7 @@ mwifiex_unregister_dev(struct mwifiex_adapter *adapter)
*/
static int mwifiex_register_dev(struct mwifiex_adapter *adapter)
{
- int ret = 0;
+ int ret;
struct sdio_mmc_card *card = adapter->card;
struct sdio_func *func = card->func;
@@ -1753,22 +1765,14 @@ static int mwifiex_register_dev(struct mwifiex_adapter *adapter)
sdio_claim_host(func);
- /* Request the SDIO IRQ */
- ret = sdio_claim_irq(func, mwifiex_sdio_interrupt);
- if (ret) {
- pr_err("claim irq failed: ret=%d\n", ret);
- goto disable_func;
- }
-
/* Set block size */
ret = sdio_set_block_size(card->func, MWIFIEX_SDIO_BLOCK_SIZE);
+ sdio_release_host(func);
if (ret) {
pr_err("cannot set SDIO block size\n");
- ret = -1;
- goto release_irq;
+ return ret;
}
- sdio_release_host(func);
sdio_set_drvdata(func, card);
adapter->dev = &func->dev;
@@ -1776,15 +1780,6 @@ static int mwifiex_register_dev(struct mwifiex_adapter *adapter)
strcpy(adapter->fw_name, card->firmware);
return 0;
-
-release_irq:
- sdio_release_irq(func);
-disable_func:
- sdio_disable_func(func);
- sdio_release_host(func);
- adapter->card = NULL;
-
- return -1;
}
/*
@@ -1813,9 +1808,6 @@ static int mwifiex_init_sdio(struct mwifiex_adapter *adapter)
*/
mwifiex_read_reg(adapter, HOST_INTSTATUS_REG, &sdio_ireg);
- /* Disable host interrupt mask register for SDIO */
- mwifiex_sdio_disable_host_int(adapter);
-
/* Get SDIO ioport */
mwifiex_init_sdio_ioport(adapter);
@@ -1957,6 +1949,7 @@ static struct mwifiex_if_ops sdio_ops = {
.register_dev = mwifiex_register_dev,
.unregister_dev = mwifiex_unregister_dev,
.enable_int = mwifiex_sdio_enable_host_int,
+ .disable_int = mwifiex_sdio_disable_host_int,
.process_int_status = mwifiex_process_int_status,
.host_to_card = mwifiex_sdio_host_to_card,
.wakeup = mwifiex_pm_wakeup_card,
--
1.8.1.4
^ permalink raw reply related
* Re: Help adding trace events to xHCI
From: Sarah Sharp @ 2013-07-11 19:00 UTC (permalink / raw)
To: Johannes Berg
Cc: Xenia Ragiadakou, OPW Kernel Interns List, linux-usb,
linux-wireless, Kalle Valo, Steven Rostedt
In-Reply-To: <1373562533.8201.33.camel@jlt4.sipsolutions.net>
On Thu, Jul 11, 2013 at 07:08:53PM +0200, Johannes Berg wrote:
> [also adding Steven, he's the tracing expert after all :-)]
>
> Hi Xenia, Sarah, all,
>
> > (Mentors and wireless folks, we're struggling a bit with adding trace
> > events to the xHCI USB host controller driver. I'm trying to look at
> > the ath6kl driver trace events as an example. We could use some help
> > and/or advice.)
>
> Those were in turn modelled on mac80211, cfg80211 and/or iwlwifi, I
> think; might be worth also looking there. In general though, it's all
> pretty similar.
>
> > > lets say that we want the tracepoint function to have the prototype:
> > >
> > > void trace_cmd_address_device(const char *fmt, ...).
>
> I'm not sure this is possible. I think we (wireless) do this with
>
> void trace_cmd_address_device(struct va_format *vaf)
>
> instead only.
>
> Note that there's no easy way to dynamically allocate the right amount
> of space in the ringbuffer, or at least I haven't found one. We
> therefore have a static size, which is somewhat inefficient.
Yes, that does look inefficient. Would it make sense to add a couple
different trace event classes for different sized buffers, and call
those trace classes conditionally, based on the size of the formatted
string? Or would that be too much of a mess.
Either way, it's only inefficient when trace events are turned on. We
don't expect xHCI debugging to be enabled by users very often. I do
expect that there will be a lot of debugging when it gets turned on.
Can userspace increase the size of the ring buffer? How much space do
we have by default?
> > The ath driver defines a new trace event class, ath6kl_log_event.
> > Various types of tracepoints, like trace_ath6kl_log_warn, use that event
> > class. Wrappers like ath6kl_warn() call those trace points, passing it
> > a struct va_format on the stack:
> >
> > int ath6kl_warn(const char *fmt, ...)
> > {
> > struct va_format vaf = {
> > .fmt = fmt,
> > };
> > va_list args;
> > int ret;
> >
> > va_start(args, fmt);
> > vaf.va = &args;
> > ret = ath6kl_printk(KERN_WARNING, "%pV", &vaf);
>
> Note also on older kernels you used to have to do va_copy() here because
> "%pV" didn't do it by itself. Guess you don't care though, but I
> sometimes have to worry about backporting :-)
The trace events are unlikely to get backported, so I'm not concerned
about that.
> > int xhci_debug_address(const char *fmt, ...)
>
> This confuses me somewhat -- why is it called "xhci_debug_address()"
> when it takes arbitrary parameters? Where's the "address" part?
It's debugging the xHCI Address command output. Depending on the status
of the command, we print different statement in the xHCI code. E.g. we
print when the command times out, or finishes with an error status
because there was a USB transfer error on the bus.
We can work on better names later. :)
> > DEFINE_EVENT(xhci_log_event, xhci_dbg_address,
> > TP_PROTO(struct va_format *vaf),
> > TP_ARGS(vaf)
> > );
> >
> > DECLARE_EVENT_CLASS(xhci_log_event,
> > TP_PROTO(struct va_format *vaf),
> > TP_ARGS(vaf),
> > TP_STRUCT__entry(
> > __dynamic_array(char, msg, ATH6KL_MSG_MAX)
>
> Should probably not be ATH6KL_MSG_MAX :-)
Yes.
> And this is what I talked about before -- it always allocates the max in
> the ringbuffer even for really short messages.
Noted.
> > And then code in xhci_address_device() in drivers/usb/host/xhci.c can do
> > things like:
> >
> > xhci_debug_address(xhci, "Bad Slot ID %d\n", udev->slot_id);
>
> Otherwise this looks about right (you have an xhci argument you didn't
> declare above, but this is obviously pseudo-code only)
>
> > And we can define similar trace event classes for the various xHCI
> > commands or ring debugging, so that we can enable or disable trace
> > points individually for different parts of the xHCI driver.
>
> I think it'd be worth (also) doing more specific tracepoints instead
> though.
>
> I don't really know what xhci does, but I suppose it has register
> read/write, maybe packet (urb?) submissions etc. so something like the
> iwlwifi_io system in drivers/net/wireless/iwlwifi/iwl-devtrace.h might
> (also) be (more) useful. In iwlwifi I have tracing for
> * IO accesses & interrupt notifications/reasons
> * commands and TX packets submitted to the device
> * notifications/RX packets received from the device
> * previously existing debug messages
My initial list of specific trace points was something like:
1. xHCI host initialization and shutdown
2. xHCI memory allocation (dynamic ring resizing, structure alloc, etc)
3. A few individual xHCI host controller command tracepoints:
* status only for all completed commands
* Address Device command status and output
* Configure Endpoint and Evaluate Context output
* individual trace points for other xHCI commands
4. Tracepoints for all USB transfer types:
* Control TX output (only for non-successful transfers)
* Bulk TX
* Interrupt TX
* Isoc TX
5. URB cancellation
And probably more. Basically, I want to be able to control what gets
printed, based on where I think the xHCI bug might be. Does that sound
reasonable?
> The message tracing was really more of an after-thought in iwlwifi (and
> ath6kl as well I guess) because we already had a lot of debug messages
> and capturing it all together can be useful.
>
> However, tracing all the debug messages is actually fairly expensive, I
> think in part because of the string formatting and in part because of
> the always-max allocations in the ringbuffer.
So are there parts of the driver that don't have the debug messages go
through the trace events code, in order to not fill up the ring buffer?
> > I'm actually wondering if the call to ath6kl_printk is somehow necessary
> > in order to be able to pass arguments on the stack.
>
> I don't think it is, but formatting the messages *only* for tracing
> seems a bit odd?
Why is it odd?
Sarah Sharp
^ permalink raw reply
* Re: Help adding trace events to xHCI
From: Steven Rostedt @ 2013-07-11 19:29 UTC (permalink / raw)
To: Johannes Berg
Cc: Sarah Sharp, Xenia Ragiadakou, OPW Kernel Interns List, linux-usb,
linux-wireless, Kalle Valo
In-Reply-To: <1373562533.8201.33.camel@jlt4.sipsolutions.net>
On Thu, 2013-07-11 at 19:08 +0200, Johannes Berg wrote:
> > > lets say that we want the tracepoint function to have the prototype:
> > >
> > > void trace_cmd_address_device(const char *fmt, ...).
>
> I'm not sure this is possible. I think we (wireless) do this with
>
> void trace_cmd_address_device(struct va_format *vaf)
>
> instead only.
>
> Note that there's no easy way to dynamically allocate the right amount
> of space in the ringbuffer, or at least I haven't found one. We
> therefore have a static size, which is somewhat inefficient.
Can you add a helper function? If these trace events can't nest (one in
interrupt context and another in normal context with interrupts
enabled), then you can just allocate a per-cpu buffer and store the
string in that, and then move the string into the buffer.
vsnprintf(this_cpu_ptr(trace_buf), MAX_BUF_LEN, fmt, va);
__assign_str(str, trace_buf);
You could even use the reg, unreg, methods for TRACE_EVENT_FN() that
will allocate the buffers when the tracepoint is created. This will mean
that you don't waste memory when not tracing.
-- Steve
^ permalink raw reply
* Using CC BY-SA for wireless wiki content
From: Luis R. Rodriguez @ 2013-07-11 20:18 UTC (permalink / raw)
To: linux-wireless
Folks,
Anyone have any issues if we license the wiki content on
wireless.kernel.org under CC BY-SA license? That would make it
compatible with Wikipedia. Please shout out if you disagree with this
move as at this point we have random collaborations but at least as
per initial review it seems this would be a good idea. Want to see if
anyone disagrees before we do the move.
Luis
^ permalink raw reply
* Re: Using CC BY-SA for wireless wiki content
From: Arend van Spriel @ 2013-07-11 20:21 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
In-Reply-To: <CAB=NE6V-MOLqe0Ty0R+MX-S3oZFSfkXq+X7rqRi9RTAQ8DtuTQ@mail.gmail.com>
On 07/11/13 22:18, Luis R. Rodriguez wrote:
> Folks,
>
> Anyone have any issues if we license the wiki content on
> wireless.kernel.org under CC BY-SA license? That would make it
> compatible with Wikipedia. Please shout out if you disagree with this
> move as at this point we have random collaborations but at least as
> per initial review it seems this would be a good idea. Want to see if
> anyone disagrees before we do the move.
Which version?
Arend
> Luis
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: Using CC BY-SA for wireless wiki content
From: Luis R. Rodriguez @ 2013-07-11 20:23 UTC (permalink / raw)
To: Arend van Spriel; +Cc: linux-wireless
In-Reply-To: <51DF13DA.3040803@broadcom.com>
On Thu, Jul 11, 2013 at 1:21 PM, Arend van Spriel <arend@broadcom.com> wrote:
> On 07/11/13 22:18, Luis R. Rodriguez wrote:
>>
>> Folks,
>>
>> Anyone have any issues if we license the wiki content on
>> wireless.kernel.org under CC BY-SA license? That would make it
>> compatible with Wikipedia. Please shout out if you disagree with this
>> move as at this point we have random collaborations but at least as
>> per initial review it seems this would be a good idea. Want to see if
>> anyone disagrees before we do the move.
>
>
> Which version?
CC BY-SA 3.0 Unported, following the same version used by Wikipedia:
https://en.wikipedia.org/wiki/Wikipedia:Text_of_Creative_Commons_Attribution-ShareAlike_3.0_Unported_License
Luis
^ permalink raw reply
* [PATCH] mac80211: fix duplicate retransmission detection
From: Johannes Berg @ 2013-07-11 20:36 UTC (permalink / raw)
To: linux-wireless
The duplicate retransmission detection code in mac80211
erroneously attempts to do the check for every frame,
even frames that don't have a sequence control field or
that don't use it (QoS-Null frames.)
This is problematic because it causes the code to access
data beyond the end of the SKB and depending on the data
there will drop packets erroneously.
Correct the code to not do duplicate detection for such
frames.
I found this error while testing AP powersave, it lead
to retransmitted PS-Poll frames being dropped entirely
as the data beyond the end of the SKB was always zero.
Cc: stable@vger.kernel.org [all versions]
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
net/mac80211/rx.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 23dbcfc..2c5a79b 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -936,8 +936,14 @@ ieee80211_rx_h_check(struct ieee80211_rx_data *rx)
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)rx->skb->data;
struct ieee80211_rx_status *status = IEEE80211_SKB_RXCB(rx->skb);
- /* Drop duplicate 802.11 retransmissions (IEEE 802.11 Chap. 9.2.9) */
- if (rx->sta && !is_multicast_ether_addr(hdr->addr1)) {
+ /*
+ * Drop duplicate 802.11 retransmissions
+ * (IEEE 802.11-2012: 9.3.2.10 "Duplicate detection and recovery")
+ */
+ if (rx->skb->len >= 24 && rx->sta &&
+ !ieee80211_is_ctl(hdr->frame_control) &&
+ !ieee80211_is_qos_nullfunc(hdr->frame_control) &&
+ !is_multicast_ether_addr(hdr->addr1)) {
if (unlikely(ieee80211_has_retry(hdr->frame_control) &&
rx->sta->last_seq_ctrl[rx->seqno_idx] ==
hdr->seq_ctrl)) {
--
1.8.0
^ permalink raw reply related
* Re: Power saving features for iwl4965
From: Pedro Francisco @ 2013-07-11 21:02 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: Tino Keitel, ML linux-wireless
In-Reply-To: <20130625142514.GA1938@redhat.com>
1On Tue, Jun 25, 2013 at 3:25 PM, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> On Fri, Jun 14, 2013 at 03:18:29PM +0200, Stanislaw Gruszka wrote:
>> > >> I also got a SYSASSERT:
>> > >> (...)
>> > >>
>> > >> I disabled powersave (but kept running the same kernel) and none of
>> > >> the errors appeared again.
>> > >
>> > > Yes, this seems to be iwlegacy PS issue and has to be fixed before
>> > > this patch could be applied.
>> >
>> > But is it a driver-only issue? I had assumed it was some sort of
>> > fireware+driver issue...
>> Looks like driver issue or firmware issue that can be workaround in
>> the driver.
>>
>> > Will running with debug on help? Or is it easily reproducible on any
>> > iwl3945 / iwl4465 ?
>> >
>> > Because in my case (iwl3945) it happens after boot, no prior suspend
>> > to RAM is required to trigger the issues.
>> I can reproduce microcode error on iwl4965 by reloading modules. Looks
>> like we put device in sleep mode and it can not be properly booted when
>> driver initalize. I did not yet test patch on iwl3945. When I'll do
>> this, I think I'll be able to reproduce problems you discovered. If not
>> I'll ask for more debug info.
>
> I found problem on 4965, we have to send power configuration command to
> device earlier, before some other commands. Attached patch solved
> microcode errors I have on 4965.
>
> Regarding iwl3945. Display on my 3945 laptop no longer works. I took
> 3945 device from that laptop and installed it on two different machines.
> Unfortunately on none of them device was detected by pci system :-/
> I have figure out how to get working 3945 testing environment, but for
> now, perhaps you could provide me some more debug information.
>
> Pedro, please do the fallowing:
>
> Add this line in /etc/rsyslog.conf:
> kern.* /var/log/kernel
>
> Restart rsyslog services:
> # systemctl restart rsyslog.service
>
> Restart iwl3945 module with verbose debug enabled:
> modprobe -r iwl3945
> modprobe iwl3945 debug=0x47ffffff
>
> Reproduce the problem.
>
> Unload module:
> modprobe -r iwl3945
>
> Then provide me generated /var/log/kernel file (compressed if needed).
I seem only to be able to trigger it with disable_hw_scan=0, I need
further testing with disable_hw_scan=1 (I use disable_hw_scan=0
because it prevents me from getting disconnected from eduroam Cisco
APs -- haven't tested disable_hw_scan=0 since the VOIP-friendly SW
scanning patch, however).
Do you want the log anyway? (modprobe iwl3945 debug=0x47ffffff
disable_hw_scan=0 and runtime PCI powersave also enabled -- I don't
know if it matters).
--
Pedro
^ permalink raw reply
* [PATCH 0/6] initval patches
From: Sujith Manoharan @ 2013-07-12 4:00 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
From: Sujith Manoharan <c_manoha@qca.qualcomm.com>
This is a resend of the pending initval patches, rebased over
master.
Sujith Manoharan (6):
initvals: Update inivals for AR9462 2.0
initvals: Add 5g-XLNA table for AR9462
initvals: Add ar9462_2p0_5g_xlna_only_rxgain table
initvals: Add rxgain tables for AR9462
initvals: Add support for AR9462 2.1
initvals: Add mix ob/db tx gain table for AR9462 2.0
tools/initvals/Makefile | 2 +
tools/initvals/ar9462_2p0_initvals.h | 345 ++++++-
tools/initvals/ar9462_2p1_initvals.h | 1774 ++++++++++++++++++++++++++++++++++
tools/initvals/checksums.txt | 28 +-
tools/initvals/initvals.c | 61 ++
5 files changed, 2208 insertions(+), 2 deletions(-)
create mode 100644 tools/initvals/ar9462_2p1_initvals.h
--
1.8.3.2
^ permalink raw reply
* [PATCH 1/6] initvals: Update inivals for AR9462 2.0
From: Sujith Manoharan @ 2013-07-12 4:00 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
In-Reply-To: <1373601613-31616-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>
---
tools/initvals/ar9462_2p0_initvals.h | 2 +-
tools/initvals/checksums.txt | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/initvals/ar9462_2p0_initvals.h b/tools/initvals/ar9462_2p0_initvals.h
index 999ab08..f00e945 100644
--- a/tools/initvals/ar9462_2p0_initvals.h
+++ b/tools/initvals/ar9462_2p0_initvals.h
@@ -78,7 +78,7 @@ static const u32 ar9462_2p0_baseband_postamble[][5] = {
{0x0000a284, 0x00000000, 0x00000000, 0x00000150, 0x00000150},
{0x0000a288, 0x00000110, 0x00000110, 0x00000110, 0x00000110},
{0x0000a28c, 0x00022222, 0x00022222, 0x00022222, 0x00022222},
- {0x0000a2c4, 0x00058d18, 0x00058d18, 0x00058d18, 0x00058d18},
+ {0x0000a2c4, 0x00158d18, 0x00158d18, 0x00158d18, 0x00158d18},
{0x0000a2d0, 0x00041981, 0x00041981, 0x00041981, 0x00041982},
{0x0000a2d8, 0x7999a83b, 0x7999a83b, 0x7999a83b, 0x7999a83b},
{0x0000a358, 0x00000000, 0x00000000, 0x00000000, 0x00000000},
diff --git a/tools/initvals/checksums.txt b/tools/initvals/checksums.txt
index 551c3ba..e3632c8 100644
--- a/tools/initvals/checksums.txt
+++ b/tools/initvals/checksums.txt
@@ -139,7 +139,7 @@ ca6088034f339ea8f106f7f034d34baafec0c0ca ar9340Modes_high_ob_db_tx_gain_t
1b9f617ab8c10ec0760e81fe61d469692f2acc29 ar9340_1p0_soc_preamble
d9efd1c575ac43d60c310d717c59617a5323c111 ar9462_modes_fast_clock_2p0
222ed8213d3ffb0d12cf4c7019bdfd874e45c7d7 ar9462_pciephy_clkreq_enable_L1_2p0
-efb4c74c657dbc49ab80dd1d42a5b8e6ff0c3651 ar9462_2p0_baseband_postamble
+d7a2102c22264c288fa3d9de27e5ae84b8f3812e ar9462_2p0_baseband_postamble
d0f7aff1a1ab7e6f6bbda0da067714459341ce5f ar9462_common_rx_gain_table_2p0
2fbe90336971cd66f0264c0cc57605c2de069d5f ar9462_pciephy_clkreq_disable_L1_2p0
a3173672141a2ac797e660228d41a609f9ab2c4c ar9462_pciephy_pll_on_clkreq_disable_L1_2p0
--
1.8.3.2
^ permalink raw reply related
* [PATCH 2/6] initvals: Add 5g-XLNA table for AR9462
From: Sujith Manoharan @ 2013-07-12 4:00 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
In-Reply-To: <1373601613-31616-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>
---
tools/initvals/ar9462_2p0_initvals.h | 5 +++++
tools/initvals/checksums.txt | 1 +
tools/initvals/initvals.c | 2 ++
3 files changed, 8 insertions(+)
diff --git a/tools/initvals/ar9462_2p0_initvals.h b/tools/initvals/ar9462_2p0_initvals.h
index f00e945..d402c5d 100644
--- a/tools/initvals/ar9462_2p0_initvals.h
+++ b/tools/initvals/ar9462_2p0_initvals.h
@@ -1449,4 +1449,9 @@ static const u32 ar9462_common_mixed_rx_gain_table_2p0[][2] = {
{0x0000b1fc, 0x00000196},
};
+static const u32 ar9462_2p0_baseband_postamble_5g_xlna[][5] = {
+ /* Addr 5G_HT20 5G_HT40 2G_HT40 2G_HT20 */
+ {0x00009e3c, 0xcf946220, 0xcf946220, 0xcfd5c782, 0xcfd5c282},
+};
+
#endif /* INITVALS_9462_2P0_H */
diff --git a/tools/initvals/checksums.txt b/tools/initvals/checksums.txt
index e3632c8..5cb85c8 100644
--- a/tools/initvals/checksums.txt
+++ b/tools/initvals/checksums.txt
@@ -156,6 +156,7 @@ fd98d0361e085b102131c2dc07c601e0a7ccdd13 ar9462_2p0_radio_core
2e6ddfe3c7e291ca6bebb5791d8a73c492db0399 ar9462_2p0_mac_core
c8dc777b012068116cd5282aade8eb460f397d20 ar9462_2p0_mac_postamble
72675fd0f308e6f31502e283119e12469d262f40 ar9462_common_mixed_rx_gain_table_2p0
+185f0537e40b74dcc4db33c7e111c1bfe79f3104 ar9462_2p0_baseband_postamble_5g_xlna
c8dc777b012068116cd5282aade8eb460f397d20 ar9485_1_1_mac_postamble
5d20e4848b97566ad55e0e95458463d622ee5480 ar9485_1_1_pcie_phy_pll_on_clkreq_disable_L1
d9a90632a00a7b417154173b947dfffdeab23e51 ar9485Common_wo_xlna_rx_gain_1_1
diff --git a/tools/initvals/initvals.c b/tools/initvals/initvals.c
index 0f4c3f1..f8a104a 100644
--- a/tools/initvals/initvals.c
+++ b/tools/initvals/initvals.c
@@ -317,6 +317,7 @@ struct initval_family {
#define ar9300_jupiter_2p0_mac_core ar9462_2p0_mac_core
#define ar9300_jupiter_2p0_mac_postamble ar9462_2p0_mac_postamble
#define ar9300Common_mixed_rx_gain_table_jupiter_2p0 ar9462_common_mixed_rx_gain_table_2p0
+#define ar9300_jupiter_2p0_baseband_postamble_5g_xlna ar9462_2p0_baseband_postamble_5g_xlna
#include "ar9300_jupiter20.ini"
@@ -902,6 +903,7 @@ static void ar9462_2p0_hw_print_initvals(bool check)
INI_PRINT(ar9462_2p0_mac_core);
INI_PRINT(ar9462_2p0_mac_postamble);
INI_PRINT(ar9462_common_mixed_rx_gain_table_2p0);
+ INI_PRINT(ar9462_2p0_baseband_postamble_5g_xlna);
}
static void ar9565_1p0_hw_print_initvals(bool check)
--
1.8.3.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