| Message ID | 1373486709-13015-6-git-send-email-dmurphy@ti.com |
|---|---|
| State | Superseded |
| Delegated to: | Tom Rini |
| Headers | show |
Dear Dan Murphy, > Add a __weak function that can be overridden to reset devices > attached to an ehci devices after the FEAT_POWER has been submitted > > Signed-off-by: Dan Murphy <dmurphy@ti.com> > --- > drivers/usb/host/ehci-hcd.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c > index 706cf0c..fdd3994 100644 > --- a/drivers/usb/host/ehci-hcd.c > +++ b/drivers/usb/host/ehci-hcd.c > @@ -616,6 +616,11 @@ __weak uint32_t *ehci_get_portsc_register(struct > ehci_hcor *hcor, int port) return (uint32_t *)&hcor->or_portsc[port]; > } > > +__weak void ehci_reset_attached_devices(int port) > +{ > + return; > +} > + Can the reset not happen elsewhere? > int > ehci_submit_root(struct usb_device *dev, unsigned long pipe, void *buffer, > int length, struct devrequest *req) > @@ -777,6 +782,7 @@ ehci_submit_root(struct usb_device *dev, unsigned long > pipe, void *buffer, reg |= EHCI_PS_PP; > ehci_writel(status_reg, reg); > } > + ehci_reset_attached_devices(port); > break; > case USB_PORT_FEAT_RESET: > if ((reg & (EHCI_PS_PE | EHCI_PS_CS)) == EHCI_PS_CS && > @@ -794,6 +800,7 @@ ehci_submit_root(struct usb_device *dev, unsigned long > pipe, void *buffer, reg |= EHCI_PS_PR; > reg &= ~EHCI_PS_PE; > ehci_writel(status_reg, reg); > + NAK > /* > * caller must wait, then call GetPortStatus > * usb 2.0 specification say 50 ms resets on Best regards, Marek Vasut
On 07/10/2013 05:20 PM, Marek Vasut wrote: > Dear Dan Murphy, > >> Add a __weak function that can be overridden to reset devices >> attached to an ehci devices after the FEAT_POWER has been submitted >> >> Signed-off-by: Dan Murphy <dmurphy@ti.com> >> --- >> drivers/usb/host/ehci-hcd.c | 7 +++++++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c >> index 706cf0c..fdd3994 100644 >> --- a/drivers/usb/host/ehci-hcd.c >> +++ b/drivers/usb/host/ehci-hcd.c >> @@ -616,6 +616,11 @@ __weak uint32_t *ehci_get_portsc_register(struct >> ehci_hcor *hcor, int port) return (uint32_t *)&hcor->or_portsc[port]; >> } >> >> +__weak void ehci_reset_attached_devices(int port) >> +{ >> + return; >> +} >> + > Can the reset not happen elsewhere? I have tried to move this around and keep this out of this file completely but nothing else seems to work. For port 2 where the USB3530 is we don't have the issue the 3530 enumerates properly. I did not see any information in the data sheet eluding to a timing issue. > >> int >> ehci_submit_root(struct usb_device *dev, unsigned long pipe, void *buffer, >> int length, struct devrequest *req) >> @@ -777,6 +782,7 @@ ehci_submit_root(struct usb_device *dev, unsigned long >> pipe, void *buffer, reg |= EHCI_PS_PP; >> ehci_writel(status_reg, reg); >> } >> + ehci_reset_attached_devices(port); >> break; >> case USB_PORT_FEAT_RESET: >> if ((reg & (EHCI_PS_PE | EHCI_PS_CS)) == EHCI_PS_CS && >> @@ -794,6 +800,7 @@ ehci_submit_root(struct usb_device *dev, unsigned long >> pipe, void *buffer, reg |= EHCI_PS_PR; >> reg &= ~EHCI_PS_PE; >> ehci_writel(status_reg, reg); >> + > NAK DOH! > >> /* >> * caller must wait, then call GetPortStatus >> * usb 2.0 specification say 50 ms resets on > Best regards, > Marek Vasut
On 07/11/2013 02:16 AM, Dan Murphy wrote: > On 07/10/2013 05:20 PM, Marek Vasut wrote: >> Dear Dan Murphy, >> >>> Add a __weak function that can be overridden to reset devices >>> attached to an ehci devices after the FEAT_POWER has been submitted >>> >>> Signed-off-by: Dan Murphy <dmurphy@ti.com> >>> --- >>> drivers/usb/host/ehci-hcd.c | 7 +++++++ >>> 1 file changed, 7 insertions(+) >>> >>> diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c >>> index 706cf0c..fdd3994 100644 >>> --- a/drivers/usb/host/ehci-hcd.c >>> +++ b/drivers/usb/host/ehci-hcd.c >>> @@ -616,6 +616,11 @@ __weak uint32_t *ehci_get_portsc_register(struct >>> ehci_hcor *hcor, int port) return (uint32_t *)&hcor->or_portsc[port]; >>> } >>> >>> +__weak void ehci_reset_attached_devices(int port) >>> +{ >>> + return; >>> +} Does this function need to be ehci specific? Other USB controllers might also need such a function. >>> + >> Can the reset not happen elsewhere? > I have tried to move this around and keep this out of this file completely but nothing else seems to work. > > For port 2 where the USB3530 is we don't have the issue the 3530 enumerates properly. > > I did not see any information in the data sheet eluding to a timing issue. This is the information I had received earlier from SMSC about USB3503A hub "You need the host up and running, and ready to go, THEN negate RESET_N. That is probably 95% of the issues." Please make sure the following sequence is done. - power up hub (RESET is active at this point). - start USB controller - wait a few ms - release hub RESET. giving a quick look at the u-boot code it seems you need to release the hub reset after usb_lowlevel_init() _OR_ usb_init() returns. cheers, -roger
Dear Roger Quadros, > On 07/11/2013 02:16 AM, Dan Murphy wrote: > > On 07/10/2013 05:20 PM, Marek Vasut wrote: > >> Dear Dan Murphy, > >> > >>> Add a __weak function that can be overridden to reset devices > >>> attached to an ehci devices after the FEAT_POWER has been submitted > >>> > >>> Signed-off-by: Dan Murphy <dmurphy@ti.com> > >>> --- > >>> > >>> drivers/usb/host/ehci-hcd.c | 7 +++++++ > >>> 1 file changed, 7 insertions(+) > >>> > >>> diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c > >>> index 706cf0c..fdd3994 100644 > >>> --- a/drivers/usb/host/ehci-hcd.c > >>> +++ b/drivers/usb/host/ehci-hcd.c > >>> @@ -616,6 +616,11 @@ __weak uint32_t *ehci_get_portsc_register(struct > >>> ehci_hcor *hcor, int port) return (uint32_t *)&hcor->or_portsc[port]; > >>> > >>> } > >>> > >>> +__weak void ehci_reset_attached_devices(int port) > >>> +{ > >>> + return; > >>> +} > > Does this function need to be ehci specific? Other USB controllers might > also need such a function. You'd need to implement this for each of the xHCIs > >>> + > >> > >> Can the reset not happen elsewhere? > > > > I have tried to move this around and keep this out of this file > > completely but nothing else seems to work. > > > > For port 2 where the USB3530 is we don't have the issue the 3530 > > enumerates properly. > > > > I did not see any information in the data sheet eluding to a timing > > issue. > > This is the information I had received earlier from SMSC about USB3503A hub > > "You need the host up and running, and ready to go, THEN negate RESET_N. > That is probably 95% of the issues." > > Please make sure the following sequence is done. > > - power up hub (RESET is active at this point). > - start USB controller > - wait a few ms > - release hub RESET. > > giving a quick look at the u-boot code it seems you need to release the hub > reset after usb_lowlevel_init() _OR_ usb_init() returns. Then it would also work in usb_lowlevel_init() ? Best regards, Marek Vasut
Hi Marek, On 07/11/2013 03:35 PM, Marek Vasut wrote: > Dear Roger Quadros, > >> On 07/11/2013 02:16 AM, Dan Murphy wrote: >>> On 07/10/2013 05:20 PM, Marek Vasut wrote: >>>> Dear Dan Murphy, >>>> >>>>> Add a __weak function that can be overridden to reset devices >>>>> attached to an ehci devices after the FEAT_POWER has been submitted >>>>> >>>>> Signed-off-by: Dan Murphy <dmurphy@ti.com> >>>>> --- >>>>> >>>>> drivers/usb/host/ehci-hcd.c | 7 +++++++ >>>>> 1 file changed, 7 insertions(+) >>>>> >>>>> diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c >>>>> index 706cf0c..fdd3994 100644 >>>>> --- a/drivers/usb/host/ehci-hcd.c >>>>> +++ b/drivers/usb/host/ehci-hcd.c >>>>> @@ -616,6 +616,11 @@ __weak uint32_t *ehci_get_portsc_register(struct >>>>> ehci_hcor *hcor, int port) return (uint32_t *)&hcor->or_portsc[port]; >>>>> >>>>> } >>>>> >>>>> +__weak void ehci_reset_attached_devices(int port) >>>>> +{ >>>>> + return; >>>>> +} >> >> Does this function need to be ehci specific? Other USB controllers might >> also need such a function. > > You'd need to implement this for each of the xHCIs OK. > >>>>> + >>>> >>>> Can the reset not happen elsewhere? >>> >>> I have tried to move this around and keep this out of this file >>> completely but nothing else seems to work. >>> >>> For port 2 where the USB3530 is we don't have the issue the 3530 >>> enumerates properly. >>> >>> I did not see any information in the data sheet eluding to a timing >>> issue. >> >> This is the information I had received earlier from SMSC about USB3503A hub >> >> "You need the host up and running, and ready to go, THEN negate RESET_N. >> That is probably 95% of the issues." >> >> Please make sure the following sequence is done. >> >> - power up hub (RESET is active at this point). >> - start USB controller >> - wait a few ms >> - release hub RESET. >> >> giving a quick look at the u-boot code it seems you need to release the hub >> reset after usb_lowlevel_init() _OR_ usb_init() returns. > > Then it would also work in usb_lowlevel_init() ? It should as long as we place the "release reset" after EHCI controller has started. Maybe safer to put it in the end of usb_lowlevel_init(). cheers, -roger
Roger On 07/11/2013 09:23 AM, Roger Quadros wrote: > Hi Marek, > > On 07/11/2013 03:35 PM, Marek Vasut wrote: >> Dear Roger Quadros, >> >>> On 07/11/2013 02:16 AM, Dan Murphy wrote: >>>> On 07/10/2013 05:20 PM, Marek Vasut wrote: >>>>> Dear Dan Murphy, >>>>> >>>>>> Add a __weak function that can be overridden to reset devices >>>>>> attached to an ehci devices after the FEAT_POWER has been submitted >>>>>> >>>>>> Signed-off-by: Dan Murphy <dmurphy@ti.com> >>>>>> --- >>>>>> >>>>>> drivers/usb/host/ehci-hcd.c | 7 +++++++ >>>>>> 1 file changed, 7 insertions(+) >>>>>> >>>>>> diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c >>>>>> index 706cf0c..fdd3994 100644 >>>>>> --- a/drivers/usb/host/ehci-hcd.c >>>>>> +++ b/drivers/usb/host/ehci-hcd.c >>>>>> @@ -616,6 +616,11 @@ __weak uint32_t *ehci_get_portsc_register(struct >>>>>> ehci_hcor *hcor, int port) return (uint32_t *)&hcor->or_portsc[port]; >>>>>> >>>>>> } >>>>>> >>>>>> +__weak void ehci_reset_attached_devices(int port) >>>>>> +{ >>>>>> + return; >>>>>> +} >>> Does this function need to be ehci specific? Other USB controllers might >>> also need such a function. >> You'd need to implement this for each of the xHCIs > OK. I can move the API to the usb-hub to call this after the FEAT_POWER is completed >>>>>> + >>>>> Can the reset not happen elsewhere? >>>> I have tried to move this around and keep this out of this file >>>> completely but nothing else seems to work. >>>> >>>> For port 2 where the USB3530 is we don't have the issue the 3530 >>>> enumerates properly. >>>> >>>> I did not see any information in the data sheet eluding to a timing >>>> issue. >>> This is the information I had received earlier from SMSC about USB3503A hub This has nothing to do with the 3503A this is the LAN9730. The 3503 works just fine without the additional reset. >>> >>> "You need the host up and running, and ready to go, THEN negate RESET_N. >>> That is probably 95% of the issues." >>> >>> Please make sure the following sequence is done. >>> >>> - power up hub (RESET is active at this point). >>> - start USB controller >>> - wait a few ms >>> - release hub RESET. >>> >>> giving a quick look at the u-boot code it seems you need to release the hub >>> reset after usb_lowlevel_init() _OR_ usb_init() returns. >> Then it would also work in usb_lowlevel_init() ? > It should as long as we place the "release reset" after EHCI controller > has started. Maybe safer to put it in the end of usb_lowlevel_init(). > > cheers, > -roger I moved the reset to the usb_lowlevel_init and it did not work. I tried holding the 9730 in reset until after ehci hcd init is complete and pulled it out of reset once the hcd is initialized but still no enumeration. Dan
Dear Roger Quadros, > Hi Marek, > > On 07/11/2013 03:35 PM, Marek Vasut wrote: > > Dear Roger Quadros, > > > >> On 07/11/2013 02:16 AM, Dan Murphy wrote: > >>> On 07/10/2013 05:20 PM, Marek Vasut wrote: > >>>> Dear Dan Murphy, > >>>> > >>>>> Add a __weak function that can be overridden to reset devices > >>>>> attached to an ehci devices after the FEAT_POWER has been submitted > >>>>> > >>>>> Signed-off-by: Dan Murphy <dmurphy@ti.com> > >>>>> --- > >>>>> > >>>>> drivers/usb/host/ehci-hcd.c | 7 +++++++ > >>>>> 1 file changed, 7 insertions(+) > >>>>> > >>>>> diff --git a/drivers/usb/host/ehci-hcd.c > >>>>> b/drivers/usb/host/ehci-hcd.c index 706cf0c..fdd3994 100644 > >>>>> --- a/drivers/usb/host/ehci-hcd.c > >>>>> +++ b/drivers/usb/host/ehci-hcd.c > >>>>> @@ -616,6 +616,11 @@ __weak uint32_t *ehci_get_portsc_register(struct > >>>>> ehci_hcor *hcor, int port) return (uint32_t *)&hcor->or_portsc[port]; > >>>>> > >>>>> } > >>>>> > >>>>> +__weak void ehci_reset_attached_devices(int port) > >>>>> +{ > >>>>> + return; > >>>>> +} > >> > >> Does this function need to be ehci specific? Other USB controllers might > >> also need such a function. > > > > You'd need to implement this for each of the xHCIs > > OK. > > >>>>> + > >>>> > >>>> Can the reset not happen elsewhere? > >>> > >>> I have tried to move this around and keep this out of this file > >>> completely but nothing else seems to work. > >>> > >>> For port 2 where the USB3530 is we don't have the issue the 3530 > >>> enumerates properly. > >>> > >>> I did not see any information in the data sheet eluding to a timing > >>> issue. > >> > >> This is the information I had received earlier from SMSC about USB3503A > >> hub > >> > >> "You need the host up and running, and ready to go, THEN negate RESET_N. > >> That is probably 95% of the issues." > >> > >> Please make sure the following sequence is done. > >> > >> - power up hub (RESET is active at this point). > >> - start USB controller > >> - wait a few ms > >> - release hub RESET. > >> > >> giving a quick look at the u-boot code it seems you need to release the > >> hub reset after usb_lowlevel_init() _OR_ usb_init() returns. > > > > Then it would also work in usb_lowlevel_init() ? > > It should as long as we place the "release reset" after EHCI controller > has started. Maybe safer to put it in the end of usb_lowlevel_init(). Can you maybe use any of the hooks efikamx uses ? board/genesi/mx51_efikamx/efikamx-usb.c Best regards, Marek Vasut
Dear Dan Murphy, > Roger > > On 07/11/2013 09:23 AM, Roger Quadros wrote: > > Hi Marek, > > > > On 07/11/2013 03:35 PM, Marek Vasut wrote: > >> Dear Roger Quadros, > >> > >>> On 07/11/2013 02:16 AM, Dan Murphy wrote: > >>>> On 07/10/2013 05:20 PM, Marek Vasut wrote: > >>>>> Dear Dan Murphy, > >>>>> > >>>>>> Add a __weak function that can be overridden to reset devices > >>>>>> attached to an ehci devices after the FEAT_POWER has been submitted > >>>>>> > >>>>>> Signed-off-by: Dan Murphy <dmurphy@ti.com> > >>>>>> --- > >>>>>> > >>>>>> drivers/usb/host/ehci-hcd.c | 7 +++++++ > >>>>>> 1 file changed, 7 insertions(+) > >>>>>> > >>>>>> diff --git a/drivers/usb/host/ehci-hcd.c > >>>>>> b/drivers/usb/host/ehci-hcd.c index 706cf0c..fdd3994 100644 > >>>>>> --- a/drivers/usb/host/ehci-hcd.c > >>>>>> +++ b/drivers/usb/host/ehci-hcd.c > >>>>>> @@ -616,6 +616,11 @@ __weak uint32_t > >>>>>> *ehci_get_portsc_register(struct ehci_hcor *hcor, int port) return > >>>>>> (uint32_t *)&hcor->or_portsc[port]; > >>>>>> > >>>>>> } > >>>>>> > >>>>>> +__weak void ehci_reset_attached_devices(int port) > >>>>>> +{ > >>>>>> + return; > >>>>>> +} > >>> > >>> Does this function need to be ehci specific? Other USB controllers > >>> might also need such a function. > >> > >> You'd need to implement this for each of the xHCIs > > > > OK. > > I can move the API to the usb-hub to call this after the FEAT_POWER is > completed > > >>>>>> + > >>>>> > >>>>> Can the reset not happen elsewhere? > >>>> > >>>> I have tried to move this around and keep this out of this file > >>>> completely but nothing else seems to work. > >>>> > >>>> For port 2 where the USB3530 is we don't have the issue the 3530 > >>>> enumerates properly. > >>>> > >>>> I did not see any information in the data sheet eluding to a timing > >>>> issue. > >>> > >>> This is the information I had received earlier from SMSC about USB3503A > >>> hub > > This has nothing to do with the 3503A this is the LAN9730. The 3503 works > just fine without the additional reset. > > >>> "You need the host up and running, and ready to go, THEN negate > >>> RESET_N. That is probably 95% of the issues." > >>> > >>> Please make sure the following sequence is done. > >>> > >>> - power up hub (RESET is active at this point). > >>> - start USB controller > >>> - wait a few ms > >>> - release hub RESET. > >>> > >>> giving a quick look at the u-boot code it seems you need to release the > >>> hub reset after usb_lowlevel_init() _OR_ usb_init() returns. > >> > >> Then it would also work in usb_lowlevel_init() ? > > > > It should as long as we place the "release reset" after EHCI controller > > has started. Maybe safer to put it in the end of usb_lowlevel_init(). > > > > cheers, > > -roger > > I moved the reset to the usb_lowlevel_init and it did not work. > I tried holding the 9730 in reset until after ehci hcd init is complete and > pulled it out of reset once the hcd is initialized but still no > enumeration. Can you try waiting a little after negating the reset ? It might be that the device takes some time to come back to life. Best regards, Marek Vasut
Marek On 07/14/2013 10:19 PM, Marek Vasut wrote: > Dear Dan Murphy, > >> Roger >> >> On 07/11/2013 09:23 AM, Roger Quadros wrote: >>> Hi Marek, >>> >>> On 07/11/2013 03:35 PM, Marek Vasut wrote: >>>> Dear Roger Quadros, >>>> >>>>> On 07/11/2013 02:16 AM, Dan Murphy wrote: >>>>>> On 07/10/2013 05:20 PM, Marek Vasut wrote: >>>>>>> Dear Dan Murphy, >>>>>>> >>>>>>>> Add a __weak function that can be overridden to reset devices >>>>>>>> attached to an ehci devices after the FEAT_POWER has been submitted >>>>>>>> >>>>>>>> Signed-off-by: Dan Murphy <dmurphy@ti.com> >>>>>>>> --- >>>>>>>> >>>>>>>> drivers/usb/host/ehci-hcd.c | 7 +++++++ >>>>>>>> 1 file changed, 7 insertions(+) >>>>>>>> >>>>>>>> diff --git a/drivers/usb/host/ehci-hcd.c >>>>>>>> b/drivers/usb/host/ehci-hcd.c index 706cf0c..fdd3994 100644 >>>>>>>> --- a/drivers/usb/host/ehci-hcd.c >>>>>>>> +++ b/drivers/usb/host/ehci-hcd.c >>>>>>>> @@ -616,6 +616,11 @@ __weak uint32_t >>>>>>>> *ehci_get_portsc_register(struct ehci_hcor *hcor, int port) return >>>>>>>> (uint32_t *)&hcor->or_portsc[port]; >>>>>>>> >>>>>>>> } >>>>>>>> >>>>>>>> +__weak void ehci_reset_attached_devices(int port) >>>>>>>> +{ >>>>>>>> + return; >>>>>>>> +} >>>>> Does this function need to be ehci specific? Other USB controllers >>>>> might also need such a function. >>>> You'd need to implement this for each of the xHCIs >>> OK. >> I can move the API to the usb-hub to call this after the FEAT_POWER is >> completed >> >>>>>>>> + >>>>>>> Can the reset not happen elsewhere? >>>>>> I have tried to move this around and keep this out of this file >>>>>> completely but nothing else seems to work. >>>>>> >>>>>> For port 2 where the USB3530 is we don't have the issue the 3530 >>>>>> enumerates properly. >>>>>> >>>>>> I did not see any information in the data sheet eluding to a timing >>>>>> issue. >>>>> This is the information I had received earlier from SMSC about USB3503A >>>>> hub >> This has nothing to do with the 3503A this is the LAN9730. The 3503 works >> just fine without the additional reset. >> >>>>> "You need the host up and running, and ready to go, THEN negate >>>>> RESET_N. That is probably 95% of the issues." >>>>> >>>>> Please make sure the following sequence is done. >>>>> >>>>> - power up hub (RESET is active at this point). >>>>> - start USB controller >>>>> - wait a few ms >>>>> - release hub RESET. >>>>> >>>>> giving a quick look at the u-boot code it seems you need to release the >>>>> hub reset after usb_lowlevel_init() _OR_ usb_init() returns. >>>> Then it would also work in usb_lowlevel_init() ? >>> It should as long as we place the "release reset" after EHCI controller >>> has started. Maybe safer to put it in the end of usb_lowlevel_init(). >>> >>> cheers, >>> -roger >> I moved the reset to the usb_lowlevel_init and it did not work. >> I tried holding the 9730 in reset until after ehci hcd init is complete and >> pulled it out of reset once the hcd is initialized but still no >> enumeration. > Can you try waiting a little after negating the reset ? It might be that the > device takes some time to come back to life. > > Best regards, > Marek Vasut I have tried that. I have a more general less invasive patch set I am going to submit. It will place the last two patches that in in disagreement at the end of the set so at least we can get the initial ones in. Dan
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c index 706cf0c..fdd3994 100644 --- a/drivers/usb/host/ehci-hcd.c +++ b/drivers/usb/host/ehci-hcd.c @@ -616,6 +616,11 @@ __weak uint32_t *ehci_get_portsc_register(struct ehci_hcor *hcor, int port) return (uint32_t *)&hcor->or_portsc[port]; } +__weak void ehci_reset_attached_devices(int port) +{ + return; +} + int ehci_submit_root(struct usb_device *dev, unsigned long pipe, void *buffer, int length, struct devrequest *req) @@ -777,6 +782,7 @@ ehci_submit_root(struct usb_device *dev, unsigned long pipe, void *buffer, reg |= EHCI_PS_PP; ehci_writel(status_reg, reg); } + ehci_reset_attached_devices(port); break; case USB_PORT_FEAT_RESET: if ((reg & (EHCI_PS_PE | EHCI_PS_CS)) == EHCI_PS_CS && @@ -794,6 +800,7 @@ ehci_submit_root(struct usb_device *dev, unsigned long pipe, void *buffer, reg |= EHCI_PS_PR; reg &= ~EHCI_PS_PE; ehci_writel(status_reg, reg); + /* * caller must wait, then call GetPortStatus * usb 2.0 specification say 50 ms resets on
Add a __weak function that can be overridden to reset devices attached to an ehci devices after the FEAT_POWER has been submitted Signed-off-by: Dan Murphy <dmurphy@ti.com> --- drivers/usb/host/ehci-hcd.c | 7 +++++++ 1 file changed, 7 insertions(+)