@@ -166,8 +166,8 @@ and the type is IPMI_SYSTEM_INTERFACE_ADDR_TYPE. This is used for talking
166
166
straight to the BMC on the current card. The channel must be
167
167
IPMI_BMC_CHANNEL.
168
168
169
- Messages that are destined to go out on the IPMB bus use the
170
- IPMI_IPMB_ADDR_TYPE address type. The format is::
169
+ Messages that are destined to go out on the IPMB bus going through the
170
+ BMC use the IPMI_IPMB_ADDR_TYPE address type. The format is::
171
171
172
172
struct ipmi_ipmb_addr
173
173
{
@@ -181,6 +181,23 @@ The "channel" here is generally zero, but some devices support more
181
181
than one channel, it corresponds to the channel as defined in the IPMI
182
182
spec.
183
183
184
+ There is also an IPMB direct address for a situation where the sender
185
+ is directly on an IPMB bus and doesn't have to go through the BMC.
186
+ You can send messages to a specific management controller (MC) on the
187
+ IPMB using the IPMI_IPMB_DIRECT_ADDR_TYPE with the following format::
188
+
189
+ struct ipmi_ipmb_direct_addr
190
+ {
191
+ int addr_type;
192
+ short channel;
193
+ unsigned char slave_addr;
194
+ unsigned char rq_lun;
195
+ unsigned char rs_lun;
196
+ };
197
+
198
+ The channel is always zero. You can also receive commands from other
199
+ MCs that you have registered to handle and respond to them, so you can
200
+ use this to implement a management controller on a bus..
184
201
185
202
Messages
186
203
--------
@@ -348,6 +365,10 @@ user may be registered for each netfn/cmd/channel, but different users
348
365
may register for different commands, or the same command if the
349
366
channel bitmasks do not overlap.
350
367
368
+ To respond to a received command, set the response bit in the returned
369
+ netfn, use the address from the received message, and use the same
370
+ msgid that you got in the receive message.
371
+
351
372
From userland, equivalent IOCTLs are provided to do these functions.
352
373
353
374
0 commit comments