ibm-acpi-devel — ibm-acpi Linux driver development

Re: [ibm-acpi-devel] [PATCH v3 1/3] input: mouse: trackpoint: Add doubletap enable/disable support

[Dmitry T. <dmi...@gm...>]

On Thu, Sep 18, 2025 at 09:31:47AM +0200, Hans de Goede wrote:
> Hi Vishnu,
> 
> On 18-Sep-25 4:37 AM, Vishnu Sankar wrote:
> > Hello all,
> > 
> > Do we have any questions or concerns?
> > Thanks in advance!
> > 
> > On Mon, Sep 1, 2025 at 10:53 PM Vishnu Sankar <vis...@gm...> wrote:
> >>
> >> Add support for enabling and disabling doubletap on TrackPoint devices
> >> that support this functionality. The feature is detected using firmware
> >> ID and exposed via sysfs as `doubletap_enabled`.
> 
> Hmm, you seem to be using a firmware ID prefix match, combined with
> a deny list of some firmware IDs with that prefix which do not support
> this. How do we know this deny list is complete?
> 
> Also as Dmitry says you really should use the is_visible() callback
> to not show the attribute at all on unsupported systems.
> 
> >> The feature is only available on newer ThinkPads (2023 and later).The driver
> >> exposes this capability via a new sysfs attribute:
> >> "/sys/bus/serio/devices/seriox/doubletap_enabled".
> >>
> >> The attribute is only created if the device is detected to be capable of
> >> doubletap via firmware and variant ID checks. This functionality will be
> >> used by platform drivers such as thinkpad_acpi to expose and control doubletap
> >> via user interfaces.
> 
> Hmm, you refer to thinkpad_acpi as a possible consumer of this
> functionality. But you only add a sysfs interface.
> 
> thinkpad_acpi will need some in kernel interface to use this.
> 
> Which brings me to my main question: thinkpad_acpi is the driver
> receiving the doubletap events since these are send out-of-bound
> and not through the ps/2 trackpoint protocol.
> 
> thinkpad_acpi already has the capability to filter out these doubletap
> events and report nothing. Why is it necessary / better to disable
> the doubletap at the trackpoint fw-level, rather then just filtering
> it at the thinkpad_acpi level ?
> 
> I don't really see a big advantage in filtering these events at
> the fw-level rather then in the kernel and we already have the
> in kernel filtering.

That is an excellent observation, thank you Hans. The frequency of these
events should be extremely low, so cost of simply ignoring events should
be miniscule...

Thanks.

-- 
Dmitry

Re: [ibm-acpi-devel] [PATCH v3 1/3] input: mouse: trackpoint: Add doubletap enable/disable support

[Dmitry T. <dmi...@gm...>]

Hi Vishnu,

On Mon, Sep 01, 2025 at 10:53:05PM +0900, Vishnu Sankar wrote:
> Add support for enabling and disabling doubletap on TrackPoint devices
> that support this functionality. The feature is detected using firmware
> ID and exposed via sysfs as `doubletap_enabled`.
> 
> The feature is only available on newer ThinkPads (2023 and later).The driver
> exposes this capability via a new sysfs attribute:
> "/sys/bus/serio/devices/seriox/doubletap_enabled".
> 
> The attribute is only created if the device is detected to be capable of
> doubletap via firmware and variant ID checks. This functionality will be
> used by platform drivers such as thinkpad_acpi to expose and control doubletap
> via user interfaces.
> 
> Signed-off-by: Vishnu Sankar <vis...@gm...>
> Suggested-by: Mark Pearson <mpe...@sq...>
> Suggested-by: Dmitry Torokhov <dmi...@gm...>
> ---
> Changes in v2:
> - Improve commit messages
> - Sysfs attributes moved to trackpoint.c
> - Removed unnecessary comments
> - Removed unnecessary debug messages
> - Using strstarts() instead of strcmp()
> - is_trackpoint_dt_capable() modified
> - Removed _BIT suffix and used BIT() define.
> - Reverse the trackpoint_doubletap_status() logic to return error first.
> - Removed export functions as a result of the design change
> - Changed trackpoint_dev->psmouse to parent_psmouse
> - The path of trackpoint.h is not changed.
> Changes in v3:
> - No changes.
> ---
>  drivers/input/mouse/trackpoint.c | 149 +++++++++++++++++++++++++++++++
>  drivers/input/mouse/trackpoint.h |  15 ++++
>  2 files changed, 164 insertions(+)
> 
> diff --git a/drivers/input/mouse/trackpoint.c b/drivers/input/mouse/trackpoint.c
> index 5f6643b69a2c..c6f17b0dec3a 100644
> --- a/drivers/input/mouse/trackpoint.c
> +++ b/drivers/input/mouse/trackpoint.c
> @@ -16,6 +16,8 @@
>  #include "psmouse.h"
>  #include "trackpoint.h"
>  
> +static struct trackpoint_data *trackpoint_dev;

Please do not use globals.

> +
>  static const char * const trackpoint_variants[] = {
>  	[TP_VARIANT_IBM]		= "IBM",
>  	[TP_VARIANT_ALPS]		= "ALPS",
> @@ -63,6 +65,21 @@ static int trackpoint_write(struct ps2dev *ps2dev, u8 loc, u8 val)
>  	return ps2_command(ps2dev, param, MAKE_PS2_CMD(3, 0, TP_COMMAND));
>  }
>  
> +/* Read function for TrackPoint extended registers */
> +static int trackpoint_extended_read(struct ps2dev *ps2dev, u8 loc, u8 *val)
> +{
> +	u8 ext_param[2] = {TP_READ_MEM, loc};
> +	int error;
> +
> +	error = ps2_command(ps2dev,
> +			    ext_param, MAKE_PS2_CMD(2, 1, TP_COMMAND));
> +
> +	if (!error)
> +		*val = ext_param[0];
> +
> +	return error;
> +}
> +
>  static int trackpoint_toggle_bit(struct ps2dev *ps2dev, u8 loc, u8 mask)
>  {
>  	u8 param[3] = { TP_TOGGLE, loc, mask };
> @@ -393,6 +410,131 @@ static int trackpoint_reconnect(struct psmouse *psmouse)
>  	return 0;
>  }
>  
> +/* List of known incapable device PNP IDs */
> +static const char * const dt_incompatible_devices[] = {
> +	"LEN0304",
> +	"LEN0306",
> +	"LEN0317",
> +	"LEN031A",
> +	"LEN031B",
> +	"LEN031C",
> +	"LEN031D",
> +};
> +
> +/*
> + * checks if it’s a doubletap capable device
> + * The PNP ID format eg: is "PNP: LEN030d PNP0f13".
> + */
> +static bool is_trackpoint_dt_capable(const char *pnp_id)
> +{
> +	const char *id_start;
> +	char id[8];
> +
> +	if (!strstarts(pnp_id, "PNP: LEN03"))
> +		return false;
> +
> +	/* Points to "LEN03xxxx" */
> +	id_start = pnp_id + 5;
> +	if (sscanf(id_start, "%7s", id) != 1)
> +		return false;
> +
> +	/* Check if it's blacklisted */
> +	for (size_t i = 0; i < ARRAY_SIZE(dt_incompatible_devices); ++i) {
> +		if (strcmp(id, dt_incompatible_devices[i]) == 0)
> +			return false;
> +	}
> +	return true;
> +}
> +
> +/* Trackpoint doubletap status function */
> +static int trackpoint_doubletap_status(bool *status)
> +{
> +	struct trackpoint_data *tp = trackpoint_dev;
> +	struct ps2dev *ps2dev = &tp->parent_psmouse->ps2dev;
> +	u8 reg_val;
> +	int rc;
> +
> +	/* Reading the Doubletap register using extended read */
> +	rc = trackpoint_extended_read(ps2dev, TP_DOUBLETAP, &reg_val);
> +	if (rc)
> +		return rc;
> +
> +	*status = reg_val & TP_DOUBLETAP_STATUS ? true : false;
> +
> +	return 0;
> +}
> +
> +/* Trackpoint doubletap enable/disable function */
> +static int trackpoint_set_doubletap(bool enable)
> +{
> +	struct trackpoint_data *tp = trackpoint_dev;
> +	struct ps2dev *ps2dev = &tp->parent_psmouse->ps2dev;
> +	static u8 doubletap_state;
> +	u8 new_val;
> +
> +	if (!tp)
> +		return -ENODEV;
> +
> +	new_val = enable ? TP_DOUBLETAP_ENABLE : TP_DOUBLETAP_DISABLE;
> +
> +	if (doubletap_state == new_val)
> +		return 0;
> +
> +	doubletap_state = new_val;
> +
> +	return trackpoint_write(ps2dev, TP_DOUBLETAP, new_val);
> +}
> +
> +/*
> + * Trackpoint Doubletap Interface
> + * Control/Monitoring of Trackpoint Doubletap from:
> + * /sys/bus/serio/devices/seriox/doubletap_enabled
> + */
> +static ssize_t doubletap_enabled_show(struct device *dev,
> +				struct device_attribute *attr, char *buf)
> +{
> +	struct serio *serio = to_serio_port(dev);
> +	struct psmouse *psmouse = psmouse_from_serio(serio);
> +	struct trackpoint_data *tp = psmouse->private;
> +	bool status;
> +	int rc;
> +
> +	if (!tp || !tp->doubletap_capable)
> +		return -ENODEV;
> +
> +	rc = trackpoint_doubletap_status(&status);
> +	if (rc)
> +		return rc;
> +
> +	return sysfs_emit(buf, "%d\n", status ? 1 : 0);
> +}
> +
> +static ssize_t doubletap_enabled_store(struct device *dev,
> +					struct device_attribute *attr,
> +					const char *buf, size_t count)
> +{
> +	struct serio *serio = to_serio_port(dev);
> +	struct psmouse *psmouse = psmouse_from_serio(serio);
> +	struct trackpoint_data *tp = psmouse->private;
> +	bool enable;
> +	int err;
> +
> +	if (!tp || !tp->doubletap_capable)
> +		return -ENODEV;
> +
> +	err = kstrtobool(buf, &enable);
> +	if (err)
> +		return err;
> +
> +	err = trackpoint_set_doubletap(enable);
> +	if (err)
> +		return err;
> +
> +	return count;
> +}
> +
> +static DEVICE_ATTR_RW(doubletap_enabled);
> +
>  int trackpoint_detect(struct psmouse *psmouse, bool set_properties)
>  {
>  	struct ps2dev *ps2dev = &psmouse->ps2dev;
> @@ -425,6 +567,9 @@ int trackpoint_detect(struct psmouse *psmouse, bool set_properties)
>  	psmouse->reconnect = trackpoint_reconnect;
>  	psmouse->disconnect = trackpoint_disconnect;
>  
> +	trackpoint_dev = psmouse->private;
> +	trackpoint_dev->parent_psmouse = psmouse;
> +
>  	if (variant_id != TP_VARIANT_IBM) {
>  		/* Newer variants do not support extended button query. */
>  		button_info = 0x33;
> @@ -470,6 +615,10 @@ int trackpoint_detect(struct psmouse *psmouse, bool set_properties)
>  		     psmouse->vendor, firmware_id,
>  		     (button_info & 0xf0) >> 4, button_info & 0x0f);
>  
> +	tp->doubletap_capable = is_trackpoint_dt_capable(ps2dev->serio->firmware_id);
> +	if (tp->doubletap_capable)
> +		device_create_file(&psmouse->ps2dev.serio->dev, &dev_attr_doubletap_enabled);

Please use existing facilities in psmouse driver to define and register
protocol-specific attributes. Use is_visible() to control whether the
attribute is accessible or not.

Thanks.

-- 
Dmitry

Re: [ibm-acpi-devel] [RFC PATCH v1] platform/x86: thinkpad_acpi: Add parameter to suppress invalid thermal sensors

[Mark P. <mpe...@sq...>]

Hi,

On Fri, Aug 22, 2025, at 7:54 AM, Armin Wolf wrote:
> Am 21.08.25 um 19:32 schrieb Marc Burkhardt:
>
>> Am 2025-08-20 00:03, schrieb Mark Pearson:
>>
>> Hi Mark,
>>
>> thanks for replying.
>>
>>> Hi Marc,
>>>
>>> On Mon, Aug 18, 2025, at 4:39 PM, Marc Burkhardt wrote:
>>>> While moving an existing Icinga installation to a Lenovo P15 20SU I 
>>>> came
>>>> across broken JSON output from a "sensors -Aj" command consumed by the
>>>> Icinga check_lm_sensors plugin. After fiddling around trying to build a
>>>> fix in either lm_sensors or Icinga I found out the error was rooted in
>>>> some sysfs file that was created but threw errors while being read. 
>>>> On my
>>>> Lenovo ThinkPad the default fallback to 8 temperature sensors creates
>>>> sysfs entries like in my case "temp8_input" that fail when read, 
>>>> causing
>>>> the issue in user-space.
>>>>
>>>> This patch adds a module parameter (suppress_sensor) using
>>>> module_param_array() to allow users to specify a comma-separated 
>>>> list of
>>>> zero-based sensor indices to suppress sysfs file creation (e.g.
>>>> suppress_sensor=3,7). Instead of a model-specific quirk, this provides
>>>> flexible configuration for any ThinkPad with similar issues and is 
>>>> working
>>>> out-of-the-box without additional models being marked for the quirk. 
>>>> The
>>>> parameter uses a fixed-size array based on 
>>>> TPACPI_MAX_THERMAL_SENSORS (16)
>>>> consistent with the driver’s thermal sensor handling (ie.
>>>> ibm_thermal_sensors_struct or sensor_dev_attr_thermal_temp_input).
>>>>
>>>> Logging via pr_info() reports the number of suppressed sensors at 
>>>> module
>>>> initialization, and pr_info() logs each suppressed sensor during sysfs
>>>> attribute creation. Invalid sensor indices are logged once via 
>>>> pr_warn()
>>>> to avoid repetitive warnings. Tested on a ThinkPad P15 with
>>>> suppress_sensor=3,7, confirming suppression of temp4_input and 
>>>> temp8_input
>>>> with no sysfs errors. Bounds checking for uncommon values is in 
>>>> place or
>>>> will be logged.
>>>>
>>>> The patch applies to the current
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
>>>> although
>>>> it was initially written for a 6.16.0 kernel.
>>>>
>>>> I look forward to any feedback on the patch and/or handling of 
>>>> submission.
>>>> Please CC: for now as I am not (yet) subscribed. Thank you.
>>>>
>>>> Signed-off-by: Marc Burkhardt <mar...@pr...>
>>>> ---
>>>> Notes:
>>>> I haven't posted on LKML or send a patch for over a decade now so
>>>> please forgive any possible mistakes I made regarding current coding
>>>> conventions or more generally in submitting this patch. The patch was
>>>> running for some time here with faulty sensors removed from sysfs 
>>>> and no
>>>> problems otherwise detected and was surely run through checkpatch.pl 
>>>> before
>>>> submission. get_maintainer.pl was helpful to find the hopefully right
>>>> people for CC:ing but I am otherweise totally unaware of any current
>>>> procedures or best-practices when it comes to submitting a patch.
>>>>
>>>> drivers/platform/x86/lenovo/thinkpad_acpi.c | 35 
>>>> +++++++++++++++++++++++++++++
>>>>  1 file changed, 35 insertions(+)
>>>>
>>>> diff --git a/drivers/platform/x86/lenovo/thinkpad_acpi.c
>>>> b/drivers/platform/x86/lenovo/thinkpad_acpi.c
>>>> index cc19fe520ea9..30ff01f87403 100644
>>>> --- a/drivers/platform/x86/lenovo/thinkpad_acpi.c
>>>> +++ b/drivers/platform/x86/lenovo/thinkpad_acpi.c
>>>> @@ -6019,6 +6019,30 @@ struct ibm_thermal_sensors_struct {
>>>>      s32 temp[TPACPI_MAX_THERMAL_SENSORS];
>>>>  };
>>>>
>>>> +static int suppress_sensor[TPACPI_MAX_THERMAL_SENSORS];
>>>> +static unsigned int suppress_sensor_count;
>>>> +
>>>> +static bool is_sensor_suppressed(int index)
>>>> +{
>>>> +    unsigned int i;
>>>> +    bool logged = false;
>>>> +
>>>> +    for (i = 0; i < suppress_sensor_count; i++) {
>>>> +        if (suppress_sensor[i] == index)
>>>> +            return true;
>>>> +
>>>> +        if (!logged &&
>>>> +            (suppress_sensor[i] < 0
>>>> +                || suppress_sensor[i] >= 
>>>> TPACPI_MAX_THERMAL_SENSORS)) {
>>>> +            pr_warn("Invalid sensor index %d in suppress_sensor\n",
>>>> +                suppress_sensor[i]);
>>>> +            logged = true;
>>>> +        }
>>>> +    }
>>>> +
>>>> +    return false;
>>>> +}
>>>> +
>>>>  static const struct tpacpi_quirk thermal_quirk_table[] __initconst = {
>>>>      /* Non-standard address for thermal registers on some ThinkPads */
>>>>      TPACPI_Q_LNV3('R', '1', 'F', true),    /* L13 Yoga Gen 2 */
>>>> @@ -6313,6 +6337,11 @@ static umode_t thermal_attr_is_visible(struct
>>>> kobject *kobj,
>>>>
>>>>      int idx = sensor_attr->index;
>>>>
>>>> +    if (is_sensor_suppressed(idx)) {
>>>> +        pr_info("Sensor %d suppressed\n", idx);
>>>> +        return 0;
>>>> +    }
>>>> +
>>>>      switch (thermal_read_mode) {
>>>>      case TPACPI_THERMAL_NONE:
>>>>          return 0;
>>>> @@ -11653,6 +11682,9 @@ static void __init
>>>> thinkpad_acpi_init_banner(void)
>>>>              thinkpad_id.model_str,
>>>>              (thinkpad_id.nummodel_str) ?
>>>>                  thinkpad_id.nummodel_str : "unknown");
>>>> +
>>>> +    pr_info("Suppressing %d user-supplied sensor(s) via parameter
>>>> suppress_sensor\n",
>>>> +        suppress_sensor_count);
>>>>  }
>>>>
>>>>  /* Module init, exit, parameters */
>>>> @@ -11785,6 +11817,9 @@ MODULE_PARM_DESC(experimental,
>>>>  module_param_named(debug, dbg_level, uint, 0);
>>>>  MODULE_PARM_DESC(debug, "Sets debug level bit-mask");
>>>>
>>>> +module_param_array(suppress_sensor, int, &suppress_sensor_count, 
>>>> 0444);
>>>> +MODULE_PARM_DESC(suppress_sensor, "Comma-separated sensor indices to
>>>> suppress (e.g., 3,7)");
>>>> +
>>>>  module_param(force_load, bool, 0444);
>>>>  MODULE_PARM_DESC(force_load,
>>>>           "Attempts to load the driver even on a mis-identified 
>>>> ThinkPad when
>>>> true");
>>>
>>> The P15 is one of the Linux certified platforms...though it's a bit 
>>> older now.
>>>
>>> I'd be more interested in figuring out which sensors are returning an 
>>> error and figuring out how we address that. I have access to the FW 
>>> and platform team for questions (though this platform is a bit older 
>>> now, so if we need FW fixes that will be trickier). My gut feeling is 
>>> we shouldn't be creating sysfs entries if the sensors don't exist or 
>>> aren't accessible.
>>
>> That is what my patch does - it prevents creating the sysfs entries 
>> but not based on a check for validity of the sensor in code (as 
>> probably desired by Ilpo when I understand a previous mail correctly) 
>> but rather on a user-provided configuration via the new parameter. I 
>> reply to the other mail as well soon.
>>
> Such sensors are meant to be ignored using /etc/sensors3.conf (provided 
> by libsensors) unless the driver itself can
> automatically determine this by asking the platform firmware. I suggest 
> that you use this mechanism instead of adding
> additional module parameters.
>
> Thanks,
> Armin Wolf
>
> (I also CCed the hwmon mailing list as libsensors originally came from there)
>
>>>
>>> I do have a P15 so can check it out (I'm going to have to blow some 
>>> dust off it). If you've got the details on which sensors need 
>>> suppressing that would be useful. I have seen previously where it's 
>>> trying to access a GPU sensor on a UMA model.
>>
>> On my hardware it's sensor temp8_input which is unreadable at all und 
>> sensor temp4_input that has a constant value of 0, no matter how hot, 
>> cold or loud the machine is running. I am, however, able to monitor 
>> GPU temps via nvidia _and_ thinkpad ACPI. The values are mostly equal, 
>> differ a bit due to internal timing sometimes.
>>
>>>

I tried this on my P15, and I do get an error when the GPU sensor is accessed as it's not available (no Nvidia card on mine).

A suggestion (based a bit on Armin's suggestions): If the is_visible function is changed so if the sensor returns an error (or not available) then the sysfs entry isn't displayed. 
I think that would prevent errors/access issues from user space - at least it worked on my system.

Something like the below (I can send this up as a proper patch if it makes sense)

diff --git a/drivers/platform/x86/lenovo/thinkpad_acpi.c b/drivers/platform/x86/lenovo/thinkpad_acpi.c
index cc19fe520ea9..075d15df183c 100644
--- a/drivers/platform/x86/lenovo/thinkpad_acpi.c
+++ b/drivers/platform/x86/lenovo/thinkpad_acpi.c
@@ -6312,6 +6312,8 @@ static umode_t thermal_attr_is_visible(struct kobject *kobj,
                                        to_sensor_dev_attr(dev_attr);
 
        int idx = sensor_attr->index;
+       s32 value;
+       int res;
 
        switch (thermal_read_mode) {
        case TPACPI_THERMAL_NONE:
@@ -6334,6 +6336,11 @@ static umode_t thermal_attr_is_visible(struct kobject *kobj,
 
        }
 
+       /* Check if sensor is available */
+       res = thermal_get_sensor(idx, &value);
+       if ((res) || (value == TPACPI_THERMAL_SENSOR_NA))
+               return 0;
+
        return attr->mode;
 }

I think this would generally be useful for removing unwanted sensors without having to do extra steps?

Mark

Re: [ibm-acpi-devel] [RFC PATCH v1] platform/x86: thinkpad_acpi: Add parameter to suppress invalid thermal sensors

[Mark P. <mpe...@sq...>]

Hi Marc,

On Mon, Aug 18, 2025, at 4:39 PM, Marc Burkhardt wrote:
> While moving an existing Icinga installation to a Lenovo P15 20SU I came
> across broken JSON output from a "sensors -Aj" command consumed by the
> Icinga check_lm_sensors plugin. After fiddling around trying to build a
> fix in either lm_sensors or Icinga I found out the error was rooted in
> some sysfs file that was created but threw errors while being read. On my
> Lenovo ThinkPad the default fallback to 8 temperature sensors creates
> sysfs entries like in my case "temp8_input" that fail when read, causing
> the issue in user-space.
>
> This patch adds a module parameter (suppress_sensor) using
> module_param_array() to allow users to specify a comma-separated list of
> zero-based sensor indices to suppress sysfs file creation (e.g.
> suppress_sensor=3,7). Instead of a model-specific quirk, this provides
> flexible configuration for any ThinkPad with similar issues and is working
> out-of-the-box without additional models being marked for the quirk. The
> parameter uses a fixed-size array based on TPACPI_MAX_THERMAL_SENSORS (16)
> consistent with the driver’s thermal sensor handling (ie.
> ibm_thermal_sensors_struct or sensor_dev_attr_thermal_temp_input).
>
> Logging via pr_info() reports the number of suppressed sensors at module
> initialization, and pr_info() logs each suppressed sensor during sysfs
> attribute creation. Invalid sensor indices are logged once via pr_warn()
> to avoid repetitive warnings. Tested on a ThinkPad P15 with
> suppress_sensor=3,7, confirming suppression of temp4_input and temp8_input
> with no sysfs errors. Bounds checking for uncommon values is in place or
> will be logged.
>
> The patch applies to the current
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git although
> it was initially written for a 6.16.0 kernel.
>
> I look forward to any feedback on the patch and/or handling of submission.
> Please CC: for now as I am not (yet) subscribed. Thank you.
>
> Signed-off-by: Marc Burkhardt <mar...@pr...>
> ---
> Notes:
> I haven't posted on LKML or send a patch for over a decade now so
> please forgive any possible mistakes I made regarding current coding
> conventions or more generally in submitting this patch. The patch was
> running for some time here with faulty sensors removed from sysfs and no
> problems otherwise detected and was surely run through checkpatch.pl before
> submission. get_maintainer.pl was helpful to find the hopefully right
> people for CC:ing but I am otherweise totally unaware of any current
> procedures or best-practices when it comes to submitting a patch.
>
> drivers/platform/x86/lenovo/thinkpad_acpi.c | 35 +++++++++++++++++++++++++++++
>  1 file changed, 35 insertions(+)
>
> diff --git a/drivers/platform/x86/lenovo/thinkpad_acpi.c 
> b/drivers/platform/x86/lenovo/thinkpad_acpi.c
> index cc19fe520ea9..30ff01f87403 100644
> --- a/drivers/platform/x86/lenovo/thinkpad_acpi.c
> +++ b/drivers/platform/x86/lenovo/thinkpad_acpi.c
> @@ -6019,6 +6019,30 @@ struct ibm_thermal_sensors_struct {
>  	s32 temp[TPACPI_MAX_THERMAL_SENSORS];
>  };
> 
> +static int suppress_sensor[TPACPI_MAX_THERMAL_SENSORS];
> +static unsigned int suppress_sensor_count;
> +
> +static bool is_sensor_suppressed(int index)
> +{
> +	unsigned int i;
> +	bool logged = false;
> +
> +	for (i = 0; i < suppress_sensor_count; i++) {
> +		if (suppress_sensor[i] == index)
> +			return true;
> +
> +		if (!logged &&
> +			(suppress_sensor[i] < 0
> +				|| suppress_sensor[i] >= TPACPI_MAX_THERMAL_SENSORS)) {
> +			pr_warn("Invalid sensor index %d in suppress_sensor\n",
> +				suppress_sensor[i]);
> +			logged = true;
> +		}
> +	}
> +
> +	return false;
> +}
> +
>  static const struct tpacpi_quirk thermal_quirk_table[] __initconst = {
>  	/* Non-standard address for thermal registers on some ThinkPads */
>  	TPACPI_Q_LNV3('R', '1', 'F', true),	/* L13 Yoga Gen 2 */
> @@ -6313,6 +6337,11 @@ static umode_t thermal_attr_is_visible(struct 
> kobject *kobj,
> 
>  	int idx = sensor_attr->index;
> 
> +	if (is_sensor_suppressed(idx)) {
> +		pr_info("Sensor %d suppressed\n", idx);
> +		return 0;
> +	}
> +
>  	switch (thermal_read_mode) {
>  	case TPACPI_THERMAL_NONE:
>  		return 0;
> @@ -11653,6 +11682,9 @@ static void __init 
> thinkpad_acpi_init_banner(void)
>  			thinkpad_id.model_str,
>  			(thinkpad_id.nummodel_str) ?
>  				thinkpad_id.nummodel_str : "unknown");
> +
> +	pr_info("Suppressing %d user-supplied sensor(s) via parameter 
> suppress_sensor\n",
> +		suppress_sensor_count);
>  }
> 
>  /* Module init, exit, parameters */
> @@ -11785,6 +11817,9 @@ MODULE_PARM_DESC(experimental,
>  module_param_named(debug, dbg_level, uint, 0);
>  MODULE_PARM_DESC(debug, "Sets debug level bit-mask");
> 
> +module_param_array(suppress_sensor, int, &suppress_sensor_count, 0444);
> +MODULE_PARM_DESC(suppress_sensor, "Comma-separated sensor indices to 
> suppress (e.g., 3,7)");
> +
>  module_param(force_load, bool, 0444);
>  MODULE_PARM_DESC(force_load,
>  		 "Attempts to load the driver even on a mis-identified ThinkPad when 
> true");

The P15 is one of the Linux certified platforms...though it's a bit older now.

I'd be more interested in figuring out which sensors are returning an error and figuring out how we address that. I have access to the FW and platform team for questions (though this platform is a bit older now, so if we need FW fixes that will be trickier). My gut feeling is we shouldn't be creating sysfs entries if the sensors don't exist or aren't accessible.

I do have a P15 so can check it out (I'm going to have to blow some dust off it). If you've got the details on which sensors need suppressing that would be useful. I have seen previously where it's trying to access a GPU sensor on a UMA model.

Mark

Re: [ibm-acpi-devel] ACPI EC access misbehaving

[Mark P. <mpe...@sq...>]

On Tue, Aug 5, 2025, at 7:58 PM, Damjan Georgievski wrote:
> hopefully last of my barrage of X9 issues
>
> I'm getting this in the kernel logs:
> kernel: thinkpad_acpi: ThinkPad ACPI EC access misbehaving, disabling
> thermal sensors access
>
> how concerned should I be about this?
>
> the system is the Thinkpad X9-14, or rather:
>
> ```
> kernel: DMI: LENOVO 21QA0048RM/21QA0048RM, BIOS N4DET30W (1.13 ) 04/02/2025
> ...
> kernel: ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored
> ...
> kernel: thinkpad_acpi: ThinkPad BIOS N4DET30W (1.13 ), EC N4DHT29W
> kernel: thinkpad_acpi: Lenovo ThinkPad X9-14 Gen 1, model 21QA0048RM
> ```
>
Yep - known issue and still under analysis by our FW team.

Mark

[ibm-acpi-devel] ACPI EC access misbehaving

[Damjan G. <gd...@gm...>]

hopefully last of my barrage of X9 issues

I'm getting this in the kernel logs:
kernel: thinkpad_acpi: ThinkPad ACPI EC access misbehaving, disabling
thermal sensors access

how concerned should I be about this?

the system is the Thinkpad X9-14, or rather:

```
kernel: DMI: LENOVO 21QA0048RM/21QA0048RM, BIOS N4DET30W (1.13 ) 04/02/2025
...
kernel: ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored
...
kernel: thinkpad_acpi: ThinkPad BIOS N4DET30W (1.13 ), EC N4DHT29W
kernel: thinkpad_acpi: Lenovo ThinkPad X9-14 Gen 1, model 21QA0048RM
```

-- 
damjan

Re: [ibm-acpi-devel] SND_HDA_GENERIC_LEDS/SND_CTL_LED dependency of config THINKPAD_ACPI

[Damjan G. <gd...@gm...>]

> I assume you're using your own config instead of a standard one from a distro? I checked with both Ubuntu and Fedora (that I have on my system currently) and they have this option enabled - but they also have Realtek (and others) enabled which would have pulled it in.

Indeed I'm using my own config, so to decrease compile times while I
experiment with kernels (can't make that d..n camera work good)

> I believe the X9-14 uses the Cirrus codec so my guess is we should be adding this to the Cirrus Kconfig. Let me just check with the Cirrus folk if they have any thoughts/concerns.

Ok, thanks for that. I was confused where it belongs.

> As a heads up - if you're using the X9-14 keep an eye on this proposed fix:
> https://lore.kernel.org/linux-input/202...@ca.../T/#t
> It fixes a rare kernel crash condition we've been seeing on suspend/resume

Oh, that ... I might have hit that, or rather, it might have hit me :D
thanks!!!


-- 
damjan

Re: [ibm-acpi-devel] SND_HDA_GENERIC_LEDS/SND_CTL_LED dependency of config THINKPAD_ACPI

[Mark P. <mpe...@sq...>]

Hi Damjan

On Tue, Aug 5, 2025, at 9:40 AM, Damjan Georgievski wrote:
> Hi all,
> I've been compiling recent torvalds/master and noticed I've lost the
> control of the *mute mic led* (on the Thinkpad X9-14).
>
> For context, the `snd-ctl-led` ("ALSA control interface to LED trigger
> code") allows the mic mute led to follow the muted state of the
> microphone capture mixer,
> and to select if you want the led on when the mic is muted or is capturing.
>
> Problem is, both SND_HDA_GENERIC_LEDS and SND_CTL_LED are not user
> selectable, and
>
> * SND_CTL_LED is selected/enabled by SND_HDA_GENERIC when
> SND_HDA_GENERIC_LEDS is enabled; and
> * SND_HDA_GENERIC_LEDS is only selected by 4 of the codecs in
> `sound/hda/codecs/`.
>
> Now none of those 4 codecs are required on *this* Thinkpad, so not
> sure what the proper solution should be.
>
> I did fix the issue *for me* by adding
> `select SND_HDA_GENERIC_LEDS if SND_HDA_GENERIC` to `config
> THINKPAD_ACPI` - but I'm not sure if that's the proper way forward.
>
I assume you're using your own config instead of a standard one from a distro? I checked with both Ubuntu and Fedora (that I have on my system currently) and they have this option enabled - but they also have Realtek (and others) enabled which would have pulled it in.

I believe the X9-14 uses the Cirrus codec so my guess is we should be adding this to the Cirrus Kconfig. Let me just check with the Cirrus folk if they have any thoughts/concerns.

As a heads up - if you're using the X9-14 keep an eye on this proposed fix:
https://lore.kernel.org/linux-input/202...@ca.../T/#t
It fixes a rare kernel crash condition we've been seeing on suspend/resume

Mark

[ibm-acpi-devel] SND_HDA_GENERIC_LEDS/SND_CTL_LED dependency of config THINKPAD_ACPI

[Damjan G. <gd...@gm...>]

Hi all,
I've been compiling recent torvalds/master and noticed I've lost the
control of the *mute mic led* (on the Thinkpad X9-14).

For context, the `snd-ctl-led` ("ALSA control interface to LED trigger
code") allows the mic mute led to follow the muted state of the
microphone capture mixer,
and to select if you want the led on when the mic is muted or is capturing.

Problem is, both SND_HDA_GENERIC_LEDS and SND_CTL_LED are not user
selectable, and

* SND_CTL_LED is selected/enabled by SND_HDA_GENERIC when
SND_HDA_GENERIC_LEDS is enabled; and
* SND_HDA_GENERIC_LEDS is only selected by 4 of the codecs in
`sound/hda/codecs/`.

Now none of those 4 codecs are required on *this* Thinkpad, so not
sure what the proper solution should be.

I did fix the issue *for me* by adding
`select SND_HDA_GENERIC_LEDS if SND_HDA_GENERIC` to `config
THINKPAD_ACPI` - but I'm not sure if that's the proper way forward.


--
damjan

Re: [ibm-acpi-devel] Support Q: copilot button on thinkpad x9-14

[Mark P. <mpe...@sq...>]

Hi

On Sat, Aug 2, 2025, at 4:16 PM, Damjan Georgievski wrote:
> Hi all,
> I have a user related question about the copilot button on recent
> laptops, but in particular the Thinkpad X9-14 (LunarLake)
>
> The Copilot button, which when pressed generates a LEFT META + LEFT
> SHIFT + F23 key combination on  the "AT Translated Set 2 keyboard".
> Is this something that can be overridden somehow? Ideally I'd like it
> to become a right ctrl. Not sure if that can be done in the kernel, in
> the BIOS or
> I should be looking at some user-space solution
>
That's the correct keycode for that button (as per Microsoft design) and there isn't anything in the BIOS/FW to change it I'm afraid (interesting idea though - I'll ask the FW team if it's something we can consider for future platforms because it would be nice)

It looks like some people have had success using keyd or kmonad to remap it:
https://superuser.com/questions/1849424/make-copilot-key-work-as-right-ctrl-again-under-linux
I haven't tried this myself.

Mark
>
> evtest reports this:
> Event: time 1754165237.366411, -------------- SYN_REPORT ------------
> Event: time 1754165238.892087, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
> Event: time 1754165238.892087, type 1 (EV_KEY), code 125 (KEY_LEFTMETA), value 1
> Event: time 1754165238.892087, -------------- SYN_REPORT ------------
> Event: time 1754165238.892984, type 4 (EV_MSC), code 4 (MSC_SCAN), value 2a
> Event: time 1754165238.892984, type 1 (EV_KEY), code 42 (KEY_LEFTSHIFT), value 1
> Event: time 1754165238.892984, -------------- SYN_REPORT ------------
> Event: time 1754165238.893919, type 4 (EV_MSC), code 4 (MSC_SCAN), value 6e
> Event: time 1754165238.893919, type 1 (EV_KEY), code 193 (KEY_F23), value 1
> Event: time 1754165238.893919, -------------- SYN_REPORT ------------
> Event: time 1754165238.927818, type 4 (EV_MSC), code 4 (MSC_SCAN), value 6e
> Event: time 1754165238.927818, type 1 (EV_KEY), code 193 (KEY_F23), value 0
> Event: time 1754165238.927818, -------------- SYN_REPORT ------------
> Event: time 1754165238.931839, type 4 (EV_MSC), code 4 (MSC_SCAN), value 2a
> Event: time 1754165238.931839, type 1 (EV_KEY), code 42 (KEY_LEFTSHIFT), value 0
> Event: time 1754165238.931839, -------------- SYN_REPORT ------------
> Event: time 1754165238.934798, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
> Event: time 1754165238.934798, type 1 (EV_KEY), code 125 (KEY_LEFTMETA), value 0
> Event: time 1754165238.934798, -------------- SYN_REPORT ------------
>
> -- 
> damjan
>
>
> _______________________________________________
> ibm-acpi-devel mailing list
> ibm...@li...
> https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

[ibm-acpi-devel] Support Q: copilot button on thinkpad x9-14

[Damjan G. <gd...@gm...>]

Hi all,
I have a user related question about the copilot button on recent
laptops, but in particular the Thinkpad X9-14 (LunarLake)

The Copilot button, which when pressed generates a LEFT META + LEFT
SHIFT + F23 key combination on  the "AT Translated Set 2 keyboard".
Is this something that can be overridden somehow? Ideally I'd like it
to become a right ctrl. Not sure if that can be done in the kernel, in
the BIOS or
I should be looking at some user-space solution


evtest reports this:
Event: time 1754165237.366411, -------------- SYN_REPORT ------------
Event: time 1754165238.892087, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
Event: time 1754165238.892087, type 1 (EV_KEY), code 125 (KEY_LEFTMETA), value 1
Event: time 1754165238.892087, -------------- SYN_REPORT ------------
Event: time 1754165238.892984, type 4 (EV_MSC), code 4 (MSC_SCAN), value 2a
Event: time 1754165238.892984, type 1 (EV_KEY), code 42 (KEY_LEFTSHIFT), value 1
Event: time 1754165238.892984, -------------- SYN_REPORT ------------
Event: time 1754165238.893919, type 4 (EV_MSC), code 4 (MSC_SCAN), value 6e
Event: time 1754165238.893919, type 1 (EV_KEY), code 193 (KEY_F23), value 1
Event: time 1754165238.893919, -------------- SYN_REPORT ------------
Event: time 1754165238.927818, type 4 (EV_MSC), code 4 (MSC_SCAN), value 6e
Event: time 1754165238.927818, type 1 (EV_KEY), code 193 (KEY_F23), value 0
Event: time 1754165238.927818, -------------- SYN_REPORT ------------
Event: time 1754165238.931839, type 4 (EV_MSC), code 4 (MSC_SCAN), value 2a
Event: time 1754165238.931839, type 1 (EV_KEY), code 42 (KEY_LEFTSHIFT), value 0
Event: time 1754165238.931839, -------------- SYN_REPORT ------------
Event: time 1754165238.934798, type 4 (EV_MSC), code 4 (MSC_SCAN), value db
Event: time 1754165238.934798, type 1 (EV_KEY), code 125 (KEY_LEFTMETA), value 0
Event: time 1754165238.934798, -------------- SYN_REPORT ------------

-- 
damjan

Re: [ibm-acpi-devel] [PATCH] x86/Mouse: thinkpad_acpi/Trackpoint: Trackpoint Doubletap handling

[Pavel M. <pa...@uc...>]

On Fri 2025-06-20 09:42:08, Vishnu Sankar wrote:
> Newer ThinkPads have a doubletap feature that needs to be turned
> ON/OFF via the trackpoint registers.
> Systems released from 2023 have doubletap disabled by default and
> need the feature enabling to be useful.
> 
> This patch introduces support for exposing and controlling the
> trackpoint doubletap feature via a sysfs attribute.
> /sys/devices/platform/thinkpad_acpi/tp_doubletap
> This can be toggled by an "enable" or a "disable".

sysfs attributes need documentation.
							Pavel
							
-- 
I don't work for Nazis and criminals, and neither should you.
Boycott Putin, Trump, and Musk!

Re: [ibm-acpi-devel] [External] Re: PrivacyGuard doesn't work even by sending ACPI commands directly

[Pellaeon L. <nfs...@gm...>]

Hi all,

I totally understand that you might have other priorities, but just
reminding you about this issue again in case you forget!

Thank you,
Pellaeon

Nitin Joshi1 <nj...@le...> 於 2025年6月20日 週五 下午4:20寫道：

> Thanks Pellaeon !
>
>
>
> Even I can reproduce it (using Ubuntu 24.04) but I can see it gets toggled
> correctly using below sysfs:
>
> cat /sys/class/drm/privacy_screen-thinkpad_acpi/hw_state
>
>
>
> Marco – Do you have any comment to debug this?
>
> Thank you very much !
>
>
>
> Thanks & Regards,
>
> Nitin
>
>
>
> *From:* Pellaeon Lin <nfs...@gm...>
> *Sent:* Thursday, June 19, 2025 10:56 PM
> *To:* Nitin Joshi1 <nj...@le...>
> *Cc:* ibm...@li...
> *Subject:* Re: [External] Re: [ibm-acpi-devel] PrivacyGuard doesn't work
> even by sending ACPI commands directly
>
>
>
> Hi all,
>
>
>
> I'd like to bring up this issue again. I just upgraded to Ubuntu 25.04,
> kernel 6.14.0-15-generic and I'm still having the same issue (the same ACPI
> call still have no effect).
>
>
>
> Thanks,
>
>
>
>
>
> Nitin Joshi1 <nj...@le...> 於 2024年9月2日 週一 下午9:42寫道：
>
> Hello Pellaeon,
>
>
>
> >> @Mark: has the team replied anything?
>
> Mark has informed me regarding this and I am yet to check this . Sorry for
> this !
>
> I will try to get hold of system and try this within this week , if I find
> AMD e-privacy guard machine .
>
>
>
> Thanks
>
>
>
> *From:* Pellaeon Lin <nfs...@gm...>
> *Sent:* Sunday, September 1, 2024 2:32 PM
> *To:* ibm...@li...
> *Subject:* [External] Re: [ibm-acpi-devel] PrivacyGuard doesn't work even
> by sending ACPI commands directly
>
>
>
> Hi,
>
>
>
> @Mark: has the team replied anything?
>
>
>
> @Marco: `proptest` on my system did not return any property related to
> privacy screen, is this normal? (I ran `proptest | grep -i privacy`, which
> returned empty result.)
>
>
>
> Thanks,
>
>
>
> Marco Trevisan (Treviño) <ma...@3v...> 於 2024年6月4日 週二 上午2:07寫道：
>
> Hi,
>
> Not sure if something changed or it is different in newer models, but
> the privacy screen feature so far has been exposed as a KMS property you
> can inspect and set with tools like proptest (in libdrm-tests package
> for what concerns ubuntu)
>
> Cheers
>
> On giu 3 2024, at 1:46 pm, Pellaeon Lin <nfs...@gm...> wrote:
>
> > Hi,
> >
> > I have a ThinkPad X13 Gen 2 AMD with PrivacyGuard. But by pressing the
> > combination key Fn+D it does not toggle the PrivacyGuard, the
> > PrivacyGuard stays on. I've tested:
> >
> > - Fn+D does toggle PrivacyGuard when I'm in the BIOS
> > - Fn+D has no effect on Ubuntu 22.10, Ubuntu 23.04, Ubuntu 23.10,
> > Ubuntu 24.04 and Fedora 40 (except Ubuntu 23.10 and 24.04, all was
> > tested using LiveUSB)
> >
> > In all of the Linux cases, I can confirm that by pressing Fn+D, the
> > status value of /proc/acpi/ibm/lcdshadow actually changes.
> >
> > I've always thought this was a Ubuntu-specific issue, until I tested
> Fedora.
> >
> > I tested this further by installing the acpi-call-dkms package on
> > Ubuntu and issues the following call:
> >
> > echo '\_SB.PCI0.LPC0.EC0.HKEY.SSSS 0x1' | sudo tee /proc/acpi/call
> >
> > It returned 0 (which should mean success), but PrivacyGuard is still
> > ON. Then I tried to call it with 0x0:
> >
> > echo '\_SB.PCI0.LPC0.EC0.HKEY.SSSS 0x0' | sudo tee /proc/acpi/call
> >
> > Also getting 0 in return. PrivacyGuard is still ON.
> >
> > Based on my limited understanding of ACPI and the kernel, at this
> > point it might be a firmware issue? (fwupdmgr shows that there is no
> > available updates) But based on my reading and understanding of
> > thinkpad_acpi.c, the particular ACPI call that I issued is also how
> > the Linux driver currently operates the PrivacyGuard feature, which
> > means the driver might also be affected by this issue. So I'm hoping
> > someone could help me debug this further, or point out anything that
> > I'm not understanding correctly.
> >
> > Thanks!
> > _______________________________________________
> >
> > ibm-acpi-devel mailing list
> >
> > ibm...@li...
> >
> > https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
>
>

Re: [ibm-acpi-devel] [PATCH] x86/Mouse: thinkpad_acpi/Trackpoint: Trackpoint Doubletap handling

[Dmitry T. <dmi...@gm...>]

On Mon, Jun 30, 2025 at 08:50:27PM +0900, Vishnu Sankar wrote:
> Hi Dimitry,
> 
> 
> On Mon, Jun 30, 2025 at 2:20 PM Dmitry Torokhov
> <dmi...@gm...> wrote:
> >
> > Hi Mark,
> >
> > On Mon, Jun 30, 2025 at 05:42:45AM +0900, Mark Pearson wrote:
> > > Hi Dmitry,
> > >
> > > On Fri, Jun 27, 2025, at 2:14 PM, Dmitry Torokhov wrote:
> > > > Hi Vishnu,
> > > >
> > > > On Fri, Jun 20, 2025 at 09:42:08AM +0900, Vishnu Sankar wrote:
> > > >> Newer ThinkPads have a doubletap feature that needs to be turned
> > > >> ON/OFF via the trackpoint registers.
> > > >> Systems released from 2023 have doubletap disabled by default and
> > > >> need the feature enabling to be useful.
> > > >>
> > > >> This patch introduces support for exposing and controlling the
> > > >> trackpoint doubletap feature via a sysfs attribute.
> > > >> /sys/devices/platform/thinkpad_acpi/tp_doubletap
> > > >> This can be toggled by an "enable" or a "disable".
> > > >>
> > > >> With this implemented we can remove the masking of events, and rely on
> > > >> HW control instead, when the feature is disabled.
> > > >>
> > > >> Note - Early Thinkpads (pre 2015) used the same register for hysteris
> > > >> control, Check the FW IDs to make sure these are not affected.
> > > >>
> > > >> trackpoint.h is moved to linux/input/.
> > > >
> > > > No, please keep everything private to trackpoint.c and do not involve
> > > > thinkpad_acpi driver. By doing so you are introducing unwanted
> > > > dependencies (for both module loading, driver initialization, and
> > > > operation) and unsafe use of non-owned pointers/dangling pointers, etc.
> > > >
> > >
> > > Do you have recommendations on how to handle this case then?
> > >
> > > This is a Thinkpad specific feature and hence the logic for involving
> > > thinkpad_acpi. There are Thinkpad hotkeys that will enable/disable the
> > > trackpoint doubletap feature - so there is some linkage. I'm not sure
> > > how to avoid that.
> > >
> > > Is there a cleaner way to do this that you'd recommend we look at
> > > using? It's a feature (albeit a minor one) on the laptops that we'd
> > > like to make available to Linux users.
> >
> > I believe if you define the doubletap as an attribute (see
> > TRACKPOINT_INT_ATTR or TRACKPOINT_BIT_ATTR in
> > drivers/input/mouse/trackpoint.c) then whatever process is handling the
> > hot keys switching this function on or off should be able to toggle the
> > behavior. The difference is that it will have to locate trackpoint node
> > in /sys/bus/serio/devices/* (or maybe scan
> > /sys/devices/platform/i8042/serio*) instead of expecting the attributes
> > be atached to thinkpad_acpi instance.
> >
> > You just don't want to have one driver directly peeking into another,
> > because then it starts breaking if you unbind or force use of a
> > different protocol, etc.
> >
> > Thanks.
> >
> > --
> > Dmitry
> 
> Thanks for the suggestion. I understand the concern about avoiding
> direct driver-to-driver calls and unwanted dependencies.
> 
> Just to clarify: if we move the sysfs attribute to the trackpoint
> driver itself (under /sys/bus/serio/devices/...), then thinkpad_acpi
> would no longer be able to directly enable/disable the doubletap
> feature in response to the Fn+G hotkey press. Don't we need userspace
> to listen for the hotkey event, find the trackpoint sysfs node, and
> toggle the attribute there?

Yes.

> That's possible, of course, but it means the feature won't work
> out-of-the-box without extra userspace integration. For example, there
> would be no automatic linkage between pressing Fn+G and toggling the
> feature unless a udev rule or userspace daemon is configured to do it.
> Or is there an approach you'd recommend to preserve the automatic
> hotkey integration while avoiding the direct dependency between
> thinkpad_acpi and trackpoint?
> Sorry, I missed something.

Well, I guess you can look into interacting with sysfs file from
thinkpad_acpi.c... There is kernel_read_file_from_path() and others, you
will need to implement write counterpart of it. Pretty ugly but safer
than following pointers that may go away.

Thanks.

-- 
Dmitry

Re: [ibm-acpi-devel] [PATCH] x86/Mouse: thinkpad_acpi/Trackpoint: Trackpoint Doubletap handling

[Dmitry T. <dmi...@gm...>]

Hi Mark,

On Mon, Jun 30, 2025 at 05:42:45AM +0900, Mark Pearson wrote:
> Hi Dmitry,
> 
> On Fri, Jun 27, 2025, at 2:14 PM, Dmitry Torokhov wrote:
> > Hi Vishnu,
> >
> > On Fri, Jun 20, 2025 at 09:42:08AM +0900, Vishnu Sankar wrote:
> >> Newer ThinkPads have a doubletap feature that needs to be turned
> >> ON/OFF via the trackpoint registers.
> >> Systems released from 2023 have doubletap disabled by default and
> >> need the feature enabling to be useful.
> >> 
> >> This patch introduces support for exposing and controlling the
> >> trackpoint doubletap feature via a sysfs attribute.
> >> /sys/devices/platform/thinkpad_acpi/tp_doubletap
> >> This can be toggled by an "enable" or a "disable".
> >> 
> >> With this implemented we can remove the masking of events, and rely on
> >> HW control instead, when the feature is disabled.
> >> 
> >> Note - Early Thinkpads (pre 2015) used the same register for hysteris
> >> control, Check the FW IDs to make sure these are not affected.
> >> 
> >> trackpoint.h is moved to linux/input/.
> >
> > No, please keep everything private to trackpoint.c and do not involve
> > thinkpad_acpi driver. By doing so you are introducing unwanted
> > dependencies (for both module loading, driver initialization, and
> > operation) and unsafe use of non-owned pointers/dangling pointers, etc.
> >
> 
> Do you have recommendations on how to handle this case then?
> 
> This is a Thinkpad specific feature and hence the logic for involving
> thinkpad_acpi. There are Thinkpad hotkeys that will enable/disable the
> trackpoint doubletap feature - so there is some linkage. I'm not sure
> how to avoid that.
> 
> Is there a cleaner way to do this that you'd recommend we look at
> using? It's a feature (albeit a minor one) on the laptops that we'd
> like to make available to Linux users.

I believe if you define the doubletap as an attribute (see
TRACKPOINT_INT_ATTR or TRACKPOINT_BIT_ATTR in
drivers/input/mouse/trackpoint.c) then whatever process is handling the
hot keys switching this function on or off should be able to toggle the
behavior. The difference is that it will have to locate trackpoint node
in /sys/bus/serio/devices/* (or maybe scan
/sys/devices/platform/i8042/serio*) instead of expecting the attributes
be atached to thinkpad_acpi instance.

You just don't want to have one driver directly peeking into another,
because then it starts breaking if you unbind or force use of a
different protocol, etc.

Thanks.

-- 
Dmitry

Re: [ibm-acpi-devel] [PATCH] x86/Mouse: thinkpad_acpi/Trackpoint: Trackpoint Doubletap handling

[Mark P. <mpe...@sq...>]

Hi Dmitry,

On Fri, Jun 27, 2025, at 2:14 PM, Dmitry Torokhov wrote:
> Hi Vishnu,
>
> On Fri, Jun 20, 2025 at 09:42:08AM +0900, Vishnu Sankar wrote:
>> Newer ThinkPads have a doubletap feature that needs to be turned
>> ON/OFF via the trackpoint registers.
>> Systems released from 2023 have doubletap disabled by default and
>> need the feature enabling to be useful.
>> 
>> This patch introduces support for exposing and controlling the
>> trackpoint doubletap feature via a sysfs attribute.
>> /sys/devices/platform/thinkpad_acpi/tp_doubletap
>> This can be toggled by an "enable" or a "disable".
>> 
>> With this implemented we can remove the masking of events, and rely on
>> HW control instead, when the feature is disabled.
>> 
>> Note - Early Thinkpads (pre 2015) used the same register for hysteris
>> control, Check the FW IDs to make sure these are not affected.
>> 
>> trackpoint.h is moved to linux/input/.
>
> No, please keep everything private to trackpoint.c and do not involve
> thinkpad_acpi driver. By doing so you are introducing unwanted
> dependencies (for both module loading, driver initialization, and
> operation) and unsafe use of non-owned pointers/dangling pointers, etc.
>

Do you have recommendations on how to handle this case then?

This is a Thinkpad specific feature and hence the logic for involving thinkpad_acpi. There are Thinkpad hotkeys that will enable/disable the trackpoint doubletap feature - so there is some linkage. I'm not sure how to avoid that.

Is there a cleaner way to do this that you'd recommend we look at using? It's a feature (albeit a minor one) on the laptops that we'd like to make available to Linux users.

Mark

Re: [ibm-acpi-devel] [PATCH] x86/Mouse: thinkpad_acpi/Trackpoint: Trackpoint Doubletap handling

[Dmitry T. <dmi...@gm...>]

Hi Vishnu,

On Fri, Jun 20, 2025 at 09:42:08AM +0900, Vishnu Sankar wrote:
> Newer ThinkPads have a doubletap feature that needs to be turned
> ON/OFF via the trackpoint registers.
> Systems released from 2023 have doubletap disabled by default and
> need the feature enabling to be useful.
> 
> This patch introduces support for exposing and controlling the
> trackpoint doubletap feature via a sysfs attribute.
> /sys/devices/platform/thinkpad_acpi/tp_doubletap
> This can be toggled by an "enable" or a "disable".
> 
> With this implemented we can remove the masking of events, and rely on
> HW control instead, when the feature is disabled.
> 
> Note - Early Thinkpads (pre 2015) used the same register for hysteris
> control, Check the FW IDs to make sure these are not affected.
> 
> trackpoint.h is moved to linux/input/.

No, please keep everything private to trackpoint.c and do not involve
thinkpad_acpi driver. By doing so you are introducing unwanted
dependencies (for both module loading, driver initialization, and
operation) and unsafe use of non-owned pointers/dangling pointers, etc.

Thanks.

-- 
Dmitry

[ibm-acpi-devel] [PATCH] platform/x86: thinkpad_acpi: handle HKEY 0x1402 event

[Mark P. <mpe...@sq...>]

2025 Thinkpads F11 key launch the Intel Unison app on Windows,
which does some sort of smart sharing between laptop and phone.

Map this key event to KEY_LINK_PHONE as the closest thing we have.
This prevents an error message being displayed on key press.

Reported-by: Damjan Georgievski<gd...@gm...>
Closes: https://sourceforge.net/p/ibm-acpi/mailman/message/59189556/
Signed-off-by: Mark Pearson <mpe...@sq...>
---
 drivers/platform/x86/lenovo/thinkpad_acpi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/platform/x86/lenovo/thinkpad_acpi.c b/drivers/platform/x86/lenovo/thinkpad_acpi.c
index e1c7bd06fa12..2155ec682b08 100644
--- a/drivers/platform/x86/lenovo/thinkpad_acpi.c
+++ b/drivers/platform/x86/lenovo/thinkpad_acpi.c
@@ -3295,6 +3295,7 @@ static const struct key_entry keymap_lenovo[] __initconst = {
 	 */
 	{ KE_KEY, 0x131d, { KEY_VENDOR } }, /* System debug info, similar to old ThinkPad key */
 	{ KE_KEY, 0x1320, { KEY_LINK_PHONE } },
+	{ KE_KEY, 0x1402, { KEY_LINK_PHONE } },
 	{ KE_KEY, TP_HKEY_EV_TRACK_DOUBLETAP /* 0x8036 */, { KEY_PROG4 } },
 	{ KE_END }
 };
-- 
2.43.0

Re: [ibm-acpi-devel] [External] Re: PrivacyGuard doesn't work even by sending ACPI commands directly

[Nitin J. <nj...@le...>]

Thanks Pellaeon !

Even I can reproduce it (using Ubuntu 24.04) but I can see it gets toggled correctly using below sysfs:
cat /sys/class/drm/privacy_screen-thinkpad_acpi/hw_state

Marco – Do you have any comment to debug this?
Thank you very much !

Thanks & Regards,
Nitin

From: Pellaeon Lin <nfs...@gm...>
Sent: Thursday, June 19, 2025 10:56 PM
To: Nitin Joshi1 <nj...@le...>
Cc: ibm...@li...
Subject: Re: [External] Re: [ibm-acpi-devel] PrivacyGuard doesn't work even by sending ACPI commands directly

Hi all,

I'd like to bring up this issue again. I just upgraded to Ubuntu 25.04, kernel 6.14.0-15-generic and I'm still having the same issue (the same ACPI call still have no effect).

Thanks,


Nitin Joshi1 <nj...@le...<mailto:nj...@le...>> 於 2024年9月2日 週一 下午9:42寫道：
Hello Pellaeon,

>> @Mark: has the team replied anything?
Mark has informed me regarding this and I am yet to check this . Sorry for this !
I will try to get hold of system and try this within this week , if I find AMD e-privacy guard machine .

Thanks

From: Pellaeon Lin <nfs...@gm...<mailto:nfs...@gm...>>
Sent: Sunday, September 1, 2024 2:32 PM
To: ibm...@li...<mailto:ibm...@li...>
Subject: [External] Re: [ibm-acpi-devel] PrivacyGuard doesn't work even by sending ACPI commands directly

Hi,

@Mark: has the team replied anything?

@Marco: `proptest` on my system did not return any property related to privacy screen, is this normal? (I ran `proptest | grep -i privacy`, which returned empty result.)

Thanks,

Marco Trevisan (Treviño) <ma...@3v...<mailto:ma...@3v...>> 於 2024年6月4日 週二 上午2:07寫道：
Hi,

Not sure if something changed or it is different in newer models, but
the privacy screen feature so far has been exposed as a KMS property you
can inspect and set with tools like proptest (in libdrm-tests package
for what concerns ubuntu)

Cheers

On giu 3 2024, at 1:46 pm, Pellaeon Lin <nfs...@gm...<mailto:nfs...@gm...>> wrote:

> Hi,
>
> I have a ThinkPad X13 Gen 2 AMD with PrivacyGuard. But by pressing the
> combination key Fn+D it does not toggle the PrivacyGuard, the
> PrivacyGuard stays on. I've tested:
>
> - Fn+D does toggle PrivacyGuard when I'm in the BIOS
> - Fn+D has no effect on Ubuntu 22.10, Ubuntu 23.04, Ubuntu 23.10,
> Ubuntu 24.04 and Fedora 40 (except Ubuntu 23.10 and 24.04, all was
> tested using LiveUSB)
>
> In all of the Linux cases, I can confirm that by pressing Fn+D, the
> status value of /proc/acpi/ibm/lcdshadow actually changes.
>
> I've always thought this was a Ubuntu-specific issue, until I tested Fedora.
>
> I tested this further by installing the acpi-call-dkms package on
> Ubuntu and issues the following call:
>
> echo '\_SB.PCI0.LPC0.EC0.HKEY.SSSS 0x1' | sudo tee /proc/acpi/call
>
> It returned 0 (which should mean success), but PrivacyGuard is still
> ON. Then I tried to call it with 0x0:
>
> echo '\_SB.PCI0.LPC0.EC0.HKEY.SSSS 0x0' | sudo tee /proc/acpi/call
>
> Also getting 0 in return. PrivacyGuard is still ON.
>
> Based on my limited understanding of ACPI and the kernel, at this
> point it might be a firmware issue? (fwupdmgr shows that there is no
> available updates) But based on my reading and understanding of
> thinkpad_acpi.c, the particular ACPI call that I issued is also how
> the Linux driver currently operates the PrivacyGuard feature, which
> means the driver might also be affected by this issue. So I'm hoping
> someone could help me debug this further, or point out anything that
> I'm not understanding correctly.
>
> Thanks!
> _______________________________________________
>
> ibm-acpi-devel mailing list
>
> ibm...@li...<mailto:ibm...@li...>
>
> https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] [External] Re: PrivacyGuard doesn't work even by sending ACPI commands directly

[Pellaeon L. <nfs...@gm...>]

Hi all,

I'd like to bring up this issue again. I just upgraded to Ubuntu 25.04,
kernel 6.14.0-15-generic and I'm still having the same issue (the same ACPI
call still have no effect).

Thanks,


Nitin Joshi1 <nj...@le...> 於 2024年9月2日 週一 下午9:42寫道：

> Hello Pellaeon,
>
>
>
> >> @Mark: has the team replied anything?
>
> Mark has informed me regarding this and I am yet to check this . Sorry for
> this !
>
> I will try to get hold of system and try this within this week , if I find
> AMD e-privacy guard machine .
>
>
>
> Thanks
>
>
>
> *From:* Pellaeon Lin <nfs...@gm...>
> *Sent:* Sunday, September 1, 2024 2:32 PM
> *To:* ibm...@li...
> *Subject:* [External] Re: [ibm-acpi-devel] PrivacyGuard doesn't work even
> by sending ACPI commands directly
>
>
>
> Hi,
>
>
>
> @Mark: has the team replied anything?
>
>
>
> @Marco: `proptest` on my system did not return any property related to
> privacy screen, is this normal? (I ran `proptest | grep -i privacy`, which
> returned empty result.)
>
>
>
> Thanks,
>
>
>
> Marco Trevisan (Treviño) <ma...@3v...> 於 2024年6月4日 週二 上午2:07寫道：
>
> Hi,
>
> Not sure if something changed or it is different in newer models, but
> the privacy screen feature so far has been exposed as a KMS property you
> can inspect and set with tools like proptest (in libdrm-tests package
> for what concerns ubuntu)
>
> Cheers
>
> On giu 3 2024, at 1:46 pm, Pellaeon Lin <nfs...@gm...> wrote:
>
> > Hi,
> >
> > I have a ThinkPad X13 Gen 2 AMD with PrivacyGuard. But by pressing the
> > combination key Fn+D it does not toggle the PrivacyGuard, the
> > PrivacyGuard stays on. I've tested:
> >
> > - Fn+D does toggle PrivacyGuard when I'm in the BIOS
> > - Fn+D has no effect on Ubuntu 22.10, Ubuntu 23.04, Ubuntu 23.10,
> > Ubuntu 24.04 and Fedora 40 (except Ubuntu 23.10 and 24.04, all was
> > tested using LiveUSB)
> >
> > In all of the Linux cases, I can confirm that by pressing Fn+D, the
> > status value of /proc/acpi/ibm/lcdshadow actually changes.
> >
> > I've always thought this was a Ubuntu-specific issue, until I tested
> Fedora.
> >
> > I tested this further by installing the acpi-call-dkms package on
> > Ubuntu and issues the following call:
> >
> > echo '\_SB.PCI0.LPC0.EC0.HKEY.SSSS 0x1' | sudo tee /proc/acpi/call
> >
> > It returned 0 (which should mean success), but PrivacyGuard is still
> > ON. Then I tried to call it with 0x0:
> >
> > echo '\_SB.PCI0.LPC0.EC0.HKEY.SSSS 0x0' | sudo tee /proc/acpi/call
> >
> > Also getting 0 in return. PrivacyGuard is still ON.
> >
> > Based on my limited understanding of ACPI and the kernel, at this
> > point it might be a firmware issue? (fwupdmgr shows that there is no
> > available updates) But based on my reading and understanding of
> > thinkpad_acpi.c, the particular ACPI call that I issued is also how
> > the Linux driver currently operates the PrivacyGuard feature, which
> > means the driver might also be affected by this issue. So I'm hoping
> > someone could help me debug this further, or point out anything that
> > I'm not understanding correctly.
> >
> > Thanks!
> > _______________________________________________
> >
> > ibm-acpi-devel mailing list
> >
> > ibm...@li...
> >
> > https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
>
>

Re: [ibm-acpi-devel] [PATCH v4 2/2] platform/x86: Move Lenovo files into lenovo subdir

[Mark P. <mpe...@sq...>]

On Wed, Jun 11, 2025, at 11:07 AM, Andy Shevchenko wrote:
> On Wed, Jun 11, 2025 at 06:01:36PM +0300, Ilpo Järvinen wrote:
>> On Tue, 10 Jun 2025, Mark Pearson wrote:
>> > On Tue, Jun 10, 2025, at 4:27 PM, Andy Shevchenko wrote:
>> > > On Tue, Jun 10, 2025 at 03:28:25PM -0400, Mark Pearson wrote:
>> > >> Create lenovo subdirectory for holding Lenovo specific drivers.
>> > >
>> > > Assuming Kconfig entries have mostly been copied'n'pasted, the rest LGTM,
>> > 
>> > Yes - no changes from what they were previously.
>> 
>> Indeed, no changes, too bad that the addition "depends on DMI" was missed 
>> because of that ;-). I've fixed this for you to not delay this patch 
>> further.
>
> Oh, thanks!
>
Ooops - sorry! That was bad :( Thanks for fixing.

>> A diff-of-pre/post magic trick helps to validate while preparing and 
>> review move changes like this:
>> 
>> diff -u <(grep '^[-]' patch.patch | cut -b 2- | sort) <(grep '^[+]' patch.patch | cut -b 2- | sort)
>
> AFAIK Git can do something like this for you (patch to the patch) or `b4`.
> Never used personally, but interested to try if somebody tells me what to
> do :-)
>
>> The sorting is not always needed if no core reordering is done in the 
>> patch but regardless of sorting or not, the unexpected differences are 
>> usually pretty easy to spot from the output of that command. It's how I 
>> found out the lack of depends on DMI on the post side and have found 
>> plenty of similar issue when changes are rebased/reordered in a series 
>> that does contain a move change.
>> 
>> While applying this, I realized I'd taken Jelle's ideapad patch which 
>> resulted in this move patch not applying cleanly, so I ended up moving 
>> Jelle's patch after this change to make things easier for me.
>> 

Thanks - hopefully this doesn't cause you headaches for the rest of the window.

Mark

Re: [ibm-acpi-devel] [PATCH v4 2/2] platform/x86: Move Lenovo files into lenovo subdir

[Andy S. <and...@li...>]

On Wed, Jun 11, 2025 at 06:01:36PM +0300, Ilpo Järvinen wrote:
> On Tue, 10 Jun 2025, Mark Pearson wrote:
> > On Tue, Jun 10, 2025, at 4:27 PM, Andy Shevchenko wrote:
> > > On Tue, Jun 10, 2025 at 03:28:25PM -0400, Mark Pearson wrote:
> > >> Create lenovo subdirectory for holding Lenovo specific drivers.
> > >
> > > Assuming Kconfig entries have mostly been copied'n'pasted, the rest LGTM,
> > 
> > Yes - no changes from what they were previously.
> 
> Indeed, no changes, too bad that the addition "depends on DMI" was missed 
> because of that ;-). I've fixed this for you to not delay this patch 
> further.

Oh, thanks!

> A diff-of-pre/post magic trick helps to validate while preparing and 
> review move changes like this:
> 
> diff -u <(grep '^[-]' patch.patch | cut -b 2- | sort) <(grep '^[+]' patch.patch | cut -b 2- | sort)

AFAIK Git can do something like this for you (patch to the patch) or `b4`.
Never used personally, but interested to try if somebody tells me what to
do :-)

> The sorting is not always needed if no core reordering is done in the 
> patch but regardless of sorting or not, the unexpected differences are 
> usually pretty easy to spot from the output of that command. It's how I 
> found out the lack of depends on DMI on the post side and have found 
> plenty of similar issue when changes are rebased/reordered in a series 
> that does contain a move change.
> 
> While applying this, I realized I'd taken Jelle's ideapad patch which 
> resulted in this move patch not applying cleanly, so I ended up moving 
> Jelle's patch after this change to make things easier for me.
> 
> > > Reviewed-by: Andy Shevchenko <and...@li...>
> > >
> > Thanks for the reviews and help with both patches
> 
> Thanks for doing this, hopefully LKP will be okay with this change too
> and we can once again focus on less conflict prone work. :-)

-- 
With Best Regards,
Andy Shevchenko

Re: [ibm-acpi-devel] [PATCH v4 2/2] platform/x86: Move Lenovo files into lenovo subdir

[Mark P. <mpe...@sq...>]

On Tue, Jun 10, 2025, at 4:27 PM, Andy Shevchenko wrote:
> On Tue, Jun 10, 2025 at 03:28:25PM -0400, Mark Pearson wrote:
>> Create lenovo subdirectory for holding Lenovo specific drivers.
>
> Assuming Kconfig entries have mostly been copied'n'pasted, the rest LGTM,

Yes - no changes from what they were previously.

> Reviewed-by: Andy Shevchenko <and...@li...>
>
Thanks for the reviews and help with both patches

Mark

Re: [ibm-acpi-devel] [PATCH v4 2/2] platform/x86: Move Lenovo files into lenovo subdir

[Andy S. <and...@li...>]

On Tue, Jun 10, 2025 at 03:28:25PM -0400, Mark Pearson wrote:
> Create lenovo subdirectory for holding Lenovo specific drivers.

Assuming Kconfig entries have mostly been copied'n'pasted, the rest LGTM,
Reviewed-by: Andy Shevchenko <and...@li...>

-- 
With Best Regards,
Andy Shevchenko

Re: [ibm-acpi-devel] [PATCH v4 1/2] platform/x86: thinklmi: improved DMI handling

[Andy S. <and...@li...>]

On Tue, Jun 10, 2025 at 03:28:24PM -0400, Mark Pearson wrote:
> Fix issues reported by kernel test robot.
>  - Require DMI for think-lmi.
>  - Check return from getting serial string

Reviewed-by: Andy Shevchenko <and...@li...>

-- 
With Best Regards,
Andy Shevchenko