1. 14 2月, 2013 12 次提交
    • A
      Merge branch 'warning-fixes' into next/fixes-non-critical · 7822eee1
      Arnd Bergmann 提交于
      These are fixes for compiler warnings that for the most
      part were introduced during the 3.8 cycle but are otherwise
      harmless.
      
      * warning-fixes:
        scripts/sortextable: silence script output
        ARM: s3c: i2c: add platform_device forward declaration
        ARM: mvebu: allow selecting mvebu without Armada XP
        ARM: pick Versatile by default for !MMU
        ARM: integrator: fix build with INTEGRATOR_AP off
        ARM: integrator/versatile: fix NOMMU warnings
        ARM: sa1100: don't warn about mach/ide.h
        ARM: shmobile: fix defconfig warning on CONFIG_USB
        ARM: w90x900: fix legacy assembly syntax
        ARM: samsung: fix assembly syntax for new gas
        ARM: disable virt_to_bus/virt_to_bus almost everywhere
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      7822eee1
    • A
      scripts/sortextable: silence script output · 8c0c774d
      Arnd Bergmann 提交于
      The exception table sorter outputs one line every time
      it gets called, e.g. 'sort done marker at 66dc00', which
      is slightly annoying when doing 'make -s' which is otherwise
      completely silent. Since that output is not helpful to
      most people building the kernel, turn it off by default.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NDavid Daney <david.daney@cavium.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      8c0c774d
    • A
      ARM: s3c: i2c: add platform_device forward declaration · b2dc0c2b
      Arnd Bergmann 提交于
      A recent cleanup to the mach-osiris.c file is causing build errors
      because the i2c-s3c2410.h header file is included before we see
      the definition for platform_device. The fix is to make the header file
      more robust against inclusion from other places. While this should
      normally go through the i2c tree, the bug only exists in arm-soc
      at the moment, so it's easier to fix it there before it goes upstream.
      
      Without this patch, building s3c2410_defconfig results in:
      
      arch/arm/mach-s3c24xx/mach-osiris.c:34:0:
      include/linux/platform_data/i2c-s3c2410.h:37:26: warning: 'struct platform_device' declared inside parameter list [enabled by default]
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: linux-i2c@vger.kernel.org
      Cc: Wolfram Sang <w.sang@pengutronix.de>
      Cc: Ben Dooks <ben-linux@fluff.org>
      Cc: Kukjin Kim <kgene.kim@samsung.com>
      b2dc0c2b
    • A
      ARM: mvebu: allow selecting mvebu without Armada XP · 81c724ab
      Arnd Bergmann 提交于
      Selecting only CONFIG_ARCH_MVEBU but not the respective
      options for Armada 370 or Armada XP results in these
      link errors:
      
      arch/arm/mach-mvebu/built-in.o: In function `armada_xp_smp_init_cpus':
      arch/arm/mach-mvebu/platsmp.c:91: undefined reference to `coherency_get_cpu_count'
      arch/arm/mach-mvebu/platsmp.c:104: undefined reference to `armada_mpic_send_doorbell'
      arch/arm/mach-mvebu/built-in.o: In function `armada_xp_smp_prepare_cpus':
      arch/arm/mach-mvebu/platsmp.c:111: undefined reference to `set_cpu_coherent'
      arch/arm/mach-mvebu/built-in.o: In function `armada_xp_boot_secondary':
      arch/arm/mach-mvebu/platsmp.c:83: undefined reference to `armada_xp_boot_cpu'
      arch/arm/mach-mvebu/built-in.o: In function `armada_xp_secondary_init':
      arch/arm/mach-mvebu/platsmp.c:75: undefined reference to `armada_xp_mpic_smp_cpu_init'
      arch/arm/mach-mvebu/built-in.o: In function `armada_xp_secondary_startup':
      arch/arm/mach-mvebu/headsmp.S:46: undefined reference to `ll_set_cpu_coherent'
      
      We can solve this by enabling all common MVEBU files that are
      referenced by the SMP files. This means we enable code that
      is not going to be used without a machine descriptor referencing
      it, but only if the kernel is configured specifically for this
      case.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: Gregory Clement <gregory.clement@free-electrons.com>
      Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
      81c724ab
    • A
      ARM: pick Versatile by default for !MMU · 1420b22b
      Arnd Bergmann 提交于
      The introduction of ARCH_MULTIPLATFORM changed
      the default for nommu kernels from Versatile to
      Integrator, which is less common, and does not
      currently build for allnoconfig because that does
      not select any of the CPUs.
      
      This also ensures that at least one of the three
      board files in versatile are enabled, which lets
      us successfully build an allnoconfig kernel.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: Russell King <linux@arm.linux.org.uk>
      1420b22b
    • A
      ARM: integrator: fix build with INTEGRATOR_AP off · a02e0a83
      Arnd Bergmann 提交于
      The conditional declaration of ap_uart_data is broken
      and causes this build error:
      
      In file included from arch/arm/mach-integrator/core.c:35:0:
      arch/arm/mach-integrator/common.h:6:37: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
      
      Turning the check into an constant-expression if(IS_ENABLED()) statement
      creates more readable code and solves this problem as well.
      
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: Russell King <linux@arm.linux.org.uk>
      a02e0a83
    • A
      ARM: integrator/versatile: fix NOMMU warnings · 060fd1be
      Arnd Bergmann 提交于
      On NOMMU kernels, the io_desc variables are unused
      because we don't use the MMU to remap the MMIO
      areas.
      
      Marking these variables as __maybe_unused easily
      avoids the otherwise harmless warnings like
      
      warning: 'versatile_io_desc' defined but not used
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: Russell King <linux@arm.linux.org.uk>
      060fd1be
    • A
      ARM: sa1100: don't warn about mach/ide.h · 29408ed9
      Arnd Bergmann 提交于
      This warning has existed since before the start of (git) history.
      Apparently nobody has bothered to fix it in a long time, and
      this is unlikely to change. Note that the file that the warning
      refers to has moved to a different location and was subsequently
      deleted in 2008.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: Russell King <linux@arm.linux.org.uk>
      29408ed9
    • A
      ARM: shmobile: fix defconfig warning on CONFIG_USB · bb57d4e3
      Arnd Bergmann 提交于
      A recent update to the marzen_defconfig introduced a
      duplicate CONFIG_USB=y line. This removes one of the
      two.
      
      arch/arm/configs/marzen_defconfig:86:warning: override: reassigning to symbol USB
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NSimon Horman <horms+renesas@verge.net.au>
      Cc: linux-sh@vger.kernel.org
      bb57d4e3
    • A
      ARM: w90x900: fix legacy assembly syntax · fa5ce5f9
      Arnd Bergmann 提交于
      New ARM binutils don't allow extraneous whitespace inside
      of brackets, which causes this error on all mach-w90x900
      defconfigs:
      
      arch/arm/kernel/entry-armv.S: Assembler messages:
      arch/arm/kernel/entry-armv.S:214: Error: ARM register expected -- `ldr r0,[ r6,#(0x10C)]'
      arch/arm/kernel/entry-armv.S:214: Error: ARM register expected -- `ldr r0,[ r6,#(0x110)]'
      arch/arm/kernel/entry-armv.S:430: Error: ARM register expected -- `ldr r0,[ r6,#(0x10C)]'
      arch/arm/kernel/entry-armv.S:430: Error: ARM register expected -- `ldr r0,[ r6,#(0x110)]'
      
      This removes the whitespace in order to build the kernel
      again.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: Wan ZongShun <mcuos.com@gmail.com>
      fa5ce5f9
    • A
      ARM: samsung: fix assembly syntax for new gas · 2815774b
      Arnd Bergmann 提交于
      Recent assembler versions complain about extraneous
      whitespace inside [] brackets. This fixes all of
      these instances for the samsung platforms. We should
      backport this to all kernels that might need to
      be built with new binutils.
      
      arch/arm/kernel/entry-armv.S: Assembler messages:
      arch/arm/kernel/entry-armv.S:214: Error: ARM register expected -- `ldr r2,[ r6,#(0x10)]'
      arch/arm/kernel/entry-armv.S:214: Error: ARM register expected -- `ldr r0,[ r6,#(0x14)]'
      arch/arm/kernel/entry-armv.S:430: Error: ARM register expected -- `ldr r2,[ r6,#(0x10)]'
      arch/arm/kernel/entry-armv.S:430: Error: ARM register expected -- `ldr r0,[ r6,#(0x14)]'
      arch/arm/mach-s3c24xx/sleep-s3c2410.S: Assembler messages:
      arch/arm/mach-s3c24xx/sleep-s3c2410.S:48: Error: ARM register expected -- `ldr r7,[ r4 ]'
      arch/arm/mach-s3c24xx/sleep-s3c2410.S:49: Error: ARM register expected -- `ldr r8,[ r5 ]'
      arch/arm/mach-s3c24xx/sleep-s3c2410.S:50: Error: ARM register expected -- `ldr r9,[ r6 ]'
      arch/arm/mach-s3c24xx/sleep-s3c2410.S:64: Error: ARM register expected -- `streq r7,[ r4 ]'
      arch/arm/mach-s3c24xx/sleep-s3c2410.S:65: Error: ARM register expected -- `streq r8,[ r5 ]'
      arch/arm/mach-s3c24xx/sleep-s3c2410.S:66: Error: ARM register expected -- `streq r9,[ r6 ]'
      arch/arm/kernel/debug.S: Assembler messages:
      arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r2,#((0x0B0)+(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000))))-((0)+(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000))))]'
      arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r3,#(0x18)]'
      arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r2,#((0x0B0)+(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000))))-((0)+(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000))))]'
      arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r3,#(0x18)]'
      arch/arm/mach-s3c24xx/pm-h1940.S: Assembler messages:
      arch/arm/mach-s3c24xx/pm-h1940.S:33: Error: ARM register expected -- `ldr pc,[ r0,#((0x0B8)+(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000))))-(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000)))]'
      arch/arm/mach-s3c24xx/sleep-s3c2412.S: Assembler messages:
      arch/arm/mach-s3c24xx/sleep-s3c2412.S:60: Error: ARM register expected -- `ldrne r9,[ r1 ]'
      arch/arm/mach-s3c24xx/sleep-s3c2412.S:61: Error: ARM register expected -- `strne r9,[ r1 ]'
      arch/arm/mach-s3c24xx/sleep-s3c2412.S:62: Error: ARM register expected -- `ldrne r9,[ r2 ]'
      arch/arm/mach-s3c24xx/sleep-s3c2412.S:63: Error: ARM register expected -- `strne r9,[ r2 ]'
      arch/arm/mach-s3c24xx/sleep-s3c2412.S:64: Error: ARM register expected -- `ldrne r9,[ r3 ]'
      arch/arm/mach-s3c24xx/sleep-s3c2412.S:65: Error: ARM register expected -- `strne r9,[ r3 ]'
      arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r3,#(0x08)]'
      arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r3,#(0x18)]'
      arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r3,#(0x10)]'
      arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r3,#(0x08)]'
      arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r3,#(0x18)]'
      arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r3,#(0x10)]'
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NKukjin Kim <kgene.kim@samsung.com>
      Cc: Ben Dooks <ben-linux@fluff.org>
      Cc: stable@vger.kernel.org
      2815774b
    • A
      ARM: disable virt_to_bus/virt_to_bus almost everywhere · a5d533ee
      Arnd Bergmann 提交于
      We are getting a number of warnings about the use of the deprecated
      bus_to_virt function in drivers using the ARM ISA DMA API:
      
      drivers/parport/parport_pc.c: In function 'parport_pc_fifo_write_block_dma':
      drivers/parport/parport_pc.c:622:3: warning: 'bus_to_virt' is deprecated
      (declared at arch/arm/include/asm/memory.h:253) [-Wdeprecated-declarations]
      
      This is only because that function gets used by the inline
      set_dma_addr() helper. We know that any driver for the ISA DMA API
      is correctly using the DMA addresses, so we can change this
      to use the __bus_to_virt() function instead, which does not warn.
      
      After this, there are no remaining drivers that are used on
      any defconfigs on ARM using virt_to_bus or bus_to_virt, with
      the exception of the OSS sound driver. That driver is only used
      on RiscPC, NetWinder and Shark, so we can set ARCH_NO_VIRT_TO_BUS
      on all other platforms and hide the deprecated functions, which
      is far more effective than marking them as deprecated, in order
      to avoid any new users of that code.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: Russell King <linux@arm.linux.org.uk>
      a5d533ee
  2. 13 2月, 2013 2 次提交
    • O
      Merge tag 'at91-fixes' of git://github.com/at91linux/linux-at91 into next/fixes-non-critical · 0e55f0b0
      Olof Johansson 提交于
      From Nicolas Ferre:
      Correction of 9x5 and 9n12 USART nodes
      
      * tag 'at91-fixes' of git://github.com/at91linux/linux-at91:
        ARM: at91/DT: remove atmel,use-dma-* from 9x5 and 9n12 USART nodes
      0e55f0b0
    • O
      Merge branch 'fixes-for-3.9' into next/fixes-non-critical · cae617b6
      Olof Johansson 提交于
      This is a branch of fixes that originally were scheduled for 3.8 but
      due to the request from Linus to hold back on all but the most critical
      of fixes, we're re-queueing them for 3.9 here.
      
      * fixes-for-3.9:
        ARM: dts: imx6: fix fec ptp clock slow 10 time
        ARM: highbank: mask cluster id from cpu_logical_map
        ARM: scu: mask cluster id from cpu_logical_map
        ARM: scu: add empty scu_enable for !CONFIG_SMP
        ARM: at91/at91sam9x5.dtsi: fix usart3 TXD
        ARM: at91: at91sam9x5: fix usart3 pinctrl name
        ARM: EXYNOS: Fix crash on soft reset on EXYNOS5440
        ARM: dts: fix tick and alarm irq numbers for exynos5440
        ARM: dts: fix compatible value for exynos pinctrl
        ARM: dts: Fix compatible value of pinctrl module on EXYNOS5440
        ARM: S3C24XX: fix uninitialized variable warning
        mfd/vexpress: vexpress_sysreg_setup must not be __init
        ARM: ux500: Fix u9540 booting issues
        arm: mvebu: i2c come back in defconfig
        arm: plat-orion: fix printing of "MPP config unavailable on this hardware"
        Dove: activate GPIO interrupts in DT
        ARM: ux500: add spin_unlock(&master_lock).
        ARM: ux500: Disable Power Supply and Battery Management by default
      Signed-off-by: NOlof Johansson <olof@lixom.net>
      cae617b6
  3. 12 2月, 2013 1 次提交
    • A
      ARM: msm: proc_comm_boot_wait should not be __init · 389d2111
      Arnd Bergmann 提交于
      msm_smd_probe is a driver probe function and may get
      called after the __init time, so it must not call
      any __init function, as the link-time warning reports.
      Take away the __init annotation on proc_comm_boot_wait
      to fix this.
      
      Without this patch, building msm_defconfig results in:
      
      WARNING: vmlinux.o(.text+0xb048): Section mismatch in reference from the function msm_smd_probe() to the function .init.text:proc_comm_boot_wait()
      The function msm_smd_probe() references
      the function __init proc_comm_boot_wait().
      This is often because msm_smd_probe lacks a __init
      annotation or the annotation of proc_comm_boot_wait is wrong.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: Bryan Huntsman <bryanh@codeaurora.org>
      Cc: Daniel Walker <c_dwalke@quicinc.com>
      Cc: linux-arm-msm@vger.kernel.org
      Acked-by: NDavid Brown <davidb@codeaurora.org>
      Signed-off-by: NOlof Johansson <olof@lixom.net>
      389d2111
  4. 10 2月, 2013 2 次提交
  5. 06 2月, 2013 3 次提交
  6. 05 2月, 2013 3 次提交
  7. 02 2月, 2013 3 次提交
  8. 01 2月, 2013 9 次提交
  9. 31 1月, 2013 5 次提交
    • 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
    • A
      dm: fix write same requests counting · fe7af2d3
      Alasdair G Kergon 提交于
      When processing write same requests, fix dm to send the configured
      number of WRITE SAME requests to the target rather than the number of
      discards, which is not always the same.
      
      Device-mapper WRITE SAME support was introduced by commit
      23508a96 ("dm: add WRITE SAME support").
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      Acked-by: NMike Snitzer <snitzer@redhat.com>
      fe7af2d3
    • 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
    • M
      dm thin: fix queue limits stacking · 0f640dca
      Mike Snitzer 提交于
      thin_io_hints() is blindly copying the queue limits from the thin-pool
      which can lead to incorrect limits being set.  The fix here simply
      deletes the thin_io_hints() hook which leaves the existing stacking
      infrastructure to set the limits correctly.
      
      When a thin-pool uses an MD device for the data device a thin device
      from the thin-pool must respect MD's constraints about disallowing a bio
      from spanning multiple chunks.  Otherwise we can see problems.  If the raid0
      chunksize is 1152K and thin-pool chunksize is 256K I see the following
      md/raid0 error (with extra debug tracing added to thin_endio) when
      mkfs.xfs is executed against the thin device:
      
      md/raid0:md99: make_request bug: can't convert block across chunks or bigger than 1152k 6688 127
      device-mapper: thin: bio sector=2080 err=-5 bi_size=130560 bi_rw=17 bi_vcnt=32 bi_idx=0
      
      This extra DM debugging shows that the failing bio is spanning across
      the first and second logical 1152K chunk (sector 2080 + 255 takes the
      bio beyond the first chunk's boundary of sector 2304).  So the bio
      splitting that DM is doing clearly isn't respecting the MD limits.
      
      max_hw_sectors_kb is 127 for both the thin-pool and thin device
      (queue_max_hw_sectors returns 255 so we'll excuse sysfs's lack of
      precision).  So this explains why bi_size is 130560.
      
      But the thin device's max_hw_sectors_kb should be 4 (PAGE_SIZE) given
      that it doesn't have a .merge function (for bio_add_page to consult
      indirectly via dm_merge_bvec) yet the thin-pool does sit above an MD
      device that has a compulsory merge_bvec_fn.  This scenario is exactly
      why DM must resort to sending single PAGE_SIZE bios to the underlying
      layer. Some additional context for this is available in the header for
      commit 8cbeb67a ("dm: avoid unsupported spanning of md stripe boundaries").
      
      Long story short, the reason a thin device doesn't properly get
      configured to have a max_hw_sectors_kb of 4 (PAGE_SIZE) is that
      thin_io_hints() is blindly copying the queue limits from the thin-pool
      device directly to the thin device's queue limits.
      
      Fix this by eliminating thin_io_hints.  Doing so is safe because the
      block layer's queue limits stacking already enables the upper level thin
      device to inherit the thin-pool device's discard and minimum_io_size and
      optimal_io_size limits that get set in pool_io_hints.  But avoiding the
      queue limits copy allows the thin and thin-pool limits to be different
      where it is important, namely max_hw_sectors_kb.
      Reported-by: NDaniel Browning <db@kavod.com>
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
      0f640dca
    • L
      Merge branch 'x86-efi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 04c2eee5
      Linus Torvalds 提交于
      Pull x86 EFI fixes from Peter Anvin:
       "This is a collection of fixes for the EFI support.  The controversial
        bit here is a set of patches which bumps the boot protocol version as
        part of fixing some serious problems with the EFI handover protocol,
        used when booting under EFI using a bootloader as opposed to directly
        from EFI.  These changes should also make it a lot saner to support
        cross-mode 32/64-bit EFI booting in the future.  Getting these changes
        into 3.8 means we avoid presenting an inconsistent ABI to bootloaders.
      
        Other changes are display detection and fixing efivarfs."
      
      * 'x86-efi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        x86, efi: remove attribute check from setup_efi_pci
        x86, build: Dynamically find entry points in compressed startup code
        x86, efi: Fix PCI ROM handing in EFI boot stub, in 32-bit mode
        x86, efi: Fix 32-bit EFI handover protocol entry point
        x86, efi: Fix display detection in EFI boot stub
        x86, boot: Define the 2.12 bzImage boot protocol
        x86/boot: Fix minor fd leakage in tools/relocs.c
        x86, efi: Set runtime_version to the EFI spec revision
        x86, efi: fix 32-bit warnings in setup_efi_pci()
        efivarfs: Delete dentry from dcache in efivarfs_file_write()
        efivarfs: Never return ENOENT from firmware
        efi, x86: Pass a proper identity mapping in efi_call_phys_prelog
        efivarfs: Drop link count of the right inode
      04c2eee5