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
