Hi Deepak,

On 13/01/20 10:23 PM, Khetan, Shara=
d wrote:
Hi Andrew,
On Thu, 9 Jan 2020, at 12:27, Andrew Jeffery wrote:

 On Sat, 21 Dec 2019, at 10:45, Kheta=
n, Sharad wrote:
 Hi Andr=
ew,
 Sorry for late response.
 The plan is to have MCTP in user space=
.

 How are you handling this then? mmap()'ing the B=
AR from sysfs?

Sorry, let me put my brain back in, I was thinking of the wrong sid=
e of the  BMC/Host MCTP channel. How much were you planning to do in usersp=
ace on the BMC? As in, are you planning to drive the BMC's PCIe MCTP contro=
ller from userspace (presumably via /dev/mem)?

Fo=
r implementation on the BMC, we agree that it's better to do it in kernel (=
and as you mentioned  - use consistent interface to upper layers, provide a=
nother transport). However, given the time needed to implement things in ke=
rnel (and the review after), we are starting with a short term solution. We=
 will be implementing MCTP (protocol elements) in user space, along with a =
low level MCTP PCIe driver just to push bits on PCIe. Iwona is working on t=
his and should be able to describe the exact primitive.
Do you plan to do the user-space work as an extension to/reusing component=
s from openbmc/libmctp?

Thanks,
Deepak

Yes we plan to reus=
e and extend the libmctp, support PCIe as well as SMBus bindings. We plan t=
o use d-bus extensions to existing libmctp. That said, we will know the exa=
ct extent of reuse/modifications when we really start implementing.

=
We are implementing this for AST 2600 (will not support any workarounds for=
 AST 2500 bug). 

@Andrew, Thanks for your response.

Thanks,Sharad