From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
torvalds@osdl.org
Subject: Re: [ide] clean up error path in do_ide_setup_pci_device()
Date: Mon, 03 Jan 2005 21:44:33 +0000 [thread overview]
Message-ID: <1104788671.13302.63.camel@localhost.localdomain> (raw)
In-Reply-To: <58cb370e050103142269e1f67f@mail.gmail.com>
On Llu, 2005-01-03 at 22:22, Bartlomiej Zolnierkiewicz wrote:
> > Nothing in the IDE specification requires the PCI IDE controller be the
> > only use of that PCI function. The damage is probably minimal as it
> > deals with error paths but this change should be reverted (and will be
> > for -ac).
>
> Different PCI functions should have different struct pci_dev instances
> so is this really a problem?
Different PCI functions are but nothing requires that the PCI function
that is the IDE controller is only the IDE controller. In some cases
other logic lives in the "spare" BAR register areas of the device.
One example where the weird design makes it obvious is the CS5520. Here
the 5520 bridge has the IDE in one BAR and all sorts of other logic
(including the xBUS virtual ISA environment) in the same PCI function.
On that chip a pci_disable_device on the IDE pci_dev turns off mundane
things like the timer chips keyboard and mouse 8).
Other vendors do equally evil things and providing the chip reports IDE
class and has the IDE BARs set up nobody else is any the wiser and
presumably gate count goes down.
Alan
next prev parent reply other threads:[~2005-01-03 22:54 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200412310343.iBV3hqvd015595@hera.kernel.org>
2005-01-03 18:42 ` [ide] clean up error path in do_ide_setup_pci_device() Alan Cox
2005-01-03 22:22 ` Bartlomiej Zolnierkiewicz
2005-01-03 21:44 ` Alan Cox [this message]
2005-01-04 0:14 ` Francois Romieu
2005-01-04 22:02 ` Alan Cox
2005-01-07 2:20 ` 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=1104788671.13302.63.camel@localhost.localdomain \
--to=alan@lxorguk.ukuu.org.uk \
--cc=bzolnier@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.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