Re: [PATCH net-next 07/12] net: stmmac: dwxgmac2: export symbols for XGMAC 3.01a DMA

On 5/2/26 10:56 AM, [email protected] wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Low] Bypassing standard DMA address translation via custom op-table overrides.
> --
> 
> commit 6c8a6ba67e29de7e71f5090bcca63c458ee9639d
> Author: Daniel Thompson <[email protected]>
> 
> net: stmmac: dwxgmac2: export symbols for XGMAC 3.01a DMA
> 
> This patch exports several DMA operations and descriptor tables from the
> dwxgmac2 core to allow platform-specific code to override them. This
> override allows the platform code to perform manual DMA address translations
> required by the chip's internal AXI bus mappings.
> 
>> One consequence of the SoC-like design is that the internal AXI bus
>> (used by the XGMAC for DMA) maps the PCI DMA space with a non-zero base
>> address. This requires a translation step (happily just simple addition)
>> to convert the PCI DMA address to the hardware DMA address.
>>
>> This is pretty funky so rather than push that translation logic into
>> the core driver we intend to keep that logic inside the TC956x
>> platform code. In order to do that we need to export a few symbols
>> to allow us to override some of the DMA and descriptor op tables.
> 
> This isn't a bug, but does this approach bypass the standard Linux DMA API?
> 
> The standard DMA API natively handles device-specific address offsets, such
> as through dma_range_map on the struct device.
> 
> Could this address translation be handled using the standard DMA abstractions
> instead of open-coding it via op-table overrides and exporting these internal
> symbols?

I'm answering this on Daniel's behalf.  He tried setting up
the DMA range mapping but it did not have the desired effect.
He suspects that the involvement of an IOMMU affects what the
range map can do for peripherals.

Guidance on how to do this better is welcome.

					-Alex