Re: [PATCH RFC 0/2] Generate device tree node for pci devicesgain,

[Frank Rowand]

On 10/14/22 12:33, Rob Herring wrote:
> On Thu, Oct 13, 2022 at 12:28 PM Frank Rowand <frowand.list@xxxxxxxxx> 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@xxxxxxxxx> 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