From: Matt Johnston <matt@codeconstruct.com.au>
To: Wolfram Sang <wsa@kernel.org>
Cc: "David S . Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
Jeremy Kerr <jk@codeconstruct.com.au>,
linux-i2c@vger.kernel.org, netdev@vger.kernel.org,
Zev Weiss <zev@bewilderbeest.net>
Subject: Re: [PATCH net-next v5 2/2] mctp i2c: MCTP I2C binding driver
Date: Thu, 17 Feb 2022 17:22:13 +0800 [thread overview]
Message-ID: <5c2673ed11ad764764998e1244a59f0c8c1cb2da.camel@codeconstruct.com.au> (raw)
In-Reply-To: <Yg4N1SYeCdSPDR+V@ninjato>
On Thu, 2022-02-17 at 09:58 +0100, Wolfram Sang wrote:
> > I think 'slave' might be a bit unclear - the driver's acting as an I2C master
> > too.
>
> Right. Yet, AFAIU only when sending responses to other nodes, or? It
> does not drive this one remote device with address 0xNN but acts itself
> as device 0xMM.
The Linux mctp-i2c endpoint (0xMM) can send MCTP messages to any I2C node
(0xNN), as a block write master->slave. The MCTP I2C transport is
bidirectional - either side can send the first message, all messages are
block writes. (Hopefully I've understood your question)
Most higher level protocols on top of MCTP are request/response style, though
it isn't inherent. The mctp-i2c driver is mostly stateless, but it in order
to deal with i2c muxes the MCTP stack has a concept of "flows" so that it
will keep a bus locked for replies after sending out a request (with timeout)
- that matches how higher level protocols expect to work.
> Oh, and one other question I have meanwhile: do you really need
> "mctp_current_mux" as a device attribute or is it mere debug and could
> go away when upstream?
Yes, it's really only useful for debugging since it could be outdated by the
time it is read. I'll remove it, we could add something more robust if people
had a need.
Cheers,
Matt
prev parent reply other threads:[~2022-02-17 9:22 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-10 6:36 [PATCH net-next v5 0/2] MCTP I2C driver Matt Johnston
2022-02-10 6:36 ` [PATCH net-next v5 1/2] dt-bindings: net: New binding mctp-i2c-controller Matt Johnston
2022-02-10 14:41 ` Rob Herring
2022-02-16 15:54 ` Wolfram Sang
2022-02-10 6:36 ` [PATCH net-next v5 2/2] mctp i2c: MCTP I2C binding driver Matt Johnston
2022-02-11 22:38 ` Jakub Kicinski
2022-02-15 4:22 ` Matt Johnston
2022-02-15 5:04 ` Jakub Kicinski
2022-02-15 10:01 ` Matt Johnston
2022-02-15 15:58 ` Jakub Kicinski
2022-02-16 16:15 ` Wolfram Sang
2022-02-17 7:39 ` Matt Johnston
2022-02-17 8:58 ` Wolfram Sang
2022-02-17 9:22 ` Matt Johnston [this message]
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=5c2673ed11ad764764998e1244a59f0c8c1cb2da.camel@codeconstruct.com.au \
--to=matt@codeconstruct.com.au \
--cc=davem@davemloft.net \
--cc=jk@codeconstruct.com.au \
--cc=kuba@kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=wsa@kernel.org \
--cc=zev@bewilderbeest.net \
/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).