1. 15 12月, 2017 1 次提交
  2. 14 12月, 2017 13 次提交
  3. 12 12月, 2017 2 次提交
    • T
      net: sh_eth: do not advertise Gigabit capabilities when not available · 2aab6b40
      Thomas Petazzoni 提交于
      Not all variants of the sh_eth hardware have Gigabit
      support. Unfortunately, the current driver doesn't tell the PHY about
      the limited MAC capabilities. Due to this, if you have a Gigabit
      capable PHY, the PHY will advertise its Gigabit capability and
      establish a link at 1Gbit/s, even though the MAC doesn't support it.
      
      In order to avoid this, we use the recently introduced
      phy_set_max_speed() to tell the PHY to not advertise speed higher than
      100 MBit/s.
      
      Tested on a SH7786 platform, with a Gigabit PHY.
      Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2aab6b40
    • J
      net: phy: meson-gxl: detect LPA corruption · f1e2400a
      Jerome Brunet 提交于
      The purpose of this change is to fix the incorrect detection of the link
      partner (LP) advertised capabilities which sometimes happens with this PHY
      (roughly 1 time in a dozen)
      
      This issue may cause the link to be negotiated at 10Mbps/Full or
      10Mbps/Half when 100MBps/Full is actually possible. In some case, the link
      is even completely broken and no communication is possible.
      
      To detect the corruption, we must look for a magic undocumented bit in the
      WOL bank (hint given by the SoC vendor kernel) but this is not enough to
      cover all cases. We also have to look at the LPA ack. If the LP supports
      Aneg but did not ack our base code when aneg is completed, we assume
      something went wrong.
      
      The detection of a corrupted LPA triggers a restart of the aneg process.
      This solves the problem but may take up to 6 retries to complete.
      
      Fixes: 7334b3e4 ("net: phy: Add Meson GXL Internal PHY driver")
      Signed-off-by: NJerome Brunet <jbrunet@baylibre.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f1e2400a
  4. 09 12月, 2017 4 次提交
    • A
      net: mvpp2: fix the RSS table entry offset · 8a7b741e
      Antoine Tenart 提交于
      The macro used to access or set an RSS table entry was using an offset
      of 8, while it should use an offset of 0. This lead to wrongly configure
      the RSS table, not accessing the right entries.
      
      Fixes: 1d7d15d7 ("net: mvpp2: initialize the RSS tables")
      Signed-off-by: NAntoine Tenart <antoine.tenart@free-electrons.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8a7b741e
    • C
      bnxt_en: Fix sources of spurious netpoll warnings · 2edbdb31
      Calvin Owens 提交于
      After applying 2270bc5d ("bnxt_en: Fix netpoll handling") and
      903649e7 ("bnxt_en: Improve -ENOMEM logic in NAPI poll loop."),
      we still see the following WARN fire:
      
        ------------[ cut here ]------------
        WARNING: CPU: 0 PID: 1875170 at net/core/netpoll.c:165 netpoll_poll_dev+0x15a/0x160
        bnxt_poll+0x0/0xd0 exceeded budget in poll
        <snip>
        Call Trace:
         [<ffffffff814be5cd>] dump_stack+0x4d/0x70
         [<ffffffff8107e013>] __warn+0xd3/0xf0
         [<ffffffff8107e07f>] warn_slowpath_fmt+0x4f/0x60
         [<ffffffff8179519a>] netpoll_poll_dev+0x15a/0x160
         [<ffffffff81795f38>] netpoll_send_skb_on_dev+0x168/0x250
         [<ffffffff817962fc>] netpoll_send_udp+0x2dc/0x440
         [<ffffffff815fa9be>] write_ext_msg+0x20e/0x250
         [<ffffffff810c8125>] call_console_drivers.constprop.23+0xa5/0x110
         [<ffffffff810c9549>] console_unlock+0x339/0x5b0
         [<ffffffff810c9a88>] vprintk_emit+0x2c8/0x450
         [<ffffffff810c9d5f>] vprintk_default+0x1f/0x30
         [<ffffffff81173df5>] printk+0x48/0x50
         [<ffffffffa0197713>] edac_raw_mc_handle_error+0x563/0x5c0 [edac_core]
         [<ffffffffa0197b9b>] edac_mc_handle_error+0x42b/0x6e0 [edac_core]
         [<ffffffffa01c3a60>] sbridge_mce_output_error+0x410/0x10d0 [sb_edac]
         [<ffffffffa01c47cc>] sbridge_check_error+0xac/0x130 [sb_edac]
         [<ffffffffa0197f3c>] edac_mc_workq_function+0x3c/0x90 [edac_core]
         [<ffffffff81095f8b>] process_one_work+0x19b/0x480
         [<ffffffff810967ca>] worker_thread+0x6a/0x520
         [<ffffffff8109c7c4>] kthread+0xe4/0x100
         [<ffffffff81884c52>] ret_from_fork+0x22/0x40
      
      This happens because we increment rx_pkts on -ENOMEM and -EIO, resulting
      in rx_pkts > 0. Fix this by only bumping rx_pkts if we were actually
      given a non-zero budget.
      Signed-off-by: NCalvin Owens <calvinowens@fb.com>
      Acked-by: NMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2edbdb31
    • B
      sfc: pass valid pointers from efx_enqueue_unwind · d4a7a889
      Bert Kenward 提交于
      The bytes_compl and pkts_compl pointers passed to efx_dequeue_buffers
      cannot be NULL. Add a paranoid warning to check this condition and fix
      the one case where they were NULL.
      
      efx_enqueue_unwind() is called very rarely, during error handling.
      Without this fix it would fail with a NULL pointer dereference in
      efx_dequeue_buffer, with efx_enqueue_skb in the call stack.
      
      Fixes: e9117e50 ("sfc: Firmware-Assisted TSO version 2")
      Reported-by: NJarod Wilson <jarod@redhat.com>
      Signed-off-by: NBert Kenward <bkenward@solarflare.com>
      Tested-by: NJarod Wilson <jarod@redhat.com>
      Acked-by: NJarod Wilson <jarod@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d4a7a889
    • C
      gianfar: Disable EEE autoneg by default · b6b5e8a6
      Claudiu Manoil 提交于
      This controller does not support EEE, but it may connect to a PHY
      which supports EEE and advertises EEE by default, while its link
      partner also advertises EEE. If this happens, the PHY enters low
      power mode when the traffic rate is low and causes packet loss.
      This patch disables EEE advertisement by default for any PHY that
      gianfar connects to, to prevent the above unwanted outcome.
      Signed-off-by: NShaohui Xie <Shaohui.Xie@nxp.com>
      Tested-by: NYangbo Lu <Yangbo.lu@nxp.com>
      Signed-off-by: NClaudiu Manoil <claudiu.manoil@nxp.com>
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b6b5e8a6
  5. 08 12月, 2017 16 次提交
  6. 07 12月, 2017 4 次提交
    • M
      drm/bridge: analogix dp: Fix runtime PM state in get_modes() callback · 510353a6
      Marek Szyprowski 提交于
      get_modes() callback might be called asynchronously from the DRM core and
      it is not synchronized with bridge_enable(), which sets proper runtime PM
      state of the main DP device. Fix this by calling pm_runtime_get_sync()
      before calling drm_get_edid(), which in turn calls drm_dp_i2c_xfer() and
      analogix_dp_transfer() to ensure that main DP device is runtime active
      when doing any access to its registers.
      
      This fixes the following kernel issue on Samsung Exynos5250 Snow board:
      Unhandled fault: imprecise external abort (0x406) at 0x00000000
      pgd = c0004000
      [00000000] *pgd=00000000
      Internal error: : 406 [#1] PREEMPT SMP ARM
      Modules linked in:
      CPU: 0 PID: 62 Comm: kworker/0:2 Not tainted 4.13.0-rc2-00364-g4a97a3da #3357
      Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
      Workqueue: events output_poll_execute
      task: edc14800 task.stack: edcb2000
      PC is at analogix_dp_transfer+0x15c/0x2fc
      LR is at analogix_dp_transfer+0x134/0x2fc
      pc : [<c0468538>]    lr : [<c0468510>]    psr: 60000013
      sp : edcb3be8  ip : 0000002a  fp : 00000001
      r10: 00000000  r9 : edcb3cd8  r8 : edcb3c40
      r7 : 00000000  r6 : edd3b380  r5 : edd3b010  r4 : 00000064
      r3 : 00000000  r2 : f0ad3000  r1 : edcb3c40  r0 : edd3b010
      Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
      Control: 10c5387d  Table: 4000406a  DAC: 00000051
      Process kworker/0:2 (pid: 62, stack limit = 0xedcb2210)
      Stack: (0xedcb3be8 to 0xedcb4000)
      [<c0468538>] (analogix_dp_transfer) from [<c0424ba4>] (drm_dp_i2c_do_msg+0x8c/0x2b4)
      [<c0424ba4>] (drm_dp_i2c_do_msg) from [<c0424e64>] (drm_dp_i2c_xfer+0x98/0x214)
      [<c0424e64>] (drm_dp_i2c_xfer) from [<c057b2d8>] (__i2c_transfer+0x140/0x29c)
      [<c057b2d8>] (__i2c_transfer) from [<c057b4a4>] (i2c_transfer+0x70/0xe4)
      [<c057b4a4>] (i2c_transfer) from [<c0441de4>] (drm_do_probe_ddc_edid+0xb4/0x114)
      [<c0441de4>] (drm_do_probe_ddc_edid) from [<c0441e5c>] (drm_probe_ddc+0x18/0x28)
      [<c0441e5c>] (drm_probe_ddc) from [<c0445728>] (drm_get_edid+0x124/0x2d4)
      [<c0445728>] (drm_get_edid) from [<c0465ea0>] (analogix_dp_get_modes+0x90/0x114)
      [<c0465ea0>] (analogix_dp_get_modes) from [<c0425e8c>] (drm_helper_probe_single_connector_modes+0x198/0x68c)
      [<c0425e8c>] (drm_helper_probe_single_connector_modes) from [<c04325d4>] (drm_setup_crtcs+0x1b4/0xd18)
      [<c04325d4>] (drm_setup_crtcs) from [<c04344a8>] (drm_fb_helper_hotplug_event+0x94/0xd0)
      [<c04344a8>] (drm_fb_helper_hotplug_event) from [<c0425a50>] (drm_kms_helper_hotplug_event+0x24/0x28)
      [<c0425a50>] (drm_kms_helper_hotplug_event) from [<c04263ec>] (output_poll_execute+0x6c/0x174)
      [<c04263ec>] (output_poll_execute) from [<c0136f18>] (process_one_work+0x188/0x3fc)
      [<c0136f18>] (process_one_work) from [<c01371f4>] (worker_thread+0x30/0x4b8)
      [<c01371f4>] (worker_thread) from [<c013daf8>] (kthread+0x128/0x164)
      [<c013daf8>] (kthread) from [<c0108510>] (ret_from_fork+0x14/0x24)
      Code: 0a000002 ea000009 e2544001 0a00004a (e59537c8)
      ---[ end trace cddc7919c79f7878 ]---
      Reported-by: NMisha Komarovskiy <zombah@gmail.com>
      CC: stable@vger.kernel.org # v4.10+
      Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
      Signed-off-by: NArchit Taneja <architt@codeaurora.org>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171121074936.22520-1-m.szyprowski@samsung.com
      510353a6
    • A
      brcmfmac: Avoid build error with make W=1 · 51ef7925
      Andy Shevchenko 提交于
      When I run make W=1 on gcc (Debian 7.2.0-16) 7.2.0 I got an error for
      the first run, all next ones are okay.
      
        CC [M]  drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.o
      drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c:2078: error: Cannot parse struct or union!
      scripts/Makefile.build:310: recipe for target 'drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.o' failed
      
      Seems like something happened with W=1 and wrong kernel doc format.
      As a quick fix remove dubious /** in the code.
      Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Acked-by: NArend van Spriel <arend.vanspriel@broadcom.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      51ef7925
    • R
      Revert "drm/i915: Display WA #1133 WaFbcSkipSegments:cnl, glk" · 7a8b7053
      Radhakrishna Sripada 提交于
      This reverts commit 8f067837.
      
      HSD says "WA withdrawn. It was causing corruption with some images.
      WA is not strictly necessary since this bug just causes loss of FBC
      compression with some sizes and images, but doesn't break anything."
      
      Fixes: 8f067837 ("drm/i915: Display WA #1133 WaFbcSkipSegments:cnl, glk")
      Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
      Signed-off-by: NRadhakrishna Sripada <radhakrishna.sripada@intel.com>
      Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171117010825.23118-1-radhakrishna.sripada@intel.com
      (cherry picked from commit 0cfecb7c)
      Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      7a8b7053
    • B
      drm/vc4: Fix false positive WARN() backtrace on refcount_inc() usage · 5bfd4013
      Boris Brezillon 提交于
      With CONFIG_REFCOUNT_FULL enabled, refcount_inc() complains when it's
      passed a refcount object that has its counter set to 0. In this driver,
      this is a valid use case since we want to increment ->usecnt only when
      the BO object starts to be used by real HW components and this is
      definitely not the case when the BO is created.
      
      Fix the problem by using refcount_inc_not_zero() instead of
      refcount_inc() and fallback to refcount_set(1) when
      refcount_inc_not_zero() returns false. Note that this 2-steps operation
      is not racy here because the whole section is protected by a mutex
      which guarantees that the counter does not change between the
      refcount_inc_not_zero() and refcount_set() calls.
      
      Fixes: b9f19259 ("drm/vc4: Add the DRM_IOCTL_VC4_GEM_MADVISE ioctl")
      Reported-by: NStefan Wahren <stefan.wahren@i2se.com>
      Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
      Acked-by: NEric Anholt <eric@anholt.net>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171122203928.28135-1-boris.brezillon@free-electrons.com
      5bfd4013