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
