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 for Android: free password hash cracker in your pocket

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

Date:   Mon, 05 Sep 2016 17:39:27 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Leo Li <pku.leo@...il.com>
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 Friday, September 2, 2016 5:16:31 PM CEST Leo Li wrote:
> 
> 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.

Fortunately, there are not too many drivers that call platform_device_add
*and* try to set up a dma mask for the child device:

git grep -wl dma_mask drivers | xargs grep -wl 'platform_device_\(add\|register\)'

drivers/base/platform.c
drivers/bcma/main.c
drivers/eisa/virtual_root.c
drivers/mfd/mfd-core.c
drivers/mfd/omap-usb-host.c
drivers/misc/mic/card/mic_x100.c
drivers/platform/goldfish/pdev_bus.c
drivers/ssb/main.c
drivers/usb/chipidea/core.c
drivers/usb/dwc3/dwc3-exynos.c
drivers/usb/dwc3/host.c
drivers/usb/gadget/udc/bdc/bdc_pci.c
drivers/usb/host/bcma-hcd.c
drivers/usb/host/fsl-mph-dr-of.c
drivers/usb/host/ssb-hcd.c
drivers/usb/misc/ftdi-elan.c
drivers/usb/musb/blackfin.c
drivers/usb/musb/musb_dsps.c
drivers/usb/musb/omap2430.c
drivers/usb/musb/ux500.c

Most of these are probably never used with any nonstandard
DMA settings (IOMMU, cache coherency, offset, ...).

One thing we could possibly do is to go through these and
replace the hardcoded dma mask setup with of_dma_configure()
in all cases in which we actually use DT for probing, which
should cover the interesting cases.

	Arnd