[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aXdxY81-bXBF2sRR@horms.kernel.org>
Date: Mon, 26 Jan 2026 13:51:31 +0000
From: Simon Horman <horms@...nel.org>
To: Ethan Nelson-Moore <enelsonmoore@...il.com>
Cc: netdev@...r.kernel.org, linux-usb@...r.kernel.org,
Andrew Lunn <andrew+netdev@...n.ch>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>
Subject: Re: [PATCH net-next] net: usb: sr9700: clarify code using BIT and
GENMASK macros
On Fri, Jan 23, 2026 at 08:02:20PM -0800, Ethan Nelson-Moore wrote:
> The sr9700 driver contains many hardcoded bit shifts and masks. Make
> the code clearer and adhere to the kernel code style by replacing them
> with the equivalent BIT and GENMASK macros. Also take the opportunity
> to align some indentation.
>
> To avoid merge conflicts, code which is removed by other pending
> patches is not modified.
>
> Signed-off-by: Ethan Nelson-Moore <enelsonmoore@...il.com>
Hi Ethan,
I like where you are going with this patch.
And the conversions look correct to me.
However, I don't think this is the right strategy for avoiding conflicts.
I think that either patches that are related - say all the ones posted
recently for sr9700 - should be collected into a patchset. Or,
you should wait for patches to land before posting changes that conflict.
Either way, I think this patch should be more comprehensive
(not excluding splitting it up logically if it becomes too long).
My advice is to wait for all your outstanding sr9700 to settle. And then
collect up those that are left into a patchset, addressing review of them.
And include, in that patchset, this patch, in it's full form.
--
pw-bot: changes-requested
Powered by blists - more mailing lists