linux-kernel - Re: [PATCH V1] Input: synaptics-rmi4

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZqqIL6cmqT4ZrqBO@google.com>
Date: Wed, 31 Jul 2024 11:53:35 -0700
From: "dmitry.torokhov@...il.com" <dmitry.torokhov@...il.com>
To: Kevin Chu <kevin.chu@...synaptics.com>
Cc: "linux-input@...r.kernel.org" <linux-input@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Marge Yang <Marge.Yang@...synaptics.com>,
	Derek Cheng <derek.cheng@...synaptics.com>,
	David Chiu <David.Chiu@...synaptics.com>,
	Vincent Huang <Vincent.huang@...synaptics.com>,
	Sam Tsai <Sam.Tsai@...aptics.com>,
	Vincent Tang <Vincent.Tang@...aptics.com>
Subject: Re: [PATCH V1] Input: synaptics-rmi4 - Supports to query DPM value.

Hi Kevin,

On Wed, Jul 31, 2024 at 09:17:56AM +0000, Kevin Chu wrote:
> Hi Dmitry and the Linux Input/Kernel Team,
>   
>   I hope this email finds you well. I'm reaching out regarding our
>   kernel code that has been awaiting review for over a quarter now.
> 
>   Given the extended period without review, it's likely that some gaps
>   or inconsistencies have developed in our code base. To ensure a
>   smooth and productive review process, we'd like to address any
>   potential issues proactively.
>   
>   Could you please provide some guidance or hints on areas we should
>   focus on before submitting for formal review? Your expertise would
>   be invaluable in helping us prepare effectively.
> 

There was nothing wrong with patch submission. If you see something
stuck please do not hesitate poking me.

A couple of questions about the patch below though:

> Thanks
> Kevin
> 
> -----Original Message-----
> From: Marge Yang <marge.yang@...synaptics.com> 
> Sent: Wednesday, March 20, 2024 7:11 PM
> To: dmitry.torokhov@...il.com; linux-input@...r.kernel.org; linux-kernel@...r.kernel.org; Marge Yang <Marge.Yang@...synaptics.com>
> Cc: David Chiu <David.Chiu@...synaptics.com>; Derek Cheng <derek.cheng@...synaptics.com>; Sam Tsai <Sam.Tsai@...aptics.com>; Vincent Huang <Vincent.huang@...synaptics.com>; Vincent Huang <Vincent.huang@...synaptics.com>
> Subject: [PATCH V1] Input: synaptics-rmi4 - Supports to query DPM value.
> 
> RMI4 F12 will support to query DPM value on Touchpad.
> When TP firmware doesn't support to report logical and physical value within the Touchpad's HID report, We can directly query the DPM value through RMI.

It seems to me the logic is inverted, if there is resolution register
the new code will query it directly, otherwise it will try to get it
from the subpacket data. Is it intentional? Or did I parse it
incorrectly?

This also does not appear to be tied to the HID transport but rather
generic RMI4 code. Did I miss the connection?

> 
> Signed-off-by: Marge Yang <marge.yang@...synaptics.com>
> Signed-off-by: Vincent Huang <Vincent.Huang@...synaptics.com>
> ---
>  drivers/input/rmi4/rmi_f12.c | 41 +++++++++++++++++++++++++++++++----------
>  1 file changed, 31 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/input/rmi4/rmi_f12.c b/drivers/input/rmi4/rmi_f12.c index 7e97944..6a7a17d 100644
> --- a/drivers/input/rmi4/rmi_f12.c
> +++ b/drivers/input/rmi4/rmi_f12.c
> @@ -24,6 +24,7 @@ enum rmi_f12_object_type {  };
>  
>  #define F12_DATA1_BYTES_PER_OBJ			8
> +#define RMI_QUERY_DPM_IN_PRESENSE_BIT          29

Why "BIT"? Should it be called RMI_F12_RESOLUTION_REG or similar?

>  
>  struct f12_data {
>  	struct rmi_2d_sensor sensor;
> @@ -73,6 +74,8 @@ static int rmi_f12_read_sensor_tuning(struct f12_data *f12)
>  	int pitch_y = 0;
>  	int rx_receivers = 0;
>  	int tx_receivers = 0;
> +	u16 query_dpm_addr = 0;
> +	int dpm_resolution = 0;
>  
>  	item = rmi_get_register_desc_item(&f12->control_reg_desc, 8);
>  	if (!item) {
> @@ -122,18 +125,36 @@ static int rmi_f12_read_sensor_tuning(struct f12_data *f12)
>  		offset += 4;
>  	}
>  
> -	if (rmi_register_desc_has_subpacket(item, 3)) {
> -		rx_receivers = buf[offset];
> -		tx_receivers = buf[offset + 1];
> -		offset += 2;
> -	}
> +	// Only supports to query DPM value on RMI F12.

I am unsure what this comment means... We are in F12 code, so what does
"only" mean here?

> +	item = rmi_get_register_desc_item(&f12->query_reg_desc, RMI_QUERY_DPM_IN_PRESENSE_BIT);
> +	if (item) {
> +		offset = rmi_register_desc_calc_reg_offset(&f12->query_reg_desc,
> +			RMI_QUERY_DPM_IN_PRESENSE_BIT);
> +		query_dpm_addr = fn->fd.query_base_addr	+ offset;
> +		ret = rmi_read(fn->rmi_dev, query_dpm_addr, buf);
> +		if (ret < 0) {
> +			dev_err(&fn->dev, "Failed to read DPM value: %d\n", ret);
> +			return -ENODEV;
> +		}
> +		dpm_resolution = buf[0];
> +
> +		sensor->x_mm = sensor->max_x / dpm_resolution;
> +		sensor->y_mm = sensor->max_y / dpm_resolution;
> +	} else {
> +		if (rmi_register_desc_has_subpacket(item, 3)) {
> +			rx_receivers = buf[offset];
> +			tx_receivers = buf[offset + 1];
> +			offset += 2;
> +		}
>  
> -	/* Skip over sensor flags */
> -	if (rmi_register_desc_has_subpacket(item, 4))
> -		offset += 1;
> +		/* Skip over sensor flags */
> +		if (rmi_register_desc_has_subpacket(item, 4))
> +			offset += 1;
> +
> +		sensor->x_mm = (pitch_x * rx_receivers) >> 12;
> +		sensor->y_mm = (pitch_y * tx_receivers) >> 12;
> +	}
>  
> -	sensor->x_mm = (pitch_x * rx_receivers) >> 12;
> -	sensor->y_mm = (pitch_y * tx_receivers) >> 12;
>  
>  	rmi_dbg(RMI_DEBUG_FN, &fn->dev, "%s: x_mm: %d y_mm: %d\n", __func__,
>  		sensor->x_mm, sensor->y_mm);
> --
> 2.7.4
> 

Thanks.

-- 
Dmitry