Hello,
I wanted to give a try to your compat-wireless bleeding edge drivers. I
have an RTL8187 based wlan chip on my laptop. After installing the
driver I was not able to use the WiFi anymore as the driver reports that
the kill switch is active no matter in what position I turn the switch
on the side of the laptop.
Here's the dmesg output of the chip detection:
[ 20.686680] phy0: Selected rate control algorithm 'minstrel'
[ 20.687554] phy0: hwaddr 00:1b:9e:eb:77:98, RTL8187BvE V0 + rtl8225z2
[ 20.710529] rtl8187: Customer ID is 0x04
[ 20.710588] Registered led device: rtl8187-phy0::tx
[ 20.710611] Registered led device: rtl8187-phy0::rx
[ 20.711393] rtl8187: wireless switch is off
I checked the driver and found the rtl8187_rfkill.c. I added some
prink's to see what's happening and noticed that the physical switch did
affect different bit than the one tested in the current driver. This
change enables the correct behavior on my laptop:
--- rtl8187_rfkill.c.orig 2009-12-02 14:12:34.646597569 +0200
+++ rtl8187_rfkill.c 2009-12-02 14:10:09.474593370 +0200
@@ -28,7 +28,7 @@ static bool rtl8187_is_radio_enabled(str
rtl818x_iowrite8(priv, &priv->map->GPIO0, gpio & ~0x02);
gpio = rtl818x_ioread8(priv, &priv->map->GPIO1);
- return gpio & 0x02;
+ return gpio & 0x04;
}
I tried to contact Realtek to provide me with some specs so that I can
verify the register in question, but all I received was a reply with the
realtek's reference driver attached. I haven't got any answer to my
follow-up request for the specification.
I looked through the reference driver but could not find anything
informational. I didn't have time to do a full review, though.
Without the specification I can't tell how this can be fixed. People
have reported success with the current driver, haven't they, so the bit
is correct for them.
As soon as distributions start shipping the new rtl8187 driver there are
people whose wlan stops working. I don't know if the killswitch with
rtl8187 chipsets is suppose to be only created with software but at
least in my laptop it didn't matter in which position the switch was
with older drivers, the radio worked anyway.
Any thoughts how to continue with this?
-- Antti
pe, 2009-12-04 kello 15:34 -0600, Larry Finger kirjoitti:
> Antti,
>
> From our private tests, you can see my problem with making a change in
> the rfkill handling. Most of the devices in the hands of the
> developers do not honor the rfkill switch; however, the one that does
> works with the current code. This code also matches the latest version
> of the vendor drivers for the RTL8187L
> (rtl8187L_linux_26.1038.0626.2009.release) and RTL8187B
> (rtl8187B_linux_26.1036.0708.2008). If you have newer drivers from
> Realtek, I would be interested in seeing them.
I attached the one I received.
> To make a special case for your system, we need to be able to
> differentiate it from all other systems. We know that the chip has the
> same cut (RTL8187BvE V0) as Hin-Tak's, and the same vendor ID (0x04).
> We do have devices that require parsing additional USB data to get the
> setup properly initialized. Please send me the full output of the
> 'lsusb -v' command for the rtl8187 device. I will get the same info
> from Hin-Tak to see if we can differentiate your two devices.
See the attached lsusb_v.txt
I had now some time to look in to this. First of all I was sad to
discover that the specifications from Realtek have incomplete EEPROM
register descriptions and they are no use to figure this problem out.
But at least they describe the functionality so that it's easier to find
out what's going on with the drivers.
I looked through the reference driver and found out that indeed the GPIO
pin is different for some devices, mine included (0x8198).
r8187_core.c:L4359
if((idProduct == 0x8197) || (idProduct == 0x8198)) {
priv->EEPROMSelectNewGPIO =((u8)((eprom_read(dev,EPROM_SELECT_GPIO) & 0xff00) >> 8)) ? true : false;
DMESG("EPROM_SELECT_GPIO:%d", priv->EEPROMSelectNewGPIO);
} else {
priv->EEPROMSelectNewGPIO = false;
}
Here's the begining of the RFKILL code (see, 0x2 vs. 0x4!)
r8187_core.c:L6258
tmp1byte = read_nic_byte(dev,GPE);
if(priv->EEPROMSelectNewGPIO == true)
tmp1byte &= ~BIT2;
else
tmp1byte &= ~BIT1;
write_nic_byte(dev,GPE,tmp1byte);
I would like to prepare a proper patch, but I'm afraid I do not have the
time right now and someone else can probably do it a lot faster. The
current rfkill code is now in 2.6.32 and some people are going to find
out that their wlan no longer is accessible because of insufficient
rfkill detection so this puts this somewhat higher priority.
-- Antti
2009/12/3 Antti Kaijanm?ki <[email protected]>:
> It's a Toshiba Satellite Pro L300.
I have a Toshiba A210; the Realtek hardware is the same, but I am a
little surprised that there is no similiarity to the mac address
(AFAIK part of the mac address is the manufacturer's identity). In any
case, the rkill code works here
(up to date fedora 12 + compat-wireless from yesterday or the day before).
> I contacted Realtek again and this morning I had data sheets for
> RTL8187B and RTL8187L chipsets in my inbox, yay!. I didn't have time to
> look deeply in to them just yet, but at quick glance the data sheets
> didn't talk anything about rfkill. My fear is that the rfkill features
> are laptop vendor specific by being implemented using the General
> Purpose IO pins, but this speculation is still premature.
Yes, I think the gpio pins are OEM-specific.
--- rtl8187_rfkill.c.orig 2009-12-02 14:12:34.646597569 +0200
+++ rtl8187_rfkill.c 2009-12-02 14:10:09.474593370 +0200
@@ -28,7 +28,7 @@ static bool rtl8187_is_radio_enabled(str
rtl818x_iowrite8(priv, &priv->map->GPIO0, gpio & ~0x02);
gpio = rtl818x_ioread8(priv, &priv->map->GPIO1);
- return gpio & 0x02;
+ return gpio & 0x04;
}
Your patch is probably wrong - all you are doing is get some random
bits off the chip and lie to the rest of the system about being radio
is enabled.
That leads to my next question - what *is the rest* of your system?
Back in F11 I had a funny problem for a few days when I was trying
out/testing the then-new rtl8187 rfkill code Larry and Herton came up
with: I can switch off the radio and it is effective for about 1
minute - then NetworkManager decides to turn the wireless chip back
on. It turned out that hal (at least on F11, and also then, a few
months ago) needed to be taught to honour the state of the rkill
switch and be aware of it. Maybe you have the reverse problem - the
rest of your system needs to be taught not to switch it off.
As for the datasheet - no, there aren't any obvious rfkill info (or I
haven't read carefully - Larry will correct me). Realtek doesn't seem
to have a problem with e-mailing it to individuals, so a few of us has
it as well; but since they don't have it available for public download
on their web site, I assume it was sent on good faith for private
viewing pleasure.... and the terms of (re-)distribution is probably to
people who show interests in improving the driver. (instead of, say,
to competitors trying to poke holes in their hardware...).
2009/12/5 Antti Kaijanm?ki <[email protected]>:
> pe, 2009-12-04 kello 15:34 -0600, Larry Finger kirjoitti:
..
>> I will get the same info
>> from Hin-Tak to see if we can differentiate your two devices.
>
> See the attached lsusb_v.txt
The only difference between yours and mine is just the USB id (8197 vs
8198). There is no other difference. (But it is probably unsafe to
base any change on product id alone - there are about 5-6 variants
even among the 3 ids
8187/8189 and 8197).
> I looked through the reference driver and found out that indeed the GPIO
> pin is different for some devices, mine included (0x8198).
There are differences between devices even with the same id - has
always been the case - see comment above.
> r8187_core.c:L4359
>
> ? ? ? ?if((idProduct == 0x8197) || (idProduct == 0x8198)) ? ? ?{
> ? ? ? ? ? ? ? ?priv->EEPROMSelectNewGPIO =((u8)((eprom_read(dev,EPROM_SELECT_GPIO) & 0xff00) >> 8)) ? true : false;
> ? ? ? ? ? ? ? ?DMESG("EPROM_SELECT_GPIO:%d", priv->EEPROMSelectNewGPIO);
> ? ? ? ?} else {
> ? ? ? ? ? ? ? ?priv->EEPROMSelectNewGPIO = false;
> ? ? ? ?}
>
>
>
> Here's the begining of the RFKILL code (see, 0x2 vs. 0x4!)
>
> r8187_core.c:L6258
>
> ? ? ? ? ? ? ? ? ? ? ? ?tmp1byte = read_nic_byte(dev,GPE);
> ? ? ? ? ? ? ? ? ? ? ? ?if(priv->EEPROMSelectNewGPIO == true)
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?tmp1byte &= ~BIT2;
> ? ? ? ? ? ? ? ? ? ? ? ?else
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?tmp1byte &= ~BIT1;
>
> ? ? ? ? ? ? ? ? ? ? ? ?write_nic_byte(dev,GPE,tmp1byte);
I'll have a look at what this does when I find the time. What version
of the vendor driver have you got? The last one we have is
26.1036.0708.2008 (mostly you just look at the 1036 part which is the
version, and 0708.2008 is the release date). If you have a more recent
version, you should share it with me, Larry and Herton - our e-mails
are in the MAINTAINERS file, but you already found me and Larry, just
Herton hasn't comment yet(?). (as I wrote, for some reason Realtek
doesn't put it up publicly for download but seems to be happy to
e-mail to people when they ask, so I think it is appropriate to behave
along similiar lines).
> I would like to prepare a proper patch, but I'm afraid I do not have the
> time right now and someone else can probably do it a lot faster. The
> current rfkill code is now in 2.6.32 and some people are going to find
> out that their wlan no longer is accessible because of insufficient
> rfkill detection so this puts this somewhat higher priority.
It is not as dramatic or gloomy as you wrote - my laptop is less than
2 years old, from the same menufacturer, so it just seems that Toshiba
chose to change and/or bought in a batch of newer Realtek chips which
behave somewhat differently. I assume yours is newer than mine. Nobody
knows how many Toshiba laptops out there behaves like mine (which was
where the rfkill code ended up in 2.6.32 was tested, successfully)
instead of like yours (which is affected adversely by the rfkill
code). And we want to fix this before major distros start to ship
2.6.32. That's probably going to be April with Ubuntu and Fedora. We
probably have a few months before it affects too many end users.
Hin-Tak
On 12/02/2009 06:25 AM, Antti Kaijanmäki wrote:
> Hello,
>
> I wanted to give a try to your compat-wireless bleeding edge drivers. I
> have an RTL8187 based wlan chip on my laptop. After installing the
> driver I was not able to use the WiFi anymore as the driver reports that
> the kill switch is active no matter in what position I turn the switch
> on the side of the laptop.
>
> Here's the dmesg output of the chip detection:
>
> [ 20.686680] phy0: Selected rate control algorithm 'minstrel'
> [ 20.687554] phy0: hwaddr 00:1b:9e:eb:77:98, RTL8187BvE V0 + rtl8225z2
> [ 20.710529] rtl8187: Customer ID is 0x04
> [ 20.710588] Registered led device: rtl8187-phy0::tx
> [ 20.710611] Registered led device: rtl8187-phy0::rx
> [ 20.711393] rtl8187: wireless switch is off
>
> I checked the driver and found the rtl8187_rfkill.c. I added some
> prink's to see what's happening and noticed that the physical switch did
> affect different bit than the one tested in the current driver. This
> change enables the correct behavior on my laptop:
>
> --- rtl8187_rfkill.c.orig 2009-12-02 14:12:34.646597569 +0200
> +++ rtl8187_rfkill.c 2009-12-02 14:10:09.474593370 +0200
> @@ -28,7 +28,7 @@ static bool rtl8187_is_radio_enabled(str
> rtl818x_iowrite8(priv, &priv->map->GPIO0, gpio & ~0x02);
> gpio = rtl818x_ioread8(priv, &priv->map->GPIO1);
>
> - return gpio & 0x02;
> + return gpio & 0x04;
> }
>
>
> I tried to contact Realtek to provide me with some specs so that I can
> verify the register in question, but all I received was a reply with the
> realtek's reference driver attached. I haven't got any answer to my
> follow-up request for the specification.
>
> I looked through the reference driver but could not find anything
> informational. I didn't have time to do a full review, though.
>
> Without the specification I can't tell how this can be fixed. People
> have reported success with the current driver, haven't they, so the bit
> is correct for them.
>
> As soon as distributions start shipping the new rtl8187 driver there are
> people whose wlan stops working. I don't know if the killswitch with
> rtl8187 chipsets is suppose to be only created with software but at
> least in my laptop it didn't matter in which position the switch was
> with older drivers, the radio worked anyway.
>
> Any thoughts how to continue with this?
As wireless in Linux approaches the correct behavior with respect to
killing wireless, there will be some cases like yours. Having the
radio work no matter the switch position is just plain wrong. I hope
you understand that.
What laptop do you have? If the RTL8187 built in or externally
plugged? If built in, is there a WMI driver for it? Do you have it loaded?
Larry
On 12/03/2009 06:01 AM, Hin-Tak Leung wrote:
> 2009/12/3 Antti Kaijanm?ki <[email protected]>:
>> It's a Toshiba Satellite Pro L300.
>
> I have a Toshiba A210; the Realtek hardware is the same, but I am a
> little surprised that there is no similiarity to the mac address
> (AFAIK part of the mac address is the manufacturer's identity). In any
> case, the rkill code works here
> (up to date fedora 12 + compat-wireless from yesterday or the day before).
>
>> I contacted Realtek again and this morning I had data sheets for
>> RTL8187B and RTL8187L chipsets in my inbox, yay!. I didn't have time to
>> look deeply in to them just yet, but at quick glance the data sheets
>> didn't talk anything about rfkill. My fear is that the rfkill features
>> are laptop vendor specific by being implemented using the General
>> Purpose IO pins, but this speculation is still premature.
>
> Yes, I think the gpio pins are OEM-specific.
>
> --- rtl8187_rfkill.c.orig 2009-12-02 14:12:34.646597569 +0200
> +++ rtl8187_rfkill.c 2009-12-02 14:10:09.474593370 +0200
> @@ -28,7 +28,7 @@ static bool rtl8187_is_radio_enabled(str
> rtl818x_iowrite8(priv, &priv->map->GPIO0, gpio & ~0x02);
> gpio = rtl818x_ioread8(priv, &priv->map->GPIO1);
>
> - return gpio & 0x02;
> + return gpio & 0x04;
>
> }
>
> Your patch is probably wrong - all you are doing is get some random
> bits off the chip and lie to the rest of the system about being radio
> is enabled.
>
> That leads to my next question - what *is the rest* of your system?
> Back in F11 I had a funny problem for a few days when I was trying
> out/testing the then-new rtl8187 rfkill code Larry and Herton came up
> with: I can switch off the radio and it is effective for about 1
> minute - then NetworkManager decides to turn the wireless chip back
> on. It turned out that hal (at least on F11, and also then, a few
> months ago) needed to be taught to honour the state of the rkill
> switch and be aware of it. Maybe you have the reverse problem - the
> rest of your system needs to be taught not to switch it off.
>
> As for the datasheet - no, there aren't any obvious rfkill info (or I
> haven't read carefully - Larry will correct me). Realtek doesn't seem
> to have a problem with e-mailing it to individuals, so a few of us has
> it as well; but since they don't have it available for public download
> on their web site, I assume it was sent on good faith for private
> viewing pleasure.... and the terms of (re-)distribution is probably to
> people who show interests in improving the driver. (instead of, say,
> to competitors trying to poke holes in their hardware...).
Hin-Tak,
What does your system report as the cut label and the customer ID? If
the OEM gets to choose how the GPIO pins are wired, perhaps we can use
that info to differentiate between a value of 0x2 vs 0x4.
If anyone else has a built-in RTL8187L with a radio-kill switch, I
would appreciate getting information regarding your system. The 2
lines are as follows:
phy0: hwaddr XX:XX:XX:XX:XX:XX, RTL8187BvE V0 + rtl8225z2
rtl8187: Customer ID is 0x04
Thanks,
Larry
la, 2009-12-05 kello 12:04 +0000, Hin-Tak Leung kirjoitti:
> 2009/12/5 Antti Kaijanmäki <[email protected]>:
> > pe, 2009-12-04 kello 15:34 -0600, Larry Finger kirjoitti:
> ..
> >> I will get the same info
> >> from Hin-Tak to see if we can differentiate your two devices.
> >
> > See the attached lsusb_v.txt
>
> The only difference between yours and mine is just the USB id (8197 vs
> 8198). There is no other difference. (But it is probably unsafe to
> base any change on product id alone - there are about 5-6 variants
> even among the 3 ids
> 8187/8189 and 8197).
>
> > I looked through the reference driver and found out that indeed the GPIO
> > pin is different for some devices, mine included (0x8198).
>
> There are differences between devices even with the same id - has
> always been the case - see comment above.
The reference driver does not use product id alone. See below, it also
tests EPROM_SELECT_GPIO. I don't know if this is sufficient, but as the
driver comes from Realtek I would presume that the detection is correct.
At least they have the documentation for full EEPROM register map and
such. I haven't got the time to test the reference driver yet, but
EPROM_SELECT_GPIO could just be the difference between our chipsets.
> > r8187_core.c:L4359
> >
> > if((idProduct == 0x8197) || (idProduct == 0x8198)) {
> > priv->EEPROMSelectNewGPIO =((u8)((eprom_read(dev,EPROM_SELECT_GPIO) & 0xff00) >> 8)) ? true : false;
> > DMESG("EPROM_SELECT_GPIO:%d", priv->EEPROMSelectNewGPIO);
> > } else {
> > priv->EEPROMSelectNewGPIO = false;
> > }
> >
> >
> >
> > Here's the begining of the RFKILL code (see, 0x2 vs. 0x4!)
> >
> > r8187_core.c:L6258
> >
> > tmp1byte = read_nic_byte(dev,GPE);
> > if(priv->EEPROMSelectNewGPIO == true)
> > tmp1byte &= ~BIT2;
> > else
> > tmp1byte &= ~BIT1;
> >
> > write_nic_byte(dev,GPE,tmp1byte);
>
> I'll have a look at what this does when I find the time. What version
> of the vendor driver have you got? The last one we have is
> 26.1036.0708.2008 (mostly you just look at the 1036 part which is the
> version, and 0708.2008 is the release date). If you have a more recent
> version, you should share it with me, Larry and Herton - our e-mails
> are in the MAINTAINERS file, but you already found me and Larry, just
> Herton hasn't comment yet(?). (as I wrote, for some reason Realtek
> doesn't put it up publicly for download but seems to be happy to
> e-mail to people when they ask, so I think it is appropriate to behave
> along similiar lines).
The driver is attached to my previous email to the list.
It should be newer than yours (1055):
rtl8187B_linux_26[1][1].1055.1102.2009.release.tar.gz
-- Antti
On 12/05/2009 03:58 AM, Antti Kaijanmäki wrote:
> pe, 2009-12-04 kello 15:34 -0600, Larry Finger kirjoitti:
>> Antti,
>>
>> From our private tests, you can see my problem with making a change in
>> the rfkill handling. Most of the devices in the hands of the
>> developers do not honor the rfkill switch; however, the one that does
>> works with the current code. This code also matches the latest version
>> of the vendor drivers for the RTL8187L
>> (rtl8187L_linux_26.1038.0626.2009.release) and RTL8187B
>> (rtl8187B_linux_26.1036.0708.2008). If you have newer drivers from
>> Realtek, I would be interested in seeing them.
>
> I attached the one I received.
>
>
>> To make a special case for your system, we need to be able to
>> differentiate it from all other systems. We know that the chip has the
>> same cut (RTL8187BvE V0) as Hin-Tak's, and the same vendor ID (0x04).
>> We do have devices that require parsing additional USB data to get the
>> setup properly initialized. Please send me the full output of the
>> 'lsusb -v' command for the rtl8187 device. I will get the same info
>> from Hin-Tak to see if we can differentiate your two devices.
>
> See the attached lsusb_v.txt
>
>
> I had now some time to look in to this. First of all I was sad to
> discover that the specifications from Realtek have incomplete EEPROM
> register descriptions and they are no use to figure this problem out.
> But at least they describe the functionality so that it's easier to find
> out what's going on with the drivers.
>
> I looked through the reference driver and found out that indeed the GPIO
> pin is different for some devices, mine included (0x8198).
>
> r8187_core.c:L4359
>
> if((idProduct == 0x8197) || (idProduct == 0x8198)) {
> priv->EEPROMSelectNewGPIO =((u8)((eprom_read(dev,EPROM_SELECT_GPIO) & 0xff00) >> 8)) ? true : false;
> DMESG("EPROM_SELECT_GPIO:%d", priv->EEPROMSelectNewGPIO);
> } else {
> priv->EEPROMSelectNewGPIO = false;
> }
>
>
>
> Here's the begining of the RFKILL code (see, 0x2 vs. 0x4!)
>
> r8187_core.c:L6258
>
> tmp1byte = read_nic_byte(dev,GPE);
> if(priv->EEPROMSelectNewGPIO == true)
> tmp1byte &= ~BIT2;
> else
> tmp1byte &= ~BIT1;
>
> write_nic_byte(dev,GPE,tmp1byte);
>
>
> I would like to prepare a proper patch, but I'm afraid I do not have the
> time right now and someone else can probably do it a lot faster. The
> current rfkill code is now in 2.6.32 and some people are going to find
> out that their wlan no longer is accessible because of insufficient
> rfkill detection so this puts this somewhat higher priority.
Thanks for this info. Your reference driver is indeed newer than the
one that I had. With the info from it, I will prepare a patch for you,
Hin-Tak, and anyone else to test. It should be ready yet today.
Larry
Antti,
>From our private tests, you can see my problem with making a change in
the rfkill handling. Most of the devices in the hands of the
developers do not honor the rfkill switch; however, the one that does
works with the current code. This code also matches the latest version
of the vendor drivers for the RTL8187L
(rtl8187L_linux_26.1038.0626.2009.release) and RTL8187B
(rtl8187B_linux_26.1036.0708.2008). If you have newer drivers from
Realtek, I would be interested in seeing them.
To make a special case for your system, we need to be able to
differentiate it from all other systems. We know that the chip has the
same cut (RTL8187BvE V0) as Hin-Tak's, and the same vendor ID (0x04).
We do have devices that require parsing additional USB data to get the
setup properly initialized. Please send me the full output of the
'lsusb -v' command for the rtl8187 device. I will get the same info
from Hin-Tak to see if we can differentiate your two devices.
Thanks,
Larry
On Thu, Dec 3, 2009 at 1:33 PM, Larry Finger <[email protected]> wrote:
> What does your system report as the cut label and the customer ID? If
> the OEM gets to choose how the GPIO pins are wired, perhaps we can use
> that info to differentiate between a value of 0x2 vs 0x4.
What's the "cut label"? Your mean the "RTL8187BvE V0 + rtl8225z2"
part? Here is mine, and it seems identical to Antti's: (I just removed
my mac-address). So everything looks identical, really, I think.
phy0: Selected rate control algorithm 'minstrel'
phy0: hwaddr -----------------, RTL8187BvE V0 + rtl8225z2
rtl8187: Customer ID is 0x04
Registered led device: rtl8187-phy0::tx
Registered led device: rtl8187-phy0::rx
rtl8187: wireless switch is off
usbcore: registered new interface driver rtl8187
udev: renamed network interface wlan0 to wlan2
...
rtl8187: wireless radio switch turned on
rtl8187: wireless radio switch turned off
rtl8187: wireless radio switch turned on
rtl8187: wireless radio switch turned off
And the last few lines from playing with the rfkill switch on the laptop.
> If anyone else has a built-in RTL8187L with a radio-kill switch, I
> would appreciate getting information regarding your system. The 2
> lines are as follows:
>
> phy0: hwaddr XX:XX:XX:XX:XX:XX, RTL8187BvE V0 + rtl8225z2
> rtl8187: Customer ID is 0x04
Looks the same here.
la, 2009-12-05 kello 14:53 +0200, Antti Kaijanmäki kirjoitti:
> The reference driver does not use product id alone. See below, it also
> tests EPROM_SELECT_GPIO. I don't know if this is sufficient, but as the
> driver comes from Realtek I would presume that the detection is correct.
> At least they have the documentation for full EEPROM register map and
> such. I haven't got the time to test the reference driver yet, but
> EPROM_SELECT_GPIO could just be the difference between our chipsets.
>
>
> > > r8187_core.c:L4359
> > >
> > > if((idProduct == 0x8197) || (idProduct == 0x8198)) {
> > > priv->EEPROMSelectNewGPIO =((u8)((eprom_read(dev,EPROM_SELECT_GPIO) & 0xff00) >> 8)) ? true : false;
> > > DMESG("EPROM_SELECT_GPIO:%d", priv->EEPROMSelectNewGPIO);
> > > } else {
> > > priv->EEPROMSelectNewGPIO = false;
> > > }
I just tested the reference driver and for me it says:
rtl8187B: EPROM_SELECT_GPIO:1
And the kill switch works as it should.
Hin-Tak, when you have time could you test the reference driver, too.
-- Antti
ke, 2009-12-02 kello 10:30 -0600, Larry Finger kirjoitti:
>
> As wireless in Linux approaches the correct behavior with respect to
> killing wireless, there will be some cases like yours. Having the
> radio work no matter the switch position is just plain wrong. I hope
> you understand that.
Of course I understand! :)
Maybe I had some unintentional negative sound in my email. I only wanted
to point out that the current code is not sufficient in my case and I
want to help to get it fixed.
> What laptop do you have?
It's a Toshiba Satellite Pro L300.
> If the RTL8187 built in or externally
> plugged?
Built in.
> If built in, is there a WMI driver for it? Do you have it loaded?
I don't know. By WMI you mean Windows Management Instrumentation? I have
WinXP dualboot so the Windows driver probably supports that if present.
-- Antti
PS.
I contacted Realtek again and this morning I had data sheets for
RTL8187B and RTL8187L chipsets in my inbox, yay!. I didn't have time to
look deeply in to them just yet, but at quick glance the data sheets
didn't talk anything about rfkill. My fear is that the rfkill features
are laptop vendor specific by being implemented using the General
Purpose IO pins, but this speculation is still premature.