[{"id":3675755,"web_url":"http://patchwork.ozlabs.org/comment/3675755/","msgid":"<715ae9de-25f4-4496-abb5-9c98ccda5ede@redhat.com>","list_archive_url":null,"date":"2026-04-10T09:34:14","subject":"Re: [Intel-wired-lan] [PATCH iwl-net 3/4] ice: fix ready bitmap\n check for non-E822 devices","submitter":{"id":74657,"url":"http://patchwork.ozlabs.org/api/people/74657/","name":"Petr Oros","email":"poros@redhat.com"},"content":"On 4/8/26 20:46, Jacob Keller wrote:\n> The E800 hardware (apart from E810) has a ready bitmap for the PHY\n> indicating which timestamp slots currently have an outstanding timestamp\n> waiting to be read by software.\n>\n> This bitmap is checked in multiple places using the\n> ice_get_phy_tx_tstamp_ready():\n>\n>   * ice_ptp_process_tx_tstamp() calls it to determine which timestamps to\n>     attempt reading from the PHY\n>   * ice_ptp_tx_tstamps_pending() calls it in a loop at the end of the\n>     miscellaneous IRQ to check if new timestamps came in while the interrupt\n>     handler was executing.\n>   * ice_ptp_maybe_trigger_tx_interrupt() calls it in the auxiliary work task\n>     to trigger a software interrupt in the event that the hardware logic\n>     gets stuck.\n>\n> For E82X devices, multiple PHYs share the same block, and the parameter\n> passed to the ready bitmap is a block number associated with the given\n> port. For E825-C devices, the PHYs have their own independent blocks and do\n> not share, so the parameter passed needs to be the port number. For E810\n> devices, the ice_get_phy_tx_tstamp_ready() always returns all 1s regardless\n> of what port, since this hardware does not have a ready bitmap. Finally,\n> for E830 devices, each PF has its own ready bitmap accessible via register,\n> and the block parameter is unused.\n>\n> The first call correctly uses the Tx timestamp tracker block parameter to\n> check the appropriate timestamp block. This works because the tracker is\n> setup correctly for each timestamp device type.\n>\n> The second two callers behave incorrectly for all device types other than\n> the older E822 devices. They both iterate in a loop using\n> ICE_GET_QUAD_NUM() which is a macro only used by E822 devices. This logic\n> is incorrect for devices other than the E822 devices.\n>\n> For E810 the calls would always return true, causing E810 devices to always\n> attempt to trigger a software interrupt even when they have no reason to.\n> For E830, this results in duplicate work as the ready bitmap is checked\n> once per number of quads. Finally, for E825-C, this results in the pending\n> checks failing to detect timestamps on ports other than the first two.\n>\n> Fix this by introducing a new hardware API function to ice_ptp_hw.c,\n> ice_check_phy_tx_tstamp_ready(). This function will check if any timestamps\n> are available and returns a positive value if any timestamps are pending.\n> For E810, the function always returns false, so that the re-trigger checks\n> never happen. For E830, check the ready bitmap just once. For E82x\n> hardware, check each quad. Finally, for E825-C, check every port.\n>\n> The interface function returns an integer to enable reporting of error code\n> if the driver is unable read the ready bitmap. This enables callers to\n> handle this case properly. The previous implementation assumed that\n> timestamps are available if they failed to read the bitmap. This is\n> problematic as it could lead to continuous software IRQ triggering if the\n> PHY timestamp registers somehow become inaccessible.\n>\n> This change is especially important for E825-C devices, as the missing\n> checks could leave a window open where a new timestamp could arrive while\n> the existing timestamps aren't completed. As a result, the hardware\n> threshold logic would not trigger a new interrupt. Without the check, the\n> timestamp is left unhandled, and new timestamps will not cause an interrupt\n> again until the timestamp is handled. Since both the interrupt check and\n> the backup check in the auxiliary task do not function properly, the device\n> may have Tx timestamps permanently stuck failing on a given port.\n>\n> The faulty checks originate from commit d938a8cca88a (\"ice: Auxbus devices\n> & driver for E822 TS\") and commit 712e876371f8 (\"ice: periodically kick Tx\n> timestamp interrupt\"), however at the time of the original coding, both\n> functions only operated on E822 hardware. This is no longer the case, and\n> hasn't been since the introduction of the ETH56G PHY model in commit\n> 7cab44f1c35f (\"ice: Introduce ETH56G PHY model for E825C products\")\n>\n> Fixes: 7cab44f1c35f (\"ice: Introduce ETH56G PHY model for E825C products\")\n> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>\n> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>\n> ---\n>   drivers/net/ethernet/intel/ice/ice_ptp_hw.h |   1 +\n>   drivers/net/ethernet/intel/ice/ice_ptp.c    |  40 ++++------\n>   drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 117 ++++++++++++++++++++++++++++\n>   3 files changed, 132 insertions(+), 26 deletions(-)\n>\n> diff --git a/drivers/net/ethernet/intel/ice/ice_ptp_hw.h b/drivers/net/ethernet/intel/ice/ice_ptp_hw.h\n> index 9d7acc7eb2ce..1b58b054f4a5 100644\n> --- a/drivers/net/ethernet/intel/ice/ice_ptp_hw.h\n> +++ b/drivers/net/ethernet/intel/ice/ice_ptp_hw.h\n> @@ -300,6 +300,7 @@ void ice_ptp_reset_ts_memory(struct ice_hw *hw);\n>   int ice_ptp_init_phc(struct ice_hw *hw);\n>   void ice_ptp_init_hw(struct ice_hw *hw);\n>   int ice_get_phy_tx_tstamp_ready(struct ice_hw *hw, u8 block, u64 *tstamp_ready);\n> +int ice_check_phy_tx_tstamp_ready(struct ice_hw *hw);\n>   int ice_ptp_one_port_cmd(struct ice_hw *hw, u8 configured_port,\n>   \t\t\t enum ice_ptp_tmr_cmd configured_cmd);\n>   \n> diff --git a/drivers/net/ethernet/intel/ice/ice_ptp.c b/drivers/net/ethernet/intel/ice/ice_ptp.c\n> index ada42bcc4d0b..34906f972d17 100644\n> --- a/drivers/net/ethernet/intel/ice/ice_ptp.c\n> +++ b/drivers/net/ethernet/intel/ice/ice_ptp.c\n> @@ -2718,7 +2718,7 @@ static bool ice_any_port_has_timestamps(struct ice_pf *pf)\n>   bool ice_ptp_tx_tstamps_pending(struct ice_pf *pf)\n>   {\n>   \tstruct ice_hw *hw = &pf->hw;\n> -\tunsigned int i;\n> +\tint ret;\n>   \n>   \t/* Check software indicator */\n>   \tswitch (pf->ptp.tx_interrupt_mode) {\n> @@ -2739,16 +2739,15 @@ bool ice_ptp_tx_tstamps_pending(struct ice_pf *pf)\n>   \t}\n>   \n>   \t/* Check hardware indicator */\n> -\tfor (i = 0; i < ICE_GET_QUAD_NUM(hw->ptp.num_lports); i++) {\n> -\t\tu64 tstamp_ready = 0;\n> -\t\tint err;\n> -\n> -\t\terr = ice_get_phy_tx_tstamp_ready(&pf->hw, i, &tstamp_ready);\n> -\t\tif (err || tstamp_ready)\n> -\t\t\treturn true;\n> +\tret = ice_check_phy_tx_tstamp_ready(hw);\n> +\tif (ret < 0) {\n> +\t\tdev_dbg(ice_pf_to_dev(pf), \"Unable to read PHY Tx timestamp ready bitmap, err %d\\n\",\n> +\t\t\tret);\n> +\t\t/* Stop triggering IRQs if we're unable to read PHY */\n> +\t\treturn false;\n>   \t}\n>   \n> -\treturn false;\n> +\treturn ret;\n>   }\n>   \n>   /**\n> @@ -2832,8 +2831,7 @@ static void ice_ptp_maybe_trigger_tx_interrupt(struct ice_pf *pf)\n>   {\n>   \tstruct device *dev = ice_pf_to_dev(pf);\n>   \tstruct ice_hw *hw = &pf->hw;\n> -\tbool trigger_oicr = false;\n> -\tunsigned int i;\n> +\tint ret;\n>   \n>   \tif (!pf->ptp.port.tx.has_ready_bitmap)\n>   \t\treturn;\n> @@ -2841,21 +2839,11 @@ static void ice_ptp_maybe_trigger_tx_interrupt(struct ice_pf *pf)\n>   \tif (!ice_pf_src_tmr_owned(pf))\n>   \t\treturn;\n>   \n> -\tfor (i = 0; i < ICE_GET_QUAD_NUM(hw->ptp.num_lports); i++) {\n> -\t\tu64 tstamp_ready;\n> -\t\tint err;\n> -\n> -\t\terr = ice_get_phy_tx_tstamp_ready(&pf->hw, i, &tstamp_ready);\n> -\t\tif (!err && tstamp_ready) {\n> -\t\t\ttrigger_oicr = true;\n> -\t\t\tbreak;\n> -\t\t}\n> -\t}\n> -\n> -\tif (trigger_oicr) {\n> -\t\t/* Trigger a software interrupt, to ensure this data\n> -\t\t * gets processed.\n> -\t\t */\n> +\tret = ice_check_phy_tx_tstamp_ready(hw);\n> +\tif (ret < 0) {\n> +\t\tdev_dbg(dev, \"PTP periodic task unable to read PHY timestamp ready bitmap, err %d\\n\",\n> +\t\t\tret);\n> +\t} else if (ret) {\n>   \t\tdev_dbg(dev, \"PTP periodic task detected waiting timestamps. Triggering Tx timestamp interrupt now.\\n\");\n>   \n>   \t\twr32(hw, PFINT_OICR, PFINT_OICR_TSYN_TX_M);\n> diff --git a/drivers/net/ethernet/intel/ice/ice_ptp_hw.c b/drivers/net/ethernet/intel/ice/ice_ptp_hw.c\n> index 441b5f10e4bb..64ad5ed5c688 100644\n> --- a/drivers/net/ethernet/intel/ice/ice_ptp_hw.c\n> +++ b/drivers/net/ethernet/intel/ice/ice_ptp_hw.c\n> @@ -2168,6 +2168,35 @@ int ice_start_phy_timer_eth56g(struct ice_hw *hw, u8 port)\n>   \treturn 0;\n>   }\n>   \n> +/**\n> + * ice_check_phy_tx_tstamp_ready_eth56g - Check Tx memory status for all ports\n> + * @hw: pointer to the HW struct\n> + *\n> + * Check the PHY_REG_TX_MEMORY_STATUS for all ports. A set bit indicates\n> + * a waiting timestamp.\n> + *\n> + * Return: 1 if any port has at least one timestamp ready bit set,\n> + * 0 otherwise, and a negative error code if unable to read the bitmap.\n> + */\n> +static int ice_check_phy_tx_tstamp_ready_eth56g(struct ice_hw *hw)\n> +{\n> +\tint port;\n> +\n> +\tfor (port = 0; port < hw->ptp.num_lports; port++) {\n> +\t\tu64 tstamp_ready;\n> +\t\tint err;\n> +\n> +\t\terr = ice_get_phy_tx_tstamp_ready(hw, port, &tstamp_ready);\n> +\t\tif (err)\n> +\t\t\treturn err;\n> +\n> +\t\tif (tstamp_ready)\n> +\t\t\treturn 1;\n> +\t}\n> +\n> +\treturn 0;\n> +}\n> +\n>   /**\n>    * ice_ptp_read_tx_hwtstamp_status_eth56g - Get TX timestamp status\n>    * @hw: pointer to the HW struct\n> @@ -4318,6 +4347,35 @@ ice_get_phy_tx_tstamp_ready_e82x(struct ice_hw *hw, u8 quad, u64 *tstamp_ready)\n>   \treturn 0;\n>   }\n>   \n> +/**\n> + * ice_check_phy_tx_tstamp_ready_e82x - Check Tx memory status for all quads\n> + * @hw: pointer to the HW struct\n> + *\n> + * Check the Q_REG_TX_MEMORY_STATUS for all quads. A set bit indicates\n> + * a waiting timestamp.\n> + *\n> + * Return: 1 if any quad has at least one timestamp ready bit set,\n> + * 0 otherwise, and a negative error value if unable to read the bitmap.\n> + */\n> +static int ice_check_phy_tx_tstamp_ready_e82x(struct ice_hw *hw)\n> +{\n> +\tint quad;\n> +\n> +\tfor (quad = 0; quad < ICE_GET_QUAD_NUM(hw->ptp.num_lports); quad++) {\n> +\t\tu64 tstamp_ready;\n> +\t\tint err;\n> +\n> +\t\terr = ice_get_phy_tx_tstamp_ready(hw, quad, &tstamp_ready);\n> +\t\tif (err)\n> +\t\t\treturn err;\n> +\n> +\t\tif (tstamp_ready)\n> +\t\t\treturn 1;\n> +\t}\n> +\n> +\treturn 0;\n> +}\n> +\n>   /**\n>    * ice_phy_cfg_intr_e82x - Configure TX timestamp interrupt\n>    * @hw: pointer to the HW struct\n> @@ -4870,6 +4928,23 @@ ice_get_phy_tx_tstamp_ready_e810(struct ice_hw *hw, u8 port, u64 *tstamp_ready)\n>   \treturn 0;\n>   }\n>   \n> +/**\n> + * ice_check_phy_tx_tstamp_ready_e810 - Check Tx memory status register\n> + * @hw: pointer to the HW struct\n> + *\n> + * The E810 devices do not have a Tx memory status register. Note this is\n> + * intentionally different behavior from ice_get_phy_tx_tstamp_ready_e810\n> + * which always says that all bits are ready. This function is called in cases\n> + * where code will trigger interrupts if timestamps are waiting, and should\n> + * not be called for E810 hardware.\n> + *\n> + * Return: 0.\n> + */\n> +static int ice_check_phy_tx_tstamp_ready_e810(struct ice_hw *hw)\n> +{\n> +\treturn 0;\n> +}\n> +\n>   /* E810 SMA functions\n>    *\n>    * The following functions operate specifically on E810 hardware and are used\n> @@ -5124,6 +5199,21 @@ static void ice_get_phy_tx_tstamp_ready_e830(const struct ice_hw *hw, u8 port,\n>   \t*tstamp_ready |= rd32(hw, E830_PRTMAC_TS_TX_MEM_VALID_L);\n>   }\n>   \n> +/**\n> + * ice_check_phy_tx_tstamp_ready_e830 - Check Tx memory status register\n> + * @hw: pointer to the HW struct\n> + *\n> + * Return: 1 if the device has waiting timestamps, 0 otherwise.\n> + */\n> +static int ice_check_phy_tx_tstamp_ready_e830(struct ice_hw *hw)\n> +{\n> +\tu64 tstamp_ready;\n> +\n> +\tice_get_phy_tx_tstamp_ready_e830(hw, 0, &tstamp_ready);\n> +\n> +\treturn !!tstamp_ready;\n> +}\n> +\n>   /**\n>    * ice_ptp_init_phy_e830 - initialize PHY parameters\n>    * @ptp: pointer to the PTP HW struct\n> @@ -5716,6 +5806,33 @@ int ice_get_phy_tx_tstamp_ready(struct ice_hw *hw, u8 block, u64 *tstamp_ready)\n>   \t}\n>   }\n>   \n> +/**\n> + * ice_check_phy_tx_tstamp_ready - Check PHY Tx timestamp memory status\n> + * @hw: pointer to the HW struct\n> + *\n> + * Check the PHY for Tx timestamp memory status on all ports. If you need to\n> + * see individual timestamp status for each index, use\n> + * ice_get_phy_tx_tstamp_ready() instead.\n> + *\n> + * Return: 1 if any port has timestamps available, 0 if there are no timestamps\n> + * available, and a negative error code on failure.\n> + */\n> +int ice_check_phy_tx_tstamp_ready(struct ice_hw *hw)\n> +{\n> +\tswitch (hw->mac_type) {\n> +\tcase ICE_MAC_E810:\n> +\t\treturn ice_check_phy_tx_tstamp_ready_e810(hw);\n> +\tcase ICE_MAC_E830:\n> +\t\treturn ice_check_phy_tx_tstamp_ready_e830(hw);\n> +\tcase ICE_MAC_GENERIC:\n> +\t\treturn ice_check_phy_tx_tstamp_ready_e82x(hw);\n> +\tcase ICE_MAC_GENERIC_3K_E825:\n> +\t\treturn ice_check_phy_tx_tstamp_ready_eth56g(hw);\n> +\tdefault:\n> +\t\treturn -EOPNOTSUPP;\n> +\t}\n> +}\n> +\n>   /**\n>    * ice_cgu_get_pin_desc_e823 - get pin description array\n>    * @hw: pointer to the hw struct\n>\nReviewed-by: Petr Oros <poros@redhat.com>","headers":{"Return-Path":"<intel-wired-lan-bounces@osuosl.org>","X-Original-To":["incoming@patchwork.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=osuosl.org header.i=@osuosl.org header.a=rsa-sha256\n header.s=default header.b=1JEEJAid;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=osuosl.org\n (client-ip=140.211.166.137; helo=smtp4.osuosl.org;\n envelope-from=intel-wired-lan-bounces@osuosl.org;\n receiver=patchwork.ozlabs.org)"],"Received":["from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fsWpp01bdz1yGS\n\tfor <incoming@patchwork.ozlabs.org>; Fri, 10 Apr 2026 19:34:25 +1000 (AEST)","from localhost (localhost [127.0.0.1])\n\tby smtp4.osuosl.org (Postfix) with ESMTP id 06D0340CEB;\n\tFri, 10 Apr 2026 09:34:24 +0000 (UTC)","from smtp4.osuosl.org ([127.0.0.1])\n by localhost (smtp4.osuosl.org [127.0.0.1]) (amavis, port 10024) with ESMTP\n id poWa0ki0L1Lo; Fri, 10 Apr 2026 09:34:23 +0000 (UTC)","from lists1.osuosl.org (lists1.osuosl.org [140.211.166.142])\n\tby smtp4.osuosl.org (Postfix) with ESMTP id 0675940CF7;\n\tFri, 10 Apr 2026 09:34:23 +0000 (UTC)","from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])\n by lists1.osuosl.org (Postfix) with ESMTP id 1FDE7237\n for <intel-wired-lan@lists.osuosl.org>; Fri, 10 Apr 2026 09:34:22 +0000 (UTC)","from localhost (localhost [127.0.0.1])\n by smtp3.osuosl.org (Postfix) with ESMTP id 1149560BAA\n for <intel-wired-lan@lists.osuosl.org>; Fri, 10 Apr 2026 09:34:22 +0000 (UTC)","from smtp3.osuosl.org ([127.0.0.1])\n by localhost (smtp3.osuosl.org [127.0.0.1]) (amavis, port 10024) with ESMTP\n id d7vBC9TbCYdR for <intel-wired-lan@lists.osuosl.org>;\n Fri, 10 Apr 2026 09:34:21 +0000 (UTC)","from us-smtp-delivery-124.mimecast.com\n (us-smtp-delivery-124.mimecast.com [170.10.129.124])\n by smtp3.osuosl.org (Postfix) with ESMTPS id D017460759\n for <intel-wired-lan@lists.osuosl.org>; Fri, 10 Apr 2026 09:34:20 +0000 (UTC)","from mail-wm1-f72.google.com (mail-wm1-f72.google.com\n [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS\n (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id\n us-mta-591-8v429RixO8CxYRSVomVMYA-1; Fri, 10 Apr 2026 05:34:18 -0400","by mail-wm1-f72.google.com with SMTP id\n 5b1f17b1804b1-488d9e1e61aso2071665e9.0\n for <intel-wired-lan@lists.osuosl.org>; Fri, 10 Apr 2026 02:34:18 -0700 (PDT)","from [192.168.2.83] ([46.175.183.46])\n by smtp.gmail.com with ESMTPSA id\n 5b1f17b1804b1-488d5d78cfdsm17897975e9.4.2026.04.10.02.34.14\n (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n Fri, 10 Apr 2026 02:34:15 -0700 (PDT)"],"X-Virus-Scanned":["amavis at osuosl.org","amavis at osuosl.org"],"X-Comment":"SPF check N/A for local connections - client-ip=140.211.166.142;\n helo=lists1.osuosl.org; envelope-from=intel-wired-lan-bounces@osuosl.org;\n receiver=<UNKNOWN> ","DKIM-Filter":["OpenDKIM Filter v2.11.0 smtp4.osuosl.org 0675940CF7","OpenDKIM Filter v2.11.0 smtp3.osuosl.org D017460759"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=osuosl.org;\n\ts=default; t=1775813663;\n\tbh=MbNXgPIhRUaORuGkZXuCuXIvu+tsHUf6wi7oUQz/0l4=;\n\th=Date:To:Cc:References:From:In-Reply-To:Subject:List-Id:\n\t List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe:\n\t From;\n\tb=1JEEJAidwJTldmICV7R1kWYoCiam7774DuJEqJNkqUVBLt6fbOLCOpDd0IDYTr3R1\n\t +IUFTx0ie4RsBxARh8+0KqeBS+elQ92rBI8zOI+Z/1OlqeMwi+7+Ybr64Ekps1lNkn\n\t 0gqEIxnsRN7Q6Fi3pnKl122RKT/ZebBHAGyDXY5LdtGwcp8aa+LBuySX+3aFDgqSRd\n\t 3ToysmSahIBh0/WRiHjudcDMhfTl2Df5pyU/bSu5aA1dNVDWHcDj8umcxEI5Mi9K49\n\t MJULW09VsJ4AOlS9KzAsHCkRlLks4bHCSMl74yWj+H22p8I3IYW/dr1sfWP+VNjyaf\n\t HKv/wGYZNwZ8Q==","Received-SPF":"Pass (mailfrom) identity=mailfrom; client-ip=170.10.129.124;\n helo=us-smtp-delivery-124.mimecast.com; envelope-from=poros@redhat.com;\n receiver=<UNKNOWN>","DMARC-Filter":"OpenDMARC Filter v1.4.2 smtp3.osuosl.org D017460759","X-MC-Unique":"8v429RixO8CxYRSVomVMYA-1","X-Mimecast-MFC-AGG-ID":"8v429RixO8CxYRSVomVMYA_1775813657","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1775813657; x=1776418457;\n h=content-transfer-encoding:in-reply-to:from:content-language\n :references:cc:to:subject:user-agent:mime-version:date:message-id\n :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id\n :reply-to;\n bh=MbNXgPIhRUaORuGkZXuCuXIvu+tsHUf6wi7oUQz/0l4=;\n b=LZ+4jb0SPYipRuwREap+77D7RDzACaFcVwbLqNw0rDYXD7XZTUAoWfgf74uaDkqPDh\n Tqc2zIEhC647yEL4CwJdJH6wEjXGcdz4wIaJfJ42PO3QYw4k+x3NOjqTdPQ7RywgPy1l\n 4f58gwtudvVY3hsyH70SzrcnMKP/75YOTeViyzSpTyEB1Ua5Jen6Fhu3zewpGoefik10\n r5yiVPuDXaKjhDwyAQVxuhv7a4/aO7VoJ4K3ZEn94ygopVyd8cFcinhA6Xtcl7DxUZ8C\n uejsojIorR/utymVq6JPm+jtNRDoKflqWYUNgAtQ6LEIK+ZuHSw7Vm7cnc/hWDZ/94Ek\n /iyw==","X-Forwarded-Encrypted":"i=1;\n AJvYcCXlxaj1COci2mceqTeFB9EZYBnomVaVUfjW78Xii3VCsxU15+AYXnNdREtXvpfDxDJFkatJ7pNt+Vu/N1OreaI=@lists.osuosl.org","X-Gm-Message-State":"AOJu0YwRXaw/vaCQB4z9eaPg1qnXoejr5qYTNWBwJ8S2Qse951LAWw6Y\n IxYfFutut5SFQf4chGJ7zgft1LM2dBTQLG3Qd2YLCGLu+sh3+O0x95qYp6T4cGiz8MzUAFA+Ueh\n XP2AB8aH1Vljvh4EQLPjdqIINnXNSX7i3TK4iskBVptlDC4ZEt1MLfgONlPu35gQMK+V6BOo=","X-Gm-Gg":"AeBDiesyvIn9cs2O/07QxRV9B38O7pe6Yv/8Om8AW2iU1KnJIqJuNKSto1yfRJRLfEb\n JMnTQobaGx7UOvlIZ6WCvJcx1E5UjrXK/1cq6QaA16M+87Z8DEPAoVDi5fsg4YngnEhlhzYxMSG\n Pt/41vJhpa2GNqFsksickaFrEmnlRcsBFW3GffEbp1sm7JaXwo31Z3j+DM9UYM7LC0Zp2jIzEbk\n pwq57pDupyGYdkIwdyv2q6C6lmiI32+FrYi66/whdTRaIree8pQAt8vHU6E5hGtU1sCezWslF7X\n 36Tf0z/mMjwJEq3eDid8YnzLH+3BqjihiI1UIoVYiVNPBCClNWjcgM8knoyvd272IM+iFpk/xAv\n N9Y6tM8qxrmcxuZKxA3L8","X-Received":["by 2002:a05:600c:3f0d:b0:485:40fd:8390 with SMTP id\n 5b1f17b1804b1-488d68769f9mr25808775e9.26.1775813656783;\n Fri, 10 Apr 2026 02:34:16 -0700 (PDT)","by 2002:a05:600c:3f0d:b0:485:40fd:8390 with SMTP id\n 5b1f17b1804b1-488d68769f9mr25808205e9.26.1775813656212;\n Fri, 10 Apr 2026 02:34:16 -0700 (PDT)"],"Message-ID":"<715ae9de-25f4-4496-abb5-9c98ccda5ede@redhat.com>","Date":"Fri, 10 Apr 2026 11:34:14 +0200","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","To":"Jacob Keller <jacob.e.keller@intel.com>,\n Anthony Nguyen <anthony.l.nguyen@intel.com>,\n Intel Wired LAN <intel-wired-lan@lists.osuosl.org>, netdev@vger.kernel.org","Cc":"Aleksandr Loktionov <aleksandr.loktionov@intel.com>,\n Timothy Miskell <timothy.miskell@intel.com>","References":"<20260408-jk-even-more-e825c-fixes-v1-0-b959da91a81f@intel.com>\n <20260408-jk-even-more-e825c-fixes-v1-3-b959da91a81f@intel.com>","From":"Petr Oros <poros@redhat.com>","In-Reply-To":"<20260408-jk-even-more-e825c-fixes-v1-3-b959da91a81f@intel.com>","X-Mimecast-Spam-Score":"0","X-Mimecast-MFC-PROC-ID":"7BYTeiI-scNl77N-eE0CUYjN1pBtNlvSrrx8_qstq98_1775813657","X-Mimecast-Originator":"redhat.com","Content-Language":"en-US","Content-Type":"text/plain; charset=UTF-8; format=flowed","Content-Transfer-Encoding":"7bit","X-Mailman-Original-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=redhat.com;\n s=mimecast20190719; t=1775813659;\n h=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n to:to:cc:cc:mime-version:mime-version:content-type:content-type:\n content-transfer-encoding:content-transfer-encoding:\n in-reply-to:in-reply-to:references:references;\n bh=MbNXgPIhRUaORuGkZXuCuXIvu+tsHUf6wi7oUQz/0l4=;\n b=T9dfO9qFTGbPEy53zG6zW0DZeshsNShR0UcUNNEjBUFvvM4irSOZDzHo2d1lsSO6qzQpI2\n rvyQIM0iKjgDu7puhB5v5CfuoS56C/ONZSv20zS+fl57ScSXwb3d0dNh62SirdSldNoWHi\n mye9po4gIL47sQpufG/IeSECbqWwwvY=","X-Mailman-Original-Authentication-Results":["smtp3.osuosl.org;\n dmarc=pass (p=quarantine dis=none)\n header.from=redhat.com","smtp3.osuosl.org;\n dkim=pass (1024-bit key,\n unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256\n header.s=mimecast20190719 header.b=T9dfO9qF"],"Subject":"Re: [Intel-wired-lan] [PATCH iwl-net 3/4] ice: fix ready bitmap\n check for non-E822 devices","X-BeenThere":"intel-wired-lan@osuosl.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Intel Wired Ethernet Linux Kernel Driver Development\n <intel-wired-lan.osuosl.org>","List-Unsubscribe":"<https://lists.osuosl.org/mailman/options/intel-wired-lan>,\n <mailto:intel-wired-lan-request@osuosl.org?subject=unsubscribe>","List-Archive":"<http://lists.osuosl.org/pipermail/intel-wired-lan/>","List-Post":"<mailto:intel-wired-lan@osuosl.org>","List-Help":"<mailto:intel-wired-lan-request@osuosl.org?subject=help>","List-Subscribe":"<https://lists.osuosl.org/mailman/listinfo/intel-wired-lan>,\n <mailto:intel-wired-lan-request@osuosl.org?subject=subscribe>","Errors-To":"intel-wired-lan-bounces@osuosl.org","Sender":"\"Intel-wired-lan\" <intel-wired-lan-bounces@osuosl.org>"}},{"id":3676072,"web_url":"http://patchwork.ozlabs.org/comment/3676072/","msgid":"<e0691ad1-9727-4250-8ae2-dd7c8fd9d1f1@intel.com>","list_archive_url":null,"date":"2026-04-10T22:32:17","subject":"Re: [Intel-wired-lan] [PATCH iwl-net 3/4] ice: fix ready bitmap\n check for non-E822 devices","submitter":{"id":9784,"url":"http://patchwork.ozlabs.org/api/people/9784/","name":"Jacob Keller","email":"jacob.e.keller@intel.com"},"content":"On 4/8/2026 11:46 AM, Jacob Keller wrote:\n> diff --git a/drivers/net/ethernet/intel/ice/ice_ptp.c b/drivers/net/ethernet/intel/ice/ice_ptp.c\n> index ada42bcc4d0b..34906f972d17 100644\n> --- a/drivers/net/ethernet/intel/ice/ice_ptp.c\n> +++ b/drivers/net/ethernet/intel/ice/ice_ptp.c\n> @@ -2718,7 +2718,7 @@ static bool ice_any_port_has_timestamps(struct ice_pf *pf)\n>  bool ice_ptp_tx_tstamps_pending(struct ice_pf *pf)\n>  {\n>  \tstruct ice_hw *hw = &pf->hw;\n> -\tunsigned int i;\n> +\tint ret;\n>  \n>  \t/* Check software indicator */\n>  \tswitch (pf->ptp.tx_interrupt_mode) {\n> @@ -2739,16 +2739,15 @@ bool ice_ptp_tx_tstamps_pending(struct ice_pf *pf)\n>  \t}\n>  \n>  \t/* Check hardware indicator */\n> -\tfor (i = 0; i < ICE_GET_QUAD_NUM(hw->ptp.num_lports); i++) {\n> -\t\tu64 tstamp_ready = 0;\n> -\t\tint err;\n> -\n> -\t\terr = ice_get_phy_tx_tstamp_ready(&pf->hw, i, &tstamp_ready);\n> -\t\tif (err || tstamp_ready)\n> -\t\t\treturn true;\n> +\tret = ice_check_phy_tx_tstamp_ready(hw);\n> +\tif (ret < 0) {\n> +\t\tdev_dbg(ice_pf_to_dev(pf), \"Unable to read PHY Tx timestamp ready bitmap, err %d\\n\",\n> +\t\t\tret);\n> +\t\t/* Stop triggering IRQs if we're unable to read PHY */\n> +\t\treturn false;\n>  \t}\n>  \n> -\treturn false;\n> +\treturn ret;\n\nI got some comments off-list from Aleks about this \"conversion\" from\ninteger to boolean here. The return from ice_check_phy_tx_tstamp_ready()\nis 0 when there are no timsetamps and 1 when there is at least one\ntimestamp available. The negative values are excluded in the check just\nabove this.\n\nI guess I can re-write this to be an if/elif/else chain instead, but I\nwonder what others on the list think here.\n\nI understand it is slightly confusing to have a return which is 3-way\n(error, 0 or 1), but other solutions seemed inellegant. Using a bool for\nthe check means we lose the nuance of the error code (and the distinct\ndev_dbg message). It also doesn't let the caller decide whether its more\nimporant to continue on error or stop on error (which might be dependant\non each call flow).\n\nJust doing \"ret ? true : false\" seems stupid since that is literally\nwhat this will do given that we already excluded negative values in the\ncheck above before returning.\n\n> +/**\n> + * ice_check_phy_tx_tstamp_ready_e810 - Check Tx memory status register\n> + * @hw: pointer to the HW struct\n> + *\n> + * The E810 devices do not have a Tx memory status register. Note this is\n> + * intentionally different behavior from ice_get_phy_tx_tstamp_ready_e810\n> + * which always says that all bits are ready. This function is called in cases\n> + * where code will trigger interrupts if timestamps are waiting, and should\n> + * not be called for E810 hardware.\n> + *\n> + * Return: 0.\n> + */\n> +static int ice_check_phy_tx_tstamp_ready_e810(struct ice_hw *hw)\n> +{\n> +\treturn 0;\n> +}\n> +\n\nI got comments off list about this \"unused parameter\" and empty\nfunction. The E810 hardware doesn't have a ready bitmap in its\nregisters. Thus, this function doesn't really do anything. I'm\nconsidering if it makes more sense to move this comment into the\nhardware wrapper layer and drop this function (and thus its unused\nparameter).\n> +/**\n> + * ice_check_phy_tx_tstamp_ready - Check PHY Tx timestamp memory status\n> + * @hw: pointer to the HW struct\n> + *\n> + * Check the PHY for Tx timestamp memory status on all ports. If you need to\n> + * see individual timestamp status for each index, use\n> + * ice_get_phy_tx_tstamp_ready() instead.\n> + *\n> + * Return: 1 if any port has timestamps available, 0 if there are no timestamps\n> + * available, and a negative error code on failure.\n> + */\n\nThis type of return is somewhat confusing and rare. Typically functions\nreturning int either return 0 for success or a non-zero error code. In\nthis case there are two \"success\" states. C doesn't have anything like\nthe Error types from newer languages.\n\nThe closest example I have is functions that read from a socket or\nbuffer or file, which return negative error codes or the number of bytes\nread/written.\n\nI could change this API to return the total number of timestamps\navailable.. but every caller just cares about whether there is at least\none timestamp, so I opted to shrink it to 0/1 in order to allow eliding\nunnecessary checks for devices with multiple ports.\n\nThoughts?\n\nThanks,\nJak","headers":{"Return-Path":"<intel-wired-lan-bounces@osuosl.org>","X-Original-To":["incoming@patchwork.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","intel-wired-lan@lists.osuosl.org"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=osuosl.org header.i=@osuosl.org header.a=rsa-sha256\n header.s=default header.b=K0bQRMhE;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=osuosl.org\n (client-ip=2605:bc80:3010::137; helo=smtp4.osuosl.org;\n envelope-from=intel-wired-lan-bounces@osuosl.org;\n receiver=patchwork.ozlabs.org)"],"Received":["from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fss4d0KJCz1yCx\n\tfor <incoming@patchwork.ozlabs.org>; Sat, 11 Apr 2026 08:32:32 +1000 (AEST)","from localhost (localhost [127.0.0.1])\n\tby smtp4.osuosl.org (Postfix) with ESMTP id 5C07C4125F;\n\tFri, 10 Apr 2026 22:32:31 +0000 (UTC)","from smtp4.osuosl.org ([127.0.0.1])\n by localhost (smtp4.osuosl.org [127.0.0.1]) (amavis, port 10024) with ESMTP\n id VC3w1yx8fx-w; Fri, 10 Apr 2026 22:32:30 +0000 (UTC)","from lists1.osuosl.org (lists1.osuosl.org [140.211.166.142])\n\tby smtp4.osuosl.org (Postfix) with ESMTP id 8A29441257;\n\tFri, 10 Apr 2026 22:32:30 +0000 (UTC)","from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])\n by lists1.osuosl.org (Postfix) with ESMTP id 3EAC6194\n for <intel-wired-lan@lists.osuosl.org>; Fri, 10 Apr 2026 22:32:29 +0000 (UTC)","from localhost (localhost [127.0.0.1])\n by smtp1.osuosl.org (Postfix) with ESMTP id 2FF6D83CE2\n for <intel-wired-lan@lists.osuosl.org>; Fri, 10 Apr 2026 22:32:29 +0000 (UTC)","from smtp1.osuosl.org ([127.0.0.1])\n by localhost (smtp1.osuosl.org [127.0.0.1]) (amavis, port 10024) with ESMTP\n id r9k-52gti0mV for <intel-wired-lan@lists.osuosl.org>;\n Fri, 10 Apr 2026 22:32:28 +0000 (UTC)","from mgamail.intel.com (mgamail.intel.com [192.198.163.9])\n by smtp1.osuosl.org (Postfix) with ESMTPS id EFB7583CE0\n for <intel-wired-lan@lists.osuosl.org>; Fri, 10 Apr 2026 22:32:27 +0000 (UTC)","from orviesa009.jf.intel.com ([10.64.159.149])\n by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 10 Apr 2026 15:32:27 -0700","from orsmsx901.amr.corp.intel.com ([10.22.229.23])\n by orviesa009.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 10 Apr 2026 15:32:27 -0700","from ORSMSX902.amr.corp.intel.com (10.22.229.24) by\n ORSMSX901.amr.corp.intel.com (10.22.229.23) with Microsoft SMTP Server\n (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id\n 15.2.2562.37; Fri, 10 Apr 2026 15:32:26 -0700","from ORSEDG903.ED.cps.intel.com (10.7.248.13) by\n ORSMSX902.amr.corp.intel.com (10.22.229.24) with Microsoft SMTP Server\n (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id\n 15.2.2562.37 via Frontend Transport; Fri, 10 Apr 2026 15:32:26 -0700","from CH5PR02CU005.outbound.protection.outlook.com (40.107.200.11) by\n edgegateway.intel.com (134.134.137.113) with Microsoft SMTP Server\n (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id\n 15.2.2562.37; Fri, 10 Apr 2026 15:32:24 -0700","from DS0PR11MB7579.namprd11.prod.outlook.com (2603:10b6:8:14d::5) by\n SAWPR11MB9546.namprd11.prod.outlook.com (2603:10b6:806:4e4::6) with\n Microsoft\n SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id\n 15.20.9769.15; Fri, 10 Apr 2026 22:32:21 +0000","from DS0PR11MB7579.namprd11.prod.outlook.com\n ([fe80::4199:4cb5:cf88:e79e]) by DS0PR11MB7579.namprd11.prod.outlook.com\n ([fe80::4199:4cb5:cf88:e79e%5]) with mapi id 15.20.9818.014; Fri, 10 Apr 2026\n 22:32:19 +0000"],"X-Virus-Scanned":["amavis at osuosl.org","amavis at osuosl.org"],"X-Comment":"SPF check N/A for local connections - client-ip=140.211.166.142;\n helo=lists1.osuosl.org; envelope-from=intel-wired-lan-bounces@osuosl.org;\n receiver=<UNKNOWN> ","DKIM-Filter":["OpenDKIM Filter v2.11.0 smtp4.osuosl.org 8A29441257","OpenDKIM Filter v2.11.0 smtp1.osuosl.org EFB7583CE0"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=osuosl.org;\n\ts=default; t=1775860350;\n\tbh=MVgNOP7ex4PWqghHtO3559iwRYvhMrkWYr2jQfhqRH8=;\n\th=Date:To:References:From:In-Reply-To:Subject:List-Id:\n\t List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe:\n\t Cc:From;\n\tb=K0bQRMhEF5BLgiIdZpZEINjrYhBXFHSOUDDrtrcrnuLv3jjaHxcZMuPFLPRobih8d\n\t a/EEQcQxHRGH4jDT1+R+929AmE29qrwP2OXDdCbjKHTmM9b75osQZt7pkvS2AoJze/\n\t MgEebQNyxCwgLsNtPqxoIgvsGiHoDr2a2qIy+3d55xbzT6EgSCP27+YHTUaw2Lci2i\n\t k0PT2cqPCJPBvaccGRbSe0X5eCxTL+3WlUZ/wj56OYF63VwIIKNPthwbaVizaiQPrX\n\t DJEoPZwr7BFkYy4N0fmU2sqiVXnD6+0wW0EPGQNa8qLmfYbxQQujz9E3gUwoYDcOIL\n\t VBgCmRZadhW5w==","Received-SPF":"Pass (mailfrom) identity=mailfrom; client-ip=192.198.163.9;\n helo=mgamail.intel.com; envelope-from=jacob.e.keller@intel.com;\n receiver=<UNKNOWN>","DMARC-Filter":"OpenDMARC Filter v1.4.2 smtp1.osuosl.org EFB7583CE0","X-CSE-ConnectionGUID":["l6P2YzKvTci/UkZ0SqQpUg==","/I5rwyVFTYuwahJryImm9w=="],"X-CSE-MsgGUID":["8qQv9QoMRtC5xtqZfg9+Hw==","bsv8ct6RS36ZTM7LnRdVtA=="],"X-IronPort-AV":["E=McAfee;i=\"6800,10657,11755\"; a=\"87586326\"","E=Sophos;i=\"6.23,172,1770624000\"; d=\"scan'208\";a=\"87586326\"","E=Sophos;i=\"6.23,172,1770624000\"; d=\"scan'208\";a=\"229090709\""],"X-ExtLoop1":"1","ARC-Seal":"i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;\n b=CdIzgjOGq8ncbzR6yxw40qjHpoPiBygPcxz2ayvjqeJsC/RgQS7VlaNu6uTEALFmDC0/EEkd1RGqD6rZWUf2OvyOiihwl1NOVcHWYpsw8BlAvr6JOstopcdNG7VWe+oCYwyckUSKOFZ2GPzHwdQgYVnRgkno40UiV5C9lxhuPWXMzNp1Iwj2j4i5qPLeeuWOWWr6LMKau+GyVRnInooaDOVZ8B8chk/YuY9r6cc5KCghBcI1TbpoknGNr0OSkDN8Wf+3EJ4a3rXXsrtTvn6DgLIkSlc2JQ5xYg6RJRv99B91r70Jip421XtdTjlMZSNZH7oW+NU+kqjVUox7i3+bMg==","ARC-Message-Signature":"i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;\n s=arcselector10001;\n h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;\n bh=MVgNOP7ex4PWqghHtO3559iwRYvhMrkWYr2jQfhqRH8=;\n b=gOlD1oI4a7oL9XHK2GdzGla8dvaXVNq8K+kvLmpy4zSHK7vclSh5SWxNK+KG3WHvk5Okq6nAL/DbN6+ZaXRMUTZ63S88U4FpNYMJuo1jC4SWVlnG9Lo0Uty+kkhPfhDUf9YwJoTrJadpLsKVCMPl8Rr8gefdO9bd/frmVczyjlwZjLy4avRJZPrrlwUXQhpVhHCzOlqAVo7gdFYlY54ka6zcPFfNyj2rlFKd+OVD8V09z82Q5ycbSnr8OZRgzoCMiv7M9WDPXfKA+XOkF3E6rdAm/IwV7Q/TmI9WgVi6F2N0rlvS9hMti8gnohGaQVfxoM6cL5Wp8NX6AiBP1yxVsw==","ARC-Authentication-Results":"i=1; mx.microsoft.com 1; spf=pass\n smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com;\n dkim=pass header.d=intel.com; arc=none","Message-ID":"<e0691ad1-9727-4250-8ae2-dd7c8fd9d1f1@intel.com>","Date":"Fri, 10 Apr 2026 15:32:17 -0700","User-Agent":"Mozilla Thunderbird","To":"Anthony Nguyen <anthony.l.nguyen@intel.com>, Intel Wired LAN\n <intel-wired-lan@lists.osuosl.org>, <netdev@vger.kernel.org>, \"Aleksandr\n Loktionov\" <aleksandr.loktionov@intel.com>, Petr Oros <poros@redhat.com>","References":"<20260408-jk-even-more-e825c-fixes-v1-0-b959da91a81f@intel.com>\n <20260408-jk-even-more-e825c-fixes-v1-3-b959da91a81f@intel.com>","From":"Jacob Keller <jacob.e.keller@intel.com>","Content-Language":"en-US","In-Reply-To":"<20260408-jk-even-more-e825c-fixes-v1-3-b959da91a81f@intel.com>","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"7bit","X-ClientProxiedBy":"MW4P221CA0003.NAMP221.PROD.OUTLOOK.COM\n (2603:10b6:303:8b::8) To DS0PR11MB7579.namprd11.prod.outlook.com\n (2603:10b6:8:14d::5)","MIME-Version":"1.0","X-MS-PublicTrafficType":"Email","X-MS-TrafficTypeDiagnostic":"DS0PR11MB7579:EE_|SAWPR11MB9546:EE_","X-MS-Office365-Filtering-Correlation-Id":"9710d2b5-02ce-4f07-8e6d-08de975106d7","X-LD-Processed":"46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr","X-MS-Exchange-SenderADCheck":"1","X-MS-Exchange-AntiSpam-Relay":"0","X-Microsoft-Antispam":"BCL:0;\n ARA:13230040|366016|376014|1800799024|22082099003|56012099003|18002099003;","X-Microsoft-Antispam-Message-Info":"\n ow1uNLz8Uvmm07d5Itc/gQ8WslRBjQiauOoEWRY6Mml31cesb2g0KRQSnSo7rUAfp8zRSplLsvjPrEGi7Sn5JrCAiFC4xEIfZkAdoIR9Ruy8lpTV0Al4iv7OfHHWKJXFvqsd/a7fhHMxvFK11WdqX8vJGZtI7ly/CQqXVJlh4CL73IXqFnJcRhrd3zQUaPr58durp30m1zbaIWSMtYF4u5BBBbz5HgEYRGuUYr90jx2AZbQSdisxNp26rVkPV8jUntcv63YJrTW0ic73wyzwwuz0Ak9Tp/95sYpNxjZcicSknFpXzkvmY5zGV7NyKdIrw16DNwtqIbsPyK/M9brqQ728BpwgivkpL7tyqdkk7+SuJSuam2iiEGLpqp/BSJdiqf14Vsc/3KnT32wiAJpi1opFYSkJjIFtgW5yNSyWZbL3yC/y+1rBjrsT+oGYOLtgQjLfPt4PHgkFUFdoxSsUf9wgyFzsGBgYDnHl8hd5NLjPCY7dWkRKnFqViIurOzswRjJI8huWeP3k/aimmdLPYI4XLo2cgDmazIjAqIs4EkoFzjbaCJxH2WtgdcZDrY+ngubJsmWS+61sBQfZYAv2Qc3Hkz+PezFUO+UTJfhj5quZnu4WeKQ5THtQxWUoS+mMmwm984ileRDmY96PyBwYI/TYK6Nr6vEhAE9Myk9ayuXqqY4pINJvcbj9+4gF7SK9D9LrScIuAh6lICSktKM8Q72WtjkdGRlH6nWVXENFZdw=","X-Forefront-Antispam-Report":"CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;\n IPV:NLI; SFV:NSPM; H:DS0PR11MB7579.namprd11.prod.outlook.com; PTR:; CAT:NONE;\n SFS:(13230040)(366016)(376014)(1800799024)(22082099003)(56012099003)(18002099003);\n DIR:OUT; SFP:1101;","X-MS-Exchange-AntiSpam-MessageData-ChunkCount":"1","X-MS-Exchange-AntiSpam-MessageData-0":"=?utf-8?q?Cnd1a5gvm2ybUS1oARndaiI9gT2P?=\n\t=?utf-8?q?4OzJzrKVBia0nlmwZcA+cxU0T4JbdgaZQIA+7UAbu/HCBq81H4Gpj72sXPiwcxgNI?=\n\t=?utf-8?q?ftRr8UzoJa0ec5/fPyktrru1pQcLig9iwnOHPv9nxHwo3JOGmVm3daS6SKLI50dEg?=\n\t=?utf-8?q?qqZGLwP6I4ds+dGyPqBp0/7WgHm4GHB0z4dqrdFwv4CN9u8BSsTTRQyfoI/wenMIv?=\n\t=?utf-8?q?d2gpiCBvllJbVlFRPs0XlKTNIDMqBFAOONmpD7ICAo4T/pin0r8lkN1PC9UO2FyWY?=\n\t=?utf-8?q?qGhfQi3uqOTjSHUbqHfA/kEkW1n8fwu8yfztAa7qxR60jbvlJUE588/mDn7qI9Uj6?=\n\t=?utf-8?q?Cxaj58/xPSMGYe7Nboe7f7xC/UF4wh10L8hriX/s3EE+lxZsu+pPN4wiLPt41snl1?=\n\t=?utf-8?q?5jDxO67myT/oI37Vj00LfdVwPHcdZkDeKWs8hY4J3LUmC9wD5RqC97Zebd1hbp5QJ?=\n\t=?utf-8?q?BY2vdGJhm5FyI5i7zjHRqjCluefTGE0O6Ch9pDncvHQm2qhbXJb4e+DArkymlvoUM?=\n\t=?utf-8?q?m7U2aLji4ufYYj7pqWwOEIoRfddCYrI4UmQomIXyY07Z5xSZW5jy65+JvrYLOQrw0?=\n\t=?utf-8?q?OOGAoXrybY8jHHbtYq0emzURDxmBUpiSkXZOy6bqo7rWZgyOfeb2b7JaKmeKnFJXZ?=\n\t=?utf-8?q?JqsWxG/d1rgdhw3rwqpmKXB6I7nnfW13hPTIcBnyp7nRoG3gxWgpLetLKlNcs5BdC?=\n\t=?utf-8?q?8N2qXeIwACT9afQ/1kFDQeKcAEdStr7ZKJuV3ADNEpM1OUcxPnQAiJOZC5vK1qKdN?=\n\t=?utf-8?q?S6GafVVlcIPvRi3BpcLlgjoLN0hBsWa6obKa0vFJSy4XD6iURM4pu9/tB2ODplCjx?=\n\t=?utf-8?q?9pap8aWqoO7UC1NYWN7Q/xzxX3+jxDYDeL6o/Dt+UXxLJ7thzgL4p3K/YlQ+QFNSn?=\n\t=?utf-8?q?8YHl40fNOb0NYgEPo8Re394OGf5/9HDSCZkZiE0h82MmP/DjJdUZje2ZHY9FUCqYq?=\n\t=?utf-8?q?XOROAPsMNXcA5EHyjdbru6uAqqem0rdFbzdrtDdJmOR/0YKXr/R+5Z9vaHROf8ajJ?=\n\t=?utf-8?q?WU5XuCOcsDl//eiFjOaISFMe/LnSesZ+EXOxH6iAUKJBfuNbWdl8UipLSZKjJjGo0?=\n\t=?utf-8?q?01i36P8H2A0fyGMPu+5biXmxUSFFIGxkTcQv8jgDSElwbrWcbp0QoaGHdh1u1pDmS?=\n\t=?utf-8?q?cT6PX1JqrhTalhKbZUmHI1Bx6b5lUfgMoJfWiXLo2tJi8Emz3dCs2SR+nXbUqkEl2?=\n\t=?utf-8?q?DQLYUPtxN47eFdz9BK0loK2J/EEG6c80GOMcGfTp7MJxwAa4NGSJ+jjv+yKrlcS2b?=\n\t=?utf-8?q?LUfnJfrPCnwDkJAgRlzH42nDx3Ji+e6w5gb/9L1VhzpeZCYmBYubWbFS1TPSEHsvB?=\n\t=?utf-8?q?BAen7R2i1sQ+RhZD/pPVy31t7v7mbAYjx1grIYGIG15erMAeQ65+mcIIMMdkI2oad?=\n\t=?utf-8?q?r3PVy+AwiDUcv4+VkLNB5yJimjMi3rnZrb+MuJ4XeRv4dizeRJMfWNmPcmCR5PPUp?=\n\t=?utf-8?q?G44xvpXLvxM00UmGKw7U4UgYwUGUGlIJ38P0jaoVGzIFekLqh3GGflbO+EX0kk14d?=\n\t=?utf-8?q?0K3bXxd3Qwb9HXVeG0SkdfYRXOiao+mh54Y0z+1OSe43VOGMdtjzUyQwfahRIEz+Z?=\n\t=?utf-8?q?yEtPN3XmvQ0/NAqa0DGYHjNDJWlR8IsFn0JpNfLrmnkVfenPoPCaTnlIKRz5AHgcV?=\n\t=?utf-8?q?kGqIUHOteAt/nQE6ER8wzWQwzdsNUM2g=3D=3D?=","X-Exchange-RoutingPolicyChecked":"\n gf2CUnjzS6RSTqKfYaunN1WLzFvvITjE7S5oHocaKro6AzbBaAxUviLvur4MhCdvMM5ZqowbbPkE5nv0DKsLiTZsN9E9xIEoDNN2yuXfnpChZK2d5MKJi4VFW1C+tTySyHotZJRHk9axYCyVKkqsqmLgdjG8l50bBmiGm9i4kCLZ99VqnSxfVTIGwzlFMl2O7SZuBo0gjBTqlcINGNYgwH73ezlkeviNWIh6E7DTGwXKZrmYE9s4plXKjlmv4ZrUeX5pLfX1/5UqJqOLpra6QahcddFdBre6SCU2wAIqOeeXRQZ8WbmAaovPy1zbGDAcyQsCZWD9dhoDmgNvSixltQ==","X-MS-Exchange-CrossTenant-Network-Message-Id":"\n 9710d2b5-02ce-4f07-8e6d-08de975106d7","X-MS-Exchange-CrossTenant-AuthSource":"DS0PR11MB7579.namprd11.prod.outlook.com","X-MS-Exchange-CrossTenant-AuthAs":"Internal","X-MS-Exchange-CrossTenant-OriginalArrivalTime":"10 Apr 2026 22:32:19.7815 (UTC)","X-MS-Exchange-CrossTenant-FromEntityHeader":"Hosted","X-MS-Exchange-CrossTenant-Id":"46c98d88-e344-4ed4-8496-4ed7712e255d","X-MS-Exchange-CrossTenant-MailboxType":"HOSTED","X-MS-Exchange-CrossTenant-UserPrincipalName":"\n aAfwi3BIcfxhH/2xkfKuC6Dzq+Yvbijx/2iR35O2WU8QV4TNXTI0CR24QE4/4yMj7i3dq8Tr9VsgNhmEmczUB/tDLizL3nSqz6TUO5lKaB4=","X-MS-Exchange-Transport-CrossTenantHeadersStamped":"SAWPR11MB9546","X-OriginatorOrg":"intel.com","X-Mailman-Original-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple;\n d=intel.com; i=@intel.com; q=dns/txt; s=Intel;\n t=1775860348; x=1807396348;\n h=message-id:date:subject:to:cc:references:from:\n in-reply-to:content-transfer-encoding:mime-version;\n bh=sI4k6V+1k6e+jCEI2JmWXERg/KYJQXRWREVfwtqc5cU=;\n b=YSfeIRCRvwZhKbDPCOYaAubt//iueeWIR25cEbRvzNhOuXbbWyqF+H4a\n LvTgZevmJUa667GqvPVjmq80mEzSbO9VsrVfNme7orOw4zDlrFYTC/wih\n G2ivs4Qv8uKAMNWbWUus9N58P6PI+4APDXw7RWmoWeilgS3x6PPKAmJlw\n fmlT4RYYuDsjuES8wOns/Q88PJUNe8n02yrescjjp5ICI901AahrU+YWp\n nQwbO95npY0iKAb/YuX1QYsO/pyh7ob4R1Hx5P8rIdhYIxcJNqxdrR2XO\n Vhkeprt6LyxCDQrWw3f7AKwG7QGotgTHS8SiSQD8KRJQ3MRnQxLnTMmXi\n A==;","X-Mailman-Original-Authentication-Results":["smtp1.osuosl.org;\n dmarc=pass (p=none dis=none)\n header.from=intel.com","smtp1.osuosl.org;\n dkim=pass (2048-bit key,\n unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256\n header.s=Intel header.b=YSfeIRCR","dkim=none (message not signed)\n header.d=none;dmarc=none action=none header.from=intel.com;"],"Subject":"Re: [Intel-wired-lan] [PATCH iwl-net 3/4] ice: fix ready bitmap\n check for non-E822 devices","X-BeenThere":"intel-wired-lan@osuosl.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Intel Wired Ethernet Linux Kernel Driver Development\n <intel-wired-lan.osuosl.org>","List-Unsubscribe":"<https://lists.osuosl.org/mailman/options/intel-wired-lan>,\n <mailto:intel-wired-lan-request@osuosl.org?subject=unsubscribe>","List-Archive":"<http://lists.osuosl.org/pipermail/intel-wired-lan/>","List-Post":"<mailto:intel-wired-lan@osuosl.org>","List-Help":"<mailto:intel-wired-lan-request@osuosl.org?subject=help>","List-Subscribe":"<https://lists.osuosl.org/mailman/listinfo/intel-wired-lan>,\n <mailto:intel-wired-lan-request@osuosl.org?subject=subscribe>","Cc":"Aleksandr Loktionov <aleksandr.loktionov@intel.com>,\n Timothy Miskell <timothy.miskell@intel.com>","Errors-To":"intel-wired-lan-bounces@osuosl.org","Sender":"\"Intel-wired-lan\" <intel-wired-lan-bounces@osuosl.org>"}}]