Re: [PATCH] Initial driver for the MAX31785 intelligent fan controller

2016-09-20 Thread Guenter Roeck 

On 09/20/2016 01:01 PM, Timothy Pearson wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/20/2016 02:59 PM, Guenter Roeck wrote:

On Tue, Sep 20, 2016 at 02:41:56PM -0500, Timothy Pearson wrote:

On 09/19/2016 07:54 PM, Guenter Roeck wrote:

On 09/19/2016 03:04 PM, Guenter Roeck wrote:
And then you are using all pmbus commands ? Seems odd.


I guess I'l buy an evaluation board if one is available and check if your claim
is correct. I am not inclined to accept a non-pmbus driver for a pmbus
device without good reason.

Guenter


Regarding the PMBus driver, I looked over the documentation available
here: https://www.kernel.org/doc/Documentation/hwmon/pmbus

From what I can tell PMBus drivers do not support configuring the fan
control parameters, only monitoring the fan status and speed.  Is this
correct, and if not where would I find the correct documentation?


So far that wasn't needed. That doesn't mean it can not be added.

I orderd an evaluation board and will likely spend some time on it myself
after I get it.

Guenter


OK, sounds good.  I looked back in the notes for this project and we had
originally considered using a PMBus driver but ran into the kernel
documentation, noted the missing control features, and I subsequently


It is always useful to talk with the maintainer.


misinterpreted the datasheet using the kernel docs as a reference.  This
is why the hwmon driver was implemented.



I am still not sure I understand what irked you off in the datasheet.
Is it the "supports a subset of the commands defined in the PMBus
Specfication" ? If so, please keep in mind that every single chip
supporting PMBus will only support a subset of PMBus commands.


Please let me know if I can be of any assistance.


Sure, I'll let you know.

Thanks,
Guenter

--
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] Initial driver for the MAX31785 intelligent fan controller

2016-09-20 Thread Timothy Pearson 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/20/2016 02:59 PM, Guenter Roeck wrote:
> On Tue, Sep 20, 2016 at 02:41:56PM -0500, Timothy Pearson wrote:
>> On 09/19/2016 07:54 PM, Guenter Roeck wrote:
 On 09/19/2016 03:04 PM, Guenter Roeck wrote:
 And then you are using all pmbus commands ? Seems odd.
>>>
>>> I guess I'l buy an evaluation board if one is available and check if your 
>>> claim
>>> is correct. I am not inclined to accept a non-pmbus driver for a pmbus
>>> device without good reason.
>>>
>>> Guenter
>>
>> Regarding the PMBus driver, I looked over the documentation available
>> here: https://www.kernel.org/doc/Documentation/hwmon/pmbus
>>
>> From what I can tell PMBus drivers do not support configuring the fan
>> control parameters, only monitoring the fan status and speed.  Is this
>> correct, and if not where would I find the correct documentation?
>>
> So far that wasn't needed. That doesn't mean it can not be added.
> 
> I orderd an evaluation board and will likely spend some time on it myself
> after I get it.
> 
> Guenter

OK, sounds good.  I looked back in the notes for this project and we had
originally considered using a PMBus driver but ran into the kernel
documentation, noted the missing control features, and I subsequently
misinterpreted the datasheet using the kernel docs as a reference.  This
is why the hwmon driver was implemented.

Please let me know if I can be of any assistance.

Thanks!

- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJX4ZWeAAoJEK+E3vEXDOFbSNkH/3IqLAbvz2aVyPUBhKBFHC72
0uaP/IhBIoDoKAdZ50jJljYQIub0hn6HrQH52SYXvNhkO43+UJwqOxIRliipueDg
X9H2esdeaptjI+O3dXCv5bLyMgy+ohGv1aPkxon+BTo506NWlHOyYlbCscIgmuMu
nsMmHVGQvEyMtbJHlwmT0tjE81IEYxFxc1eLPbPhcrdz1f6yIAY7tHFo5ZjE+wt8
mzU35ZI+zIkKbD88Qfs8Ca/aTfRzt5xDKHDI3//YouyiqlnDK7etoZrAtx2RxtcJ
Qv8k2udTpQuuYwwGobwC0SSWaxeRMlRaumX+ZkIYJz7xSp1krnArx5na2r2cTr8=
=Guwk
-END PGP SIGNATURE-
--
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] lm87: Allow channel data to be set from dts file.

2016-09-20 Thread Frank Rowand 
On 09/19/16 22:22, Mahoda Ratnayaka wrote:
> Currently there is no method for setting the channel
> value from the DTS file. When, the driver uses a dts
> file to initialize the driver platform_data is not set.
> As a the result channel variable may not be set correctly.
> 
> Without the channel variable set correctly, some of the
> sensors will not be initialized correctly. For example
> temp3 sensor sysfs entries.
> 
> This adds the required functionality to set the channel
> variable from the DTS file. This is done via reading the
> reading a property named "channel" from the lm87 driver.
> 
> Signed-off-by: Mahoda Ratnayaka 
> ---
> 
> Notes:
>  changes since v1:
>  Removed unncessary variables channel and np.
>  Update the code as per review comments.
> 
>  Documentation/devicetree/bindings/hwmon/lm87.txt | 9 +
>  drivers/hwmon/lm87.c | 7 ++-
>  2 files changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/hwmon/lm87.txt 
> b/Documentation/devicetree/bindings/hwmon/lm87.txt
> index fefcb48..1906e08 100644
> --- a/Documentation/devicetree/bindings/hwmon/lm87.txt
> +++ b/Documentation/devicetree/bindings/hwmon/lm87.txt

I do not see the file Documentation/devicetree/bindings/hwmon/lm87.txt in
Linux 4.8-rc7.  I am guessing that it might already be in a tree headed
upstream.  Can you point me to it?


> @@ -6,9 +6,18 @@ Required properties:
>  
>  - reg: I2C address
>  
> +optional properties:
> +- channels: Value for the channel mode register.
> +This allows configuration of pins with
> +selectable uses on the LM87 device (e.g.
> +choosing between voltage and temperature
> +inputs).
> +See hwmon/lm87 for further information
> +

That is configuration information, not hardware description.
Devicetree contains hardware description.

Hardware description would instead be a property that said what
is hooked up to the shared pins, eg temp3, fan1, fan2, VID, or
IRQ.  The driver should know what value to place in channel for
each of the different cases.

>  Example:
>  
>  lm87@2e {
>   compatible = "ti,lm87";
>   reg = <0x2e>;
> + channels=<0x4>;
>  };
> diff --git a/drivers/hwmon/lm87.c b/drivers/hwmon/lm87.c
> index a5e2958..358c1d4 100644
> --- a/drivers/hwmon/lm87.c
> +++ b/drivers/hwmon/lm87.c
> @@ -858,8 +858,13 @@ static void lm87_remove_files(struct i2c_client *client)
>  static void lm87_init_client(struct i2c_client *client)
>  {
>   struct lm87_data *data = i2c_get_clientdata(client);
> + u8 val = 0;
>  
> - if (dev_get_platdata(>dev)) {
> + if (!of_property_read_u8(client->dev.of_node, "channels", )) {
> + data->channel = val;
> + lm87_write_value(client,
> +  LM87_REG_CHANNEL_MODE, data->channel);
> + } else if (dev_get_platdata(>dev)) {
>   data->channel = *(u8 *)dev_get_platdata(>dev);
>   lm87_write_value(client,
>LM87_REG_CHANNEL_MODE, data->channel);
> 

--
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] lm87: Allow channel data to be set from dts file.

2016-09-20 Thread Guenter Roeck 

On 09/19/2016 10:22 PM, Mahoda Ratnayaka wrote:

Currently there is no method for setting the channel
value from the DTS file. When, the driver uses a dts
file to initialize the driver platform_data is not set.
As a the result channel variable may not be set correctly.

Without the channel variable set correctly, some of the
sensors will not be initialized correctly. For example
temp3 sensor sysfs entries.

This adds the required functionality to set the channel
variable from the DTS file. This is done via reading the
reading a property named "channel" from the lm87 driver.

Signed-off-by: Mahoda Ratnayaka 
---

Notes:
 changes since v1:
 Removed unncessary variables channel and np.
 Update the code as per review comments.

 Documentation/devicetree/bindings/hwmon/lm87.txt | 9 +
 drivers/hwmon/lm87.c | 7 ++-
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/hwmon/lm87.txt 
b/Documentation/devicetree/bindings/hwmon/lm87.txt
index fefcb48..1906e08 100644
--- a/Documentation/devicetree/bindings/hwmon/lm87.txt
+++ b/Documentation/devicetree/bindings/hwmon/lm87.txt
@@ -6,9 +6,18 @@ Required properties:

 - reg: I2C address

+optional properties:
+- channels: Value for the channel mode register.
+This allows configuration of pins with
+selectable uses on the LM87 device (e.g.
+choosing between voltage and temperature
+inputs).
+See hwmon/lm87 for further information


Rob is the ultimate person to comment here, but I think the property description
by itself should be complete and technically independent of the implementation.
Documentation/hwmon/lm87 describes the implementation, so an (incomplete)
reference to it seems inappropriate.


+
 Example:

 lm87@2e {
compatible = "ti,lm87";
reg = <0x2e>;
+   channels=<0x4>;
 };


Please move those property descriptions into the first patch. It is confusing
to have two patches touching the properties, and the first patch as it is right 
now
is really useless.


diff --git a/drivers/hwmon/lm87.c b/drivers/hwmon/lm87.c
index a5e2958..358c1d4 100644
--- a/drivers/hwmon/lm87.c
+++ b/drivers/hwmon/lm87.c
@@ -858,8 +858,13 @@ static void lm87_remove_files(struct i2c_client *client)
 static void lm87_init_client(struct i2c_client *client)
 {
struct lm87_data *data = i2c_get_clientdata(client);
+   u8 val = 0;

-   if (dev_get_platdata(>dev)) {
+   if (!of_property_read_u8(client->dev.of_node, "channels", )) {


This ignores property value errors (-ENODATA, -EOVERFLOW).
Is this what you want ?


+   data->channel = val;
+   lm87_write_value(client,
+LM87_REG_CHANNEL_MODE, data->channel);
+   } else if (dev_get_platdata(>dev)) {
data->channel = *(u8 *)dev_get_platdata(>dev);
lm87_write_value(client,
 LM87_REG_CHANNEL_MODE, data->channel);



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