Re: [PATCH] regulator: core: use regulator name for sysfs

[Stephen Warren]

On 02/21/2013 12:43 PM, Mark Brown wrote:
> On Thu, Feb 21, 2013 at 12:24:04PM -0700, Stephen Warren wrote:
>> On 02/21/2013 12:53 AM, Shawn Joo wrote:
> 
>>> regulator is named by numbering on sysfs, e.g. regulator.0,
>>> regulator.1 it confuses to find desired regulator before
>>> counting the order. add option for regulator name by
>>> use_name_onsysfs. if it is true and name is not NULL, desc's
>>> name will be the name. e.g. if name in desc is "LDO0", then
>>> regulator.LDO0 on sysfs. otherwise it follows origin.
> 
>> Does it make sense to make this change always, rather than based
>> on some new flag in regulator_desc?
> 
> It's certainly insane to change this based on the driver and given
> that sysfs is supposed to be an ABI it's questionable if we should
> do it at all.  We certainly can't use the descriptor name as that's
> very likely to clash if you have more than one PMIC.  Taking a
> glance through sysfs on my system what we're doing at the minute is
> pretty idiomatic, sysfs isn't really intended for humans but rather
> for machines to prettify.

Does the ABI describe just the layout of the sysfs filesystem, or also
the names of instances? Certainly the list of names of regulators
won't be in any ABI documentation. That said, I suppose for existing
platforms it'd probably be legitimate for someone to have looked there
and seen the names and assumed they would never change on that
particular platform, so changing them would break an implicit ABI.

>> Another place a similar change might be useful is debugfs.
> 
> debugfs already uses more human readable names, it uses the supply
> name (which is what we should be using if we were going to do
> anything as it really ought to be unique already).

Oh so it does. Was this a recent change? I could have sworn I saw lots
of regulator.n there, but perhaps I'm remembering sysfs.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/