Re: [ibm-acpi-devel] [PATCH AUTOSEL 6.1 12/24] platform/x86: thinkpad_acpi: fix for incorrect fan reporting on some ThinkPad systems

[Pavel Machek]

Hi!

> [ Upstream commit 66e92e23a72761f5b53f970aeb1badc5fd92fc74 ]
> 
> Some ThinkPad systems ECFW use non-standard addresses for fan control
> and reporting. This patch adds support for such ECFW so that it can report
> the correct fan values.
> Tested on Thinkpads L13 Yoga Gen 2 and X13 Yoga Gen 2.

This is just a new feature, and is > 200 lines. We should not have
this in stable.

BR,
Pavel





> Suggested-by: Mark Pearson 
> Signed-off-by: Vishnu Sankar 
> Reviewed-by: Hans de Goede 
> Reviewed-by: Ilpo Järvinen 
> Link: https://lore.kernel.org/r/20231214134702.166464-1-vishnu...@gmail.com
> Signed-off-by: Ilpo Järvinen 
> Signed-off-by: Sasha Levin 
> ---
>  drivers/platform/x86/thinkpad_acpi.c | 98 
>  1 file changed, 85 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/platform/x86/thinkpad_acpi.c 
> b/drivers/platform/x86/thinkpad_acpi.c
> index 05a55bc31c796..6edd2e294750e 100644
> --- a/drivers/platform/x86/thinkpad_acpi.c
> +++ b/drivers/platform/x86/thinkpad_acpi.c
> @@ -8149,8 +8149,19 @@ static struct ibm_struct volume_driver_data = {
>   *   TPACPI_FAN_WR_TPEC is also available and should be used to
>   *   command the fan.  The X31/X40/X41 seems to have 8 fan levels,
>   *   but the ACPI tables just mention level 7.
> + *
> + * TPACPI_FAN_RD_TPEC_NS:
> + *   This mode is used for a few ThinkPads (L13 Yoga Gen2, X13 Yoga Gen2 
> etc.)
> + *   that are using non-standard EC locations for reporting fan speeds.
> + *   Currently these platforms only provide fan rpm reporting.
> + *
>   */
>  
> +#define FAN_RPM_CAL_CONST 491520 /* FAN RPM calculation offset for some 
> non-standard ECFW */
> +
> +#define FAN_NS_CTRL_STATUS   BIT(2)  /* Bit which determines control 
> is enabled or not */
> +#define FAN_NS_CTRL  BIT(4)  /* Bit which determines control 
> is by host or EC */
> +
>  enum {   /* Fan control constants */
>   fan_status_offset = 0x2f,   /* EC register 0x2f */
>   fan_rpm_offset = 0x84,  /* EC register 0x84: LSB, 0x85 MSB (RPM)
> @@ -8158,6 +8169,11 @@ enum { /* Fan control 
> constants */
>   fan_select_offset = 0x31,   /* EC register 0x31 (Firmware 7M)
>  bit 0 selects which fan is active */
>  
> + fan_status_offset_ns = 0x93,/* Special status/control offset for 
> non-standard EC Fan1 */
> + fan2_status_offset_ns = 0x96,   /* Special status/control offset for 
> non-standard EC Fan2 */
> + fan_rpm_status_ns = 0x95,   /* Special offset for Fan1 RPM status 
> for non-standard EC */
> + fan2_rpm_status_ns = 0x98,  /* Special offset for Fan2 RPM status 
> for non-standard EC */
> +
>   TP_EC_FAN_FULLSPEED = 0x40, /* EC fan mode: full speed */
>   TP_EC_FAN_AUTO  = 0x80, /* EC fan mode: auto fan control */
>  
> @@ -8168,6 +8184,7 @@ enum fan_status_access_mode {
>   TPACPI_FAN_NONE = 0,/* No fan status or control */
>   TPACPI_FAN_RD_ACPI_GFAN,/* Use ACPI GFAN */
>   TPACPI_FAN_RD_TPEC, /* Use ACPI EC regs 0x2f, 0x84-0x85 */
> + TPACPI_FAN_RD_TPEC_NS,  /* Use non-standard ACPI EC regs (eg: 
> L13 Yoga gen2 etc.) */
>  };
>  
>  enum fan_control_access_mode {
> @@ -8195,6 +8212,8 @@ static u8 fan_control_desired_level;
>  static u8 fan_control_resume_level;
>  static int fan_watchdog_maxinterval;
>  
> +static bool fan_with_ns_addr;
> +
>  static struct mutex fan_mutex;
>  
>  static void fan_watchdog_fire(struct work_struct *ignored);
> @@ -8325,6 +8344,15 @@ static int fan_get_status(u8 *status)
>   }
>  
>   break;
> + case TPACPI_FAN_RD_TPEC_NS:
> + /* Default mode is AUTO which means controlled by EC */
> + if (!acpi_ec_read(fan_status_offset_ns, ))
> + return -EIO;
> +
> + if (status)
> + *status = s;
> +
> + break;
>  
>   default:
>   return -ENXIO;
> @@ -8341,7 +8369,8 @@ static int fan_get_status_safe(u8 *status)
>   if (mutex_lock_killable(_mutex))
>   return -ERESTARTSYS;
>   rc = fan_get_status();
> - if (!rc)
> + /* NS EC doesn't have register with level settings */
> + if (!rc && !fan_with_ns_addr)
>   fan_update_desired_level(s);
>   mutex_unlock(_mutex);
>  
> @@ -8368,7 +8397,13 @@ static int fan_get_speed(unsigned int *speed)
>  
>   if (likely(speed))
>   *speed = (hi << 8) | lo;
> + break;
> + case TPACPI_FAN_RD_TPEC_NS:
> + if (!acpi_ec_read(fan_rpm_status_ns, ))
> + return -EIO;
>  
> + if (speed)
> + *speed = lo ? FAN_RPM_CAL_CONST / lo : 0;
>   break;
>  
>   default:
> @@ -8380,7 +8415,7 @@ 

Re: [ibm-acpi-devel] [PATCH v2] Input: document inhibiting

[Pavel Machek]

Hi!

> +Inhibiting input devices
> +
> +
> +Inhibiting a device means ignoring input events from it. As such it is about 
> maintaining
> +relationships with input handlers - either already existing relationships, 
> or relationships
> +to be established while the device is in inhibited state.
> +
> +If a device is inhibited, no input handler will receive events from it.
> +
> +The fact that nobody wants events from the device is exploited further, by 
> calling device's
> +close() (if there are users) and open() (if there are users) on inhibit and 
> uninhibit
> +operations, respectively. Indeed, the meaning of close() is to stop 
> providing events
> +to the input core and that of open() is to start providing events to the 
> input core.
> +
> +Calling the device's close() method on inhibit (if there are users) allows 
> the driver
> +to save power. Either by directly powering down the device or by releasing 
> the
> +runtime-pm reference it got in open() when the driver is using runtime-pm.
> +
> +Inhibiting and uninhibiting are orthogonal to opening and closing the device 
> by input
> +handlers. Userspace might want to inhibit a device in anticipation before 
> any handler is
> +positively matched against it.

Ok.

> +Inhibiting and uninhibiting are orthogonal to device's being a wakeup 
> source, too. 
> Being a +wakeup source plays a role when the system is sleeping, not when the 
> system is 
> operating. +How drivers should program their interaction between inhibiting, 
> sleeping 
> and being a wakeup +source is driver-specific. + +Taking the analogy with the 
> network 

I don't believe making interaction driver-specific is good idea. We should 
decide
what reasonable behaviour is and then make drivers implement that...

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] [PATCH v3 0/7] Support inhibiting input devices

[Pavel Machek]

On Fri 2020-06-05 19:33:28, Andrzej Pietrasiewicz wrote:
> Userspace might want to implement a policy to temporarily disregard input
> from certain devices.

Wow, you certainly cc a lot of lists.

> An example use case is a convertible laptop, whose keyboard can be folded
> under the screen to create tablet-like experience. The user then must hold
> the laptop in such a way that it is difficult to avoid pressing the keyboard
> keys. It is therefore desirable to temporarily disregard input from the
> keyboard, until it is folded back. This obviously is a policy which should
> be kept out of the kernel, but the kernel must provide suitable means to
> implement such a policy.
> 
> Due to interactions with suspend/resume, a helper has been added for drivers
> to decide if the device is being used or not (PATCH 1/7) and it has been
> applied to relevant drivers (PATCH 2,4,5,6/7).

But is that a right way to implement it?

We want this for cellphones, too -- touchscreen should be disabled
while the device is locked in the pocket -- but we really want the
touchscreen hardware to be powered down in that case (because it keeps
SoC busy and eats a _lot_ of electricity).

But simplistic "receive an event and then drop it if device is
inhibited" does not allow that...

Best regards,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] [PATCH] leds: avoid races with workqueue

[Pavel Machek]

Hi!

> >Yes, that looks right. If you can add fixes: and cc: stable tags, the
> >rest should happen automagically.
> 
> Cc: sta...@kernel.org is exactly for what it claims - sending a copy
> to that list.
> 
> "Fixes:" seems to be always enough for the bots to pick a patch.
> 
> Tag added.

Well, docs says Cc: stable is right way to request inclusion, and it
does not talk about Fixes:... but I guess that will work too.

Thanks,
Pavel

(
To have the patch automatically included in the stable tree, add the
tag

.. code-block:: none

 Cc: sta...@vger.kernel.org

in the sign-off area. Once the patch is merged it will be applied to
the stable tree without anything else needing to be done by the author
or subsystem maintainer.
)

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] [PATCH] leds: avoid races with workqueue

[Pavel Machek]

On Thu 2019-05-02 21:28:06, Jacek Anaszewski wrote:
> On 5/2/19 9:13 PM, Pavel Machek wrote:
> >Hi!
> >
> >>>>>+++ b/drivers/leds/led-class.c
> >>>>>@@ -57,6 +57,7 @@ static ssize_t brightness_store(struct device *dev,
> >>>>> if (state == LED_OFF)
> >>>>> led_trigger_remove(led_cdev);
> >>>>> led_set_brightness(led_cdev, state);
> >>>>>+flush_work(_cdev->set_brightness_work);
> >>>>
> >>>>Is this really required here? It creates non-uniform brightness
> >>>>setting behavior depending on whether it is set from sysfs or
> >>>>by in-kernel call to led_set_brightness().
> >>>
> >>>This fixes the echo 0 > brightness; echo 1 > brightness. It has to be
> >>>at a place where we can sleep.
> >>>
> >>>If you have better idea, it is welcome, but it would be good to fix
> >>>the bug.
> >>
> >>Currently not, so I applied the patch in this shape.
> >
> >Thanks!
> >
> >This is actually something that makes sense for stable.. perhaps the
> >bots can pick it up.
> 
> I was thinking of it, but finally decided to submit this patch
> to linux-stable when it will prove not having side effects.
> 
> But if you think it is ready for stable then I can add
> relevant "Fixes" tag. Do you think that below will be an appropriate
> base to refer to?
> 
> Fixes 1afcadfcd184 ("leds: core: Use set_brightness_work for the blocking
> op")

Yes, that looks right. If you can add fixes: and cc: stable tags, the
rest should happen automagically.

Thanks!
Pavel



-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] [PATCH] leds: avoid races with workqueue

[Pavel Machek]

Hi!

> >>>+++ b/drivers/leds/led-class.c
> >>>@@ -57,6 +57,7 @@ static ssize_t brightness_store(struct device *dev,
> >>>   if (state == LED_OFF)
> >>>   led_trigger_remove(led_cdev);
> >>>   led_set_brightness(led_cdev, state);
> >>>+  flush_work(_cdev->set_brightness_work);
> >>
> >>Is this really required here? It creates non-uniform brightness
> >>setting behavior depending on whether it is set from sysfs or
> >>by in-kernel call to led_set_brightness().
> >
> >This fixes the echo 0 > brightness; echo 1 > brightness. It has to be
> >at a place where we can sleep.
> >
> >If you have better idea, it is welcome, but it would be good to fix
> >the bug.
> 
> Currently not, so I applied the patch in this shape.

Thanks!

This is actually something that makes sense for stable.. perhaps the
bots can pick it up.
Pavel


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] [PATCH] leds: avoid races with workqueue

[Pavel Machek]

Hi!

> >There are races between "main" thread and workqueue. They manifest
> >themselves on Thinkpad X60:
> >This should result in LED blinking, but it turns it off instead:
> > root@amd:/data/pavel# cd /sys/class/leds/tpacpi\:\:power
> > root@amd:/sys/class/leds/tpacpi::power# echo timer > trigger
> > root@amd:/sys/class/leds/tpacpi::power# echo timer > trigger
> > root@amd:/sys/class/leds/tpacpi::power#
> >It should be possible to transition from blinking to solid on by echo
> >0 > brightness; echo 1 > brightness... but that does not work, either,
> >if done too quickly.
> >Synchronization of the workqueue fixes both.
> >Signed-off-by: Pavel Machek 
> >
> >diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
> >index 68aa923..dcb59c8 100644
> >--- a/drivers/leds/led-class.c
> >+++ b/drivers/leds/led-class.c
> >@@ -57,6 +57,7 @@ static ssize_t brightness_store(struct device *dev,
> > if (state == LED_OFF)
> > led_trigger_remove(led_cdev);
> > led_set_brightness(led_cdev, state);
> >+flush_work(_cdev->set_brightness_work);
> 
> Is this really required here? It creates non-uniform brightness
> setting behavior depending on whether it is set from sysfs or
> by in-kernel call to led_set_brightness().

This fixes the echo 0 > brightness; echo 1 > brightness. It has to be
at a place where we can sleep.

If you have better idea, it is welcome, but it would be good to fix
the bug.

Best regards,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

[ibm-acpi-devel] [PATCH] leds: avoid races with workqueue

[Pavel Machek]

There are races between "main" thread and workqueue. They manifest
themselves on Thinkpad X60:

This should result in LED blinking, but it turns it off instead:

root@amd:/data/pavel# cd /sys/class/leds/tpacpi\:\:power
root@amd:/sys/class/leds/tpacpi::power# echo timer > trigger
root@amd:/sys/class/leds/tpacpi::power# echo timer > trigger
root@amd:/sys/class/leds/tpacpi::power#

It should be possible to transition from blinking to solid on by echo
0 > brightness; echo 1 > brightness... but that does not work, either,
if done too quickly.

Synchronization of the workqueue fixes both.
    
Signed-off-by: Pavel Machek 

diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
index 68aa923..dcb59c8 100644
--- a/drivers/leds/led-class.c
+++ b/drivers/leds/led-class.c
@@ -57,6 +57,7 @@ static ssize_t brightness_store(struct device *dev,
if (state == LED_OFF)
led_trigger_remove(led_cdev);
led_set_brightness(led_cdev, state);
+   flush_work(_cdev->set_brightness_work);
 
ret = size;
 unlock:
diff --git a/drivers/leds/led-core.c b/drivers/leds/led-core.c
index 9f8da39..aefac4d 100644
--- a/drivers/leds/led-core.c
+++ b/drivers/leds/led-core.c
@@ -166,6 +166,11 @@ static void led_blink_setup(struct led_classdev *led_cdev,
 unsigned long *delay_on,
 unsigned long *delay_off)
 {
+   /*
+* If "set brightness to 0" is pending in workqueue, we don't
+* want that to be reordered after blink_set()
+*/
+   flush_work(_cdev->set_brightness_work);
if (!test_bit(LED_BLINK_ONESHOT, _cdev->work_flags) &&
led_cdev->blink_set &&
!led_cdev->blink_set(led_cdev, delay_on, delay_off))

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

[ibm-acpi-devel] [PATCH] leds: tpacpi: cleanup for Thinkpad ACPI led

[Pavel Machek]

Make error returns more consistent... no behaviour change intended.

Signed-off-by: Pavel Machek 

diff --git a/drivers/platform/x86/thinkpad_acpi.c 
b/drivers/platform/x86/thinkpad_acpi.c
index 726341f..7008a7f 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -5808,7 +5808,7 @@ static int led_set_status(const unsigned int led,
return -EPERM;
if (!acpi_evalf(led_handle, NULL, NULL, "vdd",
(1 << led), led_sled_arg1[ledstatus]))
-   rc = -EIO;
+   return -EIO;
break;
case TPACPI_LED_OLD:
/* 600e/x, 770e, 770x, A21e, A2xm/p, T20-22, X20 */
@@ -5832,10 +5832,10 @@ static int led_set_status(const unsigned int led,
return -EPERM;
if (!acpi_evalf(led_handle, NULL, NULL, "vdd",
led, led_led_arg1[ledstatus]))
-   rc = -EIO;
+   return -EIO;
break;
default:
-   rc = -ENXIO;
+   return -ENXIO;
}
 
if (!rc)

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] Thinkpad ACPI led -- it keeps blinking

[Pavel Machek]

Hi!

> >This fixes one problem:

> >Signed-off-by: Pavel Machek 
> >
> >diff --git a/drivers/leds/led-core.c b/drivers/leds/led-core.c
> >index e3da7c0..d795d8f 100644
> >--- a/drivers/leds/led-core.c
> >+++ b/drivers/leds/led-core.c
> >@@ -164,8 +164,14 @@ static void led_blink_setup(struct led_classdev 
> >*led_cdev,
> >  unsigned long *delay_on,
> >  unsigned long *delay_off)
> >  {
> >+while (work_pending(_cdev->set_brightness_work)) {
> >+printk("Waiting for brightness set to finish\n");
> >+schedule();
> >+}
> 
> Or even better:
> 
> flush_work(_cdev->set_brightness_work);

Yup, thanks for a hint.

I should have acceptable patch, soon; but no promises I catched all
similar bugs, that code is quite ... tricky.

So far I have this:

diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
index 3c7e348..85848c5 100644
--- a/drivers/leds/led-class.c
+++ b/drivers/leds/led-class.c
@@ -57,6 +57,7 @@ static ssize_t brightness_store(struct device *dev,
if (state == LED_OFF)
led_trigger_remove(led_cdev);
led_set_brightness(led_cdev, state);
+   flush_work(_cdev->set_brightness_work);
 
ret = size;
 unlock:
diff --git a/drivers/leds/led-core.c b/drivers/leds/led-core.c
index e3da7c0..e9ae7f8 100644
--- a/drivers/leds/led-core.c
+++ b/drivers/leds/led-core.c
@@ -164,6 +164,11 @@ static void led_blink_setup(struct led_classdev *led_cdev,
 unsigned long *delay_on,
 unsigned long *delay_off)
 {
+   /*
+* If "set brightness to 0" is pending in workqueue, we don't
+* want that to be reordered after blink_set()
+*/
+   flush_work(_cdev->set_brightness_work);
if (!test_bit(LED_BLINK_ONESHOT, _cdev->work_flags) &&
led_cdev->blink_set &&
!led_cdev->blink_set(led_cdev, delay_on, delay_off))
diff --git a/drivers/leds/led-triggers.c b/drivers/leds/led-triggers.c
index 2d451b6..ddfd2dd 100644
--- a/drivers/leds/led-triggers.c
+++ b/drivers/leds/led-triggers.c
@@ -65,6 +65,7 @@ ssize_t led_trigger_store(struct device *dev, struct 
device_attribute *attr,
up_read(_list_lock);
 
 unlock:
+   flush_work(_cdev->set_brightness_work);
mutex_unlock(_cdev->led_access);
return ret;
 }
diff --git a/drivers/leds/trigger/ledtrig-timer.c 
b/drivers/leds/trigger/ledtrig-timer.c
index ca898c1..0b061bb5 100644
--- a/drivers/leds/trigger/ledtrig-timer.c
+++ b/drivers/leds/trigger/ledtrig-timer.c
@@ -104,6 +104,7 @@ static void pattern_init(struct led_classdev *led_cdev)
 
 static int timer_trig_activate(struct led_classdev *led_cdev)
 {
+   printk("timer_trig_activate\n");
if (led_cdev->flags & LED_INIT_DEFAULT_TRIGGER) {
pattern_init(led_cdev);
/*
@@ -115,14 +116,18 @@ static int timer_trig_activate(struct led_classdev 
*led_cdev)
 
led_blink_set(led_cdev, _cdev->blink_delay_on,
  _cdev->blink_delay_off);
+   printk("timer_trig_activate done\n");
 
return 0;
 }
 
 static void timer_trig_deactivate(struct led_classdev *led_cdev)
 {
+   printk("timer_trig_deactivate\n");
/* Stop blinking */
led_set_brightness(led_cdev, LED_OFF);
+
+   printk("timer_trig_deactivate done\n");
 }
 
 static struct led_trigger timer_led_trigger = {
diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index 3a4402a..b3fa9c9 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -363,11 +363,11 @@ int mmc_of_parse_voltage(struct device_node *np, u32 
*mask)
int num_ranges, i;
 
voltage_ranges = of_get_property(np, "voltage-ranges", _ranges);
-   num_ranges = num_ranges / sizeof(*voltage_ranges) / 2;
if (!voltage_ranges) {
pr_debug("%pOF: voltage-ranges unspecified\n", np);
return 0;
}
+   num_ranges = num_ranges / sizeof(*voltage_ranges) / 2;
if (!num_ranges) {
pr_err("%pOF: voltage-ranges empty\n", np);
return -EINVAL;
diff --git a/drivers/platform/x86/thinkpad_acpi.c 
b/drivers/platform/x86/thinkpad_acpi.c
index 57d9ae9..3580bab 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -5867,6 +5867,8 @@ static int led_set_status(const unsigned int led,
 
int rc = 0;
 
+   printk("LED set %d to %d\n", led, ledstatus);
+
switch (led_supported) {
case TPACPI_LED_570:
/* 570 */
@@ -5876,7 +5878,7 @@ static int led_set_status(const unsigned int led,
return -EPERM;
if (!acpi_evalf(led_handle, NULL, NUL

Re: [ibm-acpi-devel] Thinkpad ACPI led -- it keeps blinking

[Pavel Machek]

Hi!

It seems quite clear:

static int timer_trig_activate(struct led_classdev *led_cdev)
{
printk("timer_trig_activate\n");
if (led_cdev->flags & LED_INIT_DEFAULT_TRIGGER) {

led_blink_set(led_cdev, _cdev->blink_delay_on, 
_cdev->blink_delay_off);

printk("timer_trig_activate done\n");

return 0;
}

static void timer_trig_deactivate(struct led_classdev *led_cdev)
{
printk("timer_trig_deactivate\n");

/* Stop blinking */
led_set_brightness(led_cdev, LED_OFF);

printk("timer_trig_deactivate done\n");
}

We get timer_trig_deactivate() immediately followed by
timer_trig_activate().

set_brightness goes to workqueue because it would block. That means
that blink_set() happens before set_brightness...

Pavel

[   16.194141] e1000e :02:00.0 eth1: 10/100 speed: disabling TSO
[  145.887931] timer_trig_activate
[  145.888011] LED set 0 to 2
[  145.79] LED set 0 to 2... 0
[  145.93] timer_trig_activate done
[  149.977138] timer_trig_deactivate
[  149.977169] timer_trig_deactivate done
[  149.977479] timer_trig_activate
[  149.977497] LED set 0 to 2
[  149.978281] LED set 0 to 2... 0
[  149.978295] timer_trig_activate done
[  149.978415] LED set 0 to 0
[  149.979851] LED set 0 to 0... 0
[  184.839252] timer_trig_deactivate
[  184.839282] timer_trig_deactivate done
[  184.839319] timer_trig_activate
[  184.839337] LED set 0 to 2
[  184.839907] LED set 0 to 0
[  184.840369] LED set 0 to 2... 0
[  184.840383] timer_trig_activate done
[  184.843318] LED set 0 to 0... 0
root@amd:/sys/class/leds/tpacpi::power#

diff --git a/drivers/leds/led-core.c b/drivers/leds/led-core.c
index e3da7c0..ca1f69b 100644
--- a/drivers/leds/led-core.c
+++ b/drivers/leds/led-core.c
@@ -166,6 +166,7 @@ static void led_blink_setup(struct led_classdev *led_cdev,
 {
if (!test_bit(LED_BLINK_ONESHOT, _cdev->work_flags) &&
led_cdev->blink_set &&
+   /* This can sleep */
!led_cdev->blink_set(led_cdev, delay_on, delay_off))
return;
 
diff --git a/drivers/leds/trigger/ledtrig-timer.c 
b/drivers/leds/trigger/ledtrig-timer.c
index ca898c1..0b061bb5 100644
--- a/drivers/leds/trigger/ledtrig-timer.c
+++ b/drivers/leds/trigger/ledtrig-timer.c
@@ -104,6 +104,7 @@ static void pattern_init(struct led_classdev *led_cdev)
 
 static int timer_trig_activate(struct led_classdev *led_cdev)
 {
+   printk("timer_trig_activate\n");
if (led_cdev->flags & LED_INIT_DEFAULT_TRIGGER) {
pattern_init(led_cdev);
/*
@@ -115,14 +116,18 @@ static int timer_trig_activate(struct led_classdev 
*led_cdev)
 
led_blink_set(led_cdev, _cdev->blink_delay_on,
  _cdev->blink_delay_off);
+   printk("timer_trig_activate done\n");
 
return 0;
 }
 
 static void timer_trig_deactivate(struct led_classdev *led_cdev)
 {
+   printk("timer_trig_deactivate\n");
/* Stop blinking */
led_set_brightness(led_cdev, LED_OFF);
+
+   printk("timer_trig_deactivate done\n");
 }
 
 static struct led_trigger timer_led_trigger = {
diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index 3a4402a..b3fa9c9 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -363,11 +363,11 @@ int mmc_of_parse_voltage(struct device_node *np, u32 
*mask)
int num_ranges, i;
 
voltage_ranges = of_get_property(np, "voltage-ranges", _ranges);
-   num_ranges = num_ranges / sizeof(*voltage_ranges) / 2;
if (!voltage_ranges) {
pr_debug("%pOF: voltage-ranges unspecified\n", np);
return 0;
}
+   num_ranges = num_ranges / sizeof(*voltage_ranges) / 2;
if (!num_ranges) {
pr_err("%pOF: voltage-ranges empty\n", np);
return -EINVAL;
diff --git a/drivers/platform/x86/thinkpad_acpi.c 
b/drivers/platform/x86/thinkpad_acpi.c
index 57d9ae9..3ec6636 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -5867,6 +5867,8 @@ static int led_set_status(const unsigned int led,
 
int rc = 0;
 
+   printk("LED set %d to %d\n", led, ledstatus);
+
switch (led_supported) {
case TPACPI_LED_570:
/* 570 */
@@ -5876,7 +5878,7 @@ static int led_set_status(const unsigned int led,
return -EPERM;
if (!acpi_evalf(led_handle, NULL, NULL, "vdd",
(1 << led), led_sled_arg1[ledstatus]))
-   rc = -EIO;
+   return -EIO;
break;
case TPACPI_LED_OLD:
/* 600e/x, 770e, 770x, A21e, A2xm/p, T20-22, X20 */
@@ -5900,12 +5902,14 @@ static int led_set_status(const unsigned int led,
return -EPERM;
if (!acpi_evalf(led_handle, NULL, NULL, "vdd",
  

Re: [ibm-acpi-devel] Thinkpad ACPI led -- it keeps blinking

[Pavel Machek]

On Sat 2019-04-27 22:35:35, Jacek Anaszewski wrote:
> On 4/27/19 9:34 PM, Pavel Machek wrote:
> >On Sat 2019-04-27 18:55:37, Jacek Anaszewski wrote:
> >>On 4/26/19 11:42 PM, Pavel Machek wrote:
> >>>Hi!
> >>>
> >>>>Kernel 5.1.0-rc1 + some unrelated bits.
> >>>
> >>>I tried adding
> >>>https://marc.info/?l=linux-kernel=151622365715313=raw as Jacek
> >>>suggested, and it is still broken.
> >>>
> >>>Test code is this: ledtest actually works as expected on first try,
> >>>but keeps blinking on second run. Strange.
> >>
> >>Did it work for previous releases? If yes, then bisect should help here.
> >
> >Absolutely no idea :-(. I assume "no". Capslock LED on the same system
> >works as expected.
> >
> >I still hope thinkpad people will speak up, notice it does not work
> >for them, and debug it :-).
> 
> I see this driver implements blink_set:
> 
> tpacpi_leds[led].led_classdev.blink_set = _sysfs_blink_set;
> 
> and also applies some internal logic related to the type
> of supported LEDs, and the way how the hardware is accessed.
> 
> To eliminate the problem on the LED core side you could
> disable initialization of blink_set op in the driver.

Yep, software blinking will very likely work ok.

[  226.949924] LED set 0 to 2
[  226.950766] LED set 0 to 2... 0
[  232.613577] LED set 0 to 2
[  232.613991] LED set 0 to 0
[  232.614467] LED set 0 to 2... 0
[  232.616442] LED set 0 to 0... 0

Thinkpad ACPI driver is being asked to turn led to blink [232.613577]
LED set 0 to 2 and turn it off [  232.613991] LED set 0 to 0
simultaneously. It has no internal locking and ACPI is slow. That
can't end well.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] Thinkpad ACPI led -- it keeps blinking

[Pavel Machek]

Hi!

> Kernel 5.1.0-rc1 + some unrelated bits.

I tried adding
https://marc.info/?l=linux-kernel=151622365715313=raw as Jacek
suggested, and it is still broken.

Test code is this: ledtest actually works as expected on first try,
but keeps blinking on second run. Strange.

Pavel

#!/usr/bin/python
# -*- python -*-
# Copyright Bluez project, GPLv2
# Adapted from test/monitor-bluetooth

from __future__ import absolute_import, print_function, unicode_literals

import sys
import time
import os

import dbus
import dbus.mainloop.glib
try:
  from gi.repository import GObject
except ImportError:
  import gobject as GObject

relevant_ifaces = [ "org.bluez.Device1" ]

class LED:
def __init__(self):
self.path = "/sys/class/leds/tpacpi::power/"
#self.path = "/sys/class/leds/input5::capslock/"
self.brightness = self.path + "brightness"
self.trigger = self.path + "trigger"

def set(self, name, val):
f = open(name, "w")
f.write(val)
f.close()

def solid(self, b):
self.set(self.trigger, "none")
self.set(self.brightness, "0")
self.set(self.brightness, str(b))

def blink(self):
self.set(self.trigger, "timer")

def as_root(self):
os.chmod(self.trigger, 0777)
os.chmod(self.brightness, 0777)

def led_test():
l = LED()
l.solid(0)
time.sleep(2)
l.solid(1)
time.sleep(2)
l.blink()
time.sleep(2)
l.solid(1)

def handle_params(args):
if len(args) < 2 or args[1] == "run":
LED().blink()
run()
return
if args[1] == "ledtest":
led_test()
return
if args[1] == "stop":
LED().solid(0)
if args[1] == "startup":
LED().as_root()
return

print("Unknown parameters", args)

handle_params(sys.argv)




-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

[ibm-acpi-devel] Thinkpad ACPI led -- it keeps blinking

[Pavel Machek]

Hi!

Something is wrong with blinking on thinkpad

pavel@amd:~/bt/blee$ cat /sys/class/leds/tpacpi\:\:power/trigger
[none] bluetooth-power rfkill-any rfkill-none kbd-scrolllock
kbd-numlock kbd-capslock kbd-kanalock kbd-shiftlock kbd-altgrlock
kbd-ctrllock kbd-altlock kbd-shiftllock kbd-shiftrlock kbd-ctrlllock
kbd-ctrlrlock AC-online BAT0-charging-or-full BAT0-charging BAT0-full
BAT0-charging-blink-full-solid rfkill0 phy0rx phy0tx phy0assoc
phy0radio phy0tpt mmc0 timer heartbeat audio-mute audio-micmute
rfkill1 hci0-power rfkill5
pavel@amd:~/bt/blee$ echo 1 >
/sys/class/leds/tpacpi\:\:power/brightness
pavel@amd:~/bt/blee$ echo 0 >
/sys/class/leds/tpacpi\:\:power/brightness
pavel@amd:~/bt/blee$

Trigger indicates "none" but it keeps blinking, until I echo 0 >
brightness to stop it. I have python script to trigger this
behaviour... it seems to work from shell.

It behaves strangely. If I ask for blinking twice, it stops blinking
on second request.

pavel@amd:~/bt/blee$ echo timer >
/sys/class/leds/tpacpi\:\:power/trigger
pavel@amd:~/bt/blee$ echo timer >
/sys/class/leds/tpacpi\:\:power/trigger

echoing none fixes it. 

Kernel 5.1.0-rc1 + some unrelated bits.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

[ibm-acpi-devel] Well-known LED names was Re: [PATCH 0/6] Introduce audio-mute LED trigger (and conversions to it)

[Pavel Machek]

Hi!

> >>> If external USB keyboard is identified as "input7" device, then
> >>> "input7::mute" is a good name for mute key. But "sys::mute" does not say
> >>> anything to which device or hardware it belongs nor does not solve
> >>> problem that which device/driver/subsystem should have privilege to take
> >>> this "sys" name.
> >>
> >> How about just "platform" for the LEDs being part of the device
> >> on which the system is running?
> > 
> > "platform" works for me.
> > 
> > Are we in agreement that this name will be used for all similar LEDs,
> > as long as they are on the "main box" of the device, no matter if they
> > are connected using acpi, gpio, i2c, ...?
> 
> One doubt: say we have hdd activity LED on the "main box" - it
> would be named "platform::disk".
> 
> Now, we add external USB disk. Previously we were considering
> the naming for disk LEDs in the form e.g. "sdb::disk".
> 
> If so, there would be discrepancy between internal and external disk
> LED names. Similarly in case of eth/adsl/wlan/camera LEDs.

Well, it really depends if the "plaform::disk" is for all the disks,
or if it is for sda. In the second case, it might be better to name it
sda::disk...

Anyway... I believe we should start documenting good and bad LEDs, so
that patch authors know what is there, and can try to be consistent,
and so that userland knows what names to probe for.

What about following? Any other LEDs worth mentioning?

commit c56708addf9c312cefd760bca218a0545258b217
Author: Pavel 
Date:   Sat Dec 1 15:32:13 2018 +0100

leds: Add list of well-known LED names

Signed-off-by: Pavel Machek 

diff --git a/Documentation/leds/well-known-leds.txt 
b/Documentation/leds/well-known-leds.txt
new file mode 100644
index 000..9a262db
--- /dev/null
+++ b/Documentation/leds/well-known-leds.txt
@@ -0,0 +1,42 @@
+-*- org -*-
+
+It is somehow important to provide consistent interface to the
+userland. LED devices have one problem there, and that is naming of
+directories in /sys/class/leds. It would be nice if userland would
+just know right "name" for given LED function, but situation got more
+complex.
+
+Anyway, if backwards compatibility is not an issue, new code should
+use one of the "good" names from this list, and you should extend the
+list where applicable.
+
+Bad names are listed, too, in case you are writing application that
+wants to use particular feature, you should probe for good name first
+but then try the bad ones, too".
+
+* Keyboards
+
+Good: "input*:*:capslock"
+Good: "input*:*:scrolllock"
+Good: "input*:*:numlock"
+
+Set of common keyboard LEDs, going back to PC AT or so.
+
+Bad: "tpacpi::thinklight" (IBM/Lenovo Thinkpads)
+Bad: "lp5523:kb{1,2,3,4,5,6,7}" (Nokia N900)
+
+Keyboard frontlight/backlight.
+
+* Sound subsystem
+
+Good: "platform:*:mute"
+Good: "platform:*:micmute"
+
+LEDs on notebook body, indicating that sound input / output is muted.
+
+* System notification
+
+Good: "status-led:{red,green,blue}" (Motorola Droid 4)
+Bad: "lp5523:{r,g,b}" (Nokia N900)
+
+Phones usually have multi-color status LED.



-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] [PATCH 0/6] Introduce audio-mute LED trigger (and conversions to it)

[Pavel Machek]

Hi!

> > If external USB keyboard is identified as "input7" device, then
> > "input7::mute" is a good name for mute key. But "sys::mute" does not say
> > anything to which device or hardware it belongs nor does not solve
> > problem that which device/driver/subsystem should have privilege to take
> > this "sys" name.
> 
> How about just "platform" for the LEDs being part of the device
> on which the system is running?

"platform" works for me.

Are we in agreement that this name will be used for all similar LEDs,
as long as they are on the "main box" of the device, no matter if they
are connected using acpi, gpio, i2c, ...?

Should we start Documentation file explaining common names we want
people to use?

Thanks,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] [PATCH 0/6] Introduce audio-mute LED trigger (and conversions to it)

[Pavel Machek]

Hi!

> > > >> A nice godfather is required here...
> > > > 
> > > > Just use sys:: :-).
> > > > 
> > > > laptop:: would work for me, too. (It is always laptop in the cases we
> > > > are handling now, right?)
> > > > 
> > > > When we get a keyboard with mute led, we'll have to decide if it
> > > > should be input6::mute -- because it is on keyboard, or if it is
> > > > sys::mute -- because the key is expected to mute whole system.
> > > 
> > > drivers/input/input-leds.c seems to already support mute LED.
> > > It will be exposed as inputN::mute.
> > > 
> > > Documentation/leds/leds-class.txt defines LED naming pattern
> > > to  and "sys" does not look as
> > > something resembling device name.
> > 
> > So what is your suggestion?
> 
> I guess we should follow documentation. Or update documentation if it
> does not make sense to follow it.

That's actually in progress. Let me and Jacek deal with it. We don't
need great "how to name a LED" discussion here (google: bike shed paiting).

> > I don't care much as long as it is same in tpacpi and dell
> > case. (Neither are device names, btw :-).
> > 
> > Actually "::mute" would make sense, too.
> 
> "::mute" is not a good idea due to name uniqueness.
> 
> In case you would have two drivers which both provides "mute" led, then
> they need to have different name. Reason also why generic name "sys" is
> not a good idea.

> I think that driver name or subsystem name would be usable together with
> number.
> 
> Userspace application would be probably interested to distinguish
> between "mute led which is part of laptop" and "mute led which is
> available on external USB keyboard".
> 
> If external USB keyboard is identified as "input7" device, then
> "input7::mute" is a good name for mute key. But "sys::mute" does not say
> anything to which device or hardware it belongs nor does not solve
> problem that which device/driver/subsystem should have privilege to take
> this "sys" name.

Well, "sys" says this is system-wide mute LED. There are not expected
to be two of those, and there never will be, with the drivers
currently proposed.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] [PATCH 0/6] Introduce audio-mute LED trigger (and conversions to it)

[Pavel Machek]

Hi!

>  Looks good... except one detail: you have "tpacpi::micmute" and
>  "dell::micmute". I know it follows "tradition", but we are trying to
>  fix that at the moment. Laptop micmute button is a laptop micmute
>  button, and userspace should not need to know what prefix to use
>  depending on vendor.
> 
>  I'd suggest using "sys::micmute".
> >>>
> >>> I can imagine that in future some devices like keyboards would have also
> >>> mute led. We already have keyboards with mute key, so it is something
> >>> not unrealistic. What should be name convention for these mute leds?
> >>>
> >>> Is not "sys::" prefix too generic?
> >>
> >> Good point.  I thought of "laptop::" but it's not always laptop.
> >> "builtin::"?  Doesn't sound great, either.
> >>
> >> A nice godfather is required here...
> > 
> > Just use sys:: :-).
> > 
> > laptop:: would work for me, too. (It is always laptop in the cases we
> > are handling now, right?)
> > 
> > When we get a keyboard with mute led, we'll have to decide if it
> > should be input6::mute -- because it is on keyboard, or if it is
> > sys::mute -- because the key is expected to mute whole system.
> 
> drivers/input/input-leds.c seems to already support mute LED.
> It will be exposed as inputN::mute.
> 
> Documentation/leds/leds-class.txt defines LED naming pattern
> to  and "sys" does not look as
> something resembling device name.

So what is your suggestion?

I don't care much as long as it is same in tpacpi and dell
case. (Neither are device names, btw :-).

Actually "::mute" would make sense, too.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] [PATCH 0/6] Introduce audio-mute LED trigger (and conversions to it)

[Pavel Machek]

On Wed 2018-11-28 12:38:19, Takashi Iwai wrote:
> On Wed, 28 Nov 2018 12:18:06 +0100,
> Pali Rohár wrote:
> > 
> > On Tuesday 27 November 2018 09:44:18 Pavel Machek wrote:
> > > Looks good... except one detail: you have "tpacpi::micmute" and
> > > "dell::micmute". I know it follows "tradition", but we are trying to
> > > fix that at the moment. Laptop micmute button is a laptop micmute
> > > button, and userspace should not need to know what prefix to use
> > > depending on vendor.
> > > 
> > > I'd suggest using "sys::micmute".
> > 
> > I can imagine that in future some devices like keyboards would have also
> > mute led. We already have keyboards with mute key, so it is something
> > not unrealistic. What should be name convention for these mute leds?
> > 
> > Is not "sys::" prefix too generic?
> 
> Good point.  I thought of "laptop::" but it's not always laptop.
> "builtin::"?  Doesn't sound great, either.
> 
> A nice godfather is required here...

Just use sys:: :-).

laptop:: would work for me, too. (It is always laptop in the cases we
are handling now, right?)

When we get a keyboard with mute led, we'll have to decide if it
should be input6::mute -- because it is on keyboard, or if it is
sys::mute -- because the key is expected to mute whole system.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] [PATCH 0/6] Introduce audio-mute LED trigger (and conversions to it)

[Pavel Machek]

Hi!

> this is patch series I've hacked after useful conversation with
> Pavel.  Basically this adds a new LED trigger audio-mute and
> audio-micmute, and convert the HD-audio driver and the platform
> drivers to use the LED trigger instead of the ugly direct dynamic
> symbol binding.

Thanks a lot for doing this!

> The latest version of patches are found in topic/leds-trigger branch
> in my sound git tree.
>   git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
> 
> As these are cross-tree patches, the branch above is based cleanly on
> v4.20-rc3, so that it can be merged well to multiple trees.
> 
> Once after getting the ACK's, I'll add tags and fixate for merges.
> 
> This patch series don't include huawei-wmi stuff; so Huawei patches
> need rework.  I already have some piece of changes for huawei-wmi, so
> please ping me if needed.
> 
> I checked briefly on my Dell laptop, and a Thinkpad model.
> Wider tests are appreciated, of course.

Looks good... except one detail: you have "tpacpi::micmute" and
"dell::micmute". I know it follows "tradition", but we are trying to
fix that at the moment. Laptop micmute button is a laptop micmute
button, and userspace should not need to know what prefix to use
depending on vendor.

I'd suggest using "sys::micmute".

With that:

Acked-by: Pavel Machek 

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] ThinkPad T480s & LED_MUTE, LED_MICMUTE

[Pavel Machek]

Hi!

> > Question is if we want flexibility or security.
> 
> For thinkpad-acpi, it is security by default.  Flexibility is allowed as
> *compile*-time (Kconfig) option, and only as long as it defaults to
> secure *and* the help text is very explicit at instructing distros to
> NOT enable this option.

Yep, no problem with that.

> That said, if mic-mute is under HDA mixer control, it will only be
> "secure" if ALSA is also blocking userspace access to the relevant bits,
> and if that is not possible to do properly, might as well go for
> flexibility.  But only in that case.

That also makes sense.

> That would be why I use phisical shutters on embedded webcams unless the
> hardware actually airgaps them from the USB bus when the privacy switch
> is active.

And yes, I use them, too.
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] ThinkPad T480s & LED_MUTE, LED_MICMUTE

[Pavel Machek]

Hi!

On Fri 2018-06-15 20:36:28, Henrique de Moraes Holschuh wrote:
> On Fri, 15 Jun 2018, Pali Rohár wrote:
> > This means that kernel should not export any led class device. Or when
> > exported, then "set" operation should always fail.
> 
> "not export" is right.
> 
> > > 2. Otherwise implement it in-kernel, so that userspace cannot unmute
> > >when the human has activated the "mute" switch, and the LED cannot be
> > >controlled by userspace to lie (report mute when it is not mute).
> > 
> > This looks like a good candidate to use led "trigger" interface. Create
> > a mute trigger and attach it to that led device.
> 
> Maybe, as long as done in-kernel and not possible to mess with from
> userspace.

Question is if we want flexibility or security.

If we want security, going through LED subsystem makes no sense, just
control the LED as hardware would, or let hardware do it.

For full flexibility, just export the LED and use normal mechanisms we
have (such as triggers). root should be allowed to configure the LEDs,
and he can change the kernel, too, so...

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] ThinkPad T480s & LED_MUTE, LED_MICMUTE

[Pavel Machek]

Hi!

> Hi! With up-to-date thinkpad_acpi.ko driver on ThinkPad T480s I'm seeing
> a strange behavior of LEDs which are integrated into mic mute (Fn+F4)
> and mute (Fn+F1) keys.
> 
> When thinkpad_acpi.ko is not loaded, then mute key is working fine. When
> pressed, it correctly generates KEY_MUTE on AT Translated Set 2 keyboard
> input device and also turn on/of mute led. But when micmute key is
> pressed then, nothing happen. No key event is reported and also led is
> not turned on/off.
> 
> On the other hand, when thinkpad_acpi.ko is loaded, then both buttons
> mute and micmute correctly generates input events; mute via AT keyboard
> and micmute via ThinkPad Extra Buttons. But led is not changed. When
> thinkpad_acpi.ko is loaded it turn off both leds (mute and micmute) and
> leds after pressing any of those buttons, leds are not turned on again.

With thinkpad_acpi.ko loaded, kernel should handle the LEDs, right? Do
we have a support for that? Do they have directories in
/sys/class/leds? What are the triggers there?

With thinkpad_acpi.ko unloaded, hardware drives the LEDs, so nothing
for us to do...

   Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] [PATCH 2/3 v5] battery: Add the ThinkPad "Not Charging" quirk

[Pavel Machek]

On Sun 2017-12-10 19:05:29, Ognjen Galic wrote:
> The EC/ACPI firmware on Lenovo ThinkPads used to report a status
> of "Unknown" when the battery is between the charge start and
> charge stop thresholds. On Windows, it reports "Not Charging"
> so the quirk has been added to also report correctly.
> 
> Now the "status" attribute returns "Not Charging" when the
> battery on ThinkPads is not physicaly charging.
> 
> Tested-by: Kevin Locke 
> Tested-by: Christoph Böhmwalder 
> Signed-off-by: Ognjen Galic 

As mentioned before, it would be nice to add a state "not charging for
battery lifetime reasons" and use it here.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] [PATCH v2] thinkpad_acpi: Support the battery wear control

[Pavel Machek]

On Sat 2017-12-09 11:29:51, Ognjen Galić wrote:
> On 09/12/2017, Pavel Machek <pa...@ucw.cz> wrote:
> > In newer series (I can't find it at the moment, sorry)
> 
> The new series is a 3-patch patchset that obsoletes this
> patch. It is in the testing stage and will be pushed to
> the mailing lists and maintainers in a few days.
> 
> > Maybe we should have separate status "not charging due to wear
> > control"?
> 
> No, because the ACPI battery driver is a extension to the generic
> power supply driver, that does not understand the battery wear control.
> Also, Rafael specifically noted NOT to include any thinkpad_acpi-specific
> behavior to the generic drivers.

Yeah, what I'm saying is that maybe we need to extend generic power
supply driver.

On small devices, we usually have enough control over hardware to be
able to implement "wear control" in kernel. Nokia N900 is an
example. "Wear control" is certainly not thinkpad-specific concept.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] [PATCH v2] thinkpad_acpi: Support the battery wear control

[Pavel Machek]

Hi!

In newer series (I can't find it at the moment, sorry) you return
"NOT_CHARGING" status when not charging because of wear control.

Maybe we should have separate status "not charging due to wear
control"?

Thanks,

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] [PATCH 1/1] thinkpad_acpi: Add support for status (external cover) LED

[Pavel Machek]

On Sun 2017-05-07 20:49:03, Henrique de Moraes Holschuh wrote:
> On Sun, 07 May 2017, Pavel Machek wrote:
> > On Thu 2017-01-19 12:21:32, Adam Goode wrote:
> > > This allows the control of the red status LED, which is the dot of the "i"
> > > in the word "ThinkPad" on the outside cover of newer models.
> > > 
> > > In the manual, both this LED and the power LED are referred to as
> > > the "system-status indicators" without distinction between the two, so
> > > I chose "status" as the LED name.
> > 
> > Could we name it something like external_status or something? "status" is 
> > way too generic.
> 
> "thinkdot" ;-)

Sounds good to me ;-).

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] [PATCH 1/1] thinkpad_acpi: Add support for status (external cover) LED

[Pavel Machek]

On Thu 2017-01-19 12:21:32, Adam Goode wrote:
> This allows the control of the red status LED, which is the dot of the "i"
> in the word "ThinkPad" on the outside cover of newer models.
> 
> In the manual, both this LED and the power LED are referred to as
> the "system-status indicators" without distinction between the two, so
> I chose "status" as the LED name.

Could we name it something like external_status or something? "status" is way 
too generic.


Pavel
> 
> Signed-off-by: Adam Goode 
> 
> diff --git a/drivers/platform/x86/thinkpad_acpi.c 
> b/drivers/platform/x86/thinkpad_acpi.c
> index cacb43fb1df7..6577bf8e5635 100644
> --- a/drivers/platform/x86/thinkpad_acpi.c
> +++ b/drivers/platform/x86/thinkpad_acpi.c
> @@ -5611,11 +5611,11 @@ static const char * const 
> tpacpi_led_names[TPACPI_LED_NUMLEDS] = {
>   "tpacpi::standby",
>   "tpacpi::dock_status1",
>   "tpacpi::dock_status2",
> - "tpacpi::unknown_led2",
> + "tpacpi::status",
>   "tpacpi::unknown_led3",
>   "tpacpi::thinkvantage",
>  };
> -#define TPACPI_SAFE_LEDS 0x1081U
> +#define TPACPI_SAFE_LEDS 0x1481U
>  
>  static inline bool tpacpi_is_led_restricted(const unsigned int led)
>  {
> -- 
> 2.11.0.390.gc69c2f50cf-goog

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] [PATCH v5 2/6] leds: triggers: Add a keyboard backlight trigger

[Pavel Machek]

Hi!

> >> There might exist users that adjust LED brightness while having
> >> active trigger. The best example is default-on trigger - it sets
> >> brightness only on init, but remains active all the time. Whereas
> >> this could be fixed, there is another case: think of changing blinking
> >> brightness - it would be impossible.
> > 
> > I don't see the breakage. For existing blinking and default-on
> > triggers, existing behaviour would be kept. Difference would be that
> > for hardware that changes triggers itself (like the keyboard light) we
> > would present it as a trigger. And you are right -- there would be
> > user visible changes there. You could not assign blinking, because
> > .. it already has a trigger. But I believe it is reasonable.
> 
> We've already received negative feedback regarding blocking
> application of different trigger when hw brightness change
> notifications

Actually sometimes we'll get negative feedback for anything we do. I
still believe exposing the backlight case as a trigger is a right thing.

> are enabled. One solution to that is making the notifications
> orthogonal to the trigger mechanism. The other possibility is to allow
> for having more than one active trigger for a LED.
> 
> We could think of defining a special type of persistent trigger that
> would be always enabled.

Yes, that could be done. I'd not call it persistent trigger, but
with right name...

#1:

Apparently some LEDs change themselves, and we can't find how or
when. That's thinkpad battery LED, for example.

#2:

Then there are some LEDs that change themselves, and we can get
notifications. We should make it very clear that we'll not send
notifications kernel did itself.

So... for #1 and #2 something like

led/hardware_changes_brightness 

and for #2

led/poll_for_hardware_brightness_change

where poll() wakes the userspace up when the brightness changes, and
read() can get new brightness...?
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] s2disk broken at a ThinkPad since 4.6.5

[Pavel Machek]

On Sat 2016-11-26 15:00:17, Toralf Förster wrote:
> On 11/26/2016 02:16 PM, Pavel Machek wrote:
> > Any chance to try 4.9?
> > Pavel
> sure - 4.9-rc6 is fine, both undocked and docked system allows hibernating

Ok, thanks for the info.

From my side... debugging 4.6 does not seem terribly important. If you
want to do it, git bisect is probably the way...

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
--
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] s2disk broken at a ThinkPad since 4.6.5

[Pavel Machek]

On Sat 2016-10-29 11:33:06, Toralf Förster wrote:
> This is a hardened stable Gentoo Linux ThinkPad T440s.
> After wakeup from s2disk the console stays at line "clocksource: tsc: mask:" 
> forever.
> 
> FWIW (and maby completely unrelated) I do wonder why since that version I do 
> have a dmesg line :
>   amd_nb: Cannot enumerate AMD northbridges
> 
> The hardened kernel 4.5.7 was fine.
> 

Any chance to try 4.9?
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] [PATCH v5 2/6] leds: triggers: Add a keyboard backlight trigger

[Pavel Machek]

Hi!

> >>Triggers are not limited to periodic blinking or reporting cpu
> >>activity. There is also oneshot trigger that can be used e.g. when
> >>user touches the screen, as Pali mentioned.
> >
> >Using oneshot trigger for this would be pretty strange.
> 
> It was only an example to mention other than periodic triggers.
> You could have a trigger that just turns the LED permanently on
> after user touches the screen.

Well.. triggers kind of assume they control the LED. They were not
prepared to deal with hardware changing the brightness behind their
back.

> >Notice that in
> >some cases (thinkpad battery led, for example) we either have firmware
> >controls the LED (but then software can't control it) or we have
> >software controlling the LED (but then we don't know what firmware
> >would put there). Maybe keyboard backlight can be controlled
> >"simultaneously" by both software and firmware, but there are
> >certainly LEDs that can't handle that, and IMO it would be nice to
> >have same interface.
> >
> >>>Well.. actually... I think this is a little bit over complex and
> >>>probably unneccessary. I'd let Hans implement whatever he thinks is
> >>>easiest.
> >>
> >>I'd say this is the trigger approach which is a bit convoluted.
> >
> >In my eyes trigger approach is neccessary at least for some hardware,
> >and things it pretty clear: trigger on == LED changes without
> >userspace involvement. trigger off == userspace controls the LED.
> 
> It is likely that it would break many existing users.

Can you elaborate on that?

I just tried with leds on thinkpad

root@duo:/sys/class/leds/tpacpi::power# echo 1 > brightness
root@duo:/sys/class/leds/tpacpi::power# echo 0 > brightness
root@duo:/sys/class/leds/tpacpi::power# cat trigger
[none] bluetooth-power kbd-scrollock kbd-numlock kbd-capslock
kbd-kanalock kbd-shiftlock kbd-altgrlock kbd-ctrllock kbd-altlock
kbd-shiftllock kbd-shiftrlock kbd-ctrlllock kbd-ctrlrlock AC-online
BAT0-charging-or-full BAT0-charging BAT0-full
BAT0-charging-blink-full-solid rfkill0 phy0rx phy0tx phy0assoc
phy0radio phy0tpt mmc0 timer pattern rfkill1 hci0-power rfkill74
heartbeat
root@duo:/sys/class/leds/tpacpi::power#

I can control the LED from userspace, but then there's no way to put
the LED back to firmware control. That's just broken.

Do you have a proposal how to handle that?

> >So I'd do the trigger here. It is same way we can handle LEDs on
> >thinkpad. Yes, it means you won't be able to do oneshot trigger on
> >backlight. I don't think that's a huge problem.
> 
> There have been voices in this discussion claiming the opposite. :-)

Well, lets ignore those voices until the voices understand the current
design :-).

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
--
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] [PATCH v5 2/6] leds: triggers: Add a keyboard backlight trigger

[Pavel Machek]

Hi!

> >Lets keep it simple. Yes, monitoring backlight state while hardware
> >updates it is useful. But doing the monitor when some kind of blinking
> >from the kernel is active is just a unneccessary complexity...
> 
> Triggers are not limited to periodic blinking or reporting cpu
> activity. There is also oneshot trigger that can be used e.g. when
> user touches the screen, as Pali mentioned.

Using oneshot trigger for this would be pretty strange. Notice that in
some cases (thinkpad battery led, for example) we either have firmware
controls the LED (but then software can't control it) or we have
software controlling the LED (but then we don't know what firmware
would put there). Maybe keyboard backlight can be controlled
"simultaneously" by both software and firmware, but there are
certainly LEDs that can't handle that, and IMO it would be nice to
have same interface.

> >Well.. actually... I think this is a little bit over complex and
> >probably unneccessary. I'd let Hans implement whatever he thinks is
> >easiest.
> 
> I'd say this is the trigger approach which is a bit convoluted.

In my eyes trigger approach is neccessary at least for some hardware,
and things it pretty clear: trigger on == LED changes without
userspace involvement. trigger off == userspace controls the LED.

So I'd do the trigger here. It is same way we can handle LEDs on
thinkpad. Yes, it means you won't be able to do oneshot trigger on
backlight. I don't think that's a huge problem.

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
--
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] [PATCH v5 2/6] leds: triggers: Add a keyboard backlight trigger

[Pavel Machek]

Hi!

> > As for the modeling how the hotkey controls the LED as a trigger,
> > although I do like this from one pov, I can see Jacek's point that
> > this is confusing as there really is nothing to configure here,
> > where as normally a user could do "echo none > trigger" to break
> > the link. So I think that is best (cleanest /minimal non confusing
> > API) with just the hw_brightness_change sysfs-attribute and not
> > model this as a trigger.
> 
> I can accept with this solution (no trigger, event on new sysfs file 
> which returns current/actual brightness state, new sysfs file only for 
> devices which can report brightness state).
> 
> But I'm not sure if it is really fixing that original problem with high 
> power usage...

Yes, it is fixing that problem.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
--
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] [PATCH v5 2/6] leds: triggers: Add a keyboard backlight trigger

[Pavel Machek]

Hi!

> >>In view of the above we could report hw brightness changes with POLLPRI
> >>on brightness file, but unfortunately we can't because it is impossible
> >>to guarantee that readout of brightness file will return the brightness
> >>the POLLPRI was meant to notify about.
> >
> >Agreed here.
> >
> >>That's why a separate read only file seems to be the only proper
> >>solution.
> >
> >Yes please. And lets make self-changing leds into a trigger, as
> >proposed, and as Hans' patch should be already doing.
> 
> We can set one trigger at a time. In this case it will be impossible
> to have hw brightness change notifications while other trigger is
> active.

And that is a _good_ thing. We don't want to deal with "echo heartbeat
> kbd_backlight_trigger" and then asking for hardware brightness
changes.

Lets keep it simple. Yes, monitoring backlight state while hardware
updates it is useful. But doing the monitor when some kind of blinking
from the kernel is active is just a unneccessary complexity...

> >>Moreover, the file should return the brightness from the time
> >>of last POLLPRI.
> >
> >Not sure I agree here. Normally, kernel returns current state for
> >variables, does not track "old" state.
> 
> It would report current state. The file called hw_brightness_change
> should report last brightness change originating from hardware.
> The most recent hw brightness change is still current state from
> this perspective. It will be valid until next hw brightness change
> occurs.
> 
> Current state does not mean current brightness in this case.

Well.. actually... I think this is a little bit over complex and
probably unneccessary. I'd let Hans implement whatever he thinks is
easiest.

Best regards,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
--
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] [PATCH v5 2/6] leds: triggers: Add a keyboard backlight trigger

[Pavel Machek]

On Mon 2016-11-21 10:31:33, Hans de Goede wrote:
> Hi,
> 
> On 21-11-16 09:35, Jacek Anaszewski wrote:
> >On 11/20/2016 04:05 PM, Pali Rohár wrote:
> >>On Saturday 19 November 2016 16:44:09 Jacek Anaszewski wrote:
> >>>Hi,
> >>>
> >>>On 11/18/2016 07:47 PM, Hans de Goede wrote:
> >>>>HI,
> >>>>
> >>>>On 18-11-16 17:03, Jacek Anaszewski wrote:
> >>>>>Hi,
> >>>>>
> >>>>>On 11/18/2016 10:07 AM, Hans de Goede wrote:
> >>>>>>Hi,
> >>>>>>
> >>>>>>On 18-11-16 09:55, Jacek Anaszewski wrote:
> >>>>>>>Hi Hans,
> >>>>>>>
> >>>>>>>Thanks for the patch.
> >>>>>>>
> >>>>>>>I think we need less generic trigger name.
> >>>>>>>With present name we pretend that all kbd-backlight controllers
> >>>>>>>can change LED brightness autonomously.
> >>>>>>>
> >>>>>>>How about kbd-backlight-pollable ?
> >>>>>>
> >>>>>>This is a trigger to control kbd-backlights, in the
> >>>>>>current use-case the brightness change is already done
> >>>>>>by the firmware, hence the set_brightness argument to
> >>>>>>ledtrig_kbd_backlight(), so that we can avoid setting
> >>>>>>it again.
> >>>>>>
> >>>>>>But I can see future cases where we do want to have some
> >>>>>>event (e.g. a wmi hotkey event on a laptop where the firmware
> >>>>>>does not do the adjustment automatically) which does
> >>>>>>lead to actually updating the brightness.
> >>>>>>
> >>>>>>So I decided to go with a generic kbd-backlight trigger,
> >>>>>>which in the future can also be used to directly control
> >>>>>>kbd-backlight brightness; and not just to make ot
> >>>>>>poll-able.
> >>>>>
> >>>>>I thought that kbd-backlight stands for "keyboard backlight",
> >>>>
> >>>>It does.
> >>>>
> >>>>>that's why I assessed it is too generic.
> >>>>
> >>>>The whole purpose of the trigger as implemented is to be
> >>>>generic, as it seems senseless to implement a one off
> >>>>trigger for just the dell / thinkpad case.
> >>>>
> >>>>>It seems however to be
> >>>>>the other way round - if kbd-backlight means that this is
> >>>>>a trigger only for use with dell-laptop keyboard driver
> >>>>>(I see kbd namespacing prefix in the driver functions) than it is
> >>>>>not generic at all.
> >>>>
> >>>>The trigger as implemented is generic, if you think
> >>>>otherwise, please let me know which part is not generic
> >>>>according to you.
> >>>
> >>>I think I was too meticulous here. In the end of the previous
> >>>message I mentioned that we cannot guarantee that all keyboard
> >>>backlight controllers can adjust brightness autonomously.
> >>>Nonetheless, for the ones that cannot do that it would make no sense
> >>>to have a trigger. In view of that this trigger is generic enough.
> >>>
> >>>I'll wait for Pavel's opinion before merging the patch set
> >>>as he was also involved in this whole thread.
> >>
> >>Do you mean me? Or Pavel Machek (CCed) who was involved in LEDs for input 
> >>devices?
> >
> >I meant Pavel Machek, I haven't known that Pali is an equivalent of
> >Pavel :-)
> >Your opinion is very much appreciated though, thanks.
> >
> >>As pointed in other email, we do not know if HW really controls keyboard 
> >>backlight,
> >>so adding "fake" trigger on machines without HW control is not a good idea.
> >>
> >
> >Yes, I had also similar doubts, but got almost convinced due to
> >no objections. Now it becomes clear that we need to improve this
> >feature.
> 
> But we are not adding such a fake trigger. We are only setting up the
> kbd-backlight trigger on systems where there actually is hw-control.
> 
> Sure someone can do echo "kbd-backlight" > trigger to enable it,
> but the same is true for e.g. "mtd" or "nand-disk" on systems
> without an mtd-device / a nand-disk, and the result is the same,
> the LED gets coupled to the trigger, but nothing ever triggers
> the trigger.

We can do that, yes.

Alternatively, we could do some magic so that kbd-backlight trigger is
not available for other leds, and that _only_ kbd-backlight trigger is
available for leds that are always controlled by the hardware. But we
can do that in future patch...

> I really believe that we have the right design now (I was skeptical
> about the trigger approach at first, but it has turned out really
> well) and unless Pavel Machek has any objections I would really like
> patches 1-2 of this series merged.

I certainly like the interface from thedescription.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
--
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] [PATCH v5 2/6] leds: triggers: Add a keyboard backlight trigger

[Pavel Machek]

Hi!

> In view of the above we could report hw brightness changes with POLLPRI
> on brightness file, but unfortunately we can't because it is impossible
> to guarantee that readout of brightness file will return the brightness
> the POLLPRI was meant to notify about.

Agreed here.

> That's why a separate read only file seems to be the only proper
> solution.

Yes please. And lets make self-changing leds into a trigger, as
proposed, and as Hans' patch should be already doing.

> Moreover, the file should return the brightness from the time
> of last POLLPRI.

Not sure I agree here. Normally, kernel returns current state for
variables, does not track "old" state.

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
--
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] [PATCH v5 2/6] leds: triggers: Add a keyboard backlight trigger

[Pavel Machek]

On Thu 2016-11-24 16:36:51, Pali Rohár wrote:
> On Thursday 24 November 2016 16:32:06 Jacek Anaszewski wrote:
> > Since it has been reported that POLLPRI notifications on brightness
> > file can lead to increased power consumption, and having my above
> > statement I don't think that it is a good idea to use brightness
> > file for this.
> 
> How is brightness file different from others that it cannot issue
> POLLPRI notification?

Reading "brightness" may or may not give you current brightness of the
led, depending on hardware limitations -- and you can't know. (It may
give you maximum brightness of trigger)

Reading "hw_current_brightness" file (if present) will give you
current brightness. In addition, it is pollable.
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
--
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] [PATCH v5 2/6] leds: triggers: Add a keyboard backlight trigger

[Pavel Machek]

On Thu 2016-11-24 10:15:25, Pali Rohár wrote:
> On Wednesday 23 November 2016 12:01:02 Jacek Anaszewski wrote:
> > I would also appreciate your opinion on the other solution to the
> > problem of notifying brightness changes originating from hardware,
> > i.e. hw_brightness_change{_ro} file, that would support POLLPRI events,
> > and reading brightness.
> 
> Another idea:
> 
> If no trigger is active then led subsystem will invoke POLLPRI on
> "brightness" sysfs file.
> 
> And if there is active trigger then only trigger code could invoke
> POLLPRI on "brightness" file.

That would mess up interface even more. Sorry.

> Do not know if this is really enough for your situation, it is just and
> another idea.

We don't need another ideas at the moment, unless they are better than
proposed solution.

Thanks,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
--
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] [PATCH v5 2/6] leds: triggers: Add a keyboard backlight trigger

[Pavel Machek]

Hi!

> As pointed in other email, we do not know if HW really controls keyboard 
> backlight,
> so adding "fake" trigger on machines without HW control is not a good 
> idea.
> >>>
> >>>Well, if we know that hardware will not change the brightness on its
> >>>own, yes, I'd avoid the trigger. If we don't know (as is common on
> >>>ACPI machines, I'd keep the trigger).
> >>
> >>I'd drop the trigger approach due to the mess it can make in peoples'
> >>minds due to the fact that LED class device handles trigger events
> >>generated by itself.
> >
> >We can teach people. IMO the LED that changes itself is special, and
> >trigger explains that nicely to the userspace. Plus, it allows us to
> >keep this functionality out of the core.
> 
> Please refer to the downsides of this appraoch:
> 
> - lack of information if given LED class device supports hw
>   generated POLLPRI events

Userspace can plainly see that a trigger is active, and knows to
expect 

> - impossible to apply other trigger while polling

That's a good thing. We _don't_ want polling to be active when trigger
such as "CPU active" is active. We want userspace to monitor hardware
events but not software ones.

> >>I'd add a file hw_brightness_change or async_brightness or something
> >>similar and make it only readable/pollable. current_brightness is
> >>ambiguous and questionable.
> >
> >Well, exact name is not too important...
> 
> The name should clearly explain the file purpose. I bet that we would
> see many questions once the file appeared in the mainline.
> Also, I'm afraid that I wouldn't be able to explain this name in
> few simple words, without daunting the listener, or even triggering
> the discussion on brightness shortcomings we've already gone through.

Well, feel free to suggest non-confusing name.

Unfortunately, yes, we'll need to do some explaining, as existing
"brightness" behaviour is already pretty tricky / confusing /
counterintuitive.

Lets at least make sure new additions are clean and simple.

Thanks,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
--
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] [PATCH v5 1/6] leds: triggers: Add current_brightness trigger parameter

[Pavel Machek]

On Mon 2016-11-21 00:07:35, Pali Rohár wrote:
> On Thursday 17 November 2016 23:24:36 Hans de Goede wrote:
> > In some cases it may be desirable for userspace to be notified when
> > a trigger event happens. This commit adds support for a poll-able
> > current_brightness trigger specific sysfs attribute which triggers
> > may register:
> > 
> > What:   /sys/class/leds//current_brightness
> 
> What about name actual_brightness? That name is already used by 
> /sys/class/backlight/...

Is that a problem?
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
--
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] [PATCH v5 1/6] leds: triggers: Add current_brightness trigger parameter

[Pavel Machek]

Hi!

> > > If I understood correctly we need to handle two things:
> > > 
> > > 1) Provide poll() for userspace when LED level is changed (either
> > > by HW
> > > 
> > >or other user call)
> > > 
> > > 2) Deal with fact that on _some_ hardware, special key is hardwired
> > > to
> > > 
> > >change LED level
> > > 
> > > So why for 1) we cannot use existing sysfs file "brightness"? I do
> > > not see any problem with it.
> > 
> > That was our first attempt at this, but because the brightness may
> > also be changed by triggers / blink-timers, we need to wakeup poll()
> > in those cases too (anything else would be inconsistent) and doing
> > such a wakeup in that case has turned out to cause too much overhead
> > in some cases (even if userspace is not listening), specifically the
> > idle power uses on some systems got multiplied by a factor of 5 or
> > more.
> > 
> > So this approach was rejected.
> 
> But approach with exporting new sysfs file with name current_brightness 
> with existence of old brightness sysfs file is not good and in my 
> opinion it is even worst as current situation (= without poll
> support).

It is neccessary, see the current discussion.

> What happen in next 5 years? Somebody point that sysfs file "brightness" 

current_brightness will only appear on machines and in situations,
where we, well, can report current brightness. When you read
"brightness" file, you don't know if you are getting current
brightness or not, and it can't be changed easily.

Please go through the discussion. This design was chosen for a reason.

Thanks,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
--
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] [PATCH v5 2/6] leds: triggers: Add a keyboard backlight trigger

[Pavel Machek]

Hi!

> >  Thanks for the patch.
> >  
> >  I think we need less generic trigger name.
> >  With present name we pretend that all kbd-backlight controllers
> >  can change LED brightness autonomously.
> >  
> >  How about kbd-backlight-pollable ?
> > >>> 
> > >>> This is a trigger to control kbd-backlights, in the
> > >>> current use-case the brightness change is already done
> > >>> by the firmware, hence the set_brightness argument to
> > >>> ledtrig_kbd_backlight(), so that we can avoid setting
> > >>> it again.
> > >>> 
> > >>> But I can see future cases where we do want to have some
> > >>> event (e.g. a wmi hotkey event on a laptop where the firmware
> > >>> does not do the adjustment automatically) which does
> > >>> lead to actually updating the brightness.
> > >>> 
> > >>> So I decided to go with a generic kbd-backlight trigger,
> > >>> which in the future can also be used to directly control
> > >>> kbd-backlight brightness; and not just to make ot
> > >>> poll-able.
> > >> 
> > >> I thought that kbd-backlight stands for "keyboard backlight",
> > > 
> > > It does.
> > > 
> > >> that's why I assessed it is too generic.
> > > 
> > > The whole purpose of the trigger as implemented is to be
> > > generic, as it seems senseless to implement a one off
> > > trigger for just the dell / thinkpad case.
> > > 
> > >> It seems however to be
> > >> the other way round - if kbd-backlight means that this is
> > >> a trigger only for use with dell-laptop keyboard driver
> > >> (I see kbd namespacing prefix in the driver functions) than it is
> > >> not generic at all.
> > > 
> > > The trigger as implemented is generic, if you think
> > > otherwise, please let me know which part is not generic
> > > according to you.
> > 
> > I think I was too meticulous here. In the end of the previous
> > message I mentioned that we cannot guarantee that all keyboard
> > backlight controllers can adjust brightness autonomously.
> > Nonetheless, for the ones that cannot do that it would make no sense
> > to have a trigger. In view of that this trigger is generic enough.
> > 
> > I'll wait for Pavel's opinion before merging the patch set
> > as he was also involved in this whole thread.

If we have a keyboard backlight that may be changed automatically, I'd
go for trigger. If we know for sure that hardware will not change
brightnes "on its own", I'd not put a trigger there (and polling makes
no sense). If we don't know... I guess I'd go for trigger.

We can do various white/blacklists if we really want to..

> As pointed in other email, we do not know if HW really controls keyboard 
> backlight,
> so adding "fake" trigger on machines without HW control is not a good idea.

Well, if we know that hardware will not change the brightness on its
own, yes, I'd avoid the trigger. If we don't know (as is common on
ACPI machines, I'd keep the trigger).

Best regards,

   Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
--
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

[ibm-acpi-devel] 6ea8c546f3655 breaks thermal management on thinkpad x60 and t40p

[Pavel Machek]

Hi!

Bisection was not fun, but I've got the result:

# first bad commit: [6ea8c546f3655a81f82672f24b66dad6095bdd07] ACPICA:
FADT support cleanup

I've reverted the patch on top of 4.9-rc4, and thermal management now works.

More details are in https://bugzilla.kernel.org/show_bug.cgi?id=187311

As this breaks thermal management on both thinkpad X60 and T40p, can
I ask for a revert?

If you have other ideas, I can test them, but as this is just a
cleanup, it can wait for 4.10...

Thanks,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
--
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

[ibm-acpi-devel] thinkpad x60, T40p: overheat with v4.9-rc4 (was Re: v4.8-rc1: thinkpad x60: running at low frequency even during kernel build)

[Pavel Machek]

Hi!

Thanks to Srinivas, bug tracking moved to bugzilla at
https://bugzilla.kernel.org/show_bug.cgi?id=187311 , it is regression
from v4.8-final.

Easiest way to observe it is that cpufreq/bios_limit does not change
in v4.9, where it goes lower with high temperature on v4.8.

Best regards,

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] v4.8-rc1: thinkpad x60: running at low frequency even during kernel build

[Pavel Machek]

Hi!

BTW.. This machine has nasty habit of hanging during kernel boot when
it is "hot".. which makes reboots unplesant here. Ideas would be
welcome how to debug that.

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] v4.8-rc1: thinkpad x60: running at low frequency even during kernel build

[Pavel Machek]

On Sat 2016-11-05 16:04:58, Henrique de Moraes Holschuh wrote:
> On Sat, 05 Nov 2016, Pavel Machek wrote:
> > [  825.759661] thinkpad_acpi: THERMAL EMERGENCY: a sensor reports something 
> > is extremely hot!
> > [  825.761935] thinkpad_acpi: temperatures (Celsius): 101 49 N/A 78 33 N/A 
> > 33 N/A 47 50 N/A N/A N/A N/A N/A N/A
> 
> Oh boy, that must be the second time in a decade that I see that
> codepath triggering.  It is the second-level alert that the ThinkPad is
> about to catch fire.
> 
> It should have logged a "is too hot!" first-level alert earlier, but
> this depends on the EC and not the driver.  Maybe the temperature raised
> too fast.

I don't think I'm seeing the "is too hot" messages. Actually.. even
the "THERMAL EMERGENCY" messages seem to have too low severity, so
they are hidden in syslogs -- they don't go to all the consoles.

> In Windows, the system would attempt to hibernate or shutdown.  I would
> be quite happy to have thinkpad-acpi trigger such behavior as well,
> patches (or guidance) are welcome ;-)

Sorry, just guidance for now:

+#include 
+   orderly_poweroff(true);

[can be called from weird contexts, afaict]. 

> Anyway, if that temperature goes about 1~2°C higher, the EC should cut
> power to your motherboard.  Apparently, the built-in thermal protection
> clock modulation on the Intel processor is somehow saving your box from
> that forced power-off.

Actually, the machine _will_ shut down some time after that. It seems
that one of acpi trip points jumps to 128C which forces shutdown.

Thanks and best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] v4.8-rc1: thinkpad x60: running at low frequency even during kernel build

[Pavel Machek]

On Sat 2016-11-05 15:46:12, Henrique de Moraes Holschuh wrote:
> On Sat, 05 Nov 2016, Pavel Machek wrote:
> > Hmm, thanks for the pointer. But it seems like I'll have to build my
> > own, as /proc/acpi/ibm does not follow the usual infrastructure...
> 
> /proc/acpi/ibm has been deprecated for years.  99% of the functionality
> is available through more modern, standard interfaces.

Right, I see sensors can do it these days. Would it be good to expose
them as /sys/class/thermal/thermal_zone*, too?

Is it known what various fields in /proc/acpi/ibm/thermal measure?
Basically... 100C is okay for semiconductors, but I'd prefer not to
kill the hard drive

> thinkpad-acpi is supposed to export standard hwmon temperature sensors
> as well.  Try them instead, please.

Heh, I just finished python to work with /proc/acpi/ibm. Oh well.

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] v4.8-rc1: thinkpad x60: running at low frequency even during kernel build

[Pavel Machek]

Hi!

> > > Yes, this seems to work. scaling_max goes to 1.5, then 1.1. Also
> > > under
> > > load, scaling_max_freq changes. But at that point, we are already
> > > around 98C... and bios_limit stays the same all the time in v4.9.
> > 
> > ...while in v4.8-rc1, bios limit goes to 1.0 GHz at 90C, and
> > temperature just doesn't go above that.
> > 
> > Does it make sense to try with v4.8-final?
> I sent some suggestion to try in previous email to add more prints and
> enable debug in acpi-cpufreq. Let's try that first. We need to fix
> anyway even if 4.8-final has this issue.

Ok, you should have results in your mailbox now. If you want me to do
some more testing, let me know.

Thanks,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] v4.8-rc1: thinkpad x60: running at low frequency even during kernel build

[Pavel Machek]

Hi!

> > > > So we seem to have thermal or ACPI regression in v4.9-rc3.
> > > > 
> > > It is possible. Can you add either add printk
> > > in acpi_processor_ppc_has_changed() or use ftrace and see do you
> > > get to
> > > these functions
> > > 
> > > acpi_processor_ppc_init()
> > > acpi_processor_ppc_has_changed()
> > > acpi_processor_ppc_notifier()
> > > 
> > > ?
> > 
> > Yes, these seem to be called. Here's the log:

Ok, burnP6 pushes cpu to 102C rather quickly. dmesg is below.

Thanks,
Pavel

cpu:  scaling 1.0 1.0 1.8 cpuinfo 1.0 1.0 1.8 bios 1.8
  scaling 1.0 1.0 1.8 cpuinfo 1.0 1.0 1.8 bios 1.8
temp:  82 [65, 82, 65, 44, 66, 33, 33, 44, 51]
fan:  2874
cpu:  scaling 1.0 1.8 1.8 cpuinfo 1.0 1.8 1.8 bios 1.8
  scaling 1.0 1.8 1.8 cpuinfo 1.0 1.8 1.8 bios 1.8
temp:  85 [82, 85, 82, 44, 69, 33, 33, 44, 51]
fan:  2874
cpu:  scaling 1.0 1.8 1.8 cpuinfo 1.0 1.8 1.8 bios 1.8
  scaling 1.0 1.8 1.8 cpuinfo 1.0 1.8 1.8 bios 1.8
temp:  91 [91, 87, 91, 44, 72, 33, 33, 44, 51]
fan:  3151
cpu:  scaling 1.0 1.8 1.8 cpuinfo 1.0 1.0 1.8 bios 1.8
  scaling 1.0 1.8 1.8 cpuinfo 1.0 1.8 1.8 bios 1.8
temp:  94 [94, 88, 94, 44, 74, 33, 33, 44, 51]
fan:  3151
cpu:  scaling 1.0 1.8 1.8 cpuinfo 1.0 1.0 1.8 bios 1.8
  scaling 1.0 1.8 1.8 cpuinfo 1.0 1.8 1.8 bios 1.8
temp:  96 [96, 90, 96, 44, 76, 33, 33, 44, 52]
fan:  3531
cpu:  scaling 1.0 1.8 1.8 cpuinfo 1.0 1.0 1.8 bios 1.8
  scaling 1.0 1.8 1.8 cpuinfo 1.0 1.8 1.8 bios 1.8
temp:  98 [98, 91, 98, 45, 78, 33, 33, 44, 52]
fan:  3566
cpu:  scaling 1.0 1.8 1.8 cpuinfo 1.0 1.0 1.8 bios 1.8
  scaling 1.0 1.8 1.8 cpuinfo 1.0 1.8 1.8 bios 1.8
temp:  100 [100, 92, 100, 44, 79, 33, 33, 44, 52]
fan:  3575
cpu:  scaling 1.0 1.8 1.8 cpuinfo 1.0 1.0 1.8 bios 1.8
  scaling 1.0 1.8 1.8 cpuinfo 1.0 1.8 1.8 bios 1.8
temp:  101 [101, 93, 101, 44, 81, 33, 33, 44, 52]
fan:  3594
cpu:  scaling 1.0 1.8 1.8 cpuinfo 1.0 1.0 1.8 bios 1.8
  scaling 1.0 1.8 1.8 cpuinfo 1.0 1.8 1.8 bios 1.8
temp:  102 [102, 93, 102, 45, 82, 33, 33, 44, 53]
fan:  3596
cpu:  scaling 1.0 1.8 1.8 cpuinfo 1.0 1.8 1.8 bios 1.8
  scaling 1.0 1.8 1.8 cpuinfo 1.0 1.8 1.8 bios 1.8
temp:  102 [102, 91, 102, 44, 83, 33, 33, 44, 53]
fan:  3598
cpu:  scaling 1.0 1.8 1.8 cpuinfo 1.0 1.8 1.8 bios 1.8
  scaling 1.0 1.8 1.8 cpuinfo 1.0 1.8 1.8 bios 1.8
temp:  101 [101, 78, 101, 45, 83, 33, 33, 44, 54]
fan:  3599
cpu:  scaling 1.0 1.0 1.8 cpuinfo 1.0 1.0 1.8 bios 1.8
  scaling 1.0 1.0 1.8 cpuinfo 1.0 1.0 1.8 bios 1.8
temp:  84 [84, 75, 84, 45, 81, 33, 33, 44, 54]


[   21.594684] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery 
directory
[   21.703638] NFSD: starting 90-second grace period (net c5015600)
[   27.941612] ppc_notifier
[   27.944682] ppc_notifier: mutex
[   27.947639] ppc = 0
[   27.950576] ppc_notifier: verify within
[   27.953522] ppc = 0 freq-limit 1833000
[   27.956474] ppc_notifier
[   27.961414] ppc_notifier
[   27.963050] ppc_notifier: mutex
[   27.964674] ppc = 0
[   27.966246] ppc_notifier: verify within
[   27.967808] ppc = 0 freq-limit 1833000
[   27.969404] ppc_notifier
[   32.974593] iwl3945 :03:00.0: loaded firmware version 15.32.2.9
[   46.298794] wlan0: authenticate with 00:00:00:00:00:01
[   46.303301] wlan0: send auth to 00:00:00:00:00:01 (try 1/3)
[   46.305173] wlan0: authenticated
[   46.308558] wlan0: associate with 00:00:00:00:00:01 (try 1/3)
[   46.311352] wlan0: RX AssocResp from 00:00:00:00:00:01 (capab=0x401 status=0 
aid=4)
[   46.313568] wlan0: associated
[   80.213718] acpi_cpufreq: get_cur_freq_on_cpu (0)
[   80.213744] acpi_cpufreq: get_cur_val = 1555
[   80.213746] acpi_cpufreq: cur freq = 100
[   80.215276] acpi_cpufreq: get_cur_freq_on_cpu (1)
[   80.215280] acpi_cpufreq: get_cur_val = 2077
[   80.215282] acpi_cpufreq: cur freq = 1333000
[   85.233419] acpi_cpufreq: get_cur_freq_on_cpu (0)
[   85.233441] acpi_cpufreq: get_cur_val = 1555
[   85.233444] acpi_cpufreq: cur freq = 100
[   85.235230] acpi_cpufreq: get_cur_freq_on_cpu (1)
[   85.235235] acpi_cpufreq: get_cur_val = 1555
[   85.235238] acpi_cpufreq: cur freq = 100
[   90.241835] acpi_cpufreq: get_cur_freq_on_cpu (0)
[   90.241841] acpi_cpufreq: get_cur_val = 2860
[   90.241843] acpi_cpufreq: cur freq = 1833000
[   90.242820] acpi_cpufreq: get_cur_freq_on_cpu (1)
[   90.242825] acpi_cpufreq: get_cur_val = 2860
[   90.242826] acpi_cpufreq: cur freq = 1833000
[   95.249622] acpi_cpufreq: get_cur_freq_on_cpu (0)
[   95.249628] acpi_cpufreq: get_cur_val = 2860
[   95.249630] acpi_cpufreq: cur freq = 1833000
[   95.250608] acpi_cpufreq: get_cur_freq_on_cpu (1)
[   95.250613] acpi_cpufreq: get_cur_val = 2860
[   95.250614] acpi_cpufreq: cur freq = 1833000
[  100.257505] acpi_cpufreq: get_cur_freq_on_cpu (0)
[  100.257510] acpi_cpufreq: get_cur_val = 1555
[  100.257513] acpi_cpufreq: cur freq = 100
[  100.258490] acpi_cpufreq: get_cur_freq_on_cpu (1)
[  100.258496] acpi_cpufreq: get_cur_val = 2860
[  

Re: [ibm-acpi-devel] v4.8-rc1: thinkpad x60: running at low frequency even during kernel build

[Pavel Machek]

On Sat 2016-11-05 14:53:13, Pavel Machek wrote:
> Hi!
> 
> > > Ok, can do, let me recompile and reboot.
> > > 
> > > > 
> > > > When temperature limit is reached acpi_processor_ppc_notifier()
> > > > should
> > > > be called.
> > > 
> > > No, that's not correct for ACPI passive trip points, is it? If I
> > > recall correctly, those should be monitored even when temperature is
> > > below them so that it does not reach them...?
> > No if BIOS is sending PPC, it will be called. You can try first in 4.8.
> > 
> > Also try
> > 
> > Don't run workload, just on an idle system.
> > 
> > # echo 1 > /sys/class/thermal/cooling_device2/cur_state
> > monitor the scaling_max_freq, it should reduce
> > 
> > # echo 2 > /sys/class/thermal/cooling_device2/cur_state
> > monitor the scaling_max_freq, it should reduce
> 
> Yes, this seems to work. scaling_max goes to 1.5, then 1.1. Also under
> load, scaling_max_freq changes. But at that point, we are already
> around 98C... and bios_limit stays the same all the time in v4.9.

...while in v4.8-rc1, bios limit goes to 1.0 GHz at 90C, and
temperature just doesn't go above that.

Does it make sense to try with v4.8-final?

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] v4.8-rc1: thinkpad x60: running at low frequency even during kernel build

[Pavel Machek]

Hi!

> > Ok, can do, let me recompile and reboot.
> > 
> > > 
> > > When temperature limit is reached acpi_processor_ppc_notifier()
> > > should
> > > be called.
> > 
> > No, that's not correct for ACPI passive trip points, is it? If I
> > recall correctly, those should be monitored even when temperature is
> > below them so that it does not reach them...?
> No if BIOS is sending PPC, it will be called. You can try first in 4.8.
> 
> Also try
> 
> Don't run workload, just on an idle system.
> 
> # echo 1 > /sys/class/thermal/cooling_device2/cur_state
> monitor the scaling_max_freq, it should reduce
> 
> # echo 2 > /sys/class/thermal/cooling_device2/cur_state
> monitor the scaling_max_freq, it should reduce

Yes, this seems to work. scaling_max goes to 1.5, then 1.1. Also under
load, scaling_max_freq changes. But at that point, we are already
around 98C... and bios_limit stays the same all the time in v4.9.

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] v4.8-rc1: thinkpad x60: running at low frequency even during kernel build

[Pavel Machek]

On Fri 2016-11-04 23:20:53, Pandruvada, Srinivas wrote:
> On Fri, 2016-11-04 at 23:16 +0100, Pavel Machek wrote:
> > Hi!
> > 
> 
> [...]
> 
> > So we seem to have thermal or ACPI regression in v4.9-rc3.
> > 
> It is possible. Can you add either add printk
> in acpi_processor_ppc_has_changed() or use ftrace and see do you get to
> these functions
> 
> acpi_processor_ppc_init()
> acpi_processor_ppc_has_changed()
> acpi_processor_ppc_notifier()
> 
> ?

Ok, can do, let me recompile and reboot.

> When temperature limit is reached acpi_processor_ppc_notifier() should
> be called.

No, that's not correct for ACPI passive trip points, is it? If I
recall correctly, those should be monitored even when temperature is
below them so that it does not reach them...?

Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] v4.8-rc1: thinkpad x60: running at low frequency even during kernel build

[Pavel Machek]

Hi!

> > So we seem to have thermal or ACPI regression in v4.9-rc3.
> > 
> To me, there are two problems,
> the first one is a 4.9-rc regression that BIOS limit stops working,
> results in overheating because of high cpu frequency. I agree with
> Srinivas to check acpi_cpufreq driver code for this one.

Ok.

> the second problem is that thermal passive cooling can not prevent the
> system from overheating, when there is no BIOS limit. To debug this,
> you can enable thermal dynamic debug by
> echo 'module thermal_sys +fp' > /sys/kernel/debug/dynamic_debug/control

How is thermal passive cooling different from BIOS limit?

Is this related?

pavel@duo:/sys/class/thermal/cooling_device1$ grep -r . .
./cur_state:0
./power/runtime_active_kids:0
./power/runtime_suspended_time:0
grep: ./power/autosuspend_delay_ms: Input/output error
./power/runtime_enabled:disabled
./power/runtime_active_time:0
./power/control:auto
./power/async:disabled
./power/runtime_usage:0
./power/runtime_status:unsupported
./type:Processor
./max_state:10

Hmm. I seem to get _some_ throttling, even when bios_limit is still
1.8GHz, but I don't understand where it comes from. And yes,
'thermal_sys +fp' seems to produce some output.

[I did not get absolute records in >100C range this time, but still
there are "THERMAL EMERGENCY:" messages from thinkpad_acpi already...]

[14049.733423] thinkpad_acpi: THERMAL EMERGENCY: a sensor reports something is 
extremely hot!
[14049.735412] thinkpad_acpi: temperatures (Celsius): 92 50 N/A 80 32 N/A 32 
N/A 50 59 N/A N/A N/A N/A N/A N/A
[14049.736557] update_temperature: thermal thermal_zone1: 
last_temperature=92000, current_temperature=93000
[14049.736570] thermal_zone_trip_update: thermal thermal_zone1: 
Trip1[type=1,temp=92500]:trend=1,throttle=1
[14049.736577] get_target_state: thermal cooling_device2: cur_state=0
[14049.736580] thermal_zone_trip_update: thermal cooling_device2: old_target=0, 
target=1
[14049.736586] get_target_state: thermal cooling_device1: cur_state=0
[14049.736589] thermal_zone_trip_update: thermal cooling_device1: old_target=0, 
target=1
[14049.736593] thermal_cdev_update: thermal cooling_device2: zone1->target=1
[14049.736643] thermal_cdev_update: thermal cooling_device2: set to state 1
[14049.736647] thermal_cdev_update: thermal cooling_device1: zone1->target=1
[14049.73] thermal_cdev_update: thermal cooling_device1: set to state 1
[14049.808333] update_temperature: thermal thermal_zone1: 
last_temperature=93000, current_temperature=91000
[14049.808352] thermal_zone_trip_update: thermal thermal_zone1: 
Trip1[type=1,temp=92500]:trend=2,throttle=0
[14049.808360] get_target_state: thermal cooling_device2: cur_state=1
[14049.808364] thermal_zone_trip_update: thermal cooling_device2: old_target=1, 
target=0
[14049.808371] get_target_state: thermal cooling_device1: cur_state=1
[14049.808375] thermal_zone_trip_update: thermal cooling_device1: old_target=1, 
target=0
[14049.808381] thermal_cdev_update: thermal cooling_device2: zone1->target=0
[14049.808409] thermal_cdev_update: thermal cooling_device2: set to state 0
[14049.808414] thermal_cdev_update: thermal cooling_device1: zone1->target=0
[14049.808432] thermal_cdev_update: thermal cooling_device1: set to state 0
[14049.888385] update_temperature: thermal thermal_zone1: 
last_temperature=91000, current_temperature=92000
[14049.888401] thermal_zone_trip_update: thermal thermal_zone1: 
Trip1[type=1,temp=92500]:trend=1,throttle=0
[14049.888408] get_target_state: thermal cooling_device2: cur_state=0
[14049.888411] thermal_zone_trip_update: thermal cooling_device2: old_target=0, 
target=0
[14049.888416] get_target_state: thermal cooling_device1: cur_state=0
[14049.888419] thermal_zone_trip_update: thermal cooling_device1: old_target=0, 
target=0
[14051.312646] thinkpad_acpi: THERMAL EMERGENCY: a sensor reports something is 
extremely hot!
[14051.314442] thinkpad_acpi: temperatures (Celsius): 93 50 N/A 80 32 N/A 32 
N/A 50 59 N/A N/A N/A N/A N/A N/A
[14051.315544] update_temperature: thermal thermal_zone1: 
last_temperature=92000, current_temperature=94000
[14051.315557] thermal_zone_trip_update: thermal thermal_zone1: 
Trip1[type=1,temp=92500]:trend=1,throttle=1
[14051.315564] get_target_state: thermal cooling_device2: cur_state=0
[14051.315567] thermal_zone_trip_update: thermal cooling_device2: old_target=0, 
target=1
[14051.315572] get_target_state: thermal cooling_device1: cur_state=0
[14051.315575] thermal_zone_trip_update: thermal cooling_device1: old_target=0, 
target=1
[14051.315579] thermal_cdev_update: thermal cooling_device2: zone1->target=1
[14051.315629] thermal_cdev_update: thermal cooling_device2: set to state 1
[14051.315633] thermal_cdev_update: thermal cooling_device1: zone1->target=1
[14051.315652] thermal_cdev_update: thermal cooling_device1: set to state 1
[14051.334873] thinkpad_acpi: THERMAL EMERGENCY: a sensor reports something is 
extremely hot!
[14051.337322] thinkpad_acpi: temperatures (Celsius): 93 50 N/A 

Re: [ibm-acpi-devel] v4.8-rc1: thinkpad x60: running at low frequency even during kernel build

[Pavel Machek]

Hi!

> Under v4.8-rc, behaviour is different: bios_limit goes to 1GHz there
> when temperature is around 84C at the thermal zone. That keeps
> ibm/thermal temperatures under 90C, and no "thermal emergency"
> messages in syslog.

Argh. So v4.9 thermal management does not work.

v4.8 passive thermal management works _too well_, keeping fan at cca
3200 rpm, far below 3700 rpm it can reach. CPU is getting throttled,
and fan is not even running at full speed.

I can manually control the fan with thinkpad_acpi.fan_control=1... I
guess I can write some scripts?
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] v4.8-rc1: thinkpad x60: running at low frequency even during kernel build

[Pavel Machek]

Hi!

> > 4.9-rc2 has bios_limit:
> > 
> > pavel@duo:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/bios_limit
> > 1833000
> > 
> > and it has thermal zones:
> > 
> > /sys/devices/virtual/thermal/thermal_zone0/trip_point_0_temp 127000
> > /sys/devices/virtual/thermal/thermal_zone0/trip_point_0_type critical
> > /sys/devices/virtual/thermal/thermal_zone1/trip_point_0_temp 97000
> > /sys/devices/virtual/thermal/thermal_zone1/trip_point_0_type critical
> > /sys/devices/virtual/thermal/thermal_zone1/trip_point_1_temp 92500
> > /sys/devices/virtual/thermal/thermal_zone1/trip_point_1_type passive
> > 
> It will not act if there is no binding information. Do you have more
> files in this folder?
> 
> grep -r . * in /sys/class/thermal will be helpful.

Yes, I do. Here you go:

pavel@duo:/data/l/linux$ sudo grep -ri . /sys/class/thermal/*
/sys/class/thermal/cooling_device0/cur_state:0
/sys/class/thermal/cooling_device0/power/runtime_active_kids:0
/sys/class/thermal/cooling_device0/power/runtime_suspended_time:0
grep: /sys/class/thermal/cooling_device0/power/autosuspend_delay_ms:
Input/output error
/sys/class/thermal/cooling_device0/power/runtime_enabled:disabled
/sys/class/thermal/cooling_device0/power/runtime_active_time:0
/sys/class/thermal/cooling_device0/power/control:auto
/sys/class/thermal/cooling_device0/power/async:disabled
/sys/class/thermal/cooling_device0/power/runtime_usage:0
/sys/class/thermal/cooling_device0/power/runtime_status:unsupported
/sys/class/thermal/cooling_device0/type:LCD
/sys/class/thermal/cooling_device0/max_state:7
/sys/class/thermal/cooling_device1/cur_state:0
/sys/class/thermal/cooling_device1/power/runtime_active_kids:0
/sys/class/thermal/cooling_device1/power/runtime_suspended_time:0
grep: /sys/class/thermal/cooling_device1/power/autosuspend_delay_ms:
Input/output error
/sys/class/thermal/cooling_device1/power/runtime_enabled:disabled
/sys/class/thermal/cooling_device1/power/runtime_active_time:0
/sys/class/thermal/cooling_device1/power/control:auto
/sys/class/thermal/cooling_device1/power/async:disabled
/sys/class/thermal/cooling_device1/power/runtime_usage:0
/sys/class/thermal/cooling_device1/power/runtime_status:unsupported
/sys/class/thermal/cooling_device1/type:Processor
/sys/class/thermal/cooling_device1/max_state:10
/sys/class/thermal/cooling_device2/cur_state:0
/sys/class/thermal/cooling_device2/power/runtime_active_kids:0
/sys/class/thermal/cooling_device2/power/runtime_suspended_time:0
grep: /sys/class/thermal/cooling_device2/power/autosuspend_delay_ms:
Input/output error
/sys/class/thermal/cooling_device2/power/runtime_enabled:disabled
/sys/class/thermal/cooling_device2/power/runtime_active_time:0
/sys/class/thermal/cooling_device2/power/control:auto
/sys/class/thermal/cooling_device2/power/async:disabled
/sys/class/thermal/cooling_device2/power/runtime_usage:0
/sys/class/thermal/cooling_device2/power/runtime_status:unsupported
/sys/class/thermal/cooling_device2/type:Processor
/sys/class/thermal/cooling_device2/max_state:10
/sys/class/thermal/thermal_zone0/passive:0
/sys/class/thermal/thermal_zone0/available_policies:step_wise
/sys/class/thermal/thermal_zone0/policy:step_wise
/sys/class/thermal/thermal_zone0/mode:enabled
grep: /sys/class/thermal/thermal_zone0/offset: Input/output error
grep: /sys/class/thermal/thermal_zone0/integral_cutoff: Input/output
error
/sys/class/thermal/thermal_zone0/power/runtime_active_kids:0
/sys/class/thermal/thermal_zone0/power/runtime_suspended_time:0
grep: /sys/class/thermal/thermal_zone0/power/autosuspend_delay_ms:
Input/output error
/sys/class/thermal/thermal_zone0/power/runtime_enabled:disabled
/sys/class/thermal/thermal_zone0/power/runtime_active_time:0
/sys/class/thermal/thermal_zone0/power/control:auto
/sys/class/thermal/thermal_zone0/power/async:disabled
/sys/class/thermal/thermal_zone0/power/runtime_usage:0
/sys/class/thermal/thermal_zone0/power/runtime_status:unsupported
grep: /sys/class/thermal/thermal_zone0/k_d: Input/output error
/sys/class/thermal/thermal_zone0/trip_point_0_type:critical
/sys/class/thermal/thermal_zone0/type:acpitz
grep: /sys/class/thermal/thermal_zone0/slope: Input/output error
grep: /sys/class/thermal/thermal_zone0/k_po: Input/output error
grep: /sys/class/thermal/thermal_zone0/k_i: Input/output error
grep: /sys/class/thermal/thermal_zone0/sustainable_power: Input/output
error
/sys/class/thermal/thermal_zone0/trip_point_0_temp:127000
grep: /sys/class/thermal/thermal_zone0/k_pu: Input/output error
/sys/class/thermal/thermal_zone0/temp:58000
/sys/class/thermal/thermal_zone1/available_policies:step_wise
/sys/class/thermal/thermal_zone1/policy:step_wise
/sys/class/thermal/thermal_zone1/mode:enabled
/sys/class/thermal/thermal_zone1/trip_point_1_type:passive
grep: /sys/class/thermal/thermal_zone1/offset: Input/output error
grep: /sys/class/thermal/thermal_zone1/integral_cutoff: Input/output
error
/sys/class/thermal/thermal_zone1/power/runtime_active_kids:0

Re: [ibm-acpi-devel] v4.8-rc1: thinkpad x60: running at low frequency even during kernel build

[Pavel Machek]

Hi!

> I'd prefer mails over bugzilla for now...
> 
> 4.9-rc2 has bios_limit:
> 
> pavel@duo:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/bios_limit
> 1833000
> 
> and it has thermal zones:
> 
> /sys/devices/virtual/thermal/thermal_zone0/trip_point_0_temp 127000
> /sys/devices/virtual/thermal/thermal_zone0/trip_point_0_type critical
> /sys/devices/virtual/thermal/thermal_zone1/trip_point_0_temp 97000
> /sys/devices/virtual/thermal/thermal_zone1/trip_point_0_type critical
> /sys/devices/virtual/thermal/thermal_zone1/trip_point_1_temp 92500
> /sys/devices/virtual/thermal/thermal_zone1/trip_point_1_type passive
> 
> ..so it should slow down CPU at 92C.
> 
> So lets push the temperature up a bit...
> 
> sudo watch cat /proc/acpi/ibm/thermal
> /sys/devices/system/cpu/cpu0/cpufreq/bios_limit
> /sys/devices/virtual/thermal/thermal_zone1/temp  
> /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
> 
> temperatures:   98 49 -128 85 28 -128 28 -128 49 58 -128 -128 -128
> -128 -128 -128
> 1833000
> 95000
> 1833000
> 
> Hmm. bios_limit does not seem to change, even when the temperature is
> clearly above the trip point. (It is also interestng that acpi/ibm
> reports bigger temperatures than
> /sys/devices/virtual/thermal/thermal_zone1/temp . I have seen 103C
> there.)

Under v4.8-rc, behaviour is different: bios_limit goes to 1GHz there
when temperature is around 84C at the thermal zone. That keeps
ibm/thermal temperatures under 90C, and no "thermal emergency"
messages in syslog.

So we seem to have thermal or ACPI regression in v4.9-rc3.

Best regards,
 
Pavel
 
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] [PATCH] thinkpad_acpi: Add support for keyboard backlight

[Pavel Machek]

On Wed 2016-01-13 09:54:55, Pali Rohár wrote:
> On Tuesday 12 January 2016 22:58:04 Pavel Machek wrote:
> > Hi!
> > 
> > On Mon 2016-01-11 21:03:01, Pali Rohár wrote:
> > > On Monday 11 January 2016 20:28:00 Henrique de Moraes Holschuh wrote
> > > > The two features are not the same (and are handled differently by the
> > > > firmware, for whatever reason), although they do serve the same
> > > > purpose. I don't think a thinkpad will ever have both features at
> > > > the same time, so I have no idea why they changed the firmware
> > > > interface.
> > > 
> > > Maybe we should decide if ::kbd_backlight LED suffix could be used also 
> > > for other LED devices and not only for those which are physically under 
> > > the keyboard.
> > 
> > Another problem is that N900 has _6_ backlight LEDs. Named
> > lp5523::kb1..6. ... Which does means desktop software will probably
> > not pick them up :-(. 
> > 
> > I guess we could have "/sys/class/kbd_light/brightness" that would
> > control all of them with one write.
> 
> Probably... But there is problem that lp5523 is not ordinary on/off
> light, it can be programmed to execute own "light" application.

Yeah, but that's not a problem, right. lp5523 can still set brightness
by hand.

> > Next question is.. apparently there are some keyboards that have
> > per-key RGB backlight... but maybe we can just call that "weird
> > enough" and ignore...
> 
> First we need to defines stable kernel ABI for keyboard backlight. And I
> suggest to use existing convention used by upower/console-kit and other
> userspace apps...

Hmm... I'm not sure that can be done. What were the masks used by
upower again? Will upower write to all 6 leds if we present them?

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] [PATCH] thinkpad_acpi: Add support for keyboard backlight

[Pavel Machek]

On Wed 2016-01-13 20:07:36, Pavel Machek wrote:
> On Wed 2016-01-13 09:54:55, Pali Rohár wrote:
> > On Tuesday 12 January 2016 22:58:04 Pavel Machek wrote:
> > > Hi!
> > > 

> > > Next question is.. apparently there are some keyboards that have
> > > per-key RGB backlight... but maybe we can just call that "weird
> > > enough" and ignore...
> > 
> > First we need to defines stable kernel ABI for keyboard backlight. And I
> > suggest to use existing convention used by upower/console-kit and other
> > userspace apps...
> 
> Hmm... I'm not sure that can be done. What were the masks used by
> upower again? Will upower write to all 6 leds if we present them?

Got it...

It has function up_kbd_backlight_find() which do:

/* find a led device that is a keyboard device */
while ((filename = g_dir_read_name (dir)) != NULL) {
if (g_strstr_len (filename, -1, 
"kbd_backlight") != NULL) {
dir_path = g_build_filename 
("/sys/class/leds",
filename,

NULL);
break;

That suggests that it stops at the first matching device. Adding new
"virtual" led controlling 6 physical leds would be ugly. So... new
interface should be done.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] [PATCH] thinkpad_acpi: Add support for keyboard backlight

[Pavel Machek]

Hi!

On Mon 2016-01-11 21:03:01, Pali Rohár wrote:
> On Monday 11 January 2016 20:28:00 Henrique de Moraes Holschuh wrote
> > The two features are not the same (and are handled differently by the
> > firmware, for whatever reason), although they do serve the same
> > purpose. I don't think a thinkpad will ever have both features at
> > the same time, so I have no idea why they changed the firmware
> > interface.
> 
> Maybe we should decide if ::kbd_backlight LED suffix could be used also 
> for other LED devices and not only for those which are physically under 
> the keyboard.

Another problem is that N900 has _6_ backlight LEDs. Named
lp5523::kb1..6. ... Which does means desktop software will probably
not pick them up :-(. 

I guess we could have "/sys/class/kbd_light/brightness" that would
control all of them with one write.

Next question is.. apparently there are some keyboards that have
per-key RGB backlight... but maybe we can just call that "weird
enough" and ignore...

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] [PATCH] thinkpad_acpi: Add support for keyboard backlight

[Pavel Machek]

Hi1

> This patch adds support for controlling keyboard backlight via standard
> linux led class interface (::kbd_backlight). It uses ACPI HKEY device with
> MLCG and MLCS methods.
> 
> Signed-off-by: Pali Rohár 
> Tested-by: Fabio D'Urso 

On my thinkpad, keyboard light is controlled by

/sys/class/leds/tpacpi\:\:thinklight/brightness

(that's a bad name).

On n900, it is .../leds/kb0..kb6. Now we'd have kbd_backlight. I guess
we should standartize on one name for this light, so that userspace
has the chance to handle it automatically...

Also, neccessity of workqueues for LED setting is slowly being removed
from the kernel, see LED mailing list for details.

Thanks,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] [PATCH V4 RESEND] Support Thinkpad X1 Carbon 2nd gen's adaptive keyboard

[Pavel Machek]

Hi!

 Resend patch V4. Support Thinkpad X1 Carbon 2nd generation's adaptive
 keyboard.
 
 Hi Henrique, could you please have a chance to review it?

As far as I can tell... thinkpad just has small display above its function keys 
(right?).

Would it be possible to support it as a display? (/dev/fb1)?

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] thinkpad x60: critical thermal shutdown does not work (and ethernet overheats)

[Pavel Machek]

On Mon 2013-09-23 09:02:56, Henrique de Moraes Holschuh wrote:
 On Mon, 23 Sep 2013, Pavel Machek wrote:
   I have rather old thinkpad x60 here. Long time ago, I noticed that on
   high continuous ethernet load, it shuts itself down in regular
   way. I traced it down to overheat, followed by ACPI signaling system
   to go down.
  
  just to wrap the story up... after fixing pcie aspm problems,
  ethernet apparently stopped overheating.
 
 And that means a new kernel with fixed ASPM handling, or disabling ASPM
 entirely, or what?

That means single-line forcing ASPM to be disabled, even through linux
is normally not able to disable ASPM when it is not supported by the
BIOS. Someone at Intel knows about the problem, hopefully they will
present some better solution...

 Good to know it can be handled by a software fix, though!

Yes :-). [I wonder if it happens on other X60 machines, too?]
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

[ibm-acpi-devel] ethernet-related thermal emergency on Thinkpad x60

[Pavel Machek]

Hi!

When using nework interface (eth0), machine starts to behave
weird. Like... complete freeze, then poweroff, then it hangs on boot
(initializing ACPI) until I let it to cool down... and I'm not even
using gigabit speed.

Did anyone see it? Any ideas? Should I attempt to open it and clean
the dust?

Pavel

e1000e: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: Rx/Tx
e1000e :02:00.0: eth0: 10/100 speed: disabling TSO
coda_read_super: Bad mount data
coda_read_super: device index: 0
coda_read_super: rootfid is (01234567..08051c00.)
coda: Unexpected interruption.
Failure of coda_cnode_make for root: error -4
thinkpad_acpi: THERMAL EMERGENCY: a sensor reports something is extremely hot!
thinkpad_acpi: temperatures (Celsius): 88 49 N/A 82 40 N/A 40 N/A 52 61 N/A N/A 
N/A N/A N/A N/A


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] [RFC] Controlling the ThinkPad battery charger

[Pavel Machek]

On Mon 2011-05-09 12:29:41, Henrique de Moraes Holschuh wrote:
 On Mon, 09 May 2011, Andrew Lutomirski wrote:
   The SBS interface exposes more data about the battery, including
   per-cell-group voltage and pack microcontroller aging counters, alarms, 
   and
   the needs to get through the fuel-gaugue reset procedure semasphore.
  
  If I'm feeling really motivated, I'll look at that.  I'm currently
  more interested in the charging thresholds, though, which I think is
  independent of the choice of SBS vs ACPI to access the battery state.
  (From a quick glance at the SBS spec, you can inhibit charging
  entirely but you can't ask for thresholds.  I assume that the EC takes
  care of that.  If I'm wrong, please tell me, but SMAPI seems like a
  fine way to access the thresholds.)
 
 Yeah, SMAPI is the safest way to deal with all this.  It is an interface
 layer that Lenovo is not fond of breaking (or touches very rarely.  Amounts
 to the same in the end).
 
 SBS does not take care of thresholds, indeed.  The EC does (and I know how
 to program the threshold in a few models, if you do want to test it in your
 X220, I can send you the information.  It is safe to test if you use it
 together with SMAPI to cross-check).

Hmm, I jave a battery pack with reasonably good cells, but firmware killed it. 
IOW available for testing.

(And who know, perhaps recalibrate command would bring it back to life?)
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] [RFC] Controlling the ThinkPad battery charger

[Pavel Machek]

Hi!

  Hmm, I jave a battery pack with reasonably good cells, but firmware killed
  it. IOW available for testing.
 
 That is likely a problem with the battery pack uC, we cannot override that
 using any know firmware path in the ThinkPad.
 
 Does the thinkpad recognizes the presence of the battery pack?  If it
 doesn't, the pack uC is probably dead or in safe mode, and you'd need to
 hardware-hack it.

Yes, it does, and it reports everything ok... (Battery 100% full
IIRC). Its just that machine dies immediately when AC is removed.

  (And who know, perhaps recalibrate command would bring it back to life?)
 
 AFAIK, the recalibrate command really just does this:
 
 1. sets 'force discharge' flag on EC so that it starts discharging the
battery pack.  Discharging stops when cell voltage drops close to the
minimum safety level.
 
 2. sets stop threshold to 0 (100%) for that battery pack.
 
 That way, the box will fully-drain the pack, and then charge it to full. At
 that point, the recalibration is complete (the battery pack uC will
 auto-calibrate itself when it notices it has hit the fully-drained and
 fully-charged points).
 
 You can monitor per-cell-group voltages through tp_smapi on a original IBM
 battery pack, that functionality should still be around on the Lenovos.
 Since this is not standard SBS functionality, it might not work on
 non-original battery packs.

IIRC I tried playing with tp_smapi and did not get anything
useful. The pack should be original, and I guess I should try again.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] 2.6.33-rc2: regression: gkrellm no longer shows all the temperatures on thinkpad x60

[Pavel Machek]

Hi!

 Please apply the latest stack of patches (sent them to acpi-test
 yesterday).
 
 It is failing to register the ALSA mixer for some reason, and due
 to a bug, it is not loading the module at all.  I will look at the reason it
 is failing to register the ALSA mixer soon.  Meanwhile, the patches I sent
 to Len make sure the module can still load sucessfully.

Well, I'm not sure its completely fixed. I got this in my syslog:

thinkpad_acpi: THERMAL EMERGENCY: a sensor reports something is
extremely hot!
thinkpad_acpi: temperatures (Celsius): 95 47 N/A 89 47 N/A 41 N/A 51
61 N/A N/A N/A N/A N/A N/A

...meaning thinkpad_acpi is active and working, but still gkrellm does
not report temperatures as it used to.

r...@amd:~# cat /proc/acpi/ibm/thermal 
temperatures:   74 48 -128 75 47 -128 41 -128 51 58 -128 -128 -128
-128 -128 -128
r...@amd:~# 

...is there, so I'm not sure why gkrellm stopped working.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] 2.6.33-rc2: regression: gkrellm no longer shows all the temperatures on thinkpad x60

[Pavel Machek]

On Sun 2009-12-27 23:24:15, Didier Spaier wrote:
 Pavel Machek wrote:
 ...I'll have to find out where gkrell got that info. It worked in
 2.6.32.
 
  Pavel
 Only to make sure... What is the output of cat /proc/acpi/ibm/thermal?
 
 I ask that question because I noticed battery temperature 0° displayed  by 
 conky after updating to 2.6.32.2.
 Looking at my .conkyrc I saw I tried to display ${smapi_bat_temp 0}
but I had forgotten to re-install the tp_smapi module.

Uhuh, there's no /proc/acpi/ibm:

ls /proc/acpi/ibm 
ls: cannot access /proc/acpi/ibm: No such file or directory

. I guess that's the problem :-(. Config is:

CONFIG_THINKPAD_ACPI=y
# CONFIG_THINKPAD_ACPI_DEBUGFACILITIES is not set
# CONFIG_THINKPAD_ACPI_DEBUG is not set
CONFIG_THINKPAD_ACPI_UNSAFE_LEDS=y
CONFIG_THINKPAD_ACPI_VIDEO=y
# CONFIG_THINKPAD_ACPI_HOTKEY_POLL is not set

...so I do not see enable legacy interface option.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] [PATCH 08/10] thinkpad-acpi: log temperatures on termal alarm (v2)

[Pavel Machek]

On Tue 2009-12-08 23:36:28, Henrique de Moraes Holschuh wrote:
 Log temperatures on any of the EC thermal alarms.  It could be
 useful to help tracking down what is happening...
 
 Signed-off-by: Henrique de Moraes Holschuh h...@hmh.eng.br
 Cc: Pavel Machek pa...@ucw.cz

ACK.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] [PATCH 8/8] thinkpad-acpi: log temperatures on termal alarm

[Pavel Machek]

Hi!

   + for (i = 0; i  n; i++)
   + t.temp[i] = t.temp[i] / 1000;
   +
   + /* Fill missing sensors with N/A marker */
   + for (i = n; i  TPACPI_MAX_THERMAL_SENSORS; i++)
   + t.temp[i] = -128;
  
  -273 would be better N/A marker :-).
 
 No can do.  The firmware uses -128 (it is a signed 8-bit value), so there is
 an internal driver ABI *and* an userspace ABI since 2.6.13 or thereabouts
 that forces N/A sensors in thinkpad-acpi to return -128...
 
 In sysfs, I return an error code instead, which is arguably a much better
 way of doing that.
 
 But I do agree -273 would be a cooler value to return for N/A :-)

:-).

   + /* FIXME: it is ugly */
   + printk(TPACPI_NOTICE
   + temperatures (Celsius): 
   + %d %d %d %d %d %d %d %d %d %d %d %d %d %d %d %d\n,
  
  But this indeed is ugly. Why not sometihng like
  
  printk(TPACPI_NOTICE temperatures (Celsius): );
  for (i = 0; i  n; i++)
  printk(KERN_CONT %d , t.temp[i]);
  printk(KERN_CONT \n);
  
  ...you'd get rid of #ifdef above, ugly -128 markers, and nasty %d series...
 
 Can't get rid of -128, unless I print N/A instead, which your for() loop
 would allow.
 
 However, while using KERN_CONT is nicer, that printk is important and needs
 to get out to the logs with no reordering, no long delay, and preferably, no
 other printks interleaved with it.  Please excuse my lack of knowledge on
 this, but wouldn't KERN_CONT make it far more likely that a problem happens
 to the printk that will make it hard to read/useless (if reordering
 happens)?

It should be ok. Reordering is not possible, KERN_CONT will not
introduce delays. Interleaved messages are possible on SMP, but very
very unlikely.  I don't really expect problems.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] [PATCH 8/8] thinkpad-acpi: log temperatures on termal alarm

[Pavel Machek]

Hi!

 Log temperatures on any of the EC thermal alarms.  It could be
 useful to help tracking down what is happening...

Thanks, I applied it locally.

  static bool hotkey_notify_thermal(const u32 hkey,
bool *send_acpi_ev,
bool *ignore_acpi_ev)
  {
 + int known = true;
 +

Oops?


 + for (i = 0; i  n; i++)
 + t.temp[i] = t.temp[i] / 1000;
 +
 + /* Fill missing sensors with N/A marker */
 + for (i = n; i  TPACPI_MAX_THERMAL_SENSORS; i++)
 + t.temp[i] = -128;

-273 would be better N/A marker :-).

 + /* FIXME: it is ugly */
 + printk(TPACPI_NOTICE
 + temperatures (Celsius): 
 + %d %d %d %d %d %d %d %d %d %d %d %d %d %d %d %d\n,

But this indeed is ugly. Why not sometihng like

printk(TPACPI_NOTICE temperatures (Celsius): );
for (i = 0; i  n; i++)
printk(KERN_CONT %d , t.temp[i]);
printk(KERN_CONT \n);

...you'd get rid of #ifdef above, ugly -128 markers, and nasty %d series...

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

[ibm-acpi-devel] -rc6: annoying thermal messages

[Pavel Machek]

My dmesg log is rather full of. Thinkpad x60.
Pavel



wlan0: RX AssocResp from 00:11:95:05:30:d7 (capab=0x421 status=0
aid=2)
wlan0: associated
wlan0: deauthenticated from 00:11:95:05:30:d7 (Reason: 3)
thinkpad_acpi: THERMAL EMERGENCY: a sensor reports something is
extremely hot!
thinkpad_acpi: THERMAL EMERGENCY: a sensor reports something is
extremely hot!
thinkpad_acpi: THERMAL EMERGENCY: a sensor reports something is
extremely hot!
thinkpad_acpi: THERMAL EMERGENCY: a sensor reports something is
extremely hot!
thinkpad_acpi: THERMAL EMERGENCY: a sensor reports something is
extremely hot!
thinkpad_acpi: THERMAL EMERGENCY: a sensor reports something is
extremely hot!
thinkpad_acpi: THERMAL EMERGENCY: a sensor reports something is
extremely hot!
thinkpad_acpi: THERMAL EMERGENCY: a sensor reports something is
extremely hot!
thinkpad_acpi: THERMAL EMERGENCY: a sensor reports something is
extremely hot!
thinkpad_acpi: THERMAL EMERGENCY: a sensor reports something is
extremely hot!
thinkpad_acpi: THERMAL EMERGENCY: a sensor reports something is
extremely hot!
thinkpad_acpi: THERMAL EMERGENCY: a sensor reports something is
extremely hot!
thinkpad_acpi: THERMAL EMERGENCY: a sensor reports something is
extremely hot!
hub 1-0:1.0: state 7 ports 8 chg  evt 0004
ehci_hcd :00:1d.7: GetStatus port 2 status 001002 POWER sig=se0
CSC
hub 1-0:1.0: port 2, status 0100, change 0001, 12 Mb/s
usb 1-2: USB disconnect, address 6

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel

Re: [ibm-acpi-devel] refcounting problems with ibm_acpi but acpi=off

[Pavel Machek]

Hi!

  --- a/drivers/acpi/ibm_acpi.c
  +++ b/drivers/acpi/ibm_acpi.c
  @@ -2695,6 +2695,9 @@ static void acpi_ibm_exit(void)
   {
  int i;
   
  +   if (acpi_disabled)
  +   return;
  +
  for (i = ARRAY_SIZE(ibms) - 1; i = 0; i--)
  ibm_exit(ibms[i]);
   
  
 
 Indeed it is required, my bad.
 
 Acked-by: Henrique de Moraes Holschuh [EMAIL PROTECTED]
 
 Do you want me to forward a git patch to Len brown?

Yes, please. Hmm, seems like at least asus_acpi is affected by same problem.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel