From: Guenter Roeck <linux@roeck-us.net>
To: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
"David S. Miller" <davem@davemloft.net>,
Florian Fainelli <f.fainelli@gmail.com>,
kernel@savoirfairelinux.com
Subject: Re: [PATCH 2/2] net: dsa: register hwmon for any provided function
Date: Thu, 16 Apr 2015 19:17:36 -0700 [thread overview]
Message-ID: <55306D40.1060604@roeck-us.net> (raw)
In-Reply-To: <973411308.896485.1429221939679.JavaMail.zimbra@savoirfairelinux.com>
hi Vivien,
On 04/16/2015 03:05 PM, Vivien Didelot wrote:
> Hi Guenter,
>
>>> switch (index) {
>>> + case 0: /* temp1_input */
>>> + if (drv->get_temp)
>>> + mode |= S_IRUGO;
>>
>> This should be mandatory. Sorry, I don't really understand what you are
>> trying to accomplish here.
>>
>> Can you give me a real world example where a chip would support setting
>> a limit but not reading it ?
>
> I have no such example. I just did not see why this couldn't be allowed
> (e.g. setting only set_temp_limit and get_temp_alarm looks fine to me).
> But if you say that get_temp should be mandatory, I'm OK with that.
>
write-only attributes are not defined in the hwmon ABI. If the 'sensors'
command encounters such an attribute, it will create an error message
each time it executes. That doesn't sound very useful to me.
If a chip - for whatever reason - does not have a limit register
but an alarm register or flag, its temperature limit is usually hard-coded
and can be reported this way (the AMD temperature sensor driver does this,
for example). If there is ever a need to support the alarm-register-only
situation for some odd reason, we can add the code at the time.
For now, it just seems to me that you are adding complexity to solve
some theoretic problem which is very unlikely to occur in the real world.
> The primary goal of this patchset was to use DEVICE_ATTR_RW to declare
> temp1_max, instead of reflecting the minimal permissions needed.
>
Then why don't you just do that and nothing else ? The goal should be
to simplify code, not to make it more complicated. If the result isn't
less code, I don't think it is worth it.
Thanks,
Guenter
next prev parent reply other threads:[~2015-04-17 2:18 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-16 18:38 [PATCH 1/2] net: dsa: use DEVICE_ATTR_RW to declare temp1_max Vivien Didelot
2015-04-16 18:38 ` [PATCH 2/2] net: dsa: register hwmon for any provided function Vivien Didelot
2015-04-16 21:26 ` Guenter Roeck
2015-04-16 22:05 ` Vivien Didelot
2015-04-17 2:17 ` Guenter Roeck [this message]
2015-04-17 14:45 ` Vivien Didelot
2015-04-16 18:55 ` [PATCH 1/2] net: dsa: use DEVICE_ATTR_RW to declare temp1_max Sergei Shtylyov
2015-04-16 19:13 ` Vivien Didelot
2015-04-16 21:24 ` 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=55306D40.1060604@roeck-us.net \
--to=linux@roeck-us.net \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=kernel@savoirfairelinux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=vivien.didelot@savoirfairelinux.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).