On Mon, Oct 27, 2014 at 05:30:41PM +0200, Ivan T. Ivanov wrote:

Hi Dmitry, 

On Mon, 2014-10-13 at 16:02 +0200, Mark Brown wrote:

quoted

On Wed, Oct 08, 2014 at 01:32:33PM -0700, Dmitry Torokhov wrote:

quoted

On Wed, Oct 08, 2014 at 09:04:26PM +0100, Mark Brown wrote:

quoted

On Wed, Oct 08, 2014 at 11:20:58AM -0700, Stephen Boyd wrote:

quoted

quoted

quoted

Srini/Mark, any reason why the regmap_field structure is opaque?

quoted

quoted

So you can't peer into it and rely on the contents.  I can see it being
useful to add a bulk allocator.

quoted

And then one have to define offsets in an array and use awkward syntax
to access individual fields. Can we just reply on reviews/documentation
for users to not do wrong thing?

I have very little confidence in users not doing awful things to be
honest, this is the sort of API where the users are just random things
all over the kernel so this sort of thing tends to be found after the
fact.  I get a lot of these in drivers that just got thrown over the
wall so nobody really knows what things are doing when you do find them.

If the standard allocators aren't doing a good job (I've not checked)
I'd much rather handle this inside the API if we can.

Is there something that I can help here or patches are good as they are? :-)

Well, as far as I can see Bjorn (in the other thread) has some
objections on merging these devices together, so I ma just waiting for
you settle this issue.

I see he's not on this therad so let's CC him.

For the record I ma still not happy that we need to dynamically allocate
all these regmap fields.

Thanks.

-- 
Dmitry