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;
Message-ID: <a616f56c-60c7-ff7f-4a3c-a5d36d692a15@gmail.com>
Date:   Thu, 13 Oct 2022 01:08:10 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.11.0
Subject: Re: [PATCH RFC 0/2] Generate device tree node for pci devices
Content-Language: en-US
To:     =?UTF-8?B?Q2zDqW1lbnQgTMOpZ2Vy?= <clement.leger@bootlin.com>,
        Sonal Santan <sonal.santan@amd.com>
Cc:     Rob Herring <robh@kernel.org>, 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>
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>
 <20221010105858.140a8e98@fixe.home>
From:   Frank Rowand <frowand.list@gmail.com>
In-Reply-To: <20221010105858.140a8e98@fixe.home>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 10/10/22 03:58, Clément Léger wrote:
> Le Fri, 7 Oct 2022 15:45:17 -0700,
> Sonal Santan <sonal.santan@amd.com> a écrit :
> 
>>>> Bringing this thread back into focus. Any thoughts on how to move forward?  
>>>
>>> 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.
>>>   
> 
> 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 
>> 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).

"Buggy" is true, but not an adequate description.  See my other reply in
this thread a couple of minutes ago regarding "proof of concept".

Rob has suggested removing it at least a couple of times this year.

-Frank

> 
>>
>>> 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.  
>> To verify this patch set, in addition to a x86_64/ACPI based system, we 
>> also have an AARCH64/DT QEMU setup where we have attached a physical 
>> 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.
> 
>>
>> Perhaps we can introduce this feature in a phased manner where we first 
>> enable DT based platforms and then enable ACPI based platforms?
>>
>> -Sonal
>>>
>>> Rob  
> 
>