Re: Should 9aafabc7fece be reverted?

["Pali Rohár" <pali.rohar@gmail.com>]

On Friday 20 May 2016 11:34:32 Pavel Machek wrote:
> Hi!
> 
> > > I think it is insane to starts generating random numbers for IDR... Hard 
> > > to decide what happen if such situation occur...
> > > 
> > 
> > That's kind of what I'm looking for though, if the userspace break is
> > caused by software relying on the battery to be named "bq27200-0", then
> > nothing short of hard-coding this exact name will 100% safely fix the
> > N900 userspace software. And so using IDR and hoping it gives 0 is just
> > a hacky work-around way of just naming the device "bq27200-0".
> 
> BTW proposals how to fix that userspace would be welcome.
> 
> We have three "power supplies", but userspace does not know how they
> are connecting, resulting in strange results. For now, I have
> hardware-specific layer in userspace.
> 
> https://gitlab.com/tui/tui/blob/master/ofone/hardware.py
> 
> Kernel does not really give me other choice.

I have in my mind idea of "merged" power supply devices.

For Nokia N900 we have:
* bq27200 monitoring chip
* bq24150a charging chip
* isp1707 usb phy chargin chip (wallcharger detection + enable gpio)
* rx51_battery driver (export ADC values from battery pins: temperature + design capacity)

And each part export own power supply device in /sys/class/power_supply/
So there are 4 power supply devices!

In ideal world kernel should provide into userspace just two devices:
* power supply charger device (merged values from isp1707 and bq24150a)
* power supply battery device (merged values from rx51_battery and bq27200)

Problem is that e.g. design capacity value provide both drivers. But
bq27xxx just return constant and incorrect value from bq eeprom. Correct
design capacity return only rx51_battery (which read it via ADC, third
battery pin).

That should fix detection and discovery problem. On Nokia N900 there is
just one battery and one charger device.

-- 
Pali Rohár
pali.rohar@gmail.com