All of lore.kernel.org
 help / color / mirror / Atom feed
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


WARNING: multiple messages have this Message-ID (diff)
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


_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

WARNING: multiple messages have this Message-ID (diff)
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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-10-12 10:29 UTC|newest]

Thread overview: 102+ 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 ` Sam Shih
2021-09-14  8:51 ` 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, 1/9] " Sam Shih
2021-09-14  8:51   ` Sam Shih
2021-09-14  8:51 ` [v3,2/9] clk: mediatek: add mt7986 clock IDs Sam Shih
2021-09-14  8:51   ` Sam Shih
2021-09-14  8:51   ` Sam Shih
2021-09-14  8:51 ` [RESEND,v2,3/9] clk: mediatek: add mt7986 clock support Sam Shih
2021-09-14  8:51   ` Sam Shih
2021-09-14  8:51   ` 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-14  8:51   ` [RESEND, v3, 4/9] " Sam Shih
2021-09-14  8:51   ` Sam Shih
2021-09-16 10:07   ` [RESEND,v3,4/9] " Linus Walleij
2021-09-16 10:07     ` Linus Walleij
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  8:51   ` Sam Shih
2021-09-14  8:51   ` Sam Shih
2021-09-14 18:00   ` Matthias Brugger
2021-09-14 18:00     ` Matthias Brugger
2021-09-14 18:00     ` Matthias Brugger
2021-09-24 11:44     ` [v4,5/9] " Sam Shih
2021-09-24 11:44       ` Sam Shih
2021-09-24 11:44       ` Sam Shih
2021-09-24 13:59       ` Rob Herring
2021-09-24 13:59         ` Rob Herring
2021-09-24 13:59         ` Rob Herring
2021-09-27  2:34         ` [v5,5/9] " Sam Shih
2021-09-27  2:34           ` Sam Shih
2021-09-27  2:34           ` Sam Shih
2021-09-27 12:23           ` Rob Herring
2021-09-27 12:23             ` Rob Herring
2021-09-27 12:23             ` Rob Herring
2021-10-04  9:41             ` [v6,5/9] " Sam Shih
2021-10-04  9:41               ` Sam Shih
2021-10-04  9:41               ` Sam Shih
2021-10-12  1:26               ` Rob Herring
2021-10-12  1:26                 ` Rob Herring
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   ` Sam Shih
2021-09-14  8:51   ` Sam Shih
2021-09-14  8:51 ` [RESEND,v2,7/9] dt-bindings: arm64: dts: mediatek: Add mt7986 series Sam Shih
2021-09-14  8:51   ` Sam Shih
2021-09-14  8:51   ` Sam Shih
2021-09-14 18:00   ` Matthias Brugger
2021-09-14 18:00     ` Matthias Brugger
2021-09-14 18:00     ` Matthias Brugger
2021-09-24 11:40     ` [v3,7/9] " Sam Shih
2021-09-24 11:40       ` Sam Shih
2021-09-24 11:40       ` Sam Shih
2021-10-08 13:53       ` Matthias Brugger
2021-10-08 13:53         ` Matthias Brugger
2021-10-08 13:53         ` Matthias Brugger
2021-10-12 10:29         ` Sam Shih [this message]
2021-10-12 10:29           ` Sam Shih
2021-10-12 10:29           ` Sam Shih
2021-10-13 16:08           ` Matthias Brugger
2021-10-13 16:08             ` Matthias Brugger
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  8:51   ` Sam Shih
2021-09-14  8:51   ` Sam Shih
2021-09-14 17:55   ` Matthias Brugger
2021-09-14 17:55     ` Matthias Brugger
2021-09-14 17:55     ` Matthias Brugger
2021-09-24 11:20     ` [v3,8/9] " Sam Shih
2021-09-24 11:20       ` Sam Shih
2021-09-24 11:20       ` Sam Shih
2021-09-27 12:41       ` Marc Zyngier
2021-09-27 12:41         ` Marc Zyngier
2021-09-27 12:41         ` Marc Zyngier
2021-10-04  9:12         ` [v4,8/9] " Sam Shih
2021-10-04  9:12           ` Sam Shih
2021-10-04  9:12           ` Sam Shih
2021-10-04 10:00           ` Marc Zyngier
2021-10-04 10:00             ` Marc Zyngier
2021-10-04 10:00             ` Marc Zyngier
2021-10-04 10:07           ` Marc Zyngier
2021-10-04 10:07             ` Marc Zyngier
2021-10-04 10:07             ` Marc Zyngier
2021-10-04 12:41             ` [v5,8/9] " Sam Shih
2021-10-04 12:41               ` Sam Shih
2021-10-04 12:41               ` Sam Shih
2021-09-14  8:51 ` [RESEND,v2,9/9] arm64: dts: mediatek: add mt7986b support Sam Shih
2021-09-14  8:51   ` Sam Shih
2021-09-14  8:51   ` Sam Shih
2021-09-24 11:27   ` [v3,9/9] " Sam Shih
2021-09-24 11:27     ` Sam Shih
2021-09-24 11:27     ` Sam Shih
2021-10-04  9:16     ` [v4,9/9] " Sam Shih
2021-10-04  9:16       ` Sam Shih
2021-10-04  9:16       ` Sam Shih
2021-10-04 10:09       ` Marc Zyngier
2021-10-04 10:09         ` Marc Zyngier
2021-10-04 10:09         ` Marc Zyngier
2021-10-04 12:42         ` [v5,9/9] " Sam Shih
2021-10-04 12:42           ` Sam Shih
2021-10-04 12:42           ` 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.