From: Wolfram Sang <wsa@kernel.org>
To: Matt Johnston <matt@codeconstruct.com.au>
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: Wed, 16 Feb 2022 17:15:46 +0100 [thread overview]
Message-ID: <Yg0jMkt56EhrBybc@ninjato> (raw)
In-Reply-To: <20220210063651.798007-3-matt@codeconstruct.com.au>
[-- Attachment #1: Type: text/plain, Size: 2603 bytes --]
Hi Matt, all,
On Thu, Feb 10, 2022 at 02:36:51PM +0800, Matt Johnston wrote:
> Provides MCTP network transport over an I2C bus, as specified in
> DMTF DSP0237. All messages between nodes are sent as SMBus Block Writes.
>
> Each I2C bus to be used for MCTP is flagged in devicetree by a
> 'mctp-controller' property on the bus node. Each flagged bus gets a
> mctpi2cX net device created based on the bus number. A
> 'mctp-i2c-controller' I2C client needs to be added under the adapter. In
> an I2C mux situation the mctp-i2c-controller node must be attached only
> to the root I2C bus. The I2C client will handle incoming I2C slave block
> write data for subordinate busses as well as its own bus.
>
> In configurations without devicetree a driver instance can be attached
> to a bus using the I2C slave new_device mechanism.
>
> The MCTP core will hold/release the MCTP I2C device while responses
> are pending (a 6 second timeout or once a socket is closed, response
> received etc). While held the MCTP I2C driver will lock the I2C bus so
> that the correct I2C mux remains selected while responses are received.
>
> (Ideally we would just lock the mux to keep the current bus selected for
> the response rather than a full I2C bus lock, but that isn't exposed in
> the I2C mux API)
>
> Signed-off-by: Matt Johnston <matt@codeconstruct.com.au>
> Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au>
So, I did a high level review regardings the I2C stuff. I did not check
locking, device lifetime, etc. My biggest general remark is the mixture
of multi-comment styles, like C++ style or no empty "/*" at the
beginning as per Kernel coding style. Some functions have nice
explanations in the header but not proper kdoc formatting. And also on
the nitbit side, I don't think '__func__' helps here on the error
messages. But that's me, I'll leave it to the netdev maintainers.
Now for the I2C part. It looks good. I have only one remark:
> +static const struct i2c_device_id mctp_i2c_id[] = {
> + { "mctp-i2c", 0 },
> + {},
> +};
> +MODULE_DEVICE_TABLE(i2c, mctp_i2c_id);
...
> +static struct i2c_driver mctp_i2c_driver = {
> + .driver = {
> + .name = "mctp-i2c",
> + .of_match_table = mctp_i2c_of_match,
> + },
> + .probe_new = mctp_i2c_probe,
> + .remove = mctp_i2c_remove,
> + .id_table = mctp_i2c_id,
> +};
I'd suggest to add 'slave' to the 'mctp-i2c' string somewhere to make it
easily visible that this driver does not manage a remote device but
processes requests to its own address.
Thanks for the work!
Wolfram
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2022-02-16 16:16 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 [this message]
2022-02-17 7:39 ` Matt Johnston
2022-02-17 8:58 ` Wolfram Sang
2022-02-17 9:22 ` Matt Johnston
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=Yg0jMkt56EhrBybc@ninjato \
--to=wsa@kernel.org \
--cc=davem@davemloft.net \
--cc=jk@codeconstruct.com.au \
--cc=kuba@kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=matt@codeconstruct.com.au \
--cc=netdev@vger.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 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.