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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 0FA19CA0EFC for ; Fri, 30 Aug 2024 11:03:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:CC:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=/NdsKTCUALfWcU0xajPBHnoEGQue1OOkSmwZOpKC+4g=; b=W9DdcXXWP8T2R9pChAAWnF96d2 +/Yufe4DqfT79PlSYtSzseIlQquTLSNCrf+EgkV8kLbUWZ4806/cRlUx+/HIUeXkvgLmJEuZbSMiZ tLCkA3u6MzkbapLSQJbdI2/g5z/AWe77hsNkYuJJ4QnazGKX/5bDnhTSX7v+kwdMMGA1hL3QZWp6l 2z8LG+rj/SqioSSmqLIXX63ZTH/ozx1z0Cucg5fnGowecd55Kn43E+lNQ4h4XVJ6nLWhMXTsYxE2l zidUw/52yloISDaBTKoNEywXzQwvu/W/qglqdSBnDQZIOn0t2X6qCTEN1CKiFCRdg6uhE9Z7c7Xo2 l5GQRqHQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sjzPC-00000005wie-3rnz; Fri, 30 Aug 2024 11:03:02 +0000 Received: from esa.microchip.iphmx.com ([68.232.154.123]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sjzOF-00000005wN2-23sj; Fri, 30 Aug 2024 11:02:05 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=microchip.com; i=@microchip.com; q=dns/txt; s=mchp; t=1725015723; x=1756551723; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=TDfK2OXLeyP1NsBRvK2CqLKE67BvroyGJQRQiZTW4AU=; b=HZ3e3VToqjkEXyqAb+9MN0/5h8aMpnunY0tn5OywWsKcYTmESRVIvdUk ScQh/bW0ZSjtOpku4y9kTR49gu0nVvstBRHKEzgeT6Ie6t9ePcMwheI3i vLdriK0bXa1iBegR7XGb4exruMgVQ3NlhAaubFVB9mUz75XDd+yYzDHvp dpLilYfgdxVp1wevZw5X0jIr9vgST811cByZfK+3wqyUW3Q0ILhdpBPGQ og2hhtnirXgFCpAktOG2MhweYyOW2axEm98IgU3uvRw5+m+nAZGWZWHBy SgaTrqfj+gL9b9U1b67SxwshHAiHvCNijq97XJUYP5FBVlTskg020hWpQ A==; X-CSE-ConnectionGUID: 491UwJ12S2WuGIiIBwqZ7Q== X-CSE-MsgGUID: OvBJOUT7RViFE4CCask+Fw== X-IronPort-AV: E=Sophos;i="6.10,188,1719903600"; d="asc'?scan'208";a="198533155" X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN Received: from unknown (HELO email.microchip.com) ([170.129.1.10]) by esa6.microchip.iphmx.com with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; 30 Aug 2024 04:02:01 -0700 Received: from chn-vm-ex01.mchp-main.com (10.10.85.143) by chn-vm-ex01.mchp-main.com (10.10.85.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Fri, 30 Aug 2024 04:01:58 -0700 Received: from wendy (10.10.85.11) by chn-vm-ex01.mchp-main.com (10.10.85.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35 via Frontend Transport; Fri, 30 Aug 2024 04:01:50 -0700 Date: Fri, 30 Aug 2024 12:01:19 +0100 From: Conor Dooley To: Lorenzo Bianconi CC: Krzysztof Kozlowski , Christian Marangi , Rob Herring , Lorenzo Bianconi , Conor Dooley , Benjamin Larsson , Linus Walleij , Krzysztof Kozlowski , Conor Dooley , Sean Wang , Matthias Brugger , AngeloGioacchino Del Regno , , , , , Subject: Re: [PATCH v2 1/2] dt-bindings: pinctrl: airoha: Add EN7581 pinctrl controller Message-ID: <20240830-payphone-unexposed-75eed532c14d@wendy> References: <66c8c50f.050a0220.d7871.f209@mx.google.com> <20240826-kinsman-crunching-e3b75297088c@spud> <66ce1b04.df0a0220.a2131.6def@mx.google.com> <66d187f1.050a0220.3213d8.ad53@mx.google.com> <2c9aafdd-000b-4e8f-b599-4f57e7eb0ca7@kernel.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="BTdQ0ZNkxqHmGinK" Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240830_040203_777997_BDEAA924 X-CRM114-Status: GOOD ( 28.77 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --BTdQ0ZNkxqHmGinK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 30, 2024 at 12:55:32PM +0200, Lorenzo Bianconi wrote: > [...] >=20 > > >>> > > >>> Hi Rob, thanks a lot for the hint, I hope we can finally find a sol= ution > > >>> on how to implement this. > > >>> > > >>> In Documentation the block is called GPIO Controller. As explained = it does > > >>> expose pinctrl function AND pwm (with regs in the middle) > > >>> > > >>> Is this semplification really needed? It does pose some problem dri= ver > > >>> wise (on where to put the driver, in what subsystem) and also on the > > >> > > >> Sorry, but no, dt-bindings do not affect the driver at all in such w= ay. > > >> Nothing changes in your driver in such aspect, no dilemma where to p= ut > > >> it (the same place as before). > > >> > > >=20 > > > Ok, from the proposed node structure, is it problematic to move the > > > gpio-controller and -cells in the pinctrl node? And also the pwm-cells > > > to the pwm node? > >=20 > > The move is just unnecessary and not neat. You design DTS based on your > > drivers architecture and this is exactly what we want to avoid. > >=20 > > > This is similar to how it's done by broadcom GPIO MFD [1] that also > >=20 > > There are 'reg' fields, which is the main problem here. I don't like > > that arguments because it entirely misses the discussions - about that > > binding or other bindings - happening prior to merge. > >=20 > > > expose pinctrl and other device in the same register block as MFD > > > childs. > > >=20 > > > This would be the final node block. > > >=20 > > > mfd@1fbf0200 { > > > compatible =3D "airoha,en7581-gpio-mfd"; > > > reg =3D <0x0 0x1fbf0200 0x0 0xc0>; > > >=20 > > > interrupt-parent =3D <&gic>; > > > interrupts =3D ; > > >=20 > > > pio: pinctrl { > > > compatible =3D "airoha,en7581-pinctrl= "; > > >=20 > > > gpio-controller; > > > #gpio-cells =3D <2>; > > >=20 > > > interrupt-controller; > > > #interrupt-cells =3D <2>; > >=20 > > No resources here... >=20 > ack. iiuc, all the properties will be in the parent node (mfd) and we will > have just the compatible strings in the child ones, right? Something like: >=20 > mfd@1fbf0200 { > compatible =3D "airoha,en7581-gpio-mfd"; > reg =3D <0x0 0x1fbf0200 0x0 0xc0>; > gpio-controller; > #gpio-cells =3D <2>; >=20 > ... > #pwm-cells =3D <3>; >=20 > pio: pinctrl { > compatible =3D "airoha,en7581-pinctrl"; > }; >=20 > pwm: pwm { > compatible =3D "airoha,en7581-pwm"; > }; > }; Didn't Rob basically tell you how to do it earlier in the thread? What you've got now makes no sense, the compatibles only exist in that to probe drivers, which you can do from the mfd driver with mfd_add_devices() or w/e that function is called. Cheers, Conor. --BTdQ0ZNkxqHmGinK Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCZtGmfwAKCRB4tDGHoIJi 0sEcAQCQDluOGutoHHSxi1RRVaYRPSJP0f1MJmoiZYp/4PI/ugD+IRBsC22377IK Ef6OU0NVQVpsYSIGHZUMn0A7WR8tYwM= =YVf8 -----END PGP SIGNATURE----- --BTdQ0ZNkxqHmGinK--