From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) (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 A32713FD15E for ; Thu, 30 Apr 2026 08:55:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777539327; cv=none; b=DQbBCyC5fsA0Xj7l3l3zb+88EfMiRyfbCjuSpAzyJ9LP39fZ39ckNfD2MJ5NxT0xQjt7ESg+PjkY50xTHuqBB7shlwRA70IFgSuEsmonQFJILOBw1YKkOVxk9apczhAkyuN19PyjPGPIQzCQive7hNXprJ9GwsHXMZljTvQUlxY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777539327; 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=f/C0L0WMwlL3ho7YC6lHLcjBdhU20blx9p92Jns2okucARxl8USdLBoO+RJ4NlSKEINl8VNVHzvzhse1apN3+/maY/DTeKP7c9QnB56atKHRKSfgRimo+/xuTZYYQ51A1tlVkEjL+AVbAfGU5RHwywHV2/NGotHGhJPhrhA4Ke4= 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.42 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-f42.google.com with SMTP id ffacd0b85a97d-4486b5fcf3cso598709f8f.2 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=JmUlpRh4J+Dv/r2Ky23ZhvZM6wH3JJOZgmpkxcXuB3CfIc66iQ7GFECOq5Qslhcx1H J0HMGQl0E+KVw35Ct3hDjVDl0HupTw3K8rQ/XbiXHubwj3K6xSPq5Q3qhPbhVeEoRjbb B8ao5LuvnXUJRT4VFHhgqGatIZxEq8YJBq67VPP9hFfsNtH2qYSIkPf+1UbCPDOfnv09 mkwrotVOMIDIzG0k+MYIst8BkeR7uPSdFnC6fApq8nBfvgxOWOn6/+GBqO89KdccNPXx XgK2lsFX23cdSfEQ0kad5ztGsWztVq1l0KtHS/2bCVxSknWAlXx1WrPd8bfWy8xSzfP3 Z7pQ== X-Forwarded-Encrypted: i=1; AFNElJ8IUdYKzTfDOTsV5QcefJx5MU3Wn9ujt6unx+N08JELNFp8pe3ay6KtXP4JPKOtvYzqP6FNNOk=@vger.kernel.org X-Gm-Message-State: AOJu0Yz/yaQX04P+m+3F0QsuFfAKxDLI4KHvPY3KMI1KmXa8xSHgouyL 3N3OvIqkXtVNt4sT4GAs5OdSTeW74SPxL1SJ+U/lzYZxUt5a8x34W5hyQP2FJ02W02k= X-Gm-Gg: AeBDietCANYXu/tEHUAH67CCL7GILUJrAoFLSqtaGDjjL9nXv973vbTVu+uXHspCliI 6ACpnDgj67FdIxHpcerQflzhdmVWAWCHDgajKU5VvpkosXzdBkHyu7m8QvztBytkC+0HzRasQxv 2araT/qWLjer52AN5MY0xVWnaNJAFGFqinUvRxaqsEodlX4SSA3yFGivEcTynu8lWhJU8YJ777G 0zTH/3ubtKUzKE0S+YgdS1tSc/LG4RPGKsnGAP9YWMd84IQHiR0w6/BsF3tXpKK8PCuNG/bwaKc vCt41c8RHGUUZNGMxUlMp6VQj3mMezWp3/Utjtrt/FTo5Rp6yieUdXrPKNMSqGyeD3OVF3cFWEG IzJCFNLImePZ1zitCggbBtW66jHX36riAU+vQQkwOLbx1G/XVAAVm9DELR5XRnjQI5+g+HnNhO3 Bd1BN+FCD+LtzrxZUhlodPIMqLNHk= 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: netdev@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--