From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f48.google.com (mail-wr1-f48.google.com [209.85.221.48]) (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 148F33B7771 for ; Fri, 17 Jul 2026 09:44:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784281474; cv=none; b=P5DZPSW+C/ZXoPy27RftUqIT4aGoi71XCGCQd0Yvx9kpC4l26qDu2J4uQCEJxw/kJD8qP3BKPBp2jyeyPUM1Wg878ulyikiuYu3lKxgsnpk++aJwI7kDIWWNOGgdjlgsZ1dt1QEOhyMyljUOJxZ1fj/WA5d/GtkSZxEtKhqietw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784281474; c=relaxed/simple; bh=E+1Kv7z+qGmL9fbk0lDffWcknN7y4nXk/uMQtMMlDk0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=NSEUNqBqFw2xC/XyHpj+df7KSQD38xxNeGygTWDZEdQnFuh0STrGMrsrM0+YtIb+l1BKj3rxfDgloQqOZy8j6m1+i9ljBYWcphDPJUddHRzvBsIZby+uXQGIRAnHbzhR7ohLpt9BidDy5eMl0Cv6t7VuU2K1N0tfwzqKLKr26O8= 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 header.i=@baylibre.com header.b=ozyqjci/; arc=none smtp.client-ip=209.85.221.48 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 header.i=@baylibre.com header.b="ozyqjci/" Received: by mail-wr1-f48.google.com with SMTP id ffacd0b85a97d-4720f3bf164so698159f8f.1 for ; Fri, 17 Jul 2026 02:44:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre.com; s=google; t=1784281469; x=1784886269; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=hgcHU+bdsKQArYIt7ofIjFHQoOU+7sLLyFEnTrxcgnU=; b=ozyqjci/jSCHJzMnWl5Cxn0xkmSBdYj+O5sIn1SEAlyYHie9zVmAnWhKCH7Rszhwta h5DOEwXnv/Xvmhid0pSJLHlov9yRtJyYANtpo4bi7u0xz2CiJ2lCcAcsfEm66SQfeVwn YZT/5/Rc78/yl1918kYUASBXsTmCZlZ477AW87xIhLB8novzTudzBDsPOZKK0SNRlsRW YDRDCDwN9XxmUejAoFEb2ebZStoW7Ad8iYCJqxg5ypDenDxZ8mEJ1tDF5uDm7Kdfu6wP DRQ6SAth+Se4eEgtap4TN1GFUZhZSTBo87dcDN2YiHqx8gK2a1wkaxVLx9MNDQ7J1Qtf 73eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784281469; x=1784886269; h=in-reply-to:content-disposition:content-type: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 :content-type; bh=hgcHU+bdsKQArYIt7ofIjFHQoOU+7sLLyFEnTrxcgnU=; b=eqmiYiDlbe1yyAMSRG6aAx2H2gYFV5gzD5OWA1JE1DYgxwq4km0nq4CXAx4ejbNvVY MhgGzw89NJ0eZuj/9TwuOhPojnZGA6iT1LmywadA+t/C4BLBWjKfCHW3jXSztcjCfDIa 63bFa6NM/G+5zXSQfvCOjInXUJhVMuEyq3uwTSBAZ0hQ7bC3Uqey1+X9f82xyEBMygs1 NW8/CC6pLEmeOjDVcdCpmNeSRmCTBPv+ZG4rEa0iL2W4rU7p85ydX7/PFCKfew6V/fxW dx5Hbj1lqS8Oo6wrlzN7/rZzuoibK8BD6oOPjYlkbiTuGVWvj/StbAbZKhXezP0BFJIj KTGg== X-Forwarded-Encrypted: i=1; AHgh+RqGfWGSCWaEVvVhh1HGA0gkqNA/4LMBqoCou5WptxJTyu60iZ0Q+fBJeR34+b2dLskvlx/JA3TH0EhaT9k=@vger.kernel.org X-Gm-Message-State: AOJu0YzZCGzln5+C0xEuBSgHVat/OfGGYXCNM1T2YrD2N6FEPjfUWvgW PyMGA2rFDSZQUaXZ/p9np9pRP1PM9kDGbl9iJpUvlNs/OFg/8AgthM9m8enZRWde6WA= X-Gm-Gg: AfdE7cm5dfEjn1JyOIg2YzItP+hA1D3Y41Nh/q1+Uh7cX4Q55oYlUk/qJnCI4El6IBX iXBy4LCYUJ5jopenwYOOOQufawM7ZopcwZ2ssVFHeC/wDsmL5Eew4ROiH0IJ/vUjo1T0kX9NL/j 3vE0hawJbY9uvNKjLZYowHIhWuIk9h4IQqvmKhi5DVZ+dOx//1twVf7RoQYtwP/cnOl6+pwgNDN vjC1c5CvNdC36h3D/uW7IicEXe4y2h8Sg9xv1js2NYAx2zPipm8/g7c2/xEofgBHYjB4gLdE8m4 jZeRnLVVrCKDUSXCFB9YUk3w1cDbKcPH+BPDYNYvdfBphhfZi2Ram09bSs5JliS9Hp3zk+HGgrX lyWYc+vSDy0iOXIQeYD3EyKiYkrdB7mdv/mliqzn6P4+tMJii27PO3j0JBvwnviPVF+wof7+xG6 56A5Zn4z9GQyHQ6W8P1VHBBYHJbspue10BkfXzRpDIGoCoVllCkTaJFOPCU3nQJYEvqw== X-Received: by 2002:a05:6000:2c11:b0:46f:8561:fe60 with SMTP id ffacd0b85a97d-47f5a548693mr8364417f8f.17.1784281468951; Fri, 17 Jul 2026 02:44:28 -0700 (PDT) Received: from localhost (p200300f65f47db047d2d8b161e35ab77.dip0.t-ipconnect.de. [2003:f6:5f47:db04:7d2d:8b16:1e35:ab77]) by smtp.gmail.com with UTF8SMTPSA id ffacd0b85a97d-47f63ed1911sm2352228f8f.22.2026.07.17.02.44.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Jul 2026 02:44:28 -0700 (PDT) Date: Fri, 17 Jul 2026 11:44:26 +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="kwl2eolz2nu3tcli" Content-Disposition: inline In-Reply-To: --kwl2eolz2nu3tcli Content-Type: text/plain; protected-headers=v1; charset=iso-8859-1 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 Sat, May 09, 2026 at 03:42:44PM +0200, Uwe Kleine-K=F6nig (The Capable H= ub) wrote: > > My point is to put all burden in one place > > id est PCI_DEVICE_DATA() macro, your point is to spread a churn all over > > the kernel which I disagree with. >=20 > In my approach the first step (U1) is: >=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 > (i.e. the patch under discussion) and the second (U2) is >=20 > static int mid_pwr_probe(struct pci_dev *pdev, const struct pci_device_= id *id) > { > - struct mid_pwr_device_info *info =3D (void *)id->driver_data; > + const struct mid_pwr_device_info *info =3D id->driver_data_ptr; > struct device *dev =3D &pdev->dev; > struct mid_pwr *pwr; > int ret; > ... > static const struct pci_device_id mid_pwr_pci_ids[] =3D { > - { 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 }, > + { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_PENWELL), .driver_data_ptr = =3D &pnw_info }, > + { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_TANGIER), .driver_data_ptr = =3D &tng_info }, > {} > }; >=20 > . With your suggested approach we have instead of U1 the following (A1): >=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_DEVICE_DATA(INTEL, PENWELL), &pnw_info) }, > + { PCI_DEVICE_DATA(INTEL, TANGIER), &tng_info) }, > {} > }; >=20 > and to benefit later from the union there is still the first hunk of U2 > needed (A2): >=20 > static int mid_pwr_probe(struct pci_dev *pdev, const struct pci_device_= id *id) > { > - struct mid_pwr_device_info *info =3D (void *)id->driver_data; > + const struct mid_pwr_device_info *info =3D id->driver_data_ptr; > struct device *dev =3D &pdev->dev; > struct mid_pwr *pwr; > int ret; >=20 > . I was under the impression you assumed there is no need for A2, but > that's wrong. Additionally U2 is easier to review and judge that is > correct than A2 because it uses an indirection less, while A2 depends on > .driver_data and .driver_data_ptr holding the same data. With my > approach there is always a directly visible 1:1 correspondance between > the array and the probe function. >=20 > Also if A2 at a later point is backported to stable it applies just fine > without A1 and the _Generic extention of PCI_DEVICE_DATA() and the added > union. With my approach it's more obvious that you also need U1 before > you can apply U2. (Yes, it still doesn't fail to apply without the added > union to pci_device_id, but that's three potential papercuts with your > approach vs. one with mine.) >=20 > So I don't buy your argument that A1 + A2 is less churn than U1 + U2. In > my book U1 + U2 is even less. You stopped replying to this discussion after my argumentation. Does that mean I managed to convince you? In that case, please consider applying the patch. Thanks Uwe --kwl2eolz2nu3tcli Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEP4GsaTp6HlmJrf7Tj4D7WH0S/k4FAmpZ+XgACgkQj4D7WH0S /k6x1Qf9F0Z3GosUOoYPJoT0/OzyciHWQjo3FLhFEeUzlCFXbQx6+QDFHk3+bEN/ 8gAOXhI8XecW03H8EcEvhO5Tee7LH+IEkn7S0kHeUSbD0MyTH2SaQdD3zyAg/3V2 SX+OBt3/g3Rgc9jpkj0EiLwrSpDPJ1ph/orRKiGX+RzDdYP54lk2+LuYC8ggPuHt ouxElsVBZHqPxUpsUvMqjzMzDRv6/4tng8F/VDdNaCSroEKB6FlcRcy04VoQMOrK uEb9GWz13hpjL5I/8LKrzKgBTQRZp7b4NyOhVz7vujqZj9S01OP41xBjpNKGnjT6 ZJxoJoLWvB3Z0tZ+ATRwBBthVynHpA== =w/Et -----END PGP SIGNATURE----- --kwl2eolz2nu3tcli--