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 > > > > On Wed, 19 Feb 2020 at 09:31, <haibo.chen@xxxxxxx> wrote: > > > > > > From: Haibo Chen <haibo.chen@xxxxxxx> > > > > > > To make dma_set_max_seg_size() work, need to create dev->dma_parms. > > > > > > Find this issue on i.MX8QM mek board, this platform config the > > > max_segment_size to 65535, but this dma_set_max_seg_size do not > > > actuall work, find sometimes the segment size is 65536, exceed > > > the hardware max segment limitation, trigger ADMA error. > > > > Sounds like we want something along the lines of this to be tagged for > > stable as well. > > It really is not the job of the upper level driver to allocate the > dma params. This should be done by the bus driver. I agree. This relates to my reply to Greg K-H recently: https://lore.kernel.org/lkml/CACRpkdajhivkOkZ63v-hr7+6ObhTffYOx5uZP0P-MYvuVnyweA@xxxxxxxxxxxxxx/ The core of the problem is that drivers/of/platform.c is very simple and has no idea what kind of bus it is populating with devices from Device Tree. It is just guessing. For example platform.c contains this: dev->dev.coherent_dma_mask = DMA_BIT_MASK(32); if (!dev->dev.dma_mask) dev->dev.dma_mask = &dev->dev.coherent_dma_mask; And again part of the problem is that the device tree parser mostly just create struct platform_device's on the platform bus and has no real idea about any constraints on the bus where it will eventually end up after the platform device is probed and a new device on some other bus has been created. Assuming that most problematic MMC controllers (in this case) are probed from device tree (which I suspect, but IIUC ACPI devices have the same problem), my idea for a solution is to start to modify the platform.c parser to be able to populate devices on some buses directly, without using an intermediate platform device. 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. 3. Make struct mmc_host and mmc_alloc_host() and mmc_add_host() be created and called directly from the device tree in some way (like a plug-in mechanism to of/platform.c) without creating a platform_device that just end up as the intermediary parent of the actual device in mmc_host. 4. Now we are creating the device directly on the right bus and so we can start thinking about filling in the right dma_params and dma_mask and dma_coherent_mask when instantiating the device on the mmc_bus rather than in every (platform_device) driver. This is no trivial task because the kernel has gone down the platform device for all stuff in the device tree for a while. (Copy/paste same resoning for ACPI I'm afraid.) I suppose people were looking for a simple solution to this problem but I can only see a really complicated solution. Yours, Linus Walleij
