* Re: [PATCH 2.6.32.y] ath9k: re-enable ps by default for new single chip families
From: Kristoffer Ericson @ 2010-06-16 8:12 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: stable, greg, linux-wireless, Peter Stuge, Justin P. Mattock,
John W. Linville
In-Reply-To: <1276640359-25360-1-git-send-email-lrodriguez@atheros.com>
On Tue, Jun 15, 2010 at 06:19:19PM -0400, Luis R. Rodriguez wrote:
> commit 14acdde6e527950f66c084dbf19bad6fbfcaeedc upstream.
>
> The newer single chip hardware family of chipsets have not been
> experiencing issues with power saving set by default with recent
> fixes merged (even into stable). The remaining issues are only
> reported with AR5416 and since enabling PS by default can increase
> power savings considerably best to take advantage of that feature
> as this has been tested properly.
I havent had any issues lately. But that said Ive moved on to
2.6.33, 2.6.34 which seems to work fine. Believe you set
to disabled by default on those?
/Kristoffer
>
> For more details on this issue see the bug report:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=14267
>
> We leave AR5416 with PS disabled by default, that seems to require
> some more work.
>
> Cc: stable@kernel.org
> Cc: Peter Stuge <peter@stuge.se>
> Cc: Justin P. Mattock <justinmattock@gmail.com>
> Cc: Kristoffer Ericson <kristoffer.ericson@gmail.com>
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
> ---
>
> Greg, this is the long promised backport of the patch titled
> "ath9k: re-enable ps by default for new single chip families" backported
> down to 2.6.32.y. This just goes test compiled. Manual backport
> was required from the upstream Linus patch since the flag
> WIPHY_FLAG_PS_ON_BY_DEFAULT was not used back on 2.6.32 so instead
> we use the equivalent hw->wiphy->ps_default bool.
>
> Apologies for the delay, was just stuck with other stuff.
>
> I'll remove this from the stable pending list for 802.11 [1] once
> this gets sucked in.
>
> [1] http://wireless.kernel.org/en/developers/stable-pending
>
> drivers/net/wireless/ath/ath9k/main.c | 7 ++++++-
> 1 files changed, 6 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
> index 15eb245..dba27b7 100644
> --- a/drivers/net/wireless/ath/ath9k/main.c
> +++ b/drivers/net/wireless/ath/ath9k/main.c
> @@ -1538,6 +1538,8 @@ bad_no_ah:
>
> void ath_set_hw_capab(struct ath_softc *sc, struct ieee80211_hw *hw)
> {
> + struct ath_hw *ah = sc->sc_ah;
> +
> hw->flags = IEEE80211_HW_RX_INCLUDES_FCS |
> IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING |
> IEEE80211_HW_SIGNAL_DBM |
> @@ -1556,7 +1558,10 @@ void ath_set_hw_capab(struct ath_softc *sc, struct ieee80211_hw *hw)
> BIT(NL80211_IFTYPE_ADHOC) |
> BIT(NL80211_IFTYPE_MESH_POINT);
>
> - hw->wiphy->ps_default = false;
> + if (AR_SREV_5416(ah))
> + hw->wiphy->ps_default = false;
> + else
> + hw->wiphy->ps_default = true;
>
> hw->queues = 4;
> hw->max_rates = 4;
> --
> 1.6.3.3
^ permalink raw reply
* Re: [RFC] Changes in mac80211 to make at76c50x-usb working again
From: Sebastian Smolorz @ 2010-06-16 7:46 UTC (permalink / raw)
To: Kalle Valo
Cc: Johannes Berg, John W. Linville, linux-wireless, Marcel Holtmann
In-Reply-To: <AANLkTinHK_MbKZd9HUDoiWuWs5AmDOQiza0poofzYeDn@mail.gmail.com>
Kalle Valo wrote:
> On 15 June 2010 16:36, Johannes Berg <johannes@sipsolutions.net> wrote:
> > On Tue, 2010-06-15 at 09:26 -0400, John W. Linville wrote:
> >> On Tue, Jun 15, 2010 at 02:16:36PM +0200, Sebastian Smolorz wrote:
> >> > the at76c50x-usb driver fails to authenticate with an AP.
> >
> > We need more information on how it fails.
>
> I debugged this a long time ago. The problem is that firmware's
> CMD_JOIN only works if bssid is correct one. I remember trying
> ff:ff:ff:ff:ff:ff, but that didn't work for some reason. The join
> command needs to be sent before association, otherwise transmission
> won't work at all. And if I use a random bssid the firmware will
> filter the replies. But I tested this a long time ago, I might
> remember something wrong.
>
> I was thinking a hack which would get bssid from association frames
> and then send CMD_JOIN, before the association frame.
Could you elaborate a little bit on this?
How do we proceed to make the driver working again? Do you want to work on
this issue?
--
Sebastian
^ permalink raw reply
* Re: [PATCH v3] iw: Configure basic rates when joining ibss network
From: Johannes Berg @ 2010-06-16 7:18 UTC (permalink / raw)
To: Teemu Paasikivi; +Cc: linux-wireless
In-Reply-To: <1276669336-32266-1-git-send-email-ext-teemu.3.paasikivi@nokia.com>
On Wed, 2010-06-16 at 09:22 +0300, Teemu Paasikivi wrote:
> This patch adds option to configure basic rates when joining ibss network.
Applied, thanks.
> Signed-off-by: Teemu Paasikivi <ext-teemu.3.paasikivi@nokia.com>
> ---
> ibss.c | 35 ++++++++++++++++++++++++++++++++++-
> 1 files changed, 34 insertions(+), 1 deletions(-)
>
> diff --git a/ibss.c b/ibss.c
> index 4715ac8..7e3ff89 100644
> --- a/ibss.c
> +++ b/ibss.c
> @@ -18,6 +18,11 @@ static int join_ibss(struct nl80211_state *state,
> {
> char *end;
> unsigned char abssid[6];
> + unsigned char rates[NL80211_MAX_SUPP_RATES];
> + int n_rates = 0;
> + char *value = NULL, *sptr = NULL;
> + float rate;
> +
>
> if (argc < 2)
> return 1;
> @@ -49,6 +54,32 @@ static int join_ibss(struct nl80211_state *state,
> }
> }
>
> + /* basic rates */
> + if (argc > 1 && strcmp(argv[0], "basic-rates") == 0) {
> + argv++;
> + argc--;
> +
> + value = strtok_r(argv[0], ",", &sptr);
> +
> + while (value && n_rates < NL80211_MAX_SUPP_RATES) {
> + rate = strtod(value, &end);
> + rates[n_rates] = rate * 2;
> +
> + /* filter out suspicious values */
> + if (*end != '\0' || !rates[n_rates] ||
> + rate*2 != rates[n_rates])
> + return 1;
> +
> + n_rates++;
> + value = strtok_r(NULL, ",", &sptr);
> + }
> +
> + NLA_PUT(msg, NL80211_ATTR_BSS_BASIC_RATES, n_rates, rates);
> +
> + argv++;
> + argc--;
> + }
> +
> if (!argc)
> return 0;
>
> @@ -73,7 +104,9 @@ static int leave_ibss(struct nl80211_state *state,
> COMMAND(ibss, leave, NULL,
> NL80211_CMD_LEAVE_IBSS, 0, CIB_NETDEV, leave_ibss,
> "Leave the current IBSS cell.");
> -COMMAND(ibss, join, "<SSID> <freq in MHz> [fixed-freq] [<fixed bssid>] [key d:0:abcde]",
> +COMMAND(ibss, join,
> + "<SSID> <freq in MHz> [fixed-freq] [<fixed bssid>] "
> + "[basic-rates <rate in Mbps,rate2,...>] [key d:0:abcde]",
> NL80211_CMD_JOIN_IBSS, 0, CIB_NETDEV, join_ibss,
> "Join the IBSS cell with the given SSID, if it doesn't exist create\n"
> "it on the given frequency. When fixed frequency is requested, don't\n"
^ permalink raw reply
* Re: [PATCH 0/5] Fix set but unused variable warnings
From: Justin P. Mattock @ 2010-06-16 7:01 UTC (permalink / raw)
To: Julian Calaby; +Cc: linux-kernel, linux-wireless, linux-pci, linux-scsi
In-Reply-To: <AANLkTikwKHITQJDaSf9BnHQ9FLiQ-KYlCWNiH438otsV@mail.gmail.com>
On 06/15/2010 10:52 PM, Julian Calaby wrote:
> On Wed, Jun 16, 2010 at 15:33, Justin P. Mattock
> <justinmattock@gmail.com> wrote:
>> Here is another set of patches fixing some warning messages generated
>> when building the kernel when using gcc 4.6.0.
>>
>> This set just focuses in on the variables warnings that are reported
>> to be unused. Keep in mind there are still lots more warning messages
>> that I'm seeing, and will try my hardest to see if I can come up with
>> a fix, but if things become too difficult and so forth then a bug should
>> be filled etc..
>
> Given that patches 3, 4 and 5 seem to be a cases of missing error
> handling, (3 and 4 in particular seem to be breaking things rather
> than fixing them) in my humble opinion, I think this set needs some
> work and discussion.
>
alright..
> Justin, maybe you'd be better off posting the actual error messages
> (split up by subsystem) and letting the lists discuss them, rather
> than posting patches which are obviously wrong. (like the ones I've
> pointed out)
>
yeah I'm a newbie!! alright so just file bugs for all these then.
> I'm sure that everyone here is as committed as you are to eliminating
> compile warnings and errors and, in my opinion, more good will come
> from a healthy discussion of the warnings than maintainers NAKing your
> patches out of hand.
>
> Thanks,
>
NAKing is o.k. but having discussions is better..
Justin P. Mattock
^ permalink raw reply
* Re: [PATCH 3/5]pci:bus.c Fix variable 'retval' set but not used
From: Justin P. Mattock @ 2010-06-16 6:58 UTC (permalink / raw)
To: Junchang Wang; +Cc: linux-kernel, linux-wireless, linux-pci, linux-scsi
In-Reply-To: <20100616060738.GA12461@host-a-229.ustcsz.edu.cn>
On 06/15/2010 11:07 PM, Junchang Wang wrote:
> On Tue, Jun 15, 2010 at 10:33:52PM -0700, Justin P. Mattock wrote:
>> @@ -234,12 +234,10 @@ void pci_bus_add_devices(const struct pci_bus *bus)
>> void pci_enable_bridges(struct pci_bus *bus)
>> {
>> struct pci_dev *dev;
>> - int retval;
>>
>> list_for_each_entry(dev,&bus->devices, bus_list) {
>> if (dev->subordinate) {
>> if (!pci_is_enabled(dev)) {
>> - retval = pci_enable_device(dev);
> Hi Justin,
>
> pci_enable_device initializes device before it's used by a driver.
>
> I think you should add check instead of eliminating pci_enable_device.
>
> For example,
> retval = pci_enable_device(dev);
> if (retval< 0) {
> goto handle_err;
> }
>
> --Junchang
>
>
cool, thanks for the example and info on this. I'll play around with
this to see if I come up with anything.
cheers,
Justin P. Mattock
^ permalink raw reply
* Re: [PATCH 3/5]pci:bus.c Fix variable 'retval' set but not used
From: Justin P. Mattock @ 2010-06-16 6:56 UTC (permalink / raw)
To: Julian Calaby; +Cc: linux-kernel, linux-wireless, linux-pci, linux-scsi
In-Reply-To: <AANLkTik27fbCY0pMJdcbuCaEXr-902WiqiFPkju4Bet0@mail.gmail.com>
On 06/15/2010 10:42 PM, Julian Calaby wrote:
> On Wed, Jun 16, 2010 at 15:33, Justin P. Mattock
> <justinmattock@gmail.com> wrote:
>> The patch below fixes the warning message I am seeing with gcc 4.6.0
>> CC drivers/pci/bus.o
>> drivers/pci/bus.c: In function 'pci_enable_bridges':
>> drivers/pci/bus.c:237:6: warning: variable 'retval' set but not used
>>
>> Signed-off-by: Justin P. Mattock<justinmattock@gmail.com>
>>
>> ---
>> drivers/pci/bus.c | 2 --
>> 1 files changed, 0 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
>> index 628ea20..84bdb48 100644
>> --- a/drivers/pci/bus.c
>> +++ b/drivers/pci/bus.c
>> @@ -234,12 +234,10 @@ void pci_bus_add_devices(const struct pci_bus *bus)
>> void pci_enable_bridges(struct pci_bus *bus)
>> {
>> struct pci_dev *dev;
>> - int retval;
>>
>> list_for_each_entry(dev,&bus->devices, bus_list) {
>> if (dev->subordinate) {
>> if (!pci_is_enabled(dev)) {
>> - retval = pci_enable_device(dev);
>> pci_set_master(dev);
>> }
>> pci_enable_bridges(dev->subordinate);
>
> Er, this appears to be bogus: I'm only guessing, but I'd expect that
> the pci_enable_device() call is actually doing something useful, and
> removing it is going to break *something* - Have you booted a kernel
> with this code enabled and these patches applied?
>
> As for this warning, I think that there is a better solution.
>
> Thanks,
>
alright!!
Justin P. Mattock
^ permalink raw reply
* [PATCH v3] iw: Configure basic rates when joining ibss network
From: Teemu Paasikivi @ 2010-06-16 6:22 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, Teemu Paasikivi
This patch adds option to configure basic rates when joining ibss network.
Signed-off-by: Teemu Paasikivi <ext-teemu.3.paasikivi@nokia.com>
---
ibss.c | 35 ++++++++++++++++++++++++++++++++++-
1 files changed, 34 insertions(+), 1 deletions(-)
diff --git a/ibss.c b/ibss.c
index 4715ac8..7e3ff89 100644
--- a/ibss.c
+++ b/ibss.c
@@ -18,6 +18,11 @@ static int join_ibss(struct nl80211_state *state,
{
char *end;
unsigned char abssid[6];
+ unsigned char rates[NL80211_MAX_SUPP_RATES];
+ int n_rates = 0;
+ char *value = NULL, *sptr = NULL;
+ float rate;
+
if (argc < 2)
return 1;
@@ -49,6 +54,32 @@ static int join_ibss(struct nl80211_state *state,
}
}
+ /* basic rates */
+ if (argc > 1 && strcmp(argv[0], "basic-rates") == 0) {
+ argv++;
+ argc--;
+
+ value = strtok_r(argv[0], ",", &sptr);
+
+ while (value && n_rates < NL80211_MAX_SUPP_RATES) {
+ rate = strtod(value, &end);
+ rates[n_rates] = rate * 2;
+
+ /* filter out suspicious values */
+ if (*end != '\0' || !rates[n_rates] ||
+ rate*2 != rates[n_rates])
+ return 1;
+
+ n_rates++;
+ value = strtok_r(NULL, ",", &sptr);
+ }
+
+ NLA_PUT(msg, NL80211_ATTR_BSS_BASIC_RATES, n_rates, rates);
+
+ argv++;
+ argc--;
+ }
+
if (!argc)
return 0;
@@ -73,7 +104,9 @@ static int leave_ibss(struct nl80211_state *state,
COMMAND(ibss, leave, NULL,
NL80211_CMD_LEAVE_IBSS, 0, CIB_NETDEV, leave_ibss,
"Leave the current IBSS cell.");
-COMMAND(ibss, join, "<SSID> <freq in MHz> [fixed-freq] [<fixed bssid>] [key d:0:abcde]",
+COMMAND(ibss, join,
+ "<SSID> <freq in MHz> [fixed-freq] [<fixed bssid>] "
+ "[basic-rates <rate in Mbps,rate2,...>] [key d:0:abcde]",
NL80211_CMD_JOIN_IBSS, 0, CIB_NETDEV, join_ibss,
"Join the IBSS cell with the given SSID, if it doesn't exist create\n"
"it on the given frequency. When fixed frequency is requested, don't\n"
--
1.5.6.3
^ permalink raw reply related
* Re: [PATCH 3/5]pci:bus.c Fix variable 'retval' set but not used
From: Junchang Wang @ 2010-06-16 6:07 UTC (permalink / raw)
To: Justin P. Mattock; +Cc: linux-kernel, linux-wireless, linux-pci, linux-scsi
In-Reply-To: <1276666434-11227-4-git-send-email-justinmattock@gmail.com>
On Tue, Jun 15, 2010 at 10:33:52PM -0700, Justin P. Mattock wrote:
>@@ -234,12 +234,10 @@ void pci_bus_add_devices(const struct pci_bus *bus)
> void pci_enable_bridges(struct pci_bus *bus)
> {
> struct pci_dev *dev;
>- int retval;
>
> list_for_each_entry(dev, &bus->devices, bus_list) {
> if (dev->subordinate) {
> if (!pci_is_enabled(dev)) {
>- retval = pci_enable_device(dev);
Hi Justin,
pci_enable_device initializes device before it's used by a driver.
I think you should add check instead of eliminating pci_enable_device.
For example,
retval = pci_enable_device(dev);
if (retval < 0) {
goto handle_err;
}
--Junchang
^ permalink raw reply
* [PATCHv2] mac80211: Add interface for driver to temporarily disable dynamic ps
From: Juuso Oikarinen @ 2010-06-16 6:01 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
This mechanism introduced in this patch applies (at least) for hardware
designs using a single shared antenna for both WLAN and BT. In these designs,
the antenna must be toggled between WLAN and BT.
In those hardware, managing WLAN co-existence with Bluetooth requires WLAN
full power save whenever there is Bluetooth activity in order for WLAN to be
able to periodically relinquish the antenna to be used for BT. This is because
BT can only access the shared antenna when WLAN is idle or asleep.
Some hardware, for instance the wl1271, are able to indicate to the host
whenever there is BT traffic. In essence, the hardware will send an indication
to the host whenever there is, for example, SCO traffic or A2DP traffic, and
will send another indication when the traffic is over.
The hardware gets information of Bluetooth traffic via hardware co-existence
control lines - these lines are used to negotiate the shared antenna
ownership. The hardware will give the antenna to BT whenever WLAN is sleeping.
This patch adds the interface to mac80211 to facilitate temporarily disabling
of dynamic power save as per request of the WLAN driver. This interface will
immediately force WLAN to full powersave, hence allowing BT coexistence as
described above.
In these kind of shared antenna desings, when WLAN powersave is fully disabled,
Bluetooth will not work simultaneously with WLAN at all. This patch does not
address that problem. This interface will not change PSM state, so if PSM is
disabled it will remain so. Solving this problem requires knowledge about BT
state, and is best done in user-space.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
---
v2: moved dynamic_ps_user_timeout and disable_dynamic_ps to local
include/net/mac80211.h | 27 +++++++++++++++++++++++++++
net/mac80211/ieee80211_i.h | 3 +++
net/mac80211/mlme.c | 29 ++++++++++++++++++++++++++++-
3 files changed, 58 insertions(+), 1 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index fe1a3a6..2628550 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1271,6 +1271,15 @@ ieee80211_get_alt_retry_rate(const struct ieee80211_hw *hw,
* dynamic PS feature in stack and will just keep %IEEE80211_CONF_PS
* enabled whenever user has enabled powersave.
*
+ * Some hardware need to toggle a single shared antenna between WLAN and
+ * Bluetooth to facilitate co-existence. These types of hardware set
+ * limitations on the use of host controlled dynamic powersave whenever there
+ * is simultaneous WLAN and Bluetooth traffic. For these types of hardware, the
+ * driver may request temporarily going into full power save, in order to
+ * enable toggling the antenna between BT and WLAN. If the driver requests
+ * disabling dynamic powersave, the @dynamic_ps_timeout value will be
+ * temporarily set to zero until the driver re-enables dynamic powersave.
+ *
* Driver informs U-APSD client support by enabling
* %IEEE80211_HW_SUPPORTS_UAPSD flag. The mode is configured through the
* uapsd paramater in conf_tx() operation. Hardware needs to send the QoS
@@ -2447,6 +2456,24 @@ void ieee80211_beacon_loss(struct ieee80211_vif *vif);
void ieee80211_connection_loss(struct ieee80211_vif *vif);
/**
+ * ieee80211_disable_dyn_ps - force mac80211 to temporarily disable dynamic psm
+ *
+ * @vif: &struct ieee80211_vif pointer from the add_interface callback.
+ *
+ * Some hardware require full power save to manage simultaneous BT traffic
+ * on the WLAN frequency. Full PSM is required periodically, whenever there are
+ * burst of BT traffic. The hardware gets information of BT traffic via
+ * hardware co-existence lines, and consequentially requests mac80211 to
+ * (temporarily) enter full psm.
+ * This function will only temporarily disable dynamic PS, not enable PSM if
+ * it was not already enabled.
+ * The driver must make sure to re-enable dynamic PS if the driver has disabled
+ * it.
+ *
+ */
+void ieee80211_disable_dyn_ps(struct ieee80211_vif *vif, bool disable);
+
+/**
* ieee80211_cqm_rssi_notify - inform a configured connection quality monitoring
* rssi threshold triggered
*
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index fb54301..f90c48c 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -856,6 +856,9 @@ struct ieee80211_local {
*/
int dynamic_ps_forced_timeout;
+ int dynamic_ps_user_timeout;
+ bool disable_dynamic_ps;
+
int user_power_level; /* in dBm */
int power_constr_level; /* in dBm */
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 85c3ca3..dd16dad 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -478,6 +478,29 @@ static void ieee80211_handle_pwr_constr(struct ieee80211_sub_if_data *sdata,
}
}
+void ieee80211_disable_dyn_ps(struct ieee80211_vif *vif, bool disable)
+{
+ struct ieee80211_sub_if_data *sdata = vif_to_sdata(vif);
+ struct ieee80211_local *local = sdata->local;
+ struct ieee80211_conf *conf = &local->hw.conf;
+
+ WARN_ON(sdata->vif.type != NL80211_IFTYPE_STATION ||
+ !(local->hw.flags & IEEE80211_HW_SUPPORTS_PS) ||
+ (local->hw.flags & IEEE80211_HW_SUPPORTS_DYNAMIC_PS));
+
+ local->disable_dynamic_ps = disable;
+
+ if (disable) {
+ conf->dynamic_ps_timeout = 0;
+ del_timer_sync(&local->dynamic_ps_timer);
+ ieee80211_queue_work(&local->hw,
+ &local->dynamic_ps_enable_work);
+ } else {
+ conf->dynamic_ps_timeout = local->dynamic_ps_user_timeout;
+ }
+}
+EXPORT_SYMBOL(ieee80211_disable_dyn_ps);
+
/* powersave */
static void ieee80211_enable_ps(struct ieee80211_local *local,
struct ieee80211_sub_if_data *sdata)
@@ -553,6 +576,7 @@ void ieee80211_recalc_ps(struct ieee80211_local *local, s32 latency)
found->u.mgd.associated->beacon_ies &&
!(found->u.mgd.flags & (IEEE80211_STA_BEACON_POLL |
IEEE80211_STA_CONNECTION_POLL))) {
+ struct ieee80211_conf *conf = &local->hw.conf;
s32 beaconint_us;
if (latency < 0)
@@ -575,7 +599,10 @@ void ieee80211_recalc_ps(struct ieee80211_local *local, s32 latency)
else
timeout = 100;
}
- local->hw.conf.dynamic_ps_timeout = timeout;
+ local->dynamic_ps_user_timeout = timeout;
+ if (!local->disable_dynamic_ps)
+ conf->dynamic_ps_timeout =
+ local->dynamic_ps_user_timeout;
if (beaconint_us > latency) {
local->ps_sdata = NULL;
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH 0/5] Fix set but unused variable warnings
From: Julian Calaby @ 2010-06-16 5:52 UTC (permalink / raw)
To: Justin P. Mattock; +Cc: linux-kernel, linux-wireless, linux-pci, linux-scsi
In-Reply-To: <1276666434-11227-1-git-send-email-justinmattock@gmail.com>
On Wed, Jun 16, 2010 at 15:33, Justin P. Mattock
<justinmattock@gmail.com> wrote:
> Here is another set of patches fixing some warning messages generated
> when building the kernel when using gcc 4.6.0.
>
> This set just focuses in on the variables warnings that are reported
> to be unused. Keep in mind there are still lots more warning messages
> that I'm seeing, and will try my hardest to see if I can come up with
> a fix, but if things become too difficult and so forth then a bug should
> be filled etc..
Given that patches 3, 4 and 5 seem to be a cases of missing error
handling, (3 and 4 in particular seem to be breaking things rather
than fixing them) in my humble opinion, I think this set needs some
work and discussion.
Justin, maybe you'd be better off posting the actual error messages
(split up by subsystem) and letting the lists discuss them, rather
than posting patches which are obviously wrong. (like the ones I've
pointed out)
I'm sure that everyone here is as committed as you are to eliminating
compile warnings and errors and, in my opinion, more good will come
from a healthy discussion of the warnings than maintainers NAKing your
patches out of hand.
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
.Plan: http://sites.google.com/site/juliancalaby/
^ permalink raw reply
* Re: [PATCH] ath9k: Modify LED blinking pattern during wifi activity.
From: Vivek Natarajan @ 2010-06-16 5:51 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless
In-Reply-To: <20100615195157.GC2415@tuxdriver.com>
On Wed, Jun 16, 2010 at 1:21 AM, John W. Linville
<linville@tuxdriver.com> wrote:
> On Tue, Jun 15, 2010 at 10:50:17AM +0530, Vivek Natarajan wrote:
>> Some vendors require the LED to be ON always irrespective of any
>> radio activity. Introducing a module parameter to enable this,
>> so that one can choose between always on or led blink during
>> activity.
>>
>> Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
>
> Any particular reason the always-on behaviour is the default?
There is no specific reason for setting it as default. It is only that
some customers preferred the led to be always on instead of blinking.
Thanks
Vivek.
^ permalink raw reply
* Re: [PATCH 3/5]pci:bus.c Fix variable 'retval' set but not used
From: Julian Calaby @ 2010-06-16 5:42 UTC (permalink / raw)
To: Justin P. Mattock; +Cc: linux-kernel, linux-wireless, linux-pci, linux-scsi
In-Reply-To: <1276666434-11227-4-git-send-email-justinmattock@gmail.com>
On Wed, Jun 16, 2010 at 15:33, Justin P. Mattock
<justinmattock@gmail.com> wrote:
> The patch below fixes the warning message I am seeing with gcc 4.6.0
> CC drivers/pci/bus.o
> drivers/pci/bus.c: In function 'pci_enable_bridges':
> drivers/pci/bus.c:237:6: warning: variable 'retval' set but not used
>
> Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
>
> ---
> drivers/pci/bus.c | 2 --
> 1 files changed, 0 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
> index 628ea20..84bdb48 100644
> --- a/drivers/pci/bus.c
> +++ b/drivers/pci/bus.c
> @@ -234,12 +234,10 @@ void pci_bus_add_devices(const struct pci_bus *bus)
> void pci_enable_bridges(struct pci_bus *bus)
> {
> struct pci_dev *dev;
> - int retval;
>
> list_for_each_entry(dev, &bus->devices, bus_list) {
> if (dev->subordinate) {
> if (!pci_is_enabled(dev)) {
> - retval = pci_enable_device(dev);
> pci_set_master(dev);
> }
> pci_enable_bridges(dev->subordinate);
Er, this appears to be bogus: I'm only guessing, but I'd expect that
the pci_enable_device() call is actually doing something useful, and
removing it is going to break *something* - Have you booted a kernel
with this code enabled and these patches applied?
As for this warning, I think that there is a better solution.
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
.Plan: http://sites.google.com/site/juliancalaby/
^ permalink raw reply
* [PATCH 5/5]scsi:hosts.c Fix warning: variable 'rval' set but not used
From: Justin P. Mattock @ 2010-06-16 5:33 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-wireless, linux-pci, linux-scsi, Justin P. Mattock
In-Reply-To: <1276666434-11227-1-git-send-email-justinmattock@gmail.com>
The below patch fixes a warning message generated by gcc 4.6.0
CC drivers/scsi/hosts.o
drivers/scsi/hosts.c: In function 'scsi_host_alloc':
drivers/scsi/hosts.c:328:6: warning: variable 'rval' set but not used
Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
---
drivers/scsi/hosts.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c
index 6660fa9..00fd6a4 100644
--- a/drivers/scsi/hosts.c
+++ b/drivers/scsi/hosts.c
@@ -325,7 +325,6 @@ struct Scsi_Host *scsi_host_alloc(struct scsi_host_template *sht, int privsize)
{
struct Scsi_Host *shost;
gfp_t gfp_mask = GFP_KERNEL;
- int rval;
if (sht->unchecked_isa_dma && privsize)
gfp_mask |= __GFP_DMA;
@@ -420,7 +419,6 @@ struct Scsi_Host *scsi_host_alloc(struct scsi_host_template *sht, int privsize)
shost->ehandler = kthread_run(scsi_error_handler, shost,
"scsi_eh_%d", shost->host_no);
if (IS_ERR(shost->ehandler)) {
- rval = PTR_ERR(shost->ehandler);
goto fail_kfree;
}
--
1.7.1.rc1.21.gf3bd6
^ permalink raw reply related
* [PATCH 4/5]pci:setup_bus.c Fix warning: variable 'retval' set but not used
From: Justin P. Mattock @ 2010-06-16 5:33 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-wireless, linux-pci, linux-scsi, Justin P. Mattock
In-Reply-To: <1276666434-11227-1-git-send-email-justinmattock@gmail.com>
The below patch fixes a warning message when using gcc 4.6.0
CC drivers/pci/setup-bus.o
drivers/pci/setup-bus.c: In function 'pci_assign_unassigned_bridge_resources':
drivers/pci/setup-bus.c:868:6: warning: variable 'retval' set but not used
Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
---
drivers/pci/setup-bus.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 19b1113..215590b 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -865,7 +865,6 @@ void pci_assign_unassigned_bridge_resources(struct pci_dev *bridge)
struct pci_bus *parent = bridge->subordinate;
int tried_times = 0;
struct resource_list_x head, *list;
- int retval;
unsigned long type_mask = IORESOURCE_IO | IORESOURCE_MEM |
IORESOURCE_PREFETCH;
@@ -874,7 +873,6 @@ void pci_assign_unassigned_bridge_resources(struct pci_dev *bridge)
again:
pci_bus_size_bridges(parent);
__pci_bridge_assign_resources(bridge, &head);
- retval = pci_reenable_device(bridge);
pci_set_master(bridge);
pci_enable_bridges(parent);
--
1.7.1.rc1.21.gf3bd6
^ permalink raw reply related
* [PATCH 3/5]pci:bus.c Fix variable 'retval' set but not used
From: Justin P. Mattock @ 2010-06-16 5:33 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-wireless, linux-pci, linux-scsi, Justin P. Mattock
In-Reply-To: <1276666434-11227-1-git-send-email-justinmattock@gmail.com>
The patch below fixes the warning message I am seeing with gcc 4.6.0
CC drivers/pci/bus.o
drivers/pci/bus.c: In function 'pci_enable_bridges':
drivers/pci/bus.c:237:6: warning: variable 'retval' set but not used
Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
---
drivers/pci/bus.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
index 628ea20..84bdb48 100644
--- a/drivers/pci/bus.c
+++ b/drivers/pci/bus.c
@@ -234,12 +234,10 @@ void pci_bus_add_devices(const struct pci_bus *bus)
void pci_enable_bridges(struct pci_bus *bus)
{
struct pci_dev *dev;
- int retval;
list_for_each_entry(dev, &bus->devices, bus_list) {
if (dev->subordinate) {
if (!pci_is_enabled(dev)) {
- retval = pci_enable_device(dev);
pci_set_master(dev);
}
pci_enable_bridges(dev->subordinate);
--
1.7.1.rc1.21.gf3bd6
^ permalink raw reply related
* [PATCH 2/5]wireless:hostap_ap.c Fix warning: variable 'fc' set but not used
From: Justin P. Mattock @ 2010-06-16 5:33 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-wireless, linux-pci, linux-scsi, Justin P. Mattock
In-Reply-To: <1276666434-11227-1-git-send-email-justinmattock@gmail.com>
The below patch fixes a warning message when compiling with gcc 4.6.0
CC [M] drivers/net/wireless/hostap/hostap_ap.o
drivers/net/wireless/hostap/hostap_ap.c: In function 'hostap_ap_tx_cb_assoc':
drivers/net/wireless/hostap/hostap_ap.c:691:6: warning: variable 'fc' set but not used
Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
---
drivers/net/wireless/hostap/hostap_ap.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/hostap/hostap_ap.c b/drivers/net/wireless/hostap/hostap_ap.c
index 231dbd7..9cadaa2 100644
--- a/drivers/net/wireless/hostap/hostap_ap.c
+++ b/drivers/net/wireless/hostap/hostap_ap.c
@@ -688,7 +688,7 @@ static void hostap_ap_tx_cb_assoc(struct sk_buff *skb, int ok, void *data)
struct ap_data *ap = data;
struct net_device *dev = ap->local->dev;
struct ieee80211_hdr *hdr;
- u16 fc, status;
+ u16 status;
__le16 *pos;
struct sta_info *sta = NULL;
char *txt = NULL;
@@ -699,7 +699,6 @@ static void hostap_ap_tx_cb_assoc(struct sk_buff *skb, int ok, void *data)
}
hdr = (struct ieee80211_hdr *) skb->data;
- fc = le16_to_cpu(hdr->frame_control);
if ((!ieee80211_is_assoc_resp(hdr->frame_control) &&
!ieee80211_is_reassoc_resp(hdr->frame_control)) ||
skb->len < IEEE80211_MGMT_HDR_LEN + 4) {
--
1.7.1.rc1.21.gf3bd6
^ permalink raw reply related
* [PATCH 1/5]wireless:hostap_main.c warning: variable 'iface' set but not used
From: Justin P. Mattock @ 2010-06-16 5:33 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-wireless, linux-pci, linux-scsi, Justin P. Mattock
In-Reply-To: <1276666434-11227-1-git-send-email-justinmattock@gmail.com>
The patch below fixes a warning message Im seeing with gcc 4.6.0
CC [M] drivers/net/wireless/hostap/hostap_main.o
drivers/net/wireless/hostap/hostap_main.c: In function 'hostap_set_multicast_list_queue':
drivers/net/wireless/hostap/hostap_main.c:744:27: warning: variable 'iface' set but not used
Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
---
drivers/net/wireless/hostap/hostap_main.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/hostap/hostap_main.c b/drivers/net/wireless/hostap/hostap_main.c
index eb57d1e..eaee84b 100644
--- a/drivers/net/wireless/hostap/hostap_main.c
+++ b/drivers/net/wireless/hostap/hostap_main.c
@@ -741,9 +741,7 @@ void hostap_set_multicast_list_queue(struct work_struct *work)
local_info_t *local =
container_of(work, local_info_t, set_multicast_list_queue);
struct net_device *dev = local->dev;
- struct hostap_interface *iface;
- iface = netdev_priv(dev);
if (hostap_set_word(dev, HFA384X_RID_PROMISCUOUSMODE,
local->is_promisc)) {
printk(KERN_INFO "%s: %sabling promiscuous mode failed\n",
--
1.7.1.rc1.21.gf3bd6
^ permalink raw reply related
* [PATCH 0/5] Fix set but unused variable warnings
From: Justin P. Mattock @ 2010-06-16 5:33 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-wireless, linux-pci, linux-scsi
Here is another set of patches fixing some warning messages generated
when building the kernel when using gcc 4.6.0.
This set just focuses in on the variables warnings that are reported
to be unused. Keep in mind there are still lots more warning messages
that I'm seeing, and will try my hardest to see if I can come up with
a fix, but if things become too difficult and so forth then a bug should
be filled etc..
And lastly I want to Thank the people who helped me out on the last patch
set I had sent out and so forth.
Please look if you have the time, and let me know.
Thanks!!
Justin P. Mattock
^ permalink raw reply
* Re: [PATCH v2] iw: Configure basic rates when joining ibss network
From: Teemu Paasikivi @ 2010-06-16 5:31 UTC (permalink / raw)
To: ext Johannes Berg; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1276596357.3648.91.camel@jlt3.sipsolutions.net>
On Tue, 2010-06-15 at 12:05 +0200, ext Johannes Berg wrote:
> On Tue, 2010-06-15 at 12:46 +0300, Teemu Paasikivi wrote:
>
> > + /* basic rates */
> > + if (argc > 1 && strcmp(argv[0], "basic-rates") == 0) {
>
> > if (argc) {
>
> > +COMMAND(ibss, join,
> > + "<SSID> <freq in MHz> [fixed-freq] [<fixed bssid>] "
> > + "[basic-rates <rate in Mbps,rate2,...>] [key d:0:abcde]",
>
> that doesn't match?
>
No it doesn't. Have to fix that (and look at the mirror).
> johannes
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Teemu
^ permalink raw reply
* Re: [RFC PATCH] iw: Add support for setting transmit power
From: Juuso Oikarinen @ 2010-06-16 5:04 UTC (permalink / raw)
To: ext Julian Calaby; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <AANLkTilMwuYujJ1vhVGdoop8ZbgHeJRGcWEYECPLcx-B@mail.gmail.com>
On Tue, 2010-06-15 at 13:50 +0200, ext Julian Calaby wrote:
> On Tue, Jun 15, 2010 at 19:17, Juuso Oikarinen
> <juuso.oikarinen@nokia.com> wrote:
> > This patch adds the "set tx_power" command to allow specifying the transmit
> > power level to the WLAN stack. The transmit power configuration consists of
> > a mode (automatic, fixed, limited) and the limit mBm value.
> >
> > Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
> > ---
> > Makefile | 3 ++-
> > nl80211.h | 27 ++++++++++++++++++++++++++-
> > 2 files changed, 28 insertions(+), 2 deletions(-)
> >
> > diff --git a/Makefile b/Makefile
> > index d303f45..cbb9504 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -17,7 +17,8 @@ CFLAGS += -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing
> > OBJS = iw.o genl.o event.o info.o phy.o \
> > interface.o ibss.o station.o survey.o util.o \
> > mesh.o mpath.o scan.o reg.o version.o \
> > - reason.o status.o connect.o link.o offch.o ps.o cqm.o
> > + reason.o status.o connect.o link.o offch.o ps.o cqm.o \
> > + txpower.o
> > OBJS += sections.o
> > ALL = iw
> >
>
> Call me stupid, but is there a txpower.c?
No I won't call you stupid. It seems I have forgotten to commit again,
but no worries: The corresponding kernel patch went back to the drawing
board, so I'll to redo this patch anyway. I'll be sure also commit
then ;)
-Juuso
> Thanks,
>
^ permalink raw reply
* Re: [PATCH] ipw2200: Enable LED by default
From: Luis R. Rodriguez @ 2010-06-16 4:36 UTC (permalink / raw)
To: Leann Ogasawara; +Cc: reinette.chatre, ilw, linux-wireless, TJ, BrianK.Lee
In-Reply-To: <1276656060.26299.23.camel@emiko>
On Tue, Jun 15, 2010 at 7:41 PM, Leann Ogasawara
<leann.ogasawara@canonical.com> wrote:
> On Tue, 2010-06-15 at 18:20 -0700, Luis R. Rodriguez wrote:
>> On Tue, Jun 15, 2010 at 5:55 PM, Leann Ogasawara
>> <leann.ogasawara@canonical.com> wrote:
>> > Hi All,
>> >
>> > As documented in 2005 in Documentation/networking/README.ipw2200, "The
>> > LED code has been reported to hang some systems when running ifconfig
>> > and is therefore disabled by default." We've however been carrying the
>> > following patch in our Ubuntu kernel for quite some time which enables
>> > the ipw2200 LED by default. This was a result of numerous user
>> > requests. We've seen no subsequent bug reports of systems hanging due
>> > to the the LED code being enabled by default. I'd therefore like to
>> > propose the following patch to enable the LED by default. This patch
>> > was originally authored by TJ. I apologize in advance that I do not
>> > have TJ's full first and last name for provenance.
>> >
>> > Thanks,
>> > Leann
>> >
>> > >From 315246037a0edab4d626de6ccb68c73d3fe61ce3 Mon Sep 17 00:00:00 2001
>> > From: ubuntu@tjworld.net <ubuntu@tjworld.net>
>> > Date: Mon, 23 Mar 2009 20:29:28 +0000
>> > Subject: [PATCH] ipw2200: Enable LED by default
>> >
>> > BugLink: http://bugs.launchpad.net/bugs/21367
>> >
>> > Enable LED by default and update the MODULE_PARM_DESC. The original
>> > reason for defaulting to disabled was documented in 2005 and noted, "The
>> > LED code has been reported to hang some systems when running ifconfig
>> > and is therefore disabled by default." This no longer appears
>> > applicable and users have been requesting this be enabled for several
>> > years.
>> >
>> > Originally-by: TJ <ubuntu@tjworld.net>
>>
>> Does Originally-by also imply he has read the Certificate of Origin
>> and that he agrees for his code to be used in that way? That is the
>> purpose of the SOB anyway, but if you took his code, does that imply
>> that he agrees to it too?
>
> I'd CC'd TJ on the initial email, so I'm hoping he will respond here to
> your inquiry. I can say that he had submitted the original form of the
> patch to the Ubuntu kernel-team mailing list back in March, 2009:
>
> https://lists.ubuntu.com/archives/kernel-team/2009-March/005013.html
>
> In that original submission he did provide his official SOB.
>
> The patch was then applied with slight modification by Tim Gardner to
> the Ubuntu kernel. In forwarding this upstream, I wanted to give TJ the
> proper credit for originating the patch even though it's undergone some
> slight modification (ie the MODULE_PARM_DESC change). TJ had not
> officially signed off on this final form of the patch which is the
> reason I used "Originally-by:". If there is a better approach please
> let me know.
In that case I would just recommend to keep his original SOB, then it
would go through you/tim whoever it goes through until it reaches
Linus. But just my $0.02.
Luis
^ permalink raw reply
* Re: [PATCH] ipw2200: Enable LED by default
From: Leann Ogasawara @ 2010-06-16 2:41 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: reinette.chatre, ilw, linux-wireless, TJ, BrianK.Lee
In-Reply-To: <AANLkTikp4M3Pnh0FEYEayo75FMY8M8j4OaByiiV6EAXJ@mail.gmail.com>
On Tue, 2010-06-15 at 18:20 -0700, Luis R. Rodriguez wrote:
> On Tue, Jun 15, 2010 at 5:55 PM, Leann Ogasawara
> <leann.ogasawara@canonical.com> wrote:
> > Hi All,
> >
> > As documented in 2005 in Documentation/networking/README.ipw2200, "The
> > LED code has been reported to hang some systems when running ifconfig
> > and is therefore disabled by default." We've however been carrying the
> > following patch in our Ubuntu kernel for quite some time which enables
> > the ipw2200 LED by default. This was a result of numerous user
> > requests. We've seen no subsequent bug reports of systems hanging due
> > to the the LED code being enabled by default. I'd therefore like to
> > propose the following patch to enable the LED by default. This patch
> > was originally authored by TJ. I apologize in advance that I do not
> > have TJ's full first and last name for provenance.
> >
> > Thanks,
> > Leann
> >
> > >From 315246037a0edab4d626de6ccb68c73d3fe61ce3 Mon Sep 17 00:00:00 2001
> > From: ubuntu@tjworld.net <ubuntu@tjworld.net>
> > Date: Mon, 23 Mar 2009 20:29:28 +0000
> > Subject: [PATCH] ipw2200: Enable LED by default
> >
> > BugLink: http://bugs.launchpad.net/bugs/21367
> >
> > Enable LED by default and update the MODULE_PARM_DESC. The original
> > reason for defaulting to disabled was documented in 2005 and noted, "The
> > LED code has been reported to hang some systems when running ifconfig
> > and is therefore disabled by default." This no longer appears
> > applicable and users have been requesting this be enabled for several
> > years.
> >
> > Originally-by: TJ <ubuntu@tjworld.net>
>
> Does Originally-by also imply he has read the Certificate of Origin
> and that he agrees for his code to be used in that way? That is the
> purpose of the SOB anyway, but if you took his code, does that imply
> that he agrees to it too?
I'd CC'd TJ on the initial email, so I'm hoping he will respond here to
your inquiry. I can say that he had submitted the original form of the
patch to the Ubuntu kernel-team mailing list back in March, 2009:
https://lists.ubuntu.com/archives/kernel-team/2009-March/005013.html
In that original submission he did provide his official SOB.
The patch was then applied with slight modification by Tim Gardner to
the Ubuntu kernel. In forwarding this upstream, I wanted to give TJ the
proper credit for originating the patch even though it's undergone some
slight modification (ie the MODULE_PARM_DESC change). TJ had not
officially signed off on this final form of the patch which is the
reason I used "Originally-by:". If there is a better approach please
let me know.
Thanks,
Leann
> This is from Documentation/SubmittingPatches
>
> Developer's Certificate of Origin 1.1
>
> By making a contribution to this project, I certify that:
>
> (a) The contribution was created in whole or in part by me and I
> have the right to submit it under the open source license
> indicated in the file; or
>
> (b) The contribution is based upon previous work that, to the best
> of my knowledge, is covered under an appropriate open source
> license and I have the right under that license to submit that
> work with modifications, whether created in whole or in part
> by me, under the same open source license (unless I am
> permitted to submit under a different license), as indicated
> in the file; or
>
> (c) The contribution was provided directly to me by some other
> person who certified (a), (b) or (c) and I have not modified
> it.
>
> (d) I understand and agree that this project and the contribution
> are public and that a record of the contribution (including all
> personal information I submit with it, including my sign-off) is
> maintained indefinitely and may be redistributed consistent with
> this project or the open source license(s) involved.
>
>
> Luis
>
> > Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
> > Signed-off-by: Andy Whitcroft <apw@canonical.com>
> > Acked-by: Stefan Bader <stefan.bader@canonical.com>
> > Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
> > ---
> > Documentation/networking/README.ipw2200 | 2 +-
> > drivers/net/wireless/ipw2x00/ipw2200.c | 4 ++--
> > 2 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/Documentation/networking/README.ipw2200 b/Documentation/networking/README.ipw2200
> > index 80c7285..e4d3267 100644
> > --- a/Documentation/networking/README.ipw2200
> > +++ b/Documentation/networking/README.ipw2200
> > @@ -171,7 +171,7 @@ Where the supported parameter are:
> >
> > led
> > Can be used to turn on experimental LED code.
> > - 0 = Off, 1 = On. Default is 0.
> > + 0 = Off, 1 = On. Default is 1.
> >
> > mode
> > Can be used to set the default mode of the adapter.
> > diff --git a/drivers/net/wireless/ipw2x00/ipw2200.c b/drivers/net/wireless/ipw2x00/ipw2200.c
> > index 3aa3bb1..0805569 100644
> > --- a/drivers/net/wireless/ipw2x00/ipw2200.c
> > +++ b/drivers/net/wireless/ipw2x00/ipw2200.c
> > @@ -96,7 +96,7 @@ static int network_mode = 0;
> > static u32 ipw_debug_level;
> > static int associate;
> > static int auto_create = 1;
> > -static int led_support = 0;
> > +static int led_support = 1;
> > static int disable = 0;
> > static int bt_coexist = 0;
> > static int hwcrypto = 0;
> > @@ -12083,7 +12083,7 @@ module_param(auto_create, int, 0444);
> > MODULE_PARM_DESC(auto_create, "auto create adhoc network (default on)");
> >
> > module_param_named(led, led_support, int, 0444);
> > -MODULE_PARM_DESC(led, "enable led control on some systems (default 0 off)");
> > +MODULE_PARM_DESC(led, "enable led control on some systems (default 1 on)");
> >
> > module_param(debug, int, 0444);
> > MODULE_PARM_DESC(debug, "debug output mask");
> > --
> > 1.7.0.4
> >
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
^ permalink raw reply
* Re: [PATCH 2.6.32.y] ath9k: re-enable ps by default for new single chip families
From: Justin P. Mattock @ 2010-06-16 2:20 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: stable, greg, linux-wireless, Peter Stuge, Kristoffer Ericson,
John W. Linville
In-Reply-To: <1276640359-25360-1-git-send-email-lrodriguez@atheros.com>
On 06/15/2010 03:19 PM, Luis R. Rodriguez wrote:
> commit 14acdde6e527950f66c084dbf19bad6fbfcaeedc upstream.
>
> The newer single chip hardware family of chipsets have not been
> experiencing issues with power saving set by default with recent
> fixes merged (even into stable). The remaining issues are only
> reported with AR5416 and since enabling PS by default can increase
> power savings considerably best to take advantage of that feature
> as this has been tested properly.
>
> For more details on this issue see the bug report:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=14267
>
> We leave AR5416 with PS disabled by default, that seems to require
> some more work.
>
> Cc: stable@kernel.org
> Cc: Peter Stuge<peter@stuge.se>
> Cc: Justin P. Mattock<justinmattock@gmail.com>
> Cc: Kristoffer Ericson<kristoffer.ericson@gmail.com>
> Signed-off-by: Luis R. Rodriguez<lrodriguez@atheros.com>
> Signed-off-by: John W. Linville<linville@tuxdriver.com>
> ---
>
> Greg, this is the long promised backport of the patch titled
> "ath9k: re-enable ps by default for new single chip families" backported
> down to 2.6.32.y. This just goes test compiled. Manual backport
> was required from the upstream Linus patch since the flag
> WIPHY_FLAG_PS_ON_BY_DEFAULT was not used back on 2.6.32 so instead
> we use the equivalent hw->wiphy->ps_default bool.
>
> Apologies for the delay, was just stuck with other stuff.
>
> I'll remove this from the stable pending list for 802.11 [1] once
> this gets sucked in.
>
> [1] http://wireless.kernel.org/en/developers/stable-pending
>
> drivers/net/wireless/ath/ath9k/main.c | 7 ++++++-
> 1 files changed, 6 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
> index 15eb245..dba27b7 100644
> --- a/drivers/net/wireless/ath/ath9k/main.c
> +++ b/drivers/net/wireless/ath/ath9k/main.c
> @@ -1538,6 +1538,8 @@ bad_no_ah:
>
> void ath_set_hw_capab(struct ath_softc *sc, struct ieee80211_hw *hw)
> {
> + struct ath_hw *ah = sc->sc_ah;
> +
> hw->flags = IEEE80211_HW_RX_INCLUDES_FCS |
> IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING |
> IEEE80211_HW_SIGNAL_DBM |
> @@ -1556,7 +1558,10 @@ void ath_set_hw_capab(struct ath_softc *sc, struct ieee80211_hw *hw)
> BIT(NL80211_IFTYPE_ADHOC) |
> BIT(NL80211_IFTYPE_MESH_POINT);
>
> - hw->wiphy->ps_default = false;
> + if (AR_SREV_5416(ah))
> + hw->wiphy->ps_default = false;
> + else
> + hw->wiphy->ps_default = true;
>
> hw->queues = 4;
> hw->max_rates = 4;
I'll have to check and see if my machine run's properly with the
powersaving tuned on..
Justin P. Mattock
^ permalink raw reply
* Re: [PATCH] ipw2200: Enable LED by default
From: Luis R. Rodriguez @ 2010-06-16 1:20 UTC (permalink / raw)
To: Leann Ogasawara; +Cc: reinette.chatre, ilw, linux-wireless, TJ, BrianK.Lee
In-Reply-To: <1276649713.6127.276.camel@emiko>
On Tue, Jun 15, 2010 at 5:55 PM, Leann Ogasawara
<leann.ogasawara@canonical.com> wrote:
> Hi All,
>
> As documented in 2005 in Documentation/networking/README.ipw2200, "The
> LED code has been reported to hang some systems when running ifconfig
> and is therefore disabled by default." We've however been carrying the
> following patch in our Ubuntu kernel for quite some time which enables
> the ipw2200 LED by default. This was a result of numerous user
> requests. We've seen no subsequent bug reports of systems hanging due
> to the the LED code being enabled by default. I'd therefore like to
> propose the following patch to enable the LED by default. This patch
> was originally authored by TJ. I apologize in advance that I do not
> have TJ's full first and last name for provenance.
>
> Thanks,
> Leann
>
> >From 315246037a0edab4d626de6ccb68c73d3fe61ce3 Mon Sep 17 00:00:00 2001
> From: ubuntu@tjworld.net <ubuntu@tjworld.net>
> Date: Mon, 23 Mar 2009 20:29:28 +0000
> Subject: [PATCH] ipw2200: Enable LED by default
>
> BugLink: http://bugs.launchpad.net/bugs/21367
>
> Enable LED by default and update the MODULE_PARM_DESC. The original
> reason for defaulting to disabled was documented in 2005 and noted, "The
> LED code has been reported to hang some systems when running ifconfig
> and is therefore disabled by default." This no longer appears
> applicable and users have been requesting this be enabled for several
> years.
>
> Originally-by: TJ <ubuntu@tjworld.net>
Does Originally-by also imply he has read the Certificate of Origin
and that he agrees for his code to be used in that way? That is the
purpose of the SOB anyway, but if you took his code, does that imply
that he agrees to it too?
This is from Documentation/SubmittingPatches
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
Luis
> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
> Signed-off-by: Andy Whitcroft <apw@canonical.com>
> Acked-by: Stefan Bader <stefan.bader@canonical.com>
> Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
> ---
> Documentation/networking/README.ipw2200 | 2 +-
> drivers/net/wireless/ipw2x00/ipw2200.c | 4 ++--
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/networking/README.ipw2200 b/Documentation/networking/README.ipw2200
> index 80c7285..e4d3267 100644
> --- a/Documentation/networking/README.ipw2200
> +++ b/Documentation/networking/README.ipw2200
> @@ -171,7 +171,7 @@ Where the supported parameter are:
>
> led
> Can be used to turn on experimental LED code.
> - 0 = Off, 1 = On. Default is 0.
> + 0 = Off, 1 = On. Default is 1.
>
> mode
> Can be used to set the default mode of the adapter.
> diff --git a/drivers/net/wireless/ipw2x00/ipw2200.c b/drivers/net/wireless/ipw2x00/ipw2200.c
> index 3aa3bb1..0805569 100644
> --- a/drivers/net/wireless/ipw2x00/ipw2200.c
> +++ b/drivers/net/wireless/ipw2x00/ipw2200.c
> @@ -96,7 +96,7 @@ static int network_mode = 0;
> static u32 ipw_debug_level;
> static int associate;
> static int auto_create = 1;
> -static int led_support = 0;
> +static int led_support = 1;
> static int disable = 0;
> static int bt_coexist = 0;
> static int hwcrypto = 0;
> @@ -12083,7 +12083,7 @@ module_param(auto_create, int, 0444);
> MODULE_PARM_DESC(auto_create, "auto create adhoc network (default on)");
>
> module_param_named(led, led_support, int, 0444);
> -MODULE_PARM_DESC(led, "enable led control on some systems (default 0 off)");
> +MODULE_PARM_DESC(led, "enable led control on some systems (default 1 on)");
>
> module_param(debug, int, 0444);
> MODULE_PARM_DESC(debug, "debug output mask");
> --
> 1.7.0.4
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: Compat-wireless release for 2010-06-15v2 is baked
From: Luis R. Rodriguez @ 2010-06-16 1:17 UTC (permalink / raw)
To: linux-wireless, linux-bluetooth; +Cc: Hauke Mehrtens
In-Reply-To: <AANLkTik49vfTI7UHzCOGJRXdAYJN9fLmwS-xNcHeBcAu@mail.gmail.com>
On Tue, Jun 15, 2010 at 5:41 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> Ok if you don't see any more of these daily please kick me or Haukes.
> Both of us should have access to fix pushing these out now from orbit.
> The backup in case orbit goes down is:
>
> http://wireless.kernel.org/download/compat-wireless-2.6/
Here's another idea. If I'm on vacation or whatever, those who have
access to orbit could just flip a switch and change the git URL to
point to some other git tree to be used as base. Then to aid companies
who want to set up their own repository in case they need more timely
mannered releases based on pending patches you can use this:
git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/compat-user.git
This is the same setup as what we have at orbit, it mimics the user
environment at Orbit, so all you need is an account and space and to
set up a cronjob (read the README). If you find bugs/enhancement to
the scripts just post 'em too.
For those that can wait on me I guess Orbit will do :)
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