[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200601115131.GA3720@piout.net>
Date: Mon, 1 Jun 2020 13:51:31 +0200
From: Alexandre Belloni <alexandre.belloni@...tlin.com>
To: Vladimir Oltean <olteanv@...il.com>
Cc: Mark Brown <broonie@...nel.org>,
"David S. Miller" <davem@...emloft.net>,
netdev <netdev@...r.kernel.org>, Andrew Lunn <andrew@...n.ch>,
Vivien Didelot <vivien.didelot@...il.com>,
Florian Fainelli <f.fainelli@...il.com>,
Antoine Tenart <antoine.tenart@...tlin.com>,
Microchip Linux Driver Support <UNGLinuxDriver@...rochip.com>,
Alexandru Marginean <alexandru.marginean@....com>,
Claudiu Manoil <claudiu.manoil@....com>,
"Madalin Bucur (OSS)" <madalin.bucur@....nxp.com>,
radu-andrei.bulie@....com, fido_max@...ox.ru
Subject: Re: [PATCH v3 net-next 01/13] regmap: add helper for per-port
regfield initialization
On 01/06/2020 14:12:38+0300, Vladimir Oltean wrote:
> Hi Mark,
>
> On Mon, 1 Jun 2020 at 13:54, Mark Brown <broonie@...nel.org> wrote:
> >
> > On Sun, May 31, 2020 at 03:26:28PM +0300, Vladimir Oltean wrote:
> > > From: Vladimir Oltean <vladimir.oltean@....com>
> > >
> > > Similar to the standalone regfields, add an initializer for the users
> > > who need to set .id_size and .id_offset in order to use the
> > > regmap_fields_update_bits_base API.
> > >
> > > Signed-off-by: Vladimir Oltean <vladimir.oltean@....com>
> > > Link: https://lore.kernel.org/r/20200527234113.2491988-2-olteanv@gmail.com
> > > Signed-off-by: Mark Brown <broonie@...nel.org>
> >
> > Please either just wait till after the merge window or ask for a pull
> > request like I said when I applied the patch.
>
> The trouble with waiting is that I'll then have to wait for another
> release cycle until I can send device tree patches to Shawn Guo's
> devicetree branch. So this seemed to me as the path of least friction.
You can actually have the device tree changes and the driver changes in
the same release as there is no build time dependency.
> In my mind I am not exactly sure what the pull request does to improve
> the work flow. My simplified idea was that you would send a pull
> request upstream, then David would send a pull request upstream (or
> the other way around), and poof, this common commit would disappear
> from one of the pull requests.
No, this would make you commit appear twice in the history with
different hashes. If you want to have what you suggest, Dave needs to
first take Mark's PR so both PR will have the same commit hash.
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Powered by blists - more mailing lists