of/platform: Initialise default DMA masks
PATCH 1/1 of/platform: Initialise default DMA masks
When of_dma_configure() was first born in 591c1ee465ce ("of: configure the platform device dma parameters"), everything DMA-related was factored out of of_platform_device_create_pdata() as seemed appropriate at the time. However, now that of_dma_configure() has grown into the generic handler for processing DMA-related properties from DT for all kinds of devices, it is no longer an appropriate place to be doing OF-platform-specific business. Since there are still plenty of platform drivers not setting their own masks and depending on the bus default, let's reinstate that inialisation in the OF-platform code itself, and restore the long-standing status quo from 0589342c2794 ("of: set dma_mask to point to coherent_dma_mask")
---
This shouldn't strictly depend on the changes currently queued in the dma-mapping tree, so should be OK to go through the DT tree in parallel. Ideally we'd fix all DMA-capable drivers to set their masks correctly, but in the short term everyone's going to get cross about -rc1 not booting...
Robin.
drivers/of/platform.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/of/platform.c +3 -0
@@ -185,6 +185,9 @@ static struct platform_device *of_platform_device_create_pdata(if (!dev) goto err_clear_flag; + dev->dev.coherent_dma_mask =DMA_BIT_MASK (32 ); +if (!dev->dev.dma_mask) + dev->dev.dma_mask = &dev->dev.coherent_dma_mask; dev->dev.bus = &platform_bus_type; dev->dev.platform_data = platform_data;of_msi_configure (&dev->dev, dev->dev.of_node);
Signature · 1 line
2.17.1.dirty
PATCH 1/1 of/platform: Initialise default DMA masks
Quoted 5 lines · Robin Murphy
This shouldn't strictly depend on the changes currently queued in the dma-mapping tree, so should be OK to go through the DT tree in parallel. Ideally we'd fix all DMA-capable drivers to set their masks correctly, but in the short term everyone's going to get cross about -rc1 not booting...
I'd prefer to pick this up through the dma-mapping tree, and in fact move it before the bus_dma_mask changes just to keep a bisectable tree.
PATCH 1/1 of/platform: Initialise default DMA masks
Quoted 10 lines · Christoph Hellwig
Quoted 5 lines · Robin Murphy
This shouldn't strictly depend on the changes currently queued in the dma-mapping tree, so should be OK to go through the DT tree in parallel. Ideally we'd fix all DMA-capable drivers to set their masks correctly, but in the short term everyone's going to get cross about -rc1 not booting...
I'd prefer to pick this up through the dma-mapping tree, and in fact move it before the
bus_dma_maskchanges just to keep a bisectable tree.
Sure, if Rob and Frank are OK with that I don't mind either way.
Thanks,
Robin.
PATCH 1/1 of/platform: Initialise default DMA masks
Quoted 9 lines · Robin Murphy
Quoted 7 lines · Christoph Hellwig
Quoted 5 lines · Robin Murphy
This shouldn't strictly depend on the changes currently queued in the dma-mapping tree, so should be OK to go through the DT tree in parallel. Ideally we'd fix all DMA-capable drivers to set their masks correctly, but in the short term everyone's going to get cross about -rc1 not booting...
Quoted 5 lines
Quoted 3 lines
I'd prefer to pick this up through the dma-mapping tree, and in fact move it before the
bus_dma_maskchanges just to keep a bisectable tree.Sure, if Rob and Frank are OK with that I don't mind either way.
NP.
PATCH 1/1 of/platform: Initialise default DMA masks
Quoted 14 lines · Rob Herring
Quoted 13 lines · Robin Murphy
Quoted 10 lines · Christoph Hellwig
Quoted 5 lines · Robin Murphy
This shouldn't strictly depend on the changes currently queued in the dma-mapping tree, so should be OK to go through the DT tree in parallel. Ideally we'd fix all DMA-capable drivers to set their masks correctly, but in the short term everyone's going to get cross about -rc1 not booting...
I'd prefer to pick this up through the dma-mapping tree, and in fact move it before the
bus_dma_maskchanges just to keep a bisectable tree.
Quoted 5 lines
Quoted 1 line
Sure, if Rob and Frank are OK with that I don't mind either way.
NP.
Acked-by Rob Herring <[email protected]>
Ok, applied so that it gets into the next linux-next.