[PATCH] pinctrl: intel: add blacklist list for XPS machines

[PATCH] pinctrl: intel: add blacklist list for XPS machines

[AceLan Kao]

The touchscreen on some Dell machines stop working after
closing and opening the lid after this driver is introduced.
So, I add a dmi list to black out those machines that doesn't
work well with this driver.

Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
---
 drivers/pinctrl/intel/pinctrl-sunrisepoint.c | 33 ++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/drivers/pinctrl/intel/pinctrl-sunrisepoint.c b/drivers/pinctrl/intel/pinctrl-sunrisepoint.c
index c725a53..f0e6c97 100644
--- a/drivers/pinctrl/intel/pinctrl-sunrisepoint.c
+++ b/drivers/pinctrl/intel/pinctrl-sunrisepoint.c
@@ -15,6 +15,7 @@
 #include <linux/platform_device.h>
 #include <linux/pm.h>
 #include <linux/pinctrl/pinctrl.h>
+#include <linux/dmi.h>
 
 #include "pinctrl-intel.h"
 
@@ -554,6 +555,35 @@ static const struct acpi_device_id spt_pinctrl_acpi_match[] = {
 };
 MODULE_DEVICE_TABLE(acpi, spt_pinctrl_acpi_match);
 
+static int pinctrl_blacklist_callback(const struct dmi_system_id *id)
+{
+	pr_info("Blacklisted pinctrl-sunrisepoint for %s\n", id->ident);
+	return 1;
+}
+
+static const struct dmi_system_id pinctrl_blacklist[] = {
+	/* This driver leads to XPS(2015/2016) touchscreen failed to work
+	 * after lid close/open, so try not to load this module
+	 */
+	{
+		.callback = pinctrl_blacklist_callback,
+		.ident = "Dell XPS 13",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+			DMI_MATCH(DMI_PRODUCT_NAME, "XPS 13 9350"),
+		},
+	},
+	{
+		.callback = pinctrl_blacklist_callback,
+		.ident = "Dell XPS 13",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+			DMI_MATCH(DMI_PRODUCT_NAME, "XPS 13 9360"),
+		},
+	},
+	{ }     /* terminating entry */
+};
+
 static int spt_pinctrl_probe(struct platform_device *pdev)
 {
 	const struct intel_pinctrl_soc_data *soc_data;
@@ -563,6 +593,9 @@ static int spt_pinctrl_probe(struct platform_device *pdev)
 	if (!id || !id->driver_data)
 		return -ENODEV;
 
+	if (dmi_check_system(pinctrl_blacklist))
+		return -ENODEV;
+
 	soc_data = (const struct intel_pinctrl_soc_data *)id->driver_data;
 	return intel_pinctrl_probe(pdev, soc_data);
 }
-- 
2.7.4

Re: [PATCH] pinctrl: intel: add blacklist list for XPS machines

[Calvin Johnson]

On Wed, Oct 5, 2016 at 11:27 AM, AceLan Kao <acelan.kao@canonical.com> wrote:
> The touchscreen on some Dell machines stop working after
> closing and opening the lid after this driver is introduced.
> So, I add a dmi list to black out those machines that doesn't
> work well with this driver.

Why don't you find out what in the driver is causing this problem,
instead of avoiding the driver  loading altogether?

>
> Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
> ---
>  drivers/pinctrl/intel/pinctrl-sunrisepoint.c | 33 ++++++++++++++++++++++++++++
>  1 file changed, 33 insertions(+)
>
> diff --git a/drivers/pinctrl/intel/pinctrl-sunrisepoint.c b/drivers/pinctrl/intel/pinctrl-sunrisepoint.c
> index c725a53..f0e6c97 100644
> --- a/drivers/pinctrl/intel/pinctrl-sunrisepoint.c
> +++ b/drivers/pinctrl/intel/pinctrl-sunrisepoint.c
> @@ -15,6 +15,7 @@
>  #include <linux/platform_device.h>
>  #include <linux/pm.h>
>  #include <linux/pinctrl/pinctrl.h>
> +#include <linux/dmi.h>
>
>  #include "pinctrl-intel.h"
>
> @@ -554,6 +555,35 @@ static const struct acpi_device_id spt_pinctrl_acpi_match[] = {
>  };
>  MODULE_DEVICE_TABLE(acpi, spt_pinctrl_acpi_match);
>
> +static int pinctrl_blacklist_callback(const struct dmi_system_id *id)
> +{
> +       pr_info("Blacklisted pinctrl-sunrisepoint for %s\n", id->ident);
> +       return 1;
> +}
> +
> +static const struct dmi_system_id pinctrl_blacklist[] = {
> +       /* This driver leads to XPS(2015/2016) touchscreen failed to work
> +        * after lid close/open, so try not to load this module
> +        */
> +       {
> +               .callback = pinctrl_blacklist_callback,
> +               .ident = "Dell XPS 13",
> +               .matches = {
> +                       DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
> +                       DMI_MATCH(DMI_PRODUCT_NAME, "XPS 13 9350"),
> +               },
> +       },
> +       {
> +               .callback = pinctrl_blacklist_callback,
> +               .ident = "Dell XPS 13",
> +               .matches = {
> +                       DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
> +                       DMI_MATCH(DMI_PRODUCT_NAME, "XPS 13 9360"),
> +               },
> +       },
> +       { }     /* terminating entry */
> +};
> +
>  static int spt_pinctrl_probe(struct platform_device *pdev)
>  {
>         const struct intel_pinctrl_soc_data *soc_data;
> @@ -563,6 +593,9 @@ static int spt_pinctrl_probe(struct platform_device *pdev)
>         if (!id || !id->driver_data)
>                 return -ENODEV;
>
> +       if (dmi_check_system(pinctrl_blacklist))
> +               return -ENODEV;
> +
>         soc_data = (const struct intel_pinctrl_soc_data *)id->driver_data;
>         return intel_pinctrl_probe(pdev, soc_data);
>  }
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] pinctrl: intel: add blacklist list for XPS machines

[Mika Westerberg]

On Wed, Oct 05, 2016 at 01:27:31PM +0530, Calvin Johnson wrote:
> On Wed, Oct 5, 2016 at 11:27 AM, AceLan Kao <acelan.kao@canonical.com> wrote:
> > The touchscreen on some Dell machines stop working after
> > closing and opening the lid after this driver is introduced.
> > So, I add a dmi list to black out those machines that doesn't
> > work well with this driver.
> 
> Why don't you find out what in the driver is causing this problem,
> instead of avoiding the driver  loading altogether?

Exactly!

Re: [PATCH] pinctrl: intel: add blacklist list for XPS machines

[AceLan Kao]

I have no knowledge of those pin definitions, and with 3.19 kernel,
those 2 blacklisted machines work well.
There is no pinctrl-sunrisepoint in 3.19 kernel, so I think this
driver is not critical for the machines,
that why I blacklisted the machines in the driver.

Or maybe anyone of you can give me some hints, which pin related to
the touchscreen which is connected on USB port.
I can do some test to see if I can find other solution.
The issue we encountered is that closing the lid to enter S3 and then
open the lid to wake up, the touchscreen fails to work.
By other ways to enter S3, pm-suspend, or click from GUI, the
touchscreen still works after waking up.
Thanks.


2016-10-05 16:55 GMT+08:00 Mika Westerberg <mika.westerberg@linux.intel.com>:
> On Wed, Oct 05, 2016 at 01:27:31PM +0530, Calvin Johnson wrote:
>> On Wed, Oct 5, 2016 at 11:27 AM, AceLan Kao <acelan.kao@canonical.com> wrote:
>> > The touchscreen on some Dell machines stop working after
>> > closing and opening the lid after this driver is introduced.
>> > So, I add a dmi list to black out those machines that doesn't
>> > work well with this driver.
>>
>> Why don't you find out what in the driver is causing this problem,
>> instead of avoiding the driver  loading altogether?
>
> Exactly!

Re: [PATCH] pinctrl: intel: add blacklist list for XPS machines

[Mika Westerberg]

On Wed, Oct 05, 2016 at 05:23:08PM +0800, AceLan Kao wrote:
> Or maybe anyone of you can give me some hints, which pin related to
> the touchscreen which is connected on USB port.
> I can do some test to see if I can find other solution.
> The issue we encountered is that closing the lid to enter S3 and then
> open the lid to wake up, the touchscreen fails to work.
> By other ways to enter S3, pm-suspend, or click from GUI, the
> touchscreen still works after waking up.

You can start by either filing a bug in the kernel bugzilla or
alternatively send me full dmesg of the error. Also include output of
/proc/interrupts before and after suspend.

You can also try the following patch:

https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?h=x86/urgent&id=db91aa793ff984ac048e199ea1c54202543952fe

It fixes a memory corruption during suspend/resume which might be
related to the issue you are seeing.

Re: [PATCH] pinctrl: intel: add blacklist list for XPS machines

[AceLan Kao]

The patch doesn't work, so I filed a bug on kernel bugzilla[1]
Closing and opening the lid to trigger this issue doesn't have any
explicit error message in dmesg,
but anyway, I attached all these logs on bugzilla.
Thanks.

1. https://bugzilla.kernel.org/show_bug.cgi?id=176361

2016-10-05 17:32 GMT+08:00 Mika Westerberg <mika.westerberg@linux.intel.com>:
> On Wed, Oct 05, 2016 at 05:23:08PM +0800, AceLan Kao wrote:
>> Or maybe anyone of you can give me some hints, which pin related to
>> the touchscreen which is connected on USB port.
>> I can do some test to see if I can find other solution.
>> The issue we encountered is that closing the lid to enter S3 and then
>> open the lid to wake up, the touchscreen fails to work.
>> By other ways to enter S3, pm-suspend, or click from GUI, the
>> touchscreen still works after waking up.
>
> You can start by either filing a bug in the kernel bugzilla or
> alternatively send me full dmesg of the error. Also include output of
> /proc/interrupts before and after suspend.
>
> You can also try the following patch:
>
> https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?h=x86/urgent&id=db91aa793ff984ac048e199ea1c54202543952fe
>
> It fixes a memory corruption during suspend/resume which might be
> related to the issue you are seeing.

[PATCH] pinctrl: intel: Only restore pins that are used by the driver

[Mika Westerberg]

Dell XPS 13 (and maybe some others) uses a GPIO (CPU_GP_1) during suspend
to explicitly disable USB touchscreen interrupt. This is done to prevent
situation where the lid is closed the touchscreen is left functional.

The pinctrl driver (wrongly) assumes it owns all pins which are owned by
host and not locked down. It is perfectly fine for BIOS to use those pins
as it is also considered as host in this context.

What happens is that when the lid of Dell XPS 13 is closed, the BIOS
configures CPU_GP_1 low disabling the touchscreen interrupt. During resume
we restore all host owned pins to the known state which includes CPU_GP_1
and this overwrites what the BIOS has programmed there causing the
touchscreen to fail as no interrupts are reaching the CPU anymore.

Fix this by restoring only those pins we know are explicitly requested by
the kernel one way or other.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=176361
Reported-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
---
AceLan,

Can you try this one as well? It should do prevent the driver from messing
the pins used by the BIOS.

 drivers/pinctrl/intel/pinctrl-intel.c | 25 +++++++++++++++++++++++--
 1 file changed, 23 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/intel/pinctrl-intel.c b/drivers/pinctrl/intel/pinctrl-intel.c
index 257cab129692..2b5b20bf7d99 100644
--- a/drivers/pinctrl/intel/pinctrl-intel.c
+++ b/drivers/pinctrl/intel/pinctrl-intel.c
@@ -19,6 +19,7 @@
 #include <linux/pinctrl/pinconf.h>
 #include <linux/pinctrl/pinconf-generic.h>
 
+#include "../core.h"
 #include "pinctrl-intel.h"
 
 /* Offset from regs */
@@ -1079,6 +1080,26 @@ int intel_pinctrl_remove(struct platform_device *pdev)
 EXPORT_SYMBOL_GPL(intel_pinctrl_remove);
 
 #ifdef CONFIG_PM_SLEEP
+static bool intel_pinctrl_should_save(struct intel_pinctrl *pctrl, unsigned pin)
+{
+	const struct pin_desc *pd = pin_desc_get(pctrl->pctldev, pin);
+
+	if (!pd || !intel_pad_usable(pctrl, pin))
+		return false;
+
+	/*
+	 * Only restore the pin if it is actually in use by the kernel (or
+	 * by userspace). It is possible that some pins are used by the
+	 * BIOS during resume and those are not always locked down so leave
+	 * them alone.
+	 */
+	if (pd->mux_owner || pd->gpio_owner ||
+	    gpiochip_line_is_irq(&pctrl->chip, pin))
+		return true;
+
+	return false;
+}
+
 int intel_pinctrl_suspend(struct device *dev)
 {
 	struct platform_device *pdev = to_platform_device(dev);
@@ -1092,7 +1113,7 @@ int intel_pinctrl_suspend(struct device *dev)
 		const struct pinctrl_pin_desc *desc = &pctrl->soc->pins[i];
 		u32 val;
 
-		if (!intel_pad_usable(pctrl, desc->number))
+		if (!intel_pinctrl_should_save(pctrl, desc->number))
 			continue;
 
 		val = readl(intel_get_padcfg(pctrl, desc->number, PADCFG0));
@@ -1153,7 +1174,7 @@ int intel_pinctrl_resume(struct device *dev)
 		void __iomem *padcfg;
 		u32 val;
 
-		if (!intel_pad_usable(pctrl, desc->number))
+		if (!intel_pinctrl_should_save(pctrl, desc->number))
 			continue;
 
 		padcfg = intel_get_padcfg(pctrl, desc->number, PADCFG0);
-- 
2.9.3

RE: [PATCH] pinctrl: intel: Only restore pins that are used by the driver

[Mario.Limonciello]

> Dell XPS 13 (and maybe some others) uses a GPIO (CPU_GP_1) during
> suspend
> to explicitly disable USB touchscreen interrupt. This is done to prevent
> situation where the lid is closed the touchscreen is left functional.
> 
> The pinctrl driver (wrongly) assumes it owns all pins which are owned by
> host and not locked down. It is perfectly fine for BIOS to use those pins
> as it is also considered as host in this context.
> 
> What happens is that when the lid of Dell XPS 13 is closed, the BIOS
> configures CPU_GP_1 low disabling the touchscreen interrupt. During
> resume
> we restore all host owned pins to the known state which includes CPU_GP_1
> and this overwrites what the BIOS has programmed there causing the
> touchscreen to fail as no interrupts are reaching the CPU anymore.
> 
> Fix this by restoring only those pins we know are explicitly requested by
> the kernel one way or other.
> 
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=176361
> Reported-by: AceLan Kao <acelan.kao@canonical.com>
> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> ---
> AceLan,
> 
> Can you try this one as well? It should do prevent the driver from messing
> the pins used by the BIOS.
> 
>  drivers/pinctrl/intel/pinctrl-intel.c | 25 +++++++++++++++++++++++--
>  1 file changed, 23 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/pinctrl/intel/pinctrl-intel.c b/drivers/pinctrl/intel/pinctrl-
> intel.c
> index 257cab129692..2b5b20bf7d99 100644
> --- a/drivers/pinctrl/intel/pinctrl-intel.c
> +++ b/drivers/pinctrl/intel/pinctrl-intel.c
> @@ -19,6 +19,7 @@
>  #include <linux/pinctrl/pinconf.h>
>  #include <linux/pinctrl/pinconf-generic.h>
> 
> +#include "../core.h"
>  #include "pinctrl-intel.h"
> 
>  /* Offset from regs */
> @@ -1079,6 +1080,26 @@ int intel_pinctrl_remove(struct platform_device
> *pdev)
>  EXPORT_SYMBOL_GPL(intel_pinctrl_remove);
> 
>  #ifdef CONFIG_PM_SLEEP
> +static bool intel_pinctrl_should_save(struct intel_pinctrl *pctrl, unsigned
> pin)
> +{
> +	const struct pin_desc *pd = pin_desc_get(pctrl->pctldev, pin);
> +
> +	if (!pd || !intel_pad_usable(pctrl, pin))
> +		return false;
> +
> +	/*
> +	 * Only restore the pin if it is actually in use by the kernel (or
> +	 * by userspace). It is possible that some pins are used by the
> +	 * BIOS during resume and those are not always locked down so
> leave
> +	 * them alone.
> +	 */
> +	if (pd->mux_owner || pd->gpio_owner ||
> +	    gpiochip_line_is_irq(&pctrl->chip, pin))
> +		return true;
> +
> +	return false;
> +}
> +
>  int intel_pinctrl_suspend(struct device *dev)
>  {
>  	struct platform_device *pdev = to_platform_device(dev);
> @@ -1092,7 +1113,7 @@ int intel_pinctrl_suspend(struct device *dev)
>  		const struct pinctrl_pin_desc *desc = &pctrl->soc->pins[i];
>  		u32 val;
> 
> -		if (!intel_pad_usable(pctrl, desc->number))
> +		if (!intel_pinctrl_should_save(pctrl, desc->number))
>  			continue;
> 
>  		val = readl(intel_get_padcfg(pctrl, desc->number,
> PADCFG0));
> @@ -1153,7 +1174,7 @@ int intel_pinctrl_resume(struct device *dev)
>  		void __iomem *padcfg;
>  		u32 val;
> 
> -		if (!intel_pad_usable(pctrl, desc->number))
> +		if (!intel_pinctrl_should_save(pctrl, desc->number))
>  			continue;
> 
>  		padcfg = intel_get_padcfg(pctrl, desc->number, PADCFG0);
> --
> 2.9.3

Mika,

After positive comments in this working properly and is accepted, would you 
consider submitting back to @stable as well?  It affects all kernel versions 
that carry intel pinctrl (IIRC back to 4.1?)

Thanks,

Re: [PATCH] pinctrl: intel: Only restore pins that are used by the driver

[Mika Westerberg]

On Mon, Oct 10, 2016 at 02:37:19PM +0000, Mario.Limonciello@dell.com wrote:
> After positive comments in this working properly and is accepted, would you 
> consider submitting back to @stable as well?  It affects all kernel versions 
> that carry intel pinctrl (IIRC back to 4.1?)

Sure.

LinusW, this should have stable tag starting from v4.1. Let me know if
you want me to re-submit the patch.

Re: [PATCH] pinctrl: intel: Only restore pins that are used by the driver

[AceLan Kao]

Hi Mika,

Yes, the patch works, the touchscreen continue working after lid close and open.
Thanks for your work.

Best regards,
AceLan Kao.

2016-10-10 22:53 GMT+08:00 Mika Westerberg <mika.westerberg@linux.intel.com>:
> On Mon, Oct 10, 2016 at 02:37:19PM +0000, Mario.Limonciello@dell.com wrote:
>> After positive comments in this working properly and is accepted, would you
>> consider submitting back to @stable as well?  It affects all kernel versions
>> that carry intel pinctrl (IIRC back to 4.1?)
>
> Sure.
>
> LinusW, this should have stable tag starting from v4.1. Let me know if
> you want me to re-submit the patch.

Re: [PATCH] pinctrl: intel: Only restore pins that are used by the driver

[AceLan Kao]

Hi Mika,

BTW, I failed to compile the kernel 4.4 with the patch.

The patch uses gpiochip_line_is_irq() function which has been
introduced since 4.6-rc1, so we need to cherry pick this commit, too.
   6cee382 gpio/pinctrl: sunxi: stop poking around in private vars

But the above commit uses gpiodev data member in struct gpio_chip
which is introduced from this commit, and it's a big commit that can't
be cherry-picked clearly.
   ff2b135 gpio: make the gpiochip a real device

Will you provide other patch that can apply on top of old stable kernels?

AceLan Kao.

2016-10-11 9:31 GMT+08:00 AceLan Kao <acelan.kao@canonical.com>:
> Hi Mika,
>
> Yes, the patch works, the touchscreen continue working after lid close and open.
> Thanks for your work.
>
> Best regards,
> AceLan Kao.
>
> 2016-10-10 22:53 GMT+08:00 Mika Westerberg <mika.westerberg@linux.intel.com>:
>> On Mon, Oct 10, 2016 at 02:37:19PM +0000, Mario.Limonciello@dell.com wrote:
>>> After positive comments in this working properly and is accepted, would you
>>> consider submitting back to @stable as well?  It affects all kernel versions
>>> that carry intel pinctrl (IIRC back to 4.1?)
>>
>> Sure.
>>
>> LinusW, this should have stable tag starting from v4.1. Let me know if
>> you want me to re-submit the patch.

Re: [PATCH] pinctrl: intel: Only restore pins that are used by the driver

[Mika Westerberg]

On Tue, Oct 11, 2016 at 10:38:27AM +0800, AceLan Kao wrote:
> Hi Mika,
> 
> BTW, I failed to compile the kernel 4.4 with the patch.
> 
> The patch uses gpiochip_line_is_irq() function which has been
> introduced since 4.6-rc1, so we need to cherry pick this commit, too.
>    6cee382 gpio/pinctrl: sunxi: stop poking around in private vars
> 
> But the above commit uses gpiodev data member in struct gpio_chip
> which is introduced from this commit, and it's a big commit that can't
> be cherry-picked clearly.
>    ff2b135 gpio: make the gpiochip a real device
> 
> Will you provide other patch that can apply on top of old stable kernels?

Hmm,

So 6cee382 ("gpio/pinctrl: sunxi: stop poking around in private vars")
needs the following patch.

I can backport 6cee382 with the below patch and send both patches to
stable@ after this gets merged to mainline but not sure if that's the
correct process to follow.

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index db007a3e2af7..6240dd40e8be 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1524,7 +1524,7 @@ bool gpiochip_line_is_irq(struct gpio_chip *chip, unsigned int offset)
 	if (offset >= chip->ngpio)
 		return false;
 
-	return test_bit(FLAG_USED_AS_IRQ, &chip->gpiodev->descs[offset].flags);
+	return test_bit(FLAG_USED_AS_IRQ, &chip->desc[offset].flags);
 }
 EXPORT_SYMBOL_GPL(gpiochip_line_is_irq);
 

Re: [PATCH] pinctrl: intel: Only restore pins that are used by the driver

[AceLan Kao]

Cool, the fix works for me.

I really hope these fixes could be in stable kernel from 4.1+,
but if you have any concerns or troubles in doing that, please let me know,
I'll submit those patches to ubuntu 4.4 and 4.8 kernels.
Thanks.

2016-10-11 17:27 GMT+08:00 Mika Westerberg <mika.westerberg@linux.intel.com>:
> On Tue, Oct 11, 2016 at 10:38:27AM +0800, AceLan Kao wrote:
>> Hi Mika,
>>
>> BTW, I failed to compile the kernel 4.4 with the patch.
>>
>> The patch uses gpiochip_line_is_irq() function which has been
>> introduced since 4.6-rc1, so we need to cherry pick this commit, too.
>>    6cee382 gpio/pinctrl: sunxi: stop poking around in private vars
>>
>> But the above commit uses gpiodev data member in struct gpio_chip
>> which is introduced from this commit, and it's a big commit that can't
>> be cherry-picked clearly.
>>    ff2b135 gpio: make the gpiochip a real device
>>
>> Will you provide other patch that can apply on top of old stable kernels?
>
> Hmm,
>
> So 6cee382 ("gpio/pinctrl: sunxi: stop poking around in private vars")
> needs the following patch.
>
> I can backport 6cee382 with the below patch and send both patches to
> stable@ after this gets merged to mainline but not sure if that's the
> correct process to follow.
>
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index db007a3e2af7..6240dd40e8be 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -1524,7 +1524,7 @@ bool gpiochip_line_is_irq(struct gpio_chip *chip, unsigned int offset)
>         if (offset >= chip->ngpio)
>                 return false;
>
> -       return test_bit(FLAG_USED_AS_IRQ, &chip->gpiodev->descs[offset].flags);
> +       return test_bit(FLAG_USED_AS_IRQ, &chip->desc[offset].flags);
>  }
>  EXPORT_SYMBOL_GPL(gpiochip_line_is_irq);
>

Re: [PATCH] pinctrl: intel: add blacklist list for XPS machines

[Jon Masters]

On 10/05/2016 01:57 AM, AceLan Kao wrote:

> The touchscreen on some Dell machines stop working after
> closing and opening the lid after this driver is introduced.
> So, I add a dmi list to black out those machines that doesn't
> work well with this driver.

Woot! This fixes the problems I've been having with the touchscreen on
my 2016 SKL XPS 13 :) Thanks to Mario for the head's up!

Jon.

-- 
Computer Architect

Re: [PATCH] pinctrl: intel: Only restore pins that are used by the driver

[Linus Walleij]

On Mon, Oct 10, 2016 at 3:39 PM, Mika Westerberg
<mika.westerberg@linux.intel.com> wrote:

> Dell XPS 13 (and maybe some others) uses a GPIO (CPU_GP_1) during suspend
> to explicitly disable USB touchscreen interrupt. This is done to prevent
> situation where the lid is closed the touchscreen is left functional.
>
> The pinctrl driver (wrongly) assumes it owns all pins which are owned by
> host and not locked down. It is perfectly fine for BIOS to use those pins
> as it is also considered as host in this context.
>
> What happens is that when the lid of Dell XPS 13 is closed, the BIOS
> configures CPU_GP_1 low disabling the touchscreen interrupt. During resume
> we restore all host owned pins to the known state which includes CPU_GP_1
> and this overwrites what the BIOS has programmed there causing the
> touchscreen to fail as no interrupts are reaching the CPU anymore.
>
> Fix this by restoring only those pins we know are explicitly requested by
> the kernel one way or other.
>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=176361
> Reported-by: AceLan Kao <acelan.kao@canonical.com>
> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>

Patch applied and tagged for stable. Also added Tested-by from
AceLan.

Yours,
Linus Walleij

Re: [PATCH] pinctrl: intel: add blacklist list for XPS machines

[Linus Walleij]

On Wed, Oct 5, 2016 at 7:57 AM, AceLan Kao <acelan.kao@canonical.com> wrote:

> The touchscreen on some Dell machines stop working after
> closing and opening the lid after this driver is introduced.
> So, I add a dmi list to black out those machines that doesn't
> work well with this driver.
>
> Signed-off-by: AceLan Kao <acelan.kao@canonical.com>

Is this patch still needed after Mika's thorough fix?

I guess not?

Yours,
Linus Walleij

Re: [PATCH] pinctrl: intel: add blacklist list for XPS machines

[Mika Westerberg]

On Tue, Oct 18, 2016 at 02:43:25PM +0200, Linus Walleij wrote:
> On Wed, Oct 5, 2016 at 7:57 AM, AceLan Kao <acelan.kao@canonical.com> wrote:
> 
> > The touchscreen on some Dell machines stop working after
> > closing and opening the lid after this driver is introduced.
> > So, I add a dmi list to black out those machines that doesn't
> > work well with this driver.
> >
> > Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
> 
> Is this patch still needed after Mika's thorough fix?
> 
> I guess not?

It's not needed anymore.

Re: [PATCH] pinctrl: intel: add blacklist list for XPS machines

[Linus Walleij]

On Tue, Oct 18, 2016 at 2:46 PM, Mika Westerberg
<mika.westerberg@linux.intel.com> wrote:
> On Tue, Oct 18, 2016 at 02:43:25PM +0200, Linus Walleij wrote:
>> On Wed, Oct 5, 2016 at 7:57 AM, AceLan Kao <acelan.kao@canonical.com> wrote:
>>
>> > The touchscreen on some Dell machines stop working after
>> > closing and opening the lid after this driver is introduced.
>> > So, I add a dmi list to black out those machines that doesn't
>> > work well with this driver.
>> >
>> > Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
>>
>> Is this patch still needed after Mika's thorough fix?
>>
>> I guess not?
>
> It's not needed anymore.

Good thanks. The fix is in Torvalds' tree now.

Yours,
Linus Walleij