On 14.11.2022 09:33, Wei Chen wrote: > Hi Jan, > >> -----Original Message----- >> From: Jan Beulich <jbeul...@suse.com> >> Sent: 2022年11月14日 16:23 >> To: Wei Chen <wei.c...@arm.com> >> Cc: nd <n...@arm.com>; Andrew Cooper <andrew.coop...@citrix.com>; Roger Pau >> Monné <roger....@citrix.com>; Wei Liu <w...@xen.org>; George Dunlap >> <george.dun...@citrix.com>; Julien Grall <jul...@xen.org>; Stefano >> Stabellini <sstabell...@kernel.org>; xen-devel@lists.xenproject.org >> Subject: Re: [PATCH v8 0/6] Device tree based NUMA support for Arm - >> Part#2 >> >> On 14.11.2022 09:14, Wei Chen wrote: >>> Hi Jan, >>> >>>> -----Original Message----- >>>> From: Jan Beulich <jbeul...@suse.com> >>>> Sent: 2022年11月14日 16:05 >>>> To: Wei Chen <wei.c...@arm.com> >>>> Cc: nd <n...@arm.com>; Andrew Cooper <andrew.coop...@citrix.com>; Roger >> Pau >>>> Monné <roger....@citrix.com>; Wei Liu <w...@xen.org>; George Dunlap >>>> <george.dun...@citrix.com>; Julien Grall <jul...@xen.org>; Stefano >>>> Stabellini <sstabell...@kernel.org>; xen-devel@lists.xenproject.org >>>> Subject: Re: [PATCH v8 0/6] Device tree based NUMA support for Arm - >>>> Part#2 >>>>> So in this patch series, we implement a set of NUMA API to use >>>>> device tree to describe the NUMA layout. We reuse most of the >>>>> code of x86 NUMA to create and maintain the mapping between >>>>> memory and CPU, create the matrix between any two NUMA nodes. >>>>> Except ACPI and some x86 specified code, we have moved other >>>>> code to common. In next stage, when we implement ACPI based >>>>> NUMA for Arm64, we may move the ACPI NUMA code to common too, >>>>> but in current stage, we keep it as x86 only. >>>>> >>>>> This patch serires has been tested and booted well on one >>>>> Arm64 NUMA machine and one HPE x86 NUMA machine. >>>>> >>>>> [1] https://lists.xenproject.org/archives/html/xen-devel/2022- >>>> 06/msg00499.html >>>>> [2] https://lists.xenproject.org/archives/html/xen-devel/2021- >>>> 09/msg01903.html >>>>> >>>>> --- >>>>> v7 -> v8: >>>>> 1. Rebase code to resolve merge conflict. >>>> >>>> You mention this here but not in any of the patches. Which leaves >>>> reviewers guessing where the re-base actually was: Re-bases, at >>>> least sometimes, also need (re-)reviewing. >>>> >>> >>> I just applied the v7 to the latest staging branch, this work has not >>> Generated any new change for this series. I should have described it >>> clear or not mentioned this in cover letter. Sorry for confusing you! >> >> But you talk about a merge conflict. And that's what I refer to when >> saying "may need (re-)reviewing". The same happened during earlier >> versions of the series, except there I was aware of what you needed >> to re-base over because it was changes I had done (addressing >> observations made while reviewing your changes). This time round I'm >> simply not aware of what change(s) you needed to re-base over (which >> is why I pointed out that it is generally helpful to indicate on a >> per-patch basis when non-trivial re-basing was involved). >> > > I had thought it was a code conflict before, because our internal gerrit > system marked that this series has a merge conflict. But the actual > situation is our gerrit setting policy problem. There are no code conflicts > in these patches themselves. We also did not modify the patch to resolve > the gerrit conflicts. Regardless of whether it is a new or old version, > if I modify the patch, I will remove the reviewed-by.
I'd prefer if you didn't unilaterally. Instead I'd like to suggest that you apply common sense as to whether mere re-basing might actually invalidate previously supplied tags. Jan
