All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wolfram Sang <wsa@kernel.org>
To: Alain Volmat <alain.volmat@st.com>,
	Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: robh+dt@kernel.org, mark.rutland@arm.com,
	pierre-yves.mordret@st.com, mcoquelin.stm32@gmail.com,
	alexandre.torgue@st.com, linux-i2c@vger.kernel.org,
	devicetree@vger.kernel.org,
	linux-stm32@st-md-mailman.stormreply.com,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, fabrice.gasnier@st.com
Subject: Re: [PATCH 1/4] i2c: smbus: add core function handling SMBus host-notify
Date: Sat, 23 May 2020 12:46:25 +0200	[thread overview]
Message-ID: <20200523104624.GB3459@ninjato> (raw)
In-Reply-To: <1588657871-14747-2-git-send-email-alain.volmat@st.com>

[-- Attachment #1: Type: text/plain, Size: 2278 bytes --]


Adding Benjamin who mainly implemented this.

On Tue, May 05, 2020 at 07:51:08AM +0200, Alain Volmat wrote:
> SMBus Host-Notify protocol, from the adapter point of view
> consist of receiving a message from a client, including the
> client address and some other data.
> 
> It can be simply handled by creating a new slave device
> and registering a callback performing the parsing of the
> message received from the client.
> 
> This commit introduces two new core functions
>   * i2c_new_smbus_host_notify_device
>   * i2c_free_smbus_host_notify_device
> that take care of registration of the new slave device and
> callback and will call i2c_handle_smbus_host_notify once a
> Host-Notify event is received.

Yay, cool idea to use the slave interface. I like it a lot!

> +static int i2c_smbus_host_notify_cb(struct i2c_client *client,
> +				    enum i2c_slave_event event, u8 *val)
> +{
> +	struct i2c_smbus_host_notify_status *status = client->dev.platform_data;
> +	int ret;
> +
> +	switch (event) {
> +	case I2C_SLAVE_WRITE_REQUESTED:
> +		status->notify_start = true;
> +		break;
> +	case I2C_SLAVE_WRITE_RECEIVED:
> +		/* We only retrieve the first byte received (addr)
> +		 * since there is currently no way to retrieve the data
> +		 * parameter from the client.

Maybe s/no way/no support/ ? I still wonder if we couldn't add it
somehow. Once we find a device which needs this, of course.

> +		 */
> +		if (!status->notify_start)
> +			break;
> +		status->addr = *val;
> +		status->notify_start = false;
> +		break;
> +	case I2C_SLAVE_STOP:

What about setting 'notify_start' to false here as well? In the case of
an incomplete write?

> +		ret = i2c_handle_smbus_host_notify(client->adapter,
> +						   status->addr);
> +		if (ret < 0) {
> +			dev_warn(&client->adapter->dev, "failed to handle host_notify (%d)\n",
> +				ret);

I think we should rather add such error strings to the core if we think
they are needed. I am not convinced they are, though.

> +			return ret;
> +		}
> +		break;
> +	default:
> +		/* Only handle necessary events */
> +		break;
> +	}
> +
> +	return 0;
> +}
> +

Rest of the code looks good. Maybe we should compile all this only when
I2C_SLAVE is enabled?


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Wolfram Sang <wsa@kernel.org>
To: Alain Volmat <alain.volmat@st.com>,
	Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
	alexandre.torgue@st.com, linux-kernel@vger.kernel.org,
	pierre-yves.mordret@st.com, robh+dt@kernel.org,
	linux-i2c@vger.kernel.org, mcoquelin.stm32@gmail.com,
	fabrice.gasnier@st.com, linux-stm32@st-md-mailman.stormreply.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/4] i2c: smbus: add core function handling SMBus host-notify
Date: Sat, 23 May 2020 12:46:25 +0200	[thread overview]
Message-ID: <20200523104624.GB3459@ninjato> (raw)
In-Reply-To: <1588657871-14747-2-git-send-email-alain.volmat@st.com>


[-- Attachment #1.1: Type: text/plain, Size: 2278 bytes --]


Adding Benjamin who mainly implemented this.

On Tue, May 05, 2020 at 07:51:08AM +0200, Alain Volmat wrote:
> SMBus Host-Notify protocol, from the adapter point of view
> consist of receiving a message from a client, including the
> client address and some other data.
> 
> It can be simply handled by creating a new slave device
> and registering a callback performing the parsing of the
> message received from the client.
> 
> This commit introduces two new core functions
>   * i2c_new_smbus_host_notify_device
>   * i2c_free_smbus_host_notify_device
> that take care of registration of the new slave device and
> callback and will call i2c_handle_smbus_host_notify once a
> Host-Notify event is received.

Yay, cool idea to use the slave interface. I like it a lot!

> +static int i2c_smbus_host_notify_cb(struct i2c_client *client,
> +				    enum i2c_slave_event event, u8 *val)
> +{
> +	struct i2c_smbus_host_notify_status *status = client->dev.platform_data;
> +	int ret;
> +
> +	switch (event) {
> +	case I2C_SLAVE_WRITE_REQUESTED:
> +		status->notify_start = true;
> +		break;
> +	case I2C_SLAVE_WRITE_RECEIVED:
> +		/* We only retrieve the first byte received (addr)
> +		 * since there is currently no way to retrieve the data
> +		 * parameter from the client.

Maybe s/no way/no support/ ? I still wonder if we couldn't add it
somehow. Once we find a device which needs this, of course.

> +		 */
> +		if (!status->notify_start)
> +			break;
> +		status->addr = *val;
> +		status->notify_start = false;
> +		break;
> +	case I2C_SLAVE_STOP:

What about setting 'notify_start' to false here as well? In the case of
an incomplete write?

> +		ret = i2c_handle_smbus_host_notify(client->adapter,
> +						   status->addr);
> +		if (ret < 0) {
> +			dev_warn(&client->adapter->dev, "failed to handle host_notify (%d)\n",
> +				ret);

I think we should rather add such error strings to the core if we think
they are needed. I am not convinced they are, though.

> +			return ret;
> +		}
> +		break;
> +	default:
> +		/* Only handle necessary events */
> +		break;
> +	}
> +
> +	return 0;
> +}
> +

Rest of the code looks good. Maybe we should compile all this only when
I2C_SLAVE is enabled?


[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2020-05-23 10:46 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-05  5:51 [PATCH 0/4] stm32-f7: Addition of SMBus Alert / Host-notify features Alain Volmat
2020-05-05  5:51 ` Alain Volmat
2020-05-05  5:51 ` [PATCH 1/4] i2c: smbus: add core function handling SMBus host-notify Alain Volmat
2020-05-05  5:51   ` Alain Volmat
2020-05-11  8:26   ` Pierre Yves MORDRET
2020-05-11  8:26     ` Pierre Yves MORDRET
2020-05-23 10:46   ` Wolfram Sang [this message]
2020-05-23 10:46     ` Wolfram Sang
2020-05-26 10:23     ` Alain Volmat
2020-05-26 10:23       ` Alain Volmat
2020-05-05  5:51 ` [PATCH 2/4] i2c: addition of client reg/unreg callbacks Alain Volmat
2020-05-05  5:51   ` Alain Volmat
2020-05-11  8:28   ` Pierre Yves MORDRET
2020-05-11  8:28     ` Pierre Yves MORDRET
2020-05-23 10:49   ` Wolfram Sang
2020-05-23 10:49     ` Wolfram Sang
2020-05-05  5:51 ` [PATCH 3/4] dt-bindings: i2c-stm32: add SMBus Alert bindings Alain Volmat
2020-05-05  5:51   ` Alain Volmat
2020-05-13  2:19   ` Rob Herring
2020-05-13  2:19     ` Rob Herring
2020-05-13  5:42     ` Alain Volmat
2020-05-13  5:42       ` Alain Volmat
2020-05-18 10:53       ` Alain Volmat
2020-05-18 10:53         ` Alain Volmat
2020-05-23 10:36       ` wsa
2020-05-23 10:36         ` wsa
2020-05-26 10:31         ` Alain Volmat
2020-05-26 10:31           ` Alain Volmat
2020-05-05  5:51 ` [PATCH 4/4] i2c: stm32f7: Add SMBus-specific protocols support Alain Volmat
2020-05-05  5:51   ` Alain Volmat
2020-05-11  8:27   ` Pierre Yves MORDRET
2020-05-11  8:27     ` Pierre Yves MORDRET
2020-05-23 11:01   ` Wolfram Sang
2020-05-23 11:01     ` Wolfram Sang
2020-05-26 10:39     ` Alain Volmat
2020-05-26 10:39       ` Alain Volmat
2020-06-30  6:40       ` Wolfram Sang
2020-06-30  6:40         ` Wolfram Sang
2020-06-30  9:31         ` Alain Volmat
2020-06-30  9:31           ` Alain Volmat
2020-06-30 15:11           ` Wolfram Sang
2020-06-30 15:11             ` Wolfram Sang

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=20200523104624.GB3459@ninjato \
    --to=wsa@kernel.org \
    --cc=alain.volmat@st.com \
    --cc=alexandre.torgue@st.com \
    --cc=benjamin.tissoires@redhat.com \
    --cc=devicetree@vger.kernel.org \
    --cc=fabrice.gasnier@st.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=mark.rutland@arm.com \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=pierre-yves.mordret@st.com \
    --cc=robh+dt@kernel.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.