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 5CCEC295DB8 for ; Wed, 22 Oct 2025 09:38:44 +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=1761125926; cv=none; b=eT7fv4JvyqbY+kNSLe6OB3A/qXkRQcxK1DHZxwpBxzvehbcvJboE4fayQw4nRc3axhHOqEGljygplb4BP7zsmsl8UPyIvEqEC3nBUpgcrZdoMIjR2AhJvWWTAg2VTz2TGRtnu0CuDgC9jlghiurV4pYV5Ciw5ExR0tsdUo8SBxY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761125926; c=relaxed/simple; bh=RXI86dWsUOVLWMDkiSyvCC8/ZeCCo4YfEijOuemfgj0=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=DIeX8MHYwiK/Tnvgp0lUoKvhXf2SsW6f98m4YHRDrQDdliFruEo4czi9File4nbgd5fmxMO7Ov7RR55+RR/sRvjiaGu2E31hN9Uec95N4qa7l+jDitL2NvUrs3wjs06P8xcET5GxPousepSbE2jKojhlZQbv064GSYh2TB2GE7M= 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 1vBVIQ-00004t-1Z; Wed, 22 Oct 2025 11:38:18 +0200 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 1vBVIO-004rvs-3B; Wed, 22 Oct 2025 11:38:17 +0200 Received: from pza by lupine with local (Exim 4.98.2) (envelope-from ) id 1vBVIO-000000004t5-3n5a; Wed, 22 Oct 2025 11:38:16 +0200 Message-ID: <08fbb2fc1a2e581010b6b28cd1a544053a4f1fb0.camel@pengutronix.de> Subject: Re: [PATCH v7 4/7] reset: rzg2l-usbphy-ctrl: Add support for USB PWRRDY From: Philipp Zabel To: Claudiu Beznea , vkoul@kernel.org, kishon@kernel.org, robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org, geert+renesas@glider.be, magnus.damm@gmail.com, yoshihiro.shimoda.uh@renesas.com, biju.das.jz@bp.renesas.com Cc: linux-phy@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org, Claudiu Beznea , Wolfram Sang Date: Wed, 22 Oct 2025 11:38:16 +0200 In-Reply-To: References: <20250925100302.3508038-1-claudiu.beznea.uj@bp.renesas.com> <20250925100302.3508038-5-claudiu.beznea.uj@bp.renesas.com> <66d85e70-efb8-4a45-9164-55b123691b70@tuxon.dev> <6d4bc69c-1571-4d98-b0d4-214c68be118e@tuxon.dev> <77678dd6-071b-4911-a5c5-f1519c92e91a@tuxon.dev> <6ba1fd1f07753c9b98a57c87bffbbee16971da7a.camel@pengutronix.de> <19746f65-bf10-4687-9e2b-b259220a9ea8@tuxon.dev> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.56.1-1 Precedence: bulk X-Mailing-List: devicetree@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: devicetree@vger.kernel.org Hi Claudiu, On Di, 2025-10-21 at 11:48 +0300, Claudiu Beznea wrote: > Hi, Philipp, >=20 > On 10/15/25 11:19, Claudiu Beznea wrote: > > > > > > > > I see v2 and v3 tried to control the bit from the PHY drive= rs, and in > > > > > > > > v4 we were are already back to the reset driver. > > > > > > > v2 passed the system controller (SYSC) phandle to the USB PHY= s only (though > > > > > > > renesas,sysc-signals DT property) where the PWRRDY bit was se= t. The PWRRDY > > > > > > > bit was referenced counted in the SYSC driver though regmap A= PIs. > > > > > > >=20 > > > > > > > v3 used the approach from v2 but passed the renesas,sysc-sign= als to all the > > > > > > > USB related drivers. > > > > > > >=20 > > > > > > > Then, in v4, the PWRRDY refcounting was dropped and passed > > > > > > > renesas,sysc-signals only to the USB PHY CTRL DT node in the = idea that this > > > > > > > is the node that will always be probed first as all the other= USB blocks > > > > > > > need it and request resets from it. > > > > > > >=20 > > > > > > > v5 and v6 kept the approach from v4 and only addressed misc c= omments or > > > > > > > things that I noticed. > > > > > > Could you please let me know if you are OK with the approach pr= oposed in > > > > > > v7, so that I can start preparing a new version addressing your= comments? > > > > > If the PWRRDY signal is an input to the USB2PHY control block, an= d not > > > > > only to the PHY blocks, I have no issue with this being handled i= n the > > > > > usb2phy reset driver - > > > > Yes, this is how the Renesas HW team confirmed they are related. > > > Ok, understood. I concur that usb2phy-ctrl is the right place for the > > > sysc property then. > > >=20 > > > > > iff it is not sensible to just control the > > > > > signal from the power domain driver. > > > > As mentioned above, that can be done as well but, passing a SYSC ph= andle to > > > > the CPG DT node will not be valid from the HW description point of = view. > > > >=20 > > > > > If we have to handle it in the reset driver, I'd prefer to see th= is > > > > > controlled with a dev_pm_genpd_add_notifier(). If that is not pos= sible, > > > > > I'd like to understand why. > > > > From the code inspection I did, that can be done. From what I can t= ell at > > > > the moment, I'll have to register a gepnd notifier from > > > > reset-rzg2l-usbphy-ctrl, before runtime resuming the device and con= trol the > > > > SYSC PWRRDY from it. > > > I'd like that. > > Now, that we found the genpd notifier is not a solution, could you plea= se > > let me know how would you like me to proceed? >=20 > After discussing all the possible (known) solutions, could you please let > me know if you are OK with the approach in this series? Yes, I don't have a better idea. Let's revisit the issue of ordering guarantees when suspend/resume is implemented. regards Philipp