[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220917032610.GM4320@zorba>
Date: Fri, 16 Sep 2022 20:26:10 -0700
From: Daniel Walker <danielwa@...co.com>
To: Frank Rowand <frowand.list@...il.com>
Cc: Pantelis Antoniou <pantelis.antoniou@...sulko.com>,
Rob Herring <robh+dt@...nel.org>, xe-linux-external@...co.com,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] driver: of: overlay: demote message to warning
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
Powered by blists - more mailing lists