RE: [PATCH v6 1/7] dt-bindings: firmware: add i.MX95 SCMI Extension protocol

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux