[rt2x00-users] [RFC/RFT 1/8] rt2x00: Introduce concept of driver data in struct rt2x00_dev.

Helmut Schaa helmut.schaa at googlemail.com
Tue Jan 31 18:47:08 AEDT 2012

On Tue, Jan 31, 2012 at 12:06 AM, Gertjan van Wingerde
<gwingerde at gmail.com> wrote:
> Hi Helmut,
> On 01/30/12 13:49, Helmut Schaa wrote:
>> On Mon, Jan 30, 2012 at 1:40 PM, Stanislaw Gruszka <sgruszka at redhat.com> wrote:
>>> On Mon, Jan 30, 2012 at 09:36:18AM +0100, Helmut Schaa wrote:
>>>> no objection to this patch :) in general, but in the long term we might
>>>> also consider a driver split like iwlwifi did some time ago. Something
>>>> like rt2x00_legacy (everything till rt61pci & rt73usb) vs rt2x00 (rt2800
>>>> and later).
>>>> This would also help to remove some complexity introduced due
>>>> to the differences between different chipsets ...
>>> I believe we can keep everything in place and still avoid complexity, and
>>> also do not duplicate large chunk of code. Intel have definitely a problem
>>> with maintaining legacy stuff, they changed common code, and do not test
>>> if it still work with legacy hardware. I hope this is not the case with
>>> rt2x00 ;-)
>> I hope so too :) but still we've got quite a number of driver/device specific
>> flags that change the behavior of the generic rt2x00 part (HT TX descriptor
>> vs legacy TX descriptor, ATIM queue vs no ATIM queue, different L2 padding
>> needs, sw sequence numbers vs hw sequence numbers ...).
>> And sometimes fixing something small for newer devices causes a
>> major redesign of the rt2x00 framework to also work for older devices
>> (clearing beacon slots for example I'm currently working on).
> I certainly would hope that we wouldn't have to make such a split, as I
> think that currently the overhead and complexity of the common code is
> not unreasonable. Most of these things are just a couple of lines of
> code, and doesn't make very complex or ugly code.
> However, we could consider it when actual complex code is coming in, though.

Ok, let's leave it as is for now :) and see what changes the next generation of
ralink devices introduces ...


More information about the users mailing list