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: <07e5b001-b251-4f4f-8ce9-56b43032b5c4@ti.com>
Date: Wed, 16 Oct 2024 10:37:35 -0500
From: Andrew Davis <afd@...com>
To: Mathieu Poirier <mathieu.poirier@...aro.org>
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 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.

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