From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dy1-f177.google.com (mail-dy1-f177.google.com [74.125.82.177]) (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 3425124468C for ; Sat, 30 May 2026 05:56:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.177 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780120616; cv=none; b=S28tmZonVsOGWmb0y8jfd0jGZFE464zqn2TFaclD/yYqzSDC5XVDbe+ClovLcN/1WkfQmxmDtJSwk5u9f2Wdk7ks4rrh8VmuJlUywjvJDTVVkSTmbQdTOAmCYyLhQs8Z6WURj693P4DeUtKDBU5g7FTXSX8egzL6DcCivolldd0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780120616; c=relaxed/simple; bh=VKlbh9zABe3hibSJP65y9fDmKIjGpOWF/vplfy6zmFI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=KOG80QXjQCMQynVfqMPItvZgdstjR6telQATzRG77J101nNZvPbsebzpMnFlFXc0s4VQg/0oZDupNUpXaDFdoRZi5N7s28o67VzN3MH4gP/bobR4iGylbYhYYciw6Y3YeEbhThk2iGsfj0gtcbyX2z0zXUfY14V1I4IGCHbsILQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=IY9aLBn0; arc=none smtp.client-ip=74.125.82.177 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="IY9aLBn0" Received: by mail-dy1-f177.google.com with SMTP id 5a478bee46e88-304f590dd91so985300eec.0 for ; Fri, 29 May 2026 22:56:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780120613; x=1780725413; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=uR8xbGosrZDiZ3bGOF/uomoehMbPSntRHGsC0W465dY=; b=IY9aLBn0Y5TN6P5kMJGt0mMohZ5iKW+MXKngkZgWYnfYC8zC9Mi4iTXkoz+T1BmwJ1 0I/cDban2uJZVXzczDLBAlW6apmd3o2E+asFknRPRv8sBSeBeMKhDvWLGJC+e8JDMU6F +Tq/N51cDIDxPDbcLgOb0LHgnPxcs3LyviHMBQQ8+5nKXgLZkQZA8D2IOmXu+1MXaLIz f7vfl9swyNQGpyUtg78ewSUXeLLeXYzPjWqE+5oqhknfClnOIWALL94VwQO40iS5iAw/ wfcguMFr0l6vVhOHCTCaovanBC76BLNzqe20JbRo25CTf7T/bD4/rR9/wyKbYRTibduz LZNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780120613; x=1780725413; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=uR8xbGosrZDiZ3bGOF/uomoehMbPSntRHGsC0W465dY=; b=HehkzcCqLpS9p0Dk4HNxABNe+/brZXL0vLrcEBl/LHjXNFB3Jbj8JVt+hQmHmwMVx2 azFezLK2XLi0K8sP9yzQIUwdgtp4T81arxuelhR6MkKquBh8U7ettyhWsGjceZJTU5lU dH/FOHeMBsc1GgGEisvoom3GxYoKyJfT2FwYMveU/ovBBJZMQWwd56kBtPtUi06GCXe9 Ko0HcY0v9Uu6DtwT9X0j6gNaxINQJn3D2SNt/0L6vaTQ8yv0Wx/bOmwDqE45NchVdDXw XytFwP0/+9eyZeUY5w+dWjaZdS4WBxc6xYAX8r3ofhc/h3W6YjTe6Geu3s6htdTUDgBK ocFg== X-Forwarded-Encrypted: i=1; AFNElJ9medIzBZPlm+JRKkuM7w+XQCYOr2rOmSlrWCpECSSmP0+Tb8fFFyYkGzz8Eyja9MsyJDhzknexHTAsZO4=@vger.kernel.org X-Gm-Message-State: AOJu0YxcX4ejVEKELJWNlAR3w05YOhhgJwR6Sw58dTiqXzV48yFC+sIf 8joBE2G+uQVtAN6Rynw1gsa25bO5DGHQS5miowKK0uw44j7esTKK8VjT X-Gm-Gg: Acq92OFrEuhzjOGwkyLyG9phNBgEvIKbUe3xrlHImfU/sgOfPGrTNVn3hxTs+5Ek8UQ FgBkb/+o2v2ie3Y6QCkK51dYKzuC9Hvf/RNxYgD97JnzvGn4cY+IKBE6CMal3Iq7UBqyjF+nU8z nMGcJOxnaLPyWFhuz8LBBt8OAF5Wswe4u21MLfkx2AaxhSt+myrcF6jwibe+Dqm7sJCBSzZSmxV HURXziF7K6t7kVidFImZqcfRhStdZfOqnMLpjin86UUpoys8V3765nCdwtCoJD/cdnypZktsqLP samBNasqFZN/lHGlhvypqYHIS2lQ2ZuQFG0VXuLowKMTMSu35AMja+Cy5+vgwOaCiJE87jQKGWP H6PIlohGvMrs2YPvV4WvoDS+hpM45+dNbL+FeAvoPbLdD/ilyThVkwgg/JL/cmFBlZ6mkmcjg53 pHNpVNDeHry6mnVSXylwPAN6tNy5XQm5Ba1I9AN6ITF/7Oa6b3wC39Osdx1f4031baPzxdLpxrt IM= X-Received: by 2002:a05:7300:80c9:b0:2e0:1f09:d924 with SMTP id 5a478bee46e88-304fa526036mr1388786eec.5.1780120613171; Fri, 29 May 2026 22:56:53 -0700 (PDT) Received: from google.com ([2a00:79e0:2ebe:8:307d:2a52:8823:4a01]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-304ed53f002sm3397737eec.18.2026.05.29.22.56.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 29 May 2026 22:56:52 -0700 (PDT) Date: Fri, 29 May 2026 22:56:48 -0700 From: Dmitry Torokhov To: Uwe =?utf-8?Q?Kleine-K=C3=B6nig_=28The_Capable_Hub=29?= Cc: Anshul Dalal , Michael Hennerich , Yassine Oudjana , Linus Walleij , Nicolas Ferre , Alexandre Belloni , Claudiu Beznea , Support Opensource , Nick Dyer , Hans de Goede , Job Noorman , Mika =?utf-8?B?UGVudHRpbMOk?= , Maxime Coquelin , Alexandre Torgue , Kees Cook , bui duc phuc , Thorsten Blum , Yauhen Kharuzhy , Sakari Ailus , Marco Crivellari , Minseong Kim , Ingo Molnar , Thomas Gleixner , Oleh Kuzhylnyi , Marek Vasut , Krzysztof Kozlowski , Geert Uytterhoeven , Josua Mayer , Michael Tretter , Jeff LaBundy , Javier Carrasco , David Heidelberg , Petr Hodina , Svyatoslav Ryhel , Johannes Kirchmair , Andy Shevchenko , Xichao Zhao , linux-input@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, platform-driver-x86@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com Subject: Re: [PATCH v1] Input: Use named initializers for arrays of i2c_device_data Message-ID: References: <20260515164848.497608-2-u.kleine-koenig@baylibre.com> 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=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20260515164848.497608-2-u.kleine-koenig@baylibre.com> Hi Uwe, On Fri, May 15, 2026 at 06:48:47PM +0200, Uwe Kleine-König (The Capable Hub) wrote: > 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önig (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_devicetable.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/input/touchscreen/ili210x.c b/drivers/input/touchscreen/ili210x.c > index 66ada7ffbc80..94aa4dc002c5 100644 > --- a/drivers/input/touchscreen/ili210x.c > +++ b/drivers/input/touchscreen/ili210x.c > @@ -969,7 +969,7 @@ static int ili210x_i2c_probe(struct i2c_client *client) > > chip = device_get_match_data(dev); > if (!chip && id) > - chip = (const struct ili2xxx_chip *)id->driver_data; > + chip = id->driver_data_ptr; > if (!chip) > return dev_err_probe(&client->dev, -ENODEV, "unknown device model\n"); > > @@ -1049,10 +1049,10 @@ static int ili210x_i2c_probe(struct i2c_client *client) > } > > static const struct i2c_device_id ili210x_i2c_id[] = { > - { .name = "ili210x", .driver_data = (long)&ili210x_chip }, > - { .name = "ili2117", .driver_data = (long)&ili211x_chip }, > - { .name = "ili2120", .driver_data = (long)&ili212x_chip }, > - { .name = "ili251x", .driver_data = (long)&ili251x_chip }, > + { .name = "ili210x", .driver_data_ptr = &ili210x_chip }, > + { .name = "ili2117", .driver_data_ptr = &ili211x_chip }, > + { .name = "ili2120", .driver_data_ptr = &ili212x_chip }, > + { .name = "ili251x", .driver_data_ptr = &ili251x_chip }, > { } > }; > MODULE_DEVICE_TABLE(i2c, ili210x_i2c_id); > > 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. > > 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. I like the ability to properly set up pointers for driver data, however I do not think we should use named initializers for name field. As long as we are not planning on moving its position I like the brevity of just saying { "ili210x", .driver_data_ptr = &ili210x_chip }, Can we keep the old style for the name field? Thanks. -- Dmitry