Re: [PATCH RFC 2/3] hw/i2c: add mctp core

2022-11-17 Thread Jeremy Kerr
Hi Klaus, > I had to reverse the target mode functionality in QEMU from the linux > driver, so I am really not too sure if having START and STOP set in > the interrupt register is allowed behavior or not >From my interpretation of things, there's nothing explicitly preventing both a pending

Re: [PATCH RFC 2/3] hw/i2c: add mctp core

2022-11-17 Thread Jeremy Kerr
ible I will propose upstream. Cheers, Jeremy --- >From 6331cf2499c182606979029d2aaed93ee3e544fa Mon Sep 17 00:00:00 2001 From: Jeremy Kerr Date: Fri, 18 Nov 2022 14:04:50 +0800 Subject: [PATCH] i2c: aspeed: Allow combined STOP & START irqs Currently, if we enter our interrupt handler wit

Re: [PATCH RFC 2/3] hw/i2c: add mctp core

2022-11-17 Thread Jeremy Kerr
Hi Klaus, > Add an abstract MCTP over I2C endpoint model. This implements MCTP > control message handling as well as handling the actual I2C transport > (packetization). > > Devices are intended to derive from this and implement the class > methods. Looks good, nice to see how it's used by the

Re: [PATCH 0/3] hw/{i2c,nvme}: mctp endpoint, nvme management interface model

2022-11-16 Thread Jeremy Kerr
Hi Klaus, [+CC Matt] > This adds a generic MCTP endpoint model that other devices may derive > from. I'm not 100% happy with the design of the class methods, but > it's a start. Thanks for posting these! I'll have a more thorough look through soon, but wanted to tackle some of the larger