From nobody Mon May 25 01:59:26 2026 Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.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 5AF2D220F2D for ; Tue, 19 May 2026 14:27:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.44 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779200841; cv=none; b=W5g5hGAl4qL43NyveDr6/LTUs2boLpsU4WoRzVAsP6HpC+phYz67qdR+ZL+KPqNoD0bIuyPJo43fcu797uU/8ytOgoo6+cN6qQOuxzkKUJNcD3GEgj9gJ9B0VV3kESNkoZK9Fp/EpqHpuElrpQYqteJBi8Q5gQWnM3q7WC5sOGM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779200841; c=relaxed/simple; bh=0XIrWrrKOXAS4JSnBkq9LW5tElkQkITWVSOhNm7XbxY=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type; b=Hq9H1Uo5q1qAroGd5jnBiCZ/ziQ4Yiw27Ce457JG5FsGMll4pEobumQvULtpGeMuMMvN30Mr15eYRho/8dPg6KHvvrlrd4BS/CsLpH+AYM2KXe7VxYP1h/3VibIGze6vveUSs8oVDGu6uBPSpGbCc89WSAVFVzN8fVI5T6jJYI4= 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=H9CfzdgY; arc=none smtp.client-ip=209.85.128.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 header.i=@baylibre.com header.b="H9CfzdgY" Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-4896c22fcbaso30795465e9.0 for ; Tue, 19 May 2026 07:27:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre.com; s=google; t=1779200837; x=1779805637; 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=GnYW6cai+fx/W9v9Sht8UdcFwU9lnBLs3mWevgJE49k=; b=H9CfzdgYi3z46QMaZV7su4v1RA8u55NUFY3DOv8imzinUetRJAyt2M82Ks1CvcD3qx OlbEaLtzNuhwgbVqexNmZvnmoPhLcRCyILArafpw/9fHjYqq1/Ni+F7xNhV4cNAxQPR9 Q0yZOxfEAWzuf6L8A2+pJ5V8KxhjUehRuWI5R86NqFXmU27wG+koSprRqxSDO9ooxo+P zu+Q8PUU6dXeMhxP5ZaQOi00jkvD7SK3dgWyl+p0pHtecyUEFD4rHFTa4pBvx1wph/gE 11HVOMpyzVce1dCUmekOGHrUB6W5Vbg6qhj6hfI8HYbgiTq94gxlIWQyjVJjL3kMMden sfKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779200837; x=1779805637; 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=GnYW6cai+fx/W9v9Sht8UdcFwU9lnBLs3mWevgJE49k=; b=sHJmFvBNY/mGwsPACLl2IU5EMZRMjDneD0Wu+HzLFN5wiCnj407ISyvizakksOvZno kc/QVrITDRDXGOBpzeX6ApolOb3gevMRz4fPL2Fo1RSRcKN6vSWzd09cYkwNNAl3Wd9o WIJIbScyHKMNFbmgcLna9xRUR33KsiMAhyfUK+i/WmLe/z7ui1/tmvfSYEWTY0SlzNYR 9CICLpcQH8z5UR4uYiYAU7oth4NCGZNJVa2SduBoMC6kVCWt59WuDYl0lGQqxa7vnCZC AFO5v6SHF83bFkyl+z69mpwQRRvOkLtkoce9nTa+krOkAs6uq8Ishz/Qycui9+o4TWmI qZJg== X-Forwarded-Encrypted: i=1; AFNElJ8WlU64j5ezTQLpU0gn2hkKGhXVecLVTRbKv4JEUcr2SMvgMAQd9n6bYbMfDORk6C8S6ECIpF9kNWp0fsg=@vger.kernel.org X-Gm-Message-State: AOJu0Yx0mhUBYz2HE4atRTfCVFsoSTk1gkHKdyaO35S6kR9SSTp5gacD qRISOD2bXV7N57MF1lbQhvrmhlMVkeKWweLVxQFQiIP6EO/I24jzmXGADTbFzUCg77mdh/tLZAg NAy6YgRM= X-Gm-Gg: Acq92OFbs6Iscvrnp2tPhVi+tGKOtyzgB7XvuCo+fCINgle5x5sD2SfgcfqZ9TEnN/L gs4pMlq0qZc1q94PumocfakJ/OjqFZHgR7xVKMOT0gxMU3RrnAtQlVCVecX0TYNJLYqgn4QysK1 hzjOSXrqvQuPkHOtXBPCkvwlIola5qlO8Tzn+9bzQijPKB8XJshrYgvYaqpWCbodapiAIDfrrG0 vH0SKEz+FjrSiH7LjgbOWGYZMyVy+lcUg45c5k7TdaF5usc7HK4Rn5CxZsxBDVdFDw+NvqOTfQ2 oOCSAUTmpDiwIwMkaZxSdFCvsvW/c6R37YVMtZ5cHV3t6/DazOd9ZhVWyO7HRSaoslOJV5tVMd0 ho6MSEUh4AcPS2w4PC7LcjeKRF+ZZIwAJZ4FshSjpPtA+lHe0EX7XQGsEUcJktSMBm9wOU9SkfS uyn11pWd7LGRcvee02VApIq0JlWMiiWA9hYxk46jcPgLidwKzriWoMI1uwhhOicZWm7MvLkewE8 tHa1w33galfYOM= X-Received: by 2002:a05:600c:3e1b:b0:48a:8905:a500 with SMTP id 5b1f17b1804b1-48fe60da647mr333513865e9.12.1779200836810; Tue, 19 May 2026 07:27:16 -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-45d9ec39ff1sm49364941f8f.10.2026.05.19.07.27.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 May 2026 07:27:16 -0700 (PDT) From: =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig=20=28The=20Capable=20Hub=29?= To: Ivan Vecera , Prathosh Satish , Vadim Fedorenko , Arkadiusz Kubalewski , Jiri Pirko Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v1] dpll: zl3073x: Use named initializers for struct i2c_device_id Date: Tue, 19 May 2026 16:27:10 +0200 Message-ID: <20260519142710.1587324-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=1926; i=u.kleine-koenig@baylibre.com; h=from:subject; bh=0XIrWrrKOXAS4JSnBkq9LW5tElkQkITWVSOhNm7XbxY=; b=owEBbQGS/pANAwAKAY+A+1h9Ev5OAcsmYgBqDHM+D4fIZMJcwHlRIDBr/rS0Oqb6HZFnub+fA zJI8208+l2JATMEAAEKAB0WIQQ/gaxpOnoeWYmt/tOPgPtYfRL+TgUCagxzPgAKCRCPgPtYfRL+ TqIoB/95YWl5qAe6ho7LJkiiQ7hS8dEb6um0QjbYJHsChmMD/7b5EoqN5f5vwrtrZtvIj1k8J0u UvBovJsqwWKWoA3/GtHrZLQOlbrMTM4hdg5p6UM1DAm3RFFnBhWXv3wOqrR4GGNHqBqPUI/Fg2D kaHBL3yHa0IFz5bfM6S3sYo2GVjcwVfrEwP44kLZvh+gJ3jge/Yp8AaMfaTG9jaCSbJYP1HfSSM 3GnFN0e1I0QuuFRx/5VJCz2SWudQ3Hro80BmtxLrLm1PS4ExLMmb2KsI1efr0iuG4iNst/cQhPZ fmhriOB54ZIXMuZn219o3eLBhnElyMq3PfxwK+HZvt9hWjyn 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. 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) Reviewed-by: Ivan Vecera --- Hello, this patch is part of a bigger quest to use named initializers for mainly struct i2c_device_id::driver_data to be able to modify i2c_device_id. See e.g. https://lore.kernel.org/all/20260518111203.639603-2-u.kleine-koenig@baylibr= e.com/ for the details. This patch here isn't critical for this quest, as no driver makes use of .driver_data, so apart from the better readability this is only about consistency with other subsystems. This is the only i2c driver under drivers/dpll, so this is the only patch needed to adapt the whole system to the new style for initializing i2c_device_id arrays. Best regards Uwe --- drivers/dpll/zl3073x/i2c.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/dpll/zl3073x/i2c.c b/drivers/dpll/zl3073x/i2c.c index 979df85826ab..4a23340e29d0 100644 --- a/drivers/dpll/zl3073x/i2c.c +++ b/drivers/dpll/zl3073x/i2c.c @@ -26,11 +26,11 @@ static int zl3073x_i2c_probe(struct i2c_client *client) } =20 static const struct i2c_device_id zl3073x_i2c_id[] =3D { - { "zl30731" }, - { "zl30732" }, - { "zl30733" }, - { "zl30734" }, - { "zl30735" }, + { .name =3D "zl30731" }, + { .name =3D "zl30732" }, + { .name =3D "zl30733" }, + { .name =3D "zl30734" }, + { .name =3D "zl30735" }, { /* sentinel */ } }; MODULE_DEVICE_TABLE(i2c, zl3073x_i2c_id); base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731 --=20 2.47.3