Received-SPF: pass (google.com: domain of linux-kernel+bounces-62252-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Mon, 12 Feb 2024 14:04:31 -0500
From: Alan Stern <stern@rowland.harvard.edu>
To: Oliver Neukum <oneukum@suse.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
  Ricardo Ribalda <ribalda@chromium.org>,
  Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
  Mauro Carvalho Chehab <mchehab@kernel.org>, linux-usb@vger.kernel.org,
  linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
  stable@vger.kernel.org
Subject: Re: [PATCH v4] media: ucvideo: Add quirk for Logitech Rally Bar
Message-ID: <6aade777-d97c-4c65-b542-14ce5b39abb6@rowland.harvard.edu>
References: <20240108-rallybar-v4-1-a7450641e41b@chromium.org>
 <20240204105227.GB25334@pendragon.ideasonboard.com>
 <ca89eb86-a566-422c-9448-d8d5254d54b8@suse.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ca89eb86-a566-422c-9448-d8d5254d54b8@suse.com>

On Mon, Feb 12, 2024 at 01:22:42PM +0100, Oliver Neukum wrote:
> On 04.02.24 11:52, Laurent Pinchart wrote:
> > Hi Ricardo,
> > 
> > Thank you for the patch.
> 
> Hi,
> 
> sorry for commenting on this late, but this patch has
> a fundamental issue. In fact this issue is the reason the
> handling for quirks is in usbcore at all.
> 
> If you leave the setting/clearing of this flag to a driver you
> are introducing a race condition. The driver may or may not be
> present at the time a device is enumerated. And you have
> no idea how long the autosuspend delay is on a system
> and what its default policy is regarding suspending
> devices.
> That means that a device can have been suspended and
> resumed before it is probed. On a device that needs
> RESET_RESUME, we are in trouble.

Not necessarily.  If the driver knows that one of these devices may 
already have been suspend and resumed, it can issue its own preemptive 
reset at probe time.

> The inverse issue will arise if a device does not react
> well to RESET_RESUME. You cannot rule out that a device
> that must not be reset will be reset.

That's a separate issue, with its own list of potential problems.

> I am sorry, but it seems to me that the exceptions need
> to go into usbcore.

If we do then we may want to come up with a better scheme for seeing 
which devices need to have a quirk flag set.  A static listing probably 
won't be good enough; the decision may have to be made dynamically.

Alan Stern