[PATCH 0/3] PMU and Battery interaction in regard to kobject uevent

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:
| Hey,
|
| with 2.6.24 we are using the battery class to present our bq27000
battery. Now
| we would like to update the charging indicator immediately after the
power
| supply was plugged in and the kernel recognized that.
| The kernel has one interface for that. These are the uevents. In the
case of
| the battery you will need the kobject of the battery device.
|
| Now to the issue:
| 	- The battery code has the kobject but does not know about the pmu
| 	- The pmu knows about plugging but doesn't have the kobject.
|
| My proposal:
| 	- Extend the current callback in the pcf50633 driver to allow to
register and
| unregister handlers and make register the bq27000 there.
|
| Alternative proposal:
| 	- Use the existing cb and make the mach-gta02.c call into the battery
code..

OK after squinting at the patches a bit I understand what you mean
above.  pcf50633 specific stuff leaking into bq27000 stuff is not good
as I think you recognized.

pcf50633 driver is bloated and leaking out itself in all directions
dangerously from the maintainence POV.  This was strongly in our minds
when we talked about an MPU to soak it all up, (not that anyone who
hasn't looked in there cared).  So adding a new mega power device event
callback hub in there is not the best way I think.  And -->

The other reason I can think it will be better if the handler for the
notifications was up at the platform level is then someone can make a
device with bq27000 support but no pcf50633 for example, they can leave
the platform callback NULL'd out if they're not interested, or use it if
they want and it all works out OK.

So it looks like it's gonna be cool, but I think we need to make a new
kobject to carry these events at platform level, instead of hanging off
the battery one, and use platform callbacks opaquely (existing cb or new
specific ones) in both pcf50633 and bq27000 to access the platform-level
kobject so there is no dependency created between them (and any other
drivers that also end up notifying using this scheme).  How does that sound?

Also, I didn't see yet it broke the guts of the charging tracking patch
from me too badly, and it can basically integrated using the new
notification action: what is the view from your side?

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkhFGt0ACgkQOjLpvpq7dMrWKACfeLzyngPU/PZJhaZ8oKWf6eak
aVkAniLiNoSb9DbMqdf04wYMmqIdbo1h
=ifli
-----END PGP SIGNATURE-----