- 06 4月, 2009 15 次提交
-
-
由 David Brownell 提交于
Sometimes it's awkward to make sure that the array in the platform_data handed to the leds-gpio driver has only valid data ... some leds may not be always available, and coping with that currently requires patching or rebuilding the array. This patch fixes that by making it be OK to pass an invalid GPIO (such as "-EINVAL") ... such table entries are skipped. [rpurdie@linux.intel.com: adjusted to apply against other led tree changes] Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net> Tested-by: NDiego Dompe <diego.dompe@ridgerun.com> Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>
-
由 Riku Voipio 提交于
This fixes the expression in the driver to do the correct thing, not that I think anyone would send SND_* without EV_SND. Thanks to Roel Kluin <roel.kluin@gmail.com> for noticing. Signed-off-by: NRiku Voipio <riku.voipio@iki.fi> Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>
-
由 Uwe Kleine-König 提交于
A pointer to h1940leds_probe is passed to the core via platform_driver_register and so the function must not disappear when the .init sections are discarded. Otherwise (if also having HOTPLUG=y) unbinding and binding a device to the driver via sysfs will result in an oops as does a device being registered late. An alternative to this patch is using platform_driver_probe instead of platform_driver_register plus removing the pointer to the probe function from the struct platform_driver. Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>
-
由 Zhenwen Xu 提交于
This goto is unnecessary. Signed-off-by: NZhenwen Xu <helight.xu@gmail.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>
-
由 Kim Kyuwon 提交于
ROHM BD2802GU is a RGB LED controller attached to i2c bus and specifically engineered for decoration purposes. This RGB controller incorporates lighting patterns and illuminates. This driver is designed to minimize power consumption, so when there is no emitting LED, it enters to reset state. And because the BD2802GU has lots of features that can't be covered by the current LED framework, it provides Advanced Configuration Function(ADF) mode, so that user applications can set registers of BD2802GU directly. Here are basic usage examples : ; to turn on LED (not blink) $ echo 1 > /sys/class/leds/led1_R/brightness ; to blink LED $ echo timer > /sys/class/leds/led1_R/trigger $ echo 1 > /sys/class/leds/led1_R/delay_on $ echo 1 > /sys/class/leds/led1_R/delay_off ; to turn off LED $ echo 0 > /sys/class/leds/led1_R/brightness [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: NKim Kyuwon <chammoru@gmail.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>
-
由 Németh Márton 提交于
The leds-clevo-mail driver is in the mainline kernel since 2.6.25 and works without severe problems. Make this driver available for a larger audience. Signed-off-by: NMárton Németh <nm127@freemail.hu> Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>
-
由 Adam Nielsen 提交于
Signed-off-by: NAdam Nielsen <a.nielsen@shikadi.net> Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>
-
由 Felipe Balbi 提交于
The gpio led trigger will allow leds to be triggered by gpio events. When we give the led a gpio number, the trigger will request_irq() on that so we don't have to keep polling for gpio state. It's useful for usecases as n810's keypad leds that could be triggered by the gpio event generated when user slides up to show the keypad. We also provide means for userland to tell us what is the desired brightness for that special led when it goes on so userland could use information from ambient light sensors and not set led brightness too high if it's not necessary. Signed-off-by: NFelipe Balbi <me@felipebalbi.com> Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>
-
由 Phil Sutter 提交于
Mikrotik built six LEDs into the Routerboard 532, from which one is destined for custom use, the so called "User LED". This patch adds a driver for it, based on the LEDs class. Signed-off-by: NPhil Sutter <n0-1@freewrt.org> Acked-by: NFlorian Fainelli <florian@openwrt.org> Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>
-
由 Richard Purdie 提交于
Add an option to preserve LED state when suspending/resuming to the LED gpio driver. Based on a suggestion from Robert Jarzmik. Tested-by: NRobert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>
-
由 Luotao Fu 提交于
Add a simple driver for pwm driver LEDs. pwm_id and period can be defined in board file. It is developed for pxa, however it is probably generic enough to be used on other platforms with pwm. Signed-off-by: NLuotao Fu <l.fu@pengutronix.de> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>
-
由 Richard Purdie 提交于
You can't have multiple module_init()/module_exit calls so resort to messy ifdefs potentially pending some code refactoring. Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>
-
由 Guennadi Liakhovetski 提交于
Add an LED driver using the DAC124S085 DAC from NatSemi [randy.dunlap@oracle.com: use header files for interfaces] Signed-off-by: NGuennadi Liakhovetski <lg@denx.de> Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com> Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>
-
由 Guennadi Liakhovetski 提交于
This patch allows drivers to override the default maximum brightness value of 255. We take care to preserve backwards-compatibility as much as possible, so that user-space ABI doesn't change for existing drivers. LED trigger code has also been updated to use the per-LED maximum. Signed-off-by: NGuennadi Liakhovetski <lg@denx.de> Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>
-
由 Trent Piepho 提交于
Add bindings to support LEDs defined as of_platform devices in addition to the existing bindings for platform devices. New options in Kconfig allow the platform binding code and/or the of_platform code to be turned on. The of_platform code is of course only available on archs that have OF support. The existing probe and remove methods are refactored to use new functions create_gpio_led(), to create and register one led, and delete_gpio_led(), to unregister and free one led. The new probe and remove methods for the of_platform driver can then share most of the common probe and remove code with the platform driver. The suspend and resume methods aren't shared, but they are very short. The actual led driving code is the same for LEDs created by either binding. The OF bindings are based on patch by Anton Vorontsov <avorontsov@ru.mvista.com>. They have been extended to allow multiple LEDs per device. Signed-off-by: NTrent Piepho <tpiepho@freescale.com> Acked-by: NGrant Likely <grant.likely@secretlab.ca> Acked-by: NSean MacLennan <smaclennan@pikatech.com> Signed-off-by: NRichard Purdie <rpurdie@linux.intel.com>
-
- 05 4月, 2009 17 次提交
-
-
由 Bjorn Helgaas 提交于
This patch adds a .notify() method. The presence of .notify() causes Linux/ACPI to manage event handlers and notify handlers on our behalf, so we don't have to install and remove them ourselves. Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> CC: Zhang Rui <rui.zhang@intel.com> CC: Zhao Yakui <yakui.zhao@intel.com> CC: Venki Pallipadi <venkatesh.pallipadi@intel.com> CC: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Bjorn Helgaas 提交于
This patch adds a .notify() method. The presence of .notify() causes Linux/ACPI to manage event handlers and notify handlers on our behalf, so we don't have to install and remove them ourselves. Note that events from fixed hardware buttons now show up as a special notify event, so to preserve user-space backward compatibility, we convert that back to ACPI_BUTTON_NOTIFY_STATUS. Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Reviewed-by: NAlex Chiang <achiang@hp.com> CC: Alexey Starikovskiy <alexey.y.starikovskiy@linux.intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Bjorn Helgaas 提交于
This patch adds support for ACPI device driver .notify() methods. If such a method is present, Linux/ACPI installs a handler for device notifications (but not for system notifications such as Bus Check, Device Check, etc). When a device notification occurs, Linux/ACPI passes it on to the driver's .notify() method. In most cases, this removes the need for drivers to install their own handlers for device-specific notifications. For fixed hardware devices like some power and sleep buttons, there's no notification value because there's no control method to execute a Notify opcode. When a fixed hardware device generates an event, we handle it the same as a regular device notification, except we send a ACPI_FIXED_HARDWARE_EVENT value. This is outside the normal 0x0-0xff range used by Notify opcodes. Several drivers install their own handlers for system Bus Check and Device Check notifications so they can support hot-plug. This patch doesn't affect that usage. Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Reviewed-by: NAlex Chiang <achiang@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Samuel Ortiz 提交于
The da903x interrupt handler is retruning an int instead of an irqreturn_t. Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Mark Brown 提交于
Reverse the order of the tests for loop exit so we use a valid value before we time out. Vanishingly unlikely to happen since we retry for several times the expected conversion time. Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: NSamuel Ortiz <sameo@openedhand.com>
-
由 Tobias Klauser 提交于
The C99 specification states in section 6.11.5: The placement of a storage-class specifier other than at the beginning of the declaration specifiers in a declaration is an obsolescent feature. Signed-off-by: NTobias Klauser <tklauser@distanz.ch> Signed-off-by: NSamuel Ortiz <sameo@openedhand.com>
-
由 Philipp Zabel 提交于
Signed-off-by: NPhilipp Zabel <philipp.zabel@gmail.com> Signed-off-by: NSamuel Ortiz <sameo@openedhand.com>
-
由 Philipp Zabel 提交于
This driver requests a clock that usually is supplied by the MFD in which the DS1WM is contained. Currently, it is impossible for a MFD to register their clocks with the generic clock API due to different implementations across architectures. For now, this patch removes the clock handling from DS1WM altogether, trusting that the MFD enable/disable functions will switch the clock if needed. The clock rate is obtained from a new parameter in driver_data. Signed-off-by: NPhilipp Zabel <philipp.zabel@gmail.com> Signed-off-by: NSamuel Ortiz <sameo@openedhand.com>
-
由 Philipp Zabel 提交于
This patch makes htc-pasic3 register the DS1WM and LED cell drivers through the MFD core infrastructure instead of allocating the platform devices manually. It also calculates the bus_shift parameter from the memory resource size. Signed-off-by: NPhilipp Zabel <philipp.zabel@gmail.com> Signed-off-by: NSamuel Ortiz <sameo@openedhand.com>
-
由 Philipp Zabel 提交于
This patch converts the DS1WM driver into an MFD cell. It also calculates the bus_shift parameter from the memory resource size. Signed-off-by: NPhilipp Zabel <philipp.zabel@gmail.com> Signed-off-by: NSamuel Ortiz <sameo@openedhand.com>
-
由 Mark Brown 提交于
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: NSamuel Ortiz <sameo@openedhand.com>
-
由 Mark Brown 提交于
Some I2C controllers have high overheads for setting up I2C operations which makes the register cache setup on startup excessively slow since it does a lot of small transactions. Reduce this overhead by doing a bulk read of the entire register bank and filtering out what we don't need later. Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: NSamuel Ortiz <sameo@openedhand.com>
-
由 Huang Weiyi 提交于
Removed duplicated #include <linux/device.h> in drivers/mfd/pcf50633-core.c Signed-off-by: NHuang Weiyi <weiyi.huang@gmail.com> Signed-off-by: NSamuel Ortiz <sameo@openedhand.com>
-
由 Arjan van de Ven 提交于
The battery driver tends to take quite some time to initialize (100ms-300ms is quite typical). This patch initializes the batter driver asynchronously, so that other things in the kernel can initialize in parallel to this 300 msec. As part of this, the battery driver had to move to the back of the ACPI init order (hence the Makefile change). Without this move, the next ACPI driver would just block on the ACPI/devicee layer semaphores until the battery driver was done anyway, not gaining any boot time. Signed-off-by: NArjan van de Ven <arjan@linux.intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Carlos Corbacho 提交于
Explicitly note in the documentation that the Acer Aspire One is not supported. Signed-off-by: NCarlos Corbacho <carlos@strangeworlds.co.uk> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Andy Whitcroft 提交于
Cleanup the failure cleanup handling for brightness and email led. [cc: Split out from another patch] Signed-off-by: NAndy Whitcroft <apw@canonical.com> Signed-off-by: NCarlos Corbacho <carlos@strangeworlds.co.uk> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Carlos Corbacho 提交于
The Aspire One's ACPI-WMI interface is a placeholder that does nothing, and the invalid results that we get from it are now causing userspace problems as acer-wmi always returns that the rfkill is enabled (i.e. the radio is off, when it isn't). As it's hardware controlled, acer-wmi isn't needed on the Aspire One either. Thanks to Andy Whitcroft at Canonical for tracking down Ubuntu's userspace issues to this. Signed-off-by: NCarlos Corbacho <carlos@strangeworlds.co.uk> Reported-by: NAndy Whitcroft <apw@canonical.com> Cc: stable@kernel.org Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 04 4月, 2009 8 次提交
-
-
由 Len Brown 提交于
acpi_video_device_write_state() and friends now return ssize_t, while the constify patch assumed it was still int. Signed-off-by: NLen Brown <len.brown@intel.com>
-
Refactor and redesign the brightness control backend... In order to fix bugzilla #11750... Add a new brightness control mode: support direct NVRAM checkpointing of the backlight level (i.e. store directly to NVRAM without the need for UCMS calls), and use that together with the EC-based control. Disallow UCMS+EC, thus avoiding races with the SMM firmware. Switch the models that define HBRV (EC Brightness Value) in the DSDT to the new mode. These are: T40-T43, R50-R52, R50e, R51e, X31-X41. Change the default for all other IBM ThinkPads to UCMS-only. The Lenovo models already default to UCMS-only. Reported-by: NAlexey Fisher <bug-track@fisher-privat.net> Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: NLen Brown <len.brown@intel.com>
-
Enhance debugging messages for the fan subdriver. Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: NLen Brown <len.brown@intel.com>
-
Enhance debugging messages for the hotkey subdriver. Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: NLen Brown <len.brown@intel.com>
-
Enhance debugging messages for all rfkill subdrivers in thinkpad-acpi. Also, log a warning if the deprecated sysfs attributes are in use. These attributes are going to be removed sometime in 2010. There is an user-visible side-effect: we now coalesce attempts to enable/disable bluetooth or WWAN in the procfs interface, instead of hammering the firmware with multiple requests. Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: NLen Brown <len.brown@intel.com>
-
Some of the ThinkPad LEDs indicate critical conditions that can cause data loss or cause hardware damage when ignored (e.g. force-ejecting a powered up bay; ignoring a failing battery, or empty battery; force- undocking with the dock buses still active, etc). On almost all ThinkPads, LED access is write-only, and the firmware usually does fire-and-forget signaling on them, so you effectively lose whatever message the firmware was trying to convey to the user when you override the LED state, without any chance to restore it. Restrict access to all LEDs that can convey important alarms, or that could mislead the user into incorrectly operating the hardware. This will make the Lenovo engineers less unhappy about the whole issue. Allow users that really want it to still control all LEDs, it is the unaware user that we have to worry about. Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: NLen Brown <len.brown@intel.com>
-
The HKEY disable functionality basically cripples the entire event model of the ThinkPad firmware and of the thinkpad-acpi driver. Remove this functionality from the driver. HKEY must be enabled at all times while thinkpad-acpi is loaded, and disabled otherwise. For sysfs, according to the sysfs ABI and the thinkpad-acpi sysfs rules of engagement, we will just remove the attributes. This will be done in two stages: disable their function now, after two kernel releases, remove the attributes. For procfs, we call WARN(). If nothing triggers it, I will simply remove the enable/disable commands entirely in the future along with the sysfs attributes. I don't expect much, if any fallout from this. There really isn't any reason to mess with hotkey_enable or with the enable/disable commands to /proc/acpi/ibm/hotkey, and this has been true for years... Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: NLen Brown <len.brown@intel.com>
-
Add a debug helper that discloses the TGID of the userspace task attempting to access the driver. This is highly useful when dealing with bug reports, since often the user has no idea that some userspace application is accessing thinkpad-acpi... Also add a helper to log warnings about sysfs attributes that are deprecated. Use the new helpers to issue deprecation warnings for bluetooth_enable and wwan_enabled, that have been deprecated for a while, now. Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: NLen Brown <len.brown@intel.com>
-