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: <CADRPPNR1_6fbaHLvbmNZW+r7YWW=vOZ+wGCS-MAcNPi9gB3eOw@mail.gmail.com>
Date:   Fri, 2 Sep 2016 17:16:31 -0500
From:   Leo Li <pku.leo@...il.com>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Felipe Balbi <balbi@...nel.org>,
        Russell King - ARM Linux <linux@....linux.org.uk>,
        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>,
        Alan Stern <stern@...land.harvard.edu>,
        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, Sep 2, 2016 at 5:43 AM, Arnd Bergmann <arnd@...db.de> 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.
>
> This used to be simpler back when we could configure the kernel for
> only one SoC platform at a time, and the platforms could provide their
> own overrides for the dma-mapping interfaces. These days, we rely on
> firmware or bootloader to describe various aspects of how DMA is done,
> so you can't assume that passing a device without an of_node pointer
> or ACPI data into those functions will do the right thing.

Can we use the firmware or bootloader information to provide the
default dma-mapping attributes for devices that doesn't have an
of_node pointer or ACPI data?  This will at least restore what we had
previously provided .  I'm concerned that changing all the drivers
that are creating child device will be a big effort.  Like I mentioned
in another thread, there are many instances of platform_device_add()
under the drivers/ directory.

- Leo