linux-kernel - Re: [PATCH v5 1/1] hwmon: Add driver for Astera Labs PT5161L retimer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Tue, 6 Feb 2024 07:19:16 -0800
From: Guenter Roeck <linux@...ck-us.net>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc: Cosmo Chou <chou.cosmo@...il.com>, robh+dt@...nel.org,
 krzysztof.kozlowski+dt@...aro.org, conor+dt@...nel.org, jdelvare@...e.com,
 corbet@....net, broonie@...nel.org, naresh.solanki@...ements.com,
 vincent@...emblay.dev, patrick.rudolph@...ements.com,
 luca.ceresoli@...tlin.com, bhelgaas@...gle.com, festevam@...x.de,
 alexander.stein@...tq-group.com, heiko@...ech.de, jernej.skrabec@...il.com,
 macromorgan@...mail.com, forbidden405@...mail.com, sre@...nel.org,
 linus.walleij@...aro.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-hwmon@...r.kernel.org,
 linux-doc@...r.kernel.org, cosmo.chou@...ntatw.com
Subject: Re: [PATCH v5 1/1] hwmon: Add driver for Astera Labs PT5161L retimer

On 2/5/24 23:33, Krzysztof Kozlowski wrote:
> On 05/02/2024 17:15, Guenter Roeck wrote:
>> On Mon, Feb 05, 2024 at 04:26:08PM +0100, Krzysztof Kozlowski wrote:
>>> On 05/02/2024 16:20, Cosmo Chou wrote:
>>>> This driver implements support for temperature monitoring of Astera Labs
>>>> PT5161L series PCIe retimer chips.
>>>>
>>>> This driver implementation originates from the CSDK available at
>>>> Link: https://github.com/facebook/openbmc/tree/helium/common/recipes-lib/retimer-v2.14
>>>> The communication protocol utilized is based on the I2C/SMBus standard.
>>>>
>>>> Signed-off-by: Cosmo Chou <chou.cosmo@...il.com>
>>>> ---
>> [ ... ]
>>
>>>> +
>>>> +static int __init pt5161l_init(void)
>>>> +{
>>>> +	pt5161l_debugfs_dir = debugfs_create_dir("pt5161l", NULL);
>>>
>>> Drivers don't need initcalls. For sure any debugfs should not be handled
>>> here but in probe.
>>>
>>
>> Lots of hwmon drivers have init functions, for basic chip detection of
>> Super-I/O chips (example: drivers/hwmon/nct6775-platform.c) and to create
>> a parent debugfs subdirectory for the driver. The probe function then adds
>> subdirecties per chip instantiation. Example for pmbus, in
>> drivers/hwmon/pmbus/pmbus_core.c:
> 
> Core bus components are a bit different...
> 
>>
>> static int __init pmbus_core_init(void)
>> {
>>          pmbus_debugfs_dir = debugfs_create_dir("pmbus", NULL);
>>          if (IS_ERR(pmbus_debugfs_dir))
>>                  pmbus_debugfs_dir = NULL;
>>
>>          return 0;
>> }
>>
>> static void __exit pmbus_core_exit(void)
>> {
>>          debugfs_remove_recursive(pmbus_debugfs_dir);
>> }
>>
>> Are you saying this is all wrong ? What alternative would you suggest ?
> 
> Just create parent directory in probe and only keep remove in __exit.
> But you are right that might not be much better approach.
> 

That would just add more code and increase complexity since it would require
a mutex to protect against parallel probes. On the plus side, it would only
create the driver root directory if necessary, that is, if there is an
actual device. I am not sure if that would be worth the increased complexity.

That makes me wonder, though, if an API function such as
	struct dentry *hwmon_debugfs_get_root(char *name);
would make sense. That would move the complexity to the hwmon core and
unify its handling. I'll think about that. For the time being, I'll
accept the code as-is.

Thanks,
Guenter