Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp4392449pxf; Tue, 23 Mar 2021 09:29:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJztB4SEMvzvfrtUM9O+DYAI9/tQF+BSUeh34WRwBMnKOjpr2Hk30wvMtiT+kLfofjkzkXFH X-Received: by 2002:aa7:ccd7:: with SMTP id y23mr5446377edt.190.1616516964259; Tue, 23 Mar 2021 09:29:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1616516964; cv=none; d=google.com; s=arc-20160816; b=I+no7qhvMgyblbm5o7Y26VBNvYFIC02ezrh3Wa+12OEOdNukixFpitEApj6kh3JiUf zWQCGGYqfdjAiAFZa+OZqGGW0A0zIK9G1LB2zoWLNouuCL9e3v7Lx4aE8wvNtBHAAumR nIYTulmyIytXwj4SMGlxd9jHa/i3FzHjSuvDI+qeruVfexaN9MMqcU24wsFBkAtA094W h1jz5zNz2efKL9Ukt8+agy781AuqGgaZrJs5gEo7f8P2piBniPC46ew2NA1ESu0zDytf 3GozAd14EN7O0D270IihLyQXNP6CHi4OMIS80HkPXwGgrVJbjuvocQ7lbaRhqL+rjWmF kNow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=n+TUDhQs/HKvv7oLd1084eWq7r5zeBMJ9NM61w6HIZ8=; b=rdHFUM3ioYSSTVbgimKyseBnN0w3tCivXHAD5FsbE34wFBI2nSAuBIADl7TqZWIYo7 b2EUJRW+vTR/56kkKEvE8cmO0F1TB4RJWgfJ1a8/sZmzRta+vZ8Vza+NT9SkMCtnaAY3 FZ9vLriUNik8SrqtfwAjfiCj5qcNhppPreGd7CBzYHaS9mXp9tDe9gq3ANdPW53th7ug UHR4jezcgfRr7UCUmLJurKkHbTL7MFac4mFMpLR3wU1t6f6k7ncfKcfUFnS8qDaBQ+9A ZAeo7ABKjs2+8QrRWrDjBrx1nOUIgN8THkU04QHRcAi0EOkcHB1THukJclyJd626oD/M nXDA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=h4tmDF26; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id hc17si14504777ejc.480.2021.03.23.09.29.01; Tue, 23 Mar 2021 09:29:24 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=h4tmDF26; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233030AbhCWQ16 (ORCPT + 99 others); Tue, 23 Mar 2021 12:27:58 -0400 Received: from mail.kernel.org ([198.145.29.99]:41922 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233117AbhCWQ1u (ORCPT ); Tue, 23 Mar 2021 12:27:50 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 10AC261477; Tue, 23 Mar 2021 16:27:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1616516870; bh=jdgaujTZa4YTW3pAKo+Bn89DEHg3n7EiLFOxCUbR6lg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=h4tmDF26uCjRSu0Ex3pUvFEydYGXVbZ/vA+Y5lSbk9NxsurbG5ieY09DytyCveQ1j wco4Y58ZSVp7VnyyCt3wZAVRFLns/BwJkOgx/WkpHf4k7MTpvPocSn8Y1hlYc8r1bB O5dDMapZ7+V9ycKnrieorBsgwLHXlNnskKy/dGobRMfvDtwbXKrg2IdRr46Q5a0L9y Tu2FzuR+oyaYmmUutMMRV5tMtraK6iu4HkVOpFsBVdkZVxRgVLhBVBX+G5s0Fatwk1 OS8paI9Dn/ndy/qC9/B+ApLwrVK9otVb23/AGq9HskHghCOubG7s4nnfDWL/G0ZWOI 2vlCV5ePdIusg== Received: by pali.im (Postfix) id A9BB392C; Tue, 23 Mar 2021 17:27:47 +0100 (CET) Date: Tue, 23 Mar 2021 17:27:47 +0100 From: Pali =?utf-8?B?Um9ow6Fy?= To: Amey Narkhede Cc: alex.williamson@redhat.com, helgaas@kernel.org, lorenzo.pieralisi@arm.com, kabel@kernel.org, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, raphael.norwitz@nutanix.com Subject: Re: How long should be PCIe card in Warm Reset state? Message-ID: <20210323162747.tscfovntsy7uk5bk@pali> References: <20210310110535.zh4pnn4vpmvzwl5q@pali> <20210323161941.gim6msj3ruu3flnf@archlinux> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20210323161941.gim6msj3ruu3flnf@archlinux> User-Agent: NeoMutt/20180716 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday 23 March 2021 21:49:41 Amey Narkhede wrote: > On 21/03/10 12:05PM, Pali Rohár wrote: > > Hello! > > > > I would like to open a question about PCIe Warm Reset. Warm Reset of > > PCIe card is triggered by asserting PERST# signal and in most cases > > PERST# signal is controlled by GPIO. > > > > Basically every native Linux PCIe controller driver is doing this Warm > > Reset of connected PCIe card during native driver initialization > > procedure. > > > > And now the important question is: How long should be PCIe card in Warm > > Reset state? After which timeout can be PERST# signal de-asserted by > > Linux controller driver? > > > > Lorenzo and Rob already expressed concerns [1] [2] that this Warm Reset > > timeout should not be driver specific and I agree with them. > > > > I have done investigation which timeout is using which native PCIe > > driver [3] and basically every driver is using different timeout. > > > > I have tried to find timeouts in PCIe specifications, I was not able to > > understand and deduce correct timeout value for Warm Reset from PCIe > > specifications. What I have found is written in my email [4]. > > > > Alex (as a "reset expert"), could you look at this issue? > > > > Or is there somebody else who understand PCIe specifications and PCIe > > diagrams to figure out what is the minimal timeout for de-asserting > > PERST# signal? > > > > There are still some issues with WiFi cards (e.g. Compex one) which > > sometimes do not appear on PCIe bus. And based on these "reset timeout > > differences" in Linux PCIe controller drivers, I suspect that it is not > > (only) the problems in WiFi cards but also in Linux PCIe controller > > drivers. In my email [3] I have written that I figured out that WLE1216 > > card needs to be in Warm Reset state for at least 10ms, otherwise card > > is not detected. > > > > [1] - https://lore.kernel.org/linux-pci/20200513115940.fiemtnxfqcyqo6ik@pali/ > > [2] - https://lore.kernel.org/linux-pci/20200507212002.GA32182@bogus/ > > [3] - https://lore.kernel.org/linux-pci/20200424092546.25p3hdtkehohe3xw@pali/ > > [4] - https://lore.kernel.org/linux-pci/20200430082245.xblvb7xeamm4e336@pali/ > > I somehow got my hands on PCIe Gen4 spec. It says on page no 555- > "When PERST# is provided to a component or adapter, this signal must be > used by the component or adapter as Fundamental Reset. > When PERST# is not provided to a component or adapter, Fundamental Reset is > generated autonomously by the component or adapter, and the details of how > this is done are outside the scope of this document." > Not sure what component/adapter means in this context. > > Then below it says- > "In some cases, it may be possible for the Fundamental Reset mechanism > to be triggered by hardware without the removal and re-application of > power to the component. This is called a warm reset. This document does > not specify a means for generating a warm reset." > > Thanks, > Amey Hello Amey, PCIe Base document does not specify how to control PERST# signal and how to issue Warm Reset. But it is documented in PCIe CEM, Mini PCIe CEM and M.2 CEM documents (maybe in some other PCIe docs too). It is needed look into more documents, "merge them in head" and then deduce final meaning...