Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 10 May 2022 09:20:35 +0200
From:   =?UTF-8?B?Q2zDqW1lbnQgTMOpZ2Vy?= <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
Message-ID: <20220510092035.79164930@xps-bootlin>
In-Reply-To: <e6828dce-3e10-779e-4d12-67e7bdfd0f73@gmail.com>
References: <20220427094502.456111-1-clement.leger@bootlin.com>
        <96db62bb-18be-f44a-6f53-05b22319f23a@gmail.com>
        <20220509141634.16158c38@xps-bootlin>
        <f9b0cbf1-dde2-ff97-cca0-5d2895734f91@gmail.com>
        <20220509180917.0f0ae851@xps-bootlin>
        <e6828dce-3e10-779e-4d12-67e7bdfd0f73@gmail.com>
Organization: Bootlin
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

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

> > 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. =20
>=20
> 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.

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

Previous answer does rule out this one.

>=20
> >=20
> > 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). =20
>=20
> 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.

>=20
> 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.
>=20
> >  =20
> >>
> >> 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. =20
> >=20
> > 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).=20
> >=20
> > After implementing Rob's solution, the device-tree overlay really
> > seems the cleaner to me and requires much less modifications.
> >  =20
> >>
> >> More to come later as I finish reading through the various
> >> threads. =20
> >=20
> > Ok, thanks for your time ! =20
>=20
> Your welcome.  I'll keep looking deeper into the previous threads.
>=20
> -Frank
>=20
> >=20
> > Cl=C3=A9ment
> >  =20
> >>
> >> -Frank =20
> >=20
> > . =20
>=20