Hi Sudeep, > 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. > > > > 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. Otherwise it is quite impossible to match your > speed of patch respinning and the whole review process gets > complicated to follow. I think you might be busy. So just after addressing Cristian's comments, I post a new version. Then I think Cristian's R-b is good enough for the patch to be queued into your tree. So I did not wait for your reply on previous patchset. I usually wait more than one week, near two weeks. If no comments, I will ping. > > Also it is bit sad that you thought it needs to be re-spinned just for this > which can be easily fixed when applying. Also I haven't even started > looking at this series for the reason I mentioned above. I did not intend to bring trouble for your reviewing. For future scmi related patches that I do, I will wait for two weeks to collect comments. If no comments, I will post a ping(if you have a patchwork queue to check, that would be better). I will wait for your reply before post a new version. But if Cristian's comments are enough for me to do new version after two weeks time window, that would also be good. I hope the upper approach is good for you. Thanks, Peng. > > -- > Regards, > Sudeep
