[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7b4f9972-6aaa-fc9d-3854-d48b19a8051c@arm.com>
Date: Mon, 5 Mar 2018 15:48:32 +0000
From: Robin Murphy <robin.murphy@....com>
To: Christoph Hellwig <hch@....de>
Cc: Nipun Gupta <nipun.gupta@....com>, will.deacon@....com,
mark.rutland@....com, catalin.marinas@....com,
iommu@...ts.linux-foundation.org, robh+dt@...nel.org,
m.szyprowski@...sung.com, gregkh@...uxfoundation.org,
joro@...tes.org, leoyang.li@....com, shawnguo@...nel.org,
linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org,
linuxppc-dev@...ts.ozlabs.org, bharat.bhushan@....com,
stuyoder@...il.com, laurentiu.tudor@....com
Subject: Re: [PATCH 5/6] dma-mapping: support fsl-mc bus
On 05/03/18 15:08, Christoph Hellwig wrote:
> We should not add any new hardocded busses here. Please mark them in
> OF/ACPI.
Unfortunately for us, fsl-mc is conceptually rather like PCI in that
it's software-discoverable and the only thing described in DT is the bus
"host", thus we need the same sort of thing as for PCI to map from the
child devices back to the bus root in order to find the appropriate
firmware node. Worse than PCI, though, we wouldn't even have the option
of describing child devices statically in firmware at all, since it's
actually one of these runtime-configurable "build your own network
accelerator" hardware pools where userspace gets to create and destroy
"devices" as it likes.
Robin.
Powered by blists - more mailing lists