Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 12 Jun 2023 11:59:44 -0500
From:   Jeff LaBundy <jeff@labundy.com>
To:     Neil Armstrong <neil.armstrong@linaro.org>
Cc:     Dmitry Torokhov <dmitry.torokhov@gmail.com>,
        Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Conor Dooley <conor+dt@kernel.org>,
        Bastien Nocera <hadess@hadess.net>,
        Hans de Goede <hdegoede@redhat.com>,
        Henrik Rydberg <rydberg@bitmath.org>,
        linux-input@vger.kernel.org, linux-arm-msm@vger.kernel.org,
        devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC 2/4] input: touchscreen: add core support for Goodix
 Berlin Touchscreen IC
Message-ID: <ZIdPAKqSsbXLrqHa@nixie71>
References: <20230606-topic-goodix-berlin-upstream-initial-v1-0-4a0741b8aefd@linaro.org>
 <20230606-topic-goodix-berlin-upstream-initial-v1-2-4a0741b8aefd@linaro.org>
 <ZIai3KaMmuAbJB3M@nixie71>
 <3ad327dd-cefd-b195-2d64-6d6afc2d4283@linaro.org>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3ad327dd-cefd-b195-2d64-6d6afc2d4283@linaro.org>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?ewWKLvhBABKsY464ApFEbu0N5V8uWKBXQaCGPUpP7N4J8vTXVy3OnJyCj9Qn?=
 =?us-ascii?Q?W3iiOZqJFABLhOQq+kePefkq5U8EUvuFyLC2ROlErz+Z5YI6gRC9Rt8IW7dv?=
 =?us-ascii?Q?VuQ/9GGXVmObD0mRYzvrdFZ4Pgjuvr+mPHkE+BKyMboKIFDYOuPehW4c/ICj?=
 =?us-ascii?Q?Nz6pH6H6ZyIMTxzheRkP9uZK9l9nURhy98Fz1ZcpYDWfjy0/mu9SqhrSwMzW?=
 =?us-ascii?Q?zGSTOOEuhu41jexujVPE6wU2s1nOaSBdBWA69+RbPvxdDn2vTI6M1V86NnzE?=
 =?us-ascii?Q?wlMsWl0OWijoZ2OYOy5yKJPc7znx3m+1/gjXGO8+rrRq9Cw/Ohpr1cRLOV08?=
 =?us-ascii?Q?BVdhQ8zx051flt6iVqhHR26G5snM5VLm480zdBww7bOHIbLGAeSqsn5zSlq3?=
 =?us-ascii?Q?shAQkFciYDtwyZj0BjJmMO2OtQInXXbKb6rsIZLKMIlijeXsGu94LT4u1IV2?=
 =?us-ascii?Q?bz08oKmBNx1Aj1xSig5nBRyfYLdN+CC0+mek9xc4RzW05XniXgMUrZ952PqB?=
 =?us-ascii?Q?4pT99inH66Ufil331P4WHiSLW/PM9aF8mkqjWJJUE+92FDi/TpYO8GDQ0jCE?=
 =?us-ascii?Q?qQTiUbSwTRiXMifNI8Xfde70sbPjJfUPEDPB5PXerYJAaCiZQkLHYPbyrS2Q?=
 =?us-ascii?Q?LQpB77/Ez6B8EaSLUCsu0hxewbzTy5VgKMejb44/1lJg1mxz0FuK5s3FlvsC?=
 =?us-ascii?Q?ptLqMKUGNH7ykURyYIdP0oSzYm8cqiBz3ZAQGyQS8sMuxlo49Hg9XfyOvC9y?=
 =?us-ascii?Q?531P9PuiU//EFD812DY5IBiK7ORGJBlPt8O2VqRKXXhxw4sjZjOvkYsaAKWK?=
 =?us-ascii?Q?H6Hobl11nl/8wDmOdi/Cn+tGjrKrX6HB4VjuSKQk7U+GlQRY+XRj91/wdtgZ?=
 =?us-ascii?Q?0QWv7m2sOlS++uCB2tKtRpNK02qaZi1GG5Mrcegywl8C0Ur8enAaF99ICwa2?=
 =?us-ascii?Q?gMXqFNy/ivdI41utH0MuXNqybjX5YvsEm3BzJZeL+nngpIXDz063GWS2oIp7?=
 =?us-ascii?Q?BwDiTjkx3kjuE1gkx4fJNSiRfRYW+kk5lxH6/u0mCBH25qRXX3SBEKyr+R6d?=
 =?us-ascii?Q?MnnWHCqXurcmNejrWa0dNGFkD6sbLwGnPTpFgX/HunxBcX307sJ9fY4yxNUZ?=
 =?us-ascii?Q?x/Ct6mSmq/rGmRvT0RVPmVK7MLmrrUktuTMAJSUnpPRTc7eN50KfaFv/CMwD?=
 =?us-ascii?Q?OYVmjabWsn3lkSGaqQrBR8mlHKQoCTN2XQx+hJoSbUIr+ry+aOZ20g9oV9LE?=
 =?us-ascii?Q?z4Vt3AvNe1c1RZyDhWmASnO+WkDVTh5+FUVBoJYsTP5F25gKanEgAg4QJ48O?=
 =?us-ascii?Q?xIMQS88NN7Fc3yqxrVqFcd0Vcr0aX0nuhJ4AV0zNVtWg3OoBvOu/uqTjjxDz?=
 =?us-ascii?Q?yqJHkXHEEaHxzdVnr3pmqTbIDeDHD1jDjzEm6CGWdLQRYKnExhhV25/wqLmI?=
 =?us-ascii?Q?ACeNcnG2/gHf3ajPJNF+SFK7rfk05BzF3TmD0Gye3pBPf8wvEMZzlEpUC7CZ?=
 =?us-ascii?Q?73Dtd97QR+KcgM3Kuo6W3m1lYJM6v1FQN5+Vvd/odzdkDRSLBa6O7WLeeo6y?=
 =?us-ascii?Q?FomNs3gugoFaAEl1o0J5Bb3cjCm/aQu6NUdIO+2y?=
X-OriginatorOrg: labundy.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 881277ad-7935-47fb-c43a-08db6b666f34
X-MS-Exchange-CrossTenant-AuthSource: SN4PR0801MB3774.namprd08.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jun 2023 16:59:50.1327
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 00b69d09-acab-4585-aca7-8fb7c6323e6f
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: nsMY/is8G3WjSODyEElbmp8hLOH5Yj1tHMGsc4utq8XueEy9Lx7+No5viPj88GgN+2nc7d5jquo2KKO/5lZwfg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR08MB6616
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,
        T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Neil,

[...]

> > > + * - PEN Events
> > 
> > What is "PEN"; is it "stylus" as written elsewhere?
> 
> Yes, they use both terms in the vendor driver.

I recommend using a common term throughout; as written, I first thought
"PEN" was an acronym.

[...]

> > > +	misc->fw_attr_len = le16_to_cpu(misc->fw_attr_len);
> > > +	misc->fw_log_len = le16_to_cpu(misc->fw_log_len);
> > > +	misc->stylus_struct_len = le16_to_cpu(misc->stylus_struct_len);
> > > +	misc->mutual_struct_len = le16_to_cpu(misc->mutual_struct_len);
> > > +	misc->self_struct_len = le16_to_cpu(misc->self_struct_len);
> > > +	misc->noise_struct_len = le16_to_cpu(misc->noise_struct_len);
> > > +	misc->touch_data_addr = le32_to_cpu(misc->touch_data_addr);
> > > +	misc->touch_data_head_len = le16_to_cpu(misc->touch_data_head_len);
> > > +	misc->point_struct_len = le16_to_cpu(misc->point_struct_len);
> > > +	misc->mutual_rawdata_addr = le32_to_cpu(misc->mutual_rawdata_addr);
> > > +	misc->mutual_diffdata_addr = le32_to_cpu(misc->mutual_diffdata_addr);
> > > +	misc->mutual_refdata_addr = le32_to_cpu(misc->mutual_refdata_addr);
> > > +	misc->self_rawdata_addr = le32_to_cpu(misc->self_rawdata_addr);
> > > +	misc->self_diffdata_addr = le32_to_cpu(misc->self_diffdata_addr);
> > > +	misc->self_refdata_addr = le32_to_cpu(misc->self_refdata_addr);
> > > +	misc->iq_rawdata_addr = le32_to_cpu(misc->iq_rawdata_addr);
> > > +	misc->iq_refdata_addr = le32_to_cpu(misc->iq_refdata_addr);
> > > +	misc->im_rawdata_addr = le32_to_cpu(misc->im_rawdata_addr);
> > > +	misc->im_readata_len = le16_to_cpu(misc->im_readata_len);
> > > +	misc->noise_rawdata_addr = le32_to_cpu(misc->noise_rawdata_addr);
> > > +	misc->noise_rawdata_len = le16_to_cpu(misc->noise_rawdata_len);
> > > +	misc->stylus_rawdata_addr = le32_to_cpu(misc->stylus_rawdata_addr);
> > > +	misc->stylus_rawdata_len = le16_to_cpu(misc->stylus_rawdata_len);
> > > +	misc->noise_data_addr = le32_to_cpu(misc->noise_data_addr);
> > > +	misc->esd_addr = le32_to_cpu(misc->esd_addr);
> > 
> > What is all of this stuff for? The beginning of the driver explicitly states
> > that ESD recovery is not supported; please consider stripping all of this if
> > its only purpose is to support noise in the logs or sysfs attributes that we
> > cannot reasonably react to.
> 
> Those are all the firmware parameters used by the driver, for now only a little
> are used, we already read the entire struct so stripping isn't an option otherwise
> the values will be shifted.
> 
> We only print those over debugfs se it won't fill any logs

I feel this is a lot of bloat to simply enable pretty printing of register
values. Some of these struct members aren't even used anywhere; others seem
to be related to functions this driver does not support. Do you realistically
expect one to read those values?

For registers that customers would in fact need to read for debugging, can
you not simply rely on regmap's natural debugfs facility? It seems you are
largely duplicating that here.

I understand that some parameters are used elsewhere and it may be efficient
to read the entire memory region as a packed struct, but there is no need to
unalign and store what is effectively padding in many cases.

[...]

Kind regards,
Jeff LaBundy