Re: FAILED: patch "[PATCH] IB/mlx5: Replace tunnel mpls capability bits for" failed to apply to 4.19-stable tree

[Greg KH <gregkh@linuxfoundation.org>]

On Mon, Apr 13, 2020 at 10:26:59PM -0400, Sasha Levin wrote:
> On Fri, Apr 10, 2020 at 11:01:43AM +0200, gregkh@linuxfoundation.org wrote:
> > 
> > The patch below does not apply to the 4.19-stable tree.
> > If someone wants it applied there, or to any other stable or longterm
> > tree, then please email the backport, including the original git commit
> > id to <stable@vger.kernel.org>.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> > ------------------ original commit in Linus's tree ------------------
> > 
> > > From 41e684ef3f37ce6e5eac3fb5b9c7c1853f4b0447 Mon Sep 17 00:00:00 2001
> > From: Alex Vesker <valex@mellanox.com>
> > Date: Thu, 5 Mar 2020 14:38:41 +0200
> > Subject: [PATCH] IB/mlx5: Replace tunnel mpls capability bits for
> > tunnel_offloads
> > 
> > Until now the flex parser capability was used in ib_query_device() to
> > indicate tunnel_offloads_caps support for mpls_over_gre/mpls_over_udp.
> > 
> > Newer devices and firmware will have configurations with the flexparser
> > but without mpls support.
> > 
> > Testing for the flex parser capability was a mistake, the tunnel_stateless
> > capability was intended for detecting mpls and was introduced at the same
> > time as the flex parser capability.
> > 
> > Otherwise userspace will be incorrectly informed that a future device
> > supports MPLS when it does not.
> > 
> > Link: https://lore.kernel.org/r/20200305123841.196086-1-leon@kernel.org
> > Cc: <stable@vger.kernel.org> # 4.17
> > Fixes: e818e255a58d ("IB/mlx5: Expose MPLS related tunneling offloads")
> > Signed-off-by: Alex Vesker <valex@mellanox.com>
> > Reviewed-by: Ariel Levkovich <lariel@mellanox.com>
> > Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> > Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
> 
> The conflict was around the cqe_checksum_full cap bit being exposed by
> db849faa9bef ("net/mlx5e: Rx, Fix checksum calculation for new
> hardware").
> 
> I've resolved it by exposing cqe_checksum_full, but *not* taking
> db849faa9bef.

Thanks for doing this!

greg k-h