Hi, Am 02.06.2015 um 22:11 schrieb Pavel Machek <pavel@xxxxxx>: > On Tue 2015-06-02 16:06:47, Dr. H. Nikolaus Schaller wrote: >> Hi, >> >> Am 02.06.2015 um 15:49 schrieb Kishon Vijay Abraham I <kishon@xxxxxx>: >> >>> Hi, >>> >>> On Tuesday 02 June 2015 03:07 AM, NeilBrown wrote: >>>> On Mon, 1 Jun 2015 19:06:52 +0530 Kishon Vijay Abraham I <kishon@xxxxxx> >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> On Thursday 16 April 2015 01:33 PM, NeilBrown wrote: >>>>>> From: NeilBrown <neilb@xxxxxxx> >>>>>> >>>>>> The twl4030 phy can measure, with low precision, the >>>>>> resistance-to-ground of the ID pin. >>>>>> >>>>>> Add a function to read the value, and export the result >>>>>> via sysfs. >>>>> >>>>> Little sceptical about adding new sysfs entries. Do you have a good reason to >>>>> add this? >>>> >>>> The hardware can report the value, so why not present it to user-space? >>>> >>>> I originally used this with a udev rule which would configure the maximum >>>> current based on the resistance measure - to work with the particular charger >>>> hardware I have. >>>> >>>> More recent patches try to do all of the max-current configuration in the >>>> kernel, so I could live without exporting the value via sysfs if that is a >>>> show-stopper. >>>> >>>> I can't see where the scepticism comes from though. It is a well defined >>>> and cleary documented feature of the hardware. Why not expose it? > > Is it well defined enough that it will work on other chargers, too? It reports the resistance of the charger’s ID pin. So that works for all chargers connected to a twl4030. As long as the ID pin goes to a 5 pin USB socket. Other charger drivers do not need to expose a similar attribute since each twl4030 has its unique path within the /sys tree. > >>> ABI can never be removed or modified later. So should be really careful before adding it. >> >> Is /sys considered ABI? > > Yes. You are right: https://lwn.net/Articles/172986/ But I am as well with my doubts: https://lwn.net/Articles/173093/ > >> User space developers are always reminded not to rely on /sys nodes. > > No. Then please explain why I have the impression that it is quite unstable. BR, Nikolaus -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
