* [PATCHv3 1/5] sunxi:dts-bindings:input:ps2 bindings for A10/A20 ps2.
From: VishnuPatekar @ 2014-12-12 18:25 UTC (permalink / raw)
To: linux-input, maxime.ripard, dmitry.torokhov, hdegoede
Cc: devicetree, linux-arm-kernel, linux-kernel, robh+dt, pawel.moll,
mark.rutland, ijc+devicetree, galak, linux, grant.likely, benh,
msalter, ralf, jdelvare, VishnuPatekar
In-Reply-To: <1418408748-9797-1-git-send-email-vishnupatekar0510@gmail.com>
1. dt bindings should use the compat string for the earliest version of the
hardware which has the relevant hardware block, unless there are differences,
the A10 and A20 ps2 controllers are identical, so for both sun4i-a10-ps2
should be used as compat string.
2. ps2 / serio bindings belong under Documentation/devicetree/bindings/serio
Signed-off-by: VishnuPatekar <vishnupatekar0510@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
.../bindings/serio/allwinner,sun4i-ps2.txt | 23 ++++++++++++++++++++
1 file changed, 23 insertions(+)
create mode 100644 Documentation/devicetree/bindings/serio/allwinner,sun4i-ps2.txt
diff --git a/Documentation/devicetree/bindings/serio/allwinner,sun4i-ps2.txt b/Documentation/devicetree/bindings/serio/allwinner,sun4i-ps2.txt
new file mode 100644
index 0000000..0c30440
--- /dev/null
+++ b/Documentation/devicetree/bindings/serio/allwinner,sun4i-ps2.txt
@@ -0,0 +1,23 @@
+* Device tree bindings for Allwinner A10, A20 PS2 host controller
+
+A20 PS2 is dual role controller(PS2 host and PS2 device). These bindings are
+for PS2 A10/A20 host controller. IBM compliant IBM PS2 and AT-compatible keyboard
+and mouse can be connected.
+
+Required properties:
+
+ - reg : Offset and length of the register set for the device.
+ - compatible : Should be as of the following:
+ - "allwinner,sun4i-a10-ps2"
+ - interrupts : The interrupt line connected to the PS2.
+ - clocks : The gate clk connected to the PS2.
+
+
+Example:
+ ps20: ps2@0x01c2a000 {
+ compatible = "allwinner,sun4i-a10-ps2";
+ reg = <0x01c2a000 0x400>;
+ interrupts = <0 62 4>;
+ clocks = <&apb1_gates 6>;
+ status = "disabled";
+ };
--
1.7.9.5
^ permalink raw reply related
* [PATCHv3 3/5] ARM: sunxi: dts: Add PS2 nodes to dtsi for A10 and A20
From: VishnuPatekar @ 2014-12-12 18:25 UTC (permalink / raw)
To: linux-input, maxime.ripard, dmitry.torokhov, hdegoede
Cc: devicetree, linux-arm-kernel, linux-kernel, robh+dt, pawel.moll,
mark.rutland, ijc+devicetree, galak, linux, grant.likely, benh,
msalter, ralf, jdelvare, VishnuPatekar
In-Reply-To: <1418408748-9797-1-git-send-email-vishnupatekar0510@gmail.com>
1) Fixup the sun4i ps/2 nodes interrupt property, sun4i interrupts take
only 1 specifier
2) dt bindings should use the compat string for the earliest version of the
hardware which has the relevant hardware block, unless there are differences,
the A10 and A20 ps2 controllers are identical, so for both sun4i-a10-ps2
should be used as compat string, update the sun7i.dtsi ps2 entries to
use the sun4i-a10-ps2 compat string.
Signed-off-by: VishnuPatekar <vishnupatekar0510@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
arch/arm/boot/dts/sun4i-a10.dtsi | 17 +++++++++++++++++
arch/arm/boot/dts/sun7i-a20.dtsi | 18 ++++++++++++++++++
2 files changed, 35 insertions(+)
diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
index 7b4099f..ef9a01c 100644
--- a/arch/arm/boot/dts/sun4i-a10.dtsi
+++ b/arch/arm/boot/dts/sun4i-a10.dtsi
@@ -629,6 +629,7 @@
allwinner,drive = <0>;
allwinner,pull = <0>;
};
+
};
timer@01c20c00 {
@@ -795,5 +796,21 @@
#address-cells = <1>;
#size-cells = <0>;
};
+
+ ps20: ps2@01c2a000 {
+ compatible = "allwinner,sun4i-a10-ps2";
+ reg = <0x01c2a000 0x400>;
+ interrupts = <62>;
+ clocks = <&apb1_gates 6>;
+ status = "disabled";
+ };
+
+ ps21: ps2@01c2a400 {
+ compatible = "allwinner,sun4i-a10-ps2";
+ reg = <0x01c2a400 0x400>;
+ interrupts = <63>;
+ clocks = <&apb1_gates 7>;
+ status = "disabled";
+ };
};
};
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index e21ce59..6ab7714 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -866,6 +866,7 @@
allwinner,drive = <0>;
allwinner,pull = <0>;
};
+
};
timer@01c20c00 {
@@ -1093,5 +1094,22 @@
#interrupt-cells = <3>;
interrupts = <1 9 0xf04>;
};
+
+ ps20: ps2@01c2a000 {
+ compatible = "allwinner,sun4i-a10-ps2";
+ reg = <0x01c2a000 0x400>;
+ interrupts = <0 62 4>;
+ clocks = <&apb1_gates 6>;
+ status = "disabled";
+ };
+
+ ps21: ps2@01c2a400 {
+ compatible = "allwinner,sun4i-a10-ps2";
+ reg = <0x01c2a400 0x400>;
+ interrupts = <0 63 4>;
+ clocks = <&apb1_gates 7>;
+ status = "disabled";
+ };
+
};
};
--
1.7.9.5
^ permalink raw reply related
* [PATCHv3 4/5] ARM: sunxi: dts: Add A10/A20 PS2 pin muxing options
From: VishnuPatekar @ 2014-12-12 18:25 UTC (permalink / raw)
To: linux-input, maxime.ripard, dmitry.torokhov, hdegoede
Cc: devicetree, linux-arm-kernel, linux-kernel, robh+dt, pawel.moll,
mark.rutland, ijc+devicetree, galak, linux, grant.likely, benh,
msalter, ralf, jdelvare, VishnuPatekar
In-Reply-To: <1418408748-9797-1-git-send-email-vishnupatekar0510@gmail.com>
Added the pinmuxing options for Allwinner A10 and A20.
Signed-off-by: VishnuPatekar <vishnupatekar0510@gmail.com>
---
arch/arm/boot/dts/sun4i-a10.dtsi | 14 ++++++++++++++
arch/arm/boot/dts/sun7i-a20.dtsi | 14 ++++++++++++++
2 files changed, 28 insertions(+)
diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
index ef9a01c..5a29039 100644
--- a/arch/arm/boot/dts/sun4i-a10.dtsi
+++ b/arch/arm/boot/dts/sun4i-a10.dtsi
@@ -630,6 +630,20 @@
allwinner,pull = <0>;
};
+ ps20_pins_a: ps20@0 {
+ allwinner,pins = "PI20", "PI21";
+ allwinner,function = "ps2";
+ allwinner,drive = <0>;
+ allwinner,pull = <0>;
+ };
+
+ ps21_pins_a: ps21@0 {
+ allwinner,pins = "PH12", "PH13";
+ allwinner,function = "ps2";
+ allwinner,drive = <0>;
+ allwinner,pull = <0>;
+ };
+
};
timer@01c20c00 {
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 6ab7714..247def0 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -867,6 +867,20 @@
allwinner,pull = <0>;
};
+ ps20_pins_a: ps20@0 {
+ allwinner,pins = "PI20", "PI21";
+ allwinner,function = "ps2";
+ allwinner,drive = <0>;
+ allwinner,pull = <0>;
+ };
+
+ ps21_pins_a: ps21@0 {
+ allwinner,pins = "PH12", "PH13";
+ allwinner,function = "ps2";
+ allwinner,drive = <0>;
+ allwinner,pull = <0>;
+ };
+
};
timer@01c20c00 {
--
1.7.9.5
^ permalink raw reply related
* [PATCHv3 5/5] ARM: sunxi: dts: Add note ps2 pins conflict with hdmi
From: VishnuPatekar @ 2014-12-12 18:25 UTC (permalink / raw)
To: linux-input, maxime.ripard, dmitry.torokhov, hdegoede
Cc: devicetree, linux-arm-kernel, linux-kernel, robh+dt, pawel.moll,
mark.rutland, ijc+devicetree, galak, linux, grant.likely, benh,
msalter, ralf, jdelvare, VishnuPatekar
In-Reply-To: <1418408748-9797-1-git-send-email-vishnupatekar0510@gmail.com>
1. Please note that ps20 pins conflict with HDMI on Lime2 Board
so, by deault ps20 and ps21 are disabled for Lime2 Board.
There is no on board ps2 connector and these pins can be used
for different purpose.
Signed-off-by: VishnuPatekar <vishnupatekar0510@gmail.com>
---
arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
index ed364d5..951b615 100644
--- a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
@@ -112,7 +112,11 @@
pinctrl-0 = <&uart0_pins_a>;
status = "okay";
};
-
+
+ /* PS2 0 and PS2 1 are disabled by default; Please note that
+ ps20 pins conflict with HDMI on Lime2 Board
+ */
+
i2c0: i2c@01c2ac00 {
pinctrl-names = "default";
pinctrl-0 = <&i2c0_pins_a>;
--
1.7.9.5
^ permalink raw reply related
* [PATCHv3 0/5] ARM:sunxi:ps2 Added support for A10/A20 ps2 controller.
From: VishnuPatekar @ 2014-12-12 18:25 UTC (permalink / raw)
To: linux-input, maxime.ripard, dmitry.torokhov, hdegoede
Cc: devicetree, linux-arm-kernel, linux-kernel, robh+dt, pawel.moll,
mark.rutland, ijc+devicetree, galak, linux, grant.likely, benh,
msalter, ralf, jdelvare, VishnuPatekar
v2 --> v3
1. changed config to SERIO_SUN4I_PS2 from SERIO_SUNXI_PS2
2. changed driver name to sun4i-ps2 from sunxi-ps2.
3. changed the function names to sun4i_ps2_*.
4. added locking in sun4i_ps2_open.
5. kept compatible "sun4i-a10-ps2" for A10 and A20, as A10 is earlier SOC.
6. corrected the style errors.
7. separated the dts patches.
8. removed commented ps2 notes from lime2 dts.
9. added note that ps2 pins confilt with hdmi.
10. corrected the interrupt property for A10.
11. moved dt-bindings to Documentation/devicetree/bindings/serio
v1 --> v2:
1. added default n depends on ARCH_SUNXI || COMPILE_TEST in Kconfig.
2. handled errors and free resources on errors.
3. used BIT(x), DIV_ROUND_UP macros.
4. corrected style errors.
5. added support for A10 also, A10 and A2 have same properties of PS2 controller.
6. by default commented ps20 and ps21 nodes,as ps20 pins conflict with HDMI.
7. added compatible as allwinner,sun4i-a10-ps2.
8. corrected the possible race condition.
VishnuPatekar (5):
sunxi:dts-bindings:input:ps2 bindings for A10/A20 ps2.
ARM:sunxi:drivers:input Add support for A10/A20 PS2
ARM: sunxi: dts: Add PS2 nodes to dtsi for A10 and A20
ARM: sunxi: dts: Add A10/A20 PS2 pin muxing options
ARM: sunxi: dts: Add note ps2 pins conflict with hdmi
.../bindings/serio/allwinner,sun4i-ps2.txt | 23 ++
arch/arm/boot/dts/sun4i-a10.dtsi | 31 ++
arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts | 6 +-
arch/arm/boot/dts/sun7i-a20.dtsi | 32 ++
drivers/input/serio/Kconfig | 11 +
drivers/input/serio/Makefile | 1 +
drivers/input/serio/sun4i-ps2.c | 362 ++++++++++++++++++++
7 files changed, 465 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/serio/allwinner,sun4i-ps2.txt
create mode 100644 drivers/input/serio/sun4i-ps2.c
--
1.7.9.5
^ permalink raw reply
* [PATCHv3 2/5] ARM:sunxi:drivers:input Add support for A10/A20 PS2
From: VishnuPatekar @ 2014-12-12 18:25 UTC (permalink / raw)
To: linux-input, maxime.ripard, dmitry.torokhov, hdegoede
Cc: devicetree, linux-arm-kernel, linux-kernel, robh+dt, pawel.moll,
mark.rutland, ijc+devicetree, galak, linux, grant.likely, benh,
msalter, ralf, jdelvare, VishnuPatekar
In-Reply-To: <1418408748-9797-1-git-send-email-vishnupatekar0510@gmail.com>
Signed-off-by: VishnuPatekar <vishnupatekar0510@gmail.com>
---
drivers/input/serio/Kconfig | 11 ++
drivers/input/serio/Makefile | 1 +
drivers/input/serio/sun4i-ps2.c | 362 +++++++++++++++++++++++++++++++++++++++
3 files changed, 374 insertions(+)
create mode 100644 drivers/input/serio/sun4i-ps2.c
diff --git a/drivers/input/serio/Kconfig b/drivers/input/serio/Kconfig
index bc2d474..964afc5 100644
--- a/drivers/input/serio/Kconfig
+++ b/drivers/input/serio/Kconfig
@@ -281,4 +281,15 @@ config HYPERV_KEYBOARD
To compile this driver as a module, choose M here: the module will
be called hyperv_keyboard.
+config SERIO_SUN4I_PS2
+ tristate "Allwinner A10 PS/2 controller support"
+ default n
+ depends on ARCH_SUNXI || COMPILE_TEST
+ help
+ This selects support for the PS/2 Host Controller on
+ Allwinner A10.
+
+ To compile this driver as a module, choose M here: the
+ module will be called sun4i-ps2.
+
endif
diff --git a/drivers/input/serio/Makefile b/drivers/input/serio/Makefile
index 815d874..c600089 100644
--- a/drivers/input/serio/Makefile
+++ b/drivers/input/serio/Makefile
@@ -29,3 +29,4 @@ obj-$(CONFIG_SERIO_ARC_PS2) += arc_ps2.o
obj-$(CONFIG_SERIO_APBPS2) += apbps2.o
obj-$(CONFIG_SERIO_OLPC_APSP) += olpc_apsp.o
obj-$(CONFIG_HYPERV_KEYBOARD) += hyperv-keyboard.o
+obj-$(CONFIG_SERIO_SUN4I_PS2) += sun4i-ps2.o
diff --git a/drivers/input/serio/sun4i-ps2.c b/drivers/input/serio/sun4i-ps2.c
new file mode 100644
index 0000000..e6d22ae
--- /dev/null
+++ b/drivers/input/serio/sun4i-ps2.c
@@ -0,0 +1,362 @@
+/*
+ * Driver for Allwinner A10 PS2 host controller
+ *
+ * Author: Vishnu Patekar <vishnupatekar0510@gmail.com>
+ * Aaron.maoye <leafy.myeh@newbietech.com>
+ *
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/serio.h>
+#include <linux/interrupt.h>
+#include <linux/errno.h>
+#include <linux/slab.h>
+#include <linux/list.h>
+#include <linux/io.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/of_irq.h>
+#include <linux/of_platform.h>
+#include <linux/clk.h>
+#include <linux/delay.h>
+
+#define DRIVER_NAME "sun4i-ps2"
+
+/* register offset definitions */
+#define PS2_REG_GCTL (0x00) /* PS2 Module Global Control Reg */
+#define PS2_REG_DATA (0x04) /* PS2 Module Data Reg */
+#define PS2_REG_LCTL (0x08) /* PS2 Module Line Control Reg */
+#define PS2_REG_LSTS (0x0C) /* PS2 Module Line Status Reg */
+#define PS2_REG_FCTL (0x10) /* PS2 Module FIFO Control Reg */
+#define PS2_REG_FSTS (0x14) /* PS2 Module FIFO Status Reg */
+#define PS2_REG_CLKDR (0x18) /* PS2 Module Clock Divider Reg*/
+
+/* PS2 GLOBAL CONTROL REGISTER PS2_GCTL */
+#define PS2_GCTL_INTFLAG BIT(4)
+#define PS2_GCTL_INTEN BIT(3)
+#define PS2_GCTL_RESET BIT(2)
+#define PS2_GCTL_MASTER BIT(1)
+#define PS2_GCTL_BUSEN BIT(0)
+
+/* PS2 LINE CONTROL REGISTER */
+#define PS2_LCTL_NOACK BIT(18)
+#define PS2_LCTL_TXDTOEN BIT(8)
+#define PS2_LCTL_STOPERREN BIT(3)
+#define PS2_LCTL_ACKERREN BIT(2)
+#define PS2_LCTL_PARERREN BIT(1)
+#define PS2_LCTL_RXDTOEN BIT(0)
+
+/* PS2 LINE STATUS REGISTER */
+#define PS2_LSTS_TXTDO BIT(8)
+#define PS2_LSTS_STOPERR BIT(3)
+#define PS2_LSTS_ACKERR BIT(2)
+#define PS2_LSTS_PARERR BIT(1)
+#define PS2_LSTS_RXTDO BIT(0)
+
+#define PS2_LINE_ERROR_BIT \
+ (PS2_LSTS_TXTDO | PS2_LSTS_STOPERR | PS2_LSTS_ACKERR | \
+ PS2_LSTS_PARERR | PS2_LSTS_RXTDO)
+
+/* PS2 FIFO CONTROL REGISTER */
+#define PS2_FCTL_TXRST BIT(17)
+#define PS2_FCTL_RXRST BIT(16)
+#define PS2_FCTL_TXUFIEN BIT(10)
+#define PS2_FCTL_TXOFIEN BIT(9)
+#define PS2_FCTL_TXRDYIEN BIT(8)
+#define PS2_FCTL_RXUFIEN BIT(2)
+#define PS2_FCTL_RXOFIEN BIT(1)
+#define PS2_FCTL_RXRDYIEN BIT(0)
+
+/* PS2 FIFO STATUS REGISTER */
+#define PS2_FSTS_TXUF BIT(10)
+#define PS2_FSTS_TXOF BIT(9)
+#define PS2_FSTS_TXRDY BIT(8)
+#define PS2_FSTS_RXUF BIT(2)
+#define PS2_FSTS_RXOF BIT(1)
+#define PS2_FSTS_RXRDY BIT(0)
+
+#define PS2_FIFO_ERROR_BIT \
+ (PS2_FSTS_TXUF | PS2_FSTS_TXOF | PS2_FSTS_RXUF | PS2_FSTS_RXOF)
+
+#define PS2_SAMPLE_CLK (1000000)
+#define PS2_SCLK (125000)
+
+struct sun4i_ps2data {
+ struct serio *serio;
+ struct device *dev;
+
+ /* IO mapping base */
+ void __iomem *reg_base;
+
+ /* clock management */
+ struct clk *clk;
+
+ /* irq */
+ spinlock_t lock;
+ int irq;
+};
+
+/*********************/
+/* Interrupt handler */
+/*********************/
+static irqreturn_t sun4i_ps2_interrupt(int irq, void *dev_id)
+{
+ struct sun4i_ps2data *drvdata = dev_id;
+ u32 intr_status;
+ u32 fifo_status;
+ unsigned char byte;
+ u32 rval;
+ u32 error = 0;
+
+ spin_lock(&drvdata->lock);
+
+ /* Get the PS/2 interrupts and clear them */
+ intr_status = readl(drvdata->reg_base + PS2_REG_LSTS);
+ fifo_status = readl(drvdata->reg_base + PS2_REG_FSTS);
+
+ /*Check Line Status Register*/
+ if (intr_status & PS2_LINE_ERROR_BIT) {
+ if (intr_status & PS2_LSTS_STOPERR)
+ dev_info(drvdata->dev, "PS/2 Stop Bit Error!");
+ if (intr_status & PS2_LSTS_ACKERR)
+ dev_info(drvdata->dev, "PS/2 Acknowledge Error!\n");
+ if (intr_status & PS2_LSTS_PARERR)
+ dev_info(drvdata->dev, "PS/2 Parity Error!\n");
+ if (intr_status & PS2_LSTS_TXTDO)
+ dev_info(drvdata->dev, "PS/2 Transmit Data Timeout!\n");
+ if (intr_status & PS2_LSTS_RXTDO)
+ dev_info(drvdata->dev, "PS/2 Receive Data Timeout!\n");
+
+ /*reset PS/2 controller*/
+ rval = readl(drvdata->reg_base + PS2_REG_GCTL);
+ writel(rval | PS2_GCTL_RESET, drvdata->reg_base + PS2_REG_GCTL);
+
+ rval = PS2_LSTS_TXTDO | PS2_LSTS_STOPERR | PS2_LSTS_ACKERR |
+ PS2_LSTS_PARERR | PS2_LSTS_RXTDO;
+ writel(rval, drvdata->reg_base + PS2_REG_LSTS);
+ error = 1;
+ }
+
+ /*Check FIFO Status Register*/
+ if (fifo_status & PS2_FIFO_ERROR_BIT) {
+ if (fifo_status & PS2_FSTS_TXUF)
+ dev_info(drvdata->dev, "PS/2 Tx FIFO Underflow!\n");
+ if (fifo_status & PS2_FSTS_TXOF)
+ dev_info(drvdata->dev, "PS/2 Tx FIFO Overflow!\n");
+ if (fifo_status & PS2_FSTS_RXUF)
+ dev_info(drvdata->dev, "PS/2 Rx FIFO Underflow!\n");
+ if (fifo_status & PS2_FSTS_RXOF)
+ dev_info(drvdata->dev, "PS/2 Rx FIFO Overflow!\n");
+ /*reset PS/2 controller*/
+ writel(readl(drvdata->reg_base + PS2_REG_GCTL) | PS2_GCTL_RESET,
+ drvdata->reg_base + PS2_REG_GCTL);
+
+ rval = PS2_FSTS_TXUF | PS2_FSTS_TXOF | PS2_FSTS_TXRDY |
+ PS2_FSTS_RXUF | PS2_FSTS_RXOF | PS2_FSTS_RXRDY;
+ writel(rval, drvdata->reg_base + PS2_REG_FSTS);
+ error = 1;
+ }
+
+ rval = (fifo_status >> 16) & 0x3;
+ while (!error && rval--) {
+ byte = readl(drvdata->reg_base + PS2_REG_DATA) & 0xff;
+ serio_interrupt(drvdata->serio, byte, 0);
+ }
+
+ writel(intr_status, drvdata->reg_base + PS2_REG_LSTS);
+ writel(fifo_status, drvdata->reg_base + PS2_REG_FSTS);
+
+ spin_unlock(&drvdata->lock);
+
+ return IRQ_HANDLED;
+}
+
+
+static int sun4i_ps2_open(struct serio *pserio)
+{
+ struct sun4i_ps2data *drvdata = pserio->port_data;
+ u32 src_clk = 0;
+ u32 clk_scdf;
+ u32 clk_pcdf;
+ u32 rval;
+ unsigned long flags;
+
+ /*Set Line Control And Enable Interrupt*/
+ rval = PS2_LCTL_TXDTOEN | PS2_LCTL_STOPERREN | PS2_LCTL_ACKERREN
+ | PS2_LCTL_PARERREN | PS2_LCTL_RXDTOEN;
+ writel(rval, drvdata->reg_base + PS2_REG_LCTL);
+
+ /*Reset FIFO*/
+ rval = PS2_FCTL_TXRST | PS2_FCTL_RXRST | PS2_FCTL_TXUFIEN
+ | PS2_FCTL_TXOFIEN | PS2_FCTL_RXUFIEN
+ | PS2_FCTL_RXOFIEN | PS2_FCTL_RXRDYIEN;
+
+ writel(rval, drvdata->reg_base + PS2_REG_FCTL);
+
+ src_clk = clk_get_rate(drvdata->clk);
+ /*Set Clock Divider Register*/
+ clk_scdf = DIV_ROUND_UP(src_clk, PS2_SAMPLE_CLK) - 1;
+ clk_pcdf = DIV_ROUND_UP(PS2_SAMPLE_CLK, PS2_SCLK) - 1;
+ rval = (clk_scdf<<8) | clk_pcdf;
+ writel(rval, drvdata->reg_base + PS2_REG_CLKDR);
+
+
+ /*Set Global Control Register*/
+ rval = PS2_GCTL_RESET | PS2_GCTL_INTEN | PS2_GCTL_MASTER
+ | PS2_GCTL_BUSEN;
+
+ spin_lock_irqsave(&drvdata->lock, flags);
+ writel(rval, drvdata->reg_base + PS2_REG_GCTL);
+ spin_unlock_irqrestore(&drvdata->lock, flags);
+
+ return 0;
+}
+
+static void sun4i_ps2_close(struct serio *pserio)
+{
+ struct sun4i_ps2data *drvdata = pserio->port_data;
+ unsigned long flags;
+
+ spin_lock_irqsave(&drvdata->lock, flags);
+ /* Disable the PS2 interrupts */
+ writel(0, drvdata->reg_base + PS2_REG_GCTL);
+ spin_unlock_irqrestore(&drvdata->lock, flags);
+}
+
+static int sun4i_ps2_write(struct serio *pserio, unsigned char val)
+{
+ unsigned long expire = jiffies + msecs_to_jiffies(10000);
+ struct sun4i_ps2data *drvdata;
+
+ drvdata = (struct sun4i_ps2data *)pserio->port_data;
+
+ do {
+ if (readl(drvdata->reg_base + PS2_REG_FSTS) & PS2_FSTS_TXRDY) {
+ writel(val, drvdata->reg_base + PS2_REG_DATA);
+ return 0;
+ }
+ } while (time_before(jiffies, expire));
+
+ return 0;
+}
+
+static int sun4i_ps2_probe(struct platform_device *pdev)
+{
+ struct resource *res; /* IO mem resources */
+ struct sun4i_ps2data *drvdata;
+ struct serio *serio;
+ struct device *dev = &pdev->dev;
+ unsigned int irq;
+ int error;
+
+ drvdata = devm_kzalloc(dev, sizeof(struct sun4i_ps2data), GFP_KERNEL);
+ serio = kzalloc(sizeof(struct serio), GFP_KERNEL);
+ if (!drvdata || !serio) {
+ error = -ENOMEM;
+ goto err_free_mem;
+ }
+
+ spin_lock_init(&drvdata->lock);
+
+ /* IO */
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ drvdata->reg_base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(drvdata->reg_base)) {
+ dev_err(dev, "failed to map registers\n");
+ error = PTR_ERR(drvdata->reg_base);
+ goto err_free_mem;
+ }
+
+ drvdata->clk = devm_clk_get(dev, NULL);
+ if (IS_ERR(drvdata->clk)) {
+ error = PTR_ERR(drvdata->clk);
+ dev_err(dev, "couldn't get clock %d\n", error);
+ goto err_free_mem;
+ }
+
+ error = clk_prepare_enable(drvdata->clk);
+ if (error) {
+ dev_err(dev, "failed to enable clock %d\n", error);
+ goto err_free_mem;
+ }
+
+ serio->id.type = SERIO_8042;
+ serio->write = sun4i_ps2_write;
+ serio->open = sun4i_ps2_open;
+ serio->close = sun4i_ps2_close;
+ serio->port_data = drvdata;
+ serio->dev.parent = dev;
+ strlcpy(serio->name, dev_name(dev), sizeof(serio->name));
+ strlcpy(serio->phys, dev_name(dev), sizeof(serio->phys));
+
+ /* Get IRQ for the device */
+ irq = platform_get_irq(pdev, 0);
+ if (!irq) {
+ dev_err(dev, "no IRQ found\n");
+ error = -ENXIO;
+ goto error_disable_clk;
+ }
+
+ drvdata->irq = irq;
+ drvdata->serio = serio;
+ drvdata->dev = dev;
+ error = devm_request_threaded_irq(dev, drvdata->irq,
+ sun4i_ps2_interrupt, NULL, 0, DRIVER_NAME, drvdata);
+
+ if (error) {
+ dev_err(drvdata->dev, "Interrupt alloc failed %d:error:%d\n",
+ drvdata->irq, error);
+ goto error_disable_clk;
+ }
+
+ serio_register_port(serio);
+ platform_set_drvdata(pdev, drvdata);
+
+ return 0; /* success */
+
+error_disable_clk:
+ clk_disable_unprepare(drvdata->clk);
+
+err_free_mem:
+ kfree(serio);
+ return error;
+}
+
+static int sun4i_ps2_remove(struct platform_device *pdev)
+{
+ struct sun4i_ps2data *drvdata = platform_get_drvdata(pdev);
+
+ serio_unregister_port(drvdata->serio);
+ disable_irq(drvdata->irq);
+
+ if (!IS_ERR(drvdata->clk))
+ clk_disable_unprepare(drvdata->clk);
+ kfree(drvdata->serio);
+
+ return 0;
+}
+
+/* Match table for of_platform binding */
+static const struct of_device_id sun4i_ps2_match[] = {
+ { .compatible = "allwinner,sun4i-a10-ps2", },
+ { },
+};
+
+MODULE_DEVICE_TABLE(of, sun4i_ps2_match);
+
+/*platform driver structure*/
+static struct platform_driver sun4i_ps2_driver = {
+ .probe = sun4i_ps2_probe,
+ .remove = sun4i_ps2_remove,
+ .driver = {
+ .name = DRIVER_NAME,
+ .of_match_table = sun4i_ps2_match,
+ },
+};
+module_platform_driver(sun4i_ps2_driver);
+
+MODULE_AUTHOR("Vishnu Patekar <vishnupatekar0510@gmail.com>");
+MODULE_AUTHOR("Aaron.maoye <leafy.myeh@newbietech.com>");
+MODULE_DESCRIPTION("Allwinner A10/Sun4i PS/2 driver");
+MODULE_LICENSE("GPL v2");
--
1.7.9.5
^ permalink raw reply related
* Re: NULL pointer dereference in i2c-hid
From: Andrew Duggan @ 2014-12-12 19:12 UTC (permalink / raw)
To: Gabriele Mazzotta
Cc: Mika Westerberg, linux-input, linux-kernel, benjamin.tissoires,
jkosina
In-Reply-To: <2094646.ov2KaAkedO@xps13>
On 12/12/2014 12:12 AM, Gabriele Mazzotta wrote:
> On Thursday 11 December 2014 16:26:00 Andrew Duggan wrote:
>> On 12/11/2014 01:57 PM, Gabriele Mazzotta wrote:
>>> On Thursday 11 December 2014 13:34:02 Andrew Duggan wrote:
>>>> On 12/11/2014 01:17 PM, Gabriele Mazzotta wrote:
>>>>> On Thursday 11 December 2014 12:46:53 Andrew Duggan wrote:
>>>>>> On 12/11/2014 11:40 AM, Gabriele Mazzotta wrote:
>>>>>>> On Thursday 11 December 2014 11:21:43 Andrew Duggan wrote:
>>>>>>>> On 12/11/2014 11:11 AM, Gabriele Mazzotta wrote:
>>>>>>>>> On Thursday 11 December 2014 10:40:05 Andrew Duggan wrote:
>>>>>>>>>> On 12/11/2014 10:16 AM, Gabriele Mazzotta wrote:
>>>>>>>>>>> On Thursday 11 December 2014 16:03:07 Mika Westerberg wrote:
>>>>>>>>>>>> On Thu, Dec 11, 2014 at 10:58:01AM +0200, Mika Westerberg wrote:
>>>>>>>>>>>>> On Wed, Dec 10, 2014 at 06:04:51PM +0100, Gabriele Mazzotta wrote:
>>>>>>>>>>>>>> my laptop uses a touchpad that needs hid-rmi along with i2c-hid to work.
>>>>>>>>>>>>>> i2c-hid and hid-rmi can be loaded and unloaded independelty from each
>>>>>>>>>>>>>> other, however since 34f439e4afcd ("HID: i2c-hid: add runtime PM support")
>>>>>>>>>>>>>> if I unload hid-rmi and after it I also unload i2c-hid, I get a NULL
>>>>>>>>>>>>>> pointer dereference.
>>>>>>>>>>>>> I'll look into this.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I can reproduce this easily with i2c-hid + hid-multitouch following your
>>>>>>>>>>>>> directions.
>>>>>>>>>>>> Can you try the below patch?
>>>>>>>>>>>>
>>>>>>>>>>>> I think we shouldn't free buffers yet in ->stop() because we need the
>>>>>>>>>>>> command buffer sending power commands to the device. Also it seems that
>>>>>>>>>>>> ->start() re-allocates buffers anyway if maximum size increases.
>>>>>>>>>>>>
>>>>>>>>>>>> It shouldn't even leak memory as we release buffers at ->remove()
>>>>>>>>>>>> anyway.
>>>>>>>>>>>>
>>>>>>>>>>>> diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
>>>>>>>>>>>> index 62cec01937ea..68a8c938feea 100644
>>>>>>>>>>>> --- a/drivers/hid/i2c-hid/i2c-hid.c
>>>>>>>>>>>> +++ b/drivers/hid/i2c-hid/i2c-hid.c
>>>>>>>>>>>> @@ -705,12 +705,7 @@ static int i2c_hid_start(struct hid_device *hid)
>>>>>>>>>>>>
>>>>>>>>>>>> static void i2c_hid_stop(struct hid_device *hid)
>>>>>>>>>>>> {
>>>>>>>>>>>> - struct i2c_client *client = hid->driver_data;
>>>>>>>>>>>> - struct i2c_hid *ihid = i2c_get_clientdata(client);
>>>>>>>>>>>> -
>>>>>>>>>>>> hid->claimed = 0;
>>>>>>>>>>>> -
>>>>>>>>>>>> - i2c_hid_free_buffers(ihid);
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> static int i2c_hid_open(struct hid_device *hid)
>>>>>>>>>>> Yes, it works, thanks.
>>>>>>>>>>>
>>>>>>>>>>> This change seems to also prevent kernel ooops when I unload either
>>>>>>>>>>> i2c-hid or i2c-designware-platform while the touchpad is in use,
>>>>>>>>>>> thing that is likely to happen because of the other bug I reported.
>>>>>>>>>>>
>>>>>>>>>>> Speaking of it, does any of you have any suggestion on how to debug it?
>>>>>>>>>> I was able to reproduce the initial issue by unloading hid-rmi and
>>>>>>>>>> i2c-hid while holding my fingers on the touchpad. Mika's patch fixes it
>>>>>>>>>> for me.
>>>>>>>>>>
>>>>>>>>>> For the original bug, you can modprobe i2c-hid debug=1 and we can see
>>>>>>>>>> what data the touchpad is reporting. That might help narrowing down if
>>>>>>>>>> it's noise which the touchpad thinks are fingers or if there is a
>>>>>>>>>> problem with the I2C lines causing spurious interrupts.
>>>>>>>>>>
>>>>>>>>>> Andrew
>>>>>>>>> I've already tried to do that and here what I got:
>>>>>>>>>
>>>>>>>>> When I release the finger, the last message is repeated 81 times.
>>>>>>>>> If the byte containing informations about the width of the finger
>>>>>>>>> becomes equal to either c0 or 0c at least once, the last message is
>>>>>>>>> repeated indefinitely and changes as soon as I start using the touchpad.
>>>>>>>>> The only way to stop it is to unload and reload i2c-hid.
>>>>>>>> The reports before log throttling kicks in would still be useful. For
>>>>>>>> instance c0 is outside of the range of finger width which we report so
>>>>>>>> something is wrong there. But, the touchpad should stop interrupting
>>>>>>>> once the finger is lifted. The fact that subsequent reads are reporting
>>>>>>>> the same data does sound like a problem with I2C getting confused and
>>>>>>>> continuously interrupting and reading the old finger data. I am also
>>>>>>>> curious about the value of the byte after the report id.
>>>>>>>>
>>>>>>>> Andrew
>>>>>>> If I'm not wrong c0 means that the width is 12 on y axis, while 0c means
>>>>>>> that the width is 12 on the x axis.
>>>>>> You are correct! I forgot width was 4 bits for X and Y in the same byte.
>>>>>> That makes more sense.
>>>>>>
>>>>>>> I have to correct myself. The important thing is that the byte is either
>>>>>>> cx or xc, where x is anything below c.
>>>>>>>
>>>>>>> Another correction. Sometimes unloading i2c-hid is not enough, I have to
>>>>>>> first disable the touchpad with xinput and then unload i2c-hid. If I
>>>>>>> don't do it, the messages starts reappearing as soon as I reload i2c-hid.
>>>>>>>
>>>>>>> I did several tests in the past months and I'm quite sure that the bug
>>>>>>> happens only past xc/cy.
>>>>>> This maybe coincidental. It is not obvious to me why a certain width
>>>>>> value would cause the symptoms described.
>>>>> Yes, I don't deny it. This is just a constant I found in my tests.
>>>>>
>>>>>>> Here few lines right before the bug. The last line is repeated indefinitely:
>>>>>>>
>>>>>>> [ 1983.527097] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 67 5b 61 0a 5f 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1983.537211] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 67 5b 63 0a 60 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1983.547329] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 67 5b 64 0a 60 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1983.557486] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 67 5b 66 0a 60 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1983.567663] i2c_hid i2c-DLL060A:00: input: 20 00 0c 0c 01 00 67 5b 68 0a 60 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1983.577719] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 67 5b 6a 0a 61 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1983.587852] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 67 5b 6b 0a 61 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1983.598001] i2c_hid i2c-DLL060A:00: input: 20 00 0c 0c 01 00 67 5b 6e 0a 62 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1983.608215] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 68 5b 61 0a 62 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1983.618288] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 68 5b 64 0b 63 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1983.628493] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 68 5b 67 0b 63 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1983.638552] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 68 5b 69 0b 64 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1983.648663] i2c_hid i2c-DLL060A:00: input: 20 00 0c 0c 01 00 68 5b 6c 0b 64 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1983.658789] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 68 5b 6f 0b 64 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1983.668923] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 69 5b 61 0b 65 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1983.678819] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 69 5b 64 0b 65 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1983.689230] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 69 5b 66 0b 65 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1983.699435] i2c_hid i2c-DLL060A:00: input: 20 00 0c 0c 01 00 69 5b 68 0b 65 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1983.709502] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 69 5b 6a 0b 66 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1983.719574] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 69 5b 6c 0b 66 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1983.729713] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 69 5b 6e 0b 66 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1983.739863] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 6a 5b 60 0b 66 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1983.750001] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 6a 5b 62 0b 66 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1983.760150] i2c_hid i2c-DLL060A:00: input: 20 00 0c 0c 01 00 6a 5b 64 0b 67 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1983.770291] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 6a 5b 66 0b 67 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1983.780445] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 6a 5b 68 0b 67 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1983.790490] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 6a 5b 5a 0b 68 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1983.800667] i2c_hid i2c-DLL060A:00: input: 20 00 0c 0c 01 00 6a 5b 4e 0c 69 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1983.810691] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 6b 5b 31 0c 69 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1983.820963] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 6b 5b 24 0c 6a 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1983.831071] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 6b 5b 17 0c 6a 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1983.841178] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 6b 5b 09 0c 6a 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1983.851325] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 6b 5b 0b 0c 6b 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1983.861435] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 6b 5b 0d 0c 6b 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1983.871566] i2c_hid i2c-DLL060A:00: input: 20 00 0c 0c 01 00 6b 5b 0f 0c 6b 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1983.881735] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 6c 5b 01 0c 6b 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1983.891975] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 6c 5b 03 0c 6b 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1983.902073] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 6c 5b 05 0c 6c 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1983.912155] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 6c 5b 07 0c 6b 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1983.922224] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 6c 5b 09 0c 6c 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1983.932364] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 6c 5b 0b 0c 6c 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1983.942480] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 6c 5b 0d 0c 6c 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1983.952612] i2c_hid i2c-DLL060A:00: input: 20 00 0c 0c 01 00 6c 5b 0f 0c 6c 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1983.962774] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 6d 5a f1 0d 6d 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1983.972932] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 6d 5a f3 0d 6e 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1983.982872] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 6d 5a f6 0d 6f 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1983.993194] i2c_hid i2c-DLL060A:00: input: 20 00 0c 0c 01 00 6d 5a f9 0d 6f 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1984.003295] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 6d 5a fc 0d 6f 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1984.013511] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 6d 5a ff 0d 70 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1984.023590] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 6e 5a f2 0d 70 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1984.033747] i2c_hid i2c-DLL060A:00: input: 20 00 0c 0c 01 00 6e 5a f5 0e 71 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1984.043850] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 6e 5a f8 0e 71 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1984.053873] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 6e 5a fb 0e 71 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1984.064077] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 6e 5a fe 0e 72 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1984.074207] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 6f 5a f1 0e 72 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1984.084425] i2c_hid i2c-DLL060A:00: input: 20 00 0c 0c 01 00 6f 5a f3 0e 72 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1984.094533] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 6f 5a f6 0e 73 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1984.104629] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 6f 5a f8 0e 73 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1984.114742] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 6f 5a fa 0e 73 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1984.124890] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 6f 5a fc 0e 73 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1984.135006] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 6f 5a fe 0e 73 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1984.145149] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 70 5a f0 0e 73 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1984.155317] i2c_hid i2c-DLL060A:00: input: 20 00 0c 0c 01 00 70 5a e2 0e 73 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1984.165380] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 70 5a d4 0d 74 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1984.175532] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 70 5a d6 0d 74 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1984.185409] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 70 5a d8 0d 75 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1984.195761] i2c_hid i2c-DLL060A:00: input: 20 00 0c 0c 01 00 70 5a db 0d 75 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1984.205909] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 70 5a dd 0d 75 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1984.216034] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 71 5a d0 0e 76 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1984.226198] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 71 5a d3 0e 77 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1984.236301] i2c_hid i2c-DLL060A:00: input: 20 00 0c 0c 01 00 71 5a d6 0e 77 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1984.246520] i2c_hid i2c-DLL060A:00: input: 20 00 0c 0c 01 00 71 5a cb 0f 79 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1984.256573] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 01 00 72 5a b1 0e 78 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1984.266697] i2c_hid i2c-DLL060A:00: input: 20 00 0c 0c 01 00 72 5a a7 0e 77 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1984.276823] i2c_hid i2c-DLL060A:00: input: 20 00 0c 0c 01 00 72 5a 6d 0d 72 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1984.286921] i2c_hid i2c-DLL060A:00: input: 20 00 0c 0c 01 00 73 59 96 0a 5a 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1984.296888] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 00 00 73 59 96 00 00 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1984.306825] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 00 00 73 59 96 00 00 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>>> [ 1984.316980] i2c_hid i2c-DLL060A:00: input: 20 00 0c 04 00 00 73 59 96 00 00 03 09 40 00 00 90 86 1d 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>>>> The last report which repeats indicates that no fingers are present.
>>>>>> But, the click button is generating the interrupt and it is reporting
>>>>>> that it is in the down position. Could the click button be getting stuck
>>>>>> down? That would also explain why the data in the report is not
>>>>>> changing. Could you be bumping the touchpad with your palm which is
>>>>>> causing the click button to get stuck in the down position? That might
>>>>>> also explain the large width value. Our max width is 15, so 12 would
>>>>>> typically indicate a contact larger then a normal finger contact. That
>>>>>> would explain the width of 12 showing up when this happens.
>>>>> Yes, that's not a normal finger touch and the reported width seems
>>>>> quite accurate to me. There are no clicks involved, laying the side of
>>>>> my thumb gently on the top part of the clickpad (from where even voluntary
>>>>> clicks are hard to obtain) is enough to trigger the bug. If a click is
>>>>> reported, than something is really wrong.
>>>> Do the reports look the same? With the repeated reports starting with
>>>> "20 00 0c 04"?
>>> I'm not sure I understood exactly what you want to know, so this might
>>> not answer your questions.
>>>
>>> All the repeated messages look like this:
>>>
>>> 20 00 0c 04 00 00 27 57 fa 00 00 07 8a 0c 00 00 7e 87 eb 00 00 aa 8f 37 00 00 61 4d f1 00 00 00
>>>
>>> The values equal to zero are always equal to zero when there are no
>>> fingers on the touchpad. The non-zero values are equal to the last
>>> valid value recorded and don't change when the fingers are released.
>>>
>>> To get the above line I touched the touchpad with 5 fingers so that
>>> all the bytes (except the last one which is different from zero on
>>> click release) were used.
>> Yes, that was the information I was looking for. But, this must not be
>> my day since it turns out I misremembered what 0x4 stood for and this is
>> unrelated to the click button. You can ignore everything I said about
>> the click button =)
>>
>> The report you have above is actually a finger lift report which
>> indicates that all of the fingers left the touchpad. I checked the
>> firmware configuration for this touchpad and it will repeat the lift
>> report probably about 40 times. This is the expected behavior. However,
>> you reported earlier that the message had been repeated 81 times? That
>> seems a bit high and it would not explain why it gets repeated indefinitely.
>>
>> You can try disabling the repeating finger lift reports and see if that
>> helps. To do that you need to download a utility at:
>> https://github.com/aduggan/rmi4utils
>>
>> After building it run:
>> $ sudo ./rmihidtool -r 0x45 1 /dev/hidraw0
>> This should print out 0x78 assuming the register address is what I
>> expect. If not I can send further instructions on how to figure that out.
>>
>> To disable the repeating lift report run:
>> $ sudo ./rmihidtool -w 0x45 0x38 /dev/hidraw0
>>
>> After you do that there should only be one finger lift report.
> Yes, this disables the repeating lift report, but the bug is still there.
Ok, I would have been surprised if this fixed it. But, at least it helps
to narrow down the cause.
>
>> Also, if you can get the firmware id from your touchpad that would also
>> be useful.
>>
>> $ sudo ./rmihidtool -f /dev/hidraw0
> firmware id: 1522295
Thanks, I will see if I can get any additional information on this.
Andrew
^ permalink raw reply
* Re: [PATCHv3 5/5] ARM: sunxi: dts: Add note ps2 pins conflict with hdmi
From: Chen-Yu Tsai @ 2014-12-13 2:06 UTC (permalink / raw)
To: VishnuPatekar
Cc: linux-input@vger.kernel.org, Maxime Ripard, Dmitry Torokhov,
Hans De Goede, Mark Rutland, devicetree, Russell King - ARM Linux,
Pawel Moll, Ian Campbell, benh, msalter, linux-kernel, ralf,
Rob Herring, jdelvare, Kumar Gala, Grant Likely, linux-arm-kernel
In-Reply-To: <1418408748-9797-6-git-send-email-vishnupatekar0510@gmail.com>
Hi,
On Sat, Dec 13, 2014 at 2:25 AM, VishnuPatekar
<vishnupatekar0510@gmail.com> wrote:
> 1. Please note that ps20 pins conflict with HDMI on Lime2 Board
> so, by deault ps20 and ps21 are disabled for Lime2 Board.
> There is no on board ps2 connector and these pins can be used
> for different purpose.
>
> Signed-off-by: VishnuPatekar <vishnupatekar0510@gmail.com>
> ---
> arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
> index ed364d5..951b615 100644
> --- a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
> +++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
> @@ -112,7 +112,11 @@
> pinctrl-0 = <&uart0_pins_a>;
> status = "okay";
> };
> -
> +
> + /* PS2 0 and PS2 1 are disabled by default; Please note that
> + ps20 pins conflict with HDMI on Lime2 Board
> + */
> +
Multi-line comments should be:
/*
* line 1
* line 2
* ...
*/
And why is there a delete and insert for an empty line?
Weird... though git seems to ignore it when applying.
ChenYu
> i2c0: i2c@01c2ac00 {
> pinctrl-names = "default";
> pinctrl-0 = <&i2c0_pins_a>;
> --
> 1.7.9.5
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v14 00/12] input: cyapa: instruction of cyapa patches
From: Jeremiah Mahler @ 2014-12-13 10:17 UTC (permalink / raw)
To: Dudley Du; +Cc: linux-input, linux-kernel
In-Reply-To: <1418351262-8163-1-git-send-email-dudley.dulixin@gmail.com>
Dudley,
On Fri, Dec 12, 2014 at 10:27:30AM +0800, Dudley Du wrote:
> V14 patches have below updates, details of other updates see history list:
> 1) Correct 9 miss spelling issues of "bufferred" to "buffered".
> 2) Fix the upgrade issue of removing MOUSE_CYAPA config when make oldconfig
> by replase "depends on I2C && CRC_ITU_T" with
> "depends on I2C"
> "select CRC_ITU_T"
> in patch 9.
>
[...]
I found some sparse warnings that should be fixed.
jeri@newt:~/linux-next$ touch drivers/input/mouse/*.c
jeri@newt:~/linux-next$ touch drivers/input/mouse/*.h
jeri@newt:~/linux-next$ make C=1
CHK include/config/kernel.release
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
CALL scripts/checksyscalls.sh
CHK include/generated/compile.h
CHK kernel/config_data.h
CHECK drivers/input/mouse/cyapa.c
drivers/input/mouse/cyapa.c:43:9: warning: symbol 'cyapa_i2c_read' was
not declared. Should it be static?
drivers/input/mouse/cyapa.c:80:9: warning: symbol 'cyapa_i2c_write' was
not declared. Should it be static?
drivers/input/mouse/cyapa.c:289:5: warning: symbol 'cyapa_detect' was
not declared. Should it be static?
CC [M] drivers/input/mouse/cyapa.o
CHECK drivers/input/mouse/cyapa_gen3.c
drivers/input/mouse/cyapa_gen3.c:299:5: warning: symbol
'cyapa_read_byte' was not declared. Should it be static?
drivers/input/mouse/cyapa_gen3.c:312:5: warning: symbol
'cyapa_write_byte' was not declared. Should it be static?
drivers/input/mouse/cyapa_gen3.c:331:9: warning: symbol
'cyapa_i2c_reg_write_block' was not declared. Should it be static?
CC [M] drivers/input/mouse/cyapa_gen3.o
CHECK drivers/input/mouse/cyapa_gen5.c
drivers/input/mouse/cyapa_gen5.c:334:5: warning: symbol
'cyapa_empty_pip_output_data' was not declared. Should it be static?
drivers/input/mouse/cyapa_gen5.c:553:6: warning: symbol
'cyapa_gen5_sort_tsg_pip_bl_resp_data' was not declared. Should it be
static?
drivers/input/mouse/cyapa_gen5.c:568:6: warning: symbol
'cyapa_gen5_sort_tsg_pip_app_resp_data' was not declared. Should it be
static?
drivers/input/mouse/cyapa_gen5.c:595:6: warning: symbol
'cyapa_gen5_sort_application_launch_data' was not declared. Should it be
static?
drivers/input/mouse/cyapa_gen5.c:995:6: warning: symbol
'cyapa_gen5_sort_bl_exit_data' was not declared. Should it be static?
drivers/input/mouse/cyapa_gen5.c:1112:72: warning: Using plain integer
as NULL pointer
CC [M] drivers/input/mouse/cyapa_gen5.o
LD [M] drivers/input/mouse/cyapatp.o
Kernel: arch/x86/boot/bzImage is ready (#127)
Building modules, stage 2.
MODPOST 187 modules
CC drivers/input/mouse/cyapatp.mod.o
LDFINAL [M] drivers/input/mouse/cyapatp.ko
jeri@newt:~/linux-next
--
- Jeremiah Mahler
^ permalink raw reply
* Re: [PATCHv3 0/5] ARM:sunxi:ps2 Added support for A10/A20 ps2 controller.
From: Hans de Goede @ 2014-12-13 11:09 UTC (permalink / raw)
To: VishnuPatekar, linux-input, maxime.ripard, dmitry.torokhov
Cc: devicetree, linux-arm-kernel, linux-kernel, robh+dt, pawel.moll,
mark.rutland, ijc+devicetree, galak, linux, grant.likely, benh,
msalter, ralf, jdelvare
In-Reply-To: <1418408748-9797-1-git-send-email-vishnupatekar0510@gmail.com>
Hi VishnuPatekar,
The patch mangling for this set seems to have gone a bit wrong I'm afraid,
a lot of the patches have my fixup commit messages (which should have
disappeared when squashing in the patches), please replace those by proper
commit messages describing what the patch actually does.
Also the adding of the commented nodes for the lime2 seems to be gone entirely
from the set, instead now only a comment about the conflict with the hdmi
pins is added, but it is above the i2c node instead of above a ps2 node.
Regards,
Hans
On 12-12-14 19:25, VishnuPatekar wrote:
> v2 --> v3
> 1. changed config to SERIO_SUN4I_PS2 from SERIO_SUNXI_PS2
> 2. changed driver name to sun4i-ps2 from sunxi-ps2.
> 3. changed the function names to sun4i_ps2_*.
> 4. added locking in sun4i_ps2_open.
> 5. kept compatible "sun4i-a10-ps2" for A10 and A20, as A10 is earlier SOC.
> 6. corrected the style errors.
> 7. separated the dts patches.
> 8. removed commented ps2 notes from lime2 dts.
> 9. added note that ps2 pins confilt with hdmi.
> 10. corrected the interrupt property for A10.
> 11. moved dt-bindings to Documentation/devicetree/bindings/serio
>
> v1 --> v2:
> 1. added default n depends on ARCH_SUNXI || COMPILE_TEST in Kconfig.
> 2. handled errors and free resources on errors.
> 3. used BIT(x), DIV_ROUND_UP macros.
> 4. corrected style errors.
> 5. added support for A10 also, A10 and A2 have same properties of PS2 controller.
> 6. by default commented ps20 and ps21 nodes,as ps20 pins conflict with HDMI.
> 7. added compatible as allwinner,sun4i-a10-ps2.
> 8. corrected the possible race condition.
>
>
> VishnuPatekar (5):
> sunxi:dts-bindings:input:ps2 bindings for A10/A20 ps2.
> ARM:sunxi:drivers:input Add support for A10/A20 PS2
> ARM: sunxi: dts: Add PS2 nodes to dtsi for A10 and A20
> ARM: sunxi: dts: Add A10/A20 PS2 pin muxing options
> ARM: sunxi: dts: Add note ps2 pins conflict with hdmi
>
> .../bindings/serio/allwinner,sun4i-ps2.txt | 23 ++
> arch/arm/boot/dts/sun4i-a10.dtsi | 31 ++
> arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts | 6 +-
> arch/arm/boot/dts/sun7i-a20.dtsi | 32 ++
> drivers/input/serio/Kconfig | 11 +
> drivers/input/serio/Makefile | 1 +
> drivers/input/serio/sun4i-ps2.c | 362 ++++++++++++++++++++
> 7 files changed, 465 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/devicetree/bindings/serio/allwinner,sun4i-ps2.txt
> create mode 100644 drivers/input/serio/sun4i-ps2.c
>
^ permalink raw reply
* Re: [PATCH v14 01/12] input: cyapa: re-design driver to support multi-trackpad in one driver
From: Jeremiah Mahler @ 2014-12-13 11:16 UTC (permalink / raw)
To: Dudley Du; +Cc: dmitry.torokhov, rydberg, bleung, linux-input, linux-kernel
In-Reply-To: <1418351262-8163-2-git-send-email-dudley.dulixin@gmail.com>
Dudley,
A few suggestions and questions below...
On Fri, Dec 12, 2014 at 10:27:31AM +0800, Dudley Du wrote:
> In order to support multiple different chipsets and communication protocols
> trackpad devices in one cyapa driver, the new cyapa driver is re-designed
> with one cyapa driver core and multiple device specific functions component.
> The cyapa driver core is contained in this patch, it supplies basic functions
> that working with kernel and input subsystem, and also supplies the interfaces
> that the specific devices' component can connect and work together with as
> one driver.
> TEST=test on Chromebooks.
>
> Signed-off-by: Dudley Du <dudley.dulixin@gmail.com>
> ---
> drivers/input/mouse/Makefile | 3 +-
> drivers/input/mouse/cyapa.c | 1050 ++++++++++++++------------------------
> drivers/input/mouse/cyapa.h | 316 ++++++++++++
[...]
> - { REG_OFFSET_QUERY_BASE, QUERY_DATA_SIZE },
> - { BL_HEAD_OFFSET, 3 },
> - { BL_HEAD_OFFSET, 16 },
> - { BL_HEAD_OFFSET, 16 },
> - { BL_DATA_OFFSET, 16 },
> - { BL_HEAD_OFFSET, 32 },
> - { REG_OFFSET_QUERY_BASE, PRODUCT_ID_SIZE },
> - { REG_OFFSET_DATA_BASE, 32 }
> -};
> +const char unique_str[] = "CYTRA";
>
Since 'unique_str' is used to check the product id why not call it
'product_id'?
[...]
> +/**
> + * cyapa_i2c_write - Execute i2c block data write operation
> + * @cyapa: Handle to this driver
> + * @ret: Offset of the data to written in the register map
> + * @len: number of bytes to write
> + * @values: Data to be written
> *
> - * Note:
> - * In trackpad device, the memory block allocated for I2C register map
> - * is 256 bytes, so the max read block for I2C bus is 256 bytes.
> + * Return negative errno code on error; return zero when success.
> */
> -static ssize_t cyapa_smbus_read_block(struct cyapa *cyapa, u8 cmd, size_t len,
> - u8 *values)
> +ssize_t cyapa_i2c_write(struct cyapa *cyapa, u8 reg,
> + size_t len, const void *values)
> {
> - ssize_t ret;
> - u8 index;
> - u8 smbus_cmd;
> - u8 *buf;
> + int ret;
> struct i2c_client *client = cyapa->client;
> + char data[32], *buf;
>
> - if (!(SMBUS_BYTE_BLOCK_CMD_MASK & cmd))
> - return -EINVAL;
> -
> - if (SMBUS_GROUP_BLOCK_CMD_MASK & cmd) {
> - /* read specific block registers command. */
> - smbus_cmd = SMBUS_ENCODE_RW(cmd, SMBUS_READ);
> - ret = i2c_smbus_read_block_data(client, smbus_cmd, values);
> - goto out;
> - }
> -
> - ret = 0;
> - for (index = 0; index * I2C_SMBUS_BLOCK_MAX < len; index++) {
> - smbus_cmd = SMBUS_ENCODE_IDX(cmd, index);
> - smbus_cmd = SMBUS_ENCODE_RW(smbus_cmd, SMBUS_READ);
> - buf = values + I2C_SMBUS_BLOCK_MAX * index;
> - ret = i2c_smbus_read_block_data(client, smbus_cmd, buf);
> - if (ret < 0)
> - goto out;
> - }
> -
> -out:
> - return ret > 0 ? len : ret;
> -}
> -
> -static s32 cyapa_read_byte(struct cyapa *cyapa, u8 cmd_idx)
> -{
> - u8 cmd;
> -
> - if (cyapa->smbus) {
> - cmd = cyapa_smbus_cmds[cmd_idx].cmd;
> - cmd = SMBUS_ENCODE_RW(cmd, SMBUS_READ);
> + if (len > 31) {
> + buf = kzalloc(len + 1, GFP_KERNEL);
> + if (!buf)
> + return -ENOMEM;
> } else {
> - cmd = cyapa_i2c_cmds[cmd_idx].cmd;
> + buf = data;
> }
> - return i2c_smbus_read_byte_data(cyapa->client, cmd);
> -}
>
> -static s32 cyapa_write_byte(struct cyapa *cyapa, u8 cmd_idx, u8 value)
> -{
> - u8 cmd;
> + buf[0] = reg;
> + memcpy(&buf[1], values, len);
> + ret = i2c_master_send(client, buf, len + 1);
>
> - if (cyapa->smbus) {
> - cmd = cyapa_smbus_cmds[cmd_idx].cmd;
> - cmd = SMBUS_ENCODE_RW(cmd, SMBUS_WRITE);
> - } else {
> - cmd = cyapa_i2c_cmds[cmd_idx].cmd;
> - }
> - return i2c_smbus_write_byte_data(cyapa->client, cmd, value);
> + if (buf != data)
> + kfree(buf);
> + return (ret == (len + 1)) ? 0 : ((ret < 0) ? ret : -EIO);
> }
>
Ugh. This is hard to read since diff replaced three functions with one,
cyapa_i2c_write(). Nothing can be done about this, just a note for the
other reviewers.
The final cyapa_i2c_write() is shown below.
/**
* cyapa_i2c_write - Execute i2c block data write operation
* @cyapa: Handle to this driver
* @ret: Offset of the data to written in the register map
* @len: number of bytes to write
* @values: Data to be written
*
* Return negative errno code on error; return zero when success.
*/
ssize_t cyapa_i2c_write(struct cyapa *cyapa, u8 reg,
size_t len, const void *values)
{
int ret;
struct i2c_client *client = cyapa->client;
char data[32], *buf;
if (len > 31) {
buf = kzalloc(len + 1, GFP_KERNEL);
if (!buf)
return -ENOMEM;
} else {
buf = data;
}
buf[0] = reg;
memcpy(&buf[1], values, len);
ret = i2c_master_send(client, buf, len + 1);
if (buf != data)
kfree(buf);
return (ret == (len + 1)) ? 0 : ((ret < 0) ? ret : -EIO);
}
What is interesting about this code is that it switches between buffers
depending on length. If it is less than or equal to 31 bytes a static
buffer is used. If it is larger, memory is allocated.
Is this complexity justified or is this premature optimization?
I could only find one place where cyapa_i2c_write() was used and it only
involved 2 bytes so 32 is plenty.
Why not simplify it and only use the static buffer and just reject
anything that is too large?
ssize_t cyapa_i2c_write(struct cyapa *cyapa, u8 reg,
size_t len, const void *values)
{
int ret;
struct i2c_client *client = cyapa->client;
char buf[32];
if (len > 31)
return -ENOMEM;
buf[0] = reg;
memcpy(&buf[1], values, len);
ret = i2c_master_send(client, buf, len + 1);
return (ret == (len + 1)) ? 0 : ((ret < 0) ? ret : -EIO);
}
[...]
--
- Jeremiah Mahler
^ permalink raw reply
* Re: [PATCH v2] input: edt-ft5x06: fixed a macro coding style issue
From: Dmitry Torokhov @ 2014-12-13 18:59 UTC (permalink / raw)
To: Asaf Vertz
Cc: LW, B38611, maksqwe1, jg1.han, linux, fabf, joe, linux-input,
linux-kernel
In-Reply-To: <20141209080816.GA19581@ubuntu>
On Tue, Dec 09, 2014 at 10:08:16AM +0200, Asaf Vertz wrote:
> Fixed a coding style error, macros with complex values should be
> enclosed in parentheses.
>
> Signed-off-by: Asaf Vertz <asaf.vertz@tandemg.com>
Applied, thank you.
> ---
> Changes in v2:
> - use do {...} while (0) instead of {...}
>
> drivers/input/touchscreen/edt-ft5x06.c | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/input/touchscreen/edt-ft5x06.c b/drivers/input/touchscreen/edt-ft5x06.c
> index ee3434f..d22ed56 100644
> --- a/drivers/input/touchscreen/edt-ft5x06.c
> +++ b/drivers/input/touchscreen/edt-ft5x06.c
> @@ -850,9 +850,11 @@ static int edt_ft5x06_ts_identify(struct i2c_client *client,
> }
>
> #define EDT_ATTR_CHECKSET(name, reg) \
> +do { \
> if (pdata->name >= edt_ft5x06_attr_##name.limit_low && \
> pdata->name <= edt_ft5x06_attr_##name.limit_high) \
> - edt_ft5x06_register_write(tsdata, reg, pdata->name)
> + edt_ft5x06_register_write(tsdata, reg, pdata->name); \
> +} while (0)
>
> #define EDT_GET_PROP(name, reg) { \
> u32 val; \
> --
> 1.7.0.4
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: gpio_keys - fix warning regarding uninitialized 'button' variable
From: Dmitry Torokhov @ 2014-12-13 19:00 UTC (permalink / raw)
To: Fabio Estevam; +Cc: linux-input, festevam
In-Reply-To: <1418136252-14365-1-git-send-email-fabio.estevam@freescale.com>
On Tue, Dec 09, 2014 at 12:44:12PM -0200, Fabio Estevam wrote:
> Commit af906faabcf91eb1 ("Input: gpio_keys - fix warning regarding uninitialized
> 'irq' variable") introduced the following build warning:
>
> drivers/input/keyboard/gpio_keys.c:625:16: warning: 'button' may be used uninitialized in this function [-Wmaybe-uninitialized]
>
> Move the 'button' initialization to a proper location to avoid such warning.
Doh! Why didn't I see the warning at least? Argh!
Applied, thank you.
>
> Reported-by: Olof's autobuilder <build@lixom.net>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
> drivers/input/keyboard/gpio_keys.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/input/keyboard/gpio_keys.c b/drivers/input/keyboard/gpio_keys.c
> index fb8256f..28ac922 100644
> --- a/drivers/input/keyboard/gpio_keys.c
> +++ b/drivers/input/keyboard/gpio_keys.c
> @@ -621,6 +621,8 @@ gpio_keys_get_devtree_pdata(struct device *dev)
> int gpio = -1;
> enum of_gpio_flags flags;
>
> + button = &pdata->buttons[i++];
> +
> if (!of_find_property(pp, "gpios", NULL)) {
> button->irq = irq_of_parse_and_map(pp, 0);
> if (button->irq == 0) {
> @@ -640,8 +642,6 @@ gpio_keys_get_devtree_pdata(struct device *dev)
> }
> }
>
> - button = &pdata->buttons[i++];
> -
> button->gpio = gpio;
> button->active_low = flags & OF_GPIO_ACTIVE_LOW;
>
> --
> 1.9.1
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: gpio_keys - fix warning regarding uninitialized 'button' variable
From: Dmitry Torokhov @ 2014-12-13 19:05 UTC (permalink / raw)
To: Fabio Estevam; +Cc: linux-input, festevam
In-Reply-To: <20141213190035.GB22702@dtor-ws>
On Sat, Dec 13, 2014 at 11:00:35AM -0800, Dmitry Torokhov wrote:
> On Tue, Dec 09, 2014 at 12:44:12PM -0200, Fabio Estevam wrote:
> > Commit af906faabcf91eb1 ("Input: gpio_keys - fix warning regarding uninitialized
> > 'irq' variable") introduced the following build warning:
> >
> > drivers/input/keyboard/gpio_keys.c:625:16: warning: 'button' may be used uninitialized in this function [-Wmaybe-uninitialized]
> >
> > Move the 'button' initialization to a proper location to avoid such warning.
>
> Doh! Why didn't I see the warning at least? Argh!
>
> Applied, thank you.
>
> >
> > Reported-by: Olof's autobuilder <build@lixom.net>
> > Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> > ---
> > drivers/input/keyboard/gpio_keys.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/input/keyboard/gpio_keys.c b/drivers/input/keyboard/gpio_keys.c
> > index fb8256f..28ac922 100644
> > --- a/drivers/input/keyboard/gpio_keys.c
> > +++ b/drivers/input/keyboard/gpio_keys.c
> > @@ -621,6 +621,8 @@ gpio_keys_get_devtree_pdata(struct device *dev)
> > int gpio = -1;
> > enum of_gpio_flags flags;
> >
> > + button = &pdata->buttons[i++];
> > +
> > if (!of_find_property(pp, "gpios", NULL)) {
> > button->irq = irq_of_parse_and_map(pp, 0);
> > if (button->irq == 0) {
By the way, I added
i--;
here to avoid skipping over one element.
> > @@ -640,8 +642,6 @@ gpio_keys_get_devtree_pdata(struct device *dev)
> > }
> > }
> >
> > - button = &pdata->buttons[i++];
> > -
> > button->gpio = gpio;
> > button->active_low = flags & OF_GPIO_ACTIVE_LOW;
> >
> > --
> > 1.9.1
> >
>
> --
> Dmitry
--
Dmitry
^ permalink raw reply
* Re: [PATCH 2/2] Input: gpio_keys - replace timer and workqueue with delayed workqueue
From: Dmitry Torokhov @ 2014-12-13 19:09 UTC (permalink / raw)
To: Andy Shevchenko
Cc: linux-input, Alexander Stein, Linus Walleij, Ezequiel Garcia,
Alexander Shiyan, Laxman Dewangan, devicetree, linux-kernel
In-Reply-To: <1418236376.17201.57.camel@linux.intel.com>
Hi Andy,
On Wed, Dec 10, 2014 at 08:32:56PM +0200, Andy Shevchenko wrote:
> On Sun, 2014-12-07 at 23:21 -0800, Dmitry Torokhov wrote:
> > We do not need to roll our own implementation of delayed work now that we
> > have proper implementation of mod_delayed_work.
> >
> > For interrupt-only driven buttons we retain the timer, but we rename
> > it to release_timer to better reflect its purpose.
>
> At least it doesn't break the driver on Intel Medfield device.
>
> Tested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Thank you for testing it. Assume it is for both patches, right?
--
Dmitry
^ permalink raw reply
* Re: [PATCH v6 1/2] Input: add regulator haptic driver
From: Dmitry Torokhov @ 2014-12-13 19:56 UTC (permalink / raw)
To: Jaewon Kim
Cc: Kukjin Kim, linux-kernel, linux-samsung-soc, linux-input,
Chanwoo Choi, Hyunhee Kim
In-Reply-To: <1418380349-32588-2-git-send-email-jaewon02.kim@samsung.com>
Hi Jaewon,
On Fri, Dec 12, 2014 at 07:32:28PM +0900, Jaewon Kim wrote:
> This patch adds support for haptic driver controlled by
> voltage of regulator. And this driver support for
> Force Feedback interface from input framework
>
> Signed-off-by: Jaewon Kim <jaewon02.kim@samsung.com>
> Signed-off-by: Hyunhee Kim <hyunhee.kim@samsung.com>
> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
> Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
> Reviewed-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> ---
> .../devicetree/bindings/input/regulator-haptic.txt | 21 ++
> drivers/input/misc/Kconfig | 11 +
> drivers/input/misc/Makefile | 1 +
> drivers/input/misc/regulator-haptic.c | 259 ++++++++++++++++++++
> include/linux/input/regulator-haptic.h | 31 +++
> 5 files changed, 323 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/input/regulator-haptic.txt
> create mode 100644 drivers/input/misc/regulator-haptic.c
> create mode 100644 include/linux/input/regulator-haptic.h
>
> diff --git a/Documentation/devicetree/bindings/input/regulator-haptic.txt b/Documentation/devicetree/bindings/input/regulator-haptic.txt
> new file mode 100644
> index 0000000..3ed1c7e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/regulator-haptic.txt
> @@ -0,0 +1,21 @@
> +* Regulator Haptic Device Tree Bindings
> +
> +Required Properties:
> + - compatible : Should be "regulator-haptic"
> + - haptic-supply : Power supply to the haptic motor.
> + [*] refer Documentation/devicetree/bindings/regulator/regulator.txt
> +
> + - max-microvolt : The maximum voltage value supplied to the haptic motor.
> + [The unit of the voltage is a micro]
> +
> + - min-microvolt : The minimum voltage value supplied to the haptic motor.
> + [The unit of the voltage is a micro]
> +
> +Example:
> +
> + haptics {
> + compatible = "regulator-haptic";
> + haptic-supply = <&motor_regulator>;
> + max-microvolt = <2700000>;
> + min-microvolt = <1100000>;
> + };
> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
> index 23297ab..e5e556d 100644
> --- a/drivers/input/misc/Kconfig
> +++ b/drivers/input/misc/Kconfig
> @@ -394,6 +394,17 @@ config INPUT_CM109
> To compile this driver as a module, choose M here: the module will be
> called cm109.
>
> +config INPUT_REGULATOR_HAPTIC
> + tristate "regulator haptics support"
> + select INPUT_FF_MEMLESS
> + help
> + This option enables device driver support for the haptic controlled
> + by regulator. This driver supports ff-memless interface
> + from input framework.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called regulator-haptic.
> +
> config INPUT_RETU_PWRBUTTON
> tristate "Retu Power button Driver"
> depends on MFD_RETU
> diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
> index 19c7603..1f135af 100644
> --- a/drivers/input/misc/Makefile
> +++ b/drivers/input/misc/Makefile
> @@ -53,6 +53,7 @@ obj-$(CONFIG_INPUT_PMIC8XXX_PWRKEY) += pmic8xxx-pwrkey.o
> obj-$(CONFIG_INPUT_POWERMATE) += powermate.o
> obj-$(CONFIG_INPUT_PWM_BEEPER) += pwm-beeper.o
> obj-$(CONFIG_INPUT_RB532_BUTTON) += rb532_button.o
> +obj-$(CONFIG_INPUT_REGULATOR_HAPTIC) += regulator-haptic.o
> obj-$(CONFIG_INPUT_RETU_PWRBUTTON) += retu-pwrbutton.o
> obj-$(CONFIG_INPUT_GPIO_ROTARY_ENCODER) += rotary_encoder.o
> obj-$(CONFIG_INPUT_SGI_BTNS) += sgi_btns.o
> diff --git a/drivers/input/misc/regulator-haptic.c b/drivers/input/misc/regulator-haptic.c
> new file mode 100644
> index 0000000..2fa94bc
> --- /dev/null
> +++ b/drivers/input/misc/regulator-haptic.c
> @@ -0,0 +1,259 @@
> +/*
> + * Regulator haptic driver
> + *
> + * Copyright (c) 2014 Samsung Electronics Co., Ltd.
> + * Author: Jaewon Kim <jaewon02.kim@samsung.com>
> + * Author: Hyunhee Kim <hyunhee.kim@samsung.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include <linux/input.h>
> +#include <linux/input/regulator-haptic.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/regulator/consumer.h>
> +#include <linux/slab.h>
> +
> +#define MAX_MAGNITUDE_SHIFT 16
> +
> +struct regulator_haptic {
> + struct device *dev;
> + struct input_dev *input_dev;
> + struct regulator *regulator;
> +
> + struct work_struct work;
> + struct mutex mutex;
> +
> + bool enabled;
> + bool suspend_state;
> + unsigned int max_volt;
> + unsigned int min_volt;
> + unsigned int intensity;
> + unsigned int magnitude;
> +};
> +
> +static void regulator_haptic_enable(struct regulator_haptic *haptic, bool state)
> +{
> + int error;
> +
> + if (haptic->enabled == state)
> + return;
> +
> + if (state)
> + error = regulator_enable(haptic->regulator);
> + else
> + error = regulator_disable(haptic->regulator);
> + if (error) {
Hmm, maybe:
error = state ? regulator_enable(haptic->regulator) :
regulator_disable(haptic->regulator);
if (error)
...
> + dev_err(haptic->dev, "cannot enable regulator\n");
> + return;
> + }
> +
> + haptic->enabled = state;
> +}
> +
> +static void regulator_haptic_work(struct work_struct *work)
> +{
> + struct regulator_haptic *haptic = container_of(work,
> + struct regulator_haptic, work);
> + int error;
> +
> + if (haptic->suspend_state)
> + return;
> +
Why is this check outside of mutex?
> + mutex_lock(&haptic->mutex);
> +
> + error = regulator_set_voltage(haptic->regulator,
> + haptic->intensity + haptic->min_volt, haptic->max_volt);
> + if (error) {
> + dev_err(haptic->dev, "cannot set regulator voltage\n");
> + goto err;
> + }
> +
> + if (haptic->magnitude)
> + regulator_haptic_enable(haptic, true);
> + else
> + regulator_haptic_enable(haptic, false);
> +
> +err:
> + mutex_unlock(&haptic->mutex);
> +}
> +
> +static int regulator_haptic_play_effect(struct input_dev *input, void *data,
> + struct ff_effect *effect)
> +{
> + struct regulator_haptic *haptic = input_get_drvdata(input);
> + u64 volt_mag_multi;
> +
> + haptic->magnitude = effect->u.rumble.strong_magnitude;
> + if (!haptic->magnitude)
> + haptic->magnitude = effect->u.rumble.weak_magnitude;
> +
> +
> + volt_mag_multi = (u64)(haptic->max_volt - haptic->min_volt) *
> + haptic->magnitude;
> + haptic->intensity = (unsigned int)(volt_mag_multi >>
> + MAX_MAGNITUDE_SHIFT);
> +
> + schedule_work(&haptic->work);
> +
> + return 0;
> +}
> +
> +static void regulator_haptic_close(struct input_dev *input)
> +{
> + struct regulator_haptic *haptic = input_get_drvdata(input);
> +
> + cancel_work_sync(&haptic->work);
> + regulator_haptic_enable(haptic, false);
> +}
> +
> +#ifdef CONFIG_OF
> +static int regulator_haptic_parse_dt(struct regulator_haptic *haptic)
> +{
> + struct device_node *node = haptic->dev->of_node;
> + int error;
> +
> + error = of_property_read_u32(node, "max-microvolt", &haptic->max_volt);
> + if (error) {
> + dev_err(haptic->dev, "cannot parse max-microvolt\n");
> + return error;
> + }
> +
> + error = of_property_read_u32(node, "min-microvolt", &haptic->min_volt);
> + if (error) {
> + dev_err(haptic->dev, "cannot parse min-microvolt\n");
> + return error;
> + }
> +
> + return 0;
> +}
> +#else
> +static int regulator_haptic_parse_dt(struct regulator_haptic *haptic)
> +{
> + return 0;
This does not seem right. If you do not have platform data and CONFOG_OF
is disabled you can't continue initialization.
> +}
> +#endif /* CONFIG_OF */
> +
> +static int regulator_haptic_probe(struct platform_device *pdev)
> +{
> + struct regulator_haptic *haptic;
> + struct regulator_haptic_data *data = dev_get_platdata(&pdev->dev);
> + struct input_dev *input_dev;
> + int error;
> +
> + haptic = devm_kzalloc(&pdev->dev, sizeof(*haptic), GFP_KERNEL);
> + if (!haptic)
> + return -ENOMEM;
> +
> + haptic->dev = &pdev->dev;
> + haptic->enabled = false;
> + haptic->suspend_state = false;
> + mutex_init(&haptic->mutex);
> + INIT_WORK(&haptic->work, regulator_haptic_work);
> +
> + if (!data) {
> + if (pdev->dev.of_node) {
I'd rather we moved check for presence of of_node into
regulator_haptic_parse_dt().
> + error = regulator_haptic_parse_dt(haptic);
> + if (error) {
> + dev_err(&pdev->dev, "failed to parse device tree\n");
> + return error;
> + }
> + } else {
> + dev_err(&pdev->dev, "failed to get platdata\n");
> + return -EINVAL;
> + }
> + } else {
> + haptic->regulator = data->regulator;
What is the point of having regulator in platform data and doing
assignment here if you are going to clobber it a few lines down?
> + haptic->max_volt = data->max_volt;
> + haptic->min_volt = data->min_volt;
> + }
> +
> + haptic->regulator = devm_regulator_get_exclusive(&pdev->dev, "haptic");
> + if (IS_ERR(haptic->regulator)) {
> + dev_err(&pdev->dev, "failed to get regulator\n");
> + return PTR_ERR(haptic->regulator);
> + }
> +
> + input_dev = devm_input_allocate_device(&pdev->dev);
> + if (!input_dev)
> + return -ENOMEM;
Nit: extra space between return and error value.
> +
> + haptic->input_dev = input_dev;
> + haptic->input_dev->name = "regulator-haptic";
> + haptic->input_dev->dev.parent = &pdev->dev;
> + haptic->input_dev->close = regulator_haptic_close;
> + input_set_drvdata(haptic->input_dev, haptic);
> + input_set_capability(haptic->input_dev, EV_FF, FF_RUMBLE);
> +
> + error = input_ff_create_memless(input_dev, NULL,
> + regulator_haptic_play_effect);
> + if (error) {
> + dev_err(&pdev->dev, "failed to create force-feedback\n");
> + return error;
> + }
> +
> + error = input_register_device(haptic->input_dev);
> + if (error) {
> + dev_err(&pdev->dev, "failed to register input device\n");
> + return error;
> + }
> +
> + platform_set_drvdata(pdev, haptic);
> +
> + return 0;
> +}
> +
> +static int __maybe_unused regulator_haptic_suspend(struct device *dev)
> +{
> + struct platform_device *pdev = to_platform_device(dev);
> + struct regulator_haptic *haptic = platform_get_drvdata(pdev);
> +
> + mutex_lock(&haptic->mutex);
> + if (haptic->enabled) {
> + regulator_haptic_enable(haptic, false);
> + haptic->suspend_state = true;
Why do we only set suspend_state if an effect was playing? I think we
should always indicate that the device is suspended so that we do not
try to start playing another effect - while it is true that normally
effects are played by request from userspace which should be frozen by
now, it is theoretically possible to trigger an effect from kernel as
well.
> + }
> + mutex_unlock(&haptic->mutex);
> +
> + return 0;
> +}
> +
> +static int __maybe_unused regulator_haptic_resume(struct device *dev)
> +{
> + struct platform_device *pdev = to_platform_device(dev);
> + struct regulator_haptic *haptic = platform_get_drvdata(pdev);
> +
> + if (haptic->suspend_state) {
I think you should be gating enabling regulator not on suspend_state but
rather non-zero magnitude. And also lock the mutex to make absolutely
sure you are not racing with work item.
> + regulator_haptic_enable(haptic, true);
> + haptic->suspend_state = false;
> + }
> +
> + return 0;
> +}
> +
> +static SIMPLE_DEV_PM_OPS(regulator_haptic_pm_ops,
> + regulator_haptic_suspend, regulator_haptic_resume);
> +
> +static struct of_device_id regulator_haptic_dt_match[] = {
> + { .compatible = "regulator-haptic" },
> + { /* sentinel */ },
> +};
> +
> +static struct platform_driver regulator_haptic_driver = {
> + .probe = regulator_haptic_probe,
> + .driver = {
> + .name = "regulator-haptic",
> + .of_match_table = regulator_haptic_dt_match,
> + .pm = ®ulator_haptic_pm_ops,
> + },
> +};
> +module_platform_driver(regulator_haptic_driver);
> +
> +MODULE_AUTHOR("Jaewon Kim <jaewon02.kim@samsung.com>");
> +MODULE_AUTHOR("Hyunhee Kim <hyunhee.kim@samsung.com>");
> +MODULE_DESCRIPTION("Regulator haptic driver");
> +MODULE_LICENSE("GPL");
> diff --git a/include/linux/input/regulator-haptic.h b/include/linux/input/regulator-haptic.h
> new file mode 100644
> index 0000000..05ae038
> --- /dev/null
> +++ b/include/linux/input/regulator-haptic.h
Hmm, move it to include/linux/platform-data/ maybe?
> @@ -0,0 +1,31 @@
> +/*
> + * Regulator Haptic Platform Data
> + *
> + * Copyright (c) 2014 Samsung Electronics Co., Ltd.
> + * Author: Jaewon Kim <jaewon02.kim@samsung.com>
> + * Author: Hyunhee Kim <hyunhee.kim@samsung.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#ifndef _REGULATOR_HAPTIC_H
> +#define _REGULATOR_HAPTIC_H
> +
> +/*
> + * struct regulator_haptic_data - Platform device data
> + *
> + * @regulator: Power supply to the haptic motor
> + * @max_volt: maximum voltage value supplied to the haptic motor.
> + * <The unit of the voltage is a micro>
> + * @min_volt: minimum voltage value supplied to the haptic motor.
> + * <The unit of the voltage is a micro>
> + */
> +struct regulator_haptic_data {
> + struct regulator *regulator;
> + unsigned int max_volt;
> + unsigned int min_volt;
> +};
> +
> +#endif /* _REGULATOR_HAPTIC_H */
> --
> 1.7.9.5
>
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCHv3 0/5] ARM:sunxi:ps2 Added support for A10/A20 ps2 controller.
From: Vishnu Patekar @ 2014-12-13 20:01 UTC (permalink / raw)
To: Hans de Goede
Cc: linux-input-u79uwXL29TY76Z2rM5mHXA,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, pawel.moll-5wv7dgnIgG8,
mark.rutland-5wv7dgnIgG8, ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg,
galak-sgV2jX0FEOL9JmXXK+q4OQ, linux-lFZ/pmaqli7XmaaqVzeoHQ,
grant.likely-QSEj5FYQhm4dnm+yROfE0A,
benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r,
msalter-H+wXaHxf7aLQT0dZR+AlfA, ralf-6z/3iImG2C8G8FEW9MqTrA,
jdelvare-l3A5Bk7waGM
In-Reply-To: <548C1E7D.1000005-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Hello Hans,
Please find my comments inlined.
On 12/13/14, Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> Hi VishnuPatekar,
>
> The patch mangling for this set seems to have gone a bit wrong I'm afraid
No, this time I've corrected it. Infact, last version of patch did not
used the status bit error macros.
> a lot of the patches have my fixup commit messages (which should have
> disappeared when squashing in the patches), please replace those by proper
> commit messages describing what the patch actually does.
Yes, [PATCHv3 3/5] uses fixup. I'll correct it.
>
> Also the adding of the commented nodes for the lime2 seems to be gone
> entirely
> from the set, instead now only a comment about the conflict with the hdmi
> pins is added, but it is above the i2c node instead of above a ps2 node.
>
Maxime's suggested that we should not add commented nodes specially
when its trivial to apply. And just note saying ps20 pins conflict
with HDMI.
Should I remove the this comment as well?
Or
Put this note in start of DTS file?
> Regards,
>
> Hans
>
>
> On 12-12-14 19:25, VishnuPatekar wrote:
>> v2 --> v3
>> 1. changed config to SERIO_SUN4I_PS2 from SERIO_SUNXI_PS2
>> 2. changed driver name to sun4i-ps2 from sunxi-ps2.
>> 3. changed the function names to sun4i_ps2_*.
>> 4. added locking in sun4i_ps2_open.
>> 5. kept compatible "sun4i-a10-ps2" for A10 and A20, as A10 is earlier
>> SOC.
>> 6. corrected the style errors.
>> 7. separated the dts patches.
>> 8. removed commented ps2 notes from lime2 dts.
>> 9. added note that ps2 pins confilt with hdmi.
>> 10. corrected the interrupt property for A10.
>> 11. moved dt-bindings to Documentation/devicetree/bindings/serio
>>
>> v1 --> v2:
>> 1. added default n depends on ARCH_SUNXI || COMPILE_TEST in Kconfig.
>> 2. handled errors and free resources on errors.
>> 3. used BIT(x), DIV_ROUND_UP macros.
>> 4. corrected style errors.
>> 5. added support for A10 also, A10 and A2 have same properties of PS2
>> controller.
>> 6. by default commented ps20 and ps21 nodes,as ps20 pins conflict with
>> HDMI.
>> 7. added compatible as allwinner,sun4i-a10-ps2.
>> 8. corrected the possible race condition.
>>
>>
>> VishnuPatekar (5):
>> sunxi:dts-bindings:input:ps2 bindings for A10/A20 ps2.
>> ARM:sunxi:drivers:input Add support for A10/A20 PS2
>> ARM: sunxi: dts: Add PS2 nodes to dtsi for A10 and A20
>> ARM: sunxi: dts: Add A10/A20 PS2 pin muxing options
>> ARM: sunxi: dts: Add note ps2 pins conflict with hdmi
>>
>> .../bindings/serio/allwinner,sun4i-ps2.txt | 23 ++
>> arch/arm/boot/dts/sun4i-a10.dtsi | 31 ++
>> arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts | 6 +-
>> arch/arm/boot/dts/sun7i-a20.dtsi | 32 ++
>> drivers/input/serio/Kconfig | 11 +
>> drivers/input/serio/Makefile | 1 +
>> drivers/input/serio/sun4i-ps2.c | 362
>> ++++++++++++++++++++
>> 7 files changed, 465 insertions(+), 1 deletion(-)
>> create mode 100644
>> Documentation/devicetree/bindings/serio/allwinner,sun4i-ps2.txt
>> create mode 100644 drivers/input/serio/sun4i-ps2.c
>>
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] Input:Optimize events_per_packet count calculation
From: Dmitry Torokhov @ 2014-12-13 20:02 UTC (permalink / raw)
To: anshul.g; +Cc: linux-input, aksgarg1989
In-Reply-To: <1418212123-4549-1-git-send-email-anshul.g@samsung.com>
On Wed, Dec 10, 2014 at 05:18:43PM +0530, anshul.g@samsung.com wrote:
> From: Anshul Garg <anshul.g@samsung.com>
>
> This patch avoids unnecessary operations while estimating events per
> packet for an input device when event type is not set.
>
> Signed-off-by: Anshul Garg <anshul.g@samsung.com>
Applied, thank you.
> ---
> drivers/input/input.c | 22 +++++++++++++---------
> 1 file changed, 13 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/input/input.c b/drivers/input/input.c
> index 29ca0bb..8172296 100644
> --- a/drivers/input/input.c
> +++ b/drivers/input/input.c
> @@ -1973,18 +1973,22 @@ static unsigned int input_estimate_events_per_packet(struct input_dev *dev)
>
> events = mt_slots + 1; /* count SYN_MT_REPORT and SYN_REPORT */
>
> - for (i = 0; i < ABS_CNT; i++) {
> - if (test_bit(i, dev->absbit)) {
> - if (input_is_mt_axis(i))
> - events += mt_slots;
> - else
> - events++;
> + if (test_bit(EV_ABS, dev->evbit)) {
> + for (i = 0; i < ABS_CNT; i++) {
> + if (test_bit(i, dev->absbit)) {
> + if (input_is_mt_axis(i))
> + events += mt_slots;
> + else
> + events++;
> + }
> }
> }
>
> - for (i = 0; i < REL_CNT; i++)
> - if (test_bit(i, dev->relbit))
> - events++;
> + if (test_bit(EV_REL, dev->evbit)) {
> + for (i = 0; i < REL_CNT; i++)
> + if (test_bit(i, dev->relbit))
> + events++;
> + }
>
> /* Make room for KEY and MSC events */
> events += 7;
> --
> 1.7.9.5
>
--
Dmitry
^ permalink raw reply
* Re: [systemd-devel] Supporting U2F over HID on Linux?
From: Jiri Kosina @ 2014-12-13 22:56 UTC (permalink / raw)
To: Andy Lutomirski
Cc: David Herrmann, Benjamin Tissoires, open list:HID CORE LAYER
In-Reply-To: <CALCETrWD6w5QQSvnt=jkyHPNiBskQFxj5+LZey66LxXfyK_GcQ@mail.gmail.com>
On Fri, 12 Dec 2014, Andy Lutomirski wrote:
> It's roughly ISO7816-3. For the uninitiated (and the ISO7816 standard
> is amazingly vague), that means that the application sends a short
> (<64kB) binary request to the device (with a type, two "parameters",
> and a payload), and the device answers with exactly one reply packet
> that has two bytes of status and a payload. These requests and
> replies are fragmented into multiple HID reports.
Sorry for taking one (or maybe even more) step back, but what makes this
thing even "HID device"?
Yes, it interacts with human beings, but are the operations it's doing
covered by HID specification (at least in a "does it have HID descriptor"
sense)? It's not really completely clear to me at this point.
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [systemd-devel] Supporting U2F over HID on Linux?
From: Andy Lutomirski @ 2014-12-13 23:28 UTC (permalink / raw)
To: Jiri Kosina; +Cc: David Herrmann, Benjamin Tissoires, open list:HID CORE LAYER
In-Reply-To: <alpine.LNX.2.00.1412132353500.9918@pobox.suse.cz>
On Sat, Dec 13, 2014 at 2:56 PM, Jiri Kosina <jkosina@suse.cz> wrote:
> On Fri, 12 Dec 2014, Andy Lutomirski wrote:
>
>> It's roughly ISO7816-3. For the uninitiated (and the ISO7816 standard
>> is amazingly vague), that means that the application sends a short
>> (<64kB) binary request to the device (with a type, two "parameters",
>> and a payload), and the device answers with exactly one reply packet
>> that has two bytes of status and a payload. These requests and
>> replies are fragmented into multiple HID reports.
>
> Sorry for taking one (or maybe even more) step back, but what makes this
> thing even "HID device"?
>
> Yes, it interacts with human beings, but are the operations it's doing
> covered by HID specification (at least in a "does it have HID descriptor"
> sense)? It's not really completely clear to me at this point.
It has a HID descriptor, it's recognized by the HID stack, it
understands SET_REPORT, and it generates async HID reports. Hidraw is
willing to talk to it and, in fact, Chromium talks to it using hidraw
(ugh).
It's also supposed to be *enumerated* by reading the HID descriptor.
There are multiple vendors of these things, and the USB descriptor
doesn't seem to have anything in it to identify the device.
I think that's the full extent to which it's a HID device.
--Andy
>
> Thanks,
>
> --
> Jiri Kosina
> SUSE Labs
--
Andy Lutomirski
AMA Capital Management, LLC
^ permalink raw reply
* Re: PROBLEM: [HP Stream Notebook - 11-d010nr] clickpad malfunctions after performing a hardware click
From: Amordea Whiteoak @ 2014-12-13 23:52 UTC (permalink / raw)
To: Benjamin Tissoires; +Cc: linux-input, Peter Hutterer, Andrew Duggan
In-Reply-To: <CALmnu0Yg1vd4FOD5vtW39cbbcsRYiPuiiMD0A+obLyrkvKO+jA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 44700 bytes --]
Hello gentlemen, I have returned.
After trying to figure out for a few days how to apply the patch and
not really getting anywhere, I eventually bothered Andrew who very
helpfully showed me the way (thank you again Andrew!).
The patch works very well. No mouse input lockups anymore when
depressing hardware mouse button. Left-click performs as it should.
However right-clicking does not. It performs exactly as if it were
also a left-click button. It is admittedly hard to tell how many
buttons should be on this clickpad since there's a trackpad covering
them up. But this was originally designed to be a Windows machine so
I'm sure there's at least a separate right-click button.
I am enclosing some new evemu-record, hid-recorder, and dmesg debug
data. Each of these recordings is me using a non-conductive pen to
click the left mouse button and then the right.
Please let me know if there is anything else I can provide. Thank you.
On Mon, Dec 8, 2014 at 2:33 PM, Amordea Whiteoak <amordea@gmail.com> wrote:
>> My guess would be:
>> try open the settings panel, go into mouse (or touchpad, or whatever
>> it is called), look for an option which should allow you to change
>> this setting. If there are none, complain to the Ubuntu team by
>> opening a new bug on their launchpad.
>
> Aye, I will be opening a new report on Launchpad it seems. Thank you
> for all your help!
>
>> I hope Andrew will be able to fix your touchpad soonish. Thanks for
>> the followup BTW Andrew.
>
> And yes, thank you Andrew!!
>
>
> On Mon, Dec 8, 2014 at 2:26 PM, Benjamin Tissoires
> <benjamin.tissoires@gmail.com> wrote:
>> On Mon, Dec 8, 2014 at 2:16 PM, Amordea Whiteoak <amordea@gmail.com> wrote:
>>> While I have the ears of the touchpad gods, there is one more tiny
>>> issue I'd like to report. This may be simply a configuration issue,
>>> but I would not know how to fix it.
>>>
>>> The window for double-tapping (tapping the touchpad twice to simulate
>>> a double-click) is remarkably brief. Let me be clear, double-tapping
>>> on the touchpad does work, however if you do not get the second tap
>>> within about a 200ms window after the first, it seems to fail to
>>> register as a double-click, counting it as two unrelated single
>>> clicks--this is an uncomfortably short window of opportunity. A
>>> temporary workaround seems to be triple-tapping which for whatever
>>> reason allow for a broader window (much closer to a full second) and
>>> registers as a double-tap, but that just seems to be a happy accident
>>> and is certainly not an expected feature. Is there any way to broaden
>>> that window?
>>
>> This is usually an Xorg configuration problem (definitively not a
>> kernel one). However, you are using ubuntu 14.10 and I don't know if
>> they decided to switch to MIR yet. If so, I have no clues on what is
>> driving the touchpad, so I won't be of any help.
>>
>> My guess would be:
>> try open the settings panel, go into mouse (or touchpad, or whatever
>> it is called), look for an option which should allow you to change
>> this setting. If there are none, complain to the Ubuntu team by
>> opening a new bug on their launchpad.
>>
>>>
>>> I did not have this problem on my previous laptop with Lubuntu
>>> installed (though it had 14.04 not 14.10--it's no longer operational
>>> after suffering an unfortunate accident so I can't do comparison
>>> testing with it any longer).
>>
>> ouch :/
>>
>>>
>>> I promise this is my last remaining issue with the touchpad. :)
>>
>> No problem. We prefer having responsive users who tries to solve their
>> problems than frustrated users :)
>>
>> I hope Andrew will be able to fix your touchpad soonish. Thanks for
>> the followup BTW Andrew.
>>
>> Cheers,
>> Benjamin
>>
>>>
>>> On Mon, Dec 8, 2014 at 1:39 PM, Amordea Whiteoak <amordea@gmail.com> wrote:
>>>> My Linux newbieness is showing. :)
>>>>
>>>> I attempted to edit and boot the grub configuration, but I don't think
>>>> I did it right. I went with the seemingly more sure-fire way to get
>>>> your data and followed the second set of instructions.
>>>>
>>>> Enclosed is all the dmesg output once I got that working.
>>>>
>>>> On Mon, Dec 8, 2014 at 12:59 PM, Benjamin Tissoires
>>>> <benjamin.tissoires@gmail.com> wrote:
>>>>> On Mon, Dec 8, 2014 at 12:14 PM, Amordea Whiteoak <amordea@gmail.com> wrote:
>>>>>> There may be a thing I am failing to understand about dmesg here, but
>>>>>> a grep through both dmesg and /var/log/dmesg yielded no hits on
>>>>>> "i2c_hid.debug=1". I did find plenty of hits on just "i2c_hid", which
>>>>>> yielded several repetitive lines of what appears to be various
>>>>>> modules. Please let me know if there is something I am failing to
>>>>>> understand here, but I could not find the requested phrase in my
>>>>>> dmesg.
>>>>>
>>>>> I meant that when you reboot the laptop, in grub, append
>>>>> "i2c_hid.debug=1" to the kernel command line.
>>>>>
>>>>> This should be seen in one of the first few lines of dmesg (the one
>>>>> starting by "[ 0.000000] Command line:
>>>>> BOOT_IMAGE=/boot/vmlinuz-3.18.0-031800rc7-generic "), and a lot of raw
>>>>> events should be dumped in the dmesg.
>>>>>
>>>>>>
>>>>>> I do have the hid-recorder output though, which I am attaching here.
>>>>>> This time I used a non-conductive pen to only generate clicks without
>>>>>> all the positioning data piling in on top. This is a recording of two
>>>>>> left clicks.
>>>>>>
>>>>>
>>>>> Ok, so at least, the device sends a sane behavior (one event per
>>>>> click/release, with one bit changed). Unfortunately, I think the
>>>>> problem lies in the configuration of your device by hid-rmi. So the
>>>>> dmesg output while i2c_hid.debug=1 is set should help to figure out
>>>>> the problem.
>>>>>
>>>>> If for whatever reasons you do not manage to get the parameter
>>>>> appended to your command line, the following commands should suffice
>>>>> (as root):
>>>>> #> rmmod hid-rmi
>>>>> #> echo 1 > /sys/module/i2c_hid/parameters/debug
>>>>> #> modprobe hid-rmi
>>>>>
>>>>> do a few events on the touchpad (with clicks)
>>>>>
>>>>> #> echo 0 > /sys/module/i2c_hid/parameters/debug
>>>>>
>>>>> and send out the dmesg.
>>>>>
>>>>> Cheers,
>>>>> Benjamin
>>>>>
>>>>>> If there is anything else I can provide, please let me know.
>>>>>>
>>>>>> Thank you for helping with this bug. :)
>>>>>>
>>>>>> On Mon, Dec 8, 2014 at 11:44 AM, Benjamin Tissoires
>>>>>> <benjamin.tissoires@gmail.com> wrote:
>>>>>>> Hi Amordea,
>>>>>>>
>>>>>>> On Mon, Dec 8, 2014 at 11:20 AM, Amordea Whiteoak <amordea@gmail.com> wrote:
>>>>>>>> My apologies if my bug report was inadequate. It is the first upstream
>>>>>>>> report I've ever filed, though I did attempt to give all the
>>>>>>>> information they requested to the best of my ability.
>>>>>>>
>>>>>>> Oh, no, I was not complaining about your way of reporting the bug. I
>>>>>>> know that it can be difficult for users to report _and_ provide all
>>>>>>> the necessary information unless you already know a little bit about
>>>>>>> the communities, how they work and what tool they use.
>>>>>>> My complain was more that the way it was triaged: try an upstream
>>>>>>> kernel; oh, does not work; send it upstream because it's a "poor
>>>>>>> driver implementation". Whereas here, there may be any part of the
>>>>>>> stack involved unless we look at the evemu-record (which is the output
>>>>>>> of the kernel BTW). And saying that the driver is badly designed
>>>>>>> really does not help...
>>>>>>> Last, the "meta bug" they have is either a problem in the kernel
>>>>>>> drivers they ship, or a not up to date Xorg stack. FWIW, I don't think
>>>>>>> we have this on Fedora.
>>>>>>>
>>>>>>> Anyway, thanks for the explanations that you give in the next
>>>>>>> paragraph, it gives a more comprehensive bug report :)
>>>>>>>
>>>>>>>>
>>>>>>>> If it helps: to be clear about the design of this clickpad, it is one
>>>>>>>> where the entire pad is touch-sensitive, even the area over the
>>>>>>>> hardware click buttons which are on the bottom. The entire pad is one
>>>>>>>> piece, so the pad itself shifts when you click a button. The
>>>>>>>> malfunction occurs whenever any of these buttons are clicked, but the
>>>>>>>> simulated clicks (tapping on the pad) behave adequately and do not
>>>>>>>> cause any mouse input lock-ups. The malfunction itself causes ALL
>>>>>>>> subsequent mouse clicks from any source (including a USB mouse) to
>>>>>>>> only act in the spot where the first hardware click from the clickpad
>>>>>>>> was performed and cannot be adjusted until the clickpad has been
>>>>>>>> disabled (xinput disable <id>). The hardware buttons on the clickpad
>>>>>>>> itself do not register as clicks at all, they only cause all mouse
>>>>>>>> input to malfunction as previously described.
>>>>>>>>
>>>>>>>> I am enclosing the requested evemu-record data. This is a recording of
>>>>>>>> my clicking the left hardware click button three times in rapid
>>>>>>>> succession, but failure generally occurs after the first click.
>>>>>>>
>>>>>>> Many thanks for the logs. So here, I can see that when you click on
>>>>>>> the touchpad, both BTN_LEFT and BTN_RIGHT are emitted, but they are
>>>>>>> never released :) I do not see either the 2 other clicks.
>>>>>>> So yes, here the driver is at fault and misses to release the clicks.
>>>>>>> This infers the cross-device problem in X BTW.
>>>>>>>
>>>>>>>>
>>>>>>>> A curious behavior I noticed in the process of getting this recording
>>>>>>>> is that on the first click, I received a pasted text line in my
>>>>>>>> terminal. I could not reproduce this behavior by doing an
>>>>>>>> enable/disable cycle on the trackpad, but to confirm I rebooted a few
>>>>>>>> times to test and sure enough, the very first click each boot triggers
>>>>>>>> a clipboard paste event.
>>>>>>>
>>>>>>> You must have the middle button emulation enabled in Xorg (hitting
>>>>>>> both left and right button will trigger a middle button). So when we
>>>>>>> will be able to fix this bug, the spurious middle click should
>>>>>>> disappear.
>>>>>>>
>>>>>>>>
>>>>>>>> If there is any more information I can provide, please let me know.
>>>>>>>
>>>>>>> Ideally, I'd like to punt this one to Andrew, but I think we would be
>>>>>>> grateful if you could also provide 2 more things:
>>>>>>> - the dmesg when "i2c_hid.debug=1" is appended to the kernel boot line
>>>>>>> (without the quotes)
>>>>>>> - the hid-recorder output when you trigger the bug
>>>>>>>
>>>>>>> hid-recorder should be installed from sources in Ubuntu I guess:
>>>>>>> http://bentiss.github.io/hid-replay-docs/
>>>>>>>
>>>>>>> The hid-recorder output might not be absolutely needed, so as long as
>>>>>>> we have the dmesg with i2c_hid.debug=1, we should be fine.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Benjamin
>>>>>>>
>>>>>>>>
>>>>>>>> Thank you!
>>>>>>>>
>>>>>>>> On Mon, Dec 8, 2014 at 10:01 AM, Benjamin Tissoires
>>>>>>>> <benjamin.tissoires@gmail.com> wrote:
>>>>>>>>> Hi Amordea,
>>>>>>>>>
>>>>>>>>> I must say, the bug triaging is worse and worse with ubuntu :(
>>>>>>>>>
>>>>>>>>> From the bug description, I can not tell if the problem lies in the
>>>>>>>>> kernel, or if it is the synaptics input driver or the xserver which is
>>>>>>>>> in fault. I would be tempted to say that the problem lies in the upper
>>>>>>>>> layers given the cross-devices problem.
>>>>>>>>>
>>>>>>>>> Anyway, to be able to understand the problem, we will need to get an
>>>>>>>>> evemu-record output of your device when you are reproducing the bug.
>>>>>>>>> You can find evemu in your distribution channels, or here:
>>>>>>>>> http://www.freedesktop.org/wiki/Evemu/
>>>>>>>>>
>>>>>>>>> Given that you have an hid-rmi/i2c device, I am adding Andrew in CC,
>>>>>>>>> and Peter for the upper layers if there is anything wrong there.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Benjamin
>>>>>>>>>
>>>>>>>>> On Sun, Dec 7, 2014 at 5:50 PM, Amordea Whiteoak <amordea@gmail.com> wrote:
>>>>>>>>>> Original Bug Report:
>>>>>>>>>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1398533
>>>>>>>>>>
>>>>>>>>>> Bug Description: After clicking once at the bottom of my clickpad on
>>>>>>>>>> either button, if I move my cursor elsewhere on the screen, and then
>>>>>>>>>> subsequently click again (with either clickpad or external mouse this
>>>>>>>>>> time) it registers a click at the location where my cursor icon was
>>>>>>>>>> originally. I can continue to move my cursor anywhere on the screen,
>>>>>>>>>> and it still registers the click in the original location.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> cat /proc/version
>>>>>>>>>> Linux version 3.18.0-031800rc7-generic (apw@gomeisa) (gcc version
>>>>>>>>>> 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #201411302035 SMP Mon Dec 1
>>>>>>>>>> 01:36:38 UTC 2014
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> lsb_release -rd
>>>>>>>>>> Description: Ubuntu 14.10
>>>>>>>>>> Release: 14.10
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> sh /usr/src/linux-headers-3.18.0-031800rc7/scripts/ver_linux
>>>>>>>>>> If some fields are empty or look unusual you may have an old version.
>>>>>>>>>> Compare to the current minimal requirements in Documentation/Changes.
>>>>>>>>>>
>>>>>>>>>> Linux woprjr 3.18.0-031800rc7-generic #201411302035 SMP Mon Dec 1
>>>>>>>>>> 01:36:38 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
>>>>>>>>>>
>>>>>>>>>> Gnu C
>>>>>>>>>> /usr/src/linux-headers-3.18.0-031800rc7/scripts/ver_linux:
>>>>>>>>>> /usr/src/linux-headers-3.18.0-031800rc7/scripts/ver_linux: 20:
>>>>>>>>>> /usr/src/linux-headers-3.18.0-031800rc7/scripts/ver_linux: ld: not
>>>>>>>>>> found
>>>>>>>>>> binutils
>>>>>>>>>> util-linux 2.25.1
>>>>>>>>>> mount debug
>>>>>>>>>> module-init-tools 18
>>>>>>>>>> e2fsprogs 1.42.10
>>>>>>>>>> PPP 2.4.5
>>>>>>>>>> Linux C Library 2.19
>>>>>>>>>> Dynamic linker (ldd) 2.19
>>>>>>>>>> Procps 3.3.9
>>>>>>>>>> Net-tools 1.60
>>>>>>>>>> Kbd 1.15.5
>>>>>>>>>> Sh-utils 8.23
>>>>>>>>>> wireless-tools 30
>>>>>>>>>> Modules Loaded snd_hda_codec_hdmi snd_hda_codec_realtek
>>>>>>>>>> snd_hda_codec_generic ctr ccm joydev hp_wmi hid_rmi sparse_keymap
>>>>>>>>>> rfcomm bnep arc4 rtl8723be btcoexist rtl8723_common intel_rapl
>>>>>>>>>> uvcvideo rtl_pci intel_soc_dts_thermal intel_powerclamp
>>>>>>>>>> videobuf2_vmalloc videobuf2_memops coretemp rtlwifi videobuf2_core
>>>>>>>>>> v4l2_common videodev mac80211 media kvm cfg80211 btusb
>>>>>>>>>> crct10dif_pclmul crc32_pclmul bluetooth ghash_clmulni_intel serio_raw
>>>>>>>>>> cryptd wmi snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep
>>>>>>>>>> snd_seq_midi snd_seq_midi_event snd_rawmidi snd_soc_rt5640
>>>>>>>>>> snd_soc_rl6231 snd_soc_core snd_compress dw_dmac i915
>>>>>>>>>> snd_pcm_dmaengine dw_dmac_core snd_seq int3400_thermal int3403_thermal
>>>>>>>>>> acpi_thermal_rel nls_iso8859_1 snd_pcm i2c_hid video
>>>>>>>>>> intel_smartconnect drm_kms_helper hid drm rfkill_gpio snd_seq_device
>>>>>>>>>> i2c_designware_platform i2c_algo_bit snd_soc_sst_acpi 8250_dw
>>>>>>>>>> snd_timer i2c_designware_core hp_wireless shpchp spi_pxa2xx_platform
>>>>>>>>>> snd pwm_lpss_platform lpc_ich mac_hid mei_txe pwm_lpss iosf_mbi mei
>>>>>>>>>> soundcore parport_pc ppdev lp parport uas usb_storage mmc_block
>>>>>>>>>> sdhci_acpi sdhci
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> cat /proc/cpuinfo
>>>>>>>>>> processor : 0
>>>>>>>>>> vendor_id : GenuineIntel
>>>>>>>>>> cpu family : 6
>>>>>>>>>> model : 55
>>>>>>>>>> model name : Intel(R) Celeron(R) CPU N2840 @ 2.16GHz
>>>>>>>>>> stepping : 8
>>>>>>>>>> microcode : 0x829
>>>>>>>>>> cpu MHz : 499.741
>>>>>>>>>> cache size : 1024 KB
>>>>>>>>>> physical id : 0
>>>>>>>>>> siblings : 2
>>>>>>>>>> core id : 0
>>>>>>>>>> cpu cores : 2
>>>>>>>>>> apicid : 0
>>>>>>>>>> initial apicid : 0
>>>>>>>>>> fpu : yes
>>>>>>>>>> fpu_exception : yes
>>>>>>>>>> cpuid level : 11
>>>>>>>>>> wp : yes
>>>>>>>>>> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
>>>>>>>>>> pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
>>>>>>>>>> rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology
>>>>>>>>>> nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2
>>>>>>>>>> ssse3 cx16 xtpr pdcm sse4_1 sse4_2 movbe popcnt tsc_deadline_timer
>>>>>>>>>> rdrand lahf_lm 3dnowprefetch ida arat epb dtherm tpr_shadow vnmi
>>>>>>>>>> flexpriority ept vpid tsc_adjust smep erms
>>>>>>>>>> bugs :
>>>>>>>>>> bogomips : 4326.40
>>>>>>>>>> clflush size : 64
>>>>>>>>>> cache_alignment : 64
>>>>>>>>>> address sizes : 36 bits physical, 48 bits virtual
>>>>>>>>>> power management:
>>>>>>>>>>
>>>>>>>>>> processor : 1
>>>>>>>>>> vendor_id : GenuineIntel
>>>>>>>>>> cpu family : 6
>>>>>>>>>> model : 55
>>>>>>>>>> model name : Intel(R) Celeron(R) CPU N2840 @ 2.16GHz
>>>>>>>>>> stepping : 8
>>>>>>>>>> microcode : 0x829
>>>>>>>>>> cpu MHz : 499.741
>>>>>>>>>> cache size : 1024 KB
>>>>>>>>>> physical id : 0
>>>>>>>>>> siblings : 2
>>>>>>>>>> core id : 1
>>>>>>>>>> cpu cores : 2
>>>>>>>>>> apicid : 2
>>>>>>>>>> initial apicid : 2
>>>>>>>>>> fpu : yes
>>>>>>>>>> fpu_exception : yes
>>>>>>>>>> cpuid level : 11
>>>>>>>>>> wp : yes
>>>>>>>>>> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
>>>>>>>>>> pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
>>>>>>>>>> rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology
>>>>>>>>>> nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2
>>>>>>>>>> ssse3 cx16 xtpr pdcm sse4_1 sse4_2 movbe popcnt tsc_deadline_timer
>>>>>>>>>> rdrand lahf_lm 3dnowprefetch ida arat epb dtherm tpr_shadow vnmi
>>>>>>>>>> flexpriority ept vpid tsc_adjust smep erms
>>>>>>>>>> bugs :
>>>>>>>>>> bogomips : 4326.40
>>>>>>>>>> clflush size : 64
>>>>>>>>>> cache_alignment : 64
>>>>>>>>>> address sizes : 36 bits physical, 48 bits virtual
>>>>>>>>>> power management:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> cat /proc/modules
>>>>>>>>>> snd_hda_codec_hdmi 52670 1 - Live 0x0000000000000000
>>>>>>>>>> snd_hda_codec_realtek 80420 1 - Live 0x0000000000000000
>>>>>>>>>> snd_hda_codec_generic 69995 1 snd_hda_codec_realtek, Live 0x0000000000000000
>>>>>>>>>> ctr 13193 1 - Live 0x0000000000000000
>>>>>>>>>> ccm 17856 1 - Live 0x0000000000000000
>>>>>>>>>> joydev 17587 0 - Live 0x0000000000000000
>>>>>>>>>> hp_wmi 14017 0 - Live 0x0000000000000000
>>>>>>>>>> hid_rmi 18060 0 - Live 0x0000000000000000
>>>>>>>>>> sparse_keymap 13890 1 hp_wmi, Live 0x0000000000000000
>>>>>>>>>> rfcomm 75066 8 - Live 0x0000000000000000
>>>>>>>>>> bnep 23980 2 - Live 0x0000000000000000
>>>>>>>>>> arc4 12573 2 - Live 0x0000000000000000
>>>>>>>>>> rtl8723be 96097 0 - Live 0x0000000000000000
>>>>>>>>>> btcoexist 51822 1 rtl8723be, Live 0x0000000000000000
>>>>>>>>>> rtl8723_common 23662 1 rtl8723be, Live 0x0000000000000000
>>>>>>>>>> intel_rapl 19196 0 - Live 0x0000000000000000
>>>>>>>>>> uvcvideo 86723 0 - Live 0x0000000000000000
>>>>>>>>>> rtl_pci 27417 1 rtl8723be, Live 0x0000000000000000
>>>>>>>>>> intel_soc_dts_thermal 13523 0 - Live 0x0000000000000000
>>>>>>>>>> intel_powerclamp 19099 0 - Live 0x0000000000000000
>>>>>>>>>> videobuf2_vmalloc 13216 1 uvcvideo, Live 0x0000000000000000
>>>>>>>>>> videobuf2_memops 13362 1 videobuf2_vmalloc, Live 0x0000000000000000
>>>>>>>>>> coretemp 13638 0 - Live 0x0000000000000000
>>>>>>>>>> rtlwifi 74744 2 rtl8723be,rtl_pci, Live 0x0000000000000000
>>>>>>>>>> videobuf2_core 51547 1 uvcvideo, Live 0x0000000000000000
>>>>>>>>>> v4l2_common 15715 1 videobuf2_core, Live 0x0000000000000000
>>>>>>>>>> videodev 163831 3 uvcvideo,videobuf2_core,v4l2_common, Live 0x0000000000000000
>>>>>>>>>> mac80211 697159 3 rtl8723be,rtl_pci,rtlwifi, Live 0x0000000000000000
>>>>>>>>>> media 22008 2 uvcvideo,videodev, Live 0x0000000000000000
>>>>>>>>>> kvm 475237 0 - Live 0x0000000000000000
>>>>>>>>>> cfg80211 520257 2 rtlwifi,mac80211, Live 0x0000000000000000
>>>>>>>>>> btusb 32691 0 - Live 0x0000000000000000
>>>>>>>>>> crct10dif_pclmul 14268 0 - Live 0x0000000000000000
>>>>>>>>>> crc32_pclmul 13180 0 - Live 0x0000000000000000
>>>>>>>>>> bluetooth 486890 22 rfcomm,bnep,btusb, Live 0x0000000000000000
>>>>>>>>>> ghash_clmulni_intel 13230 0 - Live 0x0000000000000000
>>>>>>>>>> serio_raw 13483 0 - Live 0x0000000000000000
>>>>>>>>>> cryptd 20531 1 ghash_clmulni_intel, Live 0x0000000000000000
>>>>>>>>>> wmi 19379 1 hp_wmi, Live 0x0000000000000000
>>>>>>>>>> snd_hda_intel 30824 1 - Live 0x0000000000000000
>>>>>>>>>> snd_hda_controller 32234 1 snd_hda_intel, Live 0x0000000000000000
>>>>>>>>>> snd_hda_codec 144641 5
>>>>>>>>>> snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_codec_generic,snd_hda_intel,snd_hda_controller,
>>>>>>>>>> Live 0x0000000000000000
>>>>>>>>>> snd_hwdep 17709 1 snd_hda_codec, Live 0x0000000000000000
>>>>>>>>>> snd_seq_midi 13564 0 - Live 0x0000000000000000
>>>>>>>>>> snd_seq_midi_event 14899 1 snd_seq_midi, Live 0x0000000000000000
>>>>>>>>>> snd_rawmidi 31197 1 snd_seq_midi, Live 0x0000000000000000
>>>>>>>>>> snd_soc_rt5640 93325 0 - Live 0x0000000000000000
>>>>>>>>>> snd_soc_rl6231 13037 1 snd_soc_rt5640, Live 0x0000000000000000
>>>>>>>>>> snd_soc_core 207780 1 snd_soc_rt5640, Live 0x0000000000000000
>>>>>>>>>> snd_compress 19395 1 snd_soc_core, Live 0x0000000000000000
>>>>>>>>>> dw_dmac 12835 0 - Live 0x0000000000000000
>>>>>>>>>> i915 1031996 2 - Live 0x0000000000000000
>>>>>>>>>> snd_pcm_dmaengine 15229 1 snd_soc_core, Live 0x0000000000000000
>>>>>>>>>> dw_dmac_core 28558 1 dw_dmac, Live 0x0000000000000000
>>>>>>>>>> snd_seq 63540 2 snd_seq_midi,snd_seq_midi_event, Live 0x0000000000000000
>>>>>>>>>> int3400_thermal 13040 0 - Live 0x0000000000000000
>>>>>>>>>> int3403_thermal 13255 0 - Live 0x0000000000000000
>>>>>>>>>> acpi_thermal_rel 13807 1 int3400_thermal, Live 0x0000000000000000
>>>>>>>>>> nls_iso8859_1 12713 2 - Live 0x0000000000000000
>>>>>>>>>> snd_pcm 106273 7
>>>>>>>>>> snd_hda_codec_hdmi,snd_hda_intel,snd_hda_controller,snd_hda_codec,snd_soc_rt5640,snd_soc_core,snd_pcm_dmaengine,
>>>>>>>>>> Live 0x0000000000000000
>>>>>>>>>> i2c_hid 19065 0 - Live 0x0000000000000000
>>>>>>>>>> video 20649 1 i915, Live 0x0000000000000000
>>>>>>>>>> intel_smartconnect 12637 0 - Live 0x0000000000000000
>>>>>>>>>> drm_kms_helper 99802 1 i915, Live 0x0000000000000000
>>>>>>>>>> hid 110572 2 hid_rmi,i2c_hid, Live 0x0000000000000000
>>>>>>>>>> drm 323675 4 i915,drm_kms_helper, Live 0x0000000000000000
>>>>>>>>>> rfkill_gpio 12761 0 - Live 0x0000000000000000
>>>>>>>>>> snd_seq_device 14497 3 snd_seq_midi,snd_rawmidi,snd_seq, Live 0x0000000000000000
>>>>>>>>>> i2c_designware_platform 13025 0 - Live 0x0000000000000000
>>>>>>>>>> i2c_algo_bit 13564 1 i915, Live 0x0000000000000000
>>>>>>>>>> snd_soc_sst_acpi 13007 0 - Live 0x0000000000000000
>>>>>>>>>> 8250_dw 13474 0 - Live 0x0000000000000000
>>>>>>>>>> snd_timer 30118 2 snd_seq,snd_pcm, Live 0x0000000000000000
>>>>>>>>>> i2c_designware_core 14990 1 i2c_designware_platform, Live 0x0000000000000000
>>>>>>>>>> hp_wireless 12637 0 - Live 0x0000000000000000
>>>>>>>>>> shpchp 37216 0 - Live 0x0000000000000000
>>>>>>>>>> spi_pxa2xx_platform 23256 0 - Live 0x0000000000000000
>>>>>>>>>> snd 84025 15 snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_codec_generic,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_rawmidi,snd_soc_core,snd_compress,snd_seq,snd_pcm,snd_seq_device,snd_timer,
>>>>>>>>>> Live 0x0000000000000000
>>>>>>>>>> pwm_lpss_platform 12703 0 - Live 0x0000000000000000
>>>>>>>>>> lpc_ich 21176 0 - Live 0x0000000000000000
>>>>>>>>>> mac_hid 13275 0 - Live 0x0000000000000000
>>>>>>>>>> mei_txe 19808 0 - Live 0x0000000000000000
>>>>>>>>>> pwm_lpss 13281 1 pwm_lpss_platform, Live 0x0000000000000000
>>>>>>>>>> iosf_mbi 13865 1 intel_soc_dts_thermal, Live 0x0000000000000000
>>>>>>>>>> mei 88473 1 mei_txe, Live 0x0000000000000000
>>>>>>>>>> soundcore 15091 2 snd_hda_codec,snd, Live 0x0000000000000000
>>>>>>>>>> parport_pc 32909 0 - Live 0x0000000000000000
>>>>>>>>>> ppdev 17711 0 - Live 0x0000000000000000
>>>>>>>>>> lp 17799 0 - Live 0x0000000000000000
>>>>>>>>>> parport 42481 3 parport_pc,ppdev,lp, Live 0x0000000000000000
>>>>>>>>>> uas 22673 0 - Live 0x0000000000000000
>>>>>>>>>> usb_storage 67010 2 uas, Live 0x0000000000000000
>>>>>>>>>> mmc_block 36596 4 - Live 0x0000000000000000
>>>>>>>>>> sdhci_acpi 13502 0 - Live 0x0000000000000000
>>>>>>>>>> sdhci 43929 1 sdhci_acpi, Live 0x0000000000000000
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> /proc/ioports
>>>>>>>>>> 0000-006f : PCI Bus 0000:00
>>>>>>>>>> 0000-001f : dma1
>>>>>>>>>> 0020-0021 : pic1
>>>>>>>>>> 0040-0043 : timer0
>>>>>>>>>> 0050-0053 : timer1
>>>>>>>>>> 0060-0060 : keyboard
>>>>>>>>>> 0062-0062 : PNP0C09:00
>>>>>>>>>> 0062-0062 : EC data
>>>>>>>>>> 0064-0064 : keyboard
>>>>>>>>>> 0066-0066 : PNP0C09:00
>>>>>>>>>> 0066-0066 : EC cmd
>>>>>>>>>> 0070-0077 : rtc0
>>>>>>>>>> 0078-0cf7 : PCI Bus 0000:00
>>>>>>>>>> 0080-008f : dma page reg
>>>>>>>>>> 00a0-00a1 : pic2
>>>>>>>>>> 00c0-00df : dma2
>>>>>>>>>> 00f0-00ff : fpu
>>>>>>>>>> 03f8-03ff : serial
>>>>>>>>>> 0400-047f : pnp 00:01
>>>>>>>>>> 0400-0403 : ACPI PM1a_EVT_BLK
>>>>>>>>>> 0404-0405 : ACPI PM1a_CNT_BLK
>>>>>>>>>> 0408-040b : ACPI PM_TMR
>>>>>>>>>> 0420-042f : ACPI GPE0_BLK
>>>>>>>>>> 0430-0433 : iTCO_wdt
>>>>>>>>>> 0450-0450 : ACPI PM2_CNT_BLK
>>>>>>>>>> 0460-047f : iTCO_wdt
>>>>>>>>>> 0500-05fe : pnp 00:01
>>>>>>>>>> 0600-061f : pnp 00:01
>>>>>>>>>> 0680-069f : pnp 00:01
>>>>>>>>>> 0cf8-0cff : PCI conf1
>>>>>>>>>> 0d00-ffff : PCI Bus 0000:00
>>>>>>>>>> 1000-1fff : PCI Bus 0000:01
>>>>>>>>>> 1000-10ff : 0000:01:00.0
>>>>>>>>>> 1000-10ff : rtl_pci
>>>>>>>>>> 2000-201f : 0000:00:1f.3
>>>>>>>>>> 2050-2057 : 0000:00:02.0
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> cat /proc/iomem
>>>>>>>>>> 00000000-00000fff : reserved
>>>>>>>>>> 00001000-0006efff : System RAM
>>>>>>>>>> 0006f000-0006ffff : ACPI Non-volatile Storage
>>>>>>>>>> 00070000-00084fff : System RAM
>>>>>>>>>> 00085000-00086fff : reserved
>>>>>>>>>> 00087000-00087fff : System RAM
>>>>>>>>>> 00088000-0009ffff : reserved
>>>>>>>>>> 000a0000-000bffff : PCI Bus 0000:00
>>>>>>>>>> 000c0000-000dffff : PCI Bus 0000:00
>>>>>>>>>> 000e0000-000fffff : PCI Bus 0000:00
>>>>>>>>>> 000f0000-000fffff : System ROM
>>>>>>>>>> 00100000-1effffff : System RAM
>>>>>>>>>> 02000000-027b8537 : Kernel code
>>>>>>>>>> 027b8538-02d2123f : Kernel data
>>>>>>>>>> 02e87000-02fcffff : Kernel bss
>>>>>>>>>> 1f000000-1f0fffff : reserved
>>>>>>>>>> 1f100000-1fffffff : System RAM
>>>>>>>>>> 20000000-200fffff : reserved
>>>>>>>>>> 20100000-75867fff : System RAM
>>>>>>>>>> 75868000-75892fff : reserved
>>>>>>>>>> 75893000-78892fff : System RAM
>>>>>>>>>> 78893000-78922fff : reserved
>>>>>>>>>> 78923000-791a3fff : reserved
>>>>>>>>>> 791a4000-792a2fff : ACPI Non-volatile Storage
>>>>>>>>>> 792a3000-792e2fff : ACPI Tables
>>>>>>>>>> 792e3000-79ffffff : System RAM
>>>>>>>>>> 7a000000-7affffff : RAM buffer
>>>>>>>>>> 7b000000-7effffff : reserved
>>>>>>>>>> 7b000000-7effffff : Graphics Stolen Memory
>>>>>>>>>> 80000000-907ffffe : PCI Bus 0000:00
>>>>>>>>>> 80000000-8fffffff : 0000:00:02.0
>>>>>>>>>> 90000000-903fffff : 0000:00:02.0
>>>>>>>>>> 90400000-904fffff : PCI Bus 0000:01
>>>>>>>>>> 90400000-90403fff : 0000:01:00.0
>>>>>>>>>> 90400000-90403fff : rtl_pci
>>>>>>>>>> 90500000-905fffff : 0000:00:1a.0
>>>>>>>>>> 90500000-905fffff : mei_txe
>>>>>>>>>> 90600000-906fffff : 0000:00:1a.0
>>>>>>>>>> 90600000-906fffff : mei_txe
>>>>>>>>>> 90700000-9070ffff : 0000:00:14.0
>>>>>>>>>> 90700000-9070ffff : xhci-hcd
>>>>>>>>>> 90710000-90713fff : 0000:00:1b.0
>>>>>>>>>> 90710000-90713fff : ICH HD audio
>>>>>>>>>> 90718000-9071801f : 0000:00:1f.3
>>>>>>>>>> 90800000-90800fff : 80860F14:01
>>>>>>>>>> 90800000-90800fff : 80860F14:01
>>>>>>>>>> 90803000-90803fff : 80860F41:00
>>>>>>>>>> 90803000-90803fff : 80860F41:00
>>>>>>>>>> 90804000-90807fff : INTL9C60:01
>>>>>>>>>> 90804000-90807fff : INTL9C60:01
>>>>>>>>>> 90c00000-90ffffff : PCI Bus 0000:00
>>>>>>>>>> e0000000-e3ffffff : PCI MMCONFIG 0000 [bus 00-3f]
>>>>>>>>>> e00000d0-e00000db : INT33BD:00
>>>>>>>>>> e00f8000-e00f8fff : reserved
>>>>>>>>>> fec00000-fec003ff : IOAPIC 0
>>>>>>>>>> fed00000-fed003ff : HPET 0
>>>>>>>>>> fed00000-fed003ff : PNP0103:00
>>>>>>>>>> fed01000-fed01fff : reserved
>>>>>>>>>> fed01000-fed01fff : pnp 00:03
>>>>>>>>>> fed03000-fed03fff : pnp 00:03
>>>>>>>>>> fed03008-fed0300c : iTCO_wdt
>>>>>>>>>> fed04000-fed04fff : pnp 00:03
>>>>>>>>>> fed05000-fed057ff : INT3401:00
>>>>>>>>>> fed08000-fed08fff : pnp 00:03
>>>>>>>>>> fed0c000-fed0cfff : INT33FC:00
>>>>>>>>>> fed0c000-fed0cfff : INT33FC:00
>>>>>>>>>> fed0d000-fed0dfff : INT33FC:01
>>>>>>>>>> fed0d000-fed0dfff : INT33FC:01
>>>>>>>>>> fed0e000-fed0efff : INT33FC:02
>>>>>>>>>> fed0e000-fed0efff : INT33FC:02
>>>>>>>>>> fed1c000-fed1cfff : pnp 00:03
>>>>>>>>>> fed40000-fed44fff : pnp 00:01
>>>>>>>>>> fee00000-feefffff : pnp 00:03
>>>>>>>>>> fee00000-fee00fff : Local APIC
>>>>>>>>>> fef00000-feffffff : pnp 00:03
>>>>>>>>>> ff000000-ffffffff : INT0800:00
>>>>>>>>>> ffb80000-ffffffff : reserved
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> sudo lspci -vvv
>>>>>>>>>> 00:00.0 Host bridge: Intel Corporation Atom Processor Z36xxx/Z37xxx
>>>>>>>>>> Series SoC Transaction Register (rev 0e)
>>>>>>>>>> Subsystem: Hewlett-Packard Company Device 8023
>>>>>>>>>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
>>>>>>>>>> Stepping- SERR- FastB2B- DisINTx-
>>>>>>>>>> Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
>>>>>>>>>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>>>>>>>>>> Latency: 0
>>>>>>>>>> Kernel driver in use: iosf_mbi_pci
>>>>>>>>>>
>>>>>>>>>> 00:02.0 VGA compatible controller: Intel Corporation Atom Processor
>>>>>>>>>> Z36xxx/Z37xxx Series Graphics & Display (rev 0e) (prog-if 00 [VGA
>>>>>>>>>> controller])
>>>>>>>>>> Subsystem: Hewlett-Packard Company Device 8023
>>>>>>>>>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
>>>>>>>>>> Stepping- SERR- FastB2B- DisINTx+
>>>>>>>>>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
>>>>>>>>>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>>>>>>>>>> Latency: 0
>>>>>>>>>> Interrupt: pin A routed to IRQ 263
>>>>>>>>>> Region 0: Memory at 90000000 (32-bit, non-prefetchable) [size=4M]
>>>>>>>>>> Region 2: Memory at 80000000 (32-bit, prefetchable) [size=256M]
>>>>>>>>>> Region 4: I/O ports at 2050 [size=8]
>>>>>>>>>> Expansion ROM at <unassigned> [disabled]
>>>>>>>>>> Capabilities: [d0] Power Management version 2
>>>>>>>>>> Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
>>>>>>>>>> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>>>>>>>>>> Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
>>>>>>>>>> Address: fee0300c Data: 4162
>>>>>>>>>> Capabilities: [b0] Vendor Specific Information: Len=07 <?>
>>>>>>>>>> Kernel driver in use: i915
>>>>>>>>>>
>>>>>>>>>> 00:14.0 USB controller: Intel Corporation Atom Processor Z36xxx/Z37xxx
>>>>>>>>>> Series USB xHCI (rev 0e) (prog-if 30 [XHCI])
>>>>>>>>>> Subsystem: Hewlett-Packard Company Device 8023
>>>>>>>>>> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
>>>>>>>>>> Stepping- SERR- FastB2B- DisINTx+
>>>>>>>>>> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
>>>>>>>>>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>>>>>>>>>> Latency: 0
>>>>>>>>>> Interrupt: pin A routed to IRQ 261
>>>>>>>>>> Region 0: Memory at 90700000 (64-bit, non-prefetchable) [size=64K]
>>>>>>>>>> Capabilities: [70] Power Management version 2
>>>>>>>>>> Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
>>>>>>>>>> Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
>>>>>>>>>> Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+
>>>>>>>>>> Address: 00000000fee0300c Data: 41d1
>>>>>>>>>> Kernel driver in use: xhci_hcd
>>>>>>>>>>
>>>>>>>>>> 00:1a.0 Encryption controller: Intel Corporation Atom Processor
>>>>>>>>>> Z36xxx/Z37xxx Series Trusted Execution Engine (rev 0e)
>>>>>>>>>> Subsystem: Hewlett-Packard Company Device 8023
>>>>>>>>>> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
>>>>>>>>>> Stepping- SERR+ FastB2B- DisINTx+
>>>>>>>>>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
>>>>>>>>>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>>>>>>>>>> Latency: 0, Cache Line Size: 64 bytes
>>>>>>>>>> Interrupt: pin A routed to IRQ 262
>>>>>>>>>> Region 0: Memory at 90600000 (32-bit, non-prefetchable) [size=1M]
>>>>>>>>>> Region 1: Memory at 90500000 (32-bit, non-prefetchable) [size=1M]
>>>>>>>>>> Capabilities: [80] Power Management version 3
>>>>>>>>>> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold-)
>>>>>>>>>> Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
>>>>>>>>>> Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit-
>>>>>>>>>> Address: fee0300c Data: 4122
>>>>>>>>>> Kernel driver in use: mei_txe
>>>>>>>>>>
>>>>>>>>>> 00:1b.0 Audio device: Intel Corporation Atom Processor Z36xxx/Z37xxx
>>>>>>>>>> Series High Definition Audio Controller (rev 0e)
>>>>>>>>>> Subsystem: Hewlett-Packard Company Device 8023
>>>>>>>>>> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
>>>>>>>>>> Stepping- SERR- FastB2B- DisINTx+
>>>>>>>>>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
>>>>>>>>>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>>>>>>>>>> Latency: 0, Cache Line Size: 64 bytes
>>>>>>>>>> Interrupt: pin A routed to IRQ 264
>>>>>>>>>> Region 0: Memory at 90710000 (64-bit, non-prefetchable) [size=16K]
>>>>>>>>>> Capabilities: [50] Power Management version 2
>>>>>>>>>> Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
>>>>>>>>>> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>>>>>>>>>> Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
>>>>>>>>>> Address: 00000000fee0300c Data: 4182
>>>>>>>>>> Kernel driver in use: snd_hda_intel
>>>>>>>>>>
>>>>>>>>>> 00:1c.0 PCI bridge: Intel Corporation Device 0f48 (rev 0e) (prog-if 00
>>>>>>>>>> [Normal decode])
>>>>>>>>>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
>>>>>>>>>> Stepping- SERR- FastB2B- DisINTx-
>>>>>>>>>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
>>>>>>>>>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>>>>>>>>>> Latency: 0, Cache Line Size: 64 bytes
>>>>>>>>>> Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
>>>>>>>>>> I/O behind bridge: 00001000-00001fff
>>>>>>>>>> Memory behind bridge: 90400000-904fffff
>>>>>>>>>> Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
>>>>>>>>>> Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort-
>>>>>>>>>> <TAbort- <MAbort+ <SERR- <PERR-
>>>>>>>>>> BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
>>>>>>>>>> PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
>>>>>>>>>> Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00
>>>>>>>>>> DevCap: MaxPayload 128 bytes, PhantFunc 0
>>>>>>>>>> ExtTag- RBE+
>>>>>>>>>> DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
>>>>>>>>>> RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
>>>>>>>>>> MaxPayload 128 bytes, MaxReadReq 128 bytes
>>>>>>>>>> DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
>>>>>>>>>> LnkCap: Port #1, Speed 5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s
>>>>>>>>>> <512ns, L1 <4us
>>>>>>>>>> ClockPM- Surprise- LLActRep+ BwNot+
>>>>>>>>>> LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- CommClk+
>>>>>>>>>> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>>>>>>>>>> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+
>>>>>>>>>> BWMgmt+ ABWMgmt-
>>>>>>>>>> SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise-
>>>>>>>>>> Slot #0, PowerLimit 10.000W; Interlock- NoCompl+
>>>>>>>>>> SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
>>>>>>>>>> Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
>>>>>>>>>> SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
>>>>>>>>>> Changed: MRL- PresDet- LinkState+
>>>>>>>>>> RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
>>>>>>>>>> RootCap: CRSVisible-
>>>>>>>>>> RootSta: PME ReqID 0000, PMEStatus- PMEPending-
>>>>>>>>>> DevCap2: Completion Timeout: Range BC, TimeoutDis+, LTR-, OBFF Not
>>>>>>>>>> Supported ARIFwd-
>>>>>>>>>> DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF
>>>>>>>>>> Disabled ARIFwd-
>>>>>>>>>> LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
>>>>>>>>>> Transmit Margin: Normal Operating Range, EnterModifiedCompliance-
>>>>>>>>>> ComplianceSOS-
>>>>>>>>>> Compliance De-emphasis: -6dB
>>>>>>>>>> LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete-,
>>>>>>>>>> EqualizationPhase1-
>>>>>>>>>> EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
>>>>>>>>>> Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit-
>>>>>>>>>> Address: 00000000 Data: 0000
>>>>>>>>>> Capabilities: [90] Subsystem: Hewlett-Packard Company Device 8023
>>>>>>>>>> Capabilities: [a0] Power Management version 3
>>>>>>>>>> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
>>>>>>>>>> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>>>>>>>>>> Kernel driver in use: pcieport
>>>>>>>>>>
>>>>>>>>>> 00:1f.0 ISA bridge: Intel Corporation Atom Processor Z36xxx/Z37xxx
>>>>>>>>>> Series Power Control Unit (rev 0e)
>>>>>>>>>> Subsystem: Hewlett-Packard Company Device 8023
>>>>>>>>>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
>>>>>>>>>> Stepping- SERR+ FastB2B- DisINTx-
>>>>>>>>>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
>>>>>>>>>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>>>>>>>>>> Latency: 0
>>>>>>>>>> Capabilities: [e0] Vendor Specific Information: Len=0c <?>
>>>>>>>>>> Kernel driver in use: lpc_ich
>>>>>>>>>>
>>>>>>>>>> 00:1f.3 SMBus: Intel Corporation Device 0f12 (rev 0e)
>>>>>>>>>> Subsystem: Hewlett-Packard Company Device 8023
>>>>>>>>>> Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
>>>>>>>>>> Stepping- SERR- FastB2B- DisINTx-
>>>>>>>>>> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
>>>>>>>>>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>>>>>>>>>> Interrupt: pin B routed to IRQ 255
>>>>>>>>>> Region 0: Memory at 90718000 (32-bit, non-prefetchable) [size=32]
>>>>>>>>>> Region 4: I/O ports at 2000 [size=32]
>>>>>>>>>> Capabilities: [50] Power Management version 3
>>>>>>>>>> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
>>>>>>>>>> Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
>>>>>>>>>>
>>>>>>>>>> 01:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8723BE
>>>>>>>>>> PCIe Wireless Network Adapter
>>>>>>>>>> Subsystem: Hewlett-Packard Company Device 2231
>>>>>>>>>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
>>>>>>>>>> Stepping- SERR- FastB2B- DisINTx-
>>>>>>>>>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
>>>>>>>>>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>>>>>>>>>> Latency: 0, Cache Line Size: 64 bytes
>>>>>>>>>> Interrupt: pin A routed to IRQ 16
>>>>>>>>>> Region 0: I/O ports at 1000 [size=256]
>>>>>>>>>> Region 2: Memory at 90400000 (64-bit, non-prefetchable) [size=16K]
>>>>>>>>>> Capabilities: [40] Power Management version 3
>>>>>>>>>> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
>>>>>>>>>> Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
>>>>>>>>>> Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
>>>>>>>>>> Address: 0000000000000000 Data: 0000
>>>>>>>>>> Capabilities: [70] Express (v2) Endpoint, MSI 00
>>>>>>>>>> DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <4us, L1 <64us
>>>>>>>>>> ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
>>>>>>>>>> DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
>>>>>>>>>> RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
>>>>>>>>>> MaxPayload 128 bytes, MaxReadReq 512 bytes
>>>>>>>>>> DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
>>>>>>>>>> LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency
>>>>>>>>>> L0s <512ns, L1 <64us
>>>>>>>>>> ClockPM+ Surprise- LLActRep- BwNot-
>>>>>>>>>> LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- CommClk+
>>>>>>>>>> ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
>>>>>>>>>> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive-
>>>>>>>>>> BWMgmt- ABWMgmt-
>>>>>>>>>> DevCap2: Completion Timeout: Not Supported, TimeoutDis+, LTR+, OBFF
>>>>>>>>>> Via message/WAKE#
>>>>>>>>>> DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis+, LTR+, OBFF Disabled
>>>>>>>>>> LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
>>>>>>>>>> Transmit Margin: Normal Operating Range, EnterModifiedCompliance-
>>>>>>>>>> ComplianceSOS-
>>>>>>>>>> Compliance De-emphasis: -6dB
>>>>>>>>>> LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-,
>>>>>>>>>> EqualizationPhase1-
>>>>>>>>>> EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
>>>>>>>>>> Capabilities: [100 v2] Advanced Error Reporting
>>>>>>>>>> UESta: DLP- SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
>>>>>>>>>> MalfTLP- ECRC- UnsupReq- ACSViol-
>>>>>>>>>> UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
>>>>>>>>>> MalfTLP- ECRC- UnsupReq- ACSViol-
>>>>>>>>>> UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+
>>>>>>>>>> MalfTLP+ ECRC- UnsupReq- ACSViol-
>>>>>>>>>> CESta: RxErr+ BadTLP- BadDLLP+ Rollover- Timeout- NonFatalErr-
>>>>>>>>>> CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
>>>>>>>>>> AERCap: First Error Pointer: 0d, GenCap+ CGenEn- ChkCap+ ChkEn-
>>>>>>>>>> Capabilities: [140 v1] Device Serial Number 00-23-b7-fe-ff-4c-e0-00
>>>>>>>>>> Capabilities: [150 v1] Latency Tolerance Reporting
>>>>>>>>>> Max snoop latency: 71680ns
>>>>>>>>>> Max no snoop latency: 71680ns
>>>>>>>>>> Capabilities: [158 v1] L1 PM Substates
>>>>>>>>>> L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+
>>>>>>>>>> PortCommonModeRestoreTime=150us PortTPowerOnTime=150us
>>>>>>>>>> Kernel driver in use: rtl8723be
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> cat /proc/scsi/scsi
>>>>>>>>>> Attached devices:
>>>>>>>>>> Host: scsi0 Channel: 00 Id: 00 Lun: 00
>>>>>>>>>> Vendor: Generic- Model: SD/MMC/MS PRO Rev: 1.00
>>>>>>>>>> Type: Direct-Access ANSI SCSI revision: 04
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ls /proc
>>>>>>>>>> 1 12 14 1667 1745 18 1963 2345 292 35 470 55
>>>>>>>>>> 7201 asound execdomains kmsg pagetypeinfo sysvipc
>>>>>>>>>> 10 1218 1410 1685 1761 1804 2 2388 296 3573 471 554
>>>>>>>>>> 728 buddyinfo fb kpagecount partitions thread-self
>>>>>>>>>> 1020 125 142 1687 1764 1805 20 24 3 359 473 56
>>>>>>>>>> 755 bus filesystems kpageflags sched_debug timer_list
>>>>>>>>>> 1025 126 1420 1690 1767 1818 21 25 30 3623 474 57
>>>>>>>>>> 76 cgroups fs loadavg schedstat timer_stats
>>>>>>>>>> 1032 127 1423 17 1769 1828 2169 2528 31 378 485 585
>>>>>>>>>> 77 cmdline interrupts locks scsi tty
>>>>>>>>>> 1033 128 143 1701 1771 1853 2187 254 3181 3822 5 606
>>>>>>>>>> 7886 consoles iomem mdstat self uptime
>>>>>>>>>> 1038 129 1444 1710 1772 1876 2197 26 33 39 509 654
>>>>>>>>>> 8 cpuinfo ioports meminfo slabinfo version
>>>>>>>>>> 1042 13 1485 1718 1781 1883 2198 2670 3309 3932 516 655
>>>>>>>>>> 8743 crypto irq misc softirqs vmallocinfo
>>>>>>>>>> 1069 130 15 1722 1787 1893 22 2672 34 40 53 695
>>>>>>>>>> 9 devices kallsyms modules stat vmstat
>>>>>>>>>> 1070 131 1568 1725 1789 1896 2202 27 3419 41 539 7
>>>>>>>>>> 9040 diskstats kcore mounts swaps zoneinfo
>>>>>>>>>> 11 132 1645 1727 1792 19 2248 28 3433 468 542 709
>>>>>>>>>> 9056 dma keys mtrr sys
>>>>>>>>>> 1144 1331 1655 1732 1796 1905 23 29 3437 469 5421 715
>>>>>>>>>> acpi driver key-users net sysrq-trigger
>>>>>>>>>> --
>>>>>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-input" in
>>>>>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: dmesg.txt --]
[-- Type: text/plain, Size: 10908 bytes --]
[ 372.016493] i2c_hid i2c-SYN1EDE:00: i2c_hid_set_power
[ 372.016521] i2c_hid i2c-SYN1EDE:00: __i2c_hid_command: cmd=22 00 00 08
[ 372.032323] i2c_hid i2c-SYN1EDE:00: i2c_hid_set_or_send_report
[ 372.032353] i2c_hid i2c-SYN1EDE:00: __i2c_hid_command: cmd=22 00 3f 03 0f 23 00 04 00 0f 01
[ 372.033473] i2c_hid i2c-SYN1EDE:00: i2c_hid_set_or_send_report
[ 372.033498] i2c_hid i2c-SYN1EDE:00: __i2c_hid_command: cmd=25 00 17 00 09 01 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 372.034742] hid-rmi 0018:06CB:7442.0001: Scanning PDT...
[ 372.034764] i2c_hid i2c-SYN1EDE:00: i2c_hid_set_or_send_report
[ 372.034782] i2c_hid i2c-SYN1EDE:00: __i2c_hid_command: cmd=25 00 17 00 0a 00 e9 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 372.037775] i2c_hid i2c-SYN1EDE:00: input: 2a 00 0b 06 74 00 3d 00 01 34 a8 0f da 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 372.037855] hid-rmi 0018:06CB:7442.0001: Found F34 on page 0x00
[ 372.037875] i2c_hid i2c-SYN1EDE:00: i2c_hid_set_or_send_report
[ 372.037893] i2c_hid i2c-SYN1EDE:00: __i2c_hid_command: cmd=25 00 17 00 0a 00 e3 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 372.040744] i2c_hid i2c-SYN1EDE:00: input: 2a 00 0b 06 7d 72 41 13 01 01 a8 0f da 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 372.040814] hid-rmi 0018:06CB:7442.0001: Found F01 on page 0x00
[ 372.040836] i2c_hid i2c-SYN1EDE:00: i2c_hid_set_or_send_report
[ 372.040854] i2c_hid i2c-SYN1EDE:00: __i2c_hid_command: cmd=25 00 17 00 0a 00 dd 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 372.043701] i2c_hid i2c-SYN1EDE:00: input: 2a 00 0b 06 98 73 46 15 22 11 a8 0f da 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 372.043871] hid-rmi 0018:06CB:7442.0001: Found F11 on page 0x00
[ 372.043894] i2c_hid i2c-SYN1EDE:00: i2c_hid_set_or_send_report
[ 372.043912] i2c_hid i2c-SYN1EDE:00: __i2c_hid_command: cmd=25 00 17 00 0a 00 d7 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 372.046766] i2c_hid i2c-SYN1EDE:00: input: 2a 00 0b 06 00 00 00 00 00 00 a8 0f da 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 372.046831] i2c_hid i2c-SYN1EDE:00: i2c_hid_set_or_send_report
[ 372.046854] i2c_hid i2c-SYN1EDE:00: __i2c_hid_command: cmd=25 00 17 00 09 01 ff 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 372.048367] i2c_hid i2c-SYN1EDE:00: i2c_hid_set_or_send_report
[ 372.048393] i2c_hid i2c-SYN1EDE:00: __i2c_hid_command: cmd=25 00 17 00 0a 00 e9 01 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 372.051401] i2c_hid i2c-SYN1EDE:00: input: 2a 00 0b 06 6c 6b 0d 00 01 54 a8 0f da 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 372.051841] hid-rmi 0018:06CB:7442.0001: Found F54 on page 0x01
[ 372.051864] i2c_hid i2c-SYN1EDE:00: i2c_hid_set_or_send_report
[ 372.051883] i2c_hid i2c-SYN1EDE:00: __i2c_hid_command: cmd=25 00 17 00 0a 00 e3 01 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 372.054561] i2c_hid i2c-SYN1EDE:00: input: 2a 00 0b 06 00 00 00 00 00 00 a8 0f da 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 372.054631] i2c_hid i2c-SYN1EDE:00: i2c_hid_set_or_send_report
[ 372.054654] i2c_hid i2c-SYN1EDE:00: __i2c_hid_command: cmd=25 00 17 00 09 01 ff 01 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 372.056262] i2c_hid i2c-SYN1EDE:00: i2c_hid_set_or_send_report
[ 372.056286] i2c_hid i2c-SYN1EDE:00: __i2c_hid_command: cmd=25 00 17 00 0a 00 e9 02 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 372.059438] i2c_hid i2c-SYN1EDE:00: input: 2a 00 0b 06 0c 00 01 00 01 30 a8 0f da 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 372.060003] hid-rmi 0018:06CB:7442.0001: Found F30 on page 0x02
[ 372.060026] i2c_hid i2c-SYN1EDE:00: i2c_hid_set_or_send_report
[ 372.060044] i2c_hid i2c-SYN1EDE:00: __i2c_hid_command: cmd=25 00 17 00 0a 00 e3 02 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 372.062910] i2c_hid i2c-SYN1EDE:00: input: 2a 00 0b 06 00 00 00 00 00 00 a8 0f da 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 372.066148] i2c_hid i2c-SYN1EDE:00: i2c_hid_set_or_send_report
[ 372.066176] i2c_hid i2c-SYN1EDE:00: __i2c_hid_command: cmd=25 00 17 00 09 01 ff 02 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 372.069531] i2c_hid i2c-SYN1EDE:00: i2c_hid_set_or_send_report
[ 372.069559] i2c_hid i2c-SYN1EDE:00: __i2c_hid_command: cmd=25 00 17 00 0a 00 e9 03 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 372.076050] i2c_hid i2c-SYN1EDE:00: input: 2a 00 0b 06 00 00 00 00 00 00 a8 0f da 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 372.076129] hid-rmi 0018:06CB:7442.0001: rmi_scan_pdt: Done with PDT scan.
[ 372.076154] i2c_hid i2c-SYN1EDE:00: i2c_hid_set_or_send_report
[ 372.076173] i2c_hid i2c-SYN1EDE:00: __i2c_hid_command: cmd=25 00 17 00 09 01 ff 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 372.077424] i2c_hid i2c-SYN1EDE:00: i2c_hid_set_or_send_report
[ 372.077446] i2c_hid i2c-SYN1EDE:00: __i2c_hid_command: cmd=25 00 17 00 0a 00 98 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 372.080447] i2c_hid i2c-SYN1EDE:00: input: 2a 00 0b 01 f0 00 00 00 00 00 a8 0f da 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 372.080559] i2c_hid i2c-SYN1EDE:00: i2c_hid_set_or_send_report
[ 372.080583] i2c_hid i2c-SYN1EDE:00: __i2c_hid_command: cmd=25 00 17 00 0a 00 99 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 372.083458] i2c_hid i2c-SYN1EDE:00: input: 2a 00 0b 01 3c 00 00 00 00 00 a8 0f da 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 372.083987] i2c_hid i2c-SYN1EDE:00: i2c_hid_set_or_send_report
[ 372.084011] i2c_hid i2c-SYN1EDE:00: __i2c_hid_command: cmd=25 00 17 00 0a 00 a0 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 372.086879] i2c_hid i2c-SYN1EDE:00: input: 2a 00 0b 01 00 00 00 00 00 00 a8 0f da 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 372.086944] i2c_hid i2c-SYN1EDE:00: i2c_hid_set_or_send_report
[ 372.086967] i2c_hid i2c-SYN1EDE:00: __i2c_hid_command: cmd=25 00 17 00 0a 00 a2 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 372.089852] i2c_hid i2c-SYN1EDE:00: input: 2a 00 0b 01 20 00 00 00 00 00 a8 0f da 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 372.089919] i2c_hid i2c-SYN1EDE:00: i2c_hid_set_or_send_report
[ 372.089943] i2c_hid i2c-SYN1EDE:00: __i2c_hid_command: cmd=25 00 17 00 0a 00 a3 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 372.092783] i2c_hid i2c-SYN1EDE:00: input: 2a 00 0b 04 8e 03 03 02 00 00 a8 0f da 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 372.092855] hid-rmi 0018:06CB:7442.0001: rmi_populate_f11: size in mm: 91 x 52
[ 372.092877] i2c_hid i2c-SYN1EDE:00: i2c_hid_set_or_send_report
[ 372.092896] i2c_hid i2c-SYN1EDE:00: __i2c_hid_command: cmd=25 00 17 00 0a 00 b0 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 372.095673] i2c_hid i2c-SYN1EDE:00: input: 2a 00 0b 01 4c 03 03 02 00 00 a8 0f da 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 372.095897] i2c_hid i2c-SYN1EDE:00: i2c_hid_set_or_send_report
[ 372.095921] i2c_hid i2c-SYN1EDE:00: __i2c_hid_command: cmd=25 00 17 00 0a 00 b2 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 372.098804] i2c_hid i2c-SYN1EDE:00: input: 2a 00 0b 01 20 03 03 02 00 00 a8 0f da 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 372.098870] i2c_hid i2c-SYN1EDE:00: i2c_hid_set_or_send_report
[ 372.098893] i2c_hid i2c-SYN1EDE:00: __i2c_hid_command: cmd=25 00 17 00 0a 00 46 00 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 372.101857] i2c_hid i2c-SYN1EDE:00: input: 2a 00 0b 0a 38 00 19 19 00 10 a8 0f da 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 372.101926] i2c_hid i2c-SYN1EDE:00: i2c_hid_set_or_send_report
[ 372.101950] i2c_hid i2c-SYN1EDE:00: __i2c_hid_command: cmd=25 00 17 00 09 01 ff 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 372.103194] i2c_hid i2c-SYN1EDE:00: i2c_hid_set_or_send_report
[ 372.103216] i2c_hid i2c-SYN1EDE:00: __i2c_hid_command: cmd=25 00 17 00 0a 00 0c 02 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 372.106552] i2c_hid i2c-SYN1EDE:00: input: 2a 00 0b 02 28 08 19 19 00 10 a8 0f da 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 372.106621] i2c_hid i2c-SYN1EDE:00: i2c_hid_set_or_send_report
[ 372.106645] i2c_hid i2c-SYN1EDE:00: __i2c_hid_command: cmd=25 00 17 00 0a 00 02 02 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 372.109577] i2c_hid i2c-SYN1EDE:00: input: 2a 00 0b 02 00 84 19 19 00 10 a8 0f da 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 372.109694] i2c_hid i2c-SYN1EDE:00: i2c_hid_set_power
[ 372.109717] i2c_hid i2c-SYN1EDE:00: __i2c_hid_command: cmd=22 00 01 08
[ 372.110227] input: SYN1EDE:00 06CB:7442 as /devices/platform/80860F41:00/i2c-0/i2c-SYN1EDE:00/0018:06CB:7442.0001/input/input12
[ 372.111179] hid-rmi 0018:06CB:7442.0001: input,hidraw0: <UNKNOWN> HID v1.00 Mouse [SYN1EDE:00 06CB:7442] on
[ 372.153697] i2c_hid i2c-SYN1EDE:00: i2c_hid_set_power
[ 372.153713] i2c_hid i2c-SYN1EDE:00: __i2c_hid_command: cmd=22 00 00 08
[ 372.163886] i2c_hid i2c-SYN1EDE:00: i2c_hid_set_power
[ 372.163901] i2c_hid i2c-SYN1EDE:00: __i2c_hid_command: cmd=22 00 01 08
[ 372.168145] i2c_hid i2c-SYN1EDE:00: i2c_hid_set_power
[ 372.168158] i2c_hid i2c-SYN1EDE:00: __i2c_hid_command: cmd=22 00 00 08
[ 372.180151] i2c_hid i2c-SYN1EDE:00: i2c_hid_set_power
[ 372.180165] i2c_hid i2c-SYN1EDE:00: __i2c_hid_command: cmd=22 00 01 08
[ 372.185684] i2c_hid i2c-SYN1EDE:00: i2c_hid_set_power
[ 372.185698] i2c_hid i2c-SYN1EDE:00: __i2c_hid_command: cmd=22 00 00 08
[ 375.200158] i2c_hid i2c-SYN1EDE:00: input: 2a 00 0c 20 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 375.389908] i2c_hid i2c-SYN1EDE:00: input: 2a 00 0c 20 84 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 376.641340] i2c_hid i2c-SYN1EDE:00: input: 2a 00 0c 20 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 376.820625] i2c_hid i2c-SYN1EDE:00: input: 2a 00 0c 20 84 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[-- Attachment #3: clickpad.evemu --]
[-- Type: application/octet-stream, Size: 3991 bytes --]
# EVEMU 1.2
# Input device name: "SYN1EDE:00 06CB:7442"
# Input device ID: bus 0x18 vendor 0x6cb product 0x7442 version 0x100
# Supported events:
# Event type 0 (EV_SYN)
# Event code 0 (SYN_REPORT)
# Event code 1 (SYN_CONFIG)
# Event code 3 (SYN_MAX)
# Event type 1 (EV_KEY)
# Event code 272 (BTN_LEFT)
# Event code 273 (BTN_RIGHT)
# Event code 325 (BTN_TOOL_FINGER)
# Event code 328 (BTN_TOOL_QUINTTAP)
# Event code 330 (BTN_TOUCH)
# Event code 333 (BTN_TOOL_DOUBLETAP)
# Event code 334 (BTN_TOOL_TRIPLETAP)
# Event code 335 (BTN_TOOL_QUADTAP)
# Event type 3 (EV_ABS)
# Event code 0 (ABS_X)
# Value 1362
# Min 1
# Max 4008
# Fuzz 0
# Flat 0
# Resolution 44
# Event code 1 (ABS_Y)
# Value 825
# Min 1
# Max 2266
# Fuzz 0
# Flat 0
# Resolution 43
# Event code 24 (ABS_PRESSURE)
# Value 0
# Min 0
# Max 255
# Fuzz 0
# Flat 0
# Resolution 0
# Event code 47 (ABS_MT_SLOT)
# Value 0
# Min 0
# Max 4
# Fuzz 0
# Flat 0
# Resolution 0
# Event code 48 (ABS_MT_TOUCH_MAJOR)
# Value 0
# Min 0
# Max 15
# Fuzz 0
# Flat 0
# Resolution 0
# Event code 49 (ABS_MT_TOUCH_MINOR)
# Value 0
# Min 0
# Max 15
# Fuzz 0
# Flat 0
# Resolution 0
# Event code 52 (ABS_MT_ORIENTATION)
# Value 0
# Min 0
# Max 1
# Fuzz 0
# Flat 0
# Resolution 0
# Event code 53 (ABS_MT_POSITION_X)
# Value 0
# Min 1
# Max 4008
# Fuzz 0
# Flat 0
# Resolution 44
# Event code 54 (ABS_MT_POSITION_Y)
# Value 0
# Min 1
# Max 2266
# Fuzz 0
# Flat 0
# Resolution 43
# Event code 57 (ABS_MT_TRACKING_ID)
# Value 0
# Min 0
# Max 65535
# Fuzz 0
# Flat 0
# Resolution 0
# Event code 58 (ABS_MT_PRESSURE)
# Value 0
# Min 0
# Max 255
# Fuzz 0
# Flat 0
# Resolution 0
# Properties:
# Property type 0 (INPUT_PROP_POINTER)
N: SYN1EDE:00 06CB:7442
I: 0018 06cb 7442 0100
P: 01 00 00 00 00 00 00 00
B: 00 0b 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 03 00 00 00 00 00
B: 01 20 e5 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 02 00 00 00 00 00 00 00 00
B: 03 03 00 00 01 00 80 73 06
B: 04 00 00 00 00 00 00 00 00
B: 05 00 00 00 00 00 00 00 00
B: 11 00 00 00 00 00 00 00 00
B: 12 00 00 00 00 00 00 00 00
B: 15 00 00 00 00 00 00 00 00
B: 15 00 00 00 00 00 00 00 00
A: 00 1 4008 0 0 44
A: 01 1 2266 0 0 43
A: 18 0 255 0 0 0
A: 2f 0 4 0 0 0
A: 30 0 15 0 0 0
A: 31 0 15 0 0 0
A: 34 0 1 0 0 0
A: 35 1 4008 0 0 44
A: 36 1 2266 0 0 43
A: 39 0 65535 0 0 0
A: 3a 0 255 0 0 0
################################
# Waiting for events #
################################
E: 0.000000 0001 0110 0001 # EV_KEY / BTN_LEFT 1
E: 0.000000 0000 0000 0000 # ------------ SYN_REPORT (0) ----------
E: 0.218140 0001 0110 0000 # EV_KEY / BTN_LEFT 0
E: 0.218140 0000 0000 0000 # ------------ SYN_REPORT (0) ----------
E: 1.488469 0001 0110 0001 # EV_KEY / BTN_LEFT 1
E: 1.488469 0000 0000 0000 # ------------ SYN_REPORT (0) ----------
E: 1.722799 0001 0110 0000 # EV_KEY / BTN_LEFT 0
E: 1.722799 0000 0000 0000 # ------------ SYN_REPORT (0) ----------
[-- Attachment #4: clickpad.hid --]
[-- Type: application/octet-stream, Size: 1000 bytes --]
D: 0
R: 133 05 01 09 02 a1 01 85 01 09 01 a1 00 05 09 19 01 29 02 15 00 25 01 75 01 95 02 81 02 95 06 81 01 05 01 09 30 09 31 15 81 25 7f 75 08 95 02 81 06 c0 c0 06 00 ff 09 01 a1 01 85 09 09 02 15 00 26 ff 00 75 08 95 14 91 02 85 0a 09 03 15 00 26 ff 00 75 08 95 14 91 02 85 0b 09 04 15 00 26 ff 00 75 08 95 27 81 02 85 0c 09 05 15 00 26 ff 00 75 08 95 27 81 02 85 0f 09 06 15 00 26 ff 00 75 08 95 01 b1 02 c0
N: SYN1EDE:00 06CB:7442
P:
I: 18 06cb 7442
D: 0
E: 0.000000 40 0c 20 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
E: 0.150908 40 0c 20 84 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
E: 1.171933 40 0c 20 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
E: 1.342720 40 0c 20 84 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
^ permalink raw reply
* Re: [systemd-devel] Supporting U2F over HID on Linux?
From: Andy Lutomirski @ 2014-12-14 0:33 UTC (permalink / raw)
To: Benjamin Tissoires; +Cc: David Herrmann, linux-input, Jiri Kosina
In-Reply-To: <CAN+gG=F4GSe-jTGqu+73K_7QjRmkSQpwydn1ucEVKhwhWWoTYQ@mail.gmail.com>
On Sat, Dec 13, 2014 at 4:06 PM, Benjamin Tissoires
<benjamin.tissoires@gmail.com> wrote:
>
> On Dec 13, 2014 6:28 PM, "Andy Lutomirski" <luto@amacapital.net> wrote:
>>
>> On Sat, Dec 13, 2014 at 2:56 PM, Jiri Kosina <jkosina@suse.cz> wrote:
>> > On Fri, 12 Dec 2014, Andy Lutomirski wrote:
>> >
>> >> It's roughly ISO7816-3. For the uninitiated (and the ISO7816 standard
>> >> is amazingly vague), that means that the application sends a short
>> >> (<64kB) binary request to the device (with a type, two "parameters",
>> >> and a payload), and the device answers with exactly one reply packet
>> >> that has two bytes of status and a payload. These requests and
>> >> replies are fragmented into multiple HID reports.
>> >
>> > Sorry for taking one (or maybe even more) step back, but what makes this
>> > thing even "HID device"?
>> >
>> > Yes, it interacts with human beings, but are the operations it's doing
>> > covered by HID specification (at least in a "does it have HID
>> > descriptor"
>> > sense)? It's not really completely clear to me at this point.
>>
>> It has a HID descriptor, it's recognized by the HID stack, it
>> understands SET_REPORT, and it generates async HID reports. Hidraw is
>> willing to talk to it and, in fact, Chromium talks to it using hidraw
>> (ugh).
>>
>> It's also supposed to be *enumerated* by reading the HID descriptor.
>> There are multiple vendors of these things, and the USB descriptor
>> doesn't seem to have anything in it to identify the device.
>>
>> I think that's the full extent to which it's a HID device.
>
> And the most important, these devices have a button on them :)
Someone should have told the U2F committee that the device should send
a HID report, then :-/
(Also, at least one implementation is missing the button. You "press
the button" by unplugging and replugging the whole device.)
--Andy
>
> Cheers,
> Benjamin
>
>>
>> --Andy
>>
>> >
>> > Thanks,
>> >
>> > --
>> > Jiri Kosina
>> > SUSE Labs
>>
>>
>>
>> --
>> Andy Lutomirski
>> AMA Capital Management, LLC
--
Andy Lutomirski
AMA Capital Management, LLC
^ permalink raw reply
* Re: [systemd-devel] Supporting U2F over HID on Linux?
From: Benjamin Tissoires @ 2014-12-14 0:39 UTC (permalink / raw)
To: Andy Lutomirski; +Cc: David Herrmann, linux-input, Jiri Kosina
In-Reply-To: <CALCETrWxVmMSHwv5zJEBn7MMOX5qyQGW1S9FoSVxAGLh9_CKEw@mail.gmail.com>
On Sat, Dec 13, 2014 at 7:33 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Sat, Dec 13, 2014 at 4:06 PM, Benjamin Tissoires
> <benjamin.tissoires@gmail.com> wrote:
>>
>> On Dec 13, 2014 6:28 PM, "Andy Lutomirski" <luto@amacapital.net> wrote:
>>>
>>> On Sat, Dec 13, 2014 at 2:56 PM, Jiri Kosina <jkosina@suse.cz> wrote:
>>> > On Fri, 12 Dec 2014, Andy Lutomirski wrote:
>>> >
>>> >> It's roughly ISO7816-3. For the uninitiated (and the ISO7816 standard
>>> >> is amazingly vague), that means that the application sends a short
>>> >> (<64kB) binary request to the device (with a type, two "parameters",
>>> >> and a payload), and the device answers with exactly one reply packet
>>> >> that has two bytes of status and a payload. These requests and
>>> >> replies are fragmented into multiple HID reports.
>>> >
>>> > Sorry for taking one (or maybe even more) step back, but what makes this
>>> > thing even "HID device"?
>>> >
>>> > Yes, it interacts with human beings, but are the operations it's doing
>>> > covered by HID specification (at least in a "does it have HID
>>> > descriptor"
>>> > sense)? It's not really completely clear to me at this point.
>>>
>>> It has a HID descriptor, it's recognized by the HID stack, it
>>> understands SET_REPORT, and it generates async HID reports. Hidraw is
>>> willing to talk to it and, in fact, Chromium talks to it using hidraw
>>> (ugh).
>>>
>>> It's also supposed to be *enumerated* by reading the HID descriptor.
>>> There are multiple vendors of these things, and the USB descriptor
>>> doesn't seem to have anything in it to identify the device.
>>>
>>> I think that's the full extent to which it's a HID device.
>>
>> And the most important, these devices have a button on them :)
>
> Someone should have told the U2F committee that the device should send
> a HID report, then :-/
>
> (Also, at least one implementation is missing the button. You "press
> the button" by unplugging and replugging the whole device.)
>
Well, on the Yubico Fido U2F, there is a button, but it only works
when the client calls the right SET_REPORT. I guess it is to prevent
an attack when there is nobody physically behind the key. So
removing/replugging the device gives the same security: a physical
interaction is required.
Not sending an input report is here to help such button-less devices.
Cheers,
Benjamin
> --Andy
>
>>
>> Cheers,
>> Benjamin
>>
>>>
>>> --Andy
>>>
>>> >
>>> > Thanks,
>>> >
>>> > --
>>> > Jiri Kosina
>>> > SUSE Labs
>>>
>>>
>>>
>>> --
>>> Andy Lutomirski
>>> AMA Capital Management, LLC
>
>
>
> --
> Andy Lutomirski
> AMA Capital Management, LLC
^ permalink raw reply
* Re: [systemd-devel] Supporting U2F over HID on Linux?
From: Andy Lutomirski @ 2014-12-14 0:41 UTC (permalink / raw)
To: Benjamin Tissoires; +Cc: David Herrmann, linux-input, Jiri Kosina
In-Reply-To: <CAN+gG=FW80TOTDbbXW2Yw9BdoSBJTZwXa94TyFOaMirBS7YgJQ@mail.gmail.com>
On Sat, Dec 13, 2014 at 4:39 PM, Benjamin Tissoires
<benjamin.tissoires@gmail.com> wrote:
> On Sat, Dec 13, 2014 at 7:33 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>> On Sat, Dec 13, 2014 at 4:06 PM, Benjamin Tissoires
>> <benjamin.tissoires@gmail.com> wrote:
>>>
>>> On Dec 13, 2014 6:28 PM, "Andy Lutomirski" <luto@amacapital.net> wrote:
>>>>
>>>> On Sat, Dec 13, 2014 at 2:56 PM, Jiri Kosina <jkosina@suse.cz> wrote:
>>>> > On Fri, 12 Dec 2014, Andy Lutomirski wrote:
>>>> >
>>>> >> It's roughly ISO7816-3. For the uninitiated (and the ISO7816 standard
>>>> >> is amazingly vague), that means that the application sends a short
>>>> >> (<64kB) binary request to the device (with a type, two "parameters",
>>>> >> and a payload), and the device answers with exactly one reply packet
>>>> >> that has two bytes of status and a payload. These requests and
>>>> >> replies are fragmented into multiple HID reports.
>>>> >
>>>> > Sorry for taking one (or maybe even more) step back, but what makes this
>>>> > thing even "HID device"?
>>>> >
>>>> > Yes, it interacts with human beings, but are the operations it's doing
>>>> > covered by HID specification (at least in a "does it have HID
>>>> > descriptor"
>>>> > sense)? It's not really completely clear to me at this point.
>>>>
>>>> It has a HID descriptor, it's recognized by the HID stack, it
>>>> understands SET_REPORT, and it generates async HID reports. Hidraw is
>>>> willing to talk to it and, in fact, Chromium talks to it using hidraw
>>>> (ugh).
>>>>
>>>> It's also supposed to be *enumerated* by reading the HID descriptor.
>>>> There are multiple vendors of these things, and the USB descriptor
>>>> doesn't seem to have anything in it to identify the device.
>>>>
>>>> I think that's the full extent to which it's a HID device.
>>>
>>> And the most important, these devices have a button on them :)
>>
>> Someone should have told the U2F committee that the device should send
>> a HID report, then :-/
>>
>> (Also, at least one implementation is missing the button. You "press
>> the button" by unplugging and replugging the whole device.)
>>
>
> Well, on the Yubico Fido U2F, there is a button, but it only works
> when the client calls the right SET_REPORT. I guess it is to prevent
> an attack when there is nobody physically behind the key. So
> removing/replugging the device gives the same security: a physical
> interaction is required.
>
> Not sending an input report is here to help such button-less devices.
It requires that apps on devices with buttons (e.g. the Yubico device)
poll to see when the button is pressed, though.
--Andy
>
> Cheers,
> Benjamin
>
>
>> --Andy
>>
>>>
>>> Cheers,
>>> Benjamin
>>>
>>>>
>>>> --Andy
>>>>
>>>> >
>>>> > Thanks,
>>>> >
>>>> > --
>>>> > Jiri Kosina
>>>> > SUSE Labs
>>>>
>>>>
>>>>
>>>> --
>>>> Andy Lutomirski
>>>> AMA Capital Management, LLC
>>
>>
>>
>> --
>> Andy Lutomirski
>> AMA Capital Management, LLC
--
Andy Lutomirski
AMA Capital Management, LLC
^ permalink raw reply
* Re: [systemd-devel] Supporting U2F over HID on Linux?
From: Benjamin Tissoires @ 2014-12-14 0:48 UTC (permalink / raw)
To: Andy Lutomirski; +Cc: David Herrmann, linux-input, Jiri Kosina
In-Reply-To: <CALCETrXaFFemY8aNttw2tjOBDLE+gS6ydoibx6zmrWFyGPp-9w@mail.gmail.com>
On Sat, Dec 13, 2014 at 7:41 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Sat, Dec 13, 2014 at 4:39 PM, Benjamin Tissoires
> <benjamin.tissoires@gmail.com> wrote:
>> On Sat, Dec 13, 2014 at 7:33 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>>> On Sat, Dec 13, 2014 at 4:06 PM, Benjamin Tissoires
>>> <benjamin.tissoires@gmail.com> wrote:
>>>>
>>>> On Dec 13, 2014 6:28 PM, "Andy Lutomirski" <luto@amacapital.net> wrote:
>>>>>
>>>>> On Sat, Dec 13, 2014 at 2:56 PM, Jiri Kosina <jkosina@suse.cz> wrote:
>>>>> > On Fri, 12 Dec 2014, Andy Lutomirski wrote:
>>>>> >
>>>>> >> It's roughly ISO7816-3. For the uninitiated (and the ISO7816 standard
>>>>> >> is amazingly vague), that means that the application sends a short
>>>>> >> (<64kB) binary request to the device (with a type, two "parameters",
>>>>> >> and a payload), and the device answers with exactly one reply packet
>>>>> >> that has two bytes of status and a payload. These requests and
>>>>> >> replies are fragmented into multiple HID reports.
>>>>> >
>>>>> > Sorry for taking one (or maybe even more) step back, but what makes this
>>>>> > thing even "HID device"?
>>>>> >
>>>>> > Yes, it interacts with human beings, but are the operations it's doing
>>>>> > covered by HID specification (at least in a "does it have HID
>>>>> > descriptor"
>>>>> > sense)? It's not really completely clear to me at this point.
>>>>>
>>>>> It has a HID descriptor, it's recognized by the HID stack, it
>>>>> understands SET_REPORT, and it generates async HID reports. Hidraw is
>>>>> willing to talk to it and, in fact, Chromium talks to it using hidraw
>>>>> (ugh).
>>>>>
>>>>> It's also supposed to be *enumerated* by reading the HID descriptor.
>>>>> There are multiple vendors of these things, and the USB descriptor
>>>>> doesn't seem to have anything in it to identify the device.
>>>>>
>>>>> I think that's the full extent to which it's a HID device.
>>>>
>>>> And the most important, these devices have a button on them :)
>>>
>>> Someone should have told the U2F committee that the device should send
>>> a HID report, then :-/
>>>
>>> (Also, at least one implementation is missing the button. You "press
>>> the button" by unplugging and replugging the whole device.)
>>>
>>
>> Well, on the Yubico Fido U2F, there is a button, but it only works
>> when the client calls the right SET_REPORT. I guess it is to prevent
>> an attack when there is nobody physically behind the key. So
>> removing/replugging the device gives the same security: a physical
>> interaction is required.
>>
>> Not sending an input report is here to help such button-less devices.
>
> It requires that apps on devices with buttons (e.g. the Yubico device)
> poll to see when the button is pressed, though.
So this gives one more reason to have a proper kernel interface for
not doing this ugly polling :)
Out of curiosity, how did you managed to get the unplug/replugged
working? Normally, a hid(raw) device is tighten to its physical
presence, so when you remove the device, you should lose all the
context...
Cheers,
Benjamin
>>
>>
>>> --Andy
>>>
>>>>
>>>> Cheers,
>>>> Benjamin
>>>>
>>>>>
>>>>> --Andy
>>>>>
>>>>> >
>>>>> > Thanks,
>>>>> >
>>>>> > --
>>>>> > Jiri Kosina
>>>>> > SUSE Labs
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Andy Lutomirski
>>>>> AMA Capital Management, LLC
>>>
>>>
>>>
>>> --
>>> Andy Lutomirski
>>> AMA Capital Management, LLC
>
>
>
> --
> Andy Lutomirski
> AMA Capital Management, LLC
^ 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