[PATCH 0/6] thermal: Align devm_thermal_zone_{device,of_sensor}_register

[PATCH 0/6] thermal: Align devm_thermal_zone_{device,of_sensor}_register

[Marek Vasut]

This patchset attempts to align devm_thermal_zone_{device,of_sensor}_register()
functions and allow passing tz params to devm_thermal_zone_of_sensor_register()
to allow settings no_hwmon params without digging into the tz structures.

The approach is as follows:
1) Add {devm_,}thermal_zone_of_sensor_register_params(), which behaves just
   like the old variant without _params() suffix, except it takes the struct
   thermal_zone_params as an argument. The old _params()-less version of the
   function is converted to use the new function and pass params = NULL.
   The old _params()-less versions of the functions are retained to avoid
   breaking the ABI.
2) Add the no_hwmon handling into thermal_zone_of_sensor_register_params(),
   that's patch 3.
3) Convert drivers from devm_thermal_zone_of_sensor_register() with structure
   diggings to devm_thermal_zone_of_sensor_register_params() without any
   extra structure digging, that's the rest of the patches.

Marek Vasut (6):
  thermal: split thermal_zone_of_sensor_register{,_param}()
  thermal: split devm_thermal_zone_of_sensor_register{,_param}()
  thermal: Register hwmon in thermal_zone_of_sensor_register_param()
  thermal: stm32: Convert to
    devm_thermal_zone_of_sensor_register_params()
  thermal: rcar_thermal: Convert to
    devm_thermal_zone_of_sensor_register_params()
  thermal: rcar_gen3_thermal: Register hwmon sysfs interface

 drivers/thermal/of-thermal.c        | 104 +++++++++++++++++++++++++---
 drivers/thermal/rcar_gen3_thermal.c |   8 ++-
 drivers/thermal/rcar_thermal.c      |  33 ++++-----
 drivers/thermal/st/stm_thermal.c    |  20 ++----
 include/linux/thermal.h             |  25 +++++++
 5 files changed, 144 insertions(+), 46 deletions(-)

Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: linux-renesas-soc@vger.kernel.org
To: linux-pm@vger.kernel.org

-- 
2.18.0

[PATCH 1/6] thermal: split thermal_zone_of_sensor_register{,_param}()

[Marek Vasut]

Introduce new thermal_zone_of_sensor_register_params() function, which
allows passing struct thermal_zone_params into it and convert original
thermal_zone_of_sensor_register() to call it with params set to NULL.

Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: linux-renesas-soc@vger.kernel.org
To: linux-pm@vger.kernel.org
---
 drivers/thermal/of-thermal.c | 50 +++++++++++++++++++++++++++++++++---
 include/linux/thermal.h      | 12 +++++++++
 2 files changed, 59 insertions(+), 3 deletions(-)

diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
index 4bfdb4a1e47d..eb0ef7a21035 100644
--- a/drivers/thermal/of-thermal.c
+++ b/drivers/thermal/of-thermal.c
@@ -446,7 +446,8 @@ thermal_zone_of_add_sensor(struct device_node *zone,
 }
 
 /**
- * thermal_zone_of_sensor_register - registers a sensor to a DT thermal zone
+ * thermal_zone_of_sensor_register_params - registers a sensor to a DT thermal
+ *					zone with thermal zone parameters
  * @dev: a valid struct device pointer of a sensor device. Must contain
  *       a valid .of_node, for the sensor node.
  * @sensor_id: a sensor identifier, in case the sensor IP has more
@@ -454,6 +455,7 @@ thermal_zone_of_add_sensor(struct device_node *zone,
  * @data: a private pointer (owned by the caller) that will be passed
  *        back, when a temperature reading is needed.
  * @ops: struct thermal_zone_of_device_ops *. Must contain at least .get_temp.
+ * @tzp: thermal zone platform parameters
  *
  * This function will search the list of thermal zones described in device
  * tree and look for the zone that refer to the sensor device pointed by
@@ -478,8 +480,9 @@ thermal_zone_of_add_sensor(struct device_node *zone,
  * check the return value with help of IS_ERR() helper.
  */
 struct thermal_zone_device *
-thermal_zone_of_sensor_register(struct device *dev, int sensor_id, void *data,
-				const struct thermal_zone_of_device_ops *ops)
+thermal_zone_of_sensor_register_params(struct device *dev, int sensor_id,
+	void *data, const struct thermal_zone_of_device_ops *ops,
+	struct thermal_zone_params *tzp)
 {
 	struct device_node *np, *child, *sensor_np;
 	struct thermal_zone_device *tzd = ERR_PTR(-ENODEV);
@@ -533,6 +536,47 @@ thermal_zone_of_sensor_register(struct device *dev, int sensor_id, void *data,
 
 	return tzd;
 }
+
+/**
+ * thermal_zone_of_sensor_register - registers a sensor to a DT thermal zone
+ * @dev: a valid struct device pointer of a sensor device. Must contain
+ *       a valid .of_node, for the sensor node.
+ * @sensor_id: a sensor identifier, in case the sensor IP has more
+ *             than one sensors
+ * @data: a private pointer (owned by the caller) that will be passed
+ *        back, when a temperature reading is needed.
+ * @ops: struct thermal_zone_of_device_ops *. Must contain at least .get_temp.
+ *
+ * This function will search the list of thermal zones described in device
+ * tree and look for the zone that refer to the sensor device pointed by
+ * @dev->of_node as temperature providers. For the zone pointing to the
+ * sensor node, the sensor will be added to the DT thermal zone device.
+ *
+ * The thermal zone temperature is provided by the @get_temp function
+ * pointer. When called, it will have the private pointer @data back.
+ *
+ * The thermal zone temperature trend is provided by the @get_trend function
+ * pointer. When called, it will have the private pointer @data back.
+ *
+ * TODO:
+ * 01 - This function must enqueue the new sensor instead of using
+ * it as the only source of temperature values.
+ *
+ * 02 - There must be a way to match the sensor with all thermal zones
+ * that refer to it.
+ *
+ * Return: On success returns a valid struct thermal_zone_device,
+ * otherwise, it returns a corresponding ERR_PTR(). Caller must
+ * check the return value with help of IS_ERR() helper.
+ */
+
+struct thermal_zone_device *
+thermal_zone_of_sensor_register(struct device *dev, int sensor_id, void *data,
+				const struct thermal_zone_of_device_ops *ops)
+{
+	return thermal_zone_of_sensor_register_params(dev, sensor_id, data,
+						      ops, NULL);
+}
 EXPORT_SYMBOL_GPL(thermal_zone_of_sensor_register);
 
 /**
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index 5f4705f46c2f..922034eae74b 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -378,6 +378,10 @@ struct thermal_trip {
 struct thermal_zone_device *
 thermal_zone_of_sensor_register(struct device *dev, int id, void *data,
 				const struct thermal_zone_of_device_ops *ops);
+struct thermal_zone_device *
+thermal_zone_of_sensor_register_params(struct device *dev, int id, void *data,
+			const struct thermal_zone_of_device_ops *ops,
+			struct thermal_zone_params *tzp);
 void thermal_zone_of_sensor_unregister(struct device *dev,
 				       struct thermal_zone_device *tz);
 struct thermal_zone_device *devm_thermal_zone_of_sensor_register(
@@ -393,6 +397,14 @@ thermal_zone_of_sensor_register(struct device *dev, int id, void *data,
 	return ERR_PTR(-ENODEV);
 }
 
+static inline struct thermal_zone_device *
+thermal_zone_of_sensor_register_params(struct device *dev, int id, void *data,
+			const struct thermal_zone_of_device_ops *ops,
+			struct thermal_zone_params *tzp)
+{
+	return ERR_PTR(-ENODEV);
+}
+
 static inline
 void thermal_zone_of_sensor_unregister(struct device *dev,
 				       struct thermal_zone_device *tz)
-- 
2.18.0

[PATCH 2/6] thermal: split devm_thermal_zone_of_sensor_register{,_param}()

[Marek Vasut]

Introduce new split:devm_thermal_zone_of_sensor_register_params()
function, which allows passing struct thermal_zone_params into it
and convert original devm_thermal_zone_of_sensor_register() to call
it with params set to NULL.

Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: linux-renesas-soc@vger.kernel.org
To: linux-pm@vger.kernel.org
---
 drivers/thermal/of-thermal.c | 42 ++++++++++++++++++++++++++++++------
 include/linux/thermal.h      | 13 +++++++++++
 2 files changed, 49 insertions(+), 6 deletions(-)

diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
index eb0ef7a21035..901d8799587a 100644
--- a/drivers/thermal/of-thermal.c
+++ b/drivers/thermal/of-thermal.c
@@ -637,8 +637,8 @@ static int devm_thermal_zone_of_sensor_match(struct device *dev, void *res,
 }
 
 /**
- * devm_thermal_zone_of_sensor_register - Resource managed version of
- *				thermal_zone_of_sensor_register()
+ * devm_thermal_zone_of_sensor_register_params - Resource managed version of
+ *				thermal_zone_of_sensor_register_params()
  * @dev: a valid struct device pointer of a sensor device. Must contain
  *       a valid .of_node, for the sensor node.
  * @sensor_id: a sensor identifier, in case the sensor IP has more
@@ -646,8 +646,9 @@ static int devm_thermal_zone_of_sensor_match(struct device *dev, void *res,
  * @data: a private pointer (owned by the caller) that will be passed
  *	  back, when a temperature reading is needed.
  * @ops: struct thermal_zone_of_device_ops *. Must contain at least .get_temp.
+ * @tzp: thermal zone platform parameters
  *
- * Refer thermal_zone_of_sensor_register() for more details.
+ * Refer thermal_zone_of_sensor_register_params() for more details.
  *
  * Return: On success returns a valid struct thermal_zone_device,
  * otherwise, it returns a corresponding ERR_PTR(). Caller must
@@ -655,9 +656,10 @@ static int devm_thermal_zone_of_sensor_match(struct device *dev, void *res,
  * Registered thermal_zone_device device will automatically be
  * released when device is unbounded.
  */
-struct thermal_zone_device *devm_thermal_zone_of_sensor_register(
+struct thermal_zone_device *devm_thermal_zone_of_sensor_register_params(
 	struct device *dev, int sensor_id,
-	void *data, const struct thermal_zone_of_device_ops *ops)
+	void *data, const struct thermal_zone_of_device_ops *ops,
+	struct thermal_zone_params *tzp)
 {
 	struct thermal_zone_device **ptr, *tzd;
 
@@ -666,7 +668,8 @@ struct thermal_zone_device *devm_thermal_zone_of_sensor_register(
 	if (!ptr)
 		return ERR_PTR(-ENOMEM);
 
-	tzd = thermal_zone_of_sensor_register(dev, sensor_id, data, ops);
+	tzd = thermal_zone_of_sensor_register_params(dev, sensor_id, data,
+						     ops, tzp);
 	if (IS_ERR(tzd)) {
 		devres_free(ptr);
 		return tzd;
@@ -677,6 +680,33 @@ struct thermal_zone_device *devm_thermal_zone_of_sensor_register(
 
 	return tzd;
 }
+
+/**
+ * devm_thermal_zone_of_sensor_register - Resource managed version of
+ *				thermal_zone_of_sensor_register()
+ * @dev: a valid struct device pointer of a sensor device. Must contain
+ *       a valid .of_node, for the sensor node.
+ * @sensor_id: a sensor identifier, in case the sensor IP has more
+ *	       than one sensors
+ * @data: a private pointer (owned by the caller) that will be passed
+ *	  back, when a temperature reading is needed.
+ * @ops: struct thermal_zone_of_device_ops *. Must contain at least .get_temp.
+ *
+ * Refer thermal_zone_of_sensor_register() for more details.
+ *
+ * Return: On success returns a valid struct thermal_zone_device,
+ * otherwise, it returns a corresponding ERR_PTR(). Caller must
+ * check the return value with help of IS_ERR() helper.
+ * Registered thermal_zone_device device will automatically be
+ * released when device is unbounded.
+ */
+struct thermal_zone_device *devm_thermal_zone_of_sensor_register(
+	struct device *dev, int sensor_id,
+	void *data, const struct thermal_zone_of_device_ops *ops)
+{
+	return devm_thermal_zone_of_sensor_register_params(dev, sensor_id,
+							   data, ops, NULL);
+}
 EXPORT_SYMBOL_GPL(devm_thermal_zone_of_sensor_register);
 
 /**
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index 922034eae74b..a9e7bdeea1bb 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -387,6 +387,10 @@ void thermal_zone_of_sensor_unregister(struct device *dev,
 struct thermal_zone_device *devm_thermal_zone_of_sensor_register(
 		struct device *dev, int id, void *data,
 		const struct thermal_zone_of_device_ops *ops);
+struct thermal_zone_device *devm_thermal_zone_of_sensor_register_params(
+		struct device *dev, int id, void *data,
+		const struct thermal_zone_of_device_ops *ops,
+		struct thermal_zone_params *tzp);
 void devm_thermal_zone_of_sensor_unregister(struct device *dev,
 					    struct thermal_zone_device *tz);
 #else
@@ -418,6 +422,15 @@ static inline struct thermal_zone_device *devm_thermal_zone_of_sensor_register(
 	return ERR_PTR(-ENODEV);
 }
 
+static inline struct thermal_zone_device *
+	devm_thermal_zone_of_sensor_register_params(
+		struct device *dev, int id, void *data,
+		const struct thermal_zone_of_device_ops *ops,
+		struct thermal_zone_params *tzp)
+{
+	return ERR_PTR(-ENODEV);
+}
+
 static inline
 void devm_thermal_zone_of_sensor_unregister(struct device *dev,
 					    struct thermal_zone_device *tz)
-- 
2.18.0

[PATCH 3/6] thermal: Register hwmon in thermal_zone_of_sensor_register_param()

[Marek Vasut]

Register hwmon sysfs interface in thermal_zone_of_sensor_register_param()
in case thermal_zone_params->no_hwmon is set to false. This behavior is
the same as thermal_zone_device_register().

Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: linux-renesas-soc@vger.kernel.org
To: linux-pm@vger.kernel.org
---
 drivers/thermal/of-thermal.c | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
index 901d8799587a..39b2f2105d0b 100644
--- a/drivers/thermal/of-thermal.c
+++ b/drivers/thermal/of-thermal.c
@@ -15,6 +15,7 @@
 #include <linux/string.h>
 
 #include "thermal_core.h"
+#include "thermal_hwmon.h"
 
 /***   Private data structures to represent thermal device tree data ***/
 
@@ -521,8 +522,15 @@ thermal_zone_of_sensor_register_params(struct device *dev, int sensor_id,
 		if (sensor_specs.np == sensor_np && id == sensor_id) {
 			tzd = thermal_zone_of_add_sensor(child, sensor_np,
 							 data, ops);
-			if (!IS_ERR(tzd))
+			if (!IS_ERR(tzd)) {
+				tzd->tzp = tzp;
 				tzd->ops->set_mode(tzd, THERMAL_DEVICE_ENABLED);
+				if (!tzp || !tzp->no_hwmon) {
+					ret = thermal_add_hwmon_sysfs(tzd);
+					if (ret)
+						tzd = ERR_PTR(ret);
+				}
+			}
 
 			of_node_put(sensor_specs.np);
 			of_node_put(child);
@@ -604,6 +612,8 @@ void thermal_zone_of_sensor_unregister(struct device *dev,
 
 	tz = tzd->devdata;
 
+	thermal_remove_hwmon_sysfs(tzd);
+
 	/* no __thermal_zone, nothing to be done */
 	if (!tz)
 		return;
-- 
2.18.0

[PATCH 4/6] thermal: stm32: Convert to devm_thermal_zone_of_sensor_register_params()

[Marek Vasut]

Convert the stm32 code to devm_thermal_zone_of_sensor_register_params(),
no functional change.

Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: David HERNANDEZ SANCHEZ <david.hernandezsanchez@st.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: linux-renesas-soc@vger.kernel.org
Cc: linux-stm32@st-md-mailman.stormreply.com
To: linux-pm@vger.kernel.org
---
 drivers/thermal/st/stm_thermal.c | 20 ++++++--------------
 1 file changed, 6 insertions(+), 14 deletions(-)

diff --git a/drivers/thermal/st/stm_thermal.c b/drivers/thermal/st/stm_thermal.c
index 47623da0f91b..ee0915dfe96a 100644
--- a/drivers/thermal/st/stm_thermal.c
+++ b/drivers/thermal/st/stm_thermal.c
@@ -20,7 +20,6 @@
 #include <linux/thermal.h>
 
 #include "../thermal_core.h"
-#include "../thermal_hwmon.h"
 
 /* DTS register offsets */
 #define DTS_CFGR1_OFFSET	0x0
@@ -103,6 +102,10 @@ struct stm_thermal_sensor {
 	int t0, fmt0, ramp_coeff;
 };
 
+static struct thermal_zone_params stm_tz_ops = {
+	.no_hwmon	= false,
+};
+
 static irqreturn_t stm_thermal_alarm_irq(int irq, void *sdata)
 {
 	struct stm_thermal_sensor *sensor = sdata;
@@ -652,9 +655,8 @@ static int stm_thermal_probe(struct platform_device *pdev)
 	if (ret)
 		return ret;
 
-	sensor->th_dev = devm_thermal_zone_of_sensor_register(&pdev->dev, 0,
-							      sensor,
-							      &stm_tz_ops);
+	sensor->th_dev = devm_thermal_zone_of_sensor_register_params(&pdev->dev,
+				0, sensor, &stm_tz_ops, &stm_tz_ops);
 
 	if (IS_ERR(sensor->th_dev)) {
 		dev_err(&pdev->dev, "%s: thermal zone sensor registering KO\n",
@@ -711,15 +713,6 @@ static int stm_thermal_probe(struct platform_device *pdev)
 		goto err_tz;
 	}
 
-	/*
-	 * Thermal_zone doesn't enable hwmon as default,
-	 * enable it here
-	 */
-	sensor->th_dev->tzp->no_hwmon = false;
-	ret = thermal_add_hwmon_sysfs(sensor->th_dev);
-	if (ret)
-		goto err_tz;
-
 	sensor->mode = THERMAL_DEVICE_ENABLED;
 
 	dev_info(&pdev->dev, "%s: Driver initialized successfully\n",
@@ -737,7 +730,6 @@ static int stm_thermal_remove(struct platform_device *pdev)
 	struct stm_thermal_sensor *sensor = platform_get_drvdata(pdev);
 
 	stm_thermal_sensor_off(sensor);
-	thermal_remove_hwmon_sysfs(sensor->th_dev);
 	thermal_zone_of_sensor_unregister(&pdev->dev, sensor->th_dev);
 
 	return 0;
-- 
2.18.0

[PATCH 5/6] thermal: rcar_thermal: Convert to devm_thermal_zone_of_sensor_register_params()

[Marek Vasut]

Convert the rcar code to devm_thermal_zone_of_sensor_register_params(),
no functional change.

Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: linux-renesas-soc@vger.kernel.org
To: linux-pm@vger.kernel.org
---
 drivers/thermal/rcar_thermal.c | 33 +++++++++++++--------------------
 1 file changed, 13 insertions(+), 20 deletions(-)

diff --git a/drivers/thermal/rcar_thermal.c b/drivers/thermal/rcar_thermal.c
index 8014a207d8d9..ec70c2119c77 100644
--- a/drivers/thermal/rcar_thermal.c
+++ b/drivers/thermal/rcar_thermal.c
@@ -19,8 +19,6 @@
 #include <linux/spinlock.h>
 #include <linux/thermal.h>
 
-#include "thermal_hwmon.h"
-
 #define IDLE_INTERVAL	5000
 
 #define COMMON_STR	0x00
@@ -54,6 +52,10 @@ struct rcar_thermal_chip {
 	unsigned int nirqs;
 };
 
+static struct thermal_zone_params rcar_thermal_params = {
+	.no_hwmon	= false,
+};
+
 static const struct rcar_thermal_chip rcar_thermal = {
 	.use_of_thermal = 0,
 	.has_filonoff = 1,
@@ -458,9 +460,7 @@ static int rcar_thermal_remove(struct platform_device *pdev)
 	rcar_thermal_for_each_priv(priv, common) {
 		rcar_thermal_irq_disable(priv);
 		cancel_delayed_work_sync(&priv->work);
-		if (priv->chip->use_of_thermal)
-			thermal_remove_hwmon_sysfs(priv->zone);
-		else
+		if (!priv->chip->use_of_thermal)
 			thermal_zone_device_unregister(priv->zone);
 	}
 
@@ -554,16 +554,20 @@ static int rcar_thermal_probe(struct platform_device *pdev)
 		if (ret < 0)
 			goto error_unregister;
 
-		if (chip->use_of_thermal)
-			priv->zone = devm_thermal_zone_of_sensor_register(
+		if (chip->use_of_thermal) {
+			priv->zone =
+				devm_thermal_zone_of_sensor_register_params(
 						dev, i, priv,
-						&rcar_thermal_zone_of_ops);
-		else
+						&rcar_thermal_zone_of_ops,
+						&rcar_thermal_params);
+		} else {
 			priv->zone = thermal_zone_device_register(
 						"rcar_thermal",
 						1, 0, priv,
 						&rcar_thermal_zone_ops, NULL, 0,
 						idle);
+		}
+
 		if (IS_ERR(priv->zone)) {
 			dev_err(dev, "can't register thermal zone\n");
 			ret = PTR_ERR(priv->zone);
@@ -571,17 +575,6 @@ static int rcar_thermal_probe(struct platform_device *pdev)
 			goto error_unregister;
 		}
 
-		if (chip->use_of_thermal) {
-			/*
-			 * thermal_zone doesn't enable hwmon as default,
-			 * but, enable it here to keep compatible
-			 */
-			priv->zone->tzp->no_hwmon = false;
-			ret = thermal_add_hwmon_sysfs(priv->zone);
-			if (ret)
-				goto error_unregister;
-		}
-
 		rcar_thermal_irq_enable(priv);
 
 		list_move_tail(&priv->list, &common->head);
-- 
2.18.0

[PATCH 6/6] thermal: rcar_gen3_thermal: Register hwmon sysfs interface

[Marek Vasut]

Use devm_thermal_zone_of_sensor_register_params() with thermal zone
params to enable the hwmon sysfs interface.

Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: linux-renesas-soc@vger.kernel.org
To: linux-pm@vger.kernel.org
---
 drivers/thermal/rcar_gen3_thermal.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/thermal/rcar_gen3_thermal.c b/drivers/thermal/rcar_gen3_thermal.c
index 75786cc8e2f9..d86b8e746313 100644
--- a/drivers/thermal/rcar_gen3_thermal.c
+++ b/drivers/thermal/rcar_gen3_thermal.c
@@ -85,6 +85,10 @@ struct rcar_gen3_thermal_priv {
 	void (*thermal_init)(struct rcar_gen3_thermal_tsc *tsc);
 };
 
+static struct thermal_zone_params rcar_gen3_tz_of_params = {
+	.no_hwmon	= false,
+};
+
 static inline u32 rcar_gen3_thermal_read(struct rcar_gen3_thermal_tsc *tsc,
 					 u32 reg)
 {
@@ -416,8 +420,8 @@ static int rcar_gen3_thermal_probe(struct platform_device *pdev)
 		priv->thermal_init(tsc);
 		rcar_gen3_thermal_calc_coefs(&tsc->coef, ptat, thcode[i]);
 
-		zone = devm_thermal_zone_of_sensor_register(dev, i, tsc,
-							    &rcar_gen3_tz_of_ops);
+		zone = devm_thermal_zone_of_sensor_register_params(dev, i, tsc,
+				&rcar_gen3_tz_of_ops, &rcar_gen3_tz_of_params);
 		if (IS_ERR(zone)) {
 			dev_err(dev, "Can't register thermal zone\n");
 			ret = PTR_ERR(zone);
-- 
2.18.0

Re: [PATCH 6/6] thermal: rcar_gen3_thermal: Register hwmon sysfs interface

[kbuild test robot]

[-- Attachment #1: Type: text/plain, Size: 1253 bytes --]

Hi Marek,

I love your patch! Yet something to improve:

[auto build test ERROR on soc-thermal/next]
[also build test ERROR on v4.20-rc6 next-20181213]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Marek-Vasut/thermal-Align-devm_thermal_zone_-device-of_sensor-_register/20181212-185837
base:   https://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.git next
config: i386-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
        # save the attached .config to linux build tree
        make ARCH=i386 

All errors (new ones prefixed by >>):

   ERROR: "devm_thermal_zone_of_sensor_register_params" [drivers/thermal/rcar_thermal.ko] undefined!
>> ERROR: "devm_thermal_zone_of_sensor_register_params" [drivers/thermal/rcar_gen3_thermal.ko] undefined!
   make[2]: *** [__modpost] Error 1
   make[2]: Target '_modpost' not remade because of errors.
   make[1]: *** [modules] Error 2
   make[1]: Target '_all' not remade because of errors.

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 64925 bytes --]

Re: [PATCH 0/6] thermal: Align devm_thermal_zone_{device,of_sensor}_register

[Eduardo Valentin]

On Wed, Dec 12, 2018 at 02:49:21AM +0100, Marek Vasut wrote:
> This patchset attempts to align devm_thermal_zone_{device,of_sensor}_register()
> functions and allow passing tz params to devm_thermal_zone_of_sensor_register()
> to allow settings no_hwmon params without digging into the tz structures.
> 
> The approach is as follows:
> 1) Add {devm_,}thermal_zone_of_sensor_register_params(), which behaves just
>    like the old variant without _params() suffix, except it takes the struct
>    thermal_zone_params as an argument. The old _params()-less version of the
>    function is converted to use the new function and pass params = NULL.
>    The old _params()-less versions of the functions are retained to avoid
>    breaking the ABI.
> 2) Add the no_hwmon handling into thermal_zone_of_sensor_register_params(),
>    that's patch 3.
> 3) Convert drivers from devm_thermal_zone_of_sensor_register() with structure
>    diggings to devm_thermal_zone_of_sensor_register_params() without any
>    extra structure digging, that's the rest of the patches.
> 
> Marek Vasut (6):
>   thermal: split thermal_zone_of_sensor_register{,_param}()
>   thermal: split devm_thermal_zone_of_sensor_register{,_param}()
>   thermal: Register hwmon in thermal_zone_of_sensor_register_param()
>   thermal: stm32: Convert to
>     devm_thermal_zone_of_sensor_register_params()
>   thermal: rcar_thermal: Convert to
>     devm_thermal_zone_of_sensor_register_params()
>   thermal: rcar_gen3_thermal: Register hwmon sysfs interface
> 

Fix the errors reported by the bot and also please run checkpatch.pl on
your series.

>  drivers/thermal/of-thermal.c        | 104 +++++++++++++++++++++++++---
>  drivers/thermal/rcar_gen3_thermal.c |   8 ++-
>  drivers/thermal/rcar_thermal.c      |  33 ++++-----
>  drivers/thermal/st/stm_thermal.c    |  20 ++----
>  include/linux/thermal.h             |  25 +++++++
>  5 files changed, 144 insertions(+), 46 deletions(-)
> 
> Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
> Cc: Eduardo Valentin <edubezval@gmail.com>
> Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
> Cc: Zhang Rui <rui.zhang@intel.com>
> Cc: linux-renesas-soc@vger.kernel.org
> To: linux-pm@vger.kernel.org
> 
> -- 
> 2.18.0
> 

Re: [PATCH 0/6] thermal: Align devm_thermal_zone_{device,of_sensor}_register

[Marek Vasut]

On 12/15/2018 03:02 AM, Eduardo Valentin wrote:
> On Wed, Dec 12, 2018 at 02:49:21AM +0100, Marek Vasut wrote:
>> This patchset attempts to align devm_thermal_zone_{device,of_sensor}_register()
>> functions and allow passing tz params to devm_thermal_zone_of_sensor_register()
>> to allow settings no_hwmon params without digging into the tz structures.
>>
>> The approach is as follows:
>> 1) Add {devm_,}thermal_zone_of_sensor_register_params(), which behaves just
>>    like the old variant without _params() suffix, except it takes the struct
>>    thermal_zone_params as an argument. The old _params()-less version of the
>>    function is converted to use the new function and pass params = NULL.
>>    The old _params()-less versions of the functions are retained to avoid
>>    breaking the ABI.
>> 2) Add the no_hwmon handling into thermal_zone_of_sensor_register_params(),
>>    that's patch 3.
>> 3) Convert drivers from devm_thermal_zone_of_sensor_register() with structure
>>    diggings to devm_thermal_zone_of_sensor_register_params() without any
>>    extra structure digging, that's the rest of the patches.
>>
>> Marek Vasut (6):
>>   thermal: split thermal_zone_of_sensor_register{,_param}()
>>   thermal: split devm_thermal_zone_of_sensor_register{,_param}()
>>   thermal: Register hwmon in thermal_zone_of_sensor_register_param()
>>   thermal: stm32: Convert to
>>     devm_thermal_zone_of_sensor_register_params()
>>   thermal: rcar_thermal: Convert to
>>     devm_thermal_zone_of_sensor_register_params()
>>   thermal: rcar_gen3_thermal: Register hwmon sysfs interface
>>
> 
> Fix the errors reported by the bot and also please run checkpatch.pl on
> your series.

Working on it right now. Can you look at the 0001...0003 patches and
tell me if this is a valid approach ?

-- 
Best regards,
Marek Vasut

Re: [PATCH 0/6] thermal: Align devm_thermal_zone_{device,of_sensor}_register

[Eduardo Valentin]

On Sat, Dec 15, 2018 at 03:08:07AM +0100, Marek Vasut wrote:
> On 12/15/2018 03:02 AM, Eduardo Valentin wrote:
> > On Wed, Dec 12, 2018 at 02:49:21AM +0100, Marek Vasut wrote:
> >> This patchset attempts to align devm_thermal_zone_{device,of_sensor}_register()
> >> functions and allow passing tz params to devm_thermal_zone_of_sensor_register()
> >> to allow settings no_hwmon params without digging into the tz structures.
> >>
> >> The approach is as follows:
> >> 1) Add {devm_,}thermal_zone_of_sensor_register_params(), which behaves just
> >>    like the old variant without _params() suffix, except it takes the struct
> >>    thermal_zone_params as an argument. The old _params()-less version of the
> >>    function is converted to use the new function and pass params = NULL.
> >>    The old _params()-less versions of the functions are retained to avoid
> >>    breaking the ABI.
> >> 2) Add the no_hwmon handling into thermal_zone_of_sensor_register_params(),
> >>    that's patch 3.
> >> 3) Convert drivers from devm_thermal_zone_of_sensor_register() with structure
> >>    diggings to devm_thermal_zone_of_sensor_register_params() without any
> >>    extra structure digging, that's the rest of the patches.
> >>
> >> Marek Vasut (6):
> >>   thermal: split thermal_zone_of_sensor_register{,_param}()
> >>   thermal: split devm_thermal_zone_of_sensor_register{,_param}()
> >>   thermal: Register hwmon in thermal_zone_of_sensor_register_param()
> >>   thermal: stm32: Convert to
> >>     devm_thermal_zone_of_sensor_register_params()
> >>   thermal: rcar_thermal: Convert to
> >>     devm_thermal_zone_of_sensor_register_params()
> >>   thermal: rcar_gen3_thermal: Register hwmon sysfs interface
> >>
> > 
> > Fix the errors reported by the bot and also please run checkpatch.pl on
> > your series.
> 
> Working on it right now. Can you look at the 0001...0003 patches and
> tell me if this is a valid approach ?

Yes, the approach seams fine to me,

> 
> -- 
> Best regards,
> Marek Vasut

Re: [PATCH 1/6] thermal: split thermal_zone_of_sensor_register{,_param}()

[Eduardo Valentin]

On Wed, Dec 12, 2018 at 02:49:22AM +0100, Marek Vasut wrote:
> Introduce new thermal_zone_of_sensor_register_params() function, which
> allows passing struct thermal_zone_params into it and convert original
> thermal_zone_of_sensor_register() to call it with params set to NULL.
> 
> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>

Git complains about mismatch between From: and this SOB.

> Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
> Cc: Eduardo Valentin <edubezval@gmail.com>
> Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
> Cc: Zhang Rui <rui.zhang@intel.com>
> Cc: linux-renesas-soc@vger.kernel.org
> To: linux-pm@vger.kernel.org

I would prefer if you put your SOB at the bottom.

> ---
>  drivers/thermal/of-thermal.c | 50 +++++++++++++++++++++++++++++++++---
>  include/linux/thermal.h      | 12 +++++++++
>  2 files changed, 59 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
> index 4bfdb4a1e47d..eb0ef7a21035 100644
> --- a/drivers/thermal/of-thermal.c
> +++ b/drivers/thermal/of-thermal.c
> @@ -446,7 +446,8 @@ thermal_zone_of_add_sensor(struct device_node *zone,
>  }
>  
>  /**
> - * thermal_zone_of_sensor_register - registers a sensor to a DT thermal zone
> + * thermal_zone_of_sensor_register_params - registers a sensor to a DT thermal
> + *					zone with thermal zone parameters
>   * @dev: a valid struct device pointer of a sensor device. Must contain
>   *       a valid .of_node, for the sensor node.
>   * @sensor_id: a sensor identifier, in case the sensor IP has more
> @@ -454,6 +455,7 @@ thermal_zone_of_add_sensor(struct device_node *zone,
>   * @data: a private pointer (owned by the caller) that will be passed
>   *        back, when a temperature reading is needed.
>   * @ops: struct thermal_zone_of_device_ops *. Must contain at least .get_temp.
> + * @tzp: thermal zone platform parameters
>   *
>   * This function will search the list of thermal zones described in device
>   * tree and look for the zone that refer to the sensor device pointed by
> @@ -478,8 +480,9 @@ thermal_zone_of_add_sensor(struct device_node *zone,
>   * check the return value with help of IS_ERR() helper.
>   */
>  struct thermal_zone_device *
> -thermal_zone_of_sensor_register(struct device *dev, int sensor_id, void *data,
> -				const struct thermal_zone_of_device_ops *ops)
> +thermal_zone_of_sensor_register_params(struct device *dev, int sensor_id,
> +	void *data, const struct thermal_zone_of_device_ops *ops,
> +	struct thermal_zone_params *tzp)
>  {
>  	struct device_node *np, *child, *sensor_np;
>  	struct thermal_zone_device *tzd = ERR_PTR(-ENODEV);
> @@ -533,6 +536,47 @@ thermal_zone_of_sensor_register(struct device *dev, int sensor_id, void *data,
>  
>  	return tzd;
>  }
> +
> +/**
> + * thermal_zone_of_sensor_register - registers a sensor to a DT thermal zone
> + * @dev: a valid struct device pointer of a sensor device. Must contain
> + *       a valid .of_node, for the sensor node.
> + * @sensor_id: a sensor identifier, in case the sensor IP has more
> + *             than one sensors
> + * @data: a private pointer (owned by the caller) that will be passed
> + *        back, when a temperature reading is needed.
> + * @ops: struct thermal_zone_of_device_ops *. Must contain at least .get_temp.
> + *
> + * This function will search the list of thermal zones described in device
> + * tree and look for the zone that refer to the sensor device pointed by
> + * @dev->of_node as temperature providers. For the zone pointing to the
> + * sensor node, the sensor will be added to the DT thermal zone device.
> + *
> + * The thermal zone temperature is provided by the @get_temp function
> + * pointer. When called, it will have the private pointer @data back.
> + *
> + * The thermal zone temperature trend is provided by the @get_trend function
> + * pointer. When called, it will have the private pointer @data back.
> + *
> + * TODO:
> + * 01 - This function must enqueue the new sensor instead of using
> + * it as the only source of temperature values.
> + *
> + * 02 - There must be a way to match the sensor with all thermal zones
> + * that refer to it.
> + *
> + * Return: On success returns a valid struct thermal_zone_device,
> + * otherwise, it returns a corresponding ERR_PTR(). Caller must
> + * check the return value with help of IS_ERR() helper.
> + */
> +
> +struct thermal_zone_device *
> +thermal_zone_of_sensor_register(struct device *dev, int sensor_id, void *data,
> +				const struct thermal_zone_of_device_ops *ops)
> +{
> +	return thermal_zone_of_sensor_register_params(dev, sensor_id, data,
> +						      ops, NULL);
> +}
>  EXPORT_SYMBOL_GPL(thermal_zone_of_sensor_register);
>  
>  /**
> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
> index 5f4705f46c2f..922034eae74b 100644
> --- a/include/linux/thermal.h
> +++ b/include/linux/thermal.h
> @@ -378,6 +378,10 @@ struct thermal_trip {
>  struct thermal_zone_device *
>  thermal_zone_of_sensor_register(struct device *dev, int id, void *data,
>  				const struct thermal_zone_of_device_ops *ops);
> +struct thermal_zone_device *
> +thermal_zone_of_sensor_register_params(struct device *dev, int id, void *data,
> +			const struct thermal_zone_of_device_ops *ops,
> +			struct thermal_zone_params *tzp);
>  void thermal_zone_of_sensor_unregister(struct device *dev,
>  				       struct thermal_zone_device *tz);
>  struct thermal_zone_device *devm_thermal_zone_of_sensor_register(
> @@ -393,6 +397,14 @@ thermal_zone_of_sensor_register(struct device *dev, int id, void *data,
>  	return ERR_PTR(-ENODEV);
>  }
>  
> +static inline struct thermal_zone_device *
> +thermal_zone_of_sensor_register_params(struct device *dev, int id, void *data,
> +			const struct thermal_zone_of_device_ops *ops,
> +			struct thermal_zone_params *tzp)
> +{
> +	return ERR_PTR(-ENODEV);
> +}
> +
>  static inline
>  void thermal_zone_of_sensor_unregister(struct device *dev,
>  				       struct thermal_zone_device *tz)
> -- 
> 2.18.0
> 

Re: [PATCH 1/6] thermal: split thermal_zone_of_sensor_register{,_param}()

[Marek Vasut]

On 12/15/2018 06:23 PM, Eduardo Valentin wrote:
> On Wed, Dec 12, 2018 at 02:49:22AM +0100, Marek Vasut wrote:
>> Introduce new thermal_zone_of_sensor_register_params() function, which
>> allows passing struct thermal_zone_params into it and convert original
>> thermal_zone_of_sensor_register() to call it with params set to NULL.
>>
>> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
> 
> Git complains about mismatch between From: and this SOB.

I recall a discussion about gmail stripping the +foo tags from email
addresses. I can add a From: tag into the patch to override this
braindeath, or is there a better solution ?

>> Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
>> Cc: Eduardo Valentin <edubezval@gmail.com>
>> Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
>> Cc: Zhang Rui <rui.zhang@intel.com>
>> Cc: linux-renesas-soc@vger.kernel.org
>> To: linux-pm@vger.kernel.org
> 
> I would prefer if you put your SOB at the bottom.

[...]
-- 
Best regards,
Marek Vasut

Re: [PATCH 1/6] thermal: split thermal_zone_of_sensor_register{,_param}()

[Geert Uytterhoeven]

Hi Marek,

On Sat, Dec 15, 2018 at 7:38 PM Marek Vasut <marek.vasut@gmail.com> wrote:
> On 12/15/2018 06:23 PM, Eduardo Valentin wrote:
> > On Wed, Dec 12, 2018 at 02:49:22AM +0100, Marek Vasut wrote:
> >> Introduce new thermal_zone_of_sensor_register_params() function, which
> >> allows passing struct thermal_zone_params into it and convert original
> >> thermal_zone_of_sensor_register() to call it with params set to NULL.
> >>
> >> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
> >
> > Git complains about mismatch between From: and this SOB.
>
> I recall a discussion about gmail stripping the +foo tags from email
> addresses. I can add a From: tag into the patch to override this
> braindeath, or is there a better solution ?

Run the "git format-patch" command from a git repo where user.email
is marek.vasut@gmail.com, so it will retain the original From: tag in the
email body, as it is different?

> >> Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
> >> Cc: Eduardo Valentin <edubezval@gmail.com>
> >> Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
> >> Cc: Zhang Rui <rui.zhang@intel.com>
> >> Cc: linux-renesas-soc@vger.kernel.org
> >> To: linux-pm@vger.kernel.org
> >
> > I would prefer if you put your SOB at the bottom.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 1/6] thermal: split thermal_zone_of_sensor_register{,_param}()

[Marek Vasut]

On 12/15/2018 07:47 PM, Geert Uytterhoeven wrote:
> Hi Marek,
> 
> On Sat, Dec 15, 2018 at 7:38 PM Marek Vasut <marek.vasut@gmail.com> wrote:
>> On 12/15/2018 06:23 PM, Eduardo Valentin wrote:
>>> On Wed, Dec 12, 2018 at 02:49:22AM +0100, Marek Vasut wrote:
>>>> Introduce new thermal_zone_of_sensor_register_params() function, which
>>>> allows passing struct thermal_zone_params into it and convert original
>>>> thermal_zone_of_sensor_register() to call it with params set to NULL.
>>>>
>>>> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
>>>
>>> Git complains about mismatch between From: and this SOB.
>>
>> I recall a discussion about gmail stripping the +foo tags from email
>> addresses. I can add a From: tag into the patch to override this
>> braindeath, or is there a better solution ?
> 
> Run the "git format-patch" command from a git repo where user.email
> is marek.vasut@gmail.com, so it will retain the original From: tag in the
> email body, as it is different?

I can also manually patch the From tags or add them, but it's all
workarounds.

-- 
Best regards,
Marek Vasut

Re: [PATCH 1/6] thermal: split thermal_zone_of_sensor_register{,_param}()

[Geert Uytterhoeven]

Hi Marek,

On Sat, Dec 15, 2018 at 7:49 PM Marek Vasut <marek.vasut@gmail.com> wrote:
> On 12/15/2018 07:47 PM, Geert Uytterhoeven wrote:
> > On Sat, Dec 15, 2018 at 7:38 PM Marek Vasut <marek.vasut@gmail.com> wrote:
> >> On 12/15/2018 06:23 PM, Eduardo Valentin wrote:
> >>> On Wed, Dec 12, 2018 at 02:49:22AM +0100, Marek Vasut wrote:
> >>>> Introduce new thermal_zone_of_sensor_register_params() function, which
> >>>> allows passing struct thermal_zone_params into it and convert original
> >>>> thermal_zone_of_sensor_register() to call it with params set to NULL.
> >>>>
> >>>> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
> >>>
> >>> Git complains about mismatch between From: and this SOB.
> >>
> >> I recall a discussion about gmail stripping the +foo tags from email
> >> addresses. I can add a From: tag into the patch to override this
> >> braindeath, or is there a better solution ?
> >
> > Run the "git format-patch" command from a git repo where user.email
> > is marek.vasut@gmail.com, so it will retain the original From: tag in the
> > email body, as it is different?
>
> I can also manually patch the From tags or add them, but it's all
> workarounds.

Use a different outgoing email server? I use my ISP's.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 1/6] thermal: split thermal_zone_of_sensor_register{,_param}()

[Marek Vasut]

On 12/15/2018 07:54 PM, Geert Uytterhoeven wrote:
> Hi Marek,
> 
> On Sat, Dec 15, 2018 at 7:49 PM Marek Vasut <marek.vasut@gmail.com> wrote:
>> On 12/15/2018 07:47 PM, Geert Uytterhoeven wrote:
>>> On Sat, Dec 15, 2018 at 7:38 PM Marek Vasut <marek.vasut@gmail.com> wrote:
>>>> On 12/15/2018 06:23 PM, Eduardo Valentin wrote:
>>>>> On Wed, Dec 12, 2018 at 02:49:22AM +0100, Marek Vasut wrote:
>>>>>> Introduce new thermal_zone_of_sensor_register_params() function, which
>>>>>> allows passing struct thermal_zone_params into it and convert original
>>>>>> thermal_zone_of_sensor_register() to call it with params set to NULL.
>>>>>>
>>>>>> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
>>>>>
>>>>> Git complains about mismatch between From: and this SOB.
>>>>
>>>> I recall a discussion about gmail stripping the +foo tags from email
>>>> addresses. I can add a From: tag into the patch to override this
>>>> braindeath, or is there a better solution ?
>>>
>>> Run the "git format-patch" command from a git repo where user.email
>>> is marek.vasut@gmail.com, so it will retain the original From: tag in the
>>> email body, as it is different?
>>
>> I can also manually patch the From tags or add them, but it's all
>> workarounds.
> 
> Use a different outgoing email server? I use my ISP's.

Or maybe it'd make sense to fix git to handle the +tags correctly ?

-- 
Best regards,
Marek Vasut

Re: [PATCH 1/6] thermal: split thermal_zone_of_sensor_register{,_param}()

[Geert Uytterhoeven]

Hi Marek,

On Sat, Dec 15, 2018 at 8:07 PM Marek Vasut <marek.vasut@gmail.com> wrote:
> On 12/15/2018 07:54 PM, Geert Uytterhoeven wrote:
> > On Sat, Dec 15, 2018 at 7:49 PM Marek Vasut <marek.vasut@gmail.com> wrote:
> >> On 12/15/2018 07:47 PM, Geert Uytterhoeven wrote:
> >>> On Sat, Dec 15, 2018 at 7:38 PM Marek Vasut <marek.vasut@gmail.com> wrote:
> >>>> On 12/15/2018 06:23 PM, Eduardo Valentin wrote:
> >>>>> On Wed, Dec 12, 2018 at 02:49:22AM +0100, Marek Vasut wrote:
> >>>>>> Introduce new thermal_zone_of_sensor_register_params() function, which
> >>>>>> allows passing struct thermal_zone_params into it and convert original
> >>>>>> thermal_zone_of_sensor_register() to call it with params set to NULL.
> >>>>>>
> >>>>>> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
> >>>>>
> >>>>> Git complains about mismatch between From: and this SOB.
> >>>>
> >>>> I recall a discussion about gmail stripping the +foo tags from email
> >>>> addresses. I can add a From: tag into the patch to override this
> >>>> braindeath, or is there a better solution ?
> >>>
> >>> Run the "git format-patch" command from a git repo where user.email
> >>> is marek.vasut@gmail.com, so it will retain the original From: tag in the
> >>> email body, as it is different?
> >>
> >> I can also manually patch the From tags or add them, but it's all
> >> workarounds.
> >
> > Use a different outgoing email server? I use my ISP's.
>
> Or maybe it'd make sense to fix git to handle the +tags correctly ?

What needs to be fixed?
If user.email != From, git format-patch generates a From: header, else
it doesn't. Doesn't that make sense?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 1/6] thermal: split thermal_zone_of_sensor_register{,_param}()

[Marek Vasut]

On 12/15/2018 09:00 PM, Geert Uytterhoeven wrote:
> Hi Marek,
> 
> On Sat, Dec 15, 2018 at 8:07 PM Marek Vasut <marek.vasut@gmail.com> wrote:
>> On 12/15/2018 07:54 PM, Geert Uytterhoeven wrote:
>>> On Sat, Dec 15, 2018 at 7:49 PM Marek Vasut <marek.vasut@gmail.com> wrote:
>>>> On 12/15/2018 07:47 PM, Geert Uytterhoeven wrote:
>>>>> On Sat, Dec 15, 2018 at 7:38 PM Marek Vasut <marek.vasut@gmail.com> wrote:
>>>>>> On 12/15/2018 06:23 PM, Eduardo Valentin wrote:
>>>>>>> On Wed, Dec 12, 2018 at 02:49:22AM +0100, Marek Vasut wrote:
>>>>>>>> Introduce new thermal_zone_of_sensor_register_params() function, which
>>>>>>>> allows passing struct thermal_zone_params into it and convert original
>>>>>>>> thermal_zone_of_sensor_register() to call it with params set to NULL.
>>>>>>>>
>>>>>>>> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
>>>>>>>
>>>>>>> Git complains about mismatch between From: and this SOB.
>>>>>>
>>>>>> I recall a discussion about gmail stripping the +foo tags from email
>>>>>> addresses. I can add a From: tag into the patch to override this
>>>>>> braindeath, or is there a better solution ?
>>>>>
>>>>> Run the "git format-patch" command from a git repo where user.email
>>>>> is marek.vasut@gmail.com, so it will retain the original From: tag in the
>>>>> email body, as it is different?
>>>>
>>>> I can also manually patch the From tags or add them, but it's all
>>>> workarounds.
>>>
>>> Use a different outgoing email server? I use my ISP's.
>>
>> Or maybe it'd make sense to fix git to handle the +tags correctly ?
> 
> What needs to be fixed?
> If user.email != From, git format-patch generates a From: header, else
> it doesn't. Doesn't that make sense?

I believe the complaint here is that email address in From does not
match email address in SoB line, because some SMTP servers scrub the
+foo tag from From: and not from SoB-line . And yet, the SoB line is
from the same person/email address as the email address in From, so they
are equal. I think git should just ignore the +foo tag in SoB line.

-- 
Best regards,
Marek Vasut

Re: [PATCH 1/6] thermal: split thermal_zone_of_sensor_register{,_param}()

[Geert Uytterhoeven]

Hi Marek,

On Sat, Dec 15, 2018 at 9:13 PM Marek Vasut <marek.vasut@gmail.com> wrote:
> On 12/15/2018 09:00 PM, Geert Uytterhoeven wrote:
> > On Sat, Dec 15, 2018 at 8:07 PM Marek Vasut <marek.vasut@gmail.com> wrote:
> >> On 12/15/2018 07:54 PM, Geert Uytterhoeven wrote:
> >>> On Sat, Dec 15, 2018 at 7:49 PM Marek Vasut <marek.vasut@gmail.com> wrote:
> >>>> On 12/15/2018 07:47 PM, Geert Uytterhoeven wrote:
> >>>>> On Sat, Dec 15, 2018 at 7:38 PM Marek Vasut <marek.vasut@gmail.com> wrote:
> >>>>>> On 12/15/2018 06:23 PM, Eduardo Valentin wrote:
> >>>>>>> On Wed, Dec 12, 2018 at 02:49:22AM +0100, Marek Vasut wrote:
> >>>>>>>> Introduce new thermal_zone_of_sensor_register_params() function, which
> >>>>>>>> allows passing struct thermal_zone_params into it and convert original
> >>>>>>>> thermal_zone_of_sensor_register() to call it with params set to NULL.
> >>>>>>>>
> >>>>>>>> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
> >>>>>>>
> >>>>>>> Git complains about mismatch between From: and this SOB.
> >>>>>>
> >>>>>> I recall a discussion about gmail stripping the +foo tags from email
> >>>>>> addresses. I can add a From: tag into the patch to override this
> >>>>>> braindeath, or is there a better solution ?
> >>>>>
> >>>>> Run the "git format-patch" command from a git repo where user.email
> >>>>> is marek.vasut@gmail.com, so it will retain the original From: tag in the
> >>>>> email body, as it is different?
> >>>>
> >>>> I can also manually patch the From tags or add them, but it's all
> >>>> workarounds.
> >>>
> >>> Use a different outgoing email server? I use my ISP's.
> >>
> >> Or maybe it'd make sense to fix git to handle the +tags correctly ?
> >
> > What needs to be fixed?
> > If user.email != From, git format-patch generates a From: header, else
> > it doesn't. Doesn't that make sense?
>
> I believe the complaint here is that email address in From does not
> match email address in SoB line, because some SMTP servers scrub the
> +foo tag from From: and not from SoB-line . And yet, the SoB line is

Some SMTP servers (Hi Gmail!) scrub the +foo tag from the From: _header_
in the email. As the SoB is in the _body_ it is not affected.
Hence the solution is to include the correct From: in the _body_.

Git actually does that automatically, assumed your user.email config matches
the From: address that is used in your outgoing email delivery path (i.e. the
scrubbed one, when using Gmail's SMTP server).
If you lie to git in your user.email config, git cannot do the right
thing, obviously.

> from the same person/email address as the email address in From, so they
> are equal.

If they differ, they are not equal ;-)
While many mail servers ignore +foo when delivering email to mailboxes,
this is not the case for all of them.  So ignoring +foo is not the universal
solution.

> I think git should just ignore the +foo tag in SoB line.

Where should "git" ignore the +foo tag? Is it actually git that complains?
Eduardo: Do you mean checkpatch? ;-)

I did enhance checkpatch with a check to verify that patches carry SoB tags
from their authors, as too many people got that wrong, causing complaints
from sfr in linux-next later. As usual, it's better to get things right as early
as possible in the process, to avoid rework.

So the problem is on the patch sending side, not on the patch verification
receiving side.
Hence please fix your email setup, thanks!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 1/6] thermal: split thermal_zone_of_sensor_register{,_param}()

[Marek Vasut]

On 12/16/2018 09:39 AM, Geert Uytterhoeven wrote:
> Hi Marek,

Hi,

> On Sat, Dec 15, 2018 at 9:13 PM Marek Vasut <marek.vasut@gmail.com> wrote:
>> On 12/15/2018 09:00 PM, Geert Uytterhoeven wrote:
>>> On Sat, Dec 15, 2018 at 8:07 PM Marek Vasut <marek.vasut@gmail.com> wrote:
>>>> On 12/15/2018 07:54 PM, Geert Uytterhoeven wrote:
>>>>> On Sat, Dec 15, 2018 at 7:49 PM Marek Vasut <marek.vasut@gmail.com> wrote:
>>>>>> On 12/15/2018 07:47 PM, Geert Uytterhoeven wrote:
>>>>>>> On Sat, Dec 15, 2018 at 7:38 PM Marek Vasut <marek.vasut@gmail.com> wrote:
>>>>>>>> On 12/15/2018 06:23 PM, Eduardo Valentin wrote:
>>>>>>>>> On Wed, Dec 12, 2018 at 02:49:22AM +0100, Marek Vasut wrote:
>>>>>>>>>> Introduce new thermal_zone_of_sensor_register_params() function, which
>>>>>>>>>> allows passing struct thermal_zone_params into it and convert original
>>>>>>>>>> thermal_zone_of_sensor_register() to call it with params set to NULL.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
>>>>>>>>>
>>>>>>>>> Git complains about mismatch between From: and this SOB.
>>>>>>>>
>>>>>>>> I recall a discussion about gmail stripping the +foo tags from email
>>>>>>>> addresses. I can add a From: tag into the patch to override this
>>>>>>>> braindeath, or is there a better solution ?
>>>>>>>
>>>>>>> Run the "git format-patch" command from a git repo where user.email
>>>>>>> is marek.vasut@gmail.com, so it will retain the original From: tag in the
>>>>>>> email body, as it is different?
>>>>>>
>>>>>> I can also manually patch the From tags or add them, but it's all
>>>>>> workarounds.
>>>>>
>>>>> Use a different outgoing email server? I use my ISP's.
>>>>
>>>> Or maybe it'd make sense to fix git to handle the +tags correctly ?
>>>
>>> What needs to be fixed?
>>> If user.email != From, git format-patch generates a From: header, else
>>> it doesn't. Doesn't that make sense?
>>
>> I believe the complaint here is that email address in From does not
>> match email address in SoB line, because some SMTP servers scrub the
>> +foo tag from From: and not from SoB-line . And yet, the SoB line is
> 
> Some SMTP servers (Hi Gmail!) scrub the +foo tag from the From: _header_
> in the email. As the SoB is in the _body_ it is not affected.
> Hence the solution is to include the correct From: in the _body_.

This is basically what I said.

> Git actually does that automatically, assumed your user.email config matches
> the From: address that is used in your outgoing email delivery path (i.e. the
> scrubbed one, when using Gmail's SMTP server).
> If you lie to git in your user.email config, git cannot do the right
> thing, obviously.

My git user.email obviously matches the From: field , before the
scrubbing, which I believe is the correct thing to do.

>> from the same person/email address as the email address in From, so they
>> are equal.
> 
> If they differ, they are not equal ;-)

Depends on how you define 'equal' . Here I think foo+bar@example.com
should be considered equal to foo@example.com .

> While many mail servers ignore +foo when delivering email to mailboxes,
> this is not the case for all of them.  So ignoring +foo is not the universal
> solution.
> 
>> I think git should just ignore the +foo tag in SoB line.
> 
> Where should "git" ignore the +foo tag? Is it actually git that complains?
> Eduardo: Do you mean checkpatch? ;-)

Possibly. I ran checkpatch after git format-patch and it didn't complain.

> I did enhance checkpatch with a check to verify that patches carry SoB tags
> from their authors, as too many people got that wrong, causing complaints
> from sfr in linux-next later. As usual, it's better to get things right as early
> as possible in the process, to avoid rework.

Aha, so maybe that enhancement needs further enhancement to scrub the
+tags before the check ?

> So the problem is on the patch sending side, not on the patch verification
> receiving side.
> Hence please fix your email setup, thanks!

See above.

-- 
Best regards,
Marek Vasut

Re: [PATCH 1/6] thermal: split thermal_zone_of_sensor_register{,_param}()

[Geert Uytterhoeven]

Hi Marek,

On Sun, Dec 16, 2018 at 6:25 PM Marek Vasut <marek.vasut@gmail.com> wrote:
> On 12/16/2018 09:39 AM, Geert Uytterhoeven wrote:
> > On Sat, Dec 15, 2018 at 9:13 PM Marek Vasut <marek.vasut@gmail.com> wrote:
> >> On 12/15/2018 09:00 PM, Geert Uytterhoeven wrote:
> >>> On Sat, Dec 15, 2018 at 8:07 PM Marek Vasut <marek.vasut@gmail.com> wrote:
> >>>> On 12/15/2018 07:54 PM, Geert Uytterhoeven wrote:
> >>>>> On Sat, Dec 15, 2018 at 7:49 PM Marek Vasut <marek.vasut@gmail.com> wrote:
> >>>>>> On 12/15/2018 07:47 PM, Geert Uytterhoeven wrote:
> >>>>>>> On Sat, Dec 15, 2018 at 7:38 PM Marek Vasut <marek.vasut@gmail.com> wrote:
> >>>>>>>> On 12/15/2018 06:23 PM, Eduardo Valentin wrote:
> >>>>>>>>> On Wed, Dec 12, 2018 at 02:49:22AM +0100, Marek Vasut wrote:
> >>>>>>>>>> Introduce new thermal_zone_of_sensor_register_params() function, which
> >>>>>>>>>> allows passing struct thermal_zone_params into it and convert original
> >>>>>>>>>> thermal_zone_of_sensor_register() to call it with params set to NULL.
> >>>>>>>>>>
> >>>>>>>>>> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
> >>>>>>>>>
> >>>>>>>>> Git complains about mismatch between From: and this SOB.
> >>>>>>>>
> >>>>>>>> I recall a discussion about gmail stripping the +foo tags from email
> >>>>>>>> addresses. I can add a From: tag into the patch to override this
> >>>>>>>> braindeath, or is there a better solution ?
> >>>>>>>
> >>>>>>> Run the "git format-patch" command from a git repo where user.email
> >>>>>>> is marek.vasut@gmail.com, so it will retain the original From: tag in the
> >>>>>>> email body, as it is different?
> >>>>>>
> >>>>>> I can also manually patch the From tags or add them, but it's all
> >>>>>> workarounds.
> >>>>>
> >>>>> Use a different outgoing email server? I use my ISP's.
> >>>>
> >>>> Or maybe it'd make sense to fix git to handle the +tags correctly ?
> >>>
> >>> What needs to be fixed?
> >>> If user.email != From, git format-patch generates a From: header, else
> >>> it doesn't. Doesn't that make sense?
> >>
> >> I believe the complaint here is that email address in From does not
> >> match email address in SoB line, because some SMTP servers scrub the
> >> +foo tag from From: and not from SoB-line . And yet, the SoB line is
> >
> > Some SMTP servers (Hi Gmail!) scrub the +foo tag from the From: _header_
> > in the email. As the SoB is in the _body_ it is not affected.
> > Hence the solution is to include the correct From: in the _body_.
>
> This is basically what I said.
>
> > Git actually does that automatically, assumed your user.email config matches
> > the From: address that is used in your outgoing email delivery path (i.e. the
> > scrubbed one, when using Gmail's SMTP server).
> > If you lie to git in your user.email config, git cannot do the right
> > thing, obviously.
>
> My git user.email obviously matches the From: field , before the
> scrubbing, which I believe is the correct thing to do.

I disagree, because that is not how the emails are actually going out from the
SMTP server you are using.

> >> from the same person/email address as the email address in From, so they
> >> are equal.
> >
> > If they differ, they are not equal ;-)
>
> Depends on how you define 'equal' . Here I think foo+bar@example.com
> should be considered equal to foo@example.com .

That is domain-specific knowledge, which you cannot rely upon.

> > While many mail servers ignore +foo when delivering email to mailboxes,
> > this is not the case for all of them.  So ignoring +foo is not the universal
> > solution.
> >
> >> I think git should just ignore the +foo tag in SoB line.
> >
> > Where should "git" ignore the +foo tag? Is it actually git that complains?
> > Eduardo: Do you mean checkpatch? ;-)
>
> Possibly. I ran checkpatch after git format-patch and it didn't complain.
>
> > I did enhance checkpatch with a check to verify that patches carry SoB tags
> > from their authors, as too many people got that wrong, causing complaints
> > from sfr in linux-next later. As usual, it's better to get things right as early
> > as possible in the process, to avoid rework.
>
> Aha, so maybe that enhancement needs further enhancement to scrub the
> +tags before the check ?

Again, that is domain-specific knowledge, which you cannot rely upon.

> > So the problem is on the patch sending side, not on the patch verification
> > receiving side.
> > Hence please fix your email setup, thanks!
>
> See above.

How is any of this different from people making mistakes trying to send
patches through a not-to-be-named corporate email system?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 1/6] thermal: split thermal_zone_of_sensor_register{,_param}()

[Marek Vasut]

On 12/16/2018 06:42 PM, Geert Uytterhoeven wrote:
> Hi Marek,
> 
> On Sun, Dec 16, 2018 at 6:25 PM Marek Vasut <marek.vasut@gmail.com> wrote:
>> On 12/16/2018 09:39 AM, Geert Uytterhoeven wrote:
>>> On Sat, Dec 15, 2018 at 9:13 PM Marek Vasut <marek.vasut@gmail.com> wrote:
>>>> On 12/15/2018 09:00 PM, Geert Uytterhoeven wrote:
>>>>> On Sat, Dec 15, 2018 at 8:07 PM Marek Vasut <marek.vasut@gmail.com> wrote:
>>>>>> On 12/15/2018 07:54 PM, Geert Uytterhoeven wrote:
>>>>>>> On Sat, Dec 15, 2018 at 7:49 PM Marek Vasut <marek.vasut@gmail.com> wrote:
>>>>>>>> On 12/15/2018 07:47 PM, Geert Uytterhoeven wrote:
>>>>>>>>> On Sat, Dec 15, 2018 at 7:38 PM Marek Vasut <marek.vasut@gmail.com> wrote:
>>>>>>>>>> On 12/15/2018 06:23 PM, Eduardo Valentin wrote:
>>>>>>>>>>> On Wed, Dec 12, 2018 at 02:49:22AM +0100, Marek Vasut wrote:
>>>>>>>>>>>> Introduce new thermal_zone_of_sensor_register_params() function, which
>>>>>>>>>>>> allows passing struct thermal_zone_params into it and convert original
>>>>>>>>>>>> thermal_zone_of_sensor_register() to call it with params set to NULL.
>>>>>>>>>>>>
>>>>>>>>>>>> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
>>>>>>>>>>>
>>>>>>>>>>> Git complains about mismatch between From: and this SOB.
>>>>>>>>>>
>>>>>>>>>> I recall a discussion about gmail stripping the +foo tags from email
>>>>>>>>>> addresses. I can add a From: tag into the patch to override this
>>>>>>>>>> braindeath, or is there a better solution ?
>>>>>>>>>
>>>>>>>>> Run the "git format-patch" command from a git repo where user.email
>>>>>>>>> is marek.vasut@gmail.com, so it will retain the original From: tag in the
>>>>>>>>> email body, as it is different?
>>>>>>>>
>>>>>>>> I can also manually patch the From tags or add them, but it's all
>>>>>>>> workarounds.
>>>>>>>
>>>>>>> Use a different outgoing email server? I use my ISP's.
>>>>>>
>>>>>> Or maybe it'd make sense to fix git to handle the +tags correctly ?
>>>>>
>>>>> What needs to be fixed?
>>>>> If user.email != From, git format-patch generates a From: header, else
>>>>> it doesn't. Doesn't that make sense?
>>>>
>>>> I believe the complaint here is that email address in From does not
>>>> match email address in SoB line, because some SMTP servers scrub the
>>>> +foo tag from From: and not from SoB-line . And yet, the SoB line is
>>>
>>> Some SMTP servers (Hi Gmail!) scrub the +foo tag from the From: _header_
>>> in the email. As the SoB is in the _body_ it is not affected.
>>> Hence the solution is to include the correct From: in the _body_.
>>
>> This is basically what I said.
>>
>>> Git actually does that automatically, assumed your user.email config matches
>>> the From: address that is used in your outgoing email delivery path (i.e. the
>>> scrubbed one, when using Gmail's SMTP server).
>>> If you lie to git in your user.email config, git cannot do the right
>>> thing, obviously.
>>
>> My git user.email obviously matches the From: field , before the
>> scrubbing, which I believe is the correct thing to do.
> 
> I disagree, because that is not how the emails are actually going out from the
> SMTP server you are using.

Can you summarize, clearly, what you believe is the right thing to
configure and where ?

>>>> from the same person/email address as the email address in From, so they
>>>> are equal.
>>>
>>> If they differ, they are not equal ;-)
>>
>> Depends on how you define 'equal' . Here I think foo+bar@example.com
>> should be considered equal to foo@example.com .
> 
> That is domain-specific knowledge, which you cannot rely upon.
> 
>>> While many mail servers ignore +foo when delivering email to mailboxes,
>>> this is not the case for all of them.  So ignoring +foo is not the universal
>>> solution.
>>>
>>>> I think git should just ignore the +foo tag in SoB line.
>>>
>>> Where should "git" ignore the +foo tag? Is it actually git that complains?
>>> Eduardo: Do you mean checkpatch? ;-)
>>
>> Possibly. I ran checkpatch after git format-patch and it didn't complain.
>>
>>> I did enhance checkpatch with a check to verify that patches carry SoB tags
>>> from their authors, as too many people got that wrong, causing complaints
>>> from sfr in linux-next later. As usual, it's better to get things right as early
>>> as possible in the process, to avoid rework.
>>
>> Aha, so maybe that enhancement needs further enhancement to scrub the
>> +tags before the check ?
> 
> Again, that is domain-specific knowledge, which you cannot rely upon.

How so, please elaborate .

>>> So the problem is on the patch sending side, not on the patch verification
>>> receiving side.
>>> Hence please fix your email setup, thanks!
>>
>> See above.
> 
> How is any of this different from people making mistakes trying to send
> patches through a not-to-be-named corporate email system?

I lost you here.

-- 
Best regards,
Marek Vasut

Re: [PATCH 1/6] thermal: split thermal_zone_of_sensor_register{,_param}()

[Geert Uytterhoeven]

Hi Marek,

On Sun, Dec 16, 2018 at 6:49 PM Marek Vasut <marek.vasut@gmail.com> wrote:
> On 12/16/2018 06:42 PM, Geert Uytterhoeven wrote:
> > On Sun, Dec 16, 2018 at 6:25 PM Marek Vasut <marek.vasut@gmail.com> wrote:
> >> On 12/16/2018 09:39 AM, Geert Uytterhoeven wrote:
> >>> On Sat, Dec 15, 2018 at 9:13 PM Marek Vasut <marek.vasut@gmail.com> wrote:
> >>>> On 12/15/2018 09:00 PM, Geert Uytterhoeven wrote:
> >>>>> On Sat, Dec 15, 2018 at 8:07 PM Marek Vasut <marek.vasut@gmail.com> wrote:
> >>>>>> On 12/15/2018 07:54 PM, Geert Uytterhoeven wrote:
> >>>>>>> On Sat, Dec 15, 2018 at 7:49 PM Marek Vasut <marek.vasut@gmail.com> wrote:
> >>>>>>>> On 12/15/2018 07:47 PM, Geert Uytterhoeven wrote:
> >>>>>>>>> On Sat, Dec 15, 2018 at 7:38 PM Marek Vasut <marek.vasut@gmail.com> wrote:
> >>>>>>>>>> On 12/15/2018 06:23 PM, Eduardo Valentin wrote:
> >>>>>>>>>>> On Wed, Dec 12, 2018 at 02:49:22AM +0100, Marek Vasut wrote:
> >>>>>>>>>>>> Introduce new thermal_zone_of_sensor_register_params() function, which
> >>>>>>>>>>>> allows passing struct thermal_zone_params into it and convert original
> >>>>>>>>>>>> thermal_zone_of_sensor_register() to call it with params set to NULL.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
> >>>>>>>>>>>
> >>>>>>>>>>> Git complains about mismatch between From: and this SOB.
> >>>>>>>>>>
> >>>>>>>>>> I recall a discussion about gmail stripping the +foo tags from email
> >>>>>>>>>> addresses. I can add a From: tag into the patch to override this
> >>>>>>>>>> braindeath, or is there a better solution ?
> >>>>>>>>>
> >>>>>>>>> Run the "git format-patch" command from a git repo where user.email
> >>>>>>>>> is marek.vasut@gmail.com, so it will retain the original From: tag in the
> >>>>>>>>> email body, as it is different?
> >>>>>>>>
> >>>>>>>> I can also manually patch the From tags or add them, but it's all
> >>>>>>>> workarounds.
> >>>>>>>
> >>>>>>> Use a different outgoing email server? I use my ISP's.
> >>>>>>
> >>>>>> Or maybe it'd make sense to fix git to handle the +tags correctly ?
> >>>>>
> >>>>> What needs to be fixed?
> >>>>> If user.email != From, git format-patch generates a From: header, else
> >>>>> it doesn't. Doesn't that make sense?
> >>>>
> >>>> I believe the complaint here is that email address in From does not
> >>>> match email address in SoB line, because some SMTP servers scrub the
> >>>> +foo tag from From: and not from SoB-line . And yet, the SoB line is
> >>>
> >>> Some SMTP servers (Hi Gmail!) scrub the +foo tag from the From: _header_
> >>> in the email. As the SoB is in the _body_ it is not affected.
> >>> Hence the solution is to include the correct From: in the _body_.
> >>
> >> This is basically what I said.
> >>
> >>> Git actually does that automatically, assumed your user.email config matches
> >>> the From: address that is used in your outgoing email delivery path (i.e. the
> >>> scrubbed one, when using Gmail's SMTP server).
> >>> If you lie to git in your user.email config, git cannot do the right
> >>> thing, obviously.
> >>
> >> My git user.email obviously matches the From: field , before the
> >> scrubbing, which I believe is the correct thing to do.
> >
> > I disagree, because that is not how the emails are actually going out from the
> > SMTP server you are using.
>
> Can you summarize, clearly, what you believe is the right thing to
> configure and where ?

According to git-send-email(1), you can either pass your scrubbed email
address to --from, or configure it in the sendemail.from config option.
Does that work for you?

> >>>> from the same person/email address as the email address in From, so they
> >>>> are equal.
> >>>
> >>> If they differ, they are not equal ;-)
> >>
> >> Depends on how you define 'equal' . Here I think foo+bar@example.com
> >> should be considered equal to foo@example.com .
> >
> > That is domain-specific knowledge, which you cannot rely upon.

> >> Aha, so maybe that enhancement needs further enhancement to scrub the
> >> +tags before the check ?
> >
> > Again, that is domain-specific knowledge, which you cannot rely upon.
>
> How so, please elaborate .

In general, you cannot assume the "+foo" part can be ignored. Only the sender
knows.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 1/6] thermal: split thermal_zone_of_sensor_register{,_param}()

[Marek Vasut]

On 12/16/2018 09:08 PM, Geert Uytterhoeven wrote:
[...]

>>>>> Git actually does that automatically, assumed your user.email config matches
>>>>> the From: address that is used in your outgoing email delivery path (i.e. the
>>>>> scrubbed one, when using Gmail's SMTP server).
>>>>> If you lie to git in your user.email config, git cannot do the right
>>>>> thing, obviously.
>>>>
>>>> My git user.email obviously matches the From: field , before the
>>>> scrubbing, which I believe is the correct thing to do.
>>>
>>> I disagree, because that is not how the emails are actually going out from the
>>> SMTP server you are using.
>>
>> Can you summarize, clearly, what you believe is the right thing to
>> configure and where ?
> 
> According to git-send-email(1), you can either pass your scrubbed email
> address to --from, or configure it in the sendemail.from config option.
> Does that work for you?

So sendemail.from != user.email , the later has the +tag while the
former does not ?

>>>>>> from the same person/email address as the email address in From, so they
>>>>>> are equal.
>>>>>
>>>>> If they differ, they are not equal ;-)
>>>>
>>>> Depends on how you define 'equal' . Here I think foo+bar@example.com
>>>> should be considered equal to foo@example.com .
>>>
>>> That is domain-specific knowledge, which you cannot rely upon.
> 
>>>> Aha, so maybe that enhancement needs further enhancement to scrub the
>>>> +tags before the check ?
>>>
>>> Again, that is domain-specific knowledge, which you cannot rely upon.
>>
>> How so, please elaborate .
> 
> In general, you cannot assume the "+foo" part can be ignored. Only the sender
> knows.

How so ?

-- 
Best regards,
Marek Vasut

Re: [PATCH 1/6] thermal: split thermal_zone_of_sensor_register{,_param}()

[Geert Uytterhoeven]

Hi Marek,

On Sun, Dec 16, 2018 at 9:50 PM Marek Vasut <marek.vasut@gmail.com> wrote:
> On 12/16/2018 09:08 PM, Geert Uytterhoeven wrote:
> [...]
>
> >>>>> Git actually does that automatically, assumed your user.email config matches
> >>>>> the From: address that is used in your outgoing email delivery path (i.e. the
> >>>>> scrubbed one, when using Gmail's SMTP server).
> >>>>> If you lie to git in your user.email config, git cannot do the right
> >>>>> thing, obviously.
> >>>>
> >>>> My git user.email obviously matches the From: field , before the
> >>>> scrubbing, which I believe is the correct thing to do.
> >>>
> >>> I disagree, because that is not how the emails are actually going out from the
> >>> SMTP server you are using.
> >>
> >> Can you summarize, clearly, what you believe is the right thing to
> >> configure and where ?
> >
> > According to git-send-email(1), you can either pass your scrubbed email
> > address to --from, or configure it in the sendemail.from config option.
> > Does that work for you?
>
> So sendemail.from != user.email , the later has the +tag while the
> former does not ?

Right.

> >>>>>> from the same person/email address as the email address in From, so they
> >>>>>> are equal.
> >>>>>
> >>>>> If they differ, they are not equal ;-)
> >>>>
> >>>> Depends on how you define 'equal' . Here I think foo+bar@example.com
> >>>> should be considered equal to foo@example.com .
> >>>
> >>> That is domain-specific knowledge, which you cannot rely upon.
> >
> >>>> Aha, so maybe that enhancement needs further enhancement to scrub the
> >>>> +tags before the check ?
> >>>
> >>> Again, that is domain-specific knowledge, which you cannot rely upon.
> >>
> >> How so, please elaborate .
> >
> > In general, you cannot assume the "+foo" part can be ignored. Only the sender
> > knows.
>
> How so ?

It depends on the domain.

Is Bill.Gates@microsoft.com the same email address as
Bill.Gates+foo@microsoft.com?
Is Bill.Gates+1955@microsoft.com the same?
Is Bill.Gates-1955@microsoft.com the same?

I don't know. Only microsoft.com knows.
So that's why you should compare email addresses verbatim (but case
insensitive).

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 1/6] thermal: split thermal_zone_of_sensor_register{,_param}()

[Marek Vasut]

On 12/17/2018 02:26 PM, Geert Uytterhoeven wrote:
> Hi Marek,
> 
> On Sun, Dec 16, 2018 at 9:50 PM Marek Vasut <marek.vasut@gmail.com> wrote:
>> On 12/16/2018 09:08 PM, Geert Uytterhoeven wrote:
>> [...]
>>
>>>>>>> Git actually does that automatically, assumed your user.email config matches
>>>>>>> the From: address that is used in your outgoing email delivery path (i.e. the
>>>>>>> scrubbed one, when using Gmail's SMTP server).
>>>>>>> If you lie to git in your user.email config, git cannot do the right
>>>>>>> thing, obviously.
>>>>>>
>>>>>> My git user.email obviously matches the From: field , before the
>>>>>> scrubbing, which I believe is the correct thing to do.
>>>>>
>>>>> I disagree, because that is not how the emails are actually going out from the
>>>>> SMTP server you are using.
>>>>
>>>> Can you summarize, clearly, what you believe is the right thing to
>>>> configure and where ?
>>>
>>> According to git-send-email(1), you can either pass your scrubbed email
>>> address to --from, or configure it in the sendemail.from config option.
>>> Does that work for you?
>>
>> So sendemail.from != user.email , the later has the +tag while the
>> former does not ?
> 
> Right.
> 
>>>>>>>> from the same person/email address as the email address in From, so they
>>>>>>>> are equal.
>>>>>>>
>>>>>>> If they differ, they are not equal ;-)
>>>>>>
>>>>>> Depends on how you define 'equal' . Here I think foo+bar@example.com
>>>>>> should be considered equal to foo@example.com .
>>>>>
>>>>> That is domain-specific knowledge, which you cannot rely upon.
>>>
>>>>>> Aha, so maybe that enhancement needs further enhancement to scrub the
>>>>>> +tags before the check ?
>>>>>
>>>>> Again, that is domain-specific knowledge, which you cannot rely upon.
>>>>
>>>> How so, please elaborate .
>>>
>>> In general, you cannot assume the "+foo" part can be ignored. Only the sender
>>> knows.
>>
>> How so ?
> 
> It depends on the domain.
> 
> Is Bill.Gates@microsoft.com the same email address as
> Bill.Gates+foo@microsoft.com?
> Is Bill.Gates+1955@microsoft.com the same?
> Is Bill.Gates-1955@microsoft.com the same?
> 
> I don't know. Only microsoft.com knows.
> So that's why you should compare email addresses verbatim (but case
> insensitive).

Oh, you mean email-domain. In that case, since gmail treats
foo@gmail.com the same as foo+bar@gmail.com , checkpatch should treat
them equally as well. In which case, your checkpatch patch which now
generates a warning on this is wrong ?

-- 
Best regards,
Marek Vasut

Re: [PATCH 1/6] thermal: split thermal_zone_of_sensor_register{,_param}()

[Geert Uytterhoeven]

Hi Marek,

On Mon, Dec 17, 2018 at 2:28 PM Marek Vasut <marek.vasut@gmail.com> wrote:
> On 12/17/2018 02:26 PM, Geert Uytterhoeven wrote:
> > On Sun, Dec 16, 2018 at 9:50 PM Marek Vasut <marek.vasut@gmail.com> wrote:
> >> On 12/16/2018 09:08 PM, Geert Uytterhoeven wrote:
> >> [...]
> >>
> >>>>>>> Git actually does that automatically, assumed your user.email config matches
> >>>>>>> the From: address that is used in your outgoing email delivery path (i.e. the
> >>>>>>> scrubbed one, when using Gmail's SMTP server).
> >>>>>>> If you lie to git in your user.email config, git cannot do the right
> >>>>>>> thing, obviously.
> >>>>>>
> >>>>>> My git user.email obviously matches the From: field , before the
> >>>>>> scrubbing, which I believe is the correct thing to do.
> >>>>>
> >>>>> I disagree, because that is not how the emails are actually going out from the
> >>>>> SMTP server you are using.
> >>>>
> >>>> Can you summarize, clearly, what you believe is the right thing to
> >>>> configure and where ?
> >>>
> >>> According to git-send-email(1), you can either pass your scrubbed email
> >>> address to --from, or configure it in the sendemail.from config option.
> >>> Does that work for you?
> >>
> >> So sendemail.from != user.email , the later has the +tag while the
> >> former does not ?
> >
> > Right.
> >
> >>>>>>>> from the same person/email address as the email address in From, so they
> >>>>>>>> are equal.
> >>>>>>>
> >>>>>>> If they differ, they are not equal ;-)
> >>>>>>
> >>>>>> Depends on how you define 'equal' . Here I think foo+bar@example.com
> >>>>>> should be considered equal to foo@example.com .
> >>>>>
> >>>>> That is domain-specific knowledge, which you cannot rely upon.
> >>>
> >>>>>> Aha, so maybe that enhancement needs further enhancement to scrub the
> >>>>>> +tags before the check ?
> >>>>>
> >>>>> Again, that is domain-specific knowledge, which you cannot rely upon.
> >>>>
> >>>> How so, please elaborate .
> >>>
> >>> In general, you cannot assume the "+foo" part can be ignored. Only the sender
> >>> knows.
> >>
> >> How so ?
> >
> > It depends on the domain.
> >
> > Is Bill.Gates@microsoft.com the same email address as
> > Bill.Gates+foo@microsoft.com?
> > Is Bill.Gates+1955@microsoft.com the same?
> > Is Bill.Gates-1955@microsoft.com the same?
> >
> > I don't know. Only microsoft.com knows.
> > So that's why you should compare email addresses verbatim (but case
> > insensitive).
>
> Oh, you mean email-domain. In that case, since gmail treats
> foo@gmail.com the same as foo+bar@gmail.com , checkpatch should treat
> them equally as well. In which case, your checkpatch patch which now
> generates a warning on this is wrong ?

So checkpatch should know about all email domains?

Just fix your setup. All patch statistics operate on the author, incl. +foo, so
your patches will be attributed wrongly.

Thanks!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 1/6] thermal: split thermal_zone_of_sensor_register{,_param}()

[Marek Vasut]

On 12/17/2018 02:36 PM, Geert Uytterhoeven wrote:
> Hi Marek,
> 
> On Mon, Dec 17, 2018 at 2:28 PM Marek Vasut <marek.vasut@gmail.com> wrote:
>> On 12/17/2018 02:26 PM, Geert Uytterhoeven wrote:
>>> On Sun, Dec 16, 2018 at 9:50 PM Marek Vasut <marek.vasut@gmail.com> wrote:
>>>> On 12/16/2018 09:08 PM, Geert Uytterhoeven wrote:
>>>> [...]
>>>>
>>>>>>>>> Git actually does that automatically, assumed your user.email config matches
>>>>>>>>> the From: address that is used in your outgoing email delivery path (i.e. the
>>>>>>>>> scrubbed one, when using Gmail's SMTP server).
>>>>>>>>> If you lie to git in your user.email config, git cannot do the right
>>>>>>>>> thing, obviously.
>>>>>>>>
>>>>>>>> My git user.email obviously matches the From: field , before the
>>>>>>>> scrubbing, which I believe is the correct thing to do.
>>>>>>>
>>>>>>> I disagree, because that is not how the emails are actually going out from the
>>>>>>> SMTP server you are using.
>>>>>>
>>>>>> Can you summarize, clearly, what you believe is the right thing to
>>>>>> configure and where ?
>>>>>
>>>>> According to git-send-email(1), you can either pass your scrubbed email
>>>>> address to --from, or configure it in the sendemail.from config option.
>>>>> Does that work for you?
>>>>
>>>> So sendemail.from != user.email , the later has the +tag while the
>>>> former does not ?
>>>
>>> Right.
>>>
>>>>>>>>>> from the same person/email address as the email address in From, so they
>>>>>>>>>> are equal.
>>>>>>>>>
>>>>>>>>> If they differ, they are not equal ;-)
>>>>>>>>
>>>>>>>> Depends on how you define 'equal' . Here I think foo+bar@example.com
>>>>>>>> should be considered equal to foo@example.com .
>>>>>>>
>>>>>>> That is domain-specific knowledge, which you cannot rely upon.
>>>>>
>>>>>>>> Aha, so maybe that enhancement needs further enhancement to scrub the
>>>>>>>> +tags before the check ?
>>>>>>>
>>>>>>> Again, that is domain-specific knowledge, which you cannot rely upon.
>>>>>>
>>>>>> How so, please elaborate .
>>>>>
>>>>> In general, you cannot assume the "+foo" part can be ignored. Only the sender
>>>>> knows.
>>>>
>>>> How so ?
>>>
>>> It depends on the domain.
>>>
>>> Is Bill.Gates@microsoft.com the same email address as
>>> Bill.Gates+foo@microsoft.com?
>>> Is Bill.Gates+1955@microsoft.com the same?
>>> Is Bill.Gates-1955@microsoft.com the same?
>>>
>>> I don't know. Only microsoft.com knows.
>>> So that's why you should compare email addresses verbatim (but case
>>> insensitive).
>>
>> Oh, you mean email-domain. In that case, since gmail treats
>> foo@gmail.com the same as foo+bar@gmail.com , checkpatch should treat
>> them equally as well. In which case, your checkpatch patch which now
>> generates a warning on this is wrong ?
> 
> So checkpatch should know about all email domains?

If correct handling is domain specific knowledge, as you just said,
apparently so. Otherwise checkpatch produces false positives.

> Just fix your setup. All patch statistics operate on the author, incl. +foo, so
> your patches will be attributed wrongly.

Well your suggestion with sendemail.from doesn't seem to change
anything, but I'll keep it in.

-- 
Best regards,
Marek Vasut

Re: [PATCH 1/6] thermal: split thermal_zone_of_sensor_register{,_param}()

[Geert Uytterhoeven]

Hi Marek,

On Mon, Dec 17, 2018 at 2:41 PM Marek Vasut <marek.vasut@gmail.com> wrote:
> On 12/17/2018 02:36 PM, Geert Uytterhoeven wrote:
> > On Mon, Dec 17, 2018 at 2:28 PM Marek Vasut <marek.vasut@gmail.com> wrote:
> >> On 12/17/2018 02:26 PM, Geert Uytterhoeven wrote:
> >>> On Sun, Dec 16, 2018 at 9:50 PM Marek Vasut <marek.vasut@gmail.com> wrote:
> >>>> On 12/16/2018 09:08 PM, Geert Uytterhoeven wrote:
> >>>> [...]
> >>>>
> >>>>>>>>> Git actually does that automatically, assumed your user.email config matches
> >>>>>>>>> the From: address that is used in your outgoing email delivery path (i.e. the
> >>>>>>>>> scrubbed one, when using Gmail's SMTP server).
> >>>>>>>>> If you lie to git in your user.email config, git cannot do the right
> >>>>>>>>> thing, obviously.
> >>>>>>>>
> >>>>>>>> My git user.email obviously matches the From: field , before the
> >>>>>>>> scrubbing, which I believe is the correct thing to do.
> >>>>>>>
> >>>>>>> I disagree, because that is not how the emails are actually going out from the
> >>>>>>> SMTP server you are using.
> >>>>>>
> >>>>>> Can you summarize, clearly, what you believe is the right thing to
> >>>>>> configure and where ?
> >>>>>
> >>>>> According to git-send-email(1), you can either pass your scrubbed email
> >>>>> address to --from, or configure it in the sendemail.from config option.
> >>>>> Does that work for you?
> >>>>
> >>>> So sendemail.from != user.email , the later has the +tag while the
> >>>> former does not ?
> >>>
> >>> Right.
> >>>
> >>>>>>>>>> from the same person/email address as the email address in From, so they
> >>>>>>>>>> are equal.
> >>>>>>>>>
> >>>>>>>>> If they differ, they are not equal ;-)
> >>>>>>>>
> >>>>>>>> Depends on how you define 'equal' . Here I think foo+bar@example.com
> >>>>>>>> should be considered equal to foo@example.com .
> >>>>>>>
> >>>>>>> That is domain-specific knowledge, which you cannot rely upon.
> >>>>>
> >>>>>>>> Aha, so maybe that enhancement needs further enhancement to scrub the
> >>>>>>>> +tags before the check ?
> >>>>>>>
> >>>>>>> Again, that is domain-specific knowledge, which you cannot rely upon.
> >>>>>>
> >>>>>> How so, please elaborate .
> >>>>>
> >>>>> In general, you cannot assume the "+foo" part can be ignored. Only the sender
> >>>>> knows.
> >>>>
> >>>> How so ?
> >>>
> >>> It depends on the domain.
> >>>
> >>> Is Bill.Gates@microsoft.com the same email address as
> >>> Bill.Gates+foo@microsoft.com?
> >>> Is Bill.Gates+1955@microsoft.com the same?
> >>> Is Bill.Gates-1955@microsoft.com the same?
> >>>
> >>> I don't know. Only microsoft.com knows.
> >>> So that's why you should compare email addresses verbatim (but case
> >>> insensitive).
> >>
> >> Oh, you mean email-domain. In that case, since gmail treats
> >> foo@gmail.com the same as foo+bar@gmail.com , checkpatch should treat
> >> them equally as well. In which case, your checkpatch patch which now
> >> generates a warning on this is wrong ?
> >
> > So checkpatch should know about all email domains?
>
> If correct handling is domain specific knowledge, as you just said,
> apparently so.

Are you serious?

> Otherwise checkpatch produces false positives.

Even with gmail, some companies may use a single gmail account for public
development, and use the +foo to distinguish between individual developers.
So you cannot ignore it.

> > Just fix your setup. All patch statistics operate on the author, incl. +foo, so
> > your patches will be attributed wrongly.
>
> Well your suggestion with sendemail.from doesn't seem to change
> anything, but I'll keep it in.

Sorry to hear that.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 1/6] thermal: split thermal_zone_of_sensor_register{,_param}()

[Marek Vasut]

On 12/17/2018 03:15 PM, Geert Uytterhoeven wrote:
> Hi Marek,
> 
> On Mon, Dec 17, 2018 at 2:41 PM Marek Vasut <marek.vasut@gmail.com> wrote:
>> On 12/17/2018 02:36 PM, Geert Uytterhoeven wrote:
>>> On Mon, Dec 17, 2018 at 2:28 PM Marek Vasut <marek.vasut@gmail.com> wrote:
>>>> On 12/17/2018 02:26 PM, Geert Uytterhoeven wrote:
>>>>> On Sun, Dec 16, 2018 at 9:50 PM Marek Vasut <marek.vasut@gmail.com> wrote:
>>>>>> On 12/16/2018 09:08 PM, Geert Uytterhoeven wrote:
>>>>>> [...]
>>>>>>
>>>>>>>>>>> Git actually does that automatically, assumed your user.email config matches
>>>>>>>>>>> the From: address that is used in your outgoing email delivery path (i.e. the
>>>>>>>>>>> scrubbed one, when using Gmail's SMTP server).
>>>>>>>>>>> If you lie to git in your user.email config, git cannot do the right
>>>>>>>>>>> thing, obviously.
>>>>>>>>>>
>>>>>>>>>> My git user.email obviously matches the From: field , before the
>>>>>>>>>> scrubbing, which I believe is the correct thing to do.
>>>>>>>>>
>>>>>>>>> I disagree, because that is not how the emails are actually going out from the
>>>>>>>>> SMTP server you are using.
>>>>>>>>
>>>>>>>> Can you summarize, clearly, what you believe is the right thing to
>>>>>>>> configure and where ?
>>>>>>>
>>>>>>> According to git-send-email(1), you can either pass your scrubbed email
>>>>>>> address to --from, or configure it in the sendemail.from config option.
>>>>>>> Does that work for you?
>>>>>>
>>>>>> So sendemail.from != user.email , the later has the +tag while the
>>>>>> former does not ?
>>>>>
>>>>> Right.
>>>>>
>>>>>>>>>>>> from the same person/email address as the email address in From, so they
>>>>>>>>>>>> are equal.
>>>>>>>>>>>
>>>>>>>>>>> If they differ, they are not equal ;-)
>>>>>>>>>>
>>>>>>>>>> Depends on how you define 'equal' . Here I think foo+bar@example.com
>>>>>>>>>> should be considered equal to foo@example.com .
>>>>>>>>>
>>>>>>>>> That is domain-specific knowledge, which you cannot rely upon.
>>>>>>>
>>>>>>>>>> Aha, so maybe that enhancement needs further enhancement to scrub the
>>>>>>>>>> +tags before the check ?
>>>>>>>>>
>>>>>>>>> Again, that is domain-specific knowledge, which you cannot rely upon.
>>>>>>>>
>>>>>>>> How so, please elaborate .
>>>>>>>
>>>>>>> In general, you cannot assume the "+foo" part can be ignored. Only the sender
>>>>>>> knows.
>>>>>>
>>>>>> How so ?
>>>>>
>>>>> It depends on the domain.
>>>>>
>>>>> Is Bill.Gates@microsoft.com the same email address as
>>>>> Bill.Gates+foo@microsoft.com?
>>>>> Is Bill.Gates+1955@microsoft.com the same?
>>>>> Is Bill.Gates-1955@microsoft.com the same?
>>>>>
>>>>> I don't know. Only microsoft.com knows.
>>>>> So that's why you should compare email addresses verbatim (but case
>>>>> insensitive).
>>>>
>>>> Oh, you mean email-domain. In that case, since gmail treats
>>>> foo@gmail.com the same as foo+bar@gmail.com , checkpatch should treat
>>>> them equally as well. In which case, your checkpatch patch which now
>>>> generates a warning on this is wrong ?
>>>
>>> So checkpatch should know about all email domains?
>>
>> If correct handling is domain specific knowledge, as you just said,
>> apparently so.
> 
> Are you serious?

That's what the discussion would imply.

>> Otherwise checkpatch produces false positives.
> 
> Even with gmail, some companies may use a single gmail account for public
> development, and use the +foo to distinguish between individual developers.
> So you cannot ignore it.

Hm, that's a rather warped example, but I guess one can use it like so.

>>> Just fix your setup. All patch statistics operate on the author, incl. +foo, so
>>> your patches will be attributed wrongly.
>>
>> Well your suggestion with sendemail.from doesn't seem to change
>> anything, but I'll keep it in.
> 
> Sorry to hear that.
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 


-- 
Best regards,
Marek Vasut