Message ID | 20181212014927.25840-2-marek.vasut+renesas@gmail.com (mailing list archive) |
---|---|
State | Superseded |
Delegated to: | Geert Uytterhoeven |
Headers | show |
Series | thermal: Align devm_thermal_zone_{device,of_sensor}_register | expand |
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 >
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. [...]
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
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.
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
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 ?
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
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.
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
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.
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
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.
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
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 ?
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
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 ?
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
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.
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
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 >
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)
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(-)