[PATCH AUTOSEL 4.20 030/105] hwmon: (nct6775) Enable IO mapping for NCT6797D and NCT6798D

2019-02-12 Thread Sasha Levin
From: Guenter Roeck 

[ Upstream commit 9de15c95a63f527c8f7a968cd95e6ec71fc6891d ]

Similar to other recent chips from Nuvoton, IO mapping may be disabled
by default. Enable it when instantiating the driver and after resume.

Fixes: 0599682b826f ("hwmon: (nct6775) Add support for NCT6798D")
Fixes: e41da286a2fd ("hwmon: (nct6775) Add support for NCT6797D")
Reported-by: Michael Cook 
Cc: Michael Cook 
Signed-off-by: Guenter Roeck 
Signed-off-by: Sasha Levin 
---
 drivers/hwmon/nct6775.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/hwmon/nct6775.c b/drivers/hwmon/nct6775.c
index 8f91e366866f..4adec4ab7d06 100644
--- a/drivers/hwmon/nct6775.c
+++ b/drivers/hwmon/nct6775.c
@@ -4508,7 +4508,8 @@ static int __maybe_unused nct6775_resume(struct device 
*dev)
 
if (data->kind == nct6791 || data->kind == nct6792 ||
data->kind == nct6793 || data->kind == nct6795 ||
-   data->kind == nct6796)
+   data->kind == nct6796 || data->kind == nct6797 ||
+   data->kind == nct6798)
nct6791_enable_io_mapping(sioreg);
 
superio_exit(sioreg);
@@ -4644,7 +4645,8 @@ static int __init nct6775_find(int sioaddr, struct 
nct6775_sio_data *sio_data)
 
if (sio_data->kind == nct6791 || sio_data->kind == nct6792 ||
sio_data->kind == nct6793 || sio_data->kind == nct6795 ||
-   sio_data->kind == nct6796)
+   sio_data->kind == nct6796 || sio_data->kind == nct6797 ||
+   sio_data->kind == nct6798)
nct6791_enable_io_mapping(sioaddr);
 
superio_exit(sioaddr);
-- 
2.19.1



[PATCH AUTOSEL 4.20 093/105] hwmon: (tmp421) Correct the misspelling of the tmp442 compatible attribute in OF device ID table

2019-02-12 Thread Sasha Levin
From: Cheng-Min Ao 

[ Upstream commit f422449b58548a41e98fc97b259a283718e527db ]

Correct a typo in OF device ID table
The last one should be 'ti,tmp442'

Signed-off-by: Cheng-Min Ao 
Signed-off-by: Yu-Hsiang Chen 
Signed-off-by: Guenter Roeck 
Signed-off-by: Sasha Levin 
---
 drivers/hwmon/tmp421.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hwmon/tmp421.c b/drivers/hwmon/tmp421.c
index 8844c9565d2a..7053be59ad2e 100644
--- a/drivers/hwmon/tmp421.c
+++ b/drivers/hwmon/tmp421.c
@@ -88,7 +88,7 @@ static const struct of_device_id tmp421_of_match[] = {
.data = (void *)2
},
{
-   .compatible = "ti,tmp422",
+   .compatible = "ti,tmp442",
.data = (void *)3
},
{ },
-- 
2.19.1



[PATCH AUTOSEL 4.19 74/83] hwmon: (tmp421) Correct the misspelling of the tmp442 compatible attribute in OF device ID table

2019-02-12 Thread Sasha Levin
From: Cheng-Min Ao 

[ Upstream commit f422449b58548a41e98fc97b259a283718e527db ]

Correct a typo in OF device ID table
The last one should be 'ti,tmp442'

Signed-off-by: Cheng-Min Ao 
Signed-off-by: Yu-Hsiang Chen 
Signed-off-by: Guenter Roeck 
Signed-off-by: Sasha Levin 
---
 drivers/hwmon/tmp421.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hwmon/tmp421.c b/drivers/hwmon/tmp421.c
index e36399213324..ceb3db6f3fdd 100644
--- a/drivers/hwmon/tmp421.c
+++ b/drivers/hwmon/tmp421.c
@@ -88,7 +88,7 @@ static const struct of_device_id tmp421_of_match[] = {
.data = (void *)2
},
{
-   .compatible = "ti,tmp422",
+   .compatible = "ti,tmp442",
.data = (void *)3
},
{ },
-- 
2.19.1



[PATCH AUTOSEL 4.14 29/34] hwmon: (tmp421) Correct the misspelling of the tmp442 compatible attribute in OF device ID table

2019-02-12 Thread Sasha Levin
From: Cheng-Min Ao 

[ Upstream commit f422449b58548a41e98fc97b259a283718e527db ]

Correct a typo in OF device ID table
The last one should be 'ti,tmp442'

Signed-off-by: Cheng-Min Ao 
Signed-off-by: Yu-Hsiang Chen 
Signed-off-by: Guenter Roeck 
Signed-off-by: Sasha Levin 
---
 drivers/hwmon/tmp421.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hwmon/tmp421.c b/drivers/hwmon/tmp421.c
index e36399213324..ceb3db6f3fdd 100644
--- a/drivers/hwmon/tmp421.c
+++ b/drivers/hwmon/tmp421.c
@@ -88,7 +88,7 @@ static const struct of_device_id tmp421_of_match[] = {
.data = (void *)2
},
{
-   .compatible = "ti,tmp422",
+   .compatible = "ti,tmp442",
.data = (void *)3
},
{ },
-- 
2.19.1



Re: [GIT PULL] hwmon fixes for hwmon-for-v5.0-rc7

2019-02-12 Thread pr-tracker-bot
The pull request you sent on Tue, 12 Feb 2019 13:56:29 -0800:

> git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git 
> hwmon-for-v5.0-rc7

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/991b9eb4243b53e6dcaeda94e515d713ca7ddd2e

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker


Re: [PATCH] hwmon: (f71882fg) Mark expected switch fall-through

2019-02-12 Thread Gustavo A. R. Silva



On 2/12/19 3:51 PM, Guenter Roeck wrote:
> On Mon, Feb 11, 2019 at 04:07:38PM -0600, Gustavo A. R. Silva wrote:
>> In preparation to enabling -Wimplicit-fallthrough, mark switch
>> cases where we are expecting to fall through.
>>
>> This patch fixes the following warnings:
>>
>> drivers/hwmon/f71882fg.c: In function ‘f71882fg_probe’:
>> drivers/hwmon/f71882fg.c:2457:33: warning: this statement may fall through 
>> [-Wimplicit-fallthrough=]
>> data->auto_point_temp_signed = 1;
>> ~^~~
>> drivers/hwmon/f71882fg.c:2459:3: note: here
>>case f71889fg:
>>^~~~
>>
>> Warning level 3 was used: -Wimplicit-fallthrough=3
>>
>> Notice that, in this particular case, the code comment is modified
>> in accordance with what GCC is expecting to find.
>>
>> This patch is part of the ongoing efforts to enable
>> -Wimplicit-fallthrough.
>>
>> Signed-off-by: Gustavo A. R. Silva 
> 
> Applied to hwmon-next.
> 

Thanks, Guenter.

--
Gustavo


[GIT PULL] hwmon fixes for hwmon-for-v5.0-rc7

2019-02-12 Thread Guenter Roeck
Hi Linus,

Please pull hwmon fixes for Linux hwmon-for-v5.0-rc7 from signed tag:

git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git 
hwmon-for-v5.0-rc7

Thanks,
Guenter
--

The following changes since commit 49a57857aeea06ca831043acbb0fa5e0f50602fd:

  Linux 5.0-rc3 (2019-01-21 13:14:44 +1300)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git 
tags/hwmon-for-v5.0-rc7

for you to fetch changes up to 2a2ec4aa0577ec0b7df2d1bde5c84ed39a8637cb:

  hwmon: (nct6775) Fix fan6 detection for NCT6793D (2019-01-27 18:55:49 -0800)


hwmon fix for v5.0-rc7

Fix fan detection for NCT6793D.


Guenter Roeck (1):
  hwmon: (nct6775) Fix fan6 detection for NCT6793D

 drivers/hwmon/nct6775.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)


Re: [PATCH] hwmon: (f71882fg) Mark expected switch fall-through

2019-02-12 Thread Guenter Roeck
On Mon, Feb 11, 2019 at 04:07:38PM -0600, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch
> cases where we are expecting to fall through.
> 
> This patch fixes the following warnings:
> 
> drivers/hwmon/f71882fg.c: In function ‘f71882fg_probe’:
> drivers/hwmon/f71882fg.c:2457:33: warning: this statement may fall through 
> [-Wimplicit-fallthrough=]
> data->auto_point_temp_signed = 1;
> ~^~~
> drivers/hwmon/f71882fg.c:2459:3: note: here
>case f71889fg:
>^~~~
> 
> Warning level 3 was used: -Wimplicit-fallthrough=3
> 
> Notice that, in this particular case, the code comment is modified
> in accordance with what GCC is expecting to find.
> 
> This patch is part of the ongoing efforts to enable
> -Wimplicit-fallthrough.
> 
> Signed-off-by: Gustavo A. R. Silva 

Applied to hwmon-next.

Thanks,
Guenter

> ---
>  drivers/hwmon/f71882fg.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/hwmon/f71882fg.c b/drivers/hwmon/f71882fg.c
> index ca54ce5c8e10..83023798e489 100644
> --- a/drivers/hwmon/f71882fg.c
> +++ b/drivers/hwmon/f71882fg.c
> @@ -2455,7 +2455,7 @@ static int f71882fg_probe(struct platform_device *pdev)
>   case f71869a:
>   /* These always have signed auto point temps */
>   data->auto_point_temp_signed = 1;
> - /* Fall through to select correct fan/pwm reg bank! */
> + /* Fall through - to select correct fan/pwm reg bank! */
>   case f71889fg:
>   case f71889ed:
>   case f71889a:


Re: [PATCH] hwmon: (ad7418) Catch I2C errors

2019-02-12 Thread Guenter Roeck
On Thu, Feb 07, 2019 at 03:50:36PM -0600, Brandon Maier wrote:
> If there is an i2c failure, the ad7416 reports its temperature as 0C.
> Return an error code so users can properly detect errors.
> 
> Signed-off-by: Brandon Maier 

Applied to hwmon-next.

Thanks,
Guenter

> ---
> Tested on an ad7416, attempting to `cat` the temp1_input while the
> sensor is physically disconnected returns this:
> 
> > cat: read error: Remote I/O error
> ---
>  drivers/hwmon/ad7418.c | 65 +++---
>  1 file changed, 49 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/hwmon/ad7418.c b/drivers/hwmon/ad7418.c
> index 76f0a5c01e8a..28a91d14d7af 100644
> --- a/drivers/hwmon/ad7418.c
> +++ b/drivers/hwmon/ad7418.c
> @@ -54,10 +54,11 @@ struct ad7418_data {
>   u16 in[4];
>  };
>  
> -static struct ad7418_data *ad7418_update_device(struct device *dev)
> +static int ad7418_update_device(struct device *dev)
>  {
>   struct ad7418_data *data = dev_get_drvdata(dev);
>   struct i2c_client *client = data->client;
> + s32 val;
>  
>   mutex_lock(>lock);
>  
> @@ -67,47 +68,74 @@ static struct ad7418_data *ad7418_update_device(struct 
> device *dev)
>   int i, ch;
>  
>   /* read config register and clear channel bits */
> - cfg = i2c_smbus_read_byte_data(client, AD7418_REG_CONF);
> + val = i2c_smbus_read_byte_data(client, AD7418_REG_CONF);
> + if (val < 0)
> + goto abort;
> +
> + cfg = val;
>   cfg &= 0x1F;
>  
> - i2c_smbus_write_byte_data(client, AD7418_REG_CONF,
> + val = i2c_smbus_write_byte_data(client, AD7418_REG_CONF,
>   cfg | AD7418_CH_TEMP);
> + if (val < 0)
> + goto abort;
> +
>   udelay(30);
>  
>   for (i = 0; i < 3; i++) {
> - data->temp[i] =
> - i2c_smbus_read_word_swapped(client,
> - AD7418_REG_TEMP[i]);
> + val = i2c_smbus_read_word_swapped(client,
> +   AD7418_REG_TEMP[i]);
> + if (val < 0)
> + goto abort;
> +
> + data->temp[i] = val;
>   }
>  
>   for (i = 0, ch = 4; i < data->adc_max; i++, ch--) {
> - i2c_smbus_write_byte_data(client,
> - AD7418_REG_CONF,
> - cfg | AD7418_REG_ADC_CH(ch));
> + val = i2c_smbus_write_byte_data(client, AD7418_REG_CONF,
> + cfg | AD7418_REG_ADC_CH(ch));
> + if (val < 0)
> + goto abort;
>  
>   udelay(15);
> - data->in[data->adc_max - 1 - i] =
> - i2c_smbus_read_word_swapped(client,
> - AD7418_REG_ADC);
> + val = i2c_smbus_read_word_swapped(client,
> +   AD7418_REG_ADC);
> + if (val < 0)
> + goto abort;
> +
> + data->in[data->adc_max - 1 - i] = val;
>   }
>  
>   /* restore old configuration value */
> - i2c_smbus_write_word_swapped(client, AD7418_REG_CONF, cfg);
> + val = i2c_smbus_write_word_swapped(client, AD7418_REG_CONF,
> +cfg);
> + if (val < 0)
> + goto abort;
>  
>   data->last_updated = jiffies;
>   data->valid = 1;
>   }
>  
>   mutex_unlock(>lock);
> + return 0;
>  
> - return data;
> +abort:
> + data->valid = 0;
> + mutex_unlock(>lock);
> + return val;
>  }
>  
>  static ssize_t temp_show(struct device *dev, struct device_attribute 
> *devattr,
>char *buf)
>  {
>   struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
> - struct ad7418_data *data = ad7418_update_device(dev);
> + struct ad7418_data *data = dev_get_drvdata(dev);
> + int ret;
> +
> + ret = ad7418_update_device(dev);
> + if (ret < 0)
> + return ret;
> +
>   return sprintf(buf, "%d\n",
>   LM75_TEMP_FROM_REG(data->temp[attr->index]));
>  }
> @@ -116,7 +144,12 @@ static ssize_t adc_show(struct device *dev, struct 
> device_attribute *devattr,
>   char *buf)
>  {
>   struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
> - struct ad7418_data *data = ad7418_update_device(dev);
> + struct ad7418_data *data = dev_get_drvdata(dev);
> + int ret;
> +
> + ret = ad7418_update_device(dev);
> + if (ret < 0)
> +  

[PATCH] hwmon: (ntc_thermistor) Convert to new hwmon API

2019-02-12 Thread Guenter Roeck
Use devm_hwmon_device_register_with_info() instead of
devm_hwmon_device_register_with_groups() to register the hwmon
device to simplify the code and make it easier to maintain.
As part of this change, thermal device registration is moved into
the hwmon core.

Signed-off-by: Guenter Roeck 
---
 drivers/hwmon/ntc_thermistor.c | 106 +
 1 file changed, 66 insertions(+), 40 deletions(-)

diff --git a/drivers/hwmon/ntc_thermistor.c b/drivers/hwmon/ntc_thermistor.c
index 2823aff82c82..e4f9f7ce92fa 100644
--- a/drivers/hwmon/ntc_thermistor.c
+++ b/drivers/hwmon/ntc_thermistor.c
@@ -37,8 +37,6 @@
 #include 
 
 #include 
-#include 
-#include 
 
 struct ntc_compensation {
int temp_c;
@@ -588,55 +586,87 @@ static int ntc_thermistor_get_ohm(struct ntc_data *data)
return -EINVAL;
 }
 
-static int ntc_read_temp(void *data, int *temp)
+static int ntc_read(struct device *dev, enum hwmon_sensor_types type,
+   u32 attr, int channel, long *val)
 {
+   struct ntc_data *data = dev_get_drvdata(dev);
int ohm;
 
-   ohm = ntc_thermistor_get_ohm(data);
-   if (ohm < 0)
-   return ohm;
-
-   *temp = get_temp_mc(data, ohm);
-
-   return 0;
+   switch (type) {
+   case hwmon_temp:
+   switch (attr) {
+   case hwmon_temp_input:
+   ohm = ntc_thermistor_get_ohm(data);
+   if (ohm < 0)
+   return ohm;
+   *val = get_temp_mc(data, ohm);
+   return 0;
+   case hwmon_temp_type:
+   *val = 4;
+   return 0;
+   default:
+   break;
+   }
+   break;
+   default:
+   break;
+   }
+   return -EINVAL;
 }
 
-static ssize_t ntc_type_show(struct device *dev,
-struct device_attribute *attr, char *buf)
+static umode_t ntc_is_visible(const void *data, enum hwmon_sensor_types type,
+ u32 attr, int channel)
 {
-   return sprintf(buf, "4\n");
+   if (type == hwmon_temp) {
+   switch (attr) {
+   case hwmon_temp_input:
+   case hwmon_temp_type:
+   return 0444;
+   default:
+   break;
+   }
+   }
+   return 0;
 }
 
-static ssize_t ntc_temp_show(struct device *dev,
-struct device_attribute *attr, char *buf)
-{
-   struct ntc_data *data = dev_get_drvdata(dev);
-   int ohm;
+static const u32 ntc_chip_config[] = {
+   HWMON_C_REGISTER_TZ,
+   0
+};
 
-   ohm = ntc_thermistor_get_ohm(data);
-   if (ohm < 0)
-   return ohm;
+static const struct hwmon_channel_info ntc_chip = {
+   .type = hwmon_chip,
+   .config = ntc_chip_config,
+};
 
-   return sprintf(buf, "%d\n", get_temp_mc(data, ohm));
-}
+static const u32 ntc_temp_config[] = {
+   HWMON_T_INPUT, HWMON_T_TYPE,
+   0
+};
 
-static SENSOR_DEVICE_ATTR_RO(temp1_type, ntc_type, 0);
-static SENSOR_DEVICE_ATTR_RO(temp1_input, ntc_temp, 0);
+static const struct hwmon_channel_info ntc_temp = {
+   .type = hwmon_temp,
+   .config = ntc_temp_config,
+};
 
-static struct attribute *ntc_attrs[] = {
-   _dev_attr_temp1_type.dev_attr.attr,
-   _dev_attr_temp1_input.dev_attr.attr,
-   NULL,
+static const struct hwmon_channel_info *ntc_info[] = {
+   _chip,
+   _temp,
+   NULL
 };
-ATTRIBUTE_GROUPS(ntc);
 
-static const struct thermal_zone_of_device_ops ntc_of_thermal_ops = {
-   .get_temp = ntc_read_temp,
+static const struct hwmon_ops ntc_hwmon_ops = {
+   .is_visible = ntc_is_visible,
+   .read = ntc_read,
+};
+
+static const struct hwmon_chip_info ntc_chip_info = {
+   .ops = _hwmon_ops,
+   .info = ntc_info,
 };
 
 static int ntc_thermistor_probe(struct platform_device *pdev)
 {
-   struct thermal_zone_device *tz;
struct device *dev = >dev;
const struct of_device_id *of_id =
of_match_device(of_match_ptr(ntc_match), dev);
@@ -697,8 +727,9 @@ static int ntc_thermistor_probe(struct platform_device 
*pdev)
data->comp   = ntc_type[pdev_id->driver_data].comp;
data->n_comp = ntc_type[pdev_id->driver_data].n_comp;
 
-   hwmon_dev = devm_hwmon_device_register_with_groups(dev, pdev_id->name,
-  data, ntc_groups);
+   hwmon_dev = devm_hwmon_device_register_with_info(dev, pdev_id->name,
+data, _chip_info,
+NULL);
if (IS_ERR(hwmon_dev)) {
dev_err(dev, "unable to register as hwmon device.\n");
return PTR_ERR(hwmon_dev);
@@ -707,11 +738,6 @@ static int 

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

2019-02-12 Thread Guenter Roeck

On 2/12/19 12:52 AM, Geert Uytterhoeven wrote:

Hi all,

On Mon, Feb 11, 2019 at 9:43 PM Marek Vasut  wrote:

On 2/6/19 12:24 AM, Eduardo Valentin wrote:

On Mon, Jan 28, 2019 at 01:10:11PM +0100, Marek Vasut wrote:

On 1/15/19 1:35 AM, Marek Vasut wrote:

On 12/22/18 3:19 AM, Marek Vasut wrote:

On 12/18/2018 10:44 PM, Eduardo Valentin wrote:

On Mon, Dec 17, 2018 at 04:56:41PM +0100, marek.va...@gmail.com wrote:

From: 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().

From: Marek Vasut 
Cc: Daniel Lezcano 
Cc: Eduardo Valentin 
Cc: Wolfram Sang 
Cc: Zhang Rui 
Cc: linux-renesas-...@vger.kernel.org
To: linux...@vger.kernel.org
Signed-off-by: Marek Vasut 
---
V2: No change
V3: - Work around the From line and SoB line checkpatch warning
 - Reorder the SoB line at the end
---
  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 e1a303a5698c..5ccff7b678de 100644
--- a/drivers/thermal/of-thermal.c
+++ b/drivers/thermal/of-thermal.c
@@ -15,6 +15,7 @@
  #include 

  #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;


So, here you will overwrite what was done in of_parse_thermal_zones().
That means, after this point, property like sustainable power, slope and
offset are gone.


Hm, that was rather inobvious, indeed.

Do you have some suggestion how to pass in the no_hwmon = false then ?
Since tzp->no_hwmon is set to true in of_parse_thermal_zones(), the
three drivers (stm32, rcar, rcar_gen3) seem to hack around it. I'd like
to clean that up.




Yeah, that is an issue.


Bump ?


Bump again, any suggestions ?


Yeah, a couple of ideas have been proposed for this issue.

First most tempting one is to have a DT property per thermal zone.
Making it linux specific, something prefixed by linux,. I
recall Amit Kutcheria trying something similar to this, but dont
remember where that went. Frankly, this is a Linux thing, I am not
convinced DT is really the right place to fix this.


DT is not the right place for this, DT describes hardware and this is
policy, so it shouldn't be in DT.


Indeed.


Another hack that could be written is a module parameter for of-thermal
that would reflect the no_hwmon value, globally. The down side here is
you have to make sure all drivers match that no_hwmon value, right?


Indeed, it should be the driver which decides whether or not to register
a HWMON interface for the thermal zone.

I guess for now, I'll just discard this entire series and hack the data
structure like other drivers do, since I don't see any reasonable solution.


Pardon my ignorance, but when would a thermal driver (not) want to register
a hwmon interface for the thermal zone?



Thermal zones can also be registered from hwmon drivers, so we have a
chicken-and-egg problem.

Guenter


Re: coretemp driver change on dual-die/package systems

2019-02-12 Thread Zhang Rui
On 一, 2019-02-11 at 06:13 -0800, Guenter Roeck wrote:
> On 2/11/19 1:46 AM, Zhang Rui wrote:
> > 
> > Hi, Jean and Guenter,
> > 
> > Per the Intel Software Developer's Manual, which you can found at
> > www.i
> > ntel.com/sdm, when CPUID.1F is present, it is preferred over
> > CPUID.B.
> > 
> > New dual-die/package systems will see this difference:
> >     CPUID.0B enumerates the CPUs on each die as if they were in
> > different packages.
> >     CPUID.1F enumerates the CPUs on each die within the same
> > package.
> > 
> > This will manifest in the sysfs physical_package_id attribute. ie.
> > In
> > the example above, CPUID.B would cause lscpu to show 2 packages,
> > and
> > CPUID.1F will cause lscpu to show 1 package.
> > 
> > Also, with CPUID.B the concept of a package-scope MSR and a die-
> > scope
> > MSR are synonymous.  With CPUID.1F, it is possible for some MSRs to
> > have die-scope, and other MSRs to have package-scope.
> > 
> > MSR_IA32_PACKAGE_THERM_STATUS is a die-scope MSR, thus we need to
> > update the coretemp driver to become multi-die-aware when we
> > support
> > CPUID.1F.
> > 
> > Previously, we create one hwmon device for each package, now we
> > need to
> > create one hwmon device for each die.
> > But there is one problem left. For each coretemp hwmon device, the
> > "temp1_input" attribute represents the temperature got from
> > MSR_IA32_PACKAGE_THERM_STATUS, and "temp1_label" is "Package id X",
> > where X is the logical package id.
> > Now we create one hwmon device for each die, thus temp1_label can
> > not
> > use logical package id any more, because there are two dies in the
> > same
> > package.
> > To me, there are two choices,
> > 1. changing "temp1_label" from "Package id X" to "Package id Y",
> > where
> > Y is just a unique number instead of logical package id, say, using
> > ida.
> > 2. changing "temp1_label" from "Package id X" to "Package id X Die
> > id
> > Y", where Y is the die id.
> > 
> > Question is I'm not sure how temp1_label is used and if this change
> > will break any userspace, like lm-sensors?
> > 
> Please feel free to change the label as it makes sense. I would
> suggest option
> 2 to avoid confusion. The string it reports is not part of the ABI
> and
> can be changed. It can be overwritten with sensors3.conf anyway, so
> nothing
> should depend on it.

Good to know. Thanks for the clarification, Guenter!

-rui

> 
> Guenter


[PATCH v2] dt-bindings: hwmon: Add missing documentation for lm75

2019-02-12 Thread Jagan Teki
Add missing dt-binding documentation for lm75 hwmon sensor.

Signed-off-by: Jagan Teki 
---
Changes for v2:
-  Add all compatible nodes available in lm75.

 .../devicetree/bindings/hwmon/lm75.txt| 37 +++
 1 file changed, 37 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/lm75.txt

diff --git a/Documentation/devicetree/bindings/hwmon/lm75.txt 
b/Documentation/devicetree/bindings/hwmon/lm75.txt
new file mode 100644
index ..12d8cf7cf592
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/lm75.txt
@@ -0,0 +1,37 @@
+*LM75 hwmon sensor.
+
+Required properties:
+- compatible: manufacturer and chip name, one of
+   "adi,adt75",
+   "dallas,ds1775",
+   "dallas,ds75",
+   "dallas,ds7505",
+   "gmt,g751",
+   "national,lm75",
+   "national,lm75a",
+   "national,lm75b",
+   "maxim,max6625",
+   "maxim,max6626",
+   "maxim,max31725",
+   "maxim,max31726",
+   "maxim,mcp980x",
+   "st,stds75",
+   "st,stlm75",
+   "microchip,tcn75",
+   "ti,tmp100",
+   "ti,tmp101",
+   "ti,tmp105",
+   "ti,tmp112",
+   "ti,tmp175",
+   "ti,tmp275",
+   "ti,tmp75",
+   "ti,tmp75c",
+
+- reg: I2C bus address of the device
+
+Example:
+
+sensor@48 {
+   compatible = "st,stlm75";
+   reg = <0x48>;
+};
-- 
2.18.0.321.gffc6fa0e3



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

2019-02-12 Thread Geert Uytterhoeven
Hi all,

On Mon, Feb 11, 2019 at 9:43 PM Marek Vasut  wrote:
> On 2/6/19 12:24 AM, Eduardo Valentin wrote:
> > On Mon, Jan 28, 2019 at 01:10:11PM +0100, Marek Vasut wrote:
> >> On 1/15/19 1:35 AM, Marek Vasut wrote:
> >>> On 12/22/18 3:19 AM, Marek Vasut wrote:
>  On 12/18/2018 10:44 PM, Eduardo Valentin wrote:
> > On Mon, Dec 17, 2018 at 04:56:41PM +0100, marek.va...@gmail.com wrote:
> >> From: 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().
> >>
> >> From: Marek Vasut 
> >> Cc: Daniel Lezcano 
> >> Cc: Eduardo Valentin 
> >> Cc: Wolfram Sang 
> >> Cc: Zhang Rui 
> >> Cc: linux-renesas-...@vger.kernel.org
> >> To: linux...@vger.kernel.org
> >> Signed-off-by: Marek Vasut 
> >> ---
> >> V2: No change
> >> V3: - Work around the From line and SoB line checkpatch warning
> >> - Reorder the SoB line at the end
> >> ---
> >>  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 e1a303a5698c..5ccff7b678de 100644
> >> --- a/drivers/thermal/of-thermal.c
> >> +++ b/drivers/thermal/of-thermal.c
> >> @@ -15,6 +15,7 @@
> >>  #include 
> >>
> >>  #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;
> >
> > So, here you will overwrite what was done in of_parse_thermal_zones().
> > That means, after this point, property like sustainable power, slope and
> > offset are gone.
> 
>  Hm, that was rather inobvious, indeed.
> 
>  Do you have some suggestion how to pass in the no_hwmon = false then ?
>  Since tzp->no_hwmon is set to true in of_parse_thermal_zones(), the
>  three drivers (stm32, rcar, rcar_gen3) seem to hack around it. I'd like
>  to clean that up.
> >>>
> >
> > Yeah, that is an issue.
> >
> >>> Bump ?
> >>
> >> Bump again, any suggestions ?
> >
> > Yeah, a couple of ideas have been proposed for this issue.
> >
> > First most tempting one is to have a DT property per thermal zone.
> > Making it linux specific, something prefixed by linux,. I
> > recall Amit Kutcheria trying something similar to this, but dont
> > remember where that went. Frankly, this is a Linux thing, I am not
> > convinced DT is really the right place to fix this.
>
> DT is not the right place for this, DT describes hardware and this is
> policy, so it shouldn't be in DT.

Indeed.

> > Another hack that could be written is a module parameter for of-thermal
> > that would reflect the no_hwmon value, globally. The down side here is
> > you have to make sure all drivers match that no_hwmon value, right?
>
> Indeed, it should be the driver which decides whether or not to register
> a HWMON interface for the thermal zone.
>
> I guess for now, I'll just discard this entire series and hack the data
> structure like other drivers do, since I don't see any reasonable solution.

Pardon my ignorance, but when would a thermal driver (not) want to register
a hwmon interface for the thermal zone?

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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