Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp2014344ybl; Thu, 5 Dec 2019 10:30:58 -0800 (PST) X-Google-Smtp-Source: APXvYqyAkcY1pEZ9Q11xppxLTsr7KTMGA0JlUSe0rBhx/QHqoAUVAA27Y+m2K5TOI0ONER3HQbOK X-Received: by 2002:a05:6830:574:: with SMTP id f20mr7434974otc.71.1575570658836; Thu, 05 Dec 2019 10:30:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1575570658; cv=none; d=google.com; s=arc-20160816; b=cDyLHSif2g5CI5cIWGacbIUg1hj5AGE5KLdI71UEUUk3BnVUheDY2aHtmsSxKnKnct WMLcVWbqCO2O1SR+OZOHsaLWR4e3cMtG/P8Hm1e6k44fmOk7kcJZpgydG/6wKadMlfKy A3zxuVMEG90VpVsWf/FLHDiDtXeGZy0Ai8JgMDFzIMUj0nm6fKOPbbilUWTB3IvZpijO Q6e1CS9ybz4NnfSQmLC5mqvmlInOeKoUs6H9TnocpaweB/HyJ44H/beF16GKMeR8llue gqtyYbj41+5M0vBj0Ky/hfI44KZkO+QNLD+dr2tGIWx6OGQlaRFPQhaUoCMwf6u8isrO XX9Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=v3NQcCPsP0bJ95sTntzYETVlSN8qK0QpdSTn30GBR8Y=; b=EHXXEiNnCkjPf3vanPjmsvLmDtLVWO6NCwMKE2U0rLmXX2BOnL/cOeakzQERTxQcIw HYieNDUzcUmaEznxegkl+mXgWMYfvyp4DDmUl8yBUDeGwk0nmCojbBmcfnjaBsd/KmjJ qm0NmsFYsDuDbm/9K3ts8CDx4hJB8deHlVdqF4zzkNmqwzO1SiL+OkSMLGLgaaZhh11Q 5WlZTMy19VSCTzOi0fn2bfBd71AY74XdcWtNfF5BWlvcluf/BWXm3X8NgHzXQ1nYoFjy 90l+ESR3NUphYHH1bAo+6o8NftaNQzfcjPrhjfz6rcCS5dU27okH0XTOE6JC1ZMS3Y6v Ryrw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=jv3ZvTVd; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k23si5408258oic.205.2019.12.05.10.30.46; Thu, 05 Dec 2019 10:30:58 -0800 (PST) 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; dkim=pass header.i=@kernel.org header.s=default header.b=jv3ZvTVd; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730271AbfLERuu (ORCPT + 99 others); Thu, 5 Dec 2019 12:50:50 -0500 Received: from mail.kernel.org ([198.145.29.99]:48688 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730003AbfLERuu (ORCPT ); Thu, 5 Dec 2019 12:50:50 -0500 Received: from mail-qv1-f45.google.com (mail-qv1-f45.google.com [209.85.219.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 338D7224F8; Thu, 5 Dec 2019 17:50:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1575568249; bh=IEqN5jALA/tA1YwYPL5ex66SSXu8AQtHWEUKdGhqRN4=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=jv3ZvTVd98uAIGB6m+6El9AuZjrji4nvWOsrKMNDD8TiCO5nT87xnA3Yf1QeziTxN lk5rB0wL3h59uQ5dhlTyHfKZ30ogmZebK3SrY2JPBgIediOyDtZPGo0FWQSZ4cDplx RsASs/RLUC1ViKTYH7YovnPzW8ckzMXRL5RuTDgg= Received: by mail-qv1-f45.google.com with SMTP id y8so1605386qvk.6; Thu, 05 Dec 2019 09:50:49 -0800 (PST) X-Gm-Message-State: APjAAAXlNAYAE925RqL7cD/HeD+VNLzuIa1l++epG0vzSmkFKNgiQSia bLB/omhMpO0MW6LJl4Hk5G94dZu0sXGwZH+Cfg== X-Received: by 2002:ad4:450a:: with SMTP id k10mr8183566qvu.136.1575568248163; Thu, 05 Dec 2019 09:50:48 -0800 (PST) MIME-Version: 1.0 References: <3da2492c244962c27b21aad87bfa6bf74f568f1d.1575376664.git-series.andrew@aj.id.au> <40d554c0-de62-4d45-bbcc-dd3a3aa12a65@www.fastmail.com> In-Reply-To: <40d554c0-de62-4d45-bbcc-dd3a3aa12a65@www.fastmail.com> From: Rob Herring Date: Thu, 5 Dec 2019 11:50:36 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/3] dt-bindings: ipmi: aspeed: Introduce a v2 binding for KCS To: Andrew Jeffery Cc: openipmi-developer@lists.sourceforge.net, Corey Minyard , Mark Rutland , Joel Stanley , Arnd Bergmann , Greg Kroah-Hartman , devicetree@vger.kernel.org, "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , linux-aspeed@lists.ozlabs.org, "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Dec 4, 2019 at 11:12 PM Andrew Jeffery wrote: > > > > On Wed, 4 Dec 2019, at 01:01, Rob Herring wrote: > > On Tue, Dec 3, 2019 at 6:36 AM Andrew Jeffery wrote: > > > > > > The v2 binding utilises reg and renames some of the v1 properties. > > > > > > Signed-off-by: Andrew Jeffery > > > --- > > > Documentation/devicetree/bindings/ipmi/aspeed-kcs-bmc.txt | 20 +++++--- > > > 1 file changed, 14 insertions(+), 6 deletions(-) > > > > > > diff --git a/Documentation/devicetree/bindings/ipmi/aspeed-kcs-bmc.txt b/Documentation/devicetree/bindings/ipmi/aspeed-kcs-bmc.txt > > > index d98a9bf45d6c..76b180ebbde4 100644 > > > --- a/Documentation/devicetree/bindings/ipmi/aspeed-kcs-bmc.txt > > > +++ b/Documentation/devicetree/bindings/ipmi/aspeed-kcs-bmc.txt > > > @@ -1,9 +1,10 @@ > > > -* Aspeed KCS (Keyboard Controller Style) IPMI interface > > > +# Aspeed KCS (Keyboard Controller Style) IPMI interface > > > > > > The Aspeed SOCs (AST2400 and AST2500) are commonly used as BMCs > > > (Baseboard Management Controllers) and the KCS interface can be > > > used to perform in-band IPMI communication with their host. > > > > > > +## v1 > > > Required properties: > > > - compatible : should be one of > > > "aspeed,ast2400-kcs-bmc" > > > @@ -12,14 +13,21 @@ Required properties: > > > - kcs_chan : The LPC channel number in the controller > > > - kcs_addr : The host CPU IO map address > > > > > > +## v2 > > > +Required properties: > > > +- compatible : should be one of > > > + "aspeed,ast2400-kcs-bmc-v2" > > > + "aspeed,ast2500-kcs-bmc-v2" > > > +- reg : The address and size of the IDR, ODR and STR registers > > > +- interrupts : interrupt generated by the controller > > > +- slave-reg : The host CPU IO map address > > > > aspeed,slave-reg > > I don't agree, as it's not an aspeed-specific behaviour. This property > controls where the device appears in the host's LPC IO address space, > which is a common problem for any LPC IO device exposed by the BMC > to the host. Then document it as such. Common properties go into common binding documents. > > > Example: > > > > > > - kcs3: kcs3@0 { > > > - compatible = "aspeed,ast2500-kcs-bmc"; > > > - reg = <0x0 0x80>; > > > + kcs3: kcs@24 { > > > + compatible = "aspeed,ast2500-kcs-bmc-v2"; > > > + reg = <0x24 0x1>, <0x30 0x1>, <0x3c 0x1>; > > > > What are the other registers in this address space? I'm not so sure > > this is an improvement if you end up with a bunch of nodes with single > > registers. > > Put into practice the bindings give the following patch: on the AST2500: Okay, that's an unfortunate interleaving, but seems fine. > > diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi b/arch/arm/boot/dts/aspeed-g5.dtsi > index e8feb8b66a2f..5d51f469cbf0 100644 > --- a/arch/arm/boot/dts/aspeed-g5.dtsi > +++ b/arch/arm/boot/dts/aspeed-g5.dtsi > @@ -399,22 +399,22 @@ > #size-cells = <1>; > ranges = <0x0 0x0 0x80>; > > - kcs1: kcs1@0 { > - compatible = "aspeed,ast2500-kcs-bmc"; > + kcs1: kcs@24 { > + compatible = "aspeed,ast2500-kcs-bmc-v2"; > + reg = <0x24 0x1>, <0x30 0x1>, <0x3c 0x1>; > interrupts = <8>; > - kcs_chan = <1>; > status = "disabled"; > }; > - kcs2: kcs2@0 { > - compatible = "aspeed,ast2500-kcs-bmc"; > + kcs2: kcs@28 { > + compatible = "aspeed,ast2500-kcs-bmc-v2"; > + reg = <0x28 0x1>, <0x34 0x1>, <0x40 0x1>; > interrupts = <8>; > - kcs_chan = <2>; > status = "disabled"; > }; > - kcs3: kcs3@0 { > - compatible = "aspeed,ast2500-kcs-bmc"; > + kcs3: kcs@2c { > + compatible = "aspeed,ast2500-kcs-bmc-v2"; > + reg = <0x2c 0x1>, <0x38 0x1>, <0x44 0x1>; > interrupts = <8>; > - kcs_chan = <3>; > status = "disabled"; > }; > }; > @@ -428,10 +428,10 @@ > #size-cells = <1>; > ranges = <0x0 0x80 0x1e0>; > > - kcs4: kcs4@0 { > - compatible = "aspeed,ast2500-kcs-bmc"; > + kcs4: kcs@94 { > + compatible = "aspeed,ast2500-kcs-bmc-v2"; > + reg = <0x94 0x1>, <0x98 0x1>, <0x9c 0x1>; > interrupts = <8>; > - kcs_chan = <4>; > status = "disabled"; > }; > > The aim is to fix these warnings which appear for every aspeed-based devicetree: > > arch/arm/boot/dts/aspeed-g5.dtsi:376.19-381.8: Warning (unit_address_vs_reg): /ahb/apb/lpc@1e789000/lpc-bmc@0/kcs1@0: node has a unit name, but no reg property > arch/arm/boot/dts/aspeed-g5.dtsi:382.19-387.8: Warning (unit_address_vs_reg): /ahb/apb/lpc@1e789000/lpc-bmc@0/kcs2@0: node has a unit name, but no reg property > arch/arm/boot/dts/aspeed-g5.dtsi:388.19-393.8: Warning (unit_address_vs_reg): /ahb/apb/lpc@1e789000/lpc-bmc@0/kcs3@0: node has a unit name, but no reg property > arch/arm/boot/dts/aspeed-g5.dtsi:405.19-410.8: Warning (unit_address_vs_reg): /ahb/apb/lpc@1e789000/lpc-host@80/kcs4@0: node has a unit name, but no reg property > arch/arm/boot/dts/aspeed-g5.dtsi:376.19-381.8: Warning (unique_unit_address): /ahb/apb/lpc@1e789000/lpc-bmc@0/kcs1@0: duplicate unit-address (also used in node /ahb/apb/lpc@1e789000/lpc-bmc@0/kcs2@0) > arch/arm/boot/dts/aspeed-g5.dtsi:376.19-381.8: Warning (unique_unit_address): /ahb/apb/lpc@1e789000/lpc-bmc@0/kcs1@0: duplicate unit-address (also used in node /ahb/apb/lpc@1e789000/lpc-bmc@0/kcs3@0) > arch/arm/boot/dts/aspeed-g5.dtsi:382.19-387.8: Warning (unique_unit_address): /ahb/apb/lpc@1e789000/lpc-bmc@0/kcs2@0: duplicate unit-address (also used in node /ahb/apb/lpc@1e789000/lpc-bmc@0/kcs3@0) > arch/arm/boot/dts/aspeed-g5.dtsi:405.19-410.8: Warning (unique_unit_address): /ahb/apb/lpc@1e789000/lpc-host@80/kcs4@0: duplicate unit-address (also used in node /ahb/apb/lpc@1e789000/lpc-host@80/lpc-ctrl@0) > > Andrew