| Message ID | 20200531122640.1375715-2-olteanv@gmail.com |
|---|---|
| State | Changes Requested |
| Delegated to: | David Miller |
| Headers | show |
| Series | New DSA driver for VSC9953 Seville switch | expand |
On Sun, May 31, 2020 at 03:26:28PM +0300, Vladimir Oltean wrote: > From: Vladimir Oltean <vladimir.oltean@nxp.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@nxp.com> > Link: https://lore.kernel.org/r/20200527234113.2491988-2-olteanv@gmail.com > Signed-off-by: Mark Brown <broonie@kernel.org> Please either just wait till after the merge window or ask for a pull request like I said when I applied the patch.
Hi Mark, On Mon, 1 Jun 2020 at 13:54, Mark Brown <broonie@kernel.org> wrote: > > On Sun, May 31, 2020 at 03:26:28PM +0300, Vladimir Oltean wrote: > > From: Vladimir Oltean <vladimir.oltean@nxp.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@nxp.com> > > Link: https://lore.kernel.org/r/20200527234113.2491988-2-olteanv@gmail.com > > Signed-off-by: Mark Brown <broonie@kernel.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. 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. But apparently that is now how things work, so could you please create a pull request for David with this patch? Thanks! -Vladimir
On 01/06/2020 14:12:38+0300, Vladimir Oltean wrote: > Hi Mark, > > On Mon, 1 Jun 2020 at 13:54, Mark Brown <broonie@kernel.org> wrote: > > > > On Sun, May 31, 2020 at 03:26:28PM +0300, Vladimir Oltean wrote: > > > From: Vladimir Oltean <vladimir.oltean@nxp.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@nxp.com> > > > Link: https://lore.kernel.org/r/20200527234113.2491988-2-olteanv@gmail.com > > > Signed-off-by: Mark Brown <broonie@kernel.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.
On Mon, Jun 01, 2020 at 01:51:31PM +0200, Alexandre Belloni wrote: > On 01/06/2020 14:12:38+0300, Vladimir Oltean wrote: > > 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. Right, in general you shouldn't resend patches which have already been applied especially not to other maintainers. It causes confusion like we saw earlier with Dave applying the patch again (fortunately it seems that he reverted it). As well as the duplicated commits this is often a source of merge confilicts if any changes are made on top of the patch. I've now sent my pull request for this cycle so it should appear in v5.8-rc1 but in case Dave is still applying stuff even after the merge window opened: The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136: Linux 5.7-rc1 (2020-04-12 12:35:55 -0700) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git tags/regmap-per-port-field for you to fetch changes up to 8baebfc2aca26e3fa67ab28343671b82be42b22c: regmap: add helper for per-port regfield initialization (2020-05-29 13:44:30 +0100) ---------------------------------------------------------------- regmap: Add per-port field initialization helpers ---------------------------------------------------------------- Vladimir Oltean (1): regmap: add helper for per-port regfield initialization include/linux/regmap.h | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/include/linux/regmap.h b/include/linux/regmap.h index 40b07168fd8e..87703d105191 100644 --- a/include/linux/regmap.h +++ b/include/linux/regmap.h @@ -1134,6 +1134,14 @@ struct reg_field { .msb = _msb, \ } +#define REG_FIELD_ID(_reg, _lsb, _msb, _size, _offset) { \ + .reg = _reg, \ + .lsb = _lsb, \ + .msb = _msb, \ + .id_size = _size, \ + .id_offset = _offset, \ + } + struct regmap_field *regmap_field_alloc(struct regmap *regmap, struct reg_field reg_field); void regmap_field_free(struct regmap_field *field);