linux-kernel - Re: [PATCH v2] nvmem: core: don't consider subnodes not matching binding

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: <4e861088-c17d-0eca-6efa-c50b55fdecd1@pengutronix.de>
Date:   Wed, 15 Apr 2020 10:05:13 +0200
From:   Ahmad Fatoum <a.fatoum@...gutronix.de>
To:     Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
Cc:     devicetree@...r.kernel.org, Christian Eggers <CEggers@...i.de>,
        linux-kernel@...r.kernel.org, kernel@...gutronix.de
Subject: Re: [PATCH v2] nvmem: core: don't consider subnodes not matching
 binding

On 4/6/20 4:20 PM, Ahmad Fatoum wrote:
> Hello,
> 
> On 4/6/20 2:33 PM, Srinivas Kandagatla wrote:
>>
>>
>> On 23/03/2020 15:28, Ahmad Fatoum wrote:
>>> The nvmem cell binding applies to objects which match "^.*@[0-9a-f]+$",
>>> but so far the driver has matched all objects and failed if they didn't
>>> have the expected properties.
>>>
>>> The driver's behavior in this regard precludes future extension of
>>> EEPROMs by child nodes other than nvmem and clashes with the barebox
>>> bootloader binding that extends the fixed-partitions MTD binding to
>>> EEPROMs as it tries to interpret the "fixed-partitions"-compatible
>>> partitions node as a nvmem cell.
>>>
>>> Solve this issue by skipping all subnodes that don't contain an @.
>>>
>>> This still allows for cell names like `partitions@0,0', but this
>> NACK.. thats nasty hack!
>> Its standard practice as per device tree specs to have nodes name as "node-name@...t-address"
>>
>> Ref: https://github.com/devicetree-org/devicetree-specification/releases/download/v0.3/devicetree-specification-v0.3.pdf
> 
> I didn't say otherwise. I just argued if we verify there's a @ symbol in the
> node name, before considering whether it is a NVMEM cell, we will skip fixed-partitions
> while adhering to the NVMEM cell binding.
> 
>>> is much less likely to cause future collisions.
>>
>> There have been discussions on this topic in the past at:
>>
>> https://patchwork.ozlabs.org/patch/890741/
>>
>> We need to come up with a better solution!
> 
> Thanks for the link, I didn't find it when I searched whether this has
> come up before.
> 
> As you probably noticed, your suggested approach there wouldn't work for me though,
> because this time it can't be worked around in the MTD driver.
> If the suggestion here is not palatable, how do you think about (in
> my preferred order):
> 
> - If the cell has a compatible node, it must be "nvmem-cell".
>   Otherwise, a cell with a compatible node is skipped.
> 
> - Adding a nvmem cell container with a compatible and making support for
>   the old binding configurable
> 
> - Skipping cells that are malformed and lack a reg = < > property _without_
>   error

gentle ping. I can prepare another patch if you indicate which approach
you'd prefer.

> 
> Cheers
> Ahmad
> 
>>
>> --srini
>>
>>>
>>> Signed-off-by: Ahmad Fatoum <a.fatoum@...gutronix.de>
>>> ---
>>> v1 -> v2:
>>>    use ->full_name instead of ->name as to not break existing correct
>>>    cells (Christian)
>>> ---
>>>   drivers/nvmem/core.c | 2 ++
>>>   1 file changed, 2 insertions(+)
>>>
>>> diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
>>> index ef326f243f36..f051051fb1a8 100644
>>> --- a/drivers/nvmem/core.c
>>> +++ b/drivers/nvmem/core.c
>>> @@ -278,6 +278,8 @@ static int nvmem_add_cells_from_of(struct nvmem_device *nvmem)
>>>       parent = dev->of_node;
>>>         for_each_child_of_node(parent, child) {
>>> +        if (!strchr(kbasename(child->full_name), '@'))
>>> +            continue;
>>>           addr = of_get_property(child, "reg", &len);
>>>           if (!addr || (len < 2 * sizeof(u32))) {
>>>               dev_err(dev, "nvmem: invalid reg on %pOF\n", child);
>>>
>>
> 

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |