linux-watchdog.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matthias Brugger <matthias.bgg@gmail.com>
To: Sam Shih <sam.shih@mediatek.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: Wed, 13 Oct 2021 18:08:17 +0200	[thread overview]
Message-ID: <8348ed3e-c561-ad7e-fe9e-a31ed346d8d0@gmail.com> (raw)
In-Reply-To: <315d7823aa108c909a3d36464fe54763b76ab2f4.camel@mediatek.com>

Hi Sam,

On 12/10/2021 12:29, Sam Shih wrote:
> 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 ?
> 

I'd use v4 keeping the change-log and adding a link with hint to v3 in the cover 
letter.

> Does the version number in corver-letter and the version number in each
> patch need to be the same in the entire patch series ?
> 

Yes, otherwise the version number doesn't make to much sense.

> // (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

use v6 explaining where in the mailing list one can find v5.

> 
> // (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
> 

Same here, use v4.

> // (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
> 

use v7 here.

>>
>> 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 ?
> 

Respond to any review comments in the thread but once you are ready to send a 
new version of the patch, send the whole series with an incremented

> 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)

beware: applied != accepted
reviewer != maintainer

if the patch got applied to some maintainer repo, then in the next version drop 
that patch (it is already applied) but mention that in the cover letter.

>    [PATCH v2 2/3] ...   (patch set v2, need to be upgrade to v3)
>    [PATCH v2 3/3] ...   (patch set v1, waiting for review)
> 

This series would be v3, if 1/3 is applied, drop. 2/3 will have changes and 3/3 
will be the same as in v2.

> 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)
> 

yes, that's how is expected you send your patches.

Let me know if you have any further questions :)

Regards,
Matthias

> 
>>
>> 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
> 

  reply	other threads:[~2021-10-13 16:08 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
2021-10-13 16:08           ` Matthias Brugger [this message]
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=8348ed3e-c561-ad7e-fe9e-a31ed346d8d0@gmail.com \
    --to=matthias.bgg@gmail.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=mpm@selenic.com \
    --cc=mturquette@baylibre.com \
    --cc=robh+dt@kernel.org \
    --cc=sam.shih@mediatek.com \
    --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).