On 2021-01-15 17:58, Paul Kocialkowski wrote:

A mechanism was recently introduced for the sunxi architecture where
the DMA offset for specific devices (under the MBUS) is set by a common
driver (sunxi_mbus). This driver calls dma_direct_set_offset to set
the device's dma_range_map manually.

However this information was overwritten by of_dma_configure_id, which
obtains the map from of_dma_get_range (or keeps it NULL when it fails
and the force_dma argument is true, which is the case for platform
devices).

As a result, the dma_range_map was always overwritten and the mechanism
could not correctly take effect.

This adds a check to ensure that no previous DMA range map is
overwritten and prints a warning when the map was already set while
also being available from dt. In this case, the map that was already
set is kept.

Hang on, the hard-coded offset is only intended to be installed when 
there *isn't* anything described in DT, in which case of_dma_get_range() 
should always bail out early without touching it anyway. This sounds 
like something's not quite right in the MBUS driver, so I don't think 
working around it in core code is really the right thing to do.

Do you have a case where one of the relevant devices inherits a 
"dma-ranges" via the regular hierarchy without indirecting via an 
"interconnects" reference? Currently you're only checking for the 
latter, so that would be one way things could go awry (although to be a 
problem, said "dma-ranges" would also have to encode something *other* 
than the appropriate MBUS offset, which implies an incorrect or at least 
inaccurately-structured DT as well).

Robin.