From: Bartlomiej Zolnierkiewicz <bzolnier@elka.pw.edu.pl>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Jeff Garzik <jgarzik@pobox.com>, linux-ide@vger.kernel.org
Subject: Re: How to cleanly setup legacy IDE irq ?
Date: Mon, 4 Oct 2004 23:21:54 +0200 [thread overview]
Message-ID: <200410042321.54530.bzolnier@elka.pw.edu.pl> (raw)
In-Reply-To: <1096853636.23141.68.camel@gaston>
On Monday 04 October 2004 03:33, Benjamin Herrenschmidt wrote:
> On Mon, 2004-10-04 at 11:33, Jeff Garzik wrote:
> > On Mon, Oct 04, 2004 at 11:26:53AM +1000, Benjamin Herrenschmidt wrote:
> > > Also, my proposal beeing sort-of "agnostic" to the IDE layer (only
> > > pdev and channel arguments), it could be useable by libata too :)
> >
> > Will, given that perspective, I wouldn't mind a pci_get_ide_irq()
> > in the PCI layer... platforms that do not provide can easily return an
> > error code unconditionally.
>
> Yup. Good idea.
>
> I'd still call it pci_get_ide_legacy_irq() though as it's really
> specific to controllers that are left in "legacy" mode. Controllers
> in "fully native" mode use the normal PCI irq routing.
What about controllers in "half native" mode
(legacy IRQs but native addressing)?
> An negative error code vs. a positive irq number looks good ? Or can
> irq numbers be legally negative on some platforms ? I'd rather have
> it return NO_IRQ in fact if the platform can't help ;) Actually, in
> 80% of the cases, those numbers will be 14 and 15, so it could even
> have a default implementation returning those....
Your proposal sounds fine but I worry that instead of crappy #ifdefs
it will end up having crappy switch (dev->device) statements.
> I'll do a patch proposal either later today or tomorrow.
OK.
next prev parent reply other threads:[~2004-10-04 21:21 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-01 3:51 How to cleanly setup legacy IDE irq ? Benjamin Herrenschmidt
2004-10-01 14:11 ` Bartlomiej Zolnierkiewicz
2004-10-02 4:30 ` Benjamin Herrenschmidt
2004-10-02 14:56 ` Bartlomiej Zolnierkiewicz
2004-10-03 0:33 ` Benjamin Herrenschmidt
2004-10-03 20:54 ` Bartlomiej Zolnierkiewicz
2004-10-03 23:42 ` Benjamin Herrenschmidt
2004-10-04 0:27 ` Bartlomiej Zolnierkiewicz
2004-10-04 1:05 ` Benjamin Herrenschmidt
2004-10-04 1:20 ` Benjamin Herrenschmidt
2004-10-04 21:35 ` Bartlomiej Zolnierkiewicz
2004-10-04 23:27 ` Benjamin Herrenschmidt
2004-10-04 1:27 ` Jeff Garzik
2004-10-04 1:26 ` Benjamin Herrenschmidt
2004-10-04 1:33 ` Jeff Garzik
2004-10-04 1:33 ` Benjamin Herrenschmidt
2004-10-04 21:21 ` Bartlomiej Zolnierkiewicz [this message]
2004-10-04 23:26 ` Benjamin Herrenschmidt
2004-10-04 23:56 ` Bartlomiej Zolnierkiewicz
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=200410042321.54530.bzolnier@elka.pw.edu.pl \
--to=bzolnier@elka.pw.edu.pl \
--cc=benh@kernel.crashing.org \
--cc=jgarzik@pobox.com \
--cc=linux-ide@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 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).