Split from another topic with reduced Cc list. On Mon, 2014-07-28 at 14:47 +0200, Arnd Bergmann wrote: > > > We already have an interface for this, in the form of > > > dma_request_slave_channel(), which takes a string identifier that > > > is used to look up all that information in either device tree or > > > ACPI. It wouldn't be unreasonable to add a third path in there > > > to handle hardcoded platform devices, but that's a lot of work. > > > Note that you still need to encode a reference to the dma engine > > > in some way to do this right. The current code (with or without Mika's > > > patch) will break as soon as you have multiple DMA engine devices. > > > > What about to keep PCI case still valid? We can pass struct pci_dev (or > > actual struct device) of DMA controller to filter proper device. > > Yes, that would be best. IIRC you have a single PCI device that instantiates > both the SPI and the DMA engine as subdevices (I haven't looked at the > code again), so that information would be readily available. Now we have only two parameters to the function: struct device of the client and string to get an info. For PCI case we need to have struct device of DMA controller. This could cover actually a case where we have hardcoded platform data (such as one in AVR32). But this would look a bit awkward. Current infrastructure allows to extract this from struct pci_dev, but do we have a capability to distinguish PCI device from others using only struct device? -- Andy Shevchenko <andriy.shevchenko@xxxxxxxxx> Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html