Re: [PATCH 2/3] usb: dwc3: add Fujitsu Specific Glue layer

[Felipe Balbi <balbi@ti.com>]

[-- Attachment #1: Type: text/plain, Size: 1748 bytes --]

Hi,

On Sun, Jan 04, 2015 at 09:16:01PM +0800, Sneeker Yeh wrote:
> > > Then dwc3 core won't be always created via sub node in platform glue
> > node,
> > > 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

> > 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.
> >
> > > 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
> > > dwc3 platform glue driver.
> >
> > right
> >
> > > 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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]