[U-Boot] [PATCH] mvebu: usb: Add missing controller reset after initialization

[U-Boot] [PATCH] mvebu: usb: Add missing controller reset after initialization

[Phil Sutter]

In order to allow for Linux properly register the integrated EHCI host,
we have to reset it after initialization. Without this, enumeration
fails if 'usb start' wasn't issued prior to booting Linux.

Signed-off-by: Phil Sutter <phil@nwl.cc>
---
 arch/arm/mach-mvebu/cpu.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/mach-mvebu/cpu.c b/arch/arm/mach-mvebu/cpu.c
index 5c62fd5..cb885f8 100644
--- a/arch/arm/mach-mvebu/cpu.c
+++ b/arch/arm/mach-mvebu/cpu.c
@@ -281,6 +281,8 @@ static void set_cbar(u32 addr)
 					 (((addr) & 0xF) << 6))
 #define MV_USB_X3_PHY_CHANNEL(dev, reg)	(MV_USB_X3_BASE((dev) + 1) |	\
 					 (((reg) & 0xF) << 2))
+#define MV_USB_CMD_REG(dev)		(MVEBU_AXP_USB_BASE + (dev * 0x1000) + 0x140)
+#define MV_USB_MODE_REG(dev)		(MVEBU_AXP_USB_BASE + (dev * 0x1000) + 0x1A8)
 
 static void setup_usb_phys(void)
 {
@@ -313,6 +315,16 @@ static void setup_usb_phys(void)
 		setbits_le32(MV_USB_X3_PHY_CHANNEL(dev, 1), BIT(12));
 		udelay(40);
 		clrbits_le32(MV_USB_X3_PHY_CHANNEL(dev, 1), BIT(12));
+
+		/* disable (bit 0) and reset (bit 1) controller */
+		/* XXX: do this in two steps? */
+		clrsetbits_le32(MV_USB_CMD_REG(dev), BIT(0), BIT(1));
+
+		while(readl(MV_USB_CMD_REG(dev)) & BIT(1))
+			;
+
+		/* set host mode (device mode is (0x2 | 1 << 3)) */
+		writel(0x3, MV_USB_MODE_REG(dev));
 	}
 }
 
-- 
2.5.3

[U-Boot] [PATCH] mvebu: usb: Add missing controller reset after initialization

[Wolfgang Denk]

Dear Phil,

[added USB custodian to Cc:]

In message <20160102211834.E49A161C74@mail.nwl.cc> you wrote:
> In order to allow for Linux properly register the integrated EHCI host,
> we have to reset it after initialization. Without this, enumeration
> fails if 'usb start' wasn't issued prior to booting Linux.

I think this reset should actually be done in the Linux driver.

From what you write I suspect that after a "usb stop" in U-Boot the
Linux driver maight fail, too.  Leaving USB enabled in U-Boot is
extremely dangerous - see

commit 3d71c81a9bb03f866a1e98da96363ef3f46c76b3
Author: Markus Klotzb?cher <mk@denx.de>
Date:   Thu Jul 10 14:47:09 2008 +0200

    USB: shutdown USB before booting
    
    This patch fixes a potentially serious issue related to USB which was
    discouvered by Martin Krause <martin.krause@tqs.de> and fixed for
    ARM920T. Martin wrote: 
    
      Turn off USB to prevent the host controller from writing to the 
      SDRAM while Linux is booting. This could happen, because the HCCA
      (Host Controller Communication Area) lies within the SDRAM and the
      host controller writes continously to this area (as busmaster!), for
      example to increase the HccaFrameNumber variable, which happens
      every 1 ms.
    
    This is a slightly modified version of the patch in order to shutdown
    USB when booting on all architectures.
    
    Signed-off-by: Markus Klotzbuecher <mk@denx.de>


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A wise person makes his  own  decisions,  a  weak  one  obeys  public
opinion.                                           -- Chinese proverb

[U-Boot] [PATCH] mvebu: usb: Add missing controller reset after initialization

[Marek Vasut]

On Sunday, January 03, 2016 at 09:59:23 AM, Wolfgang Denk wrote:
> Dear Phil,
> 
> [added USB custodian to Cc:]

Thanks

> In message <20160102211834.E49A161C74@mail.nwl.cc> you wrote:
> > In order to allow for Linux properly register the integrated EHCI host,
> > we have to reset it after initialization. Without this, enumeration
> > fails if 'usb start' wasn't issued prior to booting Linux.
> 
> I think this reset should actually be done in the Linux driver.

Correct.

> From what you write I suspect that after a "usb stop" in U-Boot the
> Linux driver maight fail, too.  Leaving USB enabled in U-Boot is
> extremely dangerous - see
> 
> commit 3d71c81a9bb03f866a1e98da96363ef3f46c76b3
> Author: Markus Klotzb?cher <mk@denx.de>
> Date:   Thu Jul 10 14:47:09 2008 +0200
> 
>     USB: shutdown USB before booting
> 
>     This patch fixes a potentially serious issue related to USB which was
>     discouvered by Martin Krause <martin.krause@tqs.de> and fixed for
>     ARM920T. Martin wrote:
> 
>       Turn off USB to prevent the host controller from writing to the
>       SDRAM while Linux is booting. This could happen, because the HCCA
>       (Host Controller Communication Area) lies within the SDRAM and the
>       host controller writes continously to this area (as busmaster!), for
>       example to increase the HccaFrameNumber variable, which happens
>       every 1 ms.
> 
>     This is a slightly modified version of the patch in order to shutdown
>     USB when booting on all architectures.
> 
>     Signed-off-by: Markus Klotzbuecher <mk@denx.de>

This reasoning is correct.

Best regards,
Marek Vasut

[U-Boot] [PATCH] mvebu: usb: Add missing controller reset after initialization

[Phil Sutter]

Hi,

On Sun, Jan 03, 2016 at 09:59:23AM +0100, Wolfgang Denk wrote:
> [added USB custodian to Cc:]
> 
> In message <20160102211834.E49A161C74@mail.nwl.cc> you wrote:
> > In order to allow for Linux properly register the integrated EHCI host,
> > we have to reset it after initialization. Without this, enumeration
> > fails if 'usb start' wasn't issued prior to booting Linux.
> 
> I think this reset should actually be done in the Linux driver.
> 
> From what you write I suspect that after a "usb stop" in U-Boot the
> Linux driver maight fail, too.  Leaving USB enabled in U-Boot is
> extremely dangerous - see

Ah, thanks for pointing this out! I had no idea the HCD does things like
this. Though I'm a bit confused now how to solve the issue at hand:

> commit 3d71c81a9bb03f866a1e98da96363ef3f46c76b3
> Author: Markus Klotzb?cher <mk@denx.de>
> Date:   Thu Jul 10 14:47:09 2008 +0200
> 
>     USB: shutdown USB before booting
>     
>     This patch fixes a potentially serious issue related to USB which was
>     discouvered by Martin Krause <martin.krause@tqs.de> and fixed for
>     ARM920T. Martin wrote: 
>     
>       Turn off USB to prevent the host controller from writing to the 
>       SDRAM while Linux is booting. This could happen, because the HCCA
>       (Host Controller Communication Area) lies within the SDRAM and the
>       host controller writes continously to this area (as busmaster!), for
>       example to increase the HccaFrameNumber variable, which happens
>       every 1 ms.
>     
>     This is a slightly modified version of the patch in order to shutdown
>     USB when booting on all architectures.
>     
>     Signed-off-by: Markus Klotzbuecher <mk@denx.de>

This commit exists in my tree, therefore when I call 'bootm' it should
stop USB. To be sure, I tested calling 'usb stop' manually before doing
'tftpboot; bootm' and the enumeration still succeeds in Linux.

Since this all does not seem to make much sense, I reviewed my changes
again to see if the controller really is enabled after the reset - it is
not, but I found something more important: The reset is actually not
necessary at all!

The bit which really was missing is the USB mode setting I smuggled in
along with my patch - setting the devices to host mode is sufficient for
Linux to successfully enumerate the HCD.

Checking the logs of the vendor's U-Boot fork, it appears that devices 1
and 2 are configured to host mode, while the third is set to device
mode. I changed my code to copy that, but am not sure it's necessary at
all: The DS414 exports only a single port of the SoC's EHCI, and Linux
detects that:

| orion-ehci f1050000.usb: EHCI Host Controller
| orion-ehci f1050000.usb: new USB bus registered, assigned bus number 3
| orion-ehci f1050000.usb: irq 27, io mem 0xf1050000
| orion-ehci f1050000.usb: USB 2.0 started, EHCI 1.00
| hub 3-0:1.0: USB hub found
| hub 3-0:1.0: 1 port detected

OTOH I'm not sure how far this configuration is device specific in the
first place. What puzzles me is that I couldn't find a reference to this
USB mode register at 0x501A8 in Marvell's MV78230 specs, still it seems
to be crucial. Does anyone of you have this register referenced in some
Marvell datasheet somewhere?

Maybe there's also a more generic way to do this, 'usb start' (which
solves the problem without any changes to the SoC init code) seems to
not address this register.

Thanks, Phil

[U-Boot] [PATCH] mvebu: usb: Add missing controller reset after initialization

[Marek Vasut]

On Monday, January 04, 2016 at 12:38:07 AM, Phil Sutter wrote:
> Hi,
> 
> On Sun, Jan 03, 2016 at 09:59:23AM +0100, Wolfgang Denk wrote:
> > [added USB custodian to Cc:]
> > 
> > In message <20160102211834.E49A161C74@mail.nwl.cc> you wrote:
> > > In order to allow for Linux properly register the integrated EHCI host,
> > > we have to reset it after initialization. Without this, enumeration
> > > fails if 'usb start' wasn't issued prior to booting Linux.
> > 
> > I think this reset should actually be done in the Linux driver.
> > 
> > From what you write I suspect that after a "usb stop" in U-Boot the
> > Linux driver maight fail, too.  Leaving USB enabled in U-Boot is
> > extremely dangerous - see
> 
> Ah, thanks for pointing this out! I had no idea the HCD does things like
> 
> this. Though I'm a bit confused now how to solve the issue at hand:
> > commit 3d71c81a9bb03f866a1e98da96363ef3f46c76b3
> > Author: Markus Klotzb?cher <mk@denx.de>
> > Date:   Thu Jul 10 14:47:09 2008 +0200
> > 
> >     USB: shutdown USB before booting
> >     
> >     This patch fixes a potentially serious issue related to USB which was
> >     discouvered by Martin Krause <martin.krause@tqs.de> and fixed for
> >     
> >     ARM920T. Martin wrote:
> >       Turn off USB to prevent the host controller from writing to the
> >       SDRAM while Linux is booting. This could happen, because the HCCA
> >       (Host Controller Communication Area) lies within the SDRAM and the
> >       host controller writes continously to this area (as busmaster!),
> >       for example to increase the HccaFrameNumber variable, which
> >       happens every 1 ms.
> >     
> >     This is a slightly modified version of the patch in order to shutdown
> >     USB when booting on all architectures.
> >     
> >     Signed-off-by: Markus Klotzbuecher <mk@denx.de>
> 
> This commit exists in my tree, therefore when I call 'bootm' it should
> stop USB. To be sure, I tested calling 'usb stop' manually before doing
> 'tftpboot; bootm' and the enumeration still succeeds in Linux.
> 
> Since this all does not seem to make much sense, I reviewed my changes
> again to see if the controller really is enabled after the reset - it is
> not, but I found something more important: The reset is actually not
> necessary at all!
> 
> The bit which really was missing is the USB mode setting I smuggled in
> along with my patch - setting the devices to host mode is sufficient for
> Linux to successfully enumerate the HCD.

OK, so the controller is OTG capable and upon reset, it's in Gadget mode?

> Checking the logs of the vendor's U-Boot fork, it appears that devices 1
> and 2 are configured to host mode, while the third is set to device
> mode. I changed my code to copy that, but am not sure it's necessary at
> all: The DS414 exports only a single port of the SoC's EHCI, and Linux
> 
> detects that:
> | orion-ehci f1050000.usb: EHCI Host Controller
> | orion-ehci f1050000.usb: new USB bus registered, assigned bus number 3
> | orion-ehci f1050000.usb: irq 27, io mem 0xf1050000
> | orion-ehci f1050000.usb: USB 2.0 started, EHCI 1.00
> | hub 3-0:1.0: USB hub found
> | hub 3-0:1.0: 1 port detected
> 
> OTOH I'm not sure how far this configuration is device specific in the
> first place. What puzzles me is that I couldn't find a reference to this
> USB mode register at 0x501A8 in Marvell's MV78230 specs, still it seems
> to be crucial. Does anyone of you have this register referenced in some
> Marvell datasheet somewhere?

It's the USBMODE register, see for example [1] . It's part of EHCI cores
which are OTG capable.

[1] http://lxr.free-electrons.com/source/drivers/usb/host/ehci-hcd.c#L179

> Maybe there's also a more generic way to do this, 'usb start' (which
> solves the problem without any changes to the SoC init code) seems to
> not address this register.

Probably add a fixup into ehci-orion.c in Linux or something along those
lines. It should configure the code according to the "dr_mode" DT prop.

[U-Boot] [PATCH] mvebu: usb: Add missing controller reset after initialization

[Phil Sutter]

Hi,

On Mon, Jan 04, 2016 at 12:47:37AM +0100, Marek Vasut wrote:
> On Monday, January 04, 2016 at 12:38:07 AM, Phil Sutter wrote:
> > The bit which really was missing is the USB mode setting I smuggled in
> > along with my patch - setting the devices to host mode is sufficient for
> > Linux to successfully enumerate the HCD.
> 
> OK, so the controller is OTG capable and upon reset, it's in Gadget mode?

Yes, seems it's capable. Upon reset, register 0x501a0 contains value 0.
Trying to print register 0x511a0 freezes U-Boot for me.

> > Checking the logs of the vendor's U-Boot fork, it appears that devices 1
> > and 2 are configured to host mode, while the third is set to device
> > mode. I changed my code to copy that, but am not sure it's necessary at
> > all: The DS414 exports only a single port of the SoC's EHCI, and Linux
> > 
> > detects that:
> > | orion-ehci f1050000.usb: EHCI Host Controller
> > | orion-ehci f1050000.usb: new USB bus registered, assigned bus number 3
> > | orion-ehci f1050000.usb: irq 27, io mem 0xf1050000
> > | orion-ehci f1050000.usb: USB 2.0 started, EHCI 1.00
> > | hub 3-0:1.0: USB hub found
> > | hub 3-0:1.0: 1 port detected
> > 
> > OTOH I'm not sure how far this configuration is device specific in the
> > first place. What puzzles me is that I couldn't find a reference to this
> > USB mode register at 0x501A8 in Marvell's MV78230 specs, still it seems
> > to be crucial. Does anyone of you have this register referenced in some
> > Marvell datasheet somewhere?
> 
> It's the USBMODE register, see for example [1] . It's part of EHCI cores
> which are OTG capable.
> 
> [1] http://lxr.free-electrons.com/source/drivers/usb/host/ehci-hcd.c#L179

Interesting. I would have expected this to show up in MV78230 specs, but
maybe I missed the part where it clarifies these offsets to be standard
conformant.

> > Maybe there's also a more generic way to do this, 'usb start' (which
> > solves the problem without any changes to the SoC init code) seems to
> > not address this register.
> 
> Probably add a fixup into ehci-orion.c in Linux or something along those
> lines. It should configure the code according to the "dr_mode" DT prop.

Hmm. Searching through the relevant DT files didn't yield a result for
"dr_mode". Seems like this property is missing, maybe that's why Linux
fails here? Is this something generally user-configurable? (Note that I
don't have the slightest idea of how device mode USB works in Linux).

Thanks, Phil

[U-Boot] [PATCH] mvebu: usb: Add missing controller reset after initialization

[Marek Vasut]

On Monday, January 04, 2016 at 04:02:26 AM, Phil Sutter wrote:
> Hi,
> 
> On Mon, Jan 04, 2016 at 12:47:37AM +0100, Marek Vasut wrote:
> > On Monday, January 04, 2016 at 12:38:07 AM, Phil Sutter wrote:
> > > The bit which really was missing is the USB mode setting I smuggled in
> > > along with my patch - setting the devices to host mode is sufficient
> > > for Linux to successfully enumerate the HCD.
> > 
> > OK, so the controller is OTG capable and upon reset, it's in Gadget mode?
> 
> Yes, seems it's capable. Upon reset, register 0x501a0 contains value 0.
> Trying to print register 0x511a0 freezes U-Boot for me.

0x501a0 and 0x511a0 are two different registers. Freeze usually indicates
disabled clock to the IP block or somesuch.

> > > Checking the logs of the vendor's U-Boot fork, it appears that devices
> > > 1 and 2 are configured to host mode, while the third is set to device
> > > mode. I changed my code to copy that, but am not sure it's necessary
> > > at all: The DS414 exports only a single port of the SoC's EHCI, and
> > > Linux
> > > 
> > > detects that:
> > > | orion-ehci f1050000.usb: EHCI Host Controller
> > > | orion-ehci f1050000.usb: new USB bus registered, assigned bus number
> > > | 3 orion-ehci f1050000.usb: irq 27, io mem 0xf1050000
> > > | orion-ehci f1050000.usb: USB 2.0 started, EHCI 1.00
> > > | hub 3-0:1.0: USB hub found
> > > | hub 3-0:1.0: 1 port detected
> > > 
> > > OTOH I'm not sure how far this configuration is device specific in the
> > > first place. What puzzles me is that I couldn't find a reference to
> > > this USB mode register at 0x501A8 in Marvell's MV78230 specs, still it
> > > seems to be crucial. Does anyone of you have this register referenced
> > > in some Marvell datasheet somewhere?
> > 
> > It's the USBMODE register, see for example [1] . It's part of EHCI cores
> > which are OTG capable.
> > 
> > [1] http://lxr.free-electrons.com/source/drivers/usb/host/ehci-hcd.c#L179
> 
> Interesting. I would have expected this to show up in MV78230 specs, but
> maybe I missed the part where it clarifies these offsets to be standard
> conformant.

It seems to be standard comformant, but I didn't see the datasheet.

> > > Maybe there's also a more generic way to do this, 'usb start' (which
> > > solves the problem without any changes to the SoC init code) seems to
> > > not address this register.
> > 
> > Probably add a fixup into ehci-orion.c in Linux or something along those
> > lines. It should configure the code according to the "dr_mode" DT prop.
> 
> Hmm. Searching through the relevant DT files didn't yield a result for
> "dr_mode". Seems like this property is missing, maybe that's why Linux
> fails here?

More likely it's not implemented for the MVEBU yet.

> Is this something generally user-configurable? (Note that I
> don't have the slightest idea of how device mode USB works in Linux).

Yes, you can run the core in either Host/Gadget/OTG mode. For that to work,
you need to configure the core mode.

Best regards,
Marek Vasut

[U-Boot] [PATCH] mvebu: usb: Add missing controller reset after initialization

[Stefan Roese]

On 04.01.2016 12:25, Marek Vasut wrote:
> On Monday, January 04, 2016 at 04:02:26 AM, Phil Sutter wrote:
>> Hi,
>>
>> On Mon, Jan 04, 2016 at 12:47:37AM +0100, Marek Vasut wrote:
>>> On Monday, January 04, 2016 at 12:38:07 AM, Phil Sutter wrote:
>>>> The bit which really was missing is the USB mode setting I smuggled in
>>>> along with my patch - setting the devices to host mode is sufficient
>>>> for Linux to successfully enumerate the HCD.
>>>
>>> OK, so the controller is OTG capable and upon reset, it's in Gadget mode?
>>
>> Yes, seems it's capable. Upon reset, register 0x501a0 contains value 0.
>> Trying to print register 0x511a0 freezes U-Boot for me.
>
> 0x501a0 and 0x511a0 are two different registers. Freeze usually indicates
> disabled clock to the IP block or somesuch.
>
>>>> Checking the logs of the vendor's U-Boot fork, it appears that devices
>>>> 1 and 2 are configured to host mode, while the third is set to device
>>>> mode. I changed my code to copy that, but am not sure it's necessary
>>>> at all: The DS414 exports only a single port of the SoC's EHCI, and
>>>> Linux
>>>>
>>>> detects that:
>>>> | orion-ehci f1050000.usb: EHCI Host Controller
>>>> | orion-ehci f1050000.usb: new USB bus registered, assigned bus number
>>>> | 3 orion-ehci f1050000.usb: irq 27, io mem 0xf1050000
>>>> | orion-ehci f1050000.usb: USB 2.0 started, EHCI 1.00
>>>> | hub 3-0:1.0: USB hub found
>>>> | hub 3-0:1.0: 1 port detected
>>>>
>>>> OTOH I'm not sure how far this configuration is device specific in the
>>>> first place. What puzzles me is that I couldn't find a reference to
>>>> this USB mode register at 0x501A8 in Marvell's MV78230 specs, still it
>>>> seems to be crucial. Does anyone of you have this register referenced
>>>> in some Marvell datasheet somewhere?
>>>
>>> It's the USBMODE register, see for example [1] . It's part of EHCI cores
>>> which are OTG capable.
>>>
>>> [1] http://lxr.free-electrons.com/source/drivers/usb/host/ehci-hcd.c#L179
>>
>> Interesting. I would have expected this to show up in MV78230 specs, but
>> maybe I missed the part where it clarifies these offsets to be standard
>> conformant.
>
> It seems to be standard comformant, but I didn't see the datasheet.
>
>>>> Maybe there's also a more generic way to do this, 'usb start' (which
>>>> solves the problem without any changes to the SoC init code) seems to
>>>> not address this register.
>>>
>>> Probably add a fixup into ehci-orion.c in Linux or something along those
>>> lines. It should configure the code according to the "dr_mode" DT prop.
>>
>> Hmm. Searching through the relevant DT files didn't yield a result for
>> "dr_mode". Seems like this property is missing, maybe that's why Linux
>> fails here?
>
> More likely it's not implemented for the MVEBU yet.
>
>> Is this something generally user-configurable? (Note that I
>> don't have the slightest idea of how device mode USB works in Linux).
>
> Yes, you can run the core in either Host/Gadget/OTG mode. For that to work,
> you need to configure the core mode.

I've not followed the discussion and just now going through my list
of open patches.

Phil, what is the current status of this patch? Is it still needed?

Thanks,
Stefan

[U-Boot] [PATCH] mvebu: usb: Add missing controller reset after initialization

[Phil Sutter]

On Thu, Mar 24, 2016 at 10:13:35AM +0100, Stefan Roese wrote:
> On 04.01.2016 12:25, Marek Vasut wrote:
> > On Monday, January 04, 2016 at 04:02:26 AM, Phil Sutter wrote:
> >> Hi,
> >>
> >> On Mon, Jan 04, 2016 at 12:47:37AM +0100, Marek Vasut wrote:
> >>> On Monday, January 04, 2016 at 12:38:07 AM, Phil Sutter wrote:
> >>>> The bit which really was missing is the USB mode setting I smuggled in
> >>>> along with my patch - setting the devices to host mode is sufficient
> >>>> for Linux to successfully enumerate the HCD.
> >>>
> >>> OK, so the controller is OTG capable and upon reset, it's in Gadget mode?
> >>
> >> Yes, seems it's capable. Upon reset, register 0x501a0 contains value 0.
> >> Trying to print register 0x511a0 freezes U-Boot for me.
> >
> > 0x501a0 and 0x511a0 are two different registers. Freeze usually indicates
> > disabled clock to the IP block or somesuch.
> >
> >>>> Checking the logs of the vendor's U-Boot fork, it appears that devices
> >>>> 1 and 2 are configured to host mode, while the third is set to device
> >>>> mode. I changed my code to copy that, but am not sure it's necessary
> >>>> at all: The DS414 exports only a single port of the SoC's EHCI, and
> >>>> Linux
> >>>>
> >>>> detects that:
> >>>> | orion-ehci f1050000.usb: EHCI Host Controller
> >>>> | orion-ehci f1050000.usb: new USB bus registered, assigned bus number
> >>>> | 3 orion-ehci f1050000.usb: irq 27, io mem 0xf1050000
> >>>> | orion-ehci f1050000.usb: USB 2.0 started, EHCI 1.00
> >>>> | hub 3-0:1.0: USB hub found
> >>>> | hub 3-0:1.0: 1 port detected
> >>>>
> >>>> OTOH I'm not sure how far this configuration is device specific in the
> >>>> first place. What puzzles me is that I couldn't find a reference to
> >>>> this USB mode register at 0x501A8 in Marvell's MV78230 specs, still it
> >>>> seems to be crucial. Does anyone of you have this register referenced
> >>>> in some Marvell datasheet somewhere?
> >>>
> >>> It's the USBMODE register, see for example [1] . It's part of EHCI cores
> >>> which are OTG capable.
> >>>
> >>> [1] http://lxr.free-electrons.com/source/drivers/usb/host/ehci-hcd.c#L179
> >>
> >> Interesting. I would have expected this to show up in MV78230 specs, but
> >> maybe I missed the part where it clarifies these offsets to be standard
> >> conformant.
> >
> > It seems to be standard comformant, but I didn't see the datasheet.
> >
> >>>> Maybe there's also a more generic way to do this, 'usb start' (which
> >>>> solves the problem without any changes to the SoC init code) seems to
> >>>> not address this register.
> >>>
> >>> Probably add a fixup into ehci-orion.c in Linux or something along those
> >>> lines. It should configure the code according to the "dr_mode" DT prop.
> >>
> >> Hmm. Searching through the relevant DT files didn't yield a result for
> >> "dr_mode". Seems like this property is missing, maybe that's why Linux
> >> fails here?
> >
> > More likely it's not implemented for the MVEBU yet.
> >
> >> Is this something generally user-configurable? (Note that I
> >> don't have the slightest idea of how device mode USB works in Linux).
> >
> > Yes, you can run the core in either Host/Gadget/OTG mode. For that to work,
> > you need to configure the core mode.
> 
> I've not followed the discussion and just now going through my list
> of open patches.
> 
> Phil, what is the current status of this patch? Is it still needed?

I reported the issue to linux-usb list back in January, but never got
any usable reply. So no progress upstream.

Also, it seems that even with this patch the front USB port is not
usable in Linux, no devices are detected.

Cheers, Phil