linux-kernel - Re: [PATCH 13/18] dt-bindings: fix jz4780-nemc issue as reported by dtbscheck

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: <bff9b95b-7a92-5229-855c-0972e38eb222@linaro.org>
Date:   Sat, 9 Apr 2022 15:01:25 +0200
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Paul Cercueil <paul@...pouillou.net>
Cc:     "H. Nikolaus Schaller" <hns@...delico.com>,
        Rob Herring <robh+dt@...nel.org>,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
        linux-mips@...r.kernel.org, letux-kernel@...nphoenux.org
Subject: Re: [PATCH 13/18] dt-bindings: fix jz4780-nemc issue as reported by
 dtbscheck

On 09/04/2022 14:55, Paul Cercueil wrote:
>>
>> I saw the efuse children and that's why I asked who is expected to
>> populate them. You said that simple-mfd is required for this, I say 
>> no.
>> It should work without simple-mfd...
>>
>> I am kind of repeating myself but I really do not see the need of
>> simple-mfd in the bindings.
> 
> Well, it is a "simple MFD",

It's not a simple MFD, it is a memory controller. MFD is a purely
Linux/software term, so there are no devices which are MFD. Everything
which we model as MFD is actually something else in real life (e.g.
PMIC, memory controller, system controller).

> so I don't see why we can't use the 
> "simple-mfd" compatible. Why would we not want to use it?

No one said that you cannot. You just might not need...

> 
> Besides, if the nemc driver is responsible for populating the efuse 
> device, that means the nemc driver must be enabled for the efuse to 
> work, which is nonsense, the two IP blocks being unrelated.

That's actually the explanation I was looking for. It would be nice to
use it in commit msg instead of the dtbs_check warning.


Best regards,
Krzysztof