From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com [209.85.128.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 06031425481 for ; Thu, 8 Jan 2026 11:44:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.47 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767872685; cv=none; b=ZyGUNrkr7D/roXYs2pYJurzaA6mYtFx5zQOduvhOh4HZFrDQx95A8ktK93RAdSK2FUSv47eEBNWuLOQGV9tduLm7COxvpHHLJTB/HdUfth7rmJyKH7X2kHlQ8JW27yMP4RVShPd3r01ABtA5jy6R8LE3EGnDKPrKhlbMC67pNYY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767872685; c=relaxed/simple; bh=c5b43E0GnOfhYe35FNpzxBQXxJaNPMy848bxda5ueRM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=ZPOO6FECtw9AOYrOP5dReDrPPQlofuUnVuH9DycwUmw4PElA5gWlX+HOR/77XJkKxN29i2XAJ15pQE5jZHjwk0k0hiBep4R8vKbf7EsNSx+417Fz9+u7oaAXxhRTMhZj5VFaQ6KVWdabON7Xqs92RS9nTwNXTVWjf1zA64xSiTs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=tuxon.dev; spf=pass smtp.mailfrom=tuxon.dev; dkim=pass (2048-bit key) header.d=tuxon.dev header.i=@tuxon.dev header.b=HfOt6Hpq; arc=none smtp.client-ip=209.85.128.47 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=tuxon.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=tuxon.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=tuxon.dev header.i=@tuxon.dev header.b="HfOt6Hpq" Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-477619f8ae5so24697215e9.3 for ; Thu, 08 Jan 2026 03:44:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tuxon.dev; s=google; t=1767872678; x=1768477478; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=PXVp7c2KZyPxfovsWjA2iVt8yUE2heAGChkNokDPQjw=; b=HfOt6HpqSVcamO5ZckK1EPdxpfJM+gW12wwBnbJqtQfzkyNDpA9qTNqrc71CqrLIPd pWnFpsct9wZpoMUNWDHOkDtVJsvLGTdZM13R/dp6vCe1n64cKACpwWaTbwhK6jXYJKEn Pwx9bImCtKeUQq3ZRfnUEaCYQrgLNyeiQZ9IFvHgEn5L24i5WjqplnMPH2ilFB0bQqyp q3ymtDeZ3UqrjGIALUJXHCO/Ig91xLbt9YAzzMeKRiguy1hvNOZWzM2YtI4+QBp3aAoc tdpC0AIx1lKd+qemDw54r+8/t4XpbFxWU+kXxDuYLrOdimPoCW4x6eHKEHbXhj9tqFvI K+3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767872678; x=1768477478; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=PXVp7c2KZyPxfovsWjA2iVt8yUE2heAGChkNokDPQjw=; b=R5QwlQy54zHVKJ0pDJmdvWMW2wa+EtBaSfiectVrOAaWeE+vSuYIU8bkxSgCOSc4eq qa3SzelY84iRXXJS8VlKCMy4irgHcKiDkqS2cQbhVNhVexkrM5/hG2e/l1Erkh2RG3GI D0j3mmgOnlKH3E97uMK6FAUqfpU06h8Djnvry1X1nGr3aGeVHiCpR6lqSPXUgezIt/UG 69qabWHftlLwbpjs0BETdrCB1GjGbwSidADuT6SKdRxv6bVOvIWPlFztektOIJn+ersB fBDb9kw6H4pWLT28fLIjKwCG6gEtAWVBq9TdlqUnXMALWmduQ92Iy+dv1K/Tap/XqoAo UtJg== X-Gm-Message-State: AOJu0YxnYYTQ4sqThziiq5CHIv4TuJlZ0kYmhDwhr9wERtjKEXvwn9ph XyDGcV2pktEjYIzME2sTpN2ENuB3KKMer2EVuBQJQzY4qrJOWUBN37WQJKpMDTLnAuM= X-Gm-Gg: AY/fxX4A8IjqvwezZ/VJyiEgv8AZMbDu/rHCsY0cr5N58vw7PtcgXJQlkLmv+UQEK8H 9OqtQpfSXSW8g/+YU8wRZHhGccIkETJQ1rhuzyMSOPkxlUg8u96n+rGqoiXjztt/Vyq/MTuPfcb CVEJujfO0QS0xOOr9zC3KMT4pvWSWBeZ5RGUlgM5dRiBOh5PyfJQ5mpg/dbJGoTKlox/bL37P6s +dPXuvjGsAQvEURrRMTBZRoh6B7SLWVPAC/d3kU0FAx57SW1dCXfovbhmL9b4yOs87XfMgeQ66Y Aj6TxjcY95hBD4Ecgh1CTZl1ky/sChQOM2TJtg/w5+0nHm7+4uyu5cD0rGadPLNErzpizwfA9B+ 4MSJbi99oQShvQVoi7IIgHY+9CLpbr2YHb4IN6MuT68PPKM0RHDHcMcKgazLzSJ0L75lbi+HL5P qQUGkekOKXBK8FkYZaFg== X-Google-Smtp-Source: AGHT+IGAmHmwWFpxTlQrxXJ0dmlBdwdNLlou9mYsvkBH6tgG51GMjsJCWMV2eI8HMBpAFse4o/apJQ== X-Received: by 2002:a05:600c:3542:b0:46e:32dd:1b1a with SMTP id 5b1f17b1804b1-47d84b26bf0mr63907685e9.7.1767872677950; Thu, 08 Jan 2026 03:44:37 -0800 (PST) Received: from [192.168.50.4] ([82.78.167.17]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d7f65d9f0sm155006245e9.12.2026.01.08.03.44.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Jan 2026 03:44:37 -0800 (PST) Message-ID: <83ead495-04c9-4dad-b971-29dca4c45898@tuxon.dev> Date: Thu, 8 Jan 2026 13:44:36 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 2/2] reset: rzg2l-usbphy-ctrl: Add suspend/resume support To: Philipp Zabel Cc: linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org References: <20260108102600.3477012-1-claudiu.beznea.uj@bp.renesas.com> <20260108102600.3477012-3-claudiu.beznea.uj@bp.renesas.com> <7b4aa36772039d6607bf0aee38bd897b773e3f7f.camel@pengutronix.de> Content-Language: en-US From: Claudiu Beznea In-Reply-To: <7b4aa36772039d6607bf0aee38bd897b773e3f7f.camel@pengutronix.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi, Philipp, On 1/8/26 13:19, Philipp Zabel wrote: > On Do, 2026-01-08 at 12:26 +0200, Claudiu wrote: >> From: Claudiu Beznea >> >> The RZ/G2L USBPHY control driver is also used on the RZ/G3S SoC. >> The RZ/G3S SoC supports a power-saving mode in which power to most USB >> components (including the USBPHY control block) is turned off. Because of >> this, the USBPHY control block needs to be reconfigured when returning >> from power-saving mode. >> >> Add suspend/resume support to handle runtime suspend/resume of the device, >> assert/deassert the reset signal, and reinitialize the USBPHY control >> block. >> >> Reviewed-by: Biju Das >> Signed-off-by: Claudiu Beznea >> --- >> >> Changes in v3: >> - collected tags >> >> Changes in v2: >> - used pm_runtime_put_sync() in rzg2l_usbphy_ctrl_suspend() >> >> drivers/reset/reset-rzg2l-usbphy-ctrl.c | 94 +++++++++++++++++++++---- >> 1 file changed, 79 insertions(+), 15 deletions(-) >> >> diff --git a/drivers/reset/reset-rzg2l-usbphy-ctrl.c b/drivers/reset/reset-rzg2l-usbphy-ctrl.c >> index 9ce0c1f5d465..1a1581643bf3 100644 >> --- a/drivers/reset/reset-rzg2l-usbphy-ctrl.c >> +++ b/drivers/reset/reset-rzg2l-usbphy-ctrl.c > [...] >> @@ -266,10 +273,67 @@ static void rzg2l_usbphy_ctrl_remove(struct platform_device *pdev) > [...] >> +static int rzg2l_usbphy_ctrl_resume(struct device *dev) >> +{ >> + struct rzg2l_usbphy_ctrl_priv *priv = dev_get_drvdata(dev); >> + int ret; >> + >> + ret = rzg2l_usbphy_ctrl_set_pwrrdy(priv->pwrrdy, true); >> + if (ret) >> + return ret; >> + >> + ret = reset_control_deassert(priv->rstc); >> + if (ret) >> + goto pwrrdy_off; > > Do I understand correctly that this reset clears PHY_RESET_PORT[12] > bits in the RESET register such that rzg2l_usbphy_ctrl_init() must be > called below? No, this reset is the reset of this HW block, controlled by another HW block (the clock controller). Bits in PHY_RESET_PORT and other registers specific to this driver could be cleared due to the fact the power to this USB PHY CTRL HW block is turned off in suspend. The Renesas RZ/G3S SoC, that uses this HW block, has a power saving mode where power to most of the SoC components, including USB PHY CTRL, is turned off. Due to this, we need to restore the previous settings. priv->rstc need to also be restored as power to the clock controller is also lost. > >> + ret = pm_runtime_resume_and_get(dev); >> + if (ret) >> + goto reset_assert; >> + >> + rzg2l_usbphy_ctrl_init(priv); > > This assumes that consumers requested PHY_RESET_PORT[12] resets to be > asserted in their suspend function. That's right! > I think you should warn if that is > not the case during suspend. AFAICT, that could be done by adding extra logic in this driver to store the state of the de-asserted bits. We can't interrogate directly the registers as there might be the case where these resets are used by previous bootloaders (that might let them in the de-assert state) but not by Linux. In that case, w/o extra software cache, we can generate false positives by directly interrogating the registers. My point here was that the users of these resets will have to properly configure their own requested resets, otherwise, they are not doing the things in the proper way. I can add those extra software cache for the hw registers but this is what I've tried to avoid. Please let me know how do you want me to proceed and I'll update. > Saving the relevant RESET bits during > suspend and restoring them here is probably not useful. That's what I've tried to avoid. Thank you, Claudiu