On Tuesday, 25 of March 2008, Oliver Neukum wrote:
> Am Montag 24 März 2008 schrieb Rafael J. Wysocki:
> > -/*
> > +/**
> > + * struct pm_ops - device PM callbacks
> > + *
> > * Several driver power state transitions are externally visible, affecting
> > * the state of pending I/O queues and (for drivers that touch hardware)
> > * interrupts, wakeups, DMA, and other hardware state. There may also be
> > @@ -122,6 +124,254 @@ typedef struct pm_message {
> > * to the rest of the driver stack (such as a driver that's ON gating off
> > * clocks which are not in active use).
> > *
> > + * The externally visible transitions are handled with the help of the following
> > + * callbacks included in this structure:
> > + *
> > + * @prepare: Prepare the device for the upcoming transition, but do NOT change
> > + * its hardware state. Prevent new children of the device from being
> > + * registered and prevent new calls to the probe method from being made
>
> How is a driver supposed to prevent calls to probe()? You can block in probe()
> or you can fail it, but how do you prevent it from being called? User space
> can trigger probe via sysfs.
I overlooked that.
> To be useful to driver writers, this has to be clarified.
The comment is supposed to mean that probe() should be prevented from running
(i.e. even if it's executed, it should either fail or block). I'll write it this way.
> > + * after @prepare() returns. If @prepare() detects a situation it cannot
> > + * handle (e.g. registration of a child already in progress), it may return
> > + * -EAGAIN, so that the PM core can execute it once again (e.g. after the
> > + * new child has been registered) to recover from the race condition. This
> > + * method is executed for all kinds of suspend transitions and is followed
> > + * by one of the suspend callbacks: @suspend(), @freeze(), or @poweroff().
>
> This could be understood so that disconnect() cannot be called.
At what time exactly?
> > + * The PM core executes @prepare() for all devices before starting to
> > + * execute suspend callbacks for any of them, so drivers may assume all of
> > + * the other devices to be present and functional while @prepare() is being
> > + * executed. However, they may NOT assume anything about the availability
> > + * of the user space at that time.
>
> Probably it should be mentioned that this is the time to allocate memory
> if you have to.
Well, not exactly. Afterwards you cannot use GFP_KERNEL allocations, but
GFP_NOIO should still work, although for hibernation it's quite possible that
they'll fail if substantial amounts of memory are requested.
> And it is too late to request firmware.
Yes.
Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
