From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com [209.85.221.54]) (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 95BAE3D8138 for ; Thu, 30 Apr 2026 08:55:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777539328; cv=none; b=ojxY62auKoW6ic1mWT7DQ8E7uUCm7k00Ei4ktCS03VW7U6IWV5jnD/hVSplJZPU3f9a9v+RxNUqTD3Gh0sHYbb3trxm6Mrhk0LnZKLTq4K5vEFdFJu9U7SSNOT7P2pcIrV8et4VBHhEEIwTJGu2mj8qxP/FrAwIAZgKMGmvfjBI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777539328; c=relaxed/simple; bh=Pqq8zSAcOFFR5+YaBlC+lfkekk7615G+YO4hKhKWJCU=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=sZzKP8Ex+gu9a+jIHdD/P1hsD+eZj82Pbnf/tqqRVxHxiSoCk3iX4Qd+47n4aw3X3cT0Hl2DQKfFrnNSRIePhNvnVEFbVyxN3TqccL3xkRLaNyZ/CAvSK2bfUvcxlt5oRn8vYUAftvAFNR8iKxhd3lA60gzVHpnU3Cd7EqyyRZ4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=baylibre.com; spf=pass smtp.mailfrom=baylibre.com; dkim=pass (2048-bit key) header.d=baylibre-com.20251104.gappssmtp.com header.i=@baylibre-com.20251104.gappssmtp.com header.b=sG9T6KPC; arc=none smtp.client-ip=209.85.221.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=baylibre.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=baylibre.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=baylibre-com.20251104.gappssmtp.com header.i=@baylibre-com.20251104.gappssmtp.com header.b="sG9T6KPC" Received: by mail-wr1-f54.google.com with SMTP id ffacd0b85a97d-449e96a8a80so3112f8f.3 for ; Thu, 30 Apr 2026 01:55:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20251104.gappssmtp.com; s=20251104; t=1777539323; x=1778144123; darn=vger.kernel.org; h=in-reply-to:references:content-transfer-encoding:to:from:subject:cc :message-id:date:mime-version:from:to:cc:subject:date:message-id :reply-to; bh=oTklDTNdxgMiOr8HV0Z6gDUQcK4MMB7dBQkYfU4NXYc=; b=sG9T6KPC866Z2GUGB8sKaxyruk7UrFIkcWncaHwiNWzI3GPtrpX2vLWbABrn1zff0C FBCLzqJU+iA18ZKv+bdPJq5sw4Dn6MoQc/5+JUngXqaw0KW4k/wR0EMQdYt1aYIVOurC v+45ReIUit/MbA+ap2CMIyYNoCqEHfO3eohN4LpbRwZTr8NmHUgERO4cbvrB1He995ip oiFRc9o7uAl4CPBh+toq6+zBVycPnPi1kGp+o/HKHsWIy0yMWRB1XekrXSoTl2uUuvm/ KRHaaZVUHY7ijfFLaceAQh+Z54wAB1fT5XCgGkLmCWKvO4dpHRS6+zYGagcFmu4JCwTw R09A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777539323; x=1778144123; h=in-reply-to:references:content-transfer-encoding:to:from:subject:cc :message-id:date:mime-version:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=oTklDTNdxgMiOr8HV0Z6gDUQcK4MMB7dBQkYfU4NXYc=; b=n/a4b5GRMNzkj5fYmZHFGz/A1qroESFphDMGTSIHuhmE22BohWnbyujuckV4qxPtWL 9KGgRd3XooUYFIYTpHsaEfrewqk5+wjgaKlSotdDVeqzP6bqi84m+TrWlWVw+EtjPjGN 1E/cDQf1E7LpzHFhBs3i/fY0Cq8Ban+8Hih4F06xb6x1aEsTklClEvrwYza051Meq+Jf LJ+9u5Ce6T4RNq4oS01d00JvT8K4wK1ZUMe/vOnLSkvV4dABpDS5oINbxDHFW3hIT0cP +MmWGkWEW69Zixu+uDp070y4jTwNIeIjvcAwQHh/uhXtflizN31SVU16757nks3puqbP pjRA== X-Forwarded-Encrypted: i=1; AFNElJ/2pOLJ0l48ekcePeaKz3RlLvBxOGtHwgWrcb1UXjk0x90amI6qkMBOwFlbtPCgAR1VRWcJklCY24KK9ko=@vger.kernel.org X-Gm-Message-State: AOJu0Yz3YnA4q/HAvYS2DV3oe/ScuYnlolQSdEnafwnP1Tq9mmR2r3jn ymwzT4sLYnZxFdKUZJr2YFbMIbubGUAki4wiItjTsytvrdllI3CwKTzrqbXaZ4LoCx8= X-Gm-Gg: AeBDieuTIaboRxiQHy+u0RPQe3MZJL5FkARw4nm+om1MhgusjLesrabSGldudkMrtB5 FHeAr25MEPFd3swxORjjRWvFCOOeli4c1GlvltsUvWutDYpxeeybEdj5LTnwox9kUEl8Y5DXnMp rTQFocKnCot75ZrcwqpTKaQaSFxiJceJ0MdczIDxlA9W6eo2xltHMyvG4uti54R0SaHmv+8hxL0 XtwBuGDHfB083h60rh87ol9VFR8wdUwKIpU4Ly2XbGB3vVnLs+r/jAfS1P63LnabcbHtXymtjsF PRenFge9ODzWtcCwkLLwyAlbGi2ZsqxlT6sXdqLAlTVvobq6go0kwcO9cYWQRhYdggcC+9LasRL ocE0TeBNeWC0eGQSwSDYU7nxUaGgMZiv3SCpDoCLEuVZgPx9Ga6eP2CbGByL2TpPNM9tM30nZu0 FjNVv1AzmzcTsGGWF0B1MPjXFvLx8= X-Received: by 2002:a05:6000:26d1:b0:43e:a703:3665 with SMTP id ffacd0b85a97d-4493f42ced4mr3244142f8f.25.1777539322750; Thu, 30 Apr 2026 01:55:22 -0700 (PDT) Received: from localhost ([2001:4090:a246:83ca:298c:ceb1:1a:f428]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-447b7ca5fe6sm11988989f8f.32.2026.04.30.01.55.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 Apr 2026 01:55:21 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: multipart/signed; boundary=49f7733329a22fff4b83a1680bdebfd7a9830dc80234132c7fb08fa112fd; micalg=pgp-sha512; protocol="application/pgp-signature" Date: Thu, 30 Apr 2026 10:55:14 +0200 Message-Id: Cc: "Markus Schneider-Pargmann" , "Steffen Klassert" , "David Dillow" , "Ion Badulescu" , "Mark Einon" , "Rasesh Mody" , , "Sudarsana Kalluru" , "Manish Chopra" , "Potnuri Bharat Teja" , "Denis Kirjanov" , "Jijie Shao" , "Jian Shen" , "Cai Huoqing" , "Fan Gong" , "Tony Nguyen" , "Przemek Kitszel" , "Tariq Toukan" , "Saeed Mahameed" , "Leon Romanovsky" , "Mark Bloch" , "Ido Schimmel" , "Petr Machata" , "Yibo Dong" , "Simon Horman" , "Heiner Kallweit" , , "Jiri Pirko" , "Francois Romieu" , "Daniele Venzano" , "Samuel Chessman" , "Jiawen Wu" , "Mengyuan Lou" , "Kevin Curtis" , "Arend van Spriel" , "Stanislav Yakovlev" , "Richard Cochran" , "Kees Cook" , "Thomas Gleixner" , "Thomas Fourier" , "Ingo Molnar" , "Kory Maincent" , "Zilin Guan" , "Marco Crivellari" , "Vadim Fedorenko" , "Jacob Keller" , "Philipp Stanner" , "Bjorn Helgaas" , "Yeounsu Moon" , "Denis Benato" , "Peiyang Wang" , "Yonglong Liu" , "Andy Shevchenko" , "Yicong Hui" , "Randy Dunlap" , "MD Danish Anwar" , "Nathan Chancellor" , "Sai Krishna" , "Ethan Nelson-Moore" , "Larysa Zaremba" , "Joe Damato" , "Double Lo" , "Chi-hsien Lin" , "Colin Ian King" , , , , , , , , , , Subject: Re: [PATCH net-next] net: Consistently define pci_device_ids using named initializers From: "Markus Schneider-Pargmann" To: =?utf-8?b?VXdlIEtsZWluZS1Lw7ZuaWcgKFRoZSBDYXBhYmxlIEh1Yik=?= , "Michael Grzeschik" , "Andrew Lunn" , "David S. Miller" , "Eric Dumazet" , "Jakub Kicinski" , "Paolo Abeni" , "Marc Kleine-Budde" , "Vincent Mailhol" , "Krzysztof Halasa" , "Johannes Berg" Content-Transfer-Encoding: quoted-printable X-Mailer: aerc 0.21.0-126-g9e77103592fe References: <20260428171845.2288395-2-u.kleine-koenig@baylibre.com> In-Reply-To: <20260428171845.2288395-2-u.kleine-koenig@baylibre.com> --49f7733329a22fff4b83a1680bdebfd7a9830dc80234132c7fb08fa112fd Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Hi Uwe, On Tue Apr 28, 2026 at 7:18 PM CEST, Uwe Kleine-K=C3=B6nig (The Capable Hub= ) wrote: > ... and PCI device helpers. > > The various struct pci_device_id arrays were initialized mostly by one > the PCI_DEVICE macros and then list expressions. The latter isn't easily > readable if you're not into PCI. Using named initializers is more > explicit and thus easier to parse. > > Also use PCI_DEVICE* helper macros to assign .vendor, .device, > .subvendor and .subdevice where appropriate and skip explicit > assignments of 0 (which the compiler takes care of). > > The secret plan is to make struct pci_device_id::driver_data an > anonymous union (similar to > https://lore.kernel.org/all/cover.1776579304.git.u.kleine-koenig@baylibre= .com/) > and that requires named initializers. But it's also a nice cleanup on > its own. > > This change doesn't introduce changes to the compiled pci_device_id > arrays. Tested on x86 and arm64. > > Signed-off-by: Uwe Kleine-K=C3=B6nig (The Capable Hub) > --- > Hello, > > the mentioned follow-up quest allows to do > > PCI_DEVICE(0x1571, 0xa203), > + .driver_data =3D (kernel_ulong_t)&card_info_10mbit, > - .driver_data_ptr =3D &card_info_10mbit, > > which gets rid of a bunch of casts and so brings a little bit more type > safety. This patch is a preparation for that. > > I handled all of drivers/net/ in a single patch, please tell me if I > should split by subsystem. > > Best regards > Uwe > --- [...] > diff --git a/drivers/net/can/m_can/m_can_pci.c b/drivers/net/can/m_can/m_= can_pci.c > index eb31ed1f9644..cb9335c1d3ea 100644 > --- a/drivers/net/can/m_can/m_can_pci.c > +++ b/drivers/net/can/m_can/m_can_pci.c > @@ -183,9 +183,9 @@ static SIMPLE_DEV_PM_OPS(m_can_pci_pm_ops, > m_can_pci_suspend, m_can_pci_resume); > =20 > static const struct pci_device_id m_can_pci_id_table[] =3D { > - { PCI_VDEVICE(INTEL, 0x4bc1), M_CAN_CLOCK_FREQ_EHL, }, > - { PCI_VDEVICE(INTEL, 0x4bc2), M_CAN_CLOCK_FREQ_EHL, }, > - { } /* Terminating Entry */ > + { PCI_VDEVICE(INTEL, 0x4bc1), .driver_data =3D M_CAN_CLOCK_FREQ_EHL, }, > + { PCI_VDEVICE(INTEL, 0x4bc2), .driver_data =3D M_CAN_CLOCK_FREQ_EHL, }, > + { } /* terminating entry */ M_CAN_CLOCK_FREQ_EHL is basically hardcoded for all PCI devices since 2020. I don't think we need this driver data at all and can just drop it and use M_CAN_CLOCK_FREQ_EHL directly in the code for the frequency. Once a real new PCI device gets added we can see if and what driver_data is needed. Best Markus --49f7733329a22fff4b83a1680bdebfd7a9830dc80234132c7fb08fa112fd Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iKMEABYKAEsWIQSJYVVm/x+5xmOiprOFwVZpkBVKUwUCafMY8hsUgAAAAAAEAA5t YW51MiwyLjUrMS4xMiwyLDIRHG1zcEBiYXlsaWJyZS5jb20ACgkQhcFWaZAVSlPG LAD/fzJVNBHtKblmZr7CitXNgE0iUthbQCQShJJb37V4mMgA/2HCptgFXjEqdTdF h7pcmno1RbnSKnZ/TDh+JQ7CnAwN =RRmw -----END PGP SIGNATURE----- --49f7733329a22fff4b83a1680bdebfd7a9830dc80234132c7fb08fa112fd--