linux-kernel - Re: [PATCH] Input: pixcir_i2c_ts - add support for one-time total calibration

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] [day] [month] [year] [list]

Message-ID: <0e5eb4c0-bc63-4ca7-9ba2-985afa237d67@ysoft.com>
Date: Wed, 19 Nov 2025 11:23:35 +0100
From: Michal Vokáč <michal.vokac@...ft.com>
To: Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc: linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
 Fabio Estevam <festevam@...il.com>
Subject: Re: [PATCH] Input: pixcir_i2c_ts - add support for one-time total
 calibration

Hi Dmitry,

On 18. 11. 25 20:26, Dmitry Torokhov wrote:
> Hi Michal,
> 
> On Wed, Nov 12, 2025 at 02:00:19PM +0100, Michal Vokáč wrote:
>> The Pixcir Tango controller has support for a one-time total calibration
>> (manual calibration) procedure. Its purpose is to measure the capacitance
>> offsets of the electrode system and to store these values into EEPROM.
>>
>> During normal operation this calibration data is subtracted from the values
>> measured. This calibration should be necessary only once in the product
>> lifetime. It should be performed as part of the final adjustment after
>> the panel is mounted in the product.
>>
>> Add support for the calibration with sysfs interface.
>>
>> Signed-off-by: Michal Vokáč <michal.vokac@...ft.com>
>> ---
>>   drivers/input/touchscreen/pixcir_i2c_ts.c | 34 +++++++++++++++++++++++
>>   1 file changed, 34 insertions(+)
>>
>> diff --git a/drivers/input/touchscreen/pixcir_i2c_ts.c b/drivers/input/touchscreen/pixcir_i2c_ts.c
>> index dad5786e82a4..2215e56b1458 100644
>> --- a/drivers/input/touchscreen/pixcir_i2c_ts.c
>> +++ b/drivers/input/touchscreen/pixcir_i2c_ts.c
>> @@ -24,6 +24,7 @@
>>    */
>>   #define PIXCIR_REG_POWER_MODE	51
>>   #define PIXCIR_REG_INT_MODE	52
>> +#define PIXCIR_REG_SPECOP	58
>>   
>>   /*
>>    * Power modes:
>> @@ -82,6 +83,7 @@ struct pixcir_i2c_ts_data {
>>   	const struct pixcir_i2c_chip_data *chip;
>>   	struct touchscreen_properties prop;
>>   	bool running;
>> +	struct mutex sysfs_mutex;
>>   };
>>   
>>   struct pixcir_report_data {
>> @@ -462,6 +464,35 @@ static int pixcir_i2c_ts_resume(struct device *dev)
>>   static DEFINE_SIMPLE_DEV_PM_OPS(pixcir_dev_pm_ops,
>>   				pixcir_i2c_ts_suspend, pixcir_i2c_ts_resume);
>>   
>> +static ssize_t calibrate_store(struct device *dev,
>> +			       struct device_attribute *attr,
>> +			       const char *buf, size_t count)
>> +{
>> +	struct i2c_client *client = to_i2c_client(dev);
>> +	struct pixcir_i2c_ts_data *ts = i2c_get_clientdata(client);
>> +	static const u8 cmd = 0x03;
>> +	int error;
>> +
>> +	error = mutex_lock_interruptible(&ts->sysfs_mutex);
>> +	if (error)
>> +		return error;
> 
> Why do we need this mutex? i2c_smbus_write_byte_data() does take adapter
> lock, why do we need this additional locking?

Honestly I was not sure about usefulness of the lock.
I originally have not it there when the patch was in our downstream tree.
When I was rewriting it for mainline I realized there are other touchscreen
drivers that already have this calibration feature implemented and that
they have the lock in place. See raydium_i2c_ts.c or elants_i2c.c.
So I got inspired and used it as well for the case I missed something.

Now after a second look at the mentioned drivers I see that these also
have a sysfs interface for FW update. So it make sense to use the lock
to assure the whole fw transfer is finished before someone else can
access the device.

That is not our case. The mutex can safely be removed. I will send v2.

Thank you,
Michal