I2C Multi-master and Controller Slave Mode in QEMU

I2C Multi-master and Controller Slave Mode in QEMU

[Shesha Bhushan Sreenivasamurthy]

Hi,
   Is there any implementation of I2C Multi-master and Controller Slave Mode in QEMU for x86 ?

What I want is to create CXL-I2C device that can exercise DCD commands via FM-API. For that I need a bus that can support both master and slave on x86. Is there one available ?

The second question is, can qemu-cxltype3 device be used on ARM ?

Re: I2C Multi-master and Controller Slave Mode in QEMU

[Jonathan Cameron]

On Fri, 19 May 2023 19:43:25 +0000
Shesha Bhushan Sreenivasamurthy <sheshas@marvell.com> wrote:

> Hi,
>    Is there any implementation of I2C Multi-master and Controller Slave Mode in QEMU for x86 ?
> 
> What I want is to create CXL-I2C device that can exercise DCD commands via FM-API. For that I need a bus that can support both master and slave on x86. Is there one available ?

I have a side project underway to make this work.  It will be a little 'unusual'
as it'll bolt an aspeed-i2c controller with the right support onto an x86 host.
Might take me a few more days to get that working.  I have it up and running
with ACPI on an arm64 host (a few minor tweaks needed to the aspeed-i2c kernel
driver which I'll also post - mostly upstreamable but there are a couple of
hacks for now).

Currently that aspeed device is the only i2c controller that supports MCTP that has
some patches on list to do everything you want.

> 
> The second question is, can qemu-cxltype3 device be used on ARM ?

Yes, but you need the out of mainline patches from
gitlab.com/jic23/qemu Use the previous dated tag though as latest has some issues
(bad choice of base which turned out to crash :)

I'll be putting together a fixed version of that in next day or two.

https://gitlab.com/jic23/qemu/-/tree/cxl-2023-04-19?ref_type=heads
for now.

That includes support for the aspeed-i2c controller but with dt only which isn't
that helpful if you want to also use the CXL drivers.

Anyhow, it's a watch this space for now. Hopefully I'll get the PoC code in a shape
to share later this week.

Jonathan

Re: [EXT] Re: I2C Multi-master and Controller Slave Mode in QEMU

[Shesha Bhushan Sreenivasamurthy]

From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Sent: Monday, May 22, 2023 7:41 AM
To: Shesha Bhushan Sreenivasamurthy <sheshas@marvell.com>
Cc: linux-cxl@vger.kernel.org <linux-cxl@vger.kernel.org>
Subject: [EXT] Re: I2C Multi-master and Controller Slave Mode in QEMU 
 
External Email

----------------------------------------------------------------------
On Fri, 19 May 2023 19:43:25 +0000
Shesha Bhushan Sreenivasamurthy <sheshas@marvell.com> wrote:

> Hi,
>    Is there any implementation of I2C Multi-master and Controller Slave Mode in QEMU for x86 ?
> 
> What I want is to create CXL-I2C device that can exercise DCD commands via FM-API. For that I need a bus that can support both master and slave on x86. Is there one available ?

I have a side project underway to make this work.  It will be a little 'unusual'
as it'll bolt an aspeed-i2c controller with the right support onto an x86 host.
Might take me a few more days to get that working.  I have it up and running
with ACPI on an arm64 host (a few minor tweaks needed to the aspeed-i2c kernel
driver which I'll also post - mostly upstreamable but there are a couple of
hacks for now).

Currently that aspeed device is the only i2c controller that supports MCTP that has
some patches on list to do everything you want.

SS: I was able to get MCTP working on openBMC + ARM. But I was interested in using MCTP on x86. I will look forward for your patch.

> 
> The second question is, can qemu-cxltype3 device be used on ARM ?

Yes, but you need the out of mainline patches from
gitlab.com/jic23/qemu Use the previous dated tag though as latest has some issues
(bad choice of base which turned out to crash :)

I'll be putting together a fixed version of that in next day or two.

https://urldefense.proofpoint.com/v2/url?u=https-3A__gitlab.com_jic23_qemu_-2D_tree_cxl-2D2023-2D04-2D19-3Fref-5Ftype-3Dheads&d=DwICAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=Zta64bwn4nurTRpD4LY2OGr8KklkMRPn7Z_Qy0o4unU&m=HjxYTjPnn1_sL7TKjONiz2tjg7Wgb2SHDpdPWugtqp91xBPuXM8apydEWLy-PNOA&s=KPl9oVgiVvYj9UcBRp7CohPsuEPicbpQzsFLV7uieOw&e= 
for now.

That includes support for the aspeed-i2c controller but with dt only which isn't
that helpful if you want to also use the CXL drivers.

Anyhow, it's a watch this space for now. Hopefully I'll get the PoC code in a shape
to share later this week.

Do you mean to say, if I take patch from gitlab.com/jic23/qemu, can I boot linux on ARM and use CXL kernel drivers ?
Thanks
Shesha

Jonathan

Re: [EXT] Re: I2C Multi-master and Controller Slave Mode in QEMU

[Jonathan Cameron]

On Tue, 23 May 2023 22:08:21 +0000
Shesha Bhushan Sreenivasamurthy <sheshas@marvell.com> wrote:

> From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
> Sent: Monday, May 22, 2023 7:41 AM
> To: Shesha Bhushan Sreenivasamurthy <sheshas@marvell.com>
> Cc: linux-cxl@vger.kernel.org <linux-cxl@vger.kernel.org>
> Subject: [EXT] Re: I2C Multi-master and Controller Slave Mode in QEMU 
>  
> External Email
> 
> ----------------------------------------------------------------------
> On Fri, 19 May 2023 19:43:25 +0000
> Shesha Bhushan Sreenivasamurthy <sheshas@marvell.com> wrote:
> 
> > Hi,
> >    Is there any implementation of I2C Multi-master and Controller Slave Mode in QEMU for x86 ?
> > 
> > What I want is to create CXL-I2C device that can exercise DCD commands via FM-API. For that I need a bus that can support both master and slave on x86. Is there one available ?  
> 
> I have a side project underway to make this work.  It will be a little 'unusual'
> as it'll bolt an aspeed-i2c controller with the right support onto an x86 host.
> Might take me a few more days to get that working.  I have it up and running
> with ACPI on an arm64 host (a few minor tweaks needed to the aspeed-i2c kernel
> driver which I'll also post - mostly upstreamable but there are a couple of
> hacks for now).
> 
> Currently that aspeed device is the only i2c controller that supports MCTP that has
> some patches on list to do everything you want.
> 
> SS: I was able to get MCTP working on openBMC + ARM. But I was interested in using MCTP on x86. I will look forward for your patch.

I now have it running on both ARM (ACPI + DT) and x86 (ACPI).

Needs a few hacks on the relevant i2c driver in the kernel and unfortunately at least
one of those probably isn't ever going to be upstreamable.

However, that aside it all works nicely.

> 
> > 
> > The second question is, can qemu-cxltype3 device be used on ARM ?  
> 
> Yes, but you need the out of mainline patches from
> gitlab.com/jic23/qemu Use the previous dated tag though as latest has some issues
> (bad choice of base which turned out to crash :)
> 
> I'll be putting together a fixed version of that in next day or two.
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__gitlab.com_jic23_qemu_-2D_tree_cxl-2D2023-2D04-2D19-3Fref-5Ftype-3Dheads&d=DwICAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=Zta64bwn4nurTRpD4LY2OGr8KklkMRPn7Z_Qy0o4unU&m=HjxYTjPnn1_sL7TKjONiz2tjg7Wgb2SHDpdPWugtqp91xBPuXM8apydEWLy-PNOA&s=KPl9oVgiVvYj9UcBRp7CohPsuEPicbpQzsFLV7uieOw&e= 
> for now.
> 
> That includes support for the aspeed-i2c controller but with dt only which isn't
> that helpful if you want to also use the CXL drivers.
> 
> Anyhow, it's a watch this space for now. Hopefully I'll get the PoC code in a shape
> to share later this week.
> 
> Do you mean to say, if I take patch from gitlab.com/jic23/qemu, can I boot linux on ARM and use CXL kernel drivers ?

Yes, though use a slightly old version for now as I think the latest one crashes for
reasons that I never tracked down (think it was just an unlucky base).

Once I have done a tiny bit more tidying up of this MCTP stuff I'll get back to ensuring
there is a stable branch at that address and put the MCTP stuff on top.

It's minimal at the moment:
* Identify from CCI command set
* A few FM-API physical switch commands,

However that should be enough that it's fairly obvious how to extend it to add
lots more commands and hopefully others will jump in at that point.

Main job I still need to do is write some docs on how to bring it up + userspace
tooling to use etc.

Jonathan


> Thanks
> Shesha
> 
> Jonathan
> 
> 

Re: [EXT] Re: I2C Multi-master and Controller Slave Mode in QEMU

[Shesha Bhushan Sreenivasamurthy]

From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Sent: Wednesday, May 24, 2023 9:39 AM
To: Shesha Bhushan Sreenivasamurthy <sheshas@marvell.com>
Cc: linux-cxl@vger.kernel.org <linux-cxl@vger.kernel.org>
Subject: Re: [EXT] Re: I2C Multi-master and Controller Slave Mode in QEMU 
 
On Tue, 23 May 2023 22:08:21 +0000
Shesha Bhushan Sreenivasamurthy <sheshas@marvell.com> wrote:

> From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
> Sent: Monday, May 22, 2023 7:41 AM
> To: Shesha Bhushan Sreenivasamurthy <sheshas@marvell.com>
> Cc: linux-cxl@vger.kernel.org <linux-cxl@vger.kernel.org>
> Subject: [EXT] Re: I2C Multi-master and Controller Slave Mode in QEMU 
>  
> External Email
> 
> ----------------------------------------------------------------------
> On Fri, 19 May 2023 19:43:25 +0000
> Shesha Bhushan Sreenivasamurthy <sheshas@marvell.com> wrote:
> 
> > Hi,
> >    Is there any implementation of I2C Multi-master and Controller Slave Mode in QEMU for x86 ?
> > 
> > What I want is to create CXL-I2C device that can exercise DCD commands via FM-API. For that I need a bus that can support both master and slave on x86. Is there one available ?  
> 
> I have a side project underway to make this work.  It will be a little 'unusual'
> as it'll bolt an aspeed-i2c controller with the right support onto an x86 host.
> Might take me a few more days to get that working.  I have it up and running
> with ACPI on an arm64 host (a few minor tweaks needed to the aspeed-i2c kernel
> driver which I'll also post - mostly upstreamable but there are a couple of
> hacks for now).
> 
> Currently that aspeed device is the only i2c controller that supports MCTP that has
> some patches on list to do everything you want.
> 
> SS: I was able to get MCTP working on openBMC + ARM. But I was interested in using MCTP on x86. I will look forward for your patch.

I now have it running on both ARM (ACPI + DT) and x86 (ACPI).

Needs a few hacks on the relevant i2c driver in the kernel and unfortunately at least
one of those probably isn't ever going to be upstreamable.

However, that aside it all works nicely.

ss: Thats great ! Can you please share the code, both QEMU and kernel driver ?

> 
> > 
> > The second question is, can qemu-cxltype3 device be used on ARM ?  
> 
> Yes, but you need the out of mainline patches from
> gitlab.com/jic23/qemu Use the previous dated tag though as latest has some issues
> (bad choice of base which turned out to crash :)
> 
> I'll be putting together a fixed version of that in next day or two.
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__gitlab.com_jic23_qemu_-2D_tree_cxl-2D2023-2D04-2D19-3Fref-5Ftype-3Dheads&d=DwICAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=Zta64bwn4nurTRpD4LY2OGr8KklkMRPn7Z_Qy0o4unU&m=HjxYTjPnn1_sL7TKjONiz2tjg7Wgb2SHDpdPWugtqp91xBPuXM8apydEWLy-PNOA&s=KPl9oVgiVvYj9UcBRp7CohPsuEPicbpQzsFLV7uieOw&e= 
> for now.
> 
> That includes support for the aspeed-i2c controller but with dt only which isn't
> that helpful if you want to also use the CXL drivers.
> 
> Anyhow, it's a watch this space for now. Hopefully I'll get the PoC code in a shape
> to share later this week.
> 
> Do you mean to say, if I take patch from gitlab.com/jic23/qemu, can I boot linux on ARM and use CXL kernel drivers ?

Yes, though use a slightly old version for now as I think the latest one crashes for
reasons that I never tracked down (think it was just an unlucky base).

Once I have done a tiny bit more tidying up of this MCTP stuff I'll get back to ensuring
there is a stable branch at that address and put the MCTP stuff on top.

It's minimal at the moment:
* Identify from CCI command set
* A few FM-API physical switch commands,

However that should be enough that it's fairly obvious how to extend it to add
lots more commands and hopefully others will jump in at that point.

Main job I still need to do is write some docs on how to bring it up + userspace
tooling to use etc.

Jonathan


> Thanks
> Shesha
> 
> Jonathan
> 
> 

Re: [EXT] Re: I2C Multi-master and Controller Slave Mode in QEMU

[Jonathan Cameron]

> ss: Thats great ! Can you please share the code, both QEMU and kernel driver ?

QEMU:  http://gitlab.com/jic23/qemu cxl-2023-05-25 
https://lore.kernel.org/linux-cxl/20230525160859.32517-1-Jonathan.Cameron@huawei.com/T/#t
Kernel:  To enable ACPI support in the aspeed-i2c driver used.
https://lore.kernel.org/linux-cxl/20230525152203.32190-1-Jonathan.Cameron@huawei.com/T/#t

Other than enabling MCTP + the aspeed-i2c driver, not much special needed kernel side
(all access is from the MCTP socket interface in userspace).

Have fun.  It's pretty minimal at the moment.
For switches it pokes at the number of ports (the port status is all lies for now)
For Type 3 devices it just provide Identify.

I need to do a little more spec diving to check I've enabled them for the correct
MCTP bindings.

Jonathan

Re: [EXT] Re: I2C Multi-master and Controller Slave Mode in QEMU

[Shesha Bhushan Sreenivasamurthy]

Thanks a lot. It works. I am planning to add more CXL commands, especially DCD commands. Are you or any one working ? If so I will wait :)


From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Sent: Thursday, May 25, 2023 9:23 AM
To: Shesha Bhushan Sreenivasamurthy <sheshas@marvell.com>
Cc: linux-cxl@vger.kernel.org <linux-cxl@vger.kernel.org>
Subject: Re: [EXT] Re: I2C Multi-master and Controller Slave Mode in QEMU 
 

> ss: Thats great ! Can you please share the code, both QEMU and kernel driver ?

QEMU:  https://urldefense.proofpoint.com/v2/url?u=http-3A__gitlab.com_jic23_qemu&d=DwICAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=Zta64bwn4nurTRpD4LY2OGr8KklkMRPn7Z_Qy0o4unU&m=UQ3dgvJg_i34v2qxPCBlB3FuVUmLQ37oHw2LKVGYimsevbBm75NKu_2xDhtZ3LxL&s=DWzpkbi44uasdoDv_GxAR2to07vEd_Cr7eaKz0lpP6E&e=  cxl-2023-05-25 
https://urldefense.proofpoint.com/v2/url?u=https-3A__lore.kernel.org_linux-2Dcxl_20230525160859.32517-2D1-2DJonathan.Cameron-40huawei.com_T_-23t&d=DwICAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=Zta64bwn4nurTRpD4LY2OGr8KklkMRPn7Z_Qy0o4unU&m=UQ3dgvJg_i34v2qxPCBlB3FuVUmLQ37oHw2LKVGYimsevbBm75NKu_2xDhtZ3LxL&s=3zV1e3KB_3wAesmu5jsYP7YodFFgzjydMl0vICy6Tis&e= 
Kernel:  To enable ACPI support in the aspeed-i2c driver used.
https://urldefense.proofpoint.com/v2/url?u=https-3A__lore.kernel.org_linux-2Dcxl_20230525152203.32190-2D1-2DJonathan.Cameron-40huawei.com_T_-23t&d=DwICAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=Zta64bwn4nurTRpD4LY2OGr8KklkMRPn7Z_Qy0o4unU&m=UQ3dgvJg_i34v2qxPCBlB3FuVUmLQ37oHw2LKVGYimsevbBm75NKu_2xDhtZ3LxL&s=tPmsOiZy9jqzAIFK46Nj_WIzpX7WNf5bxge2uZUa2Yg&e= 

Other than enabling MCTP + the aspeed-i2c driver, not much special needed kernel side
(all access is from the MCTP socket interface in userspace).

Have fun.  It's pretty minimal at the moment.
For switches it pokes at the number of ports (the port status is all lies for now)
For Type 3 devices it just provide Identify.

I need to do a little more spec diving to check I've enabled them for the correct
MCTP bindings.

Jonathan

Re: [EXT] Re: I2C Multi-master and Controller Slave Mode in QEMU

[Jonathan Cameron]

On Thu, 1 Jun 2023 23:07:54 +0000
Shesha Bhushan Sreenivasamurthy <sheshas@marvell.com> wrote:

> Thanks a lot. It works. I am planning to add more CXL commands, especially DCD commands. Are you or any one working ? If so I will wait :)

It's on my todo list, but I'm more than happy if you do it instead.

I'll get on with something else:
I want to get the mailbox based tunneling working so that we have that
path for MHDs as well which is reasonable separate at this stage anyway
- later on we'll want to factor out some common solutions - I suspect
a lot of the actual command responses will be done in hw/mem/cxl_type3.c
and hw/pci-bridge/cxl_upstream.c, but for now it's convenient
to keep them separate.  The switch CCI stuff needs to be in the mix as well
and will likely look a bit like how the mctp CCI hooks into the switch USP.
The old prototype of that didn't talk to the devices at all so was returning
made up responses.

Jonathan



> 
> 
> From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
> Sent: Thursday, May 25, 2023 9:23 AM
> To: Shesha Bhushan Sreenivasamurthy <sheshas@marvell.com>
> Cc: linux-cxl@vger.kernel.org <linux-cxl@vger.kernel.org>
> Subject: Re: [EXT] Re: I2C Multi-master and Controller Slave Mode in QEMU 
>  
> 
> > ss: Thats great ! Can you please share the code, both QEMU and kernel driver ?  
> 
> QEMU:  https://urldefense.proofpoint.com/v2/url?u=http-3A__gitlab.com_jic23_qemu&d=DwICAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=Zta64bwn4nurTRpD4LY2OGr8KklkMRPn7Z_Qy0o4unU&m=UQ3dgvJg_i34v2qxPCBlB3FuVUmLQ37oHw2LKVGYimsevbBm75NKu_2xDhtZ3LxL&s=DWzpkbi44uasdoDv_GxAR2to07vEd_Cr7eaKz0lpP6E&e=  cxl-2023-05-25 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lore.kernel.org_linux-2Dcxl_20230525160859.32517-2D1-2DJonathan.Cameron-40huawei.com_T_-23t&d=DwICAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=Zta64bwn4nurTRpD4LY2OGr8KklkMRPn7Z_Qy0o4unU&m=UQ3dgvJg_i34v2qxPCBlB3FuVUmLQ37oHw2LKVGYimsevbBm75NKu_2xDhtZ3LxL&s=3zV1e3KB_3wAesmu5jsYP7YodFFgzjydMl0vICy6Tis&e= 
> Kernel:  To enable ACPI support in the aspeed-i2c driver used.
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lore.kernel.org_linux-2Dcxl_20230525152203.32190-2D1-2DJonathan.Cameron-40huawei.com_T_-23t&d=DwICAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=Zta64bwn4nurTRpD4LY2OGr8KklkMRPn7Z_Qy0o4unU&m=UQ3dgvJg_i34v2qxPCBlB3FuVUmLQ37oHw2LKVGYimsevbBm75NKu_2xDhtZ3LxL&s=tPmsOiZy9jqzAIFK46Nj_WIzpX7WNf5bxge2uZUa2Yg&e= 
> 
> Other than enabling MCTP + the aspeed-i2c driver, not much special needed kernel side
> (all access is from the MCTP socket interface in userspace).
> 
> Have fun.  It's pretty minimal at the moment.
> For switches it pokes at the number of ports (the port status is all lies for now)
> For Type 3 devices it just provide Identify.
> 
> I need to do a little more spec diving to check I've enabled them for the correct
> MCTP bindings.
> 
> Jonathan

Re: [EXT] Re: I2C Multi-master and Controller Slave Mode in QEMU

[Shesha Bhushan Sreenivasamurthy]

From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Sent: Friday, June 2, 2023 5:25 AM
To: Shesha Bhushan Sreenivasamurthy <sheshas@marvell.com>
Cc: linux-cxl@vger.kernel.org <linux-cxl@vger.kernel.org>
Subject: Re: [EXT] Re: I2C Multi-master and Controller Slave Mode in QEMU 
 
On Thu, 1 Jun 2023 23:07:54 +0000
Shesha Bhushan Sreenivasamurthy <sheshas@marvell.com> wrote:

> Thanks a lot. It works. I am planning to add more CXL commands, especially DCD commands. Are you or any one working ? If so I will wait :)

It's on my todo list, but I'm more than happy if you do it instead.

ss - This will be my first contribution, so will be slow, if that is okay, I will take it up

I'll get on with something else:
I want to get the mailbox based tunneling working so that we have that
path for MHDs as well which is reasonable separate at this stage anyway
- later on we'll want to factor out some common solutions - I suspect
a lot of the actual command responses will be done in hw/mem/cxl_type3.c
and hw/pci-bridge/cxl_upstream.c, but for now it's convenient
to keep them separate.  The switch CCI stuff needs to be in the mix as well
and will likely look a bit like how the mctp CCI hooks into the switch USP.
The old prototype of that didn't talk to the devices at all so was returning
made up responses.

Jonathan



> 
> 
> From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
> Sent: Thursday, May 25, 2023 9:23 AM
> To: Shesha Bhushan Sreenivasamurthy <sheshas@marvell.com>
> Cc: linux-cxl@vger.kernel.org <linux-cxl@vger.kernel.org>
> Subject: Re: [EXT] Re: I2C Multi-master and Controller Slave Mode in QEMU 
>  
> 
> > ss: Thats great ! Can you please share the code, both QEMU and kernel driver ?  
> 
> QEMU:  https://urldefense.proofpoint.com/v2/url?u=http-3A__gitlab.com_jic23_qemu&d=DwICAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=Zta64bwn4nurTRpD4LY2OGr8KklkMRPn7Z_Qy0o4unU&m=UQ3dgvJg_i34v2qxPCBlB3FuVUmLQ37oHw2LKVGYimsevbBm75NKu_2xDhtZ3LxL&s=DWzpkbi44uasdoDv_GxAR2to07vEd_Cr7eaKz0lpP6E&e=  cxl-2023-05-25 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lore.kernel.org_linux-2Dcxl_20230525160859.32517-2D1-2DJonathan.Cameron-40huawei.com_T_-23t&d=DwICAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=Zta64bwn4nurTRpD4LY2OGr8KklkMRPn7Z_Qy0o4unU&m=UQ3dgvJg_i34v2qxPCBlB3FuVUmLQ37oHw2LKVGYimsevbBm75NKu_2xDhtZ3LxL&s=3zV1e3KB_3wAesmu5jsYP7YodFFgzjydMl0vICy6Tis&e= 
> Kernel:  To enable ACPI support in the aspeed-i2c driver used.
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lore.kernel.org_linux-2Dcxl_20230525152203.32190-2D1-2DJonathan.Cameron-40huawei.com_T_-23t&d=DwICAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=Zta64bwn4nurTRpD4LY2OGr8KklkMRPn7Z_Qy0o4unU&m=UQ3dgvJg_i34v2qxPCBlB3FuVUmLQ37oHw2LKVGYimsevbBm75NKu_2xDhtZ3LxL&s=tPmsOiZy9jqzAIFK46Nj_WIzpX7WNf5bxge2uZUa2Yg&e= 
> 
> Other than enabling MCTP + the aspeed-i2c driver, not much special needed kernel side
> (all access is from the MCTP socket interface in userspace).
> 
> Have fun.  It's pretty minimal at the moment.
> For switches it pokes at the number of ports (the port status is all lies for now)
> For Type 3 devices it just provide Identify.
> 
> I need to do a little more spec diving to check I've enabled them for the correct
> MCTP bindings.
> 
> Jonathan