Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753552AbbDQCSJ (ORCPT ); Thu, 16 Apr 2015 22:18:09 -0400 Received: from bh-25.webhostbox.net ([208.91.199.152]:34784 "EHLO bh-25.webhostbox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753225AbbDQCSA (ORCPT ); Thu, 16 Apr 2015 22:18:00 -0400 Message-ID: <55306D40.1060604@roeck-us.net> Date: Thu, 16 Apr 2015 19:17:36 -0700 From: Guenter Roeck User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Vivien Didelot CC: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, "David S. Miller" , Florian Fainelli , kernel@savoirfairelinux.com Subject: Re: [PATCH 2/2] net: dsa: register hwmon for any provided function References: <1429209499-2447-1-git-send-email-vivien.didelot@savoirfairelinux.com> <1429209499-2447-2-git-send-email-vivien.didelot@savoirfairelinux.com> <20150416212638.GB2587@roeck-us.net> <973411308.896485.1429221939679.JavaMail.zimbra@savoirfairelinux.com> In-Reply-To: <973411308.896485.1429221939679.JavaMail.zimbra@savoirfairelinux.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated_sender: linux@roeck-us.net X-OutGoing-Spam-Status: No, score=-1.0 X-CTCH-PVer: 0000001 X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-Flags: 0 X-CTCH-RefID: str=0001.0A020203.55306D57.00CD,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0 X-CTCH-Score: 0.000 X-CTCH-ScoreCust: 0.000 X-CTCH-Rules: X-CTCH-SenderID: linux@roeck-us.net X-CTCH-SenderID-Flags: 0 X-CTCH-SenderID-TotalMessages: 4 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-TotalRecipients: 0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - bh-25.webhostbox.net X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - roeck-us.net X-Get-Message-Sender-Via: bh-25.webhostbox.net: mailgid no entry from get_relayhosts_entry X-Source: X-Source-Args: X-Source-Dir: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1958 Lines: 47 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/