linux-kernel - Re: [PATCH] spi: bcm63xx: fix shared reset

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] [day] [month] [year] [list]

Message-ID: <CAOiHx=kFvXoPwes4AXsysxLz7ZgGzae2FayGw=BAgbaqfJ_Ukw@mail.gmail.com>
Date: Thu, 5 Jun 2025 09:45:30 +0200
From: Jonas Gorski <jonas.gorski@...il.com>
To: Philipp Zabel <p.zabel@...gutronix.de>
Cc: Álvaro Fernández Rojas <noltari@...il.com>, 
	dgcbueu@...il.com, florian.fainelli@...adcom.com, william.zhang@...adcom.com, 
	kursad.oney@...adcom.com, bcm-kernel-feedback-list@...adcom.com, 
	broonie@...nel.org, linux-spi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] spi: bcm63xx: fix shared reset

On Mon, Jun 2, 2025 at 11:31 AM Philipp Zabel <p.zabel@...gutronix.de> wrote:
>
> On Do, 2025-05-29 at 15:09 +0200, Álvaro Fernández Rojas wrote:
> > Some bmips SoCs (bcm6362, bcm63268) share the same SPI reset for both SPI and
> > HSSPI controllers, so reset shouldn't be exclusive.
> >
> > Álvaro Fernández Rojas (2):
> >   spi: bcm63xx-spi: fix shared reset
>
> Both drivers currently enable the SPI clock before triggering a reset.
> Can the hardware cope with being reset before the clock is enabled?
> That could happen for the second device to be bound [1], unless the SPI
> clock is shared as well or already running for another reason.
>
> [1] https://docs.kernel.org/driver-api/reset.html#triggering

In a completely unscientific test, I disabled both SPI clocks and
triggered the reset, and the hardware didn't seem to mind. It also
didn't seem to have any observable effect, as all registers I checked
kept their previous values (both with and without clocks enabled).
Neither disabling the clocks nor asserting the reset prevented my from
reading the registers of either block, so their effects seem to be
rather limited.

That being said, the bootloader (in the one device I tested) seems to
keep both clocks enabled, so they would still both be enabled during
the reset of whichever is probed first.

Regards,
Jonas