linux.git/arch/sh, branch v4.17

sh: switch to NO_BOOTMEM

2018-05-11T17:35:46+00:00

Commit 0fa1c579349f ("of/fdt: use memblock_virt_alloc for early alloc")
inadvertently switched the DT unflattening allocations from memblock to
bootmem which doesn't work because the unflattening happens before
bootmem is initialized. Swapping the order of bootmem init and
unflattening could also fix this, but removing bootmem is desired. So
enable NO_BOOTMEM on SH like other architectures have done.

Fixes: 0fa1c579349f ("of/fdt: use memblock_virt_alloc for early alloc")
Reported-by: Rich Felker 
Cc: Yoshinori Sato 
Signed-off-by: Rob Herring 
Signed-off-by: Rich Felker

sh: mm: Fix unprotected access to struct device

2018-05-05T20:51:46+00:00

With commit ce88313069c36eef80f21fd7 ("arch/sh: make the DMA mapping
operations observe dev->dma_pfn_offset") the generic DMA allocation
function on which the SH 'dma_alloc_coherent()' function relies on,
accesses the 'dma_pfn_offset' field of struct device.

Unfortunately the 'dma_generic_alloc_coherent()' function is called from
several places with a NULL struct device argument, halting the CPU
during the boot process.

This patch fixes the issue by protecting access to dev->dma_pfn_offset,
with a trivial check for validity. It also passes a valid 'struct device'
in the 'platform_resource_setup_memory()' function which is the main user
of 'dma_alloc_coherent()', and inserts a WARN_ON() check to remind to future
(and existing) bogus users of this function to provide a valid 'struct device'
whenever possible.

Fixes: ce88313069c36eef80f21fd7 ("arch/sh: make the DMA mapping operations observe dev->dma_pfn_offset")
Signed-off-by: Jacopo Mondi 
Reviewed-by: Geert Uytterhoeven 
Reviewed-by: Thomas Petazzoni 
Signed-off-by: Rich Felker

sh: fix build failure for J2 cpu with SMP disabled

2018-05-05T20:51:40+00:00

The sh asm/smp.h defines a fallback hard_smp_processor_id macro for
the !SMP case, but linux/smp.h never includes asm/smp.h in the !SMP
case.

Signed-off-by: Rich Felker

Merge branch 'akpm' (patches from Andrew)

2018-04-14T15:50:50+00:00

Merge yet more updates from Andrew Morton:

 - various hotfixes

 - kexec_file updates and feature work

* emailed patches from Andrew Morton : (27 commits)
  kernel/kexec_file.c: move purgatories sha256 to common code
  kernel/kexec_file.c: allow archs to set purgatory load address
  kernel/kexec_file.c: remove mis-use of sh_offset field during purgatory load
  kernel/kexec_file.c: remove unneeded variables in kexec_purgatory_setup_sechdrs
  kernel/kexec_file.c: remove unneeded for-loop in kexec_purgatory_setup_sechdrs
  kernel/kexec_file.c: split up __kexec_load_puragory
  kernel/kexec_file.c: use read-only sections in arch_kexec_apply_relocations*
  kernel/kexec_file.c: search symbols in read-only kexec_purgatory
  kernel/kexec_file.c: make purgatory_info->ehdr const
  kernel/kexec_file.c: remove checks in kexec_purgatory_load
  include/linux/kexec.h: silence compile warnings
  kexec_file, x86: move re-factored code to generic side
  x86: kexec_file: clean up prepare_elf64_headers()
  x86: kexec_file: lift CRASH_MAX_RANGES limit on crash_mem buffer
  x86: kexec_file: remove X86_64 dependency from prepare_elf64_headers()
  x86: kexec_file: purge system-ram walking from prepare_elf64_headers()
  kexec_file,x86,powerpc: factor out kexec_file_ops functions
  kexec_file: make use of purgatory optional
  proc: revalidate misc dentries
  mm, slab: reschedule cache_reap() on the same CPU
  ...

mm/gup.c: document return value

2018-04-14T00:10:27+00:00

__get_user_pages_fast handles errors differently from
get_user_pages_fast: the former always returns the number of pages
pinned, the later might return a negative error code.

Link: http://lkml.kernel.org/r/1522962072-182137-6-git-send-email-mst@redhat.com
Signed-off-by: Michael S. Tsirkin 
Reviewed-by: Andrew Morton 
Cc: Kirill A. Shutemov 
Cc: Huang Ying 
Cc: Jonathan Corbet 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Thorsten Leemhuis 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Merge tag 'sh-for-4.17' of git://git.libc.org/linux-sh

2018-04-13T19:27:11+00:00

Pull arch/sh updates from Rich Felker:
 "Fixes for bugs in futex, device tree, and userspace breakpoint traps,
  and for PCI issues on SH7786"

* tag 'sh-for-4.17' of git://git.libc.org/linux-sh:
  arch/sh: pcie-sh7786: handle non-zero DMA offset
  arch/sh: pcie-sh7786: adjust the memory mapping
  arch/sh: pcie-sh7786: adjust PCI MEM and IO regions
  arch/sh: pcie-sh7786: exclude unusable PCI MEM areas
  arch/sh: pcie-sh7786: mark unavailable PCI resource as disabled
  arch/sh: pci: don't use disabled resources
  arch/sh: make the DMA mapping operations observe dev->dma_pfn_offset
  arch/sh: add sh7786_mm_sel() function
  sh: fix debug trap failure to process signals before return to user
  sh: fix memory corruption of unflattened device tree
  sh: fix futex FUTEX_OP_SET op on userspace addresses

arch/sh: pcie-sh7786: handle non-zero DMA offset

2018-04-12T23:47:58+00:00

On SuperH, the base of the physical memory might be different from
zero. In this case, PCI address zero will map to a non-zero physical
address. In order to make sure that the DMA mapping API takes care of
this DMA offset, we must fill in the dev->dma_pfn_offset field for PCI
devices. This gets done in the pcibios_bus_add_device() hook, called
for each new PCI device detected.

The dma_pfn_offset global variable is re-calculated for every PCI
controller available on the platform, but that's not an issue because
its value will each time be exactly the same, as it only depends on
the memory start address and memory size.

Signed-off-by: Thomas Petazzoni 
Signed-off-by: Rich Felker

arch/sh: pcie-sh7786: adjust the memory mapping

2018-04-12T23:47:58+00:00

The code setting up the PCI -> SuperHighway mapping doesn't take into
account the fact that the address stored in PCIELARx must be aligned
with the size stored in PCIELAMRx.

For example, when your physical memory starts at 0x0800_0000 (128 MB),
a size of 64 MB or 128 MB is fine. However, if you have 256 MB of
memory, it doesn't work because the base address is not aligned on the
size.

In such situation, we have to round down the base address to make sure
it is aligned on the size of the area. For for a 0x0800_0000 base
address with 256 MB of memory, we will round down to 0x0, and extend
the size of the mapping to 512 MB.

This allows the mapping to work on platforms that have 256 MB of
RAM. The current setup would only work with 128 MB of RAM or less.

Signed-off-by: Thomas Petazzoni 
Signed-off-by: Rich Felker

arch/sh: pcie-sh7786: adjust PCI MEM and IO regions

2018-04-12T23:47:57+00:00

The current definition of the PCIe IO and MEM resources for SH7786
doesn't match what the datasheet says. For example, for PCIe0
0xfe100000 is advertised by the datasheet as a PCI IO region, while
0xfd000000 is advertised as a PCI MEM region. The code currently
inverts the two.

The SH4A_PCIEPARL and SH4A_PCIEPTCTLR registers allow to define the
base address and role of the different regions (including whether it's
a MEM or IO region). However, practical experience on a SH7786 shows
that if 0xfe100000 is used for LEL and 0xfd000000 for IO, a PCIe
device using two MEM BARs cannot be accessed at all. Simply using
0xfe100000 for IO and 0xfd000000 for MEM makes the PCIe device
accessible.

It is very likely that this was never seen because there are two other
PCI MEM region listed in the resources. However, for different
reasons, none of the two other MEM regions are usable on the specific
SH7786 platform the problem was encountered. Therefore, the last MEM
region at 0xfe100000 was used to place the BARs, making the device
non-functional.

This commit therefore adjusts those PCI MEM and IO resources
definitions so that they match what the datasheet says. They have only
been tested with PCIe 0.

Signed-off-by: Thomas Petazzoni 
Signed-off-by: Rich Felker

arch/sh: pcie-sh7786: exclude unusable PCI MEM areas

2018-04-12T23:47:56+00:00

Depending on the physical memory layout, some PCI MEM areas are not
usable. According to the SH7786 datasheet, the PCI MEM area from
1000_0000 to 13FF_FFFF is only usable if the physical memory layout
(in MMSELR) is 1, 2, 5 or 6. In all other configurations, this PCI MEM
area is not usable (because it overlaps with DRAM).

Therefore, this commit adjusts the PCI SH7786 initialization to mark
the relevant PCI resource as IORESOURCE_DISABLED if we can't use it.

Signed-off-by: Thomas Petazzoni 
Signed-off-by: Rich Felker