From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id CB98CC433EF for ; Tue, 31 May 2022 08:09:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244734AbiEaIJv (ORCPT ); Tue, 31 May 2022 04:09:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33528 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244657AbiEaIJs (ORCPT ); Tue, 31 May 2022 04:09:48 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E184490CEC; Tue, 31 May 2022 01:09:46 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 94C53B80F96; Tue, 31 May 2022 08:09:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 49DA3C385A9; Tue, 31 May 2022 08:09:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1653984584; bh=RYpC6xoAQxlzwzTS1Q9qNjdKjQ7qaBCIuSSqtsnXLSA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=W1ConLa0fa4CSVyJdeiG/MvfrvK8aQ6HhtVkyfspn7uvFJDxNNOIcNyqLmAfKqTcO EkRa2N9Ses3HUwH4CrDat1jsce69unKSvoYkDIDQwQqnYtoinOjxy+pHTc4ukWM/Gi GOVRlheQSO57/Tfw11+rtubK4AoEvwzXLi0INwbCbZbBw6BfB36JcBDvgoN7LldXtf NdYwbo7NuSILBQsj8f6cGY4crptgEmSZsDjcPGqb7FJfJ3K5fl4hjDqQpW8Tlzz6eL iwvdFbfphy0PmCw+MbzVQa9ctwRLaqQAQQRLZcBzWeTrH04N/d0Kq3dpFN0Xp8kZXt 9ru/+Z/QAH3wg== Received: by mail-yw1-f171.google.com with SMTP id 00721157ae682-3043b3f7d8fso120808117b3.8; Tue, 31 May 2022 01:09:44 -0700 (PDT) X-Gm-Message-State: AOAM533M6MX1rKOBrp9iTr/VHuG+iBY99xXLp1BcRLbH8YHXV0r+MgNf LfoEK5cZG+amFsMYMNlcMduHoBHrzR46Vle5UtA= X-Google-Smtp-Source: ABdhPJyhJog8azsioErC+i5PlBgcKzbEGCvn4zseszGYzoUs1FVRvYrMO45NFlB3l1wsrjJ5hIWZQ9m0KHU6vN1LfV8= X-Received: by 2002:a81:28b:0:b0:30c:5e57:fac3 with SMTP id 133-20020a81028b000000b0030c5e57fac3mr8140757ywc.249.1653984583406; Tue, 31 May 2022 01:09:43 -0700 (PDT) MIME-Version: 1.0 References: <358025d1-28e6-708b-d23d-3f22ae12a800@xen0n.name> In-Reply-To: From: Arnd Bergmann Date: Tue, 31 May 2022 10:09:26 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [musl] Re: [GIT PULL] asm-generic changes for 5.19 To: Huacai Chen Cc: musl@lists.openwall.com, WANG Xuerui , Linus Torvalds , linux-arch , GNU C Library , Yoshinori Sato , Peter Zijlstra , Marc Zyngier , Masahiro Yamada , Linux Kernel Mailing List , Jiaxun Yang , ACPI Devel Maling List , Jianmin Lv , linux-pci , Ard Biesheuvel , Huacai Chen Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 31, 2022 at 9:50 AM Huacai Chen wrote: > On Mon, May 30, 2022 at 11:56 PM Arnd Bergmann wrote: > > On Mon, May 30, 2022 at 5:00 PM WANG Xuerui wrote: > > > Now I see > > > the loongarch-next HEAD is already rebased on top of what I believe to > > > be the current main branch, however I vaguely remember that it's not > > > good to base one's patches on top of "some random commit", so I wonder > > > whether the current branch state is appropriate for a PR? > > > > You are correct, a pull request should always be based on an -rc, orat least > > have the minimum set of dependencies. The branch was previously > > based on top of the spinlock implementation, which is still the best > > place to start here. > I have a difficult problem to select the base. Take swiotlb_init() as > an example: If I select 5.18-rc1, I should use swiotlb_init(1); if I > select Linus' latest tree, I should use swiotlb_init(true, > SWIOTLB_VERBOSE). However, if I select 5.18-rc1, linux-next will have > a build error because the code there expect swiotlb_init(true, > SWIOTLB_VERBOSE). Ok, I see. This is the kind of thing we normally prevent by having everything in linux-next for a few weeks before the merge window. How many issues like this are you aware of? If it's just the swiotlb, you could try merging the swiotlb branch that is in mainline now on top of the spinlock branch, and still get a minimum set of dependencies. If there are many more, then basing on top of the current mainline is probably less intrusive after all. Arnd