linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Clément Léger" <clement.leger@bootlin.com>
To: Frank Rowand <frowand.list@gmail.com>
Cc: 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>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Jakub Kicinski <kuba@kernel.org>,
	Hans de Goede <hdegoede@redhat.com>, Andrew Lunn <andrew@lunn.ch>,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-pci@vger.kernel.org
Subject: Re: [PATCH 0/3] add dynamic PCI device of_node creation for overlay
Date: Tue, 10 May 2022 09:20:35 +0200	[thread overview]
Message-ID: <20220510092035.79164930@xps-bootlin> (raw)
In-Reply-To: <e6828dce-3e10-779e-4d12-67e7bdfd0f73@gmail.com>

Le Mon, 9 May 2022 15:07:18 -0500,
Frank Rowand <frowand.list@gmail.com> a écrit :

> > 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.  
> 
> Are you trying to make your card work on any ACPI based system (x86,
> x86-64, etc)?  Or do you have a specific model of computer that you
> want to make this work on for a specific customer or appliance?

There is no particular appliance/architecture targeted. This card should
work with any system that can support PCIe.

> 
> If for many arbitrary systems, can you limit it to one architecture
> or sub-architecture?

Previous answer does rule out this one.

> 
> > 
> > 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).  
> 
> Yes.  I was envisioning the pre-bootloader, bootloader, or Linux
> pre-boot shim dynamically determining the slot containing the card,
> and applying the overlay devicetree to the base devicetree,
> retargeting the overlay to the proper location, before the Linux boot.

Ok, this is however not doable on many already existing platforms since
it would require to adapt this system for whatever bootloader is
present on the platform. Moreover, AFAIK some platforms bootchain (x86)
are hardly modifiable.

> 
> The base devicetree would be for a specific type of machine or family
> of machines, just as is the case for all devicetree based systems.
> 
> >   
> >>
> >> The other big issue is mixing ACPI and devicetree on a single
> >> system. Historically, the Linux devicetree community has not been
> >> receptive to the ides of that mixture.  Your example might be a
> >> specific case where the two can be isolated from each other, or
> >> maybe not.  (For disclosure, I am essentially ACPI ignorant.)  I
> >> suspect that mixing ACPI and devicetree is a recipe for disaster
> >> in the general case.  
> > 
> > Agreed, on that fact, it did raised some eyebrows, and it was for
> > that specific concern that initially, I proposed the fwnode
> > solution. Honestly, the fwnode conversion represent a lot of work
> > (hundreds of lines easily) + requires a conversion of all the
> > subsystem that are not fwnode ready (spoiler: almost all of them
> > are not ready). 
> > 
> > After implementing Rob's solution, the device-tree overlay really
> > seems the cleaner to me and requires much less modifications.
> >   
> >>
> >> More to come later as I finish reading through the various
> >> threads.  
> > 
> > Ok, thanks for your time !  
> 
> Your welcome.  I'll keep looking deeper into the previous threads.
> 
> -Frank
> 
> > 
> > Clément
> >   
> >>
> >> -Frank  
> > 
> > .  
> 


  reply	other threads:[~2022-05-10  7:34 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
2022-05-10  7:22               ` Christoph Hellwig
2022-05-09 20:07         ` Frank Rowand
2022-05-10  7:20           ` Clément Léger [this message]
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=20220510092035.79164930@xps-bootlin \
    --to=clement.leger@bootlin.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=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 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 NNTP newsgroup(s).