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 20189C7EE2E for ; Wed, 7 Jun 2023 08:55:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239337AbjFGIzj (ORCPT ); Wed, 7 Jun 2023 04:55:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54550 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239850AbjFGIzQ (ORCPT ); Wed, 7 Jun 2023 04:55:16 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 15DCC2117; Wed, 7 Jun 2023 01:54:35 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id E31C763C7F; Wed, 7 Jun 2023 08:53:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8ADF8C433EF; Wed, 7 Jun 2023 08:53:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1686127996; bh=EkWcDuYEPYfXUrrU09MKWymiN3k4KVR9kC0PGQAic3I=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=TcuIqfFjWcbeOOOUYSC7vRtsg3ISAh7sWe8Thmd9VhPEL9AaFvBM+isNCLvGdxFon VGRBCxfhFeshT+KFH75mjdqXdMReqlCS8FVDzMN/aSrBkWXt/7rLZvX1dGLUkkeKlL cBm5zAHw6osPAqQh4yWkdYBUhYYaEugEDS5TlpsYtE7RQMROKDVdcPxW7fj3Q9lDW6 beNqQ49hY5fMf3eQgijV/b6mc0IjGeOibqRh5IJEpVdh1fmvvIyhzPtmaAox68NBIl cCFkrmPWHXPNxcXD2cfNQx8LXUUTgrYEYH+Xe3UfJPN0dgRGCnu/jfNXfrwWWAjnjb gBBanZEGAqawg== Date: Wed, 7 Jun 2023 10:53:07 +0200 From: Wolfram Sang To: Geert Uytterhoeven Cc: Laurent Pinchart , Biju Das , Krzysztof Kozlowski , Rob Herring , Andrzej Hajda , Neil Armstrong , Robert Foss , David Airlie , Daniel Vetter , Kieran Bingham , Mauro Carvalho Chehab , Hans Verkuil , Alessandro Zummo , Alexandre Belloni , Jonas Karlman , Jernej Skrabec , Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= , Corey Minyard , Marek =?utf-8?B?QmVow7pu?= , Jiasheng Jiang , Antonio Borneo , Abhinav Kumar , Ahmad Fatoum , "dri-devel@lists.freedesktop.org" , "linux-i2c@vger.kernel.org" , "linux-media@vger.kernel.org" , Geert Uytterhoeven , Fabrizio Castro , "linux-renesas-soc@vger.kernel.org" Subject: Re: [PATCH v5 01/11] i2c: Enhance i2c_new_ancillary_device API Message-ID: Mail-Followup-To: Wolfram Sang , Geert Uytterhoeven , Laurent Pinchart , Biju Das , Krzysztof Kozlowski , Rob Herring , Andrzej Hajda , Neil Armstrong , Robert Foss , David Airlie , Daniel Vetter , Kieran Bingham , Mauro Carvalho Chehab , Hans Verkuil , Alessandro Zummo , Alexandre Belloni , Jonas Karlman , Jernej Skrabec , Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= , Corey Minyard , Marek =?utf-8?B?QmVow7pu?= , Jiasheng Jiang , Antonio Borneo , Abhinav Kumar , Ahmad Fatoum , "dri-devel@lists.freedesktop.org" , "linux-i2c@vger.kernel.org" , "linux-media@vger.kernel.org" , Geert Uytterhoeven , Fabrizio Castro , "linux-renesas-soc@vger.kernel.org" References: <20230522101849.297499-1-biju.das.jz@bp.renesas.com> <20230522101849.297499-2-biju.das.jz@bp.renesas.com> <20230529080552.GJ25984@pendragon.ideasonboard.com> <20230531085941.GA27043@pendragon.ideasonboard.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Nm5CNVphMfOl2T+J" Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-i2c@vger.kernel.org --Nm5CNVphMfOl2T+J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all, sorry for not being able to chime in earlier. > In Biju's particular use case, the i2c device responds to two addresses, > which is the standard i2c ancillary use case. However, what's special Not quite. ancillary is used when a *driver* needs to take care of two addresses. We already have devices bundling two features into the same chip. I recall at least RTC + EEPROM somewhere. And so far, we have been handling this by creating two nodes in DT and have proper binding docs. I think this is cleaner. First, you can see in DT already what the compound device really consists of. In this case, which RTC and RTC driver is exactly needed. Second, the code added here adds complexity to the I2C core with another layer of inderection for dummy devices. > As some resources are shared (knowledge about the clocks), splitting > this in two distinct devices in DT (which is what Biju's initial patch > series did) would need phandles to link both nodes together. >=20 > Do you have a better idea how to represent this? Not sure if I understood this chip correctly, but maybe: The PMIC driver exposes a clock gate which can be consumed by the RTC driver? Happy hacking, Wolfram --Nm5CNVphMfOl2T+J Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEOZGx6rniZ1Gk92RdFA3kzBSgKbYFAmSARW8ACgkQFA3kzBSg KbbYsRAAgTcDHo1Azv7DhDEOMF7wTqPXl27TMa07c345Y64Hxn/2+x1zO5eddL2T dHKlj2vg5Ry53CEbEC1wGPxBSDSOtDQvPPxXCSEFDi1ead63j/gOeGcuMvwySb80 7wk2qUBMkkT00yQDweMv9AwNXbo0MKOHnEYZHkhFBy36gS2qqzSYkjj6AdJuVKJR 6va/d1QulASM1ZutznMHQvXd/lL/XDBbraxfQBjGlrZG9C6wJq23WuoWavjbHwdU DAzXIYSGMvqbIMSrXNjnGrVeEFwNnMYFM8EOTk319nQR9Z1i1UMiqvoOEVoEZWW+ XzrLf1ydWAXICb9j0Mc6RlYTfz+/YUZA0JlBsv+ypN9tw4tPEkmKfmlg6TWAQBA9 aXM84EZjePIhZSU826pOURtAS+fDsfPQZMlnYS6KKdrhU+h3y29rpHA28gKjBTWT yt3LSb2AOjcOlvsFZQBigDINvwjPfhCRFjpMH2BAzKF5Ei7qygPw1kREgyh5zmr3 UDbelnwjQAk4SuZbqJpRTyKyQdPLl/ReW5lMEhIdOb/n2THQT8fEiFCElpbasoEU Zg/L7xaU6qROiqbZMPKisltXTlyZ68kY0NPRm+w0AytwQWb1C1IBqGUf8KyJWuKr oP/yC5SljRtET9R5XI6UgV0wnt4uN8UscY5sMJxbDGCEoTm/iAY= =0ELS -----END PGP SIGNATURE----- --Nm5CNVphMfOl2T+J--