Re: Should 9aafabc7fece be reverted?

["Andrew F. Davis" <afd@ti.com>]

On 05/19/2016 11:18 AM, Pali Rohár wrote:
> On Thursday 19 May 2016 18:11:14 Andrew F. Davis wrote:
>> On 05/19/2016 11:06 AM, Pali Rohár wrote:
>>> On Thursday 19 May 2016 17:57:34 Andrew F. Davis wrote:
>>>> On 05/19/2016 10:51 AM, Pali Rohár wrote:
>>>>> On Thursday 19 May 2016 17:48:29 Andrew F. Davis wrote:
>>>>>> On 05/19/2016 10:44 AM, Pali Rohár wrote:
>>>>>>> On Thursday 19 May 2016 17:38:14 Andrew F. Davis wrote:
>>>>>>>> P.S. The code is still a bit strange, I'll probably go grab
>>>>>>>> one of the N900s from our test farm and make sure my future
>>>>>>>> cleanups don't break this, but are we sure the *name* of a
>>>>>>>> driver is an ABI?
>>>>>>>
>>>>>>> It is not name of driver, but directory name of sysfs path
>>>>>>> where device is exported...
>>>>>>
>>>>>> Which is named after the drivers name, so the same question
>>>>>> remains.
>>>>>>
>>>>>> :/
>>>>>
>>>>> No, it is not driver name, but device name. That is different.
>>>>
>>>> My bad, that's what I meant, device names should be dynamic,
>>>> right? Relying on them being static in software would then be
>>>> buggy (like relying on eth0 being the right NIC everytime)?
>>>>
>>>> I'm not familiar with the N900 software, but IDR can give out
>>>> different numbers and may not always give the first battery #0 (it
>>>> does now but is that a guarantee in IDR?) and if not then what is
>>>> the userspace response to this changing?
>>>
>>> In case N900 would have more bq27xxx batteries, then yes. But N900
>>> has exactly *one* bq27200 battery, so there is no IDR problem.
>>
>> Right, but if IDR returns 42 instead of 0 would this then break its
>> userspace software?
> 
> 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".

> What I can say is that N900 charging software and other battery 
> applications stops working. And people who develop kernel for N900 
> starts to be angry, because without working battery charging it is not 
> possible to develop and fix other kernel bugs on device.
> 
>> How is this handled for other power-supply drivers when more that one
>> battery exists, they look to give static device names so I'm assuming
>> the framework handles giving them new folder names automatically.
> 
> N900 software can be happy that this problem does not happen... :-)
> 
> But basically in case there will be more batteries of same type, then it 
> depends if it is needed to distinguish between them or not. So this is 
> depends on exact situation and usage...
> 

I'll test this and see what happens, but I'm assuming there is a more
standard way to differentiate parts than appending a number to the
device name.