Messages in this thread | | | From | David Brownell <> | Subject | Re: [linux-usb-devel] Re: [PATCH] PCI: Add pci shutdown ability | Date | Mon, 25 Apr 2005 14:13:21 -0700 |
| |
> > So here's a patch for the PCI core that allows pci drivers to now just > > add a "shutdown" notifier function that will be called when the system > > is being shutdown. It happens just after the reboot notifier happens, > > and it should happen in the proper device tree order, so everyone should > > be happy.
Both kexec and sys_shutdown always call notifiers first, then the device shutdown stuff, as I understand. (I didn't see the patch, so I don't know what it should do...)
If there's going to be a "shutdown" primitive, I certainly think that it should work for PCI devices.
There's a separate issue about needing to clone such stuff into every version of bus glue. For example, OHCI runs on PCI ... but also on lots of non-PCI hardware. It's actually cleaner to use a notifier than to write almost-identical shutdown methods for each different bus it may be glued to. Same thing with EHCI; other bus-neutral register APIs will have the same issue.
> > Any objections to this patch? > > Yes. > > I believe it should just do suspend(PMSG_SUSPEND) before system > shutdown. If you think distintion between shutdown and suspend is > important (I am not 100% convinced it is), we can just add flag > saying "this is system shutdown".
I've made that point before -- essentially that shutdown() in the driver model itself is superfluous, either remove() or maybe suspend() would achieve the same result, without adding any special code that's run/tested rather infrequently ...
That is: if shutdown() isn't going to be removed, then the code that shuts down devices should invoke remove() or even suspend() in cases that there's no shutdown() method.
But the pushback was that shutdown() methods are allowed to be much lighter weight, and really ought to work even when big parts of the system are misbehaving. So they'd just do stuff like resetting chips, sanitizing GPIOs, and so on ... and nothing that'd be likely to break if significant parts of kernel memory were corrupted.
- Dave
- 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/
| |