pm: add to_power_supply macro to the API

This patch adds the to_power_supply macro to upcast a device to a power_supply struct.

This is needed because the same piece of code using container_of is used in various other places, so we abstract away such low-level operations via a macro.

---

v9:
* Split the pm changes from the thinkpad_acpi patch into its own patch

v10:
* No changes in this patch in v10

Signed-off-by Ognjen Galic <smclt30p(a)gmail.com>

---
 drivers/power/supply/power_supply_core.c | 2 +-
 include/linux/power_supply.h             | 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

drivers/power/supply/power_supply_core.c +1 -1

index 82f998a..feac7b0 100644
@@ -668,7 +668,7 @@ EXPORT_SYMBOL_GPL(power_supply_powers);
 
 static void power_supply_dev_release(struct device *dev)
 {
-       struct power_supply *psy = container_of(dev, struct power_supply, dev);
+       struct power_supply *psy = to_power_supply(dev);
        dev_dbg(dev, "%s\n", __func__);
        kfree(psy);
 }

include/linux/power_supply.h +0 -0

index 79e90b3..f0139b4 100644

Quoted 4 lines · Ognjen Galic

This patch adds the to_power_supply macro to upcast a device to a power_supply struct.

Quoted 5 lines

This is needed because the same piece of code using container_of is used in various other places, so we abstract away such low-level operations via a macro.

---

This is wrong! You have to use *existing* --- line below. Otherwise all mail parsers will cut this out including your SoB tag.

Quoted 10 lines

v9:
* Split the pm changes from the thinkpad_acpi patch into its own patch

v10:
* No changes in this patch in v10

Signed-off-by Ognjen Galic <[email protected]>

Missed:

Suggested-by Andy Shevchenko <[email protected]>

Quoted 32 lines

---
 drivers/power/supply/power_supply_core.c | 2 +- include/linux/power_supply.h             | 2 ++

 2 files changed, 3 insertions(+), 1 deletion(-)

drivers/power/supply/power_supply_core.c +1 -1

index 82f998a..feac7b0 100644
@@ -668,7 +668,7 @@ EXPORT_SYMBOL_GPL(power_supply_powers);
 
  static void power_supply_dev_release(struct device *dev)
  {
-       struct power_supply *psy = container_of(dev, struct
 power_supply, dev);
+       struct power_supply *psy = to_power_supply(dev);
         dev_dbg(dev, "%s\n", __func__);
         kfree(psy);

 }

include/linux/power_supply.h +0 -0

index 79e90b3..f0139b4 100644
@@ -371,6 +371,8 @@ devm_power_supply_register_no_ws(struct device
 *parent,
  extern void power_supply_unregister(struct power_supply *psy);

 extern int power_supply_powers(struct power_supply *psy, struct device *dev);

Quoted 6 lines

+#define to_power_supply(device) container_of(device, struct power_supply, dev)
+
 extern void *power_supply_get_drvdata(struct power_supply *psy); /* For APM emulation, think legacy userspace. */ extern struct class *power_supply_class;

Should fold in the changes you sent as a separate patch.

Quoted 10 lines · Andy Shevchenko

Quoted 8 lines · Ognjen Galic

This patch adds the to_power_supply macro to upcast a device to a power_supply struct.

This is needed because the same piece of code using container_of is used in various other places, so we abstract away such low-level operations via a macro.

Quoted 4 lines

Quoted 1 line

---

This is wrong! You have to use *existing* --- line below. Otherwise all mail parsers will cut this out including your SoB tag.

My bad I guess. Want another patch revision with that fixed or something?

Quoted 16 lines · Ognjen Galić

Quoted 14 lines · Andy Shevchenko

Quoted 9 lines · Ognjen Galic

This patch adds the to_power_supply macro to upcast a device to a power_supply struct.

This is needed because the same piece of code using container_of is used in various other places, so we abstract away such low-level operations via a macro.

---

This is wrong! You have to use *existing* --- line below. Otherwise all mail parsers will cut this out including your SoB tag.

Quoted 3 lines

My bad I guess. Want another patch revision with that fixed or something?

You definitely need to send a new revision with all comments addressed. So far you didn't responce to them which I recognize as total agreement that they have to be addressed.

Quoted 5 lines · Andy Shevchenko

On Sat, Dec 30, 2017 at 1:49 AM, Ognjen Galić <smclt30p(a)gmail.com> wrote:

You definitely need to send a new revision with all comments addressed. So far you didn't responce to them which I recognize as total agreement that they have to be addressed.

I asked for not sending new versions before I have a chance to look at the current one in detail, but enough time has passed after the last one, so I agree. Sending a new version at this point won't hurt. :-)

Quoted 8 lines · Rafael J. Wysocki

Quoted 5 lines · Andy Shevchenko

On Sat, Dec 30, 2017 at 1:49 AM, Ognjen Galić <[email protected]> wrote:

You definitely need to send a new revision with all comments addressed. So far you didn't responce to them which I recognize as total agreement that they have to be addressed.

Quoted 3 lines

I asked for not sending new versions before I have a chance to look at the current one in detail, but enough time has passed after the last one, so I agree. Sending a new version at this point won't hurt. :-)

Thanks, Rafael, for clarification, that's exactly what I kept in mind when proposing a new version (I'm concerned as well of frequency of patch series to be not so high).

Signature · 2 lines

With Best Regards,
Andy Shevchenko