All of lore.kernel.org
 help / color / mirror / Atom feed
From: Guenter Roeck <guenter.roeck@ericsson.com>
To: MyungJoo Ham <myungjoo.ham@samsung.com>
Cc: "lm-sensors@lm-sensors.org" <lm-sensors@lm-sensors.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jean Delvare <khali@linux-fr.org>,
	"dg77.kim@samsung.com" <dg77.kim@samsung.com>,
	"kyungmin.park@samsung.com" <kyungmin.park@samsung.com>,
	"myungjoo.ham@gmail.com" <myungjoo.ham@gmail.com>
Subject: Re: [lm-sensors] [RFC PATCH 0/2] HWMON: add in-kernel interfaces to
Date: Sun, 06 Nov 2011 05:53:43 +0000	[thread overview]
Message-ID: <20111106055343.GA21533@ericsson.com> (raw)
In-Reply-To: <1320389433-1671-1-git-send-email-myungjoo.ham@samsung.com>

On Fri, Nov 04, 2011 at 02:50:31AM -0400, MyungJoo Ham wrote:
> We have been reading hwmon values (TMU, the SoC-core temperature sensor,
> and NTC, the ambient or battery surface temperature sensor) for
> Charger-Manager. However, because hwmon does not have in-kernel interface,
> we have been using undesired method, including "../../../fs/*.h".
> 
> This patch is to provide in-kernel interface for hwmon:
> hwmon_get_value and hwmon_set_value. In order to use these two functions,
> the hwmon driver should provide its sysfs attributes to hwmon framework
> as well. If the hwmon driver does not provide (by providing NULL), the users
> of the hwmon won't be able to use hwmon_get/set_value();
> The sysfs attribute (struct attribuyte_group *) is provided with
> hwmon_device_register; adding the second parameter to hwmon_device_register().
> The 2/2 patch shows the changes in device drivers due to this.
> 
> Among the HWMON device, all but ntc_thermistor.c does not setup attribute_group
> for HWMON; thus they do not support hwmon_get/set_value with this patch.
> 
> As soon as the server synchronizes git repositories, you can see how
> hwmon_get_value() is used at:
> http://git.infradead.org/users/kmpark/linux-2.6-samsung/shortlog/refs/heads/charger-manager
> 
Hi,

I agree that we'll need a solution for the callback problem at some point.
However, I have a number of concerns with the approach used in your patch set.

The first patch breaks compilation. It changes the API w/o making the same changes
in the affected drivers. This is unacceptable. Each patch of a patch series must 
result in working code.

Merging functionality into one function and then breaking out again, as you do with
the set/get functions, results in unnecessarily complexity.
        {set, get} -> access(flag) --> {set, get}
Better write separate functions and keep the common code in a function called by the
{set, get} functions.

We should not have to change the API for every caller, especially if many of those will
never benefit from the new API. It would be better to define a new API function and map
the old API function to the new one. Saves a lot of calls with unnecessary "NULL" parameter,
and coincidentially reduces the patch size and avoids the breakage mentioned above.

The get and set functions are extremely expensive, having to loop through the list
of attributes and performing a string comparison on each attribute to find the sensor.

The proposed change only works for a small subset of drivers, those with a well defined
single attribute groups. If and when we implement a solution for the internal-API
problem, it should work for all hwmon drivers, not only for a small subset.

Thanks,
Guenter


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

WARNING: multiple messages have this Message-ID (diff)
From: Guenter Roeck <guenter.roeck@ericsson.com>
To: MyungJoo Ham <myungjoo.ham@samsung.com>
Cc: "lm-sensors@lm-sensors.org" <lm-sensors@lm-sensors.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jean Delvare <khali@linux-fr.org>,
	"dg77.kim@samsung.com" <dg77.kim@samsung.com>,
	"kyungmin.park@samsung.com" <kyungmin.park@samsung.com>,
	"myungjoo.ham@gmail.com" <myungjoo.ham@gmail.com>
Subject: Re: [RFC PATCH 0/2] HWMON: add in-kernel interfaces to read sensor values.
Date: Sat, 5 Nov 2011 22:53:43 -0700	[thread overview]
Message-ID: <20111106055343.GA21533@ericsson.com> (raw)
In-Reply-To: <1320389433-1671-1-git-send-email-myungjoo.ham@samsung.com>

On Fri, Nov 04, 2011 at 02:50:31AM -0400, MyungJoo Ham wrote:
> We have been reading hwmon values (TMU, the SoC-core temperature sensor,
> and NTC, the ambient or battery surface temperature sensor) for
> Charger-Manager. However, because hwmon does not have in-kernel interface,
> we have been using undesired method, including "../../../fs/*.h".
> 
> This patch is to provide in-kernel interface for hwmon:
> hwmon_get_value and hwmon_set_value. In order to use these two functions,
> the hwmon driver should provide its sysfs attributes to hwmon framework
> as well. If the hwmon driver does not provide (by providing NULL), the users
> of the hwmon won't be able to use hwmon_get/set_value();
> The sysfs attribute (struct attribuyte_group *) is provided with
> hwmon_device_register; adding the second parameter to hwmon_device_register().
> The 2/2 patch shows the changes in device drivers due to this.
> 
> Among the HWMON device, all but ntc_thermistor.c does not setup attribute_group
> for HWMON; thus they do not support hwmon_get/set_value with this patch.
> 
> As soon as the server synchronizes git repositories, you can see how
> hwmon_get_value() is used at:
> http://git.infradead.org/users/kmpark/linux-2.6-samsung/shortlog/refs/heads/charger-manager
> 
Hi,

I agree that we'll need a solution for the callback problem at some point.
However, I have a number of concerns with the approach used in your patch set.

The first patch breaks compilation. It changes the API w/o making the same changes
in the affected drivers. This is unacceptable. Each patch of a patch series must 
result in working code.

Merging functionality into one function and then breaking out again, as you do with
the set/get functions, results in unnecessarily complexity.
        {set, get} -> access(flag) --> {set, get}
Better write separate functions and keep the common code in a function called by the
{set, get} functions.

We should not have to change the API for every caller, especially if many of those will
never benefit from the new API. It would be better to define a new API function and map
the old API function to the new one. Saves a lot of calls with unnecessary "NULL" parameter,
and coincidentially reduces the patch size and avoids the breakage mentioned above.

The get and set functions are extremely expensive, having to loop through the list
of attributes and performing a string comparison on each attribute to find the sensor.

The proposed change only works for a small subset of drivers, those with a well defined
single attribute groups. If and when we implement a solution for the internal-API
problem, it should work for all hwmon drivers, not only for a small subset.

Thanks,
Guenter


  parent reply	other threads:[~2011-11-06  5:53 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-04  6:50 [lm-sensors] [RFC PATCH 0/2] HWMON: add in-kernel interfaces to MyungJoo Ham
2011-11-04  6:50 ` [RFC PATCH 0/2] HWMON: add in-kernel interfaces to read sensor values MyungJoo Ham
2011-11-04  6:50 ` [lm-sensors] [RFC PATCH 1/2] HWMON: add interfaces to read/write MyungJoo Ham
2011-11-04  6:50   ` [RFC PATCH 1/2] HWMON: add interfaces to read/write hwmon values inside kernel MyungJoo Ham
2011-11-04  6:50 ` [lm-sensors] [RFC PATCH 2/2] HWMON: adapt to the HWMON interface MyungJoo Ham
2011-11-04  6:50   ` [RFC PATCH 2/2] HWMON: adapt to the HWMON interface changes MyungJoo Ham
2011-11-06  5:53 ` Guenter Roeck [this message]
2011-11-06  5:53   ` [RFC PATCH 0/2] HWMON: add in-kernel interfaces to read sensor values Guenter Roeck
2011-11-07  4:35   ` [lm-sensors] [RFC PATCH 0/2] HWMON: add in-kernel interfaces to MyungJoo Ham
2011-11-07  4:35     ` [RFC PATCH 0/2] HWMON: add in-kernel interfaces to read sensor values MyungJoo Ham
2011-11-11 20:46 ` [lm-sensors] [RFC PATCH 0/2] HWMON: add in-kernel interfaces to Ben Hutchings
2011-11-11 20:46   ` [RFC PATCH 0/2] HWMON: add in-kernel interfaces to read sensor values Ben Hutchings
2011-11-14  1:31   ` [lm-sensors] [RFC PATCH 0/2] HWMON: add in-kernel interfaces to MyungJoo Ham
2011-11-14  1:31     ` [RFC PATCH 0/2] HWMON: add in-kernel interfaces to read sensor values MyungJoo Ham
2011-11-14 16:39     ` [lm-sensors] [RFC PATCH 0/2] HWMON: add in-kernel interfaces to Jonathan Cameron
2011-11-14 16:39       ` [RFC PATCH 0/2] HWMON: add in-kernel interfaces to read sensor values Jonathan Cameron
2011-11-17  8:22       ` [lm-sensors] [RFC PATCH 0/2] HWMON: add in-kernel interfaces to MyungJoo Ham
2011-11-17  8:22         ` [RFC PATCH 0/2] HWMON: add in-kernel interfaces to read sensor values MyungJoo Ham
2011-11-17 20:40         ` [lm-sensors] [RFC PATCH 0/2] HWMON: add in-kernel interfaces to Jonathan Cameron
2011-11-17 20:40           ` [RFC PATCH 0/2] HWMON: add in-kernel interfaces to read sensor values Jonathan Cameron

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20111106055343.GA21533@ericsson.com \
    --to=guenter.roeck@ericsson.com \
    --cc=dg77.kim@samsung.com \
    --cc=khali@linux-fr.org \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lm-sensors@lm-sensors.org \
    --cc=myungjoo.ham@gmail.com \
    --cc=myungjoo.ham@samsung.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.