All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-pci@vger.kernel.org, Alex Williamson <alex.williamson@redhat.com>
Subject: Re: reprobing BAR sizes and capabilities after a FLR?
Date: Wed, 10 Jul 2019 09:14:38 -0500	[thread overview]
Message-ID: <20190710141438.GO128603@google.com> (raw)
In-Reply-To: <20190709154019.GA30673@infradead.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

      parent reply	other threads:[~2019-07-10 14:14 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-09 15:40 reprobing BAR sizes and capabilities after a FLR? Christoph Hellwig
2019-07-09 16:27 ` Sinan Kaya
2019-07-10 14:14 ` Bjorn Helgaas [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190710141438.GO128603@google.com \
    --to=helgaas@kernel.org \
    --cc=alex.williamson@redhat.com \
    --cc=hch@infradead.org \
    --cc=linux-pci@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.