Skip to contentSkip to conversation

mailbox, remoteproc: k3-m4+: fix compile testing

PATCH In review Arnd Bergmann 5 participants 12 messages Oct 7, 2024 – Oct 16, 2024 Remote processor (remoteproc)

lore
Share & tools
lore

Arnd Bergmann

author
#0 lore raw

PATCH 1/1 mailbox, remoteproc: k3-m4+: fix compile testing

From: Arnd Bergmann <[email protected]>

The k3-m4 remoteproc driver was merged with incorrect dependencies. Despite multiple people trying to fix this, the version 6.12-rc2 remains broken and causes a build failure with CONFIG_TI_SCI_PROTOCOL=m when the driver is built-in.

arm-linux-gnueabi-ld: drivers/remoteproc/ti_k3_m4_remoteproc.o: in function `k3_m4_rproc_probe':
ti_k3_m4_remoteproc.c:(.text.k3_m4_rproc_probe+0x76): undefined reference to `devm_ti_sci_get_by_phandle'

Fix the dependency again to make it work in all configurations. The 'select OMAP2PLUS_MBOX' no longer matches what the other drivers dependencies. The link failure can be avoided with a simple 'depends do, so turn that into the same 'depends' to ensure we get no circular on TI_SCI_PROTOCOL', but the extra COMPILE_TEST alternative is what we use elsehwere. On the other hand, building for OMAP2PLUS makes no sense since the hardware only exists on K3.

Fixes ebcf9008a895 ("remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem")
Fixes ba0c0cb56f22 ("remoteproc: k3-m4: use the proper dependencies")
Fixes 54595f2807d2 ("mailbox, remoteproc: omap2+: fix compile testing")
Signed-off-by Arnd Bergmann <[email protected]>
---
 drivers/remoteproc/Kconfig | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/remoteproc/Kconfig +3 -3
index 955e4e38477e..62f8548fb46a 100644
@@ -341,9 +341,9 @@ config TI_K3_DSP_REMOTEPROC
 
 config TI_K3_M4_REMOTEPROC
 	tristate "TI K3 M4 remoteproc support"
-	depends on ARCH_OMAP2PLUS || ARCH_K3
-	select MAILBOX
-	select OMAP2PLUS_MBOX
+	depends on ARCH_K3 || COMPILE_TEST
+	depends on TI_SCI_PROTOCOL || (COMPILE_TEST && TI_SCI_PROTOCOL=n)
+	depends on OMAP2PLUS_MBOX
 	help
 	  Say m here to support TI's M4 remote processor subsystems
 	  on various TI K3 family of SoCs through the remote processor
Signature · 1 line
2.39.2
maintainer
#1 lore raw
Quoted 7 lines · Arnd Bergmann

From: Arnd Bergmann <[email protected]>

The k3-m4 remoteproc driver was merged with incorrect dependencies. Despite multiple people trying to fix this, the version 6.12-rc2 remains broken and causes a build failure with CONFIG_TI_SCI_PROTOCOL=m when the driver is built-in.

(Sigh)

I will do my own testing and will get back to you.

Quoted 39 lines

arm-linux-gnueabi-ld: drivers/remoteproc/ti_k3_m4_remoteproc.o: in function `k3_m4_rproc_probe':
ti_k3_m4_remoteproc.c:(.text.k3_m4_rproc_probe+0x76): undefined reference to `devm_ti_sci_get_by_phandle'

Fix the dependency again to make it work in all configurations. The 'select OMAP2PLUS_MBOX' no longer matches what the other drivers dependencies. The link failure can be avoided with a simple 'depends do, so turn that into the same 'depends' to ensure we get no circular on TI_SCI_PROTOCOL', but the extra COMPILE_TEST alternative is what we use elsehwere. On the other hand, building for OMAP2PLUS makes no sense since the hardware only exists on K3.

Fixes ebcf9008a895 ("remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem")
Fixes ba0c0cb56f22 ("remoteproc: k3-m4: use the proper dependencies")
Fixes 54595f2807d2 ("mailbox, remoteproc: omap2+: fix compile testing")
Signed-off-by Arnd Bergmann <[email protected]>
---
 drivers/remoteproc/Kconfig | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/remoteproc/Kconfig +3 -3
index 955e4e38477e..62f8548fb46a 100644
@@ -341,9 +341,9 @@ config TI_K3_DSP_REMOTEPROC
 
 config TI_K3_M4_REMOTEPROC
 	tristate "TI K3 M4 remoteproc support"
-	depends on ARCH_OMAP2PLUS || ARCH_K3
-	select MAILBOX
-	select OMAP2PLUS_MBOX
+	depends on ARCH_K3 || COMPILE_TEST
+	depends on TI_SCI_PROTOCOL || (COMPILE_TEST && TI_SCI_PROTOCOL=n)
+	depends on OMAP2PLUS_MBOX
 	help
 	  Say m here to support TI's M4 remote processor subsystems
 	  on various TI K3 family of SoCs through the remote processor
Signature · 1 line
2.39.2
maintainer
#2 lore raw
In reply to Arnd Bergmann

Hi Arnd,

Quoted 31 lines · Arnd Bergmann

From: Arnd Bergmann <[email protected]>

The k3-m4 remoteproc driver was merged with incorrect dependencies. Despite multiple people trying to fix this, the version 6.12-rc2 remains broken and causes a build failure with CONFIG_TI_SCI_PROTOCOL=m when the driver is built-in.

arm-linux-gnueabi-ld: drivers/remoteproc/ti_k3_m4_remoteproc.o: in function `k3_m4_rproc_probe':
ti_k3_m4_remoteproc.c:(.text.k3_m4_rproc_probe+0x76): undefined reference to `devm_ti_sci_get_by_phandle'

Fix the dependency again to make it work in all configurations. The 'select OMAP2PLUS_MBOX' no longer matches what the other drivers dependencies. The link failure can be avoided with a simple 'depends do, so turn that into the same 'depends' to ensure we get no circular on TI_SCI_PROTOCOL', but the extra COMPILE_TEST alternative is what we use elsehwere. On the other hand, building for OMAP2PLUS makes no sense since the hardware only exists on K3.

Fixes ebcf9008a895 ("remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem")
Fixes ba0c0cb56f22 ("remoteproc: k3-m4: use the proper dependencies")
Fixes 54595f2807d2 ("mailbox, remoteproc: omap2+: fix compile testing")
Signed-off-by Arnd Bergmann <[email protected]>
---
 drivers/remoteproc/Kconfig | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/remoteproc/Kconfig +0 -0
index 955e4e38477e..62f8548fb46a 100644

drivers/remoteproc/Kconfig config TI_K3_DSP_REMOTEPROC · line 346

Quoted 9 lines
drivers/remoteproc/Kconfig +3 -3
@@ -341,9 +341,9 @@ config TI_K3_DSP_REMOTEPROC
 
 config TI_K3_M4_REMOTEPROC
 	tristate "TI K3 M4 remoteproc support"
-	depends on ARCH_OMAP2PLUS || ARCH_K3
-	select MAILBOX
-	select OMAP2PLUS_MBOX
+	depends on ARCH_K3 || COMPILE_TEST
+	depends on TI_SCI_PROTOCOL || (COMPILE_TEST && TI_SCI_PROTOCOL=n)
+	depends on OMAP2PLUS_MBOX

I have tested this patch with CONFIG_TI_SCI_PROTOCOL=m on Arm and allmodconfig on x86-64 - both compilation work.

I can apply this patch as is or you can send me another one with the modifications you did for TI_K3_DSP_REMOTEPROC and TI_K3_R5_REMOTEPROC in your previous [1] attempt to fix this.

Thanks,
Mathieu

[1]. https://lore.kernel.org/all/[email protected]/

Quoted 6 lines
drivers/remoteproc/Kconfig +0 -0
 	help
 	  Say m here to support TI's M4 remote processor subsystems
 	  on various TI K3 family of SoCs through the remote processor
Signature · 1 line
2.39.2
#3 lore raw
In reply to Arnd Bergmann
Quoted 31 lines · Arnd Bergmann

From: Arnd Bergmann <[email protected]>

The k3-m4 remoteproc driver was merged with incorrect dependencies. Despite multiple people trying to fix this, the version 6.12-rc2 remains broken and causes a build failure with CONFIG_TI_SCI_PROTOCOL=m when the driver is built-in.

arm-linux-gnueabi-ld: drivers/remoteproc/ti_k3_m4_remoteproc.o: in function `k3_m4_rproc_probe':
ti_k3_m4_remoteproc.c:(.text.k3_m4_rproc_probe+0x76): undefined reference to `devm_ti_sci_get_by_phandle'

Fix the dependency again to make it work in all configurations. The 'select OMAP2PLUS_MBOX' no longer matches what the other drivers dependencies. The link failure can be avoided with a simple 'depends do, so turn that into the same 'depends' to ensure we get no circular on TI_SCI_PROTOCOL', but the extra COMPILE_TEST alternative is what we use elsehwere. On the other hand, building for OMAP2PLUS makes no sense since the hardware only exists on K3.

Fixes ebcf9008a895 ("remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem")
Fixes ba0c0cb56f22 ("remoteproc: k3-m4: use the proper dependencies")
Fixes 54595f2807d2 ("mailbox, remoteproc: omap2+: fix compile testing")
Signed-off-by Arnd Bergmann <[email protected]>
---
  drivers/remoteproc/Kconfig | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)
drivers/remoteproc/Kconfig +0 -0
index 955e4e38477e..62f8548fb46a 100644

drivers/remoteproc/Kconfig config TI_K3_DSP_REMOTEPROC · line 345

Quoted 8 lines
drivers/remoteproc/Kconfig +2 -3
@@ -341,9 +341,9 @@ config TI_K3_DSP_REMOTEPROC
 
  config TI_K3_M4_REMOTEPROC
  	tristate "TI K3 M4 remoteproc support"
-	depends on ARCH_OMAP2PLUS || ARCH_K3
-	select MAILBOX
-	select OMAP2PLUS_MBOX
+	depends on ARCH_K3 || COMPILE_TEST
+	depends on TI_SCI_PROTOCOL || (COMPILE_TEST && TI_SCI_PROTOCOL=n)

This line is odd. IMHO "COMPILE_TEST" should only be added to ARCH_* dependencies, as often only one ARCH can be selected which prevents compile testing drivers with various multiple architecture deps in one compile test.

Normal dependencies, on the other hand, can simply be enabled if one wants to compile test its dependent drivers. In this case, TI_SCI_PROTOCOL cannot be enabled as it has a dependency up the chain that doesn't allow selecting when not on a TI platform. We can fix that as I posted here[0]. With that fix in, this line can be simply become:

depends on TI_SCI_PROTOCOL

Andrew

[0] https://lore.kernel.org/lkml/[email protected]/

Quoted 4 lines
drivers/remoteproc/Kconfig +1 -0
+	depends on OMAP2PLUS_MBOX
  	help
  	  Say m here to support TI's M4 remote processor subsystems
  	  on various TI K3 family of SoCs through the remote processor
#4 lore raw
Quoted 13 lines · Andrew Davis

drivers/remoteproc/Kconfig config TI_K3_DSP_REMOTEPROC · line 345

Quoted 7 lines · Arnd Bergmann

config TI_K3_M4_REMOTEPROC
tristate "TI K3 M4 remoteproc support"

drivers/remoteproc/Kconfig +2 -3
-	depends on ARCH_OMAP2PLUS || ARCH_K3
-	select MAILBOX
-	select OMAP2PLUS_MBOX
+	depends on ARCH_K3 || COMPILE_TEST
+	depends on TI_SCI_PROTOCOL || (COMPILE_TEST && TI_SCI_PROTOCOL=n)

This line is odd. IMHO "COMPILE_TEST" should only be added to ARCH_* dependencies, as often only one ARCH can be selected which prevents compile testing drivers with various multiple architecture deps in one compile test.

I generally agree, but the TI_SCI_PROTOCOL interface definitions that were added in aa276781a64a ("firmware: Add basic support for TI System Control Interface (TI-SCI) protocol") appear to explicitly support the case of compile-testing.

See also 13678f3feb30 ("reset: ti-sci: honor TI_SCI_PROTOCOL setting when not COMPILE_TEST").

Quoted 7 lines

Normal dependencies, on the other hand, can simply be enabled if one wants to compile test its dependent drivers. In this case, TI_SCI_PROTOCOL cannot be enabled as it has a dependency up the chain that doesn't allow selecting when not on a TI platform. We can fix that as I posted here[0]. With that fix in, this line can be simply become:

depends on TI_SCI_PROTOCOL

That's certainly fine with me, but if we do this, I would suggest also removing the stub functions from include/linux/soc/ti/ti_sci_protocol.h, and the dependency in the reset driver.

Adding Nishanth Menon to Cc, to see if he has a preference.

Arnd

#5 lore raw
Quoted 31 lines · Arnd Bergmann
Quoted 13 lines · Andrew Davis

drivers/remoteproc/Kconfig config TI_K3_DSP_REMOTEPROC · line 345

Quoted 7 lines · Arnd Bergmann

config TI_K3_M4_REMOTEPROC
tristate "TI K3 M4 remoteproc support"

drivers/remoteproc/Kconfig +2 -3
-	depends on ARCH_OMAP2PLUS || ARCH_K3
-	select MAILBOX
-	select OMAP2PLUS_MBOX
+	depends on ARCH_K3 || COMPILE_TEST
+	depends on TI_SCI_PROTOCOL || (COMPILE_TEST && TI_SCI_PROTOCOL=n)

This line is odd. IMHO "COMPILE_TEST" should only be added to ARCH_* dependencies, as often only one ARCH can be selected which prevents compile testing drivers with various multiple architecture deps in one compile test.

I generally agree, but the TI_SCI_PROTOCOL interface definitions that were added in aa276781a64a ("firmware: Add basic support for TI System Control Interface (TI-SCI) protocol") appear to explicitly support the case of compile-testing.

See also 13678f3feb30 ("reset: ti-sci: honor TI_SCI_PROTOCOL setting when not COMPILE_TEST").

Quoted 7 lines

Normal dependencies, on the other hand, can simply be enabled if one wants to compile test its dependent drivers. In this case, TI_SCI_PROTOCOL cannot be enabled as it has a dependency up the chain that doesn't allow selecting when not on a TI platform. We can fix that as I posted here[0]. With that fix in, this line can be simply become:

depends on TI_SCI_PROTOCOL

Quoted 8 lines

That's certainly fine with me, but if we do this, I would suggest also removing the stub functions from include/linux/soc/ti/ti_sci_protocol.h, and the dependency in the reset driver.

Adding Nishanth Menon to Cc, to see if he has a preference.

Arnd

While I am OK to do the cleanups and make the drivers independent, I am also looking to make TISCI stuff independent and be a module itself. So, dropping the stubs will probably get in the way as we move ahead with those plans.

Signature · 3 lines
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D
#6 lore raw
Quoted 37 lines · Nishanth Menon
Quoted 36 lines · Arnd Bergmann
Quoted 13 lines · Andrew Davis

drivers/remoteproc/Kconfig config TI_K3_DSP_REMOTEPROC · line 345

Quoted 7 lines · Arnd Bergmann

config TI_K3_M4_REMOTEPROC
tristate "TI K3 M4 remoteproc support"

drivers/remoteproc/Kconfig +2 -3
-	depends on ARCH_OMAP2PLUS || ARCH_K3
-	select MAILBOX
-	select OMAP2PLUS_MBOX
+	depends on ARCH_K3 || COMPILE_TEST
+	depends on TI_SCI_PROTOCOL || (COMPILE_TEST && TI_SCI_PROTOCOL=n)

This line is odd. IMHO "COMPILE_TEST" should only be added to ARCH_* dependencies, as often only one ARCH can be selected which prevents compile testing drivers with various multiple architecture deps in one compile test.

I generally agree, but the TI_SCI_PROTOCOL interface definitions that were added in aa276781a64a ("firmware: Add basic support for TI System Control Interface (TI-SCI) protocol") appear to explicitly support the case of compile-testing.

See also 13678f3feb30 ("reset: ti-sci: honor TI_SCI_PROTOCOL setting when not COMPILE_TEST").

Quoted 7 lines

Normal dependencies, on the other hand, can simply be enabled if one wants to compile test its dependent drivers. In this case, TI_SCI_PROTOCOL cannot be enabled as it has a dependency up the chain that doesn't allow selecting when not on a TI platform. We can fix that as I posted here[0]. With that fix in, this line can be simply become:

depends on TI_SCI_PROTOCOL

That's certainly fine with me, but if we do this, I would suggest also removing the stub functions from include/linux/soc/ti/ti_sci_protocol.h, and the dependency in the reset driver.

Quoted 9 lines
Quoted 3 lines

Adding Nishanth Menon to Cc, to see if he has a preference.

Arnd

While I am OK to do the cleanups and make the drivers independent, I am also looking to make TISCI stuff independent and be a module itself. So, dropping the stubs will probably get in the way as we move ahead with those plans.

Not sure how having the stubs would help with that. TI_SCI_PROTOCOL can already be built as a module. The stubs are what cause this issue here. When built as a module, the stubs are not active so any driver that depends on this module that is built-in will cause a link error.

Stubs only make sense for optional components, like GPIOLIB, where the driver using that component can continue when it is not available. For all drivers that depend on TI-SCI it is not optional. The dependent driver *will* fail to probe and error out. These stubs do nothing, and I'd like to just remove them.

Andrew

#7 lore raw
Quoted 5 lines · Andrew Davis

Stubs only make sense for optional components, like GPIOLIB, where the driver using that component can continue when it is not available. For all drivers that depend on TI-SCI it is not optional. The dependent driver *will* fail to probe and error out. These stubs do nothing, and I'd like to just remove them.

Fair enough. I'd like to see a series where the drivers have been converted to modules and we remove the "select" from arch/arm64/Kconfig.platforms - we can then drop the stubs once the modularization is complete.

Signature · 3 lines
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D
maintainer
#8 lore raw
In reply to Andrew Davis
Quoted 45 lines · Andrew Davis
Quoted 31 lines · Arnd Bergmann

From: Arnd Bergmann <[email protected]>

The k3-m4 remoteproc driver was merged with incorrect dependencies. Despite multiple people trying to fix this, the version 6.12-rc2 remains broken and causes a build failure with CONFIG_TI_SCI_PROTOCOL=m when the driver is built-in.

arm-linux-gnueabi-ld: drivers/remoteproc/ti_k3_m4_remoteproc.o: in function `k3_m4_rproc_probe':
ti_k3_m4_remoteproc.c:(.text.k3_m4_rproc_probe+0x76): undefined reference to `devm_ti_sci_get_by_phandle'

Fix the dependency again to make it work in all configurations. The 'select OMAP2PLUS_MBOX' no longer matches what the other drivers dependencies. The link failure can be avoided with a simple 'depends do, so turn that into the same 'depends' to ensure we get no circular on TI_SCI_PROTOCOL', but the extra COMPILE_TEST alternative is what we use elsehwere. On the other hand, building for OMAP2PLUS makes no sense since the hardware only exists on K3.

Fixes ebcf9008a895 ("remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem")
Fixes ba0c0cb56f22 ("remoteproc: k3-m4: use the proper dependencies")
Fixes 54595f2807d2 ("mailbox, remoteproc: omap2+: fix compile testing")
Signed-off-by Arnd Bergmann <[email protected]>
---
  drivers/remoteproc/Kconfig | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)
drivers/remoteproc/Kconfig +0 -0
index 955e4e38477e..62f8548fb46a 100644

drivers/remoteproc/Kconfig config TI_K3_DSP_REMOTEPROC · line 344

Quoted 7 lines
drivers/remoteproc/Kconfig +2 -3
@@ -341,9 +341,9 @@ config TI_K3_DSP_REMOTEPROC
  config TI_K3_M4_REMOTEPROC
  	tristate "TI K3 M4 remoteproc support"
-	depends on ARCH_OMAP2PLUS || ARCH_K3
-	select MAILBOX
-	select OMAP2PLUS_MBOX
+	depends on ARCH_K3 || COMPILE_TEST
+	depends on TI_SCI_PROTOCOL || (COMPILE_TEST && TI_SCI_PROTOCOL=n)

This line is odd. IMHO "COMPILE_TEST" should only be added to ARCH_* dependencies, as often only one ARCH can be selected which prevents compile testing drivers with various multiple architecture deps in one compile test.

Quoted 7 lines

Normal dependencies, on the other hand, can simply be enabled if one wants to compile test its dependent drivers. In this case, TI_SCI_PROTOCOL cannot be enabled as it has a dependency up the chain that doesn't allow selecting when not on a TI platform. We can fix that as I posted here[0]. With that fix in, this line can be simply become:

depends on TI_SCI_PROTOCOL

From the above and the follow-on conversation with Nishanth, should I understand you are working on a patchset to address this issue? If not I will apply Arnd's patch. People are sending different fix [1] - the issue needs to be addressed well before the end of the cycle.

[1]. https://lore.kernel.org/linux-arm-kernel/[email protected]/T/

Quoted 9 lines

Andrew

[0] https://lore.kernel.org/lkml/[email protected]/

Quoted 4 lines
drivers/remoteproc/Kconfig +1 -0
+	depends on OMAP2PLUS_MBOX
  	help
  	  Say m here to support TI's M4 remote processor subsystems
  	  on various TI K3 family of SoCs through the remote processor
#9 lore raw
Quoted 52 lines · Mathieu Poirier
Quoted 51 lines · Andrew Davis
Quoted 31 lines · Arnd Bergmann

From: Arnd Bergmann <[email protected]>

The k3-m4 remoteproc driver was merged with incorrect dependencies. Despite multiple people trying to fix this, the version 6.12-rc2 remains broken and causes a build failure with CONFIG_TI_SCI_PROTOCOL=m when the driver is built-in.

arm-linux-gnueabi-ld: drivers/remoteproc/ti_k3_m4_remoteproc.o: in function `k3_m4_rproc_probe':
ti_k3_m4_remoteproc.c:(.text.k3_m4_rproc_probe+0x76): undefined reference to `devm_ti_sci_get_by_phandle'

Fix the dependency again to make it work in all configurations. The 'select OMAP2PLUS_MBOX' no longer matches what the other drivers dependencies. The link failure can be avoided with a simple 'depends do, so turn that into the same 'depends' to ensure we get no circular on TI_SCI_PROTOCOL', but the extra COMPILE_TEST alternative is what we use elsehwere. On the other hand, building for OMAP2PLUS makes no sense since the hardware only exists on K3.

Fixes ebcf9008a895 ("remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem")
Fixes ba0c0cb56f22 ("remoteproc: k3-m4: use the proper dependencies")
Fixes 54595f2807d2 ("mailbox, remoteproc: omap2+: fix compile testing")
Signed-off-by Arnd Bergmann <[email protected]>
---
   drivers/remoteproc/Kconfig | 6 +++---
   1 file changed, 3 insertions(+), 3 deletions(-)
drivers/remoteproc/Kconfig +0 -0
index 955e4e38477e..62f8548fb46a 100644

drivers/remoteproc/Kconfig config TI_K3_DSP_REMOTEPROC · line 344

Quoted 7 lines
drivers/remoteproc/Kconfig +2 -3
@@ -341,9 +341,9 @@ config TI_K3_DSP_REMOTEPROC
   config TI_K3_M4_REMOTEPROC
   	tristate "TI K3 M4 remoteproc support"
-	depends on ARCH_OMAP2PLUS || ARCH_K3
-	select MAILBOX
-	select OMAP2PLUS_MBOX
+	depends on ARCH_K3 || COMPILE_TEST
+	depends on TI_SCI_PROTOCOL || (COMPILE_TEST && TI_SCI_PROTOCOL=n)

This line is odd. IMHO "COMPILE_TEST" should only be added to ARCH_* dependencies, as often only one ARCH can be selected which prevents compile testing drivers with various multiple architecture deps in one compile test.

Normal dependencies, on the other hand, can simply be enabled if one wants to compile test its dependent drivers. In this case, TI_SCI_PROTOCOL cannot be enabled as it has a dependency up the chain that doesn't allow selecting when not on a TI platform. We can fix that as I posted here[0]. With that fix in, this line can be simply become:

Quoted 7 lines
Quoted 1 line

depends on TI_SCI_PROTOCOL

From the above and the follow-on conversation with Nishanth, should I understand
you are working on a patchset to address this issue? If not I will apply Arnd's patch. People are sending different fix [1] - the issue needs to be addressed well before the end of the cycle.

This is a bit complex as it touches multiple subsystems. You should take Arnd's patch. This will fix this for M4, I will then add a follow on patch doing the same for the other two remoteproc drivers (DSP and R5).

When my series here[0] goes in I will then send a final patch removing the depends TI_SCI_PROTOCOL=n oddness from all 3 drivers. This final step does not need to happen this cycle though, only the first two steps are needed to prevent any further compile test issues.

Andrew

[0] https://lore.kernel.org/lkml/[email protected]/

Quoted 11 lines

[1]. https://lore.kernel.org/linux-arm-kernel/[email protected]/T/

Quoted 9 lines

Andrew

[0] https://lore.kernel.org/lkml/[email protected]/

Quoted 4 lines
drivers/remoteproc/Kconfig +1 -0
+	depends on OMAP2PLUS_MBOX
   	help
   	  Say m here to support TI's M4 remote processor subsystems
   	  on various TI K3 family of SoCs through the remote processor
maintainer
#10 lore raw
Quoted 61 lines · Andrew Davis
Quoted 52 lines · Mathieu Poirier
Quoted 51 lines · Andrew Davis
Quoted 31 lines · Arnd Bergmann

From: Arnd Bergmann <[email protected]>

The k3-m4 remoteproc driver was merged with incorrect dependencies. Despite multiple people trying to fix this, the version 6.12-rc2 remains broken and causes a build failure with CONFIG_TI_SCI_PROTOCOL=m when the driver is built-in.

arm-linux-gnueabi-ld: drivers/remoteproc/ti_k3_m4_remoteproc.o: in function `k3_m4_rproc_probe':
ti_k3_m4_remoteproc.c:(.text.k3_m4_rproc_probe+0x76): undefined reference to `devm_ti_sci_get_by_phandle'

Fix the dependency again to make it work in all configurations. The 'select OMAP2PLUS_MBOX' no longer matches what the other drivers dependencies. The link failure can be avoided with a simple 'depends do, so turn that into the same 'depends' to ensure we get no circular on TI_SCI_PROTOCOL', but the extra COMPILE_TEST alternative is what we use elsehwere. On the other hand, building for OMAP2PLUS makes no sense since the hardware only exists on K3.

Fixes ebcf9008a895 ("remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem")
Fixes ba0c0cb56f22 ("remoteproc: k3-m4: use the proper dependencies")
Fixes 54595f2807d2 ("mailbox, remoteproc: omap2+: fix compile testing")
Signed-off-by Arnd Bergmann <[email protected]>
---
   drivers/remoteproc/Kconfig | 6 +++---
   1 file changed, 3 insertions(+), 3 deletions(-)
drivers/remoteproc/Kconfig +0 -0
index 955e4e38477e..62f8548fb46a 100644

drivers/remoteproc/Kconfig config TI_K3_DSP_REMOTEPROC · line 344

Quoted 7 lines
drivers/remoteproc/Kconfig +2 -3
@@ -341,9 +341,9 @@ config TI_K3_DSP_REMOTEPROC
   config TI_K3_M4_REMOTEPROC
   	tristate "TI K3 M4 remoteproc support"
-	depends on ARCH_OMAP2PLUS || ARCH_K3
-	select MAILBOX
-	select OMAP2PLUS_MBOX
+	depends on ARCH_K3 || COMPILE_TEST
+	depends on TI_SCI_PROTOCOL || (COMPILE_TEST && TI_SCI_PROTOCOL=n)

This line is odd. IMHO "COMPILE_TEST" should only be added to ARCH_* dependencies, as often only one ARCH can be selected which prevents compile testing drivers with various multiple architecture deps in one compile test.

Normal dependencies, on the other hand, can simply be enabled if one wants to compile test its dependent drivers. In this case, TI_SCI_PROTOCOL cannot be enabled as it has a dependency up the chain that doesn't allow selecting when not on a TI platform. We can fix that as I posted here[0]. With that fix in, this line can be simply become:

Quoted 7 lines
Quoted 1 line

depends on TI_SCI_PROTOCOL

From the above and the follow-on conversation with Nishanth, should I understand
you are working on a patchset to address this issue? If not I will apply Arnd's patch. People are sending different fix [1] - the issue needs to be addressed well before the end of the cycle.

Quoted 9 lines

This is a bit complex as it touches multiple subsystems. You should take Arnd's patch. This will fix this for M4, I will then add a follow on patch doing the same for the other two remoteproc drivers (DSP and R5).

When my series here[0] goes in I will then send a final patch removing the depends TI_SCI_PROTOCOL=n oddness from all 3 drivers. This final step does not need to happen this cycle though, only the first two steps are needed to prevent any further compile test issues.

I have applied Arnd's patch.

Quoted 15 lines

Andrew

[0] https://lore.kernel.org/lkml/[email protected]/

Quoted 11 lines

[1]. https://lore.kernel.org/linux-arm-kernel/[email protected]/T/

Quoted 9 lines

Andrew

[0] https://lore.kernel.org/lkml/[email protected]/

Quoted 4 lines
drivers/remoteproc/Kconfig +1 -0
+	depends on OMAP2PLUS_MBOX
   	help
   	  Say m here to support TI's M4 remote processor subsystems
   	  on various TI K3 family of SoCs through the remote processor
#11 lore raw
Quoted 66 lines · Mathieu Poirier
Quoted 65 lines · Andrew Davis
Quoted 52 lines · Mathieu Poirier
Quoted 51 lines · Andrew Davis
Quoted 31 lines · Arnd Bergmann

From: Arnd Bergmann <[email protected]>

The k3-m4 remoteproc driver was merged with incorrect dependencies. Despite multiple people trying to fix this, the version 6.12-rc2 remains broken and causes a build failure with CONFIG_TI_SCI_PROTOCOL=m when the driver is built-in.

arm-linux-gnueabi-ld: drivers/remoteproc/ti_k3_m4_remoteproc.o: in function `k3_m4_rproc_probe':
ti_k3_m4_remoteproc.c:(.text.k3_m4_rproc_probe+0x76): undefined reference to `devm_ti_sci_get_by_phandle'

Fix the dependency again to make it work in all configurations. The 'select OMAP2PLUS_MBOX' no longer matches what the other drivers dependencies. The link failure can be avoided with a simple 'depends do, so turn that into the same 'depends' to ensure we get no circular on TI_SCI_PROTOCOL', but the extra COMPILE_TEST alternative is what we use elsehwere. On the other hand, building for OMAP2PLUS makes no sense since the hardware only exists on K3.

Fixes ebcf9008a895 ("remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem")
Fixes ba0c0cb56f22 ("remoteproc: k3-m4: use the proper dependencies")
Fixes 54595f2807d2 ("mailbox, remoteproc: omap2+: fix compile testing")
Signed-off-by Arnd Bergmann <[email protected]>
---
    drivers/remoteproc/Kconfig | 6 +++---
    1 file changed, 3 insertions(+), 3 deletions(-)
drivers/remoteproc/Kconfig +0 -0
index 955e4e38477e..62f8548fb46a 100644

drivers/remoteproc/Kconfig config TI_K3_DSP_REMOTEPROC · line 344

Quoted 7 lines
drivers/remoteproc/Kconfig +2 -3
@@ -341,9 +341,9 @@ config TI_K3_DSP_REMOTEPROC
    config TI_K3_M4_REMOTEPROC
    	tristate "TI K3 M4 remoteproc support"
-	depends on ARCH_OMAP2PLUS || ARCH_K3
-	select MAILBOX
-	select OMAP2PLUS_MBOX
+	depends on ARCH_K3 || COMPILE_TEST
+	depends on TI_SCI_PROTOCOL || (COMPILE_TEST && TI_SCI_PROTOCOL=n)

This line is odd. IMHO "COMPILE_TEST" should only be added to ARCH_* dependencies, as often only one ARCH can be selected which prevents compile testing drivers with various multiple architecture deps in one compile test.

Normal dependencies, on the other hand, can simply be enabled if one wants to compile test its dependent drivers. In this case, TI_SCI_PROTOCOL cannot be enabled as it has a dependency up the chain that doesn't allow selecting when not on a TI platform. We can fix that as I posted here[0]. With that fix in, this line can be simply become:

Quoted 7 lines
Quoted 1 line

depends on TI_SCI_PROTOCOL

From the above and the follow-on conversation with Nishanth, should I understand
you are working on a patchset to address this issue? If not I will apply Arnd's patch. People are sending different fix [1] - the issue needs to be addressed well before the end of the cycle.

This is a bit complex as it touches multiple subsystems. You should take Arnd's patch. This will fix this for M4, I will then add a follow on patch doing the same for the other two remoteproc drivers (DSP and R5).

Quoted 8 lines
Quoted 5 lines

When my series here[0] goes in I will then send a final patch removing the depends TI_SCI_PROTOCOL=n oddness from all 3 drivers. This final step does not need to happen this cycle though, only the first two steps are needed to prevent any further compile test issues.

I have applied Arnd's patch.

Follow up series sent: https://lore.kernel.org/lkml/[email protected]/

Andrew

Quoted 15 lines
Quoted 15 lines

Andrew

[0] https://lore.kernel.org/lkml/[email protected]/

Quoted 11 lines

[1]. https://lore.kernel.org/linux-arm-kernel/[email protected]/T/

Quoted 9 lines

Andrew

[0] https://lore.kernel.org/lkml/[email protected]/

Quoted 4 lines
drivers/remoteproc/Kconfig +1 -0
+	depends on OMAP2PLUS_MBOX
    	help
    	  Say m here to support TI's M4 remote processor subsystems
    	  on various TI K3 family of SoCs through the remote processor