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