[PATCH v3 0/9] Introduce HDP support for STM32MP platforms

[PATCH v3 0/9] Introduce HDP support for STM32MP platforms

[Clément Le Goffic]

This patch series introduces the Hardware Debug Port (HDP) support for
STM32MP platforms.

It includes updates to the mmio gpio driver, the addition of device tree
bindings, the HDP driver, and updates to the device tree files for
STM32MP13, STM32MP15,
and STM32MP25 SoCs.
The series also updates the MAINTAINERS file to include myself as the
maintainer for the STM32 HDP driver and adds the necessary
pinmux configurations for HDP pins on STM32MP157C-DK2 as example.

Signed-off-by: Clément Le Goffic <clement.legoffic@foss.st.com>
---
Changes in v3:
- Use `bgpio_init()` function:
    - Add add patch to create the `BGPIOF_NO_INPUT` flag needed for the
     `bgpio_setup_direction()` used in `bgpio_init()`
    - Remove `stm32_hdp_gpio_get` and `stm32_hdp_gpio_set`
- Use `static` pm ops
- Update bindings:
    - add pattern instruction for pin values
    - remove function's maxItems to use `function: true`
    - fix the compatible in the exemples
- Link to v2: https://lore.kernel.org/r/20250520-hdp-upstream-v2-0-53f6b8b5ffc8@foss.st.com

Changes in v2:
- Remove bindings header files with function name as #define
- Add match_data with function name for three compatible:
  "st,stm32mp131-hdp", "st,stm32mp151-hdp" and "st,stm32mp251-hdp".
- Rework a bit the driver to use match_data.
- Remove the use of `dev_err_probe(` in the resume ops.
- Remove `MODULE_ALIAS(`.
- Remove the vertical bar in bindings description paragraph.
- Fix an error in the `pinctrl-0` parameter of the binding example, it
  was refering a node that wasn't existing.
- Use uppercase pin names.
- Link to v1: https://lore.kernel.org/r/20250225-hdp-upstream-v1-0-9d049c65330a@foss.st.com

---
Clément Le Goffic (9):
      gpio: mmio: add BGPIOF_NO_INPUT flag for GPO gpiochip
      dt-bindings: pinctrl: stm32: Introduce HDP
      pinctrl: stm32: Introduce HDP driver
      MAINTAINERS: Add Clément Le Goffic as STM32 HDP maintainer
      ARM: dts: stm32: add Hardware debug port (HDP) on stm32mp13
      ARM: dts: stm32: add Hardware debug port (HDP) on stm32mp15
      ARM: dts: stm32: add Hardware debug port (HDP) on stm32mp25
      ARM: dts: stm32: add alternate pinmux for HDP pin and add HDP pinctrl node
      ARM: dts: stm32: add Hardware debug port (HDP) on stm32mp157c-dk2 board

 .../bindings/pinctrl/st,stm32-pinctrl-hdp.yaml     | 187 ++++++
 MAINTAINERS                                        |   6 +
 arch/arm/boot/dts/st/stm32mp131.dtsi               |   6 +
 arch/arm/boot/dts/st/stm32mp15-pinctrl.dtsi        |  25 +
 arch/arm/boot/dts/st/stm32mp151.dtsi               |   7 +
 arch/arm/boot/dts/st/stm32mp157c-dk2.dts           |   6 +
 arch/arm64/boot/dts/st/stm32mp251.dtsi             |   7 +
 drivers/gpio/gpio-mmio.c                           |  11 +-
 drivers/pinctrl/stm32/Kconfig                      |  14 +
 drivers/pinctrl/stm32/Makefile                     |   1 +
 drivers/pinctrl/stm32/pinctrl-stm32-hdp.c          | 720 +++++++++++++++++++++
 include/linux/gpio/driver.h                        |   1 +
 12 files changed, 990 insertions(+), 1 deletion(-)
---
base-commit: a08b2b34239e63bd839078de98911d3653cdab83
change-id: 20250224-hdp-upstream-622e5da14a9f

Best regards,
-- 
Clément Le Goffic <clement.legoffic@foss.st.com>

[PATCH v3 1/9] gpio: mmio: add BGPIOF_NO_INPUT flag for GPO gpiochip

[Clément Le Goffic]

When using bgpio_init with a gpiochip acting as a GPO (output only), the
gpiochip ops `direction_input` was set to `bgpio_simple_dir_in` by
default but we have no input ability.

Adding this flag allows to set a valid ops for the `direction_output`
ops without setting a valid ops for `direction_input` by default.

Signed-off-by: Clément Le Goffic <clement.legoffic@foss.st.com>
---
 drivers/gpio/gpio-mmio.c    | 11 ++++++++++-
 include/linux/gpio/driver.h |  1 +
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-mmio.c b/drivers/gpio/gpio-mmio.c
index 4841e4ebe7a6..09b9e1275e7e 100644
--- a/drivers/gpio/gpio-mmio.c
+++ b/drivers/gpio/gpio-mmio.c
@@ -335,6 +335,11 @@ static int bgpio_dir_return(struct gpio_chip *gc, unsigned int gpio, bool dir_ou
 		return pinctrl_gpio_direction_input(gc, gpio);
 }
 
+static int bgpio_dir_in_err(struct gpio_chip *gc, unsigned int gpio)
+{
+	return -EINVAL;
+}
+
 static int bgpio_simple_dir_in(struct gpio_chip *gc, unsigned int gpio)
 {
 	return bgpio_dir_return(gc, gpio, false);
@@ -566,7 +571,11 @@ static int bgpio_setup_direction(struct gpio_chip *gc,
 			gc->direction_output = bgpio_dir_out_err;
 		else
 			gc->direction_output = bgpio_simple_dir_out;
-		gc->direction_input = bgpio_simple_dir_in;
+
+		if (flags & BGPIOF_NO_INPUT)
+			gc->direction_input = bgpio_dir_in_err;
+		else
+			gc->direction_input = bgpio_simple_dir_in;
 	}
 
 	return 0;
diff --git a/include/linux/gpio/driver.h b/include/linux/gpio/driver.h
index 4c0294a9104d..42890db9b10e 100644
--- a/include/linux/gpio/driver.h
+++ b/include/linux/gpio/driver.h
@@ -749,6 +749,7 @@ int bgpio_init(struct gpio_chip *gc, struct device *dev,
 #define BGPIOF_NO_OUTPUT		BIT(5) /* only input */
 #define BGPIOF_NO_SET_ON_INPUT		BIT(6)
 #define BGPIOF_PINCTRL_BACKEND		BIT(7) /* Call pinctrl direction setters */
+#define BGPIOF_NO_INPUT			BIT(8) /* only output */
 
 #ifdef CONFIG_GPIOLIB_IRQCHIP
 int gpiochip_irqchip_add_domain(struct gpio_chip *gc,

-- 
2.43.0

[PATCH v3 2/9] dt-bindings: pinctrl: stm32: Introduce HDP

[Clément Le Goffic]

'HDP' stands for Hardware Debug Port, it is an hardware block in
STMicrolectronics' MPUs that let the user decide which internal SoC's
signal to observe.
It provides 8 ports and for each port there is up to 16 different
signals that can be output.
Signals are different for each MPU.

Signed-off-by: Clément Le Goffic <clement.legoffic@foss.st.com>
---
 .../bindings/pinctrl/st,stm32-pinctrl-hdp.yaml     | 187 +++++++++++++++++++++
 1 file changed, 187 insertions(+)

diff --git a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl-hdp.yaml b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl-hdp.yaml
new file mode 100644
index 000000000000..416b41275714
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl-hdp.yaml
@@ -0,0 +1,187 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) STMicroelectronics 2025.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/st,stm32-pinctrl-hdp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STM32 Hardware Debug Port Mux/Config
+
+maintainers:
+  - Clément LE GOFFIC <clement.legoffic@foss.st.com>
+
+description:
+  STMicroelectronics's STM32 MPUs integrate a Hardware Debug Port (HDP).
+  It allows to output internal signals on SoC's GPIO.
+
+properties:
+  compatible:
+    enum:
+      - st,stm32mp131-hdp
+      - st,stm32mp151-hdp
+      - st,stm32mp251-hdp
+
+  reg:
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+
+patternProperties:
+  "^hdp[0-7]-pins$":
+    type: object
+    $ref: pinmux-node.yaml#
+    additionalProperties: false
+
+    properties:
+      pins:
+        pattern: '^HDP[0-7]$'
+
+      function: true
+
+    required:
+      - function
+      - pins
+
+allOf:
+  - $ref: pinctrl.yaml#
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: st,stm32mp131-hdp
+    then:
+      patternProperties:
+        "^hdp[0-7]-pins$":
+          properties:
+            function:
+              enum: [ pwr_pwrwake_sys, pwr_stop_forbidden, pwr_stdby_wakeup, pwr_encomp_vddcore,
+                      bsec_out_sec_niden, aiec_sys_wakeup, none, ddrctrl_lp_req,
+                      pwr_ddr_ret_enable_n, dts_clk_ptat, sram3ctrl_tamp_erase_act, gpoval0,
+                      pwr_sel_vth_vddcpu, pwr_mpu_ram_lowspeed, ca7_naxierrirq, pwr_okin_mr,
+                      bsec_out_sec_dbgen, aiec_c1_wakeup, rcc_pwrds_mpu, ddrctrl_dfi_ctrlupd_req,
+                      ddrctrl_cactive_ddrc_asr, sram3ctrl_hw_erase_act, nic400_s0_bready, gpoval1,
+                      pwr_pwrwake_mpu, pwr_mpu_clock_disable_ack, ca7_ndbgreset_i,
+                      bsec_in_rstcore_n, bsec_out_sec_bsc_dis, ddrctrl_dfi_init_complete,
+                      ddrctrl_perf_op_is_refresh, ddrctrl_gskp_dfi_lp_req, sram3ctrl_sw_erase_act,
+                      nic400_s0_bvalid, gpoval2, pwr_sel_vth_vddcore, pwr_mpu_clock_disable_req,
+                      ca7_npmuirq0, ca7_nfiqout0, bsec_out_sec_dftlock, bsec_out_sec_jtag_dis,
+                      rcc_pwrds_sys, sram3ctrl_tamp_erase_req, ddrctrl_stat_ddrc_reg_selfref_type0,
+                      dts_valobus1_0, dts_valobus2_0, tamp_potential_tamp_erfcfg, nic400_s0_wready,
+                      nic400_s0_rready, gpoval3, pwr_stop2_active, ca7_nl2reset_i,
+                      ca7_npreset_varm_i, bsec_out_sec_dften, bsec_out_sec_dbgswenable,
+                      eth1_out_pmt_intr_o, eth2_out_pmt_intr_o, ddrctrl_stat_ddrc_reg_selfref_type1,
+                      ddrctrl_cactive_0, dts_valobus1_1, dts_valobus2_1, tamp_nreset_sram_ercfg,
+                      nic400_s0_wlast, nic400_s0_rlast, gpoval4, ca7_standbywfil2,
+                      pwr_vth_vddcore_ack, ca7_ncorereset_i, ca7_nirqout0, bsec_in_pwrok,
+                      bsec_out_sec_deviceen, eth1_out_lpi_intr_o, eth2_out_lpi_intr_o,
+                      ddrctrl_cactive_ddrc, ddrctrl_wr_credit_cnt, dts_valobus1_2, dts_valobus2_2,
+                      pka_pka_itamp_out, nic400_s0_wvalid, nic400_s0_rvalid, gpoval5,
+                      ca7_standbywfe0, pwr_vth_vddcpu_ack, ca7_evento, bsec_in_tamper_det,
+                      bsec_out_sec_spniden, eth1_out_mac_speed_o1, eth2_out_mac_speed_o1,
+                      ddrctrl_csysack_ddrc, ddrctrl_lpr_credit_cnt, dts_valobus1_3, dts_valobus2_3,
+                      saes_tamper_out, nic400_s0_awready, nic400_s0_arready, gpoval6,
+                      ca7_standbywfi0, pwr_rcc_vcpu_rdy, ca7_eventi, ca7_dbgack0, bsec_out_fuse_ok,
+                      bsec_out_sec_spiden, eth1_out_mac_speed_o0, eth2_out_mac_speed_o0,
+                      ddrctrl_csysreq_ddrc, ddrctrl_hpr_credit_cnt, dts_valobus1_4, dts_valobus2_4,
+                      rng_tamper_out, nic400_s0_awavalid, nic400_s0_aravalid, gpoval7 ]
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: st,stm32mp151-hdp
+    then:
+      patternProperties:
+        "^hdp[0-7]-pins$":
+          properties:
+            function:
+              enum: [ pwr_pwrwake_sys, cm4_sleepdeep, pwr_stdby_wkup, pwr_encomp_vddcore,
+                      bsec_out_sec_niden, none, rcc_cm4_sleepdeep, gpu_dbg7, ddrctrl_lp_req,
+                      pwr_ddr_ret_enable_n, dts_clk_ptat, gpoval0, pwr_pwrwake_mcu, cm4_halted,
+                      ca7_naxierrirq, pwr_okin_mr, bsec_out_sec_dbgen, exti_sys_wakeup,
+                      rcc_pwrds_mpu, gpu_dbg6, ddrctrl_dfi_ctrlupd_req, ddrctrl_cactive_ddrc_asr,
+                      gpoval1, pwr_pwrwake_mpu, cm4_rxev, ca7_npmuirq1, ca7_nfiqout1,
+                      bsec_in_rstcore_n, exti_c2_wakeup, rcc_pwrds_mcu, gpu_dbg5,
+                      ddrctrl_dfi_init_complete, ddrctrl_perf_op_is_refresh,
+                      ddrctrl_gskp_dfi_lp_req, gpoval2, pwr_sel_vth_vddcore, cm4_txev, ca7_npmuirq0,
+                      ca7_nfiqout0, bsec_out_sec_dftlock, exti_c1_wakeup, rcc_pwrds_sys, gpu_dbg4,
+                      ddrctrl_stat_ddrc_reg_selfref_type0, ddrctrl_cactive_1, dts_valobus1_0,
+                      dts_valobus2_0, gpoval3, pwr_mpu_pdds_not_cstbydis, cm4_sleeping, ca7_nreset1,
+                      ca7_nirqout1, bsec_out_sec_dften, bsec_out_sec_dbgswenable,
+                      eth_out_pmt_intr_o, gpu_dbg3, ddrctrl_stat_ddrc_reg_selfref_type1,
+                      ddrctrl_cactive_0, dts_valobus1_1, dts_valobus2_1, gpoval4, ca7_standbywfil2,
+                      pwr_vth_vddcore_ack, ca7_nreset0, ca7_nirqout0, bsec_in_pwrok,
+                      bsec_out_sec_deviceen, eth_out_lpi_intr_o, gpu_dbg2, ddrctrl_cactive_ddrc,
+                      ddrctrl_wr_credit_cnt, dts_valobus1_2, dts_valobus2_2, gpoval5,
+                      ca7_standbywfi1, ca7_standbywfe1, ca7_evento, ca7_dbgack1,
+                      bsec_out_sec_spniden, eth_out_mac_speed_o1, gpu_dbg1, ddrctrl_csysack_ddrc,
+                      ddrctrl_lpr_credit_cnt, dts_valobus1_3, dts_valobus2_3, gpoval6,
+                      ca7_standbywfi0, ca7_standbywfe0, ca7_dbgack0, bsec_out_fuse_ok,
+                      bsec_out_sec_spiden, eth_out_mac_speed_o0, gpu_dbg0, ddrctrl_csysreq_ddrc,
+                      ddrctrl_hpr_credit_cnt, dts_valobus1_4, dts_valobus2_4, gpoval7 ]
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: st,stm32mp251-hdp
+    then:
+      patternProperties:
+        "^hdp[0-7]-pins$":
+          properties:
+            function:
+              enum: [ pwr_pwrwake_sys, cpu2_sleep_deep, bsec_out_tst_sdr_unlock_or_disable_scan,
+                      bsec_out_nidenm, bsec_out_nidena, cpu2_state_0, rcc_pwrds_sys, gpu_dbg7,
+                      ddrss_csysreq_ddrc, ddrss_dfi_phyupd_req, cpu3_sleep_deep,
+                      d2_gbl_per_clk_bus_req, pcie_usb_cxpl_debug_info_ei_0,
+                      pcie_usb_cxpl_debug_info_ei_8, d3_state_0, gpoval0, pwr_pwrwake_cpu2,
+                      cpu2_halted, cpu2_state_1, bsec_out_dbgenm, bsec_out_dbgena, exti1_sys_wakeup,
+                      rcc_pwrds_cpu2, gpu_dbg6, ddrss_csysack_ddrc, ddrss_dfi_phymstr_req,
+                      cpu3_halted, d2_gbl_per_dma_req, pcie_usb_cxpl_debug_info_ei_1,
+                      pcie_usb_cxpl_debug_info_ei_9, d3_state_1, gpoval1, pwr_pwrwake_cpu1,
+                      cpu2_rxev, cpu1_npumirq1, cpu1_nfiqout1, bsec_out_shdbgen, exti1_cpu2_wakeup,
+                      rcc_pwrds_cpu1, gpu_dbg5, ddrss_cactive_ddrc, ddrss_dfi_lp_req, cpu3_rxev,
+                      hpdma1_clk_bus_req, pcie_usb_cxpl_debug_info_ei_2,
+                      pcie_usb_cxpl_debug_info_ei_10, d3_state_2, gpoval2, pwr_sel_vth_vddcpu,
+                      cpu2_txev, cpu1_npumirq0, cpu1_nfiqout0, bsec_out_ddbgen, exti1_cpu1_wakeup,
+                      cpu3_state_0, gpu_dbg4, ddrss_mcdcg_en, ddrss_dfi_freq_0, cpu3_txev,
+                      hpdma2_clk_bus_req, pcie_usb_cxpl_debug_info_ei_3,
+                      pcie_usb_cxpl_debug_info_ei_11, d1_state_0, gpoval3, pwr_sel_vth_vddcore,
+                      cpu2_sleeping, cpu1_evento, cpu1_nirqout1, bsec_out_spnidena, exti2_d3_wakeup,
+                      eth1_out_pmt_intr_o, gpu_dbg3, ddrss_dphycg_en, ddrss_obsp0, cpu3_sleeping,
+                      hpdma3_clk_bus_req, pcie_usb_cxpl_debug_info_ei_4,
+                      pcie_usb_cxpl_debug_info_ei_12, d1_state_1, gpoval4, cpu1_standby_wfil2,
+                      none, cpu1_nirqout0, bsec_out_spidena, exti2_cpu3_wakeup, eth1_out_lpi_intr_o,
+                      gpu_dbg2, ddrctrl_dfi_init_start, ddrss_obsp1, cpu3_state_1,
+                      d3_gbl_per_clk_bus_req, pcie_usb_cxpl_debug_info_ei_5,
+                      pcie_usb_cxpl_debug_info_ei_13, d1_state_2, gpoval5, cpu1_standby_wfi1,
+                      cpu1_standby_wfe1, cpu1_halted1, cpu1_naxierrirq, bsec_out_spnidenm,
+                      exti2_cpu2_wakeup, eth2_out_pmt_intr_o, gpu_dbg1, ddrss_dfi_init_complete,
+                      ddrss_obsp2, d2_state_0, d3_gbl_per_dma_req, pcie_usb_cxpl_debug_info_ei_6,
+                      pcie_usb_cxpl_debug_info_ei_14, cpu1_state_0, gpoval6, cpu1_standby_wfi0,
+                      cpu1_standby_wfe0, cpu1_halted0, bsec_out_spidenm, exti2_cpu1__wakeup,
+                      eth2_out_lpi_intr_o, gpu_dbg0, ddrss_dfi_ctrlupd_req, ddrss_obsp3, d2_state_1,
+                      lpdma1_clk_bus_req, pcie_usb_cxpl_debug_info_ei_7,
+                      pcie_usb_cxpl_debug_info_ei_15, cpu1_state_1, gpoval7 ]
+
+required:
+  - compatible
+  - reg
+  - clocks
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/stm32mp1-clks.h>
+
+    pinctrl@54090000 {
+      compatible = "st,stm32mp151-hdp";
+      reg = <0x54090000 0x400>;
+      clocks = <&rcc HDP>;
+      pinctrl-names = "default";
+      pinctrl-0 = <&hdp2_gpo>;
+      hdp2_gpo: hdp2-pins {
+        function = "gpoval2";
+        pins = "HDP2";
+      };
+    };

-- 
2.43.0

[PATCH v3 3/9] pinctrl: stm32: Introduce HDP driver

[Clément Le Goffic]

This patch introduce the driver for the Hardware Debug Port available on
STM32MP platforms. The HDP allows the observation of internal SoC
signals by using multiplexers. Each HDP port can provide up to 16
internal signals (one of them can be software controlled as a GPO).

Signed-off-by: Clément Le Goffic <clement.legoffic@foss.st.com>
---
 drivers/pinctrl/stm32/Kconfig             |  14 +
 drivers/pinctrl/stm32/Makefile            |   1 +
 drivers/pinctrl/stm32/pinctrl-stm32-hdp.c | 720 ++++++++++++++++++++++++++++++
 3 files changed, 735 insertions(+)

diff --git a/drivers/pinctrl/stm32/Kconfig b/drivers/pinctrl/stm32/Kconfig
index 2656d3d3ae40..4b474cfd1f2c 100644
--- a/drivers/pinctrl/stm32/Kconfig
+++ b/drivers/pinctrl/stm32/Kconfig
@@ -57,4 +57,18 @@ config PINCTRL_STM32MP257
 	depends on OF && HAS_IOMEM
 	default MACH_STM32MP25
 	select PINCTRL_STM32
+
+config PINCTRL_STM32_HDP
+	tristate "STMicroelectronics STM32 Hardware Debug Port (HDP) pin control"
+	depends on OF && HAS_IOMEM
+	default ARM64 || (ARM && CPU_V7)
+	select PINMUX
+	select GENERIC_PINCONF
+	select GPIOLIB
+	help
+	  The Hardware Debug Port allows the observation of internal signals.
+	  It uses configurable multiplexer to route signals in a dedicated observation register.
+	  This driver also permits the observation of signals on external SoC pins.
+	  It permits the observation of up to 16 signals per HDP line.
+
 endif
diff --git a/drivers/pinctrl/stm32/Makefile b/drivers/pinctrl/stm32/Makefile
index 7b17464d8de1..98a1bbc7e16c 100644
--- a/drivers/pinctrl/stm32/Makefile
+++ b/drivers/pinctrl/stm32/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_PINCTRL_STM32H743)	+= pinctrl-stm32h743.o
 obj-$(CONFIG_PINCTRL_STM32MP135) += pinctrl-stm32mp135.o
 obj-$(CONFIG_PINCTRL_STM32MP157) += pinctrl-stm32mp157.o
 obj-$(CONFIG_PINCTRL_STM32MP257) += pinctrl-stm32mp257.o
+obj-$(CONFIG_PINCTRL_STM32_HDP) += pinctrl-stm32-hdp.o
diff --git a/drivers/pinctrl/stm32/pinctrl-stm32-hdp.c b/drivers/pinctrl/stm32/pinctrl-stm32-hdp.c
new file mode 100644
index 000000000000..e91442eb566b
--- /dev/null
+++ b/drivers/pinctrl/stm32/pinctrl-stm32-hdp.c
@@ -0,0 +1,720 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) STMicroelectronics 2025 - All Rights Reserved
+ * Author: Clément Le Goffic <clement.legoffic@foss.st.com> for STMicroelectronics.
+ */
+#include <linux/bits.h>
+#include <linux/clk.h>
+#include <linux/gpio/driver.h>
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/pinctrl/consumer.h>
+#include <linux/pinctrl/pinconf-generic.h>
+#include <linux/pinctrl/pinctrl.h>
+#include <linux/pinctrl/pinmux.h>
+#include <linux/platform_device.h>
+#include <linux/pm.h>
+
+#include "../core.h"
+
+#define DRIVER_NAME		"stm32_hdp"
+#define HDP_CTRL_ENABLE		1
+#define HDP_CTRL_DISABLE	0
+
+#define HDP_CTRL		0x000
+#define HDP_MUX			0x004
+#define HDP_VAL			0x010
+#define HDP_GPOSET		0x014
+#define HDP_GPOCLR		0x018
+#define HDP_GPOVAL		0x01c
+#define HDP_VERR		0x3f4
+#define HDP_IPIDR		0x3f8
+#define HDP_SIDR		0x3fc
+
+#define HDP_MUX_SHIFT(n)	((n) * 4)
+#define HDP_MUX_MASK(n)		(GENMASK(3, 0) << HDP_MUX_SHIFT(n))
+#define HDP_MUX_GPOVAL(n)	(0xf << HDP_MUX_SHIFT(n))
+
+#define HDP_PIN			8
+#define HDP_FUNC		16
+#define HDP_FUNC_TOTAL		(HDP_PIN * HDP_FUNC)
+
+struct stm32_hdp {
+	struct device *dev;
+	void __iomem *base;
+	struct clk *clk;
+	struct pinctrl_dev *pctl_dev;
+	struct gpio_chip gpio_chip;
+	u32 mux_conf;
+	u32 gposet_conf;
+	const char * const *func_name;
+};
+
+static const struct pinctrl_pin_desc stm32_hdp_pins[] = {
+	PINCTRL_PIN(0, "HDP0"),
+	PINCTRL_PIN(1, "HDP1"),
+	PINCTRL_PIN(2, "HDP2"),
+	PINCTRL_PIN(3, "HDP3"),
+	PINCTRL_PIN(4, "HDP4"),
+	PINCTRL_PIN(5, "HDP5"),
+	PINCTRL_PIN(6, "HDP6"),
+	PINCTRL_PIN(7, "HDP7"),
+};
+
+static const char * const func_name_mp13[] = {
+	//HDP0 functions:
+	"pwr_pwrwake_sys",
+	"pwr_stop_forbidden",
+	"pwr_stdby_wakeup",
+	"pwr_encomp_vddcore",
+	"bsec_out_sec_niden",
+	"aiec_sys_wakeup",
+	"none",
+	"none",
+	"ddrctrl_lp_req",
+	"pwr_ddr_ret_enable_n",
+	"dts_clk_ptat",
+	"none",
+	"sram3ctrl_tamp_erase_act",
+	"none",
+	"none",
+	"gpoval0",
+	//HDP1 functions:
+	"pwr_sel_vth_vddcpu",
+	"pwr_mpu_ram_lowspeed",
+	"ca7_naxierrirq",
+	"pwr_okin_mr",
+	"bsec_out_sec_dbgen",
+	"aiec_c1_wakeup",
+	"rcc_pwrds_mpu",
+	"none",
+	"ddrctrl_dfi_ctrlupd_req",
+	"ddrctrl_cactive_ddrc_asr",
+	"none",
+	"none",
+	"sram3ctrl_hw_erase_act",
+	"nic400_s0_bready",
+	"none",
+	"gpoval1",
+	//HDP2 functions:
+	"pwr_pwrwake_mpu",
+	"pwr_mpu_clock_disable_ack",
+	"ca7_ndbgreset_i",
+	"none",
+	"bsec_in_rstcore_n",
+	"bsec_out_sec_bsc_dis",
+	"none",
+	"none",
+	"ddrctrl_dfi_init_complete",
+	"ddrctrl_perf_op_is_refresh",
+	"ddrctrl_gskp_dfi_lp_req",
+	"none",
+	"sram3ctrl_sw_erase_act",
+	"nic400_s0_bvalid",
+	"none",
+	"gpoval2",
+	//HDP3 functions:
+	"pwr_sel_vth_vddcore",
+	"pwr_mpu_clock_disable_req",
+	"ca7_npmuirq0",
+	"ca7_nfiqout0",
+	"bsec_out_sec_dftlock",
+	"bsec_out_sec_jtag_dis",
+	"rcc_pwrds_sys",
+	"sram3ctrl_tamp_erase_req",
+	"ddrctrl_stat_ddrc_reg_selfref_type0",
+	"none",
+	"dts_valobus1_0",
+	"dts_valobus2_0",
+	"tamp_potential_tamp_erfcfg",
+	"nic400_s0_wready",
+	"nic400_s0_rready",
+	"gpoval3",
+	//HDP4 functions:
+	"none",
+	"pwr_stop2_active",
+	"ca7_nl2reset_i",
+	"ca7_npreset_varm_i",
+	"bsec_out_sec_dften",
+	"bsec_out_sec_dbgswenable",
+	"eth1_out_pmt_intr_o",
+	"eth2_out_pmt_intr_o",
+	"ddrctrl_stat_ddrc_reg_selfref_type1",
+	"ddrctrl_cactive_0",
+	"dts_valobus1_1",
+	"dts_valobus2_1",
+	"tamp_nreset_sram_ercfg",
+	"nic400_s0_wlast",
+	"nic400_s0_rlast",
+	"gpoval4",
+	//HDP5 functions:
+	"ca7_standbywfil2",
+	"pwr_vth_vddcore_ack",
+	"ca7_ncorereset_i",
+	"ca7_nirqout0",
+	"bsec_in_pwrok",
+	"bsec_out_sec_deviceen",
+	"eth1_out_lpi_intr_o",
+	"eth2_out_lpi_intr_o",
+	"ddrctrl_cactive_ddrc",
+	"ddrctrl_wr_credit_cnt",
+	"dts_valobus1_2",
+	"dts_valobus2_2",
+	"pka_pka_itamp_out",
+	"nic400_s0_wvalid",
+	"nic400_s0_rvalid",
+	"gpoval5",
+	//HDP6 functions:
+	"ca7_standbywfe0",
+	"pwr_vth_vddcpu_ack",
+	"ca7_evento",
+	"none",
+	"bsec_in_tamper_det",
+	"bsec_out_sec_spniden",
+	"eth1_out_mac_speed_o1",
+	"eth2_out_mac_speed_o1",
+	"ddrctrl_csysack_ddrc",
+	"ddrctrl_lpr_credit_cnt",
+	"dts_valobus1_3",
+	"dts_valobus2_3",
+	"saes_tamper_out",
+	"nic400_s0_awready",
+	"nic400_s0_arready",
+	"gpoval6",
+	//HDP7 functions:
+	"ca7_standbywfi0",
+	"pwr_rcc_vcpu_rdy",
+	"ca7_eventi",
+	"ca7_dbgack0",
+	"bsec_out_fuse_ok",
+	"bsec_out_sec_spiden",
+	"eth1_out_mac_speed_o0",
+	"eth2_out_mac_speed_o0",
+	"ddrctrl_csysreq_ddrc",
+	"ddrctrl_hpr_credit_cnt",
+	"dts_valobus1_4",
+	"dts_valobus2_4",
+	"rng_tamper_out",
+	"nic400_s0_awavalid",
+	"nic400_s0_aravalid",
+	"gpoval7",
+};
+
+static const char * const func_name_mp15[] = {
+	//HDP0 functions:
+	"pwr_pwrwake_sys",
+	"cm4_sleepdeep",
+	"pwr_stdby_wkup",
+	"pwr_encomp_vddcore",
+	"bsec_out_sec_niden",
+	"none",
+	"rcc_cm4_sleepdeep",
+	"gpu_dbg7",
+	"ddrctrl_lp_req",
+	"pwr_ddr_ret_enable_n",
+	"dts_clk_ptat",
+	"none",
+	"none",
+	"none",
+	"none",
+	"gpoval0",
+	//HDP1 functions:
+	"pwr_pwrwake_mcu",
+	"cm4_halted",
+	"ca7_naxierrirq",
+	"pwr_okin_mr",
+	"bsec_out_sec_dbgen",
+	"exti_sys_wakeup",
+	"rcc_pwrds_mpu",
+	"gpu_dbg6",
+	"ddrctrl_dfi_ctrlupd_req",
+	"ddrctrl_cactive_ddrc_asr",
+	"none",
+	"none",
+	"none",
+	"none",
+	"none",
+	"gpoval1",
+	//HDP2 functions:
+	"pwr_pwrwake_mpu",
+	"cm4_rxev",
+	"ca7_npmuirq1",
+	"ca7_nfiqout1",
+	"bsec_in_rstcore_n",
+	"exti_c2_wakeup",
+	"rcc_pwrds_mcu",
+	"gpu_dbg5",
+	"ddrctrl_dfi_init_complete",
+	"ddrctrl_perf_op_is_refresh",
+	"ddrctrl_gskp_dfi_lp_req",
+	"none",
+	"none",
+	"none",
+	"none",
+	"gpoval2",
+	//HDP3 functions:
+	"pwr_sel_vth_vddcore",
+	"cm4_txev",
+	"ca7_npmuirq0",
+	"ca7_nfiqout0",
+	"bsec_out_sec_dftlock",
+	"exti_c1_wakeup",
+	"rcc_pwrds_sys",
+	"gpu_dbg4",
+	"ddrctrl_stat_ddrc_reg_selfref_type0",
+	"ddrctrl_cactive_1",
+	"dts_valobus1_0",
+	"dts_valobus2_0",
+	"none",
+	"none",
+	"none",
+	"gpoval3",
+	//HDP4 functions:
+	"pwr_mpu_pdds_not_cstbydis",
+	"cm4_sleeping",
+	"ca7_nreset1",
+	"ca7_nirqout1",
+	"bsec_out_sec_dften",
+	"bsec_out_sec_dbgswenable",
+	"eth_out_pmt_intr_o",
+	"gpu_dbg3",
+	"ddrctrl_stat_ddrc_reg_selfref_type1",
+	"ddrctrl_cactive_0",
+	"dts_valobus1_1",
+	"dts_valobus2_1",
+	"none",
+	"none",
+	"none",
+	"gpoval4",
+	//HDP5 functions:
+	"ca7_standbywfil2",
+	"pwr_vth_vddcore_ack",
+	"ca7_nreset0",
+	"ca7_nirqout0",
+	"bsec_in_pwrok",
+	"bsec_out_sec_deviceen",
+	"eth_out_lpi_intr_o",
+	"gpu_dbg2",
+	"ddrctrl_cactive_ddrc",
+	"ddrctrl_wr_credit_cnt",
+	"dts_valobus1_2",
+	"dts_valobus2_2",
+	"none",
+	"none",
+	"none",
+	"gpoval5",
+	//HDP6 functions:
+	"ca7_standbywfi1",
+	"ca7_standbywfe1",
+	"ca7_evento",
+	"ca7_dbgack1",
+	"none",
+	"bsec_out_sec_spniden",
+	"eth_out_mac_speed_o1",
+	"gpu_dbg1",
+	"ddrctrl_csysack_ddrc",
+	"ddrctrl_lpr_credit_cnt",
+	"dts_valobus1_3",
+	"dts_valobus2_3",
+	"none",
+	"none",
+	"none",
+	"gpoval6",
+	//HDP7 functions:
+	"ca7_standbywfi0",
+	"ca7_standbywfe0",
+	"none",
+	"ca7_dbgack0",
+	"bsec_out_fuse_ok",
+	"bsec_out_sec_spiden",
+	"eth_out_mac_speed_o0",
+	"gpu_dbg0",
+	"ddrctrl_csysreq_ddrc",
+	"ddrctrl_hpr_credit_cnt",
+	"dts_valobus1_4",
+	"dts_valobus2_4",
+	"none",
+	"none",
+	"none",
+	"gpoval7"
+};
+
+static const char * const func_name_mp25[] = {
+	//HDP0 functions:
+	"pwr_pwrwake_sys",
+	"cpu2_sleep_deep",
+	"bsec_out_tst_sdr_unlock_or_disable_scan",
+	"bsec_out_nidenm",
+	"bsec_out_nidena",
+	"cpu2_state_0",
+	"rcc_pwrds_sys",
+	"gpu_dbg7",
+	"ddrss_csysreq_ddrc",
+	"ddrss_dfi_phyupd_req",
+	"cpu3_sleep_deep",
+	"d2_gbl_per_clk_bus_req",
+	"pcie_usb_cxpl_debug_info_ei_0",
+	"pcie_usb_cxpl_debug_info_ei_8",
+	"d3_state_0",
+	"gpoval0",
+	//HDP1 functions:
+	"pwr_pwrwake_cpu2",
+	"cpu2_halted",
+	"cpu2_state_1",
+	"bsec_out_dbgenm",
+	"bsec_out_dbgena",
+	"exti1_sys_wakeup",
+	"rcc_pwrds_cpu2",
+	"gpu_dbg6",
+	"ddrss_csysack_ddrc",
+	"ddrss_dfi_phymstr_req",
+	"cpu3_halted",
+	"d2_gbl_per_dma_req",
+	"pcie_usb_cxpl_debug_info_ei_1",
+	"pcie_usb_cxpl_debug_info_ei_9",
+	"d3_state_1",
+	"gpoval1",
+	//HDP2 functions:
+	"pwr_pwrwake_cpu1",
+	"cpu2_rxev",
+	"cpu1_npumirq1",
+	"cpu1_nfiqout1",
+	"bsec_out_shdbgen",
+	"exti1_cpu2_wakeup",
+	"rcc_pwrds_cpu1",
+	"gpu_dbg5",
+	"ddrss_cactive_ddrc",
+	"ddrss_dfi_lp_req",
+	"cpu3_rxev",
+	"hpdma1_clk_bus_req",
+	"pcie_usb_cxpl_debug_info_ei_2",
+	"pcie_usb_cxpl_debug_info_ei_10",
+	"d3_state_2",
+	"gpoval2",
+	//HDP3 functions:
+	"pwr_sel_vth_vddcpu",
+	"cpu2_txev",
+	"cpu1_npumirq0",
+	"cpu1_nfiqout0",
+	"bsec_out_ddbgen",
+	"exti1_cpu1_wakeup",
+	"cpu3_state_0",
+	"gpu_dbg4",
+	"ddrss_mcdcg_en",
+	"ddrss_dfi_freq_0",
+	"cpu3_txev",
+	"hpdma2_clk_bus_req",
+	"pcie_usb_cxpl_debug_info_ei_3",
+	"pcie_usb_cxpl_debug_info_ei_11",
+	"d1_state_0",
+	"gpoval3",
+	//HDP4 functions:
+	"pwr_sel_vth_vddcore",
+	"cpu2_sleeping",
+	"cpu1_evento",
+	"cpu1_nirqout1",
+	"bsec_out_spnidena",
+	"exti2_d3_wakeup",
+	"eth1_out_pmt_intr_o",
+	"gpu_dbg3",
+	"ddrss_dphycg_en",
+	"ddrss_obsp0",
+	"cpu3_sleeping",
+	"hpdma3_clk_bus_req",
+	"pcie_usb_cxpl_debug_info_ei_4",
+	"pcie_usb_cxpl_debug_info_ei_12",
+	"d1_state_1",
+	"gpoval4",
+	//HDP5 functions:
+	"cpu1_standby_wfil2",
+	"none",
+	"none",
+	"cpu1_nirqout0",
+	"bsec_out_spidena",
+	"exti2_cpu3_wakeup",
+	"eth1_out_lpi_intr_o",
+	"gpu_dbg2",
+	"ddrctrl_dfi_init_start",
+	"ddrss_obsp1",
+	"cpu3_state_1",
+	"d3_gbl_per_clk_bus_req",
+	"pcie_usb_cxpl_debug_info_ei_5",
+	"pcie_usb_cxpl_debug_info_ei_13",
+	"d1_state_2",
+	"gpoval5",
+	//HDP6 functions:
+	"cpu1_standby_wfi1",
+	"cpu1_standby_wfe1",
+	"cpu1_halted1",
+	"cpu1_naxierrirq",
+	"bsec_out_spnidenm",
+	"exti2_cpu2_wakeup",
+	"eth2_out_pmt_intr_o",
+	"gpu_dbg1",
+	"ddrss_dfi_init_complete",
+	"ddrss_obsp2",
+	"d2_state_0",
+	"d3_gbl_per_dma_req",
+	"pcie_usb_cxpl_debug_info_ei_6",
+	"pcie_usb_cxpl_debug_info_ei_14",
+	"cpu1_state_0",
+	"gpoval6",
+	//HDP7 functions:
+	"cpu1_standby_wfi0",
+	"cpu1_standby_wfe0",
+	"cpu1_halted0",
+	"none",
+	"bsec_out_spidenm",
+	"exti2_cpu1__wakeup",
+	"eth2_out_lpi_intr_o",
+	"gpu_dbg0",
+	"ddrss_dfi_ctrlupd_req",
+	"ddrss_obsp3",
+	"d2_state_1",
+	"lpdma1_clk_bus_req",
+	"pcie_usb_cxpl_debug_info_ei_7",
+	"pcie_usb_cxpl_debug_info_ei_15",
+	"cpu1_state_1",
+	"gpoval7",
+};
+
+static const char * const stm32_hdp_pins_group[] = {
+	"HDP0",
+	"HDP1",
+	"HDP2",
+	"HDP3",
+	"HDP4",
+	"HDP5",
+	"HDP6",
+	"HDP7"
+};
+
+static int stm32_hdp_gpio_get_direction(struct gpio_chip *gc, unsigned int offset)
+{
+	return GPIO_LINE_DIRECTION_OUT;
+}
+
+static int stm32_hdp_pinctrl_get_groups_count(struct pinctrl_dev *pctldev)
+{
+	return ARRAY_SIZE(stm32_hdp_pins);
+}
+
+static const char *stm32_hdp_pinctrl_get_group_name(struct pinctrl_dev *pctldev,
+						    unsigned int selector)
+{
+	return stm32_hdp_pins[selector].name;
+}
+
+static int stm32_hdp_pinctrl_get_group_pins(struct pinctrl_dev *pctldev, unsigned int selector,
+					    const unsigned int **pins, unsigned int *num_pins)
+{
+	*pins = &stm32_hdp_pins[selector].number;
+	*num_pins = 1;
+
+	return 0;
+}
+
+static const struct pinctrl_ops stm32_hdp_pinctrl_ops = {
+	.get_groups_count = stm32_hdp_pinctrl_get_groups_count,
+	.get_group_name	  = stm32_hdp_pinctrl_get_group_name,
+	.get_group_pins	  = stm32_hdp_pinctrl_get_group_pins,
+	.dt_node_to_map	  = pinconf_generic_dt_node_to_map_all,
+	.dt_free_map	  = pinconf_generic_dt_free_map,
+};
+
+static int stm32_hdp_pinmux_get_functions_count(struct pinctrl_dev *pctldev)
+{
+	return HDP_FUNC_TOTAL;
+}
+
+static const char *stm32_hdp_pinmux_get_function_name(struct pinctrl_dev *pctldev,
+							  unsigned int selector)
+{
+	struct stm32_hdp *hdp = pinctrl_dev_get_drvdata(pctldev);
+
+	return hdp->func_name[selector];
+}
+
+static int stm32_hdp_pinmux_get_function_groups(struct pinctrl_dev *pctldev, unsigned int selector,
+						const char *const **groups,
+						unsigned int *num_groups)
+{
+	u32 index = selector / HDP_FUNC;
+
+	*groups = &stm32_hdp_pins[index].name;
+	*num_groups = 1;
+
+	return 0;
+}
+
+static int stm32_hdp_pinmux_set_mux(struct pinctrl_dev *pctldev, unsigned int func_selector,
+				    unsigned int group_selector)
+{
+	struct stm32_hdp *hdp = pinctrl_dev_get_drvdata(pctldev);
+
+	unsigned int pin = stm32_hdp_pins[group_selector].number;
+	u32 mux;
+
+	func_selector %= HDP_FUNC;
+	mux = readl_relaxed(hdp->base + HDP_MUX);
+	mux &= ~HDP_MUX_MASK(pin);
+	mux |= func_selector << HDP_MUX_SHIFT(pin);
+
+	writel_relaxed(mux, hdp->base + HDP_MUX);
+	hdp->mux_conf = mux;
+
+	return 0;
+}
+
+static const struct pinmux_ops stm32_hdp_pinmux_ops = {
+	.get_functions_count = stm32_hdp_pinmux_get_functions_count,
+	.get_function_name   = stm32_hdp_pinmux_get_function_name,
+	.get_function_groups = stm32_hdp_pinmux_get_function_groups,
+	.set_mux	     = stm32_hdp_pinmux_set_mux,
+	.gpio_set_direction  = NULL,
+};
+
+static struct pinctrl_desc stm32_hdp_pdesc = {
+	.name	 = DRIVER_NAME,
+	.pins	 = stm32_hdp_pins,
+	.npins	 = ARRAY_SIZE(stm32_hdp_pins),
+	.pctlops = &stm32_hdp_pinctrl_ops,
+	.pmxops	 = &stm32_hdp_pinmux_ops,
+	.owner	 = THIS_MODULE,
+};
+
+static const struct of_device_id stm32_hdp_of_match[] = {
+	{
+		.compatible = "st,stm32mp131-hdp",
+		.data = &func_name_mp13,
+	},
+	{
+		.compatible = "st,stm32mp151-hdp",
+		.data = &func_name_mp15,
+	},
+	{
+		.compatible = "st,stm32mp251-hdp",
+		.data = &func_name_mp25,
+	},
+	{}
+};
+MODULE_DEVICE_TABLE(of, stm32_hdp_of_match);
+
+static int stm32_hdp_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct stm32_hdp *hdp;
+	u8 version;
+	int err;
+
+	hdp = devm_kzalloc(dev, sizeof(*hdp), GFP_KERNEL);
+	if (!hdp)
+		return -ENOMEM;
+	hdp->dev = dev;
+
+	platform_set_drvdata(pdev, hdp);
+
+	hdp->base = devm_platform_ioremap_resource(pdev, 0);
+	if (IS_ERR(hdp->base))
+		return PTR_ERR(hdp->base);
+
+	hdp->func_name = of_device_get_match_data(dev);
+	if (!hdp->func_name)
+		return dev_err_probe(dev, -ENODEV, "No function name provided\n");
+
+	hdp->clk = devm_clk_get_enabled(dev, NULL);
+	if (IS_ERR(hdp->clk))
+		return dev_err_probe(dev, PTR_ERR(hdp->clk), "No HDP clock provided\n");
+
+	err = devm_pinctrl_register_and_init(dev, &stm32_hdp_pdesc, hdp, &hdp->pctl_dev);
+	if (err)
+		return dev_err_probe(dev, err, "Failed to register pinctrl\n");
+
+	err = pinctrl_enable(hdp->pctl_dev);
+	if (err)
+		return dev_err_probe(dev, err, "Failed to enable pinctrl\n");
+
+	hdp->gpio_chip.get_direction = stm32_hdp_gpio_get_direction;
+	hdp->gpio_chip.ngpio	     = ARRAY_SIZE(stm32_hdp_pins);
+	hdp->gpio_chip.can_sleep     = true;
+	hdp->gpio_chip.names	     = stm32_hdp_pins_group;
+
+	err = bgpio_init(&hdp->gpio_chip, dev, 4,
+			 hdp->base + HDP_GPOVAL,
+			 hdp->base + HDP_GPOSET,
+			 hdp->base + HDP_GPOCLR,
+			 NULL, NULL, BGPIOF_NO_INPUT);
+	if (err)
+		return dev_err_probe(dev, err, "Failed to init bgpio\n");
+
+
+	err = devm_gpiochip_add_data(dev, &hdp->gpio_chip, hdp);
+	if (err)
+		return dev_err_probe(dev, err, "Failed to add gpiochip\n");
+
+	writel_relaxed(HDP_CTRL_ENABLE, hdp->base + HDP_CTRL);
+
+	version = readl_relaxed(hdp->base + HDP_VERR);
+	dev_dbg(dev, "STM32 HDP version %u.%u initialized\n", version >> 4, version & 0x0f);
+
+	return 0;
+}
+
+static void stm32_hdp_remove(struct platform_device *pdev)
+{
+	struct stm32_hdp *hdp = platform_get_drvdata(pdev);
+
+	writel_relaxed(HDP_CTRL_DISABLE, hdp->base + HDP_CTRL);
+}
+
+static int stm32_hdp_suspend(struct device *dev)
+{
+	struct stm32_hdp *hdp = dev_get_drvdata(dev);
+
+	hdp->gposet_conf = readl_relaxed(hdp->base + HDP_GPOSET);
+
+	pinctrl_pm_select_sleep_state(dev);
+
+	clk_disable_unprepare(hdp->clk);
+
+	return 0;
+}
+
+static int stm32_hdp_resume(struct device *dev)
+{
+	struct stm32_hdp *hdp = dev_get_drvdata(dev);
+	int err;
+
+	err = clk_prepare_enable(hdp->clk);
+	if (err) {
+		dev_err(dev, "Failed to prepare_enable clk (%d)\n", err);
+		return err;
+	}
+
+	writel_relaxed(HDP_CTRL_ENABLE, hdp->base + HDP_CTRL);
+	writel_relaxed(hdp->gposet_conf, hdp->base + HDP_GPOSET);
+	writel_relaxed(hdp->mux_conf, hdp->base + HDP_MUX);
+
+	pinctrl_pm_select_default_state(dev);
+
+	return 0;
+}
+
+static DEFINE_SIMPLE_DEV_PM_OPS(stm32_hdp_pm_ops, stm32_hdp_suspend, stm32_hdp_resume);
+
+static struct platform_driver stm32_hdp_driver = {
+	.probe = stm32_hdp_probe,
+	.remove = stm32_hdp_remove,
+	.driver = {
+		.name = DRIVER_NAME,
+		.pm = pm_sleep_ptr(&stm32_hdp_pm_ops),
+		.of_match_table = stm32_hdp_of_match,
+	}
+};
+
+module_platform_driver(stm32_hdp_driver);
+
+MODULE_AUTHOR("Clément Le Goffic");
+MODULE_DESCRIPTION("STMicroelectronics STM32 Hardware Debug Port driver");
+MODULE_LICENSE("GPL");

-- 
2.43.0

[PATCH v3 4/9] MAINTAINERS: Add Clément Le Goffic as STM32 HDP maintainer

[Clément Le Goffic]

Add Clément Le Goffic as STM32 HDP maintainer.

Signed-off-by: Clément Le Goffic <clement.legoffic@foss.st.com>
---
 MAINTAINERS | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index f21f1dabb5fe..c0c30fe00a2a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -23023,6 +23023,12 @@ F:	drivers/bus/stm32_etzpc.c
 F:	drivers/bus/stm32_firewall.c
 F:	drivers/bus/stm32_rifsc.c
 
+ST STM32 HDP PINCTRL DRIVER
+M:	Clément Le Goffic <clement.legoffic@foss.st.com>
+S:	Maintained
+F:	Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl-hdp.yaml
+F:	drivers/pinctrl/stm32/pinctrl-stm32-hdp.c
+
 ST STM32 I2C/SMBUS DRIVER
 M:	Pierre-Yves MORDRET <pierre-yves.mordret@foss.st.com>
 M:	Alain Volmat <alain.volmat@foss.st.com>

-- 
2.43.0

[PATCH v3 5/9] ARM: dts: stm32: add Hardware debug port (HDP) on stm32mp13

[Clément Le Goffic]

Add the hdp devicetree node for stm32mp13 SoC family

Signed-off-by: Clément Le Goffic <clement.legoffic@foss.st.com>
---
 arch/arm/boot/dts/st/stm32mp131.dtsi | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/st/stm32mp131.dtsi b/arch/arm/boot/dts/st/stm32mp131.dtsi
index 8512a6e46b33..b0537bcdb9d5 100644
--- a/arch/arm/boot/dts/st/stm32mp131.dtsi
+++ b/arch/arm/boot/dts/st/stm32mp131.dtsi
@@ -951,6 +951,12 @@ dts: thermal@50028000 {
 			clocks = <&rcc DTS>;
 			clock-names = "pclk";
 			#thermal-sensor-cells = <0>;
+		};
+
+		hdp: pinctrl@5002a000 {
+			compatible = "st,stm32mp131-hdp";
+			reg = <0x5002a000 0x400>;
+			clocks = <&rcc HDP>;
 			status = "disabled";
 		};
 

-- 
2.43.0

[PATCH v3 6/9] ARM: dts: stm32: add Hardware debug port (HDP) on stm32mp15

[Clément Le Goffic]

Add the hdp devicetree node for stm32mp15 SoC family

Signed-off-by: Clément Le Goffic <clement.legoffic@foss.st.com>
---
 arch/arm/boot/dts/st/stm32mp151.dtsi | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/st/stm32mp151.dtsi b/arch/arm/boot/dts/st/stm32mp151.dtsi
index 0daa8ffe2ff5..b1b568dfd126 100644
--- a/arch/arm/boot/dts/st/stm32mp151.dtsi
+++ b/arch/arm/boot/dts/st/stm32mp151.dtsi
@@ -270,6 +270,13 @@ dts: thermal@50028000 {
 			status = "disabled";
 		};
 
+		hdp: pinctrl@5002a000 {
+			compatible = "st,stm32mp151-hdp";
+			reg = <0x5002a000 0x400>;
+			clocks = <&rcc HDP>;
+			status = "disabled";
+		};
+
 		mdma1: dma-controller@58000000 {
 			compatible = "st,stm32h7-mdma";
 			reg = <0x58000000 0x1000>;

-- 
2.43.0

[PATCH v3 7/9] ARM: dts: stm32: add Hardware debug port (HDP) on stm32mp25

[Clément Le Goffic]

Add the hdp devicetree node for stm32mp25 SoC family

Signed-off-by: Clément Le Goffic <clement.legoffic@foss.st.com>
---
 arch/arm64/boot/dts/st/stm32mp251.dtsi | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/st/stm32mp251.dtsi b/arch/arm64/boot/dts/st/stm32mp251.dtsi
index 87110f91e489..0fd79acd458f 100644
--- a/arch/arm64/boot/dts/st/stm32mp251.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp251.dtsi
@@ -917,6 +917,13 @@ package_otp@1e8 {
 			};
 		};
 
+		hdp: pinctrl@44090000 {
+			compatible = "st,stm32mp251-hdp";
+			reg = <0x44090000 0x400>;
+			clocks = <&rcc CK_BUS_HDP>;
+			status = "disabled";
+		};
+
 		rcc: clock-controller@44200000 {
 			compatible = "st,stm32mp25-rcc";
 			reg = <0x44200000 0x10000>;

-- 
2.43.0

[PATCH v3 8/9] ARM: dts: stm32: add alternate pinmux for HDP pin and add HDP pinctrl node

[Clément Le Goffic]

Introduce hdp node to output a user defined value on port hdp2.
Add pinctrl nodes to be able to output this signal on one SoC pin.

Signed-off-by: Clément Le Goffic <clement.legoffic@foss.st.com>
---
 arch/arm/boot/dts/st/stm32mp15-pinctrl.dtsi | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/arch/arm/boot/dts/st/stm32mp15-pinctrl.dtsi b/arch/arm/boot/dts/st/stm32mp15-pinctrl.dtsi
index 40605ea85ee1..4a31e9f7a897 100644
--- a/arch/arm/boot/dts/st/stm32mp15-pinctrl.dtsi
+++ b/arch/arm/boot/dts/st/stm32mp15-pinctrl.dtsi
@@ -5,6 +5,14 @@
  */
 #include <dt-bindings/pinctrl/stm32-pinfunc.h>
 
+&hdp {
+	/omit-if-no-ref/
+	hdp2_gpo: hdp2-pins {
+		function = "gpoval2";
+		pins = "HDP2";
+	};
+};
+
 &pinctrl {
 	/omit-if-no-ref/
 	adc1_ain_pins_a: adc1-ain-0 {
@@ -731,6 +739,23 @@ pins {
 		};
 	};
 
+	/omit-if-no-ref/
+	hdp2_pins_a: hdp2-0 {
+		pins {
+			pinmux = <STM32_PINMUX('E', 13, AF0)>; /* HDP2 */
+			bias-disable;
+			drive-push-pull;
+			slew-rate = <2>;
+		};
+	};
+
+	/omit-if-no-ref/
+	hdp2_sleep_pins_a: hdp2-sleep-0 {
+		pins {
+			pinmux = <STM32_PINMUX('E', 13, ANALOG)>; /* HDP2 */
+		};
+	};
+
 	/omit-if-no-ref/
 	i2c1_pins_a: i2c1-0 {
 		pins {

-- 
2.43.0

[PATCH v3 9/9] ARM: dts: stm32: add Hardware debug port (HDP) on stm32mp157c-dk2 board

[Clément Le Goffic]

On the stm32mp157fc-dk2 board, we can observe the hdp GPOVAL function on
SoC pin E13 accessible on the pin 5 on the Arduino connector CN13.
Add the relevant configuration but keep it disabled as it's used for
debug only.

Signed-off-by: Clément Le Goffic <clement.legoffic@foss.st.com>
---
 arch/arm/boot/dts/st/stm32mp157c-dk2.dts | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/st/stm32mp157c-dk2.dts b/arch/arm/boot/dts/st/stm32mp157c-dk2.dts
index 324f7bb988d1..8a8fdf338d1d 100644
--- a/arch/arm/boot/dts/st/stm32mp157c-dk2.dts
+++ b/arch/arm/boot/dts/st/stm32mp157c-dk2.dts
@@ -63,6 +63,12 @@ &dsi_out {
 	remote-endpoint = <&panel_in>;
 };
 
+&hdp {
+	pinctrl-names = "default", "sleep";
+	pinctrl-0 = <&hdp2_gpo &hdp2_pins_a>;
+	pinctrl-1 = <&hdp2_sleep_pins_a>;
+};
+
 &i2c1 {
 	touchscreen@38 {
 		compatible = "focaltech,ft6236";

-- 
2.43.0

Re: [PATCH v3 2/9] dt-bindings: pinctrl: stm32: Introduce HDP

[Krzysztof Kozlowski]

On 23/05/2025 14:38, Clément Le Goffic wrote:
> 'HDP' stands for Hardware Debug Port, it is an hardware block in
> STMicrolectronics' MPUs that let the user decide which internal SoC's
> signal to observe.
> It provides 8 ports and for each port there is up to 16 different
> signals that can be output.
> Signals are different for each MPU.
> 
> Signed-off-by: Clément Le Goffic <clement.legoffic@foss.st.com>
> ---
>  .../bindings/pinctrl/st,stm32-pinctrl-hdp.yaml     | 187 +++++++++++++++++++++
>  1 file changed, 187 insertions(+)
> 
If there is going to be new version then filename matching compatible,
so st,stm32-hdp.yaml or st,stm32mp-hdp.yaml (compatible does not have
pinctrl).


Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

Best regards,
Krzysztof

Re: [PATCH v3 3/9] pinctrl: stm32: Introduce HDP driver

[Krzysztof Kozlowski]

On 23/05/2025 14:38, Clément Le Goffic wrote:
> This patch introduce the driver for the Hardware Debug Port available on

"Add driver...", see submitting patches



> STM32MP platforms. The HDP allows the observation of internal SoC
> signals by using multiplexers. Each HDP port can provide up to 16
> internal signals (one of them can be software controlled as a GPO).
> 
> Signed-off-by: Clément Le Goffic <clement.legoffic@foss.st.com>
> ---
>  drivers/pinctrl/stm32/Kconfig             |  14 +
>  drivers/pinctrl/stm32/Makefile            |   1 +
>  drivers/pinctrl/stm32/pinctrl-stm32-hdp.c | 720 ++++++++++++++++++++++++++++++
>  3 files changed, 735 insertions(+)
> 
> diff --git a/drivers/pinctrl/stm32/Kconfig b/drivers/pinctrl/stm32/Kconfig
> index 2656d3d3ae40..4b474cfd1f2c 100644
> --- a/drivers/pinctrl/stm32/Kconfig
> +++ b/drivers/pinctrl/stm32/Kconfig
> @@ -57,4 +57,18 @@ config PINCTRL_STM32MP257
>  	depends on OF && HAS_IOMEM
>  	default MACH_STM32MP25
>  	select PINCTRL_STM32
> +
> +config PINCTRL_STM32_HDP
> +	tristate "STMicroelectronics STM32 Hardware Debug Port (HDP) pin control"
> +	depends on OF && HAS_IOMEM
> +	default ARM64 || (ARM && CPU_V7)

I just cleaned this up and I still think this should be default for your
arch, not for every other platform during compile test. See bunch of my
commits "Do not enable by default during compile testing".


> +	select PINMUX
> +	select GENERIC_PINCONF
> +	select GPIOLIB
> +	help
> +	  The Hardware Debug Port allows the observation of internal signals.
> +	  It uses configurable multiplexer to route signals in a dedicated observation register.
> +	  This driver also permits the observation of signals on external SoC pins.
> +	  It permits the observation of up to 16 signals per HDP line.
> +
>  endif
> diff --git a/drivers/pinctrl/stm32/Makefile b/drivers/pinctrl/stm32/Makefile
> index 7b17464d8de1..98a1bbc7e16c 100644
> --- a/drivers/pinctrl/stm32/Makefile
> +++ b/drivers/pinctrl/stm32/Makefile
> @@ -11,3 +11,4 @@ obj-$(CONFIG_PINCTRL_STM32H743)	+= pinctrl-stm32h743.o
>  obj-$(CONFIG_PINCTRL_STM32MP135) += pinctrl-stm32mp135.o
>  obj-$(CONFIG_PINCTRL_STM32MP157) += pinctrl-stm32mp157.o
>  obj-$(CONFIG_PINCTRL_STM32MP257) += pinctrl-stm32mp257.o
> +obj-$(CONFIG_PINCTRL_STM32_HDP) += pinctrl-stm32-hdp.o
> diff --git a/drivers/pinctrl/stm32/pinctrl-stm32-hdp.c b/drivers/pinctrl/stm32/pinctrl-stm32-hdp.c
> new file mode 100644
> index 000000000000..e91442eb566b
> --- /dev/null
> +++ b/drivers/pinctrl/stm32/pinctrl-stm32-hdp.c
> @@ -0,0 +1,720 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) STMicroelectronics 2025 - All Rights Reserved
> + * Author: Clément Le Goffic <clement.legoffic@foss.st.com> for STMicroelectronics.
> + */
> +#include <linux/bits.h>
> +#include <linux/clk.h>
> +#include <linux/gpio/driver.h>
> +#include <linux/io.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>

Not used.

> +#include <linux/pinctrl/consumer.h>
> +#include <linux/pinctrl/pinconf-generic.h>
> +#include <linux/pinctrl/pinctrl.h>
> +#include <linux/pinctrl/pinmux.h>
> +#include <linux/platform_device.h>
> +#include <linux/pm.h>
> +
Best regards,
Krzysztof

Re: [PATCH v3 5/9] ARM: dts: stm32: add Hardware debug port (HDP) on stm32mp13

[Krzysztof Kozlowski]

On 23/05/2025 14:38, Clément Le Goffic wrote:
> Add the hdp devicetree node for stm32mp13 SoC family
> 
> Signed-off-by: Clément Le Goffic <clement.legoffic@foss.st.com>
> ---
>  arch/arm/boot/dts/st/stm32mp131.dtsi | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/st/stm32mp131.dtsi b/arch/arm/boot/dts/st/stm32mp131.dtsi
> index 8512a6e46b33..b0537bcdb9d5 100644
> --- a/arch/arm/boot/dts/st/stm32mp131.dtsi
> +++ b/arch/arm/boot/dts/st/stm32mp131.dtsi
> @@ -951,6 +951,12 @@ dts: thermal@50028000 {
>  			clocks = <&rcc DTS>;
>  			clock-names = "pclk";
>  			#thermal-sensor-cells = <0>;

Why are you enabling it? Commit msg should explain this and this should
be sparate patch.

> +		};
> +
> +		hdp: pinctrl@5002a000 {
> +			compatible = "st,stm32mp131-hdp";
> +			reg = <0x5002a000 0x400>;
> +			clocks = <&rcc HDP>;
>  			status = "disabled";

Why are you disabling it? What is missing?

>  		};
>  
> 


Best regards,
Krzysztof

Re: [PATCH v3 6/9] ARM: dts: stm32: add Hardware debug port (HDP) on stm32mp15

[Krzysztof Kozlowski]

On 23/05/2025 14:38, Clément Le Goffic wrote:
> Add the hdp devicetree node for stm32mp15 SoC family
> 
> Signed-off-by: Clément Le Goffic <clement.legoffic@foss.st.com>
> ---
>  arch/arm/boot/dts/st/stm32mp151.dtsi | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/st/stm32mp151.dtsi b/arch/arm/boot/dts/st/stm32mp151.dtsi
> index 0daa8ffe2ff5..b1b568dfd126 100644
> --- a/arch/arm/boot/dts/st/stm32mp151.dtsi
> +++ b/arch/arm/boot/dts/st/stm32mp151.dtsi
> @@ -270,6 +270,13 @@ dts: thermal@50028000 {
>  			status = "disabled";
>  		};
>  
> +		hdp: pinctrl@5002a000 {
> +			compatible = "st,stm32mp151-hdp";
> +			reg = <0x5002a000 0x400>;
> +			clocks = <&rcc HDP>;
> +			status = "disabled";

Same questions here and in further patches.

Best regards,
Krzysztof

Re: [PATCH v3 3/9] pinctrl: stm32: Introduce HDP driver

[Clement LE GOFFIC]

On 5/28/25 10:28, Krzysztof Kozlowski wrote:
> On 23/05/2025 14:38, Clément Le Goffic wrote:

Hi,

>> This patch introduce the driver for the Hardware Debug Port available on
> 
> "Add driver...", see submitting patches

Sure, I'll shorten the commit message

> 
> 
> 
>> STM32MP platforms. The HDP allows the observation of internal SoC
>> signals by using multiplexers. Each HDP port can provide up to 16
>> internal signals (one of them can be software controlled as a GPO).
>>
>> Signed-off-by: Clément Le Goffic <clement.legoffic@foss.st.com>
>> ---
>>   drivers/pinctrl/stm32/Kconfig             |  14 +
>>   drivers/pinctrl/stm32/Makefile            |   1 +
>>   drivers/pinctrl/stm32/pinctrl-stm32-hdp.c | 720 ++++++++++++++++++++++++++++++
>>   3 files changed, 735 insertions(+)
>>
>> diff --git a/drivers/pinctrl/stm32/Kconfig b/drivers/pinctrl/stm32/Kconfig
>> index 2656d3d3ae40..4b474cfd1f2c 100644
>> --- a/drivers/pinctrl/stm32/Kconfig
>> +++ b/drivers/pinctrl/stm32/Kconfig
>> @@ -57,4 +57,18 @@ config PINCTRL_STM32MP257
>>   	depends on OF && HAS_IOMEM
>>   	default MACH_STM32MP25
>>   	select PINCTRL_STM32
>> +
>> +config PINCTRL_STM32_HDP
>> +	tristate "STMicroelectronics STM32 Hardware Debug Port (HDP) pin control"
>> +	depends on OF && HAS_IOMEM
>> +	default ARM64 || (ARM && CPU_V7)
> 
> I just cleaned this up and I still think this should be default for your
> arch, not for every other platform during compile test. See bunch of my
> commits "Do not enable by default during compile testing".
> 

Ok I'll use "default ARCH_STM32 && !ARM_SINGLE_ARMV7M" which is more 
restrictive.

> 
>> +	select PINMUX
>> +	select GENERIC_PINCONF
>> +	select GPIOLIB
>> +	help
>> +	  The Hardware Debug Port allows the observation of internal signals.
>> +	  It uses configurable multiplexer to route signals in a dedicated observation register.
>> +	  This driver also permits the observation of signals on external SoC pins.
>> +	  It permits the observation of up to 16 signals per HDP line.
>> +
>>   endif
>> diff --git a/drivers/pinctrl/stm32/Makefile b/drivers/pinctrl/stm32/Makefile
>> index 7b17464d8de1..98a1bbc7e16c 100644
>> --- a/drivers/pinctrl/stm32/Makefile
>> +++ b/drivers/pinctrl/stm32/Makefile
>> @@ -11,3 +11,4 @@ obj-$(CONFIG_PINCTRL_STM32H743)	+= pinctrl-stm32h743.o
>>   obj-$(CONFIG_PINCTRL_STM32MP135) += pinctrl-stm32mp135.o
>>   obj-$(CONFIG_PINCTRL_STM32MP157) += pinctrl-stm32mp157.o
>>   obj-$(CONFIG_PINCTRL_STM32MP257) += pinctrl-stm32mp257.o
>> +obj-$(CONFIG_PINCTRL_STM32_HDP) += pinctrl-stm32-hdp.o
>> diff --git a/drivers/pinctrl/stm32/pinctrl-stm32-hdp.c b/drivers/pinctrl/stm32/pinctrl-stm32-hdp.c
>> new file mode 100644
>> index 000000000000..e91442eb566b
>> --- /dev/null
>> +++ b/drivers/pinctrl/stm32/pinctrl-stm32-hdp.c
>> @@ -0,0 +1,720 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * Copyright (C) STMicroelectronics 2025 - All Rights Reserved
>> + * Author: Clément Le Goffic <clement.legoffic@foss.st.com> for STMicroelectronics.
>> + */
>> +#include <linux/bits.h>
>> +#include <linux/clk.h>
>> +#include <linux/gpio/driver.h>
>> +#include <linux/io.h>
>> +#include <linux/of.h>
>> +#include <linux/of_device.h>
> 
> Not used.

Ack

> 
>> +#include <linux/pinctrl/consumer.h>
>> +#include <linux/pinctrl/pinconf-generic.h>
>> +#include <linux/pinctrl/pinctrl.h>
>> +#include <linux/pinctrl/pinmux.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/pm.h>
>> +
> Best regards,
> Krzysztof

Re: [PATCH v3 5/9] ARM: dts: stm32: add Hardware debug port (HDP) on stm32mp13

[Clement LE GOFFIC]

On 5/28/25 10:55, Krzysztof Kozlowski wrote:
> On 23/05/2025 14:38, Clément Le Goffic wrote:
>> Add the hdp devicetree node for stm32mp13 SoC family
>>
>> Signed-off-by: Clément Le Goffic <clement.legoffic@foss.st.com>
>> ---
>>   arch/arm/boot/dts/st/stm32mp131.dtsi | 6 ++++++
>>   1 file changed, 6 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/st/stm32mp131.dtsi b/arch/arm/boot/dts/st/stm32mp131.dtsi
>> index 8512a6e46b33..b0537bcdb9d5 100644
>> --- a/arch/arm/boot/dts/st/stm32mp131.dtsi
>> +++ b/arch/arm/boot/dts/st/stm32mp131.dtsi
>> @@ -951,6 +951,12 @@ dts: thermal@50028000 {
>>   			clocks = <&rcc DTS>;
>>   			clock-names = "pclk";
>>   			#thermal-sensor-cells = <0>;
> 
> Why are you enabling it? Commit msg should explain this and this should
> be sparate patch.

Oops good catch I'll fix this.

> 
>> +		};
>> +
>> +		hdp: pinctrl@5002a000 {
>> +			compatible = "st,stm32mp131-hdp";
>> +			reg = <0x5002a000 0x400>;
>> +			clocks = <&rcc HDP>;
>>   			status = "disabled";
> 
> Why are you disabling it? What is missing?

Nothing is missing just disabled by default.
The node is then enabled when needed in board's dts file.

> 
>>   		};
>>   
>>
> 
> 
> Best regards,
> Krzysztof

Clément

Re: [PATCH v3 6/9] ARM: dts: stm32: add Hardware debug port (HDP) on stm32mp15

[Clement LE GOFFIC]

On 5/28/25 11:00, Krzysztof Kozlowski wrote:
> On 23/05/2025 14:38, Clément Le Goffic wrote:
>> Add the hdp devicetree node for stm32mp15 SoC family
>>
>> Signed-off-by: Clément Le Goffic <clement.legoffic@foss.st.com>
>> ---
>>   arch/arm/boot/dts/st/stm32mp151.dtsi | 7 +++++++
>>   1 file changed, 7 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/st/stm32mp151.dtsi b/arch/arm/boot/dts/st/stm32mp151.dtsi
>> index 0daa8ffe2ff5..b1b568dfd126 100644
>> --- a/arch/arm/boot/dts/st/stm32mp151.dtsi
>> +++ b/arch/arm/boot/dts/st/stm32mp151.dtsi
>> @@ -270,6 +270,13 @@ dts: thermal@50028000 {
>>   			status = "disabled";
>>   		};
>>   
>> +		hdp: pinctrl@5002a000 {
>> +			compatible = "st,stm32mp151-hdp";
>> +			reg = <0x5002a000 0x400>;
>> +			clocks = <&rcc HDP>;
>> +			status = "disabled";
> 
> Same questions here and in further patches.

Same, disabled by default and enable in board's dts file

> 
> Best regards,
> Krzysztof

Clément

Re: [PATCH v3 5/9] ARM: dts: stm32: add Hardware debug port (HDP) on stm32mp13

[Krzysztof Kozlowski]

On 28/05/2025 14:14, Clement LE GOFFIC wrote:
>>
>>> +		};
>>> +
>>> +		hdp: pinctrl@5002a000 {
>>> +			compatible = "st,stm32mp131-hdp";
>>> +			reg = <0x5002a000 0x400>;
>>> +			clocks = <&rcc HDP>;
>>>   			status = "disabled";
>>
>> Why are you disabling it? What is missing?
> 
> Nothing is missing just disabled by default.
> The node is then enabled when needed in board's dts file.
Nodes should not be disabled by default if they are complete. That's why
I asked what is missing. Drop.

Best regards,
Krzysztof

Re: [PATCH v3 6/9] ARM: dts: stm32: add Hardware debug port (HDP) on stm32mp15

[Krzysztof Kozlowski]

On 28/05/2025 14:15, Clement LE GOFFIC wrote:
> On 5/28/25 11:00, Krzysztof Kozlowski wrote:
>> On 23/05/2025 14:38, Clément Le Goffic wrote:
>>> Add the hdp devicetree node for stm32mp15 SoC family
>>>
>>> Signed-off-by: Clément Le Goffic <clement.legoffic@foss.st.com>
>>> ---
>>>   arch/arm/boot/dts/st/stm32mp151.dtsi | 7 +++++++
>>>   1 file changed, 7 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/st/stm32mp151.dtsi b/arch/arm/boot/dts/st/stm32mp151.dtsi
>>> index 0daa8ffe2ff5..b1b568dfd126 100644
>>> --- a/arch/arm/boot/dts/st/stm32mp151.dtsi
>>> +++ b/arch/arm/boot/dts/st/stm32mp151.dtsi
>>> @@ -270,6 +270,13 @@ dts: thermal@50028000 {
>>>   			status = "disabled";
>>>   		};
>>>   
>>> +		hdp: pinctrl@5002a000 {
>>> +			compatible = "st,stm32mp151-hdp";
>>> +			reg = <0x5002a000 0x400>;
>>> +			clocks = <&rcc HDP>;
>>> +			status = "disabled";
>>
>> Same questions here and in further patches.
> 
> Same, disabled by default and enable in board's dts file


So the same answer, node is complete so should it be enabled.

Best regards,
Krzysztof

Re: [PATCH v3 5/9] ARM: dts: stm32: add Hardware debug port (HDP) on stm32mp13

[Krzysztof Kozlowski]

On 28/05/2025 14:14, Clement LE GOFFIC wrote:
>>
>>> +		};
>>> +
>>> +		hdp: pinctrl@5002a000 {
>>> +			compatible = "st,stm32mp131-hdp";
>>> +			reg = <0x5002a000 0x400>;
>>> +			clocks = <&rcc HDP>;
>>>   			status = "disabled";
>>
>> Why are you disabling it? What is missing?
> 
> Nothing is missing just disabled by default.
> The node is then enabled when needed in board's dts file.
> 
How much time did you give me to respond to this feedback? 1 hour 15
minutes. That's too short. We have also other work except constantly
checking inbox.

Best regards,
Krzysztof

Re: [PATCH v3 8/9] ARM: dts: stm32: add alternate pinmux for HDP pin and add HDP pinctrl node

[Linus Walleij]

On Fri, May 23, 2025 at 2:40 PM Clément Le Goffic
<clement.legoffic@foss.st.com> wrote:

> Introduce hdp node to output a user defined value on port hdp2.
> Add pinctrl nodes to be able to output this signal on one SoC pin.
>
> Signed-off-by: Clément Le Goffic <clement.legoffic@foss.st.com>

That's nice, this is exactly how pin control is supposed to be
used!
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

Re: [PATCH v3 1/9] gpio: mmio: add BGPIOF_NO_INPUT flag for GPO gpiochip

[Linus Walleij]

On Fri, May 23, 2025 at 2:40 PM Clément Le Goffic
<clement.legoffic@foss.st.com> wrote:

> When using bgpio_init with a gpiochip acting as a GPO (output only), the
> gpiochip ops `direction_input` was set to `bgpio_simple_dir_in` by
> default but we have no input ability.
>
> Adding this flag allows to set a valid ops for the `direction_output`
> ops without setting a valid ops for `direction_input` by default.
>
> Signed-off-by: Clément Le Goffic <clement.legoffic@foss.st.com>

That's a good solution.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

Re: [PATCH v3 5/9] ARM: dts: stm32: add Hardware debug port (HDP) on stm32mp13

[Clement LE GOFFIC]

On 5/29/25 11:01, Krzysztof Kozlowski wrote:
> On 28/05/2025 14:14, Clement LE GOFFIC wrote:
>>>
>>>> +		};
>>>> +
>>>> +		hdp: pinctrl@5002a000 {
>>>> +			compatible = "st,stm32mp131-hdp";
>>>> +			reg = <0x5002a000 0x400>;
>>>> +			clocks = <&rcc HDP>;
>>>>    			status = "disabled";
>>>
>>> Why are you disabling it? What is missing?
>>
>> Nothing is missing just disabled by default.
>> The node is then enabled when needed in board's dts file.
> Nodes should not be disabled by default if they are complete. That's why
> I asked what is missing. Drop.

Hi Krzysztof, OK I better understand now.
So yes the 'pinctrl-*' properties which are board dependent are lacking.

In the last patch of my serie I add them (only for stm32mp157f-dk2) but 
keep it disabled because the pin is on an external connector (the 
Arduino connector of the board).
This prevent any issue with a possible connected module.

> Best regards,
> Krzysztof

Re: [PATCH v3 8/9] ARM: dts: stm32: add alternate pinmux for HDP pin and add HDP pinctrl node

[Clement LE GOFFIC]

On 6/5/25 14:57, Linus Walleij wrote:
> On Fri, May 23, 2025 at 2:40 PM Clément Le Goffic
> <clement.legoffic@foss.st.com> wrote:
> 
>> Introduce hdp node to output a user defined value on port hdp2.
>> Add pinctrl nodes to be able to output this signal on one SoC pin.
>>
>> Signed-off-by: Clément Le Goffic <clement.legoffic@foss.st.com>
> 
> That's nice, this is exactly how pin control is supposed to be
> used!

Hi Linus, thank you!

> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> 
> Yours,
> Linus Walleij

Re: [PATCH v3 5/9] ARM: dts: stm32: add Hardware debug port (HDP) on stm32mp13

[Krzysztof Kozlowski]

On 10/06/2025 14:02, Clement LE GOFFIC wrote:
> On 5/29/25 11:01, Krzysztof Kozlowski wrote:
>> On 28/05/2025 14:14, Clement LE GOFFIC wrote:
>>>>
>>>>> +		};
>>>>> +
>>>>> +		hdp: pinctrl@5002a000 {
>>>>> +			compatible = "st,stm32mp131-hdp";
>>>>> +			reg = <0x5002a000 0x400>;
>>>>> +			clocks = <&rcc HDP>;
>>>>>    			status = "disabled";
>>>>
>>>> Why are you disabling it? What is missing?
>>>
>>> Nothing is missing just disabled by default.
>>> The node is then enabled when needed in board's dts file.
>> Nodes should not be disabled by default if they are complete. That's why
>> I asked what is missing. Drop.
> 
> Hi Krzysztof, OK I better understand now.
> So yes the 'pinctrl-*' properties which are board dependent are lacking.

These are not properties of this node.

> 
> In the last patch of my serie I add them (only for stm32mp157f-dk2) but 
> keep it disabled because the pin is on an external connector (the 
> Arduino connector of the board).
> This prevent any issue with a possible connected module.

Not relevant. Pin control for connector are board specific, but pinctrl
SoC part is SoC.

Best regards,
Krzysztof

Re: [PATCH v3 5/9] ARM: dts: stm32: add Hardware debug port (HDP) on stm32mp13

[Clement LE GOFFIC]

On 6/10/25 14:38, Krzysztof Kozlowski wrote:
> On 10/06/2025 14:02, Clement LE GOFFIC wrote:
>> On 5/29/25 11:01, Krzysztof Kozlowski wrote:
>>> On 28/05/2025 14:14, Clement LE GOFFIC wrote:
>>>>>
>>>>>> +		};
>>>>>> +
>>>>>> +		hdp: pinctrl@5002a000 {
>>>>>> +			compatible = "st,stm32mp131-hdp";
>>>>>> +			reg = <0x5002a000 0x400>;
>>>>>> +			clocks = <&rcc HDP>;
>>>>>>     			status = "disabled";
>>>>>
>>>>> Why are you disabling it? What is missing?
>>>>
>>>> Nothing is missing just disabled by default.
>>>> The node is then enabled when needed in board's dts file.
>>> Nodes should not be disabled by default if they are complete. That's why
>>> I asked what is missing. Drop.
>>
>> Hi Krzysztof, OK I better understand now.
>> So yes the 'pinctrl-*' properties which are board dependent are lacking.
> 
> These are not properties of this node.

Does this mean I should add 'pinctrl-*' properties in bindings yaml file ?
I don't get it..

>>
>> In the last patch of my serie I add them (only for stm32mp157f-dk2) but
>> keep it disabled because the pin is on an external connector (the
>> Arduino connector of the board).
>> This prevent any issue with a possible connected module.
> 
> Not relevant. Pin control for connector are board specific, but pinctrl
> SoC part is SoC.

I think we don't understand each other here too. I don't understand the 
end of your sentence "pinctrl SoC part is SoC".

Maybe some informations that could help:
The 'pinctrl-*' properties are used in the HDP case to select the 
internal signal to output AND the alternate function on the pin to 
output the HDP function.

> Best regards,
> Krzysztof

Re: [PATCH v3 5/9] ARM: dts: stm32: add Hardware debug port (HDP) on stm32mp13

[Krzysztof Kozlowski]

On 10/06/2025 15:33, Clement LE GOFFIC wrote:
> On 6/10/25 14:38, Krzysztof Kozlowski wrote:
>> On 10/06/2025 14:02, Clement LE GOFFIC wrote:
>>> On 5/29/25 11:01, Krzysztof Kozlowski wrote:
>>>> On 28/05/2025 14:14, Clement LE GOFFIC wrote:
>>>>>>
>>>>>>> +		};
>>>>>>> +
>>>>>>> +		hdp: pinctrl@5002a000 {
>>>>>>> +			compatible = "st,stm32mp131-hdp";
>>>>>>> +			reg = <0x5002a000 0x400>;
>>>>>>> +			clocks = <&rcc HDP>;
>>>>>>>     			status = "disabled";
>>>>>>
>>>>>> Why are you disabling it? What is missing?
>>>>>
>>>>> Nothing is missing just disabled by default.
>>>>> The node is then enabled when needed in board's dts file.
>>>> Nodes should not be disabled by default if they are complete. That's why
>>>> I asked what is missing. Drop.
>>>
>>> Hi Krzysztof, OK I better understand now.
>>> So yes the 'pinctrl-*' properties which are board dependent are lacking.
>>
>> These are not properties of this node.
> 
> Does this mean I should add 'pinctrl-*' properties in bindings yaml file ?
> I don't get it..

These properties have no meaning here, so the hardware description is
complete. You claim that you miss them thus device is incomplete is just
not correct: these properties do not belong here! They belong to the
board but even there they are totally optional. Why would they be a
required resource?

To remind: we talk here ONLY about required resources.

> 
>>>
>>> In the last patch of my serie I add them (only for stm32mp157f-dk2) but
>>> keep it disabled because the pin is on an external connector (the
>>> Arduino connector of the board).
>>> This prevent any issue with a possible connected module.
>>
>> Not relevant. Pin control for connector are board specific, but pinctrl
>> SoC part is SoC.
> 
> I think we don't understand each other here too. I don't understand the 
> end of your sentence "pinctrl SoC part is SoC".

Please read first how DTS is organized.

The pin controller device is part of SoC not part of a board.

Pins configuration for devices on the board are not part of the SoC.
What is not clear here? We talk here in terms how DTS is supposed to be
organized.

> 
> Maybe some informations that could help:
> The 'pinctrl-*' properties are used in the HDP case to select the 
> internal signal to output AND the alternate function on the pin to 
> output the HDP function.

We all know this.

> 
>> Best regards,
>> Krzysztof
> 


Best regards,
Krzysztof

Re: [PATCH v3 5/9] ARM: dts: stm32: add Hardware debug port (HDP) on stm32mp13

[Clement LE GOFFIC]

On 6/11/25 08:35, Krzysztof Kozlowski wrote:
> On 10/06/2025 15:33, Clement LE GOFFIC wrote:
>> On 6/10/25 14:38, Krzysztof Kozlowski wrote:
>>> On 10/06/2025 14:02, Clement LE GOFFIC wrote:
>>>> On 5/29/25 11:01, Krzysztof Kozlowski wrote:
>>>>> On 28/05/2025 14:14, Clement LE GOFFIC wrote:
>>>>>>>
>>>>>>>> +		};
>>>>>>>> +
>>>>>>>> +		hdp: pinctrl@5002a000 {
>>>>>>>> +			compatible = "st,stm32mp131-hdp";
>>>>>>>> +			reg = <0x5002a000 0x400>;
>>>>>>>> +			clocks = <&rcc HDP>;
>>>>>>>>      			status = "disabled";
>>>>>>>
>>>>>>> Why are you disabling it? What is missing?
>>>>>>
>>>>>> Nothing is missing just disabled by default.
>>>>>> The node is then enabled when needed in board's dts file.
>>>>> Nodes should not be disabled by default if they are complete. That's why
>>>>> I asked what is missing. Drop.
>>>>
>>>> Hi Krzysztof, OK I better understand now.
>>>> So yes the 'pinctrl-*' properties which are board dependent are lacking.
>>>
>>> These are not properties of this node.
>>
>> Does this mean I should add 'pinctrl-*' properties in bindings yaml file ?
>> I don't get it..
> 
> These properties have no meaning here, so the hardware description is
> complete. You claim that you miss them thus device is incomplete is just
> not correct: these properties do not belong here! They belong to the
> board but even there they are totally optional. Why would they be a
> required resource?
> 
> To remind: we talk here ONLY about required resources.

Yes, 'pinctrl-*' properties belongs to the board and are not required.
So nothing is missing.

This hdp node in the SoC dtsi file can be enabled by default.
But the hdp driver will probe and do nothing because without the 
'pinctrl-*' properties from the board files it would not be able to 
access to any pin.
I consider enabling this driver by default in SoC dtsi file as just 
increasing the boot time on "every" board.
It's the board dts that requires the hdp and provides the 'pinctrl-*' 
properties to connect the hdp to some SoC pin and then to some signal on 
the board. For me it's natural to have the status okay only in the board 
dts file.

>>
>>>>
>>>> In the last patch of my serie I add them (only for stm32mp157f-dk2) but
>>>> keep it disabled because the pin is on an external connector (the
>>>> Arduino connector of the board).
>>>> This prevent any issue with a possible connected module.
>>>
>>> Not relevant. Pin control for connector are board specific, but pinctrl
>>> SoC part is SoC.
>>
>> I think we don't understand each other here too. I don't understand the
>> end of your sentence "pinctrl SoC part is SoC".
> 
> Please read first how DTS is organized.
> 
> The pin controller device is part of SoC not part of a board.
> 
> Pins configuration for devices on the board are not part of the SoC.
> What is not clear here? We talk here in terms how DTS is supposed to be
> organized.

Now everything is clear, you want me to just set status enable in soc 
dtsi file but I disagree, keep discussing.

> 
>>
>> Maybe some informations that could help:
>> The 'pinctrl-*' properties are used in the HDP case to select the
>> internal signal to output AND the alternate function on the pin to
>> output the HDP function.
> 
> We all know this.

Ok fine

Best regards,

Clément

> 
>>
>>> Best regards,
>>> Krzysztof
>>
> 
> 
> Best regards,
> Krzysztof

Re: [PATCH v3 5/9] ARM: dts: stm32: add Hardware debug port (HDP) on stm32mp13

[Krzysztof Kozlowski]

On 11/06/2025 16:08, Clement LE GOFFIC wrote:
> On 6/11/25 08:35, Krzysztof Kozlowski wrote:
>> On 10/06/2025 15:33, Clement LE GOFFIC wrote:
>>> On 6/10/25 14:38, Krzysztof Kozlowski wrote:
>>>> On 10/06/2025 14:02, Clement LE GOFFIC wrote:
>>>>> On 5/29/25 11:01, Krzysztof Kozlowski wrote:
>>>>>> On 28/05/2025 14:14, Clement LE GOFFIC wrote:
>>>>>>>>
>>>>>>>>> +		};
>>>>>>>>> +
>>>>>>>>> +		hdp: pinctrl@5002a000 {
>>>>>>>>> +			compatible = "st,stm32mp131-hdp";
>>>>>>>>> +			reg = <0x5002a000 0x400>;
>>>>>>>>> +			clocks = <&rcc HDP>;
>>>>>>>>>      			status = "disabled";
>>>>>>>>
>>>>>>>> Why are you disabling it? What is missing?
>>>>>>>
>>>>>>> Nothing is missing just disabled by default.
>>>>>>> The node is then enabled when needed in board's dts file.
>>>>>> Nodes should not be disabled by default if they are complete. That's why
>>>>>> I asked what is missing. Drop.
>>>>>
>>>>> Hi Krzysztof, OK I better understand now.
>>>>> So yes the 'pinctrl-*' properties which are board dependent are lacking.
>>>>
>>>> These are not properties of this node.
>>>
>>> Does this mean I should add 'pinctrl-*' properties in bindings yaml file ?
>>> I don't get it..
>>
>> These properties have no meaning here, so the hardware description is
>> complete. You claim that you miss them thus device is incomplete is just
>> not correct: these properties do not belong here! They belong to the
>> board but even there they are totally optional. Why would they be a
>> required resource?
>>
>> To remind: we talk here ONLY about required resources.
> 
> Yes, 'pinctrl-*' properties belongs to the board and are not required.
> So nothing is missing.
> 
> This hdp node in the SoC dtsi file can be enabled by default.
> But the hdp driver will probe and do nothing because without the 
> 'pinctrl-*' properties from the board files it would not be able to 
> access to any pin.


Pinctrl has other features in general, including interfaces to userspace
(as pretty often combined with gpio, although not sure if relevant here).

> I consider enabling this driver by default in SoC dtsi file as just 
> increasing the boot time on "every" board.
> It's the board dts that requires the hdp and provides the 'pinctrl-*' 
> properties to connect the hdp to some SoC pin and then to some signal on 
> the board. For me it's natural to have the status okay only in the board 
> dts file.

The DTS is not the way to optimize boot processes. It is OS-independent
hardware description. My BSD system for example uses smart driver which
avoids probing, but also my user-space needs this device to talk over
exposed interface, so why choice of Linux probing should affect others?

Best regards,
Krzysztof

Re: [PATCH v3 5/9] ARM: dts: stm32: add Hardware debug port (HDP) on stm32mp13

[Clement LE GOFFIC]

On 6/11/25 17:48, Krzysztof Kozlowski wrote:
> On 11/06/2025 16:08, Clement LE GOFFIC wrote:
>> On 6/11/25 08:35, Krzysztof Kozlowski wrote:
>>> On 10/06/2025 15:33, Clement LE GOFFIC wrote:
>>>> On 6/10/25 14:38, Krzysztof Kozlowski wrote:
>>>>> On 10/06/2025 14:02, Clement LE GOFFIC wrote:
>>>>>> On 5/29/25 11:01, Krzysztof Kozlowski wrote:
>>>>>>> On 28/05/2025 14:14, Clement LE GOFFIC wrote:
>>>>>>>>>
>>>>>>>>>> +		};
>>>>>>>>>> +
>>>>>>>>>> +		hdp: pinctrl@5002a000 {
>>>>>>>>>> +			compatible = "st,stm32mp131-hdp";
>>>>>>>>>> +			reg = <0x5002a000 0x400>;
>>>>>>>>>> +			clocks = <&rcc HDP>;
>>>>>>>>>>       			status = "disabled";
>>>>>>>>>
>>>>>>>>> Why are you disabling it? What is missing?
>>>>>>>>
>>>>>>>> Nothing is missing just disabled by default.
>>>>>>>> The node is then enabled when needed in board's dts file.
>>>>>>> Nodes should not be disabled by default if they are complete. That's why
>>>>>>> I asked what is missing. Drop.
>>>>>>
>>>>>> Hi Krzysztof, OK I better understand now.
>>>>>> So yes the 'pinctrl-*' properties which are board dependent are lacking.
>>>>>
>>>>> These are not properties of this node.
>>>>
>>>> Does this mean I should add 'pinctrl-*' properties in bindings yaml file ?
>>>> I don't get it..
>>>
>>> These properties have no meaning here, so the hardware description is
>>> complete. You claim that you miss them thus device is incomplete is just
>>> not correct: these properties do not belong here! They belong to the
>>> board but even there they are totally optional. Why would they be a
>>> required resource?
>>>
>>> To remind: we talk here ONLY about required resources.
>>
>> Yes, 'pinctrl-*' properties belongs to the board and are not required.
>> So nothing is missing.
>>
>> This hdp node in the SoC dtsi file can be enabled by default.
>> But the hdp driver will probe and do nothing because without the
>> 'pinctrl-*' properties from the board files it would not be able to
>> access to any pin.
> 
> 
> Pinctrl has other features in general, including interfaces to userspace
> (as pretty often combined with gpio, although not sure if relevant here).

You're right. Also HDP pinctrl has a GPO feature accessible from userspace.
But by default the HDP is not connected to any pad; it needs the board 
'pinctrl-*' properties to configure the SoC pinctrl and expose HDP on 
the SoC pads.

That's why for me the enabling of the driver should be in the board file 
together with the SoC pinctrl configuration.

The userland cannot change the pinctrl alternate function mux, this is 
statically defined by the devicetree.

> 
>> I consider enabling this driver by default in SoC dtsi file as just
>> increasing the boot time on "every" board.
>> It's the board dts that requires the hdp and provides the 'pinctrl-*'
>> properties to connect the hdp to some SoC pin and then to some signal on
>> the board. For me it's natural to have the status okay only in the board
>> dts file.
> 
> The DTS is not the way to optimize boot processes. It is OS-independent
> hardware description. My BSD system for example uses smart driver which
> avoids probing, but also my user-space needs this device to talk over
> exposed interface, so why choice of Linux probing should affect others?

As I wrote above the HDP will not offer any functionality without the 
'pinctrl-*' properties in the board file.
If you insist, I can enable it in the SoC file but I really don't see 
any reason for that.

Best regards, Clément

> 
> Best regards,
> Krzysztof

Re: [PATCH v3 5/9] ARM: dts: stm32: add Hardware debug port (HDP) on stm32mp13

[Krzysztof Kozlowski]

On 12/06/2025 11:31, Clement LE GOFFIC wrote:
> On 6/11/25 17:48, Krzysztof Kozlowski wrote:
>> On 11/06/2025 16:08, Clement LE GOFFIC wrote:
>>> On 6/11/25 08:35, Krzysztof Kozlowski wrote:
>>>> On 10/06/2025 15:33, Clement LE GOFFIC wrote:
>>>>> On 6/10/25 14:38, Krzysztof Kozlowski wrote:
>>>>>> On 10/06/2025 14:02, Clement LE GOFFIC wrote:
>>>>>>> On 5/29/25 11:01, Krzysztof Kozlowski wrote:
>>>>>>>> On 28/05/2025 14:14, Clement LE GOFFIC wrote:
>>>>>>>>>>
>>>>>>>>>>> +		};
>>>>>>>>>>> +
>>>>>>>>>>> +		hdp: pinctrl@5002a000 {
>>>>>>>>>>> +			compatible = "st,stm32mp131-hdp";
>>>>>>>>>>> +			reg = <0x5002a000 0x400>;
>>>>>>>>>>> +			clocks = <&rcc HDP>;
>>>>>>>>>>>       			status = "disabled";
>>>>>>>>>>
>>>>>>>>>> Why are you disabling it? What is missing?
>>>>>>>>>
>>>>>>>>> Nothing is missing just disabled by default.
>>>>>>>>> The node is then enabled when needed in board's dts file.
>>>>>>>> Nodes should not be disabled by default if they are complete. That's why
>>>>>>>> I asked what is missing. Drop.
>>>>>>>
>>>>>>> Hi Krzysztof, OK I better understand now.
>>>>>>> So yes the 'pinctrl-*' properties which are board dependent are lacking.
>>>>>>
>>>>>> These are not properties of this node.
>>>>>
>>>>> Does this mean I should add 'pinctrl-*' properties in bindings yaml file ?
>>>>> I don't get it..
>>>>
>>>> These properties have no meaning here, so the hardware description is
>>>> complete. You claim that you miss them thus device is incomplete is just
>>>> not correct: these properties do not belong here! They belong to the
>>>> board but even there they are totally optional. Why would they be a
>>>> required resource?
>>>>
>>>> To remind: we talk here ONLY about required resources.
>>>
>>> Yes, 'pinctrl-*' properties belongs to the board and are not required.
>>> So nothing is missing.
>>>
>>> This hdp node in the SoC dtsi file can be enabled by default.
>>> But the hdp driver will probe and do nothing because without the
>>> 'pinctrl-*' properties from the board files it would not be able to
>>> access to any pin.
>>
>>
>> Pinctrl has other features in general, including interfaces to userspace
>> (as pretty often combined with gpio, although not sure if relevant here).
> 
> You're right. Also HDP pinctrl has a GPO feature accessible from userspace.
> But by default the HDP is not connected to any pad; it needs the board 

OK, then that was the answer to my first question - what is missing.
However aren't these pads connected internally also to other parts of
the SoC (like in most other vendors)?

> 'pinctrl-*' properties to configure the SoC pinctrl and expose HDP on 
> the SoC pads.
> 
> That's why for me the enabling of the driver should be in the board file 
> together with the SoC pinctrl configuration.

And what are the default pad settings configured by HPD driver in
bootloader (and by bootloader I mean one of few bootloaders this is
going to be used on like U-Boot)

> 
> The userland cannot change the pinctrl alternate function mux, this is 
> statically defined by the devicetree.

If you expose GPIO then userland needs this regardless of alternate mux.
IOW, board level could not configure mux because it should be always
configured to safe GPIO input.

Best regards,
Krzysztof

Re: [PATCH v3 5/9] ARM: dts: stm32: add Hardware debug port (HDP) on stm32mp13

[Clement LE GOFFIC]

On 6/12/25 13:05, Krzysztof Kozlowski wrote:
> On 12/06/2025 11:31, Clement LE GOFFIC wrote:
>> On 6/11/25 17:48, Krzysztof Kozlowski wrote:
>>> On 11/06/2025 16:08, Clement LE GOFFIC wrote:
>>>> On 6/11/25 08:35, Krzysztof Kozlowski wrote:
>>>>> On 10/06/2025 15:33, Clement LE GOFFIC wrote:
>>>>>> On 6/10/25 14:38, Krzysztof Kozlowski wrote:
>>>>>>> On 10/06/2025 14:02, Clement LE GOFFIC wrote:
>>>>>>>> On 5/29/25 11:01, Krzysztof Kozlowski wrote:
>>>>>>>>> On 28/05/2025 14:14, Clement LE GOFFIC wrote:
>>>>>>>>>>>
>>>>>>>>>>>> +		};
>>>>>>>>>>>> +
>>>>>>>>>>>> +		hdp: pinctrl@5002a000 {
>>>>>>>>>>>> +			compatible = "st,stm32mp131-hdp";
>>>>>>>>>>>> +			reg = <0x5002a000 0x400>;
>>>>>>>>>>>> +			clocks = <&rcc HDP>;
>>>>>>>>>>>>        			status = "disabled";
>>>>>>>>>>>
>>>>>>>>>>> Why are you disabling it? What is missing?
>>>>>>>>>>
>>>>>>>>>> Nothing is missing just disabled by default.
>>>>>>>>>> The node is then enabled when needed in board's dts file.
>>>>>>>>> Nodes should not be disabled by default if they are complete. That's why
>>>>>>>>> I asked what is missing. Drop.
>>>>>>>>
>>>>>>>> Hi Krzysztof, OK I better understand now.
>>>>>>>> So yes the 'pinctrl-*' properties which are board dependent are lacking.
>>>>>>>
>>>>>>> These are not properties of this node.
>>>>>>
>>>>>> Does this mean I should add 'pinctrl-*' properties in bindings yaml file ?
>>>>>> I don't get it..
>>>>>
>>>>> These properties have no meaning here, so the hardware description is
>>>>> complete. You claim that you miss them thus device is incomplete is just
>>>>> not correct: these properties do not belong here! They belong to the
>>>>> board but even there they are totally optional. Why would they be a
>>>>> required resource?
>>>>>
>>>>> To remind: we talk here ONLY about required resources.
>>>>
>>>> Yes, 'pinctrl-*' properties belongs to the board and are not required.
>>>> So nothing is missing.
>>>>
>>>> This hdp node in the SoC dtsi file can be enabled by default.
>>>> But the hdp driver will probe and do nothing because without the
>>>> 'pinctrl-*' properties from the board files it would not be able to
>>>> access to any pin.
>>>
>>>
>>> Pinctrl has other features in general, including interfaces to userspace
>>> (as pretty often combined with gpio, although not sure if relevant here).
>>
>> You're right. Also HDP pinctrl has a GPO feature accessible from userspace.
>> But by default the HDP is not connected to any pad; it needs the board
> 
> OK, then that was the answer to my first question - what is missing.
> However aren't these pads connected internally also to other parts of
> the SoC (like in most other vendors)?

No, HDP "output pads" are only connected to SoC pinctrl to route outside 
the internal SoC signals for debug purpose.

>> 'pinctrl-*' properties to configure the SoC pinctrl and expose HDP on
>> the SoC pads.
>>
>> That's why for me the enabling of the driver should be in the board file
>> together with the SoC pinctrl configuration.
> 
> And what are the default pad settings configured by HPD driver in
> bootloader (and by bootloader I mean one of few bootloaders this is
> going to be used on like U-Boot)

The default is to use the GPIO of the SoC pinctrl. The HDP is not routed 
outside.
  >>
>> The userland cannot change the pinctrl alternate function mux, this is
>> statically defined by the devicetree.
> 
> If you expose GPIO then userland needs this regardless of alternate mux.
> IOW, board level could not configure mux because it should be always
> configured to safe GPIO input.

For userland sight view, SoC GPIO are preferred instead of HDP.
HDP is only GPO not GPIO. 'pinctrl-*' properties configure at the same 
time the SoC pinctrl mux to HDP and the HDP pinctrl mux to one of the 
HDP functions (e.g. GPO).

Best regards,
Clément

Re: [PATCH v3 5/9] ARM: dts: stm32: add Hardware debug port (HDP) on stm32mp13

[Krzysztof Kozlowski]

On 12/06/2025 15:02, Clement LE GOFFIC wrote:
> On 6/12/25 13:05, Krzysztof Kozlowski wrote:
>> On 12/06/2025 11:31, Clement LE GOFFIC wrote:
>>> On 6/11/25 17:48, Krzysztof Kozlowski wrote:
>>>> On 11/06/2025 16:08, Clement LE GOFFIC wrote:
>>>>> On 6/11/25 08:35, Krzysztof Kozlowski wrote:
>>>>>> On 10/06/2025 15:33, Clement LE GOFFIC wrote:
>>>>>>> On 6/10/25 14:38, Krzysztof Kozlowski wrote:
>>>>>>>> On 10/06/2025 14:02, Clement LE GOFFIC wrote:
>>>>>>>>> On 5/29/25 11:01, Krzysztof Kozlowski wrote:
>>>>>>>>>> On 28/05/2025 14:14, Clement LE GOFFIC wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> +		};
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +		hdp: pinctrl@5002a000 {
>>>>>>>>>>>>> +			compatible = "st,stm32mp131-hdp";
>>>>>>>>>>>>> +			reg = <0x5002a000 0x400>;
>>>>>>>>>>>>> +			clocks = <&rcc HDP>;
>>>>>>>>>>>>>        			status = "disabled";
>>>>>>>>>>>>
>>>>>>>>>>>> Why are you disabling it? What is missing?
>>>>>>>>>>>
>>>>>>>>>>> Nothing is missing just disabled by default.
>>>>>>>>>>> The node is then enabled when needed in board's dts file.
>>>>>>>>>> Nodes should not be disabled by default if they are complete. That's why
>>>>>>>>>> I asked what is missing. Drop.
>>>>>>>>>
>>>>>>>>> Hi Krzysztof, OK I better understand now.
>>>>>>>>> So yes the 'pinctrl-*' properties which are board dependent are lacking.
>>>>>>>>
>>>>>>>> These are not properties of this node.
>>>>>>>
>>>>>>> Does this mean I should add 'pinctrl-*' properties in bindings yaml file ?
>>>>>>> I don't get it..
>>>>>>
>>>>>> These properties have no meaning here, so the hardware description is
>>>>>> complete. You claim that you miss them thus device is incomplete is just
>>>>>> not correct: these properties do not belong here! They belong to the
>>>>>> board but even there they are totally optional. Why would they be a
>>>>>> required resource?
>>>>>>
>>>>>> To remind: we talk here ONLY about required resources.
>>>>>
>>>>> Yes, 'pinctrl-*' properties belongs to the board and are not required.
>>>>> So nothing is missing.
>>>>>
>>>>> This hdp node in the SoC dtsi file can be enabled by default.
>>>>> But the hdp driver will probe and do nothing because without the
>>>>> 'pinctrl-*' properties from the board files it would not be able to
>>>>> access to any pin.
>>>>
>>>>
>>>> Pinctrl has other features in general, including interfaces to userspace
>>>> (as pretty often combined with gpio, although not sure if relevant here).
>>>
>>> You're right. Also HDP pinctrl has a GPO feature accessible from userspace.
>>> But by default the HDP is not connected to any pad; it needs the board
>>
>> OK, then that was the answer to my first question - what is missing.
>> However aren't these pads connected internally also to other parts of
>> the SoC (like in most other vendors)?
> 
> No, HDP "output pads" are only connected to SoC pinctrl to route outside 
> the internal SoC signals for debug purpose.
> 
>>> 'pinctrl-*' properties to configure the SoC pinctrl and expose HDP on
>>> the SoC pads.
>>>
>>> That's why for me the enabling of the driver should be in the board file
>>> together with the SoC pinctrl configuration.
>>
>> And what are the default pad settings configured by HPD driver in
>> bootloader (and by bootloader I mean one of few bootloaders this is
>> going to be used on like U-Boot)
> 
> The default is to use the GPIO of the SoC pinctrl. The HDP is not routed 
> outside.
>   >>
>>> The userland cannot change the pinctrl alternate function mux, this is
>>> statically defined by the devicetree.
>>
>> If you expose GPIO then userland needs this regardless of alternate mux.
>> IOW, board level could not configure mux because it should be always
>> configured to safe GPIO input.
> 
> For userland sight view, SoC GPIO are preferred instead of HDP.
> HDP is only GPO not GPIO. 'pinctrl-*' properties configure at the same 
> time the SoC pinctrl mux to HDP and the HDP pinctrl mux to one of the 
> HDP functions (e.g. GPO).
Thanks, that's explains, fine to keep it disabled. Unless it is obvious
for everyone, it would be nice to put it in commit msg.

Best regards,
Krzysztof

Re: [PATCH v3 5/9] ARM: dts: stm32: add Hardware debug port (HDP) on stm32mp13

[Clement LE GOFFIC]

On 6/12/25 15:09, Krzysztof Kozlowski wrote:
> On 12/06/2025 15:02, Clement LE GOFFIC wrote:
>> On 6/12/25 13:05, Krzysztof Kozlowski wrote:
>>> On 12/06/2025 11:31, Clement LE GOFFIC wrote:
>>>> On 6/11/25 17:48, Krzysztof Kozlowski wrote:
>>>>> On 11/06/2025 16:08, Clement LE GOFFIC wrote:
>>>>>> On 6/11/25 08:35, Krzysztof Kozlowski wrote:
>>>>>>> On 10/06/2025 15:33, Clement LE GOFFIC wrote:
>>>>>>>> On 6/10/25 14:38, Krzysztof Kozlowski wrote:
>>>>>>>>> On 10/06/2025 14:02, Clement LE GOFFIC wrote:
>>>>>>>>>> On 5/29/25 11:01, Krzysztof Kozlowski wrote:
>>>>>>>>>>> On 28/05/2025 14:14, Clement LE GOFFIC wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> +		};
>>>>>>>>>>>>>> +
>>>>>>>>>>>>>> +		hdp: pinctrl@5002a000 {
>>>>>>>>>>>>>> +			compatible = "st,stm32mp131-hdp";
>>>>>>>>>>>>>> +			reg = <0x5002a000 0x400>;
>>>>>>>>>>>>>> +			clocks = <&rcc HDP>;
>>>>>>>>>>>>>>         			status = "disabled";
>>>>>>>>>>>>>
>>>>>>>>>>>>> Why are you disabling it? What is missing?
>>>>>>>>>>>>
>>>>>>>>>>>> Nothing is missing just disabled by default.
>>>>>>>>>>>> The node is then enabled when needed in board's dts file.
>>>>>>>>>>> Nodes should not be disabled by default if they are complete. That's why
>>>>>>>>>>> I asked what is missing. Drop.
>>>>>>>>>>
>>>>>>>>>> Hi Krzysztof, OK I better understand now.
>>>>>>>>>> So yes the 'pinctrl-*' properties which are board dependent are lacking.
>>>>>>>>>
>>>>>>>>> These are not properties of this node.
>>>>>>>>
>>>>>>>> Does this mean I should add 'pinctrl-*' properties in bindings yaml file ?
>>>>>>>> I don't get it..
>>>>>>>
>>>>>>> These properties have no meaning here, so the hardware description is
>>>>>>> complete. You claim that you miss them thus device is incomplete is just
>>>>>>> not correct: these properties do not belong here! They belong to the
>>>>>>> board but even there they are totally optional. Why would they be a
>>>>>>> required resource?
>>>>>>>
>>>>>>> To remind: we talk here ONLY about required resources.
>>>>>>
>>>>>> Yes, 'pinctrl-*' properties belongs to the board and are not required.
>>>>>> So nothing is missing.
>>>>>>
>>>>>> This hdp node in the SoC dtsi file can be enabled by default.
>>>>>> But the hdp driver will probe and do nothing because without the
>>>>>> 'pinctrl-*' properties from the board files it would not be able to
>>>>>> access to any pin.
>>>>>
>>>>>
>>>>> Pinctrl has other features in general, including interfaces to userspace
>>>>> (as pretty often combined with gpio, although not sure if relevant here).
>>>>
>>>> You're right. Also HDP pinctrl has a GPO feature accessible from userspace.
>>>> But by default the HDP is not connected to any pad; it needs the board
>>>
>>> OK, then that was the answer to my first question - what is missing.
>>> However aren't these pads connected internally also to other parts of
>>> the SoC (like in most other vendors)?
>>
>> No, HDP "output pads" are only connected to SoC pinctrl to route outside
>> the internal SoC signals for debug purpose.
>>
>>>> 'pinctrl-*' properties to configure the SoC pinctrl and expose HDP on
>>>> the SoC pads.
>>>>
>>>> That's why for me the enabling of the driver should be in the board file
>>>> together with the SoC pinctrl configuration.
>>>
>>> And what are the default pad settings configured by HPD driver in
>>> bootloader (and by bootloader I mean one of few bootloaders this is
>>> going to be used on like U-Boot)
>>
>> The default is to use the GPIO of the SoC pinctrl. The HDP is not routed
>> outside.
>>    >>
>>>> The userland cannot change the pinctrl alternate function mux, this is
>>>> statically defined by the devicetree.
>>>
>>> If you expose GPIO then userland needs this regardless of alternate mux.
>>> IOW, board level could not configure mux because it should be always
>>> configured to safe GPIO input.
>>
>> For userland sight view, SoC GPIO are preferred instead of HDP.
>> HDP is only GPO not GPIO. 'pinctrl-*' properties configure at the same
>> time the SoC pinctrl mux to HDP and the HDP pinctrl mux to one of the
>> HDP functions (e.g. GPO).
> Thanks, that's explains, fine to keep it disabled. Unless it is obvious
> for everyone, it would be nice to put it in commit msg.

You're welcome, so I'll provide the V6 with more information in the 
commit message of patch [5-7] among other needed fixes.

> 
> Best regards,
> Krzysztof

Re: [Linux-stm32] [PATCH v3 5/9] ARM: dts: stm32: add Hardware debug port (HDP) on stm32mp13

[Clement LE GOFFIC]

On 6/12/25 15:21, Clement LE GOFFIC wrote:
> On 6/12/25 15:09, Krzysztof Kozlowski wrote:
>> On 12/06/2025 15:02, Clement LE GOFFIC wrote:
>>> On 6/12/25 13:05, Krzysztof Kozlowski wrote:
>>>> On 12/06/2025 11:31, Clement LE GOFFIC wrote:
>>>>> On 6/11/25 17:48, Krzysztof Kozlowski wrote:
>>>>>> On 11/06/2025 16:08, Clement LE GOFFIC wrote:
>>>>>>> On 6/11/25 08:35, Krzysztof Kozlowski wrote:
>>>>>>>> On 10/06/2025 15:33, Clement LE GOFFIC wrote:
>>>>>>>>> On 6/10/25 14:38, Krzysztof Kozlowski wrote:
>>>>>>>>>> On 10/06/2025 14:02, Clement LE GOFFIC wrote:
>>>>>>>>>>> On 5/29/25 11:01, Krzysztof Kozlowski wrote:
>>>>>>>>>>>> On 28/05/2025 14:14, Clement LE GOFFIC wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> +        };
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> +        hdp: pinctrl@5002a000 {
>>>>>>>>>>>>>>> +            compatible = "st,stm32mp131-hdp";
>>>>>>>>>>>>>>> +            reg = <0x5002a000 0x400>;
>>>>>>>>>>>>>>> +            clocks = <&rcc HDP>;
>>>>>>>>>>>>>>>                     status = "disabled";
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Why are you disabling it? What is missing?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Nothing is missing just disabled by default.
>>>>>>>>>>>>> The node is then enabled when needed in board's dts file.
>>>>>>>>>>>> Nodes should not be disabled by default if they are 
>>>>>>>>>>>> complete. That's why
>>>>>>>>>>>> I asked what is missing. Drop.
>>>>>>>>>>>
>>>>>>>>>>> Hi Krzysztof, OK I better understand now.
>>>>>>>>>>> So yes the 'pinctrl-*' properties which are board dependent 
>>>>>>>>>>> are lacking.
>>>>>>>>>>
>>>>>>>>>> These are not properties of this node.
>>>>>>>>>
>>>>>>>>> Does this mean I should add 'pinctrl-*' properties in bindings 
>>>>>>>>> yaml file ?
>>>>>>>>> I don't get it..
>>>>>>>>
>>>>>>>> These properties have no meaning here, so the hardware 
>>>>>>>> description is
>>>>>>>> complete. You claim that you miss them thus device is incomplete 
>>>>>>>> is just
>>>>>>>> not correct: these properties do not belong here! They belong to 
>>>>>>>> the
>>>>>>>> board but even there they are totally optional. Why would they be a
>>>>>>>> required resource?
>>>>>>>>
>>>>>>>> To remind: we talk here ONLY about required resources.
>>>>>>>
>>>>>>> Yes, 'pinctrl-*' properties belongs to the board and are not 
>>>>>>> required.
>>>>>>> So nothing is missing.
>>>>>>>
>>>>>>> This hdp node in the SoC dtsi file can be enabled by default.
>>>>>>> But the hdp driver will probe and do nothing because without the
>>>>>>> 'pinctrl-*' properties from the board files it would not be able to
>>>>>>> access to any pin.
>>>>>>
>>>>>>
>>>>>> Pinctrl has other features in general, including interfaces to 
>>>>>> userspace
>>>>>> (as pretty often combined with gpio, although not sure if relevant 
>>>>>> here).
>>>>>
>>>>> You're right. Also HDP pinctrl has a GPO feature accessible from 
>>>>> userspace.
>>>>> But by default the HDP is not connected to any pad; it needs the board
>>>>
>>>> OK, then that was the answer to my first question - what is missing.
>>>> However aren't these pads connected internally also to other parts of
>>>> the SoC (like in most other vendors)?
>>>
>>> No, HDP "output pads" are only connected to SoC pinctrl to route outside
>>> the internal SoC signals for debug purpose.
>>>
>>>>> 'pinctrl-*' properties to configure the SoC pinctrl and expose HDP on
>>>>> the SoC pads.
>>>>>
>>>>> That's why for me the enabling of the driver should be in the board 
>>>>> file
>>>>> together with the SoC pinctrl configuration.
>>>>
>>>> And what are the default pad settings configured by HPD driver in
>>>> bootloader (and by bootloader I mean one of few bootloaders this is
>>>> going to be used on like U-Boot)
>>>
>>> The default is to use the GPIO of the SoC pinctrl. The HDP is not routed
>>> outside.
>>>    >>
>>>>> The userland cannot change the pinctrl alternate function mux, this is
>>>>> statically defined by the devicetree.
>>>>
>>>> If you expose GPIO then userland needs this regardless of alternate 
>>>> mux.
>>>> IOW, board level could not configure mux because it should be always
>>>> configured to safe GPIO input.
>>>
>>> For userland sight view, SoC GPIO are preferred instead of HDP.
>>> HDP is only GPO not GPIO. 'pinctrl-*' properties configure at the same
>>> time the SoC pinctrl mux to HDP and the HDP pinctrl mux to one of the
>>> HDP functions (e.g. GPO).
>> Thanks, that's explains, fine to keep it disabled. Unless it is obvious
>> for everyone, it would be nice to put it in commit msg.
> 
> You're welcome, so I'll provide the V6 with more information in the
> commit message of patch [5-7] among other needed fixes.

V5*

>>
>> Best regards,
>> Krzysztof
> 
> _______________________________________________
> Linux-stm32 mailing list
> Linux-stm32@st-md-mailman.stormreply.com
> https://st-md-mailman.stormreply.com/mailman/listinfo/linux-stm32