From: Jonathan Cameron <Jonathan.Cameron@huawei.com> To: Lars Povlsen <lars.povlsen@microchip.com> Cc: Guenter Roeck <linux@roeck-us.net>, <linux-hwmon@vger.kernel.org>, <devicetree@vger.kernel.org>, Alexandre Belloni <alexandre.belloni@bootlin.com>, Jean Delvare <jdelvare@suse.com>, <linux-kernel@vger.kernel.org>, Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>, <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH v2 3/3] hwmon: sparx5: Add Sparx5 SoC temperature driver Date: Tue, 9 Jun 2020 14:03:13 +0100 [thread overview] Message-ID: <20200609140313.00007187@huawei.com> (raw) In-Reply-To: <87h7vkig6i.fsf@soft-dev15.microsemi.net> On Tue, 9 Jun 2020 14:20:37 +0200 Lars Povlsen <lars.povlsen@microchip.com> wrote: > Jonathan Cameron writes: > > > On Tue, 9 Jun 2020 09:49:40 +0200 > > Lars Povlsen <lars.povlsen@microchip.com> wrote: > > > >> This patch adds a temperature sensor driver to the Sparx5 SoC. > >> > >> Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com> > >> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com> > > > > Hi. Quick drive by review whilst waiting for coffee time... > > > > A few minor suggestions inline. > > > > Much appreciated! > > > Thanks, > > > > Jonathan > > > >> --- > >> drivers/hwmon/Kconfig | 10 +++ > >> drivers/hwmon/Makefile | 2 +- > >> drivers/hwmon/sparx5-temp.c | 152 > >> ++++++++++++++++++++++++++++++++++++ 3 files changed, 163 > >> insertions(+), 1 deletion(-) create mode 100644 > >> drivers/hwmon/sparx5-temp.c > >> > >> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig > >> index 288ae9f63588c..ec6bb8b8b12df 100644 > >> --- a/drivers/hwmon/Kconfig > >> +++ b/drivers/hwmon/Kconfig > >> @@ -515,6 +515,16 @@ config SENSORS_I5K_AMB > >> This driver can also be built as a module. If so, the > >> module will be called i5k_amb. > >> > >> +config SENSORS_SPARX5 > >> + tristate "Sparx5 SoC temperature sensor" > >> + depends on ARCH_SPARX5 > > Anything stop this building with COMPILE_TEST? > > > > That will great increase automated build coverage. > > > >> + help > >> + If you say yes here you get support for temperature > >> monitoring > >> + with the Microchip Sparx5 SoC. > >> + > >> + This driver can also be built as a module. If so, the > >> module > >> + will be called sparx5-temp. > >> + > >> config SENSORS_F71805F > >> tristate "Fintek F71805F/FG, F71806F/FG and F71872F/FG" > >> depends on !PPC > >> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile > >> index 3e32c21f5efe3..144f09993a3f4 100644 > >> --- a/drivers/hwmon/Makefile > >> +++ b/drivers/hwmon/Makefile > >> @@ -66,6 +66,7 @@ obj-$(CONFIG_SENSORS_DS1621) += ds1621.o > >> obj-$(CONFIG_SENSORS_EMC1403) += emc1403.o > >> obj-$(CONFIG_SENSORS_EMC2103) += emc2103.o > >> obj-$(CONFIG_SENSORS_EMC6W201) += emc6w201.o > >> +obj-$(CONFIG_SENSORS_SPARX5) += sparx5-temp.o > >> obj-$(CONFIG_SENSORS_F71805F) += f71805f.o > >> obj-$(CONFIG_SENSORS_F71882FG) += f71882fg.o > >> obj-$(CONFIG_SENSORS_F75375S) += f75375s.o > >> @@ -193,4 +194,3 @@ obj-$(CONFIG_SENSORS_OCC) += occ/ > >> obj-$(CONFIG_PMBUS) += pmbus/ > >> > >> ccflags-$(CONFIG_HWMON_DEBUG_CHIP) := -DDEBUG > >> - > >> diff --git a/drivers/hwmon/sparx5-temp.c > >> b/drivers/hwmon/sparx5-temp.c new file mode 100644 > >> index 0000000000000..2e754462b6010 > >> --- /dev/null > >> +++ b/drivers/hwmon/sparx5-temp.c > >> @@ -0,0 +1,152 @@ > >> +// SPDX-License-Identifier: GPL-2.0-or-later > >> +/* Sparx5 SoC temperature sensor driver > >> + * > >> + * Copyright (C) 2020 Lars Povlsen <lars.povlsen@microchip.com> > >> + */ > >> + > >> +#include <linux/module.h> > >> +#include <linux/init.h> > >> +#include <linux/hwmon.h> > >> +#include <linux/io.h> > >> +#include <linux/of_device.h> > > I think you only have this to define the id table? > > > > If so, perhaps better to include mod_devicetable.h and not include > > the of header. > > Well, I ended up needed other, so it became: > > -#include <linux/of_device.h> > +#include <linux/platform_device.h> > +#include <linux/mod_devicetable.h> > > Other of these drivers seem to use "linux/of_device.h" as well? Yeah. Lots of drivers take the lazy approach of including of_device.h but doesn't mean we can't do better. :) Preference is always to include a little as possible (in terms of the tree of headers rather than include lines in a file) J > > > > >> + > >> +#define TEMP_CTRL 0 > >> +#define TEMP_CFG 4 > >> +#define TEMP_CFG_CYCLES GENMASK(24, 15) > >> +#define TEMP_CFG_CYCLES_OFF 15 > > > > Could you used FIELD_PREP etc to avoid having to have both > > the mask and offset defined here? > > > >> +#define TEMP_CFG_ENA BIT(0) > >> +#define TEMP_STAT 8 > >> +#define TEMP_STAT_VALID BIT(12) > >> +#define TEMP_STAT_TEMP GENMASK(11, 0) > >> + > >> +struct s5_hwmon { > >> + void __iomem *base; > >> +}; > >> + > >> +static void s5_temp_enable(struct s5_hwmon *hwmon) > >> +{ > >> + u32 val = readl(hwmon->base + TEMP_CFG); > >> + u32 clk = 250; > >> + > >> + val &= ~TEMP_CFG_CYCLES; > >> + val |= (clk << TEMP_CFG_CYCLES_OFF); > >> + val |= TEMP_CFG_ENA; > >> + > >> + writel(val, hwmon->base + TEMP_CFG); > >> +} > >> + > >> +static void s5_temp_disable(void *data) > >> +{ > >> + struct s5_hwmon *hwmon = data; > >> + u32 val = readl(hwmon->base + TEMP_CFG); > >> + > >> + val &= ~TEMP_CFG_ENA; > >> + > >> + writel(val, hwmon->base + TEMP_CFG); > >> +} > >> + > >> +static int s5_read(struct device *dev, enum hwmon_sensor_types > >> type, > >> + u32 attr, int channel, long *temp) > >> +{ > >> + struct s5_hwmon *hwmon = dev_get_drvdata(dev); > >> + int rc = 0, value; > >> + u32 stat; > >> + > >> + switch (attr) { > >> + case hwmon_temp_input: > >> + stat = readl_relaxed(hwmon->base + TEMP_STAT); > >> + if (!(stat & TEMP_STAT_VALID)) > >> + return -EIO; > >> + value = stat & TEMP_STAT_TEMP; > >> + value = DIV_ROUND_CLOSEST(value * 3522, 4096) - 1094; > >> + value *= 100; > >> + *temp = value; > >> + break; > >> + default: > >> + rc = -EOPNOTSUPP; > >> + break; > >> + } > >> + > >> + return rc; > >> +} > >> + > >> +static umode_t s5_is_visible(const void *_data, enum > >> hwmon_sensor_types type, > >> + u32 attr, int channel) > >> +{ > >> + if (type != hwmon_temp) > >> + return 0; > >> + > >> + switch (attr) { > >> + case hwmon_temp_input: > >> + return 0444; > >> + default: > >> + return 0; > >> + } > >> +} > >> + > >> +static const struct hwmon_channel_info *s5_info[] = { > >> + HWMON_CHANNEL_INFO(chip, > >> + HWMON_C_REGISTER_TZ), > >> + HWMON_CHANNEL_INFO(temp, > >> + HWMON_T_INPUT), > > > > Excess line breaks. The above 2 would be more readable on one line > > each. > > Right. > > >> + NULL > >> +}; > >> + > >> +static const struct hwmon_ops s5_hwmon_ops = { > >> + .is_visible = s5_is_visible, > >> + .read = s5_read, > >> +}; > >> + > >> +static const struct hwmon_chip_info s5_chip_info = { > >> + .ops = &s5_hwmon_ops, > >> + .info = s5_info, > >> +}; > >> + > >> +static int s5_temp_probe(struct platform_device *pdev) > >> +{ > >> + struct device *hwmon_dev; > >> + struct s5_hwmon *hwmon; > >> + int err; > >> + > >> + hwmon = devm_kzalloc(&pdev->dev, sizeof(*hwmon), GFP_KERNEL); > >> + if (!hwmon) > >> + return -ENOMEM; > >> + > >> + hwmon->base = devm_platform_ioremap_resource(pdev, 0); > >> + if (IS_ERR(hwmon->base)) > >> + return PTR_ERR(hwmon->base); > >> + > >> + err = devm_add_action(&pdev->dev, s5_temp_disable, hwmon); > >> + if (err) > >> + return err; > > > > Probably just my linear way of thinking, but unusual to put error > > handling / remove stuff in place _before_ the thing it's unwinding. > > > > We have devm_add_action_or_reset to make it safe to call this after > > the thing it unwinds. > > > > Seems I got this "backwardness" from ltq-cputemp.c. However, its > totally unneeded here, so I'll just remove it. > > Thanks! > > ---Lars > > >> + > >> + s5_temp_enable(hwmon); > >> + > >> + hwmon_dev = devm_hwmon_device_register_with_info(&pdev->dev, > >> + "s5_temp", > >> + hwmon, > >> + > >> &s5_chip_info, > >> + NULL); > >> + > >> + return PTR_ERR_OR_ZERO(hwmon_dev); > >> +} > >> + > >> +const struct of_device_id s5_temp_match[] = { > >> + { .compatible = "microchip,sparx5-temp" }, > >> + {}, > >> +}; > >> +MODULE_DEVICE_TABLE(of, s5_temp_match); > >> + > >> +static struct platform_driver s5_temp_driver = { > >> + .probe = s5_temp_probe, > >> + .driver = { > >> + .name = "sparx5-temp", > >> + .of_match_table = s5_temp_match, > >> + }, > >> +}; > >> + > >> +module_platform_driver(s5_temp_driver); > >> + > >> +MODULE_AUTHOR("Lars Povlsen <lars.povlsen@microchip.com>"); > >> +MODULE_DESCRIPTION("Sparx5 SoC temperature sensor driver"); > >> +MODULE_LICENSE("GPL"); > >> -- > >> 2.27.0 > >> > >> _______________________________________________ > >> linux-arm-kernel mailing list > >> linux-arm-kernel@lists.infradead.org > >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >
WARNING: multiple messages have this Message-ID (diff)
From: Jonathan Cameron <Jonathan.Cameron@huawei.com> To: Lars Povlsen <lars.povlsen@microchip.com> Cc: linux-hwmon@vger.kernel.org, devicetree@vger.kernel.org, Alexandre Belloni <alexandre.belloni@bootlin.com>, Jean Delvare <jdelvare@suse.com>, linux-kernel@vger.kernel.org, Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>, linux-arm-kernel@lists.infradead.org, Guenter Roeck <linux@roeck-us.net> Subject: Re: [PATCH v2 3/3] hwmon: sparx5: Add Sparx5 SoC temperature driver Date: Tue, 9 Jun 2020 14:03:13 +0100 [thread overview] Message-ID: <20200609140313.00007187@huawei.com> (raw) In-Reply-To: <87h7vkig6i.fsf@soft-dev15.microsemi.net> On Tue, 9 Jun 2020 14:20:37 +0200 Lars Povlsen <lars.povlsen@microchip.com> wrote: > Jonathan Cameron writes: > > > On Tue, 9 Jun 2020 09:49:40 +0200 > > Lars Povlsen <lars.povlsen@microchip.com> wrote: > > > >> This patch adds a temperature sensor driver to the Sparx5 SoC. > >> > >> Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com> > >> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com> > > > > Hi. Quick drive by review whilst waiting for coffee time... > > > > A few minor suggestions inline. > > > > Much appreciated! > > > Thanks, > > > > Jonathan > > > >> --- > >> drivers/hwmon/Kconfig | 10 +++ > >> drivers/hwmon/Makefile | 2 +- > >> drivers/hwmon/sparx5-temp.c | 152 > >> ++++++++++++++++++++++++++++++++++++ 3 files changed, 163 > >> insertions(+), 1 deletion(-) create mode 100644 > >> drivers/hwmon/sparx5-temp.c > >> > >> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig > >> index 288ae9f63588c..ec6bb8b8b12df 100644 > >> --- a/drivers/hwmon/Kconfig > >> +++ b/drivers/hwmon/Kconfig > >> @@ -515,6 +515,16 @@ config SENSORS_I5K_AMB > >> This driver can also be built as a module. If so, the > >> module will be called i5k_amb. > >> > >> +config SENSORS_SPARX5 > >> + tristate "Sparx5 SoC temperature sensor" > >> + depends on ARCH_SPARX5 > > Anything stop this building with COMPILE_TEST? > > > > That will great increase automated build coverage. > > > >> + help > >> + If you say yes here you get support for temperature > >> monitoring > >> + with the Microchip Sparx5 SoC. > >> + > >> + This driver can also be built as a module. If so, the > >> module > >> + will be called sparx5-temp. > >> + > >> config SENSORS_F71805F > >> tristate "Fintek F71805F/FG, F71806F/FG and F71872F/FG" > >> depends on !PPC > >> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile > >> index 3e32c21f5efe3..144f09993a3f4 100644 > >> --- a/drivers/hwmon/Makefile > >> +++ b/drivers/hwmon/Makefile > >> @@ -66,6 +66,7 @@ obj-$(CONFIG_SENSORS_DS1621) += ds1621.o > >> obj-$(CONFIG_SENSORS_EMC1403) += emc1403.o > >> obj-$(CONFIG_SENSORS_EMC2103) += emc2103.o > >> obj-$(CONFIG_SENSORS_EMC6W201) += emc6w201.o > >> +obj-$(CONFIG_SENSORS_SPARX5) += sparx5-temp.o > >> obj-$(CONFIG_SENSORS_F71805F) += f71805f.o > >> obj-$(CONFIG_SENSORS_F71882FG) += f71882fg.o > >> obj-$(CONFIG_SENSORS_F75375S) += f75375s.o > >> @@ -193,4 +194,3 @@ obj-$(CONFIG_SENSORS_OCC) += occ/ > >> obj-$(CONFIG_PMBUS) += pmbus/ > >> > >> ccflags-$(CONFIG_HWMON_DEBUG_CHIP) := -DDEBUG > >> - > >> diff --git a/drivers/hwmon/sparx5-temp.c > >> b/drivers/hwmon/sparx5-temp.c new file mode 100644 > >> index 0000000000000..2e754462b6010 > >> --- /dev/null > >> +++ b/drivers/hwmon/sparx5-temp.c > >> @@ -0,0 +1,152 @@ > >> +// SPDX-License-Identifier: GPL-2.0-or-later > >> +/* Sparx5 SoC temperature sensor driver > >> + * > >> + * Copyright (C) 2020 Lars Povlsen <lars.povlsen@microchip.com> > >> + */ > >> + > >> +#include <linux/module.h> > >> +#include <linux/init.h> > >> +#include <linux/hwmon.h> > >> +#include <linux/io.h> > >> +#include <linux/of_device.h> > > I think you only have this to define the id table? > > > > If so, perhaps better to include mod_devicetable.h and not include > > the of header. > > Well, I ended up needed other, so it became: > > -#include <linux/of_device.h> > +#include <linux/platform_device.h> > +#include <linux/mod_devicetable.h> > > Other of these drivers seem to use "linux/of_device.h" as well? Yeah. Lots of drivers take the lazy approach of including of_device.h but doesn't mean we can't do better. :) Preference is always to include a little as possible (in terms of the tree of headers rather than include lines in a file) J > > > > >> + > >> +#define TEMP_CTRL 0 > >> +#define TEMP_CFG 4 > >> +#define TEMP_CFG_CYCLES GENMASK(24, 15) > >> +#define TEMP_CFG_CYCLES_OFF 15 > > > > Could you used FIELD_PREP etc to avoid having to have both > > the mask and offset defined here? > > > >> +#define TEMP_CFG_ENA BIT(0) > >> +#define TEMP_STAT 8 > >> +#define TEMP_STAT_VALID BIT(12) > >> +#define TEMP_STAT_TEMP GENMASK(11, 0) > >> + > >> +struct s5_hwmon { > >> + void __iomem *base; > >> +}; > >> + > >> +static void s5_temp_enable(struct s5_hwmon *hwmon) > >> +{ > >> + u32 val = readl(hwmon->base + TEMP_CFG); > >> + u32 clk = 250; > >> + > >> + val &= ~TEMP_CFG_CYCLES; > >> + val |= (clk << TEMP_CFG_CYCLES_OFF); > >> + val |= TEMP_CFG_ENA; > >> + > >> + writel(val, hwmon->base + TEMP_CFG); > >> +} > >> + > >> +static void s5_temp_disable(void *data) > >> +{ > >> + struct s5_hwmon *hwmon = data; > >> + u32 val = readl(hwmon->base + TEMP_CFG); > >> + > >> + val &= ~TEMP_CFG_ENA; > >> + > >> + writel(val, hwmon->base + TEMP_CFG); > >> +} > >> + > >> +static int s5_read(struct device *dev, enum hwmon_sensor_types > >> type, > >> + u32 attr, int channel, long *temp) > >> +{ > >> + struct s5_hwmon *hwmon = dev_get_drvdata(dev); > >> + int rc = 0, value; > >> + u32 stat; > >> + > >> + switch (attr) { > >> + case hwmon_temp_input: > >> + stat = readl_relaxed(hwmon->base + TEMP_STAT); > >> + if (!(stat & TEMP_STAT_VALID)) > >> + return -EIO; > >> + value = stat & TEMP_STAT_TEMP; > >> + value = DIV_ROUND_CLOSEST(value * 3522, 4096) - 1094; > >> + value *= 100; > >> + *temp = value; > >> + break; > >> + default: > >> + rc = -EOPNOTSUPP; > >> + break; > >> + } > >> + > >> + return rc; > >> +} > >> + > >> +static umode_t s5_is_visible(const void *_data, enum > >> hwmon_sensor_types type, > >> + u32 attr, int channel) > >> +{ > >> + if (type != hwmon_temp) > >> + return 0; > >> + > >> + switch (attr) { > >> + case hwmon_temp_input: > >> + return 0444; > >> + default: > >> + return 0; > >> + } > >> +} > >> + > >> +static const struct hwmon_channel_info *s5_info[] = { > >> + HWMON_CHANNEL_INFO(chip, > >> + HWMON_C_REGISTER_TZ), > >> + HWMON_CHANNEL_INFO(temp, > >> + HWMON_T_INPUT), > > > > Excess line breaks. The above 2 would be more readable on one line > > each. > > Right. > > >> + NULL > >> +}; > >> + > >> +static const struct hwmon_ops s5_hwmon_ops = { > >> + .is_visible = s5_is_visible, > >> + .read = s5_read, > >> +}; > >> + > >> +static const struct hwmon_chip_info s5_chip_info = { > >> + .ops = &s5_hwmon_ops, > >> + .info = s5_info, > >> +}; > >> + > >> +static int s5_temp_probe(struct platform_device *pdev) > >> +{ > >> + struct device *hwmon_dev; > >> + struct s5_hwmon *hwmon; > >> + int err; > >> + > >> + hwmon = devm_kzalloc(&pdev->dev, sizeof(*hwmon), GFP_KERNEL); > >> + if (!hwmon) > >> + return -ENOMEM; > >> + > >> + hwmon->base = devm_platform_ioremap_resource(pdev, 0); > >> + if (IS_ERR(hwmon->base)) > >> + return PTR_ERR(hwmon->base); > >> + > >> + err = devm_add_action(&pdev->dev, s5_temp_disable, hwmon); > >> + if (err) > >> + return err; > > > > Probably just my linear way of thinking, but unusual to put error > > handling / remove stuff in place _before_ the thing it's unwinding. > > > > We have devm_add_action_or_reset to make it safe to call this after > > the thing it unwinds. > > > > Seems I got this "backwardness" from ltq-cputemp.c. However, its > totally unneeded here, so I'll just remove it. > > Thanks! > > ---Lars > > >> + > >> + s5_temp_enable(hwmon); > >> + > >> + hwmon_dev = devm_hwmon_device_register_with_info(&pdev->dev, > >> + "s5_temp", > >> + hwmon, > >> + > >> &s5_chip_info, > >> + NULL); > >> + > >> + return PTR_ERR_OR_ZERO(hwmon_dev); > >> +} > >> + > >> +const struct of_device_id s5_temp_match[] = { > >> + { .compatible = "microchip,sparx5-temp" }, > >> + {}, > >> +}; > >> +MODULE_DEVICE_TABLE(of, s5_temp_match); > >> + > >> +static struct platform_driver s5_temp_driver = { > >> + .probe = s5_temp_probe, > >> + .driver = { > >> + .name = "sparx5-temp", > >> + .of_match_table = s5_temp_match, > >> + }, > >> +}; > >> + > >> +module_platform_driver(s5_temp_driver); > >> + > >> +MODULE_AUTHOR("Lars Povlsen <lars.povlsen@microchip.com>"); > >> +MODULE_DESCRIPTION("Sparx5 SoC temperature sensor driver"); > >> +MODULE_LICENSE("GPL"); > >> -- > >> 2.27.0 > >> > >> _______________________________________________ > >> linux-arm-kernel mailing list > >> linux-arm-kernel@lists.infradead.org > >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-06-09 13:03 UTC|newest] Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-06-09 7:28 [PATCH v2 0/3] hwmon: Adding support for Microchip Sparx5 SoC Lars Povlsen 2020-06-09 7:28 ` Lars Povlsen 2020-06-09 7:48 ` [PATCH v2 1/3] dt-bindings: hwmon: Add Sparx5 temperature sensor Lars Povlsen 2020-06-09 7:48 ` Lars Povlsen 2020-06-09 7:49 ` [PATCH v2 2/3] arm64: dts: sparx5: Add hwmon " Lars Povlsen 2020-06-09 7:49 ` Lars Povlsen 2020-06-09 7:49 ` [PATCH v2 3/3] hwmon: sparx5: Add Sparx5 SoC temperature driver Lars Povlsen 2020-06-09 7:49 ` Lars Povlsen 2020-06-09 8:38 ` Jonathan Cameron 2020-06-09 8:38 ` Jonathan Cameron 2020-06-09 12:20 ` Lars Povlsen 2020-06-09 12:20 ` Lars Povlsen 2020-06-09 13:03 ` Jonathan Cameron [this message] 2020-06-09 13:03 ` Jonathan Cameron 2020-06-09 12:54 ` Lars Povlsen 2020-06-09 12:54 ` Lars Povlsen 2020-06-09 13:50 ` [PATCH v2 0/3] hwmon: Adding support for Microchip Sparx5 SoC Guenter Roeck 2020-06-09 13:50 ` Guenter Roeck 2020-06-10 7:33 ` Lars Povlsen 2020-06-10 7:33 ` Lars Povlsen
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=20200609140313.00007187@huawei.com \ --to=jonathan.cameron@huawei.com \ --cc=UNGLinuxDriver@microchip.com \ --cc=alexandre.belloni@bootlin.com \ --cc=devicetree@vger.kernel.org \ --cc=jdelvare@suse.com \ --cc=lars.povlsen@microchip.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-hwmon@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux@roeck-us.net \ /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: linkBe 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.