From: Mario Limonciello <[email protected]>
On Dell XPS 13z (L321X) and 15z (L502X), switching off Bluetooth also
disables wifi due to improper improper BIOS interaction with dell-laptop.
Add those models to the rfkill blacklist.
BugLink: https://bugs.launchpad.net/bugs/901410
Signed-off-by: Mario Limonciello <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/platform/x86/dell-laptop.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/drivers/platform/x86/dell-laptop.c b/drivers/platform/x86/dell-laptop.c
index e6c08ee..8223b6c 100644
--- a/drivers/platform/x86/dell-laptop.c
+++ b/drivers/platform/x86/dell-laptop.c
@@ -120,6 +120,21 @@ static const struct dmi_system_id __initdata dell_device_table[] = {
MODULE_DEVICE_TABLE(dmi, dell_device_table);
static struct dmi_system_id __devinitdata dell_blacklist[] = {
+ /* dell_laptop breaks rfkill behavior (LP: #901410) */
+ {
+ .ident = "Dell XPS 13z",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Dell System XPS L321X"),
+ },
+ },
+ {
+ .ident = "Dell XPS 15z",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Dell System XPS L502X"),
+ },
+ },
/* Supported by compal-laptop */
{
.ident = "Dell Mini 9",
--
1.7.9.5
On Mon, May 14, 2012 at 12:27:32PM -0700, Kamal Mostafa wrote:
> From: Mario Limonciello <[email protected]>
>
> On Dell XPS 13z (L321X) and 15z (L502X), switching off Bluetooth also
> disables wifi due to improper improper BIOS interaction with dell-laptop.
> Add those models to the rfkill blacklist.
What does "Improper BIOS interaction" mean? What's the proper BIOS
interaction?
--
Matthew Garrett | [email protected]
On Mon, 2012-05-14 at 20:37 +0100, Matthew Garrett wrote:
> On Mon, May 14, 2012 at 12:27:32PM -0700, Kamal Mostafa wrote:
> > From: Mario Limonciello <[email protected]>
> >
> > On Dell XPS 13z (L321X) and 15z (L502X), switching off Bluetooth also
> > disables wifi due to improper improper BIOS interaction with dell-laptop.
> > Add those models to the rfkill blacklist.
>
> What does "Improper BIOS interaction" mean? What's the proper BIOS
> interaction?
>
Just that disabling bluetooth also incorrectly disables wifi on those
models (the same as happens for other Dell models in the table?), but
they behave properly (their disable behaviors are no longer linked) once
added to the dell_blacklist table.
I'll resubmit the patch, with perhaps better wording, and since I've
been advised that the model name "XPS 15z" should actually be just "XPS
15".
-Kamal
Kamal Mostafa wrote:
> From: Mario Limonciello <[email protected]>
>
> On Dell XPS 13z (L321X) and 15z (L502X), switching off Bluetooth also
> disables wifi due to improper improper BIOS interaction with dell-laptop.
> Add those models to the rfkill blacklist.
>
> BugLink: https://bugs.launchpad.net/bugs/901410
I was curious whether this also happens with Dell Vostro 3550 and seems not:
# rfkill list
0: dell-wifi: Wireless LAN
Soft blocked: no
Hard blocked: no
1: dell-bluetooth: Bluetooth
Soft blocked: no
Hard blocked: no
2: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
3: hci0: Bluetooth
Soft blocked: no
Hard blocked: no
# rfkill block 1
# rfkill list
0: dell-wifi: Wireless LAN
Soft blocked: no
Hard blocked: no
1: dell-bluetooth: Bluetooth
Soft blocked: yes
Hard blocked: no
2: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
3: hci0: Bluetooth
Soft blocked: no
Hard blocked: no
# rfkill block 0
# rfkill list
0: dell-wifi: Wireless LAN
Soft blocked: yes
Hard blocked: no
1: dell-bluetooth: Bluetooth
Soft blocked: yes
Hard blocked: no
2: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
3: hci0: Bluetooth
Soft blocked: no
Hard blocked: no
# iwconfig
tun0 no wireless extensions.
eth0 no wireless extensions.
lo no wireless extensions.
wlan0 IEEE 802.11bgn ESSID:off/any
Mode:Managed Access Point: Not-Associated Tx-Power=0 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
#
# rfkill unblock 1
# rfkill unblock 0
# rfkill list
0: dell-wifi: Wireless LAN
Soft blocked: no
Hard blocked: no
1: dell-bluetooth: Bluetooth
Soft blocked: no
Hard blocked: no
2: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
3: hci0: Bluetooth
Soft blocked: no
Hard blocked: no
#
Now, after doing once Fn+F2 to disable the device(s):
# rfkill list
0: dell-wifi: Wireless LAN
Soft blocked: yes
Hard blocked: yes
1: dell-bluetooth: Bluetooth
Soft blocked: yes
Hard blocked: yes
2: phy0: Wireless LAN
Soft blocked: no
Hard blocked: yes
#
Another press of Fn+F2 enables both at once:
# rfkill list
0: dell-wifi: Wireless LAN
Soft blocked: no
Hard blocked: no
1: dell-bluetooth: Bluetooth
Soft blocked: no
Hard blocked: no
2: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
4: hci0: Bluetooth
Soft blocked: no
Hard blocked: no
#
BIOS A09 here, linux-3.4-rc7.
Just do not know why I still get those "Unknown key pressed" messages:
[ 2652.048353] atkbd serio0: Unknown key pressed (translated set 2, code 0x88 on isa0060/serio0).
[ 2652.048363] atkbd serio0: Use 'setkeycodes e008 <keycode>' to make it known.
[ 2652.103556] iwlwifi 0000:09:00.0: RF_KILL bit toggled to disable radio.
...cut...
[ 3249.854374] atkbd serio0: Unknown key pressed (translated set 2, code 0x88 on isa0060/serio0).
[ 3249.854385] atkbd serio0: Use 'setkeycodes e008 <keycode>' to make it known.
[ 3250.030173] iwlwifi 0000:09:00.0: RF_KILL bit toggled to enable radio.
Regards,
Martin
From: Mario Limonciello <[email protected]>
On Dell XPS 13z (L321X) and 15 (L502X), switching off Bluetooth also
disables wifi. Fix by adding those models to the dell_blacklist table.
BugLink: https://bugs.launchpad.net/bugs/901410
Signed-off-by: Mario Limonciello <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
---
drivers/platform/x86/dell-laptop.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/drivers/platform/x86/dell-laptop.c b/drivers/platform/x86/dell-laptop.c
index e6c08ee..35b38cc 100644
--- a/drivers/platform/x86/dell-laptop.c
+++ b/drivers/platform/x86/dell-laptop.c
@@ -120,6 +120,21 @@ static const struct dmi_system_id __initdata dell_device_table[] = {
MODULE_DEVICE_TABLE(dmi, dell_device_table);
static struct dmi_system_id __devinitdata dell_blacklist[] = {
+ /* dell_laptop breaks rfkill behavior (LP: #901410) */
+ {
+ .ident = "Dell XPS 13z",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Dell System XPS L321X"),
+ },
+ },
+ {
+ .ident = "Dell XPS 15",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Dell System XPS L502X"),
+ },
+ },
/* Supported by compal-laptop */
{
.ident = "Dell Mini 9",
--
1.7.9.5
On 05/14/2012 02:37 PM, Matthew Garrett wrote:
> What does "Improper BIOS interaction" mean? What's the proper BIOS interaction?
These platforms are not obeying the smbios interface specs for turning on and off radios. It's not currently expected that the interaction will improve during the lifetime of these platforms. If it does, then this can be adjusted to only apply to the BIOS versions before the fix.
--
*Mario Limonciello*
Linux Engineer
*Dell*| OS Engineering
On Mon, May 14, 2012 at 03:08:57PM -0500, Mario Limonciello wrote:
>
> On 05/14/2012 02:37 PM, Matthew Garrett wrote:
> >What does "Improper BIOS interaction" mean? What's the proper BIOS interaction?
> These platforms are not obeying the smbios interface specs for turning on and off radios. It's not currently expected that the interaction will improve during the lifetime of these platforms. If it does, then this can be adjusted to only apply to the BIOS versions before the fix.
Ok, pretty bored of this at this point. If the bios interface is
unreliable then I'll just remove the rfkill support. I'm not going to
continue adding machines to a blacklist some time after users find
things are broken.
Is this just as broken under Windows?
--
Matthew Garrett | [email protected]
On Mon, May 14, 2012 at 04:21:17PM -0500, Mario Limonciello wrote:
> The outliers of Inspiron and XPS don't seem to follow the interface as
> explicitly. It is not broken on Windows. I don't have an
> understanding why it's not, but conjecture that it's a different
> interface being used on these that I don't have information on yet.
If we're using a different interface to Windows then we're still doing
it wrong. I'll take patches that port us to the interface that's
actually being used, but I won't take patches that just try to cover up
a broken interface that the vendor doesn't test.
> You would be better to only match on Latitude and Vostro and anything
> else that people want to opt in via a paramater than to remove the
> interface entirely IMO.
If Windows uses this interface on Latitude and Vostro then I'll do that,
but otherwise no.
--
Matthew Garrett | [email protected]
On 05/14/2012 04:19 PM, Matthew Garrett wrote:
> On Mon, May 14, 2012 at 03:08:57PM -0500, Mario Limonciello wrote:
>> On 05/14/2012 02:37 PM, Matthew Garrett wrote:
>>> What does "Improper BIOS interaction" mean? What's the proper BIOS interaction?
>> These platforms are not obeying the smbios interface specs for turning on and off radios. It's not currently expected that the interaction will improve during the lifetime of these platforms. If it does, then this can be adjusted to only apply to the BIOS versions before the fix.
> Ok, pretty bored of this at this point. If the bios interface is
> unreliable then I'll just remove the rfkill support. I'm not going to
> continue adding machines to a blacklist some time after users find
> things are broken.
>
> Is this just as broken under Windows?
>
The BIOS interface is reliable on business client (Latitude and Vostro) hardware.
The outliers of Inspiron and XPS don't seem to follow the interface as explicitly. It is not broken on Windows. I don't have an understanding why it's not, but conjecture that it's a different interface being used on these that I don't have information on yet.
You would be better to only match on Latitude and Vostro and anything else that people want to opt in via a paramater than to remove the interface entirely IMO.
--
*Mario Limonciello*
Linux Engineer
*Dell*| OS Engineering
On 05/14/2012 04:28 PM, Matthew Garrett wrote:
> On Mon, May 14, 2012 at 04:21:17PM -0500, Mario Limonciello wrote:
>
>> The outliers of Inspiron and XPS don't seem to follow the interface as
>> explicitly. It is not broken on Windows. I don't have an
>> understanding why it's not, but conjecture that it's a different
>> interface being used on these that I don't have information on yet.
> If we're using a different interface to Windows then we're still doing
> it wrong. I'll take patches that port us to the interface that's
> actually being used, but I won't take patches that just try to cover up
> a broken interface that the vendor doesn't test.
The problems were exposed on newer XPS laptops because those platforms were not tested during platform development. There really isn't a scalable way to represent whether a platform was or wasn't tested during development. In a lot of situation things just work. I would like to do the right thing for the users with what information and resources are available right now to put them in a better state. An aggressive approach of not taking patches to cover a broken interface won't fix the problem of not testing machines already in the market, it will just put end users of the kernel module at a disadvantage.
>> You would be better to only match on Latitude and Vostro and anything
>> else that people want to opt in via a paramater than to remove the
>> interface entirely IMO.
> If Windows uses this interface on Latitude and Vostro then I'll do that,
> but otherwise no.
The problem is this isn't something that can be quantified to match all different Dell laptops. Specifications, ODMS, IBVs, and requirements change over time on different laptops so this kernel module is really just a line of best fit. You can be sure the matching driver and tool on the windows side will rev and collect special case scenarios as laptops come out. If you want to continue to best represent things going forward do this:
1) Don't blacklist any Latitude or Vostro. These are tested during platform development.
2) Leave those compal_laptop supported ones blacklisted.
3) Blacklist 2010-2012 XPS. These are currently not tested during platform development.
4) If problems start to show up on Inspiron, blacklist them invidually. These platforms are currently tested during platform development though, so hopefully issues don't crop up.
On Mon, May 14, 2012 at 04:48:24PM -0500, Mario Limonciello wrote:
> The problems were exposed on newer XPS laptops because those platforms
> were not tested during platform development. There really isn't a
> scalable way to represent whether a platform was or wasn't tested
> during development. In a lot of situation things just work. I would
> like to do the right thing for the users with what information and
> resources are available right now to put them in a better state. An
> aggressive approach of not taking patches to cover a broken interface
> won't fix the problem of not testing machines already in the market,
> it will just put end users of the kernel module at a disadvantage.
That's why it's better to just remove the interface. Providing a feature
when we know it's broken on some unknown subset of hardware doesn't
benefit anyone. If even Dell don't have any idea which set of machines
it works on then how are we ever expected to make sure it's correct?
> 1) Don't blacklist any Latitude or Vostro. These are tested during platform development.
> 2) Leave those compal_laptop supported ones blacklisted.
> 3) Blacklist 2010-2012 XPS. These are currently not tested during platform development.
> 4) If problems start to show up on Inspiron, blacklist them invidually. These platforms are currently tested during platform development though, so hopefully issues don't crop up.
Is this the set of criteria that the Windows tools use? If so, I'll
implement it. If not, then either provide the set of criteria that the
Windows tools use or I'll remove the interface.
--
Matthew Garrett | [email protected]
Hi
I'm the owner of a XPS 15, which has this issue.
The best solution would indeed be to solve the real bug, and not work
around it in Linux.
But still, if we can fix it with rather small impact/code on linux, I
think we should just do it.
It makes linux more user friendly this way.
A small remark also:
Is it really possible to disable bluetooth without killing wifi in
Windows on the XPS?
Not that I use windows alot, but it doesn't seem to work perfectly in
windows neither.
This bug is prolly not very common, as default XPS doesn't have a
bluetooth chip.
Thanks
Jean-Louis
Op 14-05-12 23:55, Matthew Garrett schreef:
> On Mon, May 14, 2012 at 04:48:24PM -0500, Mario Limonciello wrote:
>
>> The problems were exposed on newer XPS laptops because those platforms
>> were not tested during platform development. There really isn't a
>> scalable way to represent whether a platform was or wasn't tested
>> during development. In a lot of situation things just work. I would
>> like to do the right thing for the users with what information and
>> resources are available right now to put them in a better state. An
>> aggressive approach of not taking patches to cover a broken interface
>> won't fix the problem of not testing machines already in the market,
>> it will just put end users of the kernel module at a disadvantage.
> That's why it's better to just remove the interface. Providing a feature
> when we know it's broken on some unknown subset of hardware doesn't
> benefit anyone. If even Dell don't have any idea which set of machines
> it works on then how are we ever expected to make sure it's correct?
>
>> 1) Don't blacklist any Latitude or Vostro. These are tested during platform development.
>> 2) Leave those compal_laptop supported ones blacklisted.
>> 3) Blacklist 2010-2012 XPS. These are currently not tested during platform development.
>> 4) If problems start to show up on Inspiron, blacklist them invidually. These platforms are currently tested during platform development though, so hopefully issues don't crop up.
> Is this the set of criteria that the Windows tools use? If so, I'll
> implement it. If not, then either provide the set of criteria that the
> Windows tools use or I'll remove the interface.
Jean-Louis Dupond wrote:
> Hi
>
> I'm the owner of a XPS 15, which has this issue.
> The best solution would indeed be to solve the real bug, and not work
> around it in Linux.
>
> But still, if we can fix it with rather small impact/code on linux, I
> think we should just do it.
> It makes linux more user friendly this way.
>
> A small remark also:
> Is it really possible to disable bluetooth without killing wifi in
> Windows on the XPS?
I rebooted into Win7. You are right, on this Dell Vostro 3550 the Fn+F2 has
only two states: turn on both BT+WiFi or turn both off. My old ASUS laptop
had 3 states and I could turn off independently BT while not WiFi. ;)
So, rfkill application on Linux behaves in the same way as the Fn+F2 in Linux
and in Win 7.
Martin