linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Eric Pilmore <epilmore@gigaio.com>
Cc: Matthew Dharm <mdharm-usb@one-eyed-alien.net>,
	Konstantin Ryabitsev <konstantin@linuxfoundation.org>,
	linux-hotplug@vger.kernel.org, D Meyer <dmeyer@gigaio.com>
Subject: Re: PSA: migrating linux-hotplug to new vger infrastructure
Date: Tue, 7 Nov 2023 07:00:57 +0100	[thread overview]
Message-ID: <2023110751-repave-crewless-5775@gregkh> (raw)
In-Reply-To: <CAOQPn8uhcVP4PR353GdJoEqUbF1CBHgKsvmtLMpgS5V=+G+kOw@mail.gmail.com>

On Mon, Nov 06, 2023 at 09:12:56PM -0800, Eric Pilmore wrote:
> On Mon, Nov 6, 2023 at 12:46 PM Matthew Dharm
> <mdharm-usb@one-eyed-alien.net> wrote:
> >
> >
> > Special MMIO reservation in BIOS is not required if a device in your
> > PCIe tree, such as a Broadcom Gen4 or Gen5 switch device, can reserve
> > address space via "synthetic mode" for missing devices.
> >
> > Matt
> 
> Yes, I'm familiar with Synthetic Mode (or Synthetic Endpoints), but
> that's simply creating a dummy device to fool the BIOS into
> effectively putting aside some amount of MMIO space. And that works
> great so long as what you want to dynamically add fits within that
> reserved space. I guess I was looking for something more flexible
> where I didn't need to know a priori the "size" of what I wanted to
> add in. Presumably this would require some kind of rebalancing of the
> address assignments within the PCIe tree/sub-tree, which in turn
> likely means temporarily "suspending" I/O activity, at least across
> some portion of the I/O tree, while addresses move around.

No, that is not something that Linux supports at this time.  I also
don't think that any other operating system supports it either, right?

We always said, if someone wants to support this, great, we will be glad
to review the patches for adding this type of functionality.  But until
then, we just rely on the BIOS or other types of hardware to handle this
properly for us.

thanks,

greg k-h

      reply	other threads:[~2023-11-07  6:01 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-06 13:21 PSA: migrating linux-hotplug to new vger infrastructure Konstantin Ryabitsev
2023-11-06 13:33 ` Greg KH
2023-11-06 14:29   ` Konstantin Ryabitsev
2023-11-06 16:35     ` Greg KH
2023-11-06 19:05   ` Eric Pilmore
2023-11-06 19:25     ` Greg KH
2023-11-06 20:46       ` Matthew Dharm
2023-11-07  5:12         ` Eric Pilmore
2023-11-07  6:00           ` Greg KH [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=2023110751-repave-crewless-5775@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=dmeyer@gigaio.com \
    --cc=epilmore@gigaio.com \
    --cc=konstantin@linuxfoundation.org \
    --cc=linux-hotplug@vger.kernel.org \
    --cc=mdharm-usb@one-eyed-alien.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).