From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Mark Brown <broonie@kernel.org>
Cc: Stephen Boyd <sboyd@codeaurora.org>,
Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
"Ivan T. Ivanov" <iivanov@mm-sol.com>,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-msm@vger.kernel.org
Subject: Re: [PATCH 2/4] Input: pmic8xxx-keypad - use regmap_field for register access
Date: Wed, 8 Oct 2014 13:32:33 -0700 [thread overview]
Message-ID: <20141008203233.GA15198@dtor-ws> (raw)
In-Reply-To: <20141008200426.GJ4609@sirena.org.uk>
On Wed, Oct 08, 2014 at 09:04:26PM +0100, Mark Brown wrote:
> On Wed, Oct 08, 2014 at 11:20:58AM -0700, Stephen Boyd wrote:
> > On 10/08/2014 11:13 AM, Dmitry Torokhov wrote:
>
> > >>>Oops. struct regmap_field is opaque. It seems that the allocation
> > >>>is the only way that I could have instance of it.
>
> > >>Maybe we can add an API to allocate an array of fields?
>
> > >Maybe we could make the structure public instead? I do not see any
> > >reason for allocating something separately that has exactly the same
> > >lifetime as owning structure.
>
> The lifetime may be different to that of the register map it references,
> consider MFD function devices for example.
Exactly, it is different than lifetime of the register map, but the same
as device structure of the driver instantiating it. And so instead of
doing 10+ separate allocations one could do just one.
>
> > Srini/Mark, any reason why the regmap_field structure is opaque?
>
> So you can't peer into it and rely on the contents. I can see it being
> useful to add a bulk allocator.
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?
Thanks.
--
Dmitry
next prev parent reply other threads:[~2014-10-08 20:32 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1412675448-11990-1-git-send-email-iivanov@mm-sol.com>
2014-10-07 9:50 ` [PATCH 1/4] Input: pmic8xxx-keypad - remove unused register and bit definitions Ivan T. Ivanov
2014-10-07 9:50 ` [PATCH 2/4] Input: pmic8xxx-keypad - use regmap_field for register access Ivan T. Ivanov
2014-10-07 17:26 ` Dmitry Torokhov
2014-10-08 9:13 ` Ivan T. Ivanov
2014-10-08 9:30 ` Ivan T. Ivanov
2014-10-08 18:00 ` Stephen Boyd
2014-10-08 18:13 ` Dmitry Torokhov
2014-10-08 18:20 ` Stephen Boyd
2014-10-08 20:04 ` Mark Brown
2014-10-08 20:32 ` Dmitry Torokhov [this message]
2014-10-13 14:02 ` Mark Brown
2014-10-27 15:30 ` Ivan T. Ivanov
2014-10-27 16:06 ` Dmitry Torokhov
2014-10-27 16:20 ` Ivan T. Ivanov
2014-10-27 16:26 ` Dmitry Torokhov
[not found] ` <1412675448-11990-1-git-send-email-iivanov-NEYub+7Iv8PQT0dZR+AlfA@public.gmane.org>
2014-10-07 9:50 ` [PATCH 3/4] Input: pmic8xxx-keypad - add support keypad found in pm8941 Ivan T. Ivanov
2014-10-07 9:50 ` [PATCH 4/4] Input: pmic8xxx-keypad - update DT bindings documentation Ivan T. Ivanov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141008203233.GA15198@dtor-ws \
--to=dmitry.torokhov@gmail.com \
--cc=broonie@kernel.org \
--cc=iivanov@mm-sol.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sboyd@codeaurora.org \
--cc=srinivas.kandagatla@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).