From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) (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 ECB7E2E413 for ; Fri, 5 Dec 2025 14:01:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764943319; cv=none; b=bx05DPWMMzHcJQmHI5kXWw0rxLoM5J7IOJsTM74qD8P6bycOE6i7A/w4vyWeGqpSW+Y9OZInnRbdGnhsPJec7Vac1MWI6V/I9/laYjB/77ZqVPY6TzXMC/uCio8cDuB9W70F2WUQXpPMO7LgQtJIreaQHd1QAZRpm5XPOQ+bQyg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764943319; c=relaxed/simple; bh=wEeRhbI5x0EzNu4bkeBOKxzkJfD8jqm9H83aTBh8FMM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=hcXyG41POy1WHutaY+djj+JBudo8+3k+l7NYHQSKOqgsUVeYxBsweRTPE+DrB6czUNss3H0nfR3BsaJ2EchE4njysBnqwgtmij6YVjY5/FTDAKTb6FTiqhFF4AUkJIHZpGn5OZ0EcLlpnED6vxf48ULnDDeaXDad2t/Si+LDfbw= 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=aNGuOTXp; arc=none smtp.client-ip=209.85.128.54 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="aNGuOTXp" Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-47775fb6c56so19198165e9.1 for ; Fri, 05 Dec 2025 06:01:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tuxon.dev; s=google; t=1764943313; x=1765548113; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=ETP6ZwRR8d1hP4cNbKBiZUy+JiTc6tdkyie3Djet/bI=; b=aNGuOTXpOQztaPUJo4ttnXn7wPwIYVv6XI3U1T05vmzU54X4/LUgkS2jG9kPPTt+Ok USiTHQMqSlLt3H8XZqo7sCPMvWfnTVQbJojXvekrU3G2KwKCBIWdHY10RYU1AMUi42SS 1OufR+4fXy5/Dnl40r6GVUpu4BR4wy7FQzSGegFuo4RHGXcQtSavrluCAQNmd0fe2c2l DIiQKUrcMcc1CE8wq/awUbwqDYqNQfEenv1opCjc9D/OiKKe2/cJ907poS0Qt9Wu/fKW mptTHkEmtNclvrfacP5HWpoZrxZZQ8djh21+CKaCzi7331c1mpq7Pt70mX0AkkOhT8EV xJLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764943313; x=1765548113; h=content-transfer-encoding:in-reply-to:content-language:from :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=ETP6ZwRR8d1hP4cNbKBiZUy+JiTc6tdkyie3Djet/bI=; b=HQ5ObiROC+/+m+dBpWgF59XDGAf6hDGUKAfAWZhA0EDw2Ng+Xj8NcYcywRUq7XfK2P 4rZoftqNBh+Ejr9lpqu1nZlAlqq1L+0LIpNAtbhn8CIVXfBj24dTQqjfAjqai6SKFiCN xE0Q1qn6NF3IBOPIj2P8XCgE8iFaCTAYmCKqv/eDMy9kQuuBalJ0KsFvRKPRasPe/NCZ 2wlBisvNdPwOC7K6S3V4w3JJF4XVRUfRIxFKFVSpM98O8AHD7SOoW9Tf+Aa/DCygf6Ar WCNKH/KkhYgc8FSfC0+rVEuFdm9oy6f3vWWpZN9O1egABknZCw6OScTxk8aPoVxF4IlJ DmCQ== X-Gm-Message-State: AOJu0YxIXxksH1ZdIPHaIsTD+4/Pb/Li7fRzM9eONmreXJxjDYqi8I3C sXbs81hTHPKtxBWFMP/U+vYb8N8O1UYRURnIjKNyMnTkfleRQnITuZ0E1jvUi4OMlTY= X-Gm-Gg: ASbGnct9eME4dEgRTGAb+N4INpH8/KhiyoKkKSG5FMEFJ3LdgbvcsAN0JTriPvDqSe8 o2vE52xQdeLARNpaueyQWCVUAN4GMcuOXfM2gv/+uU6eIl8ecx2r+jqkCFujFUsdMJUGBktbqrH +QOovQz0tLpK+sjanLI4o5RGCbyN2yDoOAF/iyt1dZXBUdSA07peDV6xd3trRk3Y6Z8aftcQWDG 2bJHsy10zv7mIimgGb+/4KqmHbuGnR/6a/cLGw0MobcX58BufeDNrx81cMz8/LxGiCHwrp/9qJN MWxHNQbRRDx/7xoXC4DBg0BhI5Q1bqaXFrFVL3q1C13DYEToIJQa5Pon0kMal+bmthz9wPhmtHz bCTvk7tm+ZwUeUH8yERPd9OVSGLyvMh9eF9+ScaWxR2iHb2udyXECy/c0z+PEdp0hORjkl3NEt+ 1qmaq8JvEJMkb0B4/m1DM= X-Google-Smtp-Source: AGHT+IHa0/JLkPmDvfwM24LUa6FS0JVCw0o6W9U9nEda9fVYcYWwSPyfk24Kk98oEUhOeULnAibMaQ== X-Received: by 2002:a05:6000:4287:b0:42b:2dfd:5350 with SMTP id ffacd0b85a97d-42f7985dc85mr7096458f8f.56.1764943313057; Fri, 05 Dec 2025 06:01:53 -0800 (PST) Received: from [192.168.50.4] ([82.78.167.134]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-42f7cbfeb38sm8828509f8f.12.2025.12.05.06.01.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 05 Dec 2025 06:01:52 -0800 (PST) Message-ID: <562eda90-6ca2-40b5-b1f8-fcc4034dd122@tuxon.dev> Date: Fri, 5 Dec 2025 16:01:51 +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 v2 0/2] reset: rzg2l-usbphy-ctrl: Add suspend to RAM support To: Biju Das , "p.zabel@pengutronix.de" Cc: "linux-kernel@vger.kernel.org" , "linux-renesas-soc@vger.kernel.org" , Claudiu Beznea References: <20251110132715.724084-1-claudiu.beznea.uj@bp.renesas.com> <19fda177-6c11-45d6-9dab-3f75edceda4e@tuxon.dev> <50937606-46fd-4202-ad4b-9ede5bff76fc@tuxon.dev> <52bf094a-a656-4bef-bb22-f903578ecf9b@tuxon.dev> From: Claudiu Beznea Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 12/5/25 15:45, Biju Das wrote: > > >> -----Original Message----- >> From: Claudiu Beznea >> Sent: 05 December 2025 13:30 >> To: Biju Das ; p.zabel@pengutronix.de >> Cc: linux-kernel@vger.kernel.org; linux-renesas-soc@vger.kernel.org; Claudiu Beznea >> >> Subject: Re: [PATCH v2 0/2] reset: rzg2l-usbphy-ctrl: Add suspend to RAM support >> >> >> >> On 12/5/25 13:55, Biju Das wrote: >>> Hi Claudiu, >>> >>>> -----Original Message----- >>>> From: Biju Das >>>> Sent: 05 December 2025 10:57 >>>> Subject: RE: [PATCH v2 0/2] reset: rzg2l-usbphy-ctrl: Add suspend to >>>> RAM support >>>> >>>> >>>> Hi Claudiu, >>>> >>>>> -----Original Message----- >>>>> From: Claudiu Beznea >>>>> Sent: 05 December 2025 10:47 >>>>> Subject: Re: [PATCH v2 0/2] reset: rzg2l-usbphy-ctrl: Add suspend to >>>>> RAM support >>>>> >>>>> >>>>> >>>>> On 12/5/25 12:17, Biju Das wrote: >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Claudiu Beznea >>>>>>> Sent: 05 December 2025 10:00 >>>>>>> To: Biju Das ; p.zabel@pengutronix.de >>>>>>> Cc: linux-kernel@vger.kernel.org; >>>>>>> linux-renesas-soc@vger.kernel.org; >>>>>>> Claudiu Beznea >>>>>>> Subject: Re: [PATCH v2 0/2] reset: rzg2l-usbphy-ctrl: Add suspend >>>>>>> to RAM support >>>>>>> >>>>>>> Hi, Biju, >>>>>>> >>>>>>> On 12/5/25 10:53, Biju Das wrote: >>>>>>>> >>>>>>>> >>>>>>>> Hi Claudiu, >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Claudiu Beznea >>>>>>>>> Sent: 04 December 2025 18:26 >>>>>>>>> Subject: Re: [PATCH v2 0/2] reset: rzg2l-usbphy-ctrl: Add >>>>>>>>> suspend to RAM support >>>>>>>>> >>>>> >>>>> From my previous experience with suspend/resume implementations, I >>>>> can say restoring the system in failure cases in suspend/resume or >>>>> not, is up to the subsystem maintainer. So, I'll let Philipp to >>>>> decide how he wants to go with it in this >>>> driver. >>>>> >>>> >>>> Agreed. >>>> >>>>> They are still supporting suspend to idle, where power is >>>>> maintained, right? Shouldn't we cover this case? >>>> >>>> Yes, I agree. Probably best thing is zero failures, if there is a >>>> failure in suspend path, the same device will fail in similar fashion, and the system never enters >> suspend state. >>>> >>>> So, report the failure and debug and fix the issue. >>> >>> FYI, On your resume path, if the below call fails, then there is a pm imbalance for next suspend(). >>> >>> ret = pm_runtime_resume_and_get(dev); >>> >>> Similarly, if reset_assert() fails for a shared reset. >> >> Wouldn't be the same if there will be no failure path code? Could you please reply to this question as I may be wrong? > > > Eg: > ret = reset_control_deassert(priv->rstc); > + if (ret) > + goto pwrrdy_off; > > Here you are skipping pm_runtime_resume_and_get(), The subsequent suspend() > Will lead to pm underflow error. > > Similarly, on suspend() you are checking the error code of reset_assert(), > If it fails, you deassert it. Surprisingly, there is no deassert operation > On resume(). Could you please share how would you like to look these functions? It looks to me that you want to ignore any operation that might fail (as you proposed in the case of resume from power off) and just re-enable everything, unconditionally. If that's the case it wouldn't cover all the cases, either. E.g., if resume looks like this: static int rzg2l_usbphy_ctrl_resume(struct device *dev) { struct rzg2l_usbphy_ctrl_priv *priv = dev_get_drvdata(dev); rzg2l_usbphy_ctrl_set_pwrrdy(priv->pwrrdy, true); reset_control_deassert(priv->rstc); pm_runtime_resume_and_get(dev); rzg2l_usbphy_ctrl_init(priv); return 0; } the rzg2l_usbphy_ctrl_set_pwrrdy(), reset_control_deassert(), pm_runtime_resume_and_get() may still fail and may still lead to imbalance refcounters for the next suspend execution or other scenarios. Thank you, Claudiu