Hi,

On Sun, Jan 04, 2015 at 09:16:01PM +0800, Sneeker Yeh wrote:

quoted

quoted

Then dwc3 core won't be always created via sub node in platform glue

node,

quoted

and vendors like us can just drop platform glue which don't have any
specific platform code to wrap dwc3 core, and just directly use dwc3 core
via device tree.

If your core is really just xhci, why don't just use xhci-plat.c

I've tried using xhci-plat.c, but our controller won't work today in
3.19-rc1.
Seems I still need the dwc3 initialization code.

probably missing PHY initialization, that should be easy to patch on
xhci-plat.c

quoted

directly ? You don't need dwc3 at all. In any case, I refrain from
allowing people to use dwc3.ko directly because that has bitten me in
the past with MUSB, so sorry but I'll always force people to use the
glue layer as that helps me keep dwc3 clean of platform-specific
details.

quoted

Of course here dwc3 core won't process clock if he got null one, so this
won't affect other vendor's platform which only pass clock phandle to

their

quoted

dwc3 platform glue driver.

right

quoted

Just wondering if it's better to write a platform glue only did clock
on/off, or to do the same improvement people ever did for
ehci-platform driver and just drop this platform glue driver?

I'll always the sour taste in my mouth due to MUSB. The thing is a
complete mess of platform-specific hacks all over the place.

Super thanks for sharing this, for me it's quite an honor to know that
story behond.
and I'll take these suggestion here to revise our platform glue layer.

hey, no problem. Cheers

-- 
balbi