linux-kernel - Re: [EXTERNAL] Re: [PATCH] misc: Kconfig: add a new dependency for MARVELL_CN10K

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: <10d583d4-29ec-4dae-8629-f6097639cc4e@app.fastmail.com>
Date: Tue, 16 Jul 2024 17:48:38 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Vamsi Attunuru" <vattunuru@...vell.com>,
 "Nathan Chancellor" <nathan@...nel.org>
Cc: "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [EXTERNAL] Re: [PATCH] misc: Kconfig: add a new dependency for
 MARVELL_CN10K_DPI

On Tue, Jul 16, 2024, at 17:33, Vamsi Krishna Attunuru wrote:
>>> Including one of the io-64-nonatomic headers would resolve this but I
>>> am not sure which one would be appropriate (or perhaps the dependency
>>> should be tightened to requiring 64BIT, as some other drivers have
>>> done).
>>
>>Right, a dependency on 64BIT makes sense here. The alternative is to include
>>linux/io-64-nonatomic-hi-lo.h or linux/io-64-nonatomic-lo-hi.h in order to
>>have a replacement readq/writeq implementation that works on 32-bit
>>architectures. However, doing this requires understanding whether what the
>>side-effects of accessing the 64-bit registers are and whether they require
>>writing the upper or lower half of the register last.
>>
>
> Yes Arnd, I am checking the functionality using lo-hi calls that you suggested.
> If it has any implications, I will fix it with the 64BIT dependency.
>

If the datasheet does not give you any insight about how it works,
you can try it out on a 64-bit kernel by changing all the
readq/writeq into lo_hi_readq()/lo_hi_writeq() or
hi_lo_readq()/hi_lo_writeq() after including the corresponding header.

Usually only one of the two works, or possibly neither if the registers
require 64-bit access. If you figure out which one works, you
can change the calls back to readq/writeq and leave the correct
header included that will provide fallback implementations on 32-bit
architectures but use the native 64-bit access on 64-bit architectures.

In practice this is not really important because nobody will ever
need to use this driver on a 32-bit kernel, given that this SoC
only supports 32-bit usermode but not kernel.

       Arnd