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 7D9EA2EB850; Tue, 19 Aug 2025 14:07:53 +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=1755612476; cv=none; b=a+t8tvefUAFlZ07TNJ2SzHH1QAI4BCFnjXAhykgtw1FX6Rb3lcWEjKqMHNw1Ie6nqYHVFUWjBhd3rf5JagDt8p6sz3fxE7yHlbP0fITF2cmoYJEDNsk6nwIoyQYbCJz4Y7/atzMzOapIcDO7i05ohrpYHsmp1jNgRntPm2VKx+4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1755612476; c=relaxed/simple; bh=XyPEOIutZF5XVSITy/v0DslxDYnWJy+0xlunS+qG4cE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=u/b4TX/0vo9R10lPwF14do6gvlFNbRQJtzcsxE8qMjqhKs+dwnO2HYIvostTX8r4ZC5mDugYJCA0T5fPyD4gjow42Mt5kvWreqvSl7Qd4y2g098sGVHfKSXdDAG4mBkb7jpVnsUVPq+Kitw8dlRdohOgoPDDCfEcW9qJqDT/+DE= 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.98.2) (envelope-from ) id 1uoMzz-000000003VL-4AgO; Tue, 19 Aug 2025 14:07:40 +0000 Date: Tue, 19 Aug 2025 15:07:32 +0100 From: Daniel Golle To: Andrew Lunn Cc: Vladimir Oltean , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Hauke Mehrtens , Simon Horman , Russell King , Florian Fainelli , Arkadi Sharshevsky , linux-kernel@vger.kernel.org, netdev@vger.kernel.org, Andreas Schirm , Lukas Stockmann , Alexander Sverdlin , Peter Christen , Avinash Jayaraman , Bing tao Xu , Liang Xu , Juraj Povazanec , "Fanni (Fang-Yi) Chan" , "Benny (Ying-Tsan) Weng" , "Livia M. Rosu" , John Crispin Subject: Re: [PATCH RFC net-next 06/23] net: dsa: lantiq_gswip: load model-specific microcode Message-ID: References: <5cabea37-2a10-4664-b02b-c803641aff1f@lunn.ch> Precedence: bulk X-Mailing-List: linux-kernel@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: <5cabea37-2a10-4664-b02b-c803641aff1f@lunn.ch> On Tue, Aug 19, 2025 at 03:17:31PM +0200, Andrew Lunn wrote: > > I didn't consider that the size of the array elements needs to be known > > when defining struct gswip_hw_info in lantiq_gswip.h. > > So the only reasonable solution is to make also the definition of > > struct gswip_pce_microcode into lantiq_gswip.h, so lantiq_pce.h won't > > have to be included before or by lantiq_gswip.h itself. > > What i've done in the past is define a structure which describes the > firmware. Two members, a pointer to the list of values, and a length > of the list of values. You can construct this structure using > ARRAY_SIZE(), and export it. It is true that with one more layer of indirection I could have a separate (allocated) struct gswip_pce_firmware with two elements .pce_microcode = &gswip_pce_microcode, .pce_microcode_size = ARRAY_SIZE(gswip_pce_microcode), However, see below why I don't think this would actually solve the whole problem. > You should then be able to put the odd > val4, val3, val2, val1 structure, and the macro together in one header > file, and use it in two places to define the firmware blobs for the > different devices. I think this is the root of the misunderstanding here. The odd val4, val3, val2, val1 struct is not only used to define the microcode instructions, but it is also used to load the microcode into the hardware, see https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/dsa/lantiq_gswip.c?h=v6.17-rc2#n743 Now, as long as there is only one header lantiq_pce.h defining such microcode along with the odd struct, all this is not a problem. However, the problem arises once there is more than one such header, which will be required to support the newer MaxLinear hardware. Which of the two (lantiq_pce.h or gsw1xx_pce.h?) is suppose to define the struct? Which of the two should be included in the share module ('lantiq_gswip_common') which will take care of loading the microcode into the hardware? (imho: none of them, both headers are hardware specific and should be included by the respective specific modules for either switch family)