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

Felipe Balbi
2016-09-02T12:57:30Z

[-- Attachment #1: Type: text/plain, Size: 1673 bytes --]

Hi,

Robin Murphy <robin.murphy@arm.com> writes:
>>>> 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.
>>
>> heh, that looks like an excuse to me :-)
>>
>> This will always be a problem for e.g. MFD, for example. Are you saying
>> MFD child-devices shouldn't be allowed to do DMA? It becomes silly when
>> you read it that way, right?
>>
>>> 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
>>
>> right, so we have a very old regression that just took a complex driver
>> such as dwc3 to trigger ;-)
>>
>>> firmware or bootloader to describe various aspects of how DMA is done,
>>
>> there's no DMA description in DT. Every OF device gets the same 32-bit
>> DMA mask and that is, itself, wrong for several devices.
>
> Huh? There's only no DMA description in DT if the device can be assumed
> to be happy with the defaults. Anything else should be using
> "dma-ranges", "dma-coherent", etc. to describe non-default integration

heh, guilty as charged. I never noticed we had dma-ranges or
dma-coherent.

--
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 800 bytes --]