On 10/1/20 11:51 AM, Stephen Boyd wrote:
> Quoting Mark Brown (2020-10-01 10:43:26)
>> On Wed, Sep 30, 2020 at 05:07:20PM -0700, Stephen Boyd wrote:
>>> Quoting David Collins (2020-09-22 15:04:18)
>>
>>>> This helps to disambiguate SPMI device regmaps from I2C ones
>>>> at /sys/kernel/debug/regmap since I2C devices use a very
>>>> similar naming scheme: 0-0000.
>>
>>> Can regmap debugfs prepend the bus name on the node made in debugfs?
>>> Does it do that already?
>>
>> It doesn't do that.  I have to say that given the use of dev_name() in
>> logging it does feel like it'd be useful to have distinct names for
>> grepping if we're running into collisions, IIRC the reason I went with
>> dev_name() was that it's a commonly used human readable handle for
>> diagnostic infrastrucuture so it makes it easier to follow things around.
> 
> To me the dev_name() usage seems fine. Maybe David has some real reason
> to change this though?
> 
> In general I don't think userspace cares what the SPMI device name is,
> i.e. the device name isn't used for dev nodes because SPMI doesn't
> support ioctls or read/write APIs on the bus. That could be a nice
> feature addition though, to support something like i2c-dev.
> 
> Changing it so that regmap debugfs is less likely to collide looks
> weird. It doesn't actually collide anyway, so it seems like we're adding
> spmi prefix to make it easier to find in debugfs?

Yes, that is correct.  There isn't a collision since I2C uses 0-0000 and
SPMI uses 0-00 naming scheme.  However, those names are very similar and
it is hard for a user to tell which is which inside
/sys/kernel/debug/regmap without a deep understanding of the I2C and SPMI
code.

The SPMI regmap debugfs files are used extensively for testing and debug
purposes internally at Qualcomm and by our customers.  It would be helpful
if the more verbose naming scheme were accepted upstream to avoid
confusion and broken test scripts.

Thanks,
David

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Reply via email to