From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756495AbcIGHSp (ORCPT ); Wed, 7 Sep 2016 03:18:45 -0400 Received: from devils.ext.ti.com ([198.47.26.153]:43666 "EHLO devils.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753363AbcIGHSn (ORCPT ); Wed, 7 Sep 2016 03:18:43 -0400 Subject: Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev To: Arnd Bergmann , References: <5147808.apZTAZ3VPE@wuerfel> CC: Alan Stern , Felipe Balbi , Grygorii Strashko , Stuart Yoder , Catalin Marinas , Yoshihiro Shimoda , "linux-usb@vger.kernel.org" , Sekhar Nori , Russell King - ARM Linux , lkml , Scott Wood , David Fisher , "Thang Q. Nguyen" , Leo Li , Greg Kroah-Hartman From: Roger Quadros Message-ID: <340685cd-7f06-21db-94cb-a87d0df36286@ti.com> Date: Wed, 7 Sep 2016 10:17:31 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <5147808.apZTAZ3VPE@wuerfel> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Arnd, On 02/09/16 18:51, Arnd Bergmann wrote: > On Friday, September 2, 2016 10:21:23 AM CEST Alan Stern wrote: >> On Fri, 2 Sep 2016, Felipe Balbi wrote: >> >>> Hi, >>> >>> Russell King - ARM Linux 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. > > Speaking of that flag, I suppose we need the same logic to know where > to look for USB devices attached to a dwc3 host when we need to describe > them in DT. By default we look for child device nodes under the > node of the HCD device node, but that would be wrong here too. I didn't get this part. Information about USB devices attached to a USB host is never provided in DT because they are always dynamically created via usb_new_device(), whether they are hard-wired on the board or hot-plugged. These USB devices inherit their DMA masks in the usb_alloc_dev() routine whereas each interface within the USB device inherits its DMA mask in usb_set_configuration(). There is a bug in the USB core because of which the ISB device and interfaces do not inherit dma_pfn_offset correctly for which I've sent a patch https://lkml.org/lkml/2016/8/17/275 cheers, -roger