Re: [PATCH v2] dmaengine: fsl-edma: tracing: no ptr dereference during log output

Frank Li <[email protected]> Tue, 28 Jul 2026 10:38:18 -0500
Newsgroups org.kernel.vger.dmaengine,dev.linux.lists.imx,dev.linux.lists.sashiko-reviews
Message-ID <amjM6hWy6oUXF2Rt@SMW015318>
On Tue, Jul 28, 2026 at 10:19:24AM +0200, Martin Kaiser wrote:
> Thus wrote [email protected] ([email protected]):
>
> > However, edma_writel() uses iowrite32() which assumes native CPU-endian
> > input:
>
> > drivers/dma/fsl-edma-common.h:edma_writel() {
>
> static inline void edma_writel(struct fsl_edma_engine *edma,
> 			       u32 val, void __iomem *addr)
>
> where val is always little-endian
>
> >     if (edma->big_endian)
>
> edma->big_endian is configured from a devicetree setting. It's possible that it
> doesn't match cpu endianness.
>
> Could we check __BYTE_ORDER__ instead (or additonally)?
>
>
> >         iowrite32be(val, addr);
> >     else
> >         iowrite32(val, addr);
>
> The potential endianness issue affects only the value that's written to the
> hardware. It's unrelated to the tracing patch that is reviewed here.
>
> >     trace_edma_writel(edma, addr, val);
>
> The value that's traced is always little-endian. We might have to use
> le32_to_cpu(val) in the trace event definition. But again, that would be a
> separate patch.
>
> May I ask that we put the sashiko comments asided and merge the trace event
> fix? (I'm happy to submit another patch for le32_to_cpu in the event.)

This is preexisting issue, which should not impact pick this patch. Just
wait for vinod to pick it.

It will be good if you send new patch to fix these preexisting problem.

Frank

>
> Thanks,
> Martin