Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp1264860imm; Wed, 23 May 2018 13:04:36 -0700 (PDT) X-Google-Smtp-Source: AB8JxZoEVEAyAlCnr0qK1HByPlZysooS4wW7EJVUMgHsWAyztCUTPYE2LuJe/ED/xl0QUN7np7dz X-Received: by 2002:a65:6310:: with SMTP id g16-v6mr3384343pgv.135.1527105876768; Wed, 23 May 2018 13:04:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527105876; cv=none; d=google.com; s=arc-20160816; b=spmcOR3Yf5nrX0PEMBzEFgwtbGWSNHuJEakn92XxzSwkOrq4Mjkd8q9HCmuhjy69Xi Gw4e7LtVZyHIzaMjIO4RHhxESPDJ9YxN97z3B4bWH+Qq+BHOCM5J/goIEHGavozdZtbK apXe+/MPsvZp93RUkVpfbkTO2mK3dO7d2l1T/9l34c1UE+sIcM+vWug5vXw2fI8cX9ce VGBvlbWeAbzyVdrGLugJxWKUMWOg5iJDQq2qpCFjXvT2xLBgRkpY0f4Oip0CxBhV8/Kt l0Y8tOF76TDxCs39dBrhZ/005qEM75vM8Yo2TRABpGiklmvUmjAXCI+jgvP+fLQc11OV 4YwQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=iGnh43DVnCu9S8xglytAfB9Yxue3Q8Wtd7gHweTcxJs=; b=d9Db12v9G8j+7Ts8DLOuEcZpjhstJ8r4/btIcG/NMGz+o3dCFnF2HU1dJkrM5ae1Vi 1eDnEr9JKvY9kb7QWTuZLsuzpfNVZw6d3B1fdZKCCPdnSu0X3l/VLB57Af5QSqkDg37L QrVlKfQJHAQ8BOAYzF07L5s8peE/AD2E+eK7MGibJzzWidiVKhYg/w6PXhqG0cUJGSw/ dk6Dw7JlAWIhUcQfXOjCaC3KRw4XMaEcRBzbhv89bvGJF8fWMqhWVwk9z9SV8ipd5TXj GasYRBcfXFjl41g58tslE8H2ymj7aV9zb2bjGIZ0Eyc3XYd0nhFHCGjawButD4paMoe6 DrjA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b18-v6si19544146pfi.254.2018.05.23.13.04.20; Wed, 23 May 2018 13:04:36 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934612AbeEWUDF (ORCPT + 99 others); Wed, 23 May 2018 16:03:05 -0400 Received: from mga12.intel.com ([192.55.52.136]:15425 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933737AbeEWUDD (ORCPT ); Wed, 23 May 2018 16:03:03 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 May 2018 13:03:03 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,434,1520924400"; d="scan'208";a="43387454" Received: from yoojae-mobl1.amr.corp.intel.com (HELO [10.7.153.151]) ([10.7.153.151]) by orsmga007.jf.intel.com with ESMTP; 23 May 2018 13:03:02 -0700 Subject: Re: [v4 07/11] dt-bindings: hwmon: Add documents for PECI hwmon client drivers To: Rob Herring Cc: Mark Rutland , Haiyue Wang , Vernon Mauery , James Feist , devicetree@vger.kernel.org, "linux-kernel@vger.kernel.org" , Andrew Jeffery , Arnd Bergmann , Jason M Biils , Joel Stanley References: <20180521195905.27983-1-jae.hyun.yoo@linux.intel.com> <20180522164230.GA11707@rob-hp-laptop> <51752610-d2c1-7fbc-101e-e99346fa29e4@linux.intel.com> From: Jae Hyun Yoo Message-ID: <22bd0e23-69ad-5858-656e-16c77007913c@linux.intel.com> Date: Wed, 23 May 2018 13:03:02 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 5/23/2018 12:33 PM, Rob Herring wrote: > On Wed, May 23, 2018 at 11:37 AM, Jae Hyun Yoo > wrote: >> On 5/23/2018 8:11 AM, Rob Herring wrote: >>> >>> On Tue, May 22, 2018 at 12:18 PM, Jae Hyun Yoo >>> wrote: >>>> >>>> On 5/22/2018 9:42 AM, Rob Herring wrote: >>>>> >>>>> >>>>> On Mon, May 21, 2018 at 12:59:05PM -0700, Jae Hyun Yoo wrote: >>>>>> >>>>>> >>>>>> This commit adds dt-bindings documents for PECI hwmon client drivers. >>>>>> >>>>>> Signed-off-by: Jae Hyun Yoo >>>>>> Reviewed-by: Haiyue Wang >>>>>> Reviewed-by: James Feist >>>>>> Reviewed-by: Vernon Mauery >>>>>> Cc: Andrew Jeffery >>>>>> Cc: Arnd Bergmann >>>>>> Cc: Jason M Biils >>>>>> Cc: Joel Stanley >>>>>> --- >>>>>> .../bindings/hwmon/peci-cputemp.txt | 23 >>>>>> ++++++++++++++++++ >>>>>> .../bindings/hwmon/peci-dimmtemp.txt | 24 >>>>>> +++++++++++++++++++ >>>>>> 2 files changed, 47 insertions(+) >>>>>> create mode 100644 >>>>>> Documentation/devicetree/bindings/hwmon/peci-cputemp.txt >>>>>> create mode 100644 >>>>>> Documentation/devicetree/bindings/hwmon/peci-dimmtemp.txt >>>>>> >>>>>> diff --git a/Documentation/devicetree/bindings/hwmon/peci-cputemp.txt >>>>>> b/Documentation/devicetree/bindings/hwmon/peci-cputemp.txt >>>>>> new file mode 100644 >>>>>> index 000000000000..2f59aee12d9e >>>>>> --- /dev/null >>>>>> +++ b/Documentation/devicetree/bindings/hwmon/peci-cputemp.txt >>>>>> @@ -0,0 +1,23 @@ >>>>>> +Bindings for Intel PECI (Platform Environment Control Interface) >>>>>> cputemp >>>>>> driver. >>>>>> + >>>>>> +Required properties: >>>>>> +- compatible : Should be "intel,peci-cputemp". >>>>>> +- reg : Should contain address of a client CPU. Address range >>>>>> of >>>>>> CPU >>>>>> + clients is starting from 0x30 based on PECI >>>>>> specification. >>>>>> + >>>>>> +Example: >>>>>> + peci-bus@0 { >>>>>> + #address-cells = <1>; >>>>>> + #size-cells = <0>; >>>>>> + < more properties > >>>>>> + >>>>>> + peci-cputemp@30 { >>>>>> + compatible = "intel,peci-cputemp"; >>>>>> + reg = <0x30>; >>>>>> + }; >>>>> >>>>> >>>>> >>>>> [...] >>>>> >>>>>> + peci-dimmtemp@30 { >>>>>> + compatible = "intel,peci-dimmtemp"; >>>>>> + reg = <0x30>; >>>>>> + }; >>>>> >>>>> >>>>> >>>>> As I said in the prior version, 2 nodes at the same address is wrong. >>>>> >>>>> Rob >>>>> >>>> >>>> In PECI bus, there is one and only bus host (adapter) and multiple >>>> clients on a PECI bus, and PECI spec doesn't allow multiple originators >>>> so only the host device can originate message. >>> >>> >>> Yes, I get that. A single host still has to address slave devices. >>> >>>> In this implementation, >>>> all message transactions on a bus from client driver modules and user >>>> space will be serialized well in the PECI core bus driver so bus >>>> occupation and traffic arbitration will be managed well in the PECI core >>>> bus driver even in case of a bus has 2 client drivers at the same >>>> address. I'm sure that this implementation doesn't make that kind of >>>> problem to OS. >>> >>> >>> Multiple clients to a single device is common, but that is a software >>> problem and doesn't belong in DT. >>> >>> I don't think there is a single other case in the kernel where >>> multiple drivers can bind to the same device at a given bus address. >>> That is why we have things like MFD. Though in this case, why can't >>> one hwmon driver register multiple hwmon devices (cpu and dimm temps)? >>> >> >> It was implemented as a single driver until v2 but dimm temps need >> delayed creation unlikely the cpu temps on hwmon subsystem because of >> memory training behavior of remote x86 cpus. Since hwmon doesn't allow >> incremental creation, I had to divide it into two, cputemp and dimmtemp, >> so that cputemp can be registered immediately when the remote x86 cpu >> turns on and dimmtemp can be registered by delayed creation. It is the >> reason why I had to make the two hwmon driver modules that sharing a >> single device address. > > That all sounds like kernel problems to me. Stop designing your DT > binding around what the kernel can or can't *currently* support. > >> Additionally, PECI isn't limited for temperature >> monitoring feature but it can be used for other functions such as >> platform management, cpu interface tuning and diagnostics and failure >> analysis, so in case of adding a new driver for the functions, we should >> add an another DT node which is sharing the same cpu address. > > No, the driver should add support for those additional functions. > Perhaps you will need to use MFD. > Do you mean that the device address sharing is acceptable if I make these nodes under "simple-mfd"? Thanks, -Jae