Re: [linux-usb-devel] Re: [PATCH] PCI: Add pci shutdown ability

[David Brownell <david-b@pacbell.net>]

> > 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/