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:
signature.asc
Description: Digital signature
