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 5B881C433F5 for ; Tue, 5 Apr 2022 23:41:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1576781AbiDEXLC (ORCPT ); Tue, 5 Apr 2022 19:11:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60370 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1443622AbiDEPkA (ORCPT ); Tue, 5 Apr 2022 11:40:00 -0400 Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A4B8617DC89 for ; Tue, 5 Apr 2022 06:57:19 -0700 (PDT) Received: by mail-ej1-x632.google.com with SMTP id dr20so26756927ejc.6 for ; Tue, 05 Apr 2022 06:57:19 -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=IVfxiW6zKe0dHxT2NnEjml4pjCNh93EsN7m5exyESZw=; b=UXRyAeEeXf2x76rRsTVT85Yu3qMDdIO8T76/plyF2HR/xrK6SSH+NaRviJpVZh7Qwg sDlhRAI83MwCI3gbOLnBxOCANE1IcKQwEfrAwCIyDHAAtFq710fD+ZRlVWZv/xEqZlP2 2xaaXUL1FQTdhZiuvu+h3FVmKJ21wi4tSIvUxoAwP1nhl6vffFEzbfhRI4nAsZi2EVnd pMeyjuSEWFMQCRF/nJ7z/vfgUOwNgvH2iTxe8G1ZXH7d9W9pBEqLvYhucm/tg3XSPyUf uvwFMkqw+KsPAZDRjdA3KHBjqlNYwp3fE3vsEHxRyU2l/m40UVa6h2Ljee9euWBm9D1t GkIw== 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=IVfxiW6zKe0dHxT2NnEjml4pjCNh93EsN7m5exyESZw=; b=GYGSLcFFf3l0Bhu/MIfCpubGV2FbAsUYcGDrIoxLZ2pgHRGublOjxreXKkQSAUcgUp FH8pawcqf/p/p5BNCEHl2O86gY/Wzo/jJw31X8uuUHycmdzljitothwMx+8BtEMFnW1h x91eFBaeNT9GbqeRqn03zr5LyRoT9l2d4oMr5TErSXgDDadpYZXHr3utfXJtR9sJ+8Br l12hb/maJeSy1bftI/sZms+r2WNjr/QWK4AbxKxqkmCIC+ElkxEKD7RhbJGSNl9rF0kz FgCy6x5baR1R9nA/S2LLjZwLx8DPizVP+7NazUNuK9Q0984kb27kSpPEGOrr+C2jplxi auig== X-Gm-Message-State: AOAM531tOBssGJo4MJJCPnQTPVhDUwXG+SyaJr78iZH2Bxc7BdJ3cCB2 FnFS1dkODPO4zUQaMt034zc2aFqt4m1bFkqq X-Google-Smtp-Source: ABdhPJzrbED2j3hKopCA4gDE01wRh9WEQTM3OOohAmICtp6UQWRL7za5ii7DlT49Qvcs5o0Kwd6rww== X-Received: by 2002:a17:906:3ad3:b0:6cd:382b:86e5 with SMTP id z19-20020a1709063ad300b006cd382b86e5mr3579318ejd.145.1649167038173; Tue, 05 Apr 2022 06:57:18 -0700 (PDT) Received: from [192.168.0.182] (xdsl-188-155-201-27.adslplus.ch. [188.155.201.27]) by smtp.gmail.com with ESMTPSA id v20-20020a056402349400b00419651e513asm6776474edc.45.2022.04.05.06.57.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Apr 2022 06:57:17 -0700 (PDT) Message-ID: Date: Tue, 5 Apr 2022 15:57:16 +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 1/2] i2c: add binding to prevent device detection Content-Language: en-US To: Vincent Whitchurch , wsa@kernel.org Cc: kernel@axis.com, linux-i2c@vger.kernel.org, devicetree@vger.kernel.org, krzk+dt@kernel.org, robh+dt@kernel.org, linux-kernel@vger.kernel.org References: <20220405121627.1560949-1-vincent.whitchurch@axis.com> <20220405121627.1560949-2-vincent.whitchurch@axis.com> From: Krzysztof Kozlowski In-Reply-To: <20220405121627.1560949-2-vincent.whitchurch@axis.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/04/2022 14:16, Vincent Whitchurch wrote: > When drivers with ->detect callbacks are loaded, the I2C core does a > bunch of transactions to try to probe for these devices, regardless of > whether they are specified in the devicetree or not. (This only happens > on I2C controllers whose drivers enable the I2C_CLASS* flags, but this > is the case for generic drivers like i2c-gpio.) > Thank you for your patch. There is something to discuss/improve. > These kinds of transactions are unnecessary on systems where the > devicetree specifies all the devices on the I2C bus, so add a property > to allow them to be disabled. > > Signed-off-by: Vincent Whitchurch > --- > Documentation/devicetree/bindings/i2c/i2c.txt | 4 ++++ Use the subject matching the subsystem (git log --oneline -- .......). > 1 file changed, 4 insertions(+) > > diff --git a/Documentation/devicetree/bindings/i2c/i2c.txt b/Documentation/devicetree/bindings/i2c/i2c.txt > index fc3dd7ec0445..5f7bdf4851e8 100644 > --- a/Documentation/devicetree/bindings/i2c/i2c.txt > +++ b/Documentation/devicetree/bindings/i2c/i2c.txt > @@ -72,6 +72,10 @@ wants to support one of the below features, it should adapt these bindings. > this information to adapt power management to keep the arbitration awake > all the time, for example. Can not be combined with 'single-master'. > > +- no-detect > + states that the system should not attempt to automatically detect > + devices which are not explicitly specified as child nodes. Focus on the hardware, not on system and behavior. The hardware property is that bus is completely described in Devicetree or detection does not work correctly. I guess the property name could stay like this, but the description could be rephrased. Best regards, Krzysztof