1. 14 Jan, 2018 2 commits
    • Len Brown's avatar
      x86/tsc: Fix erroneous TSC rate on Skylake Xeon · b5112030
      Len Brown authored
      The INTEL_FAM6_SKYLAKE_X hardcoded crystal_khz value of 25MHZ is
      problematic:
      
       - SKX workstations (with same model # as server variants) use a 24 MHz
         crystal.  This results in a -4.0% time drift rate on SKX workstations.
      
       - SKX servers subject the crystal to an EMI reduction circuit that reduces its
         actual frequency by (approximately) -0.25%.  This results in -1 second per
         10 minute time drift as compared to network time.
      
      This issue can also trigger a timer and power problem, on configurations
      that use the LAPIC timer (versus the TSC deadline timer).  Clock ticks
      scheduled with the LAPIC timer arrive a few usec before the time they are
      expected (according to the slow TSC).  This causes Linux to poll-idle, when
      it should be in an idle power saving state.  The idle and clock code do not
      graciously recover from this error, sometimes resulting in significant
      polling and measurable power impact.
      
      Stop using native_calibrate_tsc() for INTEL_FAM6_SKYLAKE_X.
      native_calibrate_tsc() will return 0, boot will run with tsc_khz = cpu_khz,
      and the TSC refined calibration will update tsc_khz to correct for the
      difference.
      
      [ tglx: Sanitized change log ]
      
      Fixes: 6baf3d61 ("x86/tsc: Add additional Intel CPU models to the crystal quirk list")
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: peterz@infradead.org
      Cc: Prarit Bhargava <prarit@redhat.com>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/ff6dcea166e8ff8f2f6a03c17beab2cb436aa779.1513920414.git.len.brown@intel.com
      b5112030
    • Len Brown's avatar
      x86/tsc: Future-proof native_calibrate_tsc() · da4ae6c4
      Len Brown authored
      If the crystal frequency cannot be determined via CPUID(15).crystal_khz or
      the built-in table then native_calibrate_tsc() will still set the
      X86_FEATURE_TSC_KNOWN_FREQ flag which prevents the refined TSC calibration.
      
      As a consequence such systems use cpu_khz for the TSC frequency which is
      incorrect when cpu_khz != tsc_khz resulting in time drift.
      
      Return early when the crystal frequency cannot be retrieved without setting
      the X86_FEATURE_TSC_KNOWN_FREQ flag. This ensures that the refined TSC
      calibration is invoked.
      
      [ tglx: Steam-blastered changelog. Sigh ]
      
      Fixes: 4ca4df0b ("x86/tsc: Mark TSC frequency determined by CPUID as known")
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: peterz@infradead.org
      Cc: Bin Gao <bin.gao@intel.com>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/0fe2503aa7d7fc69137141fc705541a78101d2b9.1513920414.git.len.brown@intel.com
      da4ae6c4
  2. 13 Jan, 2018 1 commit
    • Kirill A. Shutemov's avatar
      kdump: Write the correct address of mem_section into vmcoreinfo · 9f15b912
      Kirill A. Shutemov authored
      Depending on configuration mem_section can now be an array or a pointer
      to an array allocated dynamically. In most cases, we can continue to refer
      to it as 'mem_section' regardless of what it is.
      
      But there's one exception: '&mem_section' means "address of the array" if
      mem_section is an array, but if mem_section is a pointer, it would mean
      "address of the pointer".
      
      We've stepped onto this in the kdump code: VMCOREINFO_SYMBOL(mem_section)
      writes down the address of pointer into vmcoreinfo, not the array as we wanted,
      breaking kdump.
      
      Let's introduce VMCOREINFO_SYMBOL_ARRAY() that would handle the
      situation correctly for both cases.
      
      Mike Galbraith <efault@gmx.de>
      Signed-off-by: default avatarKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Acked-by: default avatarBaoquan He <bhe@redhat.com>
      Acked-by: default avatarDave Young <dyoung@redhat.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Cc: kexec@lists.infradead.org
      Cc: linux-mm@kvack.org
      Cc: stable@vger.kernel.org
      Fixes: 83e3c487 ("mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y")
      Link: http://lkml.kernel.org/r/20180112162532.35896-1-kirill.shutemov@linux.intel.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      9f15b912
  3. 08 Jan, 2018 1 commit
  4. 06 Jan, 2018 1 commit
  5. 05 Jan, 2018 22 commits
  6. 04 Jan, 2018 13 commits
    • Thomas Gleixner's avatar
      x86/tlb: Drop the _GPL from the cpu_tlbstate export · 1e547681
      Thomas Gleixner authored
      The recent changes for PTI touch cpu_tlbstate from various tlb_flush
      inlines. cpu_tlbstate is exported as GPL symbol, so this causes a
      regression when building out of tree drivers for certain graphics cards.
      
      Aside of that the export was wrong since it was introduced as it should
      have been EXPORT_PER_CPU_SYMBOL_GPL().
      
      Use the correct PER_CPU export and drop the _GPL to restore the previous
      state which allows users to utilize the cards they payed for.
      
      As always I'm really thrilled to make this kind of change to support the
      #friends (or however the hot hashtag of today is spelled) from that closet
      sauce graphics corp.
      
      Fixes: 1e02ce4c ("x86: Store a per-cpu shadow copy of CR4")
      Fixes: 6fd166aa ("x86/mm: Use/Fix PCID to optimize user/kernel switches")
      Reported-by: default avatarKees Cook <keescook@google.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: stable@vger.kernel.org
      1e547681
    • Peter Zijlstra's avatar
      x86/events/intel/ds: Use the proper cache flush method for mapping ds buffers · 42f3bdc5
      Peter Zijlstra authored
      Thomas reported the following warning:
      
       BUG: using smp_processor_id() in preemptible [00000000] code: ovsdb-server/4498
       caller is native_flush_tlb_single+0x57/0xc0
       native_flush_tlb_single+0x57/0xc0
       __set_pte_vaddr+0x2d/0x40
       set_pte_vaddr+0x2f/0x40
       cea_set_pte+0x30/0x40
       ds_update_cea.constprop.4+0x4d/0x70
       reserve_ds_buffers+0x159/0x410
       x86_reserve_hardware+0x150/0x160
       x86_pmu_event_init+0x3e/0x1f0
       perf_try_init_event+0x69/0x80
       perf_event_alloc+0x652/0x740
       SyS_perf_event_open+0x3f6/0xd60
       do_syscall_64+0x5c/0x190
      
      set_pte_vaddr is used to map the ds buffers into the cpu entry area, but
      there are two problems with that:
      
       1) The resulting flush is not supposed to be called in preemptible context
      
       2) The cpu entry area is supposed to be per CPU, but the debug store
          buffers are mapped for all CPUs so these mappings need to be flushed
          globally.
      
      Add the necessary preemption protection across the mapping code and flush
      TLBs globally.
      
      Fixes: c1961a46 ("x86/events/intel/ds: Map debug buffers in cpu_entry_area")
      Reported-by: default avatarThomas Zeitlhofer <thomas.zeitlhofer+lkml@ze-it.at>
      Signed-off-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Tested-by: default avatarThomas Zeitlhofer <thomas.zeitlhofer+lkml@ze-it.at>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/20180104170712.GB3040@hirez.programming.kicks-ass.net
      42f3bdc5
    • Thomas Gleixner's avatar
      x86/kaslr: Fix the vaddr_end mess · 1dddd251
      Thomas Gleixner authored
      vaddr_end for KASLR is only documented in the KASLR code itself and is
      adjusted depending on config options. So it's not surprising that a change
      of the memory layout causes KASLR to have the wrong vaddr_end. This can map
      arbitrary stuff into other areas causing hard to understand problems.
      
      Remove the whole ifdef magic and define the start of the cpu_entry_area to
      be the end of the KASLR vaddr range.
      
      Add documentation to that effect.
      
      Fixes: 92a0f81d ("x86/cpu_entry_area: Move it out of the fixmap")
      Reported-by: default avatarBenjamin Gilbert <benjamin.gilbert@coreos.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Tested-by: default avatarBenjamin Gilbert <benjamin.gilbert@coreos.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: stable <stable@vger.kernel.org>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Garnier <thgarnie@google.com>,
      Cc: Alexander Kuleshov <kuleshovmail@gmail.com>
      Link: https://lkml.kernel.org/r/alpine.DEB.2.20.1801041320360.1771@nanos
      1dddd251
    • Dave Airlie's avatar
      Merge tag 'drm-intel-fixes-2018-01-04' of... · bc6fe533
      Dave Airlie authored
      Merge tag 'drm-intel-fixes-2018-01-04' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
      
      drm/i915 fixes for v4.15-rc7
      - couple of documentation build fixes
      - serialize non-blocking modesets
      - prevent DMC from messing up GMBUS transfers
      - PSR regression fix
      
      * tag 'drm-intel-fixes-2018-01-04' of git://anongit.freedesktop.org/drm/drm-intel:
        drm/i915: Apply Display WA #1183 on skl, kbl, and cfl
        docs: fix, intel_guc_loader.c has been moved to intel_guc_fw.c
        documentation/gpu/i915: fix docs build error after file rename
        drm/i915: Put all non-blocking modesets onto an ordered wq
        drm/i915: Disable DC states around GMBUS on GLK
        drm/i915/psr: Fix register name mess up.
      bc6fe533
    • Dave Airlie's avatar
      Merge branch 'drm-fixes-4.15' of git://people.freedesktop.org/~agd5f/linux into drm-fixes · 0007b9ca
      Dave Airlie authored
      - backport of a DC change which fixes a greenish tint on some RV hw
      - properly handle kzalloc fail in ttm
      
      * 'drm-fixes-4.15' of git://people.freedesktop.org/~agd5f/linux:
        drm/ttm: check the return value of kzalloc
        drm/amd/display: call set csc_default if enable adjustment is false
      0007b9ca
    • Dave Airlie's avatar
      Merge branch 'drm-armada-fixes-4.15' of git://git.armlinux.org.uk/~rmk/linux-arm into drm-fixes · dc042da0
      Dave Airlie authored
      Armada fixes.
      
      * 'drm-armada-fixes-4.15' of git://git.armlinux.org.uk/~rmk/linux-arm:
        drm/armada: fix YUV planar format framebuffer offsets
        drm/armada: improve efficiency of armada_drm_plane_calc_addrs()
        drm/armada: fix UV swap code
        drm/armada: fix SRAM powerdown
        drm/armada: fix leak of crtc structure
      dc042da0
    • Dave Airlie's avatar
      Merge tag 'omapdrm-4.15-fixes' of... · 041ea478
      Dave Airlie authored
      Merge tag 'omapdrm-4.15-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux into drm-fixes
      
      omapdrm fixes for 4.15
      
      * Fix OMAP4 HDMI CEC interrupt handling and a possible buffer overflow
      
      * tag 'omapdrm-4.15-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux:
        omapdrm/dss/hdmi4_cec: fix interrupt handling
      041ea478
    • Thomas Gleixner's avatar
      x86/mm: Map cpu_entry_area at the same place on 4/5 level · f2078904
      Thomas Gleixner authored
      There is no reason for 4 and 5 level pagetables to have a different
      layout. It just makes determining vaddr_end for KASLR harder than
      necessary.
      
      Fixes: 92a0f81d ("x86/cpu_entry_area: Move it out of the fixmap")
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Benjamin Gilbert <benjamin.gilbert@coreos.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: stable <stable@vger.kernel.org>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Garnier <thgarnie@google.com>,
      Cc: Alexander Kuleshov <kuleshovmail@gmail.com>
      Link: https://lkml.kernel.org/r/alpine.DEB.2.20.1801041320360.1771@nanos
      f2078904
    • Andrey Ryabinin's avatar
      x86/mm: Set MODULES_END to 0xffffffffff000000 · f5a40711
      Andrey Ryabinin authored
      Since f06bdd40 ("x86/mm: Adapt MODULES_END based on fixmap section size")
      kasan_mem_to_shadow(MODULES_END) could be not aligned to a page boundary.
      
      So passing page unaligned address to kasan_populate_zero_shadow() have two
      possible effects:
      
      1) It may leave one page hole in supposed to be populated area. After commit
        21506525 ("x86/kasan/64: Teach KASAN about the cpu_entry_area") that
        hole happens to be in the shadow covering fixmap area and leads to crash:
      
       BUG: unable to handle kernel paging request at fffffbffffe8ee04
       RIP: 0010:check_memory_region+0x5c/0x190
      
       Call Trace:
        <NMI>
        memcpy+0x1f/0x50
        ghes_copy_tofrom_phys+0xab/0x180
        ghes_read_estatus+0xfb/0x280
        ghes_notify_nmi+0x2b2/0x410
        nmi_handle+0x115/0x2c0
        default_do_nmi+0x57/0x110
        do_nmi+0xf8/0x150
        end_repeat_nmi+0x1a/0x1e
      
      Note, the crash likely disappeared after commit 92a0f81d, which
      changed kasan_populate_zero_shadow() call the way it was before
      commit 21506525.
      
      2) Attempt to load module near MODULES_END will fail, because
         __vmalloc_node_range() called from kasan_module_alloc() will hit the
         WARN_ON(!pte_none(*pte)) in the vmap_pte_range() and bail out with error.
      
      To fix this we need to make kasan_mem_to_shadow(MODULES_END) page aligned
      which means that MODULES_END should be 8*PAGE_SIZE aligned.
      
      The whole point of commit f06bdd40 was to move MODULES_END down if
      NR_CPUS is big, so the cpu_entry_area takes a lot of space.
      But since 92a0f81d ("x86/cpu_entry_area: Move it out of the fixmap")
      the cpu_entry_area is no longer in fixmap, so we could just set
      MODULES_END to a fixed 8*PAGE_SIZE aligned address.
      
      Fixes: f06bdd40 ("x86/mm: Adapt MODULES_END based on fixmap section size")
      Reported-by: default avatarJakub Kicinski <kubakici@wp.pl>
      Signed-off-by: default avatarAndrey Ryabinin <aryabinin@virtuozzo.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: stable@vger.kernel.org
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Thomas Garnier <thgarnie@google.com>
      Link: https://lkml.kernel.org/r/20171228160620.23818-1-aryabinin@virtuozzo.com
      f5a40711
    • Linus Torvalds's avatar
      Merge tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc · e1915c81
      Linus Torvalds authored
      Pull ARM SoC fixes from Arnd Bergmann:
       "Fixes this time include mostly device tree changes, as usual, the
        notable ones include:
      
         - A number of patches to fix most of the remaining DTC warnings that
           got introduced when DTC started warning about some obvious
           mistakes. We still have some remaining warnings that probably may
           have to wait until 4.16 to get fixed while we try to figure out
           what the correct contents should be.
      
         - On Allwinner A64, Ethernet PHYs need a fix after a mistake in
           coordination between patches merged through multiple branches.
      
         - Various fixes for PMICs on allwinner based boards
      
         - Two fixes for ethernet link detection on some Renesas machines
      
         - Two stability fixes for rockchip based boards
      
        Aside from device-tree, two other areas got fixes for older problems:
      
         - For TI Davinci DM365, a couple of fixes were needed to repair the
           MMC DMA engine support, apparently this has been broken for a
           while.
      
         - One important fix for all Allwinner chips with the PMIC driver as a
           loadable module"
      
      * tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (23 commits)
        arm64: dts: uniphier: fix gpio-ranges property of PXs3 SoC
        arm64: dts: renesas: ulcb: Remove renesas, no-ether-link property
        arm64: dts: renesas: salvator-x: Remove renesas, no-ether-link property
        ARM: dts: tango4: remove bogus interrupt-controller property
        ARM: dts: ls1021a: fix incorrect clock references
        ARM: dts: aspeed-g4: Correct VUART IRQ number
        ARM: dts: exynos: Enable Mixer node for Exynos5800 Peach Pi machine
        ARM: dts: sun8i: a711: Reinstate the PMIC compatible
        ARM: davinci: fix mmc entries in dm365's dma_slave_map
        ARM: dts: da850-lego-ev3: Fix battery voltage gpio
        ARM: davinci: Add dma_mask to dm365's eDMA device
        ARM: davinci: Use platform_device_register_full() to create pdev for dm365's eDMA
        arm64: dts: rockchip: limit rk3328-rock64 gmac speed to 100MBit for now
        arm64: dts: rockchip: remove vdd_log from rk3399-puma
        arm64: dts: orange-pi-zero-plus2: fix sdcard detect
        arm64: allwinner: a64-sopine: Fix to use dcdc1 regulator instead of vcc3v3
        ARM: dts: sunxi: Convert to CCU index macros for HDMI controller
        sunxi-rsb: Include OF based modalias in device uevent
        ARM: dts: at91: disable the nxp,se97b SMBUS timeout on the TSE-850
        arm64: dts: rockchip: fix trailing 0 in rk3328 tsadc interrupts
        ...
      e1915c81
    • Masahiro Yamada's avatar
      arm64: dts: uniphier: fix gpio-ranges property of PXs3 SoC · abb62c46
      Masahiro Yamada authored
      This is probably a copy-paste mistake.  The gpio-ranges of PXs3 is
      different from that of LD20.
      
      Fixes: 277b51e7 ("arm64: dts: uniphier: add GPIO controller nodes")
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      abb62c46
    • Arnd Bergmann's avatar
      Merge tag 'sunxi-fixes-for-4.15' of... · d84baa5a
      Arnd Bergmann authored
      Merge tag 'sunxi-fixes-for-4.15' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into fixes
      
      Pull "Allwinner fixes for 4.15" from Chen-Yu Tsai:
      
      First, one fix that adds proper regulator references for the EMAC
      external PHYs on A64 boards. The EMAC bindings were developed for 4.13,
      but reverted at the last minute. They were finalized and brought back
      for 4.15. However in the time between, regulator support for the A64
      boards was merged. When EMAC device tree changes were reintroduced,
      this was not taken into account.
      
      Second, a patch that adds OF based modalias uevent for RSB slave devices.
      This has been missing since the introduction of RSB, and recently with
      PMIC regulator support introduced for the A64, has been seen affecting
      distributions, which have the all-important PMIC mfd drivers built as
      modules, which then don't get loaded.
      
      Other minor cleanups include final conversion of raw indices to CCU
      binding macros for sun[4567]i HDMI, cleanup of dummy regulators on the
      A64 SOPINE, a SD card detection polarity fix for the Orange Pi Zero
      Plus2, and adding a missing compatible for the PMIC on the TBS A711
      tablet.
      
      * tag 'sunxi-fixes-for-4.15' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/sunxi/linux:
        ARM: dts: sun8i: a711: Reinstate the PMIC compatible
        arm64: dts: orange-pi-zero-plus2: fix sdcard detect
        arm64: allwinner: a64-sopine: Fix to use dcdc1 regulator instead of vcc3v3
        ARM: dts: sunxi: Convert to CCU index macros for HDMI controller
        sunxi-rsb: Include OF based modalias in device uevent
        arm64: allwinner: a64: add Ethernet PHY regulator for several boards
      d84baa5a
    • Arnd Bergmann's avatar
      Merge tag 'renesas-fixes-for-v4.15' of... · 3bfbed8d
      Arnd Bergmann authored
      Merge tag 'renesas-fixes-for-v4.15' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/horms/renesas into fixes
      
      Pull "Renesas ARM Based SoC Fixes for v4.15" from Simon Horman:
      
      Vladimir Zapolskiy says:
      
      The present change is a bug fix for AVB link iteratively up/down.
      
      Steps to reproduce:
      - start AVB TX stream (Using aplay via MSE),
      - disconnect+reconnect the eth cable,
      - after a reconnection the eth connection goes iteratively up/down
        without user interaction,
      - this may heal after some seconds or even stay for minutes.
      
      As the documentation specifies, the "renesas,no-ether-link" option
      should be used when a board does not provide a proper AVB_LINK signal.
      There is no need for this option enabled on RCAR H3/M3 Salvator-X/XS
      and ULCB starter kits since the AVB_LINK is correctly handled by HW.
      
      Choosing to keep or remove the "renesas,no-ether-link" option will
      have impact on the code flow in the following ways:
      - keeping this option enabled may lead to unexpected behavior since
        the RX & TX are enabled/disabled directly from adjust_link function
        without any HW interrogation,
      - removing this option, the RX & TX will only be enabled/disabled after
        HW interrogation. The HW check is made through the LMON pin in PSR
        register which specifies AVB_LINK signal value (0 - at low level;
        1 - at high level).
      
      In conclusion, the change is also a safety improvement because it
      removes the "renesas,no-ether-link" option leading to a proper way
      of detecting the link state based on HW interrogation and not on
      software heuristic.
      
      Note that DTS files for V3M Starter Kit, Draak and Eagle boards
      contain the same property, the files are untouched due to unavailable
      schematics to verify if the fix applies to these boards as well.
      
      * tag 'renesas-fixes-for-v4.15' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/horms/renesas:
        arm64: dts: renesas: ulcb: Remove renesas, no-ether-link property
        arm64: dts: renesas: salvator-x: Remove renesas, no-ether-link property
      3bfbed8d