On 25/04/2022 07:01, Rex-BC Chen wrote:

On Sat, 2022-04-23 at 18:28 +0800, Krzysztof Kozlowski wrote:

quoted

On 22/04/2022 08:01, Rex-BC Chen wrote:

quoted

To support reset of infra_ao, add the bit definition for
thermal/PCIe/SVS.

Signed-off-by: Rex-BC Chen <redacted>
---
 include/dt-bindings/reset/mt8192-resets.h | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/include/dt-bindings/reset/mt8192-resets.h

b/include/dt-bindings/reset/mt8192-resets.h
index be9a7ca245b9..d5f3433175c1 100644

--- a/include/dt-bindings/reset/mt8192-resets.h
+++ b/include/dt-bindings/reset/mt8192-resets.h

@@ -27,4 +27,14 @@
 
 #define MT8192_TOPRGU_SW_RST_NUM				23
 
+/* INFRA RST0 */
+#define MT8192_INFRA_RST0_LVTS_AP_RST				

0
+/* INFRA RST2 */
+#define MT8192_INFRA_RST2_PCIE_PHY_RST				
15
+/* INFRA RST3 */
+#define MT8192_INFRA_RST3_PTP_RST				5
+/* INFRA RST4 */
+#define MT8192_INFRA_RST4_LVTS_MCU				12
+#define MT8192_INFRA_RST4_PCIE_TOP				1

These should be the IDs of reset, not some register values/offsets.
Therefore it is expected to have them incremented by 1.

Hello Krzysztof,

This is define bit.

There is serveral reset set for infra_ao while it's not serial.
For MT8192, it's 0x120/0x130/0x140/0x150/0x730.
We are implement #reset-cells = <2>, and we can use this reset drive
more easier.

For example, in dts, we can define
infra_ao: syscon {
	compatible = "mediatek,mt8192-infracfg", "syscon";
 	reg = <0 0x10001000 0 0x1000>;
 	#clock-cells = <1>;
	#reset-cells = <2>;
};

thermal {
	...
	resets = <&infra_ao 0x730 MT8192_INFRA_RST4_LVTS_MCU>;
	...
};

If it's acceptabel, I can update all bit difinition from 0 to 15 for
all reset set.

Bits are not acceptable, because you embed specific device programming
model (register bits) into the binding.

These should be IDs, so decimal numbers incremented from 0, so:
#define MT8192_INFRA_RST0_LVTS_AP_RST				0
#define MT8192_INFRA_RST4_LVTS_MCU				1
#define MT8192_INFRA_RST4_PCIE_TOP				2

And what is 0x730 in your example? It does not look like ID of a reset...

Entire changeset look wrong from DT point of view.

Best regards,
Krzysztof

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel