Re: Should 9aafabc7fece be reverted?

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

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?

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.