From: Davide Ciminaghi <ciminaghi@gnudd.com>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: sameo@linux.intel.com, rubini@gnudd.com,
giancarlo.asnaghi@st.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/8] sta2x11-mfd : add apb-soc regs driver and factor out common code
Date: Thu, 27 Sep 2012 10:39:32 +0200 [thread overview]
Message-ID: <20120927083932.GA6799@mail.gnudd.com> (raw)
In-Reply-To: <20120926164932.GS4428@opensource.wolfsonmicro.com>
On Wed, Sep 26, 2012 at 05:49:33PM +0100, Mark Brown wrote:
> On Wed, Sep 26, 2012 at 06:31:45PM +0200, Davide Ciminaghi wrote:
>
> > Oh, and there's another problem (I'm looking at the code right now, I had
> > forgotten about this): the clock framework also asks for a spinlock_t *.
> > Regmap has its own spinlock (or mutex), and I don't think it would be a
> > good idea trying to export it.
>
> Why is this a problem? Nested spinlocks are perfectly fine.
sorry, maybe my understanding of regmap is poor, but the problem I see is
that the regmap spinlock belongs to struct regmap, which is defined in
drivers/regmap/internal.h, so it is not visible to the caller(s)
(sta2x11-mfd in this case). My interpretation is that the reason for hiding
struct regmap (and the spinlock as a consequence) has to do with what
object-oriented people call "information hiding", so exporting the spinlock
address would somehow break the design.
We could add some regmap_get_lock_address() and read the spinlock
address from sta2x11-mfd, but then to be generic we should keep into account
that a mutex could be used by some bus, so the function prototype could for
example look like this:
void regmap_get_lock_address(struct regmap *, spinlock_t *s, struct mutex *m);
so, if a spinlock is used s would be filled with the spinlock's address (and
m set to NULL), while if a mutex is used, m would be set to the address of
the mutex (and s set to NULL). My personal opinion is that introducing
such a function would expose too many implementation details to regmap
users, but if you think it is ok, this solution would of course be very simple.
Thanks
Davide
next prev parent reply other threads:[~2012-09-27 8:39 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-12 10:22 [PATCH 0/8 RESEND] sta2x11-mfd patches ciminaghi
2012-09-12 10:22 ` [PATCH 1/8] sta2x11-mfd : add apb-soc regs driver and factor out common code ciminaghi
2012-09-25 19:20 ` Mark Brown
2012-09-26 14:56 ` Davide Ciminaghi
2012-09-26 15:04 ` Mark Brown
2012-09-26 16:31 ` Davide Ciminaghi
2012-09-26 16:49 ` Mark Brown
2012-09-27 8:39 ` Davide Ciminaghi [this message]
2012-09-27 8:56 ` Davide Ciminaghi
2012-09-27 13:41 ` Davide Ciminaghi
2012-09-27 13:49 ` Mark Brown
2012-09-28 8:43 ` Davide Ciminaghi
2012-09-28 10:52 ` Mark Brown
2012-09-27 14:13 ` Alan Cox
2012-09-28 15:29 ` Davide Ciminaghi
2012-09-12 10:22 ` [PATCH 2/8] sta2x11-mfd : add sta2x11_mfd_get_regs_data() function ciminaghi
2012-09-12 10:22 ` [PATCH 3/8] sta2x11-mfd : use defines for platform devices' names ciminaghi
2012-09-12 10:22 ` [PATCH 4/8] sta2x11-mfd : only add sta2x11_mfd if it hasn't already been added ciminaghi
2012-09-12 10:22 ` [PATCH 5/8] sta2x11-mfd : platform probe: don't mind about gpio platform data ciminaghi
2012-09-12 10:22 ` [PATCH 6/8] sta2x11-mfd : use one lock per device instead of one lock per mfd ciminaghi
2012-09-12 10:22 ` [PATCH 7/8] sta2x11-mfd : add defines for some sta2x11 sctl registers ciminaghi
2012-09-12 10:22 ` [PATCH 8/8] sta2x11-mfd : add myself to copyright ciminaghi
2012-09-16 21:25 ` [PATCH 0/8 RESEND] sta2x11-mfd patches Alessandro Rubini
-- strict thread matches above, loose matches on Subject: below --
2012-09-12 10:11 ciminaghi
2012-09-12 10:11 ` [PATCH 1/8] sta2x11-mfd : add apb-soc regs driver and factor out common code ciminaghi
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=20120927083932.GA6799@mail.gnudd.com \
--to=ciminaghi@gnudd.com \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=giancarlo.asnaghi@st.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rubini@gnudd.com \
--cc=sameo@linux.intel.com \
/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).