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
Attachment:
rtl8187B_linux_26[1][1].1055.1102.2009.release.tar.gz
Description: application/compressed-tar
Bus 002 Device 002: ID 0bda:8198 Realtek Semiconductor Corp.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x0bda Realtek Semiconductor Corp.
idProduct 0x8198
bcdDevice 2.00
iManufacturer 1 Manufacturer_Realtek
iProduct 2
iSerial 3 00e04c000001
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 81
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 4 Wireless Network Card
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 9
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 2
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x05 EP 5 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x06 EP 6 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x07 EP 7 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x89 EP 9 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x0a EP 10 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x0b EP 11 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x0c EP 12 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0000
(Bus Powered)
Attachment:
signature.asc
Description: Digitaalisesti allekirjoitettu viestin osa
