[lkml]   [2003]   [Aug]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] call drv->shutdown at rmmod
    Russell King <> writes:

    > On Thu, Aug 14, 2003 at 08:54:43AM +0100, Christoph Hellwig wrote:
    > > Sounds really confusing. And having shutdown maybe called before remove
    > > but not always sounds like a design mistake.

    My patch always called shutdown before remove, but only if the methods
    are implemented. Mandating that shutdown and remove are implemented
    is not something I am changing with this patch.

    > > Why do we have shutdown at all? Can't we just call ->remove on shutdown
    > > so the device always get's into proper unitialized state on shutdown, too?
    > That's likely to remove the keyboard driver, and some people like
    > to configure their box so that ctrl-alt-del halts the system, and
    > a further ctrl-alt-del reboots the system once halted.

    Hmm. That is a very weird case. Semantically the keyboard driver
    and everything else should be removed in any case.

    After device_shutdown is called it is improper for any driver
    to be handling interrupts because the are supposed to be in a quiescent
    state. And if they are not it is likely to break a soft reboot.

    > There are also some bus drivers which want to know the difference
    > between "device (driver) was removed" and "device was shutdown",
    > eg, for setting bus-specific stuff back into a state where the
    > machine can be soft-rebooted.
    > With the shutdown callback, drivers get the option whether to
    > handle this event or not. Combining it with remove gives them no
    > option what so ever, and bus drivers loose this knowledge.

    Reasonable. And they still get that knowledge with the way I implemented
    my patch. They just get to shutdown first.

    Russell do you have any objects to always calling shutdown before
    remove? I don't think this looses knowledge and in most cases it should
    work, but if there are bus devices were we need to do things significantly
    differently I am open to other solutions.

    All I really care about is that we get something that is simple enough
    that device driver authors can get it right. And according to my limited
    testing we don't have that right now.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:47    [W:0.021 / U:32.032 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site