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

Andy Green andy at openmoko.com
Tue Jun 3 13:33:51 CEST 2008

Hash: SHA1

Somebody in the thread at some point said:

|> 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
| entry of uevent.

So your goal there is really just to push "I am being charged"
notifications into the battery kobject?

| 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
| 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
| (neo1973_set_battery_kobect(struct kobject*))?

If it's just "I am being charged" appearing in battery uevent context
that you are basically thinking about, why not export a bq27000 API that
is just charger_state_change(int) and bq27000 privately makes his own
events on his private kobject in there.  You call charger_state_change()
then from platform callback from pcf50633 charger event actions.

It's always legitimate that an external charger would be associated with
bq27000 so this is a feature rather than a workaround.

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

OK, maybe I can take care of that when we get to the bottom of this

- -Andy

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


More information about the openmoko-kernel mailing list