Artem Bityutskiy | 1 Dec 2011 09:07
Picon

Re: [PATCH] Documentation: add sysfs entries for mtd docg3 chips

On Tue, 2011-11-29 at 23:16 +0100, Robert Jarzmik wrote:
> Add documentation for MSystems disk-on-chip docg3 chips
> sysfs entries, which enable and disable protection areas,
> giving or disabling access to the chip's memory.
> 
> Signed-off-by: Robert Jarzmik <robert.jarzmik <at> free.fr>

Pushed to l2-mtd-2.6.git, thanks!

Artem.

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Srivatsa S. Bhat | 4 Dec 2011 21:02
Picon

[PATCH 1/3] PM / Sleep: Make [un]lock_system_sleep() generic

The [un]lock_system_sleep() APIs were originally introduced to mutually
exclude memory hotplug and hibernation.

Directly using mutex_lock(&pm_mutex) to achieve mutual exclusion with
suspend or hibernation code can lead to freezing failures. However, the
APIs [un]lock_system_sleep() can be safely used to achieve the same, without
causing freezing failures.

So, since it would be beneficial to modify all the existing users of
mutex_lock(&pm_mutex) (in all parts of the kernel), so that they use these
safe APIs intead, make these APIs generic by removing the restriction that
they work only when CONFIG_HIBERNATE_CALLBACKS is set. Moreover, that
restriction didn't buy us anything anyway.

Suggested-by: Tejun Heo <tj <at> kernel.org>
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat <at> linux.vnet.ibm.com>
---

 include/linux/suspend.h |   42 ++++++++++++++++++------------------------
 1 files changed, 18 insertions(+), 24 deletions(-)

diff --git a/include/linux/suspend.h b/include/linux/suspend.h
index 1f7fff4..d109847 100644
--- a/include/linux/suspend.h
+++ b/include/linux/suspend.h
 <at>  <at>  -331,6 +331,8  <at>  <at>  static inline bool system_entering_hibernation(void) { return false; }
 #define PM_RESTORE_PREPARE	0x0005 /* Going to restore a saved image */
 #define PM_POST_RESTORE		0x0006 /* Restore failed */

+extern struct mutex pm_mutex;
(Continue reading)

Srivatsa S. Bhat | 4 Dec 2011 21:03
Picon

[PATCH 2/3] PM / Sleep: Replace mutex_[un]lock(&pm_mutex) with [un]lock_system_sleep()

Using [un]lock_system_sleep() is safer than directly using mutex_[un]lock()
on 'pm_mutex', since the latter could lead to freezing failures. Hence convert
all the present users of mutex_[un]lock(&pm_mutex) to use these safe APIs
instead.

Suggested-by: Tejun Heo <tj <at> kernel.org>
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat <at> linux.vnet.ibm.com>
---

 kernel/kexec.c           |    4 ++--
 kernel/power/hibernate.c |   16 ++++++++--------
 kernel/power/main.c      |    4 ++--
 kernel/power/suspend.c   |    4 ++--
 kernel/power/user.c      |   16 ++++++++--------
 5 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/kernel/kexec.c b/kernel/kexec.c
index dc7bc08..090ee10 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
 <at>  <at>  -1523,7 +1523,7  <at>  <at>  int kernel_kexec(void)

 #ifdef CONFIG_KEXEC_JUMP
 	if (kexec_image->preserve_context) {
-		mutex_lock(&pm_mutex);
+		lock_system_sleep();
 		pm_prepare_console();
 		error = freeze_processes();
 		if (error) {
 <at>  <at>  -1576,7 +1576,7  <at>  <at>  int kernel_kexec(void)
(Continue reading)

Rajendra Nayak | 5 Dec 2011 08:17
Picon
Favicon

[PATCH] Documentation: Fix regulator_register() API signature

The commit 2c043bcbf287 ("regulator: pass additional of_node to
regulator_register()") added an additional parameter to the
regulator_register() API.
Update the Documentation accordingly to reflect the change
in the function signature.

Reported-by: Thomas Abraham <thomas.abraham <at> linaro.org>
Signed-off-by: Rajendra Nayak <rnayak <at> ti.com>
---
 Documentation/power/regulator/regulator.txt |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/Documentation/power/regulator/regulator.txt b/Documentation/power/regulator/regulator.txt
index 3f8b528..e272d99 100644
--- a/Documentation/power/regulator/regulator.txt
+++ b/Documentation/power/regulator/regulator.txt
 <at>  <at>  -12,7 +12,7  <at>  <at>  Drivers can register a regulator by calling :-

 struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
 	struct device *dev, struct regulator_init_data *init_data,
-	void *driver_data);
+	void *driver_data, struct device_node *of_node);

 This will register the regulators capabilities and operations to the regulator
 core.
--

-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
(Continue reading)

Mark Brown | 5 Dec 2011 17:23
Favicon
Gravatar

Re: [PATCH] Documentation: Fix regulator_register() API signature

On Mon, Dec 05, 2011 at 12:47:42PM +0530, Rajendra Nayak wrote:
> The commit 2c043bcbf287 ("regulator: pass additional of_node to
> regulator_register()") added an additional parameter to the
> regulator_register() API.
> Update the Documentation accordingly to reflect the change
> in the function signature.

Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Tejun Heo | 5 Dec 2011 18:14

Re: [PATCH 1/3] PM / Sleep: Make [un]lock_system_sleep() generic

Hello,

On Mon, Dec 05, 2011 at 01:32:38AM +0530, Srivatsa S. Bhat wrote:
> +static inline void lock_system_sleep(void)
> +{
> +	/* simplified freezer_do_not_count() */
> +	current->flags |= PF_FREEZER_SKIP;
> +	mutex_lock(&pm_mutex);
> +}
> +
> +static inline void unlock_system_sleep(void)
> +{
> +	mutex_unlock(&pm_mutex);
> +	/* simplified freezer_count() */
> +	current->flags &= ~PF_FREEZER_SKIP;
> +}

BTW, don't we want try_to_freeze() there?  What's the reason for not
using freezer_count()?

Thanks.

--

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(Continue reading)

Tejun Heo | 5 Dec 2011 18:15

Re: [PATCH 3/3] PM / Docs: Recommend the use of [un]lock_system_sleep() over mutex_[un]lock(&pm_mutex)

Hello,

On Mon, Dec 05, 2011 at 01:33:42AM +0530, Srivatsa S. Bhat wrote:
> Update the documentation to explain the perils of directly using
> mutex_[un]lock(&pm_mutex) and recommend the usage of the safe
> APIs [un]lock_system_sleep() instead.

Maybe just make it pm internal?

--

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Tejun Heo | 5 Dec 2011 18:30

Re: [PATCH 1/3] PM / Sleep: Make [un]lock_system_sleep() generic

(cc'ing Oleg)

On Mon, Dec 05, 2011 at 10:55:51PM +0530, Srivatsa S. Bhat wrote:
> I wanted these APIs to be generic, not restricted to work only for userspace
> processes. Both freezer_do_not_count() and freezer_count() are effective only
> when current->mm is non-NULL (ie., only for userspace ones).
> I think I have documented this in the patch which added these things to the
> 2 APIs. See commit 6a76b7a in linux-pm/linux-next.

I see.  Oleg was curious about the ->mm condition too and IIRC there's
no reason for that restriction.  Maybe removing that in another patch
and using the count functions is better?

Thanks.

--

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Srivatsa S. Bhat | 5 Dec 2011 18:38
Picon

Re: [PATCH 3/3] PM / Docs: Recommend the use of [un]lock_system_sleep() over mutex_[un]lock(&pm_mutex)

On 12/05/2011 10:45 PM, Tejun Heo wrote:

> Hello,
> 
> On Mon, Dec 05, 2011 at 01:33:42AM +0530, Srivatsa S. Bhat wrote:
>> Update the documentation to explain the perils of directly using
>> mutex_[un]lock(&pm_mutex) and recommend the usage of the safe
>> APIs [un]lock_system_sleep() instead.
> 
> Maybe just make it pm internal?
> 

Sorry, I didn't get what you meant here. Are you talking about what
needs to be added/changed in the documentation or, are you referring
to the code itself and are saying that we must make these APIs
internal to the PM alone?

If it is the latter, please note that memory hotplug is one of the
outside-of-PM user of these APIs, and hence we really can't make
these APIs internal to the PM alone without substantially needing to
change the memory hotplug code to mutually exclude itself from PM
somehow without using these APIs.
And moreover, since these APIs avoid task freezing failures when
some out-of-PM user like memory hotplug code uses them, I don't see
much benefit by making them internal to the PM. IOW, I don't see
much use left of them, if we do that.

IMHO, we should leave these APIs as they are, until we have a better
solution for out-of-PM users to mutex themselves from PM. (For one,
currently it is not always possible to hook onto PM notifiers to
(Continue reading)

Srivatsa S. Bhat | 5 Dec 2011 18:41
Picon

Re: [PATCH 1/3] PM / Sleep: Make [un]lock_system_sleep() generic

On 12/05/2011 11:00 PM, Tejun Heo wrote:

> (cc'ing Oleg)
> 
> On Mon, Dec 05, 2011 at 10:55:51PM +0530, Srivatsa S. Bhat wrote:
>> I wanted these APIs to be generic, not restricted to work only for userspace
>> processes. Both freezer_do_not_count() and freezer_count() are effective only
>> when current->mm is non-NULL (ie., only for userspace ones).
>> I think I have documented this in the patch which added these things to the
>> 2 APIs. See commit 6a76b7a in linux-pm/linux-next.
> 
> I see.  Oleg was curious about the ->mm condition too and IIRC there's
> no reason for that restriction.  Maybe removing that in another patch
> and using the count functions is better?
> 

Oh well, then yes, that sounds like a better idea. Will send patches for
that. Thank you.

Regards,
Srivatsa S. Bhat

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Gmane