[RFC] rtlwifi: fix in_ep = in_ep_num mishap in _rtl_usb_init_rx

[RFC] rtlwifi: fix in_ep = in_ep_num mishap in _rtl_usb_init_rx

[Christian Lamparter]

in_ep and in_ep_num should not be the same as
a device can have a different in_ep than "1".

Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
---
Note:
This patch is related to:
"[PATCH 3/9] rtlwifi: fix the selection of the bulk in endpoint"

However, it would be much better if we can get rid of
in_ep_num and define an in_ep array so the rtlwifi
frameworks knows which EPs to scan. But this could be
"too much" of an overkill, so another solution would
be to just have a single in_ep. 

Larry, do you know of any hardware which has two in endpoints?

Joshua, I get as far as "blinking LEDs". But the PHY/RF and RX
seem to need more work, or did you have some success with it
and it's just the HW combination/refactoring that broke it?!

Regards,
	Chr
---
 rtlwifi/rtl8192cu/sw.c |    1 +
 rtlwifi/usb.c          |    3 ++-
 rtlwifi/wifi.h         |    1 +
 3 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/rtlwifi/rtl8192cu/sw.c b/rtlwifi/rtl8192cu/sw.c
index 9970c2b..24b6f69 100644
--- a/rtlwifi/rtl8192cu/sw.c
+++ b/rtlwifi/rtl8192cu/sw.c
@@ -151,6 +151,7 @@ MODULE_PARM_DESC(debug, "Set debug level (0-5) (default 0)");
 
 static struct rtl_hal_usbint_cfg rtl92cu_interface_cfg = {
 	/* rx */
+	.in_ep = RTL92C_USB_BULK_IN_NUM,
 	.in_ep_num = RTL92C_USB_BULK_IN_NUM,
 	.rx_urb_num = RTL92C_NUM_RX_URBS,
 	.rx_max_size = RTL92C_SIZE_MAX_RX_BUFFER,
diff --git a/rtlwifi/usb.c b/rtlwifi/usb.c
index 31db282..d7744e1 100644
--- a/rtlwifi/usb.c
+++ b/rtlwifi/usb.c
@@ -306,7 +306,8 @@ static int _rtl_usb_init_rx(struct ieee80211_hw *hw)
 
 	rtlusb->rx_max_size = rtlpriv->cfg->usb_interface_cfg->rx_max_size;
 	rtlusb->rx_urb_num = rtlpriv->cfg->usb_interface_cfg->rx_urb_num;
-	rtlusb->in_ep = rtlpriv->cfg->usb_interface_cfg->in_ep_num;
+	rtlusb->in_ep = rtlpriv->cfg->usb_interface_cfg->in_ep;
+	rtlusb->in_ep_nums = rtlpriv->cfg->usb_interface_cfg->in_ep_num;
 	rtlusb->usb_rx_hdl = rtlpriv->cfg->usb_interface_cfg->usb_rx_hdl;
 	rtlusb->usb_rx_segregate_hdl =
 		rtlpriv->cfg->usb_interface_cfg->usb_rx_segregate_hdl;
diff --git a/rtlwifi/wifi.h b/rtlwifi/wifi.h
index ad02203..882b870 100644
--- a/rtlwifi/wifi.h
+++ b/rtlwifi/wifi.h
@@ -1550,6 +1550,7 @@ struct rtl_mod_params {
 
 struct rtl_hal_usbint_cfg {
 	/* data - rx */
+	u32 in_ep;
 	u32 in_ep_num;
 	u32 rx_urb_num;
 	u32 rx_max_size;
-- 
1.7.10.4

Re: [RFC] rtlwifi: fix in_ep = in_ep_num mishap in _rtl_usb_init_rx

[Larry Finger]

On 10/14/2012 03:13 PM, Christian Lamparter wrote:
> in_ep and in_ep_num should not be the same as
> a device can have a different in_ep than "1".
>
> Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
> ---
> Note:
> This patch is related to:
> "[PATCH 3/9] rtlwifi: fix the selection of the bulk in endpoint"
>
> However, it would be much better if we can get rid of
> in_ep_num and define an in_ep array so the rtlwifi
> frameworks knows which EPs to scan. But this could be
> "too much" of an overkill, so another solution would
> be to just have a single in_ep.
>
> Larry, do you know of any hardware which has two in endpoints?

The RTL8188CU has the following:

Bus 004 Device 002: ID 0bda:8723 Realtek Semiconductor Corp.
         bEndpointAddress     0x81  EP 1 IN
         bEndpointAddress     0x02  EP 2 OUT
         bEndpointAddress     0x82  EP 2 IN
         bEndpointAddress     0x03  EP 3 OUT
         bEndpointAddress     0x83  EP 3 IN
         bEndpointAddress     0x03  EP 3 OUT
         bEndpointAddress     0x83  EP 3 IN
         bEndpointAddress     0x03  EP 3 OUT
         bEndpointAddress     0x83  EP 3 IN

My SU device has the same layout. It seems that only EP 1 is used exclusively 
for input operations.

Larry

Re: [RFC] rtlwifi: fix in_ep = in_ep_num mishap in _rtl_usb_init_rx

[Christian Lamparter]

On Monday, October 15, 2012 01:38:13 AM Larry Finger wrote:
> On 10/14/2012 03:13 PM, Christian Lamparter wrote:
> > in_ep and in_ep_num should not be the same as
> > a device can have a different in_ep than "1".
> >
> > Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
> > Larry, do you know of any hardware which has two in endpoints?
> 
> The RTL8188CU has the following:
> 
> Bus 004 Device 002: ID 0bda:8723 Realtek Semiconductor Corp.
>          bEndpointAddress     0x81  EP 1 IN
>          bEndpointAddress     0x02  EP 2 OUT
>          bEndpointAddress     0x82  EP 2 IN
>          bEndpointAddress     0x03  EP 3 OUT
>          bEndpointAddress     0x83  EP 3 IN
>          bEndpointAddress     0x03  EP 3 OUT
>          bEndpointAddress     0x83  EP 3 IN
>          bEndpointAddress     0x03  EP 3 OUT
>          bEndpointAddress     0x83  EP 3 IN
> 
> My SU device has the same layout. It seems that only EP 
> 1 is used exclusively for input operations.

It's a bit weird that you have three IN and OUT 0x3 eps. Is this
really true or is this a c&p error and your devices have more
than one interface configuration?

The endpoint configuration for my SU devices (both are the same)
look like this:
   Interface Descriptor:
        bEndpointAddress     0x83  EP 3  IN  Bulk Data 512 bytes
        bEndpointAddress     0x04  EP 4  OUT Bulk Data 512 bytes
        bEndpointAddress     0x06  EP 6  OUT Bulk Data 512 bytes
        bEndpointAddress     0x0d  EP 13 OUT Bulk Data 512 bytes

It looks like that we should parse the endpoint descriptor and
get the first endpoint from there.

Regards,
	Chr

Re: [RFC] rtlwifi: fix in_ep = in_ep_num mishap in _rtl_usb_init_rx

[Larry Finger]

On 10/15/2012 05:42 AM, Christian Lamparter wrote:
> It's a bit weird that you have three IN and OUT 0x3 eps. Is this
> really true or is this a c&p error and your devices have more
> than one interface configuration?
>
> The endpoint configuration for my SU devices (both are the same)
> look like this:
>     Interface Descriptor:
>          bEndpointAddress     0x83  EP 3  IN  Bulk Data 512 bytes
>          bEndpointAddress     0x04  EP 4  OUT Bulk Data 512 bytes
>          bEndpointAddress     0x06  EP 6  OUT Bulk Data 512 bytes
>          bEndpointAddress     0x0d  EP 13 OUT Bulk Data 512 bytes
>
> It looks like that we should parse the endpoint descriptor and
> get the first endpoint from there.

The confusion arose from me reporting the EP configuration for the USB Bluetooth 
component of an RTL8723AE that I currently have installed. It has the 
bidirectional EPs:

         bEndpointAddress     0x81  EP 1 IN
         bEndpointAddress     0x02  EP 2 OUT
         bEndpointAddress     0x82  EP 2 IN
         bEndpointAddress     0x03  EP 3 OUT
         bEndpointAddress     0x83  EP 3 IN
         bEndpointAddress     0x03  EP 3 OUT
         bEndpointAddress     0x83  EP 3 IN
         bEndpointAddress     0x03  EP 3 OUT
         bEndpointAddress     0x83  EP 3 IN
         bEndpointAddress     0x03  EP 3 OUT
         bEndpointAddress     0x83  EP 3 IN
         bEndpointAddress     0x03  EP 3 OUT
         bEndpointAddress     0x83  EP 3 IN
         bEndpointAddress     0x03  EP 3 OUT
         bEndpointAddress     0x83  EP 3 IN

My RTL8191SU and the RTL8192SU both have the following:

         bEndpointAddress     0x83  EP 3 IN
         bEndpointAddress     0x04  EP 4 OUT
         bEndpointAddress     0x06  EP 6 OUT
         bEndpointAddress     0x0d  EP 13 OUT

My two copies if RTL8188CUS chips that use rtl8192cu both have

         bEndpointAddress     0x81  EP 1 IN
         bEndpointAddress     0x02  EP 2 OUT
         bEndpointAddress     0x03  EP 3 OUT
         bEndpointAddress     0x84  EP 4 IN

Although these chips have two IN EPs, the first is the one in use, thus 
searching for the first IN EP should be OK, and we can ignore the fact that the 
chip has two IN EPs. I am currently trying to acquire a sample of the RTL8192DU 
device with dual band operation on separate MACs. I think it registers as two 
separate devices (at least the PCI version does), and it should not change the 
situation. Even if it does, its initial driver will be in staging, and will not 
use rtlwifi.

Larry