1. 23 Dec, 2016 13 commits
  2. 22 Dec, 2016 12 commits
  3. 21 Dec, 2016 15 commits
    • Colin Ian King's avatar
      net: fddi: skfp: use %p format specifier for addresses rather than %x · 551cde19
      Colin Ian King authored
      
      
      Trivial fix: Addresses should be printed using the %p format specifier
      rather than using %x.
      
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      551cde19
    • Thomas Petazzoni's avatar
      net: mvpp2: fix dma unmapping of TX buffers for fragments · 8354491c
      Thomas Petazzoni authored
      Since commit 71ce391d ("net: mvpp2: enable proper per-CPU TX
      buffers unmapping"), we are not correctly DMA unmapping TX buffers for
      fragments.
      
      Indeed, the mvpp2_txq_inc_put() function only stores in the
      txq_cpu->tx_buffs[] array the physical address of the buffer to be
      DMA-unmapped when skb != NULL. In addition, when DMA-unmapping, we use
      skb_headlen(skb) to get the size to be unmapped. Both of this works fine
      for TX descriptors that are associated directly to a SKB, but not the
      ones that are used for fragments, with a NULL pointer as skb:
      
       - We have a NULL physical address when calling DMA unmap
       - skb_headlen(skb) crashes because skb is NULL
      
      This causes random crashes when fragments are used.
      
      To solve this problem, we need to:
      
       - Store the physical address of the buffer to be unmapped
         unconditionally, regardless of whether it is tied to a SKB or not.
      
       - Store the length of the buffer to be unmapped, which requires a new
         field.
      
      Instead of adding a third array to store the length of the buffer to be
      unmapped, and as suggested by David Miller, this commit refactors the
      tx_buffs[] and tx_skb[] arrays of 'struct mvpp2_txq_pcpu' into a
      separate structure 'mvpp2_txq_pcpu_buf', to which a 'size' field is
      added. Therefore, instead of having three arrays to allocate/free, we
      have a single one, which also improve data locality, reducing the
      impact on the CPU cache.
      
      Fixes: 71ce391d
      
       ("net: mvpp2: enable proper per-CPU TX buffers unmapping")
      Reported-by: default avatarRaphael G <raphael.glon@corp.ovh.com>
      Cc: Raphael G <raphael.glon@corp.ovh.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8354491c
    • Heiko Stübner's avatar
      net: ethernet: stmmac: dwmac-rk: make clk enablement first in powerup · f217bfde
      Heiko Stübner authored
      
      
      Right now the dwmac-rk tries to set up the GRF-specific speed and link
      options before enabling clocks, phys etc and on previous socs this works
      because the GRF is supplied on the whole by one clock.
      
      On the rk3399 however the GRF (General Register Files) clock-supply
      has been split into multiple clocks and while there is no specific
      grf-gmac clock like for other sub-blocks, it seems the mac-specific
      portions are actually supplied by the general mac clock.
      
      This results in hangs on rk3399 boards if the driver is build as module.
      When built in te problem of course doesn't surface, as the clocks
      are of course still on at the stage before clock_disable_unused.
      
      To solve this, simply move the clock enablement to the first position
      in the powerup callback. This is also a good idea in general to
      enable clocks before everything else.
      
      Tested on rk3288, rk3368 and rk3399 the dwmac still works on all of them.
      
      Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f217bfde
    • Kalesh A P's avatar
      be2net: Increase skb headroom size to 256 bytes · 76b15923
      Kalesh A P authored
      
      
      The driver currently allocates 128 bytes of skb headroom.
      This was found to be insufficient with some configurations
      like Geneve tunnels, which resulted in skb head reallocations.
      
      Increase the headroom to 256 bytes to fix this.
      
      Signed-off-by: default avatarKalesh A P <kalesh-anakkur.purayil@broadcom.com>
      Signed-off-by: default avatarSuresh Reddy <suresh.reddy@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      76b15923
    • Larry Finger's avatar
      rtlwifi: Fix kernel oops introduced with commit e4965614 · 22b68b93
      Larry Finger authored
      With commit e4965614 {"rtlwifi: Use dev_kfree_skb_irq instead of
      kfree_skb"), the method used to free an skb was changed because the
      kfree_skb() was inside a spinlock. What was forgotten is that kfree_skb()
      guards against a NULL value for the argument. Routine dev_kfree_skb_irq()
      does not, and a test is needed to prevent kernel panics.
      
      Fixes: e4965614
      
       ("rtlwifi: Use dev_kfree_skb_irq instead of kfree_skb")
      Signed-off-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Cc: Stable <stable@vger.kernel.org> # 4.9+
      Cc: Wei Yongjun <weiyongjun1@huawei.com>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      22b68b93
    • Tobias Klausmann's avatar
      ath9k: do not return early to fix rcu unlocking · d1f1c0e2
      Tobias Klausmann authored
      Starting with commit d94a461d
      
       ("ath9k: use ieee80211_tx_status_noskb
      where possible") the driver uses rcu_read_lock() && rcu_read_unlock(), yet on
      returning early in ath_tx_edma_tasklet() the unlock is missing leading to stalls
      and suspicious RCU usage:
      
       ===============================
       [ INFO: suspicious RCU usage. ]
       4.9.0-rc8 #11 Not tainted
       -------------------------------
       kernel/rcu/tree.c:705 Illegal idle entry in RCU read-side critical section.!
      
       other info that might help us debug this:
      
       RCU used illegally from idle CPU!
       rcu_scheduler_active = 1, debug_locks = 0
       RCU used illegally from extended quiescent state!
       1 lock held by swapper/7/0:
       #0:
        (
       rcu_read_lock
       ){......}
       , at:
       [<ffffffffa06ed110>] ath_tx_edma_tasklet+0x0/0x450 [ath9k]
      
       stack backtrace:
       CPU: 7 PID: 0 Comm: swapper/7 Not tainted 4.9.0-rc8 #11
       Hardware name: Acer Aspire V3-571G/VA50_HC_CR, BIOS V2.21 12/16/2013
        ffff88025efc3f38 ffffffff8132b1e5 ffff88017ede4540 0000000000000001
        ffff88025efc3f68 ffffffff810a25f7 ffff88025efcee60 ffff88017edebdd8
        ffff88025eeb5400 0000000000000091 ffff88025efc3f88 ffffffff810c3cd4
       Call Trace:
        <IRQ>
        [<ffffffff8132b1e5>] dump_stack+0x68/0x93
        [<ffffffff810a25f7>] lockdep_rcu_suspicious+0xd7/0x110
        [<ffffffff810c3cd4>] rcu_eqs_enter_common.constprop.85+0x154/0x200
        [<ffffffff810c5a54>] rcu_irq_exit+0x44/0xa0
        [<ffffffff81058631>] irq_exit+0x61/0xd0
        [<ffffffff81018d25>] do_IRQ+0x65/0x110
        [<ffffffff81672189>] common_interrupt+0x89/0x89
        <EOI>
        [<ffffffff814ffe11>] ? cpuidle_enter_state+0x151/0x200
        [<ffffffff814ffee2>] cpuidle_enter+0x12/0x20
        [<ffffffff8109a6ae>] call_cpuidle+0x1e/0x40
        [<ffffffff8109a8f6>] cpu_startup_entry+0x146/0x220
        [<ffffffff810336f8>] start_secondary+0x148/0x170
      
      Signed-off-by: default avatarTobias Klausmann <tobias.johannes.klausmann@mni.thm.de>
      Fixes: d94a461d
      
       ("ath9k: use ieee80211_tx_status_noskb where possible")
      Cc: <stable@vger.kernel.org> # v4.9
      Acked-by: default avatarFelix Fietkau <nbd@nbd.name>
      Acked-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Tested-by: default avatarGabriel Craciunescu <nix.or.die@gmail.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      d1f1c0e2
    • Paul Burton's avatar
      mmc: sd: Meet alignment requirements for raw_ssr DMA · e85baa88
      Paul Burton authored
      
      
      The mmc_read_ssr() function results in DMA to the raw_ssr member of
      struct mmc_card, which is not guaranteed to be cache line aligned & thus
      might not meet the requirements set out in Documentation/DMA-API.txt:
      
        Warnings:  Memory coherency operates at a granularity called the cache
        line width.  In order for memory mapped by this API to operate
        correctly, the mapped region must begin exactly on a cache line
        boundary and end exactly on one (to prevent two separately mapped
        regions from sharing a single cache line).  Since the cache line size
        may not be known at compile time, the API will not enforce this
        requirement.  Therefore, it is recommended that driver writers who
        don't take special care to determine the cache line size at run time
        only map virtual regions that begin and end on page boundaries (which
        are guaranteed also to be cache line boundaries).
      
      On some systems where DMA is non-coherent this can lead to us losing
      data that shares cache lines with the raw_ssr array.
      
      Fix this by kmalloc'ing a temporary buffer to perform DMA into. kmalloc
      will ensure the buffer is suitably aligned, allowing the DMA to be
      performed without any loss of data.
      
      Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Fixes: 5275a652
      
       ("mmc: sd: Export SD Status via “ssr” device attribute")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      e85baa88
    • Arnd Bergmann's avatar
      cpufreq: s3c64xx: remove incorrect __init annotation · adec57c6
      Arnd Bergmann authored
      
      
      s3c64xx_cpufreq_config_regulator is incorrectly annotated
      as __init, since the caller is also not init:
      
      WARNING: vmlinux.o(.text+0x92fe1c): Section mismatch in reference from the function s3c64xx_cpufreq_driver_init() to the function .init.text:s3c64xx_cpufreq_config_regulator()
      
      With modern gcc versions, the function gets inline, so we don't
      see the warning, this only happens with gcc-4.6 and older.
      
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarKrzysztof Kozlowski <krzk@kernel.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      adec57c6
    • Boris Ostrovsky's avatar
      cpufreq: Remove CPU hotplug callbacks only if they were initialized · 2a8fa123
      Boris Ostrovsky authored
      
      
      Since CPU hotplug callbacks are requested for CPUHP_AP_ONLINE_DYN state,
      successful callback initialization will result in cpuhp_setup_state()
      returning a positive value. Therefore acpi_cpufreq_online being zero
      indicates that callbacks have not been installed.
      
      This means that acpi_cpufreq_boost_exit() should only remove them if
      acpi_cpufreq_online is positive. Trying to call
      cpuhp_remove_state_nocalls(0) will cause a BUG().
      
      Signed-off-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      2a8fa123
    • Lv Zheng's avatar
      ACPI / osl: Remove deprecated acpi_get_table_with_size()/early_acpi_os_unmap_memory() · 8d3523fb
      Lv Zheng authored
      
      
      Since all users are cleaned up, remove the 2 deprecated APIs due to no
      users.
      As a Linux variable rather than an ACPICA variable, acpi_gbl_permanent_mmap
      is renamed to acpi_permanent_mmap to have a consistent coding style across
      entire Linux ACPI subsystem.
      
      Signed-off-by: default avatarLv Zheng <lv.zheng@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      8d3523fb
    • Lv Zheng's avatar
      ACPI / osl: Remove acpi_get_table_with_size()/early_acpi_os_unmap_memory() users · 6b11d1d6
      Lv Zheng authored
      
      
      This patch removes the users of the deprectated APIs:
       acpi_get_table_with_size()
       early_acpi_os_unmap_memory()
      The following APIs should be used instead of:
       acpi_get_table()
       acpi_put_table()
      
      The deprecated APIs are invented to be a replacement of acpi_get_table()
      during the early stage so that the early mapped pointer will not be stored
      in ACPICA core and thus the late stage acpi_get_table() won't return a
      wrong pointer. The mapping size is returned just because it is required by
      early_acpi_os_unmap_memory() to unmap the pointer during early stage.
      
      But as the mapping size equals to the acpi_table_header.length
      (see acpi_tb_init_table_descriptor() and acpi_tb_validate_table()), when
      such a convenient result is returned, driver code will start to use it
      instead of accessing acpi_table_header to obtain the length.
      
      Thus this patch cleans up the drivers by replacing returned table size with
      acpi_table_header.length, and should be a no-op.
      
      Reported-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarLv Zheng <lv.zheng@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      6b11d1d6
    • Lv Zheng's avatar
      ACPICA: Tables: Allow FADT to be customized with virtual address · 66360faa
      Lv Zheng authored
      ACPICA commit d98de9ca14891130efc5dcdc871b97eb27b4b0f5
      
      FADT parsing code requires FADT to be installed as
      ACPI_TABLE_ORIGIN_INTERNAL_PHYSICAL, using new
      acpi_tb_get_table()/acpi_tb_put_table(), other address types can also be allowed,
      thus facilitates FADT customization with virtual address. Lv Zheng.
      
      Link: https://github.com/acpica/acpica/commit/d98de9ca
      
      
      Signed-off-by: default avatarLv Zheng <lv.zheng@intel.com>
      Signed-off-by: default avatarBob Moore <robert.moore@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      66360faa
    • Lv Zheng's avatar
      ACPICA: Tables: Back port acpi_get_table_with_size() and... · 174cc718
      Lv Zheng authored
      ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel
      
      ACPICA commit cac6790954d4d752a083e6122220b8a22febcd07
      
      This patch back ports Linux acpi_get_table_with_size() and
      early_acpi_os_unmap_memory() into ACPICA upstream to reduce divergences.
      
      The 2 APIs are used by Linux as table management APIs for long time, it
      contains a hidden logic that during the early stage, the mapped tables
      should be unmapped before the early stage ends.
      
      During the early stage, tables are handled by the following sequence:
       acpi_get_table_with_size();
       parse the table
       early_acpi_os_unmap_memory();
      During the late stage, tables are handled by the following sequence:
       acpi_get_table();
       parse the table
      Linux uses acpi_gbl_permanent_mmap to distinguish the early stage and the
      late stage.
      
      The reasoning of introducing acpi_get_table_with_size() is: ACPICA will
      remember the early mapped pointer in acpi_get_table() and Linux isn't able to
      prevent ACPICA from using the wrong early mapped pointer during the late
      stage as there is no API provided from ACPICA to be an inverse of
      acpi_get_table() to forget the early mapped pointer.
      
      But how ACPICA can work with the early/late stage requirement? Inside of
      ACPICA, tables are ensured to be remained in "INSTALLED" state during the
      early stage, and they are carefully not transitioned to "VALIDATED" state
      until the late stage. So the same logic is in fact implemented inside of
      ACPICA in a different way. The gap is only that the feature is not provided
      to the OSPMs in an accessible external API style.
      
      It then is possible to fix the gap by providing an inverse of
      acpi_get_table() from ACPICA, so that the two Linux sequences can be
      combined:
       acpi_get_table();
       parse the table
       acpi_put_table();
      In order to work easier with the current Linux code, acpi_get_table() and
      acpi_put_table() is implemented in a usage counting based style:
       1. When the usage count of the table is increased from 0 to 1, table is
          mapped and .Pointer is set with the mapping address (VALIDATED);
       2. When the usage count of the table is decreased from 1 to 0, .Pointer
          is unset and the mapping address is unmapped (INVALIDATED).
      So that we can deploy the new APIs to Linux with minimal effort by just
      invoking acpi_get_table() in acpi_get_table_with_size() and invoking
      acpi_put_table() in early_acpi_os_unmap_memory(). Lv Zheng.
      
      Link: https://github.com/acpica/acpica/commit/cac67909
      
      
      Signed-off-by: default avatarLv Zheng <lv.zheng@intel.com>
      Signed-off-by: default avatarBob Moore <robert.moore@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      174cc718
    • Flora Cui's avatar
      drm/amdgpu: update tile table for oland/hainan · f8d9422e
      Flora Cui authored
      
      
      Signed-off-by: default avatarFlora Cui <Flora.Cui@amd.com>
      Reviewed-by: default avatarJunwei Zhang <Jerry.Zhang@amd.com>
      Reviewed-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      f8d9422e
    • Flora Cui's avatar
      drm/amdgpu: update tile table for verde · 3548f9a8
      Flora Cui authored
      
      
      Signed-off-by: default avatarFlora Cui <Flora.Cui@amd.com>
      Reviewed-by: default avatarJunwei Zhang <Jerry.Zhang@amd.com>
      Reviewed-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      3548f9a8