From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F2AFD3749E9 for ; Wed, 1 Jul 2026 16:57:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782925027; cv=none; b=TN+K6/BOOF6uii9PVI8GE/i12A+5hG3S9lSlpNqSzdwZr4tmUZWscHup3zkK35OgM0pw1cYH5TLTfwXwRMbfzhBNkjly4zcmmkypc1rwe52kYgu7c/u/pStV0Alrfcv3bzTMYJNVHlGF6fgkwe4RcSt9FJhAtHCDEr0w+WM0wdQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782925027; c=relaxed/simple; bh=T8dyhIoBx2aM79WKVz+7If0G+RtNxz0htDU0hoecEfU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Ehr32VXgWhpD8KBWmyyZlifuJ4zLcrHMjK4PC/e3CMFecrwlk6q0g2POyQiE9SKIRIk/n4PtghRq3cXW/IwLw2tPKRFtOaKgJhPk2i3xEwQauWNfUFNqEkpnzIUBpyMDTF1k4v2AMT9NQ55CWaKwuVQourDxs/94DvDZocSfeww= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=bfxbim1W; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="bfxbim1W" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D0D0B1F000E9; Wed, 1 Jul 2026 16:57:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1782925025; bh=T8dyhIoBx2aM79WKVz+7If0G+RtNxz0htDU0hoecEfU=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=bfxbim1WIg11jZZZcTS4ZN12zcgxqp4nxJ1z00DdCwnHA2AKxKqixUhSn/pbul0yB PmdRzWDzNAuSZF5bpF3Hj9dKgVLte3Mm0q+teOuteR6fsxnxUH4CIHxacK+p7V+Tgi oObwlnShJ/opsw0uFXRQcwMw49uzx2jg/Z1S7vrO6Bm7q10CuEZ56II33QENwRtSa7 rf1jrJGuYLL0rQxSeSu4znEb86mKEudH03XVFkP0ExBInTvU8mEqGYiKtxUPsGSZre mGl3lxM7s8a8t87zPOOcDrzPoIp5zoFsXzMhUUeAb73BqnsJ8ERADexqBZEiOWXYaU CzUlkPC4b5n2g== Date: Wed, 1 Jul 2026 17:57:00 +0100 From: Conor Dooley To: Peter Wang =?utf-8?B?KOeOi+S/oeWPiyk=?= Cc: "p.zabel@pengutronix.de" , "linux-kernel@vger.kernel.org" , Alice Chao =?utf-8?B?KOi2meePruWdhyk=?= , "krzysztof.kozlowski@linaro.org" , AngeloGioacchino Del Regno , "robh@kernel.org" , wsd_upstream , Chun-Hung Wu =?utf-8?B?KOW3q+mnv+Wujyk=?= , "linux-devicetree@vger.kernel.org" , Naomi Chu =?utf-8?B?KOacseipoOeUsCk=?= , "linux-mediatek@lists.infradead.org" , "conor+dt@kernel.org" , "matthias.bgg@gmail.com" , Ed Tsai =?utf-8?B?KOiUoeWul+i7kik=?= Subject: Re: [PATCH v1 1/2] Documentation: dt: reset: add mediatek,syscon-reset binding Message-ID: <20260701-city-during-7d76a326f2f4@spud> References: <20260626074820.2537772-1-peter.wang@mediatek.com> <20260626074820.2537772-2-peter.wang@mediatek.com> <4ac862d82690a850eeaa997f041f22ee61233ed7.camel@pengutronix.de> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="GId5WCsW6pNoW8dq" Content-Disposition: inline In-Reply-To: --GId5WCsW6pNoW8dq Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 01, 2026 at 06:35:20AM +0000, Peter Wang (=E7=8E=8B=E4=BF=A1=E5= =8F=8B) wrote: > On Fri, 2026-06-26 at 10:33 +0200, Philipp Zabel wrote > >=20 > > Where is the binding doc for mediatek,mt8183-ufs0cfg_ao? Is this > > simple-mfd just to load the reset driver? > >=20 >=20 > Hi Philipp, >=20 > Thanks for the review, and sorry for the late reply. > Yes, "mediatek,mt8183-ufs0cfg_ao" should be removed. > I will remove it in the next version. >=20 > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 reg =3D <0x16840000 0x100= 0>; > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 #address-cells =3D <1>; > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 #size-cells =3D <1>; > > > + > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ufs0cfgao_rst: reset-cont= roller { > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 c= ompatible =3D "mediatek,syscon-reset"; > >=20 > > It looks to me like this is just two registers inside ufs0cfg_ao, not > > a > > separate device. Why don't you just add #reset-cells to the parent > > node? > >=20 > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 #= reset-cells =3D <1>; > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 m= ediatek,reset-bits =3D > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 <0x48=C2=A0 3=C2=A0 0x4c=C2=A0 3=C2=A0 100>, > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 <0x148 0=C2=A0 0x14c 0=C2=A0 100>, > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 <0x148 1=C2=A0 0x14c 1=C2=A0 100>, > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 <0x148 2=C2=A0 0x14c 2=C2=A0 0>; > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }; > >=20 > > Why is this in DT? This should be a table in the reset driver. > >=20 > > regards > > Philipp >=20 > Regarding the child node and reset-bits in DT, > We chose the child node approach with 'mediatek,reset-bits' defined=20 > in DT to keep the reset line descriptions self-contained and reusable=20 > across different SoC variants. MediaTek has many SoCs (mt8183, mt6985,=20 > mt6989, ...) where the same UFS subsystem may have different register=20 > offsets for reset lines. By describing them in DT, we can support new=20 > SoC variants by updating the DT alone, without requiring a new driver=20 > patch for every new SoC. =46rom what I recall, mediatek ufs is a mess with lots of vendor kernel type things slipping into mainline without proper review on the DT front. Because of that, I at least am going to require that everything is done completely (and perhaps excessively) by the book here, including introducing complete bindings for syscon regions rather than partial bits for components like this one. > This approach is also consistent with the existing 'ti,syscon-reset'=20 > binding, which uses a similar per-entry table property 'ti,reset-bits'=20 > to describe reset lines within a syscon block. This was done about 10 years ago, I would not consider it a guide for what's acceptable today. Thanks, Conor. --GId5WCsW6pNoW8dq Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCakVG3AAKCRB4tDGHoIJi 0oN8AQDM3qO2i7ZlMMw+JnJETVJwlg6ATI/v6v4nFmWDqMQt0wEAj+YOzxqvq8Gj S0GCE6Sq2uYX+59AWwWx3TInToTLWAM= =+gFw -----END PGP SIGNATURE----- --GId5WCsW6pNoW8dq--