Hello,
I just installed Linux on a new Thinkpad E15 and I experience a
non-working touchpad. I can move the mouse just fine, but when I press
one of the three buttons or move the trackpoint the kernel log gets
flooded with:
elan_i2c 0-0015: failed to read report data: -71
and nothing happens in the GUI.
This is a kernel from Debian testing, i.e. 5.10.13, during probe of the
device the following is reported:
elan_i2c 0-0015: supply vcc not found, using dummy regulator
elan_i2c 0-0015: Elan Touchpad: Module ID: 0x000e, Firmware: 0x0001, Sample: 0x0000, IAP: 0x0000
input: Elan Touchpad as /devices/pci0000:00/0000:00:1f.4/i2c-0/0-0015/input/input21
input: Elan TrackPoint as /devices/pci0000:00/0000:00:1f.4/i2c-0/0-0015/input/input22
I backported commits
056115daede8 Input: elan_i2c - add new trackpoint report type 0x5F
c7f0169e3bd2 Input: elan_i2c_core - move header inclusion inside
to this kernel, but this didn't help.
When enabling smbus tracing the matching events are:
irq/159-elan_i2-2207 [003] .... 963.625641: smbus_read: i2c-0 a=015 f=0040 c=a8 BLOCK_DATA
irq/159-elan_i2-2207 [003] .... 963.629247: smbus_result: i2c-0 a=015 f=0000 c=a8 BLOCK_DATA rd res=-71
The relevant code is:
len = i2c_smbus_read_block_data(client,
ETP_SMBUS_PACKET_QUERY,
&report[ETP_SMBUS_REPORT_OFFSET]);
if (len < 0) {
dev_err(&client->dev, "failed to read report data: %d\n", len);
return len;
}
I think the failing location in the i2c driver is
if (read_write == I2C_SMBUS_READ ||
command == I2C_SMBUS_BLOCK_PROC_CALL) {
len = inb_p(SMBHSTDAT0(priv));
if (len < 1 || len > I2C_SMBUS_BLOCK_MAX)
return -EPROTO;
data->block[0] = len;
for (i = 0; i < len; i++)
data->block[i + 1] = inb_p(SMBBLKDAT(priv));
}
in i801_block_transaction_by_block().
Does this ring a bell? Does someone know if there is documentation
available?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
HI uwe:
Please updates this patchs.
https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git/commit/?h=nex
t&id=056115daede8d01f71732bc7d778fb85acee8eb6
https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git/commit/?h=nex
t&id=e4c9062717feda88900b566463228d1c4910af6d
Thanks
jingle
-----Original Message-----
From: Uwe Kleine-König [mailto:u.kleine-koenig@pengutronix.de]
Sent: Wednesday, March 03, 2021 5:10 AM
To: Jingle Wu; Dmitry Torokhov; kernel@pengutronix.de
Cc: linux-input@vger.kernel.org
Subject: elan_i2c: failed to read report data: -71
Hello,
I just installed Linux on a new Thinkpad E15 and I experience a non-working
touchpad. I can move the mouse just fine, but when I press one of the three
buttons or move the trackpoint the kernel log gets flooded with:
elan_i2c 0-0015: failed to read report data: -71
and nothing happens in the GUI.
This is a kernel from Debian testing, i.e. 5.10.13, during probe of the
device the following is reported:
elan_i2c 0-0015: supply vcc not found, using dummy regulator
elan_i2c 0-0015: Elan Touchpad: Module ID: 0x000e, Firmware: 0x0001,
Sample: 0x0000, IAP: 0x0000
input: Elan Touchpad as
/devices/pci0000:00/0000:00:1f.4/i2c-0/0-0015/input/input21
input: Elan TrackPoint as
/devices/pci0000:00/0000:00:1f.4/i2c-0/0-0015/input/input22
I backported commits
056115daede8 Input: elan_i2c - add new trackpoint report type 0x5F
c7f0169e3bd2 Input: elan_i2c_core - move header inclusion inside
to this kernel, but this didn't help.
When enabling smbus tracing the matching events are:
irq/159-elan_i2-2207 [003] .... 963.625641: smbus_read: i2c-0 a=015
f=0040 c=a8 BLOCK_DATA
irq/159-elan_i2-2207 [003] .... 963.629247: smbus_result: i2c-0 a=015
f=0000 c=a8 BLOCK_DATA rd res=-71
The relevant code is:
len = i2c_smbus_read_block_data(client,
ETP_SMBUS_PACKET_QUERY,
&report[ETP_SMBUS_REPORT_OFFSET]);
if (len < 0) {
dev_err(&client->dev, "failed to read report data: %d\n",
len);
return len;
}
I think the failing location in the i2c driver is
if (read_write == I2C_SMBUS_READ ||
command == I2C_SMBUS_BLOCK_PROC_CALL) {
len = inb_p(SMBHSTDAT0(priv));
if (len < 1 || len > I2C_SMBUS_BLOCK_MAX)
return -EPROTO;
data->block[0] = len;
for (i = 0; i < len; i++)
data->block[i + 1] = inb_p(SMBBLKDAT(priv));
}
in i801_block_transaction_by_block().
Does this ring a bell? Does someone know if there is documentation
available?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
Hi Uwe,
On Tue, Mar 02, 2021 at 10:09:34PM +0100, Uwe Kleine-König wrote:
Hello,
I just installed Linux on a new Thinkpad E15 and I experience a
non-working touchpad. I can move the mouse just fine, but when I press
one of the three buttons or move the trackpoint the kernel log gets
flooded with:
elan_i2c 0-0015: failed to read report data: -71
and nothing happens in the GUI.
This is a kernel from Debian testing, i.e. 5.10.13, during probe of the
device the following is reported:
elan_i2c 0-0015: supply vcc not found, using dummy regulator
elan_i2c 0-0015: Elan Touchpad: Module ID: 0x000e, Firmware: 0x0001, Sample: 0x0000, IAP: 0x0000
input: Elan Touchpad as /devices/pci0000:00/0000:00:1f.4/i2c-0/0-0015/input/input21
input: Elan TrackPoint as /devices/pci0000:00/0000:00:1f.4/i2c-0/0-0015/input/input22
I backported commits
056115daede8 Input: elan_i2c - add new trackpoint report type 0x5F
c7f0169e3bd2 Input: elan_i2c_core - move header inclusion inside
to this kernel, but this didn't help.
When enabling smbus tracing the matching events are:
irq/159-elan_i2-2207 [003] .... 963.625641: smbus_read: i2c-0 a=015 f=0040 c=a8 BLOCK_DATA
irq/159-elan_i2-2207 [003] .... 963.629247: smbus_result: i2c-0 a=015 f=0000 c=a8 BLOCK_DATA rd res=-71
The relevant code is:
len = i2c_smbus_read_block_data(client,
ETP_SMBUS_PACKET_QUERY,
&report[ETP_SMBUS_REPORT_OFFSET]);
if (len < 0) {
dev_err(&client->dev, "failed to read report data: %d\n", len);
return len;
}
I think the failing location in the i2c driver is
if (read_write == I2C_SMBUS_READ ||
command == I2C_SMBUS_BLOCK_PROC_CALL) {
len = inb_p(SMBHSTDAT0(priv));
if (len < 1 || len > I2C_SMBUS_BLOCK_MAX)
return -EPROTO;
data->block[0] = len;
for (i = 0; i < len; i++)
data->block[i + 1] = inb_p(SMBBLKDAT(priv));
}
in i801_block_transaction_by_block().
Does this ring a bell? Does someone know if there is documentation
available?
I believe Nikolai also run into this issue and is saying that
modprobe i2c_i801 disable_features=0x2
cures the touchpad.
Thanks.
--
Dmitry
From: Nikolai Kostrigin <hidden> Date: 2021-03-04 00:27:23
Hi,
03.03.2021 04:26, Dmitry Torokhov пишет:
Hi Uwe,
On Tue, Mar 02, 2021 at 10:09:34PM +0100, Uwe Kleine-König wrote:
quoted
Hello,
I just installed Linux on a new Thinkpad E15 and I experience a
non-working touchpad. I can move the mouse just fine, but when I press
one of the three buttons or move the trackpoint the kernel log gets
flooded with:
elan_i2c 0-0015: failed to read report data: -71
and nothing happens in the GUI.
This is a kernel from Debian testing, i.e. 5.10.13, during probe of the
device the following is reported:
elan_i2c 0-0015: supply vcc not found, using dummy regulator
elan_i2c 0-0015: Elan Touchpad: Module ID: 0x000e, Firmware: 0x0001, Sample: 0x0000, IAP: 0x0000
input: Elan Touchpad as /devices/pci0000:00/0000:00:1f.4/i2c-0/0-0015/input/input21
input: Elan TrackPoint as /devices/pci0000:00/0000:00:1f.4/i2c-0/0-0015/input/input22
I backported commits
056115daede8 Input: elan_i2c - add new trackpoint report type 0x5F
c7f0169e3bd2 Input: elan_i2c_core - move header inclusion inside
Uwe, you might miss
e4c9062717fe Input: elantech - fix protocol errors for some trackpoints
in SMBus mode
quoted
to this kernel, but this didn't help.
When enabling smbus tracing the matching events are:
irq/159-elan_i2-2207 [003] .... 963.625641: smbus_read: i2c-0 a=015 f=0040 c=a8 BLOCK_DATA
irq/159-elan_i2-2207 [003] .... 963.629247: smbus_result: i2c-0 a=015 f=0000 c=a8 BLOCK_DATA rd res=-71
The relevant code is:
len = i2c_smbus_read_block_data(client,
ETP_SMBUS_PACKET_QUERY,
&report[ETP_SMBUS_REPORT_OFFSET]);
if (len < 0) {
dev_err(&client->dev, "failed to read report data: %d\n", len);
return len;
}
I think the failing location in the i2c driver is
if (read_write == I2C_SMBUS_READ ||
command == I2C_SMBUS_BLOCK_PROC_CALL) {
len = inb_p(SMBHSTDAT0(priv));
if (len < 1 || len > I2C_SMBUS_BLOCK_MAX)
return -EPROTO;
data->block[0] = len;
for (i = 0; i < len; i++)
data->block[i + 1] = inb_p(SMBBLKDAT(priv));
}
in i801_block_transaction_by_block().
Does this ring a bell? Does someone know if there is documentation
available?
I believe Nikolai also run into this issue and is saying that
modprobe i2c_i801 disable_features=0x2
cures the touchpad.
The first was one of the two patches I already tried, but the latter
indeed fixes my problem \o/.
@Dmitry: If you don't consider your tree stable, feel free to add a
Tested-by: Uwe Kleine-König [off-list ref]
to e4c9062717feda88900b566463228d1c4910af6d.
Best regards and thanks for your support,
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
The first was one of the two patches I already tried, but the latter
indeed fixes my problem \o/.
@Dmitry: If you don't consider your tree stable, feel free to add a
Tested-by: Uwe Kleine-König [off-list ref]
to e4c9062717feda88900b566463228d1c4910af6d.
Do you consider this patch for stable? I'd like to see it in Debian's
5.10 kernel and I guess I'm not the only one who would benefit from such
a backport.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
The first was one of the two patches I already tried, but the latter
indeed fixes my problem \o/.
@Dmitry: If you don't consider your tree stable, feel free to add a
Tested-by: Uwe Kleine-König [off-list ref]
to e4c9062717feda88900b566463228d1c4910af6d.
Do you consider this patch for stable? I'd like to see it in Debian's
5.10 kernel and I guess I'm not the only one who would benefit from such
a backport.
When I was applying the patches I did not realize that there was already
hardware in the wild that needed it. The patches are now in mainline, so
I can no longer adjust the tags, but I will not object if you propose
them for stable.
Thanks.
--
Dmitry
The first was one of the two patches I already tried, but the latter
indeed fixes my problem \o/.
@Dmitry: If you don't consider your tree stable, feel free to add a
Tested-by: Uwe Kleine-König [off-list ref]
to e4c9062717feda88900b566463228d1c4910af6d.
Do you consider this patch for stable? I'd like to see it in Debian's
5.10 kernel and I guess I'm not the only one who would benefit from such
a backport.
When I was applying the patches I did not realize that there was already
hardware in the wild that needed it. The patches are now in mainline, so
I can no longer adjust the tags, but I will not object if you propose
them for stable.
I want to propose to backport commit
e4c9062717fe ("Input: elantech - fix protocol errors for some trackpoints in SMBus mode")
to the active stable kernels. This commit repairs the track point and
the touch pad buttons on a Lenovo Thinkpad E15 here. Without this change
I don't get any events apart from an error message for each button press
or move of the track point in the kernel log. (Also the error message is
the same for all buttons and the track point, so I cannot create a new
input event driver in userspace that emulates the right event depending
on the error message :-)
At least to 5.10.x it applies cleanly, I didn't try the older stable
branches.
Best regards and thanks
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
The first was one of the two patches I already tried, but the latter
indeed fixes my problem \o/.
@Dmitry: If you don't consider your tree stable, feel free to add a
Tested-by: Uwe Kleine-König [off-list ref]
to e4c9062717feda88900b566463228d1c4910af6d.
Do you consider this patch for stable? I'd like to see it in Debian's
5.10 kernel and I guess I'm not the only one who would benefit from such
a backport.
When I was applying the patches I did not realize that there was already
hardware in the wild that needed it. The patches are now in mainline, so
I can no longer adjust the tags, but I will not object if you propose
them for stable.
I want to propose to backport commit
e4c9062717fe ("Input: elantech - fix protocol errors for some trackpoints in SMBus mode")
to the active stable kernels. This commit repairs the track point and
the touch pad buttons on a Lenovo Thinkpad E15 here. Without this change
I don't get any events apart from an error message for each button press
or move of the track point in the kernel log. (Also the error message is
the same for all buttons and the track point, so I cannot create a new
input event driver in userspace that emulates the right event depending
on the error message :-)
At least to 5.10.x it applies cleanly, I didn't try the older stable
branches.
Best regards and thanks
Uwe
I'd like to propose to backport [1] also as it was checked along with
previously proposed patch and fixes Elan Trackpoint operation on
Thinkpad L13.
Both patches apply cleanly to 5.10.17 in my case.
I also tried to apply to 5.4.x, but failed.
[1] 056115daede8 Input: elan_i2c - add new trackpoint report type 0x5F
Additional info is available here:
https://lore.kernel.org/linux-input/fe31f6f8-6e38-2ed6-8548-6fa271bf36e9@basealt.ru/T/#m514047f2c5e7e2ec4ed9658782f14221ed7598fc
--
Best regards,
Nikolai Kostrigin
The first was one of the two patches I already tried, but the latter
indeed fixes my problem \o/.
@Dmitry: If you don't consider your tree stable, feel free to add a
Tested-by: Uwe Kleine-König [off-list ref]
to e4c9062717feda88900b566463228d1c4910af6d.
Do you consider this patch for stable? I'd like to see it in Debian's
5.10 kernel and I guess I'm not the only one who would benefit from such
a backport.
When I was applying the patches I did not realize that there was already
hardware in the wild that needed it. The patches are now in mainline, so
I can no longer adjust the tags, but I will not object if you propose
them for stable.
I want to propose to backport commit
e4c9062717fe ("Input: elantech - fix protocol errors for some trackpoints in SMBus mode")
to the active stable kernels. This commit repairs the track point and
the touch pad buttons on a Lenovo Thinkpad E15 here. Without this change
I don't get any events apart from an error message for each button press
or move of the track point in the kernel log. (Also the error message is
the same for all buttons and the track point, so I cannot create a new
input event driver in userspace that emulates the right event depending
on the error message :-)
At least to 5.10.x it applies cleanly, I didn't try the older stable
branches.
The first was one of the two patches I already tried, but the latter
indeed fixes my problem \o/.
@Dmitry: If you don't consider your tree stable, feel free to add a
Tested-by: Uwe Kleine-König [off-list ref]
to e4c9062717feda88900b566463228d1c4910af6d.
Do you consider this patch for stable? I'd like to see it in Debian's
5.10 kernel and I guess I'm not the only one who would benefit from such
a backport.
When I was applying the patches I did not realize that there was already
hardware in the wild that needed it. The patches are now in mainline, so
I can no longer adjust the tags, but I will not object if you propose
them for stable.
I want to propose to backport commit
e4c9062717fe ("Input: elantech - fix protocol errors for some trackpoints in SMBus mode")
to the active stable kernels. This commit repairs the track point and
the touch pad buttons on a Lenovo Thinkpad E15 here. Without this change
I don't get any events apart from an error message for each button press
or move of the track point in the kernel log. (Also the error message is
the same for all buttons and the track point, so I cannot create a new
input event driver in userspace that emulates the right event depending
on the error message :-)
At least to 5.10.x it applies cleanly, I didn't try the older stable
branches.
Best regards and thanks
Uwe
I'd like to propose to backport [1] also as it was checked along with
previously proposed patch and fixes Elan Trackpoint operation on
Thinkpad L13.
Both patches apply cleanly to 5.10.17 in my case.
I also tried to apply to 5.4.x, but failed.
[1] 056115daede8 Input: elan_i2c - add new trackpoint report type 0x5F
The first was one of the two patches I already tried, but the latter
indeed fixes my problem \o/.
@Dmitry: If you don't consider your tree stable, feel free to add a
Tested-by: Uwe Kleine-König [off-list ref]
to e4c9062717feda88900b566463228d1c4910af6d.
Do you consider this patch for stable? I'd like to see it in Debian's
5.10 kernel and I guess I'm not the only one who would benefit from such
a backport.
When I was applying the patches I did not realize that there was already
hardware in the wild that needed it. The patches are now in mainline, so
I can no longer adjust the tags, but I will not object if you propose
them for stable.
I want to propose to backport commit
e4c9062717fe ("Input: elantech - fix protocol errors for some trackpoints in SMBus mode")
to the active stable kernels. This commit repairs the track point and
the touch pad buttons on a Lenovo Thinkpad E15 here. Without this change
I don't get any events apart from an error message for each button press
or move of the track point in the kernel log. (Also the error message is
the same for all buttons and the track point, so I cannot create a new
input event driver in userspace that emulates the right event depending
on the error message :-)
At least to 5.10.x it applies cleanly, I didn't try the older stable
branches.
Best regards and thanks
Uwe
FTR: I tested 5.10 + e4c9062717fe ("Input: elantech - fix protocol
errors for some trackpoints in SMBus mode") now and in this setup the
touchpad is still broken. I assume that in combination with 056115daede8
it will work. The working setup I tested was 5.10 + c7f0169e3bd2 +
056115daede8 + e4c9062717fe and I assume c7f0169e3bd2 isn't relevant.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
Hi,
I have installed the latest 5.10 kernel on Lenovo L13 laptop and
both touchpad and trackpoint work fine. But after resuming from
hibernation mode trackpoint(and 3 buttons) stop working. The kernel
log says:
elan_i2c 14-0015: failed to read report data: -71
I assume this is because some initial trackpoint setup is done on the
first boot. Then after hibernation the device resets. And the wake-up
code doesn't set it up properly.
Any help would be appreciated.