1. 15 10月, 2022 1 次提交
  2. 29 9月, 2022 1 次提交
  3. 27 9月, 2022 1 次提交
    • J
      net: stmmac: power up/down serdes in stmmac_open/release · 49725ffc
      Junxiao Chang 提交于
      This commit fixes DMA engine reset timeout issue in suspend/resume
      with ADLink I-Pi SMARC Plus board which dmesg shows:
      ...
      [   54.678271] PM: suspend exit
      [   54.754066] intel-eth-pci 0000:00:1d.2 enp0s29f2: PHY [stmmac-3:01] driver [Maxlinear Ethernet GPY215B] (irq=POLL)
      [   54.755808] intel-eth-pci 0000:00:1d.2 enp0s29f2: Register MEM_TYPE_PAGE_POOL RxQ-0
      ...
      [   54.780482] intel-eth-pci 0000:00:1d.2 enp0s29f2: Register MEM_TYPE_PAGE_POOL RxQ-7
      [   55.784098] intel-eth-pci 0000:00:1d.2: Failed to reset the dma
      [   55.784111] intel-eth-pci 0000:00:1d.2 enp0s29f2: stmmac_hw_setup: DMA engine initialization failed
      [   55.784115] intel-eth-pci 0000:00:1d.2 enp0s29f2: stmmac_open: Hw setup failed
      ...
      
      The issue is related with serdes which impacts clock.  There is
      serdes in ADLink I-Pi SMARC board ethernet controller. Please refer to
      commit b9663b7c ("net: stmmac: Enable SERDES power up/down sequence")
      for detial. When issue is reproduced, DMA engine clock is not ready
      because serdes is not powered up.
      
      To reproduce DMA engine reset timeout issue with hardware which has
      serdes in GBE controller, install Ubuntu. In Ubuntu GUI, click
      "Power Off/Log Out" -> "Suspend" menu, it disables network interface,
      then goes to sleep mode. When it wakes up, it enables network
      interface again. Stmmac driver is called in this way:
      
      1. stmmac_release: Stop network interface. In this function, it
         disables DMA engine and network interface;
      2. stmmac_suspend: It is called in kernel suspend flow. But because
         network interface has been disabled(netif_running(ndev) is
         false), it does nothing and returns directly;
      3. System goes into S3 or S0ix state. Some time later, system is
         waken up by keyboard or mouse;
      4. stmmac_resume: It does nothing because network interface has
         been disabled;
      5. stmmac_open: It is called to enable network interace again. DMA
         engine is initialized in this API, but serdes is not power on so
         there will be DMA engine reset timeout issue.
      
      Similarly, serdes powerdown should be added in stmmac_release.
      Network interface might be disabled by cmd "ifconfig eth0 down",
      DMA engine, phy and mac have been disabled in ndo_stop callback,
      serdes should be powered down as well. It doesn't make sense that
      serdes is on while other components have been turned off.
      
      If ethernet interface is in enabled state(netif_running(ndev) is true)
      before suspend/resume, the issue couldn't be reproduced  because serdes
      could be powered up in stmmac_resume.
      
      Because serdes_powerup is added in stmmac_open, it doesn't need to be
      called in probe function.
      
      Fixes: b9663b7c ("net: stmmac: Enable SERDES power up/down sequence")
      Signed-off-by: NJunxiao Chang <junxiao.chang@intel.com>
      Reviewed-by: NVoon Weifeng <weifeng.voon@intel.com>
      Tested-by: NJimmy JS Chen <jimmyjs.chen@adlinktech.com>
      Tested-by: NLooi, Hong Aun <hong.aun.looi@intel.com>
      Link: https://lore.kernel.org/r/20220923050448.1220250-1-junxiao.chang@intel.comSigned-off-by: NPaolo Abeni <pabeni@redhat.com>
      49725ffc
  4. 08 9月, 2022 1 次提交
  5. 26 8月, 2022 1 次提交
  6. 26 7月, 2022 5 次提交
  7. 15 7月, 2022 2 次提交
    • B
      net: stmmac: fix unbalanced ptp clock issue in suspend/resume flow · f4c7d894
      Biao Huang 提交于
      Current stmmac driver will prepare/enable ptp_ref clock in
      stmmac_init_tstamp_counter().
      
      The stmmac_pltfr_noirq_suspend will disable it once in suspend flow.
      
      But in resume flow,
      	stmmac_pltfr_noirq_resume --> stmmac_init_tstamp_counter
      	stmmac_resume --> stmmac_hw_setup --> stmmac_init_ptp --> stmmac_init_tstamp_counter
      ptp_ref clock reference counter increases twice, which leads to unbalance
      ptp clock when resume back.
      
      Move ptp_ref clock prepare/enable out of stmmac_init_tstamp_counter to fix it.
      
      Fixes: 0735e639 ("net: stmmac: skip only stmmac_ptp_register when resume from suspend")
      Signed-off-by: NBiao Huang <biao.huang@mediatek.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f4c7d894
    • B
      net: stmmac: fix pm runtime issue in stmmac_dvr_remove() · 0d9a1591
      Biao Huang 提交于
      If netif is running when stmmac_dvr_remove is invoked,
      the unregister_netdev will call ndo_stop(stmmac_release) and
      vlan_kill_rx_filter(stmmac_vlan_rx_kill_vid).
      
      Currently, stmmac_dvr_remove() will disable pm runtime before
      unregister_netdev. When stmmac_vlan_rx_kill_vid is invoked,
      pm_runtime_resume_and_get in it returns EACCESS error number,
      and reports:
      
      	dwmac-mediatek 11021000.ethernet eth0: stmmac_dvr_remove: removing driver
      	dwmac-mediatek 11021000.ethernet eth0: FPE workqueue stop
      	dwmac-mediatek 11021000.ethernet eth0: failed to kill vid 0081/0
      
      Move the pm_runtime_disable to the end of stmmac_dvr_remove
      to fix this issue.
      
      Fixes: 64495203 ("net: stmmac: properly handle with runtime pm in stmmac_dvr_remove()")
      Signed-off-by: NBiao Huang <biao.huang@mediatek.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0d9a1591
  8. 02 7月, 2022 1 次提交
  9. 17 6月, 2022 1 次提交
  10. 03 6月, 2022 1 次提交
  11. 06 5月, 2022 1 次提交
  12. 01 5月, 2022 1 次提交
  13. 16 4月, 2022 1 次提交
  14. 15 4月, 2022 1 次提交
  15. 17 3月, 2022 1 次提交
    • D
      net: stmmac: clean up impossible condition · 58e06d05
      Dan Carpenter 提交于
      This code works but it has a static checker warning:
      
          drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1687 init_dma_rx_desc_rings()
          warn: always true condition '(queue >= 0) => (0-u32max >= 0)'
      
      Obviously, it makes no sense to check if an unsigned int is >= 0.  What
      prevents this code from being a forever loop is that later there is a
      separate check for if (queue == 0).
      
      The "queue" variable is less than MTL_MAX_RX_QUEUES (8) so it can easily
      fit in an int type.  Any larger value for "queue" would lead to an array
      overflow when we assign "rx_q = &priv->rx_queue[queue]".
      
      Fixes: de0b90e5 ("net: stmmac: rearrange RX and TX desc init into per-queue basis")
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Link: https://lore.kernel.org/r/20220316083744.GB30941@kiliSigned-off-by: NPaolo Abeni <pabeni@redhat.com>
      58e06d05
  16. 10 3月, 2022 1 次提交
  17. 26 2月, 2022 1 次提交
  18. 25 2月, 2022 1 次提交
    • V
      net: stmmac: only enable DMA interrupts when ready · 087a7b94
      Vincent Whitchurch 提交于
      In this driver's ->ndo_open() callback, it enables DMA interrupts,
      starts the DMA channels, then requests interrupts with request_irq(),
      and then finally enables napi.
      
      If RX DMA interrupts are received before napi is enabled, no processing
      is done because napi_schedule_prep() will return false.  If the network
      has a lot of broadcast/multicast traffic, then the RX ring could fill up
      completely before napi is enabled.  When this happens, no further RX
      interrupts will be delivered, and the driver will fail to receive any
      packets.
      
      Fix this by only enabling DMA interrupts after all other initialization
      is complete.
      
      Fixes: 523f11b5 ("net: stmmac: move hardware setup for stmmac_open to new function")
      Reported-by: NLars Persson <larper@axis.com>
      Signed-off-by: NVincent Whitchurch <vincent.whitchurch@axis.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      087a7b94
  19. 28 1月, 2022 1 次提交
    • J
      net: stmmac: properly handle with runtime pm in stmmac_dvr_remove() · 64495203
      Jisheng Zhang 提交于
      There are two issues with runtime pm handling in stmmac_dvr_remove():
      
      1. the mac is runtime suspended before stopping dma and rx/tx. We
      need to ensure the device is properly resumed back.
      
      2. the stmmaceth clk enable/disable isn't balanced in both exit and
      error handling code path. Take the exit code path for example, when we
      unbind the driver or rmmod the driver module, the mac is runtime
      suspended as said above, so the stmmaceth clk is disabled, but
      	stmmac_dvr_remove()
      	  stmmac_remove_config_dt()
      	    clk_disable_unprepare()
      CCF will complain this time. The error handling code path suffers
      from the similar situtaion.
      
      Here are kernel warnings in error handling code path on Allwinner D1
      platform:
      
      [    1.604695] ------------[ cut here ]------------
      [    1.609328] bus-emac already disabled
      [    1.613015] WARNING: CPU: 0 PID: 38 at drivers/clk/clk.c:952 clk_core_disable+0xcc/0xec
      [    1.621039] CPU: 0 PID: 38 Comm: kworker/u2:1 Not tainted 5.14.0-rc4#1
      [    1.627653] Hardware name: Allwinner D1 NeZha (DT)
      [    1.632443] Workqueue: events_unbound deferred_probe_work_func
      [    1.638286] epc : clk_core_disable+0xcc/0xec
      [    1.642561]  ra : clk_core_disable+0xcc/0xec
      [    1.646835] epc : ffffffff8023c2ec ra : ffffffff8023c2ec sp : ffffffd00411bb10
      [    1.654054]  gp : ffffffff80ec9988 tp : ffffffe00143a800 t0 : ffffffff80ed6a6f
      [    1.661272]  t1 : ffffffff80ed6a60 t2 : 0000000000000000 s0 : ffffffe001509e00
      [    1.668489]  s1 : 0000000000000001 a0 : 0000000000000019 a1 : ffffffff80e80bd8
      [    1.675707]  a2 : 00000000ffffefff a3 : 00000000000000f4 a4 : 0000000000000002
      [    1.682924]  a5 : 0000000000000001 a6 : 0000000000000030 a7 : 00000000028f5c29
      [    1.690141]  s2 : 0000000000000800 s3 : ffffffe001375000 s4 : ffffffe01fdf7a80
      [    1.697358]  s5 : ffffffe001375010 s6 : ffffffff8001fc10 s7 : ffffffffffffffff
      [    1.704577]  s8 : 0000000000000001 s9 : ffffffff80ecb248 s10: ffffffe001b80000
      [    1.711794]  s11: ffffffe001b80760 t3 : 0000000000000062 t4 : ffffffffffffffff
      [    1.719012]  t5 : ffffffff80e0f6d8 t6 : ffffffd00411b8f0
      [    1.724321] status: 8000000201800100 badaddr: 0000000000000000 cause: 0000000000000003
      [    1.732233] [<ffffffff8023c2ec>] clk_core_disable+0xcc/0xec
      [    1.737810] [<ffffffff80240430>] clk_disable+0x38/0x78
      [    1.742956] [<ffffffff8001fc0c>] worker_thread+0x1a8/0x4d8
      [    1.748451] [<ffffffff8031a500>] stmmac_remove_config_dt+0x1c/0x4c
      [    1.754646] [<ffffffff8031c8ec>] sun8i_dwmac_probe+0x378/0x82c
      [    1.760484] [<ffffffff8001fc0c>] worker_thread+0x1a8/0x4d8
      [    1.765975] [<ffffffff8029a6c8>] platform_probe+0x64/0xf0
      [    1.771382] [<ffffffff8029833c>] really_probe.part.0+0x8c/0x30c
      [    1.777305] [<ffffffff8029865c>] __driver_probe_device+0xa0/0x148
      [    1.783402] [<ffffffff8029873c>] driver_probe_device+0x38/0x138
      [    1.789324] [<ffffffff802989cc>] __device_attach_driver+0xd0/0x170
      [    1.795508] [<ffffffff802988f8>] __driver_attach_async_helper+0xbc/0xc0
      [    1.802125] [<ffffffff802965ac>] bus_for_each_drv+0x68/0xb4
      [    1.807701] [<ffffffff80298d1c>] __device_attach+0xd8/0x184
      [    1.813277] [<ffffffff802967b0>] bus_probe_device+0x98/0xbc
      [    1.818852] [<ffffffff80297904>] deferred_probe_work_func+0x90/0xd4
      [    1.825122] [<ffffffff8001f8b8>] process_one_work+0x1e4/0x390
      [    1.830872] [<ffffffff8001fd80>] worker_thread+0x31c/0x4d8
      [    1.836362] [<ffffffff80026bf4>] kthreadd+0x94/0x188
      [    1.841335] [<ffffffff80026bf4>] kthreadd+0x94/0x188
      [    1.846304] [<ffffffff8001fa60>] process_one_work+0x38c/0x390
      [    1.852054] [<ffffffff80026564>] kthread+0x124/0x160
      [    1.857021] [<ffffffff8002643c>] set_kthread_struct+0x5c/0x60
      [    1.862770] [<ffffffff80001f08>] ret_from_syscall_rejected+0x8/0xc
      [    1.868956] ---[ end trace 8d5c6046255f84a0 ]---
      [    1.873675] ------------[ cut here ]------------
      [    1.878366] bus-emac already unprepared
      [    1.882378] WARNING: CPU: 0 PID: 38 at drivers/clk/clk.c:810 clk_core_unprepare+0xe4/0x168
      [    1.890673] CPU: 0 PID: 38 Comm: kworker/u2:1 Tainted: G        W	5.14.0-rc4 #1
      [    1.898674] Hardware name: Allwinner D1 NeZha (DT)
      [    1.903464] Workqueue: events_unbound deferred_probe_work_func
      [    1.909305] epc : clk_core_unprepare+0xe4/0x168
      [    1.913840]  ra : clk_core_unprepare+0xe4/0x168
      [    1.918375] epc : ffffffff8023d6cc ra : ffffffff8023d6cc sp : ffffffd00411bb10
      [    1.925593]  gp : ffffffff80ec9988 tp : ffffffe00143a800 t0 : 0000000000000002
      [    1.932811]  t1 : ffffffe01f743be0 t2 : 0000000000000040 s0 : ffffffe001509e00
      [    1.940029]  s1 : 0000000000000001 a0 : 000000000000001b a1 : ffffffe00143a800
      [    1.947246]  a2 : 0000000000000000 a3 : 00000000000000f4 a4 : 0000000000000001
      [    1.954463]  a5 : 0000000000000000 a6 : 0000000005fce2a5 a7 : 0000000000000001
      [    1.961680]  s2 : 0000000000000800 s3 : ffffffff80afeb90 s4 : ffffffe01fdf7a80
      [    1.968898]  s5 : ffffffe001375010 s6 : ffffffff8001fc10 s7 : ffffffffffffffff
      [    1.976115]  s8 : 0000000000000001 s9 : ffffffff80ecb248 s10: ffffffe001b80000
      [    1.983333]  s11: ffffffe001b80760 t3 : ffffffff80b39120 t4 : 0000000000000001
      [    1.990550]  t5 : 0000000000000000 t6 : ffffffe001600002
      [    1.995859] status: 8000000201800120 badaddr: 0000000000000000 cause: 0000000000000003
      [    2.003771] [<ffffffff8023d6cc>] clk_core_unprepare+0xe4/0x168
      [    2.009609] [<ffffffff802403a0>] clk_unprepare+0x24/0x3c
      [    2.014929] [<ffffffff8031a508>] stmmac_remove_config_dt+0x24/0x4c
      [    2.021125] [<ffffffff8031c8ec>] sun8i_dwmac_probe+0x378/0x82c
      [    2.026965] [<ffffffff8001fc0c>] worker_thread+0x1a8/0x4d8
      [    2.032463] [<ffffffff8029a6c8>] platform_probe+0x64/0xf0
      [    2.037871] [<ffffffff8029833c>] really_probe.part.0+0x8c/0x30c
      [    2.043795] [<ffffffff8029865c>] __driver_probe_device+0xa0/0x148
      [    2.049892] [<ffffffff8029873c>] driver_probe_device+0x38/0x138
      [    2.055815] [<ffffffff802989cc>] __device_attach_driver+0xd0/0x170
      [    2.061999] [<ffffffff802988f8>] __driver_attach_async_helper+0xbc/0xc0
      [    2.068616] [<ffffffff802965ac>] bus_for_each_drv+0x68/0xb4
      [    2.074193] [<ffffffff80298d1c>] __device_attach+0xd8/0x184
      [    2.079769] [<ffffffff802967b0>] bus_probe_device+0x98/0xbc
      [    2.085345] [<ffffffff80297904>] deferred_probe_work_func+0x90/0xd4
      [    2.091616] [<ffffffff8001f8b8>] process_one_work+0x1e4/0x390
      [    2.097367] [<ffffffff8001fd80>] worker_thread+0x31c/0x4d8
      [    2.102858] [<ffffffff80026bf4>] kthreadd+0x94/0x188
      [    2.107830] [<ffffffff80026bf4>] kthreadd+0x94/0x188
      [    2.112800] [<ffffffff8001fa60>] process_one_work+0x38c/0x390
      [    2.118551] [<ffffffff80026564>] kthread+0x124/0x160
      [    2.123520] [<ffffffff8002643c>] set_kthread_struct+0x5c/0x60
      [    2.129268] [<ffffffff80001f08>] ret_from_syscall_rejected+0x8/0xc
      [    2.135455] ---[ end trace 8d5c6046255f84a1 ]---
      
      Fixes: 5ec55823 ("net: stmmac: add clocks management for gmac driver")
      Signed-off-by: NJisheng Zhang <jszhang@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      64495203
  20. 27 1月, 2022 2 次提交
  21. 26 1月, 2022 6 次提交
  22. 25 1月, 2022 1 次提交
  23. 14 1月, 2022 1 次提交
  24. 14 12月, 2021 2 次提交
  25. 13 12月, 2021 2 次提交
  26. 30 11月, 2021 1 次提交
    • B
      net: stmmac: Add platform level debug register dump feature · 4047b9db
      Bhupesh Sharma 提交于
      dwmac-qcom-ethqos currently exposes a mechanism to dump rgmii registers
      after the 'stmmac_dvr_probe()' returns. However with commit
      5ec55823 ("net: stmmac: add clocks management for gmac driver"),
      we now let 'pm_runtime_put()' disable the clocks before returning from
      'stmmac_dvr_probe()'.
      
      This causes a crash when 'rgmii_dump()' register dumps are enabled,
      as the clocks are already off.
      
      Since other dwmac drivers (possible future users as well) might
      require a similar register dump feature, introduce a platform level
      callback to allow the same.
      
      This fixes the crash noticed while enabling rgmii_dump() dumps in
      dwmac-qcom-ethqos driver as well. It also allows future changes
      to keep a invoking the register dump callback from the correct
      place inside 'stmmac_dvr_probe()'.
      
      Fixes: 5ec55823 ("net: stmmac: add clocks management for gmac driver")
      Cc: Joakim Zhang <qiangqing.zhang@nxp.com>
      Cc: David S. Miller <davem@davemloft.net>
      Signed-off-by: NBhupesh Sharma <bhupesh.sharma@linaro.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4047b9db
  27. 29 11月, 2021 1 次提交
    • V
      net: stmmac: Avoid DMA_CHAN_CONTROL write if no Split Header support · f8e7dfd6
      Vincent Whitchurch 提交于
      The driver assumes that split headers can be enabled/disabled without
      stopping/starting the device, so it writes DMA_CHAN_CONTROL from
      stmmac_set_features().  However, on my system (IP v5.10a without Split
      Header support), simply writing DMA_CHAN_CONTROL when DMA is running
      (for example, with the commands below) leads to a TX watchdog timeout.
      
       host$ socat TCP-LISTEN:1024,fork,reuseaddr - &
       device$ ethtool -K eth0 tso off
       device$ ethtool -K eth0 tso on
       device$ dd if=/dev/zero bs=1M count=10 | socat - TCP4:host:1024
       <tx watchdog timeout>
      
      Note that since my IP is configured without Split Header support, the
      driver always just reads and writes the same value to the
      DMA_CHAN_CONTROL register.
      
      I don't have access to any platforms with Split Header support so I
      don't know if these writes to the DMA_CHAN_CONTROL while DMA is running
      actually work properly on such systems.  I could not find anything in
      the databook that says that DMA_CHAN_CONTROL should not be written when
      the DMA is running.
      
      But on systems without Split Header support, there is in any case no
      need to call enable_sph() in stmmac_set_features() at all since SPH can
      never be toggled, so we can avoid the watchdog timeout there by skipping
      this call.
      
      Fixes: 8c6fc097 ("net: stmmac: gmac4+: Add Split Header support")
      Signed-off-by: NVincent Whitchurch <vincent.whitchurch@axis.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f8e7dfd6