From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EC706381B0D for ; Mon, 20 Apr 2026 22:10:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=198.175.65.11 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776723049; cv=fail; b=V1kvCWuWsYuPusy9NePRuT/TM/g+8NF5KhrHRaoDO6FkOA+9V5JkzslaPwMUF4fDWX2Teb7Sp92MGkio3sfWpCbjcnJeRadAJwVjp/8SuKKq38BOaUrn41WU8c032D9SiZIQIGDzfrlKDjl/El9GyNvQtJnKq3WZydN1M0K+lTs= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776723049; c=relaxed/simple; bh=mnPCOs5stKyeAQeH5Sw0NITCBTvB40DqjnCwmu0jbkw=; h=Message-ID:Date:Subject:To:CC:References:From:In-Reply-To: Content-Type:MIME-Version; b=htbNS2WiTsBWD1V93NmI4UdTaqKIv9wAOoWtwXXTC61XmW+kInywmb294N1eZaf1hEIu9iMxDvIaqNJqJ2cnew54jF3kft54Xlxf/+XpYxsk/Aug+OAzjXSAHB2fl9qTI9GjyBUohCWjX1lE0HXgXk2tqPvNUNwpLHCkKGuNqwg= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=ef1MJpxL; arc=fail smtp.client-ip=198.175.65.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="ef1MJpxL" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1776723048; x=1808259048; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=mnPCOs5stKyeAQeH5Sw0NITCBTvB40DqjnCwmu0jbkw=; b=ef1MJpxLKM6ysY2WADCZz3pAGjdAFyR/mggBN2a1nhmXUG9Sn0Mu1eWF rzHxoLfOznz3xsrUirY67WxyDeWmBgi0MNDyCiZFB/Z5u8uOchiZCBMS/ BP7VXAwma7OSJy/JLBT0ucf9aVUuhxU3p6oYtXqSkKLihD/y7j8on3nht n1S8OtG4WMIRwwt0NFbOWSd6fypRkJ5kSZWWIousprcL4rDR8CzdvC/Tn v+MskrLvheIlBkMVKLMnGfj6dr0vxN8H/OQGvduBP0UdSPdlWtD197o09 RI692Z29LTyC6axdGg8O/8mhVdFISyAlBUhJABmXaYPopwI1zz+RG/+Yn g==; X-CSE-ConnectionGUID: bdgkmTY9QWCznF7YS5FF4A== X-CSE-MsgGUID: QgoF9WBNQIaRXnSGp3FdeQ== X-IronPort-AV: E=McAfee;i="6800,10657,11762"; a="87949939" X-IronPort-AV: E=Sophos;i="6.23,190,1770624000"; d="scan'208";a="87949939" Received: from orviesa009.jf.intel.com ([10.64.159.149]) by orvoesa103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Apr 2026 15:10:47 -0700 X-CSE-ConnectionGUID: dEK5G2eHT1q5NuXJ4gVs7A== X-CSE-MsgGUID: h+V1PACcR2OWfPg8hOzGHQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,190,1770624000"; d="scan'208";a="231721524" Received: from fmsmsx902.amr.corp.intel.com ([10.18.126.91]) by orviesa009.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Apr 2026 15:10:47 -0700 Received: from FMSMSX903.amr.corp.intel.com (10.18.126.92) by fmsmsx902.amr.corp.intel.com (10.18.126.91) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.37; Mon, 20 Apr 2026 15:10:46 -0700 Received: from fmsedg901.ED.cps.intel.com (10.1.192.143) by FMSMSX903.amr.corp.intel.com (10.18.126.92) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.37 via Frontend Transport; Mon, 20 Apr 2026 15:10:46 -0700 Received: from BYAPR05CU005.outbound.protection.outlook.com (52.101.85.40) by edgegateway.intel.com (192.55.55.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.37; Mon, 20 Apr 2026 15:10:45 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=DACUquxNgQQaggg/RxZnxkpFXSIHm52K9sJo1y7dV7OVbRVS/v9hFUHnM84HEDG1defmEpa9NKnSUxrXMxwcVtHMw9Lb5/qnska/9olxtGmzF/rTbi6cqjgXG/55D9DkO/qPv0IjjMG3rDHlMJyBlqWxq+/eKaPfg/mqn5xRHqufQ0yzSKffXka9582/ttFqZUNjc6fdd3Tu2heFCwt2Q/1Kk+URGNbqjq4ucGYbuvKPCk9O3UEObqW7yZ93UfwTtd6ZWLFcx1QNl1OnjlNxCKcHjP/puiGJayhrQuRwYsVGyd6cI+S3VLL4PSetjwPxidfsPD/5RV7O2OR2+gGlOQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; 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; bh=1hUkCsS0cbs7OYBu47xTgjx/C3O5C6KGhIsTo/IsRl0=; b=K0IfW8aE9SbCV5e60dnr2zlmKNf/LpI9MtMvlVtkwbcR8//sIgErq8ZxgDEO4/8j+Yyb+dfg/gi1bF27+d3xoT2e3zUVu1Hyyoddp6CbUW4WTAe/LMkSR1CFJy/kgtBqIT0mzVIM/bjXzf9oZW5UeIHaRXypSqdvAyU7+juFyVWo34mJ50lVkmcumXPnZDagPfC23uFI9Y43vEDTbm7f3zMzCgAE3ytnKiAWYgwecFdJLYso1UQn5DqBOpZvbn6cihIIDxFeyUCVkTTM84K4+FxOc8A22LLiR6gvJN70sm6AqcqQfpufvtN+/oCbhzX1wMA7ZTjTfghtq1sDHybqFQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; Received: from DS0PR11MB7579.namprd11.prod.outlook.com (2603:10b6:8:14d::5) by PH7PR11MB5916.namprd11.prod.outlook.com (2603:10b6:510:13d::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9846.15; Mon, 20 Apr 2026 22:10:43 +0000 Received: from DS0PR11MB7579.namprd11.prod.outlook.com ([fe80::4199:4cb5:cf88:e79e]) by DS0PR11MB7579.namprd11.prod.outlook.com ([fe80::4199:4cb5:cf88:e79e%5]) with mapi id 15.20.9846.014; Mon, 20 Apr 2026 22:10:43 +0000 Message-ID: <01f7d0c7-f7b5-4402-9636-db96e7555f86@intel.com> Date: Mon, 20 Apr 2026 15:10:41 -0700 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH iwl-net 3/4] ice: fix ready bitmap check for non-E822 devices To: Anthony Nguyen , Intel Wired LAN , , "Aleksandr Loktionov" CC: Grzegorz Nitka , Timothy Miskell , Aleksandr Loktionov References: <20260408-jk-even-more-e825c-fixes-v1-0-b959da91a81f@intel.com> <20260408-jk-even-more-e825c-fixes-v1-3-b959da91a81f@intel.com> Content-Language: en-US From: Jacob Keller 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: MW4PR04CA0035.namprd04.prod.outlook.com (2603:10b6:303:6a::10) To DS0PR11MB7579.namprd11.prod.outlook.com (2603:10b6:8:14d::5) Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS0PR11MB7579:EE_|PH7PR11MB5916:EE_ X-MS-Office365-Filtering-Correlation-Id: 4027d092-0045-4110-6dc1-08de9f29aa2f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|56012099003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: gdzq3FWyTY6Lw1uGCslkD3iuZtEdatoQnjbxAyLxd1xe1EmN2mqvSqOhOqay04f18XDbPeGOp+y+XsfvPyGkGumnaXqX5R9YAti8y/RJxobCO822BiQrfBm5ZIE3w5OyK0qvpcrNd9eOsIqe3IiY2+UtIlZizI/o+B8f0zHwfZD+jdyNOHP+DXhkwnR3cY6G0TWtx8ln+E+58K/lkDMPe9rQvCdmF29YNL/sUeLkJQPJFusTqW3j9Tb0WeZCh2fZwm07g55VvmNeLe5Pt8D8XesMkmM+C55U+LUHl08HQpEqvmkc+PFYwFNwfQpFmCKcJd6nr348iEHdjLT5wULlXK8gLRXnkEzPmoJ58ihmJWdhvp74Gw3J4tDqmFVtz27LUmf9UZ8dgruxD9u5YgTbfHlHZiOBHyEBRpHxz/4q8dv2kCTBw7w3eIwB7w5VLSzD9gzzmT6F1d0ZDKOKlQCfISfaSgcqzcjdnMaiQ1SOnoTbr9Pn9hKB8/TqeZPm5C99YEQqsN8yTBcdif6P+CrDjYoWJNopNRuIj4yRk54LKqHLzpAgYtrhjk9Gw7RyMUV5GfnNMDF7Ea9PaiRT1McyNS9Gdv1VuZ7N3pQsVLL9HMpLgQs6fN6XYdpYjUxj2kJkDEVo6V1f1tHaZAlaZOLaYaEag6Lf5BniZaI5NjFIN1Ed/HtRxVTfPWRkJeMXGDr+wQRTQh6Yt658ONmXHzLYWRQqZr3a+yt6Qt55b7cpuc4= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DS0PR11MB7579.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(56012099003)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?MWs2dll1d2R1d2g2NnhyVTI0U3daS1c4elZrUnhwS0xWZmlEcDNOUkNEc1hE?= =?utf-8?B?cjZjWHFoaEwvMmRzbFJ0MGRZM1MybVVDSENQS0N2ZjhZcExKdzYxRnpEUG4w?= =?utf-8?B?bGo2Vm5XditWL2s4Zk00Z3RGOENxWVEvTmRFMk10WHhIb1dIWm9TZEhwZXdB?= =?utf-8?B?UkNnR0ZrRzdlcWZjV0dzOFBLOHNwVVU0Q3gza3NXZFM4ak9kWDNHdGE2eU9q?= =?utf-8?B?OGZnaUFucjdTdmJrcjVCZTl5M2QwS0FzSEhtUHJWeG5uWFJiczhwN2p2a045?= =?utf-8?B?ME8wd004aEYyM0xYSnEzL20wS3FibGcyaGRnQWZlMXFnenQ5c0w0cVdBdTBJ?= =?utf-8?B?UTBodklzVWF0aElqMnZzSFovWVN6a3ExR3FxVTN5Tlc0YWUvL25JUFphcmVo?= =?utf-8?B?bDBqS3BMeXRpWHFpU1lYWDBaNnROMHp2WGhRYkE5ZzNvNmphZXF5d0Y1WFBw?= =?utf-8?B?QUdUc242VDROTmF4VW94alFOMlp0UHZnL2lYdmN6M1ZBTG5Wdm5qMjhHNFBX?= =?utf-8?B?T2w4Vjg1TnBCREZCYmRDdTdNeWVtRnhMOEdkRHlLeGxEVit1VkxZamxIR0lp?= =?utf-8?B?dWlWZUJQaElTeW9WZlM5MHExK3BwTWdlVEE4cUQraFJlaklXQTNmTVpyZ095?= =?utf-8?B?N0tpMDZldjFmaTBLTnB2SCt1aWtNQ2p6QkNwejk1MHlMb0ZLY1ZBU1VLNGs4?= =?utf-8?B?QjZOVVA0MXFOZ01WL1lzTStGRE1DeWw1U1VTSERLdlNsTnorVjBEa2hYRDRl?= =?utf-8?B?ZDVSTnhieVRWcG56M3pzcWdqVHhTQmQ0Z2J3U2RRbDkzMzMxbkF3UWV2Ynpy?= =?utf-8?B?Zmo4S2QweExOZ3VMaWhxUVkxdFFaOEE2TzBBMXExN0tNVlpkNUZZNEYzYmN1?= =?utf-8?B?YkE3dVJDZFZNbkFWcHZPSUFJTkYxMDQ0ODUvSEpzZXJDZ0NIQi85L3B3T0hh?= =?utf-8?B?ZCs0Q2pZR0tHdWRVQmF4Zi9WRHYzbHMyakpEK3ZqMWdHRHY5MlZ2QUtWbVg5?= =?utf-8?B?OVhoNSszV2owK1RldDRxb1JNeFFjdTlTUjdXQWNnMC9SZkR0Q3JIY1lXNUpQ?= =?utf-8?B?YzBwYTQrQnVJTDVWUzljeVE5cjMzWnJFZzFSZzVkTGErbVcyOUY0bHZOcHlH?= =?utf-8?B?VE9QTXdObmVjZmhPUjIwMXY3ME9lb3E0S3dSbGpncGtsbi9UYUJDbzFEeHRJ?= =?utf-8?B?UkdRYUJNeUFJaEtHVnJSb0Q0aHNXeTZRV1cvOXROMk1nTUMrYVBINE9jZjZC?= =?utf-8?B?UENmTlFpN1pQV0xyRm90ZTNEVFVSUEgzdW8xSWJDZVRnRExSUUhDSG9DcEcr?= =?utf-8?B?L1FFV0FBUm1TU0xpOUttS3hGTUg1eGhRalNxSDAyeklLckdMNGRXTWtzZ3p3?= =?utf-8?B?Q1ZwR0lHT0daSW80RDRrc3AwRUh2TGl4dVMvVk9MRjZHOG5vRno4QUNMRlNF?= =?utf-8?B?eWFkeWRGNVh1Mis3TlF2ZlZ2Um1Pb241eWF5QjNDTmZCUm5MU0QvNkJYUXVn?= =?utf-8?B?Q204TENraGN1a3licHV6QitPdER5dmVKWU1UdkVWT3k5MVU0MDlzUHkzT1VI?= =?utf-8?B?UGR6U3lHTlV1WXRQNWc1d1lZNlIvaXJkcXF5dk1TZ0x3SW1tMkpoMFFINzV3?= =?utf-8?B?Q2Q3bUQvcHlUZGFKR1h5MEdwdS90cHp3SXV2UjJJWlRVaXFhUitCUHBtbThN?= =?utf-8?B?QjFUZko4QnZHNEFzb0tzMDVMNFVYR0dNcUJncm1XcWhFdjlid01FOFpydWw5?= =?utf-8?B?dmVvMzRBUkVUWGhCR0oyQm1CaWx2N29hTWs2RHJDMUtJU0x3ZkxWL002LzRu?= =?utf-8?B?ZVhUekl0eDJlQlExcjNQRjhhaUlyZnRzMytHMXFGQVE0aU1PbVBiV1VJYnY3?= =?utf-8?B?citxVUhYVmlkZnQ5OU9tMXhhd2ltNUxBZFVJN1hPVkhVczNtc0dQZ2RPSkJW?= =?utf-8?B?ZUVNakdwUXVGSDlHRVpkZjFHaHh4b3FBUy9DV2FKY1dra0YyRUNmbmRXWlJ0?= =?utf-8?B?R2NmMDZoT1B1Q2QxSW9ubjV6b0NRZk5jRGtKbUVaZDhrUWptQ09nNHZEcWVv?= =?utf-8?B?NllUZzhKNnUrRm9ncFhwaDFQT3FsT05TM3pYS3YvcHM4QXZkSlZUQ1ZWclgv?= =?utf-8?B?U2luRCtjbGtNY3hnK2N2NU5zVGRqSWNBZXhZTlhyRFdkSzZlN1dyVGxWQXhz?= =?utf-8?B?OXBTVXNTR1FEcm5ESUdLOEIzMVNCSW1LSUlVOFpyc0VUVWpyYW1iSjJsRWZS?= =?utf-8?B?SWtmUkhRMStXMWY0UlBJMzc0RWwrTFBVL1JUbDAxWVFMSCt5SEhuL29hQklG?= =?utf-8?B?ZXBHOVZZV0lkTU1pMUlYSUJQbWREaWpFYXZJUEI4NWpWVlFWd3NLQT09?= X-Exchange-RoutingPolicyChecked: LWi2wH++Tw8Qe1Oec9TorGxRQHfF06BZul4ZJYVyIiJiXAa+ubpl8y+42m6SeJDyBwLYCq3zbHUdWTMSSxaDthTXuA0/G7FnR33mZF+o4fLB5EF7wfD7pl5Kc/XPpVEraXeEtIhfdc+9BvnNtZ11FPyAiazOW1wVTOgsktd7mXzL+XO42zCB7yzhTrJfifMA6E7e8foNNjyNNmBIwNKzv3SAGxUoq4Cr6TbzreImbhIDnvCsFDPo7JAvWAWV2QSJk48tsKw7gQp3WJow+nSvGen4rCFhzdsWGuY2NOvDZUD2IaXPL5vXfrIBqvb6F+9js+VSMop+Myz84QtLKvo5gw== X-MS-Exchange-CrossTenant-Network-Message-Id: 4027d092-0045-4110-6dc1-08de9f29aa2f X-MS-Exchange-CrossTenant-AuthSource: DS0PR11MB7579.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Apr 2026 22:10:43.3014 (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: jT1fStPPneib4wqpavPKACZZvSdmlMNHyPaMxlysFOa9H057/YMoxemmt8ot4XytIo/yHYuDi1AgAJdCf9BijrIENkSLBkR8DpffXcam6a8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR11MB5916 X-OriginatorOrg: intel.com On 4/8/2026 11:46 AM, Jacob Keller wrote: > The E800 hardware (apart from E810) has a ready bitmap for the PHY > indicating which timestamp slots currently have an outstanding timestamp > waiting to be read by software. > > This bitmap is checked in multiple places using the > ice_get_phy_tx_tstamp_ready(): > > * ice_ptp_process_tx_tstamp() calls it to determine which timestamps to > attempt reading from the PHY > * ice_ptp_tx_tstamps_pending() calls it in a loop at the end of the > miscellaneous IRQ to check if new timestamps came in while the interrupt > handler was executing. > * ice_ptp_maybe_trigger_tx_interrupt() calls it in the auxiliary work task > to trigger a software interrupt in the event that the hardware logic > gets stuck. > > For E82X devices, multiple PHYs share the same block, and the parameter > passed to the ready bitmap is a block number associated with the given > port. For E825-C devices, the PHYs have their own independent blocks and do > not share, so the parameter passed needs to be the port number. For E810 > devices, the ice_get_phy_tx_tstamp_ready() always returns all 1s regardless > of what port, since this hardware does not have a ready bitmap. Finally, > for E830 devices, each PF has its own ready bitmap accessible via register, > and the block parameter is unused. > > The first call correctly uses the Tx timestamp tracker block parameter to > check the appropriate timestamp block. This works because the tracker is > setup correctly for each timestamp device type. > > The second two callers behave incorrectly for all device types other than > the older E822 devices. They both iterate in a loop using > ICE_GET_QUAD_NUM() which is a macro only used by E822 devices. This logic > is incorrect for devices other than the E822 devices. > > For E810 the calls would always return true, causing E810 devices to always > attempt to trigger a software interrupt even when they have no reason to. > For E830, this results in duplicate work as the ready bitmap is checked > once per number of quads. Finally, for E825-C, this results in the pending > checks failing to detect timestamps on ports other than the first two. > > Fix this by introducing a new hardware API function to ice_ptp_hw.c, > ice_check_phy_tx_tstamp_ready(). This function will check if any timestamps > are available and returns a positive value if any timestamps are pending. > For E810, the function always returns false, so that the re-trigger checks > never happen. For E830, check the ready bitmap just once. For E82x > hardware, check each quad. Finally, for E825-C, check every port. > > The interface function returns an integer to enable reporting of error code > if the driver is unable read the ready bitmap. This enables callers to > handle this case properly. The previous implementation assumed that > timestamps are available if they failed to read the bitmap. This is > problematic as it could lead to continuous software IRQ triggering if the > PHY timestamp registers somehow become inaccessible. > > This change is especially important for E825-C devices, as the missing > checks could leave a window open where a new timestamp could arrive while > the existing timestamps aren't completed. As a result, the hardware > threshold logic would not trigger a new interrupt. Without the check, the > timestamp is left unhandled, and new timestamps will not cause an interrupt > again until the timestamp is handled. Since both the interrupt check and > the backup check in the auxiliary task do not function properly, the device > may have Tx timestamps permanently stuck failing on a given port. > > The faulty checks originate from commit d938a8cca88a ("ice: Auxbus devices > & driver for E822 TS") and commit 712e876371f8 ("ice: periodically kick Tx > timestamp interrupt"), however at the time of the original coding, both > functions only operated on E822 hardware. This is no longer the case, and > hasn't been since the introduction of the ETH56G PHY model in commit > 7cab44f1c35f ("ice: Introduce ETH56G PHY model for E825C products") > > Fixes: 7cab44f1c35f ("ice: Introduce ETH56G PHY model for E825C products") > Signed-off-by: Jacob Keller > Reviewed-by: Aleksandr Loktionov > --- > drivers/net/ethernet/intel/ice/ice_ptp_hw.h | 1 + > drivers/net/ethernet/intel/ice/ice_ptp.c | 40 ++++------ > drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 117 ++++++++++++++++++++++++++++ > 3 files changed, 132 insertions(+), 26 deletions(-) > > diff --git a/drivers/net/ethernet/intel/ice/ice_ptp_hw.h b/drivers/net/ethernet/intel/ice/ice_ptp_hw.h > index 9d7acc7eb2ce..1b58b054f4a5 100644 > --- a/drivers/net/ethernet/intel/ice/ice_ptp_hw.h > +++ b/drivers/net/ethernet/intel/ice/ice_ptp_hw.h > @@ -300,6 +300,7 @@ void ice_ptp_reset_ts_memory(struct ice_hw *hw); > int ice_ptp_init_phc(struct ice_hw *hw); > 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_check_phy_tx_tstamp_ready(struct ice_hw *hw); > int ice_ptp_one_port_cmd(struct ice_hw *hw, u8 configured_port, > enum ice_ptp_tmr_cmd configured_cmd); > > diff --git a/drivers/net/ethernet/intel/ice/ice_ptp.c b/drivers/net/ethernet/intel/ice/ice_ptp.c > index ada42bcc4d0b..34906f972d17 100644 > --- a/drivers/net/ethernet/intel/ice/ice_ptp.c > +++ b/drivers/net/ethernet/intel/ice/ice_ptp.c > @@ -2718,7 +2718,7 @@ static bool ice_any_port_has_timestamps(struct ice_pf *pf) > bool ice_ptp_tx_tstamps_pending(struct ice_pf *pf) > { > struct ice_hw *hw = &pf->hw; > - unsigned int i; > + int ret; > > /* Check software indicator */ > switch (pf->ptp.tx_interrupt_mode) { > @@ -2739,16 +2739,15 @@ bool ice_ptp_tx_tstamps_pending(struct ice_pf *pf) > } > > /* Check hardware indicator */ > - for (i = 0; i < ICE_GET_QUAD_NUM(hw->ptp.num_lports); i++) { > - u64 tstamp_ready = 0; > - int err; > - > - err = ice_get_phy_tx_tstamp_ready(&pf->hw, i, &tstamp_ready); > - if (err || tstamp_ready) > - return true; > + ret = ice_check_phy_tx_tstamp_ready(hw); > + if (ret < 0) { > + dev_dbg(ice_pf_to_dev(pf), "Unable to read PHY Tx timestamp ready bitmap, err %d\n", > + ret); > + /* Stop triggering IRQs if we're unable to read PHY */ > + return false; > } > > - return false; > + return ret; Aleks requested that I clarify this return with a comment, since he feels the implicit conversion to bool may be confusing. We do already check if its less than 0 above, which excludes converting negative values to "true", but it may not be obvious. I am going to apply a minor fixup when sending this to add a comment and make this return an explicit boolean check with "ret > 0" which is equivalent. Thanks, Jake