Re: [Intel-wired-lan] [PATCH iwl-next v1 1/3] pldmfw: selected component update

[Pucha, HimasekharX Reddy]

> -Original Message-
> From: Intel-wired-lan  On Behalf Of 
> Konrad Knitter
> Sent: 23 October 2024 15:37
> To: intel-wired-...@lists.osuosl.org
> Cc: Keller, Jacob E ; net...@vger.kernel.org; 
> j...@resnulli.us; da...@davemloft.net; eduma...@google.com; k...@kernel.org; 
> pab...@redhat.com; linux-ker...@vger.kernel.org; Nguyen, Anthony L 
> ; Kitszel, Przemyslaw 
> ; Knitter, Konrad ; 
> Marcin Szycik 
> Subject: [Intel-wired-lan] [PATCH iwl-next v1 1/3] pldmfw: selected component 
> update
>
> Enable update of a selected component.
>
> Reviewed-by: Marcin Szycik 
> Reviewed-by: Przemek Kitszel 
> Signed-off-by: Konrad Knitter 
> ---
>  include/linux/pldmfw.h | 8 
>  lib/pldmfw/pldmfw.c| 8 
>  2 files changed, 16 insertions(+)
>

Tested-by: Pucha Himasekhar Reddy  (A 
Contingent worker at Intel)

[Intel-wired-lan] [PATCH v4 iwl-net 1/4] ice: Fix E825 initialization

[Grzegorz Nitka]

From: Karol Kolacinski 

Current implementation checks revision of all PHYs on all PFs, which is
incorrect and may result in initialization failure. Check only the
revision of the current PHY.

Fixes: 7cab44f1c35f ("ice: Introduce ETH56G PHY model for E825C products")
Reviewed-by: Arkadiusz Kubalewski 
Signed-off-by: Karol Kolacinski 
Signed-off-by: Grzegorz Nitka 
---
V1 -> V3: Removed net-next hunks,
  add 'return' on PHY revision read failure
V1 -> V2: Removed net-next hunks

 drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 22 +
 1 file changed, 9 insertions(+), 13 deletions(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_ptp_hw.c 
b/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
index ec8db830ac73..d27b2f52b5ce 100644
--- a/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
+++ b/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
@@ -2663,14 +2663,15 @@ static bool ice_is_muxed_topo(struct ice_hw *hw)
 }
 
 /**
- * ice_ptp_init_phy_e825c - initialize PHY parameters
+ * ice_ptp_init_phy_e825 - initialize PHY parameters
  * @hw: pointer to the HW struct
  */
-static void ice_ptp_init_phy_e825c(struct ice_hw *hw)
+static void ice_ptp_init_phy_e825(struct ice_hw *hw)
 {
struct ice_ptp_hw *ptp = &hw->ptp;
struct ice_eth56g_params *params;
-   u8 phy;
+   u32 phy_rev;
+   int err;
 
ptp->phy_model = ICE_PHY_ETH56G;
params = &ptp->phy.eth56g;
@@ -2684,15 +2685,10 @@ static void ice_ptp_init_phy_e825c(struct ice_hw *hw)
ptp->num_lports = params->num_phys * ptp->ports_per_phy;
 
ice_sb_access_ena_eth56g(hw, true);
-   for (phy = 0; phy < params->num_phys; phy++) {
-   u32 phy_rev;
-   int err;
-
-   err = ice_read_phy_eth56g(hw, phy, PHY_REG_REVISION, &phy_rev);
-   if (err || phy_rev != PHY_REVISION_ETH56G) {
-   ptp->phy_model = ICE_PHY_UNSUP;
-   return;
-   }
+   err = ice_read_phy_eth56g(hw, hw->pf_id, PHY_REG_REVISION, &phy_rev);
+   if (err || phy_rev != PHY_REVISION_ETH56G) {
+   ptp->phy_model = ICE_PHY_UNSUP;
+   return;
}
 
ptp->is_2x50g_muxed_topo = ice_is_muxed_topo(hw);
@@ -5394,7 +5390,7 @@ void ice_ptp_init_hw(struct ice_hw *hw)
else if (ice_is_e810(hw))
ice_ptp_init_phy_e810(ptp);
else if (ice_is_e825c(hw))
-   ice_ptp_init_phy_e825c(hw);
+   ice_ptp_init_phy_e825(hw);
else
ptp->phy_model = ICE_PHY_UNSUP;
 }
-- 
2.39.3

[Intel-wired-lan] [PATCH v4 iwl-net 0/4] Fix E825 initialization

[Grzegorz Nitka]

E825 products have incorrect initialization procedure, which may lead to
initialization failures and register values.

Fix E825 products initialization by adding correct sync delay, checking
the PHY revision only for current PHY and adding proper destination
device when reading port/quad.

In addition, E825 uses PF ID for indexing per PF registers and as
a primary PHY lane number, which is incorrect.

Karol Kolacinski (4):
  ice: Fix E825 initialization
  ice: Fix quad registers read on E825
  ice: Fix ETH56G FC-FEC Rx offset value
  ice: Add correct PHY lane assignment

 .../net/ethernet/intel/ice/ice_adminq_cmd.h   |   1 +
 drivers/net/ethernet/intel/ice/ice_common.c   |  45 +++
 drivers/net/ethernet/intel/ice/ice_common.h   |   1 +
 drivers/net/ethernet/intel/ice/ice_main.c |   6 +-
 drivers/net/ethernet/intel/ice/ice_ptp.c  |  23 +-
 drivers/net/ethernet/intel/ice/ice_ptp.h  |   4 +-
 .../net/ethernet/intel/ice/ice_ptp_consts.h   |   2 +-
 drivers/net/ethernet/intel/ice/ice_ptp_hw.c   | 270 ++
 drivers/net/ethernet/intel/ice/ice_type.h |   2 -
 9 files changed, 207 insertions(+), 147 deletions(-)

V3 -> V4: Removed not-related clean-up code
V2 -> V3: Removed net-next hunks from "ice: Fix E825 initialization",
  replaced lower/upper_32_bits calls with lower/upper_16_bits
  in "ice: Fix quad registers read on E825",
  improved ice_get_phy_lane_number function in "ice: Add correct
  PHY lane assignment"
V1 -> V2: Removed net-next hunks from "ice: Fix E825 initialization",
  whole "ice: Remove unnecessary offset calculation for PF
  scoped registers" patch and fixed kdoc in "ice: Fix quad
  registers read on E825"

base-commit: 278dfaa171a0061a341f6b5d44c2c9913a2b7fa8
-- 
2.39.3

[Intel-wired-lan] [PATCH v4 iwl-net 2/4] ice: Fix quad registers read on E825

[Grzegorz Nitka]

From: Karol Kolacinski 

Quad registers are read/written incorrectly. E825 devices always use
quad 0 address and differentiate between the PHYs by changing SBQ
destination device (phy_0 or phy_0_peer).

Add helpers for reading/writing PTP registers shared per quad and use
correct quad address and SBQ destination device based on port.

Fixes: 7cab44f1c35f ("ice: Introduce ETH56G PHY model for E825C products")
Reviewed-by: Arkadiusz Kubalewski 
Signed-off-by: Karol Kolacinski 
Signed-off-by: Grzegorz Nitka 
---
V3 -> V4: Removed unrelated refactor/cleanup code
V2 -> V3: Replaced lower/upper_32_bits calls with lower/upper_16_bits
V1 -> V2: Fixed kdoc issues

 drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 226 
 drivers/net/ethernet/intel/ice/ice_type.h   |   1 -
 2 files changed, 137 insertions(+), 90 deletions(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_ptp_hw.c 
b/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
index d27b2f52b5ce..836e7718dda3 100644
--- a/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
+++ b/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
@@ -877,31 +877,46 @@ static void ice_ptp_exec_tmr_cmd(struct ice_hw *hw)
  * The following functions operate on devices with the ETH 56G PHY.
  */
 
+/**
+ * ice_ptp_get_dest_dev_e825 - get destination PHY for given port number
+ * @hw: pointer to the HW struct
+ * @port: destination port
+ *
+ * Return: destination sideband queue PHY device.
+ */
+static enum ice_sbq_msg_dev ice_ptp_get_dest_dev_e825(struct ice_hw *hw,
+ u8 port)
+{
+   /* On a single complex E825, PHY 0 is always destination device phy_0
+* and PHY 1 is phy_0_peer.
+*/
+   if (port >= hw->ptp.ports_per_phy)
+   return eth56g_phy_1;
+   else
+   return eth56g_phy_0;
+}
+
 /**
  * ice_write_phy_eth56g - Write a PHY port register
  * @hw: pointer to the HW struct
- * @phy_idx: PHY index
+ * @port: destination port
  * @addr: PHY register address
  * @val: Value to write
  *
- * Return: 0 on success, other error codes when failed to write to PHY
+ * Return: 0 on success, other error codes when failed to write to PHY.
  */
-static int ice_write_phy_eth56g(struct ice_hw *hw, u8 phy_idx, u32 addr,
-   u32 val)
+static int ice_write_phy_eth56g(struct ice_hw *hw, u8 port, u32 addr, u32 val)
 {
-   struct ice_sbq_msg_input phy_msg;
+   struct ice_sbq_msg_input msg = {
+   .dest_dev = ice_ptp_get_dest_dev_e825(hw, port),
+   .opcode = ice_sbq_msg_wr,
+   .msg_addr_low = lower_16_bits(addr),
+   .msg_addr_high = upper_16_bits(addr),
+   .data = val
+   };
int err;
 
-   phy_msg.opcode = ice_sbq_msg_wr;
-
-   phy_msg.msg_addr_low = lower_16_bits(addr);
-   phy_msg.msg_addr_high = upper_16_bits(addr);
-
-   phy_msg.data = val;
-   phy_msg.dest_dev = hw->ptp.phy.eth56g.phy_addr[phy_idx];
-
-   err = ice_sbq_rw_reg(hw, &phy_msg, ICE_AQ_FLAG_RD);
-
+   err = ice_sbq_rw_reg(hw, &msg, ICE_AQ_FLAG_RD);
if (err)
ice_debug(hw, ICE_DBG_PTP, "PTP failed to send msg to phy %d\n",
  err);
@@ -912,41 +927,36 @@ static int ice_write_phy_eth56g(struct ice_hw *hw, u8 
phy_idx, u32 addr,
 /**
  * ice_read_phy_eth56g - Read a PHY port register
  * @hw: pointer to the HW struct
- * @phy_idx: PHY index
+ * @port: destination port
  * @addr: PHY register address
  * @val: Value to write
  *
- * Return: 0 on success, other error codes when failed to read from PHY
+ * Return: 0 on success, other error codes when failed to read from PHY.
  */
-static int ice_read_phy_eth56g(struct ice_hw *hw, u8 phy_idx, u32 addr,
-  u32 *val)
+static int ice_read_phy_eth56g(struct ice_hw *hw, u8 port, u32 addr, u32 *val)
 {
-   struct ice_sbq_msg_input phy_msg;
+   struct ice_sbq_msg_input msg = {
+   .dest_dev = ice_ptp_get_dest_dev_e825(hw, port),
+   .opcode = ice_sbq_msg_rd,
+   .msg_addr_low = lower_16_bits(addr),
+   .msg_addr_high = upper_16_bits(addr)
+   };
int err;
 
-   phy_msg.opcode = ice_sbq_msg_rd;
-
-   phy_msg.msg_addr_low = lower_16_bits(addr);
-   phy_msg.msg_addr_high = upper_16_bits(addr);
-
-   phy_msg.data = 0;
-   phy_msg.dest_dev = hw->ptp.phy.eth56g.phy_addr[phy_idx];
-
-   err = ice_sbq_rw_reg(hw, &phy_msg, ICE_AQ_FLAG_RD);
-   if (err) {
+   err = ice_sbq_rw_reg(hw, &msg, ICE_AQ_FLAG_RD);
+   if (err)
ice_debug(hw, ICE_DBG_PTP, "PTP failed to send msg to phy %d\n",
  err);
-   return err;
-   }
-
-   *val = phy_msg.data;
+   else
+   *val = msg.data;
 
-   return 0;
+   return err;
 }
 
 /**
  * ice_phy_res_address_eth56g - Calculate a PHY port register address
- * @port: Port number to be written
+ * 

[Intel-wired-lan] [PATCH v4 iwl-net 3/4] ice: Fix ETH56G FC-FEC Rx offset value

[Grzegorz Nitka]

From: Karol Kolacinski 

Fix ETH56G FC-FEC incorrect Rx offset value by changing it from -255.96
to -469.26 ns.

Those values are derived from HW spec and reflect internal delays.
Hex value is a fixed point representation in Q23.9 format.

Fixes: 7cab44f1c35f ("ice: Introduce ETH56G PHY model for E825C products")
Reviewed-by: Arkadiusz Kubalewski 
Signed-off-by: Karol Kolacinski 
---
 drivers/net/ethernet/intel/ice/ice_ptp_consts.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_ptp_consts.h 
b/drivers/net/ethernet/intel/ice/ice_ptp_consts.h
index e6980b94a6c1..6620642077bb 100644
--- a/drivers/net/ethernet/intel/ice/ice_ptp_consts.h
+++ b/drivers/net/ethernet/intel/ice/ice_ptp_consts.h
@@ -131,7 +131,7 @@ struct ice_eth56g_mac_reg_cfg 
eth56g_mac_cfg[NUM_ICE_ETH56G_LNK_SPD] = {
.rx_offset = {
.serdes = 0xeb27, /* -10.42424 */
.no_fec = 0xcccd, /* -25.6 */
-   .fc = 0xfffe0014, /* -255.96 */
+   .fc = 0xfffc557b, /* -469.26 */
.sfd = 0x4a4, /* 2.32 */
.bs_ds = 0x32 /* 0.0969697 */
}
-- 
2.39.3

[Intel-wired-lan] [PATCH v4 iwl-net 4/4] ice: Add correct PHY lane assignment

[Grzegorz Nitka]

From: Karol Kolacinski 

Driver always naively assumes, that for PTP purposes, PHY lane to
configure is corresponding to PF ID.

This is not true for some port configurations, e.g.:
- 2x50G per quad, where lanes used are 0 and 2 on each quad, but PF IDs
  are 0 and 1
- 100G per quad on 2 quads, where lanes used are 0 and 4, but PF IDs are
  0 and 1

Use correct PHY lane assignment by getting and parsing port options.
This is read from the NVM by the FW and provided to the driver with
the indication of active port split.

Remove ice_is_muxed_topo(), which is no longer needed.

Fixes: 4409ea1726cb ("ice: Adjust PTP init for 2x50G E825C devices")
Reviewed-by: Przemek Kitszel 
Reviewed-by: Arkadiusz Kubalewski 
Signed-off-by: Karol Kolacinski 
Signed-off-by: Grzegorz Nitka 
---
V1 -> V3: Added checker for speed value in returned AQ Get Options

 .../net/ethernet/intel/ice/ice_adminq_cmd.h   |  1 +
 drivers/net/ethernet/intel/ice/ice_common.c   | 45 +++
 drivers/net/ethernet/intel/ice/ice_common.h   |  1 +
 drivers/net/ethernet/intel/ice/ice_main.c |  6 +--
 drivers/net/ethernet/intel/ice/ice_ptp.c  | 23 --
 drivers/net/ethernet/intel/ice/ice_ptp.h  |  4 +-
 drivers/net/ethernet/intel/ice/ice_ptp_hw.c   | 26 +--
 drivers/net/ethernet/intel/ice/ice_type.h |  1 -
 8 files changed, 62 insertions(+), 45 deletions(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h 
b/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h
index 0be1a98d7cc1..547c96b9c1d5 100644
--- a/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h
+++ b/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h
@@ -1648,6 +1648,7 @@ struct ice_aqc_get_port_options_elem {
 #define ICE_AQC_PORT_OPT_MAX_LANE_25G  5
 #define ICE_AQC_PORT_OPT_MAX_LANE_50G  6
 #define ICE_AQC_PORT_OPT_MAX_LANE_100G 7
+#define ICE_AQC_PORT_OPT_MAX_LANE_200G 8
 
u8 global_scid[2];
u8 phy_scid[2];
diff --git a/drivers/net/ethernet/intel/ice/ice_common.c 
b/drivers/net/ethernet/intel/ice/ice_common.c
index f1324e25b2af..deda8da59017 100644
--- a/drivers/net/ethernet/intel/ice/ice_common.c
+++ b/drivers/net/ethernet/intel/ice/ice_common.c
@@ -4074,6 +4074,51 @@ ice_aq_set_port_option(struct ice_hw *hw, u8 lport, u8 
lport_valid,
return ice_aq_send_cmd(hw, &desc, NULL, 0, NULL);
 }
 
+/**
+ * ice_get_phy_lane_number - Get PHY lane number for current adapter
+ * @hw: pointer to the hw struct
+ *
+ * Return: PHY lane number on success, negative error code otherwise.
+ */
+int ice_get_phy_lane_number(struct ice_hw *hw)
+{
+   struct ice_aqc_get_port_options_elem *options __free(kfree);
+   unsigned int lport = 0;
+   unsigned int lane;
+   int err;
+
+   options = kcalloc(ICE_AQC_PORT_OPT_MAX, sizeof(*options), GFP_KERNEL);
+   if (!options)
+   return -ENOMEM;
+
+   for (lane = 0; lane < ICE_MAX_PORT_PER_PCI_DEV; lane++) {
+   u8 options_count = ICE_AQC_PORT_OPT_MAX;
+   u8 speed, active_idx, pending_idx;
+   bool active_valid, pending_valid;
+
+   err = ice_aq_get_port_options(hw, options, &options_count, lane,
+ true, &active_idx, &active_valid,
+ &pending_idx, &pending_valid);
+   if (err)
+   return err;
+
+   if (!active_valid)
+   continue;
+
+   speed = options[active_idx].max_lane_speed;
+   /* If we don't get speed for this lane, it's unoccupied */
+   if (speed > ICE_AQC_PORT_OPT_MAX_LANE_200G)
+   continue;
+
+   if (hw->pf_id == lport)
+   return lane;
+   lport++;
+   }
+
+   /* PHY lane not found */
+   return -ENXIO;
+}
+
 /**
  * ice_aq_sff_eeprom
  * @hw: pointer to the HW struct
diff --git a/drivers/net/ethernet/intel/ice/ice_common.h 
b/drivers/net/ethernet/intel/ice/ice_common.h
index 27208a60cece..fe6f88cfd948 100644
--- a/drivers/net/ethernet/intel/ice/ice_common.h
+++ b/drivers/net/ethernet/intel/ice/ice_common.h
@@ -193,6 +193,7 @@ ice_aq_get_port_options(struct ice_hw *hw,
 int
 ice_aq_set_port_option(struct ice_hw *hw, u8 lport, u8 lport_valid,
   u8 new_option);
+int ice_get_phy_lane_number(struct ice_hw *hw);
 int
 ice_aq_sff_eeprom(struct ice_hw *hw, u16 lport, u8 bus_addr,
  u16 mem_addr, u8 page, u8 set_page, u8 *data, u8 length,
diff --git a/drivers/net/ethernet/intel/ice/ice_main.c 
b/drivers/net/ethernet/intel/ice/ice_main.c
index b1e7727b8677..72ef1b15b100 100644
--- a/drivers/net/ethernet/intel/ice/ice_main.c
+++ b/drivers/net/ethernet/intel/ice/ice_main.c
@@ -1144,7 +1144,7 @@ ice_link_event(struct ice_pf *pf, struct ice_port_info 
*pi, bool link_up,
if (link_up == old_link && link_speed == old_link_speed)
return 0;
 
-   ice_ptp_link_change(pf, pf->hw.pf_id, link_up);

Re: [Intel-wired-lan] [PATCH iwl-next v1 3/3] ice: support FW Recovery Mode

[Pucha, HimasekharX Reddy]

> -Original Message-
> From: Intel-wired-lan  On Behalf Of 
> Konrad Knitter
> Sent: 23 October 2024 15:37
> To: intel-wired-...@lists.osuosl.org
> Cc: Keller, Jacob E ; net...@vger.kernel.org; 
> j...@resnulli.us; da...@davemloft.net; eduma...@google.com; k...@kernel.org; 
> pab...@redhat.com; linux-ker...@vger.kernel.org; Nguyen, Anthony L 
> ; Kitszel, Przemyslaw 
> ; Knitter, Konrad 
> Subject: [Intel-wired-lan] [PATCH iwl-next v1 3/3] ice: support FW Recovery 
> Mode
>
> Recovery Mode is intended to recover from a fatal failure scenario in which 
> the device is not accessible to the host, meaning the firmware is 
> non-responsive.
>
> The purpose of the Firmware Recovery Mode is to enable software tools to 
> update firmware and/or device configuration so the fatal error can be 
> resolved.
>
> Recovery Mode Firmware supports a limited set of admin commands required for 
> NVM update.
> Recovery Firmware does not support hardware interrupts so a polling mode is 
> used.
>
> The driver will expose only the minimum set of devlink commands required for 
> the recovery of the adapter.
>
> Using an appropriate NVM image, the user can recover the adapter using the 
> devlink flash API.
>
> Prior to 4.20 E810 Adapter Recovery Firmware supports only the update and 
> erase of the "fw.mgmt" component.
>
> E810 Adapter Recovery Firmware doesn't support selected preservation of cards 
> settings or identifiers.
>
> The following command can be used to recover the adapter:
>
> $ devlink dev flash   component fw.mgmt
>   overwrite settings overwrite identifier
>
> Newer FW versions (4.20 or newer) supports update of "fw.undi" and 
> "fw.netlist" components.
>
> $ devlink dev flash  
>
> Tested on Intel Corporation Ethernet Controller E810-C for SFP FW revision 
> 3.20 and 4.30.
>
> Reviewed-by: Przemek Kitszel 
> Signed-off-by: Konrad Knitter 
> ---
>  .../net/ethernet/intel/ice/devlink/devlink.c  |  8 ++-
>  .../net/ethernet/intel/ice/ice_adminq_cmd.h   |  1 +
>  .../net/ethernet/intel/ice/ice_fw_update.c| 14 -
>  drivers/net/ethernet/intel/ice/ice_lib.c  |  6 +++
>  drivers/net/ethernet/intel/ice/ice_lib.h  |  1 +
>  drivers/net/ethernet/intel/ice/ice_main.c | 53 +++
>  6 files changed, 80 insertions(+), 3 deletions(-)
>

Tested-by: Pucha Himasekhar Reddy  (A 
Contingent worker at Intel)

Re: [Intel-wired-lan] [PATCH iwl-next v1 2/3] devlink: add devl guard

[Pucha, HimasekharX Reddy]

> -Original Message-
> From: Intel-wired-lan  On Behalf Of 
> Konrad Knitter
> Sent: 23 October 2024 15:37
> To: intel-wired-...@lists.osuosl.org
> Cc: Keller, Jacob E ; net...@vger.kernel.org; 
> j...@resnulli.us; da...@davemloft.net; eduma...@google.com; k...@kernel.org; 
> pab...@redhat.com; linux-ker...@vger.kernel.org; Nguyen, Anthony L 
> ; Kitszel, Przemyslaw 
> ; Knitter, Konrad 
> Subject: [Intel-wired-lan] [PATCH iwl-next v1 2/3] devlink: add devl guard
>
> Add devl guard for scoped_guard().
>
> Example usage:
>
> scoped_guard(devl, priv_to_devlink(pf)) {
> err = init_devlink(pf);
>   if (err)
>   return err;
> }
>
> Co-developed-by: Przemek Kitszel 
> Signed-off-by: Przemek Kitszel 
> Signed-off-by: Konrad Knitter 
> ---
>  include/net/devlink.h | 1 +
>  1 file changed, 1 insertion(+)
>

Tested-by: Pucha Himasekhar Reddy  (A 
Contingent worker at Intel)

[Intel-wired-lan] [tnguy-next-queue:dev-queue] BUILD REGRESSION 676d779106de51fc4e2685ca8de610ee5a70d35f

[kernel test robot]

tree/branch: 
https://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue.git dev-queue
branch HEAD: 676d779106de51fc4e2685ca8de610ee5a70d35f  igc: Link queues to NAPI 
instances

Error/Warning (recently discovered and may have been fixed):

https://lore.kernel.org/oe-kbuild-all/202411050805.cfj4obqq-...@intel.com
https://lore.kernel.org/oe-kbuild-all/202411051123.n3qti2f2-...@intel.com
https://lore.kernel.org/oe-kbuild-all/202411051410.qebcuz5y-...@intel.com

drivers/net/ethernet/intel/iavf/iavf_txrx.c::(.text+0x185c): undefined 
reference to `iavf_ptp_extend_32b_timestamp'
drivers/net/ethernet/intel/iavf/iavf_virtchnl.c:2618:(.text+0x4634): 
undefined reference to `iavf_ptp_process_caps'
drivers/net/ethernet/intel/iavf/iavf_virtchnl.c:381:(.text+0xf08): 
undefined reference to `iavf_ptp_cap_supported'
iavf_main.c:(.text+0x1924): undefined reference to `iavf_ptp_set_ts_config'
iavf_main.c:(.text+0x61ac): undefined reference to `iavf_ptp_cap_supported'
iavf_main.c:(.text+0x72bc): undefined reference to `iavf_ptp_release'
iavf_main.c:(.text+0x8484): undefined reference to `iavf_ptp_init'

Error/Warning ids grouped by kconfigs:

recent_errors
`-- parisc-randconfig-001-20241105
|-- 
drivers-net-ethernet-intel-iavf-iavf_txrx.c:(.text):undefined-reference-to-iavf_ptp_extend_32b_timestamp
|-- 
drivers-net-ethernet-intel-iavf-iavf_virtchnl.c:(.text):undefined-reference-to-iavf_ptp_cap_supported
|-- 
drivers-net-ethernet-intel-iavf-iavf_virtchnl.c:(.text):undefined-reference-to-iavf_ptp_process_caps
|-- iavf_main.c:(.text):undefined-reference-to-iavf_ptp_cap_supported
|-- iavf_main.c:(.text):undefined-reference-to-iavf_ptp_init
|-- iavf_main.c:(.text):undefined-reference-to-iavf_ptp_release
`-- iavf_main.c:(.text):undefined-reference-to-iavf_ptp_set_ts_config

elapsed time: 1132m

configs tested: 152
configs skipped: 3

tested configs:
alpha allnoconfiggcc-13.3.0
alphaallyesconfiggcc-13.3.0
arc  allmodconfiggcc-13.2.0
arc   allnoconfiggcc-13.2.0
arc  allyesconfiggcc-13.2.0
arc   randconfig-001-20241105gcc-13.2.0
arc   randconfig-002-20241105gcc-13.2.0
arm  allmodconfiggcc-14.1.0
arm   allnoconfigclang-20
arm  allyesconfiggcc-14.1.0
arm  footbridge_defconfigclang-20
arm   imxrt_defconfigclang-20
arm   randconfig-001-20241105gcc-14.1.0
arm   randconfig-002-20241105clang-20
arm   randconfig-003-20241105gcc-14.1.0
arm   randconfig-004-20241105clang-16
armshmobile_defconfiggcc-14.1.0
arm wpcm450_defconfiggcc-14.1.0
arm64allmodconfigclang-20
arm64 allnoconfiggcc-14.1.0
arm64 randconfig-001-20241105gcc-14.1.0
arm64 randconfig-002-20241105gcc-14.1.0
arm64 randconfig-003-20241105gcc-14.1.0
arm64 randconfig-004-20241105gcc-14.1.0
csky  allnoconfiggcc-14.1.0
csky  randconfig-001-20241105gcc-14.1.0
csky  randconfig-002-20241105gcc-14.1.0
hexagon  allmodconfigclang-20
hexagon   allnoconfigclang-20
hexagon  allyesconfigclang-20
hexagon   randconfig-001-20241105clang-20
hexagon   randconfig-002-20241105clang-20
i386 allmodconfiggcc-12
i386  allnoconfiggcc-12
i386 allyesconfiggcc-12
i386    buildonly-randconfig-001-20241105clang-19
i386    buildonly-randconfig-002-20241105gcc-12
i386    buildonly-randconfig-003-20241105clang-19
i386    buildonly-randconfig-004-20241105gcc-12
i386    buildonly-randconfig-005-20241105clang-19
i386    buildonly-randconfig-006-20241105gcc-12
i386defconfigclang-19
i386  randconfig-001-20241105gcc-12
i386  randconfig-002-20241105clang-19
i386  randconfig-003-20241105gcc-12
i386  randconfig-004-20241105clang-19
i386  randconfig-005-20241105clang-19
i386  randconfig-006-20241105gcc-12
i386  randconfig-011-20241105clang-19
i386  randconfig-012-20241105clang-19
i386  randconfig-013-20241105gcc-12
i386  ran

[Intel-wired-lan] [PATCH 5.15.y] ice: Add a per-VF limit on number of FDIR filters

[Sherry Yang]

From: Ahmed Zaki 

commit 6ebbe97a488179f5dc85f2f1e0c89b486e99ee97 upstream.

While the iavf driver adds a s/w limit (128) on the number of FDIR
filters that the VF can request, a malicious VF driver can request more
than that and exhaust the resources for other VFs.

Add a similar limit in ice.

CC: sta...@vger.kernel.org
Fixes: 1f7ea1cd6a37 ("ice: Enable FDIR Configure for AVF")
Reviewed-by: Przemek Kitszel 
Suggested-by: Sridhar Samudrala 
Signed-off-by: Ahmed Zaki 
Reviewed-by: Wojciech Drewek 
Tested-by: Rafal Romanowski 
Signed-off-by: Tony Nguyen 
Signed-off-by: Greg Kroah-Hartman 
[Sherry: bp to fix CVE-2024-42291. Ignore context change in ice_fdir.h
to resolve conflicts.]
Signed-off-by: Sherry Yang 
---
 .../net/ethernet/intel/ice/ice_ethtool_fdir.c|  2 +-
 drivers/net/ethernet/intel/ice/ice_fdir.h|  3 +++
 .../net/ethernet/intel/ice/ice_virtchnl_fdir.c   | 16 
 .../net/ethernet/intel/ice/ice_virtchnl_fdir.h   |  1 +
 4 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_ethtool_fdir.c 
b/drivers/net/ethernet/intel/ice/ice_ethtool_fdir.c
index 0106ea3519a0..b52b77579c7f 100644
--- a/drivers/net/ethernet/intel/ice/ice_ethtool_fdir.c
+++ b/drivers/net/ethernet/intel/ice/ice_ethtool_fdir.c
@@ -456,7 +456,7 @@ ice_parse_rx_flow_user_data(struct ethtool_rx_flow_spec 
*fsp,
  *
  * Returns the number of available flow director filters to this VSI
  */
-static int ice_fdir_num_avail_fltr(struct ice_hw *hw, struct ice_vsi *vsi)
+int ice_fdir_num_avail_fltr(struct ice_hw *hw, struct ice_vsi *vsi)
 {
u16 vsi_num = ice_get_hw_vsi_num(hw, vsi->idx);
u16 num_guar;
diff --git a/drivers/net/ethernet/intel/ice/ice_fdir.h 
b/drivers/net/ethernet/intel/ice/ice_fdir.h
index d2d40e18ae8a..32e9258d27d7 100644
--- a/drivers/net/ethernet/intel/ice/ice_fdir.h
+++ b/drivers/net/ethernet/intel/ice/ice_fdir.h
@@ -201,6 +201,8 @@ struct ice_fdir_base_pkt {
const u8 *tun_pkt;
 };
 
+struct ice_vsi;
+
 enum ice_status ice_alloc_fd_res_cntr(struct ice_hw *hw, u16 *cntr_id);
 enum ice_status ice_free_fd_res_cntr(struct ice_hw *hw, u16 cntr_id);
 enum ice_status
@@ -214,6 +216,7 @@ enum ice_status
 ice_fdir_get_gen_prgm_pkt(struct ice_hw *hw, struct ice_fdir_fltr *input,
  u8 *pkt, bool frag, bool tun);
 int ice_get_fdir_cnt_all(struct ice_hw *hw);
+int ice_fdir_num_avail_fltr(struct ice_hw *hw, struct ice_vsi *vsi);
 bool ice_fdir_is_dup_fltr(struct ice_hw *hw, struct ice_fdir_fltr *input);
 bool ice_fdir_has_frag(enum ice_fltr_ptype flow);
 struct ice_fdir_fltr *
diff --git a/drivers/net/ethernet/intel/ice/ice_virtchnl_fdir.c 
b/drivers/net/ethernet/intel/ice/ice_virtchnl_fdir.c
index 412deb36b645..2ca8102e8f36 100644
--- a/drivers/net/ethernet/intel/ice/ice_virtchnl_fdir.c
+++ b/drivers/net/ethernet/intel/ice/ice_virtchnl_fdir.c
@@ -744,6 +744,8 @@ static void ice_vc_fdir_reset_cnt_all(struct ice_vf_fdir 
*fdir)
fdir->fdir_fltr_cnt[flow][0] = 0;
fdir->fdir_fltr_cnt[flow][1] = 0;
}
+
+   fdir->fdir_fltr_cnt_total = 0;
 }
 
 /**
@@ -1837,6 +1839,7 @@ ice_vc_add_fdir_fltr_post(struct ice_vf *vf, struct 
ice_vf_fdir_ctx *ctx,
resp->status = status;
resp->flow_id = conf->flow_id;
vf->fdir.fdir_fltr_cnt[conf->input.flow_type][is_tun]++;
+   vf->fdir.fdir_fltr_cnt_total++;
 
ret = ice_vc_send_msg_to_vf(vf, ctx->v_opcode, v_ret,
(u8 *)resp, len);
@@ -1901,6 +1904,7 @@ ice_vc_del_fdir_fltr_post(struct ice_vf *vf, struct 
ice_vf_fdir_ctx *ctx,
resp->status = status;
ice_vc_fdir_remove_entry(vf, conf, conf->flow_id);
vf->fdir.fdir_fltr_cnt[conf->input.flow_type][is_tun]--;
+   vf->fdir.fdir_fltr_cnt_total--;
 
ret = ice_vc_send_msg_to_vf(vf, ctx->v_opcode, v_ret,
(u8 *)resp, len);
@@ -2065,6 +2069,7 @@ int ice_vc_add_fdir_fltr(struct ice_vf *vf, u8 *msg)
struct virtchnl_fdir_add *stat = NULL;
struct virtchnl_fdir_fltr_conf *conf;
enum virtchnl_status_code v_ret;
+   struct ice_vsi *vf_vsi;
struct device *dev;
struct ice_pf *pf;
int is_tun = 0;
@@ -2073,6 +2078,17 @@ int ice_vc_add_fdir_fltr(struct ice_vf *vf, u8 *msg)
 
pf = vf->pf;
dev = ice_pf_to_dev(pf);
+   vf_vsi = ice_get_vf_vsi(vf);
+
+#define ICE_VF_MAX_FDIR_FILTERS128
+   if (!ice_fdir_num_avail_fltr(&pf->hw, vf_vsi) ||
+   vf->fdir.fdir_fltr_cnt_total >= ICE_VF_MAX_FDIR_FILTERS) {
+   v_ret = VIRTCHNL_STATUS_ERR_PARAM;
+   dev_err(dev, "Max number of FDIR filters for VF %d is 
reached\n",
+   vf->vf_id);
+   goto err_exit;
+   }
+
ret = ice_vc_fdir_param_check(vf, fltr->vsi_id);
if (ret) {
v_ret = VIRTCHNL_STATUS_ERR_PARAM;
diff --git a/drivers/net/ethernet/intel/ice/ice_virtchnl_fdir.h 
b/drive

[Intel-wired-lan] [tnguy-net-queue:dev-queue 9/14] drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:2377 ixgbe_clean_rx_irq() error: uninitialized symbol 'xdp_res'.

[Dan Carpenter]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue.git 
dev-queue
head:   278dfaa171a0061a341f6b5d44c2c9913a2b7fa8
commit: c919a57ea9cdd6aa02e0e411d8fdb3e3485353cc [9/14] ixgbe: Fix passing 0 to 
ERR_PTR in ixgbe_run_xdp()
config: powerpc64-randconfig-r071-20241104 
(https://download.01.org/0day-ci/archive/20241105/202411052110.vjxfpzue-...@intel.com/config)
compiler: clang version 20.0.0git (https://github.com/llvm/llvm-project 
639a7ac648f1e50ccd2556e17d401c04f9cce625)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot 
| Reported-by: Dan Carpenter 
| Closes: https://lore.kernel.org/r/202411052110.vjxfpzue-...@intel.com/

New smatch warnings:
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:2377 ixgbe_clean_rx_irq() error: 
uninitialized symbol 'xdp_res'.


vim +/xdp_res +2377 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c

5a85e737f30ce7 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c Eliezer Tamir  
2013-06-10  2314  static int ixgbe_clean_rx_irq(struct ixgbe_q_vector 
*q_vector,
18806c9ea28320 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c Alexander Duyck
2012-07-20  2315   struct ixgbe_ring *rx_ring,
f4de00ed58df50 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c Alexander Duyck
2012-09-25  2316   const int budget)
18806c9ea28320 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c Alexander Duyck
2012-07-20  2317  {
43b5169d8355cc drivers/net/ethernet/intel/ixgbe/ixgbe_main.c Lorenzo Bianconi   
2020-12-22  2318unsigned int total_rx_bytes = 0, total_rx_packets = 0, 
frame_sz = 0;
18806c9ea28320 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c Alexander Duyck
2012-07-20  2319struct ixgbe_adapter *adapter = q_vector->adapter;
33fdc82f08835d drivers/net/ethernet/intel/ixgbe/ixgbe_main.c John Fastabend 
2017-04-24  2320  #ifdef IXGBE_FCOE
4ffdf91a5feae6 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c Mark Rustad
2012-07-18  2321int ddp_bytes;
4ffdf91a5feae6 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c Mark Rustad
2012-07-18  2322unsigned int mss = 0;
18806c9ea28320 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c Alexander Duyck
2012-07-20  2323  #endif /* IXGBE_FCOE */
18806c9ea28320 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c Alexander Duyck
2012-07-20  2324u16 cleaned_count = ixgbe_desc_unused(rx_ring);
c0d4e9d223c5f4 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c Maciej Fijalkowski 
2021-01-18  2325unsigned int offset = rx_ring->rx_offset;
ad088ec4807688 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c Jesper Dangaard 
Brouer 2018-06-26  2326unsigned int xdp_xmit = 0;
99ffc5ade4e870 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c Jesper Dangaard 
Brouer 2018-01-03  2327struct xdp_buff xdp;
c919a57ea9cdd6 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c Yue Haibing
2024-10-18  2328int xdp_res;
99ffc5ade4e870 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c Jesper Dangaard 
Brouer 2018-01-03  2329  
cf02512899805d drivers/net/ethernet/intel/ixgbe/ixgbe_main.c Jesper Dangaard 
Brouer 2020-05-14  2330/* Frame size depend on rx_ring setup when 
PAGE_SIZE=4K */
cf02512899805d drivers/net/ethernet/intel/ixgbe/ixgbe_main.c Jesper Dangaard 
Brouer 2020-05-14  2331  #if (PAGE_SIZE < 8192)
43b5169d8355cc drivers/net/ethernet/intel/ixgbe/ixgbe_main.c Lorenzo Bianconi   
2020-12-22  2332frame_sz = ixgbe_rx_frame_truesize(rx_ring, 0);
cf02512899805d drivers/net/ethernet/intel/ixgbe/ixgbe_main.c Jesper Dangaard 
Brouer 2020-05-14  2333  #endif
43b5169d8355cc drivers/net/ethernet/intel/ixgbe/ixgbe_main.c Lorenzo Bianconi   
2020-12-22  2334xdp_init_buff(&xdp, frame_sz, &rx_ring->xdp_rxq);
cf02512899805d drivers/net/ethernet/intel/ixgbe/ixgbe_main.c Jesper Dangaard 
Brouer 2020-05-14  2335  
fdabfc8a74c713 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c Eric W. Biederman  
2014-03-14  2336while (likely(total_rx_packets < budget)) {
18806c9ea28320 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c Alexander Duyck
2012-07-20  2337union ixgbe_adv_rx_desc *rx_desc;
3fd218767fa498 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c Alexander Duyck
2017-01-17  2338struct ixgbe_rx_buffer *rx_buffer;
18806c9ea28320 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c Alexander Duyck
2012-07-20  2339struct sk_buff *skb;
a06316dc87bdc0 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c Björn Töpel
2020-08-25  2340int rx_buffer_pgcnt;
3fd218767fa498 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c Alexander Duyck
2017-01-17  2341unsigned int size;
18806c9ea28320 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c Alexander Duyck
2012-07-20  2342  
18806c9ea28320 drivers/net/ethernet/intel/ixgbe/ixgbe_ma

Re: [Intel-wired-lan] [tnguy-net-queue:dev-queue 9/14] drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:2377 ixgbe_clean_rx_irq() error: uninitialized symbol 'xdp_res'.

[Tony Nguyen]

On 11/5/2024 8:14 AM, Dan Carpenter wrote:

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue.git 
dev-queue
head:   278dfaa171a0061a341f6b5d44c2c9913a2b7fa8
commit: c919a57ea9cdd6aa02e0e411d8fdb3e3485353cc [9/14] ixgbe: Fix passing 0 to 
ERR_PTR in ixgbe_run_xdp()
config: powerpc64-randconfig-r071-20241104 
(https://download.01.org/0day-ci/archive/20241105/202411052110.vjxfpzue-...@intel.com/config)
compiler: clang version 20.0.0git (https://github.com/llvm/llvm-project 
639a7ac648f1e50ccd2556e17d401c04f9cce625)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot 
| Reported-by: Dan Carpenter 
| Closes: https://lore.kernel.org/r/202411052110.vjxfpzue-...@intel.com/

New smatch warnings:
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:2377 ixgbe_clean_rx_irq() error: 
uninitialized symbol 'xdp_res'.


Thanks for the report Dan. Looks like the old version wasn't dropped 
from the *net tree when it changed target trees. There's a new version 
on *next that doesn't contain this issue:


https://lore.kernel.org/intel-wired-lan/20241026041249.1267664-4-yuehaib...@huawei.com/

Thanks,
Tony


vim +/xdp_res +2377 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c

[Intel-wired-lan] [tnguy-net-queue:dev-queue] BUILD SUCCESS 278dfaa171a0061a341f6b5d44c2c9913a2b7fa8

[kernel test robot]

tree/branch: 
https://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue.git dev-queue
branch HEAD: 278dfaa171a0061a341f6b5d44c2c9913a2b7fa8  ice: change q_index 
variable type to s16 to store -1 value

elapsed time: 1054m

configs tested: 167
configs skipped: 7

The following configs have been built successfully.
More configs may be tested in the coming days.

tested configs:
alphaallnoconfiggcc-13.3.0
alphaallnoconfiggcc-14.1.0
alpha   allyesconfigclang-20
alpha   allyesconfiggcc-13.3.0
alpha  defconfiggcc-14.1.0
arc allmodconfigclang-20
arc allmodconfiggcc-13.2.0
arc  allnoconfiggcc-13.2.0
arc  allnoconfiggcc-14.1.0
arc allyesconfigclang-20
arc allyesconfiggcc-13.2.0
arcdefconfiggcc-14.1.0
arc   nsim_700_defconfiggcc-14.1.0
arc  randconfig-001-20241105gcc-13.2.0
arc  randconfig-002-20241105gcc-13.2.0
arc   vdk_hs38_smp_defconfiggcc-14.1.0
arm allmodconfigclang-20
arm allmodconfiggcc-14.1.0
arm  allnoconfigclang-20
arm  allnoconfiggcc-14.1.0
arm allyesconfigclang-20
arm allyesconfiggcc-14.1.0
arm  aspeed_g5_defconfiggcc-14.1.0
arm   clps711x_defconfiggcc-14.1.0
armdefconfiggcc-14.1.0
arm footbridge_defconfiggcc-14.1.0
arm  imx_v4_v5_defconfiggcc-14.1.0
arm  imxrt_defconfiggcc-14.1.0
arm  randconfig-001-20241105gcc-14.1.0
arm  randconfig-002-20241105clang-20
arm  randconfig-003-20241105gcc-14.1.0
arm  randconfig-004-20241105clang-16
arm   shmobile_defconfiggcc-14.1.0
armwpcm450_defconfiggcc-14.1.0
arm64   allmodconfigclang-20
arm64allnoconfiggcc-14.1.0
arm64  defconfiggcc-14.1.0
arm64randconfig-001-20241105gcc-14.1.0
arm64randconfig-002-20241105gcc-14.1.0
arm64randconfig-003-20241105gcc-14.1.0
arm64randconfig-004-20241105gcc-14.1.0
csky allnoconfiggcc-14.1.0
csky   defconfiggcc-14.1.0
csky randconfig-001-20241105gcc-14.1.0
csky randconfig-002-20241105gcc-14.1.0
hexagon allmodconfigclang-20
hexagon  allnoconfigclang-20
hexagon  allnoconfiggcc-14.1.0
hexagon allyesconfigclang-20
hexagondefconfiggcc-14.1.0
hexagon  randconfig-001-20241105clang-20
hexagon  randconfig-002-20241105clang-20
i386allmodconfigclang-19
i386allmodconfiggcc-12
i386 allnoconfigclang-19
i386 allnoconfiggcc-12
i386allyesconfigclang-19
i386allyesconfiggcc-12
i386   defconfigclang-19
loongarch   allmodconfiggcc-14.1.0
loongarchallnoconfiggcc-14.1.0
loongarch  defconfiggcc-14.1.0
loongarchrandconfig-001-20241105gcc-14.1.0
loongarchrandconfig-002-20241105gcc-14.1.0
m68kallmodconfiggcc-14.1.0
m68k allnoconfiggcc-14.1.0
m68kallyesconfiggcc-14.1.0
m68k   defconfiggcc-14.1.0
m68k sun3x_defconfiggcc-14.1.0
microblaze  allmodconfiggcc-14.1.0
microblaze   allnoconfiggcc-14.1.0
microblaze  allyesconfiggcc-14.1.0
microblaze defconfiggcc-14.1.0
microblaze mmu_defconfiggcc-14.1.0
mips allnoconfiggcc-14.1.0
mips ath79_defconfiggcc-14.1.0
mipsbigsur_defconfiggcc-14.1.0
mips  ip27_defconfiggcc-14.1.0
mipsloongson1b_defconfiggcc-14.1.0
nios2allnoconfiggcc-14.1.0
nios2  defconfiggcc-14.1.0
nios2randconfig-001-20241105gcc-14.1.0
nios2randconfig-002-20241105gcc-14.1.0
openrisc allnoconfigclang-20
openrisc allnoconfiggcc-14.1.0
openriscallyesconfiggcc-14.1.0
openrisc   defconfiggcc-12
parisc  allmodconfiggcc-14.1.0
parisc   allnoconfigclang-20
parisc   allnoconfiggcc-14.1.0
parisc  allyesconfiggcc-14.1.0
parisc

[Intel-wired-lan] [PATCH iwl-net v1 4/4] idpf: add lock class key

[Tarun K Singh]

From: Ahmed Zaki 

Add lock class key changes to prevent lockdep from complaining
when PF reset the VFs.

Signed-off-by: Ahmed Zaki 
Reviewed-by: Przemek Kitszel 
Reviewed-by: Madhu Chittim 
Signed-off-by: Tarun K Singh 
---
 drivers/net/ethernet/intel/idpf/idpf_main.c | 32 +
 1 file changed, 20 insertions(+), 12 deletions(-)

diff --git a/drivers/net/ethernet/intel/idpf/idpf_main.c 
b/drivers/net/ethernet/intel/idpf/idpf_main.c
index 04bbc048c829..082026c2a7ab 100644
--- a/drivers/net/ethernet/intel/idpf/idpf_main.c
+++ b/drivers/net/ethernet/intel/idpf/idpf_main.c
@@ -11,6 +11,10 @@ MODULE_DESCRIPTION(DRV_SUMMARY);
 MODULE_IMPORT_NS(LIBETH);
 MODULE_LICENSE("GPL");
 
+/* Prevent lockdep from complaining when PF reset the VFs */
+static struct lock_class_key idpf_pf_vport_init_lock_key;
+static struct lock_class_key idpf_pf_work_lock_key;
+
 /**
  * idpf_remove - Device removal routine
  * @pdev: PCI device information struct
@@ -140,9 +144,25 @@ static int idpf_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent)
adapter->req_tx_splitq = true;
adapter->req_rx_splitq = true;
 
+   mutex_init(&adapter->vport_init_lock);
+   mutex_init(&adapter->vport_cfg_lock);
+   mutex_init(&adapter->vector_lock);
+   mutex_init(&adapter->queue_lock);
+   mutex_init(&adapter->vc_buf_lock);
+
+   INIT_DELAYED_WORK(&adapter->init_task, idpf_init_task);
+   INIT_DELAYED_WORK(&adapter->serv_task, idpf_service_task);
+   INIT_DELAYED_WORK(&adapter->mbx_task, idpf_mbx_task);
+   INIT_DELAYED_WORK(&adapter->stats_task, idpf_statistics_task);
+   INIT_DELAYED_WORK(&adapter->vc_event_task, idpf_vc_event_task);
+
switch (ent->device) {
case IDPF_DEV_ID_PF:
idpf_dev_ops_init(adapter);
+   lockdep_set_class(&adapter->vport_init_lock,
+ &idpf_pf_vport_init_lock_key);
+   lockdep_init_map(&adapter->vc_event_task.work.lockdep_map,
+"idpf-PF-vc-work", &idpf_pf_work_lock_key, 0);
break;
case IDPF_DEV_ID_VF:
idpf_vf_dev_ops_init(adapter);
@@ -233,18 +253,6 @@ static int idpf_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent)
goto err_cfg_hw;
}
 
-   mutex_init(&adapter->vport_init_lock);
-   mutex_init(&adapter->vport_cfg_lock);
-   mutex_init(&adapter->vector_lock);
-   mutex_init(&adapter->queue_lock);
-   mutex_init(&adapter->vc_buf_lock);
-
-   INIT_DELAYED_WORK(&adapter->init_task, idpf_init_task);
-   INIT_DELAYED_WORK(&adapter->serv_task, idpf_service_task);
-   INIT_DELAYED_WORK(&adapter->mbx_task, idpf_mbx_task);
-   INIT_DELAYED_WORK(&adapter->stats_task, idpf_statistics_task);
-   INIT_DELAYED_WORK(&adapter->vc_event_task, idpf_vc_event_task);
-
adapter->dev_ops.reg_ops.reset_reg_init(adapter);
set_bit(IDPF_HR_DRV_LOAD, adapter->flags);
queue_delayed_work(adapter->vc_event_wq, &adapter->vc_event_task,
-- 
2.46.0

Re: [Intel-wired-lan] [PATCH iwl-net 2/2] ixgbe: downgrade logging of unsupported VF API version to debug

[Keller, Jacob E]

> -Original Message-
> From: Paul Menzel 
> Sent: Friday, November 1, 2024 11:54 PM
> To: Keller, Jacob E 
> Cc: intel-wired-...@lists.osuosl.org; Yifei Liu ; 
> Kitszel,
> Przemyslaw 
> Subject: Re: [Intel-wired-lan] [PATCH iwl-net 2/2] ixgbe: downgrade logging of
> unsupported VF API version to debug
> 
> Dear Jacob,
> 
> 
> Thank you for the patch.
> 
> Am 02.11.24 um 00:05 schrieb Jacob Keller:
> > The ixgbe PF driver logs an info message when a VF attempts to negotiate an
> > API version which it does not support:
> >
> >VF 0 requested invalid api version 6
> >
> > The ixgbevf driver attempts to load with mailbox API v1.5, which is
> > required for best compatibility with other hosts such as the ESX VMWare PF.
> >
> > The Linux PF only supports API v1.4, and does not currently have support
> > for the v1.5 API.
> >
> > The logged message can confuse users, as the v1.5 API is valid, but just
> > happens to not currently be supported by the Linux PF.
> >
> > Downgrade the info message to a debug message, and fix the language to
> > use 'unsupported' instead of 'invalid' to improve message clarity.
> >
> > Long term, we should investigate whether the improvements in the v1.5 API
> > make sense for the Linux PF, and if so implement them properly. This may
> > require yet another API version to resolve issues with negotiating IPSEC
> > offload support.
> 
> It’d be great if you described the exact test setup for how to reproduce it.
> 

If you load the builtin ixgbevf and ixgbe drivers, you'll see this message.

> > Reported-by: Yifei Liu 
> 
> Do you have an Link: for this report?
> 

I do not, it was reported to me privately over email.

> > Signed-off-by: Jacob Keller 
> > Reviewed-by: Przemek Kitszel 
> > ---
> >   drivers/net/ethernet/intel/ixgbe/ixgbe_common.h | 2 ++
> >   drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c  | 2 +-
> >   2 files changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h
> b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h
> > index 6493abf189de..6639069ad528 100644
> > --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h
> > +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h
> > @@ -194,6 +194,8 @@ u32 ixgbe_read_reg(struct ixgbe_hw *hw, u32 reg);
> > dev_err(&adapter->pdev->dev, format, ## arg)
> >   #define e_dev_notice(format, arg...) \
> > dev_notice(&adapter->pdev->dev, format, ## arg)
> > +#define e_dbg(msglvl, format, arg...) \
> > +   netif_dbg(adapter, msglvl, adapter->netdev, format, ## arg)
> >   #define e_info(msglvl, format, arg...) \
> > netif_info(adapter, msglvl, adapter->netdev, format, ## arg)
> >   #define e_err(msglvl, format, arg...) \
> > diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
> b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
> > index e71715f5da22..20415c1238ef 100644
> > --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
> > +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
> > @@ -1047,7 +1047,7 @@ static int ixgbe_negotiate_vf_api(struct ixgbe_adapter
> *adapter,
> > break;
> > }
> >
> > -   e_info(drv, "VF %d requested invalid api version %u\n", vf, api);
> > +   e_dbg(drv, "VF %d requested unsupported api version %u\n", vf, api);
> 
> Is there a way to translate `api` to the API version scheme used in the
> commit message? So, 1.5 instead of 6? Maybe also add, that only the v1.4
> API is supported?
> 

I suppose I could add a enum to string converter. I didn't really feel that was 
worthwhile in a net fix.

My primary goal here is to stop complaining about v1.5 API since it’s a "known" 
but not compatible with the current ixgbe code. Users see the warning and get 
confused, so the only change I care about for net is converting to e_dbg so 
that it stops showing up without explicit developer interaction. Its not 
helpful to most end users.

> >
> > return -1;
> >   }
> 
> 
> Kind regards,
> 
> Paul

Re: [Intel-wired-lan] Small Integers: Big Penalty

[Keller, Jacob E]

> -Original Message-
> From: Michal Swiatkowski 
> Sent: Monday, November 4, 2024 3:25 AM
> To: Paul Menzel 
> Cc: David Laight ; Drewek, Wojciech
> ; Szycik, Marcin ;
> net...@vger.kernel.org; Knitter, Konrad ;
> Chmielewski, Pawel ; ho...@kernel.org; intel-
> wired-...@lists.osuosl.org; pio.raczyn...@gmail.com; Samudrala, Sridhar
> ; Keller, Jacob E ;
> j...@resnulli.us; Kitszel, Przemyslaw 
> Subject: Re: [Intel-wired-lan] Small Integers: Big Penalty
> 
> On Mon, Nov 04, 2024 at 10:12:14AM +0100, Paul Menzel wrote:
> > [Cc: -nex.sw.ncis.nat.hpm@intel.com (550 #5.1.0 Address rejected.)]
> >
> > Am 04.11.24 um 10:09 schrieb Paul Menzel:
> > > Dear David, dear Michal,
> > >
> > >
> > > Am 04.11.24 um 09:51 schrieb David Laight:
> > > > From: Michal Swiatkowski
> > > > > Sent: 04 November 2024 07:03
> > > > ...
> > > > > > The type of the devlink parameters msix_vec_per_pf_{min,max} is
> > > > > > specified as u32, so you must use value.vu32 everywhere you work 
> > > > > > with
> > > > > > them, not vu16.
> > > > > >
> > > > >
> > > > > I will change it.
> > > >
> > > > You also need a pretty good reason to use u16 anywhere at all.
> > > > Just because the domain of the value is small doesn't mean the
> > > > best type isn't [unsigned] int.
> > > >
> > > > Any arithmetic (particularly on non x86) is likely to increase
> > > > the code size above any perceived data saving.
> > >
> > > In 2012 Scott Duplichan wrote *Small Integers: Big Penalty* [1]. Of
> > > course you always should measure yourself.
> > >
> 
> Yeah, I chose it, because previously it was stored in u16. I will change
> it to u32 too, as it is stored in structure that doesn't really need to
> be small.
> 
> Thanks for comments and link to the article.
> Michal
> 

Yea.. ice driver code has a bad habit of using smaller size values in 
structures when its unnecessary.

Re: [Intel-wired-lan] [PATCH iwl-net 1/2] ixgbevf: stop attempting IPSEC offload on Mailbox API 1.5

[Jacob Keller]

On 11/1/2024 4:05 PM, Jacob Keller wrote:
> Commit 339f28964147 ("ixgbevf: Add support for new mailbox communication
> between PF and VF") added support for v1.5 of the PF to VF mailbox
> communication API. This commit mistakenly enabled IPSEC offload for API
> v1.5.
> 
> No implementation of the v1.5 API has support for IPSEC offload. This
> offload is only supported by the Linux PF as mailbox API v1.4. In fact, the
> v1.5 API is not implemented in any Linux PF.
> 
> Attempting to enable IPSEC offload on a PF which supports v1.5 API will not
> work. Only the Linux upstream ixgbe and ixgbevf support IPSEC offload, and
> only as part of the v1.4 API.
> 
> Fix the ixgbevf Linux driver to stop attempting IPSEC offload when
> the mailbox API does not support it.
> 
> The existing API design choice makes it difficult to support future API
> versions, as other non-Linux hosts do not implement IPSEC offload. If we
> add support for v1.5 to the Linux PF, then we lose support for IPSEC
> offload.
> 
> A full solution likely requires a new mailbox API with a proper negotiation
> to check that IPSEC is actually supported by the host.
> 

Fixes: 339f28964147 ("ixgbevf: Add support for new mailbox communication
between PF and VF")

> Signed-off-by: Jacob Keller 
> Reviewed-by: Przemek Kitszel 
> ---
>  drivers/net/ethernet/intel/ixgbevf/ipsec.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/intel/ixgbevf/ipsec.c 
> b/drivers/net/ethernet/intel/ixgbevf/ipsec.c
> index 66cf17f19408..f804b35d79c7 100644
> --- a/drivers/net/ethernet/intel/ixgbevf/ipsec.c
> +++ b/drivers/net/ethernet/intel/ixgbevf/ipsec.c
> @@ -629,7 +629,6 @@ void ixgbevf_init_ipsec_offload(struct ixgbevf_adapter 
> *adapter)
>  
>   switch (adapter->hw.api_version) {
>   case ixgbe_mbox_api_14:
> - case ixgbe_mbox_api_15:
>   break;
>   default:
>   return;
> 

Re: [Intel-wired-lan] [PATCH iwl-net 2/2] ixgbe: downgrade logging of unsupported VF API version to debug

[Jacob Keller]

On 11/1/2024 4:05 PM, Jacob Keller wrote:
> The ixgbe PF driver logs an info message when a VF attempts to negotiate an
> API version which it does not support:
> 
>   VF 0 requested invalid api version 6
> 
> The ixgbevf driver attempts to load with mailbox API v1.5, which is
> required for best compatibility with other hosts such as the ESX VMWare PF.
> 
> The Linux PF only supports API v1.4, and does not currently have support
> for the v1.5 API.
> 
> The logged message can confuse users, as the v1.5 API is valid, but just
> happens to not currently be supported by the Linux PF.
> 
> Downgrade the info message to a debug message, and fix the language to
> use 'unsupported' instead of 'invalid' to improve message clarity.
> 
> Long term, we should investigate whether the improvements in the v1.5 API
> make sense for the Linux PF, and if so implement them properly. This may
> require yet another API version to resolve issues with negotiating IPSEC
> offload support.
> 
> Reported-by: Yifei Liu 
> Signed-off-by: Jacob Keller 
> Reviewed-by: Przemek Kitszel 

Fixes: 339f28964147 ("ixgbevf: Add support for new mailbox communication
between PF and VF")

> ---
>  drivers/net/ethernet/intel/ixgbe/ixgbe_common.h | 2 ++
>  drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c  | 2 +-
>  2 files changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h 
> b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h
> index 6493abf189de..6639069ad528 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h
> @@ -194,6 +194,8 @@ u32 ixgbe_read_reg(struct ixgbe_hw *hw, u32 reg);
>   dev_err(&adapter->pdev->dev, format, ## arg)
>  #define e_dev_notice(format, arg...) \
>   dev_notice(&adapter->pdev->dev, format, ## arg)
> +#define e_dbg(msglvl, format, arg...) \
> + netif_dbg(adapter, msglvl, adapter->netdev, format, ## arg)
>  #define e_info(msglvl, format, arg...) \
>   netif_info(adapter, msglvl, adapter->netdev, format, ## arg)
>  #define e_err(msglvl, format, arg...) \
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c 
> b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
> index e71715f5da22..20415c1238ef 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
> @@ -1047,7 +1047,7 @@ static int ixgbe_negotiate_vf_api(struct ixgbe_adapter 
> *adapter,
>   break;
>   }
>  
> - e_info(drv, "VF %d requested invalid api version %u\n", vf, api);
> + e_dbg(drv, "VF %d requested unsupported api version %u\n", vf, api);
>  
>   return -1;
>  }
> 

Re: [Intel-wired-lan] [PATCH iwl-net 2/2] ixgbe: downgrade logging of unsupported VF API version to debug

[Jacob Keller]

On 11/1/2024 11:53 PM, Paul Menzel wrote:
> Dear Jacob,
> 
> 
> Thank you for the patch.
> 
> Am 02.11.24 um 00:05 schrieb Jacob Keller:
>> The ixgbe PF driver logs an info message when a VF attempts to negotiate an
>> API version which it does not support:
>>
>>VF 0 requested invalid api version 6
>>
>> The ixgbevf driver attempts to load with mailbox API v1.5, which is
>> required for best compatibility with other hosts such as the ESX VMWare PF.
>>
>> The Linux PF only supports API v1.4, and does not currently have support
>> for the v1.5 API.
>>
>> The logged message can confuse users, as the v1.5 API is valid, but just
>> happens to not currently be supported by the Linux PF.
>>
>> Downgrade the info message to a debug message, and fix the language to
>> use 'unsupported' instead of 'invalid' to improve message clarity.
>>
>> Long term, we should investigate whether the improvements in the v1.5 API
>> make sense for the Linux PF, and if so implement them properly. This may
>> require yet another API version to resolve issues with negotiating IPSEC
>> offload support.
> 
> It’d be great if you described the exact test setup for how to reproduce it.
> 
>> Reported-by: Yifei Liu 
> 
> Do you have an Link: for this report?
> 
>> Signed-off-by: Jacob Keller 
>> Reviewed-by: Przemek Kitszel 
>> ---
>>   drivers/net/ethernet/intel/ixgbe/ixgbe_common.h | 2 ++
>>   drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c  | 2 +-
>>   2 files changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h 
>> b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h
>> index 6493abf189de..6639069ad528 100644
>> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h
>> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h
>> @@ -194,6 +194,8 @@ u32 ixgbe_read_reg(struct ixgbe_hw *hw, u32 reg);
>>  dev_err(&adapter->pdev->dev, format, ## arg)
>>   #define e_dev_notice(format, arg...) \
>>  dev_notice(&adapter->pdev->dev, format, ## arg)
>> +#define e_dbg(msglvl, format, arg...) \
>> +netif_dbg(adapter, msglvl, adapter->netdev, format, ## arg)
>>   #define e_info(msglvl, format, arg...) \
>>  netif_info(adapter, msglvl, adapter->netdev, format, ## arg)
>>   #define e_err(msglvl, format, arg...) \
>> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c 
>> b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
>> index e71715f5da22..20415c1238ef 100644
>> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
>> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
>> @@ -1047,7 +1047,7 @@ static int ixgbe_negotiate_vf_api(struct ixgbe_adapter 
>> *adapter,
>>  break;
>>  }
>>   
>> -e_info(drv, "VF %d requested invalid api version %u\n", vf, api);
>> +e_dbg(drv, "VF %d requested unsupported api version %u\n", vf, api);
> 
> Is there a way to translate `api` to the API version scheme used in the 
> commit message? So, 1.5 instead of 6? Maybe also add, that only the v1.4 
> API is supported?
> 

I would prefer to improve the message via a cleanup on next after this
is merged and next merges with net.

Thanks,
Jake

[Intel-wired-lan] [PATCH iwl-net v1 3/4] idpf: Add init, reinit, and deinit control lock

[Tarun K Singh]

Add new 'vport_init_lock' to prevent locking issue.

The existing 'vport_cfg_lock' was controlling the vport initialization,
re-initialization due to reset, and de-initialization of code flow.
In addition to controlling the above behavior it was also controlling
the parallel netdevice calls such as open/close from Linux OS, which
can happen independent of re-init or de-init of the vport(s). If first
one such as re-init or de-init is going on then the second operation
to config the netdevice with OS should not take place. The first
operation (init or de-init) takes the precedence if both are to happen
simultaneously.

Use of single lock cause deadlock and inconsistent behavior of code
flow. E.g. when driver undergoes reset via 'idpf_init_hard_reset', it
acquires the 'vport_cfg_lock', and during this process it tries to
unregister netdevice which may call 'idpf_stop' which tries to acquire
same lock causing it to deadlock.

To address above, add new lock 'vport_init_lock' which control the
initialization, re-initialization, and de-initialization flow.
The 'vport_cfg_lock' now exclusively controls the vport config
operations.

Add vport config lock around 'idpf_vport_stop()' and 'idpf_vport_open()'
to protect close and open operation at the same time.

Add vport init lock around 'idpf_sriv_configure()' to protect it from
load and removal path. To accomplish it, use existing function
as wrapper and introduce another function 'idpf_sriov_config_vfs'
which is used inside the lock.

In idpf_remove, change 'idpf_sriov_configure' to
'idpf_sriov_config_vfs', and move inside the init lock.

Use these two locks in the following precedence:
'vport_init_lock' first, then 'vport_cfg_lock'.

Fixes: 8077c727561a ("idpf: add controlq init and reset checks")
Reviewed-by: Przemek Kitszel 
Reviewed-by: Madhu Chittim 
Signed-off-by: Tarun K Singh 
---
 drivers/net/ethernet/intel/idpf/idpf.h  | 25 +
 drivers/net/ethernet/intel/idpf/idpf_lib.c  | 41 ++---
 drivers/net/ethernet/intel/idpf/idpf_main.c |  7 +++-
 3 files changed, 67 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/intel/idpf/idpf.h 
b/drivers/net/ethernet/intel/idpf/idpf.h
index 8dea2dd784af..34dbdc7d6c88 100644
--- a/drivers/net/ethernet/intel/idpf/idpf.h
+++ b/drivers/net/ethernet/intel/idpf/idpf.h
@@ -526,6 +526,7 @@ struct idpf_vc_xn_manager;
  * @crc_enable: Enable CRC insertion offload
  * @req_tx_splitq: TX split or single queue model to request
  * @req_rx_splitq: RX split or single queue model to request
+ * @vport_init_lock: Lock to protect vport init, re-init, and deinit flow
  * @vport_cfg_lock: Lock to protect the vport config flow
  * @vector_lock: Lock to protect vector distribution
  * @queue_lock: Lock to protect queue distribution
@@ -583,6 +584,7 @@ struct idpf_adapter {
bool req_tx_splitq;
bool req_rx_splitq;
 
+   struct mutex vport_init_lock;
struct mutex vport_cfg_lock;
struct mutex vector_lock;
struct mutex queue_lock;
@@ -786,6 +788,28 @@ static inline u16 idpf_get_max_tx_hdr_size(struct 
idpf_adapter *adapter)
return le16_to_cpu(adapter->caps.max_tx_hdr_size);
 }
 
+/**
+ * idpf_vport_init_lock -acquire init/deinit control lock
+ * @adapter: private data struct
+ *
+ * It controls and protect vport initialization, re-initialization,
+ * and deinitialization code flow and its resources. This
+ * lock is only used by non-datapath code.
+ */
+static inline void idpf_vport_init_lock(struct idpf_adapter *adapter)
+{
+   mutex_lock(&adapter->vport_init_lock);
+}
+
+/**
+ * idpf_vport_init_unlock - release vport init lock
+ * @adapter: private data struct
+ */
+static inline void idpf_vport_init_unlock(struct idpf_adapter *adapter)
+{
+   mutex_unlock(&adapter->vport_init_lock);
+}
+
 /**
  * idpf_vport_cfg_lock - Acquire the vport config lock
  * @adapter: private data struct
@@ -827,6 +851,7 @@ void idpf_set_ethtool_ops(struct net_device *netdev);
 void idpf_vport_intr_write_itr(struct idpf_q_vector *q_vector,
   u16 itr, bool tx);
 int idpf_sriov_configure(struct pci_dev *pdev, int num_vfs);
+int idpf_sriov_config_vfs(struct pci_dev *pdev, int num_vfs);
 
 u8 idpf_vport_get_hsplit(const struct idpf_vport *vport);
 bool idpf_vport_set_hsplit(const struct idpf_vport *vport, u8 val);
diff --git a/drivers/net/ethernet/intel/idpf/idpf_lib.c 
b/drivers/net/ethernet/intel/idpf/idpf_lib.c
index 778dc71fbf4a..931d0f988c95 100644
--- a/drivers/net/ethernet/intel/idpf/idpf_lib.c
+++ b/drivers/net/ethernet/intel/idpf/idpf_lib.c
@@ -1000,7 +1000,10 @@ static void idpf_vport_dealloc(struct idpf_vport *vport)
unsigned int i = vport->idx;
 
idpf_deinit_mac_addr(vport);
+
+   idpf_vport_cfg_lock(adapter);
idpf_vport_stop(vport);
+   idpf_vport_cfg_unlock(adapter);
 
if (!test_bit(IDPF_HR_RESET_IN_PROG, adapter->flags))
idpf_decfg_netdev(vport);
@@ -1522,8 +1525,11 @@ void 

[Intel-wired-lan] [PATCH iwl-net v1 0/4] fix locking issue

[Tarun K Singh]

This series fix deadlock issues in the driver. The first patch changes
argument of function 'idpf_vport_ctrl_lock' to adapter. The second patch
renames 'vport_ctrl_lock' to 'vport_cfg_lock'. The first 2 patches make the
third patch easier to review. The third patch fixes the locking issue,
and the fourth patch prevents lockdep from complaining.

Ahmed Zaki (1):
  idpf: add lock class key

Tarun K Singh (3):
  idpf: Change function argument
  idpf: rename vport_ctrl_lock
  idpf: Add init, reinit, and deinit control lock

 drivers/net/ethernet/intel/idpf/idpf.h| 49 
 .../net/ethernet/intel/idpf/idpf_ethtool.c| 59 +++---
 drivers/net/ethernet/intel/idpf/idpf_lib.c| 80 +--
 drivers/net/ethernet/intel/idpf/idpf_main.c   | 39 ++---
 4 files changed, 149 insertions(+), 78 deletions(-)

-- 
2.46.0

[Intel-wired-lan] [PATCH iwl-net v1 1/4] idpf: Change function argument

[Tarun K Singh]

Change idpf_vport_ctrl_lock's argument from netdev to adapter.

Reviewed-by: Przemek Kitszel 
Signed-off-by: Tarun K Singh 
---
 drivers/net/ethernet/intel/idpf/idpf.h| 16 ++---
 .../net/ethernet/intel/idpf/idpf_ethtool.c| 59 ++-
 drivers/net/ethernet/intel/idpf/idpf_lib.c| 39 ++--
 3 files changed, 58 insertions(+), 56 deletions(-)

diff --git a/drivers/net/ethernet/intel/idpf/idpf.h 
b/drivers/net/ethernet/intel/idpf/idpf.h
index 66544faab710..d87ed50af681 100644
--- a/drivers/net/ethernet/intel/idpf/idpf.h
+++ b/drivers/net/ethernet/intel/idpf/idpf.h
@@ -788,27 +788,23 @@ static inline u16 idpf_get_max_tx_hdr_size(struct 
idpf_adapter *adapter)
 
 /**
  * idpf_vport_ctrl_lock - Acquire the vport control lock
- * @netdev: Network interface device structure
+ * @adapter: private data struct
  *
  * This lock should be used by non-datapath code to protect against vport
  * destruction.
  */
-static inline void idpf_vport_ctrl_lock(struct net_device *netdev)
+static inline void idpf_vport_ctrl_lock(struct idpf_adapter *adapter)
 {
-   struct idpf_netdev_priv *np = netdev_priv(netdev);
-
-   mutex_lock(&np->adapter->vport_ctrl_lock);
+   mutex_lock(&adapter->vport_ctrl_lock);
 }
 
 /**
  * idpf_vport_ctrl_unlock - Release the vport control lock
- * @netdev: Network interface device structure
+ * @adapter: private data struct
  */
-static inline void idpf_vport_ctrl_unlock(struct net_device *netdev)
+static inline void idpf_vport_ctrl_unlock(struct idpf_adapter *adapter)
 {
-   struct idpf_netdev_priv *np = netdev_priv(netdev);
-
-   mutex_unlock(&np->adapter->vport_ctrl_lock);
+   mutex_unlock(&adapter->vport_ctrl_lock);
 }
 
 void idpf_statistics_task(struct work_struct *work);
diff --git a/drivers/net/ethernet/intel/idpf/idpf_ethtool.c 
b/drivers/net/ethernet/intel/idpf/idpf_ethtool.c
index 59b1a1a09996..e5ac3e5a50ce 100644
--- a/drivers/net/ethernet/intel/idpf/idpf_ethtool.c
+++ b/drivers/net/ethernet/intel/idpf/idpf_ethtool.c
@@ -14,22 +14,23 @@
 static int idpf_get_rxnfc(struct net_device *netdev, struct ethtool_rxnfc *cmd,
  u32 __always_unused *rule_locs)
 {
+   struct idpf_adapter *adapter = idpf_netdev_to_adapter(netdev);
struct idpf_vport *vport;
 
-   idpf_vport_ctrl_lock(netdev);
+   idpf_vport_ctrl_lock(adapter);
vport = idpf_netdev_to_vport(netdev);
 
switch (cmd->cmd) {
case ETHTOOL_GRXRINGS:
cmd->data = vport->num_rxq;
-   idpf_vport_ctrl_unlock(netdev);
+   idpf_vport_ctrl_unlock(adapter);
 
return 0;
default:
break;
}
 
-   idpf_vport_ctrl_unlock(netdev);
+   idpf_vport_ctrl_unlock(adapter);
 
return -EOPNOTSUPP;
 }
@@ -88,9 +89,8 @@ static int idpf_get_rxfh(struct net_device *netdev,
int err = 0;
u16 i;
 
-   idpf_vport_ctrl_lock(netdev);
-
adapter = np->adapter;
+   idpf_vport_ctrl_lock(adapter);
 
if (!idpf_is_cap_ena_all(adapter, IDPF_RSS_CAPS, IDPF_CAP_RSS)) {
err = -EOPNOTSUPP;
@@ -112,7 +112,7 @@ static int idpf_get_rxfh(struct net_device *netdev,
}
 
 unlock_mutex:
-   idpf_vport_ctrl_unlock(netdev);
+   idpf_vport_ctrl_unlock(adapter);
 
return err;
 }
@@ -131,17 +131,15 @@ static int idpf_set_rxfh(struct net_device *netdev,
 struct netlink_ext_ack *extack)
 {
struct idpf_netdev_priv *np = netdev_priv(netdev);
+   struct idpf_adapter *adapter = np->adapter;
struct idpf_rss_data *rss_data;
-   struct idpf_adapter *adapter;
struct idpf_vport *vport;
int err = 0;
u16 lut;
 
-   idpf_vport_ctrl_lock(netdev);
+   idpf_vport_ctrl_lock(adapter);
vport = idpf_netdev_to_vport(netdev);
 
-   adapter = vport->adapter;
-
if (!idpf_is_cap_ena_all(adapter, IDPF_RSS_CAPS, IDPF_CAP_RSS)) {
err = -EOPNOTSUPP;
goto unlock_mutex;
@@ -168,7 +166,7 @@ static int idpf_set_rxfh(struct net_device *netdev,
err = idpf_config_rss(vport);
 
 unlock_mutex:
-   idpf_vport_ctrl_unlock(netdev);
+   idpf_vport_ctrl_unlock(adapter);
 
return err;
 }
@@ -221,6 +219,7 @@ static void idpf_get_channels(struct net_device *netdev,
 static int idpf_set_channels(struct net_device *netdev,
 struct ethtool_channels *ch)
 {
+   struct idpf_adapter *adapter = idpf_netdev_to_adapter(netdev);
struct idpf_vport_config *vport_config;
unsigned int num_req_tx_q;
unsigned int num_req_rx_q;
@@ -235,7 +234,7 @@ static int idpf_set_channels(struct net_device *netdev,
return -EINVAL;
}
 
-   idpf_vport_ctrl_lock(netdev);
+   idpf_vport_ctrl_lock(adapter);
vport = idpf_netdev_to_vport(netdev);
 
idx = vport->idx;
@@ -279,7 +278,7 @@ static int idpf_set_channels(struct net_d

[Intel-wired-lan] [PATCH iwl-net v1 2/4] idpf: rename vport_ctrl_lock

[Tarun K Singh]

Rename 'vport_ctrl_lock' to 'vport_cfg_lock'. Rename related
functions name for lock and unlock.

Reviewed-by: Przemek Kitszel 
Signed-off-by: Tarun K Singh 
---
 drivers/net/ethernet/intel/idpf/idpf.h| 16 +++
 .../net/ethernet/intel/idpf/idpf_ethtool.c| 46 +--
 drivers/net/ethernet/intel/idpf/idpf_lib.c| 24 +-
 drivers/net/ethernet/intel/idpf/idpf_main.c   |  4 +-
 4 files changed, 45 insertions(+), 45 deletions(-)

diff --git a/drivers/net/ethernet/intel/idpf/idpf.h 
b/drivers/net/ethernet/intel/idpf/idpf.h
index d87ed50af681..8dea2dd784af 100644
--- a/drivers/net/ethernet/intel/idpf/idpf.h
+++ b/drivers/net/ethernet/intel/idpf/idpf.h
@@ -526,7 +526,7 @@ struct idpf_vc_xn_manager;
  * @crc_enable: Enable CRC insertion offload
  * @req_tx_splitq: TX split or single queue model to request
  * @req_rx_splitq: RX split or single queue model to request
- * @vport_ctrl_lock: Lock to protect the vport control flow
+ * @vport_cfg_lock: Lock to protect the vport config flow
  * @vector_lock: Lock to protect vector distribution
  * @queue_lock: Lock to protect queue distribution
  * @vc_buf_lock: Lock to protect virtchnl buffer
@@ -583,7 +583,7 @@ struct idpf_adapter {
bool req_tx_splitq;
bool req_rx_splitq;
 
-   struct mutex vport_ctrl_lock;
+   struct mutex vport_cfg_lock;
struct mutex vector_lock;
struct mutex queue_lock;
struct mutex vc_buf_lock;
@@ -787,24 +787,24 @@ static inline u16 idpf_get_max_tx_hdr_size(struct 
idpf_adapter *adapter)
 }
 
 /**
- * idpf_vport_ctrl_lock - Acquire the vport control lock
+ * idpf_vport_cfg_lock - Acquire the vport config lock
  * @adapter: private data struct
  *
  * This lock should be used by non-datapath code to protect against vport
  * destruction.
  */
-static inline void idpf_vport_ctrl_lock(struct idpf_adapter *adapter)
+static inline void idpf_vport_cfg_lock(struct idpf_adapter *adapter)
 {
-   mutex_lock(&adapter->vport_ctrl_lock);
+   mutex_lock(&adapter->vport_cfg_lock);
 }
 
 /**
- * idpf_vport_ctrl_unlock - Release the vport control lock
+ * idpf_vport_cfg_unlock - Release the vport config lock
  * @adapter: private data struct
  */
-static inline void idpf_vport_ctrl_unlock(struct idpf_adapter *adapter)
+static inline void idpf_vport_cfg_unlock(struct idpf_adapter *adapter)
 {
-   mutex_unlock(&adapter->vport_ctrl_lock);
+   mutex_unlock(&adapter->vport_cfg_lock);
 }
 
 void idpf_statistics_task(struct work_struct *work);
diff --git a/drivers/net/ethernet/intel/idpf/idpf_ethtool.c 
b/drivers/net/ethernet/intel/idpf/idpf_ethtool.c
index e5ac3e5a50ce..b3ed1d9a80ae 100644
--- a/drivers/net/ethernet/intel/idpf/idpf_ethtool.c
+++ b/drivers/net/ethernet/intel/idpf/idpf_ethtool.c
@@ -17,20 +17,20 @@ static int idpf_get_rxnfc(struct net_device *netdev, struct 
ethtool_rxnfc *cmd,
struct idpf_adapter *adapter = idpf_netdev_to_adapter(netdev);
struct idpf_vport *vport;
 
-   idpf_vport_ctrl_lock(adapter);
+   idpf_vport_cfg_lock(adapter);
vport = idpf_netdev_to_vport(netdev);
 
switch (cmd->cmd) {
case ETHTOOL_GRXRINGS:
cmd->data = vport->num_rxq;
-   idpf_vport_ctrl_unlock(adapter);
+   idpf_vport_cfg_unlock(adapter);
 
return 0;
default:
break;
}
 
-   idpf_vport_ctrl_unlock(adapter);
+   idpf_vport_cfg_unlock(adapter);
 
return -EOPNOTSUPP;
 }
@@ -90,7 +90,7 @@ static int idpf_get_rxfh(struct net_device *netdev,
u16 i;
 
adapter = np->adapter;
-   idpf_vport_ctrl_lock(adapter);
+   idpf_vport_cfg_lock(adapter);
 
if (!idpf_is_cap_ena_all(adapter, IDPF_RSS_CAPS, IDPF_CAP_RSS)) {
err = -EOPNOTSUPP;
@@ -112,7 +112,7 @@ static int idpf_get_rxfh(struct net_device *netdev,
}
 
 unlock_mutex:
-   idpf_vport_ctrl_unlock(adapter);
+   idpf_vport_cfg_unlock(adapter);
 
return err;
 }
@@ -137,7 +137,7 @@ static int idpf_set_rxfh(struct net_device *netdev,
int err = 0;
u16 lut;
 
-   idpf_vport_ctrl_lock(adapter);
+   idpf_vport_cfg_lock(adapter);
vport = idpf_netdev_to_vport(netdev);
 
if (!idpf_is_cap_ena_all(adapter, IDPF_RSS_CAPS, IDPF_CAP_RSS)) {
@@ -166,7 +166,7 @@ static int idpf_set_rxfh(struct net_device *netdev,
err = idpf_config_rss(vport);
 
 unlock_mutex:
-   idpf_vport_ctrl_unlock(adapter);
+   idpf_vport_cfg_unlock(adapter);
 
return err;
 }
@@ -234,7 +234,7 @@ static int idpf_set_channels(struct net_device *netdev,
return -EINVAL;
}
 
-   idpf_vport_ctrl_lock(adapter);
+   idpf_vport_cfg_lock(adapter);
vport = idpf_netdev_to_vport(netdev);
 
idx = vport->idx;
@@ -278,7 +278,7 @@ static int idpf_set_channels(struct net_device *netdev,
}
 
 unlock_mutex:
-   idpf_vport_ctrl_unlock(adapter);
+   idpf_vport_cfg_un

[Intel-wired-lan] [tnguy-net-queue:100GbE] BUILD SUCCESS b8473723272e346e22aa487b9046fd324b73a0a5

[kernel test robot]

tree/branch: 
https://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue.git 100GbE
branch HEAD: b8473723272e346e22aa487b9046fd324b73a0a5  e1000e: Remove Meteor 
Lake SMBUS workarounds

elapsed time: 1456m

configs tested: 147
configs skipped: 4

The following configs have been built successfully.
More configs may be tested in the coming days.

tested configs:
alpha allnoconfiggcc-13.3.0
alphaallyesconfiggcc-13.3.0
arc  allmodconfiggcc-13.2.0
arc   allnoconfiggcc-13.2.0
arc  allyesconfiggcc-13.2.0
archsdk_defconfiggcc-13.2.0
arc   randconfig-001-20241105gcc-13.2.0
arc   randconfig-002-20241105gcc-13.2.0
arm  allmodconfiggcc-14.1.0
arm   allnoconfigclang-20
arm  allyesconfiggcc-14.1.0
arm axm55xx_defconfigclang-20
arm   randconfig-001-20241105gcc-14.1.0
arm   randconfig-002-20241105clang-20
arm   randconfig-003-20241105gcc-14.1.0
arm   randconfig-004-20241105clang-16
arm   sama5_defconfiggcc-14.1.0
armshmobile_defconfiggcc-14.1.0
arm64allmodconfigclang-20
arm64 allnoconfiggcc-14.1.0
arm64 randconfig-001-20241105gcc-14.1.0
arm64 randconfig-002-20241105gcc-14.1.0
arm64 randconfig-003-20241105gcc-14.1.0
arm64 randconfig-004-20241105gcc-14.1.0
csky  allnoconfiggcc-14.1.0
csky  randconfig-001-20241105gcc-14.1.0
csky  randconfig-002-20241105gcc-14.1.0
hexagon  allmodconfigclang-20
hexagon   allnoconfigclang-20
hexagon  allyesconfigclang-20
hexagon   randconfig-001-20241105clang-20
hexagon   randconfig-002-20241105clang-20
i386 allmodconfiggcc-12
i386  allnoconfiggcc-12
i386 allyesconfiggcc-12
i386buildonly-randconfig-001-20241105clang-19
i386buildonly-randconfig-002-20241105gcc-12
i386buildonly-randconfig-003-20241105clang-19
i386buildonly-randconfig-004-20241105gcc-12
i386buildonly-randconfig-005-20241105clang-19
i386buildonly-randconfig-006-20241105gcc-12
i386defconfigclang-19
i386  randconfig-001-20241105gcc-12
i386  randconfig-002-20241105clang-19
i386  randconfig-003-20241105gcc-12
i386  randconfig-004-20241105clang-19
i386  randconfig-005-20241105clang-19
i386  randconfig-006-20241105gcc-12
i386  randconfig-011-20241105clang-19
i386  randconfig-012-20241105clang-19
i386  randconfig-013-20241105gcc-12
i386  randconfig-014-20241105gcc-12
i386  randconfig-015-20241105gcc-12
i386  randconfig-016-20241105gcc-12
loongarchallmodconfiggcc-14.1.0
loongarch allnoconfiggcc-14.1.0
loongarch randconfig-001-20241105gcc-14.1.0
loongarch randconfig-002-20241105gcc-14.1.0
m68k allmodconfiggcc-14.1.0
m68k  allnoconfiggcc-14.1.0
m68k allyesconfiggcc-14.1.0
m68k   m5249evb_defconfiggcc-14.1.0
microblaze   allmodconfiggcc-14.1.0
microblazeallnoconfiggcc-14.1.0
microblaze   allyesconfiggcc-14.1.0
mips  allnoconfiggcc-14.1.0
mipsvocore2_defconfigclang-15
nios2 allnoconfiggcc-14.1.0
nios2 randconfig-001-20241105gcc-14.1.0
nios2 randconfig-002-20241105gcc-14.1.0
openrisc  allnoconfiggcc-14.1.0
openrisc allyesconfiggcc-14.1.0
openriscor1ksim_defconfiggcc-14.1.0
parisc   allmodconfiggcc-14.1.0
pariscallnoconfiggcc-14.1.0
parisc   allyesconfiggcc-14.1.0
pariscrandconfig-001-20241105gcc-14.1.0
pariscrandconfig-002-20241105gcc-14.1.0
powerpc

Re: [Intel-wired-lan] [External] : Re: [PATCH iwl-net 2/2] ixgbe: downgrade logging of unsupported VF API version to debug

[Yifei Liu]

Hi Paul and Jake, 
Please see inline. 

> On Nov 1, 2024, at 11:53 PM, Paul Menzel  wrote:
> 
> Dear Jacob,
> 
> 
> Thank you for the patch.
> 
> Am 02.11.24 um 00:05 schrieb Jacob Keller:
>> The ixgbe PF driver logs an info message when a VF attempts to negotiate an
>> API version which it does not support:
>>   VF 0 requested invalid api version 6
>> The ixgbevf driver attempts to load with mailbox API v1.5, which is
>> required for best compatibility with other hosts such as the ESX VMWare PF.
>> The Linux PF only supports API v1.4, and does not currently have support
>> for the v1.5 API.
>> The logged message can confuse users, as the v1.5 API is valid, but just
>> happens to not currently be supported by the Linux PF.
>> Downgrade the info message to a debug message, and fix the language to
>> use 'unsupported' instead of 'invalid' to improve message clarity.
>> Long term, we should investigate whether the improvements in the v1.5 API
>> make sense for the Linux PF, and if so implement them properly. This may
>> require yet another API version to resolve issues with negotiating IPSEC
>> offload support.
> 
> It’d be great if you described the exact test setup for how to reproduce it.
It could be easily reproduced by running
echo 1 > /sys/class/net/device/sriov_numvfs
> 
>> Reported-by: Yifei Liu 
> 
> Do you have an Link: for this report?
Hope this link could help: 
https://patchwork.kernel.org/project/netdevbpf/patch/20240301235837.3741422-1-yifei.l@oracle.com/
 
> 
>> Signed-off-by: Jacob Keller 
>> Reviewed-by: Przemek Kitszel 
>> ---
>>  drivers/net/ethernet/intel/ixgbe/ixgbe_common.h | 2 ++
>>  drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c  | 2 +-
>>  2 files changed, 3 insertions(+), 1 deletion(-)
>> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h 
>> b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h
>> index 6493abf189de..6639069ad528 100644
>> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h
>> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h
>> @@ -194,6 +194,8 @@ u32 ixgbe_read_reg(struct ixgbe_hw *hw, u32 reg);
>>   dev_err(&adapter->pdev->dev, format, ## arg)
>>  #define e_dev_notice(format, arg...) \
>>   dev_notice(&adapter->pdev->dev, format, ## arg)
>> +#define e_dbg(msglvl, format, arg...) \
>> + netif_dbg(adapter, msglvl, adapter->netdev, format, ## arg)
>>  #define e_info(msglvl, format, arg...) \
>>   netif_info(adapter, msglvl, adapter->netdev, format, ## arg)
>>  #define e_err(msglvl, format, arg...) \
>> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c 
>> b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
>> index e71715f5da22..20415c1238ef 100644
>> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
>> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
>> @@ -1047,7 +1047,7 @@ static int ixgbe_negotiate_vf_api(struct ixgbe_adapter 
>> *adapter,
>>   break;
>>   }
>>  - e_info(drv, "VF %d requested invalid api version %u\n", vf, api);
>> + e_dbg(drv, "VF %d requested unsupported api version %u\n", vf, api);
> 
> Is there a way to translate `api` to the API version scheme used in the 
> commit message? So, 1.5 instead of 6? Maybe also add, that only the v1.4 API 
> is supported?
> 
>> return -1;
>>  }
> 
> 
> Kind regards,
> 
> Paul
Thanks
Yifei

Re: [Intel-wired-lan] [PATCH] Revert "igb: Disable threaded IRQ for igb_msix_other"

[Jakub Kicinski]

On Mon,  4 Nov 2024 09:40:50 -0300 Wander Lairson Costa wrote:
> This reverts commit 338c4d3902feb5be49bfda530a72c7ab860e2c9f.
> 
> Sebastian noticed the ISR indirectly acquires spin_locks, which are
> sleeping locks under PREEMPT_RT, which leads to kernel splats.
> 
> Signed-off-by: Wander Lairson Costa 
> Reported-by: Sebastian Andrzej Siewior 

Please resend with the reverted commit added as a Fixes tag.
Also - your sign off should be the last tag.
-- 
pw-bot: au

Re: [Intel-wired-lan] [PATCH net-next v3 1/2] ptp: add control over HW timestamp latch point

[Jakub Kicinski]

On Wed,  6 Nov 2024 02:07:55 +0100 Arkadiusz Kubalewski wrote:
> +What:/sys/class/ptp/ptp/ts_point
> +Date:October 2024
> +Contact: Arkadiusz Kubalewski 
> +Description:
> + This file provides control over the point in time in
> + which the HW timestamp is latched. As specified in IEEE
> + 802.3cx, the latch point can be either at the beginning
> + or after the end of Start of Frame Delimiter (SFD).
> + Value "1" means the timestamp is latched at the
> + beginning of the SFD. Value "2" means that timestamp is
> + latched after the end of SFD.

Richard has the final say but IMO packet timestamping config does not
belong to the PHC, rather ndo_hwtstamp_set.

Re: [Intel-wired-lan] [PATCH net-next v2 0/2] ptp: add control over HW timestamp latch point

[Kubalewski, Arkadiusz]

>From: Intel-wired-lan  On Behalf Of
>Vadim Fedorenko
>Sent: Tuesday, October 29, 2024 5:17 PM
>
>On 29/10/2024 15:56, Kubalewski, Arkadiusz wrote:
>>> From: Vadim Fedorenko 
>>> Sent: Tuesday, October 29, 2024 12:30 PM
>>>
>>> On 28/10/2024 20:47, Arkadiusz Kubalewski wrote:
 HW support of PTP/timesync solutions in network PHY chips can be
 achieved with two different approaches, the timestamp maybe latched
 either in the beginning or after the Start of Frame Delimiter (SFD)
[1].

 Allow ptp device drivers to provide user with control over the
 timestamp latch point.

 [1] https://www.ieee802.org/3/cx/public/april20/tse_3cx_01_0420.pdf
>>>
>>> I just wonder should we add ethtool interface to control this feature.
>>> As we are adding it for phy devices, it's good idea to have a way to
>>> control it through eth device too. WDYT?
>>
>> Seems doable, I guess somehow expand the controllability being added
>> right now with this series:
>> https://lore.kernel.org/netdev/20241023-feature_ptp_netnext-v18-0-ed94
>> 8f3b6...@bootlin.com/#r
>> Or some other idea?
>
>Yeah, the series mentioned correlates with your work, that's why I asked
>about it.
>It would be great to be sure that the interface you are proposing can be
>reused or somehow combined with the series.

Sure, I did some modifications to allow this extension in the future, as
this is still being developed.

Thank you!
Arkadiusz

Re: [Intel-wired-lan] [PATCH net-next v2 1/2] ptp: add control over HW timestamp latch point

[Kubalewski, Arkadiusz]

>From: Kitszel, Przemyslaw 
>Sent: Tuesday, October 29, 2024 9:25 AM
>Subject: Re: [PATCH net-next v2 1/2] ptp: add control over HW timestamp
>latch point
>
>On 10/28/24 21:47, Arkadiusz Kubalewski wrote:
>> Currently HW support of PTP/timesync solutions in network PHY chips
>> can be implemented with two different approaches, the timestamp maybe
>> latched either at the beginning or after the Start of Frame Delimiter
>>(SFD) [1].
>>
>> Allow ptp device drivers to provide user with control over the HW
>> timestamp latch point with ptp sysfs ABI. Provide a new file under
>> sysfs ptp device (/sys/class/ptp/ptp/ts_point). The file is
>> available for the user, if the device driver implements at least one
>> of newly provided callbacks. If the file is not provided the user
>> shall find a PHY timestamp latch point within the HW vendor
>>specification.
>>
>> The file is designed for root user/group access only, as the read for
>> regular user could impact performance of the ptp device.
>>
>> Usage, examples:
>>
>> ** Obtain current state:
>> $ cat /sys/class/ptp/ptp/ts_point
>> Command returns enum/integer:
>> * 0 - timestamp latched by PHY at the beginning of SFD,
>> * 1 - timestamp latched by PHY after the SFD,
>> * None - callback returns error to the user.
>>
>> ** Configure timestamp latch point at the beginning of SFD:
>> $ echo 0 > /sys/class/ptp/ptp/ts_point
>>
>> ** Configure timestamp latch point after the SFD:
>> $ echo 1 > /sys/class/ptp/ptp/ts_point
>>
>> [1] https://www.ieee802.org/3/cx/public/april20/tse_3cx_01_0420.pdf
>>
>> Reviewed-by: Aleksandr Loktionov 
>> Signed-off-by: Arkadiusz Kubalewski 
>
>[...]
>
>> diff --git a/include/linux/ptp_clock_kernel.h
>> b/include/linux/ptp_clock_kernel.h
>> index c892d22ce0a7..ea1bcca7f7f6 100644
>> --- a/include/linux/ptp_clock_kernel.h
>> +++ b/include/linux/ptp_clock_kernel.h
>> @@ -55,6 +55,24 @@ struct ptp_system_timestamp {
>>  clockid_t clockid;
>>   };
>>
>> +/**
>> + * enum ptp_ts_point - possible timestamp latch points (IEEE 802.3cx)
>> + *
>> + * @PTP_TS_POINT_SFD: timestamp latched at the beginning of sending
>Start
>> + *of Frame Delimiter (SFD)
>> + * @PTP_TS_POINT_POST_SFD: timestamp latched after the end of sending
>Start
>> + * of Frame Delimiter (SFD)
>> + */
>> +enum ptp_ts_point {
>> +PTP_TS_POINT_SFD,
>> +PTP_TS_POINT_POST_SFD,
>> +
>> +/* private: */
>> +__PTP_TS_POINT_MAX
>> +};
>> +
>> +#define PTP_TS_POINT_MAX (__PTP_TS_POINT_MAX - 1)
>
>I would move PTP_TS_POINT_MAX into the enum
>

Fixed in v3.

Thank you!
Arkadiusz

[Intel-wired-lan] [PATCH net-next v3 1/2] ptp: add control over HW timestamp latch point

[Arkadiusz Kubalewski]

Currently HW support of ptp/timesync solutions in network PHY chips can be
implemented with two different approaches, the timestamp maybe latched
either at the beginning or after the Start of Frame Delimiter (SFD) [1].

Allow ptp device drivers to provide user with control over the HW
timestamp latch point with ptp sysfs ABI. Provide a new file under sysfs
ptp device (/sys/class/ptp/ptp/ts_point). The file is available for the
user, if the device driver implements at least one of newly provided
callbacks. If the file is not provided the user shall find a PHY timestamp
latch point within the HW vendor specification.

The file is designed for root user/group access only, as the read for
regular user could impact performance of the ptp device.

Usage, examples:

** Obtain current state:
$ cat /sys/class/ptp/ptp/ts_point
Command returns enum/integer:
* 1 - timestamp latched by PHY at the beginning of SFD,
* 2 - timestamp latched by PHY after the SFD,
* None - callback returns error to the user.

** Configure timestamp latch point at the beginning of SFD:
$ echo 1 > /sys/class/ptp/ptp/ts_point

** Configure timestamp latch point after the SFD:
$ echo 2 > /sys/class/ptp/ptp/ts_point

[1] https://www.ieee802.org/3/cx/public/april20/tse_3cx_01_0420.pdf

Reviewed-by: Aleksandr Loktionov 
Signed-off-by: Arkadiusz Kubalewski 
---
v3:
- max value of enum ptp_ts_point is also enumerated,
- move enum ptp_ts_point to uapi,
- add NONE value to enum ptp_ts_point, to make clear that value was
  not provided, thus allow further extension of ethtool netlink.
---
 Documentation/ABI/testing/sysfs-ptp | 12 
 drivers/ptp/ptp_sysfs.c | 44 +
 include/linux/ptp_clock_kernel.h| 12 
 include/uapi/linux/ptp_clock.h  | 18 
 4 files changed, 86 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-ptp 
b/Documentation/ABI/testing/sysfs-ptp
index 9c317ac7c47a..063b3e20386e 100644
--- a/Documentation/ABI/testing/sysfs-ptp
+++ b/Documentation/ABI/testing/sysfs-ptp
@@ -140,3 +140,15 @@ Description:
PPS events to the Linux PPS subsystem. To enable PPS
events, write a "1" into the file. To disable events,
write a "0" into the file.
+
+What:  /sys/class/ptp/ptp/ts_point
+Date:  October 2024
+Contact:   Arkadiusz Kubalewski 
+Description:
+   This file provides control over the point in time in
+   which the HW timestamp is latched. As specified in IEEE
+   802.3cx, the latch point can be either at the beginning
+   or after the end of Start of Frame Delimiter (SFD).
+   Value "1" means the timestamp is latched at the
+   beginning of the SFD. Value "2" means that timestamp is
+   latched after the end of SFD.
diff --git a/drivers/ptp/ptp_sysfs.c b/drivers/ptp/ptp_sysfs.c
index 6b1b8f57cd95..2f3f28edbbfd 100644
--- a/drivers/ptp/ptp_sysfs.c
+++ b/drivers/ptp/ptp_sysfs.c
@@ -28,6 +28,46 @@ static ssize_t max_phase_adjustment_show(struct device *dev,
 }
 static DEVICE_ATTR_RO(max_phase_adjustment);
 
+static ssize_t ts_point_show(struct device *dev, struct device_attribute *attr,
+char *page)
+{
+   struct ptp_clock *ptp = dev_get_drvdata(dev);
+   enum ptp_ts_point point;
+   int err;
+
+   if (!ptp->info->get_ts_point)
+   return -EOPNOTSUPP;
+   err = ptp->info->get_ts_point(ptp->info, &point);
+   if (err)
+   return err;
+
+   return sysfs_emit(page, "%d\n", point);
+}
+
+static ssize_t ts_point_store(struct device *dev, struct device_attribute 
*attr,
+ const char *buf, size_t count)
+{
+   struct ptp_clock *ptp = dev_get_drvdata(dev);
+   enum ptp_ts_point point;
+   int err;
+   u8 val;
+
+   if (!ptp->info->set_ts_point)
+   return -EOPNOTSUPP;
+   if (kstrtou8(buf, 0, &val))
+   return -EINVAL;
+   if (val <= PTP_TS_POINT_NONE || val > PTP_TS_POINT_MAX)
+   return -EINVAL;
+   point = val;
+
+   err = ptp->info->set_ts_point(ptp->info, point);
+   if (err)
+   return err;
+
+   return count;
+}
+static DEVICE_ATTR(ts_point, 0660, ts_point_show, ts_point_store);
+
 #define PTP_SHOW_INT(name, var)
\
 static ssize_t var##_show(struct device *dev,  \
   struct device_attribute *attr, char *page)   \
@@ -335,6 +375,7 @@ static struct attribute *ptp_attrs[] = {
&dev_attr_pps_enable.attr,
&dev_attr_n_vclocks.attr,
&dev_attr_max_vclocks.attr,
+   &dev_attr_ts_point.attr,
NULL
 };
 
@@ -363,6 +404,9 @@ static umode_t ptp_is_attribute_visible(struct kobject 
*kobj,
} else if (attr == &dev_attr_max_phase_adjustment.attr) {
if (!info->adjphase || !info->getmaxphase)

[Intel-wired-lan] [PATCH net-next v3 2/2] ice: ptp: add control over HW timestamp latch point

[Arkadiusz Kubalewski]

Allow user to control the latch point of ptp HW timestamps in E825
devices.

Usage, examples:

** Obtain current state:
$ cat /sys/class/net/eth/device/ptp/ts_point
Command returns enum/integer:
* 1 - timestamp latched by PHY at the beginning of SFD,
* 2 - timestamp latched by PHY after the SFD,
* None - callback returns error to the user.

** Configure timestamp latch point at the beginning of SFD:
$ echo 1 > /sys/class/net/eth/device/ptp/ts_point

** Configure timestamp latch point after the SFD:
$ echo 2 > /sys/class/net/eth/device/ptp/ts_point

Reviewed-by: Aleksandr Loktionov 
Signed-off-by: Arkadiusz Kubalewski 
---
v3:
- improve readability, for "nothing to do" logic
- /s/PTP/ptp
- remove 'tx' from docs description
---
 drivers/net/ethernet/intel/ice/ice_ptp.c| 44 +++
 drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 60 +
 drivers/net/ethernet/intel/ice/ice_ptp_hw.h |  2 +
 3 files changed, 106 insertions(+)

diff --git a/drivers/net/ethernet/intel/ice/ice_ptp.c 
b/drivers/net/ethernet/intel/ice/ice_ptp.c
index a999fface272..c351c9707394 100644
--- a/drivers/net/ethernet/intel/ice/ice_ptp.c
+++ b/drivers/net/ethernet/intel/ice/ice_ptp.c
@@ -2509,6 +2509,48 @@ static int ice_ptp_parse_sdp_entries(struct ice_pf *pf, 
__le16 *entries,
return 0;
 }
 
+/**
+ * ice_get_ts_point - get the timestamp latch point
+ * @info: the driver's ptp info structure
+ * @point: returns the configured timestamp latch point
+ *
+ * Return: 0 on success, negative on failure.
+ */
+static int ice_get_ts_point(struct ptp_clock_info *info,
+   enum ptp_ts_point *point)
+{
+   struct ice_pf *pf = ptp_info_to_pf(info);
+   struct ice_hw *hw = &pf->hw;
+   int ret;
+
+   ice_ptp_lock(hw);
+   ret = ice_ptp_hw_ts_point_get(hw, point);
+   ice_ptp_unlock(hw);
+
+   return ret;
+}
+
+/**
+ * ice_set_ts_point - set the timestamp latch point
+ * @info: the driver's ptp info structure
+ * @point: requested timestamp latch point
+ *
+ * Return: 0 on success, negative on failure.
+ */
+static int ice_set_ts_point(struct ptp_clock_info *info,
+   enum ptp_ts_point point)
+{
+   struct ice_pf *pf = ptp_info_to_pf(info);
+   struct ice_hw *hw = &pf->hw;
+   int ret;
+
+   ice_ptp_lock(hw);
+   ret = ice_ptp_hw_ts_point_set(hw, point);
+   ice_ptp_unlock(hw);
+
+   return ret;
+}
+
 /**
  * ice_ptp_set_funcs_e82x - Set specialized functions for E82X support
  * @pf: Board private structure
@@ -2529,6 +2571,8 @@ static void ice_ptp_set_funcs_e82x(struct ice_pf *pf)
if (ice_is_e825c(&pf->hw)) {
pf->ptp.ice_pin_desc = ice_pin_desc_e825c;
pf->ptp.info.n_pins = ICE_PIN_DESC_ARR_LEN(ice_pin_desc_e825c);
+   pf->ptp.info.set_ts_point = ice_set_ts_point;
+   pf->ptp.info.get_ts_point = ice_get_ts_point;
} else {
pf->ptp.ice_pin_desc = ice_pin_desc_e82x;
pf->ptp.info.n_pins = ICE_PIN_DESC_ARR_LEN(ice_pin_desc_e82x);
diff --git a/drivers/net/ethernet/intel/ice/ice_ptp_hw.c 
b/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
index dfd49732bd5b..06c32f180932 100644
--- a/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
+++ b/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
@@ -6320,3 +6320,63 @@ int ice_cgu_get_output_pin_state_caps(struct ice_hw *hw, 
u8 pin_id,
 
return 0;
 }
+
+/**
+ * ice_ptp_hw_ts_point_get - check if timestamps are latched on/post SFD
+ * @hw: pointer to the HW struct
+ * @point: return the configured timestamp latch point
+ *
+ * Verify if HW timestamping point is configured to latch at the beginning or
+ * post of SFD (Start of Frame Delimiter)
+ *
+ * Return: 0 on success, negative on error
+ */
+int ice_ptp_hw_ts_point_get(struct ice_hw *hw, enum ptp_ts_point *point)
+{
+   u8 port = hw->port_info->lport;
+   u32 val;
+   int err;
+
+   err = ice_read_mac_reg_eth56g(hw, port, PHY_MAC_XIF_MODE, &val);
+   if (err)
+   return err;
+   if (val & PHY_MAC_XIF_TS_SFD_ENA_M)
+   *point = PTP_TS_POINT_SFD;
+   else
+   *point = PTP_TS_POINT_POST_SFD;
+
+   return err;
+}
+
+/**
+ * ice_ptp_hw_ts_point_set - configure timestamping on/post SFD
+ * @hw: pointer to the HW struct
+ * @point: requested timestamp latch point
+ *
+ * Configure timestamping to measure at the beginning/post SFD (Start of Frame
+ * Delimiter)
+ *
+ * Return: 0 on success, negative on error
+ */
+int ice_ptp_hw_ts_point_set(struct ice_hw *hw, enum ptp_ts_point point)
+{
+   u8 port = hw->port_info->lport;
+   int err, val;
+
+   err = ice_read_mac_reg_eth56g(hw, port, PHY_MAC_XIF_MODE, &val);
+   if (err)
+   return err;
+   if ((val & PHY_MAC_XIF_TS_SFD_ENA_M) && point == PTP_TS_POINT_SFD)
+   return -EINVAL;
+   if (!(val & PHY_MAC_XIF_TS_SFD_ENA_M) &&
+   point == PTP_TS_POINT_POST_SFD)
+

[Intel-wired-lan] [PATCH net-next v3 0/2] ptp: add control over HW timestamp latch point

[Arkadiusz Kubalewski]

HW support of ptp/timesync solutions in network PHY chips can be
achieved with two different approaches, the timestamp maybe latched
either in the beginning or after the Start of Frame Delimiter (SFD) [1].

Allow ptp device drivers to provide user with control over the timestamp
latch point.

[1] https://www.ieee802.org/3/cx/public/april20/tse_3cx_01_0420.pdf

v3:
- move new enum ptp_ts_point to uapi ptp_clock.h and add NONE value to
  indicate that the timestamp latch point was not provided by the HW,
  allow further changes to ethtool netlink interface exstensions.

Arkadiusz Kubalewski (2):
  ptp: add control over HW timestamp latch point
  ice: ptp: add control over HW timestamp latch point

 Documentation/ABI/testing/sysfs-ptp | 12 +
 drivers/net/ethernet/intel/ice/ice_ptp.c| 44 +++
 drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 60 +
 drivers/net/ethernet/intel/ice/ice_ptp_hw.h |  2 +
 drivers/ptp/ptp_sysfs.c | 44 +++
 include/linux/ptp_clock_kernel.h| 12 +
 include/uapi/linux/ptp_clock.h  | 18 +++
 7 files changed, 192 insertions(+)

base-commit: 0452a2d8b8b98a5b1a9139c1a9ed98bccee356cc
-- 
2.38.1

Re: [Intel-wired-lan] [PATCH net-next v2 2/2] ice: ptp: add control over HW timestamp latch point

[Kubalewski, Arkadiusz]

>From: Kitszel, Przemyslaw 
>Sent: Tuesday, October 29, 2024 9:22 AM
>
>On 10/28/24 21:47, Arkadiusz Kubalewski wrote:
>> Allow user to control the latch point of ptp HW timestamps in E825
>
>sometimes you write ptp, sometimes PTP, I would make it consistent
>(but subject line is fine as is)
>
>> devices.
>>
>> Usage, examples:
>>
>> ** Obtain current state:
>> $ cat /sys/class/net/eth/device/ptp/ts_point
>> Command returns enum/integer:
>> * 0 - timestamp latched by PHY at the beginning of SFD,
>> * 1 - timestamp latched by PHY after the SFD,
>
>perhaps those values could be exported to uAPI?
>(the enum from the prev patch)
>+enum ptp_ts_point {
>+  PTP_TS_POINT_SFD,
>+  PTP_TS_POINT_POST_SFD,
>
>> * None - callback returns error to the user.
>>
>> ** Configure timestamp latch point at the beginning of SFD:
>> $ echo 0 > /sys/class/net/eth/device/ptp/ts_point
>>
>> ** Configure timestamp latch point after the SFD:
>> $ echo 1 > /sys/class/net/eth/device/ptp/ts_point
>>
>> Reviewed-by: Aleksandr Loktionov 
>> Signed-off-by: Arkadiusz Kubalewski 
>
>general ask: for future submissions please use --base switch of
>git-send-email, this will aid resolving conflicts or applying the patch
>locally for review;
>
>this series in particular would likely conflicts with current
>Tony's dev-queue (didn't checked, but Karol removes ice_is_e825c(),
>called within 3-line context of your changes).
>
>> ---
>> v2:
>> - add kernel doc return description on ice_get_ts_point(..),
>> - use enum ptp_ts_point directly, instead of additional bool to pass tx
>>timestamp latch point from userspace callback up to ptp_hw
>>configuration,
>> - fix bit logic.
>> ---
>>   drivers/net/ethernet/intel/ice/ice_ptp.c| 44 +++
>>   drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 59 +
>>   drivers/net/ethernet/intel/ice/ice_ptp_hw.h |  2 +
>>   3 files changed, 105 insertions(+)
>>
>> diff --git a/drivers/net/ethernet/intel/ice/ice_ptp.c
>b/drivers/net/ethernet/intel/ice/ice_ptp.c
>> index a999fface272..21fc6b5e2d69 100644
>> --- a/drivers/net/ethernet/intel/ice/ice_ptp.c
>> +++ b/drivers/net/ethernet/intel/ice/ice_ptp.c
>> @@ -2509,6 +2509,48 @@ static int ice_ptp_parse_sdp_entries(struct ice_pf
>>*pf, __le16 *entries,
>>  return 0;
>>   }
>>
>> +/**
>> + * ice_get_ts_point - get the tx timestamp latch point
>
>Tx, please apply in the whole patch
>
>> + * @info: the driver's PTP info structure
>> + * @point: return the configured tx timestamp latch point
>> + *
>> + * Return: 0 on success, negative on failure.
>> + */
>> +static int
>> +ice_get_ts_point(struct ptp_clock_info *info, enum ptp_ts_point *point)
>
>nit: the current preferred style is to break line after "info,"
>
>> +{
>> +struct ice_pf *pf = ptp_info_to_pf(info);
>> +struct ice_hw *hw = &pf->hw;
>> +int ret;
>> +
>> +ice_ptp_lock(hw);
>> +ret = ice_ptp_hw_ts_point_get(hw, point);
>> +ice_ptp_unlock(hw);
>> +
>> +return ret;
>> +}
>
>[...]
>
>> +/**
>> + * ice_ptp_hw_ts_point_set - configure timestamping on/post SFD
>> + * @hw: pointer to the HW struct
>> + * @point: requested tx timestamp latch point
>> + *
>> + * Configure timestamping to measure at the beginning/post SFD (Start of
>> Frame
>> + * Delimiter)
>> + *
>> + * Return: 0 on success, negative on error
>> + */
>> +int ice_ptp_hw_ts_point_set(struct ice_hw *hw, enum ptp_ts_point point)
>> +{
>> +u8 port = hw->port_info->lport;
>> +int err, val;
>> +
>> +err = ice_read_mac_reg_eth56g(hw, port, PHY_MAC_XIF_MODE, &val);
>> +if (err)
>> +return err;
>> +if ((val & PHY_MAC_XIF_TS_SFD_ENA_M && point == PTP_TS_POINT_SFD) ||
>> +(!(val & PHY_MAC_XIF_TS_SFD_ENA_M) &&
>> + point == PTP_TS_POINT_POST_SFD))
>
>that's the thing that urged me to start commenting on this patch ;)
>
>put braces around (bit & arith) combined with logical && or ||
>
>you could also split into multiple if branches for readability
>
>> +return -EINVAL;
>> +if (point == PTP_TS_POINT_SFD)
>> +val |= PHY_MAC_XIF_TS_SFD_ENA_M;
>> +else if (point == PTP_TS_POINT_POST_SFD)
>> +val &= ~PHY_MAC_XIF_TS_SFD_ENA_M;
>> +else
>> +return -EINVAL;
>> +
>> +return ice_write_mac_reg_eth56g(hw, port, PHY_MAC_XIF_MODE, val);
>> +}
>> diff --git a/drivers/net/ethernet/intel/ice/ice_ptp_hw.h
>>b/drivers/net/ethernet/intel/ice/ice_ptp_hw.h
>> index 656daff3447e..f8e495b82653 100644
>> --- a/drivers/net/ethernet/intel/ice/ice_ptp_hw.h
>> +++ b/drivers/net/ethernet/intel/ice/ice_ptp_hw.h
>> @@ -348,6 +348,8 @@ void ice_ptp_init_hw(struct ice_hw *hw);
>>   int ice_get_phy_tx_tstamp_ready(struct ice_hw *hw, u8 block, u64
>>*tstamp_ready);
>>   int ice_ptp_one_port_cmd(struct ice_hw *hw, u8 configured_port,
>>   enum ice_ptp_tmr_cmd configured_cmd);
>> +int ice_ptp_hw_ts_point_get(struct ice_hw *hw, enum ptp_ts_point
>>*point);
>> +int ice_ptp_hw_ts_point_set(struct ice_hw *

[Intel-wired-lan] [tnguy-net-queue:200GbE] BUILD SUCCESS 9eaff63bfb59b93a79ac8450e3d1e45a1f72f29a

[kernel test robot]

tree/branch: 
https://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue.git 200GbE
branch HEAD: 9eaff63bfb59b93a79ac8450e3d1e45a1f72f29a  Merge branch 
'net-ethernet-ti-am65-cpsw-fixes-to-multi-queue-rx-feature'

elapsed time: 935m

configs tested: 212
configs skipped: 7

The following configs have been built successfully.
More configs may be tested in the coming days.

tested configs:
alpha allnoconfiggcc-14.1.0
alpha allnoconfiggcc-14.2.0
alphaallyesconfigclang-20
alpha   defconfiggcc-14.1.0
alpha   defconfiggcc-14.2.0
arc  allmodconfigclang-20
arc   allnoconfiggcc-14.1.0
arc   allnoconfiggcc-14.2.0
arc  allyesconfigclang-20
arc defconfiggcc-14.2.0
arcnsim_700_defconfiggcc-14.1.0
arc   randconfig-001-20241106gcc-14.2.0
arc   randconfig-002-20241106gcc-14.2.0
arm  allmodconfigclang-20
arm   allnoconfiggcc-14.1.0
arm   allnoconfiggcc-14.2.0
arm  allyesconfigclang-20
arm defconfiggcc-14.2.0
arm   imxrt_defconfiggcc-14.2.0
arm mxs_defconfiggcc-14.2.0
arm   omap1_defconfiggcc-14.2.0
arm   randconfig-001-20241106gcc-14.2.0
arm   randconfig-002-20241106gcc-14.2.0
arm   randconfig-003-20241106gcc-14.2.0
arm   randconfig-004-20241106gcc-14.2.0
arm socfpga_defconfiggcc-14.2.0
arm  sp7021_defconfiggcc-14.1.0
armspear6xx_defconfiggcc-14.1.0
arm   spitz_defconfiggcc-14.2.0
arm64allmodconfigclang-20
arm64 allnoconfiggcc-14.1.0
arm64 allnoconfiggcc-14.2.0
arm64   defconfiggcc-14.2.0
arm64 randconfig-001-20241106gcc-14.2.0
arm64 randconfig-002-20241106gcc-14.2.0
arm64 randconfig-003-20241106gcc-14.2.0
arm64 randconfig-004-20241106gcc-14.2.0
csky  allnoconfiggcc-14.1.0
csky  allnoconfiggcc-14.2.0
cskydefconfiggcc-14.2.0
csky  randconfig-001-20241106gcc-14.2.0
csky  randconfig-002-20241106gcc-14.2.0
hexagon  allmodconfigclang-20
hexagon   allnoconfiggcc-14.1.0
hexagon   allnoconfiggcc-14.2.0
hexagon  allyesconfigclang-20
hexagon defconfiggcc-14.2.0
hexagon   randconfig-001-20241106gcc-14.2.0
hexagon   randconfig-002-20241106gcc-14.2.0
i386 allmodconfigclang-19
i386  allnoconfigclang-19
i386 allyesconfigclang-19
i386buildonly-randconfig-001-20241106gcc-12
i386buildonly-randconfig-002-20241106gcc-12
i386buildonly-randconfig-003-20241106gcc-12
i386buildonly-randconfig-004-20241106gcc-12
i386buildonly-randconfig-005-20241106gcc-12
i386buildonly-randconfig-006-20241106gcc-12
i386defconfigclang-19
i386  randconfig-001-20241106gcc-12
i386  randconfig-002-20241106gcc-12
i386  randconfig-003-20241106gcc-12
i386  randconfig-004-20241106gcc-12
i386  randconfig-005-20241106gcc-12
i386  randconfig-006-20241106gcc-12
i386  randconfig-011-20241106gcc-12
i386  randconfig-012-20241106gcc-12
i386  randconfig-013-20241106gcc-12
i386  randconfig-014-20241106gcc-12
i386  randconfig-015-20241106gcc-12
i386  randconfig-016-20241106gcc-12
loongarchallmodconfiggcc-14.1.0
loongarch allnoconfiggcc-14.1.0
loongarch allnoconfiggcc-14.2.0
loongarch   defconfiggcc-14.2.0
loongarch randconfig-001-20241106gcc-14.2.0
loongarch randconfig-002-20241106gcc-14.2.0
m68k allmodconfiggcc-14.1.0
m68k