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] [day] [month] [year] [list]

Message-ID: <ca621caa-0b6c-47c7-b602-3db6fc5be839@ti.com>
Date: Wed, 16 Oct 2024 11:43:27 -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 11:02 AM, Mathieu Poirier wrote:
> 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.
> 

Follow up series sent: https://lore.kernel.org/lkml/20241016164141.93401-1-afd@ti.com/

Andrew

>> 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