From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) (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 83CC32749DF for ; Fri, 16 Jan 2026 08:50:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768553452; cv=none; b=q6xb0rf+u7K3nPkJ1p6Ttl6A2Al0b/jE19mQmMC9opzn0Cp9LniEQcJ6R3Alga8vMayUT5FE5E/t93N2XPngsMIpttB6Q0w839H5nUqP3GUj/gnmo8RDhQtODVwwqe9uy4VW2WOGzJAZ2dM6iKYsx3Sh8QqAuxoZH5alrkLbhyA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768553452; c=relaxed/simple; bh=IxxkAHO4EnPiHaHTmJj8q4lvkE9SooXBNoQmhRF6Nyk=; h=Message-ID:Date:MIME-Version:Subject:From:To:Cc:References: In-Reply-To:Content-Type; b=BOT2Zk9KdiIU0DUGNcAXegLiZPJgAJpc3iLDQh3bck6DmPKWP4QSIJrZVu5eRUfPHjt+fouzXF+Ze6TCQJMB7bBJLlDUbjZnf8jGaw3AyenkbMNr8+izzOcPU65FGnyRBZFJcgfsoh1wHncSUVbNAP2sPucJ5wsAczBnXGUGv6Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=zvBuCoPB; arc=none smtp.client-ip=209.85.128.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="zvBuCoPB" Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-4801eb2c0a5so4423285e9.3 for ; Fri, 16 Jan 2026 00:50:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1768553450; x=1769158250; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:from:subject:user-agent:mime-version:date:message-id:from:to :cc:subject:date:message-id:reply-to; bh=pXXyXgD5w4PG1Vior3rmQ9g78aObU3Raj1nrRdpjO4M=; b=zvBuCoPByJXT9NLYNA68cAungP0ITFpI66ZhsO+5vkuZ5N1TpAFG+ih63w5C76MILC G61Se8IF2SxC68Nr71xtzdG6xwL6Krchlw3SKkG22w1/NVpTUfbQ7A3n542Jt4LYu4tJ KKE33g1lXRqwinONAfe+l4Imp2CHXhDwiwWImNeogjaql4y4C1SeqN9RTOR3hpGAwGtH FnD7wBcDWaeZ5S8mJeHkeq/F8LvWJ5qtmtToGx4k0BhjDiInimIo+0MWgj9aVK/JXOh0 ocunQbzUYBnIW/U6KMNGP+QgT/8TpTn63eKTh9NNJOBhaNNr29RlKwXLGxwlUNnfveI7 QaOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768553450; x=1769158250; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:from: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=pXXyXgD5w4PG1Vior3rmQ9g78aObU3Raj1nrRdpjO4M=; b=ReH93v5RzCD7tA15XUqitdvqcyH/qDQVJuf2aEtB9PX4h6RQeuo5LSm+1PhcXQeYLI gIiJqnaX1Hwa93fUD5nel5V777xJUxMitytFg2ikv5IBaFCK94ix56byp7u8uKuXpbGc k59rmGB6sCZ7QBt4VBlD6OksvskKr69YQ1nkSd/FeUVQ1npnLupfLfNzi4eKU1MzwT9w p2DjbJndBApnvq2TjsN+9RquhcPcyzzZtLOPkgud6iCxKNoz6abAYUyKdo0Ez4tW2mEr 83bl5gt63P6bG9gLYxBAOIDr9ZoY5db/Kv1VrraxJvjvkrUzPA3BWChthSMTekbNmnGo eDZw== X-Forwarded-Encrypted: i=1; AJvYcCUWI4QYUy6IJcoWff0OTYA717J0jP/T7k6H/DY4LIig46A1KiO8SdCFFA1IaVTAAp0uu+Ivk58V+h/LYfg=@vger.kernel.org X-Gm-Message-State: AOJu0Yzx7TLwYC6DXWtHUtQqMGBr72ruI+mRVM0x/aUezjTTpdH5Nnii 660d8gu/oDfb5yO5z+ZHO4+4MxUbEtqfknfHzH5vWddy+/0zlepTdkqCExiiWhvlSlY= X-Gm-Gg: AY/fxX5eq0kdOu5DM10M4zm9ye3ClubPUpqHvCuoZxClmcUitYCxZDBw2oQc12dKv9U cUbu/AjoS0RFh2lBGNcR4AMZetmZW9PdyqD0fjpX3dPdd4rxUPqnTxBbjHvlXt8jLpaeC5m3Is4 MztuunliIDVGuxcnrf1MOOpGp8d1REsXz59Qb1FDCeNgpaR2gJr33Lmqq2K782tyYGPInXLQt0E /NevexqF125Iav9pQTD6srJZyNkqIP4ILObi8iZQCUM7EHDTrQcyOWGD2UtOXFPRgl3gMSazBhC 7mXCBi4WUIHiUFpV8HOuYtAfYk/rUkkNF1GnpdxvGscbHzso0v/JU4Ib5aSfjOhq1XTPhAUreuU pWjkAhUzPetIlpSIAmnRQD4xc9haE6aA4aLKjd0YvsP/Bx+nbYKMRMs6GwbHRiW06BBGzEFsJ4r bJ+gLwboIrS+RHL1vNUw== X-Received: by 2002:a05:600c:414f:b0:480:20f1:7abd with SMTP id 5b1f17b1804b1-48020f17c12mr10430535e9.31.1768553449885; Fri, 16 Jan 2026 00:50:49 -0800 (PST) Received: from [10.11.12.107] ([86.127.43.8]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47f4b267661sm87966875e9.13.2026.01.16.00.50.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 16 Jan 2026 00:50:49 -0800 (PST) Message-ID: <26d86470-aaa2-46e3-9940-010a903df4fd@linaro.org> Date: Fri, 16 Jan 2026 10:50:47 +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 3/8] dt-bindings: mfd: Add Google GS101 TMU Syscon From: Tudor Ambarus To: Krzysztof Kozlowski Cc: "Rafael J. Wysocki" , Daniel Lezcano , Zhang Rui , Lukasz Luba , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Lee Jones , Alim Akhtar , Peter Griffin , =?UTF-8?Q?Andr=C3=A9_Draszik?= , Bartlomiej Zolnierkiewicz , Kees Cook , "Gustavo A. R. Silva" , willmcvicker@google.com, jyescas@google.com, shin.son@samsung.com, linux-pm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, linux-hardening@vger.kernel.org References: <20260114-acpm-tmu-v1-0-cfe56d93e90f@linaro.org> <20260114-acpm-tmu-v1-3-cfe56d93e90f@linaro.org> <20260115-slim-denim-potoo-cad9cb@quoll> <200d34bf-150e-4f8a-b400-2f54863502ac@linaro.org> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 1/15/26 6:10 PM, Tudor Ambarus wrote: >>> I'm going to link the ACPM TMU child node with the TMU node via a >>> "samsung,tmu-regs" property. >> This could be fine, but I actually wonder what's there. What registers >> exactly. For example modern Exynos 88xx, already with APM block, still >> have exactly the same TMU unit at 0x1008{04}000 with all typical >> triminfo, current temperature and thresholds. >> > It's the same for gs101, the TMU instances have all the typical registers, > it's just that everything is handled via ACPM but the intpend registers. I could still use some guidance, Krzysztof, thanks for the help so far! Based on the current feedback I was going to propose the following description: soc: soc@0 { tmu_top: thermal-sensor@100a0000 { compatible = "google,gs101-tmu-top"; reg = <0x100a0000 0x800>; clocks = <&cmu_misc CLK_GOUT_MISC_TMU_TOP_PCLK>; interrupts = ; }; }; firmware { acpm_ipc: power-management { compatible = "google,gs101-acpm-ipc"; thermal-sensor { compatible = "google,gs101-acpm-tmu-top"; samsung,tmu = <&tmu_top>; #thermal-sensor-cells = <1>; }; }; }; GS101 handles the thermal sensors in a hybrid way: it uses the TMU IP block to read the INTPEND registers, and everything else is handled via ACPM calls. There's also the abstraction that one ACPM sensor is comprised of multiple physical TMU sensors. My concern now is that the ACPM TMU child node is not hardware per se, but just a firmware abstraction (One-to-Many sensors). If everything was handled via ACPM, without the need to read the TMU's INTPEND registers directly, I would have describe the sensor just as an ACPM child. Because of the hybrid approach I'm arguing the ACPM child node does not fully describe the hardware, and it's just a firmware abstraction. So option 2/ would be to have just the TMU IP block described with a phandle to the ACPM IPC: soc: soc@0 { tmu@100a0000 { compatible = "google,gs101-tmu-top"; reg = <0x100a0000 0x800>; clocks = <&cmu_misc CLK_GOUT_MISC_TMU_TOP_PCLK>; interrupts = ; /* The "Firmware Phandle" approach */ samsung,acpm-ipc = <&acpm_ipc>; #thermal-sensor-cells = <1>; }; }; Which one do you think it better describes the hardware? Thanks! ta