[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YVbqbq180jgrhiIe@Ansuel-xps.localdomain>
Date: Fri, 1 Oct 2021 13:01:02 +0200
From: Ansuel Smith <ansuelsmth@...il.com>
To: Florian Fainelli <f.fainelli@...il.com>
Cc: Andrew Lunn <andrew@...n.ch>,
Vivien Didelot <vivien.didelot@...il.com>,
Vladimir Oltean <olteanv@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH net-next] drivers: net: dsa: qca8k: convert to
GENMASK/FIELD_PREP/FIELD_GET
On Thu, Sep 30, 2021 at 07:14:13PM -0700, Florian Fainelli wrote:
>
>
> On 9/30/2021 6:37 PM, Ansuel Smith wrote:
> > Convert and try to standardize bit fields using
> > GENMASK/FIELD_PREP/FIELD_GET macros. Rework some logic to support the
> > standard macro and tidy things up. No functional change intended.
> >
> > Signed-off-by: Ansuel Smith <ansuelsmth@...il.com>
> > ---
> >
> > I still need to test this in every part but I would like to have some
> > approval about this kind of change. Also there are tons of warning by
> > checkpatch about too long line... Are they accepted for headers? I can't
> > really find another way to workaround the problem as reducing the define
> > name would make them less descriptive.
> > Aside from that I did the conversion as carefully as possible so in
> > theory nothing should be broken and the conversion should be all
> > correct. Some real improvement by using filed macro are in the
> > fdb_read/fdb_write that now are much more readable.
>
> My main concern is that it is going to be a tad harder to back port fixes
> made to this driver with such changes in place, so unfortunately it is
> usually a matter of either the initial version of the driver use BIT(),
> FIELD_{PREP,GET} and GENMASK, or the very few commits following the initial
> commit take care of that, and then it is all rosy for everyone, or else it
> may be complicated.
>
> You are one of the active contributors to this driver, so ultimately you
> should decide.
> --
> Florian
Problem I'm trying to solve here is that I notice various name scheme
used and not an unique one... (many _S and _M mixed with MASK and SHIFT)
Various shift and strange bits handling. I think this is needed to
improve the code in all the next release.
About backports you mean for older kernel (bugfixes) or for external
project (backports for openwrt, for example?) Anyway in the main code
(the one in theory that should receive backports) I just reworked the ACL
code that should be stable and the switch ID handling (I don't think
there is anything to fix there). Aside from that and some improvement to
VLAN, I tried to implement FIELD_PREP only in the define without
touching qca8k code.
I honestly don't know if this would cause that much of a problem with
backports (assuming they only touch qca8k code and not header).
Would love to receive some feedback if I'm wrong about my idea.
Any feedback about the warning for long names in the define? Are they
accepted? I can't find anywhere how we should handle them.
--
Ansuel
Powered by blists - more mailing lists