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: A9a23:Z/cuBaNYBDz9BjvvrR1Ol8FynXyQoLVcMsEvi/4bfWQNrUpz0mBSy
 DMcXjiGMvbcYjGnKN10aIvgoEsBu5HQztNkSnM5pCpnJ55oRWUpJjg4wmPYZX76whjrFRo/h
 ykmQoCcaphyFBcwnz/1WlTbhSEUOZqgG/ytU4YoBggrHVU+EHZ410o58wIEqtcAbeaRUlvlV
 eza+6UzCHf9s9KjGjtJg04rgEoHUMXa4Fv0jHRnDRx4lAO2e00uMX4qDfrZw00U7WVjNrXSq
 +7rlNlV945ClvsnIovNfr3TKiXmTlNOVOSDoiI+ZkSsvvRNjhAy3qEFFPcxVXlGgT64mYFS1
 +tmhKXlHG/FPoWU8AgcewNTHyc7Nqpc9fqYZ3O+qseUiUbBdhMAwd03UxpwZtJeq70xWD0Vn
 RAbAGhlghSri+uwwb+/VeBEjcU4J86tN4Qa0p1l5WCCVat3GM2SE80m4/dBxCsCq8JJFMr4X
 NFecyVfUgXmXRN2bwJ/5JUWxbf02SaXnydjgFaUo7cnpmve1gp81JDzP9fPPN+HX8NYmgCfv
 G2u12j0HBAROcCFxDet7H2hnKnMkDn9VYZUE6e3ntZwh1eThWAPIB4bT122pb++kEHWc8pWL
 VAZ/is166E06EutT97gdx6/pmWZuh0bHdFXFoUS5huK1aPS70CdB3MYZjFEYd0i8sQxQFQXO
 kShhdjlA3lkt6eYDC3b/baPpjT0Mi8QRYMfWcMaZTcF797dgIwesizeRN1SFv+WkePeKAill
 lhmsxMCr7kUiMcK0YCy8lbGny+gq/D1ougdu1u/soWNs14RWWK1W2C7wQOBvKofdu51WnHE7
 SZbw5LBhAwbJcvV/BFhVtnhC11ACxytCjzXgVd1E4Im8VxBEFb8INgAuVmSyKqVW/volBfza
 0PV/AhW/pIWYz2hbLR8ZMS6DMFCIUnc+TbNCKm8gjlmO8gZmOq7EMdGPhT4M4fFyxRErE3HE
 c3HGftA9F5DYUid8BK4Rv0GzZggzT0kyGXYSPjTlkr5iuHDPybOFOtfazNii9zVCovZ8G05F
 P4CZ6O3J+l3DIUSnwGOq9dIdABWRZTFLcms8Jw/mhG/zvpOQTF9VKC5LUIJcI1+lKMdjfbT4
 ny4QSdlJKnX2xX6xfGxQik7MtvHBM8nxVpiZHBEFQjzgRALP93whJrzgrNqJ9HLAsQ5k64tJ
 xTEEu3daslypsPvoW9FNMOj99IyKHxGR2umZkKYXdT2RLY4LyShxzMuVlWHGPUmZsZvifYDn
 g==
IronPort-HdrOrdr: A9a23:4xM42q2wdZKm3DocpQlwfgqjBIkkLtp133Aq2lEZdPWaSKOlfu
 SV7ZEmPH7P+VQssR4b8+xoVJPsfZqYz+8Q3WBzB8bAYOCFggqVxehZhOOI/9SjIU3DH4Vmu5
 uIHZITNDTYNykcsS4/izPIaurJB7K8gcaVuds=
Date:   Fri, 16 Sep 2022 15:56:46 -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: <20220916225646.GK4320@zorba>
References: <20220907230709.271889-1-danielwa@cisco.com>
 <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <00850627-7ada-3a02-158c-30f3b8334d51@gmail.com>
Precedence: bulk

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.

Daniel