Hi Finn,
Am 11.05.2018 um 17:28 schrieb Finn Thain:
On Fri, 11 May 2018, Michael Schmitz wrote:
I'm afraid using platform_device_register() (which you already use for
the SCC devices) is the only option handling this on a per-device basis
without touching platform core code, while at the same time keeping the
DMA mask setup out of device drivers
I don't think that will fly. If you call platform_device_register() and
follow that with a dma mask assignment, you could race with the bus
matching and driver probe, and we are back to the same WARNING message.
I wasn't proposing to follow platform_device_register() with the mask
assignment, 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().
If you want to use platform_device_register(), you'd have to implement
arch_setup_pdev_archdata() and use that to set up the dma mask.
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 can see Geert's point there - device driver code might be shared
across implementations of the device on platforms with different DMA
mask requirements,, something the driver can't be expected to know
about).
As I said, these drivers might be expected to be portable between Macs and
early PowerMacs, but the same dma mask would apply AFAIK.
If a platform driver isn't expected to be portable, I think either method
is reasonable: arch_setup_pdev_archdata() or the method in the patch.
Anyway, there is this in arch/powerpc/kernel/setup-common.c:
void arch_setup_pdev_archdata(struct platform_device *pdev)
{
pdev->archdata.dma_mask = DMA_BIT_MASK(32);
pdev->dev.dma_mask = &pdev->archdata.dma_mask;
...
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.
I'm inclined to propose something similar for m68k. That should fix the
problem, since arch_setup_pdev_archdata() is already in the call chain:
platform_device_register_simple()
platform_device_register_resndata()
platform_device_register_full()
platform_device_alloc()
arch_setup_pdev_archdata()
Thoughts? Will this have nasty side effects for m68k platforms that use
smaller dma masks?
These can still set a smaller mask in pdev->dev directly and use
platform_device_register() instead. 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.
Cheers,
Michael
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
