From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj2-f2.google.com (mail-pj2-f2.google.com [74.125.227.130]) (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 58BA03F871C for ; Tue, 21 Jul 2026 01:55:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.227.130 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784598902; cv=none; b=CnFMJF1clrfQ/DGL38avizK6UqrXJDhRVJyuGqPrg/sAakzmjFIxb5D2ETU3rp8JwuJtB4sUbX0h3QhpqmT5+69veqTdxemdTrAUPZHCRIXgTJOjq7as9V1TyrixDlzAPxXHCGhyVIwJT6owmNTjAS+rmuMu1Cksg3P8zyrHA3k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784598902; c=relaxed/simple; bh=CmwH/B0PtnzgfGqG8j8e2Mypnvqls/YlFIwqIJNUr1I=; h=Date:From:To:CC:Subject:In-Reply-To:References:Message-ID: MIME-Version:Content-Type; b=WpnnhAKLIJU7hI9xIOZmJXqdNdimhc3B6AZYPqKjmTTCJV461LrBpI3tys2MQkN9lpDZkUzm5Qp5ggr7A36LJyHgcTxtg0NVk14912nbgH5dO6AyD49JA5HEKlO+i5zWXTEzT14jtGs2Srf/9xK0kyMkAlRmPwFc0f0kZY94Wgs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=GrvXjHlX; arc=none smtp.client-ip=74.125.227.130 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="GrvXjHlX" Received: by mail-pj2-f2.google.com with SMTP id d9443c01a7336-2ccc2e84048so63305865ad.1 for ; Mon, 20 Jul 2026 18:55:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784598900; x=1785203700; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:message-id :references:in-reply-to:user-agent:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to:content-type; bh=ffAaSrXTHoX1nF2FpytraIRkGW9osx4fNIumZb54aqE=; b=GrvXjHlX96cF/nN+KFdLoOZ+fxYBMYUTIhg9gYjxgWebsenRph3E6QaqDEVcsxkD7H pbf26lyy4Ow0i+NU7fvww839p9SDSG0hTVjU4BG2Qp22xnA2FG0cAJx6ueZDIB9eU1dX iOk7V6/C656CHz7euR7a5Nr0nbGLSXkUelY0a5r4737aHnhE7l71jY2wjrz5uEFzHYCY iEDNOTHAVFRDj5EiUZEXllqhPI37cXxQMHd0puUhizsWSp1jgVFOWCj4eELcHO54gL4/ 5sPsGV/V1FzTUWhOW7YCyPIz0PopymVADdfN7RBnLOUsNejEPve8JabGaEHSXCpmX9kp 9P8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784598900; x=1785203700; h=content-transfer-encoding:content-type:mime-version:message-id :references:in-reply-to:user-agent:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=ffAaSrXTHoX1nF2FpytraIRkGW9osx4fNIumZb54aqE=; b=q4tYh1bccVhrDFobFKqGcXsuajqQuLMJfbF18KzwucvLIdzuu7YMz1hvqGRlGyDYwO zsEdGa+XKPfBNo+ucOMvv7FpDD7hBsQmQM3sutFpXfHASMqjL6UXL5qs9+AxvdKr/PBW p+muKRGZejHq0Wi+SQpQtjcpE5wYhC/ZOqXEbV/6ugSAARvgJqPRcObQ9xME76FQVrIa ghtHTEI152P5RAFi7ARly/GJCPHNZkGFd+MGtHh+shFvm93VtLFQnPe1RdoOXV1yIWAB JEnIw3n0M5s7icO1dhB+c+K1oxFpYaO8gKsFJmEPtVw9pSiM1ekiEyIsown1CbKXW/Q6 5KMg== X-Forwarded-Encrypted: i=1; AHgh+RoTk35FU3A6+LB/pK3Nmpri0cJNue4+GZY+uRSnAIeP0cwXL+25QTyMU7RYiTC8B2eIZr6aHGKF9MNF/gc=@vger.kernel.org X-Gm-Message-State: AOJu0YzMG4UrsnIaVpaGHpLbhnuBHpgGCVtPrB+Hjm4h5+HjWY57Fs/x SzQxO+qS2o97aMOj6FTMchZHKMXOSaYEJm5+fI47QG4SamZEp22IZIqg X-Gm-Gg: AR+sD1308uI9YvDTf3rWjP8zRkp6dZK+9aZz2IoHYgmbffOPMHMxsJKlP7+ukJ9nwHx /eeE3TqN4vH3+PYAlFCUUhxsYDQni2o88fXXgObBbjN57b2a7BMOUWS/CLYYuiEYGAH0SR/Cb+T DmfbQuf9GncxIscoqPMmo2H/+/6pPwbPgaszkUNrDj2qB0Yjd4YW25W1ioT0b/asZL2+Pw0pl8M 4jbaStExsWWZWxNJlIcVNkUcFDVG5KDBBPH9TBMRHIknedoT7Wo9UUHxFFMbOo2Wl980cnAcXGd G9LSq5Yj96wMyIlTo3AoiqPcPr20d/Anj3Gtf/R7orcE3mGkOFs64MNf+7EXma5QggFPb2Ra4oc Qz5Jz9fkVu7fBgGoVxVweSvlq94Fl72G8EoIklnFCQmWf9uvrtqkdf8LXy0+OpQte24+MYM09Uc 8= X-Received: by 2002:a17:903:3c4e:b0:2cc:9179:335 with SMTP id d9443c01a7336-2cf3481b661mr171881705ad.8.1784598900381; Mon, 20 Jul 2026 18:55:00 -0700 (PDT) Received: from ehlo.thunderbird.net ([2603:c021:8000:9500:233::14]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2cf344b1ef8sm68539495ad.21.2026.07.20.18.54.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 20 Jul 2026 18:54:59 -0700 (PDT) Date: Tue, 21 Jul 2026 09:53:53 +0800 From: Coia Prant To: Jakub Kicinski CC: netdev@vger.kernel.org, Andrew Lunn , Heiner Kallweit , Russell King , "David S . Miller" , Eric Dumazet , Paolo Abeni , Serge Semin , linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH] net: pcs: xpcs-plat: fix runtime PM initialization User-Agent: K-9 Mail for Android In-Reply-To: <20260720172433.77b83dc7@kernel.org> References: <20260704214808.1566710-1-coiaprant@gmail.com> <20260720172433.77b83dc7@kernel.org> Message-ID: <7BA9366A-3243-4A46-BA8F-BB170C8AD912@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On July 21, 2026 8:24:33 AM GMT+08:00, Jakub Kicinski w= rote: >On Sun, 5 Jul 2026 05:48:08 +0800 Coia Prant wrote: >> The driver calls `pm_runtime_set_active()` before runtime PM is enabled= , >> and before the clock is prepared and enabled=2E >>=20 >> This causes the clock to be unprepared/disabled later in the suspend >> callback even though it was never prepared/enabled, resulting in warnin= gs: >>=20 >> clk_csr already disabled >> clk_csr already unprepared >>=20 >> Fix this by setting the initial runtime PM status to SUSPENDED instead >> of ACTIVE=2E >>=20 >> The clock will be properly enabled when the device is first resumed >> via runtime PM (e=2Eg=2E, during MDIO access)=2E > >Seems a bit odd that this hasn't been discovered until now=2E >Could you add more details about your platform and maybe >a hypothesis why we haven't noticed? Hi, I came across what looks like a runtime PM initialization issue while using pcs-xpcs-plat=2Ec as a reference for the Rockchip XPCS glue driver (drivers/net/pcs/pcs-xpcs-rk=2Ec)=2E The current code in pcs-xpcs-plat=2Ec does: pm_runtime_set_active(dev); ret =3D devm_pm_runtime_enable(dev); This sets the initial PM state to ACTIVE before runtime PM is fully enabled, and before the clock is prepared and enabled=2E If the device is later suspended (e=2Eg=2E, during unbind), the suspend callback may try to disable a clock that was never enabled, leading to: clk_csr already disabled clk_csr already unprepared On Rockchip platforms, the CSR clock (PCLK_XPCS) is required for register access, and this pattern seems problematic when a clock is actually provided=2E I have a few questions: 1=2E Is there a reason this hasn't been noticed before? As far as I can tell, there is currently no mainline device tree user that enables this driver on a platform with a real clock dependency=2E Out-of-tree users might be using it without any clock at all, or ACPI users might behave differently=2E 2=2E Should we select PM in Kconfig and drop __maybe_unused from the PM callbacks? Since this driver relies on runtime PM for clock management, it seems odd to allow !PM builds=2E 3=2E Should we add a =2Eremove callback to force suspend the device on unbind? Otherwise the clock might remain enabled if the driver is removed while active=2E I'm happy to send a follow-up patch addressing these points if you agree with the direction=2E Let me know what you think=2E Thanks, Coia