From nobody Sun May 24 19:34:46 2026 Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) (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 6DBB337A4BC for ; Fri, 22 May 2026 14:59:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.43 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779461994; cv=none; b=eCpQ19DZqNr7t5MPiRblpo39nWPnfD7851Y7trFUpxPnoYM50tQWXeDaaP9EzV+8Xxpx7PS+D7Hs6A1gSJI5bkc+MToSszNeFJrym9hxkr8TqDN9acPnZeHlScoMh+mqH8X1wYRdkVfM8g+rIVm0s2p1LrahJnRiZQS4vj2n5ws= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779461994; c=relaxed/simple; bh=9zUTOYb+g+3EZt7oIye6rhzKcFrhONL8UItJ3EnXyfg=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type; b=k8ViqO0sAzqfp+vr6l42r8U7a4z6YTzjB/fnpU0LyuqFIIC/x5wYm2Z6s/ukY8rmxU+M40HylLv0gZqTbTwuy6ouuPYEhyX0ub1sfCRTbBjnqP3AlKoXBdo1N/QaYjUv80BulxagQgXC9q0Q/m/mwlH7eOuBQHq5tH8E14GZOvM= 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=ktLvvU+j; arc=none smtp.client-ip=209.85.128.43 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="ktLvvU+j" Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-4903cbfad68so12943645e9.0 for ; Fri, 22 May 2026 07:59:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre.com; s=google; t=1779461991; x=1780066791; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=DLi6X6odP8H/h8Y8Pr/vuDUyKcCjgbdHGCb8Tzve4fY=; b=ktLvvU+jo1IiuDEq4mJ/gsCiPJSgrSgHAKIT1ofBv42ZlPiXXYNoKg8CmGk4NC6z1H 1jmZSE3A8vkiK91jO2NhzlQmDTcaHHJOsoqkA4d8Z2UVzLu7fdwCvaFPyC6osoMFNQJy JR7smAZvOWSY3eU7nAokS7k284R2YORUVJZeut6DcbplvkH2qR6VgXWBvhSUnUMTdvt4 9NshFwv1o/BRUXgnafJBfO61oYtotDTBOVJEp1jIkFSwsm9F1B5Gh+vObhTW13Dp2QFk 7fYUvPpo9Z72pqnkK6HZOry5XD4R0i7RUrgj3y9/mfcwOVPRXSobQ7bcMFKkf84A0BWF VxXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779461991; x=1780066791; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=DLi6X6odP8H/h8Y8Pr/vuDUyKcCjgbdHGCb8Tzve4fY=; b=m1B7qNh2Sw1kaR73ug/tmLwO8gE9zAyW6fQtqwUg95TqCtSJnex+aFiNUvVmWEgX1O lCmBL2xHMWQLN2zVHi2WXYPRAyrf7UiNfrPk2nZMeakofUOm+FwoJ8xJS8E38stkgYUc xZy0UGnO/RugFFrkrLaV1lExk+yIAflmX44VwXpVOtmS8Qw6DdxVYEPBRPqSUHcfB4Yu aNU1YiZW50zzXeQbVuRx0swHxdzx7uMdXGSL8PRg3arWa5FrxSiiGNA9jAJHd/CMPEIp dnR1oNJ3UaHsOoTeSg8fk/t65DC736um+4B3cvwE6M23+ZuUa39/CHyjDNNcb++hATPS /GTQ== X-Forwarded-Encrypted: i=1; AFNElJ9geWeZn2+7MqRHv444wrqSRJ4JuvvM4mwm0StFjwk+l+9NZw5/dah+8SH1QcyKzP5I0gnQTXzv5drrLGQ=@vger.kernel.org X-Gm-Message-State: AOJu0YzJOnncdSzEYvwdRxl5L9eyf60IquAgtnn68RZ4ZFuDCmj+FqmZ RuoUQVPQPStN905dQZliiXNFZevXB9Q34mJM+k1ZPtyv1BfoB/JEeHX4iBkoLDwg8LQ= X-Gm-Gg: Acq92OGSvCHq6f7bsoSpLos69HhhAgKMB1TxoLvQhWvJ6gMzBaVB8XBGjznBdFNWqDb E71N27v1MfVJ3xcs5fUr8l3x3vKf32tDyKrHjeqbzKXftem66TjOjSdVA49jKWoau3wMr3dDp2V PRtS01vu4UAcWyywRncp2Y+gyv58ovfEZq3NzBiRzFc0522ZrBCdHxhbZqJnwFDchOxBnNYgbOT djtaDIgEh0U0Ldy1mtBta82BxQ53NWBkVtPgX1RAO1LM/cP9X+Wf5KTvxZnN4h1pWkPsNCkvuyP hZghX7n+nc7sJkYB3XQyqvoJzsluf+U7euvLndrZKURahfDqWYv03vkGPvUFFEyFqF0nGy/ER99 7BZzI9eduWNwtah6L0mhmxD+YCjFslP61+P78hwc2GgT+aTlqSZYhOjBlMBmAYDFcLNIgmhTbRP QGhM/paFqQXCz1ppH1wMBGhPvji+bQa9uwEdf5RR1ZDS3TVfHjGxMPxSrR4dAe8Z2SsEBoQMgAC en2eYitlIL9YjM= X-Received: by 2002:a7b:c053:0:b0:488:7d01:f67b with SMTP id 5b1f17b1804b1-49035f2e1a1mr79160285e9.6.1779461990892; Fri, 22 May 2026 07:59:50 -0700 (PDT) Received: from localhost (p200300f65f47db04fdedbb26b9ad100d.dip0.t-ipconnect.de. [2003:f6:5f47:db04:fded:bb26:b9ad:100d]) by smtp.gmail.com with UTF8SMTPSA id ffacd0b85a97d-45eb6d5cb9asm5241495f8f.27.2026.05.22.07.59.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 May 2026 07:59:50 -0700 (PDT) From: =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig=20=28The=20Capable=20Hub=29?= To: Tomasz Jeznach , Joerg Roedel , Will Deacon Cc: Robin Murphy , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , iommu@lists.linux.dev, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org Subject: [PATCH v1] iommu/riscv: Drop superflous zeros in pci_device_id array Date: Fri, 22 May 2026 16:59:43 +0200 Message-ID: <20260522145943.774344-2-u.kleine-koenig@baylibre.com> X-Mailer: git-send-email 2.47.3 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Developer-Signature: v=1; a=openpgp-sha256; l=3462; i=u.kleine-koenig@baylibre.com; h=from:subject; bh=9zUTOYb+g+3EZt7oIye6rhzKcFrhONL8UItJ3EnXyfg=; b=owEBbQGS/pANAwAKAY+A+1h9Ev5OAcsmYgBqEG9f52lyWQQzuWjlCjyQbzzJzLwj5lurSUYrB 8lZOKPaAFKJATMEAAEKAB0WIQQ/gaxpOnoeWYmt/tOPgPtYfRL+TgUCahBvXwAKCRCPgPtYfRL+ TvWLB/9ik2N5fGT6RT2UEJFI4kuhLU1DsBWTnMQHyJtT6Dy/pmmAAC6CIojtti5tyTJO8ywoAVD YZ+CAUqwr8oLBppm7sXXNBgKOLDVIbJna98X9bmu7Xy/WuADWjhn8gXdGne+9KHA4rPK2EJm/YX JYmLeOMqyfLToW1LO4V1j1D8HkzhX0+36IEMU93LlqSjjvw3JFv08Uvuco7ySvFEirKujasQrbt D7iLYpurq7JBh53BCeTqSDbhrL5jk4Voax26uGO7Hb2nHnspZRQYQhQL8n/OWarN+Tri8hNhiWC yb1vF1KMsKnCWpem7hQ81E38SGitkv6JLnfYQsvbkrHFDe56 X-Developer-Key: i=u.kleine-koenig@baylibre.com; a=openpgp; fpr=0D2511F322BFAB1C1580266BE2DCDD9132669BD6 Content-Transfer-Encoding: quoted-printable The .driver_data member of the struct pci_device_id array were initialized by a list expressions to zero without making use of that value. In this case it's better to not specify a value at all and let the compiler fill in the zeros. Same for the list terminator that can better be completely empty. Signed-off-by: Uwe Kleine-K=C3=B6nig (The Capable Hub) --- Hello, while being a cleanup that can stand on its own this is also a preparation for making driver_data an anonymous union that requires that .driver_data is initialized by name and not by list order. The union allows to make better use of the C type system and drops the need for casting. The change to a driver will look as follows: diff --git a/arch/x86/platform/intel-mid/pwr.c b/arch/x86/platform/intel-m= id/pwr.c index 1739971478ff..c0d9da81d512 100644 --- a/arch/x86/platform/intel-mid/pwr.c +++ b/arch/x86/platform/intel-mid/pwr.c @@ -347,7 +347,7 @@ struct mid_pwr_device_info { =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; + struct mid_pwr_device_info *info =3D id->driver_data_ptr; struct device *dev =3D &pdev->dev; struct mid_pwr *pwr; int ret; @@ -471,8 +471,8 @@ static const struct mid_pwr_device_info tng_info =3D { =20 /* This table should be in sync with the one in drivers/pci/pci-mid.c */ static const struct pci_device_id mid_pwr_pci_ids[] =3D { - { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_PENWELL), .driver_data =3D (kernel_ul= ong_t)&pnw_info }, - { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_TANGIER), .driver_data =3D (kernel_ul= ong_t)&tng_info }, + { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_PENWELL), .driver_data_ptr =3D &pnw_i= nfo }, + { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_TANGIER), .driver_data_ptr =3D &tng_i= nfo }, {} }; =20 which is a nice improvement dropping three casts and that will make the compiler say: arch/x86/platform/intel-mid/pwr.c: In function =E2=80=98mid_pwr_probe=E2=80= =99: arch/x86/platform/intel-mid/pwr.c:350:44: error: initialization discards = =E2=80=98const=E2=80=99 qualifier from pointer target type [-Werror=3Ddisca= rded-qualifiers] 350 | struct mid_pwr_device_info *info =3D id->driver_data_ptr; | ^~ (so it promotes that driver data is supposed to be const). There is no iommu driver using pointers for driver data, so the example is from a different subsystem. Also this is the only pci driver in drivers/iommu, so no further patches for this part of my quest to that subsystem. Best regards Uwe drivers/iommu/riscv/iommu-pci.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/iommu/riscv/iommu-pci.c b/drivers/iommu/riscv/iommu-pc= i.c index d82d2b00904c..8abf52dfb4c9 100644 --- a/drivers/iommu/riscv/iommu-pci.c +++ b/drivers/iommu/riscv/iommu-pci.c @@ -109,9 +109,9 @@ static void riscv_iommu_pci_shutdown(struct pci_dev *pd= ev) } =20 static const struct pci_device_id riscv_iommu_pci_tbl[] =3D { - {PCI_VDEVICE(REDHAT, PCI_DEVICE_ID_REDHAT_RISCV_IOMMU), 0}, - {PCI_VDEVICE(RIVOS, PCI_DEVICE_ID_RIVOS_RISCV_IOMMU_GA), 0}, - {0,} + { PCI_VDEVICE(REDHAT, PCI_DEVICE_ID_REDHAT_RISCV_IOMMU) }, + { PCI_VDEVICE(RIVOS, PCI_DEVICE_ID_RIVOS_RISCV_IOMMU_GA) }, + { } }; =20 static struct pci_driver riscv_iommu_pci_driver =3D { base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731 --=20 2.47.3