Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758748AbdDSAPx (ORCPT ); Tue, 18 Apr 2017 20:15:53 -0400 Received: from mail-ua0-f194.google.com ([209.85.217.194]:34772 "EHLO mail-ua0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758732AbdDSAPs (ORCPT ); Tue, 18 Apr 2017 20:15:48 -0400 MIME-Version: 1.0 In-Reply-To: <20170418224739.GA24376@roeck-us.net> References: <20170418201702.57019-1-code@mmayer.net> <20170418201702.57019-3-code@mmayer.net> <20170418205839.GA3554@roeck-us.net> <20170418224739.GA24376@roeck-us.net> From: Markus Mayer Date: Tue, 18 Apr 2017 17:15:47 -0700 X-Google-Sender-Auth: CprBB5bRsCwo72JLukx3jdHBa1I Message-ID: Subject: Re: [PATCH 2/2] hwmon: (brcmstb) Add driver for Broadcom STB DPFE To: Guenter Roeck Cc: Florian Fainelli , Markus Mayer , Jean Delvare , Rob Herring , Mark Rutland , Markus Mayer , Broadcom Kernel List , Linux HWMON List , Device Tree List , ARM Kernel List , Linux Kernel Mailing List Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2321 Lines: 60 On 18 April 2017 at 15:47, Guenter Roeck wrote: > Hi Florian, > > On Tue, Apr 18, 2017 at 03:29:55PM -0700, Florian Fainelli wrote: >> Hey Guenter, >> >> On 04/18/2017 01:58 PM, Guenter Roeck wrote: >> > Hi Markus, >> > >> > On Tue, Apr 18, 2017 at 01:17:02PM -0700, Markus Mayer wrote: >> >> From: Markus Mayer >> >> >> >> This driver allows access to DRAM properties, such as the refresh rate, >> >> via the Broadcom STB DDR PHY Front End (DPFE). The refresh rate can be >> >> used as indirect indicator of the DRAM temperature. >> >> >> >> The driver also allows setting of the sampling interval. >> >> >> >> Signed-off-by: Markus Mayer >> >> --- >> > [ ... ] >> > >> >> + >> >> +static SENSOR_DEVICE_ATTR(dpfe_info, 0444, show_info, NULL, 1000); >> >> +static SENSOR_DEVICE_ATTR(dpfe_refresh, 0644, show_refresh, store_refresh, >> >> + 1000); >> >> +static SENSOR_DEVICE_ATTR(dpfe_vendor, 0444, show_vendor, NULL, 1000); >> >> +static struct attribute *dpfe_attrs[] = { >> >> + &sensor_dev_attr_dpfe_info.dev_attr.attr, >> >> + &sensor_dev_attr_dpfe_refresh.dev_attr.attr, >> >> + &sensor_dev_attr_dpfe_vendor.dev_attr.attr, >> >> + NULL >> >> +}; >> >> +ATTRIBUTE_GROUPS(dpfe); >> >> + >> > >> > There is not a single standard hwmon attribute. I don't know how >> > to classify this driver, and where it should reside, but it is not >> > a hwmon driver. >> >> This is a driver that talks to an embedded CPU running firmware which is >> capable of giving various informations about the DRAM chip being >> populated, including a temperature trend (hotter or cooler). We thought >> initially we would be able to expose the actual temperature, but this in >> turn required a lot more knowledge about the DRAM chip that we wish we >> knew about. That is sort of where and why this driver was proposed for >> hwmon. >> >> Which subsystem do you think would be best for this driver drivers/misc/ >> or drivers/soc/bcm/brcmstb/ maybe? > > Both should work. I would probably try misc first and let Greg tell me > which way to go ;-). Thanks for the tip. As Florian said, it was not the idea to submit a completely non-standard hwmon driver. I was sure I would be able to report at least some standard hwmon data also. Regards, -Markus