From: adharmap@codeaurora.org (Abhijeet Dharmapurikar)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH] genirq: implement read_irq_line for interrupt lines
Date: Fri, 15 Apr 2011 15:02:26 -0700 [thread overview]
Message-ID: <4DA8C072.3030705@codeaurora.org> (raw)
In-Reply-To: <20110415190319.GA24111@Krystal>
Mathieu Desnoyers wrote:
> * Abhijeet Dharmapurikar (adharmap at codeaurora.org) wrote:
>> Drivers need to be aware whether the interrupt controller is a slow bus
>> and call read_irq_line in proper context.
>
> Hrm, this strikes me as odd. Is there any way this generic API could
> handle the corner-cases without needed the caller to know this ?
Usually, a slow bus irq controller marks its irq as nested and has its
irq handler running in thread context. In that case it will be safe to
call irq_read_line from thread context. For the usual (non slow bus) irq
controller we can always call irq_read_line within irq context.
This function is intended to be called from within the handler, to know
if a rising edge or a falling edge caused the interrupt. It can be used
in other places too, but then the driver needs to be careful about the
interrupt controller slowbus nature.
The problem happens when this function is called from interrupt context
when irq controller is slowbus. For example one has taken a spin_lock
with interrupts disabled and now it wants to know the real time status
on a pin that is controlled by a slow bus controller. The slowbus
controller could end up sleeping and things go bad.
I should explain this more in the commit text. Will do so in the next
revision of this patch.
>> + * This function may be called from IRQ context only when
>> + * desc->chip->bus_lock and desc->chip->bus_sync_unlock are NULL !
>
> The comment here seems to imply "be careful when using this extremely
> fragile interface", which does not give me the warm safety feeling I
> would come to expect from a generic kernel API.
>
> Any ideas on how to improve that ?
Well, even the enable_irq() and disable_irq_nosync() have the same
calling restrictions. I picked this line from the comment block in
enable_irq() function. You think I should explain it more in the
upcoming patch?
--
Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm
Innovation Center, Inc. is a member of the Code Aurora Forum.
next prev parent reply other threads:[~2011-04-15 22:02 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-15 18:42 [RFC PATCH] genirq: implement read_irq_line for interrupt lines Abhijeet Dharmapurikar
2011-04-15 19:03 ` Mathieu Desnoyers
2011-04-15 22:02 ` Abhijeet Dharmapurikar [this message]
2011-04-15 19:11 ` Thomas Gleixner
2011-04-15 22:08 ` Abhijeet Dharmapurikar
2011-04-15 22:39 ` Thomas Gleixner
2011-04-15 23:06 ` Abhijeet Dharmapurikar
2011-04-15 19:17 ` David Daney
2011-04-15 22:17 ` Abhijeet Dharmapurikar
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=4DA8C072.3030705@codeaurora.org \
--to=adharmap@codeaurora.org \
--cc=linux-arm-kernel@lists.infradead.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).