From: Jonathan Cameron via <qemu-devel@nongnu.org>
To: Klaus Jensen <its@irrelevant.dk>
Cc: qemu-devel@nongnu.org, "Corey Minyard" <cminyard@mvista.com>,
"Keith Busch" <kbusch@kernel.org>,
"Jason Wang" <jasowang@redhat.com>,
"Lior Weintraub" <liorw@pliops.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Jeremy Kerr" <jk@codeconstruct.com.au>,
qemu-arm@nongnu.org, "Matt Johnston" <matt@codeconstruct.com.au>,
"Peter Delevoryas" <peter@pjd.dev>,
qemu-block@nongnu.org, "Cédric Le Goater" <clg@kaod.org>,
"Klaus Jensen" <k.jensen@samsung.com>,
"Peter Maydell" <peter.maydell@linaro.org>,
gost.dev@samsung.com
Subject: Re: [PATCH v3 2/3] hw/i2c: add mctp core
Date: Wed, 31 May 2023 16:04:10 +0100 [thread overview]
Message-ID: <20230531160410.0000305b@Huawei.com> (raw)
In-Reply-To: <20230531155944.00006309@Huawei.com>
On Wed, 31 May 2023 15:59:44 +0100
Jonathan Cameron <Jonathan.Cameron@Huawei.com> wrote:
> On Wed, 31 May 2023 13:47:43 +0200
> Klaus Jensen <its@irrelevant.dk> wrote:
>
> > From: Klaus Jensen <k.jensen@samsung.com>
> >
> > 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.
> >
> > Parts of this implementation is inspired by code[1] previously posted by
> > Jonathan Cameron.
> >
> > Squashed a fix[2] from Matt Johnston.
> >
> > [1]: https://lore.kernel.org/qemu-devel/20220520170128.4436-1-Jonathan.Cameron@huawei.com/
> > [2]: https://lore.kernel.org/qemu-devel/20221121080445.GA29062@codeconstruct.com.au/
> >
> > Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
> Hi Klaus,
>
> A few minor comments inline.
>
> With those tidied up feel free to add
> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
>
>
>
> > +
> > + if (pkt->mctp.hdr.flags & MCTP_H_FLAGS_SOM) {
> > + mctp->tx.is_control = false;
> > +
> > + if (mctp->state == I2C_MCTP_STATE_RX) {
> > + mc->reset(mctp);
> > + }
> > +
> > + mctp->state = I2C_MCTP_STATE_RX;
> > +
> > + mctp->tx.addr = pkt->i2c.source;
> > + mctp->tx.eid = pkt->mctp.hdr.eid.source;
> > + mctp->tx.flags = pkt->mctp.hdr.flags & 0x7;
>
> Maybe worth either defining that mask, or adding a comment that this
> is copying the msg tag. Or rename flags...
>
>
> > + mctp->tx.pktseq = (pkt->mctp.hdr.flags >> 4) & 0x3;
> > +
> > + if ((pkt->mctp.payload[0] & 0x7f) == MCTP_MESSAGE_TYPE_CONTROL) {
> > + mctp->tx.is_control = true;
> > +
> > + i2c_mctp_handle_control(mctp);
> > +
> > + return 0;
> > + }
> > + } else if (mctp->state == I2C_MCTP_STATE_RX_STARTED) {
> > + trace_i2c_mctp_drop_expected_som();
> > + goto drop;
> > + } else if (((pkt->mctp.hdr.flags >> 4) & 0x3) != (++mctp->tx.pktseq & 0x3)) {
> > + trace_i2c_mctp_drop_invalid_pktseq((pkt->mctp.hdr.flags >> 4) & 0x3,
> > + mctp->tx.pktseq & 0x3);
> > + goto drop;
> > + }
> > +
> > + mc->put_buf(mctp, i2c_mctp_payload(mctp->buffer), payload_len);
> > +
> > + if (pkt->mctp.hdr.flags & MCTP_H_FLAGS_EOM) {
> > + mc->handle(mctp);
> > + mctp->state = I2C_MCTP_STATE_WAIT_TX;
> > + }
> > +
> > + return 0;
> > +
> > + default:
> > + return -1;
> > + }
> > +
> > +drop:
> > + mc->reset(mctp);
> > +
> > + mctp->state = I2C_MCTP_STATE_IDLE;
> > +
> > + return 0;
> > +}
>
>
> > diff --git a/include/hw/i2c/mctp.h b/include/hw/i2c/mctp.h
> > new file mode 100644
> > index 000000000000..ea97792e8d43
> > --- /dev/null
> > +++ b/include/hw/i2c/mctp.h
>
> ...
> > +struct MCTPI2CEndpointClass {
> > + I2CSlaveClass parent_class;
> > +
> > + /**
> > + *
> > + * put_buf() - receive incoming message fragment
> > + *
> > + * Must returns 0 for succes or -1 for error.
> > + */
> > + int (*put_buf)(MCTPI2CEndpoint *mctp, uint8_t *buf, size_t len);
> > +
> > + /**
> > + * get_buf() - provide pointer to message fragment
> > + *
> > + * Called by the mctp subsystem to request a pointer to the next message
> > + * fragment. The implementation must advance its internal position such
> > + * that successive calls returns the next fragments.
> > + *
> > + * Must return the number of bytes available.
> > + */
> > + size_t (*get_buf)(MCTPI2CEndpoint *mctp, const uint8_t **buf,
> > + size_t maxlen, uint8_t *mctp_flags);
> > +
> > + /**
> > + * handle() - handle an MCTP message
> > + *
> > + * Called by the mctp subsystem when a full message has been delivered and
> > + * may be parsed and processed.
> > + */
> > + void (*handle)(MCTPI2CEndpoint *mctp);
> > +
> > + /**
> > + * reset() - reset internal state
> > + *
> > + * Called by the mctp subsystem in the event of some transport error.
> > + * Implementation must reset its internal state and drop any fragments
> > + * previously receieved.
> > + */
> > + void (*reset)(MCTPI2CEndpoint *mctp);
> > +
> > + /**
> > + * get_types() - provide supported mctp message types
> > + *
> > + * Must provide a buffer with a full MCTP supported message types payload
> > + * (i.e. `0x0(SUCCESS),0x1(ONE),0x4(NMI)`).
>
> ONE? Looks to be PLDM
> Good to reference DSP0239 Management Component Transport Protocol (MCTP) IDs and Codes
> which has the list.
Ah. 0x1 is the length. Call it "type count" instead of ONE and make it obvious.
>
> > + *
> > + * Returns the size of the response.
> > + */
> > + size_t (*get_types)(MCTPI2CEndpoint *mctp, const uint8_t **data);
> > +};
>
> > diff --git a/include/net/mctp.h b/include/net/mctp.h
> > new file mode 100644
> > index 000000000000..70b49235ddb2
> > --- /dev/null
> > +++ b/include/net/mctp.h
> > @@ -0,0 +1,28 @@
> > +#ifndef QEMU_MCTP_H
> > +#define QEMU_MCTP_H
> > +
> > +#define MCTP_BASELINE_MTU 64
>
> Ideally add a reference for this as well.
>
> 8.3.1 Baseline transmission unit in DSP0236 1.3.0
> > +
> > +enum {
> > + MCTP_H_FLAGS_EOM = 1 << 6,
> > + MCTP_H_FLAGS_SOM = 1 << 7,
>
> Trivial: I'm not really seeing the enum here as useful vs
> a pair of defines.
>
> > +};
> > +
> > +#define MCTP_MESSAGE_IC (1 << 7)
> > +
>
>
next prev parent reply other threads:[~2023-05-31 15:04 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-31 11:47 [PATCH v3 0/3] hw/{i2c, nvme}: mctp endpoint, nvme management interface model Klaus Jensen
2023-05-31 11:47 ` [PATCH v3 1/3] hw/i2c: add smbus pec utility function Klaus Jensen
2023-05-31 13:13 ` Jonathan Cameron via
2023-06-01 20:34 ` Philippe Mathieu-Daudé
2023-05-31 11:47 ` [PATCH v3 2/3] hw/i2c: add mctp core Klaus Jensen
2023-05-31 14:59 ` Jonathan Cameron via
2023-05-31 15:04 ` Jonathan Cameron via [this message]
2023-05-31 11:47 ` [PATCH v3 3/3] hw/nvme: add nvme management interface model Klaus Jensen
2023-05-31 15:39 ` Jonathan Cameron via
2023-06-01 19:42 ` [PATCH v3 0/3] hw/{i2c, nvme}: mctp endpoint, " Corey Minyard
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=20230531160410.0000305b@Huawei.com \
--to=qemu-devel@nongnu.org \
--cc=Jonathan.Cameron@Huawei.com \
--cc=clg@kaod.org \
--cc=cminyard@mvista.com \
--cc=gost.dev@samsung.com \
--cc=its@irrelevant.dk \
--cc=jasowang@redhat.com \
--cc=jk@codeconstruct.com.au \
--cc=k.jensen@samsung.com \
--cc=kbusch@kernel.org \
--cc=liorw@pliops.com \
--cc=matt@codeconstruct.com.au \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=peter@pjd.dev \
--cc=qemu-arm@nongnu.org \
--cc=qemu-block@nongnu.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).