linux-kernel - Re: [PATCH 2/2] ARM: configs: keystone: Remove this defconfig

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0ab47165-3ba3-4d34-aea0-9bc12fd5ff31@ti.com>
Date: Wed, 24 Jan 2024 11:31:59 -0600
From: Andrew Davis <afd@...com>
To: Nishanth Menon <nm@...com>
CC: Russell King <linux@...linux.org.uk>, Arnd Bergmann <arnd@...db.de>,
        Vignesh Raghavendra <vigneshr@...com>,
        Santosh Shilimkar
	<ssantosh@...nel.org>,
        <linux-arm-kernel@...ts.infradead.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] ARM: configs: keystone: Remove this defconfig

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@...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