| Age | Commit message (Collapse) | Author |
|---|
|
Also guard PM operations with CONFIG_PM.
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Len Brown <len.brown@intel.com>
|
|
Any of the platform API functions can fail; driver should be prepared
to handle such failures. Also:
- changed to platform_driver_probe() since the device is created
right there with the driver;
- added __devexit annotation to remove method;
- fixed memory leak on module unload - named platform_device_del() is not
enough to free platform device, need platform_device_unregister().
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Len Brown <len.brown@intel.com>
|
|
Sysfs attribute group takes care of proper creation of a set of attributes
and implements proper error unwinding so the driver does not have to do it.
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Len Brown <len.brown@intel.com>
|
|
The tc1100-wmi driver should print the current states of wireless LAN and
jogdial brightness control when "cat /sys/devices/platform/tc1100-wmi/wireless"
and "cat /sys/devices/platform/tc1100-wmi/jogdial" are executed, respectively.
What actually happens is that both of those commands print 0 regardless of the
hardware state. The cause is that wmi_query_block returns an ACPI_TYPE_INTEGER
rather than ACPI_TYPE_BUFFER as the driver assumes. Additionally, the driver
intends to return a jogdial state that is inverted with respect to the commands
required to set it (e.g. it intends to return 1 after the jogdial file was
written with 0).
This patch fixes both of those issues - the commands to query the
state now work, and should return the same state that was written.
http://bugzilla.kernel.org/show_bug.cgi?id=12286
Signed-off-by: Krzysztof Kosiński <tweenk.pl@gmail.com>
Acked-by: Carlos Corbacho <carlos@strangeworlds.co.uk>
Signed-off-by: Len Brown <len.brown@intel.com>
|
|
Conflicts:
drivers/misc/Kconfig
Signed-off-by: Len Brown <len.brown@intel.com>
|
|
Move x86 platform specific drivers from drivers/misc/
to a new home under drivers/platform/x86/.
The community has been maintaining x86 vendor-specific
platform specific drivers under /drivers/misc/ for a few years.
The oldest ones started life under drivers/acpi.
They moved out of drivers/acpi/ because they don't actually
implement the ACPI specification, but either simply
use ACPI, or implement vendor-specific ACPI extensions.
In the future we anticipate...
drivers/misc/ will go away.
other architectures will create drivers/platform/<arch>
Signed-off-by: Len Brown <len.brown@intel.com>
|
