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:   Mon, 10 Oct 2022 10:58:58 +0200
From:   =?UTF-8?B?Q2zDqW1lbnQgTMOpZ2Vy?= <clement.leger@bootlin.com>
To:     Sonal Santan <sonal.santan@amd.com>
Cc:     Rob Herring <robh@kernel.org>,
        Frank Rowand <frowand.list@gmail.com>,
        Lizhi Hou <lizhi.hou@amd.com>, linux-pci@vger.kernel.org,
        devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
        helgaas@kernel.org, max.zhen@amd.com, larry.liu@amd.com,
        brian.xu@amd.com, stefano.stabellini@xilinx.com, trix@redhat.com,
        Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
        Alexandre Belloni <alexandre.belloni@bootlin.com>,
        "Allan.Nielsen@microchip.com" <Allan.Nielsen@microchip.com>,
        "Horatiu.Vultur@microchip.com" <Horatiu.Vultur@microchip.com>,
        "Steen.Hegelund@microchip.com" <Steen.Hegelund@microchip.com>
Subject: Re: [PATCH RFC 0/2] Generate device tree node for pci devices
Message-ID: <20221010105858.140a8e98@fixe.home>
In-Reply-To: <7f2dc633-23a2-16dc-8a55-0611e2cd6b7c@amd.com>
References: <1661809417-11370-1-git-send-email-lizhi.hou@amd.com>
        <f831f62b-004b-4f73-2a66-de9d675c44b6@gmail.com>
        <CAL_JsqJn=i=TT9NArHK25g1NkZN_G1GjN3EGEeTAvyW_PUhgcw@mail.gmail.com>
        <8ea70992-d4e9-8bbd-0fca-d5700f84e071@amd.com>
        <CAL_JsqJA8K0nKO=O2QjyHdue6=EHYNqCTw6pKUsBKwrdrYGePA@mail.gmail.com>
        <7f2dc633-23a2-16dc-8a55-0611e2cd6b7c@amd.com>
Organization: Bootlin
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Le Fri, 7 Oct 2022 15:45:17 -0700,
Sonal Santan <sonal.santan@amd.com> a =C3=A9crit :

> >> Bringing this thread back into focus. Any thoughts on how to move forw=
ard? =20
> >=20
> > Reviewers raise concerns/issues and the submitters work to address
> > them or explain why they aren't an issue. The submitter has to push
> > things forward. That's how the process works.
> >  =20

Up to now, there does not seems to be a better solution to this
problem in term of maintainability, reusability and ease of use.

Again, patching the pre-boot description (ACPI or DT) is not an option,
the user is entitled to plug the card in whatever PCI slot he wants.
This is either probbly not possible and ACPI based system and would
require a difficult setup to even try to achieve that. This would also
result in two different description to support the same device.

> We are working on updating the patch set to address the feedback. The=20
> design is still based on device tree overlay infrastructure.

Agreed, moreover saying that "the overlay support is fragile" seems to
be a shortcut to do nothing and move all the support outside of the
kernel. If buggy, then it would be better to fix this support (if there
are real problems encountered with it) or kill it by removing it
entirely if not usable (option 1 would of course be preferred).

>=20
> > As I noted, much of this is needed on a DT system with PCI device not
> > described in DT. So you could split out any ACPI system support to
> > avoid that concern for example. Enabling others to exercise these
> > patches may help too. Perhaps use QEMU to create some imaginary
> > device. =20
> To verify this patch set, in addition to a x86_64/ACPI based system, we=20
> also have an AARCH64/DT QEMU setup where we have attached a physical=20
> Alveo device. We haven't run into any ACPI or DTO issues so far.

I've been able to use the same patch set with a X86 QEMU system by
attaching my physical PCI card to it. No issues were encountered
(although the usage was rather limited). Gaining some users of this
support would allow to gather more feedback.

>=20
> Perhaps we can introduce this feature in a phased manner where we first=20
> enable DT based platforms and then enable ACPI based platforms?
>=20
> -Sonal
> >=20
> > Rob =20


--=20
Cl=C3=A9ment L=C3=A9ger,
Embedded Linux and Kernel engineer at Bootlin
https://bootlin.com