[PATCH 0/4] Add support for charging battery in Nokia RX-51

[PATCH 0/4] Add support for charging battery in Nokia RX-51

[Pali Rohár]

This patch series finally bringing support for charging battery on
Nokia N900 (RX-51) without any proprietary Nokia bits in userspace.

Pali Rohár (4):
  usb: musb: Call atomic_notifier_call_chain when status is changed
  power: isp1704_charger: Fix driver to work with changes introduced in
    v3.5
  power: isp1704_charger: Add callback function set_current
  RX-51: Add platform function and data for bq24150a charger

 arch/arm/mach-omap2/board-rx51-peripherals.c |   56 +++++++++++++-
 drivers/power/isp1704_charger.c              |  107 ++++++++++++++------------
 drivers/usb/musb/omap2430.c                  |    3 +
 drivers/usb/phy/phy-twl4030-usb.c            |    2 +
 include/linux/power/isp1704_charger.h        |    1 +
 5 files changed, 117 insertions(+), 52 deletions(-)

-- 
1.7.10.4

[PATCH 0/4] Add support for charging battery in Nokia RX-51

[Pali Rohár]

This patch series finally bringing support for charging battery on
Nokia N900 (RX-51) without any proprietary Nokia bits in userspace.

Pali Roh?r (4):
  usb: musb: Call atomic_notifier_call_chain when status is changed
  power: isp1704_charger: Fix driver to work with changes introduced in
    v3.5
  power: isp1704_charger: Add callback function set_current
  RX-51: Add platform function and data for bq24150a charger

 arch/arm/mach-omap2/board-rx51-peripherals.c |   56 +++++++++++++-
 drivers/power/isp1704_charger.c              |  107 ++++++++++++++------------
 drivers/usb/musb/omap2430.c                  |    3 +
 drivers/usb/phy/phy-twl4030-usb.c            |    2 +
 include/linux/power/isp1704_charger.h        |    1 +
 5 files changed, 117 insertions(+), 52 deletions(-)

-- 
1.7.10.4

[PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Pali Rohár]

More power supply drivers depends on vbus events and without it they not
working. Power supply drivers using usb_register_notifier, so to deliver
events it is needed to call atomic_notifier_call_chain.

So without atomic notifier power supply driver isp1704 not retrieving
vbus status and reporting bogus values to userspace and also to board
platform data functions. Without proper data charger drivers trying to
charge battery also when charger is disconnected or do not start charging
when wallcharger connects.

Atomic notifier in musb driver was used before v3.5 and was replaced with
omap mailbox. This patch adding atomic_notifier_call_chain call from
function omap_musb_set_mailbox.

Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
---
 drivers/usb/musb/omap2430.c       |    3 +++
 drivers/usb/phy/phy-twl4030-usb.c |    2 ++
 2 files changed, 5 insertions(+)

diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index f44e8b5..5c40252 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -305,6 +305,9 @@ static void omap_musb_set_mailbox(struct omap2430_glue *glue)
 	default:
 		dev_dbg(dev, "ID float\n");
 	}
+
+	atomic_notifier_call_chain(&musb->xceiv->notifier,
+			musb->xceiv->last_event, NULL);
 }
 
 
diff --git a/drivers/usb/phy/phy-twl4030-usb.c b/drivers/usb/phy/phy-twl4030-usb.c
index 8f78d2d..efe6155 100644
--- a/drivers/usb/phy/phy-twl4030-usb.c
+++ b/drivers/usb/phy/phy-twl4030-usb.c
@@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct platform_device *pdev)
 	if (device_create_file(&pdev->dev, &dev_attr_vbus))
 		dev_warn(&pdev->dev, "could not create sysfs file\n");
 
+	ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
+
 	/* Our job is to use irqs and status from the power module
 	 * to keep the transceiver disabled when nothing's connected.
 	 *
-- 
1.7.10.4

[PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Pali Rohár]

More power supply drivers depends on vbus events and without it they not
working. Power supply drivers using usb_register_notifier, so to deliver
events it is needed to call atomic_notifier_call_chain.

So without atomic notifier power supply driver isp1704 not retrieving
vbus status and reporting bogus values to userspace and also to board
platform data functions. Without proper data charger drivers trying to
charge battery also when charger is disconnected or do not start charging
when wallcharger connects.

Atomic notifier in musb driver was used before v3.5 and was replaced with
omap mailbox. This patch adding atomic_notifier_call_chain call from
function omap_musb_set_mailbox.

Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>
---
 drivers/usb/musb/omap2430.c       |    3 +++
 drivers/usb/phy/phy-twl4030-usb.c |    2 ++
 2 files changed, 5 insertions(+)

diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index f44e8b5..5c40252 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -305,6 +305,9 @@ static void omap_musb_set_mailbox(struct omap2430_glue *glue)
 	default:
 		dev_dbg(dev, "ID float\n");
 	}
+
+	atomic_notifier_call_chain(&musb->xceiv->notifier,
+			musb->xceiv->last_event, NULL);
 }
 
 
diff --git a/drivers/usb/phy/phy-twl4030-usb.c b/drivers/usb/phy/phy-twl4030-usb.c
index 8f78d2d..efe6155 100644
--- a/drivers/usb/phy/phy-twl4030-usb.c
+++ b/drivers/usb/phy/phy-twl4030-usb.c
@@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct platform_device *pdev)
 	if (device_create_file(&pdev->dev, &dev_attr_vbus))
 		dev_warn(&pdev->dev, "could not create sysfs file\n");
 
+	ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
+
 	/* Our job is to use irqs and status from the power module
 	 * to keep the transceiver disabled when nothing's connected.
 	 *
-- 
1.7.10.4

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

[Pali Rohár]

* 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.rohar@gmail.com>
---
 drivers/power/isp1704_charger.c |   91 +++++++++++++++++----------------------
 1 file changed, 40 insertions(+), 51 deletions(-)

diff --git a/drivers/power/isp1704_charger.c b/drivers/power/isp1704_charger.c
index fc04d19..f726cb6 100644
--- a/drivers/power/isp1704_charger.c
+++ b/drivers/power/isp1704_charger.c
@@ -2,6 +2,7 @@
  * ISP1704 USB Charger Detection driver
  *
  * Copyright (C) 2010 Nokia Corporation
+ * Copyright (C) 2012 - 2013 Pali Rohár <pali.rohar@gmail.com>
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
@@ -65,10 +66,6 @@ struct isp1704_charger {
 	unsigned		present:1;
 	unsigned		online:1;
 	unsigned		current_max;
-
-	/* temp storage variables */
-	unsigned long		event;
-	unsigned		max_power;
 };
 
 static inline int isp1704_read(struct isp1704_charger *isp, u32 reg)
@@ -231,56 +228,59 @@ static inline int isp1704_charger_detect(struct isp1704_charger *isp)
 	return ret;
 }
 
+static inline int isp1704_charger_detect_dcp(struct isp1704_charger *isp)
+{
+	if (isp1704_charger_detect(isp) &&
+		isp1704_charger_type(isp) == POWER_SUPPLY_TYPE_USB_DCP)
+		return true;
+	else
+		return false;
+}
+
 static void isp1704_charger_work(struct work_struct *data)
 {
-	int			detect;
-	unsigned long		event;
-	unsigned		power;
 	struct isp1704_charger	*isp =
 		container_of(data, struct isp1704_charger, work);
 	static DEFINE_MUTEX(lock);
 
-	event = isp->event;
-	power = isp->max_power;
-
 	mutex_lock(&lock);
 
-	if (event != USB_EVENT_NONE)
-		isp1704_charger_set_power(isp, 1);
-
-	switch (event) {
+	switch (isp->phy->last_event) {
 	case USB_EVENT_VBUS:
-		isp->online = true;
+		/* do not call wall charger detection more times */
+		if (!isp->present) {
+			isp->online = true;
+			isp->present = 1;
+			isp1704_charger_set_power(isp, 1);
+
+			/* detect wall charger */
+			if (isp1704_charger_detect_dcp(isp)) {
+				isp->psy.type = POWER_SUPPLY_TYPE_USB_DCP;
+				isp->current_max = 1800;
+			} else {
+				isp->psy.type = POWER_SUPPLY_TYPE_USB;
+				isp->current_max = 500;
+			}
 
-		/* detect charger */
-		detect = isp1704_charger_detect(isp);
-
-		if (detect) {
-			isp->present = detect;
-			isp->psy.type = isp1704_charger_type(isp);
+			/* enable data pullups */
+			if (isp->phy->otg->gadget)
+				usb_gadget_connect(isp->phy->otg->gadget);
 		}
 
-		switch (isp->psy.type) {
-		case POWER_SUPPLY_TYPE_USB_DCP:
-			isp->current_max = 1800;
-			break;
-		case POWER_SUPPLY_TYPE_USB_CDP:
+		if (isp->psy.type != POWER_SUPPLY_TYPE_USB_DCP) {
 			/*
 			 * Only 500mA here or high speed chirp
 			 * handshaking may break
 			 */
-			isp->current_max = 500;
-			/* FALLTHROUGH */
-		case POWER_SUPPLY_TYPE_USB:
-		default:
-			/* enable data pullups */
-			if (isp->phy->otg->gadget)
-				usb_gadget_connect(isp->phy->otg->gadget);
+			if (isp->current_max > 500)
+				isp->current_max = 500;
+
+			if (isp->current_max > 100)
+				isp->psy.type = POWER_SUPPLY_TYPE_USB_CDP;
 		}
 		break;
 	case USB_EVENT_NONE:
 		isp->online = false;
-		isp->current_max = 0;
 		isp->present = 0;
 		isp->current_max = 0;
 		isp->psy.type = POWER_SUPPLY_TYPE_USB;
@@ -298,12 +298,6 @@ static void isp1704_charger_work(struct work_struct *data)
 
 		isp1704_charger_set_power(isp, 0);
 		break;
-	case USB_EVENT_ENUMERATED:
-		if (isp->present)
-			isp->current_max = 1800;
-		else
-			isp->current_max = power;
-		break;
 	default:
 		goto out;
 	}
@@ -314,16 +308,11 @@ out:
 }
 
 static int isp1704_notifier_call(struct notifier_block *nb,
-		unsigned long event, void *power)
+		unsigned long val, void *v)
 {
 	struct isp1704_charger *isp =
 		container_of(nb, struct isp1704_charger, nb);
 
-	isp->event = event;
-
-	if (power)
-		isp->max_power = *((unsigned *)power);
-
 	schedule_work(&isp->work);
 
 	return NOTIFY_OK;
@@ -462,13 +451,13 @@ static int isp1704_charger_probe(struct platform_device *pdev)
 	if (isp->phy->otg->gadget)
 		usb_gadget_disconnect(isp->phy->otg->gadget);
 
+	if (isp->phy->last_event == USB_EVENT_NONE)
+		isp1704_charger_set_power(isp, 0);
+
 	/* Detect charger if VBUS is valid (the cable was already plugged). */
-	ret = isp1704_read(isp, ULPI_USB_INT_STS);
-	isp1704_charger_set_power(isp, 0);
-	if ((ret & ULPI_INT_VBUS_VALID) && !isp->phy->otg->default_a) {
-		isp->event = USB_EVENT_VBUS;
+	if (isp->phy->last_event == USB_EVENT_VBUS &&
+			!isp->phy->otg->default_a)
 		schedule_work(&isp->work);
-	}
 
 	return 0;
 fail2:
-- 
1.7.10.4

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

[Pali Rohár]

* 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.rohar@gmail.com>
---
 drivers/power/isp1704_charger.c |   91 +++++++++++++++++----------------------
 1 file changed, 40 insertions(+), 51 deletions(-)

diff --git a/drivers/power/isp1704_charger.c b/drivers/power/isp1704_charger.c
index fc04d19..f726cb6 100644
--- a/drivers/power/isp1704_charger.c
+++ b/drivers/power/isp1704_charger.c
@@ -2,6 +2,7 @@
  * ISP1704 USB Charger Detection driver
  *
  * Copyright (C) 2010 Nokia Corporation
+ * Copyright (C) 2012 - 2013 Pali Roh?r <pali.rohar@gmail.com>
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
@@ -65,10 +66,6 @@ struct isp1704_charger {
 	unsigned		present:1;
 	unsigned		online:1;
 	unsigned		current_max;
-
-	/* temp storage variables */
-	unsigned long		event;
-	unsigned		max_power;
 };
 
 static inline int isp1704_read(struct isp1704_charger *isp, u32 reg)
@@ -231,56 +228,59 @@ static inline int isp1704_charger_detect(struct isp1704_charger *isp)
 	return ret;
 }
 
+static inline int isp1704_charger_detect_dcp(struct isp1704_charger *isp)
+{
+	if (isp1704_charger_detect(isp) &&
+		isp1704_charger_type(isp) == POWER_SUPPLY_TYPE_USB_DCP)
+		return true;
+	else
+		return false;
+}
+
 static void isp1704_charger_work(struct work_struct *data)
 {
-	int			detect;
-	unsigned long		event;
-	unsigned		power;
 	struct isp1704_charger	*isp =
 		container_of(data, struct isp1704_charger, work);
 	static DEFINE_MUTEX(lock);
 
-	event = isp->event;
-	power = isp->max_power;
-
 	mutex_lock(&lock);
 
-	if (event != USB_EVENT_NONE)
-		isp1704_charger_set_power(isp, 1);
-
-	switch (event) {
+	switch (isp->phy->last_event) {
 	case USB_EVENT_VBUS:
-		isp->online = true;
+		/* do not call wall charger detection more times */
+		if (!isp->present) {
+			isp->online = true;
+			isp->present = 1;
+			isp1704_charger_set_power(isp, 1);
+
+			/* detect wall charger */
+			if (isp1704_charger_detect_dcp(isp)) {
+				isp->psy.type = POWER_SUPPLY_TYPE_USB_DCP;
+				isp->current_max = 1800;
+			} else {
+				isp->psy.type = POWER_SUPPLY_TYPE_USB;
+				isp->current_max = 500;
+			}
 
-		/* detect charger */
-		detect = isp1704_charger_detect(isp);
-
-		if (detect) {
-			isp->present = detect;
-			isp->psy.type = isp1704_charger_type(isp);
+			/* enable data pullups */
+			if (isp->phy->otg->gadget)
+				usb_gadget_connect(isp->phy->otg->gadget);
 		}
 
-		switch (isp->psy.type) {
-		case POWER_SUPPLY_TYPE_USB_DCP:
-			isp->current_max = 1800;
-			break;
-		case POWER_SUPPLY_TYPE_USB_CDP:
+		if (isp->psy.type != POWER_SUPPLY_TYPE_USB_DCP) {
 			/*
 			 * Only 500mA here or high speed chirp
 			 * handshaking may break
 			 */
-			isp->current_max = 500;
-			/* FALLTHROUGH */
-		case POWER_SUPPLY_TYPE_USB:
-		default:
-			/* enable data pullups */
-			if (isp->phy->otg->gadget)
-				usb_gadget_connect(isp->phy->otg->gadget);
+			if (isp->current_max > 500)
+				isp->current_max = 500;
+
+			if (isp->current_max > 100)
+				isp->psy.type = POWER_SUPPLY_TYPE_USB_CDP;
 		}
 		break;
 	case USB_EVENT_NONE:
 		isp->online = false;
-		isp->current_max = 0;
 		isp->present = 0;
 		isp->current_max = 0;
 		isp->psy.type = POWER_SUPPLY_TYPE_USB;
@@ -298,12 +298,6 @@ static void isp1704_charger_work(struct work_struct *data)
 
 		isp1704_charger_set_power(isp, 0);
 		break;
-	case USB_EVENT_ENUMERATED:
-		if (isp->present)
-			isp->current_max = 1800;
-		else
-			isp->current_max = power;
-		break;
 	default:
 		goto out;
 	}
@@ -314,16 +308,11 @@ out:
 }
 
 static int isp1704_notifier_call(struct notifier_block *nb,
-		unsigned long event, void *power)
+		unsigned long val, void *v)
 {
 	struct isp1704_charger *isp =
 		container_of(nb, struct isp1704_charger, nb);
 
-	isp->event = event;
-
-	if (power)
-		isp->max_power = *((unsigned *)power);
-
 	schedule_work(&isp->work);
 
 	return NOTIFY_OK;
@@ -462,13 +451,13 @@ static int isp1704_charger_probe(struct platform_device *pdev)
 	if (isp->phy->otg->gadget)
 		usb_gadget_disconnect(isp->phy->otg->gadget);
 
+	if (isp->phy->last_event == USB_EVENT_NONE)
+		isp1704_charger_set_power(isp, 0);
+
 	/* Detect charger if VBUS is valid (the cable was already plugged). */
-	ret = isp1704_read(isp, ULPI_USB_INT_STS);
-	isp1704_charger_set_power(isp, 0);
-	if ((ret & ULPI_INT_VBUS_VALID) && !isp->phy->otg->default_a) {
-		isp->event = USB_EVENT_VBUS;
+	if (isp->phy->last_event == USB_EVENT_VBUS &&
+			!isp->phy->otg->default_a)
 		schedule_work(&isp->work);
-	}
 
 	return 0;
 fail2:
-- 
1.7.10.4

[PATCH 3/4] power: isp1704_charger: Add callback function set_current

[Pali Rohár]

This patch add callback function set_current to platform data.
Driver will call this function when isp1704 change current
and board provided this callback funtion in platform data.

This patch is needed for Nokia RX-51 to tell bq2415x charging
chip about connected wallcharger events.

Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
---
 drivers/power/isp1704_charger.c       |   16 ++++++++++++++++
 include/linux/power/isp1704_charger.h |    1 +
 2 files changed, 17 insertions(+)

diff --git a/drivers/power/isp1704_charger.c b/drivers/power/isp1704_charger.c
index f726cb6..4f20a1a 100644
--- a/drivers/power/isp1704_charger.c
+++ b/drivers/power/isp1704_charger.c
@@ -91,6 +91,18 @@ static void isp1704_charger_set_power(struct isp1704_charger *isp, bool on)
 }
 
 /*
+ * Set charger current from isp1704 if a function for it
+ * has been provided with platform data.
+ */
+static void isp1704_charger_set_current(struct isp1704_charger *isp, int mA)
+{
+	struct isp1704_charger_data *board = isp->dev->platform_data;
+
+	if (board && board->set_current)
+		board->set_current(mA);
+}
+
+/*
  * Determine is the charging port DCP (dedicated charger) or CDP (Host/HUB
  * chargers).
  *
@@ -257,6 +269,7 @@ static void isp1704_charger_work(struct work_struct *data)
 			if (isp1704_charger_detect_dcp(isp)) {
 				isp->psy.type = POWER_SUPPLY_TYPE_USB_DCP;
 				isp->current_max = 1800;
+				isp1704_charger_set_current(isp, 1800);
 			} else {
 				isp->psy.type = POWER_SUPPLY_TYPE_USB;
 				isp->current_max = 500;
@@ -277,6 +290,8 @@ static void isp1704_charger_work(struct work_struct *data)
 
 			if (isp->current_max > 100)
 				isp->psy.type = POWER_SUPPLY_TYPE_USB_CDP;
+
+			isp1704_charger_set_current(isp, isp->current_max);
 		}
 		break;
 	case USB_EVENT_NONE:
@@ -297,6 +312,7 @@ static void isp1704_charger_work(struct work_struct *data)
 			usb_gadget_disconnect(isp->phy->otg->gadget);
 
 		isp1704_charger_set_power(isp, 0);
+		isp1704_charger_set_current(isp, 0);
 		break;
 	default:
 		goto out;
diff --git a/include/linux/power/isp1704_charger.h b/include/linux/power/isp1704_charger.h
index 68096a6..d154b02 100644
--- a/include/linux/power/isp1704_charger.h
+++ b/include/linux/power/isp1704_charger.h
@@ -24,6 +24,7 @@
 
 struct isp1704_charger_data {
 	void		(*set_power)(bool on);
+	void		(*set_current)(int mA);
 };
 
 #endif
-- 
1.7.10.4

[PATCH 3/4] power: isp1704_charger: Add callback function set_current

[Pali Rohár]

This patch add callback function set_current to platform data.
Driver will call this function when isp1704 change current
and board provided this callback funtion in platform data.

This patch is needed for Nokia RX-51 to tell bq2415x charging
chip about connected wallcharger events.

Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>
---
 drivers/power/isp1704_charger.c       |   16 ++++++++++++++++
 include/linux/power/isp1704_charger.h |    1 +
 2 files changed, 17 insertions(+)

diff --git a/drivers/power/isp1704_charger.c b/drivers/power/isp1704_charger.c
index f726cb6..4f20a1a 100644
--- a/drivers/power/isp1704_charger.c
+++ b/drivers/power/isp1704_charger.c
@@ -91,6 +91,18 @@ static void isp1704_charger_set_power(struct isp1704_charger *isp, bool on)
 }
 
 /*
+ * Set charger current from isp1704 if a function for it
+ * has been provided with platform data.
+ */
+static void isp1704_charger_set_current(struct isp1704_charger *isp, int mA)
+{
+	struct isp1704_charger_data *board = isp->dev->platform_data;
+
+	if (board && board->set_current)
+		board->set_current(mA);
+}
+
+/*
  * Determine is the charging port DCP (dedicated charger) or CDP (Host/HUB
  * chargers).
  *
@@ -257,6 +269,7 @@ static void isp1704_charger_work(struct work_struct *data)
 			if (isp1704_charger_detect_dcp(isp)) {
 				isp->psy.type = POWER_SUPPLY_TYPE_USB_DCP;
 				isp->current_max = 1800;
+				isp1704_charger_set_current(isp, 1800);
 			} else {
 				isp->psy.type = POWER_SUPPLY_TYPE_USB;
 				isp->current_max = 500;
@@ -277,6 +290,8 @@ static void isp1704_charger_work(struct work_struct *data)
 
 			if (isp->current_max > 100)
 				isp->psy.type = POWER_SUPPLY_TYPE_USB_CDP;
+
+			isp1704_charger_set_current(isp, isp->current_max);
 		}
 		break;
 	case USB_EVENT_NONE:
@@ -297,6 +312,7 @@ static void isp1704_charger_work(struct work_struct *data)
 			usb_gadget_disconnect(isp->phy->otg->gadget);
 
 		isp1704_charger_set_power(isp, 0);
+		isp1704_charger_set_current(isp, 0);
 		break;
 	default:
 		goto out;
diff --git a/include/linux/power/isp1704_charger.h b/include/linux/power/isp1704_charger.h
index 68096a6..d154b02 100644
--- a/include/linux/power/isp1704_charger.h
+++ b/include/linux/power/isp1704_charger.h
@@ -24,6 +24,7 @@
 
 struct isp1704_charger_data {
 	void		(*set_power)(bool on);
+	void		(*set_current)(int mA);
 };
 
 #endif
-- 
1.7.10.4

[PATCH 4/4] RX-51: Add platform function and data for bq24150a charger

[Pali Rohár]

This patch will register bq24150a charger in RX-51 board data.
Patch also adding platform function between isp1704 and bq2415x
drivers for detecting charger type.

So finally charging battery on Nokia N900 (RX-51) working
automatically without any proprietary Nokia bits in userspace.

Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
---
 arch/arm/mach-omap2/board-rx51-peripherals.c |   56 +++++++++++++++++++++++++-
 1 file changed, 55 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 9c2dd10..a993ffe 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -25,6 +25,7 @@
 #include <linux/gpio_keys.h>
 #include <linux/mmc/host.h>
 #include <linux/power/isp1704_charger.h>
+#include <linux/power/bq2415x_charger.h>
 #include <linux/platform_data/spi-omap2-mcspi.h>
 #include <linux/platform_data/mtd-onenand-omap2.h>
 
@@ -270,6 +271,44 @@ static struct platform_device rx51_battery_device = {
 	.id	= -1,
 };
 
+static enum bq2415x_mode rx51_charger_mode = BQ2415X_MODE_OFF;
+static void *rx51_charger_hook_data;
+static void (*rx51_charger_hook)(enum bq2415x_mode mode, void *data);
+
+static int rx51_charger_set_hook(
+		void (*hook)(enum bq2415x_mode mode, void *data), void *data)
+{
+	rx51_charger_hook = hook;
+	rx51_charger_hook_data = data;
+	if (rx51_charger_hook)
+		rx51_charger_hook(rx51_charger_mode, rx51_charger_hook_data);
+	return 1;
+}
+
+static void rx51_charger_set_current(int mA)
+{
+	enum bq2415x_mode mode;
+
+	pr_info("RX-51: Charger current limit is %d mA\n", mA);
+
+	if (mA == 0)
+		mode = BQ2415X_MODE_OFF;
+	else if (mA < 500)
+		mode = BQ2415X_MODE_NONE;
+	else if (mA < 1800)
+		mode = BQ2415X_MODE_HOST_CHARGER;
+	else
+		mode = BQ2415X_MODE_DEDICATED_CHARGER;
+
+	if (rx51_charger_mode == mode)
+		return;
+
+	rx51_charger_mode = mode;
+
+	if (rx51_charger_hook)
+		rx51_charger_hook(rx51_charger_mode, rx51_charger_hook_data);
+}
+
 static void rx51_charger_set_power(bool on)
 {
 	gpio_set_value(RX51_USB_TRANSCEIVER_RST_GPIO, on);
@@ -277,6 +316,7 @@ static void rx51_charger_set_power(bool on)
 
 static struct isp1704_charger_data rx51_charger_data = {
 	.set_power	= rx51_charger_set_power,
+	.set_current	= rx51_charger_set_current,
 };
 
 static struct platform_device rx51_charger_device = {
@@ -1017,6 +1057,16 @@ static struct aic3x_pdata rx51_aic3x_data2 = {
 	.gpio_reset = 60,
 };
 
+static struct bq2415x_platform_data rx51_bq24150a_platform_data = {
+	.current_limit = 100,			/* mA */
+	.weak_battery_voltage = 3400,		/* mV */
+	.battery_regulation_voltage = 4200,	/* mV */
+	.charge_current = 650,			/* mA */
+	.termination_current = 100,		/* mA */
+	.resistor_sense = 68,			/* m ohm */
+	.set_mode_hook = &rx51_charger_set_hook,
+};
+
 static struct i2c_board_info __initdata rx51_peripherals_i2c_board_info_2[] = {
 	{
 		I2C_BOARD_INFO("tlv320aic3x", 0x18),
@@ -1044,7 +1094,11 @@ static struct i2c_board_info __initdata rx51_peripherals_i2c_board_info_2[] = {
 	{
 		I2C_BOARD_INFO("tpa6130a2", 0x60),
 		.platform_data = &rx51_tpa6130a2_data,
-	}
+	},
+	{
+		I2C_BOARD_INFO("bq24150a", 0x6b),
+		.platform_data = &rx51_bq24150a_platform_data,
+	},
 };
 
 static struct i2c_board_info __initdata rx51_peripherals_i2c_board_info_3[] = {
-- 
1.7.10.4

[PATCH 4/4] RX-51: Add platform function and data for bq24150a charger

[Pali Rohár]

This patch will register bq24150a charger in RX-51 board data.
Patch also adding platform function between isp1704 and bq2415x
drivers for detecting charger type.

So finally charging battery on Nokia N900 (RX-51) working
automatically without any proprietary Nokia bits in userspace.

Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>
---
 arch/arm/mach-omap2/board-rx51-peripherals.c |   56 +++++++++++++++++++++++++-
 1 file changed, 55 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 9c2dd10..a993ffe 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -25,6 +25,7 @@
 #include <linux/gpio_keys.h>
 #include <linux/mmc/host.h>
 #include <linux/power/isp1704_charger.h>
+#include <linux/power/bq2415x_charger.h>
 #include <linux/platform_data/spi-omap2-mcspi.h>
 #include <linux/platform_data/mtd-onenand-omap2.h>
 
@@ -270,6 +271,44 @@ static struct platform_device rx51_battery_device = {
 	.id	= -1,
 };
 
+static enum bq2415x_mode rx51_charger_mode = BQ2415X_MODE_OFF;
+static void *rx51_charger_hook_data;
+static void (*rx51_charger_hook)(enum bq2415x_mode mode, void *data);
+
+static int rx51_charger_set_hook(
+		void (*hook)(enum bq2415x_mode mode, void *data), void *data)
+{
+	rx51_charger_hook = hook;
+	rx51_charger_hook_data = data;
+	if (rx51_charger_hook)
+		rx51_charger_hook(rx51_charger_mode, rx51_charger_hook_data);
+	return 1;
+}
+
+static void rx51_charger_set_current(int mA)
+{
+	enum bq2415x_mode mode;
+
+	pr_info("RX-51: Charger current limit is %d mA\n", mA);
+
+	if (mA == 0)
+		mode = BQ2415X_MODE_OFF;
+	else if (mA < 500)
+		mode = BQ2415X_MODE_NONE;
+	else if (mA < 1800)
+		mode = BQ2415X_MODE_HOST_CHARGER;
+	else
+		mode = BQ2415X_MODE_DEDICATED_CHARGER;
+
+	if (rx51_charger_mode == mode)
+		return;
+
+	rx51_charger_mode = mode;
+
+	if (rx51_charger_hook)
+		rx51_charger_hook(rx51_charger_mode, rx51_charger_hook_data);
+}
+
 static void rx51_charger_set_power(bool on)
 {
 	gpio_set_value(RX51_USB_TRANSCEIVER_RST_GPIO, on);
@@ -277,6 +316,7 @@ static void rx51_charger_set_power(bool on)
 
 static struct isp1704_charger_data rx51_charger_data = {
 	.set_power	= rx51_charger_set_power,
+	.set_current	= rx51_charger_set_current,
 };
 
 static struct platform_device rx51_charger_device = {
@@ -1017,6 +1057,16 @@ static struct aic3x_pdata rx51_aic3x_data2 = {
 	.gpio_reset = 60,
 };
 
+static struct bq2415x_platform_data rx51_bq24150a_platform_data = {
+	.current_limit = 100,			/* mA */
+	.weak_battery_voltage = 3400,		/* mV */
+	.battery_regulation_voltage = 4200,	/* mV */
+	.charge_current = 650,			/* mA */
+	.termination_current = 100,		/* mA */
+	.resistor_sense = 68,			/* m ohm */
+	.set_mode_hook = &rx51_charger_set_hook,
+};
+
 static struct i2c_board_info __initdata rx51_peripherals_i2c_board_info_2[] = {
 	{
 		I2C_BOARD_INFO("tlv320aic3x", 0x18),
@@ -1044,7 +1094,11 @@ static struct i2c_board_info __initdata rx51_peripherals_i2c_board_info_2[] = {
 	{
 		I2C_BOARD_INFO("tpa6130a2", 0x60),
 		.platform_data = &rx51_tpa6130a2_data,
-	}
+	},
+	{
+		I2C_BOARD_INFO("bq24150a", 0x6b),
+		.platform_data = &rx51_bq24150a_platform_data,
+	},
 };
 
 static struct i2c_board_info __initdata rx51_peripherals_i2c_board_info_3[] = {
-- 
1.7.10.4

Re: [PATCH 4/4] RX-51: Add platform function and data for bq24150a charger

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 783 bytes --]

Hi Pali,

On Sun, Sep 08, 2013 at 10:50:39AM +0200, Pali Rohár wrote:
> This patch will register bq24150a charger in RX-51 board data.
> Patch also adding platform function between isp1704 and bq2415x
> drivers for detecting charger type.
> 
> So finally charging battery on Nokia N900 (RX-51) working
> automatically without any proprietary Nokia bits in userspace.

cool :)

> index 9c2dd10..a993ffe 100644
> --- a/arch/arm/mach-omap2/board-rx51-peripherals.c
> +++ b/arch/arm/mach-omap2/board-rx51-peripherals.c

AFAIK platform code for omap3 based boards is supposed to be removed
in the near future [0]. Device Tree does not support the glue layer, so
probably a small rx51 specific driver is needed.

[0] https://lkml.org/lkml/2013/8/12/70

-- Sebastian

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[PATCH 4/4] RX-51: Add platform function and data for bq24150a charger

[Sebastian Reichel]

Hi Pali,

On Sun, Sep 08, 2013 at 10:50:39AM +0200, Pali Roh?r wrote:
> This patch will register bq24150a charger in RX-51 board data.
> Patch also adding platform function between isp1704 and bq2415x
> drivers for detecting charger type.
> 
> So finally charging battery on Nokia N900 (RX-51) working
> automatically without any proprietary Nokia bits in userspace.

cool :)

> index 9c2dd10..a993ffe 100644
> --- a/arch/arm/mach-omap2/board-rx51-peripherals.c
> +++ b/arch/arm/mach-omap2/board-rx51-peripherals.c

AFAIK platform code for omap3 based boards is supposed to be removed
in the near future [0]. Device Tree does not support the glue layer, so
probably a small rx51 specific driver is needed.

[0] https://lkml.org/lkml/2013/8/12/70

-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130909/f57a5e5d/attachment-0001.sig>

Re: [PATCH 0/4] Add support for charging battery in Nokia RX-51

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 973 bytes --]

On Sunday 08 September 2013 10:50:35 Pali Rohár wrote:
> This patch series finally bringing support for charging
> battery on Nokia N900 (RX-51) without any proprietary Nokia
> bits in userspace.
> 
> Pali Rohár (4):
>   usb: musb: Call atomic_notifier_call_chain when status is
> changed power: isp1704_charger: Fix driver to work with
> changes introduced in v3.5
>   power: isp1704_charger: Add callback function set_current
>   RX-51: Add platform function and data for bq24150a charger
> 
>  arch/arm/mach-omap2/board-rx51-peripherals.c |   56
> +++++++++++++- drivers/power/isp1704_charger.c              |
>  107 ++++++++++++++------------ drivers/usb/musb/omap2430.c  
>                |    3 + drivers/usb/phy/phy-twl4030-usb.c    
>        |    2 + include/linux/power/isp1704_charger.h       
> |    1 + 5 files changed, 117 insertions(+), 52 deletions(-)

Hello, can you review this patch series?

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[PATCH 0/4] Add support for charging battery in Nokia RX-51

[Pali Rohár]

On Sunday 08 September 2013 10:50:35 Pali Roh?r wrote:
> This patch series finally bringing support for charging
> battery on Nokia N900 (RX-51) without any proprietary Nokia
> bits in userspace.
> 
> Pali Roh?r (4):
>   usb: musb: Call atomic_notifier_call_chain when status is
> changed power: isp1704_charger: Fix driver to work with
> changes introduced in v3.5
>   power: isp1704_charger: Add callback function set_current
>   RX-51: Add platform function and data for bq24150a charger
> 
>  arch/arm/mach-omap2/board-rx51-peripherals.c |   56
> +++++++++++++- drivers/power/isp1704_charger.c              |
>  107 ++++++++++++++------------ drivers/usb/musb/omap2430.c  
>                |    3 + drivers/usb/phy/phy-twl4030-usb.c    
>        |    2 + include/linux/power/isp1704_charger.h       
> |    1 + 5 files changed, 117 insertions(+), 52 deletions(-)

Hello, can you review this patch series?

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130914/5e97a21a/attachment.sig>

Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1603 bytes --]

On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Rohár wrote:
> More power supply drivers depends on vbus events and without it they not
> working. Power supply drivers using usb_register_notifier, so to deliver
> events it is needed to call atomic_notifier_call_chain.
> 
> So without atomic notifier power supply driver isp1704 not retrieving
> vbus status and reporting bogus values to userspace and also to board
> platform data functions. Without proper data charger drivers trying to
> charge battery also when charger is disconnected or do not start charging
> when wallcharger connects.
> 
> Atomic notifier in musb driver was used before v3.5 and was replaced with
> omap mailbox. This patch adding atomic_notifier_call_chain call from
> function omap_musb_set_mailbox.
> 
> Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> ---
>  drivers/usb/musb/omap2430.c       |    3 +++
>  drivers/usb/phy/phy-twl4030-usb.c |    2 ++
>  2 files changed, 5 insertions(+)
> 
> diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
> index f44e8b5..5c40252 100644
> --- a/drivers/usb/musb/omap2430.c
> +++ b/drivers/usb/musb/omap2430.c
> @@ -305,6 +305,9 @@ static void omap_musb_set_mailbox(struct omap2430_glue *glue)
>  	default:
>  		dev_dbg(dev, "ID float\n");
>  	}
> +
> +	atomic_notifier_call_chain(&musb->xceiv->notifier,
> +			musb->xceiv->last_event, NULL);

let's add a wrapper for this:

static inline int usb_phy_notify(struct usb phy *x, unsigned val, void *v)
{
	return atomic_notifier_call_chain(&x->notifier, val, v);
}

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1603 bytes --]

On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Rohár wrote:
> More power supply drivers depends on vbus events and without it they not
> working. Power supply drivers using usb_register_notifier, so to deliver
> events it is needed to call atomic_notifier_call_chain.
> 
> So without atomic notifier power supply driver isp1704 not retrieving
> vbus status and reporting bogus values to userspace and also to board
> platform data functions. Without proper data charger drivers trying to
> charge battery also when charger is disconnected or do not start charging
> when wallcharger connects.
> 
> Atomic notifier in musb driver was used before v3.5 and was replaced with
> omap mailbox. This patch adding atomic_notifier_call_chain call from
> function omap_musb_set_mailbox.
> 
> Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> ---
>  drivers/usb/musb/omap2430.c       |    3 +++
>  drivers/usb/phy/phy-twl4030-usb.c |    2 ++
>  2 files changed, 5 insertions(+)
> 
> diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
> index f44e8b5..5c40252 100644
> --- a/drivers/usb/musb/omap2430.c
> +++ b/drivers/usb/musb/omap2430.c
> @@ -305,6 +305,9 @@ static void omap_musb_set_mailbox(struct omap2430_glue *glue)
>  	default:
>  		dev_dbg(dev, "ID float\n");
>  	}
> +
> +	atomic_notifier_call_chain(&musb->xceiv->notifier,
> +			musb->xceiv->last_event, NULL);

let's add a wrapper for this:

static inline int usb_phy_notify(struct usb phy *x, unsigned val, void *v)
{
	return atomic_notifier_call_chain(&x->notifier, val, v);
}

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Felipe Balbi]

On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Roh?r wrote:
> More power supply drivers depends on vbus events and without it they not
> working. Power supply drivers using usb_register_notifier, so to deliver
> events it is needed to call atomic_notifier_call_chain.
> 
> So without atomic notifier power supply driver isp1704 not retrieving
> vbus status and reporting bogus values to userspace and also to board
> platform data functions. Without proper data charger drivers trying to
> charge battery also when charger is disconnected or do not start charging
> when wallcharger connects.
> 
> Atomic notifier in musb driver was used before v3.5 and was replaced with
> omap mailbox. This patch adding atomic_notifier_call_chain call from
> function omap_musb_set_mailbox.
> 
> Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>
> ---
>  drivers/usb/musb/omap2430.c       |    3 +++
>  drivers/usb/phy/phy-twl4030-usb.c |    2 ++
>  2 files changed, 5 insertions(+)
> 
> diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
> index f44e8b5..5c40252 100644
> --- a/drivers/usb/musb/omap2430.c
> +++ b/drivers/usb/musb/omap2430.c
> @@ -305,6 +305,9 @@ static void omap_musb_set_mailbox(struct omap2430_glue *glue)
>  	default:
>  		dev_dbg(dev, "ID float\n");
>  	}
> +
> +	atomic_notifier_call_chain(&musb->xceiv->notifier,
> +			musb->xceiv->last_event, NULL);

let's add a wrapper for this:

static inline int usb_phy_notify(struct usb phy *x, unsigned val, void *v)
{
	return atomic_notifier_call_chain(&x->notifier, val, v);
}

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130917/df17f742/attachment-0001.sig>

Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 580 bytes --]

On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Rohár wrote:
> diff --git a/drivers/usb/phy/phy-twl4030-usb.c b/drivers/usb/phy/phy-twl4030-usb.c
> index 8f78d2d..efe6155 100644
> --- a/drivers/usb/phy/phy-twl4030-usb.c
> +++ b/drivers/usb/phy/phy-twl4030-usb.c
> @@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct platform_device *pdev)
>  	if (device_create_file(&pdev->dev, &dev_attr_vbus))
>  		dev_warn(&pdev->dev, "could not create sysfs file\n");
>  
> +	ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);

BTW, this is a bugfix, send separately.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Felipe Balbi]

[-- Attachment #1.1: Type: text/plain, Size: 580 bytes --]

On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Rohár wrote:
> diff --git a/drivers/usb/phy/phy-twl4030-usb.c b/drivers/usb/phy/phy-twl4030-usb.c
> index 8f78d2d..efe6155 100644
> --- a/drivers/usb/phy/phy-twl4030-usb.c
> +++ b/drivers/usb/phy/phy-twl4030-usb.c
> @@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct platform_device *pdev)
>  	if (device_create_file(&pdev->dev, &dev_attr_vbus))
>  		dev_warn(&pdev->dev, "could not create sysfs file\n");
>  
> +	ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);

BTW, this is a bugfix, send separately.

-- 
balbi

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Felipe Balbi]

On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Roh?r wrote:
> diff --git a/drivers/usb/phy/phy-twl4030-usb.c b/drivers/usb/phy/phy-twl4030-usb.c
> index 8f78d2d..efe6155 100644
> --- a/drivers/usb/phy/phy-twl4030-usb.c
> +++ b/drivers/usb/phy/phy-twl4030-usb.c
> @@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct platform_device *pdev)
>  	if (device_create_file(&pdev->dev, &dev_attr_vbus))
>  		dev_warn(&pdev->dev, "could not create sysfs file\n");
>  
> +	ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);

BTW, this is a bugfix, send separately.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130917/dde12078/attachment.sig>

Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 2738 bytes --]

On Tuesday 17 September 2013 17:48:59 you wrote:
> On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Rohár wrote:
> > More power supply drivers depends on vbus events and without
> > it they not working. Power supply drivers using
> > usb_register_notifier, so to deliver events it is needed to
> > call atomic_notifier_call_chain.
> > 
> > So without atomic notifier power supply driver isp1704 not
> > retrieving vbus status and reporting bogus values to
> > userspace and also to board platform data functions.
> > Without proper data charger drivers trying to charge
> > battery also when charger is disconnected or do not start
> > charging when wallcharger connects.
> > 
> > Atomic notifier in musb driver was used before v3.5 and was
> > replaced with omap mailbox. This patch adding
> > atomic_notifier_call_chain call from function
> > omap_musb_set_mailbox.
> > 
> > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> > ---
> > 
> >  drivers/usb/musb/omap2430.c       |    3 +++
> >  drivers/usb/phy/phy-twl4030-usb.c |    2 ++
> >  2 files changed, 5 insertions(+)
> > 
> > diff --git a/drivers/usb/musb/omap2430.c
> > b/drivers/usb/musb/omap2430.c index f44e8b5..5c40252 100644
> > --- a/drivers/usb/musb/omap2430.c
> > +++ b/drivers/usb/musb/omap2430.c
> > @@ -305,6 +305,9 @@ static void omap_musb_set_mailbox(struct
> > omap2430_glue *glue)
> > 
> >  	default:
> >  		dev_dbg(dev, "ID float\n");
> >  	
> >  	}
> > 
> > +
> > +	atomic_notifier_call_chain(&musb->xceiv->notifier,
> > +			musb->xceiv->last_event, NULL);
> 
> let's add a wrapper for this:
> 
> static inline int usb_phy_notify(struct usb phy *x, unsigned
> val, void *v) {
> 	return atomic_notifier_call_chain(&x->notifier, val, v);
> }

Where to add this wrapper? To omap2430.c? or some include file?

On Tuesday 17 September 2013 17:49:17 Felipe Balbi wrote:
> On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Rohár wrote:
> > diff --git a/drivers/usb/phy/phy-twl4030-usb.c
> > b/drivers/usb/phy/phy-twl4030-usb.c index 8f78d2d..efe6155
> > 100644
> > --- a/drivers/usb/phy/phy-twl4030-usb.c
> > +++ b/drivers/usb/phy/phy-twl4030-usb.c
> > @@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct
> > platform_device *pdev)
> > 
> >  	if (device_create_file(&pdev->dev, &dev_attr_vbus))
> >  	
> >  		dev_warn(&pdev->dev, "could not create sysfs file\n");
> > 
> > +	ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
> 
> BTW, this is a bugfix, send separately.

What to send separately?

This full patch 1/4 is bugfix. And I did not understand what you 
want. Maybe it could be easier for you to apply this small 3+2 
lines patch how you need.

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 2798 bytes --]

On Tuesday 17 September 2013 17:48:59 you wrote:
> On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Rohár wrote:
> > More power supply drivers depends on vbus events and without
> > it they not working. Power supply drivers using
> > usb_register_notifier, so to deliver events it is needed to
> > call atomic_notifier_call_chain.
> > 
> > So without atomic notifier power supply driver isp1704 not
> > retrieving vbus status and reporting bogus values to
> > userspace and also to board platform data functions.
> > Without proper data charger drivers trying to charge
> > battery also when charger is disconnected or do not start
> > charging when wallcharger connects.
> > 
> > Atomic notifier in musb driver was used before v3.5 and was
> > replaced with omap mailbox. This patch adding
> > atomic_notifier_call_chain call from function
> > omap_musb_set_mailbox.
> > 
> > Signed-off-by: Pali Rohár <pali.rohar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > ---
> > 
> >  drivers/usb/musb/omap2430.c       |    3 +++
> >  drivers/usb/phy/phy-twl4030-usb.c |    2 ++
> >  2 files changed, 5 insertions(+)
> > 
> > diff --git a/drivers/usb/musb/omap2430.c
> > b/drivers/usb/musb/omap2430.c index f44e8b5..5c40252 100644
> > --- a/drivers/usb/musb/omap2430.c
> > +++ b/drivers/usb/musb/omap2430.c
> > @@ -305,6 +305,9 @@ static void omap_musb_set_mailbox(struct
> > omap2430_glue *glue)
> > 
> >  	default:
> >  		dev_dbg(dev, "ID float\n");
> >  	
> >  	}
> > 
> > +
> > +	atomic_notifier_call_chain(&musb->xceiv->notifier,
> > +			musb->xceiv->last_event, NULL);
> 
> let's add a wrapper for this:
> 
> static inline int usb_phy_notify(struct usb phy *x, unsigned
> val, void *v) {
> 	return atomic_notifier_call_chain(&x->notifier, val, v);
> }

Where to add this wrapper? To omap2430.c? or some include file?

On Tuesday 17 September 2013 17:49:17 Felipe Balbi wrote:
> On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Rohár wrote:
> > diff --git a/drivers/usb/phy/phy-twl4030-usb.c
> > b/drivers/usb/phy/phy-twl4030-usb.c index 8f78d2d..efe6155
> > 100644
> > --- a/drivers/usb/phy/phy-twl4030-usb.c
> > +++ b/drivers/usb/phy/phy-twl4030-usb.c
> > @@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct
> > platform_device *pdev)
> > 
> >  	if (device_create_file(&pdev->dev, &dev_attr_vbus))
> >  	
> >  		dev_warn(&pdev->dev, "could not create sysfs file\n");
> > 
> > +	ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
> 
> BTW, this is a bugfix, send separately.

What to send separately?

This full patch 1/4 is bugfix. And I did not understand what you 
want. Maybe it could be easier for you to apply this small 3+2 
lines patch how you need.

-- 
Pali Rohár
pali.rohar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Pali Rohár]

On Tuesday 17 September 2013 17:48:59 you wrote:
> On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Roh?r wrote:
> > More power supply drivers depends on vbus events and without
> > it they not working. Power supply drivers using
> > usb_register_notifier, so to deliver events it is needed to
> > call atomic_notifier_call_chain.
> > 
> > So without atomic notifier power supply driver isp1704 not
> > retrieving vbus status and reporting bogus values to
> > userspace and also to board platform data functions.
> > Without proper data charger drivers trying to charge
> > battery also when charger is disconnected or do not start
> > charging when wallcharger connects.
> > 
> > Atomic notifier in musb driver was used before v3.5 and was
> > replaced with omap mailbox. This patch adding
> > atomic_notifier_call_chain call from function
> > omap_musb_set_mailbox.
> > 
> > Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>
> > ---
> > 
> >  drivers/usb/musb/omap2430.c       |    3 +++
> >  drivers/usb/phy/phy-twl4030-usb.c |    2 ++
> >  2 files changed, 5 insertions(+)
> > 
> > diff --git a/drivers/usb/musb/omap2430.c
> > b/drivers/usb/musb/omap2430.c index f44e8b5..5c40252 100644
> > --- a/drivers/usb/musb/omap2430.c
> > +++ b/drivers/usb/musb/omap2430.c
> > @@ -305,6 +305,9 @@ static void omap_musb_set_mailbox(struct
> > omap2430_glue *glue)
> > 
> >  	default:
> >  		dev_dbg(dev, "ID float\n");
> >  	
> >  	}
> > 
> > +
> > +	atomic_notifier_call_chain(&musb->xceiv->notifier,
> > +			musb->xceiv->last_event, NULL);
> 
> let's add a wrapper for this:
> 
> static inline int usb_phy_notify(struct usb phy *x, unsigned
> val, void *v) {
> 	return atomic_notifier_call_chain(&x->notifier, val, v);
> }

Where to add this wrapper? To omap2430.c? or some include file?

On Tuesday 17 September 2013 17:49:17 Felipe Balbi wrote:
> On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Roh?r wrote:
> > diff --git a/drivers/usb/phy/phy-twl4030-usb.c
> > b/drivers/usb/phy/phy-twl4030-usb.c index 8f78d2d..efe6155
> > 100644
> > --- a/drivers/usb/phy/phy-twl4030-usb.c
> > +++ b/drivers/usb/phy/phy-twl4030-usb.c
> > @@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct
> > platform_device *pdev)
> > 
> >  	if (device_create_file(&pdev->dev, &dev_attr_vbus))
> >  	
> >  		dev_warn(&pdev->dev, "could not create sysfs file\n");
> > 
> > +	ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
> 
> BTW, this is a bugfix, send separately.

What to send separately?

This full patch 1/4 is bugfix. And I did not understand what you 
want. Maybe it could be easier for you to apply this small 3+2 
lines patch how you need.

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130917/b9164414/attachment.sig>

Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 3031 bytes --]

On Tue, Sep 17, 2013 at 06:05:15PM +0200, Pali Rohár wrote:
> On Tuesday 17 September 2013 17:48:59 you wrote:
> > On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Rohár wrote:
> > > More power supply drivers depends on vbus events and without
> > > it they not working. Power supply drivers using
> > > usb_register_notifier, so to deliver events it is needed to
> > > call atomic_notifier_call_chain.
> > > 
> > > So without atomic notifier power supply driver isp1704 not
> > > retrieving vbus status and reporting bogus values to
> > > userspace and also to board platform data functions.
> > > Without proper data charger drivers trying to charge
> > > battery also when charger is disconnected or do not start
> > > charging when wallcharger connects.
> > > 
> > > Atomic notifier in musb driver was used before v3.5 and was
> > > replaced with omap mailbox. This patch adding
> > > atomic_notifier_call_chain call from function
> > > omap_musb_set_mailbox.
> > > 
> > > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> > > ---
> > > 
> > >  drivers/usb/musb/omap2430.c       |    3 +++
> > >  drivers/usb/phy/phy-twl4030-usb.c |    2 ++
> > >  2 files changed, 5 insertions(+)
> > > 
> > > diff --git a/drivers/usb/musb/omap2430.c
> > > b/drivers/usb/musb/omap2430.c index f44e8b5..5c40252 100644
> > > --- a/drivers/usb/musb/omap2430.c
> > > +++ b/drivers/usb/musb/omap2430.c
> > > @@ -305,6 +305,9 @@ static void omap_musb_set_mailbox(struct
> > > omap2430_glue *glue)
> > > 
> > >  	default:
> > >  		dev_dbg(dev, "ID float\n");
> > >  	
> > >  	}
> > > 
> > > +
> > > +	atomic_notifier_call_chain(&musb->xceiv->notifier,
> > > +			musb->xceiv->last_event, NULL);
> > 
> > let's add a wrapper for this:
> > 
> > static inline int usb_phy_notify(struct usb phy *x, unsigned
> > val, void *v) {
> > 	return atomic_notifier_call_chain(&x->notifier, val, v);
> > }
> 
> Where to add this wrapper? To omap2430.c? or some include file?

<linux/usb/phy.h>

> On Tuesday 17 September 2013 17:49:17 Felipe Balbi wrote:
> > On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Rohár wrote:
> > > diff --git a/drivers/usb/phy/phy-twl4030-usb.c
> > > b/drivers/usb/phy/phy-twl4030-usb.c index 8f78d2d..efe6155
> > > 100644
> > > --- a/drivers/usb/phy/phy-twl4030-usb.c
> > > +++ b/drivers/usb/phy/phy-twl4030-usb.c
> > > @@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct
> > > platform_device *pdev)
> > > 
> > >  	if (device_create_file(&pdev->dev, &dev_attr_vbus))
> > >  	
> > >  		dev_warn(&pdev->dev, "could not create sysfs file\n");
> > > 
> > > +	ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
> > 
> > BTW, this is a bugfix, send separately.
> 
> What to send separately?
> 
> This full patch 1/4 is bugfix. And I did not understand what you 
> want. Maybe it could be easier for you to apply this small 3+2 
> lines patch how you need.

This hunk here (initializaing notifier head) is a separate bug fix and
needs its own patch.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Felipe Balbi]

[-- Attachment #1.1: Type: text/plain, Size: 3031 bytes --]

On Tue, Sep 17, 2013 at 06:05:15PM +0200, Pali Rohár wrote:
> On Tuesday 17 September 2013 17:48:59 you wrote:
> > On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Rohár wrote:
> > > More power supply drivers depends on vbus events and without
> > > it they not working. Power supply drivers using
> > > usb_register_notifier, so to deliver events it is needed to
> > > call atomic_notifier_call_chain.
> > > 
> > > So without atomic notifier power supply driver isp1704 not
> > > retrieving vbus status and reporting bogus values to
> > > userspace and also to board platform data functions.
> > > Without proper data charger drivers trying to charge
> > > battery also when charger is disconnected or do not start
> > > charging when wallcharger connects.
> > > 
> > > Atomic notifier in musb driver was used before v3.5 and was
> > > replaced with omap mailbox. This patch adding
> > > atomic_notifier_call_chain call from function
> > > omap_musb_set_mailbox.
> > > 
> > > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> > > ---
> > > 
> > >  drivers/usb/musb/omap2430.c       |    3 +++
> > >  drivers/usb/phy/phy-twl4030-usb.c |    2 ++
> > >  2 files changed, 5 insertions(+)
> > > 
> > > diff --git a/drivers/usb/musb/omap2430.c
> > > b/drivers/usb/musb/omap2430.c index f44e8b5..5c40252 100644
> > > --- a/drivers/usb/musb/omap2430.c
> > > +++ b/drivers/usb/musb/omap2430.c
> > > @@ -305,6 +305,9 @@ static void omap_musb_set_mailbox(struct
> > > omap2430_glue *glue)
> > > 
> > >  	default:
> > >  		dev_dbg(dev, "ID float\n");
> > >  	
> > >  	}
> > > 
> > > +
> > > +	atomic_notifier_call_chain(&musb->xceiv->notifier,
> > > +			musb->xceiv->last_event, NULL);
> > 
> > let's add a wrapper for this:
> > 
> > static inline int usb_phy_notify(struct usb phy *x, unsigned
> > val, void *v) {
> > 	return atomic_notifier_call_chain(&x->notifier, val, v);
> > }
> 
> Where to add this wrapper? To omap2430.c? or some include file?

<linux/usb/phy.h>

> On Tuesday 17 September 2013 17:49:17 Felipe Balbi wrote:
> > On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Rohár wrote:
> > > diff --git a/drivers/usb/phy/phy-twl4030-usb.c
> > > b/drivers/usb/phy/phy-twl4030-usb.c index 8f78d2d..efe6155
> > > 100644
> > > --- a/drivers/usb/phy/phy-twl4030-usb.c
> > > +++ b/drivers/usb/phy/phy-twl4030-usb.c
> > > @@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct
> > > platform_device *pdev)
> > > 
> > >  	if (device_create_file(&pdev->dev, &dev_attr_vbus))
> > >  	
> > >  		dev_warn(&pdev->dev, "could not create sysfs file\n");
> > > 
> > > +	ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
> > 
> > BTW, this is a bugfix, send separately.
> 
> What to send separately?
> 
> This full patch 1/4 is bugfix. And I did not understand what you 
> want. Maybe it could be easier for you to apply this small 3+2 
> lines patch how you need.

This hunk here (initializaing notifier head) is a separate bug fix and
needs its own patch.

-- 
balbi

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Felipe Balbi]

On Tue, Sep 17, 2013 at 06:05:15PM +0200, Pali Roh?r wrote:
> On Tuesday 17 September 2013 17:48:59 you wrote:
> > On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Roh?r wrote:
> > > More power supply drivers depends on vbus events and without
> > > it they not working. Power supply drivers using
> > > usb_register_notifier, so to deliver events it is needed to
> > > call atomic_notifier_call_chain.
> > > 
> > > So without atomic notifier power supply driver isp1704 not
> > > retrieving vbus status and reporting bogus values to
> > > userspace and also to board platform data functions.
> > > Without proper data charger drivers trying to charge
> > > battery also when charger is disconnected or do not start
> > > charging when wallcharger connects.
> > > 
> > > Atomic notifier in musb driver was used before v3.5 and was
> > > replaced with omap mailbox. This patch adding
> > > atomic_notifier_call_chain call from function
> > > omap_musb_set_mailbox.
> > > 
> > > Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>
> > > ---
> > > 
> > >  drivers/usb/musb/omap2430.c       |    3 +++
> > >  drivers/usb/phy/phy-twl4030-usb.c |    2 ++
> > >  2 files changed, 5 insertions(+)
> > > 
> > > diff --git a/drivers/usb/musb/omap2430.c
> > > b/drivers/usb/musb/omap2430.c index f44e8b5..5c40252 100644
> > > --- a/drivers/usb/musb/omap2430.c
> > > +++ b/drivers/usb/musb/omap2430.c
> > > @@ -305,6 +305,9 @@ static void omap_musb_set_mailbox(struct
> > > omap2430_glue *glue)
> > > 
> > >  	default:
> > >  		dev_dbg(dev, "ID float\n");
> > >  	
> > >  	}
> > > 
> > > +
> > > +	atomic_notifier_call_chain(&musb->xceiv->notifier,
> > > +			musb->xceiv->last_event, NULL);
> > 
> > let's add a wrapper for this:
> > 
> > static inline int usb_phy_notify(struct usb phy *x, unsigned
> > val, void *v) {
> > 	return atomic_notifier_call_chain(&x->notifier, val, v);
> > }
> 
> Where to add this wrapper? To omap2430.c? or some include file?

<linux/usb/phy.h>

> On Tuesday 17 September 2013 17:49:17 Felipe Balbi wrote:
> > On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Roh?r wrote:
> > > diff --git a/drivers/usb/phy/phy-twl4030-usb.c
> > > b/drivers/usb/phy/phy-twl4030-usb.c index 8f78d2d..efe6155
> > > 100644
> > > --- a/drivers/usb/phy/phy-twl4030-usb.c
> > > +++ b/drivers/usb/phy/phy-twl4030-usb.c
> > > @@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct
> > > platform_device *pdev)
> > > 
> > >  	if (device_create_file(&pdev->dev, &dev_attr_vbus))
> > >  	
> > >  		dev_warn(&pdev->dev, "could not create sysfs file\n");
> > > 
> > > +	ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
> > 
> > BTW, this is a bugfix, send separately.
> 
> What to send separately?
> 
> This full patch 1/4 is bugfix. And I did not understand what you 
> want. Maybe it could be easier for you to apply this small 3+2 
> lines patch how you need.

This hunk here (initializaing notifier head) is a separate bug fix and
needs its own patch.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130917/a7e83fbb/attachment.sig>

Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 3410 bytes --]

On Tuesday 17 September 2013 18:08:35 Felipe Balbi wrote:
> On Tue, Sep 17, 2013 at 06:05:15PM +0200, Pali Rohár wrote:
> > On Tuesday 17 September 2013 17:48:59 you wrote:
> > > On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Rohár wrote:
> > > > More power supply drivers depends on vbus events and
> > > > without it they not working. Power supply drivers using
> > > > usb_register_notifier, so to deliver events it is
> > > > needed to call atomic_notifier_call_chain.
> > > > 
> > > > So without atomic notifier power supply driver isp1704
> > > > not retrieving vbus status and reporting bogus values
> > > > to userspace and also to board platform data functions.
> > > > Without proper data charger drivers trying to charge
> > > > battery also when charger is disconnected or do not
> > > > start charging when wallcharger connects.
> > > > 
> > > > Atomic notifier in musb driver was used before v3.5 and
> > > > was replaced with omap mailbox. This patch adding
> > > > atomic_notifier_call_chain call from function
> > > > omap_musb_set_mailbox.
> > > > 
> > > > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> > > > ---
> > > > 
> > > >  drivers/usb/musb/omap2430.c       |    3 +++
> > > >  drivers/usb/phy/phy-twl4030-usb.c |    2 ++
> > > >  2 files changed, 5 insertions(+)
> > > > 
> > > > diff --git a/drivers/usb/musb/omap2430.c
> > > > b/drivers/usb/musb/omap2430.c index f44e8b5..5c40252
> > > > 100644 --- a/drivers/usb/musb/omap2430.c
> > > > +++ b/drivers/usb/musb/omap2430.c
> > > > @@ -305,6 +305,9 @@ static void
> > > > omap_musb_set_mailbox(struct omap2430_glue *glue)
> > > > 
> > > >  	default:
> > > >  		dev_dbg(dev, "ID float\n");
> > > >  	
> > > >  	}
> > > > 
> > > > +
> > > > +	atomic_notifier_call_chain(&musb->xceiv->notifier,
> > > > +			musb->xceiv->last_event, NULL);
> > > 
> > > let's add a wrapper for this:
> > > 
> > > static inline int usb_phy_notify(struct usb phy *x,
> > > unsigned val, void *v) {
> > > 
> > > 	return atomic_notifier_call_chain(&x->notifier, val, v);
> > > 
> > > }
> > 
> > Where to add this wrapper? To omap2430.c? or some include
> > file?
> 
> <linux/usb/phy.h>
> 
> > On Tuesday 17 September 2013 17:49:17 Felipe Balbi wrote:
> > > On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Rohár wrote:
> > > > diff --git a/drivers/usb/phy/phy-twl4030-usb.c
> > > > b/drivers/usb/phy/phy-twl4030-usb.c index
> > > > 8f78d2d..efe6155 100644
> > > > --- a/drivers/usb/phy/phy-twl4030-usb.c
> > > > +++ b/drivers/usb/phy/phy-twl4030-usb.c
> > > > @@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct
> > > > platform_device *pdev)
> > > > 
> > > >  	if (device_create_file(&pdev->dev, &dev_attr_vbus))
> > > >  	
> > > >  		dev_warn(&pdev->dev, "could not create sysfs
> > > >  		file\n");
> > > > 
> > > > +	ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
> > > 
> > > BTW, this is a bugfix, send separately.
> > 
> > What to send separately?
> > 
> > This full patch 1/4 is bugfix. And I did not understand what
> > you want. Maybe it could be easier for you to apply this
> > small 3+2 lines patch how you need.
> 
> This hunk here (initializaing notifier head) is a separate bug
> fix and needs its own patch.

So will you do that? Or it is needed to resend this one line hunk 
again in new email again?

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Pali Rohár]

On Tuesday 17 September 2013 18:08:35 Felipe Balbi wrote:
> On Tue, Sep 17, 2013 at 06:05:15PM +0200, Pali Roh?r wrote:
> > On Tuesday 17 September 2013 17:48:59 you wrote:
> > > On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Roh?r wrote:
> > > > More power supply drivers depends on vbus events and
> > > > without it they not working. Power supply drivers using
> > > > usb_register_notifier, so to deliver events it is
> > > > needed to call atomic_notifier_call_chain.
> > > > 
> > > > So without atomic notifier power supply driver isp1704
> > > > not retrieving vbus status and reporting bogus values
> > > > to userspace and also to board platform data functions.
> > > > Without proper data charger drivers trying to charge
> > > > battery also when charger is disconnected or do not
> > > > start charging when wallcharger connects.
> > > > 
> > > > Atomic notifier in musb driver was used before v3.5 and
> > > > was replaced with omap mailbox. This patch adding
> > > > atomic_notifier_call_chain call from function
> > > > omap_musb_set_mailbox.
> > > > 
> > > > Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>
> > > > ---
> > > > 
> > > >  drivers/usb/musb/omap2430.c       |    3 +++
> > > >  drivers/usb/phy/phy-twl4030-usb.c |    2 ++
> > > >  2 files changed, 5 insertions(+)
> > > > 
> > > > diff --git a/drivers/usb/musb/omap2430.c
> > > > b/drivers/usb/musb/omap2430.c index f44e8b5..5c40252
> > > > 100644 --- a/drivers/usb/musb/omap2430.c
> > > > +++ b/drivers/usb/musb/omap2430.c
> > > > @@ -305,6 +305,9 @@ static void
> > > > omap_musb_set_mailbox(struct omap2430_glue *glue)
> > > > 
> > > >  	default:
> > > >  		dev_dbg(dev, "ID float\n");
> > > >  	
> > > >  	}
> > > > 
> > > > +
> > > > +	atomic_notifier_call_chain(&musb->xceiv->notifier,
> > > > +			musb->xceiv->last_event, NULL);
> > > 
> > > let's add a wrapper for this:
> > > 
> > > static inline int usb_phy_notify(struct usb phy *x,
> > > unsigned val, void *v) {
> > > 
> > > 	return atomic_notifier_call_chain(&x->notifier, val, v);
> > > 
> > > }
> > 
> > Where to add this wrapper? To omap2430.c? or some include
> > file?
> 
> <linux/usb/phy.h>
> 
> > On Tuesday 17 September 2013 17:49:17 Felipe Balbi wrote:
> > > On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Roh?r wrote:
> > > > diff --git a/drivers/usb/phy/phy-twl4030-usb.c
> > > > b/drivers/usb/phy/phy-twl4030-usb.c index
> > > > 8f78d2d..efe6155 100644
> > > > --- a/drivers/usb/phy/phy-twl4030-usb.c
> > > > +++ b/drivers/usb/phy/phy-twl4030-usb.c
> > > > @@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct
> > > > platform_device *pdev)
> > > > 
> > > >  	if (device_create_file(&pdev->dev, &dev_attr_vbus))
> > > >  	
> > > >  		dev_warn(&pdev->dev, "could not create sysfs
> > > >  		file\n");
> > > > 
> > > > +	ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
> > > 
> > > BTW, this is a bugfix, send separately.
> > 
> > What to send separately?
> > 
> > This full patch 1/4 is bugfix. And I did not understand what
> > you want. Maybe it could be easier for you to apply this
> > small 3+2 lines patch how you need.
> 
> This hunk here (initializaing notifier head) is a separate bug
> fix and needs its own patch.

So will you do that? Or it is needed to resend this one line hunk 
again in new email again?

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130917/2aec70d8/attachment.sig>

Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 3639 bytes --]

On Tue, Sep 17, 2013 at 09:28:42PM +0200, Pali Rohár wrote:
> On Tuesday 17 September 2013 18:08:35 Felipe Balbi wrote:
> > On Tue, Sep 17, 2013 at 06:05:15PM +0200, Pali Rohár wrote:
> > > On Tuesday 17 September 2013 17:48:59 you wrote:
> > > > On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Rohár wrote:
> > > > > More power supply drivers depends on vbus events and
> > > > > without it they not working. Power supply drivers using
> > > > > usb_register_notifier, so to deliver events it is
> > > > > needed to call atomic_notifier_call_chain.
> > > > > 
> > > > > So without atomic notifier power supply driver isp1704
> > > > > not retrieving vbus status and reporting bogus values
> > > > > to userspace and also to board platform data functions.
> > > > > Without proper data charger drivers trying to charge
> > > > > battery also when charger is disconnected or do not
> > > > > start charging when wallcharger connects.
> > > > > 
> > > > > Atomic notifier in musb driver was used before v3.5 and
> > > > > was replaced with omap mailbox. This patch adding
> > > > > atomic_notifier_call_chain call from function
> > > > > omap_musb_set_mailbox.
> > > > > 
> > > > > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> > > > > ---
> > > > > 
> > > > >  drivers/usb/musb/omap2430.c       |    3 +++
> > > > >  drivers/usb/phy/phy-twl4030-usb.c |    2 ++
> > > > >  2 files changed, 5 insertions(+)
> > > > > 
> > > > > diff --git a/drivers/usb/musb/omap2430.c
> > > > > b/drivers/usb/musb/omap2430.c index f44e8b5..5c40252
> > > > > 100644 --- a/drivers/usb/musb/omap2430.c
> > > > > +++ b/drivers/usb/musb/omap2430.c
> > > > > @@ -305,6 +305,9 @@ static void
> > > > > omap_musb_set_mailbox(struct omap2430_glue *glue)
> > > > > 
> > > > >  	default:
> > > > >  		dev_dbg(dev, "ID float\n");
> > > > >  	
> > > > >  	}
> > > > > 
> > > > > +
> > > > > +	atomic_notifier_call_chain(&musb->xceiv->notifier,
> > > > > +			musb->xceiv->last_event, NULL);
> > > > 
> > > > let's add a wrapper for this:
> > > > 
> > > > static inline int usb_phy_notify(struct usb phy *x,
> > > > unsigned val, void *v) {
> > > > 
> > > > 	return atomic_notifier_call_chain(&x->notifier, val, v);
> > > > 
> > > > }
> > > 
> > > Where to add this wrapper? To omap2430.c? or some include
> > > file?
> > 
> > <linux/usb/phy.h>
> > 
> > > On Tuesday 17 September 2013 17:49:17 Felipe Balbi wrote:
> > > > On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Rohár wrote:
> > > > > diff --git a/drivers/usb/phy/phy-twl4030-usb.c
> > > > > b/drivers/usb/phy/phy-twl4030-usb.c index
> > > > > 8f78d2d..efe6155 100644
> > > > > --- a/drivers/usb/phy/phy-twl4030-usb.c
> > > > > +++ b/drivers/usb/phy/phy-twl4030-usb.c
> > > > > @@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct
> > > > > platform_device *pdev)
> > > > > 
> > > > >  	if (device_create_file(&pdev->dev, &dev_attr_vbus))
> > > > >  	
> > > > >  		dev_warn(&pdev->dev, "could not create sysfs
> > > > >  		file\n");
> > > > > 
> > > > > +	ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
> > > > 
> > > > BTW, this is a bugfix, send separately.
> > > 
> > > What to send separately?
> > > 
> > > This full patch 1/4 is bugfix. And I did not understand what
> > > you want. Maybe it could be easier for you to apply this
> > > small 3+2 lines patch how you need.
> > 
> > This hunk here (initializaing notifier head) is a separate bug
> > fix and needs its own patch.
> 
> So will you do that? Or it is needed to resend this one line hunk 
> again in new email again?

new patch, new email

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 3639 bytes --]

On Tue, Sep 17, 2013 at 09:28:42PM +0200, Pali Rohár wrote:
> On Tuesday 17 September 2013 18:08:35 Felipe Balbi wrote:
> > On Tue, Sep 17, 2013 at 06:05:15PM +0200, Pali Rohár wrote:
> > > On Tuesday 17 September 2013 17:48:59 you wrote:
> > > > On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Rohár wrote:
> > > > > More power supply drivers depends on vbus events and
> > > > > without it they not working. Power supply drivers using
> > > > > usb_register_notifier, so to deliver events it is
> > > > > needed to call atomic_notifier_call_chain.
> > > > > 
> > > > > So without atomic notifier power supply driver isp1704
> > > > > not retrieving vbus status and reporting bogus values
> > > > > to userspace and also to board platform data functions.
> > > > > Without proper data charger drivers trying to charge
> > > > > battery also when charger is disconnected or do not
> > > > > start charging when wallcharger connects.
> > > > > 
> > > > > Atomic notifier in musb driver was used before v3.5 and
> > > > > was replaced with omap mailbox. This patch adding
> > > > > atomic_notifier_call_chain call from function
> > > > > omap_musb_set_mailbox.
> > > > > 
> > > > > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> > > > > ---
> > > > > 
> > > > >  drivers/usb/musb/omap2430.c       |    3 +++
> > > > >  drivers/usb/phy/phy-twl4030-usb.c |    2 ++
> > > > >  2 files changed, 5 insertions(+)
> > > > > 
> > > > > diff --git a/drivers/usb/musb/omap2430.c
> > > > > b/drivers/usb/musb/omap2430.c index f44e8b5..5c40252
> > > > > 100644 --- a/drivers/usb/musb/omap2430.c
> > > > > +++ b/drivers/usb/musb/omap2430.c
> > > > > @@ -305,6 +305,9 @@ static void
> > > > > omap_musb_set_mailbox(struct omap2430_glue *glue)
> > > > > 
> > > > >  	default:
> > > > >  		dev_dbg(dev, "ID float\n");
> > > > >  	
> > > > >  	}
> > > > > 
> > > > > +
> > > > > +	atomic_notifier_call_chain(&musb->xceiv->notifier,
> > > > > +			musb->xceiv->last_event, NULL);
> > > > 
> > > > let's add a wrapper for this:
> > > > 
> > > > static inline int usb_phy_notify(struct usb phy *x,
> > > > unsigned val, void *v) {
> > > > 
> > > > 	return atomic_notifier_call_chain(&x->notifier, val, v);
> > > > 
> > > > }
> > > 
> > > Where to add this wrapper? To omap2430.c? or some include
> > > file?
> > 
> > <linux/usb/phy.h>
> > 
> > > On Tuesday 17 September 2013 17:49:17 Felipe Balbi wrote:
> > > > On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Rohár wrote:
> > > > > diff --git a/drivers/usb/phy/phy-twl4030-usb.c
> > > > > b/drivers/usb/phy/phy-twl4030-usb.c index
> > > > > 8f78d2d..efe6155 100644
> > > > > --- a/drivers/usb/phy/phy-twl4030-usb.c
> > > > > +++ b/drivers/usb/phy/phy-twl4030-usb.c
> > > > > @@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct
> > > > > platform_device *pdev)
> > > > > 
> > > > >  	if (device_create_file(&pdev->dev, &dev_attr_vbus))
> > > > >  	
> > > > >  		dev_warn(&pdev->dev, "could not create sysfs
> > > > >  		file\n");
> > > > > 
> > > > > +	ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
> > > > 
> > > > BTW, this is a bugfix, send separately.
> > > 
> > > What to send separately?
> > > 
> > > This full patch 1/4 is bugfix. And I did not understand what
> > > you want. Maybe it could be easier for you to apply this
> > > small 3+2 lines patch how you need.
> > 
> > This hunk here (initializaing notifier head) is a separate bug
> > fix and needs its own patch.
> 
> So will you do that? Or it is needed to resend this one line hunk 
> again in new email again?

new patch, new email

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Felipe Balbi]

On Tue, Sep 17, 2013 at 09:28:42PM +0200, Pali Roh?r wrote:
> On Tuesday 17 September 2013 18:08:35 Felipe Balbi wrote:
> > On Tue, Sep 17, 2013 at 06:05:15PM +0200, Pali Roh?r wrote:
> > > On Tuesday 17 September 2013 17:48:59 you wrote:
> > > > On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Roh?r wrote:
> > > > > More power supply drivers depends on vbus events and
> > > > > without it they not working. Power supply drivers using
> > > > > usb_register_notifier, so to deliver events it is
> > > > > needed to call atomic_notifier_call_chain.
> > > > > 
> > > > > So without atomic notifier power supply driver isp1704
> > > > > not retrieving vbus status and reporting bogus values
> > > > > to userspace and also to board platform data functions.
> > > > > Without proper data charger drivers trying to charge
> > > > > battery also when charger is disconnected or do not
> > > > > start charging when wallcharger connects.
> > > > > 
> > > > > Atomic notifier in musb driver was used before v3.5 and
> > > > > was replaced with omap mailbox. This patch adding
> > > > > atomic_notifier_call_chain call from function
> > > > > omap_musb_set_mailbox.
> > > > > 
> > > > > Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>
> > > > > ---
> > > > > 
> > > > >  drivers/usb/musb/omap2430.c       |    3 +++
> > > > >  drivers/usb/phy/phy-twl4030-usb.c |    2 ++
> > > > >  2 files changed, 5 insertions(+)
> > > > > 
> > > > > diff --git a/drivers/usb/musb/omap2430.c
> > > > > b/drivers/usb/musb/omap2430.c index f44e8b5..5c40252
> > > > > 100644 --- a/drivers/usb/musb/omap2430.c
> > > > > +++ b/drivers/usb/musb/omap2430.c
> > > > > @@ -305,6 +305,9 @@ static void
> > > > > omap_musb_set_mailbox(struct omap2430_glue *glue)
> > > > > 
> > > > >  	default:
> > > > >  		dev_dbg(dev, "ID float\n");
> > > > >  	
> > > > >  	}
> > > > > 
> > > > > +
> > > > > +	atomic_notifier_call_chain(&musb->xceiv->notifier,
> > > > > +			musb->xceiv->last_event, NULL);
> > > > 
> > > > let's add a wrapper for this:
> > > > 
> > > > static inline int usb_phy_notify(struct usb phy *x,
> > > > unsigned val, void *v) {
> > > > 
> > > > 	return atomic_notifier_call_chain(&x->notifier, val, v);
> > > > 
> > > > }
> > > 
> > > Where to add this wrapper? To omap2430.c? or some include
> > > file?
> > 
> > <linux/usb/phy.h>
> > 
> > > On Tuesday 17 September 2013 17:49:17 Felipe Balbi wrote:
> > > > On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Roh?r wrote:
> > > > > diff --git a/drivers/usb/phy/phy-twl4030-usb.c
> > > > > b/drivers/usb/phy/phy-twl4030-usb.c index
> > > > > 8f78d2d..efe6155 100644
> > > > > --- a/drivers/usb/phy/phy-twl4030-usb.c
> > > > > +++ b/drivers/usb/phy/phy-twl4030-usb.c
> > > > > @@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct
> > > > > platform_device *pdev)
> > > > > 
> > > > >  	if (device_create_file(&pdev->dev, &dev_attr_vbus))
> > > > >  	
> > > > >  		dev_warn(&pdev->dev, "could not create sysfs
> > > > >  		file\n");
> > > > > 
> > > > > +	ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
> > > > 
> > > > BTW, this is a bugfix, send separately.
> > > 
> > > What to send separately?
> > > 
> > > This full patch 1/4 is bugfix. And I did not understand what
> > > you want. Maybe it could be easier for you to apply this
> > > small 3+2 lines patch how you need.
> > 
> > This hunk here (initializaing notifier head) is a separate bug
> > fix and needs its own patch.
> 
> So will you do that? Or it is needed to resend this one line hunk 
> again in new email again?

new patch, new email

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130917/c6cd20bc/attachment.sig>

Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 5990 bytes --]

On Wednesday 18 September 2013 03:49:42 Felipe Balbi wrote:
> On Tue, Sep 17, 2013 at 09:28:42PM +0200, Pali Rohár wrote:
> > On Tuesday 17 September 2013 18:08:35 Felipe Balbi wrote:
> > > On Tue, Sep 17, 2013 at 06:05:15PM +0200, Pali Rohár wrote:
> > > > On Tuesday 17 September 2013 17:48:59 you wrote:
> > > > > On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Rohár wrote:
> > > > > > More power supply drivers depends on vbus events and
> > > > > > without it they not working. Power supply drivers
> > > > > > using usb_register_notifier, so to deliver events
> > > > > > it is needed to call atomic_notifier_call_chain.
> > > > > > 
> > > > > > So without atomic notifier power supply driver
> > > > > > isp1704 not retrieving vbus status and reporting
> > > > > > bogus values to userspace and also to board
> > > > > > platform data functions. Without proper data
> > > > > > charger drivers trying to charge battery also when
> > > > > > charger is disconnected or do not start charging
> > > > > > when wallcharger connects.
> > > > > > 
> > > > > > Atomic notifier in musb driver was used before v3.5
> > > > > > and was replaced with omap mailbox. This patch
> > > > > > adding atomic_notifier_call_chain call from
> > > > > > function omap_musb_set_mailbox.
> > > > > > 
> > > > > > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> > > > > > ---
> > > > > > 
> > > > > >  drivers/usb/musb/omap2430.c       |    3 +++
> > > > > >  drivers/usb/phy/phy-twl4030-usb.c |    2 ++
> > > > > >  2 files changed, 5 insertions(+)
> > > > > > 
> > > > > > diff --git a/drivers/usb/musb/omap2430.c
> > > > > > b/drivers/usb/musb/omap2430.c index f44e8b5..5c40252
> > > > > > 100644 --- a/drivers/usb/musb/omap2430.c
> > > > > > +++ b/drivers/usb/musb/omap2430.c
> > > > > > @@ -305,6 +305,9 @@ static void
> > > > > > omap_musb_set_mailbox(struct omap2430_glue *glue)
> > > > > > 
> > > > > >  	default:
> > > > > >  		dev_dbg(dev, "ID float\n");
> > > > > >  	
> > > > > >  	}
> > > > > > 
> > > > > > +
> > > > > > +	atomic_notifier_call_chain(&musb->xceiv->notifier,
> > > > > > +			musb->xceiv->last_event, NULL);
> > > > > 
> > > > > let's add a wrapper for this:
> > > > > 
> > > > > static inline int usb_phy_notify(struct usb phy *x,
> > > > > unsigned val, void *v) {
> > > > > 
> > > > > 	return atomic_notifier_call_chain(&x->notifier, val,
> > > > > 	v);
> > > > > 
> > > > > }
> > > > 
> > > > Where to add this wrapper? To omap2430.c? or some
> > > > include file?
> > > 
> > > <linux/usb/phy.h>
> > > 
> > > > On Tuesday 17 September 2013 17:49:17 Felipe Balbi wrote:
> > > > > On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Rohár wrote:
> > > > > > diff --git a/drivers/usb/phy/phy-twl4030-usb.c
> > > > > > b/drivers/usb/phy/phy-twl4030-usb.c index
> > > > > > 8f78d2d..efe6155 100644
> > > > > > --- a/drivers/usb/phy/phy-twl4030-usb.c
> > > > > > +++ b/drivers/usb/phy/phy-twl4030-usb.c
> > > > > > @@ -705,6 +705,8 @@ static int
> > > > > > twl4030_usb_probe(struct platform_device *pdev)
> > > > > > 
> > > > > >  	if (device_create_file(&pdev->dev,
> > > > > >  	&dev_attr_vbus))
> > > > > >  	
> > > > > >  		dev_warn(&pdev->dev, "could not create sysfs
> > > > > >  		file\n");
> > > > > > 
> > > > > > +	ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
> > > > > 
> > > > > BTW, this is a bugfix, send separately.
> > > > 
> > > > What to send separately?
> > > > 
> > > > This full patch 1/4 is bugfix. And I did not understand
> > > > what you want. Maybe it could be easier for you to
> > > > apply this small 3+2 lines patch how you need.
> > > 
> > > This hunk here (initializaing notifier head) is a separate
> > > bug fix and needs its own patch.
> > 
> > So will you do that? Or it is needed to resend this one line
> > hunk again in new email again?
> 
> new patch, new email

Guys, WHY ARE YOU SO STUPID AND ARROGANT?

Sorry but, need to copy full isolated patch/hunk from one mail to
another is hassling. So what you want from me? Do all those non
sense working only because yesterday you had bad day? Or what?

Everything needed with described information was in first mail.
Also second hunk has full isolated "git diff" output, so it is for
you really big problem to copy it? Or you did not see that patch?

I really did not understand what you wanted from me.

============================
==== BEGINNING OF PATCH ====
============================

This is bugfix and sending this patch separately from all other patches.
This patch is visibly isolated from all others and could be readable also
by disabled people. For other handicapped people I suggest to increase
font size and other text settings in program which view this patch.
For visually impaired people I suggest to use some text-to-speech software.

This is small 2 lines patch, diff starting after next visible break.

This patch initializing notifier head in tw4030 usb code which is missing.
Initialization code is needed for using any atomic_notifier_* functions.

Signed-off-by: Pali Rohár <pali.rohar@gmail.com>

===========================
==== BEGINNING OF DIFF ====
===========================

diff --git a/drivers/usb/phy/phy-twl4030-usb.c b/drivers/usb/phy/phy-twl4030-usb.c
index 8f78d2d..efe6155 100644
--- a/drivers/usb/phy/phy-twl4030-usb.c
+++ b/drivers/usb/phy/phy-twl4030-usb.c
@@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct platform_device *pdev)
 	if (device_create_file(&pdev->dev, &dev_attr_vbus))
 		dev_warn(&pdev->dev, "could not create sysfs file\n");
 
+	ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
+
 	/* Our job is to use irqs and status from the power module
 	 * to keep the transceiver disabled when nothing's connected.
 	 *

======================
==== END OF PATCH ====
======================

PS: This is end of email and patch is above ^^^^

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 6080 bytes --]

On Wednesday 18 September 2013 03:49:42 Felipe Balbi wrote:
> On Tue, Sep 17, 2013 at 09:28:42PM +0200, Pali Rohár wrote:
> > On Tuesday 17 September 2013 18:08:35 Felipe Balbi wrote:
> > > On Tue, Sep 17, 2013 at 06:05:15PM +0200, Pali Rohár wrote:
> > > > On Tuesday 17 September 2013 17:48:59 you wrote:
> > > > > On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Rohár wrote:
> > > > > > More power supply drivers depends on vbus events and
> > > > > > without it they not working. Power supply drivers
> > > > > > using usb_register_notifier, so to deliver events
> > > > > > it is needed to call atomic_notifier_call_chain.
> > > > > > 
> > > > > > So without atomic notifier power supply driver
> > > > > > isp1704 not retrieving vbus status and reporting
> > > > > > bogus values to userspace and also to board
> > > > > > platform data functions. Without proper data
> > > > > > charger drivers trying to charge battery also when
> > > > > > charger is disconnected or do not start charging
> > > > > > when wallcharger connects.
> > > > > > 
> > > > > > Atomic notifier in musb driver was used before v3.5
> > > > > > and was replaced with omap mailbox. This patch
> > > > > > adding atomic_notifier_call_chain call from
> > > > > > function omap_musb_set_mailbox.
> > > > > > 
> > > > > > Signed-off-by: Pali Rohár <pali.rohar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > > > > > ---
> > > > > > 
> > > > > >  drivers/usb/musb/omap2430.c       |    3 +++
> > > > > >  drivers/usb/phy/phy-twl4030-usb.c |    2 ++
> > > > > >  2 files changed, 5 insertions(+)
> > > > > > 
> > > > > > diff --git a/drivers/usb/musb/omap2430.c
> > > > > > b/drivers/usb/musb/omap2430.c index f44e8b5..5c40252
> > > > > > 100644 --- a/drivers/usb/musb/omap2430.c
> > > > > > +++ b/drivers/usb/musb/omap2430.c
> > > > > > @@ -305,6 +305,9 @@ static void
> > > > > > omap_musb_set_mailbox(struct omap2430_glue *glue)
> > > > > > 
> > > > > >  	default:
> > > > > >  		dev_dbg(dev, "ID float\n");
> > > > > >  	
> > > > > >  	}
> > > > > > 
> > > > > > +
> > > > > > +	atomic_notifier_call_chain(&musb->xceiv->notifier,
> > > > > > +			musb->xceiv->last_event, NULL);
> > > > > 
> > > > > let's add a wrapper for this:
> > > > > 
> > > > > static inline int usb_phy_notify(struct usb phy *x,
> > > > > unsigned val, void *v) {
> > > > > 
> > > > > 	return atomic_notifier_call_chain(&x->notifier, val,
> > > > > 	v);
> > > > > 
> > > > > }
> > > > 
> > > > Where to add this wrapper? To omap2430.c? or some
> > > > include file?
> > > 
> > > <linux/usb/phy.h>
> > > 
> > > > On Tuesday 17 September 2013 17:49:17 Felipe Balbi wrote:
> > > > > On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Rohár wrote:
> > > > > > diff --git a/drivers/usb/phy/phy-twl4030-usb.c
> > > > > > b/drivers/usb/phy/phy-twl4030-usb.c index
> > > > > > 8f78d2d..efe6155 100644
> > > > > > --- a/drivers/usb/phy/phy-twl4030-usb.c
> > > > > > +++ b/drivers/usb/phy/phy-twl4030-usb.c
> > > > > > @@ -705,6 +705,8 @@ static int
> > > > > > twl4030_usb_probe(struct platform_device *pdev)
> > > > > > 
> > > > > >  	if (device_create_file(&pdev->dev,
> > > > > >  	&dev_attr_vbus))
> > > > > >  	
> > > > > >  		dev_warn(&pdev->dev, "could not create sysfs
> > > > > >  		file\n");
> > > > > > 
> > > > > > +	ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
> > > > > 
> > > > > BTW, this is a bugfix, send separately.
> > > > 
> > > > What to send separately?
> > > > 
> > > > This full patch 1/4 is bugfix. And I did not understand
> > > > what you want. Maybe it could be easier for you to
> > > > apply this small 3+2 lines patch how you need.
> > > 
> > > This hunk here (initializaing notifier head) is a separate
> > > bug fix and needs its own patch.
> > 
> > So will you do that? Or it is needed to resend this one line
> > hunk again in new email again?
> 
> new patch, new email

Guys, WHY ARE YOU SO STUPID AND ARROGANT?

Sorry but, need to copy full isolated patch/hunk from one mail to
another is hassling. So what you want from me? Do all those non
sense working only because yesterday you had bad day? Or what?

Everything needed with described information was in first mail.
Also second hunk has full isolated "git diff" output, so it is for
you really big problem to copy it? Or you did not see that patch?

I really did not understand what you wanted from me.

============================
==== BEGINNING OF PATCH ====
============================

This is bugfix and sending this patch separately from all other patches.
This patch is visibly isolated from all others and could be readable also
by disabled people. For other handicapped people I suggest to increase
font size and other text settings in program which view this patch.
For visually impaired people I suggest to use some text-to-speech software.

This is small 2 lines patch, diff starting after next visible break.

This patch initializing notifier head in tw4030 usb code which is missing.
Initialization code is needed for using any atomic_notifier_* functions.

Signed-off-by: Pali Rohár <pali.rohar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

===========================
==== BEGINNING OF DIFF ====
===========================

diff --git a/drivers/usb/phy/phy-twl4030-usb.c b/drivers/usb/phy/phy-twl4030-usb.c
index 8f78d2d..efe6155 100644
--- a/drivers/usb/phy/phy-twl4030-usb.c
+++ b/drivers/usb/phy/phy-twl4030-usb.c
@@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct platform_device *pdev)
 	if (device_create_file(&pdev->dev, &dev_attr_vbus))
 		dev_warn(&pdev->dev, "could not create sysfs file\n");
 
+	ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
+
 	/* Our job is to use irqs and status from the power module
 	 * to keep the transceiver disabled when nothing's connected.
 	 *

======================
==== END OF PATCH ====
======================

PS: This is end of email and patch is above ^^^^

-- 
Pali Rohár
pali.rohar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Pali Rohár]

On Wednesday 18 September 2013 03:49:42 Felipe Balbi wrote:
> On Tue, Sep 17, 2013 at 09:28:42PM +0200, Pali Roh?r wrote:
> > On Tuesday 17 September 2013 18:08:35 Felipe Balbi wrote:
> > > On Tue, Sep 17, 2013 at 06:05:15PM +0200, Pali Roh?r wrote:
> > > > On Tuesday 17 September 2013 17:48:59 you wrote:
> > > > > On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Roh?r wrote:
> > > > > > More power supply drivers depends on vbus events and
> > > > > > without it they not working. Power supply drivers
> > > > > > using usb_register_notifier, so to deliver events
> > > > > > it is needed to call atomic_notifier_call_chain.
> > > > > > 
> > > > > > So without atomic notifier power supply driver
> > > > > > isp1704 not retrieving vbus status and reporting
> > > > > > bogus values to userspace and also to board
> > > > > > platform data functions. Without proper data
> > > > > > charger drivers trying to charge battery also when
> > > > > > charger is disconnected or do not start charging
> > > > > > when wallcharger connects.
> > > > > > 
> > > > > > Atomic notifier in musb driver was used before v3.5
> > > > > > and was replaced with omap mailbox. This patch
> > > > > > adding atomic_notifier_call_chain call from
> > > > > > function omap_musb_set_mailbox.
> > > > > > 
> > > > > > Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>
> > > > > > ---
> > > > > > 
> > > > > >  drivers/usb/musb/omap2430.c       |    3 +++
> > > > > >  drivers/usb/phy/phy-twl4030-usb.c |    2 ++
> > > > > >  2 files changed, 5 insertions(+)
> > > > > > 
> > > > > > diff --git a/drivers/usb/musb/omap2430.c
> > > > > > b/drivers/usb/musb/omap2430.c index f44e8b5..5c40252
> > > > > > 100644 --- a/drivers/usb/musb/omap2430.c
> > > > > > +++ b/drivers/usb/musb/omap2430.c
> > > > > > @@ -305,6 +305,9 @@ static void
> > > > > > omap_musb_set_mailbox(struct omap2430_glue *glue)
> > > > > > 
> > > > > >  	default:
> > > > > >  		dev_dbg(dev, "ID float\n");
> > > > > >  	
> > > > > >  	}
> > > > > > 
> > > > > > +
> > > > > > +	atomic_notifier_call_chain(&musb->xceiv->notifier,
> > > > > > +			musb->xceiv->last_event, NULL);
> > > > > 
> > > > > let's add a wrapper for this:
> > > > > 
> > > > > static inline int usb_phy_notify(struct usb phy *x,
> > > > > unsigned val, void *v) {
> > > > > 
> > > > > 	return atomic_notifier_call_chain(&x->notifier, val,
> > > > > 	v);
> > > > > 
> > > > > }
> > > > 
> > > > Where to add this wrapper? To omap2430.c? or some
> > > > include file?
> > > 
> > > <linux/usb/phy.h>
> > > 
> > > > On Tuesday 17 September 2013 17:49:17 Felipe Balbi wrote:
> > > > > On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Roh?r wrote:
> > > > > > diff --git a/drivers/usb/phy/phy-twl4030-usb.c
> > > > > > b/drivers/usb/phy/phy-twl4030-usb.c index
> > > > > > 8f78d2d..efe6155 100644
> > > > > > --- a/drivers/usb/phy/phy-twl4030-usb.c
> > > > > > +++ b/drivers/usb/phy/phy-twl4030-usb.c
> > > > > > @@ -705,6 +705,8 @@ static int
> > > > > > twl4030_usb_probe(struct platform_device *pdev)
> > > > > > 
> > > > > >  	if (device_create_file(&pdev->dev,
> > > > > >  	&dev_attr_vbus))
> > > > > >  	
> > > > > >  		dev_warn(&pdev->dev, "could not create sysfs
> > > > > >  		file\n");
> > > > > > 
> > > > > > +	ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
> > > > > 
> > > > > BTW, this is a bugfix, send separately.
> > > > 
> > > > What to send separately?
> > > > 
> > > > This full patch 1/4 is bugfix. And I did not understand
> > > > what you want. Maybe it could be easier for you to
> > > > apply this small 3+2 lines patch how you need.
> > > 
> > > This hunk here (initializaing notifier head) is a separate
> > > bug fix and needs its own patch.
> > 
> > So will you do that? Or it is needed to resend this one line
> > hunk again in new email again?
> 
> new patch, new email

Guys, WHY ARE YOU SO STUPID AND ARROGANT?

Sorry but, need to copy full isolated patch/hunk from one mail to
another is hassling. So what you want from me? Do all those non
sense working only because yesterday you had bad day? Or what?

Everything needed with described information was in first mail.
Also second hunk has full isolated "git diff" output, so it is for
you really big problem to copy it? Or you did not see that patch?

I really did not understand what you wanted from me.

============================
==== BEGINNING OF PATCH ====
============================

This is bugfix and sending this patch separately from all other patches.
This patch is visibly isolated from all others and could be readable also
by disabled people. For other handicapped people I suggest to increase
font size and other text settings in program which view this patch.
For visually impaired people I suggest to use some text-to-speech software.

This is small 2 lines patch, diff starting after next visible break.

This patch initializing notifier head in tw4030 usb code which is missing.
Initialization code is needed for using any atomic_notifier_* functions.

Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>

===========================
==== BEGINNING OF DIFF ====
===========================

diff --git a/drivers/usb/phy/phy-twl4030-usb.c b/drivers/usb/phy/phy-twl4030-usb.c
index 8f78d2d..efe6155 100644
--- a/drivers/usb/phy/phy-twl4030-usb.c
+++ b/drivers/usb/phy/phy-twl4030-usb.c
@@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct platform_device *pdev)
 	if (device_create_file(&pdev->dev, &dev_attr_vbus))
 		dev_warn(&pdev->dev, "could not create sysfs file\n");
 
+	ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
+
 	/* Our job is to use irqs and status from the power module
 	 * to keep the transceiver disabled when nothing's connected.
 	 *

======================
==== END OF PATCH ====
======================

PS: This is end of email and patch is above ^^^^

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130918/9c5970c0/attachment.sig>

Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Javier Martinez Canillas]

On Wed, Sep 18, 2013 at 10:20 AM, Pali Rohár <pali.rohar@gmail.com> wrote:
> On Wednesday 18 September 2013 03:49:42 Felipe Balbi wrote:
>> On Tue, Sep 17, 2013 at 09:28:42PM +0200, Pali Rohár wrote:
>> > On Tuesday 17 September 2013 18:08:35 Felipe Balbi wrote:
>> > > On Tue, Sep 17, 2013 at 06:05:15PM +0200, Pali Rohár wrote:
>> > > > On Tuesday 17 September 2013 17:48:59 you wrote:
>> > > > > On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Rohár wrote:
>> > > > > > More power supply drivers depends on vbus events and
>> > > > > > without it they not working. Power supply drivers
>> > > > > > using usb_register_notifier, so to deliver events
>> > > > > > it is needed to call atomic_notifier_call_chain.
>> > > > > >
>> > > > > > So without atomic notifier power supply driver
>> > > > > > isp1704 not retrieving vbus status and reporting
>> > > > > > bogus values to userspace and also to board
>> > > > > > platform data functions. Without proper data
>> > > > > > charger drivers trying to charge battery also when
>> > > > > > charger is disconnected or do not start charging
>> > > > > > when wallcharger connects.
>> > > > > >
>> > > > > > Atomic notifier in musb driver was used before v3.5
>> > > > > > and was replaced with omap mailbox. This patch
>> > > > > > adding atomic_notifier_call_chain call from
>> > > > > > function omap_musb_set_mailbox.
>> > > > > >
>> > > > > > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
>> > > > > > ---
>> > > > > >
>> > > > > >  drivers/usb/musb/omap2430.c       |    3 +++
>> > > > > >  drivers/usb/phy/phy-twl4030-usb.c |    2 ++
>> > > > > >  2 files changed, 5 insertions(+)
>> > > > > >
>> > > > > > diff --git a/drivers/usb/musb/omap2430.c
>> > > > > > b/drivers/usb/musb/omap2430.c index f44e8b5..5c40252
>> > > > > > 100644 --- a/drivers/usb/musb/omap2430.c
>> > > > > > +++ b/drivers/usb/musb/omap2430.c
>> > > > > > @@ -305,6 +305,9 @@ static void
>> > > > > > omap_musb_set_mailbox(struct omap2430_glue *glue)
>> > > > > >
>> > > > > >     default:
>> > > > > >             dev_dbg(dev, "ID float\n");
>> > > > > >
>> > > > > >     }
>> > > > > >
>> > > > > > +
>> > > > > > +   atomic_notifier_call_chain(&musb->xceiv->notifier,
>> > > > > > +                   musb->xceiv->last_event, NULL);
>> > > > >
>> > > > > let's add a wrapper for this:
>> > > > >
>> > > > > static inline int usb_phy_notify(struct usb phy *x,
>> > > > > unsigned val, void *v) {
>> > > > >
>> > > > >       return atomic_notifier_call_chain(&x->notifier, val,
>> > > > >       v);
>> > > > >
>> > > > > }
>> > > >
>> > > > Where to add this wrapper? To omap2430.c? or some
>> > > > include file?
>> > >
>> > > <linux/usb/phy.h>
>> > >
>> > > > On Tuesday 17 September 2013 17:49:17 Felipe Balbi wrote:
>> > > > > On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Rohár wrote:
>> > > > > > diff --git a/drivers/usb/phy/phy-twl4030-usb.c
>> > > > > > b/drivers/usb/phy/phy-twl4030-usb.c index
>> > > > > > 8f78d2d..efe6155 100644
>> > > > > > --- a/drivers/usb/phy/phy-twl4030-usb.c
>> > > > > > +++ b/drivers/usb/phy/phy-twl4030-usb.c
>> > > > > > @@ -705,6 +705,8 @@ static int
>> > > > > > twl4030_usb_probe(struct platform_device *pdev)
>> > > > > >
>> > > > > >     if (device_create_file(&pdev->dev,
>> > > > > >     &dev_attr_vbus))
>> > > > > >
>> > > > > >             dev_warn(&pdev->dev, "could not create sysfs
>> > > > > >             file\n");
>> > > > > >
>> > > > > > +   ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
>> > > > >
>> > > > > BTW, this is a bugfix, send separately.
>> > > >
>> > > > What to send separately?
>> > > >
>> > > > This full patch 1/4 is bugfix. And I did not understand
>> > > > what you want. Maybe it could be easier for you to
>> > > > apply this small 3+2 lines patch how you need.
>> > >
>> > > This hunk here (initializaing notifier head) is a separate
>> > > bug fix and needs its own patch.
>> >
>> > So will you do that? Or it is needed to resend this one line
>> > hunk again in new email again?
>>
>> new patch, new email
>
> Guys, WHY ARE YOU SO STUPID AND ARROGANT?
>
> Sorry but, need to copy full isolated patch/hunk from one mail to
> another is hassling. So what you want from me? Do all those non
> sense working only because yesterday you had bad day? Or what?
>
> Everything needed with described information was in first mail.
> Also second hunk has full isolated "git diff" output, so it is for
> you really big problem to copy it? Or you did not see that patch?
>
> I really did not understand what you wanted from me.
>
> ============================
> ==== BEGINNING OF PATCH ====
> ============================
>
> This is bugfix and sending this patch separately from all other patches.
> This patch is visibly isolated from all others and could be readable also
> by disabled people. For other handicapped people I suggest to increase
> font size and other text settings in program which view this patch.
> For visually impaired people I suggest to use some text-to-speech software.
>
> This is small 2 lines patch, diff starting after next visible break.
>
> This patch initializing notifier head in tw4030 usb code which is missing.
> Initialization code is needed for using any atomic_notifier_* functions.
>
> Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
>
> ===========================
> ==== BEGINNING OF DIFF ====
> ===========================
>
> diff --git a/drivers/usb/phy/phy-twl4030-usb.c b/drivers/usb/phy/phy-twl4030-usb.c
> index 8f78d2d..efe6155 100644
> --- a/drivers/usb/phy/phy-twl4030-usb.c
> +++ b/drivers/usb/phy/phy-twl4030-usb.c
> @@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct platform_device *pdev)
>         if (device_create_file(&pdev->dev, &dev_attr_vbus))
>                 dev_warn(&pdev->dev, "could not create sysfs file\n");
>
> +       ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
> +
>         /* Our job is to use irqs and status from the power module
>          * to keep the transceiver disabled when nothing's connected.
>          *
>
> ======================
> ==== END OF PATCH ====
> ======================
>
> PS: This is end of email and patch is above ^^^^
>

Hi Pali,

There is no need to be rude.

Felipe asked you to do the split since he believes that the notifier
chain call for musb xceiv and the twl->phy notifier head init should
be done in two separate patches.

I agree with him since is better to separate bugfixs from new features
for different reasons. For example if is found that a feature has to
be reverted, then this won't revert a bugfix causing a regression.
Also, it is easier to review and the bugfix patch can be cherry-picked
by stable kernels.

You said that to copy isolated patch/hunk from one mail to another is
hassling so why do you want Felipe to do that? He like most most
sub-system maintainers is very busy so if we want the kernel to scale
we have to help them to make their live easier.

So,  I don't understand from where your anger comes for just the need
to split your patch in two and send correct patches with git
send-email so Felipe can apply easily with git am mbox or whatever
worfklow he has.

This is not the first time you contribute to the kernel so you know
that the above patch s not only not in the correct format to be
applied but also has a very offensive commit changelog that is not
suitable for the kernel.

Take a deep breath, grab a mug of coffee and then just split your
patches and repost as v2, I'm sure you spent more time writing that
angry email that what it would have taken to do it properly ;-)

> --
> Pali Rohár
> pali.rohar@gmail.com

Best regards,
Javier

Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Javier Martinez Canillas]

On Wed, Sep 18, 2013 at 10:20 AM, Pali Rohár <pali.rohar@gmail.com> wrote:
> On Wednesday 18 September 2013 03:49:42 Felipe Balbi wrote:
>> On Tue, Sep 17, 2013 at 09:28:42PM +0200, Pali Rohár wrote:
>> > On Tuesday 17 September 2013 18:08:35 Felipe Balbi wrote:
>> > > On Tue, Sep 17, 2013 at 06:05:15PM +0200, Pali Rohár wrote:
>> > > > On Tuesday 17 September 2013 17:48:59 you wrote:
>> > > > > On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Rohár wrote:
>> > > > > > More power supply drivers depends on vbus events and
>> > > > > > without it they not working. Power supply drivers
>> > > > > > using usb_register_notifier, so to deliver events
>> > > > > > it is needed to call atomic_notifier_call_chain.
>> > > > > >
>> > > > > > So without atomic notifier power supply driver
>> > > > > > isp1704 not retrieving vbus status and reporting
>> > > > > > bogus values to userspace and also to board
>> > > > > > platform data functions. Without proper data
>> > > > > > charger drivers trying to charge battery also when
>> > > > > > charger is disconnected or do not start charging
>> > > > > > when wallcharger connects.
>> > > > > >
>> > > > > > Atomic notifier in musb driver was used before v3.5
>> > > > > > and was replaced with omap mailbox. This patch
>> > > > > > adding atomic_notifier_call_chain call from
>> > > > > > function omap_musb_set_mailbox.
>> > > > > >
>> > > > > > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
>> > > > > > ---
>> > > > > >
>> > > > > >  drivers/usb/musb/omap2430.c       |    3 +++
>> > > > > >  drivers/usb/phy/phy-twl4030-usb.c |    2 ++
>> > > > > >  2 files changed, 5 insertions(+)
>> > > > > >
>> > > > > > diff --git a/drivers/usb/musb/omap2430.c
>> > > > > > b/drivers/usb/musb/omap2430.c index f44e8b5..5c40252
>> > > > > > 100644 --- a/drivers/usb/musb/omap2430.c
>> > > > > > +++ b/drivers/usb/musb/omap2430.c
>> > > > > > @@ -305,6 +305,9 @@ static void
>> > > > > > omap_musb_set_mailbox(struct omap2430_glue *glue)
>> > > > > >
>> > > > > >     default:
>> > > > > >             dev_dbg(dev, "ID float\n");
>> > > > > >
>> > > > > >     }
>> > > > > >
>> > > > > > +
>> > > > > > +   atomic_notifier_call_chain(&musb->xceiv->notifier,
>> > > > > > +                   musb->xceiv->last_event, NULL);
>> > > > >
>> > > > > let's add a wrapper for this:
>> > > > >
>> > > > > static inline int usb_phy_notify(struct usb phy *x,
>> > > > > unsigned val, void *v) {
>> > > > >
>> > > > >       return atomic_notifier_call_chain(&x->notifier, val,
>> > > > >       v);
>> > > > >
>> > > > > }
>> > > >
>> > > > Where to add this wrapper? To omap2430.c? or some
>> > > > include file?
>> > >
>> > > <linux/usb/phy.h>
>> > >
>> > > > On Tuesday 17 September 2013 17:49:17 Felipe Balbi wrote:
>> > > > > On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Rohár wrote:
>> > > > > > diff --git a/drivers/usb/phy/phy-twl4030-usb.c
>> > > > > > b/drivers/usb/phy/phy-twl4030-usb.c index
>> > > > > > 8f78d2d..efe6155 100644
>> > > > > > --- a/drivers/usb/phy/phy-twl4030-usb.c
>> > > > > > +++ b/drivers/usb/phy/phy-twl4030-usb.c
>> > > > > > @@ -705,6 +705,8 @@ static int
>> > > > > > twl4030_usb_probe(struct platform_device *pdev)
>> > > > > >
>> > > > > >     if (device_create_file(&pdev->dev,
>> > > > > >     &dev_attr_vbus))
>> > > > > >
>> > > > > >             dev_warn(&pdev->dev, "could not create sysfs
>> > > > > >             file\n");
>> > > > > >
>> > > > > > +   ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
>> > > > >
>> > > > > BTW, this is a bugfix, send separately.
>> > > >
>> > > > What to send separately?
>> > > >
>> > > > This full patch 1/4 is bugfix. And I did not understand
>> > > > what you want. Maybe it could be easier for you to
>> > > > apply this small 3+2 lines patch how you need.
>> > >
>> > > This hunk here (initializaing notifier head) is a separate
>> > > bug fix and needs its own patch.
>> >
>> > So will you do that? Or it is needed to resend this one line
>> > hunk again in new email again?
>>
>> new patch, new email
>
> Guys, WHY ARE YOU SO STUPID AND ARROGANT?
>
> Sorry but, need to copy full isolated patch/hunk from one mail to
> another is hassling. So what you want from me? Do all those non
> sense working only because yesterday you had bad day? Or what?
>
> Everything needed with described information was in first mail.
> Also second hunk has full isolated "git diff" output, so it is for
> you really big problem to copy it? Or you did not see that patch?
>
> I really did not understand what you wanted from me.
>
> ============================
> ==== BEGINNING OF PATCH ====
> ============================
>
> This is bugfix and sending this patch separately from all other patches.
> This patch is visibly isolated from all others and could be readable also
> by disabled people. For other handicapped people I suggest to increase
> font size and other text settings in program which view this patch.
> For visually impaired people I suggest to use some text-to-speech software.
>
> This is small 2 lines patch, diff starting after next visible break.
>
> This patch initializing notifier head in tw4030 usb code which is missing.
> Initialization code is needed for using any atomic_notifier_* functions.
>
> Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
>
> ===========================
> ==== BEGINNING OF DIFF ====
> ===========================
>
> diff --git a/drivers/usb/phy/phy-twl4030-usb.c b/drivers/usb/phy/phy-twl4030-usb.c
> index 8f78d2d..efe6155 100644
> --- a/drivers/usb/phy/phy-twl4030-usb.c
> +++ b/drivers/usb/phy/phy-twl4030-usb.c
> @@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct platform_device *pdev)
>         if (device_create_file(&pdev->dev, &dev_attr_vbus))
>                 dev_warn(&pdev->dev, "could not create sysfs file\n");
>
> +       ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
> +
>         /* Our job is to use irqs and status from the power module
>          * to keep the transceiver disabled when nothing's connected.
>          *
>
> ======================
> ==== END OF PATCH ====
> ======================
>
> PS: This is end of email and patch is above ^^^^
>

Hi Pali,

There is no need to be rude.

Felipe asked you to do the split since he believes that the notifier
chain call for musb xceiv and the twl->phy notifier head init should
be done in two separate patches.

I agree with him since is better to separate bugfixs from new features
for different reasons. For example if is found that a feature has to
be reverted, then this won't revert a bugfix causing a regression.
Also, it is easier to review and the bugfix patch can be cherry-picked
by stable kernels.

You said that to copy isolated patch/hunk from one mail to another is
hassling so why do you want Felipe to do that? He like most most
sub-system maintainers is very busy so if we want the kernel to scale
we have to help them to make their live easier.

So,  I don't understand from where your anger comes for just the need
to split your patch in two and send correct patches with git
send-email so Felipe can apply easily with git am mbox or whatever
worfklow he has.

This is not the first time you contribute to the kernel so you know
that the above patch s not only not in the correct format to be
applied but also has a very offensive commit changelog that is not
suitable for the kernel.

Take a deep breath, grab a mug of coffee and then just split your
patches and repost as v2, I'm sure you spent more time writing that
angry email that what it would have taken to do it properly ;-)

> --
> Pali Rohár
> pali.rohar@gmail.com

Best regards,
Javier

[PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Javier Martinez Canillas]

On Wed, Sep 18, 2013 at 10:20 AM, Pali Roh?r <pali.rohar@gmail.com> wrote:
> On Wednesday 18 September 2013 03:49:42 Felipe Balbi wrote:
>> On Tue, Sep 17, 2013 at 09:28:42PM +0200, Pali Roh?r wrote:
>> > On Tuesday 17 September 2013 18:08:35 Felipe Balbi wrote:
>> > > On Tue, Sep 17, 2013 at 06:05:15PM +0200, Pali Roh?r wrote:
>> > > > On Tuesday 17 September 2013 17:48:59 you wrote:
>> > > > > On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Roh?r wrote:
>> > > > > > More power supply drivers depends on vbus events and
>> > > > > > without it they not working. Power supply drivers
>> > > > > > using usb_register_notifier, so to deliver events
>> > > > > > it is needed to call atomic_notifier_call_chain.
>> > > > > >
>> > > > > > So without atomic notifier power supply driver
>> > > > > > isp1704 not retrieving vbus status and reporting
>> > > > > > bogus values to userspace and also to board
>> > > > > > platform data functions. Without proper data
>> > > > > > charger drivers trying to charge battery also when
>> > > > > > charger is disconnected or do not start charging
>> > > > > > when wallcharger connects.
>> > > > > >
>> > > > > > Atomic notifier in musb driver was used before v3.5
>> > > > > > and was replaced with omap mailbox. This patch
>> > > > > > adding atomic_notifier_call_chain call from
>> > > > > > function omap_musb_set_mailbox.
>> > > > > >
>> > > > > > Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>
>> > > > > > ---
>> > > > > >
>> > > > > >  drivers/usb/musb/omap2430.c       |    3 +++
>> > > > > >  drivers/usb/phy/phy-twl4030-usb.c |    2 ++
>> > > > > >  2 files changed, 5 insertions(+)
>> > > > > >
>> > > > > > diff --git a/drivers/usb/musb/omap2430.c
>> > > > > > b/drivers/usb/musb/omap2430.c index f44e8b5..5c40252
>> > > > > > 100644 --- a/drivers/usb/musb/omap2430.c
>> > > > > > +++ b/drivers/usb/musb/omap2430.c
>> > > > > > @@ -305,6 +305,9 @@ static void
>> > > > > > omap_musb_set_mailbox(struct omap2430_glue *glue)
>> > > > > >
>> > > > > >     default:
>> > > > > >             dev_dbg(dev, "ID float\n");
>> > > > > >
>> > > > > >     }
>> > > > > >
>> > > > > > +
>> > > > > > +   atomic_notifier_call_chain(&musb->xceiv->notifier,
>> > > > > > +                   musb->xceiv->last_event, NULL);
>> > > > >
>> > > > > let's add a wrapper for this:
>> > > > >
>> > > > > static inline int usb_phy_notify(struct usb phy *x,
>> > > > > unsigned val, void *v) {
>> > > > >
>> > > > >       return atomic_notifier_call_chain(&x->notifier, val,
>> > > > >       v);
>> > > > >
>> > > > > }
>> > > >
>> > > > Where to add this wrapper? To omap2430.c? or some
>> > > > include file?
>> > >
>> > > <linux/usb/phy.h>
>> > >
>> > > > On Tuesday 17 September 2013 17:49:17 Felipe Balbi wrote:
>> > > > > On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Roh?r wrote:
>> > > > > > diff --git a/drivers/usb/phy/phy-twl4030-usb.c
>> > > > > > b/drivers/usb/phy/phy-twl4030-usb.c index
>> > > > > > 8f78d2d..efe6155 100644
>> > > > > > --- a/drivers/usb/phy/phy-twl4030-usb.c
>> > > > > > +++ b/drivers/usb/phy/phy-twl4030-usb.c
>> > > > > > @@ -705,6 +705,8 @@ static int
>> > > > > > twl4030_usb_probe(struct platform_device *pdev)
>> > > > > >
>> > > > > >     if (device_create_file(&pdev->dev,
>> > > > > >     &dev_attr_vbus))
>> > > > > >
>> > > > > >             dev_warn(&pdev->dev, "could not create sysfs
>> > > > > >             file\n");
>> > > > > >
>> > > > > > +   ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
>> > > > >
>> > > > > BTW, this is a bugfix, send separately.
>> > > >
>> > > > What to send separately?
>> > > >
>> > > > This full patch 1/4 is bugfix. And I did not understand
>> > > > what you want. Maybe it could be easier for you to
>> > > > apply this small 3+2 lines patch how you need.
>> > >
>> > > This hunk here (initializaing notifier head) is a separate
>> > > bug fix and needs its own patch.
>> >
>> > So will you do that? Or it is needed to resend this one line
>> > hunk again in new email again?
>>
>> new patch, new email
>
> Guys, WHY ARE YOU SO STUPID AND ARROGANT?
>
> Sorry but, need to copy full isolated patch/hunk from one mail to
> another is hassling. So what you want from me? Do all those non
> sense working only because yesterday you had bad day? Or what?
>
> Everything needed with described information was in first mail.
> Also second hunk has full isolated "git diff" output, so it is for
> you really big problem to copy it? Or you did not see that patch?
>
> I really did not understand what you wanted from me.
>
> ============================
> ==== BEGINNING OF PATCH ====
> ============================
>
> This is bugfix and sending this patch separately from all other patches.
> This patch is visibly isolated from all others and could be readable also
> by disabled people. For other handicapped people I suggest to increase
> font size and other text settings in program which view this patch.
> For visually impaired people I suggest to use some text-to-speech software.
>
> This is small 2 lines patch, diff starting after next visible break.
>
> This patch initializing notifier head in tw4030 usb code which is missing.
> Initialization code is needed for using any atomic_notifier_* functions.
>
> Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>
>
> ===========================
> ==== BEGINNING OF DIFF ====
> ===========================
>
> diff --git a/drivers/usb/phy/phy-twl4030-usb.c b/drivers/usb/phy/phy-twl4030-usb.c
> index 8f78d2d..efe6155 100644
> --- a/drivers/usb/phy/phy-twl4030-usb.c
> +++ b/drivers/usb/phy/phy-twl4030-usb.c
> @@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct platform_device *pdev)
>         if (device_create_file(&pdev->dev, &dev_attr_vbus))
>                 dev_warn(&pdev->dev, "could not create sysfs file\n");
>
> +       ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
> +
>         /* Our job is to use irqs and status from the power module
>          * to keep the transceiver disabled when nothing's connected.
>          *
>
> ======================
> ==== END OF PATCH ====
> ======================
>
> PS: This is end of email and patch is above ^^^^
>

Hi Pali,

There is no need to be rude.

Felipe asked you to do the split since he believes that the notifier
chain call for musb xceiv and the twl->phy notifier head init should
be done in two separate patches.

I agree with him since is better to separate bugfixs from new features
for different reasons. For example if is found that a feature has to
be reverted, then this won't revert a bugfix causing a regression.
Also, it is easier to review and the bugfix patch can be cherry-picked
by stable kernels.

You said that to copy isolated patch/hunk from one mail to another is
hassling so why do you want Felipe to do that? He like most most
sub-system maintainers is very busy so if we want the kernel to scale
we have to help them to make their live easier.

So,  I don't understand from where your anger comes for just the need
to split your patch in two and send correct patches with git
send-email so Felipe can apply easily with git am mbox or whatever
worfklow he has.

This is not the first time you contribute to the kernel so you know
that the above patch s not only not in the correct format to be
applied but also has a very offensive commit changelog that is not
suitable for the kernel.

Take a deep breath, grab a mug of coffee and then just split your
patches and repost as v2, I'm sure you spent more time writing that
angry email that what it would have taken to do it properly ;-)

> --
> Pali Roh?r
> pali.rohar at gmail.com

Best regards,
Javier

Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Pavel Machek]

Hi!

> >> > So will you do that? Or it is needed to resend this one line
> >> > hunk again in new email again?
> >>
> >> new patch, new email
> >
> > Guys, WHY ARE YOU SO STUPID AND ARROGANT?
> >
> > Sorry but, need to copy full isolated patch/hunk from one mail to
> > another is hassling. So what you want from me? Do all those non
> > sense working only because yesterday you had bad day? Or what?
...
> 
> Hi Pali,
> 
> There is no need to be rude.
> 
> Felipe asked you to do the split since he believes that the notifier
> chain call for musb xceiv and the twl->phy notifier head init should
> be done in two separate patches.

Actually, there is need to be rude, because Felipe fails to act as
maintainer. Instead of fixing bugs in his code, he bounces bugfix
patches, points people to random READMEs and wastes everyones time.
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Pavel Machek]

Hi!

> >> > So will you do that? Or it is needed to resend this one line
> >> > hunk again in new email again?
> >>
> >> new patch, new email
> >
> > Guys, WHY ARE YOU SO STUPID AND ARROGANT?
> >
> > Sorry but, need to copy full isolated patch/hunk from one mail to
> > another is hassling. So what you want from me? Do all those non
> > sense working only because yesterday you had bad day? Or what?
...
> 
> Hi Pali,
> 
> There is no need to be rude.
> 
> Felipe asked you to do the split since he believes that the notifier
> chain call for musb xceiv and the twl->phy notifier head init should
> be done in two separate patches.

Actually, there is need to be rude, because Felipe fails to act as
maintainer. Instead of fixing bugs in his code, he bounces bugfix
patches, points people to random READMEs and wastes everyones time.
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Javier Martinez Canillas]

On Wed, Sep 18, 2013 at 3:30 PM, Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
>
>> >> > So will you do that? Or it is needed to resend this one line
>> >> > hunk again in new email again?
>> >>
>> >> new patch, new email
>> >
>> > Guys, WHY ARE YOU SO STUPID AND ARROGANT?
>> >
>> > Sorry but, need to copy full isolated patch/hunk from one mail to
>> > another is hassling. So what you want from me? Do all those non
>> > sense working only because yesterday you had bad day? Or what?
> ...
>>
>> Hi Pali,
>>
>> There is no need to be rude.
>>
>> Felipe asked you to do the split since he believes that the notifier
>> chain call for musb xceiv and the twl->phy notifier head init should
>> be done in two separate patches.
>
> Actually, there is need to be rude, because Felipe fails to act as
> maintainer. Instead of fixing bugs in his code, he bounces bugfix
> patches, points people to random READMEs and wastes everyones time.
>                                                                         Pavel
>

I don't know what are you talking about (if that happened in another
thread then I need more context). Felipe is not bouncing any bugfix
but just asked to split the patch in two since the patch was solving
two separate issues so is way better to have it in two separate
patches for the reasons I explained before.

So, as far as I can tell Felipe did exactly what I would expect from a
maintainer. He took the time to review the patches sent to him and
gave feedback. If the sender doesn't want to take his feedback into
account and prefer to send pretty insulting emails instead that is his
choice but I would say that is this not the greatest approach to get
your code merged (to say the least).

Best regards,
Javier

[PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Javier Martinez Canillas]

On Wed, Sep 18, 2013 at 3:30 PM, Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
>
>> >> > So will you do that? Or it is needed to resend this one line
>> >> > hunk again in new email again?
>> >>
>> >> new patch, new email
>> >
>> > Guys, WHY ARE YOU SO STUPID AND ARROGANT?
>> >
>> > Sorry but, need to copy full isolated patch/hunk from one mail to
>> > another is hassling. So what you want from me? Do all those non
>> > sense working only because yesterday you had bad day? Or what?
> ...
>>
>> Hi Pali,
>>
>> There is no need to be rude.
>>
>> Felipe asked you to do the split since he believes that the notifier
>> chain call for musb xceiv and the twl->phy notifier head init should
>> be done in two separate patches.
>
> Actually, there is need to be rude, because Felipe fails to act as
> maintainer. Instead of fixing bugs in his code, he bounces bugfix
> patches, points people to random READMEs and wastes everyones time.
>                                                                         Pavel
>

I don't know what are you talking about (if that happened in another
thread then I need more context). Felipe is not bouncing any bugfix
but just asked to split the patch in two since the patch was solving
two separate issues so is way better to have it in two separate
patches for the reasons I explained before.

So, as far as I can tell Felipe did exactly what I would expect from a
maintainer. He took the time to review the patches sent to him and
gave feedback. If the sender doesn't want to take his feedback into
account and prefer to send pretty insulting emails instead that is his
choice but I would say that is this not the greatest approach to get
your code merged (to say the least).

Best regards,
Javier

Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Pavel Machek]

Hi!

> >> >> > So will you do that? Or it is needed to resend this one line
> >> >> > hunk again in new email again?
> >> >>
> >> >> new patch, new email
> >> >
> >> > Guys, WHY ARE YOU SO STUPID AND ARROGANT?
> >> >
> >> > Sorry but, need to copy full isolated patch/hunk from one mail to
> >> > another is hassling. So what you want from me? Do all those non
> >> > sense working only because yesterday you had bad day? Or what?
...
> > Actually, there is need to be rude, because Felipe fails to act as
> > maintainer. Instead of fixing bugs in his code, he bounces bugfix
> > patches, points people to random READMEs and wastes everyones time.
> 
> I don't know what are you talking about (if that happened in another
> thread then I need more context). Felipe is not bouncing any bugfix

Take a look here:

https://lkml.org/lkml/2013/9/17/286

I clearly state that patch can not be tested as required for "proper"
submission, but offer patch anyway. I get irrelevant boilerplate on
patch format.

> but just asked to split the patch in two since the patch was solving
> two separate issues so is way better to have it in two separate
> patches for the reasons I explained before.
> 
> So, as far as I can tell Felipe did exactly what I would expect from a
> maintainer. He took the time to review the patches sent to him and

I'd expect maintainer to, well, maintain code. It means actually
fixing bugs in his code, when he's pointed at them.

> gave feedback. If the sender doesn't want to take his feedback into
> account and prefer to send pretty insulting emails instead that is his
> choice but I would say that is this not the greatest approach to get
> your code merged (to say the least).

Clearly not. But Pali found bug in code Felipe should
maintain. Instead of "thank you for bug report, I applied this one
line of your code to fix it", Pali got "new patch, new email" for his
efforts. That is how you train dogs, not how you should treat kernel
contributors.

Now, it is possible that Felipe just has problems with english, as he
called me piece of wood in https://lkml.org/lkml/2013/9/17/476 , but
he appears more arogant than usual over email.

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Pavel Machek]

Hi!

> >> >> > So will you do that? Or it is needed to resend this one line
> >> >> > hunk again in new email again?
> >> >>
> >> >> new patch, new email
> >> >
> >> > Guys, WHY ARE YOU SO STUPID AND ARROGANT?
> >> >
> >> > Sorry but, need to copy full isolated patch/hunk from one mail to
> >> > another is hassling. So what you want from me? Do all those non
> >> > sense working only because yesterday you had bad day? Or what?
...
> > Actually, there is need to be rude, because Felipe fails to act as
> > maintainer. Instead of fixing bugs in his code, he bounces bugfix
> > patches, points people to random READMEs and wastes everyones time.
> 
> I don't know what are you talking about (if that happened in another
> thread then I need more context). Felipe is not bouncing any bugfix

Take a look here:

https://lkml.org/lkml/2013/9/17/286

I clearly state that patch can not be tested as required for "proper"
submission, but offer patch anyway. I get irrelevant boilerplate on
patch format.

> but just asked to split the patch in two since the patch was solving
> two separate issues so is way better to have it in two separate
> patches for the reasons I explained before.
> 
> So, as far as I can tell Felipe did exactly what I would expect from a
> maintainer. He took the time to review the patches sent to him and

I'd expect maintainer to, well, maintain code. It means actually
fixing bugs in his code, when he's pointed at them.

> gave feedback. If the sender doesn't want to take his feedback into
> account and prefer to send pretty insulting emails instead that is his
> choice but I would say that is this not the greatest approach to get
> your code merged (to say the least).

Clearly not. But Pali found bug in code Felipe should
maintain. Instead of "thank you for bug report, I applied this one
line of your code to fix it", Pali got "new patch, new email" for his
efforts. That is how you train dogs, not how you should treat kernel
contributors.

Now, it is possible that Felipe just has problems with english, as he
called me piece of wood in https://lkml.org/lkml/2013/9/17/476 , but
he appears more arogant than usual over email.

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Pavel Machek]

Hi!

> > gave feedback. If the sender doesn't want to take his feedback into
> > account and prefer to send pretty insulting emails instead that is his
> > choice but I would say that is this not the greatest approach to get
> > your code merged (to say the least).
> 
> Clearly not. But Pali found bug in code Felipe should
> maintain. Instead of "thank you for bug report, I applied this one
> line of your code to fix it", Pali got "new patch, new email" for his
> efforts. That is how you train dogs, not how you should treat kernel
> contributors.
> 
> Now, it is possible that Felipe just has problems with english, as he
> called me piece of wood in https://lkml.org/lkml/2013/9/17/476 , but
> he appears more arogant than usual over email.

Actually he called me "piece of wood with garbage in it". I guess I
have right to be offended. I'm baby in the next email. Hmm.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Pavel Machek]

Hi!

> > gave feedback. If the sender doesn't want to take his feedback into
> > account and prefer to send pretty insulting emails instead that is his
> > choice but I would say that is this not the greatest approach to get
> > your code merged (to say the least).
> 
> Clearly not. But Pali found bug in code Felipe should
> maintain. Instead of "thank you for bug report, I applied this one
> line of your code to fix it", Pali got "new patch, new email" for his
> efforts. That is how you train dogs, not how you should treat kernel
> contributors.
> 
> Now, it is possible that Felipe just has problems with english, as he
> called me piece of wood in https://lkml.org/lkml/2013/9/17/476 , but
> he appears more arogant than usual over email.

Actually he called me "piece of wood with garbage in it". I guess I
have right to be offended. I'm baby in the next email. Hmm.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Javier Martinez Canillas]

On Wed, Sep 18, 2013 at 4:22 PM, Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
>
>> >> >> > So will you do that? Or it is needed to resend this one line
>> >> >> > hunk again in new email again?
>> >> >>
>> >> >> new patch, new email
>> >> >
>> >> > Guys, WHY ARE YOU SO STUPID AND ARROGANT?
>> >> >
>> >> > Sorry but, need to copy full isolated patch/hunk from one mail to
>> >> > another is hassling. So what you want from me? Do all those non
>> >> > sense working only because yesterday you had bad day? Or what?
> ...
>> > Actually, there is need to be rude, because Felipe fails to act as
>> > maintainer. Instead of fixing bugs in his code, he bounces bugfix
>> > patches, points people to random READMEs and wastes everyones time.
>>
>> I don't know what are you talking about (if that happened in another
>> thread then I need more context). Felipe is not bouncing any bugfix
>
> Take a look here:
>
> https://lkml.org/lkml/2013/9/17/286
>
> I clearly state that patch can not be tested as required for "proper"
> submission, but offer patch anyway. I get irrelevant boilerplate on
> patch format.
>

Felipe didn't complain about you not being to be able to test the
patch (most of the times compile tested if enough) what he said was:

"Seriously though, read that file, you're commit log has garbage in it
which shouldn't go to git history".

which is totally true, if you want to comment things that don't have
to go to the backlog you can't comment between the --- after your
s-o-b and before the first diff. That's were you should puts comments
like "Hi! or Here's suggested patch. I don't have the hardware, so it
is completely untested."

>> but just asked to split the patch in two since the patch was solving
>> two separate issues so is way better to have it in two separate
>> patches for the reasons I explained before.
>>
>> So, as far as I can tell Felipe did exactly what I would expect from a
>> maintainer. He took the time to review the patches sent to him and
>
> I'd expect maintainer to, well, maintain code. It means actually
> fixing bugs in his code, when he's pointed at them.
>
>> gave feedback. If the sender doesn't want to take his feedback into
>> account and prefer to send pretty insulting emails instead that is his
>> choice but I would say that is this not the greatest approach to get
>> your code merged (to say the least).
>
> Clearly not. But Pali found bug in code Felipe should
> maintain. Instead of "thank you for bug report, I applied this one
> line of your code to fix it", Pali got "new patch, new email" for his
> efforts. That is how you train dogs, not how you should treat kernel
> contributors.
>

No, you misunderstood the role of the maintainers. Maintainers should
be custodian of a part of the kernel but not responsible for every
single line of code on their sub-systems. If a piece of code is buggy
then the people using and that take care of that should be fixing and
maintainers should review and suggest improvements to the patches. As
long as a piece of code keep compiling then it is harmless even if is
buggy and nobody cares about it. If it is so broken that it doesn't
even compile then the maintainer can decide to just drop it since no
one else seems to care about it.

If someone finds a bug on a piece of code is because that people care
about that functionality. Maintainers are really busy people and can
jump and fix any random bug that someone finds on a piece of code just
because it is the subsystem they maintainer neither they have to
blindly merge any crappy patch just because they don't have time (or
interest) in fixing a reported bug on a piece of code.

> Now, it is possible that Felipe just has problems with english, as he
> called me piece of wood in https://lkml.org/lkml/2013/9/17/476 , but
> he appears more arogant than usual over email.
>

Clearly he meant "your commit log has garbage" instead of you're, that's a typo.

>                                                                 Pavel

But neither Felipe needs someone to defend him nor I have time to keep
arguing with you.

Have nice day!
Javier

[PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Javier Martinez Canillas]

On Wed, Sep 18, 2013 at 4:22 PM, Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
>
>> >> >> > So will you do that? Or it is needed to resend this one line
>> >> >> > hunk again in new email again?
>> >> >>
>> >> >> new patch, new email
>> >> >
>> >> > Guys, WHY ARE YOU SO STUPID AND ARROGANT?
>> >> >
>> >> > Sorry but, need to copy full isolated patch/hunk from one mail to
>> >> > another is hassling. So what you want from me? Do all those non
>> >> > sense working only because yesterday you had bad day? Or what?
> ...
>> > Actually, there is need to be rude, because Felipe fails to act as
>> > maintainer. Instead of fixing bugs in his code, he bounces bugfix
>> > patches, points people to random READMEs and wastes everyones time.
>>
>> I don't know what are you talking about (if that happened in another
>> thread then I need more context). Felipe is not bouncing any bugfix
>
> Take a look here:
>
> https://lkml.org/lkml/2013/9/17/286
>
> I clearly state that patch can not be tested as required for "proper"
> submission, but offer patch anyway. I get irrelevant boilerplate on
> patch format.
>

Felipe didn't complain about you not being to be able to test the
patch (most of the times compile tested if enough) what he said was:

"Seriously though, read that file, you're commit log has garbage in it
which shouldn't go to git history".

which is totally true, if you want to comment things that don't have
to go to the backlog you can't comment between the --- after your
s-o-b and before the first diff. That's were you should puts comments
like "Hi! or Here's suggested patch. I don't have the hardware, so it
is completely untested."

>> but just asked to split the patch in two since the patch was solving
>> two separate issues so is way better to have it in two separate
>> patches for the reasons I explained before.
>>
>> So, as far as I can tell Felipe did exactly what I would expect from a
>> maintainer. He took the time to review the patches sent to him and
>
> I'd expect maintainer to, well, maintain code. It means actually
> fixing bugs in his code, when he's pointed at them.
>
>> gave feedback. If the sender doesn't want to take his feedback into
>> account and prefer to send pretty insulting emails instead that is his
>> choice but I would say that is this not the greatest approach to get
>> your code merged (to say the least).
>
> Clearly not. But Pali found bug in code Felipe should
> maintain. Instead of "thank you for bug report, I applied this one
> line of your code to fix it", Pali got "new patch, new email" for his
> efforts. That is how you train dogs, not how you should treat kernel
> contributors.
>

No, you misunderstood the role of the maintainers. Maintainers should
be custodian of a part of the kernel but not responsible for every
single line of code on their sub-systems. If a piece of code is buggy
then the people using and that take care of that should be fixing and
maintainers should review and suggest improvements to the patches. As
long as a piece of code keep compiling then it is harmless even if is
buggy and nobody cares about it. If it is so broken that it doesn't
even compile then the maintainer can decide to just drop it since no
one else seems to care about it.

If someone finds a bug on a piece of code is because that people care
about that functionality. Maintainers are really busy people and can
jump and fix any random bug that someone finds on a piece of code just
because it is the subsystem they maintainer neither they have to
blindly merge any crappy patch just because they don't have time (or
interest) in fixing a reported bug on a piece of code.

> Now, it is possible that Felipe just has problems with english, as he
> called me piece of wood in https://lkml.org/lkml/2013/9/17/476 , but
> he appears more arogant than usual over email.
>

Clearly he meant "your commit log has garbage" instead of you're, that's a typo.

>                                                                 Pavel

But neither Felipe needs someone to defend him nor I have time to keep
arguing with you.

Have nice day!
Javier

Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 461 bytes --]

On Wednesday 18 September 2013 15:57:13 Javier Martinez Canillas 
wrote:
> to split the patch in two since the patch was solving
> two separate issues

My patch does not solving *two* issues. It is *one* regression 
and both parts of patch are needed for fixing it. Read commit 
message again. It does not make sense to split patch fixing kernel 
regression into more one line patches - or please clarify why.

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 461 bytes --]

On Wednesday 18 September 2013 15:57:13 Javier Martinez Canillas 
wrote:
> to split the patch in two since the patch was solving
> two separate issues

My patch does not solving *two* issues. It is *one* regression 
and both parts of patch are needed for fixing it. Read commit 
message again. It does not make sense to split patch fixing kernel 
regression into more one line patches - or please clarify why.

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Pali Rohár]

On Wednesday 18 September 2013 15:57:13 Javier Martinez Canillas 
wrote:
> to split the patch in two since the patch was solving
> two separate issues

My patch does not solving *two* issues. It is *one* regression 
and both parts of patch are needed for fixing it. Read commit 
message again. It does not make sense to split patch fixing kernel 
regression into more one line patches - or please clarify why.

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130918/e9dbd364/attachment.sig>

Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1167 bytes --]

Hi,

On Wed, Sep 18, 2013 at 04:35:37PM +0200, Pavel Machek wrote:
> Hi!
> 
> > > gave feedback. If the sender doesn't want to take his feedback into
> > > account and prefer to send pretty insulting emails instead that is his
> > > choice but I would say that is this not the greatest approach to get
> > > your code merged (to say the least).
> > 
> > Clearly not. But Pali found bug in code Felipe should
> > maintain. Instead of "thank you for bug report, I applied this one
> > line of your code to fix it", Pali got "new patch, new email" for his
> > efforts. That is how you train dogs, not how you should treat kernel
> > contributors.
> > 
> > Now, it is possible that Felipe just has problems with english, as he
> > called me piece of wood in https://lkml.org/lkml/2013/9/17/476 , but
> > he appears more arogant than usual over email.
> 
> Actually he called me "piece of wood with garbage in it". I guess I
> have right to be offended. I'm baby in the next email. Hmm.

what a baby. Grow up dude, just grow up. I said your commit log has
garbage which shouldn't be there (there was a typo you're instead of
your).

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Felipe Balbi]

[-- Attachment #1.1: Type: text/plain, Size: 1167 bytes --]

Hi,

On Wed, Sep 18, 2013 at 04:35:37PM +0200, Pavel Machek wrote:
> Hi!
> 
> > > gave feedback. If the sender doesn't want to take his feedback into
> > > account and prefer to send pretty insulting emails instead that is his
> > > choice but I would say that is this not the greatest approach to get
> > > your code merged (to say the least).
> > 
> > Clearly not. But Pali found bug in code Felipe should
> > maintain. Instead of "thank you for bug report, I applied this one
> > line of your code to fix it", Pali got "new patch, new email" for his
> > efforts. That is how you train dogs, not how you should treat kernel
> > contributors.
> > 
> > Now, it is possible that Felipe just has problems with english, as he
> > called me piece of wood in https://lkml.org/lkml/2013/9/17/476 , but
> > he appears more arogant than usual over email.
> 
> Actually he called me "piece of wood with garbage in it". I guess I
> have right to be offended. I'm baby in the next email. Hmm.

what a baby. Grow up dude, just grow up. I said your commit log has
garbage which shouldn't be there (there was a typo you're instead of
your).

-- 
balbi

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Felipe Balbi]

Hi,

On Wed, Sep 18, 2013 at 04:35:37PM +0200, Pavel Machek wrote:
> Hi!
> 
> > > gave feedback. If the sender doesn't want to take his feedback into
> > > account and prefer to send pretty insulting emails instead that is his
> > > choice but I would say that is this not the greatest approach to get
> > > your code merged (to say the least).
> > 
> > Clearly not. But Pali found bug in code Felipe should
> > maintain. Instead of "thank you for bug report, I applied this one
> > line of your code to fix it", Pali got "new patch, new email" for his
> > efforts. That is how you train dogs, not how you should treat kernel
> > contributors.
> > 
> > Now, it is possible that Felipe just has problems with english, as he
> > called me piece of wood in https://lkml.org/lkml/2013/9/17/476 , but
> > he appears more arogant than usual over email.
> 
> Actually he called me "piece of wood with garbage in it". I guess I
> have right to be offended. I'm baby in the next email. Hmm.

what a baby. Grow up dude, just grow up. I said your commit log has
garbage which shouldn't be there (there was a typo you're instead of
your).

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130918/d419425d/attachment.sig>

Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 648 bytes --]

On Wed, Sep 18, 2013 at 05:56:12PM +0200, Pali Rohár wrote:
> On Wednesday 18 September 2013 15:57:13 Javier Martinez Canillas 
> wrote:
> > to split the patch in two since the patch was solving
> > two separate issues
> 
> My patch does not solving *two* issues. It is *one* regression 
> and both parts of patch are needed for fixing it. Read commit 
> message again. It does not make sense to split patch fixing kernel 
> regression into more one line patches - or please clarify why.

issue 1) twl4030-usb.c doesn't initialize atomic notifier head
issue 2) musb doesn't call notifier chain

do you need a drawing ?

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Felipe Balbi]

[-- Attachment #1.1: Type: text/plain, Size: 648 bytes --]

On Wed, Sep 18, 2013 at 05:56:12PM +0200, Pali Rohár wrote:
> On Wednesday 18 September 2013 15:57:13 Javier Martinez Canillas 
> wrote:
> > to split the patch in two since the patch was solving
> > two separate issues
> 
> My patch does not solving *two* issues. It is *one* regression 
> and both parts of patch are needed for fixing it. Read commit 
> message again. It does not make sense to split patch fixing kernel 
> regression into more one line patches - or please clarify why.

issue 1) twl4030-usb.c doesn't initialize atomic notifier head
issue 2) musb doesn't call notifier chain

do you need a drawing ?

-- 
balbi

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Felipe Balbi]

On Wed, Sep 18, 2013 at 05:56:12PM +0200, Pali Roh?r wrote:
> On Wednesday 18 September 2013 15:57:13 Javier Martinez Canillas 
> wrote:
> > to split the patch in two since the patch was solving
> > two separate issues
> 
> My patch does not solving *two* issues. It is *one* regression 
> and both parts of patch are needed for fixing it. Read commit 
> message again. It does not make sense to split patch fixing kernel 
> regression into more one line patches - or please clarify why.

issue 1) twl4030-usb.c doesn't initialize atomic notifier head
issue 2) musb doesn't call notifier chain

do you need a drawing ?

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130918/09be804b/attachment.sig>

Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 978 bytes --]

On Wednesday 18 September 2013 18:36:49 Felipe Balbi wrote:
> On Wed, Sep 18, 2013 at 05:56:12PM +0200, Pali Rohár wrote:
> > On Wednesday 18 September 2013 15:57:13 Javier Martinez
> > Canillas
> > 
> > wrote:
> > > to split the patch in two since the patch was solving
> > > two separate issues
> > 
> > My patch does not solving *two* issues. It is *one*
> > regression and both parts of patch are needed for fixing
> > it. Read commit message again. It does not make sense to
> > split patch fixing kernel regression into more one line
> > patches - or please clarify why.
> 
> issue 1) twl4030-usb.c doesn't initialize atomic notifier head
> issue 2) musb doesn't call notifier chain
> 
> do you need a drawing ?

Regression 1) power supply drivers not working since v3.5

Look at firsts emails.


Do you really have problem to do what *you* need with 1 line 
patch which I sent? Or what what you want?

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 978 bytes --]

On Wednesday 18 September 2013 18:36:49 Felipe Balbi wrote:
> On Wed, Sep 18, 2013 at 05:56:12PM +0200, Pali Rohár wrote:
> > On Wednesday 18 September 2013 15:57:13 Javier Martinez
> > Canillas
> > 
> > wrote:
> > > to split the patch in two since the patch was solving
> > > two separate issues
> > 
> > My patch does not solving *two* issues. It is *one*
> > regression and both parts of patch are needed for fixing
> > it. Read commit message again. It does not make sense to
> > split patch fixing kernel regression into more one line
> > patches - or please clarify why.
> 
> issue 1) twl4030-usb.c doesn't initialize atomic notifier head
> issue 2) musb doesn't call notifier chain
> 
> do you need a drawing ?

Regression 1) power supply drivers not working since v3.5

Look at firsts emails.


Do you really have problem to do what *you* need with 1 line 
patch which I sent? Or what what you want?

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Pali Rohár]

On Wednesday 18 September 2013 18:36:49 Felipe Balbi wrote:
> On Wed, Sep 18, 2013 at 05:56:12PM +0200, Pali Roh?r wrote:
> > On Wednesday 18 September 2013 15:57:13 Javier Martinez
> > Canillas
> > 
> > wrote:
> > > to split the patch in two since the patch was solving
> > > two separate issues
> > 
> > My patch does not solving *two* issues. It is *one*
> > regression and both parts of patch are needed for fixing
> > it. Read commit message again. It does not make sense to
> > split patch fixing kernel regression into more one line
> > patches - or please clarify why.
> 
> issue 1) twl4030-usb.c doesn't initialize atomic notifier head
> issue 2) musb doesn't call notifier chain
> 
> do you need a drawing ?

Regression 1) power supply drivers not working since v3.5

Look at firsts emails.


Do you really have problem to do what *you* need with 1 line 
patch which I sent? Or what what you want?

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130918/7f96b2a0/attachment.sig>

Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1301 bytes --]

On Wed, Sep 18, 2013 at 06:43:49PM +0200, Pali Rohár wrote:
> On Wednesday 18 September 2013 18:36:49 Felipe Balbi wrote:
> > On Wed, Sep 18, 2013 at 05:56:12PM +0200, Pali Rohár wrote:
> > > On Wednesday 18 September 2013 15:57:13 Javier Martinez
> > > Canillas
> > > 
> > > wrote:
> > > > to split the patch in two since the patch was solving
> > > > two separate issues
> > > 
> > > My patch does not solving *two* issues. It is *one*
> > > regression and both parts of patch are needed for fixing
> > > it. Read commit message again. It does not make sense to
> > > split patch fixing kernel regression into more one line
> > > patches - or please clarify why.
> > 
> > issue 1) twl4030-usb.c doesn't initialize atomic notifier head
> > issue 2) musb doesn't call notifier chain
> > 
> > do you need a drawing ?
> 
> Regression 1) power supply drivers not working since v3.5
> 
> Look at firsts emails.
> 
> 
> Do you really have problem to do what *you* need with 1 line 
> patch which I sent? Or what what you want?

if you had already resent patches the way I requested, they'd already be
applied. Instead you chose to troll the people who are trying to helping
out.

You have two issues being fixed in the same patch and that's not
acceptable.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Felipe Balbi]

[-- Attachment #1.1: Type: text/plain, Size: 1301 bytes --]

On Wed, Sep 18, 2013 at 06:43:49PM +0200, Pali Rohár wrote:
> On Wednesday 18 September 2013 18:36:49 Felipe Balbi wrote:
> > On Wed, Sep 18, 2013 at 05:56:12PM +0200, Pali Rohár wrote:
> > > On Wednesday 18 September 2013 15:57:13 Javier Martinez
> > > Canillas
> > > 
> > > wrote:
> > > > to split the patch in two since the patch was solving
> > > > two separate issues
> > > 
> > > My patch does not solving *two* issues. It is *one*
> > > regression and both parts of patch are needed for fixing
> > > it. Read commit message again. It does not make sense to
> > > split patch fixing kernel regression into more one line
> > > patches - or please clarify why.
> > 
> > issue 1) twl4030-usb.c doesn't initialize atomic notifier head
> > issue 2) musb doesn't call notifier chain
> > 
> > do you need a drawing ?
> 
> Regression 1) power supply drivers not working since v3.5
> 
> Look at firsts emails.
> 
> 
> Do you really have problem to do what *you* need with 1 line 
> patch which I sent? Or what what you want?

if you had already resent patches the way I requested, they'd already be
applied. Instead you chose to troll the people who are trying to helping
out.

You have two issues being fixed in the same patch and that's not
acceptable.

-- 
balbi

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Felipe Balbi]

On Wed, Sep 18, 2013 at 06:43:49PM +0200, Pali Roh?r wrote:
> On Wednesday 18 September 2013 18:36:49 Felipe Balbi wrote:
> > On Wed, Sep 18, 2013 at 05:56:12PM +0200, Pali Roh?r wrote:
> > > On Wednesday 18 September 2013 15:57:13 Javier Martinez
> > > Canillas
> > > 
> > > wrote:
> > > > to split the patch in two since the patch was solving
> > > > two separate issues
> > > 
> > > My patch does not solving *two* issues. It is *one*
> > > regression and both parts of patch are needed for fixing
> > > it. Read commit message again. It does not make sense to
> > > split patch fixing kernel regression into more one line
> > > patches - or please clarify why.
> > 
> > issue 1) twl4030-usb.c doesn't initialize atomic notifier head
> > issue 2) musb doesn't call notifier chain
> > 
> > do you need a drawing ?
> 
> Regression 1) power supply drivers not working since v3.5
> 
> Look at firsts emails.
> 
> 
> Do you really have problem to do what *you* need with 1 line 
> patch which I sent? Or what what you want?

if you had already resent patches the way I requested, they'd already be
applied. Instead you chose to troll the people who are trying to helping
out.

You have two issues being fixed in the same patch and that's not
acceptable.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130918/68a1dfef/attachment-0001.sig>

[PATCH usb 1/2] usb: musb: Add missing ATOMIC_INIT_NOTIFIER_HEAD

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 673 bytes --]

&twl->phy.notifier is not initalized

Signed-off-by: Pali Rohár <pali.rohar@gmail.com>

diff --git a/drivers/usb/phy/phy-twl4030-usb.c b/drivers/usb/phy/phy-twl4030-usb.c
index 8f78d2d..efe6155 100644
--- a/drivers/usb/phy/phy-twl4030-usb.c
+++ b/drivers/usb/phy/phy-twl4030-usb.c
@@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct platform_device *pdev)
 	if (device_create_file(&pdev->dev, &dev_attr_vbus))
 		dev_warn(&pdev->dev, "could not create sysfs file\n");
 
+	ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
+
 	/* Our job is to use irqs and status from the power module
 	 * to keep the transceiver disabled when nothing's connected.
 	 *

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[PATCH usb 1/2] usb: musb: Add missing ATOMIC_INIT_NOTIFIER_HEAD

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 673 bytes --]

&twl->phy.notifier is not initalized

Signed-off-by: Pali Rohár <pali.rohar@gmail.com>

diff --git a/drivers/usb/phy/phy-twl4030-usb.c b/drivers/usb/phy/phy-twl4030-usb.c
index 8f78d2d..efe6155 100644
--- a/drivers/usb/phy/phy-twl4030-usb.c
+++ b/drivers/usb/phy/phy-twl4030-usb.c
@@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct platform_device *pdev)
 	if (device_create_file(&pdev->dev, &dev_attr_vbus))
 		dev_warn(&pdev->dev, "could not create sysfs file\n");
 
+	ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
+
 	/* Our job is to use irqs and status from the power module
 	 * to keep the transceiver disabled when nothing's connected.
 	 *

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[PATCH usb 1/2] usb: musb: Add missing ATOMIC_INIT_NOTIFIER_HEAD

[Pali Rohár]

&twl->phy.notifier is not initalized

Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>

diff --git a/drivers/usb/phy/phy-twl4030-usb.c b/drivers/usb/phy/phy-twl4030-usb.c
index 8f78d2d..efe6155 100644
--- a/drivers/usb/phy/phy-twl4030-usb.c
+++ b/drivers/usb/phy/phy-twl4030-usb.c
@@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct platform_device *pdev)
 	if (device_create_file(&pdev->dev, &dev_attr_vbus))
 		dev_warn(&pdev->dev, "could not create sysfs file\n");
 
+	ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
+
 	/* Our job is to use irqs and status from the power module
 	 * to keep the transceiver disabled when nothing's connected.
 	 *
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130918/48b5af9e/attachment.sig>

[PATCH usb 2/2] usb: musb: Call atomic_notifier_call_chain when status is changed

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 1165 bytes --]

More power supply drivers depends on vbus events and without it they not
working. Power supply drivers using usb_register_notifier, so to deliver
events it is needed to call atomic_notifier_call_chain.

So without atomic notifier power supply driver isp1704 not retrieving
vbus status and reporting bogus values to userspace and also to board
platform data functions. Without proper data charger drivers trying to
charge battery also when charger is disconnected or do not start charging
when wallcharger connects.

Atomic notifier in musb driver was used before v3.5 and was replaced with
omap mailbox. This patch adding atomic_notifier_call_chain call from
function omap_musb_set_mailbox.

Signed-off-by: Pali Rohár <pali.rohar@gmail.com>

diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index f44e8b5..5c40252 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -305,6 +305,9 @@ static void omap_musb_set_mailbox(struct omap2430_glue *glue)
 	default:
 		dev_dbg(dev, "ID float\n");
 	}
+
+	atomic_notifier_call_chain(&musb->xceiv->notifier,
+			musb->xceiv->last_event, NULL);
 }
 

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[PATCH usb 2/2] usb: musb: Call atomic_notifier_call_chain when status is changed

[Pali Rohár]

[-- Attachment #1.1: Type: Text/Plain, Size: 1165 bytes --]

More power supply drivers depends on vbus events and without it they not
working. Power supply drivers using usb_register_notifier, so to deliver
events it is needed to call atomic_notifier_call_chain.

So without atomic notifier power supply driver isp1704 not retrieving
vbus status and reporting bogus values to userspace and also to board
platform data functions. Without proper data charger drivers trying to
charge battery also when charger is disconnected or do not start charging
when wallcharger connects.

Atomic notifier in musb driver was used before v3.5 and was replaced with
omap mailbox. This patch adding atomic_notifier_call_chain call from
function omap_musb_set_mailbox.

Signed-off-by: Pali Rohár <pali.rohar@gmail.com>

diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index f44e8b5..5c40252 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -305,6 +305,9 @@ static void omap_musb_set_mailbox(struct omap2430_glue *glue)
 	default:
 		dev_dbg(dev, "ID float\n");
 	}
+
+	atomic_notifier_call_chain(&musb->xceiv->notifier,
+			musb->xceiv->last_event, NULL);
 }
 

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH usb 2/2] usb: musb: Call atomic_notifier_call_chain when status is changed

[Pali Rohár]

More power supply drivers depends on vbus events and without it they not
working. Power supply drivers using usb_register_notifier, so to deliver
events it is needed to call atomic_notifier_call_chain.

So without atomic notifier power supply driver isp1704 not retrieving
vbus status and reporting bogus values to userspace and also to board
platform data functions. Without proper data charger drivers trying to
charge battery also when charger is disconnected or do not start charging
when wallcharger connects.

Atomic notifier in musb driver was used before v3.5 and was replaced with
omap mailbox. This patch adding atomic_notifier_call_chain call from
function omap_musb_set_mailbox.

Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>

diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index f44e8b5..5c40252 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -305,6 +305,9 @@ static void omap_musb_set_mailbox(struct omap2430_glue *glue)
 	default:
 		dev_dbg(dev, "ID float\n");
 	}
+
+	atomic_notifier_call_chain(&musb->xceiv->notifier,
+			musb->xceiv->last_event, NULL);
 }
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130918/1407c00d/attachment.sig>

Re: [PATCH 4/4] RX-51: Add platform function and data for bq24150a charger

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 4040 bytes --]

On Sunday 08 September 2013 10:50:39 Pali Rohár wrote:
> This patch will register bq24150a charger in RX-51 board data.
> Patch also adding platform function between isp1704 and
> bq2415x drivers for detecting charger type.
> 
> So finally charging battery on Nokia N900 (RX-51) working
> automatically without any proprietary Nokia bits in userspace.
> 
> Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> ---
>  arch/arm/mach-omap2/board-rx51-peripherals.c |   56
> +++++++++++++++++++++++++- 1 file changed, 55 insertions(+),
> 1 deletion(-)
> 
> diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
> b/arch/arm/mach-omap2/board-rx51-peripherals.c index
> 9c2dd10..a993ffe 100644
> --- a/arch/arm/mach-omap2/board-rx51-peripherals.c
> +++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
> @@ -25,6 +25,7 @@
>  #include <linux/gpio_keys.h>
>  #include <linux/mmc/host.h>
>  #include <linux/power/isp1704_charger.h>
> +#include <linux/power/bq2415x_charger.h>
>  #include <linux/platform_data/spi-omap2-mcspi.h>
>  #include <linux/platform_data/mtd-onenand-omap2.h>
> 
> @@ -270,6 +271,44 @@ static struct platform_device
> rx51_battery_device = { .id	= -1,
>  };
> 
> +static enum bq2415x_mode rx51_charger_mode =
> BQ2415X_MODE_OFF; +static void *rx51_charger_hook_data;
> +static void (*rx51_charger_hook)(enum bq2415x_mode mode, void
> *data); +
> +static int rx51_charger_set_hook(
> +		void (*hook)(enum bq2415x_mode mode, void *data), void
> *data) +{
> +	rx51_charger_hook = hook;
> +	rx51_charger_hook_data = data;
> +	if (rx51_charger_hook)
> +		rx51_charger_hook(rx51_charger_mode,
> rx51_charger_hook_data); +	return 1;
> +}
> +
> +static void rx51_charger_set_current(int mA)
> +{
> +	enum bq2415x_mode mode;
> +
> +	pr_info("RX-51: Charger current limit is %d mA\n", mA);
> +
> +	if (mA == 0)
> +		mode = BQ2415X_MODE_OFF;
> +	else if (mA < 500)
> +		mode = BQ2415X_MODE_NONE;
> +	else if (mA < 1800)
> +		mode = BQ2415X_MODE_HOST_CHARGER;
> +	else
> +		mode = BQ2415X_MODE_DEDICATED_CHARGER;
> +
> +	if (rx51_charger_mode == mode)
> +		return;
> +
> +	rx51_charger_mode = mode;
> +
> +	if (rx51_charger_hook)
> +		rx51_charger_hook(rx51_charger_mode,
> rx51_charger_hook_data); +}
> +
>  static void rx51_charger_set_power(bool on)
>  {
>  	gpio_set_value(RX51_USB_TRANSCEIVER_RST_GPIO, on);
> @@ -277,6 +316,7 @@ static void rx51_charger_set_power(bool
> on)
> 
>  static struct isp1704_charger_data rx51_charger_data = {
>  	.set_power	= rx51_charger_set_power,
> +	.set_current	= rx51_charger_set_current,
>  };
> 
>  static struct platform_device rx51_charger_device = {
> @@ -1017,6 +1057,16 @@ static struct aic3x_pdata
> rx51_aic3x_data2 = { .gpio_reset = 60,
>  };
> 
> +static struct bq2415x_platform_data
> rx51_bq24150a_platform_data = { +	.current_limit = 100,			
/*
> mA */
> +	.weak_battery_voltage = 3400,		/* mV */
> +	.battery_regulation_voltage = 4200,	/* mV */
> +	.charge_current = 650,			/* mA */
> +	.termination_current = 100,		/* mA */
> +	.resistor_sense = 68,			/* m ohm */
> +	.set_mode_hook = &rx51_charger_set_hook,
> +};
> +
>  static struct i2c_board_info __initdata
> rx51_peripherals_i2c_board_info_2[] = { {
>  		I2C_BOARD_INFO("tlv320aic3x", 0x18),
> @@ -1044,7 +1094,11 @@ static struct i2c_board_info __initdata
> rx51_peripherals_i2c_board_info_2[] = { {
>  		I2C_BOARD_INFO("tpa6130a2", 0x60),
>  		.platform_data = &rx51_tpa6130a2_data,
> -	}
> +	},
> +	{
> +		I2C_BOARD_INFO("bq24150a", 0x6b),
> +		.platform_data = &rx51_bq24150a_platform_data,
> +	},
>  };
> 
>  static struct i2c_board_info __initdata
> rx51_peripherals_i2c_board_info_3[] = {

Tony, can you look and review this board patch?

I think that this patch series it the most important for Nokia 
N900, because it finally bringing charging support. And without 
charging battery it very hard to use phone which has power supply 
only from battery.

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[PATCH 4/4] RX-51: Add platform function and data for bq24150a charger

[Pali Rohár]

On Sunday 08 September 2013 10:50:39 Pali Roh?r wrote:
> This patch will register bq24150a charger in RX-51 board data.
> Patch also adding platform function between isp1704 and
> bq2415x drivers for detecting charger type.
> 
> So finally charging battery on Nokia N900 (RX-51) working
> automatically without any proprietary Nokia bits in userspace.
> 
> Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>
> ---
>  arch/arm/mach-omap2/board-rx51-peripherals.c |   56
> +++++++++++++++++++++++++- 1 file changed, 55 insertions(+),
> 1 deletion(-)
> 
> diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
> b/arch/arm/mach-omap2/board-rx51-peripherals.c index
> 9c2dd10..a993ffe 100644
> --- a/arch/arm/mach-omap2/board-rx51-peripherals.c
> +++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
> @@ -25,6 +25,7 @@
>  #include <linux/gpio_keys.h>
>  #include <linux/mmc/host.h>
>  #include <linux/power/isp1704_charger.h>
> +#include <linux/power/bq2415x_charger.h>
>  #include <linux/platform_data/spi-omap2-mcspi.h>
>  #include <linux/platform_data/mtd-onenand-omap2.h>
> 
> @@ -270,6 +271,44 @@ static struct platform_device
> rx51_battery_device = { .id	= -1,
>  };
> 
> +static enum bq2415x_mode rx51_charger_mode =
> BQ2415X_MODE_OFF; +static void *rx51_charger_hook_data;
> +static void (*rx51_charger_hook)(enum bq2415x_mode mode, void
> *data); +
> +static int rx51_charger_set_hook(
> +		void (*hook)(enum bq2415x_mode mode, void *data), void
> *data) +{
> +	rx51_charger_hook = hook;
> +	rx51_charger_hook_data = data;
> +	if (rx51_charger_hook)
> +		rx51_charger_hook(rx51_charger_mode,
> rx51_charger_hook_data); +	return 1;
> +}
> +
> +static void rx51_charger_set_current(int mA)
> +{
> +	enum bq2415x_mode mode;
> +
> +	pr_info("RX-51: Charger current limit is %d mA\n", mA);
> +
> +	if (mA == 0)
> +		mode = BQ2415X_MODE_OFF;
> +	else if (mA < 500)
> +		mode = BQ2415X_MODE_NONE;
> +	else if (mA < 1800)
> +		mode = BQ2415X_MODE_HOST_CHARGER;
> +	else
> +		mode = BQ2415X_MODE_DEDICATED_CHARGER;
> +
> +	if (rx51_charger_mode == mode)
> +		return;
> +
> +	rx51_charger_mode = mode;
> +
> +	if (rx51_charger_hook)
> +		rx51_charger_hook(rx51_charger_mode,
> rx51_charger_hook_data); +}
> +
>  static void rx51_charger_set_power(bool on)
>  {
>  	gpio_set_value(RX51_USB_TRANSCEIVER_RST_GPIO, on);
> @@ -277,6 +316,7 @@ static void rx51_charger_set_power(bool
> on)
> 
>  static struct isp1704_charger_data rx51_charger_data = {
>  	.set_power	= rx51_charger_set_power,
> +	.set_current	= rx51_charger_set_current,
>  };
> 
>  static struct platform_device rx51_charger_device = {
> @@ -1017,6 +1057,16 @@ static struct aic3x_pdata
> rx51_aic3x_data2 = { .gpio_reset = 60,
>  };
> 
> +static struct bq2415x_platform_data
> rx51_bq24150a_platform_data = { +	.current_limit = 100,			
/*
> mA */
> +	.weak_battery_voltage = 3400,		/* mV */
> +	.battery_regulation_voltage = 4200,	/* mV */
> +	.charge_current = 650,			/* mA */
> +	.termination_current = 100,		/* mA */
> +	.resistor_sense = 68,			/* m ohm */
> +	.set_mode_hook = &rx51_charger_set_hook,
> +};
> +
>  static struct i2c_board_info __initdata
> rx51_peripherals_i2c_board_info_2[] = { {
>  		I2C_BOARD_INFO("tlv320aic3x", 0x18),
> @@ -1044,7 +1094,11 @@ static struct i2c_board_info __initdata
> rx51_peripherals_i2c_board_info_2[] = { {
>  		I2C_BOARD_INFO("tpa6130a2", 0x60),
>  		.platform_data = &rx51_tpa6130a2_data,
> -	}
> +	},
> +	{
> +		I2C_BOARD_INFO("bq24150a", 0x6b),
> +		.platform_data = &rx51_bq24150a_platform_data,
> +	},
>  };
> 
>  static struct i2c_board_info __initdata
> rx51_peripherals_i2c_board_info_3[] = {

Tony, can you look and review this board patch?

I think that this patch series it the most important for Nokia 
N900, because it finally bringing charging support. And without 
charging battery it very hard to use phone which has power supply 
only from battery.

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130920/f25e367a/attachment.sig>

Re: [PATCH 0/4] Add support for charging battery in Nokia RX-51

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 1042 bytes --]

On Sunday 08 September 2013 10:50:35 Pali Rohár wrote:
> This patch series finally bringing support for charging
> battery on Nokia N900 (RX-51) without any proprietary Nokia
> bits in userspace.
> 
> Pali Rohár (4):
>   usb: musb: Call atomic_notifier_call_chain when status is
> changed power: isp1704_charger: Fix driver to work with
> changes introduced in v3.5
>   power: isp1704_charger: Add callback function set_current
>   RX-51: Add platform function and data for bq24150a charger
> 
>  arch/arm/mach-omap2/board-rx51-peripherals.c |   56
> +++++++++++++- drivers/power/isp1704_charger.c              |
>  107 ++++++++++++++------------ drivers/usb/musb/omap2430.c  
>                |    3 + drivers/usb/phy/phy-twl4030-usb.c    
>        |    2 + include/linux/power/isp1704_charger.h       
> |    1 + 5 files changed, 117 insertions(+), 52 deletions(-)

Anton, can you review this patch series, specially power supply 
code (changes to isp1704_charger.c driver)?

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[PATCH 0/4] Add support for charging battery in Nokia RX-51

[Pali Rohár]

On Sunday 08 September 2013 10:50:35 Pali Roh?r wrote:
> This patch series finally bringing support for charging
> battery on Nokia N900 (RX-51) without any proprietary Nokia
> bits in userspace.
> 
> Pali Roh?r (4):
>   usb: musb: Call atomic_notifier_call_chain when status is
> changed power: isp1704_charger: Fix driver to work with
> changes introduced in v3.5
>   power: isp1704_charger: Add callback function set_current
>   RX-51: Add platform function and data for bq24150a charger
> 
>  arch/arm/mach-omap2/board-rx51-peripherals.c |   56
> +++++++++++++- drivers/power/isp1704_charger.c              |
>  107 ++++++++++++++------------ drivers/usb/musb/omap2430.c  
>                |    3 + drivers/usb/phy/phy-twl4030-usb.c    
>        |    2 + include/linux/power/isp1704_charger.h       
> |    1 + 5 files changed, 117 insertions(+), 52 deletions(-)

Anton, can you review this patch series, specially power supply 
code (changes to isp1704_charger.c driver)?

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130921/ac95098d/attachment.sig>

Re: [PATCH 4/4] RX-51: Add platform function and data for bq24150a charger

[Tony Lindgren]

* Pali Rohár <pali.rohar@gmail.com> [130920 12:29]:
> On Sunday 08 September 2013 10:50:39 Pali Rohár wrote:
> > This patch will register bq24150a charger in RX-51 board data.
> > Patch also adding platform function between isp1704 and
> > bq2415x drivers for detecting charger type.
> > 
> > So finally charging battery on Nokia N900 (RX-51) working
> > automatically without any proprietary Nokia bits in userspace.
...
 
> > @@ -277,6 +316,7 @@ static void rx51_charger_set_power(bool
> > on)
> > 
> >  static struct isp1704_charger_data rx51_charger_data = {
> >  	.set_power	= rx51_charger_set_power,
> > +	.set_current	= rx51_charger_set_current,
> >  };

We want to get rid of the platform data callbacks here,
there no longer any need to keep these under arch/arm.

> Tony, can you look and review this board patch?

Yes, looks like this can all be done in the driver nowadays.
You can use drivers/reset for the set_power. Or if it's really
controlling the regulator, then the regulator framework. The
info can be passed in a .dts file for those.

The .set_current you can do in the driver based on the
compatible flag.
 
> I think that this patch series it the most important for Nokia 
> N900, because it finally bringing charging support. And without 
> charging battery it very hard to use phone which has power supply 
> only from battery.

Right, let's get this driver updated to use the device tree
based init and that way this file is no longer needed.
I would like to $ grep -i grandmom ~/.phonebook | call too :)

I forgot how this charger is wired up, but maybe take a
look at commit d7bf353f (bq24190_charger: Add support for TI
BQ24190 Battery Charger) for the DT parts.

Regards,

Tony

[PATCH 4/4] RX-51: Add platform function and data for bq24150a charger

[Tony Lindgren]

* Pali Roh?r <pali.rohar@gmail.com> [130920 12:29]:
> On Sunday 08 September 2013 10:50:39 Pali Roh?r wrote:
> > This patch will register bq24150a charger in RX-51 board data.
> > Patch also adding platform function between isp1704 and
> > bq2415x drivers for detecting charger type.
> > 
> > So finally charging battery on Nokia N900 (RX-51) working
> > automatically without any proprietary Nokia bits in userspace.
...
 
> > @@ -277,6 +316,7 @@ static void rx51_charger_set_power(bool
> > on)
> > 
> >  static struct isp1704_charger_data rx51_charger_data = {
> >  	.set_power	= rx51_charger_set_power,
> > +	.set_current	= rx51_charger_set_current,
> >  };

We want to get rid of the platform data callbacks here,
there no longer any need to keep these under arch/arm.

> Tony, can you look and review this board patch?

Yes, looks like this can all be done in the driver nowadays.
You can use drivers/reset for the set_power. Or if it's really
controlling the regulator, then the regulator framework. The
info can be passed in a .dts file for those.

The .set_current you can do in the driver based on the
compatible flag.
 
> I think that this patch series it the most important for Nokia 
> N900, because it finally bringing charging support. And without 
> charging battery it very hard to use phone which has power supply 
> only from battery.

Right, let's get this driver updated to use the device tree
based init and that way this file is no longer needed.
I would like to $ grep -i grandmom ~/.phonebook | call too :)

I forgot how this charger is wired up, but maybe take a
look at commit d7bf353f (bq24190_charger: Add support for TI
BQ24190 Battery Charger) for the DT parts.

Regards,

Tony

Re: [PATCH 4/4] RX-51: Add platform function and data for bq24150a charger

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 2578 bytes --]

Hello,

On Monday 23 September 2013 20:03:00 you wrote:
> * Pali Rohár <pali.rohar@gmail.com> [130920 12:29]:
> > On Sunday 08 September 2013 10:50:39 Pali Rohár wrote:
> > > This patch will register bq24150a charger in RX-51 board
> > > data. Patch also adding platform function between isp1704
> > > and bq2415x drivers for detecting charger type.
> > > 
> > > So finally charging battery on Nokia N900 (RX-51) working
> > > automatically without any proprietary Nokia bits in
> > > userspace.
> 
> ...
> 
> > > @@ -277,6 +316,7 @@ static void
> > > rx51_charger_set_power(bool on)
> > > 
> > >  static struct isp1704_charger_data rx51_charger_data = {
> > >  
> > >  	.set_power	= rx51_charger_set_power,
> > > 
> > > +	.set_current	= rx51_charger_set_current,
> > > 
> > >  };
> 
> We want to get rid of the platform data callbacks here,
> there no longer any need to keep these under arch/arm.
> 

Where to put rx51 board specified functions?
It cannot go to DT, because DT does not support C/ASM code.

> > Tony, can you look and review this board patch?
> 
> Yes, looks like this can all be done in the driver nowadays.
> You can use drivers/reset for the set_power. Or if it's really
> controlling the regulator, then the regulator framework. The
> info can be passed in a .dts file for those.
> 
> The .set_current you can do in the driver based on the
> compatible flag.
> 

It is not as simple as it looks. This is reason why I submited 
this patch long time after I submited bq2415x driver.

Problem is that for rx51 is needed specific function which connect 
to two drivers (bq2415x and isp1704) plus it call specific rx51 
board functions.

Something which cannot be in DT (unless DT support C/ASM code).

> > I think that this patch series it the most important for
> > Nokia N900, because it finally bringing charging support.
> > And without charging battery it very hard to use phone
> > which has power supply only from battery.
> 
> Right, let's get this driver updated to use the device tree
> based init and that way this file is no longer needed.
> I would like to $ grep -i grandmom ~/.phonebook | call too :)
> 

Patches for modem support are being prepared for upstreaming :-) 
so after that it is up to you to create "call" script as you want

> I forgot how this charger is wired up, but maybe take a
> look at commit d7bf353f (bq24190_charger: Add support for TI
> BQ24190 Battery Charger) for the DT parts.
> 
> Regards,
> 
> Tony

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[PATCH 4/4] RX-51: Add platform function and data for bq24150a charger

[Pali Rohár]

Hello,

On Monday 23 September 2013 20:03:00 you wrote:
> * Pali Roh?r <pali.rohar@gmail.com> [130920 12:29]:
> > On Sunday 08 September 2013 10:50:39 Pali Roh?r wrote:
> > > This patch will register bq24150a charger in RX-51 board
> > > data. Patch also adding platform function between isp1704
> > > and bq2415x drivers for detecting charger type.
> > > 
> > > So finally charging battery on Nokia N900 (RX-51) working
> > > automatically without any proprietary Nokia bits in
> > > userspace.
> 
> ...
> 
> > > @@ -277,6 +316,7 @@ static void
> > > rx51_charger_set_power(bool on)
> > > 
> > >  static struct isp1704_charger_data rx51_charger_data = {
> > >  
> > >  	.set_power	= rx51_charger_set_power,
> > > 
> > > +	.set_current	= rx51_charger_set_current,
> > > 
> > >  };
> 
> We want to get rid of the platform data callbacks here,
> there no longer any need to keep these under arch/arm.
> 

Where to put rx51 board specified functions?
It cannot go to DT, because DT does not support C/ASM code.

> > Tony, can you look and review this board patch?
> 
> Yes, looks like this can all be done in the driver nowadays.
> You can use drivers/reset for the set_power. Or if it's really
> controlling the regulator, then the regulator framework. The
> info can be passed in a .dts file for those.
> 
> The .set_current you can do in the driver based on the
> compatible flag.
> 

It is not as simple as it looks. This is reason why I submited 
this patch long time after I submited bq2415x driver.

Problem is that for rx51 is needed specific function which connect 
to two drivers (bq2415x and isp1704) plus it call specific rx51 
board functions.

Something which cannot be in DT (unless DT support C/ASM code).

> > I think that this patch series it the most important for
> > Nokia N900, because it finally bringing charging support.
> > And without charging battery it very hard to use phone
> > which has power supply only from battery.
> 
> Right, let's get this driver updated to use the device tree
> based init and that way this file is no longer needed.
> I would like to $ grep -i grandmom ~/.phonebook | call too :)
> 

Patches for modem support are being prepared for upstreaming :-) 
so after that it is up to you to create "call" script as you want

> I forgot how this charger is wired up, but maybe take a
> look at commit d7bf353f (bq24190_charger: Add support for TI
> BQ24190 Battery Charger) for the DT parts.
> 
> Regards,
> 
> Tony

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130923/2395c3e1/attachment.sig>

Re: [PATCH 4/4] RX-51: Add platform function and data for bq24150a charger

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 983 bytes --]

On Mon, Sep 23, 2013 at 09:16:18PM +0200, Pali Rohár wrote:
> It is not as simple as it looks. This is reason why I submited 
> this patch long time after I submited bq2415x driver.
> 
> Problem is that for rx51 is needed specific function which connect 
> to two drivers (bq2415x and isp1704) plus it call specific rx51 
> board functions.
> 
> Something which cannot be in DT (unless DT support C/ASM code).

mh could isp1704 driver expose the data via the regulator framework?
Then the bq2415x chip can just use the regulator framework. This
should make converting to DT easy (by giving the bq2415x chip the
isp1704 as regulator) and uses existing standard interfaces.

> Patches for modem support are being prepared for upstreaming :-) 
> so after that it is up to you to create "call" script as you want

I'm on it. RFC round will be sent out this week. It seems
hwmod data is already finished, since i didn't get feedback for
that patch :)

-- Sebastian

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[PATCH 4/4] RX-51: Add platform function and data for bq24150a charger

[Sebastian Reichel]

On Mon, Sep 23, 2013 at 09:16:18PM +0200, Pali Roh?r wrote:
> It is not as simple as it looks. This is reason why I submited 
> this patch long time after I submited bq2415x driver.
> 
> Problem is that for rx51 is needed specific function which connect 
> to two drivers (bq2415x and isp1704) plus it call specific rx51 
> board functions.
> 
> Something which cannot be in DT (unless DT support C/ASM code).

mh could isp1704 driver expose the data via the regulator framework?
Then the bq2415x chip can just use the regulator framework. This
should make converting to DT easy (by giving the bq2415x chip the
isp1704 as regulator) and uses existing standard interfaces.

> Patches for modem support are being prepared for upstreaming :-) 
> so after that it is up to you to create "call" script as you want

I'm on it. RFC round will be sent out this week. It seems
hwmod data is already finished, since i didn't get feedback for
that patch :)

-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130923/853a6857/attachment.sig>

Re: [PATCH 4/4] RX-51: Add platform function and data for bq24150a charger

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 1286 bytes --]

On Monday 23 September 2013 22:00:09 Sebastian Reichel wrote:
> On Mon, Sep 23, 2013 at 09:16:18PM +0200, Pali Rohár wrote:
> > It is not as simple as it looks. This is reason why I
> > submited this patch long time after I submited bq2415x
> > driver.
> > 
> > Problem is that for rx51 is needed specific function which
> > connect to two drivers (bq2415x and isp1704) plus it call
> > specific rx51 board functions.
> > 
> > Something which cannot be in DT (unless DT support C/ASM
> > code).
> 
> mh could isp1704 driver expose the data via the regulator
> framework?

No, isp1704 is power supply driver and export data via power 
supply (sysfs) interface. It is not regulator but charger driver.

> Then the bq2415x chip can just use the regulator
> framework. This should make converting to DT easy (by giving
> the bq2415x chip the isp1704 as regulator) and uses existing
> standard interfaces.
> 
> > Patches for modem support are being prepared for upstreaming
> > :-) so after that it is up to you to create "call" script
> > as you want
> 
> I'm on it. RFC round will be sent out this week. It seems
> hwmod data is already finished, since i didn't get feedback
> for that patch :)
> 
> -- Sebastian

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[PATCH 4/4] RX-51: Add platform function and data for bq24150a charger

[Pali Rohár]

On Monday 23 September 2013 22:00:09 Sebastian Reichel wrote:
> On Mon, Sep 23, 2013 at 09:16:18PM +0200, Pali Roh?r wrote:
> > It is not as simple as it looks. This is reason why I
> > submited this patch long time after I submited bq2415x
> > driver.
> > 
> > Problem is that for rx51 is needed specific function which
> > connect to two drivers (bq2415x and isp1704) plus it call
> > specific rx51 board functions.
> > 
> > Something which cannot be in DT (unless DT support C/ASM
> > code).
> 
> mh could isp1704 driver expose the data via the regulator
> framework?

No, isp1704 is power supply driver and export data via power 
supply (sysfs) interface. It is not regulator but charger driver.

> Then the bq2415x chip can just use the regulator
> framework. This should make converting to DT easy (by giving
> the bq2415x chip the isp1704 as regulator) and uses existing
> standard interfaces.
> 
> > Patches for modem support are being prepared for upstreaming
> > :-) so after that it is up to you to create "call" script
> > as you want
> 
> I'm on it. RFC round will be sent out this week. It seems
> hwmod data is already finished, since i didn't get feedback
> for that patch :)
> 
> -- Sebastian

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130923/07adf26c/attachment.sig>

Re: [PATCH 4/4] RX-51: Add platform function and data for bq24150a charger

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 1122 bytes --]

On Mon, Sep 23, 2013 at 10:06:46PM +0200, Pali Rohár wrote:
> On Monday 23 September 2013 22:00:09 Sebastian Reichel wrote:
> > On Mon, Sep 23, 2013 at 09:16:18PM +0200, Pali Rohár wrote:
> > > It is not as simple as it looks. This is reason why I
> > > submited this patch long time after I submited bq2415x
> > > driver.
> > > 
> > > Problem is that for rx51 is needed specific function which
> > > connect to two drivers (bq2415x and isp1704) plus it call
> > > specific rx51 board functions.
> > > 
> > > Something which cannot be in DT (unless DT support C/ASM
> > > code).
> > 
> > mh could isp1704 driver expose the data via the regulator
> > framework?
> 
> No, isp1704 is power supply driver and export data via power 
> supply (sysfs) interface. It is not regulator but charger driver.

well it does not charge the battery directly, but just provides a
power line with 5 Volt and a specified amount of current to the
system, doesn't it?

From my POV this is a candiate for the regulator framework:

https://www.kernel.org/doc/Documentation/power/regulator/overview.txt

-- Sebastian

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[PATCH 4/4] RX-51: Add platform function and data for bq24150a charger

[Sebastian Reichel]

On Mon, Sep 23, 2013 at 10:06:46PM +0200, Pali Roh?r wrote:
> On Monday 23 September 2013 22:00:09 Sebastian Reichel wrote:
> > On Mon, Sep 23, 2013 at 09:16:18PM +0200, Pali Roh?r wrote:
> > > It is not as simple as it looks. This is reason why I
> > > submited this patch long time after I submited bq2415x
> > > driver.
> > > 
> > > Problem is that for rx51 is needed specific function which
> > > connect to two drivers (bq2415x and isp1704) plus it call
> > > specific rx51 board functions.
> > > 
> > > Something which cannot be in DT (unless DT support C/ASM
> > > code).
> > 
> > mh could isp1704 driver expose the data via the regulator
> > framework?
> 
> No, isp1704 is power supply driver and export data via power 
> supply (sysfs) interface. It is not regulator but charger driver.

well it does not charge the battery directly, but just provides a
power line with 5 Volt and a specified amount of current to the
system, doesn't it?

>From my POV this is a candiate for the regulator framework:

https://www.kernel.org/doc/Documentation/power/regulator/overview.txt

-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130923/458b2b62/attachment.sig>

Re: [PATCH 4/4] RX-51: Add platform function and data for bq24150a charger

[Tony Lindgren]

* Sebastian Reichel <sre@ring0.de> [130923 13:55]:
> On Mon, Sep 23, 2013 at 10:06:46PM +0200, Pali Rohár wrote:
> > On Monday 23 September 2013 22:00:09 Sebastian Reichel wrote:
> > > On Mon, Sep 23, 2013 at 09:16:18PM +0200, Pali Rohár wrote:
> > > > It is not as simple as it looks. This is reason why I
> > > > submited this patch long time after I submited bq2415x
> > > > driver.
> > > > 
> > > > Problem is that for rx51 is needed specific function which
> > > > connect to two drivers (bq2415x and isp1704) plus it call
> > > > specific rx51 board functions.
> > > > 
> > > > Something which cannot be in DT (unless DT support C/ASM
> > > > code).
> > > 
> > > mh could isp1704 driver expose the data via the regulator
> > > framework?
> > 
> > No, isp1704 is power supply driver and export data via power 
> > supply (sysfs) interface. It is not regulator but charger driver.
> 
> well it does not charge the battery directly, but just provides a
> power line with 5 Volt and a specified amount of current to the
> system, doesn't it?
> 
> From my POV this is a candiate for the regulator framework:
> 
> https://www.kernel.org/doc/Documentation/power/regulator/overview.txt

Yes I think we should be able handle that rail with the
regulator framework.

Regards,

Tony

[PATCH 4/4] RX-51: Add platform function and data for bq24150a charger

[Tony Lindgren]

* Sebastian Reichel <sre@ring0.de> [130923 13:55]:
> On Mon, Sep 23, 2013 at 10:06:46PM +0200, Pali Roh?r wrote:
> > On Monday 23 September 2013 22:00:09 Sebastian Reichel wrote:
> > > On Mon, Sep 23, 2013 at 09:16:18PM +0200, Pali Roh?r wrote:
> > > > It is not as simple as it looks. This is reason why I
> > > > submited this patch long time after I submited bq2415x
> > > > driver.
> > > > 
> > > > Problem is that for rx51 is needed specific function which
> > > > connect to two drivers (bq2415x and isp1704) plus it call
> > > > specific rx51 board functions.
> > > > 
> > > > Something which cannot be in DT (unless DT support C/ASM
> > > > code).
> > > 
> > > mh could isp1704 driver expose the data via the regulator
> > > framework?
> > 
> > No, isp1704 is power supply driver and export data via power 
> > supply (sysfs) interface. It is not regulator but charger driver.
> 
> well it does not charge the battery directly, but just provides a
> power line with 5 Volt and a specified amount of current to the
> system, doesn't it?
> 
> From my POV this is a candiate for the regulator framework:
> 
> https://www.kernel.org/doc/Documentation/power/regulator/overview.txt

Yes I think we should be able handle that rail with the
regulator framework.

Regards,

Tony

Re: [PATCH 4/4] RX-51: Add platform function and data for bq24150a charger

[Pavel Machek]

Hi!

> > No, isp1704 is power supply driver and export data via power 
> > supply (sysfs) interface. It is not regulator but charger driver.
> 
> well it does not charge the battery directly, but just provides a
> power line with 5 Volt and a specified amount of current to the
> system, doesn't it?

I don't want to talk about isp1704, but...

LiION charger is just something that provides 4.2V power line with
C/10 current limitation...

(IOW line between regulators and chargers is very very thin, if it
even exists).

									Pavel

            (who did use laboratory power supply as emergency battery charger)
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[PATCH 4/4] RX-51: Add platform function and data for bq24150a charger

[Pavel Machek]

Hi!

> > No, isp1704 is power supply driver and export data via power 
> > supply (sysfs) interface. It is not regulator but charger driver.
> 
> well it does not charge the battery directly, but just provides a
> power line with 5 Volt and a specified amount of current to the
> system, doesn't it?

I don't want to talk about isp1704, but...

LiION charger is just something that provides 4.2V power line with
C/10 current limitation...

(IOW line between regulators and chargers is very very thin, if it
even exists).

									Pavel

            (who did use laboratory power supply as emergency battery charger)
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH 4/4] RX-51: Add platform function and data for bq24150a charger

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 1674 bytes --]

On Monday 23 September 2013 22:47:15 Sebastian Reichel wrote:
> On Mon, Sep 23, 2013 at 10:06:46PM +0200, Pali Rohár wrote:
> > On Monday 23 September 2013 22:00:09 Sebastian Reichel wrote:
> > > On Mon, Sep 23, 2013 at 09:16:18PM +0200, Pali Rohár wrote:
> > > > It is not as simple as it looks. This is reason why I
> > > > submited this patch long time after I submited bq2415x
> > > > driver.
> > > > 
> > > > Problem is that for rx51 is needed specific function
> > > > which connect to two drivers (bq2415x and isp1704) plus
> > > > it call specific rx51 board functions.
> > > > 
> > > > Something which cannot be in DT (unless DT support C/ASM
> > > > code).
> > > 
> > > mh could isp1704 driver expose the data via the regulator
> > > framework?
> > 
> > No, isp1704 is power supply driver and export data via power
> > supply (sysfs) interface. It is not regulator but charger
> > driver.
> 
> well it does not charge the battery directly, but just
> provides a power line with 5 Volt and a specified amount of
> current to the system, doesn't it?
> 

No, isp1704 driver is doing fastcharger detection (and then 
export charger type via sysfs power supply) based on musb usb 
events.

Real charging (enabling/disabling and setting properties) is done 
by bq24150a chip which has own power driver bq2415x_charger.

As already wrote this is not simple and this is reason why I sent 
board data and functions only now...

> From my POV this is a candiate for the regulator framework:
> 
> https://www.kernel.org/doc/Documentation/power/regulator/overv
> iew.txt
> 
> -- Sebastian

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[PATCH 4/4] RX-51: Add platform function and data for bq24150a charger

[Pali Rohár]

On Monday 23 September 2013 22:47:15 Sebastian Reichel wrote:
> On Mon, Sep 23, 2013 at 10:06:46PM +0200, Pali Roh?r wrote:
> > On Monday 23 September 2013 22:00:09 Sebastian Reichel wrote:
> > > On Mon, Sep 23, 2013 at 09:16:18PM +0200, Pali Roh?r wrote:
> > > > It is not as simple as it looks. This is reason why I
> > > > submited this patch long time after I submited bq2415x
> > > > driver.
> > > > 
> > > > Problem is that for rx51 is needed specific function
> > > > which connect to two drivers (bq2415x and isp1704) plus
> > > > it call specific rx51 board functions.
> > > > 
> > > > Something which cannot be in DT (unless DT support C/ASM
> > > > code).
> > > 
> > > mh could isp1704 driver expose the data via the regulator
> > > framework?
> > 
> > No, isp1704 is power supply driver and export data via power
> > supply (sysfs) interface. It is not regulator but charger
> > driver.
> 
> well it does not charge the battery directly, but just
> provides a power line with 5 Volt and a specified amount of
> current to the system, doesn't it?
> 

No, isp1704 driver is doing fastcharger detection (and then 
export charger type via sysfs power supply) based on musb usb 
events.

Real charging (enabling/disabling and setting properties) is done 
by bq24150a chip which has own power driver bq2415x_charger.

As already wrote this is not simple and this is reason why I sent 
board data and functions only now...

> From my POV this is a candiate for the regulator framework:
> 
> https://www.kernel.org/doc/Documentation/power/regulator/overv
> iew.txt
> 
> -- Sebastian

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130924/23254e9e/attachment.sig>

Re: [PATCH 4/4] RX-51: Add platform function and data for bq24150a charger

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 989 bytes --]

Hi,

On Tue, Sep 24, 2013 at 07:05:47PM +0200, Pali Rohár wrote:
> No, isp1704 driver is doing fastcharger detection (and then 
> export charger type via sysfs power supply) based on musb usb 
> events.
> 
> Real charging (enabling/disabling and setting properties) is done 
> by bq24150a chip which has own power driver bq2415x_charger.
> 
> As already wrote this is not simple and this is reason why I sent 
> board data and functions only now...

Yes, I'm aware of this. Technically the isp1704 does not provide the
5 volt line, but for the system as a whole that fact does not really
matter.

The isp1704 can provide its functionality via the regulator API
as a simple regulator device. It provides information about the
power "it can supply".

The bq24150a on the other hand can just use the regulator via the
consumer interface.

The regulator framework provides capabilities for events:
"Regulators can notify consumers of external events"

-- Sebastian

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[PATCH 4/4] RX-51: Add platform function and data for bq24150a charger

[Sebastian Reichel]

Hi,

On Tue, Sep 24, 2013 at 07:05:47PM +0200, Pali Roh?r wrote:
> No, isp1704 driver is doing fastcharger detection (and then 
> export charger type via sysfs power supply) based on musb usb 
> events.
> 
> Real charging (enabling/disabling and setting properties) is done 
> by bq24150a chip which has own power driver bq2415x_charger.
> 
> As already wrote this is not simple and this is reason why I sent 
> board data and functions only now...

Yes, I'm aware of this. Technically the isp1704 does not provide the
5 volt line, but for the system as a whole that fact does not really
matter.

The isp1704 can provide its functionality via the regulator API
as a simple regulator device. It provides information about the
power "it can supply".

The bq24150a on the other hand can just use the regulator via the
consumer interface.

The regulator framework provides capabilities for events:
"Regulators can notify consumers of external events"

-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130924/649da08c/attachment.sig>

Re: [PATCH usb 1/2] usb: musb: Add missing ATOMIC_INIT_NOTIFIER_HEAD

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 867 bytes --]

On Wednesday 18 September 2013 19:03:33 Pali Rohár wrote:
> &twl->phy.notifier is not initalized
> 
> Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> 
> diff --git a/drivers/usb/phy/phy-twl4030-usb.c
> b/drivers/usb/phy/phy-twl4030-usb.c index 8f78d2d..efe6155
> 100644
> --- a/drivers/usb/phy/phy-twl4030-usb.c
> +++ b/drivers/usb/phy/phy-twl4030-usb.c
> @@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct
> platform_device *pdev) if (device_create_file(&pdev->dev,
> &dev_attr_vbus)) dev_warn(&pdev->dev, "could not create sysfs
> file\n");
> 
> +	ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
> +
>  	/* Our job is to use irqs and status from the power module
>  	 * to keep the transceiver disabled when nothing's
> connected. *

I sent above patch week ago. Did you already included it?

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH usb 1/2] usb: musb: Add missing ATOMIC_INIT_NOTIFIER_HEAD

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 867 bytes --]

On Wednesday 18 September 2013 19:03:33 Pali Rohár wrote:
> &twl->phy.notifier is not initalized
> 
> Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> 
> diff --git a/drivers/usb/phy/phy-twl4030-usb.c
> b/drivers/usb/phy/phy-twl4030-usb.c index 8f78d2d..efe6155
> 100644
> --- a/drivers/usb/phy/phy-twl4030-usb.c
> +++ b/drivers/usb/phy/phy-twl4030-usb.c
> @@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct
> platform_device *pdev) if (device_create_file(&pdev->dev,
> &dev_attr_vbus)) dev_warn(&pdev->dev, "could not create sysfs
> file\n");
> 
> +	ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
> +
>  	/* Our job is to use irqs and status from the power module
>  	 * to keep the transceiver disabled when nothing's
> connected. *

I sent above patch week ago. Did you already included it?

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[PATCH usb 1/2] usb: musb: Add missing ATOMIC_INIT_NOTIFIER_HEAD

[Pali Rohár]

On Wednesday 18 September 2013 19:03:33 Pali Roh?r wrote:
> &twl->phy.notifier is not initalized
> 
> Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>
> 
> diff --git a/drivers/usb/phy/phy-twl4030-usb.c
> b/drivers/usb/phy/phy-twl4030-usb.c index 8f78d2d..efe6155
> 100644
> --- a/drivers/usb/phy/phy-twl4030-usb.c
> +++ b/drivers/usb/phy/phy-twl4030-usb.c
> @@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct
> platform_device *pdev) if (device_create_file(&pdev->dev,
> &dev_attr_vbus)) dev_warn(&pdev->dev, "could not create sysfs
> file\n");
> 
> +	ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
> +
>  	/* Our job is to use irqs and status from the power module
>  	 * to keep the transceiver disabled when nothing's
> connected. *

I sent above patch week ago. Did you already included it?

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130925/e77b7f6a/attachment.sig>

Re: [PATCH usb 1/2] usb: musb: Add missing ATOMIC_INIT_NOTIFIER_HEAD

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 979 bytes --]

Hi,

On Wed, Sep 25, 2013 at 10:17:38AM +0200, Pali Rohár wrote:
> On Wednesday 18 September 2013 19:03:33 Pali Rohár wrote:
> > &twl->phy.notifier is not initalized
> > 
> > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> > 
> > diff --git a/drivers/usb/phy/phy-twl4030-usb.c
> > b/drivers/usb/phy/phy-twl4030-usb.c index 8f78d2d..efe6155
> > 100644
> > --- a/drivers/usb/phy/phy-twl4030-usb.c
> > +++ b/drivers/usb/phy/phy-twl4030-usb.c
> > @@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct
> > platform_device *pdev) if (device_create_file(&pdev->dev,
> > &dev_attr_vbus)) dev_warn(&pdev->dev, "could not create sysfs
> > file\n");
> > 
> > +	ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
> > +
> >  	/* Our job is to use irqs and status from the power module
> >  	 * to keep the transceiver disabled when nothing's
> > connected. *
> 
> I sent above patch week ago. Did you already included it?

look at my testing branch.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH usb 1/2] usb: musb: Add missing ATOMIC_INIT_NOTIFIER_HEAD

[Felipe Balbi]

[-- Attachment #1.1: Type: text/plain, Size: 979 bytes --]

Hi,

On Wed, Sep 25, 2013 at 10:17:38AM +0200, Pali Rohár wrote:
> On Wednesday 18 September 2013 19:03:33 Pali Rohár wrote:
> > &twl->phy.notifier is not initalized
> > 
> > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> > 
> > diff --git a/drivers/usb/phy/phy-twl4030-usb.c
> > b/drivers/usb/phy/phy-twl4030-usb.c index 8f78d2d..efe6155
> > 100644
> > --- a/drivers/usb/phy/phy-twl4030-usb.c
> > +++ b/drivers/usb/phy/phy-twl4030-usb.c
> > @@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct
> > platform_device *pdev) if (device_create_file(&pdev->dev,
> > &dev_attr_vbus)) dev_warn(&pdev->dev, "could not create sysfs
> > file\n");
> > 
> > +	ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
> > +
> >  	/* Our job is to use irqs and status from the power module
> >  	 * to keep the transceiver disabled when nothing's
> > connected. *
> 
> I sent above patch week ago. Did you already included it?

look at my testing branch.

-- 
balbi

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH usb 1/2] usb: musb: Add missing ATOMIC_INIT_NOTIFIER_HEAD

[Felipe Balbi]

Hi,

On Wed, Sep 25, 2013 at 10:17:38AM +0200, Pali Roh?r wrote:
> On Wednesday 18 September 2013 19:03:33 Pali Roh?r wrote:
> > &twl->phy.notifier is not initalized
> > 
> > Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>
> > 
> > diff --git a/drivers/usb/phy/phy-twl4030-usb.c
> > b/drivers/usb/phy/phy-twl4030-usb.c index 8f78d2d..efe6155
> > 100644
> > --- a/drivers/usb/phy/phy-twl4030-usb.c
> > +++ b/drivers/usb/phy/phy-twl4030-usb.c
> > @@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct
> > platform_device *pdev) if (device_create_file(&pdev->dev,
> > &dev_attr_vbus)) dev_warn(&pdev->dev, "could not create sysfs
> > file\n");
> > 
> > +	ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
> > +
> >  	/* Our job is to use irqs and status from the power module
> >  	 * to keep the transceiver disabled when nothing's
> > connected. *
> 
> I sent above patch week ago. Did you already included it?

look at my testing branch.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130925/4582c849/attachment.sig>

Re: [PATCH usb 1/2] usb: musb: Add missing ATOMIC_INIT_NOTIFIER_HEAD

[Pavel Machek]

On Wed 2013-09-25 15:33:33, Felipe Balbi wrote:
> Hi,
> 
> On Wed, Sep 25, 2013 at 10:17:38AM +0200, Pali Rohár wrote:
> > On Wednesday 18 September 2013 19:03:33 Pali Rohár wrote:
> > > &twl->phy.notifier is not initalized
> > > 
> > > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> > > 
> > > diff --git a/drivers/usb/phy/phy-twl4030-usb.c
> > > b/drivers/usb/phy/phy-twl4030-usb.c index 8f78d2d..efe6155
> > > 100644
> > > --- a/drivers/usb/phy/phy-twl4030-usb.c
> > > +++ b/drivers/usb/phy/phy-twl4030-usb.c
> > > @@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct
> > > platform_device *pdev) if (device_create_file(&pdev->dev,
> > > &dev_attr_vbus)) dev_warn(&pdev->dev, "could not create sysfs
> > > file\n");
> > > 
> > > +	ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
> > > +
> > >  	/* Our job is to use irqs and status from the power module
> > >  	 * to keep the transceiver disabled when nothing's
> > > connected. *
> > 
> > I sent above patch week ago. Did you already included it?
> 
> look at my testing branch.

Felipe prefers you to go MAINTAINERS file for

git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git

entry. After few clicks, you'll find out your two patches in 

https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/log/?h=testing

. So yes, it seems that after 10+ flames Felipe was _not_ lazy to
send, "Thanks for a patch" mail was too much work.

Apparently, we'll need  Documentation/HowToBeGoodMaintainer file...

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[PATCH usb 1/2] usb: musb: Add missing ATOMIC_INIT_NOTIFIER_HEAD

[Pavel Machek]

On Wed 2013-09-25 15:33:33, Felipe Balbi wrote:
> Hi,
> 
> On Wed, Sep 25, 2013 at 10:17:38AM +0200, Pali Roh?r wrote:
> > On Wednesday 18 September 2013 19:03:33 Pali Roh?r wrote:
> > > &twl->phy.notifier is not initalized
> > > 
> > > Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>
> > > 
> > > diff --git a/drivers/usb/phy/phy-twl4030-usb.c
> > > b/drivers/usb/phy/phy-twl4030-usb.c index 8f78d2d..efe6155
> > > 100644
> > > --- a/drivers/usb/phy/phy-twl4030-usb.c
> > > +++ b/drivers/usb/phy/phy-twl4030-usb.c
> > > @@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct
> > > platform_device *pdev) if (device_create_file(&pdev->dev,
> > > &dev_attr_vbus)) dev_warn(&pdev->dev, "could not create sysfs
> > > file\n");
> > > 
> > > +	ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
> > > +
> > >  	/* Our job is to use irqs and status from the power module
> > >  	 * to keep the transceiver disabled when nothing's
> > > connected. *
> > 
> > I sent above patch week ago. Did you already included it?
> 
> look at my testing branch.

Felipe prefers you to go MAINTAINERS file for

git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git

entry. After few clicks, you'll find out your two patches in 

https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/log/?h=testing

. So yes, it seems that after 10+ flames Felipe was _not_ lazy to
send, "Thanks for a patch" mail was too much work.

Apparently, we'll need  Documentation/HowToBeGoodMaintainer file...

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH usb 1/2] usb: musb: Add missing ATOMIC_INIT_NOTIFIER_HEAD

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1875 bytes --]

Hi,

On Thu, Sep 26, 2013 at 02:00:59AM +0200, Pavel Machek wrote:
> > On Wed, Sep 25, 2013 at 10:17:38AM +0200, Pali Rohár wrote:
> > > On Wednesday 18 September 2013 19:03:33 Pali Rohár wrote:
> > > > &twl->phy.notifier is not initalized
> > > > 
> > > > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> > > > 
> > > > diff --git a/drivers/usb/phy/phy-twl4030-usb.c
> > > > b/drivers/usb/phy/phy-twl4030-usb.c index 8f78d2d..efe6155
> > > > 100644
> > > > --- a/drivers/usb/phy/phy-twl4030-usb.c
> > > > +++ b/drivers/usb/phy/phy-twl4030-usb.c
> > > > @@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct
> > > > platform_device *pdev) if (device_create_file(&pdev->dev,
> > > > &dev_attr_vbus)) dev_warn(&pdev->dev, "could not create sysfs
> > > > file\n");
> > > > 
> > > > +	ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
> > > > +
> > > >  	/* Our job is to use irqs and status from the power module
> > > >  	 * to keep the transceiver disabled when nothing's
> > > > connected. *
> > > 
> > > I sent above patch week ago. Did you already included it?
> > 
> > look at my testing branch.
> 
> Felipe prefers you to go MAINTAINERS file for
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
> 
> entry. After few clicks, you'll find out your two patches in 
> 
> https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/log/?h=testing
> 
> . So yes, it seems that after 10+ flames Felipe was _not_ lazy to
> send, "Thanks for a patch" mail was too much work.
> 
> Apparently, we'll need  Documentation/HowToBeGoodMaintainer file...

I only send my automated emails after properly testing them. They sit in
'testing' for as long as necessary. After all the test is done, they'll
be moved to 'next' at which point you get your email notification and
they reach linux-next for the next day.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH usb 1/2] usb: musb: Add missing ATOMIC_INIT_NOTIFIER_HEAD

[Felipe Balbi]

[-- Attachment #1.1: Type: text/plain, Size: 1875 bytes --]

Hi,

On Thu, Sep 26, 2013 at 02:00:59AM +0200, Pavel Machek wrote:
> > On Wed, Sep 25, 2013 at 10:17:38AM +0200, Pali Rohár wrote:
> > > On Wednesday 18 September 2013 19:03:33 Pali Rohár wrote:
> > > > &twl->phy.notifier is not initalized
> > > > 
> > > > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> > > > 
> > > > diff --git a/drivers/usb/phy/phy-twl4030-usb.c
> > > > b/drivers/usb/phy/phy-twl4030-usb.c index 8f78d2d..efe6155
> > > > 100644
> > > > --- a/drivers/usb/phy/phy-twl4030-usb.c
> > > > +++ b/drivers/usb/phy/phy-twl4030-usb.c
> > > > @@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct
> > > > platform_device *pdev) if (device_create_file(&pdev->dev,
> > > > &dev_attr_vbus)) dev_warn(&pdev->dev, "could not create sysfs
> > > > file\n");
> > > > 
> > > > +	ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
> > > > +
> > > >  	/* Our job is to use irqs and status from the power module
> > > >  	 * to keep the transceiver disabled when nothing's
> > > > connected. *
> > > 
> > > I sent above patch week ago. Did you already included it?
> > 
> > look at my testing branch.
> 
> Felipe prefers you to go MAINTAINERS file for
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
> 
> entry. After few clicks, you'll find out your two patches in 
> 
> https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/log/?h=testing
> 
> . So yes, it seems that after 10+ flames Felipe was _not_ lazy to
> send, "Thanks for a patch" mail was too much work.
> 
> Apparently, we'll need  Documentation/HowToBeGoodMaintainer file...

I only send my automated emails after properly testing them. They sit in
'testing' for as long as necessary. After all the test is done, they'll
be moved to 'next' at which point you get your email notification and
they reach linux-next for the next day.

-- 
balbi

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH usb 1/2] usb: musb: Add missing ATOMIC_INIT_NOTIFIER_HEAD

[Felipe Balbi]

Hi,

On Thu, Sep 26, 2013 at 02:00:59AM +0200, Pavel Machek wrote:
> > On Wed, Sep 25, 2013 at 10:17:38AM +0200, Pali Roh?r wrote:
> > > On Wednesday 18 September 2013 19:03:33 Pali Roh?r wrote:
> > > > &twl->phy.notifier is not initalized
> > > > 
> > > > Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>
> > > > 
> > > > diff --git a/drivers/usb/phy/phy-twl4030-usb.c
> > > > b/drivers/usb/phy/phy-twl4030-usb.c index 8f78d2d..efe6155
> > > > 100644
> > > > --- a/drivers/usb/phy/phy-twl4030-usb.c
> > > > +++ b/drivers/usb/phy/phy-twl4030-usb.c
> > > > @@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct
> > > > platform_device *pdev) if (device_create_file(&pdev->dev,
> > > > &dev_attr_vbus)) dev_warn(&pdev->dev, "could not create sysfs
> > > > file\n");
> > > > 
> > > > +	ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
> > > > +
> > > >  	/* Our job is to use irqs and status from the power module
> > > >  	 * to keep the transceiver disabled when nothing's
> > > > connected. *
> > > 
> > > I sent above patch week ago. Did you already included it?
> > 
> > look at my testing branch.
> 
> Felipe prefers you to go MAINTAINERS file for
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
> 
> entry. After few clicks, you'll find out your two patches in 
> 
> https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/log/?h=testing
> 
> . So yes, it seems that after 10+ flames Felipe was _not_ lazy to
> send, "Thanks for a patch" mail was too much work.
> 
> Apparently, we'll need  Documentation/HowToBeGoodMaintainer file...

I only send my automated emails after properly testing them. They sit in
'testing' for as long as necessary. After all the test is done, they'll
be moved to 'next' at which point you get your email notification and
they reach linux-next for the next day.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131001/529e96bf/attachment-0001.sig>

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

[Anton Vorontsov]

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

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

[Anton Vorontsov]

On Sun, Sep 08, 2013 at 10:50:37AM +0200, Pali Roh?r wrote:
> * omap musb driver does not report USB_EVENT_ENUMERATED event anymore
> * omap musb driver reporting USB_EVENT_VBUS when charger is connected
> * read last event from phy->last_event (instead from ulpi register)
> * do not call wall charger detection more times
> 
> Signed-off-by: Pali Roh?r <pali.rohar@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

[PATCH v2 0/3] Add support for charging battery in Nokia RX-51

[Pali Rohár]

This patch series finally bringing support for charging battery on
Nokia N900 (RX-51) without any proprietary Nokia bits in userspace.

I removed hook function from bq2415x_charger driver and replaced it
by Jenny TC power_supply notifier code. This simplify usage of
bq2415x driver and also allow adding DT support in future because
driver does not need board specific function anymore (only static data).

I tested this series with linux 3.12-rc5 on Nokia N900.

Pali Rohár (3):
  power_supply: Add power_supply notifier
  bq2415x_charger: Use power_supply notifier for automode
  RX-51: Add platform data for bq24150a charger

 arch/arm/mach-omap2/board-rx51-peripherals.c |   17 +++++-
 drivers/power/bq2415x_charger.c              |   77 ++++++++++++++++++++------
 drivers/power/power_supply_core.c            |   17 ++++++
 include/linux/power/bq2415x_charger.h        |   48 ++--------------
 include/linux/power_supply.h                 |   10 ++++
 5 files changed, 108 insertions(+), 61 deletions(-)

-- 
1.7.9.5

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

[Pali Rohár]

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.tc@intel.com>
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
---
 drivers/power/power_supply_core.c |   17 +++++++++++++++++
 include/linux/power_supply.h      |   10 ++++++++++
 2 files changed, 27 insertions(+)

diff --git a/drivers/power/power_supply_core.c b/drivers/power/power_supply_core.c
index 00e6672..08bce22 100644
--- a/drivers/power/power_supply_core.c
+++ b/drivers/power/power_supply_core.c
@@ -24,6 +24,9 @@
 struct class *power_supply_class;
 EXPORT_SYMBOL_GPL(power_supply_class);
 
+ATOMIC_NOTIFIER_HEAD(power_supply_notifier);
+EXPORT_SYMBOL_GPL(power_supply_notifier);
+
 static struct device_type power_supply_dev_type;
 
 static bool __power_supply_is_supplied_by(struct power_supply *supplier,
@@ -80,6 +83,8 @@ static void power_supply_changed_work(struct work_struct *work)
 		class_for_each_device(power_supply_class, NULL, psy,
 				      __power_supply_changed_work);
 		power_supply_update_leds(psy);
+		atomic_notifier_call_chain(&power_supply_notifier,
+				PSY_EVENT_PROP_CHANGED, psy);
 		kobject_uevent(&psy->dev->kobj, KOBJ_CHANGE);
 		spin_lock_irqsave(&psy->changed_lock, flags);
 	}
@@ -347,6 +352,18 @@ static void power_supply_dev_release(struct device *dev)
 	kfree(dev);
 }
 
+int power_supply_reg_notifier(struct notifier_block *nb)
+{
+	return atomic_notifier_chain_register(&power_supply_notifier, nb);
+}
+EXPORT_SYMBOL_GPL(power_supply_reg_notifier);
+
+void power_supply_unreg_notifier(struct notifier_block *nb)
+{
+	atomic_notifier_chain_unregister(&power_supply_notifier, nb);
+}
+EXPORT_SYMBOL_GPL(power_supply_unreg_notifier);
+
 #ifdef CONFIG_THERMAL
 static int power_supply_read_temp(struct thermal_zone_device *tzd,
 		unsigned long *temp)
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index 5c26006..c6f52c0 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -158,6 +158,13 @@ enum power_supply_type {
 	POWER_SUPPLY_TYPE_USB_ACA,	/* Accessory Charger Adapters */
 };
 
+enum power_supply_notifier_events {
+	PSY_EVENT_NONE,
+	PSY_EVENT_PROP_CHANGED,
+	PSY_EVENT_BATTERY,
+	PSY_EVENT_CABLE,
+};
+
 union power_supply_propval {
 	int intval;
 	const char *strval;
@@ -235,6 +242,9 @@ struct power_supply_info {
 	int use_for_apm;
 };
 
+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);
 extern void power_supply_changed(struct power_supply *psy);
 extern int power_supply_am_i_supplied(struct power_supply *psy);
-- 
1.7.9.5

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

[Pali Rohár]

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.rohar@gmail.com>
---
 drivers/power/bq2415x_charger.c       |   77 +++++++++++++++++++++++++--------
 include/linux/power/bq2415x_charger.h |   48 +++-----------------
 2 files changed, 65 insertions(+), 60 deletions(-)

diff --git a/drivers/power/bq2415x_charger.c b/drivers/power/bq2415x_charger.c
index 0727f92..d89583d 100644
--- a/drivers/power/bq2415x_charger.c
+++ b/drivers/power/bq2415x_charger.c
@@ -1,7 +1,7 @@
 /*
  * bq2415x charger driver
  *
- * Copyright (C) 2011-2012  Pali Rohár <pali.rohar@gmail.com>
+ * Copyright (C) 2011-2013  Pali Rohár <pali.rohar@gmail.com>
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
@@ -170,6 +170,7 @@ struct bq2415x_device {
 	struct bq2415x_platform_data init_data;
 	struct power_supply charger;
 	struct delayed_work work;
+	struct notifier_block nb;
 	enum bq2415x_mode reported_mode;/* mode reported by hook function */
 	enum bq2415x_mode mode;		/* current configured mode */
 	enum bq2415x_chip chip;
@@ -791,24 +792,53 @@ static int bq2415x_set_mode(struct bq2415x_device *bq, enum bq2415x_mode mode)
 
 }
 
-/* hook function called by other driver which set reported mode */
-static void bq2415x_hook_function(enum bq2415x_mode mode, void *data)
+static int bq2415x_notifier_call(struct notifier_block *nb,
+		unsigned long val, void *v)
 {
-	struct bq2415x_device *bq = data;
+	struct bq2415x_device *bq =
+		container_of(nb, struct bq2415x_device, nb);
+	struct power_supply *psy = v;
+	enum bq2415x_mode mode;
+	union power_supply_propval prop;
+	int ret;
+	int mA;
 
-	if (!bq)
-		return;
+	if (val != PSY_EVENT_PROP_CHANGED)
+		return NOTIFY_OK;
+
+	if (strcmp(psy->name, bq->init_data.notify_device) != 0)
+		return NOTIFY_OK;
+
+	dev_dbg(bq->dev, "notifier call was called\n");
+
+	ret = psy->get_property(psy, POWER_SUPPLY_PROP_CURRENT_MAX, &prop);
+	if (ret != 0)
+		return NOTIFY_OK;
+
+	mA = prop.intval;
+
+	if (mA == 0)
+		mode = BQ2415X_MODE_OFF;
+	else if (mA < 500)
+		mode = BQ2415X_MODE_NONE;
+	else if (mA < 1800)
+		mode = BQ2415X_MODE_HOST_CHARGER;
+	else
+		mode = BQ2415X_MODE_DEDICATED_CHARGER;
+
+	if (bq->reported_mode == mode)
+		return NOTIFY_OK;
 
-	dev_dbg(bq->dev, "hook function was called\n");
 	bq->reported_mode = mode;
 
 	/* if automode is not enabled do not tell about reported_mode */
 	if (bq->automode < 1)
-		return;
+		return NOTIFY_OK;
 
 	sysfs_notify(&bq->charger.dev->kobj, NULL, "reported_mode");
 	bq2415x_set_mode(bq, bq->reported_mode);
 
+	return NOTIFY_OK;
 }
 
 /**** timer functions ****/
@@ -1508,6 +1538,7 @@ static int bq2415x_probe(struct i2c_client *client,
 	int num;
 	char *name;
 	struct bq2415x_device *bq;
+	struct power_supply *psy;
 
 	if (!client->dev.platform_data) {
 		dev_err(&client->dev, "platform data not set\n");
@@ -1569,16 +1600,27 @@ static int bq2415x_probe(struct i2c_client *client,
 		goto error_4;
 	}
 
-	if (bq->init_data.set_mode_hook) {
-		if (bq->init_data.set_mode_hook(
-				bq2415x_hook_function, bq)) {
-			bq->automode = 1;
+	if (bq->init_data.notify_device) {
+		bq->nb.notifier_call = bq2415x_notifier_call;
+		ret = power_supply_reg_notifier(&bq->nb);
+		if (ret) {
+			dev_err(bq->dev, "failed to reg notifier: %d\n", ret);
+			goto error_5;
+		}
+		psy = power_supply_get_by_name(bq->init_data.notify_device);
+		if (psy) {
+			/* Query for initial reported_mode and set it */
+			bq2415x_notifier_call(&bq->nb,
+					PSY_EVENT_PROP_CHANGED, psy);
 			bq2415x_set_mode(bq, bq->reported_mode);
-			dev_info(bq->dev, "automode enabled\n");
 		} else {
-			bq->automode = -1;
-			dev_info(bq->dev, "automode failed\n");
+			dev_info(bq->dev, "notifier power supply device (%s) "
+				"for automode is not registred yet... "
+				"automode will not work without that device\n",
+				bq->init_data.notify_device);
 		}
+		bq->automode = 1;
+		dev_info(bq->dev, "automode enabled\n");
 	} else {
 		bq->automode = -1;
 		dev_info(bq->dev, "automode not supported\n");
@@ -1590,6 +1632,7 @@ static int bq2415x_probe(struct i2c_client *client,
 	dev_info(bq->dev, "driver registered\n");
 	return 0;
 
+error_5:
 error_4:
 	bq2415x_sysfs_exit(bq);
 error_3:
@@ -1610,8 +1653,8 @@ static int bq2415x_remove(struct i2c_client *client)
 {
 	struct bq2415x_device *bq = i2c_get_clientdata(client);
 
-	if (bq->init_data.set_mode_hook)
-		bq->init_data.set_mode_hook(NULL, NULL);
+	if (bq->init_data.notify_device)
+		power_supply_unreg_notifier(&bq->nb);
 
 	bq2415x_sysfs_exit(bq);
 	bq2415x_power_supply_exit(bq);
diff --git a/include/linux/power/bq2415x_charger.h b/include/linux/power/bq2415x_charger.h
index 8dcc0f4..50762af 100644
--- a/include/linux/power/bq2415x_charger.h
+++ b/include/linux/power/bq2415x_charger.h
@@ -1,7 +1,7 @@
 /*
  * bq2415x charger driver
  *
- * Copyright (C) 2011-2012  Pali Rohár <pali.rohar@gmail.com>
+ * Copyright (C) 2011-2013  Pali Rohár <pali.rohar@gmail.com>
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
@@ -31,46 +31,9 @@
  * termination current. It it is less or equal to zero, configuring charge
  * and termination current will not be possible.
  *
- * Function set_mode_hook is needed for automode (setting correct current
- * limit when charger is connected/disconnected or setting boost mode).
- * When is NULL, automode function is disabled. When is not NULL, it must
- * have this prototype:
- *
- *    int (*set_mode_hook)(
- *      void (*hook)(enum bq2415x_mode mode, void *data),
- *      void *data)
- *
- * hook is hook function (see below) and data is pointer to driver private
- * data
- *
- * bq2415x driver will call it as:
- *
- *    platform_data->set_mode_hook(bq2415x_hook_function, bq2415x_device);
- *
- * Board/platform function set_mode_hook return non zero value when hook
- * function was successful registered. Platform code should call that hook
- * function (which get from pointer, with data) every time when charger
- * was connected/disconnected or require to enable boost mode. bq2415x
- * driver then will set correct current limit, enable/disable charger or
- * boost mode.
- *
- * Hook function has this prototype:
- *
- *    void hook(enum bq2415x_mode mode, void *data);
- *
- * mode is bq2415x mode (charger or boost)
- * data is pointer to driver private data (which get from
- * set_charger_type_hook)
- *
- * When bq driver is being unloaded, it call function:
- *
- *    platform_data->set_mode_hook(NULL, NULL);
- *
- * (hook function and driver private data are NULL)
- *
- * After that board/platform code must not call driver hook function! It
- * is possible that pointer to hook function will not be valid and calling
- * will cause undefined result.
+ * For automode support is needed to provide name of power supply device
+ * in value notify_device. Device driver must immediately report property
+ * POWER_SUPPLY_PROP_CURRENT_MAX when current changed.
  */
 
 /* Supported modes with maximal current limit */
@@ -89,8 +52,7 @@ struct bq2415x_platform_data {
 	int charge_current;		/* mA */
 	int termination_current;	/* mA */
 	int resistor_sense;		/* m ohm */
-	int (*set_mode_hook)(void (*hook)(enum bq2415x_mode mode, void *data),
-			     void *data);
+	const char *notify_device;	/* name */
 };
 
 #endif
-- 
1.7.9.5

[PATCH v2 3/3] RX-51: Add platform data for bq24150a charger

[Pali Rohár]

This patch will register bq24150a charger in RX-51 board data.

So finally charging battery on Nokia N900 (RX-51) working
automatically without any proprietary Nokia bits in userspace.

Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
---
 arch/arm/mach-omap2/board-rx51-peripherals.c |   17 ++++++++++++++++-
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 70fcaff..95e6638 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -25,6 +25,7 @@
 #include <linux/gpio_keys.h>
 #include <linux/mmc/host.h>
 #include <linux/power/isp1704_charger.h>
+#include <linux/power/bq2415x_charger.h>
 #include <linux/platform_data/spi-omap2-mcspi.h>
 #include <linux/platform_data/mtd-onenand-omap2.h>
 #include <linux/hsi/hsi.h>
@@ -1275,6 +1276,16 @@ static struct aic3x_pdata rx51_aic3x_data2 = {
 	.gpio_reset = 60,
 };
 
+static struct bq2415x_platform_data rx51_bq24150a_platform_data = {
+	.current_limit = 100,			/* mA */
+	.weak_battery_voltage = 3400,		/* mV */
+	.battery_regulation_voltage = 4200,	/* mV */
+	.charge_current = 650,			/* mA */
+	.termination_current = 100,		/* mA */
+	.resistor_sense = 68,			/* m ohm */
+	.notify_device = "isp1704",
+};
+
 static struct i2c_board_info __initdata rx51_peripherals_i2c_board_info_2[] = {
 	{
 		I2C_BOARD_INFO("tlv320aic3x", 0x18),
@@ -1302,7 +1313,11 @@ static struct i2c_board_info __initdata rx51_peripherals_i2c_board_info_2[] = {
 	{
 		I2C_BOARD_INFO("tpa6130a2", 0x60),
 		.platform_data = &rx51_tpa6130a2_data,
-	}
+	},
+	{
+		I2C_BOARD_INFO("bq24150a", 0x6b),
+		.platform_data = &rx51_bq24150a_platform_data,
+	},
 };
 
 static struct i2c_board_info __initdata rx51_peripherals_i2c_board_info_3[] = {
-- 
1.7.9.5

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

[Pavel Machek]

On Tue 2013-11-19 11:18:03, 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.tc@intel.com>
> Signed-off-by: Pali Rohár <pali.rohar@gmail.com>

Reviewed-by: Pavel Machek <pavel@ucw.cz>

> +extern struct atomic_notifier_head    power_supply_notifier;

You may want to delete some spaces here.

Thanks,
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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

[Pali Rohár]

On Tuesday 19 November 2013 14:10:06 Pavel Machek wrote:
> On Tue 2013-11-19 11:18:03, 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.tc@intel.com>
> > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> 
> Reviewed-by: Pavel Machek <pavel@ucw.cz>
> 
> > +extern struct atomic_notifier_head   
> > power_supply_notifier;
> 
> You may want to delete some spaces here.
> 
> Thanks,
> 								Pavel

Ok, note that this patch I copied from: 
https://lkml.org/lkml/2013/9/23/181

-- 
Pali Rohár
pali.rohar@gmail.com

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

[Pavel Machek]

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.rohar@gmail.com>

Reviewed-by: Pavel Machek <pavel@ucw.cz>
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH v2 3/3] RX-51: Add platform data for bq24150a charger

[Pavel Machek]

On Tue 2013-11-19 11:18:05, Pali Rohár wrote:
> This patch will register bq24150a charger in RX-51 board data.
> 
> So finally charging battery on Nokia N900 (RX-51) working
> automatically without any proprietary Nokia bits in userspace.
> 
> Signed-off-by: Pali Rohár <pali.rohar@gmail.com>

Reviewed-by: Pavel Machek <pavel@ucw.cz>

									Pavel
BTW, current code says:

That seems to limit charging voltage to 3.9V, with comment saying
4.11V... which means battery will not be charged fully. does it make
sense to raise limit to 4.11V here?

Aha, and actually will not 4.2V requested by
rx51_bq24150a_platform_data trigger -EINVAL?

/* set battery regulation voltage in mV */
static int bq2415x_set_battery_regulation_voltage(struct
bq2415x_device *bq,
                                                  int mV)
{
        int val = (mV/10 - 350) / 2;

        if (val < 0)
                val = 0;
        else if (val > 94) /* FIXME: Max is 94 or 122 ? Set max value
                ? */
                return -EINVAL;

        return bq2415x_i2c_write_mask(bq, BQ2415X_REG_VOLTAGE, val,
                        BQ2415X_MASK_VO, BQ2415X_SHIFT_VO);
}

> --- a/arch/arm/mach-omap2/board-rx51-peripherals.c
> +++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
> @@ -1275,6 +1276,16 @@ static struct aic3x_pdata rx51_aic3x_data2 = {
>  	.gpio_reset = 60,
>  };
>  
> +static struct bq2415x_platform_data rx51_bq24150a_platform_data = {
> +	.current_limit = 100,			/* mA */
> +	.weak_battery_voltage = 3400,		/* mV */
> +	.battery_regulation_voltage = 4200,	/* mV */
> +	.charge_current = 650,			/* mA */
> +	.termination_current = 100,		/* mA */
> +	.resistor_sense = 68,			/* m ohm */
> +	.notify_device = "isp1704",
> +};
> +
>  static struct i2c_board_info __initdata rx51_peripherals_i2c_board_info_2[] = {
>  	{
>  		I2C_BOARD_INFO("tlv320aic3x", 0x18),

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH v2 0/3] Add support for charging battery in Nokia RX-51

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 653 bytes --]

Hi Pali,

On Tue, Nov 19, 2013 at 11:18:02AM +0100, Pali Rohár wrote:
> This patch series finally bringing support for charging battery on
> Nokia N900 (RX-51) without any proprietary Nokia bits in userspace.

YAY! :)

> I removed hook function from bq2415x_charger driver and replaced it
> by Jenny TC power_supply notifier code. This simplify usage of
> bq2415x driver and also allow adding DT support in future because
> driver does not need board specific function anymore (only static data).
> 
> I tested this series with linux 3.12-rc5 on Nokia N900.

cool :)

Do you want me to take this up and add DT support?

-- Sebastian

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH v2 0/3] Add support for charging battery in Nokia RX-51

[Tony Lindgren]

* Sebastian Reichel <sre@debian.org> [131119 06:45]:
> Hi Pali,
> 
> On Tue, Nov 19, 2013 at 11:18:02AM +0100, Pali Rohár wrote:
> > This patch series finally bringing support for charging battery on
> > Nokia N900 (RX-51) without any proprietary Nokia bits in userspace.
> 
> YAY! :)
> 
> > I removed hook function from bq2415x_charger driver and replaced it
> > by Jenny TC power_supply notifier code. This simplify usage of
> > bq2415x driver and also allow adding DT support in future because
> > driver does not need board specific function anymore (only static data).
> > 
> > I tested this series with linux 3.12-rc5 on Nokia N900.
> 
> cool :)
> 
> Do you want me to take this up and add DT support?

Great news, yeah let's add this with DT support instead as we're
planning to switch over to DT only booting anyways. The values can be
probably set directly in the charger driver based on the compatible
flag.

Note that we can also still add the I2C devices as needed from
the pdata-quirks.c, but in this case there should not be any need
for it :)

Regards,

Tony

Re: [PATCH v2 0/3] Add support for charging battery in Nokia RX-51

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 866 bytes --]

On Tuesday 19 November 2013 15:44:09 Sebastian Reichel wrote:
> Hi Pali,
> 
> On Tue, Nov 19, 2013 at 11:18:02AM +0100, Pali Rohár wrote:
> > This patch series finally bringing support for charging
> > battery on Nokia N900 (RX-51) without any proprietary Nokia
> > bits in userspace.
> 
> YAY! :)
> 
> > I removed hook function from bq2415x_charger driver and
> > replaced it by Jenny TC power_supply notifier code. This
> > simplify usage of bq2415x driver and also allow adding DT
> > support in future because driver does not need board
> > specific function anymore (only static data).
> > 
> > I tested this series with linux 3.12-rc5 on Nokia N900.
> 
> cool :)
> 
> Do you want me to take this up and add DT support?
> 
> -- Sebastian

Hello, if you have time, can you add DT support code?

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH v2 3/3] RX-51: Add platform data for bq24150a charger

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 1470 bytes --]

On Tuesday 19 November 2013 14:32:13 Pavel Machek wrote:
> On Tue 2013-11-19 11:18:05, Pali Rohár wrote:
> > This patch will register bq24150a charger in RX-51 board
> > data.
> > 
> > So finally charging battery on Nokia N900 (RX-51) working
> > automatically without any proprietary Nokia bits in
> > userspace.
> > 
> > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> 
> Reviewed-by: Pavel Machek <pavel@ucw.cz>
> 
> 									Pavel
> BTW, current code says:
> 
> That seems to limit charging voltage to 3.9V, with comment
> saying 4.11V... which means battery will not be charged
> fully. does it make sense to raise limit to 4.11V here?
> 
> Aha, and actually will not 4.2V requested by
> rx51_bq24150a_platform_data trigger -EINVAL?
> 
> /* set battery regulation voltage in mV */
> static int bq2415x_set_battery_regulation_voltage(struct
> bq2415x_device *bq,
>                                                   int mV)
> {
>         int val = (mV/10 - 350) / 2;
> 
>         if (val < 0)
>                 val = 0;
>         else if (val > 94) /* FIXME: Max is 94 or 122 ? Set
> max value ? */
>                 return -EINVAL;
> 
>         return bq2415x_i2c_write_mask(bq, BQ2415X_REG_VOLTAGE,
> val, BQ2415X_MASK_VO, BQ2415X_SHIFT_VO); }
> 

Above bq2415x_set_battery_regulation_voltage function is updated 
in 3.13, see commit 3ed5cd79b82e9a055e0df3275eeb471ea0f1e2d7.

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 599 bytes --]

Hi,

On Tue, Nov 19, 2013 at 11:18:04AM +0100, 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.

I'm wondering if the watchdog thread should check some values, like
e.g. battery temperature. It should stop charging the battery if
some critical battery temperature threshold is reached.

-- Sebastian

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 756 bytes --]

Hi,

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
>
> [...]

Tested-By: Sebastian Reichel <sre@debian.org>

-- Sebastian

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Michael Trimarchi]

Hi

On Tue, Nov 19, 2013 at 11:18 AM, Pali Rohár <pali.rohar@gmail.com> 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.rohar@gmail.com>
> ---
>  drivers/power/bq2415x_charger.c       |   77 +++++++++++++++++++++++++--------
>  include/linux/power/bq2415x_charger.h |   48 +++-----------------
>  2 files changed, 65 insertions(+), 60 deletions(-)
>
> diff --git a/drivers/power/bq2415x_charger.c b/drivers/power/bq2415x_charger.c
> index 0727f92..d89583d 100644
> --- a/drivers/power/bq2415x_charger.c
> +++ b/drivers/power/bq2415x_charger.c
> @@ -1,7 +1,7 @@
>  /*
>   * bq2415x charger driver
>   *
> - * Copyright (C) 2011-2012  Pali Rohár <pali.rohar@gmail.com>
> + * Copyright (C) 2011-2013  Pali Rohár <pali.rohar@gmail.com>
>   *
>   * This program is free software; you can redistribute it and/or modify
>   * it under the terms of the GNU General Public License as published by
> @@ -170,6 +170,7 @@ struct bq2415x_device {
>         struct bq2415x_platform_data init_data;
>         struct power_supply charger;
>         struct delayed_work work;
> +       struct notifier_block nb;
>         enum bq2415x_mode reported_mode;/* mode reported by hook function */
>         enum bq2415x_mode mode;         /* current configured mode */
>         enum bq2415x_chip chip;
> @@ -791,24 +792,53 @@ static int bq2415x_set_mode(struct bq2415x_device *bq, enum bq2415x_mode mode)
>
>  }
>
> -/* hook function called by other driver which set reported mode */
> -static void bq2415x_hook_function(enum bq2415x_mode mode, void *data)
> +static int bq2415x_notifier_call(struct notifier_block *nb,
> +               unsigned long val, void *v)
>  {
> -       struct bq2415x_device *bq = data;
> +       struct bq2415x_device *bq =
> +               container_of(nb, struct bq2415x_device, nb);
> +       struct power_supply *psy = v;
> +       enum bq2415x_mode mode;
> +       union power_supply_propval prop;
> +       int ret;
> +       int mA;
>
> -       if (!bq)
> -               return;
> +       if (val != PSY_EVENT_PROP_CHANGED)
> +               return NOTIFY_OK;
> +
> +       if (strcmp(psy->name, bq->init_data.notify_device) != 0)
> +               return NOTIFY_OK;
> +
> +       dev_dbg(bq->dev, "notifier call was called\n");
> +
> +       ret = psy->get_property(psy, POWER_SUPPLY_PROP_CURRENT_MAX, &prop);
> +       if (ret != 0)
> +               return NOTIFY_OK;

So you can read this value without any type of synchronization with
the power_supply_core
and sysfs implementation?


Michael

> +
> +       mA = prop.intval;
> +
> +       if (mA == 0)
> +               mode = BQ2415X_MODE_OFF;
> +       else if (mA < 500)
> +               mode = BQ2415X_MODE_NONE;
> +       else if (mA < 1800)
> +               mode = BQ2415X_MODE_HOST_CHARGER;
> +       else
> +               mode = BQ2415X_MODE_DEDICATED_CHARGER;
> +
> +       if (bq->reported_mode == mode)
> +               return NOTIFY_OK;
>
> -       dev_dbg(bq->dev, "hook function was called\n");
>         bq->reported_mode = mode;
>
>         /* if automode is not enabled do not tell about reported_mode */
>         if (bq->automode < 1)
> -               return;
> +               return NOTIFY_OK;
>
>         sysfs_notify(&bq->charger.dev->kobj, NULL, "reported_mode");
>         bq2415x_set_mode(bq, bq->reported_mode);
>
> +       return NOTIFY_OK;
>  }
>
>  /**** timer functions ****/
> @@ -1508,6 +1538,7 @@ static int bq2415x_probe(struct i2c_client *client,
>         int num;
>         char *name;
>         struct bq2415x_device *bq;
> +       struct power_supply *psy;
>
>         if (!client->dev.platform_data) {
>                 dev_err(&client->dev, "platform data not set\n");
> @@ -1569,16 +1600,27 @@ static int bq2415x_probe(struct i2c_client *client,
>                 goto error_4;
>         }
>
> -       if (bq->init_data.set_mode_hook) {
> -               if (bq->init_data.set_mode_hook(
> -                               bq2415x_hook_function, bq)) {
> -                       bq->automode = 1;
> +       if (bq->init_data.notify_device) {
> +               bq->nb.notifier_call = bq2415x_notifier_call;
> +               ret = power_supply_reg_notifier(&bq->nb);
> +               if (ret) {
> +                       dev_err(bq->dev, "failed to reg notifier: %d\n", ret);
> +                       goto error_5;
> +               }
> +               psy = power_supply_get_by_name(bq->init_data.notify_device);
> +               if (psy) {
> +                       /* Query for initial reported_mode and set it */
> +                       bq2415x_notifier_call(&bq->nb,
> +                                       PSY_EVENT_PROP_CHANGED, psy);
>                         bq2415x_set_mode(bq, bq->reported_mode);
> -                       dev_info(bq->dev, "automode enabled\n");
>                 } else {
> -                       bq->automode = -1;
> -                       dev_info(bq->dev, "automode failed\n");
> +                       dev_info(bq->dev, "notifier power supply device (%s) "
> +                               "for automode is not registred yet... "
> +                               "automode will not work without that device\n",
> +                               bq->init_data.notify_device);
>                 }
> +               bq->automode = 1;
> +               dev_info(bq->dev, "automode enabled\n");
>         } else {
>                 bq->automode = -1;
>                 dev_info(bq->dev, "automode not supported\n");
> @@ -1590,6 +1632,7 @@ static int bq2415x_probe(struct i2c_client *client,
>         dev_info(bq->dev, "driver registered\n");
>         return 0;
>
> +error_5:
>  error_4:
>         bq2415x_sysfs_exit(bq);
>  error_3:
> @@ -1610,8 +1653,8 @@ static int bq2415x_remove(struct i2c_client *client)
>  {
>         struct bq2415x_device *bq = i2c_get_clientdata(client);
>
> -       if (bq->init_data.set_mode_hook)
> -               bq->init_data.set_mode_hook(NULL, NULL);
> +       if (bq->init_data.notify_device)
> +               power_supply_unreg_notifier(&bq->nb);
>
>         bq2415x_sysfs_exit(bq);
>         bq2415x_power_supply_exit(bq);
> diff --git a/include/linux/power/bq2415x_charger.h b/include/linux/power/bq2415x_charger.h
> index 8dcc0f4..50762af 100644
> --- a/include/linux/power/bq2415x_charger.h
> +++ b/include/linux/power/bq2415x_charger.h
> @@ -1,7 +1,7 @@
>  /*
>   * bq2415x charger driver
>   *
> - * Copyright (C) 2011-2012  Pali Rohár <pali.rohar@gmail.com>
> + * Copyright (C) 2011-2013  Pali Rohár <pali.rohar@gmail.com>
>   *
>   * This program is free software; you can redistribute it and/or modify
>   * it under the terms of the GNU General Public License as published by
> @@ -31,46 +31,9 @@
>   * termination current. It it is less or equal to zero, configuring charge
>   * and termination current will not be possible.
>   *
> - * Function set_mode_hook is needed for automode (setting correct current
> - * limit when charger is connected/disconnected or setting boost mode).
> - * When is NULL, automode function is disabled. When is not NULL, it must
> - * have this prototype:
> - *
> - *    int (*set_mode_hook)(
> - *      void (*hook)(enum bq2415x_mode mode, void *data),
> - *      void *data)
> - *
> - * hook is hook function (see below) and data is pointer to driver private
> - * data
> - *
> - * bq2415x driver will call it as:
> - *
> - *    platform_data->set_mode_hook(bq2415x_hook_function, bq2415x_device);
> - *
> - * Board/platform function set_mode_hook return non zero value when hook
> - * function was successful registered. Platform code should call that hook
> - * function (which get from pointer, with data) every time when charger
> - * was connected/disconnected or require to enable boost mode. bq2415x
> - * driver then will set correct current limit, enable/disable charger or
> - * boost mode.
> - *
> - * Hook function has this prototype:
> - *
> - *    void hook(enum bq2415x_mode mode, void *data);
> - *
> - * mode is bq2415x mode (charger or boost)
> - * data is pointer to driver private data (which get from
> - * set_charger_type_hook)
> - *
> - * When bq driver is being unloaded, it call function:
> - *
> - *    platform_data->set_mode_hook(NULL, NULL);
> - *
> - * (hook function and driver private data are NULL)
> - *
> - * After that board/platform code must not call driver hook function! It
> - * is possible that pointer to hook function will not be valid and calling
> - * will cause undefined result.
> + * For automode support is needed to provide name of power supply device
> + * in value notify_device. Device driver must immediately report property
> + * POWER_SUPPLY_PROP_CURRENT_MAX when current changed.
>   */
>
>  /* Supported modes with maximal current limit */
> @@ -89,8 +52,7 @@ struct bq2415x_platform_data {
>         int charge_current;             /* mA */
>         int termination_current;        /* mA */
>         int resistor_sense;             /* m ohm */
> -       int (*set_mode_hook)(void (*hook)(enum bq2415x_mode mode, void *data),
> -                            void *data);
> +       const char *notify_device;      /* name */
>  };
>
>  #endif
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Michael Trimarchi]

Hi

On Tue, Nov 19, 2013 at 11:18 AM, Pali Rohár <pali.rohar@gmail.com> 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.rohar@gmail.com>
> ---
>  drivers/power/bq2415x_charger.c       |   77 +++++++++++++++++++++++++--------
>  include/linux/power/bq2415x_charger.h |   48 +++-----------------
>  2 files changed, 65 insertions(+), 60 deletions(-)
>
> diff --git a/drivers/power/bq2415x_charger.c b/drivers/power/bq2415x_charger.c
> index 0727f92..d89583d 100644
> --- a/drivers/power/bq2415x_charger.c
> +++ b/drivers/power/bq2415x_charger.c
> @@ -1,7 +1,7 @@
>  /*
>   * bq2415x charger driver
>   *
> - * Copyright (C) 2011-2012  Pali Rohár <pali.rohar@gmail.com>
> + * Copyright (C) 2011-2013  Pali Rohár <pali.rohar@gmail.com>
>   *
>   * This program is free software; you can redistribute it and/or modify
>   * it under the terms of the GNU General Public License as published by
> @@ -170,6 +170,7 @@ struct bq2415x_device {
>         struct bq2415x_platform_data init_data;
>         struct power_supply charger;
>         struct delayed_work work;
> +       struct notifier_block nb;
>         enum bq2415x_mode reported_mode;/* mode reported by hook function */
>         enum bq2415x_mode mode;         /* current configured mode */
>         enum bq2415x_chip chip;
> @@ -791,24 +792,53 @@ static int bq2415x_set_mode(struct bq2415x_device *bq, enum bq2415x_mode mode)
>
>  }
>
> -/* hook function called by other driver which set reported mode */
> -static void bq2415x_hook_function(enum bq2415x_mode mode, void *data)
> +static int bq2415x_notifier_call(struct notifier_block *nb,
> +               unsigned long val, void *v)
>  {
> -       struct bq2415x_device *bq = data;
> +       struct bq2415x_device *bq =
> +               container_of(nb, struct bq2415x_device, nb);
> +       struct power_supply *psy = v;
> +       enum bq2415x_mode mode;
> +       union power_supply_propval prop;
> +       int ret;
> +       int mA;
>
> -       if (!bq)
> -               return;
> +       if (val != PSY_EVENT_PROP_CHANGED)
> +               return NOTIFY_OK;
> +
> +       if (strcmp(psy->name, bq->init_data.notify_device) != 0)
> +               return NOTIFY_OK;
> +
> +       dev_dbg(bq->dev, "notifier call was called\n");
> +
> +       ret = psy->get_property(psy, POWER_SUPPLY_PROP_CURRENT_MAX, &prop);
> +       if (ret != 0)
> +               return NOTIFY_OK;

So you can read this value without any type of synchronization with
the power_supply_core
and sysfs implementation?


Michael

> +
> +       mA = prop.intval;
> +
> +       if (mA == 0)
> +               mode = BQ2415X_MODE_OFF;
> +       else if (mA < 500)
> +               mode = BQ2415X_MODE_NONE;
> +       else if (mA < 1800)
> +               mode = BQ2415X_MODE_HOST_CHARGER;
> +       else
> +               mode = BQ2415X_MODE_DEDICATED_CHARGER;
> +
> +       if (bq->reported_mode == mode)
> +               return NOTIFY_OK;
>
> -       dev_dbg(bq->dev, "hook function was called\n");
>         bq->reported_mode = mode;
>
>         /* if automode is not enabled do not tell about reported_mode */
>         if (bq->automode < 1)
> -               return;
> +               return NOTIFY_OK;
>
>         sysfs_notify(&bq->charger.dev->kobj, NULL, "reported_mode");
>         bq2415x_set_mode(bq, bq->reported_mode);
>
> +       return NOTIFY_OK;
>  }
>
>  /**** timer functions ****/
> @@ -1508,6 +1538,7 @@ static int bq2415x_probe(struct i2c_client *client,
>         int num;
>         char *name;
>         struct bq2415x_device *bq;
> +       struct power_supply *psy;
>
>         if (!client->dev.platform_data) {
>                 dev_err(&client->dev, "platform data not set\n");
> @@ -1569,16 +1600,27 @@ static int bq2415x_probe(struct i2c_client *client,
>                 goto error_4;
>         }
>
> -       if (bq->init_data.set_mode_hook) {
> -               if (bq->init_data.set_mode_hook(
> -                               bq2415x_hook_function, bq)) {
> -                       bq->automode = 1;
> +       if (bq->init_data.notify_device) {
> +               bq->nb.notifier_call = bq2415x_notifier_call;
> +               ret = power_supply_reg_notifier(&bq->nb);
> +               if (ret) {
> +                       dev_err(bq->dev, "failed to reg notifier: %d\n", ret);
> +                       goto error_5;
> +               }
> +               psy = power_supply_get_by_name(bq->init_data.notify_device);
> +               if (psy) {
> +                       /* Query for initial reported_mode and set it */
> +                       bq2415x_notifier_call(&bq->nb,
> +                                       PSY_EVENT_PROP_CHANGED, psy);
>                         bq2415x_set_mode(bq, bq->reported_mode);
> -                       dev_info(bq->dev, "automode enabled\n");
>                 } else {
> -                       bq->automode = -1;
> -                       dev_info(bq->dev, "automode failed\n");
> +                       dev_info(bq->dev, "notifier power supply device (%s) "
> +                               "for automode is not registred yet... "
> +                               "automode will not work without that device\n",
> +                               bq->init_data.notify_device);
>                 }
> +               bq->automode = 1;
> +               dev_info(bq->dev, "automode enabled\n");
>         } else {
>                 bq->automode = -1;
>                 dev_info(bq->dev, "automode not supported\n");
> @@ -1590,6 +1632,7 @@ static int bq2415x_probe(struct i2c_client *client,
>         dev_info(bq->dev, "driver registered\n");
>         return 0;
>
> +error_5:
>  error_4:
>         bq2415x_sysfs_exit(bq);
>  error_3:
> @@ -1610,8 +1653,8 @@ static int bq2415x_remove(struct i2c_client *client)
>  {
>         struct bq2415x_device *bq = i2c_get_clientdata(client);
>
> -       if (bq->init_data.set_mode_hook)
> -               bq->init_data.set_mode_hook(NULL, NULL);
> +       if (bq->init_data.notify_device)
> +               power_supply_unreg_notifier(&bq->nb);
>
>         bq2415x_sysfs_exit(bq);
>         bq2415x_power_supply_exit(bq);
> diff --git a/include/linux/power/bq2415x_charger.h b/include/linux/power/bq2415x_charger.h
> index 8dcc0f4..50762af 100644
> --- a/include/linux/power/bq2415x_charger.h
> +++ b/include/linux/power/bq2415x_charger.h
> @@ -1,7 +1,7 @@
>  /*
>   * bq2415x charger driver
>   *
> - * Copyright (C) 2011-2012  Pali Rohár <pali.rohar@gmail.com>
> + * Copyright (C) 2011-2013  Pali Rohár <pali.rohar@gmail.com>
>   *
>   * This program is free software; you can redistribute it and/or modify
>   * it under the terms of the GNU General Public License as published by
> @@ -31,46 +31,9 @@
>   * termination current. It it is less or equal to zero, configuring charge
>   * and termination current will not be possible.
>   *
> - * Function set_mode_hook is needed for automode (setting correct current
> - * limit when charger is connected/disconnected or setting boost mode).
> - * When is NULL, automode function is disabled. When is not NULL, it must
> - * have this prototype:
> - *
> - *    int (*set_mode_hook)(
> - *      void (*hook)(enum bq2415x_mode mode, void *data),
> - *      void *data)
> - *
> - * hook is hook function (see below) and data is pointer to driver private
> - * data
> - *
> - * bq2415x driver will call it as:
> - *
> - *    platform_data->set_mode_hook(bq2415x_hook_function, bq2415x_device);
> - *
> - * Board/platform function set_mode_hook return non zero value when hook
> - * function was successful registered. Platform code should call that hook
> - * function (which get from pointer, with data) every time when charger
> - * was connected/disconnected or require to enable boost mode. bq2415x
> - * driver then will set correct current limit, enable/disable charger or
> - * boost mode.
> - *
> - * Hook function has this prototype:
> - *
> - *    void hook(enum bq2415x_mode mode, void *data);
> - *
> - * mode is bq2415x mode (charger or boost)
> - * data is pointer to driver private data (which get from
> - * set_charger_type_hook)
> - *
> - * When bq driver is being unloaded, it call function:
> - *
> - *    platform_data->set_mode_hook(NULL, NULL);
> - *
> - * (hook function and driver private data are NULL)
> - *
> - * After that board/platform code must not call driver hook function! It
> - * is possible that pointer to hook function will not be valid and calling
> - * will cause undefined result.
> + * For automode support is needed to provide name of power supply device
> + * in value notify_device. Device driver must immediately report property
> + * POWER_SUPPLY_PROP_CURRENT_MAX when current changed.
>   */
>
>  /* Supported modes with maximal current limit */
> @@ -89,8 +52,7 @@ struct bq2415x_platform_data {
>         int charge_current;             /* mA */
>         int termination_current;        /* mA */
>         int resistor_sense;             /* m ohm */
> -       int (*set_mode_hook)(void (*hook)(enum bq2415x_mode mode, void *data),
> -                            void *data);
> +       const char *notify_device;      /* name */
>  };
>
>  #endif
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 1008 bytes --]

On Sunday 24 November 2013 18:00:00 Sebastian Reichel wrote:
> Hi,
> 
> On Tue, Nov 19, 2013 at 11:18:04AM +0100, 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.
> 
> I'm wondering if the watchdog thread should check some values,
> like e.g. battery temperature. It should stop charging the
> battery if some critical battery temperature threshold is
> reached.
> 
> -- Sebastian

For checking battery temperature is needed third driver 
(rx51_battery.ko). And I think this should not be implemented in 
driver itself but in charger manager framework...

Currently on Maemo 5 this is handled in userspace (with open 
source dsme daemon).

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 2018 bytes --]

On Sunday 24 November 2013 18:18:03 Michael Trimarchi wrote:
> Hi
> 
> On Tue, Nov 19, 2013 at 11:18 AM, Pali Rohár 
<pali.rohar@gmail.com> 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.rohar@gmail.com>
> > ---
> > 
> >  drivers/power/bq2415x_charger.c       |   77
> >  +++++++++++++++++++++++++--------
> >  include/linux/power/bq2415x_charger.h |   48
> >  +++----------------- 2 files changed, 65 insertions(+), 60
> >  deletions(-)
> > 
...
> > 
> > -       struct bq2415x_device *bq = data;
> > +       struct bq2415x_device *bq =
> > +               container_of(nb, struct bq2415x_device, nb);
> > +       struct power_supply *psy = v;
> > +       enum bq2415x_mode mode;
> > +       union power_supply_propval prop;
> > +       int ret;
> > +       int mA;
> > 
> > -       if (!bq)
> > -               return;
> > +       if (val != PSY_EVENT_PROP_CHANGED)
> > +               return NOTIFY_OK;
> > +
> > +       if (strcmp(psy->name, bq->init_data.notify_device)
> > != 0) +               return NOTIFY_OK;
> > +
> > +       dev_dbg(bq->dev, "notifier call was called\n");
> > +
> > +       ret = psy->get_property(psy,
> > POWER_SUPPLY_PROP_CURRENT_MAX, &prop); +       if (ret !=
> > 0)
> > +               return NOTIFY_OK;
> 
> So you can read this value without any type of synchronization
> with the power_supply_core
> and sysfs implementation?
> 
> 
> Michael
> 

I do not see reason why I cannot use it. When isp1704 driver send 
PSY_EVENT_PROP_CHANGED then property 
POWER_SUPPLY_PROP_CURRENT_MAX is already updated and can be read 
by get_property function.

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 1224 bytes --]

On Sun, Nov 24, 2013 at 08:01:16PM +0100, Pali Rohár wrote:
> > I'm wondering if the watchdog thread should check some values,
> > like e.g. battery temperature. It should stop charging the
> > battery if some critical battery temperature threshold is
> > reached.
> 
> For checking battery temperature is needed third driver 
> (rx51_battery.ko).

I know, but that doesn't mean one can skip the check.

> And I think this should not be implemented in driver itself but in
> charger manager framework...

There is a reason, that the HW has a watchdog. I think the safety
relevant stuff should be done in the watchdog thread. This ensures,
that charging depends on reading the safety relevant sensors.

Of course the watchdog stuff could be moved into the charger manager
framework...

> Currently on Maemo 5 this is handled in userspace (with open 
> source dsme daemon).

I assume it currently also takes care of the bq2415x watchdog? That
means if the daemon dies charging will stop, because the watchdog
does no longer trigger.

When your patch is applied you have introduced a safety issue.
When the daemon dies charging will continue and temperature is
no longer checked.

-- Sebastian

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 1101 bytes --]

On Sunday 24 November 2013 20:26:09 Sebastian Reichel wrote:
> On Sun, Nov 24, 2013 at 08:01:16PM +0100, Pali Rohár wrote:
> > Currently on Maemo 5 this is handled in userspace (with open
> > source dsme daemon).
> 
> I assume it currently also takes care of the bq2415x watchdog?
> That means if the daemon dies charging will stop, because the
> watchdog does no longer trigger.
> 
> When your patch is applied you have introduced a safety issue.
> When the daemon dies charging will continue and temperature is
> no longer checked.
> 
> -- Sebastian

No dsme checking battery temperature and does not handle bq24510 
timer (previously this was in closed bme daemon which 
functionality is now in kernel drivers). But dsme daemon also 
kicking tlw4030 watchdog, so when daemon dies after 30s tlw4030 
reboot device.

But right you can implement correctly this in userspace (e.g. 
when daemon not running/crashed, you can restart daemon or reboot 
system or disable charing, whatever...) and you do not need to 
have it in kernel...

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 1606 bytes --]

On Sun, Nov 24, 2013 at 08:41:46PM +0100, Pali Rohár wrote:
> On Sunday 24 November 2013 20:26:09 Sebastian Reichel wrote:
> > On Sun, Nov 24, 2013 at 08:01:16PM +0100, Pali Rohár wrote:
> > > Currently on Maemo 5 this is handled in userspace (with open
> > > source dsme daemon).
> > 
> > I assume it currently also takes care of the bq2415x watchdog?
> > That means if the daemon dies charging will stop, because the
> > watchdog does no longer trigger.
> > 
> > When your patch is applied you have introduced a safety issue.
> > When the daemon dies charging will continue and temperature is
> > no longer checked.
> > 
> > -- Sebastian
> 
> No dsme checking battery temperature and does not handle bq24510 
> timer (previously this was in closed bme daemon which 
> functionality is now in kernel drivers).

Ok, so then the temperature checks are done by bme.

> But dsme daemon also kicking tlw4030 watchdog, so when daemon dies
> after 30s tlw4030 reboot device.

Yes, but that does not matter if it does not take care of the
charging. If the dsme daemon is not started for some reason
phone will not be rebootet and phone charges.

> But right you can implement correctly this in userspace (e.g. 
> when daemon not running/crashed, you can restart daemon or reboot 
> system or disable charing, whatever...) and you do not need to 
> have it in kernel...

That does not change the fact, that the kernel openes a safety issue
in default configuration. To be on the safe side charging must be
disabled until some safety checking daemon enables it.

-- Sebastian

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Pavel Machek]

Hi!

On Sun 2013-11-24 20:41:46, Pali Rohár wrote:
> On Sunday 24 November 2013 20:26:09 Sebastian Reichel wrote:
> > On Sun, Nov 24, 2013 at 08:01:16PM +0100, Pali Rohár wrote:
> > > Currently on Maemo 5 this is handled in userspace (with open
> > > source dsme daemon).
> > 
> > I assume it currently also takes care of the bq2415x watchdog?
> > That means if the daemon dies charging will stop, because the
> > watchdog does no longer trigger.
> > 
> > When your patch is applied you have introduced a safety issue.
> > When the daemon dies charging will continue and temperature is
> > no longer checked.
> > 
> > -- Sebastian
> 
> No dsme checking battery temperature and does not handle bq24510 
> timer (previously this was in closed bme daemon which 
> functionality is now in kernel drivers). But dsme daemon also 
> kicking tlw4030 watchdog, so when daemon dies after 30s tlw4030 
> reboot device.
> 
> But right you can implement correctly this in userspace (e.g. 
> when daemon not running/crashed, you can restart daemon or reboot 
> system or disable charing, whatever...) and you do not need to 
> have it in kernel...

Charging handling really should be in kernel.

1st) you want charging to work with init=/bin/bash, and you want it
with regular (not n900-specific) debian/arm.

2st) normally hardware, firmware or kernel does the charging. (PCs,
Sharp Zaurus). Yes, it pulls us farther away from Maemo...

Where can I get dsme sources?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 699 bytes --]

On Monday 25 November 2013 15:01:27 Pavel Machek wrote:
> Where can I get dsme sources?
> 									Pavel

dsme daemon: https://gitorious.org/community-ssu/dsme
dsme thermal plugin: https://gitorious.org/rx51-bme-replacement/dsme-thermalobject-surface

dsme thermal plugin is responsible for checking temperature of 
battery and send it to dsme damon. dsme daemon itself checking 
temperature limits and do something (e.g reboot device)

in dsme thermal plugin git history you can find both old version 
(which asking temperature from proprietary nokia bme daemon) and 
new version which reading temperature from power supply kernel 
modules.

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Pavel Machek]

On Mon 2013-11-25 15:10:00, Pali Rohár wrote:
> On Monday 25 November 2013 15:01:27 Pavel Machek wrote:
> > Where can I get dsme sources?
> > 									Pavel
> 
> dsme daemon: https://gitorious.org/community-ssu/dsme
> dsme thermal plugin: https://gitorious.org/rx51-bme-replacement/dsme-thermalobject-surface
> 
> dsme thermal plugin is responsible for checking temperature of 
> battery and send it to dsme damon. dsme daemon itself checking 
> temperature limits and do something (e.g reboot device)

Thanks for links!

AFAICT.... dsme daemon does some kind of system management, not
directly controlling charging, right? It does monitor system temperature.

Now.. Imagine phone left in car in charger (on sun). Likely
temperature will reach high values, kernel is charging, dsme will
reboot the system, but kernel will start charging again, dsme will
reboot again, ...

And it is not only high temperatures that are problem for li-ion
charging; battery should not be fast charged below 5C and should not
be charged below 0C. (Again, both are likely to happen if you leave
your phone in car).

AFAICT, we should simply disable charging below 5C or above 45C.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 1578 bytes --]

On Monday 25 November 2013 16:18:39 Pavel Machek wrote:
> On Mon 2013-11-25 15:10:00, Pali Rohár wrote:
> > On Monday 25 November 2013 15:01:27 Pavel Machek wrote:
> > > Where can I get dsme sources?
> > > 
> > > 									Pavel
> > 
> > dsme daemon: https://gitorious.org/community-ssu/dsme
> > dsme thermal plugin:
> > https://gitorious.org/rx51-bme-replacement/dsme-thermalobje
> > ct-surface
> > 
> > dsme thermal plugin is responsible for checking temperature
> > of battery and send it to dsme damon. dsme daemon itself
> > checking temperature limits and do something (e.g reboot
> > device)
> 
> Thanks for links!
> 
> AFAICT.... dsme daemon does some kind of system management,
> not directly controlling charging, right? It does monitor
> system temperature.
> 

Yes.

> Now.. Imagine phone left in car in charger (on sun). Likely
> temperature will reach high values, kernel is charging, dsme
> will reboot the system, but kernel will start charging again,
> dsme will reboot again, ...
> 
> And it is not only high temperatures that are problem for
> li-ion charging; battery should not be fast charged below 5C
> and should not be charged below 0C. (Again, both are likely
> to happen if you leave your phone in car).
> 
> AFAICT, we should simply disable charging below 5C or above
> 45C.
> 
> 									Pavel

Similar patch (as this) can be added to check for temperature 
from specified power supply driver (in timer reset thread). This 
can be easy and will fix this problem.

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Michael Trimarchi]

Hi

On Sun, Nov 24, 2013 at 8:01 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> On Sunday 24 November 2013 18:18:03 Michael Trimarchi wrote:
>> Hi
>>
>> On Tue, Nov 19, 2013 at 11:18 AM, Pali Rohár
> <pali.rohar@gmail.com> 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.rohar@gmail.com>
>> > ---
>> >
>> >  drivers/power/bq2415x_charger.c       |   77
>> >  +++++++++++++++++++++++++--------
>> >  include/linux/power/bq2415x_charger.h |   48
>> >  +++----------------- 2 files changed, 65 insertions(+), 60
>> >  deletions(-)
>> >
> ...
>> >
>> > -       struct bq2415x_device *bq = data;
>> > +       struct bq2415x_device *bq =
>> > +               container_of(nb, struct bq2415x_device, nb);
>> > +       struct power_supply *psy = v;
>> > +       enum bq2415x_mode mode;
>> > +       union power_supply_propval prop;
>> > +       int ret;
>> > +       int mA;
>> >
>> > -       if (!bq)
>> > -               return;
>> > +       if (val != PSY_EVENT_PROP_CHANGED)
>> > +               return NOTIFY_OK;
>> > +
>> > +       if (strcmp(psy->name, bq->init_data.notify_device)
>> > != 0) +               return NOTIFY_OK;
>> > +
>> > +       dev_dbg(bq->dev, "notifier call was called\n");
>> > +
>> > +       ret = psy->get_property(psy,
>> > POWER_SUPPLY_PROP_CURRENT_MAX, &prop); +       if (ret !=
>> > 0)
>> > +               return NOTIFY_OK;
>>
>> So you can read this value without any type of synchronization
>> with the power_supply_core
>> and sysfs implementation?
>>
>>
>> Michael
>>
>
> I do not see reason why I cannot use it. When isp1704 driver send
> PSY_EVENT_PROP_CHANGED then property
> POWER_SUPPLY_PROP_CURRENT_MAX is already updated and can be read
> by get_property function.
>

https://lists.ubuntu.com/archives/kernel-team/2013-January/025206.html

I found and equivalent scenario that I was trying to said

Michael


> --
> Pali Rohár
> pali.rohar@gmail.com

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

[Michael Trimarchi]

Hi

On Sun, Nov 24, 2013 at 8:01 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> On Sunday 24 November 2013 18:18:03 Michael Trimarchi wrote:
>> Hi
>>
>> On Tue, Nov 19, 2013 at 11:18 AM, Pali Rohár
> <pali.rohar@gmail.com> 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.rohar@gmail.com>
>> > ---
>> >
>> >  drivers/power/bq2415x_charger.c       |   77
>> >  +++++++++++++++++++++++++--------
>> >  include/linux/power/bq2415x_charger.h |   48
>> >  +++----------------- 2 files changed, 65 insertions(+), 60
>> >  deletions(-)
>> >
> ...
>> >
>> > -       struct bq2415x_device *bq = data;
>> > +       struct bq2415x_device *bq =
>> > +               container_of(nb, struct bq2415x_device, nb);
>> > +       struct power_supply *psy = v;
>> > +       enum bq2415x_mode mode;
>> > +       union power_supply_propval prop;
>> > +       int ret;
>> > +       int mA;
>> >
>> > -       if (!bq)
>> > -               return;
>> > +       if (val != PSY_EVENT_PROP_CHANGED)
>> > +               return NOTIFY_OK;
>> > +
>> > +       if (strcmp(psy->name, bq->init_data.notify_device)
>> > != 0) +               return NOTIFY_OK;
>> > +
>> > +       dev_dbg(bq->dev, "notifier call was called\n");
>> > +
>> > +       ret = psy->get_property(psy,
>> > POWER_SUPPLY_PROP_CURRENT_MAX, &prop); +       if (ret !=
>> > 0)
>> > +               return NOTIFY_OK;
>>
>> So you can read this value without any type of synchronization
>> with the power_supply_core
>> and sysfs implementation?
>>
>>
>> Michael
>>
>
> I do not see reason why I cannot use it. When isp1704 driver send
> PSY_EVENT_PROP_CHANGED then property
> POWER_SUPPLY_PROP_CURRENT_MAX is already updated and can be read
> by get_property function.
>

https://lists.ubuntu.com/archives/kernel-team/2013-January/025206.html

I found and equivalent scenario that I was trying to said

Michael


> --
> Pali Rohár
> pali.rohar@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Tc, Jenny]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 979 bytes --]


> 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.tc@intel.com>
> Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> ---

Acked-by: Jenny TC <jenny.tc@intel.com>
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

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

[Tc, Jenny]

> 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.tc@intel.com>
> Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> ---

Acked-by: Jenny TC <jenny.tc@intel.com>

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

[Anton Vorontsov]

On Wed, Nov 27, 2013 at 05:23:34PM +0000, 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.tc@intel.com>
> > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> > ---
> 
> Acked-by: Jenny TC <jenny.tc@intel.com>

Applied, thanks a lot!

Anton

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

[Anton Vorontsov]

On Tue, Nov 19, 2013 at 11:18:03AM +0100, Pali Rohár wrote:
> This patch adds a notifier chain to the power_supply.
> This notifier helps drivers in other subsystem to listen to
> changes in power supply subsystem. This would help to take some
> actions in those drivers on changing the power supply properties.
> One such scenario is to increase/decrease system performance based
> on the battery capacity/voltage. Another scenario is to adjust the
> h/w peak current detection voltage/current thresholds based on battery
> voltage/capacity. The notifier helps drivers to listen to changes
> in power_suppy susbystem without polling the power_supply properties
> 
> Signed-off-by: Jenny TC <jenny.tc@intel.com>
> Signed-off-by: Pali Rohár <pali.rohar@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_head    power_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);

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

[Anton Vorontsov]

On Tue, Nov 19, 2013 at 11:18:03AM +0100, Pali Rohár wrote:
> This patch adds a notifier chain to the power_supply.
> This notifier helps drivers in other subsystem to listen to
> changes in power supply subsystem. This would help to take some
> actions in those drivers on changing the power supply properties.
> One such scenario is to increase/decrease system performance based
> on the battery capacity/voltage. Another scenario is to adjust the
> h/w peak current detection voltage/current thresholds based on battery
> voltage/capacity. The notifier helps drivers to listen to changes
> in power_suppy susbystem without polling the power_supply properties
> 
> Signed-off-by: Jenny TC <jenny.tc@intel.com>
> Signed-off-by: Pali Rohár <pali.rohar@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_head    power_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-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Anton Vorontsov]

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

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

Thanks,

Anton

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

[Michael Trimarchi]

Hi Anton

On Sun, Dec 1, 2013 at 11:37 PM, Anton Vorontsov <anton@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?

Michael

> notifiers should be careful to not hold any locks, because the other
> driver might call get_property(), which might acquire locks.
>
> Thanks,
>
> Anton

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

[Anton Vorontsov]

On Mon, Dec 02, 2013 at 01:02:40AM +0100, Michael Trimarchi wrote:
> On Sun, Dec 1, 2013 at 11:37 PM, Anton Vorontsov <anton@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

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

[Michael Trimarchi]

Hi

On Mon, Dec 2, 2013 at 1:24 AM, Anton Vorontsov <anton@enomsg.org> wrote:
> On Mon, Dec 02, 2013 at 01:02:40AM +0100, Michael Trimarchi wrote:
>> On Sun, Dec 1, 2013 at 11:37 PM, Anton Vorontsov <anton@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.
>

Is it more simple to make it not atomic and use a mutex in get_property?

Michael

> Thanks,
>
> Anton

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

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 757 bytes --]

On Tuesday 19 November 2013 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.rohar@gmail.com>
> ---
>  drivers/power/bq2415x_charger.c       |   77
> +++++++++++++++++++++++++--------
> include/linux/power/bq2415x_charger.h |   48
> +++----------------- 2 files changed, 65 insertions(+), 60
> deletions(-)
> 

Hi Anton, is there any problem with this patch?

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Anton Vorontsov]

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

Applied, thanks!

Anton

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

[Tc, Jenny]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2859 bytes --]

Anton,

I don't see this patch in Linux tree. Any update on this would be helpful

Thanks
Jenny

> -----Original Message-----
> From: Anton Vorontsov [mailto:anton@scarybugs.org] On Behalf Of Anton
> Vorontsov
> Sent: Monday, December 02, 2013 3:54 AM
> To: Pali Rohár
> Cc: David Woodhouse; Tony Lindgren; Russell King; linux-kernel@vger.kernel.org;
> linux-omap@vger.kernel.org; freemangordon@abv.bg; aaro.koskinen@iki.fi;
> pavel@ucw.cz; Tc, Jenny
> Subject: 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.tc@intel.com>
> > Signed-off-by: Pali Rohár <pali.rohar@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_head    power_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);
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

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

[Tc, Jenny]

Anton,

I don't see this patch in Linux tree. Any update on this would be helpful

Thanks
Jenny

> -----Original Message-----
> From: Anton Vorontsov [mailto:anton@scarybugs.org] On Behalf Of Anton
> Vorontsov
> Sent: Monday, December 02, 2013 3:54 AM
> To: Pali Rohár
> Cc: David Woodhouse; Tony Lindgren; Russell King; linux-kernel@vger.kernel.org;
> linux-omap@vger.kernel.org; freemangordon@abv.bg; aaro.koskinen@iki.fi;
> pavel@ucw.cz; Tc, Jenny
> Subject: 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.tc@intel.com>
> > Signed-off-by: Pali Rohár <pali.rohar@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_head    power_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);

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

[Anton Vorontsov]

On Fri, Jan 03, 2014 at 11:09:49AM +0000, 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

?..

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

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 3830 bytes --]

On Mon, Dec 02, 2013 at 02:45:06AM +0100, Michael Trimarchi wrote:
> On Mon, Dec 2, 2013 at 1:24 AM, Anton Vorontsov <anton@enomsg.org> wrote:
> > On Mon, Dec 02, 2013 at 01:02:40AM +0100, Michael Trimarchi wrote:
> >> On Sun, Dec 1, 2013 at 11:37 PM, Anton Vorontsov <anton@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.
> >
> 
> Is it more simple to make it not atomic and use a mutex in get_property?

I just built a kernel with CONFIG_DEBUG_ATOMIC_SLEEP to test another
driver and got the following output for bq2415x:

[    7.667449] Workqueue: events power_supply_changed_work
[    7.673034] [<c0015c28>] (unwind_backtrace+0x0/0xe0) from [<c0011e1c>] (show_stack+0x10/0x14)
[    7.682098] [<c0011e1c>] (show_stack+0x10/0x14) from [<c052cdd0>] (dump_stack+0x78/0xac)
[    7.690704] [<c052cdd0>] (dump_stack+0x78/0xac) from [<c052a044>] (__schedule_bug+0x48/0x60)
[    7.699645] [<c052a044>] (__schedule_bug+0x48/0x60) from [<c053071c>] (__schedule+0x74/0x638)
[    7.708618] [<c053071c>] (__schedule+0x74/0x638) from [<c05301fc>] (schedule_timeout+0x1dc/0x24c)
[    7.718017] [<c05301fc>] (schedule_timeout+0x1dc/0x24c) from [<c05316ec>] (wait_for_common+0x138/0x17c)
[    7.727966] [<c05316ec>] (wait_for_common+0x138/0x17c) from [<c0362a70>] (omap_i2c_xfer+0x340/0x4a0)
[    7.737640] [<c0362a70>] (omap_i2c_xfer+0x340/0x4a0) from [<c035d928>] (__i2c_transfer+0x40/0x74)
[    7.747039] [<c035d928>] (__i2c_transfer+0x40/0x74) from [<c035e22c>] (i2c_transfer+0x6c/0x90)
[    7.756195] [<c035e22c>] (i2c_transfer+0x6c/0x90) from [<c037ad24>] (bq2415x_i2c_write+0x48/0x78)
[    7.765563] [<c037ad24>] (bq2415x_i2c_write+0x48/0x78) from [<c037ae60>] (bq2415x_set_weak_battery_voltage+0x4c/0x50)
[    7.776824] [<c037ae60>] (bq2415x_set_weak_battery_voltage+0x4c/0x50) from [<c037bce8>] (bq2415x_set_mode+0xdc/0x14c)
[    7.788085] [<c037bce8>] (bq2415x_set_mode+0xdc/0x14c) from [<c037bfb8>] (bq2415x_notifier_call+0xa8/0xb4)
[    7.798309] [<c037bfb8>] (bq2415x_notifier_call+0xa8/0xb4) from [<c005f228>] (notifier_call_chain+0x38/0x68)
[    7.808715] [<c005f228>] (notifier_call_chain+0x38/0x68) from [<c005f284>] (__atomic_notifier_call_chain+0x2c/0x3c)
[    7.819732] [<c005f284>] (__atomic_notifier_call_chain+0x2c/0x3c) from [<c005f2a8>] (atomic_notifier_call_chain+0x14/0x18)
[    7.831420] [<c005f2a8>] (atomic_notifier_call_chain+0x14/0x18) from [<c0378078>] (power_supply_changed_work+0x6c/0xb8)
[    7.842864] [<c0378078>] (power_supply_changed_work+0x6c/0xb8) from [<c00556c0>] (process_one_work+0x248/0x440)
[    7.853546] [<c00556c0>] (process_one_work+0x248/0x440) from [<c0055d6c>] (worker_thread+0x208/0x350)
[    7.863372] [<c0055d6c>] (worker_thread+0x208/0x350) from [<c005b0ac>] (kthread+0xc8/0xdc)
[    7.872131] [<c005b0ac>] (kthread+0xc8/0xdc) from [<c000e138>] (ret_from_fork+0x14/0x3c)

-- Sebastian

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Michael Trimarchi]

Hi

On Sun, Jan 19, 2014 at 9:54 PM, Sebastian Reichel <sre@ring0.de> wrote:
> On Mon, Dec 02, 2013 at 02:45:06AM +0100, Michael Trimarchi wrote:
>> On Mon, Dec 2, 2013 at 1:24 AM, Anton Vorontsov <anton@enomsg.org> wrote:
>> > On Mon, Dec 02, 2013 at 01:02:40AM +0100, Michael Trimarchi wrote:
>> >> On Sun, Dec 1, 2013 at 11:37 PM, Anton Vorontsov <anton@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.
>> >
>>
>> Is it more simple to make it not atomic and use a mutex in get_property?
>
> I just built a kernel with CONFIG_DEBUG_ATOMIC_SLEEP to test another
> driver and got the following output for bq2415x:
>
> [    7.667449] Workqueue: events power_supply_changed_work
> [    7.673034] [<c0015c28>] (unwind_backtrace+0x0/0xe0) from [<c0011e1c>] (show_stack+0x10/0x14)
> [    7.682098] [<c0011e1c>] (show_stack+0x10/0x14) from [<c052cdd0>] (dump_stack+0x78/0xac)
> [    7.690704] [<c052cdd0>] (dump_stack+0x78/0xac) from [<c052a044>] (__schedule_bug+0x48/0x60)
> [    7.699645] [<c052a044>] (__schedule_bug+0x48/0x60) from [<c053071c>] (__schedule+0x74/0x638)
> [    7.708618] [<c053071c>] (__schedule+0x74/0x638) from [<c05301fc>] (schedule_timeout+0x1dc/0x24c)
> [    7.718017] [<c05301fc>] (schedule_timeout+0x1dc/0x24c) from [<c05316ec>] (wait_for_common+0x138/0x17c)
> [    7.727966] [<c05316ec>] (wait_for_common+0x138/0x17c) from [<c0362a70>] (omap_i2c_xfer+0x340/0x4a0)
> [    7.737640] [<c0362a70>] (omap_i2c_xfer+0x340/0x4a0) from [<c035d928>] (__i2c_transfer+0x40/0x74)
> [    7.747039] [<c035d928>] (__i2c_transfer+0x40/0x74) from [<c035e22c>] (i2c_transfer+0x6c/0x90)
> [    7.756195] [<c035e22c>] (i2c_transfer+0x6c/0x90) from [<c037ad24>] (bq2415x_i2c_write+0x48/0x78)
> [    7.765563] [<c037ad24>] (bq2415x_i2c_write+0x48/0x78) from [<c037ae60>] (bq2415x_set_weak_battery_voltage+0x4c/0x50)
> [    7.776824] [<c037ae60>] (bq2415x_set_weak_battery_voltage+0x4c/0x50) from [<c037bce8>] (bq2415x_set_mode+0xdc/0x14c)
> [    7.788085] [<c037bce8>] (bq2415x_set_mode+0xdc/0x14c) from [<c037bfb8>] (bq2415x_notifier_call+0xa8/0xb4)
> [    7.798309] [<c037bfb8>] (bq2415x_notifier_call+0xa8/0xb4) from [<c005f228>] (notifier_call_chain+0x38/0x68)
> [    7.808715] [<c005f228>] (notifier_call_chain+0x38/0x68) from [<c005f284>] (__atomic_notifier_call_chain+0x2c/0x3c)
> [    7.819732] [<c005f284>] (__atomic_notifier_call_chain+0x2c/0x3c) from [<c005f2a8>] (atomic_notifier_call_chain+0x14/0x18)
> [    7.831420] [<c005f2a8>] (atomic_notifier_call_chain+0x14/0x18) from [<c0378078>] (power_supply_changed_work+0x6c/0xb8)
> [    7.842864] [<c0378078>] (power_supply_changed_work+0x6c/0xb8) from [<c00556c0>] (process_one_work+0x248/0x440)
> [    7.853546] [<c00556c0>] (process_one_work+0x248/0x440) from [<c0055d6c>] (worker_thread+0x208/0x350)
> [    7.863372] [<c0055d6c>] (worker_thread+0x208/0x350) from [<c005b0ac>] (kthread+0xc8/0xdc)
> [    7.872131] [<c005b0ac>] (kthread+0xc8/0xdc) from [<c000e138>] (ret_from_fork+0x14/0x3c)
>
> -- Sebastian


I have already give my opinion about this problem

Michael

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

[Russell King - ARM Linux]

And another one using that evil mail-followup-to header:

Mail-Followup-To: Pali Rohár <pali.rohar@gmail.com>,
        Anton Vorontsov <anton@enomsg.org>,
        Michael Trimarchi <michael@amarulasolutions.com>,
        David Woodhouse <dwmw2@infradead.org>,
        Tony Lindgren <tony@atomide.com>,
        Russell King <linux@arm.linux.org.uk>, linux-kernel@vger.kernel.org,
        Linux OMAP Mailing List <linux-omap@vger.kernel.org>,
        freemangordon@abv.bg, aaro.koskinen@iki.fi, pavel@ucw.cz

which results in all the above being moved into the To: header by
unsuspecting recipients who reply to your message.

-- 
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".

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

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 799 bytes --]

On Mon, Jan 20, 2014 at 10:21:29AM +0000, Russell King - ARM Linux wrote:
> And another one using that evil mail-followup-to header:
> 
> Mail-Followup-To: Pali Rohár <pali.rohar@gmail.com>,
>         Anton Vorontsov <anton@enomsg.org>,
>         Michael Trimarchi <michael@amarulasolutions.com>,
>         David Woodhouse <dwmw2@infradead.org>,
>         Tony Lindgren <tony@atomide.com>,
>         Russell King <linux@arm.linux.org.uk>, linux-kernel@vger.kernel.org,
>         Linux OMAP Mailing List <linux-omap@vger.kernel.org>,
>         freemangordon@abv.bg, aaro.koskinen@iki.fi, pavel@ucw.cz
> 
> which results in all the above being moved into the To: header by
> unsuspecting recipients who reply to your message.

Thanks for the hint. Should be fixed now.

-- Sebastian

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 1918 bytes --]

On Thursday 28 November 2013 01:25:50 Sebastian Reichel wrote:
> On Wed, Nov 27, 2013 at 10:16:47PM +0100, Pali Rohár wrote:
> > On Monday 25 November 2013 22:50:01 Sebastian Reichel wrote:
> > > > 2 seems more generic to me, but as rx51-battery is
> > > > missing the functionality to send events on temperature
> > > > change, I guess 1 will be easier to implement.
> > > 
> > > The temperature must be polled anyway, if the ADC does not
> > > support interrupts.
> > 
> > Yes, ADC does not support interrupts, temperature must be
> > polled. Also bq27200 chip does not support interrupts, but
> > bq27x00_battery driver using delayed work which every 60s
> > poll all values (timeout can be configured via modprobe
> > param). So similar code can be added to rx51_battery.ko
> > too.
> 
> I think the safest implementation would be:
> 
> bq2415x polls the temperature from rx51-battery in the bq2415x
> watchdog handler. That way discontinuation of the charge
> process is guaranteed.
> 
> To avoid useless ADC conversion the rx51-battery driver caches
> the converted temperature value for a reasonable time (e.g.
> 10 seconds). This helps if multiple users want to read the
> battery temperature (e.g. userspace).
> 
> This also means, that the kernel stuff can handle charging
> autonomously and the userland daemon checks the battery
> temperature only for emergency shutdown (I guess the
> temperatures for stopping the charging and emergency shutdown
> are different).
> 
> IMHO it makes sense to move the emergency shutdown also into
> the kernel (but different driver!) in the future, but that's
> another topic :)
> 
> -- Sebastian

Just to note, here is original nokia table of temperature limits:

https://gitorious.org/rx51-bme-replacement/dsme-thermalobject-surface/source/master:modules/thermalobject_surface.c#L40

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 1549 bytes --]

On Wed, Nov 27, 2013 at 10:16:47PM +0100, Pali Rohár wrote:
> On Monday 25 November 2013 22:50:01 Sebastian Reichel wrote:
> > > 2 seems more generic to me, but as rx51-battery is missing
> > > the functionality to send events on temperature change, I
> > > guess 1 will be easier to implement.
> > 
> > The temperature must be polled anyway, if the ADC does not
> > support interrupts.
> > 
> 
> Yes, ADC does not support interrupts, temperature must be polled. 
> Also bq27200 chip does not support interrupts, but 
> bq27x00_battery driver using delayed work which every 60s poll 
> all values (timeout can be configured via modprobe param). So 
> similar code can be added to rx51_battery.ko too.

I think the safest implementation would be:

bq2415x polls the temperature from rx51-battery in the bq2415x
watchdog handler. That way discontinuation of the charge process
is guaranteed.

To avoid useless ADC conversion the rx51-battery driver caches the
converted temperature value for a reasonable time (e.g. 10 seconds).
This helps if multiple users want to read the battery temperature
(e.g. userspace).

This also means, that the kernel stuff can handle charging
autonomously and the userland daemon checks the battery temperature
only for emergency shutdown (I guess the temperatures for stopping
the charging and emergency shutdown are different).

IMHO it makes sense to move the emergency shutdown also into the
kernel (but different driver!) in the future, but that's another
topic :)

-- Sebastian

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 669 bytes --]

On Monday 25 November 2013 22:50:01 Sebastian Reichel wrote:
> > 2 seems more generic to me, but as rx51-battery is missing
> > the functionality to send events on temperature change, I
> > guess 1 will be easier to implement.
> 
> The temperature must be polled anyway, if the ADC does not
> support interrupts.
> 

Yes, ADC does not support interrupts, temperature must be polled. 
Also bq27200 chip does not support interrupts, but 
bq27x00_battery driver using delayed work which every 60s poll 
all values (timeout can be configured via modprobe param). So 
similar code can be added to rx51_battery.ko too.

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 1188 bytes --]

Hi,

On Mon, Nov 25, 2013 at 08:32:46PM +0200, Ивайло Димитров wrote:
> So, AIUI there are 2 options:
> 
> 1. charger driver polls the battery driver every n (60?) seconds.
> 2. battery driver sends PSY_EVENT_PROP_CHANGED on every degree
>    up or down.
>  
> In both cases if the temperature is outside of the safe margins, the
> charging should be stopped.

ACK.

> 2 seems more generic to me, but as rx51-battery is missing the
> functionality to send events on temperature change, I guess 1 will
> be easier to implement.

The temperature must be polled anyway, if the ADC does not support
interrupts.

> And I think there should be some method (sysfs entry?, /dev/bqxxx
> opened?) to tell the charger driver to stop polling the battery 
> driver once (and if) the userspace has started to take care of the 
> battery temperature - makes no sense to duplicate the checks IMO.

I would just cache the temperature value in the battery driver for a
couple of seconds. Then userspace can check for very high temperatures
(-> system shutdown) and the charging driver can check for
temperatures, which are critical for charging.

-- Sebastian

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Ивайло Димитров]

  >-------- Оригинално писмо --------
 >От:  Sebastian Reichel 
 >Относно: Re: [PATCH v2 2/3] bq2415x_charger: Use power_supply notifier for
 automode
 >До: Ивайло Димитров 
 >Изпратено на: Понеделник, 2013, Ноември 25 19:14:21 EET
 >
 >
 >On Mon, Nov 25, 2013 at 07:01:54PM +0200, Ивайло Димитров wrote:
 >>> Now.. Imagine phone left in car in charger (on sun). Likely
 >>> temperature will reach high values, kernel is charging, dsme will
 >>> reboot the system, but kernel will start charging again, dsme will
 >>> reboot again, ...
 >>>
 >>> And it is not only high temperatures that are problem for li-ion
 >>> charging; battery should not be fast charged below 5C and should not
 >>> be charged below 0C. (Again, both are likely to happen if you leave
 >>> your phone in car).
 >>>
 >>> AFAICT, we should simply disable charging below 5C or above 45C.
 >> 
 >> AFAIK dsme will not restart it, but power it off, so the above
 >> scenario won't happen.
 >
 >Just assume what happens, when dsme does not start (e.g. system boot
 >hangs).
 >
 >If everything is controlled from userspace, charger would not start
 >(-> safe!). If everything is controlled by the kernel, temperature
 >safety checks are taken (-> safe!). But in the currently proposed
 >variant: No safety checks.
 >
 >-- Sebastian
 >
 >

Hmm, you have a point here :)

So, AIUI there are 2 options:

1. charger driver polls the battery driver every n (60?) seconds.
2. battery driver sends PSY_EVENT_PROP_CHANGED on every degree up or
down
 
In both cases if the temperature is outside of the safe margins, the
charging should be stopped.

2 seems more generic to me, but as rx51-battery is missing the
functionality to send events on temperature change, I guess 1 will
be easier to implement.

And I think there should be some method (sysfs entry?, /dev/bqxxx
opened?) to tell the charger driver to stop polling the battery 
driver once (and if) the userspace has started to take care of the 
battery temperature - makes no sense to duplicate the checks IMO.

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

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 1051 bytes --]

On Mon, Nov 25, 2013 at 07:01:54PM +0200, Ивайло Димитров wrote:
>> Now.. Imagine phone left in car in charger (on sun). Likely
>> temperature will reach high values, kernel is charging, dsme will
>> reboot the system, but kernel will start charging again, dsme will
>> reboot again, ...
>>
>> And it is not only high temperatures that are problem for li-ion
>> charging; battery should not be fast charged below 5C and should not
>> be charged below 0C. (Again, both are likely to happen if you leave
>> your phone in car).
>>
>> AFAICT, we should simply disable charging below 5C or above 45C.
> 
> AFAIK dsme will not restart it, but power it off, so the above
> scenario won't happen.

Just assume what happens, when dsme does not start (e.g. system boot
hangs).

If everything is controlled from userspace, charger would not start
(-> safe!). If everything is controlled by the kernel, temperature
safety checks are taken (-> safe!). But in the currently proposed
variant: No safety checks.

-- Sebastian


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Ивайло Димитров]

 




 >-------- Оригинално писмо --------
 >От:  Pavel Machek 
 >Относно: Re: [PATCH v2 2/3] bq2415x_charger: Use power_supply notifier for
 automode
 >До: Pali Rohár 
 >Изпратено на: Понеделник, 2013, Ноември 25 17:18:39 EET
 >
 >
 >On Mon 2013-11-25 15:10:00, Pali Rohár wrote:
 >> On Monday 25 November 2013 15:01:27 Pavel Machek wrote:
 >> > Where can I get dsme sources?
 >> > 									Pavel
 >> 
 >> dsme daemon: https://gitorious.org/community-ssu/dsme
 >> dsme thermal plugin: https://gitorious.org/rx51-bme-replacement/dsme-thermalobject-surface
 >> 
 >> dsme thermal plugin is responsible for checking temperature of 
 >> battery and send it to dsme damon. dsme daemon itself checking 
 >> temperature limits and do something (e.g reboot device)
 >
 >Thanks for links!
 >
 >AFAICT.... dsme daemon does some kind of system management, not
 >directly controlling charging, right? It does monitor system temperature.
 >
 >Now.. Imagine phone left in car in charger (on sun). Likely
 >temperature will reach high values, kernel is charging, dsme will
 >reboot the system, but kernel will start charging again, dsme will
 >reboot again, ...
 >
 >And it is not only high temperatures that are problem for li-ion
 >charging; battery should not be fast charged below 5C and should not
 >be charged below 0C. (Again, both are likely to happen if you leave
 >your phone in car).
 >
 >AFAICT, we should simply disable charging below 5C or above 45C.
 >
 >									Pavel
 >-- 
 >(english) http://www.livejournal.com/~pavelmachek
 >(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
 >

AFAIK dsme will not restart it, but power it off, so the above scenario won't happen.

Regards,
Ivo