Re: [RFC PATCH v2 0/2] regmap: add APIs to bypass regmap_field and work with reg_field directly

[Victor Chernyakin]

> > Working with the existing regmap_field_* APIs requires you to define
> > a reg_field, then use one of the regmap_field_*_alloc functions to turn
> > it into a dynamically allocated regmap_field. But reg_field and
> > regmap_field are practically the same struct; all the *_alloc functions do
> > is shuffle the data around. So this RFC proposes adding functions that
> > cut out the middleman and take reg_field directly. Patch 1 adds two
> > of them: regmap_reg_field_read and regmap_reg_field_write.
> >
> > Patch 2 ports a driver to use these new functions. The result is
> > shorter and simpler, since all the code to perform the allocations
> > and manage the resulting regmap_fields goes away. In theory,
> > there should also be a performance benefit (we're doing fewer allocations
> > and have less duplicated state), but I haven't benchmarked it, so take that
> > with a grain of salt.
> >
> > If we like this approach, I can post a v3 that adds regmap_reg_field_*
> > analogs for all the regmap_field_* functions, not just the two you see
> > here.
> >
> >
> > This is not actually a new idea! Both it and the current *_alloc approach
> > were suggested as alternatives right when the regmap_field_* APIs were
> > being added [1]. The *_alloc approach was chosen without much
> > discussion, but I think (and Patch 2 demonstrates, I hope) that
> > this approach is the cleaner one.
> 
> It may be good to Cc your attempts to the authors (and active
> reviewers) of the mentioned change.
> 
> > [1] https://lore.kernel.org/20130604210137.GV31367@xxxxxxxxxxxxx

That would make sense, here we go:

Cc: Srinivas Kandagatla <srini@xxxxxxxxxx>
Cc: Lars-Peter Clausen <lars@xxxxxxxxxx>