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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200803251255.31482.oliver@neukum.org>
Date:	Tue, 25 Mar 2008 12:55:30 +0100
From:	Oliver Neukum <oliver@...kum.org>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	Alan Stern <stern@...land.harvard.edu>,
	pm list <linux-pm@...ts.linux-foundation.org>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	Greg KH <greg@...ah.com>, Len Brown <lenb@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Alexey Starikovskiy <astarikovskiy@...e.de>,
	David Brownell <david-b@...bell.net>,
	Pavel Machek <pavel@....cz>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Subject: Re: [RFC][PATCH] PM: Introduce new top level suspend and hibernation callbacks (rev. 3)

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/