All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicolas Boichat <drinkcat@chromium.org>
To: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Cc: lkml <linux-kernel@vger.kernel.org>,
	Collabora Kernel ML <kernel@collabora.com>,
	Fabien Parent <fparent@baylibre.com>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Hsin-Yi Wang <hsinyi@chromium.org>,
	Weiyi Lu <weiyi.lu@mediatek.com>,
	Matthias Brugger <mbrugger@suse.com>,
	linux-arm Mailing List <linux-arm-kernel@lists.infradead.org>,
	"moderated list:ARM/Mediatek SoC support" 
	<linux-mediatek@lists.infradead.org>
Subject: Re: [PATCH v2 02/12] soc: mediatek: Add MediaTek SCPSYS power domains
Date: Wed, 28 Oct 2020 09:13:23 +0800	[thread overview]
Message-ID: <CANMq1KDJPqiyXJKyeER7rSVbu7VxAcvrcV8rxDLMV+VEyx-Xmg@mail.gmail.com> (raw)
In-Reply-To: <2e6def0a-400c-836f-ef8b-c4fe6ac6c26e@collabora.com>

On Wed, Oct 28, 2020 at 12:25 AM Enric Balletbo i Serra
<enric.balletbo@collabora.com> wrote:
>
> Hi Nicolas,
>
> On 27/10/20 1:19, Nicolas Boichat wrote:
> > Hi Enric,
> >
> > On Mon, Oct 26, 2020 at 11:17 PM Enric Balletbo i Serra
> > <enric.balletbo@collabora.com> wrote:
> >>
> >> Hi Nicolas,
> >>
> >> Many thanks for looking at this.
> >
> > Thanks to you ,-)
> >
> > [snip]
> >>>> +       if (id >= scpsys->soc_data->num_domains) {
> >>>> +               dev_err_probe(scpsys->dev, -EINVAL, "%pOFn: invalid domain id %d\n", node, id);
> >>>> +               return -EINVAL;
> >>>> +       }
> >>>> +
> >>>> +       domain_data = &scpsys->soc_data->domains[id];
> >>>> +       if (!domain_data) {
> >>>
> >>> Is that even possible at all? I mean, even if
> >>> scpsys->soc_data->domains is NULL, as long as id != 0, this will no
> >>> happen.
> >>>
> >>
> >> I think could happen with a bad DT definition. I.e if for the definition of the
> >> MT8173 domains you use a wrong value for the reg property, a value that is not
> >> present in the SoC data. It is unlikely if you use the defines but could happen
> >> if you hardcore the value. We cannot check this with the DT json-schema.
> >
> > I wasn't clear in my explanation, and looking further there is more
> > that looks wrong.
> >
> > This expression &scpsys->soc_data->domains[id] is a pointer to element
> > "id" of the array domains. So if you convert to integer arithmetic,
> > it'll be something like `(long)scpsys->soc_data->domains +
> > (sizeof(struct generic_pm_domain *)) * id`. The only way this can be
> > NULL is if scpsys->soc_data->domains pointer is NULL, which, actually,
> > can't really happen as it's the 5th element of a struct scpsys
> > structure `(long)scpsys->soc_data + offset_of(domains, struct scpsys)
> > + (sizeof(struct generic_pm_domain *)) * id`.
> >
> > I think what you mean is either:
> > domain_data = &scpsys->soc_data->domains[id];
> > if (!*domain_data)
> > [but then domain_data type should be `struct generic_pm_domain **`?
>
> I think you're confusing the field `struct generic_pm_domain *domains[]`from the
> `struct scpsys` with `const struct scpsys_domain_data *domains` from `struct
> scpsys_soc_data`. My bad they have the same name, I should probably rename the
> second one as domain_info or domain_data to avoid that confusion.

Oh, okay, get it, thanks for clarifying, I got myself confused indeed ,-P

But, still, part of my integer arithmetics still holds...

&scpsys->soc_data->domains[id] = (long)scpsys->soc_data->domains +
(sizeof(struct generic_pm_domain *)) * id. The only way domain_data
can be NULL is if scpsys->soc_data->domains pointer is NULL (it can't
be, really, assuming scpsys_soc_data structures are well defined) AND
id is 0.

Now, if I understand what you want to check here. If a domain id is
not specified in scpsys_domain_data (e.g. if there is a gap in
MT8XXX_POWER_DOMAIN_YYY indices and if `id` points at one of those
gaps), you'll get an all-zero entry in domain_data. So maybe you can
just check that domain_data->sta_mask != 0? Would that be enough? (I
expect that sta_mask would always need to be set?)

But then again, are there ever gaps in MT8XXX_POWER_DOMAIN_YYY indices?

>
>
> diff --git a/drivers/soc/mediatek/mtk-pm-domains.h
> b/drivers/soc/mediatek/mtk-pm-domains.h
> index 7c8efcb3cef2..6ff095db8a27 100644
> --- a/drivers/soc/mediatek/mtk-pm-domains.h
> +++ b/drivers/soc/mediatek/mtk-pm-domains.h
> @@ -56,7 +56,7 @@ struct scpsys_domain_data {
>  };
>
>  struct scpsys_soc_data {
> -       const struct scpsys_domain_data *domains;
> +       const struct scpsys_domain_data *domain_data;
>         int num_domains;
>         int pwr_sta_offs;
>         int pwr_sta2nd_offs;
>
> ---
>
> struct scpsys {
>     ...
>     const struct scpsys_soc_data *soc_data;
>     ...
>     struct generic_pm_domain *domains[];
> }
>
>
> domain_data = &scpsys->soc_data->domain_data[id];
> if (!domain_data)
>
> Thanks,
>   Enric
>
>
> > Does your code compile with warnings enabled?]
> > or:
> > domain_data = scpsys->soc_data->domains[id];
> > if (!domain_data)
> > [then the test makes sense]
> >
> > [snip]
> >

WARNING: multiple messages have this Message-ID (diff)
From: Nicolas Boichat <drinkcat@chromium.org>
To: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Cc: Matthias Brugger <mbrugger@suse.com>,
	Weiyi Lu <weiyi.lu@mediatek.com>,
	lkml <linux-kernel@vger.kernel.org>,
	Fabien Parent <fparent@baylibre.com>,
	"moderated list:ARM/Mediatek SoC support"
	<linux-mediatek@lists.infradead.org>,
	Hsin-Yi Wang <hsinyi@chromium.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Collabora Kernel ML <kernel@collabora.com>,
	linux-arm Mailing List <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2 02/12] soc: mediatek: Add MediaTek SCPSYS power domains
Date: Wed, 28 Oct 2020 09:13:23 +0800	[thread overview]
Message-ID: <CANMq1KDJPqiyXJKyeER7rSVbu7VxAcvrcV8rxDLMV+VEyx-Xmg@mail.gmail.com> (raw)
In-Reply-To: <2e6def0a-400c-836f-ef8b-c4fe6ac6c26e@collabora.com>

On Wed, Oct 28, 2020 at 12:25 AM Enric Balletbo i Serra
<enric.balletbo@collabora.com> wrote:
>
> Hi Nicolas,
>
> On 27/10/20 1:19, Nicolas Boichat wrote:
> > Hi Enric,
> >
> > On Mon, Oct 26, 2020 at 11:17 PM Enric Balletbo i Serra
> > <enric.balletbo@collabora.com> wrote:
> >>
> >> Hi Nicolas,
> >>
> >> Many thanks for looking at this.
> >
> > Thanks to you ,-)
> >
> > [snip]
> >>>> +       if (id >= scpsys->soc_data->num_domains) {
> >>>> +               dev_err_probe(scpsys->dev, -EINVAL, "%pOFn: invalid domain id %d\n", node, id);
> >>>> +               return -EINVAL;
> >>>> +       }
> >>>> +
> >>>> +       domain_data = &scpsys->soc_data->domains[id];
> >>>> +       if (!domain_data) {
> >>>
> >>> Is that even possible at all? I mean, even if
> >>> scpsys->soc_data->domains is NULL, as long as id != 0, this will no
> >>> happen.
> >>>
> >>
> >> I think could happen with a bad DT definition. I.e if for the definition of the
> >> MT8173 domains you use a wrong value for the reg property, a value that is not
> >> present in the SoC data. It is unlikely if you use the defines but could happen
> >> if you hardcore the value. We cannot check this with the DT json-schema.
> >
> > I wasn't clear in my explanation, and looking further there is more
> > that looks wrong.
> >
> > This expression &scpsys->soc_data->domains[id] is a pointer to element
> > "id" of the array domains. So if you convert to integer arithmetic,
> > it'll be something like `(long)scpsys->soc_data->domains +
> > (sizeof(struct generic_pm_domain *)) * id`. The only way this can be
> > NULL is if scpsys->soc_data->domains pointer is NULL, which, actually,
> > can't really happen as it's the 5th element of a struct scpsys
> > structure `(long)scpsys->soc_data + offset_of(domains, struct scpsys)
> > + (sizeof(struct generic_pm_domain *)) * id`.
> >
> > I think what you mean is either:
> > domain_data = &scpsys->soc_data->domains[id];
> > if (!*domain_data)
> > [but then domain_data type should be `struct generic_pm_domain **`?
>
> I think you're confusing the field `struct generic_pm_domain *domains[]`from the
> `struct scpsys` with `const struct scpsys_domain_data *domains` from `struct
> scpsys_soc_data`. My bad they have the same name, I should probably rename the
> second one as domain_info or domain_data to avoid that confusion.

Oh, okay, get it, thanks for clarifying, I got myself confused indeed ,-P

But, still, part of my integer arithmetics still holds...

&scpsys->soc_data->domains[id] = (long)scpsys->soc_data->domains +
(sizeof(struct generic_pm_domain *)) * id. The only way domain_data
can be NULL is if scpsys->soc_data->domains pointer is NULL (it can't
be, really, assuming scpsys_soc_data structures are well defined) AND
id is 0.

Now, if I understand what you want to check here. If a domain id is
not specified in scpsys_domain_data (e.g. if there is a gap in
MT8XXX_POWER_DOMAIN_YYY indices and if `id` points at one of those
gaps), you'll get an all-zero entry in domain_data. So maybe you can
just check that domain_data->sta_mask != 0? Would that be enough? (I
expect that sta_mask would always need to be set?)

But then again, are there ever gaps in MT8XXX_POWER_DOMAIN_YYY indices?

>
>
> diff --git a/drivers/soc/mediatek/mtk-pm-domains.h
> b/drivers/soc/mediatek/mtk-pm-domains.h
> index 7c8efcb3cef2..6ff095db8a27 100644
> --- a/drivers/soc/mediatek/mtk-pm-domains.h
> +++ b/drivers/soc/mediatek/mtk-pm-domains.h
> @@ -56,7 +56,7 @@ struct scpsys_domain_data {
>  };
>
>  struct scpsys_soc_data {
> -       const struct scpsys_domain_data *domains;
> +       const struct scpsys_domain_data *domain_data;
>         int num_domains;
>         int pwr_sta_offs;
>         int pwr_sta2nd_offs;
>
> ---
>
> struct scpsys {
>     ...
>     const struct scpsys_soc_data *soc_data;
>     ...
>     struct generic_pm_domain *domains[];
> }
>
>
> domain_data = &scpsys->soc_data->domain_data[id];
> if (!domain_data)
>
> Thanks,
>   Enric
>
>
> > Does your code compile with warnings enabled?]
> > or:
> > domain_data = scpsys->soc_data->domains[id];
> > if (!domain_data)
> > [then the test makes sense]
> >
> > [snip]
> >

_______________________________________________
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: Nicolas Boichat <drinkcat@chromium.org>
To: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Cc: Matthias Brugger <mbrugger@suse.com>,
	Weiyi Lu <weiyi.lu@mediatek.com>,
	lkml <linux-kernel@vger.kernel.org>,
	Fabien Parent <fparent@baylibre.com>,
	"moderated list:ARM/Mediatek SoC support"
	<linux-mediatek@lists.infradead.org>,
	Hsin-Yi Wang <hsinyi@chromium.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Collabora Kernel ML <kernel@collabora.com>,
	linux-arm Mailing List <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2 02/12] soc: mediatek: Add MediaTek SCPSYS power domains
Date: Wed, 28 Oct 2020 09:13:23 +0800	[thread overview]
Message-ID: <CANMq1KDJPqiyXJKyeER7rSVbu7VxAcvrcV8rxDLMV+VEyx-Xmg@mail.gmail.com> (raw)
In-Reply-To: <2e6def0a-400c-836f-ef8b-c4fe6ac6c26e@collabora.com>

On Wed, Oct 28, 2020 at 12:25 AM Enric Balletbo i Serra
<enric.balletbo@collabora.com> wrote:
>
> Hi Nicolas,
>
> On 27/10/20 1:19, Nicolas Boichat wrote:
> > Hi Enric,
> >
> > On Mon, Oct 26, 2020 at 11:17 PM Enric Balletbo i Serra
> > <enric.balletbo@collabora.com> wrote:
> >>
> >> Hi Nicolas,
> >>
> >> Many thanks for looking at this.
> >
> > Thanks to you ,-)
> >
> > [snip]
> >>>> +       if (id >= scpsys->soc_data->num_domains) {
> >>>> +               dev_err_probe(scpsys->dev, -EINVAL, "%pOFn: invalid domain id %d\n", node, id);
> >>>> +               return -EINVAL;
> >>>> +       }
> >>>> +
> >>>> +       domain_data = &scpsys->soc_data->domains[id];
> >>>> +       if (!domain_data) {
> >>>
> >>> Is that even possible at all? I mean, even if
> >>> scpsys->soc_data->domains is NULL, as long as id != 0, this will no
> >>> happen.
> >>>
> >>
> >> I think could happen with a bad DT definition. I.e if for the definition of the
> >> MT8173 domains you use a wrong value for the reg property, a value that is not
> >> present in the SoC data. It is unlikely if you use the defines but could happen
> >> if you hardcore the value. We cannot check this with the DT json-schema.
> >
> > I wasn't clear in my explanation, and looking further there is more
> > that looks wrong.
> >
> > This expression &scpsys->soc_data->domains[id] is a pointer to element
> > "id" of the array domains. So if you convert to integer arithmetic,
> > it'll be something like `(long)scpsys->soc_data->domains +
> > (sizeof(struct generic_pm_domain *)) * id`. The only way this can be
> > NULL is if scpsys->soc_data->domains pointer is NULL, which, actually,
> > can't really happen as it's the 5th element of a struct scpsys
> > structure `(long)scpsys->soc_data + offset_of(domains, struct scpsys)
> > + (sizeof(struct generic_pm_domain *)) * id`.
> >
> > I think what you mean is either:
> > domain_data = &scpsys->soc_data->domains[id];
> > if (!*domain_data)
> > [but then domain_data type should be `struct generic_pm_domain **`?
>
> I think you're confusing the field `struct generic_pm_domain *domains[]`from the
> `struct scpsys` with `const struct scpsys_domain_data *domains` from `struct
> scpsys_soc_data`. My bad they have the same name, I should probably rename the
> second one as domain_info or domain_data to avoid that confusion.

Oh, okay, get it, thanks for clarifying, I got myself confused indeed ,-P

But, still, part of my integer arithmetics still holds...

&scpsys->soc_data->domains[id] = (long)scpsys->soc_data->domains +
(sizeof(struct generic_pm_domain *)) * id. The only way domain_data
can be NULL is if scpsys->soc_data->domains pointer is NULL (it can't
be, really, assuming scpsys_soc_data structures are well defined) AND
id is 0.

Now, if I understand what you want to check here. If a domain id is
not specified in scpsys_domain_data (e.g. if there is a gap in
MT8XXX_POWER_DOMAIN_YYY indices and if `id` points at one of those
gaps), you'll get an all-zero entry in domain_data. So maybe you can
just check that domain_data->sta_mask != 0? Would that be enough? (I
expect that sta_mask would always need to be set?)

But then again, are there ever gaps in MT8XXX_POWER_DOMAIN_YYY indices?

>
>
> diff --git a/drivers/soc/mediatek/mtk-pm-domains.h
> b/drivers/soc/mediatek/mtk-pm-domains.h
> index 7c8efcb3cef2..6ff095db8a27 100644
> --- a/drivers/soc/mediatek/mtk-pm-domains.h
> +++ b/drivers/soc/mediatek/mtk-pm-domains.h
> @@ -56,7 +56,7 @@ struct scpsys_domain_data {
>  };
>
>  struct scpsys_soc_data {
> -       const struct scpsys_domain_data *domains;
> +       const struct scpsys_domain_data *domain_data;
>         int num_domains;
>         int pwr_sta_offs;
>         int pwr_sta2nd_offs;
>
> ---
>
> struct scpsys {
>     ...
>     const struct scpsys_soc_data *soc_data;
>     ...
>     struct generic_pm_domain *domains[];
> }
>
>
> domain_data = &scpsys->soc_data->domain_data[id];
> if (!domain_data)
>
> Thanks,
>   Enric
>
>
> > Does your code compile with warnings enabled?]
> > or:
> > domain_data = scpsys->soc_data->domains[id];
> > if (!domain_data)
> > [then the test makes sense]
> >
> > [snip]
> >

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

  reply	other threads:[~2020-10-29  0:48 UTC|newest]

Thread overview: 89+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-01 16:01 [PATCH v2 00/12] soc: mediatek: pm-domains: Add new driver for SCPSYS power domains controller Enric Balletbo i Serra
2020-10-01 16:01 ` Enric Balletbo i Serra
2020-10-01 16:01 ` Enric Balletbo i Serra
2020-10-01 16:01 ` [PATCH v2 01/12] dt-bindings: power: Add bindings for the Mediatek " Enric Balletbo i Serra
2020-10-01 16:01   ` Enric Balletbo i Serra
2020-10-01 16:01   ` Enric Balletbo i Serra
2020-10-01 16:01 ` [PATCH v2 02/12] soc: mediatek: Add MediaTek SCPSYS power domains Enric Balletbo i Serra
2020-10-01 16:01   ` Enric Balletbo i Serra
2020-10-01 16:01   ` Enric Balletbo i Serra
2020-10-05  1:39   ` Nicolas Boichat
2020-10-05  1:39     ` Nicolas Boichat
2020-10-05  1:39     ` Nicolas Boichat
2020-10-26 15:17     ` Enric Balletbo i Serra
2020-10-26 15:17       ` Enric Balletbo i Serra
2020-10-26 15:17       ` Enric Balletbo i Serra
2020-10-27  0:19       ` Nicolas Boichat
2020-10-27  0:19         ` Nicolas Boichat
2020-10-27  0:19         ` Nicolas Boichat
2020-10-27 16:25         ` Enric Balletbo i Serra
2020-10-27 16:25           ` Enric Balletbo i Serra
2020-10-27 16:25           ` Enric Balletbo i Serra
2020-10-28  1:13           ` Nicolas Boichat [this message]
2020-10-28  1:13             ` Nicolas Boichat
2020-10-28  1:13             ` Nicolas Boichat
2020-10-30 10:29             ` Enric Balletbo i Serra
2020-10-30 10:29               ` Enric Balletbo i Serra
2020-10-30 10:29               ` Enric Balletbo i Serra
2020-10-30 12:44               ` Nicolas Boichat
2020-10-30 12:44                 ` Nicolas Boichat
2020-10-30 12:44                 ` Nicolas Boichat
2020-10-01 16:01 ` [PATCH v2 03/12] arm64: dts: mediatek: Add mt8173 power domain controller Enric Balletbo i Serra
2020-10-01 16:01   ` Enric Balletbo i Serra
2020-10-01 16:01   ` Enric Balletbo i Serra
2020-10-01 16:01 ` [PATCH v2 04/12] soc: mediatek: pm-domains: Add bus protection protocol Enric Balletbo i Serra
2020-10-01 16:01   ` Enric Balletbo i Serra
2020-10-01 16:01   ` Enric Balletbo i Serra
2020-10-01 16:01 ` [PATCH v2 05/12] soc: mediatek: pm_domains: Make bus protection generic Enric Balletbo i Serra
2020-10-01 16:01   ` Enric Balletbo i Serra
2020-10-01 16:01   ` Enric Balletbo i Serra
2020-10-01 16:01 ` [PATCH v2 06/12] soc: mediatek: pm-domains: Add SMI block as bus protection block Enric Balletbo i Serra
2020-10-01 16:01   ` Enric Balletbo i Serra
2020-10-01 16:01   ` Enric Balletbo i Serra
2020-10-02  8:56   ` Matthias Brugger
2020-10-02  8:56     ` Matthias Brugger
2020-10-02  8:56     ` Matthias Brugger
2020-10-05  1:48     ` Nicolas Boichat
2020-10-05  1:48       ` Nicolas Boichat
2020-10-05  1:48       ` Nicolas Boichat
2020-10-05 10:28       ` Matthias Brugger
2020-10-05 10:28         ` Matthias Brugger
2020-10-05 10:28         ` Matthias Brugger
2020-10-26 15:18       ` Enric Balletbo i Serra
2020-10-26 15:18         ` Enric Balletbo i Serra
2020-10-26 15:18         ` Enric Balletbo i Serra
2020-10-26 15:18     ` Enric Balletbo i Serra
2020-10-26 15:18       ` Enric Balletbo i Serra
2020-10-26 15:18       ` Enric Balletbo i Serra
2020-10-01 16:01 ` [PATCH v2 07/12] soc: mediatek: pm-domains: Add extra sram control Enric Balletbo i Serra
2020-10-01 16:01   ` Enric Balletbo i Serra
2020-10-01 16:01   ` Enric Balletbo i Serra
2020-10-02  9:24   ` Matthias Brugger
2020-10-02  9:24     ` Matthias Brugger
2020-10-02  9:24     ` Matthias Brugger
2020-10-01 16:01 ` [PATCH v2 08/12] soc: mediatek: pm-domains: Add subsystem clocks Enric Balletbo i Serra
2020-10-01 16:01   ` Enric Balletbo i Serra
2020-10-01 16:01   ` Enric Balletbo i Serra
2020-10-02  9:04   ` Matthias Brugger
2020-10-02  9:04     ` Matthias Brugger
2020-10-02  9:04     ` Matthias Brugger
2020-10-26 15:17     ` Enric Balletbo i Serra
2020-10-26 15:17       ` Enric Balletbo i Serra
2020-10-26 15:17       ` Enric Balletbo i Serra
2020-10-01 16:01 ` [PATCH v2 09/12] soc: mediatek: pm-domains: Allow bus protection to ignore clear ack Enric Balletbo i Serra
2020-10-01 16:01   ` Enric Balletbo i Serra
2020-10-01 16:01   ` Enric Balletbo i Serra
2020-10-01 16:01 ` [PATCH v2 10/12] dt-bindings: power: Add MT8183 power domains Enric Balletbo i Serra
2020-10-01 16:01   ` Enric Balletbo i Serra
2020-10-01 16:01   ` Enric Balletbo i Serra
2020-10-01 16:01 ` [PATCH v2 11/12] soc: mediatek: pm-domains: Add support for mt8183 Enric Balletbo i Serra
2020-10-01 16:01   ` Enric Balletbo i Serra
2020-10-01 16:01   ` Enric Balletbo i Serra
2020-10-01 16:01 ` [PATCH v2 12/12] arm64: dts: mediatek: Add mt8183 power domains controller Enric Balletbo i Serra
2020-10-01 16:01   ` Enric Balletbo i Serra
2020-10-01 16:01   ` Enric Balletbo i Serra
2020-10-02  9:11   ` Matthias Brugger
2020-10-02  9:11     ` Matthias Brugger
2020-10-02  9:11     ` Matthias Brugger
2020-10-11 14:55   ` kernel test robot
2020-10-11 14:55     ` kernel test robot

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=CANMq1KDJPqiyXJKyeER7rSVbu7VxAcvrcV8rxDLMV+VEyx-Xmg@mail.gmail.com \
    --to=drinkcat@chromium.org \
    --cc=enric.balletbo@collabora.com \
    --cc=fparent@baylibre.com \
    --cc=hsinyi@chromium.org \
    --cc=kernel@collabora.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=matthias.bgg@gmail.com \
    --cc=mbrugger@suse.com \
    --cc=weiyi.lu@mediatek.com \
    /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.