-----BEGIN PGP SIGNED MESSAGE----- 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 sysfs | 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 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*))? 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 patchset. - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkhFLB8ACgkQOjLpvpq7dMoZQgCgilR3OWBAGpd9WN+44rOKZ7MH cz0AnirDhKC7hG2xhvu9Qk7tqSt7Xv0t =Ww5X -----END PGP SIGNATURE-----
