From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Andrew F. Davis" Subject: Re: Should 9aafabc7fece be reverted? Date: Thu, 19 May 2016 11:46:55 -0500 Message-ID: <573DEDFF.8060305@ti.com> References: <573C9F45.5090109@ti.com> <201605191806.50809@pali> <573DE5A2.7070900@ti.com> <201605191818.20237@pali> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Received: from bear.ext.ti.com ([198.47.19.11]:58533 "EHLO bear.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753865AbcESQr2 (ORCPT ); Thu, 19 May 2016 12:47:28 -0400 In-Reply-To: <201605191818.20237@pali> Sender: linux-pm-owner@vger.kernel.org List-Id: linux-pm@vger.kernel.org To: =?UTF-8?Q?Pali_Roh=c3=a1r?= Cc: Ivaylo Dimitrov , Sebastian Reichel , Dmitry Eremin-Solenikov , David Woodhouse , linux-pm@vger.kernel.org, Pavel Machek On 05/19/2016 11:18 AM, Pali Roh=C3=A1r wrote: > On Thursday 19 May 2016 18:11:14 Andrew F. Davis wrote: >> On 05/19/2016 11:06 AM, Pali Roh=C3=A1r wrote: >>> On Thursday 19 May 2016 17:57:34 Andrew F. Davis wrote: >>>> On 05/19/2016 10:51 AM, Pali Roh=C3=A1r wrote: >>>>> On Thursday 19 May 2016 17:48:29 Andrew F. Davis wrote: >>>>>> On 05/19/2016 10:44 AM, Pali Roh=C3=A1r 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? >=20 > I think it is insane to starts generating random numbers for IDR... H= ard=20 > to decide what happen if such situation occur... >=20 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=20 > applications stops working. And people who develop kernel for N900=20 > starts to be angry, because without working battery charging it is no= t=20 > possible to develop and fix other kernel bugs on device. >=20 >> How is this handled for other power-supply drivers when more that on= e >> battery exists, they look to give static device names so I'm assumin= g >> the framework handles giving them new folder names automatically. >=20 > N900 software can be happy that this problem does not happen... :-) >=20 > But basically in case there will be more batteries of same type, then= it=20 > depends if it is needed to distinguish between them or not. So this i= s=20 > depends on exact situation and usage... >=20 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.