RE: [PATCH v6 1/7] dt-bindings: firmware: add i.MX95 SCMI Extension protocol
From: Peng Fan <peng.fan@nxp.com>
Date: 2024-08-06 14:04:44
Also in:
arm-scmi, imx, linux-devicetree, linux-input, linux-rtc, lkml
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:quoted
quoted
Subject: Re: [PATCH v6 1/7] dt-bindings: firmware: add i.MX95SCMIquoted
quoted
Extension protocol On Wed, Jul 31, 2024 at 12:18:28PM +0000, Peng Fan wrote:quoted
quoted
Subject: Re: [PATCH v6 1/7] dt-bindings: firmware: add i.MX95SCMIquoted
quoted
Extension protocol On 18/07/2024 09:41, Peng Fan (OSS) wrote:quoted
From: Peng Fan <peng.fan@nxp.com> Add i.MX SCMI Extension protocols bindings for: - Battery Backed Module(BBM) Protocol This contains persistent storage (GPR), an RTC, and the ON/OFFbutton.quoted
The protocol can also provide access to similar functionsimplemented viaquoted
external board components. - MISC Protocol. This includes controls that are misc settings/actions that must beexposedquoted
from the SM to agents. They are device specific and are usuallydefine toquoted
access bit fields in various mix block control modules, IOMUX_GPR,andquoted
other GPR/CSR owned by the SM. Reviewed-by: "Rob Herring (Arm)" <robh@kernel.org>Why quotes? Which tools did you use?I could not recall why have this. I will drop and resend thepatchset.quoted
quoted
quoted
Resend only if you have any other comments addressed, no spinjustquoted
quoted
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@nxp.com/ (local) 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