From 86bcd3a12999447faad60ec59c2d64d18d8e61ac Mon Sep 17 00:00:00 2001 From: Lucas Stach Date: Mon, 2 Dec 2019 09:37:00 -0800 Subject: Input: synaptics-rmi4 - re-enable IRQs in f34v7_do_reflash F34 is a bit special as it reinitializes the device and related driver structs during the firmware update. This clears the fn_irq_mask which will then prevent F34 from receiving further interrupts, leading to timeouts during the firmware update. Make sure to reinitialize the IRQ enables at the appropriate times. The issue is in F34 code, but the commit in the fixes tag exposed the issue, as before this commit things would work by accident. Fixes: 363c53875aef (Input: synaptics-rmi4 - avoid processing unknown IRQs) Signed-off-by: Lucas Stach Link: https://lore.kernel.org/r/20191129133514.23224-1-l.stach@pengutronix.de Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov --- drivers/input/rmi4/rmi_f34v7.c | 3 +++ 1 file changed, 3 insertions(+) (limited to 'drivers/input/rmi4') diff --git a/drivers/input/rmi4/rmi_f34v7.c b/drivers/input/rmi4/rmi_f34v7.c index a4cabf52740c..74f7c6f214ff 100644 --- a/drivers/input/rmi4/rmi_f34v7.c +++ b/drivers/input/rmi4/rmi_f34v7.c @@ -1189,6 +1189,9 @@ int rmi_f34v7_do_reflash(struct f34_data *f34, const struct firmware *fw) { int ret; + f34->fn->rmi_dev->driver->set_irq_bits(f34->fn->rmi_dev, + f34->fn->irq_mask); + rmi_f34v7_read_queries_bl_version(f34); f34->v7.image = fw->data; -- cgit v1.2.3 From a284e11c371e446371675668d8c8120a27227339 Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Mon, 2 Dec 2019 10:08:12 -0800 Subject: Input: synaptics-rmi4 - don't increment rmiaddr for SMBus transfers This increment of rmi_smbus in rmi_smb_read/write_block() causes garbage to be read/written. The first read of SMB_MAX_COUNT bytes is fine, but after that it is nonsense. Trial-and-error showed that by dropping the increment of rmiaddr everything is fine and the F54 function properly works. I tried a hack with rmi_smb_write_block() as well (writing to the same F54 touchpad data area, then reading it back), and that suggests that there too the rmiaddr increment has to be dropped. It makes sense that if it has to be dropped for read, then it has to be dropped for write as well. It looks like the initial work with F54 was done using i2c, not smbus, and it seems nobody ever tested F54 with smbus. The other functions all read/write less than SMB_MAX_COUNT as far as I can tell, so this issue was never noticed with non-F54 functions. With this change I can read out the touchpad data correctly on my Lenovo X1 Carbon 6th Gen laptop. Signed-off-by: Hans Verkuil Link: https://lore.kernel.org/r/8dd22e21-4933-8e9c-a696-d281872c8de7@xs4all.nl Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov --- drivers/input/rmi4/rmi_smbus.c | 2 -- 1 file changed, 2 deletions(-) (limited to 'drivers/input/rmi4') diff --git a/drivers/input/rmi4/rmi_smbus.c b/drivers/input/rmi4/rmi_smbus.c index 2407ea43de59..b313c579914f 100644 --- a/drivers/input/rmi4/rmi_smbus.c +++ b/drivers/input/rmi4/rmi_smbus.c @@ -163,7 +163,6 @@ static int rmi_smb_write_block(struct rmi_transport_dev *xport, u16 rmiaddr, /* prepare to write next block of bytes */ cur_len -= SMB_MAX_COUNT; databuff += SMB_MAX_COUNT; - rmiaddr += SMB_MAX_COUNT; } exit: mutex_unlock(&rmi_smb->page_mutex); @@ -215,7 +214,6 @@ static int rmi_smb_read_block(struct rmi_transport_dev *xport, u16 rmiaddr, /* prepare to read next block of bytes */ cur_len -= SMB_MAX_COUNT; databuff += SMB_MAX_COUNT; - rmiaddr += SMB_MAX_COUNT; } retval = 0; -- cgit v1.2.3