Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 10 8月, 2009 1 次提交
  3. 09 8月, 2009 1 次提交
  5. 08 8月, 2009 3 次提交
    • O
      x86: Add quirk to make Apple MacBookPro5,1 use reboot=pci · 498cdbfb
      由 Ozan Çağlayan 提交于 
      MacBookPro5,1 is not able to reboot unless reboot=pci is set.
This patch forces it through a DMI quirk specific to this
device.
Signed-off-by: NOzan Çağlayan <ozan@pardus.org.tr>
LKML-Reference: <1249403971-6543-1-git-send-email-ozan@pardus.org.tr>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      498cdbfb
    • Y
      x86: Fix MSI-X initialization by using online_mask for x2apic target_cpus · 087d7e56
      由 Yinghai Lu 提交于 
      found a system where x2apic reports an MSI-X irq initialization
failure:

[  302.859446] igbvf 0000:81:10.4: enabling device (0000 -> 0002)
[  302.874369] igbvf 0000:81:10.4: using 64bit DMA mask
[  302.879023] igbvf 0000:81:10.4: using 64bit consistent DMA mask
[  302.894386] igbvf 0000:81:10.4: enabling bus mastering
[  302.898171] igbvf 0000:81:10.4: setting latency timer to 64
[  302.914050] reserve_memtype added 0xefb08000-0xefb0c000, track uncached-minus, req uncached-minus, ret uncached-minus
[  302.933839] reserve_memtype added 0xefb28000-0xefb29000, track uncached-minus, req uncached-minus, ret uncached-minus
[  302.940367]   alloc irq_desc for 265 on node 4
[  302.956874]   alloc kstat_irqs on node 4
[  302.959452] alloc irq_2_iommu on node 0
[  302.974328] igbvf 0000:81:10.4: irq 265 for MSI/MSI-X
[  302.977778]   alloc irq_desc for 266 on node 4
[  302.980347]   alloc kstat_irqs on node 4
[  302.995312] free_memtype request 0xefb28000-0xefb29000
[  302.998816] igbvf 0000:81:10.4: Failed to initialize MSI-X interrupts.

... it turns out that when trying to enable MSI-X,
__assign_irq_vector(new, cfg_new, apic->target_cpus()) can not
get vector because for x2apic target-cpus returns cpumask_of(0)

Update that to online_mask like xapic.
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
Acked-by: NSuresh Siddha <suresh.b.siddha@intel.com>
LKML-Reference: <4A785AFF.3050902@kernel.org>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      087d7e56
    • G
      USB: musb: fix the nop registration for OMAP3EVM · e8e2ff46
      由 Gupta, Ajay Kumar 提交于 
      OMAP3EVM uses ISP1504 phy which doesn't require any programming and
thus has to use NOP otg transceiver.

Cleanups being done:
	- Remove unwanted code in usb-musb.c file
	- Register NOP in OMAP3EVM board file using
	  usb_nop_xceiv_register().
	- Select NOP_USB_XCEIV for OMAP3EVM boards.
	- Don't enable TWL4030_USB in omap3_evm_defconfig
Signed-off-by: NAjay Kumar Gupta <ajay.gupta@ti.com>
Signed-off-by: NEino-Ville Talvala <talvala@stanford.edu>
Acked-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      e8e2ff46
  7. 07 8月, 2009 2 次提交
  9. 06 8月, 2009 5 次提交
  11. 05 8月, 2009 11 次提交
  13. 04 8月, 2009 17 次提交
    • S
      x86: Work around compilation warning in arch/x86/kernel/apm_32.c · dc731fbb
      由 Subrata Modak 提交于 
      The following fix was initially inspired by David Howells fix
few days back:

  http://lkml.org/lkml/2009/7/9/109

However, Ingo disapproves such fixes as it's dangerous (it can
hide future, relevant warnings) - in something as
performance-uncritical.

So, initialize 'err' to '0' to work around a GCC false positive
warning:

  http://lkml.org/lkml/2009/7/18/89

Signed-off-by: Subrata Modak<subrata@linux.vnet.ibm.com>
Cc: Sachin P Sant <sachinp@linux.vnet.ibm.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Balbir Singh <balbir@linux.vnet.ibm.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
LKML-Reference: <20090721023226.31855.67236.sendpatchset@subratamodak.linux.ibm.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      dc731fbb
    • J
      x86, UV: Complete IRQ interrupt migration in arch_enable_uv_irq() · 2a5ef416
      由 Jack Steiner 提交于 
      In uv_setup_irq(), the call to create_irq() initially assigns
IRQ vectors to cpu 0. The subsequent call to
assign_irq_vector() in arch_enable_uv_irq() migrates the IRQ to
another cpu and frees the cpu 0 vector - at least it will be
freed as soon as the "IRQ move" completes.

arch_enable_uv_irq() needs to send a cleanup IPI to complete
the IRQ move. Otherwise, assignment of GRU interrupts on large
systems (>200 cpus) will exhaust the cpu 0 interrupt vectors
and initialization of the GRU driver will fail.
Signed-off-by: NJack Steiner <steiner@sgi.com>
LKML-Reference: <20090720142840.GA8885@sgi.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      2a5ef416
    • J
      x86, 32-bit: Fix double accounting in reserve_top_address() · 6abf6551
      由 Jan Beulich 提交于 
      With VMALLOC_END included in the calculation of MAXMEM (as of
2.6.28) it is no longer correct to also bump __VMALLOC_RESERVE
in reserve_top_address(). Doing so results in needlessly small
lowmem.
Signed-off-by: NJan Beulich <jbeulich@novell.com>
LKML-Reference: <4A71DD2A020000780000D482@vpn.id2.novell.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      6abf6551
    • Y
      x86: Don't use current_cpu_data in x2apic phys_pkg_id · d8c7eb34
      由 Yinghai Lu 提交于 
      One system has socket 1 come up as BSP.

kexeced kernel reports BSP as:

[    1.524550] Initializing cgroup subsys cpuacct
[    1.536064] initial_apicid:20
[    1.537135] ht_mask_width:1
[    1.538128] core_select_mask:f
[    1.539126] core_plus_mask_width:5
[    1.558479] CPU: Physical Processor ID: 0
[    1.559501] CPU: Processor Core ID: 0
[    1.560539] CPU: L1 I cache: 32K, L1 D cache: 32K
[    1.579098] CPU: L2 cache: 256K
[    1.580085] CPU: L3 cache: 24576K
[    1.581108] CPU 0/0x20 -> Node 0
[    1.596193] CPU 0 microcode level: 0xffff0008

It doesn't have correct physical processor id and will get an
error:

[   38.840859] CPU0 attaching sched-domain:
[   38.848287]  domain 0: span 0,8,72 level SIBLING
[   38.851151]   groups: 0 8 72
[   38.858137]   domain 1: span 0,8-15,72-79 level MC
[   38.868944]    groups: 0,8,72 9,73 10,74 11,75 12,76 13,77 14,78 15,79
[   38.881383] ERROR: parent span is not a superset of domain->span
[   38.890724]    domain 2: span 0-7,64-71 level CPU
[   38.899237] ERROR: domain->groups does not contain CPU0
[   38.909229]     groups: 8-15,72-79
[   38.912547] ERROR: groups don't span domain->span
[   38.919665]     domain 3: span 0-127 level NODE
[   38.930739]      groups: 0-7,64-71 8-15,72-79 16-23,80-87 24-31,88-95 32-39,96-103 40-47,104-111 48-55,112-119 56-63,120-127

it turns out: we can not use current_cpu_data in phys_pgd_id
for x2apic.

identify_boot_cpu() is called by check_bugs() before
smp_prepare_cpus() and till smp_prepare_cpus() current_cpu_data
for bsp is assigned with boot_cpu_data.

Just make phys_pkg_id for x2apic is aligned to xapic.
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
Acked-by: NSuresh Siddha <suresh.b.siddha@intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
LKML-Reference: <4A6ADD0D.10002@kernel.org>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      d8c7eb34
    • J
      x86, UV: Fix UV apic mode · c5997fa8
      由 Jack Steiner 提交于 
      Change SGI UV default apicid mode to "physical". This is
required to match settings in the UV hub chip.
Signed-off-by: NJack Steiner <steiner@sgi.com>
LKML-Reference: <20090727143856.GA8905@sgi.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c5997fa8
    • J
      x86, UV: Fix macros for accessing large node numbers · 67e83f30
      由 Jack Steiner 提交于 
      The UV chipset automatically supplies the upper bits on nodes
being referenced by MMR accesses. These bit can be deleted from
the hub addressing macros.
Signed-off-by: NJack Steiner <steiner@sgi.com>
LKML-Reference: <20090727143808.GA8076@sgi.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      67e83f30
    • J
      x86, UV: Delete mapping of MMR rangs mapped by BIOS · cc5e4fa1
      由 Jack Steiner 提交于 
      The UV BIOS has added additional MMR ranges that are mapped via
EFI virtual mode mappings. These ranges should be deleted from
ranges mapped by uv_system_init().
Signed-off-by: NJack Steiner <steiner@sgi.com>
Cc: linux-mm@kvack.org
LKML-Reference: <20090727143656.GA7698@sgi.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      cc5e4fa1
    • J
      x86, UV: Handle missing blade-local memory correctly · 6c7184b7
      由 Jack Steiner 提交于 
      UV blades may not have any blade-local memory. Add a field
(nid) to the UV blade structure to indicates whether the node
has local memory. This is needed by the GRU driver (pushed
separately).
Signed-off-by: NJack Steiner <steiner@sgi.com>
Cc: linux-mm@kvack.org
LKML-Reference: <20090727143507.GA7006@sgi.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      6c7184b7
    • H
      x86: fix assembly constraints in native_save_fl() · f1f029c7
      由 H. Peter Anvin 提交于 
      From Gabe Black in bugzilla 13888:

native_save_fl is implemented as follows:

  11static inline unsigned long native_save_fl(void)
  12{
  13        unsigned long flags;
  14
  15        asm volatile("# __raw_save_flags\n\t"
  16                     "pushf ; pop %0"
  17                     : "=g" (flags)
  18                     : /* no input */
  19                     : "memory");
  20
  21        return flags;
  22}

If gcc chooses to put flags on the stack, for instance because this is
inlined into a larger function with more register pressure, the offset
of the flags variable from the stack pointer will change when the
pushf is performed. gcc doesn't attempt to understand that fact, and
address used for pop will still be the same. It will write to
somewhere near flags on the stack but not actually into it and
overwrite some other value.

I saw this happen in the ide_device_add_all function when running in a
simulator I work on. I'm assuming that some quirk of how the simulated
hardware is set up caused the code path this is on to be executed when
it normally wouldn't.

A simple fix might be to change "=g" to "=r".
Reported-by: NGabe Black <spamforgabe@umich.edu>
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
Cc: Stable Team <stable@kernel.org>
      f1f029c7
    • B
      x86, msr: execute on the correct CPU subset · bab9a3da
      由 Borislav Petkov 提交于 
      Make rdmsr_on_cpus/wrmsr_on_cpus execute on the current CPU only if it
is in the supplied bitmask.
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      bab9a3da
    • H
      x86: Fix assert syntax in vmlinux.lds.S · d2ba8b21
      由 H. Peter Anvin 提交于 
      Older versions of binutils did not accept the naked "ASSERT" syntax;
it is considered an expression whose value needs to be assigned to
something.
Reported-tested-and-fixed-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      d2ba8b21
    • P
      x86: Make 64-bit efi_ioremap use ioremap on MMIO regions · 6a7bbd57
      由 Paul Mackerras 提交于 
      Booting current 64-bit x86 kernels on the latest Apple MacBook
(MacBook5,2) via EFI gives the following warning:

[    0.182209] ------------[ cut here ]------------
[    0.182222] WARNING: at arch/x86/mm/pageattr.c:581 __cpa_process_fault+0x44/0xa0()
[    0.182227] Hardware name: MacBook5,2
[    0.182231] CPA: called for zero pte. vaddr = ffff8800ffe00000 cpa->vaddr = ffff8800ffe00000
[    0.182236] Modules linked in:
[    0.182242] Pid: 0, comm: swapper Not tainted 2.6.31-rc4 #6
[    0.182246] Call Trace:
[    0.182254]  [<ffffffff8102c754>] ? __cpa_process_fault+0x44/0xa0
[    0.182261]  [<ffffffff81048668>] warn_slowpath_common+0x78/0xd0
[    0.182266]  [<ffffffff81048744>] warn_slowpath_fmt+0x64/0x70
[    0.182272]  [<ffffffff8102c7ec>] ? update_page_count+0x3c/0x50
[    0.182280]  [<ffffffff818d25c5>] ? phys_pmd_init+0x140/0x22e
[    0.182286]  [<ffffffff8102c754>] __cpa_process_fault+0x44/0xa0
[    0.182292]  [<ffffffff8102ce60>] __change_page_attr_set_clr+0x5f0/0xb40
[    0.182301]  [<ffffffff810d1035>] ? vm_unmap_aliases+0x175/0x190
[    0.182307]  [<ffffffff8102d4ae>] change_page_attr_set_clr+0xfe/0x3d0
[    0.182314]  [<ffffffff8102dcca>] _set_memory_uc+0x2a/0x30
[    0.182319]  [<ffffffff8102dd4b>] set_memory_uc+0x7b/0xb0
[    0.182327]  [<ffffffff818afe31>] efi_enter_virtual_mode+0x2ad/0x2c9
[    0.182334]  [<ffffffff818a1c66>] start_kernel+0x2db/0x3f4
[    0.182340]  [<ffffffff818a1289>] x86_64_start_reservations+0x99/0xb9
[    0.182345]  [<ffffffff818a1389>] x86_64_start_kernel+0xe0/0xf2
[    0.182357] ---[ end trace 4eaa2a86a8e2da22 ]---
[    0.182982] init_memory_mapping: 00000000ffffc000-0000000100000000
[    0.182993]  00ffffc000 - 0100000000 page 4k

This happens because the 64-bit version of efi_ioremap calls
init_memory_mapping for all addresses, regardless of whether they are
RAM or MMIO.  The EFI tables on this machine ask for runtime access to
some MMIO regions:

[    0.000000] EFI: mem195: type=11, attr=0x8000000000000000, range=[0x0000000093400000-0x0000000093401000) (0MB)
[    0.000000] EFI: mem196: type=11, attr=0x8000000000000000, range=[0x00000000ffc00000-0x00000000ffc40000) (0MB)
[    0.000000] EFI: mem197: type=11, attr=0x8000000000000000, range=[0x00000000ffc40000-0x00000000ffc80000) (0MB)
[    0.000000] EFI: mem198: type=11, attr=0x8000000000000000, range=[0x00000000ffc80000-0x00000000ffca4000) (0MB)
[    0.000000] EFI: mem199: type=11, attr=0x8000000000000000, range=[0x00000000ffca4000-0x00000000ffcb4000) (0MB)
[    0.000000] EFI: mem200: type=11, attr=0x8000000000000000, range=[0x00000000ffcb4000-0x00000000ffffc000) (3MB)
[    0.000000] EFI: mem201: type=11, attr=0x8000000000000000, range=[0x00000000ffffc000-0x0000000100000000) (0MB)

This arranges to pass the EFI memory type through to efi_ioremap, and
makes efi_ioremap use ioremap rather than init_memory_mapping if the
type is EFI_MEMORY_MAPPED_IO.  With this, the above warning goes away.
Signed-off-by: NPaul Mackerras <paulus@samba.org>
LKML-Reference: <19062.55858.533494.471153@cargo.ozlabs.ibm.com>
Cc: Huang Ying <ying.huang@intel.com>
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      6a7bbd57
    • P
      x86: Add quirk to make Apple MacBook5,2 use reboot=pci · 6c6c51e4
      由 Paul Mackerras 提交于 
      The latest Apple MacBook (MacBook5,2) doesn't reboot successfully
under Linux; neither the EFI reboot method nor the default method
using the keyboard controller works (the system just hangs and doesn't
reset).  However, the method using the "PCI reset register" at 0xcf9
does work.

This adds a quirk to detect this machine via DMI and force the
reboot_type to BOOT_CF9.  With this it reboots successfully without
requiring a command-line option.  Note that the EFI code forces
reboot_type to BOOT_EFI when the machine is booted via EFI, but this
overrides that since the core_initcall runs after the EFI
initialization code.
Signed-off-by: NPaul Mackerras <paulus@samba.org>
LKML-Reference: <19062.56420.501516.316181@cargo.ozlabs.ibm.com>
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      6c6c51e4
    • T
      x86: Fix CPA memtype reserving in the set_pages_array*() cases · 8523acfe
      由 Thomas Hellstrom 提交于 
      The code was incorrectly reserving memtypes using the page
virtual address instead of the physical address. Furthermore,
the code was not ignoring highmem pages as it ought to.

( upstream does not pass in highmem pages yet - but upcoming
  graphics code will do it and there's no reason to not handle
  this properly in the CPA APIs.)

Fixes: http://bugzilla.kernel.org/show_bug.cgi?id=13884Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Acked-by: NSuresh Siddha <suresh.b.siddha@intel.com>
Cc: <stable@kernel.org>
Cc: dri-devel@lists.sourceforge.net
Cc: venkatesh.pallipadi@intel.com
LKML-Reference: <1249284345-7654-1-git-send-email-thellstrom@vmware.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      8523acfe
    • R
      MIPS: Wire up accept4 syscall. · 54822de7
      由 Ralf Baechle 提交于 
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      54822de7
    • R
      MIPS: VPE: Delete unused function get_tc_unused(). · ce21f4e8
      由 Ralf Baechle 提交于 
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      ce21f4e8
    • R
      MIPS: VPE: Fix bogus indentation. · 349c4229
      由 Ralf Baechle 提交于 
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      349c4229