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=-2.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 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 53C64C74A26 for ; Wed, 10 Jul 2019 14:14:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 23744208E4 for ; Wed, 10 Jul 2019 14:14:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1562768081; bh=doOg+rHk2EN9esXNLf9coAoeUka6jalwXBt2NUvawdo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=w0kHyg9XZFIQr47fbO82qV75B0cH1jd2m5vyOVyVo9QmrmQWGRyj0vy/WCWZNcpAd ZH7LdZj8R7Mwd+VbKciMyY9oMFEHY/Rr7vG3ui/Uz3B/j8hGTu/zPugBw7/2k8xE6V 0+MH7woBZ3zPH+EIjotdCcXY3ItPrrr+K5Cx0tPQ= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727009AbfGJOOk (ORCPT ); Wed, 10 Jul 2019 10:14:40 -0400 Received: from mail.kernel.org ([198.145.29.99]:39430 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726957AbfGJOOk (ORCPT ); Wed, 10 Jul 2019 10:14:40 -0400 Received: from localhost (173-25-83-245.client.mchsi.com [173.25.83.245]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 9D1D12086D; Wed, 10 Jul 2019 14:14:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1562768079; bh=doOg+rHk2EN9esXNLf9coAoeUka6jalwXBt2NUvawdo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=f47oWhKvnxmeDUYzYhus0hu7jRaCo5u4QFhREAWnendTAZThMO2ePqxaAn9iglU/7 3xR//69DOv7HVWwoo6g2fR9Dc8QpzjLtPdja8sHteYZT3Hwm8+v3rKxitPLDWwj5AA fU30c2T8nrtYLZHXdsbauSDj5fgypEiH2xH8ql94= Date: Wed, 10 Jul 2019 09:14:38 -0500 From: Bjorn Helgaas To: Christoph Hellwig Cc: linux-pci@vger.kernel.org, Alex Williamson Subject: Re: reprobing BAR sizes and capabilities after a FLR? Message-ID: <20190710141438.GO128603@google.com> References: <20190709154019.GA30673@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190709154019.GA30673@infradead.org> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org [+cc Alex] On Tue, Jul 09, 2019 at 08:40:19AM -0700, Christoph Hellwig wrote: > Hi all, > > I've just been talking to some firmware developers that were a little > surprised that Linux does not reprobe BAR sizes after a FLR. I looked > at our code and we do not reprobe anything at all after a FLR. Is it > a good assumption that a devices comes back in exactly the same state > after an FLR? I am a little nervous about the fact that we don't reprobe devices after reset because the reset may cause the device to load new firmware, which may cause arbitrary changes (device type, number and size of BARs, etc). FLR is a little more restrictive than Conventional Reset, e.g., FLR must not affect the link state, so maybe it's safer to assume BAR sizes are unchanged. But I'm not at all confident about that. I mooted the idea of reprobing after reset, but that would break higher level software that isn't prepared to see hotplug-like events caused by reset, so haven't gone that direction (yet). Bjorn