[PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Pali Rohár]

Dell platform team told us that some (DMI whitelisted) Dell Latitude
machines have ST microelectronics accelerometer at i2c address 0x29. That
i2c address is not specified in DMI or ACPI, so runtime detection without
whitelist which is below is not possible.

Presence of that ST microelectronics accelerometer is verified by existence
of SMO88xx ACPI device which represent that accelerometer. Unfortunately
without i2c address.

This patch registers lis3lv02d device at i2c address 0x29 if is detected.

Finally commit a7ae81952cda ("i2c: i801: Allow ACPI SystemIO OpRegion to
conflict with PCI BAR") allowed to use i2c-i801 driver on Dell machines so
lis3lv02d correctly initialize accelerometer.

Tested on Dell Latitude E6440.

Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
---
 drivers/i2c/busses/i2c-i801.c |   98 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 98 insertions(+)

diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
index eb3627f..188cfd4 100644
--- a/drivers/i2c/busses/i2c-i801.c
+++ b/drivers/i2c/busses/i2c-i801.c
@@ -1118,6 +1118,101 @@ static void dmi_check_onboard_devices(const struct dmi_header *dm, void *adap)
 	}
 }
 
+static acpi_status check_acpi_smo88xx_device(acpi_handle obj_handle,
+					     u32 nesting_level,
+					     void *context,
+					     void **return_value)
+{
+	struct acpi_device_info *info;
+	acpi_status status;
+	char *hid;
+
+	status = acpi_get_object_info(obj_handle, &info);
+	if (!ACPI_SUCCESS(status) || !(info->valid & ACPI_VALID_HID))
+		return AE_OK;
+
+	hid = info->hardware_id.string;
+	if (!hid)
+		return AE_OK;
+
+	if (strlen(hid) < 7)
+		return AE_OK;
+
+	if (memcmp(hid, "SMO88", 5) != 0)
+		return AE_OK;
+
+	*((bool *)return_value) = true;
+	return AE_CTRL_TERMINATE;
+}
+
+static bool is_dell_system_with_lis3lv02d(void)
+{
+	bool found;
+	acpi_status status;
+	const char *vendor;
+
+	vendor = dmi_get_system_info(DMI_SYS_VENDOR);
+	if (strcmp(vendor, "Dell Inc.") != 0)
+		return false;
+
+	/*
+	 * Check if ACPI device SMO88xx exists and if is enabled. That ACPI
+	 * device represent our ST microelectronics lis3lv02d accelerometer but
+	 * unfortunately without any other additional information.
+	 */
+	found = false;
+	status = acpi_get_devices(NULL, check_acpi_smo88xx_device, NULL,
+				  (void **)&found);
+	if (!ACPI_SUCCESS(status) || !found)
+		return false;
+
+	return true;
+}
+
+/*
+ * Dell platform team told us that these Latitude devices have
+ * ST microelectronics accelerometer at i2c address 0x29.
+ * That i2c address is not specified in DMI or ACPI, so runtime
+ * detection without whitelist which is below is not possible.
+ */
+static const char * const dmi_dell_product_names[] = {
+	"Latitude E5250",
+	"Latitude E5450",
+	"Latitude E5550",
+	"Latitude E6440",
+	"Latitude E6440 ATG",
+	"Latitude E6540",
+};
+
+static void register_dell_lis3lv02d_i2c_device(struct i801_priv *priv)
+{
+	struct i2c_board_info info;
+	const char *product_name;
+	bool known_i2c_address;
+	int i;
+
+	known_i2c_address = false;
+	product_name = dmi_get_system_info(DMI_PRODUCT_NAME);
+	for (i = 0; i < ARRAY_SIZE(dmi_dell_product_names); ++i) {
+		if (strcmp(product_name, dmi_dell_product_names[i]) == 0) {
+			known_i2c_address = true;
+			break;
+		}
+	}
+
+	if (!known_i2c_address) {
+		dev_warn(&priv->pci_dev->dev,
+			 "Accelerometer lis3lv02d i2c device is present "
+			 "but its i2c address is unknown, skipping ...\n");
+		return;
+	}
+
+	memset(&info, 0, sizeof(struct i2c_board_info));
+	info.addr = 0x29;
+	strlcpy(info.type, "lis3lv02d", I2C_NAME_SIZE);
+	i2c_new_device(&priv->adapter, &info);
+}
+
 /* Register optional slaves */
 static void i801_probe_optional_slaves(struct i801_priv *priv)
 {
@@ -1136,6 +1231,9 @@ static void i801_probe_optional_slaves(struct i801_priv *priv)
 
 	if (dmi_name_in_vendors("FUJITSU"))
 		dmi_walk(dmi_check_onboard_devices, &priv->adapter);
+
+	if (is_dell_system_with_lis3lv02d())
+		register_dell_lis3lv02d_i2c_device(priv);
 }
 #else
 static void __init input_apanel_init(void) {}
-- 
1.7.9.5

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Wolfram Sang]

> Dell platform team told us that some (DMI whitelisted) Dell Latitude
> machines have ST microelectronics accelerometer at i2c address 0x29. 
> That
> i2c address is not specified in DMI or ACPI, so runtime detection 
> without
> whitelist which is below is not possible.

I'd think this should rather live somewhere in
drivers/platform/x86/dell*.c?

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 814 bytes --]

On Tuesday 27 December 2016 14:43:49 Wolfram Sang wrote:
> > Dell platform team told us that some (DMI whitelisted) Dell
> > Latitude machines have ST microelectronics accelerometer at i2c
> > address 0x29. That
> > i2c address is not specified in DMI or ACPI, so runtime detection
> > without
> > whitelist which is below is not possible.
> 
> I'd think this should rather live somewhere in
> drivers/platform/x86/dell*.c?

i2c_new_device() with lis3lv02d for i801 i2c bus needs to be called 
after initializing i2c-i801 bus driver.

I have no idea how to do it (properly) outside of i2c-i801.c file.

Same thing is done for Fujitsu machines, see function 
i801_probe_optional_slaves() in i2c-i801.c file. So I did similar 
approach for Dell machines.

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Andy Shevchenko]

On Tue, Dec 27, 2016 at 3:51 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> On Tuesday 27 December 2016 14:43:49 Wolfram Sang wrote:
>> > Dell platform team told us that some (DMI whitelisted) Dell
>> > Latitude machines have ST microelectronics accelerometer at i2c
>> > address 0x29. That
>> > i2c address is not specified in DMI or ACPI, so runtime detection
>> > without
>> > whitelist which is below is not possible.
>>
>> I'd think this should rather live somewhere in
>> drivers/platform/x86/dell*.c?
>
> i2c_new_device() with lis3lv02d for i801 i2c bus needs to be called
> after initializing i2c-i801 bus driver.
>
> I have no idea how to do it (properly) outside of i2c-i801.c file.

I doubt we need a single line of code for this. See [1] and perhaps
create an EFI variable with necessary upgrade device node.

> Same thing is done for Fujitsu machines, see function
> i801_probe_optional_slaves() in i2c-i801.c file. So I did similar
> approach for Dell machines.

Perhaps, this also needs to be converted to use EFI variable.

[1] https://lwn.net/Articles/693212/

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Valdis.Kletnieks]

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

On Wed, 28 Dec 2016 00:15:30 +0200, Andy Shevchenko said:
> On Tue, Dec 27, 2016 at 3:51 PM, Pali Rohár <pali.rohar@gmail.com> wrote:

> > I have no idea how to do it (properly) outside of i2c-i801.c file.
>
> I doubt we need a single line of code for this. See [1] and perhaps
> create an EFI variable with necessary upgrade device node.
>
> > Same thing is done for Fujitsu machines, see function
> > i801_probe_optional_slaves() in i2c-i801.c file. So I did similar
> > approach for Dell machines.
>
> Perhaps, this also needs to be converted to use EFI variable.
>
> [1] https://lwn.net/Articles/693212/

There's no guarantee that the laptops in question are booted with UEFI,
as Dell still supports legacy boot. So assuming the presence of EFI variables
is somewhat problematic.

In addition, it requires the user (or something in userspace) to set the UEFI
variable or configfs tweak, rather than Just Working Out Of The Box.


[-- Attachment #2: Type: application/pgp-signature, Size: 484 bytes --]

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Andy Shevchenko]

On Wed, Dec 28, 2016 at 12:41 AM,  <Valdis.Kletnieks@vt.edu> wrote:
> On Wed, 28 Dec 2016 00:15:30 +0200, Andy Shevchenko said:
>> On Tue, Dec 27, 2016 at 3:51 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
>
>> > I have no idea how to do it (properly) outside of i2c-i801.c file.
>>
>> I doubt we need a single line of code for this. See [1] and perhaps
>> create an EFI variable with necessary upgrade device node.
>>
>> > Same thing is done for Fujitsu machines, see function
>> > i801_probe_optional_slaves() in i2c-i801.c file. So I did similar
>> > approach for Dell machines.
>>
>> Perhaps, this also needs to be converted to use EFI variable.
>>
>> [1] https://lwn.net/Articles/693212/
>
> There's no guarantee that the laptops in question are booted with UEFI,
> as Dell still supports legacy boot. So assuming the presence of EFI variables
> is somewhat problematic.


> In addition, it requires the user (or something in userspace) to set the UEFI
> variable or configfs tweak, rather than Just Working Out Of The Box.

I have no strong opinion, though I don't support the idea to put all
hacks in the world to the kernel. For example, we have user space tool
to switch USB modem from storage to actual communication device and
that is just working out of the box.

Mika, Darren, what are your opinions?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 1813 bytes --]

On Wednesday 28 December 2016 08:55:18 Andy Shevchenko wrote:
> On Wed, Dec 28, 2016 at 12:41 AM,  <Valdis.Kletnieks@vt.edu> wrote:
> > On Wed, 28 Dec 2016 00:15:30 +0200, Andy Shevchenko said:
> >> On Tue, Dec 27, 2016 at 3:51 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> >
> >> > I have no idea how to do it (properly) outside of i2c-i801.c file.
> >>
> >> I doubt we need a single line of code for this. See [1] and perhaps
> >> create an EFI variable with necessary upgrade device node.
> >>
> >> > Same thing is done for Fujitsu machines, see function
> >> > i801_probe_optional_slaves() in i2c-i801.c file. So I did similar
> >> > approach for Dell machines.
> >>
> >> Perhaps, this also needs to be converted to use EFI variable.
> >>
> >> [1] https://lwn.net/Articles/693212/
> >
> > There's no guarantee that the laptops in question are booted with UEFI,
> > as Dell still supports legacy boot. So assuming the presence of EFI variables
> > is somewhat problematic.
> 
> 
> > In addition, it requires the user (or something in userspace) to set the UEFI
> > variable or configfs tweak, rather than Just Working Out Of The Box.
> 
> I have no strong opinion, though I don't support the idea to put all
> hacks in the world to the kernel. For example, we have user space tool
> to switch USB modem from storage to actual communication device and
> that is just working out of the box.
> 
> Mika, Darren, what are your opinions?

I have absolutely no idea how to you want to achieve calling that i2c_new_device() registration 
without kernel patches.

So before starting discussion which option to use (EFI, kernel patch, userspace script, etc...) 
please describe how would you implement such logic with different options.

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Wolfram Sang]

> I have absolutely no idea how to you want to achieve calling that 
> i2c_new_device() registration
> without kernel patches.

Documentation/i2c/instantiating-devices lists all supported methods.
Method 4 is userspace instantiation.

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Valdis.Kletnieks]

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

On Wed, 28 Dec 2016 15:03:02 +0100, Wolfram Sang said:
> > I have absolutely no idea how to you want to achieve calling that
> > i2c_new_device() registration
> > without kernel patches.
>
> Documentation/i2c/instantiating-devices lists all supported methods.
> Method 4 is userspace instantiation.

I'd be totally OK with userspace doing it, except for the question "How good
will distros be about shipping it"?  I don't have any sense of how good Fedora
and Ubuntu and so on will be about making sure the userspace part is already
done for the user.

Anybody got evidence one way or another?


[-- Attachment #2: Type: application/pgp-signature, Size: 484 bytes --]

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 1089 bytes --]

On Tuesday 27 December 2016 23:15:30 Andy Shevchenko wrote:
> On Tue, Dec 27, 2016 at 3:51 PM, Pali Rohár <pali.rohar@gmail.com>
> wrote:
> > On Tuesday 27 December 2016 14:43:49 Wolfram Sang wrote:
> >> > Dell platform team told us that some (DMI whitelisted) Dell
> >> > Latitude machines have ST microelectronics accelerometer at i2c
> >> > address 0x29. That
> >> > i2c address is not specified in DMI or ACPI, so runtime
> >> > detection without
> >> > whitelist which is below is not possible.
> >> 
> >> I'd think this should rather live somewhere in
> >> drivers/platform/x86/dell*.c?
> > 
> > i2c_new_device() with lis3lv02d for i801 i2c bus needs to be called
> > after initializing i2c-i801 bus driver.
> > 
> > I have no idea how to do it (properly) outside of i2c-i801.c file.
> 
> I doubt we need a single line of code for this. See [1] and perhaps
> create an EFI variable with necessary upgrade device node.

Sorry, but EFI variable is not accessible from BIOS booted kernel. So 
such thing will not work.

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Wolfram Sang]

On Tue, Dec 27, 2016 at 02:51:01PM +0100, Pali Rohár wrote:
> On Tuesday 27 December 2016 14:43:49 Wolfram Sang wrote:
> > > Dell platform team told us that some (DMI whitelisted) Dell
> > > Latitude machines have ST microelectronics accelerometer at i2c
> > > address 0x29. That
> > > i2c address is not specified in DMI or ACPI, so runtime detection
> > > without
> > > whitelist which is below is not possible.
> >
> > I'd think this should rather live somewhere in
> > drivers/platform/x86/dell*.c?
>
> i2c_new_device() with lis3lv02d for i801 i2c bus needs to be called
> after initializing i2c-i801 bus driver.
>
> I have no idea how to do it (properly) outside of i2c-i801.c file.

I once used bus_notifiers to achieve something similar. You could check
arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c to see an action
triggered once a client device got added, but you could act on another
action like BUS_NOTIFY_BOUND_DRIVER. I used exactly that, too, somewhen
somewhere.  Haven't checked if that helps here, too. And since we have 
a
precedence (Fujitsu case), I'll leave it to Jean who is the maintainer
of this driver.

Thanks,

    Wolfram

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Jean Delvare]

On Wed, 28 Dec 2016 15:02:52 +0100, Wolfram Sang wrote:
> On Tue, Dec 27, 2016 at 02:51:01PM +0100, Pali Rohár wrote:
> > i2c_new_device() with lis3lv02d for i801 i2c bus needs to be called
> > after initializing i2c-i801 bus driver.
> >
> > I have no idea how to do it (properly) outside of i2c-i801.c file.
> 
> I once used bus_notifiers to achieve something similar. You could check
> arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c to see an action
> triggered once a client device got added, but you could act on another
> action like BUS_NOTIFY_BOUND_DRIVER. I used exactly that, too, somewhen
> somewhere.  Haven't checked if that helps here, too. And since we have 
> a
> precedence (Fujitsu case), I'll leave it to Jean who is the maintainer
> of this driver.

I don't have a strong opinion on the matter, whatever works is fine
with me.

-- 
Jean Delvare
SUSE L3 Support

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Michał Kępień]

> Dell platform team told us that some (DMI whitelisted) Dell Latitude
> machines have ST microelectronics accelerometer at i2c address 0x29. That
> i2c address is not specified in DMI or ACPI, so runtime detection without
> whitelist which is below is not possible.
> 
> Presence of that ST microelectronics accelerometer is verified by existence
> of SMO88xx ACPI device which represent that accelerometer. Unfortunately
> without i2c address.

This part of the commit message sounded a bit confusing to me at first
because there is already an ACPI driver which handles SMO88xx devices
(dell-smo8800).  My understanding is that:

  * the purpose of this patch is to expose a richer interface (as
    provided by lis3lv02d) to these devices on some machines,

  * on whitelisted machines, dell-smo8800 and lis3lv02d can work
    simultaneously (even though dell-smo8800 effectively duplicates the
    work that lis3lv02d does).

If I got something wrong, please correct me.  If I got it right, it
might make sense to rephrase the commit message a bit so that the first
bullet point above is immediately clear to the reader.

> 
> This patch registers lis3lv02d device at i2c address 0x29 if is detected.
> 
> Finally commit a7ae81952cda ("i2c: i801: Allow ACPI SystemIO OpRegion to
> conflict with PCI BAR") allowed to use i2c-i801 driver on Dell machines so
> lis3lv02d correctly initialize accelerometer.
> 
> Tested on Dell Latitude E6440.
> 
> Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> ---
>  drivers/i2c/busses/i2c-i801.c |   98 +++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 98 insertions(+)
> 
> diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
> index eb3627f..188cfd4 100644
> --- a/drivers/i2c/busses/i2c-i801.c
> +++ b/drivers/i2c/busses/i2c-i801.c
> @@ -1118,6 +1118,101 @@ static void dmi_check_onboard_devices(const struct dmi_header *dm, void *adap)
>  	}
>  }
>  
> +static acpi_status check_acpi_smo88xx_device(acpi_handle obj_handle,
> +					     u32 nesting_level,
> +					     void *context,
> +					     void **return_value)
> +{
> +	struct acpi_device_info *info;
> +	acpi_status status;
> +	char *hid;
> +
> +	status = acpi_get_object_info(obj_handle, &info);

acpi_get_object_info() allocates the returned buffer, which the caller
has to free.

> +	if (!ACPI_SUCCESS(status) || !(info->valid & ACPI_VALID_HID))
> +		return AE_OK;
> +
> +	hid = info->hardware_id.string;
> +	if (!hid)
> +		return AE_OK;
> +
> +	if (strlen(hid) < 7)
> +		return AE_OK;
> +
> +	if (memcmp(hid, "SMO88", 5) != 0)
> +		return AE_OK;
> +
> +	*((bool *)return_value) = true;
> +	return AE_CTRL_TERMINATE;
> +}
> +
> +static bool is_dell_system_with_lis3lv02d(void)
> +{
> +	bool found;
> +	acpi_status status;
> +	const char *vendor;
> +
> +	vendor = dmi_get_system_info(DMI_SYS_VENDOR);
> +	if (strcmp(vendor, "Dell Inc.") != 0)
> +		return false;
> +
> +	/*
> +	 * Check if ACPI device SMO88xx exists and if is enabled. That ACPI
> +	 * device represent our ST microelectronics lis3lv02d accelerometer but
> +	 * unfortunately without any other additional information.
> +	 */
> +	found = false;
> +	status = acpi_get_devices(NULL, check_acpi_smo88xx_device, NULL,
> +				  (void **)&found);
> +	if (!ACPI_SUCCESS(status) || !found)
> +		return false;
> +
> +	return true;
> +}
> +
> +/*
> + * Dell platform team told us that these Latitude devices have
> + * ST microelectronics accelerometer at i2c address 0x29.
> + * That i2c address is not specified in DMI or ACPI, so runtime
> + * detection without whitelist which is below is not possible.
> + */
> +static const char * const dmi_dell_product_names[] = {
> +	"Latitude E5250",
> +	"Latitude E5450",
> +	"Latitude E5550",
> +	"Latitude E6440",
> +	"Latitude E6440 ATG",
> +	"Latitude E6540",
> +};
> +
> +static void register_dell_lis3lv02d_i2c_device(struct i801_priv *priv)
> +{
> +	struct i2c_board_info info;
> +	const char *product_name;
> +	bool known_i2c_address;
> +	int i;
> +
> +	known_i2c_address = false;
> +	product_name = dmi_get_system_info(DMI_PRODUCT_NAME);
> +	for (i = 0; i < ARRAY_SIZE(dmi_dell_product_names); ++i) {
> +		if (strcmp(product_name, dmi_dell_product_names[i]) == 0) {
> +			known_i2c_address = true;
> +			break;
> +		}
> +	}
> +
> +	if (!known_i2c_address) {
> +		dev_warn(&priv->pci_dev->dev,
> +			 "Accelerometer lis3lv02d i2c device is present "
> +			 "but its i2c address is unknown, skipping ...\n");

You are probably well aware of this, but checkpatch prefers keeping long
log messages in one line.  I am pointing it out just in case.

> +		return;
> +	}
> +
> +	memset(&info, 0, sizeof(struct i2c_board_info));

How about just doing "struct i2c_board_info info = { 0 };" instead?

> +	info.addr = 0x29;
> +	strlcpy(info.type, "lis3lv02d", I2C_NAME_SIZE);
> +	i2c_new_device(&priv->adapter, &info);
> +}
> +
>  /* Register optional slaves */
>  static void i801_probe_optional_slaves(struct i801_priv *priv)
>  {
> @@ -1136,6 +1231,9 @@ static void i801_probe_optional_slaves(struct i801_priv *priv)
>  
>  	if (dmi_name_in_vendors("FUJITSU"))
>  		dmi_walk(dmi_check_onboard_devices, &priv->adapter);
> +
> +	if (is_dell_system_with_lis3lv02d())
> +		register_dell_lis3lv02d_i2c_device(priv);
>  }
>  #else
>  static void __init input_apanel_init(void) {}
> -- 
> 1.7.9.5
> 

I tested this patch on a Vostro V131, which is not on the whitelist, so
all I got was the warning message, but to this extent, it works for me.

-- 
Best regards,
Michał Kępień

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 7708 bytes --]

On Thursday 29 December 2016 09:29:36 Michał Kępień wrote:
> > Dell platform team told us that some (DMI whitelisted) Dell
> > Latitude machines have ST microelectronics accelerometer at i2c
> > address 0x29. That i2c address is not specified in DMI or ACPI, so
> > runtime detection without whitelist which is below is not
> > possible.
> > 
> > Presence of that ST microelectronics accelerometer is verified by
> > existence of SMO88xx ACPI device which represent that
> > accelerometer. Unfortunately without i2c address.
> 
> This part of the commit message sounded a bit confusing to me at
> first because there is already an ACPI driver which handles SMO88xx
> devices (dell-smo8800).  My understanding is that:
> 
>   * the purpose of this patch is to expose a richer interface (as
>     provided by lis3lv02d) to these devices on some machines,
> 
>   * on whitelisted machines, dell-smo8800 and lis3lv02d can work
>     simultaneously (even though dell-smo8800 effectively duplicates
>     the work that lis3lv02d does).

No. dell-smo8800 reads from ACPI irq number and exports /dev/freefall 
device which notify userspace about falls. lis3lv02d is i2c driver which 
exports axes of accelerometer. Additionaly lis3lv02d can export also 
/dev/freefall if registerer of i2c device provides irq number -- which 
is not case of this patch.

So both drivers are doing different things and both are useful.

IIRC both dell-smo8800 and lis3lv02d represent one HW device (that ST 
microelectronics accelerometer) but due to complicated HW abstraction 
and layers on Dell laptops it is handled by two drivers, one ACPI and 
one i2c.

Yes, in ideal world irq number should be passed to lis3lv02d driver and 
that would export whole device (with /dev/freefall too), but due to HW 
abstraction it is too much complicated...

> If I got something wrong, please correct me.  If I got it right, it
> might make sense to rephrase the commit message a bit so that the
> first bullet point above is immediately clear to the reader.
> 
> > This patch registers lis3lv02d device at i2c address 0x29 if is
> > detected.
> > 
> > Finally commit a7ae81952cda ("i2c: i801: Allow ACPI SystemIO
> > OpRegion to conflict with PCI BAR") allowed to use i2c-i801 driver
> > on Dell machines so lis3lv02d correctly initialize accelerometer.
> > 
> > Tested on Dell Latitude E6440.
> > 
> > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> > ---
> > 
> >  drivers/i2c/busses/i2c-i801.c |   98
> >  +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 98
> >  insertions(+)
> > 
> > diff --git a/drivers/i2c/busses/i2c-i801.c
> > b/drivers/i2c/busses/i2c-i801.c index eb3627f..188cfd4 100644
> > --- a/drivers/i2c/busses/i2c-i801.c
> > +++ b/drivers/i2c/busses/i2c-i801.c
> > @@ -1118,6 +1118,101 @@ static void dmi_check_onboard_devices(const
> > struct dmi_header *dm, void *adap)
> > 
> >  	}
> >  
> >  }
> > 
> > +static acpi_status check_acpi_smo88xx_device(acpi_handle
> > obj_handle, +					     u32 nesting_level,
> > +					     void *context,
> > +					     void **return_value)
> > +{
> > +	struct acpi_device_info *info;
> > +	acpi_status status;
> > +	char *hid;
> > +
> > +	status = acpi_get_object_info(obj_handle, &info);
> 
> acpi_get_object_info() allocates the returned buffer, which the
> caller has to free.

Ok, I will fix it in next patch iteration.

> > +	if (!ACPI_SUCCESS(status) || !(info->valid & ACPI_VALID_HID))
> > +		return AE_OK;
> > +
> > +	hid = info->hardware_id.string;
> > +	if (!hid)
> > +		return AE_OK;
> > +
> > +	if (strlen(hid) < 7)
> > +		return AE_OK;
> > +
> > +	if (memcmp(hid, "SMO88", 5) != 0)
> > +		return AE_OK;
> > +
> > +	*((bool *)return_value) = true;
> > +	return AE_CTRL_TERMINATE;
> > +}
> > +
> > +static bool is_dell_system_with_lis3lv02d(void)
> > +{
> > +	bool found;
> > +	acpi_status status;
> > +	const char *vendor;
> > +
> > +	vendor = dmi_get_system_info(DMI_SYS_VENDOR);
> > +	if (strcmp(vendor, "Dell Inc.") != 0)
> > +		return false;
> > +
> > +	/*
> > +	 * Check if ACPI device SMO88xx exists and if is enabled. That
> > ACPI +	 * device represent our ST microelectronics lis3lv02d
> > accelerometer but +	 * unfortunately without any other additional
> > information. +	 */
> > +	found = false;
> > +	status = acpi_get_devices(NULL, check_acpi_smo88xx_device, NULL,
> > +				  (void **)&found);
> > +	if (!ACPI_SUCCESS(status) || !found)
> > +		return false;
> > +
> > +	return true;
> > +}
> > +
> > +/*
> > + * Dell platform team told us that these Latitude devices have
> > + * ST microelectronics accelerometer at i2c address 0x29.
> > + * That i2c address is not specified in DMI or ACPI, so runtime
> > + * detection without whitelist which is below is not possible.
> > + */
> > +static const char * const dmi_dell_product_names[] = {
> > +	"Latitude E5250",
> > +	"Latitude E5450",
> > +	"Latitude E5550",
> > +	"Latitude E6440",
> > +	"Latitude E6440 ATG",
> > +	"Latitude E6540",
> > +};
> > +
> > +static void register_dell_lis3lv02d_i2c_device(struct i801_priv
> > *priv) +{
> > +	struct i2c_board_info info;
> > +	const char *product_name;
> > +	bool known_i2c_address;
> > +	int i;
> > +
> > +	known_i2c_address = false;
> > +	product_name = dmi_get_system_info(DMI_PRODUCT_NAME);
> > +	for (i = 0; i < ARRAY_SIZE(dmi_dell_product_names); ++i) {
> > +		if (strcmp(product_name, dmi_dell_product_names[i]) == 0) {
> > +			known_i2c_address = true;
> > +			break;
> > +		}
> > +	}
> > +
> > +	if (!known_i2c_address) {
> > +		dev_warn(&priv->pci_dev->dev,
> > +			 "Accelerometer lis3lv02d i2c device is present "
> > +			 "but its i2c address is unknown, skipping ...\n");
> 
> You are probably well aware of this, but checkpatch prefers keeping
> long log messages in one line.  I am pointing it out just in case.

Yes, but I do not know how to fix it. Splitting message into two lines 
generates warning. Having long line generates warning too.

> > +		return;
> > +	}
> > +
> > +	memset(&info, 0, sizeof(struct i2c_board_info));
> 
> How about just doing "struct i2c_board_info info = { 0 };" instead?

Ok.

> > +	info.addr = 0x29;
> > +	strlcpy(info.type, "lis3lv02d", I2C_NAME_SIZE);
> > +	i2c_new_device(&priv->adapter, &info);
> > +}
> > +
> > 
> >  /* Register optional slaves */
> >  static void i801_probe_optional_slaves(struct i801_priv *priv)
> >  {
> > 
> > @@ -1136,6 +1231,9 @@ static void i801_probe_optional_slaves(struct
> > i801_priv *priv)
> > 
> >  	if (dmi_name_in_vendors("FUJITSU"))
> >  	
> >  		dmi_walk(dmi_check_onboard_devices, &priv->adapter);
> > 
> > +
> > +	if (is_dell_system_with_lis3lv02d())
> > +		register_dell_lis3lv02d_i2c_device(priv);
> > 
> >  }
> >  #else
> >  static void __init input_apanel_init(void) {}
> 
> I tested this patch on a Vostro V131, which is not on the whitelist,
> so all I got was the warning message, but to this extent, it works
> for me.

Hm... That means your notebook has ST microelectronics accelerometer 
too. You could try to find it on i2c-i801 bus with userspace i2cdetect 
program (part of i2c-tools) and get i2c address. If it will work we can 
extend DMI name --> i2c address mapping and include your notebook too.

I have that list of confirmed Latitude devices since April 2015 but due 
to problem with ACPI resource conflicts it was not possible to load i2c-
i801.ko bus driver. It was fixed only this year by commit a7ae81952cda. 
So list of devices is probably not up-to-date and new appeared.

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Michał Kępień]

> On Thursday 29 December 2016 09:29:36 Michał Kępień wrote:
> > > Dell platform team told us that some (DMI whitelisted) Dell
> > > Latitude machines have ST microelectronics accelerometer at i2c
> > > address 0x29. That i2c address is not specified in DMI or ACPI, so
> > > runtime detection without whitelist which is below is not
> > > possible.
> > > 
> > > Presence of that ST microelectronics accelerometer is verified by
> > > existence of SMO88xx ACPI device which represent that
> > > accelerometer. Unfortunately without i2c address.
> > 
> > This part of the commit message sounded a bit confusing to me at
> > first because there is already an ACPI driver which handles SMO88xx
> > devices (dell-smo8800).  My understanding is that:
> > 
> >   * the purpose of this patch is to expose a richer interface (as
> >     provided by lis3lv02d) to these devices on some machines,
> > 
> >   * on whitelisted machines, dell-smo8800 and lis3lv02d can work
> >     simultaneously (even though dell-smo8800 effectively duplicates
> >     the work that lis3lv02d does).
> 
> No. dell-smo8800 reads from ACPI irq number and exports /dev/freefall 
> device which notify userspace about falls. lis3lv02d is i2c driver which 
> exports axes of accelerometer. Additionaly lis3lv02d can export also 
> /dev/freefall if registerer of i2c device provides irq number -- which 
> is not case of this patch.
> 
> So both drivers are doing different things and both are useful.
> 
> IIRC both dell-smo8800 and lis3lv02d represent one HW device (that ST 
> microelectronics accelerometer) but due to complicated HW abstraction 
> and layers on Dell laptops it is handled by two drivers, one ACPI and 
> one i2c.
> 
> Yes, in ideal world irq number should be passed to lis3lv02d driver and 
> that would export whole device (with /dev/freefall too), but due to HW 
> abstraction it is too much complicated...

Why?  AFAICT, all that is required to pass that IRQ number all the way
down to lis3lv02d is to set the irq field of the struct i2c_board_info
you are passing to i2c_new_device().  And you can extract that IRQ
number e.g. in check_acpi_smo88xx_device().  However, you would then
need to make sure dell-smo8800 does not attempt to request the same IRQ
on whitelisted machines.  This got me thinking about a way to somehow
incorporate your changes into dell-smo8800 using Wolfram's bus_notifier
suggestion, but I do not have a working solution for now.  What is
tempting about this approach is that you would not have to scan the ACPI
namespace in search of SMO88xx devices, because smo8800_add() is
automatically called for them.  However, I fear that the resulting
solution may be more complicated than the one you submitted.

> 
> > If I got something wrong, please correct me.  If I got it right, it
> > might make sense to rephrase the commit message a bit so that the
> > first bullet point above is immediately clear to the reader.
> > 
> > > This patch registers lis3lv02d device at i2c address 0x29 if is
> > > detected.
> > > 
> > > Finally commit a7ae81952cda ("i2c: i801: Allow ACPI SystemIO
> > > OpRegion to conflict with PCI BAR") allowed to use i2c-i801 driver
> > > on Dell machines so lis3lv02d correctly initialize accelerometer.
> > > 
> > > Tested on Dell Latitude E6440.
> > > 
> > > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> > > ---
> > > 
> > >  drivers/i2c/busses/i2c-i801.c |   98
> > >  +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 98
> > >  insertions(+)
> > > 
> > > diff --git a/drivers/i2c/busses/i2c-i801.c
> > > b/drivers/i2c/busses/i2c-i801.c index eb3627f..188cfd4 100644
> > > --- a/drivers/i2c/busses/i2c-i801.c
> > > +++ b/drivers/i2c/busses/i2c-i801.c
> > > @@ -1118,6 +1118,101 @@ static void dmi_check_onboard_devices(const
> > > struct dmi_header *dm, void *adap)
> > > 
> > >  	}
> > >  
> > >  }
> > > 
> > > +static acpi_status check_acpi_smo88xx_device(acpi_handle
> > > obj_handle, +					     u32 nesting_level,
> > > +					     void *context,
> > > +					     void **return_value)
> > > +{
> > > +	struct acpi_device_info *info;
> > > +	acpi_status status;
> > > +	char *hid;
> > > +
> > > +	status = acpi_get_object_info(obj_handle, &info);
> > 
> > acpi_get_object_info() allocates the returned buffer, which the
> > caller has to free.
> 
> Ok, I will fix it in next patch iteration.
> 
> > > +	if (!ACPI_SUCCESS(status) || !(info->valid & ACPI_VALID_HID))
> > > +		return AE_OK;
> > > +
> > > +	hid = info->hardware_id.string;
> > > +	if (!hid)
> > > +		return AE_OK;
> > > +
> > > +	if (strlen(hid) < 7)
> > > +		return AE_OK;
> > > +
> > > +	if (memcmp(hid, "SMO88", 5) != 0)
> > > +		return AE_OK;
> > > +
> > > +	*((bool *)return_value) = true;
> > > +	return AE_CTRL_TERMINATE;
> > > +}
> > > +
> > > +static bool is_dell_system_with_lis3lv02d(void)
> > > +{
> > > +	bool found;
> > > +	acpi_status status;
> > > +	const char *vendor;
> > > +
> > > +	vendor = dmi_get_system_info(DMI_SYS_VENDOR);
> > > +	if (strcmp(vendor, "Dell Inc.") != 0)
> > > +		return false;
> > > +
> > > +	/*
> > > +	 * Check if ACPI device SMO88xx exists and if is enabled. That
> > > ACPI +	 * device represent our ST microelectronics lis3lv02d
> > > accelerometer but +	 * unfortunately without any other additional
> > > information. +	 */
> > > +	found = false;
> > > +	status = acpi_get_devices(NULL, check_acpi_smo88xx_device, NULL,
> > > +				  (void **)&found);
> > > +	if (!ACPI_SUCCESS(status) || !found)
> > > +		return false;
> > > +
> > > +	return true;
> > > +}
> > > +
> > > +/*
> > > + * Dell platform team told us that these Latitude devices have
> > > + * ST microelectronics accelerometer at i2c address 0x29.
> > > + * That i2c address is not specified in DMI or ACPI, so runtime
> > > + * detection without whitelist which is below is not possible.
> > > + */
> > > +static const char * const dmi_dell_product_names[] = {
> > > +	"Latitude E5250",
> > > +	"Latitude E5450",
> > > +	"Latitude E5550",
> > > +	"Latitude E6440",
> > > +	"Latitude E6440 ATG",
> > > +	"Latitude E6540",
> > > +};
> > > +
> > > +static void register_dell_lis3lv02d_i2c_device(struct i801_priv
> > > *priv) +{
> > > +	struct i2c_board_info info;
> > > +	const char *product_name;
> > > +	bool known_i2c_address;
> > > +	int i;
> > > +
> > > +	known_i2c_address = false;
> > > +	product_name = dmi_get_system_info(DMI_PRODUCT_NAME);
> > > +	for (i = 0; i < ARRAY_SIZE(dmi_dell_product_names); ++i) {
> > > +		if (strcmp(product_name, dmi_dell_product_names[i]) == 0) {
> > > +			known_i2c_address = true;
> > > +			break;
> > > +		}
> > > +	}
> > > +
> > > +	if (!known_i2c_address) {
> > > +		dev_warn(&priv->pci_dev->dev,
> > > +			 "Accelerometer lis3lv02d i2c device is present "
> > > +			 "but its i2c address is unknown, skipping ...\n");
> > 
> > You are probably well aware of this, but checkpatch prefers keeping
> > long log messages in one line.  I am pointing it out just in case.
> 
> Yes, but I do not know how to fix it. Splitting message into two lines 
> generates warning. Having long line generates warning too.

Weird, checkpatch does not protest on my machine when the log message is
written on a single line...

> 
> > > +		return;
> > > +	}
> > > +
> > > +	memset(&info, 0, sizeof(struct i2c_board_info));
> > 
> > How about just doing "struct i2c_board_info info = { 0 };" instead?
> 
> Ok.
> 
> > > +	info.addr = 0x29;
> > > +	strlcpy(info.type, "lis3lv02d", I2C_NAME_SIZE);
> > > +	i2c_new_device(&priv->adapter, &info);
> > > +}
> > > +
> > > 
> > >  /* Register optional slaves */
> > >  static void i801_probe_optional_slaves(struct i801_priv *priv)
> > >  {
> > > 
> > > @@ -1136,6 +1231,9 @@ static void i801_probe_optional_slaves(struct
> > > i801_priv *priv)
> > > 
> > >  	if (dmi_name_in_vendors("FUJITSU"))
> > >  	
> > >  		dmi_walk(dmi_check_onboard_devices, &priv->adapter);
> > > 
> > > +
> > > +	if (is_dell_system_with_lis3lv02d())
> > > +		register_dell_lis3lv02d_i2c_device(priv);
> > > 
> > >  }
> > >  #else
> > >  static void __init input_apanel_init(void) {}
> > 
> > I tested this patch on a Vostro V131, which is not on the whitelist,
> > so all I got was the warning message, but to this extent, it works
> > for me.
> 
> Hm... That means your notebook has ST microelectronics accelerometer 
> too. You could try to find it on i2c-i801 bus with userspace i2cdetect 
> program (part of i2c-tools) and get i2c address.

Bingo, it is at 0x1d.  I modified your patch to set the i2c address to
0x1d and at least free fall detection seems to be working correctly.

-- 
Best regards,
Michał Kępień

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 10463 bytes --]

On Thursday 29 December 2016 14:47:19 Michał Kępień wrote:
> > On Thursday 29 December 2016 09:29:36 Michał Kępień wrote:
> > > > Dell platform team told us that some (DMI whitelisted) Dell
> > > > Latitude machines have ST microelectronics accelerometer at i2c
> > > > address 0x29. That i2c address is not specified in DMI or ACPI,
> > > > so runtime detection without whitelist which is below is not
> > > > possible.
> > > > 
> > > > Presence of that ST microelectronics accelerometer is verified
> > > > by existence of SMO88xx ACPI device which represent that
> > > > accelerometer. Unfortunately without i2c address.
> > > 
> > > This part of the commit message sounded a bit confusing to me at
> > > first because there is already an ACPI driver which handles
> > > SMO88xx
> > > 
> > > devices (dell-smo8800).  My understanding is that:
> > >   * the purpose of this patch is to expose a richer interface (as
> > >   
> > >     provided by lis3lv02d) to these devices on some machines,
> > >   
> > >   * on whitelisted machines, dell-smo8800 and lis3lv02d can work
> > >   
> > >     simultaneously (even though dell-smo8800 effectively
> > >     duplicates the work that lis3lv02d does).
> > 
> > No. dell-smo8800 reads from ACPI irq number and exports
> > /dev/freefall device which notify userspace about falls. lis3lv02d
> > is i2c driver which exports axes of accelerometer. Additionaly
> > lis3lv02d can export also /dev/freefall if registerer of i2c
> > device provides irq number -- which is not case of this patch.
> > 
> > So both drivers are doing different things and both are useful.
> > 
> > IIRC both dell-smo8800 and lis3lv02d represent one HW device (that
> > ST microelectronics accelerometer) but due to complicated HW
> > abstraction and layers on Dell laptops it is handled by two
> > drivers, one ACPI and one i2c.
> > 
> > Yes, in ideal world irq number should be passed to lis3lv02d driver
> > and that would export whole device (with /dev/freefall too), but
> > due to HW abstraction it is too much complicated...
> 
> Why?  AFAICT, all that is required to pass that IRQ number all the
> way down to lis3lv02d is to set the irq field of the struct
> i2c_board_info you are passing to i2c_new_device().  And you can
> extract that IRQ number e.g. in check_acpi_smo88xx_device(). 
> However, you would then need to make sure dell-smo8800 does not
> attempt to request the same IRQ on whitelisted machines.  This got
> me thinking about a way to somehow incorporate your changes into
> dell-smo8800 using Wolfram's bus_notifier suggestion, but I do not
> have a working solution for now.  What is tempting about this
> approach is that you would not have to scan the ACPI namespace in
> search of SMO88xx devices, because smo8800_add() is automatically
> called for them.  However, I fear that the resulting solution may be
> more complicated than the one you submitted.

Then we need to deal with lot of problems. Order of loading .ko modules 
is undefined. Binding devices to drivers registered by .ko module is 
also in "random" order. At any time any of those .ko module can be 
unloaded or at least device unbind (via sysfs) from driver... And there 
can be some pathological situation (thanks to adding ACPI layer as Andy 
pointed) that there will be more SMO88xx devices in ACPI. Plus you can 
compile kernel with and without those modules and also you can blacklist 
loading them (so compile time check is not enough). And still some 
correct message notifier must be used.

I think such solution is much much more complicated, there are lot of 
combinations of kernel configuration and available dell devices...

> > > If I got something wrong, please correct me.  If I got it right,
> > > it might make sense to rephrase the commit message a bit so that
> > > the first bullet point above is immediately clear to the reader.
> > > 
> > > > This patch registers lis3lv02d device at i2c address 0x29 if is
> > > > detected.
> > > > 
> > > > Finally commit a7ae81952cda ("i2c: i801: Allow ACPI SystemIO
> > > > OpRegion to conflict with PCI BAR") allowed to use i2c-i801
> > > > driver on Dell machines so lis3lv02d correctly initialize
> > > > accelerometer.
> > > > 
> > > > Tested on Dell Latitude E6440.
> > > > 
> > > > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> > > > ---
> > > > 
> > > >  drivers/i2c/busses/i2c-i801.c |   98
> > > >  +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 98
> > > >  insertions(+)
> > > > 
> > > > diff --git a/drivers/i2c/busses/i2c-i801.c
> > > > b/drivers/i2c/busses/i2c-i801.c index eb3627f..188cfd4 100644
> > > > --- a/drivers/i2c/busses/i2c-i801.c
> > > > +++ b/drivers/i2c/busses/i2c-i801.c
> > > > @@ -1118,6 +1118,101 @@ static void
> > > > dmi_check_onboard_devices(const struct dmi_header *dm, void
> > > > *adap)
> > > > 
> > > >  	}
> > > >  
> > > >  }
> > > > 
> > > > +static acpi_status check_acpi_smo88xx_device(acpi_handle
> > > > obj_handle, +					     u32 nesting_level,
> > > > +					     void *context,
> > > > +					     void **return_value)
> > > > +{
> > > > +	struct acpi_device_info *info;
> > > > +	acpi_status status;
> > > > +	char *hid;
> > > > +
> > > > +	status = acpi_get_object_info(obj_handle, &info);
> > > 
> > > acpi_get_object_info() allocates the returned buffer, which the
> > > caller has to free.
> > 
> > Ok, I will fix it in next patch iteration.
> > 
> > > > +	if (!ACPI_SUCCESS(status) || !(info->valid & ACPI_VALID_HID))
> > > > +		return AE_OK;
> > > > +
> > > > +	hid = info->hardware_id.string;
> > > > +	if (!hid)
> > > > +		return AE_OK;
> > > > +
> > > > +	if (strlen(hid) < 7)
> > > > +		return AE_OK;
> > > > +
> > > > +	if (memcmp(hid, "SMO88", 5) != 0)
> > > > +		return AE_OK;
> > > > +
> > > > +	*((bool *)return_value) = true;
> > > > +	return AE_CTRL_TERMINATE;
> > > > +}
> > > > +
> > > > +static bool is_dell_system_with_lis3lv02d(void)
> > > > +{
> > > > +	bool found;
> > > > +	acpi_status status;
> > > > +	const char *vendor;
> > > > +
> > > > +	vendor = dmi_get_system_info(DMI_SYS_VENDOR);
> > > > +	if (strcmp(vendor, "Dell Inc.") != 0)
> > > > +		return false;
> > > > +
> > > > +	/*
> > > > +	 * Check if ACPI device SMO88xx exists and if is enabled.
> > > > That ACPI +	 * device represent our ST microelectronics
> > > > lis3lv02d accelerometer but +	 * unfortunately without any
> > > > other additional information. +	 */
> > > > +	found = false;
> > > > +	status = acpi_get_devices(NULL, check_acpi_smo88xx_device,
> > > > NULL, +				  (void **)&found);
> > > > +	if (!ACPI_SUCCESS(status) || !found)
> > > > +		return false;
> > > > +
> > > > +	return true;
> > > > +}
> > > > +
> > > > +/*
> > > > + * Dell platform team told us that these Latitude devices have
> > > > + * ST microelectronics accelerometer at i2c address 0x29.
> > > > + * That i2c address is not specified in DMI or ACPI, so
> > > > runtime + * detection without whitelist which is below is not
> > > > possible. + */
> > > > +static const char * const dmi_dell_product_names[] = {
> > > > +	"Latitude E5250",
> > > > +	"Latitude E5450",
> > > > +	"Latitude E5550",
> > > > +	"Latitude E6440",
> > > > +	"Latitude E6440 ATG",
> > > > +	"Latitude E6540",
> > > > +};
> > > > +
> > > > +static void register_dell_lis3lv02d_i2c_device(struct
> > > > i801_priv *priv) +{
> > > > +	struct i2c_board_info info;
> > > > +	const char *product_name;
> > > > +	bool known_i2c_address;
> > > > +	int i;
> > > > +
> > > > +	known_i2c_address = false;
> > > > +	product_name = dmi_get_system_info(DMI_PRODUCT_NAME);
> > > > +	for (i = 0; i < ARRAY_SIZE(dmi_dell_product_names); ++i) {
> > > > +		if (strcmp(product_name, dmi_dell_product_names[i]) == 0)
> > > > {
> > > > +			known_i2c_address = true;
> > > > +			break;
> > > > +		}
> > > > +	}
> > > > +
> > > > +	if (!known_i2c_address) {
> > > > +		dev_warn(&priv->pci_dev->dev,
> > > > +			 "Accelerometer lis3lv02d i2c device is present "
> > > > +			 "but its i2c address is unknown, skipping ...\n");
> > > 
> > > You are probably well aware of this, but checkpatch prefers
> > > keeping long log messages in one line.  I am pointing it out
> > > just in case.
> > 
> > Yes, but I do not know how to fix it. Splitting message into two
> > lines generates warning. Having long line generates warning too.
> 
> Weird, checkpatch does not protest on my machine when the log message
> is written on a single line...

I hope that i2c maintainers decide how to format that line.

> > > > +		return;
> > > > +	}
> > > > +
> > > > +	memset(&info, 0, sizeof(struct i2c_board_info));
> > > 
> > > How about just doing "struct i2c_board_info info = { 0 };"
> > > instead?
> > 
> > Ok.
> > 
> > > > +	info.addr = 0x29;
> > > > +	strlcpy(info.type, "lis3lv02d", I2C_NAME_SIZE);
> > > > +	i2c_new_device(&priv->adapter, &info);
> > > > +}
> > > > +
> > > > 
> > > >  /* Register optional slaves */
> > > >  static void i801_probe_optional_slaves(struct i801_priv *priv)
> > > >  {
> > > > 
> > > > @@ -1136,6 +1231,9 @@ static void
> > > > i801_probe_optional_slaves(struct i801_priv *priv)
> > > > 
> > > >  	if (dmi_name_in_vendors("FUJITSU"))
> > > >  	
> > > >  		dmi_walk(dmi_check_onboard_devices, &priv->adapter);
> > > > 
> > > > +
> > > > +	if (is_dell_system_with_lis3lv02d())
> > > > +		register_dell_lis3lv02d_i2c_device(priv);
> > > > 
> > > >  }
> > > >  #else
> > > >  static void __init input_apanel_init(void) {}
> > > 
> > > I tested this patch on a Vostro V131, which is not on the
> > > whitelist, so all I got was the warning message, but to this
> > > extent, it works for me.
> > 
> > Hm... That means your notebook has ST microelectronics
> > accelerometer too. You could try to find it on i2c-i801 bus with
> > userspace i2cdetect program (part of i2c-tools) and get i2c
> > address.
> 
> Bingo, it is at 0x1d.  I modified your patch to set the i2c address
> to 0x1d and at least free fall detection seems to be working
> correctly.

lis3lv02d exports input device, you should find its number lsinput. You 
can then test accelerometer with e.g. program input-events.

If it is working fine, I can add your machine to whitelist with i2c 
address 0x1d.

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Michał Kępień]

> On Thursday 29 December 2016 14:47:19 Michał Kępień wrote:
> > > On Thursday 29 December 2016 09:29:36 Michał Kępień wrote:
> > > > > Dell platform team told us that some (DMI whitelisted) Dell
> > > > > Latitude machines have ST microelectronics accelerometer at i2c
> > > > > address 0x29. That i2c address is not specified in DMI or ACPI,
> > > > > so runtime detection without whitelist which is below is not
> > > > > possible.
> > > > > 
> > > > > Presence of that ST microelectronics accelerometer is verified
> > > > > by existence of SMO88xx ACPI device which represent that
> > > > > accelerometer. Unfortunately without i2c address.
> > > > 
> > > > This part of the commit message sounded a bit confusing to me at
> > > > first because there is already an ACPI driver which handles
> > > > SMO88xx
> > > > 
> > > > devices (dell-smo8800).  My understanding is that:
> > > >   * the purpose of this patch is to expose a richer interface (as
> > > >   
> > > >     provided by lis3lv02d) to these devices on some machines,
> > > >   
> > > >   * on whitelisted machines, dell-smo8800 and lis3lv02d can work
> > > >   
> > > >     simultaneously (even though dell-smo8800 effectively
> > > >     duplicates the work that lis3lv02d does).
> > > 
> > > No. dell-smo8800 reads from ACPI irq number and exports
> > > /dev/freefall device which notify userspace about falls. lis3lv02d
> > > is i2c driver which exports axes of accelerometer. Additionaly
> > > lis3lv02d can export also /dev/freefall if registerer of i2c
> > > device provides irq number -- which is not case of this patch.
> > > 
> > > So both drivers are doing different things and both are useful.
> > > 
> > > IIRC both dell-smo8800 and lis3lv02d represent one HW device (that
> > > ST microelectronics accelerometer) but due to complicated HW
> > > abstraction and layers on Dell laptops it is handled by two
> > > drivers, one ACPI and one i2c.
> > > 
> > > Yes, in ideal world irq number should be passed to lis3lv02d driver
> > > and that would export whole device (with /dev/freefall too), but
> > > due to HW abstraction it is too much complicated...
> > 
> > Why?  AFAICT, all that is required to pass that IRQ number all the
> > way down to lis3lv02d is to set the irq field of the struct
> > i2c_board_info you are passing to i2c_new_device().  And you can
> > extract that IRQ number e.g. in check_acpi_smo88xx_device(). 
> > However, you would then need to make sure dell-smo8800 does not
> > attempt to request the same IRQ on whitelisted machines.  This got
> > me thinking about a way to somehow incorporate your changes into
> > dell-smo8800 using Wolfram's bus_notifier suggestion, but I do not
> > have a working solution for now.  What is tempting about this
> > approach is that you would not have to scan the ACPI namespace in
> > search of SMO88xx devices, because smo8800_add() is automatically
> > called for them.  However, I fear that the resulting solution may be
> > more complicated than the one you submitted.
> 
> Then we need to deal with lot of problems. Order of loading .ko modules 
> is undefined. Binding devices to drivers registered by .ko module is 
> also in "random" order. At any time any of those .ko module can be 
> unloaded or at least device unbind (via sysfs) from driver... And there 
> can be some pathological situation (thanks to adding ACPI layer as Andy 
> pointed) that there will be more SMO88xx devices in ACPI. Plus you can 
> compile kernel with and without those modules and also you can blacklist 
> loading them (so compile time check is not enough). And still some 
> correct message notifier must be used.
> 
> I think such solution is much much more complicated, there are lot of 
> combinations of kernel configuration and available dell devices...

I tried a few more things, but ultimately failed to find a nice way to
implement this.

Another issue popped up, though.  Linus' master branch contains a recent
commit by Benjamin Tissoires (CC'ed), 4d5538f5882a ("i2c: use an IRQ to
report Host Notify events, not alert") which breaks your patch.  The
reason for that is that lis3lv02d relies on the i2c client's IRQ being 0
to detect that it should not create /dev/freefall.  Benjamin's patch
causes the Host Notify IRQ to be assigned to the i2c client your patch
creates, thus causing lis3lv02d to create /dev/freefall, which in turn
conflicts with dell-smo8800 which is trying to create /dev/freefall
itself.
        
Also, just to make sure we do not overthink this, I understand that not
every unit of the models from the whitelist has an accelerometer,
correct?  In other words, could we perhaps skip the part where we are
making sure the SMO88xx ACPI device is there?

> 
> > > > If I got something wrong, please correct me.  If I got it right,
> > > > it might make sense to rephrase the commit message a bit so that
> > > > the first bullet point above is immediately clear to the reader.
> > > > 
> > > > > This patch registers lis3lv02d device at i2c address 0x29 if is
> > > > > detected.
> > > > > 
> > > > > Finally commit a7ae81952cda ("i2c: i801: Allow ACPI SystemIO
> > > > > OpRegion to conflict with PCI BAR") allowed to use i2c-i801
> > > > > driver on Dell machines so lis3lv02d correctly initialize
> > > > > accelerometer.
> > > > > 
> > > > > Tested on Dell Latitude E6440.
> > > > > 
> > > > > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> > > > > ---
> > > > > 
> > > > >  drivers/i2c/busses/i2c-i801.c |   98
> > > > >  +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 98
> > > > >  insertions(+)
> > > > > 
> > > > > diff --git a/drivers/i2c/busses/i2c-i801.c
> > > > > b/drivers/i2c/busses/i2c-i801.c index eb3627f..188cfd4 100644
> > > > > --- a/drivers/i2c/busses/i2c-i801.c
> > > > > +++ b/drivers/i2c/busses/i2c-i801.c
> > > > > @@ -1118,6 +1118,101 @@ static void
> > > > > dmi_check_onboard_devices(const struct dmi_header *dm, void
> > > > > *adap)
> > > > > 
> > > > >  	}
> > > > >  
> > > > >  }
> > > > > 
> > > > > +static acpi_status check_acpi_smo88xx_device(acpi_handle
> > > > > obj_handle, +					     u32 nesting_level,
> > > > > +					     void *context,
> > > > > +					     void **return_value)
> > > > > +{
> > > > > +	struct acpi_device_info *info;
> > > > > +	acpi_status status;
> > > > > +	char *hid;
> > > > > +
> > > > > +	status = acpi_get_object_info(obj_handle, &info);
> > > > 
> > > > acpi_get_object_info() allocates the returned buffer, which the
> > > > caller has to free.
> > > 
> > > Ok, I will fix it in next patch iteration.
> > > 
> > > > > +	if (!ACPI_SUCCESS(status) || !(info->valid & ACPI_VALID_HID))
> > > > > +		return AE_OK;
> > > > > +
> > > > > +	hid = info->hardware_id.string;
> > > > > +	if (!hid)
> > > > > +		return AE_OK;
> > > > > +
> > > > > +	if (strlen(hid) < 7)
> > > > > +		return AE_OK;
> > > > > +
> > > > > +	if (memcmp(hid, "SMO88", 5) != 0)
> > > > > +		return AE_OK;
> > > > > +
> > > > > +	*((bool *)return_value) = true;
> > > > > +	return AE_CTRL_TERMINATE;
> > > > > +}
> > > > > +
> > > > > +static bool is_dell_system_with_lis3lv02d(void)
> > > > > +{
> > > > > +	bool found;
> > > > > +	acpi_status status;
> > > > > +	const char *vendor;
> > > > > +
> > > > > +	vendor = dmi_get_system_info(DMI_SYS_VENDOR);
> > > > > +	if (strcmp(vendor, "Dell Inc.") != 0)
> > > > > +		return false;
> > > > > +
> > > > > +	/*
> > > > > +	 * Check if ACPI device SMO88xx exists and if is enabled.
> > > > > That ACPI +	 * device represent our ST microelectronics
> > > > > lis3lv02d accelerometer but +	 * unfortunately without any
> > > > > other additional information. +	 */
> > > > > +	found = false;
> > > > > +	status = acpi_get_devices(NULL, check_acpi_smo88xx_device,
> > > > > NULL, +				  (void **)&found);
> > > > > +	if (!ACPI_SUCCESS(status) || !found)
> > > > > +		return false;
> > > > > +
> > > > > +	return true;
> > > > > +}
> > > > > +
> > > > > +/*
> > > > > + * Dell platform team told us that these Latitude devices have
> > > > > + * ST microelectronics accelerometer at i2c address 0x29.
> > > > > + * That i2c address is not specified in DMI or ACPI, so
> > > > > runtime + * detection without whitelist which is below is not
> > > > > possible. + */
> > > > > +static const char * const dmi_dell_product_names[] = {
> > > > > +	"Latitude E5250",
> > > > > +	"Latitude E5450",
> > > > > +	"Latitude E5550",
> > > > > +	"Latitude E6440",
> > > > > +	"Latitude E6440 ATG",
> > > > > +	"Latitude E6540",
> > > > > +};
> > > > > +
> > > > > +static void register_dell_lis3lv02d_i2c_device(struct
> > > > > i801_priv *priv) +{
> > > > > +	struct i2c_board_info info;
> > > > > +	const char *product_name;
> > > > > +	bool known_i2c_address;
> > > > > +	int i;
> > > > > +
> > > > > +	known_i2c_address = false;
> > > > > +	product_name = dmi_get_system_info(DMI_PRODUCT_NAME);
> > > > > +	for (i = 0; i < ARRAY_SIZE(dmi_dell_product_names); ++i) {
> > > > > +		if (strcmp(product_name, dmi_dell_product_names[i]) == 0)
> > > > > {
> > > > > +			known_i2c_address = true;
> > > > > +			break;
> > > > > +		}
> > > > > +	}
> > > > > +
> > > > > +	if (!known_i2c_address) {
> > > > > +		dev_warn(&priv->pci_dev->dev,
> > > > > +			 "Accelerometer lis3lv02d i2c device is present "
> > > > > +			 "but its i2c address is unknown, skipping ...\n");
> > > > 
> > > > You are probably well aware of this, but checkpatch prefers
> > > > keeping long log messages in one line.  I am pointing it out
> > > > just in case.
> > > 
> > > Yes, but I do not know how to fix it. Splitting message into two
> > > lines generates warning. Having long line generates warning too.
> > 
> > Weird, checkpatch does not protest on my machine when the log message
> > is written on a single line...
> 
> I hope that i2c maintainers decide how to format that line.
> 
> > > > > +		return;
> > > > > +	}
> > > > > +
> > > > > +	memset(&info, 0, sizeof(struct i2c_board_info));
> > > > 
> > > > How about just doing "struct i2c_board_info info = { 0 };"
> > > > instead?
> > > 
> > > Ok.
> > > 
> > > > > +	info.addr = 0x29;
> > > > > +	strlcpy(info.type, "lis3lv02d", I2C_NAME_SIZE);
> > > > > +	i2c_new_device(&priv->adapter, &info);
> > > > > +}
> > > > > +
> > > > > 
> > > > >  /* Register optional slaves */
> > > > >  static void i801_probe_optional_slaves(struct i801_priv *priv)
> > > > >  {
> > > > > 
> > > > > @@ -1136,6 +1231,9 @@ static void
> > > > > i801_probe_optional_slaves(struct i801_priv *priv)
> > > > > 
> > > > >  	if (dmi_name_in_vendors("FUJITSU"))
> > > > >  	
> > > > >  		dmi_walk(dmi_check_onboard_devices, &priv->adapter);
> > > > > 
> > > > > +
> > > > > +	if (is_dell_system_with_lis3lv02d())
> > > > > +		register_dell_lis3lv02d_i2c_device(priv);
> > > > > 
> > > > >  }
> > > > >  #else
> > > > >  static void __init input_apanel_init(void) {}
> > > > 
> > > > I tested this patch on a Vostro V131, which is not on the
> > > > whitelist, so all I got was the warning message, but to this
> > > > extent, it works for me.
> > > 
> > > Hm... That means your notebook has ST microelectronics
> > > accelerometer too. You could try to find it on i2c-i801 bus with
> > > userspace i2cdetect program (part of i2c-tools) and get i2c
> > > address.
> > 
> > Bingo, it is at 0x1d.  I modified your patch to set the i2c address
> > to 0x1d and at least free fall detection seems to be working
> > correctly.
> 
> lis3lv02d exports input device, you should find its number lsinput. You 
> can then test accelerometer with e.g. program input-events.
> 
> If it is working fine, I can add your machine to whitelist with i2c 
> address 0x1d.

I did some tests with evtest and it seems that axis values are
consistent with laptop's movements, so I think it is safe to whitelist
Vostro V131 with i2c address 0x1d.

-- 
Best regards,
Michał Kępień

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 13187 bytes --]

On Thursday 29 December 2016 22:09:32 Michał Kępień wrote:
> > On Thursday 29 December 2016 14:47:19 Michał Kępień wrote:
> > > > On Thursday 29 December 2016 09:29:36 Michał Kępień wrote:
> > > > > > Dell platform team told us that some (DMI whitelisted) Dell
> > > > > > Latitude machines have ST microelectronics accelerometer at
> > > > > > i2c address 0x29. That i2c address is not specified in DMI
> > > > > > or ACPI, so runtime detection without whitelist which is
> > > > > > below is not possible.
> > > > > > 
> > > > > > Presence of that ST microelectronics accelerometer is
> > > > > > verified by existence of SMO88xx ACPI device which
> > > > > > represent that accelerometer. Unfortunately without i2c
> > > > > > address.
> > > > > 
> > > > > This part of the commit message sounded a bit confusing to me
> > > > > at first because there is already an ACPI driver which
> > > > > handles SMO88xx
> > > > > 
> > > > > devices (dell-smo8800).  My understanding is that:
> > > > >   * the purpose of this patch is to expose a richer interface
> > > > >   (as
> > > > >   
> > > > >     provided by lis3lv02d) to these devices on some machines,
> > > > >   
> > > > >   * on whitelisted machines, dell-smo8800 and lis3lv02d can
> > > > >   work
> > > > >   
> > > > >     simultaneously (even though dell-smo8800 effectively
> > > > >     duplicates the work that lis3lv02d does).
> > > > 
> > > > No. dell-smo8800 reads from ACPI irq number and exports
> > > > /dev/freefall device which notify userspace about falls.
> > > > lis3lv02d is i2c driver which exports axes of accelerometer.
> > > > Additionaly lis3lv02d can export also /dev/freefall if
> > > > registerer of i2c device provides irq number -- which is not
> > > > case of this patch.
> > > > 
> > > > So both drivers are doing different things and both are useful.
> > > > 
> > > > IIRC both dell-smo8800 and lis3lv02d represent one HW device
> > > > (that ST microelectronics accelerometer) but due to
> > > > complicated HW abstraction and layers on Dell laptops it is
> > > > handled by two drivers, one ACPI and one i2c.
> > > > 
> > > > Yes, in ideal world irq number should be passed to lis3lv02d
> > > > driver and that would export whole device (with /dev/freefall
> > > > too), but due to HW abstraction it is too much complicated...
> > > 
> > > Why?  AFAICT, all that is required to pass that IRQ number all
> > > the way down to lis3lv02d is to set the irq field of the struct
> > > i2c_board_info you are passing to i2c_new_device().  And you can
> > > extract that IRQ number e.g. in check_acpi_smo88xx_device().
> > > However, you would then need to make sure dell-smo8800 does not
> > > attempt to request the same IRQ on whitelisted machines.  This
> > > got me thinking about a way to somehow incorporate your changes
> > > into dell-smo8800 using Wolfram's bus_notifier suggestion, but I
> > > do not have a working solution for now.  What is tempting about
> > > this approach is that you would not have to scan the ACPI
> > > namespace in search of SMO88xx devices, because smo8800_add() is
> > > automatically called for them.  However, I fear that the
> > > resulting solution may be more complicated than the one you
> > > submitted.
> > 
> > Then we need to deal with lot of problems. Order of loading .ko
> > modules is undefined. Binding devices to drivers registered by .ko
> > module is also in "random" order. At any time any of those .ko
> > module can be unloaded or at least device unbind (via sysfs) from
> > driver... And there can be some pathological situation (thanks to
> > adding ACPI layer as Andy pointed) that there will be more SMO88xx
> > devices in ACPI. Plus you can compile kernel with and without
> > those modules and also you can blacklist loading them (so compile
> > time check is not enough). And still some correct message notifier
> > must be used.
> > 
> > I think such solution is much much more complicated, there are lot
> > of combinations of kernel configuration and available dell
> > devices...
> 
> I tried a few more things, but ultimately failed to find a nice way
> to implement this.
> 
> Another issue popped up, though.  Linus' master branch contains a
> recent commit by Benjamin Tissoires (CC'ed), 4d5538f5882a ("i2c: use
> an IRQ to report Host Notify events, not alert") which breaks your
> patch.  The reason for that is that lis3lv02d relies on the i2c
> client's IRQ being 0 to detect that it should not create
> /dev/freefall.  Benjamin's patch causes the Host Notify IRQ to be
> assigned to the i2c client your patch creates, thus causing
> lis3lv02d to create /dev/freefall, which in turn conflicts with
> dell-smo8800 which is trying to create /dev/freefall itself.

So 4d5538f5882a is breaking lis3lv02d driver...

> Also, just to make sure we do not overthink this, I understand that
> not every unit of the models from the whitelist has an
> accelerometer, correct?  In other words, could we perhaps skip the
> part where we are making sure the SMO88xx ACPI device is there?

Good question... At least for E6440 I'm did not thing it was possible to 
configure notebook without "3 axes free fall sensor".

But! In BIOS SETUP it is possible to disable free fall sensor. I will 
try to disable it there and will check what happen. My guess is that it 
will be disabled in ACPI.

> > > > > If I got something wrong, please correct me.  If I got it
> > > > > right, it might make sense to rephrase the commit message a
> > > > > bit so that the first bullet point above is immediately
> > > > > clear to the reader.
> > > > > 
> > > > > > This patch registers lis3lv02d device at i2c address 0x29
> > > > > > if is detected.
> > > > > > 
> > > > > > Finally commit a7ae81952cda ("i2c: i801: Allow ACPI
> > > > > > SystemIO OpRegion to conflict with PCI BAR") allowed to
> > > > > > use i2c-i801 driver on Dell machines so lis3lv02d
> > > > > > correctly initialize accelerometer.
> > > > > > 
> > > > > > Tested on Dell Latitude E6440.
> > > > > > 
> > > > > > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> > > > > > ---
> > > > > > 
> > > > > >  drivers/i2c/busses/i2c-i801.c |   98
> > > > > >  +++++++++++++++++++++++++++++++++++++++++ 1 file changed,
> > > > > >  98 insertions(+)
> > > > > > 
> > > > > > diff --git a/drivers/i2c/busses/i2c-i801.c
> > > > > > b/drivers/i2c/busses/i2c-i801.c index eb3627f..188cfd4
> > > > > > 100644 --- a/drivers/i2c/busses/i2c-i801.c
> > > > > > +++ b/drivers/i2c/busses/i2c-i801.c
> > > > > > @@ -1118,6 +1118,101 @@ static void
> > > > > > dmi_check_onboard_devices(const struct dmi_header *dm, void
> > > > > > *adap)
> > > > > > 
> > > > > >  	}
> > > > > >  
> > > > > >  }
> > > > > > 
> > > > > > +static acpi_status check_acpi_smo88xx_device(acpi_handle
> > > > > > obj_handle, +					     u32 nesting_level,
> > > > > > +					     void *context,
> > > > > > +					     void **return_value)
> > > > > > +{
> > > > > > +	struct acpi_device_info *info;
> > > > > > +	acpi_status status;
> > > > > > +	char *hid;
> > > > > > +
> > > > > > +	status = acpi_get_object_info(obj_handle, &info);
> > > > > 
> > > > > acpi_get_object_info() allocates the returned buffer, which
> > > > > the caller has to free.
> > > > 
> > > > Ok, I will fix it in next patch iteration.
> > > > 
> > > > > > +	if (!ACPI_SUCCESS(status) || !(info->valid &
> > > > > > ACPI_VALID_HID)) +		return AE_OK;
> > > > > > +
> > > > > > +	hid = info->hardware_id.string;
> > > > > > +	if (!hid)
> > > > > > +		return AE_OK;
> > > > > > +
> > > > > > +	if (strlen(hid) < 7)
> > > > > > +		return AE_OK;
> > > > > > +
> > > > > > +	if (memcmp(hid, "SMO88", 5) != 0)
> > > > > > +		return AE_OK;
> > > > > > +
> > > > > > +	*((bool *)return_value) = true;
> > > > > > +	return AE_CTRL_TERMINATE;
> > > > > > +}
> > > > > > +
> > > > > > +static bool is_dell_system_with_lis3lv02d(void)
> > > > > > +{
> > > > > > +	bool found;
> > > > > > +	acpi_status status;
> > > > > > +	const char *vendor;
> > > > > > +
> > > > > > +	vendor = dmi_get_system_info(DMI_SYS_VENDOR);
> > > > > > +	if (strcmp(vendor, "Dell Inc.") != 0)
> > > > > > +		return false;
> > > > > > +
> > > > > > +	/*
> > > > > > +	 * Check if ACPI device SMO88xx exists and if is enabled.
> > > > > > That ACPI +	 * device represent our ST microelectronics
> > > > > > lis3lv02d accelerometer but +	 * unfortunately without any
> > > > > > other additional information. +	 */
> > > > > > +	found = false;
> > > > > > +	status = acpi_get_devices(NULL,
> > > > > > check_acpi_smo88xx_device, NULL, +				  (void
> > > > > > **)&found);
> > > > > > +	if (!ACPI_SUCCESS(status) || !found)
> > > > > > +		return false;
> > > > > > +
> > > > > > +	return true;
> > > > > > +}
> > > > > > +
> > > > > > +/*
> > > > > > + * Dell platform team told us that these Latitude devices
> > > > > > have + * ST microelectronics accelerometer at i2c address
> > > > > > 0x29. + * That i2c address is not specified in DMI or
> > > > > > ACPI, so runtime + * detection without whitelist which is
> > > > > > below is not possible. + */
> > > > > > +static const char * const dmi_dell_product_names[] = {
> > > > > > +	"Latitude E5250",
> > > > > > +	"Latitude E5450",
> > > > > > +	"Latitude E5550",
> > > > > > +	"Latitude E6440",
> > > > > > +	"Latitude E6440 ATG",
> > > > > > +	"Latitude E6540",
> > > > > > +};
> > > > > > +
> > > > > > +static void register_dell_lis3lv02d_i2c_device(struct
> > > > > > i801_priv *priv) +{
> > > > > > +	struct i2c_board_info info;
> > > > > > +	const char *product_name;
> > > > > > +	bool known_i2c_address;
> > > > > > +	int i;
> > > > > > +
> > > > > > +	known_i2c_address = false;
> > > > > > +	product_name = dmi_get_system_info(DMI_PRODUCT_NAME);
> > > > > > +	for (i = 0; i < ARRAY_SIZE(dmi_dell_product_names); ++i)
> > > > > > { +		if (strcmp(product_name, dmi_dell_product_names[i])
> > > > > > == 0) {
> > > > > > +			known_i2c_address = true;
> > > > > > +			break;
> > > > > > +		}
> > > > > > +	}
> > > > > > +
> > > > > > +	if (!known_i2c_address) {
> > > > > > +		dev_warn(&priv->pci_dev->dev,
> > > > > > +			 "Accelerometer lis3lv02d i2c device is present "
> > > > > > +			 "but its i2c address is unknown, skipping ...
> > > > > > \n");
> > > > > 
> > > > > You are probably well aware of this, but checkpatch prefers
> > > > > keeping long log messages in one line.  I am pointing it out
> > > > > just in case.
> > > > 
> > > > Yes, but I do not know how to fix it. Splitting message into
> > > > two lines generates warning. Having long line generates
> > > > warning too.
> > > 
> > > Weird, checkpatch does not protest on my machine when the log
> > > message is written on a single line...
> > 
> > I hope that i2c maintainers decide how to format that line.
> > 
> > > > > > +		return;
> > > > > > +	}
> > > > > > +
> > > > > > +	memset(&info, 0, sizeof(struct i2c_board_info));
> > > > > 
> > > > > How about just doing "struct i2c_board_info info = { 0 };"
> > > > > instead?
> > > > 
> > > > Ok.
> > > > 
> > > > > > +	info.addr = 0x29;
> > > > > > +	strlcpy(info.type, "lis3lv02d", I2C_NAME_SIZE);
> > > > > > +	i2c_new_device(&priv->adapter, &info);
> > > > > > +}
> > > > > > +
> > > > > > 
> > > > > >  /* Register optional slaves */
> > > > > >  static void i801_probe_optional_slaves(struct i801_priv
> > > > > >  *priv) {
> > > > > > 
> > > > > > @@ -1136,6 +1231,9 @@ static void
> > > > > > i801_probe_optional_slaves(struct i801_priv *priv)
> > > > > > 
> > > > > >  	if (dmi_name_in_vendors("FUJITSU"))
> > > > > >  	
> > > > > >  		dmi_walk(dmi_check_onboard_devices, &priv->adapter);
> > > > > > 
> > > > > > +
> > > > > > +	if (is_dell_system_with_lis3lv02d())
> > > > > > +		register_dell_lis3lv02d_i2c_device(priv);
> > > > > > 
> > > > > >  }
> > > > > >  #else
> > > > > >  static void __init input_apanel_init(void) {}
> > > > > 
> > > > > I tested this patch on a Vostro V131, which is not on the
> > > > > whitelist, so all I got was the warning message, but to this
> > > > > extent, it works for me.
> > > > 
> > > > Hm... That means your notebook has ST microelectronics
> > > > accelerometer too. You could try to find it on i2c-i801 bus
> > > > with userspace i2cdetect program (part of i2c-tools) and get
> > > > i2c address.
> > > 
> > > Bingo, it is at 0x1d.  I modified your patch to set the i2c
> > > address to 0x1d and at least free fall detection seems to be
> > > working correctly.
> > 
> > lis3lv02d exports input device, you should find its number lsinput.
> > You can then test accelerometer with e.g. program input-events.
> > 
> > If it is working fine, I can add your machine to whitelist with i2c
> > address 0x1d.
> 
> I did some tests with evtest and it seems that axis values are
> consistent with laptop's movements, so I think it is safe to
> whitelist Vostro V131 with i2c address 0x1d.

Ok.

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Benjamin Tissoires]

On Dec 29 2016 or thereabouts, Pali Rohár wrote:
> On Thursday 29 December 2016 22:09:32 Michał Kępień wrote:
> > > On Thursday 29 December 2016 14:47:19 Michał Kępień wrote:
> > > > > On Thursday 29 December 2016 09:29:36 Michał Kępień wrote:
> > > > > > > Dell platform team told us that some (DMI whitelisted) Dell
> > > > > > > Latitude machines have ST microelectronics accelerometer at
> > > > > > > i2c address 0x29. That i2c address is not specified in DMI
> > > > > > > or ACPI, so runtime detection without whitelist which is
> > > > > > > below is not possible.
> > > > > > > 
> > > > > > > Presence of that ST microelectronics accelerometer is
> > > > > > > verified by existence of SMO88xx ACPI device which
> > > > > > > represent that accelerometer. Unfortunately without i2c
> > > > > > > address.
> > > > > > 
> > > > > > This part of the commit message sounded a bit confusing to me
> > > > > > at first because there is already an ACPI driver which
> > > > > > handles SMO88xx
> > > > > > 
> > > > > > devices (dell-smo8800).  My understanding is that:
> > > > > >   * the purpose of this patch is to expose a richer interface
> > > > > >   (as
> > > > > >   
> > > > > >     provided by lis3lv02d) to these devices on some machines,
> > > > > >   
> > > > > >   * on whitelisted machines, dell-smo8800 and lis3lv02d can
> > > > > >   work
> > > > > >   
> > > > > >     simultaneously (even though dell-smo8800 effectively
> > > > > >     duplicates the work that lis3lv02d does).
> > > > > 
> > > > > No. dell-smo8800 reads from ACPI irq number and exports
> > > > > /dev/freefall device which notify userspace about falls.
> > > > > lis3lv02d is i2c driver which exports axes of accelerometer.
> > > > > Additionaly lis3lv02d can export also /dev/freefall if
> > > > > registerer of i2c device provides irq number -- which is not
> > > > > case of this patch.
> > > > > 
> > > > > So both drivers are doing different things and both are useful.
> > > > > 
> > > > > IIRC both dell-smo8800 and lis3lv02d represent one HW device
> > > > > (that ST microelectronics accelerometer) but due to
> > > > > complicated HW abstraction and layers on Dell laptops it is
> > > > > handled by two drivers, one ACPI and one i2c.
> > > > > 
> > > > > Yes, in ideal world irq number should be passed to lis3lv02d
> > > > > driver and that would export whole device (with /dev/freefall
> > > > > too), but due to HW abstraction it is too much complicated...
> > > > 
> > > > Why?  AFAICT, all that is required to pass that IRQ number all
> > > > the way down to lis3lv02d is to set the irq field of the struct
> > > > i2c_board_info you are passing to i2c_new_device().  And you can
> > > > extract that IRQ number e.g. in check_acpi_smo88xx_device().
> > > > However, you would then need to make sure dell-smo8800 does not
> > > > attempt to request the same IRQ on whitelisted machines.  This
> > > > got me thinking about a way to somehow incorporate your changes
> > > > into dell-smo8800 using Wolfram's bus_notifier suggestion, but I
> > > > do not have a working solution for now.  What is tempting about
> > > > this approach is that you would not have to scan the ACPI
> > > > namespace in search of SMO88xx devices, because smo8800_add() is
> > > > automatically called for them.  However, I fear that the
> > > > resulting solution may be more complicated than the one you
> > > > submitted.
> > > 
> > > Then we need to deal with lot of problems. Order of loading .ko
> > > modules is undefined. Binding devices to drivers registered by .ko
> > > module is also in "random" order. At any time any of those .ko
> > > module can be unloaded or at least device unbind (via sysfs) from
> > > driver... And there can be some pathological situation (thanks to
> > > adding ACPI layer as Andy pointed) that there will be more SMO88xx
> > > devices in ACPI. Plus you can compile kernel with and without
> > > those modules and also you can blacklist loading them (so compile
> > > time check is not enough). And still some correct message notifier
> > > must be used.
> > > 
> > > I think such solution is much much more complicated, there are lot
> > > of combinations of kernel configuration and available dell
> > > devices...
> > 
> > I tried a few more things, but ultimately failed to find a nice way
> > to implement this.
> > 
> > Another issue popped up, though.  Linus' master branch contains a
> > recent commit by Benjamin Tissoires (CC'ed), 4d5538f5882a ("i2c: use
> > an IRQ to report Host Notify events, not alert") which breaks your
> > patch.  The reason for that is that lis3lv02d relies on the i2c
> > client's IRQ being 0 to detect that it should not create
> > /dev/freefall.  Benjamin's patch causes the Host Notify IRQ to be
> > assigned to the i2c client your patch creates, thus causing
> > lis3lv02d to create /dev/freefall, which in turn conflicts with
> > dell-smo8800 which is trying to create /dev/freefall itself.
> 
> So 4d5538f5882a is breaking lis3lv02d driver...

Apologies for that.

I could easily fix this by adding a kernel API to know whether the
provided irq is from Host Notify or if it was coming from an actual
declaration. However, I have no idea how many other drivers would
require this (hopefully only this one).

One other solution would be to reserve the Host Notify IRQ and let the
actual drivers that need it to set it, but this was not the best
solution according to Dmitri. On my side, I am not entirely against this
given that it's a chip feature, so the driver should be able to know
that it's available.

Dmitri, Wolfram, Jean, any preferences?

> 
> > Also, just to make sure we do not overthink this, I understand that
> > not every unit of the models from the whitelist has an
> > accelerometer, correct?  In other words, could we perhaps skip the
> > part where we are making sure the SMO88xx ACPI device is there?
> 
> Good question... At least for E6440 I'm did not thing it was possible to 
> configure notebook without "3 axes free fall sensor".
> 
> But! In BIOS SETUP it is possible to disable free fall sensor. I will 
> try to disable it there and will check what happen. My guess is that it 
> will be disabled in ACPI.

Just adding my 2 cents regarding the whitelist and interaction between
those 2 drivers. I find this very fragile to have only one available
/dev/freefall node and to rely on the fairness of each driver to not bind
one. It would have been much simpler to have /dev/freefallXX and a
proper misc class device for it. This way, we don't even need to
mutually exclude the drivers. But this is already 8 years old code, so I
guess userspace expects this... (why isn't that using the input subsystem
at all?).

Cheers,
Benjamin.

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Pali Rohár]

On Tuesday 03 January 2017 10:06:41 Benjamin Tissoires wrote:
> On Dec 29 2016 or thereabouts, Pali Rohár wrote:
> > On Thursday 29 December 2016 22:09:32 Michał Kępień wrote:
> > > Also, just to make sure we do not overthink this, I understand that
> > > not every unit of the models from the whitelist has an
> > > accelerometer, correct?  In other words, could we perhaps skip the
> > > part where we are making sure the SMO88xx ACPI device is there?
> > 
> > Good question... At least for E6440 I'm did not thing it was possible to 
> > configure notebook without "3 axes free fall sensor".
> > 
> > But! In BIOS SETUP it is possible to disable free fall sensor. I will 
> > try to disable it there and will check what happen. My guess is that it 
> > will be disabled in ACPI.
> 
> Just adding my 2 cents regarding the whitelist and interaction between
> those 2 drivers. I find this very fragile to have only one available
> /dev/freefall node and to rely on the fairness of each driver to not bind
> one. It would have been much simpler to have /dev/freefallXX and a
> proper misc class device for it. This way, we don't even need to
> mutually exclude the drivers. But this is already 8 years old code, so I
> guess userspace expects this... (why isn't that using the input subsystem
> at all?).
> 
> Cheers,
> Benjamin.
> 

I think there is no problem with more /dev/freefall devices. With these
Dell drivers it should not happen as only one driver can request IRQ
which is associated with /dev/freefall. And /dev/freefal is registered
after acquiring IRQ.

But... there are other problems with it as wrote in previous emails.

-- 
Pali Rohár
pali.rohar@gmail.com

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Dmitry Torokhov]

On Tue, Jan 03, 2017 at 10:06:41AM +0100, Benjamin Tissoires wrote:
> On Dec 29 2016 or thereabouts, Pali Rohár wrote:
> > On Thursday 29 December 2016 22:09:32 Michał Kępień wrote:
> > > > On Thursday 29 December 2016 14:47:19 Michał Kępień wrote:
> > > > > > On Thursday 29 December 2016 09:29:36 Michał Kępień wrote:
> > > > > > > > Dell platform team told us that some (DMI whitelisted) Dell
> > > > > > > > Latitude machines have ST microelectronics accelerometer at
> > > > > > > > i2c address 0x29. That i2c address is not specified in DMI
> > > > > > > > or ACPI, so runtime detection without whitelist which is
> > > > > > > > below is not possible.
> > > > > > > > 
> > > > > > > > Presence of that ST microelectronics accelerometer is
> > > > > > > > verified by existence of SMO88xx ACPI device which
> > > > > > > > represent that accelerometer. Unfortunately without i2c
> > > > > > > > address.
> > > > > > > 
> > > > > > > This part of the commit message sounded a bit confusing to me
> > > > > > > at first because there is already an ACPI driver which
> > > > > > > handles SMO88xx
> > > > > > > 
> > > > > > > devices (dell-smo8800).  My understanding is that:
> > > > > > >   * the purpose of this patch is to expose a richer interface
> > > > > > >   (as
> > > > > > >   
> > > > > > >     provided by lis3lv02d) to these devices on some machines,
> > > > > > >   
> > > > > > >   * on whitelisted machines, dell-smo8800 and lis3lv02d can
> > > > > > >   work
> > > > > > >   
> > > > > > >     simultaneously (even though dell-smo8800 effectively
> > > > > > >     duplicates the work that lis3lv02d does).
> > > > > > 
> > > > > > No. dell-smo8800 reads from ACPI irq number and exports
> > > > > > /dev/freefall device which notify userspace about falls.
> > > > > > lis3lv02d is i2c driver which exports axes of accelerometer.
> > > > > > Additionaly lis3lv02d can export also /dev/freefall if
> > > > > > registerer of i2c device provides irq number -- which is not
> > > > > > case of this patch.
> > > > > > 
> > > > > > So both drivers are doing different things and both are useful.
> > > > > > 
> > > > > > IIRC both dell-smo8800 and lis3lv02d represent one HW device
> > > > > > (that ST microelectronics accelerometer) but due to
> > > > > > complicated HW abstraction and layers on Dell laptops it is
> > > > > > handled by two drivers, one ACPI and one i2c.
> > > > > > 
> > > > > > Yes, in ideal world irq number should be passed to lis3lv02d
> > > > > > driver and that would export whole device (with /dev/freefall
> > > > > > too), but due to HW abstraction it is too much complicated...
> > > > > 
> > > > > Why?  AFAICT, all that is required to pass that IRQ number all
> > > > > the way down to lis3lv02d is to set the irq field of the struct
> > > > > i2c_board_info you are passing to i2c_new_device().  And you can
> > > > > extract that IRQ number e.g. in check_acpi_smo88xx_device().
> > > > > However, you would then need to make sure dell-smo8800 does not
> > > > > attempt to request the same IRQ on whitelisted machines.  This
> > > > > got me thinking about a way to somehow incorporate your changes
> > > > > into dell-smo8800 using Wolfram's bus_notifier suggestion, but I
> > > > > do not have a working solution for now.  What is tempting about
> > > > > this approach is that you would not have to scan the ACPI
> > > > > namespace in search of SMO88xx devices, because smo8800_add() is
> > > > > automatically called for them.  However, I fear that the
> > > > > resulting solution may be more complicated than the one you
> > > > > submitted.
> > > > 
> > > > Then we need to deal with lot of problems. Order of loading .ko
> > > > modules is undefined. Binding devices to drivers registered by .ko
> > > > module is also in "random" order. At any time any of those .ko
> > > > module can be unloaded or at least device unbind (via sysfs) from
> > > > driver... And there can be some pathological situation (thanks to
> > > > adding ACPI layer as Andy pointed) that there will be more SMO88xx
> > > > devices in ACPI. Plus you can compile kernel with and without
> > > > those modules and also you can blacklist loading them (so compile
> > > > time check is not enough). And still some correct message notifier
> > > > must be used.
> > > > 
> > > > I think such solution is much much more complicated, there are lot
> > > > of combinations of kernel configuration and available dell
> > > > devices...
> > > 
> > > I tried a few more things, but ultimately failed to find a nice way
> > > to implement this.
> > > 
> > > Another issue popped up, though.  Linus' master branch contains a
> > > recent commit by Benjamin Tissoires (CC'ed), 4d5538f5882a ("i2c: use
> > > an IRQ to report Host Notify events, not alert") which breaks your
> > > patch.  The reason for that is that lis3lv02d relies on the i2c
> > > client's IRQ being 0 to detect that it should not create
> > > /dev/freefall.  Benjamin's patch causes the Host Notify IRQ to be
> > > assigned to the i2c client your patch creates, thus causing
> > > lis3lv02d to create /dev/freefall, which in turn conflicts with
> > > dell-smo8800 which is trying to create /dev/freefall itself.
> > 
> > So 4d5538f5882a is breaking lis3lv02d driver...
> 
> Apologies for that.
> 
> I could easily fix this by adding a kernel API to know whether the
> provided irq is from Host Notify or if it was coming from an actual
> declaration. However, I have no idea how many other drivers would
> require this (hopefully only this one).
> 
> One other solution would be to reserve the Host Notify IRQ and let the
> actual drivers that need it to set it, but this was not the best
> solution according to Dmitri. On my side, I am not entirely against this
> given that it's a chip feature, so the driver should be able to know
> that it's available.
> 
> Dmitri, Wolfram, Jean, any preferences?

I read this:

"IIRC both dell-smo8800 and lis3lv02d represent one HW device (that ST
microelectronics accelerometer) but due to complicated HW abstraction
and layers on Dell laptops it is handled by two drivers, one ACPI and
one i2c."

and that is the core of the issue. You have 2 drivers fighting over the
same device. Fix this and it will all work.

As far as I can see hp_accel instantiates lis3lv02d and accesses it via
ACPI methods, can the same be done for Dell?

> 
> > 
> > > Also, just to make sure we do not overthink this, I understand that
> > > not every unit of the models from the whitelist has an
> > > accelerometer, correct?  In other words, could we perhaps skip the
> > > part where we are making sure the SMO88xx ACPI device is there?
> > 
> > Good question... At least for E6440 I'm did not thing it was possible to 
> > configure notebook without "3 axes free fall sensor".
> > 
> > But! In BIOS SETUP it is possible to disable free fall sensor. I will 
> > try to disable it there and will check what happen. My guess is that it 
> > will be disabled in ACPI.
> 
> Just adding my 2 cents regarding the whitelist and interaction between
> those 2 drivers. I find this very fragile to have only one available
> /dev/freefall node and to rely on the fairness of each driver to not bind
> one. It would have been much simpler to have /dev/freefallXX and a
> proper misc class device for it. This way, we don't even need to
> mutually exclude the drivers. But this is already 8 years old code, so I
> guess userspace expects this... (why isn't that using the input subsystem
> at all?).

I do not consider throwing a unit down an ordinary user interaction ;)
So there is no input event code for this.

Userspace should really use IIO accelerometer interface here. And kernel
could provide composite IIO->/dev/freefall bridge, like we did for
/dev/input/mice when all userspace wanted only PS/2.

Thanks.

-- 
Dmitry

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 9073 bytes --]

On Tuesday 03 January 2017 19:38:43 Dmitry Torokhov wrote:
> On Tue, Jan 03, 2017 at 10:06:41AM +0100, Benjamin Tissoires wrote:
> > On Dec 29 2016 or thereabouts, Pali Rohár wrote:
> > > On Thursday 29 December 2016 22:09:32 Michał Kępień wrote:
> > > > > On Thursday 29 December 2016 14:47:19 Michał Kępień wrote:
> > > > > > > On Thursday 29 December 2016 09:29:36 Michał Kępień wrote:
> > > > > > > > > Dell platform team told us that some (DMI
> > > > > > > > > whitelisted) Dell Latitude machines have ST
> > > > > > > > > microelectronics accelerometer at i2c address 0x29.
> > > > > > > > > That i2c address is not specified in DMI or ACPI, so
> > > > > > > > > runtime detection without whitelist which is below
> > > > > > > > > is not possible.
> > > > > > > > > 
> > > > > > > > > Presence of that ST microelectronics accelerometer is
> > > > > > > > > verified by existence of SMO88xx ACPI device which
> > > > > > > > > represent that accelerometer. Unfortunately without
> > > > > > > > > i2c address.
> > > > > > > > 
> > > > > > > > This part of the commit message sounded a bit confusing
> > > > > > > > to me at first because there is already an ACPI driver
> > > > > > > > which handles SMO88xx
> > > > > > > > 
> > > > > > > > devices (dell-smo8800).  My understanding is that:
> > > > > > > >   * the purpose of this patch is to expose a richer
> > > > > > > >   interface (as
> > > > > > > >   
> > > > > > > >     provided by lis3lv02d) to these devices on some
> > > > > > > >     machines,
> > > > > > > >   
> > > > > > > >   * on whitelisted machines, dell-smo8800 and lis3lv02d
> > > > > > > >   can work
> > > > > > > >   
> > > > > > > >     simultaneously (even though dell-smo8800
> > > > > > > >     effectively duplicates the work that lis3lv02d
> > > > > > > >     does).
> > > > > > > 
> > > > > > > No. dell-smo8800 reads from ACPI irq number and exports
> > > > > > > /dev/freefall device which notify userspace about falls.
> > > > > > > lis3lv02d is i2c driver which exports axes of
> > > > > > > accelerometer. Additionaly lis3lv02d can export also
> > > > > > > /dev/freefall if registerer of i2c device provides irq
> > > > > > > number -- which is not case of this patch.
> > > > > > > 
> > > > > > > So both drivers are doing different things and both are
> > > > > > > useful.
> > > > > > > 
> > > > > > > IIRC both dell-smo8800 and lis3lv02d represent one HW
> > > > > > > device (that ST microelectronics accelerometer) but due
> > > > > > > to complicated HW abstraction and layers on Dell laptops
> > > > > > > it is handled by two drivers, one ACPI and one i2c.
> > > > > > > 
> > > > > > > Yes, in ideal world irq number should be passed to
> > > > > > > lis3lv02d driver and that would export whole device
> > > > > > > (with /dev/freefall too), but due to HW abstraction it
> > > > > > > is too much complicated...
> > > > > > 
> > > > > > Why?  AFAICT, all that is required to pass that IRQ number
> > > > > > all the way down to lis3lv02d is to set the irq field of
> > > > > > the struct i2c_board_info you are passing to
> > > > > > i2c_new_device().  And you can extract that IRQ number
> > > > > > e.g. in check_acpi_smo88xx_device(). However, you would
> > > > > > then need to make sure dell-smo8800 does not attempt to
> > > > > > request the same IRQ on whitelisted machines.  This got me
> > > > > > thinking about a way to somehow incorporate your changes
> > > > > > into dell-smo8800 using Wolfram's bus_notifier suggestion,
> > > > > > but I do not have a working solution for now.  What is
> > > > > > tempting about this approach is that you would not have to
> > > > > > scan the ACPI namespace in search of SMO88xx devices,
> > > > > > because smo8800_add() is automatically called for them. 
> > > > > > However, I fear that the resulting solution may be more
> > > > > > complicated than the one you submitted.
> > > > > 
> > > > > Then we need to deal with lot of problems. Order of loading
> > > > > .ko modules is undefined. Binding devices to drivers
> > > > > registered by .ko module is also in "random" order. At any
> > > > > time any of those .ko module can be unloaded or at least
> > > > > device unbind (via sysfs) from driver... And there can be
> > > > > some pathological situation (thanks to adding ACPI layer as
> > > > > Andy pointed) that there will be more SMO88xx devices in
> > > > > ACPI. Plus you can compile kernel with and without those
> > > > > modules and also you can blacklist loading them (so compile
> > > > > time check is not enough). And still some correct message
> > > > > notifier must be used.
> > > > > 
> > > > > I think such solution is much much more complicated, there
> > > > > are lot of combinations of kernel configuration and
> > > > > available dell devices...
> > > > 
> > > > I tried a few more things, but ultimately failed to find a nice
> > > > way to implement this.
> > > > 
> > > > Another issue popped up, though.  Linus' master branch contains
> > > > a recent commit by Benjamin Tissoires (CC'ed), 4d5538f5882a
> > > > ("i2c: use an IRQ to report Host Notify events, not alert")
> > > > which breaks your patch.  The reason for that is that
> > > > lis3lv02d relies on the i2c client's IRQ being 0 to detect
> > > > that it should not create /dev/freefall.  Benjamin's patch
> > > > causes the Host Notify IRQ to be assigned to the i2c client
> > > > your patch creates, thus causing lis3lv02d to create
> > > > /dev/freefall, which in turn conflicts with dell-smo8800 which
> > > > is trying to create /dev/freefall itself.
> > > 
> > > So 4d5538f5882a is breaking lis3lv02d driver...
> > 
> > Apologies for that.
> > 
> > I could easily fix this by adding a kernel API to know whether the
> > provided irq is from Host Notify or if it was coming from an actual
> > declaration. However, I have no idea how many other drivers would
> > require this (hopefully only this one).
> > 
> > One other solution would be to reserve the Host Notify IRQ and let
> > the actual drivers that need it to set it, but this was not the
> > best solution according to Dmitri. On my side, I am not entirely
> > against this given that it's a chip feature, so the driver should
> > be able to know that it's available.
> > 
> > Dmitri, Wolfram, Jean, any preferences?
> 
> I read this:
> 
> "IIRC both dell-smo8800 and lis3lv02d represent one HW device (that
> ST microelectronics accelerometer) but due to complicated HW
> abstraction and layers on Dell laptops it is handled by two drivers,
> one ACPI and one i2c."
> 
> and that is the core of the issue. You have 2 drivers fighting over
> the same device. Fix this and it will all work.

With my current implementation (which I sent in this patch), they are 
not fighting.

dell-smo8800 exports /dev/freefall (and nothing more) and lis3lv02d only 
accelerometer device as lis3lv02d driver does not get IRQ number in 
platform data.

> As far as I can see hp_accel instantiates lis3lv02d and accesses it
> via ACPI methods, can the same be done for Dell?

No, Dell does not have any ACPI methods. And as I wrote in ACPI or DMI 
is even not i2c address of device, so it needs to be specified in code 
itself.

Really there is no other way... :-(

> > > > Also, just to make sure we do not overthink this, I understand
> > > > that not every unit of the models from the whitelist has an
> > > > accelerometer, correct?  In other words, could we perhaps skip
> > > > the part where we are making sure the SMO88xx ACPI device is
> > > > there?
> > > 
> > > Good question... At least for E6440 I'm did not thing it was
> > > possible to configure notebook without "3 axes free fall
> > > sensor".
> > > 
> > > But! In BIOS SETUP it is possible to disable free fall sensor. I
> > > will try to disable it there and will check what happen. My
> > > guess is that it will be disabled in ACPI.
> > 
> > Just adding my 2 cents regarding the whitelist and interaction
> > between those 2 drivers. I find this very fragile to have only one
> > available /dev/freefall node and to rely on the fairness of each
> > driver to not bind one. It would have been much simpler to have
> > /dev/freefallXX and a proper misc class device for it. This way,
> > we don't even need to mutually exclude the drivers. But this is
> > already 8 years old code, so I guess userspace expects this...
> > (why isn't that using the input subsystem at all?).
> 
> I do not consider throwing a unit down an ordinary user interaction
> ;) So there is no input event code for this.
> 
> Userspace should really use IIO accelerometer interface here. And
> kernel could provide composite IIO->/dev/freefall bridge, like we

Such "generic" bridge is probably not possible, as /dev/freefall is 
connected to specific lis3lv02d IRQ.

> did for /dev/input/mice when all userspace wanted only PS/2.
> 
> Thanks.

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

RE: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Mario.Limonciello]

> -----Original Message-----
> From: Pali Rohár [mailto:pali.rohar@gmail.com]
> Sent: Tuesday, January 3, 2017 12:50 PM
> To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>; Michał Kępień
> <kernel@kempniu.pl>; Jean Delvare <jdelvare@suse.com>; Wolfram Sang
> <wsa@the-dreams.de>; Steven Honeyman <stevenhoneyman@gmail.com>;
> Valdis.Kletnieks@vt.edu; Jochen Eisinger <jochen@penguin-breeder.org>;
> Gabriele Mazzotta <gabriele.mzt@gmail.com>; Andy Lutomirski
> <luto@kernel.org>; Limonciello, Mario <Mario_Limonciello@Dell.com>; Alex
> Hung <alex.hung@canonical.com>; Takashi Iwai <tiwai@suse.de>; linux-
> i2c@vger.kernel.org; linux-kernel@vger.kernel.org; platform-driver-
> x86@vger.kernel.org
> Subject: Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell
> machines
> 
> On Tuesday 03 January 2017 19:38:43 Dmitry Torokhov wrote:
> > On Tue, Jan 03, 2017 at 10:06:41AM +0100, Benjamin Tissoires wrote:
> > > On Dec 29 2016 or thereabouts, Pali Rohár wrote:
> > > > On Thursday 29 December 2016 22:09:32 Michał Kępień wrote:
> > > > > > On Thursday 29 December 2016 14:47:19 Michał Kępień wrote:
> > > > > > > > On Thursday 29 December 2016 09:29:36 Michał Kępień wrote:
> > > > > > > > > > Dell platform team told us that some (DMI
> > > > > > > > > > whitelisted) Dell Latitude machines have ST
> > > > > > > > > > microelectronics accelerometer at i2c address 0x29.
> > > > > > > > > > That i2c address is not specified in DMI or ACPI, so
> > > > > > > > > > runtime detection without whitelist which is below is
> > > > > > > > > > not possible.
> > > > > > > > > >
> > > > > > > > > > Presence of that ST microelectronics accelerometer is
> > > > > > > > > > verified by existence of SMO88xx ACPI device which
> > > > > > > > > > represent that accelerometer. Unfortunately without
> > > > > > > > > > i2c address.
> > > > > > > > >
> > > > > > > > > This part of the commit message sounded a bit confusing
> > > > > > > > > to me at first because there is already an ACPI driver
> > > > > > > > > which handles SMO88xx
> > > > > > > > >
> > > > > > > > > devices (dell-smo8800).  My understanding is that:
> > > > > > > > >   * the purpose of this patch is to expose a richer
> > > > > > > > >   interface (as
> > > > > > > > >
> > > > > > > > >     provided by lis3lv02d) to these devices on some
> > > > > > > > >     machines,
> > > > > > > > >
> > > > > > > > >   * on whitelisted machines, dell-smo8800 and lis3lv02d
> > > > > > > > >   can work
> > > > > > > > >
> > > > > > > > >     simultaneously (even though dell-smo8800
> > > > > > > > >     effectively duplicates the work that lis3lv02d
> > > > > > > > >     does).
> > > > > > > >
> > > > > > > > No. dell-smo8800 reads from ACPI irq number and exports
> > > > > > > > /dev/freefall device which notify userspace about falls.
> > > > > > > > lis3lv02d is i2c driver which exports axes of
> > > > > > > > accelerometer. Additionaly lis3lv02d can export also
> > > > > > > > /dev/freefall if registerer of i2c device provides irq
> > > > > > > > number -- which is not case of this patch.
> > > > > > > >
> > > > > > > > So both drivers are doing different things and both are
> > > > > > > > useful.
> > > > > > > >
> > > > > > > > IIRC both dell-smo8800 and lis3lv02d represent one HW
> > > > > > > > device (that ST microelectronics accelerometer) but due to
> > > > > > > > complicated HW abstraction and layers on Dell laptops it
> > > > > > > > is handled by two drivers, one ACPI and one i2c.
> > > > > > > >
> > > > > > > > Yes, in ideal world irq number should be passed to
> > > > > > > > lis3lv02d driver and that would export whole device (with
> > > > > > > > /dev/freefall too), but due to HW abstraction it is too
> > > > > > > > much complicated...
> > > > > > >
> > > > > > > Why?  AFAICT, all that is required to pass that IRQ number
> > > > > > > all the way down to lis3lv02d is to set the irq field of the
> > > > > > > struct i2c_board_info you are passing to i2c_new_device().
> > > > > > > And you can extract that IRQ number e.g. in
> > > > > > > check_acpi_smo88xx_device(). However, you would then need to
> > > > > > > make sure dell-smo8800 does not attempt to request the same
> > > > > > > IRQ on whitelisted machines.  This got me thinking about a
> > > > > > > way to somehow incorporate your changes into dell-smo8800
> > > > > > > using Wolfram's bus_notifier suggestion, but I do not have a
> > > > > > > working solution for now.  What is tempting about this
> > > > > > > approach is that you would not have to scan the ACPI
> > > > > > > namespace in search of SMO88xx devices, because
> > > > > > > smo8800_add() is automatically called for them.
> > > > > > > However, I fear that the resulting solution may be more
> > > > > > > complicated than the one you submitted.
> > > > > >
> > > > > > Then we need to deal with lot of problems. Order of loading
> > > > > > .ko modules is undefined. Binding devices to drivers
> > > > > > registered by .ko module is also in "random" order. At any
> > > > > > time any of those .ko module can be unloaded or at least
> > > > > > device unbind (via sysfs) from driver... And there can be some
> > > > > > pathological situation (thanks to adding ACPI layer as Andy
> > > > > > pointed) that there will be more SMO88xx devices in ACPI. Plus
> > > > > > you can compile kernel with and without those modules and also
> > > > > > you can blacklist loading them (so compile time check is not
> > > > > > enough). And still some correct message notifier must be used.
> > > > > >
> > > > > > I think such solution is much much more complicated, there are
> > > > > > lot of combinations of kernel configuration and available dell
> > > > > > devices...
> > > > >
> > > > > I tried a few more things, but ultimately failed to find a nice
> > > > > way to implement this.
> > > > >
> > > > > Another issue popped up, though.  Linus' master branch contains
> > > > > a recent commit by Benjamin Tissoires (CC'ed), 4d5538f5882a
> > > > > ("i2c: use an IRQ to report Host Notify events, not alert")
> > > > > which breaks your patch.  The reason for that is that lis3lv02d
> > > > > relies on the i2c client's IRQ being 0 to detect that it should
> > > > > not create /dev/freefall.  Benjamin's patch causes the Host
> > > > > Notify IRQ to be assigned to the i2c client your patch creates,
> > > > > thus causing lis3lv02d to create /dev/freefall, which in turn
> > > > > conflicts with dell-smo8800 which is trying to create
> > > > > /dev/freefall itself.
> > > >
> > > > So 4d5538f5882a is breaking lis3lv02d driver...
> > >
> > > Apologies for that.
> > >
> > > I could easily fix this by adding a kernel API to know whether the
> > > provided irq is from Host Notify or if it was coming from an actual
> > > declaration. However, I have no idea how many other drivers would
> > > require this (hopefully only this one).
> > >
> > > One other solution would be to reserve the Host Notify IRQ and let
> > > the actual drivers that need it to set it, but this was not the best
> > > solution according to Dmitri. On my side, I am not entirely against
> > > this given that it's a chip feature, so the driver should be able to
> > > know that it's available.
> > >
> > > Dmitri, Wolfram, Jean, any preferences?
> >
> > I read this:
> >
> > "IIRC both dell-smo8800 and lis3lv02d represent one HW device (that ST
> > microelectronics accelerometer) but due to complicated HW abstraction
> > and layers on Dell laptops it is handled by two drivers, one ACPI and
> > one i2c."
> >
> > and that is the core of the issue. You have 2 drivers fighting over
> > the same device. Fix this and it will all work.
> 
> With my current implementation (which I sent in this patch), they are not
> fighting.
> 
> dell-smo8800 exports /dev/freefall (and nothing more) and lis3lv02d only
> accelerometer device as lis3lv02d driver does not get IRQ number in platform
> data.
> 
> > As far as I can see hp_accel instantiates lis3lv02d and accesses it
> > via ACPI methods, can the same be done for Dell?
> 
> No, Dell does not have any ACPI methods. And as I wrote in ACPI or DMI is even
> not i2c address of device, so it needs to be specified in code itself.
> 
> Really there is no other way... :-(

Dell doesn't export the general purpose accelerometer 
data up to the OS.

Pali wanted it however and came up with a way to access it though 
from the information we have shared.

That's the reason that there is no ACPI method for this and it needs
to be whitelisted in this driver on the platforms that have it wired
up this way.


> 
> > > > > Also, just to make sure we do not overthink this, I understand
> > > > > that not every unit of the models from the whitelist has an
> > > > > accelerometer, correct?  In other words, could we perhaps skip
> > > > > the part where we are making sure the SMO88xx ACPI device is
> > > > > there?
> > > >
> > > > Good question... At least for E6440 I'm did not thing it was
> > > > possible to configure notebook without "3 axes free fall sensor".
> > > >
> > > > But! In BIOS SETUP it is possible to disable free fall sensor. I
> > > > will try to disable it there and will check what happen. My guess
> > > > is that it will be disabled in ACPI.
> > >
> > > Just adding my 2 cents regarding the whitelist and interaction
> > > between those 2 drivers. I find this very fragile to have only one
> > > available /dev/freefall node and to rely on the fairness of each
> > > driver to not bind one. It would have been much simpler to have
> > > /dev/freefallXX and a proper misc class device for it. This way, we
> > > don't even need to mutually exclude the drivers. But this is already
> > > 8 years old code, so I guess userspace expects this...
> > > (why isn't that using the input subsystem at all?).
> >
> > I do not consider throwing a unit down an ordinary user interaction
> > ;) So there is no input event code for this.
> >
> > Userspace should really use IIO accelerometer interface here. And
> > kernel could provide composite IIO->/dev/freefall bridge, like we
> 
> Such "generic" bridge is probably not possible, as /dev/freefall is connected to
> specific lis3lv02d IRQ.
> 
> > did for /dev/input/mice when all userspace wanted only PS/2.
> >
> > Thanks.
> 
> --
> Pali Rohár
> pali.rohar@gmail.com

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Dmitry Torokhov]

On Tue, Jan 03, 2017 at 07:50:17PM +0100, Pali Rohár wrote:
> On Tuesday 03 January 2017 19:38:43 Dmitry Torokhov wrote:
> > On Tue, Jan 03, 2017 at 10:06:41AM +0100, Benjamin Tissoires wrote:
> > > On Dec 29 2016 or thereabouts, Pali Rohár wrote:
> > > > On Thursday 29 December 2016 22:09:32 Michał Kępień wrote:
> > > > > > On Thursday 29 December 2016 14:47:19 Michał Kępień wrote:
> > > > > > > > On Thursday 29 December 2016 09:29:36 Michał Kępień wrote:
> > > > > > > > > > Dell platform team told us that some (DMI
> > > > > > > > > > whitelisted) Dell Latitude machines have ST
> > > > > > > > > > microelectronics accelerometer at i2c address 0x29.
> > > > > > > > > > That i2c address is not specified in DMI or ACPI, so
> > > > > > > > > > runtime detection without whitelist which is below
> > > > > > > > > > is not possible.
> > > > > > > > > > 
> > > > > > > > > > Presence of that ST microelectronics accelerometer is
> > > > > > > > > > verified by existence of SMO88xx ACPI device which
> > > > > > > > > > represent that accelerometer. Unfortunately without
> > > > > > > > > > i2c address.
> > > > > > > > > 
> > > > > > > > > This part of the commit message sounded a bit confusing
> > > > > > > > > to me at first because there is already an ACPI driver
> > > > > > > > > which handles SMO88xx
> > > > > > > > > 
> > > > > > > > > devices (dell-smo8800).  My understanding is that:
> > > > > > > > >   * the purpose of this patch is to expose a richer
> > > > > > > > >   interface (as
> > > > > > > > >   
> > > > > > > > >     provided by lis3lv02d) to these devices on some
> > > > > > > > >     machines,
> > > > > > > > >   
> > > > > > > > >   * on whitelisted machines, dell-smo8800 and lis3lv02d
> > > > > > > > >   can work
> > > > > > > > >   
> > > > > > > > >     simultaneously (even though dell-smo8800
> > > > > > > > >     effectively duplicates the work that lis3lv02d
> > > > > > > > >     does).
> > > > > > > > 
> > > > > > > > No. dell-smo8800 reads from ACPI irq number and exports
> > > > > > > > /dev/freefall device which notify userspace about falls.
> > > > > > > > lis3lv02d is i2c driver which exports axes of
> > > > > > > > accelerometer. Additionaly lis3lv02d can export also
> > > > > > > > /dev/freefall if registerer of i2c device provides irq
> > > > > > > > number -- which is not case of this patch.
> > > > > > > > 
> > > > > > > > So both drivers are doing different things and both are
> > > > > > > > useful.
> > > > > > > > 
> > > > > > > > IIRC both dell-smo8800 and lis3lv02d represent one HW
> > > > > > > > device (that ST microelectronics accelerometer) but due
> > > > > > > > to complicated HW abstraction and layers on Dell laptops
> > > > > > > > it is handled by two drivers, one ACPI and one i2c.
> > > > > > > > 
> > > > > > > > Yes, in ideal world irq number should be passed to
> > > > > > > > lis3lv02d driver and that would export whole device
> > > > > > > > (with /dev/freefall too), but due to HW abstraction it
> > > > > > > > is too much complicated...
> > > > > > > 
> > > > > > > Why?  AFAICT, all that is required to pass that IRQ number
> > > > > > > all the way down to lis3lv02d is to set the irq field of
> > > > > > > the struct i2c_board_info you are passing to
> > > > > > > i2c_new_device().  And you can extract that IRQ number
> > > > > > > e.g. in check_acpi_smo88xx_device(). However, you would
> > > > > > > then need to make sure dell-smo8800 does not attempt to
> > > > > > > request the same IRQ on whitelisted machines.  This got me
> > > > > > > thinking about a way to somehow incorporate your changes
> > > > > > > into dell-smo8800 using Wolfram's bus_notifier suggestion,
> > > > > > > but I do not have a working solution for now.  What is
> > > > > > > tempting about this approach is that you would not have to
> > > > > > > scan the ACPI namespace in search of SMO88xx devices,
> > > > > > > because smo8800_add() is automatically called for them. 
> > > > > > > However, I fear that the resulting solution may be more
> > > > > > > complicated than the one you submitted.
> > > > > > 
> > > > > > Then we need to deal with lot of problems. Order of loading
> > > > > > .ko modules is undefined. Binding devices to drivers
> > > > > > registered by .ko module is also in "random" order. At any
> > > > > > time any of those .ko module can be unloaded or at least
> > > > > > device unbind (via sysfs) from driver... And there can be
> > > > > > some pathological situation (thanks to adding ACPI layer as
> > > > > > Andy pointed) that there will be more SMO88xx devices in
> > > > > > ACPI. Plus you can compile kernel with and without those
> > > > > > modules and also you can blacklist loading them (so compile
> > > > > > time check is not enough). And still some correct message
> > > > > > notifier must be used.
> > > > > > 
> > > > > > I think such solution is much much more complicated, there
> > > > > > are lot of combinations of kernel configuration and
> > > > > > available dell devices...
> > > > > 
> > > > > I tried a few more things, but ultimately failed to find a nice
> > > > > way to implement this.
> > > > > 
> > > > > Another issue popped up, though.  Linus' master branch contains
> > > > > a recent commit by Benjamin Tissoires (CC'ed), 4d5538f5882a
> > > > > ("i2c: use an IRQ to report Host Notify events, not alert")
> > > > > which breaks your patch.  The reason for that is that
> > > > > lis3lv02d relies on the i2c client's IRQ being 0 to detect
> > > > > that it should not create /dev/freefall.  Benjamin's patch
> > > > > causes the Host Notify IRQ to be assigned to the i2c client
> > > > > your patch creates, thus causing lis3lv02d to create
> > > > > /dev/freefall, which in turn conflicts with dell-smo8800 which
> > > > > is trying to create /dev/freefall itself.
> > > > 
> > > > So 4d5538f5882a is breaking lis3lv02d driver...
> > > 
> > > Apologies for that.
> > > 
> > > I could easily fix this by adding a kernel API to know whether the
> > > provided irq is from Host Notify or if it was coming from an actual
> > > declaration. However, I have no idea how many other drivers would
> > > require this (hopefully only this one).
> > > 
> > > One other solution would be to reserve the Host Notify IRQ and let
> > > the actual drivers that need it to set it, but this was not the
> > > best solution according to Dmitri. On my side, I am not entirely
> > > against this given that it's a chip feature, so the driver should
> > > be able to know that it's available.
> > > 
> > > Dmitri, Wolfram, Jean, any preferences?
> > 
> > I read this:
> > 
> > "IIRC both dell-smo8800 and lis3lv02d represent one HW device (that
> > ST microelectronics accelerometer) but due to complicated HW
> > abstraction and layers on Dell laptops it is handled by two drivers,
> > one ACPI and one i2c."
> > 
> > and that is the core of the issue. You have 2 drivers fighting over
> > the same device. Fix this and it will all work.
> 
> With my current implementation (which I sent in this patch), they are 
> not fighting.
> 
> dell-smo8800 exports /dev/freefall (and nothing more) and lis3lv02d only 
> accelerometer device as lis3lv02d driver does not get IRQ number in 
> platform data.
> 
> > As far as I can see hp_accel instantiates lis3lv02d and accesses it
> > via ACPI methods, can the same be done for Dell?
> 
> No, Dell does not have any ACPI methods. And as I wrote in ACPI or DMI 
> is even not i2c address of device, so it needs to be specified in code 
> itself.
> 
> Really there is no other way... :-(

Sure there is:

1. dell-smo8800 instantiates I2C device as "dell-smo8800-accel".
2. dell-smo8800 provides read/write functions for lis3lv02d that simply
   forward requests to dell-smo8800-accel i2c client.
3. dell-smo8800 instantiates lis3lv02d instance like hp_accel does.

Alternatively, can lis3lv02d be tasked to create /dev/freefall?

Yet another option: can we add a new flag to i2c_board_info controlling
whether we want to enable/disable wiring up host notify interrupt?
Benjamin, is there anything "special" in RMI SMbus ACPI descriptors we
could use?

Thanks.

-- 
Dmitry

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 9473 bytes --]

On Tuesday 03 January 2017 20:48:12 Dmitry Torokhov wrote:
> On Tue, Jan 03, 2017 at 07:50:17PM +0100, Pali Rohár wrote:
> > On Tuesday 03 January 2017 19:38:43 Dmitry Torokhov wrote:
> > > On Tue, Jan 03, 2017 at 10:06:41AM +0100, Benjamin Tissoires
> > > wrote:
> > > > On Dec 29 2016 or thereabouts, Pali Rohár wrote:
> > > > > On Thursday 29 December 2016 22:09:32 Michał Kępień wrote:
> > > > > > > On Thursday 29 December 2016 14:47:19 Michał Kępień wrote:
> > > > > > > > > On Thursday 29 December 2016 09:29:36 Michał Kępień
> > > > > > > > > wrote:
> > > > > > > > > > > Dell platform team told us that some (DMI
> > > > > > > > > > > whitelisted) Dell Latitude machines have ST
> > > > > > > > > > > microelectronics accelerometer at i2c address
> > > > > > > > > > > 0x29. That i2c address is not specified in DMI
> > > > > > > > > > > or ACPI, so runtime detection without whitelist
> > > > > > > > > > > which is below is not possible.
> > > > > > > > > > > 
> > > > > > > > > > > Presence of that ST microelectronics
> > > > > > > > > > > accelerometer is verified by existence of
> > > > > > > > > > > SMO88xx ACPI device which represent that
> > > > > > > > > > > accelerometer. Unfortunately without i2c
> > > > > > > > > > > address.
> > > > > > > > > > 
> > > > > > > > > > This part of the commit message sounded a bit
> > > > > > > > > > confusing to me at first because there is already
> > > > > > > > > > an ACPI driver which handles SMO88xx
> > > > > > > > > > 
> > > > > > > > > > devices (dell-smo8800).  My understanding is that:
> > > > > > > > > >   * the purpose of this patch is to expose a richer
> > > > > > > > > >   interface (as
> > > > > > > > > >   
> > > > > > > > > >     provided by lis3lv02d) to these devices on some
> > > > > > > > > >     machines,
> > > > > > > > > >   
> > > > > > > > > >   * on whitelisted machines, dell-smo8800 and
> > > > > > > > > >   lis3lv02d can work
> > > > > > > > > >   
> > > > > > > > > >     simultaneously (even though dell-smo8800
> > > > > > > > > >     effectively duplicates the work that lis3lv02d
> > > > > > > > > >     does).
> > > > > > > > > 
> > > > > > > > > No. dell-smo8800 reads from ACPI irq number and
> > > > > > > > > exports /dev/freefall device which notify userspace
> > > > > > > > > about falls. lis3lv02d is i2c driver which exports
> > > > > > > > > axes of accelerometer. Additionaly lis3lv02d can
> > > > > > > > > export also /dev/freefall if registerer of i2c
> > > > > > > > > device provides irq number -- which is not case of
> > > > > > > > > this patch.
> > > > > > > > > 
> > > > > > > > > So both drivers are doing different things and both
> > > > > > > > > are useful.
> > > > > > > > > 
> > > > > > > > > IIRC both dell-smo8800 and lis3lv02d represent one HW
> > > > > > > > > device (that ST microelectronics accelerometer) but
> > > > > > > > > due to complicated HW abstraction and layers on Dell
> > > > > > > > > laptops it is handled by two drivers, one ACPI and
> > > > > > > > > one i2c.
> > > > > > > > > 
> > > > > > > > > Yes, in ideal world irq number should be passed to
> > > > > > > > > lis3lv02d driver and that would export whole device
> > > > > > > > > (with /dev/freefall too), but due to HW abstraction
> > > > > > > > > it is too much complicated...
> > > > > > > > 
> > > > > > > > Why?  AFAICT, all that is required to pass that IRQ
> > > > > > > > number all the way down to lis3lv02d is to set the irq
> > > > > > > > field of the struct i2c_board_info you are passing to
> > > > > > > > i2c_new_device().  And you can extract that IRQ number
> > > > > > > > e.g. in check_acpi_smo88xx_device(). However, you would
> > > > > > > > then need to make sure dell-smo8800 does not attempt to
> > > > > > > > request the same IRQ on whitelisted machines.  This got
> > > > > > > > me thinking about a way to somehow incorporate your
> > > > > > > > changes into dell-smo8800 using Wolfram's bus_notifier
> > > > > > > > suggestion, but I do not have a working solution for
> > > > > > > > now.  What is tempting about this approach is that you
> > > > > > > > would not have to scan the ACPI namespace in search of
> > > > > > > > SMO88xx devices, because smo8800_add() is
> > > > > > > > automatically called for them. However, I fear that
> > > > > > > > the resulting solution may be more complicated than
> > > > > > > > the one you submitted.
> > > > > > > 
> > > > > > > Then we need to deal with lot of problems. Order of
> > > > > > > loading .ko modules is undefined. Binding devices to
> > > > > > > drivers registered by .ko module is also in "random"
> > > > > > > order. At any time any of those .ko module can be
> > > > > > > unloaded or at least device unbind (via sysfs) from
> > > > > > > driver... And there can be some pathological situation
> > > > > > > (thanks to adding ACPI layer as Andy pointed) that there
> > > > > > > will be more SMO88xx devices in ACPI. Plus you can
> > > > > > > compile kernel with and without those modules and also
> > > > > > > you can blacklist loading them (so compile time check is
> > > > > > > not enough). And still some correct message notifier
> > > > > > > must be used.
> > > > > > > 
> > > > > > > I think such solution is much much more complicated,
> > > > > > > there are lot of combinations of kernel configuration
> > > > > > > and available dell devices...
> > > > > > 
> > > > > > I tried a few more things, but ultimately failed to find a
> > > > > > nice way to implement this.
> > > > > > 
> > > > > > Another issue popped up, though.  Linus' master branch
> > > > > > contains a recent commit by Benjamin Tissoires (CC'ed),
> > > > > > 4d5538f5882a ("i2c: use an IRQ to report Host Notify
> > > > > > events, not alert") which breaks your patch.  The reason
> > > > > > for that is that lis3lv02d relies on the i2c client's IRQ
> > > > > > being 0 to detect that it should not create /dev/freefall.
> > > > > >  Benjamin's patch causes the Host Notify IRQ to be
> > > > > > assigned to the i2c client your patch creates, thus
> > > > > > causing lis3lv02d to create /dev/freefall, which in turn
> > > > > > conflicts with dell-smo8800 which is trying to create
> > > > > > /dev/freefall itself.
> > > > > 
> > > > > So 4d5538f5882a is breaking lis3lv02d driver...
> > > > 
> > > > Apologies for that.
> > > > 
> > > > I could easily fix this by adding a kernel API to know whether
> > > > the provided irq is from Host Notify or if it was coming from
> > > > an actual declaration. However, I have no idea how many other
> > > > drivers would require this (hopefully only this one).
> > > > 
> > > > One other solution would be to reserve the Host Notify IRQ and
> > > > let the actual drivers that need it to set it, but this was
> > > > not the best solution according to Dmitri. On my side, I am
> > > > not entirely against this given that it's a chip feature, so
> > > > the driver should be able to know that it's available.
> > > > 
> > > > Dmitri, Wolfram, Jean, any preferences?
> > > 
> > > I read this:
> > > 
> > > "IIRC both dell-smo8800 and lis3lv02d represent one HW device
> > > (that ST microelectronics accelerometer) but due to complicated
> > > HW abstraction and layers on Dell laptops it is handled by two
> > > drivers, one ACPI and one i2c."
> > > 
> > > and that is the core of the issue. You have 2 drivers fighting
> > > over the same device. Fix this and it will all work.
> > 
> > With my current implementation (which I sent in this patch), they
> > are not fighting.
> > 
> > dell-smo8800 exports /dev/freefall (and nothing more) and lis3lv02d
> > only accelerometer device as lis3lv02d driver does not get IRQ
> > number in platform data.
> > 
> > > As far as I can see hp_accel instantiates lis3lv02d and accesses
> > > it via ACPI methods, can the same be done for Dell?
> > 
> > No, Dell does not have any ACPI methods. And as I wrote in ACPI or
> > DMI is even not i2c address of device, so it needs to be specified
> > in code itself.
> > 
> > Really there is no other way... :-(
> 
> Sure there is:
> 
> 1. dell-smo8800 instantiates I2C device as "dell-smo8800-accel".
> 2. dell-smo8800 provides read/write functions for lis3lv02d that
> simply forward requests to dell-smo8800-accel i2c client.
> 3. dell-smo8800 instantiates lis3lv02d instance like hp_accel does.

Sorry, but I do not understand how you mean it... Why to provides new 
read/write i2c functions which are already implemented by i2c-i801 bus 
and lis3lv02d i2c driver?

> Alternatively, can lis3lv02d be tasked to create /dev/freefall?

If i2c_board_info contains IRQ then lis3lv02d create /dev/freefall 
device.

But... what is problem with current implementation? Accelerometer HW 
provides two functions:

1) 3 axes reports
2) Disk freefall detection

And 1) is handled by i2c driver lis3lv02d and 2) is by dell-smo8800. 
Both functions are independent here.

I think you just trying to complicate this situation even more to be 
more complicated as currently is.

> Yet another option: can we add a new flag to i2c_board_info
> controlling whether we want to enable/disable wiring up host notify
> interrupt? Benjamin, is there anything "special" in RMI SMbus ACPI
> descriptors we could use?
> 
> Thanks.

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Dmitry Torokhov]

On Tue, Jan 03, 2017 at 09:05:51PM +0100, Pali Rohár wrote:
> On Tuesday 03 January 2017 20:48:12 Dmitry Torokhov wrote:
> > On Tue, Jan 03, 2017 at 07:50:17PM +0100, Pali Rohár wrote:
> > > On Tuesday 03 January 2017 19:38:43 Dmitry Torokhov wrote:
> > > > On Tue, Jan 03, 2017 at 10:06:41AM +0100, Benjamin Tissoires
> > > > wrote:
> > > > > On Dec 29 2016 or thereabouts, Pali Rohár wrote:
> > > > > > On Thursday 29 December 2016 22:09:32 Michał Kępień wrote:
> > > > > > > > On Thursday 29 December 2016 14:47:19 Michał Kępień wrote:
> > > > > > > > > > On Thursday 29 December 2016 09:29:36 Michał Kępień
> > > > > > > > > > wrote:
> > > > > > > > > > > > Dell platform team told us that some (DMI
> > > > > > > > > > > > whitelisted) Dell Latitude machines have ST
> > > > > > > > > > > > microelectronics accelerometer at i2c address
> > > > > > > > > > > > 0x29. That i2c address is not specified in DMI
> > > > > > > > > > > > or ACPI, so runtime detection without whitelist
> > > > > > > > > > > > which is below is not possible.
> > > > > > > > > > > > 
> > > > > > > > > > > > Presence of that ST microelectronics
> > > > > > > > > > > > accelerometer is verified by existence of
> > > > > > > > > > > > SMO88xx ACPI device which represent that
> > > > > > > > > > > > accelerometer. Unfortunately without i2c
> > > > > > > > > > > > address.
> > > > > > > > > > > 
> > > > > > > > > > > This part of the commit message sounded a bit
> > > > > > > > > > > confusing to me at first because there is already
> > > > > > > > > > > an ACPI driver which handles SMO88xx
> > > > > > > > > > > 
> > > > > > > > > > > devices (dell-smo8800).  My understanding is that:
> > > > > > > > > > >   * the purpose of this patch is to expose a richer
> > > > > > > > > > >   interface (as
> > > > > > > > > > >   
> > > > > > > > > > >     provided by lis3lv02d) to these devices on some
> > > > > > > > > > >     machines,
> > > > > > > > > > >   
> > > > > > > > > > >   * on whitelisted machines, dell-smo8800 and
> > > > > > > > > > >   lis3lv02d can work
> > > > > > > > > > >   
> > > > > > > > > > >     simultaneously (even though dell-smo8800
> > > > > > > > > > >     effectively duplicates the work that lis3lv02d
> > > > > > > > > > >     does).
> > > > > > > > > > 
> > > > > > > > > > No. dell-smo8800 reads from ACPI irq number and
> > > > > > > > > > exports /dev/freefall device which notify userspace
> > > > > > > > > > about falls. lis3lv02d is i2c driver which exports
> > > > > > > > > > axes of accelerometer. Additionaly lis3lv02d can
> > > > > > > > > > export also /dev/freefall if registerer of i2c
> > > > > > > > > > device provides irq number -- which is not case of
> > > > > > > > > > this patch.
> > > > > > > > > > 
> > > > > > > > > > So both drivers are doing different things and both
> > > > > > > > > > are useful.
> > > > > > > > > > 
> > > > > > > > > > IIRC both dell-smo8800 and lis3lv02d represent one HW
> > > > > > > > > > device (that ST microelectronics accelerometer) but
> > > > > > > > > > due to complicated HW abstraction and layers on Dell
> > > > > > > > > > laptops it is handled by two drivers, one ACPI and
> > > > > > > > > > one i2c.
> > > > > > > > > > 
> > > > > > > > > > Yes, in ideal world irq number should be passed to
> > > > > > > > > > lis3lv02d driver and that would export whole device
> > > > > > > > > > (with /dev/freefall too), but due to HW abstraction
> > > > > > > > > > it is too much complicated...
> > > > > > > > > 
> > > > > > > > > Why?  AFAICT, all that is required to pass that IRQ
> > > > > > > > > number all the way down to lis3lv02d is to set the irq
> > > > > > > > > field of the struct i2c_board_info you are passing to
> > > > > > > > > i2c_new_device().  And you can extract that IRQ number
> > > > > > > > > e.g. in check_acpi_smo88xx_device(). However, you would
> > > > > > > > > then need to make sure dell-smo8800 does not attempt to
> > > > > > > > > request the same IRQ on whitelisted machines.  This got
> > > > > > > > > me thinking about a way to somehow incorporate your
> > > > > > > > > changes into dell-smo8800 using Wolfram's bus_notifier
> > > > > > > > > suggestion, but I do not have a working solution for
> > > > > > > > > now.  What is tempting about this approach is that you
> > > > > > > > > would not have to scan the ACPI namespace in search of
> > > > > > > > > SMO88xx devices, because smo8800_add() is
> > > > > > > > > automatically called for them. However, I fear that
> > > > > > > > > the resulting solution may be more complicated than
> > > > > > > > > the one you submitted.
> > > > > > > > 
> > > > > > > > Then we need to deal with lot of problems. Order of
> > > > > > > > loading .ko modules is undefined. Binding devices to
> > > > > > > > drivers registered by .ko module is also in "random"
> > > > > > > > order. At any time any of those .ko module can be
> > > > > > > > unloaded or at least device unbind (via sysfs) from
> > > > > > > > driver... And there can be some pathological situation
> > > > > > > > (thanks to adding ACPI layer as Andy pointed) that there
> > > > > > > > will be more SMO88xx devices in ACPI. Plus you can
> > > > > > > > compile kernel with and without those modules and also
> > > > > > > > you can blacklist loading them (so compile time check is
> > > > > > > > not enough). And still some correct message notifier
> > > > > > > > must be used.
> > > > > > > > 
> > > > > > > > I think such solution is much much more complicated,
> > > > > > > > there are lot of combinations of kernel configuration
> > > > > > > > and available dell devices...
> > > > > > > 
> > > > > > > I tried a few more things, but ultimately failed to find a
> > > > > > > nice way to implement this.
> > > > > > > 
> > > > > > > Another issue popped up, though.  Linus' master branch
> > > > > > > contains a recent commit by Benjamin Tissoires (CC'ed),
> > > > > > > 4d5538f5882a ("i2c: use an IRQ to report Host Notify
> > > > > > > events, not alert") which breaks your patch.  The reason
> > > > > > > for that is that lis3lv02d relies on the i2c client's IRQ
> > > > > > > being 0 to detect that it should not create /dev/freefall.
> > > > > > >  Benjamin's patch causes the Host Notify IRQ to be
> > > > > > > assigned to the i2c client your patch creates, thus
> > > > > > > causing lis3lv02d to create /dev/freefall, which in turn
> > > > > > > conflicts with dell-smo8800 which is trying to create
> > > > > > > /dev/freefall itself.
> > > > > > 
> > > > > > So 4d5538f5882a is breaking lis3lv02d driver...
> > > > > 
> > > > > Apologies for that.
> > > > > 
> > > > > I could easily fix this by adding a kernel API to know whether
> > > > > the provided irq is from Host Notify or if it was coming from
> > > > > an actual declaration. However, I have no idea how many other
> > > > > drivers would require this (hopefully only this one).
> > > > > 
> > > > > One other solution would be to reserve the Host Notify IRQ and
> > > > > let the actual drivers that need it to set it, but this was
> > > > > not the best solution according to Dmitri. On my side, I am
> > > > > not entirely against this given that it's a chip feature, so
> > > > > the driver should be able to know that it's available.
> > > > > 
> > > > > Dmitri, Wolfram, Jean, any preferences?
> > > > 
> > > > I read this:
> > > > 
> > > > "IIRC both dell-smo8800 and lis3lv02d represent one HW device
> > > > (that ST microelectronics accelerometer) but due to complicated
> > > > HW abstraction and layers on Dell laptops it is handled by two
> > > > drivers, one ACPI and one i2c."
> > > > 
> > > > and that is the core of the issue. You have 2 drivers fighting
> > > > over the same device. Fix this and it will all work.
> > > 
> > > With my current implementation (which I sent in this patch), they
> > > are not fighting.
> > > 
> > > dell-smo8800 exports /dev/freefall (and nothing more) and lis3lv02d
> > > only accelerometer device as lis3lv02d driver does not get IRQ
> > > number in platform data.
> > > 
> > > > As far as I can see hp_accel instantiates lis3lv02d and accesses
> > > > it via ACPI methods, can the same be done for Dell?
> > > 
> > > No, Dell does not have any ACPI methods. And as I wrote in ACPI or
> > > DMI is even not i2c address of device, so it needs to be specified
> > > in code itself.
> > > 
> > > Really there is no other way... :-(
> > 
> > Sure there is:
> > 
> > 1. dell-smo8800 instantiates I2C device as "dell-smo8800-accel".
> > 2. dell-smo8800 provides read/write functions for lis3lv02d that
> > simply forward requests to dell-smo8800-accel i2c client.
> > 3. dell-smo8800 instantiates lis3lv02d instance like hp_accel does.
> 
> Sorry, but I do not understand how you mean it... Why to provides new 
> read/write i2c functions which are already implemented by i2c-i801 bus 
> and lis3lv02d i2c driver?

Because that would allow you to avoid clashes with i2c creating
interrupt mapping for client residing on host-notify-capable controller.

> 
> > Alternatively, can lis3lv02d be tasked to create /dev/freefall?
> 
> If i2c_board_info contains IRQ then lis3lv02d create /dev/freefall 
> device.
> 
> But... what is problem with current implementation? Accelerometer HW 
> provides two functions:
> 
> 1) 3 axes reports
> 2) Disk freefall detection
> 
> And 1) is handled by i2c driver lis3lv02d and 2) is by dell-smo8800. 
> Both functions are independent here.
> 
> I think you just trying to complicate this situation even more to be 
> more complicated as currently is.

Because this apparently does not work for you, does it? In general, if
you want the same hardware be handled by 2 different drivers you are
going to have bad time.

It seems to be that /dev/freefall in dell-smo8800 and lis3lv02d are the
same, right? So, instead of having 2 drivers split the functionality,
can you forego registering smo8800 ACPI driver on your whitelisted
boxes and instead instantiate full i2c client device with properly
assigned both address and IRQ and let lis3lv02d handle it (providing
both accelerometer data and /dev/freefall)?

Thanks.

-- 
Dmitry

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 12177 bytes --]

On Tuesday 03 January 2017 21:24:18 Dmitry Torokhov wrote:
> On Tue, Jan 03, 2017 at 09:05:51PM +0100, Pali Rohár wrote:
> > On Tuesday 03 January 2017 20:48:12 Dmitry Torokhov wrote:
> > > On Tue, Jan 03, 2017 at 07:50:17PM +0100, Pali Rohár wrote:
> > > > On Tuesday 03 January 2017 19:38:43 Dmitry Torokhov wrote:
> > > > > On Tue, Jan 03, 2017 at 10:06:41AM +0100, Benjamin Tissoires
> > > > > 
> > > > > wrote:
> > > > > > On Dec 29 2016 or thereabouts, Pali Rohár wrote:
> > > > > > > On Thursday 29 December 2016 22:09:32 Michał Kępień wrote:
> > > > > > > > > On Thursday 29 December 2016 14:47:19 Michał Kępień
> > > > > > > > > wrote:
> > > > > > > > > > > On Thursday 29 December 2016 09:29:36 Michał
> > > > > > > > > > > Kępień
> > > > > > > > > > > 
> > > > > > > > > > > wrote:
> > > > > > > > > > > > > Dell platform team told us that some (DMI
> > > > > > > > > > > > > whitelisted) Dell Latitude machines have ST
> > > > > > > > > > > > > microelectronics accelerometer at i2c address
> > > > > > > > > > > > > 0x29. That i2c address is not specified in
> > > > > > > > > > > > > DMI or ACPI, so runtime detection without
> > > > > > > > > > > > > whitelist which is below is not possible.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Presence of that ST microelectronics
> > > > > > > > > > > > > accelerometer is verified by existence of
> > > > > > > > > > > > > SMO88xx ACPI device which represent that
> > > > > > > > > > > > > accelerometer. Unfortunately without i2c
> > > > > > > > > > > > > address.
> > > > > > > > > > > > 
> > > > > > > > > > > > This part of the commit message sounded a bit
> > > > > > > > > > > > confusing to me at first because there is
> > > > > > > > > > > > already an ACPI driver which handles SMO88xx
> > > > > > > > > > > > 
> > > > > > > > > > > > devices (dell-smo8800).  My understanding is
> > > > > > > > > > > > that:
> > > > > > > > > > > >   * the purpose of this patch is to expose a
> > > > > > > > > > > >   richer interface (as
> > > > > > > > > > > >   
> > > > > > > > > > > >     provided by lis3lv02d) to these devices on
> > > > > > > > > > > >     some machines,
> > > > > > > > > > > >   
> > > > > > > > > > > >   * on whitelisted machines, dell-smo8800 and
> > > > > > > > > > > >   lis3lv02d can work
> > > > > > > > > > > >   
> > > > > > > > > > > >     simultaneously (even though dell-smo8800
> > > > > > > > > > > >     effectively duplicates the work that
> > > > > > > > > > > >     lis3lv02d does).
> > > > > > > > > > > 
> > > > > > > > > > > No. dell-smo8800 reads from ACPI irq number and
> > > > > > > > > > > exports /dev/freefall device which notify
> > > > > > > > > > > userspace about falls. lis3lv02d is i2c driver
> > > > > > > > > > > which exports axes of accelerometer. Additionaly
> > > > > > > > > > > lis3lv02d can export also /dev/freefall if
> > > > > > > > > > > registerer of i2c device provides irq number --
> > > > > > > > > > > which is not case of this patch.
> > > > > > > > > > > 
> > > > > > > > > > > So both drivers are doing different things and
> > > > > > > > > > > both are useful.
> > > > > > > > > > > 
> > > > > > > > > > > IIRC both dell-smo8800 and lis3lv02d represent
> > > > > > > > > > > one HW device (that ST microelectronics
> > > > > > > > > > > accelerometer) but due to complicated HW
> > > > > > > > > > > abstraction and layers on Dell laptops it is
> > > > > > > > > > > handled by two drivers, one ACPI and one i2c.
> > > > > > > > > > > 
> > > > > > > > > > > Yes, in ideal world irq number should be passed
> > > > > > > > > > > to lis3lv02d driver and that would export whole
> > > > > > > > > > > device (with /dev/freefall too), but due to HW
> > > > > > > > > > > abstraction it is too much complicated...
> > > > > > > > > > 
> > > > > > > > > > Why?  AFAICT, all that is required to pass that IRQ
> > > > > > > > > > number all the way down to lis3lv02d is to set the
> > > > > > > > > > irq field of the struct i2c_board_info you are
> > > > > > > > > > passing to i2c_new_device().  And you can extract
> > > > > > > > > > that IRQ number e.g. in
> > > > > > > > > > check_acpi_smo88xx_device(). However, you would
> > > > > > > > > > then need to make sure dell-smo8800 does not
> > > > > > > > > > attempt to request the same IRQ on whitelisted
> > > > > > > > > > machines.  This got me thinking about a way to
> > > > > > > > > > somehow incorporate your changes into dell-smo8800
> > > > > > > > > > using Wolfram's bus_notifier suggestion, but I do
> > > > > > > > > > not have a working solution for now.  What is
> > > > > > > > > > tempting about this approach is that you would not
> > > > > > > > > > have to scan the ACPI namespace in search of
> > > > > > > > > > SMO88xx devices, because smo8800_add() is
> > > > > > > > > > automatically called for them. However, I fear that
> > > > > > > > > > the resulting solution may be more complicated than
> > > > > > > > > > the one you submitted.
> > > > > > > > > 
> > > > > > > > > Then we need to deal with lot of problems. Order of
> > > > > > > > > loading .ko modules is undefined. Binding devices to
> > > > > > > > > drivers registered by .ko module is also in "random"
> > > > > > > > > order. At any time any of those .ko module can be
> > > > > > > > > unloaded or at least device unbind (via sysfs) from
> > > > > > > > > driver... And there can be some pathological
> > > > > > > > > situation (thanks to adding ACPI layer as Andy
> > > > > > > > > pointed) that there will be more SMO88xx devices in
> > > > > > > > > ACPI. Plus you can compile kernel with and without
> > > > > > > > > those modules and also you can blacklist loading
> > > > > > > > > them (so compile time check is not enough). And
> > > > > > > > > still some correct message notifier must be used.
> > > > > > > > > 
> > > > > > > > > I think such solution is much much more complicated,
> > > > > > > > > there are lot of combinations of kernel configuration
> > > > > > > > > and available dell devices...
> > > > > > > > 
> > > > > > > > I tried a few more things, but ultimately failed to
> > > > > > > > find a nice way to implement this.
> > > > > > > > 
> > > > > > > > Another issue popped up, though.  Linus' master branch
> > > > > > > > contains a recent commit by Benjamin Tissoires (CC'ed),
> > > > > > > > 4d5538f5882a ("i2c: use an IRQ to report Host Notify
> > > > > > > > events, not alert") which breaks your patch.  The
> > > > > > > > reason for that is that lis3lv02d relies on the i2c
> > > > > > > > client's IRQ being 0 to detect that it should not
> > > > > > > > create /dev/freefall.
> > > > > > > > 
> > > > > > > >  Benjamin's patch causes the Host Notify IRQ to be
> > > > > > > > 
> > > > > > > > assigned to the i2c client your patch creates, thus
> > > > > > > > causing lis3lv02d to create /dev/freefall, which in
> > > > > > > > turn conflicts with dell-smo8800 which is trying to
> > > > > > > > create /dev/freefall itself.
> > > > > > > 
> > > > > > > So 4d5538f5882a is breaking lis3lv02d driver...
> > > > > > 
> > > > > > Apologies for that.
> > > > > > 
> > > > > > I could easily fix this by adding a kernel API to know
> > > > > > whether the provided irq is from Host Notify or if it was
> > > > > > coming from an actual declaration. However, I have no idea
> > > > > > how many other drivers would require this (hopefully only
> > > > > > this one).
> > > > > > 
> > > > > > One other solution would be to reserve the Host Notify IRQ
> > > > > > and let the actual drivers that need it to set it, but
> > > > > > this was not the best solution according to Dmitri. On my
> > > > > > side, I am not entirely against this given that it's a
> > > > > > chip feature, so the driver should be able to know that
> > > > > > it's available.
> > > > > > 
> > > > > > Dmitri, Wolfram, Jean, any preferences?
> > > > > 
> > > > > I read this:
> > > > > 
> > > > > "IIRC both dell-smo8800 and lis3lv02d represent one HW device
> > > > > (that ST microelectronics accelerometer) but due to
> > > > > complicated HW abstraction and layers on Dell laptops it is
> > > > > handled by two drivers, one ACPI and one i2c."
> > > > > 
> > > > > and that is the core of the issue. You have 2 drivers
> > > > > fighting over the same device. Fix this and it will all
> > > > > work.
> > > > 
> > > > With my current implementation (which I sent in this patch),
> > > > they are not fighting.
> > > > 
> > > > dell-smo8800 exports /dev/freefall (and nothing more) and
> > > > lis3lv02d only accelerometer device as lis3lv02d driver does
> > > > not get IRQ number in platform data.
> > > > 
> > > > > As far as I can see hp_accel instantiates lis3lv02d and
> > > > > accesses it via ACPI methods, can the same be done for Dell?
> > > > 
> > > > No, Dell does not have any ACPI methods. And as I wrote in ACPI
> > > > or DMI is even not i2c address of device, so it needs to be
> > > > specified in code itself.
> > > > 
> > > > Really there is no other way... :-(
> > > 
> > > Sure there is:
> > > 
> > > 1. dell-smo8800 instantiates I2C device as "dell-smo8800-accel".
> > > 2. dell-smo8800 provides read/write functions for lis3lv02d that
> > > simply forward requests to dell-smo8800-accel i2c client.
> > > 3. dell-smo8800 instantiates lis3lv02d instance like hp_accel
> > > does.
> > 
> > Sorry, but I do not understand how you mean it... Why to provides
> > new read/write i2c functions which are already implemented by
> > i2c-i801 bus and lis3lv02d i2c driver?
> 
> Because that would allow you to avoid clashes with i2c creating
> interrupt mapping for client residing on host-notify-capable
> controller.
> 
> > > Alternatively, can lis3lv02d be tasked to create /dev/freefall?
> > 
> > If i2c_board_info contains IRQ then lis3lv02d create /dev/freefall
> > device.
> > 
> > But... what is problem with current implementation? Accelerometer
> > HW provides two functions:
> > 
> > 1) 3 axes reports
> > 2) Disk freefall detection
> > 
> > And 1) is handled by i2c driver lis3lv02d and 2) is by
> > dell-smo8800. Both functions are independent here.
> > 
> > I think you just trying to complicate this situation even more to
> > be more complicated as currently is.
> 
> Because this apparently does not work for you, does it?

It is working fine. I do not see any problem.

> In general,
> if you want the same hardware be handled by 2 different drivers you
> are going to have bad time.

Yes, but in this case half of device is ACPI based and other half i2c 
based. This is problem of ACPI and Dell design.

> It seems to be that /dev/freefall in dell-smo8800 and lis3lv02d are
> the same, right?

Yes. I understand that clean solution is to have one driver which 
provides everything.

But because half of data are ACPI and half i2c, you still needs to 
create two drivers (one ACPI and one i2c). You can put both drivers into 
one .ko module, but still these will be two drivers due to how ACPI and 
i2c linux abstractions are different.

> So, instead of having 2 drivers split the
> functionality, can you forego registering smo8800 ACPI driver on
> your whitelisted boxes and instead instantiate full i2c client
> device with properly assigned both address and IRQ and let lis3lv02d
> handle it (providing both accelerometer data and /dev/freefall)?

With Michał we already discussed about it, see emails. Basically you can 
enable/disable kernel modules at compile time or blacklist at runtime 
(or even chose what will be compiled into vmlinux and what as external 
.ko module). Some distributions blacklist i2c-i801.ko module... And 
there can be also problem with initialization of i2c-i801 driver (fix is 
in commit a7ae81952cda, but does not have to work at every time!). So 
that move on whitelisted machines can potentially cause disappearance of 
/dev/freefall and users will not have hdd protection which is currently 
working.

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Dmitry Torokhov]

On Tue, Jan 03, 2017 at 09:39:13PM +0100, Pali Rohár wrote:
> On Tuesday 03 January 2017 21:24:18 Dmitry Torokhov wrote:
> > On Tue, Jan 03, 2017 at 09:05:51PM +0100, Pali Rohár wrote:
> > > On Tuesday 03 January 2017 20:48:12 Dmitry Torokhov wrote:
> > > > On Tue, Jan 03, 2017 at 07:50:17PM +0100, Pali Rohár wrote:
> > > > > On Tuesday 03 January 2017 19:38:43 Dmitry Torokhov wrote:
> > > > > > On Tue, Jan 03, 2017 at 10:06:41AM +0100, Benjamin Tissoires
> > > > > > 
> > > > > > wrote:
> > > > > > > On Dec 29 2016 or thereabouts, Pali Rohár wrote:
> > > > > > > > On Thursday 29 December 2016 22:09:32 Michał Kępień wrote:
> > > > > > > > > > On Thursday 29 December 2016 14:47:19 Michał Kępień
> > > > > > > > > > wrote:
> > > > > > > > > > > > On Thursday 29 December 2016 09:29:36 Michał
> > > > > > > > > > > > Kępień
> > > > > > > > > > > > 
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > Dell platform team told us that some (DMI
> > > > > > > > > > > > > > whitelisted) Dell Latitude machines have ST
> > > > > > > > > > > > > > microelectronics accelerometer at i2c address
> > > > > > > > > > > > > > 0x29. That i2c address is not specified in
> > > > > > > > > > > > > > DMI or ACPI, so runtime detection without
> > > > > > > > > > > > > > whitelist which is below is not possible.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Presence of that ST microelectronics
> > > > > > > > > > > > > > accelerometer is verified by existence of
> > > > > > > > > > > > > > SMO88xx ACPI device which represent that
> > > > > > > > > > > > > > accelerometer. Unfortunately without i2c
> > > > > > > > > > > > > > address.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > This part of the commit message sounded a bit
> > > > > > > > > > > > > confusing to me at first because there is
> > > > > > > > > > > > > already an ACPI driver which handles SMO88xx
> > > > > > > > > > > > > 
> > > > > > > > > > > > > devices (dell-smo8800).  My understanding is
> > > > > > > > > > > > > that:
> > > > > > > > > > > > >   * the purpose of this patch is to expose a
> > > > > > > > > > > > >   richer interface (as
> > > > > > > > > > > > >   
> > > > > > > > > > > > >     provided by lis3lv02d) to these devices on
> > > > > > > > > > > > >     some machines,
> > > > > > > > > > > > >   
> > > > > > > > > > > > >   * on whitelisted machines, dell-smo8800 and
> > > > > > > > > > > > >   lis3lv02d can work
> > > > > > > > > > > > >   
> > > > > > > > > > > > >     simultaneously (even though dell-smo8800
> > > > > > > > > > > > >     effectively duplicates the work that
> > > > > > > > > > > > >     lis3lv02d does).
> > > > > > > > > > > > 
> > > > > > > > > > > > No. dell-smo8800 reads from ACPI irq number and
> > > > > > > > > > > > exports /dev/freefall device which notify
> > > > > > > > > > > > userspace about falls. lis3lv02d is i2c driver
> > > > > > > > > > > > which exports axes of accelerometer. Additionaly
> > > > > > > > > > > > lis3lv02d can export also /dev/freefall if
> > > > > > > > > > > > registerer of i2c device provides irq number --
> > > > > > > > > > > > which is not case of this patch.
> > > > > > > > > > > > 
> > > > > > > > > > > > So both drivers are doing different things and
> > > > > > > > > > > > both are useful.
> > > > > > > > > > > > 
> > > > > > > > > > > > IIRC both dell-smo8800 and lis3lv02d represent
> > > > > > > > > > > > one HW device (that ST microelectronics
> > > > > > > > > > > > accelerometer) but due to complicated HW
> > > > > > > > > > > > abstraction and layers on Dell laptops it is
> > > > > > > > > > > > handled by two drivers, one ACPI and one i2c.
> > > > > > > > > > > > 
> > > > > > > > > > > > Yes, in ideal world irq number should be passed
> > > > > > > > > > > > to lis3lv02d driver and that would export whole
> > > > > > > > > > > > device (with /dev/freefall too), but due to HW
> > > > > > > > > > > > abstraction it is too much complicated...
> > > > > > > > > > > 
> > > > > > > > > > > Why?  AFAICT, all that is required to pass that IRQ
> > > > > > > > > > > number all the way down to lis3lv02d is to set the
> > > > > > > > > > > irq field of the struct i2c_board_info you are
> > > > > > > > > > > passing to i2c_new_device().  And you can extract
> > > > > > > > > > > that IRQ number e.g. in
> > > > > > > > > > > check_acpi_smo88xx_device(). However, you would
> > > > > > > > > > > then need to make sure dell-smo8800 does not
> > > > > > > > > > > attempt to request the same IRQ on whitelisted
> > > > > > > > > > > machines.  This got me thinking about a way to
> > > > > > > > > > > somehow incorporate your changes into dell-smo8800
> > > > > > > > > > > using Wolfram's bus_notifier suggestion, but I do
> > > > > > > > > > > not have a working solution for now.  What is
> > > > > > > > > > > tempting about this approach is that you would not
> > > > > > > > > > > have to scan the ACPI namespace in search of
> > > > > > > > > > > SMO88xx devices, because smo8800_add() is
> > > > > > > > > > > automatically called for them. However, I fear that
> > > > > > > > > > > the resulting solution may be more complicated than
> > > > > > > > > > > the one you submitted.
> > > > > > > > > > 
> > > > > > > > > > Then we need to deal with lot of problems. Order of
> > > > > > > > > > loading .ko modules is undefined. Binding devices to
> > > > > > > > > > drivers registered by .ko module is also in "random"
> > > > > > > > > > order. At any time any of those .ko module can be
> > > > > > > > > > unloaded or at least device unbind (via sysfs) from
> > > > > > > > > > driver... And there can be some pathological
> > > > > > > > > > situation (thanks to adding ACPI layer as Andy
> > > > > > > > > > pointed) that there will be more SMO88xx devices in
> > > > > > > > > > ACPI. Plus you can compile kernel with and without
> > > > > > > > > > those modules and also you can blacklist loading
> > > > > > > > > > them (so compile time check is not enough). And
> > > > > > > > > > still some correct message notifier must be used.
> > > > > > > > > > 
> > > > > > > > > > I think such solution is much much more complicated,
> > > > > > > > > > there are lot of combinations of kernel configuration
> > > > > > > > > > and available dell devices...
> > > > > > > > > 
> > > > > > > > > I tried a few more things, but ultimately failed to
> > > > > > > > > find a nice way to implement this.
> > > > > > > > > 
> > > > > > > > > Another issue popped up, though.  Linus' master branch
> > > > > > > > > contains a recent commit by Benjamin Tissoires (CC'ed),
> > > > > > > > > 4d5538f5882a ("i2c: use an IRQ to report Host Notify
> > > > > > > > > events, not alert") which breaks your patch.  The
> > > > > > > > > reason for that is that lis3lv02d relies on the i2c
> > > > > > > > > client's IRQ being 0 to detect that it should not
> > > > > > > > > create /dev/freefall.
> > > > > > > > > 
> > > > > > > > >  Benjamin's patch causes the Host Notify IRQ to be
> > > > > > > > > 
> > > > > > > > > assigned to the i2c client your patch creates, thus
> > > > > > > > > causing lis3lv02d to create /dev/freefall, which in
> > > > > > > > > turn conflicts with dell-smo8800 which is trying to
> > > > > > > > > create /dev/freefall itself.
> > > > > > > > 
> > > > > > > > So 4d5538f5882a is breaking lis3lv02d driver...
> > > > > > > 
> > > > > > > Apologies for that.
> > > > > > > 
> > > > > > > I could easily fix this by adding a kernel API to know
> > > > > > > whether the provided irq is from Host Notify or if it was
> > > > > > > coming from an actual declaration. However, I have no idea
> > > > > > > how many other drivers would require this (hopefully only
> > > > > > > this one).
> > > > > > > 
> > > > > > > One other solution would be to reserve the Host Notify IRQ
> > > > > > > and let the actual drivers that need it to set it, but
> > > > > > > this was not the best solution according to Dmitri. On my
> > > > > > > side, I am not entirely against this given that it's a
> > > > > > > chip feature, so the driver should be able to know that
> > > > > > > it's available.
> > > > > > > 
> > > > > > > Dmitri, Wolfram, Jean, any preferences?
> > > > > > 
> > > > > > I read this:
> > > > > > 
> > > > > > "IIRC both dell-smo8800 and lis3lv02d represent one HW device
> > > > > > (that ST microelectronics accelerometer) but due to
> > > > > > complicated HW abstraction and layers on Dell laptops it is
> > > > > > handled by two drivers, one ACPI and one i2c."
> > > > > > 
> > > > > > and that is the core of the issue. You have 2 drivers
> > > > > > fighting over the same device. Fix this and it will all
> > > > > > work.
> > > > > 
> > > > > With my current implementation (which I sent in this patch),
> > > > > they are not fighting.
> > > > > 
> > > > > dell-smo8800 exports /dev/freefall (and nothing more) and
> > > > > lis3lv02d only accelerometer device as lis3lv02d driver does
> > > > > not get IRQ number in platform data.
> > > > > 
> > > > > > As far as I can see hp_accel instantiates lis3lv02d and
> > > > > > accesses it via ACPI methods, can the same be done for Dell?
> > > > > 
> > > > > No, Dell does not have any ACPI methods. And as I wrote in ACPI
> > > > > or DMI is even not i2c address of device, so it needs to be
> > > > > specified in code itself.
> > > > > 
> > > > > Really there is no other way... :-(
> > > > 
> > > > Sure there is:
> > > > 
> > > > 1. dell-smo8800 instantiates I2C device as "dell-smo8800-accel".
> > > > 2. dell-smo8800 provides read/write functions for lis3lv02d that
> > > > simply forward requests to dell-smo8800-accel i2c client.
> > > > 3. dell-smo8800 instantiates lis3lv02d instance like hp_accel
> > > > does.
> > > 
> > > Sorry, but I do not understand how you mean it... Why to provides
> > > new read/write i2c functions which are already implemented by
> > > i2c-i801 bus and lis3lv02d i2c driver?
> > 
> > Because that would allow you to avoid clashes with i2c creating
> > interrupt mapping for client residing on host-notify-capable
> > controller.
> > 
> > > > Alternatively, can lis3lv02d be tasked to create /dev/freefall?
> > > 
> > > If i2c_board_info contains IRQ then lis3lv02d create /dev/freefall
> > > device.
> > > 
> > > But... what is problem with current implementation? Accelerometer
> > > HW provides two functions:
> > > 
> > > 1) 3 axes reports
> > > 2) Disk freefall detection
> > > 
> > > And 1) is handled by i2c driver lis3lv02d and 2) is by
> > > dell-smo8800. Both functions are independent here.
> > > 
> > > I think you just trying to complicate this situation even more to
> > > be more complicated as currently is.
> > 
> > Because this apparently does not work for you, does it?
> 
> It is working fine. I do not see any problem.
> 
> > In general,
> > if you want the same hardware be handled by 2 different drivers you
> > are going to have bad time.
> 
> Yes, but in this case half of device is ACPI based and other half i2c 
> based. This is problem of ACPI and Dell design.
> 
> > It seems to be that /dev/freefall in dell-smo8800 and lis3lv02d are
> > the same, right?
> 
> Yes. I understand that clean solution is to have one driver which 
> provides everything.
> 
> But because half of data are ACPI and half i2c, you still needs to 
> create two drivers (one ACPI and one i2c). You can put both drivers into 
> one .ko module, but still these will be two drivers due to how ACPI and 
> i2c linux abstractions are different.
> 
> > So, instead of having 2 drivers split the
> > functionality, can you forego registering smo8800 ACPI driver on
> > your whitelisted boxes and instead instantiate full i2c client
> > device with properly assigned both address and IRQ and let lis3lv02d
> > handle it (providing both accelerometer data and /dev/freefall)?
> 
> With Michał we already discussed about it, see emails. Basically you can 
> enable/disable kernel modules at compile time or blacklist at runtime 
> (or even chose what will be compiled into vmlinux and what as external 
> .ko module).

This can be solved with a bit of Kconfig/IS_ENABLED() code.

> Some distributions blacklist i2c-i801.ko module... And 

Any particular reason for that?

> there can be also problem with initialization of i2c-i801 driver (fix is 
> in commit a7ae81952cda, but does not have to work at every time!). So 
> that move on whitelisted machines can potentially cause disappearance of 
> /dev/freefall and users will not have hdd protection which is currently 
> working.

Well, I gave you 2 possible solutions (roll your own i2c read/write,
forward them to i2c client) or have faith in your implementation and let
lis3lv02d handle it.

The 3rd one is to possibly add a flag to disable host notify to IRQ
mapping for given client (if Wolfram/Jean OK with it).

Oh, the 4th one: change the irq in lis3lv02d.h to be "int" and change
the check in lis3lv02d.c to be "lis->irq <= 0" and instantiate your
i2c_client with board_info->irq = -1.

Pick whichever you prefer.

By the way, what do you need accelerometer for on these devices? They
don't appear to be tablets that could use one... 

Thanks.

-- 
Dmitry

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Pali Rohár]

On Tuesday 03 January 2017 12:59:37 Dmitry Torokhov wrote:
> On Tue, Jan 03, 2017 at 09:39:13PM +0100, Pali Rohár wrote:
> > On Tuesday 03 January 2017 21:24:18 Dmitry Torokhov wrote:
> > > On Tue, Jan 03, 2017 at 09:05:51PM +0100, Pali Rohár wrote:
> > > > On Tuesday 03 January 2017 20:48:12 Dmitry Torokhov wrote:
> > > > > On Tue, Jan 03, 2017 at 07:50:17PM +0100, Pali Rohár wrote:
> > > > > > On Tuesday 03 January 2017 19:38:43 Dmitry Torokhov wrote:
> > > > > > > On Tue, Jan 03, 2017 at 10:06:41AM +0100, Benjamin Tissoires
> > > > > > > 
> > > > > > > wrote:
> > > > > > > > On Dec 29 2016 or thereabouts, Pali Rohár wrote:
> > > > > > > > > On Thursday 29 December 2016 22:09:32 Michał Kępień wrote:
> > > > > > > > > > > On Thursday 29 December 2016 14:47:19 Michał Kępień
> > > > > > > > > > > wrote:
> > > > > > > > > > > > > On Thursday 29 December 2016 09:29:36 Michał
> > > > > > > > > > > > > Kępień
> > > > > > > > > > > > > 
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > Dell platform team told us that some (DMI
> > > > > > > > > > > > > > > whitelisted) Dell Latitude machines have ST
> > > > > > > > > > > > > > > microelectronics accelerometer at i2c address
> > > > > > > > > > > > > > > 0x29. That i2c address is not specified in
> > > > > > > > > > > > > > > DMI or ACPI, so runtime detection without
> > > > > > > > > > > > > > > whitelist which is below is not possible.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Presence of that ST microelectronics
> > > > > > > > > > > > > > > accelerometer is verified by existence of
> > > > > > > > > > > > > > > SMO88xx ACPI device which represent that
> > > > > > > > > > > > > > > accelerometer. Unfortunately without i2c
> > > > > > > > > > > > > > > address.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > This part of the commit message sounded a bit
> > > > > > > > > > > > > > confusing to me at first because there is
> > > > > > > > > > > > > > already an ACPI driver which handles SMO88xx
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > devices (dell-smo8800).  My understanding is
> > > > > > > > > > > > > > that:
> > > > > > > > > > > > > >   * the purpose of this patch is to expose a
> > > > > > > > > > > > > >   richer interface (as
> > > > > > > > > > > > > >   
> > > > > > > > > > > > > >     provided by lis3lv02d) to these devices on
> > > > > > > > > > > > > >     some machines,
> > > > > > > > > > > > > >   
> > > > > > > > > > > > > >   * on whitelisted machines, dell-smo8800 and
> > > > > > > > > > > > > >   lis3lv02d can work
> > > > > > > > > > > > > >   
> > > > > > > > > > > > > >     simultaneously (even though dell-smo8800
> > > > > > > > > > > > > >     effectively duplicates the work that
> > > > > > > > > > > > > >     lis3lv02d does).
> > > > > > > > > > > > > 
> > > > > > > > > > > > > No. dell-smo8800 reads from ACPI irq number and
> > > > > > > > > > > > > exports /dev/freefall device which notify
> > > > > > > > > > > > > userspace about falls. lis3lv02d is i2c driver
> > > > > > > > > > > > > which exports axes of accelerometer. Additionaly
> > > > > > > > > > > > > lis3lv02d can export also /dev/freefall if
> > > > > > > > > > > > > registerer of i2c device provides irq number --
> > > > > > > > > > > > > which is not case of this patch.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > So both drivers are doing different things and
> > > > > > > > > > > > > both are useful.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > IIRC both dell-smo8800 and lis3lv02d represent
> > > > > > > > > > > > > one HW device (that ST microelectronics
> > > > > > > > > > > > > accelerometer) but due to complicated HW
> > > > > > > > > > > > > abstraction and layers on Dell laptops it is
> > > > > > > > > > > > > handled by two drivers, one ACPI and one i2c.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Yes, in ideal world irq number should be passed
> > > > > > > > > > > > > to lis3lv02d driver and that would export whole
> > > > > > > > > > > > > device (with /dev/freefall too), but due to HW
> > > > > > > > > > > > > abstraction it is too much complicated...
> > > > > > > > > > > > 
> > > > > > > > > > > > Why?  AFAICT, all that is required to pass that IRQ
> > > > > > > > > > > > number all the way down to lis3lv02d is to set the
> > > > > > > > > > > > irq field of the struct i2c_board_info you are
> > > > > > > > > > > > passing to i2c_new_device().  And you can extract
> > > > > > > > > > > > that IRQ number e.g. in
> > > > > > > > > > > > check_acpi_smo88xx_device(). However, you would
> > > > > > > > > > > > then need to make sure dell-smo8800 does not
> > > > > > > > > > > > attempt to request the same IRQ on whitelisted
> > > > > > > > > > > > machines.  This got me thinking about a way to
> > > > > > > > > > > > somehow incorporate your changes into dell-smo8800
> > > > > > > > > > > > using Wolfram's bus_notifier suggestion, but I do
> > > > > > > > > > > > not have a working solution for now.  What is
> > > > > > > > > > > > tempting about this approach is that you would not
> > > > > > > > > > > > have to scan the ACPI namespace in search of
> > > > > > > > > > > > SMO88xx devices, because smo8800_add() is
> > > > > > > > > > > > automatically called for them. However, I fear that
> > > > > > > > > > > > the resulting solution may be more complicated than
> > > > > > > > > > > > the one you submitted.
> > > > > > > > > > > 
> > > > > > > > > > > Then we need to deal with lot of problems. Order of
> > > > > > > > > > > loading .ko modules is undefined. Binding devices to
> > > > > > > > > > > drivers registered by .ko module is also in "random"
> > > > > > > > > > > order. At any time any of those .ko module can be
> > > > > > > > > > > unloaded or at least device unbind (via sysfs) from
> > > > > > > > > > > driver... And there can be some pathological
> > > > > > > > > > > situation (thanks to adding ACPI layer as Andy
> > > > > > > > > > > pointed) that there will be more SMO88xx devices in
> > > > > > > > > > > ACPI. Plus you can compile kernel with and without
> > > > > > > > > > > those modules and also you can blacklist loading
> > > > > > > > > > > them (so compile time check is not enough). And
> > > > > > > > > > > still some correct message notifier must be used.
> > > > > > > > > > > 
> > > > > > > > > > > I think such solution is much much more complicated,
> > > > > > > > > > > there are lot of combinations of kernel configuration
> > > > > > > > > > > and available dell devices...
> > > > > > > > > > 
> > > > > > > > > > I tried a few more things, but ultimately failed to
> > > > > > > > > > find a nice way to implement this.
> > > > > > > > > > 
> > > > > > > > > > Another issue popped up, though.  Linus' master branch
> > > > > > > > > > contains a recent commit by Benjamin Tissoires (CC'ed),
> > > > > > > > > > 4d5538f5882a ("i2c: use an IRQ to report Host Notify
> > > > > > > > > > events, not alert") which breaks your patch.  The
> > > > > > > > > > reason for that is that lis3lv02d relies on the i2c
> > > > > > > > > > client's IRQ being 0 to detect that it should not
> > > > > > > > > > create /dev/freefall.
> > > > > > > > > > 
> > > > > > > > > >  Benjamin's patch causes the Host Notify IRQ to be
> > > > > > > > > > 
> > > > > > > > > > assigned to the i2c client your patch creates, thus
> > > > > > > > > > causing lis3lv02d to create /dev/freefall, which in
> > > > > > > > > > turn conflicts with dell-smo8800 which is trying to
> > > > > > > > > > create /dev/freefall itself.
> > > > > > > > > 
> > > > > > > > > So 4d5538f5882a is breaking lis3lv02d driver...
> > > > > > > > 
> > > > > > > > Apologies for that.
> > > > > > > > 
> > > > > > > > I could easily fix this by adding a kernel API to know
> > > > > > > > whether the provided irq is from Host Notify or if it was
> > > > > > > > coming from an actual declaration. However, I have no idea
> > > > > > > > how many other drivers would require this (hopefully only
> > > > > > > > this one).
> > > > > > > > 
> > > > > > > > One other solution would be to reserve the Host Notify IRQ
> > > > > > > > and let the actual drivers that need it to set it, but
> > > > > > > > this was not the best solution according to Dmitri. On my
> > > > > > > > side, I am not entirely against this given that it's a
> > > > > > > > chip feature, so the driver should be able to know that
> > > > > > > > it's available.
> > > > > > > > 
> > > > > > > > Dmitri, Wolfram, Jean, any preferences?
> > > > > > > 
> > > > > > > I read this:
> > > > > > > 
> > > > > > > "IIRC both dell-smo8800 and lis3lv02d represent one HW device
> > > > > > > (that ST microelectronics accelerometer) but due to
> > > > > > > complicated HW abstraction and layers on Dell laptops it is
> > > > > > > handled by two drivers, one ACPI and one i2c."
> > > > > > > 
> > > > > > > and that is the core of the issue. You have 2 drivers
> > > > > > > fighting over the same device. Fix this and it will all
> > > > > > > work.
> > > > > > 
> > > > > > With my current implementation (which I sent in this patch),
> > > > > > they are not fighting.
> > > > > > 
> > > > > > dell-smo8800 exports /dev/freefall (and nothing more) and
> > > > > > lis3lv02d only accelerometer device as lis3lv02d driver does
> > > > > > not get IRQ number in platform data.
> > > > > > 
> > > > > > > As far as I can see hp_accel instantiates lis3lv02d and
> > > > > > > accesses it via ACPI methods, can the same be done for Dell?
> > > > > > 
> > > > > > No, Dell does not have any ACPI methods. And as I wrote in ACPI
> > > > > > or DMI is even not i2c address of device, so it needs to be
> > > > > > specified in code itself.
> > > > > > 
> > > > > > Really there is no other way... :-(
> > > > > 
> > > > > Sure there is:
> > > > > 
> > > > > 1. dell-smo8800 instantiates I2C device as "dell-smo8800-accel".
> > > > > 2. dell-smo8800 provides read/write functions for lis3lv02d that
> > > > > simply forward requests to dell-smo8800-accel i2c client.
> > > > > 3. dell-smo8800 instantiates lis3lv02d instance like hp_accel
> > > > > does.
> > > > 
> > > > Sorry, but I do not understand how you mean it... Why to provides
> > > > new read/write i2c functions which are already implemented by
> > > > i2c-i801 bus and lis3lv02d i2c driver?
> > > 
> > > Because that would allow you to avoid clashes with i2c creating
> > > interrupt mapping for client residing on host-notify-capable
> > > controller.
> > > 
> > > > > Alternatively, can lis3lv02d be tasked to create /dev/freefall?
> > > > 
> > > > If i2c_board_info contains IRQ then lis3lv02d create /dev/freefall
> > > > device.
> > > > 
> > > > But... what is problem with current implementation? Accelerometer
> > > > HW provides two functions:
> > > > 
> > > > 1) 3 axes reports
> > > > 2) Disk freefall detection
> > > > 
> > > > And 1) is handled by i2c driver lis3lv02d and 2) is by
> > > > dell-smo8800. Both functions are independent here.
> > > > 
> > > > I think you just trying to complicate this situation even more to
> > > > be more complicated as currently is.
> > > 
> > > Because this apparently does not work for you, does it?
> > 
> > It is working fine. I do not see any problem.
> > 
> > > In general,
> > > if you want the same hardware be handled by 2 different drivers you
> > > are going to have bad time.
> > 
> > Yes, but in this case half of device is ACPI based and other half i2c 
> > based. This is problem of ACPI and Dell design.
> > 
> > > It seems to be that /dev/freefall in dell-smo8800 and lis3lv02d are
> > > the same, right?
> > 
> > Yes. I understand that clean solution is to have one driver which 
> > provides everything.
> > 
> > But because half of data are ACPI and half i2c, you still needs to 
> > create two drivers (one ACPI and one i2c). You can put both drivers into 
> > one .ko module, but still these will be two drivers due to how ACPI and 
> > i2c linux abstractions are different.
> > 
> > > So, instead of having 2 drivers split the
> > > functionality, can you forego registering smo8800 ACPI driver on
> > > your whitelisted boxes and instead instantiate full i2c client
> > > device with properly assigned both address and IRQ and let lis3lv02d
> > > handle it (providing both accelerometer data and /dev/freefall)?
> > 
> > With Michał we already discussed about it, see emails. Basically you can 
> > enable/disable kernel modules at compile time or blacklist at runtime 
> > (or even chose what will be compiled into vmlinux and what as external 
> > .ko module).
> 
> This can be solved with a bit of Kconfig/IS_ENABLED() code.
> 
> > Some distributions blacklist i2c-i801.ko module... And 
> 
> Any particular reason for that?
> 
> > there can be also problem with initialization of i2c-i801 driver (fix is 
> > in commit a7ae81952cda, but does not have to work at every time!). So 
> > that move on whitelisted machines can potentially cause disappearance of 
> > /dev/freefall and users will not have hdd protection which is currently 
> > working.
> 
> Well, I gave you 2 possible solutions (roll your own i2c read/write,
> forward them to i2c client) or have faith in your implementation and let
> lis3lv02d handle it.
> 
> The 3rd one is to possibly add a flag to disable host notify to IRQ
> mapping for given client (if Wolfram/Jean OK with it).
> 
> Oh, the 4th one: change the irq in lis3lv02d.h to be "int" and change
> the check in lis3lv02d.c to be "lis->irq <= 0" and instantiate your
> i2c_client with board_info->irq = -1.
> 
> Pick whichever you prefer.
> 
> By the way, what do you need accelerometer for on these devices? They
> don't appear to be tablets that could use one... 

Ah, you are talking about problem that after 4d5538f5882a lis3lv02d will
not work... I thought that discussion is about different mechanism how
to implement bus registration notification to smo8800 driver (or
different solution to not have registration in i801).

-- 
Pali Rohár
pali.rohar@gmail.com

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Benjamin Tissoires]

On Jan 04 2017 or thereabouts, Pali Rohár wrote:
> On Tuesday 03 January 2017 12:59:37 Dmitry Torokhov wrote:
> > On Tue, Jan 03, 2017 at 09:39:13PM +0100, Pali Rohár wrote:
> > > On Tuesday 03 January 2017 21:24:18 Dmitry Torokhov wrote:
> > > > On Tue, Jan 03, 2017 at 09:05:51PM +0100, Pali Rohár wrote:
> > > > > On Tuesday 03 January 2017 20:48:12 Dmitry Torokhov wrote:
> > > > > > On Tue, Jan 03, 2017 at 07:50:17PM +0100, Pali Rohár wrote:
> > > > > > > On Tuesday 03 January 2017 19:38:43 Dmitry Torokhov wrote:
> > > > > > > > On Tue, Jan 03, 2017 at 10:06:41AM +0100, Benjamin Tissoires
> > > > > > > > 
> > > > > > > > wrote:
> > > > > > > > > On Dec 29 2016 or thereabouts, Pali Rohár wrote:
> > > > > > > > > > On Thursday 29 December 2016 22:09:32 Michał Kępień wrote:
> > > > > > > > > > > > On Thursday 29 December 2016 14:47:19 Michał Kępień
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > On Thursday 29 December 2016 09:29:36 Michał
> > > > > > > > > > > > > > Kępień
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > Dell platform team told us that some (DMI
> > > > > > > > > > > > > > > > whitelisted) Dell Latitude machines have ST
> > > > > > > > > > > > > > > > microelectronics accelerometer at i2c address
> > > > > > > > > > > > > > > > 0x29. That i2c address is not specified in
> > > > > > > > > > > > > > > > DMI or ACPI, so runtime detection without
> > > > > > > > > > > > > > > > whitelist which is below is not possible.
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > Presence of that ST microelectronics
> > > > > > > > > > > > > > > > accelerometer is verified by existence of
> > > > > > > > > > > > > > > > SMO88xx ACPI device which represent that
> > > > > > > > > > > > > > > > accelerometer. Unfortunately without i2c
> > > > > > > > > > > > > > > > address.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > This part of the commit message sounded a bit
> > > > > > > > > > > > > > > confusing to me at first because there is
> > > > > > > > > > > > > > > already an ACPI driver which handles SMO88xx
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > devices (dell-smo8800).  My understanding is
> > > > > > > > > > > > > > > that:
> > > > > > > > > > > > > > >   * the purpose of this patch is to expose a
> > > > > > > > > > > > > > >   richer interface (as
> > > > > > > > > > > > > > >   
> > > > > > > > > > > > > > >     provided by lis3lv02d) to these devices on
> > > > > > > > > > > > > > >     some machines,
> > > > > > > > > > > > > > >   
> > > > > > > > > > > > > > >   * on whitelisted machines, dell-smo8800 and
> > > > > > > > > > > > > > >   lis3lv02d can work
> > > > > > > > > > > > > > >   
> > > > > > > > > > > > > > >     simultaneously (even though dell-smo8800
> > > > > > > > > > > > > > >     effectively duplicates the work that
> > > > > > > > > > > > > > >     lis3lv02d does).
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > No. dell-smo8800 reads from ACPI irq number and
> > > > > > > > > > > > > > exports /dev/freefall device which notify
> > > > > > > > > > > > > > userspace about falls. lis3lv02d is i2c driver
> > > > > > > > > > > > > > which exports axes of accelerometer. Additionaly
> > > > > > > > > > > > > > lis3lv02d can export also /dev/freefall if
> > > > > > > > > > > > > > registerer of i2c device provides irq number --
> > > > > > > > > > > > > > which is not case of this patch.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > So both drivers are doing different things and
> > > > > > > > > > > > > > both are useful.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > IIRC both dell-smo8800 and lis3lv02d represent
> > > > > > > > > > > > > > one HW device (that ST microelectronics
> > > > > > > > > > > > > > accelerometer) but due to complicated HW
> > > > > > > > > > > > > > abstraction and layers on Dell laptops it is
> > > > > > > > > > > > > > handled by two drivers, one ACPI and one i2c.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Yes, in ideal world irq number should be passed
> > > > > > > > > > > > > > to lis3lv02d driver and that would export whole
> > > > > > > > > > > > > > device (with /dev/freefall too), but due to HW
> > > > > > > > > > > > > > abstraction it is too much complicated...
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Why?  AFAICT, all that is required to pass that IRQ
> > > > > > > > > > > > > number all the way down to lis3lv02d is to set the
> > > > > > > > > > > > > irq field of the struct i2c_board_info you are
> > > > > > > > > > > > > passing to i2c_new_device().  And you can extract
> > > > > > > > > > > > > that IRQ number e.g. in
> > > > > > > > > > > > > check_acpi_smo88xx_device(). However, you would
> > > > > > > > > > > > > then need to make sure dell-smo8800 does not
> > > > > > > > > > > > > attempt to request the same IRQ on whitelisted
> > > > > > > > > > > > > machines.  This got me thinking about a way to
> > > > > > > > > > > > > somehow incorporate your changes into dell-smo8800
> > > > > > > > > > > > > using Wolfram's bus_notifier suggestion, but I do
> > > > > > > > > > > > > not have a working solution for now.  What is
> > > > > > > > > > > > > tempting about this approach is that you would not
> > > > > > > > > > > > > have to scan the ACPI namespace in search of
> > > > > > > > > > > > > SMO88xx devices, because smo8800_add() is
> > > > > > > > > > > > > automatically called for them. However, I fear that
> > > > > > > > > > > > > the resulting solution may be more complicated than
> > > > > > > > > > > > > the one you submitted.
> > > > > > > > > > > > 
> > > > > > > > > > > > Then we need to deal with lot of problems. Order of
> > > > > > > > > > > > loading .ko modules is undefined. Binding devices to
> > > > > > > > > > > > drivers registered by .ko module is also in "random"
> > > > > > > > > > > > order. At any time any of those .ko module can be
> > > > > > > > > > > > unloaded or at least device unbind (via sysfs) from
> > > > > > > > > > > > driver... And there can be some pathological
> > > > > > > > > > > > situation (thanks to adding ACPI layer as Andy
> > > > > > > > > > > > pointed) that there will be more SMO88xx devices in
> > > > > > > > > > > > ACPI. Plus you can compile kernel with and without
> > > > > > > > > > > > those modules and also you can blacklist loading
> > > > > > > > > > > > them (so compile time check is not enough). And
> > > > > > > > > > > > still some correct message notifier must be used.
> > > > > > > > > > > > 
> > > > > > > > > > > > I think such solution is much much more complicated,
> > > > > > > > > > > > there are lot of combinations of kernel configuration
> > > > > > > > > > > > and available dell devices...
> > > > > > > > > > > 
> > > > > > > > > > > I tried a few more things, but ultimately failed to
> > > > > > > > > > > find a nice way to implement this.
> > > > > > > > > > > 
> > > > > > > > > > > Another issue popped up, though.  Linus' master branch
> > > > > > > > > > > contains a recent commit by Benjamin Tissoires (CC'ed),
> > > > > > > > > > > 4d5538f5882a ("i2c: use an IRQ to report Host Notify
> > > > > > > > > > > events, not alert") which breaks your patch.  The
> > > > > > > > > > > reason for that is that lis3lv02d relies on the i2c
> > > > > > > > > > > client's IRQ being 0 to detect that it should not
> > > > > > > > > > > create /dev/freefall.
> > > > > > > > > > > 
> > > > > > > > > > >  Benjamin's patch causes the Host Notify IRQ to be
> > > > > > > > > > > 
> > > > > > > > > > > assigned to the i2c client your patch creates, thus
> > > > > > > > > > > causing lis3lv02d to create /dev/freefall, which in
> > > > > > > > > > > turn conflicts with dell-smo8800 which is trying to
> > > > > > > > > > > create /dev/freefall itself.
> > > > > > > > > > 
> > > > > > > > > > So 4d5538f5882a is breaking lis3lv02d driver...
> > > > > > > > > 
> > > > > > > > > Apologies for that.
> > > > > > > > > 
> > > > > > > > > I could easily fix this by adding a kernel API to know
> > > > > > > > > whether the provided irq is from Host Notify or if it was
> > > > > > > > > coming from an actual declaration. However, I have no idea
> > > > > > > > > how many other drivers would require this (hopefully only
> > > > > > > > > this one).
> > > > > > > > > 
> > > > > > > > > One other solution would be to reserve the Host Notify IRQ
> > > > > > > > > and let the actual drivers that need it to set it, but
> > > > > > > > > this was not the best solution according to Dmitri. On my
> > > > > > > > > side, I am not entirely against this given that it's a
> > > > > > > > > chip feature, so the driver should be able to know that
> > > > > > > > > it's available.
> > > > > > > > > 
> > > > > > > > > Dmitri, Wolfram, Jean, any preferences?
> > > > > > > > 
> > > > > > > > I read this:
> > > > > > > > 
> > > > > > > > "IIRC both dell-smo8800 and lis3lv02d represent one HW device
> > > > > > > > (that ST microelectronics accelerometer) but due to
> > > > > > > > complicated HW abstraction and layers on Dell laptops it is
> > > > > > > > handled by two drivers, one ACPI and one i2c."
> > > > > > > > 
> > > > > > > > and that is the core of the issue. You have 2 drivers
> > > > > > > > fighting over the same device. Fix this and it will all
> > > > > > > > work.
> > > > > > > 
> > > > > > > With my current implementation (which I sent in this patch),
> > > > > > > they are not fighting.
> > > > > > > 
> > > > > > > dell-smo8800 exports /dev/freefall (and nothing more) and
> > > > > > > lis3lv02d only accelerometer device as lis3lv02d driver does
> > > > > > > not get IRQ number in platform data.
> > > > > > > 
> > > > > > > > As far as I can see hp_accel instantiates lis3lv02d and
> > > > > > > > accesses it via ACPI methods, can the same be done for Dell?
> > > > > > > 
> > > > > > > No, Dell does not have any ACPI methods. And as I wrote in ACPI
> > > > > > > or DMI is even not i2c address of device, so it needs to be
> > > > > > > specified in code itself.
> > > > > > > 
> > > > > > > Really there is no other way... :-(
> > > > > > 
> > > > > > Sure there is:
> > > > > > 
> > > > > > 1. dell-smo8800 instantiates I2C device as "dell-smo8800-accel".
> > > > > > 2. dell-smo8800 provides read/write functions for lis3lv02d that
> > > > > > simply forward requests to dell-smo8800-accel i2c client.
> > > > > > 3. dell-smo8800 instantiates lis3lv02d instance like hp_accel
> > > > > > does.
> > > > > 
> > > > > Sorry, but I do not understand how you mean it... Why to provides
> > > > > new read/write i2c functions which are already implemented by
> > > > > i2c-i801 bus and lis3lv02d i2c driver?
> > > > 
> > > > Because that would allow you to avoid clashes with i2c creating
> > > > interrupt mapping for client residing on host-notify-capable
> > > > controller.
> > > > 
> > > > > > Alternatively, can lis3lv02d be tasked to create /dev/freefall?
> > > > > 
> > > > > If i2c_board_info contains IRQ then lis3lv02d create /dev/freefall
> > > > > device.
> > > > > 
> > > > > But... what is problem with current implementation? Accelerometer
> > > > > HW provides two functions:
> > > > > 
> > > > > 1) 3 axes reports
> > > > > 2) Disk freefall detection
> > > > > 
> > > > > And 1) is handled by i2c driver lis3lv02d and 2) is by
> > > > > dell-smo8800. Both functions are independent here.
> > > > > 
> > > > > I think you just trying to complicate this situation even more to
> > > > > be more complicated as currently is.
> > > > 
> > > > Because this apparently does not work for you, does it?
> > > 
> > > It is working fine. I do not see any problem.
> > > 
> > > > In general,
> > > > if you want the same hardware be handled by 2 different drivers you
> > > > are going to have bad time.
> > > 
> > > Yes, but in this case half of device is ACPI based and other half i2c 
> > > based. This is problem of ACPI and Dell design.
> > > 
> > > > It seems to be that /dev/freefall in dell-smo8800 and lis3lv02d are
> > > > the same, right?
> > > 
> > > Yes. I understand that clean solution is to have one driver which 
> > > provides everything.
> > > 
> > > But because half of data are ACPI and half i2c, you still needs to 
> > > create two drivers (one ACPI and one i2c). You can put both drivers into 
> > > one .ko module, but still these will be two drivers due to how ACPI and 
> > > i2c linux abstractions are different.
> > > 
> > > > So, instead of having 2 drivers split the
> > > > functionality, can you forego registering smo8800 ACPI driver on
> > > > your whitelisted boxes and instead instantiate full i2c client
> > > > device with properly assigned both address and IRQ and let lis3lv02d
> > > > handle it (providing both accelerometer data and /dev/freefall)?
> > > 
> > > With Michał we already discussed about it, see emails. Basically you can 
> > > enable/disable kernel modules at compile time or blacklist at runtime 
> > > (or even chose what will be compiled into vmlinux and what as external 
> > > .ko module).
> > 
> > This can be solved with a bit of Kconfig/IS_ENABLED() code.
> > 
> > > Some distributions blacklist i2c-i801.ko module... And 
> > 
> > Any particular reason for that?
> > 
> > > there can be also problem with initialization of i2c-i801 driver (fix is 
> > > in commit a7ae81952cda, but does not have to work at every time!). So 
> > > that move on whitelisted machines can potentially cause disappearance of 
> > > /dev/freefall and users will not have hdd protection which is currently 
> > > working.
> > 
> > Well, I gave you 2 possible solutions (roll your own i2c read/write,
> > forward them to i2c client) or have faith in your implementation and let
> > lis3lv02d handle it.
> > 
> > The 3rd one is to possibly add a flag to disable host notify to IRQ
> > mapping for given client (if Wolfram/Jean OK with it).
> > 
> > Oh, the 4th one: change the irq in lis3lv02d.h to be "int" and change
> > the check in lis3lv02d.c to be "lis->irq <= 0" and instantiate your
> > i2c_client with board_info->irq = -1.
> > 
> > Pick whichever you prefer.
> > 
> > By the way, what do you need accelerometer for on these devices? They
> > don't appear to be tablets that could use one... 
> 
> Ah, you are talking about problem that after 4d5538f5882a lis3lv02d will
> not work... I thought that discussion is about different mechanism how
> to implement bus registration notification to smo8800 driver (or
> different solution to not have registration in i801).
> 

Just because I am not sure I got everything right, could you confirm
that:
- in the current upstream tree, the dell-smo8800 driver is now broken
  after 4d5538f5882a (i2c: use an IRQ to report Host Notify events, not
  alert)
- this series adds an extra lis3lv02d on some machines and you have
  problem fighting for the irq (but this is not upstream yet). The extra
  lis3lv02d node is added from dell-smo8800

If the first point is not correct (by default, dell-smo8800 will not be
loaded at the same time than lis3lv02d), then it's a design issue with
the interactions between those 2 drivers.

If the first point is correct because ACPI declares both devices, then
there is an urgent fix to propose to not enable Host Notify by default
on Host Notifier capable adapters. (even though the design between the
2 drivers is wrong, it's considered as a regression).

Cheers,
Benjamin

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Pali Rohár]

On Wednesday 04 January 2017 10:05:22 Benjamin Tissoires wrote:
> On Jan 04 2017 or thereabouts, Pali Rohár wrote:
> > On Tuesday 03 January 2017 12:59:37 Dmitry Torokhov wrote:
> > > On Tue, Jan 03, 2017 at 09:39:13PM +0100, Pali Rohár wrote:
> > > > On Tuesday 03 January 2017 21:24:18 Dmitry Torokhov wrote:
> > > > > On Tue, Jan 03, 2017 at 09:05:51PM +0100, Pali Rohár wrote:
> > > > > > On Tuesday 03 January 2017 20:48:12 Dmitry Torokhov wrote:
> > > > > > > On Tue, Jan 03, 2017 at 07:50:17PM +0100, Pali Rohár wrote:
> > > > > > > > On Tuesday 03 January 2017 19:38:43 Dmitry Torokhov wrote:
> > > > > > > > > On Tue, Jan 03, 2017 at 10:06:41AM +0100, Benjamin Tissoires
> > > > > > > > > 
> > > > > > > > > wrote:
> > > > > > > > > > On Dec 29 2016 or thereabouts, Pali Rohár wrote:
> > > > > > > > > > > On Thursday 29 December 2016 22:09:32 Michał Kępień wrote:
> > > > > > > > > > > > > On Thursday 29 December 2016 14:47:19 Michał Kępień
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > On Thursday 29 December 2016 09:29:36 Michał
> > > > > > > > > > > > > > > Kępień
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > Dell platform team told us that some (DMI
> > > > > > > > > > > > > > > > > whitelisted) Dell Latitude machines have ST
> > > > > > > > > > > > > > > > > microelectronics accelerometer at i2c address
> > > > > > > > > > > > > > > > > 0x29. That i2c address is not specified in
> > > > > > > > > > > > > > > > > DMI or ACPI, so runtime detection without
> > > > > > > > > > > > > > > > > whitelist which is below is not possible.
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > Presence of that ST microelectronics
> > > > > > > > > > > > > > > > > accelerometer is verified by existence of
> > > > > > > > > > > > > > > > > SMO88xx ACPI device which represent that
> > > > > > > > > > > > > > > > > accelerometer. Unfortunately without i2c
> > > > > > > > > > > > > > > > > address.
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > This part of the commit message sounded a bit
> > > > > > > > > > > > > > > > confusing to me at first because there is
> > > > > > > > > > > > > > > > already an ACPI driver which handles SMO88xx
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > devices (dell-smo8800).  My understanding is
> > > > > > > > > > > > > > > > that:
> > > > > > > > > > > > > > > >   * the purpose of this patch is to expose a
> > > > > > > > > > > > > > > >   richer interface (as
> > > > > > > > > > > > > > > >   
> > > > > > > > > > > > > > > >     provided by lis3lv02d) to these devices on
> > > > > > > > > > > > > > > >     some machines,
> > > > > > > > > > > > > > > >   
> > > > > > > > > > > > > > > >   * on whitelisted machines, dell-smo8800 and
> > > > > > > > > > > > > > > >   lis3lv02d can work
> > > > > > > > > > > > > > > >   
> > > > > > > > > > > > > > > >     simultaneously (even though dell-smo8800
> > > > > > > > > > > > > > > >     effectively duplicates the work that
> > > > > > > > > > > > > > > >     lis3lv02d does).
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > No. dell-smo8800 reads from ACPI irq number and
> > > > > > > > > > > > > > > exports /dev/freefall device which notify
> > > > > > > > > > > > > > > userspace about falls. lis3lv02d is i2c driver
> > > > > > > > > > > > > > > which exports axes of accelerometer. Additionaly
> > > > > > > > > > > > > > > lis3lv02d can export also /dev/freefall if
> > > > > > > > > > > > > > > registerer of i2c device provides irq number --
> > > > > > > > > > > > > > > which is not case of this patch.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > So both drivers are doing different things and
> > > > > > > > > > > > > > > both are useful.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > IIRC both dell-smo8800 and lis3lv02d represent
> > > > > > > > > > > > > > > one HW device (that ST microelectronics
> > > > > > > > > > > > > > > accelerometer) but due to complicated HW
> > > > > > > > > > > > > > > abstraction and layers on Dell laptops it is
> > > > > > > > > > > > > > > handled by two drivers, one ACPI and one i2c.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Yes, in ideal world irq number should be passed
> > > > > > > > > > > > > > > to lis3lv02d driver and that would export whole
> > > > > > > > > > > > > > > device (with /dev/freefall too), but due to HW
> > > > > > > > > > > > > > > abstraction it is too much complicated...
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Why?  AFAICT, all that is required to pass that IRQ
> > > > > > > > > > > > > > number all the way down to lis3lv02d is to set the
> > > > > > > > > > > > > > irq field of the struct i2c_board_info you are
> > > > > > > > > > > > > > passing to i2c_new_device().  And you can extract
> > > > > > > > > > > > > > that IRQ number e.g. in
> > > > > > > > > > > > > > check_acpi_smo88xx_device(). However, you would
> > > > > > > > > > > > > > then need to make sure dell-smo8800 does not
> > > > > > > > > > > > > > attempt to request the same IRQ on whitelisted
> > > > > > > > > > > > > > machines.  This got me thinking about a way to
> > > > > > > > > > > > > > somehow incorporate your changes into dell-smo8800
> > > > > > > > > > > > > > using Wolfram's bus_notifier suggestion, but I do
> > > > > > > > > > > > > > not have a working solution for now.  What is
> > > > > > > > > > > > > > tempting about this approach is that you would not
> > > > > > > > > > > > > > have to scan the ACPI namespace in search of
> > > > > > > > > > > > > > SMO88xx devices, because smo8800_add() is
> > > > > > > > > > > > > > automatically called for them. However, I fear that
> > > > > > > > > > > > > > the resulting solution may be more complicated than
> > > > > > > > > > > > > > the one you submitted.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Then we need to deal with lot of problems. Order of
> > > > > > > > > > > > > loading .ko modules is undefined. Binding devices to
> > > > > > > > > > > > > drivers registered by .ko module is also in "random"
> > > > > > > > > > > > > order. At any time any of those .ko module can be
> > > > > > > > > > > > > unloaded or at least device unbind (via sysfs) from
> > > > > > > > > > > > > driver... And there can be some pathological
> > > > > > > > > > > > > situation (thanks to adding ACPI layer as Andy
> > > > > > > > > > > > > pointed) that there will be more SMO88xx devices in
> > > > > > > > > > > > > ACPI. Plus you can compile kernel with and without
> > > > > > > > > > > > > those modules and also you can blacklist loading
> > > > > > > > > > > > > them (so compile time check is not enough). And
> > > > > > > > > > > > > still some correct message notifier must be used.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I think such solution is much much more complicated,
> > > > > > > > > > > > > there are lot of combinations of kernel configuration
> > > > > > > > > > > > > and available dell devices...
> > > > > > > > > > > > 
> > > > > > > > > > > > I tried a few more things, but ultimately failed to
> > > > > > > > > > > > find a nice way to implement this.
> > > > > > > > > > > > 
> > > > > > > > > > > > Another issue popped up, though.  Linus' master branch
> > > > > > > > > > > > contains a recent commit by Benjamin Tissoires (CC'ed),
> > > > > > > > > > > > 4d5538f5882a ("i2c: use an IRQ to report Host Notify
> > > > > > > > > > > > events, not alert") which breaks your patch.  The
> > > > > > > > > > > > reason for that is that lis3lv02d relies on the i2c
> > > > > > > > > > > > client's IRQ being 0 to detect that it should not
> > > > > > > > > > > > create /dev/freefall.
> > > > > > > > > > > > 
> > > > > > > > > > > >  Benjamin's patch causes the Host Notify IRQ to be
> > > > > > > > > > > > 
> > > > > > > > > > > > assigned to the i2c client your patch creates, thus
> > > > > > > > > > > > causing lis3lv02d to create /dev/freefall, which in
> > > > > > > > > > > > turn conflicts with dell-smo8800 which is trying to
> > > > > > > > > > > > create /dev/freefall itself.
> > > > > > > > > > > 
> > > > > > > > > > > So 4d5538f5882a is breaking lis3lv02d driver...
> > > > > > > > > > 
> > > > > > > > > > Apologies for that.
> > > > > > > > > > 
> > > > > > > > > > I could easily fix this by adding a kernel API to know
> > > > > > > > > > whether the provided irq is from Host Notify or if it was
> > > > > > > > > > coming from an actual declaration. However, I have no idea
> > > > > > > > > > how many other drivers would require this (hopefully only
> > > > > > > > > > this one).
> > > > > > > > > > 
> > > > > > > > > > One other solution would be to reserve the Host Notify IRQ
> > > > > > > > > > and let the actual drivers that need it to set it, but
> > > > > > > > > > this was not the best solution according to Dmitri. On my
> > > > > > > > > > side, I am not entirely against this given that it's a
> > > > > > > > > > chip feature, so the driver should be able to know that
> > > > > > > > > > it's available.
> > > > > > > > > > 
> > > > > > > > > > Dmitri, Wolfram, Jean, any preferences?
> > > > > > > > > 
> > > > > > > > > I read this:
> > > > > > > > > 
> > > > > > > > > "IIRC both dell-smo8800 and lis3lv02d represent one HW device
> > > > > > > > > (that ST microelectronics accelerometer) but due to
> > > > > > > > > complicated HW abstraction and layers on Dell laptops it is
> > > > > > > > > handled by two drivers, one ACPI and one i2c."
> > > > > > > > > 
> > > > > > > > > and that is the core of the issue. You have 2 drivers
> > > > > > > > > fighting over the same device. Fix this and it will all
> > > > > > > > > work.
> > > > > > > > 
> > > > > > > > With my current implementation (which I sent in this patch),
> > > > > > > > they are not fighting.
> > > > > > > > 
> > > > > > > > dell-smo8800 exports /dev/freefall (and nothing more) and
> > > > > > > > lis3lv02d only accelerometer device as lis3lv02d driver does
> > > > > > > > not get IRQ number in platform data.
> > > > > > > > 
> > > > > > > > > As far as I can see hp_accel instantiates lis3lv02d and
> > > > > > > > > accesses it via ACPI methods, can the same be done for Dell?
> > > > > > > > 
> > > > > > > > No, Dell does not have any ACPI methods. And as I wrote in ACPI
> > > > > > > > or DMI is even not i2c address of device, so it needs to be
> > > > > > > > specified in code itself.
> > > > > > > > 
> > > > > > > > Really there is no other way... :-(
> > > > > > > 
> > > > > > > Sure there is:
> > > > > > > 
> > > > > > > 1. dell-smo8800 instantiates I2C device as "dell-smo8800-accel".
> > > > > > > 2. dell-smo8800 provides read/write functions for lis3lv02d that
> > > > > > > simply forward requests to dell-smo8800-accel i2c client.
> > > > > > > 3. dell-smo8800 instantiates lis3lv02d instance like hp_accel
> > > > > > > does.
> > > > > > 
> > > > > > Sorry, but I do not understand how you mean it... Why to provides
> > > > > > new read/write i2c functions which are already implemented by
> > > > > > i2c-i801 bus and lis3lv02d i2c driver?
> > > > > 
> > > > > Because that would allow you to avoid clashes with i2c creating
> > > > > interrupt mapping for client residing on host-notify-capable
> > > > > controller.
> > > > > 
> > > > > > > Alternatively, can lis3lv02d be tasked to create /dev/freefall?
> > > > > > 
> > > > > > If i2c_board_info contains IRQ then lis3lv02d create /dev/freefall
> > > > > > device.
> > > > > > 
> > > > > > But... what is problem with current implementation? Accelerometer
> > > > > > HW provides two functions:
> > > > > > 
> > > > > > 1) 3 axes reports
> > > > > > 2) Disk freefall detection
> > > > > > 
> > > > > > And 1) is handled by i2c driver lis3lv02d and 2) is by
> > > > > > dell-smo8800. Both functions are independent here.
> > > > > > 
> > > > > > I think you just trying to complicate this situation even more to
> > > > > > be more complicated as currently is.
> > > > > 
> > > > > Because this apparently does not work for you, does it?
> > > > 
> > > > It is working fine. I do not see any problem.
> > > > 
> > > > > In general,
> > > > > if you want the same hardware be handled by 2 different drivers you
> > > > > are going to have bad time.
> > > > 
> > > > Yes, but in this case half of device is ACPI based and other half i2c 
> > > > based. This is problem of ACPI and Dell design.
> > > > 
> > > > > It seems to be that /dev/freefall in dell-smo8800 and lis3lv02d are
> > > > > the same, right?
> > > > 
> > > > Yes. I understand that clean solution is to have one driver which 
> > > > provides everything.
> > > > 
> > > > But because half of data are ACPI and half i2c, you still needs to 
> > > > create two drivers (one ACPI and one i2c). You can put both drivers into 
> > > > one .ko module, but still these will be two drivers due to how ACPI and 
> > > > i2c linux abstractions are different.
> > > > 
> > > > > So, instead of having 2 drivers split the
> > > > > functionality, can you forego registering smo8800 ACPI driver on
> > > > > your whitelisted boxes and instead instantiate full i2c client
> > > > > device with properly assigned both address and IRQ and let lis3lv02d
> > > > > handle it (providing both accelerometer data and /dev/freefall)?
> > > > 
> > > > With Michał we already discussed about it, see emails. Basically you can 
> > > > enable/disable kernel modules at compile time or blacklist at runtime 
> > > > (or even chose what will be compiled into vmlinux and what as external 
> > > > .ko module).
> > > 
> > > This can be solved with a bit of Kconfig/IS_ENABLED() code.
> > > 
> > > > Some distributions blacklist i2c-i801.ko module... And 
> > > 
> > > Any particular reason for that?
> > > 
> > > > there can be also problem with initialization of i2c-i801 driver (fix is 
> > > > in commit a7ae81952cda, but does not have to work at every time!). So 
> > > > that move on whitelisted machines can potentially cause disappearance of 
> > > > /dev/freefall and users will not have hdd protection which is currently 
> > > > working.
> > > 
> > > Well, I gave you 2 possible solutions (roll your own i2c read/write,
> > > forward them to i2c client) or have faith in your implementation and let
> > > lis3lv02d handle it.
> > > 
> > > The 3rd one is to possibly add a flag to disable host notify to IRQ
> > > mapping for given client (if Wolfram/Jean OK with it).
> > > 
> > > Oh, the 4th one: change the irq in lis3lv02d.h to be "int" and change
> > > the check in lis3lv02d.c to be "lis->irq <= 0" and instantiate your
> > > i2c_client with board_info->irq = -1.
> > > 
> > > Pick whichever you prefer.
> > > 
> > > By the way, what do you need accelerometer for on these devices? They
> > > don't appear to be tablets that could use one... 
> > 
> > Ah, you are talking about problem that after 4d5538f5882a lis3lv02d will
> > not work... I thought that discussion is about different mechanism how
> > to implement bus registration notification to smo8800 driver (or
> > different solution to not have registration in i801).
> > 
> 
> Just because I am not sure I got everything right, could you confirm
> that:
> - in the current upstream tree, the dell-smo8800 driver is now broken
>   after 4d5538f5882a (i2c: use an IRQ to report Host Notify events, not
>   alert)

No, dell-smo8800 it is working fine. It is fully independent from i2c
and lis3lv02d. It is pure ACPI driver which does not share anything with
i2c.

> - this series adds an extra lis3lv02d on some machines and you have
>   problem fighting for the irq (but this is not upstream yet).

Yes, this series (not merged yet) adds extra lis3lv02d device but is not
working because of 4d5538f5882a.

> The extra lis3lv02d node is added from dell-smo8800

No, dell-smo8800 does not add new node in this patch.

> If the first point is not correct (by default, dell-smo8800 will not be
> loaded at the same time than lis3lv02d), then it's a design issue with
> the interactions between those 2 drivers.

No, there is no interactions between these two drivers (dell-smo8800 and
lis3lv02d). dell-smo8800 is pure ACPI driver and exports just
/dev/freefall device based on IRQ (and nothing more).

And lis3lv02d in *current* configuration in this patch exports only
accelerometer input device, not /dev/freefall. It does not use IRQ.
(Just there is problem with 4d5538f5882a which tells lis3lv02d IRQ
number which is not freefall report, therefore lis3lv02d does not work).

To make it clear, ST Accelerometer provides two operations:
* report free fall
* report 3 axes

Free fall is reported by IRQ, state of 3 axes via i2c bus. Free fall IRQ
is handled by dell-smo8800, state of 3 axes via i2c lis3lv02d driver.

lis3lv02d can handle also free fall IRQ is platform i2c data provides
IRQ number for it -- but this is not case in our Dell configuration. But
commit 4d5538f5882a inject some IRQ number to lis3lv02d driver which is
not free fall detection and so is breaking lis3lv02 driver. In our Dell
configuration (by this patch) there should be no IRQ number.

It is clear now?

> If the first point is correct because ACPI declares both devices, then
> there is an urgent fix to propose to not enable Host Notify by default
> on Host Notifier capable adapters. (even though the design between the
> 2 drivers is wrong, it's considered as a regression).
> 
> Cheers,
> Benjamin

-- 
Pali Rohár
pali.rohar@gmail.com

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Benjamin Tissoires]

On Jan 04 2017 or thereabouts, Pali Rohár wrote:
> On Wednesday 04 January 2017 10:05:22 Benjamin Tissoires wrote:
> > On Jan 04 2017 or thereabouts, Pali Rohár wrote:
> > > On Tuesday 03 January 2017 12:59:37 Dmitry Torokhov wrote:
> > > > On Tue, Jan 03, 2017 at 09:39:13PM +0100, Pali Rohár wrote:
> > > > > On Tuesday 03 January 2017 21:24:18 Dmitry Torokhov wrote:
> > > > > > On Tue, Jan 03, 2017 at 09:05:51PM +0100, Pali Rohár wrote:
> > > > > > > On Tuesday 03 January 2017 20:48:12 Dmitry Torokhov wrote:
> > > > > > > > On Tue, Jan 03, 2017 at 07:50:17PM +0100, Pali Rohár wrote:
> > > > > > > > > On Tuesday 03 January 2017 19:38:43 Dmitry Torokhov wrote:
> > > > > > > > > > On Tue, Jan 03, 2017 at 10:06:41AM +0100, Benjamin Tissoires
> > > > > > > > > > 
> > > > > > > > > > wrote:
> > > > > > > > > > > On Dec 29 2016 or thereabouts, Pali Rohár wrote:
> > > > > > > > > > > > On Thursday 29 December 2016 22:09:32 Michał Kępień wrote:
> > > > > > > > > > > > > > On Thursday 29 December 2016 14:47:19 Michał Kępień
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > On Thursday 29 December 2016 09:29:36 Michał
> > > > > > > > > > > > > > > > Kępień
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > Dell platform team told us that some (DMI
> > > > > > > > > > > > > > > > > > whitelisted) Dell Latitude machines have ST
> > > > > > > > > > > > > > > > > > microelectronics accelerometer at i2c address
> > > > > > > > > > > > > > > > > > 0x29. That i2c address is not specified in
> > > > > > > > > > > > > > > > > > DMI or ACPI, so runtime detection without
> > > > > > > > > > > > > > > > > > whitelist which is below is not possible.
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > Presence of that ST microelectronics
> > > > > > > > > > > > > > > > > > accelerometer is verified by existence of
> > > > > > > > > > > > > > > > > > SMO88xx ACPI device which represent that
> > > > > > > > > > > > > > > > > > accelerometer. Unfortunately without i2c
> > > > > > > > > > > > > > > > > > address.
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > This part of the commit message sounded a bit
> > > > > > > > > > > > > > > > > confusing to me at first because there is
> > > > > > > > > > > > > > > > > already an ACPI driver which handles SMO88xx
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > devices (dell-smo8800).  My understanding is
> > > > > > > > > > > > > > > > > that:
> > > > > > > > > > > > > > > > >   * the purpose of this patch is to expose a
> > > > > > > > > > > > > > > > >   richer interface (as
> > > > > > > > > > > > > > > > >   
> > > > > > > > > > > > > > > > >     provided by lis3lv02d) to these devices on
> > > > > > > > > > > > > > > > >     some machines,
> > > > > > > > > > > > > > > > >   
> > > > > > > > > > > > > > > > >   * on whitelisted machines, dell-smo8800 and
> > > > > > > > > > > > > > > > >   lis3lv02d can work
> > > > > > > > > > > > > > > > >   
> > > > > > > > > > > > > > > > >     simultaneously (even though dell-smo8800
> > > > > > > > > > > > > > > > >     effectively duplicates the work that
> > > > > > > > > > > > > > > > >     lis3lv02d does).
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > No. dell-smo8800 reads from ACPI irq number and
> > > > > > > > > > > > > > > > exports /dev/freefall device which notify
> > > > > > > > > > > > > > > > userspace about falls. lis3lv02d is i2c driver
> > > > > > > > > > > > > > > > which exports axes of accelerometer. Additionaly
> > > > > > > > > > > > > > > > lis3lv02d can export also /dev/freefall if
> > > > > > > > > > > > > > > > registerer of i2c device provides irq number --
> > > > > > > > > > > > > > > > which is not case of this patch.
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > So both drivers are doing different things and
> > > > > > > > > > > > > > > > both are useful.
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > IIRC both dell-smo8800 and lis3lv02d represent
> > > > > > > > > > > > > > > > one HW device (that ST microelectronics
> > > > > > > > > > > > > > > > accelerometer) but due to complicated HW
> > > > > > > > > > > > > > > > abstraction and layers on Dell laptops it is
> > > > > > > > > > > > > > > > handled by two drivers, one ACPI and one i2c.
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > Yes, in ideal world irq number should be passed
> > > > > > > > > > > > > > > > to lis3lv02d driver and that would export whole
> > > > > > > > > > > > > > > > device (with /dev/freefall too), but due to HW
> > > > > > > > > > > > > > > > abstraction it is too much complicated...
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Why?  AFAICT, all that is required to pass that IRQ
> > > > > > > > > > > > > > > number all the way down to lis3lv02d is to set the
> > > > > > > > > > > > > > > irq field of the struct i2c_board_info you are
> > > > > > > > > > > > > > > passing to i2c_new_device().  And you can extract
> > > > > > > > > > > > > > > that IRQ number e.g. in
> > > > > > > > > > > > > > > check_acpi_smo88xx_device(). However, you would
> > > > > > > > > > > > > > > then need to make sure dell-smo8800 does not
> > > > > > > > > > > > > > > attempt to request the same IRQ on whitelisted
> > > > > > > > > > > > > > > machines.  This got me thinking about a way to
> > > > > > > > > > > > > > > somehow incorporate your changes into dell-smo8800
> > > > > > > > > > > > > > > using Wolfram's bus_notifier suggestion, but I do
> > > > > > > > > > > > > > > not have a working solution for now.  What is
> > > > > > > > > > > > > > > tempting about this approach is that you would not
> > > > > > > > > > > > > > > have to scan the ACPI namespace in search of
> > > > > > > > > > > > > > > SMO88xx devices, because smo8800_add() is
> > > > > > > > > > > > > > > automatically called for them. However, I fear that
> > > > > > > > > > > > > > > the resulting solution may be more complicated than
> > > > > > > > > > > > > > > the one you submitted.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Then we need to deal with lot of problems. Order of
> > > > > > > > > > > > > > loading .ko modules is undefined. Binding devices to
> > > > > > > > > > > > > > drivers registered by .ko module is also in "random"
> > > > > > > > > > > > > > order. At any time any of those .ko module can be
> > > > > > > > > > > > > > unloaded or at least device unbind (via sysfs) from
> > > > > > > > > > > > > > driver... And there can be some pathological
> > > > > > > > > > > > > > situation (thanks to adding ACPI layer as Andy
> > > > > > > > > > > > > > pointed) that there will be more SMO88xx devices in
> > > > > > > > > > > > > > ACPI. Plus you can compile kernel with and without
> > > > > > > > > > > > > > those modules and also you can blacklist loading
> > > > > > > > > > > > > > them (so compile time check is not enough). And
> > > > > > > > > > > > > > still some correct message notifier must be used.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > I think such solution is much much more complicated,
> > > > > > > > > > > > > > there are lot of combinations of kernel configuration
> > > > > > > > > > > > > > and available dell devices...
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I tried a few more things, but ultimately failed to
> > > > > > > > > > > > > find a nice way to implement this.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Another issue popped up, though.  Linus' master branch
> > > > > > > > > > > > > contains a recent commit by Benjamin Tissoires (CC'ed),
> > > > > > > > > > > > > 4d5538f5882a ("i2c: use an IRQ to report Host Notify
> > > > > > > > > > > > > events, not alert") which breaks your patch.  The
> > > > > > > > > > > > > reason for that is that lis3lv02d relies on the i2c
> > > > > > > > > > > > > client's IRQ being 0 to detect that it should not
> > > > > > > > > > > > > create /dev/freefall.
> > > > > > > > > > > > > 
> > > > > > > > > > > > >  Benjamin's patch causes the Host Notify IRQ to be
> > > > > > > > > > > > > 
> > > > > > > > > > > > > assigned to the i2c client your patch creates, thus
> > > > > > > > > > > > > causing lis3lv02d to create /dev/freefall, which in
> > > > > > > > > > > > > turn conflicts with dell-smo8800 which is trying to
> > > > > > > > > > > > > create /dev/freefall itself.
> > > > > > > > > > > > 
> > > > > > > > > > > > So 4d5538f5882a is breaking lis3lv02d driver...
> > > > > > > > > > > 
> > > > > > > > > > > Apologies for that.
> > > > > > > > > > > 
> > > > > > > > > > > I could easily fix this by adding a kernel API to know
> > > > > > > > > > > whether the provided irq is from Host Notify or if it was
> > > > > > > > > > > coming from an actual declaration. However, I have no idea
> > > > > > > > > > > how many other drivers would require this (hopefully only
> > > > > > > > > > > this one).
> > > > > > > > > > > 
> > > > > > > > > > > One other solution would be to reserve the Host Notify IRQ
> > > > > > > > > > > and let the actual drivers that need it to set it, but
> > > > > > > > > > > this was not the best solution according to Dmitri. On my
> > > > > > > > > > > side, I am not entirely against this given that it's a
> > > > > > > > > > > chip feature, so the driver should be able to know that
> > > > > > > > > > > it's available.
> > > > > > > > > > > 
> > > > > > > > > > > Dmitri, Wolfram, Jean, any preferences?
> > > > > > > > > > 
> > > > > > > > > > I read this:
> > > > > > > > > > 
> > > > > > > > > > "IIRC both dell-smo8800 and lis3lv02d represent one HW device
> > > > > > > > > > (that ST microelectronics accelerometer) but due to
> > > > > > > > > > complicated HW abstraction and layers on Dell laptops it is
> > > > > > > > > > handled by two drivers, one ACPI and one i2c."
> > > > > > > > > > 
> > > > > > > > > > and that is the core of the issue. You have 2 drivers
> > > > > > > > > > fighting over the same device. Fix this and it will all
> > > > > > > > > > work.
> > > > > > > > > 
> > > > > > > > > With my current implementation (which I sent in this patch),
> > > > > > > > > they are not fighting.
> > > > > > > > > 
> > > > > > > > > dell-smo8800 exports /dev/freefall (and nothing more) and
> > > > > > > > > lis3lv02d only accelerometer device as lis3lv02d driver does
> > > > > > > > > not get IRQ number in platform data.
> > > > > > > > > 
> > > > > > > > > > As far as I can see hp_accel instantiates lis3lv02d and
> > > > > > > > > > accesses it via ACPI methods, can the same be done for Dell?
> > > > > > > > > 
> > > > > > > > > No, Dell does not have any ACPI methods. And as I wrote in ACPI
> > > > > > > > > or DMI is even not i2c address of device, so it needs to be
> > > > > > > > > specified in code itself.
> > > > > > > > > 
> > > > > > > > > Really there is no other way... :-(
> > > > > > > > 
> > > > > > > > Sure there is:
> > > > > > > > 
> > > > > > > > 1. dell-smo8800 instantiates I2C device as "dell-smo8800-accel".
> > > > > > > > 2. dell-smo8800 provides read/write functions for lis3lv02d that
> > > > > > > > simply forward requests to dell-smo8800-accel i2c client.
> > > > > > > > 3. dell-smo8800 instantiates lis3lv02d instance like hp_accel
> > > > > > > > does.
> > > > > > > 
> > > > > > > Sorry, but I do not understand how you mean it... Why to provides
> > > > > > > new read/write i2c functions which are already implemented by
> > > > > > > i2c-i801 bus and lis3lv02d i2c driver?
> > > > > > 
> > > > > > Because that would allow you to avoid clashes with i2c creating
> > > > > > interrupt mapping for client residing on host-notify-capable
> > > > > > controller.
> > > > > > 
> > > > > > > > Alternatively, can lis3lv02d be tasked to create /dev/freefall?
> > > > > > > 
> > > > > > > If i2c_board_info contains IRQ then lis3lv02d create /dev/freefall
> > > > > > > device.
> > > > > > > 
> > > > > > > But... what is problem with current implementation? Accelerometer
> > > > > > > HW provides two functions:
> > > > > > > 
> > > > > > > 1) 3 axes reports
> > > > > > > 2) Disk freefall detection
> > > > > > > 
> > > > > > > And 1) is handled by i2c driver lis3lv02d and 2) is by
> > > > > > > dell-smo8800. Both functions are independent here.
> > > > > > > 
> > > > > > > I think you just trying to complicate this situation even more to
> > > > > > > be more complicated as currently is.
> > > > > > 
> > > > > > Because this apparently does not work for you, does it?
> > > > > 
> > > > > It is working fine. I do not see any problem.
> > > > > 
> > > > > > In general,
> > > > > > if you want the same hardware be handled by 2 different drivers you
> > > > > > are going to have bad time.
> > > > > 
> > > > > Yes, but in this case half of device is ACPI based and other half i2c 
> > > > > based. This is problem of ACPI and Dell design.
> > > > > 
> > > > > > It seems to be that /dev/freefall in dell-smo8800 and lis3lv02d are
> > > > > > the same, right?
> > > > > 
> > > > > Yes. I understand that clean solution is to have one driver which 
> > > > > provides everything.
> > > > > 
> > > > > But because half of data are ACPI and half i2c, you still needs to 
> > > > > create two drivers (one ACPI and one i2c). You can put both drivers into 
> > > > > one .ko module, but still these will be two drivers due to how ACPI and 
> > > > > i2c linux abstractions are different.
> > > > > 
> > > > > > So, instead of having 2 drivers split the
> > > > > > functionality, can you forego registering smo8800 ACPI driver on
> > > > > > your whitelisted boxes and instead instantiate full i2c client
> > > > > > device with properly assigned both address and IRQ and let lis3lv02d
> > > > > > handle it (providing both accelerometer data and /dev/freefall)?
> > > > > 
> > > > > With Michał we already discussed about it, see emails. Basically you can 
> > > > > enable/disable kernel modules at compile time or blacklist at runtime 
> > > > > (or even chose what will be compiled into vmlinux and what as external 
> > > > > .ko module).
> > > > 
> > > > This can be solved with a bit of Kconfig/IS_ENABLED() code.
> > > > 
> > > > > Some distributions blacklist i2c-i801.ko module... And 
> > > > 
> > > > Any particular reason for that?
> > > > 
> > > > > there can be also problem with initialization of i2c-i801 driver (fix is 
> > > > > in commit a7ae81952cda, but does not have to work at every time!). So 
> > > > > that move on whitelisted machines can potentially cause disappearance of 
> > > > > /dev/freefall and users will not have hdd protection which is currently 
> > > > > working.
> > > > 
> > > > Well, I gave you 2 possible solutions (roll your own i2c read/write,
> > > > forward them to i2c client) or have faith in your implementation and let
> > > > lis3lv02d handle it.
> > > > 
> > > > The 3rd one is to possibly add a flag to disable host notify to IRQ
> > > > mapping for given client (if Wolfram/Jean OK with it).
> > > > 
> > > > Oh, the 4th one: change the irq in lis3lv02d.h to be "int" and change
> > > > the check in lis3lv02d.c to be "lis->irq <= 0" and instantiate your
> > > > i2c_client with board_info->irq = -1.
> > > > 
> > > > Pick whichever you prefer.
> > > > 
> > > > By the way, what do you need accelerometer for on these devices? They
> > > > don't appear to be tablets that could use one... 
> > > 
> > > Ah, you are talking about problem that after 4d5538f5882a lis3lv02d will
> > > not work... I thought that discussion is about different mechanism how
> > > to implement bus registration notification to smo8800 driver (or
> > > different solution to not have registration in i801).
> > > 
> > 
> > Just because I am not sure I got everything right, could you confirm
> > that:
> > - in the current upstream tree, the dell-smo8800 driver is now broken
> >   after 4d5538f5882a (i2c: use an IRQ to report Host Notify events, not
> >   alert)
> 
> No, dell-smo8800 it is working fine. It is fully independent from i2c
> and lis3lv02d. It is pure ACPI driver which does not share anything with
> i2c.
> 
> > - this series adds an extra lis3lv02d on some machines and you have
> >   problem fighting for the irq (but this is not upstream yet).
> 
> Yes, this series (not merged yet) adds extra lis3lv02d device but is not
> working because of 4d5538f5882a.
> 
> > The extra lis3lv02d node is added from dell-smo8800
> 
> No, dell-smo8800 does not add new node in this patch.
> 
> > If the first point is not correct (by default, dell-smo8800 will not be
> > loaded at the same time than lis3lv02d), then it's a design issue with
> > the interactions between those 2 drivers.
> 
> No, there is no interactions between these two drivers (dell-smo8800 and
> lis3lv02d). dell-smo8800 is pure ACPI driver and exports just
> /dev/freefall device based on IRQ (and nothing more).
> 
> And lis3lv02d in *current* configuration in this patch exports only
> accelerometer input device, not /dev/freefall. It does not use IRQ.
> (Just there is problem with 4d5538f5882a which tells lis3lv02d IRQ
> number which is not freefall report, therefore lis3lv02d does not work).
> 
> To make it clear, ST Accelerometer provides two operations:
> * report free fall
> * report 3 axes
> 
> Free fall is reported by IRQ, state of 3 axes via i2c bus. Free fall IRQ
> is handled by dell-smo8800, state of 3 axes via i2c lis3lv02d driver.
> 
> lis3lv02d can handle also free fall IRQ is platform i2c data provides
> IRQ number for it -- but this is not case in our Dell configuration. But
> commit 4d5538f5882a inject some IRQ number to lis3lv02d driver which is
> not free fall detection and so is breaking lis3lv02 driver. In our Dell
> configuration (by this patch) there should be no IRQ number.
> 
> It is clear now?

I think I am starting to understand the problem.

Currently (upstream tree), 4d5538f5882a doesn't break anything. On the
mentioned Dell platforms, the dell-smo8800 gets loaded and provides
/dev/freefall. lis3lv02d is not loaded so everything just works.

The problem comes from this patch which doesn't set the irq in
i2c_board_info and so i2c_core sets the IRQ to Host Notify. I think
Dmitri already gave you the solution: set the irq to -1 (or -ENOENT)
in i2c_board_info in your patch and only forward it to
lis3lv02d_init_device() only if it is positive (valid).

So, to me 4d5538f5882a doesn't introduce a regression so we should keep
it in its current state.

Cheers,
Benjamin

> 
> > If the first point is correct because ACPI declares both devices, then
> > there is an urgent fix to propose to not enable Host Notify by default
> > on Host Notifier capable adapters. (even though the design between the
> > 2 drivers is wrong, it's considered as a regression).
> > 
> > Cheers,
> > Benjamin
> 
> -- 
> Pali Rohár
> pali.rohar@gmail.com

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Pali Rohár]

On Wednesday 04 January 2017 11:13:06 Benjamin Tissoires wrote:
> On Jan 04 2017 or thereabouts, Pali Rohár wrote:
> > On Wednesday 04 January 2017 10:05:22 Benjamin Tissoires wrote:
> > > On Jan 04 2017 or thereabouts, Pali Rohár wrote:
> > > > On Tuesday 03 January 2017 12:59:37 Dmitry Torokhov wrote:
> > > > > On Tue, Jan 03, 2017 at 09:39:13PM +0100, Pali Rohár wrote:
> > > > > > On Tuesday 03 January 2017 21:24:18 Dmitry Torokhov wrote:
> > > > > > > On Tue, Jan 03, 2017 at 09:05:51PM +0100, Pali Rohár wrote:
> > > > > > > > On Tuesday 03 January 2017 20:48:12 Dmitry Torokhov wrote:
> > > > > > > > > On Tue, Jan 03, 2017 at 07:50:17PM +0100, Pali Rohár wrote:
> > > > > > > > > > On Tuesday 03 January 2017 19:38:43 Dmitry Torokhov wrote:
> > > > > > > > > > > On Tue, Jan 03, 2017 at 10:06:41AM +0100, Benjamin Tissoires
> > > > > > > > > > > 
> > > > > > > > > > > wrote:
> > > > > > > > > > > > On Dec 29 2016 or thereabouts, Pali Rohár wrote:
> > > > > > > > > > > > > On Thursday 29 December 2016 22:09:32 Michał Kępień wrote:
> > > > > > > > > > > > > > > On Thursday 29 December 2016 14:47:19 Michał Kępień
> > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > On Thursday 29 December 2016 09:29:36 Michał
> > > > > > > > > > > > > > > > > Kępień
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > Dell platform team told us that some (DMI
> > > > > > > > > > > > > > > > > > > whitelisted) Dell Latitude machines have ST
> > > > > > > > > > > > > > > > > > > microelectronics accelerometer at i2c address
> > > > > > > > > > > > > > > > > > > 0x29. That i2c address is not specified in
> > > > > > > > > > > > > > > > > > > DMI or ACPI, so runtime detection without
> > > > > > > > > > > > > > > > > > > whitelist which is below is not possible.
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > Presence of that ST microelectronics
> > > > > > > > > > > > > > > > > > > accelerometer is verified by existence of
> > > > > > > > > > > > > > > > > > > SMO88xx ACPI device which represent that
> > > > > > > > > > > > > > > > > > > accelerometer. Unfortunately without i2c
> > > > > > > > > > > > > > > > > > > address.
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > This part of the commit message sounded a bit
> > > > > > > > > > > > > > > > > > confusing to me at first because there is
> > > > > > > > > > > > > > > > > > already an ACPI driver which handles SMO88xx
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > devices (dell-smo8800).  My understanding is
> > > > > > > > > > > > > > > > > > that:
> > > > > > > > > > > > > > > > > >   * the purpose of this patch is to expose a
> > > > > > > > > > > > > > > > > >   richer interface (as
> > > > > > > > > > > > > > > > > >   
> > > > > > > > > > > > > > > > > >     provided by lis3lv02d) to these devices on
> > > > > > > > > > > > > > > > > >     some machines,
> > > > > > > > > > > > > > > > > >   
> > > > > > > > > > > > > > > > > >   * on whitelisted machines, dell-smo8800 and
> > > > > > > > > > > > > > > > > >   lis3lv02d can work
> > > > > > > > > > > > > > > > > >   
> > > > > > > > > > > > > > > > > >     simultaneously (even though dell-smo8800
> > > > > > > > > > > > > > > > > >     effectively duplicates the work that
> > > > > > > > > > > > > > > > > >     lis3lv02d does).
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > No. dell-smo8800 reads from ACPI irq number and
> > > > > > > > > > > > > > > > > exports /dev/freefall device which notify
> > > > > > > > > > > > > > > > > userspace about falls. lis3lv02d is i2c driver
> > > > > > > > > > > > > > > > > which exports axes of accelerometer. Additionaly
> > > > > > > > > > > > > > > > > lis3lv02d can export also /dev/freefall if
> > > > > > > > > > > > > > > > > registerer of i2c device provides irq number --
> > > > > > > > > > > > > > > > > which is not case of this patch.
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > So both drivers are doing different things and
> > > > > > > > > > > > > > > > > both are useful.
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > IIRC both dell-smo8800 and lis3lv02d represent
> > > > > > > > > > > > > > > > > one HW device (that ST microelectronics
> > > > > > > > > > > > > > > > > accelerometer) but due to complicated HW
> > > > > > > > > > > > > > > > > abstraction and layers on Dell laptops it is
> > > > > > > > > > > > > > > > > handled by two drivers, one ACPI and one i2c.
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > Yes, in ideal world irq number should be passed
> > > > > > > > > > > > > > > > > to lis3lv02d driver and that would export whole
> > > > > > > > > > > > > > > > > device (with /dev/freefall too), but due to HW
> > > > > > > > > > > > > > > > > abstraction it is too much complicated...
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > Why?  AFAICT, all that is required to pass that IRQ
> > > > > > > > > > > > > > > > number all the way down to lis3lv02d is to set the
> > > > > > > > > > > > > > > > irq field of the struct i2c_board_info you are
> > > > > > > > > > > > > > > > passing to i2c_new_device().  And you can extract
> > > > > > > > > > > > > > > > that IRQ number e.g. in
> > > > > > > > > > > > > > > > check_acpi_smo88xx_device(). However, you would
> > > > > > > > > > > > > > > > then need to make sure dell-smo8800 does not
> > > > > > > > > > > > > > > > attempt to request the same IRQ on whitelisted
> > > > > > > > > > > > > > > > machines.  This got me thinking about a way to
> > > > > > > > > > > > > > > > somehow incorporate your changes into dell-smo8800
> > > > > > > > > > > > > > > > using Wolfram's bus_notifier suggestion, but I do
> > > > > > > > > > > > > > > > not have a working solution for now.  What is
> > > > > > > > > > > > > > > > tempting about this approach is that you would not
> > > > > > > > > > > > > > > > have to scan the ACPI namespace in search of
> > > > > > > > > > > > > > > > SMO88xx devices, because smo8800_add() is
> > > > > > > > > > > > > > > > automatically called for them. However, I fear that
> > > > > > > > > > > > > > > > the resulting solution may be more complicated than
> > > > > > > > > > > > > > > > the one you submitted.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Then we need to deal with lot of problems. Order of
> > > > > > > > > > > > > > > loading .ko modules is undefined. Binding devices to
> > > > > > > > > > > > > > > drivers registered by .ko module is also in "random"
> > > > > > > > > > > > > > > order. At any time any of those .ko module can be
> > > > > > > > > > > > > > > unloaded or at least device unbind (via sysfs) from
> > > > > > > > > > > > > > > driver... And there can be some pathological
> > > > > > > > > > > > > > > situation (thanks to adding ACPI layer as Andy
> > > > > > > > > > > > > > > pointed) that there will be more SMO88xx devices in
> > > > > > > > > > > > > > > ACPI. Plus you can compile kernel with and without
> > > > > > > > > > > > > > > those modules and also you can blacklist loading
> > > > > > > > > > > > > > > them (so compile time check is not enough). And
> > > > > > > > > > > > > > > still some correct message notifier must be used.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > I think such solution is much much more complicated,
> > > > > > > > > > > > > > > there are lot of combinations of kernel configuration
> > > > > > > > > > > > > > > and available dell devices...
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > I tried a few more things, but ultimately failed to
> > > > > > > > > > > > > > find a nice way to implement this.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Another issue popped up, though.  Linus' master branch
> > > > > > > > > > > > > > contains a recent commit by Benjamin Tissoires (CC'ed),
> > > > > > > > > > > > > > 4d5538f5882a ("i2c: use an IRQ to report Host Notify
> > > > > > > > > > > > > > events, not alert") which breaks your patch.  The
> > > > > > > > > > > > > > reason for that is that lis3lv02d relies on the i2c
> > > > > > > > > > > > > > client's IRQ being 0 to detect that it should not
> > > > > > > > > > > > > > create /dev/freefall.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >  Benjamin's patch causes the Host Notify IRQ to be
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > assigned to the i2c client your patch creates, thus
> > > > > > > > > > > > > > causing lis3lv02d to create /dev/freefall, which in
> > > > > > > > > > > > > > turn conflicts with dell-smo8800 which is trying to
> > > > > > > > > > > > > > create /dev/freefall itself.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > So 4d5538f5882a is breaking lis3lv02d driver...
> > > > > > > > > > > > 
> > > > > > > > > > > > Apologies for that.
> > > > > > > > > > > > 
> > > > > > > > > > > > I could easily fix this by adding a kernel API to know
> > > > > > > > > > > > whether the provided irq is from Host Notify or if it was
> > > > > > > > > > > > coming from an actual declaration. However, I have no idea
> > > > > > > > > > > > how many other drivers would require this (hopefully only
> > > > > > > > > > > > this one).
> > > > > > > > > > > > 
> > > > > > > > > > > > One other solution would be to reserve the Host Notify IRQ
> > > > > > > > > > > > and let the actual drivers that need it to set it, but
> > > > > > > > > > > > this was not the best solution according to Dmitri. On my
> > > > > > > > > > > > side, I am not entirely against this given that it's a
> > > > > > > > > > > > chip feature, so the driver should be able to know that
> > > > > > > > > > > > it's available.
> > > > > > > > > > > > 
> > > > > > > > > > > > Dmitri, Wolfram, Jean, any preferences?
> > > > > > > > > > > 
> > > > > > > > > > > I read this:
> > > > > > > > > > > 
> > > > > > > > > > > "IIRC both dell-smo8800 and lis3lv02d represent one HW device
> > > > > > > > > > > (that ST microelectronics accelerometer) but due to
> > > > > > > > > > > complicated HW abstraction and layers on Dell laptops it is
> > > > > > > > > > > handled by two drivers, one ACPI and one i2c."
> > > > > > > > > > > 
> > > > > > > > > > > and that is the core of the issue. You have 2 drivers
> > > > > > > > > > > fighting over the same device. Fix this and it will all
> > > > > > > > > > > work.
> > > > > > > > > > 
> > > > > > > > > > With my current implementation (which I sent in this patch),
> > > > > > > > > > they are not fighting.
> > > > > > > > > > 
> > > > > > > > > > dell-smo8800 exports /dev/freefall (and nothing more) and
> > > > > > > > > > lis3lv02d only accelerometer device as lis3lv02d driver does
> > > > > > > > > > not get IRQ number in platform data.
> > > > > > > > > > 
> > > > > > > > > > > As far as I can see hp_accel instantiates lis3lv02d and
> > > > > > > > > > > accesses it via ACPI methods, can the same be done for Dell?
> > > > > > > > > > 
> > > > > > > > > > No, Dell does not have any ACPI methods. And as I wrote in ACPI
> > > > > > > > > > or DMI is even not i2c address of device, so it needs to be
> > > > > > > > > > specified in code itself.
> > > > > > > > > > 
> > > > > > > > > > Really there is no other way... :-(
> > > > > > > > > 
> > > > > > > > > Sure there is:
> > > > > > > > > 
> > > > > > > > > 1. dell-smo8800 instantiates I2C device as "dell-smo8800-accel".
> > > > > > > > > 2. dell-smo8800 provides read/write functions for lis3lv02d that
> > > > > > > > > simply forward requests to dell-smo8800-accel i2c client.
> > > > > > > > > 3. dell-smo8800 instantiates lis3lv02d instance like hp_accel
> > > > > > > > > does.
> > > > > > > > 
> > > > > > > > Sorry, but I do not understand how you mean it... Why to provides
> > > > > > > > new read/write i2c functions which are already implemented by
> > > > > > > > i2c-i801 bus and lis3lv02d i2c driver?
> > > > > > > 
> > > > > > > Because that would allow you to avoid clashes with i2c creating
> > > > > > > interrupt mapping for client residing on host-notify-capable
> > > > > > > controller.
> > > > > > > 
> > > > > > > > > Alternatively, can lis3lv02d be tasked to create /dev/freefall?
> > > > > > > > 
> > > > > > > > If i2c_board_info contains IRQ then lis3lv02d create /dev/freefall
> > > > > > > > device.
> > > > > > > > 
> > > > > > > > But... what is problem with current implementation? Accelerometer
> > > > > > > > HW provides two functions:
> > > > > > > > 
> > > > > > > > 1) 3 axes reports
> > > > > > > > 2) Disk freefall detection
> > > > > > > > 
> > > > > > > > And 1) is handled by i2c driver lis3lv02d and 2) is by
> > > > > > > > dell-smo8800. Both functions are independent here.
> > > > > > > > 
> > > > > > > > I think you just trying to complicate this situation even more to
> > > > > > > > be more complicated as currently is.
> > > > > > > 
> > > > > > > Because this apparently does not work for you, does it?
> > > > > > 
> > > > > > It is working fine. I do not see any problem.
> > > > > > 
> > > > > > > In general,
> > > > > > > if you want the same hardware be handled by 2 different drivers you
> > > > > > > are going to have bad time.
> > > > > > 
> > > > > > Yes, but in this case half of device is ACPI based and other half i2c 
> > > > > > based. This is problem of ACPI and Dell design.
> > > > > > 
> > > > > > > It seems to be that /dev/freefall in dell-smo8800 and lis3lv02d are
> > > > > > > the same, right?
> > > > > > 
> > > > > > Yes. I understand that clean solution is to have one driver which 
> > > > > > provides everything.
> > > > > > 
> > > > > > But because half of data are ACPI and half i2c, you still needs to 
> > > > > > create two drivers (one ACPI and one i2c). You can put both drivers into 
> > > > > > one .ko module, but still these will be two drivers due to how ACPI and 
> > > > > > i2c linux abstractions are different.
> > > > > > 
> > > > > > > So, instead of having 2 drivers split the
> > > > > > > functionality, can you forego registering smo8800 ACPI driver on
> > > > > > > your whitelisted boxes and instead instantiate full i2c client
> > > > > > > device with properly assigned both address and IRQ and let lis3lv02d
> > > > > > > handle it (providing both accelerometer data and /dev/freefall)?
> > > > > > 
> > > > > > With Michał we already discussed about it, see emails. Basically you can 
> > > > > > enable/disable kernel modules at compile time or blacklist at runtime 
> > > > > > (or even chose what will be compiled into vmlinux and what as external 
> > > > > > .ko module).
> > > > > 
> > > > > This can be solved with a bit of Kconfig/IS_ENABLED() code.
> > > > > 
> > > > > > Some distributions blacklist i2c-i801.ko module... And 
> > > > > 
> > > > > Any particular reason for that?
> > > > > 
> > > > > > there can be also problem with initialization of i2c-i801 driver (fix is 
> > > > > > in commit a7ae81952cda, but does not have to work at every time!). So 
> > > > > > that move on whitelisted machines can potentially cause disappearance of 
> > > > > > /dev/freefall and users will not have hdd protection which is currently 
> > > > > > working.
> > > > > 
> > > > > Well, I gave you 2 possible solutions (roll your own i2c read/write,
> > > > > forward them to i2c client) or have faith in your implementation and let
> > > > > lis3lv02d handle it.
> > > > > 
> > > > > The 3rd one is to possibly add a flag to disable host notify to IRQ
> > > > > mapping for given client (if Wolfram/Jean OK with it).
> > > > > 
> > > > > Oh, the 4th one: change the irq in lis3lv02d.h to be "int" and change
> > > > > the check in lis3lv02d.c to be "lis->irq <= 0" and instantiate your
> > > > > i2c_client with board_info->irq = -1.
> > > > > 
> > > > > Pick whichever you prefer.
> > > > > 
> > > > > By the way, what do you need accelerometer for on these devices? They
> > > > > don't appear to be tablets that could use one... 
> > > > 
> > > > Ah, you are talking about problem that after 4d5538f5882a lis3lv02d will
> > > > not work... I thought that discussion is about different mechanism how
> > > > to implement bus registration notification to smo8800 driver (or
> > > > different solution to not have registration in i801).
> > > > 
> > > 
> > > Just because I am not sure I got everything right, could you confirm
> > > that:
> > > - in the current upstream tree, the dell-smo8800 driver is now broken
> > >   after 4d5538f5882a (i2c: use an IRQ to report Host Notify events, not
> > >   alert)
> > 
> > No, dell-smo8800 it is working fine. It is fully independent from i2c
> > and lis3lv02d. It is pure ACPI driver which does not share anything with
> > i2c.
> > 
> > > - this series adds an extra lis3lv02d on some machines and you have
> > >   problem fighting for the irq (but this is not upstream yet).
> > 
> > Yes, this series (not merged yet) adds extra lis3lv02d device but is not
> > working because of 4d5538f5882a.
> > 
> > > The extra lis3lv02d node is added from dell-smo8800
> > 
> > No, dell-smo8800 does not add new node in this patch.
> > 
> > > If the first point is not correct (by default, dell-smo8800 will not be
> > > loaded at the same time than lis3lv02d), then it's a design issue with
> > > the interactions between those 2 drivers.
> > 
> > No, there is no interactions between these two drivers (dell-smo8800 and
> > lis3lv02d). dell-smo8800 is pure ACPI driver and exports just
> > /dev/freefall device based on IRQ (and nothing more).
> > 
> > And lis3lv02d in *current* configuration in this patch exports only
> > accelerometer input device, not /dev/freefall. It does not use IRQ.
> > (Just there is problem with 4d5538f5882a which tells lis3lv02d IRQ
> > number which is not freefall report, therefore lis3lv02d does not work).
> > 
> > To make it clear, ST Accelerometer provides two operations:
> > * report free fall
> > * report 3 axes
> > 
> > Free fall is reported by IRQ, state of 3 axes via i2c bus. Free fall IRQ
> > is handled by dell-smo8800, state of 3 axes via i2c lis3lv02d driver.
> > 
> > lis3lv02d can handle also free fall IRQ is platform i2c data provides
> > IRQ number for it -- but this is not case in our Dell configuration. But
> > commit 4d5538f5882a inject some IRQ number to lis3lv02d driver which is
> > not free fall detection and so is breaking lis3lv02 driver. In our Dell
> > configuration (by this patch) there should be no IRQ number.
> > 
> > It is clear now?
> 
> I think I am starting to understand the problem.
> 
> Currently (upstream tree), 4d5538f5882a doesn't break anything.

I cannot prove it... lis3lv02d i2c driver itself uses this IRQ logic
(missing = no freefall) and there could be already hardware/boards which
register lis3lv02d i2c device without IRQ number. And definitions could
be also in device tree and so outside of kernel sources...

So there can be potentially break. But at least not case of Dell.

> On the
> mentioned Dell platforms, the dell-smo8800 gets loaded and provides
> /dev/freefall. lis3lv02d is not loaded so everything just works.

Yes.

> The problem comes from this patch which doesn't set the irq in
> i2c_board_info and so i2c_core sets the IRQ to Host Notify. I think
> Dmitri already gave you the solution: set the irq to -1 (or -ENOENT)
> in i2c_board_info in your patch and only forward it to
> lis3lv02d_init_device() only if it is positive (valid).

Now I understood that Dmitri means. For this Dell platforms it is OK,
but we have a problem for device tree platforms. Normally in device tree
if device does not support something you just do not specify it. But
with this approach you need to explicitly specify IRQ to -1 in device
tree. And I think this is really not a clean solution.

> So, to me 4d5538f5882a doesn't introduce a regression so we should keep
> it in its current state.
> 
> Cheers,
> Benjamin
> 
> > 
> > > If the first point is correct because ACPI declares both devices, then
> > > there is an urgent fix to propose to not enable Host Notify by default
> > > on Host Notifier capable adapters. (even though the design between the
> > > 2 drivers is wrong, it's considered as a regression).
> > > 
> > > Cheers,
> > > Benjamin
> > 
> > -- 
> > Pali Rohár
> > pali.rohar@gmail.com

-- 
Pali Rohár
pali.rohar@gmail.com

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Benjamin Tissoires]

On Jan 04 2017 or thereabouts, Pali Rohár wrote:
> On Wednesday 04 January 2017 11:13:06 Benjamin Tissoires wrote:
> > On Jan 04 2017 or thereabouts, Pali Rohár wrote:
> > > On Wednesday 04 January 2017 10:05:22 Benjamin Tissoires wrote:
> > > > On Jan 04 2017 or thereabouts, Pali Rohár wrote:
> > > > > On Tuesday 03 January 2017 12:59:37 Dmitry Torokhov wrote:
> > > > > > On Tue, Jan 03, 2017 at 09:39:13PM +0100, Pali Rohár wrote:
> > > > > > > On Tuesday 03 January 2017 21:24:18 Dmitry Torokhov wrote:
> > > > > > > > On Tue, Jan 03, 2017 at 09:05:51PM +0100, Pali Rohár wrote:
> > > > > > > > > On Tuesday 03 January 2017 20:48:12 Dmitry Torokhov wrote:
> > > > > > > > > > On Tue, Jan 03, 2017 at 07:50:17PM +0100, Pali Rohár wrote:
> > > > > > > > > > > On Tuesday 03 January 2017 19:38:43 Dmitry Torokhov wrote:
> > > > > > > > > > > > On Tue, Jan 03, 2017 at 10:06:41AM +0100, Benjamin Tissoires
> > > > > > > > > > > > 
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > On Dec 29 2016 or thereabouts, Pali Rohár wrote:
> > > > > > > > > > > > > > On Thursday 29 December 2016 22:09:32 Michał Kępień wrote:
> > > > > > > > > > > > > > > > On Thursday 29 December 2016 14:47:19 Michał Kępień
> > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > On Thursday 29 December 2016 09:29:36 Michał
> > > > > > > > > > > > > > > > > > Kępień
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > Dell platform team told us that some (DMI
> > > > > > > > > > > > > > > > > > > > whitelisted) Dell Latitude machines have ST
> > > > > > > > > > > > > > > > > > > > microelectronics accelerometer at i2c address
> > > > > > > > > > > > > > > > > > > > 0x29. That i2c address is not specified in
> > > > > > > > > > > > > > > > > > > > DMI or ACPI, so runtime detection without
> > > > > > > > > > > > > > > > > > > > whitelist which is below is not possible.
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > Presence of that ST microelectronics
> > > > > > > > > > > > > > > > > > > > accelerometer is verified by existence of
> > > > > > > > > > > > > > > > > > > > SMO88xx ACPI device which represent that
> > > > > > > > > > > > > > > > > > > > accelerometer. Unfortunately without i2c
> > > > > > > > > > > > > > > > > > > > address.
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > This part of the commit message sounded a bit
> > > > > > > > > > > > > > > > > > > confusing to me at first because there is
> > > > > > > > > > > > > > > > > > > already an ACPI driver which handles SMO88xx
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > devices (dell-smo8800).  My understanding is
> > > > > > > > > > > > > > > > > > > that:
> > > > > > > > > > > > > > > > > > >   * the purpose of this patch is to expose a
> > > > > > > > > > > > > > > > > > >   richer interface (as
> > > > > > > > > > > > > > > > > > >   
> > > > > > > > > > > > > > > > > > >     provided by lis3lv02d) to these devices on
> > > > > > > > > > > > > > > > > > >     some machines,
> > > > > > > > > > > > > > > > > > >   
> > > > > > > > > > > > > > > > > > >   * on whitelisted machines, dell-smo8800 and
> > > > > > > > > > > > > > > > > > >   lis3lv02d can work
> > > > > > > > > > > > > > > > > > >   
> > > > > > > > > > > > > > > > > > >     simultaneously (even though dell-smo8800
> > > > > > > > > > > > > > > > > > >     effectively duplicates the work that
> > > > > > > > > > > > > > > > > > >     lis3lv02d does).
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > No. dell-smo8800 reads from ACPI irq number and
> > > > > > > > > > > > > > > > > > exports /dev/freefall device which notify
> > > > > > > > > > > > > > > > > > userspace about falls. lis3lv02d is i2c driver
> > > > > > > > > > > > > > > > > > which exports axes of accelerometer. Additionaly
> > > > > > > > > > > > > > > > > > lis3lv02d can export also /dev/freefall if
> > > > > > > > > > > > > > > > > > registerer of i2c device provides irq number --
> > > > > > > > > > > > > > > > > > which is not case of this patch.
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > So both drivers are doing different things and
> > > > > > > > > > > > > > > > > > both are useful.
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > IIRC both dell-smo8800 and lis3lv02d represent
> > > > > > > > > > > > > > > > > > one HW device (that ST microelectronics
> > > > > > > > > > > > > > > > > > accelerometer) but due to complicated HW
> > > > > > > > > > > > > > > > > > abstraction and layers on Dell laptops it is
> > > > > > > > > > > > > > > > > > handled by two drivers, one ACPI and one i2c.
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > Yes, in ideal world irq number should be passed
> > > > > > > > > > > > > > > > > > to lis3lv02d driver and that would export whole
> > > > > > > > > > > > > > > > > > device (with /dev/freefall too), but due to HW
> > > > > > > > > > > > > > > > > > abstraction it is too much complicated...
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > Why?  AFAICT, all that is required to pass that IRQ
> > > > > > > > > > > > > > > > > number all the way down to lis3lv02d is to set the
> > > > > > > > > > > > > > > > > irq field of the struct i2c_board_info you are
> > > > > > > > > > > > > > > > > passing to i2c_new_device().  And you can extract
> > > > > > > > > > > > > > > > > that IRQ number e.g. in
> > > > > > > > > > > > > > > > > check_acpi_smo88xx_device(). However, you would
> > > > > > > > > > > > > > > > > then need to make sure dell-smo8800 does not
> > > > > > > > > > > > > > > > > attempt to request the same IRQ on whitelisted
> > > > > > > > > > > > > > > > > machines.  This got me thinking about a way to
> > > > > > > > > > > > > > > > > somehow incorporate your changes into dell-smo8800
> > > > > > > > > > > > > > > > > using Wolfram's bus_notifier suggestion, but I do
> > > > > > > > > > > > > > > > > not have a working solution for now.  What is
> > > > > > > > > > > > > > > > > tempting about this approach is that you would not
> > > > > > > > > > > > > > > > > have to scan the ACPI namespace in search of
> > > > > > > > > > > > > > > > > SMO88xx devices, because smo8800_add() is
> > > > > > > > > > > > > > > > > automatically called for them. However, I fear that
> > > > > > > > > > > > > > > > > the resulting solution may be more complicated than
> > > > > > > > > > > > > > > > > the one you submitted.
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > Then we need to deal with lot of problems. Order of
> > > > > > > > > > > > > > > > loading .ko modules is undefined. Binding devices to
> > > > > > > > > > > > > > > > drivers registered by .ko module is also in "random"
> > > > > > > > > > > > > > > > order. At any time any of those .ko module can be
> > > > > > > > > > > > > > > > unloaded or at least device unbind (via sysfs) from
> > > > > > > > > > > > > > > > driver... And there can be some pathological
> > > > > > > > > > > > > > > > situation (thanks to adding ACPI layer as Andy
> > > > > > > > > > > > > > > > pointed) that there will be more SMO88xx devices in
> > > > > > > > > > > > > > > > ACPI. Plus you can compile kernel with and without
> > > > > > > > > > > > > > > > those modules and also you can blacklist loading
> > > > > > > > > > > > > > > > them (so compile time check is not enough). And
> > > > > > > > > > > > > > > > still some correct message notifier must be used.
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > I think such solution is much much more complicated,
> > > > > > > > > > > > > > > > there are lot of combinations of kernel configuration
> > > > > > > > > > > > > > > > and available dell devices...
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > I tried a few more things, but ultimately failed to
> > > > > > > > > > > > > > > find a nice way to implement this.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Another issue popped up, though.  Linus' master branch
> > > > > > > > > > > > > > > contains a recent commit by Benjamin Tissoires (CC'ed),
> > > > > > > > > > > > > > > 4d5538f5882a ("i2c: use an IRQ to report Host Notify
> > > > > > > > > > > > > > > events, not alert") which breaks your patch.  The
> > > > > > > > > > > > > > > reason for that is that lis3lv02d relies on the i2c
> > > > > > > > > > > > > > > client's IRQ being 0 to detect that it should not
> > > > > > > > > > > > > > > create /dev/freefall.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >  Benjamin's patch causes the Host Notify IRQ to be
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > assigned to the i2c client your patch creates, thus
> > > > > > > > > > > > > > > causing lis3lv02d to create /dev/freefall, which in
> > > > > > > > > > > > > > > turn conflicts with dell-smo8800 which is trying to
> > > > > > > > > > > > > > > create /dev/freefall itself.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > So 4d5538f5882a is breaking lis3lv02d driver...
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Apologies for that.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I could easily fix this by adding a kernel API to know
> > > > > > > > > > > > > whether the provided irq is from Host Notify or if it was
> > > > > > > > > > > > > coming from an actual declaration. However, I have no idea
> > > > > > > > > > > > > how many other drivers would require this (hopefully only
> > > > > > > > > > > > > this one).
> > > > > > > > > > > > > 
> > > > > > > > > > > > > One other solution would be to reserve the Host Notify IRQ
> > > > > > > > > > > > > and let the actual drivers that need it to set it, but
> > > > > > > > > > > > > this was not the best solution according to Dmitri. On my
> > > > > > > > > > > > > side, I am not entirely against this given that it's a
> > > > > > > > > > > > > chip feature, so the driver should be able to know that
> > > > > > > > > > > > > it's available.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Dmitri, Wolfram, Jean, any preferences?
> > > > > > > > > > > > 
> > > > > > > > > > > > I read this:
> > > > > > > > > > > > 
> > > > > > > > > > > > "IIRC both dell-smo8800 and lis3lv02d represent one HW device
> > > > > > > > > > > > (that ST microelectronics accelerometer) but due to
> > > > > > > > > > > > complicated HW abstraction and layers on Dell laptops it is
> > > > > > > > > > > > handled by two drivers, one ACPI and one i2c."
> > > > > > > > > > > > 
> > > > > > > > > > > > and that is the core of the issue. You have 2 drivers
> > > > > > > > > > > > fighting over the same device. Fix this and it will all
> > > > > > > > > > > > work.
> > > > > > > > > > > 
> > > > > > > > > > > With my current implementation (which I sent in this patch),
> > > > > > > > > > > they are not fighting.
> > > > > > > > > > > 
> > > > > > > > > > > dell-smo8800 exports /dev/freefall (and nothing more) and
> > > > > > > > > > > lis3lv02d only accelerometer device as lis3lv02d driver does
> > > > > > > > > > > not get IRQ number in platform data.
> > > > > > > > > > > 
> > > > > > > > > > > > As far as I can see hp_accel instantiates lis3lv02d and
> > > > > > > > > > > > accesses it via ACPI methods, can the same be done for Dell?
> > > > > > > > > > > 
> > > > > > > > > > > No, Dell does not have any ACPI methods. And as I wrote in ACPI
> > > > > > > > > > > or DMI is even not i2c address of device, so it needs to be
> > > > > > > > > > > specified in code itself.
> > > > > > > > > > > 
> > > > > > > > > > > Really there is no other way... :-(
> > > > > > > > > > 
> > > > > > > > > > Sure there is:
> > > > > > > > > > 
> > > > > > > > > > 1. dell-smo8800 instantiates I2C device as "dell-smo8800-accel".
> > > > > > > > > > 2. dell-smo8800 provides read/write functions for lis3lv02d that
> > > > > > > > > > simply forward requests to dell-smo8800-accel i2c client.
> > > > > > > > > > 3. dell-smo8800 instantiates lis3lv02d instance like hp_accel
> > > > > > > > > > does.
> > > > > > > > > 
> > > > > > > > > Sorry, but I do not understand how you mean it... Why to provides
> > > > > > > > > new read/write i2c functions which are already implemented by
> > > > > > > > > i2c-i801 bus and lis3lv02d i2c driver?
> > > > > > > > 
> > > > > > > > Because that would allow you to avoid clashes with i2c creating
> > > > > > > > interrupt mapping for client residing on host-notify-capable
> > > > > > > > controller.
> > > > > > > > 
> > > > > > > > > > Alternatively, can lis3lv02d be tasked to create /dev/freefall?
> > > > > > > > > 
> > > > > > > > > If i2c_board_info contains IRQ then lis3lv02d create /dev/freefall
> > > > > > > > > device.
> > > > > > > > > 
> > > > > > > > > But... what is problem with current implementation? Accelerometer
> > > > > > > > > HW provides two functions:
> > > > > > > > > 
> > > > > > > > > 1) 3 axes reports
> > > > > > > > > 2) Disk freefall detection
> > > > > > > > > 
> > > > > > > > > And 1) is handled by i2c driver lis3lv02d and 2) is by
> > > > > > > > > dell-smo8800. Both functions are independent here.
> > > > > > > > > 
> > > > > > > > > I think you just trying to complicate this situation even more to
> > > > > > > > > be more complicated as currently is.
> > > > > > > > 
> > > > > > > > Because this apparently does not work for you, does it?
> > > > > > > 
> > > > > > > It is working fine. I do not see any problem.
> > > > > > > 
> > > > > > > > In general,
> > > > > > > > if you want the same hardware be handled by 2 different drivers you
> > > > > > > > are going to have bad time.
> > > > > > > 
> > > > > > > Yes, but in this case half of device is ACPI based and other half i2c 
> > > > > > > based. This is problem of ACPI and Dell design.
> > > > > > > 
> > > > > > > > It seems to be that /dev/freefall in dell-smo8800 and lis3lv02d are
> > > > > > > > the same, right?
> > > > > > > 
> > > > > > > Yes. I understand that clean solution is to have one driver which 
> > > > > > > provides everything.
> > > > > > > 
> > > > > > > But because half of data are ACPI and half i2c, you still needs to 
> > > > > > > create two drivers (one ACPI and one i2c). You can put both drivers into 
> > > > > > > one .ko module, but still these will be two drivers due to how ACPI and 
> > > > > > > i2c linux abstractions are different.
> > > > > > > 
> > > > > > > > So, instead of having 2 drivers split the
> > > > > > > > functionality, can you forego registering smo8800 ACPI driver on
> > > > > > > > your whitelisted boxes and instead instantiate full i2c client
> > > > > > > > device with properly assigned both address and IRQ and let lis3lv02d
> > > > > > > > handle it (providing both accelerometer data and /dev/freefall)?
> > > > > > > 
> > > > > > > With Michał we already discussed about it, see emails. Basically you can 
> > > > > > > enable/disable kernel modules at compile time or blacklist at runtime 
> > > > > > > (or even chose what will be compiled into vmlinux and what as external 
> > > > > > > .ko module).
> > > > > > 
> > > > > > This can be solved with a bit of Kconfig/IS_ENABLED() code.
> > > > > > 
> > > > > > > Some distributions blacklist i2c-i801.ko module... And 
> > > > > > 
> > > > > > Any particular reason for that?
> > > > > > 
> > > > > > > there can be also problem with initialization of i2c-i801 driver (fix is 
> > > > > > > in commit a7ae81952cda, but does not have to work at every time!). So 
> > > > > > > that move on whitelisted machines can potentially cause disappearance of 
> > > > > > > /dev/freefall and users will not have hdd protection which is currently 
> > > > > > > working.
> > > > > > 
> > > > > > Well, I gave you 2 possible solutions (roll your own i2c read/write,
> > > > > > forward them to i2c client) or have faith in your implementation and let
> > > > > > lis3lv02d handle it.
> > > > > > 
> > > > > > The 3rd one is to possibly add a flag to disable host notify to IRQ
> > > > > > mapping for given client (if Wolfram/Jean OK with it).
> > > > > > 
> > > > > > Oh, the 4th one: change the irq in lis3lv02d.h to be "int" and change
> > > > > > the check in lis3lv02d.c to be "lis->irq <= 0" and instantiate your
> > > > > > i2c_client with board_info->irq = -1.
> > > > > > 
> > > > > > Pick whichever you prefer.
> > > > > > 
> > > > > > By the way, what do you need accelerometer for on these devices? They
> > > > > > don't appear to be tablets that could use one... 
> > > > > 
> > > > > Ah, you are talking about problem that after 4d5538f5882a lis3lv02d will
> > > > > not work... I thought that discussion is about different mechanism how
> > > > > to implement bus registration notification to smo8800 driver (or
> > > > > different solution to not have registration in i801).
> > > > > 
> > > > 
> > > > Just because I am not sure I got everything right, could you confirm
> > > > that:
> > > > - in the current upstream tree, the dell-smo8800 driver is now broken
> > > >   after 4d5538f5882a (i2c: use an IRQ to report Host Notify events, not
> > > >   alert)
> > > 
> > > No, dell-smo8800 it is working fine. It is fully independent from i2c
> > > and lis3lv02d. It is pure ACPI driver which does not share anything with
> > > i2c.
> > > 
> > > > - this series adds an extra lis3lv02d on some machines and you have
> > > >   problem fighting for the irq (but this is not upstream yet).
> > > 
> > > Yes, this series (not merged yet) adds extra lis3lv02d device but is not
> > > working because of 4d5538f5882a.
> > > 
> > > > The extra lis3lv02d node is added from dell-smo8800
> > > 
> > > No, dell-smo8800 does not add new node in this patch.
> > > 
> > > > If the first point is not correct (by default, dell-smo8800 will not be
> > > > loaded at the same time than lis3lv02d), then it's a design issue with
> > > > the interactions between those 2 drivers.
> > > 
> > > No, there is no interactions between these two drivers (dell-smo8800 and
> > > lis3lv02d). dell-smo8800 is pure ACPI driver and exports just
> > > /dev/freefall device based on IRQ (and nothing more).
> > > 
> > > And lis3lv02d in *current* configuration in this patch exports only
> > > accelerometer input device, not /dev/freefall. It does not use IRQ.
> > > (Just there is problem with 4d5538f5882a which tells lis3lv02d IRQ
> > > number which is not freefall report, therefore lis3lv02d does not work).
> > > 
> > > To make it clear, ST Accelerometer provides two operations:
> > > * report free fall
> > > * report 3 axes
> > > 
> > > Free fall is reported by IRQ, state of 3 axes via i2c bus. Free fall IRQ
> > > is handled by dell-smo8800, state of 3 axes via i2c lis3lv02d driver.
> > > 
> > > lis3lv02d can handle also free fall IRQ is platform i2c data provides
> > > IRQ number for it -- but this is not case in our Dell configuration. But
> > > commit 4d5538f5882a inject some IRQ number to lis3lv02d driver which is
> > > not free fall detection and so is breaking lis3lv02 driver. In our Dell
> > > configuration (by this patch) there should be no IRQ number.
> > > 
> > > It is clear now?
> > 
> > I think I am starting to understand the problem.
> > 
> > Currently (upstream tree), 4d5538f5882a doesn't break anything.
> 
> I cannot prove it... lis3lv02d i2c driver itself uses this IRQ logic
> (missing = no freefall) and there could be already hardware/boards which
> register lis3lv02d i2c device without IRQ number. And definitions could
> be also in device tree and so outside of kernel sources...
> 
> So there can be potentially break. But at least not case of Dell.
> 
> > On the
> > mentioned Dell platforms, the dell-smo8800 gets loaded and provides
> > /dev/freefall. lis3lv02d is not loaded so everything just works.
> 
> Yes.
> 
> > The problem comes from this patch which doesn't set the irq in
> > i2c_board_info and so i2c_core sets the IRQ to Host Notify. I think
> > Dmitri already gave you the solution: set the irq to -1 (or -ENOENT)
> > in i2c_board_info in your patch and only forward it to
> > lis3lv02d_init_device() only if it is positive (valid).
> 
> Now I understood that Dmitri means. For this Dell platforms it is OK,
> but we have a problem for device tree platforms. Normally in device tree
> if device does not support something you just do not specify it. But
> with this approach you need to explicitly specify IRQ to -1 in device
> tree. And I think this is really not a clean solution.
> 

No. DT platforms won't have an issue: they don't change anything, and
there will be a new /dev/freefall misc device for the platforms that
don't have the irq set *and* if the device is on a Host Notify capable
adapter, currently only i2c-i801. But given that they are DT and not
ACPI, this won't conflict with dell-smo8800, so there won't be any
errors, just a dangling unused device node.

This approach is IMO the best if you want to have this in the kernel.

Cheers,
Benjamin

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Pali Rohár]

On Wednesday 04 January 2017 11:32:33 Benjamin Tissoires wrote:
> On Jan 04 2017 or thereabouts, Pali Rohár wrote:
> > On Wednesday 04 January 2017 11:13:06 Benjamin Tissoires wrote:
> > > On Jan 04 2017 or thereabouts, Pali Rohár wrote:
> > > > On Wednesday 04 January 2017 10:05:22 Benjamin Tissoires wrote:
> > > > > On Jan 04 2017 or thereabouts, Pali Rohár wrote:
> > > > > > On Tuesday 03 January 2017 12:59:37 Dmitry Torokhov wrote:
> > > > > > > On Tue, Jan 03, 2017 at 09:39:13PM +0100, Pali Rohár wrote:
> > > > > > > > On Tuesday 03 January 2017 21:24:18 Dmitry Torokhov wrote:
> > > > > > > > > On Tue, Jan 03, 2017 at 09:05:51PM +0100, Pali Rohár wrote:
> > > > > > > > > > On Tuesday 03 January 2017 20:48:12 Dmitry Torokhov wrote:
> > > > > > > > > > > On Tue, Jan 03, 2017 at 07:50:17PM +0100, Pali Rohár wrote:
> > > > > > > > > > > > On Tuesday 03 January 2017 19:38:43 Dmitry Torokhov wrote:
> > > > > > > > > > > > > On Tue, Jan 03, 2017 at 10:06:41AM +0100, Benjamin Tissoires
> > > > > > > > > > > > > 
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > On Dec 29 2016 or thereabouts, Pali Rohár wrote:
> > > > > > > > > > > > > > > On Thursday 29 December 2016 22:09:32 Michał Kępień wrote:
> > > > > > > > > > > > > > > > > On Thursday 29 December 2016 14:47:19 Michał Kępień
> > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > On Thursday 29 December 2016 09:29:36 Michał
> > > > > > > > > > > > > > > > > > > Kępień
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > Dell platform team told us that some (DMI
> > > > > > > > > > > > > > > > > > > > > whitelisted) Dell Latitude machines have ST
> > > > > > > > > > > > > > > > > > > > > microelectronics accelerometer at i2c address
> > > > > > > > > > > > > > > > > > > > > 0x29. That i2c address is not specified in
> > > > > > > > > > > > > > > > > > > > > DMI or ACPI, so runtime detection without
> > > > > > > > > > > > > > > > > > > > > whitelist which is below is not possible.
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > Presence of that ST microelectronics
> > > > > > > > > > > > > > > > > > > > > accelerometer is verified by existence of
> > > > > > > > > > > > > > > > > > > > > SMO88xx ACPI device which represent that
> > > > > > > > > > > > > > > > > > > > > accelerometer. Unfortunately without i2c
> > > > > > > > > > > > > > > > > > > > > address.
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > This part of the commit message sounded a bit
> > > > > > > > > > > > > > > > > > > > confusing to me at first because there is
> > > > > > > > > > > > > > > > > > > > already an ACPI driver which handles SMO88xx
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > devices (dell-smo8800).  My understanding is
> > > > > > > > > > > > > > > > > > > > that:
> > > > > > > > > > > > > > > > > > > >   * the purpose of this patch is to expose a
> > > > > > > > > > > > > > > > > > > >   richer interface (as
> > > > > > > > > > > > > > > > > > > >   
> > > > > > > > > > > > > > > > > > > >     provided by lis3lv02d) to these devices on
> > > > > > > > > > > > > > > > > > > >     some machines,
> > > > > > > > > > > > > > > > > > > >   
> > > > > > > > > > > > > > > > > > > >   * on whitelisted machines, dell-smo8800 and
> > > > > > > > > > > > > > > > > > > >   lis3lv02d can work
> > > > > > > > > > > > > > > > > > > >   
> > > > > > > > > > > > > > > > > > > >     simultaneously (even though dell-smo8800
> > > > > > > > > > > > > > > > > > > >     effectively duplicates the work that
> > > > > > > > > > > > > > > > > > > >     lis3lv02d does).
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > No. dell-smo8800 reads from ACPI irq number and
> > > > > > > > > > > > > > > > > > > exports /dev/freefall device which notify
> > > > > > > > > > > > > > > > > > > userspace about falls. lis3lv02d is i2c driver
> > > > > > > > > > > > > > > > > > > which exports axes of accelerometer. Additionaly
> > > > > > > > > > > > > > > > > > > lis3lv02d can export also /dev/freefall if
> > > > > > > > > > > > > > > > > > > registerer of i2c device provides irq number --
> > > > > > > > > > > > > > > > > > > which is not case of this patch.
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > So both drivers are doing different things and
> > > > > > > > > > > > > > > > > > > both are useful.
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > IIRC both dell-smo8800 and lis3lv02d represent
> > > > > > > > > > > > > > > > > > > one HW device (that ST microelectronics
> > > > > > > > > > > > > > > > > > > accelerometer) but due to complicated HW
> > > > > > > > > > > > > > > > > > > abstraction and layers on Dell laptops it is
> > > > > > > > > > > > > > > > > > > handled by two drivers, one ACPI and one i2c.
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > Yes, in ideal world irq number should be passed
> > > > > > > > > > > > > > > > > > > to lis3lv02d driver and that would export whole
> > > > > > > > > > > > > > > > > > > device (with /dev/freefall too), but due to HW
> > > > > > > > > > > > > > > > > > > abstraction it is too much complicated...
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > Why?  AFAICT, all that is required to pass that IRQ
> > > > > > > > > > > > > > > > > > number all the way down to lis3lv02d is to set the
> > > > > > > > > > > > > > > > > > irq field of the struct i2c_board_info you are
> > > > > > > > > > > > > > > > > > passing to i2c_new_device().  And you can extract
> > > > > > > > > > > > > > > > > > that IRQ number e.g. in
> > > > > > > > > > > > > > > > > > check_acpi_smo88xx_device(). However, you would
> > > > > > > > > > > > > > > > > > then need to make sure dell-smo8800 does not
> > > > > > > > > > > > > > > > > > attempt to request the same IRQ on whitelisted
> > > > > > > > > > > > > > > > > > machines.  This got me thinking about a way to
> > > > > > > > > > > > > > > > > > somehow incorporate your changes into dell-smo8800
> > > > > > > > > > > > > > > > > > using Wolfram's bus_notifier suggestion, but I do
> > > > > > > > > > > > > > > > > > not have a working solution for now.  What is
> > > > > > > > > > > > > > > > > > tempting about this approach is that you would not
> > > > > > > > > > > > > > > > > > have to scan the ACPI namespace in search of
> > > > > > > > > > > > > > > > > > SMO88xx devices, because smo8800_add() is
> > > > > > > > > > > > > > > > > > automatically called for them. However, I fear that
> > > > > > > > > > > > > > > > > > the resulting solution may be more complicated than
> > > > > > > > > > > > > > > > > > the one you submitted.
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > Then we need to deal with lot of problems. Order of
> > > > > > > > > > > > > > > > > loading .ko modules is undefined. Binding devices to
> > > > > > > > > > > > > > > > > drivers registered by .ko module is also in "random"
> > > > > > > > > > > > > > > > > order. At any time any of those .ko module can be
> > > > > > > > > > > > > > > > > unloaded or at least device unbind (via sysfs) from
> > > > > > > > > > > > > > > > > driver... And there can be some pathological
> > > > > > > > > > > > > > > > > situation (thanks to adding ACPI layer as Andy
> > > > > > > > > > > > > > > > > pointed) that there will be more SMO88xx devices in
> > > > > > > > > > > > > > > > > ACPI. Plus you can compile kernel with and without
> > > > > > > > > > > > > > > > > those modules and also you can blacklist loading
> > > > > > > > > > > > > > > > > them (so compile time check is not enough). And
> > > > > > > > > > > > > > > > > still some correct message notifier must be used.
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > I think such solution is much much more complicated,
> > > > > > > > > > > > > > > > > there are lot of combinations of kernel configuration
> > > > > > > > > > > > > > > > > and available dell devices...
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > I tried a few more things, but ultimately failed to
> > > > > > > > > > > > > > > > find a nice way to implement this.
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > Another issue popped up, though.  Linus' master branch
> > > > > > > > > > > > > > > > contains a recent commit by Benjamin Tissoires (CC'ed),
> > > > > > > > > > > > > > > > 4d5538f5882a ("i2c: use an IRQ to report Host Notify
> > > > > > > > > > > > > > > > events, not alert") which breaks your patch.  The
> > > > > > > > > > > > > > > > reason for that is that lis3lv02d relies on the i2c
> > > > > > > > > > > > > > > > client's IRQ being 0 to detect that it should not
> > > > > > > > > > > > > > > > create /dev/freefall.
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > >  Benjamin's patch causes the Host Notify IRQ to be
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > assigned to the i2c client your patch creates, thus
> > > > > > > > > > > > > > > > causing lis3lv02d to create /dev/freefall, which in
> > > > > > > > > > > > > > > > turn conflicts with dell-smo8800 which is trying to
> > > > > > > > > > > > > > > > create /dev/freefall itself.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > So 4d5538f5882a is breaking lis3lv02d driver...
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Apologies for that.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > I could easily fix this by adding a kernel API to know
> > > > > > > > > > > > > > whether the provided irq is from Host Notify or if it was
> > > > > > > > > > > > > > coming from an actual declaration. However, I have no idea
> > > > > > > > > > > > > > how many other drivers would require this (hopefully only
> > > > > > > > > > > > > > this one).
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > One other solution would be to reserve the Host Notify IRQ
> > > > > > > > > > > > > > and let the actual drivers that need it to set it, but
> > > > > > > > > > > > > > this was not the best solution according to Dmitri. On my
> > > > > > > > > > > > > > side, I am not entirely against this given that it's a
> > > > > > > > > > > > > > chip feature, so the driver should be able to know that
> > > > > > > > > > > > > > it's available.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Dmitri, Wolfram, Jean, any preferences?
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I read this:
> > > > > > > > > > > > > 
> > > > > > > > > > > > > "IIRC both dell-smo8800 and lis3lv02d represent one HW device
> > > > > > > > > > > > > (that ST microelectronics accelerometer) but due to
> > > > > > > > > > > > > complicated HW abstraction and layers on Dell laptops it is
> > > > > > > > > > > > > handled by two drivers, one ACPI and one i2c."
> > > > > > > > > > > > > 
> > > > > > > > > > > > > and that is the core of the issue. You have 2 drivers
> > > > > > > > > > > > > fighting over the same device. Fix this and it will all
> > > > > > > > > > > > > work.
> > > > > > > > > > > > 
> > > > > > > > > > > > With my current implementation (which I sent in this patch),
> > > > > > > > > > > > they are not fighting.
> > > > > > > > > > > > 
> > > > > > > > > > > > dell-smo8800 exports /dev/freefall (and nothing more) and
> > > > > > > > > > > > lis3lv02d only accelerometer device as lis3lv02d driver does
> > > > > > > > > > > > not get IRQ number in platform data.
> > > > > > > > > > > > 
> > > > > > > > > > > > > As far as I can see hp_accel instantiates lis3lv02d and
> > > > > > > > > > > > > accesses it via ACPI methods, can the same be done for Dell?
> > > > > > > > > > > > 
> > > > > > > > > > > > No, Dell does not have any ACPI methods. And as I wrote in ACPI
> > > > > > > > > > > > or DMI is even not i2c address of device, so it needs to be
> > > > > > > > > > > > specified in code itself.
> > > > > > > > > > > > 
> > > > > > > > > > > > Really there is no other way... :-(
> > > > > > > > > > > 
> > > > > > > > > > > Sure there is:
> > > > > > > > > > > 
> > > > > > > > > > > 1. dell-smo8800 instantiates I2C device as "dell-smo8800-accel".
> > > > > > > > > > > 2. dell-smo8800 provides read/write functions for lis3lv02d that
> > > > > > > > > > > simply forward requests to dell-smo8800-accel i2c client.
> > > > > > > > > > > 3. dell-smo8800 instantiates lis3lv02d instance like hp_accel
> > > > > > > > > > > does.
> > > > > > > > > > 
> > > > > > > > > > Sorry, but I do not understand how you mean it... Why to provides
> > > > > > > > > > new read/write i2c functions which are already implemented by
> > > > > > > > > > i2c-i801 bus and lis3lv02d i2c driver?
> > > > > > > > > 
> > > > > > > > > Because that would allow you to avoid clashes with i2c creating
> > > > > > > > > interrupt mapping for client residing on host-notify-capable
> > > > > > > > > controller.
> > > > > > > > > 
> > > > > > > > > > > Alternatively, can lis3lv02d be tasked to create /dev/freefall?
> > > > > > > > > > 
> > > > > > > > > > If i2c_board_info contains IRQ then lis3lv02d create /dev/freefall
> > > > > > > > > > device.
> > > > > > > > > > 
> > > > > > > > > > But... what is problem with current implementation? Accelerometer
> > > > > > > > > > HW provides two functions:
> > > > > > > > > > 
> > > > > > > > > > 1) 3 axes reports
> > > > > > > > > > 2) Disk freefall detection
> > > > > > > > > > 
> > > > > > > > > > And 1) is handled by i2c driver lis3lv02d and 2) is by
> > > > > > > > > > dell-smo8800. Both functions are independent here.
> > > > > > > > > > 
> > > > > > > > > > I think you just trying to complicate this situation even more to
> > > > > > > > > > be more complicated as currently is.
> > > > > > > > > 
> > > > > > > > > Because this apparently does not work for you, does it?
> > > > > > > > 
> > > > > > > > It is working fine. I do not see any problem.
> > > > > > > > 
> > > > > > > > > In general,
> > > > > > > > > if you want the same hardware be handled by 2 different drivers you
> > > > > > > > > are going to have bad time.
> > > > > > > > 
> > > > > > > > Yes, but in this case half of device is ACPI based and other half i2c 
> > > > > > > > based. This is problem of ACPI and Dell design.
> > > > > > > > 
> > > > > > > > > It seems to be that /dev/freefall in dell-smo8800 and lis3lv02d are
> > > > > > > > > the same, right?
> > > > > > > > 
> > > > > > > > Yes. I understand that clean solution is to have one driver which 
> > > > > > > > provides everything.
> > > > > > > > 
> > > > > > > > But because half of data are ACPI and half i2c, you still needs to 
> > > > > > > > create two drivers (one ACPI and one i2c). You can put both drivers into 
> > > > > > > > one .ko module, but still these will be two drivers due to how ACPI and 
> > > > > > > > i2c linux abstractions are different.
> > > > > > > > 
> > > > > > > > > So, instead of having 2 drivers split the
> > > > > > > > > functionality, can you forego registering smo8800 ACPI driver on
> > > > > > > > > your whitelisted boxes and instead instantiate full i2c client
> > > > > > > > > device with properly assigned both address and IRQ and let lis3lv02d
> > > > > > > > > handle it (providing both accelerometer data and /dev/freefall)?
> > > > > > > > 
> > > > > > > > With Michał we already discussed about it, see emails. Basically you can 
> > > > > > > > enable/disable kernel modules at compile time or blacklist at runtime 
> > > > > > > > (or even chose what will be compiled into vmlinux and what as external 
> > > > > > > > .ko module).
> > > > > > > 
> > > > > > > This can be solved with a bit of Kconfig/IS_ENABLED() code.
> > > > > > > 
> > > > > > > > Some distributions blacklist i2c-i801.ko module... And 
> > > > > > > 
> > > > > > > Any particular reason for that?
> > > > > > > 
> > > > > > > > there can be also problem with initialization of i2c-i801 driver (fix is 
> > > > > > > > in commit a7ae81952cda, but does not have to work at every time!). So 
> > > > > > > > that move on whitelisted machines can potentially cause disappearance of 
> > > > > > > > /dev/freefall and users will not have hdd protection which is currently 
> > > > > > > > working.
> > > > > > > 
> > > > > > > Well, I gave you 2 possible solutions (roll your own i2c read/write,
> > > > > > > forward them to i2c client) or have faith in your implementation and let
> > > > > > > lis3lv02d handle it.
> > > > > > > 
> > > > > > > The 3rd one is to possibly add a flag to disable host notify to IRQ
> > > > > > > mapping for given client (if Wolfram/Jean OK with it).
> > > > > > > 
> > > > > > > Oh, the 4th one: change the irq in lis3lv02d.h to be "int" and change
> > > > > > > the check in lis3lv02d.c to be "lis->irq <= 0" and instantiate your
> > > > > > > i2c_client with board_info->irq = -1.
> > > > > > > 
> > > > > > > Pick whichever you prefer.
> > > > > > > 
> > > > > > > By the way, what do you need accelerometer for on these devices? They
> > > > > > > don't appear to be tablets that could use one... 
> > > > > > 
> > > > > > Ah, you are talking about problem that after 4d5538f5882a lis3lv02d will
> > > > > > not work... I thought that discussion is about different mechanism how
> > > > > > to implement bus registration notification to smo8800 driver (or
> > > > > > different solution to not have registration in i801).
> > > > > > 
> > > > > 
> > > > > Just because I am not sure I got everything right, could you confirm
> > > > > that:
> > > > > - in the current upstream tree, the dell-smo8800 driver is now broken
> > > > >   after 4d5538f5882a (i2c: use an IRQ to report Host Notify events, not
> > > > >   alert)
> > > > 
> > > > No, dell-smo8800 it is working fine. It is fully independent from i2c
> > > > and lis3lv02d. It is pure ACPI driver which does not share anything with
> > > > i2c.
> > > > 
> > > > > - this series adds an extra lis3lv02d on some machines and you have
> > > > >   problem fighting for the irq (but this is not upstream yet).
> > > > 
> > > > Yes, this series (not merged yet) adds extra lis3lv02d device but is not
> > > > working because of 4d5538f5882a.
> > > > 
> > > > > The extra lis3lv02d node is added from dell-smo8800
> > > > 
> > > > No, dell-smo8800 does not add new node in this patch.
> > > > 
> > > > > If the first point is not correct (by default, dell-smo8800 will not be
> > > > > loaded at the same time than lis3lv02d), then it's a design issue with
> > > > > the interactions between those 2 drivers.
> > > > 
> > > > No, there is no interactions between these two drivers (dell-smo8800 and
> > > > lis3lv02d). dell-smo8800 is pure ACPI driver and exports just
> > > > /dev/freefall device based on IRQ (and nothing more).
> > > > 
> > > > And lis3lv02d in *current* configuration in this patch exports only
> > > > accelerometer input device, not /dev/freefall. It does not use IRQ.
> > > > (Just there is problem with 4d5538f5882a which tells lis3lv02d IRQ
> > > > number which is not freefall report, therefore lis3lv02d does not work).
> > > > 
> > > > To make it clear, ST Accelerometer provides two operations:
> > > > * report free fall
> > > > * report 3 axes
> > > > 
> > > > Free fall is reported by IRQ, state of 3 axes via i2c bus. Free fall IRQ
> > > > is handled by dell-smo8800, state of 3 axes via i2c lis3lv02d driver.
> > > > 
> > > > lis3lv02d can handle also free fall IRQ is platform i2c data provides
> > > > IRQ number for it -- but this is not case in our Dell configuration. But
> > > > commit 4d5538f5882a inject some IRQ number to lis3lv02d driver which is
> > > > not free fall detection and so is breaking lis3lv02 driver. In our Dell
> > > > configuration (by this patch) there should be no IRQ number.
> > > > 
> > > > It is clear now?
> > > 
> > > I think I am starting to understand the problem.
> > > 
> > > Currently (upstream tree), 4d5538f5882a doesn't break anything.
> > 
> > I cannot prove it... lis3lv02d i2c driver itself uses this IRQ logic
> > (missing = no freefall) and there could be already hardware/boards which
> > register lis3lv02d i2c device without IRQ number. And definitions could
> > be also in device tree and so outside of kernel sources...
> > 
> > So there can be potentially break. But at least not case of Dell.
> > 
> > > On the
> > > mentioned Dell platforms, the dell-smo8800 gets loaded and provides
> > > /dev/freefall. lis3lv02d is not loaded so everything just works.
> > 
> > Yes.
> > 
> > > The problem comes from this patch which doesn't set the irq in
> > > i2c_board_info and so i2c_core sets the IRQ to Host Notify. I think
> > > Dmitri already gave you the solution: set the irq to -1 (or -ENOENT)
> > > in i2c_board_info in your patch and only forward it to
> > > lis3lv02d_init_device() only if it is positive (valid).
> > 
> > Now I understood that Dmitri means. For this Dell platforms it is OK,
> > but we have a problem for device tree platforms. Normally in device tree
> > if device does not support something you just do not specify it. But
> > with this approach you need to explicitly specify IRQ to -1 in device
> > tree. And I think this is really not a clean solution.
> > 

Here I was talking about other platforms/devices (not this Dell one).

> No. DT platforms won't have an issue: they don't change anything, and
> there will be a new /dev/freefall misc device for the platforms that

And this is wrong! There should not be any /dev/freefall device
connected with signal host notify. /dev/freefall is for hardware which
supports free fall hdd detection.

> don't have the irq set *and* if the device is on a Host Notify capable
> adapter, currently only i2c-i801.

I understood, but in future more bus drivers could support host notify.
This is basically incorrect if we use one property for two different
things (host notify and hdd free fall).

For me it looks like that we should separate these two things into two
IRQ properties. It is really wrong design if one property is used for
two different things.

> But given that they are DT and not
> ACPI, this won't conflict with dell-smo8800, so there won't be any
> errors, just a dangling unused device node.

Yes, for upcoming Dell in this patch (with IRQ -1) it is not a problem.

> This approach is IMO the best if you want to have this in the kernel.
> 
> Cheers,
> Benjamin

-- 
Pali Rohár
pali.rohar@gmail.com

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Pali Rohár]

On Wednesday 04 January 2017 12:22:23 Pali Rohár wrote:
> On Wednesday 04 January 2017 11:32:33 Benjamin Tissoires wrote:
> > On Jan 04 2017 or thereabouts, Pali Rohár wrote:
> > > On Wednesday 04 January 2017 11:13:06 Benjamin Tissoires wrote:
> > > > On Jan 04 2017 or thereabouts, Pali Rohár wrote:
> > > > > On Wednesday 04 January 2017 10:05:22 Benjamin Tissoires wrote:
> > > > > > On Jan 04 2017 or thereabouts, Pali Rohár wrote:
> > > > > > > On Tuesday 03 January 2017 12:59:37 Dmitry Torokhov wrote:
> > > > > > > > On Tue, Jan 03, 2017 at 09:39:13PM +0100, Pali Rohár wrote:
> > > > > > > > > On Tuesday 03 January 2017 21:24:18 Dmitry Torokhov wrote:
> > > > > > > > > > On Tue, Jan 03, 2017 at 09:05:51PM +0100, Pali Rohár wrote:
> > > > > > > > > > > On Tuesday 03 January 2017 20:48:12 Dmitry Torokhov wrote:
> > > > > > > > > > > > On Tue, Jan 03, 2017 at 07:50:17PM +0100, Pali Rohár wrote:
> > > > > > > > > > > > > On Tuesday 03 January 2017 19:38:43 Dmitry Torokhov wrote:
> > > > > > > > > > > > > > On Tue, Jan 03, 2017 at 10:06:41AM +0100, Benjamin Tissoires
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > On Dec 29 2016 or thereabouts, Pali Rohár wrote:
> > > > > > > > > > > > > > > > On Thursday 29 December 2016 22:09:32 Michał Kępień wrote:
> > > > > > > > > > > > > > > > > > On Thursday 29 December 2016 14:47:19 Michał Kępień
> > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > On Thursday 29 December 2016 09:29:36 Michał
> > > > > > > > > > > > > > > > > > > > Kępień
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > Dell platform team told us that some (DMI
> > > > > > > > > > > > > > > > > > > > > > whitelisted) Dell Latitude machines have ST
> > > > > > > > > > > > > > > > > > > > > > microelectronics accelerometer at i2c address
> > > > > > > > > > > > > > > > > > > > > > 0x29. That i2c address is not specified in
> > > > > > > > > > > > > > > > > > > > > > DMI or ACPI, so runtime detection without
> > > > > > > > > > > > > > > > > > > > > > whitelist which is below is not possible.
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > Presence of that ST microelectronics
> > > > > > > > > > > > > > > > > > > > > > accelerometer is verified by existence of
> > > > > > > > > > > > > > > > > > > > > > SMO88xx ACPI device which represent that
> > > > > > > > > > > > > > > > > > > > > > accelerometer. Unfortunately without i2c
> > > > > > > > > > > > > > > > > > > > > > address.
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > This part of the commit message sounded a bit
> > > > > > > > > > > > > > > > > > > > > confusing to me at first because there is
> > > > > > > > > > > > > > > > > > > > > already an ACPI driver which handles SMO88xx
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > devices (dell-smo8800).  My understanding is
> > > > > > > > > > > > > > > > > > > > > that:
> > > > > > > > > > > > > > > > > > > > >   * the purpose of this patch is to expose a
> > > > > > > > > > > > > > > > > > > > >   richer interface (as
> > > > > > > > > > > > > > > > > > > > >   
> > > > > > > > > > > > > > > > > > > > >     provided by lis3lv02d) to these devices on
> > > > > > > > > > > > > > > > > > > > >     some machines,
> > > > > > > > > > > > > > > > > > > > >   
> > > > > > > > > > > > > > > > > > > > >   * on whitelisted machines, dell-smo8800 and
> > > > > > > > > > > > > > > > > > > > >   lis3lv02d can work
> > > > > > > > > > > > > > > > > > > > >   
> > > > > > > > > > > > > > > > > > > > >     simultaneously (even though dell-smo8800
> > > > > > > > > > > > > > > > > > > > >     effectively duplicates the work that
> > > > > > > > > > > > > > > > > > > > >     lis3lv02d does).
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > No. dell-smo8800 reads from ACPI irq number and
> > > > > > > > > > > > > > > > > > > > exports /dev/freefall device which notify
> > > > > > > > > > > > > > > > > > > > userspace about falls. lis3lv02d is i2c driver
> > > > > > > > > > > > > > > > > > > > which exports axes of accelerometer. Additionaly
> > > > > > > > > > > > > > > > > > > > lis3lv02d can export also /dev/freefall if
> > > > > > > > > > > > > > > > > > > > registerer of i2c device provides irq number --
> > > > > > > > > > > > > > > > > > > > which is not case of this patch.
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > So both drivers are doing different things and
> > > > > > > > > > > > > > > > > > > > both are useful.
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > IIRC both dell-smo8800 and lis3lv02d represent
> > > > > > > > > > > > > > > > > > > > one HW device (that ST microelectronics
> > > > > > > > > > > > > > > > > > > > accelerometer) but due to complicated HW
> > > > > > > > > > > > > > > > > > > > abstraction and layers on Dell laptops it is
> > > > > > > > > > > > > > > > > > > > handled by two drivers, one ACPI and one i2c.
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > Yes, in ideal world irq number should be passed
> > > > > > > > > > > > > > > > > > > > to lis3lv02d driver and that would export whole
> > > > > > > > > > > > > > > > > > > > device (with /dev/freefall too), but due to HW
> > > > > > > > > > > > > > > > > > > > abstraction it is too much complicated...
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > Why?  AFAICT, all that is required to pass that IRQ
> > > > > > > > > > > > > > > > > > > number all the way down to lis3lv02d is to set the
> > > > > > > > > > > > > > > > > > > irq field of the struct i2c_board_info you are
> > > > > > > > > > > > > > > > > > > passing to i2c_new_device().  And you can extract
> > > > > > > > > > > > > > > > > > > that IRQ number e.g. in
> > > > > > > > > > > > > > > > > > > check_acpi_smo88xx_device(). However, you would
> > > > > > > > > > > > > > > > > > > then need to make sure dell-smo8800 does not
> > > > > > > > > > > > > > > > > > > attempt to request the same IRQ on whitelisted
> > > > > > > > > > > > > > > > > > > machines.  This got me thinking about a way to
> > > > > > > > > > > > > > > > > > > somehow incorporate your changes into dell-smo8800
> > > > > > > > > > > > > > > > > > > using Wolfram's bus_notifier suggestion, but I do
> > > > > > > > > > > > > > > > > > > not have a working solution for now.  What is
> > > > > > > > > > > > > > > > > > > tempting about this approach is that you would not
> > > > > > > > > > > > > > > > > > > have to scan the ACPI namespace in search of
> > > > > > > > > > > > > > > > > > > SMO88xx devices, because smo8800_add() is
> > > > > > > > > > > > > > > > > > > automatically called for them. However, I fear that
> > > > > > > > > > > > > > > > > > > the resulting solution may be more complicated than
> > > > > > > > > > > > > > > > > > > the one you submitted.
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > Then we need to deal with lot of problems. Order of
> > > > > > > > > > > > > > > > > > loading .ko modules is undefined. Binding devices to
> > > > > > > > > > > > > > > > > > drivers registered by .ko module is also in "random"
> > > > > > > > > > > > > > > > > > order. At any time any of those .ko module can be
> > > > > > > > > > > > > > > > > > unloaded or at least device unbind (via sysfs) from
> > > > > > > > > > > > > > > > > > driver... And there can be some pathological
> > > > > > > > > > > > > > > > > > situation (thanks to adding ACPI layer as Andy
> > > > > > > > > > > > > > > > > > pointed) that there will be more SMO88xx devices in
> > > > > > > > > > > > > > > > > > ACPI. Plus you can compile kernel with and without
> > > > > > > > > > > > > > > > > > those modules and also you can blacklist loading
> > > > > > > > > > > > > > > > > > them (so compile time check is not enough). And
> > > > > > > > > > > > > > > > > > still some correct message notifier must be used.
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > I think such solution is much much more complicated,
> > > > > > > > > > > > > > > > > > there are lot of combinations of kernel configuration
> > > > > > > > > > > > > > > > > > and available dell devices...
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > I tried a few more things, but ultimately failed to
> > > > > > > > > > > > > > > > > find a nice way to implement this.
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > Another issue popped up, though.  Linus' master branch
> > > > > > > > > > > > > > > > > contains a recent commit by Benjamin Tissoires (CC'ed),
> > > > > > > > > > > > > > > > > 4d5538f5882a ("i2c: use an IRQ to report Host Notify
> > > > > > > > > > > > > > > > > events, not alert") which breaks your patch.  The
> > > > > > > > > > > > > > > > > reason for that is that lis3lv02d relies on the i2c
> > > > > > > > > > > > > > > > > client's IRQ being 0 to detect that it should not
> > > > > > > > > > > > > > > > > create /dev/freefall.
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > >  Benjamin's patch causes the Host Notify IRQ to be
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > assigned to the i2c client your patch creates, thus
> > > > > > > > > > > > > > > > > causing lis3lv02d to create /dev/freefall, which in
> > > > > > > > > > > > > > > > > turn conflicts with dell-smo8800 which is trying to
> > > > > > > > > > > > > > > > > create /dev/freefall itself.
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > So 4d5538f5882a is breaking lis3lv02d driver...
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Apologies for that.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > I could easily fix this by adding a kernel API to know
> > > > > > > > > > > > > > > whether the provided irq is from Host Notify or if it was
> > > > > > > > > > > > > > > coming from an actual declaration. However, I have no idea
> > > > > > > > > > > > > > > how many other drivers would require this (hopefully only
> > > > > > > > > > > > > > > this one).
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > One other solution would be to reserve the Host Notify IRQ
> > > > > > > > > > > > > > > and let the actual drivers that need it to set it, but
> > > > > > > > > > > > > > > this was not the best solution according to Dmitri. On my
> > > > > > > > > > > > > > > side, I am not entirely against this given that it's a
> > > > > > > > > > > > > > > chip feature, so the driver should be able to know that
> > > > > > > > > > > > > > > it's available.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Dmitri, Wolfram, Jean, any preferences?
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > I read this:
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > "IIRC both dell-smo8800 and lis3lv02d represent one HW device
> > > > > > > > > > > > > > (that ST microelectronics accelerometer) but due to
> > > > > > > > > > > > > > complicated HW abstraction and layers on Dell laptops it is
> > > > > > > > > > > > > > handled by two drivers, one ACPI and one i2c."
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > and that is the core of the issue. You have 2 drivers
> > > > > > > > > > > > > > fighting over the same device. Fix this and it will all
> > > > > > > > > > > > > > work.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > With my current implementation (which I sent in this patch),
> > > > > > > > > > > > > they are not fighting.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > dell-smo8800 exports /dev/freefall (and nothing more) and
> > > > > > > > > > > > > lis3lv02d only accelerometer device as lis3lv02d driver does
> > > > > > > > > > > > > not get IRQ number in platform data.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > > As far as I can see hp_accel instantiates lis3lv02d and
> > > > > > > > > > > > > > accesses it via ACPI methods, can the same be done for Dell?
> > > > > > > > > > > > > 
> > > > > > > > > > > > > No, Dell does not have any ACPI methods. And as I wrote in ACPI
> > > > > > > > > > > > > or DMI is even not i2c address of device, so it needs to be
> > > > > > > > > > > > > specified in code itself.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Really there is no other way... :-(
> > > > > > > > > > > > 
> > > > > > > > > > > > Sure there is:
> > > > > > > > > > > > 
> > > > > > > > > > > > 1. dell-smo8800 instantiates I2C device as "dell-smo8800-accel".
> > > > > > > > > > > > 2. dell-smo8800 provides read/write functions for lis3lv02d that
> > > > > > > > > > > > simply forward requests to dell-smo8800-accel i2c client.
> > > > > > > > > > > > 3. dell-smo8800 instantiates lis3lv02d instance like hp_accel
> > > > > > > > > > > > does.
> > > > > > > > > > > 
> > > > > > > > > > > Sorry, but I do not understand how you mean it... Why to provides
> > > > > > > > > > > new read/write i2c functions which are already implemented by
> > > > > > > > > > > i2c-i801 bus and lis3lv02d i2c driver?
> > > > > > > > > > 
> > > > > > > > > > Because that would allow you to avoid clashes with i2c creating
> > > > > > > > > > interrupt mapping for client residing on host-notify-capable
> > > > > > > > > > controller.
> > > > > > > > > > 
> > > > > > > > > > > > Alternatively, can lis3lv02d be tasked to create /dev/freefall?
> > > > > > > > > > > 
> > > > > > > > > > > If i2c_board_info contains IRQ then lis3lv02d create /dev/freefall
> > > > > > > > > > > device.
> > > > > > > > > > > 
> > > > > > > > > > > But... what is problem with current implementation? Accelerometer
> > > > > > > > > > > HW provides two functions:
> > > > > > > > > > > 
> > > > > > > > > > > 1) 3 axes reports
> > > > > > > > > > > 2) Disk freefall detection
> > > > > > > > > > > 
> > > > > > > > > > > And 1) is handled by i2c driver lis3lv02d and 2) is by
> > > > > > > > > > > dell-smo8800. Both functions are independent here.
> > > > > > > > > > > 
> > > > > > > > > > > I think you just trying to complicate this situation even more to
> > > > > > > > > > > be more complicated as currently is.
> > > > > > > > > > 
> > > > > > > > > > Because this apparently does not work for you, does it?
> > > > > > > > > 
> > > > > > > > > It is working fine. I do not see any problem.
> > > > > > > > > 
> > > > > > > > > > In general,
> > > > > > > > > > if you want the same hardware be handled by 2 different drivers you
> > > > > > > > > > are going to have bad time.
> > > > > > > > > 
> > > > > > > > > Yes, but in this case half of device is ACPI based and other half i2c 
> > > > > > > > > based. This is problem of ACPI and Dell design.
> > > > > > > > > 
> > > > > > > > > > It seems to be that /dev/freefall in dell-smo8800 and lis3lv02d are
> > > > > > > > > > the same, right?
> > > > > > > > > 
> > > > > > > > > Yes. I understand that clean solution is to have one driver which 
> > > > > > > > > provides everything.
> > > > > > > > > 
> > > > > > > > > But because half of data are ACPI and half i2c, you still needs to 
> > > > > > > > > create two drivers (one ACPI and one i2c). You can put both drivers into 
> > > > > > > > > one .ko module, but still these will be two drivers due to how ACPI and 
> > > > > > > > > i2c linux abstractions are different.
> > > > > > > > > 
> > > > > > > > > > So, instead of having 2 drivers split the
> > > > > > > > > > functionality, can you forego registering smo8800 ACPI driver on
> > > > > > > > > > your whitelisted boxes and instead instantiate full i2c client
> > > > > > > > > > device with properly assigned both address and IRQ and let lis3lv02d
> > > > > > > > > > handle it (providing both accelerometer data and /dev/freefall)?
> > > > > > > > > 
> > > > > > > > > With Michał we already discussed about it, see emails. Basically you can 
> > > > > > > > > enable/disable kernel modules at compile time or blacklist at runtime 
> > > > > > > > > (or even chose what will be compiled into vmlinux and what as external 
> > > > > > > > > .ko module).
> > > > > > > > 
> > > > > > > > This can be solved with a bit of Kconfig/IS_ENABLED() code.
> > > > > > > > 
> > > > > > > > > Some distributions blacklist i2c-i801.ko module... And 
> > > > > > > > 
> > > > > > > > Any particular reason for that?
> > > > > > > > 
> > > > > > > > > there can be also problem with initialization of i2c-i801 driver (fix is 
> > > > > > > > > in commit a7ae81952cda, but does not have to work at every time!). So 
> > > > > > > > > that move on whitelisted machines can potentially cause disappearance of 
> > > > > > > > > /dev/freefall and users will not have hdd protection which is currently 
> > > > > > > > > working.
> > > > > > > > 
> > > > > > > > Well, I gave you 2 possible solutions (roll your own i2c read/write,
> > > > > > > > forward them to i2c client) or have faith in your implementation and let
> > > > > > > > lis3lv02d handle it.
> > > > > > > > 
> > > > > > > > The 3rd one is to possibly add a flag to disable host notify to IRQ
> > > > > > > > mapping for given client (if Wolfram/Jean OK with it).
> > > > > > > > 
> > > > > > > > Oh, the 4th one: change the irq in lis3lv02d.h to be "int" and change
> > > > > > > > the check in lis3lv02d.c to be "lis->irq <= 0" and instantiate your
> > > > > > > > i2c_client with board_info->irq = -1.
> > > > > > > > 
> > > > > > > > Pick whichever you prefer.
> > > > > > > > 
> > > > > > > > By the way, what do you need accelerometer for on these devices? They
> > > > > > > > don't appear to be tablets that could use one... 
> > > > > > > 
> > > > > > > Ah, you are talking about problem that after 4d5538f5882a lis3lv02d will
> > > > > > > not work... I thought that discussion is about different mechanism how
> > > > > > > to implement bus registration notification to smo8800 driver (or
> > > > > > > different solution to not have registration in i801).
> > > > > > > 
> > > > > > 
> > > > > > Just because I am not sure I got everything right, could you confirm
> > > > > > that:
> > > > > > - in the current upstream tree, the dell-smo8800 driver is now broken
> > > > > >   after 4d5538f5882a (i2c: use an IRQ to report Host Notify events, not
> > > > > >   alert)
> > > > > 
> > > > > No, dell-smo8800 it is working fine. It is fully independent from i2c
> > > > > and lis3lv02d. It is pure ACPI driver which does not share anything with
> > > > > i2c.
> > > > > 
> > > > > > - this series adds an extra lis3lv02d on some machines and you have
> > > > > >   problem fighting for the irq (but this is not upstream yet).
> > > > > 
> > > > > Yes, this series (not merged yet) adds extra lis3lv02d device but is not
> > > > > working because of 4d5538f5882a.
> > > > > 
> > > > > > The extra lis3lv02d node is added from dell-smo8800
> > > > > 
> > > > > No, dell-smo8800 does not add new node in this patch.
> > > > > 
> > > > > > If the first point is not correct (by default, dell-smo8800 will not be
> > > > > > loaded at the same time than lis3lv02d), then it's a design issue with
> > > > > > the interactions between those 2 drivers.
> > > > > 
> > > > > No, there is no interactions between these two drivers (dell-smo8800 and
> > > > > lis3lv02d). dell-smo8800 is pure ACPI driver and exports just
> > > > > /dev/freefall device based on IRQ (and nothing more).
> > > > > 
> > > > > And lis3lv02d in *current* configuration in this patch exports only
> > > > > accelerometer input device, not /dev/freefall. It does not use IRQ.
> > > > > (Just there is problem with 4d5538f5882a which tells lis3lv02d IRQ
> > > > > number which is not freefall report, therefore lis3lv02d does not work).
> > > > > 
> > > > > To make it clear, ST Accelerometer provides two operations:
> > > > > * report free fall
> > > > > * report 3 axes
> > > > > 
> > > > > Free fall is reported by IRQ, state of 3 axes via i2c bus. Free fall IRQ
> > > > > is handled by dell-smo8800, state of 3 axes via i2c lis3lv02d driver.
> > > > > 
> > > > > lis3lv02d can handle also free fall IRQ is platform i2c data provides
> > > > > IRQ number for it -- but this is not case in our Dell configuration. But
> > > > > commit 4d5538f5882a inject some IRQ number to lis3lv02d driver which is
> > > > > not free fall detection and so is breaking lis3lv02 driver. In our Dell
> > > > > configuration (by this patch) there should be no IRQ number.
> > > > > 
> > > > > It is clear now?
> > > > 
> > > > I think I am starting to understand the problem.
> > > > 
> > > > Currently (upstream tree), 4d5538f5882a doesn't break anything.
> > > 
> > > I cannot prove it... lis3lv02d i2c driver itself uses this IRQ logic
> > > (missing = no freefall) and there could be already hardware/boards which
> > > register lis3lv02d i2c device without IRQ number. And definitions could
> > > be also in device tree and so outside of kernel sources...
> > > 
> > > So there can be potentially break. But at least not case of Dell.
> > > 
> > > > On the
> > > > mentioned Dell platforms, the dell-smo8800 gets loaded and provides
> > > > /dev/freefall. lis3lv02d is not loaded so everything just works.
> > > 
> > > Yes.
> > > 
> > > > The problem comes from this patch which doesn't set the irq in
> > > > i2c_board_info and so i2c_core sets the IRQ to Host Notify. I think
> > > > Dmitri already gave you the solution: set the irq to -1 (or -ENOENT)
> > > > in i2c_board_info in your patch and only forward it to
> > > > lis3lv02d_init_device() only if it is positive (valid).
> > > 
> > > Now I understood that Dmitri means. For this Dell platforms it is OK,
> > > but we have a problem for device tree platforms. Normally in device tree
> > > if device does not support something you just do not specify it. But
> > > with this approach you need to explicitly specify IRQ to -1 in device
> > > tree. And I think this is really not a clean solution.
> > > 
> 
> Here I was talking about other platforms/devices (not this Dell one).
> 
> > No. DT platforms won't have an issue: they don't change anything, and
> > there will be a new /dev/freefall misc device for the platforms that
> 
> And this is wrong! There should not be any /dev/freefall device
> connected with signal host notify. /dev/freefall is for hardware which
> supports free fall hdd detection.
> 
> > don't have the irq set *and* if the device is on a Host Notify capable
> > adapter, currently only i2c-i801.
> 
> I understood, but in future more bus drivers could support host notify.

This is really fragile. lis3lv02d will empty IRQ (0) will work on some
i2c buses and on some not. I would really expect that i2c driver
(lis3lv02d) will work in same way with any i2c bus driver. And not that
on i801 will acts differently as on e.g. omap3 i2c bus.

> This is basically incorrect if we use one property for two different
> things (host notify and hdd free fall).
> 
> For me it looks like that we should separate these two things into two
> IRQ properties. It is really wrong design if one property is used for
> two different things.
> 
> > But given that they are DT and not
> > ACPI, this won't conflict with dell-smo8800, so there won't be any
> > errors, just a dangling unused device node.
> 
> Yes, for upcoming Dell in this patch (with IRQ -1) it is not a problem.
> 
> > This approach is IMO the best if you want to have this in the kernel.
> > 
> > Cheers,
> > Benjamin
> 

-- 
Pali Rohár
pali.rohar@gmail.com

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Benjamin Tissoires]

On Jan 04 2017 or thereabouts, Pali Rohár wrote:
> On Wednesday 04 January 2017 12:22:23 Pali Rohár wrote:
> > On Wednesday 04 January 2017 11:32:33 Benjamin Tissoires wrote:
> > > On Jan 04 2017 or thereabouts, Pali Rohár wrote:
> > > > On Wednesday 04 January 2017 11:13:06 Benjamin Tissoires wrote:
> > > > > On Jan 04 2017 or thereabouts, Pali Rohár wrote:
> > > > > > On Wednesday 04 January 2017 10:05:22 Benjamin Tissoires wrote:
> > > > > > > On Jan 04 2017 or thereabouts, Pali Rohár wrote:
> > > > > > > > On Tuesday 03 January 2017 12:59:37 Dmitry Torokhov wrote:
> > > > > > > > > On Tue, Jan 03, 2017 at 09:39:13PM +0100, Pali Rohár wrote:
> > > > > > > > > > On Tuesday 03 January 2017 21:24:18 Dmitry Torokhov wrote:
> > > > > > > > > > > On Tue, Jan 03, 2017 at 09:05:51PM +0100, Pali Rohár wrote:
> > > > > > > > > > > > On Tuesday 03 January 2017 20:48:12 Dmitry Torokhov wrote:
> > > > > > > > > > > > > On Tue, Jan 03, 2017 at 07:50:17PM +0100, Pali Rohár wrote:
> > > > > > > > > > > > > > On Tuesday 03 January 2017 19:38:43 Dmitry Torokhov wrote:
> > > > > > > > > > > > > > > On Tue, Jan 03, 2017 at 10:06:41AM +0100, Benjamin Tissoires
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > On Dec 29 2016 or thereabouts, Pali Rohár wrote:
> > > > > > > > > > > > > > > > > On Thursday 29 December 2016 22:09:32 Michał Kępień wrote:
> > > > > > > > > > > > > > > > > > > On Thursday 29 December 2016 14:47:19 Michał Kępień
> > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > On Thursday 29 December 2016 09:29:36 Michał
> > > > > > > > > > > > > > > > > > > > > Kępień
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > Dell platform team told us that some (DMI
> > > > > > > > > > > > > > > > > > > > > > > whitelisted) Dell Latitude machines have ST
> > > > > > > > > > > > > > > > > > > > > > > microelectronics accelerometer at i2c address
> > > > > > > > > > > > > > > > > > > > > > > 0x29. That i2c address is not specified in
> > > > > > > > > > > > > > > > > > > > > > > DMI or ACPI, so runtime detection without
> > > > > > > > > > > > > > > > > > > > > > > whitelist which is below is not possible.
> > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > Presence of that ST microelectronics
> > > > > > > > > > > > > > > > > > > > > > > accelerometer is verified by existence of
> > > > > > > > > > > > > > > > > > > > > > > SMO88xx ACPI device which represent that
> > > > > > > > > > > > > > > > > > > > > > > accelerometer. Unfortunately without i2c
> > > > > > > > > > > > > > > > > > > > > > > address.
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > This part of the commit message sounded a bit
> > > > > > > > > > > > > > > > > > > > > > confusing to me at first because there is
> > > > > > > > > > > > > > > > > > > > > > already an ACPI driver which handles SMO88xx
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > devices (dell-smo8800).  My understanding is
> > > > > > > > > > > > > > > > > > > > > > that:
> > > > > > > > > > > > > > > > > > > > > >   * the purpose of this patch is to expose a
> > > > > > > > > > > > > > > > > > > > > >   richer interface (as
> > > > > > > > > > > > > > > > > > > > > >   
> > > > > > > > > > > > > > > > > > > > > >     provided by lis3lv02d) to these devices on
> > > > > > > > > > > > > > > > > > > > > >     some machines,
> > > > > > > > > > > > > > > > > > > > > >   
> > > > > > > > > > > > > > > > > > > > > >   * on whitelisted machines, dell-smo8800 and
> > > > > > > > > > > > > > > > > > > > > >   lis3lv02d can work
> > > > > > > > > > > > > > > > > > > > > >   
> > > > > > > > > > > > > > > > > > > > > >     simultaneously (even though dell-smo8800
> > > > > > > > > > > > > > > > > > > > > >     effectively duplicates the work that
> > > > > > > > > > > > > > > > > > > > > >     lis3lv02d does).
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > No. dell-smo8800 reads from ACPI irq number and
> > > > > > > > > > > > > > > > > > > > > exports /dev/freefall device which notify
> > > > > > > > > > > > > > > > > > > > > userspace about falls. lis3lv02d is i2c driver
> > > > > > > > > > > > > > > > > > > > > which exports axes of accelerometer. Additionaly
> > > > > > > > > > > > > > > > > > > > > lis3lv02d can export also /dev/freefall if
> > > > > > > > > > > > > > > > > > > > > registerer of i2c device provides irq number --
> > > > > > > > > > > > > > > > > > > > > which is not case of this patch.
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > So both drivers are doing different things and
> > > > > > > > > > > > > > > > > > > > > both are useful.
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > IIRC both dell-smo8800 and lis3lv02d represent
> > > > > > > > > > > > > > > > > > > > > one HW device (that ST microelectronics
> > > > > > > > > > > > > > > > > > > > > accelerometer) but due to complicated HW
> > > > > > > > > > > > > > > > > > > > > abstraction and layers on Dell laptops it is
> > > > > > > > > > > > > > > > > > > > > handled by two drivers, one ACPI and one i2c.
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > Yes, in ideal world irq number should be passed
> > > > > > > > > > > > > > > > > > > > > to lis3lv02d driver and that would export whole
> > > > > > > > > > > > > > > > > > > > > device (with /dev/freefall too), but due to HW
> > > > > > > > > > > > > > > > > > > > > abstraction it is too much complicated...
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > Why?  AFAICT, all that is required to pass that IRQ
> > > > > > > > > > > > > > > > > > > > number all the way down to lis3lv02d is to set the
> > > > > > > > > > > > > > > > > > > > irq field of the struct i2c_board_info you are
> > > > > > > > > > > > > > > > > > > > passing to i2c_new_device().  And you can extract
> > > > > > > > > > > > > > > > > > > > that IRQ number e.g. in
> > > > > > > > > > > > > > > > > > > > check_acpi_smo88xx_device(). However, you would
> > > > > > > > > > > > > > > > > > > > then need to make sure dell-smo8800 does not
> > > > > > > > > > > > > > > > > > > > attempt to request the same IRQ on whitelisted
> > > > > > > > > > > > > > > > > > > > machines.  This got me thinking about a way to
> > > > > > > > > > > > > > > > > > > > somehow incorporate your changes into dell-smo8800
> > > > > > > > > > > > > > > > > > > > using Wolfram's bus_notifier suggestion, but I do
> > > > > > > > > > > > > > > > > > > > not have a working solution for now.  What is
> > > > > > > > > > > > > > > > > > > > tempting about this approach is that you would not
> > > > > > > > > > > > > > > > > > > > have to scan the ACPI namespace in search of
> > > > > > > > > > > > > > > > > > > > SMO88xx devices, because smo8800_add() is
> > > > > > > > > > > > > > > > > > > > automatically called for them. However, I fear that
> > > > > > > > > > > > > > > > > > > > the resulting solution may be more complicated than
> > > > > > > > > > > > > > > > > > > > the one you submitted.
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > Then we need to deal with lot of problems. Order of
> > > > > > > > > > > > > > > > > > > loading .ko modules is undefined. Binding devices to
> > > > > > > > > > > > > > > > > > > drivers registered by .ko module is also in "random"
> > > > > > > > > > > > > > > > > > > order. At any time any of those .ko module can be
> > > > > > > > > > > > > > > > > > > unloaded or at least device unbind (via sysfs) from
> > > > > > > > > > > > > > > > > > > driver... And there can be some pathological
> > > > > > > > > > > > > > > > > > > situation (thanks to adding ACPI layer as Andy
> > > > > > > > > > > > > > > > > > > pointed) that there will be more SMO88xx devices in
> > > > > > > > > > > > > > > > > > > ACPI. Plus you can compile kernel with and without
> > > > > > > > > > > > > > > > > > > those modules and also you can blacklist loading
> > > > > > > > > > > > > > > > > > > them (so compile time check is not enough). And
> > > > > > > > > > > > > > > > > > > still some correct message notifier must be used.
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > I think such solution is much much more complicated,
> > > > > > > > > > > > > > > > > > > there are lot of combinations of kernel configuration
> > > > > > > > > > > > > > > > > > > and available dell devices...
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > I tried a few more things, but ultimately failed to
> > > > > > > > > > > > > > > > > > find a nice way to implement this.
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > Another issue popped up, though.  Linus' master branch
> > > > > > > > > > > > > > > > > > contains a recent commit by Benjamin Tissoires (CC'ed),
> > > > > > > > > > > > > > > > > > 4d5538f5882a ("i2c: use an IRQ to report Host Notify
> > > > > > > > > > > > > > > > > > events, not alert") which breaks your patch.  The
> > > > > > > > > > > > > > > > > > reason for that is that lis3lv02d relies on the i2c
> > > > > > > > > > > > > > > > > > client's IRQ being 0 to detect that it should not
> > > > > > > > > > > > > > > > > > create /dev/freefall.
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > >  Benjamin's patch causes the Host Notify IRQ to be
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > assigned to the i2c client your patch creates, thus
> > > > > > > > > > > > > > > > > > causing lis3lv02d to create /dev/freefall, which in
> > > > > > > > > > > > > > > > > > turn conflicts with dell-smo8800 which is trying to
> > > > > > > > > > > > > > > > > > create /dev/freefall itself.
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > So 4d5538f5882a is breaking lis3lv02d driver...
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > Apologies for that.
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > I could easily fix this by adding a kernel API to know
> > > > > > > > > > > > > > > > whether the provided irq is from Host Notify or if it was
> > > > > > > > > > > > > > > > coming from an actual declaration. However, I have no idea
> > > > > > > > > > > > > > > > how many other drivers would require this (hopefully only
> > > > > > > > > > > > > > > > this one).
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > One other solution would be to reserve the Host Notify IRQ
> > > > > > > > > > > > > > > > and let the actual drivers that need it to set it, but
> > > > > > > > > > > > > > > > this was not the best solution according to Dmitri. On my
> > > > > > > > > > > > > > > > side, I am not entirely against this given that it's a
> > > > > > > > > > > > > > > > chip feature, so the driver should be able to know that
> > > > > > > > > > > > > > > > it's available.
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > Dmitri, Wolfram, Jean, any preferences?
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > I read this:
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > "IIRC both dell-smo8800 and lis3lv02d represent one HW device
> > > > > > > > > > > > > > > (that ST microelectronics accelerometer) but due to
> > > > > > > > > > > > > > > complicated HW abstraction and layers on Dell laptops it is
> > > > > > > > > > > > > > > handled by two drivers, one ACPI and one i2c."
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > and that is the core of the issue. You have 2 drivers
> > > > > > > > > > > > > > > fighting over the same device. Fix this and it will all
> > > > > > > > > > > > > > > work.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > With my current implementation (which I sent in this patch),
> > > > > > > > > > > > > > they are not fighting.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > dell-smo8800 exports /dev/freefall (and nothing more) and
> > > > > > > > > > > > > > lis3lv02d only accelerometer device as lis3lv02d driver does
> > > > > > > > > > > > > > not get IRQ number in platform data.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > As far as I can see hp_accel instantiates lis3lv02d and
> > > > > > > > > > > > > > > accesses it via ACPI methods, can the same be done for Dell?
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > No, Dell does not have any ACPI methods. And as I wrote in ACPI
> > > > > > > > > > > > > > or DMI is even not i2c address of device, so it needs to be
> > > > > > > > > > > > > > specified in code itself.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Really there is no other way... :-(
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Sure there is:
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 1. dell-smo8800 instantiates I2C device as "dell-smo8800-accel".
> > > > > > > > > > > > > 2. dell-smo8800 provides read/write functions for lis3lv02d that
> > > > > > > > > > > > > simply forward requests to dell-smo8800-accel i2c client.
> > > > > > > > > > > > > 3. dell-smo8800 instantiates lis3lv02d instance like hp_accel
> > > > > > > > > > > > > does.
> > > > > > > > > > > > 
> > > > > > > > > > > > Sorry, but I do not understand how you mean it... Why to provides
> > > > > > > > > > > > new read/write i2c functions which are already implemented by
> > > > > > > > > > > > i2c-i801 bus and lis3lv02d i2c driver?
> > > > > > > > > > > 
> > > > > > > > > > > Because that would allow you to avoid clashes with i2c creating
> > > > > > > > > > > interrupt mapping for client residing on host-notify-capable
> > > > > > > > > > > controller.
> > > > > > > > > > > 
> > > > > > > > > > > > > Alternatively, can lis3lv02d be tasked to create /dev/freefall?
> > > > > > > > > > > > 
> > > > > > > > > > > > If i2c_board_info contains IRQ then lis3lv02d create /dev/freefall
> > > > > > > > > > > > device.
> > > > > > > > > > > > 
> > > > > > > > > > > > But... what is problem with current implementation? Accelerometer
> > > > > > > > > > > > HW provides two functions:
> > > > > > > > > > > > 
> > > > > > > > > > > > 1) 3 axes reports
> > > > > > > > > > > > 2) Disk freefall detection
> > > > > > > > > > > > 
> > > > > > > > > > > > And 1) is handled by i2c driver lis3lv02d and 2) is by
> > > > > > > > > > > > dell-smo8800. Both functions are independent here.
> > > > > > > > > > > > 
> > > > > > > > > > > > I think you just trying to complicate this situation even more to
> > > > > > > > > > > > be more complicated as currently is.
> > > > > > > > > > > 
> > > > > > > > > > > Because this apparently does not work for you, does it?
> > > > > > > > > > 
> > > > > > > > > > It is working fine. I do not see any problem.
> > > > > > > > > > 
> > > > > > > > > > > In general,
> > > > > > > > > > > if you want the same hardware be handled by 2 different drivers you
> > > > > > > > > > > are going to have bad time.
> > > > > > > > > > 
> > > > > > > > > > Yes, but in this case half of device is ACPI based and other half i2c 
> > > > > > > > > > based. This is problem of ACPI and Dell design.
> > > > > > > > > > 
> > > > > > > > > > > It seems to be that /dev/freefall in dell-smo8800 and lis3lv02d are
> > > > > > > > > > > the same, right?
> > > > > > > > > > 
> > > > > > > > > > Yes. I understand that clean solution is to have one driver which 
> > > > > > > > > > provides everything.
> > > > > > > > > > 
> > > > > > > > > > But because half of data are ACPI and half i2c, you still needs to 
> > > > > > > > > > create two drivers (one ACPI and one i2c). You can put both drivers into 
> > > > > > > > > > one .ko module, but still these will be two drivers due to how ACPI and 
> > > > > > > > > > i2c linux abstractions are different.
> > > > > > > > > > 
> > > > > > > > > > > So, instead of having 2 drivers split the
> > > > > > > > > > > functionality, can you forego registering smo8800 ACPI driver on
> > > > > > > > > > > your whitelisted boxes and instead instantiate full i2c client
> > > > > > > > > > > device with properly assigned both address and IRQ and let lis3lv02d
> > > > > > > > > > > handle it (providing both accelerometer data and /dev/freefall)?
> > > > > > > > > > 
> > > > > > > > > > With Michał we already discussed about it, see emails. Basically you can 
> > > > > > > > > > enable/disable kernel modules at compile time or blacklist at runtime 
> > > > > > > > > > (or even chose what will be compiled into vmlinux and what as external 
> > > > > > > > > > .ko module).
> > > > > > > > > 
> > > > > > > > > This can be solved with a bit of Kconfig/IS_ENABLED() code.
> > > > > > > > > 
> > > > > > > > > > Some distributions blacklist i2c-i801.ko module... And 
> > > > > > > > > 
> > > > > > > > > Any particular reason for that?
> > > > > > > > > 
> > > > > > > > > > there can be also problem with initialization of i2c-i801 driver (fix is 
> > > > > > > > > > in commit a7ae81952cda, but does not have to work at every time!). So 
> > > > > > > > > > that move on whitelisted machines can potentially cause disappearance of 
> > > > > > > > > > /dev/freefall and users will not have hdd protection which is currently 
> > > > > > > > > > working.
> > > > > > > > > 
> > > > > > > > > Well, I gave you 2 possible solutions (roll your own i2c read/write,
> > > > > > > > > forward them to i2c client) or have faith in your implementation and let
> > > > > > > > > lis3lv02d handle it.
> > > > > > > > > 
> > > > > > > > > The 3rd one is to possibly add a flag to disable host notify to IRQ
> > > > > > > > > mapping for given client (if Wolfram/Jean OK with it).
> > > > > > > > > 
> > > > > > > > > Oh, the 4th one: change the irq in lis3lv02d.h to be "int" and change
> > > > > > > > > the check in lis3lv02d.c to be "lis->irq <= 0" and instantiate your
> > > > > > > > > i2c_client with board_info->irq = -1.
> > > > > > > > > 
> > > > > > > > > Pick whichever you prefer.
> > > > > > > > > 
> > > > > > > > > By the way, what do you need accelerometer for on these devices? They
> > > > > > > > > don't appear to be tablets that could use one... 
> > > > > > > > 
> > > > > > > > Ah, you are talking about problem that after 4d5538f5882a lis3lv02d will
> > > > > > > > not work... I thought that discussion is about different mechanism how
> > > > > > > > to implement bus registration notification to smo8800 driver (or
> > > > > > > > different solution to not have registration in i801).
> > > > > > > > 
> > > > > > > 
> > > > > > > Just because I am not sure I got everything right, could you confirm
> > > > > > > that:
> > > > > > > - in the current upstream tree, the dell-smo8800 driver is now broken
> > > > > > >   after 4d5538f5882a (i2c: use an IRQ to report Host Notify events, not
> > > > > > >   alert)
> > > > > > 
> > > > > > No, dell-smo8800 it is working fine. It is fully independent from i2c
> > > > > > and lis3lv02d. It is pure ACPI driver which does not share anything with
> > > > > > i2c.
> > > > > > 
> > > > > > > - this series adds an extra lis3lv02d on some machines and you have
> > > > > > >   problem fighting for the irq (but this is not upstream yet).
> > > > > > 
> > > > > > Yes, this series (not merged yet) adds extra lis3lv02d device but is not
> > > > > > working because of 4d5538f5882a.
> > > > > > 
> > > > > > > The extra lis3lv02d node is added from dell-smo8800
> > > > > > 
> > > > > > No, dell-smo8800 does not add new node in this patch.
> > > > > > 
> > > > > > > If the first point is not correct (by default, dell-smo8800 will not be
> > > > > > > loaded at the same time than lis3lv02d), then it's a design issue with
> > > > > > > the interactions between those 2 drivers.
> > > > > > 
> > > > > > No, there is no interactions between these two drivers (dell-smo8800 and
> > > > > > lis3lv02d). dell-smo8800 is pure ACPI driver and exports just
> > > > > > /dev/freefall device based on IRQ (and nothing more).
> > > > > > 
> > > > > > And lis3lv02d in *current* configuration in this patch exports only
> > > > > > accelerometer input device, not /dev/freefall. It does not use IRQ.
> > > > > > (Just there is problem with 4d5538f5882a which tells lis3lv02d IRQ
> > > > > > number which is not freefall report, therefore lis3lv02d does not work).
> > > > > > 
> > > > > > To make it clear, ST Accelerometer provides two operations:
> > > > > > * report free fall
> > > > > > * report 3 axes
> > > > > > 
> > > > > > Free fall is reported by IRQ, state of 3 axes via i2c bus. Free fall IRQ
> > > > > > is handled by dell-smo8800, state of 3 axes via i2c lis3lv02d driver.
> > > > > > 
> > > > > > lis3lv02d can handle also free fall IRQ is platform i2c data provides
> > > > > > IRQ number for it -- but this is not case in our Dell configuration. But
> > > > > > commit 4d5538f5882a inject some IRQ number to lis3lv02d driver which is
> > > > > > not free fall detection and so is breaking lis3lv02 driver. In our Dell
> > > > > > configuration (by this patch) there should be no IRQ number.
> > > > > > 
> > > > > > It is clear now?
> > > > > 
> > > > > I think I am starting to understand the problem.
> > > > > 
> > > > > Currently (upstream tree), 4d5538f5882a doesn't break anything.
> > > > 
> > > > I cannot prove it... lis3lv02d i2c driver itself uses this IRQ logic
> > > > (missing = no freefall) and there could be already hardware/boards which
> > > > register lis3lv02d i2c device without IRQ number. And definitions could
> > > > be also in device tree and so outside of kernel sources...
> > > > 
> > > > So there can be potentially break. But at least not case of Dell.
> > > > 
> > > > > On the
> > > > > mentioned Dell platforms, the dell-smo8800 gets loaded and provides
> > > > > /dev/freefall. lis3lv02d is not loaded so everything just works.
> > > > 
> > > > Yes.
> > > > 
> > > > > The problem comes from this patch which doesn't set the irq in
> > > > > i2c_board_info and so i2c_core sets the IRQ to Host Notify. I think
> > > > > Dmitri already gave you the solution: set the irq to -1 (or -ENOENT)
> > > > > in i2c_board_info in your patch and only forward it to
> > > > > lis3lv02d_init_device() only if it is positive (valid).
> > > > 
> > > > Now I understood that Dmitri means. For this Dell platforms it is OK,
> > > > but we have a problem for device tree platforms. Normally in device tree
> > > > if device does not support something you just do not specify it. But
> > > > with this approach you need to explicitly specify IRQ to -1 in device
> > > > tree. And I think this is really not a clean solution.
> > > > 
> > 
> > Here I was talking about other platforms/devices (not this Dell one).
> > 
> > > No. DT platforms won't have an issue: they don't change anything, and
> > > there will be a new /dev/freefall misc device for the platforms that
> > 
> > And this is wrong! There should not be any /dev/freefall device
> > connected with signal host notify. /dev/freefall is for hardware which
> > supports free fall hdd detection.

On the principle, I agree. But let's be realistic: this device will be
created but no events will be generated from it. It's a capability for
the chip to provide freefall, so I don't see why it's such an issue to
have one created which says nothing. (talking about non Dell platforms
here too)

> > 
> > > don't have the irq set *and* if the device is on a Host Notify capable
> > > adapter, currently only i2c-i801.
> > 
> > I understood, but in future more bus drivers could support host notify.
> 
> This is really fragile. lis3lv02d will empty IRQ (0) will work on some
> i2c buses and on some not. I would really expect that i2c driver
> (lis3lv02d) will work in same way with any i2c bus driver. And not that
> on i801 will acts differently as on e.g. omap3 i2c bus.

I really don't follow you here. On a bus with no Host Notify, the IRQ
will be 0 and it will work in the same way. On a bus with Host Notify,
the IRQ should be set to something negative in the i2c_board_info to be
sure to not have an Host Notify irq assigned. In both case the
lis3lv02d_i2c driver will just do:
	if (client->irq > 0)
		lis3_dev.irq = client->irq;

So there is no bus adapter specifics in the driver.

> 
> > This is basically incorrect if we use one property for two different
> > things (host notify and hdd free fall).

Host Notify is a way for a I2C device to report an interrupt without
having a dedicated line assigned (and so an IRQ). So the chip could use
Host Notify to report hdd free fall if it supports the feature.

> > 
> > For me it looks like that we should separate these two things into two
> > IRQ properties. It is really wrong design if one property is used for
> > two different things.

I won't say the design is wrong because Host Notify really is just an
IRQ. Where the issue lies now is that lis3lv02d makes the assumption
that an irq attached to an i2c_client means that it will report
freefall. It was correct before, but now it's not true anymore.
So maybe this series should also add a way to provide the source of
the IRQ (Host Notify or ACPI or DT). Then, lis3lv02d could ignore or
not the incoming IRQ.

Cheers,
Benjamin

> > 
> > > But given that they are DT and not
> > > ACPI, this won't conflict with dell-smo8800, so there won't be any
> > > errors, just a dangling unused device node.
> > 
> > Yes, for upcoming Dell in this patch (with IRQ -1) it is not a problem.
> > 
> > > This approach is IMO the best if you want to have this in the kernel.
> > > 
> > > Cheers,
> > > Benjamin
> > 
> 
> -- 
> Pali Rohár
> pali.rohar@gmail.com

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Pali Rohár]

On Wednesday 04 January 2017 14:02:52 Benjamin Tissoires wrote:
> On Jan 04 2017 or thereabouts, Pali Rohár wrote:
> > On Wednesday 04 January 2017 12:22:23 Pali Rohár wrote:
> > > On Wednesday 04 January 2017 11:32:33 Benjamin Tissoires wrote:
> > > > On Jan 04 2017 or thereabouts, Pali Rohár wrote:
> > > > > On Wednesday 04 January 2017 11:13:06 Benjamin Tissoires wrote:
> > > > > > On Jan 04 2017 or thereabouts, Pali Rohár wrote:
> > > > > > > On Wednesday 04 January 2017 10:05:22 Benjamin Tissoires wrote:
> > > > > > > > On Jan 04 2017 or thereabouts, Pali Rohár wrote:
> > > > > > > > > On Tuesday 03 January 2017 12:59:37 Dmitry Torokhov wrote:
> > > > > > > > > > On Tue, Jan 03, 2017 at 09:39:13PM +0100, Pali Rohár wrote:
> > > > > > > > > > > On Tuesday 03 January 2017 21:24:18 Dmitry Torokhov wrote:
> > > > > > > > > > > > On Tue, Jan 03, 2017 at 09:05:51PM +0100, Pali Rohár wrote:
> > > > > > > > > > > > > On Tuesday 03 January 2017 20:48:12 Dmitry Torokhov wrote:
> > > > > > > > > > > > > > On Tue, Jan 03, 2017 at 07:50:17PM +0100, Pali Rohár wrote:
> > > > > > > > > > > > > > > On Tuesday 03 January 2017 19:38:43 Dmitry Torokhov wrote:
> > > > > > > > > > > > > > > > On Tue, Jan 03, 2017 at 10:06:41AM +0100, Benjamin Tissoires
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > On Dec 29 2016 or thereabouts, Pali Rohár wrote:
> > > > > > > > > > > > > > > > > > On Thursday 29 December 2016 22:09:32 Michał Kępień wrote:
> > > > > > > > > > > > > > > > > > > > On Thursday 29 December 2016 14:47:19 Michał Kępień
> > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > On Thursday 29 December 2016 09:29:36 Michał
> > > > > > > > > > > > > > > > > > > > > > Kępień
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > > Dell platform team told us that some (DMI
> > > > > > > > > > > > > > > > > > > > > > > > whitelisted) Dell Latitude machines have ST
> > > > > > > > > > > > > > > > > > > > > > > > microelectronics accelerometer at i2c address
> > > > > > > > > > > > > > > > > > > > > > > > 0x29. That i2c address is not specified in
> > > > > > > > > > > > > > > > > > > > > > > > DMI or ACPI, so runtime detection without
> > > > > > > > > > > > > > > > > > > > > > > > whitelist which is below is not possible.
> > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > Presence of that ST microelectronics
> > > > > > > > > > > > > > > > > > > > > > > > accelerometer is verified by existence of
> > > > > > > > > > > > > > > > > > > > > > > > SMO88xx ACPI device which represent that
> > > > > > > > > > > > > > > > > > > > > > > > accelerometer. Unfortunately without i2c
> > > > > > > > > > > > > > > > > > > > > > > > address.
> > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > This part of the commit message sounded a bit
> > > > > > > > > > > > > > > > > > > > > > > confusing to me at first because there is
> > > > > > > > > > > > > > > > > > > > > > > already an ACPI driver which handles SMO88xx
> > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > devices (dell-smo8800).  My understanding is
> > > > > > > > > > > > > > > > > > > > > > > that:
> > > > > > > > > > > > > > > > > > > > > > >   * the purpose of this patch is to expose a
> > > > > > > > > > > > > > > > > > > > > > >   richer interface (as
> > > > > > > > > > > > > > > > > > > > > > >   
> > > > > > > > > > > > > > > > > > > > > > >     provided by lis3lv02d) to these devices on
> > > > > > > > > > > > > > > > > > > > > > >     some machines,
> > > > > > > > > > > > > > > > > > > > > > >   
> > > > > > > > > > > > > > > > > > > > > > >   * on whitelisted machines, dell-smo8800 and
> > > > > > > > > > > > > > > > > > > > > > >   lis3lv02d can work
> > > > > > > > > > > > > > > > > > > > > > >   
> > > > > > > > > > > > > > > > > > > > > > >     simultaneously (even though dell-smo8800
> > > > > > > > > > > > > > > > > > > > > > >     effectively duplicates the work that
> > > > > > > > > > > > > > > > > > > > > > >     lis3lv02d does).
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > No. dell-smo8800 reads from ACPI irq number and
> > > > > > > > > > > > > > > > > > > > > > exports /dev/freefall device which notify
> > > > > > > > > > > > > > > > > > > > > > userspace about falls. lis3lv02d is i2c driver
> > > > > > > > > > > > > > > > > > > > > > which exports axes of accelerometer. Additionaly
> > > > > > > > > > > > > > > > > > > > > > lis3lv02d can export also /dev/freefall if
> > > > > > > > > > > > > > > > > > > > > > registerer of i2c device provides irq number --
> > > > > > > > > > > > > > > > > > > > > > which is not case of this patch.
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > So both drivers are doing different things and
> > > > > > > > > > > > > > > > > > > > > > both are useful.
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > IIRC both dell-smo8800 and lis3lv02d represent
> > > > > > > > > > > > > > > > > > > > > > one HW device (that ST microelectronics
> > > > > > > > > > > > > > > > > > > > > > accelerometer) but due to complicated HW
> > > > > > > > > > > > > > > > > > > > > > abstraction and layers on Dell laptops it is
> > > > > > > > > > > > > > > > > > > > > > handled by two drivers, one ACPI and one i2c.
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > Yes, in ideal world irq number should be passed
> > > > > > > > > > > > > > > > > > > > > > to lis3lv02d driver and that would export whole
> > > > > > > > > > > > > > > > > > > > > > device (with /dev/freefall too), but due to HW
> > > > > > > > > > > > > > > > > > > > > > abstraction it is too much complicated...
> > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > Why?  AFAICT, all that is required to pass that IRQ
> > > > > > > > > > > > > > > > > > > > > number all the way down to lis3lv02d is to set the
> > > > > > > > > > > > > > > > > > > > > irq field of the struct i2c_board_info you are
> > > > > > > > > > > > > > > > > > > > > passing to i2c_new_device().  And you can extract
> > > > > > > > > > > > > > > > > > > > > that IRQ number e.g. in
> > > > > > > > > > > > > > > > > > > > > check_acpi_smo88xx_device(). However, you would
> > > > > > > > > > > > > > > > > > > > > then need to make sure dell-smo8800 does not
> > > > > > > > > > > > > > > > > > > > > attempt to request the same IRQ on whitelisted
> > > > > > > > > > > > > > > > > > > > > machines.  This got me thinking about a way to
> > > > > > > > > > > > > > > > > > > > > somehow incorporate your changes into dell-smo8800
> > > > > > > > > > > > > > > > > > > > > using Wolfram's bus_notifier suggestion, but I do
> > > > > > > > > > > > > > > > > > > > > not have a working solution for now.  What is
> > > > > > > > > > > > > > > > > > > > > tempting about this approach is that you would not
> > > > > > > > > > > > > > > > > > > > > have to scan the ACPI namespace in search of
> > > > > > > > > > > > > > > > > > > > > SMO88xx devices, because smo8800_add() is
> > > > > > > > > > > > > > > > > > > > > automatically called for them. However, I fear that
> > > > > > > > > > > > > > > > > > > > > the resulting solution may be more complicated than
> > > > > > > > > > > > > > > > > > > > > the one you submitted.
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > Then we need to deal with lot of problems. Order of
> > > > > > > > > > > > > > > > > > > > loading .ko modules is undefined. Binding devices to
> > > > > > > > > > > > > > > > > > > > drivers registered by .ko module is also in "random"
> > > > > > > > > > > > > > > > > > > > order. At any time any of those .ko module can be
> > > > > > > > > > > > > > > > > > > > unloaded or at least device unbind (via sysfs) from
> > > > > > > > > > > > > > > > > > > > driver... And there can be some pathological
> > > > > > > > > > > > > > > > > > > > situation (thanks to adding ACPI layer as Andy
> > > > > > > > > > > > > > > > > > > > pointed) that there will be more SMO88xx devices in
> > > > > > > > > > > > > > > > > > > > ACPI. Plus you can compile kernel with and without
> > > > > > > > > > > > > > > > > > > > those modules and also you can blacklist loading
> > > > > > > > > > > > > > > > > > > > them (so compile time check is not enough). And
> > > > > > > > > > > > > > > > > > > > still some correct message notifier must be used.
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > I think such solution is much much more complicated,
> > > > > > > > > > > > > > > > > > > > there are lot of combinations of kernel configuration
> > > > > > > > > > > > > > > > > > > > and available dell devices...
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > I tried a few more things, but ultimately failed to
> > > > > > > > > > > > > > > > > > > find a nice way to implement this.
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > Another issue popped up, though.  Linus' master branch
> > > > > > > > > > > > > > > > > > > contains a recent commit by Benjamin Tissoires (CC'ed),
> > > > > > > > > > > > > > > > > > > 4d5538f5882a ("i2c: use an IRQ to report Host Notify
> > > > > > > > > > > > > > > > > > > events, not alert") which breaks your patch.  The
> > > > > > > > > > > > > > > > > > > reason for that is that lis3lv02d relies on the i2c
> > > > > > > > > > > > > > > > > > > client's IRQ being 0 to detect that it should not
> > > > > > > > > > > > > > > > > > > create /dev/freefall.
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > >  Benjamin's patch causes the Host Notify IRQ to be
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > assigned to the i2c client your patch creates, thus
> > > > > > > > > > > > > > > > > > > causing lis3lv02d to create /dev/freefall, which in
> > > > > > > > > > > > > > > > > > > turn conflicts with dell-smo8800 which is trying to
> > > > > > > > > > > > > > > > > > > create /dev/freefall itself.
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > So 4d5538f5882a is breaking lis3lv02d driver...
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > Apologies for that.
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > I could easily fix this by adding a kernel API to know
> > > > > > > > > > > > > > > > > whether the provided irq is from Host Notify or if it was
> > > > > > > > > > > > > > > > > coming from an actual declaration. However, I have no idea
> > > > > > > > > > > > > > > > > how many other drivers would require this (hopefully only
> > > > > > > > > > > > > > > > > this one).
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > One other solution would be to reserve the Host Notify IRQ
> > > > > > > > > > > > > > > > > and let the actual drivers that need it to set it, but
> > > > > > > > > > > > > > > > > this was not the best solution according to Dmitri. On my
> > > > > > > > > > > > > > > > > side, I am not entirely against this given that it's a
> > > > > > > > > > > > > > > > > chip feature, so the driver should be able to know that
> > > > > > > > > > > > > > > > > it's available.
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > Dmitri, Wolfram, Jean, any preferences?
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > I read this:
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > "IIRC both dell-smo8800 and lis3lv02d represent one HW device
> > > > > > > > > > > > > > > > (that ST microelectronics accelerometer) but due to
> > > > > > > > > > > > > > > > complicated HW abstraction and layers on Dell laptops it is
> > > > > > > > > > > > > > > > handled by two drivers, one ACPI and one i2c."
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > and that is the core of the issue. You have 2 drivers
> > > > > > > > > > > > > > > > fighting over the same device. Fix this and it will all
> > > > > > > > > > > > > > > > work.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > With my current implementation (which I sent in this patch),
> > > > > > > > > > > > > > > they are not fighting.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > dell-smo8800 exports /dev/freefall (and nothing more) and
> > > > > > > > > > > > > > > lis3lv02d only accelerometer device as lis3lv02d driver does
> > > > > > > > > > > > > > > not get IRQ number in platform data.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > As far as I can see hp_accel instantiates lis3lv02d and
> > > > > > > > > > > > > > > > accesses it via ACPI methods, can the same be done for Dell?
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > No, Dell does not have any ACPI methods. And as I wrote in ACPI
> > > > > > > > > > > > > > > or DMI is even not i2c address of device, so it needs to be
> > > > > > > > > > > > > > > specified in code itself.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Really there is no other way... :-(
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Sure there is:
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > 1. dell-smo8800 instantiates I2C device as "dell-smo8800-accel".
> > > > > > > > > > > > > > 2. dell-smo8800 provides read/write functions for lis3lv02d that
> > > > > > > > > > > > > > simply forward requests to dell-smo8800-accel i2c client.
> > > > > > > > > > > > > > 3. dell-smo8800 instantiates lis3lv02d instance like hp_accel
> > > > > > > > > > > > > > does.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Sorry, but I do not understand how you mean it... Why to provides
> > > > > > > > > > > > > new read/write i2c functions which are already implemented by
> > > > > > > > > > > > > i2c-i801 bus and lis3lv02d i2c driver?
> > > > > > > > > > > > 
> > > > > > > > > > > > Because that would allow you to avoid clashes with i2c creating
> > > > > > > > > > > > interrupt mapping for client residing on host-notify-capable
> > > > > > > > > > > > controller.
> > > > > > > > > > > > 
> > > > > > > > > > > > > > Alternatively, can lis3lv02d be tasked to create /dev/freefall?
> > > > > > > > > > > > > 
> > > > > > > > > > > > > If i2c_board_info contains IRQ then lis3lv02d create /dev/freefall
> > > > > > > > > > > > > device.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > But... what is problem with current implementation? Accelerometer
> > > > > > > > > > > > > HW provides two functions:
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 1) 3 axes reports
> > > > > > > > > > > > > 2) Disk freefall detection
> > > > > > > > > > > > > 
> > > > > > > > > > > > > And 1) is handled by i2c driver lis3lv02d and 2) is by
> > > > > > > > > > > > > dell-smo8800. Both functions are independent here.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I think you just trying to complicate this situation even more to
> > > > > > > > > > > > > be more complicated as currently is.
> > > > > > > > > > > > 
> > > > > > > > > > > > Because this apparently does not work for you, does it?
> > > > > > > > > > > 
> > > > > > > > > > > It is working fine. I do not see any problem.
> > > > > > > > > > > 
> > > > > > > > > > > > In general,
> > > > > > > > > > > > if you want the same hardware be handled by 2 different drivers you
> > > > > > > > > > > > are going to have bad time.
> > > > > > > > > > > 
> > > > > > > > > > > Yes, but in this case half of device is ACPI based and other half i2c 
> > > > > > > > > > > based. This is problem of ACPI and Dell design.
> > > > > > > > > > > 
> > > > > > > > > > > > It seems to be that /dev/freefall in dell-smo8800 and lis3lv02d are
> > > > > > > > > > > > the same, right?
> > > > > > > > > > > 
> > > > > > > > > > > Yes. I understand that clean solution is to have one driver which 
> > > > > > > > > > > provides everything.
> > > > > > > > > > > 
> > > > > > > > > > > But because half of data are ACPI and half i2c, you still needs to 
> > > > > > > > > > > create two drivers (one ACPI and one i2c). You can put both drivers into 
> > > > > > > > > > > one .ko module, but still these will be two drivers due to how ACPI and 
> > > > > > > > > > > i2c linux abstractions are different.
> > > > > > > > > > > 
> > > > > > > > > > > > So, instead of having 2 drivers split the
> > > > > > > > > > > > functionality, can you forego registering smo8800 ACPI driver on
> > > > > > > > > > > > your whitelisted boxes and instead instantiate full i2c client
> > > > > > > > > > > > device with properly assigned both address and IRQ and let lis3lv02d
> > > > > > > > > > > > handle it (providing both accelerometer data and /dev/freefall)?
> > > > > > > > > > > 
> > > > > > > > > > > With Michał we already discussed about it, see emails. Basically you can 
> > > > > > > > > > > enable/disable kernel modules at compile time or blacklist at runtime 
> > > > > > > > > > > (or even chose what will be compiled into vmlinux and what as external 
> > > > > > > > > > > .ko module).
> > > > > > > > > > 
> > > > > > > > > > This can be solved with a bit of Kconfig/IS_ENABLED() code.
> > > > > > > > > > 
> > > > > > > > > > > Some distributions blacklist i2c-i801.ko module... And 
> > > > > > > > > > 
> > > > > > > > > > Any particular reason for that?
> > > > > > > > > > 
> > > > > > > > > > > there can be also problem with initialization of i2c-i801 driver (fix is 
> > > > > > > > > > > in commit a7ae81952cda, but does not have to work at every time!). So 
> > > > > > > > > > > that move on whitelisted machines can potentially cause disappearance of 
> > > > > > > > > > > /dev/freefall and users will not have hdd protection which is currently 
> > > > > > > > > > > working.
> > > > > > > > > > 
> > > > > > > > > > Well, I gave you 2 possible solutions (roll your own i2c read/write,
> > > > > > > > > > forward them to i2c client) or have faith in your implementation and let
> > > > > > > > > > lis3lv02d handle it.
> > > > > > > > > > 
> > > > > > > > > > The 3rd one is to possibly add a flag to disable host notify to IRQ
> > > > > > > > > > mapping for given client (if Wolfram/Jean OK with it).
> > > > > > > > > > 
> > > > > > > > > > Oh, the 4th one: change the irq in lis3lv02d.h to be "int" and change
> > > > > > > > > > the check in lis3lv02d.c to be "lis->irq <= 0" and instantiate your
> > > > > > > > > > i2c_client with board_info->irq = -1.
> > > > > > > > > > 
> > > > > > > > > > Pick whichever you prefer.
> > > > > > > > > > 
> > > > > > > > > > By the way, what do you need accelerometer for on these devices? They
> > > > > > > > > > don't appear to be tablets that could use one... 
> > > > > > > > > 
> > > > > > > > > Ah, you are talking about problem that after 4d5538f5882a lis3lv02d will
> > > > > > > > > not work... I thought that discussion is about different mechanism how
> > > > > > > > > to implement bus registration notification to smo8800 driver (or
> > > > > > > > > different solution to not have registration in i801).
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > Just because I am not sure I got everything right, could you confirm
> > > > > > > > that:
> > > > > > > > - in the current upstream tree, the dell-smo8800 driver is now broken
> > > > > > > >   after 4d5538f5882a (i2c: use an IRQ to report Host Notify events, not
> > > > > > > >   alert)
> > > > > > > 
> > > > > > > No, dell-smo8800 it is working fine. It is fully independent from i2c
> > > > > > > and lis3lv02d. It is pure ACPI driver which does not share anything with
> > > > > > > i2c.
> > > > > > > 
> > > > > > > > - this series adds an extra lis3lv02d on some machines and you have
> > > > > > > >   problem fighting for the irq (but this is not upstream yet).
> > > > > > > 
> > > > > > > Yes, this series (not merged yet) adds extra lis3lv02d device but is not
> > > > > > > working because of 4d5538f5882a.
> > > > > > > 
> > > > > > > > The extra lis3lv02d node is added from dell-smo8800
> > > > > > > 
> > > > > > > No, dell-smo8800 does not add new node in this patch.
> > > > > > > 
> > > > > > > > If the first point is not correct (by default, dell-smo8800 will not be
> > > > > > > > loaded at the same time than lis3lv02d), then it's a design issue with
> > > > > > > > the interactions between those 2 drivers.
> > > > > > > 
> > > > > > > No, there is no interactions between these two drivers (dell-smo8800 and
> > > > > > > lis3lv02d). dell-smo8800 is pure ACPI driver and exports just
> > > > > > > /dev/freefall device based on IRQ (and nothing more).
> > > > > > > 
> > > > > > > And lis3lv02d in *current* configuration in this patch exports only
> > > > > > > accelerometer input device, not /dev/freefall. It does not use IRQ.
> > > > > > > (Just there is problem with 4d5538f5882a which tells lis3lv02d IRQ
> > > > > > > number which is not freefall report, therefore lis3lv02d does not work).
> > > > > > > 
> > > > > > > To make it clear, ST Accelerometer provides two operations:
> > > > > > > * report free fall
> > > > > > > * report 3 axes
> > > > > > > 
> > > > > > > Free fall is reported by IRQ, state of 3 axes via i2c bus. Free fall IRQ
> > > > > > > is handled by dell-smo8800, state of 3 axes via i2c lis3lv02d driver.
> > > > > > > 
> > > > > > > lis3lv02d can handle also free fall IRQ is platform i2c data provides
> > > > > > > IRQ number for it -- but this is not case in our Dell configuration. But
> > > > > > > commit 4d5538f5882a inject some IRQ number to lis3lv02d driver which is
> > > > > > > not free fall detection and so is breaking lis3lv02 driver. In our Dell
> > > > > > > configuration (by this patch) there should be no IRQ number.
> > > > > > > 
> > > > > > > It is clear now?
> > > > > > 
> > > > > > I think I am starting to understand the problem.
> > > > > > 
> > > > > > Currently (upstream tree), 4d5538f5882a doesn't break anything.
> > > > > 
> > > > > I cannot prove it... lis3lv02d i2c driver itself uses this IRQ logic
> > > > > (missing = no freefall) and there could be already hardware/boards which
> > > > > register lis3lv02d i2c device without IRQ number. And definitions could
> > > > > be also in device tree and so outside of kernel sources...
> > > > > 
> > > > > So there can be potentially break. But at least not case of Dell.
> > > > > 
> > > > > > On the
> > > > > > mentioned Dell platforms, the dell-smo8800 gets loaded and provides
> > > > > > /dev/freefall. lis3lv02d is not loaded so everything just works.
> > > > > 
> > > > > Yes.
> > > > > 
> > > > > > The problem comes from this patch which doesn't set the irq in
> > > > > > i2c_board_info and so i2c_core sets the IRQ to Host Notify. I think
> > > > > > Dmitri already gave you the solution: set the irq to -1 (or -ENOENT)
> > > > > > in i2c_board_info in your patch and only forward it to
> > > > > > lis3lv02d_init_device() only if it is positive (valid).
> > > > > 
> > > > > Now I understood that Dmitri means. For this Dell platforms it is OK,
> > > > > but we have a problem for device tree platforms. Normally in device tree
> > > > > if device does not support something you just do not specify it. But
> > > > > with this approach you need to explicitly specify IRQ to -1 in device
> > > > > tree. And I think this is really not a clean solution.
> > > > > 
> > > 
> > > Here I was talking about other platforms/devices (not this Dell one).
> > > 
> > > > No. DT platforms won't have an issue: they don't change anything, and
> > > > there will be a new /dev/freefall misc device for the platforms that
> > > 
> > > And this is wrong! There should not be any /dev/freefall device
> > > connected with signal host notify. /dev/freefall is for hardware which
> > > supports free fall hdd detection.
> 
> On the principle, I agree. But let's be realistic: this device will be
> created but no events will be generated from it.

And I think this is a problem. This provides false information to kernel
and also to userspace applications that there is working free fall
sensor (even there is not).

> It's a capability for the chip to provide freefall,

That it is not truth. Not every chip has it. Platform data are there to
provides this information for driver, if HW has freefall capability or
not.

> so I don't see why it's such an issue to
> have one created which says nothing. (talking about non Dell platforms
> here too)
> 
> > > 
> > > > don't have the irq set *and* if the device is on a Host Notify capable
> > > > adapter, currently only i2c-i801.
> > > 
> > > I understood, but in future more bus drivers could support host notify.
> > 
> > This is really fragile. lis3lv02d will empty IRQ (0) will work on some
> > i2c buses and on some not. I would really expect that i2c driver
> > (lis3lv02d) will work in same way with any i2c bus driver. And not that
> > on i801 will acts differently as on e.g. omap3 i2c bus.
> 
> I really don't follow you here. On a bus with no Host Notify, the IRQ
> will be 0 and it will work in the same way.

That it OK.

> On a bus with Host Notify,
> the IRQ should be set to something negative in the i2c_board_info

Not only in i2c_board_info but also in DTS. Which means every one DTS
needs to be updates -- also those outside of linux kernel. Which is for
me wrong.

> to be
> sure to not have an Host Notify irq assigned. In both case the
> lis3lv02d_i2c driver will just do:
> 	if (client->irq > 0)
> 		lis3_dev.irq = client->irq;
> 
> So there is no bus adapter specifics in the driver.
> 
> > 
> > > This is basically incorrect if we use one property for two different
> > > things (host notify and hdd free fall).
> 
> Host Notify is a way for a I2C device to report an interrupt without
> having a dedicated line assigned (and so an IRQ).

Yes. But lis3lv02d i2c devices which I have uses dedicated IRQ. They
does not work in way like you describe.

> So the chip could use
> Host Notify to report hdd free fall if it supports the feature.

Old existing HW could not. As those were not designed for such purpose.

Yes, new HW can be designed in this way, but linux kernel should not
drop (or modify) correct support for old HW devices just because there
is new HW design.

> > > 
> > > For me it looks like that we should separate these two things into two
> > > IRQ properties. It is really wrong design if one property is used for
> > > two different things.
> 
> I won't say the design is wrong because Host Notify really is just an
> IRQ.

Yes it is IRQ, but different. And lis3lv02d does not issue host notify
IRQ, so it should not be assigned to lis3lv02d.

> Where the issue lies now is that lis3lv02d makes the assumption
> that an irq attached to an i2c_client means that it will report
> freefall.

Yes.

> It was correct before, but now it's not true anymore.

Agree.

> So maybe this series should also add a way to provide the source of
> the IRQ (Host Notify or ACPI or DT). Then, lis3lv02d could ignore or
> not the incoming IRQ.

Yes, this is an option how to fix this problem.

I would rather introduce new IRQ property in both DTS and lis3lv02d
platform data (e.g. irq-freefall) which will unambiguously identify
freefall IRQ.

But I do not think it should be part of my Dell patch. It is
independent fix for lis3lv02d driver for bug which was introduced by
commit 4d5538f5882a.

> 
> Cheers,
> Benjamin
> 
> > > 
> > > > But given that they are DT and not
> > > > ACPI, this won't conflict with dell-smo8800, so there won't be any
> > > > errors, just a dangling unused device node.
> > > 
> > > Yes, for upcoming Dell in this patch (with IRQ -1) it is not a problem.
> > > 
> > > > This approach is IMO the best if you want to have this in the kernel.
> > > > 
> > > > Cheers,
> > > > Benjamin
> > > 
> > 
> > -- 
> > Pali Rohár
> > pali.rohar@gmail.com

-- 
Pali Rohár
pali.rohar@gmail.com

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Benjamin Tissoires]

On Jan 04 2017 or thereabouts, Pali Rohár wrote:
> On Wednesday 04 January 2017 14:02:52 Benjamin Tissoires wrote:
> > > > > No. DT platforms won't have an issue: they don't change anything, and
> > > > > there will be a new /dev/freefall misc device for the platforms that
> > > > 
> > > > And this is wrong! There should not be any /dev/freefall device
> > > > connected with signal host notify. /dev/freefall is for hardware which
> > > > supports free fall hdd detection.
> > 
> > On the principle, I agree. But let's be realistic: this device will be
> > created but no events will be generated from it.
> 
> And I think this is a problem. This provides false information to kernel
> and also to userspace applications that there is working free fall
> sensor (even there is not).
> 
> > It's a capability for the chip to provide freefall,
> 
> That it is not truth. Not every chip has it. Platform data are there to
> provides this information for driver, if HW has freefall capability or
> not.
> 
> > so I don't see why it's such an issue to
> > have one created which says nothing. (talking about non Dell platforms
> > here too)
> > 
> > > > 
> > > > > don't have the irq set *and* if the device is on a Host Notify capable
> > > > > adapter, currently only i2c-i801.
> > > > 
> > > > I understood, but in future more bus drivers could support host notify.
> > > 
> > > This is really fragile. lis3lv02d will empty IRQ (0) will work on some
> > > i2c buses and on some not. I would really expect that i2c driver
> > > (lis3lv02d) will work in same way with any i2c bus driver. And not that
> > > on i801 will acts differently as on e.g. omap3 i2c bus.
> > 
> > I really don't follow you here. On a bus with no Host Notify, the IRQ
> > will be 0 and it will work in the same way.
> 
> That it OK.
> 
> > On a bus with Host Notify,
> > the IRQ should be set to something negative in the i2c_board_info
> 
> Not only in i2c_board_info but also in DTS. Which means every one DTS
> needs to be updates -- also those outside of linux kernel. Which is for
> me wrong.
> 
> > to be
> > sure to not have an Host Notify irq assigned. In both case the
> > lis3lv02d_i2c driver will just do:
> > 	if (client->irq > 0)
> > 		lis3_dev.irq = client->irq;
> > 
> > So there is no bus adapter specifics in the driver.
> > 
> > > 
> > > > This is basically incorrect if we use one property for two different
> > > > things (host notify and hdd free fall).
> > 
> > Host Notify is a way for a I2C device to report an interrupt without
> > having a dedicated line assigned (and so an IRQ).
> 
> Yes. But lis3lv02d i2c devices which I have uses dedicated IRQ. They
> does not work in way like you describe.
> 
> > So the chip could use
> > Host Notify to report hdd free fall if it supports the feature.
> 
> Old existing HW could not. As those were not designed for such purpose.
> 
> Yes, new HW can be designed in this way, but linux kernel should not
> drop (or modify) correct support for old HW devices just because there
> is new HW design.

I never said we should drop support of old hardware. I was just
explaining what is Host Notify and saying that it is not incompatible
with lis3lv02d. 

> 
> > > > 
> > > > For me it looks like that we should separate these two things into two
> > > > IRQ properties. It is really wrong design if one property is used for
> > > > two different things.
> > 
> > I won't say the design is wrong because Host Notify really is just an
> > IRQ.
> 
> Yes it is IRQ, but different. And lis3lv02d does not issue host notify
> IRQ, so it should not be assigned to lis3lv02d.

Sigh.

> 
> > Where the issue lies now is that lis3lv02d makes the assumption
> > that an irq attached to an i2c_client means that it will report
> > freefall.
> 
> Yes.
> 
> > It was correct before, but now it's not true anymore.
> 
> Agree.
> 
> > So maybe this series should also add a way to provide the source of
> > the IRQ (Host Notify or ACPI or DT). Then, lis3lv02d could ignore or
> > not the incoming IRQ.
> 
> Yes, this is an option how to fix this problem.

How about:
---
>From daa7571bbf337704332c0cfeec9b8fd5aeae596f Mon Sep 17 00:00:00 2001
From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Date: Wed, 4 Jan 2017 18:26:54 +0100
Subject: [PATCH] I2C: add the source of the IRQ in struct i2c_client

With commit 4d5538f5882a ("i2c: use an IRQ to report Host Notify events,
not alert"), the IRQ provided in struct i2c_client might be assigned while
it has not been explicitly declared by either the platform information
or OF or ACPI.
Some drivers (lis3lv02d) rely on the fact that the IRQ gets assigned or
not to trigger a different behavior (exposing /dev/freefall in this case).

Provide a way for others to know who set the IRQ and so they can behave
accordingly.

Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
 drivers/i2c/i2c-core.c |  7 +++++++
 include/linux/i2c.h    | 11 +++++++++++
 2 files changed, 18 insertions(+)

diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index cf9e396..226c75d 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -935,8 +935,12 @@ static int i2c_device_probe(struct device *dev)
 			irq = of_irq_get_byname(dev->of_node, "irq");
 			if (irq == -EINVAL || irq == -ENODATA)
 				irq = of_irq_get(dev->of_node, 0);
+			if (irq > 0)
+				client->irq_source = I2C_IRQ_SOURCE_OF;
 		} else if (ACPI_COMPANION(dev)) {
 			irq = acpi_dev_gpio_irq_get(ACPI_COMPANION(dev), 0);
+			if (irq > 0)
+				client->irq_source = I2C_IRQ_SOURCE_ACPI;
 		}
 		if (irq == -EPROBE_DEFER)
 			return irq;
@@ -947,6 +951,8 @@ static int i2c_device_probe(struct device *dev)
 		if (irq < 0) {
 			dev_dbg(dev, "Using Host Notify IRQ\n");
 			irq = i2c_smbus_host_notify_to_irq(client);
+			if (irq > 0)
+				client->irq_source = I2C_IRQ_SOURCE_HOST_NOTIFY;
 		}
 		if (irq < 0)
 			irq = 0;
@@ -1317,6 +1323,7 @@ i2c_new_device(struct i2c_adapter *adap, struct i2c_board_info const *info)
 	client->flags = info->flags;
 	client->addr = info->addr;
 	client->irq = info->irq;
+	client->irq_source = I2C_IRQ_SOURCE_PLATFORM;
 
 	strlcpy(client->name, info->type, sizeof(client->name));
 
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index b2109c5..7d0368d 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -213,6 +213,13 @@ struct i2c_driver {
 };
 #define to_i2c_driver(d) container_of(d, struct i2c_driver, driver)
 
+enum i2c_irq_source {
+	I2C_IRQ_SOURCE_PLATFORM,
+	I2C_IRQ_SOURCE_OF,
+	I2C_IRQ_SOURCE_ACPI,
+	I2C_IRQ_SOURCE_HOST_NOTIFY,
+};
+
 /**
  * struct i2c_client - represent an I2C slave device
  * @flags: I2C_CLIENT_TEN indicates the device uses a ten bit chip address;
@@ -227,6 +234,9 @@ struct i2c_driver {
  *	userspace_devices list
  * @slave_cb: Callback when I2C slave mode of an adapter is used. The adapter
  *	calls it to pass on slave events to the slave driver.
+ * @irq_source: Enum which provides the source of the IRQ. Useful to know
+ * 	if the IRQ was issued from Host Notify or if it was provided by an other
+ * 	component.
  *
  * An i2c_client identifies a single device (i.e. chip) connected to an
  * i2c bus. The behaviour exposed to Linux is defined by the driver
@@ -245,6 +255,7 @@ struct i2c_client {
 #if IS_ENABLED(CONFIG_I2C_SLAVE)
 	i2c_slave_cb_t slave_cb;	/* callback for slave mode	*/
 #endif
+	enum i2c_irq_source irq_source;	/* which component assigned the irq */
 };
 #define to_i2c_client(d) container_of(d, struct i2c_client, dev)
 
-- 
2.9.3
---

Dmitry, Wolfram, Jean, would this be acceptable for you?

> 
> I would rather introduce new IRQ property in both DTS and lis3lv02d
> platform data (e.g. irq-freefall) which will unambiguously identify
> freefall IRQ.

Sigh. You asked above to not break existing DT bindings, so I don't
understand why you suddenly want to change every bindings by introducing
a change which breaks backward compatibility.

> 
> But I do not think it should be part of my Dell patch. It is
> independent fix for lis3lv02d driver for bug which was introduced by
> commit 4d5538f5882a.

It's not part of the dell patch, but it can be part of the series you
are about to send. Please remember that the current state is that there
is no breakage (only a spurious /dev/freefall which you are not happy
about). The only breakage is with your patch, so it doesn't hurt to have
both sent together so you can control all the requirements at once.
So please incorporate my patch in your series if Wolfram, Jean and Dmitry
agree, and also add the fix in lis3lv02d_i2c to make use of the IRQ source.

Cheers,
Benjamin

> 
> > 
> > Cheers,
> > Benjamin
> > 
> > > > 
> > > > > But given that they are DT and not
> > > > > ACPI, this won't conflict with dell-smo8800, so there won't be any
> > > > > errors, just a dangling unused device node.
> > > > 
> > > > Yes, for upcoming Dell in this patch (with IRQ -1) it is not a problem.
> > > > 
> > > > > This approach is IMO the best if you want to have this in the kernel.
> > > > > 
> > > > > Cheers,
> > > > > Benjamin
> > > > 
> > > 
> > > -- 
> > > Pali Rohár
> > > pali.rohar@gmail.com
> 
> -- 
> Pali Rohár
> pali.rohar@gmail.com

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Wolfram Sang]

> How about:
> ---
> From daa7571bbf337704332c0cfeec9b8fd5aeae596f Mon Sep 17 00:00:00 2001
> From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> Date: Wed, 4 Jan 2017 18:26:54 +0100
> Subject: [PATCH] I2C: add the source of the IRQ in struct i2c_client
> 
> With commit 4d5538f5882a ("i2c: use an IRQ to report Host Notify events,
> not alert"), the IRQ provided in struct i2c_client might be assigned while
> it has not been explicitly declared by either the platform information
> or OF or ACPI.
> Some drivers (lis3lv02d) rely on the fact that the IRQ gets assigned or
> not to trigger a different behavior (exposing /dev/freefall in this case).
> 
> Provide a way for others to know who set the IRQ and so they can behave
> accordingly.
> 
> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> ---
>  drivers/i2c/i2c-core.c |  7 +++++++
>  include/linux/i2c.h    | 11 +++++++++++
>  2 files changed, 18 insertions(+)
> 
> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> index cf9e396..226c75d 100644
> --- a/drivers/i2c/i2c-core.c
> +++ b/drivers/i2c/i2c-core.c
> @@ -935,8 +935,12 @@ static int i2c_device_probe(struct device *dev)
>  			irq = of_irq_get_byname(dev->of_node, "irq");
>  			if (irq == -EINVAL || irq == -ENODATA)
>  				irq = of_irq_get(dev->of_node, 0);
> +			if (irq > 0)
> +				client->irq_source = I2C_IRQ_SOURCE_OF;
>  		} else if (ACPI_COMPANION(dev)) {
>  			irq = acpi_dev_gpio_irq_get(ACPI_COMPANION(dev), 0);
> +			if (irq > 0)
> +				client->irq_source = I2C_IRQ_SOURCE_ACPI;
>  		}
>  		if (irq == -EPROBE_DEFER)
>  			return irq;
> @@ -947,6 +951,8 @@ static int i2c_device_probe(struct device *dev)
>  		if (irq < 0) {
>  			dev_dbg(dev, "Using Host Notify IRQ\n");
>  			irq = i2c_smbus_host_notify_to_irq(client);
> +			if (irq > 0)
> +				client->irq_source = I2C_IRQ_SOURCE_HOST_NOTIFY;
>  		}
>  		if (irq < 0)
>  			irq = 0;
> @@ -1317,6 +1323,7 @@ i2c_new_device(struct i2c_adapter *adap, struct i2c_board_info const *info)
>  	client->flags = info->flags;
>  	client->addr = info->addr;
>  	client->irq = info->irq;
> +	client->irq_source = I2C_IRQ_SOURCE_PLATFORM;
>  
>  	strlcpy(client->name, info->type, sizeof(client->name));
>  
> diff --git a/include/linux/i2c.h b/include/linux/i2c.h
> index b2109c5..7d0368d 100644
> --- a/include/linux/i2c.h
> +++ b/include/linux/i2c.h
> @@ -213,6 +213,13 @@ struct i2c_driver {
>  };
>  #define to_i2c_driver(d) container_of(d, struct i2c_driver, driver)
>  
> +enum i2c_irq_source {
> +	I2C_IRQ_SOURCE_PLATFORM,
> +	I2C_IRQ_SOURCE_OF,
> +	I2C_IRQ_SOURCE_ACPI,
> +	I2C_IRQ_SOURCE_HOST_NOTIFY,
> +};
> +
>  /**
>   * struct i2c_client - represent an I2C slave device
>   * @flags: I2C_CLIENT_TEN indicates the device uses a ten bit chip address;
> @@ -227,6 +234,9 @@ struct i2c_driver {
>   *	userspace_devices list
>   * @slave_cb: Callback when I2C slave mode of an adapter is used. The adapter
>   *	calls it to pass on slave events to the slave driver.
> + * @irq_source: Enum which provides the source of the IRQ. Useful to know
> + * 	if the IRQ was issued from Host Notify or if it was provided by an other
> + * 	component.

I'd think some documentation somewhere makes sense why we need to
distinguish this in some cases?

>   *
>   * An i2c_client identifies a single device (i.e. chip) connected to an
>   * i2c bus. The behaviour exposed to Linux is defined by the driver
> @@ -245,6 +255,7 @@ struct i2c_client {
>  #if IS_ENABLED(CONFIG_I2C_SLAVE)
>  	i2c_slave_cb_t slave_cb;	/* callback for slave mode	*/
>  #endif
> +	enum i2c_irq_source irq_source;	/* which component assigned the irq */
>  };
>  #define to_i2c_client(d) container_of(d, struct i2c_client, dev)
> 
> Dmitry, Wolfram, Jean, would this be acceptable for you?

Adding something to i2c_driver is not exactly cheap, but from what I
glimpsed from this thread, this is one of the cleanest solution to this
problem?

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Dmitry Torokhov]

On Wed, Jan 04, 2017 at 06:46:19PM +0100, Wolfram Sang wrote:
> 
> > How about:
> > ---
> > From daa7571bbf337704332c0cfeec9b8fd5aeae596f Mon Sep 17 00:00:00 2001
> > From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> > Date: Wed, 4 Jan 2017 18:26:54 +0100
> > Subject: [PATCH] I2C: add the source of the IRQ in struct i2c_client
> > 
> > With commit 4d5538f5882a ("i2c: use an IRQ to report Host Notify events,
> > not alert"), the IRQ provided in struct i2c_client might be assigned while
> > it has not been explicitly declared by either the platform information
> > or OF or ACPI.
> > Some drivers (lis3lv02d) rely on the fact that the IRQ gets assigned or
> > not to trigger a different behavior (exposing /dev/freefall in this case).
> > 
> > Provide a way for others to know who set the IRQ and so they can behave
> > accordingly.
> > 
> > Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> > ---
> >  drivers/i2c/i2c-core.c |  7 +++++++
> >  include/linux/i2c.h    | 11 +++++++++++
> >  2 files changed, 18 insertions(+)
> > 
> > diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> > index cf9e396..226c75d 100644
> > --- a/drivers/i2c/i2c-core.c
> > +++ b/drivers/i2c/i2c-core.c
> > @@ -935,8 +935,12 @@ static int i2c_device_probe(struct device *dev)
> >  			irq = of_irq_get_byname(dev->of_node, "irq");
> >  			if (irq == -EINVAL || irq == -ENODATA)
> >  				irq = of_irq_get(dev->of_node, 0);
> > +			if (irq > 0)
> > +				client->irq_source = I2C_IRQ_SOURCE_OF;
> >  		} else if (ACPI_COMPANION(dev)) {
> >  			irq = acpi_dev_gpio_irq_get(ACPI_COMPANION(dev), 0);
> > +			if (irq > 0)
> > +				client->irq_source = I2C_IRQ_SOURCE_ACPI;
> >  		}
> >  		if (irq == -EPROBE_DEFER)
> >  			return irq;
> > @@ -947,6 +951,8 @@ static int i2c_device_probe(struct device *dev)
> >  		if (irq < 0) {
> >  			dev_dbg(dev, "Using Host Notify IRQ\n");
> >  			irq = i2c_smbus_host_notify_to_irq(client);
> > +			if (irq > 0)
> > +				client->irq_source = I2C_IRQ_SOURCE_HOST_NOTIFY;
> >  		}
> >  		if (irq < 0)
> >  			irq = 0;
> > @@ -1317,6 +1323,7 @@ i2c_new_device(struct i2c_adapter *adap, struct i2c_board_info const *info)
> >  	client->flags = info->flags;
> >  	client->addr = info->addr;
> >  	client->irq = info->irq;
> > +	client->irq_source = I2C_IRQ_SOURCE_PLATFORM;
> >  
> >  	strlcpy(client->name, info->type, sizeof(client->name));
> >  
> > diff --git a/include/linux/i2c.h b/include/linux/i2c.h
> > index b2109c5..7d0368d 100644
> > --- a/include/linux/i2c.h
> > +++ b/include/linux/i2c.h
> > @@ -213,6 +213,13 @@ struct i2c_driver {
> >  };
> >  #define to_i2c_driver(d) container_of(d, struct i2c_driver, driver)
> >  
> > +enum i2c_irq_source {
> > +	I2C_IRQ_SOURCE_PLATFORM,
> > +	I2C_IRQ_SOURCE_OF,
> > +	I2C_IRQ_SOURCE_ACPI,
> > +	I2C_IRQ_SOURCE_HOST_NOTIFY,
> > +};
> > +
> >  /**
> >   * struct i2c_client - represent an I2C slave device
> >   * @flags: I2C_CLIENT_TEN indicates the device uses a ten bit chip address;
> > @@ -227,6 +234,9 @@ struct i2c_driver {
> >   *	userspace_devices list
> >   * @slave_cb: Callback when I2C slave mode of an adapter is used. The adapter
> >   *	calls it to pass on slave events to the slave driver.
> > + * @irq_source: Enum which provides the source of the IRQ. Useful to know
> > + * 	if the IRQ was issued from Host Notify or if it was provided by an other
> > + * 	component.
> 
> I'd think some documentation somewhere makes sense why we need to
> distinguish this in some cases?

I'd rather drivers be oblivious of the source of interrupt. If they need
to distinguish between them that means that our IRQ abstration failed.

> 
> >   *
> >   * An i2c_client identifies a single device (i.e. chip) connected to an
> >   * i2c bus. The behaviour exposed to Linux is defined by the driver
> > @@ -245,6 +255,7 @@ struct i2c_client {
> >  #if IS_ENABLED(CONFIG_I2C_SLAVE)
> >  	i2c_slave_cb_t slave_cb;	/* callback for slave mode	*/
> >  #endif
> > +	enum i2c_irq_source irq_source;	/* which component assigned the irq */
> >  };
> >  #define to_i2c_client(d) container_of(d, struct i2c_client, dev)
> > 
> > Dmitry, Wolfram, Jean, would this be acceptable for you?
> 
> Adding something to i2c_driver is not exactly cheap, but from what I
> glimpsed from this thread, this is one of the cleanest solution to this
> problem?
> 

As Benjamin said, it is really property of device [instance], not
driver. I.e. driver could handle both wired IRQ and HostNotify-based
scheme similarly, it is device (and board) that knows how stuff is
connected.

Maybe we could do something like this (untested):


>From e362a0277fd1bd6112f258664d8831d9bc6b78da Mon Sep 17 00:00:00 2001
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date: Wed, 4 Jan 2017 09:33:43 -0800
Subject: [PATCH] i2c: do not enable fall back to Host Notify by default

Falling back unconditionally to HostNotify as primary client's interrupt
breaks some drivers which alter their functionality depending on whether
interrupt is present or not, so let's introduce a board flag telling I2C
core explicitly if we want wired interrupt or HostNotify-based one:
I2C_CLIENT_HOST_NOTIFY.

For DT-based systems we introduce "host-notofy" property that we convert
to I2C_CLIENT_HOST_NOTIFY board flag.

Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
 Documentation/devicetree/bindings/i2c/i2c.txt |  8 ++++++++
 drivers/i2c/i2c-core.c                        | 17 ++++++++---------
 include/linux/i2c.h                           |  1 +
 3 files changed, 17 insertions(+), 9 deletions(-)

diff --git a/Documentation/devicetree/bindings/i2c/i2c.txt b/Documentation/devicetree/bindings/i2c/i2c.txt
index 5fa691e6f638..cee9d5055fa2 100644
--- a/Documentation/devicetree/bindings/i2c/i2c.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c.txt
@@ -62,6 +62,9 @@ wants to support one of the below features, it should adapt the bindings below.
 	"irq" and "wakeup" names are recognized by I2C core, other names are
 	left to individual drivers.
 
+- host-notify
+	device uses SMBus host notify protocol instead of interrupt line.
+
 - multi-master
 	states that there is another master active on this bus. The OS can use
 	this information to adapt power management to keep the arbitration awake
@@ -81,6 +84,11 @@ Binding may contain optional "interrupts" property, describing interrupts
 used by the device. I2C core will assign "irq" interrupt (or the very first
 interrupt if not using interrupt names) as primary interrupt for the slave.
 
+Alternatively, devices supporting SMbus Host Notify, and connected to
+adapters that support this feature, may use "host-notify" property. I2C
+core will create a virtual interrupt for Host Notify and assign it as
+primary interrupt for the slave.
+
 Also, if device is marked as a wakeup source, I2C core will set up "wakeup"
 interrupt for the device. If "wakeup" interrupt name is not present in the
 binding, then primary interrupt will be used as wakeup interrupt.
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index cf9e396d7702..250969fa7670 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -931,7 +931,10 @@ static int i2c_device_probe(struct device *dev)
 	if (!client->irq) {
 		int irq = -ENOENT;
 
-		if (dev->of_node) {
+		if (client->flags & I2C_CLIENT_HOST_HOTIFY) {
+			dev_dbg(dev, "Using Host Notify IRQ\n");
+			irq = i2c_smbus_host_notify_to_irq(client);
+		} else if (dev->of_node) {
 			irq = of_irq_get_byname(dev->of_node, "irq");
 			if (irq == -EINVAL || irq == -ENODATA)
 				irq = of_irq_get(dev->of_node, 0);
@@ -940,14 +943,7 @@ static int i2c_device_probe(struct device *dev)
 		}
 		if (irq == -EPROBE_DEFER)
 			return irq;
-		/*
-		 * ACPI and OF did not find any useful IRQ, try to see
-		 * if Host Notify can be used.
-		 */
-		if (irq < 0) {
-			dev_dbg(dev, "Using Host Notify IRQ\n");
-			irq = i2c_smbus_host_notify_to_irq(client);
-		}
+
 		if (irq < 0)
 			irq = 0;
 
@@ -1716,6 +1712,9 @@ static struct i2c_client *of_i2c_register_device(struct i2c_adapter *adap,
 	info.of_node = of_node_get(node);
 	info.archdata = &dev_ad;
 
+	if (of_read_property_bool(node, "host-notify"))
+		info.flags |= I2C_CLIENT_HOST_NOTIFY;
+
 	if (of_get_property(node, "wakeup-source", NULL))
 		info.flags |= I2C_CLIENT_WAKE;
 
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index b2109c522dec..4b45ec46161f 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -665,6 +665,7 @@ i2c_unlock_adapter(struct i2c_adapter *adapter)
 #define I2C_CLIENT_TEN		0x10	/* we have a ten bit chip address */
 					/* Must equal I2C_M_TEN below */
 #define I2C_CLIENT_SLAVE	0x20	/* we are the slave */
+#define I2C_CLIENT_HOST_NOTIFY	0x40	/* We want to use I2C host notify */
 #define I2C_CLIENT_WAKE		0x80	/* for board_info; true iff can wake */
 #define I2C_CLIENT_SCCB		0x9000	/* Use Omnivision SCCB protocol */
 					/* Must match I2C_M_STOP|IGNORE_NAK */
-- 
2.11.0.390.gc69c2f50cf-goog


-- 
Dmitry

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Benjamin Tissoires]

On Jan 04 2017 or thereabouts, Dmitry Torokhov wrote:
> On Wed, Jan 04, 2017 at 06:46:19PM +0100, Wolfram Sang wrote:
> > 
> > > How about:
> > > ---
> > > From daa7571bbf337704332c0cfeec9b8fd5aeae596f Mon Sep 17 00:00:00 2001
> > > From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> > > Date: Wed, 4 Jan 2017 18:26:54 +0100
> > > Subject: [PATCH] I2C: add the source of the IRQ in struct i2c_client
> > > 
> > > With commit 4d5538f5882a ("i2c: use an IRQ to report Host Notify events,
> > > not alert"), the IRQ provided in struct i2c_client might be assigned while
> > > it has not been explicitly declared by either the platform information
> > > or OF or ACPI.
> > > Some drivers (lis3lv02d) rely on the fact that the IRQ gets assigned or
> > > not to trigger a different behavior (exposing /dev/freefall in this case).
> > > 
> > > Provide a way for others to know who set the IRQ and so they can behave
> > > accordingly.
> > > 
> > > Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> > > ---
> > >  drivers/i2c/i2c-core.c |  7 +++++++
> > >  include/linux/i2c.h    | 11 +++++++++++
> > >  2 files changed, 18 insertions(+)
> > > 
> > > diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> > > index cf9e396..226c75d 100644
> > > --- a/drivers/i2c/i2c-core.c
> > > +++ b/drivers/i2c/i2c-core.c
> > > @@ -935,8 +935,12 @@ static int i2c_device_probe(struct device *dev)
> > >  			irq = of_irq_get_byname(dev->of_node, "irq");
> > >  			if (irq == -EINVAL || irq == -ENODATA)
> > >  				irq = of_irq_get(dev->of_node, 0);
> > > +			if (irq > 0)
> > > +				client->irq_source = I2C_IRQ_SOURCE_OF;
> > >  		} else if (ACPI_COMPANION(dev)) {
> > >  			irq = acpi_dev_gpio_irq_get(ACPI_COMPANION(dev), 0);
> > > +			if (irq > 0)
> > > +				client->irq_source = I2C_IRQ_SOURCE_ACPI;
> > >  		}
> > >  		if (irq == -EPROBE_DEFER)
> > >  			return irq;
> > > @@ -947,6 +951,8 @@ static int i2c_device_probe(struct device *dev)
> > >  		if (irq < 0) {
> > >  			dev_dbg(dev, "Using Host Notify IRQ\n");
> > >  			irq = i2c_smbus_host_notify_to_irq(client);
> > > +			if (irq > 0)
> > > +				client->irq_source = I2C_IRQ_SOURCE_HOST_NOTIFY;
> > >  		}
> > >  		if (irq < 0)
> > >  			irq = 0;
> > > @@ -1317,6 +1323,7 @@ i2c_new_device(struct i2c_adapter *adap, struct i2c_board_info const *info)
> > >  	client->flags = info->flags;
> > >  	client->addr = info->addr;
> > >  	client->irq = info->irq;
> > > +	client->irq_source = I2C_IRQ_SOURCE_PLATFORM;
> > >  
> > >  	strlcpy(client->name, info->type, sizeof(client->name));
> > >  
> > > diff --git a/include/linux/i2c.h b/include/linux/i2c.h
> > > index b2109c5..7d0368d 100644
> > > --- a/include/linux/i2c.h
> > > +++ b/include/linux/i2c.h
> > > @@ -213,6 +213,13 @@ struct i2c_driver {
> > >  };
> > >  #define to_i2c_driver(d) container_of(d, struct i2c_driver, driver)
> > >  
> > > +enum i2c_irq_source {
> > > +	I2C_IRQ_SOURCE_PLATFORM,
> > > +	I2C_IRQ_SOURCE_OF,
> > > +	I2C_IRQ_SOURCE_ACPI,
> > > +	I2C_IRQ_SOURCE_HOST_NOTIFY,
> > > +};
> > > +
> > >  /**
> > >   * struct i2c_client - represent an I2C slave device
> > >   * @flags: I2C_CLIENT_TEN indicates the device uses a ten bit chip address;
> > > @@ -227,6 +234,9 @@ struct i2c_driver {
> > >   *	userspace_devices list
> > >   * @slave_cb: Callback when I2C slave mode of an adapter is used. The adapter
> > >   *	calls it to pass on slave events to the slave driver.
> > > + * @irq_source: Enum which provides the source of the IRQ. Useful to know
> > > + * 	if the IRQ was issued from Host Notify or if it was provided by an other
> > > + * 	component.
> > 
> > I'd think some documentation somewhere makes sense why we need to
> > distinguish this in some cases?
> 
> I'd rather drivers be oblivious of the source of interrupt. If they need
> to distinguish between them that means that our IRQ abstration failed.
> 
> > 
> > >   *
> > >   * An i2c_client identifies a single device (i.e. chip) connected to an
> > >   * i2c bus. The behaviour exposed to Linux is defined by the driver
> > > @@ -245,6 +255,7 @@ struct i2c_client {
> > >  #if IS_ENABLED(CONFIG_I2C_SLAVE)
> > >  	i2c_slave_cb_t slave_cb;	/* callback for slave mode	*/
> > >  #endif
> > > +	enum i2c_irq_source irq_source;	/* which component assigned the irq */
> > >  };
> > >  #define to_i2c_client(d) container_of(d, struct i2c_client, dev)
> > > 
> > > Dmitry, Wolfram, Jean, would this be acceptable for you?
> > 
> > Adding something to i2c_driver is not exactly cheap, but from what I
> > glimpsed from this thread, this is one of the cleanest solution to this
> > problem?
> > 
> 
> As Benjamin said, it is really property of device [instance], not
> driver. I.e. driver could handle both wired IRQ and HostNotify-based
> scheme similarly, it is device (and board) that knows how stuff is
> connected.
> 
> Maybe we could do something like this (untested):
> 
> 
> From e362a0277fd1bd6112f258664d8831d9bc6b78da Mon Sep 17 00:00:00 2001
> From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Date: Wed, 4 Jan 2017 09:33:43 -0800
> Subject: [PATCH] i2c: do not enable fall back to Host Notify by default
> 
> Falling back unconditionally to HostNotify as primary client's interrupt
> breaks some drivers which alter their functionality depending on whether
> interrupt is present or not, so let's introduce a board flag telling I2C
> core explicitly if we want wired interrupt or HostNotify-based one:
> I2C_CLIENT_HOST_NOTIFY.
> 
> For DT-based systems we introduce "host-notofy" property that we convert

typo: s/host-notofy/host-notify/

> to I2C_CLIENT_HOST_NOTIFY board flag.
> 
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> ---
>  Documentation/devicetree/bindings/i2c/i2c.txt |  8 ++++++++
>  drivers/i2c/i2c-core.c                        | 17 ++++++++---------
>  include/linux/i2c.h                           |  1 +
>  3 files changed, 17 insertions(+), 9 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/i2c/i2c.txt b/Documentation/devicetree/bindings/i2c/i2c.txt
> index 5fa691e6f638..cee9d5055fa2 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c.txt
> +++ b/Documentation/devicetree/bindings/i2c/i2c.txt
> @@ -62,6 +62,9 @@ wants to support one of the below features, it should adapt the bindings below.
>  	"irq" and "wakeup" names are recognized by I2C core, other names are
>  	left to individual drivers.
>  
> +- host-notify
> +	device uses SMBus host notify protocol instead of interrupt line.
> +
>  - multi-master
>  	states that there is another master active on this bus. The OS can use
>  	this information to adapt power management to keep the arbitration awake
> @@ -81,6 +84,11 @@ Binding may contain optional "interrupts" property, describing interrupts
>  used by the device. I2C core will assign "irq" interrupt (or the very first
>  interrupt if not using interrupt names) as primary interrupt for the slave.
>  
> +Alternatively, devices supporting SMbus Host Notify, and connected to
> +adapters that support this feature, may use "host-notify" property. I2C
> +core will create a virtual interrupt for Host Notify and assign it as
> +primary interrupt for the slave.
> +
>  Also, if device is marked as a wakeup source, I2C core will set up "wakeup"
>  interrupt for the device. If "wakeup" interrupt name is not present in the
>  binding, then primary interrupt will be used as wakeup interrupt.
> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> index cf9e396d7702..250969fa7670 100644
> --- a/drivers/i2c/i2c-core.c
> +++ b/drivers/i2c/i2c-core.c
> @@ -931,7 +931,10 @@ static int i2c_device_probe(struct device *dev)
>  	if (!client->irq) {
>  		int irq = -ENOENT;
>  
> -		if (dev->of_node) {
> +		if (client->flags & I2C_CLIENT_HOST_HOTIFY) {

typo: s/I2C_CLIENT_HOST_HOTIFY/I2C_CLIENT_HOST_NOTIFY/

With these fixed, the code is:
Tested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>

I tested both with and without the I2C_CLIENT_HOST_HOTIFY flag on the
Thinkpad T450s, and everything is in order.

Thanks Dmitry for the patch!

Cheers,
Benjamin


> +			dev_dbg(dev, "Using Host Notify IRQ\n");
> +			irq = i2c_smbus_host_notify_to_irq(client);
> +		} else if (dev->of_node) {
>  			irq = of_irq_get_byname(dev->of_node, "irq");
>  			if (irq == -EINVAL || irq == -ENODATA)
>  				irq = of_irq_get(dev->of_node, 0);
> @@ -940,14 +943,7 @@ static int i2c_device_probe(struct device *dev)
>  		}
>  		if (irq == -EPROBE_DEFER)
>  			return irq;
> -		/*
> -		 * ACPI and OF did not find any useful IRQ, try to see
> -		 * if Host Notify can be used.
> -		 */
> -		if (irq < 0) {
> -			dev_dbg(dev, "Using Host Notify IRQ\n");
> -			irq = i2c_smbus_host_notify_to_irq(client);
> -		}
> +
>  		if (irq < 0)
>  			irq = 0;
>  
> @@ -1716,6 +1712,9 @@ static struct i2c_client *of_i2c_register_device(struct i2c_adapter *adap,
>  	info.of_node = of_node_get(node);
>  	info.archdata = &dev_ad;
>  
> +	if (of_read_property_bool(node, "host-notify"))
> +		info.flags |= I2C_CLIENT_HOST_NOTIFY;
> +
>  	if (of_get_property(node, "wakeup-source", NULL))
>  		info.flags |= I2C_CLIENT_WAKE;
>  
> diff --git a/include/linux/i2c.h b/include/linux/i2c.h
> index b2109c522dec..4b45ec46161f 100644
> --- a/include/linux/i2c.h
> +++ b/include/linux/i2c.h
> @@ -665,6 +665,7 @@ i2c_unlock_adapter(struct i2c_adapter *adapter)
>  #define I2C_CLIENT_TEN		0x10	/* we have a ten bit chip address */
>  					/* Must equal I2C_M_TEN below */
>  #define I2C_CLIENT_SLAVE	0x20	/* we are the slave */
> +#define I2C_CLIENT_HOST_NOTIFY	0x40	/* We want to use I2C host notify */
>  #define I2C_CLIENT_WAKE		0x80	/* for board_info; true iff can wake */
>  #define I2C_CLIENT_SCCB		0x9000	/* Use Omnivision SCCB protocol */
>  					/* Must match I2C_M_STOP|IGNORE_NAK */
> -- 
> 2.11.0.390.gc69c2f50cf-goog
> 
> 
> -- 
> Dmitry

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Dmitry Torokhov]

On Wed, Jan 04, 2017 at 10:49:06PM +0100, Benjamin Tissoires wrote:
> On Jan 04 2017 or thereabouts, Dmitry Torokhov wrote:
> > On Wed, Jan 04, 2017 at 06:46:19PM +0100, Wolfram Sang wrote:
> > > 
> > > > How about:
> > > > ---
> > > > From daa7571bbf337704332c0cfeec9b8fd5aeae596f Mon Sep 17 00:00:00 2001
> > > > From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> > > > Date: Wed, 4 Jan 2017 18:26:54 +0100
> > > > Subject: [PATCH] I2C: add the source of the IRQ in struct i2c_client
> > > > 
> > > > With commit 4d5538f5882a ("i2c: use an IRQ to report Host Notify events,
> > > > not alert"), the IRQ provided in struct i2c_client might be assigned while
> > > > it has not been explicitly declared by either the platform information
> > > > or OF or ACPI.
> > > > Some drivers (lis3lv02d) rely on the fact that the IRQ gets assigned or
> > > > not to trigger a different behavior (exposing /dev/freefall in this case).
> > > > 
> > > > Provide a way for others to know who set the IRQ and so they can behave
> > > > accordingly.
> > > > 
> > > > Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> > > > ---
> > > >  drivers/i2c/i2c-core.c |  7 +++++++
> > > >  include/linux/i2c.h    | 11 +++++++++++
> > > >  2 files changed, 18 insertions(+)
> > > > 
> > > > diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> > > > index cf9e396..226c75d 100644
> > > > --- a/drivers/i2c/i2c-core.c
> > > > +++ b/drivers/i2c/i2c-core.c
> > > > @@ -935,8 +935,12 @@ static int i2c_device_probe(struct device *dev)
> > > >  			irq = of_irq_get_byname(dev->of_node, "irq");
> > > >  			if (irq == -EINVAL || irq == -ENODATA)
> > > >  				irq = of_irq_get(dev->of_node, 0);
> > > > +			if (irq > 0)
> > > > +				client->irq_source = I2C_IRQ_SOURCE_OF;
> > > >  		} else if (ACPI_COMPANION(dev)) {
> > > >  			irq = acpi_dev_gpio_irq_get(ACPI_COMPANION(dev), 0);
> > > > +			if (irq > 0)
> > > > +				client->irq_source = I2C_IRQ_SOURCE_ACPI;
> > > >  		}
> > > >  		if (irq == -EPROBE_DEFER)
> > > >  			return irq;
> > > > @@ -947,6 +951,8 @@ static int i2c_device_probe(struct device *dev)
> > > >  		if (irq < 0) {
> > > >  			dev_dbg(dev, "Using Host Notify IRQ\n");
> > > >  			irq = i2c_smbus_host_notify_to_irq(client);
> > > > +			if (irq > 0)
> > > > +				client->irq_source = I2C_IRQ_SOURCE_HOST_NOTIFY;
> > > >  		}
> > > >  		if (irq < 0)
> > > >  			irq = 0;
> > > > @@ -1317,6 +1323,7 @@ i2c_new_device(struct i2c_adapter *adap, struct i2c_board_info const *info)
> > > >  	client->flags = info->flags;
> > > >  	client->addr = info->addr;
> > > >  	client->irq = info->irq;
> > > > +	client->irq_source = I2C_IRQ_SOURCE_PLATFORM;
> > > >  
> > > >  	strlcpy(client->name, info->type, sizeof(client->name));
> > > >  
> > > > diff --git a/include/linux/i2c.h b/include/linux/i2c.h
> > > > index b2109c5..7d0368d 100644
> > > > --- a/include/linux/i2c.h
> > > > +++ b/include/linux/i2c.h
> > > > @@ -213,6 +213,13 @@ struct i2c_driver {
> > > >  };
> > > >  #define to_i2c_driver(d) container_of(d, struct i2c_driver, driver)
> > > >  
> > > > +enum i2c_irq_source {
> > > > +	I2C_IRQ_SOURCE_PLATFORM,
> > > > +	I2C_IRQ_SOURCE_OF,
> > > > +	I2C_IRQ_SOURCE_ACPI,
> > > > +	I2C_IRQ_SOURCE_HOST_NOTIFY,
> > > > +};
> > > > +
> > > >  /**
> > > >   * struct i2c_client - represent an I2C slave device
> > > >   * @flags: I2C_CLIENT_TEN indicates the device uses a ten bit chip address;
> > > > @@ -227,6 +234,9 @@ struct i2c_driver {
> > > >   *	userspace_devices list
> > > >   * @slave_cb: Callback when I2C slave mode of an adapter is used. The adapter
> > > >   *	calls it to pass on slave events to the slave driver.
> > > > + * @irq_source: Enum which provides the source of the IRQ. Useful to know
> > > > + * 	if the IRQ was issued from Host Notify or if it was provided by an other
> > > > + * 	component.
> > > 
> > > I'd think some documentation somewhere makes sense why we need to
> > > distinguish this in some cases?
> > 
> > I'd rather drivers be oblivious of the source of interrupt. If they need
> > to distinguish between them that means that our IRQ abstration failed.
> > 
> > > 
> > > >   *
> > > >   * An i2c_client identifies a single device (i.e. chip) connected to an
> > > >   * i2c bus. The behaviour exposed to Linux is defined by the driver
> > > > @@ -245,6 +255,7 @@ struct i2c_client {
> > > >  #if IS_ENABLED(CONFIG_I2C_SLAVE)
> > > >  	i2c_slave_cb_t slave_cb;	/* callback for slave mode	*/
> > > >  #endif
> > > > +	enum i2c_irq_source irq_source;	/* which component assigned the irq */
> > > >  };
> > > >  #define to_i2c_client(d) container_of(d, struct i2c_client, dev)
> > > > 
> > > > Dmitry, Wolfram, Jean, would this be acceptable for you?
> > > 
> > > Adding something to i2c_driver is not exactly cheap, but from what I
> > > glimpsed from this thread, this is one of the cleanest solution to this
> > > problem?
> > > 
> > 
> > As Benjamin said, it is really property of device [instance], not
> > driver. I.e. driver could handle both wired IRQ and HostNotify-based
> > scheme similarly, it is device (and board) that knows how stuff is
> > connected.
> > 
> > Maybe we could do something like this (untested):
> > 
> > 
> > From e362a0277fd1bd6112f258664d8831d9bc6b78da Mon Sep 17 00:00:00 2001
> > From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > Date: Wed, 4 Jan 2017 09:33:43 -0800
> > Subject: [PATCH] i2c: do not enable fall back to Host Notify by default
> > 
> > Falling back unconditionally to HostNotify as primary client's interrupt
> > breaks some drivers which alter their functionality depending on whether
> > interrupt is present or not, so let's introduce a board flag telling I2C
> > core explicitly if we want wired interrupt or HostNotify-based one:
> > I2C_CLIENT_HOST_NOTIFY.
> > 
> > For DT-based systems we introduce "host-notofy" property that we convert
> 
> typo: s/host-notofy/host-notify/
> 
> > to I2C_CLIENT_HOST_NOTIFY board flag.
> > 
> > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > ---
> >  Documentation/devicetree/bindings/i2c/i2c.txt |  8 ++++++++
> >  drivers/i2c/i2c-core.c                        | 17 ++++++++---------
> >  include/linux/i2c.h                           |  1 +
> >  3 files changed, 17 insertions(+), 9 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/i2c/i2c.txt b/Documentation/devicetree/bindings/i2c/i2c.txt
> > index 5fa691e6f638..cee9d5055fa2 100644
> > --- a/Documentation/devicetree/bindings/i2c/i2c.txt
> > +++ b/Documentation/devicetree/bindings/i2c/i2c.txt
> > @@ -62,6 +62,9 @@ wants to support one of the below features, it should adapt the bindings below.
> >  	"irq" and "wakeup" names are recognized by I2C core, other names are
> >  	left to individual drivers.
> >  
> > +- host-notify
> > +	device uses SMBus host notify protocol instead of interrupt line.
> > +
> >  - multi-master
> >  	states that there is another master active on this bus. The OS can use
> >  	this information to adapt power management to keep the arbitration awake
> > @@ -81,6 +84,11 @@ Binding may contain optional "interrupts" property, describing interrupts
> >  used by the device. I2C core will assign "irq" interrupt (or the very first
> >  interrupt if not using interrupt names) as primary interrupt for the slave.
> >  
> > +Alternatively, devices supporting SMbus Host Notify, and connected to
> > +adapters that support this feature, may use "host-notify" property. I2C
> > +core will create a virtual interrupt for Host Notify and assign it as
> > +primary interrupt for the slave.
> > +
> >  Also, if device is marked as a wakeup source, I2C core will set up "wakeup"
> >  interrupt for the device. If "wakeup" interrupt name is not present in the
> >  binding, then primary interrupt will be used as wakeup interrupt.
> > diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> > index cf9e396d7702..250969fa7670 100644
> > --- a/drivers/i2c/i2c-core.c
> > +++ b/drivers/i2c/i2c-core.c
> > @@ -931,7 +931,10 @@ static int i2c_device_probe(struct device *dev)
> >  	if (!client->irq) {
> >  		int irq = -ENOENT;
> >  
> > -		if (dev->of_node) {
> > +		if (client->flags & I2C_CLIENT_HOST_HOTIFY) {
> 
> typo: s/I2C_CLIENT_HOST_HOTIFY/I2C_CLIENT_HOST_NOTIFY/
> 
> With these fixed, the code is:
> Tested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> 
> I tested both with and without the I2C_CLIENT_HOST_HOTIFY flag on the
> Thinkpad T450s, and everything is in order.
> 
> Thanks Dmitry for the patch!

Thanks Benjamin. Let me submit the patch "officially" and CC Rob & DT
folks on binding change.

-- 
Dmitry

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Wolfram Sang]

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


> From e362a0277fd1bd6112f258664d8831d9bc6b78da Mon Sep 17 00:00:00 2001
> From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Date: Wed, 4 Jan 2017 09:33:43 -0800
> Subject: [PATCH] i2c: do not enable fall back to Host Notify by default
> 
> Falling back unconditionally to HostNotify as primary client's interrupt
> breaks some drivers which alter their functionality depending on whether
> interrupt is present or not, so let's introduce a board flag telling I2C
> core explicitly if we want wired interrupt or HostNotify-based one:
> I2C_CLIENT_HOST_NOTIFY.
> 
> For DT-based systems we introduce "host-notofy" property that we convert
> to I2C_CLIENT_HOST_NOTIFY board flag.
> 
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Yay, this looks better to me. One nit:

> +Alternatively, devices supporting SMbus Host Notify, and connected to
> +adapters that support this feature, may use "host-notify" property. I2C
> +core will create a virtual interrupt for Host Notify and assign it as
> +primary interrupt for the slave.

This paragraph sounds Linux-ish while binding docs should be OS
agnostic. Maybe we can shorten the second sentence to "It will be
assigned then as the primary interrupt for the slave."?


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

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Dmitry Torokhov]

On Wed, Jan 04, 2017 at 10:55:47PM +0100, Wolfram Sang wrote:
> 
> > From e362a0277fd1bd6112f258664d8831d9bc6b78da Mon Sep 17 00:00:00 2001
> > From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > Date: Wed, 4 Jan 2017 09:33:43 -0800
> > Subject: [PATCH] i2c: do not enable fall back to Host Notify by default
> > 
> > Falling back unconditionally to HostNotify as primary client's interrupt
> > breaks some drivers which alter their functionality depending on whether
> > interrupt is present or not, so let's introduce a board flag telling I2C
> > core explicitly if we want wired interrupt or HostNotify-based one:
> > I2C_CLIENT_HOST_NOTIFY.
> > 
> > For DT-based systems we introduce "host-notofy" property that we convert
> > to I2C_CLIENT_HOST_NOTIFY board flag.
> > 
> > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> 
> Yay, this looks better to me. One nit:
> 
> > +Alternatively, devices supporting SMbus Host Notify, and connected to
> > +adapters that support this feature, may use "host-notify" property. I2C
> > +core will create a virtual interrupt for Host Notify and assign it as
> > +primary interrupt for the slave.
> 
> This paragraph sounds Linux-ish while binding docs should be OS
> agnostic. Maybe we can shorten the second sentence to "It will be
> assigned then as the primary interrupt for the slave."?

Heh, I just sent out patch to DT folks. Provided that they are fine with
the new property I can either send V2 or you could edit when applying,
whatever is easier for you.

Thanks.

-- 
Dmitry

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Dmitry Torokhov]

On Wed, Jan 04, 2017 at 02:00:30PM -0800, Dmitry Torokhov wrote:
> On Wed, Jan 04, 2017 at 10:55:47PM +0100, Wolfram Sang wrote:
> > 
> > > From e362a0277fd1bd6112f258664d8831d9bc6b78da Mon Sep 17 00:00:00 2001
> > > From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > > Date: Wed, 4 Jan 2017 09:33:43 -0800
> > > Subject: [PATCH] i2c: do not enable fall back to Host Notify by default
> > > 
> > > Falling back unconditionally to HostNotify as primary client's interrupt
> > > breaks some drivers which alter their functionality depending on whether
> > > interrupt is present or not, so let's introduce a board flag telling I2C
> > > core explicitly if we want wired interrupt or HostNotify-based one:
> > > I2C_CLIENT_HOST_NOTIFY.
> > > 
> > > For DT-based systems we introduce "host-notofy" property that we convert
> > > to I2C_CLIENT_HOST_NOTIFY board flag.
> > > 
> > > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > 
> > Yay, this looks better to me. One nit:
> > 
> > > +Alternatively, devices supporting SMbus Host Notify, and connected to
> > > +adapters that support this feature, may use "host-notify" property. I2C
> > > +core will create a virtual interrupt for Host Notify and assign it as
> > > +primary interrupt for the slave.
> > 
> > This paragraph sounds Linux-ish while binding docs should be OS
> > agnostic. Maybe we can shorten the second sentence to "It will be
> > assigned then as the primary interrupt for the slave."?
> 
> Heh, I just sent out patch to DT folks. Provided that they are fine with
> the new property I can either send V2 or you could edit when applying,
> whatever is easier for you.

That said, both variants are Linux-ish to me: I do not believe that
"primary slave interrupt" for I2C devices is a generic concept. Is it?
Do BSD and Windows use it?

Also, it matches the paragraph above that also talks about I2C core.

In any case, it is your decision, I'm just making random noise here.

Thanks.

-- 
Dmitry

Re: [PATCH] i2c: do not enable fall back to Host Notify by default

[kbuild test robot]

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

Hi Dmitry,

[auto build test ERROR on wsa/i2c/for-next]
[also build test ERROR on v4.10-rc2 next-20170104]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Dmitry-Torokhov/i2c-do-not-enable-fall-back-to-Host-Notify-by-default/20170105-095405
base:   https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-next
config: x86_64-randconfig-x017-201701 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
        # save the attached .config to linux build tree
        make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/i2c/i2c-core.c: In function 'i2c_device_probe':
   drivers/i2c/i2c-core.c:934:23: error: 'I2C_CLIENT_HOST_HOTIFY' undeclared (first use in this function)
      if (client->flags & I2C_CLIENT_HOST_HOTIFY) {
                          ^~~~~~~~~~~~~~~~~~~~~~
   drivers/i2c/i2c-core.c:934:23: note: each undeclared identifier is reported only once for each function it appears in
   drivers/i2c/i2c-core.c: In function 'of_i2c_register_device':
>> drivers/i2c/i2c-core.c:1715:6: error: implicit declaration of function 'of_read_property_bool' [-Werror=implicit-function-declaration]
     if (of_read_property_bool(node, "host-notify"))
         ^~~~~~~~~~~~~~~~~~~~~
   cc1: some warnings being treated as errors

vim +/of_read_property_bool +1715 drivers/i2c/i2c-core.c

  1709		}
  1710	
  1711		info.addr = addr;
  1712		info.of_node = of_node_get(node);
  1713		info.archdata = &dev_ad;
  1714	
> 1715		if (of_read_property_bool(node, "host-notify"))
  1716			info.flags |= I2C_CLIENT_HOST_NOTIFY;
  1717	
  1718		if (of_get_property(node, "wakeup-source", NULL))

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 24760 bytes --]

Re: [PATCH] i2c: do not enable fall back to Host Notify by default

[kbuild test robot]

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

Hi Dmitry,

[auto build test ERROR on wsa/i2c/for-next]
[also build test ERROR on v4.10-rc2 next-20170104]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Dmitry-Torokhov/i2c-do-not-enable-fall-back-to-Host-Notify-by-default/20170105-095405
base:   https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-next
config: x86_64-randconfig-x011-201701 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
        # save the attached .config to linux build tree
        make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/i2c/i2c-core.c: In function 'i2c_device_probe':
>> drivers/i2c/i2c-core.c:934:23: error: 'I2C_CLIENT_HOST_HOTIFY' undeclared (first use in this function)
      if (client->flags & I2C_CLIENT_HOST_HOTIFY) {
                          ^~~~~~~~~~~~~~~~~~~~~~
   drivers/i2c/i2c-core.c:934:23: note: each undeclared identifier is reported only once for each function it appears in

vim +/I2C_CLIENT_HOST_HOTIFY +934 drivers/i2c/i2c-core.c

   928		if (!client)
   929			return 0;
   930	
   931		if (!client->irq) {
   932			int irq = -ENOENT;
   933	
 > 934			if (client->flags & I2C_CLIENT_HOST_HOTIFY) {
   935				dev_dbg(dev, "Using Host Notify IRQ\n");
   936				irq = i2c_smbus_host_notify_to_irq(client);
   937			} else if (dev->of_node) {

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 24858 bytes --]

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Pali Rohár]

On Wednesday 04 January 2017 09:54:56 Dmitry Torokhov wrote:
> On Wed, Jan 04, 2017 at 06:46:19PM +0100, Wolfram Sang wrote:
> > 
> > > How about:
> > > ---
> > > From daa7571bbf337704332c0cfeec9b8fd5aeae596f Mon Sep 17 00:00:00 2001
> > > From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> > > Date: Wed, 4 Jan 2017 18:26:54 +0100
> > > Subject: [PATCH] I2C: add the source of the IRQ in struct i2c_client
> > > 
> > > With commit 4d5538f5882a ("i2c: use an IRQ to report Host Notify events,
> > > not alert"), the IRQ provided in struct i2c_client might be assigned while
> > > it has not been explicitly declared by either the platform information
> > > or OF or ACPI.
> > > Some drivers (lis3lv02d) rely on the fact that the IRQ gets assigned or
> > > not to trigger a different behavior (exposing /dev/freefall in this case).
> > > 
> > > Provide a way for others to know who set the IRQ and so they can behave
> > > accordingly.
> > > 
> > > Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> > > ---
> > >  drivers/i2c/i2c-core.c |  7 +++++++
> > >  include/linux/i2c.h    | 11 +++++++++++
> > >  2 files changed, 18 insertions(+)
> > > 
> > > diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> > > index cf9e396..226c75d 100644
> > > --- a/drivers/i2c/i2c-core.c
> > > +++ b/drivers/i2c/i2c-core.c
> > > @@ -935,8 +935,12 @@ static int i2c_device_probe(struct device *dev)
> > >  			irq = of_irq_get_byname(dev->of_node, "irq");
> > >  			if (irq == -EINVAL || irq == -ENODATA)
> > >  				irq = of_irq_get(dev->of_node, 0);
> > > +			if (irq > 0)
> > > +				client->irq_source = I2C_IRQ_SOURCE_OF;
> > >  		} else if (ACPI_COMPANION(dev)) {
> > >  			irq = acpi_dev_gpio_irq_get(ACPI_COMPANION(dev), 0);
> > > +			if (irq > 0)
> > > +				client->irq_source = I2C_IRQ_SOURCE_ACPI;
> > >  		}
> > >  		if (irq == -EPROBE_DEFER)
> > >  			return irq;
> > > @@ -947,6 +951,8 @@ static int i2c_device_probe(struct device *dev)
> > >  		if (irq < 0) {
> > >  			dev_dbg(dev, "Using Host Notify IRQ\n");
> > >  			irq = i2c_smbus_host_notify_to_irq(client);
> > > +			if (irq > 0)
> > > +				client->irq_source = I2C_IRQ_SOURCE_HOST_NOTIFY;
> > >  		}
> > >  		if (irq < 0)
> > >  			irq = 0;
> > > @@ -1317,6 +1323,7 @@ i2c_new_device(struct i2c_adapter *adap, struct i2c_board_info const *info)
> > >  	client->flags = info->flags;
> > >  	client->addr = info->addr;
> > >  	client->irq = info->irq;
> > > +	client->irq_source = I2C_IRQ_SOURCE_PLATFORM;
> > >  
> > >  	strlcpy(client->name, info->type, sizeof(client->name));
> > >  
> > > diff --git a/include/linux/i2c.h b/include/linux/i2c.h
> > > index b2109c5..7d0368d 100644
> > > --- a/include/linux/i2c.h
> > > +++ b/include/linux/i2c.h
> > > @@ -213,6 +213,13 @@ struct i2c_driver {
> > >  };
> > >  #define to_i2c_driver(d) container_of(d, struct i2c_driver, driver)
> > >  
> > > +enum i2c_irq_source {
> > > +	I2C_IRQ_SOURCE_PLATFORM,
> > > +	I2C_IRQ_SOURCE_OF,
> > > +	I2C_IRQ_SOURCE_ACPI,
> > > +	I2C_IRQ_SOURCE_HOST_NOTIFY,
> > > +};
> > > +
> > >  /**
> > >   * struct i2c_client - represent an I2C slave device
> > >   * @flags: I2C_CLIENT_TEN indicates the device uses a ten bit chip address;
> > > @@ -227,6 +234,9 @@ struct i2c_driver {
> > >   *	userspace_devices list
> > >   * @slave_cb: Callback when I2C slave mode of an adapter is used. The adapter
> > >   *	calls it to pass on slave events to the slave driver.
> > > + * @irq_source: Enum which provides the source of the IRQ. Useful to know
> > > + * 	if the IRQ was issued from Host Notify or if it was provided by an other
> > > + * 	component.
> > 
> > I'd think some documentation somewhere makes sense why we need to
> > distinguish this in some cases?
> 
> I'd rather drivers be oblivious of the source of interrupt. If they need
> to distinguish between them that means that our IRQ abstration failed.
> 
> > 
> > >   *
> > >   * An i2c_client identifies a single device (i.e. chip) connected to an
> > >   * i2c bus. The behaviour exposed to Linux is defined by the driver
> > > @@ -245,6 +255,7 @@ struct i2c_client {
> > >  #if IS_ENABLED(CONFIG_I2C_SLAVE)
> > >  	i2c_slave_cb_t slave_cb;	/* callback for slave mode	*/
> > >  #endif
> > > +	enum i2c_irq_source irq_source;	/* which component assigned the irq */
> > >  };
> > >  #define to_i2c_client(d) container_of(d, struct i2c_client, dev)
> > > 
> > > Dmitry, Wolfram, Jean, would this be acceptable for you?
> > 
> > Adding something to i2c_driver is not exactly cheap, but from what I
> > glimpsed from this thread, this is one of the cleanest solution to this
> > problem?
> > 
> 
> As Benjamin said, it is really property of device [instance], not
> driver. I.e. driver could handle both wired IRQ and HostNotify-based
> scheme similarly, it is device (and board) that knows how stuff is
> connected.
> 
> Maybe we could do something like this (untested):
> 
> 
> From e362a0277fd1bd6112f258664d8831d9bc6b78da Mon Sep 17 00:00:00 2001
> From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Date: Wed, 4 Jan 2017 09:33:43 -0800
> Subject: [PATCH] i2c: do not enable fall back to Host Notify by default
> 
> Falling back unconditionally to HostNotify as primary client's interrupt
> breaks some drivers which alter their functionality depending on whether
> interrupt is present or not, so let's introduce a board flag telling I2C
> core explicitly if we want wired interrupt or HostNotify-based one:
> I2C_CLIENT_HOST_NOTIFY.
> 
> For DT-based systems we introduce "host-notofy" property that we convert
> to I2C_CLIENT_HOST_NOTIFY board flag.
> 
> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> ---
>  Documentation/devicetree/bindings/i2c/i2c.txt |  8 ++++++++
>  drivers/i2c/i2c-core.c                        | 17 ++++++++---------
>  include/linux/i2c.h                           |  1 +
>  3 files changed, 17 insertions(+), 9 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/i2c/i2c.txt b/Documentation/devicetree/bindings/i2c/i2c.txt
> index 5fa691e6f638..cee9d5055fa2 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c.txt
> +++ b/Documentation/devicetree/bindings/i2c/i2c.txt
> @@ -62,6 +62,9 @@ wants to support one of the below features, it should adapt the bindings below.
>  	"irq" and "wakeup" names are recognized by I2C core, other names are
>  	left to individual drivers.
>  
> +- host-notify
> +	device uses SMBus host notify protocol instead of interrupt line.
> +
>  - multi-master
>  	states that there is another master active on this bus. The OS can use
>  	this information to adapt power management to keep the arbitration awake
> @@ -81,6 +84,11 @@ Binding may contain optional "interrupts" property, describing interrupts
>  used by the device. I2C core will assign "irq" interrupt (or the very first
>  interrupt if not using interrupt names) as primary interrupt for the slave.
>  
> +Alternatively, devices supporting SMbus Host Notify, and connected to
> +adapters that support this feature, may use "host-notify" property. I2C
> +core will create a virtual interrupt for Host Notify and assign it as
> +primary interrupt for the slave.
> +
>  Also, if device is marked as a wakeup source, I2C core will set up "wakeup"
>  interrupt for the device. If "wakeup" interrupt name is not present in the
>  binding, then primary interrupt will be used as wakeup interrupt.
> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> index cf9e396d7702..250969fa7670 100644
> --- a/drivers/i2c/i2c-core.c
> +++ b/drivers/i2c/i2c-core.c
> @@ -931,7 +931,10 @@ static int i2c_device_probe(struct device *dev)
>  	if (!client->irq) {
>  		int irq = -ENOENT;
>  
> -		if (dev->of_node) {
> +		if (client->flags & I2C_CLIENT_HOST_HOTIFY) {
> +			dev_dbg(dev, "Using Host Notify IRQ\n");
> +			irq = i2c_smbus_host_notify_to_irq(client);
> +		} else if (dev->of_node) {
>  			irq = of_irq_get_byname(dev->of_node, "irq");
>  			if (irq == -EINVAL || irq == -ENODATA)
>  				irq = of_irq_get(dev->of_node, 0);
> @@ -940,14 +943,7 @@ static int i2c_device_probe(struct device *dev)
>  		}
>  		if (irq == -EPROBE_DEFER)
>  			return irq;
> -		/*
> -		 * ACPI and OF did not find any useful IRQ, try to see
> -		 * if Host Notify can be used.
> -		 */
> -		if (irq < 0) {
> -			dev_dbg(dev, "Using Host Notify IRQ\n");
> -			irq = i2c_smbus_host_notify_to_irq(client);
> -		}
> +
>  		if (irq < 0)
>  			irq = 0;
>  
> @@ -1716,6 +1712,9 @@ static struct i2c_client *of_i2c_register_device(struct i2c_adapter *adap,
>  	info.of_node = of_node_get(node);
>  	info.archdata = &dev_ad;
>  
> +	if (of_read_property_bool(node, "host-notify"))
> +		info.flags |= I2C_CLIENT_HOST_NOTIFY;
> +
>  	if (of_get_property(node, "wakeup-source", NULL))
>  		info.flags |= I2C_CLIENT_WAKE;
>  
> diff --git a/include/linux/i2c.h b/include/linux/i2c.h
> index b2109c522dec..4b45ec46161f 100644
> --- a/include/linux/i2c.h
> +++ b/include/linux/i2c.h
> @@ -665,6 +665,7 @@ i2c_unlock_adapter(struct i2c_adapter *adapter)
>  #define I2C_CLIENT_TEN		0x10	/* we have a ten bit chip address */
>  					/* Must equal I2C_M_TEN below */
>  #define I2C_CLIENT_SLAVE	0x20	/* we are the slave */
> +#define I2C_CLIENT_HOST_NOTIFY	0x40	/* We want to use I2C host notify */
>  #define I2C_CLIENT_WAKE		0x80	/* for board_info; true iff can wake */
>  #define I2C_CLIENT_SCCB		0x9000	/* Use Omnivision SCCB protocol */
>  					/* Must match I2C_M_STOP|IGNORE_NAK */
> -- 
> 2.11.0.390.gc69c2f50cf-goog
> 
> 

Looks good, this seems to be elegant solution to our problem.

But then it is needed to patch those touchpad drivers to add that
I2C_CLIENT_HOST_NOTIFY flag, right?

-- 
Pali Rohár
pali.rohar@gmail.com

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Benjamin Tissoires]

On Jan 05 2017 or thereabouts, Pali Rohár wrote:
> On Wednesday 04 January 2017 09:54:56 Dmitry Torokhov wrote:
> > On Wed, Jan 04, 2017 at 06:46:19PM +0100, Wolfram Sang wrote:
> > > 
> > > > How about:
> > > > ---
> > > > From daa7571bbf337704332c0cfeec9b8fd5aeae596f Mon Sep 17 00:00:00 2001
> > > > From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> > > > Date: Wed, 4 Jan 2017 18:26:54 +0100
> > > > Subject: [PATCH] I2C: add the source of the IRQ in struct i2c_client
> > > > 
> > > > With commit 4d5538f5882a ("i2c: use an IRQ to report Host Notify events,
> > > > not alert"), the IRQ provided in struct i2c_client might be assigned while
> > > > it has not been explicitly declared by either the platform information
> > > > or OF or ACPI.
> > > > Some drivers (lis3lv02d) rely on the fact that the IRQ gets assigned or
> > > > not to trigger a different behavior (exposing /dev/freefall in this case).
> > > > 
> > > > Provide a way for others to know who set the IRQ and so they can behave
> > > > accordingly.
> > > > 
> > > > Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> > > > ---
> > > >  drivers/i2c/i2c-core.c |  7 +++++++
> > > >  include/linux/i2c.h    | 11 +++++++++++
> > > >  2 files changed, 18 insertions(+)
> > > > 
> > > > diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> > > > index cf9e396..226c75d 100644
> > > > --- a/drivers/i2c/i2c-core.c
> > > > +++ b/drivers/i2c/i2c-core.c
> > > > @@ -935,8 +935,12 @@ static int i2c_device_probe(struct device *dev)
> > > >  			irq = of_irq_get_byname(dev->of_node, "irq");
> > > >  			if (irq == -EINVAL || irq == -ENODATA)
> > > >  				irq = of_irq_get(dev->of_node, 0);
> > > > +			if (irq > 0)
> > > > +				client->irq_source = I2C_IRQ_SOURCE_OF;
> > > >  		} else if (ACPI_COMPANION(dev)) {
> > > >  			irq = acpi_dev_gpio_irq_get(ACPI_COMPANION(dev), 0);
> > > > +			if (irq > 0)
> > > > +				client->irq_source = I2C_IRQ_SOURCE_ACPI;
> > > >  		}
> > > >  		if (irq == -EPROBE_DEFER)
> > > >  			return irq;
> > > > @@ -947,6 +951,8 @@ static int i2c_device_probe(struct device *dev)
> > > >  		if (irq < 0) {
> > > >  			dev_dbg(dev, "Using Host Notify IRQ\n");
> > > >  			irq = i2c_smbus_host_notify_to_irq(client);
> > > > +			if (irq > 0)
> > > > +				client->irq_source = I2C_IRQ_SOURCE_HOST_NOTIFY;
> > > >  		}
> > > >  		if (irq < 0)
> > > >  			irq = 0;
> > > > @@ -1317,6 +1323,7 @@ i2c_new_device(struct i2c_adapter *adap, struct i2c_board_info const *info)
> > > >  	client->flags = info->flags;
> > > >  	client->addr = info->addr;
> > > >  	client->irq = info->irq;
> > > > +	client->irq_source = I2C_IRQ_SOURCE_PLATFORM;
> > > >  
> > > >  	strlcpy(client->name, info->type, sizeof(client->name));
> > > >  
> > > > diff --git a/include/linux/i2c.h b/include/linux/i2c.h
> > > > index b2109c5..7d0368d 100644
> > > > --- a/include/linux/i2c.h
> > > > +++ b/include/linux/i2c.h
> > > > @@ -213,6 +213,13 @@ struct i2c_driver {
> > > >  };
> > > >  #define to_i2c_driver(d) container_of(d, struct i2c_driver, driver)
> > > >  
> > > > +enum i2c_irq_source {
> > > > +	I2C_IRQ_SOURCE_PLATFORM,
> > > > +	I2C_IRQ_SOURCE_OF,
> > > > +	I2C_IRQ_SOURCE_ACPI,
> > > > +	I2C_IRQ_SOURCE_HOST_NOTIFY,
> > > > +};
> > > > +
> > > >  /**
> > > >   * struct i2c_client - represent an I2C slave device
> > > >   * @flags: I2C_CLIENT_TEN indicates the device uses a ten bit chip address;
> > > > @@ -227,6 +234,9 @@ struct i2c_driver {
> > > >   *	userspace_devices list
> > > >   * @slave_cb: Callback when I2C slave mode of an adapter is used. The adapter
> > > >   *	calls it to pass on slave events to the slave driver.
> > > > + * @irq_source: Enum which provides the source of the IRQ. Useful to know
> > > > + * 	if the IRQ was issued from Host Notify or if it was provided by an other
> > > > + * 	component.
> > > 
> > > I'd think some documentation somewhere makes sense why we need to
> > > distinguish this in some cases?
> > 
> > I'd rather drivers be oblivious of the source of interrupt. If they need
> > to distinguish between them that means that our IRQ abstration failed.
> > 
> > > 
> > > >   *
> > > >   * An i2c_client identifies a single device (i.e. chip) connected to an
> > > >   * i2c bus. The behaviour exposed to Linux is defined by the driver
> > > > @@ -245,6 +255,7 @@ struct i2c_client {
> > > >  #if IS_ENABLED(CONFIG_I2C_SLAVE)
> > > >  	i2c_slave_cb_t slave_cb;	/* callback for slave mode	*/
> > > >  #endif
> > > > +	enum i2c_irq_source irq_source;	/* which component assigned the irq */
> > > >  };
> > > >  #define to_i2c_client(d) container_of(d, struct i2c_client, dev)
> > > > 
> > > > Dmitry, Wolfram, Jean, would this be acceptable for you?
> > > 
> > > Adding something to i2c_driver is not exactly cheap, but from what I
> > > glimpsed from this thread, this is one of the cleanest solution to this
> > > problem?
> > > 
> > 
> > As Benjamin said, it is really property of device [instance], not
> > driver. I.e. driver could handle both wired IRQ and HostNotify-based
> > scheme similarly, it is device (and board) that knows how stuff is
> > connected.
> > 
> > Maybe we could do something like this (untested):
> > 
> > 
> > From e362a0277fd1bd6112f258664d8831d9bc6b78da Mon Sep 17 00:00:00 2001
> > From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > Date: Wed, 4 Jan 2017 09:33:43 -0800
> > Subject: [PATCH] i2c: do not enable fall back to Host Notify by default
> > 
> > Falling back unconditionally to HostNotify as primary client's interrupt
> > breaks some drivers which alter their functionality depending on whether
> > interrupt is present or not, so let's introduce a board flag telling I2C
> > core explicitly if we want wired interrupt or HostNotify-based one:
> > I2C_CLIENT_HOST_NOTIFY.
> > 
> > For DT-based systems we introduce "host-notofy" property that we convert
> > to I2C_CLIENT_HOST_NOTIFY board flag.
> > 
> > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > ---
> >  Documentation/devicetree/bindings/i2c/i2c.txt |  8 ++++++++
> >  drivers/i2c/i2c-core.c                        | 17 ++++++++---------
> >  include/linux/i2c.h                           |  1 +
> >  3 files changed, 17 insertions(+), 9 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/i2c/i2c.txt b/Documentation/devicetree/bindings/i2c/i2c.txt
> > index 5fa691e6f638..cee9d5055fa2 100644
> > --- a/Documentation/devicetree/bindings/i2c/i2c.txt
> > +++ b/Documentation/devicetree/bindings/i2c/i2c.txt
> > @@ -62,6 +62,9 @@ wants to support one of the below features, it should adapt the bindings below.
> >  	"irq" and "wakeup" names are recognized by I2C core, other names are
> >  	left to individual drivers.
> >  
> > +- host-notify
> > +	device uses SMBus host notify protocol instead of interrupt line.
> > +
> >  - multi-master
> >  	states that there is another master active on this bus. The OS can use
> >  	this information to adapt power management to keep the arbitration awake
> > @@ -81,6 +84,11 @@ Binding may contain optional "interrupts" property, describing interrupts
> >  used by the device. I2C core will assign "irq" interrupt (or the very first
> >  interrupt if not using interrupt names) as primary interrupt for the slave.
> >  
> > +Alternatively, devices supporting SMbus Host Notify, and connected to
> > +adapters that support this feature, may use "host-notify" property. I2C
> > +core will create a virtual interrupt for Host Notify and assign it as
> > +primary interrupt for the slave.
> > +
> >  Also, if device is marked as a wakeup source, I2C core will set up "wakeup"
> >  interrupt for the device. If "wakeup" interrupt name is not present in the
> >  binding, then primary interrupt will be used as wakeup interrupt.
> > diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> > index cf9e396d7702..250969fa7670 100644
> > --- a/drivers/i2c/i2c-core.c
> > +++ b/drivers/i2c/i2c-core.c
> > @@ -931,7 +931,10 @@ static int i2c_device_probe(struct device *dev)
> >  	if (!client->irq) {
> >  		int irq = -ENOENT;
> >  
> > -		if (dev->of_node) {
> > +		if (client->flags & I2C_CLIENT_HOST_HOTIFY) {
> > +			dev_dbg(dev, "Using Host Notify IRQ\n");
> > +			irq = i2c_smbus_host_notify_to_irq(client);
> > +		} else if (dev->of_node) {
> >  			irq = of_irq_get_byname(dev->of_node, "irq");
> >  			if (irq == -EINVAL || irq == -ENODATA)
> >  				irq = of_irq_get(dev->of_node, 0);
> > @@ -940,14 +943,7 @@ static int i2c_device_probe(struct device *dev)
> >  		}
> >  		if (irq == -EPROBE_DEFER)
> >  			return irq;
> > -		/*
> > -		 * ACPI and OF did not find any useful IRQ, try to see
> > -		 * if Host Notify can be used.
> > -		 */
> > -		if (irq < 0) {
> > -			dev_dbg(dev, "Using Host Notify IRQ\n");
> > -			irq = i2c_smbus_host_notify_to_irq(client);
> > -		}
> > +
> >  		if (irq < 0)
> >  			irq = 0;
> >  
> > @@ -1716,6 +1712,9 @@ static struct i2c_client *of_i2c_register_device(struct i2c_adapter *adap,
> >  	info.of_node = of_node_get(node);
> >  	info.archdata = &dev_ad;
> >  
> > +	if (of_read_property_bool(node, "host-notify"))
> > +		info.flags |= I2C_CLIENT_HOST_NOTIFY;
> > +
> >  	if (of_get_property(node, "wakeup-source", NULL))
> >  		info.flags |= I2C_CLIENT_WAKE;
> >  
> > diff --git a/include/linux/i2c.h b/include/linux/i2c.h
> > index b2109c522dec..4b45ec46161f 100644
> > --- a/include/linux/i2c.h
> > +++ b/include/linux/i2c.h
> > @@ -665,6 +665,7 @@ i2c_unlock_adapter(struct i2c_adapter *adapter)
> >  #define I2C_CLIENT_TEN		0x10	/* we have a ten bit chip address */
> >  					/* Must equal I2C_M_TEN below */
> >  #define I2C_CLIENT_SLAVE	0x20	/* we are the slave */
> > +#define I2C_CLIENT_HOST_NOTIFY	0x40	/* We want to use I2C host notify */
> >  #define I2C_CLIENT_WAKE		0x80	/* for board_info; true iff can wake */
> >  #define I2C_CLIENT_SCCB		0x9000	/* Use Omnivision SCCB protocol */
> >  					/* Must match I2C_M_STOP|IGNORE_NAK */
> > -- 
> > 2.11.0.390.gc69c2f50cf-goog
> > 
> > 
> 
> Looks good, this seems to be elegant solution to our problem.
> 
> But then it is needed to patch those touchpad drivers to add that
> I2C_CLIENT_HOST_NOTIFY flag, right?
>

Yes, but currently the 2 drivers that are using Host Notify upstream are
rmi_smbus and elan_i2c. Both don't have an automatic binding (yet), so
there is nothing to worry about for now.

Cheers,
Benjamin

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Jean Delvare]

On Tue, 3 Jan 2017 12:59:37 -0800, Dmitry Torokhov wrote:
> On Tue, Jan 03, 2017 at 09:39:13PM +0100, Pali Rohár wrote:
> > Some distributions blacklist i2c-i801.ko module... And 
> 
> Any particular reason for that?

At some point in time, the i2c-i801 driver caused problems on a few
systems. They decided that blacklisting the driver for everybody was
the easiest way to fix the problem. Of course this doesn't make any
sense and should be reverted. The root cause of the problem should have
been investigated back then. Maybe it's fixed by now and they will
never now...

-- 
Jean Delvare
SUSE L3 Support

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Andy Shevchenko]

On Tue, Jan 3, 2017 at 10:39 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
>
> With Michał we already discussed about it, see emails. Basically you can
> enable/disable kernel modules at compile time or blacklist at runtime
> (or even chose what will be compiled into vmlinux and what as external
> .ko module). Some distributions blacklist i2c-i801.ko module...

But you understand that any of compile/not compile is not an option, right?
The case which we face will be both of them, if possible, will be
compiled as modules.

Blacklisting means making your problem the actual user's one. Not good.

> And
> there can be also problem with initialization of i2c-i801 driver (fix is
> in commit a7ae81952cda, but does not have to work at every time!). So
> that move on whitelisted machines can potentially cause disappearance of
> /dev/freefall and users will not have hdd protection which is currently
> working.


-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Benjamin Tissoires]

On Jan 04 2017 or thereabouts, Andy Shevchenko wrote:
> On Tue, Jan 3, 2017 at 10:39 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> >
> > With Michał we already discussed about it, see emails. Basically you can
> > enable/disable kernel modules at compile time or blacklist at runtime
> > (or even chose what will be compiled into vmlinux and what as external
> > .ko module). Some distributions blacklist i2c-i801.ko module...
> 
> But you understand that any of compile/not compile is not an option, right?
> The case which we face will be both of them, if possible, will be
> compiled as modules.
> 
> Blacklisting means making your problem the actual user's one. Not good.
> 
> > And
> > there can be also problem with initialization of i2c-i801 driver (fix is
> > in commit a7ae81952cda, but does not have to work at every time!). So
> > that move on whitelisted machines can potentially cause disappearance of
> > /dev/freefall and users will not have hdd protection which is currently
> > working.
> 

I am seeing the same issues with psmouse and SMBus touchpads. The PS/2
device knows about the availability of a better but unlisted device at
the ACPI level.

The way I solved this to not have to deal with compile/not compile and
runtime errors is the same way Wolfram told you about: bus notifiers.
I also use an intermediate platform driver to not add i2c dependency on
psmouse.

For you the solution would be:
- In dell-smo8800, after checking the whitelist, add a platform driver
  "dell-lis3lv02d-platform", and add in the platform_data the I2C address
  of the chip.
- create a new driver dell-lis3lv02d-platform.ko which listens for the
  i2c bus creation and registers the lis3lv02d I2C node when it sees a
  matching adapter. (see [1] for my solution)
- in dell-lis3lv02d-platform.ko make sure to set the irq to -ENOENT so
  that lis3lv02d.ko doesn't create /dev/freefall which will still be
  handled by ACPI.

How does that sound?

Cheers,
Benjamin

[1] https://github.com/bentiss/linux/blob/synaptics-rmi4-v4.9-rc7+/drivers/input/rmi4/rmi_platform.c 

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Pali Rohár]

On Wednesday 04 January 2017 11:25:44 Benjamin Tissoires wrote:
> On Jan 04 2017 or thereabouts, Andy Shevchenko wrote:
> > On Tue, Jan 3, 2017 at 10:39 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> > >
> > > With Michał we already discussed about it, see emails. Basically you can
> > > enable/disable kernel modules at compile time or blacklist at runtime
> > > (or even chose what will be compiled into vmlinux and what as external
> > > .ko module). Some distributions blacklist i2c-i801.ko module...
> > 
> > But you understand that any of compile/not compile is not an option, right?
> > The case which we face will be both of them, if possible, will be
> > compiled as modules.
> > 
> > Blacklisting means making your problem the actual user's one. Not good.
> > 
> > > And
> > > there can be also problem with initialization of i2c-i801 driver (fix is
> > > in commit a7ae81952cda, but does not have to work at every time!). So
> > > that move on whitelisted machines can potentially cause disappearance of
> > > /dev/freefall and users will not have hdd protection which is currently
> > > working.
> > 
> 
> I am seeing the same issues with psmouse and SMBus touchpads. The PS/2
> device knows about the availability of a better but unlisted device at
> the ACPI level.
> 
> The way I solved this to not have to deal with compile/not compile and
> runtime errors is the same way Wolfram told you about: bus notifiers.
> I also use an intermediate platform driver to not add i2c dependency on
> psmouse.
> 
> For you the solution would be:
> - In dell-smo8800, after checking the whitelist, add a platform driver
>   "dell-lis3lv02d-platform", and add in the platform_data the I2C address
>   of the chip.
> - create a new driver dell-lis3lv02d-platform.ko which listens for the
>   i2c bus creation and registers the lis3lv02d I2C node when it sees a
>   matching adapter. (see [1] for my solution)
> - in dell-lis3lv02d-platform.ko make sure to set the irq to -ENOENT so
>   that lis3lv02d.ko doesn't create /dev/freefall which will still be
>   handled by ACPI.
> 
> How does that sound?

Yes, something like this was already suggested. But it is more
complicated as my approach and less error prone... See my notes in
previous emails.

My current path (after fixing IRQ to -1) is smaller more intuitive and
do not introduce new complicated parts like bus notifier and new "fake"
i2c driver...

> Cheers,
> Benjamin
> 
> [1] https://github.com/bentiss/linux/blob/synaptics-rmi4-v4.9-rc7+/drivers/input/rmi4/rmi_platform.c 

-- 
Pali Rohár
pali.rohar@gmail.com

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Benjamin Tissoires]

On Jan 04 2017 or thereabouts, Pali Rohár wrote:
> On Wednesday 04 January 2017 11:25:44 Benjamin Tissoires wrote:
> > On Jan 04 2017 or thereabouts, Andy Shevchenko wrote:
> > > On Tue, Jan 3, 2017 at 10:39 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> > > >
> > > > With Michał we already discussed about it, see emails. Basically you can
> > > > enable/disable kernel modules at compile time or blacklist at runtime
> > > > (or even chose what will be compiled into vmlinux and what as external
> > > > .ko module). Some distributions blacklist i2c-i801.ko module...
> > > 
> > > But you understand that any of compile/not compile is not an option, right?
> > > The case which we face will be both of them, if possible, will be
> > > compiled as modules.
> > > 
> > > Blacklisting means making your problem the actual user's one. Not good.
> > > 
> > > > And
> > > > there can be also problem with initialization of i2c-i801 driver (fix is
> > > > in commit a7ae81952cda, but does not have to work at every time!). So
> > > > that move on whitelisted machines can potentially cause disappearance of
> > > > /dev/freefall and users will not have hdd protection which is currently
> > > > working.
> > > 
> > 
> > I am seeing the same issues with psmouse and SMBus touchpads. The PS/2
> > device knows about the availability of a better but unlisted device at
> > the ACPI level.
> > 
> > The way I solved this to not have to deal with compile/not compile and
> > runtime errors is the same way Wolfram told you about: bus notifiers.
> > I also use an intermediate platform driver to not add i2c dependency on
> > psmouse.
> > 
> > For you the solution would be:
> > - In dell-smo8800, after checking the whitelist, add a platform driver
> >   "dell-lis3lv02d-platform", and add in the platform_data the I2C address
> >   of the chip.
> > - create a new driver dell-lis3lv02d-platform.ko which listens for the
> >   i2c bus creation and registers the lis3lv02d I2C node when it sees a
> >   matching adapter. (see [1] for my solution)
> > - in dell-lis3lv02d-platform.ko make sure to set the irq to -ENOENT so
> >   that lis3lv02d.ko doesn't create /dev/freefall which will still be
> >   handled by ACPI.
> > 
> > How does that sound?
> 
> Yes, something like this was already suggested. But it is more
> complicated as my approach and less error prone... See my notes in
> previous emails.

Sorry but I can't find your notes about errors in your previous emails.
This solution indeed is a little bit more complex than just adding the
bits in i2c-i801, but I don't really see the reason for an *adapter*
driver to instantiate specific *clients* depending on some DMI
matching.

It's a platform issue, so it should be solved at a platform level, not
at the i2c adapter level.

Plus the bus notifier solutions guarantees plain separation between the
elements and prevents any conflicts, with or without compile guards.

> 
> My current path (after fixing IRQ to -1) is smaller more intuitive and

This will only fix the fact that you have 2 concurrent drivers on the
same resource (freefall), not the fact that the global design of having
2 drivers which do not cooperate is wrong.

> do not introduce new complicated parts like bus notifier and new "fake"
> i2c driver...

It's not a "fake i2c driver". It's a platform driver. If you don't like
the idea of the platform driver, just add the bus notifier code in
dell-smo8800, but this will pull a new dependency on I2C in this ACPI
driver.

Cheers,
Benjamin

> > [1] https://github.com/bentiss/linux/blob/synaptics-rmi4-v4.9-rc7+/drivers/input/rmi4/rmi_platform.c 
> 
> -- 
> Pali Rohár
> pali.rohar@gmail.com

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Benjamin Tissoires]

On Jan 03 2017 or thereabouts, Dmitry Torokhov wrote:
> On Tue, Jan 03, 2017 at 07:50:17PM +0100, Pali Rohár wrote:
> > On Tuesday 03 January 2017 19:38:43 Dmitry Torokhov wrote:
> > > On Tue, Jan 03, 2017 at 10:06:41AM +0100, Benjamin Tissoires wrote:
> > > > On Dec 29 2016 or thereabouts, Pali Rohár wrote:
> > > > > On Thursday 29 December 2016 22:09:32 Michał Kępień wrote:
> > > > > > > On Thursday 29 December 2016 14:47:19 Michał Kępień wrote:
> > > > > > > > > On Thursday 29 December 2016 09:29:36 Michał Kępień wrote:
> > > > > > > > > > > Dell platform team told us that some (DMI
> > > > > > > > > > > whitelisted) Dell Latitude machines have ST
> > > > > > > > > > > microelectronics accelerometer at i2c address 0x29.
> > > > > > > > > > > That i2c address is not specified in DMI or ACPI, so
> > > > > > > > > > > runtime detection without whitelist which is below
> > > > > > > > > > > is not possible.
> > > > > > > > > > > 
> > > > > > > > > > > Presence of that ST microelectronics accelerometer is
> > > > > > > > > > > verified by existence of SMO88xx ACPI device which
> > > > > > > > > > > represent that accelerometer. Unfortunately without
> > > > > > > > > > > i2c address.
> > > > > > > > > > 
> > > > > > > > > > This part of the commit message sounded a bit confusing
> > > > > > > > > > to me at first because there is already an ACPI driver
> > > > > > > > > > which handles SMO88xx
> > > > > > > > > > 
> > > > > > > > > > devices (dell-smo8800).  My understanding is that:
> > > > > > > > > >   * the purpose of this patch is to expose a richer
> > > > > > > > > >   interface (as
> > > > > > > > > >   
> > > > > > > > > >     provided by lis3lv02d) to these devices on some
> > > > > > > > > >     machines,
> > > > > > > > > >   
> > > > > > > > > >   * on whitelisted machines, dell-smo8800 and lis3lv02d
> > > > > > > > > >   can work
> > > > > > > > > >   
> > > > > > > > > >     simultaneously (even though dell-smo8800
> > > > > > > > > >     effectively duplicates the work that lis3lv02d
> > > > > > > > > >     does).
> > > > > > > > > 
> > > > > > > > > No. dell-smo8800 reads from ACPI irq number and exports
> > > > > > > > > /dev/freefall device which notify userspace about falls.
> > > > > > > > > lis3lv02d is i2c driver which exports axes of
> > > > > > > > > accelerometer. Additionaly lis3lv02d can export also
> > > > > > > > > /dev/freefall if registerer of i2c device provides irq
> > > > > > > > > number -- which is not case of this patch.
> > > > > > > > > 
> > > > > > > > > So both drivers are doing different things and both are
> > > > > > > > > useful.
> > > > > > > > > 
> > > > > > > > > IIRC both dell-smo8800 and lis3lv02d represent one HW
> > > > > > > > > device (that ST microelectronics accelerometer) but due
> > > > > > > > > to complicated HW abstraction and layers on Dell laptops
> > > > > > > > > it is handled by two drivers, one ACPI and one i2c.
> > > > > > > > > 
> > > > > > > > > Yes, in ideal world irq number should be passed to
> > > > > > > > > lis3lv02d driver and that would export whole device
> > > > > > > > > (with /dev/freefall too), but due to HW abstraction it
> > > > > > > > > is too much complicated...
> > > > > > > > 
> > > > > > > > Why?  AFAICT, all that is required to pass that IRQ number
> > > > > > > > all the way down to lis3lv02d is to set the irq field of
> > > > > > > > the struct i2c_board_info you are passing to
> > > > > > > > i2c_new_device().  And you can extract that IRQ number
> > > > > > > > e.g. in check_acpi_smo88xx_device(). However, you would
> > > > > > > > then need to make sure dell-smo8800 does not attempt to
> > > > > > > > request the same IRQ on whitelisted machines.  This got me
> > > > > > > > thinking about a way to somehow incorporate your changes
> > > > > > > > into dell-smo8800 using Wolfram's bus_notifier suggestion,
> > > > > > > > but I do not have a working solution for now.  What is
> > > > > > > > tempting about this approach is that you would not have to
> > > > > > > > scan the ACPI namespace in search of SMO88xx devices,
> > > > > > > > because smo8800_add() is automatically called for them. 
> > > > > > > > However, I fear that the resulting solution may be more
> > > > > > > > complicated than the one you submitted.
> > > > > > > 
> > > > > > > Then we need to deal with lot of problems. Order of loading
> > > > > > > .ko modules is undefined. Binding devices to drivers
> > > > > > > registered by .ko module is also in "random" order. At any
> > > > > > > time any of those .ko module can be unloaded or at least
> > > > > > > device unbind (via sysfs) from driver... And there can be
> > > > > > > some pathological situation (thanks to adding ACPI layer as
> > > > > > > Andy pointed) that there will be more SMO88xx devices in
> > > > > > > ACPI. Plus you can compile kernel with and without those
> > > > > > > modules and also you can blacklist loading them (so compile
> > > > > > > time check is not enough). And still some correct message
> > > > > > > notifier must be used.
> > > > > > > 
> > > > > > > I think such solution is much much more complicated, there
> > > > > > > are lot of combinations of kernel configuration and
> > > > > > > available dell devices...
> > > > > > 
> > > > > > I tried a few more things, but ultimately failed to find a nice
> > > > > > way to implement this.
> > > > > > 
> > > > > > Another issue popped up, though.  Linus' master branch contains
> > > > > > a recent commit by Benjamin Tissoires (CC'ed), 4d5538f5882a
> > > > > > ("i2c: use an IRQ to report Host Notify events, not alert")
> > > > > > which breaks your patch.  The reason for that is that
> > > > > > lis3lv02d relies on the i2c client's IRQ being 0 to detect
> > > > > > that it should not create /dev/freefall.  Benjamin's patch
> > > > > > causes the Host Notify IRQ to be assigned to the i2c client
> > > > > > your patch creates, thus causing lis3lv02d to create
> > > > > > /dev/freefall, which in turn conflicts with dell-smo8800 which
> > > > > > is trying to create /dev/freefall itself.
> > > > > 
> > > > > So 4d5538f5882a is breaking lis3lv02d driver...
> > > > 
> > > > Apologies for that.
> > > > 
> > > > I could easily fix this by adding a kernel API to know whether the
> > > > provided irq is from Host Notify or if it was coming from an actual
> > > > declaration. However, I have no idea how many other drivers would
> > > > require this (hopefully only this one).
> > > > 
> > > > One other solution would be to reserve the Host Notify IRQ and let
> > > > the actual drivers that need it to set it, but this was not the
> > > > best solution according to Dmitri. On my side, I am not entirely
> > > > against this given that it's a chip feature, so the driver should
> > > > be able to know that it's available.
> > > > 
> > > > Dmitri, Wolfram, Jean, any preferences?
> > > 
> > > I read this:
> > > 
> > > "IIRC both dell-smo8800 and lis3lv02d represent one HW device (that
> > > ST microelectronics accelerometer) but due to complicated HW
> > > abstraction and layers on Dell laptops it is handled by two drivers,
> > > one ACPI and one i2c."
> > > 
> > > and that is the core of the issue. You have 2 drivers fighting over
> > > the same device. Fix this and it will all work.
> > 
> > With my current implementation (which I sent in this patch), they are 
> > not fighting.
> > 
> > dell-smo8800 exports /dev/freefall (and nothing more) and lis3lv02d only 
> > accelerometer device as lis3lv02d driver does not get IRQ number in 
> > platform data.
> > 
> > > As far as I can see hp_accel instantiates lis3lv02d and accesses it
> > > via ACPI methods, can the same be done for Dell?
> > 
> > No, Dell does not have any ACPI methods. And as I wrote in ACPI or DMI 
> > is even not i2c address of device, so it needs to be specified in code 
> > itself.
> > 
> > Really there is no other way... :-(
> 
> Sure there is:
> 
> 1. dell-smo8800 instantiates I2C device as "dell-smo8800-accel".
> 2. dell-smo8800 provides read/write functions for lis3lv02d that simply
>    forward requests to dell-smo8800-accel i2c client.
> 3. dell-smo8800 instantiates lis3lv02d instance like hp_accel does.
> 
> Alternatively, can lis3lv02d be tasked to create /dev/freefall?
> 
> Yet another option: can we add a new flag to i2c_board_info controlling
> whether we want to enable/disable wiring up host notify interrupt?

That should be fairly easy to implement. For now, given that only Elan
and Synaptics are the one in need for Host Notify, it could be better to
request the Host Notify IRQ instead of disabling it unconditionally
(which would make the current yet 8 years old lis3lv02d driver happy
again).

> Benjamin, is there anything "special" in RMI SMbus ACPI descriptors we
> could use?
> 

No, there is nothing special. Same situation for Elan with their latest
touchpads over PS/2. There is just a knowledge from the driver that
there is a device connected on a Host Notify capable bus on a specific
address. To give you an idea, on Windows, the Synaptics (and Elan)
driver even ships the equivalent of i2c-i801 to be sure to have one
driver for it...
So the knowledge is all in the driver.

Cheers,
Benjamin

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Dmitry Torokhov]

On Tue, Jan 03, 2017 at 10:29:34PM +0100, Benjamin Tissoires wrote:
> On Jan 03 2017 or thereabouts, Dmitry Torokhov wrote:
>
> > Yet another option: can we add a new flag to i2c_board_info controlling
> > whether we want to enable/disable wiring up host notify interrupt?
> 
> That should be fairly easy to implement. For now, given that only Elan
> and Synaptics are the one in need for Host Notify, it could be better to
> request the Host Notify IRQ instead of disabling it unconditionally
> (which would make the current yet 8 years old lis3lv02d driver happy
> again).

I like that we have it done in i2c core instead of having drivers
implementing it individually. Since you are saying that handling host
notify is property of the slave/driver maybe we should be adding a flag
to the *i2c_driver* structure to let i2c core that we want to have host
notify mapped as interrupt if "native" interrupt is not supplied by the
platform code?

Thanks.

-- 
Dmitry

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Benjamin Tissoires]

On Jan 03 2017 or thereabouts, Dmitry Torokhov wrote:
> On Tue, Jan 03, 2017 at 10:29:34PM +0100, Benjamin Tissoires wrote:
> > On Jan 03 2017 or thereabouts, Dmitry Torokhov wrote:
> >
> > > Yet another option: can we add a new flag to i2c_board_info controlling
> > > whether we want to enable/disable wiring up host notify interrupt?
> > 
> > That should be fairly easy to implement. For now, given that only Elan
> > and Synaptics are the one in need for Host Notify, it could be better to
> > request the Host Notify IRQ instead of disabling it unconditionally
> > (which would make the current yet 8 years old lis3lv02d driver happy
> > again).
> 
> I like that we have it done in i2c core instead of having drivers
> implementing it individually. Since you are saying that handling host
> notify is property of the slave/driver maybe we should be adding a flag
> to the *i2c_driver* structure to let i2c core that we want to have host
> notify mapped as interrupt if "native" interrupt is not supplied by the
> platform code?

I don't think this is a good idea. It's still a property of the I2C
device, not the driver. It's crappy under Windows, but that doesn't
prevent us to do the right thing.

I think the idea of having it at the i2c_board_info level is the good
one. It's a property of the device node and it wouldn't hurt me to have
a device tree property for that too (not entering the DT field now).
There is no ACPI prop for it too, but I wouldn't be surprised if it
comes in a later revision. The advantage of having it turned on
unconditionally is that we can instantiate it from userspace without
breaking the sysfs ABI.

Note that in the 2 uses I have seen so far of Host Notify, in both cases
I need to instantiate the I2C device from an other driver (psmouse) so I
can control the content of i2c_board_info.

Cheers,
Benjamin

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Pali Rohár]

On Wednesday 04 January 2017 10:13:38 Benjamin Tissoires wrote:
> On Jan 03 2017 or thereabouts, Dmitry Torokhov wrote:
> > On Tue, Jan 03, 2017 at 10:29:34PM +0100, Benjamin Tissoires wrote:
> > > On Jan 03 2017 or thereabouts, Dmitry Torokhov wrote:
> > >
> > > > Yet another option: can we add a new flag to i2c_board_info controlling
> > > > whether we want to enable/disable wiring up host notify interrupt?
> > > 
> > > That should be fairly easy to implement. For now, given that only Elan
> > > and Synaptics are the one in need for Host Notify, it could be better to
> > > request the Host Notify IRQ instead of disabling it unconditionally
> > > (which would make the current yet 8 years old lis3lv02d driver happy
> > > again).
> > 
> > I like that we have it done in i2c core instead of having drivers
> > implementing it individually. Since you are saying that handling host
> > notify is property of the slave/driver maybe we should be adding a flag
> > to the *i2c_driver* structure to let i2c core that we want to have host
> > notify mapped as interrupt if "native" interrupt is not supplied by the
> > platform code?
> 
> I don't think this is a good idea. It's still a property of the I2C
> device, not the driver. It's crappy under Windows, but that doesn't
> prevent us to do the right thing.
> 
> I think the idea of having it at the i2c_board_info level is the good
> one. It's a property of the device node and it wouldn't hurt me to have
> a device tree property for that too (not entering the DT field now).
> There is no ACPI prop for it too, but I wouldn't be surprised if it
> comes in a later revision. The advantage of having it turned on
> unconditionally is that we can instantiate it from userspace without
> breaking the sysfs ABI.
> 
> Note that in the 2 uses I have seen so far of Host Notify, in both cases
> I need to instantiate the I2C device from an other driver (psmouse) so I
> can control the content of i2c_board_info.

If I understand it correctly, there is problem that i2c lis3lv02d driver
needs to get IRQ number for freefall and in current structure you pass
host notify IRQ number.

It means that one property in lis3lv02d driver is used for two things:
free fall IRQ and host notify IRQ. So the only way how to fix it is to
use two different IRQ properties. Probably free fall IRQ is lis3lv02d
specific and should be in platform data structure, not in generic
i2c_board_info shared across all i2c drivers?

-- 
Pali Rohár
pali.rohar@gmail.com

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Andy Shevchenko]

On Tue, Jan 3, 2017 at 8:50 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> On Tuesday 03 January 2017 19:38:43 Dmitry Torokhov wrote:

>> "IIRC both dell-smo8800 and lis3lv02d represent one HW device (that
>> ST microelectronics accelerometer) but due to complicated HW
>> abstraction and layers on Dell laptops it is handled by two drivers,
>> one ACPI and one i2c."
>>
>> and that is the core of the issue. You have 2 drivers fighting over
>> the same device. Fix this and it will all work.
>
> With my current implementation (which I sent in this patch), they are
> not fighting.
>
> dell-smo8800 exports /dev/freefall (and nothing more) and lis3lv02d only
> accelerometer device as lis3lv02d driver does not get IRQ number in
> platform data.
>
>> As far as I can see hp_accel instantiates lis3lv02d and accesses it
>> via ACPI methods, can the same be done for Dell?
>
> No, Dell does not have any ACPI methods.

> And as I wrote in ACPI or DMI
> is even not i2c address of device, so it needs to be specified in code
> itself.

And as I wrote there is still a way to provide it without hardcoding
on model basis.

> Really there is no other way... :-(


-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Jean Delvare]

On Tue, 3 Jan 2017 10:06:41 +0100, Benjamin Tissoires wrote:
> On Dec 29 2016 or thereabouts, Pali Rohár wrote:
> > So 4d5538f5882a is breaking lis3lv02d driver...
> 
> Apologies for that.
> 
> I could easily fix this by adding a kernel API to know whether the
> provided irq is from Host Notify or if it was coming from an actual
> declaration. However, I have no idea how many other drivers would
> require this (hopefully only this one).
> 
> One other solution would be to reserve the Host Notify IRQ and let the
> actual drivers that need it to set it, but this was not the best
> solution according to Dmitri. On my side, I am not entirely against this
> given that it's a chip feature, so the driver should be able to know
> that it's available.
> 
> Dmitri, Wolfram, Jean, any preferences?

I did not look at your work so I do not feel qualified to give advice
on the proper way. I trust you to make the right decision :-)

-- 
Jean Delvare
SUSE L3 Support

Re: [PATCH] i2c: i801: Register optional lis3lv02d i2c device on Dell machines

[Wolfram Sang]

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


> > > > > +	if (!known_i2c_address) {
> > > > > +		dev_warn(&priv->pci_dev->dev,
> > > > > +			 "Accelerometer lis3lv02d i2c device is present "
> > > > > +			 "but its i2c address is unknown, skipping ...\n");
> > > > 
> > > > You are probably well aware of this, but checkpatch prefers
> > > > keeping long log messages in one line.  I am pointing it out
> > > > just in case.
> > > 
> > > Yes, but I do not know how to fix it. Splitting message into two
> > > lines generates warning. Having long line generates warning too.
> > 
> > Weird, checkpatch does not protest on my machine when the log message
> > is written on a single line...
> 
> I hope that i2c maintainers decide how to format that line.

Make it one line saying "accelerometer address unknown"?


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