From: Ben Hutchings <ben@decadent.org.uk>
To: roel kluin <roel.kluin@gmail.com>
Cc: davem@davemloft.net, netdev@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] net: eepro testing positive EBUSY return by request_irq()?
Date: Sun, 02 Jan 2011 19:51:32 +0000 [thread overview]
Message-ID: <1293997892.3167.53.camel@localhost> (raw)
In-Reply-To: <4D209127.5080505@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2115 bytes --]
On Sun, 2011-01-02 at 15:52 +0100, roel kluin wrote:
> >> - if (request_irq (*irqp, NULL, IRQF_SHARED, "bogus", dev) != EBUSY) {
> >> + if (request_irq (*irqp, NULL, IRQF_SHARED, "bogus", dev) != -EBUSY) {
>
> > This condition is completely bogus - request_irq() with a NULL handler
> > now returns -EINVAL before even checking whether the IRQ is in use. The
> > code should be fixed along the lines of what I did for 3c503 in commit
> > b0cf4dfb7cd21556efd9a6a67edcba0840b4d98d.
> >
> > The e2100 and hp net drivers have the same bug.
> >
> > Ben.
>
> I've made an attempt to fix the mentioned issues, but I'm not sure it is complete.
> The commit made some other changes as well which didn't seem appropriate here to me.
They are absolutely necessary.
In the bad old days before plug-and-play, some expansion cards would
have jumpers to configure the IRQ number and no software mechanism to
set or query it. Users were expected to specify the IRQ to the driver
explicitly. probe_irq_{on,off}() allow drivers to avoid this by
triggering an IRQ and checking which was received. That assumes that
there are no IRQ conflicts, and it only works reliably in a quiescent
system.
These drivers have been abusing request_irq(), probe_irq_{on,off}() to
do resource allocation for hardware that *does* have a software
mechanism to set the IRQ number. This has become less reliable as
driver loading has been made more dynamic, and is now broken completely
due to the change in request_irq(). I believe the correct way to do
this allocation is what I did in 3c503. Possibly it's worth adding a
generic function.
> And I didn't compile or run test this.
I compiled but didn't have hardware to test.
> As a side note, in the function changed by the commit you mentioned, el2_open(), it
> appears that in current git, boolean `seen' cannot ever become true, can it?
[...]
The IRQ handler data is set to &seen and el2_probe_interrupt() uses that
pointer to set it.
Ben.
--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
next prev parent reply other threads:[~2011-01-02 19:51 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-31 14:47 [PATCH] net: eepro testing positive EBUSY return by request_irq()? roel kluin
2010-12-31 15:27 ` Ben Hutchings
2011-01-02 14:52 ` roel kluin
2011-01-02 19:51 ` Ben Hutchings [this message]
2011-01-03 19:37 ` David Miller
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=1293997892.3167.53.camel@localhost \
--to=ben@decadent.org.uk \
--cc=akpm@linux-foundation.org \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=roel.kluin@gmail.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).