From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 221343563F8 for ; Sat, 7 Feb 2026 22:14:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770502478; cv=none; b=CO+P4qfiuGMRH14B8tPbXpMzIR8Q3JrXN0Hml1IOL8V8GQXz7gp0Q4YQuGR/AzB8qTjgGNKT4KKO3Z6fMyYUQ7JsNhygEFEHjkTW/KZc8c8jf7k72oxQhlW4Q27hktP34J44S+jHya4Uk54WtcOdk86ZKusg/RGjGdv0YpD6Tws= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770502478; c=relaxed/simple; bh=wVV/OHkI3Z4KQtzVDooXk7EXxRMhF6PTB9BNiER4oB8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=EGqHau8Cri26eaozEIEq+xF+SPR8F2wlEx9pBPRiGBOGKM/lvmaItcRV+IKBqWyFVF2pSb0JGN9BlJTFMHf7Q5UJcH1RiRHRWJONCGhDa9iEQHO1VfJ8Rcms3mCmEYRIlAzpbQOFxCZgOXUSdV8SUe1nm1fVVJF9RRwdHNXtFEk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=AemQ0PYZ; arc=none smtp.client-ip=209.85.128.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="AemQ0PYZ" Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-4806b88d8c9so4299885e9.2 for ; Sat, 07 Feb 2026 14:14:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770502476; x=1771107276; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=3ZbWUdr0AzBddCE7/lwnLtwuvGPqtGInyCAxrwKAOjI=; b=AemQ0PYZ8p4Qv1JVbCgf2wcH2t80+L82mxQJRNFF+eLVEBvJ3UUSzuTTD1cBZKFcBA zJ/xH7MzNfswAxhtxkc9NelF3jCqlF106GZeIPLJH4KFQSPHz/VZpaDXB7eSbXYqP/Sg P0b+620E/VORfEWYXKAGfVnejoPKDj7SSDI8bpYG4VyEyMVrifcWlGFYCt2cfXDJX4ez 6cTaqjK3mo7pdNbNsO1V6NBmsYX3oce0DcAKVNacnh59tvQtV9VwEBH7QvUkADyw7CTx rZkrm4PP9nRo4wVhTTpInndFDSG/mpv72253Fhyr0KmMgh2SGR2RYfbqWlK9IohNS45A MsMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770502476; x=1771107276; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=3ZbWUdr0AzBddCE7/lwnLtwuvGPqtGInyCAxrwKAOjI=; b=ded3AICKue/h0t5vMV0CQjfNaElrM936kEUKeID5Pns0SNxJGOThhu/hMSj/pJBPqJ +xt99ONwc68PDwcgr24B54CT02FshzVkz9iv2LW1owNtpZ4x/4ikJQc9o/Wft/MbdWeK XGdVKHuhDRsIxQweAspD+JSN+OCTDixcKdBhdwJ70e7s6AsHmOISXhdASkr4U51FDbLG 0TOQZWOqUb6/FpxB2t4KDPBNjRMB2jiR02nSgB0K3lqQGQBOQaJ/TzV0myjkcjbXp5/B omby+2zDHKU4V5CISbxDYQVxRv3o9vm6A1JfAJ1Ox/3aGlqnhfoEqMOjR1rzqKVF3xab 3rLQ== X-Forwarded-Encrypted: i=1; AJvYcCX/BXZip5z07ZzCS+eFjJQN9hMJNaACvmnUPoE6Cm0XBcfvgyK48uit/vUE4Tenmxef/n3IAZkTe9Yx7Dg=@vger.kernel.org X-Gm-Message-State: AOJu0Yw0G7UNHf5f9uNuCIkiL3SYvVLqOHLpqxrm7ZkhJ5YbbCnrJn/R PTVvxzKAjJYqAWp87sfQe/AUz4u9NDgETqW4shk/TM2S1JRKrW+zHJK/ X-Gm-Gg: AZuq6aIcv1oMbyIDg8jckgkf6fvy/JuYsiSdI+1+4v8SZnbNtNW3w5tdY6/vblmrF5d yUbYN3kuv52PgBzgGcEkkrVMfcldmMFJOJhdl7/O/vIigRnqUCFHFcnhi0m9C1lVXPX8DyGIBLo /UdvgP7fP72et+X4SCcnq7CRouzLpOpLRhonPCkDdga9yeX/kmI7lWozrRzlkWJTcG7vndOSW0b AjorNEobjC5ZL4Bix00IHRbDv8Z4MgKahRUVOebcFP4zuGcxxUgHrGOCWK6BCqHvTi3PK2e9N4x 2XyL6AeQlAMfuuShcs2BM4uT/OIULP7E2Fma2tcKu4NqlxcIdq5Op3Q7lePuq/5TW+dylNOC4nA 2uNtckDcWWK9DypHm1MnAu1lZpkwQR/dPfOeT/nUVKBOHFrBqagNL2FwxVX/y2QUBnDJLUXjnvY +71tQ= X-Received: by 2002:a05:600c:c173:b0:477:7a78:3000 with SMTP id 5b1f17b1804b1-4832022a52emr67879265e9.6.1770502476379; Sat, 07 Feb 2026 14:14:36 -0800 (PST) Received: from skbuf ([2a02:2f04:d501:d900:c705:d6fa:62de:90a5]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43631c8d378sm9125185f8f.21.2026.02.07.14.14.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 07 Feb 2026 14:14:35 -0800 (PST) Date: Sun, 8 Feb 2026 00:14:31 +0200 From: Vladimir Oltean To: Daniel Golle Cc: Jakub Kicinski , Andrew Lunn , "David S. Miller" , Eric Dumazet , Paolo Abeni , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Heiner Kallweit , Russell King , Simon Horman , netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Frank Wunderlich , Chad Monroe , Cezary Wilmanski , Liang Xu , John Crispin Subject: Re: [PATCH net-next v13 4/4] net: dsa: add basic initial driver for MxL862xx switches Message-ID: <20260207221431.y4cckfsrbmhzs6ot@skbuf> References: <2da8267175bfe7b8ff92d67ba5aa88755fab1710.1770211259.git.daniel@makrotopia.org> <20260205182117.41618f8d@kernel.org> <20260206133418.vxui223u4d6jdpql@skbuf> 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: On Fri, Feb 06, 2026 at 04:43:19PM +0000, Daniel Golle wrote: > I've spent an hour studying the pack_fields() API and it's (well > written) documentation. The only example of it's use in the current > kernel I could find is the Intel E800 (ICE) driver. And there it does > make sense as it is handling conversion between CPU and hardware formats > in the hotpath for DMA descriptors, a total of 3 different structs, each > with their individual accessor functions. > > Using this approach for this switch driver would require writing a lot > of boilerplate code, accessor functions for each and every struct, > and a struct definition once unpacked for the host platform and then > again using the PACKED_FIELD(...) notation for the hardware format. > Surely, most of that could be auto-generated using the existing > vendor drivers API definition. Yet (at least to me) it feels like > over-engineering and also it would require rewriting most of the driver > which has been discussed for almost 2 months now. > > Also note that the driver doesn't need the naturally aligned version of > all these structs in native CPU endian -- they are not used for further > processing anything, you can see that because they aren't ever used as a > function parameters, but only ever as exchange formats when > communicating with the firmware. OK. If the fields were packed more densely maybe the tradeoff would have looked differently then. But you're talking to an MCU and not to hardware. And you don't need to keep a local direct representation of the data passed through those packed buffers. Your arguments are valid. > Maybe I'm missing something obvious here and there is a more simple way > to use this API, some generic macros using compiler introspection to > magically handle everything without needing to write packed and unpacked > struct definitions and individual pack/unpack boiler-plate functions for > each struct. If so, please provide me with an example or explain how you > imagine the pack_fields() API to be used in the context of this driver > and it's total of at more than 30 different structs which will be used > for all the different firmware function I will need to use in order to > implement phylink_pcs as well as the various offloading and VLAN-related > functionality the driver should have in the end (ie. the structs you > currently see in the mxl862xx-api.h file are just a fraction of what I > hope to add there by follow-up series) No, the API usage example is how you imagine it. There's a structure where you only need to pull in the fields you care about (and in whatever order), rather than every other unrelated tidbit you don't currently need and possibly never will (like ingress_marking_mode, etc etc). And another array of PACKED_FIELD() where you say where each field goes. You probably don't need a pack_fields() and an unpack_fields() call for the same data structure in most cases, just one or the other.