* Re: [PATCH] sony-laptop: check for rfkill hard block at load time
From: Johannes Berg @ 2009-09-24 19:27 UTC (permalink / raw)
To: Alan Jenkins
Cc: Mattia Dongili, linux-wireless@vger.kernel.org, Norbert Preining,
Almer S. Tigelaar, Matthias Welwarsky
In-Reply-To: <4ABBC54C.5010103@tuffmail.co.uk>
[-- Attachment #1: Type: text/plain, Size: 1602 bytes --]
On Thu, 2009-09-24 at 20:15 +0100, Alan Jenkins wrote:
> "I recently (on a flight) I found out that when I boot with the hard-switch
> activated, so turning off all wireless activity on my laptop, the state
> is not correctly announced in /dev/rfkill (reading it with rfkill command,
> or my own gnome applet)...
>
> After turning off and on again the hard-switch the events were right."
>
> We can fix this by querying the firmware at load time and calling
> rfkill_set_hw_state().
>
> Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
> Tested-by: Norbert Preining <preining@logic.at>
Looks good, thanks Alan.
Acked-by: Johannes Berg <johannes@sipsolutions.net>
> ---
> drivers/platform/x86/sony-laptop.c | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/platform/x86/sony-laptop.c b/drivers/platform/x86/sony-laptop.c
> index dafaa4a..a234a9d 100644
> --- a/drivers/platform/x86/sony-laptop.c
> +++ b/drivers/platform/x86/sony-laptop.c
> @@ -1081,6 +1081,8 @@ static int sony_nc_setup_rfkill(struct acpi_device *device,
> struct rfkill *rfk;
> enum rfkill_type type;
> const char *name;
> + int result;
> + bool hwblock;
>
> switch (nc_type) {
> case SONY_WIFI:
> @@ -1108,6 +1110,10 @@ static int sony_nc_setup_rfkill(struct acpi_device *device,
> if (!rfk)
> return -ENOMEM;
>
> + sony_call_snc_handle(0x124, 0x200, &result);
> + hwblock = !(result & 0x1);
> + rfkill_set_hw_state(rfk, hwblock);
> +
> err = rfkill_register(rfk);
> if (err) {
> rfkill_destroy(rfk);
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] sony-laptop: check for rfkill hard block at load time
From: Gábor Stefanik @ 2009-09-24 19:24 UTC (permalink / raw)
To: Alan Jenkins
Cc: Mattia Dongili, linux-wireless@vger.kernel.org, Norbert Preining,
Johannes Berg, Almer S. Tigelaar, Matthias Welwarsky
In-Reply-To: <4ABBC54C.5010103@tuffmail.co.uk>
On Thu, Sep 24, 2009 at 9:15 PM, Alan Jenkins
<alan-jenkins@tuffmail.co.uk> wrote:
> "I recently (on a flight) I found out that when I boot with the hard-switch
> activated, so turning off all wireless activity on my laptop, the state
> is not correctly announced in /dev/rfkill (reading it with rfkill command,
> or my own gnome applet)...
>
> After turning off and on again the hard-switch the events were right."
>
> We can fix this by querying the firmware at load time and calling
> rfkill_set_hw_state().
>
> Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
> Tested-by: Norbert Preining <preining@logic.at>
> ---
> drivers/platform/x86/sony-laptop.c | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/platform/x86/sony-laptop.c b/drivers/platform/x86/sony-laptop.c
> index dafaa4a..a234a9d 100644
> --- a/drivers/platform/x86/sony-laptop.c
> +++ b/drivers/platform/x86/sony-laptop.c
> @@ -1081,6 +1081,8 @@ static int sony_nc_setup_rfkill(struct acpi_device *device,
> struct rfkill *rfk;
> enum rfkill_type type;
> const char *name;
> + int result;
> + bool hwblock;
>
> switch (nc_type) {
> case SONY_WIFI:
> @@ -1108,6 +1110,10 @@ static int sony_nc_setup_rfkill(struct acpi_device *device,
> if (!rfk)
> return -ENOMEM;
>
> + sony_call_snc_handle(0x124, 0x200, &result);
Please define these somewhere, don't use magic numbers.
> + hwblock = !(result & 0x1);
> + rfkill_set_hw_state(rfk, hwblock);
> +
> err = rfkill_register(rfk);
> if (err) {
> rfkill_destroy(rfk);
> --
> 1.6.3.2
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* [PATCH] sony-laptop: check for rfkill hard block at load time
From: Alan Jenkins @ 2009-09-24 19:15 UTC (permalink / raw)
To: Mattia Dongili
Cc: linux-wireless@vger.kernel.org, Norbert Preining, Johannes Berg,
Almer S. Tigelaar, Matthias Welwarsky
In-Reply-To: <1253813371.3868.313.camel@johannes.local>
"I recently (on a flight) I found out that when I boot with the hard-switch
activated, so turning off all wireless activity on my laptop, the state
is not correctly announced in /dev/rfkill (reading it with rfkill command,
or my own gnome applet)...
After turning off and on again the hard-switch the events were right."
We can fix this by querying the firmware at load time and calling
rfkill_set_hw_state().
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Tested-by: Norbert Preining <preining@logic.at>
---
drivers/platform/x86/sony-laptop.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/platform/x86/sony-laptop.c b/drivers/platform/x86/sony-laptop.c
index dafaa4a..a234a9d 100644
--- a/drivers/platform/x86/sony-laptop.c
+++ b/drivers/platform/x86/sony-laptop.c
@@ -1081,6 +1081,8 @@ static int sony_nc_setup_rfkill(struct acpi_device *device,
struct rfkill *rfk;
enum rfkill_type type;
const char *name;
+ int result;
+ bool hwblock;
switch (nc_type) {
case SONY_WIFI:
@@ -1108,6 +1110,10 @@ static int sony_nc_setup_rfkill(struct acpi_device *device,
if (!rfk)
return -ENOMEM;
+ sony_call_snc_handle(0x124, 0x200, &result);
+ hwblock = !(result & 0x1);
+ rfkill_set_hw_state(rfk, hwblock);
+
err = rfkill_register(rfk);
if (err) {
rfkill_destroy(rfk);
--
1.6.3.2
^ permalink raw reply related
* Re: [PATCH 1/2] cfg80211: add firmware and hardware version to wiphy
From: Kalle Valo @ 2009-09-24 19:14 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
In-Reply-To: <43e72e890909241132r2c684de2i9e80537bc3d13c63@mail.gmail.com>
On Thu, Sep 24, 2009 at 11:32 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Thu, Sep 24, 2009 at 11:02 AM, Kalle Valo <kalle.valo@iki.fi> wrote:
>> From: Kalle Valo <kalle.valo@nokia.com>
>>
>> It's useful to provide firmware and hardware version to user space and have a
>> generic interface to retrieve them. Users can provide the version information
>> in bug reports etc.
>>
>> Add fields for firmware and hardware version to struct wiphy and return
>> them to user space in NL80211_CMD_GET_WIPHY reply.
>
> Wow that was quick :)
Yeah, it's easy to hack here at Plumbers :D
>> NL80211_ATTR_PID,
>>
>> + NL80211_ATTR_FW_VERSION,
>> + NL80211_ATTR_HW_VERSION,
>> +
>
> Some kdoc on this would be nice.
Definitely. I'll add it in v2 if the implementation is ok otherwise.
>> /* add attributes here, update the policy in nl80211.c */
>>
>> __NL80211_ATTR_AFTER_LAST,
>> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
>> index 3d874c6..de3da19 100644
>> --- a/include/net/cfg80211.h
>> +++ b/include/net/cfg80211.h
>> @@ -1070,6 +1070,8 @@ struct cfg80211_ops {
>> * and registration/helper functions
>> */
>>
>> +#define CFG80211_VERSION_LEN 32
>
> Probably best to just remove this or at least make this not just
> CFG80211_VERSION_LEN, seems like this is related to cfg80211's version
> somehow.
The length is used four time so I would not want to remove it. Maybe
rename to CFG80211_FWHW_VERSION_LEN?
Kalle
^ permalink raw reply
* Re: Problems with "cfg80211: fix SME connect" commit
From: Hin-Tak Leung @ 2009-09-24 19:13 UTC (permalink / raw)
To: Johannes Berg; +Cc: Albert Herranz, Holger Schurig, linville, linux-wireless
In-Reply-To: <1253779538.3868.14.camel@johannes.local>
On Thu, Sep 24, 2009 at 9:05 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Mon, 2009-09-21 at 18:11 +0200, Albert Herranz wrote:
>
>> Adding back "cfg80211: fix SME connect" and applying "cfg80211: don't
>> overwrite privacy setting" fixes the connection issue, but with a
>> introduces a small difference vs the previous working version.
>> There is now an extra "deauthenticating by local choice (reason=3)"
>> message in the logs.
>
>> [ 13.969153] b43-phy0 debug: Adding Interface type 2
>> [ 16.679249] wlan1: direct probe to AP 00:12:17:15:e7:79 (try 1)
>
>> * master-20090916 + "cfg80211: don't overwrite privacy setting"
>
>> [ 13.218613] b43-phy0 debug: Adding Interface type 2
>> [ 15.832582] wlan1: deauthenticating by local choice (reason=3)
>> [ 16.131599] wlan1: direct probe to AP 00:12:17:15:e7:79 (try 1)
>
> Very odd. Can you edit the deauthenticating message to show the
> BSSID/MAC address?
>
> johannes
>
This seems to look like/relate to a little problem I have for the last
few days - lately I have authentication failure on first try and have
to click on NM a 2nd time for it to go through; blow away
compat-wireless & revert to as-shipped distro modules gives me the
older/smooth behavior of NM just associating without me
clicking/asking.
v2.6.31-38294-ged3ac87 + 'cfg80211: don't set privacy w/o key' doesn't
improve my situation.
wpa_supplicant log:
--------- distro modules:
Trying to associate with <id> (SSID='ID' freq=2437 MHz)
Associated with <id>
CTRL-EVENT-CONNECTED - Connection to <id> completed (auth) [id=0 id_str=]
CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
-------- compat-wireless
Trying to associate with <id> (SSID='ID' freq=2437 MHz)
Authentication with 00:00:00:00:00:00 timed out.
Trying to associate with <id> (SSID='ID' freq=2437 MHz)
Associated with <id>
CTRL-EVENT-CONNECTED - Connection to <id> completed (auth) [id=0 id_str=]
------ dmesg distro modules
wlan2: direct probe to AP <id> try 1
wlan2 direct probe responded
wlan2: authenticate with AP <id>
wlan2: authenticated
wlan2: associate with AP <id>
wlan2: RX AssocResp from <id> (capab=0x431 status=0 aid=1)
wlan2: associated
------ compat-wireless, note the extra deauth at the beginning, and
all those 'try 1''s.
wlan2: deauthenticating by local choice (reason=3)
wlan2: direct probe to AP <id> (try 1)
wlan2 direct probe responded
wlan2: authenticate with AP <id> (try 1)
wlan2: authenticated
wlan2: associate with AP <id> (try 1)
wlan2: RX AssocResp from <id> (capab=0x431 status=0 aid=1)
wlan2: associated
my wpa_supplicant config has two configurations, one (the usual) wep,
and a catch-all generic open network, if that matters.
Most of the instances in wpa log are extra authentication timeouts
with 00:00:00:00:00:00 , but occasionally it is my AP's address.
^ permalink raw reply
* Re: [PATCH 2/2] at76c50x-usb: set firmware and hardware version in wiphy
From: Kalle Valo @ 2009-09-24 19:10 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, Felix Bitterli
In-Reply-To: <43e72e890909241135j21f687a7oc4f929d2134b6310@mail.gmail.com>
On Thu, Sep 24, 2009 at 11:35 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> So ath9k and ath5k keep their own strings for such things, to name the
> MAC/Baseband, and then the radio revision and subrevisions... What I'd
> like to see documented on the kdoc for hw_version is what exactly is
> expected to be put there.
>
> The hw_version and fw_version seem to be helpful in providing more
> information to userspace which you would not typically see -- things
> you would only tend to see on a dmesg output so at least for that
> purpose I think its nice. For example lspci won't really tell you the
> exact hardware type on atheros chipsets, so this seems nice.
Exactly, that's my idea here. And with this the information should be
easy to show in UI.
> Anyway, getting some more clarification on the docs would be nice.
I will definitely add documentation. I meant to send these patches RFC
for the implementation idea, but forgot to do it.
BTW, is there an easy way to get the module name for the interface?
That's also helpful information for the user.
Kalle
^ permalink raw reply
* Re: A problem loading ssb module
From: Luis R. Rodriguez @ 2009-09-24 18:37 UTC (permalink / raw)
To: Hauke Mehrtens, Tim Gardner
Cc: Bryan Wu, Mauro Di Domenico, bcm43xx-dev, linux-wireless
In-Reply-To: <4ABBBB8C.8080401@hauke-m.de>
On Thu, Sep 24, 2009 at 11:33 AM, Hauke Mehrtens <hauke@hauke-m.de> wrote:
> Bryan Wu wrote:
>> Mauro Di Domenico wrote:
>>> Hi,
>>> I'm testing new b43 modules for my 14e4:4315 broadcom card.
>>> I've compiled and installed compat-wireless-2009-09-16 in a debian
>>> machine with kernel version 2.6.30-6.
>>>
>>> During the boot I experience this problem:
>>>
>>> $ dmesg|egrep "b43|ssb"
>>>
>>> [ 2.384463] b43-pci-bridge 0000:06:00.0: PCI INT A -> GSI 17 (level,
>>> low) -> IRQ 17
>>> [ 2.384477] b43-pci-bridge 0000:06:00.0: setting latency timer to 64
>>> [ 2.544344] ssb: Sonics Silicon Backplane found on PCI device
>>> 0000:06:00.0
>>> [ 6.968981] b43: disagrees about version of symbol
>>> ssb_device_is_enabled
>>> [ 6.968986] b43: Unknown symbol ssb_device_is_enabled
>>> [ 6.969280] b43: Unknown symbol ssb_pmu_set_ldo_paref
>>> [ 6.969407] b43: disagrees about version of symbol
>>> ssb_pcicore_dev_irqvecs_enable
>>> [ 6.969410] b43: Unknown symbol ssb_pcicore_dev_irqvecs_enable
>>> .....
>>> ....
>>> ...
>>>
>>
>> I faced the exactly same issue as Mauro did. +1 from me, but currently have
>> no time to take a deeper look.
>>
>> Thanks
> Hi,
>
> I had the same problem with the ssb module and compat-wireless in ubuntu
> 9.04. The problem is that the ssb module is integrated into the
> initramfs image. The version out of the initramfs image is loaded on
> startup and not the version of compat-wireless. Running "sudo
> update-initramfs -u" after installing compat-wireless and restaing the
> system fixes the problem for me. Either Debian/Ubuntu should remove ssb
> form default initramfs image or compat-wireless should update the image
> with the install command. At least the compat-wireless documentation
> needs an update.
>
> Hauke
>
> (adding Luis and linux-wireless list)
Tim, do you guys update the initramfs upon installation of lbm? If a
user does not use lbm and uses compat-wireless I suppose we need to do
something similar.
Luis
^ permalink raw reply
* Re: [PATCH 2/2] at76c50x-usb: set firmware and hardware version in wiphy
From: Luis R. Rodriguez @ 2009-09-24 18:35 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Felix Bitterli
In-Reply-To: <20090924180251.14503.64152.stgit@tikku>
On Thu, Sep 24, 2009 at 11:02 AM, Kalle Valo <kalle.valo@iki.fi> wrote:
> Set firmware and hardware version in wiphy so that user space can access
> it.
>
> Signed-off-by: Kalle Valo <kalle.valo@iki.fi>
> ---
>
> drivers/net/wireless/at76c50x-usb.c | 15 +++++++++++++++
> 1 files changed, 15 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/wireless/at76c50x-usb.c b/drivers/net/wireless/at76c50x-usb.c
> index 8e1a55d..b6de657 100644
> --- a/drivers/net/wireless/at76c50x-usb.c
> +++ b/drivers/net/wireless/at76c50x-usb.c
> @@ -2217,6 +2217,8 @@ static struct ieee80211_supported_band at76_supported_band = {
> static int at76_init_new_device(struct at76_priv *priv,
> struct usb_interface *interface)
> {
> + struct wiphy *wiphy;
> + size_t len;
> int ret;
>
> /* set up the endpoint information */
> @@ -2254,6 +2256,7 @@ static int at76_init_new_device(struct at76_priv *priv,
> priv->device_unplugged = 0;
>
> /* mac80211 initialisation */
> + wiphy = priv->hw->wiphy;
> priv->hw->wiphy->max_scan_ssids = 1;
> priv->hw->wiphy->max_scan_ie_len = 0;
> priv->hw->wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION);
> @@ -2265,6 +2268,18 @@ static int at76_init_new_device(struct at76_priv *priv,
> SET_IEEE80211_DEV(priv->hw, &interface->dev);
> SET_IEEE80211_PERM_ADDR(priv->hw, priv->mac_addr);
>
> + len = sizeof(wiphy->fw_version);
> + snprintf(wiphy->fw_version, len, "%d.%d.%d-%d",
> + priv->fw_version.major, priv->fw_version.minor,
> + priv->fw_version.patch, priv->fw_version.build);
> +
> + len = sizeof(wiphy->hw_version);
> + snprintf(wiphy->hw_version, len, "%d", priv->board_type);
So ath9k and ath5k keep their own strings for such things, to name the
MAC/Baseband, and then the radio revision and subrevisions... What I'd
like to see documented on the kdoc for hw_version is what exactly is
expected to be put there.
The hw_version and fw_version seem to be helpful in providing more
information to userspace which you would not typically see -- things
you would only tend to see on a dmesg output so at least for that
purpose I think its nice. For example lspci won't really tell you the
exact hardware type on atheros chipsets, so this seems nice.
Anyway, getting some more clarification on the docs would be nice.
Luis
^ permalink raw reply
* Re: A problem loading ssb module
From: Hauke Mehrtens @ 2009-09-24 18:33 UTC (permalink / raw)
To: Bryan Wu
Cc: Mauro Di Domenico, bcm43xx-dev, Luis R. Rodriguez, linux-wireless
In-Reply-To: <4ABBAB47.8040300@canonical.com>
[-- Attachment #1: Type: text/plain, Size: 1742 bytes --]
Bryan Wu wrote:
> Mauro Di Domenico wrote:
>> Hi,
>> I'm testing new b43 modules for my 14e4:4315 broadcom card.
>> I've compiled and installed compat-wireless-2009-09-16 in a debian
>> machine with kernel version 2.6.30-6.
>>
>> During the boot I experience this problem:
>>
>> $ dmesg|egrep "b43|ssb"
>>
>> [ 2.384463] b43-pci-bridge 0000:06:00.0: PCI INT A -> GSI 17 (level,
>> low) -> IRQ 17
>> [ 2.384477] b43-pci-bridge 0000:06:00.0: setting latency timer to 64
>> [ 2.544344] ssb: Sonics Silicon Backplane found on PCI device
>> 0000:06:00.0
>> [ 6.968981] b43: disagrees about version of symbol
>> ssb_device_is_enabled
>> [ 6.968986] b43: Unknown symbol ssb_device_is_enabled
>> [ 6.969280] b43: Unknown symbol ssb_pmu_set_ldo_paref
>> [ 6.969407] b43: disagrees about version of symbol
>> ssb_pcicore_dev_irqvecs_enable
>> [ 6.969410] b43: Unknown symbol ssb_pcicore_dev_irqvecs_enable
>> .....
>> ....
>> ...
>>
>
> I faced the exactly same issue as Mauro did. +1 from me, but currently have
> no time to take a deeper look.
>
> Thanks
Hi,
I had the same problem with the ssb module and compat-wireless in ubuntu
9.04. The problem is that the ssb module is integrated into the
initramfs image. The version out of the initramfs image is loaded on
startup and not the version of compat-wireless. Running "sudo
update-initramfs -u" after installing compat-wireless and restaing the
system fixes the problem for me. Either Debian/Ubuntu should remove ssb
form default initramfs image or compat-wireless should update the image
with the install command. At least the compat-wireless documentation
needs an update.
Hauke
(adding Luis and linux-wireless list)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 898 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] cfg80211: add firmware and hardware version to wiphy
From: Luis R. Rodriguez @ 2009-09-24 18:32 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
In-Reply-To: <20090924180242.14503.11148.stgit@tikku>
On Thu, Sep 24, 2009 at 11:02 AM, Kalle Valo <kalle.valo@iki.fi> wrote:
> From: Kalle Valo <kalle.valo@nokia.com>
>
> It's useful to provide firmware and hardware version to user space and have a
> generic interface to retrieve them. Users can provide the version information
> in bug reports etc.
>
> Add fields for firmware and hardware version to struct wiphy and return
> them to user space in NL80211_CMD_GET_WIPHY reply.
Wow that was quick :)
> Signed-off-by: Kalle Valo <kalle.valo@nokia.com>
> ---
>
> include/linux/nl80211.h | 3 +++
> include/net/cfg80211.h | 5 +++++
> net/wireless/nl80211.c | 11 +++++++++++
> 3 files changed, 19 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/nl80211.h b/include/linux/nl80211.h
> index a8d71ed..6d6651f 100644
> --- a/include/linux/nl80211.h
> +++ b/include/linux/nl80211.h
> @@ -714,6 +714,9 @@ enum nl80211_attrs {
>
> NL80211_ATTR_PID,
>
> + NL80211_ATTR_FW_VERSION,
> + NL80211_ATTR_HW_VERSION,
> +
Some kdoc on this would be nice.
> /* add attributes here, update the policy in nl80211.c */
>
> __NL80211_ATTR_AFTER_LAST,
> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
> index 3d874c6..de3da19 100644
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -1070,6 +1070,8 @@ struct cfg80211_ops {
> * and registration/helper functions
> */
>
> +#define CFG80211_VERSION_LEN 32
Probably best to just remove this or at least make this not just
CFG80211_VERSION_LEN, seems like this is related to cfg80211's version
somehow.
Luis
^ permalink raw reply
* Re: 2.6.31-git wireless broken
From: Johannes Berg @ 2009-09-24 18:23 UTC (permalink / raw)
To: Hugh Dickins; +Cc: John W. Linville, Rafael J. Wysocki, linux-wireless
In-Reply-To: <Pine.LNX.4.64.0909241859020.25022@sister.anvils>
[-- Attachment #1: Type: text/plain, Size: 1478 bytes --]
On Thu, 2009-09-24 at 19:14 +0100, Hugh Dickins wrote:
> I've been working under the belief that it's WPA encrypted.
>
> > If it's open, can you try this patch?
>
> But I could try the patch, in case I've been fooled.
>
> > http://johannes.sipsolutions.net/patches/kernel/all/2009-09-24-17%3a32/010-cfg80211-fix-wpas-open.patch
>
> However, all the trees I'm working with (Linus latest, or the bisect
> result, or a week old mmotm) have cfg80211_mgd_wext_connect saying:
>
> if (!netif_running(wdev->netdev))
> return 0;
>
> wdev->wext.connect.ie = wdev->wext.ie;
> wdev->wext.connect.ie_len = wdev->wext.ie_len;
> wdev->wext.connect.privacy = wdev->wext.default_key != -1;
>
> if (wdev->wext.keys) {
> wdev->wext.keys->def = wdev->wext.default_key;
> wdev->wext.keys->defmgmt = wdev->wext.default_mgmt_key;
> }
>
> if (!wdev->wext.connect.ssid_len)
> return 0;
>
> which is not consistent with the fix your patch is making.
Ah. That patch isn't in yet I guess. I wonder if that could still be an
issue though. Maybe you can try that patch along with this one:
http://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=commitdiff_plain;h=55a00b83339f25d2979b85ab6e2151390327db80;hp=cfa53f1e753ed709f0a483fa8bd16bc7d08d402d
Anyhow, I'm grasping at straws -- can you tell me more about the failure
mode, and possibly enable CONFIG_MAC80211_DEBUG_MENU and
CONFIG_MAC80211_VERBOSE_DEBUG?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: 2.6.31-git wireless broken
From: Hugh Dickins @ 2009-09-24 18:14 UTC (permalink / raw)
To: Johannes Berg; +Cc: John W. Linville, Rafael J. Wysocki, linux-wireless
In-Reply-To: <1253813740.3868.324.camel@johannes.local>
Many thanks for your rapid response.
On Thu, 24 Sep 2009, Johannes Berg wrote:
> On Thu, 2009-09-24 at 18:18 +0100, Hugh Dickins wrote:
> >
> > I expect you'll need a lot more info from me: please do ask
> > (but bear in mind that I'm wireless and network ignorant).
>
> Thanks. I'm not sure why you'd get the warning there every few seconds,
> but I suppose we don't really care all that much.
>
> I think you're probably running afoul of a bugfix that I did while at
> the wireless summit, and then the fix to it made it in, but not yet the
> fix to the fix :(
>
> Are you using an encrypted network, or an open one?
I've been working under the belief that it's WPA encrypted.
> If it's open, can you try this patch?
But I could try the patch, in case I've been fooled.
> http://johannes.sipsolutions.net/patches/kernel/all/2009-09-24-17%3a32/010-cfg80211-fix-wpas-open.patch
However, all the trees I'm working with (Linus latest, or the bisect
result, or a week old mmotm) have cfg80211_mgd_wext_connect saying:
if (!netif_running(wdev->netdev))
return 0;
wdev->wext.connect.ie = wdev->wext.ie;
wdev->wext.connect.ie_len = wdev->wext.ie_len;
wdev->wext.connect.privacy = wdev->wext.default_key != -1;
if (wdev->wext.keys) {
wdev->wext.keys->def = wdev->wext.default_key;
wdev->wext.keys->defmgmt = wdev->wext.default_mgmt_key;
}
if (!wdev->wext.connect.ssid_len)
return 0;
which is not consistent with the fix your patch is making.
But I do believe I'm encrypted anyway.
Hugh
^ permalink raw reply
* [PATCH 2/2] iw: print firmware and hardware version
From: Kalle Valo @ 2009-09-24 18:09 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <20090924180048.14503.9579.stgit@tikku>
struct wiphy now contains firmware and hardware version, print that
information to the user.
---
info.c | 15 +++++++++++++++
nl80211.h | 3 +++
2 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/info.c b/info.c
index 7bca69d..ae3ed54 100644
--- a/info.c
+++ b/info.c
@@ -66,6 +66,7 @@ static int print_phy_handler(struct nl_msg *msg, void *arg)
struct nlattr *nl_freq;
struct nlattr *nl_rate;
struct nlattr *nl_mode;
+ const char *str;
int bandidx = 1;
int rem_band, rem_freq, rem_rate, rem_mode;
int open;
@@ -263,6 +264,20 @@ static int print_phy_handler(struct nl_msg *msg, void *arg)
printf("\tRTS threshold: %d\n", rts);
}
+ if (tb_msg[NL80211_ATTR_FW_VERSION]) {
+ str = nla_get_string(tb_msg[NL80211_ATTR_FW_VERSION]);
+ if (strlen(str) == 0)
+ str = "<unknown>";
+ printf("\tFirmware version: %s\n", str);
+ }
+
+ if (tb_msg[NL80211_ATTR_HW_VERSION]) {
+ str = nla_get_string(tb_msg[NL80211_ATTR_HW_VERSION]);
+ if (strlen(str) == 0)
+ str = "<unknown>";
+ printf("\tHardware version: %s\n", str);
+ }
+
if (!tb_msg[NL80211_ATTR_SUPPORTED_IFTYPES])
return NL_SKIP;
diff --git a/nl80211.h b/nl80211.h
index a8d71ed..6d6651f 100644
--- a/nl80211.h
+++ b/nl80211.h
@@ -714,6 +714,9 @@ enum nl80211_attrs {
NL80211_ATTR_PID,
+ NL80211_ATTR_FW_VERSION,
+ NL80211_ATTR_HW_VERSION,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
^ permalink raw reply related
* [PATCH 1/2] iw: update nl80211.h from wireless-testing
From: Kalle Valo @ 2009-09-24 18:09 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <20090924180048.14503.9579.stgit@tikku>
---
nl80211.h | 26 +++++++++++++++++++++-----
1 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/nl80211.h b/nl80211.h
index 962e223..a8d71ed 100644
--- a/nl80211.h
+++ b/nl80211.h
@@ -262,6 +262,9 @@
* reasons, for this the %NL80211_ATTR_DISCONNECTED_BY_AP and
* %NL80211_ATTR_REASON_CODE attributes are used.
*
+ * @NL80211_CMD_SET_WIPHY_NETNS: Set a wiphy's netns. Note that all devices
+ * associated with this wiphy must be down and will follow.
+ *
* @NL80211_CMD_MAX: highest used command number
* @__NL80211_CMD_AFTER_LAST: internal use
*/
@@ -336,6 +339,8 @@ enum nl80211_commands {
NL80211_CMD_ROAM,
NL80211_CMD_DISCONNECT,
+ NL80211_CMD_SET_WIPHY_NETNS,
+
/* add new commands above here */
/* used to define NL80211_CMD_MAX below */
@@ -475,10 +480,6 @@ enum nl80211_commands {
* @NL80211_ATTR_SCAN_FREQUENCIES: nested attribute with frequencies (in MHz)
* @NL80211_ATTR_SCAN_SSIDS: nested attribute with SSIDs, leave out for passive
* scanning and include a zero-length SSID (wildcard) for wildcard scan
- * @NL80211_ATTR_SCAN_GENERATION: the scan generation increases whenever the
- * scan result list changes (BSS expired or added) so that applications
- * can verify that they got a single, consistent snapshot (when all dump
- * messages carried the same generation number)
* @NL80211_ATTR_BSS: scan result BSS
*
* @NL80211_ATTR_REG_INITIATOR: indicates who requested the regulatory domain
@@ -573,6 +574,16 @@ enum nl80211_commands {
* and join_ibss(), key information is in a nested attribute each
* with %NL80211_KEY_* sub-attributes
*
+ * @NL80211_ATTR_PID: Process ID of a network namespace.
+ *
+ * @NL80211_ATTR_GENERATION: Used to indicate consistent snapshots for
+ * dumps. This number increases whenever the object list being
+ * dumped changes, and as such userspace can verify that it has
+ * obtained a complete and consistent snapshot by verifying that
+ * all dump messages contain the same generation number. If it
+ * changed then the list changed and the dump should be repeated
+ * completely from scratch.
+ *
* @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
*/
@@ -644,7 +655,7 @@ enum nl80211_attrs {
NL80211_ATTR_SCAN_FREQUENCIES,
NL80211_ATTR_SCAN_SSIDS,
- NL80211_ATTR_SCAN_GENERATION,
+ NL80211_ATTR_GENERATION, /* replaces old SCAN_GENERATION */
NL80211_ATTR_BSS,
NL80211_ATTR_REG_INITIATOR,
@@ -701,12 +712,17 @@ enum nl80211_attrs {
NL80211_ATTR_KEY,
NL80211_ATTR_KEYS,
+ NL80211_ATTR_PID,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
NL80211_ATTR_MAX = __NL80211_ATTR_AFTER_LAST - 1
};
+/* source-level API compatibility */
+#define NL80211_ATTR_SCAN_GENERATION NL80211_ATTR_GENERATION
+
/*
* Allow user space programs to use #ifdef on new attributes by defining them
* here
^ permalink raw reply related
* [PATCH 2/2] at76c50x-usb: set firmware and hardware version in wiphy
From: Kalle Valo @ 2009-09-24 18:02 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <20090924180048.14503.9579.stgit@tikku>
Set firmware and hardware version in wiphy so that user space can access
it.
Signed-off-by: Kalle Valo <kalle.valo@iki.fi>
---
drivers/net/wireless/at76c50x-usb.c | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/at76c50x-usb.c b/drivers/net/wireless/at76c50x-usb.c
index 8e1a55d..b6de657 100644
--- a/drivers/net/wireless/at76c50x-usb.c
+++ b/drivers/net/wireless/at76c50x-usb.c
@@ -2217,6 +2217,8 @@ static struct ieee80211_supported_band at76_supported_band = {
static int at76_init_new_device(struct at76_priv *priv,
struct usb_interface *interface)
{
+ struct wiphy *wiphy;
+ size_t len;
int ret;
/* set up the endpoint information */
@@ -2254,6 +2256,7 @@ static int at76_init_new_device(struct at76_priv *priv,
priv->device_unplugged = 0;
/* mac80211 initialisation */
+ wiphy = priv->hw->wiphy;
priv->hw->wiphy->max_scan_ssids = 1;
priv->hw->wiphy->max_scan_ie_len = 0;
priv->hw->wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION);
@@ -2265,6 +2268,18 @@ static int at76_init_new_device(struct at76_priv *priv,
SET_IEEE80211_DEV(priv->hw, &interface->dev);
SET_IEEE80211_PERM_ADDR(priv->hw, priv->mac_addr);
+ len = sizeof(wiphy->fw_version);
+ snprintf(wiphy->fw_version, len, "%d.%d.%d-%d",
+ priv->fw_version.major, priv->fw_version.minor,
+ priv->fw_version.patch, priv->fw_version.build);
+
+ len = sizeof(wiphy->hw_version);
+ snprintf(wiphy->hw_version, len, "%d", priv->board_type);
+
+ /* null terminate the strings in case they were truncated */
+ wiphy->fw_version[len - 1] = '\0';
+ wiphy->hw_version[len - 1] = '\0';
+
ret = ieee80211_register_hw(priv->hw);
if (ret) {
printk(KERN_ERR "cannot register mac80211 hw (status %d)!\n",
^ permalink raw reply related
* [PATCH 0/2] cfg80211: firmware and hardware version
From: Kalle Valo @ 2009-09-24 18:02 UTC (permalink / raw)
To: linux-wireless
Here's my suggestion how to provide firmware and hardware version to
user space. First I was thinking adding a new nl80211 command and
it looked so ugly that I decided include the versions in struct wiphy
instead.
Please comment.
---
Kalle Valo (2):
at76c50x-usb: set firmware and hardware version in wiphy
cfg80211: add firmware and hardware version to wiphy
drivers/net/wireless/at76c50x-usb.c | 15 +++++++++++++++
include/linux/nl80211.h | 3 +++
include/net/cfg80211.h | 5 +++++
net/wireless/nl80211.c | 11 +++++++++++
4 files changed, 34 insertions(+), 0 deletions(-)
^ permalink raw reply
* [PATCH 1/2] cfg80211: add firmware and hardware version to wiphy
From: Kalle Valo @ 2009-09-24 18:02 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <20090924180048.14503.9579.stgit@tikku>
From: Kalle Valo <kalle.valo@nokia.com>
It's useful to provide firmware and hardware version to user space and have a
generic interface to retrieve them. Users can provide the version information
in bug reports etc.
Add fields for firmware and hardware version to struct wiphy and return
them to user space in NL80211_CMD_GET_WIPHY reply.
Signed-off-by: Kalle Valo <kalle.valo@nokia.com>
---
include/linux/nl80211.h | 3 +++
include/net/cfg80211.h | 5 +++++
net/wireless/nl80211.c | 11 +++++++++++
3 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/include/linux/nl80211.h b/include/linux/nl80211.h
index a8d71ed..6d6651f 100644
--- a/include/linux/nl80211.h
+++ b/include/linux/nl80211.h
@@ -714,6 +714,9 @@ enum nl80211_attrs {
NL80211_ATTR_PID,
+ NL80211_ATTR_FW_VERSION,
+ NL80211_ATTR_HW_VERSION,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 3d874c6..de3da19 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1070,6 +1070,8 @@ struct cfg80211_ops {
* and registration/helper functions
*/
+#define CFG80211_VERSION_LEN 32
+
/**
* struct wiphy - wireless hardware description
* @idx: the wiphy index assigned to this item
@@ -1142,6 +1144,9 @@ struct wiphy {
u32 frag_threshold;
u32 rts_threshold;
+ char fw_version[CFG80211_VERSION_LEN];
+ char hw_version[CFG80211_VERSION_LEN];
+
/* If multiple wiphys are registered and you're handed e.g.
* a regular netdev with assigned ieee80211_ptr, you won't
* know whether it points to a wiphy your driver has registered
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index eddab09..9e2214e 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -138,6 +138,14 @@ static struct nla_policy nl80211_policy[NL80211_ATTR_MAX+1] __read_mostly = {
[NL80211_ATTR_CIPHER_SUITE_GROUP] = { .type = NLA_U32 },
[NL80211_ATTR_WPA_VERSIONS] = { .type = NLA_U32 },
[NL80211_ATTR_PID] = { .type = NLA_U32 },
+ [NL80211_ATTR_FW_VERSION] = {
+ .type = NLA_NUL_STRING,
+ .len = CFG80211_VERSION_LEN,
+ },
+ [NL80211_ATTR_HW_VERSION] = {
+ .type = NLA_NUL_STRING,
+ .len = CFG80211_VERSION_LEN,
+ },
};
/* policy for the attributes */
@@ -420,6 +428,9 @@ static int nl80211_send_wiphy(struct sk_buff *msg, u32 pid, u32 seq, int flags,
NLA_PUT_U32(msg, NL80211_ATTR_WIPHY_RTS_THRESHOLD,
dev->wiphy.rts_threshold);
+ NLA_PUT_STRING(msg, NL80211_ATTR_FW_VERSION, dev->wiphy.fw_version);
+ NLA_PUT_STRING(msg, NL80211_ATTR_HW_VERSION, dev->wiphy.hw_version);
+
NLA_PUT_U8(msg, NL80211_ATTR_MAX_NUM_SCAN_SSIDS,
dev->wiphy.max_scan_ssids);
NLA_PUT_U16(msg, NL80211_ATTR_MAX_SCAN_IE_LEN,
^ permalink raw reply related
* Re: 2.6.31-git wireless broken
From: Johannes Berg @ 2009-09-24 17:35 UTC (permalink / raw)
To: Hugh Dickins; +Cc: John W. Linville, Rafael J. Wysocki, linux-wireless
In-Reply-To: <Pine.LNX.4.64.0909241737390.20846@sister.anvils>
[-- Attachment #1: Type: text/plain, Size: 1695 bytes --]
On Thu, 2009-09-24 at 18:18 +0100, Hugh Dickins wrote:
> I've noticed for a while that wireless is broken in linux-next, on both
> the machines I use it on (a Fujitsu Siemens laptop using iwl3945 and an
> Acer Aspire One using ath5k: both running openSUSE 11.1, with WPA):
> I hoped to find it fixed later, but no, Linus's git is broken now.
>
> Only found time to bisect it a couple of days ago (on the Aspire One:
> guess the other would show the same, but that's no more than a guess).
> It arrived at the commit below as the culprit, which from your own
> words doesn't seem like a very hopeful place to land :-(
>
> That commit does give me a "WARNING: at net/mac80211/mlme.c:1904",
> followed by "WARNING: at net/mac80211/mlme.c:2308" every few seconds;
> and those do get fixed later on (don't appear with latest git).
> But I think there's another problem that comes in later, because
> at this commit iwconfig does show my ESSID, whereas with later
> git it just says "ESSID:off/any" (I have not bisected when that
> change comes in).
>
> I expect you'll need a lot more info from me: please do ask
> (but bear in mind that I'm wireless and network ignorant).
Thanks. I'm not sure why you'd get the warning there every few seconds,
but I suppose we don't really care all that much.
I think you're probably running afoul of a bugfix that I did while at
the wireless summit, and then the fix to it made it in, but not yet the
fix to the fix :(
Are you using an encrypted network, or an open one? If it's open, can
you try this patch?
http://johannes.sipsolutions.net/patches/kernel/all/2009-09-24-17%3a32/010-cfg80211-fix-wpas-open.patch
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: rfkill hard state after booting
From: Johannes Berg @ 2009-09-24 17:29 UTC (permalink / raw)
To: Alan Jenkins
Cc: Norbert Preining, linux-wireless, Mattia Dongili,
Almer S. Tigelaar, Matthias Welwarsky
In-Reply-To: <4ABB8C5E.6070402@tuffmail.co.uk>
[-- Attachment #1: Type: text/plain, Size: 580 bytes --]
On Thu, 2009-09-24 at 16:12 +0100, Alan Jenkins wrote:
> > Although maybe it should just call sony_nc_rfkill_update() after
> > registering all of them?
> That means the initial "add" uevents etc. will contain wrong values (and
> then be updated immediately after). Do we care about that? It's
> unlikely to matter in practice for platform devices which only get
> loaded at boot-time, but perhaps it would set a bad example.
Ah, good point. I was just a little concerned about the logic
difference, but I don't really understand the _update() logic.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* 2.6.31-git wireless broken
From: Hugh Dickins @ 2009-09-24 17:18 UTC (permalink / raw)
To: Johannes Berg; +Cc: John W. Linville, Rafael J. Wysocki, linux-wireless
I've noticed for a while that wireless is broken in linux-next, on both
the machines I use it on (a Fujitsu Siemens laptop using iwl3945 and an
Acer Aspire One using ath5k: both running openSUSE 11.1, with WPA):
I hoped to find it fixed later, but no, Linus's git is broken now.
Only found time to bisect it a couple of days ago (on the Aspire One:
guess the other would show the same, but that's no more than a guess).
It arrived at the commit below as the culprit, which from your own
words doesn't seem like a very hopeful place to land :-(
That commit does give me a "WARNING: at net/mac80211/mlme.c:1904",
followed by "WARNING: at net/mac80211/mlme.c:2308" every few seconds;
and those do get fixed later on (don't appear with latest git).
But I think there's another problem that comes in later, because
at this commit iwconfig does show my ESSID, whereas with later
git it just says "ESSID:off/any" (I have not bisected when that
change comes in).
I expect you'll need a lot more info from me: please do ask
(but bear in mind that I'm wireless and network ignorant).
Thanks,
Hugh
77fdaa12cea26c204cc12c312fe40bc0f3dcdfd8 is first bad commit
commit 77fdaa12cea26c204cc12c312fe40bc0f3dcdfd8
Author: Johannes Berg <johannes@sipsolutions.net>
Date: Tue Jul 7 03:45:17 2009 +0200
mac80211: rework MLME for multiple authentications
Sit tight. This shakes up the world as you know
it. Let go of your spaghetti tongs, they will no
longer be required, the horrible statemachine in
net/mac80211/mlme.c is no more...
With the cfg80211 SME mac80211 now has much less
to keep track of, but, on the other hand, for FT
it needs to be able to keep track of at least one
authentication being in progress while associated.
So convert from a single state machine to having
small ones for all the different things we need to
do. For real FT it will still need work wrt. PS,
but this should be a good step.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
:040000 040000 437301807c7c27495cee7692f293dac1ca56ed78 02520ec555c0873050318af669dade9e066f479d M net
^ permalink raw reply
* Re: [PATCH 3/3 V2] i2400m-sdio: select IWMC3200TOP in Kconfig
From: Inaky Perez-Gonzalez @ 2009-09-24 17:25 UTC (permalink / raw)
To: Winkler, Tomas
Cc: davem@davemloft.net, linville@tuxdriver.com,
netdev@vger.kernel.org, linux-wireless@vger.kernel.org,
linux-mmc@vger.kernel.org, Zhu, Yi, Kao, Cindy H, Cohen, Guy,
Rindjunsky, Ron
In-Reply-To: <1253779256-17058-1-git-send-email-tomas.winkler@intel.com>
On Thu, 2009-09-24 at 02:00 -0600, Winkler, Tomas wrote:
> i2400m-sdio requires iwmc3200top for its operation
>
> create separate config option to separate 3200 specifics
> from eventual further wimax sdio HW.
>
> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Acked-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
I'll merge this into the WiMAX tree.
--
-- Inaky
^ permalink raw reply
* Re: rfkill hard state after booting
From: Norbert Preining @ 2009-09-24 16:19 UTC (permalink / raw)
To: Alan Jenkins
Cc: Johannes Berg, linux-wireless, Mattia Dongili, Almer S. Tigelaar,
Matthias Welwarsky
In-Reply-To: <4ABB89B2.8070302@tuffmail.co.uk>
On Do, 24 Sep 2009, Alan Jenkins wrote:
> + sony_call_snc_handle(0x124, 0x200, &result);
> + hwblock = !(result & 0x1);
> + rfkill_set_hw_state(rfk, hwblock);
> +
I confirm that the (full) patch fixed that problem. Thanks!
Best wishes
Norbert
-------------------------------------------------------------------------------
Dr. Norbert Preining <preining@logic.at> Vienna University of Technology
Debian Developer <preining@debian.org> Debian TeX Group
gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
GOLANT (adj.)
Blank, sly and faintly embarrassed. Pertaining to the expression seen
on the face of someone who has clearly forgotten your name.
--- Douglas Adams, The Meaning of Liff
^ permalink raw reply
* Re: rfkill hard state after booting
From: Alan Jenkins @ 2009-09-24 15:12 UTC (permalink / raw)
To: Johannes Berg
Cc: Norbert Preining, linux-wireless, Mattia Dongili,
Almer S. Tigelaar, Matthias Welwarsky
In-Reply-To: <1253804713.3868.168.camel@johannes.local>
Johannes Berg wrote:
> On Thu, 2009-09-24 at 16:01 +0100, Alan Jenkins wrote:
>
>
>> I think it's pretty clear it's in the sony code. It doesn't call
>> set_hw_state() during init. I.e. (completely untested):
>>
>
> Agree, looking at the code this seems reasonable.
>
> Although maybe it should just call sony_nc_rfkill_update() after
> registering all of them?
>
> johannes
>
That means the initial "add" uevents etc. will contain wrong values (and
then be updated immediately after). Do we care about that? It's
unlikely to matter in practice for platform devices which only get
loaded at boot-time, but perhaps it would set a bad example.
Regards
Alan
^ permalink raw reply
* Re: rfkill hard state after booting
From: Alan Jenkins @ 2009-09-24 15:01 UTC (permalink / raw)
To: Johannes Berg
Cc: Norbert Preining, linux-wireless, Mattia Dongili,
Almer S. Tigelaar, Matthias Welwarsky
In-Reply-To: <1253801252.3868.108.camel@johannes.local>
Johannes Berg wrote:
> On Thu, 2009-09-24 at 15:02 +0200, Norbert Preining wrote:
>
>
>> I recently (on a flight) I found out that when I boot with the hard-switch
>> activated, so turning off all wireless activity on my laptop, the state
>> is not correctly announced in /dev/rfkill (reading it with rfkill command,
>> or my own gnome applet). All the devices seem to be in normal state but
>> one.
>>
>
> Very strange.
>
>
>> Here some outputs:
>> $ cd /sys/class/rfkill
>> $ ls
>> rfkill0@ rfkill1@ rfkill2@ rfkill3@ rfkill4@ rfkill5@
>> $ cat rfkill?/name
>> sony-wifi
>> sony-bluetooth
>> sony-wwan
>> hso-0
>> hci0
>> phy0
>> $
>>
>> and the three sony-* are the ones for actually turning on/off the devices,
>> but they showed all soft 0 hard 0 at initial startup. Only phy0 (AFAIR)
>> had hard 1.
>>
>
> Makes sense. I mean, that phy0 was hard blocked.
>
>
>> After turning off and on again the hard-switch the events were right.
>>
>
> I can't decide where this bug is. I suspect it's in the sony code.
> Anyone feel responsible for that code?
>
> johannes
>
I think it's pretty clear it's in the sony code. It doesn't call
set_hw_state() during init. I.e. (completely untested):
diff --git a/drivers/platform/x86/sony-laptop.c b/drivers/platform/x86/sony-laptop.c
index dafaa4a..a234a9d 100644
--- a/drivers/platform/x86/sony-laptop.c
+++ b/drivers/platform/x86/sony-laptop.c
@@ -1081,6 +1081,8 @@ static int sony_nc_setup_rfkill(struct acpi_device *device,
struct rfkill *rfk;
enum rfkill_type type;
const char *name;
+ int result;
+ bool hwblock;
switch (nc_type) {
case SONY_WIFI:
@@ -1108,6 +1110,10 @@ static int sony_nc_setup_rfkill(struct acpi_device *device,
if (!rfk)
return -ENOMEM;
+ sony_call_snc_handle(0x124, 0x200, &result);
+ hwblock = !(result & 0x1);
+ rfkill_set_hw_state(rfk, hwblock);
+
err = rfkill_register(rfk);
if (err) {
rfkill_destroy(rfk);
^ permalink raw reply related
* Re: rfkill hard state after booting
From: Johannes Berg @ 2009-09-24 15:05 UTC (permalink / raw)
To: Alan Jenkins
Cc: Norbert Preining, linux-wireless, Mattia Dongili,
Almer S. Tigelaar, Matthias Welwarsky
In-Reply-To: <4ABB89B2.8070302@tuffmail.co.uk>
[-- Attachment #1: Type: text/plain, Size: 346 bytes --]
On Thu, 2009-09-24 at 16:01 +0100, Alan Jenkins wrote:
> I think it's pretty clear it's in the sony code. It doesn't call
> set_hw_state() during init. I.e. (completely untested):
Agree, looking at the code this seems reasonable.
Although maybe it should just call sony_nc_rfkill_update() after
registering all of them?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ 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