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;
IronPort-Data: =?us-ascii?q?A9a23=3A72pbo6v79hAFZ23LkVpVEqfvEefnVN5cMUV32?=
 =?us-ascii?q?f8akzHdYApBsoF/qtZmKWqFb6zYY2SjeIgiYYzkoEgFscDXnYJnHQY4riwyR?=
 =?us-ascii?q?CNHgMeUXt7xwmUckM+xwmwvdK/shiknQoGowPscEzmN/39BDpC79SMmjfzRG?=
 =?us-ascii?q?OKlYAL5EnkZqTFMGX9JZS1Lw4bVsqYw6TSIK1vlVeHa+qUzC3f9s9JACV/43?=
 =?us-ascii?q?orYwP9ZUFsejxtD1rA2TagjUFYzDBD5BrpHTU26ByOQroW5goeHq+j/ILGRp?=
 =?us-ascii?q?gs1/j83Ad+j1738aEBPHPjZPBOFjTxdXK3Kbhpq/3NplP1kcqtHLx4K1F1ln?=
 =?us-ascii?q?PgpoDlJnZC5TwYkOrLFsO8cSBJfVSp5OMWq/ZeWcSHl6JPOlBOun3zEhq8G4?=
 =?us-ascii?q?FsNFYkZ/PtnRGJD7/oVLBgTYR2ZweG72rS2Tq9rnMtLBMXmIoIUt216wDzxE?=
 =?us-ascii?q?/krW9bATr/M6Nse2y0/7uhUGvzeJMYFQTlidhLNZ1tIIFh/IIo3mvulgnjkN?=
 =?us-ascii?q?TRetFWTpK0qy2vUyhds1LvqdtHSf7SiS99SgU+eqiTC/n/lKh4fPd2bjzGC9?=
 =?us-ascii?q?xqRakXn9c/gcJgZGLv9/flwjRjNgGcSExYRE1C8pJGEZoeFc4o3AyQpFuAG9?=
 =?us-ascii?q?MDeLHCWc+Q=3D?=
IronPort-HdrOrdr: =?us-ascii?q?A9a23=3A/94Ja6txklqy1qiBrlXxcxJT7skDTdV00z?=
 =?us-ascii?q?EX/kB9WHVpmwKj+PxGuM5rsCMc6QxhOk3I9urrBEDtex7hHNtOkO0s1NSZLW?=
 =?us-ascii?q?rbUQmTTb2KhLGKq1bd8m/FltK1vp0PT0ERMrHN5HFB/KHHCM3SKadY/DFBm5?=
 =?us-ascii?q?rY49vj8w=3D=3D?=
Date:   Fri, 16 Sep 2022 20:26:10 -0700
From:   Daniel Walker <danielwa@cisco.com>
To:     Frank Rowand <frowand.list@gmail.com>
Cc:     Pantelis Antoniou <pantelis.antoniou@konsulko.com>,
        Rob Herring <robh+dt@kernel.org>, xe-linux-external@cisco.com,
        devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] driver: of: overlay: demote message to warning
Message-ID: <20220917032610.GM4320@zorba>
References: <973f7127-8165-45f6-071f-04360046b7d7@gmail.com>
 <20220908003510.GE4320@zorba>
 <c0c66918-f55e-83e4-edea-b2d32fdb27a7@gmail.com>
 <3fcea82c-f5cf-f066-67b9-08669c44a9c6@gmail.com>
 <20220912170524.GX4320@zorba>
 <75e803f8-2b25-22c8-0831-e90d0c889da1@gmail.com>
 <20220913005153.GZ4320@zorba>
 <00850627-7ada-3a02-158c-30f3b8334d51@gmail.com>
 <20220916225646.GK4320@zorba>
 <b6a43df4-e5d8-06d2-a6b9-3626f2677161@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <b6a43df4-e5d8-06d2-a6b9-3626f2677161@gmail.com>
Precedence: bulk

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