From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 1B1AB3E00A3 for ; Fri, 15 May 2026 16:21:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778862095; cv=none; b=rjQxdOs/EGJAYPsCwk10nxehX3IcOxqUL9USRTT/N5yjgvoAsjEVMrUHMaZb3M6A3dRSGd14FJi2qdZg0uacxqO7kZGGCsQkF2u2ZN4JdTCGAc4UHaHMO0AMAG++fa+WijtbhJHH9Qj5xH9Y24VSRFxunMrbJDASwc1lOdeAh90= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778862095; c=relaxed/simple; bh=VaLnYsZ5jUTj/7eXesrqYg9o6HiF7DOwNnzsogKf/3U=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=q3mZbomunCu0zdYJvXAskC7ZGkGWKda/0Ptip3ot1aKPmyjHra/yy+Afva35IQXXTPPEWZt7WOtvemSzAdaUPA2S2h1Od209CuwOP5bIMYoBhozz/LSTY0nguZzrZIkS2WaEnqfwWVqZa9veOSzLbaHqd2Di7tZZST/7bSimORI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ZsQkFL2X; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ZsQkFL2X" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 78525C2BCB0; Fri, 15 May 2026 16:21:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778862094; bh=VaLnYsZ5jUTj/7eXesrqYg9o6HiF7DOwNnzsogKf/3U=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ZsQkFL2XrcdsPySWMm/2bZcc8c+jL+wlftQ4S+isnHHkNcTMgJqXUB0+undHXT111 YwYkrxWp9OiUQHoMU0/QnqBAv2coM++RSk1/CB8zo4f89nhyQZc6kycKVtc2bXeh9I VdsDXWNSjvIdxlvMaVrRja5h82fjxyXLiBjp1h/q7emyQ0oG2wyDPcxLI8m2sOI2P0 jwGjQT5bIkk8W4BBiRE6oXHPXo0brHu0al3R7mwshOTWVlEqsMFdNG7J5fcVj8gYcq wlsDG8/Nb4NYJ18YBPVY/3mx4TUWXVsV/IYxRo96yCdV8I7J5B7UFkk2HF0L6JTWAr KMCXQS3tuaYcA== Date: Fri, 15 May 2026 17:21:30 +0100 From: Simon Horman To: "Korba, Przemyslaw" Cc: "intel-wired-lan@lists.osuosl.org" , "netdev@vger.kernel.org" , "Nguyen, Anthony L" , "Kitszel, Przemyslaw" , "Loktionov, Aleksandr" , "Kubalewski, Arkadiusz" Subject: Re: [PATCH iwl-net v2] ice: support SBQ posted writes with non-posted support for CGU Message-ID: <20260515162130.GA227382@horms.kernel.org> References: <20260508102247.826375-1-przemyslaw.korba@intel.com> <20260512092740.290008-2-horms@kernel.org> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Thu, May 14, 2026 at 11:58:20AM +0000, Korba, Przemyslaw wrote: > > > > > -----Original Message----- > > From: Simon Horman > > Sent: Tuesday, May 12, 2026 11:28 AM > > To: Korba, Przemyslaw > > Cc: 'Simon Horman' ; intel-wired-lan@lists.osuosl.org; netdev@vger.kernel.org; Nguyen, Anthony L > > ; Kitszel, Przemyslaw ; Loktionov, Aleksandr ; > > Kubalewski, Arkadiusz > > Subject: Re: [PATCH iwl-net v2] ice: support SBQ posted writes with non-posted support for CGU > > > > From: 'Simon Horman' > > > > This is an AI-generated review of your patch. The human sending this > > email has considered the AI review valid, or at least plausible. > > Full review at: https://sashiko.dev > > --- > > ice: support SBQ posted writes with non-posted support for CGU > > > > This commit introduces non-posted SBQ writes while allowing posted writes > > to skip completion waits. It also adds an SBQ flush by reading address 0 > > from PHY 0 before issuing a SYNC command to ensure writes are completed. > > > > > diff --git a/drivers/net/ethernet/intel/ice/ice_ptp_hw.c b/drivers/net/ethernet/intel/ice/ice_ptp_hw.c > > > index 24fb7a3e14d63..ec4c85ad12e4d 100644 > > > --- a/drivers/net/ethernet/intel/ice/ice_ptp_hw.c > > > +++ b/drivers/net/ethernet/intel/ice/ice_ptp_hw.c > > > @@ -352,6 +352,17 @@ void ice_ptp_src_cmd(struct ice_hw *hw, enum ice_ptp_tmr_cmd cmd) > > > static void ice_ptp_exec_tmr_cmd(struct ice_hw *hw) > > > { > > > struct ice_pf *pf = container_of(hw, struct ice_pf, hw); > > > + struct ice_sbq_msg_input msg = { > > > + .dest_dev = ice_sbq_dev_phy_0, > > > + .opcode = ice_sbq_msg_rd, > > > + }; > > > + int err; > > > + > > > + if (hw->mac_type != ICE_MAC_E810) { > > > + err = ice_sbq_rw_reg(hw, &msg, LIBIE_AQ_FLAG_RD); > > > + if (err) > > > + dev_warn(ice_hw_to_dev(hw), "Failed to flush SBQ: %d\n", err); > > > + } > > > > [ ... ] > > > > > @@ -4469,15 +4482,15 @@ static int ice_read_phy_reg_e810(struct ice_hw *hw, u32 addr, u32 *val) > > > */ > > > static int ice_write_phy_reg_e810(struct ice_hw *hw, u32 addr, u32 val) > > > { > > > - struct ice_sbq_msg_input msg = {0}; > > > + struct ice_sbq_msg_input msg = { > > > + .dest_dev = ice_sbq_dev_phy_0, > > > + .opcode = ice_sbq_msg_wr_p, > > > + .msg_addr_low = lower_16_bits(addr), > > > + .msg_addr_high = upper_16_bits(addr), > > > + .data = val > > > + }; > > > > Since ice_write_phy_reg_e810() is updated to use the posted write opcode > > (ice_sbq_msg_wr_p), it will skip the completion wait and return immediately. > > > > If the SBQ flush in ice_ptp_exec_tmr_cmd() explicitly skips E810 devices > > via the check for hw->mac_type != ICE_MAC_E810, does this leave E810 PHY > > writes entirely asynchronous and unguarded? > > > > Could this lead to a race condition where the writes have not actually > > completed before the SYNC_EXEC_CMD is executed? > > Hi, thanks for review! > With E810 only opcode 0x01 for writing is supported. > On E810, the FW always sends completion responses for opcode 0x01, so the driver waits for each write to complete. > On newer E8XX devices, opcode 0x01 is truly posted (no completion response), which is why the SBQ flush is needed before SYNC_EXEC_CMD. > Since E810 writes are synchronous (driver waits for completion), flushing SBQ is unnecessary - all writes are already complete when the function returns. > I can add comments explaining that, or make it a bit clearer in the code if you'd like 😊 Sorry, there was supposed to be some extra text along the lines of seeking clarification. Yes, I think it would be good to add a comment or something to the commit message about this. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 98EABCD343F for ; Fri, 15 May 2026 16:21:39 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 5C1DC83C0F; Fri, 15 May 2026 16:21:39 +0000 (UTC) X-Virus-Scanned: amavis at osuosl.org Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavis, port 10024) with ESMTP id Yd-Ry6LMYZIG; Fri, 15 May 2026 16:21:38 +0000 (UTC) X-Comment: SPF check N/A for local connections - client-ip=140.211.166.142; helo=lists1.osuosl.org; envelope-from=intel-wired-lan-bounces@osuosl.org; receiver= DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 8C94B842F3 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=osuosl.org; s=default; t=1778862098; bh=DzmAcrJQwdNDyvyO4kjC7sI5ncqInsi8No2bwy36jAA=; h=Date:From:To:Cc:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=Eca5wbYTwNZYMJ3i7D4uQoAnRJB2/u9C7kz9+ZFyWpFlfGg6JqRIaxBdeLSR7L2k4 qaup9DbKbxoy5ku6ULfW1oJn+5bZb7VYIy6bBhQ+lfzTIYunIYBORhCcIPYddgZdWa iFVJ9LlJR8Pzj+sWLpVNh3QFo5907hQN1YdTp421CHZoRtse9mRDJA7rncbg5fCl79 xKMQRTRPkuuepkhtuxNiRCkJy2tiBqqjf6dqWOjgOjZ3EObChSfZaDXgEoLazeuv5V l7KeVw8F4zS48A1u65/sLsytPPciQgqiMFAkKsf7bhQBlpUQSB9nRWrPlQRaQzQFZt 9vi/ykz/15X6w== Received: from lists1.osuosl.org (lists1.osuosl.org [140.211.166.142]) by smtp1.osuosl.org (Postfix) with ESMTP id 8C94B842F3; Fri, 15 May 2026 16:21:38 +0000 (UTC) Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists1.osuosl.org (Postfix) with ESMTP id F3CB4282 for ; Fri, 15 May 2026 16:21:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id D97A961633 for ; Fri, 15 May 2026 16:21:37 +0000 (UTC) X-Virus-Scanned: amavis at osuosl.org Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavis, port 10024) with ESMTP id eqHlYhqR3AGY for ; Fri, 15 May 2026 16:21:37 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=172.105.4.254; helo=tor.source.kernel.org; envelope-from=horms@kernel.org; receiver= DMARC-Filter: OpenDMARC Filter v1.4.2 smtp3.osuosl.org E822161632 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org E822161632 Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by smtp3.osuosl.org (Postfix) with ESMTPS id E822161632 for ; Fri, 15 May 2026 16:21:36 +0000 (UTC) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 35A1560098; Fri, 15 May 2026 16:21:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 78525C2BCB0; Fri, 15 May 2026 16:21:33 +0000 (UTC) Date: Fri, 15 May 2026 17:21:30 +0100 From: Simon Horman To: "Korba, Przemyslaw" Cc: "intel-wired-lan@lists.osuosl.org" , "netdev@vger.kernel.org" , "Nguyen, Anthony L" , "Kitszel, Przemyslaw" , "Loktionov, Aleksandr" , "Kubalewski, Arkadiusz" Message-ID: <20260515162130.GA227382@horms.kernel.org> References: <20260508102247.826375-1-przemyslaw.korba@intel.com> <20260512092740.290008-2-horms@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Mailman-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778862094; bh=VaLnYsZ5jUTj/7eXesrqYg9o6HiF7DOwNnzsogKf/3U=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ZsQkFL2XrcdsPySWMm/2bZcc8c+jL+wlftQ4S+isnHHkNcTMgJqXUB0+undHXT111 YwYkrxWp9OiUQHoMU0/QnqBAv2coM++RSk1/CB8zo4f89nhyQZc6kycKVtc2bXeh9I VdsDXWNSjvIdxlvMaVrRja5h82fjxyXLiBjp1h/q7emyQ0oG2wyDPcxLI8m2sOI2P0 jwGjQT5bIkk8W4BBiRE6oXHPXo0brHu0al3R7mwshOTWVlEqsMFdNG7J5fcVj8gYcq wlsDG8/Nb4NYJ18YBPVY/3mx4TUWXVsV/IYxRo96yCdV8I7J5B7UFkk2HF0L6JTWAr KMCXQS3tuaYcA== X-Mailman-Original-Authentication-Results: smtp3.osuosl.org; dmarc=pass (p=quarantine dis=none) header.from=kernel.org X-Mailman-Original-Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=ZsQkFL2X Subject: Re: [Intel-wired-lan] [PATCH iwl-net v2] ice: support SBQ posted writes with non-posted support for CGU X-BeenThere: intel-wired-lan@osuosl.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Intel Wired Ethernet Linux Kernel Driver Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-wired-lan-bounces@osuosl.org Sender: "Intel-wired-lan" On Thu, May 14, 2026 at 11:58:20AM +0000, Korba, Przemyslaw wrote: > > > > > -----Original Message----- > > From: Simon Horman > > Sent: Tuesday, May 12, 2026 11:28 AM > > To: Korba, Przemyslaw > > Cc: 'Simon Horman' ; intel-wired-lan@lists.osuosl.org; netdev@vger.kernel.org; Nguyen, Anthony L > > ; Kitszel, Przemyslaw ; Loktionov, Aleksandr ; > > Kubalewski, Arkadiusz > > Subject: Re: [PATCH iwl-net v2] ice: support SBQ posted writes with non-posted support for CGU > > > > From: 'Simon Horman' > > > > This is an AI-generated review of your patch. The human sending this > > email has considered the AI review valid, or at least plausible. > > Full review at: https://sashiko.dev > > --- > > ice: support SBQ posted writes with non-posted support for CGU > > > > This commit introduces non-posted SBQ writes while allowing posted writes > > to skip completion waits. It also adds an SBQ flush by reading address 0 > > from PHY 0 before issuing a SYNC command to ensure writes are completed. > > > > > diff --git a/drivers/net/ethernet/intel/ice/ice_ptp_hw.c b/drivers/net/ethernet/intel/ice/ice_ptp_hw.c > > > index 24fb7a3e14d63..ec4c85ad12e4d 100644 > > > --- a/drivers/net/ethernet/intel/ice/ice_ptp_hw.c > > > +++ b/drivers/net/ethernet/intel/ice/ice_ptp_hw.c > > > @@ -352,6 +352,17 @@ void ice_ptp_src_cmd(struct ice_hw *hw, enum ice_ptp_tmr_cmd cmd) > > > static void ice_ptp_exec_tmr_cmd(struct ice_hw *hw) > > > { > > > struct ice_pf *pf = container_of(hw, struct ice_pf, hw); > > > + struct ice_sbq_msg_input msg = { > > > + .dest_dev = ice_sbq_dev_phy_0, > > > + .opcode = ice_sbq_msg_rd, > > > + }; > > > + int err; > > > + > > > + if (hw->mac_type != ICE_MAC_E810) { > > > + err = ice_sbq_rw_reg(hw, &msg, LIBIE_AQ_FLAG_RD); > > > + if (err) > > > + dev_warn(ice_hw_to_dev(hw), "Failed to flush SBQ: %d\n", err); > > > + } > > > > [ ... ] > > > > > @@ -4469,15 +4482,15 @@ static int ice_read_phy_reg_e810(struct ice_hw *hw, u32 addr, u32 *val) > > > */ > > > static int ice_write_phy_reg_e810(struct ice_hw *hw, u32 addr, u32 val) > > > { > > > - struct ice_sbq_msg_input msg = {0}; > > > + struct ice_sbq_msg_input msg = { > > > + .dest_dev = ice_sbq_dev_phy_0, > > > + .opcode = ice_sbq_msg_wr_p, > > > + .msg_addr_low = lower_16_bits(addr), > > > + .msg_addr_high = upper_16_bits(addr), > > > + .data = val > > > + }; > > > > Since ice_write_phy_reg_e810() is updated to use the posted write opcode > > (ice_sbq_msg_wr_p), it will skip the completion wait and return immediately. > > > > If the SBQ flush in ice_ptp_exec_tmr_cmd() explicitly skips E810 devices > > via the check for hw->mac_type != ICE_MAC_E810, does this leave E810 PHY > > writes entirely asynchronous and unguarded? > > > > Could this lead to a race condition where the writes have not actually > > completed before the SYNC_EXEC_CMD is executed? > > Hi, thanks for review! > With E810 only opcode 0x01 for writing is supported. > On E810, the FW always sends completion responses for opcode 0x01, so the driver waits for each write to complete. > On newer E8XX devices, opcode 0x01 is truly posted (no completion response), which is why the SBQ flush is needed before SYNC_EXEC_CMD. > Since E810 writes are synchronous (driver waits for completion), flushing SBQ is unnecessary - all writes are already complete when the function returns. > I can add comments explaining that, or make it a bit clearer in the code if you'd like 😊 Sorry, there was supposed to be some extra text along the lines of seeking clarification. Yes, I think it would be good to add a comment or something to the commit message about this.