From nobody Mon May 25 02:54:31 2026 Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) (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 8AF903ED3BF for ; Tue, 19 May 2026 14:01:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.53 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779199279; cv=none; b=TR6kNww37tTgmJLN9Vkucg4wdZCHc8knkR1wxLWvOVKxhMZS6rcbklRM6r+NvWj2HcvnvDIkXuVm67y1lqdTaU85LgE+i7kE5QNXyTNAWTe43/GuSZQBXhh0+CRw6wSj4QyiQuZ49cnQi7f9qxKEnrF/SkFcUXlggSO3/8nwONc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779199279; c=relaxed/simple; bh=Unbfd+jMuUVdbtRMYUn9CMrCJcN79/joicb4mz1QtVk=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type; b=ABkJUNFIwrl1H+v7TyJtSVv7PtT0cIHUyoN/6BXMbSgqhPhvnd5R+yScD4godryicm7AY+DGW4jzISFPfwJVIuPpfODmVjxKhaMpWvDKVUWrKW223XcoLZOkA1w38t8j41f4o/YnzNhi857Df410J+dNkItoNtqK8Y9sSymk28M= 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=bv4sxd4r; arc=none smtp.client-ip=209.85.221.53 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="bv4sxd4r" Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-453903ee4adso901854f8f.3 for ; Tue, 19 May 2026 07:01:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre.com; s=google; t=1779199275; x=1779804075; 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=s6V0npOlv/pb1pXj0+v8WQf0cSg92bgbaYxRXmYzFU0=; b=bv4sxd4rsJkTK7N0ubnrvFRxlVJ85FE+SSu+jz8irJKMsFSRKBC+sar3HWOUBDBqsq HCGj/2aPydbuOXjU5QrZCV97ALlUpwah6Pg/76pUrt4oGqv8z0L1dZ60fpuBmDmg92p5 +qaztR7AeJ6jYf8sO5oNfRJXoOfV04u1Rieifyqgex3x04BM3aPVTDELziaKjQ2O0j7u btyXBDAtDdFZSRewa7R3tgdaA57AtH1/IAHTYY9Hx5nB9Stwx4HksYKvyzWjmEW1GP7g wxuaCBX8bL0W0XhL1QY5mvAPAUbvVQ596fNY1PzXbyjrAmJXGi/LzyVXmFkWRWN+Fhvl Metg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779199275; x=1779804075; 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=s6V0npOlv/pb1pXj0+v8WQf0cSg92bgbaYxRXmYzFU0=; b=BN7Dbze0npPu2AWBuOPMyvtgWkAAvkRjQT9Uqyl3mrJ4IjF1OU0dw17z+q9FC1xi/M nlIC9idRqNzqhZ7JJ31/NjI1vAXRpkxeKWi4KL27EKC/m7MXAtRBTJ6rOdLNDJA1vjpr oBDhKe/t+nVFETm+Lp3RW5w4n0NahROsD7GHItGImqAIlxlF/8pTT96D9T4PDKUnMPA5 692bE5aMtwHLjk1/g8ZL2DG//ThSD+tNhGZqZYUKvY1pfA5BCBGp/s8z2KfkYGOjfoEK ghQbL95oVmm2Wrst956FKOge6eqTmpd8t9BBTU/BmgYfkL+ankyPgIkfEbWkaYX/oiSx OJfA== X-Forwarded-Encrypted: i=1; AFNElJ/v/XG70tMrXct8unZpcNMKg1ly4ebVYyDv8t9fVdAAxK54j51VadcbDoPa2umGM0tVYF625GtmCqRCp5Y=@vger.kernel.org X-Gm-Message-State: AOJu0YwE86+2/lz0Am2uUtTMSb22P7S8dFkgsnF9ZX+auLn4wrUNDqF3 2wHH49P4phRv1mcckSmgW8XK+BiV/4yy423SLSWR+0QB0xIJeSYW+Uq4yCC0pvsniBY= X-Gm-Gg: Acq92OEXnGEzsXMsQlj8vIzS7MWLfDXbwj7vQHJv7TTtc0e42dwXlA1k6OAfUSZ9ICQ YJlPjXSQ8FvDXcwu9YZgmpHOpy+4HVViInzkBSNmy7od7Y9VLU59yNv2t24TcVkLfZ6xjmpK96Y HvlEDdZ4eljpTwLZR5S2yEOSwdkXUBMEXW+NnB7v8fTocQm7Jg4jbvGAbkcHJCjMIqSsGBlnGy+ DvOr99wQnbNODXKK/0K1gBoT6qnxppXnHAn6q+lT3DYVnqYPtHr9XzeAjPHe6vC5LaBPB3dGA9r x8B3qQrUItvWxdwKmgGmP2qjuEnVfiPTIqiD0CEvRnJf4nj1Hg08ihxE1jSOG671LphmyEXyGr0 oLtAGPYCEsD6w6Ou/eEPPQBH/OiS0MlyG712Idl22xa2GT3e/ZuFNFsGyhOh38uqO5K3dpGb/Yp JiYehXjgSyr0LS48SrqE4YV/7qLKfLKE0uGrkRbp6GDAkhCf/r1ETvK9jePaidGzpcHCjlARCUN iyP3tZoPLBBTmw8HvLDEz4BMg== X-Received: by 2002:a05:6000:186c:b0:44a:247e:67b1 with SMTP id ffacd0b85a97d-45e5c35e40amr31881085f8f.5.1779199274455; Tue, 19 May 2026 07:01:14 -0700 (PDT) Received: from localhost (p200300f65f47db048a8dfcf61053817f.dip0.t-ipconnect.de. [2003:f6:5f47:db04:8a8d:fcf6:1053:817f]) by smtp.gmail.com with UTF8SMTPSA id ffacd0b85a97d-45da0a178adsm48461563f8f.18.2026.05.19.07.01.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 May 2026 07:01:13 -0700 (PDT) From: =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig=20=28The=20Capable=20Hub=29?= To: Oleksij Rempel , Kory Maincent Cc: Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH net-next v1] net: pse-pd: Use named initializers for arrays of i2c_device_data Date: Tue, 19 May 2026 16:01:01 +0200 Message-ID: <20260519140101.1584946-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=5192; i=u.kleine-koenig@baylibre.com; h=from:subject; bh=Unbfd+jMuUVdbtRMYUn9CMrCJcN79/joicb4mz1QtVk=; b=owEBbQGS/pANAwAKAY+A+1h9Ev5OAcsmYgBqDG0ewcHQT5DffG5Eg6fy1z4TZi+R4rnoEDhWo xvM9vwuA06JATMEAAEKAB0WIQQ/gaxpOnoeWYmt/tOPgPtYfRL+TgUCagxtHgAKCRCPgPtYfRL+ TvVcB/0QT6bP47k1eZUYJ00NbxGEls4QW7QmMlOonh8h6dGDUDOFHKAvrMBqDANFkfgrYzbmvs3 QTNQlqYMCefFMtsl+SejqGqtaHDsG2rc2OvjZvc/N0yobelPOWdSfPr198Kd9HRAxtrej5r0oG0 wDagpnXX8GyPXiNlk7XuBOfPU6EdsiiAJq5wWMOyfeGZanvuHvR8lVfCQw4BI9ioiEkDGhLfdJE EAotOUNcEscyU/FYUl07ZVjPozmJehxTP0TDzyTbHJH7qx95AzbxJO3ZpG4tKxMapkCBMlzlv+O xEAwLEbKTdhUk5n+kxZWwMER31aoNQ325rJqSJPbcvF5qZSc 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) Acked-by: Oleksij Rempel --- 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 pse-pd 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/net/pse-pd/pd692x0.c | 2 +- drivers/net/pse-pd/si3474.c | 4 ++-- drivers/net/pse-pd/tps23881.c | 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/net/pse-pd/pd692x0.c b/drivers/net/pse-pd/pd692x0.c index 4a3c852780f5..49b1527829ad 100644 --- a/drivers/net/pse-pd/pd692x0.c +++ b/drivers/net/pse-pd/pd692x0.c @@ -1853,7 +1853,7 @@ static void pd692x0_i2c_remove(struct i2c_client *cli= ent) } =20 static const struct i2c_device_id pd692x0_id[] =3D { - { PD692X0_PSE_NAME }, + { .name =3D PD692X0_PSE_NAME }, { } }; MODULE_DEVICE_TABLE(i2c, pd692x0_id); diff --git a/drivers/net/pse-pd/si3474.c b/drivers/net/pse-pd/si3474.c index aa07ffbce54d..1845b9c51cf7 100644 --- a/drivers/net/pse-pd/si3474.c +++ b/drivers/net/pse-pd/si3474.c @@ -550,8 +550,8 @@ static int si3474_i2c_probe(struct i2c_client *client) } =20 static const struct i2c_device_id si3474_id[] =3D { - { "si3474" }, - {} + { .name =3D "si3474" }, + { } }; MODULE_DEVICE_TABLE(i2c, si3474_id); =20 diff --git a/drivers/net/pse-pd/tps23881.c b/drivers/net/pse-pd/tps23881.c index d40cb35a2547..49d6389da067 100644 --- a/drivers/net/pse-pd/tps23881.c +++ b/drivers/net/pse-pd/tps23881.c @@ -1528,8 +1528,8 @@ static int tps23881_i2c_probe(struct i2c_client *clie= nt) } =20 static const struct i2c_device_id tps23881_id[] =3D { - { "tps23881", .driver_data =3D (kernel_ulong_t)&tps23881_info[TPS23881] }, - { "tps23881b", .driver_data =3D (kernel_ulong_t)&tps23881_info[TPS23881B]= }, + { .name =3D "tps23881", .driver_data =3D (kernel_ulong_t)&tps23881_info[T= PS23881] }, + { .name =3D "tps23881b", .driver_data =3D (kernel_ulong_t)&tps23881_info[= TPS23881B] }, { } }; MODULE_DEVICE_TABLE(i2c, tps23881_id); base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731 --=20 2.47.3