On Thu, Jul 07, 2016 at 01:41:01PM +0200, Pali Rohár wrote: > On Tuesday 21 June 2016 13:27:30 Pali Rohár wrote: > > On Monday 20 June 2016 17:31:13 Dmitry Torokhov wrote: > > > Hi Pali, > > > > > > On Mon, Jun 06, 2016 at 01:23:56PM +0200, Pali Rohár wrote: > > > > This patch series cleanup usage of alps_model_data table. > > > > > > > > Pali Rohár (5): > > > > Input: alps - move ALPS_PROTO_V6 out of alps_model_data table > > > > Input: alps - move ALPS_PROTO_V4 out of alps_model_data table > > > > Input: alps - move ALPS_PROTO_V1 out of alps_model_data table > > > > Input: alps - warn about unsupported ALPS V9 touchpad > > > > Input: alps - cleanup ALPS_PROTO_V2 detection > > > > > > Frankly, I do not quite like this series. The rule of thumb we had: if > > > we can use e7 data to identify the device it should go into table, > > > if we need to have more elaborate logic - then implement it in > > > __alps_indentify(). I would understand if we got rid of the table > > > completely, but we didn't. > > > > Hans and me agreed that alps_model_data array is for old touchpads > > defined as quirks table. So in this patch series I'm trying to eliminate > > using that array. And it is possible for V1, V4 and V6 touchpads because > > each protocol has only one entry in table. And last user is just V2 > > protocol which is I think better... > > > > So this is my motivation for this patch series. > > Any suggestion how to rework it? And any agreement if we should remove > V1/V4/V6 from alps_model_date or let it stay here? As I mentioned below I am happy with removing ALPS_PROTO_V4 and subsequently command_mode_resp from alps_model_info, while leaving the rest in the table. Thanks. > > > > I think the patch removing ALPS_PROTO_V4 and subsequent patch removing > > > command_mode_resp from alps_model_info are good, the rest are not so > > > much. > > > > > > Thanks. > > > > > > > -- > Pali Rohár > pali.rohar@xxxxxxxxx -- 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
