Re: [RFC][PATCH 1/3] PM: Introduce new top level suspend and hibernation callbacks

On Thu, 20 Mar 2008, Benjamin Herrenschmidt wrote:

An important point I tried to make in the earlier email is that drivers
will want a simple way to know when it is illegal for them to register
new children. For example, suppose the registration is done by a
workqueue routine. The most reliable way for the driver to insure that
the routine won't try to register new children improperly is to have
the routine check a flag which gets set _before_ prepare() is called.

I don't totally agree here. Drivers could have their own flag set
internally with appropriate locking. The problem with your approach is
locking. Just setting a flag is mostly useless, -unless- there
appropriate locking between setter and testers.

Here's an example of what I mean.

One of the things we don't want to do is bind a new driver to a device
after it has gone through the prepare() stage. Doing so would involve
calling the driver's probe() routine, which is likely to want to
register new children and who knows what else. The probe routine might
even end up running after the device was suspended! Clearly this
should be avoided.

But the user can force a binding to occur by writing the device's path
to the driver's "bind" attribute in sysfs. This means that
driver_bind() in drivers/base/bus.c will need to know whether or not
the device has gone through the prepare() stage, which means the device
structure will need to have a flag set before prepare() is called (more
precisely, the flag must be set before dev->sem is released following
the call to prepare).

Either that or else driver_bind() must always block whenever a system
sleep is in progress. That would be easier -- but it's a lot like what
the freezer would do. Which would you prefer?

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: VxWorks 6.6 - Ethernet interface driver support
    ... “geiMuxConnect” routine function call). ... The effect of the writing to the registers RXCW and STATUS is outlined ... Register content directly before the write done in the ... It should be cleared for port 0 and set for port 1. ...
    (comp.os.vxworks)
  • Re: MOVZX has stall register
    ... > MOV EAX, 0FEH ... Matt Taylor tells the same thing to use 32 Bits instructions rather ... CH, and DH register. ... I don't need it if I use Sign Flag, Zero Flag, and Carry Flag. ...
    (comp.lang.asm.x86)
  • Re: registers
    ... eax, ebx, ecx, edx, esi, & edi are general-purpose ... The eflags register does a lot of things, but the flags of primary concern ... Zero flag ... I would highly recommend looking at the Intel reference manuals: ...
    (comp.lang.asm.x86)
  • Re: gcc return reg on inline asm
    ... xor sets the z flag which I'm trying to store in the next instruction. ... it has to clear %%eax first. ... save that reg with a push and pop off the stack. ... must be a register allocator bug. ...
    (comp.lang.asm.x86)
  • Re: using MISC (post 1987 Forth hardware) opcodes
    ... We found that having a stack of registers with flag bits was much more ... for more conventional things like a conventional flag register design. ... Once you add -IF then non-destructive branching is much ...
    (comp.lang.forth)
Loading