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;
Message-ID: <b6a43df4-e5d8-06d2-a6b9-3626f2677161@gmail.com>
Date:   Fri, 16 Sep 2022 21:47:19 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.11.0
Subject: Re: [PATCH] driver: of: overlay: demote message to warning
Content-Language: en-US
To:     Daniel Walker <danielwa@cisco.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
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>
 <20220916225646.GK4320@zorba>
From:   Frank Rowand <frowand.list@gmail.com>
In-Reply-To: <20220916225646.GK4320@zorba>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

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

> 
> Daniel