From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 67034C433EF for ; Sat, 9 Apr 2022 13:01:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241147AbiDINDg (ORCPT ); Sat, 9 Apr 2022 09:03:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36238 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240199AbiDINDf (ORCPT ); Sat, 9 Apr 2022 09:03:35 -0400 Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E930C3D1F6 for ; Sat, 9 Apr 2022 06:01:27 -0700 (PDT) Received: by mail-ed1-x52a.google.com with SMTP id z99so4310737ede.5 for ; Sat, 09 Apr 2022 06:01:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=c9dM3853RnMFXxBz17KqwFXKDYGLlscOpcfs4FJdfuQ=; b=LWVdH3uG36OJu6zfwpvkQ2SDiedaK8SV5p22SMwUSqs/+bMmWey9Yy8KY032Ev9HjV Zg3p+3gn4h21XGfibpCDZaXgDQZ21MX3/dkYntudZPHMrdAWNrAu/xKig0HYAfuUhXEC ADsthBEnSHiGneX7/qKZp78xYZKXSxnDbtdRruRAnc+YmID/ALcQkPa19iL+8eVkYLkL TxWkEWZWVeuabTsGkl1logTyKyCTIdVv8Eq7JcvFQa7FvCVracdy23k8f9Pr6aBvmNST 4z81dnu49+6N7c9GROhvdlphf0pY/WeDRhDTpCirpxpzzA0RD8YIbzX4VMn4FRfluOYa DnGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=c9dM3853RnMFXxBz17KqwFXKDYGLlscOpcfs4FJdfuQ=; b=qTtYqg0hLQe8dQ6lW+zCMzyA7y2IJimgBKUG6494lbe4gIccW3YjkOgkZIzwgBA0KJ GuTsi9DxKI6fr6lS4NE0wyYZ46W3lt5XpVyk05bc+bR2Qv8kUlgyyF7d2TrNmo9Pp7iZ xA4Z8m9ttcAJF8djn7loQuG+Mv6ybSsXtj2rOPJX2MxRoAUFC/SxK3zAUXN7BBzj04yc 64/btzo07K/Dbik1IJ6op8q8N9bCeNHzyFXzNipQEdcyIJtK6ubnbxJW1zs0W00Y/G6a I6KNzGBAFWorwVS8e2tQ5ZxkY3JaxuQmB/L4kjOOP/FBf788xGkRFJaBvrh/DooR3xkj +7Tw== X-Gm-Message-State: AOAM533LGWae/iiDsreC1SlG8O2XY7cdpwQiocAXHSQR3gGYfcMcY7qw ch6g3ADC9tHtg/zshTg/BfA5eg== X-Google-Smtp-Source: ABdhPJz6VgeARo0M98zu/J/i+gEUu2WhD2bzJkY9CzUcO6xAjDrdkOP2Kd5xEhDGol+ZqT6u4pR6lw== X-Received: by 2002:a05:6402:42c6:b0:41c:defd:24d1 with SMTP id i6-20020a05640242c600b0041cdefd24d1mr24532402edc.326.1649509286375; Sat, 09 Apr 2022 06:01:26 -0700 (PDT) Received: from [192.168.0.188] (xdsl-188-155-201-27.adslplus.ch. [188.155.201.27]) by smtp.gmail.com with ESMTPSA id z2-20020a17090674c200b006e13403964asm9809747ejl.77.2022.04.09.06.01.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 09 Apr 2022 06:01:26 -0700 (PDT) Message-ID: 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 Cc: "H. Nikolaus Schaller" , Rob Herring , Thomas Bogendoerfer , linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-mips@vger.kernel.org, letux-kernel@openphoenux.org References: <84adfe6237cd4cfd52cb9723416f69926e556e55.1649443080.git.hns@goldelico.com> <036b66b2-c221-6e9e-6a56-510e7a0d20d3@linaro.org> <2e1495ab-2773-a3bb-0ad2-4af607cccc11@linaro.org> From: Krzysztof Kozlowski In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org 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