From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com [209.85.214.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 488A8159209 for ; Tue, 14 Jan 2025 16:46:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.181 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736873171; cv=none; b=S0jKpEiH1pC8+fiCj3cVN+Skw15FS1XHH4Vb431JwFwgNoHNTcFlsdkUfLTvi8qcJ7cPqfJp7GSfOMgqVroWkltpENsQhEuL+6m9dBg1n502JZWXEOnaITgvWrvyxGQQXb/EhTV4P8AgCc3JFJTkroK2WhK5opIWWxrEkGLOKB8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736873171; c=relaxed/simple; bh=FeGRHC4opBjeYP+NykQJ9KuRA1EzhXTFeXezxUccur4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=mnum2XJkxHNe45fa2TMQA45MBwsUv7W/CkF35+OfeciIMSfFJF9AQ9GWkchNnSV0qZVYV+Y2uHPIsQASNuQ9IUUV2eCH20+4P+tICoNlLOBB3QPbvWOGKFO/BNzBYzQSd/u1LG2tFyPR2PVLiPdBGMVxiz9eUqjMkuN6fSypgdU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=minyard.net; spf=none smtp.mailfrom=minyard.net; dkim=pass (2048-bit key) header.d=minyard-net.20230601.gappssmtp.com header.i=@minyard-net.20230601.gappssmtp.com header.b=uCA7NPIO; arc=none smtp.client-ip=209.85.214.181 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=minyard.net Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=minyard.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=minyard-net.20230601.gappssmtp.com header.i=@minyard-net.20230601.gappssmtp.com header.b="uCA7NPIO" Received: by mail-pl1-f181.google.com with SMTP id d9443c01a7336-2166022c5caso90055745ad.2 for ; Tue, 14 Jan 2025 08:46:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=minyard-net.20230601.gappssmtp.com; s=20230601; t=1736873169; x=1737477969; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=RxWYotfxywN3NwGBQO3BiIkoRPcGTpIVsh2/TXME74Q=; b=uCA7NPIOcbXCFnA8+H16dcqnyoaP3hU3Ya+s4nJbEZLKwRAy0nKoWWaNYhC0/TIh57 HPDOI71FtcZGwliRegj+fQBm6jhGRcQqKD8qFhIY3s7rJYexWE+a56cDrSTvc83Kkz5T k8hid0dHLR4WxNJ7IsredvG2eKsHqhJe+ltwLxfPNaZArLPvhoSNPDPDPeWKoU1eJZRW DIlXBC9e6J+OQ5Sk+bIS/YnUZcUcCsSb+WHdQe0Etrar8PaEFd6/Wx0UqUotf9YM1Ks8 6eU9mVLUqjBdF1OeP8QsFwDIRCpbmWpcOxu5YXBDVcMaNR4XFO4kxr/kzvRkVvsXA/8B fvwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736873169; x=1737477969; h=in-reply-to:content-disposition:mime-version:references:reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=RxWYotfxywN3NwGBQO3BiIkoRPcGTpIVsh2/TXME74Q=; b=pDWfdUa2Euf33CJm4SkPalLy2a5W+JbZn8PgpRZ4a5svpVMgqfbYjr5pkPgcflMEx2 tQ0bKb7m4+nu4v7f+kY1XcTWzIvTULjslGGKLC03A6TccUjGFQk4VbqpO+cYJc06TvJy eHthHUGVAPiHi6QiaXiK+B2F8yqPV9rCagKzg6xVHmXy7rhkaCLDDSpgumA9JKpR6qDv BxaQxjLMVfufzjsfGKjCvc5IF76hONmgbaGrgJhf3BDLMZ+uEmQj98ovYf6AcHPd9Gqq Zp9i91deY3OfTJesmW/l40VVovmqr2RzSyA3hCddtVit4hS6JZHA22j48TRErXTS0bLC rckA== X-Forwarded-Encrypted: i=1; AJvYcCXWKE+x2XPxsDlMM/w+6wm5/aymmf1vF021R90pM3Xz3OhoarcCc8jl6VsjEKZj93ZStFB1vFdeA73szxI=@vger.kernel.org X-Gm-Message-State: AOJu0Yz7K744P5KI9aT8rkTHaL5hVbryfLFITs2JQXpmVjuJhVwZ3K4v 5xUZgIgBEXwlXNLQucEfRLD/6eoGkrV4LEPse5lpaoDF8Sb2u3NgKXELZn9yR38= X-Gm-Gg: ASbGncvFkSSyPcCJ/rKtQL325zdRcxNbw5Na4ysBjOgwmCPxwolzQ15RQKIYjo/5Oe5 tmgPkTenHpaAynvC9su+goODn110lRfAZ2Dpiu9Yhe/OTcelh5PlKV3mdSA0zYbCh3eWyUuOXAF i7GdCOAZjntRBopDdDltsTkpKW81Gcfx9AJtJ6Ohtk4EoVIaiYVgBb/XD8do15ZYAdegxQA9h72 xttmZpMx0986GQ6JWYagoArYnJXqxLqYWqapcjuzMLvdfyFY3w4n8HZUwQ2 X-Google-Smtp-Source: AGHT+IFduq35RcsU3aO5RRhPDalwAW/p83/zhfkLttMULeNifRcViC7DtwI7vuIYT8rQlSliD0flaA== X-Received: by 2002:aa7:8887:0:b0:72a:bb83:7804 with SMTP id d2e1a72fcca58-72d21fd2e16mr34122515b3a.17.1736873169522; Tue, 14 Jan 2025 08:46:09 -0800 (PST) Received: from mail.minyard.net ([2001:470:b8f6:1b:4641:6dae:60a7:e5ab]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-72d4065a560sm7614353b3a.87.2025.01.14.08.46.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Jan 2025 08:46:08 -0800 (PST) Date: Tue, 14 Jan 2025 10:46:01 -0600 From: Corey Minyard To: Ninad Palsule Cc: minyard@acm.org, robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org, andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, openipmi-developer@lists.sourceforge.net, netdev@vger.kernel.org, joel@jms.id.au, andrew@codeconstruct.com.au, devicetree@vger.kernel.org, eajames@linux.ibm.com, linux-arm-kernel@lists.infradead.org, linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 2/9] bindings: ipmi: Add binding for IPMB device intf Message-ID: Reply-To: corey@minyard.net References: <20250113194822.571884-1-ninad@linux.ibm.com> <20250113194822.571884-3-ninad@linux.ibm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250113194822.571884-3-ninad@linux.ibm.com> On Mon, Jan 13, 2025 at 01:48:12PM -0600, Ninad Palsule wrote: > Add device tree binding document for the IPMB device interface. > This device is already in use in both driver and .dts files. > > Signed-off-by: Ninad Palsule > --- > .../devicetree/bindings/ipmi/ipmb-dev.yaml | 55 +++++++++++++++++++ > 1 file changed, 55 insertions(+) > create mode 100644 Documentation/devicetree/bindings/ipmi/ipmb-dev.yaml > > diff --git a/Documentation/devicetree/bindings/ipmi/ipmb-dev.yaml b/Documentation/devicetree/bindings/ipmi/ipmb-dev.yaml > new file mode 100644 > index 000000000000..136806cba632 > --- /dev/null > +++ b/Documentation/devicetree/bindings/ipmi/ipmb-dev.yaml > @@ -0,0 +1,55 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/ipmi/ipmb-dev.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: The Intelligent Platform Management Bus(IPMB) Device > + > +description: | > + The IPMB is an I2C bus which provides interconnection between Baseboard "Baseboard -> "a Baseboard" > + Management Controller(BMC) and chassis electronics. The BMC sends IPMI > + requests to intelligent controllers like Satellite Management Controller(MC) > + device via IPMB and the device sends a response back to the BMC. device -> devices "a response" -> responses > + This device binds backend Satelite MC which is a I2C slave device with the BMC You use IPMB devices on both the BMC and the MCs. The sentence above is a little confusing, too. How about: This device uses an I2C slave device to send and receive IPMB messages, either on a BMC or other MC. > + for management purpose. A miscalleneous device provices a user space program Misspelling: miscellaneous > + to communicate with kernel and backend device. Some IPMB devices only support "kernel" -> "the kernel" > + I2C protocol instead of SMB protocol. the I2C protocol and not the SMB protocol. Yes, the English language uses way too many articles... That is a lot of detail, but it looks good beyond what I've commented on. > + > + IPMB communications protocol Specification V1.0 > + https://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/ipmp-spec-v1.0.pdf > + > +maintainers: > + - Ninad Palsule > + > +properties: > + compatible: > + enum: > + - ipmb-dev > + > + reg: > + maxItems: 1 > + > + i2c-protocol: > + description: > + Use I2C block transfer instead of SMBUS block transfer. > + type: boolean > + > +required: > + - compatible > + - reg > + > +additionalProperties: false > + > +examples: > + - | > + i2c { > + #address-cells = <1>; > + #size-cells = <0>; > + > + ipmb-dev@10 { > + compatible = "ipmb-dev"; > + reg = <0x10>; I'm not sure of the conventions around device tree here, but the reg is not used in the driver and it will always be the I2C address that already in that node just one level up. It does not serve any purpose that I can see. My suggestion would be to remove it. -corey > + i2c-protocol; > + }; > + }; > -- > 2.43.0 >