linux-kernel - Re: [PATCH] ARM: samsung: Save defconfig for Exynos, S3C and S5P configs

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]

Date:   Thu, 8 Jun 2017 08:45:20 +0200
From:   Krzysztof Kozlowski <krzk@...nel.org>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Russell King <linux@...linux.org.uk>,
        Kukjin Kim <kgene@...nel.org>,
        Javier Martinez Canillas <javier@....samsung.com>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        "moderated list:ARM/SAMSUNG EXYNOS ARM ARCHITECTURES" 
        <linux-samsung-soc@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Olof Johansson <olof@...om.net>
Subject: Re: [PATCH] ARM: samsung: Save defconfig for Exynos, S3C and S5P
 configs

On Wed, Jun 07, 2017 at 09:49:58PM +0200, Arnd Bergmann wrote:
> On Wed, Jun 7, 2017 at 8:18 PM, Krzysztof Kozlowski <krzk@...nel.org> wrote:
> > Some configs for Samsung ARM SoCs were not updated for some time and
> > they still contain obsolete Kconfig entries.  Generate new defconfig for
> > all Samsung ARM architectures (Exynos, S3C24xx, S3C64xx, S5Pv210).
> >
> > Signed-off-by: Krzysztof Kozlowski <krzk@...nel.org>
> 
> Hi Krzysztof,
> 
> Updating the defconfig files is good, but I'm always a little unsure
> about loss of
> information when we do that. Would it be possible for you to split this patch
> into two halves, with one of them just reordering the entries that moved,
> and the second one removing the entries that have disappeared, with an
> explanation for why they are no longer there? That would let us see whether
> the change was intentional and avoid problems from renamed Kconfig
> symbols that are no longer enabled afterwards.

Splitting the change into two commits (reorder and removal) makes sense.
However getting the information why some things were removed, will
require more effort. I'll see what I can do.

Best regards,
Krzysztof