> Subject: Re: [PATCH v6 1/7] dt-bindings: firmware: add i.MX95 SCMI > Extension protocol > > On Wed, Jul 31, 2024 at 12:49:59PM +0000, Peng Fan wrote: > > > Subject: Re: [PATCH v6 1/7] dt-bindings: firmware: add i.MX95 > SCMI > > > Extension protocol > > > > > > On Wed, Jul 31, 2024 at 12:18:28PM +0000, Peng Fan wrote: > > > > > Subject: Re: [PATCH v6 1/7] dt-bindings: firmware: add i.MX95 > > > SCMI > > > > > Extension protocol > > > > > > > > > > On 18/07/2024 09:41, Peng Fan (OSS) wrote: > > > > > > From: Peng Fan <peng.fan@xxxxxxx> > > > > > > > > > > > > Add i.MX SCMI Extension protocols bindings for: > > > > > > - Battery Backed Module(BBM) Protocol > > > > > > This contains persistent storage (GPR), an RTC, and the > > > > > > ON/OFF > > > > > button. > > > > > > The protocol can also provide access to similar functions > > > > > implemented via > > > > > > external board components. > > > > > > - MISC Protocol. > > > > > > This includes controls that are misc settings/actions that > > > > > > must be > > > > > exposed > > > > > > from the SM to agents. They are device specific and are > > > > > > usually > > > > > define to > > > > > > access bit fields in various mix block control modules, > > > > > > IOMUX_GPR, > > > > > and > > > > > > other GPR/CSR owned by the SM. > > > > > > > > > > > > Reviewed-by: "Rob Herring (Arm)" <robh@xxxxxxxxxx> > > > > > > > > > > Why quotes? Which tools did you use? > > > > > > > > I could not recall why have this. I will drop and resend the > patchset. > > > > > > > > > > Resend only if you have any other comments addressed, no spin > just > > > for this one please. > > > > Sorry, I pushed the button too quick to send out v7(just correct this > > R-b tag and rebased to linux-next) before checking my inbox. > > > I just rechecked the whole series patch version history from the cover-letter. And I have to respond again to your reply. > Just makes me wonder if I should wait for 3-4 pings + 2-3 weeks after > the last version of any of your patch set without any version bump > before I can look at it. I hope not. I think I not did rapid version respin. Otherwise it is quite impossible to match your > speed of patch respinning and the whole review process gets > complicated to follow. I'd argue for this. If you have read the cover-letter. https://lore.kernel.org/all/20240731-imx95-bbm-misc-v2-v7-0-a41394365602@xxxxxxx/ The patch version timeline is as below: v1: 2024-2-2 v2: 2024-4-5 v3: 2024-4-12 v4: 2024-5-24 v5: 2024-6-21 v6: 2024-7-18 v7: 2024-7-31 v2->v3 is 1 week, I admit this is short period. as you said, you not look into this patchset. It is almost 6 months, I not think it is a rapid patch version respin except that I did a quick update in v7 with just a minor R-b tag update after I reply in . > > Also it is bit sad that you thought it needs to be re-spinned just for this > which can be easily fixed when applying. I admit it is not good to just update R-b with a new version. But.. Also I haven't even started > looking at this series for the reason I mentioned above. > It is 6 months.. if just because I missed your 20mins reply, you think the whole patchset should be delayed or else, that is not fair, there must be some misunderstanding here. Thanks, Peng. > -- > Regards, > Sudeep
