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: <fbfb817c-6f09-32d0-fafc-7d37618e2886@gmail.com>
Date:   Fri, 14 Oct 2022 13:52:50 -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 devicesgain,
Content-Language: en-US
To:     Rob Herring <robh@kernel.org>
Cc:     =?UTF-8?B?Q2zDqW1lbnQgTMOpZ2Vy?= <clement.leger@bootlin.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, sonal.santan@amd.com,
        larry.liu@amd.com, brian.xu@amd.com, stefano.stabellini@xilinx.com,
        trix@redhat.com
References: <1661809417-11370-1-git-send-email-lizhi.hou@amd.com>
 <1d9faa2e-e3fc-d104-c85f-4035233848d6@gmail.com>
 <ca35a14d-501d-265e-b196-a87e1e994cd0@amd.com>
 <78211af5-171c-ef4f-a8c2-17f63dc479bc@gmail.com>
 <20221010104210.68edf825@fixe.home>
 <0d571d21-507d-fcc5-bf58-d02f958de28a@gmail.com>
 <20221013100245.14c509ec@fixe.home>
 <c427fd85-3746-bf26-e4a3-9b2aa53f6572@gmail.com>
 <CAL_Jsq+aiJbrna6kpvb9k=KWUwMH-k8_Y_W1+HkJpHyGEee7NA@mail.gmail.com>
From:   Frank Rowand <frowand.list@gmail.com>
In-Reply-To: <CAL_Jsq+aiJbrna6kpvb9k=KWUwMH-k8_Y_W1+HkJpHyGEee7NA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 10/14/22 12:33, Rob Herring wrote:
> On Thu, Oct 13, 2022 at 12:28 PM Frank Rowand <frowand.list@gmail.com> wrote:
>>
>> On 10/13/22 03:02, Clément Léger wrote:
>>> Le Thu, 13 Oct 2022 01:05:26 -0500,
>>> Frank Rowand <frowand.list@gmail.com> a écrit :
>>>
>>>>> This would also require two different descriptions of the same card
>>>>> (for ACPI and device-tree) and would require the final user to create a
>>>>> specific overlay for its device based on the PCI slots the card is
>>>>> plugged in.
>>>>
>>>> One of the many missing pieces of overlay support.  There have been several
>>>> discussion of how to describe a "socket" in a device tree that a device
>>>> could be plugged into, where a single device tree subtree .dtb could be
>>>> relocated to one or more different socket locations.  Thus in this
>>>> case a single overlay could be relocated to various PCI slots.
>>>>
>>>> I don't expect be getting involved in any future efforts around sockets
>>>> (see my following comment for why).
>>>>
>>>>>
>>>>> The solution we proposed (Lizhi and I) allows to overcome these
>>>>> problems and is way easier to use. Fixing the potential bugs that might
>>>>> exists in the overlay layer seems a way better idea that just pushing
>>>>
>>>> It is not potential bugs.  The current run time overlay implementation is
>>>> proof of concept quality and completeness.  It is not production ready.
>>>>
>>>> I got an opportunity for early retirement a couple of weeks ago.  My first
>>>> inclination was to continue the same level of device tree maintainership,
>>>> but I am quickly realizing that there are other activities that I would
>>>> like to devote my time and energy to.  I will continue to support Rob with
>>>> minor patch reviews and testing, and potentially finishing up some
>>>> improvements to unittest.  On the other hand, bringing run time overlay
>>>> support to product quality would be a major investment of my time that I
>>>> am not willing to continue.
>>>
>>> Hi Frank,
>>>
>>> This explains your position on the overlay support and I can
>>> certainly understand it ! Regarding the fact that it would enter
>>
>> No, my position on the technical aspects of overlay support is totally
>> unchanged.
>>
>> The only thing that has changed is that my time will not be available to
>> assist in future overlay related work.  The burden for this will fall
>> more on Rob than it has in the past.
> 
> s/Rob/someone that steps up to maintain the overlay code/
> 
>>> "production", the devices we are talking about are not really
>>> widespread yet? This would be a good opportunity to gather feedback
>>> early and improve the support gradually. We could probably even be able
>>> to support improvements in the overlay code if needed I guess.
>>
>> That is avoiding my point about the current implementation being
>> proof of concept.
> 


> I think it would be better to talk in terms of under what conditions
> the overlay support is adequate (for production) rather than a blanket
> statement that it is not-production ready. 

I sort of agree.  Use of run time overlays has been narrowly supported
for use by a limited set of very cautious developers in a very constrained
usage.

> A large part of it is
> really outside the code itself and related to going from static to
> dynamic DT. There are certainly issues, but dynamic DTs have been used
> in production for a very long time. However, that usage has been
> constrained.

Yes, to the dynamic DT comments.

When the run time overlay code was added the overlay code used the existing
dynamic DT code as a foundation but did not address the architectural
issues that are exposed by using the dynamic DT code in a less constrained
manner.

> 
> Rob