From nobody Mon May 25 04:35:27 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 88AC32773F9 for ; Mon, 18 May 2026 17:05:51 +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=1779123953; cv=none; b=ibieGNiTLu78bQWrGUMJOCrM5PrcIL0FjSoL02FzrOQ5FfOMw9v3JTXzAvoRVY52zCHVBFWa8NJYwqkU/+/bUv2kr6Hsz+LwD1Sxp86gc/oSZ0wO+k0rzS55jNBoTxVMOtPq8kF7f4SZNtqmFBb4PHdNcxBWxnVXVX0vwnlhL7k= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779123953; c=relaxed/simple; bh=v5OIJNsk67U76wJjPC7hqs+G51U6k0pEBy58uPTbPjc=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type; b=QZZeuhWRrM0oX2CavbX3tKrczjOA14zZrUo5njZ0bNyukkDNw8w76c3udfiQmhU/eZN/B0Yo3fCEsgVf4ZVE0CTCXkGBUJDXqosNC5EZ0b/hhK72tRlcmdOkqJ+pRqWw9E6fJoFMZApiSE0yrSUoZWOMuPU8o5VVYtgJJRu5cj8= 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=I5vgKXhe; 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="I5vgKXhe" Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-488b150559bso19980225e9.1 for ; Mon, 18 May 2026 10:05:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre.com; s=google; t=1779123950; x=1779728750; 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=WTijTnfbP2QXvo6ZSkaGvHIK1QTeCa7hz6oIw9U70KQ=; b=I5vgKXhe8+X2Ncsh1TF2iZU/fuAU3iHy4ovIDVgYmxjN2MHQNGZGkGkxAmjIpURQCe 2+EfxOx4VcSfOBEVOgjbn+jGhQjSmRR+HvqkcVUvYjr1vxeKB6O7zfv1YAWuJjfZt9s3 YcixrKJ8E3ZyIZnMysl7LVEJuH9ucocPR9IPPgNn7e4/Zm2a3taxxxJdZjJ9/3n0q6fc j7/ZPuLG3D3Blv2E+eMEAfNgxI3Z8O/7ObonaFRNb+nOflAA55Uv2hyEgymhsGoEqlSe dALgGczSY1WgCkZHcFY7+1cTzYA41VOwfe1oH9oCg45yHopOYzHiPwpFR9D0QMHPErNO sJpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779123950; x=1779728750; 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=WTijTnfbP2QXvo6ZSkaGvHIK1QTeCa7hz6oIw9U70KQ=; b=WGx/mG/WKSeku+VoLjs9kXzbieNQmU9LEfv6WlOFcu068pKsf+9zvvFa0F1njIavFY K4dALtdEUOIZ7aG7+tr7cx8+7q3H75MT/CKjgod1cuJTFQbJ5iJTkMLWf/X4FpvSICq7 BOyRB53H16QyaI1DKuozep2jcUYVfU59rYY6v/luE25KKAczOMtw61PS0IapPrHEuhZP DAxMzczLZto2ZeQcgDYca6wfI0ZCyk+VUwL8dDC1qmqbpTheGjJa7Jitq+alSILxfn3D sAIOzWdHSKNeUJXD5DvzXs0Jhb2ImvG2rZEc2PuH+sFmjtWZF7u0MapEkpFq9OPN8eqS lPZg== X-Forwarded-Encrypted: i=1; AFNElJ8aZWe2X/Kd6pxlL9HpzqjtMNtlJihuZjxjOWhj/s6A3MwkrjiriW4AFZjXniHPgF+LgakK4oKScppceqk=@vger.kernel.org X-Gm-Message-State: AOJu0Yw1TQrDqL0+f0kD+ANw4W4LaepBBU0TwfqxjgfuGKD1SpyJtzQf nTncIAEzFafUSeRsUJYsKLtgxhd+9l3225d2WmC7XeLbRTEYYLWHVQq6UUj80UKVUfc= X-Gm-Gg: Acq92OGWih/NuPSRL6tf4VAuA01mIoiWBBcXgOk+iFBjDauWSXQwIBuiDaZVsnNRQX6 7+UCsTcEhL+/3+CQwRIXufLQmXfUYcIkkx7RNolkDyGI6lPXXvIrFoLP+5jLqxIzRbTnaY86pi3 6MLqtAOKk+5/qp8rVApimyWUGURjA8ebuIxoSAnZM2zig37jpeTcPf7Brw355PS0Lmh32o98aL3 tpNHn77sanft7eoe7XZ6EcI+M8Lr/L79QPxTrZg5tzXvlHCxLCPuPOg8ywIIKpf8ypUotT5vGjS X8qInXanEhnpHInreNxD/XuIbFI4SgU1PHShqQoLWuvRfxiwUK9mnjoUaVTa4dhF1Tbd4W0/TS5 rJHvpBWHKAzz3SMvxfTZBOP+Kknm3AVrUcm47bpotc3NS0P3sO1ykXZdBuyCNYEpuCVutCygM0K IzJO90xg+/sK6ZHUki+H+112Jz+o/rWVQJpSnOQZcM8LADX3yAL0mr8pOLRdaGTsGXq7mheqf/P YMdu3223GE4oA== X-Received: by 2002:a05:600c:8210:b0:48a:5c23:cab with SMTP id 5b1f17b1804b1-48fe6322447mr231303205e9.19.1779123949856; Mon, 18 May 2026 10:05:49 -0700 (PDT) Received: from localhost (p200300f65f47db041bee4d0e08e9609b.dip0.t-ipconnect.de. [2003:f6:5f47:db04:1bee:4d0e:8e9:609b]) by smtp.gmail.com with UTF8SMTPSA id 5b1f17b1804b1-48fe5694fbfsm465987925e9.6.2026.05.18.10.05.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 May 2026 10:05:49 -0700 (PDT) From: =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig=20=28The=20Capable=20Hub=29?= To: Mark Brown Cc: linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v1] spi: Use named initializers for arrays of i2c_device_data Date: Mon, 18 May 2026 19:05:41 +0200 Message-ID: <20260518170542.807843-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=4615; i=u.kleine-koenig@baylibre.com; h=from:subject; bh=v5OIJNsk67U76wJjPC7hqs+G51U6k0pEBy58uPTbPjc=; b=owEBbQGS/pANAwAKAY+A+1h9Ev5OAcsmYgBqC0bmXvyH81515D+CX/H+6I//tUMvr92ExiOop G2sRnSQisyJATMEAAEKAB0WIQQ/gaxpOnoeWYmt/tOPgPtYfRL+TgUCagtG5gAKCRCPgPtYfRL+ TvK8B/9IRB81AvStNb7w8AuHuvgqfkw59qFh/d5a99r1/iDEtPdXzfDHsyHb9XN0452A+XK0Z+5 Ii6ZKhmjAbV7R1q07j+FOGIG1Z7WHa6adlu8ptqjFetQKbUAkvttBEadHS/BaqKhfk5cXDaIH7C 1mrCC/zDcNvtlAMxKRBGJkv/2bl+Hm4Z80qZry9onxsCMRtyd8bUK6NrZ1NvLHF4QDTgyr3Kppi ks3Em2yGDaN1wdU791CRHeeNU9ubQR4hAb0hSYwoe9N3hU1rWx0abqpUKWzFUMkV5K5AfKYoO9z dma+OsINGmJC1if5as7hQnE0W+bW2ZDDqRBYAflTi2gCJ8gU X-Developer-Key: i=u.kleine-koenig@baylibre.com; a=openpgp; fpr=0D2511F322BFAB1C1580266BE2DCDD9132669BD6 Content-Transfer-Encoding: quoted-printable While being less compact, using named initializers allows to more easily see which members of the structs are assigned which value without having to lookup the declaration of the struct. And it's also more robust against changes to the struct definition. The mentioned robustness is relevant for a planned change to struct i2c_device_id that replaces .driver_data by an anonymous union. While touching these arrays, drop a comma after the list terminator. This patch doesn't modify the compiled arrays, only their representation in source form benefits. The former was confirmed with x86 and arm64 builds. Signed-off-by: Uwe Kleine-K=C3=B6nig (The Capable Hub) --- Hello, the mentioned change to i2c_device_id is the following: diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetab= le.h index 23ff24080dfd..aebd3a5e90af 100644 --- a/include/linux/mod_devicetable.h +++ b/include/linux/mod_devicetable.h @@ -477,7 +477,11 @@ struct rpmsg_device_id { struct i2c_device_id { char name[I2C_NAME_SIZE]; - kernel_ulong_t driver_data; /* Data private to the driver */ + union { + /* Data private to the driver */ + kernel_ulong_t driver_data; + const void *driver_data_ptr; + }; }; /* pci_epf */ and this requires that .driver_data is assigned via a named initializer for static data. This requirement isn't a bad one because named initializers are also much better readable than list initializers. The union added to struct i2c_device_id enables further cleanups like: diff --git a/drivers/regulator/ad5398.c b/drivers/regulator/ad5398.c index 0123ca8157a8..dfb0b07500a7 100644 --- a/drivers/regulator/ad5398.c +++ b/drivers/regulator/ad5398.c @@ -207,8 +207,8 @@ struct ad5398_current_data_format { static const struct ad5398_current_data_format df_10_4_120 =3D {10, 4, 0,= 120000}; static const struct i2c_device_id ad5398_id[] =3D { - { .name =3D "ad5398", .driver_data =3D (kernel_ulong_t)&df_10_4_120 }, - { .name =3D "ad5821", .driver_data =3D (kernel_ulong_t)&df_10_4_120 }, + { .name =3D "ad5398", .driver_data_ptr =3D &df_10_4_120 }, + { .name =3D "ad5821", .driver_data_ptr =3D &df_10_4_120 }, { } }; MODULE_DEVICE_TABLE(i2c, ad5398_id); @@ -219,8 +219,7 @@ static int ad5398_probe(struct i2c_client *client) struct regulator_init_data *init_data =3D dev_get_platdata(&client->dev); struct regulator_config config =3D { }; struct ad5398_chip_info *chip; - const struct ad5398_current_data_format *df =3D - (struct ad5398_current_data_format *)id->driver_data; + const struct ad5398_current_data_format *df =3D id->driver_data; chip =3D devm_kzalloc(&client->dev, sizeof(*chip), GFP_KERNEL); if (!chip) that are an improvement for readability (again!) and it keeps some properties of the pointers (here: being const) without having to pay attention for that. (I didn't find a spi driver that benefits, so this is "only" a regulator driver example.) My additional motivation for this effort is CHERI[1]. This is a hardware extension that uses 128 bit pointers but unsigned long is still 64 bit. So with CHERI you cannot store pointers in unsigned long variables. Best regards Uwe [1] https://cheri-alliance.org/discover-cheri/ https://lwn.net/Articles/1037974/ drivers/spi/spi-sc18is602.c | 6 +++--- drivers/spi/spi-xcomm.c | 4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/spi/spi-sc18is602.c b/drivers/spi/spi-sc18is602.c index 78c558e7228e..ae534ebd5e87 100644 --- a/drivers/spi/spi-sc18is602.c +++ b/drivers/spi/spi-sc18is602.c @@ -295,9 +295,9 @@ static int sc18is602_probe(struct i2c_client *client) } =20 static const struct i2c_device_id sc18is602_id[] =3D { - { "sc18is602", sc18is602 }, - { "sc18is602b", sc18is602b }, - { "sc18is603", sc18is603 }, + { .name =3D "sc18is602", .driver_data =3D sc18is602 }, + { .name =3D "sc18is602b", .driver_data =3D sc18is602b }, + { .name =3D "sc18is603", .driver_data =3D sc18is603 }, { } }; MODULE_DEVICE_TABLE(i2c, sc18is602_id); diff --git a/drivers/spi/spi-xcomm.c b/drivers/spi/spi-xcomm.c index 130a3d716dd4..e40ec6ebe4e5 100644 --- a/drivers/spi/spi-xcomm.c +++ b/drivers/spi/spi-xcomm.c @@ -269,8 +269,8 @@ static int spi_xcomm_probe(struct i2c_client *i2c) } =20 static const struct i2c_device_id spi_xcomm_ids[] =3D { - { "spi-xcomm" }, - { }, + { .name =3D "spi-xcomm" }, + { } }; MODULE_DEVICE_TABLE(i2c, spi_xcomm_ids); =20 base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731 --=20 2.47.3