1. 17 2月, 2013 7 次提交
  2. 16 2月, 2013 11 次提交
  3. 08 2月, 2013 4 次提交
    • W
      ARM: 7641/1: memory: fix broken mmap by ensuring TASK_UNMAPPED_BASE is aligned · 79d1f5c9
      Will Deacon 提交于
      We have received multiple reports of mmap failures when running with a
      2:2 vm split. These manifest as either -EINVAL with a non page-aligned
      address (ending 0xaaa) or a SEGV, depending on the application. The
      issue is commonly observed in children of make, which appears to use
      bottom-up mmap (assumedly because it changes the stack rlimit).
      
      Further investigation reveals that this regression was triggered by
      394ef640 ("mm: use vm_unmapped_area() on arm architecture"), whereby
      TASK_UNMAPPED_BASE is no longer page-aligned for bottom-up mmap, causing
      get_unmapped_area to choke on misaligned addressed.
      
      This patch fixes the problem by defining TASK_UNMAPPED_BASE in terms of
      TASK_SIZE and explicitly aligns the result to 16M, matching the other
      end of the heap.
      Acked-by: NNicolas Pitre <nico@linaro.org>
      Reported-by: NSteve Capper <steve.capper@arm.com>
      Reported-by: NJean-Francois Moine <moinejf@free.fr>
      Reported-by: NChristoffer Dall <cdall@cs.columbia.edu>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      79d1f5c9
    • R
      ARM: DMA mapping: fix bad atomic test · 633dc92a
      Russell King 提交于
      Realview fails to boot with this warning:
      BUG: spinlock lockup suspected on CPU#0, init/1
       lock: 0xcf8bde10, .magic: dead4ead, .owner: init/1, .owner_cpu: 0
      Backtrace:
      [<c00185d8>] (dump_backtrace+0x0/0x10c) from [<c03294e8>] (dump_stack+0x18/0x1c) r6:cf8bde10 r5:cf83d1c0 r4:cf8bde10 r3:cf83d1c0
      [<c03294d0>] (dump_stack+0x0/0x1c) from [<c018926c>] (spin_dump+0x84/0x98)
      [<c01891e8>] (spin_dump+0x0/0x98) from [<c0189460>] (do_raw_spin_lock+0x100/0x198)
      [<c0189360>] (do_raw_spin_lock+0x0/0x198) from [<c032cbac>] (_raw_spin_lock+0x3c/0x44)
      [<c032cb70>] (_raw_spin_lock+0x0/0x44) from [<c01c9224>] (pl011_console_write+0xe8/0x11c)
      [<c01c913c>] (pl011_console_write+0x0/0x11c) from [<c002aea8>] (call_console_drivers.clone.7+0xdc/0x104)
      [<c002adcc>] (call_console_drivers.clone.7+0x0/0x104) from [<c002b320>] (console_unlock+0x2e8/0x454)
      [<c002b038>] (console_unlock+0x0/0x454) from [<c002b8b4>] (vprintk_emit+0x2d8/0x594)
      [<c002b5dc>] (vprintk_emit+0x0/0x594) from [<c0329718>] (printk+0x3c/0x44)
      [<c03296dc>] (printk+0x0/0x44) from [<c002929c>] (warn_slowpath_common+0x28/0x6c)
      [<c0029274>] (warn_slowpath_common+0x0/0x6c) from [<c0029304>] (warn_slowpath_null+0x24/0x2c)
      [<c00292e0>] (warn_slowpath_null+0x0/0x2c) from [<c0070ab0>] (lockdep_trace_alloc+0xd8/0xf0)
      [<c00709d8>] (lockdep_trace_alloc+0x0/0xf0) from [<c00c0850>] (kmem_cache_alloc+0x24/0x11c)
      [<c00c082c>] (kmem_cache_alloc+0x0/0x11c) from [<c00bb044>] (__get_vm_area_node.clone.24+0x7c/0x16c)
      [<c00bafc8>] (__get_vm_area_node.clone.24+0x0/0x16c) from [<c00bb7b8>] (get_vm_area_caller+0x48/0x54)
      [<c00bb770>] (get_vm_area_caller+0x0/0x54) from [<c0020064>] (__alloc_remap_buffer.clone.15+0x38/0xb8)
      [<c002002c>] (__alloc_remap_buffer.clone.15+0x0/0xb8) from [<c0020244>] (__dma_alloc+0x160/0x2c8)
      [<c00200e4>] (__dma_alloc+0x0/0x2c8) from [<c00204d8>] (arm_dma_alloc+0x88/0xa0)[<c0020450>] (arm_dma_alloc+0x0/0xa0) from [<c00beb00>] (dma_pool_alloc+0xcc/0x1a8)
      [<c00bea34>] (dma_pool_alloc+0x0/0x1a8) from [<c01a9d14>] (pl08x_fill_llis_for_desc+0x28/0x568)
      [<c01a9cec>] (pl08x_fill_llis_for_desc+0x0/0x568) from [<c01aab8c>] (pl08x_prep_slave_sg+0x258/0x3b0)
      [<c01aa934>] (pl08x_prep_slave_sg+0x0/0x3b0) from [<c01c9f74>] (pl011_dma_tx_refill+0x140/0x288)
      [<c01c9e34>] (pl011_dma_tx_refill+0x0/0x288) from [<c01ca748>] (pl011_start_tx+0xe4/0x120)
      [<c01ca664>] (pl011_start_tx+0x0/0x120) from [<c01c54a4>] (__uart_start+0x48/0x4c)
      [<c01c545c>] (__uart_start+0x0/0x4c) from [<c01c632c>] (uart_start+0x2c/0x3c)
      [<c01c6300>] (uart_start+0x0/0x3c) from [<c01c795c>] (uart_write+0xcc/0xf4)
      [<c01c7890>] (uart_write+0x0/0xf4) from [<c01b0384>] (n_tty_write+0x1c0/0x3e4)
      [<c01b01c4>] (n_tty_write+0x0/0x3e4) from [<c01acfe8>] (tty_write+0x144/0x240)
      [<c01acea4>] (tty_write+0x0/0x240) from [<c01ad17c>] (redirected_tty_write+0x98/0xac)
      [<c01ad0e4>] (redirected_tty_write+0x0/0xac) from [<c00c371c>] (vfs_write+0xbc/0x150)
      [<c00c3660>] (vfs_write+0x0/0x150) from [<c00c39c0>] (sys_write+0x4c/0x78)
      [<c00c3974>] (sys_write+0x0/0x78) from [<c0014460>] (ret_fast_syscall+0x0/0x3c)
      
      This happens because the DMA allocation code is not respecting atomic
      allocations correctly.
      
      GFP flags should not be tested for GFP_ATOMIC to determine if an
      atomic allocation is being requested.  GFP_ATOMIC is not a flag but
      a value.  The GFP bitmask flags are all prefixed with __GFP_.
      
      The rest of the kernel tests for __GFP_WAIT not being set to indicate
      an atomic allocation.  We need to do the same.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      633dc92a
    • R
      ARM: realview: ensure that we have sufficient IRQs available · e210101d
      Russell King 提交于
      Realview EB with a rev B MPcore tile results in lots of warnings at
      boot because it can't allocate enough IRQs.  Fix this by increasing
      the number of available IRQs.
      
      WARNING: at /home/rmk/git/linux-rmk/arch/arm/common/gic.c:757 gic_init_bases+0x12c/0x2ec()
      Cannot allocate irq_descs @ IRQ96, assuming pre-allocated
      Modules linked in:
      Backtrace:
      [<c00185d8>] (dump_backtrace+0x0/0x10c) from [<c03294e8>] (dump_stack+0x18/0x1c) r6:000002f5 r5:c042c62c r4:c044ff40 r3:c045f240
      [<c03294d0>] (dump_stack+0x0/0x1c) from [<c00292c8>] (warn_slowpath_common+0x54/0x6c)
      [<c0029274>] (warn_slowpath_common+0x0/0x6c) from [<c0029384>] (warn_slowpath_fmt+0x38/0x40)
      [<c002934c>] (warn_slowpath_fmt+0x0/0x40) from [<c042c62c>] (gic_init_bases+0x12c/0x2ec)
      [<c042c500>] (gic_init_bases+0x0/0x2ec) from [<c042cdc8>] (gic_init_irq+0x8c/0xd8)
      [<c042cd3c>] (gic_init_irq+0x0/0xd8) from [<c042827c>] (init_IRQ+0x1c/0x24)
      [<c0428260>] (init_IRQ+0x0/0x24) from [<c04256c8>] (start_kernel+0x1a4/0x300)
      [<c0425524>] (start_kernel+0x0/0x300) from [<70008070>] (0x70008070)
      ---[ end trace 1b75b31a2719ed1c ]---
      ------------[ cut here ]------------
      WARNING: at /home/rmk/git/linux-rmk/kernel/irq/irqdomain.c:234 irq_domain_add_legacy+0x80/0x140()
      Modules linked in:
      Backtrace:
      [<c00185d8>] (dump_backtrace+0x0/0x10c) from [<c03294e8>] (dump_stack+0x18/0x1c) r6:000000ea r5:c0081a38 r4:00000000 r3:c045f240
      [<c03294d0>] (dump_stack+0x0/0x1c) from [<c00292c8>] (warn_slowpath_common+0x54/0x6c)
      [<c0029274>] (warn_slowpath_common+0x0/0x6c) from [<c0029304>] (warn_slowpath_null+0x24/0x2c)
      [<c00292e0>] (warn_slowpath_null+0x0/0x2c) from [<c0081a38>] (irq_domain_add_legacy+0x80/0x140)
      [<c00819b8>] (irq_domain_add_legacy+0x0/0x140) from [<c042c64c>] (gic_init_bases+0x14c/0x2ec)
      [<c042c500>] (gic_init_bases+0x0/0x2ec) from [<c042cdc8>] (gic_init_irq+0x8c/0xd8)
      [<c042cd3c>] (gic_init_irq+0x0/0xd8) from [<c042827c>] (init_IRQ+0x1c/0x24)
      [<c0428260>] (init_IRQ+0x0/0x24) from [<c04256c8>] (start_kernel+0x1a4/0x300)
      [<c0425524>] (start_kernel+0x0/0x300) from [<70008070>] (0x70008070)
      ---[ end trace 1b75b31a2719ed1d ]---
      ------------[ cut here ]------------
      WARNING: at /home/rmk/git/linux-rmk/arch/arm/common/gic.c:762 gic_init_bases+0x170/0x2ec()
      Modules linked in:
      Backtrace:
      [<c00185d8>] (dump_backtrace+0x0/0x10c) from [<c03294e8>] (dump_stack+0x18/0x1c) r6:000002fa r5:c042c670 r4:00000000 r3:c045f240
      [<c03294d0>] (dump_stack+0x0/0x1c) from [<c00292c8>] (warn_slowpath_common+0x54/0x6c)
      [<c0029274>] (warn_slowpath_common+0x0/0x6c) from [<c0029304>] (warn_slowpath_null+0x24/0x2c)
      [<c00292e0>] (warn_slowpath_null+0x0/0x2c) from [<c042c670>] (gic_init_bases+0x170/0x2ec)
      [<c042c500>] (gic_init_bases+0x0/0x2ec) from [<c042cdc8>] (gic_init_irq+0x8c/0xd8)
      [<c042cd3c>] (gic_init_irq+0x0/0xd8) from [<c042827c>] (init_IRQ+0x1c/0x24)
      [<c0428260>] (init_IRQ+0x0/0x24) from [<c04256c8>] (start_kernel+0x1a4/0x300)
      [<c0425524>] (start_kernel+0x0/0x300) from [<70008070>] (0x70008070)
      ---[ end trace 1b75b31a2719ed1e ]---
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      e210101d
    • R
      ARM: GIC: fix GIC cpumask initialization · 2bb31351
      Russell King 提交于
      Punit Agrawal reports:
      > I was trying to boot 3.8-rc5 on Realview EB 11MPCore using
      > realview-smp_defconfig as a starting point but the kernel failed to
      > progress past the log below (config attached).
      >
      > Pawel suggested I try reverting 384a2902 - "ARM: gic: use a private
      > mapping for CPU target interfaces" that you've authored. With this
      > commit reverted the kernel boots.
      >
      > I am not quite sure why the commit breaks 11MPCore but Pawel (cc'd)
      > might be able to shed light on that.
      
      Some early GIC implementations return zero for the first distributor
      CPU routing register.  This means we can't rely on that telling us
      which CPU interface we're connected to.  We know that these platforms
      implement PPIs for IRQs 29-31 - but we shouldn't assume that these
      will always be populated.
      
      So, instead, scan for a non-zero CPU routing register in the first
      32 IRQs and use that as our CPU mask.
      Reported-by: NPunit Agrawal <punit.agrawal@arm.com>
      Reviewed-by: NNicolas Pitre <nico@linaro.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      2bb31351
  4. 05 2月, 2013 1 次提交
  5. 04 2月, 2013 2 次提交
    • B
      x86/intel/cacheinfo: Shut up annoying warning · f76e39c5
      Borislav Petkov 提交于
      I've been getting the following warning when doing randbuilds
      since forever. Now it finally pissed me off just the perfect
      amount so that I can fix it.
      
        arch/x86/kernel/cpu/intel_cacheinfo.c:489:27: warning: ‘cache_disable_0’ defined but not used [-Wunused-variable]
        arch/x86/kernel/cpu/intel_cacheinfo.c:491:27: warning: ‘cache_disable_1’ defined but not used [-Wunused-variable] arch/x86/kernel/cpu/intel_cacheinfo.c:524:27: warning: ‘subcaches’ defined but not used [-Wunused-variable]
      
      It happens because in randconfigs where CONFIG_SYSFS is not set,
      the whole sysfs-interface to L3 cache index disabling is
      remaining unused and gcc correctly warns about it. Make it
      optional, depending on CONFIG_SYSFS too, as is the case with
      other sysfs-related machinery in this file.
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
      Link: http://lkml.kernel.org/r/1359969195-27362-1-git-send-email-bp@alien8.deSigned-off-by: NIngo Molnar <mingo@kernel.org>
      f76e39c5
    • A
      powerpc/mm: Fix hash computation function · eda8eebd
      Aneesh Kumar K.V 提交于
      The ASM version of hash computation function was truncating the upper bit.
      Make the ASM version similar to hpt_hash function. Remove masking vsid bits.
      Without this patch, we observed hang during bootup due to not satisfying page
      fault request correctly. The fault handler used wrong hash values to update
      the HPTE. Hence we kept looping with page fault.
      
      hash_page(ea=000001003e260008, access=203, trap=300 ip=3fff91787134 dsisr 42000000
      The computed value of hash 000000000f22f390
      update: avpnv=4003e46054003e00, hash=000000000722f390, f=80000006, psize: 2 ...
      
      BenH: The over-masking has been there for ever but only hurts with the
      new 64T support introduced in 3.7
      Reported-by: NMike Qiu <qiudayu@linux.vnet.ibm.com>
      Signed-off-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Tested-by: NMike Qiu <qiudayu@linux.vnet.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      CC: <stable@vger.kernel.org> [v3.7]
      eda8eebd
  6. 31 1月, 2013 8 次提交
    • A
      MIPS: Function tracer: Fix broken function tracing · 58b69401
      Al Cooper 提交于
      Function tracing is currently broken for all 32 bit MIPS platforms.
      When tracing is enabled, the kernel immediately hangs on boot.
      This is a result of commit b732d439
      that changes the kernel/trace/Kconfig file so that is no longer
      forces FRAME_POINTER when FUNCTION_TRACING is enabled.
      
      MIPS frame pointers are generally considered to be useless because
      they cannot be used to unwind the stack. Unfortunately the MIPS
      function tracing code has bugs that are masked by the use of frame
      pointers. This commit fixes the bugs so that MIPS frame pointers
      don't need to be enabled.
      
      The bugs are a result of the odd calling sequence used to call the trace
      routine. This calling sequence is inserted into every traceable function
      when the tracing CONFIG option is enabled. This sequence is generated
      for 32bit MIPS platforms by the compiler via the "-pg" flag.
      
      Part of the sequence is "addiu sp,sp,-8" in the delay slot after every
      call to the trace routine "_mcount" (some legacy thing where 2 arguments
      used to be pushed on the stack). The _mcount routine is expected to
      adjust the sp by +8 before returning.  So when not disabled, the original
      jalr and addiu will be there, so _mcount has to adjust sp.
      
      The problem is that when tracing is disabled for a function, the
      "jalr _mcount" instruction is replaced with a nop, but the
      "addiu sp,sp,-8" is still executed and the stack pointer is left
      trashed. When frame pointers are enabled the problem is masked
      because any access to the stack is done through the frame
      pointer and the stack pointer is restored from the frame pointer when
      the function returns.
      
      This patch writes two nops starting at the address of the "jalr _mcount"
      instruction whenever tracing is disabled. This means that the
      "addiu sp,sp.-8" will be converted to a nop along with the "jalr".  When
      disabled, there will be two nops.
      
      This is SMP safe because the first time this happens is during
      ftrace_init() which is before any other processor has been started.
      Subsequent calls to enable/disable tracing when other CPUs ARE running
      will still be safe because the enable will only change the first nop
      to a "jalr" and the disable, while writing 2 nops, will only be changing
      the "jalr". This patch also stops using stop_machine() to call the
      tracer enable/disable routines and calls them directly because the
      routines are SMP safe.
      
      When the kernel first boots we have to be able to handle the gcc
      generated jalr, addui sequence until ftrace_init gets a chance to run
      and change the sequence. At this point mcount just adjusts the stack
      and returns. When ftrace_init runs, we convert the jalr/addui to nops.
      Then whenever tracing is enabled we convert the first nop to a "jalr
      mcount+8". The mcount+8 entry point skips the stack adjust.
      
      [ralf@linux-mips.org: Folded in  Steven Rostedt's build fix.]
      Signed-off-by: NAl Cooper <alcooperx@gmail.com>
      Cc: rostedt@goodmis.org
      Cc: ddaney.cavm@gmail.com
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/4806/
      Patchwork: https://patchwork.linux-mips.org/patch/4841/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      58b69401
    • S
      mips: Move __virt_addr_valid() to a place for MIPS 64 · 196897a2
      Steven Rostedt 提交于
      Commit d3ce8843 "MIPS: Fix modpost error in modules attepting to use
      virt_addr_valid()" moved __virt_addr_valid() from a macro in a header
      file to a function in ioremap.c. But ioremap.c is only compiled for MIPS
      32, and not for MIPS 64.
      
      When compiling for my yeeloong2, which supposedly supports hibernation,
      which compiles kernel/power/snapshot.c which calls virt_addr_valid(), I
      got this error:
      
        LD      init/built-in.o
      kernel/built-in.o: In function `memory_bm_free':
      snapshot.c:(.text+0x4c9c4): undefined reference to `__virt_addr_valid'
      snapshot.c:(.text+0x4ca58): undefined reference to `__virt_addr_valid'
      kernel/built-in.o: In function `snapshot_write_next':
      (.text+0x4e44c): undefined reference to `__virt_addr_valid'
      kernel/built-in.o: In function `snapshot_write_next':
      (.text+0x4e890): undefined reference to `__virt_addr_valid'
      make[1]: *** [vmlinux] Error 1
      make: *** [sub-make] Error 2
      
      I suspect that __virt_addr_valid() is fine for mips 64. I moved it to
      mmap.c such that it gets compiled for mips 64 and 32.
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      Cc: linux-kernel@vger.kernel.org
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/4842/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      196897a2
    • J
      x86-64: Replace left over sti/cli in ia32 audit exit code · 40a1ef95
      Jan Beulich 提交于
      For some reason they didn't get replaced so far by their
      paravirt equivalents, resulting in code to be run with
      interrupts disabled that doesn't expect so (causing, in the
      observed case, a BUG_ON() to trigger) when syscall auditing is
      enabled.
      
      David (Cc-ed) came up with an identical fix, so likely this can
      be taken to count as an ack from him.
      Reported-by: NPeter Moody <pmoody@google.com>
      Signed-off-by: NJan Beulich <jbeulich@suse.com>
      Cc: David Vrabel <david.vrabel@citrix.com>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Link: http://lkml.kernel.org/r/5108E01902000078000BA9C5@nat28.tlf.novell.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      Cc: stable@vger.kernel.org
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: David Vrabel <david.vrabel@citrix.com>
      Tested-by: NPeter Moody <pmoody@google.com>
      40a1ef95
    • J
      MIPS: Netlogic: Fix UP compilation on XLR · 26f5ae86
      Jayachandran C 提交于
      The commit 2a37b1ae "MIPS: Netlogic: Move from u32 cpumask to cpumask_t"
      breaks uniprocessor compilation on XLR with:
      
      arch/mips/netlogic/xlr/setup.c: In function 'prom_init':
      arch/mips/netlogic/xlr/setup.c:196:6: error: unused variable 'i'
      
      Fix by defining 'i' only when CONFIG_SMP is defined.
      Signed-off-by: NJayachandran C <jchandra@broadcom.com>
      Patchwork: http://patchwork.linux-mips.org/patch/4760/Signed-off-by: NJohn Crispin <blogic@openwrt.org>
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      26f5ae86
    • G
      MIPS: AR71xx: Fix AR71XX_PCI_MEM_SIZE · fe950df7
      Gabor Juhos 提交于
      The base address of the PCI memory is 0x10000000 and the base address of the
      PCI configuration space is 0x17000000 on the AR71xx SoCs.
      
      The AR71XX_PCI_MEM_SIZE is defined as 0x08000000 which is wrong because that
      overlaps with the configuration space.  This patch fixes the value of the
      AR71XX_PCI_MEM_SIZE constant, in order to avoid this resource conflicts.
      Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
      Patchwork: http://patchwork.linux-mips.org/patch/4873/Signed-off-by: NJohn Crispin <blogic@openwrt.org>
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      fe950df7
    • G
      MIPS: AR724x: Fix AR724X_PCI_MEM_SIZE · 4c960910
      Gabor Juhos 提交于
      The base address of the PCI memory is
      0x10000000 and the base address of the
      PCI configuration space is 0x14000000
      on the AR724x SoCs.
      
      The AR724X_PCI_MEM_SIZE is defined as
      0x08000000 which is wrong because that
      overlaps  with the configuration space.
      
      The patch fixes the value of the
      AR724X_PCI_MEM_SIZE constant, in order
      to avoid this resource conflicts.
      Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
      Patchwork: http://patchwork.linux-mips.org/patch/4872/Signed-off-by: NJohn Crispin <blogic@openwrt.org>
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      4c960910
    • J
      MIPS: Lantiq: Fix cp0_perfcount_irq mapping · 79d61a04
      John Crispin 提交于
      The introduction of the OF support broke the cp0_perfcount_irq mapping. This
      resulted in oprofile not working anymore.
      
      Offending commit is :
      
      commit 3645da02
      Author: John Crispin <blogic@openwrt.org>
      Date:   Tue Apr 17 10:18:32 2012 +0200
      
      OF: MIPS: lantiq: implement irq_domain support
      Signed-off-by: NConor O'Gorman <i@conorogorman.net>
      Signed-off-by: NJohn Crispin <blogic@openwrt.org>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/4875/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      79d61a04
    • M
      efi: Make 'efi_enabled' a function to query EFI facilities · 83e68189
      Matt Fleming 提交于
      Originally 'efi_enabled' indicated whether a kernel was booted from
      EFI firmware. Over time its semantics have changed, and it now
      indicates whether or not we are booted on an EFI machine with
      bit-native firmware, e.g. 64-bit kernel with 64-bit firmware.
      
      The immediate motivation for this patch is the bug report at,
      
          https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557
      
      which details how running a platform driver on an EFI machine that is
      designed to run under BIOS can cause the machine to become
      bricked. Also, the following report,
      
          https://bugzilla.kernel.org/show_bug.cgi?id=47121
      
      details how running said driver can also cause Machine Check
      Exceptions. Drivers need a new means of detecting whether they're
      running on an EFI machine, as sadly the expression,
      
          if (!efi_enabled)
      
      hasn't been a sufficient condition for quite some time.
      
      Users actually want to query 'efi_enabled' for different reasons -
      what they really want access to is the list of available EFI
      facilities.
      
      For instance, the x86 reboot code needs to know whether it can invoke
      the ResetSystem() function provided by the EFI runtime services, while
      the ACPI OSL code wants to know whether the EFI config tables were
      mapped successfully. There are also checks in some of the platform
      driver code to simply see if they're running on an EFI machine (which
      would make it a bad idea to do BIOS-y things).
      
      This patch is a prereq for the samsung-laptop fix patch.
      
      Cc: David Airlie <airlied@linux.ie>
      Cc: Corentin Chary <corentincj@iksaif.net>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Dave Jiang <dave.jiang@intel.com>
      Cc: Olof Johansson <olof@lixom.net>
      Cc: Peter Jones <pjones@redhat.com>
      Cc: Colin Ian King <colin.king@canonical.com>
      Cc: Steve Langasek <steve.langasek@canonical.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      83e68189
  7. 30 1月, 2013 1 次提交
  8. 29 1月, 2013 6 次提交
    • G
      xtensa: Provide dummy dma_mmap_coherent() and dma_get_sgtable() · da57b936
      Geert Uytterhoeven 提交于
      xtensa/allmodconfig:
      
      drivers/media/v4l2-core/videobuf2-dma-contig.c: In function ‘vb2_dc_mmap’:
      drivers/media/v4l2-core/videobuf2-dma-contig.c:204: error: implicit declaration of function ‘dma_mmap_coherent’
      drivers/media/v4l2-core/videobuf2-dma-contig.c: In function ‘vb2_dc_get_base_sgt’:
      drivers/media/v4l2-core/videobuf2-dma-contig.c:387: error: implicit declaration of function ‘dma_get_sgtable’
      
      For architectures using dma_map_ops, dma_mmap_coherent() and
      dma_get_sgtable() are provided in <asm-generic/dma-mapping-common.h>.
      
      Xtensa does not use dma_map_ops, hence it should implement them itself.
      For now, use dummy implementations that just return -EINVAL, until the API
      has been finalized.
      Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      Cc: Marek Szyprowski <m.szyprowski@samsung.com>
      Cc: linux-xtensa@linux-xtensa.org
      Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
      da57b936
    • G
      parisc: Provide dummy dma_mmap_coherent() and dma_get_sgtable() · 59bb8407
      Geert Uytterhoeven 提交于
      parisc/allmodconfig:
      
      drivers/media/v4l2-core/videobuf2-dma-contig.c: In function ‘vb2_dc_mmap’:
      drivers/media/v4l2-core/videobuf2-dma-contig.c:204: error: implicit declaration of function ‘dma_mmap_coherent’
      drivers/media/v4l2-core/videobuf2-dma-contig.c: In function ‘vb2_dc_get_base_sgt’:
      drivers/media/v4l2-core/videobuf2-dma-contig.c:387: error: implicit declaration of function ‘dma_get_sgtable’
      
      For architectures using dma_map_ops, dma_mmap_coherent() and
      dma_get_sgtable() are provided in <asm-generic/dma-mapping-common.h>.
      
      Parisc does not use dma_map_ops, hence it should implement them itself.
      For now, use dummy implementations that just return -EINVAL, until the
      API has been finalized, as it cannot be supported on PA-RISC as-is.
      Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      Cc: Marek Szyprowski <m.szyprowski@samsung.com>
      Cc: James Bottomley <James.Bottomley@hansenpartnership.com>
      Cc: linux-parisc@vger.kernel.org
      Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
      59bb8407
    • G
      mn10300: Provide dummy dma_mmap_coherent() and dma_get_sgtable() · 90582b2a
      Geert Uytterhoeven 提交于
      mn10300/allmodconfig:
      
      drivers/media/v4l2-core/videobuf2-dma-contig.c: In function ‘vb2_dc_mmap’:
      drivers/media/v4l2-core/videobuf2-dma-contig.c:204: error: implicit declaration of function ‘dma_mmap_coherent’
      drivers/media/v4l2-core/videobuf2-dma-contig.c: In function ‘vb2_dc_get_base_sgt’:
      drivers/media/v4l2-core/videobuf2-dma-contig.c:387: error: implicit declaration of function ‘dma_get_sgtable’
      
      For architectures using dma_map_ops, dma_mmap_coherent() and
      dma_get_sgtable() are provided in <asm-generic/dma-mapping-common.h>.
      
      Mn10300 does not use dma_map_ops, hence it should implement them itself.
      For now, use dummy implementations that just return -EINVAL, until the API
      has been finalized.
      Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      Cc: Marek Szyprowski <m.szyprowski@samsung.com>
      Cc: linux-am33-list@redhat.com
      Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
      90582b2a
    • G
      m68k: Provide dma_mmap_coherent() and dma_get_sgtable() · 546eda4b
      Geert Uytterhoeven 提交于
      m68k/allmodconfig:
      
      drivers/media/v4l2-core/videobuf2-dma-contig.c: In function ‘vb2_dc_mmap’:
      drivers/media/v4l2-core/videobuf2-dma-contig.c:204: error: implicit declaration of function ‘dma_mmap_coherent’
      drivers/media/v4l2-core/videobuf2-dma-contig.c: In function ‘vb2_dc_get_base_sgt’:
      drivers/media/v4l2-core/videobuf2-dma-contig.c:387: error: implicit declaration of function ‘dma_get_sgtable’
      
      For architectures using dma_map_ops, dma_mmap_coherent() and
      dma_get_sgtable() are provided in <asm-generic/dma-mapping-common.h>.
      
      M68k does not use dma_map_ops, hence it should implement them as inline
      stubs using dma_common_mmap() and dma_common_get_sgtable().
      Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      Cc: Marek Szyprowski <m.szyprowski@samsung.com>
      Cc: linux-m68k@lists.linux-m68k.org
      Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
      546eda4b
    • G
      frv: Provide dummy dma_mmap_coherent() and dma_get_sgtable() · 5fd38112
      Geert Uytterhoeven 提交于
      frv/allmodconfig:
      
      drivers/media/v4l2-core/videobuf2-dma-contig.c: In function ‘vb2_dc_mmap’:
      drivers/media/v4l2-core/videobuf2-dma-contig.c:204: error: implicit declaration of function ‘dma_mmap_coherent’
      drivers/media/v4l2-core/videobuf2-dma-contig.c: In function ‘vb2_dc_get_base_sgt’:
      drivers/media/v4l2-core/videobuf2-dma-contig.c:387: error: implicit declaration of function ‘dma_get_sgtable’
      
      For architectures using dma_map_ops, dma_mmap_coherent() and
      dma_get_sgtable() are provided in <asm-generic/dma-mapping-common.h>.
      
      Frv does not use dma_map_ops, hence it should implement them itself.
      For now, use dummy implementations that just return -EINVAL, until the API
      has been finalized.
      Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      Cc: Marek Szyprowski <m.szyprowski@samsung.com>
      Cc: David Howells <dhowells@redhat.com>
      Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
      5fd38112
    • G
      cris: Provide dma_mmap_coherent() and dma_get_sgtable() · 063aceba
      Geert Uytterhoeven 提交于
      cris/allmodconfig:
      
      drivers/media/v4l2-core/videobuf2-dma-contig.c: In function ‘vb2_dc_mmap’:
      drivers/media/v4l2-core/videobuf2-dma-contig.c:204: error: implicit declaration of function ‘dma_mmap_coherent’
      drivers/media/v4l2-core/videobuf2-dma-contig.c: In function ‘vb2_dc_get_base_sgt’:
      drivers/media/v4l2-core/videobuf2-dma-contig.c:387: error: implicit declaration of function ‘dma_get_sgtable’
      
      For architectures using dma_map_ops, dma_mmap_coherent() and
      dma_get_sgtable() are provided in <asm-generic/dma-mapping-common.h>.
      
      Cris does not use dma_map_ops, hence it should implement them as inline
      stubs using dma_common_mmap() and dma_common_get_sgtable().
      Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      Cc: Marek Szyprowski <m.szyprowski@samsung.com>
      Cc: linux-cris-kernel@axis.com
      Acked-by: NJesper Nilsson <jesper.nilsson@axis.com>
      Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
      063aceba