subject:"\[PATCH 2\/3\] staging\/rtl8192e\: use s8 instead of char"

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

2016-07-22 Thread Stefan Lippers-Hollmann

Hi

On 2016-07-22, Arnd Bergmann wrote:
> On Friday, July 22, 2016 7:55:36 AM CEST Jes Sorensen wrote:
> > Stefan Lippers-Hollmann  writes:  
> > > On 2016-07-20, Arnd Bergmann wrote:  
> > >> On Wednesday, July 20, 2016 11:33:43 AM CEST Jes Sorensen wrote:  
> > >> > Arnd Bergmann  writes:
> > >> > > On Wednesday, July 20, 2016 7:25:19 AM CEST Jes Sorensen wrote:
> > >> > >> Arnd Bergmann  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/

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

2016-07-22 Thread Arnd Bergmann

On Friday, July 22, 2016 7:55:36 AM CEST Jes Sorensen wrote:
> Stefan Lippers-Hollmann  writes:
> > Hi
> >
> > On 2016-07-20, Arnd Bergmann wrote:
> >> On Wednesday, July 20, 2016 11:33:43 AM CEST Jes Sorensen wrote:
> >> > Arnd Bergmann  writes:  
> >> > > On Wednesday, July 20, 2016 7:25:19 AM CEST Jes Sorensen wrote:  
> >> > >> Arnd Bergmann  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

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

2016-07-22 Thread Jes Sorensen

Stefan Lippers-Hollmann  writes:
> Hi
>
> On 2016-07-20, Arnd Bergmann wrote:
>> On Wednesday, July 20, 2016 11:33:43 AM CEST Jes Sorensen wrote:
>> > Arnd Bergmann  writes:  
>> > > On Wednesday, July 20, 2016 7:25:19 AM CEST Jes Sorensen wrote:  
>> > >> Arnd Bergmann  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

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

2016-07-21 Thread Stefan Lippers-Hollmann

Hi

On 2016-07-20, Arnd Bergmann wrote:
> On Wednesday, July 20, 2016 11:33:43 AM CEST Jes Sorensen wrote:
> > Arnd Bergmann  writes:  
> > > On Wednesday, July 20, 2016 7:25:19 AM CEST Jes Sorensen wrote:  
> > >> Arnd Bergmann  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

pgp85Y9TKCthM.pgp
Description: Digitale Signatur von OpenPGP

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

2016-07-20 Thread Arnd Bergmann

On Wednesday, July 20, 2016 11:33:43 AM CEST Jes Sorensen wrote:
> Arnd Bergmann  writes:
> > On Wednesday, July 20, 2016 7:25:19 AM CEST Jes Sorensen wrote:
> >> Arnd Bergmann  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

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

2016-07-20 Thread Christian Lamparter

On Wednesday, July 20, 2016 5:06:27 PM CEST Xose Vazquez Perez wrote:
> Arnd Bergmann  wrote:
> 
> > rtlwifi, but I found the older r8712u device to work fine with
> > the staging/rtl8712 driver.
> 
> A replacement for "staging/rtl8712", with MAC80211 support, is
> available at: https://github.com/chunkeey/rtl8192su
> 
> Also a fullmac/cfg80211 driver(r92su) is available at the
> same repository.
> 
Yes, it has its problems. The rtl8712/r92su isn't really
a fullmac device. While the MLME (scan, probe, auth, assoc) is
done by the firmware. The 802.11 frame creation (from 802.3)
frames needs to be done by the driver. The rtl8712 firmware
however has its fair share of issues. Like: no support for
(tx) fragmentation and ERP is a mystery too. monitor 
mode is barely working and limited to 20Mhz wide channels.
There's also limited tx injection support and of course
stability issues (just like with the staging/rtl8712 driver
or FreeBSD's rsu driver).

The rtl8192su driver (based on rtlwifi) in the same repository
has proper fragmentation support. But it uses the firmware from
the windows/mac os x driver, which is similar to rtl8192se softmac
firmware in design. Getting it to work properly in station mode
however either needs "some magic" or help from Realtek's USB group...

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

2016-07-20 Thread Jes Sorensen

Arnd Bergmann  writes:
> On Wednesday, July 20, 2016 7:25:19 AM CEST Jes Sorensen wrote:
>> Arnd Bergmann  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: 00e04c01
> [  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  
>  
>

[PATCH 2/3] staging/rtl8192e: use s8 instead of char

2016-07-20 Thread Arnd Bergmann

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/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 
Acked-by: Jes Sorensen 
---
 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 
 4 files changed, 12 insertions(+), 12 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

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

2016-07-20 Thread Arnd Bergmann

On Wednesday, July 20, 2016 7:25:19 AM CEST Jes Sorensen wrote:
> Arnd Bergmann  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: 00e04c01
[  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

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

2016-07-20 Thread Xose Vazquez Perez

Arnd Bergmann  wrote:

> rtlwifi, but I found the older r8712u device to work fine with
> the staging/rtl8712 driver.

A replacement for "staging/rtl8712", with MAC80211 support, is
available at: https://github.com/chunkeey/rtl8192su

Also a fullmac/cfg80211 driver(r92su) is available at the
same repository.

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

2016-07-20 Thread Larry Finger


On 07/20/2016 06:25 AM, Jes Sorensen wrote:

Arnd Bergmann  writes:

On Tuesday, July 19, 2016 12:05:00 PM CEST Jes Sorensen wrote:

Arnd Bergmann  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

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

2016-07-20 Thread Jes Sorensen

Arnd Bergmann  writes:
> On Tuesday, July 19, 2016 12:05:00 PM CEST Jes Sorensen wrote:
>> Arnd Bergmann  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

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

2016-07-20 Thread Arnd Bergmann

On Tuesday, July 19, 2016 12:05:00 PM CEST Jes Sorensen wrote:
> Arnd Bergmann  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

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

2016-07-19 Thread Jes Sorensen

Arnd Bergmann  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

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

2016-07-19 Thread Arnd Bergmann

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

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

2016-07-19 Thread Jes Sorensen

Arnd Bergmann  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 
> ---
>  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

[PATCH 2/3] staging/rtl8192e: use s8 instead of char

2016-07-19 Thread Arnd Bergmann

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 
---
 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

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

[PATCH 2/3] staging/rtl8192e: use s8 instead of char

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

[PATCH 2/3] staging/rtl8192e: use s8 instead of char

17 matches

Site Navigation

Mail list logo

Footer information