Re: [PATCH v3 2/2] hwmon: ina3221: Read channel input source info from DT

2018-09-22 Thread Guenter Roeck

On 09/22/2018 08:33 PM, Nicolin Chen wrote:


No. If the chip was configured by the BIOS/ROMMON, it is supposed
to be that way. We can not just override that.


For this driver, it does soft reset in the probe() so we're
sure that all channels are enabled at the moment of calling
this regmap_update_bits. So there's no assumption anymore.



Good point.


But the case that you mentioned is a good one. It does give
me some insight about the use case and the things that will
need to be careful when adding in[123]_enable. Just it'd be
also possible that BIOS could disable a channel that is not
explicitly disabled in the DT -- then the driver should not
enable it.



Not necessarily. Again, we can not assume that everyone has DT
(or that it and/or the BIOS is correct, for that matter).

Nevertheless, adding the enable attribute is not required at this
point, so it is ok for me to skip it. Please note that I'll accept
a patch adding it, though, if it is ever submitted (with a use case).

Thanks,
Guenter


Re: [PATCH v3 2/2] hwmon: ina3221: Read channel input source info from DT

2018-09-22 Thread Nicolin Chen
On Sat, Sep 22, 2018 at 08:33:00PM -0700, Nicolin Chen wrote:
> On Sat, Sep 22, 2018 at 07:07:02PM -0700, Guenter Roeck wrote:
> > On 09/22/2018 05:38 PM, Nicolin Chen wrote:
> > >On Sat, Sep 22, 2018 at 04:59:55PM -0700, Guenter Roeck wrote:
> > >
> > >+  /* Disable channels if their inputs are disconnected */
> > >+  for (i = 0, mask = 0; i < INA3221_NUM_CHANNELS; i++) {
> > >+  if (ina->inputs[i].disconnected)
> > >+  mask |= INA3221_CONFIG_CHx_EN(i);
> > >+  }
> > 
> > Consequently, you should also _enable_ channels which are not 
> > explicitly disabled.
> > >>>
> > >>>The register has enabled all channels by default. So I felt it'd
> > >>>be neat to have disabling code only. My v1 actually had enabling
> > >>>part as well, but I can add it back if you think it'd be better.
> > >>>
> > This can be tricky since you'll have to distinguish non-DT and DT 
> > configuration
> > and retain the original configuration if no channel configuration data 
> > is available
> > from devicetree.
> > >
> > >>>For non-DT configurations, input->disconnected is always false by
> > >>>default unless someone adds config for it (through platform_data).
> > >>>If regmap_update_bits only does disabling like this version does,
> > >>>non-DT configurations will not get affected since mask = 0. Or if
> > >>>we change it to do both enabling and disabling, regmap_update_bits
> > >>>will still ignore since there's no register value changed, though
> > >>>it won't really hurt even if regmap writes correct configurations
> > >>>to the register.
> > >>>
> > >>>For DT configurations (without channel input source defined), it's
> > >>>like the same as non-DT configurations. As we have platforms only
> > >>>enabled ina3221 via DT while they don't have this new DT binding,
> > >>>the driver has to be backward compatible, so my change only sets
> > >>>input->disconnected=true when a status="disabled" is present, i.e.
> > >>>those platforms are treated as all channels getting enabled until
> > >>>they update their DTs.
> > >
> > >>I think your assumption may be that the chip is always in its reset state
> > >>when Linux is loaded. This is not necessarily the case; it may be
> > >>preconfigured by BIOS or ROMMON, or even by someone using i2cset before
> > >>loading the driver. If you add enable/disable functionality, you can
> > >>not make an assumption about the original state of the chip at probe time;
> > >>you have to read it from the chip itself.
> > >
> > >I see. That made a point. In that case, I think the simplest way
> > >is probably to do software reset before having configurations.
> > >
> > No. If the chip was configured by the BIOS/ROMMON, it is supposed
> > to be that way. We can not just override that.
> 
> For this driver, it does soft reset in the probe() so we're
> sure that all channels are enabled at the moment of calling
> this regmap_update_bits. So there's no assumption anymore.
> 
> But the case that you mentioned is a good one. It does give
> me some insight about the use case and the things that will
> need to be careful when adding in[123]_enable. Just it'd be
> also possible that BIOS could disable a channel that is not
> explicitly disabled in the DT -- then the driver should not
> enable it.
> 
> Therefore, for both cases, it seems that disabling only the
> disconnected channels as this version is a safe solution.
> 
> And the driver actually won't update input->disconnected as
> this is a physical hardware status that won't be changed. I

[...]
> probably could define the input->disconnected in const type.
[...]

Please ignore this line. It'd be read-only then. I got myself
confused as it's not a pointer like label.

> For in[123]_enable, it'd be safer to read/write the register
> directly.
> 
> Thanks
> Nicolin
> 
> > >The "disconnected" here is to describe the physical connection,
> > >not exact the switch control status because a channel could be
> > >connected but disabled. However, a channel would not be enabled
> > >if it's disconnected. So I think it'd be safe to just disable
> > >the disconnected channels here as this version does, meanwhile,
> > >I will add a soft reset to make sure all channels are enabled.
> > >
> > >Thanks
> > >Nicolin
> > >
> > 


Re: [PATCH v3 2/2] hwmon: ina3221: Read channel input source info from DT

2018-09-22 Thread Nicolin Chen
On Sat, Sep 22, 2018 at 04:59:55PM -0700, Guenter Roeck wrote:

> > > > +   /* Disable channels if their inputs are disconnected */
> > > > +   for (i = 0, mask = 0; i < INA3221_NUM_CHANNELS; i++) {
> > > > +   if (ina->inputs[i].disconnected)
> > > > +   mask |= INA3221_CONFIG_CHx_EN(i);
> > > > +   }
> > > 
> > > Consequently, you should also _enable_ channels which are not explicitly 
> > > disabled.
> > 
> > The register has enabled all channels by default. So I felt it'd
> > be neat to have disabling code only. My v1 actually had enabling
> > part as well, but I can add it back if you think it'd be better.
> > 
> > > This can be tricky since you'll have to distinguish non-DT and DT 
> > > configuration
> > > and retain the original configuration if no channel configuration data is 
> > > available
> > > from devicetree.

> > For non-DT configurations, input->disconnected is always false by
> > default unless someone adds config for it (through platform_data).
> > If regmap_update_bits only does disabling like this version does,
> > non-DT configurations will not get affected since mask = 0. Or if
> > we change it to do both enabling and disabling, regmap_update_bits
> > will still ignore since there's no register value changed, though
> > it won't really hurt even if regmap writes correct configurations
> > to the register.
> > 
> > For DT configurations (without channel input source defined), it's
> > like the same as non-DT configurations. As we have platforms only
> > enabled ina3221 via DT while they don't have this new DT binding,
> > the driver has to be backward compatible, so my change only sets
> > input->disconnected=true when a status="disabled" is present, i.e.
> > those platforms are treated as all channels getting enabled until
> > they update their DTs.

> I think your assumption may be that the chip is always in its reset state
> when Linux is loaded. This is not necessarily the case; it may be
> preconfigured by BIOS or ROMMON, or even by someone using i2cset before
> loading the driver. If you add enable/disable functionality, you can
> not make an assumption about the original state of the chip at probe time;
> you have to read it from the chip itself.

I see. That made a point. In that case, I think the simplest way
is probably to do software reset before having configurations.

The "disconnected" here is to describe the physical connection,
not exact the switch control status because a channel could be
connected but disabled. However, a channel would not be enabled
if it's disconnected. So I think it'd be safe to just disable
the disconnected channels here as this version does, meanwhile,
I will add a soft reset to make sure all channels are enabled.

Thanks
Nicolin


Re: [PATCH v3 2/2] hwmon: ina3221: Read channel input source info from DT

2018-09-22 Thread Guenter Roeck

On 09/22/2018 11:46 AM, Nicolin Chen wrote:

This patch adds a new structure of input source specific
information including input source label, shunt resistor
value and its connection status. It exposes these labels
via sysfs and also disables those channels where there's
no input source being connected.



I see you have decided to just display the disconnected channels.
This is misleading, and I can not accept it. Please either use the
is_visible callback to not display those channels at all, or have


I will add is_visible. I have almost finished it while waiting for
the v3's review comments. Will test it and include in the v4.


the _input attribute of disabled channels return -ENODATA (see
'in[0-*]_enable' attribute in the ABI). If you implement the latter,
I would suggest to also implement the _enable attribute.


I will also add one separate patch for in[0-*]_enable after these
two changes pass the review and get applied.


As mentioned in patch 1, I can not accept an implicitly mandatory
label attribute. The property defining the label attribute will
have to be optional and well defined to ensure that it matches
the ABI.


I replied this in the PATCH-1. Let's discuss this topic there.


+   /* Disable channels if their inputs are disconnected */
+   for (i = 0, mask = 0; i < INA3221_NUM_CHANNELS; i++) {
+   if (ina->inputs[i].disconnected)
+   mask |= INA3221_CONFIG_CHx_EN(i);
+   }


Consequently, you should also _enable_ channels which are not explicitly 
disabled.


The register has enabled all channels by default. So I felt it'd
be neat to have disabling code only. My v1 actually had enabling
part as well, but I can add it back if you think it'd be better.


This can be tricky since you'll have to distinguish non-DT and DT configuration
and retain the original configuration if no channel configuration data is 
available
from devicetree.


I don't quite understand this comments. Would you please elaborate
it?

For non-DT configurations, input->disconnected is always false by
default unless someone adds config for it (through platform_data).
If regmap_update_bits only does disabling like this version does,
non-DT configurations will not get affected since mask = 0. Or if
we change it to do both enabling and disabling, regmap_update_bits
will still ignore since there's no register value changed, though
it won't really hurt even if regmap writes correct configurations
to the register.

For DT configurations (without channel input source defined), it's
like the same as non-DT configurations. As we have platforms only
enabled ina3221 via DT while they don't have this new DT binding,
the driver has to be backward compatible, so my change only sets
input->disconnected=true when a status="disabled" is present, i.e.
those platforms are treated as all channels getting enabled until
they update their DTs.



I think your assumption may be that the chip is always in its reset state
when Linux is loaded. This is not necessarily the case; it may be
preconfigured by BIOS or ROMMON, or even by someone using i2cset before
loading the driver. If you add enable/disable functionality, you can
not make an assumption about the original state of the chip at probe time;
you have to read it from the chip itself.

Thanks,
Guenter


Re: [PATCH v3 2/2] hwmon: ina3221: Read channel input source info from DT

2018-09-22 Thread Nicolin Chen
> >This patch adds a new structure of input source specific
> >information including input source label, shunt resistor
> >value and its connection status. It exposes these labels
> >via sysfs and also disables those channels where there's
> >no input source being connected.
> >
> 
> I see you have decided to just display the disconnected channels.
> This is misleading, and I can not accept it. Please either use the
> is_visible callback to not display those channels at all, or have

I will add is_visible. I have almost finished it while waiting for
the v3's review comments. Will test it and include in the v4.

> the _input attribute of disabled channels return -ENODATA (see
> 'in[0-*]_enable' attribute in the ABI). If you implement the latter,
> I would suggest to also implement the _enable attribute.

I will also add one separate patch for in[0-*]_enable after these
two changes pass the review and get applied.

> As mentioned in patch 1, I can not accept an implicitly mandatory
> label attribute. The property defining the label attribute will
> have to be optional and well defined to ensure that it matches
> the ABI.

I replied this in the PATCH-1. Let's discuss this topic there.

> >+/* Disable channels if their inputs are disconnected */
> >+for (i = 0, mask = 0; i < INA3221_NUM_CHANNELS; i++) {
> >+if (ina->inputs[i].disconnected)
> >+mask |= INA3221_CONFIG_CHx_EN(i);
> >+}
> 
> Consequently, you should also _enable_ channels which are not explicitly 
> disabled.

The register has enabled all channels by default. So I felt it'd
be neat to have disabling code only. My v1 actually had enabling
part as well, but I can add it back if you think it'd be better.

> This can be tricky since you'll have to distinguish non-DT and DT 
> configuration
> and retain the original configuration if no channel configuration data is 
> available
> from devicetree.

I don't quite understand this comments. Would you please elaborate
it?

For non-DT configurations, input->disconnected is always false by
default unless someone adds config for it (through platform_data).
If regmap_update_bits only does disabling like this version does,
non-DT configurations will not get affected since mask = 0. Or if
we change it to do both enabling and disabling, regmap_update_bits
will still ignore since there's no register value changed, though
it won't really hurt even if regmap writes correct configurations
to the register.

For DT configurations (without channel input source defined), it's
like the same as non-DT configurations. As we have platforms only
enabled ina3221 via DT while they don't have this new DT binding,
the driver has to be backward compatible, so my change only sets
input->disconnected=true when a status="disabled" is present, i.e.
those platforms are treated as all channels getting enabled until
they update their DTs.

Thanks for the review
Nicolin


Re: [PATCH v3 2/2] hwmon: ina3221: Read channel input source info from DT

2018-09-22 Thread Guenter Roeck

Hi,

On 09/21/2018 03:32 PM, Nicolin Chen wrote:

From: Nicolin Chen 

An ina3221 chip has three input ports. Each port is used
to measure the voltage and current of its input source.

The DT binding now has defined bindings for their input
sources, so the driver should read these information and
handle accordingly.

This patch adds a new structure of input source specific
information including input source label, shunt resistor
value and its connection status. It exposes these labels
via sysfs and also disables those channels where there's
no input source being connected.



I see you have decided to just display the disconnected channels.
This is misleading, and I can not accept it. Please either use the
is_visible callback to not display those channels at all, or have
the _input attribute of disabled channels return -ENODATA (see
'in[0-*]_enable' attribute in the ABI). If you implement the latter,
I would suggest to also implement the _enable attribute.

As mentioned in patch 1, I can not accept an implicitly mandatory
label attribute. The property defining the label attribute will
have to be optional and well defined to ensure that it matches
the ABI.

One more comment inline below.

Thanks,
Guenter


Signed-off-by: Nicolin Chen 
---
Changelog
v2->v3:
  * N/A
v1->v2:
  * Added a structure for input source corresponding to DT bindings
  * Moved shunt resistor value to the structure
  * Defined in[123]_label sysfs nodes instead of name[123]_input
  * Updated probe() function to get information from DT
  * Updated ina3221 hwmon documentation for the labels
  * Dropped dynamical group definition to keep all groups as they were
  * * Will send an incremental patch later apart from this DT binding series

  Documentation/hwmon/ina3221 |   1 +
  drivers/hwmon/ina3221.c | 126 +---
  2 files changed, 117 insertions(+), 10 deletions(-)

diff --git a/Documentation/hwmon/ina3221 b/Documentation/hwmon/ina3221
index 0ff74854cb2e..2726038be5bd 100644
--- a/Documentation/hwmon/ina3221
+++ b/Documentation/hwmon/ina3221
@@ -22,6 +22,7 @@ Sysfs entries
  -
  
  in[123]_input   Bus voltage(mV) channels

+in[123]_label   Voltage channel labels
  curr[123]_input Current(mA) measurement channels
  shunt[123]_resistor Shunt resistance(uOhm) channels
  curr[123]_crit  Critical alert current(mA) setting, activates the
diff --git a/drivers/hwmon/ina3221.c b/drivers/hwmon/ina3221.c
index e6b49500c52a..ba470fc53e27 100644
--- a/drivers/hwmon/ina3221.c
+++ b/drivers/hwmon/ina3221.c
@@ -41,6 +41,7 @@
  #define INA3221_CONFIG_MODE_SHUNT BIT(1)
  #define INA3221_CONFIG_MODE_BUS   BIT(2)
  #define INA3221_CONFIG_MODE_CONTINUOUSBIT(3)
+#define INA3221_CONFIG_CHx_EN(x)   BIT(14 - (x))
  
  #define INA3221_RSHUNT_DEFAULT		1
  
@@ -86,16 +87,28 @@ static const unsigned int register_channel[] = {

[INA3221_WARN3] = INA3221_CHANNEL3,
  };
  
+/**

+ * struct ina3221_input - channel input source specific information
+ * @label: label of channel input source
+ * @shunt_resistor: shunt resistor value of channel input source
+ * @disconnected: connection status of channel input source
+ */
+struct ina3221_input {
+   const char *label;
+   int shunt_resistor;
+   bool disconnected;
+};
+
  /**
   * struct ina3221_data - device specific information
   * @regmap: Register map of the device
   * @fields: Register fields of the device
- * @shunt_resistors: Array of resistor values per channel
+ * @inputs: Array of channel input source specific structures
   */
  struct ina3221_data {
struct regmap *regmap;
struct regmap_field *fields[F_MAX_FIELDS];
-   int shunt_resistors[INA3221_NUM_CHANNELS];
+   struct ina3221_input inputs[INA3221_NUM_CHANNELS];
  };
  
  static int ina3221_read_value(struct ina3221_data *ina, unsigned int reg,

@@ -131,6 +144,17 @@ static ssize_t ina3221_show_bus_voltage(struct device *dev,
return snprintf(buf, PAGE_SIZE, "%d\n", voltage_mv);
  }
  
+static ssize_t ina3221_show_label(struct device *dev,

+ struct device_attribute *attr, char *buf)
+{
+   struct sensor_device_attribute *sd_attr = to_sensor_dev_attr(attr);
+   struct ina3221_data *ina = dev_get_drvdata(dev);
+   unsigned int channel = sd_attr->index;
+   struct ina3221_input *input = >inputs[channel];
+
+   return snprintf(buf, PAGE_SIZE, "%s\n", input->label);
+}
+
  static ssize_t ina3221_show_shunt_voltage(struct device *dev,
  struct device_attribute *attr,
  char *buf)
@@ -155,7 +179,8 @@ static ssize_t ina3221_show_current(struct device *dev,
struct ina3221_data *ina = dev_get_drvdata(dev);
unsigned int reg = sd_attr->index;
unsigned int channel = register_channel[reg];
-   int resistance_uo = ina->shunt_resistors[channel];
+