linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Trilok Soni <tsoni@codeaurora.org>
Cc: Rabin Vincent <rabin.vincent@stericsson.com>,
	Sundar R IYER <sundar.iyer@stericsson.com>,
	"sameo@linux.intel.com" <sameo@linux.intel.com>,
	"linux-input@vger.kernel.org" <linux-input@vger.kernel.org>,
	STEricsson_nomadik_linux <STEricsson_nomadik_linux@list.st.com>
Subject: Re: [PATCH] input: add support for PowerOn(PonKey) button on the AB8500 MFD
Date: Fri, 3 Sep 2010 09:43:49 -0700	[thread overview]
Message-ID: <20100903164348.GD2200@core.coreip.homeip.net> (raw)
In-Reply-To: <4C8084C7.4020105@codeaurora.org>

On Fri, Sep 03, 2010 at 10:46:55AM +0530, Trilok Soni wrote:
> Hi Dmitry,
> 
> On 9/3/2010 1:54 AM, Dmitry Torokhov wrote:
> >>
> > 
> > I disagree. I believe that drivers should use request_threaded_irq()
> > only if they _themselves_ require handling interrupts in process context.
> > The fact that someone up the stack set up threaded IRQ and not hard IRQ
> > should not matter.
> > 
> > Ideally I'd love request_irq() to be what request_any_context_irq()
> > currently is and then we'd have request_hard_irq() for driver that
> > absolutely need hard IRQ context.
> > 
> 
> Well, how I see the request_any_context_irq(...) call is that when the caller
> doesn't know the protocol being setup from the irq core code

Well, here lies the difference in our approaches ;) For me it is not
that the driver does not know, but that it does not _care_. It, by
itself, can work in both threaded and hard interrupt mode.

I do believe that driver should request threaded interrupts only if they
need threaded interrupts.

> and how the line
> he is controlling was being setup, so in that case request_any_context_irq(..)
> to be the safest call. But in this case we know that it will be __always__
> threaded due the PMIC driven over slow bus.
> 
> May be multiple APIs are now causing confusion :)
> 

Thanks.

-- 
Dmitry

  reply	other threads:[~2010-09-03 16:44 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-01  7:35 [PATCH] input: add support for PowerOn(PonKey) button on the AB8500 MFD Sundar Iyer
2010-09-01 16:51 ` Dmitry Torokhov
2010-09-02  6:55   ` Rabin Vincent
2010-09-02 17:22     ` Dmitry Torokhov
2010-09-02 19:53       ` Trilok Soni
2010-09-02 20:24         ` Dmitry Torokhov
2010-09-03  5:16           ` Trilok Soni
2010-09-03 16:43             ` Dmitry Torokhov [this message]
2010-09-03  7:10 ` Trilok Soni
2010-09-03  7:20   ` Sundar R IYER
2010-09-03  7:54     ` Trilok Soni
2010-09-03 16:40   ` Dmitry Torokhov
2010-09-03 19:06     ` Trilok Soni
2010-09-06  3:11     ` Sundar R IYER

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=20100903164348.GD2200@core.coreip.homeip.net \
    --to=dmitry.torokhov@gmail.com \
    --cc=STEricsson_nomadik_linux@list.st.com \
    --cc=linux-input@vger.kernel.org \
    --cc=rabin.vincent@stericsson.com \
    --cc=sameo@linux.intel.com \
    --cc=sundar.iyer@stericsson.com \
    --cc=tsoni@codeaurora.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).