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 D776830DEA2 for ; Fri, 8 May 2026 10:49:44 +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=1778237387; cv=none; b=SOoiwe9F1ZNHigoYzoJZY+gguhbjy4Jw4jwGnGDQYYC0MJM47WFo+jynhsLUPlzaDhYY2Rf5lGRHX8ARS69gIdAHG9F33g6+BDD0Ig07uIfvk1PuKk4I51XJIGcFrNTE0YREtlcxTT+jeKEQuPWdp02QIpeAYNfZGUXARLchbCQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778237387; c=relaxed/simple; bh=TdPoruKtI0KpwKqsx2SHk/Z2cYfI/F3EmBkmYLRMvZw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=HEJ6nV747/rEO7kpPZGoHcxX89l/JSeqLB3oPQehtEyo3CKa9JHwgZ3LFsdR51E0DnOOaK8qnsTBMVm0dUC/gQGxO0r1jb/Q+DRTE5qnKerHvjBppDHoGMSluKuf5r01two6IGi1S3UNJkGJvgvPuE0CG1nkWAlnZs0PUoB2TvE= 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=K/Y7o7oP; arc=none smtp.client-ip=209.85.128.52 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="K/Y7o7oP" Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-488a9033b2cso17654095e9.2 for ; Fri, 08 May 2026 03:49:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20251104.gappssmtp.com; s=20251104; t=1778237383; x=1778842183; 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=rWU1mBk0M8y7smlttZWWUBzsq/nUTjltdlZQbqASAMc=; b=K/Y7o7oPWRUGSWV5qrBk2yXII5N6uVPsBC5bvu5PfOeJJOyndZgNmSQnPA0Opqpvjj 1/ZKyp1Mo4RXJsx/iXsO3SeeGFeo1E4wdJgCYrRYo/f2iQ3MziCTKCz72NmUDOAgrM// 1SuxdBmKS0+WaHFip1Jy6qLldced6DouYQycBkWoSBheHf8YZG62tvOvdp+CjO/6pUnn udEfgqWk9IY9qJQMvQXzVqAmvYhNYKoyASMUFW/fS3QWgn0IztMGTdtz9C7WGTCYVOF8 sGuaCr54+7zv+CtOjIUQv2DJ1vh6WunHrF78TKJstugbzaTNWnWyJLgzJOXj1Wa+1wSa Bh9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778237383; x=1778842183; 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=rWU1mBk0M8y7smlttZWWUBzsq/nUTjltdlZQbqASAMc=; b=n1YXlLTVyRiS+Z+0ANKAtNAy/K64waf8JpMS9dLRXseLgN4njD3oUbid4RIVSurlUf GuKVdvOAxtKYEGoBMX5YY50CDrMMmrxFXzg1OHWw6BA5S6EO5sVyS1m0Urxqqzx44Gys iMkWrBflpUqezQzB+wegLL8BkU8xC4tzhWF2xFQP4gH16vnCvUehWg/9b+oI9O91DW3N dXWoFURFC7JRT1RUSZGnzYQTDCBFDtp1vJB4x1EUWR1IIw/1bJbDdi9w75lTUfqSz9mI 6+jEsEuU98cv7fIrQuzQgjKkJxYAW9scVqrXRUJP3pjFu3/wSiFJhFdashGBjGj6l+/7 zrjA== X-Forwarded-Encrypted: i=1; AFNElJ/cl4xmmlG7lIu21gwxqkt0bUrqdeTrDTO1uM/b/dpwB0WrxfACcX4MtHo32OPAFGwBuE0Ijrno9qD2YaM=@vger.kernel.org X-Gm-Message-State: AOJu0YxoXq/wwO0m0B0XTUK6K2YywxK5ujKhnvVnjVLUZy+BcEN0TnC1 kF5fwqDVctJESfLMtitV+bdJkh68QLxVaWWMNfq0kQd1V+gIQzdECdXppOfmUuURUOM= X-Gm-Gg: AeBDietOiWAsUDdxYSlLfZU7q1i1Ko6Q5qjdd8yc0ESLrvojTY+BbWJwdfrNef/GQUa h2zBvu4bbjcJpKMdK7+HQ5NhVKXYhe2TGHi+kkzEAA3Xu/GpONTS+4X7//cE2ch4ZwNRMo1dRVq u2QxcW+8OWsVKf68dxbol9z5GKbKQys0Rk4FKBXG9VP9NY+nrgL3QBQhXd8aKvS894pJ+D1sNIF +kXSm1gGn0G/G53a2mZ/Jbb+A+qY5agE0q3av+LZ6EiSJhRCeoX653Z+9e4sXMjaFmnec5r+vNq cVI9ohaMkawDrVqrMUd7TMDSW+HtAinZLfxMawDJaqJkJUHhqeB5sySaDeDV9b0bCo3nJkDvJtg aqS4f0yF+AeYu4d4LuusnPWxo+XoFX9gX93qUEPTefifWDtZZ9NTqeBiLYkg1QM2wR/RbtM8VWk Fs6mVNlUlI2mZwkfGUT/f46P9UIZZPYvQr1dKsp+ujdXQt+tsSar6OP18cd2TlQw8Q+Fq1awCzj MXqPTQmyTQPgKcxw5gDto9nMtK3QEPogaCf X-Received: by 2002:a05:600c:1d18:b0:489:149a:f9e7 with SMTP id 5b1f17b1804b1-48e51f483d8mr181280335e9.27.1778237383219; Fri, 08 May 2026 03:49:43 -0700 (PDT) Received: from localhost (p200300f65f114e0881d5ec0867b49c0a.dip0.t-ipconnect.de. [2003:f6:5f11:4e08:81d5:ec08:67b4:9c0a]) by smtp.gmail.com with UTF8SMTPSA id 5b1f17b1804b1-48e65a09f2asm21506705e9.5.2026.05.08.03.49.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 May 2026 03:49:42 -0700 (PDT) Date: Fri, 8 May 2026 12:49:41 +0200 From: Uwe =?utf-8?Q?Kleine-K=C3=B6nig_=28The_Capable_Hub=29?= To: Andy Shevchenko Cc: Andy Shevchenko , Andy Shevchenko , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , linux-kernel@vger.kernel.org, Markus Schneider-Pargmann Subject: Re: [PATCH] x86/platform/intel-mid: Use named initializer for pci_device_id array Message-ID: References: <20260507154043.3113348-2-u.kleine-koenig@baylibre.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="lulz64zdbxewlllb" Content-Disposition: inline In-Reply-To: --lulz64zdbxewlllb Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [PATCH] x86/platform/intel-mid: Use named initializer for pci_device_id array MIME-Version: 1.0 Hello Andy, On Fri, May 08, 2026 at 10:15:51AM +0300, Andy Shevchenko wrote: > On Fri, May 08, 2026 at 08:25:45AM +0200, Uwe Kleine-K=C3=B6nig (The Capa= ble Hub) wrote: > > On Thu, May 07, 2026 at 08:24:18PM +0300, Andy Shevchenko wrote: > > > On Thu, May 7, 2026 at 6:40=E2=80=AFPM Uwe Kleine-K=C3=B6nig (The Cap= able Hub) > > > wrote: > > > > static const struct pci_device_id mid_pwr_pci_ids[] =3D { > > > > - { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_PENWELL), (kernel_ulong_= t)&pnw_info }, > > > > - { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_TANGIER), (kernel_ulong_= t)&tng_info }, > > > > + { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_PENWELL), .driver_data = =3D (kernel_ulong_t)&pnw_info }, > > > > + { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_TANGIER), .driver_data = =3D (kernel_ulong_t)&tng_info }, > > > > {} > > > > }; > > >=20 > > > Just use PCI_DEVICE_DATA() here and do whatever you want in the future > > > there, once for all. > >=20 > > I see quite some benefit in having some things explicit in a driver and > > not hide them behind a macro using _Generic magic. Yes being explicit is > > more verbose and here requires to touch the driver twice. But in my > > subjective view it's better to be able to look at the array in the > > driver and be able to understand instantly what happens without having > > to recurse into macro definitions to understand that. IMHO PCI_VDEVICE > > is already at least borderline in that regard because it composes > > identifier names (with the result that `INTEL` is used to build > > `PCI_VENDOR_ID_INTEL` which takes away the possibility to jump to its > > definition using the usual code editor functions) and it contains two > > zeros initializing .class and .class_mask which also isn't obvious for > > the casual reader. >=20 > > Yes PCI_DEVICE_DATA is more compact and for someone who touches PCI code > > daily it's also readable and if your working for Intel you maybe even > > know the value of PCI_VENDOR_ID_INTEL by heart and so never are in the > > situation to want to easily jump to its definition. >=20 > The same argument may be applied to many macros that use concatenation > (##) in them, I fully agree! > this is not an argument at all. I don't understand how you deduce this then however. Not every macro using ## is bad, but every such macro comes at a cost that you have to consider when justifying the usefulness of the macro. Of course there is some subjective weighing involved. In my subjective weighing using both ## and assignments to .class and .class_mask makes PCI_VDEVICE *at least* questionable. (When all initializers are using names, the 2nd can be fixed.) PCI_DEVICE_DATA using ## and the outlook of it using a _Generic construct is IMHO even worse and so I hesitate going that route. > > But for people who don't know the subsystem and its magic such macros > > raise the bar to understand what happens---and that's bad for long term > > maintainabilty and attacting new developers. > >=20 > > Additionally I also see benefit in the initializer explicitly using > > .driver_data (or .driver_data_ptr) to match that against the probe > > function that hopefully uses the same member. > >=20 > > So I hear you and understand the advantages you point out, but in my > > assessment the disadvantages of PCI_DEVICE_DATA still prevail here. >=20 > The whole point is to hide whatever you do behind a single (or a few) > macro and don't disrupt kernel with thousands of unneeded churn patches. >=20 > I do not see any benefit of doing several steps here. Convert the driver > to use PCI_DEVICE_DATA() once and no need to touch this driver anymore. If you ignore the cost of hiding stuff, there is indeed no benefit. It seems we have to agree to not agree here. Best regards Uwe --lulz64zdbxewlllb Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEP4GsaTp6HlmJrf7Tj4D7WH0S/k4FAmn9v8MACgkQj4D7WH0S /k7eBQf/Wg1HMXX2x0Y67srN0ACmAGNZN0WWXwfNquD1aTy+OREKy0PEFGhznUnk m/W5/W/4lu6AsQ56WwGIIMVzVgKjkHFwnFbJsoWV6XD8mVJY9hdFC1e2UW4GIEPG YCrH2XaiILWsM4qHeT6e6QFDiwpAG+vPH6vN4fqZk2XI+6MJ9tvyewV3Z/kdcitX SLfzH/vfiPWWh9xM7Y7cJS7ki8JTHiaKlcw/zIO+u0h1nsCLzbCs720xKZIenCMC 63GQ/MDARNXoOP0wvjOJ+9laTX3AwRdoIUEXwX2N9MEbFpIL6FXnD28Hjsxcl3VX 80PVNqIudnioXL4boIZR6yNHwCWagA== =6mfh -----END PGP SIGNATURE----- --lulz64zdbxewlllb--