On Tue, Aug 15, 2017 at 09:19:50AM -0500, Rob Herring wrote:
> > For the immediate issue at hand, I guess the alternative plan of attack
> > would be to stick a flag in struct bus_type for the bus drivers
> > themselves to opt into generic DMA configuration. That at least keeps
> > everything withi
On Tue, Aug 15, 2017 at 5:18 AM, Robin Murphy wrote:
> On 14/08/17 21:08, Rob Herring wrote:
>> +linuxppc-dev
>>
>> On Fri, Aug 11, 2017 at 11:29 AM, Robin Murphy wrote:
>>> Moving DMA configuration to happen later at driver probe time had the
>>> unnoticed side-effect that we now perform DMA con
On 14/08/17 21:08, Rob Herring wrote:
> +linuxppc-dev
>
> On Fri, Aug 11, 2017 at 11:29 AM, Robin Murphy wrote:
>> Moving DMA configuration to happen later at driver probe time had the
>> unnoticed side-effect that we now perform DMA configuration for *every*
>> device represented in DT, rather t
+linuxppc-dev
On Fri, Aug 11, 2017 at 11:29 AM, Robin Murphy wrote:
> Moving DMA configuration to happen later at driver probe time had the
> unnoticed side-effect that we now perform DMA configuration for *every*
> device represented in DT, rather than only those explicitly created by
> the of_p
On Fri, Aug 11, 2017 at 05:29:57PM +0100, Robin Murphy wrote:
> The good news is that DT already gives us the ammunition to do the right
> thing - anything lacking a "dma-ranges" property should be considered
> not to have a mapping of DMA address space from its children to its
> parent, thus anyth
Moving DMA configuration to happen later at driver probe time had the
unnoticed side-effect that we now perform DMA configuration for *every*
device represented in DT, rather than only those explicitly created by
the of_platform and PCI code.
As Christoph points out, this is not really the best th
6 matches
Mail list logo
