1. 12 8月, 2022 1 次提交
  2. 02 7月, 2022 1 次提交
  3. 01 7月, 2022 2 次提交
  4. 29 5月, 2022 1 次提交
  5. 28 5月, 2022 1 次提交
  6. 23 5月, 2022 5 次提交
    • I
      dpaa2-eth: unmap the SGT buffer before accessing its contents · 0a09c5b8
      Ioana Ciornei 提交于
      DMA unmap the Scatter/Gather table before going through the array to
      unmap and free each of the header and data chunks. This is so we do not
      touch the data between the dma_map and dma_unmap calls.
      
      Fixes: 3dc709e0 ("dpaa2-eth: add support for software TSO")
      Signed-off-by: NIoana Ciornei <ioana.ciornei@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0a09c5b8
    • I
      dpaa2-eth: use the correct software annotation field · d5f4e19a
      Ioana Ciornei 提交于
      The incorrect software annotation field was being used, swa->sg.sgt_size
      instead of swa->tso.sgt_size, which meant that the SGT buffer was
      unmapped with a wrong size.
      This is also confirmed by the DMA API debug prints which showed the
      following:
      
      [   38.962434] DMA-API: fsl_dpaa2_eth dpni.2: device driver frees DMA memory with different size [device address=0x0000fffffafba740] [map size=224 bytes] [unmap size=0 bytes]
      [   38.980496] WARNING: CPU: 11 PID: 1131 at kernel/dma/debug.c:973 check_unmap+0x58c/0x9b0
      [   38.988586] Modules linked in:
      [   38.991631] CPU: 11 PID: 1131 Comm: iperf3 Not tainted 5.18.0-rc7-00117-g59130eeb2b8f #1972
      [   38.999970] Hardware name: NXP Layerscape LX2160ARDB (DT)
      
      Fixes: 3dc709e0 ("dpaa2-eth: add support for software TSO")
      Signed-off-by: NIoana Ciornei <ioana.ciornei@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d5f4e19a
    • I
      dpaa2-eth: retrieve the virtual address before dma_unmap · 06d12994
      Ioana Ciornei 提交于
      The TSO header was DMA unmapped before the virtual address was retrieved
      and then used to free the buffer. This meant that we were actually
      removing the DMA map and then trying to search for it to help in
      retrieving the virtual address. This lead to a invalid virtual address
      being used in the kfree call.
      
      Fix this by calling dpaa2_iova_to_virt() prior to the dma_unmap call.
      
      [  487.231819] Unable to handle kernel paging request at virtual address fffffd9807000008
      
      (...)
      
      [  487.354061] Hardware name: SolidRun LX2160A Honeycomb (DT)
      [  487.359535] pstate: a0400005 (NzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
      [  487.366485] pc : kfree+0xac/0x304
      [  487.369799] lr : kfree+0x204/0x304
      [  487.373191] sp : ffff80000c4eb120
      [  487.376493] x29: ffff80000c4eb120 x28: ffff662240c46400 x27: 0000000000000001
      [  487.383621] x26: 0000000000000001 x25: ffff662246da0cc0 x24: ffff66224af78000
      [  487.390748] x23: ffffad184f4ce008 x22: ffffad1850185000 x21: ffffad1838d13cec
      [  487.397874] x20: ffff6601c0000000 x19: fffffd9807000000 x18: 0000000000000000
      [  487.405000] x17: ffffb910cdc49000 x16: ffffad184d7d9080 x15: 0000000000004000
      [  487.412126] x14: 0000000000000008 x13: 000000000000ffff x12: 0000000000000000
      [  487.419252] x11: 0000000000000004 x10: 0000000000000001 x9 : ffffad184d7d927c
      [  487.426379] x8 : 0000000000000000 x7 : 0000000ffffffd1d x6 : ffff662240a94900
      [  487.433505] x5 : 0000000000000003 x4 : 0000000000000009 x3 : ffffad184f4ce008
      [  487.440632] x2 : ffff662243eec000 x1 : 0000000100000100 x0 : fffffc0000000000
      [  487.447758] Call trace:
      [  487.450194]  kfree+0xac/0x304
      [  487.453151]  dpaa2_eth_free_tx_fd.isra.0+0x33c/0x3e0 [fsl_dpaa2_eth]
      [  487.459507]  dpaa2_eth_tx_conf+0x100/0x2e0 [fsl_dpaa2_eth]
      [  487.464989]  dpaa2_eth_poll+0xdc/0x380 [fsl_dpaa2_eth]
      
      Fixes: 3dc709e0 ("dpaa2-eth: add support for software TSO")
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=215886Signed-off-by: NIoana Ciornei <ioana.ciornei@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      06d12994
    • U
      net: fec: Do proper error checking for enet_out clk · 5ff851b7
      Uwe Kleine-König 提交于
      An error code returned by devm_clk_get() might have other meanings than
      "This clock doesn't exist". So use devm_clk_get_optional() and handle
      all remaining errors as fatal.
      Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5ff851b7
    • U
      net: fec: Do proper error checking for optional clks · 43252ed1
      Uwe Kleine-König 提交于
      An error code returned by devm_clk_get() might have other meanings than
      "This clock doesn't exist". So use devm_clk_get_optional() and handle
      all remaining errors as fatal.
      Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      43252ed1
  7. 19 5月, 2022 1 次提交
  8. 12 5月, 2022 3 次提交
    • V
      net: enetc: kill PHY-less mode for PFs · 0f84d403
      Vladimir Oltean 提交于
      Right now, a PHY-less port (no phy-mode, no fixed-link, no phy-handle)
      doesn't register with phylink, but calls netif_carrier_on() from
      enetc_start().
      
      This makes sense for a VF, but for a PF, this is braindead, because we
      never call enetc_mac_enable() so the MAC is left inoperational.
      Furthermore, commit 71b77a7a ("enetc: Migrate to PHYLINK and
      PCS_LYNX") put the nail in the coffin because it removed the initial
      netif_carrier_off() call done right after register_netdev().
      
      Without that call, netif_carrier_on() does not call
      linkwatch_fire_event(), so the operstate remains IF_OPER_UNKNOWN.
      
      Just deny the broken configuration by requiring that a phy-mode is
      present, and always register a PF with phylink.
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: NClaudiu Manoil <claudiu.manoil@nxp.com>
      Link: https://lore.kernel.org/r/20220511094200.558502-1-vladimir.oltean@nxp.comSigned-off-by: NPaolo Abeni <pabeni@redhat.com>
      0f84d403
    • P
      net: enetc: count the tc-taprio window drops · 285e8ded
      Po Liu 提交于
      The enetc scheduler for IEEE 802.1Qbv has 2 options (depending on
      PTGCR[TG_DROP_DISABLE]) when we attempt to send an oversized packet
      which will never fit in its allotted time slot for its traffic class:
      either block the entire port due to head-of-line blocking, or drop the
      packet and set a bit in the writeback format of the transmit buffer
      descriptor, allowing other packets to be sent.
      
      We obviously choose the second option in the driver, but we do not
      detect the drop condition, so from the perspective of the network stack,
      the packet is sent and no error counter is incremented.
      
      This change checks the writeback of the TX BD when tc-taprio is enabled,
      and increments a specific ethtool statistics counter and a generic
      "tx_dropped" counter in ndo_get_stats64.
      Signed-off-by: NPo Liu <Po.Liu@nxp.com>
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: NClaudiu Manoil <claudiu.manoil@nxp.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      285e8ded
    • V
      net: enetc: manage ENETC_F_QBV in priv->active_offloads only when enabled · 32bf8e1f
      Vladimir Oltean 提交于
      Future work in this driver would like to look at priv->active_offloads &
      ENETC_F_QBV to determine whether a tc-taprio qdisc offload was
      installed, but this does not produce the intended effect.
      
      All the other flags in priv->active_offloads are managed dynamically,
      except ENETC_F_QBV which is set statically based on the probed SI capability.
      
      This change makes priv->active_offloads & ENETC_F_QBV really track the
      presence of a tc-taprio schedule on the port.
      
      Some existing users, like the enetc_sched_speed_set() call from
      phylink_mac_link_up(), are best kept using the old logic: the tc-taprio
      offload does not re-trigger another link mode resolve, so the scheduler
      needs to be functional from the get go, as long as Qbv is supported at
      all on the port. So to preserve functionality there, look at the static
      station interface capability from pf->si->hw_features instead.
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: NClaudiu Manoil <claudiu.manoil@nxp.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      32bf8e1f
  9. 10 5月, 2022 1 次提交
  10. 08 5月, 2022 1 次提交
  11. 06 5月, 2022 3 次提交
  12. 29 4月, 2022 2 次提交
  13. 28 4月, 2022 1 次提交
  14. 11 4月, 2022 1 次提交
  15. 05 4月, 2022 1 次提交
  16. 26 3月, 2022 1 次提交
  17. 18 3月, 2022 2 次提交
  18. 14 3月, 2022 5 次提交
  19. 11 3月, 2022 1 次提交
  20. 28 2月, 2022 1 次提交
  21. 20 2月, 2022 2 次提交
    • R
      dpaa2-eth: Update SINGLE_STEP register access · c4680c97
      Radu Bulie 提交于
      DPAA2 MAC supports 1588 one step timestamping.
      If this option is enabled then for each transmitted PTP event packet,
      the 1588 SINGLE_STEP register is accessed to modify the following fields:
      
      -offset of the correction field inside the PTP packet
      -UDP checksum update bit,  in case the PTP event packet has
       UDP encapsulation
      
      These values can change any time, because there may be multiple
      PTP clients connected, that receive various 1588 frame types:
      - L2 only frame
      - UDP / Ipv4
      - UDP / Ipv6
      - other
      
      The current implementation uses dpni_set_single_step_cfg to update the
      SINLGE_STEP register.
      Using an MC command  on the Tx datapath for each transmitted 1588 message
      introduces high delays, leading to low throughput and consequently to a
      small number of supported PTP clients. Besides these, the nanosecond
      correction field from the PTP packet will contain the high delay from the
      driver which together with the originTimestamp will render timestamp
      values that are unacceptable in a GM clock implementation.
      
      This patch updates the Tx datapath for 1588 messages when single step
      timestamp is enabled and provides direct access to SINGLE_STEP register,
      eliminating the  overhead caused by the dpni_set_single_step_cfg
      MC command. MC version >= 10.32 implements this functionality.
      If the MC version does not have support for returning the
      single step register base address, the driver will use
      dpni_set_single_step_cfg command for updates operations.
      
      All the delay introduced by dpni_set_single_step_cfg
      function will be eliminated (if MC version has support for returning the
      base address of the single step register), improving the egress driver
      performance for PTP packets when single step timestamping is enabled.
      
      Before these changes the maximum throughput for 1588 messages with
      single step hardware timestamp enabled was around 2000pps.
      After the updates the throughput increased up to 32.82 Mbps / 46631.02 pps.
      Signed-off-by: NRadu Bulie <radu-andrei.bulie@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c4680c97
    • R
      dpaa2-eth: Update dpni_get_single_step_cfg command · 9572594e
      Radu Bulie 提交于
      dpni_get_single_step_cfg is an MC firmware command used for
      retrieving the contents of SINGLE_STEP 1588 register available
      in a DPMAC.
      
      This patch adds a new version of this command that returns as an extra
      argument the physical base address of the aforementioned register.
      The address will be used to directly modify the contents of the
      SINGLE_STEP register instead of invoking the MC command
      dpni_set_single_step_cgf. The former approach introduced huge delays on
      the TX datapath when one step PTP events were transmitted. This led to low
      throughput and high latencies observed in the PTP correction field.
      Signed-off-by: NRadu Bulie <radu-andrei.bulie@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9572594e
  22. 17 2月, 2022 1 次提交
  23. 15 2月, 2022 2 次提交