Home
last modified time | relevance | path

Searched hist:"400766 f94322a00981b012e714734cab0ed52e68" (Results 1 – 5 of 5) sorted by relevance

/openbmc/libmctp/
H A Dconfigure.acdiff 400766f94322a00981b012e714734cab0ed52e68 Thu Sep 07 07:57:25 CDT 2023 Konstantin Aladyshev <aladyshev22@gmail.com> astlpc: Provide KCS device path as a binding argument

Currently astlpc binding expects a '/dev/mctp0' device in the system
for the KCS communication. This device is a symbolic link to the
real '/dev/raw-kcsX' device, created by the udev rules populated by the
build system.
This approach is not ideal since the build system populates udev rules
for the KCS3 and KCS4 channels simultaneously and for these channels
only. This means that there are some design limitations for the MCTP
communication. It is only possible on KCS3 or KCS4 channel, and if one
of these channels is used, the other one must be disabled.
To make design more flexible get rid of all the udev rules and provide
'/dev/raw-kcsX' device path as an argument to the binding
initialization code.

Change-Id: I505e44280636c83b59669b314f60279b371d0403
Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com>
H A Dlibmctp-astlpc.hdiff 400766f94322a00981b012e714734cab0ed52e68 Thu Sep 07 07:57:25 CDT 2023 Konstantin Aladyshev <aladyshev22@gmail.com> astlpc: Provide KCS device path as a binding argument

Currently astlpc binding expects a '/dev/mctp0' device in the system
for the KCS communication. This device is a symbolic link to the
real '/dev/raw-kcsX' device, created by the udev rules populated by the
build system.
This approach is not ideal since the build system populates udev rules
for the KCS3 and KCS4 channels simultaneously and for these channels
only. This means that there are some design limitations for the MCTP
communication. It is only possible on KCS3 or KCS4 channel, and if one
of these channels is used, the other one must be disabled.
To make design more flexible get rid of all the udev rules and provide
'/dev/raw-kcsX' device path as an argument to the binding
initialization code.

Change-Id: I505e44280636c83b59669b314f60279b371d0403
Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com>
H A DMakefile.amdiff 400766f94322a00981b012e714734cab0ed52e68 Thu Sep 07 07:57:25 CDT 2023 Konstantin Aladyshev <aladyshev22@gmail.com> astlpc: Provide KCS device path as a binding argument

Currently astlpc binding expects a '/dev/mctp0' device in the system
for the KCS communication. This device is a symbolic link to the
real '/dev/raw-kcsX' device, created by the udev rules populated by the
build system.
This approach is not ideal since the build system populates udev rules
for the KCS3 and KCS4 channels simultaneously and for these channels
only. This means that there are some design limitations for the MCTP
communication. It is only possible on KCS3 or KCS4 channel, and if one
of these channels is used, the other one must be disabled.
To make design more flexible get rid of all the udev rules and provide
'/dev/raw-kcsX' device path as an argument to the binding
initialization code.

Change-Id: I505e44280636c83b59669b314f60279b371d0403
Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com>
H A Dastlpc.cdiff 400766f94322a00981b012e714734cab0ed52e68 Thu Sep 07 07:57:25 CDT 2023 Konstantin Aladyshev <aladyshev22@gmail.com> astlpc: Provide KCS device path as a binding argument

Currently astlpc binding expects a '/dev/mctp0' device in the system
for the KCS communication. This device is a symbolic link to the
real '/dev/raw-kcsX' device, created by the udev rules populated by the
build system.
This approach is not ideal since the build system populates udev rules
for the KCS3 and KCS4 channels simultaneously and for these channels
only. This means that there are some design limitations for the MCTP
communication. It is only possible on KCS3 or KCS4 channel, and if one
of these channels is used, the other one must be disabled.
To make design more flexible get rid of all the udev rules and provide
'/dev/raw-kcsX' device path as an argument to the binding
initialization code.

Change-Id: I505e44280636c83b59669b314f60279b371d0403
Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com>
/openbmc/libmctp/utils/
H A Dmctp-demux-daemon.cdiff 400766f94322a00981b012e714734cab0ed52e68 Thu Sep 07 07:57:25 CDT 2023 Konstantin Aladyshev <aladyshev22@gmail.com> astlpc: Provide KCS device path as a binding argument

Currently astlpc binding expects a '/dev/mctp0' device in the system
for the KCS communication. This device is a symbolic link to the
real '/dev/raw-kcsX' device, created by the udev rules populated by the
build system.
This approach is not ideal since the build system populates udev rules
for the KCS3 and KCS4 channels simultaneously and for these channels
only. This means that there are some design limitations for the MCTP
communication. It is only possible on KCS3 or KCS4 channel, and if one
of these channels is used, the other one must be disabled.
To make design more flexible get rid of all the udev rules and provide
'/dev/raw-kcsX' device path as an argument to the binding
initialization code.

Change-Id: I505e44280636c83b59669b314f60279b371d0403
Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com>