Patchwork [U-Boot,V4,01/17] usb: gadget: mv_udc: don't check CONFIG_USB_MAX_CONTROLLER_COUNT

login
register
mail settings
Submitter Troy Kisky
Date Sept. 20, 2013, 3:29 a.m.
Message ID <1379647780-2623-2-git-send-email-troy.kisky@boundarydevices.com>
Download mbox | patch
Permalink /patch/276198/
State Superseded
Delegated to: Marek Vasut
Headers show

Comments

Troy Kisky - Sept. 20, 2013, 3:29 a.m.
i.mx6 has 1 otg controller, and 3 host ports. So,
CONFIG_USB_MAX_CONTROLLER_COUNT can be greater than 1
even though only 1 device mode controller is supported.

Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>

---
v4: new patch
---
 drivers/usb/gadget/mv_udc.c | 4 ----
 1 file changed, 4 deletions(-)
Marek Vasut - Sept. 20, 2013, 10:45 a.m.
Dear Troy Kisky,

> i.mx6 has 1 otg controller, and 3 host ports. So,
> CONFIG_USB_MAX_CONTROLLER_COUNT can be greater than 1
> even though only 1 device mode controller is supported.
> 
> Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
> 

The problem is, will the 3 additional ports still work? I suspect they will, but 
then if you run 'usb reset', the gadget port will also be switched back into USB 
Host function, no

Best regards,
Marek Vasut
Troy Kisky - Sept. 20, 2013, 6:18 p.m.
On 9/20/2013 3:45 AM, Marek Vasut wrote:
> Dear Troy Kisky,
>
>> i.mx6 has 1 otg controller, and 3 host ports. So,
>> CONFIG_USB_MAX_CONTROLLER_COUNT can be greater than 1
>> even though only 1 device mode controller is supported.
>>
>> Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
>>
> The problem is, will the 3 additional ports still work? I suspect they will, but
> then if you run 'usb reset', the gadget port will also be switched back into USB
> Host function, no
>
> Best regards,
> Marek Vasut
>
The next patch checks the OTG id before switching to host mode. If it is 
grounded, then it enters
host mode, otherwise it doesn't.  But, running 'usb reset' on a 
netconsole may kill your connection.
I haven't tested that.  Do you have a suggestion to fix that? I've been 
testing with tftp transfers only.

Thanks
Troy
Marek Vasut - Sept. 23, 2013, 12:05 a.m.
Dear Troy Kisky,

> On 9/20/2013 3:45 AM, Marek Vasut wrote:
> > Dear Troy Kisky,
> > 
> >> i.mx6 has 1 otg controller, and 3 host ports. So,
> >> CONFIG_USB_MAX_CONTROLLER_COUNT can be greater than 1
> >> even though only 1 device mode controller is supported.
> >> 
> >> Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
> > 
> > The problem is, will the 3 additional ports still work? I suspect they
> > will, but then if you run 'usb reset', the gadget port will also be
> > switched back into USB Host function, no
> > 
> > Best regards,
> > Marek Vasut
> 
> The next patch checks the OTG id before switching to host mode. If it is
> grounded, then it enters
> host mode, otherwise it doesn't.  But, running 'usb reset' on a
> netconsole may kill your connection.

It won't if you properly ignore rhis one controller depending on the OTG pin 
then, no ?

> I haven't tested that.  Do you have a suggestion to fix that? I've been
> testing with tftp transfers only.
> 
> Thanks
> Troy

Best regards,
Marek Vasut
Troy Kisky - Sept. 23, 2013, 8:23 p.m.
On 9/22/2013 5:05 PM, Marek Vasut wrote:
> Dear Troy Kisky,
>
>> On 9/20/2013 3:45 AM, Marek Vasut wrote:
>>> Dear Troy Kisky,
>>>
>>>> i.mx6 has 1 otg controller, and 3 host ports. So,
>>>> CONFIG_USB_MAX_CONTROLLER_COUNT can be greater than 1
>>>> even though only 1 device mode controller is supported.
>>>>
>>>> Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
>>> The problem is, will the 3 additional ports still work? I suspect they
>>> will, but then if you run 'usb reset', the gadget port will also be
>>> switched back into USB Host function, no
>>>
>>> Best regards,
>>> Marek Vasut
>> The next patch checks the OTG id before switching to host mode. If it is
>> grounded, then it enters
>> host mode, otherwise it doesn't.  But, running 'usb reset' on a
>> netconsole may kill your connection.
> It won't if you properly ignore rhis one controller depending on the OTG pin
> then, no ?
>
I can return an error code from ehci_hcd_init, so that ehci_reset will 
not be called. But then
usb_lowlevel_init will also return an error, which is good for the call 
from usb_init, but bad
for the call in usb_gadget_register_driver.

Perhaps I should return a 1, instead of 0, when the otg_id pin is high? 
And check for < 0
before aborting from usb_gadget_register_driver ?

Thanks
Troy
Troy Kisky - Sept. 23, 2013, 8:55 p.m.
On 9/23/2013 1:23 PM, Troy Kisky wrote:
> On 9/22/2013 5:05 PM, Marek Vasut wrote:
>> Dear Troy Kisky,
>>
>>> On 9/20/2013 3:45 AM, Marek Vasut wrote:
>>>> Dear Troy Kisky,
>>>>
>>>>> i.mx6 has 1 otg controller, and 3 host ports. So,
>>>>> CONFIG_USB_MAX_CONTROLLER_COUNT can be greater than 1
>>>>> even though only 1 device mode controller is supported.
>>>>>
>>>>> Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
>>>> The problem is, will the 3 additional ports still work? I suspect they
>>>> will, but then if you run 'usb reset', the gadget port will also be
>>>> switched back into USB Host function, no
>>>>
>>>> Best regards,
>>>> Marek Vasut
>>> The next patch checks the OTG id before switching to host mode. If 
>>> it is
>>> grounded, then it enters
>>> host mode, otherwise it doesn't.  But, running 'usb reset' on a
>>> netconsole may kill your connection.
>> It won't if you properly ignore rhis one controller depending on the 
>> OTG pin
>> then, no ?
>>
> I can return an error code from ehci_hcd_init, so that ehci_reset will 
> not be called. But then
> usb_lowlevel_init will also return an error, which is good for the 
> call from usb_init, but bad
> for the call in usb_gadget_register_driver.
>
> Perhaps I should return a 1, instead of 0, when the otg_id pin is 
> high? And check for < 0
> before aborting from usb_gadget_register_driver ?
>
> Thanks
> Troy
>
>
>
Or maybe add a parameter to usb_lowlevel_init specifying if I desire 
host or device mode?

Thanks
Troy
Marek Vasut - Sept. 23, 2013, 9:17 p.m.
Dear Troy Kisky,

> On 9/23/2013 1:23 PM, Troy Kisky wrote:
> > On 9/22/2013 5:05 PM, Marek Vasut wrote:
> >> Dear Troy Kisky,
> >> 
> >>> On 9/20/2013 3:45 AM, Marek Vasut wrote:
> >>>> Dear Troy Kisky,
> >>>> 
> >>>>> i.mx6 has 1 otg controller, and 3 host ports. So,
> >>>>> CONFIG_USB_MAX_CONTROLLER_COUNT can be greater than 1
> >>>>> even though only 1 device mode controller is supported.
> >>>>> 
> >>>>> Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
> >>>> 
> >>>> The problem is, will the 3 additional ports still work? I suspect they
> >>>> will, but then if you run 'usb reset', the gadget port will also be
> >>>> switched back into USB Host function, no
> >>>> 
> >>>> Best regards,
> >>>> Marek Vasut
> >>> 
> >>> The next patch checks the OTG id before switching to host mode. If
> >>> it is
> >>> grounded, then it enters
> >>> host mode, otherwise it doesn't.  But, running 'usb reset' on a
> >>> netconsole may kill your connection.
> >> 
> >> It won't if you properly ignore rhis one controller depending on the
> >> OTG pin
> >> then, no ?
> > 
> > I can return an error code from ehci_hcd_init, so that ehci_reset will
> > not be called. But then
> > usb_lowlevel_init will also return an error, which is good for the
> > call from usb_init, but bad
> > for the call in usb_gadget_register_driver.
> > 
> > Perhaps I should return a 1, instead of 0, when the otg_id pin is
> > high? And check for < 0
> > before aborting from usb_gadget_register_driver ?
> > 
> > Thanks
> > Troy
> 
> Or maybe add a parameter to usb_lowlevel_init specifying if I desire
> host or device mode?

Check

[PATCH v4] usb: new board-specific USB init interface

That might give you some ideas.

Best regards,
Marek Vasut

Patch

diff --git a/drivers/usb/gadget/mv_udc.c b/drivers/usb/gadget/mv_udc.c
index 7574e31..b87119c 100644
--- a/drivers/usb/gadget/mv_udc.c
+++ b/drivers/usb/gadget/mv_udc.c
@@ -17,10 +17,6 @@ 
 #include <linux/types.h>
 #include <usb/mv_udc.h>
 
-#if CONFIG_USB_MAX_CONTROLLER_COUNT > 1
-#error This driver only supports one single controller.
-#endif
-
 /*
  * Check if the system has too long cachelines. If the cachelines are
  * longer then 128b, the driver will not be able flush/invalidate data