All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andre Przywara <andre.przywara@arm.com>
To: Samuel Holland <samuel@sholland.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>,
	Mark Brown <broonie@kernel.org>, Chen-Yu Tsai <wens@csie.org>,
	Jernej Skrabec <jernej.skrabec@gmail.com>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Rob Herring <robh+dt@kernel.org>, Andrew Lunn <andrew@lunn.ch>,
	Heiko Stuebner <heiko@sntech.de>,
	Maxime Ripard <mripard@kernel.org>,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-sunxi@lists.linux.dev
Subject: Re: [PATCH v4 2/4] regulator: sun20i: Add Allwinner D1 LDOs driver
Date: Sat, 26 Nov 2022 00:22:43 +0000	[thread overview]
Message-ID: <20221126002243.37b1034d@slackpad.lan> (raw)
In-Reply-To: <20221125040112.18160-3-samuel@sholland.org>

On Thu, 24 Nov 2022 22:01:10 -0600
Samuel Holland <samuel@sholland.org> wrote:

Hi Samuel,

> D1 contains two pairs of LDOs, "analog" LDOs and "system" LDOs. They are
> similar and can share a driver, but only the system LDOs have a DT
> binding defined so far.
> 
> The system LDOs have a single linear range. The voltage step is not an
> integer, so a custom .list_voltage is needed to get the rounding right.
> 
> Signed-off-by: Samuel Holland <samuel@sholland.org>
> ---
> 
> Changes in v4:
>  - Drop the analog LDOs until the codec binding is ready
> 
> Changes in v3:
>  - Adjust control flow in sun20i_regulator_get_regmap() for clarity
> 
> Changes in v2:
>  - Use decimal numbers for .n_voltages instead of field widths
>  - Get the regmap from the parent device instead of a property/phandle
> 
>  drivers/regulator/Kconfig            |   8 ++
>  drivers/regulator/Makefile           |   1 +
>  drivers/regulator/sun20i-regulator.c | 150 +++++++++++++++++++++++++++
>  3 files changed, 159 insertions(+)
>  create mode 100644 drivers/regulator/sun20i-regulator.c
> 
> diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
> index 070e4403c6c2..8480532114c1 100644
> --- a/drivers/regulator/Kconfig
> +++ b/drivers/regulator/Kconfig
> @@ -1280,6 +1280,14 @@ config REGULATOR_STW481X_VMMC
>  	  This driver supports the internal VMMC regulator in the STw481x
>  	  PMIC chips.
>  
> +config REGULATOR_SUN20I
> +	tristate "Allwinner D1 internal LDOs"
> +	depends on ARCH_SUNXI || COMPILE_TEST
> +	select MFD_SYSCON
> +	default ARCH_SUNXI
> +	help
> +	  This driver supports the internal LDOs in the Allwinner D1 SoC.
> +
>  config REGULATOR_SY7636A
>  	tristate "Silergy SY7636A voltage regulator"
>  	depends on MFD_SY7636A
> diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
> index 5962307e1130..8e9b5a21123d 100644
> --- a/drivers/regulator/Makefile
> +++ b/drivers/regulator/Makefile
> @@ -150,6 +150,7 @@ obj-$(CONFIG_REGULATOR_STM32_VREFBUF) += stm32-vrefbuf.o
>  obj-$(CONFIG_REGULATOR_STM32_PWR) += stm32-pwr.o
>  obj-$(CONFIG_REGULATOR_STPMIC1) += stpmic1_regulator.o
>  obj-$(CONFIG_REGULATOR_STW481X_VMMC) += stw481x-vmmc.o
> +obj-$(CONFIG_REGULATOR_SUN20I) += sun20i-regulator.o
>  obj-$(CONFIG_REGULATOR_SY7636A) += sy7636a-regulator.o
>  obj-$(CONFIG_REGULATOR_SY8106A) += sy8106a-regulator.o
>  obj-$(CONFIG_REGULATOR_SY8824X) += sy8824x.o
> diff --git a/drivers/regulator/sun20i-regulator.c b/drivers/regulator/sun20i-regulator.c
> new file mode 100644
> index 000000000000..031bcc3dee50
> --- /dev/null
> +++ b/drivers/regulator/sun20i-regulator.c
> @@ -0,0 +1,150 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +//
> +// Copyright (c) 2021-2022 Samuel Holland <samuel@sholland.org>
> +//
> +
> +#include <linux/mfd/syscon.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <linux/regulator/driver.h>
> +
> +#define SUN20I_SYS_LDO_CTRL_REG		0x150
> +
> +struct sun20i_regulator_data {
> +	const struct regulator_desc	*descs;
> +	unsigned int			ndescs;
> +};
> +
> +/* regulator_list_voltage_linear() modified for the non-integral uV_step. */
> +static int sun20i_d1_system_ldo_list_voltage(struct regulator_dev *rdev,
> +					     unsigned int selector)
> +{
> +	const struct regulator_desc *desc = rdev->desc;
> +	unsigned int uV;
> +
> +	if (selector >= desc->n_voltages)
> +		return -EINVAL;
> +
> +	uV = desc->min_uV + (desc->uV_step * selector);
> +
> +	/* Produce correctly-rounded absolute voltages. */
> +	return uV + ((selector + 1 + (desc->min_uV % 4)) / 3);
> +}
> +
> +static const struct regulator_ops sun20i_d1_system_ldo_ops = {
> +	.list_voltage		= sun20i_d1_system_ldo_list_voltage,
> +	.map_voltage		= regulator_map_voltage_ascend,
> +	.set_voltage_sel	= regulator_set_voltage_sel_regmap,
> +	.get_voltage_sel	= regulator_get_voltage_sel_regmap,
> +};
> +
> +static const struct regulator_desc sun20i_d1_system_ldo_descs[] = {
> +	{
> +		.name		= "ldoa",
> +		.supply_name	= "ldo-in",
> +		.of_match	= "ldoa",
> +		.ops		= &sun20i_d1_system_ldo_ops,
> +		.type		= REGULATOR_VOLTAGE,
> +		.owner		= THIS_MODULE,
> +		.n_voltages	= 32,
> +		.min_uV		= 1600000,
> +		.uV_step	= 13333, /* repeating */

So while I see that those values are probably the closest we can with a
simple linear algorithm, they first two values seem to be slightly off
from those values in the manual:
sel diff algor  manual
 0:   7 (1.600 - 1.593)
 1:   6 (1.613 - 1.607)
Oddly enough the rest of the values are spot on.
I don't know if this really matters, or if the LDOs are actually
accurate enough to that level of precision, or if it's a manual bug, or
if we really care at all, but it might warrant some comment, I guess?
I just got triggered by the min value not being the first value in the
list.

> +		.vsel_reg	= SUN20I_SYS_LDO_CTRL_REG,
> +		.vsel_mask	= GENMASK(7, 0),
> +	},
> +	{
> +		.name		= "ldob",
> +		.supply_name	= "ldo-in",
> +		.of_match	= "ldob",
> +		.ops		= &sun20i_d1_system_ldo_ops,
> +		.type		= REGULATOR_VOLTAGE,
> +		.owner		= THIS_MODULE,
> +		.n_voltages	= 64,
> +		.min_uV		= 1166666,
> +		.uV_step	= 13333, /* repeating */

For LDOB it seems to be worse, as the second half is constantly off by
what looks like 6.666mV:
sel diff algor  manual
...
32:   0 (1.593 - 1.593)
33:   0 (1.607 - 1.607)
34:  -7 (1.620 - 1.627)
35:  -7 (1.633 - 1.64)
36:  -6 (1.647 - 1.653)
...
63:  -6 (2.007 - 2.013)
The first half is correct, though. Closer inspection reveals that
everything with bit 5 set is exactly the same as LDOA. Maybe we can use
that to our advantage?

Cheers,
Andre

> +		.vsel_reg	= SUN20I_SYS_LDO_CTRL_REG,
> +		.vsel_mask	= GENMASK(15, 8),
> +	},
> +};
> +
> +static const struct sun20i_regulator_data sun20i_d1_system_ldos = {
> +	.descs	= sun20i_d1_system_ldo_descs,
> +	.ndescs	= ARRAY_SIZE(sun20i_d1_system_ldo_descs),
> +};
> +
> +static struct regmap *sun20i_regulator_get_regmap(struct device *dev)
> +{
> +	struct regmap *regmap;
> +
> +	/*
> +	 * First try the syscon interface. The system control device is not
> +	 * compatible with "syscon", so fall back to getting the regmap from
> +	 * its platform device. This is ugly, but required for devicetree
> +	 * backward compatibility.
> +	 */
> +	regmap = syscon_node_to_regmap(dev->parent->of_node);
> +	if (!IS_ERR(regmap))
> +		return regmap;
> +
> +	regmap = dev_get_regmap(dev->parent, NULL);
> +	if (regmap)
> +		return regmap;
> +
> +	return ERR_PTR(-EPROBE_DEFER);
> +}
> +
> +static int sun20i_regulator_probe(struct platform_device *pdev)
> +{
> +	const struct sun20i_regulator_data *data;
> +	struct device *dev = &pdev->dev;
> +	struct regulator_config config;
> +	struct regmap *regmap;
> +
> +	data = of_device_get_match_data(dev);
> +	if (!data)
> +		return -EINVAL;
> +
> +	regmap = sun20i_regulator_get_regmap(dev);
> +	if (IS_ERR(regmap))
> +		return dev_err_probe(dev, PTR_ERR(regmap), "Failed to get regmap\n");
> +
> +	config = (struct regulator_config) {
> +		.dev	= dev,
> +		.regmap	= regmap,
> +	};
> +
> +	for (unsigned int i = 0; i < data->ndescs; ++i) {
> +		const struct regulator_desc *desc = &data->descs[i];
> +		struct regulator_dev *rdev;
> +
> +		rdev = devm_regulator_register(dev, desc, &config);
> +		if (IS_ERR(rdev))
> +			return PTR_ERR(rdev);
> +	}
> +
> +	return 0;
> +}
> +
> +static const struct of_device_id sun20i_regulator_of_match[] = {
> +	{
> +		.compatible = "allwinner,sun20i-d1-system-ldos",
> +		.data = &sun20i_d1_system_ldos,
> +	},
> +	{ },
> +};
> +MODULE_DEVICE_TABLE(of, sun20i_regulator_of_match);
> +
> +static struct platform_driver sun20i_regulator_driver = {
> +	.probe	= sun20i_regulator_probe,
> +	.driver	= {
> +		.name		= "sun20i-regulator",
> +		.of_match_table	= sun20i_regulator_of_match,
> +	},
> +};
> +module_platform_driver(sun20i_regulator_driver);
> +
> +MODULE_AUTHOR("Samuel Holland <samuel@sholland.org>");
> +MODULE_DESCRIPTION("Allwinner D1 internal LDO driver");
> +MODULE_LICENSE("GPL");


WARNING: multiple messages have this Message-ID (diff)
From: Andre Przywara <andre.przywara@arm.com>
To: Samuel Holland <samuel@sholland.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>,
	Mark Brown <broonie@kernel.org>, Chen-Yu Tsai <wens@csie.org>,
	Jernej Skrabec <jernej.skrabec@gmail.com>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Rob Herring <robh+dt@kernel.org>, Andrew Lunn <andrew@lunn.ch>,
	Heiko Stuebner <heiko@sntech.de>,
	Maxime Ripard <mripard@kernel.org>,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-sunxi@lists.linux.dev
Subject: Re: [PATCH v4 2/4] regulator: sun20i: Add Allwinner D1 LDOs driver
Date: Sat, 26 Nov 2022 00:22:43 +0000	[thread overview]
Message-ID: <20221126002243.37b1034d@slackpad.lan> (raw)
In-Reply-To: <20221125040112.18160-3-samuel@sholland.org>

On Thu, 24 Nov 2022 22:01:10 -0600
Samuel Holland <samuel@sholland.org> wrote:

Hi Samuel,

> D1 contains two pairs of LDOs, "analog" LDOs and "system" LDOs. They are
> similar and can share a driver, but only the system LDOs have a DT
> binding defined so far.
> 
> The system LDOs have a single linear range. The voltage step is not an
> integer, so a custom .list_voltage is needed to get the rounding right.
> 
> Signed-off-by: Samuel Holland <samuel@sholland.org>
> ---
> 
> Changes in v4:
>  - Drop the analog LDOs until the codec binding is ready
> 
> Changes in v3:
>  - Adjust control flow in sun20i_regulator_get_regmap() for clarity
> 
> Changes in v2:
>  - Use decimal numbers for .n_voltages instead of field widths
>  - Get the regmap from the parent device instead of a property/phandle
> 
>  drivers/regulator/Kconfig            |   8 ++
>  drivers/regulator/Makefile           |   1 +
>  drivers/regulator/sun20i-regulator.c | 150 +++++++++++++++++++++++++++
>  3 files changed, 159 insertions(+)
>  create mode 100644 drivers/regulator/sun20i-regulator.c
> 
> diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
> index 070e4403c6c2..8480532114c1 100644
> --- a/drivers/regulator/Kconfig
> +++ b/drivers/regulator/Kconfig
> @@ -1280,6 +1280,14 @@ config REGULATOR_STW481X_VMMC
>  	  This driver supports the internal VMMC regulator in the STw481x
>  	  PMIC chips.
>  
> +config REGULATOR_SUN20I
> +	tristate "Allwinner D1 internal LDOs"
> +	depends on ARCH_SUNXI || COMPILE_TEST
> +	select MFD_SYSCON
> +	default ARCH_SUNXI
> +	help
> +	  This driver supports the internal LDOs in the Allwinner D1 SoC.
> +
>  config REGULATOR_SY7636A
>  	tristate "Silergy SY7636A voltage regulator"
>  	depends on MFD_SY7636A
> diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
> index 5962307e1130..8e9b5a21123d 100644
> --- a/drivers/regulator/Makefile
> +++ b/drivers/regulator/Makefile
> @@ -150,6 +150,7 @@ obj-$(CONFIG_REGULATOR_STM32_VREFBUF) += stm32-vrefbuf.o
>  obj-$(CONFIG_REGULATOR_STM32_PWR) += stm32-pwr.o
>  obj-$(CONFIG_REGULATOR_STPMIC1) += stpmic1_regulator.o
>  obj-$(CONFIG_REGULATOR_STW481X_VMMC) += stw481x-vmmc.o
> +obj-$(CONFIG_REGULATOR_SUN20I) += sun20i-regulator.o
>  obj-$(CONFIG_REGULATOR_SY7636A) += sy7636a-regulator.o
>  obj-$(CONFIG_REGULATOR_SY8106A) += sy8106a-regulator.o
>  obj-$(CONFIG_REGULATOR_SY8824X) += sy8824x.o
> diff --git a/drivers/regulator/sun20i-regulator.c b/drivers/regulator/sun20i-regulator.c
> new file mode 100644
> index 000000000000..031bcc3dee50
> --- /dev/null
> +++ b/drivers/regulator/sun20i-regulator.c
> @@ -0,0 +1,150 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +//
> +// Copyright (c) 2021-2022 Samuel Holland <samuel@sholland.org>
> +//
> +
> +#include <linux/mfd/syscon.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <linux/regulator/driver.h>
> +
> +#define SUN20I_SYS_LDO_CTRL_REG		0x150
> +
> +struct sun20i_regulator_data {
> +	const struct regulator_desc	*descs;
> +	unsigned int			ndescs;
> +};
> +
> +/* regulator_list_voltage_linear() modified for the non-integral uV_step. */
> +static int sun20i_d1_system_ldo_list_voltage(struct regulator_dev *rdev,
> +					     unsigned int selector)
> +{
> +	const struct regulator_desc *desc = rdev->desc;
> +	unsigned int uV;
> +
> +	if (selector >= desc->n_voltages)
> +		return -EINVAL;
> +
> +	uV = desc->min_uV + (desc->uV_step * selector);
> +
> +	/* Produce correctly-rounded absolute voltages. */
> +	return uV + ((selector + 1 + (desc->min_uV % 4)) / 3);
> +}
> +
> +static const struct regulator_ops sun20i_d1_system_ldo_ops = {
> +	.list_voltage		= sun20i_d1_system_ldo_list_voltage,
> +	.map_voltage		= regulator_map_voltage_ascend,
> +	.set_voltage_sel	= regulator_set_voltage_sel_regmap,
> +	.get_voltage_sel	= regulator_get_voltage_sel_regmap,
> +};
> +
> +static const struct regulator_desc sun20i_d1_system_ldo_descs[] = {
> +	{
> +		.name		= "ldoa",
> +		.supply_name	= "ldo-in",
> +		.of_match	= "ldoa",
> +		.ops		= &sun20i_d1_system_ldo_ops,
> +		.type		= REGULATOR_VOLTAGE,
> +		.owner		= THIS_MODULE,
> +		.n_voltages	= 32,
> +		.min_uV		= 1600000,
> +		.uV_step	= 13333, /* repeating */

So while I see that those values are probably the closest we can with a
simple linear algorithm, they first two values seem to be slightly off
from those values in the manual:
sel diff algor  manual
 0:   7 (1.600 - 1.593)
 1:   6 (1.613 - 1.607)
Oddly enough the rest of the values are spot on.
I don't know if this really matters, or if the LDOs are actually
accurate enough to that level of precision, or if it's a manual bug, or
if we really care at all, but it might warrant some comment, I guess?
I just got triggered by the min value not being the first value in the
list.

> +		.vsel_reg	= SUN20I_SYS_LDO_CTRL_REG,
> +		.vsel_mask	= GENMASK(7, 0),
> +	},
> +	{
> +		.name		= "ldob",
> +		.supply_name	= "ldo-in",
> +		.of_match	= "ldob",
> +		.ops		= &sun20i_d1_system_ldo_ops,
> +		.type		= REGULATOR_VOLTAGE,
> +		.owner		= THIS_MODULE,
> +		.n_voltages	= 64,
> +		.min_uV		= 1166666,
> +		.uV_step	= 13333, /* repeating */

For LDOB it seems to be worse, as the second half is constantly off by
what looks like 6.666mV:
sel diff algor  manual
...
32:   0 (1.593 - 1.593)
33:   0 (1.607 - 1.607)
34:  -7 (1.620 - 1.627)
35:  -7 (1.633 - 1.64)
36:  -6 (1.647 - 1.653)
...
63:  -6 (2.007 - 2.013)
The first half is correct, though. Closer inspection reveals that
everything with bit 5 set is exactly the same as LDOA. Maybe we can use
that to our advantage?

Cheers,
Andre

> +		.vsel_reg	= SUN20I_SYS_LDO_CTRL_REG,
> +		.vsel_mask	= GENMASK(15, 8),
> +	},
> +};
> +
> +static const struct sun20i_regulator_data sun20i_d1_system_ldos = {
> +	.descs	= sun20i_d1_system_ldo_descs,
> +	.ndescs	= ARRAY_SIZE(sun20i_d1_system_ldo_descs),
> +};
> +
> +static struct regmap *sun20i_regulator_get_regmap(struct device *dev)
> +{
> +	struct regmap *regmap;
> +
> +	/*
> +	 * First try the syscon interface. The system control device is not
> +	 * compatible with "syscon", so fall back to getting the regmap from
> +	 * its platform device. This is ugly, but required for devicetree
> +	 * backward compatibility.
> +	 */
> +	regmap = syscon_node_to_regmap(dev->parent->of_node);
> +	if (!IS_ERR(regmap))
> +		return regmap;
> +
> +	regmap = dev_get_regmap(dev->parent, NULL);
> +	if (regmap)
> +		return regmap;
> +
> +	return ERR_PTR(-EPROBE_DEFER);
> +}
> +
> +static int sun20i_regulator_probe(struct platform_device *pdev)
> +{
> +	const struct sun20i_regulator_data *data;
> +	struct device *dev = &pdev->dev;
> +	struct regulator_config config;
> +	struct regmap *regmap;
> +
> +	data = of_device_get_match_data(dev);
> +	if (!data)
> +		return -EINVAL;
> +
> +	regmap = sun20i_regulator_get_regmap(dev);
> +	if (IS_ERR(regmap))
> +		return dev_err_probe(dev, PTR_ERR(regmap), "Failed to get regmap\n");
> +
> +	config = (struct regulator_config) {
> +		.dev	= dev,
> +		.regmap	= regmap,
> +	};
> +
> +	for (unsigned int i = 0; i < data->ndescs; ++i) {
> +		const struct regulator_desc *desc = &data->descs[i];
> +		struct regulator_dev *rdev;
> +
> +		rdev = devm_regulator_register(dev, desc, &config);
> +		if (IS_ERR(rdev))
> +			return PTR_ERR(rdev);
> +	}
> +
> +	return 0;
> +}
> +
> +static const struct of_device_id sun20i_regulator_of_match[] = {
> +	{
> +		.compatible = "allwinner,sun20i-d1-system-ldos",
> +		.data = &sun20i_d1_system_ldos,
> +	},
> +	{ },
> +};
> +MODULE_DEVICE_TABLE(of, sun20i_regulator_of_match);
> +
> +static struct platform_driver sun20i_regulator_driver = {
> +	.probe	= sun20i_regulator_probe,
> +	.driver	= {
> +		.name		= "sun20i-regulator",
> +		.of_match_table	= sun20i_regulator_of_match,
> +	},
> +};
> +module_platform_driver(sun20i_regulator_driver);
> +
> +MODULE_AUTHOR("Samuel Holland <samuel@sholland.org>");
> +MODULE_DESCRIPTION("Allwinner D1 internal LDO driver");
> +MODULE_LICENSE("GPL");


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

  reply	other threads:[~2022-11-26  0:24 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-25  4:01 [PATCH v4 0/4] regulator: Add support for Allwinner D1 system LDOs Samuel Holland
2022-11-25  4:01 ` Samuel Holland
2022-11-25  4:01 ` [PATCH v4 1/4] regulator: dt-bindings: Add " Samuel Holland
2022-11-25  4:01   ` Samuel Holland
2022-11-25  8:08   ` Krzysztof Kozlowski
2022-11-25  8:08     ` Krzysztof Kozlowski
2022-11-25  4:01 ` [PATCH v4 2/4] regulator: sun20i: Add Allwinner D1 LDOs driver Samuel Holland
2022-11-25  4:01   ` Samuel Holland
2022-11-26  0:22   ` Andre Przywara [this message]
2022-11-26  0:22     ` Andre Przywara
2022-11-26  3:03     ` Samuel Holland
2022-11-26  3:03       ` Samuel Holland
2022-11-25  4:01 ` [PATCH v4 3/4] dt-bindings: sram: sunxi-sram: Add regulators child Samuel Holland
2022-11-25  4:01   ` Samuel Holland
2022-11-25  8:10   ` Krzysztof Kozlowski
2022-11-25  8:10     ` Krzysztof Kozlowski
2022-11-25  4:01 ` [PATCH v4 4/4] soc: sunxi: sram: Only iterate over SRAM children Samuel Holland
2022-11-25  4:01   ` Samuel Holland
2022-12-05 21:08   ` Jernej Škrabec
2022-12-05 21:08     ` Jernej Škrabec

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=20221126002243.37b1034d@slackpad.lan \
    --to=andre.przywara@arm.com \
    --cc=andrew@lunn.ch \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=heiko@sntech.de \
    --cc=jernej.skrabec@gmail.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sunxi@lists.linux.dev \
    --cc=mripard@kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=samuel@sholland.org \
    --cc=wens@csie.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.