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: <22bf9a24-b4db-4017-b5a9-1b03e6f20bff@app.fastmail.com>
Date: Wed, 17 Jul 2024 07:39:57 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Vamsi Attunuru" <vattunuru@...vell.com>,
 "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

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?

      Arnd