From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B689623AE8E for ; Mon, 10 Feb 2025 15:32:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739201525; cv=none; b=QfHI6CYlpcfda4fq5ZlNvOK/cV3Vx4A8ru+Pj07YW3Qmr1wGNDatQ2kFmjgtJv/TjaJfXU8VtT4tPDsJJUn+/eCQpegRScICW6hYgQpVxX0SiIWXlsWyNCDm1LKvFtrxGKBMS9MSFevaRkBBynduNVsakh8ftTpWtZZhKY7FCPE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739201525; c=relaxed/simple; bh=J1txiC+7XGCUcKNAIj9Ckq31hPjHma/hMYcKlWTKvbU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=MY0BCpyh5PVjuxn12vRWLfdGfvilihuhpnfCRRnFAwax1icuBg4qxQMWFwKPxOnkyUTkgO+23h52WFdP2TD1uH310EooMGG2wB9gd4qrgO21s9D8AXzqLMEZeSZIvWqq+iEcIqb/DriIR9LPJtEa/gRrKE0kN3vE1/NW39XPFG8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=aXyO3kbX; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="aXyO3kbX" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 34175C4CEDF; Mon, 10 Feb 2025 15:32:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1739201525; bh=J1txiC+7XGCUcKNAIj9Ckq31hPjHma/hMYcKlWTKvbU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=aXyO3kbXy81dvrQuQPVE1sZ8kXQH6cuoMHFOcU9fefLdVAx1O8Ajf/+eJxHUyBfs9 qygkvdCvmRIKjWbMj5f/UoK5G85MfDKlB5+a9aYC0d3Tug/PkqMvTJxqK4WQIZwImc i+Gmp6z/Llx/O30tzXzuBfl1MBxXU28f+YebjB5aGtr+bPPhT7KgCPbhehKzWQaDkH XK11zjMZ/677zcXnQpgTrm9+RoOXGt/sQlaGCBcNqUrT5gIV1rq5XBvJkzjTzG+Mqm zORlqQ6QUGConP/FyIfuySkNfVU48qt6zTUF4SUS8RYaSns+iENJfIgHqku+pF5mba Y4al4U5RJ8m6Q== Date: Mon, 10 Feb 2025 08:32:03 -0700 From: Keith Busch To: Lukas Wunner Cc: Keith Busch , bhelgaas@google.com, linux-pci@vger.kernel.org Subject: Re: [PATCH] pci: allow user specifiy a reset wait timeout Message-ID: References: <20250207204310.2546091-1-kbusch@meta.com> Precedence: bulk X-Mailing-List: linux-pci@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Mon, Feb 10, 2025 at 04:15:54PM +0100, Lukas Wunner wrote: > On Mon, Feb 10, 2025 at 07:59:01AM -0700, Keith Busch wrote: > > My concern with quirking it is that we'd have to settle on what we think > > is the worst case timeout, then it becomes compiled into that kernel for > > that device. The devices I'm dealing with are actively under > > development, and the time to ready gets bigger or smaller as updates > > occur, or some new worst case scenario is discovered. Making this a boot > > time decicion really helps with experimentation here. > > I understand, but honestly this doesn't sound like something which > needs to be in the upstream kernel. If it's for experimentation only, > I'd keep it in the downstream kernel used for experimentation > and if it turns out that 60 sec is insufficient for the final > production device, I'd submit a quirk for that. It's always a pain to carry out of tree patches. These might be devices having active development, but they are used in production and the systems they're in follow the standard kernel updates. And before this generation of devices even settles on an appropriate quirk timeout might require (if that ever happens), I have the next generations to deal with, so this need isn't going to go away. Carrying such an out of tree patch for eternity sounds unpleasant.