1. 06 Jul, 2024 26 commits
  2. 05 Jul, 2024 14 commits
    • Sebastian Andrzej Siewior's avatar
      tun: Assign missing bpf_net_context. · fecef4cd
      Sebastian Andrzej Siewior authored
      During the introduction of struct bpf_net_context handling for
      XDP-redirect, the tun driver has been missed.
      Jakub also pointed out that there is another call chain to
      do_xdp_generic() originating from netif_receive_skb() and drivers may
      use it outside from the NAPI context.
      
      Set the bpf_net_context before invoking BPF XDP program within the TUN
      driver. Set the bpf_net_context also in do_xdp_generic() if a xdp
      program is available.
      
      Reported-by: syzbot+0b5c75599f1d872bea6f@syzkaller.appspotmail.com
      Reported-by: syzbot+5ae46b237278e2369cac@syzkaller.appspotmail.com
      Reported-by: syzbot+c1e04a422bbc0f0f2921@syzkaller.appspotmail.com
      Fixes: 401cb7da ("net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.")
      Signed-off-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Link: https://patch.msgid.link/20240704144815.j8xQda5r@linutronix.deSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      fecef4cd
    • Daniel Golle's avatar
      net: ethernet: mediatek: Allow gaps in MAC allocation · 3b2aef99
      Daniel Golle authored
      Some devices with MediaTek SoCs don't use the first but only the second
      MAC in the chip. Especially with MT7981 which got a built-in 1GE PHY
      connected to the second MAC this is quite common.
      Make sure to reset and enable PSE also in those cases by skipping gaps
      using 'continue' instead of aborting the loop using 'break'.
      
      Fixes: dee4dd10 ("net: ethernet: mtk_eth_soc: ppe: add support for multiple PPEs")
      Suggested-by: default avatarElad Yifee <eladwf@gmail.com>
      Signed-off-by: default avatarDaniel Golle <daniel@makrotopia.org>
      Reviewed-by: default avatarPrzemek Kitszel <przemyslaw.kitszel@intel.com>
      Link: https://patch.msgid.link/379ae584cea112db60f4ada79c7e5ba4f3364a64.1719862038.git.daniel@makrotopia.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      3b2aef99
    • Florian Westphal's avatar
      openvswitch: prepare for stolen verdict coming from conntrack and nat engine · c7f79f26
      Florian Westphal authored
      At this time, conntrack either returns NF_ACCEPT or NF_DROP.
      To improve debuging it would be nice to be able to replace NF_DROP
      verdict with NF_DROP_REASON() helper,
      
      This helper releases the skb instantly (so drop_monitor can pinpoint
      precise location) and returns NF_STOLEN.
      
      Prepare call sites to deal with this before introducing such changes
      in conntrack and nat core.
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Reviewed-by: default avatarAaron Conole <aconole@redhat.om>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c7f79f26
    • David S. Miller's avatar
      Merge branch 'pcs-xpcs-mmap' into main · aba43bdf
      David S. Miller authored
      Serge Semin <fancer says:
      
      ====================
      net: pcs: xpcs: Add memory-mapped device support
      
      The main goal of this series is to extend the DW XPCS device support in
      the kernel. Particularly the patchset adds a support of the DW XPCS
      device with the MCI/APB3 IO interface registered as a platform device. In
      order to have them utilized by the DW XPCS core the fwnode-based DW XPCS
      descriptor creation procedure has been introduced. Finally the STMMAC
      driver has been altered to support the DW XPCS passed via the 'pcs-handle'
      property.
      
      Note the series has been significantly re-developed since v1. So I even
      had to change the subject. Anyway I've done my best to take all the noted
      into account.
      
      The series traditionally starts with a set of the preparation patches.
      First one just moves the generic DW XPCS IDs macros from the internal
      header file to the external one where some other IDs also reside. Second
      patch splits up the xpcs_create() method to a set of the coherent
      sub-functions for the sake of the further easier updates and to have it
      looking less complicated. The goal of the next three patches is to extend
      the DW XPCS ID management code by defining a new dw_xpcs_info structure
      with both PCS and PMA IDs.
      
      The next two patches provide the DW XPCS device DT-bindings and the
      respective platform-device driver for the memory-mapped DW XPCS devices.
      Besides the later patch makes use of the introduced dw_xpcs_info structure
      to pre-define the DW XPCS IDs based on the platform-device compatible
      string. Thus if there is no way to auto-identify the XPCS device
      capabilities it can be done based on the custom device IDs passed via the
      MDIO-device platform data.
      
      Final DW XPCS driver change is about adding a new method of the DW XPCS
      descriptor creation. The xpcs_create_fwnode() function has been introduced
      with the same semantics as a similar method recently added to the Lynx PCS
      driver. It's supposed to be called with the fwnode pointing to the DW XPCS
      device node, for which the XPCS descriptor will be created.
      
      The series is terminated with two STMMAC driver patches. The former one
      simplifies the DW XPCS descriptor registration procedure by dropping the
      MDIO-bus scanning and creating the descriptor for the particular device
      address. The later patch alters the STMMAC PCS setup method so one would
      support the DW XPCS specified via the "pcs-handle" property.
      
      That's it for now. Thanks for review in advance. Any tests are very
      welcome. After this series is merged in, I'll submit another one which
      adds the generic 10GBase-R and 10GBase-X interfaces support to the STMMAC
      and DW XPCS driver with the proper CSRs re-initialization, PMA
      initialization and reference clock selection as it's described in the
      Synopsys DW XPCS HW manual.
      
      Link: https://lore.kernel.org/netdev/20231205103559.9605-1-fancer.lancer@gmail.com
      Changelog v2:
      - Drop the patches:
        [PATCH net-next 01/16] net: pcs: xpcs: Drop sentinel entry from 2500basex ifaces list
        [PATCH net-next 02/16] net: pcs: xpcs: Drop redundant workqueue.h include directive
        [PATCH net-next 03/16] net: pcs: xpcs: Return EINVAL in the internal methods
        [PATCH net-next 04/16] net: pcs: xpcs: Explicitly return error on caps validation
        as ones have already been merged into the kernel repo:
      Link: https://lore.kernel.org/netdev/20240222175843.26919-1-fancer.lancer@gmail.com/
      - Drop the patches:
        [PATCH net-next 14/16] net: stmmac: Pass netdev to XPCS setup function
        [PATCH net-next 15/16] net: stmmac: Add dedicated XPCS cleanup method
        as ones have already been merged into the kernel repo:
      Link: https://lore.kernel.org/netdev/20240513-rzn1-gmac1-v7-0-6acf58b5440d@bootlin.com/
      - Drop the patch:
        [PATCH net-next 06/16] net: pcs: xpcs: Avoid creating dummy XPCS MDIO device
        [PATCH net-next 09/16] net: mdio: Add Synopsys DW XPCS management interface support
        [PATCH net-next 11/16] net: pcs: xpcs: Change xpcs_create_mdiodev() suffix to "byaddr"
        [PATCH net-next 13/16] net: stmmac: intel: Register generic MDIO device
        as no longer relevant.
      - Add new patches:
        [PATCH net-next v2 03/10] net: pcs: xpcs: Convert xpcs_id to dw_xpcs_desc
        [PATCH net-next v2 04/10] net: pcs: xpcs: Convert xpcs_compat to dw_xpcs_compat
        [PATCH net-next v2 05/10] net: pcs: xpcs: Introduce DW XPCS info structure
        [PATCH net-next v2 09/10] net: stmmac: Create DW XPCS device with particular address
      - Use the xpcs_create_fwnode() function name and semantics similar to the
        Lynx PCS driver.
      - Add kdoc describing the DW XPCS registration functions.
      - Convert the memory-mapped DW XPCS device driver to being the
        platform-device driver.
      - Convert the DW XPCS DT-bindings to defining both memory-mapped and MDIO
        devices.
      - Drop inline'es from the methods statically defined in *.c. (@Maxime)
      - Preserve the strict refcount-ing pattern. (@Russell)
      
      Link: https://lore.kernel.org/netdev/20240602143636.5839-1-fancer.lancer@gmail.com/
      Changelov v3:
      - Implement the ordered clocks constraint. (@Rob)
      - Convert xpcs_plat_pm_ops to being defined as static. (@Simon)
      - Add the "@interface" argument kdoc to the xpcs_create_mdiodev()
        function. (@Simon)
      - Fix the "@fwnode" argument name in the xpcs_create_fwnode() method kdoc.
        (@Simon)
      - Move the return value descriptions to the "Return:" section of the
        xpcs_create_mdiodev() and xpcs_create_fwnode() kdoc. (@Simon)
      - Drop stmmac_mdio_bus_data::has_xpcs flag and define the PCS-address
        mask with particular XPCS address instead.
      
      Link: https://lore.kernel.org/netdev/20240627004142.8106-1-fancer.lancer@gmail.com/
      Changelog v4:
      - Make sure the series is applicable to the net-next tree. (@Vladimir)
      - Rename entry to desc in the xpcs_init_id() method. (@Andrew)
      - Add a comment to the clock-names property constraint about the
        oneOf-subschemas applicability. (@Conor)
      - Convert "pclk" clock name to "csr" to match the DW XPCS IP-core
        input signal name. (@Rob)
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      aba43bdf
    • Serge Semin's avatar
      net: stmmac: Add DW XPCS specified via "pcs-handle" support · 357768c7
      Serge Semin authored
      Recently the DW XPCS DT-bindings have been introduced and the DW XPCS
      driver has been altered to support the DW XPCS registered as a platform
      device. In order to have the DW XPCS DT-device accessed from the STMMAC
      driver let's alter the STMMAC PCS-setup procedure to support the
      "pcs-handle" property containing the phandle reference to the DW XPCS
      device DT-node. The respective fwnode will be then passed to the
      xpcs_create_fwnode() function which in its turn will create the DW XPCS
      descriptor utilized in the main driver for the PCS-related setups.
      Signed-off-by: default avatarSerge Semin <fancer.lancer@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      357768c7
    • Serge Semin's avatar
      net: stmmac: Create DW XPCS device with particular address · 351066ba
      Serge Semin authored
      Currently the only STMMAC platform driver using the DW XPCS code is the
      Intel mGBE device driver. (It can be determined by finding all the drivers
      having the stmmac_mdio_bus_data::has_xpcs flag set.) At the same time the
      low-level platform driver masks out the DW XPCS MDIO-address from being
      auto-detected as PHY by the MDIO subsystem core. Seeing the PCS MDIO ID is
      known the procedure of the DW XPCS device creation can be simplified by
      dropping the loop over all the MDIO IDs. From now the DW XPCS device
      descriptor will be created for the MDIO-bus address pre-defined by the
      platform drivers via the stmmac_mdio_bus_data::pcs_mask field.
      
      Note besides this shall speed up a bit the Intel mGBE probing.
      Signed-off-by: default avatarSerge Semin <fancer.lancer@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      351066ba
    • Serge Semin's avatar
      net: pcs: xpcs: Add fwnode-based descriptor creation method · 9cad7275
      Serge Semin authored
      It's now possible to have the DW XPCS device defined as a standard
      platform device for instance in the platform DT-file. Although that
      functionality is useless unless there is a way to have the device found by
      the client drivers (STMMAC/DW *MAC, NXP SJA1105 Eth Switch, etc). Provide
      such ability by means of the xpcs_create_fwnode() method. It needs to be
      called with the device DW XPCS fwnode instance passed. That node will be
      then used to find the MDIO-device instance in order to create the DW XPCS
      descriptor.
      
      Note the method semantics and name is similar to what has been recently
      introduced in the Lynx PCS driver.
      Signed-off-by: default avatarSerge Semin <fancer.lancer@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9cad7275
    • Serge Semin's avatar
      net: pcs: xpcs: Add Synopsys DW xPCS platform device driver · f6bb3e9d
      Serge Semin authored
      Synopsys DesignWare XPCS IP-core can be synthesized with the device CSRs
      being accessible over the MCI or APB3 interface instead of the MDIO bus
      (see the CSR_INTERFACE HDL parameter). Thus all the PCS registers can be
      just memory mapped and be a subject of the standard MMIO operations of
      course taking into account the peculiarities of the Clause C45 CSRs
      mapping. From that perspective the DW XPCS devices would look as just
      normal platform devices for the kernel.
      
      On the other hand in order to have the DW XPCS devices handled by the
      pcs-xpcs.c driver they need to be registered in the framework of the
      MDIO-subsystem. So the suggested change is about providing a DW XPCS
      platform device driver registering a virtual MDIO-bus with a single
      MDIO-device representing the DW XPCS device.
      
      DW XPCS platform device is supposed to be described by the respective
      compatible string "snps,dw-xpcs" (or with the PMA-specific compatible
      string), CSRs memory space and optional peripheral bus and reference clock
      sources. Depending on the INDIRECT_ACCESS IP-core synthesize parameter the
      memory-mapped reg-space can be represented as either directly or
      indirectly mapped Clause 45 space. In the former case the particular
      address is determined based on the MMD device and the registers offset (5
      + 16 bits all together) within the device reg-space. In the later case
      there is only 8 lower address bits are utilized for the registers mapping
      (255 CSRs). The upper bits are supposed to be written into the respective
      viewport CSR in order to select the respective MMD sub-page.
      
      Note, only the peripheral bus clock source is requested in the platform
      device probe procedure. The core and pad clocks handling has been
      implemented in the framework of the xpcs_create() method intentionally
      since the clocks-related setups are supposed to be performed later, during
      the DW XPCS main configuration procedures. (For instance they will be
      required for the DW Gen5 10G PMA configuration.)
      Signed-off-by: default avatarSerge Semin <fancer.lancer@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f6bb3e9d
    • Serge Semin's avatar
      dt-bindings: net: Add Synopsys DW xPCS bindings · 664690eb
      Serge Semin authored
      Synopsys DesignWare XPCS IP-core is a Physical Coding Sublayer (PCS) layer
      providing an interface between the Media Access Control (MAC) and Physical
      Medium Attachment Sublayer (PMA) through a Media independent interface.
      From software point of view it exposes IEEE std. Clause 45 CSR space and
      can be accessible either by MDIO or MCI/APB3 bus interfaces. In the former
      case the PCS device is supposed to be defined under the respective MDIO
      bus DT-node. In the later case the DW xPCS will be just a normal IO
      memory-mapped device.
      
      Besides of that DW XPCS DT-nodes can have an interrupt signal and clock
      source properties specified. The former one indicates the Clause 73/37
      auto-negotiation events like: negotiation page received, AN is completed
      or incompatible link partner. The clock DT-properties can describe up to
      three clock sources: peripheral bus clock source, internal reference clock
      and the externally connected reference clock.
      
      Finally the DW XPCS IP-core can be optionally synthesized with a
      vendor-specific interface connected to the Synopsys PMA (also called
      DesignWare Consumer/Enterprise PHY). Alas that isn't auto-detectable in a
      portable way. So if the DW XPCS device has the respective PMA attached
      then it should be reflected in the DT-node compatible string so the driver
      would be aware of the PMA-specific device capabilities (mainly connected
      with CSRs available for the fine-tunings).
      Signed-off-by: default avatarSerge Semin <fancer.lancer@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      664690eb
    • Serge Semin's avatar
      net: pcs: xpcs: Introduce DW XPCS info structure · bcac735c
      Serge Semin authored
      The being introduced structure will preserve the PCS and PMA IDs retrieved
      from the respective DW XPCS MMDs or potentially pre-defined by the client
      drivers. (The later change will be introduced later in the framework of
      the commit adding the memory-mapped DW XPCS devices support.)
      
      The structure fields are filled in in the xpcs_get_id() function, which
      used to be responsible for the PCS Device ID getting only. Besides of the
      PCS ID the method now fetches the PMA/PMD IDs too from MMD 1, which used
      to be done in xpcs_dev_flag(). The retrieved PMA ID will be from now
      utilized for the PMA-specific tweaks like it was introduced for the
      Wangxun TxGBE PCS in the commit f629acc6 ("net: pcs: xpcs: support to
      switch mode for Wangxun NICs").
      
      Note 1. The xpcs_get_id() error-handling semantics has been changed. From
      now the error number will be returned from the function. There is no point
      in the next IOs or saving 0xffs and then looping over the actual device
      IDs if device couldn't be reached. -ENODEV will be returned if the very
      first IO operation failed thus indicating that no device could be found.
      
      Note 2. The PCS and PMA IDs macros have been converted to enum'es. The
      enum'es will be populated later in another commit with the virtual IDs
      identifying the DW XPCS devices which have some platform-specifics, but
      have been synthesized with the default PCS/PMA ID.
      Signed-off-by: default avatarSerge Semin <fancer.lancer@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bcac735c
    • Serge Semin's avatar
      net: pcs: xpcs: Convert xpcs_compat to dw_xpcs_compat · 410232ab
      Serge Semin authored
      The xpcs_compat structure has been left as the only dw-prefix-less
      structure since the previous commit. Let's unify at least the structures
      naming in the driver by adding the dw_-prefix to it.
      Signed-off-by: default avatarSerge Semin <fancer.lancer@gmail.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      410232ab
    • Serge Semin's avatar
      net: pcs: xpcs: Convert xpcs_id to dw_xpcs_desc · 71b200b3
      Serge Semin authored
      A structure with the PCS/PMA MMD IDs data is being introduced in one of
      the next commits. In order to prevent the names ambiguity let's convert
      the xpcs_id structure name to dw_xpcs_desc. The later version is more
      suitable since the structure content is indeed the device descriptor
      containing the data and callbacks required for the driver to correctly set
      the device up.
      Signed-off-by: default avatarSerge Semin <fancer.lancer@gmail.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      71b200b3
    • Serge Semin's avatar
      net: pcs: xpcs: Split up xpcs_create() body to sub-functions · 03b3be07
      Serge Semin authored
      As an initial preparation before adding the fwnode-based DW XPCS device
      support let's split the xpcs_create() function code up to a set of the
      small sub-functions. Thus the xpcs_create() implementation will get to
      look simpler and turn to be more coherent. Further updates will just touch
      the new sub-functions a bit: add platform-specific device info, add the
      reference clock getting and enabling.
      
      The xpcs_create() method will now contain the next static methods calls:
      
      xpcs_create_data() - create the DW XPCS device descriptor, pre-initialize
      it' fields and increase the mdio device refcount-er;
      
      xpcs_init_id() - find XPCS ID instance and save it in the device
      descriptor;
      
      xpcs_init_iface() - find MAC/PCS interface descriptor and perform
      basic initialization specific to it: soft-reset, disable polling.
      
      The update doesn't imply any semantic change but merely makes the code
      looking simpler and more ready for adding new features support.
      
      Note the xpcs_destroy() has been moved to being defined below the
      xpcs_create_mdiodev() function as the driver now implies having the
      protagonist-then-antagonist functions definition order.
      Signed-off-by: default avatarSerge Semin <fancer.lancer@gmail.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      03b3be07
    • Serge Semin's avatar
      net: pcs: xpcs: Move native device ID macro to linux/pcs/pcs-xpcs.h · f37bee95
      Serge Semin authored
      One of the next commits will alter the DW XPCS driver to support setting a
      custom device ID for the particular MDIO-device detected on the platform.
      The generic DW XPCS ID can be used as a custom ID as well in case if the
      DW XPCS-device was erroneously synthesized with no or some undefined ID.
      In addition to that having all supported DW XPCS device IDs defined in a
      single place will improve the code maintainability and readability.
      
      Note while at it rename the macros to being shorter and looking alike to
      the already defined NXP XPCS ID macro.
      Signed-off-by: default avatarSerge Semin <fancer.lancer@gmail.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f37bee95