* Re: [PATCH v5] cfg80211: Add nl80211 antenna configuration
From: Johannes Berg @ 2010-08-02 11:01 UTC (permalink / raw)
To: Felix Fietkau; +Cc: Luis R. Rodriguez, Bruno Randolf, linville, linux-wireless
In-Reply-To: <4C56A251.7080903@openwrt.org>
On Mon, 2010-08-02 at 12:47 +0200, Felix Fietkau wrote:
> Legacy hardware => run time changes possible (actually optional)
> 802.11n hardware => need to bring down the interface before changing
> the antenna settings
I think I'd prefer if all hw just required the device to be stopped.
Otherwise things either become awkward when you have, say. software
diversity control, or they become unpredictable quite, no?
johannes
^ permalink raw reply
* Re: iwlwifi connection problems
From: Johannes Berg @ 2010-08-02 10:58 UTC (permalink / raw)
To: Alex Romosan; +Cc: Guy, Wey-Yi, linux-wireless@vger.kernel.org
In-Reply-To: <87bp9l6f4k.fsf@sycorax.lbl.gov>
On Sun, 2010-08-01 at 17:18 -0700, Alex Romosan wrote:
> > So is the issue maybe the channel the AP is no, not the fact that it's
> > hidden? or something like that?
>
> it's still not working even with kernel 2.6.35 so i decided to play with
> it a little bit more. indeed, it has nothing to do with the access
> point being hidden or not. it doesn't work even when it's visible
> (previously i was able to connect to the wireless at work which is
> visible so i wrongly assumed that was the cause).
Ok, thanks for checking, that's good to know.
> so it looks like the problem is connecting to this particular access
> point which is a proxim ap-200 orinoco wireless ap i got in 2003. right
> now the ap is setup on channel 3 and the rate is set to 11 Mbps. should
> i try a different channel? which one?
Channel 3 should be fine, we just had reports about channel 13 failing.
2.6.35 includes the QoS fix, so I'm not sure what the issue could be
here.
Typically such ancient APs have issues with the supported rates bitmap,
could you maybe try to revert 76f273640134f3eb8257179cd5b3bc6ba5fe4a96?
This is the only relevant commit I can find between .34 and .35.
However, if that doesn't help this seems like an ideal candidate for
bisection, would you be willing to try that? I'd restrict to wireless
code, i.e.
git bisect start -- net/wireless net/mac80211 drivers/net/wireless/iwlwifi
johannes
^ permalink raw reply
* Re: [PATCH v5] cfg80211: Add nl80211 antenna configuration
From: Luis R. Rodriguez @ 2010-08-02 10:51 UTC (permalink / raw)
To: Felix Fietkau; +Cc: Bruno Randolf, johannes, linville, linux-wireless
In-Reply-To: <4C56A251.7080903@openwrt.org>
On Mon, Aug 2, 2010 at 3:47 AM, Felix Fietkau <nbd@openwrt.org> wrote:
> 802.11n hardware => need to bring down the interface before changing
> the antenna settings
The current patch does not deal with the 802.11n case you mentioned.
Luis
^ permalink raw reply
* Re: [PATCH v5] cfg80211: Add nl80211 antenna configuration
From: Felix Fietkau @ 2010-08-02 10:47 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Bruno Randolf, johannes, linville, linux-wireless
In-Reply-To: <AANLkTimWnefNaiPzqMXwc6d8aePmy3SZ8w9FB4=6CRko@mail.gmail.com>
On 2010-08-02 12:18 PM, Luis R. Rodriguez wrote:
> On Mon, Aug 2, 2010 at 3:10 AM, Felix Fietkau <nbd@openwrt.org> wrote:
>> On 2010-08-02 11:52 AM, Luis R. Rodriguez wrote:
>>> On Mon, Aug 2, 2010 at 2:32 AM, Felix Fietkau <nbd@openwrt.org> wrote:
>>>> On 2010-08-02 11:23 AM, Luis R. Rodriguez wrote:
>>>>> Sure, I just did not see any code for this in these patches. My point
>>>>> about the hw config vs fake/mod'd is if we'd expose the mod'd config
>>>>> changes to userspace or if we'd keep them internal to cfg80211. How
>>>>> would this be dealt with?
>>>> Right now, cfg80211 doesn't know enough to handle this stuff on its own,
>>>> so let's handle it in the driver completely on the first iteration. The
>>>> patches do not need any changes for this right now.
>>>
>>> I'd prefer that code to be written rather then let this be defined as
>>> API now and let drivers deal with this differently. But that's me, I'm
>>> not the maintainer, I just will not deal with bug reports dealing with
>>> this and I'll assign them to you guys if this gets through. Still
>>> think its crap and should just go through debugfs until all the code
>>> mentioned does exist.
>> Sorry, but WTF? There's two parts to this: API visible to user space,
>> and the internal API for handling changes.
>> So you're suggesting to reject the user space API, because of missing
>> parts in the internal API (which we can change any time) that will only
>> be used for drivers that this series doesn't even contain any code for??
>> Am I confused here, or does this seem rather strange?
>
> If the current patches are accepted it means anyone *can* submit
> patches for an 802.11n driver and expect it to be accepted. Hence why
> I was asking for this to be defined as a legacy API only, if that is
> the only purpose right now.
This discussion is getting quite redundant. I would like to ask you
again, what the specific concern purely from a user space API point of
view is.
You asked how run time changes should be handled, I made a proposal for
that (simply not accepting them at run time on 802.11n hardware if they
affect the chainmask), and then you started complaining about what
should be in cfg80211 and what should be in the drivers. What does that
have to do with the public API?
The limitations wrt. chainmask changes at run time are known, and they
aren't really hardware specific, so you won't see some random driver
suddenly implementing some hypothetical crazy scheme that nobody
expects. This has nothing to do with code being in cfg80211 vs code
being in the driver.
It's really simple: in AP mode, hostapd needs to have the HT stuff set
when it starts up, in STA mode, it needs to be set at least at assoc
time. Since this is affected by the chainmask, we can't just change
stuff at a random point in time, but this is expected.
So the lowest common denominator that we can use for all 802.11n
hardware in all modes is to just refuse changes unless the interface is
down. Then we use the antenna mask to calculate the chainmask (an
inherently driver specific aspect, at least at the moment), recalculate
the HT capabilities based on the chainmask (driver has to do this at
init time already, needs very little refactoring), and then just apply
the new settings to the hardware (again, driver specific, will probably
be deferred to the interface bringup sequence).
So aside from the meaning of the actual value, which we need to make
easier to understand in the user space code, the only thing that users
need to be aware of is this:
Legacy hardware => run time changes possible (actually optional)
802.11n hardware => need to bring down the interface before changing
the antenna settings
What else is left that we need to figure out? What would we need the
temporary debugfs crap for?
- Felix
^ permalink raw reply
* Re: [PATCH v5] cfg80211: Add nl80211 antenna configuration
From: Luis R. Rodriguez @ 2010-08-02 10:18 UTC (permalink / raw)
To: Felix Fietkau; +Cc: Bruno Randolf, johannes, linville, linux-wireless
In-Reply-To: <4C5699AE.6090103@openwrt.org>
On Mon, Aug 2, 2010 at 3:10 AM, Felix Fietkau <nbd@openwrt.org> wrote:
> On 2010-08-02 11:52 AM, Luis R. Rodriguez wrote:
>> On Mon, Aug 2, 2010 at 2:32 AM, Felix Fietkau <nbd@openwrt.org> wrote:
>>> On 2010-08-02 11:23 AM, Luis R. Rodriguez wrote:
>>>> Sure, I just did not see any code for this in these patches. My point
>>>> about the hw config vs fake/mod'd is if we'd expose the mod'd config
>>>> changes to userspace or if we'd keep them internal to cfg80211. How
>>>> would this be dealt with?
>>> Right now, cfg80211 doesn't know enough to handle this stuff on its own,
>>> so let's handle it in the driver completely on the first iteration. The
>>> patches do not need any changes for this right now.
>>
>> I'd prefer that code to be written rather then let this be defined as
>> API now and let drivers deal with this differently. But that's me, I'm
>> not the maintainer, I just will not deal with bug reports dealing with
>> this and I'll assign them to you guys if this gets through. Still
>> think its crap and should just go through debugfs until all the code
>> mentioned does exist.
> Sorry, but WTF? There's two parts to this: API visible to user space,
> and the internal API for handling changes.
> So you're suggesting to reject the user space API, because of missing
> parts in the internal API (which we can change any time) that will only
> be used for drivers that this series doesn't even contain any code for??
> Am I confused here, or does this seem rather strange?
If the current patches are accepted it means anyone *can* submit
patches for an 802.11n driver and expect it to be accepted. Hence why
I was asking for this to be defined as a legacy API only, if that is
the only purpose right now.
Luis
^ permalink raw reply
* Re: [PATCH v5] cfg80211: Add nl80211 antenna configuration
From: Felix Fietkau @ 2010-08-02 10:10 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Bruno Randolf, johannes, linville, linux-wireless
In-Reply-To: <AANLkTimoU+iF2bVJ-Fs4iT3k5v0iU9PaE783NhUdnQQ-@mail.gmail.com>
On 2010-08-02 11:52 AM, Luis R. Rodriguez wrote:
> On Mon, Aug 2, 2010 at 2:32 AM, Felix Fietkau <nbd@openwrt.org> wrote:
>> On 2010-08-02 11:23 AM, Luis R. Rodriguez wrote:
>>> Sure, I just did not see any code for this in these patches. My point
>>> about the hw config vs fake/mod'd is if we'd expose the mod'd config
>>> changes to userspace or if we'd keep them internal to cfg80211. How
>>> would this be dealt with?
>> Right now, cfg80211 doesn't know enough to handle this stuff on its own,
>> so let's handle it in the driver completely on the first iteration. The
>> patches do not need any changes for this right now.
>
> I'd prefer that code to be written rather then let this be defined as
> API now and let drivers deal with this differently. But that's me, I'm
> not the maintainer, I just will not deal with bug reports dealing with
> this and I'll assign them to you guys if this gets through. Still
> think its crap and should just go through debugfs until all the code
> mentioned does exist.
Sorry, but WTF? There's two parts to this: API visible to user space,
and the internal API for handling changes.
So you're suggesting to reject the user space API, because of missing
parts in the internal API (which we can change any time) that will only
be used for drivers that this series doesn't even contain any code for??
Am I confused here, or does this seem rather strange?
- Felix
^ permalink raw reply
* Re: [PATCH v5] cfg80211: Add nl80211 antenna configuration
From: Luis R. Rodriguez @ 2010-08-02 9:52 UTC (permalink / raw)
To: Felix Fietkau; +Cc: Bruno Randolf, johannes, linville, linux-wireless
In-Reply-To: <4C5690C7.2080104@openwrt.org>
On Mon, Aug 2, 2010 at 2:32 AM, Felix Fietkau <nbd@openwrt.org> wrote:
> On 2010-08-02 11:23 AM, Luis R. Rodriguez wrote:
>> On Mon, Aug 2, 2010 at 2:17 AM, Felix Fietkau <nbd@openwrt.org> wrote:
>>> On 2010-08-02 11:10 AM, Luis R. Rodriguez wrote:
>>>> On Mon, Aug 2, 2010 at 1:59 AM, Felix Fietkau <nbd@openwrt.org> wrote:
>>>>> On 2010-08-02 7:37 AM, Luis R. Rodriguez wrote:
>>>>>> I'm not, the point I was trying to make is that solving this for
>>>>>> legacy and that for 802.11n this needs more thought and work.
>>>>> I need this for 802.11n as well, and I believe the API is good enough
>>>>> for that.
>>>>
>>>> Sure.
>>>>
>>>>>>> as long as the API is flexible
>>>>>>> enough i think it can be added later as 802.11n devices are going to accept
>>>>>>> antenna configuration.
>>>>>>
>>>>>> If you want really flexible stuff without addressing serious
>>>>>> considerations before introducing a new kernel API then use debugfs.
>>>>> I'd like to see this in nl80211. Is there any specific concern left that
>>>>> I haven't addressed already? If so, please point me at it...
>>>>
>>>> The code that deals with not accepting changes unless we're not
>>>> associated, and that also caches the old real hw config vs the
>>>> modified one.
>>> This is not really an API issue, this is more of an implementation
>>> aspect. I think it's up to the driver to reject changes that it cannot
>>> handle at the moment.
>>
>> Huh,why not deal with this on cfg80211 and/or mac80211?
> Right now, the drivers calculate this. We could make a helper function
> in cfg80211 at some point, but we're talking about really small chunks
> of code.
>
>>> For 802.11n, changes that affect the chainmask should be rejected while
>>> the interface is up. That way we don't run into weird cached config vs
>>> hw config issues, and also keep a sane state for the HT capabilities.
>>
>> Sure, I just did not see any code for this in these patches. My point
>> about the hw config vs fake/mod'd is if we'd expose the mod'd config
>> changes to userspace or if we'd keep them internal to cfg80211. How
>> would this be dealt with?
> Right now, cfg80211 doesn't know enough to handle this stuff on its own,
> so let's handle it in the driver completely on the first iteration. The
> patches do not need any changes for this right now.
I'd prefer that code to be written rather then let this be defined as
API now and let drivers deal with this differently. But that's me, I'm
not the maintainer, I just will not deal with bug reports dealing with
this and I'll assign them to you guys if this gets through. Still
think its crap and should just go through debugfs until all the code
mentioned does exist.
Luis
^ permalink raw reply
* Re: [PATCH v5] cfg80211: Add nl80211 antenna configuration
From: Felix Fietkau @ 2010-08-02 9:32 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Bruno Randolf, johannes, linville, linux-wireless
In-Reply-To: <AANLkTinGdwt4bSPRDV=ZfPBmoKS42GgUVjLAg_O1vL3i@mail.gmail.com>
On 2010-08-02 11:23 AM, Luis R. Rodriguez wrote:
> On Mon, Aug 2, 2010 at 2:17 AM, Felix Fietkau <nbd@openwrt.org> wrote:
>> On 2010-08-02 11:10 AM, Luis R. Rodriguez wrote:
>>> On Mon, Aug 2, 2010 at 1:59 AM, Felix Fietkau <nbd@openwrt.org> wrote:
>>>> On 2010-08-02 7:37 AM, Luis R. Rodriguez wrote:
>>>>> I'm not, the point I was trying to make is that solving this for
>>>>> legacy and that for 802.11n this needs more thought and work.
>>>> I need this for 802.11n as well, and I believe the API is good enough
>>>> for that.
>>>
>>> Sure.
>>>
>>>>>> as long as the API is flexible
>>>>>> enough i think it can be added later as 802.11n devices are going to accept
>>>>>> antenna configuration.
>>>>>
>>>>> If you want really flexible stuff without addressing serious
>>>>> considerations before introducing a new kernel API then use debugfs.
>>>> I'd like to see this in nl80211. Is there any specific concern left that
>>>> I haven't addressed already? If so, please point me at it...
>>>
>>> The code that deals with not accepting changes unless we're not
>>> associated, and that also caches the old real hw config vs the
>>> modified one.
>> This is not really an API issue, this is more of an implementation
>> aspect. I think it's up to the driver to reject changes that it cannot
>> handle at the moment.
>
> Huh,why not deal with this on cfg80211 and/or mac80211?
Right now, the drivers calculate this. We could make a helper function
in cfg80211 at some point, but we're talking about really small chunks
of code.
>> For 802.11n, changes that affect the chainmask should be rejected while
>> the interface is up. That way we don't run into weird cached config vs
>> hw config issues, and also keep a sane state for the HT capabilities.
>
> Sure, I just did not see any code for this in these patches. My point
> about the hw config vs fake/mod'd is if we'd expose the mod'd config
> changes to userspace or if we'd keep them internal to cfg80211. How
> would this be dealt with?
Right now, cfg80211 doesn't know enough to handle this stuff on its own,
so let's handle it in the driver completely on the first iteration. The
patches do not need any changes for this right now.
- Felix
^ permalink raw reply
* Re: Regulatory domain
From: Emmanuel Grumbach @ 2010-08-02 9:29 UTC (permalink / raw)
To: Sebastien Cayetanot; +Cc: linux-wireless
In-Reply-To: <4C5683C9.1090504@linux.intel.com>
>>
>> (aaaa-bbbb @ c),(n/a, 23), XXX
>>
>> each line is a range in frequencies (channels that fall between aaaa
>> and bbbb. c is the channel width (10 Mhz for Japan's narrow channels,
>> 20 Mhz for regular channels and 40 Mhz for wide channels). 23 is the
>> maximum Tx power e.i.r.p. in db.
>
> Many thanks for your support and the link. One additional parameter 'N/A' is
> my example are sometimes fills w/ a number depending on the country I set.
>
> What is the meaning of this parameter, I didn't catch it on the Regulatory
> page.
It is the maximum antenna gain: look at
http://wireless.kernel.org/en/developers/Regulatory/Database and click
on one of the countries there.
>
> Thx
>
> Sebastien
>
^ permalink raw reply
* Re: [PATCH v5] cfg80211: Add nl80211 antenna configuration
From: Luis R. Rodriguez @ 2010-08-02 9:23 UTC (permalink / raw)
To: Felix Fietkau; +Cc: Bruno Randolf, johannes, linville, linux-wireless
In-Reply-To: <4C568D23.2000203@openwrt.org>
On Mon, Aug 2, 2010 at 2:17 AM, Felix Fietkau <nbd@openwrt.org> wrote:
> On 2010-08-02 11:10 AM, Luis R. Rodriguez wrote:
>> On Mon, Aug 2, 2010 at 1:59 AM, Felix Fietkau <nbd@openwrt.org> wrote:
>>> On 2010-08-02 7:37 AM, Luis R. Rodriguez wrote:
>>>> I'm not, the point I was trying to make is that solving this for
>>>> legacy and that for 802.11n this needs more thought and work.
>>> I need this for 802.11n as well, and I believe the API is good enough
>>> for that.
>>
>> Sure.
>>
>>>>> as long as the API is flexible
>>>>> enough i think it can be added later as 802.11n devices are going to accept
>>>>> antenna configuration.
>>>>
>>>> If you want really flexible stuff without addressing serious
>>>> considerations before introducing a new kernel API then use debugfs.
>>> I'd like to see this in nl80211. Is there any specific concern left that
>>> I haven't addressed already? If so, please point me at it...
>>
>> The code that deals with not accepting changes unless we're not
>> associated, and that also caches the old real hw config vs the
>> modified one.
> This is not really an API issue, this is more of an implementation
> aspect. I think it's up to the driver to reject changes that it cannot
> handle at the moment.
Huh,why not deal with this on cfg80211 and/or mac80211?
> For legacy, changing settings is fine in any state (even with assoc).
Sure.
> For 802.11n, changes that affect the chainmask should be rejected while
> the interface is up. That way we don't run into weird cached config vs
> hw config issues, and also keep a sane state for the HT capabilities.
Sure, I just did not see any code for this in these patches. My point
about the hw config vs fake/mod'd is if we'd expose the mod'd config
changes to userspace or if we'd keep them internal to cfg80211. How
would this be dealt with?
Luis
^ permalink raw reply
* Re: [PATCH v5] cfg80211: Add nl80211 antenna configuration
From: Felix Fietkau @ 2010-08-02 9:17 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Bruno Randolf, johannes, linville, linux-wireless
In-Reply-To: <AANLkTi=Qm53CgFNNgtF4iBvh3jbfYzd8XPH4y9ysUaoV@mail.gmail.com>
On 2010-08-02 11:10 AM, Luis R. Rodriguez wrote:
> On Mon, Aug 2, 2010 at 1:59 AM, Felix Fietkau <nbd@openwrt.org> wrote:
>> On 2010-08-02 7:37 AM, Luis R. Rodriguez wrote:
>>> I'm not, the point I was trying to make is that solving this for
>>> legacy and that for 802.11n this needs more thought and work.
>> I need this for 802.11n as well, and I believe the API is good enough
>> for that.
>
> Sure.
>
>>>> as long as the API is flexible
>>>> enough i think it can be added later as 802.11n devices are going to accept
>>>> antenna configuration.
>>>
>>> If you want really flexible stuff without addressing serious
>>> considerations before introducing a new kernel API then use debugfs.
>> I'd like to see this in nl80211. Is there any specific concern left that
>> I haven't addressed already? If so, please point me at it...
>
> The code that deals with not accepting changes unless we're not
> associated, and that also caches the old real hw config vs the
> modified one.
This is not really an API issue, this is more of an implementation
aspect. I think it's up to the driver to reject changes that it cannot
handle at the moment.
For legacy, changing settings is fine in any state (even with assoc).
For 802.11n, changes that affect the chainmask should be rejected while
the interface is up. That way we don't run into weird cached config vs
hw config issues, and also keep a sane state for the HT capabilities.
- Felix
^ permalink raw reply
* Re: [PATCH v5] cfg80211: Add nl80211 antenna configuration
From: Luis R. Rodriguez @ 2010-08-02 9:10 UTC (permalink / raw)
To: Felix Fietkau; +Cc: Bruno Randolf, johannes, linville, linux-wireless
In-Reply-To: <4C5688F7.1070200@openwrt.org>
On Mon, Aug 2, 2010 at 1:59 AM, Felix Fietkau <nbd@openwrt.org> wrote:
> On 2010-08-02 7:37 AM, Luis R. Rodriguez wrote:
>> I'm not, the point I was trying to make is that solving this for
>> legacy and that for 802.11n this needs more thought and work.
> I need this for 802.11n as well, and I believe the API is good enough
> for that.
Sure.
>>> as long as the API is flexible
>>> enough i think it can be added later as 802.11n devices are going to accept
>>> antenna configuration.
>>
>> If you want really flexible stuff without addressing serious
>> considerations before introducing a new kernel API then use debugfs.
> I'd like to see this in nl80211. Is there any specific concern left that
> I haven't addressed already? If so, please point me at it...
The code that deals with not accepting changes unless we're not
associated, and that also caches the old real hw config vs the
modified one.
Luis
^ permalink raw reply
* Re: [PATCH v5] cfg80211: Add nl80211 antenna configuration
From: Felix Fietkau @ 2010-08-02 8:59 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Bruno Randolf, johannes, linville, linux-wireless
In-Reply-To: <AANLkTimRnfa8HVpi0hcP7Eo9Nrns60ff3Hs+fq39WoJh@mail.gmail.com>
On 2010-08-02 7:37 AM, Luis R. Rodriguez wrote:
> I'm not, the point I was trying to make is that solving this for
> legacy and that for 802.11n this needs more thought and work.
I need this for 802.11n as well, and I believe the API is good enough
for that.
>> as long as the API is flexible
>> enough i think it can be added later as 802.11n devices are going to accept
>> antenna configuration.
>
> If you want really flexible stuff without addressing serious
> considerations before introducing a new kernel API then use debugfs.
I'd like to see this in nl80211. Is there any specific concern left that
I haven't addressed already? If so, please point me at it...
- Felix
^ permalink raw reply
* Re: SMC 2802W -status unsupported
From: Christian Lamparter @ 2010-08-02 8:46 UTC (permalink / raw)
To: David Cozatt; +Cc: linux-wireless
In-Reply-To: <AANLkTi=XOECFnOgB5mmaDejVhH2aAEedYqz9tyeSz7Ge@mail.gmail.com>
On Sunday 01 August 2010 18:17:16 David Cozatt wrote:
> Accessing http://wireless.kernel.org/en/users/Drivers/p54 shows in unsupported
>
> * early PrismGT cards (e.g.: Netgear WG511v1, SMC 2802W)
>
> phy0: hwaddr 00:04:e2:63:c2:67, MAC:isl3890 RF:Duette3
>
> [...]
>
> Mine is the -164 version. Anything else needed to confirm working properly?
No,
but it would be great if we could have a copy of that EEPROM.
I've attached inline-patch that will dump its content to
the console via kernel messaging system.
If you are not entirely familiar with the procedure, then let
me know (off-list), I'm sure we can work that out.
Regards,
Christian
---
diff --git a/drivers/net/wireless/p54/eeprom.c b/drivers/net/wireless/p54/eeprom.c
index d687cb7..84eb993 100644
--- a/drivers/net/wireless/p54/eeprom.c
+++ b/drivers/net/wireless/p54/eeprom.c
@@ -544,6 +544,8 @@ int p54_parse_eeprom(struct ieee80211_hw *dev, void *eeprom, int len)
wrap = (struct eeprom_pda_wrap *) eeprom;
entry = (void *)wrap->data + le16_to_cpu(wrap->len);
+ print_hex_dump_bytes("P54E:", DUMP_PREFIX_OFFSET, eeprom, len);
+
/* verify that at least the entry length/code fits */
while ((u8 *)entry <= end - sizeof(*entry)) {
entry_len = le16_to_cpu(entry->len);
^ permalink raw reply related
* Re: Regulatory domain
From: Sebastien Cayetanot @ 2010-08-02 8:37 UTC (permalink / raw)
To: Emmanuel Grumbach; +Cc: linux-wireless
In-Reply-To: <AANLkTin5jKr4BQdxooy4NRjmBja2Z8TPdgE-5RV++AQh@mail.gmail.com>
On 8/1/2010 8:08 AM, Emmanuel Grumbach wrote:
>> country JP:
>> (2402 - 2472 @ 40), (N/A, 20)
>> (2457 - 2482 @ 20), (N/A, 20)
>> (2474 - 2494 @ 20), (N/A, 20), NO-OFDM
>> (4910 - 4930 @ 10), (N/A, 23)
>> (4910 - 4990 @ 40), (N/A, 23)
>> (4930 - 4950 @ 10), (N/A, 23)
>> (5030 - 5045 @ 10), (N/A, 23)
>> (5030 - 5090 @ 40), (N/A, 23)
>> (5050 - 5060 @ 10), (N/A, 23)
>> (5170 - 5250 @ 40), (N/A, 20)
>> (5250 - 5330 @ 40), (N/A, 20), DFS
>> (5490 - 5710 @ 40), (N/A, 23), DFS
>>
>> I would like to understand exactly what is displayed.
>>
>> - the number of line (xxx-xxx @ xx), (xx,xx) is equal to the number of channel which can be accessed
>> - What is the meaning of each line and details on each parameter.
>>
> http://wireless.kernel.org/en/developers/Regulatory
>
> (aaaa-bbbb @ c),(n/a, 23), XXX
>
> each line is a range in frequencies (channels that fall between aaaa
> and bbbb. c is the channel width (10 Mhz for Japan's narrow channels,
> 20 Mhz for regular channels and 40 Mhz for wide channels). 23 is the
> maximum Tx power e.i.r.p. in db.
Many thanks for your support and the link. One additional parameter
'N/A' is my example are sometimes fills w/ a number depending on the
country I set.
What is the meaning of this parameter, I didn't catch it on the
Regulatory page.
Thx
Sebastien
^ permalink raw reply
* Re: [PATCH v2 00/20] native support for wl1271 on ZOOM
From: Luciano Coelho @ 2010-08-02 8:16 UTC (permalink / raw)
To: ext John W. Linville
Cc: Ohad Ben-Cohen, linux-wireless@vger.kernel.org,
linux-mmc@vger.kernel.org, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux@arm.linux.org.uk,
Chikkature Rajashekar Madhusudhan, akpm@linux-foundation.org,
San Mehat, Quadros Roger (Nokia-MS/Helsinki), Tony Lindgren,
Nicolas Pitre, Pandita Vikram, Kalle Valo
In-Reply-To: <20100726193028.GG3903@tuxdriver.com>
On Mon, 2010-07-26 at 21:30 +0200, ext John W. Linville wrote:
> On Wed, Jul 21, 2010 at 08:33:34PM +0300, Ohad Ben-Cohen wrote:
> > This patch series adds native support for wl1271 on ZOOM.
>
> Just for the record, I'm fine with the wl1271 bits here going through
> the omap tree with the rest of the series.
Yeah, I agree. This is probably the best way to keep things in sync.
--
Cheers,
Luca.
^ permalink raw reply
* Re: MX27 libertas_sdio SDIO Interrupts vs available bitrate
From: Andreas Feuersinger @ 2010-08-02 6:40 UTC (permalink / raw)
To: Gabay, Benzy
Cc: libertas-dev@lists.infradead.org, linux-mmc@vger.kernel.org,
linux-wireless@vger.kernel.org
In-Reply-To: <676FD6AA0F002F49B89E70F0C5EFD22C1311499C43@dlee04.ent.ti.com>
Hi Benzy Gabay,
On Fri, 30 Jul 2010 15:08:06 -0500
"Gabay, Benzy" <benzyg@ti.com> wrote:
> > I figured, it does not make any difference wheter I use DMA for data
> > transfer or not (odd?)
> If interrupts are not handled in MMC level and you are disabling DMA
> operation how then will the transfer completion is handled in that
> case?
>
PIO transfer is used in function mxcmci_cmd_done. A while loop cycles
and calls readl until the buffer is read.
Afterwards CRC checks and stuff is done.
Enabling DMA exits prior that code section calling mxc_dma_enable.
^ permalink raw reply
* Re: SMC 2802W -status unsupported
From: Geoff Simmons @ 2010-08-02 6:17 UTC (permalink / raw)
To: Larry Finger; +Cc: David Cozatt, linux-wireless
In-Reply-To: <4C55DA66.3090507@lwfinger.net>
On Sun, Aug 01, 2010 at 03:34:46PM -0500, Larry Finger wrote:
> Looking at the driver code, we need the patch below to enable the
> device:
[...]
> + /* Standard Microsystems Corp SMC2802W Wireless PCI */
> + { PCI_DEVICE(0x10b8, 0x2802) },
No, 10b8:2802 is the subsystem ID of the SMC2802W v1.
Both v1 and v2 use 1260:3890 as their device ID, which is already
defined in p54pci.c. Your patch is not necessary.
Geoff
^ permalink raw reply
* Re: [PATCH v5] cfg80211: Add nl80211 antenna configuration
From: Luis R. Rodriguez @ 2010-08-02 5:37 UTC (permalink / raw)
To: Bruno Randolf; +Cc: johannes, linville, nbd, linux-wireless
In-Reply-To: <201008021313.54850.br1@einfach.org>
On Sun, Aug 1, 2010 at 9:13 PM, Bruno Randolf <br1@einfach.org> wrote:
> On Fri July 30 2010 00:04:49 Luis R. Rodriguez wrote:
>> >> I don't want to do any work myself on drivers for this, can we have
>> >> cfg80211/mac80211 do this for us?
>> >
>> > is this not a separate issue from defining the API? you could have it do
>> > this for you even now, with or without the antenna API, no?
>>
>> It depends on the consumer and at what level we think the consumer
>> should be doing whatever checks or changes it should. For starters I
>> would expect at least a check for association within cfg80211 which
>> disallows hw config changes.
>
> for ath5k at least, it's o.k. to change antenna configuration during
> association.
Then do it through debugfs.
> if 802.11n devices cannot change antenna setup during association, the driver
> could simply reject the configuration. but i can see that it can make sense to
> handle some of this in cfg80211 or mac80211. it should be possible to add that
> on top of my patches.
I would expect the respective changes within your patches, not after.
> i think you are expecting to much.
I refuse to accept patches which can potentially create bogus bug
reports or loose crap implementations in drivers. Wext had a lot of
this and I am glad we haven't yet allowed for this crap with nl80211.
To allow your patch to go through as-is without addressing all the
points made would be enabling driver developers to get real sloppy.
> for now i just want to define an API which
> 1) can be used right now and 2) is flexible enough to support 802.11n devices.
Use debugfs or consider a simple API for legacy for nl80211.
> as i don't work with 802.11n devices right now, please don't expect me to
> solve all 802.11n related antenna problems.
I'm not, the point I was trying to make is that solving this for
legacy and that for 802.11n this needs more thought and work.
> as long as the API is flexible
> enough i think it can be added later as 802.11n devices are going to accept
> antenna configuration.
If you want really flexible stuff without addressing serious
considerations before introducing a new kernel API then use debugfs.
Luis
^ permalink raw reply
* Re: [PATCH v4 1/3] cfg80211: Add nl80211 antenna configuration
From: Luis R. Rodriguez @ 2010-08-02 5:31 UTC (permalink / raw)
To: Bruno Randolf; +Cc: Felix Fietkau, johannes, linville, linux-wireless
In-Reply-To: <201008021259.16623.br1@einfach.org>
On Sun, Aug 1, 2010 at 8:59 PM, Bruno Randolf <br1@einfach.org> wrote:
> On Fri July 30 2010 00:09:17 you wrote:
>> On Wed, Jul 28, 2010 at 7:11 PM, Bruno Randolf <br1@einfach.org> wrote:
>> > i already tried to explain several times why FIXED_A, FIXED_B, or
>> > DIVERSITY is not enough even for "legacy". please re-read the mails and
>> > the description of the first patch - i really don't want to re-iterate
>> > it *again*. thanks :)
>>
>> What legacy device and respective device driver do we support upstream
>> on the kernel that has this sort of extra antenna setup? Do you
>> foresee this happening?
>
> right now, probably none. but it's easy to this to ath5k. madwifi supported it
> and it's just a matter of setting tx and rx antennas (it's already there as
> AR5K_ANTMODE_DEBUG). i might add it, just to make my case... ;)
>
> anyhow, i can see your point of view now. but while you might not care about
> anything before 802.11n - there are millions of what you call 'legacy' chips
> out there (and you guys are actually still selling them!), so i think it's
> worth it to properly support them, especially since i still believe that my
> proposal is usable for both 802.11n and before.
I am not saying to drop legacy support I am saying to just support
legacy via the two standard antenna model because there is nothing
visible being supported which I think merits expanding a simple API
for legacy.
Luis
^ permalink raw reply
* Re: [PATCH] net: wl12xx: do not use kfree'd memory
From: Juuso Oikarinen @ 2010-08-02 5:04 UTC (permalink / raw)
To: ext Kulikov Vasiliy
Cc: kernel-janitors@vger.kernel.org,
Coelho Luciano (Nokia-MS/Helsinki), John W. Linville,
Paasikivi Teemu.3 (EXT-Ixonos/Tampere),
linux-wireless@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <1280594039-3246-1-git-send-email-segooon@gmail.com>
On Sat, 2010-07-31 at 18:33 +0200, ext Kulikov Vasiliy wrote:
> wl1271_dump() uses cmd after kfree(cmd). Move kfree() just after
> wl1271_dump().
>
> Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
> ---
> drivers/net/wireless/wl12xx/wl1271_spi.c | 3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/wl12xx/wl1271_spi.c b/drivers/net/wireless/wl12xx/wl1271_spi.c
> index 96d25fb..4cb99c5 100644
> --- a/drivers/net/wireless/wl12xx/wl1271_spi.c
> +++ b/drivers/net/wireless/wl12xx/wl1271_spi.c
> @@ -160,9 +160,8 @@ static void wl1271_spi_init(struct wl1271 *wl)
> spi_message_add_tail(&t, &m);
>
> spi_sync(wl_to_spi(wl), &m);
> - kfree(cmd);
> -
> wl1271_dump(DEBUG_SPI, "spi init -> ", cmd, WSPI_INIT_CMD_LEN);
> + kfree(cmd);
> }
>
> #define WL1271_BUSY_WORD_TIMEOUT 1000
Whoops ;) Good catch, thanks.
Acked-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
-Juuso
^ permalink raw reply
* Re: virtual access poitns (ath5k/mac80211)
From: Ben Greear @ 2010-08-02 5:00 UTC (permalink / raw)
To: Ryszard; +Cc: Florian Fainelli, Patrick McHardy, linux-wireless
In-Reply-To: <AANLkTi=FEFrKdXUHN-h-BZruvNzSmwXdPcq9-OgZcFAM@mail.gmail.com>
On 08/01/2010 06:51 PM, Ryszard wrote:
> Hey ben,
>
> thanks for the reply on this.
>
> perhaps i'm missing something fundamental along the way. here is what
> i've done:
>
> iw dev phy0 interface add sta0 type station
> iw dev wlan0 interface add sta0 type station
> iw dev wlan0 interface add sta1 type station
>
> iw dev wlan0 interface add vap0 type __ap
> iw dev wlan0 interface add vap1 type __a
> p
>
> vap1, vap0, sta0 and sta1_rename
>
> output from iwconfig:
> wlan0 IEEE 802.11abg ESSID:off/any
> Mode:Managed Access Point: Not-Associated Tx-Power=20 dBm
> Retry long limit:7 RTS thr:off Fragment thr:off
> Encryption key:off
> Power Management:off
> sta0 IEEE 802.11abg ESSID:off/any
> Mode:Managed Access Point: Not-Associated Tx-Power=20 dBm
> Retry long limit:7 RTS thr:off Fragment thr:off
> Encryption key:off
> Power Management:off
> sta1_rename IEEE 802.11abg ESSID:off/any
> Mode:Managed Access Point: Not-Associated Tx-Power=20 dBm
> Retry long limit:7 RTS thr:off Fragment thr:off
> Encryption key:off
> Power Management:off
> vap0 IEEE 802.11abg ESSID:off/any
> Mode:Managed Access Point: Not-Associated Tx-Power=20 dBm
> Retry long limit:7 RTS thr:off Fragment thr:off
> Encryption key:off
> Power Management:off
> vap1 IEEE 802.11abg Mode:Master Frequency:2.457 GHz Tx-Power=20 dBm
> Retry long limit:7 RTS thr:off Fragment thr:off
> Power Management:off
> to get the interface up i've used macchanger on one of the vap
> interfaces. I've also got (isc) DHCP set and listening on the vapn and
> when i run hostapd on the vapn interface i get mon.vapn . using a
> wireless client, i can get an ip address assigned from one interface
> (vap0), but not the other. I also get a call trace in syslog which i
> guess could be the very problem.
>
> I realise i've not listed a specific course of events/driver versions
> i've followed here, but i am willing to lay it all down in a blow by
> blow repeatable sequence if thats what it takes. in fact aside from
> coding (i'm not a coder except for perl) i'm willing to do whatever to
> get it working, and provide any doco for the community...
Well, please show the trace. Also, are you loading the driver with
hwcrypt disabled?
Here are my notes (ath9k doesn't work yet, btw).
# Make udev get out of the way
vi /etc/udev/rules.d/75-persistent-net-generator.rules
or, for F11:
vi /lib/udev/rules.d/75-persistent-net-generator.rules
# device name whitelist
#KERNEL!="eth*|ath*|wlan*[0-9]|ra*|sta*|ctc*|lcs*|hsi*", GOTO="persistent_net_generator_end"
KERNEL!="eth*|ath*|ra*|ctc*|lcs*|hsi*", GOTO="persistent_net_generator_end"
# Skip virtual interfaces of all types.
SUBSYSTEM=="net", ACTION=="add", ATTR(iflink)!="0", GOTO="persistent_net_generator_end"
# delete lines similar to this in /etc/udev/rules.d/70-persistent-net.rules, if it exists.
# PCI device 0x168c:0x0013 (ath5k)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0b:6b:83:5f:a6", ATTR{type}=="1", NAME="wlan0"
# Fix up modprobe.conf to turn off hwaccel for ath5k:
echo options ath5k nohwcrypt=1 >> /etc/modprobe.d/ath5k.conf
echo options ath9k nohwcrypt=1 >> /etc/modprobe.d/ath9k.conf
# Mount debug-fs
echo debugfs /debug debugfs defaults 0 0 >> /etc/fstab
mkdir /debug
>
> regs R
>
> On 2 August 2010 08:21, Ben Greear <greearb@candelatech.com
> <mailto:greearb@candelatech.com>> wrote:
>
> On 08/01/2010 01:56 PM, Ryszard wrote:
>
> Hey Florian,
>
> thanks for the help on this! Ben/Patrick, if you rebase the patches
> for this functionality, i'm more than happy and willing to do
> userland
> testing on this to move it along.
>
> regs
>
> On 1 August 2010 19:37, Florian Fainelli<florian@openwrt.org
> <mailto:florian@openwrt.org>> wrote:
>
> Hi,
>
> Le Sunday 1 August 2010 03:53:13, Ryszard a écrit :
>
> Hi all,
>
> i'm working on a project that requires i can create
> multiple access
> points on the one bit of hardware. After an insane
> amount of googling
> and reading the lists the closest i've been able to come
> up with is
> something along the lines of:
> iw dev wlan0 interface add vap0 type __ap
> iw dev wlan0 interface add vap1 type __ap
>
> then using macchanger to assign unique mac addresses.
>
> I've also seen something from March 2009
> (http://lwn.net/Articles/321690/) that hints at the
> functionality
> available with the ath9k which gave me a bit of hope!
>
> My question is, is it possible to create multiple
> virtual access
> points with my hardware ( Atheros Communications Inc.
> AR5413 802.11abg
> ) and the ath5k/mac80211 drivers (or is there some other
> method to
> achieve what i'm after) ? i'm not too fussed about
> different
> channels, but different SSID's and WPA keys are a
> requirement for the
> project.
>
>
> There is support for creating virtual interfaces using iw
> and ath5k here:
> http://www.candelatech.com/oss/vsta.html
>
> I really wish someone could submit this mainline,
> unfortunately it is pretty
> hard to isolate the commits in this tree which are
> implementing virtual
> interfaces support.
>
> Ben, Patrick, could you rebase your patches on top of
> wireless-testing and
> send them for review/testing?
>
>
> You would not believe how hard it is to keep up with the wireless
> tree. Last time,
> by the time we had something stable, upstream had changed too much
> to merge.
>
> The merge from .31 to .34 was basically not happening, so we are
> trying to
> re-do things from scratch. I've been busy working on other .34 bugs
> (and
> updating our user-space stuff to work with .34), and haven't heard from
> Patrick in a while.
>
> We plan to get this done, but I don't know when.
>
> For what it's worth, our .31 code works pretty well, supporting
> virtual STA
> and APs and deals with multiple STAs trying to all scan at once, etc.
>
> Thanks,
> Ben
>
> --
> Ben Greear <greearb@candelatech.com <mailto:greearb@candelatech.com>>
> Candela Technologies Inc http://www.candelatech.com
>
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH v5] cfg80211: Add nl80211 antenna configuration
From: Bruno Randolf @ 2010-08-02 4:13 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: johannes, linville, nbd, linux-wireless
In-Reply-To: <AANLkTi=ihY=pAmKaEp7Pga=DOxwASZqSxqmURbgnks-d@mail.gmail.com>
On Fri July 30 2010 00:04:49 Luis R. Rodriguez wrote:
> >> I don't want to do any work myself on drivers for this, can we have
> >> cfg80211/mac80211 do this for us?
> >
> > is this not a separate issue from defining the API? you could have it do
> > this for you even now, with or without the antenna API, no?
>
> It depends on the consumer and at what level we think the consumer
> should be doing whatever checks or changes it should. For starters I
> would expect at least a check for association within cfg80211 which
> disallows hw config changes.
for ath5k at least, it's o.k. to change antenna configuration during
association.
if 802.11n devices cannot change antenna setup during association, the driver
could simply reject the configuration. but i can see that it can make sense to
handle some of this in cfg80211 or mac80211. it should be possible to add that
on top of my patches.
i think you are expecting to much. for now i just want to define an API which
1) can be used right now and 2) is flexible enough to support 802.11n devices.
as i don't work with 802.11n devices right now, please don't expect me to
solve all 802.11n related antenna problems. as long as the API is flexible
enough i think it can be added later as 802.11n devices are going to accept
antenna configuration.
bruno
^ permalink raw reply
* Re: [PATCH v4 1/3] cfg80211: Add nl80211 antenna configuration
From: Bruno Randolf @ 2010-08-02 3:59 UTC (permalink / raw)
To: Luis R. Rodriguez, Felix Fietkau, johannes, linville,
linux-wireless
In-Reply-To: <AANLkTinH-2VNYGGBVha-M2HOzYJYe_GBb3Ww1V6i6Hyc@mail.gmail.com>
On Fri July 30 2010 00:09:17 you wrote:
> On Wed, Jul 28, 2010 at 7:11 PM, Bruno Randolf <br1@einfach.org> wrote:
> > i already tried to explain several times why FIXED_A, FIXED_B, or
> > DIVERSITY is not enough even for "legacy". please re-read the mails and
> > the description of the first patch - i really don't want to re-iterate
> > it *again*. thanks :)
>
> What legacy device and respective device driver do we support upstream
> on the kernel that has this sort of extra antenna setup? Do you
> foresee this happening?
right now, probably none. but it's easy to this to ath5k. madwifi supported it
and it's just a matter of setting tx and rx antennas (it's already there as
AR5K_ANTMODE_DEBUG). i might add it, just to make my case... ;)
anyhow, i can see your point of view now. but while you might not care about
anything before 802.11n - there are millions of what you call 'legacy' chips
out there (and you guys are actually still selling them!), so i think it's
worth it to properly support them, especially since i still believe that my
proposal is usable for both 802.11n and before.
bruno
^ permalink raw reply
* Re: iwlwifi connection problems
From: Alex Romosan @ 2010-08-02 0:18 UTC (permalink / raw)
To: Johannes Berg; +Cc: Guy, Wey-Yi, linux-wireless@vger.kernel.org
In-Reply-To: <1280212629.19098.0.camel@jlt3.sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> writes:
> On Mon, 2010-07-26 at 21:59 -0700, Alex Romosan wrote:
>
>> any ideas on how i can debug this? i tried to do a git-bisect but i
>> didn't get anywhere. i have the driver compiled in the kernel if that
>> makes any difference. as i played with the later kernels (after 2.6.34)
>> i discovered that if kept bringing the interface down and then up again
>> eventually i would get "cfg80211: Calling CRDA to update world
>> regulatory domain" the antenna light on the laptop (i have a thinkpad
>> t61) would go off and then at the next ifup the driver connected. looks
>> like some kind of reset/initialization problem to me.
>
> So is the issue maybe the channel the AP is no, not the fact that it's
> hidden? or something like that?
it's still not working even with kernel 2.6.35 so i decided to play with
it a little bit more. indeed, it has nothing to do with the access
point being hidden or not. it doesn't work even when it's visible
(previously i was able to connect to the wireless at work which is
visible so i wrongly assumed that was the cause).
so it looks like the problem is connecting to this particular access
point which is a proxim ap-200 orinoco wireless ap i got in 2003. right
now the ap is setup on channel 3 and the rate is set to 11 Mbps. should
i try a different channel? which one?
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
^ 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