On Thu, Mar 5, 2020 at 4:04 PM Linus Walleij <linus.walleij@xxxxxxxxxx> wrote:
> 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.
Note the difference between a fake bus instance and a fake bus
type: the problem in certain drivers is making up a bus instance
for internal abstractions, and this causes problems with managing
DMA.
The 'platform_bus' bus_type being fake is a completely
unrelated problem, this is mostly an artifact of not being
able to model the actual buses because we don't even
know if something is an AXI or AHB bus or something else
in many cases, so we fall back to using platform_bus for
anything device that has mmio, dma, interrupts etc
but doesn't have a discoverable bus type already.
> 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.)
Traditionally we had a separate bus type for devices
probed from DT, but turned out to be a huge hassle because
of all the drivers that were also probed from board files
then needed to register two separate device_driver
structures.
Arnd
