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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.