Re: rtl8821ae.

[Malcolm Priestley]

On Sun, 2014-02-02 at 18:07 +0000, Stefan Lippers-Hollmann wrote:
> Hi
> 
> [ CC'ing the relevant parties ]
> 
> On Sunday 02 February 2014, Dave Jones wrote:
> > On Sun, Feb 02, 2014 at 03:41:27AM -0800, scan-admin@xxxxxxxxxxxx wrote:
> >  > 
> >  > Please find the latest report on new defect(s) introduced to Linux found with Coverity Scan.
> >  > 
> >  > Defect(s) Reported-by: Coverity Scan
> >  > Showing 20 of 83 defect(s)
> > 
> > Ugh, this is even worse than the usual realtek drivers. (With the exception of rtl8188eu)
> > All 83 of those new defects came from this new driver, and while there's
> > a bunch of "who cares" type things in there, there's a load of stuff that
> > needs fixing a lot more urgently than CodingStyle issues or anything else in the TODO
> > for that driver.
> > 
> > A bigger problem though, is what is the plan for these realtek drivers ?
> > They've been in staging forever. rtl8187se has been there for _five_ years with
> > no indication it's ever getting promoted to first class status.
> 
> Actually rtl8187se (aka rtl8185b) seems to have gotten some attention 
> recently:
> 
> http://lkml.kernel.org/r/CAN8YU5PGkx9s9deWpFTO_ZtDr-+wDD5cX2JRv1zd1m1Q0BpkCw@xxxxxxxxxxxxxx
> 
> > The git logs are littered mostly with CodingStyle cleanups, sparse cleanups and such,
> > meanwhile for five years they've had out of bounds reads, overflows, and such 
> > for this whole time.  Even worse, when one of the drivers gets fixes for actual
> > problems like this, they never make it back to Realtek, who clone the same
> > old shitty driver they shipped last time, and reintroduce new variants of the
> > same damn bugs, and then we import the new turd into staging and start all over again.
> > 
> > I get the whole "a shit driver is better than no driver", but there's no discernable
> > effort to ever improve this pile, just to keep adding to it.
> > 
> > 	Dave
> 
> I think there are mostly two major problems with these drivers, besides 
> RealTek still working on a non-mac80211 codebase for USB based devices.
> 
> The sheer number of slightly different RealTek drivers for similar
> chipsets, for which RealTek as forked off a dedicated driver each, 
> rather than extending the existing ones. With the other, probably even 
> larger, problem being that it isn't possible to port wireless drivers
> from non-mac80111 to mac80211 in a gradual fashion, it's always a 
> parallel re-implementation. Just look at the recent history of staging
> wireless drivers:
> 
> the successful ones:
> - csr --> /dev/null
> - otus --> ar9170 --> carl9170
> - ( rt2870 && rt3070 ) --> rt2800usb
> - rt2870 --> rt2800pci
> - [ at76c503a --> ] at76_usb --> at76c50x-usb   [*] not in staging
> 
> the pending ones
> - rtl8187se [ --> rtl8180 ]   [*] hopefully soon
> - rtl8188eu --> ?
> - [ rtl8192du --> ? ]   [*] not in staging, [1]
> - rtl8192e --> ?
> - rtl8192u --> ?
> - rtl8192su --> rtl8712 --> ? [ r92su[2] would add cfg80211 support, 
>                                 but it being a fullmac like
>                                 re-implementation doesn't get it 
>                                 anywhere ]
> - rtl8821ae [ --> mac80211 port planned for 3.15[3]? ]
> 
> these devices are, besides rtl8187se (802.11g) and rtl8821ae 
> (802.11ac), all 802.11n compatible, but were quickly EOLed by the 
> vendor, probably making it hard to get enough traction for a proper 
> mac80211 port. Coincidentally these chipsets are also very popular, 
> rtl8187se being the chipset of the early netbook craze, rtl8188eu 
> pretty ubiquitous on embedded platforms, the others making the bulk 
> of aftermarket USB devices.
> 
> ancient hardware, probably not going anywhere:
The below devices are still been sold new
> - vt6655 --> ?
> - vt6656 --> ?
to mac80211

I have already done the conversion, just some minor things todo
LED/ host implementation

Should be ready to merge next + 3-4.

I will update the TODO file shortly.

> - wlags49_h2 --> ?
> - wlags49_h25 --> ?
> - wlan-ng --> ?
> 
> This likely leaves staging wireless drivers to small corrections and 
> bugfixes. In the hope that the devices will get enough traction that 
> someone takes up the effort of doing a parallel re-implementation of a
> proper mac80211 based driver, using the staging source only as 
> reference.
> 
For my part, it is an educational exercise.

However, I do wonder why I don't simply submit a new driver. There
is very little of the staging code left.

Regards


Malcolm


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/