Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp141342pxb; Wed, 6 Oct 2021 01:31:18 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwC1oGq7Gs8XVPdxi5J7t4og7ABCk/71GKDBly7r9Ve2L6i9rz7Ly7u6ANZzlUFI2qFbPMC X-Received: by 2002:a17:906:32d6:: with SMTP id k22mr30600686ejk.228.1633509077999; Wed, 06 Oct 2021 01:31:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633509077; cv=none; d=google.com; s=arc-20160816; b=hBYSI8zHQY+GFSLtoQH0+aMB2NhhZ/tJp8IGRHphF7gYJ5/uHRY+uy5ZDqpD09bd37 CzySc7jgzJDYrNOUpUvkgC78PrnB+HiDwkgYZ3T5/aRQdHQim8c875NF95bFkuaLyVL0 M5d4WiPXQRl7KwByFrtR//9VS2J04LUrXyGmLY9Nd3viEvWOQhu1TZg+Ufku7ORMQFH1 /EEm+DoN4WVCKax0nXMfVTPOKCXlqd3jVlKclIS4OudVgknxTDqJNvP0wKkniJ6/bbIC dCt0pA1BzYXeI3et9Tdao85/Z+mnimG1kuWn+hb4JIZkozX0oN6jesY/oihJ/Ym41vRj gdJg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=Cs32oKjPY880HhRcpboK0pON5dPQmpZCrv3AmYoudi4=; b=VacQ0iPhhbZfbuPCVUT7q1NBKNYKs7J0JKrCJmYfBrTWeMgmyb2ScVy8v9wGcu3j3f T89DOVl1wzYoAGz4ByD4Bm1sm328yRa6ZB2sNCp8wVzJBjcnQTXYYzHCKkVtAUBy40J1 x/o2iCiCOoM7h/cKyOZ5N3uwOPlondUvlrc3h59gJA0lwKi5Wqh6BxZVubBb9hA+lraN jlisouQGXuHagG8kdQX/3c22dkPs1jg2mcrJgalsWsvDwNxbSFqgNuJXLXTGGQPKhBlo +yPe85fWyk6no6qYqeodhRCqk7LJmCpV1PEB1Itx4HiA+27xr7h9ecJewnqhPB2/BAj/ SU9g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@semihalf-com.20210112.gappssmtp.com header.s=20210112 header.b=Y7jduTBL; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x8si22514650edd.324.2021.10.06.01.30.52; Wed, 06 Oct 2021 01:31:17 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@semihalf-com.20210112.gappssmtp.com header.s=20210112 header.b=Y7jduTBL; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237728AbhJFIbL (ORCPT + 99 others); Wed, 6 Oct 2021 04:31:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38506 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237653AbhJFIbK (ORCPT ); Wed, 6 Oct 2021 04:31:10 -0400 Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E61C4C061749 for ; Wed, 6 Oct 2021 01:29:18 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id r19so6981431lfe.10 for ; Wed, 06 Oct 2021 01:29:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Cs32oKjPY880HhRcpboK0pON5dPQmpZCrv3AmYoudi4=; b=Y7jduTBLBpq47YNLGK+8Fs1peBjDqtnqaIvJ71rnYHl2LKlBGz14YVXsbSX59h/7Y1 Mpy86aVzDlMC7vyhQDY0ggy1MsBXlPo/Ri//HkNUdIFfOGLV40yK1Trpb03j940CkDcv aAi/bqPh8x4BcyfK9LhFAKp78v/GNsJe/AjNjzTLXl5ez3JblOovjZ2YaxpfDaASzd7K kimrxEauFPfupzQ6Nknzw562FDT0tk6D8TVLUU5SA23Moj0PXlw0yo3uP2eWMEzUUkHm GFjDlEiJHZj48oW2v7cLjvTKto/78fzY5Td0AE8ohTmVRtoxxTZux0z8S0solecVTL/f UYZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Cs32oKjPY880HhRcpboK0pON5dPQmpZCrv3AmYoudi4=; b=DUyQKF0MWlQRZxmaOZZ8Ockc0tK4GJs7U8G9BxmFugkgZZn299mpffpdvExCIAw2UG deo1JwcKqESGP5MJ3Nft+5Jj7WpNildeBIxPZBGZLQvhngS499jCkT3qFYg1D1TO7gaP KlpnkDs4fu/8ZWy4/Lzfg60Qo066ur1wklC75uBdKh+njvh3kk4cHBIJdn8vX9j1yyhz 0ve/2lXq/iNcdtn4rm3n9eaKZjxNxC0hHLBK9gux29IX/OLoLzhGlfRT5CO1+TFBgwlR QG8jAwXwyVA/ATJB2i/u95yv7j2ORO9PD/jsZID6FIKV4QcFD/EpyKzWODKnltVLDKc0 r7KQ== X-Gm-Message-State: AOAM533Plq0FmU5mRM21p1O3ygIR8z9q12D89LIHcDVFg2Dza3Bi6HA/ l1y9f/F4U5wFdrrzUIJ2ykvcFkmniKgv1A3ISRrccw== X-Received: by 2002:a05:6512:21cb:: with SMTP id d11mr8276307lft.579.1633508954553; Wed, 06 Oct 2021 01:29:14 -0700 (PDT) MIME-Version: 1.0 References: <20211005143748.2471647-1-pan@semihalf.com> <20211005143748.2471647-3-pan@semihalf.com> In-Reply-To: From: =?UTF-8?Q?Pawe=C5=82_Anikiel?= Date: Wed, 6 Oct 2021 11:29:03 +0200 Message-ID: Subject: Re: [PATCH v2 2/4] dt-bindings: add bus number property To: Alexandre Belloni Cc: Arnd Bergmann , jarkko.nikula@linux.intel.com, Andy Shevchenko , Mika Westerberg , Rob Herring , Philipp Zabel , Olof Johansson , SoC Team , Dinh Nguyen , Pratyush Yadav , Tudor Ambarus , Linux I2C , Linux Kernel Mailing List , Sebastian Reichel , "Leizhen (ThunderTown)" , Jonathan Cameron , DTML , Linux ARM , Konrad Adamczyk , Tomasz Nowicki , Jacek Majkowski , Alexandru Stan Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 5, 2021 at 6:28 PM Alexandre Belloni wrote: > > On 05/10/2021 18:22:12+0200, Arnd Bergmann wrote: > > On Tue, Oct 5, 2021 at 4:37 PM Pawe=C5=82 Anikiel wr= ote: > > > > > > On SoCFPGA systems, it's desireable to have fixed numbering for > > > i2c busses, while being able to enable/disable them (e.g. have i2c1 > > > be mapped to /dev/i2c-1, even though i2c0 is disabled). This can also > > > be achieved using devicetree aliases (see i2c_add_adapter). However, > > > having the driver be self-contained without relying on aliases is mor= e > > > robust. > > > > > > Signed-off-by: Pawe=C5=82 Anikiel > > > > I don't see how adding a nonstandard property in one of the i2c bus > > drivers helps at all. How do you expect this to work when there are > > multiple i2c controllers in the system using different drivers? What > > should happen if both an alias and the busno property are set? > > > > What happens when two nodes have the same busno property because e.g. > one is in a dtsi and the other one is in a dts? > If busno is set, the alias is ignored (the code that checks aliases is never reached). If two nodes have the same busno property, we get a WARN in drivers/i2c/i2c-core-base.c:1637, and only on of them gets attached. What is a better way of doing this then? Is adding aliases to the devicetree like this okay? aliases { ... i2c0 =3D &i2c0; i2c1 =3D &i2c1; };