linux-toradex.git/arch/xtensa/kernel, branch v4.4.58

xtensa: move parse_tag_fdt out of #ifdef CONFIG_BLK_DEV_INITRD

2017-03-15T01:57:14+00:00

commit 4ab18701c66552944188dbcd0ce0012729baab84 upstream.

FDT tag parsing is not related to whether BLK_DEV_INITRD is configured
or not, move it out of the corresponding #ifdef/#endif block.
This fixes passing external FDT to the kernel configured w/o
BLK_DEV_INITRD support.

Signed-off-by: Max Filippov 
Signed-off-by: Greg Kroah-Hartman

xtensa: clear all DBREAKC registers on start

2016-04-12T16:08:55+00:00

commit 7de7ac785ae18a2cdc78d7560f48e3213d9ea0ab upstream.

There are XCHAL_NUM_DBREAK registers, clear them all.
This also fixes cryptic assembler error message with binutils 2.25 when
XCHAL_NUM_DBREAK is 0:

  as: out of memory allocating 18446744073709551575 bytes after a total
  of 495616 bytes

Signed-off-by: Max Filippov 
Signed-off-by: Greg Kroah-Hartman

Merge tag 'xtensa-20151108' of git://github.com/czankel/xtensa-linux

2015-11-10T00:32:13+00:00

Pull xtensa updates from Chris Zankel:

 - fix remaining issues with noMMU cores
 - fix build for cores w/o cache or zero overhead loop options
 - fix boot of secondary cores in SMP configuration
 - add support for DMA to high memory pages
 - add dma_to_phys and phys_to_dma functions.

* tag 'xtensa-20151108' of git://github.com/czankel/xtensa-linux:
  xtensa: implement dma_to_phys and phys_to_dma
  xtensa: support DMA to high memory
  Revert "xtensa: cache inquiry and unaligned cache handling functions"
  xtensa: drop unused sections and remapped reset handlers
  xtensa: fix secondary core boot in SMP
  xtensa: add FORCE_MAX_ZONEORDER to Kconfig
  xtensa: nommu: provide defconfig for de212 on kc705
  xtensa: nommu: xtfpga: add kc705 DTS
  xtensa: add de212 core variant
  xtensa: nommu: select HAVE_FUTEX_CMPXCHG
  xtensa: nommu: fix default memory start address
  xtensa: nommu: provide correct KIO addresses
  xtensa: nommu: fix USER_RING definition
  xtensa: xtfpga: fix integer overflow in TASK_SIZE
  xtensa: fix build for configs without cache options
  xtensa: fixes for configs without loop option

xtensa: support DMA to high memory

2015-11-08T22:25:37+00:00

- don't bugcheck if high memory page is passed to xtensa_map_page;
- turn empty dcache flush macros into functions so that they could be
  passed as function parameters;
- use kmap_atomic to map high memory pages for cache invalidation/
  flushing performed by xtensa_sync_single_for_{cpu,device}.

Signed-off-by: Max Filippov

xtensa: drop unused sections and remapped reset handlers

2015-11-03T14:19:39+00:00

There are no .bootstrap or .ResetVector.text sections linked to the
vmlinux image, drop these sections from vmlinux.ld.S. Drop
RESET_VECTOR_VADDR definition only used for .ResetVector.text.

Drop remapped copies of primary and secondary reset vectors, as modern
gdb don't have problems stepping through instructions at arbitrary
locations. Drop corresponding sections from the corresponding linker
scripts.

Signed-off-by: Max Filippov

xtensa: fix secondary core boot in SMP

2015-11-03T14:19:38+00:00

There are multiple factors adding to the issue in different
configurations:

- commit 17290231df16eeee ("xtensa: add fixup for double exception raised
  in window overflow") added function window_overflow_restore_a0_fixup to
  double exception vector overlapping reset vector location of secondary
  processor cores.
- on MMUv2 cores RESET_VECTOR1_VADDR may point to uncached kernel memory
  making code overlapping depend on cache type and size, so that without
  cache or with WT cache reset vector code overwrites double exception
  code, making issue even harder to detect.
- on MMUv3 cores RESET_VECTOR1_VADDR may point to unmapped area, as
  MMUv3 cores change virtual address map to match MMUv2 layout, but
  reset vector virtual address is given for the original MMUv3 mapping.
- physical memory region of the secondary reset vector is not reserved
  in the physical memory map, and thus may be allocated and overwritten
  at arbitrary moment.

Fix it as follows:

- move window_overflow_restore_a0_fixup code to .text section.
- define RESET_VECTOR1_VADDR so that it points to reset vector in the
  cacheable MMUv2 map for cores with MMU.
- reserve reset vector region in the physical memory map. Drop separate
  literal section and build mxhead.S with text section literals.

Cc: 
Signed-off-by: Max Filippov

xtensa: nommu: provide correct KIO addresses

2015-11-02T15:03:02+00:00

KIO region location is different for noMMU cores. Provide different
default physical address and make KIO virtual address equal to physical.

Move xtensa_get_kio_paddr function close to XCHAL_KIO_PADDR definition
and define it not only for MMUv3, but for all MMU options except MMUv2.

Signed-off-by: Max Filippov

xtensa: fixes for configs without loop option

2015-11-02T15:02:47+00:00

Build-time fixes:
- make lbeg/lend/lcount save/restore conditional on kernel entry;
- don't clear lcount in platform_restart functions unconditionally.

Run-time fixes:
- use correct end of range register in __endla paired with __loopt, not
  the unused temporary register. This fixes .bss zero-initialization.
  Update comments in asmmacro.h;
- don't clobber a10 in the usercopy that leads to access to unmapped
  memory.

Cc: 
Signed-off-by: Max Filippov

clocksource: cosmetic: Drop OF 'dependency' from symbols

2015-10-01T00:18:39+00:00

Seeing the 'of' characters in a symbol that is being called from
ACPI seems to freak out people. So let's do a bit of pointless
renaming so that these folks do feel at home.

Signed-off-by: Marc Zyngier 
Acked-by: Catalin Marinas 
Reviewed-by: Hanjun Guo 
Acked-by: Thomas Gleixner 
Tested-by: Hanjun Guo 
Signed-off-by: Rafael J. Wysocki

PCI: Revert "PCI: Call pci_read_bridge_bases() from core instead of arch code"

2015-09-15T18:18:04+00:00

Revert dff22d2054b5 ("PCI: Call pci_read_bridge_bases() from core instead
of arch code").

Reading PCI bridge windows is not arch-specific in itself, but there is PCI
core code that doesn't work correctly if we read them too early. For
example, Hannes found this case on an ARM Freescale i.mx6 board:

pci_bus 0000:00: root bus resource [mem 0x01000000-0x01efffff]
pci 0000:00:00.0: PCI bridge to [bus 01-ff]
pci 0000:00:00.0: BAR 8: no space for [mem size 0x01000000] (mem window)
pci 0000:01:00.0: BAR 2: failed to assign [mem size 0x00200000]
pci 0000:01:00.0: BAR 1: failed to assign [mem size 0x00004000]
pci 0000:01:00.0: BAR 0: failed to assign [mem size 0x00000100]

The 00:00.0 mem window needs to be at least 3MB: the 01:00.0 device needs
0x204100 of space, and mem windows are megabyte-aligned.

Bus sizing can increase a bridge window size, but never *decrease* it (see
d65245c3297a ("PCI: don't shrink bridge resources")). Prior to
dff22d2054b5, ARM didn't read bridge windows at all, so the "original size"
was zero, and we assigned a 3MB window.

After dff22d2054b5, we read the bridge windows before sizing the bus. The
firmware programmed a 16MB window (size 0x01000000) in 00:00.0, and since
we never decrease the size, we kept 16MB even though we only needed 3MB.
But 16MB doesn't fit in the host bridge aperture, so we failed to assign
space for the window and the downstream devices.

I think this is a defect in the PCI core: we shouldn't rely on the firmware
to assign sensible windows.

Ray reported a similar problem, also on ARM, with Broadcom iProc.

Issues like this are too hard to fix right now, so revert dff22d2054b5.

Reported-by: Hannes
Reported-by: Ray Jui
Link: http://lkml.kernel.org/r/CAAa04yFQEUJm7Jj1qMT57-LG7ZGtnhNDBe=PpSRa70Mj+XhW-A@mail.gmail.com
Link: http://lkml.kernel.org/r/55F75BB8.4070405@broadcom.com
Signed-off-by: Bjorn Helgaas
Acked-by: Yinghai Lu
Acked-by: Lorenzo Pieralisi