reset: sc5xx: Add ADI SC5XX reset controller driver #3079

artursartamonovsadi · 2026-01-14T16:57:19Z

PR Description

ADI ADSP-SC5xx reset driver, goal of PR to do first round of improvements on reset driver to align with general
kernel style. And align driver with upstreaming efforts.

renamed rcu.c to match upstream patch reset-sc5xx.c and moved under drivers/reset
removed properties adi,sharc-min and adi,sharc-max, and replaced with adi,sharc-core-ids

PR Type

Bug fix (a change that fixes an issue)
New feature (a change that adds new functionality)
Breaking change (a change that affects other repos or cause CIs to fail)

PR Checklist

I have conducted a self-review of my own code changes
I have compiled my changes, including the documentation
I have tested the changes on the relevant hardware
I have updated the documentation outside this repo accordingly
I have provided links for the relevant upstream lore

UtsavAgarwalADI · 2026-01-23T13:15:11Z

It says there are conflicts with sc573's defconfig - does this need rebasing?

UtsavAgarwalADI · 2026-01-23T13:19:28Z

drivers/reset/reset-sc5xx.c


 #define ADI_RCU_REBOOT_PRIORITY		255
 #define ADI_RCU_CORE_INIT_TIMEOUT	msecs_to_jiffies(2000)
+#define ADI_RCU_CORE_NUM		4


Why is this 4? Isn't the max sharc core count 2?

Also, do we want to hardcode this value? We might want to change things in the future if needed.

Idea, was to have ARRAY of Cores, and mark Cores as being SHARC, as core assignment at currently are
Core0 ARM and usually Core1,Core2 are SHARC's
What if there if assignment of cores are like Core0,Core1,Core2,Core3 and Core0 and Core 3 are ARM's and Core1 and Core2 are SHARC's.

Why is this 4? Isn't the max sharc core count 2?
Yes, and this is how many RCU's are there not how many SHARC Cores

UtsavAgarwalADI · 2026-01-23T13:25:53Z

drivers/reset/Kconfig


+config RESET_SC5XX
+	bool "ADI SC5XX Reset Driver"
+	depends on ARCH_SC59X_64 || ARCH_SC59X || ARCH_SC58X || ARCH_SC57X


Maybe we can use ARCH_SC59X_64 || ARCH_SC5XX ?

linux/arch/arm/mach-sc5xx/Kconfig

Line 2 in 9305cac

menuconfig ARCH_SC5XX

Move the ADI ADSP-SC5XX reset controller from drivers/soc/adi/mach-sc5xx/ to drivers/reset/ to integrate with the standard reset controller subsystem. Signed-off-by: Arturs Artamonovs <Arturs.Artamonovs@analog.com>

ozan956 · 2026-01-23T14:57:45Z

arch/arm/configs/sc573-ezlite_defconfig

 # CONFIG_FTRACE is not set
 CONFIG_ARM_PTDUMP_DEBUGFS=y
 CONFIG_EARLY_PRINTK=y
+CONFIG_RESET_SC5XX=y


missing newline at the end of the file, its also the case for other defconfigs.

ozan956 · 2026-01-23T15:05:15Z

drivers/reset/reset-sc5xx.c

Why we are not using the generic reset controller framework of the kernel?
https://docs.kernel.org/driver-api/reset.html

This PR is to gradually improve the state of driver, also lets wait for comments from upstream.

ozan956 · 2026-01-23T15:08:29Z

drivers/reset/reset-sc5xx.c

+		return -EINVAL;
+
+	for (i = 0; i < count; i++)
+		adi_rcu->sharc_core_ids[i] = 1;


So as I understand correctly, we first read this array from device tree above (line 275), then we overwrite every entry 1 with this loop. Why is that so?

I believe the goal is that the core IDs of the sharc core are read from the device tree, and then become the indexes that gets set to 1 in sharc_core_ids[] so the driver know which ones are the sharc cores, as we can set in check_coreid_valid above.

So there are a couple of issues here. If the device tree has 1, 2 for the core ids , this code will set indexes 0 and 1 in sharc_core_ids, instead of the expected 1 and 2. We should read the values from the device tree and use them as the indexes into the sharc_core_ids array instead of using the count which will always update the array starting from 0.

I would recommend reading this into another array first and sanity checking the values, and then updating the sharc_core_ids array.

yea idea is to mark from list of cores mark each SHARC cores, as enumeration of SHARC cores isn't determinate between different ADSP-SC5xx SoC, also easy to detect when calling https://github.com/analogdevicesinc/linux/blob/adsp-main-6.12-rcu-review/drivers/reset/reset-sc5xx.c#L103

CalebEthridgeADI · 2026-01-23T15:46:09Z

drivers/reset/reset-sc5xx.c

+		return -EINVAL;
+
+	for (i = 0; i < count; i++)
+		adi_rcu->sharc_core_ids[i] = 1;


I believe the goal is that the core IDs of the sharc core are read from the device tree, and then become the indexes that gets set to 1 in sharc_core_ids[] so the driver know which ones are the sharc cores, as we can set in check_coreid_valid above.

So there are a couple of issues here. If the device tree has 1, 2 for the core ids , this code will set indexes 0 and 1 in sharc_core_ids, instead of the expected 1 and 2. We should read the values from the device tree and use them as the indexes into the sharc_core_ids array instead of using the count which will always update the array starting from 0.

I would recommend reading this into another array first and sanity checking the values, and then updating the sharc_core_ids array.

CalebEthridgeADI · 2026-01-23T15:54:26Z

drivers/reset/reset-sc5xx.c

+		return -EINVAL;
+	}
+	memset32(adi_rcu->sharc_core_ids, 0, count);
+	ret = of_property_read_u32_array(np, "adi,sharc-core-ids", adi_rcu->sharc_core_ids, ADI_RCU_CORE_NUM);


I see we check above if the number of elements in the sharc-core-ids is greater than the number of cores, but should we also add a check here to make sure the actual elements aren't out of bounds, for example accidentally putting 1,5 as the core ids?

nunojsa · 2026-01-27T08:58:35Z

@artursartamonovsadi , fixup commits are really not helpful for reviewers. If you're working on something mark this as a draft and then mark it ready for review (without fixups) when ready

pamolloy added this to ADSP Jan 15, 2026

artursartamonovsadi force-pushed the adsp-main-6.12-rcu-review branch 2 times, most recently from 97cf234 to 7dfeabf Compare January 20, 2026 12:03

artursartamonovsadi requested review from a team, CalebEthridgeADI, UtsavAgarwalADI, jiez, nunojsa, ozan956, pamolloy and qasim-ijaz January 20, 2026 12:11

artursartamonovsadi force-pushed the adsp-main-6.12-rcu-review branch from 3e0a768 to 9305cac Compare January 23, 2026 12:47

UtsavAgarwalADI reviewed Jan 23, 2026

View reviewed changes

reset: sc5xx: Add ADI SC5XX reset controller driver

52368fe

Move the ADI ADSP-SC5XX reset controller from drivers/soc/adi/mach-sc5xx/ to drivers/reset/ to integrate with the standard reset controller subsystem. Signed-off-by: Arturs Artamonovs <Arturs.Artamonovs@analog.com>

artursartamonovsadi force-pushed the adsp-main-6.12-rcu-review branch from 9305cac to 52368fe Compare January 23, 2026 14:42

ozan956 reviewed Jan 23, 2026

View reviewed changes

CalebEthridgeADI reviewed Jan 23, 2026

View reviewed changes

fixup! reset: sc5xx: Add ADI SC5XX reset controller driver

b3b89ab

artursartamonovsadi marked this pull request as draft January 27, 2026 14:01

pamolloy assigned artursartamonovsadi Jan 30, 2026

fixup! reset: sc5xx: Add ADI SC5XX reset controller driver

77f4d74

reset: sc5xx: Add ADI SC5XX reset controller driver #3079

Are you sure you want to change the base?

reset: sc5xx: Add ADI SC5XX reset controller driver #3079

Uh oh!

Conversation

artursartamonovsadi commented Jan 14, 2026 • edited by qasim-ijaz Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Description

PR Type

PR Checklist

Uh oh!

UtsavAgarwalADI commented Jan 23, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nunojsa commented Jan 27, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

artursartamonovsadi commented Jan 14, 2026 •

edited by qasim-ijaz

Loading