[U-Boot] Doubt in USB driver for Vybrid vf610

[U-Boot] Doubt in USB driver for Vybrid vf610

[Santhosh]

Hi All,
I am working on USB part for vybrid vf-610 processor, We have two ports in the board

when I type usb start in uboot command prompt, It returns as ENODEV for USB0 and when analyzed, It is returning from the below code in ehci-hcd_init function(in ehci-vf.c)

        if (init == USB_INIT_HOST && index == 0)
                return -ENODEV;

 If these two  lines are commented, the usb start is working and device is found on USB0. 
Why is this check kept in the code? 

Regards,
Santhosh


::DISCLAIMER::
----------------------------------------------------------------------------------------------------------------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and other defects.

----------------------------------------------------------------------------------------------------------------------------------------------------

[U-Boot] Doubt in USB driver for Vybrid vf610

[maitysanchayan at gmail.com]

Hello,

On 15-10-16 16:20:07, Santhosh Kumar Janardhanam -ERS, HCL Tech wrote:
> Hi All,
> I am working on USB part for vybrid vf-610 processor, We have two ports in the board
> 
> when I type usb start in uboot command prompt, It returns as ENODEV for USB0 and when analyzed, It is returning from the below code in ehci-hcd_init function(in ehci-vf.c)
> 
>         if (init == USB_INIT_HOST && index == 0)
>                 return -ENODEV;
> 
>  If these two  lines are commented, the usb start is working and device is found on USB0. 
> Why is this check kept in the code? 

I am the author of the ehci-vf USB driver which is based on iMX6 implementation.
The implementation was done as per our requirements where we have one port as
host and another as client. In hindsight my implementation is severely restricting
and at that time I missed thinking of it and did not had other boards to test.

I will fix this up and send a patch. However I need to look a bit. The ideal way
would be to fix it up in board_ehci_hcd_init call however that does not provide
the init parameter to distinguish between USB_INIT_DEVICE and USB_INIT_HOST.

May I ask are you using some module or you have your custom setup around the
Vybrid? Sorry for the trouble. Thanks for reporting.

- Sanchayan.

>
> Regards,
> Santhosh
> 
> 
> ::DISCLAIMER::
> ----------------------------------------------------------------------------------------------------------------------------------------------------
> 
> The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
> E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted,
> lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents
> (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates.
> Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the
> views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,
> distribution and / or publication of this message without the prior written consent of authorized representative of
> HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately.
> Before opening any email and/or attachments, please check them for viruses and other defects.
> 
> ----------------------------------------------------------------------------------------------------------------------------------------------------
> 
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Doubt in USB driver for Vybrid vf610

[maitysanchayan at gmail.com]

Hello Marek,

On 15-10-17 21:59:07, maitysanchayan at gmail.com wrote:
> Hello,
> 
> On 15-10-16 16:20:07, Santhosh Kumar Janardhanam -ERS, HCL Tech wrote:
> > Hi All,
> > I am working on USB part for vybrid vf-610 processor, We have two ports in the board
> > 
> > when I type usb start in uboot command prompt, It returns as ENODEV for USB0 and when analyzed, It is returning from the below code in ehci-hcd_init function(in ehci-vf.c)
> > 
> >         if (init == USB_INIT_HOST && index == 0)
> >                 return -ENODEV;
> > 

Along with the above
if (init == USB_INIT_DEVICE && index == 1)
	return -ENODEV;

In the ehci-vf USB driver for Vybrid, currently we have two "if" cases as above which basically
serve the purpose of preventing one of the USB ports from being configured as host, which we
did like to keep as client. So for us, USB0 is client and USB1 is host and the above was put
in with that intention to prevent USB0 from being configured as host, when usb start is called.
However this is bad for other users out there, sorry about that.

I checked and it seems even without the above, if both ports are configured as host with usb
start and later dfu is called to used the intended as client for upgrade purposes, things still
seem to work. Not sure if there are cases where this can break which I am missing.

Not being that well versed with USB I wanted to ask is this ok or this is completely wrong?
If it is ok, I guess we can go ahead and nuke the above checks? OR will be it be a better
approach to introduce something like board_ehci_hch_init_with_type(int index, enum usb_init_type type)
which will be a weak function and then have the board specific code hook call it?

- Sanchayan.

> >  If these two  lines are commented, the usb start is working and device is found on USB0.
> > Why is this check kept in the code? 
> 
> I am the author of the ehci-vf USB driver which is based on iMX6 implementation.
> The implementation was done as per our requirements where we have one port as
> host and another as client. In hindsight my implementation is severely restricting
> and at that time I missed thinking of it and did not had other boards to test.
> 
> I will fix this up and send a patch. However I need to look a bit. The ideal way
> would be to fix it up in board_ehci_hcd_init call however that does not provide
> the init parameter to distinguish between USB_INIT_DEVICE and USB_INIT_HOST.
> 
> May I ask are you using some module or you have your custom setup around the
> Vybrid? Sorry for the trouble. Thanks for reporting.
> 
> - Sanchayan.
> 
> >
> > Regards,
> > Santhosh
> > 
> > 
> > ::DISCLAIMER::
> > ----------------------------------------------------------------------------------------------------------------------------------------------------
> > 
> > The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
> > E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted,
> > lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents
> > (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates.
> > Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the
> > views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,
> > distribution and / or publication of this message without the prior written consent of authorized representative of
> > HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately.
> > Before opening any email and/or attachments, please check them for viruses and other defects.
> > 
> > ----------------------------------------------------------------------------------------------------------------------------------------------------
> > 
> > _______________________________________________
> > U-Boot mailing list
> > U-Boot at lists.denx.de
> > http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Doubt in USB driver for Vybrid vf610

[Santhosh]

Hi Sanchayan,
We are using a custom board with vybrid processor,in which we need to configure USB0 as host and USB1 as client.

Regards,
Santhosh

-----Original Message-----
From: maitysanchayan@gmail.com [mailto:maitysanchayan at gmail.com] 
Sent: Monday, October 19, 2015 10:59 AM
To: marex at denx.de
Cc: u-boot at lists.denx.de; Santhosh Kumar Janardhanam -ERS, HCL Tech
Subject: Re: [U-Boot] Doubt in USB driver for Vybrid vf610

Hello Marek,

On 15-10-17 21:59:07, maitysanchayan at gmail.com wrote:
> Hello,
> 
> On 15-10-16 16:20:07, Santhosh Kumar Janardhanam -ERS, HCL Tech wrote:
> > Hi All,
> > I am working on USB part for vybrid vf-610 processor, We have two 
> > ports in the board
> > 
> > when I type usb start in uboot command prompt, It returns as ENODEV 
> > for USB0 and when analyzed, It is returning from the below code in 
> > ehci-hcd_init function(in ehci-vf.c)
> > 
> >         if (init == USB_INIT_HOST && index == 0)
> >                 return -ENODEV;
> > 

Along with the above
if (init == USB_INIT_DEVICE && index == 1)
	return -ENODEV;

In the ehci-vf USB driver for Vybrid, currently we have two "if" cases as above which basically serve the purpose of preventing one of the USB ports from being configured as host, which we did like to keep as client. So for us, USB0 is client and USB1 is host and the above was put in with that intention to prevent USB0 from being configured as host, when usb start is called.
However this is bad for other users out there, sorry about that.

I checked and it seems even without the above, if both ports are configured as host with usb start and later dfu is called to used the intended as client for upgrade purposes, things still seem to work. Not sure if there are cases where this can break which I am missing.

Not being that well versed with USB I wanted to ask is this ok or this is completely wrong?
If it is ok, I guess we can go ahead and nuke the above checks? OR will be it be a better approach to introduce something like board_ehci_hch_init_with_type(int index, enum usb_init_type type) which will be a weak function and then have the board specific code hook call it?

- Sanchayan.

> >  If these two  lines are commented, the usb start is working and device is found on USB0.
> > Why is this check kept in the code? 
> 
> I am the author of the ehci-vf USB driver which is based on iMX6 implementation.
> The implementation was done as per our requirements where we have one 
> port as host and another as client. In hindsight my implementation is 
> severely restricting and at that time I missed thinking of it and did not had other boards to test.
> 
> I will fix this up and send a patch. However I need to look a bit. The 
> ideal way would be to fix it up in board_ehci_hcd_init call however 
> that does not provide the init parameter to distinguish between USB_INIT_DEVICE and USB_INIT_HOST.
> 
> May I ask are you using some module or you have your custom setup 
> around the Vybrid? Sorry for the trouble. Thanks for reporting.
> 
> - Sanchayan.
> 
> >
> > Regards,
> > Santhosh
> > 
> > 
> > ::DISCLAIMER::
> > --------------------------------------------------------------------
> > --------------------------------------------------------------------
> > ------------
> > 
> > The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
> > E-mail transmission is not guaranteed to be secure or error-free as 
> > information could be intercepted, corrupted, lost, destroyed, arrive 
> > late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates.
> > Views or opinions, if any, presented in this email are solely those 
> > of the author and may not necessarily reflect the views or opinions 
> > of HCL or its affiliates. Any form of reproduction, dissemination, 
> > copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately.
> > Before opening any email and/or attachments, please check them for viruses and other defects.
> > 
> > --------------------------------------------------------------------
> > --------------------------------------------------------------------
> > ------------
> > 
> > _______________________________________________
> > U-Boot mailing list
> > U-Boot at lists.denx.de
> > http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Doubt in USB driver for Vybrid vf610

[maitysanchayan at gmail.com]

Hello Marek,

Any inputs on the below?

Thanks & Regards,
Sanchayan Maity.

On 15-10-19 10:58:47, maitysanchayan at gmail.com wrote:
> Hello Marek,
> 
> On 15-10-17 21:59:07, maitysanchayan at gmail.com wrote:
> > Hello,
> > 
> > On 15-10-16 16:20:07, Santhosh Kumar Janardhanam -ERS, HCL Tech wrote:
> > > Hi All,
> > > I am working on USB part for vybrid vf-610 processor, We have two ports in the board
> > > 
> > > when I type usb start in uboot command prompt, It returns as ENODEV for USB0 and when analyzed, It is returning from the below code in ehci-hcd_init function(in ehci-vf.c)
> > > 
> > >         if (init == USB_INIT_HOST && index == 0)
> > >                 return -ENODEV;
> > > 
> 
> Along with the above
> if (init == USB_INIT_DEVICE && index == 1)
> 	return -ENODEV;
> 
> In the ehci-vf USB driver for Vybrid, currently we have two "if" cases as above which basically
> serve the purpose of preventing one of the USB ports from being configured as host, which we
> did like to keep as client. So for us, USB0 is client and USB1 is host and the above was put
> in with that intention to prevent USB0 from being configured as host, when usb start is called.
> However this is bad for other users out there, sorry about that.
> 
> I checked and it seems even without the above, if both ports are configured as host with usb
> start and later dfu is called to used the intended as client for upgrade purposes, things still
> seem to work. Not sure if there are cases where this can break which I am missing.
> 
> Not being that well versed with USB I wanted to ask is this ok or this is completely wrong?
> If it is ok, I guess we can go ahead and nuke the above checks? OR will be it be a better
> approach to introduce something like board_ehci_hch_init_with_type(int index, enum usb_init_type type)
> which will be a weak function and then have the board specific code hook call it?
> 
> - Sanchayan.
> 
> > >  If these two  lines are commented, the usb start is working and device is found on USB0.
> > > Why is this check kept in the code? 
> > 
> > I am the author of the ehci-vf USB driver which is based on iMX6 implementation.
> > The implementation was done as per our requirements where we have one port as
> > host and another as client. In hindsight my implementation is severely restricting
> > and at that time I missed thinking of it and did not had other boards to test.
> > 
> > I will fix this up and send a patch. However I need to look a bit. The ideal way
> > would be to fix it up in board_ehci_hcd_init call however that does not provide
> > the init parameter to distinguish between USB_INIT_DEVICE and USB_INIT_HOST.
> > 
> > May I ask are you using some module or you have your custom setup around the
> > Vybrid? Sorry for the trouble. Thanks for reporting.
> > 
> > - Sanchayan.
> > 
> > >
> > > Regards,
> > > Santhosh
> > > 
> > > 
> > > ::DISCLAIMER::
> > > ----------------------------------------------------------------------------------------------------------------------------------------------------
> > > 
> > > The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
> > > E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted,
> > > lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents
> > > (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates.
> > > Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the
> > > views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,
> > > distribution and / or publication of this message without the prior written consent of authorized representative of
> > > HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately.
> > > Before opening any email and/or attachments, please check them for viruses and other defects.
> > > 
> > > ----------------------------------------------------------------------------------------------------------------------------------------------------
> > > 
> > > _______________________________________________
> > > U-Boot mailing list
> > > U-Boot at lists.denx.de
> > > http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Doubt in USB driver for Vybrid vf610

[Marek Vasut]

On Friday, October 23, 2015 at 07:18:44 AM, maitysanchayan at gmail.com wrote:
> Hello Marek,

Hi,

> Any inputs on the below?

I don't have a Vybrid device, CCing Fabio.

> Thanks & Regards,
> Sanchayan Maity.
> 
> On 15-10-19 10:58:47, maitysanchayan at gmail.com wrote:
> > Hello Marek,
> > 
> > On 15-10-17 21:59:07, maitysanchayan at gmail.com wrote:
> > > Hello,
> > > 
> > > On 15-10-16 16:20:07, Santhosh Kumar Janardhanam -ERS, HCL Tech wrote:
> > > > Hi All,
> > > > I am working on USB part for vybrid vf-610 processor, We have two
> > > > ports in the board
> > > > 
> > > > when I type usb start in uboot command prompt, It returns as ENODEV
> > > > for USB0 and when analyzed, It is returning from the below code in
> > > > ehci-hcd_init function(in ehci-vf.c)
> > > > 
> > > >         if (init == USB_INIT_HOST && index == 0)
> > > >         
> > > >                 return -ENODEV;
> > 
> > Along with the above
> > if (init == USB_INIT_DEVICE && index == 1)
> > 
> > 	return -ENODEV;
> > 
> > In the ehci-vf USB driver for Vybrid, currently we have two "if" cases as
> > above which basically serve the purpose of preventing one of the USB
> > ports from being configured as host, which we did like to keep as
> > client. So for us, USB0 is client and USB1 is host and the above was put
> > in with that intention to prevent USB0 from being configured as host,
> > when usb start is called. However this is bad for other users out there,
> > sorry about that.
> > 
> > I checked and it seems even without the above, if both ports are
> > configured as host with usb start and later dfu is called to used the
> > intended as client for upgrade purposes, things still seem to work. Not
> > sure if there are cases where this can break which I am missing.
> > 
> > Not being that well versed with USB I wanted to ask is this ok or this is
> > completely wrong? If it is ok, I guess we can go ahead and nuke the
> > above checks? OR will be it be a better approach to introduce something
> > like board_ehci_hch_init_with_type(int index, enum usb_init_type type)
> > which will be a weak function and then have the board specific code hook
> > call it?
> > 
> > - Sanchayan.
> > 
> > > >  If these two  lines are commented, the usb start is working and
> > > >  device is found on USB0.
> > > > 
> > > > Why is this check kept in the code?
> > > 
> > > I am the author of the ehci-vf USB driver which is based on iMX6
> > > implementation. The implementation was done as per our requirements
> > > where we have one port as host and another as client. In hindsight my
> > > implementation is severely restricting and at that time I missed
> > > thinking of it and did not had other boards to test.
> > > 
> > > I will fix this up and send a patch. However I need to look a bit. The
> > > ideal way would be to fix it up in board_ehci_hcd_init call however
> > > that does not provide the init parameter to distinguish between
> > > USB_INIT_DEVICE and USB_INIT_HOST.
> > > 
> > > May I ask are you using some module or you have your custom setup
> > > around the Vybrid? Sorry for the trouble. Thanks for reporting.
> > > 
> > > - Sanchayan.
> > > 
> > > > Regards,
> > > > Santhosh
> > > > 
> > > > ::DISCLAIMER::
> > > > ---------------------------------------------------------------------
> > > > ---------------------------------------------------------------------
> > > > ----------
> > > > 
> > > > The contents of this e-mail and any attachment(s) are confidential
> > > > and intended for the named recipient(s) only. E-mail transmission is
> > > > not guaranteed to be secure or error-free as information could be
> > > > intercepted, corrupted, lost, destroyed, arrive late or incomplete,
> > > > or may contain viruses in transmission. The e mail and its contents
> > > > (with or without referred errors) shall therefore not attach any
> > > > liability on the originator or HCL or its affiliates. Views or
> > > > opinions, if any, presented in this email are solely those of the
> > > > author and may not necessarily reflect the views or opinions of HCL
> > > > or its affiliates. Any form of reproduction, dissemination, copying,
> > > > disclosure, modification, distribution and / or publication of this
> > > > message without the prior written consent of authorized
> > > > representative of HCL is strictly prohibited. If you have received
> > > > this email in error please delete it and notify the sender
> > > > immediately. Before opening any email and/or attachments, please
> > > > check them for viruses and other defects.
> > > > 
> > > > ---------------------------------------------------------------------
> > > > ---------------------------------------------------------------------
> > > > ----------
> > > > 
> > > > _______________________________________________
> > > > U-Boot mailing list
> > > > U-Boot at lists.denx.de
> > > > http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Doubt in USB driver for Vybrid vf610

[Fabio Estevam]

Hi Marek,

On Fri, Oct 23, 2015 at 4:23 PM, Marek Vasut <marex@denx.de> wrote:

>> Any inputs on the below?
>
> I don't have a Vybrid device, CCing Fabio.

I don't have access to a Vybrid board either.

Sanchayan,

Does drivers/usb/host/ehci-mx6.c behave the same way?

Regards,

Fabio Estevam

[U-Boot] Doubt in USB driver for Vybrid vf610

[maitysanchayan at gmail.com]

Hello,

On 15-10-24 12:09:43, Fabio Estevam wrote:
> Hi Marek,
> 
> On Fri, Oct 23, 2015 at 4:23 PM, Marek Vasut <marex@denx.de> wrote:
> 
> >> Any inputs on the below?
> >
> > I don't have a Vybrid device, CCing Fabio.
> 
> I don't have access to a Vybrid board either.
> 
> Sanchayan,
> 
> Does drivers/usb/host/ehci-mx6.c behave the same way?

No.

I included the particular piece of code below


	if (init == USB_INIT_DEVICE && index == 1)
		return -ENODEV;
	if (init == USB_INIT_HOST && index == 0)
		return -ENODEV;

in the ehci-vf driver because our requirement was to have one port
as client and other as host. Since on USB start both ports get configured
as host as it iterates depending on USB EHCI controller count, the above
was meant to stop the port required as client to be configured as host and
vice versa while using client functionality such as DFU.

I made the mistake of not thinking that this is not a generic use case,
someone might want it the other way around or such.

So coming to the main question, what would be the correct way to fix this?
I tested that even if the above four lines are removed and USB start configures
both ports as host, calling dfu later will still result in correct functioning.
So is this ok and the four lines should be nuked or a more appropriate way would
be to add something like board_ehci_hcd_init_with_type(int index, enum usb_init
_type init) which would be a weak function and have the board specific code call
this to do the above which is currently done in ehci-vf.

I wasn't sure about the right approach to take so I asked.

Thanks & Regards,
Sanchayan.

[U-Boot] Doubt in USB driver for Vybrid vf610

[Marek Vasut]

On Saturday, October 24, 2015 at 05:23:05 PM, maitysanchayan at gmail.com wrote:
> Hello,
> 
> On 15-10-24 12:09:43, Fabio Estevam wrote:
> > Hi Marek,
> > 
> > On Fri, Oct 23, 2015 at 4:23 PM, Marek Vasut <marex@denx.de> wrote:
> > >> Any inputs on the below?
> > > 
> > > I don't have a Vybrid device, CCing Fabio.
> > 
> > I don't have access to a Vybrid board either.
> > 
> > Sanchayan,
> > 
> > Does drivers/usb/host/ehci-mx6.c behave the same way?
> 
> No.
> 
> I included the particular piece of code below
> 
> 
> 	if (init == USB_INIT_DEVICE && index == 1)
> 		return -ENODEV;
> 	if (init == USB_INIT_HOST && index == 0)
> 		return -ENODEV;
> 
> in the ehci-vf driver because our requirement was to have one port
> as client and other as host. Since on USB start both ports get configured
> as host as it iterates depending on USB EHCI controller count, the above
> was meant to stop the port required as client to be configured as host and
> vice versa while using client functionality such as DFU.
> 
> I made the mistake of not thinking that this is not a generic use case,
> someone might want it the other way around or such.
>
> So coming to the main question, what would be the correct way to fix this?
> I tested that even if the above four lines are removed and USB start
> configures both ports as host, calling dfu later will still result in
> correct functioning. So is this ok and the four lines should be nuked or a
> more appropriate way would be to add something like
> board_ehci_hcd_init_with_type(int index, enum usb_init _type init) which
> would be a weak function and have the board specific code call this to do
> the above which is currently done in ehci-vf.
> 
> I wasn't sure about the right approach to take so I asked.

Brief glare over the driver tells me that those four lines are complete nonsense
and should be removed.

Best regards,
Marek Vasut

[U-Boot] Doubt in USB driver for Vybrid vf610

[maitysanchayan at gmail.com]

On 15-10-24 18:08:53, Marek Vasut wrote:
> On Saturday, October 24, 2015 at 05:23:05 PM, maitysanchayan at gmail.com wrote:
> > Hello,
> > 
> > On 15-10-24 12:09:43, Fabio Estevam wrote:
> > > Hi Marek,
> > > 
> > > On Fri, Oct 23, 2015 at 4:23 PM, Marek Vasut <marex@denx.de> wrote:
> > > >> Any inputs on the below?
> > > > 
> > > > I don't have a Vybrid device, CCing Fabio.
> > > 
> > > I don't have access to a Vybrid board either.
> > > 
> > > Sanchayan,
> > > 
> > > Does drivers/usb/host/ehci-mx6.c behave the same way?
> > 
> > No.
> > 
> > I included the particular piece of code below
> > 
> > 
> > 	if (init == USB_INIT_DEVICE && index == 1)
> > 		return -ENODEV;
> > 	if (init == USB_INIT_HOST && index == 0)
> > 		return -ENODEV;
> > 
> > in the ehci-vf driver because our requirement was to have one port
> > as client and other as host. Since on USB start both ports get configured
> > as host as it iterates depending on USB EHCI controller count, the above
> > was meant to stop the port required as client to be configured as host and
> > vice versa while using client functionality such as DFU.
> > 
> > I made the mistake of not thinking that this is not a generic use case,
> > someone might want it the other way around or such.
> >
> > So coming to the main question, what would be the correct way to fix this?
> > I tested that even if the above four lines are removed and USB start
> > configures both ports as host, calling dfu later will still result in
> > correct functioning. So is this ok and the four lines should be nuked or a
> > more appropriate way would be to add something like
> > board_ehci_hcd_init_with_type(int index, enum usb_init _type init) which
> > would be a weak function and have the board specific code call this to do
> > the above which is currently done in ehci-vf.
> > 
> > I wasn't sure about the right approach to take so I asked.
> 
> Brief glare over the driver tells me that those four lines are complete nonsense
> and should be removed.

Yes very much so. But is removing just ok or it would be better to actually
restrict as per a board's requirement what gets configured as host and what
gets configured as client by adding the weak function hook I was talking
about?

- Sanchayan.

[U-Boot] Doubt in USB driver for Vybrid vf610

[Marek Vasut]

On Saturday, October 24, 2015 at 06:08:57 PM, maitysanchayan at gmail.com wrote:
> On 15-10-24 18:08:53, Marek Vasut wrote:
> > On Saturday, October 24, 2015 at 05:23:05 PM, maitysanchayan at gmail.com 
wrote:
> > > Hello,
> > > 
> > > On 15-10-24 12:09:43, Fabio Estevam wrote:
> > > > Hi Marek,
> > > > 
> > > > On Fri, Oct 23, 2015 at 4:23 PM, Marek Vasut <marex@denx.de> wrote:
> > > > >> Any inputs on the below?
> > > > > 
> > > > > I don't have a Vybrid device, CCing Fabio.
> > > > 
> > > > I don't have access to a Vybrid board either.
> > > > 
> > > > Sanchayan,
> > > > 
> > > > Does drivers/usb/host/ehci-mx6.c behave the same way?
> > > 
> > > No.
> > > 
> > > I included the particular piece of code below
> > > 
> > > 	if (init == USB_INIT_DEVICE && index == 1)
> > > 	
> > > 		return -ENODEV;
> > > 	
> > > 	if (init == USB_INIT_HOST && index == 0)
> > > 	
> > > 		return -ENODEV;
> > > 
> > > in the ehci-vf driver because our requirement was to have one port
> > > as client and other as host. Since on USB start both ports get
> > > configured as host as it iterates depending on USB EHCI controller
> > > count, the above was meant to stop the port required as client to be
> > > configured as host and vice versa while using client functionality
> > > such as DFU.
> > > 
> > > I made the mistake of not thinking that this is not a generic use case,
> > > someone might want it the other way around or such.
> > > 
> > > So coming to the main question, what would be the correct way to fix
> > > this? I tested that even if the above four lines are removed and USB
> > > start configures both ports as host, calling dfu later will still
> > > result in correct functioning. So is this ok and the four lines should
> > > be nuked or a more appropriate way would be to add something like
> > > board_ehci_hcd_init_with_type(int index, enum usb_init _type init)
> > > which would be a weak function and have the board specific code call
> > > this to do the above which is currently done in ehci-vf.
> > > 
> > > I wasn't sure about the right approach to take so I asked.
> > 
> > Brief glare over the driver tells me that those four lines are complete
> > nonsense and should be removed.
> 
> Yes very much so. But is removing just ok or it would be better to actually
> restrict as per a board's requirement what gets configured as host and what
> gets configured as client by adding the weak function hook I was talking
> about?

The mx6 ones does board_usb_phy_mode() to determine this restriction. But (!)
it'd be even better if this information was obtained from DT. It'd be nice
if someone started working on converting i.MX to DT.

Best regards,
Marek Vasut

[U-Boot] Doubt in USB driver for Vybrid vf610

[maitysanchayan at gmail.com]

On 15-10-24 18:16:20, Marek Vasut wrote:
> On Saturday, October 24, 2015 at 06:08:57 PM, maitysanchayan at gmail.com wrote:
> > On 15-10-24 18:08:53, Marek Vasut wrote:
> > > On Saturday, October 24, 2015 at 05:23:05 PM, maitysanchayan at gmail.com 
> wrote:
> > > > Hello,
> > > > 
> > > > On 15-10-24 12:09:43, Fabio Estevam wrote:
> > > > > Hi Marek,
> > > > > 
> > > > > On Fri, Oct 23, 2015 at 4:23 PM, Marek Vasut <marex@denx.de> wrote:
> > > > > >> Any inputs on the below?
> > > > > > 
> > > > > > I don't have a Vybrid device, CCing Fabio.
> > > > > 
> > > > > I don't have access to a Vybrid board either.
> > > > > 
> > > > > Sanchayan,
> > > > > 
> > > > > Does drivers/usb/host/ehci-mx6.c behave the same way?
> > > > 
> > > > No.
> > > > 
> > > > I included the particular piece of code below
> > > > 
> > > > 	if (init == USB_INIT_DEVICE && index == 1)
> > > > 	
> > > > 		return -ENODEV;
> > > > 	
> > > > 	if (init == USB_INIT_HOST && index == 0)
> > > > 	
> > > > 		return -ENODEV;
> > > > 
> > > > in the ehci-vf driver because our requirement was to have one port
> > > > as client and other as host. Since on USB start both ports get
> > > > configured as host as it iterates depending on USB EHCI controller
> > > > count, the above was meant to stop the port required as client to be
> > > > configured as host and vice versa while using client functionality
> > > > such as DFU.
> > > > 
> > > > I made the mistake of not thinking that this is not a generic use case,
> > > > someone might want it the other way around or such.
> > > > 
> > > > So coming to the main question, what would be the correct way to fix
> > > > this? I tested that even if the above four lines are removed and USB
> > > > start configures both ports as host, calling dfu later will still
> > > > result in correct functioning. So is this ok and the four lines should
> > > > be nuked or a more appropriate way would be to add something like
> > > > board_ehci_hcd_init_with_type(int index, enum usb_init _type init)
> > > > which would be a weak function and have the board specific code call
> > > > this to do the above which is currently done in ehci-vf.
> > > > 
> > > > I wasn't sure about the right approach to take so I asked.
> > > 
> > > Brief glare over the driver tells me that those four lines are complete
> > > nonsense and should be removed.
> > 
> > Yes very much so. But is removing just ok or it would be better to actually
> > restrict as per a board's requirement what gets configured as host and what
> > gets configured as client by adding the weak function hook I was talking
> > about?
> 
> The mx6 ones does board_usb_phy_mode() to determine this restriction. But (!)
> it'd be even better if this information was obtained from DT. It'd be nice
> if someone started working on converting i.MX to DT.

Yes, that's how iMX6 does it. However note that Vybrid USB is not a true OTG.

I quote the Vybrid TRM here,

"The USB is not a true OTG. It can be configured by software to function either
as a peripheral or as host. The ID pin, which is unique for OTG operation, is
not present in this implementation. There are no five pin interface. The user
will get four pin host/device interface."

As per 44.2.1.2 of the Vybrid TRM.

- Sanchayan.

[U-Boot] Doubt in USB driver for Vybrid vf610

[Marek Vasut]

On Saturday, October 24, 2015 at 06:23:44 PM, maitysanchayan at gmail.com wrote:
> On 15-10-24 18:16:20, Marek Vasut wrote:
> > On Saturday, October 24, 2015 at 06:08:57 PM, maitysanchayan at gmail.com 
wrote:
> > > On 15-10-24 18:08:53, Marek Vasut wrote:
> > > > On Saturday, October 24, 2015 at 05:23:05 PM,
> > > > maitysanchayan at gmail.com
> > 
> > wrote:
> > > > > Hello,
> > > > > 
> > > > > On 15-10-24 12:09:43, Fabio Estevam wrote:
> > > > > > Hi Marek,
> > > > > > 
> > > > > > On Fri, Oct 23, 2015 at 4:23 PM, Marek Vasut <marex@denx.de> wrote:
> > > > > > >> Any inputs on the below?
> > > > > > > 
> > > > > > > I don't have a Vybrid device, CCing Fabio.
> > > > > > 
> > > > > > I don't have access to a Vybrid board either.
> > > > > > 
> > > > > > Sanchayan,
> > > > > > 
> > > > > > Does drivers/usb/host/ehci-mx6.c behave the same way?
> > > > > 
> > > > > No.
> > > > > 
> > > > > I included the particular piece of code below
> > > > > 
> > > > > 	if (init == USB_INIT_DEVICE && index == 1)
> > > > > 	
> > > > > 		return -ENODEV;
> > > > > 	
> > > > > 	if (init == USB_INIT_HOST && index == 0)
> > > > > 	
> > > > > 		return -ENODEV;
> > > > > 
> > > > > in the ehci-vf driver because our requirement was to have one port
> > > > > as client and other as host. Since on USB start both ports get
> > > > > configured as host as it iterates depending on USB EHCI controller
> > > > > count, the above was meant to stop the port required as client to
> > > > > be configured as host and vice versa while using client
> > > > > functionality such as DFU.
> > > > > 
> > > > > I made the mistake of not thinking that this is not a generic use
> > > > > case, someone might want it the other way around or such.
> > > > > 
> > > > > So coming to the main question, what would be the correct way to
> > > > > fix this? I tested that even if the above four lines are removed
> > > > > and USB start configures both ports as host, calling dfu later
> > > > > will still result in correct functioning. So is this ok and the
> > > > > four lines should be nuked or a more appropriate way would be to
> > > > > add something like board_ehci_hcd_init_with_type(int index, enum
> > > > > usb_init _type init) which would be a weak function and have the
> > > > > board specific code call this to do the above which is currently
> > > > > done in ehci-vf.
> > > > > 
> > > > > I wasn't sure about the right approach to take so I asked.
> > > > 
> > > > Brief glare over the driver tells me that those four lines are
> > > > complete nonsense and should be removed.
> > > 
> > > Yes very much so. But is removing just ok or it would be better to
> > > actually restrict as per a board's requirement what gets configured as
> > > host and what gets configured as client by adding the weak function
> > > hook I was talking about?
> > 
> > The mx6 ones does board_usb_phy_mode() to determine this restriction. But
> > (!) it'd be even better if this information was obtained from DT. It'd
> > be nice if someone started working on converting i.MX to DT.
> 
> Yes, that's how iMX6 does it. However note that Vybrid USB is not a true
> OTG.
> 
> I quote the Vybrid TRM here,
> 
> "The USB is not a true OTG. It can be configured by software to function
> either as a peripheral or as host. The ID pin, which is unique for OTG
> operation, is not present in this implementation. There are no five pin
> interface. The user will get four pin host/device interface."

Can't the user use a GPIO instead of dedicated OTG switch pin ?

[U-Boot] Doubt in USB driver for Vybrid vf610

[maitysanchayan at gmail.com]

On 15-10-24 19:50:13, Marek Vasut wrote:
> On Saturday, October 24, 2015 at 06:23:44 PM, maitysanchayan at gmail.com wrote:
> > On 15-10-24 18:16:20, Marek Vasut wrote:
> > > On Saturday, October 24, 2015 at 06:08:57 PM, maitysanchayan at gmail.com 
> wrote:
> > > > On 15-10-24 18:08:53, Marek Vasut wrote:
> > > > > On Saturday, October 24, 2015 at 05:23:05 PM,
> > > > > maitysanchayan at gmail.com
> > > 
> > > wrote:
> > > > > > Hello,
> > > > > > 
> > > > > > On 15-10-24 12:09:43, Fabio Estevam wrote:
> > > > > > > Hi Marek,
> > > > > > > 
> > > > > > > On Fri, Oct 23, 2015 at 4:23 PM, Marek Vasut <marex@denx.de> wrote:
> > > > > > > >> Any inputs on the below?
> > > > > > > > 
> > > > > > > > I don't have a Vybrid device, CCing Fabio.
> > > > > > > 
> > > > > > > I don't have access to a Vybrid board either.
> > > > > > > 
> > > > > > > Sanchayan,
> > > > > > > 
> > > > > > > Does drivers/usb/host/ehci-mx6.c behave the same way?
> > > > > > 
> > > > > > No.
> > > > > > 
> > > > > > I included the particular piece of code below
> > > > > > 
> > > > > > 	if (init == USB_INIT_DEVICE && index == 1)
> > > > > > 	
> > > > > > 		return -ENODEV;
> > > > > > 	
> > > > > > 	if (init == USB_INIT_HOST && index == 0)
> > > > > > 	
> > > > > > 		return -ENODEV;
> > > > > > 
> > > > > > in the ehci-vf driver because our requirement was to have one port
> > > > > > as client and other as host. Since on USB start both ports get
> > > > > > configured as host as it iterates depending on USB EHCI controller
> > > > > > count, the above was meant to stop the port required as client to
> > > > > > be configured as host and vice versa while using client
> > > > > > functionality such as DFU.
> > > > > > 
> > > > > > I made the mistake of not thinking that this is not a generic use
> > > > > > case, someone might want it the other way around or such.
> > > > > > 
> > > > > > So coming to the main question, what would be the correct way to
> > > > > > fix this? I tested that even if the above four lines are removed
> > > > > > and USB start configures both ports as host, calling dfu later
> > > > > > will still result in correct functioning. So is this ok and the
> > > > > > four lines should be nuked or a more appropriate way would be to
> > > > > > add something like board_ehci_hcd_init_with_type(int index, enum
> > > > > > usb_init _type init) which would be a weak function and have the
> > > > > > board specific code call this to do the above which is currently
> > > > > > done in ehci-vf.
> > > > > > 
> > > > > > I wasn't sure about the right approach to take so I asked.
> > > > > 
> > > > > Brief glare over the driver tells me that those four lines are
> > > > > complete nonsense and should be removed.
> > > > 
> > > > Yes very much so. But is removing just ok or it would be better to
> > > > actually restrict as per a board's requirement what gets configured as
> > > > host and what gets configured as client by adding the weak function
> > > > hook I was talking about?
> > > 
> > > The mx6 ones does board_usb_phy_mode() to determine this restriction. But
> > > (!) it'd be even better if this information was obtained from DT. It'd
> > > be nice if someone started working on converting i.MX to DT.
> > 
> > Yes, that's how iMX6 does it. However note that Vybrid USB is not a true
> > OTG.
> > 
> > I quote the Vybrid TRM here,
> > 
> > "The USB is not a true OTG. It can be configured by software to function
> > either as a peripheral or as host. The ID pin, which is unique for OTG
> > operation, is not present in this implementation. There are no five pin
> > interface. The user will get four pin host/device interface."
> 
> Can't the user use a GPIO instead of dedicated OTG switch pin ?

Yes. In fact in Linux we use the extcon framework along with the GPIO to have
automatic switch over between client and host.

I will send a patch by Monday to remove the incorrect code. Will later send
a patch to incoporate the correct fix. Since all boards might not have a GPIO
to do this I had not considered this option but if this is acceptable it is
fine by me.

Thanks.

- Sanchayan.

[U-Boot] Doubt in USB driver for Vybrid vf610

[Marek Vasut]

On Saturday, October 24, 2015 at 08:19:36 PM, maitysanchayan at gmail.com wrote:
> On 15-10-24 19:50:13, Marek Vasut wrote:
> > On Saturday, October 24, 2015 at 06:23:44 PM, maitysanchayan at gmail.com 
wrote:
> > > On 15-10-24 18:16:20, Marek Vasut wrote:
> > > > On Saturday, October 24, 2015 at 06:08:57 PM,
> > > > maitysanchayan at gmail.com
> > 
> > wrote:
> > > > > On 15-10-24 18:08:53, Marek Vasut wrote:
> > > > > > On Saturday, October 24, 2015 at 05:23:05 PM,
> > > > > > maitysanchayan at gmail.com
> > > > 
> > > > wrote:
> > > > > > > Hello,
> > > > > > > 
> > > > > > > On 15-10-24 12:09:43, Fabio Estevam wrote:
> > > > > > > > Hi Marek,
> > > > > > > > 
> > > > > > > > On Fri, Oct 23, 2015 at 4:23 PM, Marek Vasut <marex@denx.de> 
wrote:
> > > > > > > > >> Any inputs on the below?
> > > > > > > > > 
> > > > > > > > > I don't have a Vybrid device, CCing Fabio.
> > > > > > > > 
> > > > > > > > I don't have access to a Vybrid board either.
> > > > > > > > 
> > > > > > > > Sanchayan,
> > > > > > > > 
> > > > > > > > Does drivers/usb/host/ehci-mx6.c behave the same way?
> > > > > > > 
> > > > > > > No.
> > > > > > > 
> > > > > > > I included the particular piece of code below
> > > > > > > 
> > > > > > > 	if (init == USB_INIT_DEVICE && index == 1)
> > > > > > > 	
> > > > > > > 		return -ENODEV;
> > > > > > > 	
> > > > > > > 	if (init == USB_INIT_HOST && index == 0)
> > > > > > > 	
> > > > > > > 		return -ENODEV;
> > > > > > > 
> > > > > > > in the ehci-vf driver because our requirement was to have one
> > > > > > > port as client and other as host. Since on USB start both
> > > > > > > ports get configured as host as it iterates depending on USB
> > > > > > > EHCI controller count, the above was meant to stop the port
> > > > > > > required as client to be configured as host and vice versa
> > > > > > > while using client functionality such as DFU.
> > > > > > > 
> > > > > > > I made the mistake of not thinking that this is not a generic
> > > > > > > use case, someone might want it the other way around or such.
> > > > > > > 
> > > > > > > So coming to the main question, what would be the correct way
> > > > > > > to fix this? I tested that even if the above four lines are
> > > > > > > removed and USB start configures both ports as host, calling
> > > > > > > dfu later will still result in correct functioning. So is this
> > > > > > > ok and the four lines should be nuked or a more appropriate
> > > > > > > way would be to add something like
> > > > > > > board_ehci_hcd_init_with_type(int index, enum usb_init _type
> > > > > > > init) which would be a weak function and have the board
> > > > > > > specific code call this to do the above which is currently
> > > > > > > done in ehci-vf.
> > > > > > > 
> > > > > > > I wasn't sure about the right approach to take so I asked.
> > > > > > 
> > > > > > Brief glare over the driver tells me that those four lines are
> > > > > > complete nonsense and should be removed.
> > > > > 
> > > > > Yes very much so. But is removing just ok or it would be better to
> > > > > actually restrict as per a board's requirement what gets configured
> > > > > as host and what gets configured as client by adding the weak
> > > > > function hook I was talking about?
> > > > 
> > > > The mx6 ones does board_usb_phy_mode() to determine this restriction.
> > > > But (!) it'd be even better if this information was obtained from
> > > > DT. It'd be nice if someone started working on converting i.MX to
> > > > DT.
> > > 
> > > Yes, that's how iMX6 does it. However note that Vybrid USB is not a
> > > true OTG.
> > > 
> > > I quote the Vybrid TRM here,
> > > 
> > > "The USB is not a true OTG. It can be configured by software to
> > > function either as a peripheral or as host. The ID pin, which is
> > > unique for OTG operation, is not present in this implementation. There
> > > are no five pin interface. The user will get four pin host/device
> > > interface."
> > 
> > Can't the user use a GPIO instead of dedicated OTG switch pin ?
> 
> Yes. In fact in Linux we use the extcon framework along with the GPIO to
> have automatic switch over between client and host.
> 
> I will send a patch by Monday to remove the incorrect code. Will later send
> a patch to incoporate the correct fix. Since all boards might not have a
> GPIO to do this I had not considered this option but if this is acceptable
> it is fine by me.

The boards should be able to implement such a GPIO-based switching in the
board_usb_phy_mode(), no ?

btw please send both patches at the same time, this "later" usually means
"never" in my opinion.