Re: [ibm-acpi-devel] [PATCH 0/4] power: supply: add charge_behaviour property (force-discharge, inhibit-charge)
On Wed, 2021-11-24 at 00:27 +0100, Thomas Weißschuh wrote:
> this series adds support for the charge_behaviour property to the power
> subsystem and thinkpad_acpi driver.
Wonderful! Thanks for working on this.
I can confirm inhibit-charge and force-discharge states work with
patch v2 on v5.16-rc2 on a T430 (2342-CTO) with BIOS G1ETC2WW (2.82 ),
EC G1HT36WW and a single battery. Most behavior is as expected:
- With force-discharge, status becomes "Discharging" and energy_now
drops over time while AC remains connected.
- With inhibit-charge, status becomes "Unknown" and energy_now is
stable over time, even when not fully charged.
- With auto, status becomes "Charging" and energy_now rises over time.
- charge_behaviour takes precedence over
charge_control_{start,end}_threshold: status remains
Discharging/Unknown when below the start threshold, either due to
discharge or threshold change.
- charge_behaviour is preserved over soft reboot.
- inhibit-charge/auto are preserved across battery removal and
reinsertion.
- inhibit-charge/auto are preserved across s2ram (S3).
- With force-discharge, if the battery is removed, the machine
immediately powers off.
Some behavior is a little surprising:
- charge_behaviour can not be set to force-discharge if AC is
disconnected (EIO). If charge_behaviour is force-discharge when AC
is disconnected, it changes to auto, unlike inhibit-charge.
- charge_behavior force-discharge is not preserved across s2ram (S3),
unlike inhibit-charge.
- charge_behaviour is not preserved across hard reset (unlike charge
thresholds). Interestingly, it appears that inhibit-charge is
preserved across power-off (no charging is observed while powered
off) but not power-on, even though it is preserved across soft
reboot, as noted above.
I assume the behavior is under the control of the EC, so these aren't
criticisms of the patch. Just some observations.
Tested-by: Kevin Locke
Thanks again,
Kevin
___
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/2] platorm/x86: thinkpad_acpi: sysfs interface to reduce wlan tx power
On Fri, 2021-02-12 at 14:58 +0900, Nitin Joshi wrote: > Some newer Thinkpads have the WLAN antenna placed close to the WWAN > antenna. In these cases FCC certification requires that when WWAN is > active we reduce WLAN transmission power. A new Dynamic Power > Reduction Control (DPRC) method is available from the BIOS on these > platforms to reduce or restore WLAN Tx power. > > This patch provides a sysfs interface that userspace can use to adjust the > WLAN power appropriately. Question from a user: How does wlan_tx_strength_reduce relate to or interact with ioctl(SIOCSIWTXPOW) (i.e. iwconfig txpower) and NL80211_ATTR_WIPHY_TX_POWER_LEVEL (i.e. iw dev set txpower)? If I request 30 dBm then enable wlan_tx_strength_reduce, what happens? Same in the opposite order? Will ioctl(SIOCGIWTXPOW) show the reduced txpower? Thanks, Kevin ___ 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] thinkpad_acpi: add support for force_discharge
On Sun, 2018-05-13 at 17:30 +0200, Ognjen Galic wrote: > Lenovo ThinkPad systems have a feature that lets you > force the battery to discharge regardless if AC is attached > or not. > > This patch implements that feature and exposes it via the generic > ACPI battery driver. On a T430 (2342-CTO) I can confirm that both force_discharge and inhibit_charge behave as expected, both when the battery is above and below charge_start_threshold. Input validation also works as-expected. The only oddity I noticed is that force_discharge has a delay taking effect (<1 sec) transitioning from 0 to 1 (but not 1 to 0). Tested-by: Kevin Locke <ke...@kevinlocke.name> Thanks for working on this! Kevin -- 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 v4 2/4] platform: x86: thinkpad: Call led_notify_brightness_change on kbd brightness change
On Fri, 2016-11-11 at 15:33 +0100, Hans de Goede wrote: > On 11-11-16 15:12, Pali Rohár wrote: >> My question remains. Is this for Thinklight or keyboard backlight? >> Because Thinklinght has led device "tpacpi_led_thinklight" and keyboard >> backlight has led device "tpacpi_led_kbdlight". > > I would say both, this matches with the pre-existing > TP_ACPI_HKEY_THNKLGHT_MASK (they have a 1:1 mapping), > keep in mind that there are no thinkpads with both > a thinklight and a backlit keyboard, as those both > serve the same purpose so it looks like the re-used > the scancode. That's not entirely correct. The ThinkPad T430 has both a ThinkLight and a keyboard backlight. Pressing Fn-Space toggles between 4 states: Both Off -> Backlight Low -> Backlight High -> ThinkLight On (BL Off) I tested out your patch and observed the following behavior (printing brightness initially and on POLLPRI): # Initial state with both lights off. tpacpi::kbd_backlight/brightness: 0 tpacpi::thinklight/brightness: 0 # Press Fn-Space. KBD Backlight comes on low. tpacpi::kbd_backlight/brightness: 1 # Press Fn-Space. KBD Backlight brightens to high. tpacpi::kbd_backlight/brightness: 2 # Press Fn-Space. KBD Backlight turns off. ThinkLight turns on. tpacpi::kbd_backlight/brightness: 0 # Press Fn-Space. ThinkLight turns off. tpacpi::kbd_backlight/brightness: 0 It works, but the behavior is not quite what I would hope for. There are no poll events for tpacpi::thinklight/brightness and when the ThinkLight turns off it triggers an unnecessary tpacpi::kbd_backlight/brightness poll event. If there is anything else I can do to assist, let me know. Thanks for working on this, Kevin -- 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
On 01/12/2016 10:20 AM, Henrique de Moraes Holschuh wrote: > On Tue, Jan 12, 2016, at 16:11, Kevin Locke wrote: >> I looked through the DSDT and SSDT AML on the T430 (which also has both >> a keyboard backlight and ThinkLight) and couldn't deduce which method >> was being invoked for Fn+Space or an analog to MLCG/MLCS for the >> ThinkLight. However, that may be due to my inexperience interpreting >> AML. I'll keep looking/learning. > > It calls directly into the SMBIOS :-( Bummer! Thank you for taking the time to figure that out. Kevin -- 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] bluetooth off state not remembered accross reboots?
On Sat, 2009-12-05 at 18:12 -0200, Henrique de Moraes Holschuh wrote: On Sat, 05 Dec 2009, Kevin Locke wrote: Rfkill pretends that the master switch was set in its current position at startup by using an EV_SW event on devices that support them. So Actually, no, rfkill doesn't pretend anything. The *drivers* that implement that EV_SW SW_RFKILL_ALL (like thinkpad-acpi) *push* EV_SW events to rfkill with the current state. Except that it is also sent internally in rfkill when the input device is registered by rfkill_start at input.c:252 (without any request from the individual driver afaict - other than support for EV_SW), which is where the problem is happening. Fixing this is possible, but quite troublesome (we need to register an input device signature permanently in the rfkill core, and remember it across input device attach/detach, and do the right thing if it attaches twice because there are two such devices in the system, etc). In the most common use case (modules are loaded at boot and left alone after that) it causes no problem, so I don't think it will get fixed anytime soon. So states being preserved across reboots is not considered part of the common use case? I can live with that, although it is frustrating. The reason that master_switch_mode=1 is broken is that when a new input device is registered, the rfkill_handler specifies rfkill_start to be called for the new handle, which schedules an rfkill_restore_states to be called before rfkill_eop is ever called. So the 0-initialized (unblocked) save state is loaded for all devices. master_switch_mode=1 should set it to whatever the default state is (there's a module parameter to set that, I use 1 since I want radios blocked by default) if no epo ever happened (i.e. it doesn't have a state to go back to), or maybe do nothing at all if epo never happened before. Note: I didn't check what it is doing right now. If it is broken, I think a patch fixing this would be accepted by the rfkill maintainer. Yep, it's a 1-liner fix. I'll work on it. Kevin -- 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] bluetooth off state not remembered accross reboots?
On Tue, 2009-12-01 at 18:29 -0200, Henrique de Moraes Holschuh wrote: Well, if you pull from here: git://repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git release/2.6.31 All testing now being done from this branch. Please check and report what thinkpad-acpi reports for the content of /sys/bus/platform/devices/thinkpad-acpi/hotkey_radio_sw It has to be zero if the rfkill *physical* switch is on the radios disabled position, and 1 if it is in the radios enabled position. I can confirm that it is. When the switch is in the radios disabled position, *every* rfkill device based on thinkpad-acpi *must* report that the state is 2 (hardware-blocked). When the switch is in the radios enabled position, the rfkill devices must report either state 0 (software blocked) or 1 (unblocked). I can confirm this is true as well. Note that with master_switch_mode=1 or master_switch_mode=2 all devices will report 1 after switching off and back on, regardless of previous state. With master_switch_mode=0 all devices report 0 after switching off and back on, regardless of previous state. The rfkill core keeps global state for each type of rfkill switch, and something weird might be happening related to that. It could be interesting to check it, but you will need something to interface to /dev/rfkill. Using that utility in list mode, it reports states which match those from sysfs. In event mode, some of the output may be more useful. Note that I think phy0 lags behind tpacpi, which confuses the output a little. In the output below, master_switch_mode=1 and idx 0 is phy0, 1 is tpacpi_bluetooth_sw, 2 is tpacpi_wwan_sw. The testing was started with bluetooth soft blocked and everything else unblocked, at the end of the test everything is unblocked. # Initial state RFKILL event: idx 0 type 1 op 0 soft 0 hard 0 RFKILL event: idx 1 type 2 op 0 soft 1 hard 0 RFKILL event: idx 2 type 5 op 0 soft 0 hard 0 # Switch toggled to off RFKILL event: idx 1 type 2 op 2 soft 1 hard 1 RFKILL event: idx 2 type 5 op 2 soft 0 hard 1 RFKILL event: idx 0 type 1 op 2 soft 1 hard 0 RFKILL event: idx 1 type 2 op 2 soft 1 hard 1 RFKILL event: idx 2 type 5 op 2 soft 1 hard 1 RFKILL event: idx 0 type 1 op 2 soft 1 hard 1 # Switch toggled to on RFKILL event: idx 1 type 2 op 2 soft 1 hard 0 RFKILL event: idx 2 type 5 op 2 soft 1 hard 0 RFKILL event: idx 0 type 1 op 2 soft 0 hard 1 RFKILL event: idx 1 type 2 op 2 soft 0 hard 0 RFKILL event: idx 2 type 5 op 2 soft 0 hard 0 RFKILL event: idx 0 type 1 op 2 soft 0 hard 0 RFKILL event: idx 4 type 2 op 0 soft 0 hard 0 RFKILL event: idx 4 type 2 op 2 soft 0 hard 0 But it appears, from your description, that we are disturbing the kernel at module load. One of the things that thinkpad-acpi will do at module load, is to issue a EV_SW SW_RFKILL_ALL event with the current state of the rfkill switch. If that is not working right, it might be the reason for the problem. That would make sense with how the master switch behaves when toggled. If this same effect is simulated with the EV_SW, that would explain what is happening. On Tue, 01 Dec 2009, Kevin Locke wrote: If this is expected behavior, could it be documented somewhere (or am I overlooking somewhere that it is documented already)? No, there is something wrong, and I'd really like to know what :P I really appreciate you looking into it. If there is anything else I can do to help/test, please let me know. Kevin -- 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] bluetooth off state not remembered accross reboots?
On Tue, 2009-12-01 at 14:55 -0200, Henrique de Moraes Holschuh wrote: On Mon, 30 Nov 2009, Kevin Locke wrote: Then, the radio is unblocked by rfkill_switch_all which is queued by rfkill_schedule_evsw_rfkillall as part of input_register_device: If you disable bluetooth through rfkill (and not through bluetooth_enable) before you rmmod thinkpad-acpi ; modprobe thinkpad-acpi, what happens? If I change step 2 to # echo 0 /sys/devices/platform/thinkpad_acpi/rfkill/rfkill0/state the behavior is unchanged (light off, then after modprobe, back on) Also, are you sure you don't have a bluetooth=enable parameter in an options line for thinkpad-acpi somewhere in the modprobe config (in /etc/modprobe.d/*) ? I'm sure. Note: 2.6.31 has an all-new rfkill core and thinkpad-acpi glue, so it is worth testing it on 2.6.31 too. One known bug: will resume with radios disabled. A fix is ready for that problem already, but it has not made it to the kernel, yet. I should have mentioned originally, the testing is being done on 2.6.31.6 with thinkpad-acpi-0.23-20091010_v2.6.31.3.patch applied (but I could pull from git if you would prefer). Actually, with a little more testing I just figured it out. It was staring me in the face this whole time. The trick was to add the following somewhere in /etc/modprobe.d options rfkill default_state=0 master_switch_mode=0 With that line added, everything works as expected. Interestingly, I would have thought master_switch_mode=1 (restore) would fix it as well, but it does not. Only master_switch_mode=0 (unlock) works. If this is expected behavior, could it be documented somewhere (or am I overlooking somewhere that it is documented already)? Thanks, Kevin -- 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] bluetooth off state not remembered accross reboots?
Sorry for digging up such an old thread, but I am afflicted by the same problem and just recently found time to investigate. On Sat, 2009-10-10 at 13:49 -0300, Henrique de Moraes Holschuh wrote: On Sat, 10 Oct 2009, Yves-Alexis Perez wrote: since some time (I guess 2.6.29 or 2.6.30 kernel), it seems that the bluetooth ???off??? state isn't remembered on my T61. The driver can remember state, yes. It *might* not work though. And it can be overriden by userspace. The symptoms that I am observing on a T60p: * Boot into single-user mode and kill everything (including udev) * echo 0 /sys/devices/platform/thinkpad_acpi/bluetooth_enable (bluetooth light is now off and it disappears from the USB bus) * modprobe -r thinkpad_acpi * modprobe thinkpad_acpi (bluetooth light back on and device reappears on USB bus) Additionally, note that I have options rfkill default_state=0 set in modprobe.conf.d, if that is relevant. With some more investigation and judicious use of dump_stack(), I have put together the following call sequences that occur during modprobe of thinkpad_acpi: First, bluetooth is initialized and blocked: thinkpad_acpi: bluetooth_init: bluetooth is supported, status 0x01 thinkpad_acpi: tpacpi_rfk_hook_set_block: request to change radio state to blocked Pid: 1444, comm: modprobe Not tainted 2.6.31.6 #24 Call Trace: [f8681d79] tpacpi_rfk_hook_set_block+0x39/0x5c [thinkpad_acpi] [f81543f4] rfkill_set_block+0x6b/0xad [rfkill] [f81544cc] __rfkill_switch_all+0x2d/0x50 [rfkill] [f8154fd4] rfkill_register+0x183/0x1c7 [rfkill] [f868f8f5] tpacpi_new_rfkill+0xc4/0xfe [thinkpad_acpi] [f868fc9d] bluetooth_init+0x10e/0x13c [thinkpad_acpi] [f8690245] thinkpad_acpi_module_init+0x57a/0x909 [thinkpad_acpi] [f868fccb] ? thinkpad_acpi_module_init+0x0/0x909 [thinkpad_acpi] [c1001139] do_one_initcall+0x4c/0x131 [c1052c4d] sys_init_module+0xa7/0x1b7 [c1002af0] sysenter_do_call+0x12/0x22 thinkpad_acpi: bluetooth_set_status: will attempt to disable bluetooth Then, the radio is unblocked by rfkill_switch_all which is queued by rfkill_schedule_evsw_rfkillall as part of input_register_device: Pid: 1444, comm: modprobe Not tainted 2.6.31.6 #24 Call Trace: [c127f90d] ? printk+0xf/0x12 [f81552ef] rfkill_schedule_evsw_rfkillall+0x1c/0x33 [rfkill] [f815533c] rfkill_start+0x36/0x46 [rfkill] [c11f599a] input_register_handle+0x6a/0x74 [f81554af] rfkill_connect+0x99/0xc6 [rfkill] [c11f5502] input_attach_handler+0x33/0x66 [c11f6288] input_register_device+0x140/0x186 [f8690505] thinkpad_acpi_module_init+0x83a/0x909 [thinkpad_acpi] [f868fccb] ? thinkpad_acpi_module_init+0x0/0x909 [thinkpad_acpi] [c1001139] do_one_initcall+0x4c/0x131 [c1052c4d] sys_init_module+0xa7/0x1b7 [c1002af0] sysenter_do_call+0x12/0x22 thinkpad_acpi: tpacpi_rfk_hook_set_block: request to change radio state to unblocked Pid: 7, comm: events/0 Not tainted 2.6.31.6 #24 Call Trace: [f8681d79] tpacpi_rfk_hook_set_block+0x39/0x5c [thinkpad_acpi] [f81543f4] rfkill_set_block+0x6b/0xad [rfkill] [f81544cc] __rfkill_switch_all+0x2d/0x50 [rfkill] [f8154560] rfkill_switch_all+0x2f/0x3d [rfkill] [f8155153] rfkill_op_handler+0x8b/0x152 [rfkill] [c103c749] worker_thread+0x16f/0x200 [f81550c8] ? rfkill_op_handler+0x0/0x152 [rfkill] [c1040161] ? autoremove_wake_function+0x0/0x33 [c103c5da] ? worker_thread+0x0/0x200 [c103fe7e] kthread+0x6e/0x73 [c103fe10] ? kthread+0x0/0x73 [c100364f] kernel_thread_helper+0x7/0x10 thinkpad_acpi: bluetooth_set_status: will attempt to enable bluetooth So, is there something that I am missing? Should some userspace daemon be setting the bluetooth to blocked on boot if I prefer it that way? Or is this just a bug (and would you prefer that I bugzilla it)? Thanks, Kevin -- 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
