From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B7189C35247 for ; Tue, 4 Feb 2020 15:05:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 847DA20674 for ; Tue, 4 Feb 2020 15:05:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1580828710; bh=zw4chvfmalwHdOyciqzFRFSi/gBzWHXQ9lnCpZVOjsg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=wXIdg+TFYhiJ1487xbBNcsHAMPSC/lGoXmqaXZqDn/D7EPZMfAbY3k8+583wUkHkV Jnzney22BBp3UBnrG0WBZI0ylqKQEBrzs9jekTXGnwpMEfe9GXSsk2k4gH8UGDgMbN 7ZU7CSVzdRaEU1b/512NkBOiXh7wTsLuiNSnPxSM= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727282AbgBDPFK (ORCPT ); Tue, 4 Feb 2020 10:05:10 -0500 Received: from mail-lj1-f196.google.com ([209.85.208.196]:42348 "EHLO mail-lj1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727258AbgBDPFK (ORCPT ); Tue, 4 Feb 2020 10:05:10 -0500 Received: by mail-lj1-f196.google.com with SMTP id d10so18939672ljl.9; Tue, 04 Feb 2020 07:05:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=xbsSRVY+zrKeKD2bmft2n6uSca8g8oklqAyVNk6FGQM=; b=Lw3gIJgl2OKQVaYueBuBkaV1u/r25o5yg3nDsbUPNQGyPgN4OB0v1JVIymGFlHYZAR 01hyOWr/2p6vam1QTnZynawgmRWa3qWsQkI/BlCtB8VSHv3LhO7nxEQDYhd62e/t+/gN NhYoD/5a4clm1/n1akHAUlij9hEyOXggT5/ZXK/57TcAb6OpjIbkqIO6ebrBfajEi4rF 1c8PF7ulZtKdh11g8NCFyforJ980ZUogQ563hzheyufL05eEBckwhx+R7FzUt40GfyWC 1fKywD4i7PQvX5pTWLIi2+xc+ITVQB5LChPHEpwbzs0qNBNNei4pvkiHE4hgfM3PZ3Wo fRtw== X-Gm-Message-State: APjAAAVBe7iCBEpm1PffUQb/MlhDWZggtHfjPHOBrccGr7vVUo4akOnb FcqPv+ULFoQygivEvRTUNmY= X-Google-Smtp-Source: APXvYqyRyMKwmaJHozBl1yZ7dhrbWnyGc2SvVB9Gq9ugJCyZf0zX27+irtkpvgz1NBSt5sT9gSVwnQ== X-Received: by 2002:a2e:8eda:: with SMTP id e26mr18110616ljl.65.1580828707623; Tue, 04 Feb 2020 07:05:07 -0800 (PST) Received: from xi.terra (c-12aae455.07-184-6d6c6d4.bbcust.telenor.se. [85.228.170.18]) by smtp.gmail.com with ESMTPSA id v12sm11565009ljc.94.2020.02.04.07.05.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 04 Feb 2020 07:05:06 -0800 (PST) Received: from johan by xi.terra with local (Exim 4.92.3) (envelope-from ) id 1iyzlM-0004k0-Ss; Tue, 04 Feb 2020 16:05:16 +0100 Date: Tue, 4 Feb 2020 16:05:16 +0100 From: Johan Hovold To: Lauri Jakku Cc: Jiri Kosina , Johan Hovold , Lauri Jakku , oneukum@suse.com, benjamin.tissoires@redhat.com, linux-input@vger.kernel.org, gregkh@linuxfoundation.org, linux-usb@vger.kernel.org Subject: Re: [PATCH v2] USB: HID: random timeout failures tackle try. Message-ID: <20200204150516.GN26725@localhost> References: <20200204110658.32454-1-lja@iki.fi> <20200204123508.GJ26725@localhost> <3bb9f515-a5c6-3162-be5d-f9f984969882@pp.inet.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3bb9f515-a5c6-3162-be5d-f9f984969882@pp.inet.fi> Sender: linux-input-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-input@vger.kernel.org On Tue, Feb 04, 2020 at 02:55:41PM +0200, Lauri Jakku wrote: > > On 4.2.2020 14.43, Jiri Kosina wrote: > > On Tue, 4 Feb 2020, Johan Hovold wrote: > > > >>> Why modify usb-hid-core: No need to modify driver by driver. > >> Because you cannot decide how every use should handle timeouts. > >> > >> Just fix up the driver that needs this. > > I think that if the device is left to errorneus state without > re-trying, it shows up to user very annoying. For example: > My mouse now has the problem with buttons: if i click left > button -> nothing may happen, and it is not functioning until > right button is pressed once. I make adaption to divide the > timeout by 100, and keep the try-loop in core. > > I dont have list all the drivers that needs this -> better fix at > one common place. No, that's precisely my point. You cannot force this behaviour onto every user of control requests. Different devices need different handling, that's why this must be per driver or possibly implemented as a device quirk as Jiri suggested. But we need a better description of the problem first. Is this an issue also during enumeration, or only after when you use your mouse? And exactly which control requests are failing here? Your example above doesn't seem to involve any such requests (only interrupt URB completions). > > I believe it will actually not be a particular driver, but perhaps a set > > of devices with b0rked USB implementation, and we could just introduce > > (another, oh well) per-device quirk list if needed. > > > > Do we have any idea / indication how many devices out there actually > > require this? > Well i'd say quite many. What do you base that on? Johan