Re: [RFC][PATCH] PM: Introduce new top level suspend and hibernation callbacks (rev. 3)

[Oliver Neukum]

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. To be useful to driver writers, this has
to be clarified.

> + *     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.

> + *     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. And it is too late to request firmware.

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