Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
MIME-Version: 1.0
References: <CAK8P3a2_52JPnBWNvTTkFVwLxPAa7=NaQ4whwC1UeH_NYHeUKQ@mail.gmail.com>
 <CAK8P3a0SpU1n+29KQxzKnPRvzmDE=L0V9RUpKxhemv=74kevcQ@mail.gmail.com>
 <df5c406c-eec6-c340-2847-49670b7fe8bf@xen0n.name> <CAK8P3a3awFdB1-G65DC38NBuSTvo6SvFTaS0m9YBxunHjHjQvQ@mail.gmail.com>
 <CAAhV-H6sNr-yo8brBFtzziH6k9Tby0dFp7yehK55SfH5HjZ8hQ@mail.gmail.com> <358025d1-28e6-708b-d23d-3f22ae12a800@xen0n.name>
In-Reply-To: <358025d1-28e6-708b-d23d-3f22ae12a800@xen0n.name>
From:   Arnd Bergmann <arnd@kernel.org>
Date:   Mon, 30 May 2022 17:55:43 +0200
Message-ID: <CAK8P3a1ge2bZS13ahm_LdO3jEcbtR4w3do-gLjggKvppqnBDkw@mail.gmail.com>
Subject: Re: [musl] Re: [GIT PULL] asm-generic changes for 5.19
To:     musl@lists.openwall.com
Cc:     Huacai Chen <chenhuacai@kernel.org>,
        WANG Xuerui <kernel@xen0n.name>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        linux-arch <linux-arch@vger.kernel.org>,
        GNU C Library <libc-alpha@sourceware.org>,
        Yoshinori Sato <ysato@users.sourceforge.jp>,
        Peter Zijlstra <peterz@infradead.org>,
        Marc Zyngier <maz@kernel.org>,
        Masahiro Yamada <masahiroy@kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Jiaxun Yang <jiaxun.yang@flygoat.com>,
        ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
        Jianmin Lv <lvjianmin@loongson.cn>,
        linux-pci <linux-pci@vger.kernel.org>,
        Ard Biesheuvel <ardb@kernel.org>,
        Huacai Chen <chenhuacai@loongson.cn>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Mon, May 30, 2022 at 5:00 PM WANG Xuerui <kernel@xen0n.name> wrote:
> On 5/30/22 21:01, Huacai Chen wrote:
>
> Thanks for the recognition from both of you; it is my honor and pleasure
> to contribute to the LoongArch port and to Linux in general.
>
> As I'm still not entirely satisfied with my kernel development skills,
> plus my day job is not kernel-related nor Loongson/LoongArch-related at
> all, listing me as reviewer should be enough for now. I will take care
> of the arch as long as I have the hardware.

Thanks, sounds good to me.

> BTW, there were already several breakages when rebasing the previous
> revision (I believe it's commit 215da6d2dac0 ("MAINTAINERS: Add
> maintainer information for LoongArch")) on top of linus' tree.

Right, at least most of these should be fairly easy to address by disabling
the corresponding features. For the allmodconfig build, I see some
warnings that are introduced in gcc-12.1 across all architectures, and
those can be ignored for now.

Some of the errors already have fixes on top of the 215da6d2dac0
commit, but some of the other commits look like we should leave
them out here.

I also see some conflicts between local symbol definitions and device
drivers such as

arch/loongarch/include/asm/loongarch.h:240:29: note: previous
definition of 'csr_writel' with type 'void(u32,  u32)' {aka
'void(unsigned int,  unsigned int)'}
  240 | static __always_inline void csr_writel(u32 val, u32 reg)
      |                             ^~~~~~~~~~
drivers/media/platform/amphion/vpu_core.h:10:5: error: conflicting
types for 'csr_readl'; have 'u32(struct vpu_core *, u32)' {aka
'unsigned int(struct vpu_core *, unsigned int)'}

and

drivers/usb/cdns3/cdns3-imx.c:85: error: "PS_MASK" redefined [-Werror]

I would suggest renaming the loongarch specific symbols here, though we
may want to also change those drivers to use less generic identifiers.

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

       Arnd