2009/12/5 Antti Kaijanmäki <antti@xxxxxxxxxxxxxx>:
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
