Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 13 12月, 2016 3 次提交
  3. 12 12月, 2016 4 次提交
  5. 07 12月, 2016 6 次提交
    • V
      s390/sysinfo: show partition extended name and UUID if available · e32eae10
      由 Viktor Mihajlovski 提交于 
      Extract extended name and UUID from SYSIB 2.2.2 data.
As the code to convert the raw extended name into printable format
can be reused by stsi_2_2_2 we're moving the conversion code into a
separate function convert_ext_name.
Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
Reviewed-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      e32eae10
    • H
      s390/numa: establish cpu to node mapping early · 8c910580
      由 Heiko Carstens 提交于 
      Initialize the cpu topology and therefore also the cpu to node mapping
much earlier. Fixes this warning and subsequent crashes when using the
fake numa emulation mode on s390:

WARNING: CPU: 0 PID: 1 at include/linux/cpumask.h:121 select_task_rq+0xe6/0x1a8
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.6.0-rc6-00001-ge9d867a6-dirty #28
task: 00000001dd270008 ti: 00000001eccb4000 task.ti: 00000001eccb4000
Krnl PSW : 0404c00180000000 0000000000176c56 (select_task_rq+0xe6/0x1a8)
           R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3
Call Trace:
([<0000000000176c30>] select_task_rq+0xc0/0x1a8)
([<0000000000177d64>] try_to_wake_up+0x2e4/0x478)
([<000000000015d46c>] create_worker+0x174/0x1c0)
([<0000000000161a98>] alloc_unbound_pwq+0x360/0x438)
([<0000000000162550>] apply_wqattrs_prepare+0x200/0x2a0)
([<000000000016266a>] apply_workqueue_attrs_locked+0x7a/0xb0)
([<0000000000162af0>] apply_workqueue_attrs+0x50/0x78)
([<000000000016441c>] __alloc_workqueue_key+0x304/0x520)
([<0000000000ee3706>] default_bdi_init+0x3e/0x70)
([<0000000000100270>] do_one_initcall+0x140/0x1d8)
([<0000000000ec9da8>] kernel_init_freeable+0x220/0x2d8)
([<0000000000984a7a>] kernel_init+0x2a/0x150)
([<00000000009913fa>] kernel_thread_starter+0x6/0xc)
([<00000000009913f4>] kernel_thread_starter+0x0/0xc)
Reviewed-by: NMichael Holzheu <holzheu@linux.vnet.ibm.com>
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      8c910580
    • H
      s390/topology: use cpu_topology array instead of per cpu variable · 30fc4ca2
      由 Heiko Carstens 提交于 
      CPU topology information like cpu to node mapping must be setup in
setup_arch already. Topology information is currently made available
with a per cpu variable; this however will not work when the
initialization will be moved to setup_arch, since the generic percpu
setup will be done much later.

Therefore convert back to a cpu_topology array.
Reviewed-by: NMichael Holzheu <holzheu@linux.vnet.ibm.com>
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      30fc4ca2
    • H
      s390/smp: initialize cpu_present_mask in setup_arch · af51160e
      由 Heiko Carstens 提交于 
      In order to be able to setup the cpu to node mappings early it is a
prerequisite to know which cpus are present. Therefore cpus must be
detected much earlier than before.

For sclp based cpu detection this requires yet another early sclp
call, since the system is not ready to use the regular interrupt and
memory allocations.
Reviewed-by: NMichael Holzheu <holzheu@linux.vnet.ibm.com>
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      af51160e
    • H
      s390/numa: always use logical cpu and core ids · 307b3114
      由 Heiko Carstens 提交于 
      The toptree algorithm uses the physical core ids to create a mapping
between cores and nodes (to_node_id array within emu_cores structure).
The core ids are used as an index into an array which size depends on
CONFIG_NR_CPUS. If the physical core ids are larger, this will result
in out-of-bounds write accesses.

Generate logical core ids instead to avoid this.
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      307b3114
    • M
      s390: Remove VLAIS in ptff() and clear_table() · 11a247e3
      由 Michael Holzheu 提交于 
      The ptff() and clear_table() functions use the gcc extension "variable
length arrays in structures" (VLAIS) to define in the inline assembler
constraints the area of the clobbered memory. This extension will most
likely never be supported by LLVM/Clang.

Since currently BPF programs are compiled with LLVM, this leads to the
following compile errors:

 $ cd samples/bpf
 $ make

 In file included from /root/linux-master/samples/bpf/tracex1_kern.c:8:
 In file included from ./include/linux/netdevice.h:44:
 ...
 In file included from ./arch/s390/include/asm/mmu_context.h:10:
  ./arch/s390/include/asm/pgalloc.h:30:24: error: fields must have a
  constant size: 'variable length array in structure' extension will never
  be supported
         typedef struct { char _[n]; } addrtype;

 In file included from /root/linux-master/samples/bpf/tracex1_kern.c:7:
 In file included from ./include/linux/skbuff.h:18:
 ...
 In file included from ./include/linux/jiffies.h:8:
 In file included from ./include/linux/timex.h:65:
  ./arch/s390/include/asm/timex.h:105:24: error: fields must have a
  constant size: 'variable length array in structure' extension will never
  be supported
        typedef struct { char _[len]; } addrtype;

To fix this do the following:

 - Convert ptff() into a macro that then uses a fixed size array
   when expanded.
 - Convert the clear_table() function and use an inline assembly
   with fixed size array in a loop.
   The runtime performance of the new version is even better than
   the old version (tested with EC12/z13 and gcc 4.8.5/6.2.1 with
   "-march=z196 -O2").
Reported-by: NZvonko Kosic <zvonko.kosic@de.ibm.com>
Signed-off-by: NMichael Holzheu <holzheu@linux.vnet.ibm.com>
Acked-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      11a247e3
  7. 29 11月, 2016 1 次提交
  9. 23 11月, 2016 4 次提交
  11. 22 11月, 2016 1 次提交
  13. 17 11月, 2016 1 次提交
  15. 16 11月, 2016 3 次提交
  17. 15 11月, 2016 1 次提交
  19. 11 11月, 2016 6 次提交
  21. 07 11月, 2016 2 次提交
  23. 28 10月, 2016 2 次提交
  25. 25 10月, 2016 1 次提交
  27. 17 10月, 2016 3 次提交
  29. 08 10月, 2016 1 次提交
  31. 22 9月, 2016 1 次提交
    • S
      s390/pci_dma: improve lazy flush for unmap · 13954fd6
      由 Sebastian Ott 提交于 
      Lazy unmap (defer tlb flush after unmap until dma address reuse) can
greatly reduce the number of RPCIT instructions in the best case. In
reality we are often far away from the best case scenario because our
implementation suffers from the following problem:

To create dma addresses we maintain an iommu bitmap and a pointer into
that bitmap to mark the start of the next search. That pointer moves from
the start to the end of that bitmap and we issue a global tlb flush
once that pointer wraps around. To prevent address reuse before we issue
the tlb flush we even have to move the next pointer during unmaps - when
clearing a bit > next. This could lead to a situation where we only use
the rear part of that bitmap and issue more tlb flushes than expected.

To fix this we no longer clear bits during unmap but maintain a 2nd
bitmap which we use to mark addresses that can't be reused until we issue
the global tlb flush after wrap around.
Signed-off-by: NSebastian Ott <sebott@linux.vnet.ibm.com>
Reviewed-by: NGerald Schaefer <gerald.schaefer@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      13954fd6