Messages in this thread | | | Date | Fri, 11 May 2018 20:06:06 +1000 (AEST) | From | Finn Thain <> | Subject | Re: [PATCH net] macmace: Set platform device coherent_dma_mask |
| |
On Fri, 11 May 2018, Michael Schmitz wrote:
> > I wasn't proposing to follow platform_device_register() with the mask > assignment,
I see.
> but rather to use the same strategy from the Coldfire FEC patch > (f61e64310b75): set pdev.dev.coherent_dma_mask and pdev.dev.dma_mask > _before_ calling platform_device_register(). >
That patch is attempting to solve the same problem using a different approach, but I'd prefer to keep using platform_device_register_simple().
> > If you want to avoid the overhead of defining the macmace platform > device and using platform_device_register() ... seeing as you would not > be defining just the DMA mask and nothing else, that's probably the > least effort for the MACE and SONIC drivers. >
I don't mind the effort. I want to avoid all the boilerplate.
> > You would have to be careful not to overwrite a pdev->dev.dma_mask and > pdev->dev.dma_coherent_mask that might have been set in a platform > device passed via platform_device_register here. Coldfire is the only > m68k platform currently using that, but there might be others in future. >
That Coldfire patch could be reverted if this is a better solution.
> ... But I don't think there are smaller DMA masks used by m68k drivers > that use the platform device mechanism at present. I've only looked at > arch/m68k though.
So we're back at the same problem that Geert's suggestion also raised: how to identify potentially affected platform devices and drivers?
Maybe we can take a leaf out of Christoph's book, and leave a noisy WARNING splat in the log.
void arch_setup_pdev_archdata(struct platform_device *pdev) { WARN_ON_ONCE(pdev->dev.coherent_dma_mask != DMA_MASK_NONE || pdev->dev.dma_mask != NULL); pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32); pdev->dev.dma_mask = &pdev->dev.coherent_dma_mask; }
--
| |