linux-kernel - Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <340685cd-7f06-21db-94cb-a87d0df36286@ti.com>
Date:   Wed, 7 Sep 2016 10:17:31 +0300
From:   Roger Quadros <rogerq@...com>
To:     Arnd Bergmann <arnd@...db.de>,
        <linux-arm-kernel@...ts.infradead.org>
CC:     Alan Stern <stern@...land.harvard.edu>,
        Felipe Balbi <balbi@...nel.org>,
        Grygorii Strashko <grygorii.strashko@...com>,
        Stuart Yoder <stuart.yoder@....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>,
        Russell King - ARM Linux <linux@...linux.org.uk>,
        lkml <linux-kernel@...r.kernel.org>,
        Scott Wood <oss@...error.net>,
        David Fisher <david.fisher1@...opsys.com>,
        "Thang Q. Nguyen" <tqnguyen@....com>, Leo Li <pku.leo@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent
 dev

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 <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.
> 
> 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