From: Jeff Garzik <jgarzik@mandrakesoft.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: "David S. Miller" <davem@redhat.com>, linux-kernel@vger.kernel.org
Subject: Re: pci_disable_device() vs. arch
Date: Sat, 16 Jun 2001 17:28:25 -0400 [thread overview]
Message-ID: <3B2BCF79.9BCC40E0@mandrakesoft.com> (raw)
In-Reply-To: <3B2BC57F.408A9B18@mandrakesoft.com> <20010616211449.2117@smtp.wanadoo.fr>
Benjamin Herrenschmidt wrote:
>
> >
> >Its not clutter -- what you are doing is hiding pieces of the driver
> >from the driver maintainer. pcibios_enable_device should not be
> >cluttered up with such mess, too.
>
> Well... pcibios_enable_device() has to at least make sure the device
> gets powered up as it's powered down after PCI probe. Except if we
> end up calling pci_set_power_state() to power it up early in the
> sungem driver.
huh? pci_enable_device calls pci_set_power_state. sungem calls
pci_enable_device.
pcibios_enable_device shouldn't have to worry about power stuff. If it
does, you need a pcibios_set_power_state, called from
pci_set_power_state, instead.
> >I point out that I recently fixed a bug where Via interrupts were being
> >assigned incorrectly. If I had not done a global grep for Via
> >irq-related code, I would have missed the spot where the PPC code was
> >doing a kludge for one of the four on-board Via devices, hardcoding the
> >USB irq number to 11.
>
> Hrm... interrupt routing on some PPC-based motherboard is quite a
> mess, fortunately that's not the case on pmacs. The IRQ assignement
> has to be part of the arch AFAIK, only the arch knows on which
> interrupt line of the controller a given chip is wired and how
> interrupt controllers are cascaded.
Via is an exception
> What I suggest if for pci_bus to have an optional set_power_state
> function that is called when a device on that bus calls
> pci_set_power_state(). This function would then be able to implement
> those cases where power control is possible, while not done
> via PCI PM caps.
> A pci_bus structure exist for both "root" busses and busses under
> PCI<->PCI bridges, so effectively, there's a pci_bus structure per
> bridge (beeing host or PCI<->PCI). I beleive it makes sense for
> the bridge to have a way to handle the child power state.
Ok, agreed. There are always gonna be special case bridges, including
(for my interest) multi-port NICs whose interfaces are presented as PCI
devices downstream from a PCI-PCI bridge. Controlling power for these
nics is sometimes done by messing around with the PM bits on the bridge,
not on the downstream devices.
Jeff
--
Jeff Garzik | Andre the Giant has a posse.
Building 1024 |
MandrakeSoft |
next prev parent reply other threads:[~2001-06-16 21:29 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200106162255.SAA02119@olimpo.networx.com.br.suse.lists.linux.kernel>
[not found] ` <E15B0vv-000780-00@the-village.bc.nu.suse.lists.linux.kernel>
[not found] ` <15146.33742.299279.102372@pizda.ninka.net.suse.lists.linux.kernel>
2001-06-16 5:57 ` Linux 2.4.5-ac14 Andi Kleen
2001-06-16 6:15 ` Alexander Viro
2001-06-16 7:37 ` Alexander Viro
2001-06-16 8:20 ` Marc ZYNGIER
2001-06-16 8:36 ` Alexander Viro
2001-06-17 20:47 ` Olaf Hering
2001-06-16 16:33 ` David S. Miller
2001-06-16 19:53 ` pci_disable_device() vs. arch Benjamin Herrenschmidt
2001-06-16 20:06 ` Jeff Garzik
2001-06-16 20:32 ` Benjamin Herrenschmidt
2001-06-16 20:45 ` Jeff Garzik
2001-06-16 21:14 ` Benjamin Herrenschmidt
2001-06-16 21:28 ` Jeff Garzik [this message]
2001-06-16 23:23 ` Benjamin Herrenschmidt
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=3B2BCF79.9BCC40E0@mandrakesoft.com \
--to=jgarzik@mandrakesoft.com \
--cc=benh@kernel.crashing.org \
--cc=davem@redhat.com \
--cc=linux-kernel@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).