linux-kernel - Re: [PATCH] mailbox, remoteproc: k3-m4+: fix compile testing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Zw/jkpnGXW6ez56o@p14s>
Date: Wed, 16 Oct 2024 10:02:26 -0600
From: Mathieu Poirier <mathieu.poirier@...aro.org>
To: Andrew Davis <afd@...com>
Cc: Arnd Bergmann <arnd@...nel.org>, Bjorn Andersson <andersson@...nel.org>,
	Martyn Welch <martyn.welch@...labora.com>,
	Hari Nagalla <hnagalla@...com>,
	Jassi Brar <jassisinghbrar@...il.com>,
	Arnd Bergmann <arnd@...db.de>, linux-remoteproc@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mailbox, remoteproc: k3-m4+: fix compile testing

On Wed, Oct 16, 2024 at 10:37:35AM -0500, Andrew Davis wrote:
> On 10/16/24 10:26 AM, Mathieu Poirier wrote:
> > On Mon, Oct 14, 2024 at 09:56:11AM -0500, Andrew Davis wrote:
> > > On 10/7/24 8:23 AM, Arnd Bergmann wrote:
> > > > From: Arnd Bergmann <arnd@...db.de>
> > > > 
> > > > 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 <arnd@...db.de>
> > > > ---
> > > >    drivers/remoteproc/Kconfig | 6 +++---
> > > >    1 file changed, 3 insertions(+), 3 deletions(-)
> > > > 
> > > > diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> > > > index 955e4e38477e..62f8548fb46a 100644
> > > > --- a/drivers/remoteproc/Kconfig
> > > > +++ b/drivers/remoteproc/Kconfig
> > > > @@ -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
> > 
> >  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.
>

I have applied Arnd's patch.

> Andrew
> 
> [0] https://lore.kernel.org/lkml/20241015213322.2649011-1-afd@ti.com/
> 
> > [1]. https://lore.kernel.org/linux-arm-kernel/20241016013922.1392290-1-zengheng4@huawei.com/T/
> > 
> > > 
> > > Andrew
> > > 
> > > [0] https://lore.kernel.org/lkml/20241014144821.15094-1-afd@ti.com/
> > > 
> > > > +	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