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

Holger Freyther zecke at openmoko.org
Tue Jun 3 12:51:27 CEST 2008

On Tuesday 03 June 2008 12:20:14 Andy Green wrote:

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

Yes, it is a monster.

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

Yes, if (machine_is_gta02()) would be a workaround to that issue (and it is 
missing from the patch).

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

Well. We need the kobject of the struct power_supply device. To my 
understanding we exactly need that kobject because it is used for the sysfs 
entry of uevent.

So mach-gta02.c is already handling the callbacks for the pcf50633, if we 
would have access to the kobject if the power_supply of the bq27000 driver we 
could send the uevent there.

So how would we get access to? platform_data is normally just a way to give 
data to the driver, not the other way around and we should leave it that way? 
The other option would be the bq27000 informing the machine about the kobject 
(neo1973_set_battery_kobect(struct kobject*))?

Other ideas hints? We need this because we want to update the graphical 
charging indication immdiately (at least that is the bug QA filed on 
illume) :)

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

Yeah, it would require a manual merge but the same approach would work.


More information about the openmoko-kernel mailing list