On Mon, May 30, 2022 at 5:00 PM WANG Xuerui <kernel@xxxxxxxxxx> 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