Re: [PATCH] Revert "reset: microchip-sparx5: allow building as a module"

From: Michael Walle
Date: Wed Jul 13 2022 - 05:52:09 EST

[+ Horatiu, I missed you earlier, sorry]

Hi Steen,

Am 2022-07-13 11:40, schrieb Steen Hegelund:
I am afraid that the exact list of affected modules is not available,
so using the
RESET_PROT_STAT.SYS_RST_PROT_VCORE bit is the best known way of
resetting as much as possible, and
still continue execution.

Mh, you are designing that chip (at least the LAN966x) no? Shouldn't
that information be available anywhere at Microchip? ;)

Anyway, it looks like almost the whole chip is reset
except some minor things. So the driver has actually a
wrong name. Until recently only the switch driver was the
sole user of it (at least on the lan966x). So, my question
remains, is this correct? I mean the switch driver says,
"reset the switch core", but what actually happens is that
the the entire SoC except the CPU and maybe the io mux is reset.
What about the watchdog for example? Will that be reset, too?


This is what the Sparx5 datasheet has to say about the
SYS_RST_PROT_VCORE protect bit:

The device can be soft-reset by writing SOFT_RST.SOFT_CHIP_RST. The
VCore system and CPU can be
protected from a device soft-reset by writing
initiating soft-reset. 

In this case, a chip-level soft reset is applied to all other blocks
except the VCore system and the
VCore CPU. When protecting the VCore system and CPU from a soft reset,
the frame DMA must be
disabled prior to a chip-level soft reset. The SERDES and PLL blocks
can be protected from reset by
writing to SOFT_RST.SOFT_SWC_RST instead of SOFT_CHIP_RST.

The VCore general purpose registers (CPU::GPR) and GPIO alternate
modes (DEVCPU_GCB::GPIO_ALT) are
not affected by a soft-reset. These registers are only reset when an
external reset is asserted.


On Wed, 2022-07-13 at 11:03 +0200, Michael Walle wrote:
EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe

[+ Claudiu, Kavyasree ]
Am 2022-07-13 10:40, schrieb Philipp Zabel:
> This reverts commit b6b9585876da018bdde2d5f15d206a689c0d70f3.
> This breaks MDIO on kswitch-d10, presumably because the global switch
> reset is not released early enough anymore.
> Reported-by: Michael Walle <michael@xxxxxxxx>
> Cc: Clément Léger <clement.leger@xxxxxxxxxxx>
> Signed-off-by: Philipp Zabel <p.zabel@xxxxxxxxxxxxxx>


Tested-by: Michael Walle <michael@xxxxxxxx>

And maybe Microchip can chime in here and tell us what
subsystems in the SoC will actually be reset by this.
I fear this reset will affect almost every part of the
SoC. So it would have to be bound to every single
device? Or maybe adding that reset to the switch driver
was a mistake in the first place?

I mean, if it wouldn't be for the guard bit, it would
also reset the CPU core..