All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron via <qemu-devel@nongnu.org>
To: Jonathan Cameron via <qemu-devel@nongnu.org>
Cc: Jonathan Cameron <Jonathan.Cameron@Huawei.com>,
	Maverickk 78 <maverickk1778@gmail.com>
Subject: Re: Call failed: MCTP Endpoint did not respond: Qemu CXL switch with mctp-1.0
Date: Fri, 17 Mar 2023 18:12:05 +0000	[thread overview]
Message-ID: <20230317181205.0000002d@huawei.com> (raw)
In-Reply-To: <20230317163720.00005c23@Huawei.com>

On Fri, 17 Mar 2023 16:37:20 +0000
Jonathan Cameron via <qemu-devel@nongnu.org> wrote:

> On Fri, 17 Mar 2023 00:11:10 +0530
> Maverickk 78 <maverickk1778@gmail.com> wrote:
> 
> > Hi
> > 
> >  I am trying mctp & mctpd with aspeed +buildroot(master) + linux v6.2
> > with Qemu 7.2.
> > 
> > 
> > I have added necessary FMAPI related patches into QEMU to support CLX
> > switch emulation
> > 
> > RFC-1-2-misc-i2c_mctp_cxl_fmapi-Initial-device-emulation.diff
> > 
> > RFC-2-3-hw-i2c-add-mctp-core.diff
> > 
> > RFC-4-4-hw-misc-add-a-toy-i2c-echo-device.diff
> > 
> > RFC-2-2-arm-virt-Add-aspeed-i2c-controller-and-MCTP-EP-to-enable-MCTP-testing.diff
> > 
> > RFC-3-3-hw-nvme-add-nvme-management-interface-model.diff
> > 
> > 
> > Executed following mctp commands to setup the binding,
> > 
> > mctp link set mctpi2c15 up
> > 
> > mctp addr add 50 dev mctpi2c15
> > 
> > mctp link set mctpi2c15 net 11
> > 
> > systemctl restart mctpd.service
> > 
> > busctl call xyz.openbmc_project.MCTP /xyz/openbmc_project/mctp
> > au.com.CodeConstruct.MCTP AssignEndpoint say mctpi2c15 1 0x4d
> > 
> > 
> >  The above busctl configuration is reaching fmapi patch and sets up
> > the endpoint id but then mctpd fails with log after timeout.
> > 
> > Call failed: MCTP Endpoint did not respond
> > 
> > Any clue what's going on?  
> 
> Hi Raghu,
> 
> Yikes. Didn't think anyone would still use that series.
> Not even sure I still have a tree with it on.
> 
> I'll try and bring up again and get back to you. Might be a little
> while though.

It is Friday and this was more interesting than what I was planning to do. :)

I think the breakage comes from the async send i2c series that was a month
or so after the PoC was posted. Issues was it was only entering the _bh once.

Following hack works for me on current mainline (+ CXL patches that shouldn't
affect this.)




From c8d819835faaec2b2a4755eb891284fe21c0747d Mon Sep 17 00:00:00 2001
From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date: Fri, 17 Mar 2023 18:07:08 +0000
Subject: [PATCH] misc/i2c_mctp_fmapi: Hack

Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---
 hw/misc/i2c_mctp_cxl_fmapi.c | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/hw/misc/i2c_mctp_cxl_fmapi.c b/hw/misc/i2c_mctp_cxl_fmapi.c
index 219e30bfd5..2e2da80264 100644
--- a/hw/misc/i2c_mctp_cxl_fmapi.c
+++ b/hw/misc/i2c_mctp_cxl_fmapi.c
@@ -330,7 +330,7 @@ static int i2c_mctp_cxl_switch_event(I2CSlave *i2c, enum i2c_event event)
     case I2C_FINISH:
         s->len = 0;
         s->state = MCTP_I2C_PROCESS_REQUEST;
-        qemu_bh_schedule(s->bh);
+        i2c_bus_master(s->bus, s->bh);
         return 0;
     case I2C_NACK:
     default:
@@ -671,12 +671,11 @@ static void mctp_bh(void *opaque)
 
     switch (s->state) {
     case MCTP_I2C_PROCESS_REQUEST:
-        i2c_bus_master(s->bus, s->bh);
         s->state = MCTP_I2C_START_SEND;
-        return;
-        
+//        return;
+        //fallthrough
     case MCTP_I2C_START_SEND:
-        i2c_start_send(s->bus, s->source_slave_addr);
+        i2c_start_send_async(s->bus, s->source_slave_addr);
         s->send_buf[s->len] = s->source_slave_addr << 1;
         s->len++;
         s->state = MCTP_I2C_ACK;
-- 
2.37.2


> 
> Jonathan
> 
> 
> > 
> > 
> > Regards
> > Raghu  
> 
> 
> 



  reply	other threads:[~2023-03-17 18:12 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-16 18:41 Call failed: MCTP Endpoint did not respond: Qemu CXL switch with mctp-1.0 Maverickk 78
2023-03-17 16:37 ` Jonathan Cameron via
2023-03-17 18:12   ` Jonathan Cameron via [this message]
2023-03-17 20:02     ` Maverickk 78

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230317181205.0000002d@huawei.com \
    --to=qemu-devel@nongnu.org \
    --cc=Jonathan.Cameron@Huawei.com \
    --cc=maverickk1778@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.