lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <1202428633-6711-3-git-send-email-hmh@hmh.eng.br>
Date:	Thu,  7 Feb 2008 21:57:13 -0200
From:	Henrique de Moraes Holschuh <hmh@....eng.br>
To:	Richard Purdie <rpurdie@...ys.net>
Cc:	linux-kernel@...r.kernel.org, ibm-acpi-devel@...ts.sourceforge.net,
	linux-acpi@...r.kernel.org,
	Henrique de Moraes Holschuh <hmh@....eng.br>,
	Richard Purdie <rpurdie@...ys.net>
Subject: [PATCH 3/3] ACPI: thinkpad-acpi: add sysfs led class support to thinkpad leds

Add a sysfs led class interface to the led subdriver.

Signed-off-by: Henrique de Moraes Holschuh <hmh@....eng.br>
Cc: Richard Purdie <rpurdie@...ys.net>
---
 Documentation/thinkpad-acpi.txt |   46 +++++++++++++--
 drivers/misc/thinkpad_acpi.c    |  120 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 160 insertions(+), 6 deletions(-)

diff --git a/Documentation/thinkpad-acpi.txt b/Documentation/thinkpad-acpi.txt
index 0301394..53aa620 100644
--- a/Documentation/thinkpad-acpi.txt
+++ b/Documentation/thinkpad-acpi.txt
@@ -823,28 +823,62 @@ 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: "tp::power", "tp:orange:battery", "tp:green:battery",
+"tp::ultrabase", "tp::ultrabay", "tp::ultrabase_batt", "tp::unknown_led",
+"tp::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 blinks in hardware, 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
 ----------------------------------
 
diff --git a/drivers/misc/thinkpad_acpi.c b/drivers/misc/thinkpad_acpi.c
index 68bd8a1..8f0ff2f 100644
--- a/drivers/misc/thinkpad_acpi.c
+++ b/drivers/misc/thinkpad_acpi.c
@@ -3233,6 +3233,19 @@ TPACPI_HANDLE(led, ec, "SLED",	/* 570 */
 	   "LED",		/* all others */
 	   );			/* R30, R31 */
 
+#define TPACPI_LED_NUMLEDS 8
+static struct led_classdev *tpacpi_leds;
+static const char const *tpacpi_led_names[TPACPI_LED_NUMLEDS] = {
+	"tp::power",
+	"tp:orange:battery",
+	"tp:green:battery",
+	"tp::ultrabase",
+	"tp::ultrabay",
+	"tp::ultrabase_batt",	/* 19 char + NULL limit on sysfs */
+	"tp::unknown_led",
+	"tp::standby",
+};
+
 static int led_get_status(unsigned int led)
 {
 	int status;
@@ -3296,10 +3309,93 @@ static int led_set_status(unsigned int led, enum led_status_t ledstatus)
 	return rc;
 }
 
+/*
+ * This is highly dependent on the tpacpi_leds array
+ */
+static void led_sysfs_set(struct led_classdev *led_cdev,
+			enum led_brightness brightness)
+{
+	unsigned int led;
+	enum led_status_t newstatus;
+
+	led = led_cdev - tpacpi_leds;
+	BUG_ON(led >= TPACPI_LED_NUMLEDS);
+
+	if (brightness == LED_OFF)
+		newstatus = TPACPI_LED_OFF;
+	else
+		newstatus = TPACPI_LED_ON;
+
+	led_set_status(led, newstatus);
+}
+
+/*
+ * This is highly dependent on the tpacpi_leds array
+ */
+static int led_sysfs_blink_set(struct led_classdev *led_cdev,
+			unsigned long *delay_on, unsigned long *delay_off)
+{
+	unsigned int led;
+
+	led = led_cdev - tpacpi_leds;
+	BUG_ON(led >= TPACPI_LED_NUMLEDS);
+
+	/* Can we choose the flash rate? */
+	if (*delay_on == 0 && *delay_off == 0) {
+		/* yes. set them to the hardware blink rate (1 Hz) */
+		*delay_on = 500; /* ms */
+		*delay_off = 500; /* ms */
+	} else if ((*delay_on != 500) || (*delay_off != 500))
+		return -EINVAL;
+
+	led_set_status(led, TPACPI_LED_BLINK);
+
+	return 0;
+}
+
+/*
+ * This is highly dependent on the tpacpi_leds array
+ */
+static enum led_brightness led_sysfs_get(struct led_classdev *led_cdev)
+{
+	unsigned int led;
+	int rc;
+
+	led = led_cdev - tpacpi_leds;
+	BUG_ON(led >= TPACPI_LED_NUMLEDS);
+
+	rc = led_get_status(led);
+
+	if (rc == TPACPI_LED_OFF || rc < 0)
+		rc = LED_OFF;	/* no error handling in led class :( */
+	else
+		rc = LED_FULL;
+
+	return rc;
+}
+
+static void led_exit(void)
+{
+	unsigned int i;
+
+	for (i = 0; i < TPACPI_LED_NUMLEDS; i++) {
+		if (tpacpi_leds[i].name)
+			led_classdev_unregister(&tpacpi_leds[i]);
+	}
+
+	kfree(tpacpi_leds);
+	tpacpi_leds = NULL;
+}
+
 static int __init led_init(struct ibm_init_struct *iibm)
 {
+	unsigned int i;
+	int rc;
+
 	vdbg_printk(TPACPI_DBG_INIT, "initializing LED subdriver\n");
 
+	tpacpi_leds = NULL;
+
 	TPACPI_ACPIHANDLE_INIT(led);
 
 	if (!led_handle)
@@ -3318,6 +3414,29 @@ static int __init led_init(struct ibm_init_struct *iibm)
 	vdbg_printk(TPACPI_DBG_INIT, "LED commands are %s, mode %d\n",
 		str_supported(led_supported), led_supported);
 
+	tpacpi_leds = kzalloc(sizeof(*tpacpi_leds) * TPACPI_LED_NUMLEDS,
+			      GFP_KERNEL);
+	if (!tpacpi_leds) {
+		printk(TPACPI_ERR "Out of memory for LED data\n");
+		return -ENOMEM;
+	}
+
+	for (i = 0; i < TPACPI_LED_NUMLEDS; i++) {
+		tpacpi_leds[i].brightness_set = &led_sysfs_set;
+		tpacpi_leds[i].blink_set = &led_sysfs_blink_set;
+		if (led_supported == TPACPI_LED_570)
+			tpacpi_leds[i].brightness_get = &led_sysfs_get;
+		tpacpi_leds[i].name = tpacpi_led_names[i];
+
+		rc = led_classdev_register(&tpacpi_pdev->dev,
+					   &tpacpi_leds[i]);
+		if (rc < 0) {
+			tpacpi_leds[i].name = NULL;
+			led_exit();
+			return rc;
+		}
+	}
+
 	return (led_supported != TPACPI_LED_NONE)? 0 : 1;
 }
 
@@ -3388,6 +3507,7 @@ static struct ibm_struct led_driver_data = {
 	.name = "led",
 	.read = led_read,
 	.write = led_write,
+	.exit = led_exit,
 };
 
 /*************************************************************************
-- 
1.5.3.8

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ