RE: [PATCH 5/6] dma-mapping: support fsl-mc bus

[Nipun Gupta <nipun.gupta@nxp.com>]

> From: Robin Murphy [mailto:robin.murphy@arm.com]
> Sent: Tuesday, March 06, 2018 0:22
> 
> On 05/03/18 18:39, Christoph Hellwig wrote:
> > On Mon, Mar 05, 2018 at 03:48:32PM +0000, Robin Murphy wrote:
> >> 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.
> >
> > I really hate the PCI special case just as much.  Maybe we just
> > need a dma_configure method on the bus, and move PCI as well as fsl-mc
> > to it.
> 
> Hmm, on reflection, 100% ack to that idea. It would neatly supersede
> bus->force_dma *and* mean that we don't have to effectively pull pci.h
> into everything, which I've never liked. In hindsight dma_configure()
> does feel like it's grown into this odd choke point where we munge
> everything in just for it to awkwardly unpick things again.
> 
> Robin.

+1 to the idea.

Sorry for asking a trivial question - looking into dma_configure() I see that
PCI is used in the start and the end of the API.
In the end part pci_put_host_bridge_device() is called.
So are two bus callbacks something like 'dma_config_start' & 'dma_config_end'
will be required where the former one will return "dma_dev"?

Regards,
Nipun