All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans de Goede <j.w.r.degoede@hhs.nl>
To: lm-sensors@vger.kernel.org
Subject: Re: [lm-sensors] [PATCH 2.6.29.3 1/1] hwmon: added support for the
Date: Tue, 19 May 2009 17:08:43 +0000	[thread overview]
Message-ID: <4A12E79B.8050908@hhs.nl> (raw)
In-Reply-To: <9EE81EBECB70824985BE0EDA8DC9B5150214E42C@VIECLEX01.frequentis.frq>

On 05/19/2009 12:45 PM, Engelmayer Christian wrote:
>> I'm not sure we should be exporting gpio functionality like this. First of
>> all the gpio function usually is fixed by how the IC is wired up, so I
> would
>> expect that to be set by the BIOS / firmware. And when not, this should be
>> set through a board configuration file, exporting this to userspace feels
> wrong.
>
> I see Your points. I also missed the actual sysfs interface definition.
> I will leave setting up the pins and the knowledge on the actual wiring
> completely to the custom firmware then.
>
>> The same can be said for toggling the pin when its an output, its function
> will
>> depend upon how its wired up again, and I would expect some higher level
> interface
>> (like an ACPI interface or whatever) expose its functionality in a more
> sane way.
>
> For the usecase that drives me, I would nevertheless need userspace
> to be able to check whether an alarm condition exists. Having firmware
> set up the gpio usage and enabled the adapted alarm conditions one
> could combine the various alarm sources provided by the chip (min/max
> output, tach overflow, gpio related) into alarm file 'fan1_alarm' as
> already specified in the hwmon sysfs-interface standard.
>
> Would that be an acceptable extension?
>

Extending the supported alarms would be fine, although I would not aggregate
them all under one sysfs file, just make a gpio#_alarm sysfs file, and make the
presence of this file conditional on the configuration of the gpio pins.

Would that work for you ?

Regards,

Hans

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

  parent reply	other threads:[~2009-05-19 17:08 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-19  8:39 [lm-sensors] [PATCH 2.6.29.3 1/1] hwmon: added support for the Engelmayer Christian
2009-05-19  9:11 ` Hans de Goede
2009-05-19 10:45 ` Engelmayer Christian
2009-05-19 17:08 ` Hans de Goede [this message]
2009-05-19 20:52 ` Christian Engelmayer
2009-05-19 21:11 ` Jean Delvare
2009-05-20 10:52 ` Engelmayer Christian
2009-05-20 18:31 ` Hans de Goede

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=4A12E79B.8050908@hhs.nl \
    --to=j.w.r.degoede@hhs.nl \
    --cc=lm-sensors@vger.kernel.org \
    /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.