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 F2508C433F5 for ; Wed, 18 May 2022 16:26:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240154AbiERQ0l (ORCPT ); Wed, 18 May 2022 12:26:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37174 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240118AbiERQ0K (ORCPT ); Wed, 18 May 2022 12:26:10 -0400 X-Greylist: delayed 965 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Wed, 18 May 2022 09:26:05 PDT Received: from hostingweb31-40.netsons.net (hostingweb31-40.netsons.net [89.40.174.40]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C6D8A1D0E6; Wed, 18 May 2022 09:26:04 -0700 (PDT) Received: from [77.244.183.192] (port=64666 helo=[192.168.178.75]) by hostingweb31.netsons.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1nrMFJ-000DgX-8b; Wed, 18 May 2022 18:09:57 +0200 Message-ID: <806462b6-e85e-f5e8-9ffb-cffa5dae72c2@lucaceresoli.net> Date: Wed, 18 May 2022 18:09:55 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: [PATCH v2 1/2] dt-bindings: i2c: add property to avoid device detection Content-Language: en-US To: Peter Rosin , Wolfram Sang , Vincent Whitchurch , 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: <20220412085046.1110127-1-vincent.whitchurch@axis.com> <20220412085046.1110127-2-vincent.whitchurch@axis.com> <7ab1f387-3670-4b49-211d-3ff9a7c3d40b@axentia.se> <758ebcab-b0a2-29bd-d79c-1fbdc95212ae@axentia.se> From: Luca Ceresoli In-Reply-To: <758ebcab-b0a2-29bd-d79c-1fbdc95212ae@axentia.se> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hostingweb31.netsons.net X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lucaceresoli.net X-Get-Message-Sender-Via: hostingweb31.netsons.net: authenticated_id: luca@lucaceresoli.net X-Authenticated-Sender: hostingweb31.netsons.net: luca@lucaceresoli.net X-Source: X-Source-Args: X-Source-Dir: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Peter, all, On 16/05/22 10:07, Peter Rosin wrote: > [Now with the proper email to Luca, sorry about that...] > > 2022-05-16 at 09:57, Peter Rosin wrote: >> 2022-05-14 at 16:26, Wolfram Sang wrote: >>> On Tue, Apr 12, 2022 at 10:50:45AM +0200, 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.) >>>> >>>> These kinds of transactions are unnecessary on systems where the >>>> devicetree specifies all the devices on the I2C bus, so add a property >>>> to indicate that the devicetree description of the hardware is complete >>>> and thus allow this discovery to be disabled. >>> Hmm, I don't think the name is fitting. "no-detect" is the desired >>> behaviour but a proper description is more like "bus-complete" or >>> something? >>> >>> That aside, I am not sure we should handle this at DT level. Maybe we >>> should better change the GPIO driver to not populate a class if we have >>> a firmware node? >> We also have the somewhat related address translation case (which I >> still need to look at). [Adding Luca to Cc] >> >> https://lore.kernel.org/lkml/20220206115939.3091265-1-luca@lucaceresoli.net/ >> >> If a bus is "bus-complete", then address translation could use >> any unused address instead of from an explicit list of addresses. >> I.e. the "i2c-alias-pool" in the binding in patch 4/6 of that >> series could be made optional if the bus is "bus-complete". Indeed the alias pool is meant to completely disappear from the ATR implementation. The i2c core should evolve to know which addresses correspond to a device (no matter if it has a driver or not) and use any other addresses as aliases. This was the outcome of discussion on this topic with Wolfram, even though I AFAIK any implementation effort is idle since a long time. -- Luca