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
