From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Jeff Garzik <jgarzik@mandrakesoft.com>
Cc: "David S. Miller" <davem@redhat.com>, <linux-kernel@vger.kernel.org>
Subject: Re: pci_disable_device() vs. arch
Date: Sun, 17 Jun 2001 01:23:58 +0200 [thread overview]
Message-ID: <20010616232358.22354@smtp.wanadoo.fr> (raw)
In-Reply-To: <3B2BCF79.9BCC40E0@mandrakesoft.com>
In-Reply-To: <3B2BCF79.9BCC40E0@mandrakesoft.com>
>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.
Right, having a hook in pci_set_power_state() handles it all. Now,
there need to be some thinking about how to actually implement it
(when to call pcibios_set_power_state inside pci_set_power_state
and what result should it returns).
I see several options:
- Use it when the device has no PM capabilities
- Call it first, and depending on the result code, do the normal
PM or not, or eventually just fail.
- Call it last/first depending if entering a low power state or
exiting.
In my case, the device don't have PM caps, so I don't really care,
and it's the same for the other devices I have in mind that would
need it.
I still like the idea of implementing this as a function pointer
inside the pci_bus. In fact, the current implementation could be
done by filling this pointer with a default value, thus allowing
the arch to do any variation it may like by overriding this
pointer.
I keep having embedded in mind, where we have all sort of weird
designs (usually to save a few wires on a PLD) and flexibility is
fine when it doesn't add bloat. In this case, I beleive having
this notion of "pci_bus ops" for PM makes sense and is not bloat.
>Via is an exception
Yes, unless it's cascaded on a master interrupt controller. But
I agree the hard coding wasn't good, PPC is just so many different
boxes, they don't all have a nice device-tree or useable BIOS
residual datas :(
>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.
Ah, nice you see you agree ;)
Ben.
prev parent reply other threads:[~2001-06-16 23:24 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
2001-06-16 23:23 ` Benjamin Herrenschmidt [this message]
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=20010616232358.22354@smtp.wanadoo.fr \
--to=benh@kernel.crashing.org \
--cc=davem@redhat.com \
--cc=jgarzik@mandrakesoft.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).