All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron via <qemu-arm@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)
> > +  
> 
> 


WARNING: multiple messages have this Message-ID (diff)
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)
> > +  
> 
> 



  reply	other threads:[~2023-05-31 15:04 UTC|newest]

Thread overview: 14+ 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-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 14:59     ` Jonathan Cameron via
2023-05-31 15:04     ` Jonathan Cameron via [this message]
2023-05-31 15:04       ` Jonathan Cameron via
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-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-arm@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-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.