Re: [EXTERNAL] Re: [PATCH] misc: mrvl-cn10k-dpi: resolve compilation issues on 32-bit ARM

[Jeff Johnson]

On 7/17/2024 6:41 AM, Nathan Chancellor wrote:
> On Wed, Jul 17, 2024 at 12:17:08PM +0000, Vamsi Krishna Attunuru wrote:
>>
>>
>>> -----Original Message-----
>>> From: Arnd Bergmann <arnd@xxxxxxxx>
>>> Sent: Wednesday, July 17, 2024 5:20 PM
>>> To: Vamsi Krishna Attunuru <vattunuru@xxxxxxxxxxx>; Greg Kroah-Hartman
>>> <gregkh@xxxxxxxxxxxxxxxxxxx>
>>> Cc: linux-kernel@xxxxxxxxxxxxxxx; Nathan Chancellor <nathan@xxxxxxxxxx>;
>>> Jeff Johnson <quic_jjohnson@xxxxxxxxxxx>
>>> Subject: Re: [EXTERNAL] Re: [PATCH] misc: mrvl-cn10k-dpi: resolve
>>> compilation issues on 32-bit ARM
>>>
>>> On Wed, Jul 17, 2024, at 13: 45, Vamsi Krishna Attunuru wrote: > > Neither of
>>> them worked in our case, HW folks also confirmed that only > 64bit access
>>> work correctly. > I will just include the header that address the compilation
>>>
>>> On Wed, Jul 17, 2024, at 13:45, Vamsi Krishna Attunuru wrote:
>>>>
>>>> Neither of them worked in our case, HW folks also confirmed that only
>>>> 64bit access work correctly.
>>>> I will just include the header that address the compilation errors
>>>> with ARCH=arm, anyways nobody will use this driver on 32-bit kernel.
>>>
>>> Please just use a Kconfig dependency then. If the device requires 64-bit
>>> register access, then the driver should not use the fallback.
>>
>> Ack, since it needs to skip compilation on 32-bit platforms, can you please
>> confirm below change is suffice or not.
>>
>> --- a/drivers/misc/Kconfig
>> +++ b/drivers/misc/Kconfig
>> @@ -588,7 +588,7 @@ config NSM
>>  config MARVELL_CN10K_DPI
>>         tristate "Octeon CN10K DPI driver"
>>         depends on PCI
>> -       depends on ARCH_THUNDER || COMPILE_TEST
>> +       depends on (ARCH_THUNDER || COMPILE_TEST) && 64BIT
> 
> I think it would be a little clearer written as
> 
>   depends on ARCH_THUNDER || (COMPILE_TEST && 64BIT)
> 
> because ARCH_THUNDER can only be defined when 64BIT is set. Regardless
> though, that should resolve the issue.
> 
> Tested-by: Nathan Chancellor <nathan@xxxxxxxxxx>
> 
> Cheers,
> Nathan

I took Nathan's suggestion locally,

Tested-by: Jeff Johnson <quic_jjohnson@xxxxxxxxxxx>