Re: rtl8821ae.
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-ad...@coverity.com 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-+wdd5cx2jrv1zd1m1q0bp...@mail.gmail.com > 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: - vt6655 --> ? - vt6656 --> ? - 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. Regards Stefan Lippers-Hollmann [1] https://github.com/lwfinger/rtl8192du [2] https://github.com/chunkeey/rtl8192su/tree/master/r92su [3] http://lkml.kernel.org/r/52e066a1.9010...@lwfinger.net http://lkml.kernel.org/r/52e7d9f6.5070...@lwfinger.net ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: rtl8821ae.
On Sun, 2014-02-02 at 18:07 +, 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-ad...@coverity.com 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-+wdd5cx2jrv1zd1m1q0bp...@mail.gmail.com > > > 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 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: r8188eu: Fix typo in USB_DEVICE list
There is a typo in the device list that interchanges the vendor and
product codes for one of the entries.
Signed-off-by: Larry Finger
---
drivers/staging/rtl8188eu/os_dep/usb_intf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8188eu/os_dep/usb_intf.c
b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
index 0a341d6..e9e3c76 100644
--- a/drivers/staging/rtl8188eu/os_dep/usb_intf.c
+++ b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
@@ -53,7 +53,7 @@ static struct usb_device_id rtw_usb_id_tbl[] = {
{USB_DEVICE(USB_VENDER_ID_REALTEK, 0x0179)}, /* 8188ETV */
/*=== Customer ID ===*/
/** 8188EUS /
- {USB_DEVICE(0x8179, 0x07B8)}, /* Abocom - Abocom */
+ {USB_DEVICE(0x07bb, 0x8179)}, /* Abocom - Abocom */
{USB_DEVICE(0x2001, 0x330F)}, /* DLink DWA-125 REV D1 */
{} /* Terminating entry */
};
--
1.8.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: r8188eu: Fix typo in USB_DEVICE list
On 02/02/2014 12:07 PM, Larry Finger wrote:
> There is a typo in the device list that interchanges the vendor and
> product codes for one of the entries.
You also changed 0x7b8 to 0x7bb.
Did you mean to do that?
> Signed-off-by: Larry Finger
> ---
> drivers/staging/rtl8188eu/os_dep/usb_intf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/rtl8188eu/os_dep/usb_intf.c
> b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
> index 0a341d6..e9e3c76 100644
> --- a/drivers/staging/rtl8188eu/os_dep/usb_intf.c
> +++ b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
> @@ -53,7 +53,7 @@ static struct usb_device_id rtw_usb_id_tbl[] = {
> {USB_DEVICE(USB_VENDER_ID_REALTEK, 0x0179)}, /* 8188ETV */
> /*=== Customer ID ===*/
> /** 8188EUS /
> - {USB_DEVICE(0x8179, 0x07B8)}, /* Abocom - Abocom */
> + {USB_DEVICE(0x07bb, 0x8179)}, /* Abocom - Abocom */
> {USB_DEVICE(0x2001, 0x330F)}, /* DLink DWA-125 REV D1 */
> {} /* Terminating entry */
> };
>
--
~Randy
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: r8188eu: Fix typo in USB_DEVICE list
On 02/02/2014 03:04 PM, Randy Dunlap wrote: On 02/02/2014 12:07 PM, Larry Finger wrote: There is a typo in the device list that interchanges the vendor and product codes for one of the entries. You also changed 0x7b8 to 0x7bb. Did you mean to do that? No, I did not. Thanks for catching that typo. Larry ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: r8188eu: Fix typo in USB_DEVICE list
On Sun, Feb 02, 2014 at 02:07:06PM -0600, Larry Finger wrote:
> There is a typo in the device list that interchanges the vendor and
> product codes for one of the entries.
>
> Signed-off-by: Larry Finger
> ---
> drivers/staging/rtl8188eu/os_dep/usb_intf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/rtl8188eu/os_dep/usb_intf.c
> b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
> index 0a341d6..e9e3c76 100644
> --- a/drivers/staging/rtl8188eu/os_dep/usb_intf.c
> +++ b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
> @@ -53,7 +53,7 @@ static struct usb_device_id rtw_usb_id_tbl[] = {
> {USB_DEVICE(USB_VENDER_ID_REALTEK, 0x0179)}, /* 8188ETV */
> /*=== Customer ID ===*/
> /** 8188EUS /
> - {USB_DEVICE(0x8179, 0x07B8)}, /* Abocom - Abocom */
> + {USB_DEVICE(0x07bb, 0x8179)}, /* Abocom - Abocom */
Becides the b8 -> bb issue, are you sure this is correct? I've seen
lots of USB devices that got this backwards (vendor id in the product id
place), so it wouldn't be the first time it's happened.
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: r8188eu: Fix typo in USB_DEVICE list
On 02/02/2014 03:26 PM, Greg KH wrote:
On Sun, Feb 02, 2014 at 02:07:06PM -0600, Larry Finger wrote:
There is a typo in the device list that interchanges the vendor and
product codes for one of the entries.
Signed-off-by: Larry Finger
---
drivers/staging/rtl8188eu/os_dep/usb_intf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8188eu/os_dep/usb_intf.c
b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
index 0a341d6..e9e3c76 100644
--- a/drivers/staging/rtl8188eu/os_dep/usb_intf.c
+++ b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
@@ -53,7 +53,7 @@ static struct usb_device_id rtw_usb_id_tbl[] = {
{USB_DEVICE(USB_VENDER_ID_REALTEK, 0x0179)}, /* 8188ETV */
/*=== Customer ID ===*/
/** 8188EUS /
- {USB_DEVICE(0x8179, 0x07B8)}, /* Abocom - Abocom */
+ {USB_DEVICE(0x07bb, 0x8179)}, /* Abocom - Abocom */
Becides the b8 -> bb issue, are you sure this is correct? I've seen
lots of USB devices that got this backwards (vendor id in the product id
place), so it wouldn't be the first time it's happened.
The listing at http://www.linux-usb.org/usb.ids shows that the vendor code for
AboCom Systems Inc is 0x07b8. Although it does not show a device id of 0x8179,
I'm pretty sure that this listing has reversed the two entries.
Larry
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH V2] staging: r8188eu: Fix typo in USB_DEVICE list
There is a typo in the device list that interchanges the vendor and
product codes for one of the entries. This exchange was determined
by noticing that the vendor code is 0x07b8 for Abocom at
http://www.linux-usb.org/usb.ids.
Signed-off-by: Larry Finger
---
V2 - fix typo in revised version that was spotted by Randy Dunlap.
---
drivers/staging/rtl8188eu/os_dep/usb_intf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8188eu/os_dep/usb_intf.c
b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
index 0a341d6..a70dcef 100644
--- a/drivers/staging/rtl8188eu/os_dep/usb_intf.c
+++ b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
@@ -53,7 +53,7 @@ static struct usb_device_id rtw_usb_id_tbl[] = {
{USB_DEVICE(USB_VENDER_ID_REALTEK, 0x0179)}, /* 8188ETV */
/*=== Customer ID ===*/
/** 8188EUS /
- {USB_DEVICE(0x8179, 0x07B8)}, /* Abocom - Abocom */
+ {USB_DEVICE(0x07b8, 0x8179)}, /* Abocom - Abocom */
{USB_DEVICE(0x2001, 0x330F)}, /* DLink DWA-125 REV D1 */
{} /* Terminating entry */
};
--
1.8.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
