* [PATCH 04/13] dt-bindings: gpio: add DT bindings for max77650
From: Bartosz Golaszewski @ 2019-01-18 13:42 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Linus Walleij, Dmitry Torokhov,
Jacek Anaszewski, Pavel Machek, Lee Jones, Sebastian Reichel,
Liam Girdwood, Mark Brown, Greg Kroah-Hartman
Cc: linux-kernel, linux-gpio, devicetree, linux-input, linux-leds,
linux-pm, Bartosz Golaszewski
In-Reply-To: <20190118134244.22253-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Add the DT binding document for the GPIO module of max77650.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
.../bindings/gpio/gpio-max77650.txt | 34 +++++++++++++++++++
1 file changed, 34 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-max77650.txt
diff --git a/Documentation/devicetree/bindings/gpio/gpio-max77650.txt b/Documentation/devicetree/bindings/gpio/gpio-max77650.txt
new file mode 100644
index 000000000000..b5dbbe934deb
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-max77650.txt
@@ -0,0 +1,34 @@
+GPIO driver for MAX77650 PMIC from Maxim Integrated.
+
+This module is part of the MAX77650 MFD device. For more details
+see Documentation/devicetree/bindings/mfd/max77650.txt.
+
+The GPIO controller is represented as a sub-node of the PMIC node on
+the device tree.
+
+This device has a single GPIO pin.
+
+Required properties:
+--------------------
+- compatible: Must be "maxim,max77650-gpio"
+- gpio-controller : Marks the device node as a gpio controller.
+- #gpio-cells : Must be <2>. The first cell is the pin number and
+ the second cell is used to specify the gpio active
+ state.
+
+Optional properties:
+--------------------
+gpio-line-names: Single string containing the name of the GPIO line.
+
+For more details, please refer to the generic GPIO DT binding document
+<devicetree/bindings/gpio/gpio.txt>.
+
+Example:
+--------
+
+ gpio {
+ compatible = "maxim,max77650-gpio";
+ gpio-line-names = "max77650-charger";
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
--
2.19.1
^ permalink raw reply related
* [PATCH 03/13] dt-bindings: power: supply: add DT bindings for max77650
From: Bartosz Golaszewski @ 2019-01-18 13:42 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Linus Walleij, Dmitry Torokhov,
Jacek Anaszewski, Pavel Machek, Lee Jones, Sebastian Reichel,
Liam Girdwood, Mark Brown, Greg Kroah-Hartman
Cc: linux-kernel, linux-gpio, devicetree, linux-input, linux-leds,
linux-pm, Bartosz Golaszewski
In-Reply-To: <20190118134244.22253-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Add the DT binding document for the battery charger module of max77650.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
.../power/supply/max77650-charger.txt | 27 +++++++++++++++++++
1 file changed, 27 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/supply/max77650-charger.txt
diff --git a/Documentation/devicetree/bindings/power/supply/max77650-charger.txt b/Documentation/devicetree/bindings/power/supply/max77650-charger.txt
new file mode 100644
index 000000000000..f3e00d41e299
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/supply/max77650-charger.txt
@@ -0,0 +1,27 @@
+Battery charger driver for MAX77650 PMIC from Maxim Integrated.
+
+This module is part of the MAX77650 MFD device. For more details
+see Documentation/devicetree/bindings/mfd/max77650.txt.
+
+The charger is represented as a sub-node of the PMIC node on the device tree.
+
+Required properties:
+--------------------
+- compatible: Must be "maxim,max77650-charger"
+
+Optional properties:
+--------------------
+- maxim,vchgin-min: Minimum CHGIN regulation voltage (in microvolts). Must be
+ one of: 4000000, 4100000, 4200000, 4300000, 4400000,
+ 4500000, 4600000, 4700000.
+- maxim,ichgin-lim: CHGIN input current limit (in microamps). Must be one of:
+ 95000, 190000, 285000, 380000, 475000.
+
+Example:
+--------
+
+ charger {
+ compatible = "maxim,max77650-charger";
+ maxim,vchgin-min = <4200000>;
+ maxim,ichgin-lim = <285000>;
+ };
--
2.19.1
^ permalink raw reply related
* [PATCH 02/13] dt-bindings: regulator: add DT bindings for max77650
From: Bartosz Golaszewski @ 2019-01-18 13:42 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Linus Walleij, Dmitry Torokhov,
Jacek Anaszewski, Pavel Machek, Lee Jones, Sebastian Reichel,
Liam Girdwood, Mark Brown, Greg Kroah-Hartman
Cc: linux-kernel, linux-gpio, devicetree, linux-input, linux-leds,
linux-pm, Bartosz Golaszewski
In-Reply-To: <20190118134244.22253-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Add the DT binding document for max77650 regulators.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
.../bindings/regulator/max77650-regulator.txt | 41 +++++++++++++++++++
1 file changed, 41 insertions(+)
create mode 100644 Documentation/devicetree/bindings/regulator/max77650-regulator.txt
diff --git a/Documentation/devicetree/bindings/regulator/max77650-regulator.txt b/Documentation/devicetree/bindings/regulator/max77650-regulator.txt
new file mode 100644
index 000000000000..f1cbe813c30f
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/max77650-regulator.txt
@@ -0,0 +1,41 @@
+Regulator driver for MAX77650 PMIC from Maxim Integrated.
+
+This module is part of the MAX77650 MFD device. For more details
+see Documentation/devicetree/bindings/mfd/max77650.txt.
+
+The regulator controller is represented as a sub-node of the PMIC node
+on the device tree.
+
+The device has a single LDO regulator and a SIMO buck-boost regulator with
+three independent power rails.
+
+Required properties:
+--------------------
+- compatible: Must be "maxim,max77650-regulator"
+
+Each rail must be instantiated under the regulators subnode of the top PMIC
+node. Up to four regulators can be defined. For standard regulator properties
+refer to Documentation/devicetree/bindings/regulator/regulator.txt.
+
+Available regulator compatible strings are: "ldo", "sbb0", "sbb1", "sbb2".
+
+Example:
+--------
+
+ regulators {
+ compatible = "maxim,max77650-regulator";
+
+ max77650_ldo: regulator@0 {
+ regulator-compatible = "ldo";
+ regulator-name = "max77650-ldo";
+ regulator-min-microvolt = <1350000>;
+ regulator-max-microvolt = <2937500>;
+ };
+
+ max77650_sbb0: regulator@1 {
+ regulator-compatible = "sbb0";
+ regulator-name = "max77650-sbb0";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1587500>;
+ };
+ };
--
2.19.1
^ permalink raw reply related
* [PATCH 01/13] dt-bindings: mfd: add DT bindings for max77650
From: Bartosz Golaszewski @ 2019-01-18 13:42 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Linus Walleij, Dmitry Torokhov,
Jacek Anaszewski, Pavel Machek, Lee Jones, Sebastian Reichel,
Liam Girdwood, Mark Brown, Greg Kroah-Hartman
Cc: linux-kernel, linux-gpio, devicetree, linux-input, linux-leds,
linux-pm, Bartosz Golaszewski
In-Reply-To: <20190118134244.22253-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Add a DT binding document for max77650 ultra-low power PMIC. This
describes the core mfd device.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
.../devicetree/bindings/mfd/max77650.txt | 28 +++++++++++++++++++
1 file changed, 28 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/max77650.txt
diff --git a/Documentation/devicetree/bindings/mfd/max77650.txt b/Documentation/devicetree/bindings/mfd/max77650.txt
new file mode 100644
index 000000000000..84631d3b1e14
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/max77650.txt
@@ -0,0 +1,28 @@
+MAX77650 ultra low-power PMIC from Maxim Integrated.
+
+Required properties:
+-------------------
+- compatible: Must be "maxim,max77650"
+- reg: I2C device address.
+- interrupts: The interrupt on the parent the controller is
+ connected to.
+- interrupt-parent: phandle of the parent interrupt controller.
+- interrupt-controller: Marks the device node as an interrupt controller.
+- #interrupt-cells: Must be <2>.
+
+For device-tree bindings of sub-modules (regulator, power supply, GPIO, LEDs
+and onkey) refer to the binding documents under the respective sub-system
+directories.
+
+Example:
+--------
+
+ pmic: max77650@48 {
+ compatible = "maxim,max77650";
+ reg = <0x48>;
+
+ interrupt-controller;
+ interrupt-parent = <&gpio2>;
+ #interrupt-cells = <2>;
+ interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
+ };
--
2.19.1
^ permalink raw reply related
* [PATCH 00/13] mfd: add support for max77650 PMIC
From: Bartosz Golaszewski @ 2019-01-18 13:42 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Linus Walleij, Dmitry Torokhov,
Jacek Anaszewski, Pavel Machek, Lee Jones, Sebastian Reichel,
Liam Girdwood, Mark Brown, Greg Kroah-Hartman
Cc: linux-kernel, linux-gpio, devicetree, linux-input, linux-leds,
linux-pm, Bartosz Golaszewski
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
This series adds support for max77650 ultra low-power PMIC. It provides
the core mfd driver and a set of five sub-drivers for the regulator,
power supply, gpio, leds and input subsystems.
Patches 1-6 add the DT binding documents. Patches 7-12 add all drivers.
Last patch adds a MAINTAINERS entry for this device.
Note that patch 8/13 depends on commit 03c87b95ac04 ("regulator: provide
rdev_get_regmap()") which was picked up by Mark Brown for v5.1.
Bartosz Golaszewski (13):
dt-bindings: mfd: add DT bindings for max77650
dt-bindings: regulator: add DT bindings for max77650
dt-bindings: power: supply: add DT bindings for max77650
dt-bindings: gpio: add DT bindings for max77650
dt-bindings: leds: add DT bindings for max77650
dt-bindings: input: add DT bindings for max77650
mfd: max77650: new core mfd driver
regulator: max77650: add regulator support
power: supply: max77650: add support for battery charger
gpio: max77650: add GPIO support
leds: max77650: add LEDs support
input: max77650: add onkey support
MAINTAINERS: add an entry for max77650 mfd driver
.../bindings/gpio/gpio-max77650.txt | 34 ++
.../bindings/input/max77650-onkey.txt | 26 +
.../bindings/leds/leds-max77650.txt | 57 ++
.../devicetree/bindings/mfd/max77650.txt | 28 +
.../power/supply/max77650-charger.txt | 27 +
.../bindings/regulator/max77650-regulator.txt | 41 ++
MAINTAINERS | 14 +
drivers/gpio/Kconfig | 7 +
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-max77650.c | 189 ++++++
drivers/input/misc/Kconfig | 9 +
drivers/input/misc/Makefile | 1 +
drivers/input/misc/max77650-onkey.c | 135 +++++
drivers/leds/Kconfig | 6 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-max77650.c | 162 ++++++
drivers/mfd/Kconfig | 11 +
drivers/mfd/Makefile | 1 +
drivers/mfd/max77650.c | 212 +++++++
drivers/power/supply/Kconfig | 7 +
drivers/power/supply/Makefile | 1 +
drivers/power/supply/max77650-charger.c | 347 +++++++++++
drivers/regulator/Kconfig | 8 +
drivers/regulator/Makefile | 1 +
drivers/regulator/max77650-regulator.c | 537 ++++++++++++++++++
include/linux/mfd/max77650.h | 73 +++
26 files changed, 1936 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-max77650.txt
create mode 100644 Documentation/devicetree/bindings/input/max77650-onkey.txt
create mode 100644 Documentation/devicetree/bindings/leds/leds-max77650.txt
create mode 100644 Documentation/devicetree/bindings/mfd/max77650.txt
create mode 100644 Documentation/devicetree/bindings/power/supply/max77650-charger.txt
create mode 100644 Documentation/devicetree/bindings/regulator/max77650-regulator.txt
create mode 100644 drivers/gpio/gpio-max77650.c
create mode 100644 drivers/input/misc/max77650-onkey.c
create mode 100644 drivers/leds/leds-max77650.c
create mode 100644 drivers/mfd/max77650.c
create mode 100644 drivers/power/supply/max77650-charger.c
create mode 100644 drivers/regulator/max77650-regulator.c
create mode 100644 include/linux/mfd/max77650.h
--
2.19.1
^ permalink raw reply
* RE: [PATCH 1/1] Input: elantech: Use SMBus based on bus info
From: 廖崇榮 @ 2019-01-18 9:29 UTC (permalink / raw)
To: 'Kai Heng Feng', 'Benjamin Tissoires'
Cc: 'Dmitry Torokhov', 'open list:HID CORE LAYER',
'lkml'
In-Reply-To: <0BD3A587-B7B6-4C99-8F87-187394FF6EFC@canonical.com>
-----Original Message-----
From: Kai Heng Feng [mailto:kai.heng.feng@canonical.com]
Sent: Friday, January 18, 2019 12:15 AM
To: Benjamin Tissoires
Cc: Dmitry Torokhov; 廖崇榮; open list:HID CORE LAYER; lkml
Subject: Re: [PATCH 1/1] Input: elantech: Use SMBus based on bus info
> On Jan 17, 2019, at 10:42 PM, Benjamin Tissoires
<benjamin.tissoires@redhat.com> wrote:
>
> Hi Kai-Heng,
>
> On Thu, Jan 17, 2019 at 10:30 AM Kai-Heng Feng
> <kai.heng.feng@canonical.com> wrote:
>>
>> There are some new HP laptops with Elantech touchpad don't support
>> multitouch.
>>
>> Both ETP_BUS_SMB_HST_NTFY_ONLY and ETP_BUS_PS2_SMB_HST_NTFY devices
>> can use SMBus to support 5 fingers touch, so we need to chech them too.
>>
>> So use elantech_use_host_notify() to do a more thouroughly check.
>>
>> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
>> ---
>> drivers/input/mouse/elantech.c | 58
>> +++++++++++++++++-----------------
>> 1 file changed, 29 insertions(+), 29 deletions(-)
>>
>> diff --git a/drivers/input/mouse/elantech.c
>> b/drivers/input/mouse/elantech.c index 9fe075c137dc..5bcf1c147eb1
>> 100644
>> --- a/drivers/input/mouse/elantech.c
>> +++ b/drivers/input/mouse/elantech.c
>> @@ -1799,6 +1799,34 @@ static int elantech_create_smbus(struct psmouse
*psmouse,
>> leave_breadcrumbs); }
>>
>> +static bool elantech_use_host_notify(struct psmouse *psmouse,
>> + struct elantech_device_info
>> +*info) {
>> + if (ETP_NEW_IC_SMBUS_HOST_NOTIFY(info->fw_version))
>> + return true;
>> +
>> + switch (info->bus) {
>> + case ETP_BUS_PS2_ONLY:
>> + /* expected case */
>> + break;
>> + case ETP_BUS_SMB_ALERT_ONLY:
>> + /* fall-through */
>> + case ETP_BUS_PS2_SMB_ALERT:
>> + psmouse_dbg(psmouse, "Ignoring SMBus provider through
alert protocol.\n");
>> + break;
>> + case ETP_BUS_SMB_HST_NTFY_ONLY:
>> + /* fall-through */
>> + case ETP_BUS_PS2_SMB_HST_NTFY:
>> + return true;
>> + default:
>> + psmouse_dbg(psmouse,
>> + "Ignoring SMBus bus provider %d.\n",
>> + info->bus);
>> + }
>> +
>> + return false;
>> +}
>> +
>> /**
>> * elantech_setup_smbus - called once the PS/2 devices are enumerated
>> * and decides to instantiate a SMBus InterTouch device.
>> @@ -1818,7 +1846,7 @@ static int elantech_setup_smbus(struct psmouse
*psmouse,
>> * i2c_blacklist_pnp_ids.
>> * Old ICs are up to the user to decide.
>> */
>> - if (!ETP_NEW_IC_SMBUS_HOST_NOTIFY(info->fw_version) ||
>> + if (!elantech_use_host_notify(psmouse, info) ||
>
> That was my initial approach of the series, but I ended up being more
> conservative as this would flip all of the existing elantech SMBUS
> capable touchpads to use elan_i2c.
> And I didn't want to deal with 4/5 year old laptops that suddenly broke.
>
> So I wonder if you can restrict this default change to the recent
> laptops (let's say 2018+). Maybe by looking at their FW version or
> something else in the DMI?
It was KT who told me that I should use ETP_BUS_PS2_SMB_HST_NTFY.
As for date, KT still knows better than me.
KT,
Can you name a year which is safe enough to enable SMBus?
I have discussed it internally.
The internal rule for FW's SMbus implementation is stable after 2018
If you meet some special case, please let me know.
BTW, The SMbus supporting is requested by HP this time, and there are plenty
of HP laptop use old IC
which doesn't meet " ETP_NEW_IC_SMBUS_HOST_NOTIFY".
Elan touchpad works well in PS/2 for HP, because it don't support
TrackPoint.
You may let old HP platform work as PS/2 for safety.
Thanks
KT
Kai-Heng
>
> Cheers,
> Benjamin
>
>> psmouse_matches_pnp_id(psmouse,
i2c_blacklist_pnp_ids))
>> return -ENXIO;
>> }
>> @@ -1838,34 +1866,6 @@ static int elantech_setup_smbus(struct psmouse
*psmouse,
>> return 0;
>> }
>>
>> -static bool elantech_use_host_notify(struct psmouse *psmouse,
>> - struct elantech_device_info *info)
>> -{
>> - if (ETP_NEW_IC_SMBUS_HOST_NOTIFY(info->fw_version))
>> - return true;
>> -
>> - switch (info->bus) {
>> - case ETP_BUS_PS2_ONLY:
>> - /* expected case */
>> - break;
>> - case ETP_BUS_SMB_ALERT_ONLY:
>> - /* fall-through */
>> - case ETP_BUS_PS2_SMB_ALERT:
>> - psmouse_dbg(psmouse, "Ignoring SMBus provider through
alert protocol.\n");
>> - break;
>> - case ETP_BUS_SMB_HST_NTFY_ONLY:
>> - /* fall-through */
>> - case ETP_BUS_PS2_SMB_HST_NTFY:
>> - return true;
>> - default:
>> - psmouse_dbg(psmouse,
>> - "Ignoring SMBus bus provider %d.\n",
>> - info->bus);
>> - }
>> -
>> - return false;
>> -}
>> -
>> int elantech_init_smbus(struct psmouse *psmouse) {
>> struct elantech_device_info info;
>> --
>> 2.17.1
^ permalink raw reply
* Re: [PATCH 1/1] Input: elantech: Use SMBus based on bus info
From: Kai Heng Feng @ 2019-01-17 16:14 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Dmitry Torokhov, 廖崇榮,
open list:HID CORE LAYER, lkml
In-Reply-To: <CAO-hwJKyBHM1Yy8=pQrbDoArTOX4=8G6f0jECv4x1mth+LZZDw@mail.gmail.com>
> On Jan 17, 2019, at 10:42 PM, Benjamin Tissoires <benjamin.tissoires@redhat.com> wrote:
>
> Hi Kai-Heng,
>
> On Thu, Jan 17, 2019 at 10:30 AM Kai-Heng Feng
> <kai.heng.feng@canonical.com> wrote:
>>
>> There are some new HP laptops with Elantech touchpad don't support
>> multitouch.
>>
>> Both ETP_BUS_SMB_HST_NTFY_ONLY and ETP_BUS_PS2_SMB_HST_NTFY devices can
>> use SMBus to support 5 fingers touch, so we need to chech them too.
>>
>> So use elantech_use_host_notify() to do a more thouroughly check.
>>
>> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
>> ---
>> drivers/input/mouse/elantech.c | 58 +++++++++++++++++-----------------
>> 1 file changed, 29 insertions(+), 29 deletions(-)
>>
>> diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
>> index 9fe075c137dc..5bcf1c147eb1 100644
>> --- a/drivers/input/mouse/elantech.c
>> +++ b/drivers/input/mouse/elantech.c
>> @@ -1799,6 +1799,34 @@ static int elantech_create_smbus(struct psmouse *psmouse,
>> leave_breadcrumbs);
>> }
>>
>> +static bool elantech_use_host_notify(struct psmouse *psmouse,
>> + struct elantech_device_info *info)
>> +{
>> + if (ETP_NEW_IC_SMBUS_HOST_NOTIFY(info->fw_version))
>> + return true;
>> +
>> + switch (info->bus) {
>> + case ETP_BUS_PS2_ONLY:
>> + /* expected case */
>> + break;
>> + case ETP_BUS_SMB_ALERT_ONLY:
>> + /* fall-through */
>> + case ETP_BUS_PS2_SMB_ALERT:
>> + psmouse_dbg(psmouse, "Ignoring SMBus provider through alert protocol.\n");
>> + break;
>> + case ETP_BUS_SMB_HST_NTFY_ONLY:
>> + /* fall-through */
>> + case ETP_BUS_PS2_SMB_HST_NTFY:
>> + return true;
>> + default:
>> + psmouse_dbg(psmouse,
>> + "Ignoring SMBus bus provider %d.\n",
>> + info->bus);
>> + }
>> +
>> + return false;
>> +}
>> +
>> /**
>> * elantech_setup_smbus - called once the PS/2 devices are enumerated
>> * and decides to instantiate a SMBus InterTouch device.
>> @@ -1818,7 +1846,7 @@ static int elantech_setup_smbus(struct psmouse *psmouse,
>> * i2c_blacklist_pnp_ids.
>> * Old ICs are up to the user to decide.
>> */
>> - if (!ETP_NEW_IC_SMBUS_HOST_NOTIFY(info->fw_version) ||
>> + if (!elantech_use_host_notify(psmouse, info) ||
>
> That was my initial approach of the series, but I ended up being more
> conservative as this would flip all of the existing elantech SMBUS
> capable touchpads to use elan_i2c.
> And I didn't want to deal with 4/5 year old laptops that suddenly broke.
>
> So I wonder if you can restrict this default change to the recent
> laptops (let's say 2018+). Maybe by looking at their FW version or
> something else in the DMI?
It was KT who told me that I should use ETP_BUS_PS2_SMB_HST_NTFY.
As for date, KT still knows better than me.
KT,
Can you name a year which is safe enough to enable SMBus?
Kai-Heng
>
> Cheers,
> Benjamin
>
>> psmouse_matches_pnp_id(psmouse, i2c_blacklist_pnp_ids))
>> return -ENXIO;
>> }
>> @@ -1838,34 +1866,6 @@ static int elantech_setup_smbus(struct psmouse *psmouse,
>> return 0;
>> }
>>
>> -static bool elantech_use_host_notify(struct psmouse *psmouse,
>> - struct elantech_device_info *info)
>> -{
>> - if (ETP_NEW_IC_SMBUS_HOST_NOTIFY(info->fw_version))
>> - return true;
>> -
>> - switch (info->bus) {
>> - case ETP_BUS_PS2_ONLY:
>> - /* expected case */
>> - break;
>> - case ETP_BUS_SMB_ALERT_ONLY:
>> - /* fall-through */
>> - case ETP_BUS_PS2_SMB_ALERT:
>> - psmouse_dbg(psmouse, "Ignoring SMBus provider through alert protocol.\n");
>> - break;
>> - case ETP_BUS_SMB_HST_NTFY_ONLY:
>> - /* fall-through */
>> - case ETP_BUS_PS2_SMB_HST_NTFY:
>> - return true;
>> - default:
>> - psmouse_dbg(psmouse,
>> - "Ignoring SMBus bus provider %d.\n",
>> - info->bus);
>> - }
>> -
>> - return false;
>> -}
>> -
>> int elantech_init_smbus(struct psmouse *psmouse)
>> {
>> struct elantech_device_info info;
>> --
>> 2.17.1
^ permalink raw reply
* Re: [PATCH 1/1] Input: elantech: Use SMBus based on bus info
From: Benjamin Tissoires @ 2019-01-17 14:42 UTC (permalink / raw)
To: Kai-Heng Feng
Cc: Dmitry Torokhov, 廖崇榮,
open list:HID CORE LAYER, lkml
In-Reply-To: <20190117092948.32079-1-kai.heng.feng@canonical.com>
Hi Kai-Heng,
On Thu, Jan 17, 2019 at 10:30 AM Kai-Heng Feng
<kai.heng.feng@canonical.com> wrote:
>
> There are some new HP laptops with Elantech touchpad don't support
> multitouch.
>
> Both ETP_BUS_SMB_HST_NTFY_ONLY and ETP_BUS_PS2_SMB_HST_NTFY devices can
> use SMBus to support 5 fingers touch, so we need to chech them too.
>
> So use elantech_use_host_notify() to do a more thouroughly check.
>
> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
> ---
> drivers/input/mouse/elantech.c | 58 +++++++++++++++++-----------------
> 1 file changed, 29 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
> index 9fe075c137dc..5bcf1c147eb1 100644
> --- a/drivers/input/mouse/elantech.c
> +++ b/drivers/input/mouse/elantech.c
> @@ -1799,6 +1799,34 @@ static int elantech_create_smbus(struct psmouse *psmouse,
> leave_breadcrumbs);
> }
>
> +static bool elantech_use_host_notify(struct psmouse *psmouse,
> + struct elantech_device_info *info)
> +{
> + if (ETP_NEW_IC_SMBUS_HOST_NOTIFY(info->fw_version))
> + return true;
> +
> + switch (info->bus) {
> + case ETP_BUS_PS2_ONLY:
> + /* expected case */
> + break;
> + case ETP_BUS_SMB_ALERT_ONLY:
> + /* fall-through */
> + case ETP_BUS_PS2_SMB_ALERT:
> + psmouse_dbg(psmouse, "Ignoring SMBus provider through alert protocol.\n");
> + break;
> + case ETP_BUS_SMB_HST_NTFY_ONLY:
> + /* fall-through */
> + case ETP_BUS_PS2_SMB_HST_NTFY:
> + return true;
> + default:
> + psmouse_dbg(psmouse,
> + "Ignoring SMBus bus provider %d.\n",
> + info->bus);
> + }
> +
> + return false;
> +}
> +
> /**
> * elantech_setup_smbus - called once the PS/2 devices are enumerated
> * and decides to instantiate a SMBus InterTouch device.
> @@ -1818,7 +1846,7 @@ static int elantech_setup_smbus(struct psmouse *psmouse,
> * i2c_blacklist_pnp_ids.
> * Old ICs are up to the user to decide.
> */
> - if (!ETP_NEW_IC_SMBUS_HOST_NOTIFY(info->fw_version) ||
> + if (!elantech_use_host_notify(psmouse, info) ||
That was my initial approach of the series, but I ended up being more
conservative as this would flip all of the existing elantech SMBUS
capable touchpads to use elan_i2c.
And I didn't want to deal with 4/5 year old laptops that suddenly broke.
So I wonder if you can restrict this default change to the recent
laptops (let's say 2018+). Maybe by looking at their FW version or
something else in the DMI?
Cheers,
Benjamin
> psmouse_matches_pnp_id(psmouse, i2c_blacklist_pnp_ids))
> return -ENXIO;
> }
> @@ -1838,34 +1866,6 @@ static int elantech_setup_smbus(struct psmouse *psmouse,
> return 0;
> }
>
> -static bool elantech_use_host_notify(struct psmouse *psmouse,
> - struct elantech_device_info *info)
> -{
> - if (ETP_NEW_IC_SMBUS_HOST_NOTIFY(info->fw_version))
> - return true;
> -
> - switch (info->bus) {
> - case ETP_BUS_PS2_ONLY:
> - /* expected case */
> - break;
> - case ETP_BUS_SMB_ALERT_ONLY:
> - /* fall-through */
> - case ETP_BUS_PS2_SMB_ALERT:
> - psmouse_dbg(psmouse, "Ignoring SMBus provider through alert protocol.\n");
> - break;
> - case ETP_BUS_SMB_HST_NTFY_ONLY:
> - /* fall-through */
> - case ETP_BUS_PS2_SMB_HST_NTFY:
> - return true;
> - default:
> - psmouse_dbg(psmouse,
> - "Ignoring SMBus bus provider %d.\n",
> - info->bus);
> - }
> -
> - return false;
> -}
> -
> int elantech_init_smbus(struct psmouse *psmouse)
> {
> struct elantech_device_info info;
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH] HID: i2c-hid: Disable runtime PM on Goodix touchpad
From: Benjamin Tissoires @ 2019-01-17 12:35 UTC (permalink / raw)
To: Kai-Heng Feng, Hans de Goede, anisse
Cc: Jiri Kosina, open list:HID CORE LAYER, lkml
In-Reply-To: <1897F291-4EB4-4E4B-87AA-3C16EF321340@canonical.com>
On Thu, Jan 17, 2019 at 12:41 PM Kai-Heng Feng
<kai.heng.feng@canonical.com> wrote:
>
>
>
> > On Jan 17, 2019, at 16:06, Benjamin Tissoires <benjamin.tissoires@redhat.com> wrote:
> >
> > On Thu, Jan 17, 2019 at 6:02 AM Kai-Heng Feng
> > <kai.heng.feng@canonical.com> wrote:
> [snipped]
> >> Goodix says the firmware needs at least 60ms to fully respond ON and
> >> SLEEP command.
> >
> > I was about to say that this is not conformant to the specification.
> > But looking at 7.2.8 SET_POWER of
> > https://docs.microsoft.com/en-us/previous-versions/windows/hardware/design/dn642101(v=vs.85)
> >
> > They say:
> > "The DEVICE must ensure that it transitions to the HOST specified
> > Power State in under 1 second. "
> > But in the RESPONSE paragraph: "The DEVICE shall not respond back
> > after receiving the command. The DEVICE is mandated to enter that
> > power state imminently."
> >
> > My interpretation was always that the device has to be in a ready
> > state for new commands "immediately".
> > However, the first sentence may suggest that the driver would block
> > any command to the device before the 1 second timestamp.
> >
> >>
> >> I’ll see if an 200ms autosuspend can solve all Goodix, LG and Raydium
> >> touchpanels.
> >
> > We already have a I2C_HID_QUIRK_DELAY_AFTER_SLEEP quirk that delay
> > operations after sleep by 20ms. Maybe we can keep the runtime PM but
> > use the same timers to not confuse the hardware.
>
> Yes, but wouldn’t use pm_*_autosuspend() helpers can both solve the issue
> and make the code more cleaner?
You are probably correct :)
I am not too familiar with the details of the runtime PM API, but if
you can make this a barrier to prevent the host to call too many
suspends/resumes in a row, that would be nice.
And we might be able to ditch I2C_HID_QUIRK_DELAY_AFTER_SLEEP and
I2C_HID_QUIRK_NO_RUNTIME_PM.
Adding the involved people in the thread.
Cheers,
Benjamin
^ permalink raw reply
* Re: [PATCH] HID: i2c-hid: Disable runtime PM on Goodix touchpad
From: Kai-Heng Feng @ 2019-01-17 11:41 UTC (permalink / raw)
To: Benjamin Tissoires; +Cc: Jiri Kosina, open list:HID CORE LAYER, lkml
In-Reply-To: <CAO-hwJLHm8b6X9kX1myz7xx1992VW2tVjdn6xw2n1MVX2dn0=g@mail.gmail.com>
> On Jan 17, 2019, at 16:06, Benjamin Tissoires <benjamin.tissoires@redhat.com> wrote:
>
> On Thu, Jan 17, 2019 at 6:02 AM Kai-Heng Feng
> <kai.heng.feng@canonical.com> wrote:
[snipped]
>> Goodix says the firmware needs at least 60ms to fully respond ON and
>> SLEEP command.
>
> I was about to say that this is not conformant to the specification.
> But looking at 7.2.8 SET_POWER of
> https://docs.microsoft.com/en-us/previous-versions/windows/hardware/design/dn642101(v=vs.85)
>
> They say:
> "The DEVICE must ensure that it transitions to the HOST specified
> Power State in under 1 second. "
> But in the RESPONSE paragraph: "The DEVICE shall not respond back
> after receiving the command. The DEVICE is mandated to enter that
> power state imminently."
>
> My interpretation was always that the device has to be in a ready
> state for new commands "immediately".
> However, the first sentence may suggest that the driver would block
> any command to the device before the 1 second timestamp.
>
>>
>> I’ll see if an 200ms autosuspend can solve all Goodix, LG and Raydium
>> touchpanels.
>
> We already have a I2C_HID_QUIRK_DELAY_AFTER_SLEEP quirk that delay
> operations after sleep by 20ms. Maybe we can keep the runtime PM but
> use the same timers to not confuse the hardware.
Yes, but wouldn’t use pm_*_autosuspend() helpers can both solve the issue
and make the code more cleaner?
Kai-Heng
>
> Cheers,
> Benjamin
^ permalink raw reply
* [PATCH 1/1] Input: elantech: Use SMBus based on bus info
From: Kai-Heng Feng @ 2019-01-17 9:29 UTC (permalink / raw)
To: dmitry.torokhov
Cc: benjamin.tissoires, kt.liao, linux-input, linux-kernel,
Kai-Heng Feng
There are some new HP laptops with Elantech touchpad don't support
multitouch.
Both ETP_BUS_SMB_HST_NTFY_ONLY and ETP_BUS_PS2_SMB_HST_NTFY devices can
use SMBus to support 5 fingers touch, so we need to chech them too.
So use elantech_use_host_notify() to do a more thouroughly check.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
---
drivers/input/mouse/elantech.c | 58 +++++++++++++++++-----------------
1 file changed, 29 insertions(+), 29 deletions(-)
diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
index 9fe075c137dc..5bcf1c147eb1 100644
--- a/drivers/input/mouse/elantech.c
+++ b/drivers/input/mouse/elantech.c
@@ -1799,6 +1799,34 @@ static int elantech_create_smbus(struct psmouse *psmouse,
leave_breadcrumbs);
}
+static bool elantech_use_host_notify(struct psmouse *psmouse,
+ struct elantech_device_info *info)
+{
+ if (ETP_NEW_IC_SMBUS_HOST_NOTIFY(info->fw_version))
+ return true;
+
+ switch (info->bus) {
+ case ETP_BUS_PS2_ONLY:
+ /* expected case */
+ break;
+ case ETP_BUS_SMB_ALERT_ONLY:
+ /* fall-through */
+ case ETP_BUS_PS2_SMB_ALERT:
+ psmouse_dbg(psmouse, "Ignoring SMBus provider through alert protocol.\n");
+ break;
+ case ETP_BUS_SMB_HST_NTFY_ONLY:
+ /* fall-through */
+ case ETP_BUS_PS2_SMB_HST_NTFY:
+ return true;
+ default:
+ psmouse_dbg(psmouse,
+ "Ignoring SMBus bus provider %d.\n",
+ info->bus);
+ }
+
+ return false;
+}
+
/**
* elantech_setup_smbus - called once the PS/2 devices are enumerated
* and decides to instantiate a SMBus InterTouch device.
@@ -1818,7 +1846,7 @@ static int elantech_setup_smbus(struct psmouse *psmouse,
* i2c_blacklist_pnp_ids.
* Old ICs are up to the user to decide.
*/
- if (!ETP_NEW_IC_SMBUS_HOST_NOTIFY(info->fw_version) ||
+ if (!elantech_use_host_notify(psmouse, info) ||
psmouse_matches_pnp_id(psmouse, i2c_blacklist_pnp_ids))
return -ENXIO;
}
@@ -1838,34 +1866,6 @@ static int elantech_setup_smbus(struct psmouse *psmouse,
return 0;
}
-static bool elantech_use_host_notify(struct psmouse *psmouse,
- struct elantech_device_info *info)
-{
- if (ETP_NEW_IC_SMBUS_HOST_NOTIFY(info->fw_version))
- return true;
-
- switch (info->bus) {
- case ETP_BUS_PS2_ONLY:
- /* expected case */
- break;
- case ETP_BUS_SMB_ALERT_ONLY:
- /* fall-through */
- case ETP_BUS_PS2_SMB_ALERT:
- psmouse_dbg(psmouse, "Ignoring SMBus provider through alert protocol.\n");
- break;
- case ETP_BUS_SMB_HST_NTFY_ONLY:
- /* fall-through */
- case ETP_BUS_PS2_SMB_HST_NTFY:
- return true;
- default:
- psmouse_dbg(psmouse,
- "Ignoring SMBus bus provider %d.\n",
- info->bus);
- }
-
- return false;
-}
-
int elantech_init_smbus(struct psmouse *psmouse)
{
struct elantech_device_info info;
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] input: misc: pwm-vibra: Prevent unbalanced regulator
From: Paweł Chmiel @ 2019-01-17 8:44 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-kernel, Jonathan Bakker
In-Reply-To: <20190117070838.GA8109@dtor-ws>
czw., 17 sty 2019 o 08:08 Dmitry Torokhov <dmitry.torokhov@gmail.com>
napisał(a):
>
> Hi Paweł,
>
> On Wed, Jan 16, 2019 at 10:11:31PM +0100, Paweł Chmiel wrote:
> > From: Jonathan Bakker <xc-racer2@live.ca>
> >
> > pwm_vibrator_stop disables the regulator, but it can be called from
> > multiple places, even when the regulator is already disabled. Fix this
> > by using regulator_is_enabled check when starting and stopping device.
> >
> > Signed-off-by: Jonathan Bakker <xc-racer2@live.ca>
> > Signed-off-by: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
> > ---
> > drivers/input/misc/pwm-vibra.c | 13 ++++++++-----
> > 1 file changed, 8 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/input/misc/pwm-vibra.c b/drivers/input/misc/pwm-vibra.c
> > index 55da191ae550..66677ee770ca 100644
> > --- a/drivers/input/misc/pwm-vibra.c
> > +++ b/drivers/input/misc/pwm-vibra.c
> > @@ -42,10 +42,12 @@ static int pwm_vibrator_start(struct pwm_vibrator *vibrator)
> > struct pwm_state state;
> > int err;
> >
> > - err = regulator_enable(vibrator->vcc);
> > - if (err) {
> > - dev_err(pdev, "failed to enable regulator: %d", err);
> > - return err;
> > + if (!regulator_is_enabled(vibrator->vcc)) {
>
> I do not think this is correct in case of shared supply, as this checks
> global state of regulator. That means that if there is another user, we
> may forego enabling regulator here, and that anther user may power it
> down and vibrator will stop working.
>
> I think you need a local flag here.
Ok will fix this (funny that in first version of patch there was such flag).
>
> > + err = regulator_enable(vibrator->vcc);
> > + if (err) {
> > + dev_err(pdev, "failed to enable regulator: %d", err);
> > + return err;
> > + }
> > }
> >
> > pwm_get_state(vibrator->pwm, &state);
> > @@ -76,7 +78,8 @@ static int pwm_vibrator_start(struct pwm_vibrator *vibrator)
> >
> > static void pwm_vibrator_stop(struct pwm_vibrator *vibrator)
> > {
> > - regulator_disable(vibrator->vcc);
> > + if (regulator_is_enabled(vibrator->vcc))
> > + regulator_disable(vibrator->vcc);
>
> Looking at this, I wonder if we should not disable PWMs first and the
> disable regulator.
I will create and send separate patch for this.
Thanks for review
>
> >
> > if (vibrator->pwm_dir)
> > pwm_disable(vibrator->pwm_dir);
> > --
> > 2.17.1
> >
>
> Thanks.
>
> --
> Dmitry
^ permalink raw reply
* Re: [PATCH] Input: synaptics - add PNP IDs for Dell XPS models to forcepad
From: Benjamin Tissoires @ 2019-01-17 8:13 UTC (permalink / raw)
To: Kim Phillips; +Cc: Dmitry Torokhov, lkml, Paul Menzel, open list:HID CORE LAYER
In-Reply-To: <4f0e0b88-c13a-a064-3a13-4d8abca252b3@kimphillips.com>
On Wed, Jan 16, 2019 at 5:59 AM Kim Phillips <kim@kimphillips.com> wrote:
>
> On 1/15/19 2:57 AM, Benjamin Tissoires wrote:
> > On Mon, Jan 14, 2019 at 7:40 PM Dmitry Torokhov
> > <dmitry.torokhov@gmail.com> wrote:
> >>
> >> On Sat, Jan 12, 2019 at 04:04:36PM -0600, Kim Phillips wrote:
> >>> On 1/11/19 7:40 PM, Dmitry Torokhov wrote:
> >>>> Hi Kim,
> >>>
> >>> Hi Dmitry,
> >>>
> >>>> On Fri, Jan 11, 2019 at 02:54:30PM -0600, Kim Phillips wrote:
> >>>>> This patch is the result of seeing this message:
> >>>>>
> >>>>> psmouse serio1: synaptics: Your touchpad (PNP: DLL087c PNP0f13) says it can support a different bus. If i2c-hid and hid-rmi are not used, you might want to try setting psmouse.synaptics_intertouch to 1 and report this to linux-input@vger.kernel.org.
> >>>>>
> >>>>> If I set psmouse.synaptics_intertouch=1, or add the PNP ID to
> >>>>> smbus_pnp_ids, the touchpad continues to work, and the above message
> >>>>> goes away, but we now get:
> >>>>>
> >>>>> psmouse serio1: synaptics: Trying to set up SMBus access
> >>>>> psmouse serio1: synaptics: SMbus companion is not ready yet
> >>>>>
> >>>>> With this patch applied, i.e., the PNP IDs are added to the forcepad
> >>>>> array, the touchpad continues to work and all of the above messages
> >>>>> disappear.
> >>>>
> >>>> Are you sure the touchpad in XPSes is a forcepad (i.e. it does not have
> >>>> physical button underneath it)? As far as I know there were only couple
> >>>> of HP laptops with forcepads and when switching to RMI mode forcepads
> >>>> need F21 handler that we do not currently have in the kernel.
> >>>
> >>> I see, no, I'm not sure, but assuming you're right, the IDs
> >>> should be added to the smbus array instead, after fixing
> >>> the SMbus "companion not ready" problem? Pointers for that and
> >>> the below interrupts when touchpad idle after resume, welcome.
> >>>
> >>> Also, the link to get the RMI4 spec in
> >>> Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt
> >>> is broken. Any pointers for that also appreciated.
> >>
> >> OK, sorting it all out some more:
> >>
> >> - because we do not have support for F21 necessary for forcepads adding
> >> APIC ID to forcepad list actuallty disables SMbus companion mode, that
> >> is why you no longer see "companion not ready" messages vs. setting
> >> psmouse.synaptics_intertouch=1 module parameter.
> >
> > Yep
> >
> >>
> >> - this does not really matter as your touchpad ends up being driven by
> >> i2c-hid and hid-multitouch drivers, and that is how we wait it to
> >> work, as we do not want to deviate from behavior on Windows since OEM
> >> tested it (the device and firmware) in tha configuration.
> >
> > Yep too. The I2C-hid touchpads from Synaptics do not have the SMBus
> > wired at all, so we can't enable SMBus for them. Also, the fact that
> > the device gets loaded over i2c-hid means that we can't know that it
> > is the case from the psmouse/synaptics point of view.
>
> Sigh, OK, I wasn't registering the word "not" when reading
> "If i2c-hid and hid-rmi are not used" too quickly.
>
> >> - we need to figure out issue with interrupts on resume, maybe Benjamin
> >> have seen it?
> >
> > First time I see it.
> >
> > I just tried on a XPS 9360 and kernel v4.18 (fedora) and nothing was a problem.
> > I then tried on a XPS 9575 with v4.19, and here, the wacom I2C node is
> > also keeping firing the interrupts, but not the touchpad. However,
> > here, the interrupts are not stopping when I touch the touchscreen or
> > if I approach a pen.
> >
> > Kim, rmmod-ing i2c-hid and modprobing back it with the parameter
> > debug=1 doesn't show any events processed when the interrupts are
> > firing. Do you see the same?
>
> After rmmodding i2c_hid, the WCOM488F and SYNA2393 entries in /proc/interrupts
> somewhat expectedly disappear, however, the modprobe (with or without debug=1)
> fails to bring them back, with these messages left in dmesg:
>
> [ 3882.073222] calling i2c_hid_driver_init+0x0/0x1000 [i2c_hid] @ 3082
> [ 3882.180938] i2c_hid i2c-WCOM488F:00: HID over i2c has not been provided an Int IRQ
> [ 3882.181060] i2c_hid: probe of i2c-WCOM488F:00 failed with error -22
> [ 3882.181065] probe of i2c-WCOM488F:00 returned 0 after 496 usecs
> [ 3882.289196] i2c_hid i2c-SYNA2393:00: HID over i2c has not been provided an Int IRQ
> [ 3882.289318] i2c_hid: probe of i2c-SYNA2393:00 failed with error -22
> [ 3882.289321] probe of i2c-SYNA2393:00 returned 0 after 508 usecs
> [ 3882.289418] initcall i2c_hid_driver_init+0x0/0x1000 [i2c_hid] returned 0 after 211119 usecs
Yes, that is a weird behavior I experience the other day also. It
looks like rmmod-ing the driver simply kills the irq description
attached to the i2c node. This waasn't the case previously, and I
wonder if the issue is in i2c-hid (unlikely) or in i2c-core.
>
> In order to work around that problem, I set h2c_hid.debug=1 in the
> boot command line, and after a resume, dmesg contains these messages,
> relevant to i2c_hid:
>
> [ 267.235673] i2c_hid i2c-WCOM488F:00: calling i2c_hid_resume+0x0/0x140 [i2c_hid] @ 3078, parent: i2c-9
> [ 267.235676] input input16: calling input_dev_resume+0x0/0x50 @ 3060, parent: card0
> [ 267.235681] input input16: input_dev_resume+0x0/0x50 returned 0 after 0 usecs
> [ 267.235682] i2c_hid i2c-WCOM488F:00: i2c_hid_set_power
> [ 267.235687] input input17: calling input_dev_resume+0x0/0x50 @ 3060, parent: card0
> [ 267.235689] i2c_hid i2c-WCOM488F:00: __i2c_hid_command: cmd=04 00 00 08
> [ 267.235693] input input17: input_dev_resume+0x0/0x50 returned 0 after 0 usecs
> [ 267.235698] idma64 idma64.1: calling platform_pm_resume+0x0/0x50 @ 3060, parent: 0000:00:15.1
> [ 267.235701] idma64 idma64.1: platform_pm_resume+0x0/0x50 returned 0 after 0 usecs
> [ 267.235706] i2c_designware i2c_designware.1: calling platform_pm_resume+0x0/0x50 @ 3060, parent: 0000:00:15.1
> [ 267.235709] i2c_designware i2c_designware.1: platform_pm_resume+0x0/0x50 returned 0 after 0 usecs
> [ 267.235718] rfkill rfkill0: calling rfkill_resume+0x0/0x60 @ 3060, parent: phy0
> [ 267.235724] rfkill rfkill0: rfkill_resume+0x0/0x60 returned 0 after 3 usecs
> [ 267.235768] i2c_hid i2c-SYNA2393:00: calling i2c_hid_resume+0x0/0x140 [i2c_hid] @ 3108, parent: i2c-10
> [ 267.235774] i2c_hid i2c-SYNA2393:00: i2c_hid_set_power
> [ 267.235776] i2c_hid i2c-SYNA2393:00: __i2c_hid_command: cmd=22 00 00 08
> [ 267.236051] i2c_hid i2c-SYNA2393:00: i2c_hid_set_or_send_report
> [ 267.236053] i2c_hid i2c-SYNA2393:00: __i2c_hid_command: cmd=22 00 3d 03 23 00 04 00 0d 00
> [ 267.236076] i2c_hid i2c-WCOM488F:00: i2c_hid_set_or_send_report
> [ 267.236080] i2c_hid i2c-WCOM488F:00: __i2c_hid_command: cmd=04 00 3b 03 05 00 42 00 0b 00 fd 89 a3 07 f3 02 20 8d 49 06 d7 9c ff ff 80 59 5c 13 d7 9c ff ff 08 00 00 08 d7 9c ff ff 01 00 00 00 00 00 00 00 16 00 00 00 66 69 6c 65 75 74 6c 2e 6d 65 73 73
> [ 267.237691] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
> [ 267.238137] i2c_hid i2c-SYNA2393:00: i2c_hid_set_or_send_report
> [ 267.238140] i2c_hid i2c-SYNA2393:00: __i2c_hid_command: cmd=22 00 34 03 23 00 04 00 04 03
> [ 267.238670] i2c_hid i2c-WCOM488F:00: i2c_hid_get_report
> [ 267.238673] i2c_hid i2c-WCOM488F:00: __i2c_hid_command: cmd=04 00 3b 02 05 00
> [ 267.239708] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
> [ 267.240084] i2c_hid i2c-SYNA2393:00: i2c_hid_set_or_send_report
> [ 267.240087] i2c_hid i2c-SYNA2393:00: __i2c_hid_command: cmd=22 00 36 03 23 00 04 00 06 03
> [ 267.241377] i2c_hid i2c-WCOM488F:00: i2c_hid_set_or_send_report
> [ 267.241380] i2c_hid i2c-WCOM488F:00: __i2c_hid_command: cmd=04 00 3b 03 05 00 42 00 0b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [ 267.241711] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
> [ 267.243279] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
> [ 267.243981] i2c_hid i2c-WCOM488F:00: i2c_hid_get_report
> [ 267.243984] i2c_hid i2c-WCOM488F:00: __i2c_hid_command: cmd=04 00 3b 02 05 00
> [ 267.244847] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
> [ 267.245360] i2c_hid i2c-SYNA2393:00: i2c_hid_resume+0x0/0x140 [i2c_hid] returned 0 after 9360 usecs
> [ 267.245455] input input27: calling input_dev_resume+0x0/0x50 @ 3060, parent: 0018:06CB:7A13.0002
> [ 267.245460] input input27: input_dev_resume+0x0/0x50 returned 0 after 0 usecs
> [ 267.246773] i2c_hid i2c-WCOM488F:00: i2c_hid_set_or_send_report
> [ 267.246777] i2c_hid i2c-WCOM488F:00: __i2c_hid_command: cmd=04 00 3b 03 05 00 42 00 0b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [ 267.246919] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
> [ 267.248517] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
> [ 267.249383] i2c_hid i2c-WCOM488F:00: i2c_hid_get_report
> [ 267.249386] i2c_hid i2c-WCOM488F:00: __i2c_hid_command: cmd=04 00 3b 02 05 00
> [ 267.250116] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
> [ 267.251767] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
> [ 267.252137] i2c_hid i2c-WCOM488F:00: i2c_hid_set_or_send_report
> [ 267.252140] i2c_hid i2c-WCOM488F:00: __i2c_hid_command: cmd=04 00 3b 03 05 00 42 00 0b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [ 267.253440] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
> [ 267.254734] i2c_hid i2c-WCOM488F:00: i2c_hid_get_report
> [ 267.254737] i2c_hid i2c-WCOM488F:00: __i2c_hid_command: cmd=04 00 3b 02 05 00
> [ 267.255015] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
> [ 267.256612] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
> [ 267.257475] i2c_hid i2c-WCOM488F:00: i2c_hid_set_or_send_report
> [ 267.257478] i2c_hid i2c-WCOM488F:00: __i2c_hid_command: cmd=04 00 3b 03 05 00 42 00 0b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [ 267.258275] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
> [ 267.259852] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
> [ 267.260046] i2c_hid i2c-WCOM488F:00: i2c_hid_get_report
> [ 267.260049] i2c_hid i2c-WCOM488F:00: __i2c_hid_command: cmd=04 00 3b 02 05 00
> [ 267.261441] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
> [ 267.262789] i2c_hid i2c-WCOM488F:00: i2c_hid_set_or_send_report
> [ 267.262792] i2c_hid i2c-WCOM488F:00: __i2c_hid_command: cmd=04 00 3b 03 05 00 42 00 0b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [ 267.263129] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
> [ 267.264718] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
> [ 267.265410] i2c_hid i2c-WCOM488F:00: i2c_hid_get_report
> [ 267.265413] i2c_hid i2c-WCOM488F:00: __i2c_hid_command: cmd=04 00 3b 02 05 00
> [ 267.266318] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
> [ 267.267971] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
> [ 267.268169] i2c_hid i2c-WCOM488F:00: i2c_hid_set_or_send_report
> [ 267.268172] i2c_hid i2c-WCOM488F:00: __i2c_hid_command: cmd=04 00 3e 03 05 00 05 00 0e 02 00
> [ 267.268728] i2c_hid i2c-WCOM488F:00: i2c_hid_resume+0x0/0x140 [i2c_hid] returned 0 after 32273 usecs
> [ 267.269575] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
> [ 267.271144] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
> [ 267.272719] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
> [ 267.274298] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
>
> ...and it goes on and on, where that same last line gets
> repeated as the interrupts fire, until I start using the touchpad,
> thereby stopping the interrupts.
It looks like valid inputs. So I would expect the firmware to unset
the IRQ line, but it doesn't do it.
On an other thread, it has been brought to my attention that maybe we
are not 100% compatible with the Windows driver regarding
sleep/power_on commands. We expect the device to be ready while the
Windows driver waits a little before sending a command. Maybe we can
try to see if adding I2C_HID_QUIRK_DELAY_AFTER_SLEEP to this device
changes something.
>
> I'm not seeing any such bad behaviour from the WCOM device.
In my case, the reports have a size of 0, so they are firing but
nothing is processed (though i2c fetches the reports).
I'll need to investigate all of these.
Cheers,
Benjamin
^ permalink raw reply
* Re: [PATCH] HID: i2c-hid: Disable runtime PM on Goodix touchpad
From: Benjamin Tissoires @ 2019-01-17 8:06 UTC (permalink / raw)
To: Kai-Heng Feng; +Cc: Jiri Kosina, open list:HID CORE LAYER, lkml
In-Reply-To: <2149AEF5-ABBF-4745-89F9-7FF9719251B5@canonical.com>
On Thu, Jan 17, 2019 at 6:02 AM Kai-Heng Feng
<kai.heng.feng@canonical.com> wrote:
>
>
>
> > On Jan 16, 2019, at 16:21, Kai Heng Feng <kai.heng.feng@canonical.com> wrote:
> >
> >
> >
> >> On Jan 14, 2019, at 19:18, Jiri Kosina <jikos@kernel.org> wrote:
> >>
> >> On Mon, 14 Jan 2019, Kai-Heng Feng wrote:
> >>
> >>> A Goodix touchpad doesn't work. Touching the touchpad can trigger IRQ
> >>> but there's no input event from HID subsystem.
> >>>
> >>> Turns out it reports some invalid data:
> >>> [ 22.136630] i2c_hid i2c-DELL091F:00: input: 0b 00 01 00 00 00 00 00 00 00 00
> >>>
> >>> After some trial and error, it's another device that doesn't work well
> >>> with ON/SLEEP commands. Disable runtime PM to fix the issue.
> >>
> >> Thanks, I've now applied the patch to for-5.0/upstream-fixes. I am
> >> wondering though we are we seeing these at all - do other OSes not do the
> >> runtime PM on i2c at all?
> >
> > According to the vendor, Windows does use ON/SLEEP, but infrequently.
> >
> > We can use pm_runtime_use_autosuspend() to reduce the frequency of
> > ON/SLEEP commands, but it’s just papering over the touchpad firmware
> > bug.
>
> Goodix says the firmware needs at least 60ms to fully respond ON and
> SLEEP command.
I was about to say that this is not conformant to the specification.
But looking at 7.2.8 SET_POWER of
https://docs.microsoft.com/en-us/previous-versions/windows/hardware/design/dn642101(v=vs.85)
They say:
"The DEVICE must ensure that it transitions to the HOST specified
Power State in under 1 second. "
But in the RESPONSE paragraph: "The DEVICE shall not respond back
after receiving the command. The DEVICE is mandated to enter that
power state imminently."
My interpretation was always that the device has to be in a ready
state for new commands "immediately".
However, the first sentence may suggest that the driver would block
any command to the device before the 1 second timestamp.
>
> I’ll see if an 200ms autosuspend can solve all Goodix, LG and Raydium
> touchpanels.
We already have a I2C_HID_QUIRK_DELAY_AFTER_SLEEP quirk that delay
operations after sleep by 20ms. Maybe we can keep the runtime PM but
use the same timers to not confuse the hardware.
Cheers,
Benjamin
^ permalink raw reply
* Re: [PATCH] Input: olpc_apsp - assign priv->dev earlier
From: Dmitry Torokhov @ 2019-01-17 7:12 UTC (permalink / raw)
To: Lubomir Rintel; +Cc: linux-input, linux-kernel, stable
In-Reply-To: <20190116094438.1921667-1-lkundrak@v3.sk>
On Wed, Jan 16, 2019 at 10:44:38AM +0100, Lubomir Rintel wrote:
> The dev field needs to be set when serio_register_port() is called,
> because the open callback may use it (in the error handling path).
>
> Cc: stable@vger.kernel.org # v4.18+
> Fixes: commit af518342effd ("Input: olpc_apsp - check FIFO status on open(), not probe()")
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Applied, thank you.
> ---
> drivers/input/serio/olpc_apsp.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/input/serio/olpc_apsp.c b/drivers/input/serio/olpc_apsp.c
> index 0aece9777087..554f4b8228d2 100644
> --- a/drivers/input/serio/olpc_apsp.c
> +++ b/drivers/input/serio/olpc_apsp.c
> @@ -198,6 +198,8 @@ static int olpc_apsp_probe(struct platform_device *pdev)
> if (!priv)
> return -ENOMEM;
>
> + priv->dev = &pdev->dev;
> +
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> priv->base = devm_ioremap_resource(&pdev->dev, res);
> if (IS_ERR(priv->base)) {
> @@ -261,7 +263,6 @@ static int olpc_apsp_probe(struct platform_device *pdev)
> goto err_irq;
> }
>
> - priv->dev = &pdev->dev;
> device_init_wakeup(priv->dev, 1);
> platform_set_drvdata(pdev, priv);
>
> --
> 2.20.1
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH] input: misc: pwm-vibra: Prevent unbalanced regulator
From: Dmitry Torokhov @ 2019-01-17 7:08 UTC (permalink / raw)
To: Paweł Chmiel; +Cc: linux-input, linux-kernel, Jonathan Bakker
In-Reply-To: <20190116211131.18809-1-pawel.mikolaj.chmiel@gmail.com>
Hi Paweł,
On Wed, Jan 16, 2019 at 10:11:31PM +0100, Paweł Chmiel wrote:
> From: Jonathan Bakker <xc-racer2@live.ca>
>
> pwm_vibrator_stop disables the regulator, but it can be called from
> multiple places, even when the regulator is already disabled. Fix this
> by using regulator_is_enabled check when starting and stopping device.
>
> Signed-off-by: Jonathan Bakker <xc-racer2@live.ca>
> Signed-off-by: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
> ---
> drivers/input/misc/pwm-vibra.c | 13 ++++++++-----
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/input/misc/pwm-vibra.c b/drivers/input/misc/pwm-vibra.c
> index 55da191ae550..66677ee770ca 100644
> --- a/drivers/input/misc/pwm-vibra.c
> +++ b/drivers/input/misc/pwm-vibra.c
> @@ -42,10 +42,12 @@ static int pwm_vibrator_start(struct pwm_vibrator *vibrator)
> struct pwm_state state;
> int err;
>
> - err = regulator_enable(vibrator->vcc);
> - if (err) {
> - dev_err(pdev, "failed to enable regulator: %d", err);
> - return err;
> + if (!regulator_is_enabled(vibrator->vcc)) {
I do not think this is correct in case of shared supply, as this checks
global state of regulator. That means that if there is another user, we
may forego enabling regulator here, and that anther user may power it
down and vibrator will stop working.
I think you need a local flag here.
> + err = regulator_enable(vibrator->vcc);
> + if (err) {
> + dev_err(pdev, "failed to enable regulator: %d", err);
> + return err;
> + }
> }
>
> pwm_get_state(vibrator->pwm, &state);
> @@ -76,7 +78,8 @@ static int pwm_vibrator_start(struct pwm_vibrator *vibrator)
>
> static void pwm_vibrator_stop(struct pwm_vibrator *vibrator)
> {
> - regulator_disable(vibrator->vcc);
> + if (regulator_is_enabled(vibrator->vcc))
> + regulator_disable(vibrator->vcc);
Looking at this, I wonder if we should not disable PWMs first and the
disable regulator.
>
> if (vibrator->pwm_dir)
> pwm_disable(vibrator->pwm_dir);
> --
> 2.17.1
>
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] HID: i2c-hid: Disable runtime PM on Goodix touchpad
From: Kai-Heng Feng @ 2019-01-17 5:02 UTC (permalink / raw)
To: Jiri Kosina; +Cc: benjamin.tissoires, linux-input, linux-kernel
In-Reply-To: <663EE74C-02E8-49DB-A197-2022AFE2D863@canonical.com>
> On Jan 16, 2019, at 16:21, Kai Heng Feng <kai.heng.feng@canonical.com> wrote:
>
>
>
>> On Jan 14, 2019, at 19:18, Jiri Kosina <jikos@kernel.org> wrote:
>>
>> On Mon, 14 Jan 2019, Kai-Heng Feng wrote:
>>
>>> A Goodix touchpad doesn't work. Touching the touchpad can trigger IRQ
>>> but there's no input event from HID subsystem.
>>>
>>> Turns out it reports some invalid data:
>>> [ 22.136630] i2c_hid i2c-DELL091F:00: input: 0b 00 01 00 00 00 00 00 00 00 00
>>>
>>> After some trial and error, it's another device that doesn't work well
>>> with ON/SLEEP commands. Disable runtime PM to fix the issue.
>>
>> Thanks, I've now applied the patch to for-5.0/upstream-fixes. I am
>> wondering though we are we seeing these at all - do other OSes not do the
>> runtime PM on i2c at all?
>
> According to the vendor, Windows does use ON/SLEEP, but infrequently.
>
> We can use pm_runtime_use_autosuspend() to reduce the frequency of
> ON/SLEEP commands, but it’s just papering over the touchpad firmware
> bug.
Goodix says the firmware needs at least 60ms to fully respond ON and
SLEEP command.
I’ll see if an 200ms autosuspend can solve all Goodix, LG and Raydium
touchpanels.
Kai-Heng
>
> Kai-Heng
>
>>
>> --
>> Jiri Kosina
>> SUSE Labs
^ permalink raw reply
* [PATCH] input: misc: pwm-vibra: Prevent unbalanced regulator
From: Paweł Chmiel @ 2019-01-16 21:11 UTC (permalink / raw)
To: dmitry.torokhov
Cc: linux-input, linux-kernel, Jonathan Bakker, Paweł Chmiel
From: Jonathan Bakker <xc-racer2@live.ca>
pwm_vibrator_stop disables the regulator, but it can be called from
multiple places, even when the regulator is already disabled. Fix this
by using regulator_is_enabled check when starting and stopping device.
Signed-off-by: Jonathan Bakker <xc-racer2@live.ca>
Signed-off-by: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
---
drivers/input/misc/pwm-vibra.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/input/misc/pwm-vibra.c b/drivers/input/misc/pwm-vibra.c
index 55da191ae550..66677ee770ca 100644
--- a/drivers/input/misc/pwm-vibra.c
+++ b/drivers/input/misc/pwm-vibra.c
@@ -42,10 +42,12 @@ static int pwm_vibrator_start(struct pwm_vibrator *vibrator)
struct pwm_state state;
int err;
- err = regulator_enable(vibrator->vcc);
- if (err) {
- dev_err(pdev, "failed to enable regulator: %d", err);
- return err;
+ if (!regulator_is_enabled(vibrator->vcc)) {
+ err = regulator_enable(vibrator->vcc);
+ if (err) {
+ dev_err(pdev, "failed to enable regulator: %d", err);
+ return err;
+ }
}
pwm_get_state(vibrator->pwm, &state);
@@ -76,7 +78,8 @@ static int pwm_vibrator_start(struct pwm_vibrator *vibrator)
static void pwm_vibrator_stop(struct pwm_vibrator *vibrator)
{
- regulator_disable(vibrator->vcc);
+ if (regulator_is_enabled(vibrator->vcc))
+ regulator_disable(vibrator->vcc);
if (vibrator->pwm_dir)
pwm_disable(vibrator->pwm_dir);
--
2.17.1
^ permalink raw reply related
* [GIT PULL] Immutable branch between MFD, Input and Watchdog due for the v5.1 merge window
From: Lee Jones @ 2019-01-16 14:04 UTC (permalink / raw)
To: Pascal PAILLET-LME
Cc: dmitry.torokhov@gmail.com, robh+dt@kernel.org,
mark.rutland@arm.com, lgirdwood@gmail.com, broonie@kernel.org,
wim@linux-watchdog.org, linux@roeck-us.net,
linux-input@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-watchdog@vger.kernel.org,
benjamin.gaignard@linaro.org, eballetbo@gmail.com,
axel.lin@ingics.com
In-Reply-To: <1547460290-21049-1-git-send-email-p.paillet@st.com>
Enjoy!
The following changes since commit bfeffd155283772bbe78c6a05dec7c0128ee500c:
Linux 5.0-rc1 (2019-01-06 17:08:20 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git ib-mfd-input-watchdog-v5.1
for you to fetch changes up to 28804c2c8fb3401aa4b7f16a883d49dd82f5e377:
watchdog: stpmic1: Add STPMIC1 watchdog driver (2019-01-16 14:01:19 +0000)
----------------------------------------------------------------
Immutable branch between MFD, Input and Watchdog due for the v5.1 merge window
----------------------------------------------------------------
Pascal PAILLET-LME (6):
dt-bindings: mfd: Document STPMIC1
mfd: stpmic1: Add STPMIC1 driver
dt-bindings: input: Document STPMIC1 PMIC onkey
input: stpmic1: Add STPMIC1 onkey driver
dt-bindings: watchdog: document STPMIC1 PMIC watchdog
watchdog: stpmic1: Add STPMIC1 watchdog driver
.../devicetree/bindings/input/st,stpmic1-onkey.txt | 28 +++
.../devicetree/bindings/mfd/st,stpmic1.txt | 61 ++++++
.../bindings/watchdog/st,stpmic1-wdt.txt | 11 ++
drivers/input/misc/Kconfig | 11 ++
drivers/input/misc/Makefile | 2 +
drivers/input/misc/stpmic1_onkey.c | 198 +++++++++++++++++++
drivers/mfd/Kconfig | 16 ++
drivers/mfd/Makefile | 1 +
drivers/mfd/stpmic1.c | 213 +++++++++++++++++++++
drivers/watchdog/Kconfig | 12 ++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/stpmic1_wdt.c | 139 ++++++++++++++
include/dt-bindings/mfd/st,stpmic1.h | 50 +++++
include/linux/mfd/stpmic1.h | 212 ++++++++++++++++++++
14 files changed, 955 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/st,stpmic1-onkey.txt
create mode 100644 Documentation/devicetree/bindings/mfd/st,stpmic1.txt
create mode 100644 Documentation/devicetree/bindings/watchdog/st,stpmic1-wdt.txt
create mode 100644 drivers/input/misc/stpmic1_onkey.c
create mode 100644 drivers/mfd/stpmic1.c
create mode 100644 drivers/watchdog/stpmic1_wdt.c
create mode 100644 include/dt-bindings/mfd/st,stpmic1.h
create mode 100644 include/linux/mfd/stpmic1.h
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [GIT PULL] Immutable branch between MFD, IIO and Input due for the v5.1 merge window
From: Lee Jones @ 2019-01-16 12:44 UTC (permalink / raw)
To: Philippe Schenker
Cc: jic23, marcel.ziswiler, stefan, robh, alexandre.torgue, shawnguo,
dmitry.torokhov, thierry.reding, digetx, coquelin.stm32,
Philippe Schenker, Arnd Bergmann, Arnaud Pouliquen, linux-iio,
Mark Brown, Pengutronix Kernel Team, Rob Herring,
Geert Uytterhoeven, William Breathitt Gray, linux-stm32,
Fabio Estevam, Randy Dunlap, Jonathan Cameron,
Freeman Liu <fre>
In-Reply-To: <20181221134638.20600-1-dev@pschenker.ch>
Taken all but the ARM patches.
These need to be reviewed and go in via ARM-SoC.
The following changes since commit bfeffd155283772bbe78c6a05dec7c0128ee500c:
Linux 5.0-rc1 (2019-01-06 17:08:20 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git ib-mfd-iio-input-v5.1
for you to fetch changes up to 81cdab79818988d27d8aeb162b7988c9e6dde936:
iio: adc: add STMPE ADC devicetree bindings (2019-01-16 12:37:36 +0000)
----------------------------------------------------------------
Immutable branch between MFD, IIO and Input due for the v5.1 merge window
----------------------------------------------------------------
Philippe Schenker (3):
dt-bindings: stmpe: Reformatting parameter list and use tabs only
mfd: stmpe: Move ADC related defines to MFD header
Input: stmpe-ts: preparations for STMPE ADC driver
Stefan Agner (3):
mfd: stmpe: Preparations for STMPE ADC driver
iio: adc: add STMPE ADC driver using IIO framework
iio: adc: add STMPE ADC devicetree bindings
.../devicetree/bindings/iio/adc/stmpe-adc.txt | 21 ++
.../bindings/input/touchscreen/stmpe.txt | 116 +++++--
Documentation/devicetree/bindings/mfd/stmpe.txt | 28 +-
drivers/iio/adc/Kconfig | 7 +
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/stmpe-adc.c | 363 +++++++++++++++++++++
drivers/input/touchscreen/stmpe-ts.c | 66 +---
drivers/mfd/Kconfig | 3 +-
drivers/mfd/stmpe.c | 68 ++++
include/linux/mfd/stmpe.h | 21 ++
10 files changed, 610 insertions(+), 84 deletions(-)
create mode 100644 Documentation/devicetree/bindings/iio/adc/stmpe-adc.txt
create mode 100644 drivers/iio/adc/stmpe-adc.c
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH] Input: olpc_apsp - assign priv->dev earlier
From: Lubomir Rintel @ 2019-01-16 9:44 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-kernel, Lubomir Rintel, stable
The dev field needs to be set when serio_register_port() is called,
because the open callback may use it (in the error handling path).
Cc: stable@vger.kernel.org # v4.18+
Fixes: commit af518342effd ("Input: olpc_apsp - check FIFO status on open(), not probe()")
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
---
drivers/input/serio/olpc_apsp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/input/serio/olpc_apsp.c b/drivers/input/serio/olpc_apsp.c
index 0aece9777087..554f4b8228d2 100644
--- a/drivers/input/serio/olpc_apsp.c
+++ b/drivers/input/serio/olpc_apsp.c
@@ -198,6 +198,8 @@ static int olpc_apsp_probe(struct platform_device *pdev)
if (!priv)
return -ENOMEM;
+ priv->dev = &pdev->dev;
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
priv->base = devm_ioremap_resource(&pdev->dev, res);
if (IS_ERR(priv->base)) {
@@ -261,7 +263,6 @@ static int olpc_apsp_probe(struct platform_device *pdev)
goto err_irq;
}
- priv->dev = &pdev->dev;
device_init_wakeup(priv->dev, 1);
platform_set_drvdata(pdev, priv);
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] HID: i2c-hid: Disable runtime PM on Goodix touchpad
From: Kai Heng Feng @ 2019-01-16 8:21 UTC (permalink / raw)
To: Jiri Kosina; +Cc: benjamin.tissoires, linux-input, linux-kernel
In-Reply-To: <nycvar.YFH.7.76.1901141217550.6626@cbobk.fhfr.pm>
> On Jan 14, 2019, at 19:18, Jiri Kosina <jikos@kernel.org> wrote:
>
> On Mon, 14 Jan 2019, Kai-Heng Feng wrote:
>
>> A Goodix touchpad doesn't work. Touching the touchpad can trigger IRQ
>> but there's no input event from HID subsystem.
>>
>> Turns out it reports some invalid data:
>> [ 22.136630] i2c_hid i2c-DELL091F:00: input: 0b 00 01 00 00 00 00 00 00 00 00
>>
>> After some trial and error, it's another device that doesn't work well
>> with ON/SLEEP commands. Disable runtime PM to fix the issue.
>
> Thanks, I've now applied the patch to for-5.0/upstream-fixes. I am
> wondering though we are we seeing these at all - do other OSes not do the
> runtime PM on i2c at all?
According to the vendor, Windows does use ON/SLEEP, but infrequently.
We can use pm_runtime_use_autosuspend() to reduce the frequency of
ON/SLEEP commands, but it’s just papering over the touchpad firmware
bug.
Kai-Heng
>
> --
> Jiri Kosina
> SUSE Labs
>
^ permalink raw reply
* Re: [PATCH v7 0/7] Introduce STPMIC1 PMIC Driver
From: Lee Jones @ 2019-01-16 8:13 UTC (permalink / raw)
To: dmitry.torokhov@gmail.com
Cc: Pascal PAILLET-LME, robh+dt@kernel.org, mark.rutland@arm.com,
lgirdwood@gmail.com, broonie@kernel.org, wim@linux-watchdog.org,
linux@roeck-us.net, linux-input@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-watchdog@vger.kernel.org, benjamin.gaignard@linaro.org,
eballetbo@gmail.com, axel.lin@ingics.com
In-Reply-To: <20190115004856.GL117329@dtor-ws>
On Mon, 14 Jan 2019, dmitry.torokhov@gmail.com wrote:
> On Fri, Dec 14, 2018 at 12:47:01PM +0000, Lee Jones wrote:
> > On Fri, 30 Nov 2018, Pascal PAILLET-LME wrote:
> >
> > > The goal of this patch-set is to propose a driver for the STPMIC1 PMIC from
> > > STMicroelectronics.
> > > The STPMIC1 regulators supply power to an application processor as well as
> > > to external system peripherals such as DDR, Flash memories and system
> > > devices. It also features onkey button input and an hardware watchdog.
> > > The STPMIC1 is controlled via I2C.
> > >
> > > Main driver is drivers/mfd/stpmic1 that handle I2C regmap configuration and
> > > irqchip. stpmic1_regulator, stpmic1_onkey and stpmic1_wdt need stpmic1 mfd
> > > as parent.
> > >
> > > STPMIC1 MFD and regulator drivers maybe mandatory at boot time.
> > >
> > > Pascal Paillet (7):
> > > changes in v7:
> > > * rebase on regul/for-next
> > >
> > > dt-bindings: mfd: document stpmic1
> > > mfd: stpmic1: add stpmic1 driver
> > > dt-bindings: input: document stpmic1 pmic onkey
> > > input: stpmic1: add stpmic1 onkey driver
> > > dt-bindings: watchdog: document stpmic1 pmic watchdog
> > > watchdog: stpmic1: add stpmic1 watchdog driver
> > > regulator: stpmic1: fix regulator_lock usage
> >
> > Could you please remove any patches which have been applied and
> > [RESEND]?
> >
> > Also, is Dmitry planning on Acking:
> >
> > dt-bindings: input: document stpmic1 pmic onkey
> >
> > ... or is Rob's Ack enough?
>
> For bindings I normally defer to Rob (unless I see something that really
> bugs me and then I'll speak up).
I usually do the opposite. Seeing as Rob is pretty heavily laden with
DT patches, I tend to review/apply patches which do not add new DT
properties and/or are obvious/trivial and leave Rob to the rest.
Your train-set though of course, your decision.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH] Input: synaptics - add PNP IDs for Dell XPS models to forcepad
From: Kim Phillips @ 2019-01-16 4:59 UTC (permalink / raw)
To: Benjamin Tissoires, Dmitry Torokhov
Cc: lkml, Paul Menzel, open list:HID CORE LAYER
In-Reply-To: <CAO-hwJKCeV5ZEw7aX58=mnfhWex5QtEVYbRdDX7OosfS5+suUw@mail.gmail.com>
On 1/15/19 2:57 AM, Benjamin Tissoires wrote:
> On Mon, Jan 14, 2019 at 7:40 PM Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
>>
>> On Sat, Jan 12, 2019 at 04:04:36PM -0600, Kim Phillips wrote:
>>> On 1/11/19 7:40 PM, Dmitry Torokhov wrote:
>>>> Hi Kim,
>>>
>>> Hi Dmitry,
>>>
>>>> On Fri, Jan 11, 2019 at 02:54:30PM -0600, Kim Phillips wrote:
>>>>> This patch is the result of seeing this message:
>>>>>
>>>>> psmouse serio1: synaptics: Your touchpad (PNP: DLL087c PNP0f13) says it can support a different bus. If i2c-hid and hid-rmi are not used, you might want to try setting psmouse.synaptics_intertouch to 1 and report this to linux-input@vger.kernel.org.
>>>>>
>>>>> If I set psmouse.synaptics_intertouch=1, or add the PNP ID to
>>>>> smbus_pnp_ids, the touchpad continues to work, and the above message
>>>>> goes away, but we now get:
>>>>>
>>>>> psmouse serio1: synaptics: Trying to set up SMBus access
>>>>> psmouse serio1: synaptics: SMbus companion is not ready yet
>>>>>
>>>>> With this patch applied, i.e., the PNP IDs are added to the forcepad
>>>>> array, the touchpad continues to work and all of the above messages
>>>>> disappear.
>>>>
>>>> Are you sure the touchpad in XPSes is a forcepad (i.e. it does not have
>>>> physical button underneath it)? As far as I know there were only couple
>>>> of HP laptops with forcepads and when switching to RMI mode forcepads
>>>> need F21 handler that we do not currently have in the kernel.
>>>
>>> I see, no, I'm not sure, but assuming you're right, the IDs
>>> should be added to the smbus array instead, after fixing
>>> the SMbus "companion not ready" problem? Pointers for that and
>>> the below interrupts when touchpad idle after resume, welcome.
>>>
>>> Also, the link to get the RMI4 spec in
>>> Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt
>>> is broken. Any pointers for that also appreciated.
>>
>> OK, sorting it all out some more:
>>
>> - because we do not have support for F21 necessary for forcepads adding
>> APIC ID to forcepad list actuallty disables SMbus companion mode, that
>> is why you no longer see "companion not ready" messages vs. setting
>> psmouse.synaptics_intertouch=1 module parameter.
>
> Yep
>
>>
>> - this does not really matter as your touchpad ends up being driven by
>> i2c-hid and hid-multitouch drivers, and that is how we wait it to
>> work, as we do not want to deviate from behavior on Windows since OEM
>> tested it (the device and firmware) in tha configuration.
>
> Yep too. The I2C-hid touchpads from Synaptics do not have the SMBus
> wired at all, so we can't enable SMBus for them. Also, the fact that
> the device gets loaded over i2c-hid means that we can't know that it
> is the case from the psmouse/synaptics point of view.
Sigh, OK, I wasn't registering the word "not" when reading
"If i2c-hid and hid-rmi are not used" too quickly.
>> - we need to figure out issue with interrupts on resume, maybe Benjamin
>> have seen it?
>
> First time I see it.
>
> I just tried on a XPS 9360 and kernel v4.18 (fedora) and nothing was a problem.
> I then tried on a XPS 9575 with v4.19, and here, the wacom I2C node is
> also keeping firing the interrupts, but not the touchpad. However,
> here, the interrupts are not stopping when I touch the touchscreen or
> if I approach a pen.
>
> Kim, rmmod-ing i2c-hid and modprobing back it with the parameter
> debug=1 doesn't show any events processed when the interrupts are
> firing. Do you see the same?
After rmmodding i2c_hid, the WCOM488F and SYNA2393 entries in /proc/interrupts
somewhat expectedly disappear, however, the modprobe (with or without debug=1)
fails to bring them back, with these messages left in dmesg:
[ 3882.073222] calling i2c_hid_driver_init+0x0/0x1000 [i2c_hid] @ 3082
[ 3882.180938] i2c_hid i2c-WCOM488F:00: HID over i2c has not been provided an Int IRQ
[ 3882.181060] i2c_hid: probe of i2c-WCOM488F:00 failed with error -22
[ 3882.181065] probe of i2c-WCOM488F:00 returned 0 after 496 usecs
[ 3882.289196] i2c_hid i2c-SYNA2393:00: HID over i2c has not been provided an Int IRQ
[ 3882.289318] i2c_hid: probe of i2c-SYNA2393:00 failed with error -22
[ 3882.289321] probe of i2c-SYNA2393:00 returned 0 after 508 usecs
[ 3882.289418] initcall i2c_hid_driver_init+0x0/0x1000 [i2c_hid] returned 0 after 211119 usecs
In order to work around that problem, I set h2c_hid.debug=1 in the
boot command line, and after a resume, dmesg contains these messages,
relevant to i2c_hid:
[ 267.235673] i2c_hid i2c-WCOM488F:00: calling i2c_hid_resume+0x0/0x140 [i2c_hid] @ 3078, parent: i2c-9
[ 267.235676] input input16: calling input_dev_resume+0x0/0x50 @ 3060, parent: card0
[ 267.235681] input input16: input_dev_resume+0x0/0x50 returned 0 after 0 usecs
[ 267.235682] i2c_hid i2c-WCOM488F:00: i2c_hid_set_power
[ 267.235687] input input17: calling input_dev_resume+0x0/0x50 @ 3060, parent: card0
[ 267.235689] i2c_hid i2c-WCOM488F:00: __i2c_hid_command: cmd=04 00 00 08
[ 267.235693] input input17: input_dev_resume+0x0/0x50 returned 0 after 0 usecs
[ 267.235698] idma64 idma64.1: calling platform_pm_resume+0x0/0x50 @ 3060, parent: 0000:00:15.1
[ 267.235701] idma64 idma64.1: platform_pm_resume+0x0/0x50 returned 0 after 0 usecs
[ 267.235706] i2c_designware i2c_designware.1: calling platform_pm_resume+0x0/0x50 @ 3060, parent: 0000:00:15.1
[ 267.235709] i2c_designware i2c_designware.1: platform_pm_resume+0x0/0x50 returned 0 after 0 usecs
[ 267.235718] rfkill rfkill0: calling rfkill_resume+0x0/0x60 @ 3060, parent: phy0
[ 267.235724] rfkill rfkill0: rfkill_resume+0x0/0x60 returned 0 after 3 usecs
[ 267.235768] i2c_hid i2c-SYNA2393:00: calling i2c_hid_resume+0x0/0x140 [i2c_hid] @ 3108, parent: i2c-10
[ 267.235774] i2c_hid i2c-SYNA2393:00: i2c_hid_set_power
[ 267.235776] i2c_hid i2c-SYNA2393:00: __i2c_hid_command: cmd=22 00 00 08
[ 267.236051] i2c_hid i2c-SYNA2393:00: i2c_hid_set_or_send_report
[ 267.236053] i2c_hid i2c-SYNA2393:00: __i2c_hid_command: cmd=22 00 3d 03 23 00 04 00 0d 00
[ 267.236076] i2c_hid i2c-WCOM488F:00: i2c_hid_set_or_send_report
[ 267.236080] i2c_hid i2c-WCOM488F:00: __i2c_hid_command: cmd=04 00 3b 03 05 00 42 00 0b 00 fd 89 a3 07 f3 02 20 8d 49 06 d7 9c ff ff 80 59 5c 13 d7 9c ff ff 08 00 00 08 d7 9c ff ff 01 00 00 00 00 00 00 00 16 00 00 00 66 69 6c 65 75 74 6c 2e 6d 65 73 73
[ 267.237691] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
[ 267.238137] i2c_hid i2c-SYNA2393:00: i2c_hid_set_or_send_report
[ 267.238140] i2c_hid i2c-SYNA2393:00: __i2c_hid_command: cmd=22 00 34 03 23 00 04 00 04 03
[ 267.238670] i2c_hid i2c-WCOM488F:00: i2c_hid_get_report
[ 267.238673] i2c_hid i2c-WCOM488F:00: __i2c_hid_command: cmd=04 00 3b 02 05 00
[ 267.239708] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
[ 267.240084] i2c_hid i2c-SYNA2393:00: i2c_hid_set_or_send_report
[ 267.240087] i2c_hid i2c-SYNA2393:00: __i2c_hid_command: cmd=22 00 36 03 23 00 04 00 06 03
[ 267.241377] i2c_hid i2c-WCOM488F:00: i2c_hid_set_or_send_report
[ 267.241380] i2c_hid i2c-WCOM488F:00: __i2c_hid_command: cmd=04 00 3b 03 05 00 42 00 0b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 267.241711] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
[ 267.243279] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
[ 267.243981] i2c_hid i2c-WCOM488F:00: i2c_hid_get_report
[ 267.243984] i2c_hid i2c-WCOM488F:00: __i2c_hid_command: cmd=04 00 3b 02 05 00
[ 267.244847] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
[ 267.245360] i2c_hid i2c-SYNA2393:00: i2c_hid_resume+0x0/0x140 [i2c_hid] returned 0 after 9360 usecs
[ 267.245455] input input27: calling input_dev_resume+0x0/0x50 @ 3060, parent: 0018:06CB:7A13.0002
[ 267.245460] input input27: input_dev_resume+0x0/0x50 returned 0 after 0 usecs
[ 267.246773] i2c_hid i2c-WCOM488F:00: i2c_hid_set_or_send_report
[ 267.246777] i2c_hid i2c-WCOM488F:00: __i2c_hid_command: cmd=04 00 3b 03 05 00 42 00 0b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 267.246919] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
[ 267.248517] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
[ 267.249383] i2c_hid i2c-WCOM488F:00: i2c_hid_get_report
[ 267.249386] i2c_hid i2c-WCOM488F:00: __i2c_hid_command: cmd=04 00 3b 02 05 00
[ 267.250116] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
[ 267.251767] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
[ 267.252137] i2c_hid i2c-WCOM488F:00: i2c_hid_set_or_send_report
[ 267.252140] i2c_hid i2c-WCOM488F:00: __i2c_hid_command: cmd=04 00 3b 03 05 00 42 00 0b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 267.253440] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
[ 267.254734] i2c_hid i2c-WCOM488F:00: i2c_hid_get_report
[ 267.254737] i2c_hid i2c-WCOM488F:00: __i2c_hid_command: cmd=04 00 3b 02 05 00
[ 267.255015] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
[ 267.256612] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
[ 267.257475] i2c_hid i2c-WCOM488F:00: i2c_hid_set_or_send_report
[ 267.257478] i2c_hid i2c-WCOM488F:00: __i2c_hid_command: cmd=04 00 3b 03 05 00 42 00 0b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 267.258275] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
[ 267.259852] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
[ 267.260046] i2c_hid i2c-WCOM488F:00: i2c_hid_get_report
[ 267.260049] i2c_hid i2c-WCOM488F:00: __i2c_hid_command: cmd=04 00 3b 02 05 00
[ 267.261441] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
[ 267.262789] i2c_hid i2c-WCOM488F:00: i2c_hid_set_or_send_report
[ 267.262792] i2c_hid i2c-WCOM488F:00: __i2c_hid_command: cmd=04 00 3b 03 05 00 42 00 0b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 267.263129] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
[ 267.264718] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
[ 267.265410] i2c_hid i2c-WCOM488F:00: i2c_hid_get_report
[ 267.265413] i2c_hid i2c-WCOM488F:00: __i2c_hid_command: cmd=04 00 3b 02 05 00
[ 267.266318] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
[ 267.267971] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
[ 267.268169] i2c_hid i2c-WCOM488F:00: i2c_hid_set_or_send_report
[ 267.268172] i2c_hid i2c-WCOM488F:00: __i2c_hid_command: cmd=04 00 3e 03 05 00 05 00 0e 02 00
[ 267.268728] i2c_hid i2c-WCOM488F:00: i2c_hid_resume+0x0/0x140 [i2c_hid] returned 0 after 32273 usecs
[ 267.269575] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
[ 267.271144] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
[ 267.272719] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
[ 267.274298] i2c_hid i2c-SYNA2393:00: input: 20 00 03 01 3c 03 a8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 60 01 00
...and it goes on and on, where that same last line gets
repeated as the interrupts fire, until I start using the touchpad,
thereby stopping the interrupts.
I'm not seeing any such bad behaviour from the WCOM device.
Kim
^ permalink raw reply
* Re: [PATCH] input_event: Provide override for sparc64
From: Deepa Dinamani @ 2019-01-16 0:10 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Arnd Bergmann, linux-input@vger.kernel.org, lkml,
y2038 Mailman List, David Miller
In-Reply-To: <CAKdAkRQdO14OP7SgE=D4x5RG7=cjDoCAOmtnCcWw_DrToeEmhA@mail.gmail.com>
> On Jan 15, 2019, at 2:32 PM, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
>
>> On Tue, Jan 15, 2019 at 1:29 PM David Miller <davem@davemloft.net> wrote:
>>
>> From: Arnd Bergmann <arnd@arndb.de>
>> Date: Tue, 15 Jan 2019 22:19:27 +0100
>>
>>> The correct check appears to be
>>>
>>> #if defined(__sparc__) && defined(__arch64__)
>>
>> That is correct.
>
> OK. Deepa, could you please send me a fixup as I already pushed out
> the original patch?
Ok, I’m traveling. I will post an update in a couple of days.
Thanks,
Deepa
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox