* Re: [ath5k-devel] [PATCH v3] ath5k: disable ASPM
From: Maxim Levitsky @ 2010-07-28 23:48 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Matthew Garrett, ath5k-devel@lists.ath5k.org,
linux-wireless@vger.kernel.org, David Quan, Luis R. Rodriguez,
linux-kernel, kernel-team@lists.ubuntu.com, Luis Rodriguez,
Jussi Kivilinna, tim.gardner@canonical.com
In-Reply-To: <AANLkTim1sZ5ZoGcrsdCw8dFSzUj4igZOiq7irKsdbfXR@mail.gmail.com>
On Tue, 2010-07-27 at 08:57 -0700, Luis R. Rodriguez wrote:
> On Tue, Jul 27, 2010 at 2:35 AM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
> > On Mon, 2010-07-26 at 23:50 +0100, Matthew Garrett wrote:
> >> On Mon, Jul 26, 2010 at 03:43:04PM -0700, Luis R. Rodriguez wrote:
> >>
> >> > I see.. thanks Mathew... in that case since L1 works on all devices we
> >> > could just force enable L1 for all PCIE devices. What do you think?
> >>
> >> Works for me.
> >>
> >
> > On the second thought, there is no 'pci_enable_link_state' :-)
> > I afraid that if I add it, I might not do that right for all cases, thus
> > do more harm that good...
>
> I'm sorry, can you elaborate?
I mean ASPM code doesn't have a function to undo effects of the
blacklist (due to pre 1.1 pcie device).
Its not that simple to write such function.
Best regards,
Maxim Levitsky
^ permalink raw reply
* [PATCH] mwl8k: change maintenance status
From: Lennert Buytenhek @ 2010-07-28 23:47 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless
The 8366 AP support in particular is still rather incomplete, but
this is unlikely to be addressed any time soon.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
diff --git a/MAINTAINERS b/MAINTAINERS
index c9a3fe0..8edb240 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3619,7 +3619,7 @@ F: include/linux/mv643xx.h
MARVELL MWL8K WIRELESS DRIVER
M: Lennert Buytenhek <buytenh@wantstofly.org>
L: linux-wireless@vger.kernel.org
-S: Maintained
+S: Odd Fixes
F: drivers/net/wireless/mwl8k.c
MARVELL SOC MMC/SD/SDIO CONTROLLER DRIVER
^ permalink raw reply related
* [PATCH] cfg80211: fix dev <-> wiphy typo
From: Christian Lamparter @ 2010-07-28 23:28 UTC (permalink / raw)
To: linux-wireless; +Cc: Joe Perches, John W. Linville
Cc: Joe Perches <joe@perches.com>
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
---
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index ae80f8f..2fd06c6 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -2451,7 +2451,7 @@ int wiphy_debug(const struct wiphy *wiphy, const char *format, ...)
wiphy_printk(KERN_DEBUG, wiphy, format, ##args)
#elif defined(CONFIG_DYNAMIC_DEBUG)
#define wiphy_dbg(wiphy, format, args...) \
- dynamic_pr_debug("%s: " format, wiphy_name(dev), ##args)
+ dynamic_pr_debug("%s: " format, wiphy_name(wiphy), ##args)
#else
#define wiphy_dbg(wiphy, format, args...) \
({ \
^ permalink raw reply related
* Re: [PATCH 1/3] ath9k: prevent calibration during off-channel activity
From: Luis R. Rodriguez @ 2010-07-28 22:48 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, linville
In-Reply-To: <AANLkTin+sPu45teiAiePPWdBp3huffds3v_uzJBtKmLO@mail.gmail.com>
On Wed, Jul 28, 2010 at 3:47 PM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> On Wed, Jul 28, 2010 at 3:28 PM, Felix Fietkau <nbd@openwrt.org> wrote:
>> On 2010-07-29 12:12 AM, Luis R. Rodriguez wrote:
>>> On Wed, Jul 28, 2010 at 2:08 PM, Felix Fietkau <nbd@openwrt.org> wrote:
>>>> On 2010-07-28 10:43 PM, Luis R. Rodriguez wrote:
>>>>> On Wed, Jul 28, 2010 at 10:45 AM, Felix Fietkau <nbd@openwrt.org> wrote:
>>>>>> Previously the software scan callback was used to indicate to the hardware,
>>>>>> when it was safe to calibrate. This didn't really work properly, because it
>>>>>> depends on a specific order of software scan callbacks vs. channel changes.
>>>>>> Also, software scans are not the only thing that triggers off-channel
>>>>>> activity, so it's better to use the newly added indication from mac80211 for
>>>>>> this and not use the software scan callback for anything calibration related.
>>>>>>
>>>>>> This fixes at least some of the invalid noise floor readings that I've seen
>>>>>> in AP mode on AR9160
>>>>>
>>>>> Neat!
>>>>>
>>>>>> --- a/drivers/net/wireless/ath/ath9k/main.c
>>>>>> +++ b/drivers/net/wireless/ath/ath9k/main.c
>>>>>> @@ -154,6 +154,27 @@ void ath9k_ps_restore(struct ath_softc *sc)
>>>>>> spin_unlock_irqrestore(&sc->sc_pm_lock, flags);
>>>>>> }
>>>>>> spin_unlock_irqrestore(&sc->sc_pm_lock, flags);
>>>>>> }
>>>>>>
>>>>>> +static void ath_start_ani(struct ath_common *common)
>>>>>> +{
>>>>>> + struct ath_hw *ah = common->ah;
>>>>>> + unsigned long timestamp = jiffies_to_msecs(jiffies);
>>>>>> + struct ath_softc *sc = (struct ath_softc *) common->priv;
>>>>>> +
>>>>>> + if (!(sc->sc_flags & SC_OP_ANI_RUN))
>>>>>> + return;
>>>>>> +
>>>>>> + if (sc->sc_flags & SC_OP_OFFCHANNEL)
>>>>>> + return;
>>>>>> +
>>>>>> + common->ani.longcal_timer = timestamp;
>>>>>> + common->ani.shortcal_timer = timestamp;
>>>>>> + common->ani.checkani_timer = timestamp;
>>>>>> +
>>>>>> + mod_timer(&common->ani.timer,
>>>>>> + jiffies +
>>>>>> + msecs_to_jiffies((u32)ah->config.ani_poll_interval));
>>>>>> +}
>>>>>
>>>>> I would prefer if you do this sort of code shift in a separate patch.
>>>>> In this case its pretty easy to see the code is the same so I think
>>>>> its fine the way it is now but for next time please. Otherwise looks
>>>>> good, thanks!!
>>>> If it had been a bigger function, I'd have made a separate patch, but I
>>>> figured for something as trivial as this it wouldn't matter.
>>>
>>> iw event -t while pinging and then issuing a scan:
>>>
>>> 1280354915.820607: wlan32 (phy #0): scan started
>>> 1280354920.390438: wlan32 (phy #0): scan finished: 2412 2417 2422 2427
>>> 2432 2437 2442 2447 2452 2457 2462 5180 5200 5220 5240 5260 5280 5300
>>> 5320 5500 5520 5540 5560 5580 5660 5680 5700 5745 5765 5785 5805 5825,
>>> ""
>>> 1280354923.103628: wlan32 (phy #0): deauth FOO -> BAR reason 4:
>>> Disassociated due to inactivity
>>> 1280354923.103736: wlan32 (phy #0): disconnected (local request)
>>> 1280354923.111251: phy #0: regulatory domain change: set to world
>>> roaming by the wireless core upon initialization request
>>>
>>> So this seems to re-introduce the same issue I was seeing before.
>>
>> Are you sure it's this change?
>
> Just reverted the changes and it works without these issues.
Also without these patches I get 0% packet loss, with the patches
applied I get some packet loss.
Luis
^ permalink raw reply
* Re: [PATCH 1/3] ath9k: prevent calibration during off-channel activity
From: Luis R. Rodriguez @ 2010-07-28 22:47 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, linville
In-Reply-To: <4C50AEF4.4060905@openwrt.org>
On Wed, Jul 28, 2010 at 3:28 PM, Felix Fietkau <nbd@openwrt.org> wrote:
> On 2010-07-29 12:12 AM, Luis R. Rodriguez wrote:
>> On Wed, Jul 28, 2010 at 2:08 PM, Felix Fietkau <nbd@openwrt.org> wrote:
>>> On 2010-07-28 10:43 PM, Luis R. Rodriguez wrote:
>>>> On Wed, Jul 28, 2010 at 10:45 AM, Felix Fietkau <nbd@openwrt.org> wrote:
>>>>> Previously the software scan callback was used to indicate to the hardware,
>>>>> when it was safe to calibrate. This didn't really work properly, because it
>>>>> depends on a specific order of software scan callbacks vs. channel changes.
>>>>> Also, software scans are not the only thing that triggers off-channel
>>>>> activity, so it's better to use the newly added indication from mac80211 for
>>>>> this and not use the software scan callback for anything calibration related.
>>>>>
>>>>> This fixes at least some of the invalid noise floor readings that I've seen
>>>>> in AP mode on AR9160
>>>>
>>>> Neat!
>>>>
>>>>> --- a/drivers/net/wireless/ath/ath9k/main.c
>>>>> +++ b/drivers/net/wireless/ath/ath9k/main.c
>>>>> @@ -154,6 +154,27 @@ void ath9k_ps_restore(struct ath_softc *sc)
>>>>> spin_unlock_irqrestore(&sc->sc_pm_lock, flags);
>>>>> }
>>>>> spin_unlock_irqrestore(&sc->sc_pm_lock, flags);
>>>>> }
>>>>>
>>>>> +static void ath_start_ani(struct ath_common *common)
>>>>> +{
>>>>> + struct ath_hw *ah = common->ah;
>>>>> + unsigned long timestamp = jiffies_to_msecs(jiffies);
>>>>> + struct ath_softc *sc = (struct ath_softc *) common->priv;
>>>>> +
>>>>> + if (!(sc->sc_flags & SC_OP_ANI_RUN))
>>>>> + return;
>>>>> +
>>>>> + if (sc->sc_flags & SC_OP_OFFCHANNEL)
>>>>> + return;
>>>>> +
>>>>> + common->ani.longcal_timer = timestamp;
>>>>> + common->ani.shortcal_timer = timestamp;
>>>>> + common->ani.checkani_timer = timestamp;
>>>>> +
>>>>> + mod_timer(&common->ani.timer,
>>>>> + jiffies +
>>>>> + msecs_to_jiffies((u32)ah->config.ani_poll_interval));
>>>>> +}
>>>>
>>>> I would prefer if you do this sort of code shift in a separate patch.
>>>> In this case its pretty easy to see the code is the same so I think
>>>> its fine the way it is now but for next time please. Otherwise looks
>>>> good, thanks!!
>>> If it had been a bigger function, I'd have made a separate patch, but I
>>> figured for something as trivial as this it wouldn't matter.
>>
>> iw event -t while pinging and then issuing a scan:
>>
>> 1280354915.820607: wlan32 (phy #0): scan started
>> 1280354920.390438: wlan32 (phy #0): scan finished: 2412 2417 2422 2427
>> 2432 2437 2442 2447 2452 2457 2462 5180 5200 5220 5240 5260 5280 5300
>> 5320 5500 5520 5540 5560 5580 5660 5680 5700 5745 5765 5785 5805 5825,
>> ""
>> 1280354923.103628: wlan32 (phy #0): deauth FOO -> BAR reason 4:
>> Disassociated due to inactivity
>> 1280354923.103736: wlan32 (phy #0): disconnected (local request)
>> 1280354923.111251: phy #0: regulatory domain change: set to world
>> roaming by the wireless core upon initialization request
>>
>> So this seems to re-introduce the same issue I was seeing before.
>
> Are you sure it's this change?
Just reverted the changes and it works without these issues.
> Can you make a log with debug=0x8?
Sure, one sec let me open that branch up again and recompile again.
> What's the specific symptom here? Does the rx path turn deaf?
Not sure exactly, but what I immediately see is disconnects right after scans.
Luis
^ permalink raw reply
* Re: [PATCH 1/3] ath9k: prevent calibration during off-channel activity
From: Felix Fietkau @ 2010-07-28 22:28 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, linville
In-Reply-To: <AANLkTimqsXoynA2CPJ1tFmj6wUetztDUJ3iKCpQHJKCe@mail.gmail.com>
On 2010-07-29 12:12 AM, Luis R. Rodriguez wrote:
> On Wed, Jul 28, 2010 at 2:08 PM, Felix Fietkau <nbd@openwrt.org> wrote:
>> On 2010-07-28 10:43 PM, Luis R. Rodriguez wrote:
>>> On Wed, Jul 28, 2010 at 10:45 AM, Felix Fietkau <nbd@openwrt.org> wrote:
>>>> Previously the software scan callback was used to indicate to the hardware,
>>>> when it was safe to calibrate. This didn't really work properly, because it
>>>> depends on a specific order of software scan callbacks vs. channel changes.
>>>> Also, software scans are not the only thing that triggers off-channel
>>>> activity, so it's better to use the newly added indication from mac80211 for
>>>> this and not use the software scan callback for anything calibration related.
>>>>
>>>> This fixes at least some of the invalid noise floor readings that I've seen
>>>> in AP mode on AR9160
>>>
>>> Neat!
>>>
>>>> --- a/drivers/net/wireless/ath/ath9k/main.c
>>>> +++ b/drivers/net/wireless/ath/ath9k/main.c
>>>> @@ -154,6 +154,27 @@ void ath9k_ps_restore(struct ath_softc *sc)
>>>> spin_unlock_irqrestore(&sc->sc_pm_lock, flags);
>>>> }
>>>> spin_unlock_irqrestore(&sc->sc_pm_lock, flags);
>>>> }
>>>>
>>>> +static void ath_start_ani(struct ath_common *common)
>>>> +{
>>>> + struct ath_hw *ah = common->ah;
>>>> + unsigned long timestamp = jiffies_to_msecs(jiffies);
>>>> + struct ath_softc *sc = (struct ath_softc *) common->priv;
>>>> +
>>>> + if (!(sc->sc_flags & SC_OP_ANI_RUN))
>>>> + return;
>>>> +
>>>> + if (sc->sc_flags & SC_OP_OFFCHANNEL)
>>>> + return;
>>>> +
>>>> + common->ani.longcal_timer = timestamp;
>>>> + common->ani.shortcal_timer = timestamp;
>>>> + common->ani.checkani_timer = timestamp;
>>>> +
>>>> + mod_timer(&common->ani.timer,
>>>> + jiffies +
>>>> + msecs_to_jiffies((u32)ah->config.ani_poll_interval));
>>>> +}
>>>
>>> I would prefer if you do this sort of code shift in a separate patch.
>>> In this case its pretty easy to see the code is the same so I think
>>> its fine the way it is now but for next time please. Otherwise looks
>>> good, thanks!!
>> If it had been a bigger function, I'd have made a separate patch, but I
>> figured for something as trivial as this it wouldn't matter.
>
> iw event -t while pinging and then issuing a scan:
>
> 1280354915.820607: wlan32 (phy #0): scan started
> 1280354920.390438: wlan32 (phy #0): scan finished: 2412 2417 2422 2427
> 2432 2437 2442 2447 2452 2457 2462 5180 5200 5220 5240 5260 5280 5300
> 5320 5500 5520 5540 5560 5580 5660 5680 5700 5745 5765 5785 5805 5825,
> ""
> 1280354923.103628: wlan32 (phy #0): deauth FOO -> BAR reason 4:
> Disassociated due to inactivity
> 1280354923.103736: wlan32 (phy #0): disconnected (local request)
> 1280354923.111251: phy #0: regulatory domain change: set to world
> roaming by the wireless core upon initialization request
>
> So this seems to re-introduce the same issue I was seeing before.
Are you sure it's this change? Can you make a log with debug=0x8?
What's the specific symptom here? Does the rx path turn deaf?
- Felix
^ permalink raw reply
* Re: [PATCH v4 1/3] cfg80211: Add nl80211 antenna configuration
From: Luis R. Rodriguez @ 2010-07-28 22:14 UTC (permalink / raw)
To: Felix Fietkau
Cc: Bruno Randolf, johannes@sipsolutions.net, linville@tuxdriver.com,
linux-wireless@vger.kernel.org
In-Reply-To: <4C50A9B9.5070708@openwrt.org>
On Wed, Jul 28, 2010 at 3:05 PM, Felix Fietkau <nbd@openwrt.org> wrote:
> On 2010-07-28 11:39 PM, Luis R. Rodriguez wrote:
>> On Wed, Jul 28, 2010 at 02:26:35PM -0700, Felix Fietkau wrote:
>>> We don't need any special case handling for this at all. Drivers already
>>> calculate their HT capabilities based on the number of available chains.
>>> Once the antenna selection stuff is actually used, they will have some
>>> internal information about which chains have how many antennas.
>>>
>>> The reason why we can ignore *all* of this stuff for the API is simple:
>>> We only need to refactor the code to calculate these settings based on
>>> effective chainmask / antenna mask instead of pure hardware capability.
>>>
>>> The effective chainmask / antenna mask is basically the same as the
>>> hardware settings, except that it gets masked with the values that are
>>> configured through this API. That leaves us with something that's easy
>>> to configure, easy to implement for drivers, and doesn't need special
>>> case stuff for various 802.11n features.
>>
>> Consider the case of an already associated STA in 3x3 mode, and someone
>> uses this API to limit it to a 1 stream 1x1 chaimask setting using
>> only one antenna. How would the AP find out about this RX setting
>> from the STA? Are we going to deny mucking with this prior to association?
>> What about if you're the AP?
>>
>> If you are using STBC and the user tunes the device to 1 stream 1x1 chainmask
>> settings, who deals with the required adaptations?
> I think we should simply not accept runtime modifications of this stuff.
> The user should bring down the interface, change the value, then bring
> it back up again. That allows the driver to recalculate all the HT stuff
> based on the updated chainmask/antenna mask without special cases.
Sound good, so based on the passed info, will cfg80211 lift off STBC
capability settings if 1 stream 1x1 settings are used?
Luis
^ permalink raw reply
* Re: [PATCH 1/3] ath9k: prevent calibration during off-channel activity
From: Luis R. Rodriguez @ 2010-07-28 22:12 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, linville
In-Reply-To: <4C509C65.4020305@openwrt.org>
On Wed, Jul 28, 2010 at 2:08 PM, Felix Fietkau <nbd@openwrt.org> wrote:
> On 2010-07-28 10:43 PM, Luis R. Rodriguez wrote:
>> On Wed, Jul 28, 2010 at 10:45 AM, Felix Fietkau <nbd@openwrt.org> wrote:
>>> Previously the software scan callback was used to indicate to the hardware,
>>> when it was safe to calibrate. This didn't really work properly, because it
>>> depends on a specific order of software scan callbacks vs. channel changes.
>>> Also, software scans are not the only thing that triggers off-channel
>>> activity, so it's better to use the newly added indication from mac80211 for
>>> this and not use the software scan callback for anything calibration related.
>>>
>>> This fixes at least some of the invalid noise floor readings that I've seen
>>> in AP mode on AR9160
>>
>> Neat!
>>
>>> --- a/drivers/net/wireless/ath/ath9k/main.c
>>> +++ b/drivers/net/wireless/ath/ath9k/main.c
>>> @@ -154,6 +154,27 @@ void ath9k_ps_restore(struct ath_softc *sc)
>>> spin_unlock_irqrestore(&sc->sc_pm_lock, flags);
>>> }
>>> spin_unlock_irqrestore(&sc->sc_pm_lock, flags);
>>> }
>>>
>>> +static void ath_start_ani(struct ath_common *common)
>>> +{
>>> + struct ath_hw *ah = common->ah;
>>> + unsigned long timestamp = jiffies_to_msecs(jiffies);
>>> + struct ath_softc *sc = (struct ath_softc *) common->priv;
>>> +
>>> + if (!(sc->sc_flags & SC_OP_ANI_RUN))
>>> + return;
>>> +
>>> + if (sc->sc_flags & SC_OP_OFFCHANNEL)
>>> + return;
>>> +
>>> + common->ani.longcal_timer = timestamp;
>>> + common->ani.shortcal_timer = timestamp;
>>> + common->ani.checkani_timer = timestamp;
>>> +
>>> + mod_timer(&common->ani.timer,
>>> + jiffies +
>>> + msecs_to_jiffies((u32)ah->config.ani_poll_interval));
>>> +}
>>
>> I would prefer if you do this sort of code shift in a separate patch.
>> In this case its pretty easy to see the code is the same so I think
>> its fine the way it is now but for next time please. Otherwise looks
>> good, thanks!!
> If it had been a bigger function, I'd have made a separate patch, but I
> figured for something as trivial as this it wouldn't matter.
iw event -t while pinging and then issuing a scan:
1280354915.820607: wlan32 (phy #0): scan started
1280354920.390438: wlan32 (phy #0): scan finished: 2412 2417 2422 2427
2432 2437 2442 2447 2452 2457 2462 5180 5200 5220 5240 5260 5280 5300
5320 5500 5520 5540 5560 5580 5660 5680 5700 5745 5765 5785 5805 5825,
""
1280354923.103628: wlan32 (phy #0): deauth FOO -> BAR reason 4:
Disassociated due to inactivity
1280354923.103736: wlan32 (phy #0): disconnected (local request)
1280354923.111251: phy #0: regulatory domain change: set to world
roaming by the wireless core upon initialization request
So this seems to re-introduce the same issue I was seeing before.
Luis
^ permalink raw reply
* Re: [PATCH v4 1/3] cfg80211: Add nl80211 antenna configuration
From: Felix Fietkau @ 2010-07-28 22:05 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Bruno Randolf, johannes@sipsolutions.net, linville@tuxdriver.com,
linux-wireless@vger.kernel.org
In-Reply-To: <20100728213939.GB8033@tux>
On 2010-07-28 11:39 PM, Luis R. Rodriguez wrote:
> On Wed, Jul 28, 2010 at 02:26:35PM -0700, Felix Fietkau wrote:
>> We don't need any special case handling for this at all. Drivers already
>> calculate their HT capabilities based on the number of available chains.
>> Once the antenna selection stuff is actually used, they will have some
>> internal information about which chains have how many antennas.
>>
>> The reason why we can ignore *all* of this stuff for the API is simple:
>> We only need to refactor the code to calculate these settings based on
>> effective chainmask / antenna mask instead of pure hardware capability.
>>
>> The effective chainmask / antenna mask is basically the same as the
>> hardware settings, except that it gets masked with the values that are
>> configured through this API. That leaves us with something that's easy
>> to configure, easy to implement for drivers, and doesn't need special
>> case stuff for various 802.11n features.
>
> Consider the case of an already associated STA in 3x3 mode, and someone
> uses this API to limit it to a 1 stream 1x1 chaimask setting using
> only one antenna. How would the AP find out about this RX setting
> from the STA? Are we going to deny mucking with this prior to association?
> What about if you're the AP?
>
> If you are using STBC and the user tunes the device to 1 stream 1x1 chainmask
> settings, who deals with the required adaptations?
I think we should simply not accept runtime modifications of this stuff.
The user should bring down the interface, change the value, then bring
it back up again. That allows the driver to recalculate all the HT stuff
based on the updated chainmask/antenna mask without special cases.
- Felix
^ permalink raw reply
* Re: [PATCH 2/3] ath9k_hw: clean up per-channel calibration data
From: Felix Fietkau @ 2010-07-28 22:03 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Luis Rodriguez, linux-wireless@vger.kernel.org,
linville@tuxdriver.com, Jouni Malinen
In-Reply-To: <20100728214041.GC8033@tux>
On 2010-07-28 11:40 PM, Luis R. Rodriguez wrote:
> On Wed, Jul 28, 2010 at 02:30:24PM -0700, Felix Fietkau wrote:
>> My current patch should work just fine with virtual wiphy's, since I
>> store the calibration data in the ath_wiphy struct.
>
> Ah neat, this approach seems fine in the long run then. My only remaining
> questions is how effective our scans are in a noisy environemnt with what
> I suppose are some default settings?
Scans in noisy environments should be fine. The hardware reset kicks off
an initial NF calibration that lets the baseband use the result
immediately and unfiltered by software. That is much more appropriate
than a calibration history of a channel that is almost never used.
- Felix
^ permalink raw reply
* Re: [PATCH 2/3] ath9k_hw: clean up per-channel calibration data
From: Luis R. Rodriguez @ 2010-07-28 21:40 UTC (permalink / raw)
To: Felix Fietkau
Cc: Luis Rodriguez, linux-wireless@vger.kernel.org,
linville@tuxdriver.com, Jouni Malinen
In-Reply-To: <4C50A170.1070902@openwrt.org>
On Wed, Jul 28, 2010 at 02:30:24PM -0700, Felix Fietkau wrote:
> On 2010-07-28 11:21 PM, Luis R. Rodriguez wrote:
> > On Wed, Jul 28, 2010 at 2:10 PM, Felix Fietkau <nbd@openwrt.org> wrote:
> >> On 2010-07-28 10:52 PM, Luis R. Rodriguez wrote:
> >>> On Wed, Jul 28, 2010 at 10:45 AM, Felix Fietkau <nbd@openwrt.org> wrote:
> >>>> The noise floor history buffer is currently not kept per channel, which
> >>>> can lead to problems when changing channels from a clean channel to a
> >>>> noisy one. Also when switching from HT20 to HT40, the noise floor
> >>>> history buffer is full of measurements, but none of them contain data
> >>>> for the extension channel, which it needs quite a bit of time to recover
> >>>> from.
> >>>>
> >>>> This patch puts all the per-channel calibration data into a single data
> >>>> structure, and gives the the driver control over whether that is used
> >>>> per-channel or even not used for some channels.
> >>>>
> >>>> For ath9k_htc, I decided to keep this per-channel in order to avoid
> >>>> creating regressions.
> >>>>
> >>>> For ath9k, the data is kept only for the operating channel, which saves
> >>>> some space. ath9k_hw takes care of wiping old data when the operating
> >>>> channel or its channel flags change.
> >>>>
> >>>> Signed-off-by: Felix Fietkau <nbd@openwrt.org>
> >>>
> >>> But this also means every time we want to get operational on a channel
> >>> we have to learn the current noise all over again. This means for WiFi
> >>> Direct every channel swap we'd have to learn to walk, which happens
> >>> quite often. What do you think? Sorry, I know we discussed this
> >>> approach and I seemed fine but this just occurred to me now, and will
> >>> become really important later when we support WiFi Direct.
> >> When we get to implementing per-vif channel settings with switching
> >> being done in mac80211, we can just move the calibration data to ath9k's
> >> virtual interface data and thus keep the calibration for multiple
> >> operating channels.
> >
> > Sounds good. This would currently break the ath9k virtual wiphy's
> > calibration stuff :P (not like I care), Jouni?
>
> My current patch should work just fine with virtual wiphy's, since I
> store the calibration data in the ath_wiphy struct.
Ah neat, this approach seems fine in the long run then. My only remaining
questions is how effective our scans are in a noisy environemnt with what
I suppose are some default settings?
Luis
^ permalink raw reply
* Re: [PATCH v4 1/3] cfg80211: Add nl80211 antenna configuration
From: Luis R. Rodriguez @ 2010-07-28 21:39 UTC (permalink / raw)
To: Felix Fietkau
Cc: Luis Rodriguez, Bruno Randolf, johannes@sipsolutions.net,
linville@tuxdriver.com, linux-wireless@vger.kernel.org
In-Reply-To: <4C50A08B.2080002@openwrt.org>
On Wed, Jul 28, 2010 at 02:26:35PM -0700, Felix Fietkau wrote:
> On 2010-07-28 11:15 PM, Luis R. Rodriguez wrote:
> > On Wed, Jul 28, 2010 at 10:50 AM, Felix Fietkau <nbd@openwrt.org> wrote:
> >> For AR9285 we will already deviate from treating this as a chainmask,
> >> because it has one chain with rx diversity.
> >
> > Good point but the single stream 802.11n case just needs to be
> > documented as well, it'll be like that for other single stream 802.11n
> > devices, if there are others, not sure if Atheros has the only ones in
> > the market or what.
> >
> >> Please accept this API
> >
> > If you really need some knobs without detailed review and discussion
> > shoot for debugfs, otherwise I will take my time reviewing carefully
> > all the details because once its API then.. well its set in stone and
> > we have to deal with it. I realize I'm being a real big fucking pain
> > in the ass with this but.. I believe these discussions have also been
> > helpful.
> >
> >> I'm sure the API can be used to handle everything related to 802.11n
> >> antenna/chain selection properly. :)
> >
> > Sure, but who deals with the 11n stuff? Right now this patches just
> > pass two variables, TX and RX antenna mask, and has no special case
> > handling for the different 802.11n cases, nor does it document who
> > should handle that.
> >
> > * STBC (11n 9.6.0.c, 9.7g, etc)
> > * TX Beamforming (11n 19.19)
> > * Antenna selection (11n 19.20)
> >
> > IMHO we should be thinking about this if we want to define an API that
> > *all* 802.11 drivers can use if the API will be used for 802.11n as
> > well.
>
> We don't need any special case handling for this at all. Drivers already
> calculate their HT capabilities based on the number of available chains.
> Once the antenna selection stuff is actually used, they will have some
> internal information about which chains have how many antennas.
>
> The reason why we can ignore *all* of this stuff for the API is simple:
> We only need to refactor the code to calculate these settings based on
> effective chainmask / antenna mask instead of pure hardware capability.
>
> The effective chainmask / antenna mask is basically the same as the
> hardware settings, except that it gets masked with the values that are
> configured through this API. That leaves us with something that's easy
> to configure, easy to implement for drivers, and doesn't need special
> case stuff for various 802.11n features.
Consider the case of an already associated STA in 3x3 mode, and someone
uses this API to limit it to a 1 stream 1x1 chaimask setting using
only one antenna. How would the AP find out about this RX setting
from the STA? Are we going to deny mucking with this prior to association?
What about if you're the AP?
If you are using STBC and the user tunes the device to 1 stream 1x1 chainmask
settings, who deals with the required adaptations?
Luis
^ permalink raw reply
* Re: [PATCH 2/3] ath9k_hw: clean up per-channel calibration data
From: Felix Fietkau @ 2010-07-28 21:30 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, linville, Jouni Malinen
In-Reply-To: <AANLkTi==nB+Wqe3KcmDf6P=JUYnLzc2PeAuOZQE3v9bn@mail.gmail.com>
On 2010-07-28 11:21 PM, Luis R. Rodriguez wrote:
> On Wed, Jul 28, 2010 at 2:10 PM, Felix Fietkau <nbd@openwrt.org> wrote:
>> On 2010-07-28 10:52 PM, Luis R. Rodriguez wrote:
>>> On Wed, Jul 28, 2010 at 10:45 AM, Felix Fietkau <nbd@openwrt.org> wrote:
>>>> The noise floor history buffer is currently not kept per channel, which
>>>> can lead to problems when changing channels from a clean channel to a
>>>> noisy one. Also when switching from HT20 to HT40, the noise floor
>>>> history buffer is full of measurements, but none of them contain data
>>>> for the extension channel, which it needs quite a bit of time to recover
>>>> from.
>>>>
>>>> This patch puts all the per-channel calibration data into a single data
>>>> structure, and gives the the driver control over whether that is used
>>>> per-channel or even not used for some channels.
>>>>
>>>> For ath9k_htc, I decided to keep this per-channel in order to avoid
>>>> creating regressions.
>>>>
>>>> For ath9k, the data is kept only for the operating channel, which saves
>>>> some space. ath9k_hw takes care of wiping old data when the operating
>>>> channel or its channel flags change.
>>>>
>>>> Signed-off-by: Felix Fietkau <nbd@openwrt.org>
>>>
>>> But this also means every time we want to get operational on a channel
>>> we have to learn the current noise all over again. This means for WiFi
>>> Direct every channel swap we'd have to learn to walk, which happens
>>> quite often. What do you think? Sorry, I know we discussed this
>>> approach and I seemed fine but this just occurred to me now, and will
>>> become really important later when we support WiFi Direct.
>> When we get to implementing per-vif channel settings with switching
>> being done in mac80211, we can just move the calibration data to ath9k's
>> virtual interface data and thus keep the calibration for multiple
>> operating channels.
>
> Sounds good. This would currently break the ath9k virtual wiphy's
> calibration stuff :P (not like I care), Jouni?
My current patch should work just fine with virtual wiphy's, since I
store the calibration data in the ath_wiphy struct.
- Felix
^ permalink raw reply
* [PATCH v2] ar9170: add get_survey callback in order to get channel noise
From: John W. Linville @ 2010-07-28 21:20 UTC (permalink / raw)
To: linux-wireless; +Cc: Christian Lamparter, John W. Linville
In-Reply-To: <1280349040-25102-1-git-send-email-linville@tuxdriver.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Acked-by: Christian Lamparter <chunkeey@googlemail.com>
---
v2 -> add TODO comment
drivers/net/wireless/ath/ar9170/main.c | 19 +++++++++++++++++++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ar9170/main.c b/drivers/net/wireless/ath/ar9170/main.c
index 5e2c514..c67b05f 100644
--- a/drivers/net/wireless/ath/ar9170/main.c
+++ b/drivers/net/wireless/ath/ar9170/main.c
@@ -1905,6 +1905,24 @@ static int ar9170_get_stats(struct ieee80211_hw *hw,
return 0;
}
+static int ar9170_get_survey(struct ieee80211_hw *hw, int idx,
+ struct survey_info *survey)
+{
+ struct ar9170 *ar = hw->priv;
+ struct ieee80211_conf *conf = &hw->conf;
+
+ if (idx != 0)
+ return -ENOENT;
+
+ /* TODO: update noise value, e.g. call ar9170_set_channel */
+
+ survey->channel = conf->channel;
+ survey->filled = SURVEY_INFO_NOISE_DBM;
+ survey->noise = ar->noise[0];
+
+ return 0;
+}
+
static int ar9170_conf_tx(struct ieee80211_hw *hw, u16 queue,
const struct ieee80211_tx_queue_params *param)
{
@@ -1957,6 +1975,7 @@ static const struct ieee80211_ops ar9170_ops = {
.get_tsf = ar9170_op_get_tsf,
.set_key = ar9170_set_key,
.get_stats = ar9170_get_stats,
+ .get_survey = ar9170_get_survey,
.ampdu_action = ar9170_ampdu_action,
};
--
1.7.1.1
^ permalink raw reply related
* Re: [PATCH v4 1/3] cfg80211: Add nl80211 antenna configuration
From: Felix Fietkau @ 2010-07-28 21:26 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Bruno Randolf, johannes, linville, linux-wireless
In-Reply-To: <AANLkTi=HyyA0oqVRRsh2_ad_0zLGCSBQ6CK=fCg=g=ad@mail.gmail.com>
On 2010-07-28 11:15 PM, Luis R. Rodriguez wrote:
> On Wed, Jul 28, 2010 at 10:50 AM, Felix Fietkau <nbd@openwrt.org> wrote:
>> This is easy to handle, it can work like this:
>> We treat the setting not as a raw chainmask, but actually as an antenna
>> mask. The chainmask gets calculated from that. If we disable all
>> antennas belonging to a particular chain, we disable the entire chain.
>
> Fair enough. Would cfg80211 deal with this logic then? That would be
> my preference. But then, do we even expose enough hardware
> capabilities for cfg80211 to make this decision already?
There isn't much for cfg80211 to deal with, really.
>> For AR9285 we will already deviate from treating this as a chainmask,
>> because it has one chain with rx diversity.
>
> Good point but the single stream 802.11n case just needs to be
> documented as well, it'll be like that for other single stream 802.11n
> devices, if there are others, not sure if Atheros has the only ones in
> the market or what.
>
>> Please accept this API
>
> If you really need some knobs without detailed review and discussion
> shoot for debugfs, otherwise I will take my time reviewing carefully
> all the details because once its API then.. well its set in stone and
> we have to deal with it. I realize I'm being a real big fucking pain
> in the ass with this but.. I believe these discussions have also been
> helpful.
>
>> I'm sure the API can be used to handle everything related to 802.11n
>> antenna/chain selection properly. :)
>
> Sure, but who deals with the 11n stuff? Right now this patches just
> pass two variables, TX and RX antenna mask, and has no special case
> handling for the different 802.11n cases, nor does it document who
> should handle that.
>
> * STBC (11n 9.6.0.c, 9.7g, etc)
> * TX Beamforming (11n 19.19)
> * Antenna selection (11n 19.20)
>
> IMHO we should be thinking about this if we want to define an API that
> *all* 802.11 drivers can use if the API will be used for 802.11n as
> well.
We don't need any special case handling for this at all. Drivers already
calculate their HT capabilities based on the number of available chains.
Once the antenna selection stuff is actually used, they will have some
internal information about which chains have how many antennas.
The reason why we can ignore *all* of this stuff for the API is simple:
We only need to refactor the code to calculate these settings based on
effective chainmask / antenna mask instead of pure hardware capability.
The effective chainmask / antenna mask is basically the same as the
hardware settings, except that it gets masked with the values that are
configured through this API. That leaves us with something that's easy
to configure, easy to implement for drivers, and doesn't need special
case stuff for various 802.11n features.
- Felix
^ permalink raw reply
* Re: [PATCH 2/3] ath9k_hw: clean up per-channel calibration data
From: Luis R. Rodriguez @ 2010-07-28 21:21 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, linville, Jouni Malinen
In-Reply-To: <4C509CE1.90503@openwrt.org>
On Wed, Jul 28, 2010 at 2:10 PM, Felix Fietkau <nbd@openwrt.org> wrote:
> On 2010-07-28 10:52 PM, Luis R. Rodriguez wrote:
>> On Wed, Jul 28, 2010 at 10:45 AM, Felix Fietkau <nbd@openwrt.org> wrote:
>>> The noise floor history buffer is currently not kept per channel, which
>>> can lead to problems when changing channels from a clean channel to a
>>> noisy one. Also when switching from HT20 to HT40, the noise floor
>>> history buffer is full of measurements, but none of them contain data
>>> for the extension channel, which it needs quite a bit of time to recover
>>> from.
>>>
>>> This patch puts all the per-channel calibration data into a single data
>>> structure, and gives the the driver control over whether that is used
>>> per-channel or even not used for some channels.
>>>
>>> For ath9k_htc, I decided to keep this per-channel in order to avoid
>>> creating regressions.
>>>
>>> For ath9k, the data is kept only for the operating channel, which saves
>>> some space. ath9k_hw takes care of wiping old data when the operating
>>> channel or its channel flags change.
>>>
>>> Signed-off-by: Felix Fietkau <nbd@openwrt.org>
>>
>> But this also means every time we want to get operational on a channel
>> we have to learn the current noise all over again. This means for WiFi
>> Direct every channel swap we'd have to learn to walk, which happens
>> quite often. What do you think? Sorry, I know we discussed this
>> approach and I seemed fine but this just occurred to me now, and will
>> become really important later when we support WiFi Direct.
> When we get to implementing per-vif channel settings with switching
> being done in mac80211, we can just move the calibration data to ath9k's
> virtual interface data and thus keep the calibration for multiple
> operating channels.
Sounds good. This would currently break the ath9k virtual wiphy's
calibration stuff :P (not like I care), Jouni?
Luis
^ permalink raw reply
* Re: [PATCH v4 1/3] cfg80211: Add nl80211 antenna configuration
From: Luis R. Rodriguez @ 2010-07-28 21:15 UTC (permalink / raw)
To: Felix Fietkau; +Cc: Bruno Randolf, johannes, linville, linux-wireless
In-Reply-To: <4C506DF7.9020907@openwrt.org>
On Wed, Jul 28, 2010 at 10:50 AM, Felix Fietkau <nbd@openwrt.org> wrote:
> On 2010-07-28 7:24 PM, Luis R. Rodriguez wrote:
>> On Tue, Jul 27, 2010 at 7:06 PM, Bruno Randolf <br1@einfach.org> wrote:
>>> On Wed July 28 2010 01:47:34 Luis R. Rodriguez wrote:
>>>> On Tue, Jul 27, 2010 at 9:39 AM, Felix Fietkau <nbd@openwrt.org> wrote:
>>>> > On 2010-07-27 6:19 PM, Luis R. Rodriguez wrote:
>>>> >>> + * @NL80211_ATTR_WIPHY_ANTENNA_TX: Bitmap of allowed antennas for
>>>> >>> transmitting. + * Each bit represents one antenna, starting with
>>>> >>> antenna 1 at the first + * bit. If the bitmap is zero (0), the TX
>>>> >>> antenna follows RX diversity.
>>>> >>
>>>> >> What about for 802.11n? What if you want to disable TX?
>>>> >
>>>> > Disabling tx shouldn't be handled by the antenna setting, IMHO.
>>>> >
>>>> >>> + * If multiple antennas are selected all selected antennas have to
>>>> >>> be used + * for transmitting (801.11n multiple TX chains).
>>>> >>
>>>> >> I rather call this TX / RX chainmask then.
>>>> >
>>>> > Well, for legacy hardware, these aren't really chains, as there is only
>>>> > one rx and one tx path, just with switching onto multiple antennas.
>>>> >
>>>> >>> + * Drivers may reject configurations they cannot support.
>>>> >>> + *
>>>> >>> + * @NL80211_ATTR_WIPHY_ANTENNA_RX: Bitmap of allowed antennas for
>>>> >>> receiving. + * Each bit represents one antenna, starting with
>>>> >>> antenna 1 at the first + * bit. If multiple antennas are selected
>>>> >>> in the bitmap, 802.11n devices + * should use multiple RX chains
>>>> >>> on these antennas, while non-802.11n + * drivers should use
>>>> >>> antenna diversity between these antennas.
>>>> >>
>>>> >> What about TX beamforming, and STBC?
>>>> >
>>>> > Disabling one antenna/chain on a two-chain device would naturally
>>>> > disable TxBF and STBC as well, since it limits the number of available
>>>> > chains. The driver should simply act as if the disabled chains didn't
>>>> > exist.
>>>>
>>>> That would work.
>>>>
>>>> >> Unless 802.11n is completely dealt with I really prefer this patch to
>>>> >> only address legacy. Otherwise I see sloppyness and inconsistencies on
>>>> >> supporting this feature throughout different drivers. I'd like to
>>>> >> avoid that at all costs on nl80211. What you are trying to address is
>>>> >> legacy antenna setup, not 802.11n RX/TX chainmask dynamic settings so
>>>> >> I'd really try to avoid it unless you really want to address all
>>>> >> aspects of chain configuration for 802.11n and even then what I'm
>>>> >> leading on to say is I think you'll see if you try to address both it
>>>> >> just gets messy.
>>>> >
>>>> > I think 802.11n is already completely dealt with if you treat this as
>>>> > the chainmask on 11n devices.
>>>>
>>>> Its fine by me if the above cases are also embedded into the
>>>> documentation, just don't want these questions lingering. I can't
>>>> think of other 802.11n special cases.
>>>
>>> thanks felix :)
>>>
>>> luis, could you tell me what exactly you would want to include in the
>>> documentation?
>>
>> Sure, but after some though I'm sticking to my preference for an API
>> for this, legacy and 802.11n chainmask / antenna selection should be
>> dealt with separately.
>
> As I pointed out in an earlier discussion, they *cannot* really be
> treated separately if you're running in AP mode, dealing with both
> legacy and 11n clients.
In AP mode you'd use the 11n mode stuff not the legacy stuff, so not
sure how this matters.
>> Reason is I just reviewed the IEEE 802.11 sections 19.19 for TX
>> beamforming but also happened to stumble upon section 19.20 Antenna
>> selection. This Antenna Selection section indicates you can support
>> more antennas than chains and you can use and that the antenna you use
>> for your chains can vary over time. You select which antenna to use
>> based on training/sounding tests on each antenna. Antenna selection as
>> per 19.19 supports up to 8 antennas and up to 4 RF chains. Section
>> 19.20.2 deals with how a STA can initiate antenna selection training
>> with another STA. Now granted we don't have code for this and I don't
>> think this is all done explicitly in hardware so one can argue we can
>> deal with this when/if we do add support for this but this just
>> highlights how different "antenna selection" or knobs to tune antennas
>> is even from a standard perspective than legacy. For STBC and TX
>> beamforming requirements I would like to see mac80211 actually have
>> code which disables STBC and later TX beamforming (once we have code
>> for it) if we enable only one chain, I don't see why drivers should
>> deal with this.
>
> This is easy to handle, it can work like this:
> We treat the setting not as a raw chainmask, but actually as an antenna
> mask. The chainmask gets calculated from that. If we disable all
> antennas belonging to a particular chain, we disable the entire chain.
Fair enough. Would cfg80211 deal with this logic then? That would be
my preference. But then, do we even expose enough hardware
capabilities for cfg80211 to make this decision already?
> For AR9285 we will already deviate from treating this as a chainmask,
> because it has one chain with rx diversity.
Good point but the single stream 802.11n case just needs to be
documented as well, it'll be like that for other single stream 802.11n
devices, if there are others, not sure if Atheros has the only ones in
the market or what.
> Please accept this API
If you really need some knobs without detailed review and discussion
shoot for debugfs, otherwise I will take my time reviewing carefully
all the details because once its API then.. well its set in stone and
we have to deal with it. I realize I'm being a real big fucking pain
in the ass with this but.. I believe these discussions have also been
helpful.
> I'm sure the API can be used to handle everything related to 802.11n
> antenna/chain selection properly. :)
Sure, but who deals with the 11n stuff? Right now this patches just
pass two variables, TX and RX antenna mask, and has no special case
handling for the different 802.11n cases, nor does it document who
should handle that.
* STBC (11n 9.6.0.c, 9.7g, etc)
* TX Beamforming (11n 19.19)
* Antenna selection (11n 19.20)
IMHO we should be thinking about this if we want to define an API that
*all* 802.11 drivers can use if the API will be used for 802.11n as
well.
Luis
^ permalink raw reply
* [PATCH] wl1251: update hw/fw version info in wiphy struct
From: John W. Linville @ 2010-07-28 21:07 UTC (permalink / raw)
To: linux-wireless; +Cc: Kalle Valo, Juuso Oikarinen, John W. Linville
This makes the information available through ethtool...
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/wl12xx/wl1251_main.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/wl1251_main.c b/drivers/net/wireless/wl12xx/wl1251_main.c
index a6d8d1a..861a5f3 100644
--- a/drivers/net/wireless/wl12xx/wl1251_main.c
+++ b/drivers/net/wireless/wl12xx/wl1251_main.c
@@ -411,6 +411,7 @@ static int wl1251_op_tx(struct ieee80211_hw *hw, struct sk_buff *skb)
static int wl1251_op_start(struct ieee80211_hw *hw)
{
struct wl1251 *wl = hw->priv;
+ struct wiphy *wiphy = hw->wiphy;
int ret = 0;
wl1251_debug(DEBUG_MAC80211, "mac80211 start");
@@ -444,6 +445,10 @@ static int wl1251_op_start(struct ieee80211_hw *hw)
wl1251_info("firmware booted (%s)", wl->fw_ver);
+ /* update hw/fw version info in wiphy struct */
+ wiphy->hw_version = wl->chip_id;
+ strncpy(wiphy->fw_version, wl->fw_ver, sizeof(wiphy->fw_version));
+
out:
if (ret < 0)
wl1251_power_off(wl);
--
1.7.1.1
^ permalink raw reply related
* [PATCH] wl1271: update hw/fw version info in wiphy struct
From: John W. Linville @ 2010-07-28 21:10 UTC (permalink / raw)
To: linux-wireless; +Cc: Luciano Coelho, Juuso Oikarinen, John W. Linville
This makes the information available through ethtool...
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/wl12xx/wl1271_main.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/wl1271_main.c b/drivers/net/wireless/wl12xx/wl1271_main.c
index 374abf0..9d68f00 100644
--- a/drivers/net/wireless/wl12xx/wl1271_main.c
+++ b/drivers/net/wireless/wl12xx/wl1271_main.c
@@ -839,6 +839,7 @@ static int wl1271_op_add_interface(struct ieee80211_hw *hw,
struct ieee80211_vif *vif)
{
struct wl1271 *wl = hw->priv;
+ struct wiphy *wiphy = hw->wiphy;
int retries = WL1271_BOOT_RETRIES;
int ret = 0;
@@ -892,6 +893,12 @@ static int wl1271_op_add_interface(struct ieee80211_hw *hw,
wl->state = WL1271_STATE_ON;
wl1271_info("firmware booted (%s)", wl->chip.fw_ver);
+
+ /* update hw/fw version info in wiphy struct */
+ wiphy->hw_version = wl->chip.id;
+ strncpy(wiphy->fw_version, wl->chip.fw_ver,
+ sizeof(wiphy->fw_version));
+
goto out;
irq_disable:
--
1.7.1.1
^ permalink raw reply related
* Re: [ath5k-devel] [PATCH] ath5k: add led_disable module option
From: Bob Copeland @ 2010-07-28 21:14 UTC (permalink / raw)
To: Johannes Berg
Cc: Luis R. Rodriguez, ath5k-devel, linux-wireless, John W. Linville
In-Reply-To: <1280351044.3732.0.camel@jlt3.sipsolutions.net>
On Wed, Jul 28, 2010 at 5:04 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Wed, 2010-07-28 at 14:01 -0700, Luis R. Rodriguez wrote:
>> On Wed, Jul 28, 2010 at 9:31 AM, John W. Linville
>> <linville@tuxdriver.com> wrote:
>> > Not everyone agrees about LED behaviour...give them an escape hatch that
>> > will at least stop the lights from annoying them.
>> >
>> > Signed-off-by: John W. Linville <linville@tuxdriver.com>
>>
>> I wonder if we can just do this on cfg80211 through a debugfs knob,
>> which would take care of all device drivers?
>
> We have proper API for this in sysfs if anybody bothered to hook this up
> through the LED class/trigger system
Yes, they are hooked up through the triggers, so you can disable
them via sysfs (which I have told several people, but complaints still
roll in...)
I don't have any devices with LEDs so either way I don't care too much.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: [PATCH 2/3] ath9k_hw: clean up per-channel calibration data
From: Felix Fietkau @ 2010-07-28 21:10 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, linville, Jouni Malinen
In-Reply-To: <AANLkTi=8UX5B9+nLymSdJS2J-gRwMsYT_SVnviHX9Zi3@mail.gmail.com>
On 2010-07-28 10:52 PM, Luis R. Rodriguez wrote:
> On Wed, Jul 28, 2010 at 10:45 AM, Felix Fietkau <nbd@openwrt.org> wrote:
>> The noise floor history buffer is currently not kept per channel, which
>> can lead to problems when changing channels from a clean channel to a
>> noisy one. Also when switching from HT20 to HT40, the noise floor
>> history buffer is full of measurements, but none of them contain data
>> for the extension channel, which it needs quite a bit of time to recover
>> from.
>>
>> This patch puts all the per-channel calibration data into a single data
>> structure, and gives the the driver control over whether that is used
>> per-channel or even not used for some channels.
>>
>> For ath9k_htc, I decided to keep this per-channel in order to avoid
>> creating regressions.
>>
>> For ath9k, the data is kept only for the operating channel, which saves
>> some space. ath9k_hw takes care of wiping old data when the operating
>> channel or its channel flags change.
>>
>> Signed-off-by: Felix Fietkau <nbd@openwrt.org>
>
> But this also means every time we want to get operational on a channel
> we have to learn the current noise all over again. This means for WiFi
> Direct every channel swap we'd have to learn to walk, which happens
> quite often. What do you think? Sorry, I know we discussed this
> approach and I seemed fine but this just occurred to me now, and will
> become really important later when we support WiFi Direct.
When we get to implementing per-vif channel settings with switching
being done in mac80211, we can just move the calibration data to ath9k's
virtual interface data and thus keep the calibration for multiple
operating channels.
- Felix
^ permalink raw reply
* Re: [PATCH 1/3] ath9k: prevent calibration during off-channel activity
From: Felix Fietkau @ 2010-07-28 21:08 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, linville
In-Reply-To: <AANLkTimZ8zTZWDcXwr7Hu2FT=gDPeCiiUFXcBmpYpp7M@mail.gmail.com>
On 2010-07-28 10:43 PM, Luis R. Rodriguez wrote:
> On Wed, Jul 28, 2010 at 10:45 AM, Felix Fietkau <nbd@openwrt.org> wrote:
>> Previously the software scan callback was used to indicate to the hardware,
>> when it was safe to calibrate. This didn't really work properly, because it
>> depends on a specific order of software scan callbacks vs. channel changes.
>> Also, software scans are not the only thing that triggers off-channel
>> activity, so it's better to use the newly added indication from mac80211 for
>> this and not use the software scan callback for anything calibration related.
>>
>> This fixes at least some of the invalid noise floor readings that I've seen
>> in AP mode on AR9160
>
> Neat!
>
>> --- a/drivers/net/wireless/ath/ath9k/main.c
>> +++ b/drivers/net/wireless/ath/ath9k/main.c
>> @@ -154,6 +154,27 @@ void ath9k_ps_restore(struct ath_softc *sc)
>> spin_unlock_irqrestore(&sc->sc_pm_lock, flags);
>> }
>> spin_unlock_irqrestore(&sc->sc_pm_lock, flags);
>> }
>>
>> +static void ath_start_ani(struct ath_common *common)
>> +{
>> + struct ath_hw *ah = common->ah;
>> + unsigned long timestamp = jiffies_to_msecs(jiffies);
>> + struct ath_softc *sc = (struct ath_softc *) common->priv;
>> +
>> + if (!(sc->sc_flags & SC_OP_ANI_RUN))
>> + return;
>> +
>> + if (sc->sc_flags & SC_OP_OFFCHANNEL)
>> + return;
>> +
>> + common->ani.longcal_timer = timestamp;
>> + common->ani.shortcal_timer = timestamp;
>> + common->ani.checkani_timer = timestamp;
>> +
>> + mod_timer(&common->ani.timer,
>> + jiffies +
>> + msecs_to_jiffies((u32)ah->config.ani_poll_interval));
>> +}
>
> I would prefer if you do this sort of code shift in a separate patch.
> In this case its pretty easy to see the code is the same so I think
> its fine the way it is now but for next time please. Otherwise looks
> good, thanks!!
If it had been a bigger function, I'd have made a separate patch, but I
figured for something as trivial as this it wouldn't matter.
- Felix
^ permalink raw reply
* Re: [ath5k-devel] [PATCH] ath5k: add led_disable module option
From: Johannes Berg @ 2010-07-28 21:04 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: John W. Linville, linux-wireless, ath5k-devel
In-Reply-To: <AANLkTim_Yr0Hx58GHYPfiPxRBWjspuFUd64epUHn_4La@mail.gmail.com>
On Wed, 2010-07-28 at 14:01 -0700, Luis R. Rodriguez wrote:
> On Wed, Jul 28, 2010 at 9:31 AM, John W. Linville
> <linville@tuxdriver.com> wrote:
> > Not everyone agrees about LED behaviour...give them an escape hatch that
> > will at least stop the lights from annoying them.
> >
> > Signed-off-by: John W. Linville <linville@tuxdriver.com>
>
> I wonder if we can just do this on cfg80211 through a debugfs knob,
> which would take care of all device drivers?
We have proper API for this in sysfs if anybody bothered to hook this up
through the LED class/trigger system
johannes
^ permalink raw reply
* Re: [ath5k-devel] [PATCH] ath5k: add led_disable module option
From: Luis R. Rodriguez @ 2010-07-28 21:01 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, ath5k-devel
In-Reply-To: <1280334711-6141-1-git-send-email-linville@tuxdriver.com>
On Wed, Jul 28, 2010 at 9:31 AM, John W. Linville
<linville@tuxdriver.com> wrote:
> Not everyone agrees about LED behaviour...give them an escape hatch that
> will at least stop the lights from annoying them.
>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
I wonder if we can just do this on cfg80211 through a debugfs knob,
which would take care of all device drivers?
Luis
^ permalink raw reply
* Re: [PATCH 2/3] ath9k_hw: clean up per-channel calibration data
From: Luis R. Rodriguez @ 2010-07-28 20:52 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, linville, Jouni Malinen
In-Reply-To: <1280339151-37084-2-git-send-email-nbd@openwrt.org>
On Wed, Jul 28, 2010 at 10:45 AM, Felix Fietkau <nbd@openwrt.org> wrote:
> The noise floor history buffer is currently not kept per channel, which
> can lead to problems when changing channels from a clean channel to a
> noisy one. Also when switching from HT20 to HT40, the noise floor
> history buffer is full of measurements, but none of them contain data
> for the extension channel, which it needs quite a bit of time to recover
> from.
>
> This patch puts all the per-channel calibration data into a single data
> structure, and gives the the driver control over whether that is used
> per-channel or even not used for some channels.
>
> For ath9k_htc, I decided to keep this per-channel in order to avoid
> creating regressions.
>
> For ath9k, the data is kept only for the operating channel, which saves
> some space. ath9k_hw takes care of wiping old data when the operating
> channel or its channel flags change.
>
> Signed-off-by: Felix Fietkau <nbd@openwrt.org>
But this also means every time we want to get operational on a channel
we have to learn the current noise all over again. This means for WiFi
Direct every channel swap we'd have to learn to walk, which happens
quite often. What do you think? Sorry, I know we discussed this
approach and I seemed fine but this just occurred to me now, and will
become really important later when we support WiFi Direct.
Luis
^ 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