Re: [GIT PULL] asm-generic changes for 5.19

Re: [GIT PULL] asm-generic changes for 5.19

[Arnd Bergmann]

On Thu, May 26, 2022 at 5:00 PM Arnd Bergmann <arnd@kernel.org> wrote:
> - A series to add a generic ticket spinlock that can be shared by most
>   architectures with a working cmpxchg or ll/sc type atomic, including
>   the conversion of riscv, csky and openrisc. This series is also a
>   prerequisite for the loongarch64 architecture port that will come as
>   a separate pull request.

An update on Loongarch: I was originally planning to  send Linus a
pull request with
the branch with the contents from

https://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson.git/log/?h=loongarch-next

but I saw that this includes both the architecture code and some
device drivers (irqchip,
pci, acpi) that are essential for the kernel to actually boot. At
least the irqchip driver
has not passed review because it uses a nonstandard way to integrate into ACPI,
and the PCI stuff may or may not be ready but has no Reviewed-by or
Acked-by tags
from the maintainers. I clearly don't want to bypass the subsystem
maintainers on
those drivers by sending a pull request for the current branch.

My feeling is that there is also no point in merging a port without
the drivers as it cannot
work on any hardware. On the other hand, the libc submissions (glibc
and musl) are
currently blocked while they are waiting for the kernel port to get merged.

       Arnd

Re: [GIT PULL] asm-generic changes for 5.19

[WANG Xuerui]

On 5/29/22 19:24, Arnd Bergmann wrote:
> On Thu, May 26, 2022 at 5:00 PM Arnd Bergmann <arnd@kernel.org> wrote:
>> - A series to add a generic ticket spinlock that can be shared by most
>>    architectures with a working cmpxchg or ll/sc type atomic, including
>>    the conversion of riscv, csky and openrisc. This series is also a
>>    prerequisite for the loongarch64 architecture port that will come as
>>    a separate pull request.
> An update on Loongarch: I was originally planning to  send Linus a
> pull request with
> the branch with the contents from
>
> https://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson.git/log/?h=loongarch-next
>
> but I saw that this includes both the architecture code and some
> device drivers (irqchip,
> pci, acpi) that are essential for the kernel to actually boot. At
> least the irqchip driver
> has not passed review because it uses a nonstandard way to integrate into ACPI,
> and the PCI stuff may or may not be ready but has no Reviewed-by or
> Acked-by tags
> from the maintainers. I clearly don't want to bypass the subsystem
> maintainers on
> those drivers by sending a pull request for the current branch.
>
> My feeling is that there is also no point in merging a port without
> the drivers as it cannot
> work on any hardware. On the other hand, the libc submissions (glibc
> and musl) are
> currently blocked while they are waiting for the kernel port to get merged.

(CC-ing Jianmin Lv as he is apparently the person responsible for the 
majority of irqchip changes, which are arguably the center of the whole 
controversy; and Jiaxun Yang, author of the original Loongson MIPS IRQ 
scheme, carried over to the LoongArch era.)

Just my two cents, sorry for the wall of text following:

It's unfortunate the irqchip situation evolved to eventually block 
merging of the whole port altogether, especially the kernel ABI; but I'd 
like to point out that *the ship has already sailed*, regarding the move 
to fully dynamic IRQ topology probing.

IIUC, the necessary ACPI spec changes were already accepted even before 
the first revision of the port, back in late 2021; while I don't know if 
there's time for the responsible Loongson team to listen and amend the 
spec draft before the freeze, the end result is no change, and I was 
told that the ACPI 6.5 release is imminent (around early June). As 
everyone can see from the code, it's simply not possible to express 
fully dynamic associations between the interrupt controllers, the 
necessary reference fields for describing arbitrary graph edges are 
simply not there.

The responsible Loongson team could be hard-pressed to revise their 
tables and make it more IORT-like so as to satisfy the subsystem 
maintainer's requirement, but it'll be at least 1 year before the fixed 
ACPI 6.6 is out, and there will already be loads of boards featuring the 
fixed-topology ACPI 6.5 tables, which we have to support for a while anyway.

Yes, the Loongson teams could be (or most probably, are already) 
punished for their uncooperative attitude towards upstream reviews, by 
letting them miss the 5.19 window; the open-source community in general 
is *not* going to bend rules only for some random people's KPI and the 
kernel community is famously no exception. Reviewers always give 
suggestions out of their goodwill and previous experience, and I believe 
in this case it must be the case too; it's Loongson's fault to 
repeatedly ignore the comments after all, no matter due to ignorance, or 
language barrier (looking at the conversations, it's painfully clear to 
a native Chinese speaker that many chances to resolve 
confusion/misunderstanding have been wasted), and missing 5.19 is 
precisely that hard lesson for them.

But what for the users and downstream projects? Do the users owning 
LoongArch hardware (me included) and projects/companies porting their 
offerings have to pay for Loongson's mistakes and wait another [2mo, 
1yr], "ideally" also missing the glibc 2.36 release too?

So, being an affected end user and a distro developer, I suggest that we 
be pragmatic, and try to review the irqchip code in its current form, in 
hopes of making it into this merge window. The more elegant alternative 
is already impossible in the context of ACPI 6.5, and the current code 
is going to get in eventually anyway, unless we're ready to declare the 
ACPI 6.5 LoongArch systems deprecated and unsupported from day one, due 
to some Loongson dev being unreasonably stubborn and rejecting upstream 
reviews. In return, the Loongson devs should really lower their ego and 
consider the maintainer's advice, and ensure things are sorted out in 
ACPI 6.6; the experience behind the comment simply cannot be ignored for 
any reason.

At the very least, we should give out a clear signal for downstream 
projects, that the userspace ABI of the port can already be considered 
stable, so they could somehow move forward even if the port is not going 
to appear in 5.19. (Semi-selfishly speaking, it's arguably preferable to 
work especially hard for inclusion in 5.19, because otherwise we would 
likely miss the glibc 2.36 release, which means another 6mo of carrying 
patches downstream, and widespream patching of glibc symbol versions 
once the glibc port is changed to target 2.37 instead. It's really hard 
to teach end users to migrate such low-level thing.)

Lastly, I'd like to clarify, that this is by no means a 
passive-aggressive statement to make the community look like "the bad 
guy", or to make Loongson "look bad"; I just intend to provide a 
hopefully fresh perspective from a/an {end user, hobbyist kernel 
developer, distro developer, native Chinese speaker with a hopefully 
decent grasp of English}'s view.


And thanks for your patience,

WANG Xuerui

Re: [GIT PULL] asm-generic changes for 5.19

[Arnd Bergmann]

On Sun, May 29, 2022 at 3:10 PM WANG Xuerui <kernel@xen0n.name> wrote:
> But what for the users and downstream projects? Do the users owning
> LoongArch hardware (me included) and projects/companies porting their
> offerings have to pay for Loongson's mistakes and wait another [2mo,
> 1yr], "ideally" also missing the glibc 2.36 release too?
...
> Lastly, I'd like to clarify, that this is by no means a
> passive-aggressive statement to make the community look like "the bad
> guy", or to make Loongson "look bad"; I just intend to provide a
> hopefully fresh perspective from a/an {end user, hobbyist kernel
> developer, distro developer, native Chinese speaker with a hopefully
> decent grasp of English}'s view.

Your feedback has been extremely valuable, as always. I definitely
don't want to hold up merging the port for the glibc-2.36 release. If
that is a risk, and if merging the architecture port without the drivers
helps with that, I agree we should just do that. This will also help
with build testing and any treewide changes that are going to be
done on top of v5.19-rc1.

For the continuous maintenance, would you be available as an
additional Reviewer or co-maintainer to be listed in the maintainers
file? I think in general it is a good idea to have at least one maintainer
that is not directly part of the organization that owns the product,
and you are clearly the best person outside of loongson technology
for this.

Regarding the irqchip driver, merging those is entirely up to Marc and
Thomas. Marc already brought up the precedent of merging arch/arm64
without the required irqchip driver support, and if it turns out that he
find the latest driver submission acceptable, that might still make it in
through the irqchip tree.

        Arnd

Re: [GIT PULL] asm-generic changes for 5.19

[Huacai Chen]

Hi, Arnd,

On Mon, May 30, 2022 at 4:21 PM Arnd Bergmann <arnd@kernel.org> wrote:
>
> On Sun, May 29, 2022 at 3:10 PM WANG Xuerui <kernel@xen0n.name> wrote:
> > But what for the users and downstream projects? Do the users owning
> > LoongArch hardware (me included) and projects/companies porting their
> > offerings have to pay for Loongson's mistakes and wait another [2mo,
> > 1yr], "ideally" also missing the glibc 2.36 release too?
> ...
> > Lastly, I'd like to clarify, that this is by no means a
> > passive-aggressive statement to make the community look like "the bad
> > guy", or to make Loongson "look bad"; I just intend to provide a
> > hopefully fresh perspective from a/an {end user, hobbyist kernel
> > developer, distro developer, native Chinese speaker with a hopefully
> > decent grasp of English}'s view.
>
> Your feedback has been extremely valuable, as always. I definitely
> don't want to hold up merging the port for the glibc-2.36 release. If
> that is a risk, and if merging the architecture port without the drivers
> helps with that, I agree we should just do that. This will also help
> with build testing and any treewide changes that are going to be
> done on top of v5.19-rc1.
>
> For the continuous maintenance, would you be available as an
> additional Reviewer or co-maintainer to be listed in the maintainers
> file? I think in general it is a good idea to have at least one maintainer
> that is not directly part of the organization that owns the product,
> and you are clearly the best person outside of loongson technology
> for this.
Yes, Xuerui is very suitable as a Reviewer.

Huacai
>
> Regarding the irqchip driver, merging those is entirely up to Marc and
> Thomas. Marc already brought up the precedent of merging arch/arm64
> without the required irqchip driver support, and if it turns out that he
> find the latest driver submission acceptable, that might still make it in
> through the irqchip tree.
>
>         Arnd

Re: [GIT PULL] asm-generic changes for 5.19

[WANG Xuerui]

On 5/30/22 21:01, Huacai Chen wrote:
> Hi, Arnd,
>
> On Mon, May 30, 2022 at 4:21 PM Arnd Bergmann <arnd@kernel.org> wrote:
>> On Sun, May 29, 2022 at 3:10 PM WANG Xuerui <kernel@xen0n.name> wrote:
>>> But what for the users and downstream projects? Do the users owning
>>> LoongArch hardware (me included) and projects/companies porting their
>>> offerings have to pay for Loongson's mistakes and wait another [2mo,
>>> 1yr], "ideally" also missing the glibc 2.36 release too?
>> ...
>>> Lastly, I'd like to clarify, that this is by no means a
>>> passive-aggressive statement to make the community look like "the bad
>>> guy", or to make Loongson "look bad"; I just intend to provide a
>>> hopefully fresh perspective from a/an {end user, hobbyist kernel
>>> developer, distro developer, native Chinese speaker with a hopefully
>>> decent grasp of English}'s view.
>> Your feedback has been extremely valuable, as always. I definitely
>> don't want to hold up merging the port for the glibc-2.36 release. If
>> that is a risk, and if merging the architecture port without the drivers
>> helps with that, I agree we should just do that. This will also help
>> with build testing and any treewide changes that are going to be
>> done on top of v5.19-rc1.
>>
>> For the continuous maintenance, would you be available as an
>> additional Reviewer or co-maintainer to be listed in the maintainers
>> file? I think in general it is a good idea to have at least one maintainer
>> that is not directly part of the organization that owns the product,
>> and you are clearly the best person outside of loongson technology
>> for this.
> Yes, Xuerui is very suitable as a Reviewer.

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.

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

Re: [musl] Re: [GIT PULL] asm-generic changes for 5.19

[Arnd Bergmann]

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

Re: [musl] Re: [GIT PULL] asm-generic changes for 5.19

[Huacai Chen]

Hi, Arnd,

On Mon, May 30, 2022 at 11:56 PM Arnd Bergmann <arnd@kernel.org> wrote:
>
> 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.
OK, loongarch specific symbols will be renamed.

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

Huacai

>
>        Arnd

Re: [musl] Re: [GIT PULL] asm-generic changes for 5.19

[Arnd Bergmann]

On Tue, May 31, 2022 at 9:50 AM Huacai Chen <chenhuacai@kernel.org> wrote:
> On Mon, May 30, 2022 at 11:56 PM Arnd Bergmann <arnd@kernel.org> wrote:
> > On Mon, May 30, 2022 at 5:00 PM WANG Xuerui <kernel@xen0n.name> 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

Re: [musl] Re: [GIT PULL] asm-generic changes for 5.19

[Huacai Chen]

Hi, Arnd,

On Tue, May 31, 2022 at 4:09 PM Arnd Bergmann <arnd@kernel.org> wrote:
>
> On Tue, May 31, 2022 at 9:50 AM Huacai Chen <chenhuacai@kernel.org> wrote:
> > On Mon, May 30, 2022 at 11:56 PM Arnd Bergmann <arnd@kernel.org> wrote:
> > > On Mon, May 30, 2022 at 5:00 PM WANG Xuerui <kernel@xen0n.name> 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.
I have 3 issues:
1, swiotlb_init(1) --> swiotlb_init(true, SWIOTLB_VERBOSE);
2, the prototype of handle_kernel_image() should be changed from 5
parameters to 6 parameters;
3, the return value type of huge_ptep_get_and_clear() should be
changed from void to pte_t (and the function implementation should be
also changed).

Huacai
>
>        Arnd

Re: [musl] Re: [GIT PULL] asm-generic changes for 5.19

[Arnd Bergmann]

On Tue, May 31, 2022 at 10:17 AM Huacai Chen <chenhuacai@kernel.org> wrote:
> On Tue, May 31, 2022 at 4:09 PM Arnd Bergmann <arnd@kernel.org> wrote:
> >
> > On Tue, May 31, 2022 at 9:50 AM Huacai Chen <chenhuacai@kernel.org> wrote:
> > > On Mon, May 30, 2022 at 11:56 PM Arnd Bergmann <arnd@kernel.org> wrote:
> > > > On Mon, May 30, 2022 at 5:00 PM WANG Xuerui <kernel@xen0n.name> 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.
> I have 3 issues:
> 1, swiotlb_init(1) --> swiotlb_init(true, SWIOTLB_VERBOSE);
> 2, the prototype of handle_kernel_image() should be changed from 5
> parameters to 6 parameters;
> 3, the return value type of huge_ptep_get_and_clear() should be
> changed from void to pte_t (and the function implementation should be
> also changed).

Ok, I see. Let's stay with the base on top of a mainline snapshot then.

       Arnd

Re: [musl] Re: [GIT PULL] asm-generic changes for 5.19

[Huacai Chen]

Hi, Arnd,

On Tue, May 31, 2022 at 7:15 PM Arnd Bergmann <arnd@kernel.org> wrote:
>
> On Tue, May 31, 2022 at 10:17 AM Huacai Chen <chenhuacai@kernel.org> wrote:
> > On Tue, May 31, 2022 at 4:09 PM Arnd Bergmann <arnd@kernel.org> wrote:
> > >
> > > On Tue, May 31, 2022 at 9:50 AM Huacai Chen <chenhuacai@kernel.org> wrote:
> > > > On Mon, May 30, 2022 at 11:56 PM Arnd Bergmann <arnd@kernel.org> wrote:
> > > > > On Mon, May 30, 2022 at 5:00 PM WANG Xuerui <kernel@xen0n.name> 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.
> > I have 3 issues:
> > 1, swiotlb_init(1) --> swiotlb_init(true, SWIOTLB_VERBOSE);
> > 2, the prototype of handle_kernel_image() should be changed from 5
> > parameters to 6 parameters;
> > 3, the return value type of huge_ptep_get_and_clear() should be
> > changed from void to pte_t (and the function implementation should be
> > also changed).
>
> Ok, I see. Let's stay with the base on top of a mainline snapshot then.
https://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson.git/log/?h=loongarch-next
has been updated. Now this branch droped irqchip drivers and pci
drivers. But the existing irqchip drivers need some small adjustment
to avoid build errors [1], and I hope Marc can give an Acked-by.
Thanks.

This branch can be built with defconfig and allmodconfig (except
drivers/platform/surface/aggregator/controller.c, because it requires
8bit/16bit cmpxchg, which I was told to remove their support).

[1] https://lore.kernel.org/lkml/e7cf33a170d0b4e98e53744f60dbf922@kernel.org/T/#t

Huacai
>
>        Arnd

Re: [musl] Re: [GIT PULL] asm-generic changes for 5.19

[Arnd Bergmann]

On Tue, May 31, 2022 at 6:01 PM Huacai Chen <chenhuacai@kernel.org> wrote:
> On Tue, May 31, 2022 at 7:15 PM Arnd Bergmann <arnd@kernel.org> wrote:
> > On Tue, May 31, 2022 at 10:17 AM Huacai Chen <chenhuacai@kernel.org> wrote:

> https://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson.git/log/?h=loongarch-next
> has been updated. Now this branch droped irqchip drivers and pci
> drivers. But the existing irqchip drivers need some small adjustment
> to avoid build errors [1], and I hope Marc can give an Acked-by.

Ok, glad you got that working.

 What about the ACPI changes? I see that these are needed to get a clean build,
and as I understood it, they are supposed to get merged through the
acpica tree.

> This branch can be built with defconfig and allmodconfig (except
> drivers/platform/surface/aggregator/controller.c, because it requires
> 8bit/16bit cmpxchg, which I was told to remove their support).

Right, that is ok to keep in there, we should fix that by adding a Kconfig
dependency for the driver. It looks like it has a CONFIG_ACPI dependency,
so it is currently limited to x86/arm64/ia64, which all have the short
cmpxchg(),
but in reality this driver can only work on x86 and arm64.

       Arnd

Re: [musl] Re: [GIT PULL] asm-generic changes for 5.19

[Arnd Bergmann]

On Tue, May 31, 2022 at 10:07 PM Arnd Bergmann <arnd@kernel.org> wrote:
>
> On Tue, May 31, 2022 at 6:01 PM Huacai Chen <chenhuacai@kernel.org> wrote:
> > On Tue, May 31, 2022 at 7:15 PM Arnd Bergmann <arnd@kernel.org> wrote:
> > > On Tue, May 31, 2022 at 10:17 AM Huacai Chen <chenhuacai@kernel.org> wrote:
>
> > https://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson.git/log/?h=loongarch-next
> > has been updated. Now this branch droped irqchip drivers and pci
> > drivers. But the existing irqchip drivers need some small adjustment
> > to avoid build errors [1], and I hope Marc can give an Acked-by.
>
> Ok, glad you got that working.
>

From an allmodconfig build, I see two more things that could be addressed first:

drivers/pci/probe.c: In function 'pci_scan_bridge_extend':
drivers/pci/probe.c:1298:44: error: implicit declaration of function
'pcibios_assign_all_busses' [-Werror=implicit-function-declaration]
 1298 |         if ((secondary || subordinate) &&
!pcibios_assign_all_busses() &&
      |                                            ^~~~~~~~~~~~~~~~~~~~~~~~~
drivers/pci/setup-res.c: In function '__pci_assign_resource':
drivers/pci/setup-res.c:257:46: error: 'PCIBIOS_MIN_IO' undeclared
(first use in this function)
  257 |         min = (res->flags & IORESOURCE_IO) ? PCIBIOS_MIN_IO :
PCIBIOS_MIN_MEM;
      |                                              ^~~~~~~~~~~~~~
drivers/pci/setup-res.c:257:46: note: each undeclared identifier is
reported only once for each function it appears in
drivers/pci/setup-res.c:257:63: error: 'PCIBIOS_MIN_MEM' undeclared
(first use in this function)
  257 |         min = (res->flags & IORESOURCE_IO) ? PCIBIOS_MIN_IO :
PCIBIOS_MIN_MEM;
      |
^~~~~~~~~~~~~~~
drivers/pci/quirks.c: In function 'quirk_isa_dma_hangs':
drivers/pci/quirks.c:252:14: error: 'isa_dma_bridge_buggy' undeclared
(first use in this function)
  252 |         if (!isa_dma_bridge_buggy) {
      |              ^~~~~~~~~~~~~~~~~~~~

I think you accidentally dropped the asm/pci.h header, so adding that one back
should make it build again.


lib/test_printf.c:215: warning: "PTR" redefined
  215 | #define PTR ((void *)0xffff0123456789abUL)
      |
In file included from /git/arm-soc/arch/loongarch/include/asm/vdso/vdso.h:9,
                 from
/git/arm-soc/arch/loongarch/include/asm/vdso/gettimeofday.h:13,
                 from /git/arm-soc/include/vdso/datapage.h:137,
                 from /git/arm-soc/arch/loongarch/include/asm/vdso.h:11,
                 from /git/arm-soc/arch/loongarch/include/asm/elf.h:13,
                 from /git/arm-soc/include/linux/elf.h:6,
                 from /git/arm-soc/include/linux/module.h:19,
                 from /git/arm-soc/lib/test_printf.c:10:
/git/arm-soc/arch/loongarch/include/asm/asm.h:182: note: this is the
location of the previous definition
  182 | #define PTR             .dword
      |

Not sure what the best fix is for this, maybe the contents of asm/asm.h could
just be hidden in an "#idef __ASSEMBLER__" check. This can be a follow-up
patch when the branch is merged.

        Arnd

Re: [musl] Re: [GIT PULL] asm-generic changes for 5.19

[WANG Xuerui]

On 6/1/22 04:40, Arnd Bergmann wrote:
> lib/test_printf.c:215: warning: "PTR" redefined
>    215 | #define PTR ((void *)0xffff0123456789abUL)
>        |
> In file included from /git/arm-soc/arch/loongarch/include/asm/vdso/vdso.h:9,
>                   from
> /git/arm-soc/arch/loongarch/include/asm/vdso/gettimeofday.h:13,
>                   from /git/arm-soc/include/vdso/datapage.h:137,
>                   from /git/arm-soc/arch/loongarch/include/asm/vdso.h:11,
>                   from /git/arm-soc/arch/loongarch/include/asm/elf.h:13,
>                   from /git/arm-soc/include/linux/elf.h:6,
>                   from /git/arm-soc/include/linux/module.h:19,
>                   from /git/arm-soc/lib/test_printf.c:10:
> /git/arm-soc/arch/loongarch/include/asm/asm.h:182: note: this is the
> location of the previous definition
>    182 | #define PTR             .dword
>        |
>
> Not sure what the best fix is for this, maybe the contents of asm/asm.h could
> just be hidden in an "#idef __ASSEMBLER__" check. This can be a follow-up
> patch when the branch is merged.

Ah, the dreaded PTR... This has plagued Loongson users since antiquity 
(i.e. the MIPS era).

It must have been the case that the arch/loongarch was based on an 
earlier version of arch/mips, that didn't have the commit fa62f39dc7e25 
("MIPS: Fix build error due to PTR used in more places"). So the fix 
would be simple: just rename the PTR to something else. MIPS changed 
that to PTR_WD and maybe we could re-use that name.

But I agree that wrapping the whole asm/asm.h with an #ifdef 
__ASSEMBLY__ is very reasonable regardless. Maybe both could be done.

Re: [musl] Re: [GIT PULL] asm-generic changes for 5.19

[WANG Xuerui]

On 6/1/22 04:07, Arnd Bergmann wrote:
> On Tue, May 31, 2022 at 6:01 PM Huacai Chen <chenhuacai@kernel.org> wrote:
>> On Tue, May 31, 2022 at 7:15 PM Arnd Bergmann <arnd@kernel.org> wrote:
>>> On Tue, May 31, 2022 at 10:17 AM Huacai Chen <chenhuacai@kernel.org> wrote:
>> https://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson.git/log/?h=loongarch-next
>> has been updated. Now this branch droped irqchip drivers and pci
>> drivers. But the existing irqchip drivers need some small adjustment
>> to avoid build errors [1], and I hope Marc can give an Acked-by.
> Ok, glad you got that working.
>
>   What about the ACPI changes? I see that these are needed to get a clean build,
> and as I understood it, they are supposed to get merged through the
> acpica tree.

I think the acpica bits could be dropped with some effort too; the main 
dependency on the various ACPI 6.5 tables are the SMP bits, which relies 
on the new MADT CPUINTC tables. While the others also provide 
information, they're not as fundamental as this, and even this CPUINTC 
piece can be taken out given we can't run this branch on any real 
LoongArch hardware after all (due to the irqchip changes being backed 
out), I think we can just leave the remaining bits dummy-initialized 
with some simple comment. We can review once the new branch with only 
arch/loongarch changes is out.

>> This branch can be built with defconfig and allmodconfig (except
>> drivers/platform/surface/aggregator/controller.c, because it requires
>> 8bit/16bit cmpxchg, which I was told to remove their support).
> Right, that is ok to keep in there, we should fix that by adding a Kconfig
> dependency for the driver. It looks like it has a CONFIG_ACPI dependency,
> so it is currently limited to x86/arm64/ia64, which all have the short
> cmpxchg(),
> but in reality this driver can only work on x86 and arm64.

In case this isn't obvious to any non-native English speaker: the driver 
is written for the Microsoft Surface, which only has x86 and arm64 
variants to this date and the list is probably not going to expand in 
the foreseeable future, so the word "work" here takes a quite literal 
sense. ;-)

I agree a tiny fix for that driver could be added later that limits the 
driver to X86 || ARM64. As a popular product line, adding support for 
yet another architecture would be a news visible enough for the crowd 
that they'll come and tweak the Kconfig themselves.

Re: [musl] Re: [GIT PULL] asm-generic changes for 5.19

[WANG Xuerui]

On 6/1/22 00:01, Huacai Chen wrote:
> https://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson.git/log/?h=loongarch-next
> has been updated. Now this branch droped irqchip drivers and pci
> drivers. But the existing irqchip drivers need some small adjustment
> to avoid build errors [1], and I hope Marc can give an Acked-by.
> Thanks.
>
> This branch can be built with defconfig and allmodconfig (except
> drivers/platform/surface/aggregator/controller.c, because it requires
> 8bit/16bit cmpxchg, which I was told to remove their support).
>
> [1] https://lore.kernel.org/lkml/e7cf33a170d0b4e98e53744f60dbf922@kernel.org/T/#t

I see the loongarch-next HEAD has been updated and it's now purely arch 
changes aside from the two trivial irqchip cleanups. Some other changes 
to the v11 patchset [1] are included, but arguably minor enough to not 
invalidate previous Reviewed-by tags.

After some small tweaks:

- adding "#include <asm/irqflags.h>" to arch/loongarch/include/asm/ptrace.h,
- adding an arch/loongarch/include/uapi/asm/bpf_perf_event.h with the 
same content as arch/arm64's, and
- adding "depends on ARM64 || X86" to 
drivers/platform/surface/aggregator/Kconfig,

the current loongarch-next HEAD (commit 
36552a24f70d21b7d63d9ef490561dbdc13798d7) now passes allmodconfig build 
(with CONFIG_WERROR disabled; my Gentoo-flavored gcc-12 seems to emit 
warnings on a few drivers).

The majority of userspace ABI has been stable for a few months already, 
after the addition of orig_a0 and removal of newfstatat; the necessary 
changes to switch to statx are already reviewed [2] / merged [3], and 
have been integrated into the LoongArch port of Gentoo for a while. Eric 
looked at the v11 and gave comments, and changes were made according to 
the suggestions, but it'd probably better to get a proper Reviewed-by.

Among the rest of patches, I think maybe the EFI/boot protocol part 
still need approval/ack from the EFI maintainer. However because the 
current port isn't going to be able to run on any real hardware, maybe 
that part could be done later; I'm not sure if the unacknowledged EFI 
bits should be removed as well.

Arnd, what do you think about the current branch's status? Do Huacai 
need to send a quick final v12 to gather tags?


[1]: 
https://lore.kernel.org/all/20220518092619.1269111-1-chenhuacai@loongson.cn/
[2]: https://sourceware.org/pipermail/libc-alpha/2022-May/139127.html
[3]: https://go-review.googlesource.com/c/go/+/407694

Re: [musl] Re: [GIT PULL] asm-generic changes for 5.19

[Arnd Bergmann]

On Wed, Jun 1, 2022 at 7:52 AM WANG Xuerui <kernel@xen0n.name> wrote:
> On 6/1/22 00:01, Huacai Chen wrote:
> > https://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson.git/log/?h=loongarch-next
> > has been updated. Now this branch droped irqchip drivers and pci
> > drivers. But the existing irqchip drivers need some small adjustment
> > to avoid build errors [1], and I hope Marc can give an Acked-by.
> > Thanks.
> >
> > This branch can be built with defconfig and allmodconfig (except
> > drivers/platform/surface/aggregator/controller.c, because it requires
> > 8bit/16bit cmpxchg, which I was told to remove their support).
> >
> > [1] https://lore.kernel.org/lkml/e7cf33a170d0b4e98e53744f60dbf922@kernel.org/T/#t
>
> I see the loongarch-next HEAD has been updated and it's now purely arch
> changes aside from the two trivial irqchip cleanups. Some other changes
> to the v11 patchset [1] are included, but arguably minor enough to not
> invalidate previous Reviewed-by tags.

Very nice! I don't see exactly how the previous build bugs were addressed,
but I can confirm that this version builds. Regarding the two irqchip patches,
621e7015b529 ("irqchip/loongson-liointc: Fix build error for LoongArch") is
a good way to work around the mips oddity, and I have no problem taking
that through the asm-generic tree. The other one, f54b4a166023 ("irqchip:
 Adjust Kconfig for Loongson"), looks mostly unnecessary, and I think only
the LOONGSON_HTPIC change should be included here, while I would
leave out the COMPILE_TEST changes and instead have the driver
changes take care of making it possible to keep building it on x86, possibly
doing

        depends on MACH_LOONGSON64 || (COMPILE_TEST && ACPI)

in the future, after the loongarch64 ACPI support is merged.

> After some small tweaks:
>
> - adding "#include <asm/irqflags.h>" to arch/loongarch/include/asm/ptrace.h,
> - adding an arch/loongarch/include/uapi/asm/bpf_perf_event.h with the
> same content as arch/arm64's, and
> - adding "depends on ARM64 || X86" to
> drivers/platform/surface/aggregator/Kconfig,
>
> the current loongarch-next HEAD (commit
> 36552a24f70d21b7d63d9ef490561dbdc13798d7) now passes allmodconfig build
> (with CONFIG_WERROR disabled; my Gentoo-flavored gcc-12 seems to emit
> warnings on a few drivers).

The only one of these issues that I see is the surface aggregator one.
I think we can address all three as follow-up fixes after -rc1 if the port
gets merged and these are still required.

> The majority of userspace ABI has been stable for a few months already,
> after the addition of orig_a0 and removal of newfstatat; the necessary
> changes to switch to statx are already reviewed [2] / merged [3], and
> have been integrated into the LoongArch port of Gentoo for a while. Eric
> looked at the v11 and gave comments, and changes were made according to
> the suggestions, but it'd probably better to get a proper Reviewed-by.

Right.

> Among the rest of patches, I think maybe the EFI/boot protocol part
> still need approval/ack from the EFI maintainer. However because the
> current port isn't going to be able to run on any real hardware, maybe
> that part could be done later; I'm not sure if the unacknowledged EFI
> bits should be removed as well.

Ard, do you have any last comments on this?

> Arnd, what do you think about the current branch's status? Do Huacai
> need to send a quick final v12 to gather tags?

I think that would be good, yes.

        Arnd

Re: [musl] Re: [GIT PULL] asm-generic changes for 5.19

[Ard Biesheuvel]

On Wed, 1 Jun 2022 at 09:41, Arnd Bergmann <arnd@kernel.org> wrote:
>
> On Wed, Jun 1, 2022 at 7:52 AM WANG Xuerui <kernel@xen0n.name> wrote:
> > On 6/1/22 00:01, Huacai Chen wrote:
> > > https://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson.git/log/?h=loongarch-next
> > > has been updated. Now this branch droped irqchip drivers and pci
> > > drivers. But the existing irqchip drivers need some small adjustment
> > > to avoid build errors [1], and I hope Marc can give an Acked-by.
> > > Thanks.
> > >
> > > This branch can be built with defconfig and allmodconfig (except
> > > drivers/platform/surface/aggregator/controller.c, because it requires
> > > 8bit/16bit cmpxchg, which I was told to remove their support).
> > >
> > > [1] https://lore.kernel.org/lkml/e7cf33a170d0b4e98e53744f60dbf922@kernel.org/T/#t
> >
> > I see the loongarch-next HEAD has been updated and it's now purely arch
> > changes aside from the two trivial irqchip cleanups. Some other changes
> > to the v11 patchset [1] are included, but arguably minor enough to not
> > invalidate previous Reviewed-by tags.
>
> Very nice! I don't see exactly how the previous build bugs were addressed,
> but I can confirm that this version builds. Regarding the two irqchip patches,
> 621e7015b529 ("irqchip/loongson-liointc: Fix build error for LoongArch") is
> a good way to work around the mips oddity, and I have no problem taking
> that through the asm-generic tree. The other one, f54b4a166023 ("irqchip:
>  Adjust Kconfig for Loongson"), looks mostly unnecessary, and I think only
> the LOONGSON_HTPIC change should be included here, while I would
> leave out the COMPILE_TEST changes and instead have the driver
> changes take care of making it possible to keep building it on x86, possibly
> doing
>
>         depends on MACH_LOONGSON64 || (COMPILE_TEST && ACPI)
>
> in the future, after the loongarch64 ACPI support is merged.
>
> > After some small tweaks:
> >
> > - adding "#include <asm/irqflags.h>" to arch/loongarch/include/asm/ptrace.h,
> > - adding an arch/loongarch/include/uapi/asm/bpf_perf_event.h with the
> > same content as arch/arm64's, and
> > - adding "depends on ARM64 || X86" to
> > drivers/platform/surface/aggregator/Kconfig,
> >
> > the current loongarch-next HEAD (commit
> > 36552a24f70d21b7d63d9ef490561dbdc13798d7) now passes allmodconfig build
> > (with CONFIG_WERROR disabled; my Gentoo-flavored gcc-12 seems to emit
> > warnings on a few drivers).
>
> The only one of these issues that I see is the surface aggregator one.
> I think we can address all three as follow-up fixes after -rc1 if the port
> gets merged and these are still required.
>
> > The majority of userspace ABI has been stable for a few months already,
> > after the addition of orig_a0 and removal of newfstatat; the necessary
> > changes to switch to statx are already reviewed [2] / merged [3], and
> > have been integrated into the LoongArch port of Gentoo for a while. Eric
> > looked at the v11 and gave comments, and changes were made according to
> > the suggestions, but it'd probably better to get a proper Reviewed-by.
>
> Right.
>
> > Among the rest of patches, I think maybe the EFI/boot protocol part
> > still need approval/ack from the EFI maintainer. However because the
> > current port isn't going to be able to run on any real hardware, maybe
> > that part could be done later; I'm not sure if the unacknowledged EFI
> > bits should be removed as well.
>
> Ard, do you have any last comments on this?
>

It would be nice if the questions I raised against the previous
revision (v11) were addressed (or at least answered) first. In
general, I think this is feeling a bit rushed and IMHO we should
probably defer this to the next cycle.

Re: [musl] Re: [GIT PULL] asm-generic changes for 5.19

[WANG Xuerui]

Hi Ard,

On 6/2/22 00:01, Ard Biesheuvel wrote:
> On Wed, 1 Jun 2022 at 09:41, Arnd Bergmann <arnd@kernel.org> wrote:
>> On Wed, Jun 1, 2022 at 7:52 AM WANG Xuerui <kernel@xen0n.name> wrote:
>>> On 6/1/22 00:01, Huacai Chen wrote:
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson.git/log/?h=loongarch-next
>>>> has been updated. Now this branch droped irqchip drivers and pci
>>>> drivers. But the existing irqchip drivers need some small adjustment
>>>> to avoid build errors [1], and I hope Marc can give an Acked-by.
>>>> Thanks.
>>>>
>>>> This branch can be built with defconfig and allmodconfig (except
>>>> drivers/platform/surface/aggregator/controller.c, because it requires
>>>> 8bit/16bit cmpxchg, which I was told to remove their support).
>>>>
>>>> [1] https://lore.kernel.org/lkml/e7cf33a170d0b4e98e53744f60dbf922@kernel.org/T/#t
>>> I see the loongarch-next HEAD has been updated and it's now purely arch
>>> changes aside from the two trivial irqchip cleanups. Some other changes
>>> to the v11 patchset [1] are included, but arguably minor enough to not
>>> invalidate previous Reviewed-by tags.
>> Very nice! I don't see exactly how the previous build bugs were addressed,
>> but I can confirm that this version builds. Regarding the two irqchip patches,
>> 621e7015b529 ("irqchip/loongson-liointc: Fix build error for LoongArch") is
>> a good way to work around the mips oddity, and I have no problem taking
>> that through the asm-generic tree. The other one, f54b4a166023 ("irqchip:
>>   Adjust Kconfig for Loongson"), looks mostly unnecessary, and I think only
>> the LOONGSON_HTPIC change should be included here, while I would
>> leave out the COMPILE_TEST changes and instead have the driver
>> changes take care of making it possible to keep building it on x86, possibly
>> doing
>>
>>          depends on MACH_LOONGSON64 || (COMPILE_TEST && ACPI)
>>
>> in the future, after the loongarch64 ACPI support is merged.
>>
>>> After some small tweaks:
>>>
>>> - adding "#include <asm/irqflags.h>" to arch/loongarch/include/asm/ptrace.h,
>>> - adding an arch/loongarch/include/uapi/asm/bpf_perf_event.h with the
>>> same content as arch/arm64's, and
>>> - adding "depends on ARM64 || X86" to
>>> drivers/platform/surface/aggregator/Kconfig,
>>>
>>> the current loongarch-next HEAD (commit
>>> 36552a24f70d21b7d63d9ef490561dbdc13798d7) now passes allmodconfig build
>>> (with CONFIG_WERROR disabled; my Gentoo-flavored gcc-12 seems to emit
>>> warnings on a few drivers).
>> The only one of these issues that I see is the surface aggregator one.
>> I think we can address all three as follow-up fixes after -rc1 if the port
>> gets merged and these are still required.
>>
>>> The majority of userspace ABI has been stable for a few months already,
>>> after the addition of orig_a0 and removal of newfstatat; the necessary
>>> changes to switch to statx are already reviewed [2] / merged [3], and
>>> have been integrated into the LoongArch port of Gentoo for a while. Eric
>>> looked at the v11 and gave comments, and changes were made according to
>>> the suggestions, but it'd probably better to get a proper Reviewed-by.
>> Right.
>>
>>> Among the rest of patches, I think maybe the EFI/boot protocol part
>>> still need approval/ack from the EFI maintainer. However because the
>>> current port isn't going to be able to run on any real hardware, maybe
>>> that part could be done later; I'm not sure if the unacknowledged EFI
>>> bits should be removed as well.
>> Ard, do you have any last comments on this?
>>
> It would be nice if the questions I raised against the previous
> revision (v11) were addressed (or at least answered) first. In
> general, I think this is feeling a bit rushed and IMHO we should
> probably defer this to the next cycle.

Actually I think Huacai did reply to your review on v11: 
https://lore.kernel.org/all/CAAhV-H7KAg8RxN7M=WiOOh0fDhEKTyqrwp6V-SC0cyR0iMrdeg@mail.gmail.com/. 
It's a bit unfortunate that he probably didn't justify some of the 
approaches enough, and it's especially unfortunate that some of the 
points (like maybe the kernel version string in the EFI stub header) are 
result of their internal discussion, which I presume to be especially 
hard to change due to their particularly worrying corporate dynamics...

But again, my point is that the userspace ABI in particular is *not* 
rushed -- it has been brewing since v1 of the port which is already 
several months ago, and multiple distro-building efforts are already 
underway. We (LoongArch distro packagers) want to freeze the userspace 
ABI so that many downstream efforts wouldn't be blocked by the merging 
of kernel port.

As the boot protocol is technically not part of the userspace ABI that 
toolchains care about, and we already know it'll be a rather 
standards-compliant UEFI implementation even if this part gets dropped 
for brewing one more cycle, would taking this part out work for you?

Re: [musl] Re: [GIT PULL] asm-generic changes for 5.19

[Huacai Chen]

Hi, Ard,

On Thu, Jun 2, 2022 at 12:44 AM WANG Xuerui <kernel@xen0n.name> wrote:
>
> Hi Ard,
>
> On 6/2/22 00:01, Ard Biesheuvel wrote:
> > On Wed, 1 Jun 2022 at 09:41, Arnd Bergmann <arnd@kernel.org> wrote:
> >> On Wed, Jun 1, 2022 at 7:52 AM WANG Xuerui <kernel@xen0n.name> wrote:
> >>> On 6/1/22 00:01, Huacai Chen wrote:
> >>>> https://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson.git/log/?h=loongarch-next
> >>>> has been updated. Now this branch droped irqchip drivers and pci
> >>>> drivers. But the existing irqchip drivers need some small adjustment
> >>>> to avoid build errors [1], and I hope Marc can give an Acked-by.
> >>>> Thanks.
> >>>>
> >>>> This branch can be built with defconfig and allmodconfig (except
> >>>> drivers/platform/surface/aggregator/controller.c, because it requires
> >>>> 8bit/16bit cmpxchg, which I was told to remove their support).
> >>>>
> >>>> [1] https://lore.kernel.org/lkml/e7cf33a170d0b4e98e53744f60dbf922@kernel.org/T/#t
> >>> I see the loongarch-next HEAD has been updated and it's now purely arch
> >>> changes aside from the two trivial irqchip cleanups. Some other changes
> >>> to the v11 patchset [1] are included, but arguably minor enough to not
> >>> invalidate previous Reviewed-by tags.
> >> Very nice! I don't see exactly how the previous build bugs were addressed,
> >> but I can confirm that this version builds. Regarding the two irqchip patches,
> >> 621e7015b529 ("irqchip/loongson-liointc: Fix build error for LoongArch") is
> >> a good way to work around the mips oddity, and I have no problem taking
> >> that through the asm-generic tree. The other one, f54b4a166023 ("irqchip:
> >>   Adjust Kconfig for Loongson"), looks mostly unnecessary, and I think only
> >> the LOONGSON_HTPIC change should be included here, while I would
> >> leave out the COMPILE_TEST changes and instead have the driver
> >> changes take care of making it possible to keep building it on x86, possibly
> >> doing
> >>
> >>          depends on MACH_LOONGSON64 || (COMPILE_TEST && ACPI)
> >>
> >> in the future, after the loongarch64 ACPI support is merged.
> >>
> >>> After some small tweaks:
> >>>
> >>> - adding "#include <asm/irqflags.h>" to arch/loongarch/include/asm/ptrace.h,
> >>> - adding an arch/loongarch/include/uapi/asm/bpf_perf_event.h with the
> >>> same content as arch/arm64's, and
> >>> - adding "depends on ARM64 || X86" to
> >>> drivers/platform/surface/aggregator/Kconfig,
> >>>
> >>> the current loongarch-next HEAD (commit
> >>> 36552a24f70d21b7d63d9ef490561dbdc13798d7) now passes allmodconfig build
> >>> (with CONFIG_WERROR disabled; my Gentoo-flavored gcc-12 seems to emit
> >>> warnings on a few drivers).
> >> The only one of these issues that I see is the surface aggregator one.
> >> I think we can address all three as follow-up fixes after -rc1 if the port
> >> gets merged and these are still required.
> >>
> >>> The majority of userspace ABI has been stable for a few months already,
> >>> after the addition of orig_a0 and removal of newfstatat; the necessary
> >>> changes to switch to statx are already reviewed [2] / merged [3], and
> >>> have been integrated into the LoongArch port of Gentoo for a while. Eric
> >>> looked at the v11 and gave comments, and changes were made according to
> >>> the suggestions, but it'd probably better to get a proper Reviewed-by.
> >> Right.
> >>
> >>> Among the rest of patches, I think maybe the EFI/boot protocol part
> >>> still need approval/ack from the EFI maintainer. However because the
> >>> current port isn't going to be able to run on any real hardware, maybe
> >>> that part could be done later; I'm not sure if the unacknowledged EFI
> >>> bits should be removed as well.
> >> Ard, do you have any last comments on this?
> >>
> > It would be nice if the questions I raised against the previous
> > revision (v11) were addressed (or at least answered) first. In
> > general, I think this is feeling a bit rushed and IMHO we should
> > probably defer this to the next cycle.
>
> Actually I think Huacai did reply to your review on v11:
> https://lore.kernel.org/all/CAAhV-H7KAg8RxN7M=WiOOh0fDhEKTyqrwp6V-SC0cyR0iMrdeg@mail.gmail.com/.
> It's a bit unfortunate that he probably didn't justify some of the
> approaches enough, and it's especially unfortunate that some of the
> points (like maybe the kernel version string in the EFI stub header) are
> result of their internal discussion, which I presume to be especially
> hard to change due to their particularly worrying corporate dynamics...
I'm sorry that you haven't seen my reply, but as Xuerui said, I have
replied to your review. :)
Since you didn't reply to my answers again, I supposed that you
consider "everything is OK". :)
Now I plan to send V13, with the following changes:
1, Remove kernel_version string in efistub;
2, Remove the boardinfo knob in /sys/firmware/efi;
3, Add a reference in the commit message to explain while we need a
magic number [1].
[1] https://lists.gnu.org/archive/html/grub-devel/2021-10/msg00215.html

Huacai

>
> But again, my point is that the userspace ABI in particular is *not*
> rushed -- it has been brewing since v1 of the port which is already
> several months ago, and multiple distro-building efforts are already
> underway. We (LoongArch distro packagers) want to freeze the userspace
> ABI so that many downstream efforts wouldn't be blocked by the merging
> of kernel port.
>
> As the boot protocol is technically not part of the userspace ABI that
> toolchains care about, and we already know it'll be a rather
> standards-compliant UEFI implementation even if this part gets dropped
> for brewing one more cycle, would taking this part out work for you?
>

Re: [GIT PULL] asm-generic changes for 5.19

[Marc Zyngier]

On Sun, 29 May 2022 12:24:29 +0100,
Arnd Bergmann <arnd@kernel.org> wrote:
> 
> On Thu, May 26, 2022 at 5:00 PM Arnd Bergmann <arnd@kernel.org> wrote:
> > - A series to add a generic ticket spinlock that can be shared by most
> >   architectures with a working cmpxchg or ll/sc type atomic, including
> >   the conversion of riscv, csky and openrisc. This series is also a
> >   prerequisite for the loongarch64 architecture port that will come as
> >   a separate pull request.
>
> An update on Loongarch: I was originally planning to  send Linus a
> pull request with
> the branch with the contents from
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson.git/log/?h=loongarch-next
> 
> but I saw that this includes both the architecture code and some
> device drivers (irqchip, pci, acpi) that are essential for the
> kernel to actually boot. At least the irqchip driver has not passed
> review because it uses a nonstandard way to integrate into ACPI, and
> the PCI stuff may or may not be ready but has no Reviewed-by or
> Acked-by tags from the maintainers. I clearly don't want to bypass
> the subsystem maintainers on those drivers by sending a pull request
> for the current branch.

It seems that there is now a new contributor on the irqchip front, and
the current approach *should* be better than the "copy MIPS and run"
approach that was previously taken. I'm still to find time to review
the new series (I just came back from a week off), but hopefully next
week.

> My feeling is that there is also no point in merging a port without
> the drivers as it cannot work on any hardware. On the other hand,
> the libc submissions (glibc and musl) are currently blocked while
> they are waiting for the kernel port to get merged.

I'd tend to agree. But if on the other hand the userspace ABI is
clearly defined, I think it could make sense to go for it (if I
remember well, we merged arm64 without any support irqchip support,
and the arm64 GIC support appeared later in the game).

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

Re: [GIT PULL] asm-generic changes for 5.19

[Huacai Chen]

On Sun, May 29, 2022 at 9:21 PM Marc Zyngier <maz@kernel.org> wrote:
>
> On Sun, 29 May 2022 12:24:29 +0100,
> Arnd Bergmann <arnd@kernel.org> wrote:
> >
> > On Thu, May 26, 2022 at 5:00 PM Arnd Bergmann <arnd@kernel.org> wrote:
> > > - A series to add a generic ticket spinlock that can be shared by most
> > >   architectures with a working cmpxchg or ll/sc type atomic, including
> > >   the conversion of riscv, csky and openrisc. This series is also a
> > >   prerequisite for the loongarch64 architecture port that will come as
> > >   a separate pull request.
> >
> > An update on Loongarch: I was originally planning to  send Linus a
> > pull request with
> > the branch with the contents from
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson.git/log/?h=loongarch-next
> >
> > but I saw that this includes both the architecture code and some
> > device drivers (irqchip, pci, acpi) that are essential for the
> > kernel to actually boot. At least the irqchip driver has not passed
> > review because it uses a nonstandard way to integrate into ACPI, and
> > the PCI stuff may or may not be ready but has no Reviewed-by or
> > Acked-by tags from the maintainers. I clearly don't want to bypass
> > the subsystem maintainers on those drivers by sending a pull request
> > for the current branch.
>
> It seems that there is now a new contributor on the irqchip front, and
> the current approach *should* be better than the "copy MIPS and run"
> approach that was previously taken. I'm still to find time to review
> the new series (I just came back from a week off), but hopefully next
> week.
>
> > My feeling is that there is also no point in merging a port without
> > the drivers as it cannot work on any hardware. On the other hand,
> > the libc submissions (glibc and musl) are currently blocked while
> > they are waiting for the kernel port to get merged.
>
> I'd tend to agree. But if on the other hand the userspace ABI is
> clearly defined, I think it could make sense to go for it (if I
> remember well, we merged arm64 without any support irqchip support,
> and the arm64 GIC support appeared later in the game).
(adding linux-pci and linux-acpi maintainers to Cc)

Hi Bjorn and Rafael,

I'd like to confirm the review status of the respective LoongArch
patchsets ([1], [2]), to see if we can make it into this merge window.

Specifically:

I'd like to confirm with Bjorn, if the PCI patches are in a reasonable
shape and can get an Acked-by.

And Rafael: would you sync with the ACPICA repos to bring in the
LoongArch changes upstreamed there?

[1]: https://lore.kernel.org/linux-pci/20220430084846.3127041-1-chenhuacai@loongson.cn/T/#t
[2]: https://lore.kernel.org/linux-acpi/20220306111838.810959-1-chenhuacai@loongson.cn/T/#t

Thanks,
Huacai

>
> Thanks,
>
>         M.
>
> --
> Without deviation from the norm, progress is not possible.

Re: [musl] Re: [GIT PULL] asm-generic changes for 5.19

[Arnd Bergmann]

On Mon, May 30, 2022 at 8:28 AM Huacai Chen <chenhuacai@kernel.org> wrote:
> On Sun, May 29, 2022 at 9:21 PM Marc Zyngier <maz@kernel.org> wrote:
> > On Sun, 29 May 2022 12:24:29 +0100, Arnd Bergmann <arnd@kernel.org> wrote:
> >
> > I'd tend to agree. But if on the other hand the userspace ABI is
> > clearly defined, I think it could make sense to go for it (if I
> > remember well, we merged arm64 without any support irqchip support,
> > and the arm64 GIC support appeared later in the game).
> (adding linux-pci and linux-acpi maintainers to Cc)
>
> I'd like to confirm the review status of the respective LoongArch
> patchsets ([1], [2]), to see if we can make it into this merge window.

In the meantime, can you rebase the tree once more to split out the
driver patches and make sure the architecture port without the drivers
still builds cleanly (at least defconfig and allmodconfig) using the compiler
from [1]? If this requires additional patches, please add them on top.

Once that is done, we can ask Linus to consider merging the branch
for the architecture port, while you keep working with the pci and irqchip
maintainers to merge the drivers either for 5.19 or a future release.

While this means merging a branch that does not actually work on any
hardware by itself, it should be sufficient for the libc patches to
consider the ABI stable, and it is consistent with how we keep
CPU architecture support separate from platform driver support
elsewhere.

       Arnd

[1] https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/12.1.0/x86_64-gcc-12.1.0-nolibc-loongarch64-linux.tar.xz

Re: [GIT PULL] asm-generic changes for 5.19

[Arnd Bergmann]

On Sun, May 29, 2022 at 3:21 PM Marc Zyngier <maz@kernel.org> wrote:
> > My feeling is that there is also no point in merging a port without
> > the drivers as it cannot work on any hardware. On the other hand,
> > the libc submissions (glibc and musl) are currently blocked while
> > they are waiting for the kernel port to get merged.
>
> I'd tend to agree. But if on the other hand the userspace ABI is
> clearly defined, I think it could make sense to go for it (if I
> remember well, we merged arm64 without any support irqchip support,
> and the arm64 GIC support appeared later in the game).

Ok, thanks for taking another look. I think we should just merge the
port without the drivers then, and you can make a decision on
the irqchip drivers after you've reviewed the latest version.

      Arnd