From: Vladimir Oltean <olteanv@gmail.com>
To: Ansuel Smith <ansuelsmth@gmail.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
Vivien Didelot <vivien.didelot@gmail.com>,
Florian Fainelli <f.fainelli@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
Russell King <linux@armlinux.org.uk>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [net-next PATCH v2 5/9] net: dsa: qca8k: convert qca8k to regmap helper
Date: Mon, 22 Nov 2021 04:22:11 +0200 [thread overview]
Message-ID: <20211122022211.jqlo4pts46gyavca@skbuf> (raw)
In-Reply-To: <619af8f3.1c69fb81.71bf6.e95d@mx.google.com>
On Mon, Nov 22, 2021 at 02:56:58AM +0100, Ansuel Smith wrote:
> > Maybe you could keep qca8k_read and qca8k_write and make them return
> > regmap_read(priv->regmap, ...), this could reduce the patch's delta,
> > make future bugfix patches conflict less with this change, etc etc.
> > What do you think?
>
> Problem is that many function will have to be moved to a separate file
> (for the common stuff) and they won't have qca8k_read/write/rmw...
> So converting everything to regmap would be handy as you drop the
> extra functions.
> But I see how reworking the read/write/rmw would massively reduce the
> patch delta.
>
> When we will have to split the code, we will have this problem again and
> we will have to decide if continue using the qca8k_read/write... or drop
> them and switch to regmap.
>
> So... yes i'm stuck as if we want to save some conflicts we will have to
> carry the extra function forver I think.
> (Wonder if the conflict problem will just be """solved""" with the code
> split as someone will have to rework the patch anyway as the function
> will be located on a different file)
Yeah, well, if you have to split then you have to split. It probably
won't be pretty, with a lot of code added for v5.16 and now for v5.17,
so it hasn't had time to reach to a larger pool of users and get cleaned
of bugs which you didn't notice. But what can you do. Other than wait
for a few months for the code to stabilize (which is counterproductive
in its own ways), probably nothing.
next prev parent reply other threads:[~2021-11-22 2:22 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-22 1:03 [net-next PATCH v2 0/9] Multiple cleanup and feature for qca8k Ansuel Smith
2021-11-22 1:03 ` [net-next PATCH v2 1/9] net: dsa: qca8k: remove redundant check in parse_port_config Ansuel Smith
2021-11-22 1:03 ` [net-next PATCH v2 2/9] net: dsa: qca8k: convert to GENMASK/FIELD_PREP/FIELD_GET Ansuel Smith
2021-11-22 1:03 ` [net-next PATCH v2 3/9] net: dsa: qca8k: remove extra mutex_init in qca8k_setup Ansuel Smith
2021-11-22 1:32 ` Vladimir Oltean
2021-11-22 1:03 ` [net-next PATCH v2 4/9] net: dsa: qca8k: move regmap init in probe and set it mandatory Ansuel Smith
2021-11-22 1:33 ` Vladimir Oltean
2021-11-22 1:03 ` [net-next PATCH v2 5/9] net: dsa: qca8k: convert qca8k to regmap helper Ansuel Smith
2021-11-22 1:38 ` Vladimir Oltean
2021-11-22 1:56 ` Ansuel Smith
2021-11-22 2:22 ` Vladimir Oltean [this message]
2021-11-22 1:03 ` [net-next PATCH v2 6/9] net: dsa: qca8k: add additional MIB counter and make it dynamic Ansuel Smith
2021-11-22 1:03 ` [net-next PATCH v2 7/9] net: dsa: qca8k: add support for port fast aging Ansuel Smith
2021-11-22 1:40 ` Vladimir Oltean
2021-11-22 1:03 ` [net-next PATCH v2 8/9] net: dsa: qca8k: add set_ageing_time support Ansuel Smith
2021-11-22 1:40 ` Vladimir Oltean
2021-11-22 1:03 ` [net-next PATCH v2 9/9] net: dsa: qca8k: add support for mdb_add/del Ansuel Smith
2021-11-22 1:48 ` Vladimir Oltean
2021-11-22 1:29 ` [net-next PATCH v2 0/9] Multiple cleanup and feature for qca8k Vladimir Oltean
2021-11-22 1:43 ` Ansuel Smith
2021-11-22 1:55 ` Vladimir Oltean
2021-11-22 12:21 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211122022211.jqlo4pts46gyavca@skbuf \
--to=olteanv@gmail.com \
--cc=andrew@lunn.ch \
--cc=ansuelsmth@gmail.com \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=vivien.didelot@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox