Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1410067 > unrolled thread

[PATCH v7 0/4] i2c-smbus: add support for HOST NOTIFY

Back to article view | Back to linux.kernel

Contents

  [PATCH v7 0/4] i2c-smbus: add support for HOST NOTIFY Benjamin Tissoires <benjamin.tissoires@redhat.com> - 2016-05-31 12:10 +0200
    [PATCH v7 1/4] i2c: add a protocol parameter to the alert callback Benjamin Tissoires <benjamin.tissoires@redhat.com> - 2016-05-31 12:10 +0200
      Re: [PATCH v7 1/4] i2c: add a protocol parameter to the alert  callback Wolfram Sang <wsa@the-dreams.de> - 2016-06-05 09:20 +0200
    Re: [PATCH v7 0/4] i2c-smbus: add support for HOST NOTIFY Wolfram Sang <wsa@the-dreams.de> - 2016-06-05 09:20 +0200
      Re: [PATCH v7 0/4] i2c-smbus: add support for HOST NOTIFY Benjamin Tissoires <benjamin.tissoires@redhat.com> - 2016-06-07 16:10 +0200
        Re: [PATCH v7 0/4] i2c-smbus: add support for HOST NOTIFY Wolfram Sang <wsa@the-dreams.de> - 2016-06-07 16:20 +0200

#1410067 — [PATCH v7 0/4] i2c-smbus: add support for HOST NOTIFY

Hi,

this is mostly a resubmission of the v6 with the acks, tested-by and few typos
here and there.

We really need this to be integrated in the kernel to be able to finally
support the touchpads found in many laptops (such as the Lenovo Thinkpad series,
some HPs, and probably many others). Currently those laptops are running the
fallback mechanism over PS/2 which is full of bugs as it has not been given
the same QA than the RMI4 over SMBus (Windows uses RMI4 over SMBus).

RMI4 is now in Linus' tree since v4.6, so it would be nice to see Host Notify
in the I2C tree as well.

Cheers,
Benjamin

Benjamin Tissoires (4):
  i2c: add a protocol parameter to the alert callback
  i2c-smbus: add SMBus Host Notify support
  i2c: i801: add support of Host Notify
  Input: synaptics-rmi4 - add SMBus support

 Documentation/i2c/smbus-protocol |   3 +
 drivers/char/ipmi/ipmi_ssif.c    |   6 +-
 drivers/hwmon/lm90.c             |   6 +-
 drivers/i2c/busses/Kconfig       |   1 +
 drivers/i2c/busses/i2c-i801.c    |  85 ++++++-
 drivers/i2c/i2c-smbus.c          | 112 +++++++++-
 drivers/input/rmi4/Kconfig       |  12 +
 drivers/input/rmi4/Makefile      |   1 +
 drivers/input/rmi4/rmi_bus.h     |  12 +
 drivers/input/rmi4/rmi_smbus.c   | 470 +++++++++++++++++++++++++++++++++++++++
 include/linux/i2c-smbus.h        |  44 ++++
 include/linux/i2c.h              |  10 +-
 include/uapi/linux/i2c.h         |   1 +
 13 files changed, 753 insertions(+), 10 deletions(-)
 create mode 100644 drivers/input/rmi4/rmi_smbus.c

-- 
2.5.0

[toc] | [next] | [standalone]

#1410069 — [PATCH v7 1/4] i2c: add a protocol parameter to the alert callback

.alert() is meant to be generic, but there is currently no way
for the device driver to know which protocol generated the alert.
Add a parameter in .alert() to help the device driver to understand
what is given in data.

This patch is required to have the support of SMBus Host Notify protocol
through .alert().

Tested-by: Andrew Duggan <aduggan@synaptics.com
For hwmon:
Acked-by: Guenter Roeck <linux@roeck-us.net>
For IPMI:
Acked-by: Corey Minyard <cminyard@mvista.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---

new in v2

changes in v3:
- added also lm90.c to support the new API
 
no changes in v4
 
no changes in v5

changes in v6:
- made sure lm90 also checks for the type of alert first

no changes in v7

 drivers/char/ipmi/ipmi_ssif.c | 6 +++++-
 drivers/hwmon/lm90.c          | 6 +++++-
 drivers/i2c/i2c-smbus.c       | 3 ++-
 include/linux/i2c.h           | 7 ++++++-
 4 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/drivers/char/ipmi/ipmi_ssif.c b/drivers/char/ipmi/ipmi_ssif.c
index 8b3be8b..10a2365 100644
--- a/drivers/char/ipmi/ipmi_ssif.c
+++ b/drivers/char/ipmi/ipmi_ssif.c
@@ -568,12 +568,16 @@ static void retry_timeout(unsigned long data)
 }
 
 
-static void ssif_alert(struct i2c_client *client, unsigned int data)
+static void ssif_alert(struct i2c_client *client, enum i2c_alert_protocol type,
+		       unsigned int data)
 {
 	struct ssif_info *ssif_info = i2c_get_clientdata(client);
 	unsigned long oflags, *flags;
 	bool do_get = false;
 
+	if (type != I2C_PROTOCOL_SMBUS_ALERT)
+		return;
+
 	ssif_inc_stat(ssif_info, alerts);
 
 	flags = ipmi_ssif_lock_cond(ssif_info, &oflags);
diff --git a/drivers/hwmon/lm90.c b/drivers/hwmon/lm90.c
index c9ff08d..a00fd38 100644
--- a/drivers/hwmon/lm90.c
+++ b/drivers/hwmon/lm90.c
@@ -1624,10 +1624,14 @@ static int lm90_remove(struct i2c_client *client)
 	return 0;
 }
 
-static void lm90_alert(struct i2c_client *client, unsigned int flag)
+static void lm90_alert(struct i2c_client *client, enum i2c_alert_protocol type,
+		       unsigned int flag)
 {
 	u16 alarms;
 
+	if (type != I2C_PROTOCOL_SMBUS_ALERT)
+		return;
+
 	if (lm90_is_tripped(client, &alarms)) {
 		/*
 		 * Disable ALERT# output, because these chips don't implement
diff --git a/drivers/i2c/i2c-smbus.c b/drivers/i2c/i2c-smbus.c
index abb55d3..3b6765a 100644
--- a/drivers/i2c/i2c-smbus.c
+++ b/drivers/i2c/i2c-smbus.c
@@ -56,7 +56,8 @@ static int smbus_do_alert(struct device *dev, void *addrp)
 	if (client->dev.driver) {
 		driver = to_i2c_driver(client->dev.driver);
 		if (driver->alert)
-			driver->alert(client, data->flag);
+			driver->alert(client, I2C_PROTOCOL_SMBUS_ALERT,
+				      data->flag);
 		else
 			dev_warn(&client->dev, "no driver alert()!\n");
 	} else
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index 200cf13b..baae02a 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -126,6 +126,10 @@ i2c_smbus_read_i2c_block_data_or_emulated(const struct i2c_client *client,
 					  u8 command, u8 length, u8 *values);
 #endif /* I2C */
 
+enum i2c_alert_protocol {
+	I2C_PROTOCOL_SMBUS_ALERT,
+};
+
 /**
  * struct i2c_driver - represent an I2C device driver
  * @class: What kind of i2c device we instantiate (for detect)
@@ -181,7 +185,8 @@ struct i2c_driver {
 	 * For the SMBus alert protocol, there is a single bit of data passed
 	 * as the alert response's low bit ("event flag").
 	 */
-	void (*alert)(struct i2c_client *, unsigned int data);
+	void (*alert)(struct i2c_client *, enum i2c_alert_protocol protocol,
+		      unsigned int data);
 
 	/* a ioctl like command that can be used to perform specific functions
 	 * with the device.
-- 
2.5.0

[toc] | [prev] | [next] | [standalone]

#1413943 — Re: [PATCH v7 1/4] i2c: add a protocol parameter to the alert callback

[Multipart message — attachments visible in raw view] — view raw

On Tue, May 31, 2016 at 12:03:02PM +0200, Benjamin Tissoires wrote:
> .alert() is meant to be generic, but there is currently no way
> for the device driver to know which protocol generated the alert.
> Add a parameter in .alert() to help the device driver to understand
> what is given in data.
> 
> This patch is required to have the support of SMBus Host Notify protocol
> through .alert().
> 
> Tested-by: Andrew Duggan <aduggan@synaptics.com

Checkpatch gives an error on this broken email address!

[toc] | [prev] | [next] | [standalone]

#1413942

[Multipart message — attachments visible in raw view] — view raw

Hi Benjamin,

> this is mostly a resubmission of the v6 with the acks, tested-by and few typos
> here and there.

I actually reviewed v6 but got an NMI so writing the mails fell through
the cracks :( Sorry about that! Good news is that the code is fine from
my point of view, some documentation updates I'd request. After updating
those, I will pick up the core patches right away. Note that while the
i801 patch looks good to me, I need Jean's review here. There are other
patches pending for i801, that needs to be coordinated by him.

Thanks,

   Wolfram

[toc] | [prev] | [next] | [standalone]

#1416235

Hi Wolfram,

On Jun 05 2016 or thereabouts, Wolfram Sang wrote:
> Hi Benjamin,
> 
> > this is mostly a resubmission of the v6 with the acks, tested-by and few typos
> > here and there.
> 
> I actually reviewed v6 but got an NMI so writing the mails fell through
> the cracks :( Sorry about that! Good news is that the code is fine from
> my point of view, some documentation updates I'd request. After updating
> those, I will pick up the core patches right away. Note that while the

Great, many thanks!
The documentation fixes look simple enough to do. However, I just
realized a conflict in the i801 which requires tests (in the resume
call).

> i801 patch looks good to me, I need Jean's review here. There are other
> patches pending for i801, that needs to be coordinated by him.

OK. I'll try to fetch those pending patches on patchwork and see how the
merge would behave.

Cheers,
Benjamin

> 
> Thanks,
> 
>    Wolfram
> 

[toc] | [prev] | [next] | [standalone]

#1416253

[Multipart message — attachments visible in raw view] — view raw

> OK. I'll try to fetch those pending patches on patchwork and see how the
> merge would behave.

Thanks. If you have time for a bit of a reviewing eye on them, this
would also be much appreciated :)

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web