Re: Need some help on "Input: elantech - add LEN2146 to SMBus blacklist for ThinkPad L13 Gen2"
From: Nikolai Kostrigin
Date: Thu Feb 25 2021 - 04:17:04 EST
Hi, List!
I'd like to draw attention of Elantech and Lenovo engineers to an issue
of a non-working trackpoint.
Earlier this month I've discovered that Lenovo Thinkpad L13 trackpoint
doesn't work on Linux while touchpad does.
Both use elan_i2c + i2c_i801 drivers. The issue is confirmed for 5.4 and
5.10 kernels.
I had a preliminary discussion with Benjamin Tissoires and according to
our agreement I repost it for wider audience.
Blacklisting the device was decided to be a bad idea.
But actually I managed to get touchpad totally operational via SMBus
using a following hack:
providing a parameter to i2c_i801 driver:
modprobe i2c_i801 disable_features=0x2 (i.e. disable the block buffer).
If any additional information is needed I'm ready to provide it.
Some technical details on the issue we've managed to figure out by now
are here-in-after:
19.02.2021 11:30, Benjamin Tissoires пишет:
> Hi Nikolai,
>
> On Thu, Feb 18, 2021 at 6:05 PM Nikolai Kostrigin <nickel@xxxxxxxxxx> wrote:
>> Hi, Benjamin!
>>
>> Sorry for bothering you directly.
>>
>> I have a question concerning the work on the issue we were discussing on
>> linux-input mailing list.
>>
>> https://patchwork.kernel.org/project/linux-input/patch/20210208075205.3784059-1-nickel@xxxxxxxxxxxx/
[...]
>> With elantech-smbus protocol I was getting persistent messages in dmesg:
>>
>> elan_i2c [...] 0000:00:1f.4 failed to read report data: -71
>>
>> I managed to track -71 (-EPROTO) error code to drivers/i2c/busses/i2c-i801.c
>>
>> Actually I managed to get Touchpad totally operational via SMBus using a
>> following hack:
>> providing a parameter to i2c_i801 driver:
>>
>> modprobe i2c_i801 disable_features=0x2 (i.e. disable the block buffer).
> ooh...
>
>> This makes code operating in other way and recover from illegal SMBus
>> block read size (giving warning messages in dmesg though).
>>
>>
>> [ 1270.105103] i801_smbus 0000:00:1f.4: Illegal SMBus block read size
>> from i801_isr_byte_done 93
>> [ 1270.119337] i801_smbus 0000:00:1f.4: Illegal SMBus block read size
>> from i801_isr_byte_done 93
>> [ 1270.133108] i801_smbus 0000:00:1f.4: Illegal SMBus block read size
>> from i801_isr_byte_done 93 <- theese are from trackpoint
>> [ 1270.167344] i801_smbus 0000:00:1f.4: Illegal SMBus block read size
>> from i801_isr_byte_done 93
>> [ 1399.869023] i801_smbus 0000:00:1f.4: SMBus block read size is 32
>> [ 1399.882266] i801_smbus 0000:00:1f.4: SMBus block read size is 32
>> [ 1399.896619] i801_smbus 0000:00:1f.4: SMBus block read size is 32
>> [ 1399.909850] i801_smbus 0000:00:1f.4: SMBus block read size is 32
>> <- these are from touchpad
>> [ 1399.924117] i801_smbus 0000:00:1f.4: SMBus block read size is 32
>>
>>
>> We end up in this piece of code that has a built-in workaround and makes
>> Trackpoint work with SMBus
>>
>> NB: pay attention to /* FIXME: Recover */ priv->len = I2C_SMBUS_BLOCK_MAX;
>> All code snippets are from drivers/i2c/busses/i2c-i801.c here-in-after
>> (with some debug messages of mine).
>>
>> static void i801_isr_byte_done(struct i801_priv *priv)
>> {
>> if (priv->is_read) {
>> /* For SMBus block reads, length is received with first
>> byte */
>> if (((priv->cmd & 0x1c) == I801_BLOCK_DATA) &&
>> (priv->count == 0)) {
>> priv->len = inb_p(SMBHSTDAT0(priv));
>> if (priv->len < 1 || priv->len >
>> I2C_SMBUS_BLOCK_MAX) {
>> dev_err(&priv->pci_dev->dev,
>> "Illegal SMBus block read size
>> from i801_isr_byte_done %d\n",
>> priv->len);
>> /* FIXME: Recover */
>> priv->len = I2C_SMBUS_BLOCK_MAX;
>> } else {
>> dev_dbg(&priv->pci_dev->dev,
>> "SMBus block read size is %d\n",
>> priv->len);
>> }
>> priv->data[-1] = priv->len;
>> }
>>
>>
>>
>> But with no param passed to i2c_i801 driver we end up here due to len=93
>> with our trackpoint:
>>
>> static int i801_block_transaction_by_block(struct i801_priv *priv,
>> union i2c_smbus_data *data,
>> char read_write, int command,
>> int hwpec)
>> {
>>
>> [...]
>> status = i801_transaction(priv, xact);
>> if (status)
>> return status;
>>
>> 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)
>> {
>> dev_err(&priv->pci_dev->dev,
>> "!!!! Going to send EPROTO from
>> i801_block_transaction_by_block len= %d\n",
>> len);
>> return -EPROTO;
>> }
>> data->block[0] = len;
>> for (i = 0; i < len; i++)
>> data->block[i + 1] = inb_p(SMBBLKDAT(priv));
>> }
>> return 0;
>>
>>
>> so the question is: whether trackpoint has a buggy firmware which
>> violates SMBus spec;
>> or it is really an I2C device which was erroneously
>> wired to SMBus i801 bridge...
> Good question.
> Couple of points:
> - these touchpads can only be used in SMBus as they use the Host
> Notify functionality
> - maybe the trackpoint on it should be handled differently
[...]
>> Please help me to decide what way to choose while developing a workaround.
>>
>> Should I correct trackpoint features list to not mess with 32-byte
>> buffer, or should I force it not to use SMBus at all and use only I2C
>> (if this at all possible).
> I think 2 types of people could help us there:
> - the elan engineers to give us the 'how this trackpoint is supposed
> to behave'. We can involve them in the public thread on linux-input
> - the i2c folks on how we can add a special quirk for these trackpoints.
[...]
> Cheers,
> Benjamin
>
>> --
>> Best regards,
>> Nikolai Kostrigin
>> ALT Linux Team
>>
--
Best regards,
Nikolai Kostrigin