[{"id":3678983,"web_url":"http://patchwork.ozlabs.org/comment/3678983/","msgid":"<20260418164837.380985-2-horms@kernel.org>","list_archive_url":null,"date":"2026-04-18T16:48:38","subject":"Re: [Intel-wired-lan] [PATCH iwl-next v2 3/3] igc: add support for\n forcing link speed without autonegotiation","submitter":{"id":82748,"url":"http://patchwork.ozlabs.org/api/people/82748/","name":"Simon Horman","email":"horms@kernel.org"},"content":"From: 'Simon Horman' \n\nThis is an AI-generated review of your patch. The human sending this\nemail has considered the AI review valid, or at least plausible.\nFull review at: https://sashiko.dev\n---\nigc: add support for forcing link speed without autonegotiation\n\nThis commit adds support to allow users to force 10/100 Mb/s link speed\nand duplex via ethtool when autonegotiation is disabled.\n\n> diff --git a/drivers/net/ethernet/intel/igc/igc_ethtool.c b/drivers/net/ethernet/intel/igc/igc_ethtool.c\n> index cfcbf2fdad6ea..5bd37d1be1688 100644\n> --- a/drivers/net/ethernet/intel/igc/igc_ethtool.c\n> +++ b/drivers/net/ethernet/intel/igc/igc_ethtool.c\n\n[ ... ]\n\n> @@ -2000,6 +2013,41 @@ static int igc_ethtool_get_link_ksettings(struct net_device *netdev,\n> \treturn 0;\n> }\n> \n> +/**\n> + * igc_handle_autoneg_disabled - Configure forced speed/duplex settings\n> + * @adapter: private driver structure\n> + * @speed: requested speed (must be SPEED_10 or SPEED_100)\n> + * @duplex: requested duplex\n> + *\n> + * Records forced speed/duplex when autoneg is disabled.\n> + * Caller must validate speed before calling this function.\n> + */\n> +static void igc_handle_autoneg_disabled(struct igc_adapter *adapter, u32 speed,\n> +\t\t\t\t\tu8 duplex)\n> +{\n> +\tstruct igc_mac_info *mac = &adapter->hw.mac;\n> +\n> +\tswitch (speed) {\n> +\tcase SPEED_10:\n> +\t\tmac->forced_speed_duplex = (duplex == DUPLEX_FULL) ?\n> +\t\t\tIGC_FORCED_10F : IGC_FORCED_10H;\n> +\t\tbreak;\n> +\tcase SPEED_100:\n> +\t\tmac->forced_speed_duplex = (duplex == DUPLEX_FULL) ?\n> +\t\t\tIGC_FORCED_100F : IGC_FORCED_100H;\n> +\t\tbreak;\n> +\tdefault:\n> +\t\tWARN_ONCE(1, \"Unsupported speed %u\\n\", speed);\n> +\t\treturn;\n> +\t}\n> +\n> +\tmac->autoneg_enabled = false;\n> +\n> +\t/* Half-duplex cannot support flow control per IEEE 802.3 */\n> +\tif (duplex == DUPLEX_HALF)\n> +\t\tadapter->hw.fc.requested_mode = igc_fc_none;\n> +}\n\nIf userspace issues an ethtool command without specifying duplex, the duplex\nvalue can be DUPLEX_UNKNOWN. In this case, forced_speed_duplex correctly\ndefaults to half-duplex since duplex == DUPLEX_FULL evaluates to false. \n\nHowever, since DUPLEX_UNKNOWN is not equal to DUPLEX_HALF, the check above\nfails, and the requested flow control mode remains unchanged. Could this leave\nflow control enabled on a forced half-duplex link, violating IEEE 802.3?\nShould this check be based on the resolved mac->forced_speed_duplex state\ninstead?\n\n[ ... ]\n\n> @@ -2071,14 +2120,20 @@ igc_ethtool_set_link_ksettings(struct net_device *netdev,\n> \t\t}\n> \t}\n> \n> +\tif (cmd->base.autoneg == AUTONEG_DISABLE &&\n> +\t cmd->base.speed != SPEED_10 && cmd->base.speed != SPEED_100) {\n> +\t\tnetdev_info(dev, \"Unsupported speed for forced link\\n\");\n> +\t\treturn -EINVAL;\n> +\t}\n> +\n> \twhile (test_and_set_bit(__IGC_RESETTING, &adapter->state))\n> \t\tusleep_range(1000, 2000);\n\nThis isn't a bug introduced by this patch, but does this ad-hoc\nsynchronization using bit flags circumvent proper locking guarantees? The\nnetworking subsystem guidelines forbid using bit flags as ad-hoc locks. \n\nUsing a bit flag in a polling loop bypasses lockdep analysis, fairness, and\nstrict memory ordering. Could this be replaced with a real synchronization\nmechanism like a mutex?","headers":{"Return-Path":"","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=NnXNTFeY;\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 4fyd8K2d1kz1yCv\n\tfor ; Sun, 19 Apr 2026 02:52:16 +1000 (AEST)","from localhost (localhost [127.0.0.1])\n\tby smtp4.osuosl.org (Postfix) with ESMTP id 23B4240F76;\n\tSat, 18 Apr 2026 16:52:10 +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 xn_RHZpyooB0; Sat, 18 Apr 2026 16:52:08 +0000 (UTC)","from lists1.osuosl.org (lists1.osuosl.org [140.211.166.142])\n\tby smtp4.osuosl.org (Postfix) with ESMTP id A06E440F70;\n\tSat, 18 Apr 2026 16:52:08 +0000 (UTC)","from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])\n by lists1.osuosl.org (Postfix) with ESMTP id 77E2A259\n for ; Sat, 18 Apr 2026 16:52:07 +0000 (UTC)","from localhost (localhost [127.0.0.1])\n by smtp4.osuosl.org (Postfix) with ESMTP id 5DD5440F70\n for ; Sat, 18 Apr 2026 16:52:07 +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 MEiJEYzwKfkm for ;\n Sat, 18 Apr 2026 16:52:06 +0000 (UTC)","from tor.source.kernel.org (tor.source.kernel.org\n [IPv6:2600:3c04:e001:324:0:1991:8:25])\n by smtp4.osuosl.org (Postfix) with ESMTPS id 60A0D40F6C\n for ; Sat, 18 Apr 2026 16:52:06 +0000 (UTC)","from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])\n by tor.source.kernel.org (Postfix) with ESMTP id 8AE7360138;\n Sat, 18 Apr 2026 16:52:04 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id 0DB15C19424;\n Sat, 18 Apr 2026 16:52:00 +0000 (UTC)"],"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= ","DKIM-Filter":["OpenDKIM Filter v2.11.0 smtp4.osuosl.org A06E440F70","OpenDKIM Filter v2.11.0 smtp4.osuosl.org 60A0D40F6C"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=osuosl.org;\n\ts=default; t=1776531128;\n\tbh=lJT6eUZ8/0wb0gv+fWpBt8xji6v9X7XIoCnYmfmk5Gg=;\n\th=From:To:Cc:Date:In-Reply-To:References:Subject:List-Id:\n\t List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe:\n\t From;\n\tb=NnXNTFeYayGHe3M/udpHM0hNH3a+NCTBrcS1RBs5cIskgsAVgQdzPGjnYTHVeKr1Y\n\t 3MN+gzQ8Utn26mLrLRajB4nz3G0QIEpBLJ+KY4TjFeJpAvotlwpfS5bEZyygg4Oj+E\n\t GEbzufvN3DMOYA/pKmS1qS2ghRB7kP7FeaQyK51hAz+cX1JgGOjFdq9Av8xywb3JjW\n\t GjmKaaw5TN7CHYmT7kfQeDLMHa9U6kOoqIgZxoeajiyoiwEar6u6cbOikgh0t1UA6X\n\t C7Av5ehRLp4v53DOrc3X3hhCiJawVXaxhaoDTmqsP2fDdTAjfuyvH7RFzxoqdc/ZfC\n\t eZ5Ns7hrfxtUg==","Received-SPF":"Pass (mailfrom) identity=mailfrom;\n client-ip=2600:3c04:e001:324:0:1991:8:25; helo=tor.source.kernel.org;\n envelope-from=horms@kernel.org; receiver=","DMARC-Filter":"OpenDMARC Filter v1.4.2 smtp4.osuosl.org 60A0D40F6C","From":"Simon Horman ","To":"khai.wen.tan@linux.intel.com","Cc":"'Simon Horman' , anthony.l.nguyen@intel.com,\n przemyslaw.kitszel@intel.com, andrew+netdev@lunn.ch, davem@davemloft.net,\n edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,\n intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,\n linux-kernel@vger.kernel.org, faizal.abdul.rahim@intel.com,\n hong.aun.looi@intel.com, khai.wen.tan@intel.com,\n faizal.abdul.rahim@linux.intel.com","Date":"Sat, 18 Apr 2026 17:48:38 +0100","Message-ID":"<20260418164837.380985-2-horms@kernel.org>","X-Mailer":"git-send-email 2.53.0","In-Reply-To":"<20260416015520.6090-4-khai.wen.tan@linux.intel.com>","References":"<20260416015520.6090-4-khai.wen.tan@linux.intel.com>","MIME-Version":"1.0","Content-Transfer-Encoding":"8bit","X-Mailman-Original-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple;\n d=kernel.org; s=k20201202; t=1776531124;\n bh=XMTZj1YxPkY22L6vssswSQjk4oTxVG3RPZgGbSOfif8=;\n h=From:To:Cc:Subject:Date:In-Reply-To:References:From;\n b=rKzdxscKKp1giWSsuSCO3jKQUC4b8sL/u/GsH00AIPnDBiOFJoqb+6gaZ64Cr6ODv\n K4N1QExtkRpDDRwGOlvYHPsn+kQOOUeOFYwtQza7gw7DCyUCcQQltn08GGsU8FNvX9\n XFH4j7PYOg+Mg4sCJDgKFHcgbadra4WCrK94J4fAkuf8JCj0ow8UCP1ehX1OCtAgT/\n dSf1NBAr93ssqP8u0Z7P8dOZ1mFG3FAivCr/GSgm2zRV8CJE4MpIsnM1ATPPng9N68\n xtinbU1VIwcPW6/o2Jqq708tUrlauGyQ7aipfDdgZ4LnQrCcJG7lco/Bhk63vOq04c\n TZ5P6Z7j6yNsg==","X-Mailman-Original-Authentication-Results":["smtp4.osuosl.org;\n dmarc=pass (p=quarantine dis=none)\n header.from=kernel.org","smtp4.osuosl.org;\n dkim=pass (2048-bit key,\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=rKzdxscK"],"Subject":"Re: [Intel-wired-lan] [PATCH iwl-next v2 3/3] igc: add support for\n forcing link speed without autonegotiation","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 ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"intel-wired-lan-bounces@osuosl.org","Sender":"\"Intel-wired-lan\" "}},{"id":3679201,"web_url":"http://patchwork.ozlabs.org/comment/3679201/","msgid":"<3481ae84-5c36-4591-94c1-78b70fff4d7b@linux.intel.com>","list_archive_url":null,"date":"2026-04-20T03:20:07","subject":"Re: [Intel-wired-lan] [PATCH iwl-next v2 3/3] igc: add support for\n forcing link speed without autonegotiation","submitter":{"id":88801,"url":"http://patchwork.ozlabs.org/api/people/88801/","name":"Abdul Rahim, Faizal","email":"faizal.abdul.rahim@linux.intel.com"},"content":"On 19/4/2026 12:48 am, Simon Horman wrote:\n> From: 'Simon Horman' \n> \n> This is an AI-generated review of your patch. The human sending this\n> email has considered the AI review valid, or at least plausible.\n> Full review at: https://sashiko.dev\n> ---\n> igc: add support for forcing link speed without autonegotiation\n> \n> This commit adds support to allow users to force 10/100 Mb/s link speed\n> and duplex via ethtool when autonegotiation is disabled.\n> \n>> diff --git a/drivers/net/ethernet/intel/igc/igc_ethtool.c b/drivers/net/ethernet/intel/igc/igc_ethtool.c\n>> index cfcbf2fdad6ea..5bd37d1be1688 100644\n>> --- a/drivers/net/ethernet/intel/igc/igc_ethtool.c\n>> +++ b/drivers/net/ethernet/intel/igc/igc_ethtool.c\n> \n> [ ... ]\n> \n>> @@ -2000,6 +2013,41 @@ static int igc_ethtool_get_link_ksettings(struct net_device *netdev,\n>> \treturn 0;\n>> }\n>> \n>> +/**\n>> + * igc_handle_autoneg_disabled - Configure forced speed/duplex settings\n>> + * @adapter: private driver structure\n>> + * @speed: requested speed (must be SPEED_10 or SPEED_100)\n>> + * @duplex: requested duplex\n>> + *\n>> + * Records forced speed/duplex when autoneg is disabled.\n>> + * Caller must validate speed before calling this function.\n>> + */\n>> +static void igc_handle_autoneg_disabled(struct igc_adapter *adapter, u32 speed,\n>> +\t\t\t\t\tu8 duplex)\n>> +{\n>> +\tstruct igc_mac_info *mac = &adapter->hw.mac;\n>> +\n>> +\tswitch (speed) {\n>> +\tcase SPEED_10:\n>> +\t\tmac->forced_speed_duplex = (duplex == DUPLEX_FULL) ?\n>> +\t\t\tIGC_FORCED_10F : IGC_FORCED_10H;\n>> +\t\tbreak;\n>> +\tcase SPEED_100:\n>> +\t\tmac->forced_speed_duplex = (duplex == DUPLEX_FULL) ?\n>> +\t\t\tIGC_FORCED_100F : IGC_FORCED_100H;\n>> +\t\tbreak;\n>> +\tdefault:\n>> +\t\tWARN_ONCE(1, \"Unsupported speed %u\\n\", speed);\n>> +\t\treturn;\n>> +\t}\n>> +\n>> +\tmac->autoneg_enabled = false;\n>> +\n>> +\t/* Half-duplex cannot support flow control per IEEE 802.3 */\n>> +\tif (duplex == DUPLEX_HALF)\n>> +\t\tadapter->hw.fc.requested_mode = igc_fc_none;\n>> +}\n> \n> If userspace issues an ethtool command without specifying duplex, the duplex\n> value can be DUPLEX_UNKNOWN. In this case, forced_speed_duplex correctly\n> defaults to half-duplex since duplex == DUPLEX_FULL evaluates to false.\n> \n> However, since DUPLEX_UNKNOWN is not equal to DUPLEX_HALF, the check above\n> fails, and the requested flow control mode remains unchanged. Could this leave\n> flow control enabled on a forced half-duplex link, violating IEEE 802.3?\n> Should this check be based on the resolved mac->forced_speed_duplex state\n> instead?\n>\n\nYou're right, thanks for pointing that out.\n\nThat said, it feels simpler to address it with [1]:\nif (duplex != DUPLEX_FULL)\n adapter->hw.fc.requested_mode = igc_fc_none;\n\nRather than [2]:\n if (mac->forced_speed_duplex == IGC_FORCED_10H ||\n mac->forced_speed_duplex == IGC_FORCED_100H)\n adapter->hw.fc.requested_mode = igc_fc_none;\n\nAre you okay with [1] ?\n\n> [ ... ]\n> \n>> @@ -2071,14 +2120,20 @@ igc_ethtool_set_link_ksettings(struct net_device *netdev,\n>> \t\t}\n>> \t}\n>> \n>> +\tif (cmd->base.autoneg == AUTONEG_DISABLE &&\n>> +\t cmd->base.speed != SPEED_10 && cmd->base.speed != SPEED_100) {\n>> +\t\tnetdev_info(dev, \"Unsupported speed for forced link\\n\");\n>> +\t\treturn -EINVAL;\n>> +\t}\n>> +\n>> \twhile (test_and_set_bit(__IGC_RESETTING, &adapter->state))\n>> \t\tusleep_range(1000, 2000);\n> \n> This isn't a bug introduced by this patch, but does this ad-hoc\n> synchronization using bit flags circumvent proper locking guarantees? The\n> networking subsystem guidelines forbid using bit flags as ad-hoc locks.\n> \n> Using a bit flag in a polling loop bypasses lockdep analysis, fairness, and\n> strict memory ordering. Could this be replaced with a real synchronization\n> mechanism like a mutex?\n\nIt looks like a worthwhile cleanup. However, it likely doesn’t belong in \nthis series, since the synchronization pattern predates these patches and \nis used throughout the igc driver (set_ringparam, set_pauseparam, \nset_channels, etc.). We could address it in different patch series and \nalign the other code paths at the same time ?","headers":{"Return-Path":"","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=egjiinG4;\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 4fzW2b6M3bz1yCv\n\tfor ; Mon, 20 Apr 2026 13:20:21 +1000 (AEST)","from localhost (localhost [127.0.0.1])\n\tby smtp4.osuosl.org (Postfix) with ESMTP id 8522F40483;\n\tMon, 20 Apr 2026 03:20:19 +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 yrIpUAAgJNDg; Mon, 20 Apr 2026 03:20:17 +0000 (UTC)","from lists1.osuosl.org (lists1.osuosl.org [140.211.166.142])\n\tby smtp4.osuosl.org (Postfix) with ESMTP id D1D8740437;\n\tMon, 20 Apr 2026 03:20:17 +0000 (UTC)","from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])\n by lists1.osuosl.org (Postfix) with ESMTP id DB108355\n for ; Mon, 20 Apr 2026 03:20:16 +0000 (UTC)","from localhost (localhost [127.0.0.1])\n by smtp2.osuosl.org (Postfix) with ESMTP id CCA81404EF\n for ; Mon, 20 Apr 2026 03:20:16 +0000 (UTC)","from smtp2.osuosl.org ([127.0.0.1])\n by localhost (smtp2.osuosl.org [127.0.0.1]) (amavis, port 10024) with ESMTP\n id VMReus_E_Cf3 for ;\n Mon, 20 Apr 2026 03:20:15 +0000 (UTC)","from mgamail.intel.com (mgamail.intel.com [198.175.65.12])\n by smtp2.osuosl.org (Postfix) with ESMTPS id 61FD44018B\n for ; Mon, 20 Apr 2026 03:20:15 +0000 (UTC)","from orviesa007.jf.intel.com ([10.64.159.147])\n by orvoesa104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 19 Apr 2026 20:20:14 -0700","from mohdfai2-mobl.gar.corp.intel.com (HELO [10.247.8.237])\n ([10.247.8.237])\n by orviesa007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 19 Apr 2026 20:20:11 -0700"],"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= ","DKIM-Filter":["OpenDKIM Filter v2.11.0 smtp4.osuosl.org D1D8740437","OpenDKIM Filter v2.11.0 smtp2.osuosl.org 61FD44018B"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=osuosl.org;\n\ts=default; t=1776655217;\n\tbh=CDbOcpEpwlCoe+cmcL5MxKFYd9FeAbNUbUef9MdqyjY=;\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=egjiinG4mUEFrlO1OxJ5yoUzos0w1BrPl7erY3Es4yF4wa5qLBbGM6XLyTHGQvOPS\n\t AdPSjzAsXZBb26hmXQa+AAkIscG5lA25j7336lBO4pJY5FD50k/w1sLJE4ZG8L70xr\n\t t6YEtn3/re1vyr/ZthHjUSEbWtGcfZX50ZiPCvVJd5sjvZYmE7SD3q5kXcSUtjlqRk\n\t KSLFxflB1Xi2NKXjza7LpiPZ5t657fs9RqKMLG9mohEb1wSBjA3dDbAtVHp0AzGAfX\n\t VCmx5ndGcIPFz1dfCRBLIzTscv1ciS0E2BJt/0/lFeHUgdQBmiLi6tlreKO7RvsynY\n\t q2oyigt4DrC4w==","Received-SPF":"Pass (mailfrom) identity=mailfrom; client-ip=198.175.65.12;\n helo=mgamail.intel.com; envelope-from=faizal.abdul.rahim@linux.intel.com;\n receiver=","DMARC-Filter":"OpenDMARC Filter v1.4.2 smtp2.osuosl.org 61FD44018B","X-CSE-ConnectionGUID":["eI4SSgJnS5myW+Y5Vnb4pA==","qPAi+K2FSGeq+PDZXEyAuw=="],"X-CSE-MsgGUID":["UXeC/2seRbGjrA+0kJrMxg==","eNtEGU/+Shq84y5c6COEFw=="],"X-IronPort-AV":["E=McAfee;i=\"6800,10657,11762\"; a=\"89032151\"","E=Sophos;i=\"6.23,189,1770624000\"; d=\"scan'208\";a=\"89032151\"","E=Sophos;i=\"6.23,189,1770624000\"; d=\"scan'208\";a=\"231880747\""],"X-ExtLoop1":"1","Message-ID":"<3481ae84-5c36-4591-94c1-78b70fff4d7b@linux.intel.com>","Date":"Mon, 20 Apr 2026 11:20:07 +0800","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","To":"Simon Horman , khai.wen.tan@linux.intel.com","Cc":"anthony.l.nguyen@intel.com, przemyslaw.kitszel@intel.com,\n andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,\n kuba@kernel.org, pabeni@redhat.com, intel-wired-lan@lists.osuosl.org,\n netdev@vger.kernel.org, linux-kernel@vger.kernel.org,\n faizal.abdul.rahim@intel.com, hong.aun.looi@intel.com, khai.wen.tan@intel.com","References":"<20260416015520.6090-4-khai.wen.tan@linux.intel.com>\n <20260418164837.380985-2-horms@kernel.org>","Content-Language":"en-US","From":"\"Abdul Rahim, Faizal\" ","In-Reply-To":"<20260418164837.380985-2-horms@kernel.org>","Content-Type":"text/plain; charset=UTF-8; format=flowed","Content-Transfer-Encoding":"8bit","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=1776655216; x=1808191216;\n h=message-id:date:mime-version:subject:to:cc:references:\n from:in-reply-to:content-transfer-encoding;\n bh=I96x05WWbxNDXdYnL1sEhcmWSmBoa7yu/uYaLcjrTYE=;\n b=Dgj2nrWv/oNhUfvezmbOV1vr9UfQ6lED1Lef+03Lux5P6bbjcb5vXl+e\n KwZZdYQ5uRJCPwoXwcXnVUCYsFaq7gMy7Yy5o03Z7iOn0UglcNClDcU5B\n GXSPTz/RrcnYx+gRImicGxSxiJdK4QPE5uvWdhCy6eeFoGuiv/pSG1+g1\n KXDe8TOU+0rUwks6kK6fGCivr43J/7EfezIqwOTMWuOzmNvsJjtGpgI/Y\n LUeaVB8WsyBIZazgqhPfHSv5zELdun0KQjYtpGhU9607uIxo5yCPOe8ec\n EZaD/AQ6NRmt/YK/2Fh6jvU1JB9apRpxHTTrvFo/cxJ77o/2OgfJtMCkH\n g==;","X-Mailman-Original-Authentication-Results":["smtp2.osuosl.org;\n dmarc=none (p=none dis=none)\n header.from=linux.intel.com","smtp2.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=Dgj2nrWv"],"Subject":"Re: [Intel-wired-lan] [PATCH iwl-next v2 3/3] igc: add support for\n forcing link speed without autonegotiation","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 ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"intel-wired-lan-bounces@osuosl.org","Sender":"\"Intel-wired-lan\" "}},{"id":3679437,"web_url":"http://patchwork.ozlabs.org/comment/3679437/","msgid":"<20260420153520.GR280379@horms.kernel.org>","list_archive_url":null,"date":"2026-04-20T15:35:20","subject":"Re: [Intel-wired-lan] [PATCH iwl-next v2 3/3] igc: add support for\n forcing link speed without autonegotiation","submitter":{"id":82748,"url":"http://patchwork.ozlabs.org/api/people/82748/","name":"Simon Horman","email":"horms@kernel.org"},"content":"On Mon, Apr 20, 2026 at 11:20:07AM +0800, Abdul Rahim, Faizal wrote:\n> \n> \n> On 19/4/2026 12:48 am, Simon Horman wrote:\n> > From: 'Simon Horman' \n> > \n> > This is an AI-generated review of your patch. The human sending this\n> > email has considered the AI review valid, or at least plausible.\n> > Full review at: https://sashiko.dev\n> > ---\n> > igc: add support for forcing link speed without autonegotiation\n> > \n> > This commit adds support to allow users to force 10/100 Mb/s link speed\n> > and duplex via ethtool when autonegotiation is disabled.\n> > \n> > > diff --git a/drivers/net/ethernet/intel/igc/igc_ethtool.c b/drivers/net/ethernet/intel/igc/igc_ethtool.c\n> > > index cfcbf2fdad6ea..5bd37d1be1688 100644\n> > > --- a/drivers/net/ethernet/intel/igc/igc_ethtool.c\n> > > +++ b/drivers/net/ethernet/intel/igc/igc_ethtool.c\n> > \n> > [ ... ]\n> > \n> > > @@ -2000,6 +2013,41 @@ static int igc_ethtool_get_link_ksettings(struct net_device *netdev,\n> > > \treturn 0;\n> > > }\n> > > +/**\n> > > + * igc_handle_autoneg_disabled - Configure forced speed/duplex settings\n> > > + * @adapter: private driver structure\n> > > + * @speed: requested speed (must be SPEED_10 or SPEED_100)\n> > > + * @duplex: requested duplex\n> > > + *\n> > > + * Records forced speed/duplex when autoneg is disabled.\n> > > + * Caller must validate speed before calling this function.\n> > > + */\n> > > +static void igc_handle_autoneg_disabled(struct igc_adapter *adapter, u32 speed,\n> > > +\t\t\t\t\tu8 duplex)\n> > > +{\n> > > +\tstruct igc_mac_info *mac = &adapter->hw.mac;\n> > > +\n> > > +\tswitch (speed) {\n> > > +\tcase SPEED_10:\n> > > +\t\tmac->forced_speed_duplex = (duplex == DUPLEX_FULL) ?\n> > > +\t\t\tIGC_FORCED_10F : IGC_FORCED_10H;\n> > > +\t\tbreak;\n> > > +\tcase SPEED_100:\n> > > +\t\tmac->forced_speed_duplex = (duplex == DUPLEX_FULL) ?\n> > > +\t\t\tIGC_FORCED_100F : IGC_FORCED_100H;\n> > > +\t\tbreak;\n> > > +\tdefault:\n> > > +\t\tWARN_ONCE(1, \"Unsupported speed %u\\n\", speed);\n> > > +\t\treturn;\n> > > +\t}\n> > > +\n> > > +\tmac->autoneg_enabled = false;\n> > > +\n> > > +\t/* Half-duplex cannot support flow control per IEEE 802.3 */\n> > > +\tif (duplex == DUPLEX_HALF)\n> > > +\t\tadapter->hw.fc.requested_mode = igc_fc_none;\n> > > +}\n> > \n> > If userspace issues an ethtool command without specifying duplex, the duplex\n> > value can be DUPLEX_UNKNOWN. In this case, forced_speed_duplex correctly\n> > defaults to half-duplex since duplex == DUPLEX_FULL evaluates to false.\n> > \n> > However, since DUPLEX_UNKNOWN is not equal to DUPLEX_HALF, the check above\n> > fails, and the requested flow control mode remains unchanged. Could this leave\n> > flow control enabled on a forced half-duplex link, violating IEEE 802.3?\n> > Should this check be based on the resolved mac->forced_speed_duplex state\n> > instead?\n> > \n> \n> You're right, thanks for pointing that out.\n> \n> That said, it feels simpler to address it with [1]:\n> if (duplex != DUPLEX_FULL)\n> adapter->hw.fc.requested_mode = igc_fc_none;\n> \n> Rather than [2]:\n> if (mac->forced_speed_duplex == IGC_FORCED_10H ||\n> mac->forced_speed_duplex == IGC_FORCED_100H)\n> adapter->hw.fc.requested_mode = igc_fc_none;\n> \n> Are you okay with [1] ?\n\nYes, [1] sounds sensible to me.\n\n> \n> > [ ... ]\n> > \n> > > @@ -2071,14 +2120,20 @@ igc_ethtool_set_link_ksettings(struct net_device *netdev,\n> > > \t\t}\n> > > \t}\n> > > +\tif (cmd->base.autoneg == AUTONEG_DISABLE &&\n> > > +\t cmd->base.speed != SPEED_10 && cmd->base.speed != SPEED_100) {\n> > > +\t\tnetdev_info(dev, \"Unsupported speed for forced link\\n\");\n> > > +\t\treturn -EINVAL;\n> > > +\t}\n> > > +\n> > > \twhile (test_and_set_bit(__IGC_RESETTING, &adapter->state))\n> > > \t\tusleep_range(1000, 2000);\n> > \n> > This isn't a bug introduced by this patch, but does this ad-hoc\n> > synchronization using bit flags circumvent proper locking guarantees? The\n> > networking subsystem guidelines forbid using bit flags as ad-hoc locks.\n> > \n> > Using a bit flag in a polling loop bypasses lockdep analysis, fairness, and\n> > strict memory ordering. Could this be replaced with a real synchronization\n> > mechanism like a mutex?\n> \n> It looks like a worthwhile cleanup. However, it likely doesn’t belong in\n> this series, since the synchronization pattern predates these patches and is\n> used throughout the igc driver (set_ringparam, set_pauseparam, set_channels,\n> etc.). We could address it in different patch series and align the other\n> code paths at the same time ?\n\nYes, agreed.","headers":{"Return-Path":"","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=ihnpZupI;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=osuosl.org\n (client-ip=140.211.166.136; helo=smtp3.osuosl.org;\n envelope-from=intel-wired-lan-bounces@osuosl.org;\n receiver=patchwork.ozlabs.org)"],"Received":["from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])\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 4fzqLt5L3dz1yD4\n\tfor ; Tue, 21 Apr 2026 01:35:32 +1000 (AEST)","from localhost (localhost [127.0.0.1])\n\tby smtp3.osuosl.org (Postfix) with ESMTP id 8414560BA6;\n\tMon, 20 Apr 2026 15:35:30 +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 qkll0I31DBGu; Mon, 20 Apr 2026 15:35:29 +0000 (UTC)","from lists1.osuosl.org (lists1.osuosl.org [140.211.166.142])\n\tby smtp3.osuosl.org (Postfix) with ESMTP id A57156105F;\n\tMon, 20 Apr 2026 15:35:29 +0000 (UTC)","from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])\n by lists1.osuosl.org (Postfix) with ESMTP id 71CA6259\n for ; Mon, 20 Apr 2026 15:35:28 +0000 (UTC)","from localhost (localhost [127.0.0.1])\n by smtp4.osuosl.org (Postfix) with ESMTP id 582E240B78\n for ; Mon, 20 Apr 2026 15:35:28 +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 I_80v6ZWGWaz for ;\n Mon, 20 Apr 2026 15:35:27 +0000 (UTC)","from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])\n by smtp4.osuosl.org (Postfix) with ESMTPS id 7BDAA40B57\n for ; Mon, 20 Apr 2026 15:35:27 +0000 (UTC)","from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])\n by sea.source.kernel.org (Postfix) with ESMTP id D5D5D44108;\n Mon, 20 Apr 2026 15:35:26 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id 6DF54C2BCB4;\n Mon, 20 Apr 2026 15:35:23 +0000 (UTC)"],"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= ","DKIM-Filter":["OpenDKIM Filter v2.11.0 smtp3.osuosl.org A57156105F","OpenDKIM Filter v2.11.0 smtp4.osuosl.org 7BDAA40B57"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=osuosl.org;\n\ts=default; t=1776699329;\n\tbh=N3trZqLikRis3QLAdPWoS4PuGAy+fE3neMliF1UAJyA=;\n\th=Date:From:To:Cc:References:In-Reply-To:Subject:List-Id:\n\t List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe:\n\t From;\n\tb=ihnpZupISUlJg8DNeol06U93zI45mJ+BL0DnPk/34NTGXthIf+okqpIwoceqAMLWv\n\t QvESqsyN6XnGj/CcCOY5raslK/9irdzDLVs7LenmXpaY7HzBO0br/zy91t/Yc1iGd4\n\t PR7vgYFOvrFEj++uZuzQTkSGOYiLAo2xq5D+F4kasoGF4foR2TkbYCpFvSpul9+UQY\n\t Mj4UYNMxivMrKJSRheNJnPTYi4zySnRNvAsv3doAvC8UkJYKB/+wA7Ot+NMA8g/9xz\n\t 86y8+AHbURg03oq1BIdFC4Oq1cGw01K837WEGUjc0BfKaz/2UCnZ7hQmVSk3B0opQL\n\t BmNkb42SN8vhA==","Received-SPF":"Pass (mailfrom) identity=mailfrom; client-ip=172.234.252.31;\n helo=sea.source.kernel.org; envelope-from=horms@kernel.org;\n receiver=","DMARC-Filter":"OpenDMARC Filter v1.4.2 smtp4.osuosl.org 7BDAA40B57","Date":"Mon, 20 Apr 2026 16:35:20 +0100","From":"Simon Horman ","To":"\"Abdul Rahim, Faizal\" ","Cc":"khai.wen.tan@linux.intel.com, anthony.l.nguyen@intel.com,\n przemyslaw.kitszel@intel.com, andrew+netdev@lunn.ch,\n davem@davemloft.net, edumazet@google.com, kuba@kernel.org,\n pabeni@redhat.com, intel-wired-lan@lists.osuosl.org,\n netdev@vger.kernel.org, linux-kernel@vger.kernel.org,\n faizal.abdul.rahim@intel.com, hong.aun.looi@intel.com,\n khai.wen.tan@intel.com","Message-ID":"<20260420153520.GR280379@horms.kernel.org>","References":"<20260416015520.6090-4-khai.wen.tan@linux.intel.com>\n <20260418164837.380985-2-horms@kernel.org>\n <3481ae84-5c36-4591-94c1-78b70fff4d7b@linux.intel.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"<3481ae84-5c36-4591-94c1-78b70fff4d7b@linux.intel.com>","X-Mailman-Original-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple;\n d=kernel.org; s=k20201202; t=1776699326;\n bh=IGDlVa4/d0HT3rb4xC7h1M2d+XyUMQQkRyNMsH9Y984=;\n h=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n b=KwYpiejqS9shzOnNgUMfR3fw6CPxszOp5vtWLAMWNP7WGEJRiI9ooz/L3XCqmKmFV\n OHPbGvr5/3C0evuskGsuj1B3HnfhjNtLfQtnORK3/y9dSj1mvfovc90KbkFNZ4Y6R8\n CjiPQANuKe50YJ0TaqZgSkvHWiP2HuOk4xWrpld3qMHpwe174zh3Ia/YSY3MzkL+G1\n syTcSRc0MAytBXGwsDMoDp04FLN4wCTI+y9d4XBI20Q4VFk58/KIiQxYhzIQ7PjfED\n wJWgWE1jJLGdp0BnsUsr8URNYL0JbAaKYyKHz6dRJnxiVSM2WHah4lufe9f7Qgn2fn\n 9XfahCH1sDWLA==","X-Mailman-Original-Authentication-Results":["smtp4.osuosl.org;\n dmarc=pass (p=quarantine dis=none)\n header.from=kernel.org","smtp4.osuosl.org;\n dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.a=rsa-sha256 header.s=k20201202 header.b=KwYpiejq"],"Subject":"Re: [Intel-wired-lan] [PATCH iwl-next v2 3/3] igc: add support for\n forcing link speed without autonegotiation","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 ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"intel-wired-lan-bounces@osuosl.org","Sender":"\"Intel-wired-lan\" "}}]