From: Sam Shih <sam.shih@mediatek.com>
To: Matthias Brugger <matthias.bgg@gmail.com>
Cc: <Ryder.Lee@mediatek.com>, <devicetree@vger.kernel.org>,
<enric.balletbo@collabora.com>, <fparent@baylibre.com>,
<gregkh@linuxfoundation.org>, <herbert@gondor.apana.org.au>,
<hsinyi@chromium.org>, <john@phrozen.org>,
<linus.walleij@linaro.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-clk@vger.kernel.org>, <linux-crypto@vger.kernel.org>,
<linux-gpio@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<linux-mediatek@lists.infradead.org>,
<linux-serial@vger.kernel.org>, <linux-watchdog@vger.kernel.org>,
<linux@roeck-us.net>, <mpm@selenic.com>,
<mturquette@baylibre.com>, <robh+dt@kernel.org>,
<sboyd@kernel.org>, <sean.wang@kernel.org>,
<seiya.wang@mediatek.com>, <wim@linux-watchdog.org>
Subject: Re: [v3,7/9] dt-bindings: arm64: dts: mediatek: Add mt7986 series
Date: Tue, 12 Oct 2021 18:29:28 +0800 [thread overview]
Message-ID: <315d7823aa108c909a3d36464fe54763b76ab2f4.camel@mediatek.com> (raw)
In-Reply-To: <bc29d5bc-9ce7-6147-a708-e6304249b600@gmail.com>
Hi
On Fri, 2021-10-08 at 15:53 +0200, Matthias Brugger wrote:
> Hi Sam,
>
> I'd advise to split this series in parts for:
> - basic device support via dts.
> - pinctrl driver + dts
> - clk driver + dts
Okay, I will split the patches that are still under review into the
above patch series.
But I have a dumb question, currently, we have some patches that have
been assigned version numbers.
If I want to seprate original patch series, and resend 3 new patch
series (basic / pinctrl / clock) according to your comment, if I want
to keep the preview change log, tags in the patch set:
like:
---
v3: changed 'MT7986' to 'MT7986 series' in the commit message
v2: added an Acked-by tag
---
Which version number should I use for these new patch series ?
Does the version number in corver-letter and the version number in each
patch need to be the same in the entire patch series ?
// (Original patch series/thread, version number is v3)
[PATCH v3 0/3] Add basic SoC support for mediatek mt7986
[PATCH v3 1/3] dt-bindings: arm64: dts: mediatek: Add mt7986 series
// (the version number has been updated to v5 previously)
// (basic part only, not include pinctrl and clock nodes)
[PATCH v5 2/3] arm64: dts: mediatek: add mt7986a support
[PATCH v5 3/3] arm64: dts: mediatek: add mt7986b support
// (New clock driver patch series)
[PATCH 0/3] Add clock driver support for mediatek mt7986
[PATCH v3,1/3] dt-bindings: clock: mediatek: document clk bindings
for mediatek mt7986 SoC
// (the version number has been updated to v3 previously)
[PATCH v3 2/3] clk: mediatek: add mt7986 clock IDs
[PATCH v2 3/3] clk: mediatek: add mt7986 clock support
// (New pinctrl driver patch series)
[PATCH 0/4] Add pinctrl driver support for mediatek mt7986
// (the version number has been updated to v6 previously)
[PATCH v6 1/4] dt-bindings: pinctrl: update bindings for MT7986 SoC
// (the version number has been updated to v2 previously)
[PATCH v2 2/4] pinctrl: mediatek: add support for MT7986 SoC
[PATCH 3/4] arm64: dts: mediatek: add mt7986a pinctrl support
[PATCH 3/4] arm64: dts: mediatek: add mt7986b pinctrl support
>
> I would also advise to not send new versions of patches as new
> threads and don't
> respond in the same thread. At least for me that breaks my workflow
> as I use b4.
If I don't respond to the next patch set in the same thread, should I
create an entire new patch series ?
For example, if I want to update PATCH 2/3 in the bellows patch series,
and my PATCH 1/3 has been accepted by reviewer previously
[PATCH v2 0/3] Add basic SoC support for mediatek mt7986
[PATCH v2 1/3] ... (patch set v1, applied by matainer)
[PATCH v2 2/3] ... (patch set v2, need to be upgrade to v3)
[PATCH v2 3/3] ... (patch set v1, waiting for review)
Is this correct to send patch mail to maintaiers for the above
situation ?
[PATCH v3 0/2] Add basic SoC support for mediatek mt7986
[PATCH v3 1/2] ... (patch set v3)
[PATCH v3 2/2] ... (still patch set v1, waiting for review)
>
> Regards,
> Matthias
>
>
> On 24/09/2021 13:40, Sam Shih wrote:
> > MT7986 series is Mediatek's new 4-core SoC, which is mainly for
> > wifi-router application. The difference between mt7986a and mt7986b
> > is that some pins do not exist on mt7986b.
> >
> > Signed-off-by: Sam Shih <sam.shih@mediatek.com>
> > Acked-by: Rob Herring <robh@kernel.org>
> >
> > ---
> > v3: changed 'MT7986' to 'MT7986 series' in the commit message
> > v2: added an Acked-by tag
> > ---
> > Documentation/devicetree/bindings/arm/mediatek.yaml | 8 ++++++++
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml
> > b/Documentation/devicetree/bindings/arm/mediatek.yaml
> > index 80a05f6fee85..a9a778269684 100644
> > --- a/Documentation/devicetree/bindings/arm/mediatek.yaml
> > +++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
> > @@ -76,6 +76,14 @@ properties:
> > - enum:
> > - mediatek,mt7629-rfb
> > - const: mediatek,mt7629
> > + - items:
> > + - enum:
> > + - mediatek,mt7986a-rfb
> > + - const: mediatek,mt7986a
> > + - items:
> > + - enum:
> > + - mediatek,mt7986b-rfb
> > + - const: mediatek,mt7986b
> > - items:
> > - enum:
> > - mediatek,mt8127-moose
> >
Thanks,
Sam
next prev parent reply other threads:[~2021-10-12 10:29 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-14 8:51 [v3,0/9] Add basic SoC support for mediatek mt7986 Sam Shih
2021-09-14 8:51 ` [v3,1/9] dt-bindings: clock: mediatek: document clk bindings for mediatek mt7986 SoC Sam Shih
2021-09-14 8:51 ` [v3,2/9] clk: mediatek: add mt7986 clock IDs Sam Shih
2021-09-14 8:51 ` [RESEND,v2,3/9] clk: mediatek: add mt7986 clock support Sam Shih
2021-09-14 8:51 ` [RESEND,v3,4/9] pinctrl: mediatek: moore: check if pin_desc is valid before use Sam Shih
2021-09-16 10:07 ` Linus Walleij
2021-09-14 8:51 ` [v3,5/9] dt-bindings: pinctrl: update bindings for MT7986 SoC Sam Shih
2021-09-14 18:00 ` Matthias Brugger
2021-09-24 11:44 ` [v4,5/9] " Sam Shih
2021-09-24 13:59 ` Rob Herring
2021-09-27 2:34 ` [v5,5/9] " Sam Shih
2021-09-27 12:23 ` Rob Herring
2021-10-04 9:41 ` [v6,5/9] " Sam Shih
2021-10-12 1:26 ` Rob Herring
2021-09-14 8:51 ` [v4,6/9] pinctrl: mediatek: add support " Sam Shih
2021-09-14 8:51 ` [RESEND,v2,7/9] dt-bindings: arm64: dts: mediatek: Add mt7986 series Sam Shih
2021-09-14 18:00 ` Matthias Brugger
2021-09-24 11:40 ` [v3,7/9] " Sam Shih
2021-10-08 13:53 ` Matthias Brugger
2021-10-12 10:29 ` Sam Shih [this message]
2021-10-13 16:08 ` Matthias Brugger
2021-09-14 8:51 ` [RESEND,v2,8/9] arm64: dts: mediatek: add mt7986a support Sam Shih
2021-09-14 17:55 ` Matthias Brugger
2021-09-24 11:20 ` [v3,8/9] " Sam Shih
2021-09-27 12:41 ` Marc Zyngier
2021-10-04 9:12 ` [v4,8/9] " Sam Shih
2021-10-04 10:00 ` Marc Zyngier
2021-10-04 10:07 ` Marc Zyngier
2021-10-04 12:41 ` [v5,8/9] " Sam Shih
2021-09-14 8:51 ` [RESEND,v2,9/9] arm64: dts: mediatek: add mt7986b support Sam Shih
2021-09-24 11:27 ` [v3,9/9] " Sam Shih
2021-10-04 9:16 ` [v4,9/9] " Sam Shih
2021-10-04 10:09 ` Marc Zyngier
2021-10-04 12:42 ` [v5,9/9] " Sam Shih
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=315d7823aa108c909a3d36464fe54763b76ab2f4.camel@mediatek.com \
--to=sam.shih@mediatek.com \
--cc=Ryder.Lee@mediatek.com \
--cc=devicetree@vger.kernel.org \
--cc=enric.balletbo@collabora.com \
--cc=fparent@baylibre.com \
--cc=gregkh@linuxfoundation.org \
--cc=herbert@gondor.apana.org.au \
--cc=hsinyi@chromium.org \
--cc=john@phrozen.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-serial@vger.kernel.org \
--cc=linux-watchdog@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=matthias.bgg@gmail.com \
--cc=mpm@selenic.com \
--cc=mturquette@baylibre.com \
--cc=robh+dt@kernel.org \
--cc=sboyd@kernel.org \
--cc=sean.wang@kernel.org \
--cc=seiya.wang@mediatek.com \
--cc=wim@linux-watchdog.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).