* Re: [PATCH] sdio: pass unknown cis tuples to sdio drivers
From: Albert Herranz @ 2009-09-11 8:28 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-mmc, bcm43xx-dev, linux-wireless
In-Reply-To: <20090911010102.4c7840b0.akpm@linux-foundation.org>
--- El vie, 11/9/09, Andrew Morton <akpm@linux-foundation.org> escribió:
> > >
> > > ret == -EINVAL
> > >
> >
> > At this point ret is not -EINVAL.
>
> Yes it is. We just did
>
> ret = -EINVAL;
>
>
> If that assignment happens, we leak `this'.
>
Hi Andrew,
I misunderstood you. I thought that you were trying to imply on your original comment that retval was _already_ -EINVAL at that point.
Now I see the issue. `this' should be freed if successfully parsed (!ret) or if invalid and not going to be passed to a SDIO driver (ret == -EINVAL).
Thanks for catching that. I'll send an updated patch.
Cheers,
Albert
^ permalink raw reply
* [PATCH] cfg80211: use cfg80211_wext_freq() for freq conversion
From: Holger Schurig @ 2009-09-11 8:13 UTC (permalink / raw)
To: John W Linville, linux-wireless, Johannes Berg
WEXT's "struct iw_freq" can also be used to handle a channel. This patch now
uses cfg80211_wext_freq() instead of hand-converting the frequency. That
allows user-space to specify channels as well, like with SIOCSIWFREQ.
Signed-off-by: Holger Schurig <hs4233@mail.mn-solutions.de>
Index: linux-wl/net/wireless/scan.c
===================================================================
--- linux-wl.orig/net/wireless/scan.c 2009-09-11 09:05:27.000000000 +0200
+++ linux-wl/net/wireless/scan.c 2009-09-11 09:05:39.000000000 +0200
@@ -662,7 +662,7 @@ int cfg80211_wext_siwscan(struct net_dev
int k;
int wiphy_freq = wiphy->bands[band]->channels[j].center_freq;
for (k = 0; k < wreq->num_channels; k++) {
- int wext_freq = wreq->channel_list[k].m / 100000;
+ int wext_freq = cfg80211_wext_freq(wiphy, &wreq->channel_list[k]);
if (wext_freq == wiphy_freq)
goto wext_freq_found;
}
--
M&N Solutions GmbH Ein Unternehmen der Datagroup AG
Holger Schurig
Raiffeisenstr. 10
61191 Rosbach
Tel: 06003/9141-15 Fax 06003/9141-49
http://www.mn-solutions.de/
Handelsregister Friedberg, HRB 5903
Geschäftsführer: P.Schrittenlocher
^ permalink raw reply
* Re: [PATCH] sdio: pass unknown cis tuples to sdio drivers
From: Albert Herranz @ 2009-09-11 8:21 UTC (permalink / raw)
To: Pierre Ossman; +Cc: akpm, linux-mmc, bcm43xx-dev, linux-wireless
In-Reply-To: <20090911080659.2ac822fc@mjolnir.ossman.eu>
--- El vie, 11/9/09, Pierre Ossman <pierre@ossman.eu> escribió:
> The description for this patch should be made clearer. The title
> suggests it adds functionality that's already in place. It should be
> something along the lines of "Also pass malformed tuples to
> card drivers".
Hi Pierre,
Thanks for your patch review.
I didn't want to use "malformed" in the first place. I used "unknown" as "unknown to the SDIO core". The SDIO core in Linux only knows about FUNCE tuples of type 1 (with a sane length) as described in the SDIO Simplified Spec V2.00.
I think we just have a language issue here, but if you prefer the "malformed" wording I'm ok with that.
> In the sake of sanity, you might want to add this behaviour to all
> parsers, not just the FUNCE one.
I didn't find an application for the other parsers yet, so I tried to stick to the strictly necessary and just did the FUNCE one which has a direct application for Broadcom cards.
>
> I'm also unclear on how this is supposed to work. What does the
> broadcom tuple look like? This patch looks like it will silence a lot
> of legitimate warnings, and possibly pollute the card structures with
> bogus data.
The contents of the Broadcom FUNCE (type 0x22) tuple that contains the MAC address of a card looks like the following (tuple size 8):
04 06 00 1d bc 62 79 fd
^^ ^^ ^^^^^^^^^^^^^^^^^
| | |
| | +--- MAC address
| +--------------------- length (6 bytes for a ethernet MAC address)
+------------------------ type 4 (CISTPL_FUNCE_LAN_NODE_ID)
If you prefer it, instead of passing al "unknown" (or "malformed") FUNCE tuples to SDIO drivers, I can let through only a subset of whitelisted FUNCE types (starting with type 4).
>
> > diff --git a/drivers/mmc/core/sdio_cis.c b/drivers/mmc/core/sdio_cis.c
> > index 963f293..87934ac 100644
> > --- a/drivers/mmc/core/sdio_cis.c
> > +++ b/drivers/mmc/core/sdio_cis.c
> > @@ -123,8 +123,9 @@ static int cistpl_funce_func(struct sdio_func *func,
> > vsn = func->card->cccr.sdio_vsn;
> > min_size = (vsn == SDIO_SDIO_REV_1_00) ? 28 : 42;
> >
> > + /* let the SDIO driver take care of unknown tuples */
> > if (size < min_size || buf[0] != 1)
>
> Misleading comment, the tuple is not unknown.
>
Same language issue described before.
> > - return -EINVAL;
> > + return -EILSEQ;
> >
>
> What does this change improve?
-EILSEQ is used to indicate that the tuple was not parsed by the SDIO core and should be passed to the SDIO driver via the SDIO func tuple list.
>
> > /* TPLFE_MAX_BLK_SIZE */
> > func->max_blksize =
> buf[12] | (buf[13] << 8);
> > @@ -154,13 +155,7 @@ static int cistpl_funce(struct mmc_card *card, struct sdio_func *func,
> > else
> > ret = cistpl_funce_common(card, buf, size);
> >
> > - if (ret) {
> > - printk(KERN_ERR "%s: bad CISTPL_FUNCE size %u "
> > - "type %u\n", mmc_hostname(card->host), size, buf[0]);
> > - return ret;
> > - }
> > -
> > - return 0;
> > + return ret;
> > }
> >
> > typedef int (tpl_parse_t)(struct mmc_card *, struct sdio_func *,
>
> Silencing a legitimate error.
>
Yes, I see your point.
I think we can keep this code but prevent displaying the error if ret == -EILSEQ (i.e. the tuple is "unknown"/"malformed" BUT should be passed to the SDIO driver for parsing).
> > + if (ret == -EILSEQ) {
> > +
> /* this tuple is unknown to the core */
>
> Misleading comment, the tuple might be known but malformed.
Same languange issue again.
>
> Rgds
> --
> -- Pierre Ossman
Thanks a lot for your comments,
Albert
^ permalink raw reply
* [PATCH] cfg80211: minimal error handling for wext-compat freq scanning
From: Holger Schurig @ 2009-09-11 8:13 UTC (permalink / raw)
To: John W Linville, linux-wireless; +Cc: Johannes Berg
Signed-off-by: Holger Schurig <hs4233@mail.mn-solutions.de>
Index: linux-wl/net/wireless/scan.c
===================================================================
--- linux-wl.orig/net/wireless/scan.c 2009-09-11 09:05:39.000000000 +0200
+++ linux-wl/net/wireless/scan.c 2009-09-11 09:05:42.000000000 +0200
@@ -680,6 +680,11 @@ int cfg80211_wext_siwscan(struct net_dev
err = -EINVAL;
goto out;
}
+ /* No channels found? */
+ if (!i) {
+ err = -EINVAL;
+ goto out;
+ }
/* Set real number of channels specified in creq->channels[] */
creq->n_channels = i;
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: [PATCH] sdio: pass unknown cis tuples to sdio drivers
From: Andrew Morton @ 2009-09-11 8:01 UTC (permalink / raw)
To: Albert Herranz; +Cc: linux-mmc, bcm43xx-dev, linux-wireless
In-Reply-To: <354996.83066.qm@web28302.mail.ukl.yahoo.com>
On Fri, 11 Sep 2009 07:52:11 +0000 (GMT) Albert Herranz <albert_herranz@yahoo.es> wrote:
> --- El vie, 11/9/09, Andrew Morton <akpm@linux-foundation.org> escribi__:
> > > Some manufacturers provide vendor information in
> > non-vendor specific CIS
> > > tuples. For example, Broadcom uses an Extended
> > Function tuple to provide
> > > the MAC address on some of their network cards, as in
> > the case of the
> > > Nintendo Wii WLAN daughter card.
> > >
> > > This patch allows passing correct tuples unknown to
> > the SDIO core to
> > > a matching SDIO driver instead of rejecting them and
> > failing.
> > >
> >
> > This looks leaky to me.
> >
>
> Hi Andrew, thanks for the review.
> I hope I can clarify a bit what the patch does in the next comments.
>
> >
> > : ______ ______ if (i < ARRAY_SIZE(cis_tpl_list)) {
argh, now yahoo mail is converting tabs to 0xa0's as well. Despair.
> > : ______ ______ ______ const struct cis_tpl *tpl = cis_tpl_list + i;
> > : ______ ______ ______ if (tpl_link < tpl->min_size) {
> > : ______ ______ ______ ______ printk(KERN_ERR
> > : ______ ______ ______ ______ __ __ ______"%s: bad CIS tuple 0x%02x"
> > : ______ ______ ______ ______ __ __ ______" (length = %u, expected >= %u)\n",
> > : ______ ______ ______ ______mmc_hostname(card->host),
> > : ______ ______ ______ ______ __ __ ______tpl_code, tpl_link, tpl->min_size);
> > : ______ ______ ______ ______ ret = -EINVAL;
> >
> > ret == -EINVAL
> >
>
> At this point ret is not -EINVAL.
Yes it is. We just did
ret = -EINVAL;
If that assignment happens, we leak `this'.
^ permalink raw reply
* Re: [PATCH] cfg80211: allow scanning on specified frequencies when using wext-compatibility
From: Holger Schurig @ 2009-09-11 7:52 UTC (permalink / raw)
To: Johannes Berg; +Cc: John W Linville, linux-wireless
In-Reply-To: <1252629664.23427.4.camel@johannes.local>
> This is a bit weird -- this way you don't report errors if the
> user specified frequencies that don't exist.
The old code did this:
Loop over all bands
Loop over all channels
Stick channel to scan request
I simply added this:
Loop over all bands
Loop over all channels
If scan-request hasn't this channel freq: continue
Stick channel to scan request
Now, if I want to report an -EINVAL for every possibly invalid
scan-request channel, I'd have to do this:
If scan-request has freqs:
Loop over all scan-request freqs
Loop over all bands
Loop over all channels
search for freq
if found:
Stick channel to scan request
else:
err = -EINVAL
else:
Loop over all bands
Loop over all channels
Stick channel to scan request
This is considerable code-bloat for such a seldom-used function.
I'd rather do it like this:
Loop over all bands
Loop over all channels
If scan-request hasn't this channel freq: continue
Stick channel to scan request
if no channels:
err = -EINVAL
That's a compromise :-)
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: [PATCH] sdio: pass unknown cis tuples to sdio drivers
From: Albert Herranz @ 2009-09-11 7:52 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-mmc, bcm43xx-dev, linux-wireless
In-Reply-To: <20090910203951.041d5c17.akpm@linux-foundation.org>
--- El vie, 11/9/09, Andrew Morton <akpm@linux-foundation.org> escribió:
> > Some manufacturers provide vendor information in
> non-vendor specific CIS
> > tuples. For example, Broadcom uses an Extended
> Function tuple to provide
> > the MAC address on some of their network cards, as in
> the case of the
> > Nintendo Wii WLAN daughter card.
> >
> > This patch allows passing correct tuples unknown to
> the SDIO core to
> > a matching SDIO driver instead of rejecting them and
> failing.
> >
>
> This looks leaky to me.
>
Hi Andrew, thanks for the review.
I hope I can clarify a bit what the patch does in the next comments.
>
> : if (i < ARRAY_SIZE(cis_tpl_list)) {
> : const struct cis_tpl *tpl = cis_tpl_list + i;
> : if (tpl_link < tpl->min_size) {
> : printk(KERN_ERR
> : "%s: bad CIS tuple 0x%02x"
> : " (length = %u, expected >= %u)\n",
> : mmc_hostname(card->host),
> : tpl_code, tpl_link, tpl->min_size);
> : ret = -EINVAL;
>
> ret == -EINVAL
>
At this point ret is not -EINVAL. If it was -EINVAL the code would have had exit at this snipped before:
if (ret) {
kfree(this);
break;
}
> : } else if (tpl->parse) {
> : ret = tpl->parse(card, func,
> : this->data, tpl_link);
> : }
> : /* already successfully parsed, not needed anymore */
> : if (!ret)
> : kfree(this);
>
> `this' doesn't get freed
>
Yes, that's the whole point of the patch. It must be freed _only_ if the SDIO core parsed it. If the SDIO core cannot parse it then it gets passed to the SDIO driver via the SDIO func struct tuple list (later).
> : } else {
> : /* unknown tuple */
> : ret = -EILSEQ;
> : }
> :
> : if (ret == -EILSEQ) {
>
> `this' doesn't get remembered.
>
When ret is -EILSEQ `this' is linked to the SDIO func tuple list (later).
> : /* this tuple is unknown to the core */
> : this->next = NULL;
> : this->code = tpl_code;
> : this->size = tpl_link;
> : *prev = this;
> : prev = &this->next;
> : pr_debug("%s: queuing CIS tuple 0x%02x length %u\n",
> : mmc_hostname(card->host), tpl_code, tpl_link);
> : /* keep on analyzing tuples */
> : ret = 0;
> : }
> :
> : ptr += tpl_link;
>
> `this' leaks.
>
`this' doesn't leak. `this' has been linked to the SDIO func tuple list in:
*prev = this;
> : } while (!ret);
>
> Please check?
>
Thanks a lot for you comments,
Albert
^ permalink raw reply
* Re: [PATCH] cfg80211: allow scanning on specified frequencies when using wext-compatibility
From: Holger Schurig @ 2009-09-11 7:35 UTC (permalink / raw)
To: Johannes Berg; +Cc: John W Linville, linux-wireless
In-Reply-To: <1252629664.23427.4.camel@johannes.local>
> This is a bit weird -- this way you don't report errors if the
> user specified frequencies that don't exist.
Couldn't / shouldn't this done in user-space, e.g. after checking
IWRANGE.
> Also, are you sure that it has to be a frequency as opposed to
> a channel number?
I'm not totally sure, because there's nowhere any documentation
about the exact meanings of fields in "struct iw_freq". My patch
for wpa_supplicant's driver_wext.c only put's a frequency there:
+ req.channel_list[i].m = params->freqs[i] * 100000;
+ req.channel_list[i].e = 1;
+ req.channel_list[i].i = i;
+ req.channel_list[i].flags = 0;
But now that you bring this into my mind, I should have looked
at another consumer of "struct iw_freq", e.g. I should use
cfg80211_wext_freq() like cfg80211_wext_siwfreq() ?!?
I'll prepare some patch.
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: [PATCH 3/4] ath5k: define ath_common ops
From: Luis R. Rodriguez @ 2009-09-11 7:23 UTC (permalink / raw)
To: Jiri Slaby
Cc: Nick Kossifidis, devel, ath9k-devel, linux-wireless, Alan Cox,
Linus Torvalds, Jeff Garzik
In-Reply-To: <4AA9F22C.3090007@gmail.com>
On Thu, Sep 10, 2009 at 11:46 PM, Jiri Slaby <jirislaby@gmail.com> wrote:
> On 09/11/2009 08:16 AM, Nick Kossifidis wrote:
>>> static inline u32 ath5k_hw_reg_read(struct ath5k_hw *ah, u16 reg)
>>> {
>>> - return ioread32(ah->ah_iobase + reg);
>>> + return ath5k_hw_common(ah)->ops->read(ah, reg);
>>> }
>>>
>>> -/*
>>> - * Write to a register
>>> - */
>>> static inline void ath5k_hw_reg_write(struct ath5k_hw *ah, u32 val, u16 reg)
>>> {
>>> - iowrite32(val, ah->ah_iobase + reg);
>>> + ath5k_hw_common(ah)->ops->write(ah, reg, val);
> ...
>> Since each driver will use it's own reg read/write functions (ath5k hw
>> code still uses ath5k_hw_reg_read/write), why do we need to have
>> common reg read/write functions like that used in the driver code ?
>> This makes the code more complex that it needs to be and i don't see a
>> reason why we need it. I understand why we need a way to handle
>> read/write functions from common ath code but i don't see a reason to
>> use these functions on ath5k, we can just fill ath_ops struct so that
>> common code can use them and leave ath5k_hw_read/write untouched.
>
> I definitely agree with Nick here. Althought whole ath_ops will be hot
> cache after the first operation, there is no need to prolong hot paths
> by computing the op address and a call. Ok, read/write on PCI is pretty
> slow, but still...
That is the way I had it originally before submission, and I
completely agree its reasonable to not incur additional cost at the
expense of having two separate read/write paths, and perhaps we should
only incur the extra cost on routines shared between
ath9k/ath9k/ath9k_htc. But -- is there really is a measurable cost
penalty?
This is why I asked if someone can test and give measurable
differences over this. If there really isn't then that's not strong
point against it.
For example, long ago I had argued over the cost incurred over the
unnecessary branching on ioread()/iowrite() when you know you have
MMIO devices [1] -- the defense then, and IMHO reasonable now, was
that the benefits of allowing cleaner drivers through the new
interfaces outweigh the theoretical penalties imposed by them.
Granted you can argue these new interfaces between
ath5k/ath9k/ath9k_htc would make things a little more complex, but I
would expect sharing the code will help in the end. And if these
interfaces are not acceptable I'm completely open to better suggested
alternatives.
[1] http://lkml.indiana.edu/hypermail/linux/kernel/0709.2/1068.html
Luis
^ permalink raw reply
* Re: [PATCH 3/4] ath5k: define ath_common ops
From: Jiri Slaby @ 2009-09-11 6:46 UTC (permalink / raw)
To: Nick Kossifidis; +Cc: Luis R. Rodriguez, devel, ath9k-devel, linux-wireless
In-Reply-To: <40f31dec0909102316q7902098jbee7fd8d17c3f622@mail.gmail.com>
On 09/11/2009 08:16 AM, Nick Kossifidis wrote:
>> static inline u32 ath5k_hw_reg_read(struct ath5k_hw *ah, u16 reg)
>> {
>> - return ioread32(ah->ah_iobase + reg);
>> + return ath5k_hw_common(ah)->ops->read(ah, reg);
>> }
>>
>> -/*
>> - * Write to a register
>> - */
>> static inline void ath5k_hw_reg_write(struct ath5k_hw *ah, u32 val, u16 reg)
>> {
>> - iowrite32(val, ah->ah_iobase + reg);
>> + ath5k_hw_common(ah)->ops->write(ah, reg, val);
...
> Since each driver will use it's own reg read/write functions (ath5k hw
> code still uses ath5k_hw_reg_read/write), why do we need to have
> common reg read/write functions like that used in the driver code ?
> This makes the code more complex that it needs to be and i don't see a
> reason why we need it. I understand why we need a way to handle
> read/write functions from common ath code but i don't see a reason to
> use these functions on ath5k, we can just fill ath_ops struct so that
> common code can use them and leave ath5k_hw_read/write untouched.
I definitely agree with Nick here. Althought whole ath_ops will be hot
cache after the first operation, there is no need to prolong hot paths
by computing the op address and a call. Ok, read/write on PCI is pretty
slow, but still...
^ permalink raw reply
* Re: [PATCH 06/10] ath5k: use common curbssid, bssidmask and macaddr
From: Nick Kossifidis @ 2009-09-11 6:20 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linville, linux-wireless, ath9k-devel, devel
In-Reply-To: <1252611027-5285-7-git-send-email-lrodriguez@atheros.com>
2009/9/10 Luis R. Rodriguez <lrodriguez@atheros.com>:
>
> -
> -/****************\
> -* BSSID handling *
> -\****************/
> -
No need to remove that unless all bssid related functions are gone.
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
^ permalink raw reply
* Re: [b43] About supporting of BCM4312 [14e4:4315] with Low Power PHY
From: Gábor Stefanik @ 2009-09-11 6:18 UTC (permalink / raw)
To: Bryan Wu; +Cc: mb, stefano.brivio, linux-wireless
In-Reply-To: <4AA9B46E.8020100@canonical.com>
This chip works (though not quite "supported", that is, can't
guarantee that it will work for you, and speed is not up to par with
wl_hybrid) in wireless-testing. It should also work in
compat-wireless, though compat-wireless is having problems with 64-bit
DMA lately (probably also affects the G-PHY 4311/02). Specifically,
the Dell 1397 (half-mini version of the 1395) and the HP 459263-002
are known to work.
On Fri, Sep 11, 2009 at 4:22 AM, Bryan Wu <bryan.wu@canonical.com> wrote:
> Dear Michael and Stefano,
>
> I have a project which integrate Broadcom Wifi chip. But the mainline b43 still does not support this chip, because it has Low Power PHY.
>
> Here is my lspci -vvnn output for this device:
> ------
> 07:00.0 Network controller [0280]: Broadcom Corporation BCM4312 802.11b/g [14e4:4315] (rev 01)
> Subsystem: Dell Device [1028:000c]
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0, Cache Line Size: 32 bytes
> Interrupt: pin A routed to IRQ 17
> Region 0: Memory at f0100000 (64-bit, non-prefetchable) [size=16K]
> Capabilities: [40] Power Management version 3
> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
> Status: D0 PME-Enable- DSel=0 DScale=2 PME-
> Capabilities: [58] Vendor Specific Information <?>
> Capabilities: [e8] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
> Address: 0000000000000000 Data: 0000
> Capabilities: [d0] Express (v1) Endpoint, MSI 00
> DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <4us, L1 unlimited
> ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
> DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
> RlxdOrd- ExtTag+ PhantFunc- AuxPwr- NoSnoop-
> MaxPayload 128 bytes, MaxReadReq 128 bytes
> DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend-
> LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <4us, L1 <64us
> ClockPM+ Suprise- LLActRep- BwNot-
> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
> Kernel driver in use: b43-pci-bridge
> Kernel modules: ssb
> ------
>
> Do you guys know how to support this device in 2.6.31 kernel? Need I backport some code from wireless-testing? I enabled the PHY_LP config manually in 2.6.31 kernel and b43 driver recognized the hardware wifi device, but it still
> does not work at all.
>
> Or there is no choice but Broadcom's STA driver? I do not like such non-GPL stuff.
>
> Thanks a lot
> --
> Bryan Wu <bryan.wu@canonical.com>
> Kernel Developer +86.138-1617-6545 Mobile
> Ubuntu Kernel Team | Hardware Enablement Team
> Canonical Ltd. www.canonical.com
> Ubuntu - Linux for human beings | www.ubuntu.com
> --
> 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
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: [PATCH 3/4] ath5k: define ath_common ops
From: Nick Kossifidis @ 2009-09-11 6:16 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linville, linux-wireless, ath9k-devel, devel
In-Reply-To: <1252632895-11914-4-git-send-email-lrodriguez@atheros.com>
2009/9/11 Luis R. Rodriguez <lrodriguez@atheros.com>:
> All read/write ops now go through the common ops.
>
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> ---
> drivers/net/wireless/ath/ath5k/ath5k.h | 20 ++++++++++++--------
> drivers/net/wireless/ath/ath5k/base.c | 17 +++++++++++++++++
> drivers/net/wireless/ath/ath5k/base.h | 11 -----------
> 3 files changed, 29 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath5k/ath5k.h b/drivers/net/wireless/ath/ath5k/ath5k.h
> index 29ce868..997101b 100644
> --- a/drivers/net/wireless/ath/ath5k/ath5k.h
> +++ b/drivers/net/wireless/ath/ath5k/ath5k.h
> @@ -1315,20 +1315,24 @@ static inline unsigned int ath5k_hw_clocktoh(unsigned int clock, bool turbo)
> return turbo ? (clock / 80) : (clock / 40);
> }
>
> -/*
> - * Read from a register
> - */
> +static inline struct ath_common *ath5k_hw_common(struct ath5k_hw *ah)
> +{
> + return &ah->common;
> +}
> +
> +static inline struct ath_regulatory *ath5k_hw_regulatory(struct ath5k_hw *ah)
> +{
> + return &(ath5k_hw_common(ah)->regulatory);
> +}
> +
> static inline u32 ath5k_hw_reg_read(struct ath5k_hw *ah, u16 reg)
> {
> - return ioread32(ah->ah_iobase + reg);
> + return ath5k_hw_common(ah)->ops->read(ah, reg);
> }
>
> -/*
> - * Write to a register
> - */
> static inline void ath5k_hw_reg_write(struct ath5k_hw *ah, u32 val, u16 reg)
> {
> - iowrite32(val, ah->ah_iobase + reg);
> + ath5k_hw_common(ah)->ops->write(ah, reg, val);
> }
>
> #if defined(_ATH5K_RESET) || defined(_ATH5K_PHY)
> diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
> index 3cb0752..535ea72 100644
> --- a/drivers/net/wireless/ath/ath5k/base.c
> +++ b/drivers/net/wireless/ath/ath5k/base.c
> @@ -437,6 +437,22 @@ ath5k_chip_name(enum ath5k_srev_type type, u_int16_t val)
>
> return name;
> }
> +static unsigned int ath5k_ioread32(void *hw_priv, u32 reg_offset)
> +{
> + struct ath5k_hw *ah = (struct ath5k_hw *) hw_priv;
> + return ioread32(ah->ah_iobase + reg_offset);
> +}
> +
> +static void ath5k_iowrite32(void *hw_priv, u32 reg_offset, u32 val)
> +{
> + struct ath5k_hw *ah = (struct ath5k_hw *) hw_priv;
> + iowrite32(val, ah->ah_iobase + reg_offset);
> +}
> +
> +static struct ath_ops ath5k_common_ops = {
> + .read = ath5k_ioread32,
> + .write = ath5k_iowrite32,
> +};
>
> static int __devinit
> ath5k_pci_probe(struct pci_dev *pdev,
> @@ -576,6 +592,7 @@ ath5k_pci_probe(struct pci_dev *pdev,
> sc->ah->ah_sc = sc;
> sc->ah->ah_iobase = sc->iobase;
> common = ath5k_hw_common(sc->ah);
> + common->ops = &ath5k_common_ops;
> common->cachelsz = csz << 2; /* convert to bytes */
>
> /* Initialize device */
> diff --git a/drivers/net/wireless/ath/ath5k/base.h b/drivers/net/wireless/ath/ath5k/base.h
> index 005d25f..b14ba07 100644
> --- a/drivers/net/wireless/ath/ath5k/base.h
> +++ b/drivers/net/wireless/ath/ath5k/base.h
> @@ -201,15 +201,4 @@ struct ath5k_softc {
> #define ath5k_hw_hasveol(_ah) \
> (ath5k_hw_get_capability(_ah, AR5K_CAP_VEOL, 0, NULL) == 0)
>
> -static inline struct ath_common *ath5k_hw_common(struct ath5k_hw *ah)
> -{
> - return &ah->common;
> -}
> -
> -static inline struct ath_regulatory *ath5k_hw_regulatory(struct ath5k_hw *ah)
> -{
> - return &(ath5k_hw_common(ah)->regulatory);
> -
> -}
> -
> #endif
Since each driver will use it's own reg read/write functions (ath5k hw
code still uses ath5k_hw_reg_read/write), why do we need to have
common reg read/write functions like that used in the driver code ?
This makes the code more complex that it needs to be and i don't see a
reason why we need it. I understand why we need a way to handle
read/write functions from common ath code but i don't see a reason to
use these functions on ath5k, we can just fill ath_ops struct so that
common code can use them and leave ath5k_hw_read/write untouched.
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
^ permalink raw reply
* Re: [PATCH] sdio: pass unknown cis tuples to sdio drivers
From: Pierre Ossman @ 2009-09-11 6:06 UTC (permalink / raw)
To: Albert Herranz
Cc: akpm, linux-mmc, bcm43xx-dev, linux-wireless, Albert Herranz
In-Reply-To: <1252587402-7382-2-git-send-email-albert_herranz@yahoo.es>
[-- Attachment #1: Type: text/plain, Size: 2616 bytes --]
On Thu, 10 Sep 2009 14:56:42 +0200
Albert Herranz <albert_herranz@yahoo.es> wrote:
> Some manufacturers provide vendor information in non-vendor specific CIS
> tuples. For example, Broadcom uses an Extended Function tuple to provide
> the MAC address on some of their network cards, as in the case of the
> Nintendo Wii WLAN daughter card.
>
> This patch allows passing correct tuples unknown to the SDIO core to
> a matching SDIO driver instead of rejecting them and failing.
>
> Signed-off-by: Albert Herranz <albert_herranz@yahoo.es>
> ---
The description for this patch should be made clearer. The title
suggests it adds functionality that's already in place. It should be
something along the lines of "Also pass malformed tuples to card
drivers".
In the sake of sanity, you might want to add this behaviour to all
parsers, not just the FUNCE one.
I'm also unclear on how this is supposed to work. What does the
broadcom tuple look like? This patch looks like it will silence a lot
of legitimate warnings, and possibly pollute the card structures with
bogus data.
> diff --git a/drivers/mmc/core/sdio_cis.c b/drivers/mmc/core/sdio_cis.c
> index 963f293..87934ac 100644
> --- a/drivers/mmc/core/sdio_cis.c
> +++ b/drivers/mmc/core/sdio_cis.c
> @@ -123,8 +123,9 @@ static int cistpl_funce_func(struct sdio_func *func,
> vsn = func->card->cccr.sdio_vsn;
> min_size = (vsn == SDIO_SDIO_REV_1_00) ? 28 : 42;
>
> + /* let the SDIO driver take care of unknown tuples */
> if (size < min_size || buf[0] != 1)
Misleading comment, the tuple is not unknown.
> - return -EINVAL;
> + return -EILSEQ;
>
What does this change improve?
> /* TPLFE_MAX_BLK_SIZE */
> func->max_blksize = buf[12] | (buf[13] << 8);
> @@ -154,13 +155,7 @@ static int cistpl_funce(struct mmc_card *card, struct sdio_func *func,
> else
> ret = cistpl_funce_common(card, buf, size);
>
> - if (ret) {
> - printk(KERN_ERR "%s: bad CISTPL_FUNCE size %u "
> - "type %u\n", mmc_hostname(card->host), size, buf[0]);
> - return ret;
> - }
> -
> - return 0;
> + return ret;
> }
>
> typedef int (tpl_parse_t)(struct mmc_card *, struct sdio_func *,
Silencing a legitimate error.
> + if (ret == -EILSEQ) {
> + /* this tuple is unknown to the core */
Misleading comment, the tuple might be known but malformed.
Rgds
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] sdio: recognize io card without powercycle
From: Pierre Ossman @ 2009-09-11 5:58 UTC (permalink / raw)
To: Albert Herranz
Cc: akpm, linux-mmc, bcm43xx-dev, linux-wireless, Albert Herranz
In-Reply-To: <1252587402-7382-1-git-send-email-albert_herranz@yahoo.es>
[-- Attachment #1: Type: text/plain, Size: 1277 bytes --]
On Thu, 10 Sep 2009 14:56:41 +0200
Albert Herranz <albert_herranz@yahoo.es> wrote:
> SDIO Simplified Specification V2.00 states that it is strongly recommended
> that the host executes either a power reset or issues a CMD52 (I/O Reset) to
> re-initialize an I/O only card or the I/O portion of a combo card.
> Additionally, the CMD52 must be issued first because it cannot be issued
> after a CMD0.
>
> With this patch the Nintendo Wii SDIO-based WLAN card is detected after a
> system reset, without requiring a complete system powercycle.
>
> Signed-off-by: Albert Herranz <albert_herranz@yahoo.es>
> ---
I had problems with cards already in the idle state crashing when I
sent them a reset. I suggest a big round of testing before merging this.
> @@ -182,3 +189,20 @@ int mmc_io_rw_extended(struct mmc_card *card, int write, unsigned fn,
> return 0;
> }
>
> +int sdio_go_idle(struct mmc_host *host)
> +{
It might be clearer if you use the terminology from the spec, so either
sdio_abort() or sdio_reset().
Rgds
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] input: Add KEY_RFKILL
From: Dmitry Torokhov @ 2009-09-11 5:13 UTC (permalink / raw)
To: Matthew Garrett; +Cc: linux-input, linux-wireless, marcel
In-Reply-To: <1252603292-20830-1-git-send-email-mjg@redhat.com>
On Thu, Sep 10, 2009 at 06:21:31PM +0100, Matthew Garrett wrote:
> Most laptops have keys that are intended to toggle all device state, not
> just wifi. These are currently generally mapped to KEY_WLAN. As a result,
> rfkill will only kill or enable wifi in response to the key press. This
> confuses users and can make it difficult for them to enable bluetooth
> and wwan devices.
>
> This patch adds a new keycode, KEY_RFKILL_ALL. It indicates that the
The new name in description does not match the code...
> system should toggle the state of all rfkillable devices.
Hmm, rfkill changes usually go through net tree so unless they want me
to push it though I'll just ACK the new keycode.
>
> Signed-off-by: Matthew Garrett <mjg@redhat.com>
Acked-by: Dmitry Torokhov <dtor@mail.ru>
> ---
> include/linux/input.h | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/input.h b/include/linux/input.h
> index 8b3bc3e..20a622e 100644
> --- a/include/linux/input.h
> +++ b/include/linux/input.h
> @@ -595,6 +595,8 @@ struct input_absinfo {
> #define KEY_NUMERIC_STAR 0x20a
> #define KEY_NUMERIC_POUND 0x20b
>
> +#define KEY_RFKILL 0x20c /* Key that controls all radios */
> +
> /* We avoid low common keys in module aliases so they don't get huge. */
> #define KEY_MIN_INTERESTING KEY_MUTE
> #define KEY_MAX 0x2ff
--
Dmitry
^ permalink raw reply
* Re: Differences between wireless-testing and mainline
From: Pavel Roskin @ 2009-09-11 4:37 UTC (permalink / raw)
To: John Ranson; +Cc: linux-wireless
In-Reply-To: <bcd1ba70909101959u4581537ci684a2c45bc17c965@mail.gmail.com>
Quoting John Ranson <ranson@analager.net>:
> Is there a good way to keep track of the differences between the
> mainline kernel and wireless testing? I'm running wireless testing to
> minimize firmware errors with my iwl4965 card. When mainline
> incorporates the code that I'm running, I would like to switch back.
git whatchanged wireless-testing/base..wireless-testing/master
wireless-testing/base is usually the latest release or release
candidate from the mainline.
If you want a better granularity, e.g. you are ready to switch to the
mainline before rc1, you'll need to track the mainline and look for
the patches you care about.
You can also pick up the patches you need from wireless-testing and
apply them to the mainline repository. If you do it with STGit, it
will tell you that the patches have been merged by telling you that
the local patches have become empty after the update.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] sdio: pass unknown cis tuples to sdio drivers
From: Andrew Morton @ 2009-09-11 3:39 UTC (permalink / raw)
To: Albert Herranz; +Cc: linux-mmc, bcm43xx-dev, linux-wireless
In-Reply-To: <1252587402-7382-2-git-send-email-albert_herranz@yahoo.es>
On Thu, 10 Sep 2009 14:56:42 +0200 Albert Herranz <albert_herranz@yahoo.es> wrote:
> Some manufacturers provide vendor information in non-vendor specific CIS
> tuples. For example, Broadcom uses an Extended Function tuple to provide
> the MAC address on some of their network cards, as in the case of the
> Nintendo Wii WLAN daughter card.
>
> This patch allows passing correct tuples unknown to the SDIO core to
> a matching SDIO driver instead of rejecting them and failing.
>
This looks leaky to me.
: if (i < ARRAY_SIZE(cis_tpl_list)) {
: const struct cis_tpl *tpl = cis_tpl_list + i;
: if (tpl_link < tpl->min_size) {
: printk(KERN_ERR
: "%s: bad CIS tuple 0x%02x"
: " (length = %u, expected >= %u)\n",
: mmc_hostname(card->host),
: tpl_code, tpl_link, tpl->min_size);
: ret = -EINVAL;
ret == -EINVAL
: } else if (tpl->parse) {
: ret = tpl->parse(card, func,
: this->data, tpl_link);
: }
: /* already successfully parsed, not needed anymore */
: if (!ret)
: kfree(this);
`this' doesn't get freed
: } else {
: /* unknown tuple */
: ret = -EILSEQ;
: }
:
: if (ret == -EILSEQ) {
`this' doesn't get remembered.
: /* this tuple is unknown to the core */
: this->next = NULL;
: this->code = tpl_code;
: this->size = tpl_link;
: *prev = this;
: prev = &this->next;
: pr_debug("%s: queuing CIS tuple 0x%02x length %u\n",
: mmc_hostname(card->host), tpl_code, tpl_link);
: /* keep on analyzing tuples */
: ret = 0;
: }
:
: ptr += tpl_link;
`this' leaks.
: } while (!ret);
Please check?
^ permalink raw reply
* [PATCH] ath9k: Fix bug in ANI channel handling
From: Sujith @ 2009-09-11 3:00 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
When processing MIB interrupts, OFDM and CCK error
handling routines for low RSSI values have to be invoked
only when the channel mode is 11G/11B. Since HT channels
will also fall under the bands 2Ghz/5Ghz, check appropriately.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
---
This patch would apply over Luis' pending patches.
drivers/net/wireless/ath/ath9k/ani.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ani.c b/drivers/net/wireless/ath/ath9k/ani.c
index f5cd7da..e4f9559 100644
--- a/drivers/net/wireless/ath/ath9k/ani.c
+++ b/drivers/net/wireless/ath/ath9k/ani.c
@@ -327,7 +327,8 @@ static void ath9k_hw_ani_ofdm_err_trigger(struct ath_hw *ah)
aniState->firstepLevel + 1);
return;
} else {
- if (conf->channel->band == IEEE80211_BAND_2GHZ) {
+ if ((conf->channel->band == IEEE80211_BAND_2GHZ) &&
+ !conf_is_ht(conf)) {
if (!aniState->ofdmWeakSigDetectOff)
ath9k_hw_ani_control(ah,
ATH9K_ANI_OFDM_WEAK_SIGNAL_DETECTION,
@@ -369,7 +370,8 @@ static void ath9k_hw_ani_cck_err_trigger(struct ath_hw *ah)
ath9k_hw_ani_control(ah, ATH9K_ANI_FIRSTEP_LEVEL,
aniState->firstepLevel + 1);
} else {
- if (conf->channel->band == IEEE80211_BAND_2GHZ) {
+ if ((conf->channel->band == IEEE80211_BAND_2GHZ) &&
+ !conf_is_ht(conf)) {
if (aniState->firstepLevel > 0)
ath9k_hw_ani_control(ah,
ATH9K_ANI_FIRSTEP_LEVEL, 0);
--
1.6.4.2
^ permalink raw reply related
* Differences between wireless-testing and mainline
From: John Ranson @ 2009-09-11 2:59 UTC (permalink / raw)
To: linux-wireless
Is there a good way to keep track of the differences between the
mainline kernel and wireless testing? I'm running wireless testing to
minimize firmware errors with my iwl4965 card. When mainline
incorporates the code that I'm running, I would like to switch back.
John
^ permalink raw reply
* [b43] About supporting of BCM4312 [14e4:4315] with Low Power PHY
From: Bryan Wu @ 2009-09-11 2:22 UTC (permalink / raw)
To: mb, stefano.brivio; +Cc: linux-wireless
Dear Michael and Stefano,
I have a project which integrate Broadcom Wifi chip. But the mainline b43 still does not support this chip, because it has Low Power PHY.
Here is my lspci -vvnn output for this device:
------
07:00.0 Network controller [0280]: Broadcom Corporation BCM4312 802.11b/g [14e4:4315] (rev 01)
Subsystem: Dell Device [1028:000c]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 17
Region 0: Memory at f0100000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=2 PME-
Capabilities: [58] Vendor Specific Information <?>
Capabilities: [e8] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
Address: 0000000000000000 Data: 0000
Capabilities: [d0] Express (v1) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <4us, L1 unlimited
ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag+ PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <4us, L1 <64us
ClockPM+ Suprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
Kernel driver in use: b43-pci-bridge
Kernel modules: ssb
------
Do you guys know how to support this device in 2.6.31 kernel? Need I backport some code from wireless-testing? I enabled the PHY_LP config manually in 2.6.31 kernel and b43 driver recognized the hardware wifi device, but it still
does not work at all.
Or there is no choice but Broadcom's STA driver? I do not like such non-GPL stuff.
Thanks a lot
--
Bryan Wu <bryan.wu@canonical.com>
Kernel Developer +86.138-1617-6545 Mobile
Ubuntu Kernel Team | Hardware Enablement Team
Canonical Ltd. www.canonical.com
Ubuntu - Linux for human beings | www.ubuntu.com
^ permalink raw reply
* Testing of pending patches for ath, ath5k, ath9k, ar9170
From: Luis R. Rodriguez @ 2009-09-11 1:50 UTC (permalink / raw)
To: linux-wireless, devel, ath9k-devel, ath5k-devel
I've posted my series of patches so far as PATCH form as I feel
confident about them, but it always helps to get early testers. If you
have ath5k, ath9k, or ar9170 hardware please give these a whirl on top
of wireless-testing. Nothing much has changed except a lot of code
shuffling and the start of hw code sharing. I'm curious if any user on
real single CPU boxen notices any differences, I would doubt it, but
hey, lets see.
http://bombadil.infradead.org/~mcgrof/patches/ath/2009/09/all-2009-09-10.patch
After this I guess there's just a few tiny places to address on hw
related code to ensure ath_softc is not used, once this is all cleaned
up we can start using the code as-is on ath9k_htc.
Luis
^ permalink raw reply
* Re: [PATCH 3/4] ath5k: define ath_common ops
From: Luis R. Rodriguez @ 2009-09-11 1:46 UTC (permalink / raw)
To: Bob Copeland; +Cc: linville, linux-wireless, ath9k-devel, devel
In-Reply-To: <b6c5339f0909101842t74479b34heaf0628d1a3b7edb@mail.gmail.com>
On Thu, Sep 10, 2009 at 6:42 PM, Bob Copeland <bcopeland@gmail.com> wrote:
> On Thu, Sep 10, 2009 at 9:34 PM, Luis R. Rodriguez
> <lrodriguez@atheros.com> wrote:
>> static inline u32 ath5k_hw_reg_read(struct ath5k_hw *ah, u16 reg)
>> {
>> - return ioread32(ah->ah_iobase + reg);
>> + return ath5k_hw_common(ah)->ops->read(ah, reg);
>> }
>
> Is there any way we can do this without two pointer dereferences for every
> read and write? I have a feeling this is going to make certain operations
> (e.g. loading initvals during reset) really suck.
It seems to work fine on my box, perhaps a single CPU (real single
CPU) user can test to see if there are any differences noted. I don't
think there should be really.
In any case if its deemed too nested for ath5k purposes you can just
leave an ioread/iowrite on the ath5k_hw_reg_read() and later just
move all read/write ops to use the common ops calls. If someone can
think of better alternatives I'm all ears.
Luis
^ permalink raw reply
* Re: [PATCH 3/4] ath5k: define ath_common ops
From: Bob Copeland @ 2009-09-11 1:42 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linville, linux-wireless, ath9k-devel, devel
In-Reply-To: <1252632895-11914-4-git-send-email-lrodriguez@atheros.com>
On Thu, Sep 10, 2009 at 9:34 PM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> static inline u32 ath5k_hw_reg_read(struct ath5k_hw *ah, u16 reg)
> {
> - return ioread32(ah->ah_iobase + reg);
> + return ath5k_hw_common(ah)->ops->read(ah, reg);
> }
Is there any way we can do this without two pointer dereferences for every
read and write? I have a feeling this is going to make certain operations
(e.g. loading initvals during reset) really suck.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* [PATCH 4/4] atheros: define shared bssidmask setting
From: Luis R. Rodriguez @ 2009-09-11 1:34 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, ath9k-devel, devel, Luis R. Rodriguez
In-Reply-To: <1252632895-11914-1-git-send-email-lrodriguez@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
drivers/net/wireless/ath/Makefile | 5 +-
drivers/net/wireless/ath/ath.h | 3 +
drivers/net/wireless/ath/ath5k/ath5k.h | 2 +-
drivers/net/wireless/ath/ath5k/attach.c | 2 +-
drivers/net/wireless/ath/ath5k/base.c | 1 +
drivers/net/wireless/ath/ath5k/pcu.c | 113 +--------------------------
drivers/net/wireless/ath/ath9k/hw.c | 10 +--
drivers/net/wireless/ath/ath9k/main.c | 1 +
drivers/net/wireless/ath/ath9k/recv.c | 2 +-
drivers/net/wireless/ath/ath9k/virtual.c | 2 +-
drivers/net/wireless/ath/hw.c | 126 ++++++++++++++++++++++++++++++
drivers/net/wireless/ath/reg.h | 2 +
12 files changed, 145 insertions(+), 124 deletions(-)
create mode 100644 drivers/net/wireless/ath/hw.c
create mode 100644 drivers/net/wireless/ath/reg.h
diff --git a/drivers/net/wireless/ath/Makefile b/drivers/net/wireless/ath/Makefile
index 4bb0132..6ebf214 100644
--- a/drivers/net/wireless/ath/Makefile
+++ b/drivers/net/wireless/ath/Makefile
@@ -3,4 +3,7 @@ obj-$(CONFIG_ATH9K) += ath9k/
obj-$(CONFIG_AR9170_USB) += ar9170/
obj-$(CONFIG_ATH_COMMON) += ath.o
-ath-objs := main.o regd.o
+
+ath-objs := main.o \
+ regd.o \
+ hw.o
diff --git a/drivers/net/wireless/ath/ath.h b/drivers/net/wireless/ath/ath.h
index 91cb43c..1d022a3 100644
--- a/drivers/net/wireless/ath/ath.h
+++ b/drivers/net/wireless/ath/ath.h
@@ -45,6 +45,7 @@ struct ath_ops {
};
struct ath_common {
+ void *ah;
u16 cachelsz;
u16 curaid;
u8 macaddr[ETH_ALEN];
@@ -58,4 +59,6 @@ struct sk_buff *ath_rxbuf_alloc(struct ath_common *common,
u32 len,
gfp_t gfp_mask);
+void ath_hw_setbssidmask(struct ath_common *common);
+
#endif /* ATH_H */
diff --git a/drivers/net/wireless/ath/ath5k/ath5k.h b/drivers/net/wireless/ath/ath5k/ath5k.h
index 997101b..cc116c7 100644
--- a/drivers/net/wireless/ath/ath5k/ath5k.h
+++ b/drivers/net/wireless/ath/ath5k/ath5k.h
@@ -1192,7 +1192,7 @@ extern int ath5k_hw_set_opmode(struct ath5k_hw *ah);
/* BSSID Functions */
extern int ath5k_hw_set_lladdr(struct ath5k_hw *ah, const u8 *mac);
extern void ath5k_hw_set_associd(struct ath5k_hw *ah, const u8 *bssid, u16 assoc_id);
-extern int ath5k_hw_set_bssid_mask(struct ath5k_hw *ah, const u8 *mask);
+extern void ath5k_hw_set_bssid_mask(struct ath5k_hw *ah, const u8 *mask);
/* Receive start/stop functions */
extern void ath5k_hw_start_rx_pcu(struct ath5k_hw *ah);
extern void ath5k_hw_stop_rx_pcu(struct ath5k_hw *ah);
diff --git a/drivers/net/wireless/ath/ath5k/attach.c b/drivers/net/wireless/ath/ath5k/attach.c
index c0840ab..e230de8 100644
--- a/drivers/net/wireless/ath/ath5k/attach.c
+++ b/drivers/net/wireless/ath/ath5k/attach.c
@@ -104,7 +104,7 @@ static int ath5k_hw_post(struct ath5k_hw *ah)
int ath5k_hw_attach(struct ath5k_softc *sc)
{
struct ath5k_hw *ah = sc->ah;
- struct ath_common *common;
+ struct ath_common *common = ath5k_hw_common(ah);
struct pci_dev *pdev = sc->pdev;
struct ath5k_eeprom_info *ee;
int ret;
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index 535ea72..02e1ce6 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -593,6 +593,7 @@ ath5k_pci_probe(struct pci_dev *pdev,
sc->ah->ah_iobase = sc->iobase;
common = ath5k_hw_common(sc->ah);
common->ops = &ath5k_common_ops;
+ common->ah = sc->ah;
common->cachelsz = csz << 2; /* convert to bytes */
/* Initialize device */
diff --git a/drivers/net/wireless/ath/ath5k/pcu.c b/drivers/net/wireless/ath/ath5k/pcu.c
index f03c06d..6329148 100644
--- a/drivers/net/wireless/ath/ath5k/pcu.c
+++ b/drivers/net/wireless/ath/ath5k/pcu.c
@@ -316,125 +316,18 @@ void ath5k_hw_set_associd(struct ath5k_hw *ah, const u8 *bssid, u16 assoc_id)
ath5k_hw_enable_pspoll(ah, NULL, 0);
}
-/**
- * ath5k_hw_set_bssid_mask - filter out bssids we listen
- *
- * @ah: the &struct ath5k_hw
- * @mask: the bssid_mask, a u8 array of size ETH_ALEN
- *
- * BSSID masking is a method used by AR5212 and newer hardware to inform PCU
- * which bits of the interface's MAC address should be looked at when trying
- * to decide which packets to ACK. In station mode and AP mode with a single
- * BSS every bit matters since we lock to only one BSS. In AP mode with
- * multiple BSSes (virtual interfaces) not every bit matters because hw must
- * accept frames for all BSSes and so we tweak some bits of our mac address
- * in order to have multiple BSSes.
- *
- * NOTE: This is a simple filter and does *not* filter out all
- * relevant frames. Some frames that are not for us might get ACKed from us
- * by PCU because they just match the mask.
- *
- * When handling multiple BSSes you can get the BSSID mask by computing the
- * set of ~ ( MAC XOR BSSID ) for all bssids we handle.
- *
- * When you do this you are essentially computing the common bits of all your
- * BSSes. Later it is assumed the harware will "and" (&) the BSSID mask with
- * the MAC address to obtain the relevant bits and compare the result with
- * (frame's BSSID & mask) to see if they match.
- */
-/*
- * Simple example: on your card you have have two BSSes you have created with
- * BSSID-01 and BSSID-02. Lets assume BSSID-01 will not use the MAC address.
- * There is another BSSID-03 but you are not part of it. For simplicity's sake,
- * assuming only 4 bits for a mac address and for BSSIDs you can then have:
- *
- * \
- * MAC: 0001 |
- * BSSID-01: 0100 | --> Belongs to us
- * BSSID-02: 1001 |
- * /
- * -------------------
- * BSSID-03: 0110 | --> External
- * -------------------
- *
- * Our bssid_mask would then be:
- *
- * On loop iteration for BSSID-01:
- * ~(0001 ^ 0100) -> ~(0101)
- * -> 1010
- * bssid_mask = 1010
- *
- * On loop iteration for BSSID-02:
- * bssid_mask &= ~(0001 ^ 1001)
- * bssid_mask = (1010) & ~(0001 ^ 1001)
- * bssid_mask = (1010) & ~(1001)
- * bssid_mask = (1010) & (0110)
- * bssid_mask = 0010
- *
- * A bssid_mask of 0010 means "only pay attention to the second least
- * significant bit". This is because its the only bit common
- * amongst the MAC and all BSSIDs we support. To findout what the real
- * common bit is we can simply "&" the bssid_mask now with any BSSID we have
- * or our MAC address (we assume the hardware uses the MAC address).
- *
- * Now, suppose there's an incoming frame for BSSID-03:
- *
- * IFRAME-01: 0110
- *
- * An easy eye-inspeciton of this already should tell you that this frame
- * will not pass our check. This is beacuse the bssid_mask tells the
- * hardware to only look at the second least significant bit and the
- * common bit amongst the MAC and BSSIDs is 0, this frame has the 2nd LSB
- * as 1, which does not match 0.
- *
- * So with IFRAME-01 we *assume* the hardware will do:
- *
- * allow = (IFRAME-01 & bssid_mask) == (bssid_mask & MAC) ? 1 : 0;
- * --> allow = (0110 & 0010) == (0010 & 0001) ? 1 : 0;
- * --> allow = (0010) == 0000 ? 1 : 0;
- * --> allow = 0
- *
- * Lets now test a frame that should work:
- *
- * IFRAME-02: 0001 (we should allow)
- *
- * allow = (0001 & 1010) == 1010
- *
- * allow = (IFRAME-02 & bssid_mask) == (bssid_mask & MAC) ? 1 : 0;
- * --> allow = (0001 & 0010) == (0010 & 0001) ? 1 :0;
- * --> allow = (0010) == (0010)
- * --> allow = 1
- *
- * Other examples:
- *
- * IFRAME-03: 0100 --> allowed
- * IFRAME-04: 1001 --> allowed
- * IFRAME-05: 1101 --> allowed but its not for us!!!
- *
- */
-int ath5k_hw_set_bssid_mask(struct ath5k_hw *ah, const u8 *mask)
+void ath5k_hw_set_bssid_mask(struct ath5k_hw *ah, const u8 *mask)
{
struct ath_common *common = ath5k_hw_common(ah);
- u32 low_id, high_id;
ATH5K_TRACE(ah->ah_sc);
/* Cache bssid mask so that we can restore it
* on reset */
memcpy(common->bssidmask, mask, ETH_ALEN);
- if (ah->ah_version == AR5K_AR5212) {
- low_id = get_unaligned_le32(mask);
- high_id = get_unaligned_le16(mask + 4);
-
- ath5k_hw_reg_write(ah, low_id, AR5K_BSS_IDM0);
- ath5k_hw_reg_write(ah, high_id, AR5K_BSS_IDM1);
-
- return 0;
- }
-
- return -EIO;
+ if (ah->ah_version == AR5K_AR5212)
+ ath_hw_setbssidmask(common);
}
-
/************\
* RX Control *
\************/
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index dabff52..80bfa18 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -2423,7 +2423,7 @@ int ath9k_hw_reset(struct ath_hw *ah, struct ath9k_channel *chan,
| ah->sta_id1_defaults);
ath9k_hw_set_operating_mode(ah, ah->opmode);
- ath9k_hw_setbssidmask(ah);
+ ath_hw_setbssidmask(common);
REG_WRITE(ah, AR_DEF_ANTENNA, saveDefAntenna);
@@ -3950,14 +3950,6 @@ void ath9k_hw_setmcastfilter(struct ath_hw *ah, u32 filter0, u32 filter1)
REG_WRITE(ah, AR_MCAST_FIL1, filter1);
}
-void ath9k_hw_setbssidmask(struct ath_hw *ah)
-{
- struct ath_common *common = ath9k_hw_common(ah);
-
- REG_WRITE(ah, AR_BSSMSKL, get_unaligned_le32(common->bssidmask));
- REG_WRITE(ah, AR_BSSMSKU, get_unaligned_le16(common->bssidmask + 4));
-}
-
void ath9k_hw_write_associd(struct ath_hw *ah)
{
struct ath_common *common = ath9k_hw_common(ah);
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 5f8a18a..9a8c9ce 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -1574,6 +1574,7 @@ static int ath_init_softc(u16 devid, struct ath_softc *sc, u16 subsysid)
common = ath9k_hw_common(ah);
common->ops = &ath9k_common_ops;
+ common->ah = ah;
/*
* Cache line size is used to size and align various
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index 97a5efe..fb635a0 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -282,7 +282,7 @@ static void ath_opmode_init(struct ath_softc *sc)
/* configure bssid mask */
if (ah->caps.hw_caps & ATH9K_HW_CAP_BSSIDMASK)
- ath9k_hw_setbssidmask(ah);
+ ath_hw_setbssidmask(common);
/* configure operational mode */
ath9k_hw_setopmode(ah);
diff --git a/drivers/net/wireless/ath/ath9k/virtual.c b/drivers/net/wireless/ath/ath9k/virtual.c
index 7b763b6..bc7d173 100644
--- a/drivers/net/wireless/ath/ath9k/virtual.c
+++ b/drivers/net/wireless/ath/ath9k/virtual.c
@@ -94,7 +94,7 @@ void ath9k_set_bssid_mask(struct ieee80211_hw *hw)
common->bssidmask[4] = ~mask[4];
common->bssidmask[5] = ~mask[5];
- ath9k_hw_setbssidmask(sc->sc_ah);
+ ath_hw_setbssidmask(common);
}
int ath9k_wiphy_add(struct ath_softc *sc)
diff --git a/drivers/net/wireless/ath/hw.c b/drivers/net/wireless/ath/hw.c
new file mode 100644
index 0000000..5f7598e
--- /dev/null
+++ b/drivers/net/wireless/ath/hw.c
@@ -0,0 +1,126 @@
+/*
+ * Copyright (c) 2009 Atheros Communications Inc.
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include <asm/unaligned.h>
+
+#include "ath.h"
+#include "reg.h"
+
+#define REG_READ common->ops->read
+#define REG_WRITE common->ops->write
+
+/**
+ * ath_hw_set_bssid_mask - filter out bssids we listen
+ *
+ * @common: the ath_common struct for the device.
+ *
+ * BSSID masking is a method used by AR5212 and newer hardware to inform PCU
+ * which bits of the interface's MAC address should be looked at when trying
+ * to decide which packets to ACK. In station mode and AP mode with a single
+ * BSS every bit matters since we lock to only one BSS. In AP mode with
+ * multiple BSSes (virtual interfaces) not every bit matters because hw must
+ * accept frames for all BSSes and so we tweak some bits of our mac address
+ * in order to have multiple BSSes.
+ *
+ * NOTE: This is a simple filter and does *not* filter out all
+ * relevant frames. Some frames that are not for us might get ACKed from us
+ * by PCU because they just match the mask.
+ *
+ * When handling multiple BSSes you can get the BSSID mask by computing the
+ * set of ~ ( MAC XOR BSSID ) for all bssids we handle.
+ *
+ * When you do this you are essentially computing the common bits of all your
+ * BSSes. Later it is assumed the harware will "and" (&) the BSSID mask with
+ * the MAC address to obtain the relevant bits and compare the result with
+ * (frame's BSSID & mask) to see if they match.
+ *
+ * Simple example: on your card you have have two BSSes you have created with
+ * BSSID-01 and BSSID-02. Lets assume BSSID-01 will not use the MAC address.
+ * There is another BSSID-03 but you are not part of it. For simplicity's sake,
+ * assuming only 4 bits for a mac address and for BSSIDs you can then have:
+ *
+ * \
+ * MAC: 0001 |
+ * BSSID-01: 0100 | --> Belongs to us
+ * BSSID-02: 1001 |
+ * /
+ * -------------------
+ * BSSID-03: 0110 | --> External
+ * -------------------
+ *
+ * Our bssid_mask would then be:
+ *
+ * On loop iteration for BSSID-01:
+ * ~(0001 ^ 0100) -> ~(0101)
+ * -> 1010
+ * bssid_mask = 1010
+ *
+ * On loop iteration for BSSID-02:
+ * bssid_mask &= ~(0001 ^ 1001)
+ * bssid_mask = (1010) & ~(0001 ^ 1001)
+ * bssid_mask = (1010) & ~(1001)
+ * bssid_mask = (1010) & (0110)
+ * bssid_mask = 0010
+ *
+ * A bssid_mask of 0010 means "only pay attention to the second least
+ * significant bit". This is because its the only bit common
+ * amongst the MAC and all BSSIDs we support. To findout what the real
+ * common bit is we can simply "&" the bssid_mask now with any BSSID we have
+ * or our MAC address (we assume the hardware uses the MAC address).
+ *
+ * Now, suppose there's an incoming frame for BSSID-03:
+ *
+ * IFRAME-01: 0110
+ *
+ * An easy eye-inspeciton of this already should tell you that this frame
+ * will not pass our check. This is beacuse the bssid_mask tells the
+ * hardware to only look at the second least significant bit and the
+ * common bit amongst the MAC and BSSIDs is 0, this frame has the 2nd LSB
+ * as 1, which does not match 0.
+ *
+ * So with IFRAME-01 we *assume* the hardware will do:
+ *
+ * allow = (IFRAME-01 & bssid_mask) == (bssid_mask & MAC) ? 1 : 0;
+ * --> allow = (0110 & 0010) == (0010 & 0001) ? 1 : 0;
+ * --> allow = (0010) == 0000 ? 1 : 0;
+ * --> allow = 0
+ *
+ * Lets now test a frame that should work:
+ *
+ * IFRAME-02: 0001 (we should allow)
+ *
+ * allow = (0001 & 1010) == 1010
+ *
+ * allow = (IFRAME-02 & bssid_mask) == (bssid_mask & MAC) ? 1 : 0;
+ * --> allow = (0001 & 0010) == (0010 & 0001) ? 1 :0;
+ * --> allow = (0010) == (0010)
+ * --> allow = 1
+ *
+ * Other examples:
+ *
+ * IFRAME-03: 0100 --> allowed
+ * IFRAME-04: 1001 --> allowed
+ * IFRAME-05: 1101 --> allowed but its not for us!!!
+ *
+ */
+void ath_hw_setbssidmask(struct ath_common *common)
+{
+ void *ah = common->ah;
+
+ REG_WRITE(ah, AR_BSSMSKL, get_unaligned_le32(common->bssidmask));
+ REG_WRITE(ah, AR_BSSMSKU, get_unaligned_le16(common->bssidmask + 4));
+}
+EXPORT_SYMBOL(ath_hw_setbssidmask);
diff --git a/drivers/net/wireless/ath/reg.h b/drivers/net/wireless/ath/reg.h
new file mode 100644
index 0000000..70453f6
--- /dev/null
+++ b/drivers/net/wireless/ath/reg.h
@@ -0,0 +1,2 @@
+#define AR_BSSMSKL 0x80e0
+#define AR_BSSMSKU 0x80e4
--
1.6.3.3
^ 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