From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f194.google.com (mail-pf1-f194.google.com [209.85.210.194]) (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 1928B37416D for ; Tue, 3 Feb 2026 23:12:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.194 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770160377; cv=none; b=oGcVM0rVWi25Irm8fkN1rMfErEZOAVodDzMRThi29OazANkxOcdlawofnEkKAETytLTd44zLIdvXcYoUlcPCCXztj446rQyk3SRQLfvuRA3bNpWlj+6WVEFlNuAUiI1spkDZFtSSd+uWBLVuDZlhzQCH66XglzazUB/LxCQaQ38= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770160377; c=relaxed/simple; bh=b+6ezU8PaueXB2DpM+akcgePYGBcPLLporezIjuLT+g=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=p0IBhHluOyCPcnLUggn6/uEbPLdTY+kY0vAnZJhWFNEIuPxkf/0ZUplj6hLUFIKO87ZtonS7NbWbz61lqHLOrjtA0QNS51bME3qBOddlKOhucG8V6fUmwkgybePZQFL0It6GHCvp+vrgruXnZhCxgKQFfl6TBkDumsJHMW7C8rI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=baylibre.com; spf=pass smtp.mailfrom=baylibre.com; dkim=pass (2048-bit key) header.d=baylibre-com.20230601.gappssmtp.com header.i=@baylibre-com.20230601.gappssmtp.com header.b=gNFazDB1; arc=none smtp.client-ip=209.85.210.194 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=baylibre.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=baylibre.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=baylibre-com.20230601.gappssmtp.com header.i=@baylibre-com.20230601.gappssmtp.com header.b="gNFazDB1" Received: by mail-pf1-f194.google.com with SMTP id d2e1a72fcca58-81f4f4d4822so3145739b3a.3 for ; Tue, 03 Feb 2026 15:12:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20230601.gappssmtp.com; s=20230601; t=1770160374; x=1770765174; darn=vger.kernel.org; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:from:to:cc:subject:date:message-id:reply-to; bh=hCOjNNMnUuznv6tosNTA/iIRiTXu2wBeg3Ia+sthXnc=; b=gNFazDB1fEFOxYJalqDLQnf2a9KU5UxQM/7PkxkGtDV1nok7eq3eZveSWzBoI8jd7w 3aAy7gNFXbkum1bc1XR7TP4nvkqBrlIBd1CI8VTkEVJkgPBK0+i/vdf+VIou32iFFDoF 3FwjHmPqRIRcFbvdKe2QqpAlMUsCTEjyv6esizdi+gglNAoTdyJ/niobMbs67Gm7UkUq OgVkjl5lVs00rpiaKmLVRWhGiPFgOm10RJlOTgpv5DnIEHqWi2NkTgfPpAfyTSH3qq3d QilVD2rfiBGOZ9K8pSZpLnQOaANb2d/Tw+ykFOpAjPBNuZcJ7rDAGbJjxZCqvqX8NgRj 8vgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770160374; x=1770765174; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=hCOjNNMnUuznv6tosNTA/iIRiTXu2wBeg3Ia+sthXnc=; b=OGqYXd1U0cVpLhaj18pEw0pMwx/gAGQG+S8h5gSoUV6j6ZQP+49r2GBal9FCdGwtYN sLXPPU6J9M3bmQVHuVDj7HOcwDLBR3X3nmU3vVfrwuEBh6Xdf1fFxAyRC5PRAlEdoAV3 1hCy/YCJYRCSoS3/LuEGJgp4h1Rxi8ZrIJJY/SuKOZrzicO5DZdvlBByknjSgEs4KOz4 7rW5mH62xVkS8jNHwEbwhZDtHCHezzkZR2bepUyzuOMkzrOvkbNt1VoVQEbpoptcLMoL r3Fkgc0I+hL+TyirkC+P4STngFrfQInTTtGhJRSaegiksFDsVVekqYuyoTwotSbg6z0C XOtQ== X-Forwarded-Encrypted: i=1; AJvYcCXZhFrwFfCD9V01DVdSr1ZWoxYqcJ3hUAgDPaCDZb8Rqa0LQEpEMKWqOS+3JGFozgnzb7V2cVRTwOMoC4w=@vger.kernel.org X-Gm-Message-State: AOJu0Yxm3BsaBguizwk3azLOdKSt+JD3LlrheBOAaqBKKyN+f39+V4F9 +RQB7zutDpyXzCpWWzfQzBRIlyFouNwrJeGY708DkfyJgjNEmuBxlYeMS2uumv0AbPSaP8t+tNq 7uoQtGSQ= X-Gm-Gg: AZuq6aKg0kdtod4bpZUZfkjmL1DMXtVB8VtZ3V1+bU+wiQUH2yDwxOxHUVGagZqdUvK vPS8VY0lK80v9ZwT1uzftI7Ap5XFmfzBaKMGo9ZjOSqg+mpPflv9sW6aHTMQ/uf9CIsgJ4g24a+ //rZwwgvCq4alz/pdjHDBuDIZ1MU/NgQg9WZP+D7x59t/eeJRBLwi5ucU7euugPP/YtQf40d3l0 6cu4aAxs0WNJZf/UMsN7aoUMYMISTGeBwo4Ld7E2PfIXe9/eY+2RARmDSMIh7WER6R18hiRqw2i JVY8zt7YAWDg+Sn9PcRP/JPWcYZgcXl6vuZrIBVsYIR23Y1ICC6qEqlG1gdpm2oM1SUvTJx53VE +TfzgW4tydq/AV+C4vE7oAIEEYruF7bA5MRXAXYH49kFHP4kyKOUecFqrSO5RDOoBfFtlloeN/5 f6inwgmtLDtzWXjA+Uywg= X-Received: by 2002:a05:6a20:9185:b0:366:58cc:b74b with SMTP id adf61e73a8af0-393720cfdddmr966865637.21.1770160374489; Tue, 03 Feb 2026 15:12:54 -0800 (PST) Received: from localhost ([71.212.200.220]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-c6c84c70e08sm321672a12.20.2026.02.03.15.12.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Feb 2026 15:12:53 -0800 (PST) From: Kevin Hilman To: Rob Herring Cc: Ulf Hansson , "Rafael J. Wysocki" , Sudeep Holla , Cristian Marussi , devicetree@vger.kernel.org, linux-pm@vger.kernel.org, arm-scmi@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH RFC v5 1/2] pmdomain: core: support domain hierarchy via power-domain-map In-Reply-To: <20260127151735.GA1699112-robh@kernel.org> References: <20260122-pmdomain-hierarchy-onecell-v5-0-76855ec856bd@baylibre.com> <20260122-pmdomain-hierarchy-onecell-v5-1-76855ec856bd@baylibre.com> <20260127151735.GA1699112-robh@kernel.org> Date: Tue, 03 Feb 2026 15:12:53 -0800 Message-ID: <7hjywtzaiy.fsf@baylibre.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 Rob Herring writes: > On Thu, Jan 22, 2026 at 05:14:00PM -0800, Kevin Hilman (TI) wrote: >> Add of_genpd_[add|remove]_subdomain_map() helper functions to support >> hierarchical PM domains defined by using power-domains-map > > power-domain-map. No 's'. > >> property (c.f. nexus node maps in DT spec, section 2.5.1). >> >> This enables PM domain providers with #power-domain-cells > 0 to >> establish subdomain relationships via the power-domain-map property, >> which was not previously possible. >> >> These new helper functions: >> - uses an OF helper to iterate to over entries in power-domain-map >> - For each mapped entry: extracts child specifier, resolves parent phandle, >> extracts parent specifier args, and establishes subdomain relationship >> - Calls genpd_[add|remove]_subdomain() with proper gpd_list_lock mutex protection >> >> Example from k3-am62l.dtsi: >> >> scmi_pds: protocol@11 { >> #power-domain-cells = <1>; >> power-domain-map = <15 &MAIN_PD>, /* TIMER0 */ >> <19 &WKUP_PD>; /* WKUP_TIMER0 */ >> }; >> >> MAIN_PD: power-controller-main { >> #power-domain-cells = <0>; >> }; >> >> WKUP_PD: power-controller-main { >> #power-domain-cells = <0>; >> }; >> >> This allows SCMI power domain 15 to become a subdomain of MAIN_PD, and >> domain 19 to become a subdomain of WKUP_PD. > > One concern I have here is generally *-map is transparent meaning when > you lookup <&scmi_pds 15>, &MAIN_PD is returned as the provider. It's > also possible to have a map point to another map until you get to the > final provider. The only way we have to support both behaviors is the > consumer has to specify (i.e. with of_parse_phandle_with_args_map() vs. > of_parse_phandle_with_args()), but the consumer shouldn't really know > this detail. > > Maybe a transparent map of power-domains would never make sense. IDK. If > so, then there's not really any issue since the pmdomain core handles > everyone the same way. I don't really know enough about potential usage of maps to know if there's ever a usecase for transparent maps. However, the problem I'm trying to solve is less about transparent maps, and more about describing hierarchy in a situation where "leaf" domains of the same type (e.g. SCMI) can have different parent domains. When I first proposed this[1], I didn't use a map, but you suggested I try using a map[2]. So I'm not sure if I misunderstood what you proposed, or if now that you see it implemented, you're second guessing if the map is the right approach. Kevin [1] https://lore.kernel.org/r/20250528-pmdomain-hierarchy-onecell-v1-1-851780700c68@baylibre.com [2] https://lore.kernel.org/r/20250528203532.GA704342-robh@kernel.org