* Re: Linux 2.4.5-ac14 [not found] ` <15146.33742.299279.102372@pizda.ninka.net.suse.lists.linux.kernel> @ 2001-06-16 5:57 ` Andi Kleen 2001-06-16 6:15 ` Alexander Viro 2001-06-16 7:37 ` Alexander Viro 2001-06-16 16:33 ` David S. Miller 1 sibling, 2 replies; 14+ messages in thread From: Andi Kleen @ 2001-06-16 5:57 UTC (permalink / raw) To: David S. Miller; +Cc: linux-kernel "David S. Miller" <davem@redhat.com> writes: > Alan Cox writes: > > Because right now I dont consider the 2.4.6 page cache ext2 stuff safe > > enough to merge. I'm letting someone else be the sucide squad.. so far it > > looks like it is indeed fine but I want to wait and see more yet > > If it means anything it has already withstanded a few > cerebus-->fsck_check-->cerebus rounds on machines here > in my lab. ... it also seems to make ppc not boot anymore. -Andi ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Linux 2.4.5-ac14 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 1 sibling, 0 replies; 14+ messages in thread From: Alexander Viro @ 2001-06-16 6:15 UTC (permalink / raw) To: Andi Kleen; +Cc: David S. Miller, linux-kernel On 16 Jun 2001, Andi Kleen wrote: > "David S. Miller" <davem@redhat.com> writes: > > > Alan Cox writes: > > > Because right now I dont consider the 2.4.6 page cache ext2 stuff safe > > > enough to merge. I'm letting someone else be the sucide squad.. so far it > > > looks like it is indeed fine but I want to wait and see more yet > > > > If it means anything it has already withstanded a few > > cerebus-->fsck_check-->cerebus rounds on machines here > > in my lab. > > ... it also seems to make ppc not boot anymore. Huh? By the time when ext2 directories come into the game you are _very_ far into the boot sequence. At which stage does it fail? Does it fail with root on minixfs/reiserfs/etc.? ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Linux 2.4.5-ac14 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-17 20:47 ` Olaf Hering 1 sibling, 2 replies; 14+ messages in thread From: Alexander Viro @ 2001-06-16 7:37 UTC (permalink / raw) To: Alan Cox; +Cc: Andi Kleen, David S. Miller, linux-kernel On 16 Jun 2001, Andi Kleen wrote: > "David S. Miller" <davem@redhat.com> writes: > > > Alan Cox writes: > > > Because right now I dont consider the 2.4.6 page cache ext2 stuff safe > > > enough to merge. I'm letting someone else be the sucide squad.. so far it > > > looks like it is indeed fine but I want to wait and see more yet > > > > If it means anything it has already withstanded a few > > cerebus-->fsck_check-->cerebus rounds on machines here > > in my lab. > > ... it also seems to make ppc not boot anymore. OK, after looking at the bug report things smell very strange: * kernel had barfed on lookup for /dev/console. * kernel had found /dev - right inode number, etc. * read_cache_page(inode->i_mapping, n, ext2_readpage) on it gave all-zeroes for each page within first 32Kb (size of /dev on box in question). * filesystem is not corrupted. * all that stuff had happened with cold caches. * kernel was 2.4.6-pre3 + some unspecified modifications. Very odd. Could somebody try vanilla 2.4.6-pre1 on a PPC box? I _really_ doubt that it might be an architecture-specific problem in directory code - it would simply fail the lookup for /dev in that case. I'll try to find a PPC nearby, but it may be tricky on weekend. So if somebody wants to help... Notice that problem was on read-only mount, so it can be tested without risking fs corruption - just try to boot with init=/bin/sh and do ls -lR, etc. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Linux 2.4.5-ac14 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 1 sibling, 1 reply; 14+ messages in thread From: Marc ZYNGIER @ 2001-06-16 8:20 UTC (permalink / raw) To: Alexander Viro; +Cc: Alan Cox, Andi Kleen, David S. Miller, linux-kernel >>>>> "Al" == Alexander Viro <viro@math.psu.edu> writes: Al> Very odd. Could somebody try vanilla 2.4.6-pre1 on a PPC box? I _really_ Al> doubt that it might be an architecture-specific problem in directory Al> code - it would simply fail the lookup for /dev in that case. I have 2.4.6-pre3 running. Machine is a PowerMac clone with a G3 CPU. It gets loads of bogus interrupts (known problem with this machine), but otherwise runs fine (that is, for the time being). maz@crisis:~$ uname -a Linux crisis 2.4.6-pre3 #1 Sat Jun 16 01:35:36 CEST 2001 ppc unknown maz@crisis:~$ cat /proc/cpuinfo processor : 0 cpu : 750 temperature : 0 C clock : 240MHz revision : 2.2 bogomips : 478.91 zero pages : total: 0 (0Kb) current: 0 (0Kb) hits: 0/0 (0%) machine : Power Macintosh motherboard : AAPL,e407 MacRISC memory : 144MB l2cr override : 0xa5000000 pmac-generation : OldWorld Al> I'll try to find a PPC nearby, but it may be tricky on weekend. So Al> if somebody wants to help... Notice that problem was on read-only Al> mount, so it can be tested without risking fs corruption - just Al> try to boot with init=/bin/sh and do ls -lR, etc. Been there, done that. Just works. Would 2.4.6-pre1 be a better test ? I can dig into that if you want. M. -- Places change, faces change. Life is so very strange. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Linux 2.4.5-ac14 2001-06-16 8:20 ` Marc ZYNGIER @ 2001-06-16 8:36 ` Alexander Viro 0 siblings, 0 replies; 14+ messages in thread From: Alexander Viro @ 2001-06-16 8:36 UTC (permalink / raw) To: Marc ZYNGIER; +Cc: Alan Cox, Andi Kleen, David S. Miller, linux-kernel On 16 Jun 2001, Marc ZYNGIER wrote: > >>>>> "Al" == Alexander Viro <viro@math.psu.edu> writes: > > Al> Very odd. Could somebody try vanilla 2.4.6-pre1 on a PPC box? I _really_ > Al> doubt that it might be an architecture-specific problem in directory > Al> code - it would simply fail the lookup for /dev in that case. > > I have 2.4.6-pre3 running. Machine is a PowerMac clone with a G3 CPU. > It gets loads of bogus interrupts (known problem with this machine), > but otherwise runs fine (that is, for the time being). [snip] > Been there, done that. Just works. > Would 2.4.6-pre1 be a better test ? I can dig into that if you want. Nah - just that 2.4.6-pre1 was the version where ext2 patch went in. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Linux 2.4.5-ac14 2001-06-16 7:37 ` Alexander Viro 2001-06-16 8:20 ` Marc ZYNGIER @ 2001-06-17 20:47 ` Olaf Hering 1 sibling, 0 replies; 14+ messages in thread From: Olaf Hering @ 2001-06-17 20:47 UTC (permalink / raw) To: Alexander Viro; +Cc: Alan Cox, Andi Kleen, David S. Miller, linux-kernel On Sat, Jun 16, Alexander Viro wrote: > > > On 16 Jun 2001, Andi Kleen wrote: > > > "David S. Miller" <davem@redhat.com> writes: > > > > > Alan Cox writes: > > > > Because right now I dont consider the 2.4.6 page cache ext2 stuff safe > > > > enough to merge. I'm letting someone else be the sucide squad.. so far it > > > > looks like it is indeed fine but I want to wait and see more yet > > > > > > If it means anything it has already withstanded a few > > > cerebus-->fsck_check-->cerebus rounds on machines here > > > in my lab. > > > > ... it also seems to make ppc not boot anymore. > > OK, after looking at the bug report things smell very strange: > > * kernel had barfed on lookup for /dev/console. > * kernel had found /dev - right inode number, etc. > * read_cache_page(inode->i_mapping, n, ext2_readpage) on it > gave all-zeroes for each page within first 32Kb (size of /dev on box in > question). > * filesystem is not corrupted. > * all that stuff had happened with cold caches. > * kernel was 2.4.6-pre3 + some unspecified modifications. > > Very odd. Could somebody try vanilla 2.4.6-pre1 on a PPC box? I _really_ > doubt that it might be an architecture-specific problem in directory > code - it would simply fail the lookup for /dev in that case. > > I'll try to find a PPC nearby, but it may be tricky on weekend. So if > somebody wants to help... Notice that problem was on read-only mount, > so it can be tested without risking fs corruption - just try to boot > with init=/bin/sh and do ls -lR, etc. Al, the pre2 didnt boot on the POWER3 SMP box. pre3 does (runs in 32bit mode). It could be a compiler bug because we have some trouble right now with our toolchain on ppc32. Right now it runs pre3 fine with a binary from the same compiler etc. I have seen this only on that box. Is it possible that a ppc64 writes some bogus values to the disk? I had a ppc64 binary running but I wasnt too excited about it because it misses some essential stuff like autofs. So I booted the 2.4.2 ppc32 kernel again with no trouble for a while.. Gruss Olaf -- $ man clone BUGS Main feature not yet implemented... ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Linux 2.4.5-ac14 [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 16:33 ` David S. Miller 2001-06-16 19:53 ` pci_disable_device() vs. arch Benjamin Herrenschmidt 1 sibling, 1 reply; 14+ messages in thread From: David S. Miller @ 2001-06-16 16:33 UTC (permalink / raw) To: Andi Kleen; +Cc: linux-kernel Andi Kleen writes: > ... it also seems to make ppc not boot anymore. Which is odd since all my machines are big-endian too. It might smell of a compiler bug... Later, David S. Miller davem@redhat.com ^ permalink raw reply [flat|nested] 14+ messages in thread
* pci_disable_device() vs. arch 2001-06-16 16:33 ` David S. Miller @ 2001-06-16 19:53 ` Benjamin Herrenschmidt 2001-06-16 20:06 ` Jeff Garzik 0 siblings, 1 reply; 14+ messages in thread From: Benjamin Herrenschmidt @ 2001-06-16 19:53 UTC (permalink / raw) To: David S. Miller; +Cc: linux-kernel 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. 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. 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. Ben. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: pci_disable_device() vs. arch 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 0 siblings, 1 reply; 14+ messages in thread From: Jeff Garzik @ 2001-06-16 20:06 UTC (permalink / raw) To: Benjamin Herrenschmidt; +Cc: David S. Miller, linux-kernel 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 | ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: pci_disable_device() vs. arch 2001-06-16 20:06 ` Jeff Garzik @ 2001-06-16 20:32 ` Benjamin Herrenschmidt 2001-06-16 20:45 ` Jeff Garzik 0 siblings, 1 reply; 14+ messages in thread From: Benjamin Herrenschmidt @ 2001-06-16 20:32 UTC (permalink / raw) To: Jeff Garzik; +Cc: David S. Miller, linux-kernel >What arch-specific things need to be done? I can control the gmac cell's clock. Actually, I can do the same with the firewire clock (the firewire cell is in the same ASIC) and with the firewire cable power. >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. Well... I did that in gmac.c. With the arrival of sungem, I had in mind to avoid clobbering sungem with such things, and since we already have arch hook for pci_enable_device(), which I use to turn ON the chip, I though about doing the same with pci_disable_device(). (Note that I do turn it ON temporarily during PCI probe so that the pci_dev entry exist in the kernel). It's mostly a mater of taste, I prefered avoiding calling arch specific routines if possible in a "generic" driver. Note that I will probably have to do some anyway as I need some arch calls to control the PHY reset as well. >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... In that case, it's not a power down, it's just a clock control. Which appear to be reather safe to toggle quickly. >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. I'm aware of this. Actually, pci_disable_device() doesn't de-assign any resource, but well... I guess there should be nothing wrong about resources beeing un-assigned and/or re-assigned when the driver is rmmod'ed or insmod'ed back. I agree pci_set_power_state() would be a better choice, but it would require some arch hooks as well since this is done done via normal PCI power management. Since I'll have to implement the suspend() and resume() callbacks as well, maybe we can agree on an arch hook for pci_set_power_state(). Actually, I beleive instead of an arch callback, I'd rather see a function pointer in the pci_bus structure of the parent bridge. Our arch would then put the proper code for it in the pci_bus associated with that side of UniNorth. (UniNorth has 3 host bridges). That said, a pcibios_disable_device() hook would be logical, since there's already one in pcibios_enable_device(). Ben. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: pci_disable_device() vs. arch 2001-06-16 20:32 ` Benjamin Herrenschmidt @ 2001-06-16 20:45 ` Jeff Garzik 2001-06-16 21:14 ` Benjamin Herrenschmidt 0 siblings, 1 reply; 14+ messages in thread From: Jeff Garzik @ 2001-06-16 20:45 UTC (permalink / raw) To: Benjamin Herrenschmidt; +Cc: David S. Miller, linux-kernel Benjamin Herrenschmidt wrote: > > >What arch-specific things need to be done? > > I can control the gmac cell's clock. Actually, I can do the same > with the firewire clock (the firewire cell is in the same ASIC) > and with the firewire cable power. > > >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. > > Well... I did that in gmac.c. With the arrival of sungem, I had in > mind to avoid clobbering sungem with such things, and since we > already have arch hook for pci_enable_device(), which I use to turn > ON the chip, I though about doing the same with pci_disable_device(). > > (Note that I do turn it ON temporarily during PCI probe so that > the pci_dev entry exist in the kernel). > > It's mostly a mater of taste, I prefered avoiding calling arch > specific routines if possible in a "generic" driver. Note that I > will probably have to do some anyway as I need some arch calls > to control the PHY reset as well. 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. 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. > >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... > > In that case, it's not a power down, it's just a clock control. > Which appear to be reather safe to toggle quickly. > > >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. > > I'm aware of this. Actually, pci_disable_device() doesn't de-assign > any resource, but well... I guess there should be nothing wrong about > resources beeing un-assigned and/or re-assigned when the driver is > rmmod'ed or insmod'ed back. Correct. If your driver uses the API correctly, then when/if we want to mess around with hotplug resource assignment, we can un-assign resources as we like. Since there aren't too many users of pci_disable_device so far, I want to make sure early adopters get it right. > I agree pci_set_power_state() would be a better choice, but it would > require some arch hooks as well since this is done done via normal PCI > power management. > > Since I'll have to implement the suspend() and resume() callbacks > as well, maybe we can agree on an arch hook for pci_set_power_state(). > Actually, I beleive instead of an arch callback, I'd rather see a > function pointer in the pci_bus structure of the parent bridge. Our > arch would then put the proper code for it in the pci_bus associated > with that side of UniNorth. (UniNorth has 3 host bridges). > > That said, a pcibios_disable_device() hook would be logical, since > there's already one in pcibios_enable_device(). Can you give a -specific- example of arch code that is -not- sungem related, but needs to occur when one powers-down a sungem MAC? If the PM code is related to sungem, it belongs in sungem. So far I don't see a need for arch-specific hooks anywhere... Jeff -- Jeff Garzik | Andre the Giant has a posse. Building 1024 | MandrakeSoft | ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: pci_disable_device() vs. arch 2001-06-16 20:45 ` Jeff Garzik @ 2001-06-16 21:14 ` Benjamin Herrenschmidt 2001-06-16 21:28 ` Jeff Garzik 0 siblings, 1 reply; 14+ messages in thread From: Benjamin Herrenschmidt @ 2001-06-16 21:14 UTC (permalink / raw) To: Jeff Garzik; +Cc: David S. Miller, linux-kernel > >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. >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. >Correct. If your driver uses the API correctly, then when/if we want to >mess around with hotplug resource assignment, we can un-assign resources >as we like. Since there aren't too many users of pci_disable_device so >far, I want to make sure early adopters get it right. Well... at least with sungem, there's no such risk as the entire bus (up to the host bridge) where it lives is internal to the UniNorth ASIC. >Can you give a -specific- example of arch code that is -not- sungem >related, but needs to occur when one powers-down a sungem MAC? > >If the PM code is related to sungem, it belongs in sungem. >So far I don't see a need for arch-specific hooks anywhere... Hrm... let me try again... Powering down individual devices can be controlled by the PCI PM capabilities, or in some cases (at least 2 cases here on UniNorth based pmacs) by other bits in the host bridge. 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. Ben ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: pci_disable_device() vs. arch 2001-06-16 21:14 ` Benjamin Herrenschmidt @ 2001-06-16 21:28 ` Jeff Garzik 2001-06-16 23:23 ` Benjamin Herrenschmidt 0 siblings, 1 reply; 14+ messages in thread From: Jeff Garzik @ 2001-06-16 21:28 UTC (permalink / raw) To: Benjamin Herrenschmidt; +Cc: David S. Miller, linux-kernel 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 | ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: pci_disable_device() vs. arch 2001-06-16 21:28 ` Jeff Garzik @ 2001-06-16 23:23 ` Benjamin Herrenschmidt 0 siblings, 0 replies; 14+ messages in thread From: Benjamin Herrenschmidt @ 2001-06-16 23:23 UTC (permalink / raw) To: Jeff Garzik; +Cc: David S. Miller, linux-kernel >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. ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2001-06-17 20:47 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [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 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).