Update compatability string for remoteproc by artursartamonovsadi · Pull Request #3575 · analogdevicesinc/linux

artursartamonovsadi · 2026-09-30T08:53:40Z

PR Description

This comes from WIP in #3499

As new platform support is added, SC8XX memory mapping's are incompatible with SC5XX, There is need to distinguish both of them.

The renaming follows stm32 remoteproc upstream
Compatibility string changed
adi,remoteproc
now is

adi,sc5xx-rproc for SHARC
adi,sc8xx-rproc for SHARC-FX(Xtensa)

This is first set of tiny PR's that shouldn't brake old code but introduce support for remoteproc on SC8XX

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

ukleinek · 2026-09-30T09:07:17Z

Fine for me, maybe consider keeping the old compatible as a fallback (i.e.

compatible = "adi,sc5xx-rproc", "adi,remoteproc";

but I don't feel strong about it and intend to change the binding in an incompatible way anyhow soon (which I think is needed for upstreaming), so there isn't much use on keeping compatibility anyhow.

ukleinek

Apart from a minor concern, I agree that's the right way forward.

artursartamonovsadi · 2026-09-30T10:00:42Z

Fine for me, maybe consider keeping the old compatible as a fallback (i.e.
compatible = "adi,sc5xx-rproc", "adi,remoteproc";
but I don't feel strong about it and intend to change the binding in an incompatible way anyhow soon (which I think is needed for upstreaming), so there isn't much use on keeping compatibility anyhow.

Have added, for now

artursartamonovsadi · 2026-09-30T11:12:33Z

@sipraga renamed to adi,adsp-sc598-rproc

nunojsa · 2026-09-30T11:38:16Z

but I don't feel strong about it and intend to change the binding in an incompatible way anyhow soon (which I think is needed for upstreaming), so there isn't much use on keeping compatibility anyhow.

Long term we also want to upstream all of this and I guess the legacy stuff won't be taken into account anyways :)

sipraga · 2026-10-08T15:03:04Z

 static const struct of_device_id adi_rproc_of_match[] = {
-	{ .compatible = "adi,remoteproc" },
+	{ .compatible = "adi,adsp-sc598-rproc" },
+	{ .compatible = "adi,adsp-sc846-rproc" },


did you not want to already wire in .data pointers?

He had but it but I asked to drop it. These pointers are useless if we're not going to do anything with them (which was the case). When we do need to do anything different per variant, then we can add them. But until them, just noise :)

Fair enough, but I guess by the same logic this should also be dropped:

enum adi_rproc_variant { SC5XX_RPROC_SHARC, SC5XX_RPROC_SHARCFX, }; struct adi_rproc_config { unsigned int variant; };

It looks like the sc846 remoteproc PR will add those: #3499. I feel like we should drop it here and then let that PR add them once they are actually being used.

I wanted to make it in small chunks rather as big PR. So all parts can be reviewed in fast manner.

That PR now have 2 platforms, will split it in 2, SC846 - ELF support, and SC598 ELF support PR's first one is SC846

sipraga · 2026-10-08T15:03:47Z

 	scb {
 		core1-rproc@3108C000 {
-			compatible = "adi,remoteproc";
+			compatible = "adi,adsp-sc598-rproc","adi,remoteproc";


commit subject should be ARM: not arm64:

sipraga · 2026-10-08T15:09:27Z


 		core2-rproc@3108C000 {
-			compatible = "adi,remoteproc";
+			compatible = "adi,adsp-sc598-rproc","adi,remoteproc";


Generic compatibles are frowned upon. There is some advice here:

https://docs.kernel.org/devicetree/bindings/writing-bindings.html

Relevant rules:

DO make ‘compatible’ properties specific.

DON’T use wildcards or device-family names in compatible strings.

DON’T add fake fallback compatibles when software cannot use such to match and bind to a device, and still operate correctly.

DO use a SoC-specific compatible for all SoC devices, followed by a fallback if appropriate. SoC-specific compatibles are also preferred for the fallbacks.

Ergo, I would make this:

"adi,adsp-sc573-rproc","adi,adsp-sc598-remoteproc"

if 598 is to be the fallback compatible.

Agree, "adi,remoteproc"; as a valid compatible is not the way to go

not sure why to add "adi,adsp-sc573-rproc" as there is no any difference in code for for whole set of SHARC+ part's
something like adi,adsp-sp-rproc" for all SHARC+ remoteproc drivers.

calebethridge · 2026-10-09T13:36:48Z

 	scb {
 		core1-rproc@3108C000 {
-			compatible = "adi,remoteproc";
+			compatible = "adi,adsp-sc598-rproc","adi,remoteproc";


We should add some DT bindings for these compatibles

there was no compatibles by default

as usually don't want to get out of scope in singe tiny PR, can always separate PR that add DT bindings

Replace the generic "adi,remoteproc" compatible with "adi,sc5xx-rproc" and "adi,sc8xx-rproc", each carrying an adi_rproc_config that tags the SHARC variant (SHARC+ vs SHARCFX) so later patches can branch on the core type. Rename the platform driver to "adi-rproc" to match. Signed-off-by: Arturs Artamonovs <Arturs.Artamonovs@analog.com>

calebethridge · 2026-10-12T16:02:50Z

 	scb {
 		core1-rproc@3108C000 {
-			compatible = "adi,remoteproc";
+			compatible = "adi,adsp-sc598-rproc";


Should we add a compatible string for the non-sc598 boards, e.g adi,adsp-sc573-rproc? This could be confusing to someone who doesn't know that the underlying architecture is the same. Otherwise LGTM

nunojsa

At some point we also need to start renaming the filenames

nunojsa · 2026-10-13T09:52:31Z


 		core2-rproc@3108C000 {
-			compatible = "adi,remoteproc";
+			compatible = "adi,adsp-sc598-rproc";


Yeah... looks a bit weird to me. I guess we could very well already add adi,adsp-sc573-rproc. I guess the plan is still to upstream first 598 so we could make that as the fallback one

nunojsa · 2026-10-13T09:52:52Z

 &scb {
 	sharc0: core1-rproc@28240000 {
-		compatible = "adi,remoteproc";
+		compatible = "adi,adsp-sc846-rproc";


nunojsa · 2026-10-13T09:53:26Z


 		core2-rproc@28a40000 {
-			compatible = "adi,remoteproc";
+			compatible = "adi,adsp-sc598-rproc";


nunojsa · 2026-10-13T09:53:35Z


 		sharc1: core2-rproc@28a40000 {
-			compatible = "adi,remoteproc";
+			compatible = "adi,adsp-sc598-rproc";


nunojsa · 2026-10-13T09:56:35Z

Also, do not ignore comments without justifying :). @sipraga made the same points about compatibles and also git subject style :)

sipraga · 2026-10-13T11:14:05Z

looks fine now except I would still add the more SoC-specific compatibles, like compatible = "adi,adsp-sc573-rproc", "adi,adsp-sc598-rproc"; for SC573.

I know in theory there is no difference, but when it comes to mainlining the DTs it will be required to do this. Rationale is that one day you might find that there is a subtle difference and you need to update the driver to account for it (do X if SC573, do Y if SC598). But because the driver has to work with "old" device trees (since DTs are kind of ABI), you want to future proof things by having that more SoC-specific compatible in place from the very beginning.

The fallback compatible you choose (here sc598) is usually arbitrary. In fact I think the driver itself need only list that particular compatible in its OF match table if there is no actual difference in behaviour. The dtbs_check makefile target will however require that all compatibles are listed in the yaml bindings.

So in the bindings you do like:

compatible:
  oneOf:
    - items:
        - enum:
            - adi,adsp-sc573-rproc
            - adi,adsp-sc589-rproc
            - ...
        - const: adi,adsp-sc598-rproc
    - const: adi,adsp-sc598-rproc
    - const: adi,adsp-sc846-rproc

I put 846 separately because it's not actually compatible with 598.

sipraga · 2026-10-13T11:22:49Z

Since there isn't any bindings yaml file right now I think you can skip that part in this PR though, no harm done

Signed-off-by: Arturs Artamonovs <Arturs.Artamonovs@analog.com>

sipraga

LGTM now!

also, I just noticed that the remoteproc nodes are in the som/board-level DTs rather than the SoC-level DT. seems a bit odd. probably needs to be moved at some point (but that's really for another day, out of scope here)

artursartamonovsadi requested review from a team, nunojsa, pamolloy, sipraga and ukleinek and removed request for nunojsa and sipraga September 30, 2026 09:00

ukleinek approved these changes Sep 30, 2026

View reviewed changes

Comment thread drivers/remoteproc/adi_remoteproc.c Outdated

artursartamonovsadi force-pushed the arturs/adsp/rproc-compatability branch 3 times, most recently from ecb53b4 to 3ab66e0 Compare September 30, 2026 09:59

artursartamonovsadi force-pushed the arturs/adsp/rproc-compatability branch from 3ab66e0 to 5410ad5 Compare September 30, 2026 11:09

artursartamonovsadi requested a review from ukleinek September 30, 2026 11:12

nunojsa reviewed Sep 30, 2026

View reviewed changes

Comment thread drivers/remoteproc/adi_remoteproc.c Outdated

artursartamonovsadi force-pushed the arturs/adsp/rproc-compatability branch from 5410ad5 to f439089 Compare October 8, 2026 13:31

artursartamonovsadi requested a review from nunojsa October 8, 2026 13:40

sipraga reviewed Oct 8, 2026

View reviewed changes

calebethridge reviewed Oct 9, 2026

View reviewed changes

artursartamonovsadi force-pushed the arturs/adsp/rproc-compatability branch from d7b236b to c2fb2a6 Compare October 9, 2026 13:44

artursartamonovsadi requested review from calebethridge and sipraga October 9, 2026 14:05

artursartamonovsadi force-pushed the arturs/adsp/rproc-compatability branch from c2fb2a6 to cfdc2b2 Compare October 9, 2026 14:51

calebethridge approved these changes Oct 12, 2026

View reviewed changes

nunojsa reviewed Oct 13, 2026

View reviewed changes

artursartamonovsadi added 5 commits October 13, 2026 14:30

arm: dts: sc573-ezlite: update SHARC remoteproc compatible string

2004ae0

Signed-off-by: Arturs Artamonovs <Arturs.Artamonovs@analog.com>

arm: dts: sc589-mini: update SHARC remoteproc compatible string

e6adb41

Signed-off-by: Arturs Artamonovs <Arturs.Artamonovs@analog.com>

arm: dts: sc594-som: update SHARC remoteproc compatible string

f58419c

Signed-off-by: Arturs Artamonovs <Arturs.Artamonovs@analog.com>

arm64: dts: sc598-som: update SHARC remoteproc compatible string

c9e8b32

Signed-off-by: Arturs Artamonovs <Arturs.Artamonovs@analog.com>

arm64: dts: sc846-som: update SHARC-FX remoteproc compatible string

0a9eb3d

Signed-off-by: Arturs Artamonovs <Arturs.Artamonovs@analog.com>

artursartamonovsadi force-pushed the arturs/adsp/rproc-compatability branch from 2edfc9c to 0a9eb3d Compare October 13, 2026 13:31

sipraga approved these changes Oct 13, 2026

View reviewed changes

artursartamonovsadi merged commit c969610 into adsp-6.18.31-y Oct 13, 2026
17 of 19 checks passed

artursartamonovsadi deleted the arturs/adsp/rproc-compatability branch October 13, 2026 14:53

Conversation

artursartamonovsadi commented Sep 30, 2026

PR Description

PR Type

PR Checklist

Uh oh!

ukleinek commented Sep 30, 2026

Uh oh!

ukleinek left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

artursartamonovsadi commented Sep 30, 2026

Uh oh!

artursartamonovsadi commented Sep 30, 2026

Uh oh!

nunojsa commented Sep 30, 2026

Uh oh!

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!

Uh oh!

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 left a comment

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 Oct 13, 2026

Uh oh!

sipraga commented Oct 13, 2026

Uh oh!

sipraga commented Oct 13, 2026

Uh oh!

sipraga left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants