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 16:06:20 -0400 [thread overview]
Message-ID: <3B2BBC3C.BEC4B313@mandrakesoft.com> (raw)
In-Reply-To: <15147.35421.866268.67790@pizda.ninka.net> <20010616195331.26754@smtp.wanadoo.fr>
Benjamin Herrenschmidt wrote:
>
> Hi !
>
> Would it make sense to add a
>
> pcibios_disable_device(pci_dev*) called from the end of
> pci_disable_device() ?
>
> I'm adding a call to it to sungem along with other pmac stuffs
> so that the chip can be properly power down (actually it's not
> really powered down but unclocked) after module removal.
> Of course, the arch code must be able to catch it in order to
> play with the various UniNorth control bits.
What arch-specific things need to be done?
arch-specific pcibios_disable_device may be a good idea... but in this
case it sounds like you need to put #ifdef CONFIG_ALL_PPC code in
sungem.c instead, if the power-down code is specific to gmacs.
> Note that my current gmac driver does shut the chip down when
> the interface is down, which makes it a bit more useful for
> laptops as most users currently compile the driver in the kernel.
Although some drivers already do this, you really need an inactivity
timer instead of unconditionally powering-down the hardware on
dev->stop(). dhcp and other applications will often bounce the
interface...
> I have nothing about changing the policy if you prefer so that
> users will now have to rmmod the driver once done with the
> interface to save power.
For power-down specifically, you should use pci-set-power-state not
pci-disable-device. pci_disable_device is the opposite of
pci_enable_device. pci_enable_device not only wakes up the device, but
also assigns resources. Which implies that pci-disable-device is
allowed to un-assign resources. There shouldn't be a problem with a net
device doing that per se, but you should be aware of the implications.
Jeff
--
Jeff Garzik | Andre the Giant has a posse.
Building 1024 |
MandrakeSoft |
next prev parent reply other threads:[~2001-06-16 20:07 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 [this message]
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
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=3B2BBC3C.BEC4B313@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