Date:   Mon, 22 Nov 2021 04:22:11 +0200
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
Message-ID: <20211122022211.jqlo4pts46gyavca@skbuf>
References: <20211122010313.24944-1-ansuelsmth@gmail.com>
 <20211122010313.24944-6-ansuelsmth@gmail.com>
 <20211122013853.dpprmlprm2q2f24v@skbuf>
 <619af8f3.1c69fb81.71bf6.e95d@mx.google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <619af8f3.1c69fb81.71bf6.e95d@mx.google.com>
Precedence: bulk

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.