On Thu, Feb 01, 2024 at 12:40:17PM +0100, Frank Wunderlich wrote:

Am 19. Januar 2024 18:04:36 MEZ schrieb Conor Dooley [off-list ref]:

quoted

On Fri, Jan 19, 2024 at 10:28:30AM +0100, AngeloGioacchino Del Regno wrote:

quoted

The resets are organized on a per-reset-controller basis, so, the ETHWARP
reset controller's first reset is RST_SWITCH, the second one is RST_something_else,
etc. while the first reset of the INFRA reset controller is PEXTP_MAC_SWRST.

That's why ETHWARP has a reset index 0 and INFRA also starts at 0.
I think that the numbering is good as it is, and having one driver start at index 5
while the other starts at index 12 would only overcomplicate registering the resets
in each driver, or waste bytes by making unnecessarily large arrays, for (imo) no
good reason.

This is one header, but it should "in theory" be more than one... so we would have
one for each hardware block - but that'd make the reset directory over-crowded, as
other MediaTek SoCs have got even more resets in even more hardware blocks than the
MT7988. That'd be something like ~4 reset headers per SoC (and will increase with
newer ones)...
...and this is why we have one binding header for resets.

That's okay. The commit message leaves me, who clearly isn't a mediatek
guy, with no information as to why these are not one contiguous set.
IMO being for different reset controllers entirely is fine.

quoted

On the topic of leaving space to allow grouping RST0/RST1: -> No. <-
The indices have to start from zero and have to be sequential, with no holes.

Agreed.

Hi,

Just a friendly reminder.

As far as i understood, Patches are fine so far and do not need any rework,right?

I suspect I was asking for a commit message that explains why these
numbers don't continue in sequence. With that,
Acked-by: Conor Dooley <conor.dooley@microchip.com>

Cheers,
Conor.

But i have not seen them picked up yet in linux-next.
regards Frank