From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from m16.mail.163.com (m16.mail.163.com [220.197.31.2]) (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 EAB2B21A447 for ; Mon, 15 Jun 2026 01:28:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=220.197.31.2 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781486938; cv=none; b=SVE8GCC+EPJsdX3n3RUA79qCvzb5Nm8V2WDfRz1c1Ug/t8+sgIthCBoXgzsoQYiAetAYFEX6nY2RmOq8F0/p0FIOEd4Ss0Xk5r9DIgdpXMVZcyGGimvkbdIpCfyUMpH11LpAwoVEJaQdgQdItFb/EusH9FQqm56vOeHZRiTzYwg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781486938; c=relaxed/simple; bh=p0PNIM+AdI194NEDzvHgcBoZhq48rNFDPdXQrXERr3c=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=KOGxsPASBWfulkBwjmPvOrJgC8x0pOWvwIvaB3spllgzLWeRZbzNoRU+YomPQ+xmPG1gDHm//aMHGCkvXF1EPp/GpzbFYY1CulmP07M5Xhu//2dTEQ7i2RZgjtdhD9qtiGlynufru5ubSmOlOsxo3niHc7lc8B9T3s5/GAo7Ymg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com; spf=pass smtp.mailfrom=163.com; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b=N7Eeqduo; arc=none smtp.client-ip=220.197.31.2 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=163.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b="N7Eeqduo" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=Message-ID:Date:MIME-Version:Subject:To:From: Content-Type; bh=M483btWre2cnhhj8gL56GG70ENRhHk5py6rwm6CMRmU=; b=N7Eeqduo/7+BR2+dxEpXDvc7w9quwS9MrtopAynm951PhPbQiXEY9d0IHyyMgW nVom+bFZ+bQID10cltGcxkj+0OoIg/pXFcPfI0IinZFiRPWD+176wnUcAUFUnaON WUXnuJpD87XBuKEC6z1l1NS/w9yxbn4SSXYkBUCS7Pz88= Received: from [10.42.20.136] (unknown []) by gzga-smtp-mtada-g1-3 (Coremail) with SMTP id _____wBXRPIwVS9qIyKeDA--.149S2; Mon, 15 Jun 2026 09:28:18 +0800 (CST) Message-ID: <6a4bb07e-dbfb-4017-b0c3-b01ef2fc5432@163.com> Date: Mon, 15 Jun 2026 09:28:16 +0800 Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net-next v1] e1000: Initialize phy_data to avoid unexpected values To: Andrew Lunn Cc: przemyslaw.kitszel@intel.com, anthony.l.nguyen@intel.com, netdev@vger.kernel.org, intel-wired-lan@lists.osuosl.org, Rongguang Wei References: <20260612080331.120096-1-clementwei90@163.com> <1578c474-ffbf-46f7-b906-49da4ea48142@lunn.ch> Content-Language: en-US From: Rongguang Wei In-Reply-To: <1578c474-ffbf-46f7-b906-49da4ea48142@lunn.ch> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-CM-TRANSID:_____wBXRPIwVS9qIyKeDA--.149S2 X-Coremail-Antispam: 1Uf129KBjvJXoW7uF1UAF48JrWxGw17Xr17trb_yoW8tF45pr 47Xa4qyF4UXr9Fg397Jw18Ary5X397t3yfCF4fuw1Ygr95JrWvqF1xKFWUGF1avwsrurWa vF1jvasxAan8AaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07UcSdkUUUUU= X-CM-SenderInfo: 5fohzv5qwzvxizq6il2tof0z/xtbC-hLHM2ovVTLRgQAA3q 在 2026/6/13 03:39, Andrew Lunn 写道: > On Fri, Jun 12, 2026 at 04:03:31PM +0800, Rongguang Wei wrote: >> From: Rongguang Wei >> >> The phy_data variable is not initialized. If e1000_read_phy_reg >> returns an error, phy_data will not point to a valid value from >> the PHY register, which may cause the regs_buff array to be populated >> with unexpected values. >> >> Signed-off-by: Rongguang Wei >> Change-Id: I46071b3b21a566f8da650168d38d6968251b077d > > What does this Change-Id mean? > Sorry, it just a auto generate id when I push this patch on my own repos. I forget to delete. >> --- >> drivers/net/ethernet/intel/e1000/e1000_ethtool.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/net/ethernet/intel/e1000/e1000_ethtool.c b/drivers/net/ethernet/intel/e1000/e1000_ethtool.c >> index 4dcbeabb3ad2..f068108c5004 100644 >> --- a/drivers/net/ethernet/intel/e1000/e1000_ethtool.c >> +++ b/drivers/net/ethernet/intel/e1000/e1000_ethtool.c >> @@ -327,7 +327,7 @@ static void e1000_get_regs(struct net_device *netdev, struct ethtool_regs *regs, >> struct e1000_adapter *adapter = netdev_priv(netdev); >> struct e1000_hw *hw = &adapter->hw; >> u32 *regs_buff = p; >> - u16 phy_data; >> + u16 phy_data = 0; > > if (hw->phy_type == e1000_phy_igp) { > e1000_write_phy_reg(hw, IGP01E1000_PHY_PAGE_SELECT, > IGP01E1000_PHY_AGC_A); > e1000_read_phy_reg(hw, IGP01E1000_PHY_AGC_A & > IGP01E1000_PHY_PAGE_SELECT, &phy_data); > regs_buff[13] = (u32)phy_data; /* cable length */ > > Isn't a cable length of 0 also unexpected? > > How does this patch actually make the situation better? > Uninitialized variables may be initialized to 0 by the system, explicit initialization is performed to avoid accidents. The 0 is from e1000_read_phy_reg_ex in e1000_main.c and e1000_power_down_phy when use e1000_read_phy_reg function the last paramenters is initialized 0. So I used this value. There are many other function which use e1000_read_phy_reg also not initialize the last paramenters eg. e1000_phy_reset_clk_and_crs. I can do it in V2. > > Andrew > > --- > pw-bot: cr