Skip to content

K
Kernel

openeuler / Kernel
大约 1 年 前同步成功

通知 5
Star 0
Fork 0
K
Kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 06 5月, 2008 1 次提交
  3. 05 5月, 2008 12 次提交
  5. 04 5月, 2008 17 次提交
  7. 02 5月, 2008 10 次提交
    • D
      sparc32: Delete prom_stdin and prom_stdout. · 4a1236ac
      由 David S. Miller 提交于 
      They are written, but never used.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4a1236ac
    • D
      sparc32: More memory probing consolidation. · 9f2b2a5f
      由 David S. Miller 提交于 
      The PROM library function prom_meminit() builds a table,
prom_phys_avail[], just so that probe_memory() in
arch/sparc/mm/fault.c can copy it into sp_banks[].

Just have prom_meminit() fill in the sp_banks[] array directly, and
remove duplicated sort() function.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9f2b2a5f
    • D
      sparc32: Kill totally unused memory information tables. · ccc34028
      由 David S. Miller 提交于 
      The code in arch/sparc/prom/memory.c computes three tables, the list
of total memory, the list of available memory (total minus what
firmware is using), and the list of firmware taken memory.

Only the available memory list is even used.

Therefore, kill those unused tables and make prom_meminfo() return
just the available memory list.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ccc34028
    • D
      sparc64: Fix syscall restart, for real... · 2678fefe
      由 David S. Miller 提交于 
      The change I put into copy_thread() just papered over the real
problem.

When we are looking to see if we should do a syscall restart, when
deliverying a signal, we should only interpret the syscall return
value as an error if the carry condition code(s) are set.

Otherwise it's a success return.

Also, sigreturn paths should do a pt_regs_clear_trap_type().

It turns out that doing a syscall restart when returning from a fork()
does and should happen, from time to time.  Even if copy_thread()
returns success, copy_process() can still unwind and signal
-ERESTARTNOINTR in the parent.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2678fefe
    • D
      sparc64: Stop creating dummy root PCI host controller devices. · c26d3c01
      由 David S. Miller 提交于 
      It just creates confusion, errors, and bugs.

For one thing, this can cause dup sysfs or procfs nodes to get
created:

[    1.198015] proc_dir_entry '00.0' already registered
[    1.198036] Call Trace:
[    1.198052]  [00000000004f2534] create_proc_entry+0x7c/0x98
[    1.198092]  [00000000005719e4] pci_proc_attach_device+0xa4/0xd4
[    1.198126]  [00000000007d991c] pci_proc_init+0x64/0x88
[    1.198158]  [00000000007c62a4] kernel_init+0x190/0x330
[    1.198183]  [0000000000426cf8] kernel_thread+0x38/0x48
[    1.198210]  [00000000006a0d90] rest_init+0x18/0x5c
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c26d3c01
    • P
      [POWERPC] Bolt in SLB entry for kernel stack on secondary cpus · 3b575064
      由 Paul Mackerras 提交于 
      This fixes a regression reported by Kamalesh Bulabel where a POWER4
machine would crash because of an SLB miss at a point where the SLB
miss exception was unrecoverable.  This regression is tracked at:

http://bugzilla.kernel.org/show_bug.cgi?id=10082

SLB misses at such points shouldn't happen because the kernel stack is
the only memory accessed other than things in the first segment of the
linear mapping (which is mapped at all times by entry 0 of the SLB).
The context switch code ensures that SLB entry 2 covers the kernel
stack, if it is not already covered by entry 0.  None of entries 0
to 2 are ever replaced by the SLB miss handler.

Where this went wrong is that the context switch code assumes it
doesn't have to write to SLB entry 2 if the new kernel stack is in the
same segment as the old kernel stack, since entry 2 should already be
correct.  However, when we start up a secondary cpu, it calls
slb_initialize, which doesn't set up entry 2.  This is correct for
the boot cpu, where we will be using a stack in the kernel BSS at this
point (i.e. init_thread_union), but not necessarily for secondary
cpus, whose initial stack can be allocated anywhere.  This doesn't
cause any immediate problem since the SLB miss handler will just
create an SLB entry somewhere else to cover the initial stack.

In fact it's possible for the cpu to go quite a long time without SLB
entry 2 being valid.  Eventually, though, the entry created by the SLB
miss handler will get overwritten by some other entry, and if the next
access to the stack is at an unrecoverable point, we get the crash.

This fixes the problem by making slb_initialize create a suitable
entry for the kernel stack, if we are on a secondary cpu and the stack
isn't covered by SLB entry 0.  This requires initializing the
get_paca()->kstack field earlier, so I do that in smp_create_idle
where the current field is initialized.  This also abstracts a bit of
the computation that mk_esid_data in slb.c does so that it can be used
in slb_initialize.
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      3b575064
    • G
      [POWERPC] PS3: Update ps3_defconfig · d9f2f3f5
      由 Geoff Levand 提交于 
      Update ps3_defconfig.
Signed-off-by: NGeoff Levand <geoffrey.levand@am.sony.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      d9f2f3f5
    • G
      [POWERPC] PS3: Make ps3_virq_setup and ps3_virq_destroy static · fdedb4ca
      由 Geert Uytterhoeven 提交于 
      The routines ps3_virq_setup() and ps3_virq_destroy() are used
in only one file, so make them static.
Signed-off-by: NGeert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
Signed-off-by: NGeoff Levand <geoffrey.levand@am.sony.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      fdedb4ca
    • G
      [POWERPC] Fix slb.c compile warnings · bbea3460
      由 Geoff Levand 提交于 
      Arrange for a syntax check to always be done on the powerpc/mm/slb.c
DBG() macro by defining it to pr_debug() for non-debug builds.

Also, fix these related compile warnings:

  slb.c:273: warning: format '%04x' expects type 'unsigned int', but argument 2 has type 'long unsigned int
  slb.c:274: warning: format '%04x' expects type 'unsigned int', but argument 2 has type 'long unsigned int'
Signed-off-by: NGeoff Levand <geoffrey.levand@am.sony.com>
Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      bbea3460
    • K
      [POWERPC] Xilinx: Fix compile warnings · b17b8181
      由 Kumar Gala 提交于 
      arch/powerpc/sysdev/xilinx_intc.c: In function 'xilinx_intc_init':
arch/powerpc/sysdev/xilinx_intc.c:111: warning: format '%08X' expects type 'unsigned int', but argument 2 has type 'resource_size_t'
drivers/char/xilinx_hwicap/xilinx_hwicap.c: In function 'hwicap_setup':
drivers/char/xilinx_hwicap/xilinx_hwicap.c:626: warning: cast to pointer from integer of different size
drivers/char/xilinx_hwicap/xilinx_hwicap.c:646: warning: format '%x' expects type 'unsigned int', but argument 6 has type 'resource_size_t'
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      b17b8181