From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from metis.whiteo.stw.pengutronix.de (metis.whiteo.stw.pengutronix.de [185.203.201.7]) (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 5AD78186E54 for ; Fri, 14 Feb 2025 18:03:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.203.201.7 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739556205; cv=none; b=oM2lBqGPyr69aatq3AY0bYgxq6t2Rr0UtP1Ul9xBEM9xY6upAJ3+gnMZNYEWTx0Xwq1zlnNu7vT+CRbIK20mowUGBn+w/GFTyHCXECmLGT01S1AAjsamNe2ekxmnEY+ldqMYtnXMFym83H8XV0ST23GzUld7vR+fHqC0ObFCf5E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739556205; c=relaxed/simple; bh=k8MEGxuiLlmPuqpoYOTE5EbOg9Iz3g5ldM672B1/FXg=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=XrLzcrTyr6gMXm5h0ONucGFmb5yJLfnoGxoxA2gc4SkQxBIPNGN/ZadlaY7egq0l/0FRjnFUh/j9saj5XXyn3jFnVqUigxzDeVeWDThqV74rq/NctwqXLyiOoHd1O64oKEAbWFi4D3pIJmOT4WYyQBaQISoH6C83oSAGY3GU24M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=pengutronix.de; spf=pass smtp.mailfrom=pengutronix.de; arc=none smtp.client-ip=185.203.201.7 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=pengutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pengutronix.de Received: from drehscheibe.grey.stw.pengutronix.de ([2a0a:edc0:0:c01:1d::a2]) by metis.whiteo.stw.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tj025-0000CI-3a; Fri, 14 Feb 2025 19:03:21 +0100 Received: from lupine.office.stw.pengutronix.de ([2a0a:edc0:0:900:1d::4e] helo=lupine) by drehscheibe.grey.stw.pengutronix.de with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1tj021-000xHw-2A; Fri, 14 Feb 2025 19:03:17 +0100 Received: from pza by lupine with local (Exim 4.96) (envelope-from ) id 1tj021-000BqJ-1u; Fri, 14 Feb 2025 19:03:17 +0100 Message-ID: <8a9518fdfda805f52b96e93649c9ee39274f5844.camel@pengutronix.de> Subject: Re: [PATCH 1/4] [PATCH 1/4] reset: simple: Add syscon device compatible From: Philipp Zabel To: Wilson Ding , "linux-kernel@vger.kernel.org" , "devicetree@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" Cc: "andrew@lunn.ch" , "gregory.clement@bootlin.com" , "sebastian.hesselbarth@gmail.com" , "robh@kernel.org" , "krzk+dt@kernel.org" , "conor+dt@kernel.org" , Sanghoon Lee , Geethasowjanya Akula Date: Fri, 14 Feb 2025 19:03:17 +0100 In-Reply-To: References: <20250214065833.530276-1-dingwei@marvell.com> <20250214065833.530276-3-dingwei@marvell.com> <6dd9ed2750abe1f5174805673411ccb919ee5461.camel@pengutronix.de> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4-2 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-SA-Exim-Connect-IP: 2a0a:edc0:0:c01:1d::a2 X-SA-Exim-Mail-From: p.zabel@pengutronix.de X-SA-Exim-Scanned: No (on metis.whiteo.stw.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org On Fr, 2025-02-14 at 17:13 +0000, Wilson Ding wrote: >=20 > > -----Original Message----- > > From: Philipp Zabel > > Sent: Friday, February 14, 2025 3:54 AM > > To: Wilson Ding ; linux-kernel@vger.kernel.org; > > devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org > > Cc: andrew@lunn.ch; gregory.clement@bootlin.com; > > sebastian.hesselbarth@gmail.com; robh@kernel.org; krzk+dt@kernel.org; > > conor+dt@kernel.org; Sanghoon Lee ; Geethasowjanya > > Akula > > Subject: [EXTERNAL] Re: [PATCH 1/4] [PATCH 1/4] reset: simple: Add sysc= on > > device compatible > >=20 > > On Do, 2025-02-13 at 22:58 -0800, Wilson Ding wrote: > > > Introduce the new ops for updating reset line and getting status. > > > Thus, the reset controller can be accessed through either direct I/O > > > or regmap interfaces. > >=20 > > Please don't add a new layer of function pointer indirection, just add = a new > > struct reset_control_ops for the regmap variant. > >=20 >=20 > If just adding a new struct reset_control_ops for the regmap variant, alm= ost > all the functions will be duplicated for regmap variant.=20 > Besides reset_simple_regmap_assert/deassert(), we also need to have the > regmap version of reset_simple_update(). Yes. You could also duplicate/fold update() into assert/deassert(). It is trivial enough and the compiler will do that anyway. > Since reset_simple_reset() invokes > reset_simple_regmap_assert/deassert(), it also needs to be > duplicated. That one could go through the data->rcdev.ops->assert/deassert function pointers and be reused. But I wonder if that one function is worth the added complexity. > In this case, there will be too many redundant codes in this file. I doub= t if > it is worth to use the reset simple code. Maybe it's better to fork a new= file > for the syscon device, such as 'reset-simple-syscon.c'. What do you say? That sounds sensible to me. regards Philipp