[PATCH v4] reset: spacemit: k3: Decouple composite reset lines

[Philipp Zabel]

On Fr, 2026-03-20 at 06:51 +0000, Yixun Lan wrote:
> Instead of grouping several different reset lines into one composite
> reset, decouple them to individual ones which make it more aligned
> with underlying hardware. And for DWC USB driver, it will match well
> with the number of the reset property in the DT bindings.
> 
> The DWC3 USB host controller in K3 SoC has three reset lines - AHB, VCC,
> PHY. The PCIe controller also has three reset lines - DBI, Slave, Master.
> Also three reset lines each for UCIE and RCPU block.
> 
> As an agreement with maintainer, the reset IDs has been rearranged as
> contiguous number but keep EMAC part unchanged to avoid break patches
> which already sent to mailing list. The changes of DT binding header file
> and reset driver are merged together as one single commit to avoid
> git-bisect breakage.
> 
> Fixes: 938ce3b16582 ("reset: spacemit: Add SpacemiT K3 reset driver")
> Fixes: 216e0a5e98e5 ("dt-bindings: soc: spacemit: Add K3 reset support and IDs")
> Signed-off-by: Yixun Lan <dlan at kernel.org>
> ---
> Previously, the reset of The USB and PCIe was submited as a composite
> reset, try to decouple them in this series.
> 
> The motivation behind is that it will will make the result more aligned
> with the hardware which describe them as different reset lines, and also
> match with the K3 dwc3 DT binding which request different reset, 
> K1 and K3 SoC share same topology of the reset line design.
> 
> See the reset part info in binding doc
> Documentation/devicetree/bindings/usb/spacemit,k1-dwc3.yaml
> 
> In V2, I've visited through whole reset driver and decouple more resets,
> which include the block - UCIE and RPCU. Also add an explanation of why
> rearrange the reset IDs as contiguous number.
> 
> In V4, I've rearranged all reset IDs to keep them linear(no hole), while
> keep EMAC part IDs unchanged, this still bring lots changes to ID number,
> let me know if it's ok.

It would be safer to just keep all reset IDs that don't have to be
split unchanged. Patches using them are trickling in.

The search for changed IDs [1] now yields a user of RESET_APMU_DMA [2].

[1] https://lore.kernel.org/all/?q=dfb:RESET_APMU_USB2%20OR%20dfb:RESET_APMU_USB3_PORTA%20OR%20dfb:RESET_APMU_USB3_PORTB%20OR%20dfb:RESET_APMU_USB3_PORTC%20OR%20dfb:RESET_APMU_USB3_PORTD%20OR%20dfb:RESET_APMU_QSPI%20OR%20dfb:RESET_APMU_QSPI_BUS%20OR%20dfb:RESET_APMU_DMA%20OR%20dfb:RESET_APMU_AES_WTM%20OR%20dfb:RESET_APMU_MCB_DCLK%20OR%20dfb:RESET_APMU_MCB_ACLK%20OR%20dfb:RESET_APMU_VPU%20OR%20dfb:RESET_APMU_DTC%20OR%20dfb:RESET_APMU_GPU%20OR%20dfb:RESET_APMU_ALZO%20OR%20dfb:RESET_APMU_MC%20OR%20dfb:RESET_APMU_CPU0_POP%20OR%20dfb:RESET_APMU_CPU0_SW%20OR%20dfb:RESET_APMU_CPU1_POP%20OR%20dfb:RESET_APMU_CPU1_SW%20OR%20dfb:RESET_APMU_CPU2_POP%20OR%20dfb:RESET_APMU_CPU2_SW%20OR%20dfb:RESET_APMU_CPU3_POP%20OR%20dfb:RESET_APMU_CPU3_SW%20OR%20dfb:RESET_APMU_C0_MPSUB_SW%20OR%20dfb:RESET_APMU_CPU4_POP%20OR%20dfb:RESET_APMU_CPU4_SW%20OR%20dfb:RESET_APMU_CPU5_POP%20OR%20dfb:RESET_APMU_CPU5_SW%20OR%20dfb:RESET_APMU_CPU6_POP%20OR%20dfb:RESET_APMU_CPU6_SW%20OR%20dfb:RESET_APMU_CPU7_POP%20OR%20dfb:RESET_APMU_CPU7_SW%20OR%20dfb:RESET_APMU_C1_MPSUB_SW%20OR%20dfb:RESET_APMU_MPSUB_DBG%20OR%20dfb:RESET_APMU_UCIE%20OR%20dfb:RESET_APMU_RCPU%20OR%20dfb:RESET_APMU_DSI4LN2_ESCCLK%20OR%20dfb:RESET_APMU_DSI4LN2_LCD_SW%20OR%20dfb:RESET_APMU_DSI4LN2_LCD_MCLK%20OR%20dfb:RESET_APMU_DSI4LN2_LCD_DSCCLK%20OR%20dfb:RESET_APMU_DSI4LN2_DPU_ACLK%20OR%20dfb:RESET_APMU_DPU_ACLK%20OR%20dfb:RESET_APMU_UFS_ACLK%20OR%20dfb:RESET_APMU_EDP0%20OR%20dfb:RESET_APMU_EDP1%20OR%20dfb:RESET_APMU_PCIE_PORTA%20OR%20dfb:RESET_APMU_PCIE_PORTB%20OR%20dfb:RESET_APMU_PCIE_PORTC%20OR%20dfb:RESET_APMU_PCIE_PORTD%20OR%20dfb:RESET_APMU_PCIE_PORTE
[2] https://lore.kernel.org/all/20260317-k3-pdma-v1-1-f39d3e97b53a@linux.spacemit.com/

Which means

#define RESET_APMU_DMA           23

should stay unchanged as well.

regards
Philipp