From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1753228AbcDFTuy (ORCPT <rfc822;w@1wt.eu>);
	Wed, 6 Apr 2016 15:50:54 -0400
Received: from mailrelay7.public.one.com ([91.198.169.215]:53619 "EHLO
	mailrelay7.public.one.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751866AbcDFTuw (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 6 Apr 2016 15:50:52 -0400
X-HalOne-Cookie: c94dde89f4375a44a2a5a842e278e9be81c3fc93
X-HalOne-ID: dc2dddde-fc30-11e5-bb5b-b82a72cffc46
Subject: Re: [PATCH] Input: Do not add SYN_REPORT in between a single packet
 data
To: Aniroop Mathur <aniroop.mathur@gmail.com>,
        Dmitry Torokhov <dmitry.torokhov@gmail.com>
References: <1457372672-884-1-git-send-email-a.mathur@samsung.com>
 <CAKdAkRQT0R6peS8iO8PhQ4YoPMowt6voZJez4EubK7R0ZV_m4Q@mail.gmail.com>
 <56E17A73.8090901@bitmath.org>
 <CADYu30-b+5TFh2yy2SrGTJJ7FzvcezWut1XL3Ypno5R29hyYww@mail.gmail.com>
 <20160401215128.GA5216@dtor-ws>
 <CADYu309K20ki1oMMTGmGQ+CmftCELoSFZfv704YZ_hzmzQG1kQ@mail.gmail.com>
 <CADYu3083da+hW_uLg3WWqgotvOZD1f3V3TdabgX6gDTY93GB7w@mail.gmail.com>
 <20160406173848.GC38452@dtor-ws>
 <CADYu308OF98jdbsqpSVdQpTa0sEafuQmVuC=ttN3-1u59_QvmA@mail.gmail.com>
Cc: Aniroop Mathur <a.mathur@samsung.com>,
        "linux-input@vger.kernel.org" <linux-input@vger.kernel.org>,
        lkml <linux-kernel@vger.kernel.org>
From: Henrik Rydberg <rydberg@bitmath.org>
Message-ID: <570568AB.8010501@bitmath.org>
Date: Wed, 6 Apr 2016 21:51:07 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <CADYu308OF98jdbsqpSVdQpTa0sEafuQmVuC=ttN3-1u59_QvmA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Aniroop,

>> I am not sure what the urgency is. It is more of a theoretical problem
>> ans so far the proposed solutions were actually introducing more
>> problems than they were solving.
>>
>> I am sorry, bit this particular topic is not a priority for me.
>>
> 
> There is no hurry at all. :-) As you know request is made a long time ago,
> so I am only very curious to complete it.

This kind of patch is not liked by any maintainer, because it does not solve any
immediate problem, but instead may create one. If such a simple patch takes
three of four tries to look right, it only adds to the perception that the code
is best left alone.

I think the solution at this stage is to say no to this patch.

If there is ever a driver for which the input_estimate_events_per_packet()
function returns less than the actual maximum number of events per frame, this
issue can be revisited and resolved in a number of different ways.

Sorry, and thanks for your work.

Henrik