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: <87y11osnuq.fsf@bootlin.com>
Date: Tue, 12 Nov 2024 12:17:17 +0100
From: Miquel Raynal <miquel.raynal@...tlin.com>
To: Bastien Curutchet <bastien.curutchet@...tlin.com>
Cc: Santosh Shilimkar <ssantosh@...nel.org>,  Krzysztof Kozlowski
 <krzk@...nel.org>,  Richard Weinberger <richard@....at>,  Vignesh
 Raghavendra <vigneshr@...com>,  linux-kernel@...r.kernel.org,
  linux-mtd@...ts.infradead.org,  Thomas Petazzoni
 <thomas.petazzoni@...tlin.com>,  Herve Codina <herve.codina@...tlin.com>,
  Christopher Cordahi <christophercordahi@...ometrics.ca>
Subject: Re: [PATCH v2 2/6] memory: ti-aemif: Export aemif_set_cs_timings()

Hi Bastien,

On 12/11/2024 at 10:13:38 +01, Bastien Curutchet <bastien.curutchet@...tlin.com> wrote:

> Hi Miquèl,
>
> On 11/11/24 8:21 PM, Miquel Raynal wrote:
>> Hello Bastien,
>> On 06/11/2024 at 09:55:03 +01, Bastien Curutchet
>> <bastien.curutchet@...tlin.com> wrote:
>> 
>>> Export the aemif_set_cs_timing() symbol so it can be used by other
>>> drivers
>>>
>>> Add a spinlock to protect the CS configuration register from concurrent
>>> accesses.
>> What concurrent accesses are you trying to protect yourself against?
>> I fail to see the use case, but TBH I haven't tried hard enough maybe.
>> 
>
> The register that handles the CS configuration belongs to the AEMIF
> component but it will also be accessed by the AEMIF 'children' with the
> aemif_set_cs_timing() function. So far, concurrent accesses shouldn't
> occur because the AEMIF configures the CS timings only once and does so
> before probing its 'children'; but I don't know how things can evolve in
> the future.

Okay, and I guess we can have more than one children, in this case
indeed we need serialization.

>> Also, what justifies the use of a spin-lock in this case?
>> 
>
> TBH, I always struggle to choose between mutexes and spin-locks. I chose
> spin-lock because it only protects one memory-mapped register so I think
> it doesn't worth going to sleep when waiting for the lock.

In general, I believe in a path that is not a hot-path and if you can
sleep, you should go for a mutex.

Cheers,
Miquèl

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ