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

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: 
 <SJ0PR18MB524672A30BAE8A7163FABECCA6A32@SJ0PR18MB5246.namprd18.prod.outlook.com>
Date: Wed, 17 Jul 2024 11:45:50 +0000
From: Vamsi Krishna Attunuru <vattunuru@...vell.com>
To: Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman
	<gregkh@...uxfoundation.org>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Nathan
 Chancellor <nathan@...nel.org>,
        Jeff Johnson <quic_jjohnson@...cinc.com>
Subject: RE: [EXTERNAL] Re: [PATCH] misc: mrvl-cn10k-dpi: resolve compilation
 issues on 32-bit ARM



>-----Original Message-----
>From: Arnd Bergmann <arnd@...db.de>
>Sent: Wednesday, July 17, 2024 11:10 AM
>To: Vamsi Krishna Attunuru <vattunuru@...vell.com>; Greg Kroah-Hartman
><gregkh@...uxfoundation.org>
>Cc: linux-kernel@...r.kernel.org; Nathan Chancellor <nathan@...nel.org>;
>Jeff Johnson <quic_jjohnson@...cinc.com>
>Subject: Re: [EXTERNAL] Re: [PATCH] misc: mrvl-cn10k-dpi: resolve
>compilation issues on 32-bit ARM
>
>On Wed, Jul 17, 2024, at 07: 35, Vamsi Krishna Attunuru wrote: >>> #include
><uapi/misc/mrvl_cn10k_dpi. h> >>> >>> @@ -185,6 +188,8 @@ struct
>dpi_mbox_message { >>> uint64_t word_h; >>> }; >>>
>
>On Wed, Jul 17, 2024, at 07:35, Vamsi Krishna Attunuru wrote:
>
>>>>  #include <uapi/misc/mrvl_cn10k_dpi.h>
>>>>
>>>> @@ -185,6 +188,8 @@ struct dpi_mbox_message {
>>>>  	uint64_t word_h;
>>>>  };
>>>>
>>>> +#ifdef CONFIG_64BIT
>>>> +
>>>>  static inline void dpi_reg_write(struct dpipf *dpi, u64 offset, u64
>>>> val)  {
>>>>  	writeq(val, dpi->reg_base + offset); @@ -195,6 +200,40 @@ static
>>>> inline u64 dpi_reg_read(struct dpipf *dpi, u64 offset)
>>>>  	return readq(dpi->reg_base + offset);  }
>>>>
>>>> +static inline void dpi_writeq(u64 val, void __iomem *addr) {
>>>> +	writeq(val, addr);
>>>> +}
>>>> +
>>>> +static inline u64 dpi_readq(const void __iomem *addr) {
>>>> +	return readq(addr);
>>>> +}
>>>> +
>>>> +#else
>>>
>>>Normally we do not like #ifdef in .c files, are you sure this is the
>>>correct way to handle this?
>>
>> Ok, came across the similar usage in some other drivers and presumed
>> it's fine with small routines. I will move the #ifdef inside the
>> routines than.
>>
>> Thank you, Greg, for the prompt feedback.
>
>You shouldn't need any #ifdef here, just call readq/writeq unconditionally
>after including the header.
>
>Have you been able to confirm whether the device works correctly with the
>lo_hi ordering?
>

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.

Thanks Arnd. 

Vamsi

>      Arnd