Re: [PATCH 20/22] pstore: %pF is only for function pointers
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/
Re: [PATCH 20/22] pstore: %pF is only for function pointers
On Tue, Jun 16, 2015 at 03:02:50PM -0700, Kees Cook wrote: On Wed, Mar 11, 2015 at 8:13 PM, Scott Wood scottw...@freescale.com 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 scottw...@freescale.com ... - 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 keesc...@chromium.org 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))
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/
CNS3xxx maintainer (was Re: master build: 0 failures 28 warnings (v3.17-rc4-158-ge874a5f))
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
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: [RESEND PATCH v3 2/5] charger: tps65090: Allow charger module to be used when no irq
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 dbarysh...@gmail.com 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 dbarysh...@gmail.com Acked-by: Anton Vorontsov an...@enomsg.org -- 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()
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
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 v3 5/6] timerfd: Add support for deferrable timers
On Thu, Feb 20, 2014 at 12:09:43PM +0100, Thomas Gleixner wrote: On Thu, 20 Feb 2014, Alexey Perevalov wrote: From: Anton Vorontsov an...@enomsg.org 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 v3 4/6] timerfd: Factor out timer-type unspecific timerfd_expire()
On Thu, Feb 20, 2014 at 11:52:03AM +0100, Thomas Gleixner wrote: From: Anton Vorontsov an...@enomsg.org 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 anton.voront...@linaro.org Signed-off-by: Alexey Perevalov a.pereva...@samsung.com ... 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 v2 1/3] power_supply: Add power_supply notifier
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
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/
[GIT PULL] battery-2.6.git
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 v2 1/3] power_supply: Add power_supply notifier
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/
Re: [PATCH] gpio-charger: support wakeup events
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
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
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
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
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
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
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/2] power: reset: as3722: add power-off driver
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 ldewan...@nvidia.com Tested-by: Stephen Warren swar...@nvidia.com --- 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
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 pali.ro...@gmail.com Reviewed-by: Pavel Machek pa...@ucw.cz 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/3] power_supply: add power_supply_get_by_phandle
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 s...@debian.org
---
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
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: [PATCHv2 0/2] DT support for isp1704-charger
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 v7 1/3] charger: max14577: Add charger support for Maxim 14577
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 k.kozlow...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- 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] gpio-charger: support wakeup events
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 dbarysh...@gmail.com --- 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/3] bq2415x_charger: Use power_supply notifier for automode
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
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
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
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
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
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/
Re: [PATCH v3 1/2] power_supply: Fix Oops from NULL pointer dereference from wakeup_source_activate
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/
Re: [PATCH v2 1/3] power_supply: Add power_supply notifier
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 jenny...@intel.com Signed-off-by: Pali Rohár pali.ro...@gmail.com --- Acked-by: Jenny TC jenny...@intel.com 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 1/3] power_supply: Add power_supply notifier
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 jenny...@intel.com
Signed-off-by: Pali Rohár pali.ro...@gmail.com
...
+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 linux/init.h
#include linux/slab.h
#include linux/device.h
+#include linux/notifier.h
#include linux/err.h
#include linux/power_supply.h
#include linux/thermal.h
@@ -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] max17042: Fix build errors caused by missing REGMAP_I2C config
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 boyle.aus...@gmail.com --- 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 jonghwa3@samsung.com 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 2/3] bq2415x_charger: Use power_supply notifier for automode
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 v2 2/3] bq2415x_charger: Use power_supply notifier for automode
On Mon, Dec 02, 2013 at 01:02:40AM +0100, Michael Trimarchi wrote: On Sun, Dec 1, 2013 at 11:37 PM, Anton Vorontsov an...@enomsg.org 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/
[GIT PULL] battery-2.6.git
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/
[GIT PULL] battery-2.6.git
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
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] pm2301-charger: remove unneeded NULL checks
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 dan.carpen...@oracle.com 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
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
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
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
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
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 7/7] power_supply: Introduce PSE compliant algorithm
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: N900 DT
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] power:power_supply_syfs : Treat PROP_TYPE as a regular attribute first
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: [PATCH 1/7] power_supply: Add charger control properties
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 @@
Re: [PATCH 1/7] power_supply: Add charger control properties
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 jenny...@intel.com 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_ALERT_MAX - maximum battery temperature alert
Re: [PATCH] Fuel Guague: MAX17040: Use regmap to interface with internal registers
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
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
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.
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
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
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
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
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] power:power_supply_syfs : Treat PROP_TYPE as a regular attribute first
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 v3 1/4] ab8500-charger: Check return value of regulator_enable
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 sachin.ka...@linaro.org Cc: Lee Jones lee.jo...@linaro.org --- 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 lee.jo...@linaro.org 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 V5] drivers: power: Add support for bq24735 charger
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 swar...@wwwdotorg.org 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 V5] drivers: power: Add support for bq24735 charger
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 swar...@wwwdotorg.org tag. :) Oh, and as well as Thanks-to: Thierry Reding thierry.red...@gmail.com (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] tps65090-charger: Use IS_ENABLED(CONFIG_OF) for DT code.
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 badarkhe.man...@gmail.com --- :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 rkl...@nvidia.com 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
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 alexandre.bell...@free-electrons.com 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] max17042_battery: use SIMPLE_DEV_PM_OPS
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 badarkhe.man...@gmail.com 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] Fuel Guague: MAX17040: Use regmap to interface with internal registers
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 kw46@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- $ 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 2/4] power: isp1704_charger: Fix driver to work with changes introduced in v3.5
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 2/4] power: isp1704_charger: Fix driver to work with changes introduced in v3.5
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 pali.ro...@gmail.com 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
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] mm, vmpressure: add high level
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
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(>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(>sr_lock);
> return;
> + }
>
> - spin_lock(>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
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
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
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 an...@enomsg.org
Thanks!
---
From 888745909da34f8aee8a208a82d467236b828d0d Mon Sep 17 00:00:00 2001
From: Michal Hocko mho...@suse.cz
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 hu...@google.com
Signed-off-by: Michal Hocko mho...@suse.cz
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
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(>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
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/
[GIT PULL] battery-2.6.git
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] vmpressure: fix divide-by-0 in vmpressure_work_fn
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 hu...@google.com
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/
Re: [PATCH] power: rx51_battery: Replace hardcoded channels values.
> 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() <= 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] power: rx51_battery: Replace hardcoded channels values.
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 marek.beli...@open-nandra.com 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()
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
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()
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()
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/
[PATCH] of/irq: Provide struct device_node forward-declaration for !OF case
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 an...@enomsg.org
---
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()
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/
Re: [PATCH 33/35] power: use dev_get_platdata()
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
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(>dev->kobj, KOBJ_CHANGE);
> + spin_lock_irqsave(>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
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()
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.
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
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
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] power: max8925: fix missing of_node_put
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 libo.c...@huawei.com 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
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 mgr...@animalcreek.com --- 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.
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 marek.beli...@open-nandra.com 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/
