On Tue, Jan 31, 2012 at 8:21 AM, Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> wrote: > On Sun, Jan 29, 2012 at 04:28:12PM +0100, Javier Martinez Canillas wrote: >> On Sun, Jan 29, 2012 at 7:18 AM, Dmitry Torokhov >> <dmitry.torokhov@xxxxxxxxx> wrote: >> > On Sun, Jan 29, 2012 at 06:53:50AM +0100, Javier Martinez Canillas wrote: >> >> This is patch fixes two bugs in Dmitry's last cleanup patch. >> >> >> >> 1- The hardware tracking ids are stored in the ids array and the information for >> >> each contact is obtained calling cyttsp_get_tch() with an index. In the clean-up >> >> patch the value of the tracking id was used instead of the contact index. >> >> >> > >> > Oops, thank you for fixing that. >> > >> >> 2- i2c_set_clientdata() is called after the generic cyttsp_probe() function and >> >> this function calls cyttsp_power_on() that sends an ttsp command to the device >> >> and needs the client data before is set. The fix is to execute cyttsp_power_on >> >> inside the transport specific probe function (I2C, SPI) after the generic probe >> >> function is executed and the client data is set. >> >> >> > >> > Not quite happy about this one, how about we pass cyttsp directly to bus >> > methods instead of relying on drvdata (as in the patch below)? >> > >> > Thanks. >> > >> > -- >> > Dmitry >> >> Hi Dmitry, >> >> Yes, you are right that is a much more clever solution to the issue. >> Thank you for suggesting that. >> >> I just sent an v2 of the incremental patch to be applied on top of >> your last clean-up. >> >> This fixes the index bug stated before and the dev->i2c_client->cyttsp >> reference being NULL issue changing the read/write methods signature >> as you suggested. >> >> It also fixes an unbalanced IRQ warning since soft_reset() now is >> called inside the probe function and removes the wake_up platform >> function in enable() as with the incremental v1. >> >> Thanks a lot for your help and best regards, > > Folded everything up and applied to my 3.4 queue. > > Thank you Javier. > > -- > Dmitry Great, thank you very much for your help Dmitry! Regards, Javier -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
