-----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-----
