[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20220805142948.4dc2a1dd@kernel.org>
Date: Fri, 5 Aug 2022 14:29:48 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Alexandra Winter <wintera@...ux.ibm.com>
Cc: Andrew Lunn <andrew@...n.ch>, David Miller <davem@...emloft.net>,
netdev@...r.kernel.org, linux-s390@...r.kernel.org,
Heiko Carstens <hca@...ux.ibm.com>,
Thorsten Winkler <twinkler@...ux.ibm.com>
Subject: Re: [PATCH net 1/2] s390/qeth: update cached link_info for ethtool
On Fri, 5 Aug 2022 09:05:47 +0200 Alexandra Winter wrote:
> >> Since this is for net, than yes, maybe it would be best to go with a
> >> minimal patch to make your backwards around code work. But for
> >> net-next, you really should fix this properly.
> >
> > Then again this patch doesn't look like a regression fix (and does not
> > have a fixes tag). Channeling my inner Greg I'd say - fix this right and
> > then worry about backports later.
> This patch is a pre-req for [PATCH net 2/2] s390/qeth: use cached link_info for ethtool
> 2/2 is the regression fix.
> Guidance is welcome. Should I merge them into a single commit?
> Or clarify in the commit message of 1/1 that this is a preparation for 2/2?
Ohh, now it makes far more sense, I see. Could you please add a line to
patch 1 saying that it's a pre-req for the next change, separated out
for ease of review? Hopefully the backport does not get confused and
pulls in both of them...
Powered by blists - more mailing lists