On Thu, Mar 5, 2020 at 3:45 PM Arnd Bergmann <arnd@xxxxxxxx> wrote: > On Thu, Mar 5, 2020 at 3:30 PM Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: > > On Wed, Mar 4, 2020 at 5:28 PM Christoph Hellwig <hch@xxxxxx> wrote: > > > On Wed, Mar 04, 2020 at 02:32:42PM +0100, Ulf Hansson wrote: > > > > + Christoph, Arnd > > > Today MMC isn't using a bus for the host controllers, > > it is a class device, so I suppose the "real" solution would > > be: > > > > 1. Move MMC hosts to a bus instead of a class named > > say mmc_bus. If this is OK with the userspace ABI. > > > > 2. Make everything necessary from the struct device > > inside struct mmc_host (today called "class_device") > > copied over from the parent and stop referencing > > the struct device *parent field in struct mmc_host > > directly for everything and its dog. > > I don't think that copying the dma settings is a good solution > here. The software model that we have is that a bus can be a > dma master on its parent, which in turn is a master on > a parent bus, all the way up to the root of the tree. This is > not always the reality, but having an intermediate device > on a fake bus won't make it better. Alas, that is what we have today, because the platform_bus is pretty much fake. My initial reasoning was because Greg has expressed that he thinks the platform_bus is overused and more specific buses should be used, so I outlined a plan to make OF not use the platform bus. (Which is maybe too hard.) > The natural model is that an mmc host is a device on an > arbitrary dma capable bus (platform, pci, ...), and its > children are mmc devices with bus=&mmc_bus_type. > > If that is not already the case, that is where I'd start > changing it to simplify the model. The current way that the device tree parser uses the platform bus is that it has no idea about what it is doing when it comes to DMA, most of the time. But maybe if we take a step back: can we make the platform bus aware of what it is doing? For example we have dma-ranges and similar properties in the device tree, but subsystems call directly into drivers/of/address.c to parse these out. Would it be possible to tag nodes on the device tree with the appropriate segment size and boundary somehow also define the mask in the device tree in a proper way, and have the platform.c parser actually set this up correctly? I am not aware that we have anything like this currently, apart from the dma-ranges all DMA DT bindings we have seems to pertain to DMA engines. (I suppose the same apply for ACPI.) Yours, Linus Walleij
