From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f171.google.com (mail-pf1-f171.google.com [209.85.210.171]) (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 E3A6F33F5B4 for ; Wed, 1 Apr 2026 02:52:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775011972; cv=none; b=sI0y5TIBWp0G1lNKoSvrTWWK7eCkbfQRHakKZVAm6y4QGSVPsFVkcaZJ2/JxGcvr5nVheHKMPYfXiiAnnvJ3435qXDfX/Y+uYB4SEInvNhpi6oUfvACxZe0WY4D7Ry415qShGCaE82dH82kTweDfa2DeYprc5Myre41ztWt8d1s= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775011972; c=relaxed/simple; bh=vKesLwcwWY6NcoP+fdXjgJXgpybwD+nmbppg/Nc8390=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type: Content-Disposition; b=iukyubiLciFbaiOd7UAqr1aAXlUgpjvop3u94ZGmF9FbC58sMCOtEPxHE03gnYo1kCxrtW2znaZgkQfU+ygMuAWxuclCMF3yC0zTxpbjNsZLXJXE6gb1+O5yBumT/TXQWRNNg/B62S1kOmbCIulTFifi8nLELo3d6pVDtuBvTTQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=orb.net; spf=pass smtp.mailfrom=orb.net; dkim=pass (2048-bit key) header.d=orb-net.20230601.gappssmtp.com header.i=@orb-net.20230601.gappssmtp.com header.b=uUPj5g4Z; arc=none smtp.client-ip=209.85.210.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=orb.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=orb.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=orb-net.20230601.gappssmtp.com header.i=@orb-net.20230601.gappssmtp.com header.b="uUPj5g4Z" Received: by mail-pf1-f171.google.com with SMTP id d2e1a72fcca58-82c2239140aso2578129b3a.0 for ; Tue, 31 Mar 2026 19:52:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orb-net.20230601.gappssmtp.com; s=20230601; t=1775011963; x=1775616763; darn=vger.kernel.org; h=content-disposition:mime-version:message-id:subject:to:from:date :from:to:cc:subject:date:message-id:reply-to; bh=20Mz45WcJH9ziI7hDt00QqO2FOFl1B6yMCjToNQfBoc=; b=uUPj5g4Z6UuwZFBTcWwQ29MxwmsGvB0dinXpteP2bOwrdLV2fR5KXgmJsqoimbHCtI DbnN9MkNAAxEBFULe02/ZuCM6bOtpKDfdUsgNnRqWd/taHlb48pyeg2abtRxyNcwIqei 1ysBFuSUODycbQAFbCxgd8fSSrS7R4hYsHmYWsFayhJzO5ki7p8Ctyz9e03kZtQG/GJL iPwcGiBX3HZBDt7IGUpZI1N6YVe0YvTM7d447GYPkbK1SgeI3PIDidqTv9lKxe4p68P/ BHBG+D1nuHx/+pMQgigFQPa9TuS0T8Q/7BcaI+XjTX+svzlGDYL8Rx+FFPtb2KkSM9qG F1KA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775011963; x=1775616763; h=content-disposition:mime-version:message-id:subject:to:from:date :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=20Mz45WcJH9ziI7hDt00QqO2FOFl1B6yMCjToNQfBoc=; b=Hab5WJKAWE8nKeHTSbzJTElmPWsDJ0FElblfbmt37U80hhU7Jb3KsuPTaFwGfMoVU3 Q7BTYN9EUBz/ijblQ29zc8zJuR0VdqsAaaQ8ujc1Pf5sH0rMML6tK+HBMJrG+YVy2zrN l5PbK1MRiLyOf1br0spGMfn9pN8Yfob/sWGtyCW562j0ZZN9BsmjMXLmHylg8OumBaNH apdJ1oVP3Cj2MaBhiBogsAK+kHYZ5Gmka3ID+QHoQxLUPuD8OCcvViOLrTTyV/0hnurR vzs9BAKvxkSJ2WOCFE2lfYckWMFlFduLSxZmIPz7GOI5sq5zrMfCDN0cdz13JKfWYZJ8 PO1w== X-Forwarded-Encrypted: i=1; AJvYcCXSdG0h456sFDpLjnxRZdTwmEIzonZ5vxQA7i3nQcC9XO67RTqre+FSIa8tPmfRSB/8zWrH8fTRpt2qXA0=@vger.kernel.org X-Gm-Message-State: AOJu0YxNMw6YZnCMQFlvM8edQ7ET6lQhg0bhNiPO/uF8yZUwHx4PvReI GAvgyHXCHBOF5mptNSGVVgplh0hoEwG+ootLD4KB/bObuOeyYSflXSE1EK0vxARC2zU= X-Gm-Gg: ATEYQzzd4gyCE2SKxh/FBmmokZSxAn26K8NUGPihDE5K/3KFh1HZDNUTV4i6AaIAewi y2z3xarx3TehREa25cwZ5pyORC8c1n/Wh/tGq2YpjFfqmls/Zq3ew7D0DhF/YPeX0mKsj1EOeuz RZ17WWKusi4hZ+buAHOI+sw+QlG/u5n9Ay1iNTevuXDgLyqsGcYZXCCQIBehUmV31Me/Z/yh31j c6/4GEJ6ltSopPErRnqM07hyOzJB28Pg+iYpIBKjJXZ+6C02X+mpla4d/QC16KmhbiwDI5KJRgV oljwDOj1k9cNz1jFSkD4pvhhtVy9VijM2S/G+WUjrUuIja/cQuvDeuUVNap186aMnwE9TYaXiCW 2rQIWcTA9VGbgT8w5IdAC8bx4HxVVOrg8Q7kzOp+Tx0E5HMZVkrZjVnI/62bk1YOzs8fhO0rB2N OxfFo3+F/1CD0EVFV022SSrSc1G46l5bO108MQQrAegd6UDivKuZatR8ivBgCb4qETgXkAwAJu X-Received: by 2002:a05:6a00:2e94:b0:827:441a:c970 with SMTP id d2e1a72fcca58-82ce88ea395mr2028303b3a.6.1775011963217; Tue, 31 Mar 2026 19:52:43 -0700 (PDT) Received: from claude-dev ([50.125.94.20]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-82ca846e08dsm11917878b3a.24.2026.03.31.19.52.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 31 Mar 2026 19:52:42 -0700 (PDT) Date: Wed, 1 Apr 2026 02:52:42 +0000 From: Daniel Bozeman To: ulf.hansson@linaro.org, heiko@sntech.de, linux-pm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] pmdomain/rockchip: skip QoS operations for idle-only domains Message-ID: 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=us-ascii Content-Disposition: inline The NanoPi Zero2 (RK3528) kernel panics during boot when a GPIO-controlled USB VBUS regulator is defined on GPIO4 (which is in PD_RKVENC). The goal of this series is to make USB host power work on boards that use GPIO4 for regulator control. The root cause is a probe ordering issue. On RK3528, the power domain controller's first probe attempt fails because PD_GPU's clock lookup returns -EPROBE_DEFER (CRU hasn't probed yet). The driver then tears down all domains, including PD_RKVENC which would have registered successfully (it has no clock requirements). During this window, the USB regulator driver probes and requests GPIO4, which is in the now-unregistered PD_RKVENC -- this triggers a synchronous external abort. With patch 2 alone (skipping deferred domains), the idle-only domains register successfully. But the genpd framework then attempts to power them off via genpd_power_off_work_fn. This calls rockchip_pd_power(), which does QoS save and idle requests on domains with pwr_mask == 0 that cannot actually be powered off. To your question about why QoS registers become inaccessible on idle-only domains: I have not root-caused that specifically. What I can confirm is the crash trace below, which occurs when patch 2 is applied without patch 1. The abort happens during rockchip_pmu_set_idle_request on an idle-only domain: Internal error: synchronous external abort: 0000000096000010 CPU: 2 PID: 60 Comm: kworker/2:3 Workqueue: pm genpd_power_off_work_fn pc : regmap_mmio_read32le+0x8/0x20 lr : regmap_mmio_read+0x44/0x70 Call trace: regmap_mmio_read32le+0x8/0x20 _regmap_bus_reg_read+0x6c/0xac _regmap_read+0x60/0xd8 regmap_read+0x4c/0x7c rockchip_pmu_set_idle_request.isra.0+0x94/0x1b4 rockchip_pd_power+0x37c/0x608 rockchip_pd_power_off+0x14/0x38 genpd_power_off.isra.0+0x1f0/0x2f0 genpd_power_off_work_fn+0x34/0x54 The two patches work together: patch 1 prevents QoS access on idle-only domains, and patch 2 prevents the full probe teardown when a single domain defers. Tested on NanoPi Zero2 (fixes panic) and Radxa E20C (no regression).