2011-05-30 21:34:42

by Ben Hutchings

[permalink] [raw]
Subject: rtl8192se replacing rtl8192e?

I'm happy to see rtl8192se in Linux 3.0-rc1. I noticed that it claims
PCI device ID 10ec:8192, which is already claimed by staging driver
rtl8192e. Is it intended to replace that driver, or are there two
different devices with that ID which they will distinguish in their
probe functions?

If is intended to replace rtl8192e, shouldn't it also claim these device
IDs?

/* Corega */
{ PCI_DEVICE(0x07aa, 0x0044) },
{ PCI_DEVICE(0x07aa, 0x0047) },

Ben.

--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


Attachments:
signature.asc (828.00 B)
This is a digitally signed message part

2011-05-31 03:15:35

by Larry Finger

[permalink] [raw]
Subject: Re: rtl8192se replacing rtl8192e?

On 05/30/2011 04:34 PM, Ben Hutchings wrote:
> I'm happy to see rtl8192se in Linux 3.0-rc1. I noticed that it claims
> PCI device ID 10ec:8192, which is already claimed by staging driver
> rtl8192e. Is it intended to replace that driver, or are there two
> different devices with that ID which they will distinguish in their
> probe functions?
>
> If is intended to replace rtl8192e, shouldn't it also claim these device
> IDs?
>
> /* Corega */
> { PCI_DEVICE(0x07aa, 0x0044) },
> { PCI_DEVICE(0x07aa, 0x0047) },

The RTL8192E is a different device than the RTL8192SE, thus rtl8192se will not
replace rtl8192e. The way to tell them apart is the PCIe revision id. At
present, I don't have a method to use that info to load the correct driver, but
I will be working on it. In addition, I need to acquire an RTL8192E.

No, rtl8192se should not claim those Corega devices.

Larry

2011-05-31 03:20:23

by Ben Hutchings

[permalink] [raw]
Subject: Re: rtl8192se replacing rtl8192e?

On Mon, 2011-05-30 at 22:15 -0500, Larry Finger wrote:
> On 05/30/2011 04:34 PM, Ben Hutchings wrote:
> > I'm happy to see rtl8192se in Linux 3.0-rc1. I noticed that it claims
> > PCI device ID 10ec:8192, which is already claimed by staging driver
> > rtl8192e. Is it intended to replace that driver, or are there two
> > different devices with that ID which they will distinguish in their
> > probe functions?
> >
> > If is intended to replace rtl8192e, shouldn't it also claim these device
> > IDs?
> >
> > /* Corega */
> > { PCI_DEVICE(0x07aa, 0x0044) },
> > { PCI_DEVICE(0x07aa, 0x0047) },
>
> The RTL8192E is a different device than the RTL8192SE, thus rtl8192se will not
> replace rtl8192e. The way to tell them apart is the PCIe revision id. At
> present, I don't have a method to use that info to load the correct driver, but
> I will be working on it.

It doesn't matter too much if both drivers get loaded, so long as their
respective probe() functions fail cleanly and return -ENODEV when called
for the wrong device.

> In addition, I need to acquire an RTL8192E.
>
> No, rtl8192se should not claim those Corega devices.

Thanks.

Ben.

--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


Attachments:
signature.asc (828.00 B)
This is a digitally signed message part

2011-05-31 03:29:45

by Larry Finger

[permalink] [raw]
Subject: Re: rtl8192se replacing rtl8192e?

On 05/30/2011 10:20 PM, Ben Hutchings wrote:
> On Mon, 2011-05-30 at 22:15 -0500, Larry Finger wrote:
>> On 05/30/2011 04:34 PM, Ben Hutchings wrote:
>>> I'm happy to see rtl8192se in Linux 3.0-rc1. I noticed that it claims
>>> PCI device ID 10ec:8192, which is already claimed by staging driver
>>> rtl8192e. Is it intended to replace that driver, or are there two
>>> different devices with that ID which they will distinguish in their
>>> probe functions?
>>>
>>> If is intended to replace rtl8192e, shouldn't it also claim these device
>>> IDs?
>>>
>>> /* Corega */
>>> { PCI_DEVICE(0x07aa, 0x0044) },
>>> { PCI_DEVICE(0x07aa, 0x0047) },
>>
>> The RTL8192E is a different device than the RTL8192SE, thus rtl8192se will not
>> replace rtl8192e. The way to tell them apart is the PCIe revision id. At
>> present, I don't have a method to use that info to load the correct driver, but
>> I will be working on it.
>
> It doesn't matter too much if both drivers get loaded, so long as their
> respective probe() functions fail cleanly and return -ENODEV when called
> for the wrong device.

Yes, I understand the issue and I have trial patches but no hardware for testing.

Larry