Messages in this thread | | | Date | Mon, 5 Jan 2015 09:52:45 -0600 | From | Felipe Balbi <> | Subject | Re: [PATCH 2/3] usb: dwc3: add Fujitsu Specific Glue layer |
| |
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 [unhandled content-type:application/pgp-signature] | |