linux-kernel - Re: [PATCH 2/2] regulator: max20339: add Maxim MAX20339 regulator driver

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: <a2193800-69ea-4909-ba8b-05b85915ae6a@kernel.org>
Date: Tue, 17 Sep 2024 10:15:04 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: André Draszik <andre.draszik@...aro.org>,
 Liam Girdwood <lgirdwood@...il.com>, Mark Brown <broonie@...nel.org>,
 Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, Michael Walle <mwalle@...nel.org>
Cc: Peter Griffin <peter.griffin@...aro.org>,
 Tudor Ambarus <tudor.ambarus@...aro.org>,
 Will McVicker <willmcvicker@...gle.com>, kernel-team@...roid.com,
 linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH 2/2] regulator: max20339: add Maxim MAX20339 regulator
 driver

On 17/09/2024 10:03, André Draszik wrote:
>>> +}
>>> +
>>> +static int max20339_lsw_dt_parse(struct device_node *np,
>>> +				 const struct regulator_desc *desc,
>>> +				 struct regulator_config *cfg)
>>> +{
>>> +	struct max20339_regulator *data = cfg->driver_data;
>>> +
>>> +	/* we turn missing properties into a fatal issue during probe() */
>>
>> Your binding does not look in sync with above.
> 
> Do you mean it doesn't enforce existence of this property? (It does and
> binding check appropriately complains if it's missing). Otherwise, can
> you please point me to the problem you're seeing?

Indeed, it's in the subnode. It's fine.

> 
> From the binding:
> 
> +properties:
> +  [...]
> +  regulators:
> +    type: object
> +    [...]
> +    patternProperties:
> +      "^lsw[12]$":
> +        [...]
> +        properties:
> +          [...]
> +          shunt-resistor-micro-ohms:
> +            [...]
> +        required:
> +          - shunt-resistor-micro-ohms
> +
> +        unevaluatedProperties: false
> +
> +    required:
> +      - lsw1
> +      - lsw2
> +
> +    additionalProperties: false
> +
> +[...]
> +
> +required:
> +  [...]
> +  - regulators
> 
> Anything wrong or missing in the above?
> 
>>> [...]
>>> +	},                                                        \
>>> +	.ovp_mask = _ovp_mask,                                    \
>>> +	.status_reg = _status_reg,                                \
>>> +}
>>> +
>>> +
>>
>> Here and in few other places - just one blank line.
> 
> OK.
> 
>>> +static struct max20339_regulator max20339_regulators[MAX20339_N_REGULATORS] = {
>>
>> This can be const and then use container_of instead of rdev_get_drvdata().
>>
>> See:
>> https://lore.kernel.org/all/20240909-regulator-const-v1-17-8934704a5787@linaro.org/
> 
> Thanks!
> 
>> [...]
>>> +
>>> +	irq_flags = IRQF_ONESHOT | IRQF_SHARED;
>>
>> Why shared?
> 
> Just to be nice in case somebody puts it on a shared line. Not actually
> required in my case.
> 
>>> +	irq_flags |= irqd_get_trigger_type(irq_get_irq_data(client->irq));
>>> +
>>> +	ret = devm_request_threaded_irq(&client->dev, client->irq,
>>
>> Shared interrupts should not be devm. It leads to tricky cases during
>> removal. If you investigated the code and you are 100% sure there is no
>> issue, please write a short comment in the code confirming that. Or just
>> don't use devm.
> 
> I wasn't aware of this, thanks. I'll drop the shared and somebody can
> revisit it in the future if required. BTW, a naive grep returned +400
> drivers that use shared together with devm.

Yeah, I was once thinking to check them, because there is an easy hint
problems are possible: if driver has remove() callback which does
anything with resources. However even if driver code looks unsafe, it
requires quite some time to figure out if the issue is real - need to
find other driver who will trigger the interrupt afterwards.

You can BTW test it with CONFIG_DEBUG_SHIRQ + bind/unbind.

Maybe we need some more explicit documentation around devm() or IRQF_SHARED.

Best regards,
Krzysztof