[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20211005004019.2670691-5-minyard@acm.org>
Date: Mon, 4 Oct 2021 19:40:18 -0500
From: minyard@....org
To: openipmi-developer@...ts.sourceforge.net
Cc: Andrew Manley <andrew.manley@...lingtech.com>,
linux-kernel@...r.kernel.org, Corey Minyard <cminyard@...sta.com>,
Corey Minyard <minyard@....org>
Subject: [PATCH 4/5] ipmi: Add docs for IPMB direct addressing
From: Corey Minyard <cminyard@...sta.com>
Describe the addressing mechanism and how to use it.
Signed-off-by: Corey Minyard <minyard@....org>
Tested-by: Andrew Manley <andrew.manley@...lingtech.com>
Reviewed-by: Andrew Manley <andrew.manley@...lingtech.com>
---
Documentation/driver-api/ipmi.rst | 25 +++++++++++++++++++++++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/Documentation/driver-api/ipmi.rst b/Documentation/driver-api/ipmi.rst
index bc281f10ce4b..c9cb5669bc4c 100644
--- a/Documentation/driver-api/ipmi.rst
+++ b/Documentation/driver-api/ipmi.rst
@@ -166,8 +166,8 @@ and the type is IPMI_SYSTEM_INTERFACE_ADDR_TYPE. This is used for talking
straight to the BMC on the current card. The channel must be
IPMI_BMC_CHANNEL.
-Messages that are destined to go out on the IPMB bus use the
-IPMI_IPMB_ADDR_TYPE address type. The format is::
+Messages that are destined to go out on the IPMB bus going through the
+BMC use the IPMI_IPMB_ADDR_TYPE address type. The format is::
struct ipmi_ipmb_addr
{
@@ -181,6 +181,23 @@ The "channel" here is generally zero, but some devices support more
than one channel, it corresponds to the channel as defined in the IPMI
spec.
+There is also an IPMB direct address for a situation where the sender
+is directly on an IPMB bus and doesn't have to go through the BMC.
+You can send messages to a specific management controller (MC) on the
+IPMB using the IPMI_IPMB_DIRECT_ADDR_TYPE with the following format::
+
+ struct ipmi_ipmb_direct_addr
+ {
+ int addr_type;
+ short channel;
+ unsigned char slave_addr;
+ unsigned char rq_lun;
+ unsigned char rs_lun;
+ };
+
+The channel is always zero. You can also receive commands from other
+MCs that you have registered to handle and respond to them, so you can
+use this to implement a management controller on a bus..
Messages
--------
@@ -348,6 +365,10 @@ user may be registered for each netfn/cmd/channel, but different users
may register for different commands, or the same command if the
channel bitmasks do not overlap.
+To respond to a received command, set the response bit in the returned
+netfn, use the address from the received message, and use the same
+msgid that you got in the receive message.
+
From userland, equivalent IOCTLs are provided to do these functions.
--
2.25.1
Powered by blists - more mailing lists