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;
MIME-Version: 1.0
References: <1658681004-132191-1-git-send-email-john.garry@huawei.com>
 <CAK8P3a0umWWic6LAzxXJ7BACYVE--m-wbynh7Z8F+pGoUBxGTA@mail.gmail.com> <6a85baa4-80cc-a715-b5f5-fcc276d44010@huawei.com>
In-Reply-To: <6a85baa4-80cc-a715-b5f5-fcc276d44010@huawei.com>
From:   Arnd Bergmann <arnd@arndb.de>
Date:   Mon, 25 Jul 2022 09:08:22 +0200
Message-ID: <CAK8P3a2VaG1UB4pB0=9K=qfS_Mjyiiuy+ngOU4ttKMoZTQ4Tbw@mail.gmail.com>
Subject: Re: [PATCH 0/2] arm64 defconfig: Get faddr2line working
To:     John Garry <john.garry@huawei.com>
Cc:     Arnd Bergmann <arnd@arndb.de>, Will Deacon <will@kernel.org>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Linux ARM <linux-arm-kernel@lists.infradead.org>,
        Olof Johansson <olof@lixom.net>, SoC Team <soc@kernel.org>,
        jpoimboe@kernel.org,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Mon, Jul 25, 2022 at 8:50 AM John Garry <john.garry@huawei.com> wrote:
> On 24/07/2022 21:35, Arnd Bergmann wrote:
> >> Note: this is based on next-20220722 and it may be wiser to sync the
> >> defconfig manually (instead of using 1/2). Indeed I am not sure what is
> >> the policy is of sync'ing this anyway.
> > I only synchronized the 32-bit defconfig files in my tree, not the 64-bit
> > one. However, I can't really apply your patch 2/2 because you appear
> > to  mix refreshing the order of the options with changes that remove
> > options that are gone after a 'savedefconfig', risking that we miss
> > other bugs as well, as seen from your diffstat:
> >
> >   1 file changed, 36 insertions(+), 48 deletions(-)
> >
> > I have refreshed this one as well now, which on my tree gives me
> >
> >   1 file changed, 31 insertions(+), 31 deletions(-)
>
> I am not sure what you are doing in this refresh - can you share the
> steps? I guess that you sync with the savedefconfig and then manually
> edit the resultant defconfig to restore the configs which were getting
> deleting (and not just moved around).

Yes, I did it manually using vimdiff here. I had scripted this for the
arm32 defconfigs, but my script was a bit fragile so this seemed easier.

You can find my commit at
https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git/commit/?h=arm/defconfig&id=abf73c76121d8417998356a1cccfccd17f5cfd11

> > These should be checked manually to find out why savedefconfig
> > no longer shows them, it could be either a bug (a new dependency,
> > renamed option, a driver randomly selects another subsystem, etc)
> > that we need to fix, or a harmless change (driver was removed,
> > option is now intended to be default-enabled, ...)
> >
> > If you want to help more, can you check some or all of the above
> > and send patches to either re-enable the options or remove them
> > individually with explanations about why they are no longer
> > part of the savedefconfig output?
>
> ok, I can check them.

Thanks!

        Arnd