[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.1609021019260.2027-100000@iolanthe.rowland.org>
Date: Fri, 2 Sep 2016 10:21:23 -0400 (EDT)
From: Alan Stern <stern@...land.harvard.edu>
To: Felipe Balbi <balbi@...nel.org>
cc: Russell King - ARM Linux <linux@...linux.org.uk>,
Arnd Bergmann <arnd@...db.de>, Leo Li <pku.leo@...il.com>,
Grygorii Strashko <grygorii.strashko@...com>,
Catalin Marinas <catalin.marinas@....com>,
Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>,
"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
Sekhar Nori <nsekhar@...com>,
lkml <linux-kernel@...r.kernel.org>,
David Fisher <david.fisher1@...opsys.com>,
"Thang Q. Nguyen" <tqnguyen@....com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
Stuart Yoder <stuart.yoder@....com>,
Scott Wood <oss@...error.net>
Subject: Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent
dev
On Fri, 2 Sep 2016, Felipe Balbi wrote:
> Hi,
>
> Russell King - ARM Linux <linux@...linux.org.uk> writes:
> > On Fri, Sep 02, 2016 at 12:43:39PM +0200, Arnd Bergmann wrote:
> >> On Thursday, September 1, 2016 5:14:28 PM CEST Leo Li wrote:
> >> >
> >> > Hi Felipe and Arnd,
> >> >
> >> > It has been a while since the last response to this discussion, but we
> >> > haven't reached an agreement yet! Can we get to a conclusion on if it
> >> > is valid to create child platform device for abstraction purpose? If
> >> > yes, can this child device do DMA by itself?
> >>
> >> I'd say it's no problem for a driver to create child devices in order
> >> to represent different aspects of a device, but you should not rely on
> >> those devices working when used with the dma-mapping interfaces.
> >
> > That's absolutely right. Consider the USB model - only the USB host
> > controller can perform DMA, not the USB devices themselves. All DMA
> > mappings need to be mapped using the USB host controller device struct
> > not the USB device struct.
> >
> > The same _should_ be true everywhere else: the struct device representing
> > the device performing DMA must be the one used to map the transfer.
>
> How do we fix dwc3 in dual-role, then?
>
> Peripheral-side dwc3 is easy, we just require a glue-layer to be present
> and use dwc3.ko's parent device (which will be the PCI device or OF
> device). But for host side dwc3, the problem is slightly more complex
> because we're using xhci-plat.ko by just instantiating a xhci-platform
> device so xhci-plat can probe.
>
> xhci core has no means to know if its own device or the parent of its
> parent should be used for DMA. Any ideas?
In theory, you can store a flag somewhere in the platform device,
something that would tell xhci-hcd that it has to use the parent's
parent for DMA purposes.
I know it would be somewhat of a hack, but ought to work.
Alan Stern
Powered by blists - more mailing lists