linux-kernel - Re: [PATCH 05/28] mfd: zl3073x: Add components versions register defs

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <5af77349-5a76-4557-839b-d9ac643f5368@kernel.org>
Date: Thu, 10 Apr 2025 09:11:36 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Ivan Vecera <ivecera@...hat.com>, Andrew Lunn <andrew@...n.ch>
Cc: netdev@...r.kernel.org, Michal Schmidt <mschmidt@...hat.com>,
 Vadim Fedorenko <vadim.fedorenko@...ux.dev>,
 Arkadiusz Kubalewski <arkadiusz.kubalewski@...el.com>,
 Jiri Pirko <jiri@...nulli.us>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Prathosh Satish <Prathosh.Satish@...rochip.com>,
 Lee Jones <lee@...nel.org>, Kees Cook <kees@...nel.org>,
 Andy Shevchenko <andy@...nel.org>, Andrew Morton
 <akpm@...ux-foundation.org>, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org
Subject: Re: [PATCH 05/28] mfd: zl3073x: Add components versions register defs

On 09/04/2025 08:44, Ivan Vecera wrote:
> On 07. 04. 25 11:09 odp., Andrew Lunn wrote:
>> On Mon, Apr 07, 2025 at 07:28:32PM +0200, Ivan Vecera wrote:
>>> Add register definitions for components versions and report them
>>> during probe.
>>>
>>> Reviewed-by: Michal Schmidt <mschmidt@...hat.com>
>>> Signed-off-by: Ivan Vecera <ivecera@...hat.com>
>>> ---
>>>   drivers/mfd/zl3073x-core.c | 35 +++++++++++++++++++++++++++++++++++
>>>   1 file changed, 35 insertions(+)
>>>
>>> diff --git a/drivers/mfd/zl3073x-core.c b/drivers/mfd/zl3073x-core.c
>>> index 39d4c8608a740..b3091b00cffa8 100644
>>> --- a/drivers/mfd/zl3073x-core.c
>>> +++ b/drivers/mfd/zl3073x-core.c
>>> @@ -1,10 +1,19 @@
>>>   // SPDX-License-Identifier: GPL-2.0-only
>>>   
>>> +#include <linux/bitfield.h>
>>>   #include <linux/module.h>
>>>   #include <linux/unaligned.h>
>>>   #include <net/devlink.h>
>>>   #include "zl3073x.h"
>>>   
>>> +/*
>>> + * Register Map Page 0, General
>>> + */
>>> +ZL3073X_REG16_DEF(id,			0x0001);
>>> +ZL3073X_REG16_DEF(revision,		0x0003);
>>> +ZL3073X_REG16_DEF(fw_ver,		0x0005);
>>> +ZL3073X_REG32_DEF(custom_config_ver,	0x0007);
>>> +
>>>   /*
>>>    * Regmap ranges
>>>    */
>>> @@ -159,10 +168,36 @@ EXPORT_SYMBOL_NS_GPL(zl3073x_dev_alloc, "ZL3073X");
>>>   
>>>   int zl3073x_dev_init(struct zl3073x_dev *zldev)
>>>   {
>>> +	u16 id, revision, fw_ver;
>>>   	struct devlink *devlink;
>>> +	u32 cfg_ver;
>>> +	int rc;
>>>   
>>>   	devm_mutex_init(zldev->dev, &zldev->lock);
>>>   
>>> +	scoped_guard(zl3073x, zldev) {
>>
>> Why the scoped_guard? The locking scheme you have seems very opaque.
> 
> We are read the HW registers in this block and the access is protected 
> by this device lock. Regmap locking will be disabled in v2 as this is 

Reading ID must be protected by mutex? Why and how?

What is a "device lock"?

> not sufficient.
> 
>>> +		rc = zl3073x_read_id(zldev, &id);
>>> +		if (rc)
>>> +			return rc;
>>> +		rc = zl3073x_read_revision(zldev, &revision);
>>> +		if (rc)
>>> +			return rc;
>>> +		rc = zl3073x_read_fw_ver(zldev, &fw_ver);
>>> +		if (rc)
>>> +			return rc;
>>> +		rc = zl3073x_read_custom_config_ver(zldev, &cfg_ver);
>>> +		if (rc)
>>> +			return rc;
>>
>> Could a parallel operation change the ID? Upgrade the firmware
>> version?
>>
>> 	Andrew
> 
> No, but register access functions require the device lock to be held. 
> See above.

Andrew comments stay valid here. This is weird need of locking and your
explanation is very vague.

BTW, do not send v2 before people respond to your comments in reasonable
time. You just send 28 patchset and expect people to finish review after
one day.

Best regards,
Krzysztof