From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) (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 EF7343EF643 for ; Mon, 17 Aug 2026 09:43:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786959810; cv=none; b=oP8IvTnXMTtCGz1GAwo1bkWr0nlpeWBY479wODvGaltLZ+JTGwYYPdpsyUiW0oC+Y+ZzGfCZwT+5kaASxUUQr24BVaYzDUWpm5sBjqEdeOyriFH5M23kTtc6ewkPl/O70/u7cjbAhHvE4tGBwaU+LGC4FKosbs7xTh4ssupEYY0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786959810; c=relaxed/simple; bh=AYV2llpwHVx2jpCfwLLNfUkWZvtKPwZ698vf4LkmWB4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=iGjeBCIdpnFda65ED4+giG8MkIIUApxcs6lC+abWBy2gA5FZ5F7to4Az0HtchgHvqhp0xNGFpAN4VbD0XhXySppPjfwIRhWOrcPUh9sSAIjb58DXSEQuLUW4W9Wuf0zpcQTbFxGUBXzFf7qbbC0KIBoeFvlrx4ZEf0+vXjsV8dY= 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=DIfuvWJ6; arc=none smtp.client-ip=209.85.128.44 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="DIfuvWJ6" Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-49552f516beso861535e9.1 for ; Mon, 17 Aug 2026 02:43:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786959803; x=1787564603; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=iJxT22zdZziRjbZwbed7OeV6jhdxmd27WO3H1gy/w60=; b=DIfuvWJ6zju3wW7Z8XHRffCrOWx1bsQYELMvpXppqd/DlTKlsixHXVgN1IhAuZwXYW LHi+b/S0cFHiFf+ohSTr0Z3ZbrRHOPTqerI0TF1XEMfqzBm9r73uyMScTf30pEH6CiPR nvMmeFJA9J2z7QePUo3acg7Q7Eo3J0N6Lv+l8Mzy6rhPod+UYw5NYecS1KBHaIMtQtqM xabOnPKtTpb61tkZye6EAwh9norucdtBU5zto91it3qtpmZV8sBHy/7MicVLiIhkRt4c J+aWbKZ6EkhdBcCQ1XSPanAMjCIGFvjR0nWuJw1lT+CIDip3woidjAWdNvMyEPNK2Em7 wsNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786959803; x=1787564603; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=iJxT22zdZziRjbZwbed7OeV6jhdxmd27WO3H1gy/w60=; b=soW/lvORLvYu9tT/P/FzAJGB/BpZXuvvDPl/ED8r2Ym8FEy/kAeY0FDhEg8DCXhH+4 l4F3DajuGGpwsUytaEhYnyzFvdTsIKHe6CTmXdQ/77O2EUpOCuwVPNpSkIBZ5OGGZb4I M+djFusQbUNKF49LhZ7nRjx806uNxKQyJs6iJLuARxpdWhnqQKqM/l1uCFyreCYTAUjF Yr2An9PJvYfYT2bsgBqIB8E/8k7cuWLrQLT3h02x4Td6AN3zHV/fIR673pWcqI3W5mSm MlL8ZVFFDBykbHFNI/6Ez4UZq3Ea8oHDSoALZxKVpz5cWyc5DFebxW3L/Z7vKl5964b3 zGjA== X-Forwarded-Encrypted: i=1; AHgh+Rp25wiXAQ7/JQmdYKk6g0mKXeZRpWsUtWStcJCGw5CvLTfCOjYESXB4WsivdehUAJyppqEalvLyqaST7as=@vger.kernel.org X-Gm-Message-State: AOJu0YwhIEMJWyhvfp3gsL7ccnftIVUnCgezeLBe4Rox0d4rkvvIkyvQ L3IxKBv4sc2UCmvXx2jmjxge2Jwtp2w4FbgaTdRZUEFADEoPVPl0ylLCzGObFA== X-Gm-Gg: AR+sD128rIiV7UbjBrV32WWcdLjT6jSAh+teC80/5LaPbCTEXgwtgOYyGcmygoLvuBF y6m5zFF+E+If0otn5uF1pO5/xw3NyLIBgEjHzWcUguDHiDObSn5qZqG/Yi7mpApcPEu5rxyAvaL xUu2GTBDws6wCrK0q1mI4wfKkA8J5AJEIh3RURn2pDjGmm9uI3FTLOoijo17PgzscvILzImgy5z BJP2m0Sv+rnRx2XNiOx7tvlmSZuWGPJeK97tNcFJ4sYp42WK+ROraWo/wVgh+ATGb/Q7AujC1oB OoBECyxZWYQURs6t918lYRQp1QKdq346DJYr6aLERo5Krd7ED6xJpKkIZQey/daNZvPZ56fmkWf y2/6uyWCc8o5LQrO+KVZuCHzdHapht3c+gQcFiDF3KDcGP1OSPVPBaVSOG+xIQVHD92b4JZFu6X 3NvuEwqkyDVP+/+sDBk5eHC+LsO+5sl/sXR7jhGxrxo1XgCHcTsPpWNskp+6QyoCTITVLycGaO6 dWrW9tTlZ3TaSnMbZTrAyliP8Xky8rpVvJUGs0ANn8a0wu71VSqtjJKCjQuLE88KTqXXw== X-Received: by 2002:a05:600c:8714:b0:498:8e6:d463 with SMTP id 5b1f17b1804b1-4998792fee6mr180593925e9.1.1786959802911; Mon, 17 Aug 2026 02:43:22 -0700 (PDT) Received: from OrangePi5-Plus.BB-HOME (20014C4E1B8FC50027494B64639367E4.dsl.pool.telekom.hu. [2001:4c4e:1b8f:c500:2749:4b64:6393:67e4]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-482a5b783basm2546509f8f.30.2026.08.17.02.43.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 17 Aug 2026 02:43:22 -0700 (PDT) From: Igor Paunovic To: Muhammed Subair Cc: Igor Paunovic , Heiko Stuebner , Sandy Huang , Andy Yan , Alexey Charkov , Sebastian Reichel , Ulf Hansson , Ulf Hansson , linux-pm@vger.kernel.org, linux-rockchip@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: RK3576: rockchip-pm-domain fw_devlink device-link failures for nested power-domain nodes Date: Mon, 17 Aug 2026 11:42:53 +0200 Message-ID: <20260817094258.23332-1-royalnet026@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Hi Subair, Your diagnosis is right, and the answer to your first question is: this is not RK3576 missing anything. RK3588 does the same thing. >From my Orange Pi 5 Plus on mainline 7.2.0-rc7, one line per boot: [ 2.215019] rockchip-pm-domain fd8d8000.power-management:power-controller: Failed to create device link (0x180) with supplier spi2.0 for /power-management@fd8d8000/power-controller/power-domain@12 Same driver, same 0x180, same nested-child path, different SoC. And the trigger on my board is a different property than yours: power-domain@12 and power-domain@8 here carry `domain-supply`, so the supplier resolves to the SPI-attached PMIC regulator rather than to `soc` via `clocks`. Two different properties on two different SoCs producing the same message is a fairly strong sign the cause is structural rather than a per-SoC DT omission. So I would drop your option 1. On the flags, for whoever picks this up: 0x180 is DL_FLAG_SYNC_STATE_ONLY | DL_FLAG_INFERRED, i.e. FW_DEVLINK_FLAGS_PERMISSIVE in drivers/base/core.c, and that value is taken on the branch where the fwnode declaring the dependency is not the device's own fwnode: if (con->fwnode == link->consumer) flags = fw_devlink_get_flags(link->flags); else flags = FW_DEVLINK_FLAGS_PERMISSIVE; which is exactly the nested-child case you describe. Worth noting that DL_FLAG_CYCLE is a separate bit, so a cycle-tagged link would print 0x380. More usefully: this has already been explained on-list. Sebastian Reichel answered the same message class for RK3588 on 12 June 2026, replying to Diederik de Haas's reports on nanopc-t6-lts, nanopc-t6-plus and Rock 5B (identical 0x180, power-domain@8 and @12, suppliers 2-0042 and spi2.0): https://lore.kernel.org/all/aixze8zFboY3huSf@venus/ His explanation is a cyclic dependency arising because all domains are provided by a single power-controller device: to probe the regulator you need the bus controller, which needs its power domain, which needs the power-controller, which needs the regulator. I would read that message before going further, and I would not treat this as cosmetic. He is explicit that it is "neither super bad, nor completely harmless", because the kernel ends up missing dependency information and pays for it in extra -EPROBE_DEFER rounds. He also says fixing it properly needs substantial restructuring of the Rockchip power-controller driver, which is a rather bigger answer than any of your three options. One last thing, and I mean it helpfully: I think you have mailed the wrong people. Your To: list is get_maintainer.pl output for drivers/gpu/drm/rockchip, which is why five DRM maintainers were on a power-domain question while the people who own it were not. For the subsystems you are actually asking about: drivers/pmdomain/rockchip/ -> Ulf Hansson, linux-pm@vger.kernel.org drivers/of/ (fw_devlink) -> Saravana Kannan, devicetree@vger.kernel.org I have added linux-pm and Ulf here, and dropped the DRM maintainers and dri-devel since the topic is not DRM. If you follow up, consider adding Saravana and devicetree as well, and run scripts/get_maintainer.pl against the files you are asking about rather than reusing a recipient list from another thread. That is most likely why this went five days without an answer. Regards, Igor