From nobody Mon May 25 04:35:17 2026 Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) (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 29F97382381 for ; Mon, 18 May 2026 17:15:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.49 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779124507; cv=none; b=P7HBp3QCeFKRQdq+5Za5VYJmn7vxyjbndIaWGA8FiRD07Fb17lmNN81wxas1bJEPnlesXsYIL3jy83trZXIF/gARbw4Oybl0zvEF866lySU7gDqd93bIAfDi00gkQ7ffjnwVobqidIrHznWDdhy0jasdqpPT41BofA2pD069tLo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779124507; c=relaxed/simple; bh=bM19BoyYaERUgoZcwGuoc/NRODNxQrARsbXs/77TAa0=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type; b=P3Xy/SVup2AEL/khvhP6TpomhejY13buNvte9nSOTL0ldP0ZJaCqx+8xF0/VyJl9W1p/rUNzLIiDeR4XjeRQCNcBE0JZD63X5HO3nzsQd8GMb/8z64UanWG5Uolr8RFoivoBFgGqMlhKwnDkZz1rqp4rMCkrzxnaRouhVT06Utg= 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=g1KebT3W; arc=none smtp.client-ip=209.85.128.49 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="g1KebT3W" Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-488b8bc6bc9so14955325e9.3 for ; Mon, 18 May 2026 10:15:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre.com; s=google; t=1779124502; x=1779729302; 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=PdKwSE8evT0jCvX7UfuhA928WLg86vpz0JlXNiQhHdE=; b=g1KebT3WVmwHVJfGR4R0h8kgOQoJX6P/DRpGuGHKgYTuyh2nWW3w0sYWXIOTns6/nl 94WNGRYWvvy+wHSfJfuqZ14c8hkJizIvFM9Dvg9XQUqflaYrMvqi1bawl3ltCg01UTXm uGjf2MB5yylb1cFK2lmmRCGqsszGxld8zmjOt1MdMCbS5b7FDTDHjb5g1RFQdFknD4Cx K3iw2e0/AMy6YbDPUtvld8pXeMq6Xoh0Nx+dM0Kfv9xrTtpRSJVXUhoZ9FMxPIBGZuCV HrGUYnoYeaU3D1gO2npi3CpAttZUXGaoUSHrLE52Q4uY6m6apsi7EgdF0axyD0Sdi/03 D4kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779124502; x=1779729302; 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=PdKwSE8evT0jCvX7UfuhA928WLg86vpz0JlXNiQhHdE=; b=N+L9yHGsBZGrJwgoEVAgDx4tqWJfV8q/UrvAH37Zx2Y935Y04cbf/j3sk0qLoqrBsv vZjC0KENj2L8WdYXgKWp3VguF4xeQkXzVeI1SdC7qdGF3Jq2WL9MXtairrE+TDmwoB2c GUBLI7C+57HodaMx7TA6r2Md9ISSCZbGHlnBzxeveWuQhFWHO2lBNhwX2yqjYFqd/lB3 3W66B26aizqGxAlknz0d0QF6hzdnCe67K5cmLpP7BarjV+VULDl34i70gU64emlUkmDn mpPqxOHwzJEIE+Ih5p0A/lQ7yL60cjPPprRYfIiFDlTXlAFfrb96QDVLbhiYhCnfcsf9 MYgQ== X-Gm-Message-State: AOJu0Yz2KTaizhYVkI4GDMFBlauKP3GsnRv85vYY/vwQmSAb/YWFxiWK b2jlXl+EZGiiMfD68Bewr5KfeJ4Qi8cWt+Rk3alMf5MGJ2+FlyZHhQbkhCyl3A9XBUw= X-Gm-Gg: Acq92OEc1yLcDx5+PJOlVhVtImmL4dc9RtpR0gPGIldBrF02VHGS7oEGckvs8DnofHN UYs6TKR9Exgp8dXBxQNHJzUmHfasuO0Ttnhpg7waT7bggCIIbVcXpnTuqXo5wv24qdL3gZOsos5 PfL3fE3nQ4vhlZA1z1Anz246M2NJH0j0mGMhkpbrrhh0eA2apN2XMi2Nbbsrn9Wufp3XaajNhNh 3oWsQCXIX5rYt6zEExehe+f1RUTsgy/vUhoFwqmfk/OhlYG6ZtJhpRNOvMnyAlsa/bxbz8udIc9 WBkTbYFK1w626kVdx+MY+Y98yBByXFGJFqEAvFANXNDdl+27Kg7+oMZ0X7TUkZnjPGsNnegVWS6 AMhAMX31RH6DhSdfeUNAKlyXVnd6N1bkVaTMMdnB6G4HUuzZudEuM5eIvD3KTYcz4ksRlntvX/c T4q9TmImOiHtW6OwZeWyrouydZSePbmuIlYukkcHHOh07YEes/xI7JunIIxptkrGq4tTwa7Iv3b TnZEKWX7WAl8n8UlyCbojMk X-Received: by 2002:a05:600c:608b:b0:488:8bdd:cfcc with SMTP id 5b1f17b1804b1-48fe5ea04cemr257470975e9.0.1779124502507; Mon, 18 May 2026 10:15:02 -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-48febe7dd22sm115221325e9.7.2026.05.18.10.15.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 May 2026 10:15:02 -0700 (PDT) From: =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig=20=28The=20Capable=20Hub=29?= To: Krzysztof Kozlowski Cc: linux-kernel@vger.kernel.org Subject: [PATCH v1] w1: ds2482: Use named initializers for arrays of i2c_device_data Date: Mon, 18 May 2026 19:14:56 +0200 Message-ID: <20260518171456.872736-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=4008; i=u.kleine-koenig@baylibre.com; h=from:subject; bh=bM19BoyYaERUgoZcwGuoc/NRODNxQrARsbXs/77TAa0=; b=kA0DAAoBj4D7WH0S/k4ByyZiAGoLSRCg2GpiqLYrxh1kxaX74cgbMC7DE8oIUhK7wpXyv198Z okBMwQAAQoAHRYhBD+BrGk6eh5Zia3+04+A+1h9Ev5OBQJqC0kQAAoJEI+A+1h9Ev5OwaYH/0NH lLpdkFah+MV9zIxroKWreAyPH1CjoBI0KCebRL8OtUpYjZVzRPjloEPQxXYxp00m56hN88i89Ax fcMHfYCJEJ7d3nky+jKBuab7ACo2E6bf9rLo7Ee+wzsNaFrAoe84Zl03NE61p+lcBMy63iRJIyV Ub2d8ScvUVY/qOz+l6UaNBl90VYTnLf/WiJZLJ0JaWEPlrTF6kJ2Ry1HksZJclb1puYt3qN7JSK OTxEB61eAR9us3/vy/CwV3RsuoVH4IlmDWyqU+8F/1EfBFvZN6rIsGtqACAxteoDOnVsYeEq30B gejHmFxlyGxU55o4SVcYOLPCeiez9X73Usi/gXU= 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. 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 tpm 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. This is the only w1 driver needing adaption (as of v7.1-rc1). Best regards Uwe [1] https://cheri-alliance.org/discover-cheri/ https://lwn.net/Articles/1037974/ drivers/w1/masters/ds2482.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/w1/masters/ds2482.c b/drivers/w1/masters/ds2482.c index e2a568c9a43a..0069e6f854d7 100644 --- a/drivers/w1/masters/ds2482.c +++ b/drivers/w1/masters/ds2482.c @@ -539,8 +539,8 @@ static void ds2482_remove(struct i2c_client *client) * Driver data (common to all clients) */ static const struct i2c_device_id ds2482_id[] =3D { - { "ds2482" }, - { "ds2484" }, + { .name =3D "ds2482" }, + { .name =3D "ds2484" }, { } }; MODULE_DEVICE_TABLE(i2c, ds2482_id); base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731 --=20 2.47.3