From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 112C5C10F11 for ; Wed, 24 Apr 2019 12:32:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D21D820811 for ; Wed, 24 Apr 2019 12:32:40 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=lunn.ch header.i=@lunn.ch header.b="xGGUgqYW" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730085AbfDXMcj (ORCPT ); Wed, 24 Apr 2019 08:32:39 -0400 Received: from vps0.lunn.ch ([185.16.172.187]:42571 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729750AbfDXMcj (ORCPT ); Wed, 24 Apr 2019 08:32:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=G6oLoFd/FQdsKh3RwBy82Aq4TQDWSEUuRpOALIl3tTc=; b=xGGUgqYWj+LyxpGv9YkaZe11tO 26oOGpnQJo76QchGaX+rsRQBOm+UFVRGrPCtU3+F9/sp3JzxvgAckCcA5EdNVpPZXrLbBNqEMbuQx xw/RYCdoZgfzGWeuwbeVdvq4rJw0EHBBJ5CrQ6sHG/7/bwosCk0B86qpXgeopET5kA/U=; Received: from andrew by vps0.lunn.ch with local (Exim 4.89) (envelope-from ) id 1hJH4j-000891-UY; Wed, 24 Apr 2019 14:32:33 +0200 Date: Wed, 24 Apr 2019 14:32:33 +0200 From: Andrew Lunn To: Igor Russkikh Cc: "David S . Miller" , "netdev@vger.kernel.org" , Nikita Danilov , Dmitry Bogdanov , Yana Esina Subject: Re: [PATCH v2 net-next 02/16] net: aquantia: implement hwmon api for chip temperature Message-ID: <20190424123233.GF3371@lunn.ch> References: <869d56f1adaa7c16f067bfe4b2e8cd780a29beaf.1556024424.git.igor.russkikh@aquantia.com> <20190423191758.GL28405@lunn.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Wed, Apr 24, 2019 at 08:28:46AM +0000, Igor Russkikh wrote: > > >> +static u32 aq_hwmon_temp_config[] = { > >> + HWMON_T_INPUT | HWMON_T_LABEL, > >> + 0, > > > > It would be nice to also have > > > > HWMON_T_MAX | HWMON_T_MIN | > > HWMON_T_CRIT | HWMON_T_LCRIT | > > > > which the PHY probably has. > > > > At gives some degree of context. A temperature on its own of say 65C > > is hard to interpret. Is it too hot? But if we have a critical of 85C > > and a max of 95C we know we are O.K. > > I can give here only suggested constants, since we don't have now any interface > on reading/configuring these. Hi Igor You mean your firmware is blocking you from accessing these PHY registers? > Do you think that will be ok? I think the HWMON maintainer prefers they come from the hardware. You are also going to get odd results, when the provisioning data for the PHY is different to what you hard code in the driver. The PHY shuts down to protect itself, but your hard coded values indicate everything should be O.K. I would suggest you stick with the current patch, until you can add more features to the firmware to allow access to these registers. Andrew