For rtl8188ee, we pass -Idrivers/net/wireless/rtlwifi/ to gcc,
however that directy no longer exists, so evidently this option
is no longer required here and can be removed to avoid a warning
when building with 'make W=1' or 'gcc -Wmissing-include-dirs'
Signed-off-by: Arnd Bergmann <[email protected]>
---
drivers/net/wireless/realtek/rtlwifi/rtl8188ee/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/Makefile b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/Makefile
index a85419a37651..676e7de27f27 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/Makefile
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/Makefile
@@ -12,4 +12,4 @@ rtl8188ee-objs := \
obj-$(CONFIG_RTL8188EE) += rtl8188ee.o
-ccflags-y += -Idrivers/net/wireless/rtlwifi -D__CHECK_ENDIAN__
+ccflags-y += -D__CHECK_ENDIAN__
--
2.9.0
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 <[email protected]>
---
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(-)
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;
--
2.9.0
On Wednesday, July 20, 2016 11:33:43 AM CEST Jes Sorensen wrote:
> Arnd Bergmann <[email protected]> writes:
> > On Wednesday, July 20, 2016 7:25:19 AM CEST Jes Sorensen wrote:
> >> Arnd Bergmann <[email protected]> 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
Arnd Bergmann <[email protected]> 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
Arnd Bergmann <[email protected]> wrote:
> For rtl8188ee, we pass -Idrivers/net/wireless/rtlwifi/ to gcc,
> however that directy no longer exists, so evidently this option
> is no longer required here and can be removed to avoid a warning
> when building with 'make W=1' or 'gcc -Wmissing-include-dirs'
>
> Signed-off-by: Arnd Bergmann <[email protected]>
Thanks, 1 patch applied to wireless-drivers-next.git:
944c07a7aac9 rtlwifi: don't add include path for rtl8188ee
--
Sent by pwcli
https://patchwork.kernel.org/patch/9237723/
Arnd Bergmann <[email protected]> writes:
> On Tuesday, July 19, 2016 12:05:00 PM CEST Jes Sorensen wrote:
>> Arnd Bergmann <[email protected]> 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
Arnd Bergmann <[email protected]> writes:
> On Wednesday, July 20, 2016 7:25:19 AM CEST Jes Sorensen wrote:
>> Arnd Bergmann <[email protected]> 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
Arnd Bergmann <[email protected]> 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 <[email protected]>
> ---
> 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
Hi
On 2016-07-20, Arnd Bergmann wrote:
> On Wednesday, July 20, 2016 11:33:43 AM CEST Jes Sorensen wrote:
> > Arnd Bergmann <[email protected]> writes:
> > > On Wednesday, July 20, 2016 7:25:19 AM CEST Jes Sorensen wrote:
> > >> Arnd Bergmann <[email protected]> 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
On 07/20/2016 06:25 AM, Jes Sorensen wrote:
> Arnd Bergmann <[email protected]> writes:
>> On Tuesday, July 19, 2016 12:05:00 PM CEST Jes Sorensen wrote:
>>> Arnd Bergmann <[email protected]> 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
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/rtl8192u/r8192U_core.c:4150:16: error: comparison is always false due to limited range of data type [-Werror=type-limits]
staging/rtl8192u/r8192U_dm.c:646:50: 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 <[email protected]>
---
drivers/staging/rtl8192u/ieee80211/ieee80211.h | 4 ++--
drivers/staging/rtl8192u/r8192U.h | 4 ++--
drivers/staging/rtl8192u/r8192U_core.c | 14 +++++++-------
3 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211.h b/drivers/staging/rtl8192u/ieee80211/ieee80211.h
index 09e9499b7f9d..077ea13eb1e7 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211.h
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211.h
@@ -746,7 +746,7 @@ struct ieee80211_rx_stats {
bool bisrxaggrsubframe;
bool bPacketBeacon; //cosa add for rssi
bool bToSelfBA; //cosa add for rssi
- char cck_adc_pwdb[4]; //cosa add for rx path selection
+ s8 cck_adc_pwdb[4]; //cosa add for rx path selection
u16 Seq_Num;
};
@@ -1814,7 +1814,7 @@ struct ieee80211_device {
u32 wpax_type_notify; //{added by David, 2006.9.26}
/* QoS related flag */
- char init_wmmparam_flag;
+ s8 init_wmmparam_flag;
/* set on initialization */
u8 qos_support;
diff --git a/drivers/staging/rtl8192u/r8192U.h b/drivers/staging/rtl8192u/r8192U.h
index 5dba6a28dd9b..b28bc7812caa 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -533,7 +533,7 @@ typedef struct _rt_9x_tx_rate_history {
u32 ht_mcs[4][16];
} rt_tx_rahis_t, *prt_tx_rahis_t;
typedef struct _RT_SMOOTH_DATA_4RF {
- char elements[4][100]; /* array to store values */
+ s8 elements[4][100]; /* array to store values */
u32 index; /* index to current array to store */
u32 TotalNum; /* num of valid elements */
u32 TotalVal[4]; /* sum of valid elements */
@@ -1031,7 +1031,7 @@ typedef struct r8192_priv {
s8 cck_present_attentuation;
u8 cck_present_attentuation_20Mdefault;
u8 cck_present_attentuation_40Mdefault;
- char cck_present_attentuation_difference;
+ s8 cck_present_attentuation_difference;
bool btxpower_tracking;
bool bcck_in_ch14;
bool btxpowerdata_readfromEEPORM;
diff --git a/drivers/staging/rtl8192u/r8192U_core.c b/drivers/staging/rtl8192u/r8192U_core.c
index dd0970facdf5..f36b2d3b1ee9 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -4209,7 +4209,7 @@ static void rtl8192_process_phyinfo(struct r8192_priv *priv, u8 *buffer,
*
* Return: 0-100 percentage
*---------------------------------------------------------------------------*/
-static u8 rtl819x_query_rxpwrpercentage(char antpower)
+static u8 rtl819x_query_rxpwrpercentage(s8 antpower)
{
if ((antpower <= -100) || (antpower >= 20))
return 0;
@@ -4220,9 +4220,9 @@ static u8 rtl819x_query_rxpwrpercentage(char antpower)
} /* QueryRxPwrPercentage */
-static u8 rtl819x_evm_dbtopercentage(char value)
+static u8 rtl819x_evm_dbtopercentage(s8 value)
{
- char ret_val;
+ s8 ret_val;
ret_val = value;
@@ -4297,8 +4297,8 @@ static void rtl8192_query_rxphystatus(struct r8192_priv *priv,
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;
@@ -4423,7 +4423,7 @@ static void rtl8192_query_rxphystatus(struct r8192_priv *priv,
/* Get Rx snr value in DB */
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;
@@ -4457,7 +4457,7 @@ static void rtl8192_query_rxphystatus(struct r8192_priv *priv,
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);
/* Do not use shift operation like "rx_evmX >>= 1"
* because the compiler of free build environment will
--
2.9.0
On Tuesday, July 19, 2016 12:05:00 PM CEST Jes Sorensen wrote:
> Arnd Bergmann <[email protected]> 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
Stefan Lippers-Hollmann <[email protected]> writes:
> Hi
>
> On 2016-07-20, Arnd Bergmann wrote:
>> On Wednesday, July 20, 2016 11:33:43 AM CEST Jes Sorensen wrote:
>> > Arnd Bergmann <[email protected]> writes:
>> > > On Wednesday, July 20, 2016 7:25:19 AM CEST Jes Sorensen wrote:
>> > >> Arnd Bergmann <[email protected]> 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
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
On Friday, July 22, 2016 7:55:36 AM CEST Jes Sorensen wrote:
> Stefan Lippers-Hollmann <[email protected]> writes:
> > Hi
> >
> > On 2016-07-20, Arnd Bergmann wrote:
> >> On Wednesday, July 20, 2016 11:33:43 AM CEST Jes Sorensen wrote:
> >> > Arnd Bergmann <[email protected]> writes:
> >> > > On Wednesday, July 20, 2016 7:25:19 AM CEST Jes Sorensen wrote:
> >> > >> Arnd Bergmann <[email protected]> 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
Arnd Bergmann <[email protected]> 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/rtl8192u/r8192U_core.c:4150:16: error: comparison is always false due to limited range of data type [-Werror=type-limits]
> staging/rtl8192u/r8192U_dm.c:646:50: 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 <[email protected]>
> ---
> drivers/staging/rtl8192u/ieee80211/ieee80211.h | 4 ++--
> drivers/staging/rtl8192u/r8192U.h | 4 ++--
> drivers/staging/rtl8192u/r8192U_core.c | 14 +++++++-------
> 3 files changed, 11 insertions(+), 11 deletions(-)
Looks good to me
Acked-by: Jes Sorensen <[email protected]>
On Wednesday, July 20, 2016 7:25:19 AM CEST Jes Sorensen wrote:
> Arnd Bergmann <[email protected]> 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