Re: [PATCH 20/22] pstore: %pF is only for function pointers

2015-06-16 Thread Anton Vorontsov
On Tue, Jun 16, 2015 at 03:02:50PM -0700, Kees Cook wrote:
> On Wed, Mar 11, 2015 at 8:13 PM, Scott Wood  wrote:
> > Use %pS for actual addresses, otherwise you'll get bad output
> > on arches like ppc64 where %pF expects a function descriptor.
> >
> > Signed-off-by: Scott Wood 
...
> > -   seq_printf(s, "%d %08lx  %08lx  %pf <- %pF\n",
> > +   seq_printf(s, "%d %08lx  %08lx  %ps <- %pS\n",
...
> Anton, does this look okay to you? (i.e. switching from function
> pointer to direct pointer?) vsprintf docs say:
>  * Note: The difference between 'S' and 'F' is that on ia64 and ppc64
>  * function pointers are really function descriptors, which contain a
>  * pointer to the real address.
> 
> So this seems correct to me.
> 
> Reviewed-by: Kees Cook 

Without questioning the confusing behaviour of "%pF", yes, sure... ack. :)

(However, intuitively I'd expect %pF to behave like %pS... but this surely not
going to change...)

Thanks!

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


CNS3xxx maintainer (was Re: master build: 0 failures 28 warnings (v3.17-rc4-158-ge874a5f))

2014-09-10 Thread Anton Vorontsov
On Wed, Sep 10, 2014 at 10:01:43AM +0200, Arnd Bergmann wrote:
[...]
> > ---
> > arm-allmodconfig : PASS, 0 errors, 18 warnings, 0 section mismatches
> > 
> > Warnings:
> > ../arch/arm/mach-cns3xxx/pcie.c:311:1: warning: the frame size of 1072 
> > bytes is larger than 1024 bytes [-Wframe-larger-than=]
> 
> I guess we should try to find a new cns3xxx maintainer

I'd be more than happy to hand it over. As far as I know, OpenWRT is a
major user of cns3xxx nowadays, so Cc'ing some of the active folks.

> Anton no longer has access to the hardware as far as I know,

Yup.

> and the patch I made for this needs to be tested.

Fwiw, it looked really good.

Thanks!

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


Re: [RESEND PATCH v3 2/5] charger: tps65090: Allow charger module to be used when no irq

2014-05-05 Thread Anton Vorontsov
On Mon, May 05, 2014 at 09:51:28AM -0700, Olof Johansson wrote:
> > All the rest of this series has been acked and applied.  Do you have
> > time to review this patch?
> >
> > Thanks!  :)
> 
> FWIW, I've seen very little email traffic from Anton this year, he
> might have limited time for maintainership at the moment.

Yup.

commit 573189354b7c97cd2256b87cf083ee435584594e
Author: Dmitry Eremin-Solenikov 
Date:   Tue Jan 21 03:33:09 2014 +0400

MAINTAINERS: Pick up power supply maintainership

Anton stated that he would have to abandon power supply maintainership
due to the lack of time. By agreement with him and David, pick up power
supply tree.

Signed-off-by: Dmitry Eremin-Solenikov 
Acked-by: Anton Vorontsov 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v3 4/6] timerfd: Factor out timer-type unspecific timerfd_expire()

2014-02-20 Thread Anton Vorontsov
On Thu, Feb 20, 2014 at 11:52:03AM +0100, Thomas Gleixner wrote:
> > From: Anton Vorontsov 
> > 
> > There is nothing hrtimer-specific inside the timerfd_tmrproc(), except
> > the function prototype. We're about to add other timer types, so factor
> > out generic timerfd_expire() helper from timerfd_tmrproc().
> 
> This changelog is completely useless. How is timerfd_tmrproc, which is
> not a function but a function pointer, related to the patch?
> 
> Moving duplicated code to a common function is nice, but 

> > Signed-off-by: Anton Vorontsov 
> > Signed-off-by: Alexey Perevalov 
... 
> Warnings are there to be ignored and testing of user space
> interfaces after a change is overrated, right?
> 
> Aside of that you just blindly copied the original code w/o fixing up
> the now unnecessary line breaks.

Alexey,

While I appreciate the desire to be careful with authorship and stuff,
please remove my name as an author of this patch -- the current code has
nothing to do with my original work, and I surely don't want to take any
responsibility for it. This is a common practice if you modify someone's
patch to a great extend.

Thomas is bashing the thing, which has my name on it; although _my_ patch
did not produce any warnings, came with a completely different changelog,
and served completely different purposes.

Instead of rushing with resending yet another series, please actually read
Thomas' review.

Thanks,

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


Re: [PATCH v3 5/6] timerfd: Add support for deferrable timers

2014-02-20 Thread Anton Vorontsov
On Thu, Feb 20, 2014 at 12:09:43PM +0100, Thomas Gleixner wrote:
> On Thu, 20 Feb 2014, Alexey Perevalov wrote:
> > From: Anton Vorontsov 
> > 
> > This patch implements a userland-side API for generic deferrable timers,
> > per linux/timer.h:
> > 
> >  * A deferrable timer will work normally when the system is busy, but
> >  * will not cause a CPU to come out of idle just to service it; instead,
> >  * the timer will be serviced when the CPU eventually wakes up with a
> >  * subsequent non-deferrable timer.
> > 
> > These timers are crucial for power saving, i.e. periodic tasks that want
> > to work in background when the system is under use, but don't want to
> > cause wakeups themselves.
> > 
> > The deferred timers are somewhat orthogonal to high-res external timers,
> > since the deferred timer is tied to the system load, not just to some
> > external decrementer source.
> 
> Again this changelog makes no sense. What's orthogonal to high-res
> timers and why are they external?

Not trying to defend the current series, just felt the need clarify this
one.

By orthogonal I meant that comparing to high resolution timers' use cases,
deferred timers can be super-low resolution, super inaccurate. We don't
know exactly when they will fire, all we know is something like "every 0.2
seconds, iff the system/user is doing something, otherwise don't bother."

As for external (my bad, shouldn't invent personal terminology): the
hrtimers are tied to some clock source (which is "external" to me), but
deferred timers are mostly tied to the system's activity.

Thanks,

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


Re: [PATCH v2 1/3] power_supply: Add power_supply notifier

2014-01-03 Thread Anton Vorontsov
On Fri, Jan 03, 2014 at 11:09:49AM +, Tc, Jenny wrote:
> Anton,
> 
> I don't see this patch in Linux tree. Any update on this would be helpful

http://git.infradead.org/battery-2.6.git/commit/d36240d26025bec95f3499e2401a56db98d9f01c

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


[GIT PULL] battery-2.6.git

2014-01-03 Thread Anton Vorontsov
Hello Linus,

Please pull battery-2.6 git tree to receive two fixes prepared for the
v3.13 release:

- Fix build error caused by max17042_battery conversion to the regmap API.

- Fix kernel oops when booting with wakeup_source_activate enabled.

Thank you!

Anton


The following changes since commit dc1ccc48159d63eca5089e507c82c7d22ef60839:

  Linux 3.13-rc2 (2013-11-29 12:57:14 -0800)

are available in the git repository at:

  git://git.infradead.org/battery-2.6.git tags/for-v3.13-fixes

for you to fetch changes up to 93353e8088057dd988362e6cae727af43734b494:

  max17042_battery: Fix build errors caused by missing REGMAP_I2C config 
(2013-12-01 14:25:03 -0800)


Austin Boyle (1):
  max17042_battery: Fix build errors caused by missing REGMAP_I2C config

Shuah Khan (1):
  power_supply: Fix Oops from NULL pointer dereference from 
wakeup_source_activate

 drivers/power/Kconfig |  1 +
 drivers/power/power_supply_core.c | 12 ++--
 2 files changed, 7 insertions(+), 6 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] gpio-charger: support wakeup events

2013-12-23 Thread Anton Vorontsov
On Wed, Dec 11, 2013 at 02:47:16AM +0400, Dmitry Eremin-Solenikov wrote:
> Add support for using gpio-charger IRQ as a wakeup event.
> 
> Signed-off-by: Dmitry Eremin-Solenikov 
> ---

Applied, thanks!

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


Re: [PATCH v7 1/3] charger: max14577: Add charger support for Maxim 14577

2013-12-23 Thread Anton Vorontsov
On Fri, Dec 06, 2013 at 12:32:12PM +0100, Krzysztof Kozlowski wrote:
> MAX14577 chip is a multi-function device which includes MUIC, charger
> and voltage regulator. The driver is located in drivers/mfd.
> 
> This patch supports battery charging control of MAX14577 chip and
> provides power supply class information to userspace.
> 
> Signed-off-by: Krzysztof Kozlowski 
> Signed-off-by: Kyungmin Park 
> ---

Applied, thanks!

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


Re: [PATCHv2 0/2] DT support for isp1704-charger

2013-12-23 Thread Anton Vorontsov
On Sun, Dec 01, 2013 at 02:00:09AM +0100, Sebastian Reichel wrote:
> This is the second iteration of the isp1704 DT patches.
> 
> Changes since v1:
>  * reword the binding documentation slightly according
>to the suggestions of Mark Rutland
>  * keep supporting the set_power callback and leave the
>board code in its current state. This solves potential
>merge problems. The additional code can be removed in
>the next merge window.

Applied, thanks a lot!

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


Re: [PATCH 1/3] power_supply: add power_supply_get_by_phandle

2013-12-23 Thread Anton Vorontsov
On Sun, Nov 24, 2013 at 05:49:29PM +0100, Sebastian Reichel wrote:
> Add method to get power supply by device tree phandle.
> 
> Signed-off-by: Sebastian Reichel 
> ---
>  drivers/power/power_supply_core.c | 24 
>  include/linux/power_supply.h  |  2 ++
>  2 files changed, 26 insertions(+)
> 
> diff --git a/drivers/power/power_supply_core.c 
> b/drivers/power/power_supply_core.c
> index 08bce22..99e4b41 100644
> --- a/drivers/power/power_supply_core.c
> +++ b/drivers/power/power_supply_core.c
> @@ -340,6 +340,30 @@ struct power_supply *power_supply_get_by_name(const char 
> *name)
...
> +
> + dev = class_find_device(power_supply_class, NULL, power_supply_np,
> + power_supply_match_device_node);
> +
> + of_node_put(power_supply_np);
> +
> + return dev ? dev_get_drvdata(dev) : NULL;
> +}
> +EXPORT_SYMBOL_GPL(power_supply_get_by_phandle);

The code had no !CONFIG_OF protection so I had to make the following
changes to this patch:

diff --git a/drivers/power/power_supply_core.c 
b/drivers/power/power_supply_core.c
index 23cd055..2660664 100644
--- a/drivers/power/power_supply_core.c
+++ b/drivers/power/power_supply_core.c
@@ -341,6 +341,7 @@ struct power_supply *power_supply_get_by_name(const char 
*name)
 }
 EXPORT_SYMBOL_GPL(power_supply_get_by_name);
 
+#ifdef CONFIG_OF
 static int power_supply_match_device_node(struct device *dev, const void *data)
 {
return dev->parent && dev->parent->of_node == data;
@@ -364,6 +365,7 @@ struct power_supply *power_supply_get_by_phandle(struct 
device_node *np,
return dev ? dev_get_drvdata(dev) : NULL;
 }
 EXPORT_SYMBOL_GPL(power_supply_get_by_phandle);
+#endif /* CONFIG_OF */
 
 int power_supply_powers(struct power_supply *psy, struct device *dev)
 {
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index 8d06537..c9dc4e0 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -244,8 +244,14 @@ extern struct atomic_notifier_head power_supply_notifier;
 extern int power_supply_reg_notifier(struct notifier_block *nb);
 extern void power_supply_unreg_notifier(struct notifier_block *nb);
 extern struct power_supply *power_supply_get_by_name(const char *name);
+#ifdef CONFIG_OF
 extern struct power_supply *power_supply_get_by_phandle(struct device_node *np,
const char *property);
+#else /* !CONFIG_OF */
+static inline struct power_supply *
+power_supply_get_by_phandle(struct device_node *np, const char *property)
+{ return NULL; }
+#endif /* CONFIG_OF */
 extern void power_supply_changed(struct power_supply *psy);
 extern int power_supply_am_i_supplied(struct power_supply *psy);
 extern int power_supply_set_battery_charged(struct power_supply *psy);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 0/3] DT support for bq2415x

2013-12-23 Thread Anton Vorontsov
On Sun, Nov 24, 2013 at 05:49:28PM +0100, Sebastian Reichel wrote:
> This patchset adds DT support for the bq2415x charger, which is used in the
> Nokia N900. The changes depend on Pali Rohár's "[PATCH v2 0/3] Add support for
> charging battery in Nokia RX-51" patchset [0].

Patches 1/3 and 2/3 applied, thanks a lot!

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


Re: [PATCH v2 2/3] bq2415x_charger: Use power_supply notifier for automode

2013-12-23 Thread Anton Vorontsov
On Tue, Nov 19, 2013 at 02:24:16PM +0100, Pavel Machek wrote:
> On Tue 2013-11-19 11:18:04, Pali Rohár wrote:
> > This patch removing set_mode_hook function from board data and replacing it 
> > with
> > new string variable of notifier power supply device. After this change it is
> > possible to add DT support because driver does not need specific board 
> > function
> > anymore. Only static data and name of power supply device is required.
> > 
> > Signed-off-by: Pali Rohár 
> 
> Reviewed-by: Pavel Machek 

Applied, thanks!

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


Re: [PATCH V2 2/2] power: reset: as3722: add power-off driver

2013-12-23 Thread Anton Vorontsov
On Fri, Dec 20, 2013 at 06:54:00PM +0530, Laxman Dewangan wrote:
> ams AS3722 supports the power off functionality to turn off
> system.
> 
> Add power off driver for ams AS3722.
> 
> Signed-off-by: Laxman Dewangan 
> Tested-by: Stephen Warren 
> ---
> Changes from V1:
> - Just added tested by.

Both applied, thanks a lot!

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


Re: [PATCH v2 2/3] bq2415x_charger: Use power_supply notifier for automode

2013-12-01 Thread Anton Vorontsov
On Mon, Dec 02, 2013 at 01:02:40AM +0100, Michael Trimarchi wrote:
> On Sun, Dec 1, 2013 at 11:37 PM, Anton Vorontsov  wrote:
> > On Mon, Nov 25, 2013 at 08:16:34PM +0100, Michael Trimarchi wrote:
> > ...
> >> >> So you can read this value without any type of synchronization
> >> >> with the power_supply_core
> >> >> and sysfs implementation?
> > ...
> >> https://lists.ubuntu.com/archives/kernel-team/2013-January/025206.html
> >>
> >> I found and equivalent scenario that I was trying to said
> >
> > That's a good question, actually. Even though in Pali's case the notifier
> > is atomic (so that we are pretty confident that the object won't be
> > unregistered), there is still a possiblity of a dead lock, for example. So
> 
> So if the get_property is a sleeping function it will be a deadlock. Right?

All kind of bad things might happen, yes. But before that I would expect a
bunch of warnings from might_sleep() stuff.

I would recommend to test the patches using preempt/smp kernels + various
DEBUG_ kernel options set.

Thanks,

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


Re: [PATCH v2 2/3] bq2415x_charger: Use power_supply notifier for automode

2013-12-01 Thread Anton Vorontsov
On Mon, Nov 25, 2013 at 08:16:34PM +0100, Michael Trimarchi wrote:
...
> >> So you can read this value without any type of synchronization
> >> with the power_supply_core
> >> and sysfs implementation?
...
> https://lists.ubuntu.com/archives/kernel-team/2013-January/025206.html
> 
> I found and equivalent scenario that I was trying to said

That's a good question, actually. Even though in Pali's case the notifier
is atomic (so that we are pretty confident that the object won't be
unregistered), there is still a possiblity of a dead lock, for example. So
notifiers should be careful to not hold any locks, because the other
driver might call get_property(), which might acquire locks.

Thanks,

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


Re: [PATCH] max17042: Fix build errors caused by missing REGMAP_I2C config

2013-12-01 Thread Anton Vorontsov
On Mon, Nov 25, 2013 at 09:40:04AM +0900, jonghwa3@samsung.com wrote:
> > max17042 now uses regmap interface but does not enable config option. This 
> > patch fixes the following build errors:
> > 
> > drivers/power/max17042_battery.c:661:15: error: variable 
> > ‘max17042_regmap_config’ has initializer but incomplete type
> > 
> > Signed-off-by: Austin Boyle 
> > ---
> > diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
> > index 5e2054a..85ad58c 100644
> > --- a/drivers/power/Kconfig
> > +++ b/drivers/power/Kconfig
> > @@ -196,6 +196,7 @@ config BATTERY_MAX17040
> >  config BATTERY_MAX17042
> > tristate "Maxim MAX17042/17047/17050/8997/8966 Fuel Gauge"
> > depends on I2C
> > +   select REGMAP_I2C
> > help
> >   MAX17042 is fuel-gauge systems for lithium-ion (Li+) batteries
> >   in handheld and portable equipment. The MAX17042 is configured
> 
> Sorry, It's my fault. Thanks.
> 
> Acked-by: Jonghwa Lee 

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


Re: [PATCH v2 1/3] power_supply: Add power_supply notifier

2013-12-01 Thread Anton Vorontsov
On Tue, Nov 19, 2013 at 11:18:03AM +0100, Pali Rohár wrote:
> This patch adds a notifier chain to the power_supply.
> This notifier helps drivers in other subsystem to listen to
> changes in power supply subsystem. This would help to take some
> actions in those drivers on changing the power supply properties.
> One such scenario is to increase/decrease system performance based
> on the battery capacity/voltage. Another scenario is to adjust the
> h/w peak current detection voltage/current thresholds based on battery
> voltage/capacity. The notifier helps drivers to listen to changes
> in power_suppy susbystem without polling the power_supply properties
> 
> Signed-off-by: Jenny TC 
> Signed-off-by: Pali Rohár 
...
> +enum power_supply_notifier_events {
> + PSY_EVENT_NONE,

This one is not needed.

> + PSY_EVENT_PROP_CHANGED,
> + PSY_EVENT_BATTERY,
> + PSY_EVENT_CABLE,
> +};

The only event that is currently used in your patch series is
EVENT_PROP_CHANGED... So, I applied the patch with the following changes:

diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index c6f52c0..0c2a260 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -159,10 +159,7 @@ enum power_supply_type {
 };
 
 enum power_supply_notifier_events {
-   PSY_EVENT_NONE,
PSY_EVENT_PROP_CHANGED,
-   PSY_EVENT_BATTERY,
-   PSY_EVENT_CABLE,
 };
 
 union power_supply_propval {
@@ -242,7 +239,7 @@ struct power_supply_info {
int use_for_apm;
 };
 
-extern struct atomic_notifier_headpower_supply_notifier;
+extern struct atomic_notifier_head power_supply_notifier;
 extern int power_supply_reg_notifier(struct notifier_block *nb);
 extern void power_supply_unreg_notifier(struct notifier_block *nb);
 extern struct power_supply *power_supply_get_by_name(const char *name);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v2 1/3] power_supply: Add power_supply notifier

2013-12-01 Thread Anton Vorontsov
On Wed, Nov 27, 2013 at 05:23:34PM +, Tc, Jenny wrote:
> 
> > Subject: [PATCH v2 1/3] power_supply: Add power_supply notifier
> > 
> > This patch adds a notifier chain to the power_supply.
> > This notifier helps drivers in other subsystem to listen to changes in 
> > power supply
> > subsystem. This would help to take some actions in those drivers on 
> > changing the power
> > supply properties.
> > One such scenario is to increase/decrease system performance based on the 
> > battery
> > capacity/voltage. Another scenario is to adjust the h/w peak current 
> > detection
> > voltage/current thresholds based on battery voltage/capacity. The notifier 
> > helps drivers to
> > listen to changes in power_suppy susbystem without polling the power_supply 
> > properties
> > 
> > Signed-off-by: Jenny TC 
> > Signed-off-by: Pali Rohár 
> > ---
> 
> Acked-by: Jenny TC 

Applied, thanks a lot!

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


Re: [PATCH v3 1/2] power_supply: Fix Oops from NULL pointer dereference from wakeup_source_activate

2013-12-01 Thread Anton Vorontsov
On Fri, Nov 22, 2013 at 10:54:28AM -0700, Shuah Khan wrote:
> power_supply_register() calls device_init_wakeup() to register a wakeup
> source before initializing dev_name. As a result, device_wakeup_enable()
> end up registering wakeup source with a null name when 
> wakeup_source_register()
> gets called with dev_name(dev) which is null at the time.
> 
> When kernel is booted with wakeup_source_activate enabled, it will panic
> when the trace point code tries to dereference ws->name.
> 
> Fixed the problem by moving up the kobject_set_name() call prior to accesses
> to dev_name(). Replaced kobject_set_name() with dev_set_name() which is the
> right interface to be called from drivers. Fixed the call to device_del() 
> prior
> to device_add() in for wakeup_init_failed error handling code.

Applied, thanks a lot!

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


[GIT PULL] battery-2.6.git

2013-11-17 Thread Anton Vorontsov
Hello Linus,

Please pull battery-2.6 git tree to receive changes prepared for the v3.13
release. Highlights:

- A new driver for TI BQ24735 Battery Chargers, courtesy of NVidia.

- Device tree bindings for TWL4030 chips.

- Random fixes and cleanups.

Thank you,

Anton


The following changes since commit 61e6cfa80de5760bbe406f4e815b7739205754d2:

  Linux 3.12-rc5 (2013-10-13 15:41:28 -0700)

are available in the git repository at:

  git://git.infradead.org/battery-2.6.git tags/for-v3.13

for you to fetch changes up to c8024234c20eaf7b163cc4dbd963cb9cd03a4ff1:

  pm2301-charger: Remove unneeded NULL checks (2013-11-12 22:36:34 -0800)


Alexandre Belloni (1):
  bq2415x_charger: Fix max battery regulation voltage

Anton Vorontsov (1):
  power_supply: Fix documentation for TEMP_*ALERT* properties

Dan Carpenter (1):
  pm2301-charger: Remove unneeded NULL checks

Darbha Sriharsha (1):
  power_supply: Add support for bq24735 charger

Jonghwa Lee (2):
  charger-manager : Replace kzalloc to devm_kzalloc and remove uneccessary 
code
  max17042_battery: Support regmap to access device's registers

Manish Badarkhe (2):
  tps65090-charger: Use "IS_ENABLED(CONFIG_OF)" for DT code
  max17042_battery: Use SIMPLE_DEV_PM_OPS

NeilBrown (1):
  twl4030_charger: Add devicetree support

Pali Rohár (1):
  isp1704_charger: Fix driver to work with changes introduced in v3.5

Sachin Kamat (4):
  ab8500-charger: Check return value of regulator_enable
  ab8500-charger: Remove redundant break
  pm2301-charger: Check return value of regulator_enable
  pm2301-charger: Staticize pm2xxx_charger_die_therm_mngt

Wei Yongjun (1):
  tps65090-charger: Drop devm_free_irq of devm_ allocated irq

 .../devicetree/bindings/power/twl-charger.txt  |  20 +
 .../bindings/power_supply/ti,bq24735.txt   |  32 ++
 Documentation/power/power_supply_class.txt |   8 +-
 arch/arm/boot/dts/twl4030.dtsi |   6 +
 drivers/power/Kconfig  |   6 +
 drivers/power/Makefile |   1 +
 drivers/power/ab8500_charger.c |  17 +-
 drivers/power/bq2415x_charger.c|   6 +-
 drivers/power/bq24735-charger.c| 419 +
 drivers/power/charger-manager.c|  85 ++---
 drivers/power/isp1704_charger.c|  91 ++---
 drivers/power/max17042_battery.c   | 373 +-
 drivers/power/pm2301_charger.c |  27 +-
 drivers/power/tps65090-charger.c   |  30 +-
 drivers/power/twl4030_charger.c|  47 ++-
 include/linux/power/bq24735-charger.h  |  39 ++
 16 files changed, 852 insertions(+), 355 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/power/twl-charger.txt
 create mode 100644 
Documentation/devicetree/bindings/power_supply/ti,bq24735.txt
 create mode 100644 drivers/power/bq24735-charger.c
 create mode 100644 include/linux/power/bq24735-charger.h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [patch] pm2301-charger: remove unneeded NULL checks

2013-11-12 Thread Anton Vorontsov
On Thu, Nov 07, 2013 at 11:06:17AM +0300, Dan Carpenter wrote:
> If "pm2" were NULL we would oops printing the error message.
> Fortunately, that's not possible so I have removed the NULL checks.
> 
> Signed-off-by: Dan Carpenter 

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


Re: [PATCH] power:power_supply_syfs : Treat PROP_TYPE as a regular attribute first

2013-10-27 Thread Anton Vorontsov
On Sat, Oct 26, 2013 at 02:01:22AM +0300, Philippe De Swert wrote:
...
> I think I did not make myself very clear. Well there are actually no
> different chargers here. It is one USB charger input, however its
> properties are different depending on the actual connected "charger
> device/type". It is the same charging controller however when a usb
> cable is connected and power comes from a PC it is very different
> from when it is a dedicated USB charger.

See this discussion http://lkml.org/lkml/2013/10/28/39, there I am trying
to make a point that we need a separate subsystem for chargers. And in
power supply subsystem we want to only report the AC/USB supply state.

Thanks,

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


Re: N900 DT

2013-10-27 Thread Anton Vorontsov
On Mon, Oct 28, 2013 at 03:01:35AM +, Tc, Jenny wrote:
> > On Saturday 26 October 2013 02:25:02 Sebastian Reichel wrote:
> > > On Fri, Oct 25, 2013 at 08:39:40PM +0200, Pali Rohár wrote:
> > > > Now I found this patch and it looks like it will be in mainline
> > > > kernel. And after that it could be simple to listen for needed
> > > > events from isp driver in my bq driver (without touching isp).
> > > >
> > > > https://lkml.org/lkml/2013/7/25/204
> > > >
> > > > Can you look at isp1704 driver for DT support? I think that only one
> > > > gpio needs to be passed to driver from board data.
> > >
...
> > What I need is receive property change event (from isp1704) in bq24150a. 
> > And with this
> > patch https://lkml.org/lkml/2013/7/25/204
> > bq24150a driver can receive them and use only these which comes from driver 
> > specified in
> > DT (on n900 from isp1704).

Pali, Sebastian,

I am OK with that patch. Please send it (of course preserving Jenny's
authorship), along with a user of that notifier and I'll happily apply it.

Thanks,

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


Re: [PATCH 7/7] power_supply: Introduce PSE compliant algorithm

2013-10-27 Thread Anton Vorontsov
On Mon, Sep 23, 2013 at 11:34:05PM +0530, Jenny TC wrote:
[...]
> +#define BATTID_STR_LEN   8
> +#define BATT_TEMP_NR_RNG 6
> +/* Charging Profile */
> +struct psy_ps_pse_mod_prof {
> + /* battery id */
> + char batt_id[BATTID_STR_LEN];
> + /* type of battery */
> + u16 battery_type;
> + u16 capacity;
> + u16 voltage_max;
> + /* charge termination current */
> + u16 chrg_term_mA;
> + /* Low battery level voltage */
> + u16 low_batt_mV;
> + /* upper and lower temperature limits on discharging */
> + u8 disch_tmp_ul;
> + u8 disch_tmp_ll;
> + /* number of temperature monitoring ranges */
> + u16 temp_mon_ranges;
> + struct psy_ps_temp_chg_table temp_mon_range[BATT_TEMP_NR_RNG];
> + /* Lowest temperature supported */
> + short int temp_low_lim;
> +} __packed;

These all seem like properties of a battery. Why the battery is not
registered with the power_supply framework?

What is PSE, by the way?

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


Re: [PATCH 1/7] power_supply: Add charger control properties

2013-10-27 Thread Anton Vorontsov
On Mon, Oct 28, 2013 at 03:36:36AM +, Tc, Jenny wrote:
> > But do we really want to control the chargers through the power_supply's 
> > user-visible
> > interface? It makes the whole power supply thing so complicated that I'm 
> > already losing
> > track of it. Right now I think I would prefer to move all the charger logic 
> > out of the psy
> > class.
> >
> 
> I think exposing properties make the logic generic, otherwise it may end up 
> in having callback
> functions.
>
> Also there are some scenarios where the charging algorithm has to be in the
> user space.

Which scenarios?

Plus, I am more questioning if the power supply framework is the right
thing to control the *chargers*. Chargers are not the power supply to the
system or any device (well, except for the batteries themselves).

> Using the patch https://lkml.org/lkml/2013/7/25/204,
> the power supply change notification can be broadcasted. We can add notifier 
> events
> for power_supply_register and thermal throttling. This way 
> power_supply_charger.c can
> be a separate driver and it can listen to psy notifications to take actions.

If you ever need this particular notifier, I am OK with it (but I'll
consider applying it only together with some its users).

Basically, I am more against these three patches:

[PATCH 3/7] power_supply: add throttle state
[PATCH 2/7] power_supply: add charger cable properties
[PATCH 1/7] power_supply: Add charger control properties (enable_charger part)

These three add too much "charger" specifics to the power_supply stuff. I
think they deserve their own subsystem/class/whatever.

Also, the battid framework is written without any notion of device/driver
separation, uses global variables, and I suspect it should not exist at
all (psy_get_batt_prop function makes me think that you should just
register the i2c/spi/w1 battery with the power_supply and not use the
ad-hoc stuff).

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


Re: [PATCH 1/7] power_supply: Add charger control properties

2013-10-27 Thread Anton Vorontsov
Hello Jenny,

Thanks a lot for your work on this!

On Mon, Sep 23, 2013 at 11:33:59PM +0530, Jenny TC wrote:
> The battery charger needs to have control path along
> with the reporting charger properties. In existing solutions
> this is implemented using regulator framework. A regulator
> framework doesn't fit a charger driver requirement because of the
> following reason
>

General note:

Please always Cc as many relevant developers as possible, not just me. For
me it takes months to review patches, and you surely want to get at least
a preliminary review from other power supply folks. By Cc'ing just me you
are slowing yourself down.

If you get some Acks/Reviews from other developers on your patches that
shows that the feature is surely in demand and makes sense in general.

"git shortlog -s -n -e drivers/power/*charg*" is a good start to see whom
you'd better Cc in this case.

(Unrelated to these patches, but just FYI, having a chain of

Reviewed-by: Somebody1 <...@same_company.foo>
Reviewed-by: Somebody2 <...@same_company.foo>
...
Reviewed-by: SomebodyN <...@same_company.foo>

Works in opposite direction, it makes me suspicious. :)

> and charging (charger to battery).Disabling the charging path alone
> (eg over battery temperature) will allow the platform to work with
> power from charger without discharging the battery. And the charger
> may need to be disabled completely based on the charger temperature
> or the platform temperature.
> Charger has more than one pair of voltage/current to control (CC,CV,INLMT)
> These features will not directly fit in the regulator framework
> 
> Since the charger driver sits in the power supply subsystem it make sense
> to add the properties to control the charger.

Looking into the patches, it seems that we are putting a lot of
charger-specific knobs into the power supply class, but the primary idea
of power supply subsystem is to monitor the power supplies of the system
itself and system's devices like mouse/keyboard's batteries.

The border of what we define as power supply class object is blurry, so
there is a lot of confusion indeed. For example, some chargers register
TYPE_MAINS or TYPE_USB power_supply objects, but they do it since the
charger chip itself is responsible for monitoring these supplies, so it is
fine, and it does not affect the power supply class itself.

But do we really want to control the chargers through the power_supply's
user-visible interface? It makes the whole power supply thing so
complicated that I'm already losing track of it. Right now I think I would
prefer to move all the charger logic out of the psy class.

More specifically, this code:

> @@ -561,6 +575,11 @@ int power_supply_register(struct device *parent, struct 
> power_supply *psy)
>   if (rc)
>   goto create_triggers_failed;
>
> + if (psy_is_charger(psy))
> + rc = power_supply_register_charger(psy);
> + if (rc)
> + pr_debug("device: '%s': power_supply_register_charger failed\n",
> + dev_name(dev));

I have a weird feeling about the fact that the power_supply_register()
registers a charger. OK, we have thermal stuff registration there, but it
is completely different. We have the cooling device registration there as
well, and this stuff would be really nice to move out to some "chargers
subsystem".

So, Jenny, the question is: can we separate chargers logic from the power
supply? So that we don't have "charger enable"/"charger disable" knobs in
the psy class itself. It is still fine if you need to have some interface
to the psy class so that the chargers subsystem would interface with it,
though. But I think that charger drivers have to register itself with two
subsystems: chargers and power_supply (optionally).

Thanks,

Anton

> Signed-off-by: Jenny TC 
> 
> Change-Id: Id91dbbd8f34499afa97b7d8f11ecf5467847f6a8
> ---
>  Documentation/power/power_supply_class.txt |   16 
>  drivers/power/power_supply_sysfs.c |8 
>  include/linux/power_supply.h   |8 
>  3 files changed, 32 insertions(+)
> 
> diff --git a/Documentation/power/power_supply_class.txt 
> b/Documentation/power/power_supply_class.txt
> index 3f10b39..5a5e7fa 100644
> --- a/Documentation/power/power_supply_class.txt
> +++ b/Documentation/power/power_supply_class.txt
> @@ -118,6 +118,10 @@ relative, time-based measurements.
>  CONSTANT_CHARGE_CURRENT - constant charge current programmed by charger.
>  CONSTANT_CHARGE_CURRENT_MAX - maximum charge current supported by the
>  power supply object.
> +INPUT_CURRENT_LIMIT - input current limit programmed by charger. Indicates
> +the current drawn from a charging source.
> +CHARGE_TERM_CUR - Charge termination current used to detect the end of charge
> +condition
>  
>  CONSTANT_CHARGE_VOLTAGE - constant charge voltage programmed by charger.
>  CONSTANT_CHARGE_VOLTAGE_MAX - maximum charge voltage supported by the
> @@ -140,12 +144,24 @@ TEMP_

Re: [PATCH] Fuel Guague: MAX17040: Use regmap to interface with internal registers

2013-10-25 Thread Anton Vorontsov
On Mon, Oct 21, 2013 at 05:48:35PM +0900, �� wrote:
> We use regmap to interface with internal registers in fuel guague MAX17040.
> 
> Signed-off-by: Nam KwanWoo 
> Signed-off-by: Kyungmin Park 
> ---

$ git am -s patch
fatal: cannot convert from ks_c_5601-1987 to UTF-8

I fixed this manually, but then I noticed this:

> @@ -124,22 +104,23 @@ static void max17040_get_vcell(struct i2c_client
> *client)

Which means that the patch is also line-wrap damaged... so I gave up.

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


Re: [PATCH] max17042_battery: use SIMPLE_DEV_PM_OPS

2013-10-25 Thread Anton Vorontsov
On Mon, Oct 14, 2013 at 10:56:51AM +0530, Manish Badarkhe wrote:
> Use the SIMPLE_DEV_PM_OPS macro to declare the driver's
> pm_ops.
> 
> Signed-off-by: Manish Badarkhe 

Applied, thanks!

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


Re: [PATCH] bq2415x_charger: fix max battery regulation voltage

2013-10-25 Thread Anton Vorontsov
On Wed, Oct 16, 2013 at 04:09:40PM +0200, Alexandre Belloni wrote:
> I forgot to add this is a v2 and I just added a comment.
> 
> On 16/10/2013 16:08, Alexandre Belloni wrote:
> > As per the datasheets, maximum battery regulation voltage is 4440mV.
> >
> > The formula is (voltage - offset) / step, so the maximum value is:
> > (4440 - 3500) / 20 = 47
> >
> > Signed-off-by: Alexandre Belloni 

Applied, thanks!

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


Re: [PATCH] tps65090-charger: Use "IS_ENABLED(CONFIG_OF)" for DT code.

2013-10-25 Thread Anton Vorontsov
On Mon, Sep 30, 2013 at 12:03:40PM -0400, Rhyland Klein wrote:
> On 9/28/2013 12:32 AM, Manish Badarkhe wrote:
> > Instead of "#if defined(CONFIG_OF)" use "IS_ENABLED(CONFIG_OF)" option
> > for DT code to avoid if-deffery in code.
> > Also, arranged header files in alphabetically.
> > 
> > Signed-off-by: Manish Badarkhe 
> > ---
> > :100644 100644 bdd7b9b... 8b9c406... M  drivers/power/tps65090-charger.c
> >  drivers/power/tps65090-charger.c |   19 +--
> >  1 file changed, 5 insertions(+), 14 deletions(-)
> LGTM
> Acked-by: Rhyland Klein 

Applied, thanks!

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


Re: [Patch V5] drivers: power: Add support for bq24735 charger

2013-10-25 Thread Anton Vorontsov
On Fri, Oct 25, 2013 at 03:48:41PM -0700, Anton Vorontsov wrote:
> On Mon, Oct 14, 2013 at 12:40:26PM -0600, Stephen Warren wrote:
> > >>> diff --git 
> > >>> a/Documentation/devicetree/bindings/power_supply/ti,bq24735.txt 
> > >>> b/Documentation/devicetree/bindings/power_supply/ti,bq24735.txt
> > >>
> > >>> +Optional properties :
> > >>
> > >>> + - ti,ac-detect-gpios : This GPIO is optionally used to read the AC 
> > >>> adapter
> > >>> +   presence.
> > >>
> > >> Is that actually a property of the BQ24735 chip itself (i.e. is it an
> > >> output signal from the chip), or part of the board/system?
> > > 
> > > The gpio itself is actually what the IRQ line is tied to from the
> > > bq24735 -> tegra (in this case). In other words this is a Host GPIO that
> > > is configured as an input and connected to the bq24735.
> > 
> > Ok, so this is the ACOK output pin? In that case, it's fine. It might be
> > worth mentioning that explicitly though.
> 
> I added the comment to the documentation and applied the patch with a
> "Thanks-to: Stephen Warren " tag. :)

Oh, and as well as

Thanks-to: Thierry Reding 

(People seem to review drivers, but do not give their Reviewed-by tags, so
the thanks tag is the best thing I can legally do in such a case.)

Thanks,

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


Re: [Patch V5] drivers: power: Add support for bq24735 charger

2013-10-25 Thread Anton Vorontsov
On Mon, Oct 14, 2013 at 12:40:26PM -0600, Stephen Warren wrote:
> >>> diff --git 
> >>> a/Documentation/devicetree/bindings/power_supply/ti,bq24735.txt 
> >>> b/Documentation/devicetree/bindings/power_supply/ti,bq24735.txt
> >>
> >>> +Optional properties :
> >>
> >>> + - ti,ac-detect-gpios : This GPIO is optionally used to read the AC 
> >>> adapter
> >>> +   presence.
> >>
> >> Is that actually a property of the BQ24735 chip itself (i.e. is it an
> >> output signal from the chip), or part of the board/system?
> > 
> > The gpio itself is actually what the IRQ line is tied to from the
> > bq24735 -> tegra (in this case). In other words this is a Host GPIO that
> > is configured as an input and connected to the bq24735.
> 
> Ok, so this is the ACOK output pin? In that case, it's fine. It might be
> worth mentioning that explicitly though.

I added the comment to the documentation and applied the patch with a
"Thanks-to: Stephen Warren " tag. :)

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


Re: [PATCH v3 1/4] ab8500-charger: Check return value of regulator_enable

2013-10-25 Thread Anton Vorontsov
On Fri, Sep 06, 2013 at 10:38:00AM +0100, Lee Jones wrote:
> On Fri, 06 Sep 2013, Sachin Kamat wrote:
> 
> > Check the return value of regulator_enable to silence the following
> > type of warnings:
> > drivers/power/ab8500_charger.c:1390:20: warning: ignoring return value
> > of ‘regulator_enable’, declared with attribute warn_unused_result
> > [-Wunused-result]
> > 
> > Signed-off-by: Sachin Kamat 
> > Cc: Lee Jones 
> > ---
> > Compile tested.
> > 
> > Changes since v2:
> > * removed redundant assignment to false.
> > Changes since v1:
> > * converted dev_err and return to dev_warn as suggested by Lee Jones.
> > ---
> > 
> >  drivers/power/ab8500_charger.c |   16 
> >  1 file changed, 12 insertions(+), 4 deletions(-)
> 
> Looks good now.
> 
> Acked-by: Lee Jones 

Applied, thanks a lot for the patches and reviews!

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


Re: [PATCH] power:power_supply_syfs : Treat PROP_TYPE as a regular attribute first

2013-10-25 Thread Anton Vorontsov
On Thu, Aug 15, 2013 at 02:09:58AM +0300, Philippe De Swert wrote:
> These days we often have USB powered devices. This means that often the
> type is variable. Common examples are smartphones which can be charged
> through a normal USB port on a PC/laptop, a dedicated charger, etc...
> Often those chips also have support for other charger types like a
> mains/DC charger. This means that often there are several psy structures
> in the driver and makes it impossible to stick to just one type.

I would guess that a lot of userland code assumes that the type is fixed.
We can't break this assumption. Plus I don't think we really need the
changing types.

> Userspace sometimes needs to behave differently based on the type of charger
> connected to such devices.

A system with several charger should either:

1. Register all of them (mains, usb, etc.) as a separate power supply
device, and then use PROP_ONLINE to specify whether something is connected
to the port or not.

2. Register only the charger type that is currently connected to the
system.

This is how we've been doing things from the very start.

Thanks,

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


Re: [PATCH 2/4] power: isp1704_charger: Fix driver to work with changes introduced in v3.5

2013-10-22 Thread Anton Vorontsov
On Sun, Sep 08, 2013 at 10:50:37AM +0200, Pali Rohár wrote:
> * omap musb driver does not report USB_EVENT_ENUMERATED event anymore
> * omap musb driver reporting USB_EVENT_VBUS when charger is connected
> * read last event from phy->last_event (instead from ulpi register)
> * do not call wall charger detection more times
> 
> Signed-off-by: Pali Rohár 

Applied, thanks a lot!

(Per others' review comments I am assuming that the second isp1704 patch
will be reworked to support device-tree, so I am not applying it.)

Thanks,

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


Re: [patch] mm, vmpressure: add high level

2013-10-16 Thread Anton Vorontsov
Hello David,

On Wed, Oct 16, 2013 at 05:43:55PM -0700, David Rientjes wrote:
> Vmpressure has two important levels: medium and critical.  Medium is 
> defined at 60% and critical is defined at 95%.
> 
> We have a customer who needs a notification at a higher level than medium, 
> which is slight to moderate reclaim activity, and before critical to start 
> throttling incoming requests to save memory and avoid oom.
> 
> This patch adds the missing link: a high level defined at 80%.
> 
> In the future, it would probably be better to allow the user to specify an 
> integer ratio for the notification rather than relying on arbitrarily 
> specified levels.

Does the customer need to differentiate the two levels (medium and high),
or the customer only interested in this (80%) specific level?

In the latter case, instead of adding a new level I would vote for adding
a [sysfs] knob for modifying medium level's threshold.

Thanks,

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


Re: [PATCH] vmpressure: fix divide-by-0 in vmpressure_work_fn

2013-09-11 Thread Anton Vorontsov
On Wed, Sep 11, 2013 at 06:03:57PM +0200, Michal Hocko wrote:
> The patch below. I find it little bit nicer than Hugh's original one
> because having the two checks sounds more confusing.
> What do you think Hugh, Anton?

Acked-by: Anton Vorontsov 

Thanks!

> ---
> From 888745909da34f8aee8a208a82d467236b828d0d Mon Sep 17 00:00:00 2001
> From: Michal Hocko 
> Date: Wed, 11 Sep 2013 17:48:10 +0200
> Subject: [PATCH] vmpressure: fix divide-by-0 in vmpressure_work_fn
> 
> Hugh Dickins has reported a division by 0 when a vmpressure event is
> processed. The reason for the exception is that a single vmpressure
> work item (which is per memcg) might be processed by multiple CPUs
> because it is enqueued on system_wq which is !WQ_NON_REENTRANT.
> This means that the out of lock vmpr->scanned check in
> vmpressure_work_fn is inherently racy and the racing workers will see
> already zeroed scanned value after they manage to take the spin lock.
> 
> The patch simply moves the vmp->scanned check inside the sr_lock to fix
> the race.
> 
> The issue was there since the very beginning but "vmpressure: change
> vmpressure::sr_lock to spinlock" might have made it more visible as the
> racing workers would sleep on the mutex and give it more time to see
> updated value. The issue was still there, though.
> 
> Reported-by: Hugh Dickins 
> Signed-off-by: Michal Hocko 
> Cc: sta...@vger.kernel.org
> ---
>  mm/vmpressure.c |   17 +
>  1 file changed, 9 insertions(+), 8 deletions(-)
> 
> diff --git a/mm/vmpressure.c b/mm/vmpressure.c
> index e0f6283..ad679a0 100644
> --- a/mm/vmpressure.c
> +++ b/mm/vmpressure.c
> @@ -164,18 +164,19 @@ static void vmpressure_work_fn(struct work_struct *work)
>   unsigned long scanned;
>   unsigned long reclaimed;
>  
> + spin_lock(&vmpr->sr_lock);
> +
>   /*
> -  * Several contexts might be calling vmpressure(), so it is
> -  * possible that the work was rescheduled again before the old
> -  * work context cleared the counters. In that case we will run
> -  * just after the old work returns, but then scanned might be zero
> -  * here. No need for any locks here since we don't care if
> -  * vmpr->reclaimed is in sync.
> +  * Several contexts might be calling vmpressure() and the work
> +  * item is sitting on !WQ_NON_REENTRANT workqueue so different
> +  * CPUs might execute it concurrently. Bail out if the scanned
> +  * counter is already 0 because all the work has been done already.
>*/
> - if (!vmpr->scanned)
> + if (!vmpr->scanned) {
> + spin_unlock(&vmpr->sr_lock);
>   return;
> + }
>  
> - spin_lock(&vmpr->sr_lock);
>   scanned = vmpr->scanned;
>   reclaimed = vmpr->reclaimed;
>   vmpr->scanned = 0;
> -- 
> 1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] vmpressure: fix divide-by-0 in vmpressure_work_fn

2013-09-11 Thread Anton Vorontsov
On Mon, Sep 09, 2013 at 01:08:47PM +0200, Michal Hocko wrote:
> On Fri 06-09-13 22:59:16, Hugh Dickins wrote:
> > Hit divide-by-0 in vmpressure_work_fn(): checking vmpr->scanned before
> > taking the lock is not enough, we must check scanned afterwards too.
> 
> As vmpressure_work_fn seems the be the only place where we set scanned
> to 0 (except for the rare occasion when scanned overflows which
> would be really surprising) then the only possible way would be two
> vmpressure_work_fn racing over the same work item. system_wq is
> !WQ_NON_REENTRANT so one work item might be processed by multiple
> workers on different CPUs. This means that the vmpr->scanned check in
> the beginning of vmpressure_work_fn is inherently racy.
> 
> Hugh's patch fixes the issue obviously but doesn't it make more sense to
> move the initial vmpr->scanned check under the lock instead?
> 
> Anton, what was the initial motivation for the out of the lock
> check? Does it really optimize anything?

Thanks a lot for the explanation.

Answering your question: the idea was to minimize the lock section, but the
section is quite small anyway so I doubt that it makes any difference (during
development I could not measure any effect of vmpressure() calls in my system,
though the system itself was quite small).

I am happy with moving the check under the lock or moving the work into
its own WQ_NON_REENTRANT queue.

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


Re: [PATCH] vmpressure: fix divide-by-0 in vmpressure_work_fn

2013-09-10 Thread Anton Vorontsov
On Fri, Sep 06, 2013 at 10:59:16PM -0700, Hugh Dickins wrote:
> Hit divide-by-0 in vmpressure_work_fn(): checking vmpr->scanned before
> taking the lock is not enough, we must check scanned afterwards too.
> 
> Signed-off-by: Hugh Dickins 
> Cc: sta...@vger.kernel.org

Hm... Just trying to understand this one. I don't see how this can happen,
considering that only one instance of vmpressure_work_fn() supposed to be
running (unlike vmpressure()), and the only place where we zero
vmpr->scanned is vmpressure_work_fn() itself?

> ---
> 
>  mm/vmpressure.c |3 +++
>  1 file changed, 3 insertions(+)
> 
> --- 3.11/mm/vmpressure.c  2013-09-02 13:46:10.0 -0700
> +++ linux/mm/vmpressure.c 2013-09-06 22:43:03.596003080 -0700
> @@ -187,6 +187,9 @@ static void vmpressure_work_fn(struct wo
>   vmpr->reclaimed = 0;
>   spin_unlock(&vmpr->sr_lock);
>  
> + if (!scanned)
> + return;
> +
>   do {
>   if (vmpressure_event(vmpr, scanned, reclaimed))
>   break;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[GIT PULL] battery-2.6.git

2013-09-10 Thread Anton Vorontsov
Hello Linus,

Please pull battery-2.6 git tree to receive changes prepared for the v3.12
release. Here is what we have:

New drivers:

- APM X-Gene system reboot driver by Feng Kan and Loc Ho (APM).

- Qualcomm MSM reboot/poweroff driver by Abhimanyu Kapur (Codeaurora).

- Texas Instruments BQ24190 charger driver by Mark A. Greer (Animal Creek
  Technologies).

- Texas Instruments TWL4030 MADC battery driver by Lukas Märdian and Marek
  Belisko (Golden Delicious Computers). The driver is used on Freerunner
  GTA04 phones.

Highlighted fixes and improvements:

- Suspend/wakeup logic improvements: power supply objects will block
  system suspend until all power supply events are processed. Thanks to
  Zoran Markovic (Linaro), Arve Hjonnevag and Todd Poynor (Google).

Thanks!

Anton


The following changes since commit c095ba7224d8edc71dcef0d655911399a8bd4a3f:

  Linux 3.11-rc4 (2013-08-04 13:46:46 -0700)

are available in the git repository at:

  git://git.infradead.org/battery-2.6.git tags/for-v3.12

for you to fetch changes up to db15e6312efd537e2deb2cbad110c23f98704a3c:

  rx51_battery: Fix channel number when reading adc value (2013-08-30 17:49:15 
-0700)


Abhimanyu Kapur (1):
  power: reset: Add msm restart support

Andrea Adami (2):
  power supply: collie_battery: Convert to use dev_pm_ops
  power_supply: tosa_battery: Get rid of irq_to_gpio usage

Anton Vorontsov (1):
  bq24190_charger: Workaround SS definition problem on i386 builds

Dan Carpenter (1):
  ab8500-charger: We print an unintended error message

Jingoo Han (1):
  power_supply: Replace strict_strtol() with kstrtol()

Kevin Hilman (1):
  MAINTAINERS: drivers/power: add entry for SmartReflex AVS drivers

Libo Chen (1):
  max8925_power: Fix missing of_node_put

Loc Ho (1):
  power: Add APM X-Gene system reboot driver

Marek Belisko (3):
  rx51_battery: Replace hardcoded channels values.
  power: Add twl4030_madc battery driver.
  rx51_battery: Fix channel number when reading adc value

Mark A. Greer (1):
  bq24190_charger: Add support for TI BQ24190 Battery Charger

Paul Gortmaker (1):
  power_supply: Make goldfish_battery depend on GOLDFISH || COMPILE_TEST

Pawel Moll (1):
  vexpress-poweroff: Should depend on the required infrastructure

Peter Ujfalusi (1):
  twl4030-charger: Fix compiler warning with regulator_enable()

Zoran Markovic (1):
  power_supply: Prevent suspend until power supply events are processed

 .../bindings/power_supply/msm-poweroff.txt |   17 +
 MAINTAINERS|8 +
 drivers/power/Kconfig  |   15 +-
 drivers/power/Makefile |2 +
 drivers/power/ab8500_charger.c |1 +
 drivers/power/bq24190_charger.c| 1549 
 drivers/power/collie_battery.c |2 +-
 drivers/power/max8925_power.c  |1 +
 drivers/power/power_supply_core.c  |   38 +-
 drivers/power/power_supply_sysfs.c |2 +-
 drivers/power/reset/Kconfig|   15 +-
 drivers/power/reset/Makefile   |2 +
 drivers/power/reset/msm-poweroff.c |   73 +
 drivers/power/reset/xgene-reboot.c |  103 ++
 drivers/power/rx51_battery.c   |   14 +-
 drivers/power/tosa_battery.c   |2 +-
 drivers/power/twl4030_charger.c|7 +-
 drivers/power/twl4030_madc_battery.c   |  245 
 include/linux/power/bq24190_charger.h  |   16 +
 include/linux/power/twl4030_madc_battery.h |   39 +
 include/linux/power_supply.h   |3 +
 21 files changed, 2137 insertions(+), 17 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/power_supply/msm-poweroff.txt
 create mode 100644 drivers/power/bq24190_charger.c
 create mode 100644 drivers/power/reset/msm-poweroff.c
 create mode 100644 drivers/power/reset/xgene-reboot.c
 create mode 100644 drivers/power/twl4030_madc_battery.c
 create mode 100644 include/linux/power/bq24190_charger.h
 create mode 100644 include/linux/power/twl4030_madc_battery.h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] power: rx51_battery: Replace hardcoded channels values.

2013-08-30 Thread Anton Vorontsov
> This issue was introduced in commit:
> power: rx51_battery: Replace hardcoded channels values.
> 
> Original code use channel as argument which was shifted by one in function.
> After mentioned commit argument is already shifted so we need to get index
> back.
> 
> Signed-off-by: Marek Belisko 

Applied, thanks!

> ---
>  drivers/power/rx51_battery.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/power/rx51_battery.c b/drivers/power/rx51_battery.c
> index 03f5761..1bc5857 100644
> --- a/drivers/power/rx51_battery.c
> +++ b/drivers/power/rx51_battery.c
> @@ -51,7 +51,7 @@ static int rx51_battery_read_adc(int channel)
>   if (twl4030_madc_conversion(&req) <= 0)
>   return -ENODATA;
> 
> - return req.rbuf[channel];
> + return req.rbuf[ffs(channel) - 1];
>  }
> 
>  /*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 33/35] power: use dev_get_platdata()

2013-08-28 Thread Anton Vorontsov
On Wed, Aug 28, 2013 at 07:07:14PM -0700, 'Greg Kroah-Hartman' wrote:
> On Wed, Aug 28, 2013 at 06:18:49PM -0700, Anton Vorontsov wrote:
> > On Wed, Aug 28, 2013 at 11:36:30AM +0300, Dan Carpenter wrote:
> > > He doesn't want to take the patch.  He's the maintainer so it's his
> > > choice.  That's the end of the story.
> > 
> > Just to clarify: I don't want to take the patch for a reason, not just
> > because of my mood today. Once the patch comes in combination with another
> > patch (or a plan) that actually makes use of the wrapper function, then
> > I'd happily apply/ack it.
> > 
> > This is the same story as global checkpatch.pl fixes: they are more harm
> > than good, and without the actual use of the dev_get_platdata(), the patch
> > falls into "global checkpatch.pl fixes" category.
> 
> If you view this as a checkpatch.pl fixup

As a standalone patch I view it as a checkpatch.pl fixup.

Even the author of the patch seem to agree:

| On Thu, Aug 29, 2013 at 11:14:37AM +0900, Jingoo Han wrote:
| > This patch is a just cosmetic change.

And indeed I am against massive "just cosmetic" changes.

These changes not so much burden for me personally (it was actually easier
for me to just apply the patch without all the arguing), but for those who
actually do real bugfixes/features in the drivers: their local development
trees will produce conflicts. Solving the trivial conflicts not a problem
either, but irritating (especially realizing that you waste time resolving
conflicts because of the "just cosmetic" crap).

These days I don't code that much, but I was in that boat resolving
"cosmetic" conflicts, and I did not like it. So I'm trying to solve the
issue for drivers/power/ developers.

Thanks,

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


[PATCH] of/irq: Provide struct device_node forward-declaration for !OF case

2013-08-28 Thread Anton Vorontsov
The patch fixes the following warnings:

  CC  drivers/power/bq24190_charger.o
  In file included from drivers/power/bq24190_charger.c:14:0:
  include/linux/of_irq.h:82:7: warning: ‘struct device_node’ declared
  inside parameter list [enabled by default]
  include/linux/of_irq.h:82:7: warning: its scope is only this definition
  or declaration, which is probably not what you want [enabled by default]
  include/linux/of_irq.h:87:118: warning: ‘struct device_node’ declared
  inside parameter list [enabled by default]

Signed-off-by: Anton Vorontsov 
---
 include/linux/of_irq.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/linux/of_irq.h b/include/linux/of_irq.h
index 535cecf..988d5c9 100644
--- a/include/linux/of_irq.h
+++ b/include/linux/of_irq.h
@@ -78,6 +78,9 @@ extern void of_irq_init(const struct of_device_id *matches);
 #endif /* CONFIG_OF_IRQ */
 
 #else /* !CONFIG_OF */
+
+struct device_node;
+
 static inline unsigned int irq_of_parse_and_map(struct device_node *dev,
int index)
 {
-- 
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 33/35] power: use dev_get_platdata()

2013-08-28 Thread Anton Vorontsov
On Wed, Aug 28, 2013 at 11:36:30AM +0300, Dan Carpenter wrote:
> He doesn't want to take the patch.  He's the maintainer so it's his
> choice.  That's the end of the story.

Just to clarify: I don't want to take the patch for a reason, not just
because of my mood today. Once the patch comes in combination with another
patch (or a plan) that actually makes use of the wrapper function, then
I'd happily apply/ack it.

This is the same story as global checkpatch.pl fixes: they are more harm
than good, and without the actual use of the dev_get_platdata(), the patch
falls into "global checkpatch.pl fixes" category.

Thanks,

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


Re: [PATCH 33/35] power: use dev_get_platdata()

2013-08-27 Thread Anton Vorontsov
On Tue, Aug 13, 2013 at 12:00:39PM +0300, Dan Carpenter wrote:
> > > > Use the wrapper function for retrieving the platform data instead of
> > > > accessing dev->platform_data directly.
> > > 
> > > Um.. what is the benefit or rationale of this patch?
> > 
> > CC'ed Joe Perches, Dan Carpenter
> > 
> > Hi Anton Vorontsov,
> > 
> > Usually, using the wrapper function makes the code simpler.
> > Also, it make the code more readable.
> 
> Since people are asking my opinion, then yes using
> dev_get_platdata() as intended is better than open coding.  It's a
> coding standard thing.

I don't see any immediate benefit of applying this patch... It does not
fix anything now or in the near future (or we are about to add something
into dev_get_platdata() wrapper, or get rid of dev.platform_data member?
Any plans for this? Then it should be in the commit message.)

Without any plans to actually use the wrapper the patch is just a churn
[that might result into patch conflicts that I'll have to deal with], so
I'll refrain from applying it.

Thanks,

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


Re: [RFC PATCH] pm: prevent suspend until power supply events are processed

2013-08-27 Thread Anton Vorontsov
On Fri, Aug 02, 2013 at 01:38:02PM -0700, Zoran Markovic wrote:
> This patch, originally authored by Arve Hjonnevag and Todd Poynor,
> prevents the system from entering suspend mode until the power
> supply plug, unplug, or any other change of state event is fully
> processed. This guarantees that the screen lights up and displays
> the battery charging state. The implementation uses the power
> supply wakeup_source object.
> 
> Cc: Anton Vorontsov 
> Cc: David Woodhouse 
> Cc: Arve Hjonnevag 
> Cc: Todd Poynor 
> Cc: John Stultz 
> Signed-off-by: Zoran Markovic 
> ---
...
> + kobject_uevent(&psy->dev->kobj, KOBJ_CHANGE);
> + spin_lock_irqsave(&psy->changed_lock, flags);
> + }
> + /* dependent power supplies (e.g. battery) may have changed

Multi-line comments style issue...

> +  * state as a result of this event, so poll again and hold
> +  * the wakeup_source until all events are processed.
> +  */
> + if (!psy->changed)
> + pm_relax(psy->dev);
...
> diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
> index 804b906..253d412 100644
> --- a/include/linux/power_supply.h
> +++ b/include/linux/power_supply.h
> @@ -194,6 +194,8 @@ struct power_supply {
>   /* private */
>   struct device *dev;
>   struct work_struct changed_work;
> + spinlock_t changed_lock;

#include  is needed.

I fixed it up and applied the patch, thanks a lot!

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


Re: [PATCH] power/reset: Make vexpress driver depend on required infrastructure

2013-08-27 Thread Anton Vorontsov
On Thu, Aug 15, 2013 at 04:35:52PM +0100, Pawel Moll wrote:
> ARM Versatile Express reset driver requires platform-specific
> config infrastructure to be present in the kernel. When
> VEXPRESS_CONFIG is not selected, the build will fail like this:
> 
> drivers/built-in.o: In function `vexpress_reset_do.clone.0':
> iio-trig-interrupt.c:(.text+0x1aff38): undefined reference to 
> `__vexpress_config_func_get'
> iio-trig-interrupt.c:(.text+0x1aff4c): undefined reference to 
> `vexpress_config_write'
> 
> Added required dependency to the Kconfig entry.
> 
> Signed-off-by: Pawel Moll 

Applied, thanks!

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


Re: [PATCH] power: twl4030-charger: Fix compiler warning with regulator_enable()

2013-08-27 Thread Anton Vorontsov
On Wed, Aug 21, 2013 at 11:31:37AM +0300, Peter Ujfalusi wrote:
> The return value of regulator_enable need to be checked. This patch fixes
> the following warning:
> drivers/power/twl4030_charger.c: In function ‘twl4030_charger_enable_usb’:
> drivers/power/twl4030_charger.c:192:20: warning: ignoring return value of 
> ‘regulator_enable’, declared with attribute warn_unused_result 
> [-Wunused-result]
> 
> Signed-off-by: Peter Ujfalusi 

Applied, thanks a lot!

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


Re: [PATCH] power: rx51_battery: Replace hardcoded channels values.

2013-08-27 Thread Anton Vorontsov
On Thu, Aug 22, 2013 at 12:45:10AM +0200, Marek Belisko wrote:
> In twl4030_madc header exist defines for fixed channels
> + add rx51 specific channels and replace all hardcoded channels
> values.
> 
> Signed-off-by: Marek Belisko 

Applied, thanks!

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


Re: [PATCH v2] bq24190_charger: Add support for TI BQ24190 Battery Charger

2013-08-27 Thread Anton Vorontsov
On Fri, Aug 23, 2013 at 07:21:03PM -0700, Mark A. Greer wrote:
> Add driver support for the Texas Instruments BQ24190
> battery charger.  Some of the information provided by
> the device is about the charger and other information
> is about the battery so create two power_supply objects
> (one for each) and provide the appropriate information
> for each one.
> 
> The device has many fields that go beyond what is
> reasonable to report or modify using the existing
> 'POWER_SUPPLY_PROP_*' properties so the driver exports
> the register fields via sysfs.  They are prefixed by
> 'f_' (for 'field') to make it easier to distinguish
> between a register field and a "normal" sysfs file
> exported by the power_supply infrastructure.
> 
> Signed-off-by: Mark A. Greer 
> ---

Applied, thanks a lot!

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


Re: [PATCH] power: max8925: fix missing of_node_put

2013-08-27 Thread Anton Vorontsov
On Mon, Aug 26, 2013 at 03:06:36PM +0800, Libo Chen wrote:
> 
> decrease np device_node refcount after task completion
> 
> Signed-off-by: Libo Chen 

Applied, thanks!

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


Re: [PATCH 3/3] power_supply: add throttle state

2013-08-09 Thread Anton Vorontsov
On Sun, Jul 14, 2013 at 11:08:15PM +0530, Jenny TC wrote:
> The charger and battery temperature contribute to the
> platform thermal. The only way to control the temperature
> is to control the charging. The charging can be controlled in different
> way. This could be disabling charger, disabling charging, adjusting CC,
> or by adjusting the INLMT. This patch adds a structure to define the
> charger throttle actions. Also this patch adds a throttle_states
> field to the struct power_supply which can be used by the charger
> driver to define it's throttle actions for different states
> 
> Signed-off-by: Jenny TC 
> ---

The code itself is OK. But for this and the previous patches I'd like to
see at least one user before merging it, i.e. I'd like to see how things
actually interact...

>  include/linux/power_supply.h |   15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
> index 5a24e10..516e4c4 100644
> --- a/include/linux/power_supply.h
> +++ b/include/linux/power_supply.h
> @@ -209,6 +209,18 @@ union power_supply_propval {
>  
>  struct device_node;
>  
> +enum psy_throttle_action {
> +

Stray empty line here.

> + PSY_THROTTLE_DISABLE_CHARGER = 0,
> + PSY_THROTTLE_DISABLE_CHARGING,
> + PSY_THROTTLE_CC_LIMIT,

CHG_CUR?

> + PSY_THROTTLE_INPUT_LIMIT,
> +};
> +
> +struct psy_throttle_state {
> + enum psy_throttle_action throttle_action;
> + unsigned throttle_val;
> +};

Missing empty line here.

>  struct power_supply {
>   const char *name;
>   enum power_supply_type type;
> @@ -223,6 +235,9 @@ struct power_supply {
>   size_t num_supplies;
>   struct device_node *of_node;
>  
> + struct psy_throttle_state *throttle_states;
> + size_t num_throttle_states;
> +
>   int (*get_property)(struct power_supply *psy,
>   enum power_supply_property psp,
>   union power_supply_propval *val);
> -- 
> 1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 1/3] power_supply: Add charger control properties

2013-08-09 Thread Anton Vorontsov
On Sun, Jul 14, 2013 at 11:07:45PM +0530, Jenny TC wrote:
> The battery charger needs to have control path along
> with the reporting charger properties. In existing solutions
> this is implemented using regulator framework. A regulator
> framework doesn't fit a charger driver requirement because of the
> following reason
> Charger needs support two paths - charger path (charger to platform)
> and charging (charger to battery).Disabling the charging path alone
> (eg over battery temperature) will allow the platform to work with
> power from charger without discharging the battery. And the charger
> may need to be disabled completely based on the charger temperature
> or the platform temperature. Charger has more than one pair of
> voltage/current to control (CC,CV,INLMT).These features will not
> directly fit in the regulator framework. Since the charger driver
> sits in the power supply subsystem it make sense to add the properties
> to control the charger.
> 
> Signed-off-by: Jenny TC 
> ---

The patch is missing Documentation/ part for the new properties...

>  drivers/power/power_supply_sysfs.c |8 
>  include/linux/power_supply.h   |8 
>  2 files changed, 16 insertions(+)
> 
> diff --git a/drivers/power/power_supply_sysfs.c 
> b/drivers/power/power_supply_sysfs.c
> index 29178f7..643971c 100644
> --- a/drivers/power/power_supply_sysfs.c
> +++ b/drivers/power/power_supply_sysfs.c
> @@ -167,6 +167,7 @@ static struct device_attribute power_supply_attrs[] = {
>   POWER_SUPPLY_ATTR(constant_charge_voltage_max),
>   POWER_SUPPLY_ATTR(charge_control_limit),
>   POWER_SUPPLY_ATTR(charge_control_limit_max),
> + POWER_SUPPLY_ATTR(input_cur_limit),
>   POWER_SUPPLY_ATTR(energy_full_design),
>   POWER_SUPPLY_ATTR(energy_empty_design),
>   POWER_SUPPLY_ATTR(energy_full),
> @@ -178,6 +179,8 @@ static struct device_attribute power_supply_attrs[] = {
>   POWER_SUPPLY_ATTR(capacity_alert_max),
>   POWER_SUPPLY_ATTR(capacity_level),
>   POWER_SUPPLY_ATTR(temp),
> + POWER_SUPPLY_ATTR(max_temp),
> + POWER_SUPPLY_ATTR(min_temp),
>   POWER_SUPPLY_ATTR(temp_alert_min),
>   POWER_SUPPLY_ATTR(temp_alert_max),
>   POWER_SUPPLY_ATTR(temp_ambient),
> @@ -189,6 +192,11 @@ static struct device_attribute power_supply_attrs[] = {
>   POWER_SUPPLY_ATTR(time_to_full_avg),
>   POWER_SUPPLY_ATTR(type),
>   POWER_SUPPLY_ATTR(scope),
> + POWER_SUPPLY_ATTR(charge_term_cur),
> + POWER_SUPPLY_ATTR(enable_charging),
> + POWER_SUPPLY_ATTR(enable_charger),
> + POWER_SUPPLY_ATTR(cable_type),
> + POWER_SUPPLY_ATTR(priority),
>   /* Properties of type `const char *' */
>   POWER_SUPPLY_ATTR(model_name),
>   POWER_SUPPLY_ATTR(manufacturer),
> diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
> index 804b906..1265131 100644
> --- a/include/linux/power_supply.h
> +++ b/include/linux/power_supply.h
> @@ -118,6 +118,7 @@ enum power_supply_property {
>   POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE_MAX,
>   POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT,
>   POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT_MAX,
> + POWER_SUPPLY_PROP_INLMT,

Kinda cryptic...

You wrote a great explanation here:

http://lkml.indiana.edu/hypermail/linux/kernel/1207.0/00050.html

Why don't just copy-paste it into Documentation? :)

>   POWER_SUPPLY_PROP_ENERGY_FULL_DESIGN,
>   POWER_SUPPLY_PROP_ENERGY_EMPTY_DESIGN,
>   POWER_SUPPLY_PROP_ENERGY_FULL,
> @@ -129,6 +130,8 @@ enum power_supply_property {
>   POWER_SUPPLY_PROP_CAPACITY_ALERT_MAX, /* in percents! */
>   POWER_SUPPLY_PROP_CAPACITY_LEVEL,
>   POWER_SUPPLY_PROP_TEMP,
> + POWER_SUPPLY_PROP_MAX_TEMP,
> + POWER_SUPPLY_PROP_MIN_TEMP,
>   POWER_SUPPLY_PROP_TEMP_ALERT_MIN,
>   POWER_SUPPLY_PROP_TEMP_ALERT_MAX,
>   POWER_SUPPLY_PROP_TEMP_AMBIENT,
> @@ -140,6 +143,11 @@ enum power_supply_property {
>   POWER_SUPPLY_PROP_TIME_TO_FULL_AVG,
>   POWER_SUPPLY_PROP_TYPE, /* use power_supply.type instead */
>   POWER_SUPPLY_PROP_SCOPE,
> + POWER_SUPPLY_PROP_CHARGE_TERM_CUR,
> + POWER_SUPPLY_PROP_ENABLE_CHARGING,
> + POWER_SUPPLY_PROP_ENABLE_CHARGER,
> + POWER_SUPPLY_PROP_CABLE_TYPE,
> + POWER_SUPPLY_PROP_PRIORITY,
>   /* Properties of type `const char *' */
>   POWER_SUPPLY_PROP_MODEL_NAME,
>   POWER_SUPPLY_PROP_MANUFACTURER,
> -- 
> 1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 2/2] drivers: power: Add support for BATTERY_ARIESVE

2013-08-09 Thread Anton Vorontsov
On Wed, Jul 24, 2013 at 04:27:10PM +0200, Balint Czobor wrote:
> Add initial support for the battery in Samsung ARIESVE.
> 
> Signed-off-by: Balint Czobor 
> ---
>  arch/arm/mach-msm/include/mach/msm_battery.h   |   31 +
>  arch/arm/mach-msm/include/mach/msm_rpcrouter.h |  376 
>  drivers/power/Kconfig  |   14 +
>  drivers/power/Makefile |1 +
>  drivers/power/ariesve_battery.c| 2710 
> 
>  drivers/power/fuelgauge_max17043.c |  434 
>  drivers/power/power_supply_sysfs.c |   19 +-
>  include/linux/earlysuspend.h   |   56 +
>  include/linux/leds-pmic8058.h  |   40 +
>  include/linux/mfd/pm8xxx/batt-alarm.h  |  201 ++
>  include/linux/mfd/pm8xxx/gpio.h|  162 ++
>  include/linux/mfd/pm8xxx/misc.h|  284 +++
>  include/linux/mfd/pm8xxx/mpp.h |  263 +++
>  include/linux/mfd/pm8xxx/nfc.h |   79 +
>  include/linux/mfd/pm8xxx/tm.h  |   42 +
>  include/linux/mfd/pm8xxx/upl.h |   65 +
>  include/linux/mfd/pm8xxx/vibrator.h|   39 +
>  include/linux/mfd/pmic8058.h   |  137 ++
>  include/linux/pmic8058-othc.h  |  146 ++
>  include/linux/pmic8058-pwm.h   |  148 ++
>  include/linux/pmic8058-xoadc.h |  121 ++
>  include/linux/power_supply.h   |   13 +-
>  include/linux/regulator/pm8058-xo.h|   31 +
>  include/linux/regulator/pmic8058-regulator.h   |   89 +
>  include/linux/wakelock.h   |   90 +

Thanks for the driver! There are a lot of issues with the patch, though.

Most of the header files are not needed for this driver. The patch should
also be split into several parts (i.e. power_supply_sysfs.c changes should
be aside). In the patch there is a lot of dead (commented-out) code and
code that completely violates Linux coding standards.

I would say that for now, drivers/staging/ is more appropriate place for
the driver. Meanwhile, be sure to read Documentation/CodingStyle and
Documentation/SubmittingPatches. And a special url about #ifdefs in .c
files, typedefs, etc.:

http://kroah.com/linux/talks/ols_2002_kernel_codingstyle_talk/html/

Thanks,

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


Re: [PATCH 33/35] power: use dev_get_platdata()

2013-08-09 Thread Anton Vorontsov
On Tue, Jul 30, 2013 at 05:19:27PM +0900, Jingoo Han wrote:
> Use the wrapper function for retrieving the platform data instead of
> accessing dev->platform_data directly.

Um.. what is the benefit or rationale of this patch?

Thanks,

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


Re: [PATCH] power: power: replace strict_strtol() with kstrtol()

2013-08-09 Thread Anton Vorontsov
On Fri, Jul 19, 2013 at 04:06:16PM +0900, Jingoo Han wrote:
> The usage of strict_strtol() is not preferred, because
> strict_strtol() is obsolete. Thus, kstrtol() should be
> used.
> 
> Signed-off-by: Jingoo Han 
> ---

Applied, thanks.

>  drivers/power/power_supply_sysfs.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/power/power_supply_sysfs.c 
> b/drivers/power/power_supply_sysfs.c
> index 29178f7..44420d1 100644
> --- a/drivers/power/power_supply_sysfs.c
> +++ b/drivers/power/power_supply_sysfs.c
> @@ -118,7 +118,7 @@ static ssize_t power_supply_store_property(struct device 
> *dev,
>   long long_val;
>  
>   /* TODO: support other types than int */
> - ret = strict_strtol(buf, 10, &long_val);
> + ret = kstrtol(buf, 10, &long_val);
>   if (ret < 0)
>   return ret;
>  
> -- 
> 1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] power supply: tosa_battery: get rid of irq_to_gpio usage

2013-08-09 Thread Anton Vorontsov
On Sun, Jul 21, 2013 at 01:07:46AM +0200, Andrea Adami wrote:
> Fix
> linux/drivers/power/tosa_battery.c:153:2: error: implicit declaration of
> function 'irq_to_gpio' [-Werror=implicit-function-declaration]
> |   pr_info("tosa_bat_gpio irq: %d\n",
> gpio_get_value(irq_to_gpio(irq)));
> 
> as done for collie_battery.c with
> commit 629bcb4b72d49b3631ae3dd0fe1d345820fadfcc
> 
> Since 9d08d5d77a355510c2f5657c86b0a4b25acfe72c, irq_to_gpio() is no
> longer available but still in use by collie_battery.c. As it's just
> for a debug message, just get rid of this call.
> 
> Signed-off-by: Andrea Adami 
> ---

Applied, thanks!

>  drivers/power/tosa_battery.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/power/tosa_battery.c b/drivers/power/tosa_battery.c
> index 0224de5..f4d80df 100644
> --- a/drivers/power/tosa_battery.c
> +++ b/drivers/power/tosa_battery.c
> @@ -150,7 +150,7 @@ static void tosa_bat_external_power_changed(struct 
> power_supply *psy)
>  
>  static irqreturn_t tosa_bat_gpio_isr(int irq, void *data)
>  {
> - pr_info("tosa_bat_gpio irq: %d\n", gpio_get_value(irq_to_gpio(irq)));
> + pr_info("tosa_bat_gpio irq\n");
>   schedule_work(&bat_work);
>   return IRQ_HANDLED;
>  }
> -- 
> 1.8.1.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] power supply: collie_battery: convert to use dev_pm_ops

2013-08-09 Thread Anton Vorontsov
On Sun, Jul 21, 2013 at 01:07:44AM +0200, Andrea Adami wrote:
> Fix
> linux/drivers/power/collie_battery.c:372:2: warning: initialization from
> incompatible pointer type [enabled by default]
> linux/drivers/power/collie_battery.c:372:2: warning: (near initialization
> for 'collie_bat_driver.suspend') [enabled by default]
> 
> Referencess:
> MFD: ucb1x00-core: convert to use dev_pm_ops
> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/include/linux/mfd?id=5a09b7120a965a7d7e8494d0ed509135bbce0118
> 
> MFD: mcp-core: remove legacy driver suspend/resume methods
> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/include/linux/mfd?id=cf4abfcc0df2985ff6061f74e63b8353f2a1d0bc
> 
> Signed-off-by: Andrea Adami 
> ---

Applied. Thanks a lot, Andrea!

>  drivers/power/collie_battery.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/power/collie_battery.c b/drivers/power/collie_battery.c
> index c58d0e3..d02ae02 100644
> --- a/drivers/power/collie_battery.c
> +++ b/drivers/power/collie_battery.c
> @@ -287,7 +287,7 @@ static struct gpio collie_batt_gpios[] = {
>  };
>  
>  #ifdef CONFIG_PM
> -static int collie_bat_suspend(struct ucb1x00_dev *dev, pm_message_t state)
> +static int collie_bat_suspend(struct ucb1x00_dev *dev)
>  {
>   /* flush all pending status updates */
>   flush_work(&bat_work);
> -- 
> 1.8.1.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 2/4] power: make goldfish_battery depend on GOLDFISH || COMPILE_TEST

2013-08-09 Thread Anton Vorontsov
On Thu, Jul 04, 2013 at 01:39:11AM -0400, Paul Gortmaker wrote:
> Nearly all the other goldfish peripherals (mtd, keyboard, etc)
> have a dependency on the main platform's GOLDFISH Kconfig item,
> but this one got skipped.  Even with consistency as a
> justification, there was initial resistance[1] from some people
> to adding it however, as they wanted the extra compile coverage.
> 
> Now, with CONFIG_COMPILE_TEST, we have the middle ground that
> will give people the coverage who want it, and let those who
> don't want it to skip ever seeing the option presented.
> 
> [1] https://lkml.org/lkml/2013/2/27/333
> 
> Cc: Anton Vorontsov 
> Cc: David Woodhouse 
> Cc: Jiri Slaby 
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Paul Gortmaker 
> ---

So, CONFIG_AKPM... kinda. :) It works for me. Applied, thank you!

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


Re: [PATCH] bq24190_charger: Add support for TI BQ24190 Battery Charger

2013-08-09 Thread Anton Vorontsov
On Wed, Aug 07, 2013 at 02:56:48PM -0700, Mark A. Greer wrote:
> Add driver support for the Texas Instruments BQ24190
> battery charger.  Some of the information provided by
> the device is about the charger and other information
> is about the battery so create two power_supply objects
> (one for each) and provide the appropriate information
> for each one.
> 
> The device has many fields that go beyond what is
> reasonable to report or modify using the existing
> 'POWER_SUPPLY_PROP_*' properties so the driver exports
> the register fields via sysfs.  They are prefixed by
> 'f_' (for 'field') to make it easier to distinguish
> between a register field and a "normal" sysfs file
> exported by the power_supply infrastructure.
> 
> Signed-off-by: Mark A. Greer 
> ---
...
> +static irqreturn_t bq24190_irq_handler_thread(int irq, void *data)
> +{
> + struct bq24190_dev_info *bdi = data;
> + bool alert_userspace = false;
> + u8 ss_reg, f_reg;
> + int ret;
> + static bool first_time = true;
...
> + /*
> +  * Sometimes bq24190 gives a steady trickle of interrupts even
> +  * though the watchdog timer is turned off and neither the STATUS
> +  * nor FAULT registers have changed.  Weed out these sprurious
> +  * interrupts so userspace isn't alerted for no reason.
> +  * In addition, the chip always generates an interrupt after
> +  * register reset so we should ignore that one (the very first
> +  * interrupt received).
> +  */
> + if (alert_userspace && !first_time) {

Hm, global static... I would guess that per-device flag would be more
appropriate, just in case if there are multiple chargers?

> + power_supply_changed(&bdi->charger);
> + power_supply_changed(&bdi->battery);
> + first_time = false;
> + }
...
> + do {
> + ret = bq24190_read_mask(bdi, BQ24190_REG_POC,
> + BQ24190_REG_POC_RESET_MASK,
> + BQ24190_REG_POC_RESET_SHIFT,
> + &v);
> + if ((ret <= 0) || !v)
> + break;
> +
> + udelay(10);
> + } while (--limit);
> +
> + if (!ret && limit)
> + ret = bq24190_set_mode_host(bdi);
> +out:
> + pm_runtime_put_sync(bdi->dev);
> + return ret;
> +}
> +
> +#define irq_to_gpio(irq) ((irq) - gpio_to_irq(0))

Ugh... this does not seem right. On a particular platform it might work,
but not in general...

Thanks,

Anton

p.s. I am also not a big fan of unnecessary 'out:' goto labels... most of
them might be changed to just 'return ...;'
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] power_supply: Add power_supply notifier

2013-08-09 Thread Anton Vorontsov
On Fri, Jul 26, 2013 at 12:51:09AM +0530, Jenny TC wrote:
> This patch adds a notifier chain to the power_supply.
> This notifier helps drivers in other subsystem to listen to
> changes in power supply subsystem. This would help to take some
> actions in those drivers on changing the power supply properties.
> One such scenario is to increase/decrease system performance based
> on the battery capacity/voltage. Another scenario is to adjust the
> h/w peak current detection voltage/current thresholds based on battery
> voltage/capacity. The notifier helps drivers to listen to changes
> in power_suppy susbystem without polling the power_supply properties
> 
> Signed-off-by: Jenny TC 
> ---

Hi Jenny,

Can you please submit users of this new API as well, so that we could see
the whole picture?

Thanks,

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


Re: [PATCH] drivers: power: reset: add msm restart support

2013-08-09 Thread Anton Vorontsov
On Tue, Jul 30, 2013 at 05:05:28PM -0700, Abhimanyu Kapur wrote:
> Add support for restart and poweroff functionality present on MSM
> chipsets with the MPM2 ps-hold hardware.
> 
> Signed-off-by: Abhimanyu Kapur 
> ---

Applied, thanks a lot!

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


Re: [PATCH] MAINTAINERS: drivers/power: add entry for SmartReflex AVS drivers

2013-08-09 Thread Anton Vorontsov
On Tue, Aug 06, 2013 at 04:57:14PM -0700, Kevin Hilman wrote:
> Subject: [PATCH] MAINTAINERS: drivers/power: add entry for SmartReflex AVS
>  drivers
> 
> The SmartReflex AVS driver evolved out of the OMAP kernel and now
> lives under drivers/power/avs.
> 
> I've historically been maintainer of this but Nishanth Menon is doing
> most of the heavy lifting now.  Add us both as co-maintainers.
> 
> Cc: Anton Vorontsov 
> Cc: David Woodhouse 
> Cc: Rafael J. Wysocki 
> Cc: Nishanth Menon 
> Signed-off-by: Kevin Hilman 
> ---
>  MAINTAINERS | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index defc053..93e9ba0 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6450,6 +6450,14 @@ S: Maintained
>  F:   include/linux/power_supply.h
>  F:   drivers/power/
>  
> +SMARTREFLEX DRIVERS FOR ADAPTIVE VOLTAGE SCALING (AVS)
> +M:   Kevin Hilman 
> +M:   Nishanth Menon 
> +S:   Maintained
> +F:   drivers/power/avs/smartreflex.c
> +F:   include/linux/power/smartreflex.h
> +L:   linux...@vger.kernel.org
> +

The file should be alphabetically sorted... I fixed it up and applied the
patch.

Thanks!

Anton

>  PNP SUPPORT
>  M:   Rafael J. Wysocki 
>  M:   Bjorn Helgaas 
> -- 
> 1.8.3
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] MAINTAINERS: drivers/power: add entry for SmartReflex AVS drivers

2013-08-05 Thread Anton Vorontsov
On Mon, Aug 05, 2013 at 09:29:37AM -0700, Kevin Hilman wrote:
> The SmartReflex AVS driver evolved out of the OMAP kernel and now
> lives under drivers/power/avs.
> 
> I've historically been maintainer of this but Nishanth Menon is doing
> most of the heavy lifting now.  Add us both as co-maintainers.
> 
...
> +M:   Kevin Hilman 
> +M:   Nishanth Menon 
> +S:   Maintained
> +F:   drivers/power/avs/smartreflex.c
> +F:  include/linux/power/smartreflex.h

This line is borken (whitespaces).

> +L:   linux...@vger.kernel.org
> +
>  PNP SUPPORT
>  M:   Rafael J. Wysocki 
>  M:   Bjorn Helgaas 
> -- 
> 1.8.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[GIT PULL] battery-2.6.git

2013-07-08 Thread Anton Vorontsov
Hello Linus,

Please pull battery-2.6 git tree to receive changes prepared for the v3.11
release. This time there is nothing exciting in there, just assorted fixes
and cleanups.

Thanks!

Anton


The following changes since commit d683b96b072dc4680fc74964eca77e6a23d1fa6e:

  Linux 3.10-rc4 (2013-06-02 17:11:17 +0900)

are available in the git repository at:

  git://git.infradead.org/battery-2.6.git tags/for-v3.11

for you to fetch changes up to 5a6c2208455f25b3e6f939adc2da59aa00d4806e:

  charger-manager: Fix regulator_get() return check (2013-06-28 18:37:03 -0700)


Andrew Chew (1):
  tps65090-charger: Fix AC detect

Anton Vorontsov (2):
  MAINTAINERS: Update email address for Anton Vorontsov
  power_supply: Move of_node out of the #ifdef CONFIG_OF

Axel Lin (3):
  pm2301_charger: Fix NULL pointer dereference
  pm2301_charger: Return error if create_singlethread_workqueue fails
  generic-adc-battery: Fix checking if none of the channels are supported

Jingoo Han (10):
  88pm860x_battery: Remove unnecessary platform_set_drvdata()
  88pm860x_charger: Remove unnecessary platform_set_drvdata()
  ab8500_bm: Remove unnecessary platform_set_drvdata()
  bq27x00_battery: Remove unnecessary platform_set_drvdata()
  gpio-charger: Remove unnecessary platform_set_drvdata()
  jz4740-battery: Remove unnecessary platform_set_drvdata()
  rx51_battery: Remove unnecessary platform_set_drvdata()
  twl4030_charger: Remove unnecessary platform_set_drvdata()
  power: Use platform_{get,set}_drvdata()
  power_supply: Replace strict_strtoul() with kstrtoul()

Joe Perches (1):
  charger-manager: Add missing newlines, fix a couple of typos, add pr_fmt

Jonghwa Lee (2):
  charger-manager: Fix a bug when it unregisters notifier block of extcon
  charger-manager: Fix regulator_get() return check

Kees Cook (1):
  charger-manager: Ensure event is not used as format string

Kim, Milo (1):
  lp8727_charger: Support the device tree feature

Pawel Moll (1):
  power/reset: Make the vexpress driver optional on arm and arm64

Rhyland Klein (3):
  power_supply: Add of_node_put to fix refcount
  sbs-battery: Add dt to power_supply struct
  tps65090-charger: Add dt node to power_supply

 .../bindings/power_supply/lp8727_charger.txt   |  44 +++
 MAINTAINERS|   8 +-
 drivers/power/88pm860x_battery.c   |   1 -
 drivers/power/88pm860x_charger.c   |   1 -
 drivers/power/ab8500_btemp.c   |   1 -
 drivers/power/ab8500_charger.c |   2 -
 drivers/power/ab8500_fg.c  |   7 +-
 drivers/power/abx500_chargalg.c|   1 -
 drivers/power/bq27x00_battery.c|   2 -
 drivers/power/charger-manager.c| 146 +
 drivers/power/generic-adc-battery.c|   4 +-
 drivers/power/gpio-charger.c   |   2 -
 drivers/power/intel_mid_battery.c  |   2 +-
 drivers/power/jz4740-battery.c |   4 +-
 drivers/power/lp8727_charger.c |  68 ++
 drivers/power/pcf50633-charger.c   |   8 +-
 drivers/power/pm2301_charger.c |  11 +-
 drivers/power/power_supply_core.c  |   4 +
 drivers/power/reset/Kconfig|   3 +-
 drivers/power/rx51_battery.c   |   5 +-
 drivers/power/sbs-battery.c|   1 +
 drivers/power/tps65090-charger.c   |  40 +-
 drivers/power/twl4030_charger.c|   2 -
 include/linux/power_supply.h   |   4 +-
 24 files changed, 241 insertions(+), 130 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/power_supply/lp8727_charger.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v2] vmpressure: implement strict mode

2013-07-02 Thread Anton Vorontsov
On Tue, Jul 02, 2013 at 10:59:11AM -0400, Luiz Capitulino wrote:
>  2. Considering the interface can be extended, how can new applications
> work on backwards mode? Say, we add ultra-critical on 3.12 and
> I update my application to work on it, how will my application
> work on 3.11?

It will refuse to run, as expected. We are returning -EINVAL on unknown
levels. The same way you try to run e.g. systemd on linux-2.4. Systemd
requires new features of the kernel, if there are no features present the
kernel returns an error and then app gracefully fails.

> Hint: Try and error is an horribly bad approach.
> 
>  3. I also don't believe we have good forward compatibility with
> the current API, as adding new events will cause existing ones
> to be triggered more often,

If they don't register for the new events (the old apps don't know about
them, so they won't), there will be absolutely no difference in the
behaviour, and that is what is most important.

There is a scalability problem I can see because of the need of the read()
call on each fd, but the "scalability" problem will actually arise if we
have insane number of levels.

> Honestly, what Andrew suggested is the best design for me: apps
> are notified on all events but the event name is sent to the application.

I am fine with this approach (or any other, I'm really indifferent to the
API itself -- read/netlink/notification per file/whatever for the
payload), except that you still have the similar problem:

  read() oldread() new
  --
   "low"   "low"
   "low"   "foo" -- the app does not know what does this mean
   "med"   "bar" -- ditto
   "med"   "med"

> This is pretty simple and solves all the problems we've discussed
> so far.
> 
> Why can't we just do it?

Because of the problems described above. Again, add versioning and there
will be no problem (but just the fact that we need for versioning for that
kind of interface might raise questions).

> > > > Here is more complicated case:
> > > > 
> > > > Old kernels, pressure_level reads:
> > > > 
> > > >   low, med, crit
> > > > 
> > > > The app just wants to listen for med level.
> > > > 
> > > > New kernels, pressure_level reads:
> > > > 
> > > >   low, FOO, med, BAR, crit
> > > > 
> > > > How would application decide which of FOO and BAR are ex-med levels?
> > > 
> > > What you meant by ex-med?
> > 
> > The scale is continuous and non-overlapping. If you add some other level,
> > you effectively "shrinking" other levels, so the ex-med in the list above
> > might correspond to "FOO, med" or "med, BAR" or "FOO, med, BAR", and that
> > is exactly the problem.
> 
> Just return the events in order?

The order is not a problem, the meaning is. The old app does not know the
meaning of FOO or BAR levels, for it is is literally "some foo" and "some
bar" -- it can't make any decision.

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


Re: [PATCH v2] vmpressure: implement strict mode

2013-07-01 Thread Anton Vorontsov
On Mon, Jul 01, 2013 at 05:22:36PM +0900, Hyunhee Kim wrote:
> >> > > for each event in memory.pressure_level; do
> >> > >   /* register eventfd to be notified on "event" */
> >> > > done
> >> >
> >> > This scheme registers "all" events.
> >>
> >> Yes, because I thought that's the user-case that matters for activity
> >> manager :)
> >
> > Some activity managers use only low levels (Android), some might use only
> > medium levels (simple load-balancing).
> 
> When the platform like Android uses only "low" level, is it the
> process you intended when designing vmpressure?
> 
> 1. activity manager receives "low" level events
> 2. it reads and checks the current memory (e.g. available memory) using vmstat
> 3. if the available memory is not under the threshold (defined e.g. by
> activity manager), activity manager does nothing
> 4. if the available memory is under the threshold, activity manager
> handles it by e.g. reclaiming or killing processes?

Yup, exactly.

> At first time when I saw this vmpressure, I thought that I should
> register all events ("low", "medium", and "critical
> ") and use different handler for each event. However, without the mode
> like strict mode, I should see too many events. So, now, I think that
> it is better to use only one level and run each handler after checking
> available memory as you mentioned.

Yup, this should work ideally.

> But,
> 
> 1. Isn't it overhead to read event and check memory state every time
> we receive events?

Even if it is an overhead, is it measurable? Plus, vmstat/memcg stats are
the only source of information that Activity Manager can use to make a
decision, so there is no point in duplicating the information in the
notifications.

> - sometimes, even when there are lots of available memory, low
> level event could occur if most of them is reclaimable memory not free
> pages.

The point of low level is to signal [any] reclaiming activity. So, yes, 

> - Don't most of platforms use available memory to judge their
> current memory state?

No, because you hardly want to monitor available memory only. You want to
take into account the level of the page caches, etc.

> Is there any reason vmpressure use reclaim rate?

Yes, you can refer to this email:

  http://lkml.org/lkml/2012/10/4/145

And here is about the levels thing:

  http://lkml.org/lkml/2012/10/22/177

> IMO, activity manager doesn't have to check available memory if it
> could receive signal based on the available memory.

But userspace can define its own policy of managing the tasks/resouces
based on different factors, other than just available memory. And that is
exactly why we don't filter the events in the kernel anymore. The only
filtering that we make is the levels, which, as it appears, can work for
many use-cases. 

> 2. If we use only "medium" to avoid the overheads occurred when using
> "low" level, isn't it possible to miss sending events when there is a
> little available memory but reclaim ratio is high?

If your app don't "trust" reclaim ratio idicator, then the application can
use its own heuristics, using low level just to monitor reclaiming
activity. More than that, you can change vmpressure itself to use
different heuristics for low/med/crit levels: the point of introducing
levels was also to hide the implementation and memory management details,
so if you can come up with a better approach for vmpressure "internals"
you are more than welcome to do so. :)

> IMHO, we cannot consider and cover all the use cases, but considering
> some use cases and giving some guides and directions to use this
> vmpressure will be helpful to make many platform accept this for their
> low memory manager.

Can't argue with that. :) I guess I will need to better document current
behavior of the levels and when exactly the events trigger.

Thanks!

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


Re: [PATCH -next] PM / AVS: SmartReflex: remove redundant dev_err call in omap_sr_probe()

2013-06-28 Thread Anton Vorontsov
On Wed, Jun 26, 2013 at 09:57:14AM +0800, Wei Yongjun wrote:
> From: Wei Yongjun 
> 
> There is a error message within devm_ioremap_resource
> already, so remove the dev_err call to avoid redundant
> error message.
> 
> Signed-off-by: Wei Yongjun 
> ---

The patch does not apply to the battery-2.6.git tree... :-/

(In the patch I see "sr_info", but in the current driver there is just
"sr".)

>  drivers/power/avs/smartreflex.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/power/avs/smartreflex.c b/drivers/power/avs/smartreflex.c
> index db9973b..c26acfc 100644
> --- a/drivers/power/avs/smartreflex.c
> +++ b/drivers/power/avs/smartreflex.c
> @@ -871,10 +871,8 @@ static int __init omap_sr_probe(struct platform_device 
> *pdev)
>  
>   mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>   sr_info->base = devm_ioremap_resource(&pdev->dev, mem);
> - if (IS_ERR(sr_info->base)) {
> - dev_err(&pdev->dev, "%s: ioremap fail\n", __func__);
> + if (IS_ERR(sr_info->base))
>   return PTR_ERR(sr_info->base);
> - }
>  
>   irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
>  
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v2] power: charger-manager: regulator_get() never returns NULL.

2013-06-28 Thread Anton Vorontsov
On Tue, Jun 25, 2013 at 02:54:17PM +0900, Chanwoo Choi wrote:
> Acked-by: Chanwoo Choi 
> 
> > This patch fixes return value checking of regulator_get() in
> > charger-manager
> > driver. The API, regulator_get(), returns ERR_PTR() when it fails to get
> > regulator with given name, not NULL.
> >
> > Signed-off-by: Jonghwa Lee 
> > Signed-off-by: Myungjoo Ham 

1/2 v2 and 2/2 applied.

Thanks!

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


Re: [PATCH 1/4] power_supply: Add of_node_put to fix refcount

2013-06-28 Thread Anton Vorontsov
On Mon, Jun 10, 2013 at 05:26:39PM -0400, Rhyland Klein wrote:
> of_parse_phandle increments the refcount for a dt node before returning
> it. Add of_node_put where needed to properly decrement the refcount
> when we are done using a given node.
> 
> Signed-off-by: Rhyland Klein 
> ---

With CONFIG_OF=n I got this:

  CC  drivers/power/sbs-battery.o
  drivers/power/sbs-battery.c: In function ‘sbs_probe’:
  drivers/power/sbs-battery.c:707:20: error: ‘struct power_supply’ has no
  member named ‘of_node’
  make[1]: *** [drivers/power/sbs-battery.o] Error 1

I fixed this by the patch below and applied your 1-3 series.

Thanks!

Anton

commit b50df95c8f0703c95625181d2eaf53855c5ebee5
Author: Anton Vorontsov 
Date:   Fri Jun 28 18:17:22 2013 -0700

power_supply: Move of_node out of the #ifdef CONFIG_OF

Similar to linux/device.h, move of_node struct member out of the #ifdef
CONFIG_OF so that the drivers won't have to mess with #ifdefs in .c files.
    
    Signed-off-by: Anton Vorontsov 

diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index 3828cef..804b906 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -162,6 +162,8 @@ union power_supply_propval {
const char *strval;
 };
 
+struct device_node;
+
 struct power_supply {
const char *name;
enum power_supply_type type;
@@ -173,9 +175,7 @@ struct power_supply {
 
char **supplied_from;
size_t num_supplies;
-#ifdef CONFIG_OF
struct device_node *of_node;
-#endif
 
int (*get_property)(struct power_supply *psy,
enum power_supply_property psp,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v2] vmpressure: implement strict mode

2013-06-28 Thread Anton Vorontsov
On Fri, Jun 28, 2013 at 03:44:02PM -0400, Luiz Capitulino wrote:
> > Why can't you use poll() and demultiplex the events? Check if there is an
> > event in the crit fd, and if there is, then just ignore all the rest.
> 
> This may be a valid workaround for current kernels, but application
> behavior will be different among kernels with a different number of
> events.

This is not a workaround, this is how poll works, and this is kinda
expected... But not that I had this plan in mind when I was designing the
current scheme... :)

> Say, we events on top of critical. Then crit fd will now be
> notified for cases where it didn't use to on older kernels.

I'm not sure I am following here... but thinking about it more, I guess
the extra read() will be needed anyway (to reset the counter).

> > > However, it *is* possible to make non-strict work on strict if we make
> > > strict default _and_ make reads on memory.pressure_level return
> > > available events. Just do this on app initialization:
> > > 
> > > for each event in memory.pressure_level; do
> > >   /* register eventfd to be notified on "event" */
> > > done
> > 
> > This scheme registers "all" events.
> 
> Yes, because I thought that's the user-case that matters for activity
> manager :)

Some activity managers use only low levels (Android), some might use only
medium levels (simple load-balancing).

Being able to register only "all" does not make sense to me.

> > Here is more complicated case:
> > 
> > Old kernels, pressure_level reads:
> > 
> >   low, med, crit
> > 
> > The app just wants to listen for med level.
> > 
> > New kernels, pressure_level reads:
> > 
> >   low, FOO, med, BAR, crit
> > 
> > How would application decide which of FOO and BAR are ex-med levels?
> 
> What you meant by ex-med?

The scale is continuous and non-overlapping. If you add some other level,
you effectively "shrinking" other levels, so the ex-med in the list above
might correspond to "FOO, med" or "med, BAR" or "FOO, med, BAR", and that
is exactly the problem.

> Let's not over-design. I agree that allowing the API to be extended
> is a good thing, but we shouldn't give complex meaning to events,
> otherwise we're better with a numeric scale instead.

I am not over-desiging at all. Again, you did not provide any solution for
the case if we are going to add a new level. Thing is, I don't know if we
are going to add more levels, but the three-levels scheme is not something
scientifically proven, it is just an arbitrary thing we made up. We may
end up with four, or five... or not.

Thanks,

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


Re: [PATCH v2] vmpressure: implement strict mode

2013-06-28 Thread Anton Vorontsov
On Fri, Jun 28, 2013 at 02:45:07PM -0400, Luiz Capitulino wrote:
> On Fri, 28 Jun 2013 10:09:17 -0700
> Anton Vorontsov  wrote:
> 
> > So, I would now argue that the current scheme is perfectly OK and can do
> > everything you can do with the "strict" one,
> 
> I forgot commenting this bit. This is not true, because I don't want a
> low fd to be notified on critical level. The current interface just
> can't do that.

Why can't you use poll() and demultiplex the events? Check if there is an
event in the crit fd, and if there is, then just ignore all the rest.

> However, it *is* possible to make non-strict work on strict if we make
> strict default _and_ make reads on memory.pressure_level return
> available events. Just do this on app initialization:
> 
> for each event in memory.pressure_level; do
>   /* register eventfd to be notified on "event" */
> done

This scheme registers "all" events. Here is more complicated case:

Old kernels, pressure_level reads:

  low, med, crit

The app just wants to listen for med level.

New kernels, pressure_level reads:

  low, FOO, med, BAR, crit

How would application decide which of FOO and BAR are ex-med levels?

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


Re: [PATCH v2] vmpressure: implement strict mode

2013-06-28 Thread Anton Vorontsov
On Fri, Jun 28, 2013 at 02:25:58PM -0400, Luiz Capitulino wrote:
> > > > That's how it's expected to work, because on strict mode you're notified
> > > > for the level you registered for. So apps registering for critical, will
> > > > still be notified on critical just like before.
> > > 
> > > Suppose you introduce a new level, and the system hits this level. Before,
> > > the app would receive at least some notification for the given memory load
> > > (i.e. one of the old levels), with the new level introduced in the kernel,
> > > the app will receive no events at all.
> 
> That's not true. If an app registered for critical it will still get
> critical notification when the system is at the critical level. Just as it
> always did. No new events will change this.
> 
> With today's semantics though, new events will change when current events
> are triggered. So each new extension will cause applications to have
> different behaviors, in different kernel versions. This looks quite
> undesirable to me.

I'll try to explain it again.

Old behaviour:

low -> event
  x <- but the system is at this unnamed level, between low and med
med
crit


We add a level:

low
low-med <- system at this state, we send an event, but the old app does
   not know about it, so it won't receive *any* notifications. (In
   older kernels it would receive low level notification
med
crit

You really don't see a problem here?

I see the problem, and I see these solutions:

1. Use current scheme.
2. Add versioning.
3. Never change the levels (how can we know?)

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


Re: [PATCH v2] vmpressure: implement strict mode

2013-06-28 Thread Anton Vorontsov
On Fri, Jun 28, 2013 at 09:57:22AM -0700, Anton Vorontsov wrote:
> On Fri, Jun 28, 2013 at 10:00:27AM -0400, Luiz Capitulino wrote:
> > On Thu, 27 Jun 2013 22:07:12 -0700
> > Anton Vorontsov  wrote:
> > 
> > > On Thu, Jun 27, 2013 at 09:34:11PM -0700, Anton Vorontsov wrote:
> > > > ... we can add the strict mode and deprecate the
> > > > "filtering" -- basically we'll implement the idea of requiring that
> > > > userspace registers a separate fd for each level.
> > > 
> > > Btw, assuming that more levels can be added, there will be a problem:
> > > imagine that an app hooked up onto low, med, crit levels in "strict"
> > > mode... then once we add a new level, the app will start missing the new
> > > level events.
> > 
> > That's how it's expected to work, because on strict mode you're notified
> > for the level you registered for. So apps registering for critical, will
> > still be notified on critical just like before.
> 
> Suppose you introduce a new level, and the system hits this level. Before,
> the app would receive at least some notification for the given memory load
> (i.e. one of the old levels), with the new level introduced in the kernel,
> the app will receive no events at all. This makes a serious behavioural
> change in the app (read: it'll break it).

Btw, why exactly you need the strict mode? Why 'medium' won't work for the
load-balancing? If you want some special logic for the critical level in
addition to the load-balancing, then you can hook into medium and critical
in the current scheme, and it will be an equivalent, except that you will
still be receiving 'medium' events, which you can filter out in userland.

You don't even need additional syscalls -- you don't have to read from the
medium-level eventfd if poll() returned events from the critical-level
eventfd.

So, I would now argue that the current scheme is perfectly OK and can do
everything you can do with the "strict" one, except that the old one is
better, as it handles backwards-compatibility in a nice way. :)

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


Re: [PATCH v2] vmpressure: implement strict mode

2013-06-28 Thread Anton Vorontsov
On Fri, Jun 28, 2013 at 10:00:27AM -0400, Luiz Capitulino wrote:
> On Thu, 27 Jun 2013 22:07:12 -0700
> Anton Vorontsov  wrote:
> 
> > On Thu, Jun 27, 2013 at 09:34:11PM -0700, Anton Vorontsov wrote:
> > > ... we can add the strict mode and deprecate the
> > > "filtering" -- basically we'll implement the idea of requiring that
> > > userspace registers a separate fd for each level.
> > 
> > Btw, assuming that more levels can be added, there will be a problem:
> > imagine that an app hooked up onto low, med, crit levels in "strict"
> > mode... then once we add a new level, the app will start missing the new
> > level events.
> 
> That's how it's expected to work, because on strict mode you're notified
> for the level you registered for. So apps registering for critical, will
> still be notified on critical just like before.

Suppose you introduce a new level, and the system hits this level. Before,
the app would receive at least some notification for the given memory load
(i.e. one of the old levels), with the new level introduced in the kernel,
the app will receive no events at all. This makes a serious behavioural
change in the app (read: it'll break it).

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


Re: [PATCH v2] vmpressure: implement strict mode

2013-06-27 Thread Anton Vorontsov
On Thu, Jun 27, 2013 at 09:34:11PM -0700, Anton Vorontsov wrote:
> ... we can add the strict mode and deprecate the
> "filtering" -- basically we'll implement the idea of requiring that
> userspace registers a separate fd for each level.

Btw, assuming that more levels can be added, there will be a problem:
imagine that an app hooked up onto low, med, crit levels in "strict"
mode... then once we add a new level, the app will start missing the new
level events.

In the old scheme it is not a problem because of the >= condition.

With a proper versioning this won't be a problem for a new scheme too.

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


Re: [PATCH v2] vmpressure: implement strict mode

2013-06-27 Thread Anton Vorontsov
On Thu, Jun 27, 2013 at 06:13:53PM -0700, Andrew Morton wrote:
> On Thu, 27 Jun 2013 17:58:53 -0700 Anton Vorontsov  wrote:
> > Current frequency is 1/(2MB). Suppose we ended up scanning the whole
> > memory on a 2GB host, this will give us 1024 hits. Doesn't feel too much*
> > to me... But for what it worth, I am against adding read() to the
> > interface -- just because we can avoid the unnecessary switch into the
> > kernel.
> 
> What was it they said about premature optimization?
> 
> I think I'd rather do nothing than add a mode hack (already!).
> 
> The information Luiz wants is already available with the existing
> interface, so why not just use it until there is a real demonstrated
> problem?
> 
> But all this does point at the fact that the chosen interface was not a
> good one.  And it's happening so soon :( A far better interface would
> be to do away with this level filtering stuff in the kernel altogether.

OK, I am convinced that modes might be not necessary, but I see no big
problem in current situation, we can add the strict mode and deprecate the
"filtering" -- basically we'll implement the idea of requiring that
userspace registers a separate fd for each level.

As one of the ways to change the interface, we can do the strict mode by
writing levels in uppercase, and warn_once on lowercase levels, describing
that the old behaviour will go away. Once (if ever) we remove the old
behaviour, the apps trying the old-style lowercase levels will fail
gracefully with EINVAL.

Or we can be honest and admit that we can't be perfect and just add an
explicit versioning to the interface. :)

It might be unfortunate that we did not foresee this and have to change
things that soon, but we did change interfaces in the past for a lot of
sysfs and proc knobs, so it is not something new. Once the vmpressure
feature will get even wider usage exposure, we might realize that we need
to make even more changes...

> (Why didn't vmpressure use netlink, btw?  Then we'd have decent payload
> delivery)

Because we decided to be a part of memcg and thus we used standard cgroups
notifications. And we didn't need the payload (and still don't need it if
we go with the multiple fds interface).

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


Re: [PATCH v2] vmpressure: implement strict mode

2013-06-27 Thread Anton Vorontsov
On Thu, Jun 27, 2013 at 05:34:33PM -0700, Andrew Morton wrote:
> > If so, userland daemon would receive lots of events which are no interest.
> 
> "lots"?  If vmpressure is generating events at such a high frequency that
> this matters then it's already busted?

Current frequency is 1/(2MB). Suppose we ended up scanning the whole
memory on a 2GB host, this will give us 1024 hits. Doesn't feel too much*
to me... But for what it worth, I am against adding read() to the
interface -- just because we can avoid the unnecessary switch into the
kernel.

* For bigger hosts we should increase the window, as we do for the vmstat. 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] vmpressure: implement strict mode

2013-06-26 Thread Anton Vorontsov
On Wed, Jun 26, 2013 at 04:50:51PM +0900, Minchan Kim wrote:
> On Tue, Jun 25, 2013 at 05:51:29PM -0400, Luiz Capitulino wrote:
> > Currently, applications are notified for the level they registered for
> > _plus_ higher levels.
> > 
> > This is a problem if the application wants to implement different
> > actions for different levels. For example, an application might want
> > to release 10% of its cache on level low, 50% on medium and 100% on
> > critical. To do this, the application has to register a different fd
> > for each event. However, fd low is always going to be notified and
> > and all fds are going to be notified on level critical.
> > 
> > Strict mode solves this problem by strictly notifiying the event
> > an fd has registered for. It's optional. By default we still notify
> > on higher levels.
> > 
> > Signed-off-by: Luiz Capitulino 
> Acked-by: Minchan Kim 
> 
> Shouldn't we make this default?
> What do you think about it?

Either way works and both modes have their use-cases (as I have described
in my previous mail). Changing the default mode is just unneeded churn,
IMO. As long as things are documented properly, we are good. :)

Thanks,

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


Re: [PATCH] vmpressure: implement strict mode

2013-06-25 Thread Anton Vorontsov
On Tue, Jun 25, 2013 at 05:51:29PM -0400, Luiz Capitulino wrote:
> Currently, applications are notified for the level they registered for
> _plus_ higher levels.
> 
> This is a problem if the application wants to implement different
> actions for different levels. For example, an application might want
> to release 10% of its cache on level low, 50% on medium and 100% on
> critical. To do this, the application has to register a different fd
> for each event. However, fd low is always going to be notified and
> and all fds are going to be notified on level critical.
> 
> Strict mode solves this problem by strictly notifiying the event
> an fd has registered for. It's optional. By default we still notify
> on higher levels.
> 
> Signed-off-by: Luiz Capitulino 

In the documentation I would add more information about why exactly the
strict mode makes sense.

For example, the non-strict fd listener hooked onto the low level makes
sense for apps that just monitor reclaiming activity (like current Android
Activity Manager), hooking onto 'medium' non-strict mode makes sense for
simple load-balancing logic, and the new strict mode is for the cases when
an application wants to implement some fancy logic as it makes a decision
based on a concrete level.

Otherwise, it looks good.

Acked-by: Anton Vorontsov 

Thanks!

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


Re: [PATCH] power/reset: Make the vexpress driver optional on arm and arm64

2013-06-21 Thread Anton Vorontsov
On Mon, Jun 10, 2013 at 04:12:01PM +0100, Pawel Moll wrote:
> The driver can be used on either arm or arm64 platforms, but
> the latter doesn't have any platform-specific configuration
> options, so it must be possible to manually enable the driver.
> 
> Signed-off-by: Pawel Moll 
> Acked-by: Catalin Marinas 
> ---

Applied. Thanks a lot, Pawel!

> diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
> index 349e9ae..ee039dc 100644
> --- a/drivers/power/reset/Kconfig
> +++ b/drivers/power/reset/Kconfig
> @@ -32,7 +32,8 @@ config POWER_RESET_RESTART
> user presses a key. u-boot then boots into Linux.
>  
>  config POWER_RESET_VEXPRESS
> - bool
> + bool "ARM Versatile Express power-off and reset driver"
> + depends on ARM || ARM64
>   depends on POWER_RESET
>   help
> Power off and reset support for the ARM Ltd. Versatile
> -- 
> 1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [GIT PULL] pstore/ram for 3.11

2013-06-14 Thread Anton Vorontsov
On Fri, Jun 14, 2013 at 05:32:16PM -0500, Rob Herring wrote:
> https://lkml.org/lkml/2013/4/9/831
> 
> The main discussion was around the write-combining change which I
> dropped. You can pick patches 2 and 3 off the mail list if you prefer. I
> would assume they only require an ack from one of the 4 of you which
> pulling the tree implicitly does.

I've just re-reviewed the discussion. I see Colin was talking about ftrace
causing infinite loops due to recursion. Once I stumbled onto this too
(but the issue itself was due to missing 'notrace' mark), and Stephen told
that recursion protection is kind of mandatory:

  http://lists.linaro.org/pipermail/linaro-kernel/2012-August/002084.html

I belive that the protection is actually there nowadays, and that is why
Rob does not see the problem with his patch.

So, I guess the patches are good, at least they fix real issues for Rob.
:)

Acked-by: Anton Vorontsov 

(Or I can pick this via linux-pstore.git tree, I'll let Tony decide.)

Thanks!

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


Re: [PATCH 1/2] MMC: P2020 SDHC: Add support for 8-bit bus width and non-removable card

2013-06-13 Thread Anton Vorontsov
On Wed, Jun 12, 2013 at 04:53:25PM +0300, Oded Gabbay wrote:
> @@ -262,7 +288,23 @@ static const struct sdhci_pltfm_data sdhci_esdhc_pdata = 
> {
>  
>  static int sdhci_esdhc_probe(struct platform_device *pdev)
>  {
> - return sdhci_pltfm_register(pdev, &sdhci_esdhc_pdata);
> + struct sdhci_host *host;
> + int ret = 0;

No need for the 0 initializer.

Otherwise it looks OK, thanks!

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


Re: [PATCH 2/2] MMC: P2020 SDHC: Fix bug when writing to SDHCI_HOST_CONTROL register

2013-06-13 Thread Anton Vorontsov
On Wed, Jun 12, 2013 at 04:54:37PM +0300, Oded Gabbay wrote:
> The P2020 has a non-standard implementation of the SDHCI_HOST_CONTROL
> register. This patch adds a QUIRK in the SDHCI header to signal that
> a host controller has a non-standard SDHCI_HOST_CONTROL register. The
> patch adds a check to the function esdhc_writeb in file
> sdhci-of-esdhc.c, where it checks if the write is done to the
> SDHCI_HOST_CONTROL register and th host has the above mentioned QUIRK,
> then the function simply returns instead of writing to the register.
> The patch also detects if the processor is P2020 (by looking in dev
> tree) and if so, adds the QUIRK to the host->quirk2
> 
> This patch depends on the first patch of this set (total of 2 patches)
> 
> Signed-off-by: Oded Gabbay 
> ---
>  drivers/mmc/host/sdhci-of-esdhc.c | 14 ++
>  include/linux/mmc/sdhci.h |  2 ++
>  2 files changed, 16 insertions(+)
> 
> diff --git a/drivers/mmc/host/sdhci-of-esdhc.c 
> b/drivers/mmc/host/sdhci-of-esdhc.c
> index fd149a0..ca88529 100644
> --- a/drivers/mmc/host/sdhci-of-esdhc.c
> +++ b/drivers/mmc/host/sdhci-of-esdhc.c
> @@ -121,6 +121,11 @@ static void esdhc_writeb(struct sdhci_host *host, u8 
> val, int reg)
>   if (reg == SDHCI_HOST_CONTROL) {
>   u32 dma_bits;
>  
> + /* If host control register is not standard, exit
> +  * this function */

Broken comments.

> + if (host->quirks2 & SDHCI_QUIRK2_BROKEN_HOST_CONTROL)
> + return;
> +
>   /* DMA select is 22,23 bits in Protocol Control Register */
>   dma_bits = (val & SDHCI_CTRL_DMA_MASK) << 5;
>   clrsetbits_be32(host->ioaddr + reg , SDHCI_CTRL_DMA_MASK << 5,
> @@ -289,6 +294,7 @@ static const struct sdhci_pltfm_data sdhci_esdhc_pdata = {
>  static int sdhci_esdhc_probe(struct platform_device *pdev)
>  {
>   struct sdhci_host *host;
> + struct device_node *np;
>   int ret = 0;
>  
>   host = sdhci_pltfm_init(pdev, &sdhci_esdhc_pdata);
> @@ -297,6 +303,14 @@ static int sdhci_esdhc_probe(struct platform_device 
> *pdev)
>  
>   sdhci_get_of_property(pdev);
>  
> + np = pdev->dev.of_node;
> + if (of_device_is_compatible(np, "fsl,p2020-esdhc")) {
> + /* Freescale messed up with P2020 as it has a non-standard
> + * host control register
> + */

Ditto.

Otherwise, it looks good. Thanks!

Reviewed-by: Anton Vorontsov 

> + host->quirks2 |= SDHCI_QUIRK2_BROKEN_HOST_CONTROL;
> + }
> +
>   /* call to generic mmc_of_parse to support additional capabilities */
>   mmc_of_parse(host->mmc);
>  
> diff --git a/include/linux/mmc/sdhci.h b/include/linux/mmc/sdhci.h
> index b838ffc..b73dbdd 100644
> --- a/include/linux/mmc/sdhci.h
> +++ b/include/linux/mmc/sdhci.h
> @@ -95,6 +95,8 @@ struct sdhci_host {
>  /* The system physically doesn't support 1.8v, even if the host does */
>  #define SDHCI_QUIRK2_NO_1_8_V(1<<2)
>  #define SDHCI_QUIRK2_PRESET_VALUE_BROKEN (1<<3)
> +/* Controller has a non-standard host control register */
> +#define SDHCI_QUIRK2_BROKEN_HOST_CONTROL (1<<4)
>  
>   int irq;/* Device IRQ */
>   void __iomem *ioaddr;   /* Mapped address */
> -- 
> 1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] power: Add missing newlines, fix a couple of typos, add pr_fmt

2013-06-09 Thread Anton Vorontsov
On Fri, Jun 07, 2013 at 11:31:06AM -0700, Kees Cook wrote:
> On Thu, Jun 6, 2013 at 6:25 PM, Joe Perches  wrote:
> > Make sure that dev_ calls are newline terminated.
> > Add #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt to prefix
> > all pr_ calls with "charger-manager: "
> >
> > Fix a couple of typos.
> > Fix formats with terminating n that should be \n.
> > Coalesce formats for easier grep.
> > Align arguments to open parenthesis for these dev_ calls.
> > Add missing spaces after coalescing multiple string segments.
> >
> > Signed-off-by: Joe Perches 
> 
> Looks like good clean-ups.
> 
> Acked-by: Kees Cook 

Applied, thanks!

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


Re: [PATCH 1/1] tps65090-charger: Fix AC detect

2013-06-09 Thread Anton Vorontsov
On Fri, Jun 07, 2013 at 12:07:39PM -0400, Rhyland Klein wrote:
> On 6/6/2013 5:12 PM, Andrew Chew wrote:
> > The VACG interrupt was not being enabled.  Thus, interrupts were never
> > generated when AC status changes.  In addition, interrupts were never
> > cleared after taking and processing the interrupt.
> > 
> > Added the register offset for the INTR_MASK register, since this is needed
> > to unmask the VACG interrupt.
> > 
> > Enabled the VACG interrupt in tps65090_config_charger().
> > 
> > Cleared interrupts after processing, in tps65090_charger_isr().
> > 
> > Also removed unused variable "enable" in tps65090_enable_charging(),
> > and fixed a typo in one of the dev_err() prints.
> > 
> > Signed-off-by: Andrew Chew 
> > ---
> 
> Great! Tested and it works great on my Dalmore.
> 
> Tested-by: Rhyland Klein 
> Acked-by: Rhyland Klein 

Applied, thanks!

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


[PATCH] MAINTAINERS: Update email address for Anton Vorontsov

2013-06-09 Thread Anton Vorontsov
Old email addresses seem to gradually stop working so people are getting
bounces. This patch updates my email address.

Suggested-by: Andy Shevchenko 
Signed-off-by: Anton Vorontsov 
---

I'm about to merge this patch via battery-2.6.git tree.

 MAINTAINERS | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index f35a259..9e63f91 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -742,7 +742,7 @@ S:  Maintained
 F: arch/arm/mach-highbank/
 
 ARM/CAVIUM NETWORKS CNS3XXX MACHINE SUPPORT
-M: Anton Vorontsov 
+M: Anton Vorontsov 
 S: Maintained
 F: arch/arm/mach-cns3xxx/
 T: git git://git.infradead.org/users/cbou/linux-cns3xxx.git
@@ -6314,7 +6314,7 @@ F:include/linux/timer*
 F: kernel/*timer*
 
 POWER SUPPLY CLASS/SUBSYSTEM and DRIVERS
-M: Anton Vorontsov 
+M: Anton Vorontsov 
 M: David Woodhouse 
 T: git git://git.infradead.org/battery-2.6.git
 S: Maintained
@@ -6424,7 +6424,7 @@ S:Maintained
 F: drivers/block/ps3vram.c
 
 PSTORE FILESYSTEM
-M: Anton Vorontsov 
+M: Anton Vorontsov 
 M: Colin Cross 
 M: Kees Cook 
 M: Tony Luck 
@@ -7122,7 +7122,7 @@ F:drivers/mmc/host/sdhci.*
 F: drivers/mmc/host/sdhci-pltfm.[ch]
 
 SECURE DIGITAL HOST CONTROLLER INTERFACE, OPEN FIRMWARE BINDINGS (SDHCI-OF)
-M: Anton Vorontsov 
+M: Anton Vorontsov 
 L: linuxppc-...@lists.ozlabs.org
 L: linux-...@vger.kernel.org
 S: Maintained
-- 
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 4/8] power: ensure event is not used as format string

2013-06-06 Thread Anton Vorontsov
On Thu, Jun 06, 2013 at 01:52:21PM -0700, Kees Cook wrote:
> The exposed interface for cm_notify_event() could result in the event
> msg string being parsed as a format string. Make sure it is only used
> as a literal string.
> 
> Signed-off-by: Kees Cook 
> Cc: sta...@vger.kernel.org
> Cc: Anton Vorontsov 
> Cc: David Woodhouse 
> ---

Thanks a lot, Kees! This is now applied.

>  drivers/power/charger-manager.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/power/charger-manager.c b/drivers/power/charger-manager.c
> index fefc39f..98de1dd 100644
> --- a/drivers/power/charger-manager.c
> +++ b/drivers/power/charger-manager.c
> @@ -450,7 +450,7 @@ static void uevent_notify(struct charger_manager *cm, 
> const char *event)
>   strncpy(env_str, event, UEVENT_BUF_SIZE);
>   kobject_uevent(&cm->dev->kobj, KOBJ_CHANGE);
>  
> - dev_info(cm->dev, event);
> + dev_info(cm->dev, "%s", event);
>  }
>  
>  /**
> -- 
> 1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH V2] power: replace strict_strtoul() with kstrtoul()

2013-06-06 Thread Anton Vorontsov
On Mon, Jun 03, 2013 at 01:49:49PM +0300, Andy Shevchenko wrote:
> On Mon, Jun 3, 2013 at 12:05 PM, Jingoo Han  wrote:
> > The usage of strict_strtoul() is not preferred, because
> > strict_strtoul() is obsolete. Thus, kstrtoul() should be
> > used.
> >
> > Signed-off-by: Jingoo Han 
> 
> Looks better.
> Reviewed-by: Andy Shevchenko 

Applied, thanks a lot!

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


Re: [PATCH] power_supply: generic-adc-battery: Fix checking if none of the channels are supported

2013-06-06 Thread Anton Vorontsov
On Tue, May 28, 2013 at 11:57:37AM +0530, anish singh wrote:
> On Fri, May 24, 2013 at 11:11 PM, Axel Lin  wrote:
> > If none of the channels are supported, index is 0.
> > Also ensure to return error code instead of 0 in goto second_mem_fail path.
> >
> > Signed-off-by: Axel Lin 
> Acked-by: anish kumar 

Applied, thanks!

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


Re: [PATCH] power: use platform_{get,set}_drvdata()

2013-06-06 Thread Anton Vorontsov
On Thu, May 23, 2013 at 07:34:39PM +0900, Jingoo Han wrote:
> Use the wrapper functions for getting and setting the driver data using
> platform_device instead of using dev_{get,set}_drvdata() with &pdev->dev,
> so we can directly pass a struct platform_device.
> 
> Signed-off-by: Jingoo Han 
> ---

Applied, thanks!

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


Re: [PATCH] power_supply: pm2301_charger: Return error if create_singlethread_workqueue fails

2013-06-06 Thread Anton Vorontsov
On Mon, May 20, 2013 at 01:42:43PM +0200, Linus Walleij wrote:
> On Thu, May 16, 2013 at 3:17 PM, Axel Lin  wrote:
> 
> > Return error instead of 0 if create_singlethread_workqueue call fails.
> >
> > Signed-off-by: Axel Lin 
> 
> Acked-by: Linus Walleij 

Also applied, thank you!

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


Re: [PATCH] power_supply: pm2301_charger: Fix NULL pointer dereference

2013-06-06 Thread Anton Vorontsov
On Fri, May 17, 2013 at 03:45:55PM +0200, Linus Walleij wrote:
> On Thu, May 16, 2013 at 11:31 AM, Axel Lin  wrote:
> 
> > Add checking pl_data in probe, this prevent possible NULL pointer 
> > dereference.
> > Also fix NULL pointer deference in dev_err when allocate memory for pm2 
> > fails.
> >
> > Signed-off-by: Axel Lin 
> 
> Acked-by: Linus Walleij 

Applied, thanks!

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


Re: [PATCH] power: lp8727: support the device tree feature

2013-06-06 Thread Anton Vorontsov
On Fri, May 10, 2013 at 07:17:51AM +, Kim, Milo wrote:
> The interrupt and charging parameters are configurable in the device tree
> structure. In the board test, a GPIO is used for handling LP8727 interrupts.
> The device tree binding documentation is added also.
> 
> Signed-off-by: Milo(Woogyom) Kim 
> ---

Applied, thanks!

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


Re: [PATCH 1/8] 88pm860x_battery: remove unnecessary platform_set_drvdata()

2013-06-06 Thread Anton Vorontsov
On Mon, May 06, 2013 at 01:16:30PM +0900, Jingoo Han wrote:
> The driver core clears the driver data to NULL after device_release
> or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
> (device-core: Ensure drvdata = NULL when no driver is bound).
> Thus, it is not needed to manually clear the device driver data to NULL.
> 
> Signed-off-by: Jingoo Han 

1-8 applied, thanks a lot!

Anton

> ---
>  drivers/power/88pm860x_battery.c |1 -
>  1 files changed, 0 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/power/88pm860x_battery.c 
> b/drivers/power/88pm860x_battery.c
> index d338c1c..dfcda3a 100644
> --- a/drivers/power/88pm860x_battery.c
> +++ b/drivers/power/88pm860x_battery.c
> @@ -992,7 +992,6 @@ static int pm860x_battery_remove(struct platform_device 
> *pdev)
>   free_irq(info->irq_batt, info);
>   free_irq(info->irq_cc, info);
>   power_supply_unregister(&info->battery);
> - platform_set_drvdata(pdev, NULL);
>   return 0;
>  }
>  
> -- 
> 1.7.2.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [GIT PULL] battery-2.6.git

2013-05-25 Thread Anton Vorontsov
On Sun, May 26, 2013 at 12:23:32AM +0100, David Woodhouse wrote:
> On Sat, 2013-05-25 at 15:23 -0700, Anton Vorontsov wrote:
> > Please pull battery-2.6 git tree to get a few one-liners: wrong kfree
> > usage fix, module alias fixup and kconfig adjustments. The patches really
> > small, so for convenience I inline them here.
> 
> Please note git.infradead.org has just been migrated to a virtual
> machine, and was rebooted once or twice after this pull request was
> sent. We don't anticipate any more reboots imminently.
> 
> The new IP address (2001:1868:205::9, or 198.137.202.9 for those stuck
> in the 20th century) should have propagated in DNS already and the
> migration should theoretically be fairly seamless. But please let me
> know if anything goes wrong.
> 
> It will be moving again, onto real hardware once it becomes available,
> hopefully in the next week or so. It will retain the same IP addresses.

Thanks a lot for your efforts and letting us know, David!

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


[GIT PULL] battery-2.6.git

2013-05-25 Thread Anton Vorontsov
Hello Linus,

Please pull battery-2.6 git tree to get a few one-liners: wrong kfree
usage fix, module alias fixup and kconfig adjustments. The patches really
small, so for convenience I inline them here.

Thanks!

Anton

The following changes since commit 6b170807cd5cac8dc6353f47a88ccb14bbf76c4f:

  pm2301-charger: Fix suspend/resume (2013-04-16 19:00:01 -0700)

are available in the git repository at:

  git://git.infradead.org/battery-2.6.git tags/for-v3.10-fixes

for you to fetch changes up to dccab6092d3c25bf943d12fb658e63fd88bf8b4a:

  pm2301_charger: Fix module alias prefix (2013-05-10 11:57:14 -0700)


Axel Lin (2):
  wm831x_backup: Fix wrong kfree call for devdata->backup.name
  pm2301_charger: Fix module alias prefix

Randy Dunlap (1):
  lp8788-charger: Fix kconfig dependency

Xiong Zhou (1):
  bq27x00: Fix I2C dependency in KConfig

 drivers/power/Kconfig  | 2 ++
 drivers/power/pm2301_charger.c | 2 +-
 drivers/power/wm831x_backup.c  | 1 -
 3 files changed, 3 insertions(+), 2 deletions(-)


commit dccab6092d3c25bf943d12fb658e63fd88bf8b4a
Author: Axel Lin 
Date:   Sat May 4 18:51:09 2013 +0800

pm2301_charger: Fix module alias prefix

This driver is a i2c driver, use "i2c" rather than "platform" prefix for
module alias.

Signed-off-by: Axel Lin 
    Signed-off-by: Anton Vorontsov 

diff --git a/drivers/power/pm2301_charger.c b/drivers/power/pm2301_charger.c
index f123f3c..e9c6ba0 100644
--- a/drivers/power/pm2301_charger.c
+++ b/drivers/power/pm2301_charger.c
@@ -1269,5 +1269,5 @@ module_exit(pm2xxx_charger_exit);
 
 MODULE_LICENSE("GPL v2");
 MODULE_AUTHOR("Rajkumar kasirajan, Olivier Launay");
-MODULE_ALIAS("platform:pm2xxx-charger");
+MODULE_ALIAS("i2c:pm2xxx-charger");
 MODULE_DESCRIPTION("PM2xxx charger management driver");

commit c909fc8573af3cff9184551e79cf37784b5ddc24
Author: Axel Lin 
Date:   Sat May 4 13:57:55 2013 +0800

wm831x_backup: Fix wrong kfree call for devdata->backup.name

devdata->backup.name points to devdata->name, the memory for devdata->name
is part of struct wm831x_backup. Thus remove kfree call for
devdata->backup.name.

    Signed-off-by: Axel Lin 
Acked-by: Mark Brown 
Signed-off-by: Anton Vorontsov 

diff --git a/drivers/power/wm831x_backup.c b/drivers/power/wm831x_backup.c
index 58cbb00..56fb509 100644
--- a/drivers/power/wm831x_backup.c
+++ b/drivers/power/wm831x_backup.c
@@ -207,7 +207,6 @@ static int wm831x_backup_remove(struct platform_device 
*pdev)
struct wm831x_backup *devdata = platform_get_drvdata(pdev);
 
power_supply_unregister(&devdata->backup);
-   kfree(devdata->backup.name);
 
return 0;
 }

commit a2d0dbb4b55681874c5f288538ae55ae69baeaff
Author: Xiong Zhou 
Date:   Tue May 7 10:15:56 2013 +0800

bq27x00: Fix I2C dependency in KConfig

This patch fixes build failure(randconfig) of next-20130501. When config
I2C as m, BATTERY_BQ27x00 as y, here comes the failure. The driver depends
on I2C only if I2C is not disabled, as Lars commented. Last version of
this patch make the driver depend on I2C unconditionally.

Failure message:
drivers/built-in.o: In function `bq27x00_read_i2c':
bq27x00_battery.c:(.text+0x1082a7): undefined reference to `i2c_transfer'
drivers/built-in.o: In function `bq27x00_battery_init':
bq27x00_battery.c:(.init.text+0x6085): undefined reference to 
`i2c_register_driver'
bq27x00_battery.c:(.init.text+0x60c7): undefined reference to 
`i2c_del_driver'
drivers/built-in.o: In function `bq27x00_battery_exit':
bq27x00_battery.c:(.exit.text+0xbf0): undefined reference to 
`i2c_del_driver'
make: *** [vmlinux] Error 1

Signed-off-by: Xiong Zhou 
Cc: Lars-Peter Clausen 
Signed-off-by: Anton Vorontsov 

diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 814bcb9..674e633 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -152,6 +152,7 @@ config BATTERY_SBS
 
 config BATTERY_BQ27x00
tristate "BQ27x00 battery driver"
+   depends on I2C || I2C=n
help
  Say Y here to enable support for batteries with BQ27x00 (I2C/HDQ) 
chips.
 

commit 237a1b01fdb29df6a28d50d6dbe7a988c4fb3625
Author: Randy Dunlap 
Date:   Wed May 1 12:18:43 2013 -0700

lp8788-charger: Fix kconfig dependency

Fix build errors in lp8788-charger by making it depend on IIO.
Fixes errors when CONFIG_IIO=m and CHARGER_LP8788=y.

lp8788-charger.c:(.text+0x2146b5): undefined reference to `iio_channel_get'
lp8788-charger.c:(.text+0x2146ce): undefined reference to `iio_channel_get'
lp8788-charger.c:(.text+0x214a86): undefined reference to 
`iio_read_channel_processed'
lp8788-charger.c:(.text+0x214b51

Re: [PATCH] kernel/debug/kdb: code enhancement for 3 areas.

2013-05-23 Thread Anton Vorontsov
On Thu, May 16, 2013 at 07:25:46PM +0800, Chen Gang wrote:
> Delete waste '{' for 'case' statement.
> 
> For the return variable 'long res' in function kdb_task_state_string(),
> neither it matches the function return type 'unsigned long', nor is
> suitable as a flag variable to make 'or' operation. So use 'unsigned
> long' instead of 'long'.
> 
> If "case 'A'" happen in function kdb_task_state_string(), can return
> ~0UL directly to save the useless looping.
> 
> Signed-off-by: Chen Gang 

If anything, these should be 3 separate patches...

Thanks!

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


Re: [PATCH 3/3] ARM: versatile: Make able to use UART ports for KGDB FIQ debugger

2013-05-17 Thread Anton Vorontsov
Thanks a lot for the review, Thomas!

On Fri, May 10, 2013 at 04:17:10PM +0200, Thomas Petazzoni wrote:
[...]
> > +{
> > +   return readl(kgdb_irq_base + VIC_FIQ_STATUS) & (1 << kgdb_irq);
> > +}
> > +
> > +static int __init kgdb_fiq_init(void)
> > +{
> > +   kgdb_irq_base = __io_address(VERSATILE_VIC_BASE);
> > +   kgdb_irq += INT_UARTINT0;
> > +   WARN_ON(kgdb_irq > INT_UARTINT2);
> > +
> > +   return kgdb_register_fiq(kgdb_fiq_select, kgdb_is_fiq_rised);
> > +}
> > +console_initcall(kgdb_fiq_init);
> 
> Also, this code that uses hardcoded addresses and IRQ numbers doesn't
> seem to play really well with the DT. I was considering toying around
> with this thing on the mach-mvebu platform, but don't have those
> hardcoded addresses and IRQs, and the register offsets of the IRQ
> controller driver are not exposed in an header file. Shouldn't IRQ
> controller driver be exposing a the fiq_select() functionality instead?
> Like a new flag for irq_chip->irq_set_type(), or a completely new hook
> irq_chip->irq_set_mode() or something like that?

FIQs are very specific to the platform, and I doubt that anyone will be
happy in exposing this kind of knowledge to the generic subsystem.

Moreover, Russell King once said that we should better detach IRQ stuff
from FIQs altogether. Thing is, FIQs are not going through the generic IRQ
code flow, so there is actually very little point in managing them thru
the generic IRQ subsystem.

What seems more plausible is making a "FIQ subsystem", and register each
IRQ controller that can redirect its sources to FIQ with that new
subsystem. But the "subsystem" isn't there, and even doing some cleanups
in this core stuff takes forever to review/make decision. :) Plus, writing
it for this small thing seems like a bit of overhead.

And if you take a closer look at this patch, it actually does not use IRQ
numbers with the IRQ subsystem. Instead, it bypasses the whole thing and
writes to the VIC registers directly.

So, for your case (if you want to use FIQ debugger on your board), I would
suggest doing the same. At least until we figure out how to do these ten
lines of board-specific code better (ideas/hints are welcome! :)

Thanks!

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


  1   2   3   4   5   6   7   8   9   >