Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752641AbdGMXjD (ORCPT ); Thu, 13 Jul 2017 19:39:03 -0400 Received: from mail.kernel.org ([198.145.29.99]:60214 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751198AbdGMXjC (ORCPT ); Thu, 13 Jul 2017 19:39:02 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AA63D22CAA Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=helgaas@kernel.org Date: Thu, 13 Jul 2017 18:38:59 -0500 From: Bjorn Helgaas To: Sinan Kaya Cc: linux-pci@vger.kernel.org, timur@codeaurora.org, alex.williamson@redhat.com, vikrams@codeaurora.org, Lorenzo.Pieralisi@arm.com, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, Bjorn Helgaas , linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH V4] PCI: handle CRS returned by device after FLR Message-ID: <20170713233859.GA5944@bhelgaas-glaptop.roam.corp.google.com> References: <1499375234-23928-1-git-send-email-okaya@codeaurora.org> <20170713121758.GL4486@bhelgaas-glaptop.roam.corp.google.com> <0bcc0b00-1ad3-6866-32ab-15da8ea1821e@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0bcc0b00-1ad3-6866-32ab-15da8ea1821e@codeaurora.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1258 Lines: 25 On Thu, Jul 13, 2017 at 11:44:12AM -0400, Sinan Kaya wrote: > On 7/13/2017 8:17 AM, Bjorn Helgaas wrote: > >> he spec is calling to wait up to 1 seconds if the device is sending CRS. > >> The NVMe device seems to be requiring more. Relax this up to 60 seconds. > > Can you add a pointer to the "1 second" requirement in the spec here? > > We use 60 seconds in pci_scan_device() and acpiphp_add_context(). Is > > there a basis in the spec for the 60 second timeout? > > This does not specify a hard limit above on how long SW need to wait. I wouldn't expect a *maximum* time we can wait. I'm looking for the minimum times the spec requires. If you're claiming "the spec is calling to wait up to 1 second", I just want to know where in the spec it says that. That helps in the future when we need to maintain code like this. > If I remember it right from CRS commit messages, 60 seconds was coming from > some PCIe switch taking too long to boot. If you have a pointer to this, please include it. The earliest thing I can find is when Linux was imported into git (1da177e4c3f4 ("Linux-2.6.12-rc2")), which includes a 60 second timeout: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pci/probe.c?id=1da177e4c3f4#n686