Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752545AbdIMP0S (ORCPT ); Wed, 13 Sep 2017 11:26:18 -0400 Received: from mail.kernel.org ([198.145.29.99]:51618 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751800AbdIMP0O (ORCPT ); Wed, 13 Sep 2017 11:26:14 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 87A7C21D28 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=robh@kernel.org X-Google-Smtp-Source: AOwi7QBnu+2X68/3o5cIzIttSgFuPxg8Ql9FzH4/RGpgLPmQpZJBL/BA4IMYw9rirTEzEwbJJG76A7gjr0gq4Kee47o= MIME-Version: 1.0 In-Reply-To: References: <20170901065818.2037-1-fe@dev.tdt.de> <20170901065818.2037-2-fe@dev.tdt.de> <20170901142622.GC599@roeck-us.net> <20170912162008.y2dp3llaikkp3l45@rob-hp-laptop> From: Rob Herring Date: Wed, 13 Sep 2017 10:25:51 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 2/2] hwmon: (ltq-cputemp) add devicetree bindings documentation To: Florian Eckert Cc: Guenter Roeck , Mark Rutland , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Linux HWMON List , Jean Delvare 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: 1426 Lines: 46 On Wed, Sep 13, 2017 at 12:36 AM, Florian Eckert wrote: > Hello Rob > >>> > --- /dev/null >>> > +++ b/Documentation/devicetree/bindings/hwmon/ltq-cputemp.txt >>> > @@ -0,0 +1,10 @@ >>> > +Lantiq cpu temperatur sensor >> >> >> s/temperatur/temperature/ > > > Will update this in a follow up page based on the old one. So no v4? > >> >>> > + >>> > +Requires node properties: >>> > +- compatible value : >>> > + "lantiq,cputemp" >> >> >> Kind of non-specific. How is this device even accessed without any other >> property? > > > It does not need any further properties. If this is set in the device tree > then the driver is loaded. DT is not the only way to instantiate drivers. What I meant is how do you access the hardware? That should be evident from the binding and it is not. Looking at the driver, you have some memory mapped system control registers which get ioremapped in arch/mips/lantiq/xway/sysctrl.c and accesses thru some platform specific macros. That is not the ideal way to do things as we use syscon and regmap for such things. But that's all mostly kernel details not so relevant to the DT binding. For DT, I'd expect this is a child node of the sysctrl block with a reg property value of <0x40 4> (along with any other child devices). You could also not even put this in DT and the system controller can have it's own driver that instantiates the child device for this driver. Rob