[PATCH 1/3] rtlwifi: don't add include path for rtl8188ee

[PATCH 1/3] rtlwifi: don't add include path for rtl8188ee

[Arnd Bergmann]

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 <arnd@arndb.de>
---
 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

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

[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 <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(-)

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

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

[Jes Sorensen]

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

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

[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

[Jes Sorensen]

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

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

[Arnd Bergmann]

On Tuesday, July 19, 2016 12:05:00 PM CEST Jes Sorensen wrote:
> Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> 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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Jes Sorensen]

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

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

[Larry Finger]

On 07/20/2016 06:25 AM, Jes Sorensen wrote:
> Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> writes:
>> On Tuesday, July 19, 2016 12:05:00 PM CEST Jes Sorensen wrote:
>>> Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> 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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Arnd Bergmann]

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

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

[Jes Sorensen]

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

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

[Arnd Bergmann]

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

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

[Stefan Lippers-Hollmann]

[-- Attachment #1: Type: text/plain, Size: 1144 bytes --]

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

[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Jes Sorensen]

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

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

[Arnd Bergmann]

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

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

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

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

[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/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 <arnd@arndb.de>
---
 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

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

[Jes Sorensen]

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/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 <arnd@arndb.de>
> ---
>  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 <Jes.Sorensen@redhat.com>

Re: [1/3] rtlwifi: don't add include path for rtl8188ee

[Kalle Valo]

Arnd Bergmann <arnd@arndb.de> 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 <arnd@arndb.de>

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/