On Thu, Feb 01, 2024 at 12:40:17PM +0100, Frank Wunderlich wrote: > Am 19. Januar 2024 18:04:36 MEZ schrieb Conor Dooley <conor@xxxxxxxxxx>: > >On Fri, Jan 19, 2024 at 10:28:30AM +0100, AngeloGioacchino Del Regno wrote: > >> > >> 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. > > > >> 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@xxxxxxxxxxxxx> Cheers, Conor. > > But i have not seen them picked up yet in linux-next. > regards Frank
Attachment:
signature.asc
Description: PGP signature
