All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Schneider-Pargmann <msp@baylibre.com>
To: AngeloGioacchino Del Regno  <angelogioacchino.delregno@collabora.com>
Cc: Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Weiyi Lu <weiyi.lu@mediatek.com>,
	Fabien Parent <parent.f@gmail.com>,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org,
	Alexandre Bailon <abailon@baylibre.com>,
	Fabien Parent <fparent@baylibre.com>
Subject: Re: [PATCH v2 2/4] soc: mediatek: Add support of WAY_EN operations
Date: Fri, 19 Aug 2022 14:42:06 +0200	[thread overview]
Message-ID: <20220819124206.kwp6ammicyy4z3jb@blmsp> (raw)
In-Reply-To: <dccc2863-a9db-d9ea-01e1-a18cf0db1d1e@collabora.com>

Hi Angelo,

Thanks for your review, I fixed most, comments inline.

On Mon, Jul 25, 2022 at 11:55:27AM +0200, AngeloGioacchino Del Regno wrote:
> Il 25/07/22 10:18, Markus Schneider-Pargmann ha scritto:
> > From: Alexandre Bailon <abailon@baylibre.com>
> > 
> > This updates the power domain to support WAY_EN operations. These
> > operations enable a path between different units of the chip and are
> > labeled as 'way_en' in the register descriptions.
> > 
> > This operation is required by the mt8365 for the MM power domain.
> > 
> > Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
> > Signed-off-by: Fabien Parent <fparent@baylibre.com>
> > Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
> > ---
> > 
> > Notes:
> >      Changes in v2:
> >      - some minor style fixes.
> >      - Renamed 'wayen' to 'way_en' to clarify the meaning
> >      - Updated commit message
> > 
> >   drivers/soc/mediatek/mtk-pm-domains.c | 64 +++++++++++++++++++++------
> >   drivers/soc/mediatek/mtk-pm-domains.h | 28 +++++++-----
> >   2 files changed, 68 insertions(+), 24 deletions(-)
> > 
> > diff --git a/drivers/soc/mediatek/mtk-pm-domains.c b/drivers/soc/mediatek/mtk-pm-domains.c
> > index 5ced254b082b..d0eae2227813 100644
> > --- a/drivers/soc/mediatek/mtk-pm-domains.c
> > +++ b/drivers/soc/mediatek/mtk-pm-domains.c
> > @@ -44,6 +44,7 @@ struct scpsys_domain {
> >   	struct clk_bulk_data *subsys_clks;
> >   	struct regmap *infracfg;
> >   	struct regmap *smi;
> > +	struct regmap *infracfg_nao;
> 
> What does "nao" mean?

I couldn't find the meaning of nao right now. It is the name of the
infracfg node in the datasheet. The normal one is called 'infracfg_ao'
the other one 'infracfg_nao' as far as I can see.

> 
> Besides, please move that before *infracfg to at least keep the same type members
> alphabetically sorted..
> 
> >   	struct regulator *supply;
> >   };
> > @@ -116,23 +117,38 @@ static int scpsys_sram_disable(struct scpsys_domain *pd)
> >   					MTK_POLL_TIMEOUT);
> >   }
> > -static int _scpsys_bus_protect_enable(const struct scpsys_bus_prot_data *bpd, struct regmap *regmap)
> > +static int _scpsys_bus_protect_enable(const struct scpsys_bus_prot_data *bpd,
> > +				      struct regmap *regmap, struct regmap *infracfg_nao)
> >   {
> >   	int i, ret;
> >   	for (i = 0; i < SPM_MAX_BUS_PROT_DATA; i++) {
> > -		u32 val, mask = bpd[i].bus_prot_mask;
> > +		u32 mask = bpd[i].bus_prot_mask;
> > +		u32 val = mask, sta_mask = mask;
> 
> You have modified the macros to use sta_mask as mask, so, why are you doing
> that distinction in here between the two? You can simply keep assigning
> 
> 		u32 mask = bpd[1].bus_prot_mask;
> 		u32 sta_mask = bpd[1].bus_prot_sta_mask;
> 
> > +		struct regmap *ack_regmap = regmap;
> 
> Double assignment. You're reassigning this if way_en == true.
> 
> >   		if (!mask)
> >   			break;
> > +		if (bpd[i].way_en) {
> > +			if (!infracfg_nao)
> > +				return -ENODEV;
> > +
> > +			val = 0;
> > +			sta_mask = bpd[i].bus_prot_sta_mask;
> > +			ack_regmap = infracfg_nao;
> > +		}
> 
> 		if (bpd[i].way_en) {
> 			ack_regmap = regmap_nao;
> 			val = 0;
> 		} else {
> 			ack_regmap = regmap;
> 			val = mask;
> 		}
> 
> > +
> >   		if (bpd[i].bus_prot_reg_update)
> > -			regmap_set_bits(regmap, bpd[i].bus_prot_set, mask);
> > +			regmap_update_bits(regmap, bpd[i].bus_prot_set, mask, val);
> >   		else
> >   			regmap_write(regmap, bpd[i].bus_prot_set, mask);
> > -		ret = regmap_read_poll_timeout(regmap, bpd[i].bus_prot_sta,
> > -					       val, (val & mask) == mask,
> > +		if (bpd[i].ignore_clr_ack)
> > +			continue;
> 
> You're adding that ignore_clr_ack here in the bus prot enablement function
> which wasn't here before... and I didn't check carefully, but I think that
> this is wrong: as the name says, it's to "ignore CLEAR ack", we're not doing
> any clearing here, we're not in bus_protect_disable.
> 
> If you're really sure that this is not a mistake, you should guard it for way_en.

We are clearing bits here if way_en is true and bus_prot_reg_update is
true as well. Then val=0 and regmap_update_bits(..., mask, val) will
clear the bits given in mask. And yes either way_en or val==0 should
probably be checked here. Thanks.

> 
> > +
> > +		ret = regmap_read_poll_timeout(ack_regmap, bpd[i].bus_prot_sta,
> > +					       val, (val & sta_mask) == sta_mask,
> >   					       MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
> >   		if (ret)
> >   			return ret;
> > @@ -145,34 +161,49 @@ static int scpsys_bus_protect_enable(struct scpsys_domain *pd)
> >   {
> >   	int ret;
> > -	ret = _scpsys_bus_protect_enable(pd->data->bp_infracfg, pd->infracfg);
> > +	ret = _scpsys_bus_protect_enable(pd->data->bp_infracfg,
> > +					 pd->infracfg, pd->infracfg_nao);
> >   	if (ret)
> >   		return ret;
> > -	return _scpsys_bus_protect_enable(pd->data->bp_smi, pd->smi);
> > +	return _scpsys_bus_protect_enable(pd->data->bp_smi, pd->smi, NULL);
> >   }
> > +#define mask_cond(way_en, val, mask) \
> > +	((way_en && ((val & mask) == mask)) || (!way_en && !(val & mask)))
> > +
> >   static int _scpsys_bus_protect_disable(const struct scpsys_bus_prot_data *bpd,
> > -				       struct regmap *regmap)
> > +				       struct regmap *regmap, struct regmap *infracfg_nao)
> >   {
> >   	int i, ret;
> >   	for (i = SPM_MAX_BUS_PROT_DATA - 1; i >= 0; i--) {
> > -		u32 val, mask = bpd[i].bus_prot_mask;
> > +		u32 val = 0, mask = bpd[i].bus_prot_mask;
> > +		u32 sta_mask = mask;
> > +		struct regmap *ack_regmap = regmap;
> >   		if (!mask)
> >   			continue;
> > +		if (bpd[i].way_en) {
> > +			if (!infracfg_nao)
> > +				return -ENODEV;
> > +
> > +			val = mask;
> > +			sta_mask = bpd[i].bus_prot_sta_mask;
> > +			ack_regmap = infracfg_nao;
> > +		}
> > +
> >   		if (bpd[i].bus_prot_reg_update)
> > -			regmap_clear_bits(regmap, bpd[i].bus_prot_clr, mask);
> > +			regmap_update_bits(regmap, bpd[i].bus_prot_clr, mask, val);
> >   		else
> >   			regmap_write(regmap, bpd[i].bus_prot_clr, mask);
> >   		if (bpd[i].ignore_clr_ack)
> >   			continue;
> > -		ret = regmap_read_poll_timeout(regmap, bpd[i].bus_prot_sta,
> > -					       val, !(val & mask),
> > +		ret = regmap_read_poll_timeout(ack_regmap, bpd[i].bus_prot_sta,
> > +					       val, mask_cond(bpd[i].way_en, val, sta_mask),
> 
> "I don't know why", my brain still keeps telling me that using different functions
> for the WAY_EN (en/dis) is just better.
> 
> This commit seems to be overcomplicating two "easy" en/dis functions.

Looking at the code again, I think you are right. I redesigned basically
this whole patch, and I think it is easier to understand now.
> 
> >   					       MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
> >   		if (ret)
> >   			return ret;
> > @@ -185,11 +216,12 @@ static int scpsys_bus_protect_disable(struct scpsys_domain *pd)
> >   {
> >   	int ret;
> > -	ret = _scpsys_bus_protect_disable(pd->data->bp_smi, pd->smi);
> > +	ret = _scpsys_bus_protect_disable(pd->data->bp_smi, pd->smi, NULL);
> >   	if (ret)
> >   		return ret;
> > -	return _scpsys_bus_protect_disable(pd->data->bp_infracfg, pd->infracfg);
> > +	return _scpsys_bus_protect_disable(pd->data->bp_infracfg,
> > +			pd->infracfg, pd->infracfg_nao);
> >   }
> >   static int scpsys_regulator_enable(struct regulator *supply)
> > @@ -363,6 +395,10 @@ generic_pm_domain *scpsys_add_one_domain(struct scpsys *scpsys, struct device_no
> >   			return ERR_CAST(pd->smi);
> >   	}
> > +	pd->infracfg_nao = syscon_regmap_lookup_by_phandle_optional(node, "mediatek,infracfg_nao");
> > +	if (IS_ERR(pd->infracfg_nao))
> > +		return ERR_CAST(pd->infracfg_nao);
> > +
> 
> I think that we should enforce a check here:
> 
> pd->infracfg_nao = syscon_regmap_lookup_by_phandle(node, "mediatek,infracfg_nao");
> if (IS_ERR(pd->infracfg_nao)) {
> 	/* checking if infracfg_nao != NULL at every pwoeron/poweroff is largely
> 	 * suboptimal, as if it't present once, it's present always (!)
> 	 */
> 	if (we have WAY_EN)
> 		return ERR_CAST ...
> 	pd->infracfg_nao = NULL;
> }

Yes, I added another check that enforces .bp_smi not having any way_en
configuration.

Thanks,
Markus

WARNING: multiple messages have this Message-ID (diff)
From: Markus Schneider-Pargmann <msp@baylibre.com>
To: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Cc: Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Weiyi Lu <weiyi.lu@mediatek.com>,
	Fabien Parent <parent.f@gmail.com>,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org,
	Alexandre Bailon <abailon@baylibre.com>,
	Fabien Parent <fparent@baylibre.com>
Subject: Re: [PATCH v2 2/4] soc: mediatek: Add support of WAY_EN operations
Date: Fri, 19 Aug 2022 14:42:06 +0200	[thread overview]
Message-ID: <20220819124206.kwp6ammicyy4z3jb@blmsp> (raw)
In-Reply-To: <dccc2863-a9db-d9ea-01e1-a18cf0db1d1e@collabora.com>

Hi Angelo,

Thanks for your review, I fixed most, comments inline.

On Mon, Jul 25, 2022 at 11:55:27AM +0200, AngeloGioacchino Del Regno wrote:
> Il 25/07/22 10:18, Markus Schneider-Pargmann ha scritto:
> > From: Alexandre Bailon <abailon@baylibre.com>
> > 
> > This updates the power domain to support WAY_EN operations. These
> > operations enable a path between different units of the chip and are
> > labeled as 'way_en' in the register descriptions.
> > 
> > This operation is required by the mt8365 for the MM power domain.
> > 
> > Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
> > Signed-off-by: Fabien Parent <fparent@baylibre.com>
> > Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
> > ---
> > 
> > Notes:
> >      Changes in v2:
> >      - some minor style fixes.
> >      - Renamed 'wayen' to 'way_en' to clarify the meaning
> >      - Updated commit message
> > 
> >   drivers/soc/mediatek/mtk-pm-domains.c | 64 +++++++++++++++++++++------
> >   drivers/soc/mediatek/mtk-pm-domains.h | 28 +++++++-----
> >   2 files changed, 68 insertions(+), 24 deletions(-)
> > 
> > diff --git a/drivers/soc/mediatek/mtk-pm-domains.c b/drivers/soc/mediatek/mtk-pm-domains.c
> > index 5ced254b082b..d0eae2227813 100644
> > --- a/drivers/soc/mediatek/mtk-pm-domains.c
> > +++ b/drivers/soc/mediatek/mtk-pm-domains.c
> > @@ -44,6 +44,7 @@ struct scpsys_domain {
> >   	struct clk_bulk_data *subsys_clks;
> >   	struct regmap *infracfg;
> >   	struct regmap *smi;
> > +	struct regmap *infracfg_nao;
> 
> What does "nao" mean?

I couldn't find the meaning of nao right now. It is the name of the
infracfg node in the datasheet. The normal one is called 'infracfg_ao'
the other one 'infracfg_nao' as far as I can see.

> 
> Besides, please move that before *infracfg to at least keep the same type members
> alphabetically sorted..
> 
> >   	struct regulator *supply;
> >   };
> > @@ -116,23 +117,38 @@ static int scpsys_sram_disable(struct scpsys_domain *pd)
> >   					MTK_POLL_TIMEOUT);
> >   }
> > -static int _scpsys_bus_protect_enable(const struct scpsys_bus_prot_data *bpd, struct regmap *regmap)
> > +static int _scpsys_bus_protect_enable(const struct scpsys_bus_prot_data *bpd,
> > +				      struct regmap *regmap, struct regmap *infracfg_nao)
> >   {
> >   	int i, ret;
> >   	for (i = 0; i < SPM_MAX_BUS_PROT_DATA; i++) {
> > -		u32 val, mask = bpd[i].bus_prot_mask;
> > +		u32 mask = bpd[i].bus_prot_mask;
> > +		u32 val = mask, sta_mask = mask;
> 
> You have modified the macros to use sta_mask as mask, so, why are you doing
> that distinction in here between the two? You can simply keep assigning
> 
> 		u32 mask = bpd[1].bus_prot_mask;
> 		u32 sta_mask = bpd[1].bus_prot_sta_mask;
> 
> > +		struct regmap *ack_regmap = regmap;
> 
> Double assignment. You're reassigning this if way_en == true.
> 
> >   		if (!mask)
> >   			break;
> > +		if (bpd[i].way_en) {
> > +			if (!infracfg_nao)
> > +				return -ENODEV;
> > +
> > +			val = 0;
> > +			sta_mask = bpd[i].bus_prot_sta_mask;
> > +			ack_regmap = infracfg_nao;
> > +		}
> 
> 		if (bpd[i].way_en) {
> 			ack_regmap = regmap_nao;
> 			val = 0;
> 		} else {
> 			ack_regmap = regmap;
> 			val = mask;
> 		}
> 
> > +
> >   		if (bpd[i].bus_prot_reg_update)
> > -			regmap_set_bits(regmap, bpd[i].bus_prot_set, mask);
> > +			regmap_update_bits(regmap, bpd[i].bus_prot_set, mask, val);
> >   		else
> >   			regmap_write(regmap, bpd[i].bus_prot_set, mask);
> > -		ret = regmap_read_poll_timeout(regmap, bpd[i].bus_prot_sta,
> > -					       val, (val & mask) == mask,
> > +		if (bpd[i].ignore_clr_ack)
> > +			continue;
> 
> You're adding that ignore_clr_ack here in the bus prot enablement function
> which wasn't here before... and I didn't check carefully, but I think that
> this is wrong: as the name says, it's to "ignore CLEAR ack", we're not doing
> any clearing here, we're not in bus_protect_disable.
> 
> If you're really sure that this is not a mistake, you should guard it for way_en.

We are clearing bits here if way_en is true and bus_prot_reg_update is
true as well. Then val=0 and regmap_update_bits(..., mask, val) will
clear the bits given in mask. And yes either way_en or val==0 should
probably be checked here. Thanks.

> 
> > +
> > +		ret = regmap_read_poll_timeout(ack_regmap, bpd[i].bus_prot_sta,
> > +					       val, (val & sta_mask) == sta_mask,
> >   					       MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
> >   		if (ret)
> >   			return ret;
> > @@ -145,34 +161,49 @@ static int scpsys_bus_protect_enable(struct scpsys_domain *pd)
> >   {
> >   	int ret;
> > -	ret = _scpsys_bus_protect_enable(pd->data->bp_infracfg, pd->infracfg);
> > +	ret = _scpsys_bus_protect_enable(pd->data->bp_infracfg,
> > +					 pd->infracfg, pd->infracfg_nao);
> >   	if (ret)
> >   		return ret;
> > -	return _scpsys_bus_protect_enable(pd->data->bp_smi, pd->smi);
> > +	return _scpsys_bus_protect_enable(pd->data->bp_smi, pd->smi, NULL);
> >   }
> > +#define mask_cond(way_en, val, mask) \
> > +	((way_en && ((val & mask) == mask)) || (!way_en && !(val & mask)))
> > +
> >   static int _scpsys_bus_protect_disable(const struct scpsys_bus_prot_data *bpd,
> > -				       struct regmap *regmap)
> > +				       struct regmap *regmap, struct regmap *infracfg_nao)
> >   {
> >   	int i, ret;
> >   	for (i = SPM_MAX_BUS_PROT_DATA - 1; i >= 0; i--) {
> > -		u32 val, mask = bpd[i].bus_prot_mask;
> > +		u32 val = 0, mask = bpd[i].bus_prot_mask;
> > +		u32 sta_mask = mask;
> > +		struct regmap *ack_regmap = regmap;
> >   		if (!mask)
> >   			continue;
> > +		if (bpd[i].way_en) {
> > +			if (!infracfg_nao)
> > +				return -ENODEV;
> > +
> > +			val = mask;
> > +			sta_mask = bpd[i].bus_prot_sta_mask;
> > +			ack_regmap = infracfg_nao;
> > +		}
> > +
> >   		if (bpd[i].bus_prot_reg_update)
> > -			regmap_clear_bits(regmap, bpd[i].bus_prot_clr, mask);
> > +			regmap_update_bits(regmap, bpd[i].bus_prot_clr, mask, val);
> >   		else
> >   			regmap_write(regmap, bpd[i].bus_prot_clr, mask);
> >   		if (bpd[i].ignore_clr_ack)
> >   			continue;
> > -		ret = regmap_read_poll_timeout(regmap, bpd[i].bus_prot_sta,
> > -					       val, !(val & mask),
> > +		ret = regmap_read_poll_timeout(ack_regmap, bpd[i].bus_prot_sta,
> > +					       val, mask_cond(bpd[i].way_en, val, sta_mask),
> 
> "I don't know why", my brain still keeps telling me that using different functions
> for the WAY_EN (en/dis) is just better.
> 
> This commit seems to be overcomplicating two "easy" en/dis functions.

Looking at the code again, I think you are right. I redesigned basically
this whole patch, and I think it is easier to understand now.
> 
> >   					       MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
> >   		if (ret)
> >   			return ret;
> > @@ -185,11 +216,12 @@ static int scpsys_bus_protect_disable(struct scpsys_domain *pd)
> >   {
> >   	int ret;
> > -	ret = _scpsys_bus_protect_disable(pd->data->bp_smi, pd->smi);
> > +	ret = _scpsys_bus_protect_disable(pd->data->bp_smi, pd->smi, NULL);
> >   	if (ret)
> >   		return ret;
> > -	return _scpsys_bus_protect_disable(pd->data->bp_infracfg, pd->infracfg);
> > +	return _scpsys_bus_protect_disable(pd->data->bp_infracfg,
> > +			pd->infracfg, pd->infracfg_nao);
> >   }
> >   static int scpsys_regulator_enable(struct regulator *supply)
> > @@ -363,6 +395,10 @@ generic_pm_domain *scpsys_add_one_domain(struct scpsys *scpsys, struct device_no
> >   			return ERR_CAST(pd->smi);
> >   	}
> > +	pd->infracfg_nao = syscon_regmap_lookup_by_phandle_optional(node, "mediatek,infracfg_nao");
> > +	if (IS_ERR(pd->infracfg_nao))
> > +		return ERR_CAST(pd->infracfg_nao);
> > +
> 
> I think that we should enforce a check here:
> 
> pd->infracfg_nao = syscon_regmap_lookup_by_phandle(node, "mediatek,infracfg_nao");
> if (IS_ERR(pd->infracfg_nao)) {
> 	/* checking if infracfg_nao != NULL at every pwoeron/poweroff is largely
> 	 * suboptimal, as if it't present once, it's present always (!)
> 	 */
> 	if (we have WAY_EN)
> 		return ERR_CAST ...
> 	pd->infracfg_nao = NULL;
> }

Yes, I added another check that enforces .bp_smi not having any way_en
configuration.

Thanks,
Markus

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

  reply	other threads:[~2022-08-19 12:42 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-25  8:18 [PATCH v2 0/4] soc: mediatek: MT8365 power support Markus Schneider-Pargmann
2022-07-25  8:18 ` Markus Schneider-Pargmann
2022-07-25  8:18 ` [PATCH v2 1/4] dt-bindings: power: Add MT8365 power domains Markus Schneider-Pargmann
2022-07-25  8:18   ` Markus Schneider-Pargmann
2022-07-25  8:54   ` AngeloGioacchino Del Regno
2022-07-25  8:54     ` AngeloGioacchino Del Regno
2022-08-11 10:14     ` Markus Schneider-Pargmann
2022-08-11 10:14       ` Markus Schneider-Pargmann
2022-08-11 10:45       ` Krzysztof Kozlowski
2022-08-11 10:45         ` Krzysztof Kozlowski
2022-07-25  8:18 ` [PATCH v2 2/4] soc: mediatek: Add support of WAY_EN operations Markus Schneider-Pargmann
2022-07-25  8:18   ` Markus Schneider-Pargmann
2022-07-25  9:55   ` AngeloGioacchino Del Regno
2022-07-25  9:55     ` AngeloGioacchino Del Regno
2022-08-19 12:42     ` Markus Schneider-Pargmann [this message]
2022-08-19 12:42       ` Markus Schneider-Pargmann
2022-07-25  8:18 ` [PATCH v2 3/4] soc: mediatek: add support of MTK_SCPD_STRICT_BUSP cap Markus Schneider-Pargmann
2022-07-25  8:18   ` Markus Schneider-Pargmann
2022-07-25  9:07   ` AngeloGioacchino Del Regno
2022-07-25  9:07     ` AngeloGioacchino Del Regno
2022-07-25  8:18 ` [PATCH v2 4/4] soc: mediatek: pm-domains: Add support for MT8365 Markus Schneider-Pargmann
2022-07-25  8:18   ` Markus Schneider-Pargmann

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=20220819124206.kwp6ammicyy4z3jb@blmsp \
    --to=msp@baylibre.com \
    --cc=abailon@baylibre.com \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=devicetree@vger.kernel.org \
    --cc=fparent@baylibre.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --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=parent.f@gmail.com \
    --cc=robh+dt@kernel.org \
    --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.