Received-SPF: pass (google.com: domain of linux-kernel+bounces-37440-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Message-ID: <0ab47165-3ba3-4d34-aea0-9bc12fd5ff31@ti.com>
Date: Wed, 24 Jan 2024 11:31:59 -0600
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/2] ARM: configs: keystone: Remove this defconfig
Content-Language: en-US
To: Nishanth Menon <nm@ti.com>
CC: Russell King <linux@armlinux.org.uk>, Arnd Bergmann <arnd@arndb.de>,
        Vignesh Raghavendra <vigneshr@ti.com>,
        Santosh Shilimkar
	<ssantosh@kernel.org>,
        <linux-arm-kernel@lists.infradead.org>, <linux-kernel@vger.kernel.org>
References: <20240124162857.111915-1-afd@ti.com>
 <20240124162857.111915-2-afd@ti.com>
 <20240124164116.k5ah56xvuclfkxdr@despise>
From: Andrew Davis <afd@ti.com>
In-Reply-To: <20240124164116.k5ah56xvuclfkxdr@despise>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit

On 1/24/24 10:41 AM, Nishanth Menon wrote:
> On 10:28-20240124, Andrew Davis wrote:
>> TI Keystone devices can and should use the common multi-v7 defconfig.
>> Currently it is not clear which defconfig should be used and so config
>> options for Keystone boards are added to either both defconfigs, or only
>> one or the other. As nice as it is to have a config just for this platform
>> it is a maintenance burden. As it is not used by generic distros it is not
>> very useful to continue to maintain. Remove this defconfig.
>>
>> Signed-off-by: Andrew Davis <afd@ti.com>
>> ---
>>   arch/arm/configs/keystone_defconfig | 238 ----------------------------
>>   1 file changed, 238 deletions(-)
>>   delete mode 100644 arch/arm/configs/keystone_defconfig
>>
> 
> There are a bunch of downstream folks who will have recipe fails etc if
> we do that. I am not sure we need to go down that route.
> 

That is the point of this patch, we want to stop any remaining downstream
folks from using this defconfig. It is not maintained nor updated like
the multi_v7_defconfig, any new or needed options will only be added to
multi-v7 defconfig.

> I know we had intent on multi_v7_defconfig -> but as far as I recollect,
> at least during armv7 it did'nt exactly pan out as it did on armv8.
> 

It worked for ARMv8 as it wasn't allowed go spin up custom defconfigs for
every random platform. It will work here for many/most platforms just the
same if they do what I'm doing here and remove their old unneeded defconfigs.

Andrew