From nobody Mon May 25 05:13:13 2026 Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) (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 CFD4F3264EA for ; Mon, 18 May 2026 10:15:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.44 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779099311; cv=none; b=E+zOPYAMr83dnm8xc/U7vi9U/lcji9efopxxzgUqLJjTRiSV7TEH5atmyNtgpjlN0LzuSy98FO7myNebEcFjgFHe03Z8DxxlUUt5zup4cn1BXwP5cpw3pk/pD+vGNRwX6ICay7G8wnkijyYYlo67KdsqikYh0EstJBF1d9P7IvM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779099311; c=relaxed/simple; bh=gWVfDidBZPIWcU7dRUXxYpUwrEW3lYdjaP8RDg7ddWk=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type; b=VkPhuZ1sTXld23zdDFTtrFelDMRIaTAjNZfyrUCts4x9APdkKpgBbY2ZI19kLCopFQHExpeqYvyEF4l04pp5zcPPvtorgfgQ5CvSKmDktHvQMoESfp+gh+YbDreNdSAF+qB+tTX2caPw112Gb0WWZcOuSGZs1iRC2tGByhERQHY= 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=dqeBG6zB; arc=none smtp.client-ip=209.85.221.44 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="dqeBG6zB" Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-43d76dd4ee8so1772697f8f.2 for ; Mon, 18 May 2026 03:15:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20251104.gappssmtp.com; s=20251104; t=1779099307; x=1779704107; 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=yef2OxHPO6NCColQiJSX2213UsQXUe9NzdyRR7J7TuQ=; b=dqeBG6zBlebhZNXRBM4h8Z6dFeDqk8N6a/h/n2LqLcLZUitmpqanqA+1XAvzkYHFSm v5Q9NtrTnckTrLPG219Z3J9HyzbEB3gFzldUqkchROYtKlrISKqsG/vyIJ7ieqrbD8c/ zzQ7G8TYgxYYocEFm6PgL3drn52yDJF5QMW0WBBaBvOc9M+FGY3qw2R8IJ5l8/5ivFDz y4qXartjCEUvE0gkarpt8VeGIjyj59YY68BzhnEq6/hOWWSmI8LM6lE4eexQXN9zVTHy Mo8kiuY/cI1vMr5i+jLH78b+sEI51N6x+DLd1czDISctFGUDCpmQQw6Es68AAw5kpws4 88zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779099307; x=1779704107; 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=yef2OxHPO6NCColQiJSX2213UsQXUe9NzdyRR7J7TuQ=; b=aL63SYWLagkj5qyVwv68CibR1/egEpk09GMPhk6zdy+k9tCChoKNttFhM3NbRzzoWQ IU0J1jgGo/0FeEgQFBsIebUbPQthhkF16nBSobpq54pL7+WDMpTySPb2jwxBXpfEVO4z kddlVJPjUdF7X4H/ZvFuVCN0i0C+gjDpANYybJcyzlfxH1dWfvS3GlJvUo0f1ua3Tmq4 m+FyZQKcLL22G7rte3L96QjLj4MWNFXv4xTiVARLmvs2io+hTyHZnfxgXOyea7qbNG3V 0Gb2lE12+EkyMXqYyV7Xpz7CkwehnpcaqUOT/GN8BWAglxBffWKWKMXnper872m6fYoJ TiYA== X-Gm-Message-State: AOJu0Yyeh804KpM+LnbsYUl/GEYT/iN/0G3+T57pqSZ+u6xvSzQ3IHPd /MNLLpIensnKB6BSXrL9JRw8/2OdOG472l4cmwKk9OpLtr0mg+2RrLC3wuIkGb57nGs= X-Gm-Gg: Acq92OHS4iyfbQOO/Vx/7mUJ2h2X5C54oivbLwu1NB3I6IAclcWj3z5a9ulUyXrRLuj umEetL4Abb5cv1CL96G4YlkgtUwsEuIlxyeVygLmhohA7Ixmo/HaIQrJWn4Kev5Ud1MYSt/mE/7 IHYit+ECUs2flwFL9a/90Z38FAw5L8oVHkIfQyqF3AmQLgnuwTD8FU+ICVtv0F6fXp4/tHazeXh Uw7LifTUmqIZCK18UxI2vbpZJ+x3eYj8BAgkuicSBnGorcb0iyc6/4Kboft6uaMglOezXkGIxPt ICiPm0rRB/azdgE2H4QKj5bNQjhr2vrTT1EwO92PEjq7dyz+XpQSmlgebFnx5OVVOLqpaDhiIuR 0N60z7BM3mfcFWU4caW6pUDQQ2yxFPVMzHl9osGoF5BkV+n3WrZ9T5IaD1wR1q8F3Ktdu+Av1PK 09MX06nIl3AWp0jo7BTJEMIR4sPN+HzztYgZzi+W1QCVSbPF9rzXy8aRw+oKQX3szeSu3741wEQ 4mXhtMzIgHWmzFi82tn610y7A== X-Received: by 2002:a5d:52cb:0:b0:45e:655d:6f7 with SMTP id ffacd0b85a97d-45e655d0715mr12424737f8f.24.1779099307115; Mon, 18 May 2026 03:15:07 -0700 (PDT) Received: from localhost (p200300f65f47db049367b55fc4056f2b.dip0.t-ipconnect.de. [2003:f6:5f47:db04:9367:b55f:c405:6f2b]) by smtp.gmail.com with UTF8SMTPSA id ffacd0b85a97d-45d9e768c4fsm36171677f8f.8.2026.05.18.03.15.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 May 2026 03:15:06 -0700 (PDT) From: =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig=20=28The=20Capable=20Hub=29?= To: Greg Kroah-Hartman , Jiri Slaby , Tapio Reijonen , Dan Carpenter , Xichao Zhao , Bartosz Golaszewski , Hugo Villeneuve Cc: linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org Subject: [PATCH] drm: Use named initializers for arrays of i2c_device_data Date: Mon, 18 May 2026 12:14:56 +0200 Message-ID: <20260518101456.632410-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=5912; i=u.kleine-koenig@baylibre.com; h=from:subject; bh=gWVfDidBZPIWcU7dRUXxYpUwrEW3lYdjaP8RDg7ddWk=; b=owEBbQGS/pANAwAKAY+A+1h9Ev5OAcsmYgBqCuag1ll+dFBRP6YGuv0PULwXrN7t/tr7kjdCk 9FQMlq7EvaJATMEAAEKAB0WIQQ/gaxpOnoeWYmt/tOPgPtYfRL+TgUCagrmoAAKCRCPgPtYfRL+ TvGFCACOtQ1XBECOWkFXKtQ8nGd0VvMSH0Tn390ZoXc4NflYGpVfsWgbjc+ffBNEUE1N0MGMDkl bCOYiiZ8pliyh6raMxUWjDvU3AsgYGMSqDFE1rXoHd3Vft9B+x5JXWRXSFfCgcg8DBCL1NtowBj B1UkOE2scC1NW0ejBzIJW64iT13zCMGb0rUXnYCAC+lAzOELqSAVOvkmbhsyZ0llEzvFlxJoI+6 7xGElcktfXn6Jc/Rh+9+pW3+et4jPDFnThHY52H+23iduulDh2VTAu/fhcp0PybNXMl0kpBQZ9T 30r4s0spXr1uYIvvd9w0/IG/LqUgxIcLtPtNJpukRlKWLjTj 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 all these arrays, unify usage of whitespace in 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 serial 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/tty/serial/max310x.c | 8 ++++---- drivers/tty/serial/sc16is7xx_i2c.c | 14 +++++++------- 2 files changed, 11 insertions(+), 11 deletions(-) diff --git a/drivers/tty/serial/max310x.c b/drivers/tty/serial/max310x.c index ac7d3f197c3a..742b8c23bacf 100644 --- a/drivers/tty/serial/max310x.c +++ b/drivers/tty/serial/max310x.c @@ -1671,10 +1671,10 @@ static void max310x_i2c_remove(struct i2c_client *c= lient) } =20 static const struct i2c_device_id max310x_i2c_id_table[] =3D { - { "max3107", (kernel_ulong_t)&max3107_devtype, }, - { "max3108", (kernel_ulong_t)&max3108_devtype, }, - { "max3109", (kernel_ulong_t)&max3109_devtype, }, - { "max14830", (kernel_ulong_t)&max14830_devtype, }, + { .name =3D "max3107", .driver_data =3D (kernel_ulong_t)&max3107_devtype = }, + { .name =3D "max3108", .driver_data =3D (kernel_ulong_t)&max3108_devtype = }, + { .name =3D "max3109", .driver_data =3D (kernel_ulong_t)&max3109_devtype = }, + { .name =3D "max14830", .driver_data =3D (kernel_ulong_t)&max14830_devtyp= e }, { } }; MODULE_DEVICE_TABLE(i2c, max310x_i2c_id_table); diff --git a/drivers/tty/serial/sc16is7xx_i2c.c b/drivers/tty/serial/sc16is= 7xx_i2c.c index 699376c3b3a5..6c2a697556a6 100644 --- a/drivers/tty/serial/sc16is7xx_i2c.c +++ b/drivers/tty/serial/sc16is7xx_i2c.c @@ -39,13 +39,13 @@ static void sc16is7xx_i2c_remove(struct i2c_client *cli= ent) } =20 static const struct i2c_device_id sc16is7xx_i2c_id_table[] =3D { - { "sc16is74x", (kernel_ulong_t)&sc16is74x_devtype, }, - { "sc16is740", (kernel_ulong_t)&sc16is74x_devtype, }, - { "sc16is741", (kernel_ulong_t)&sc16is74x_devtype, }, - { "sc16is750", (kernel_ulong_t)&sc16is750_devtype, }, - { "sc16is752", (kernel_ulong_t)&sc16is752_devtype, }, - { "sc16is760", (kernel_ulong_t)&sc16is760_devtype, }, - { "sc16is762", (kernel_ulong_t)&sc16is762_devtype, }, + { .name =3D "sc16is74x", .driver_data =3D (kernel_ulong_t)&sc16is74x_devt= ype }, + { .name =3D "sc16is740", .driver_data =3D (kernel_ulong_t)&sc16is74x_devt= ype }, + { .name =3D "sc16is741", .driver_data =3D (kernel_ulong_t)&sc16is74x_devt= ype }, + { .name =3D "sc16is750", .driver_data =3D (kernel_ulong_t)&sc16is750_devt= ype }, + { .name =3D "sc16is752", .driver_data =3D (kernel_ulong_t)&sc16is752_devt= ype }, + { .name =3D "sc16is760", .driver_data =3D (kernel_ulong_t)&sc16is760_devt= ype }, + { .name =3D "sc16is762", .driver_data =3D (kernel_ulong_t)&sc16is762_devt= ype }, { } }; MODULE_DEVICE_TABLE(i2c, sc16is7xx_i2c_id_table); base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731 --=20 2.47.3