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 -- 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
