All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andy.shevchenko@gmail.com>
To: Frank Rowand <frowand.list@gmail.com>
Cc: "Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
	"Clément Léger" <clement.leger@bootlin.com>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Pantelis Antoniou" <pantelis.antoniou@konsulko.com>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Allan Nielsen" <allan.nielsen@microchip.com>,
	"Horatiu Vultur" <horatiu.vultur@microchip.com>,
	"Steen Hegelund" <steen.hegelund@microchip.com>,
	"Thomas Petazzoni" <thomas.petazonni@bootlin.com>,
	"Alexandre Belloni" <alexandre.belloni@bootlin.com>,
	"Mark Brown" <broonie@kernel.org>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Hans de Goede" <hdegoede@redhat.com>,
	"Andrew Lunn" <andrew@lunn.ch>,
	devicetree <devicetree@vger.kernel.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	linux-pci <linux-pci@vger.kernel.org>
Subject: Re: [PATCH 0/3] add dynamic PCI device of_node creation for overlay
Date: Mon, 9 May 2022 22:40:12 +0200	[thread overview]
Message-ID: <CAHp75VedNAG4EqPkCp-mCSUNJiKPNgaJEtsHQkWimyaYh0Nueg@mail.gmail.com> (raw)
In-Reply-To: <b476913d-896d-309c-f304-3ab37b81b4a9@gmail.com>

On Mon, May 9, 2022 at 10:36 PM Frank Rowand <frowand.list@gmail.com> wrote:
>
> On 5/9/22 12:00, Andy Shevchenko wrote:
> > On Mon, May 09, 2022 at 06:09:17PM +0200, Clément Léger wrote:
> >> Le Mon, 9 May 2022 10:56:36 -0500,
> >> Frank Rowand <frowand.list@gmail.com> a écrit :
> >
> > ...
> >
> >>> On the surface, it appears that your need might be well met by having
> >>> a base devicetree that describes all of the pcie nodes, but with each
> >>> node having a status of "disabled" so that they will not be used.
> >>> Have a devicetree overlay describing the pcie card (as you proposed),
> >>> where the overlay also includes a status of "ok" for the pcie node.
> >>> Applying the overlay, with a method of redirecting the target to a
> >>> specific pcie node would change the status of the pcie node to enable
> >>> its use.  (You have already proposed a patch to modify
> >>> of_overlay_fdt_apply() to allow a modified target, so not a new
> >>> concept from me.)  My suggestion is to apply the overlay devicetree
> >>> to the base devicetree before the combined FDT devicetree is passed
> >>> to the kernel at boot.  The overlay apply could be done by several
> >>> different entities.  It could be before the bootloader executes, it
> >>> could be done by the bootloader, it could be done by a shim between
> >>> the bootloader and the kernel.  This method avoids all of the issues
> >>> of applying an overlay to a running system that I find problematic.
> >>> It is also a method used by the U-boot bootloader, as an example.
> >>
> >> Ok, that is actually possible on a system that is given a device-tree
> >> by the bootloader. But on a system that is desrcibed using ACPI (such
> >> as the x86), this is much more difficult (at least to my knowledge)...
> >> We want this feature to be easy to use for the end user. Adding such
> >> configuration which also differs between various architecture is
> >> clearly not so easy to setup.
> >>
> >> Moreover, since the PCI is meant to be "Plug and Play", such
> >> configuration would completely break that. If the user switches the
> >> PCIe card from one slot to another, the bootloader configuration will
> >> need to be modified. This seems a big no way for me (and for the user).
> >
> > The main problem here is that Linux does not support hotplugging for the
> > devices behind non-hotpluggable buses. You need to develop something to
> > say that the device tree (in terms of hardware) can morph at run-time
> > transparently to the user. I think the closest one is what FPGA does,
> > or at least should do.
>
> That is something I was not aware of yet.  Is the card in question a
> hotpluggable card?  Do the systems that you anticipate plugging the
> card into support hotplug?

Any PCIe card is potentially hotpluggable (seems nobody actually cares
in 90%+ drivers in the Linux kernel). But what I have heard in a
thread (not this one IIRC) is that the card may have pluggable modules
and it would be nice to change configuration and notify OS somehow. I
might be mistaken if it's the case here or not.

-- 
With Best Regards,
Andy Shevchenko

  reply	other threads:[~2022-05-09 20:41 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-27  9:44 [PATCH 0/3] add dynamic PCI device of_node creation for overlay Clément Léger
2022-04-27  9:45 ` [PATCH 1/3] of: always populate a root node Clément Léger
2022-05-03 13:45   ` Rob Herring
2022-05-03 15:38     ` Clément Léger
2022-05-03 17:22     ` Frank Rowand
2022-05-17  3:11     ` Frank Rowand
2022-05-17  7:37       ` Clément Léger
2022-05-17 15:03         ` Frank Rowand
2022-05-18 10:03           ` Clément Léger
2022-04-27  9:45 ` [PATCH 2/3] PCI: of: create DT nodes for PCI devices if they do not exists Clément Léger
2022-04-27 17:37   ` kernel test robot
2022-04-27 17:47   ` kernel test robot
2022-05-03 14:12   ` Rob Herring
2022-05-03 16:05     ` Clément Léger
2022-05-03 22:53   ` Bjorn Helgaas
2022-05-04 13:43     ` Clément Léger
2022-05-18 19:22       ` Lizhi Hou
2022-04-27  9:45 ` [PATCH 3/3] of: overlay: add of_overlay_fdt_apply_to_node() Clément Léger
2022-05-06 18:33 ` [PATCH 0/3] add dynamic PCI device of_node creation for overlay Frank Rowand
2022-05-09 12:16   ` Clément Léger
2022-05-09 15:56     ` Frank Rowand
2022-05-09 16:09       ` Clément Léger
2022-05-09 17:00         ` Andy Shevchenko
2022-05-09 20:11           ` Frank Rowand
2022-05-09 20:40             ` Andy Shevchenko [this message]
2022-05-10  7:22               ` Christoph Hellwig
2022-05-09 20:07         ` Frank Rowand
2022-05-10  7:20           ` Clément Léger
2022-05-09 18:36       ` Rob Herring
2022-05-09 20:35         ` Frank Rowand
2022-05-10 14:43           ` Rob Herring

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=CAHp75VedNAG4EqPkCp-mCSUNJiKPNgaJEtsHQkWimyaYh0Nueg@mail.gmail.com \
    --to=andy.shevchenko@gmail.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=allan.nielsen@microchip.com \
    --cc=andrew@lunn.ch \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=bhelgaas@google.com \
    --cc=broonie@kernel.org \
    --cc=clement.leger@bootlin.com \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --cc=hdegoede@redhat.com \
    --cc=horatiu.vultur@microchip.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=pantelis.antoniou@konsulko.com \
    --cc=robh+dt@kernel.org \
    --cc=steen.hegelund@microchip.com \
    --cc=thomas.petazonni@bootlin.com \
    /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.