All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laxman Dewangan <ldewangan@nvidia.com>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] regmap: irq: do not write mask register if it is not supported
Date: Thu, 14 Feb 2013 17:25:13 +0530	[thread overview]
Message-ID: <511CD0A1.70606@nvidia.com> (raw)
In-Reply-To: <20130214113531.GC13249@opensource.wolfsonmicro.com>

On Thursday 14 February 2013 05:05 PM, Mark Brown wrote:
> * PGP Signed by an unknown key
>
> On Thu, Feb 14, 2013 at 04:36:08PM +0530, Laxman Dewangan wrote:
>> On Wednesday 13 February 2013 07:50 PM, Mark Brown wrote:
>>>>   	for (i = 0; i < d->chip->num_regs; i++) {
>>>> +		if (!d->chip->mask_base)
>>>> +			goto skip_mask_reg_update;
>>> Why is this inside the loop?
> You appear to have ignored this question.

I have accepted this to put out of loop.
Originally  thought that Inside loop, there is two register update one 
is mask and other is wakup. If I ignore the loop for mask_base= 0 then 
probably wake_ register will not get updated and hence it is inside the 
loop to update the wake register. If there is wake_base is 0 then this 
register update will be ignored anyhow.



>
>>> I'd also expect us to return an error if a caller tries to enable or
>>> disable an interrupt, or possibly to give different ops to the IRQ
>>> subsystem, rather than just silently claim we did what we were asked.
> if I remove the mask_buf at all then how do we tell the int_sts
> register is corresponding to which gpio handler?
> This doesn't sound like something that should be open coded in
> individual interrupt controller drivers, obviously it's a bit rubbish
> that there's no way to enable or disable the interrupt but presumably
> other hardware has the same "feature" and the IRQ subsystem ought to
> understand it.
>

To support such case, can we assume that mask is always enabled 
(interrupt enabled) so that it can be use in irq_thread to mask the 
interrupt status. So during initialization, if there is no mask_base 
register then all mask_buf is such that it enabled interrupt.



  reply	other threads:[~2013-02-14 11:55 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-13 13:14 [PATCH 1/2] regmap: irq: Add support for interrupt type Laxman Dewangan
2013-02-13 13:14 ` [PATCH 2/2] regmap: irq: do not write mask register if it is not supported Laxman Dewangan
2013-02-13 14:20   ` Mark Brown
2013-02-14 11:06     ` Laxman Dewangan
2013-02-14 11:35       ` Mark Brown
2013-02-14 11:55         ` Laxman Dewangan [this message]
2013-02-14 11:57           ` Mark Brown
2013-02-14 12:16             ` Laxman Dewangan
2013-02-13 13:54 ` [PATCH 1/2] regmap: irq: Add support for interrupt type Mark Brown
2013-02-14 11:01   ` Laxman Dewangan
2013-02-14 11:06     ` 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=511CD0A1.70606@nvidia.com \
    --to=ldewangan@nvidia.com \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.