date:20180322

Re: [PATCH v2] hwmon: (lm92) Add max6635 to lm92_id[]

2018-03-22 Thread Guenter Roeck

On Thu, Mar 22, 2018 at 04:56:17PM +0100, Jean Delvare wrote:
> On Thu, 22 Mar 2018 15:37:44 +0100, Alvaro Gamez Machado wrote:
> > Since autodetection of this chip was removed, it makes sense to add prefix
> > max6635 so that the device can be instantiated by its actual name.
> > 
> > Signed-off-by: Alvaro Gamez Machado 

Never mind my previous comment. I'll take this patch instead.

Thanks,
Guenter

> > ---
> > Differences:
> > * Update also Documentation/hwmon/lm92 with new prefix to use
> > 
> >  Documentation/hwmon/lm92 | 2 +-
> >  drivers/hwmon/lm92.c | 5 +++--
> >  2 files changed, 4 insertions(+), 3 deletions(-)
> > 
> > diff --git a/Documentation/hwmon/lm92 b/Documentation/hwmon/lm92
> > index f2a5adcf4ead..cfa99a353b8c 100644
> > --- a/Documentation/hwmon/lm92
> > +++ b/Documentation/hwmon/lm92
> > @@ -11,7 +11,7 @@ Supported chips:
> >  Addresses scanned: none, force parameter needed
> >  Datasheet: http://www.national.com/pf/LM/LM76.html
> >* Maxim MAX6633/MAX6634/MAX6635
> > -Prefix: 'lm92'
> > +Prefix: 'max6635'
> >  Addresses scanned: none, force parameter needed
> >  Datasheet: http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3074
> >  
> > diff --git a/drivers/hwmon/lm92.c b/drivers/hwmon/lm92.c
> > index 18509b5af11e..d40fe5122e94 100644
> > --- a/drivers/hwmon/lm92.c
> > +++ b/drivers/hwmon/lm92.c
> > @@ -52,6 +52,7 @@
> >   */
> >  static const unsigned short normal_i2c[] = { 0x48, 0x49, 0x4a, 0x4b,
> > I2C_CLIENT_END };
> > +enum chips { lm92, max6635 };
> >  
> >  /* The LM92 registers */
> >  #define LM92_REG_CONFIG0x01 /* 8-bit, RW */
> > @@ -329,8 +330,8 @@ static int lm92_probe(struct i2c_client *new_client,
> >   */
> >  
> >  static const struct i2c_device_id lm92_id[] = {
> > -   { "lm92", 0 },
> > -   /* max6635 could be added here */
> > +   { "lm92", lm92 },
> > +   { "max6635", max6635 },
> > { }
> >  };
> >  MODULE_DEVICE_TABLE(i2c, lm92_id);
> 
> Reviewed-by: Jean Delvare 
> 
> -- 
> Jean Delvare
> SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] hwmon: (lm92) Do not try to detect MAX6635

2018-03-22 Thread Guenter Roeck

On Thu, Mar 22, 2018 at 10:17:02AM +0100, Jean Delvare wrote:
> On Wed, 21 Mar 2018 16:04:52 +0100, Alvaro Gamez Machado wrote:
> > Maxim MAX663x family are mostly compatible with LM92, but they lack any
> > identification register. Weakening the detect function would make it prone
> > to false positives, and current one doesn't detect all chips.  Therefore,
> > the detect function for max6635 devices is removed in favor of explicit
> > device instatiation.
> > 
> > Signed-off-by: Alvaro Gamez Machado 
> > ---
> >  Documentation/hwmon/lm92 |  4 +---
> >  drivers/hwmon/lm92.c | 58 
> > 
> >  2 files changed, 1 insertion(+), 61 deletions(-)
> > 
> > diff --git a/Documentation/hwmon/lm92 b/Documentation/hwmon/lm92
> > index 22f68ad032cf..f2a5adcf4ead 100644
> > --- a/Documentation/hwmon/lm92
> > +++ b/Documentation/hwmon/lm92
> > @@ -12,9 +12,7 @@ Supported chips:
> >  Datasheet: http://www.national.com/pf/LM/LM76.html
> >* Maxim MAX6633/MAX6634/MAX6635
> >  Prefix: 'lm92'
> > -Addresses scanned: I2C 0x48 - 0x4b
> > -MAX6633 with address in 0x40 - 0x47, 0x4c - 0x4f needs force parameter
> > -and MAX6634 with address in 0x4c - 0x4f needs force parameter
> > +Addresses scanned: none, force parameter needed
> >  Datasheet: http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3074
> >  
> >  Authors:
> > diff --git a/drivers/hwmon/lm92.c b/drivers/hwmon/lm92.c
> > index 2a91974a10bb..18509b5af11e 100644
> > --- a/drivers/hwmon/lm92.c
> > +++ b/drivers/hwmon/lm92.c
> > @@ -259,62 +259,6 @@ static void lm92_init_client(struct i2c_client *client)
> >   config & 0xFE);
> >  }
> >  
> > -/*
> > - * The MAX6635 has no identification register, so we have to use tricks
> > - * to identify it reliably. This is somewhat slow.
> > - * Note that we do NOT rely on the 2 MSB of the configuration register
> > - * always reading 0, as suggested by the datasheet, because it was once
> > - * reported not to be true.
> > - */
> > -static int max6635_check(struct i2c_client *client)
> > -{
> > -   u16 temp_low, temp_high, temp_hyst, temp_crit;
> > -   u8 conf;
> > -   int i;
> > -
> > -   /*
> > -* No manufacturer ID register, so a read from this address will
> > -* always return the last read value.
> > -*/
> > -   temp_low = i2c_smbus_read_word_data(client, LM92_REG_TEMP_LOW);
> > -   if (i2c_smbus_read_word_data(client, LM92_REG_MAN_ID) != temp_low)
> > -   return 0;
> > -   temp_high = i2c_smbus_read_word_data(client, LM92_REG_TEMP_HIGH);
> > -   if (i2c_smbus_read_word_data(client, LM92_REG_MAN_ID) != temp_high)
> > -   return 0;
> > -
> > -   /* Limits are stored as integer values (signed, 9-bit). */
> > -   if ((temp_low & 0x7f00) || (temp_high & 0x7f00))
> > -   return 0;
> > -   temp_hyst = i2c_smbus_read_word_data(client, LM92_REG_TEMP_HYST);
> > -   temp_crit = i2c_smbus_read_word_data(client, LM92_REG_TEMP_CRIT);
> > -   if ((temp_hyst & 0x7f00) || (temp_crit & 0x7f00))
> > -   return 0;
> > -
> > -   /*
> > -* Registers addresses were found to cycle over 16-byte boundaries.
> > -* We don't test all registers with all offsets so as to save some
> > -* reads and time, but this should still be sufficient to dismiss
> > -* non-MAX6635 chips.
> > -*/
> > -   conf = i2c_smbus_read_byte_data(client, LM92_REG_CONFIG);
> > -   for (i = 16; i < 96; i *= 2) {
> > -   if (temp_hyst != i2c_smbus_read_word_data(client,
> > -LM92_REG_TEMP_HYST + i - 16)
> > -|| temp_crit != i2c_smbus_read_word_data(client,
> > -LM92_REG_TEMP_CRIT + i)
> > -|| temp_low != i2c_smbus_read_word_data(client,
> > -   LM92_REG_TEMP_LOW + i + 16)
> > -|| temp_high != i2c_smbus_read_word_data(client,
> > -LM92_REG_TEMP_HIGH + i + 32)
> > -|| conf != i2c_smbus_read_byte_data(client,
> > -   LM92_REG_CONFIG + i))
> > -   return 0;
> > -   }
> > -
> > -   return 1;
> > -}
> > -
> >  static struct attribute *lm92_attrs[] = {
> > _dev_attr_temp1_input.dev_attr.attr,
> > _dev_attr_temp1_crit.dev_attr.attr,
> > @@ -348,8 +292,6 @@ static int lm92_detect(struct i2c_client *new_client,
> >  
> > if ((config & 0xe0) == 0x00 && man_id == 0x0180)
> > pr_info("lm92: Found National Semiconductor LM92 chip\n");
> > -   else if (max6635_check(new_client))
> > -   pr_info("lm92: Found Maxim MAX6635 chip\n");
> > else
> > return -ENODEV;
> >  
> 
> Reviewed-by: Jean Delvare 
> 
> It would probably make sense to add prefix "max6635" to lm92_id[] so
> that the device can be instantiated by its actual name.

Excellent idea. I took the freedom to add that to the patch.

Thanks,
Guenter

> 
> -- 
> Jean Delvare
> SUSE L3

Re: [PATCH v2] hwmon: (lm92) Add max6635 to lm92_id[]

2018-03-22 Thread Jean Delvare

On Thu, 22 Mar 2018 15:37:44 +0100, Alvaro Gamez Machado wrote:
> Since autodetection of this chip was removed, it makes sense to add prefix
> max6635 so that the device can be instantiated by its actual name.
> 
> Signed-off-by: Alvaro Gamez Machado 
> ---
> Differences:
>   * Update also Documentation/hwmon/lm92 with new prefix to use
> 
>  Documentation/hwmon/lm92 | 2 +-
>  drivers/hwmon/lm92.c | 5 +++--
>  2 files changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/hwmon/lm92 b/Documentation/hwmon/lm92
> index f2a5adcf4ead..cfa99a353b8c 100644
> --- a/Documentation/hwmon/lm92
> +++ b/Documentation/hwmon/lm92
> @@ -11,7 +11,7 @@ Supported chips:
>  Addresses scanned: none, force parameter needed
>  Datasheet: http://www.national.com/pf/LM/LM76.html
>* Maxim MAX6633/MAX6634/MAX6635
> -Prefix: 'lm92'
> +Prefix: 'max6635'
>  Addresses scanned: none, force parameter needed
>  Datasheet: http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3074
>  
> diff --git a/drivers/hwmon/lm92.c b/drivers/hwmon/lm92.c
> index 18509b5af11e..d40fe5122e94 100644
> --- a/drivers/hwmon/lm92.c
> +++ b/drivers/hwmon/lm92.c
> @@ -52,6 +52,7 @@
>   */
>  static const unsigned short normal_i2c[] = { 0x48, 0x49, 0x4a, 0x4b,
>   I2C_CLIENT_END };
> +enum chips { lm92, max6635 };
>  
>  /* The LM92 registers */
>  #define LM92_REG_CONFIG  0x01 /* 8-bit, RW */
> @@ -329,8 +330,8 @@ static int lm92_probe(struct i2c_client *new_client,
>   */
>  
>  static const struct i2c_device_id lm92_id[] = {
> - { "lm92", 0 },
> - /* max6635 could be added here */
> + { "lm92", lm92 },
> + { "max6635", max6635 },
>   { }
>  };
>  MODULE_DEVICE_TABLE(i2c, lm92_id);

Reviewed-by: Jean Delvare 

-- 
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] hwmon: (lm92) Add max6635 to lm92_id[]

2018-03-22 Thread Alvaro Gamez Machado

Since autodetection of this chip was removed, it makes sense to add prefix
max6635 so that the device can be instantiated by its actual name.

Signed-off-by: Alvaro Gamez Machado 
---
Differences:
* Update also Documentation/hwmon/lm92 with new prefix to use

 Documentation/hwmon/lm92 | 2 +-
 drivers/hwmon/lm92.c | 5 +++--
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/Documentation/hwmon/lm92 b/Documentation/hwmon/lm92
index f2a5adcf4ead..cfa99a353b8c 100644
--- a/Documentation/hwmon/lm92
+++ b/Documentation/hwmon/lm92
@@ -11,7 +11,7 @@ Supported chips:
 Addresses scanned: none, force parameter needed
 Datasheet: http://www.national.com/pf/LM/LM76.html
   * Maxim MAX6633/MAX6634/MAX6635
-Prefix: 'lm92'
+Prefix: 'max6635'
 Addresses scanned: none, force parameter needed
 Datasheet: http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3074
 
diff --git a/drivers/hwmon/lm92.c b/drivers/hwmon/lm92.c
index 18509b5af11e..d40fe5122e94 100644
--- a/drivers/hwmon/lm92.c
+++ b/drivers/hwmon/lm92.c
@@ -52,6 +52,7 @@
  */
 static const unsigned short normal_i2c[] = { 0x48, 0x49, 0x4a, 0x4b,
I2C_CLIENT_END };
+enum chips { lm92, max6635 };
 
 /* The LM92 registers */
 #define LM92_REG_CONFIG0x01 /* 8-bit, RW */
@@ -329,8 +330,8 @@ static int lm92_probe(struct i2c_client *new_client,
  */
 
 static const struct i2c_device_id lm92_id[] = {
-   { "lm92", 0 },
-   /* max6635 could be added here */
+   { "lm92", lm92 },
+   { "max6635", max6635 },
{ }
 };
 MODULE_DEVICE_TABLE(i2c, lm92_id);
-- 
2.16.2

--
To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] hwmon: (lm92) Add max6635 to lm92_id[]

2018-03-22 Thread Alvaro Gamez Machado

Hi!

On Thu, Mar 22, 2018 at 03:29:47PM +0100, Jean Delvare wrote:
> As the driver doesn't treat the two devices differently, the enum isn't
> really needed. I don't really mind though, just a notice.

Yeah, I just thought it looked cleaner this way. I thought also about
adding an enum chips entry to struct lm92_data, but I didn't like that
because there's no use for it right now, until (if) the driver is extended
to support different but similar enough chips, so I just added the enum.

> 
> Reviewed-by: Jean Delvare 
> 
> Please also update Documentation/hwmon/lm92 which currently claims that
> the max6635 must use "lm92" as prefix.

Oh, I totally forgot about that. I'll be sending patch v2 in a couple of
minutes.

Thank you!

-- 
Alvaro G. M.
--
To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] hwmon: (lm92) Add max6635 to lm92_id[]

2018-03-22 Thread Jean Delvare

Hi Alvaro,

On Thu, 22 Mar 2018 14:43:11 +0100, Alvaro Gamez Machado wrote:
> Since autodetection of this chip was removed, it makes sense to add prefix
> max6635 so that the device can be instantiated by its actual name.
> 
> Signed-off-by: Alvaro Gamez Machado 
> ---
>  drivers/hwmon/lm92.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/hwmon/lm92.c b/drivers/hwmon/lm92.c
> index 18509b5af11e..d40fe5122e94 100644
> --- a/drivers/hwmon/lm92.c
> +++ b/drivers/hwmon/lm92.c
> @@ -52,6 +52,7 @@
>   */
>  static const unsigned short normal_i2c[] = { 0x48, 0x49, 0x4a, 0x4b,
>   I2C_CLIENT_END };
> +enum chips { lm92, max6635 };
>  
>  /* The LM92 registers */
>  #define LM92_REG_CONFIG  0x01 /* 8-bit, RW */
> @@ -329,8 +330,8 @@ static int lm92_probe(struct i2c_client *new_client,
>   */
>  
>  static const struct i2c_device_id lm92_id[] = {
> - { "lm92", 0 },
> - /* max6635 could be added here */
> + { "lm92", lm92 },
> + { "max6635", max6635 },
>   { }
>  };
>  MODULE_DEVICE_TABLE(i2c, lm92_id);

As the driver doesn't treat the two devices differently, the enum isn't
really needed. I don't really mind though, just a notice.

Reviewed-by: Jean Delvare 

Please also update Documentation/hwmon/lm92 which currently claims that
the max6635 must use "lm92" as prefix.

Thanks,
-- 
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/3] powernv: opal-sensor-groups: Add attributes to disable/enable sensors

2018-03-22 Thread Shilpasri G Bhat

This patch provides support to disable and enable plaform specific
sensor groups like performance, utilization and frequency.

Signed-off-by: Shilpasri G Bhat 
---
 .../ABI/testing/sysfs-firmware-opal-sensor-groups  | 34 +
 .../powerpc/platforms/powernv/opal-sensor-groups.c | 80 +-
 2 files changed, 83 insertions(+), 31 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-firmware-opal-sensor-groups

diff --git a/Documentation/ABI/testing/sysfs-firmware-opal-sensor-groups 
b/Documentation/ABI/testing/sysfs-firmware-opal-sensor-groups
new file mode 100644
index 000..484ff1c
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-firmware-opal-sensor-groups
@@ -0,0 +1,34 @@
+What:  /sys/firmware/opal/sensor_groups
+Date:  March 2018
+Contact:   Linux for PowerPC mailing list 
+Description:   Sensor groups directory for POWER9 powernv servers
+
+   Each folder in this directory contains a sensor group
+   which are classified based on type of the sensor
+   like power, temperature, frequency, current, etc. They
+   can also indicate the group of sensors belonging to
+   different owners like CSM, Profiler, Job-Scheduler
+
+What:  /sys/firmware/opal/sensor_groups//clear
+Date:  March 2018
+Contact:   Linux for PowerPC mailing list 
+Description:   Sysfs file to clear the min-max of all the sensors
+   belonging to the group.
+
+   Writing 1 to this file will clear the minimum and
+   maximum values of all the sensors in the group. The
+   min-max of a sensor is the historical minimum and
+   maximum value of the sensor cached by OCC.
+
+What:  /sys/firmware/opal/sensor_groups//enable
+Date:  March 2018
+Contact:   Linux for PowerPC mailing list 
+Description:   Sysfs file to enable/disable the sensor-group
+
+   Writing 0 value to this file will disable the copying
+   of the sensor-group to main memory by OCC. And writing
+   1 to this file will enable the sensor-group copying.
+   By default all the sensor-groups are enabled and will
+   be copied to main memory. This file can be used to
+   increase the update frequency of selective
+   sensor-groups.
diff --git a/arch/powerpc/platforms/powernv/opal-sensor-groups.c 
b/arch/powerpc/platforms/powernv/opal-sensor-groups.c
index 5b53f58..67f28b2 100644
--- a/arch/powerpc/platforms/powernv/opal-sensor-groups.c
+++ b/arch/powerpc/platforms/powernv/opal-sensor-groups.c
@@ -24,6 +24,7 @@
 struct sg_attr {
u32 handle;
struct kobj_attribute attr;
+   u32 opal_no;
 };
 
 static struct sensor_group {
@@ -60,34 +61,17 @@ int sensor_group_enable(u32 handle, bool enable)
 }
 EXPORT_SYMBOL_GPL(sensor_group_enable);
 
-static ssize_t sg_store(struct kobject *kobj, struct kobj_attribute *attr,
-   const char *buf, size_t count)
+static int sensor_group_clear(u32 handle)
 {
-   struct sg_attr *sattr = container_of(attr, struct sg_attr, attr);
struct opal_msg msg;
-   u32 data;
-   int ret, token;
-
-   ret = kstrtoint(buf, 0, );
-   if (ret)
-   return ret;
-
-   if (data != 1)
-   return -EINVAL;
+   int token, ret;
 
token = opal_async_get_token_interruptible();
-   if (token < 0) {
-   pr_devel("Failed to get token\n");
+   if (token < 0)
return token;
-   }
 
-   ret = mutex_lock_interruptible(_mutex);
-   if (ret)
-   goto out_token;
-
-   ret = opal_sensor_group_clear(sattr->handle, token);
-   switch (ret) {
-   case OPAL_ASYNC_COMPLETION:
+   ret = opal_sensor_group_clear(handle, token);
+   if (ret == OPAL_ASYNC_COMPLETION) {
ret = opal_async_wait_response(token, );
if (ret) {
pr_devel("Failed to wait for the async response\n");
@@ -95,20 +79,48 @@ static ssize_t sg_store(struct kobject *kobj, struct 
kobj_attribute *attr,
goto out;
}
ret = opal_error_code(opal_get_async_rc(msg));
-   if (!ret)
-   ret = count;
+   } else {
+   ret = opal_error_code(ret);
+   }
+
+out:
+   opal_async_release_token(token);
+   return ret;
+}
+
+static ssize_t sg_store(struct kobject *kobj, struct kobj_attribute *attr,
+   const char *buf, size_t count)
+{
+   struct sg_attr *sattr = container_of(attr, struct sg_attr, attr);
+   u32 data;
+   int ret;
+
+   ret = kstrtoint(buf, 0, );
+   if (ret)
+   return ret;
+
+   ret = mutex_lock_interruptible(_mutex);
+   if (ret)

[PATCH 0/3] Add support to disable sensor groups in P9

2018-03-22 Thread Shilpasri G Bhat

This patch series adds support to enable/disable OCC based
inband-sensor groups at runtime. The environmental sensor groups are
managed in HWMON and the remaining platform specific sensor groups are
managed in /sys/firmware/opal.

The firmware changes required for this patch is posted below:
https://lists.ozlabs.org/pipermail/skiboot/2018-March/010812.html

Shilpasri G Bhat (3):
  powernv:opal-sensor-groups: Add support to enable sensor groups
  hwmon: ibmpowernv: Add attributes to enable/disable sensor groups
  powernv: opal-sensor-groups: Add attributes to disable/enable sensors

 .../ABI/testing/sysfs-firmware-opal-sensor-groups  |  34 ++
 Documentation/hwmon/ibmpowernv |  31 -
 arch/powerpc/include/asm/opal-api.h|   4 +-
 arch/powerpc/include/asm/opal.h|   2 +
 .../powerpc/platforms/powernv/opal-sensor-groups.c | 104 -
 arch/powerpc/platforms/powernv/opal-wrappers.S |   1 +
 drivers/hwmon/ibmpowernv.c | 127 +++--
 7 files changed, 265 insertions(+), 38 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-firmware-opal-sensor-groups

-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] hwmon: (lm92) Add max6635 to lm92_id[]

Re: [PATCH] hwmon: (lm92) Do not try to detect MAX6635

Re: [PATCH v2] hwmon: (lm92) Add max6635 to lm92_id[]

[PATCH v2] hwmon: (lm92) Add max6635 to lm92_id[]

Re: [PATCH] hwmon: (lm92) Add max6635 to lm92_id[]

Re: [PATCH] hwmon: (lm92) Add max6635 to lm92_id[]

[PATCH 3/3] powernv: opal-sensor-groups: Add attributes to disable/enable sensors

[PATCH 0/3] Add support to disable sensor groups in P9

8 matches

Site Navigation

Mail list logo

Footer information