From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pidgin.makrotopia.org (pidgin.makrotopia.org [185.142.180.65]) (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 E97CD375F83; Thu, 19 Mar 2026 11:56:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.142.180.65 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773921380; cv=none; b=B2XIplfNp6tTr+B56dfEUEidhsmxrCTbgziHnAhr9kwtmBgddphopjYTySvFxXWxtu02gTYkx3gfqxI93A/zloW4jREzgo/g2oL08c1xpbNNMpdT1Zvb/KOi/apkYH76R0SmjerDnhcc/OMxdEWMfIcb9bEYghgTIX57qiWXJ6g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773921380; c=relaxed/simple; bh=U8S6+x8KALQvgwaexlGFBr++P357T8IURtV0VjjNlD4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=U+zxoVD9yxaqQ4Gulj+cbzCi5IxTZW7KJKF484kufhl1pTRes7MuG2aWoj342yYE8WC7oYd1acsX3yGfXSm2GWawHcxb6DybI2KnGhlaoLwBY8sWW8hawhmVB7NKP+FGTkG3atuIZGqPnUcX8kB81i0RmpBMdQnVT3xFO5Yv0Ig= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=makrotopia.org; spf=pass smtp.mailfrom=makrotopia.org; arc=none smtp.client-ip=185.142.180.65 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=makrotopia.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=makrotopia.org Received: from local by pidgin.makrotopia.org with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.99) (envelope-from ) id 1w3Byt-000000003kZ-2Gdp; Thu, 19 Mar 2026 11:56:03 +0000 Date: Thu, 19 Mar 2026 11:56:00 +0000 From: Daniel Golle To: Paolo Abeni Cc: Andrew Lunn , Vladimir Oltean , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Simon Horman , Russell King , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Frank Wunderlich , Chad Monroe , Cezary Wilmanski , Liang Xu , "Benny (Ying-Tsan) Weng" , Jose Maria Verdu Munoz , Avinash Jayaraman , John Crispin Subject: Re: [PATCH net-next v5 2/2] net: dsa: mxl862xx: implement bridge offloading Message-ID: References: <0cf66a043eff3585270785a35e821e9a44afd6b6.1773591297.git.daniel@makrotopia.org> <16a4ac6c-abde-4121-9032-7626640facbe@redhat.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16a4ac6c-abde-4121-9032-7626640facbe@redhat.com> On Thu, Mar 19, 2026 at 09:51:40AM +0100, Paolo Abeni wrote: > On 3/15/26 5:20 PM, Daniel Golle wrote: > > +static int mxl862xx_set_ageing_time(struct dsa_switch *ds, unsigned int msecs) > > +{ > > + struct mxl862xx_cfg param; > > + int ret; > > + > > + ret = MXL862XX_API_READ(ds->priv, MXL862XX_COMMON_CFGGET, param); > > AI review says: > > Is the param struct initialized here? Looking at MXL862XX_API_READ(), it > expands to mxl862xx_api_wrap() which writes the contents of the data buffer > to firmware MDIO registers before sending the GET command. This would send > uninitialized kernel stack data to the firmware hardware. > > Every other MXL862XX_API_READ() call site in the driver uses a > zero-initialized struct. For example, in mxl862xx_setup(): > > struct mxl862xx_cfg cfg = {}; > ... > ret = MXL862XX_API_READ(priv, MXL862XX_COMMON_CFGGET, cfg); > > Should param be initialized with = {} here? > While I agree that just sending over uninitialized memory is kinda ugly, for this specific firmware API call it is not a problem because it completely discards what ever is sent, and fully overwrites all struct members before sending it back to the host. Anyway zero-initializing it with {} is probably still good practise and I'll do that, so AI or static analysis tools don't complain about that.