Suggested patches for merging

Suggested patches for merging

[John Paul Adrian Glaubitz]

Hi Rich!

After updating my SH kernel to the latest git version and applying various proposed
patches on top, my machines runs very stable. I suggest merging the following patches:

> [PATCH 01/10] sh: remove -Werror from Makefiles
> https://marc.info/?l=linux-sh&m\x159472940531658&w=2

> [PATCH 02/10] sh: sort the selects for SUPERH alphabetically
> https://marc.info/?l=linux-sh&m\x159472953631694&w=2

> [PATCH 03/10] sh: remove __KERNEL__ ifdefs from non-UAPI headers
> https://marc.info/?l=linux-sh&m\x159472967331732&w=2

> [PATCH 04/10] sh: move ioremap_fixed details out of <asm/io.h>
> https://marc.info/?l=linux-sh&m\x159472980331793&w=2

> [PATCH 05/10] sh: move the ioremap implementation out of line
> https://marc.info/?l=linux-sh&m\x159472993031837&w=2

> [PATCH 06/10] sh: don't include <asm/io_trapped.h> in <asm/io.h>
> https://marc.info/?l=linux-sh&m\x159472995331856&w=2

> [PATCH 07/10] sh: unexport register_trapped_io and match_trapped_io_handler
> https://marc.info/?l=linux-sh&m\x159472993331840&w=2

> [PATCH 08/10] dma-mapping: consolidate the NO_DMA definition in kernel/dma/Kconfig
> https://marc.info/?l=linux-sh&m\x159472994531848&w=2

> [PATCH 09/10] sh: don't allow non-coherent DMA for NOMMU
> https://marc.info/?l=linux-sh&m\x159472994631849&w=2

> [PATCH 10/10] sh: use the generic dma coherent remap allocator
> https://marc.info/?l=linux-sh&m\x159472994631850&w=2

> [PATCH] sh: Implement __get_user_u64() required for 64-bit get_user()
> https://marc.info/?l=linux-sh&m\x159186232702043&w=2

> [PATCH v2 0/9] sh: Modernize printing of kernel messages
> https://lore.kernel.org/lkml/20200617143639.18315-1-geert+renesas@glider.be/

These patches fix multiple important issues on SH, but are most likely
going in through different trees:

> [PATCH v2] serial: core: Initialise spin lock before use in uart_configure_port()
> https://lore.kernel.org/linux-serial/20200706143548.63985-1-andriy.shevchenko@linux.intel.com/

> sh: Fix unneeded constructor in page table allocation
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?idsc348f31b63d28d176ed290eb1aa2a648f3e51e
> You seem to have already picked this one up?

> sh/tlb: Fix PGTABLE_LEVELS > 2
> https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git/commit/?h=mm/tlb&id\x1f19a4bf8dcb42efc278940fb81c288c346b3eda

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Suggested patches for merging

[Rich Felker]

On Fri, Jul 17, 2020 at 09:11:49AM +0200, John Paul Adrian Glaubitz wrote:
> Hi Rich!
> 
> After updating my SH kernel to the latest git version and applying various proposed
> patches on top, my machines runs very stable. I suggest merging the following patches:
> 
> > [PATCH 01/10] sh: remove -Werror from Makefiles
> > https://marc.info/?l=linux-sh&m\x159472940531658&w=2
> 
> > [PATCH 02/10] sh: sort the selects for SUPERH alphabetically
> > https://marc.info/?l=linux-sh&m\x159472953631694&w=2
> 
> > [PATCH 03/10] sh: remove __KERNEL__ ifdefs from non-UAPI headers
> > https://marc.info/?l=linux-sh&m\x159472967331732&w=2
> 
> > [PATCH 04/10] sh: move ioremap_fixed details out of <asm/io.h>
> > https://marc.info/?l=linux-sh&m\x159472980331793&w=2
> 
> > [PATCH 05/10] sh: move the ioremap implementation out of line
> > https://marc.info/?l=linux-sh&m\x159472993031837&w=2
> 
> > [PATCH 06/10] sh: don't include <asm/io_trapped.h> in <asm/io.h>
> > https://marc.info/?l=linux-sh&m\x159472995331856&w=2
> 
> > [PATCH 07/10] sh: unexport register_trapped_io and match_trapped_io_handler
> > https://marc.info/?l=linux-sh&m\x159472993331840&w=2

All ok.

> > [PATCH 08/10] dma-mapping: consolidate the NO_DMA definition in kernel/dma/Kconfig
> > https://marc.info/?l=linux-sh&m\x159472994531848&w=2

I can't take this because it's for kernel/dma and arch/{m68k,um}, not
arch/sh. And I think the following depend on it:

> > [PATCH 09/10] sh: don't allow non-coherent DMA for NOMMU
> > https://marc.info/?l=linux-sh&m\x159472994631849&w=2
> 
> > [PATCH 10/10] sh: use the generic dma coherent remap allocator
> > https://marc.info/?l=linux-sh&m\x159472994631850&w=2

Are these needed now? If so I need the above merged by the appropriate
maintainer and then I can take these. If not I'll just defer them for
now.

> > [PATCH] sh: Implement __get_user_u64() required for 64-bit get_user()
> > https://marc.info/?l=linux-sh&m\x159186232702043&w=2

Already got this.

> > [PATCH v2 0/9] sh: Modernize printing of kernel messages
> > https://lore.kernel.org/lkml/20200617143639.18315-1-geert+renesas@glider.be/

I have these queued now.

> These patches fix multiple important issues on SH, but are most likely
> going in through different trees:
> 
> > [PATCH v2] serial: core: Initialise spin lock before use in uart_configure_port()
> > https://lore.kernel.org/linux-serial/20200706143548.63985-1-andriy.shevchenko@linux.intel.com/

Indeed this is outside scope of arch/sh.

> > sh: Fix unneeded constructor in page table allocation
> > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?idsc348f31b63d28d176ed290eb1aa2a648f3e51e
> > You seem to have already picked this one up?

Yes.

> > sh/tlb: Fix PGTABLE_LEVELS > 2
> > https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git/commit/?h=mm/tlb&id\x1f19a4bf8dcb42efc278940fb81c288c346b3eda

This last one is a fix independent of the overall series that follows
it, and since it's fixing a major regression I've picked it up. If
there's a conflict with me having it too that can be resolved in
linux-next before merge window.

Thanks for the summary and poking me to get it done.

Rich

Re: Suggested patches for merging

[John Paul Adrian Glaubitz]

Hi!

On 7/17/20 9:11 AM, John Paul Adrian Glaubitz wrote:
> After updating my SH kernel to the latest git version and applying various proposed
> patches on top, my machines runs very stable. I suggest merging the following patches:

I have collected all patches that I am currently using on my SH-7785LCR in a repository
on github, see [1].

These contain all patches by Geert, Christoph, my patch, Michael's patches and the
two fixes by Peter Zijlstra and Matthew Wilcox.

One patch by Peter Zijlstra (sh_tlb: Fix __pmd_free_tlb()) did not apply, I assume
because it must be committed with the whole series [2].

Adrian

> [1] https://github.com/glaubitz/linux/commits/sh-queue
> [2] https://marc.info/?l=linux-mm&m\x159498447020445&w=2

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Suggested patches for merging

[Rich Felker]

On Thu, Jul 23, 2020 at 02:34:31PM +0200, John Paul Adrian Glaubitz wrote:
> Hi!
> 
> On 7/17/20 9:11 AM, John Paul Adrian Glaubitz wrote:
> > After updating my SH kernel to the latest git version and applying various proposed
> > patches on top, my machines runs very stable. I suggest merging the following patches:
> 
> I have collected all patches that I am currently using on my SH-7785LCR in a repository
> on github, see [1].
> 
> These contain all patches by Geert, Christoph, my patch, Michael's patches and the
> two fixes by Peter Zijlstra and Matthew Wilcox.
> 
> One patch by Peter Zijlstra (sh_tlb: Fix __pmd_free_tlb()) did not apply, I assume
> because it must be committed with the whole series [2].
> 
> Adrian
> 
> > [1] https://github.com/glaubitz/linux/commits/sh-queue
> > [2] https://marc.info/?l=linux-mm&m\x159498447020445&w=2

Have you checked my for-next? It already has all of these except the
new seccomp series.

Rich

Re: Suggested patches for merging

[John Paul Adrian Glaubitz]

Hi Rich!

On 7/23/20 7:52 PM, Rich Felker wrote:
> Have you checked my for-next? It already has all of these except the
> new seccomp series.

I haven't checked yet as last time I did a check-out the connection
was rather slow to me.

Might be better if you get a tree on kernel.org.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Suggested patches for merging

[Rich Felker]

On Thu, Jul 23, 2020 at 07:56:24PM +0200, John Paul Adrian Glaubitz wrote:
> Hi Rich!
> 
> On 7/23/20 7:52 PM, Rich Felker wrote:
> > Have you checked my for-next? It already has all of these except the
> > new seccomp series.
> 
> I haven't checked yet as last time I did a check-out the connection
> was rather slow to me.
> 
> Might be better if you get a tree on kernel.org.

I would love to have one, and was trying to get it for years, but the
ridiculous stone-age PGP policy and flakiness of folks who said they'd
sign keys but never did has prevented it. This is 2020 and I can
easily publish a fingerprint through multiple channels I'm known
through in a way that couldn't plausibly be fake on all of them.
Getting a key trusted should not depend on meeting people in person
and trusting them to follow up with signing.

In the mean time, I recommend a "git fetch --tags" from linus's main
tree followed by pull from mine to keep the volume of the latter down.

Rich

Re: Suggested patches for merging

[John Paul Adrian Glaubitz]

On 7/23/20 8:02 PM, Rich Felker wrote:
> I would love to have one, and was trying to get it for years, but the
> ridiculous stone-age PGP policy and flakiness of folks who said they'd
> sign keys but never did has prevented it. This is 2020 and I can
> easily publish a fingerprint through multiple channels I'm known
> through in a way that couldn't plausibly be fake on all of them.
> Getting a key trusted should not depend on meeting people in person
> and trusting them to follow up with signing.

Sounds like the kernel people are using the same method that is used
within Debian which means you have a hard time if you're in a region
with few fellow kernel developers around.

> In the mean time, I recommend a "git fetch --tags" from linus's main
> tree followed by pull from mine to keep the volume of the latter down.

Good idea, thanks.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913