On Fri, Sep 16, 2022 at 09:47:19PM -0500, Frank Rowand wrote: > On 9/16/22 17:56, Daniel Walker wrote: > > On Fri, Sep 16, 2022 at 05:47:54PM -0500, Frank Rowand wrote: > >>> > >>> Maybe you could add a flag or other indicator which would indicate the overlay will never be > >>> removed. Then your code could rely on this property to inform on if the author > >>> has consider the removal issues related to overlays. > >> > >> No. I guess I wasn't clear enough above, where I said: > >> > >> "And I will not accept a > >> change that suppresses the message if there is no expectation to remove the > >> overlay." > >> > >> There are multiple reasons for this, but the most fundamental is that if a > >> new overlay is not removable, then any overlay already applied can not be > >> removed (because overlays must be removed in the reverse order that they > >> are applied). It would be incredibly bad architecture to allow an overlay > >> to block another overlay from being removed. > > > > So how about an option to turn off removable overlays entirely? As far as I can > > tell it's not used currently by the tiny number of implementation I've seen. > > > > Cisco doesn't need it, and we could have a smaller kernel without it. > > > > The issue is that the error log on blast is log level abuse in my opinion. If > > there's no way to fix it, it should not be an error. > > The way to fix it is to not have a construct in the overlay that triggers the > message. In other words, do not add a property to a pre-existing node. (At > least I think that is what is the underlying cause, if I recall correctly.) > > -Frank Here's the check, if (!of_node_check_flag(target->np, OF_OVERLAY)) If the print shows when the modifications is made to a non-overlay, I'm not sure how you could construct a device tree where you only modify other overlays. It seems like this should print on the vast majority of overlays. Daniel
