Re: [PATCH 6.1 v2] crypto: qat - fix ring to service map for QAT GEN4

[Greg KH <gregkh@linuxfoundation.org>]

On Mon, Aug 18, 2025 at 12:29:13PM +0100, Giovanni Cabiddu wrote:
> Hi Greg and Sasha,
> 
> On Tue, Jul 22, 2025 at 04:07:09PM +0100, Giovanni Cabiddu wrote:
> > [ Upstream commit a238487f7965d102794ed9f8aff0b667cd2ae886 ]
> > 
> > The 4xxx drivers hardcode the ring to service mapping. However, when
> > additional configurations where added to the driver, the mappings were
> > not updated. This implies that an incorrect mapping might be reported
> > through pfvf for certain configurations.
> > 
> > This is a backport of the upstream commit with modifications, as the
> > original patch does not apply cleanly to kernel v6.1.x. The logic has
> > been simplified to reflect the limited configurations of the QAT driver
> > in this version: crypto-only and compression.
> > 
> > Instead of dynamically computing the ring to service mappings, these are
> > now hardcoded to simplify the backport.
> > 
> > Fixes: 0cec19c761e5 ("crypto: qat - add support for compression for 4xxx")
> > Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
> > Reviewed-by: Damian Muszynski <damian.muszynski@intel.com>
> > Reviewed-by: Tero Kristo <tero.kristo@linux.intel.com>
> > Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
> > (cherry-picked from commit a238487f7965d102794ed9f8aff0b667cd2ae886)
> > [Giovanni: backport to 6.1.y, conflict resolved simplifying the logic
> > in the function get_ring_to_svc_map() as the QAT driver in v6.1 supports
> > only limited configurations (crypto only and compression).  Differs from
> > upstream as the ring to service mapping is hardcoded rather than being
> > dynamically computed.]
> > Reviewed-by: Ahsan Atta <ahsan.atta@intel.com>
> > Tested-by: Ahsan Atta <ahsan.atta@intel.com>
> > Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
> > ---
> > V1 -> V2: changed signed-off-by area:
> >   * added (cherry-picked from ...) after last tag from upstream commit
> >   * added a note explaining how this backport differs from the original patch
> >   * added a new Signed-off-by tag for the backport author.
> 
> Just following up on this patch as I haven't seen any activity on it yet.
> 
> Was it possibly missed, or is there anything I should do to move it
> forward?

It's in a pending queue of hundreds of stable backports I have yet to
get to.  That's what I get for trying to take a vacation... :)

Don't worry, it's not lost, just that we have to process patches for the
newer stable kernels first, as that's where we have the most users.
This, and many others, will be gotten to in a week or so.

thanks,

greg k-h