aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2016-03-14drm/nouveau/gr/gk20a: move firmware bundle release to gf100Alexandre Courbot4-19/+12
Some members of gf100_gr were freed by the gk20a driver. That's not where it should be done - free them in gf100 so other chips that use NVIDIA-provided firmware free these structures properly. This also removes the need for a GK20A-specific destructor. Signed-off-by: Alexandre Courbot <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2016-03-14drm/nouveau/core: add gpuobj memcpy helper functionsAlexandre Courbot2-0/+24
Add memcpy functions to copy a buffer to a gpuobj and vice-versa. This will be used by the secure boot code. Signed-off-by: Alexandre Courbot <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2016-03-14drm/nouveau/gm200: enable graphics deviceBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <[email protected]>
2016-03-14drm/nouveau/gr/gm200: s/gm204/gm200/Ben Skeggs10-128/+128
Most of the per-chipset differences will go away when we fully switch to using the register lists provided by the firmware files, which will leave all the remaining code "belonging" to GM200. This is a preemptive rename from GM204 to GM200. Signed-off-by: Ben Skeggs <[email protected]>
2016-03-14drm/nouveau/bios/devinit: properly handle unknown generic conditionsBen Skeggs1-2/+3
Upon encountering an unknown condition code, the script interpreter is supposed to skip 'size' bytes and continue at the next devinit token. Signed-off-by: Ben Skeggs <[email protected]>
2016-03-14drm/nouveau/bios/devinit: rename INIT_DP_CONDITION to INIT_GENERIC_CONDITIONBen Skeggs1-5/+5
Signed-off-by: Ben Skeggs <[email protected]>
2016-03-14drm/nouveau/ltc/gm107: fix slice intr offsetBen Skeggs1-1/+1
Signed-off-by: Ben Skeggs <[email protected]>
2016-03-14drm/nouveau/devinit/gf100-: detect if BIOS invoked devinitAlexandre Courbot4-3/+16
It is not advisable to perform devinit if it has already been done. VBIOS will very likely have invoked devinit if the GPU is the primary graphics device, but there is no accurate way to detect this fact yet. This patch adds such a method for gf100 and later chips, by means of the NV_PTOP_SCRATCH1_DEVINIT_COMPLETED bit. This bit is set to 1 by devinit, and reset to 0 when the GPU is powered. Signed-off-by: Alexandre Courbot <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2016-03-14drm/nouveau/devinit/nv50: remove unneeded variableAlexandre Courbot1-7/+6
We never use any nv50-specific member in this nv50_devinit_preinit(). Signed-off-by: Alexandre Courbot <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2016-03-14drm/nouveau: s/gm204/gm200/ in a number of placesBen Skeggs39-150/+150
Signed-off-by: Ben Skeggs <[email protected]>
2016-03-14drm/nouveau: recognise GM200 chipsetBen Skeggs1-0/+31
Signed-off-by: Ben Skeggs <[email protected]>
2016-03-14drm/nouveau/device/tegra: fix uninitialized IRQ numberAlexandre Courbot1-1/+0
nvkm_device_tegra_new initializes the irq member of the Tegra device to -1 in order to signal that it is uninitialized. However, nvkm_device_tegra_fini tests it against 0 to check whether an IRQ has been allocated or not. This leads to free_irq being called on -1 during device initialization. Fix this by using 0 as the uninitialized value everywhere. Signed-off-by: Alexandre Courbot <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2016-03-14drm/nouveau/device: call nvkm_device_fini if nvkm_device_init failsAlexandre Courbot1-0/+2
nvkm_device_fini is never called if a failure occurs in nvkm_device_init, even when unloading the module. This can lead to a resources leak (one example is the Tegra interrupt which would never be freed in that case). Fix this by calling nvkm_device_fini in nvkm_device_init's failure path. Signed-off-by: Alexandre Courbot <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2016-03-14drm/nouveau/gr/gf100: use the nvkm_firmware functionsAlexandre Courbot1-15/+3
Use the nvkm_firmware_* functions when loading external firmware to avoid duplicate code. Signed-off-by: Alexandre Courbot <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2016-03-14drm/nouveau/core: add firmware handling functionsAlexandre Courbot3-0/+73
Add two functions nvkm_firmware_get() and nvkm_firmware_put() to load a firmware file and free its resources, respectively. Since firmware files are becoming a necessity for new GPUs, and their location has been standardized to nvidia/chip/, this will prevent duplicate and error-prone name-generation code. Signed-off-by: Alexandre Courbot <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2016-03-14drm/nouveau/ltc/gm107: wait on relevant bit in gm107_ltc_cbc_waitAlexandre Courbot1-4/+2
Patch "ltc/gm107: use nvkm_mask to set cbc_ctrl1" sets the 3rd bit of the CTRL1 register instead of writing it entirely in gm107_ltc_cbc_clear(). As a counterpart, gm107_ltc_cbc_wait() must also be modified to wait on that single bit only, otherwise a timeout may occur if some other bit of that register is set. This happened at least on GM206 when running glmark2-drm. While we are at it, use the more compact nvkm_wait_msec() to wait for the bit to clear. Signed-off-by: Alexandre Courbot <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2016-03-13drm/vc4: Return -EFAULT on copy_from_user() failureDan Carpenter1-3/+4
The copy_from_user() function returns the number of bytes not copied but we want to return a negative error code. Fixes: 463873d57014 ('drm/vc4: Add an API for creating GPU shaders in GEM BOs.') Cc: [email protected] Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Eric Anholt <[email protected]>
2016-03-13drm/vc4: Respect GPIO_ACTIVE_LOW on HDMI HPD if set in the devicetree.Eric Anholt1-2/+10
The original Raspberry Pi had the GPIO active high, but the later models are active low. The DT GPIO bindings allow specifying the active flag, except that it doesn't get propagated to the gpiodesc, so you have to handle it yourself. Signed-off-by: Eric Anholt <[email protected]> Tested-by: Daniel Stone <[email protected]>
2016-03-13drm/vc4: Let gpiolib know that we're OK with sleeping for HPD.Eric Anholt1-1/+1
Fixes an error thrown every few seconds when we poll HPD when it's on a I2C to GPIO expander. Signed-off-by: Eric Anholt <[email protected]> Tested-by: Daniel Stone <[email protected]>
2016-03-13drm/vc4: improve throughput by pipelining binning and rendering jobsVarad Gautam3-52/+166
The hardware provides us with separate threads for binning and rendering, and the existing model waits for them both to complete before submitting the next job. Splitting the binning and rendering submissions reduces idle time and gives us approx 20-30% speedup with some x11perf tests such as -line10 and -tilerect1. Improves openarena performance by 1.01897% +/- 0.247857% (n=16). Thanks to anholt for suggesting this. v2: Rebase on the spurious resets fix (change by anholt). Signed-off-by: Varad Gautam <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Eric Anholt <[email protected]>
2016-03-14Merge tag 'drm-vc4-fixes-2016-03-03' of github.com:anholt/linux into drm-nextDave Airlie3-3/+64
This pull request fixes the major VC4 HDMI modesetting bugs found when the first wave of users showed up in Raspbian. * tag 'drm-vc4-fixes-2016-03-03' of github.com:anholt/linux: drm/vc4: Initialize scaler DISPBKGND on modeset. drm/vc4: Fix setting of vertical timings in the CRTC. drm/vc4: Fix the name of the VSYNCD_EVEN register. drm/vc4: Add another reg to HDMI debug dumping. drm/vc4: Bring HDMI up from power off if necessary. drm/vc4: Fix a framebuffer reference leak on async flip interrupt.
2016-03-14Merge branch 'exynos-drm-next' of ↵Dave Airlie4-1/+31
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next * 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos: drm/exynos: add DRM_EXYNOS_GEM_MAP ioctl
2016-03-14Merge drm-fixes into drm-next.Dave Airlie1064-8100/+12833
Nouveau wanted this to avoid some worse conflicts when I merge that.
2016-03-13drm: atomic helper: do not unreference error pointerLionel Landwerlin1-0/+1
562c5b4d8986 didn't quite fix the issue of dealing with an error pointer. We can't free/unref an error pointer so reset it to NULL. Many thanks to Dan Carpenter for pointing this out again. Signed-off-by: Lionel Landwerlin <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: Daniel Stone <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Matt Roper <[email protected]> Cc: [email protected] Fixes: 562c5b4d8986 ("drm: fix blob pointer check") Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2016-03-13drm/edid: Extract SADs properly from multiple audio data blocksVille Syrjälä1-6/+11
SADs may span multiple CEA audio data blocks in the EDID. CEA-861-E says: "The order of the Data Blocks is not constrained. It is also possible to have more than one of a specific type of data block if necessary to include all of the descriptors needed to describe the sink’s capabilities." Each audio data block can carry up to 10 SADs, whereas the ELD SAD limit is 15 according to HDA 1.0a spec. So we should support at least two data blocks. And apparently some devices take a more liberal interpretation and stuff only one SAD per data block even when they would fit into one. So let's try to extract all the SADs we can fit into the ELD even when they span multiple data blocks. While at it, toss in a comment to explain the 13 byte monitor name string limit which confused me at first. Cc: Arturo Pérez <[email protected]> Tested-by: Arturo Pérez <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94197 Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2016-03-13drm/exynos: add DRM_EXYNOS_GEM_MAP ioctlJoonyoung Shim4-1/+31
The commit d931589c01a2 ("drm/exynos: remove DRM_EXYNOS_GEM_MAP_OFFSET ioctl") removed it same with the ioctl that this patch adds. The reason that removed DRM_EXYNOS_GEM_MAP_OFFSET was we could use DRM_IOCTL_MODE_MAP_DUMB. Both did exactly same thing. Now we again will revive it as DRM_EXYNOS_GEM_MAP because of render node. DRM_IOCTL_MODE_MAP_DUMB isn't permitted in render node. Signed-off-by: Joonyoung Shim <[email protected]> Signed-off-by: Inki Dae <[email protected]>
2016-03-12Merge tag 'drm-intel-fixes-2016-03-11' of ↵Dave Airlie5-4/+9
git://anongit.freedesktop.org/drm-intel into drm-next Two i915 regression fixes. * tag 'drm-intel-fixes-2016-03-11' of git://anongit.freedesktop.org/drm-intel: drm/i915: Actually retry with bit-banging after GMBUS timeout drm/i915: Fix bogus dig_port_map[] assignment for pre-HSW
2016-03-11Merge tag 'armsoc-fixes' of ↵Linus Torvalds13-20/+41
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc 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
2016-03-11Merge tag 'media/v4.5-5' of ↵Linus Torvalds2-1/+28
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media 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
2016-03-11ARM: mvebu: fix overlap of Crypto SRAM with PCIe memory windowThomas Petazzoni9-19/+19
When the Crypto SRAM mappings were added to the Device Tree files describing the Armada XP boards in commit c466d997bb16 ("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 0xf1000000: - 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 0xf1000000): - 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: c466d997bb16 ("ARM: mvebu: define crypto SRAM ranges for all armada-xp boards") Reported-by: Phil Sutter <[email protected]> Cc: Phil Sutter <[email protected]> Cc: <[email protected]> Signed-off-by: Thomas Petazzoni <[email protected]> Acked-by: Gregory CLEMENT <[email protected]> Signed-off-by: Olof Johansson <[email protected]>
2016-03-11Merge tag 'dmaengine-fix-4.5' of git://git.infradead.org/users/vkoul/slave-dmaLinus Torvalds2-3/+41
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
2016-03-11Merge tag 'pm+acpi-4.5-final' of ↵Linus Torvalds2-9/+8
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm 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. Specifics: - 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"
2016-03-11Merge tag 'xfs-for-linus-4.5-rc7' of ↵Linus Torvalds1-103/+168
git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs 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. Changes: - 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
2016-03-11Merge branch 'for-linus' of ↵Linus Torvalds2-4/+9
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs 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()
2016-03-11Merge branches 'device-properties-fixes' and 'acpica-fixes'Rafael J. Wysocki2-9/+8
* device-properties-fixes: device property: fwnode->secondary may contain ERR_PTR(-ENODEV) * acpica-fixes: ACPICA: Revert "Parser: Fix for SuperName method invocation"
2016-03-11drm/i915: Actually retry with bit-banging after GMBUS timeoutVille Syrjälä1-0/+6
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 <[email protected]> Cc: [email protected] Fixes: bffce907d640 ("drm/i915: abstract i2c bit banging fallback in gmbus xfer") Signed-off-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]> (cherry picked from commit 8b1f165a4a8f64c28cf42d10e1f4d3b451dedc51) Signed-off-by: Jani Nikula <[email protected]>
2016-03-10Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds6-16/+53
Pull KVM fixes from Paolo Bonzini: "A few simple fixes for ARM, x86, PPC and generic code. The x86 MMU fix is a bit larger because the surrounding code needed a cleanup, but nothing worrisome" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: KVM: MMU: fix reserved bit check for ept=0/CR0.WP=0/CR4.SMEP=1/EFER.NX=0 KVM: MMU: fix ept=0/pte.u=1/pte.w=0/CR0.WP=0/CR4.SMEP=1/EFER.NX=0 combo kvm: cap halt polling at exactly halt_poll_ns KVM: s390: correct fprs on SIGP (STOP AND) STORE STATUS KVM: VMX: disable PEBS before a guest entry KVM: PPC: Book3S HV: Sanitize special-purpose register values on guest exit
2016-03-10Merge tag 'arm64-fixes' of ↵Linus Torvalds2-16/+3
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fixes from Will Deacon: "I thought we were done for 4.5, but then the 64k-page chaps came crawling out of the woodwork. *sigh* The vmemmap fix I sent for -rc7 caused a regression with 64k pages and sparsemem and at some point during the release cycle the new hugetlb code using contiguous ptes started failing the libhugetlbfs tests with 64k pages enabled. So here are a couple of patches that fix the vmemmap alignment and disable the new hugetlb page sizes whilst a proper fix is being developed: - Temporarily disable huge pages built using contiguous ptes - Ensure vmemmap region is sufficiently aligned for sparsemem sections" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: hugetlb: partial revert of 66b3923a1a0f arm64: account for sparsemem section alignment when choosing vmemmap offset
2016-03-10Merge branch 'for-linus' of ↵Linus Torvalds4-13/+38
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 fixes from Martin Schwidefsky: "Three bug fixes: - The fix for the page table corruption (CVE-2016-2143) - The diagnose statistics introduced a regression for the dasd diag driver - Boot crash on systems without the set-program-parameters facility" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390/mm: four page table levels vs. fork s390/cpumf: Fix lpp detection s390/dasd: fix diag 0x250 inline assembly
2016-03-10[media] media-device: map new functions into old types for legacy APIMauro Carvalho Chehab2-1/+28
The legacy media controller userspace API exposes entity types that carry both type and function information. The new API replaces the type with a function. It preserves backward compatibility by defining legacy functions for the existing types and using them in drivers. This works fine, as long as newer entity functions won't be added. Unfortunately, some tools, like media-ctl with --print-dot argument rely on the now legacy MEDIA_ENT_T_V4L2_SUBDEV and MEDIA_ENT_T_DEVNODE numeric ranges to identify what entities will be shown. Also, if the entity doesn't match those ranges, it will ignore the major/minor information on devnodes, and won't be getting the devnode name via udev or sysfs. As we're now adding devices outside the old range, the legacy ioctl needs to map the new entity functions into a type at the old range, or otherwise we'll have a regression. Detected on all released media-ctl versions (e. g. versions <= 1.10). Fix this by deriving the type from the function to emulate the legacy API if the function isn't in the legacy functions range. Reported-by: Laurent Pinchart <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2016-03-10drm/amdgpu: split pipeline sync out of SDMA vm_flush() as wellChristian König3-20/+53
Code it similar to how we did it for the gfx and compute engines. Signed-off-by: Christian König <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2016-03-10drm: fix blob pointer checkLionel Landwerlin1-2/+2
Check properly that the allocated blob's pointer is valid. Signed-off-by: Lionel Landwerlin <[email protected]> Reported-by: Dan Carpenter <[email protected]> Cc: Daniel Stone <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Matt Roper <[email protected]> Cc: [email protected] Reviewed-by: Daniel Stone <[email protected]> Fixes: 5488dc16fde7 ("drm: introduce pipe color correction properties") Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2016-03-10dmaengine: at_xdmac: fix residue computationLudovic Desroches1-3/+39
When computing the residue we need two pieces of information: the current descriptor and the remaining data of the current descriptor. To get that information, we need to read consecutively two registers but we can't do it in an atomic way. For that reason, we have to check manually that current descriptor has not changed. Signed-off-by: Ludovic Desroches <[email protected]> Suggested-by: Cyrille Pitchen <[email protected]> Reported-by: David Engraf <[email protected]> Tested-by: David Engraf <[email protected]> Fixes: e1f7c9eee707 ("dmaengine: at_xdmac: creation of the atmel eXtended DMA Controller driver") Cc: [email protected] #4.1 and later Signed-off-by: Vinod Koul <[email protected]>
2016-03-10KVM: MMU: fix reserved bit check for ept=0/CR0.WP=0/CR4.SMEP=1/EFER.NX=0Paolo Bonzini1-1/+3
KVM has special logic to handle pages with pte.u=1 and pte.w=0 when CR0.WP=1. These pages' SPTEs flip continuously between two states: U=1/W=0 (user and supervisor reads allowed, supervisor writes not allowed) and U=0/W=1 (supervisor reads and writes allowed, user writes not allowed). When SMEP is in effect, however, U=0 will enable kernel execution of this page. To avoid this, KVM also sets NX=1 in the shadow PTE together with U=0, making the two states U=1/W=0/NX=gpte.NX and U=0/W=1/NX=1. When guest EFER has the NX bit cleared, the reserved bit check thinks that the latter state is invalid; teach it that the smep_andnot_wp case will also use the NX bit of SPTEs. Cc: [email protected] Reviewed-by: Xiao Guangrong <[email protected]> Fixes: c258b62b264fdc469b6d3610a907708068145e3b Signed-off-by: Paolo Bonzini <[email protected]>
2016-03-10KVM: MMU: fix ept=0/pte.u=1/pte.w=0/CR0.WP=0/CR4.SMEP=1/EFER.NX=0 comboPaolo Bonzini2-14/+25
Yes, all of these are needed. :) This is admittedly a bit odd, but kvm-unit-tests access.flat tests this if you run it with "-cpu host" and of course ept=0. KVM runs the guest with CR0.WP=1, so it must handle supervisor writes specially when pte.u=1/pte.w=0/CR0.WP=0. Such writes cause a fault when U=1 and W=0 in the SPTE, but they must succeed because CR0.WP=0. When KVM gets the fault, it sets U=0 and W=1 in the shadow PTE and restarts execution. This will still cause a user write to fault, while supervisor writes will succeed. User reads will fault spuriously now, and KVM will then flip U and W again in the SPTE (U=1, W=0). User reads will be enabled and supervisor writes disabled, going back to the originary situation where supervisor writes fault spuriously. When SMEP is in effect, however, U=0 will enable kernel execution of this page. To avoid this, KVM also sets NX=1 in the shadow PTE together with U=0. If the guest has not enabled NX, the result is a continuous stream of page faults due to the NX bit being reserved. The fix is to force EFER.NX=1 even if the CPU is taking care of the EFER switch. (All machines with SMEP have the CPU_LOAD_IA32_EFER vm-entry control, so they do not use user-return notifiers for EFER---if they did, EFER.NX would be forced to the same value as the host). There is another bug in the reserved bit check, which I've split to a separate patch for easier application to stable kernels. Cc: [email protected] Cc: Andy Lutomirski <[email protected]> Reviewed-by: Xiao Guangrong <[email protected]> Fixes: f6577a5fa15d82217ca73c74cd2dcbc0f6c781dd Signed-off-by: Paolo Bonzini <[email protected]>
2016-03-10s390/mm: four page table levels vs. forkMartin Schwidefsky2-10/+30
The fork of a process with four page table levels is broken since git commit 6252d702c5311ce9 "[S390] dynamic page tables." All new mm contexts are created with three page table levels and an asce limit of 4TB. If the parent has four levels dup_mmap will add vmas to the new context which are outside of the asce limit. The subsequent call to copy_page_range will walk the three level page table structure of the new process with non-zero pgd and pud indexes. This leads to memory clobbers as the pgd_index *and* the pud_index is added to the mm->pgd pointer without a pgd_deref in between. The init_new_context() function is selecting the number of page table levels for a new context. The function is used by mm_init() which in turn is called by dup_mm() and mm_alloc(). These two are used by fork() and exec(). The init_new_context() function can distinguish the two cases by looking at mm->context.asce_limit, for fork() the mm struct has been copied and the number of page table levels may not change. For exec() the mm_alloc() function set the new mm structure to zero, in this case a three-level page table is created as the temporary stack space is located at STACK_TOP_MAX = 4TB. This fixes CVE-2016-2143. Reported-by: Marcin Kościelnicki <[email protected]> Reviewed-by: Heiko Carstens <[email protected]> Cc: [email protected] Signed-off-by: Martin Schwidefsky <[email protected]>
2016-03-09Merge tag 'spi-fix-v4.5-rc7' of ↵Linus Torvalds2-15/+5
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi Pull spi fixes from Mark Brown: "A few driver specific fixes for the Rockchip and i.MX SPI controllers, especially for the i.MX they're annoying bugs if you run into them" * tag 'spi-fix-v4.5-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: spi: imx: fix spi resource leak with dma transfer spi: imx: allow only WML aligned transfers to use DMA spi: rockchip: add missing spi_master_put spi: rockchip: disable runtime pm when in err case
2016-03-10Merge remote-tracking branch 'spi/fix/rockchip' into spi-linusMark Brown1-0/+3
2016-03-10Merge remote-tracking branch 'spi/fix/imx' into spi-linusMark Brown1-15/+2
2016-03-09Merge tag 'ext4_for_linus_stable' of ↵Linus Torvalds1-0/+1
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 Pull ext4 fix from Ted Ts'o: "This fixes a regression which crept in v4.5-rc5" * tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4: ext4: iterate over buffer heads correctly in move_extent_per_page()
Powered by cgit, Gruvboxed by Blaster4385.