[IPMBD] ipmbSend handling
KFTING at nuvoton.com
KFTING at nuvoton.com
Fri Aug 24 16:02:47 AEST 2018
Hi:
I check the ipmbd implementation from
https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.openbmc-2Dproject.xyz_-23_c_openbmc_ipmbbridge_-2B_11130_&d=DwICAg&c=ue8mO8zgC4VZ4q_aNVKt8G9MC01UFDmisvMR1k-EoDM&r=kGibSCEQz-PilnW-r9KNT7_zWJXJNtnSK5aYZCe7SVs&m=9vYrt5dE5uTcGZ0xJvXwlc2qHu9SzkgJbpR7h9W0jXE&s=xLAMWHrLSU8GJiEb4ObBmfmlBhRwK26Z3t4-piFCe1c&e= and find out that the IPMB request or response messages are passed down to the I2C slave device in the ipmbSend function.
The master device node is /dev/i2c-0 and the slave device node is /sys/bus/i2c/devices/0-1010/slave-mqueue in the ipmbbridge implementation.
The direction is always from the master device to the slave device.
In normal IPMB usage case, an IPMB request is sent to the master device (say /dev/i2c-3) and then the master device sends that IPMB request to the client device attached to the master device's bus.
While an IPMB response returns from the client device, the client device uses an I2C master-write transfer to send the response back to the request originator, which is /dev/i2c-3, according to IPMB spec. So the request originator becomes an I2C slave at this moment.
It seems to me that ipmbSend behavior doesn't get aligned with the description of request/response protocol in IPMB spec.
I might misunderstand the ipmbSend behavior and any comment is welcome.
Thank you.
Regards,
Tyrone
===========================================================================================
The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20180824/affa1308/attachment.html>
More information about the openbmc
mailing list