Messages in this thread | | | Subject | Re: Patch: linux-2.5.42/kernel/sys.c - warm reboot should not suspend devices | From | (Eric W. Biederman) | Date | 13 Oct 2002 18:07:15 -0600 |
| |
"Adam J. Richter" <adam@yggdrasil.com> writes:
> Russell King wrote: > >On Sun, Oct 13, 2002 at 04:10:01PM -0700, Adam J. Richter wrote: > >> I have no objection to replacing or supplementing the reboot > >> notifier chain with a method in struct device_driver, but let's not > >> overload these methods with ambiguous semantics. I do not want to > >> call thirty functions that primarily return memory to various memory > >> allocators, mark a bunch of inodes as invalid, and otherwise arrange > >> things so that the kernel can smoothly continue to run user level > >> programs when, in fact, we just want to pull the reset line on the > >> computer. > > > >And what about setups where you can't pull the reset line from software. > >I have several machines here like that. And one of them needs software > >to talk to the cards to put them back into a sane state before rebooting. > > > >"rebooting" in this particular case is "turn MMU off, jump to location 0" > > As I send in my response Eric Biederman, > > | If you have a platform where, for example, somehow PCI devices > | are able to continue jabbering away after the computer has been reset, > | then that could probably be done more consistently for most drivers by > | having machine_restart on that platform walk the PCI bus and shut down > | everything (drivers that need to do something really special would > | still use the reboot notifier). > | > | I could even see calling device_shutdown from machine_restart > | on that platform only, [...] > > > >And I never said anything about needing to allocate memory to do this. > >I agree with you that suspending devices on reboot _is_ silly. However, > >that's not what I was proposing. > > Then you've started a new thread of discussion, because > device_shutdown is defined in drivers/base/power.c as: > > void device_shutdown(void) > { > device_suspend(4, SUSPEND_POWER_DOWN); > } > > > Perhaps device_suspend ought to be renamed device_power_down. > > However, I'm not trying to quash what you want to discuss. > I'd be interested in hearing about clarifications and perhaps > extensions of the struct device_driver methods, which I think is what > you're getting at, perhaps here or on linux-hotplug. It's just that, > for this thread, I'm trying to focus on my patch that eliminates the > software suspend on reboot (pros and cons, alternatives to it, etc.).
The 2.5.41 variant is below. The bug is reusing the old enumeration value as was previously mentioned.
/** * device_shutdown - queisce all the devices before reboot/shutdown * * Do depth first iteration over device tree, calling ->remove() for each * device. This should ensure the devices are put into a sane state before * we reboot the system. * * device_shutdown - call device_suspend with status set to shutdown, to * cause all devices to remove themselves cleanly */ void device_shutdown(void) { struct list_head * node, * next; struct device * prev = NULL;
printk(KERN_EMERG "Shutting down devices\n");
spin_lock(&device_lock); list_for_each_safe(node,next,&global_device_list) { struct device * dev = get_device_locked(to_dev(node)); if (dev) { spin_unlock(&device_lock); if (dev->driver && dev->driver->remove) dev->driver->remove(dev); if (prev) put_device(prev); prev = dev; spin_lock(&device_lock); } } spin_unlock(&device_lock); if (prev) put_device(prev); }
Eric k - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |