From: Klaus Jensen <its@irrelevant.dk>
To: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Corey Minyard <cminyard@mvista.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Peter Maydell <peter.maydell@linaro.org>,
Jason Wang <jasowang@redhat.com>, Keith Busch <kbusch@kernel.org>,
Lior Weintraub <liorw@pliops.com>,
Jeremy Kerr <jk@codeconstruct.com.au>,
Matt Johnston <matt@codeconstruct.com.au>,
Peter Delevoryas <peter@pjd.dev>,
qemu-devel@nongnu.org, qemu-arm@nongnu.org,
qemu-block@nongnu.org, Klaus Jensen <k.jensen@samsung.com>
Subject: Re: [PATCH v4 2/3] hw/i2c: add mctp core
Date: Mon, 4 Sep 2023 12:49:20 +0200 [thread overview]
Message-ID: <ZPW2MFWp6mIvReS5@cormorant.local> (raw)
In-Reply-To: <20230830153123.00006cc4@Huawei.com>
[-- Attachment #1: Type: text/plain, Size: 7050 bytes --]
On Aug 30 15:31, Jonathan Cameron wrote:
> On Wed, 23 Aug 2023 11:21:59 +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>
>
> I made the minor changes to the CXL FM-API PoC to use this and all works as expected so
>
> Tested-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
>
>
> Some minor things inline. With those tidied up or ignored with clear reasoning.
>
> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
>
>
> > diff --git a/hw/i2c/mctp.c b/hw/i2c/mctp.c
> > new file mode 100644
> > index 000000000000..217073d62435
> > --- /dev/null
> > +++ b/hw/i2c/mctp.c
>
>
> ...
>
>
> > +static int i2c_mctp_event_cb(I2CSlave *i2c, enum i2c_event event)
> > +{
> > + MCTPI2CEndpoint *mctp = MCTP_I2C_ENDPOINT(i2c);
> > + MCTPI2CEndpointClass *mc = MCTP_I2C_ENDPOINT_GET_CLASS(mctp);
> > + MCTPI2CPacket *pkt = (MCTPI2CPacket *)mctp->buffer;
> > + size_t payload_len;
> > + uint8_t pec, pktseq, msgtype;
> > +
> > + switch (event) {
> > + case I2C_START_SEND:
> > + if (mctp->state == I2C_MCTP_STATE_IDLE) {
> > + mctp->state = I2C_MCTP_STATE_RX_STARTED;
> > + } else if (mctp->state != I2C_MCTP_STATE_RX) {
> > + return -1;
> > + }
> > +
> > + /* the i2c core eats the slave address, so put it back in */
> > + pkt->i2c.dest = i2c->address << 1;
> > + mctp->len = 1;
> > +
> > + return 0;
> > +
> > + case I2C_FINISH:
> > + if (mctp->len < sizeof(MCTPI2CPacket) + 1) {
> > + trace_i2c_mctp_drop_short_packet(mctp->len);
> > + goto drop;
> > + }
> > +
> > + payload_len = mctp->len - (1 + offsetof(MCTPI2CPacket, mctp.payload));
> > +
> > + if (pkt->i2c.byte_count + 3 != mctp->len - 1) {
> > + trace_i2c_mctp_drop_invalid_length(pkt->i2c.byte_count + 3,
> > + mctp->len - 1);
> > + goto drop;
> > + }
> > +
> > + pec = i2c_smbus_pec(0, mctp->buffer, mctp->len - 1);
> > + if (mctp->buffer[mctp->len - 1] != pec) {
> > + trace_i2c_mctp_drop_invalid_pec(mctp->buffer[mctp->len - 1], pec);
> > + goto drop;
> > + }
> > +
> > + if (!(pkt->mctp.hdr.eid.dest == mctp->my_eid ||
> > + pkt->mctp.hdr.eid.dest == 0)) {
> > + trace_i2c_mctp_drop_invalid_eid(pkt->mctp.hdr.eid.dest,
> > + mctp->my_eid);
> > + goto drop;
> > + }
> > +
> > + pktseq = FIELD_EX8(pkt->mctp.hdr.flags, MCTP_H_FLAGS, PKTSEQ);
> > +
> > + if (FIELD_EX8(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 >> 1;
> > + mctp->tx.eid = pkt->mctp.hdr.eid.source;
> > + mctp->tx.tag = FIELD_EX8(pkt->mctp.hdr.flags, MCTP_H_FLAGS, TAG);
> > + mctp->tx.pktseq = pktseq;
> > +
> > + msgtype = FIELD_EX8(pkt->mctp.payload[0], MCTP_MESSAGE_H, TYPE);
> > +
> > + if (msgtype == 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 (pktseq != (++mctp->tx.pktseq & 0x3)) {
> > + trace_i2c_mctp_drop_invalid_pktseq(pktseq, mctp->tx.pktseq & 0x3);
> > + goto drop;
> > + }
> > +
> > + mc->put_buf(mctp, i2c_mctp_payload(mctp->buffer), payload_len);
>
> Given this returns -1 on error should probably handle errors.
>
Yes.
The event callback should only potentially return -1 in the case of
I2C_START_SEND, so I just do a `goto drop` here.
>
> > +
> > + if (FIELD_EX8(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..fccbf249cdbe
> > --- /dev/null
> > +++ b/include/hw/i2c/mctp.h
> > @@ -0,0 +1,127 @@
> > +#ifndef QEMU_I2C_MCTP_H
> > +#define QEMU_I2C_MCTP_H
> > +
> > +#include "qom/object.h"
> > +#include "hw/qdev-core.h"
> > +
> > +#define TYPE_MCTP_I2C_ENDPOINT "mctp-i2c-endpoint"
> > +OBJECT_DECLARE_TYPE(MCTPI2CEndpoint, MCTPI2CEndpointClass, MCTP_I2C_ENDPOINT)
> > +
> > +struct MCTPI2CEndpointClass {
> > + I2CSlaveClass parent_class;
> > +
> > + /**
> > + *
>
> Drop the blank line for consistency with the other comments.
>
> > + * put_buf() - receive incoming message fragment
> > + *
> > + * Must returns 0 for succes or -1 for error.
>
> I would expect any negative to count as error rather than just -1.
> Also, simple imperative should be clear enough
> * Return 0 for success or negative 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.
> Subsequent call with return next fragment.
>
> Up to the implementation to decide how it does this.
>
> > + *
> > + * Must return the number of bytes available.
> Return number of bytes in message fragment.
>
> Available might mean in all fragments.
>
Thanks for these suggestions, I worked that in.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2023-09-04 10:50 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-23 9:21 [PATCH v4 0/3] hw/{i2c,nvme}: mctp endpoint, nvme management interface model Klaus Jensen
2023-08-23 9:21 ` [PATCH v4 1/3] hw/i2c: add smbus pec utility function Klaus Jensen
2023-08-30 13:04 ` Jonathan Cameron via
2023-08-30 13:04 ` Jonathan Cameron via
2023-08-23 9:21 ` [PATCH v4 2/3] hw/i2c: add mctp core Klaus Jensen
2023-08-30 14:31 ` Jonathan Cameron via
2023-09-04 10:49 ` Klaus Jensen [this message]
2023-08-23 9:22 ` [PATCH v4 3/3] hw/nvme: add nvme management interface model Klaus Jensen
2023-08-30 14:47 ` Jonathan Cameron via
2023-08-30 14:47 ` Jonathan Cameron via
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=ZPW2MFWp6mIvReS5@cormorant.local \
--to=its@irrelevant.dk \
--cc=Jonathan.Cameron@huawei.com \
--cc=cminyard@mvista.com \
--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 \
--cc=qemu-devel@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 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.