Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <bff9b95b-7a92-5229-855c-0972e38eb222@linaro.org>
Date:   Sat, 9 Apr 2022 15:01:25 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.7.0
Subject: Re: [PATCH 13/18] dt-bindings: fix jz4780-nemc issue as reported by
 dtbscheck
Content-Language: en-US
To:     Paul Cercueil <paul@crapouillou.net>
Cc:     "H. Nikolaus Schaller" <hns@goldelico.com>,
        Rob Herring <robh+dt@kernel.org>,
        Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
        linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
        linux-mips@vger.kernel.org, letux-kernel@openphoenux.org
References: <cover.1649443080.git.hns@goldelico.com>
 <84adfe6237cd4cfd52cb9723416f69926e556e55.1649443080.git.hns@goldelico.com>
 <036b66b2-c221-6e9e-6a56-510e7a0d20d3@linaro.org>
 <VDO2AR.XO9112UD3KYT3@crapouillou.net>
 <2e1495ab-2773-a3bb-0ad2-4af607cccc11@linaro.org>
 <O7P2AR.D8D4QSYF9P8E@crapouillou.net>
From:   Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
In-Reply-To: <O7P2AR.D8D4QSYF9P8E@crapouillou.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

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