Re: [PATCH v7 net] octeontx2-af: switch qmem from coherent DMA alloc to streaming DMA mapping
From: Leon Romanovsky
Date: Tue Sep 08 2026 - 02:21:40 EST
On Mon, Sep 07, 2026 at 05:44:48PM +0530, Ratheesh Kannoth wrote:
> On 2026-09-07 at 17:02:44, Leon Romanovsky (leon@xxxxxxxxxx) wrote:
> > > > > + */
> > > > > + if (order > MAX_PAGE_ORDER) {
> > > >
> > > > Size is coming from the kernel, how can it be with order more than MAX_PAGE_ORDER?
> > > There is contigious memory allocation request from driver for PF-to-VF mail box memory.
> > > It is crossing max page order in newer platforms as number of VFs per PF increased.
> >
> > I'm not sure what this means. You can't create a VF without assigning it
> > enough memory for DMA. You shouldn't get an "order > MAX_PAGE_ORDER"
> > error at this stage. If you do, there is likely another bug involved.
>
> I will move the MAX_PAGE_ORDER / size validation out of the DMA helper and handle any
> allocation failure with a clear error at the call site, where we know the required size and VF count.
>
> One question on dev_is_dma_coherent(): this qmem path relies on the platform being DMA-coherent
> (as noted in the commit message). Would you prefer that we keep this check in this function as explicit
> guard so that a future port to a non-I/O-coherent SoC fails early rather than silently misbehaving?
It is a platform integration bug to use such an SoC on a platform that
cannot support it. As with any other driver, this should not be handled
in the driver, since DMA coherency is a platform/device property.
If the device works only on a specific architecture (x86 is DMA-coherent),
add the appropriate CONFIG_ dependency in Kconfig.
Thanks