Re: [PATCH 00/15] atmel_mxt_ts - device tree, bootloader, etc

[Stephen Warren]

On 07/29/2014 11:06 AM, Nick Dyer wrote:
> On 29/07/14 17:16, Stephen Warren wrote:
> > I then tried updating the firmware. This didn't work at all.
> >
> > First I tried via mxt-app:
> >
> > > root@localhost:~# ./obp-utils/mxt-app -d i2c-dev:1-004b --flash
> > > 130.1_1.0.170.bin
> > > Version:1.16-65-g0a4c
> > > Opening firmware file 130.1_1.0.170.bin
> > > Registered i2c-dev adapter:1 address:0x4b
> > > Chip detected
> > > Current firmware version: 1.0.AA
> > > Skipping version check
> > > Resetting in bootloader mode
> > > Registered i2c-dev adapter:1 address:0x25
> > > Error Remote I/O error (121) reading from i2c
> > > Bootloader read failure
> > > Bootloader not found
> >
> > Then I power-cycled and tried via the atmel_mxt_ts modules' sysfs files:
> >
> > > root@localhost:~# echo 1 >
> > > /sys/devices/soc0/7000c400.i2c/i2c-1/1-004b/update_fw
> > > [   38.495420] atmel_mxt_ts 1-004b: mxt_bootloader_read: i2c recv failed
> > > (-121)
> > > [   38.506208] atmel_mxt_ts 1-004b: mxt_bootloader_read: i2c recv failed
> > > (-121)
> > > [   38.513836] atmel_mxt_ts 1-004b: The firmware update failed(-121)
> > > -bash: echo: write error: Remote I/O error
>
> OK - that's the same error in both cases, it has tried to switch the device
> into bootloader mode, however it is not responding on the bootloader I2C
> address.
>
> Couple of things to check:
> - is the device in deep sleep mode when you run the mxt-app command? can
> you try doing "mxt-app [device] -W -T7 FFFF" which will make sure it is
> definitely not sleeping first.

That didn't hekp.

> - if you do "mxt-app [device] -i" straight after the --flash failure, does
> it respond (which would mean it hasn't actioned the reset-into-bootloader
> command)

That still works, so I assume it wasn't reset into bootloader mode. I 
also tried mxt-app --reset-bootloader, and mxt-app -i still works after 
that too.

> > I also found that removing the module (even without attempting a FW update)
> > yields:
> >
> > After attempted FW update via sysfs:
> >
> > > root@localhost:~# rmmod ./atmel_mxt_ts.ko
> > > [   81.995672] Unable to handle kernel NULL pointer dereference at virtual address 00000364
>
> Not good. It's trying to free an input device which isn't registered at
> that point. In a later patch in my series I add a guard around that
> (mxt_free_input_device):
> https://github.com/ndyer/linux/commit/bb4800ff8c185

It looks like 8d01a84b86b0 "Input: atmel_mxt_ts - implement T100 touch 
object support" from that branch is what solves the issue.

Ah, in linux-next, it's simply a double-unregister; both mxt_remove() 
and mxt_free_object_table() call 
input_unregister_device(data->input_dev). I think it would make sense to 
send the following patch for 3.17. Do you agree?

diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c 
b/drivers/input/touchscreen/atmel_mxt_ts.c
index 03b85711cb70..da497dbf9735 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -1353,8 +1353,10 @@ static int mxt_get_info(struct mxt_data *data)

 static void mxt_free_object_table(struct mxt_data *data)
 {
-	input_unregister_device(data->input_dev);
-	data->input_dev = NULL;
+	if (data->input_dev) {
+		input_unregister_device(data->input_dev);
+		data->input_dev = NULL;
+	}

 	kfree(data->object_table);
 	data->object_table = NULL;
@@ -2194,7 +2196,6 @@ static int mxt_remove(struct i2c_client *client)

 	sysfs_remove_group(&client->dev.kobj, &mxt_attr_group);
 	free_irq(data->irq, data);
-	input_unregister_device(data->input_dev);
 	mxt_free_object_table(data);
 	kfree(data);

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/