Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp2941578imm; Thu, 24 May 2018 19:32:37 -0700 (PDT) X-Google-Smtp-Source: AB8JxZr7Pj0rcHT8iiUc5frj1pKiLT0aW+TKe9IQdc5zTzvFpVgT3kNa1x8TzTXTLieAUaRIzdSW X-Received: by 2002:a17:902:7209:: with SMTP id ba9-v6mr587385plb.119.1527215557633; Thu, 24 May 2018 19:32:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527215557; cv=none; d=google.com; s=arc-20160816; b=jEdXRBkNpExX85wMLwTHoqHlpOFkHM6jwpF2AAm1Ldm1SRM9I3p8xRcEWyK09P9k2p S1naGvGuCR/2BmvDHNWJA7KghLpHFCD7aKSM7fCCLhdWgrZlJaDFU76TXU9+OUjG5L1x guqKMn5y1yShKnF6tfRXh3UPb3GPtYc+272rHFakooWFmlNlv0QufD+t6p+saRrV42Ua btyM0UJAbQF8GAZZfaSO6j6d3uAZWEs9EXBeQvbpribFESB4mMqlYUBWLnTSn26Y9DkY iOb2RU2VFZVjpRMa5OH2KawrQPf3+1Kwq/3wzThY1S7vc9qgS2z5OywzcHxtboZbbia6 kYCw== 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=kjNC6H6p/+CrouzL9ityMqrpztwmKQOH6Di5zQk5v4w=; b=CzbDtYKCmuR3SHn25wi46pZsMa/38SZ0HDUlzLCE8crW1U8Mo3p0mUaioaomnhcjMa V+jW/Xz8vrwoAO8ro63QEhPbwsCzMeMC/q9lMKOZIlDzvWCldZPNNVl2+Z5K43tvnSPm 4wpAe/NdsXzVFklybtdAFg5/SlKwhE++8M1wB5n/kGUrBYexWSPmMxEaReBK7UD5i93g vdy7QxOXVKYs2Lw41ypRUKukgmXGdS345qSPISAqHqsqdGzbanjtLz/oeHzchJ0fFRzz OleR/XSM4barnxlHvcAR6lROhbQARDGgYaCRU+qCgVZrOpaBFMKTkcVJXPAId9dytHiL hr/Q== 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 c6-v6si22425022plo.88.2018.05.24.19.32.23; Thu, 24 May 2018 19:32:37 -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 S1034139AbeEXRJb (ORCPT + 99 others); Thu, 24 May 2018 13:09:31 -0400 Received: from mga05.intel.com ([192.55.52.43]:61100 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1034127AbeEXRJ1 (ORCPT ); Thu, 24 May 2018 13:09:27 -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 fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 May 2018 10:09:26 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,436,1520924400"; d="scan'208";a="43655546" Received: from yoojae-mobl1.amr.corp.intel.com (HELO [10.7.153.151]) ([10.7.153.151]) by orsmga007.jf.intel.com with ESMTP; 24 May 2018 10:09:25 -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> <22bd0e23-69ad-5858-656e-16c77007913c@linux.intel.com> <8b56c103-fdab-fc98-f4d8-9bf435a9b59b@linux.intel.com> From: Jae Hyun Yoo Message-ID: Date: Thu, 24 May 2018 10:09:25 -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/24/2018 6:47 AM, Rob Herring wrote: > On Wed, May 23, 2018 at 4:56 PM, Jae Hyun Yoo > wrote: >> On 5/23/2018 1:03 PM, Jae Hyun Yoo wrote: >>> >>> 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 >> >> >> Hi Rob, >> >> I'm planning to change the whole PECI node like below: >> >> peci: peci@1e78b000 { >> compatible = "simple-bus"; >> #address-cells = <1>; >> #size-cells = <1>; >> ranges = <0x0 0x1e78b000 0x60>; >> >> peci0: peci-bus@0 { >> compatible = "aspeed,ast2500-peci"; >> reg = <0x0 0x60>; >> #address-cells = <1>; >> #size-cells = <0>; >> interrupts = <15>; >> clocks = <&syscon ASPEED_CLK_GATE_REFCLK>; >> resets = <&syscon ASPEED_RESET_PECI>; >> clock-frequency = <24000000>; >> msg-timing = <1>; >> addr-timing = <1>; >> rd-sampling-point = <8>; >> cmd-timeout-ms = <1000>; >> status = "disabled"; >> >> peci-client@30 { >> compatible = "simple-mfd", "syscon"; > > These compatibles alone is not correct. There should be a specific > compatible for the device. > > Also, I don't think "syscon" even makes sense in this case. > Got it. I'll change it like: compatible = "intel,peci-client", "simple-mfd"; so that drivers could be instantiated altogether if the drivers use the "intel,peci-client" compatible string. >> reg = <0x30>; >> >> cputemp: cputemp { >> compatible = "intel,peci-cputemp"; >> }; > > There is no point in this node being in DT. It doesn't define any > resources. All it does is provide you a convenient way to bind your > driver, but that is not the purpose of DT. Put a specific compatible > in the parent and its driver can instantiate whatever child devices it > wants. > My intention is making each driver can be selectively instantiated by this node and it could use its parent reg resource which is in simple-mfd node. If the selective instantiation is not needed, drivers could use "intel,peci-client". Please correct me if it is still unacceptable. Thanks, -Jae