1. 17 Mar, 2016 8 commits
    • Rich Felker's avatar
      sh: add SMP method selection to device tree pseudo-board · 044b81f8
      Rich Felker authored
      Allow selection of plat_smp_ops based on the enable-method cpu
      property from device tree and provide dummy ops for booting with a
      device tree that does not enable SMP.
      Signed-off-by: default avatarRich Felker <dalias@libc.org>
    • Rich Felker's avatar
      sh: add device tree support and generic board using device tree · 7480e0aa
      Rich Felker authored
      Add a new pseudo-board, within the existing SH boards/machine-vectors
      framework, which does not represent any actual hardware but instead
      requires all hardware to be described by the device tree blob provided
      by the boot loader. Changes made are thus non-invasive and do not risk
      breaking support for legacy boards.
      New hardware, including the open-hardware J2 and associated SoC
      devices, will use device free from the outset. Legacy SH boards can
      transition to device tree once all their hardware has device tree
      bindings, driver support for device tree, and a dts file for the
      It is intented that, once all boards are supported in the new
      framework, the existing machine-vectors framework should be removed
      and the new device tree setup code integrated directly.
      Signed-off-by: default avatarRich Felker <dalias@libc.org>
    • Rich Felker's avatar
      sh: remove arch-specific localtimer and use generic one · 45624ac3
      Rich Felker authored
      The code being removed was copied from arm, where the corresponding
      code was removed in 2013. The only functional change should be that
      the rating of the dummy local timer changes from 400 to 100.
      Signed-off-by: default avatarRich Felker <dalias@libc.org>
    • Rich Felker's avatar
      sh: make MMU-specific SMP code conditional on CONFIG_MMU · 5f2cb34d
      Rich Felker authored
      This is a prerequisite for adding NOMMU SMP support.
      Signed-off-by: default avatarRich Felker <dalias@libc.org>
    • Rich Felker's avatar
      sh: provide unified syscall trap compatible with all SH models · 3623d138
      Rich Felker authored
      Historically SH-2 Linux (and originally uClinux) used a syscall
      calling convention incompatible with the established SH-3/4 Linux ABI.
      This choice was made because the trap range used by the existing ABI,
      0x10-0x17, overlaps with the hardware exception/interrupt trap range
      reserved by SH-2, and in particular, with the SH-2A divide-by-zero and
      division-overflow exceptions.
      Despite the documented syscall convention using the low bits of the
      trap number to signal the number of arguments the kernel should
      expect, no version of the kernel has ever used this information, nor
      is it useful; all of the registers need to be saved anyway. Therefore,
      it is possible to pick a new trap number, 0x1f, that is both supported
      by all existing SH-3/4 kernels and unassigned as a hardware trap in
      the SH-2 range. This makes it possible to produce SH-2 application
      binaries that are forwards-compatible with running on SH-3/4 kernels
      and to treat SH as a unified platform with varying ISA support levels
      rather than multiple gratuitously-incompatible platforms.
      This patch adjusts the range checking SH-2 and SH-2A kernels make for
      the syscall trap to accept the range 0x1f-0x2f rather than just
      0x20-0x2f. As a result, trap 0x1f now acts as a syscall for all SH
      Signed-off-by: default avatarRich Felker <dalias@libc.org>
    • Yoshinori Sato's avatar
      sh: New gcc support · 940d4113
      Yoshinori Sato authored
      New gcc (4.8 or later) used new shift helper functions.
      So we need added new helper to private libgcc.
      Signed-off-by: default avatarYoshinori Sato <ysato@users.sourceforge.jp>
      Signed-off-by: default avatarRich Felker <dalias@libc.org>
    • Yoshinori Sato's avatar
    • Stephen Boyd's avatar
      sh: Use generic clkdev.h header · ea17c9d8
      Stephen Boyd authored
      The generic header file is almost equivalent to the SH one. The
      only difference is that the SH one supports allocating clkdev
      lookups early using bootmem allocators instead of the slabs. From
      what I can tell using visual inspection, the slab is initialized
      before any clkdev allocation is made under arch/sh. So let's
      remove the arch specific clkdev.h header and use the generic one
      Signed-off-by: default avatarStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: default avatarRich Felker <dalias@libc.org>
  2. 13 Mar, 2016 6 commits
  3. 12 Mar, 2016 6 commits
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.dk/linux-block · f414ca64
      Linus Torvalds authored
      Pull block merge fix from Jens Axboe.
      This fixes the block segment counting bug and resulting sg overrun
      reported by Kent Overstreet, introduced with the last block pull.
      * 'for-linus' of git://git.kernel.dk/linux-block:
        block: don't optimize for non-cloned bio in bio_get_last_bvec()
    • Linus Torvalds's avatar
      Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 2f51c820
      Linus Torvalds authored
      Pull x86 fixes from Ingo Molnar:
       "This fixes 3 FPU handling related bugs, an EFI boot crash and a
        runtime warning.
        The EFI fix arrived late but I didn't want to delay it to after v4.5
        because the effects are pretty bad for the systems that are affected
        by it"
      [ Actually, I don't think the EFI fix really matters yet, because we
        haven't switched to the separate EFI page tables in mainline yet ]
      * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        x86/efi: Fix boot crash by always mapping boot service regions into new EFI page tables
        x86/fpu: Fix eager-FPU handling on legacy FPU machines
        x86/delay: Avoid preemptible context checks in delay_mwaitx()
        x86/fpu: Revert ("x86/fpu: Disable AVX when eagerfpu is off")
        x86/fpu: Fix 'no387' regression
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending · fda604a4
      Linus Torvalds authored
      Pull SCSI target bug fix from Nicholas Bellinger:
       "Here is an outstanding target-core bug-fix for v4.5 code."
        This patch addresses a recent Task Management (TMR) regression related
        to larger set of multi-port LUN_RESET bug-fixes in v4.5-rc5.
        It drops a left-over target_put_sess_cmd() of se_cmd->cmd_kref within
        ABORT_TASK failure path, once a se_cmd descriptor has already
        completed posting response to fabric driver logic, and must be skipped
        during normal ABORT_TASK se_cmd->tag lookup"
      * git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending:
        target: Drop incorrect ABORT_TASK put for completed commands
    • Ming Lei's avatar
      block: don't optimize for non-cloned bio in bio_get_last_bvec() · 90d0f0f1
      Ming Lei authored
      For !BIO_CLONED bio, we can use .bi_vcnt safely, but it
      doesn't mean we can just simply return .bi_io_vec[.bi_vcnt - 1]
      because the start postion may have been moved in the middle of
      the bvec, such as splitting in the middle of bvec.
      Fixes: 7bcd79ac
      (block: bio: introduce helpers to get the 1st and last bvec)
      Cc: stable@vger.kernel.org
      Reported-by: default avatarKent Overstreet <kent.overstreet@gmail.com>
      Signed-off-by: default avatarMing Lei <ming.lei@canonical.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
    • Matt Fleming's avatar
      x86/efi: Fix boot crash by always mapping boot service regions into new EFI page tables · 452308de
      Matt Fleming authored
      Some machines have EFI regions in page zero (physical address
      0x00000000) and historically that region has been added to the e820
      map via trim_bios_range(), and ultimately mapped into the kernel page
      tables. It was not mapped via efi_map_regions() as one would expect.
      Alexis reports that with the new separate EFI page tables some boot
      services regions, such as page zero, are not mapped. This triggers an
      oops during the SetVirtualAddressMap() runtime call.
      For the EFI boot services quirk on x86 we need to memblock_reserve()
      boot services regions until after SetVirtualAddressMap(). Doing that
      while respecting the ownership of regions that may have already been
      reserved by the kernel was the motivation behind this commit:
       ("x86, efi: Do not reserve boot services regions within reserved areas")
      That patch was merged at a time when the EFI runtime virtual mappings
      were inserted into the kernel page tables as described above, and the
      trick of setting ->numpages (and hence the region size) to zero to
      track regions that should not be freed in efi_free_boot_services()
      meant that we never mapped those regions in efi_map_regions(). Instead
      we were relying solely on the existing kernel mappings.
      Now that we have separate page tables we need to make sure the EFI
      boot services regions are mapped correctly, even if someone else has
      already called memblock_reserve(). Instead of stashing a tag in
      ->numpages, set the EFI_MEMORY_RUNTIME bit of ->attribute. Since it
      generally makes no sense to mark a boot services region as required at
      runtime, it's pretty much guaranteed the firmware will not have
      already set this bit.
      For the record, the specific circumstances under which Alexis
      triggered this bug was that an EFI runtime driver on his machine was
      responding to the EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE event during
      The event handler for this driver looks like this,
        sub rsp,0x28
        lea rdx,[rip+0x2445] # 0xaa948720
        mov ecx,0x4
        call func_aa9447c0  ; call to ConvertPointer(4, & 0xaa948720)
        mov r11,QWORD PTR [rip+0x2434] # 0xaa948720
        xor eax,eax
        mov BYTE PTR [r11+0x1],0x1
        add rsp,0x28
      Which is pretty typical code for an EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE
      handler. The "mov r11, QWORD PTR [rip+0x2424]" was the faulting
      instruction because ConvertPointer() was being called to convert the
      address 0x0000000000000000, which when converted is left unchanged and
      remains 0x0000000000000000.
      The output of the oops trace gave the impression of a standard NULL
      pointer dereference bug, but because we're accessing physical
      addresses during ConvertPointer(), it wasn't. EFI boot services code
      is stored at that address on Alexis' machine.
      Reported-by: default avatarAlexis Murzeau <amurzeau@gmail.com>
      Signed-off-by: default avatarMatt Fleming <matt@codeblueprint.co.uk>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Raphael Hertzog <hertzog@debian.org>
      Cc: Roger Shimizu <rogershimizu@gmail.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-efi@vger.kernel.org
      Link: http://lkml.kernel.org/r/1457695163-29632-2-git-send-email-matt@codeblueprint.co.uk
      Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815125
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
    • Borislav Petkov's avatar
      x86/fpu: Fix eager-FPU handling on legacy FPU machines · 6e686709
      Borislav Petkov authored
      i486 derived cores like Intel Quark support only the very old,
      legacy x87 FPU (FSAVE/FRSTOR, CPUID bit FXSR is not set), and
      our FPU code wasn't handling the saving and restoring there
      properly in the 'eagerfpu' case.
      So after we made eagerfpu the default for all CPU types:
       x86/fpu: Default eagerfpu=on on all CPUs
      these old FPU designs broke. First, Andy Shevchenko reported a splat:
        WARNING: CPU: 0 PID: 823 at arch/x86/include/asm/fpu/internal.h:163 fpu__clear+0x8c/0x160
      which was us trying to execute FXRSTOR on those machines even though
      they don't support it.
      After taking care of that, Bryan O'Donoghue reported that a simple FPU
      test still failed because we weren't initializing the FPU state properly
      on those machines.
      Take care of all that.
      Reported-and-tested-by: default avatarBryan O'Donoghue <pure.logic@nexus-software.ie>
      Reported-by: default avatarAndy Shevchenko <andy.shevchenko@gmail.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Acked-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Quentin Casasnovas <quentin.casasnovas@oracle.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Yu-cheng <yu-cheng.yu@intel.com>
      Link: http://lkml.kernel.org/r/20160311113206.GD4312@pd.tnic
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
  4. 11 Mar, 2016 12 commits
    • Linus Torvalds's avatar
      Merge tag 'for-linus-20160311' of git://git.infradead.org/linux-mtd · 03c668a9
      Linus Torvalds authored
      Pull MTD fixes from Brian Norris:
       "Late MTD fix for v4.5:
         - A simple error code handling fix for the NAND ECC test; this was a
           regression in v4.5-rc1
         - A MAINTAINERS update, which might as well go in ASAP"
      * tag 'for-linus-20160311' of git://git.infradead.org/linux-mtd:
        MAINTAINERS: add a maintainer for the NAND subsystem
        mtd: nand: tests: fix regression introduced in mtd_nandectest
    • Linus Torvalds's avatar
      Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux · 3ab0a0f9
      Linus Torvalds authored
      Pull drm/i915 fixes from Dave Airlie:
       "Just two i915 regression fixes, that should be it from me"
      * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
        drm/i915: Actually retry with bit-banging after GMBUS timeout
        drm/i915: Fix bogus dig_port_map[] assignment for pre-HSW
    • Matthew Dawson's avatar
      mm/mempool: avoid KASAN marking mempool poison checks as use-after-free · 76401310
      Matthew Dawson authored
      When removing an element from the mempool, mark it as unpoisoned in KASAN
      before verifying its contents for SLUB/SLAB debugging.  Otherwise KASAN
      will flag the reads checking the element use-after-free writes as
      use-after-free reads.
      Signed-off-by: default avatarMatthew Dawson <matthew@mjdsystems.ca>
      Acked-by: default avatarAndrey Ryabinin <aryabinin@virtuozzo.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    • Linus Torvalds's avatar
      Merge tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc · 2a4fb270
      Linus Torvalds authored
      Pull ARM SoC fixes from Olof Johansson:
       "Two more fixes for 4.5:
         - One is a fix for OMAP that is urgently needed to avoid DRA7xx chips
           from premature aging, by always keeping the Ethernet clock enabled.
         - The other solves a I/O memory layout issue on Armada, where SROM
           and PCI memory windows were conflicting in some configurations"
      * tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
        ARM: mvebu: fix overlap of Crypto SRAM with PCIe memory window
        ARM: dts: dra7: do not gate cpsw clock due to errata i877
        ARM: OMAP2+: hwmod: Introduce ti,no-idle dt property
    • Linus Torvalds's avatar
      Merge tag 'media/v4.5-5' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media · 95f41fb2
      Linus Torvalds authored
      Pull media fix from Mauro Carvalho Chehab:
       "One last time fix: It adds a code that prevents some media tools like
        media-ctl to hide some entities that have their IDs out of the range
        expected by those apps"
      * tag 'media/v4.5-5' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media:
        [media] media-device: map new functions into old types for legacy API
    • Thomas Petazzoni's avatar
      ARM: mvebu: fix overlap of Crypto SRAM with PCIe memory window · d7d5a43c
      Thomas Petazzoni authored
      When the Crypto SRAM mappings were added to the Device Tree files
      describing the Armada XP boards in commit c466d997 ("ARM: mvebu:
      define crypto SRAM ranges for all armada-xp boards"), the fact that
      those mappings were overlaping with the PCIe memory aperture was
      overlooked. Due to this, we currently have for all Armada XP platforms
      a situation that looks like this:
      Memory mapping on Armada XP boards with internal registers at
       - 0x00000000 -> 0xf0000000	3.75G 	RAM
       - 0xf0000000 -> 0xf1000000	16M	NOR flashes (AXP GP / AXP DB)
       - 0xf1000000 -> 0xf1100000	1M	internal registers
       - 0xf8000000 -> 0xffe0000	126M	PCIe memory aperture
       - 0xf8100000 -> 0xf8110000	64KB	Crypto SRAM #0	=> OVERLAPS WITH PCIE !
       - 0xf8110000 -> 0xf8120000	64KB	Crypto SRAM #1	=> OVERLAPS WITH PCIE !
       - 0xffe00000 -> 0xfff00000	1M	PCIe I/O aperture
       - 0xfff0000  -> 0xffffffff	1M	BootROM
      The overlap means that when PCIe devices are added, depending on their
      memory window needs, they might or might not be mapped into the
      physical address space. Indeed, they will not be mapped if the area
      allocated in the PCIe memory aperture by the PCI core overlaps with
      one of the Crypto SRAM. Typically, a Intel IGB PCIe NIC that needs 8MB
      of PCIe memory will see its PCIe memory window allocated from
      0xf80000000 for 8MB, which overlaps with the Crypto SRAM windows. Due
      to this, the PCIe window is not created, and any attempt to access the
      PCIe window makes the kernel explode:
      [    3.302213] igb: Copyright (c) 2007-2014 Intel Corporation.
      [    3.307841] pci 0000:00:09.0: enabling device (0140 -> 0143)
      [    3.313539] mvebu_mbus: cannot add window '4:f8', conflicts with another window
      [    3.320870] mvebu-pcie soc:pcie-controller: Could not create MBus window at [mem 0xf8000000-0xf87fffff]: -22
      [    3.330811] Unhandled fault: external abort on non-linefetch (0x1008) at 0xf08c0018
      This problem does not occur on Armada 370 boards, because we use the
      following memory mapping (for boards that have internal registers at
       - 0x00000000 -> 0xf0000000	3.75G 	RAM
       - 0xf0000000 -> 0xf1000000	16M	NOR flashes (AXP GP / AXP DB)
       - 0xf1000000 -> 0xf1100000	1M	internal registers
       - 0xf1100000 -> 0xf1110000	64KB	Crypto SRAM #0 => OK !
       - 0xf8000000 -> 0xffe0000	126M	PCIe memory
       - 0xffe00000 -> 0xfff00000	1M	PCIe I/O
       - 0xfff0000  -> 0xffffffff	1M	BootROM
      Obviously, the solution is to align the location of the Crypto SRAM
      mappings of Armada XP to be similar with the ones on Armada 370, i.e
      have them between the "internal registers" area and the beginning of
      the PCIe aperture.
      However, we have a special case with the OpenBlocks AX3-4 platform,
      which has a 128 MB NOR flash. Currently, this NOR flash is mapped from
      0xf0000000 to 0xf8000000. This is possible because on OpenBlocks
      AX3-4, the internal registers are not at 0xf1000000. And this explains
      why the Crypto SRAM mappings were not configured at the same place on
      Armada XP.
      Hence, the solution is two-fold:
       (1) Move the NOR flash mapping on Armada XP OpenBlocks AX3-4 from
           0xe8000000 to 0xf0000000. This frees the 0xf0000000 ->
           0xf80000000 space.
       (2) Move the Crypto SRAM mappings on Armada XP to be similar to
           Armada 370 (except of course that Armada XP has two Crypto SRAM
           and not one).
      After this patch, the memory mapping on Armada XP boards with
      registers at 0xf1 is:
       - 0x00000000 -> 0xf0000000	3.75G 	RAM
       - 0xf0000000 -> 0xf1000000	16M	NOR flashes (AXP GP / AXP DB)
       - 0xf1000000 -> 0xf1100000	1M	internal registers
       - 0xf1100000 -> 0xf1110000	64KB	Crypto SRAM #0
       - 0xf1110000 -> 0xf1120000	64KB	Crypto SRAM #1
       - 0xf8000000 -> 0xffe0000	126M	PCIe memory
       - 0xffe00000 -> 0xfff00000	1M	PCIe I/O
       - 0xfff0000  -> 0xffffffff	1M	BootROM
      And the memory mapping for the special case of the OpenBlocks AX3-4
      (internal registers at 0xd0000000, NOR of 128 MB):
       - 0x00000000 -> 0xc0000000	3G 	RAM
       - 0xd0000000 -> 0xd1000000	1M	internal registers
       - 0xe800000  -> 0xf0000000	128M	NOR flash
       - 0xf1100000 -> 0xf1110000	64KB	Crypto SRAM #0
       - 0xf1110000 -> 0xf1120000	64KB	Crypto SRAM #1
       - 0xf8000000 -> 0xffe0000	126M	PCIe memory
       - 0xffe00000 -> 0xfff00000	1M	PCIe I/O
       - 0xfff0000  -> 0xffffffff	1M	BootROM
      Fixes: c466d997
       ("ARM: mvebu: define crypto SRAM ranges for all armada-xp boards")
      Reported-by: default avatarPhil Sutter <phil@nwl.cc>
      Cc: Phil Sutter <phil@nwl.cc>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Acked-by: default avatarGregory CLEMENT <gregory.clement@free-electrons.com>
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
    • Linus Torvalds's avatar
      Merge tag 'dmaengine-fix-4.5' of git://git.infradead.org/users/vkoul/slave-dma · 20698c92
      Linus Torvalds authored
      Pull dmaengine fixes from Vinod Koul:
       "Two fixes showed up in last few days, and they should be included in
        4.5.  Summary:
        Two more late fixes to drivers, nothing major here:
         - A memory leak fix in fsdma unmap the dma descriptors on freeup
         - A fix in xdmac driver for residue calculation of dma descriptor"
      * tag 'dmaengine-fix-4.5' of git://git.infradead.org/users/vkoul/slave-dma:
        dmaengine: at_xdmac: fix residue computation
        dmaengine: fsldma: fix memory leak
    • Linus Torvalds's avatar
      Merge tag 'pm+acpi-4.5-final' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm · 7ae9c768
      Linus Torvalds authored
      Pull power management and ACPI fixes from Rafael Wysocki:
       "Two more fixes for issues introduced recently, one in the generic
        device properties framework and one in ACPICA.
         - Revert a recent ACPICA commit that has been reverted upstream,
           because it caused problems to happen on user systems and the
           problem it attempted to address will not be relevant any more after
           upcoming ACPI specification changes (Bob Moore).
         - Fix crash in the generic device properties framework introduced by
           a recent change that forgot to check pointers against error values
           in addition to checking them against NULL (Heikki Krogerus)"
      * tag 'pm+acpi-4.5-final' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
        device property: fwnode->secondary may contain ERR_PTR(-ENODEV)
        ACPICA: Revert "Parser: Fix for SuperName method invocation"
    • Linus Torvalds's avatar
      Merge tag 'xfs-for-linus-4.5-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs · 2a62ec0a
      Linus Torvalds authored
      Pull xfs fixes from Dave Chinner:
       "This is a fix for a regression introduced in 4.5-rc1 by the new torn
        log write detection code.  The regression only affects people moving a
        clean filesystem between machines/kernels of different architecture
        (such as changing between 32 bit and 64 bit kernels), but this is the
        recommended (and only!) safe way to migrate a filesystem between
        architectures so we really need to ensure it works.
        The changes are larger than I'd prefer right at the end of the release
        cycle, but the majority of the change is just factoring code to enable
        the detection of a clean log at the correct time to avoid this issue.
         - Only perform torn log write detection on dirty logs.  This prevents
           failures being detected due to a clean filesystem being moved
           between machines or kernels of different architectures (e.g.  32 ->
           64 bit, BE -> LE, etc).  This fixes a regression introduced by the
           torn log write detection in 4.5-rc1"
      * tag 'xfs-for-linus-4.5-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs:
        xfs: only run torn log write detection on dirty logs
        xfs: refactor in-core log state update to helper
        xfs: refactor unmount record detection into helper
        xfs: separate log head record discovery from verification
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs · 63cf207e
      Linus Torvalds authored
      Pull vfs fixes from Al Viro:
       "A couple of fixes: Fix for my dumb braino in ncpfs and a long-standing
        breakage on recovery from failed rename() in jffs2"
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
        jffs2: reduce the breakage on recovery from halfway failed rename()
        ncpfs: fix a braino in OOM handling in ncp_fill_cache()
    • Rafael J. Wysocki's avatar
      Merge branches 'device-properties-fixes' and 'acpica-fixes' · 5b3e7e05
      Rafael J. Wysocki authored
      * device-properties-fixes:
        device property: fwnode->secondary may contain ERR_PTR(-ENODEV)
      * acpica-fixes:
        ACPICA: Revert "Parser: Fix for SuperName method invocation"
    • Ville Syrjälä's avatar
      drm/i915: Actually retry with bit-banging after GMBUS timeout · 0bbca274
      Ville Syrjälä authored
      After the GMBUS transfer times out, we set force_bit=1 and
      return -EAGAIN expecting the i2c core to call the .master_xfer
      hook again so that we will retry the same transfer via bit-banging.
      This is in case the gmbus hardware is somehow faulty.
      Unfortunately we left adapter->retries to 0, meaning the i2c core
      didn't actually do the retry. Let's tell the core we want one retry
      when we return -EAGAIN.
      Note that i2c-algo-bit also uses this retry count for some internal
      retries, so we'll end up increasing those a bit as well.
      Cc: Jani Nikula <jani.nikula@intel.com>
      Cc: drm-intel-fixes@lists.freedesktop.org
      Fixes: bffce907
       ("drm/i915: abstract i2c bit banging fallback in gmbus xfer")
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1457366220-29409-2-git-send-email-ville.syrjala@linux.intel.com
      Reviewed-by: default avatarJani Nikula <jani.nikula@intel.com>
      (cherry picked from commit 8b1f165a
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
  5. 10 Mar, 2016 8 commits