- 16 12月, 2009 1 次提交
-
-
由 Corentin Chary 提交于
The light sensor disable brightness key and /sys/class/backlight/ control. There was a lot of report from users who didn't understand why they couldn't change their brightness, including: https://bugs.launchpad.net/bugs/222171 https://bugzilla.novell.com/show_bug.cgi?id=514747 http://bugzilla.kernel.org/show_bug.cgi?id=13671 http://bugzilla.kernel.org/show_bug.cgi?id=14432 Now the light sensor is disabled, and if the user want to enable it, the level should be ok. The funny thing is that comments where ok, not code. Cc: stable@kernel.org Cc: Thomas Renninger <trenn@suse.de> Cc: Peter Küppers <peter-mailbox@web.de> Cc: Michael Franzl <michaelfranzl@gmx.at> Cc: Ian Turner <vectro@vectro.org> Signed-off-by: NCorentin Chary <corentincj@iksaif.net> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 10 12月, 2009 32 次提交
-
-
由 Corentin Chary 提交于
Signed-off-by: NCorentin Chary <corentincj@iksaif.net> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Alan Jenkins 提交于
As Corentin points out, we do not create a backlight device if the ACPI video driver is able to provide equivalent functionality. So we do need to check before we try to update the backlight device. We now ignore brightness events completely if we have not created a backlight device. This is slightly more cautious than the original check. Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Corentin Chary 提交于
fix styles problems introduced by commit e86bda235a08b6a8e64c1e8bb9d175f6961554e3 Signed-off-by: NCorentin Chary <corentincj@iksaif.net> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Corentin Chary 提交于
Signed-off-by: NCorentin Chary <corentincj@iksaif.net> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Corentin Chary 提交于
Signed-off-by: NCorentin Chary <corentincj@iksaif.net> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Ike Panhc 提交于
Lenovo SL series laptop has a very similar DSDT with Asus laptops. We can easily have the extra ACPI function support with little modification in asus-laptop.c Here is the hotkey enablement for Lenovo SL series laptop. This patch will enable the following hotkey: - Volumn Up - Volumn Down - Mute - Screen Lock (Fn+F2) - Battery Status (Fn+F3) - WLAN switch (Fn+F5) - Video output switch (Fn+F7) - Touchpad switch (Fn+F8) - Screen Magnifier (Fn+Space) The following function of Lenovo SL laptop is still need to be enabled: - Hotkey: KEY_SUSPEND (Fn+F4), KEY_SLEEP (Fn+F12), Dock Eject (Fn+F9) - Rfkill for bluetooth and wlan - LenovoCare LED - Hwmon for fan speed - Fingerprint scanner - Active Protection System Signed-off-by: NIke Panhc <ike.pan@canonical.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Corentin Chary 提交于
The same key is used in toshiba-laptop, and there is no reserved key for that. Signed-off-by: NCorentin Chary <corentincj@iksaif.net> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Alan Jenkins 提交于
Callback methods should not refer to a variable like "eeepc" (formally "ehotk"). Instead, they should extract the data they need either from a "driver data" parameter, or the "driver data" field of the object which they operate on. The "eeepc" variable can then be removed. In practice, drivers under "drivers/platform" can get away without using driver data, because it doesn't make sense to have more than one instance of them. However this makes it harder to review them for correctness. This is especially true for core ACPI developers who have not previously been exposed to this anti-pattern :-). This will serve as an example of best practice for new driver writers (whether they find it themselves, or have it pointed out during review :-). The hwmon sub-device is a special case. It uses ec_{read,write} which are defined to communicate with the (first) EC, so it does not require any driver data. It should still only be instantiated in the context of an ASUS010 device because we don't have a safe way to probe for it. Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk> CC: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Alan Jenkins 提交于
eeepc-laptop now does a lot more than just hotkeys. Replace the "hotk" names used throughout the driver with some slightly more appropriate names. The actual strings used in kernel messages and sysfs are left unchanged. e.g. EEEPC_HOTK_FILE -> EEEPC_LAPTOP_FILE EEEPC_HOTK_HID -> EEEPC_ACPI_HID eeepc_hotk_notify -> eeepc_acpi_notify struct eeepc_hotk -> struct eeepc_laptop ehotk -> eeepc I'm about to refactor the entire driver to remove the global "ehotk" variable, and I don't wish to add "struct eeepc_hotk *ehotk" to functions which have nothing to do with hotkeys. Also - fix the name of "eepc_get_entry_by_keycode()" - remove the unused definition of NOTIFY_WLAN_ON. Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Alan Jenkins 提交于
Move e.g. backlight_init() and backlight_exit() together along with the other backlight functions, instead of grouping init() and exit() functions. Move e.g. backlight_ops to follow the functions it refers to, and remove the forward declarations. The code itself should remain unchanged. The eeepc-laptop driver implements a number of interfaces like the backlight class driver. This change makes it easier to examine the implementation of one interface at at a time, without having to search through the file to find init() and exit() functions etc. Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Alan Jenkins 提交于
This moves the sysfs_create_group() call just after the declaration of the platform device attributes. It should make it easier to examine the implementation of the platform device attributes in isolation from the rest of the code. (The next commit will apply this pattern to all of the sub-devices as well). Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Alan Jenkins 提交于
Strictly speaking we should register the platform driver exactly once, whether there are zero, one, or multiple matching acpi devices. Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Alan Jenkins 提交于
Separate out input_notify(), in a similar way to how notify_brn() is already separated. This will allow all the functions which refer to the input device to be grouped together. This includes a small behaviour change - we now synthesize brightness up/down key events even if the brightness is already at the maximum/minimum value. This is consistent with the new uevent interface. Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Alan Jenkins 提交于
The hwmon device uses ec_write() to write values to the EC. So for consistency it should use ec_read() to read values. The extra layers of indirection used did not add any value. This may mean we no longer take the ACPI global lock for such reads (if the EC operation region requires the lock and the EC does not). But there is no point locking each one-byte read individually, when write operations do not use the lock at all. Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Alan Jenkins 提交于
We don't need to store init_flags after using them. And we don't use the result of INIT, so we don't need to allocate a buffer for it. Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Alan Jenkins 提交于
We already tell the backlight class our maximum brightness value; it will validate the user requested values for us. Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Alan Jenkins 提交于
eeepc_hotk_notify() cannot be called with ehotk == NULL or bd == NULL. We check both variables for allocation failure and would bail out before the notifier is registered. Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Alan Jenkins 提交于
If the control method does not exist, return -ENODEV for consistency with get_acpi() Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Alan Jenkins 提交于
If we bail out because we can't create the led class device, we need to ensure the led workqueue is cleaned up. Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Alan Jenkins 提交于
Create the workqueue thread used by tpd_led_set() *before* we register the led device. (And vice versa for unregistration). Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Alan Jenkins 提交于
Documentation/hwmon/sysfs-interface tells us that automatic fan speed control should be represented by a value of 2 or above for pwm1_enable. Fix eeepc_get_fan_ctrl() to return 2 for automatic fan control. Setting "1" for manual control is already consistent with the documentation, so this remains unchanged. Let's preserve the ABI for this specific driver, so that writing "0" will still invoke automatic control. (The documentation says setting "0" should leave the fan at full speed all the time. This mode is not directly supported by our hardware. Full speed is rather noisy on my 701 and the automatic control has never used it. If you really want this e.g. to prolong the life of an EeePC used as a server, you can always use manual mode. hwmon has always been fairly machine-specific, and you're in a tiny minority (or elite :-). I'm sure you're smart enough to notice that the fan doesn't turn on to full speed when you try this mode, either by ear or checking fan_input1. We could even claim to be honouring the spirit of the documentation. "0" really means "safe mode". EeePCs default to automatic mode, ie that is what Asus will actually test. Since we do not provide any way to tamper with the temperature threshold, automatic mode _is_ the safe option). Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Alan Jenkins 提交于
The owner field provides the link between drivers and modules in sysfs, but no ACPI driver was setting it. After setting the owner field, we can see which module provides which driver and vice versa by looking at /sys/bus/acpi/driver/*/module and /sys/module/*/drivers/acpi:*. Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Alan Jenkins 提交于
acpi_bus_register_driver() already checks acpi_disabled, so acpi bus drivers don't need to. Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Alan Jenkins 提交于
The acpi device callbacks add, start, remove, suspend and resume can never be called with a NULL acpi_device. Each callsite in acpi/scan.c has to dereference the device in order to get the ops structure, e.g. struct acpi_device *acpi_dev = to_acpi_device(dev); struct acpi_driver *acpi_drv = acpi_dev->driver; if (acpi_drv && acpi_drv->ops.suspend) return acpi_drv->ops.suspend(acpi_dev, state); Remove all checks for acpi_dev == NULL within these callbacks. Also remove the checks for acpi_driver_data(acpi_dev) == NULL. None of these checks could fail unless the driver does something strange (which none of them do), the acpi core did something terribly wrong, or we have a memory corruption issue. If this does happen then it's best to dereference the pointer and crash noisily. Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Corentin Chary 提交于
This led can be found on Eeepc 1005 series. Signed-off-by: NCorentin Chary <corentincj@iksaif.net> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Alan Jenkins 提交于
The owner field provides the link between drivers and modules in sysfs, but no ACPI driver was setting it. After setting the owner field, we can see which module provides which driver and vice versa by looking at /sys/bus/acpi/driver/*/module and /sys/module/*/drivers/acpi:*. Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Alan Jenkins 提交于
The owner field provides the link between drivers and modules in sysfs, but no ACPI driver was setting it. After setting the owner field, we can see which module provides which driver and vice versa by looking at /sys/bus/acpi/driver/*/module and /sys/module/*/drivers/acpi:*. Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Alan Jenkins 提交于
acpi_bus_register_driver() already checks acpi_disabled, so acpi bus drivers don't need to. Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Alan Jenkins 提交于
acpi_bus_register_driver() already checks acpi_disabled, so acpi bus drivers don't need to. Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Alan Jenkins 提交于
The acpi device callbacks add, start, remove, suspend and resume can never be called with a NULL acpi_device. Each callsite in acpi/scan.c has to dereference the device in order to get the ops structure, e.g. struct acpi_device *acpi_dev = to_acpi_device(dev); struct acpi_driver *acpi_drv = acpi_dev->driver; if (acpi_drv && acpi_drv->ops.suspend) return acpi_drv->ops.suspend(acpi_dev, state); Remove all checks for acpi_dev == NULL within these callbacks. Also remove the checks for acpi_driver_data(acpi_dev) == NULL. None of these checks could fail unless the driver does something strange (which none of them do), the acpi core did something terribly wrong, or we have a memory corruption issue. If this does happen then it's best to dereference the pointer and crash noisily. Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Alan Jenkins 提交于
The acpi device callbacks add, start, remove, suspend and resume can never be called with a NULL acpi_device. Each callsite in acpi/scan.c has to dereference the device in order to get the ops structure, e.g. struct acpi_device *acpi_dev = to_acpi_device(dev); struct acpi_driver *acpi_drv = acpi_dev->driver; if (acpi_drv && acpi_drv->ops.suspend) return acpi_drv->ops.suspend(acpi_dev, state); Remove all checks for acpi_dev == NULL within these callbacks. Also remove the checks for acpi_driver_data(acpi_dev) == NULL. None of these checks could fail unless the driver does something strange (which none of them do), the acpi core did something terribly wrong, or we have a memory corruption issue. If this does happen then it's best to dereference the pointer and crash noisily. Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Alan Jenkins 提交于
Currently, reading from the disp attribute fails with "No such device", which is misleading. According to CMSG table on acpi4asus project site, no models have a getter method corresponding to SDSP. Change the file permission to disallow reads. If some joker changes the permission to permit reads, then return -EIO to be consistent with sysfs' behaviour when no show() method is provided. Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: NCorentin Chary <corentincj@iksaif.net> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 03 12月, 2009 7 次提交
-
-
由 Linus Torvalds 提交于
-
由 Julia Lawall 提交于
request_region should be used with release_region, not request_mem_region. Geert Uytterhoeven pointed out that in the case of drivers/video/gbefb.c, the problem is actually the other way around; request_mem_region should be used instead of request_region. The semantic patch that finds/fixes this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r1@ expression start; @@ request_region(start,...) @b1@ expression r1.start; @@ request_mem_region(start,...) @depends on !b1@ expression r1.start; expression E; @@ - release_mem_region + release_region (start,E) // </smpl> Signed-off-by: NJulia Lawall <julia@diku.dk> Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Atsushi Nemoto 提交于
TXx9 SPI bit rate is calculated by: fBR = (spi-baseclk) / (n + 1) Fix calculation of min_speed_hz, max_speed_hz and n. Signed-off-by: NAtsushi Nemoto <anemo@mba.ocn.ne.jp> Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6由 Linus Torvalds 提交于
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6: mfd: Correct WM831X_MAX_ISEL_VALUE
-
由 Anisse Astier 提交于
These laptops often leave i8042 in a wierd state resulting in non- operational touchpad and keyboard. Signed-off-by: NAnisse Astier <anisse@astier.eu> Signed-off-by: NDmitry Torokhov <dtor@mail.ru> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
git://neil.brown.name/md由 Linus Torvalds 提交于
* 'for-linus' of git://neil.brown.name/md: md: revert incorrect fix for read error handling in raid1.
-
由 Rusty Russell 提交于
Jon confirms that recent modprobe will look in /proc/cmdline, so these cmdline options can still be used. See http://bugzilla.kernel.org/show_bug.cgi?id=14164Reported-by: NAdam Williamson <awilliam@redhat.com> Cc: stable@kernel.org Signed-off-by: NRusty Russell <rusty@rustcorp.com.au> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-