| Message ID | 20160719153403.2967812-2-arnd@arndb.de (mailing list archive) |
|---|---|
| State | Not Applicable |
| Delegated to: | Kalle Valo |
| Headers | show |
Arnd Bergmann <arnd@arndb.de> writes: > Compiling the rtlwifi drivers for ARM with gcc -Wextra warns about lots of > incorrect code that results from 'char' being unsigned here, e.g. > > staging/rtl8192e/rtl8192e/r8192E_phy.c:1072:36: error: comparison is always false due to limited range of data type [-Werror=type-limits] > staging/rtl8192e/rtl8192e/r8192E_phy.c:1104:36: error: comparison is always false due to limited range of data type [-Werror=type-limits] > staging/rtl8192e/rtl8192e/rtl_core.c:1987:16: error: comparison is always false due to limited range of data type [-Werror=type-limits] > staging/rtl8192e/rtl8192e/rtl_dm.c:782:37: error: comparison is always false due to limited range of data type [-Werror=type-limits] > staging/rtl8192e/rtl819x_TSProc.c:326:14: error: comparison is always true due to limited range of data type [-Werror=type-limits] > staging/rtl8192e/rtllib_softmac_wx.c:465:16: error: comparison is always false due to limited range of data type [-Werror=type-limits] > > This patch changes all uses of 'char' in this driver that refer to > 8-bit integers to use 's8' instead, which is signed on all architectures. > > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > --- > drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c | 8 ++++---- > drivers/staging/rtl8192e/rtl8192e/r8192E_phy.c | 2 +- > drivers/staging/rtl8192e/rtl8192e/rtl_core.c | 6 +++--- > drivers/staging/rtl8192e/rtl8192e/rtl_core.h | 8 ++++---- > drivers/staging/rtl8192e/rtl819x_TSProc.c | 2 +- > 5 files changed, 13 insertions(+), 13 deletions(-) > Most of this looks fine to me. One issue stands out which I don't think is right: > diff --git a/drivers/staging/rtl8192e/rtl819x_TSProc.c b/drivers/staging/rtl8192e/rtl819x_TSProc.c > index 2c8a526773ed..e0a2fe5e6148 100644 > --- a/drivers/staging/rtl8192e/rtl819x_TSProc.c > +++ b/drivers/staging/rtl8192e/rtl819x_TSProc.c > @@ -323,7 +323,7 @@ bool GetTs(struct rtllib_device *ieee, struct ts_common_info **ppTS, > if (ieee->current_network.qos_data.supported == 0) { > UP = 0; > } else { > - if (!IsACValid(TID)) { > + if (!IsACValid((s8)TID)) { > netdev_warn(ieee->dev, "%s(): TID(%d) is not valid\n", > __func__, TID); > return false; TID is a 4-bit field, it should never go negative. The cast to s8 seems wrong to me, if anything it should be using u8. I do realize the macro IsACValid checks against negative too, but that just looks silly to me. Cheers, Jes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tuesday, July 19, 2016 11:46:04 AM CEST Jes Sorensen wrote: > > diff --git a/drivers/staging/rtl8192e/rtl819x_TSProc.c b/drivers/staging/rtl8192e/rtl819x_TSProc.c > > index 2c8a526773ed..e0a2fe5e6148 100644 > > --- a/drivers/staging/rtl8192e/rtl819x_TSProc.c > > +++ b/drivers/staging/rtl8192e/rtl819x_TSProc.c > > @@ -323,7 +323,7 @@ bool GetTs(struct rtllib_device *ieee, struct ts_common_info **ppTS, > > if (ieee->current_network.qos_data.supported == 0) { > > UP = 0; > > } else { > > - if (!IsACValid(TID)) { > > + if (!IsACValid((s8)TID)) { > > netdev_warn(ieee->dev, "%s(): TID(%d) is not valid\n", > > __func__, TID); > > return false; > > TID is a 4-bit field, it should never go negative. The cast to s8 seems > wrong to me, if anything it should be using u8. I do realize the macro > IsACValid checks against negative too, but that just looks silly to me. Ok, I'll remove the extra comparison then to avoid the warning: staging/rtl8192e/rtl819x_TSProc.c:326:14: error: comparison is always true due to limited range of data type [-Werror=type-limits] I guess it should be a separate patch. I had just stumbled over the same thing before resending the patch but decided not to change it to keep the patch simple. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Arnd Bergmann <arnd@arndb.de> writes: > On Tuesday, July 19, 2016 11:46:04 AM CEST Jes Sorensen wrote: >> > diff --git a/drivers/staging/rtl8192e/rtl819x_TSProc.c b/drivers/staging/rtl8192e/rtl819x_TSProc.c >> > index 2c8a526773ed..e0a2fe5e6148 100644 >> > --- a/drivers/staging/rtl8192e/rtl819x_TSProc.c >> > +++ b/drivers/staging/rtl8192e/rtl819x_TSProc.c >> > @@ -323,7 +323,7 @@ bool GetTs(struct rtllib_device *ieee, struct ts_common_info **ppTS, >> > if (ieee->current_network.qos_data.supported == 0) { >> > UP = 0; >> > } else { >> > - if (!IsACValid(TID)) { >> > + if (!IsACValid((s8)TID)) { >> > netdev_warn(ieee->dev, "%s(): TID(%d) is not valid\n", >> > __func__, TID); >> > return false; >> >> TID is a 4-bit field, it should never go negative. The cast to s8 seems >> wrong to me, if anything it should be using u8. I do realize the macro >> IsACValid checks against negative too, but that just looks silly to me. > > Ok, I'll remove the extra comparison then to avoid the warning: > > staging/rtl8192e/rtl819x_TSProc.c:326:14: error: comparison is always > true due to limited range of data type [-Werror=type-limits] > > I guess it should be a separate patch. I had just stumbled over the > same thing before resending the patch but decided not to change it > to keep the patch simple. I think that would be better, albeit not a big issue. I'd like to get rid of all the drivers/staging/rtl* drivers eventually :) Cheers, Jes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tuesday, July 19, 2016 12:05:00 PM CEST Jes Sorensen wrote: > Arnd Bergmann <arnd@arndb.de> writes: > > On Tuesday, July 19, 2016 11:46:04 AM CEST Jes Sorensen wrote: > >> > diff --git a/drivers/staging/rtl8192e/rtl819x_TSProc.c b/drivers/staging/rtl8192e/rtl819x_TSProc.c > >> > index 2c8a526773ed..e0a2fe5e6148 100644 > >> > --- a/drivers/staging/rtl8192e/rtl819x_TSProc.c > >> > +++ b/drivers/staging/rtl8192e/rtl819x_TSProc.c > >> > @@ -323,7 +323,7 @@ bool GetTs(struct rtllib_device *ieee, struct ts_common_info **ppTS, > >> > if (ieee->current_network.qos_data.supported == 0) { > >> > UP = 0; > >> > } else { > >> > - if (!IsACValid(TID)) { > >> > + if (!IsACValid((s8)TID)) { > >> > netdev_warn(ieee->dev, "%s(): TID(%d) is not valid\n", > >> > __func__, TID); > >> > return false; > >> > >> TID is a 4-bit field, it should never go negative. The cast to s8 seems > >> wrong to me, if anything it should be using u8. I do realize the macro > >> IsACValid checks against negative too, but that just looks silly to me. > > > > Ok, I'll remove the extra comparison then to avoid the warning: > > > > staging/rtl8192e/rtl819x_TSProc.c:326:14: error: comparison is always > > true due to limited range of data type [-Werror=type-limits] > > > > I guess it should be a separate patch. I had just stumbled over the > > same thing before resending the patch but decided not to change it > > to keep the patch simple. > > I think that would be better, albeit not a big issue. Ok, and since Kalle applied the first patch to his tree, I'm now sending a series of three patches that are all for Greg, which also avoids some possible confusion. > I'd like to get rid of all the drivers/staging/rtl* drivers eventually That would be great, yes. Can you clarify what the long-term plan is? I see that drivers/net/wireless/realtek/rtlwifi/ has most of the PCIe parts and one USB device (rtl8192cu/rtl8188cus) while drivers/net/wireless/rtl8xxx has all the USB parts including that one. Does that mean we want the staging drivers for PCIe devices to get merged into rtlwifi, and the remaining USB drivers to get replaced by r8xxxu? As one data point that I can provide (but you are probably aware of), I could never get my rtl8188cus stick to work with rtlwifi, but I found the older r8712u device to work fine with the staging/rtl8712 driver. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Arnd Bergmann <arnd@arndb.de> writes: > On Tuesday, July 19, 2016 12:05:00 PM CEST Jes Sorensen wrote: >> Arnd Bergmann <arnd@arndb.de> writes: >> I think that would be better, albeit not a big issue. > > Ok, and since Kalle applied the first patch to his tree, I'm now sending > a series of three patches that are all for Greg, which also avoids some > possible confusion. Awesome! >> I'd like to get rid of all the drivers/staging/rtl* drivers eventually > > That would be great, yes. > > Can you clarify what the long-term plan is? I see that > drivers/net/wireless/realtek/rtlwifi/ has most of the PCIe parts > and one USB device (rtl8192cu/rtl8188cus) while > drivers/net/wireless/rtl8xxx has all the USB parts including > that one. > > Does that mean we want the staging drivers for PCIe devices > to get merged into rtlwifi, and the remaining USB drivers to get > replaced by r8xxxu? Well it really all depends on how much time I have and how much others step up and help contribute to the code. For rtl8xxxu my plans are as follows: 1) rtl8188eu support, since this is the most widely distributed USB dongle which isn't currently supported by a non staging driver. I am currently working on this together with Andrea Merello. 2) Beacon support for IBSS and AP mode - hopefully this should make it possible to default rtl8xxxu for rtl8192cu/rtl8188cu devices and disable them in rtlwifi. 3) SDIO device support 4) PCI device support 5) 802.11ac device support 3/4/5 not necessarily in that order. There really is no reason why rtl8xxxu shouldn't have SDIO and PCI device support added so the core code can be shared. > As one data point that I can provide (but you are probably > aware of), I could never get my rtl8188cus stick to work with > rtlwifi, but I found the older r8712u device to work fine with > the staging/rtl8712 driver. I'd love to hear if the rtl8188cus works better with rtl8xxxu. For the rtl8712 device, rtl8192su?, then potentially that could be added to rtl8xxxu as well, but it's not a top priority on my list right now. Cheers, Jes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 07/20/2016 06:25 AM, Jes Sorensen wrote: > Arnd Bergmann <arnd@arndb.de> writes: >> On Tuesday, July 19, 2016 12:05:00 PM CEST Jes Sorensen wrote: >>> Arnd Bergmann <arnd@arndb.de> writes: >>> I think that would be better, albeit not a big issue. >> >> Ok, and since Kalle applied the first patch to his tree, I'm now sending >> a series of three patches that are all for Greg, which also avoids some >> possible confusion. > > Awesome! > >>> I'd like to get rid of all the drivers/staging/rtl* drivers eventually >> >> That would be great, yes. >> >> Can you clarify what the long-term plan is? I see that >> drivers/net/wireless/realtek/rtlwifi/ has most of the PCIe parts >> and one USB device (rtl8192cu/rtl8188cus) while >> drivers/net/wireless/rtl8xxx has all the USB parts including >> that one. >> >> Does that mean we want the staging drivers for PCIe devices >> to get merged into rtlwifi, and the remaining USB drivers to get >> replaced by r8xxxu? > > Well it really all depends on how much time I have and how much others > step up and help contribute to the code. For rtl8xxxu my plans are as > follows: > > 1) rtl8188eu support, since this is the most widely distributed USB > dongle which isn't currently supported by a non staging driver. I am > currently working on this together with Andrea Merello. > > 2) Beacon support for IBSS and AP mode - hopefully this should make it > possible to default rtl8xxxu for rtl8192cu/rtl8188cu devices and disable > them in rtlwifi. > > 3) SDIO device support > > 4) PCI device support > > 5) 802.11ac device support > > 3/4/5 not necessarily in that order. There really is no reason why > rtl8xxxu shouldn't have SDIO and PCI device support added so the core > code can be shared. > >> As one data point that I can provide (but you are probably >> aware of), I could never get my rtl8188cus stick to work with >> rtlwifi, but I found the older r8712u device to work fine with >> the staging/rtl8712 driver. > > I'd love to hear if the rtl8188cus works better with rtl8xxxu. For the > rtl8712 device, rtl8192su?, then potentially that could be added to > rtl8xxxu as well, but it's not a top priority on my list right now. I would be very pleased to eliminate all the rtl* drivers from staging, particularly the USB varieties. I have been very disappointed with the USB group at Realtek. They dropped rtl8192cu on me, and then have provided no support. As I know nothing of the chip internals, there has been little I could do to improve the driver. In addition, they have never implemented any of the code improvements in any new USB drivers. Jes has done a wonderful job of making sense of the crap drivers from Realtek, and rtl8xxxu is a very good start. Adding SDIO support for the RTL8723BS would be a plus. At the moment, there is only an out-of-tree driver at GitHub, which I refuse to submit to staging. At the moment, it appears that every tablet with this chip needs special treatment. In addition, the SDIO support seems to be buggy. The drivers in question and my comments are as follows: rtl8712u and rtl8188eu - replaced by new code in rtl8xxxu. rtl8723au - already in rtl8xxxu rtl8192e - This chip is so rarely used that it does not make much difference what we do. If someone wants to integrate it into rtlwifi, I would have no objection, but I do not expect to contribute to the effort. rtl8192u - This one is even rarer. I have no sample, thus I would be unable to test. rtl8192cu - Replace with rtl8xxxu as soon as the new driver supports beacons. Good riddance. Larry -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wednesday, July 20, 2016 7:25:19 AM CEST Jes Sorensen wrote: > Arnd Bergmann <arnd@arndb.de> writes: > >> I'd like to get rid of all the drivers/staging/rtl* drivers eventually > > > > That would be great, yes. > > > > Can you clarify what the long-term plan is? I see that > > drivers/net/wireless/realtek/rtlwifi/ has most of the PCIe parts > > and one USB device (rtl8192cu/rtl8188cus) while > > drivers/net/wireless/rtl8xxx has all the USB parts including > > that one. > > > > Does that mean we want the staging drivers for PCIe devices > > to get merged into rtlwifi, and the remaining USB drivers to get > > replaced by r8xxxu? > > Well it really all depends on how much time I have and how much others > step up and help contribute to the code. For rtl8xxxu my plans are as > follows: > > 1) rtl8188eu support, since this is the most widely distributed USB > dongle which isn't currently supported by a non staging driver. I am > currently working on this together with Andrea Merello. Ok, cool. > 2) Beacon support for IBSS and AP mode - hopefully this should make it > possible to default rtl8xxxu for rtl8192cu/rtl8188cu devices and disable > them in rtlwifi. Do we have any indication that those two actually work in rtlwifi at the moment? My experience seems to match the recommendations for all the raspberry pi users that use yet another (worse looking) driver: https://github.com/raspberrypi/linux/commit/9ee31007a5032a3afe2fcb20c36b34f0ad57df56 > 3) SDIO device support > > 4) PCI device support > > 5) 802.11ac device support > > 3/4/5 not necessarily in that order. There really is no reason why > rtl8xxxu shouldn't have SDIO and PCI device support added so the core > code can be shared. Ok, got it. > > As one data point that I can provide (but you are probably > > aware of), I could never get my rtl8188cus stick to work with > > rtlwifi, but I found the older r8712u device to work fine with > > the staging/rtl8712 driver. > > I'd love to hear if the rtl8188cus works better with rtl8xxxu. It took me far too long to get the driver running on my machine (all my fault), but I've tested it now. Unfortunately there is something very wrong with my home wireless network at the moment, so I can only confirm that it doesn't work any worse than my Intel Wireless card on 2.4GHz, but that isn't any good (5GHz devices are fine, but that doesn't help on a 2.4GHz-only device). This is what I see in the kernel log [ 773.862848] usb 2-1.2: new high-speed USB device number 8 using ehci-pci [ 773.957415] usb 2-1.2: New USB device found, idVendor=0bda, idProduct=8176 [ 773.957425] usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 773.957430] usb 2-1.2: Manufacturer: Realtek [ 773.957433] usb 2-1.2: SerialNumber: 00e04c000001 [ 774.115182] usb 2-1.2: Vendor: Realtek [ 774.115192] usb 2-1.2: Product: [ 774.115199] usb 2-1.2: rtl8192cu_parse_efuse: dumping efuse (0x80 bytes): [ 774.115206] usb 2-1.2: 00: 29 81 00 74 ed 00 00 00 [ 774.115212] usb 2-1.2: 08: ff 00 da 0b 76 81 01 41 [ 774.115219] usb 2-1.2: 10: 32 00 85 62 7e ad 5c f3 [ 774.115225] usb 2-1.2: 18: 70 15 9c b1 0a 03 52 65 [ 774.115231] usb 2-1.2: 20: 61 6c 74 65 6b 00 02 03 [ 774.115237] usb 2-1.2: 28: 00 00 00 00 00 00 00 00 [ 774.115242] usb 2-1.2: 30: 00 00 00 00 00 00 00 00 [ 774.115248] usb 2-1.2: 38: 00 00 00 00 00 00 00 00 [ 774.115254] usb 2-1.2: 40: 00 00 00 00 00 00 00 00 [ 774.115260] usb 2-1.2: 48: 00 00 00 00 00 00 00 00 [ 774.115265] usb 2-1.2: 50: 00 00 00 00 00 00 00 00 [ 774.115271] usb 2-1.2: 58: 06 00 2a 2a 2a 00 00 00 [ 774.115277] usb 2-1.2: 60: 2a 2a 2a 00 00 00 00 00 [ 774.115283] usb 2-1.2: 68: 00 00 00 00 04 04 04 00 [ 774.115289] usb 2-1.2: 70: 00 00 00 00 00 00 05 00 [ 774.115295] usb 2-1.2: 78: 10 00 00 00 36 00 00 00 [ 774.115302] usb 2-1.2: RTL8188CU rev A (TSMC) 1T1R, TX queues 2, WiFi=1, BT=0, GPS=0, HI PA=0 [ 774.115308] usb 2-1.2: RTL8188CU MAC: 5c:f3:70:15:9c:b1 [ 774.115314] usb 2-1.2: rtl8xxxu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin [ 774.115409] usb 2-1.2: Firmware revision 80.0 (signature 0x88c1) [ 775.692344] rtl8xxxu 2-1.2:1.0 wlan1: renamed from wlan0 [ 775.721151] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready [ 775.746653] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready [ 775.798780] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready [ 788.414618] wlan2: authenticate with 22:4e:7f:6f:5b:3c [ 788.452485] wlan2: send auth to 22:4e:7f:6f:5b:3c (try 1/3) [ 788.457926] wlan2: authenticated [ 788.462261] wlan2: associate with 22:4e:7f:6f:5b:3c (try 1/3) [ 788.475159] wlan2: RX AssocResp from 22:4e:7f:6f:5b:3c (capab=0x431 status=0 aid=1) [ 788.504683] wlan2: associated throughput for me is 2mbit/s, compared to my intel 2x2 wireless that gets 5mbit/s on the same network, but I guess that doesn't really mean much as long as I have problems with the infrastructure. rtl8xxxu IEEE 802.11 ESSID:"openwrt24-ab" Mode:Managed Frequency:2.462 GHz Access Point: 22:4E:7F:6F:5B:3C Bit Rate=54 Mb/s Tx-Power=20 dBm Retry short limit:7 RTS thr=2347 B Fragment thr:off Power Management:off Link Quality=47/70 Signal level=-63 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:38 Missed beacon:0 iwlwifi IEEE 802.11 ESSID:"openwrt24-ab" Mode:Managed Frequency:2.462 GHz Access Point: 22:4E:7F:6F:5B:3C Bit Rate=54 Mb/s Tx-Power=15 dBm Retry short limit:7 RTS thr:off Fragment thr:off Power Management:on Link Quality=65/70 Signal level=-45 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:90 Invalid misc:146 Missed beacon:0 > For the rtl8712 device, rtl8192su?, then potentially that could be added to > rtl8xxxu as well, but it's not a top priority on my list right now. This one: Bus 001 Device 033: ID 0bda:8171 Realtek Semiconductor Corp. RTL8188SU 802.11n WLAN Adapter I bought the rtl8188su a while ago, while the rtl8188cus (0bda:8176) is from this year. According to https://wikidevi.com/wiki/Realtek, it seems to be one year older than the rtl8188cus and was almost as common in its day. Apparently everyone that used to make ...su device replaced it with a ...cu or the newer ...eu chips and that is all you can buy these days on the low end. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Arnd Bergmann <arnd@arndb.de> writes: > On Wednesday, July 20, 2016 7:25:19 AM CEST Jes Sorensen wrote: >> Arnd Bergmann <arnd@arndb.de> writes: >> Well it really all depends on how much time I have and how much others >> step up and help contribute to the code. For rtl8xxxu my plans are as >> follows: >> >> 1) rtl8188eu support, since this is the most widely distributed USB >> dongle which isn't currently supported by a non staging driver. I am >> currently working on this together with Andrea Merello. > > Ok, cool. > >> 2) Beacon support for IBSS and AP mode - hopefully this should make it >> possible to default rtl8xxxu for rtl8192cu/rtl8188cu devices and disable >> them in rtlwifi. > > Do we have any indication that those two actually work in rtlwifi at the > moment? My experience seems to match the recommendations for all the > raspberry pi users that use yet another (worse looking) driver: > > https://github.com/raspberrypi/linux/commit/9ee31007a5032a3afe2fcb20c36b34f0ad57df56 I am not really authoritative on that one. I tried it in station mode and it didn't work well for me. I never played with AP mode - It may work better in IBSS or AP mode than it does in station mode. I don't like to pull the rug away under people, which is why I haven't pushed for this. >> > As one data point that I can provide (but you are probably >> > aware of), I could never get my rtl8188cus stick to work with >> > rtlwifi, but I found the older r8712u device to work fine with >> > the staging/rtl8712 driver. >> >> I'd love to hear if the rtl8188cus works better with rtl8xxxu. > > It took me far too long to get the driver running on my machine (all my fault), > but I've tested it now. Unfortunately there is something very wrong > with my home wireless network at the moment, so I can only confirm > that it doesn't work any worse than my Intel Wireless card on 2.4GHz, > but that isn't any good (5GHz devices are fine, but that doesn't > help on a 2.4GHz-only device). > > This is what I see in the kernel log > > [ 773.862848] usb 2-1.2: new high-speed USB device number 8 using ehci-pci > [ 773.957415] usb 2-1.2: New USB device found, idVendor=0bda, idProduct=8176 > [ 773.957425] usb 2-1.2: New USB device strings: Mfr=1, Product=2, > SerialNumber=3 > [ 773.957430] usb 2-1.2: Manufacturer: Realtek > [ 773.957433] usb 2-1.2: SerialNumber: 00e04c000001 > [ 774.115182] usb 2-1.2: Vendor: Realtek > [ 774.115192] usb 2-1.2: Product: > [ 774.115199] usb 2-1.2: rtl8192cu_parse_efuse: dumping efuse (0x80 bytes): > [ 774.115206] usb 2-1.2: 00: 29 81 00 74 ed 00 00 00 > [ 774.115212] usb 2-1.2: 08: ff 00 da 0b 76 81 01 41 > [ 774.115219] usb 2-1.2: 10: 32 00 85 62 7e ad 5c f3 > [ 774.115225] usb 2-1.2: 18: 70 15 9c b1 0a 03 52 65 > [ 774.115231] usb 2-1.2: 20: 61 6c 74 65 6b 00 02 03 > [ 774.115237] usb 2-1.2: 28: 00 00 00 00 00 00 00 00 > [ 774.115242] usb 2-1.2: 30: 00 00 00 00 00 00 00 00 > [ 774.115248] usb 2-1.2: 38: 00 00 00 00 00 00 00 00 > [ 774.115254] usb 2-1.2: 40: 00 00 00 00 00 00 00 00 > [ 774.115260] usb 2-1.2: 48: 00 00 00 00 00 00 00 00 > [ 774.115265] usb 2-1.2: 50: 00 00 00 00 00 00 00 00 > [ 774.115271] usb 2-1.2: 58: 06 00 2a 2a 2a 00 00 00 > [ 774.115277] usb 2-1.2: 60: 2a 2a 2a 00 00 00 00 00 > [ 774.115283] usb 2-1.2: 68: 00 00 00 00 04 04 04 00 > [ 774.115289] usb 2-1.2: 70: 00 00 00 00 00 00 05 00 > [ 774.115295] usb 2-1.2: 78: 10 00 00 00 36 00 00 00 > [ 774.115302] usb 2-1.2: RTL8188CU rev A (TSMC) 1T1R, TX queues 2, > WiFi=1, BT=0, GPS=0, HI PA=0 > [ 774.115308] usb 2-1.2: RTL8188CU MAC: 5c:f3:70:15:9c:b1 > [ 774.115314] usb 2-1.2: rtl8xxxu: Loading firmware > rtlwifi/rtl8192cufw_TMSC.bin > [ 774.115409] usb 2-1.2: Firmware revision 80.0 (signature 0x88c1) > [ 775.692344] rtl8xxxu 2-1.2:1.0 wlan1: renamed from wlan0 > [ 775.721151] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready > [ 775.746653] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready > [ 775.798780] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready > [ 788.414618] wlan2: authenticate with 22:4e:7f:6f:5b:3c > [ 788.452485] wlan2: send auth to 22:4e:7f:6f:5b:3c (try 1/3) > [ 788.457926] wlan2: authenticated > [ 788.462261] wlan2: associate with 22:4e:7f:6f:5b:3c (try 1/3) > [ 788.475159] wlan2: RX AssocResp from 22:4e:7f:6f:5b:3c (capab=0x431 > status=0 aid=1) > [ 788.504683] wlan2: associated That all looks reasonable to me. > throughput for me is 2mbit/s, compared to my intel 2x2 wireless that gets > 5mbit/s on the same network, but I guess that doesn't really mean much > as long as I have problems with the infrastructure. :) Note the rtl8xxxu driver doesn't report speeds properly to NetworkMangler or 'iw' as the API for this relies on confirmed TX speeds, and I only have an easy way of retrieving RX speeds from the RTL device. The vendor driver probably fakes it. > rtl8xxxu IEEE 802.11 ESSID:"openwrt24-ab" > Mode:Managed Frequency:2.462 GHz Access Point: 22:4E:7F:6F:5B:3C > Bit Rate=54 Mb/s Tx-Power=20 dBm > Retry short limit:7 RTS thr=2347 B Fragment thr:off > Power Management:off > Link Quality=47/70 Signal level=-63 dBm > Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 > Tx excessive retries:0 Invalid misc:38 Missed beacon:0 > > iwlwifi IEEE 802.11 ESSID:"openwrt24-ab" > Mode:Managed Frequency:2.462 GHz Access Point: 22:4E:7F:6F:5B:3C > Bit Rate=54 Mb/s Tx-Power=15 dBm > Retry short limit:7 RTS thr:off Fragment thr:off > Power Management:on > Link Quality=65/70 Signal level=-45 dBm > Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 > Tx excessive retries:90 Invalid misc:146 Missed beacon:0 > > >> For the rtl8712 device, rtl8192su?, then potentially that could be added to >> rtl8xxxu as well, but it's not a top priority on my list right now. > > This one: > Bus 001 Device 033: ID 0bda:8171 Realtek Semiconductor Corp. RTL8188SU > 802.11n WLAN Adapter > > I bought the rtl8188su a while ago, while the rtl8188cus (0bda:8176) > is from this year. According to https://wikidevi.com/wiki/Realtek, it > seems to be one year older than the rtl8188cus and was almost as common > in its day. Apparently everyone that used to make ...su device replaced it > with a ...cu or the newer ...eu chips and that is all you can buy these days > on the low end. Gotcha, 8188su is the 1x1 version of it. I do have a 8192su in the drawer somewhere, but the TODO list is a bit long already :) Cheers, Jes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wednesday, July 20, 2016 11:33:43 AM CEST Jes Sorensen wrote: > Arnd Bergmann <arnd@arndb.de> writes: > > On Wednesday, July 20, 2016 7:25:19 AM CEST Jes Sorensen wrote: > >> Arnd Bergmann <arnd@arndb.de> writes: > >> Well it really all depends on how much time I have and how much others > >> step up and help contribute to the code. For rtl8xxxu my plans are as > >> follows: > >> > >> 1) rtl8188eu support, since this is the most widely distributed USB > >> dongle which isn't currently supported by a non staging driver. I am > >> currently working on this together with Andrea Merello. > > > > Ok, cool. > > > >> 2) Beacon support for IBSS and AP mode - hopefully this should make it > >> possible to default rtl8xxxu for rtl8192cu/rtl8188cu devices and disable > >> them in rtlwifi. > > > > Do we have any indication that those two actually work in rtlwifi at the > > moment? My experience seems to match the recommendations for all the > > raspberry pi users that use yet another (worse looking) driver: > > > > https://github.com/raspberrypi/linux/commit/9ee31007a5032a3afe2fcb20c36b34f0ad57df56 > > I am not really authoritative on that one. I tried it in station mode > and it didn't work well for me. I never played with AP mode - It may > work better in IBSS or AP mode than it does in station mode. I don't > like to pull the rug away under people, which is why I haven't pushed > for this. Right. Then again, for AP mode, all information on the web indicates similar problems, recommending the out-of-tree driver and a custom hostap fork: https://bogeskov.dk/UsbAccessPoint.html > > throughput for me is 2mbit/s, compared to my intel 2x2 wireless that gets > > 5mbit/s on the same network, but I guess that doesn't really mean much > > as long as I have problems with the infrastructure. > > Note the rtl8xxxu driver doesn't report speeds properly to > NetworkMangler or 'iw' as the API for this relies on confirmed TX > speeds, and I only have an easy way of retrieving RX speeds from the RTL > device. The vendor driver probably fakes it. This was the rx speed I got from downloading a file from a known server. With the rtl8192cu driver, I could get no connection at all today, and when I last tried, it stopped working after a few minutes at best. > > This one: > > Bus 001 Device 033: ID 0bda:8171 Realtek Semiconductor Corp. RTL8188SU > > 802.11n WLAN Adapter > > > > I bought the rtl8188su a while ago, while the rtl8188cus (0bda:8176) > > is from this year. According to https://wikidevi.com/wiki/Realtek, it > > seems to be one year older than the rtl8188cus and was almost as common > > in its day. Apparently everyone that used to make ...su device replaced it > > with a ...cu or the newer ...eu chips and that is all you can buy these days > > on the low end. > > Gotcha, 8188su is the 1x1 version of it. I do have a 8192su in the > drawer somewhere, but the TODO list is a bit long already Yes, I was just agreeing here that it's not worth doing that one. As far as I can see, the evolution of these devices is RTL81xxU (2008) RTL81xxSU (2009) RTL81xxCU (2010) RTL81xxEU (2013) Clearly there is no use working on the older ones before the latest ones work well. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi On 2016-07-20, Arnd Bergmann wrote: > On Wednesday, July 20, 2016 11:33:43 AM CEST Jes Sorensen wrote: > > Arnd Bergmann <arnd@arndb.de> writes: > > > On Wednesday, July 20, 2016 7:25:19 AM CEST Jes Sorensen wrote: > > >> Arnd Bergmann <arnd@arndb.de> writes: [...] > Yes, I was just agreeing here that it's not worth doing that one. > As far as I can see, the evolution of these devices is > > RTL81xxU (2008) > RTL81xxSU (2009) > RTL81xxCU (2010) There is also RTL81xxDU, apparently from 2011, a dualband device coming in several variants (single MAC + single PHY, double MAC + double PHY and double PHY); e.g. 0bda:8194 (single PHY + single MAC). While probably not overly common, it was/ is (hardware-wise) a pretty interesting device due to its support for 5 GHz[1] - actually I hoped it to be a (supported-) RTL8192CU variant when I bought it. Unfortunately no driver[2] made it to staging or the proper kernel. > RTL81xxEU (2013) Regards Stefan Lippers-Hollmann [1] apparently even concurrent operations for the double MAC + double PHY variants [2] https://github.com/lwfinger/rtl8192du
Stefan Lippers-Hollmann <s.l-h@gmx.de> writes: > Hi > > On 2016-07-20, Arnd Bergmann wrote: >> On Wednesday, July 20, 2016 11:33:43 AM CEST Jes Sorensen wrote: >> > Arnd Bergmann <arnd@arndb.de> writes: >> > > On Wednesday, July 20, 2016 7:25:19 AM CEST Jes Sorensen wrote: >> > >> Arnd Bergmann <arnd@arndb.de> writes: > [...] >> Yes, I was just agreeing here that it's not worth doing that one. >> As far as I can see, the evolution of these devices is >> >> RTL81xxU (2008) >> RTL81xxSU (2009) >> RTL81xxCU (2010) > > There is also RTL81xxDU, apparently from 2011, a dualband device > coming in several variants (single MAC + single PHY, double MAC + > double PHY and double PHY); e.g. 0bda:8194 (single PHY + single MAC). > > While probably not overly common, it was/ is (hardware-wise) a pretty > interesting device due to its support for 5 GHz[1] - actually I hoped > it to be a (supported-) RTL8192CU variant when I bought it. > Unfortunately no driver[2] made it to staging or the proper kernel. I actually have one of those in my USB dongle box, but as you say, not overly common so not sure if/when I'll get to it. Adding 8192du support for 2.4GHz to rtl8xxxu probably wouldn't be too complicated. Cheers, Jes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Friday, July 22, 2016 7:55:36 AM CEST Jes Sorensen wrote: > Stefan Lippers-Hollmann <s.l-h@gmx.de> writes: > > Hi > > > > On 2016-07-20, Arnd Bergmann wrote: > >> On Wednesday, July 20, 2016 11:33:43 AM CEST Jes Sorensen wrote: > >> > Arnd Bergmann <arnd@arndb.de> writes: > >> > > On Wednesday, July 20, 2016 7:25:19 AM CEST Jes Sorensen wrote: > >> > >> Arnd Bergmann <arnd@arndb.de> writes: > > [...] > >> Yes, I was just agreeing here that it's not worth doing that one. > >> As far as I can see, the evolution of these devices is > >> > >> RTL81xxU (2008) > >> RTL81xxSU (2009) > >> RTL81xxCU (2010) > > > > There is also RTL81xxDU, apparently from 2011, a dualband device > > coming in several variants (single MAC + single PHY, double MAC + > > double PHY and double PHY); e.g. 0bda:8194 (single PHY + single MAC). Right. In my list above I tried to have just the ones that seem to each be 100% supersets of previous generations replacing the earlier ones, which isn't true for RTL81xxDU as RTL81xxEU reverts to single PHY. > > While probably not overly common, it was/ is (hardware-wise) a pretty > > interesting device due to its support for 5 GHz[1] - actually I hoped > > it to be a (supported-) RTL8192CU variant when I bought it. > > Unfortunately no driver[2] made it to staging or the proper kernel. > > I actually have one of those in my USB dongle box, but as you say, not > overly common so not sure if/when I'll get to it. > > Adding 8192du support for 2.4GHz to rtl8xxxu probably wouldn't be too > complicated. My guess is that these devices have largely been replaced by 802.11ac devices on the market, and whoever has one of the old ones probably bought it because of the 5GHz support, so adding 2.4GHz-only support for it may not help all that much either. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi On 2016-07-22, Arnd Bergmann wrote: > On Friday, July 22, 2016 7:55:36 AM CEST Jes Sorensen wrote: > > Stefan Lippers-Hollmann <s.l-h@gmx.de> writes: > > > On 2016-07-20, Arnd Bergmann wrote: > > >> On Wednesday, July 20, 2016 11:33:43 AM CEST Jes Sorensen wrote: > > >> > Arnd Bergmann <arnd@arndb.de> writes: > > >> > > On Wednesday, July 20, 2016 7:25:19 AM CEST Jes Sorensen wrote: > > >> > >> Arnd Bergmann <arnd@arndb.de> writes: [...] > > > While probably not overly common, it was/ is (hardware-wise) a pretty > > > interesting device due to its support for 5 GHz[1] - actually I hoped > > > it to be a (supported-) RTL8192CU variant when I bought it. > > > Unfortunately no driver[2] made it to staging or the proper kernel. > > > > I actually have one of those in my USB dongle box, but as you say, not > > overly common so not sure if/when I'll get to it. > > > > Adding 8192du support for 2.4GHz to rtl8xxxu probably wouldn't be too > > complicated. > > My guess is that these devices have largely been replaced by > 802.11ac devices on the market, and whoever has one of the old ones > probably bought it because of the 5GHz support, so adding 2.4GHz-only > support for it may not help all that much either. Talking purely for myself, I've certainly bought the rtl8192du device because of its 5 GHz support, as I've made it a fairly hard policy for me not to buy 2.4 GHz only devices anymore. But this doesn't mean that a mainline driver only supporting 2.4 GHz for the time being would not be appreciated dearly, given that the current state of the device is pretty much being a doorstop[1] - especially considering that 5 GHz support might even become a possibility at a later time, when 802.11ac devices start demanding most of the functionality for potentially more common newer chipset generations. So even with my current personal policy of only buying 5 GHz capable devices, in practice you probably won't find 5 GHz only AP installations (aside from long range/ outdoor point-to-point connections), be it because of the plethora of existing 2.4 GHz only devices or just because of the longer indoor (walls) range of the 2.4 GHz band. In practice, by far most of my existing wireless devices don't support 5 GHz (the router does, of course) because of the reasons mentioned above, but replacing older devices takes its time. Regards Stefan Lippers-Hollmann [1] yes, I know about https://github.com/lwfinger/rtl8192du/ and even have a couple of clean-up patches pending[2] for the kernel-version branch, but those need some further testing. [2] http://aptosid.com/slh/rtl8192du/kernel-version/ -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c b/drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c index ba64a4f1b3a8..8d6bca61e7aa 100644 --- a/drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c +++ b/drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c @@ -1487,8 +1487,8 @@ static void _rtl92e_query_rxphystatus( struct phy_ofdm_rx_status_rxsc_sgien_exintfflag *prxsc; u8 *prxpkt; u8 i, max_spatial_stream, tmp_rxsnr, tmp_rxevm, rxsc_sgien_exflg; - char rx_pwr[4], rx_pwr_all = 0; - char rx_snrX, rx_evmX; + s8 rx_pwr[4], rx_pwr_all = 0; + s8 rx_snrX, rx_evmX; u8 evm, pwdb_all; u32 RSSI, total_rssi = 0; u8 is_cck_rate = 0; @@ -1613,7 +1613,7 @@ static void _rtl92e_query_rxphystatus( 2) - 110; tmp_rxsnr = pofdm_buf->rxsnr_X[i]; - rx_snrX = (char)(tmp_rxsnr); + rx_snrX = (s8)(tmp_rxsnr); rx_snrX /= 2; priv->stats.rxSNRdB[i] = (long)rx_snrX; @@ -1643,7 +1643,7 @@ static void _rtl92e_query_rxphystatus( for (i = 0; i < max_spatial_stream; i++) { tmp_rxevm = pofdm_buf->rxevm_X[i]; - rx_evmX = (char)(tmp_rxevm); + rx_evmX = (s8)(tmp_rxevm); rx_evmX /= 2; diff --git a/drivers/staging/rtl8192e/rtl8192e/r8192E_phy.c b/drivers/staging/rtl8192e/rtl8192e/r8192E_phy.c index 5e3bbe5c3ca4..0698131e4300 100644 --- a/drivers/staging/rtl8192e/rtl8192e/r8192E_phy.c +++ b/drivers/staging/rtl8192e/rtl8192e/r8192E_phy.c @@ -630,7 +630,7 @@ void rtl92e_set_tx_power(struct net_device *dev, u8 channel) { struct r8192_priv *priv = rtllib_priv(dev); u8 powerlevel = 0, powerlevelOFDM24G = 0; - char ant_pwr_diff; + s8 ant_pwr_diff; u32 u4RegValue; if (priv->epromtype == EEPROM_93C46) { diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_core.c b/drivers/staging/rtl8192e/rtl8192e/rtl_core.c index 13a5ddc2bea5..41e05f206300 100644 --- a/drivers/staging/rtl8192e/rtl8192e/rtl_core.c +++ b/drivers/staging/rtl8192e/rtl8192e/rtl_core.c @@ -1982,7 +1982,7 @@ void rtl92e_update_rx_statistics(struct r8192_priv *priv, weighting) / 6; } -u8 rtl92e_rx_db_to_percent(char antpower) +u8 rtl92e_rx_db_to_percent(s8 antpower) { if ((antpower <= -100) || (antpower >= 20)) return 0; @@ -1993,9 +1993,9 @@ u8 rtl92e_rx_db_to_percent(char antpower) } /* QueryRxPwrPercentage */ -u8 rtl92e_evm_db_to_percent(char value) +u8 rtl92e_evm_db_to_percent(s8 value) { - char ret_val; + s8 ret_val; ret_val = value; diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_core.h b/drivers/staging/rtl8192e/rtl8192e/rtl_core.h index f627fdc15a58..6921125c9d35 100644 --- a/drivers/staging/rtl8192e/rtl8192e/rtl_core.h +++ b/drivers/staging/rtl8192e/rtl8192e/rtl_core.h @@ -503,8 +503,8 @@ struct r8192_priv { u32 Pwr_Track; u8 CCKPresentAttentuation_20Mdefault; u8 CCKPresentAttentuation_40Mdefault; - char CCKPresentAttentuation_difference; - char CCKPresentAttentuation; + s8 CCKPresentAttentuation_difference; + s8 CCKPresentAttentuation; long undecorated_smoothed_pwdb; u32 MCSTxPowerLevelOriginalOffset[6]; @@ -604,8 +604,8 @@ void rtl92e_update_rx_pkt_timestamp(struct net_device *dev, long rtl92e_translate_to_dbm(struct r8192_priv *priv, u8 signal_strength_index); void rtl92e_update_rx_statistics(struct r8192_priv *priv, struct rtllib_rx_stats *pprevious_stats); -u8 rtl92e_evm_db_to_percent(char value); -u8 rtl92e_rx_db_to_percent(char antpower); +u8 rtl92e_evm_db_to_percent(s8 value); +u8 rtl92e_rx_db_to_percent(s8 antpower); void rtl92e_copy_mpdu_stats(struct rtllib_rx_stats *psrc_stats, struct rtllib_rx_stats *ptarget_stats); bool rtl92e_enable_nic(struct net_device *dev); diff --git a/drivers/staging/rtl8192e/rtl819x_TSProc.c b/drivers/staging/rtl8192e/rtl819x_TSProc.c index 2c8a526773ed..e0a2fe5e6148 100644 --- a/drivers/staging/rtl8192e/rtl819x_TSProc.c +++ b/drivers/staging/rtl8192e/rtl819x_TSProc.c @@ -323,7 +323,7 @@ bool GetTs(struct rtllib_device *ieee, struct ts_common_info **ppTS, if (ieee->current_network.qos_data.supported == 0) { UP = 0; } else { - if (!IsACValid(TID)) { + if (!IsACValid((s8)TID)) { netdev_warn(ieee->dev, "%s(): TID(%d) is not valid\n", __func__, TID); return false;
Compiling the rtlwifi drivers for ARM with gcc -Wextra warns about lots of incorrect code that results from 'char' being unsigned here, e.g. staging/rtl8192e/rtl8192e/r8192E_phy.c:1072:36: error: comparison is always false due to limited range of data type [-Werror=type-limits] staging/rtl8192e/rtl8192e/r8192E_phy.c:1104:36: error: comparison is always false due to limited range of data type [-Werror=type-limits] staging/rtl8192e/rtl8192e/rtl_core.c:1987:16: error: comparison is always false due to limited range of data type [-Werror=type-limits] staging/rtl8192e/rtl8192e/rtl_dm.c:782:37: error: comparison is always false due to limited range of data type [-Werror=type-limits] staging/rtl8192e/rtl819x_TSProc.c:326:14: error: comparison is always true due to limited range of data type [-Werror=type-limits] staging/rtl8192e/rtllib_softmac_wx.c:465:16: error: comparison is always false due to limited range of data type [-Werror=type-limits] This patch changes all uses of 'char' in this driver that refer to 8-bit integers to use 's8' instead, which is signed on all architectures. Signed-off-by: Arnd Bergmann <arnd@arndb.de> --- drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c | 8 ++++---- drivers/staging/rtl8192e/rtl8192e/r8192E_phy.c | 2 +- drivers/staging/rtl8192e/rtl8192e/rtl_core.c | 6 +++--- drivers/staging/rtl8192e/rtl8192e/rtl_core.h | 8 ++++---- drivers/staging/rtl8192e/rtl819x_TSProc.c | 2 +- 5 files changed, 13 insertions(+), 13 deletions(-)