From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) (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 E78B332F764 for ; Fri, 8 May 2026 06:25:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778221560; cv=none; b=VYCe/2i4TRM4BtQugdbWiZLESdrCapTJFxNyqrZ3hYMQyDF1aStuxozgjeMvkuytcnbq4hzzgKeAauB9qjc/aZ0Rnqk4R5b7yZ7HaxCUkW9xTVFSueP5D5JFMQuKiRZP2SEF3nnQ5QNE1AHbgo/qw4g7d6pVW2LWtyIy8KIO7Ec= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778221560; c=relaxed/simple; bh=wH6Fosgrr4zIb4wk3eUpoeljI/D1S/8AGRCR9KKwhCs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=FwlXSVeeDi0ix99YqXJBReTyHGHNjk4aTfrIXufBXdEblfPVr1j4IIVsfFj5l9rwtFmK+NuMOsCexqZkHMKznHPBmtHcoVqadg2GHkS/O6GbT73SOJ93F68QU+XeVgvZC5JPAGccp+I6/WNuZfQmlqhvaREWyWcjWPyp3ZIszXU= 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=BQoAzHpq; arc=none smtp.client-ip=209.85.128.51 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="BQoAzHpq" Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-488a88aeec9so19214995e9.2 for ; Thu, 07 May 2026 23:25:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20251104.gappssmtp.com; s=20251104; t=1778221549; x=1778826349; 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=wjdP/rCQGnbgqfVsoIiLbg+emcj6QiUEAMuee7YUQHk=; b=BQoAzHpqgZgkZKSJoXtbXJaXX7GphpZ+xqZiyB53O+zloeQZAxCPk4NSZhCGTLUwfH XyA4DfxAyL6lP0CEO2BBF4N6H7WFMBj5X5xYSETufth84lOz2NTqOqmwhkpY0VxYnVt9 GOXI/SZDVgtQRnD92N08TfhWnxzkuKntpnx8rk69rNLEbx4oOTRFp4ZJ46mYvftRarQt j1aL1+f4kKYFJWrPP86x9cvghOClT1Z33kc4ADr3oqxa5VCLJq5nHdFOT2sOU5x73Dhz Ijdxxtqpy3lfcjH4yDZvTN3aXAU7dyeM0iRQd9kxDNFBscuzz6Trf8eV9Vfbi8SDBVLl RT/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778221549; x=1778826349; 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=wjdP/rCQGnbgqfVsoIiLbg+emcj6QiUEAMuee7YUQHk=; b=E2o5PysxxbvqA1fXmACua1RC2Q7NQjxYxnY/fO094w3Gz3CwMl98es+bDVCq7xpeKQ ryzCtwePqvctaKbO3E6BMNIRG/usJxLgJvvLG8AYWtH0CGiwUT0xGDVBvGty41SGeB0p XGp72Xs0fK7BKNBDUw/GMz/nC9fKmddY1QiQMaS3tgfqkjsabuwk/06oKEspLhIUR9xx xbP1NDJVH6pnsvv5jLgJF7ehiKRiNDRW9dp4zyumIz4iqLhnw3nvrZOxULVPrDXM6RRj SIDLuIywIZHltLYFWtPDGmMHcnFNi+HQeOOYFjwMmr/56V+RlHM9m2M73kuWjbrRnI4w 9iwA== X-Forwarded-Encrypted: i=1; AFNElJ8/KfFMH+yUj2QoIIKricVywSmo+92sa32wsEQhJO7lW2sUXaDP9h9memwFtZ5syVr6Xm/sGUmG+wpOmUQ=@vger.kernel.org X-Gm-Message-State: AOJu0YygGfaO4l57/ZbX47gktOwYe8ATQk+HvVC9qgsWPPi+zLVtS2y4 X/FbkdiIJeWzW8mbyUTz9SinofKZXNe8kG7/cdRhsBCrSdknpD4WBX9R3wk1hOQXcsM= X-Gm-Gg: AeBDiev2EysFuyl55qQWmtCQeCSpwsa9E9ihyUXWzAUEY9RHqhCBnYmqUWYufrCQllL fXtr0nXURc9tswDYdZj25WDNhh2OXG8T6y8OcOD84d3m2KzBjiM9pkGRwUZ1bEdb/PGpLSvc0BB YQ3T1xJyEnizYM1LHSYsr1J79lcjm47uzRu5szh85870DbmxXruysi+6R7nbaJbXQLY/TtBY7z2 DgNtABTERXPSH7FUoE/DHNxPki96C9vt5+tvKVxXgDLyUCDyrIy8I5Tk9MInFXOQrk92aZsPivP O5MEhICayctwYNHCVoo9t9H7TwtylwZesmy8zKHjcnAaBiFK1YXiD+ww9+0L2m3j2ZEz3cK5zwq ZXmBzk8q8joKgCKxH5Pz1u29Ff0zLc1gO7YwMXmqLoEhnirttmNt5g0g5Xco9FX/CLLxbjXFLEU VPXPGFtoAmkJfB/ToUOsz/zivmQPXyla6LrhawKZEiL9hoMCMUGaTUzGuFI1QtpLCoYbkDxYkTG BqyX78bM+OSeaw= X-Received: by 2002:a05:600c:6d0:b0:487:21c7:2885 with SMTP id 5b1f17b1804b1-48e51e09730mr105907495e9.5.1778221548584; Thu, 07 May 2026 23:25:48 -0700 (PDT) Received: from localhost (p200300f65f114e082207a70be6c99fa4.dip0.t-ipconnect.de. [2003:f6:5f11:4e08:2207:a70b:e6c9:9fa4]) by smtp.gmail.com with UTF8SMTPSA id 5b1f17b1804b1-48e68f5d48fsm11631945e9.14.2026.05.07.23.25.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 May 2026 23:25:47 -0700 (PDT) Date: Fri, 8 May 2026 08:25:45 +0200 From: Uwe =?utf-8?Q?Kleine-K=C3=B6nig_=28The_Capable_Hub=29?= To: Andy Shevchenko Cc: 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="d4e6nvvqudan2aga" Content-Disposition: inline In-Reply-To: --d4e6nvvqudan2aga 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 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 Capable= Hub) > wrote: > > > > While being more verbose using a named initializer yields easier to > > understand code and doesn't rely on the two hidden zeros in the > > PCI_VDEVICE macro. > > > > This doesn't introduce any changes to the compiled result of the array, > > which was confirmed with an ARCH=3Dx86 build. >=20 > Instead you can modify PCI_DEVICE_DATA() to accept different types and > act accordingly, no need for this churn in the drivers. >=20 > > /* This table should be in sync with the one in drivers/pci/pc= i-mid.c */ > > static const struct pci_device_id mid_pwr_pci_ids[] =3D { > > - { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_PENWELL), .driver_da= ta =3D (kernel_ulong_t)&pnw_info }, > > - { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_TANGIER), .driver_da= ta =3D (kernel_ulong_t)&tng_info }, > > + { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_PENWELL), .driver_da= ta_ptr =3D &pnw_info }, > > + { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_TANGIER), .driver_da= ta_ptr =3D &tng_info }, > > {} > > }; >=20 > ... >=20 > > static const struct pci_device_id mid_pwr_pci_ids[] =3D { > > - { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_PENWELL), (kernel_ulong_t)&p= nw_info }, > > - { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_TANGIER), (kernel_ulong_t)&t= ng_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. 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. 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. 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. Additionally I also see benefit in the initializer explicitly using =2Edriver_data (or .driver_data_ptr) to match that against the probe function that hopefully uses the same member. So I hear you and understand the advantages you point out, but in my assessment the disadvantages of PCI_DEVICE_DATA still prevail here. Best regards Uwe --d4e6nvvqudan2aga Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEP4GsaTp6HlmJrf7Tj4D7WH0S/k4FAmn9geUACgkQj4D7WH0S /k6UewgAttWGD+43VCex9SAaDNbs8qVm9Depv8+EgcPF0502vVxYmB27UBWWA500 yI45mKfd248nEI0iXsWtp0z/krRi4Fa/GHjY0tFYCxpABdjj6tNTCsmW59nzyBOZ OHKZH3LjilzKBMspzJ2f3UqRiE9duNvArSQYgWuxevTTt9cU4SauMQjKGTILg6es 9TdhbeuuqxbJ4uY6GRw13L6tH9Oj+6Oy76DD8+aywSH9FPU0FCh8c+FGKwSNrmnO baq9uzePQl2DjMxhlTr+cWeqZ5UhF2c45K8z5FVv+sMaMUBEgvxYvEm8L4Xc8GZE uW0Uv4Bfi4tXLYoyu/GvC3D+c3+V8A== =Wmfc -----END PGP SIGNATURE----- --d4e6nvvqudan2aga--