linux-kernel - Re: [RFC] DMA initialization for manually created devices

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] [day] [month] [year] [list]

Date:	Wed, 20 Apr 2016 13:31:12 +0300
From:	Felipe Balbi <felipe.balbi@...ux.intel.com>
To:	David Woodhouse <dwmw2@...radead.org>,
	Vinod Koul <vinod.koul@...el.com>
Cc:	linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org
Subject: Re: [RFC] DMA initialization for manually created devices

Hi again,

Felipe Balbi <felipe.balbi@...ux.intel.com> writes:
> David Woodhouse <dwmw2@...radead.org> writes:
>> On Tue, 2016-04-19 at 14:38 +0300, Felipe Balbi wrote:
>>> 
>>> The reason for that I'm using a manually created platform_device and
>>> that misses dev->archdata which the underlying/parent PCI device has.
>>
>> Typically we'd expect you to use the parent device for DMA, as in your
>> second option.
>>
>> That said, we're exploring the option of moving the dma_ops to be a
>> first-class member of 'struct device' instead of hiding it in archdata,
>> and cleaning up the way that it gets initialised for newly-created
>> devices. And at that point we might end up letting it get inherited
>> from the parent so your original code *would* work... but I wouldn't
>> hold your breath for that.
>>
>> Definitely *don't* mess around in archdata.
>
> alright, I'll patch it up to use parent device everywhere, at least for
> now.

reviving this a little bit, it seems like inheritance of DMA bits from
parent is the way to go in the future. Let's consider a dual-role
instance of dwc3:

The peripheral IP is Synopsys' proprietary and gets built into dwc3.ko
which is a child device of a parent dwc3-pci.ko (in case of intel, at
least).

The host side, is regular XHCI, so dwc3.ko creates yet another child
device for xhci-plat.ko. The parent-child tree ends up like so:

dwc3-pci
  |_ dwc3
     |_ xhci-plat

dma for dwc3.ko is simple(-ish), instead of dma_alloc_coherent(dev,
....), we just replace that with dma_alloc_coherent(dev->parent, ...).

As for XHCI, which is a generic device also used directly by PCI
devices, the problem is more peculiar.

For dwc3's xHCI, we would have to call
dma_alloc_coherent(dev->parent->parent,  ...), but that would break
regular, non-dwc3 XHCI blocks which have direct access to the pci
device.

So, for dwc3.ko, I've fixed this with [1], however, if I remove copying
of DMA bits from parent to child, xhci-plat.ko will regress. Any hints
for this particular situation ?

The solution, IMO, is to either automatic copying of parent's DMA bits
to child by the time it's registered, or make DMA API search the device
parent tree until it finds a parent with a suitable DMA configuration.

[1] https://marc.info/?l=linux-usb&m=146107237232681&w=2

-- 
balbi

Download attachment "signature.asc" of type "application/pgp-signature" (819 bytes)