Re: [ibm-acpi-devel] [PATCH] platform/x86: thinkpad_acpi: fix kernel-doc warnings

[Randy Dunlap]

Hi Mark,

On 12/6/23 07:30, Mark Pearson wrote:
> Hi Randy
> 
> On Wed, Dec 6, 2023, at 1:01 AM, Randy Dunlap wrote:
>> Add a function's return description and don't misuse "/**" for
>> non-kernel-doc comments to prevent warnings from scripts/kernel-doc.
>>
>> thinkpad_acpi.c:523: warning: No description found for return value of 
>> 'tpacpi_check_quirks'
>> thinkpad_acpi.c:9307: warning: This comment starts with '/**', but 
>> isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
>> thinkpad_acpi.c:9307: warning: missing initial short description on 
>> line:
>>  * This evaluates a ACPI method call specific to the battery
>>
>> Signed-off-by: Randy Dunlap 
>> Cc: Henrique de Moraes Holschuh 
>> Cc: Hans de Goede 
>> Cc: "Ilpo Järvinen" 
>> CC: ibm-acpi-devel@lists.sourceforge.net
>> CC: platform-driver-...@vger.kernel.org
>> ---
>>  drivers/platform/x86/thinkpad_acpi.c |6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff -- a/drivers/platform/x86/thinkpad_acpi.c 
>> b/drivers/platform/x86/thinkpad_acpi.c
>> --- a/drivers/platform/x86/thinkpad_acpi.c
>> +++ b/drivers/platform/x86/thinkpad_acpi.c
>> @@ -512,10 +512,10 @@ struct tpacpi_quirk {
>>   * Iterates over a quirks list until one is found that matches the
>>   * ThinkPad's vendor, BIOS and EC model.
>>   *
>> - * Returns 0 if nothing matches, otherwise returns the quirks field of
>> + * Returns: %0 if nothing matches, otherwise returns the quirks field 
> 
> Just being nosy - what does %0 do?
> I assume it helps with the return value but was intrigued how it is used and 
> where

It causes the output to be formatted as a CONSTANT (probably monospaced font,
but no guarantees on that).

> 
>> of
>>   * the matching  tpacpi_quirk entry.
>>   *
>> - * The match criteria is: vendor, ec and bios much match.
>> + * The match criteria is: vendor, ec and bios must match.
> I can't for the life of me see what is different here. What am I missing? 

s/much/must/

> 
>>   */
>>  static unsigned long __init tpacpi_check_quirks(
>>  const struct tpacpi_quirk *qlist,
>> @@ -9303,7 +9303,7 @@ static struct tpacpi_battery_driver_data
>>
>>  /* ACPI helpers/functions/probes */
>>
>> -/**
>> +/*
>>   * This evaluates a ACPI method call specific to the battery
>>   * ACPI extension. The specifics are that an error is marked
>>   * in the 32rd bit of the response, so we just check that here.
>>
>>
>> ___
>> ibm-acpi-devel mailing list
>> ibm-acpi-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
> 
> Thanks
> Mark

-- 
~Randy


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

[ibm-acpi-devel] [PATCH] platform/x86: thinkpad_acpi: fix kernel-doc warnings

[Randy Dunlap]

Add a function's return description and don't misuse "/**" for
non-kernel-doc comments to prevent warnings from scripts/kernel-doc.

thinkpad_acpi.c:523: warning: No description found for return value of 
'tpacpi_check_quirks'
thinkpad_acpi.c:9307: warning: This comment starts with '/**', but isn't a 
kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
thinkpad_acpi.c:9307: warning: missing initial short description on line:
 * This evaluates a ACPI method call specific to the battery

Signed-off-by: Randy Dunlap 
Cc: Henrique de Moraes Holschuh 
Cc: Hans de Goede 
Cc: "Ilpo Järvinen" 
CC: ibm-acpi-devel@lists.sourceforge.net
CC: platform-driver-...@vger.kernel.org
---
 drivers/platform/x86/thinkpad_acpi.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff -- a/drivers/platform/x86/thinkpad_acpi.c 
b/drivers/platform/x86/thinkpad_acpi.c
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -512,10 +512,10 @@ struct tpacpi_quirk {
  * Iterates over a quirks list until one is found that matches the
  * ThinkPad's vendor, BIOS and EC model.
  *
- * Returns 0 if nothing matches, otherwise returns the quirks field of
+ * Returns: %0 if nothing matches, otherwise returns the quirks field of
  * the matching  tpacpi_quirk entry.
  *
- * The match criteria is: vendor, ec and bios much match.
+ * The match criteria is: vendor, ec and bios must match.
  */
 static unsigned long __init tpacpi_check_quirks(
const struct tpacpi_quirk *qlist,
@@ -9303,7 +9303,7 @@ static struct tpacpi_battery_driver_data
 
 /* ACPI helpers/functions/probes */
 
-/**
+/*
  * This evaluates a ACPI method call specific to the battery
  * ACPI extension. The specifics are that an error is marked
  * in the 32rd bit of the response, so we just check that here.


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

[ibm-acpi-devel] [PATCH] Documentation: laptops: thinkpad-acpi: fix underline length build warning

[Randy Dunlap]

From: Randy Dunlap 

Fix underline length build warning in thinkpad-acpi.rst documentation:

Documentation/admin-guide/laptops/thinkpad-acpi.rst:1437: WARNING: Title 
underline too short.
DYTC Lapmode sensor
--

Fixes: acf7f4a59114 ("platform/x86: thinkpad_acpi: lap or desk mode interface")
Signed-off-by: Randy Dunlap 
Cc: Nitin Joshi 
Cc: Sugumaran 
Cc: Bastien Nocera 
Cc: Mark Pearson 
Cc: Andy Shevchenko 
Cc: Darren Hart 
Cc: Henrique de Moraes Holschuh 
Cc: ibm-acpi-devel@lists.sourceforge.net
Cc: platform-driver-...@vger.kernel.org
---
 Documentation/admin-guide/laptops/thinkpad-acpi.rst |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- lnx-59-rc2.orig/Documentation/admin-guide/laptops/thinkpad-acpi.rst
+++ lnx-59-rc2/Documentation/admin-guide/laptops/thinkpad-acpi.rst
@@ -1434,7 +1434,7 @@ on the feature, restricting the viewing
 
 
 DYTC Lapmode sensor
---
+---
 
 sysfs: dytc_lapmode
 




___
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] Input: document inhibiting

[Randy Dunlap]

On 6/17/20 3:18 AM, Andrzej Pietrasiewicz wrote:
> Document inhibiting input devices and its relation to being
> a wakeup source.
> 
> Signed-off-by: Andrzej Pietrasiewicz 
> ---
> v1..v2:
> 
> - Addressed editorial comments from Randy
> - Added a paragraph by Hans
> 
>  Documentation/input/input-programming.rst | 40 +++
>  1 file changed, 40 insertions(+)
> 
> diff --git a/Documentation/input/input-programming.rst 
> b/Documentation/input/input-programming.rst
> index 45a4c6e05e39..7432315cc829 100644
> --- a/Documentation/input/input-programming.rst
> +++ b/Documentation/input/input-programming.rst
> @@ -164,6 +164,46 @@ disconnects. Calls to both callbacks are serialized.
>  The open() callback should return a 0 in case of success or any nonzero value
>  in case of failure. The close() callback (which is void) must always succeed.
>  
> +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.
> +
> +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 devices - bringing a network interface 
> down doesn't mean
> +that it should be impossible be wake the system up on LAN through this 
> interface. So, there
> +may be input drivers which should be considered wakeup sources even when 
> inhibited. Actually,
> +in many I2C input devices their interrupt is declared a wakeup interrupt and 
> its handling
> +happens in driver's core, which is not aware of input-specific inhibit (nor 
> should it be).
> +Composite devices containing several interfaces can be inhibited on a 
> per-interface basis and
> +e.g. inhibiting one interface shouldn't affect the device's capability of 
> being a wakeup source.
> +
> +If a device is to be considered a wakeup source while inhibited, special 
> care must be taken when
> +programming its suspend(), as it might need to call device's open(). 
> Depending on what close()
> +means for the device in question, not opening() it before going to sleep 
> might make it
> +impossible to provide any wakeup events. The device is going to sleep anyway.
> +
>  Basic event types
>  ~
>  
> 

Reviewed-by: Randy Dunlap 

Thanks.

-- 
~Randy


___
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] Input: document inhibiting

[Randy Dunlap]

On 6/16/20 10:29 AM, Andrzej Pietrasiewicz wrote:
> Document inhibiting input devices and its relation to being
> a wakeup source.
> 
> Signed-off-by: Andrzej Pietrasiewicz 
> ---

Hi,
I have some editorial comments. Please see below.


> @Hans, @Dmitry,
> 
> My fist attempt at documenting inhibiting. Kindly look at it to see if I 
> haven't got anything
> wrong.
> 
> Andrzej
> 
>  Documentation/input/input-programming.rst | 36 +++
>  1 file changed, 36 insertions(+)
> 
> diff --git a/Documentation/input/input-programming.rst 
> b/Documentation/input/input-programming.rst
> index 45a4c6e05e39..0cd1ad4504fb 100644
> --- a/Documentation/input/input-programming.rst
> +++ b/Documentation/input/input-programming.rst
> @@ -164,6 +164,42 @@ disconnects. Calls to both callbacks are serialized.
>  The open() callback should return a 0 in case of success or any nonzero value
>  in case of failure. The close() callback (which is void) must always succeed.
>  
> +Inhibiting input devices
> +
> +
> +Inhibiting a device means ignoring input events from it. As such it is about 
> maintaining
> +relationships with input handlers - either an 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.
> +
> +Inhibiting and uninhibiting is orthogonal to opening and closing the device 
> by input

   are

> +handlers. Userspace might want to inhibit a device in anticipation before 
> any handler is
> +positively matched against it.
> +
> +Inhibiting and uninhibiting is orthogonal to device's being a wakeup source, 
> too. Being a

   are

> +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 devices - bringing a network interface 
> down doesn't mean
> +that it should be impossible to be wake the system up on LAN through this 
> interface. So, there
> +may be input drivers which should be considered wakeup sources even when 
> inhibited. Actually,
> +in many i2c input devices their interrupt is declared a wakeup interrupt and 
> its handling

   I2C

> +happens in driver's core, which is not aware of input-specific inhibit (nor 
> should it be).
> +Composite devices containing several interfaces can be inhibited on a 
> per-interface basis and
> +e.g. inhibiting one interface shouldn't affect the device's capability of 
> being a wakeup source.
> +
> +If a device is to be considered a wakeup source while inhibited, special 
> care must be taken when
> +programming its suspend(), as it might need to call device's open(). 
> Depending on what close()
> +means for the device in question not opening() it before going to sleep 
> might make it impossible

in question, not

> +to provide any wakeup events. The device is going to sleep anyway.
> +
>  Basic event types
>  ~
>  
> 

thanks for documentation.

-- 
~Randy



___
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/1] Use checkpatch.pl to make thinkpad_acpi.c error free: octal permissions

[Randy Dunlap]

On 11/14/2017 03:14 PM, Simranjit Singh wrote:
> From: Simranjit Singh 
> 
> Using the checkpatch.pl script, there were 8 errors in thinkpad_acpi.c. I 
> fixed them by changing permissions to octal,
> and by adding parenthesis. 
> On the current tree, if you use checkpatch.pl, thinkpad_acpi.c will have 8 
> errors. With my changes, there are 0 errors.
> However, I have added 3 new warnings. 
> I'm very new to kernel development, so if I messed up somewhere, please do 
> tell me.
> 
> Changed binary permissions to octal in accordance with checkpatch.pl in 
> thinkpad_acpi.c
> 
> Signed-off-by: Simranjit Singh 

a. You should have [PATCH 1/2] and [PATCH 2/2].

b. Subject should be something like [PATCH 1/2] thinkpad_acpi: fix octal 
permissions
(if they need to be fixed)

> ---
> diff --git a/drivers/platform/x86/thinkpad_acpi.c 
> b/drivers/platform/x86/thinkpad_acpi.c
> index 2242d60..9ad1f5b 100644
> --- a/drivers/platform/x86/thinkpad_acpi.c
> +++ b/drivers/platform/x86/thinkpad_acpi.c
> @@ -9574,7 +9574,7 @@ static int __init set_ibm_param(const char *val, struct 
> kernel_param *kp)
>  MODULE_PARM_DESC(experimental,
>"Enables experimental features when non-zero");
>  
> -module_param_named(debug, dbg_level, uint, 0);

Is 0 not octal?

> +module_param_named(debug, dbg_level, uint, 0444;

missing closing ')'.  So you did not compile this, right?  boo.

>  MODULE_PARM_DESC(debug, "Sets debug level bit-mask");
>  
>  module_param(force_load, bool, 0444);
> @@ -9638,25 +9638,25 @@ static int __init set_ibm_param(const char *val, 
> struct kernel_param *kp)
>  #ifdef CONFIG_THINKPAD_ACPI_DEBUGFACILITIES
>  module_param(dbg_wlswemul, uint, 0444);
>  MODULE_PARM_DESC(dbg_wlswemul, "Enables WLSW emulation");
> -module_param_named(wlsw_state, tpacpi_wlsw_emulstate, bool, 0);
> +module_param_named(wlsw_state, tpacpi_wlsw_emulstate, 044);

module_param_named() still takes 4 parameters.

>  MODULE_PARM_DESC(wlsw_state,
>"Initial state of the emulated WLSW switch");
>  
>  module_param(dbg_bluetoothemul, uint, 0444);
>  MODULE_PARM_DESC(dbg_bluetoothemul, "Enables bluetooth switch emulation");
> -module_param_named(bluetooth_state, tpacpi_bluetooth_emulstate, bool, 0);
> +module_param_named(bluetooth_state, tpacpi_bluetooth_emulstate, 0444);
'
ditto.

>  MODULE_PARM_DESC(bluetooth_state,
>"Initial state of the emulated bluetooth switch");
>  
>  module_param(dbg_wwanemul, uint, 0444);
>  MODULE_PARM_DESC(dbg_wwanemul, "Enables WWAN switch emulation");
> -module_param_named(wwan_state, tpacpi_wwan_emulstate, bool, 0);
> +module_param_named(wwan_state, tpacpi_wwan_emulstate, 0444);

ditto.

>  MODULE_PARM_DESC(wwan_state,
>"Initial state of the emulated WWAN switch");
>  
>  module_param(dbg_uwbemul, uint, 0444);
>  MODULE_PARM_DESC(dbg_uwbemul, "Enables UWB switch emulation");
> -module_param_named(uwb_state, tpacpi_uwb_emulstate, bool, 0);
> +module_param_named(uwb_state, tpacpi_uwb_emulstate, 0444);

ditto.

>  MODULE_PARM_DESC(uwb_state,
>"Initial state of the emulated UWB switch");
>  #endif
> 
> 
> 


-- 
~Randy

--
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] thinkpad_acpi: fix a build error

[Randy Dunlap]

On Mon, 21 Dec 2009 14:38:56 -0800 Marcel Holtmann wrote:

 Hi Henrique,
 
   The patch isn't correct (I guess the upstream fix is same?).
   
   CONFIG_SOUND is a global config for sound subsystem.  The relevant
   functions are ALSA core part, which is CONFIG_SND.
   So, the fix should be:
   
 depends on SND
   
   instead.
  
  Indeed.  Ingo already fixed that too.
  
  Although I personally would prefer:
  select SOUND
  select SND
  
  But anything that stops the build errors will do for now.
 
 I still haven't seen this patch in Linus' tree. And you do need select
 SOUND and SND. Otherwise you still get build errors. I have tested this
 on my machine. So can someone please submit a proper patch to get this
 fixed.

Ugh.  Please don't 'select' to build an entire subsystem.

---
~Randy

--
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 10/14] ACPI: thinkpad-acpi: use uppercase for LED on user documentation

[Randy Dunlap]

Henrique de Moraes Holschuh wrote:
 Change all occourences of the led word to full uppercase in user
 documentation.
 
 Signed-off-by: Henrique de Moraes Holschuh [EMAIL PROTECTED]
 Cc: Randy Dunlap [EMAIL PROTECTED]

Thank you.
Acked-by: Randy Dunlap [EMAIL PROTECTED]


 ---
  Documentation/laptops/thinkpad-acpi.txt |   22 +++---
  1 files changed, 11 insertions(+), 11 deletions(-)
 
 diff --git a/Documentation/laptops/thinkpad-acpi.txt 
 b/Documentation/laptops/thinkpad-acpi.txt
 index 73b80a7..947b726 100644
 --- a/Documentation/laptops/thinkpad-acpi.txt
 +++ b/Documentation/laptops/thinkpad-acpi.txt
 @@ -697,7 +697,7 @@ ThinkLight control
  --
  
  procfs: /proc/acpi/ibm/light
 -sysfs attributes: as per led class, for the tpacpi::thinklight led
 +sysfs attributes: as per LED class, for the tpacpi::thinklight LED
  
  procfs notes:
  
 @@ -710,11 +710,11 @@ status as unknown. The available commands are:
  
  sysfs notes:
  
 -The ThinkLight sysfs interface is documented by the led class
 -documentation, in Documentation/leds-class.txt.  The ThinkLight led name
 +The ThinkLight sysfs interface is documented by the LED class
 +documentation, in Documentation/leds-class.txt.  The ThinkLight LED name
  is tpacpi::thinklight.
  
 -Due to limitations in the sysfs led class, if the status of the thinklight
 +Due to limitations in the sysfs LED class, if the status of the thinklight
  cannot be read or if it is unknown, thinkpad-acpi will report it as off.
  It is impossible to know if the status returned through sysfs is valid.
  
 @@ -880,7 +880,7 @@ LED control
  ---
  
  procfs: /proc/acpi/ibm/led
 -sysfs attributes: as per led class, see below for names
 +sysfs attributes: as per LED class, see below for names
  
  Some of the LED indicators can be controlled through this feature.  On
  some older ThinkPad models, it is possible to query the status of the
 @@ -891,11 +891,11 @@ procfs notes:
  
  The available commands are:
  
 - echo 'led number on' /proc/acpi/ibm/led
 - echo 'led number off' /proc/acpi/ibm/led
 - echo 'led number blink' /proc/acpi/ibm/led
 + echo 'LED number on' /proc/acpi/ibm/led
 + echo 'LED number off' /proc/acpi/ibm/led
 + echo 'LED number blink' /proc/acpi/ibm/led
  
 -The led number range is 0 to 7. The set of LEDs that can be
 +The LED number range is 0 to 7. The set of LEDs that can be
  controlled varies from model to model. Here is the common ThinkPad
  mapping:
  
 @@ -912,7 +912,7 @@ All of the above can be turned on and off and can be made 
 to blink.
  
  sysfs notes:
  
 -The ThinkPad LED sysfs interface is described in detail by the led class
 +The ThinkPad LED sysfs interface is described in detail by the LED class
  documentation, in Documentation/leds-class.txt.
  
  The leds are named (in LED ID order, from 0 to 7):
 @@ -920,7 +920,7 @@ The leds are named (in LED ID order, from 0 to 7):
  tpacpi::dock_active, tpacpi::bay_active, tpacpi::dock_batt,
  tpacpi::unknown_led, tpacpi::standby.
  
 -Due to limitations in the sysfs led class, if the status of the LED
 +Due to limitations in the sysfs LED class, if the status of the LED
  indicators cannot be read due to an error, thinkpad-acpi will report it as
  a brightness of zero (same as LED off).
  


-- 
~Randy

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
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 09/13] ACPI: thinkpad-acpi: add sysfs led class support to thinkpad leds (v3.1)

[Randy Dunlap]

On Thu, 10 Apr 2008 00:53:01 -0300 Henrique de Moraes Holschuh wrote:

 Add a sysfs led class interface to the led subdriver.
 
 Signed-off-by: Henrique de Moraes Holschuh [EMAIL PROTECTED]
 Cc: Richard Purdie [EMAIL PROTECTED]
 ---
  Documentation/laptops/thinkpad-acpi.txt |   47 +--
  drivers/misc/thinkpad_acpi.c|  136 
 ++-
  2 files changed, 176 insertions(+), 7 deletions(-)
 
 diff --git a/Documentation/laptops/thinkpad-acpi.txt 
 b/Documentation/laptops/thinkpad-acpi.txt
 index 22c1ac4..27ca0f9 100644
 --- a/Documentation/laptops/thinkpad-acpi.txt
 +++ b/Documentation/laptops/thinkpad-acpi.txt
 @@ -875,28 +875,63 @@ The cmos command interface is prone to firmware 
 split-brain problems, as
  in newer ThinkPads it is just a compatibility layer.  Do not use it, it is
  exported just as a debug tool.
  
 -LED control -- /proc/acpi/ibm/led
 --
 +LED control
 +---
  
 -Some of the LED indicators can be controlled through this feature. The
 -available commands are:
 +procfs: /proc/acpi/ibm/led
 +sysfs attributes: as per led class, see below for names
 +
 +Some of the LED indicators can be controlled through this feature.  On
 +some older ThinkPad models, it is possible to query the status of the
 +LED indicators as well.  Newer ThinkPads cannot query the real status
 +of the LED indicators.
 +
 +procfs notes:
 +
 +The available commands are:
  
   echo 'led number on' /proc/acpi/ibm/led
   echo 'led number off' /proc/acpi/ibm/led
   echo 'led number blink' /proc/acpi/ibm/led
  
  The led number range is 0 to 7. The set of LEDs that can be
 -controlled varies from model to model. Here is the mapping on the X40:
 +controlled varies from model to model. Here is the common ThinkPad
 +mapping:
  
   0 - power
   1 - battery (orange)
   2 - battery (green)
 - 3 - UltraBase
 + 3 - UltraBase/dock
   4 - UltraBay
 + 5 - UltraBase battery slot
 + 6 - (unknown)
   7 - standby
  
  All of the above can be turned on and off and can be made to blink.
  
 +sysfs notes:
 +
 +The ThinkPad LED sysfs interface is described in detail by the led class
 +documentation, in Documentation/leds-class.txt.
 +
 +The leds are named (in LED ID order, from 0 to7):

   to 7):

 +tpacpi::power, tpacpi:orange:batt, tpacpi:green:batt,
 +tpacpi::dock_active, tpacpi::bay_active, tpacpi::dock_batt,
 +tpacpi::unknown_led, tpacpi::standby.
 +
 +Due to limitations in the sysfs led class, if the status of the LED
 +indicators cannot be read due to an error, thinkpad-acpi will report it as
 +a brightness of zero (same as LED off).
 +
 +If the thinkpad firmware doesn't support reading the current status,
 +trying to read the current LED brightness will just return whatever
 +brightness was last written to that attribute.
 +
 +These LEDs can blink using hardware acceleration.  To request that a
 +ThinkPad indicator LED should blink in hardware accelerated mode, use the
 +timer trigger, and leave the delay_on and delay_off parameters set to
 +zero (to request hardware acceleration autodetection).
 +
  ACPI sounds -- /proc/acpi/ibm/beep
  --


---
~Randy

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
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/13] ACPI: thinkpad-acpi: add sysfs led class support for thinklight (v3.1)

[Randy Dunlap]

On Thu, 10 Apr 2008 00:53:00 -0300 Henrique de Moraes Holschuh wrote:

 Add a sysfs led class interface to the thinklight (light subdriver).
 
 Signed-off-by: Henrique de Moraes Holschuh [EMAIL PROTECTED]
 Cc: Richard Purdie [EMAIL PROTECTED]
 ---
  Documentation/laptops/thinkpad-acpi.txt |   25 +++---
  drivers/misc/thinkpad_acpi.c|   57 
 ++-
  2 files changed, 76 insertions(+), 6 deletions(-)
 
 diff --git a/Documentation/laptops/thinkpad-acpi.txt 
 b/Documentation/laptops/thinkpad-acpi.txt
 index 0f403ff..22c1ac4 100644
 --- a/Documentation/laptops/thinkpad-acpi.txt
 +++ b/Documentation/laptops/thinkpad-acpi.txt
 @@ -692,16 +692,31 @@ while others are still having problems. For more 
 information:
  
  https://bugs.freedesktop.org/show_bug.cgi?id=2000
  
 -ThinkLight control -- /proc/acpi/ibm/light
 ---
 +ThinkLight control
 +--
 +
 +procfs: /proc/acpi/ibm/light
 +sysfs attributes: as per led class, for the tpacpi::thinklight led
 +

Well, I would really prefer that we call LEDs LED instead of led
in user documentation.

 +procfs notes:
  
 -The current status of the ThinkLight can be found in this file. A few
 -models which do not make the status available will show it as
 -unknown. The available commands are:
 +The ThinkLight status can be read and set through the procfs interface.  A
 +few models which do not make the status available will show the ThinkLight
 +status as unknown. The available commands are:
  
   echo on   /proc/acpi/ibm/light
   echo off  /proc/acpi/ibm/light
  
 +sysfs notes:
 +
 +The ThinkLight sysfs interface is documented by the led class
 +documentation, in Documentation/leds-class.txt.  The ThinkLight led name
 +is tpacpi::thinklight.
 +
 +Due to limitations in the sysfs led class, if the status of the thinklight
 +cannot be read or if it is unknown, thinkpad-acpi will report it as off.
 +It is impossible to know if the status returned through sysfs is valid.
 +
  Docking / undocking -- /proc/acpi/ibm/dock
  --


---
~Randy

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
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 01/13] ACPI: thinkpad-acpi: BIOS backlight mode helper (v2)

[Randy Dunlap]

On Thu, 10 Apr 2008 00:52:53 -0300 Henrique de Moraes Holschuh wrote:

  Documentation/laptops/thinkpad-acpi.txt |   49 +++
  drivers/misc/thinkpad_acpi.c|  238 
 +--
  2 files changed, 182 insertions(+), 105 deletions(-)
 
 diff --git a/Documentation/laptops/thinkpad-acpi.txt 
 b/Documentation/laptops/thinkpad-acpi.txt
 index 76cb428..bbc8275 100644
 --- a/Documentation/laptops/thinkpad-acpi.txt
 +++ b/Documentation/laptops/thinkpad-acpi.txt
 @@ -571,6 +571,46 @@ netlink interface and the input layer interface, and 
 don't bother at all
  with hotkey_report_mode.
  
  
 +Brightness hotkey notes:
 +
 +These are the current sane choices for brightness key mapping in
 +thinkpad-acpi:
 +
 +For IBM and Lenovo models *without* ACPI backlight control (the ones on
 +which thinkpad-acpi will autoload its backlight interface by default,
 +and on which ACPI video does not export a backlight interface):
 +
 +1. Don't enable or map the brightness hotkeys in thinkpad-acpi, as
 +   these older firmware versions unfortunately won't respect the hotkey
 +   mask for brightness keys anyway, and always reacts to them.  This
 +   usually work fine, unless X.org is doing something to block the BIOS.

X.org is an organization AFAIK.  Please use something like
X.org drivers or X.org video drivers when that it what is meant.

 +   In that case, use (3) below.  This is the default mode of operation.
 +
 +2. Enable the hotkeys, but map them to something else that is NOT
 +   KEY_BRIGHTNESS_UP/DOWN or any other keycode that would cause
 +   userspace to try to change the backlight level, and use that as an
 +   on-screen-display hint.
 +
 +3. IF AND ONLY IF X.org finds a way to block the firmware from

ditto

 +   automatically changing the brightness, enable the hotkeys and map
 +   them to KEY_BRIGHTNESS_UP and KEY_BRIGHTNESS_DOWN, and feed that to
 +   something that calls xbacklight.  thinkpad-acpi will not be able to
 +   change brightness in that case either, so you should disable its
 +   backlight interface.


---
~Randy

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel