* Re: [PATCH] ath9k_htc: fix skb_under_panic error
From: Helmut Schaa @ 2013-06-05 14:24 UTC (permalink / raw)
To: Oleksij Rempel; +Cc: linux-wireless, ath9k-devel, Marc Kleine-Budde
In-Reply-To: <1370371064-6903-1-git-send-email-linux@rempel-privat.de>
On Tue, Jun 4, 2013 at 8:37 PM, Oleksij Rempel <linux@rempel-privat.de> wrote:
> This error seems to be really rare, and we do not know real couse of it.
> But, in any case, we should check size of head before reducing it.
Mind to try the (completely untested) patch against wireless-testing instead?
Helmut
---
Subject: [PATCH] ath9k_htc: Restore skb headroom when returning skb to mac80211
ath9k_htc adds padding between the 802.11 header and the payload during
TX by moving the header. When handing the frame back to mac80211 for TX
status handling the header is not moved back into its original position.
This can result in a too small skb headroom when entering ath9k_htc
again (due to a soft retransmission for example) causing an
skb_under_panic oops.
Fix this by moving the 802.11 header back into its original position
before returning the frame to mac80211 as other drivers like rt2x00
or ath5k do.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
---
drivers/net/wireless/ath/ath9k/htc_drv_txrx.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
b/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
index e602c95..666cfb6 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
@@ -448,6 +448,8 @@ static void ath9k_htc_tx_process(struct
ath9k_htc_priv *priv,
struct ieee80211_conf *cur_conf = &priv->hw->conf;
bool txok;
int slot;
+ struct ieee80211_hdr *hdr;
+ int padpos, padsize;
slot = strip_drv_header(priv, skb);
if (slot < 0) {
@@ -504,6 +506,15 @@ send_mac80211:
ath9k_htc_tx_clear_slot(priv, slot);
+ /* Remove padding before handing frame back to mac80211 */
+ hdr = (struct ieee80211_hdr *) skb->data;
+ padpos = ieee80211_hdrlen(hdr->frame_control);
+ padsize = padpos & 3;
+ if (padsize && skb->len > padpos + padsize) {
+ memmove(skb->data + padsize, skb->data, padpos);
+ skb_pull(skb, padsize);
+ }
+
/* Send status to mac80211 */
ieee80211_tx_status(priv->hw, skb);
}
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCHv2 3/4] brcm80211: make mgmt_tx in brcmfmac accept a NULL channel
From: Antonio Quartulli @ 2013-06-05 14:17 UTC (permalink / raw)
To: Arend van Spriel
Cc: Antonio Quartulli, Johannes Berg, linux-wireless@vger.kernel.org,
brcm80211-dev-list@broadcom.com
In-Reply-To: <51AF47AF.9060802@broadcom.com>
[-- Attachment #1: Type: text/plain, Size: 1581 bytes --]
On Wed, Jun 05, 2013 at 07:14:07AM -0700, Arend van Spriel wrote:
> On 06/05/2013 03:57 PM, Antonio Quartulli wrote:
> > On Wed, Jun 05, 2013 at 06:53:32AM -0700, Arend van Spriel wrote:
> >
> > [...]
> >
> >>> + freq = cfg->channel;
> >>> + if (chan)
> >>> + freq = chan->center_freq;
> >>> + chan_nr = ieee80211_frequency_to_channel(freq);
> >>
> >> Could you get rid of 'freq' variable and use
> >> ieee80211_frequency_to_channel() on cfg->channel or chan->center_freq.
> >>
> >
> > I tried that, but the line indented below the if would be longer than 80 chars
> > and breaking it is quite ugly.
> >
> >> Another thing is that cfg->channel can be zero resulting in chan_nr
> >> being zero. I had a quick look whether the device firmware can handle
> >> this. I suspect not, but I will need to ask to be sure.
> >>
> >
> > ok. But when cfg->channel is zero, where is the current freq stored?
>
> It is not. The rf on the device is set to a certain channel so it can be
> retrieved from the device:
>
> brcmf_fil_cmd_int_get(vif->ifp, BRCMF_C_GET_CHANNEL, &freq);
>
> The vif pointer can be obtained using container_of() on the wdev. That
> is done in mgmt_tx() already some lines above. May you should move
> determining the vif pointer and do it unconditional.
>
Yeah, I like this approach.
I'll send v3 of this patchset with this change in it.
@johannes: I'll also revert the order of the patches.
Thanks a lot Arend.
Regards,
--
Antonio Quartulli
..each of us alone is worth nothing..
Ernesto "Che" Guevara
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCHv2 3/4] brcm80211: make mgmt_tx in brcmfmac accept a NULL channel
From: Arend van Spriel @ 2013-06-05 14:14 UTC (permalink / raw)
To: Antonio Quartulli
Cc: Antonio Quartulli, Johannes Berg, linux-wireless@vger.kernel.org,
brcm80211-dev-list@broadcom.com
In-Reply-To: <20130605135757.GF2349@open-mesh.com>
On 06/05/2013 03:57 PM, Antonio Quartulli wrote:
> On Wed, Jun 05, 2013 at 06:53:32AM -0700, Arend van Spriel wrote:
>
> [...]
>
>>> + freq = cfg->channel;
>>> + if (chan)
>>> + freq = chan->center_freq;
>>> + chan_nr = ieee80211_frequency_to_channel(freq);
>>
>> Could you get rid of 'freq' variable and use
>> ieee80211_frequency_to_channel() on cfg->channel or chan->center_freq.
>>
>
> I tried that, but the line indented below the if would be longer than 80 chars
> and breaking it is quite ugly.
>
>> Another thing is that cfg->channel can be zero resulting in chan_nr
>> being zero. I had a quick look whether the device firmware can handle
>> this. I suspect not, but I will need to ask to be sure.
>>
>
> ok. But when cfg->channel is zero, where is the current freq stored?
It is not. The rf on the device is set to a certain channel so it can be
retrieved from the device:
brcmf_fil_cmd_int_get(vif->ifp, BRCMF_C_GET_CHANNEL, &freq);
The vif pointer can be obtained using container_of() on the wdev. That
is done in mgmt_tx() already some lines above. May you should move
determining the vif pointer and do it unconditional.
Regards,
Arend
^ permalink raw reply
* Re: [PATCH] ath9k: limit multicast buffer hardware queue depth
From: Jouni Malinen @ 2013-06-05 14:09 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, linville
In-Reply-To: <1370280714-1594-1-git-send-email-nbd@openwrt.org>
On Mon, Jun 03, 2013 at 07:31:54PM +0200, Felix Fietkau wrote:
> The CAB (Content after Beacon) queue is used for beacon-triggered
> transmission of buffered multicast frames. If lots of multicast frames
> were buffered and this queue fills up, it drowns out all regular
> traffic. To limit the damage that buffered traffic can do, try to limit
> the queued data to becaon_interval / 8.
I'm not sure this would be compliant with the standard, but I guess
something along these lines could be reasonable in some cases. However,
it could be useful to take into account different DTIM Period parameters
in the limit and instead of hardcoding this to one eight of the Beacon
interval, the limit could be set based on Beacon interval * DTIM Period.
Especially with large DTIM Period values, one eight of a Beacon interval
may not be sufficient to handle even reasonable amount of group
addressed frames.
Does this commit address More Data field updates when the driver decides
to stop getting more frames without notifying mac80211 of this? The
associated STAs would need to know when they can go back to sleep after
the DTIM Beacon and the More Data field needs to be set to zero in the
last frame the AP is sending out in the case this new limit is hit.
> diff --git a/drivers/net/wireless/ath/ath9k/beacon.c b/drivers/net/wireless/ath/ath9k/beacon.c
> @@ -205,9 +205,15 @@ static struct ath_buf *ath9k_beacon_generate(struct ieee80211_hw *hw,
> while (skb) {
> ath9k_tx_cabq(hw, skb);
> +
> + if (sc->beacon.cabq_dur / 1000 - 1 >
> + sc->cur_beacon_conf.beacon_interval / ATH_BCBUF)
> + break;
> +
> skb = ieee80211_get_buffered_bc(hw, vif);
> }
mac80211 handles the More Data field values based on what is actually
buffered. I don't see how this patch would fix that either by modifying
mac80211 to know that no more buffered frames are sent or by having the
driver update the frame.
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Re: [PATCHv2 3/4] brcm80211: make mgmt_tx in brcmfmac accept a NULL channel
From: Antonio Quartulli @ 2013-06-05 13:57 UTC (permalink / raw)
To: Arend van Spriel
Cc: Antonio Quartulli, Johannes Berg, linux-wireless@vger.kernel.org,
brcm80211-dev-list@broadcom.com
In-Reply-To: <51AF42DC.3000001@broadcom.com>
[-- Attachment #1: Type: text/plain, Size: 846 bytes --]
On Wed, Jun 05, 2013 at 06:53:32AM -0700, Arend van Spriel wrote:
[...]
> > + freq = cfg->channel;
> > + if (chan)
> > + freq = chan->center_freq;
> > + chan_nr = ieee80211_frequency_to_channel(freq);
>
> Could you get rid of 'freq' variable and use
> ieee80211_frequency_to_channel() on cfg->channel or chan->center_freq.
>
I tried that, but the line indented below the if would be longer than 80 chars
and breaking it is quite ugly.
> Another thing is that cfg->channel can be zero resulting in chan_nr
> being zero. I had a quick look whether the device firmware can handle
> this. I suspect not, but I will need to ask to be sure.
>
ok. But when cfg->channel is zero, where is the current freq stored?
Regards,
--
Antonio Quartulli
..each of us alone is worth nothing..
Ernesto "Che" Guevara
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCHv2 3/4] brcm80211: make mgmt_tx in brcmfmac accept a NULL channel
From: Arend van Spriel @ 2013-06-05 13:53 UTC (permalink / raw)
To: Antonio Quartulli
Cc: Johannes Berg, linux-wireless, Antonio Quartulli,
brcm80211-dev-list
In-Reply-To: <1370433187-1337-3-git-send-email-ordex@autistici.org>
On 06/05/2013 01:53 PM, Antonio Quartulli wrote:
> From: Antonio Quartulli <antonio@open-mesh.com>
>
> cfg80211 passes a NULL channel to mgmt_tx if the frame has
> to be sent on the one currently in use by the device.
> Make the implementation of mgmt_tx correctly handle this
> case
>
> Cc: Arend van Spriel <arend@broadcom.com>
> Cc: brcm80211-dev-list@broadcom.com
> Signed-off-by: Antonio Quartulli <antonio@open-mesh.com>
> ---
> drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c b/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
> index 6d758f2..dcb0c00 100644
> --- a/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
> +++ b/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
> @@ -3917,6 +3917,7 @@ brcmf_cfg80211_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
> struct brcmf_fil_af_params_le *af_params;
> bool ack;
> s32 chan_nr;
> + u32 freq;
>
> brcmf_dbg(TRACE, "Enter\n");
>
> @@ -3968,8 +3969,13 @@ brcmf_cfg80211_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
> memcpy(&af_params->bssid[0], &mgmt->bssid[0], ETH_ALEN);
> /* Add the length exepted for 802.11 header */
> action_frame->len = cpu_to_le16(len - DOT11_MGMT_HDR_LEN);
> - /* Add the channel */
> - chan_nr = ieee80211_frequency_to_channel(chan->center_freq);
> + /* Add the channel. Default to the current one, but use the one
> + * specified as parameter if any
> + */
> + freq = cfg->channel;
> + if (chan)
> + freq = chan->center_freq;
> + chan_nr = ieee80211_frequency_to_channel(freq);
Could you get rid of 'freq' variable and use
ieee80211_frequency_to_channel() on cfg->channel or chan->center_freq.
Another thing is that cfg->channel can be zero resulting in chan_nr
being zero. I had a quick look whether the device firmware can handle
this. I suspect not, but I will need to ask to be sure.
Regards,
Arend
^ permalink raw reply
* Re: [PATCH v8] cfg80211: P2P find phase offload
From: Vladimir Kondratiev @ 2013-06-05 13:30 UTC (permalink / raw)
To: Johannes Berg
Cc: Jouni Malinen, Peer, Ilan, linux-wireless@vger.kernel.org,
Rodriguez, Luis, John W . Linville
In-Reply-To: <1370418780.8920.19.camel@jlt4.sipsolutions.net>
On Wednesday, June 05, 2013 09:53:00 AM Johannes Berg wrote:
> > When reporting probes, driver/firmware may do its best to filter out
> > probes that would not be replied with probe-resp accordingly to the
> > P2P rules for active device configuration.
>
> This I think should be more specific. "[W]ould not be replied" is
> clearly one step, but in an environment where you actually want to
> offload the P2P probe responses that is pretty much useless. I'd rather
> say something like:
>
> ---
> When probe response offload it supported, the device should not report
> probe requests to the host that it already responded to. It must report
> (and therefore not respond to) probe requests that indicate the sending
> device is in active PBC mode (specifically, <...add more details...>).
> It may also drop invalid or malformed probe requests or ones that would
> not be replied to for other reasons.
> ---
>
> I think this would be a reasonable tradeoff. It means that if a probe
> request is actually reported, wpa_supplicant must reply to it, and we
> don't have to get into the business of having to decide whether or not
> it needs to respond.
>
> Alternatively, we could specify that the device _must_ respond if
> offload is supported, and then report it.
I like this alternative. Except, reporting is accordingly to the rx filter.
wpa_s may be not interesting in probes at all, or want only ones with PBC.
If device answer probes in firmware, this would reduce CPU wake-ups.
>
> However, we need to clearly specify this so that we don't get two
> responses, one from the device and one from wpa_s. If there's no way to
> specify this, we need to introduce a "reply already sent" flag into the
> frame reporting.
Said above translates to all-or-nothing approach w.r.t. responses:
- If device indicate probe-resp offload, it must reply all probes, supplicant
must not send probe-resp.
- If device does not indicate probe-resp offload, it should never send
probe-resp by itself; it should report all matching probes
and supplicant will generate probe-resp.
Regarding what probes to report, I'd specify relaxed requirements
for the driver:
- in non-offload case, driver must report all matching probes
(but may just report all, and wpa_s will filter)
- in offload case, must report matching probes if rx filter says so. It is not
neccessary to report all probes that device replied to.
I don't want to force firmware or driver to parse probes to detect PBC; if we
got frame to the host, from power perspective there is no much difference who
will filter it - driver or wpa_s; and wpa_s already do this parsing.
For PBC - can one specify "probes with PBC" using existing rx filter mechanism?
Also, I feel this explanation get large, it deserves separate comment block,
it is overkill for start_p2p_find comment. Maybe do it in another patch?
Thanks, Vladimir
^ permalink raw reply
* Re: [bcmdhd] Retransmission packet
From: Arend van Spriel @ 2013-06-05 13:28 UTC (permalink / raw)
To: Matteo; +Cc: brcm80211-dev-list, linux-wireless
In-Reply-To: <7CCB4989-196D-421E-BE73-1EF52F25C381@gmail.com>
+ linux-wireless
On 06/05/2013 02:04 PM, Matteo wrote:
> Hi Arend,
> thank a lot.
>
> yea, I wanted to find the retransmissions of the frame over the air.
> I don't know, if other devices (broadcom or atheros) could give that information.
On Android? I guess any mac80211 based driver could give you that
information. The information is provided by the driver to mac80211 upon
txstatus using struct ieee80211_tx_info::status. The rates field should
contain the rates at which the transmits were attempted and how often
(see explanation of struct ieee80211_tx_rate).
Regards,
Arend
> Thanks again
> Matteo
>
> On Jun 5, 2013, at 10:50 AM, "Arend van Spriel" <arend@broadcom.com> wrote:
>
>> - linux-wireless@vger.kernel.org
>>
>> bcmdhd is not an upstream linux driver so removing that mailing list address.
>>
>> On 06/04/2013 11:20 PM, Matteo Danieletto wrote:
>>> Hi all,
>>>
>>> I am trying to extract the number of retransmissions frame occur during
>>> data transfer between two nodes.
>>
>> I suppose you want the know the retransmissions of the frame over the air. The retries in the code below are over the bus between host and device. So that is not the information you want (right?).
>>
>> The bad news is that the information is not available in the driver.
>>
>> Regards,
>> Arend
>>
>>> I found in did_sdio.c this function:
>>>
>>> 1. /* Writes a HW/SW header into the packet and sends it. */
>>> 2. /* Assumes: (a) header space already there, (b) caller holds lock */
>>> 3. staticint
>>> 4. dhdsdio_txpkt(dhd_bus_t *bus,void*pkt,uint chan,boolfree_pkt)
>>>
>>>
>>> .
>>> .
>>> .
>>> there is this part:
>>>
>>> 1. do{
>>> 2. ret
>>> =dhd_bcmsdh_send_buf(bus,bcmsdh_cur_sbwad(sdh),SDIO_FUNC_2,F2SYNC,
>>> 3. frame,len,pkt,NULL,NULL);
>>> 4. bus->f2txdata++;
>>> 5. ASSERT(ret !=BCME_PENDING);
>>> 6.
>>>
>>> 7. if(ret <0){
>>> 8. /* On failure, abort the command and terminate the frame */
>>> 9. DHD_INFO(("%s: sdio error %d, abort command
>>> and terminate frame.\n",
>>> 10. __FUNCTION__,ret));
>>> 11. bus->tx_sderrs++;
>>> 12.
>>>
>>> 13. bcmsdh_abort(sdh,SDIO_FUNC_2);
>>> 14.
>>> bcmsdh_cfg_write(sdh,SDIO_FUNC_1,SBSDIO_FUNC1_FRAMECTRL,
>>> 15. SFC_WF_TERM,NULL);
>>> 16. bus->f1regdata++;
>>> 17.
>>>
>>> 18. for(i =0;i <3;i++){
>>> 19. uint8 hi,lo;
>>> 20. hi =bcmsdh_cfg_read(sdh,SDIO_FUNC_1,
>>> 21.
>>> SBSDIO_FUNC1_WFRAMEBCHI,NULL);
>>> 22. lo =bcmsdh_cfg_read(sdh,SDIO_FUNC_1,
>>> 23.
>>> SBSDIO_FUNC1_WFRAMEBCLO,NULL);
>>> 24. bus->f1regdata +=2;
>>> 25. if((hi ==0)&&(lo ==0))
>>> 26. break;
>>> 27. }
>>> 28.
>>>
>>> 29. }
>>> 30. if(ret ==0){
>>> 31. bus->tx_seq =(bus->tx_seq
>>> +1)%SDPCM_SEQUENCE_WRAP;
>>> 32. }
>>> 33. }while((ret <0)&&retrydata &&retries++<TXRETRIES);
>>>
>>>
>>>
>>> I exploited iperf to create a data stream between two nodes, but it
>>> never occurred an incrementation of retries variable, then everytime
>>> did_bcmsdh_send_buf returned 0.
>>>
>>> So, I don't know if it is the right point to extract this information
>>> and it never occurred a retransmission, or more it is not possible
>>> extract what I want.
>>>
>>> Thanks a lot
>>>
>>> Matteo
>>>
>>>
>>
>>
>
>
^ permalink raw reply
* Re: carl9170:5/10 MHz Channel Support on carl9170
From: C.B. Wang @ 2013-06-05 12:59 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless
In-Reply-To: <201306042143.06998.chunkeey@googlemail.com>
Hi
I've read the "otus" vendor driver and found that in the source file
/HalPlus/OTUS_FB50/hpreg.h on
line 1915,the comment says "Temporary discard channel that BW < 20MHz
(5 or 10MHz) */
/* Our architecture does not implemnt it"
I think either the driver does not implement the 5/10 channels or
worse,the ar9170 chip does
not support 5/10 mhz channel at all.
But 802.11j has 10mhz channel support.To comply with the 802.11j
standard,the chip should
support 10mhz channel width.
I know ar9170 support 4.9ghz channels.But does it also support
non-standard bands like 2.3ghz and 6.0ghz?
Also the ar9170 MAC was indeed designed by ZyDaS berfore the company
was taken over by
Atheros.It has some problems with long distance links.
On 6/5/13, Christian Lamparter <chunkeey@googlemail.com> wrote:
> On Tuesday, June 04, 2013 03:20:26 PM C.B. Wang wrote:
>> I want to know if the ar9170 chip support 5/10 mhz channels.
> Maybe. if you care about it, you'll have to look for clues in
> the original vendor driver (otus - was part of the kernel's staging/
> directory for < 2.6.39?) and the original vendor firmware
> (ar9170fw - you can find a git-tree @ git.sipsolutions.com).
>
> Anyway, if you need a definitive "yes" or "no", you should
> ask Qualcomm Atheros directly. As I can only tell something
> about the MAC [which does have a 802.11j Mode. It can be
> enabled by setting bit 3 in AR9170_MAC_REG_POWER_STATE_CTRL.]
> However, I don't have any information about the PHY/FEM/RF
> and BB.
>
>> The datasheet says it supports 802.11j, but the carl9170
>> driver does not provide support.
> Again, talk to Qualcomm Atheros to find out what needs to be
> done in order to support it.
>
>> Also the radio chip ar9104 has tuning range from 2.3-2.5ghz and
>> 4.9-6.1ghz,but the driver does not provide any support for these
>> super channels.
> Some AR9170 devices do indeed support the 4.9 GHz channels
> (out of the box). e.g.:
> Frequencies:
> * 4920 MHz [-16] (18.0 dBm)
> * 4940 MHz [-12] (18.0 dBm)
> * 4960 MHz [-8] (18.0 dBm)
> * 4980 MHz [-4] (18.0 dBm)
> * 5040 MHz [8] (18.0 dBm)
> * 5060 MHz [12] (18.0 dBm)
> * 5080 MHz [16] (18.0 dBm)
>
> However, the device needs to be calibrated for the frequencies
> to use them legally (the Japanese Market). Look in your kernel
> logs when the driver is loaded; There should be something like
> this:
>
>> ath: EEPROM regdomain: 0x8xyz
>> ath: EEPROM indicates we should expect a country code
>> ath: doing EEPROM country->regdmn map search
>> ath: Country alpha2 being used: JP <--- JaPan
>
> If your country code is not "JP", then you'll have to talk to
> the manufacturer.
>
> Regards,
> Chr
>
^ permalink raw reply
* Re: [PATCH 1/2] rt2x00: convert rt2x00_ops.extra_tx_headroom to be a fuction
From: Stanislaw Gruszka @ 2013-06-05 12:51 UTC (permalink / raw)
To: Gabor Juhos; +Cc: John Linville, linux-wireless, users
In-Reply-To: <1370429640-31565-1-git-send-email-juhosg@openwrt.org>
On Wed, Jun 05, 2013 at 12:53:59PM +0200, Gabor Juhos wrote:
> The rt2x00_ops structure has a static field to indicate
> the extra TX headroom size required for a given device.
> The drawback of this is that we have to use a separate
> rt2x00_ops structure for each chipset which requires
> different size.
>
> Convert the static field into a callback function.
> This allows the drivers to dynamically determine the
> extra TX headroom size based on the actual chipset.
> Also implement the the callback in the drivers which
> needs an extra TX headroom, and remove the field
> initialization from the others.
>
> Additionally, introduce a new extra_tx_headroom field
> in struct rt2x00_dev, initialize its value in the probe
> routine and use the cached value in the rest of the code.
Could we rather get rid of that extra_tx_headroom variable and use queue
parameters: winfo_size and desc_size ?
Stanislaw
^ permalink raw reply
* Re: [PATCH] cw1200: fix some obvious mistakes
From: Arnd Bergmann @ 2013-06-05 12:08 UTC (permalink / raw)
To: Solomon Peachy
Cc: linux-kernel, John W. Linville, Wei Yongjun, Dmitry Tarnyagin,
Ajitpal Singh, linux-wireless
In-Reply-To: <20130605040802.GA22735@shaftnet.org>
On Wednesday 05 June 2013, Solomon Peachy wrote:
> > Regarding a long-term solution, I think what we should do here is to
> > move the reset logic into the SDIO framework itself: We have similar
> > requirements even for eMMC and SD cards, where you need to provide
> > the correct voltage to a device on the MMC port in order for it to
> > work. Today this is supported to a varying degree on the MMC controller
> > level, where we hook into various frameworks (clk, reset-controller,
> > regulator, gpio, pinctrl, power domain) based on platformm data or
> > device tree information on the controller node.
>
> If I understand you correctly, the "traditional" platform data -- power
> supply, clock source, and gpio (ie POWERUP, RESET) lines would be
> brought up using this mechanism, in order to get the device to attach to
> the SDIO bus. One wrinkle here is that the cw1200 has some minimum
> timing requirements between when each of those signals are brought up; I
> don't know if there's a way to encode that into the devicetree.
If there is a way to know the timings by the SDIO device ID, we should
not need device tree data. However, if the timings need to be set up
right in order to find out the device ID, I think they should go into
the device tree.
> But that's only half the equation.
>
> Once the device has identified it to the SDIO bus and the driver's
> probe() function is called, the other half of the platform data is
> needed to successfully probe the hardware. Namely, the 'ref_clk' field.
> This would need to be made available to the probe() call (eg via
> func->dev.platform_data) but from what I can tell there's currently no
> mechanism to make that connection.
I may not following right what you say here, but I think we need two
separate platform_data structures, one for the SDIO pins, used by the
SDIO layer to set up the clocks and regulators, and a separate
platform_data structure specific to the actual SDIO device, which is
used by the cw1200 driver and attached to the sdio_func.
I think mmc_attach_sdio would be the right place to pass down the
platform_data from the host to the func, if set by the platform.
I notice that this function already sets up the voltage and the
power domain for the card, so adding any further clock/reset/...
code could also be done there, or you model the reset line through
a power domain.
In case of DT booting, we would do the respective thing and
add the device_node pointer for the children of the mmc host to
the sdio devices. We don't currently do that, but it would be
straightforward to add as well.
Arnd
^ permalink raw reply
* [PATCHv2 4/4] ath6kl: make mgmt_tx accept a NULL channel
From: Antonio Quartulli @ 2013-06-05 11:53 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless, Antonio Quartulli, Kalle Valo, Nicolas Cavallari
In-Reply-To: <1370433187-1337-1-git-send-email-ordex@autistici.org>
From: Antonio Quartulli <antonio@open-mesh.com>
cfg80211 passes a NULL channel to mgmt_tx if the frame has
to be sent on the one currently in use by the device.
Make the implementation of mgmt_tx correctly handle this
case
Cc: Kalle Valo <kvalo@qca.qualcomm.com>
Cc: Nicolas Cavallari <Nicolas.Cavallari@lri.fr>
Signed-off-by: Antonio Quartulli <antonio@open-mesh.com>
---
drivers/net/wireless/ath/ath6kl/cfg80211.c | 23 +++++++++++++----------
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/ath/ath6kl/cfg80211.c b/drivers/net/wireless/ath/ath6kl/cfg80211.c
index f7995b2..b542203 100644
--- a/drivers/net/wireless/ath/ath6kl/cfg80211.c
+++ b/drivers/net/wireless/ath/ath6kl/cfg80211.c
@@ -3175,10 +3175,17 @@ static int ath6kl_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
{
struct ath6kl_vif *vif = ath6kl_vif_from_wdev(wdev);
struct ath6kl *ar = ath6kl_priv(vif->ndev);
- u32 id;
+ u32 id, freq;
const struct ieee80211_mgmt *mgmt;
bool more_data, queued;
+ /* default to the current channel, but use the one specified as argument
+ * if any
+ */
+ freq = vif->ch_hint;
+ if (chan)
+ freq = chan->center_freq;
+
mgmt = (const struct ieee80211_mgmt *) buf;
if (vif->nw_type == AP_NETWORK && test_bit(CONNECTED, &vif->flags) &&
ieee80211_is_probe_resp(mgmt->frame_control) &&
@@ -3188,8 +3195,7 @@ static int ath6kl_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
* command to allow the target to fill in the generic IEs.
*/
*cookie = 0; /* TX status not supported */
- return ath6kl_send_go_probe_resp(vif, buf, len,
- chan->center_freq);
+ return ath6kl_send_go_probe_resp(vif, buf, len, freq);
}
id = vif->send_action_id++;
@@ -3205,17 +3211,14 @@ static int ath6kl_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
/* AP mode Power saving processing */
if (vif->nw_type == AP_NETWORK) {
- queued = ath6kl_mgmt_powersave_ap(vif,
- id, chan->center_freq,
- wait, buf,
- len, &more_data, no_cck);
+ queued = ath6kl_mgmt_powersave_ap(vif, id, freq, wait, buf, len,
+ &more_data, no_cck);
if (queued)
return 0;
}
- return ath6kl_wmi_send_mgmt_cmd(ar->wmi, vif->fw_vif_idx, id,
- chan->center_freq, wait,
- buf, len, no_cck);
+ return ath6kl_wmi_send_mgmt_cmd(ar->wmi, vif->fw_vif_idx, id, freq,
+ wait, buf, len, no_cck);
}
static void ath6kl_mgmt_frame_register(struct wiphy *wiphy,
--
1.8.1.5
^ permalink raw reply related
* [PATCHv2 3/4] brcm80211: make mgmt_tx in brcmfmac accept a NULL channel
From: Antonio Quartulli @ 2013-06-05 11:53 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless, Antonio Quartulli, Arend van Spriel,
brcm80211-dev-list
In-Reply-To: <1370433187-1337-1-git-send-email-ordex@autistici.org>
From: Antonio Quartulli <antonio@open-mesh.com>
cfg80211 passes a NULL channel to mgmt_tx if the frame has
to be sent on the one currently in use by the device.
Make the implementation of mgmt_tx correctly handle this
case
Cc: Arend van Spriel <arend@broadcom.com>
Cc: brcm80211-dev-list@broadcom.com
Signed-off-by: Antonio Quartulli <antonio@open-mesh.com>
---
drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c b/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
index 6d758f2..dcb0c00 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
@@ -3917,6 +3917,7 @@ brcmf_cfg80211_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
struct brcmf_fil_af_params_le *af_params;
bool ack;
s32 chan_nr;
+ u32 freq;
brcmf_dbg(TRACE, "Enter\n");
@@ -3968,8 +3969,13 @@ brcmf_cfg80211_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
memcpy(&af_params->bssid[0], &mgmt->bssid[0], ETH_ALEN);
/* Add the length exepted for 802.11 header */
action_frame->len = cpu_to_le16(len - DOT11_MGMT_HDR_LEN);
- /* Add the channel */
- chan_nr = ieee80211_frequency_to_channel(chan->center_freq);
+ /* Add the channel. Default to the current one, but use the one
+ * specified as parameter if any
+ */
+ freq = cfg->channel;
+ if (chan)
+ freq = chan->center_freq;
+ chan_nr = ieee80211_frequency_to_channel(freq);
af_params->channel = cpu_to_le32(chan_nr);
memcpy(action_frame->data, &buf[DOT11_MGMT_HDR_LEN],
--
1.8.1.5
^ permalink raw reply related
* [PATCHv2 1/4] nl80211: allow sending CMD_FRAME without specifying any frequency
From: Antonio Quartulli @ 2013-06-05 11:53 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Antonio Quartulli
From: Antonio Quartulli <antonio@open-mesh.com>
Users may want to send a frame on the current channel
without specifying it.
This is particularly useful for the correct implementation
of the IBSS/RSN support in wpa_supplicant which requires to
receive and send AUTH frames.
Make mgmt_tx pass a NULL channel to the driver if none has
been specified by the user.
Signed-off-by: Antonio Quartulli <antonio@open-mesh.com>
---
net/wireless/nl80211.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 88e820b..06af395 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -7139,6 +7139,9 @@ static int nl80211_tx_mgmt(struct sk_buff *skb, struct genl_info *info)
return -EOPNOTSUPP;
switch (wdev->iftype) {
+ case NL80211_IFTYPE_P2P_DEVICE:
+ if (!info->attrs[NL80211_ATTR_WIPHY_FREQ])
+ return -EINVAL;
case NL80211_IFTYPE_STATION:
case NL80211_IFTYPE_ADHOC:
case NL80211_IFTYPE_P2P_CLIENT:
@@ -7146,7 +7149,6 @@ static int nl80211_tx_mgmt(struct sk_buff *skb, struct genl_info *info)
case NL80211_IFTYPE_AP_VLAN:
case NL80211_IFTYPE_MESH_POINT:
case NL80211_IFTYPE_P2P_GO:
- case NL80211_IFTYPE_P2P_DEVICE:
break;
default:
return -EOPNOTSUPP;
@@ -7174,9 +7176,15 @@ static int nl80211_tx_mgmt(struct sk_buff *skb, struct genl_info *info)
no_cck = nla_get_flag(info->attrs[NL80211_ATTR_TX_NO_CCK_RATE]);
- err = nl80211_parse_chandef(rdev, info, &chandef);
- if (err)
- return err;
+ /* get the channel if any has been specified, otherwise pass NULL to
+ * the driver. The latter will use the current one
+ */
+ chandef.chan = NULL;
+ if (info->attrs[NL80211_ATTR_WIPHY_FREQ]) {
+ err = nl80211_parse_chandef(rdev, info, &chandef);
+ if (err)
+ return err;
+ }
if (!dont_wait_for_ack) {
msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
--
1.8.1.5
^ permalink raw reply related
* [PATCHv2 2/4] mac80211: make mgmt_tx accept a NULL channel
From: Antonio Quartulli @ 2013-06-05 11:53 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Antonio Quartulli
In-Reply-To: <1370433187-1337-1-git-send-email-ordex@autistici.org>
From: Antonio Quartulli <antonio@open-mesh.com>
cfg80211 passes a NULL channel to mgmt_tx if the frame has
to be sent on the one currently in use by the device.
Make the implementation of mgmt_tx correctly handle this
case. Fail if offchan is required.
Signed-off-by: Antonio Quartulli <antonio@open-mesh.com>
---
net/mac80211/cfg.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 3062210..617c5c8 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -2838,6 +2838,12 @@ static int ieee80211_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
return -EOPNOTSUPP;
}
+ /* configurations requiring offchan cannot work if no channel has been
+ * specified
+ */
+ if (need_offchan && !chan)
+ return -EINVAL;
+
mutex_lock(&local->mtx);
/* Check if the operating channel is the requested channel */
@@ -2847,10 +2853,14 @@ static int ieee80211_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
rcu_read_lock();
chanctx_conf = rcu_dereference(sdata->vif.chanctx_conf);
- if (chanctx_conf)
- need_offchan = chan != chanctx_conf->def.chan;
- else
+ if (chanctx_conf) {
+ need_offchan = chan && (chan != chanctx_conf->def.chan);
+ } else if (!chan) {
+ ret = -EINVAL;
+ goto out_unlock;
+ } else {
need_offchan = true;
+ }
rcu_read_unlock();
}
--
1.8.1.5
^ permalink raw reply related
* Re: cw1200: add driver for the ST-E CW1100 & CW1200 WLAN chipsets
From: Kalle Valo @ 2013-06-05 11:36 UTC (permalink / raw)
To: Solomon Peachy; +Cc: Dan Carpenter, linux-wireless
In-Reply-To: <20130605111258.GA15549@shaftnet.org>
Solomon Peachy <pizza@shaftnet.org> writes:
> On Wed, Jun 05, 2013 at 11:06:33AM +0300, Kalle Valo wrote:
>> > I'll try to robustify this rather ugly interface as much as possible.
>>
>> We have nl80211 testmode interface for just stuff like this. I recommend
>> using that instead of debugfs.
>
> When in the so-called etf_mode, the driver doesn't create a netdev. It
> doesn't probe the hardware; it doesn't even (automatically) load
> firmware because it doesn't know what firmware to load. The driver
> becomes a (mostly very dumb) conduit for messages to/from userspace.
>
> That userspace in turn is a thin daemon that listens on a TCP socket and
> relays everything to/from a windows-only highly proprietary vendor tool.
> Everything needed to initialize the hardware (even the dpll value), is
> obtained via these messages.
This is exactly what testmode was written for.
> There's no inherent reason why this daemon couldn't use nl80211 instead,
> but IMO it's not worth the effort to rewrite the driver so it can bring
> up a netdev that (cleanly) fails everything other than nl80211
> testcmds.
What do you mean with bring up netdev? I don't understand.
Even now you call ieee80211_register_hw() before cw1200_debug_init(). At
least from a quick look I don't see any technical reason why you can't
use testmode (unless I'm missing something).
And if there's a problem how testmode is implemented we can always fix
it.
> After all, it'll still be an opaque binary interface whether it uses
> nl80211, custom ioctls, or the existing debugfs interface.
>
> If the existing debugfs interface is too ugly to stomach in the
> mainline, we're better off just stripping it out and maintaining it as
> an out-of-tree patch for the handful of users that need to use the
> vendor tools -- In other words, folks bringing up new hardware designs
> or obtaining FCC(etc) certification.
Again, this is exactly what testmode is for.
We have been working hard to get rid of all sort ugly driver specific
interfaces. If you don't want to use the proper interface then I guess
it's better to remove the custom debugfs interface from cw1200.
--
Kalle Valo
^ permalink raw reply
* Re: ath6kl_sdio blocked by RFKILL
From: Ulf Samuelsson @ 2013-06-05 11:17 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, ath6kl-devel
In-Reply-To: <8738t2nh6a.fsf@kamboji.qca.qualcomm.com>
On 2013-06-01 14:34, Kalle Valo wrote:
> Ulf Samuelsson <ntp@emagii.com> writes:
>
>> Have built the ath6kl_sdio driver for an Cortex-A5 chip using the
>> linux-3.6.9 kernel
>> File system built using Yocto and Busybox RF-Kill.
>>
>> Kernel Config contains:
>>
>> CONFIG_RFKILL=m
>> CONFIG_RFKILL_LEDS=y
>> CONFIG_RFKILL_INPUT=y
>> # CONFIG_RFKILL_GPIO is not set
>>
>> When I do
>>
>> # ifconfig wlan0 up.
>>
>> I get the error message:
>>
>> ifconfig: SIOCSIFFLAGS: Operation not possible due to RF-kill
>>
>> If I run "rfkill list" I get
>>
>> 1: phy1: wlan
>> Soft blocked: yes
>> Hard blocked: no
>>
>>
>> If I try to unblock using "rfkill unblock all" or "wifi" or "wlan",
>> the soft block remains.
> Have you tried "rfkill unblock 1"?
>
Yes, I have now been able to reproduce on another board.
The System has an MMC connector, and if I boot with my SD51 SDIO card in
the connector, then
"rfkill unblock <x>"
won't work, with x = {all,wifi,1 ...}
If I boot without the SD51 card beeing inserted, and then insert if
after theboot has been completed,
then rfkill works as expected.
The MMC host driver is built as a module, maybe it shouldn't.
BR
Ulf Samuelsson
^ permalink raw reply
* Re: [PATCH] brcmsmac: disable power-save related functions
From: Antonio Quartulli @ 2013-06-05 11:11 UTC (permalink / raw)
To: Kalle Valo
Cc: Arend van Spriel, John W. Linville, linux-wireless, David Miller
In-Reply-To: <87zjv43jb8.fsf@purkki.adurom.net>
[-- Attachment #1: Type: text/plain, Size: 2008 bytes --]
On Wed, Jun 05, 2013 at 02:09:47PM +0300, Kalle Valo wrote:
> "Arend van Spriel" <arend@broadcom.com> writes:
>
> > On 06/05/2013 10:44 AM, Kalle Valo wrote:
> >> Kalle Valo <kvalo@adurom.com> writes:
> >>
> >>> "Arend van Spriel" <arend@broadcom.com> writes:
> >>>
> >>>> This patch fixes a regression introduced by:
> >>>>
> >>>> commit 6da3b6c48d79da96a36c2632053cf4f53bf48fb2
> >>>> Author: Hauke Mehrtens <hauke@hauke-m.de>
> >>>> Date: Sun Mar 24 01:45:52 2013 +0100
> >>>>
> >>>> brcmsmac: remove brcms_bss_cfg->associated
> >>>>
> >>>> The regression behaviour is described in:
> >>>>
> >>>> http://www.spinics.net/lists/linux-wireless/msg107474.html
> >>>
> >>> The link is not a very reliable reference, it can die anytime and
> >>> there's no way to know what message it refers to. Stating the message id
> >>> would better. And the best would be to copy the full text to the commit
> >>> log, it's only few lines anyway.
> >>
> >> Johannes gave a handy tip. Gmane has a service which uses message ids:
> >>
> >> http://mid.gmane.org/5197DC4F.7030503@broadcom.com
> >>
> >> If the link or service dies, one can find the email with the message id
> >> visible from the link.
> >>
> >
> > What if gmane dies ;-)
>
> You missed my point. If gmane dies you do this:
>
> http://lmgtfy.com/?q=5197DC4F.7030503%40broadcom.com
>
> :D
>
> The id above is the real message id from the email, that's why you can
> use it to search from email archives, google and so on.
Would it be too hard to copy the text in the commit message? :-)
Why should somebody jump here and there just to get the description of a bug?
Imho, at least a short description should appear here. In this way also David
can immediately figure out what the problem is, without jumping on the web
(imagine many of this in one pull request) :-)
my 2 cents.
Cheers,
--
Antonio Quartulli
..each of us alone is worth nothing..
Ernesto "Che" Guevara
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: cw1200: add driver for the ST-E CW1100 & CW1200 WLAN chipsets
From: Solomon Peachy @ 2013-06-05 11:12 UTC (permalink / raw)
To: Kalle Valo; +Cc: Dan Carpenter, linux-wireless
In-Reply-To: <87d2s13rsm.fsf@purkki.adurom.net>
[-- Attachment #1: Type: text/plain, Size: 1655 bytes --]
On Wed, Jun 05, 2013 at 11:06:33AM +0300, Kalle Valo wrote:
> > I'll try to robustify this rather ugly interface as much as possible.
>
> We have nl80211 testmode interface for just stuff like this. I recommend
> using that instead of debugfs.
When in the so-called etf_mode, the driver doesn't create a netdev. It
doesn't probe the hardware; it doesn't even (automatically) load
firmware because it doesn't know what firmware to load. The driver
becomes a (mostly very dumb) conduit for messages to/from userspace.
That userspace in turn is a thin daemon that listens on a TCP socket and
relays everything to/from a windows-only highly proprietary vendor tool.
Everything needed to initialize the hardware (even the dpll value), is
obtained via these messages.
There's no inherent reason why this daemon couldn't use nl80211 instead,
but IMO it's not worth the effort to rewrite the driver so it can bring
up a netdev that (cleanly) fails everything other than nl80211 testcmds.
After all, it'll still be an opaque binary interface whether it uses
nl80211, custom ioctls, or the existing debugfs interface.
If the existing debugfs interface is too ugly to stomach in the
mainline, we're better off just stripping it out and maintaining it as
an out-of-tree patch for the handful of users that need to use the
vendor tools -- In other words, folks bringing up new hardware designs
or obtaining FCC(etc) certification.
- Solomon
--
Solomon Peachy pizza at shaftnet dot org
Delray Beach, FL ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum viditur.
[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: [PATCH] brcmsmac: disable power-save related functions
From: Kalle Valo @ 2013-06-05 11:09 UTC (permalink / raw)
To: Arend van Spriel; +Cc: John W. Linville, linux-wireless, David Miller
In-Reply-To: <51AEFACD.7000902@broadcom.com>
"Arend van Spriel" <arend@broadcom.com> writes:
> On 06/05/2013 10:44 AM, Kalle Valo wrote:
>> Kalle Valo <kvalo@adurom.com> writes:
>>
>>> "Arend van Spriel" <arend@broadcom.com> writes:
>>>
>>>> This patch fixes a regression introduced by:
>>>>
>>>> commit 6da3b6c48d79da96a36c2632053cf4f53bf48fb2
>>>> Author: Hauke Mehrtens <hauke@hauke-m.de>
>>>> Date: Sun Mar 24 01:45:52 2013 +0100
>>>>
>>>> brcmsmac: remove brcms_bss_cfg->associated
>>>>
>>>> The regression behaviour is described in:
>>>>
>>>> http://www.spinics.net/lists/linux-wireless/msg107474.html
>>>
>>> The link is not a very reliable reference, it can die anytime and
>>> there's no way to know what message it refers to. Stating the message id
>>> would better. And the best would be to copy the full text to the commit
>>> log, it's only few lines anyway.
>>
>> Johannes gave a handy tip. Gmane has a service which uses message ids:
>>
>> http://mid.gmane.org/5197DC4F.7030503@broadcom.com
>>
>> If the link or service dies, one can find the email with the message id
>> visible from the link.
>>
>
> What if gmane dies ;-)
You missed my point. If gmane dies you do this:
http://lmgtfy.com/?q=5197DC4F.7030503%40broadcom.com
:D
The id above is the real message id from the email, that's why you can
use it to search from email archives, google and so on.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] brcmsmac: disable power-save related functions
From: Hauke Mehrtens @ 2013-06-05 11:07 UTC (permalink / raw)
To: Arend van Spriel
Cc: Kalle Valo, John W. Linville, linux-wireless, David Miller
In-Reply-To: <51AEFACD.7000902@broadcom.com>
On 06/05/2013 10:46 AM, Arend van Spriel wrote:
> On 06/05/2013 10:44 AM, Kalle Valo wrote:
>> Kalle Valo <kvalo@adurom.com> writes:
>>
>>> "Arend van Spriel" <arend@broadcom.com> writes:
>>>
>>>> This patch fixes a regression introduced by:
>>>>
>>>> commit 6da3b6c48d79da96a36c2632053cf4f53bf48fb2
>>>> Author: Hauke Mehrtens <hauke@hauke-m.de>
>>>> Date: Sun Mar 24 01:45:52 2013 +0100
>>>>
>>>> brcmsmac: remove brcms_bss_cfg->associated
>>>>
>>>> The regression behaviour is described in:
>>>>
>>>> http://www.spinics.net/lists/linux-wireless/msg107474.html
>>>
>>> The link is not a very reliable reference, it can die anytime and
>>> there's no way to know what message it refers to. Stating the message id
>>> would better. And the best would be to copy the full text to the commit
>>> log, it's only few lines anyway.
>>
>> Johannes gave a handy tip. Gmane has a service which uses message ids:
>>
>> http://mid.gmane.org/5197DC4F.7030503@broadcom.com
>>
>> If the link or service dies, one can find the email with the message id
>> visible from the link.
>>
>
> What if gmane dies ;-)
>
> Gr. AvS
There is also a bugzilla entry for this bug:
https://bugzilla.kernel.org/show_bug.cgi?id=58471
Hauke
^ permalink raw reply
* Re: ath6kl_mgmt_tx with NULL chan
From: Antonio Quartulli @ 2013-06-05 11:00 UTC (permalink / raw)
To: Kalle Valo
Cc: Antonio Quartulli, Nicolas Cavallari, Johannes Berg,
linux-wireless@vger.kernel.org, ath6kl-devel@qca.qualcomm.com
In-Reply-To: <87ppw0j22p.fsf@kamboji.qca.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 387 bytes --]
On Wed, Jun 05, 2013 at 03:15:26AM -0700, Kalle Valo wrote:
> But when modifying that code, please add a check to make sure that
> channel 0 is not used by accident.
Ok, maybe I'll send another patch for this. I don't want to mix a new behaviour
with a fix.
Thanks a lot!
Cheers,
--
Antonio Quartulli
..each of us alone is worth nothing..
Ernesto "Che" Guevara
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH 1/2] rt2x00: convert rt2x00_ops.extra_tx_headroom to be a fuction
From: Gabor Juhos @ 2013-06-05 10:53 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, users, Gabor Juhos
The rt2x00_ops structure has a static field to indicate
the extra TX headroom size required for a given device.
The drawback of this is that we have to use a separate
rt2x00_ops structure for each chipset which requires
different size.
Convert the static field into a callback function.
This allows the drivers to dynamically determine the
extra TX headroom size based on the actual chipset.
Also implement the the callback in the drivers which
needs an extra TX headroom, and remove the field
initialization from the others.
Additionally, introduce a new extra_tx_headroom field
in struct rt2x00_dev, initialize its value in the probe
routine and use the cached value in the rest of the code.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
---
The patch depends on the 'rt2x00: get rid of static data queue descriptors'
series.
---
drivers/net/wireless/rt2x00/rt2400pci.c | 1 -
drivers/net/wireless/rt2x00/rt2500pci.c | 1 -
drivers/net/wireless/rt2x00/rt2500usb.c | 8 +++++++-
drivers/net/wireless/rt2x00/rt2800pci.c | 8 +++++++-
drivers/net/wireless/rt2x00/rt2800usb.c | 13 +++++++++++--
drivers/net/wireless/rt2x00/rt2x00.h | 5 ++++-
drivers/net/wireless/rt2x00/rt2x00dev.c | 10 ++++++++--
drivers/net/wireless/rt2x00/rt2x00queue.c | 6 +++---
drivers/net/wireless/rt2x00/rt61pci.c | 1 -
drivers/net/wireless/rt2x00/rt73usb.c | 8 +++++++-
10 files changed, 47 insertions(+), 14 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2400pci.c b/drivers/net/wireless/rt2x00/rt2400pci.c
index e1ec9a4..3d53a09 100644
--- a/drivers/net/wireless/rt2x00/rt2400pci.c
+++ b/drivers/net/wireless/rt2x00/rt2400pci.c
@@ -1813,7 +1813,6 @@ static const struct rt2x00_ops rt2400pci_ops = {
.eeprom_size = EEPROM_SIZE,
.rf_size = RF_SIZE,
.tx_queues = NUM_TX_QUEUES,
- .extra_tx_headroom = 0,
.queue_init = rt2400pci_queue_init,
.lib = &rt2400pci_rt2x00_ops,
.hw = &rt2400pci_mac80211_ops,
diff --git a/drivers/net/wireless/rt2x00/rt2500pci.c b/drivers/net/wireless/rt2x00/rt2500pci.c
index a1670e8..0ac5c58 100644
--- a/drivers/net/wireless/rt2x00/rt2500pci.c
+++ b/drivers/net/wireless/rt2x00/rt2500pci.c
@@ -2102,7 +2102,6 @@ static const struct rt2x00_ops rt2500pci_ops = {
.eeprom_size = EEPROM_SIZE,
.rf_size = RF_SIZE,
.tx_queues = NUM_TX_QUEUES,
- .extra_tx_headroom = 0,
.queue_init = rt2500pci_queue_init,
.lib = &rt2500pci_rt2x00_ops,
.hw = &rt2500pci_mac80211_ops,
diff --git a/drivers/net/wireless/rt2x00/rt2500usb.c b/drivers/net/wireless/rt2x00/rt2500usb.c
index e5e5479..f8fa2a8 100644
--- a/drivers/net/wireless/rt2x00/rt2500usb.c
+++ b/drivers/net/wireless/rt2x00/rt2500usb.c
@@ -1907,13 +1907,19 @@ static void rt2500usb_queue_init(struct data_queue *queue)
}
}
+static unsigned int
+rt2500usb_extra_tx_headroom(struct rt2x00_dev *rt2x00dev)
+{
+ return TXD_DESC_SIZE;
+}
+
static const struct rt2x00_ops rt2500usb_ops = {
.name = KBUILD_MODNAME,
.max_ap_intf = 1,
.eeprom_size = EEPROM_SIZE,
.rf_size = RF_SIZE,
.tx_queues = NUM_TX_QUEUES,
- .extra_tx_headroom = TXD_DESC_SIZE,
+ .extra_tx_headroom = rt2500usb_extra_tx_headroom,
.queue_init = rt2500usb_queue_init,
.lib = &rt2500usb_rt2x00_ops,
.hw = &rt2500usb_mac80211_ops,
diff --git a/drivers/net/wireless/rt2x00/rt2800pci.c b/drivers/net/wireless/rt2x00/rt2800pci.c
index 260c8b4..4e69792 100644
--- a/drivers/net/wireless/rt2x00/rt2800pci.c
+++ b/drivers/net/wireless/rt2x00/rt2800pci.c
@@ -1224,6 +1224,12 @@ static void rt2800pci_queue_init(struct data_queue *queue)
}
}
+static unsigned int
+rt2800pci_extra_tx_headroom(struct rt2x00_dev *rt2x00dev)
+{
+ return TXWI_DESC_SIZE;
+}
+
static const struct rt2x00_ops rt2800pci_ops = {
.name = KBUILD_MODNAME,
.drv_data_size = sizeof(struct rt2800_drv_data),
@@ -1231,7 +1237,7 @@ static const struct rt2x00_ops rt2800pci_ops = {
.eeprom_size = EEPROM_SIZE,
.rf_size = RF_SIZE,
.tx_queues = NUM_TX_QUEUES,
- .extra_tx_headroom = TXWI_DESC_SIZE,
+ .extra_tx_headroom = rt2800pci_extra_tx_headroom,
.queue_init = rt2800pci_queue_init,
.lib = &rt2800pci_rt2x00_ops,
.drv = &rt2800pci_rt2800_ops,
diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c b/drivers/net/wireless/rt2x00/rt2800usb.c
index b81d509..57729a8 100644
--- a/drivers/net/wireless/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/rt2x00/rt2800usb.c
@@ -898,6 +898,15 @@ static void rt2800usb_queue_init(struct data_queue *queue)
}
}
+static unsigned int
+rt2800usb_extra_tx_headroom(struct rt2x00_dev *rt2x00dev)
+{
+ if (rt2x00_rt(rt2x00dev, RT5592))
+ return TXINFO_DESC_SIZE + TXWI_DESC_SIZE_5592;
+
+ return TXINFO_DESC_SIZE + TXWI_DESC_SIZE;
+}
+
static const struct rt2x00_ops rt2800usb_ops = {
.name = KBUILD_MODNAME,
.drv_data_size = sizeof(struct rt2800_drv_data),
@@ -905,7 +914,7 @@ static const struct rt2x00_ops rt2800usb_ops = {
.eeprom_size = EEPROM_SIZE,
.rf_size = RF_SIZE,
.tx_queues = NUM_TX_QUEUES,
- .extra_tx_headroom = TXINFO_DESC_SIZE + TXWI_DESC_SIZE,
+ .extra_tx_headroom = rt2800usb_extra_tx_headroom,
.queue_init = rt2800usb_queue_init,
.lib = &rt2800usb_rt2x00_ops,
.drv = &rt2800usb_rt2800_ops,
@@ -922,7 +931,7 @@ static const struct rt2x00_ops rt2800usb_ops_5592 = {
.eeprom_size = EEPROM_SIZE,
.rf_size = RF_SIZE,
.tx_queues = NUM_TX_QUEUES,
- .extra_tx_headroom = TXINFO_DESC_SIZE + TXWI_DESC_SIZE_5592,
+ .extra_tx_headroom = rt2800usb_extra_tx_headroom,
.queue_init = rt2800usb_queue_init,
.lib = &rt2800usb_rt2x00_ops,
.drv = &rt2800usb_rt2800_ops,
diff --git a/drivers/net/wireless/rt2x00/rt2x00.h b/drivers/net/wireless/rt2x00/rt2x00.h
index 2a17f7e..41ca342 100644
--- a/drivers/net/wireless/rt2x00/rt2x00.h
+++ b/drivers/net/wireless/rt2x00/rt2x00.h
@@ -648,7 +648,7 @@ struct rt2x00_ops {
const unsigned int eeprom_size;
const unsigned int rf_size;
const unsigned int tx_queues;
- const unsigned int extra_tx_headroom;
+ unsigned int (*extra_tx_headroom)(struct rt2x00_dev *rt2x00dev);
void (*queue_init)(struct data_queue *queue);
const struct rt2x00lib_ops *lib;
const void *drv;
@@ -1007,6 +1007,9 @@ struct rt2x00_dev {
*/
struct list_head bar_list;
spinlock_t bar_list_lock;
+
+ /* Extra TX headroom required for alignment purposes. */
+ unsigned int extra_tx_headroom;
};
struct rt2x00_bar_list_entry {
diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c b/drivers/net/wireless/rt2x00/rt2x00dev.c
index dff5012..964bf1a 100644
--- a/drivers/net/wireless/rt2x00/rt2x00dev.c
+++ b/drivers/net/wireless/rt2x00/rt2x00dev.c
@@ -334,7 +334,7 @@ void rt2x00lib_txdone(struct queue_entry *entry,
/*
* Remove the extra tx headroom from the skb.
*/
- skb_pull(entry->skb, rt2x00dev->ops->extra_tx_headroom);
+ skb_pull(entry->skb, rt2x00dev->extra_tx_headroom);
/*
* Signal that the TX descriptor is no longer in the skb.
@@ -1049,7 +1049,7 @@ static int rt2x00lib_probe_hw(struct rt2x00_dev *rt2x00dev)
*/
rt2x00dev->hw->extra_tx_headroom =
max_t(unsigned int, IEEE80211_TX_STATUS_HEADROOM,
- rt2x00dev->ops->extra_tx_headroom);
+ rt2x00dev->extra_tx_headroom);
/*
* Take TX headroom required for alignment into account.
@@ -1280,6 +1280,12 @@ int rt2x00lib_probe_dev(struct rt2x00_dev *rt2x00dev)
}
}
+ if (rt2x00dev->ops->extra_tx_headroom) {
+ /* Cache TX headroom value */
+ rt2x00dev->extra_tx_headroom =
+ rt2x00dev->ops->extra_tx_headroom(rt2x00dev);
+ }
+
spin_lock_init(&rt2x00dev->irqmask_lock);
mutex_init(&rt2x00dev->csr_mutex);
INIT_LIST_HEAD(&rt2x00dev->bar_list);
diff --git a/drivers/net/wireless/rt2x00/rt2x00queue.c b/drivers/net/wireless/rt2x00/rt2x00queue.c
index c4f1e2b..6c0a91f 100644
--- a/drivers/net/wireless/rt2x00/rt2x00queue.c
+++ b/drivers/net/wireless/rt2x00/rt2x00queue.c
@@ -542,8 +542,8 @@ static int rt2x00queue_write_tx_data(struct queue_entry *entry,
/*
* Add the requested extra tx headroom in front of the skb.
*/
- skb_push(entry->skb, rt2x00dev->ops->extra_tx_headroom);
- memset(entry->skb->data, 0, rt2x00dev->ops->extra_tx_headroom);
+ skb_push(entry->skb, rt2x00dev->extra_tx_headroom);
+ memset(entry->skb->data, 0, rt2x00dev->extra_tx_headroom);
/*
* Call the driver's write_tx_data function, if it exists.
@@ -596,7 +596,7 @@ static void rt2x00queue_bar_check(struct queue_entry *entry)
{
struct rt2x00_dev *rt2x00dev = entry->queue->rt2x00dev;
struct ieee80211_bar *bar = (void *) (entry->skb->data +
- rt2x00dev->ops->extra_tx_headroom);
+ rt2x00dev->extra_tx_headroom);
struct rt2x00_bar_list_entry *bar_entry;
if (likely(!ieee80211_is_back_req(bar->frame_control)))
diff --git a/drivers/net/wireless/rt2x00/rt61pci.c b/drivers/net/wireless/rt2x00/rt61pci.c
index 17507d1..53754bc6 100644
--- a/drivers/net/wireless/rt2x00/rt61pci.c
+++ b/drivers/net/wireless/rt2x00/rt61pci.c
@@ -3066,7 +3066,6 @@ static const struct rt2x00_ops rt61pci_ops = {
.eeprom_size = EEPROM_SIZE,
.rf_size = RF_SIZE,
.tx_queues = NUM_TX_QUEUES,
- .extra_tx_headroom = 0,
.queue_init = rt61pci_queue_init,
.lib = &rt61pci_rt2x00_ops,
.hw = &rt61pci_mac80211_ops,
diff --git a/drivers/net/wireless/rt2x00/rt73usb.c b/drivers/net/wireless/rt2x00/rt73usb.c
index b2e346a..5545fa7 100644
--- a/drivers/net/wireless/rt2x00/rt73usb.c
+++ b/drivers/net/wireless/rt2x00/rt73usb.c
@@ -2394,13 +2394,19 @@ static void rt73usb_queue_init(struct data_queue *queue)
}
}
+static unsigned int
+rt73usb_extra_tx_headroom(struct rt2x00_dev *rt2x00dev)
+{
+ return TXD_DESC_SIZE;
+}
+
static const struct rt2x00_ops rt73usb_ops = {
.name = KBUILD_MODNAME,
.max_ap_intf = 4,
.eeprom_size = EEPROM_SIZE,
.rf_size = RF_SIZE,
.tx_queues = NUM_TX_QUEUES,
- .extra_tx_headroom = TXD_DESC_SIZE,
+ .extra_tx_headroom = rt73usb_extra_tx_headroom,
.queue_init = rt73usb_queue_init,
.lib = &rt73usb_rt2x00_ops,
.hw = &rt73usb_mac80211_ops,
--
1.7.10
^ permalink raw reply related
* [PATCH 2/2] rt2x00: rt2800usb: nuke rt2800usb_ops_5592
From: Gabor Juhos @ 2013-06-05 10:54 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, users, Gabor Juhos
In-Reply-To: <1370429640-31565-1-git-send-email-juhosg@openwrt.org>
It is exactly the same like the generic rt2800usb_ops.
Remove the duplicate and use the generic ops for all
devices.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
---
drivers/net/wireless/rt2x00/rt2800usb.c | 30 +++++-------------------------
1 file changed, 5 insertions(+), 25 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c b/drivers/net/wireless/rt2x00/rt2800usb.c
index 57729a8..c065d43 100644
--- a/drivers/net/wireless/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/rt2x00/rt2800usb.c
@@ -924,23 +924,6 @@ static const struct rt2x00_ops rt2800usb_ops = {
#endif /* CONFIG_RT2X00_LIB_DEBUGFS */
};
-static const struct rt2x00_ops rt2800usb_ops_5592 = {
- .name = KBUILD_MODNAME,
- .drv_data_size = sizeof(struct rt2800_drv_data),
- .max_ap_intf = 8,
- .eeprom_size = EEPROM_SIZE,
- .rf_size = RF_SIZE,
- .tx_queues = NUM_TX_QUEUES,
- .extra_tx_headroom = rt2800usb_extra_tx_headroom,
- .queue_init = rt2800usb_queue_init,
- .lib = &rt2800usb_rt2x00_ops,
- .drv = &rt2800usb_rt2800_ops,
- .hw = &rt2800usb_mac80211_ops,
-#ifdef CONFIG_RT2X00_LIB_DEBUGFS
- .debugfs = &rt2800_rt2x00debug,
-#endif /* CONFIG_RT2X00_LIB_DEBUGFS */
-};
-
/*
* rt2800usb module information.
*/
@@ -1253,15 +1236,15 @@ static struct usb_device_id rt2800usb_device_table[] = {
#endif
#ifdef CONFIG_RT2800USB_RT55XX
/* Arcadyan */
- { USB_DEVICE(0x043e, 0x7a32), .driver_info = 5592 },
+ { USB_DEVICE(0x043e, 0x7a32) },
/* AVM GmbH */
- { USB_DEVICE(0x057c, 0x8501), .driver_info = 5592 },
+ { USB_DEVICE(0x057c, 0x8501) },
/* D-Link DWA-160-B2 */
- { USB_DEVICE(0x2001, 0x3c1a), .driver_info = 5592 },
+ { USB_DEVICE(0x2001, 0x3c1a) },
/* Proware */
- { USB_DEVICE(0x043e, 0x7a13), .driver_info = 5592 },
+ { USB_DEVICE(0x043e, 0x7a13) },
/* Ralink */
- { USB_DEVICE(0x148f, 0x5572), .driver_info = 5592 },
+ { USB_DEVICE(0x148f, 0x5572) },
#endif
#ifdef CONFIG_RT2800USB_UNKNOWN
/*
@@ -1366,9 +1349,6 @@ MODULE_LICENSE("GPL");
static int rt2800usb_probe(struct usb_interface *usb_intf,
const struct usb_device_id *id)
{
- if (id->driver_info == 5592)
- return rt2x00usb_probe(usb_intf, &rt2800usb_ops_5592);
-
return rt2x00usb_probe(usb_intf, &rt2800usb_ops);
}
--
1.7.10
^ permalink raw reply related
* Re: ath6kl_mgmt_tx with NULL chan
From: Kalle Valo @ 2013-06-05 10:15 UTC (permalink / raw)
To: Antonio Quartulli
Cc: Antonio Quartulli, Nicolas Cavallari, Johannes Berg,
linux-wireless@vger.kernel.org, ath6kl-devel@qca.qualcomm.com
In-Reply-To: <20130605100332.GB2349@open-mesh.com>
Antonio Quartulli <antonio@open-mesh.com> writes:
> On Wed, Jun 05, 2013 at 02:57:07AM -0700, Kalle Valo wrote:
>> Antonio Quartulli <ordex@autistici.org> writes:
>>
>> > I'm looking at ath6kl_mgmt_tx() in ath6kl/cfg80211.c and I've seen that the
>> > currently "configured" frequency can be obtained by reading the
>> > ath6kl_vif->ch_hint field.
>> >
>> > But, is this correct?
>>
>> I did a quick look. To me using ch_hint looks correct.
>>
>> > I couldn't see any real relation between the ch_hint field and the
>> > real frequency (probably because a lot of logic is hidden to the
>> > driver). I could only understand that the ch_hint field stores the
>> > frequency passed as parameter during the connection, but I have found
>> > no guarantee that this is the really used one.
>>
>> Can you be more specific, please?
>>
>> To me it looks that ch_hint is used both with ath6kl_wmi_reconnect_cmd()
>> and ath6kl_wmi_connect_cmd() commands, which both are used to connect to
>> a network. I don't see any other variables used for specifying the
>> frequency to the firmware. But I could just be blind...
>
> I agree with your analysis. My doubt came from the fact that I don't know what
> the firmware does and I was wondering whether it could ignore the channel passed
> as argument on connect for some reason.
It might do that, I'm not involved with the firmware development.
> Actually the doubt was raised due to the variable name "ch_HINT".
Yeah, the name is really misleading. But that's still legacy from the
pre-cleanup driver, so I wouldn't worry about that too much.
> But you are the ath6k expert :-) Therefore I guess this can work.
It should but you never know :)
But when modifying that code, please add a check to make sure that
channel 0 is not used by accident.
--
Kalle Valo
^ permalink raw reply
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