All of lore.kernel.org
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: "thilo.cestonaro@ts.fujitsu.com" <thilo.cestonaro@ts.fujitsu.com>,
	"linux-hwmon@vger.kernel.org" <linux-hwmon@vger.kernel.org>
Subject: Re: [PATCH] added kernel module for FTS sensor chip "Teutates"
Date: Mon, 6 Jun 2016 20:18:24 -0700	[thread overview]
Message-ID: <57563D00.3030005@roeck-us.net> (raw)
In-Reply-To: <1465204713.5580.25.camel@ts.fujitsu.com>

On 06/06/2016 02:21 AM, thilo.cestonaro@ts.fujitsu.com wrote:
> Hey Guenter!
>
> Thanks for your patience and very detailed review!
> I will change the code to address all you hints where no discussion is needed.
> The others follow down here.
>
> On Fr, 2016-06-03 at 22:51 -0700, Guenter Roeck wrote:
>>> +#define FTSTEUTATES_WATCHDOG_RESOLUTION		   60
>>> +
>> 60 seconds (minimum) resolution ? Really ? This is very unusual.
> Will double check and talk to the hw guy.
>
>>> +static ssize_t show_fan_fault(struct device *dev,
>>> +	struct device_attribute *devattr, char *buf)
>>> +{
>>> +	int index = to_sensor_dev_attr(devattr)->index;
>>> +	struct ftsteutates_data *data = ftsteutates_update_device(dev);
>>> +
>>> +	return sprintf(buf, "%d\n", data->fan_present[index] == 1 ? 0 : 1);
>> A non-present fan does not indicate a fan fault.
> For me a fan fault was a not existing fan, as the alarm is handled via fan_alarm.
> What is the understanding of fan_fault and fan_alarm?
>

Some fan controllers can detect if a fan is faulty, for example if it consumes
power but does not turn. Unless you know for sure that a fan is faulty, don't
report that it is. A non-existing fan is definitely not faulty.

>>> +static ssize_t show_fan_source(struct device *dev,
>>> +		struct device_attribute *devattr, char *buf)
>>> +{
>>> +	int index = to_sensor_dev_attr(devattr)->index;
>>> +	struct ftsteutates_data *data = ftsteutates_update_device(dev);
>>> +
>>> +	if (data->fan_present[index]) {
>>> +		if (data->fan_source[index] == 0xFF)
>>> +			return sprintf(buf, "none\n");
>>> +		else
>>> +			return sprintf(buf, "%d\n", data->fan_source[index]);
>>> +	} else
>>> +		return sprintf(buf, "-\n");
>> is_visible() is your friend here. If the fan is not present, don't display
>> the attributes. If fan presence can change at runtime, just display 0.
> I just tried to change to presence at runtime (pull the fan cable),
> and it looks like I don't change. So I'll use the is_visible function of the
> sysfs entries.
>
>> In general though I don't understand what fan presence has to do with
>> the the fan source. What is the fan source anyway ? This is a non-standard
>> attribute, so you will need to explain why it is needed and what data
>> it provides in detail.
> The fan source represents the sensor number which actually defines the fan-speed.
> And the present or not present check is just to show another value if not present.
> Which will be unnecessary when the module uses is_visible.
>
>>> +SENSOR_DEVICE_ATTR(overall_uptime, S_IRUGO, show_overall_uptime, NULL, 0);
>>> +
>> I am not inclined to accept those (non-standard) attributes unless you make
>> a really good case why they are needed.
> The chip has this functionality, so I wanted to provide access to it.
> If this non-standard "export" of functionality disturbs anyone,
> I have no problem with removing it.
>
>>> +	err = watchdog_register_device(&ftsteutates_wdt);
>>> +	if (err) {
>>> +		dev_err(&client->dev,
>>> +			"Registering watchdog device failed: %d\n", err);
>>> +		goto exit_detach;
>>> +	}
>> I don't really like combining those drivers. There should really be a means
>> (other than mfd) to write two separate drivers for a chip like this.
>> I'll have to research that a bit.
> So export the watchdog part into a separate module?
> Is the i2c client forwarded to another driver if a driver which uses it was found?

An mfd driver would handle that. As I said, I'll have to research if there is an
easier way to do it.

Guenter


  reply	other threads:[~2016-06-07  3:18 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-31  8:55 [PATCH] added kernel module for FTS sensor chip "Teutates" Thilo Cestonaro
2016-06-04  5:51 ` Guenter Roeck
2016-06-06  9:21   ` thilo.cestonaro
2016-06-07  3:18     ` Guenter Roeck [this message]
2016-06-07  7:39       ` thilo.cestonaro
2016-06-07 13:30         ` Guenter Roeck
2016-06-09  9:13   ` thilo.cestonaro
2016-06-09 13:25     ` Guenter Roeck

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=57563D00.3030005@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=thilo.cestonaro@ts.fujitsu.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.