devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Stephen Warren <swarren@wwwdotorg.org>
Cc: Samuel Ortiz <sameo@linux.intel.com>,
	Laxman Dewangan <ldewangan@nvidia.com>,
	Liam Girdwood <lrg@ti.com>,
	linux-kernel@vger.kernel.org,
	devicetree-discuss@lists.ozlabs.org,
	Gyungoh Yoo <jack.yoo@maxim-ic.com>,
	Stephen Warren <swarren@nvidia.com>
Subject: Re: [PATCH] mfd: add MAX8907 core driver
Date: Thu, 26 Jul 2012 22:51:51 +0100	[thread overview]
Message-ID: <20120726215150.GI4560@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <5011B32D.1080102@wwwdotorg.org>

[-- Attachment #1: Type: text/plain, Size: 1404 bytes --]

On Thu, Jul 26, 2012 at 03:14:21PM -0600, Stephen Warren wrote:
> On 07/26/2012 02:35 PM, Mark Brown wrote:

> > This looks very suspicious...  why do we need to call 
> > irqd_irq_disabled() here?

> I believe the status register reflects the unmasked status, it's just
> the interrupt signal that's affected by the mask.

This is totally normal, the standard pattern here is to and the status
register with the mask register before parsing.

> So the idea here was that the IRQ core is already maintaining state
> which describes which IRQs are enabled/disabled and wake/not. Rather
> than have irq_enable/irq_disable/set_wake do nothing but save the same
> state to irq_chip-specific structures, I removed the body of those
> functions and instead just call irqd_irq_disabled() etc. wherever I
> would have accessed the "local" state. Is that not a legitimate design
> then?

It seems very smelly, if you were supposed to do this then you wouldn't
have to be defining the empty operations.  There's also the counter
argument that it means you've got to go through every interrupt and work
out the state before syncing rather than just being able to blast the
register states in but that's fairly weak.

I think it's a totally sensible idea to reuse the state in the core, but
I do think it's a bad idea to dance around the core's back like this
with the empty operations.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2012-07-26 21:51 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-26 19:40 [PATCH] mfd: add MAX8907 core driver Stephen Warren
2012-07-26 20:35 ` Mark Brown
     [not found]   ` <20120726203526.GD4560-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2012-07-26 21:14     ` Stephen Warren
2012-07-26 21:51       ` Mark Brown [this message]
2012-07-26 22:07   ` Stephen Warren
2012-07-26 22:16     ` Mark Brown
2012-07-27  6:36 ` Laxman Dewangan
  -- strict thread matches above, loose matches on Subject: below --
2012-08-01 20:48 Stephen Warren
2012-08-02 16:15 ` Mark Brown
2012-08-02 17:11   ` Stephen Warren
2012-08-02 17:56     ` Mark Brown

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=20120726215150.GI4560@opensource.wolfsonmicro.com \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=jack.yoo@maxim-ic.com \
    --cc=ldewangan@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lrg@ti.com \
    --cc=sameo@linux.intel.com \
    --cc=swarren@nvidia.com \
    --cc=swarren@wwwdotorg.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).