- 04 1月, 2012 1 次提交
-
-
由 Al Viro 提交于
both proc_dir_entry ->mode and populating functions Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
-
- 06 8月, 2011 1 次提交
-
-
由 Sergey Senozhatsky 提交于
Commit 9c921c22 Author: Lan Tianyu <tianyu.lan@intel.com> ACPI / Battery: Resolve the race condition in the sysfs_remove_battery() fixed BUG https://bugzilla.kernel.org/show_bug.cgi?id=35642 , but as a side effect made lockdep unhappy with sysfs_remove_battery(): [14818.477168] [14818.477170] ======================================================= [14818.477200] [ INFO: possible circular locking dependency detected ] [14818.477221] 3.1.0-dbg-07865-g1280ea8-dirty #668 [14818.477236] ------------------------------------------------------- [14818.477257] s2ram/1599 is trying to acquire lock: [14818.477276] (s_active#8){++++.+}, at: [<ffffffff81169147>] sysfs_addrm_finish+0x31/0x5a [14818.477323] [14818.477325] but task is already holding lock: [14818.477350] (&battery->lock){+.+.+.}, at: [<ffffffffa0047278>] sysfs_remove_battery+0x10/0x4b [battery] [14818.477395] [14818.477397] which lock already depends on the new lock. [14818.477399] [..] [14818.479121] stack backtrace: [14818.479148] Pid: 1599, comm: s2ram Not tainted 3.1.0-dbg-07865-g1280ea8-dirty #668 [14818.479175] Call Trace: [14818.479198] [<ffffffff814828c3>] print_circular_bug+0x293/0x2a4 [14818.479228] [<ffffffff81070cb5>] __lock_acquire+0xfe4/0x164b [14818.479260] [<ffffffff81169147>] ? sysfs_addrm_finish+0x31/0x5a [14818.479288] [<ffffffff810718d2>] lock_acquire+0x138/0x1ac [14818.479316] [<ffffffff81169147>] ? sysfs_addrm_finish+0x31/0x5a [14818.479345] [<ffffffff81168a79>] sysfs_deactivate+0x9b/0xec [14818.479373] [<ffffffff81169147>] ? sysfs_addrm_finish+0x31/0x5a [14818.479405] [<ffffffff81169147>] sysfs_addrm_finish+0x31/0x5a [14818.479433] [<ffffffff81167bc5>] sysfs_hash_and_remove+0x54/0x77 [14818.479461] [<ffffffff811681b9>] sysfs_remove_file+0x12/0x14 [14818.479488] [<ffffffff81385bf8>] device_remove_file+0x12/0x14 [14818.479516] [<ffffffff81386504>] device_del+0x119/0x17c [14818.479542] [<ffffffff81386575>] device_unregister+0xe/0x1a [14818.479570] [<ffffffff813c6ef9>] power_supply_unregister+0x23/0x27 [14818.479601] [<ffffffffa004729c>] sysfs_remove_battery+0x34/0x4b [battery] [14818.479632] [<ffffffffa004778f>] battery_notify+0x2c/0x3a [battery] [14818.479662] [<ffffffff8148fe82>] notifier_call_chain+0x74/0xa1 [14818.479692] [<ffffffff810624b4>] __blocking_notifier_call_chain+0x6c/0x89 [14818.479722] [<ffffffff810624e0>] blocking_notifier_call_chain+0xf/0x11 [14818.479751] [<ffffffff8107e40e>] pm_notifier_call_chain+0x15/0x27 [14818.479770] [<ffffffff8107ee1a>] enter_state+0xa7/0xd5 [14818.479782] [<ffffffff8107e341>] state_store+0xaa/0xc0 [14818.479795] [<ffffffff8107e297>] ? pm_async_store+0x45/0x45 [14818.479807] [<ffffffff81248837>] kobj_attr_store+0x17/0x19 [14818.479820] [<ffffffff81167e27>] sysfs_write_file+0x103/0x13f [14818.479834] [<ffffffff81109037>] vfs_write+0xad/0x13d [14818.479847] [<ffffffff811092b2>] sys_write+0x45/0x6c [14818.479860] [<ffffffff81492f92>] system_call_fastpath+0x16/0x1b This patch introduces separate lock to struct acpi_battery to grab in sysfs_remove_battery() instead of battery->lock. So fix by Lan Tianyu is still there, we just grab independent lock. Signed-off-by: NSergey Senozhatsky <sergey.senozhatsky@gmail.com> Tested-by: NLan Tianyu <tianyu.lan@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 21 7月, 2011 1 次提交
-
-
由 Phil Carmody 提交于
All these are instances of #define NAME value; or #define NAME(params_opt) value; These of course fail to build when used in contexts like if(foo $OP NAME) while(bar $OP NAME) and may silently generate the wrong code in contexts such as foo = NAME + 1; /* foo = value; + 1; */ bar = NAME - 1; /* bar = value; - 1; */ baz = NAME & quux; /* baz = value; & quux; */ Reported on comp.lang.c, Message-ID: <ab0d55fe-25e5-482b-811e-c475aa6065c3@c29g2000yqd.googlegroups.com> Initial analysis of the dangers provided by Keith Thompson in that thread. There are many more instances of more complicated macros having unnecessary trailing semicolons, but this pile seems to be all of the cases of simple values suffering from the problem. (Thus things that are likely to be found in one of the contexts above, more complicated ones aren't.) Signed-off-by: NPhil Carmody <ext-phil.2.carmody@nokia.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
- 17 7月, 2011 3 次提交
-
-
由 Stefan Hajnoczi 提交于
Make sure the error return from sysfs_add_battery() is checked and propagated out from acpi_battery_add(). Signed-off-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Stefan Hajnoczi 提交于
When acpi_battery_add_fs() fails the error handling code does not clean up completely. Moreover, it does not return resulting in a use-after-free. Signed-off-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Vasiliy Kulikov 提交于
Structs battery_file, acpi_dock_ops, file_operations, thermal_cooling_device_ops, thermal_zone_device_ops, kernel_param_ops are not changed in runtime. It is safe to make them const. register_hotplug_dock_device() was altered to take const "ops" argument to respect acpi_dock_ops' const notion. Signed-off-by: NVasiliy Kulikov <segoon@openwall.com> Acked-by: NJeff Garzik <jgarzik@redhat.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 14 7月, 2011 6 次提交
-
-
由 Lan Tianyu 提交于
Use battery->lock in sysfs_remove_battery() to make checking, removing, and clearing bat.dev atomic. This is necessary because sysfs_remove_battery() may be invoked concurrently from different paths. https://bugzilla.kernel.org/show_bug.cgi?id=35642Signed-off-by: NLan Tianyu <tianyu.lan@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Lan Tianyu 提交于
In the commit 25be5821, add the refresh sysfs when system resumes from suspending. But it didn't check that the battery exists. This will cause battery sysfs files added when the battery doesn't exist. This patch add the check before refreshing. https://bugzilla.kernel.org/show_bug.cgi?id=35642Signed-off-by: NLan Tianyu <tianyu.lan@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Lan Tianyu 提交于
The Commit 25be5821 has added a PM notifier to refresh the sys in order to deal with the unit change of the Battery Present Rate. But it just consided the suspend situation. The problem also will happen during the hibernation according the bug 28192. https://bugzilla.kernel.org/show_bug.cgi?id=28192 This patch adds the hibernation process and fix the bug. Signed-off-by: NLan Tianyu <tianyu.lan@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Lan Tianyu 提交于
This patch is cosmetic only, and makes no functional change. Since the acpi_battery_quirks has been deleted, rename acpi_battery_quirks2 with acpi_battery_quirks to clean the code. Signed-off-by: NLan Tianyu <tianyu.lan@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Lan Tianyu 提交于
This patch is for some machines which report the battery current as a 16-bit signed negative when it is charging. This is caused by DSDT bug. The commit bc76f90b has resolved the problem for Acer laptops. But some other machines also have such problem. https://bugzilla.kernel.org/show_bug.cgi?id=33722 Since it is improper that the current is above 32A on laptops whether on AC or on battery, this patch is to check the current and take its absolute value as current and producing a message when it is negative in s16. Remove Acer quirk, as this workaround handles Acer too. Signed-off-by: NLan Tianyu <tianyu.lan@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Lan Tianyu 提交于
This patch is cosmetic only, and makes no functional change. Signed-off-by: NLan Tianyu <tianyu.lan@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 23 3月, 2011 1 次提交
-
-
由 Kyle McMartin 提交于
Commit da8aeb92 re-poked the battery on resume, but Linus reports that it broke his eee and partially reverted it in b23fffd7. Unfortunately this also results in my x201s giving crack values until the sysfs files are poked again. In the revert message, it was suggested that we poke it from a PM notifier, so let's do that. With this in place, I haven't noticed the units going nutty on my gnome-power-manager across a dozen suspends or so... Signed-off-by: NKyle McMartin <kyle@redhat.com> Acked-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 21 1月, 2011 1 次提交
-
-
由 Linus Torvalds 提交于
This partially reverts commit da8aeb92 ("ACPI / Battery: Update information on info notification and resume"), which causes a hang on resume on at least some machines. This bug was bisected on an ASUS EeePC 901, which hangs at resume time if we do that "acpi_battery_refresh(battery)" in the battery resume function. Rafael suspects we'll still need to refresh the sysfs files upon resume, but that that can be done from a PM notifier (that will run after thawing user space). Bisected-and-tested-by: NLinus Torvalds <torvalds@linux-foundation.org> Cc: Matthew Garrett <mjg@redhat.com> Cc: Len Brown <len.brown@intel.com> Acked-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 12 1月, 2011 2 次提交
-
-
由 Rafael J. Wysocki 提交于
A notification event 0x81 from an ACPI battery device requires us to re-read the battery information structure. Follow this requirement and remove and re-create the battery's attibutes in sysfs so that they reflect the reporting units used by the battery at the moment (those units may actually change sometimes at run time, which happens on some Thinkpads). The approach used in this patch was suggested by Matthew Garrett. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Reported-by: NMatthew Garrett <mjg@redhat.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Zhang Rui 提交于
sysfs I/F for ACPI power devices, including AC and Battery, has been working in upstream kenrel since 2.6.24, Sep 2007. In 2.6.37, we made the sysfs I/F always built in and this option disabled by default. Now, we plan to remove this option and the ACPI power procfs interface in 2.6.39. First, update the feature-removal-schedule to announce this change. Second, add runtime warnings in ACPI AC/Battery/SBS driver, so that users will notice this change even if "make oldconfig" is used. Signed-off-by: NZhang Rui <rui.zhang@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 25 12月, 2010 1 次提交
-
-
由 Len Brown 提交于
This reverts commit 3138b32d. as it caused a crash upon battery removal: https://bugzilla.kernel.org/show_bug.cgi?id=25302Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 10 12月, 2010 1 次提交
-
-
由 Zhang Rui 提交于
Sometimes the Battery driver doesn't get notifications when it's plugged/unplugged. And this results in the incorrect Battery status reported by the power supply sysfs I/F. Update Battery status first when querying from sysfs. http://marc.info/?l=linux-acpi&m=128855015826728&w=2 Tested_by: Seblu <seblu@seblu.net> Signed-off-by: NZhang Rui <rui.zhang@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 24 10月, 2010 1 次提交
-
-
由 Rafael J. Wysocki 提交于
The function acpi_battery_get_property() is called by the power supply framework's function power_supply_show_property() implementing the sysfs interface for power supply devices as the ACPI battery driver's ->get_property() callback. Thus it is supposed to return error code if the value of the given property is unknown. Unfortunately, however, it returns 0 in those cases and puts a wrong (negative) value into the intval field of the union power_supply_propval object provided by power_supply_show_property(). In consequence, wrong negative values are read by user space from the battery's sysfs files. Fix this by making acpi_battery_get_property() return -ENODEV for properties with unknown values (-ENODEV is returned, because power_supply_uevent() returns with error for any other error code returned by power_supply_show_property()). Reported-and-tested-by: NSitsofe Wheeler <sitsofe@yahoo.com> Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 22 10月, 2010 1 次提交
-
-
由 Zhang Rui 提交于
According to the ACPI spec, some kinds of primary battery can report percentage battery remaining capacity directly to OS. In this case, it reports the LastFullChargedCapacity == 100, BatteryPresentRate = 0xFFFFFFFF, and BatteryRemaingCapacity a percentage value, which actually means RemainingBatteryPercentage. Now we found some battery follows this rule even if it's a rechargeable. https://bugzilla.kernel.org/show_bug.cgi?id=15979 Handle these batteries correctly in ACPI battery driver so that they won't break userspace. Signed-off-by: NZhang Rui <rui.zhang@intel.com> Tested-by: NSitsofe Wheeler <sitsofe@yahoo.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 16 10月, 2010 1 次提交
-
-
由 Zhang Rui 提交于
ACPI AC/Battery/SBS driver has different kernel option for procfs and sysfs I/F. This patch, 1. Change CONFIG_ACPI_PROCFS_POWER to 'n' by default so that we can remove it in the next release or two. 2. Remove CONFIG_ACPI_SYSFS_POWER and always build in the sysfs I/F of these drivers. Signed-off-by: NZhang Rui <rui.zhang@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 31 8月, 2010 1 次提交
-
-
由 Matthew Garrett 提交于
ACPI batteries can report in units of either current or energy. Right now we expose the current_now file even if the battery is reporting energy units, resulting in a file that should contain mA instead containing mW. Don't expose this value unless the battery is reporting current. Signed-off-by: NMatthew Garrett <mjg@redhat.com> Cc: Arjan van de Ven <arjan@linux.intel.com> Acked-by: NRafael J. Wysocki <rjw@sisk.pl> Acked-by: NZhang Rui <rui.zhang@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 07 7月, 2010 1 次提交
-
-
由 Zhang Rui 提交于
When battery is hot-added, we should not invoke power_supply_changed in acpi_battery_notify, because it has been invoked in acpi_battery_update, and battery->bat.changed_work is queued in keventd already. https://bugzilla.kernel.org/show_bug.cgi?id=16244Signed-off-by: NZhang Rui <rui.zhang@intel.com> Acked-by: NAlexey Starikovskiy <astarikovskiy@sude.de> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 05 4月, 2010 2 次提交
-
-
由 Alan Jenkins 提交于
Calling kobject_uevent() directly is a layering violation. In particular, it means we'll miss updating the generic LED trigger. Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk> Acked-by: NAlexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Alan Jenkins 提交于
Disabling CONFIG_ACPI_SYSFS_POWER changes the behaviour of acpi_battery_update(). It will call acpi_battery_get_info() even if the battery is not present. I haven't noticed this causing any problem, but it does look like a bad idea. Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk> Acked-by: NAlexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 30 3月, 2010 1 次提交
-
-
由 Tejun Heo 提交于
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: NTejun Heo <tj@kernel.org> Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
-
- 28 1月, 2010 1 次提交
-
-
由 Lin Ming 提交于
acpi_integer is now obsolete and removed from the ACPICA code base, replaced by u64. Signed-off-by: NLin Ming <ming.m.lin@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 16 1月, 2010 2 次提交
-
-
由 Alexey Starikovskiy 提交于
Signed-off-by: NAlexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Alexey Starikovskiy 提交于
Signed-off-by: NAlexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 16 12月, 2009 1 次提交
-
-
由 Justin P. Mattock 提交于
Signed-off-by: NJustin P. Mattock <justinmattock@gmail.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 30 8月, 2009 1 次提交
-
-
由 Hector Martin 提交于
Acer Aspire 8930G laptops (and possibly others) report the battery current as a 16-bit signed negative when it is charging. It also reports it as 0x10000 when the current is 0. This patch adds a quirk for this which takes the absolute value of the reported current cast to an s16. This is a DSDT bug present in the latest BIOS revision (the EC register is 16 bits signed and the DSDT attempts to take the 16-bit two's complement of this, which works for discharge but not charge. It also breaks zero values because a 32-bit register is used and the high bits aren't thrown away). I've enabled this for all Acer systems which report in mA units. This should be safe since it won't break compliant systems unless they report a current above 32A, which is insane. The patch also detects the valid 32-bit value -1, which indicates unknown status, and does not attempt the fix in that case (note that this does not conflict with 16-bit -1, which is 65535 as read normally and gets translated to 1mA). Signed-off-by: NHector Martin <hector@marcansoft.com> Acked-by: NAlexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 29 8月, 2009 1 次提交
-
-
由 Len Brown 提交于
Linux/ACPI core files using internal.h all PREFIX "ACPI: ", however, not all ACPI drivers use/want it -- and they should not have to #undef PREFIX to define their own. Add GPL commment to internal.h while we are there. This does not change any actual console output, asside from a whitespace fix. Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 18 6月, 2009 2 次提交
-
-
由 Len Brown 提交于
drivers/acpi/battery.c:841: warning: label ‘end’ defined but not used 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. This driver apparently relies on seeing ALL notify events, not just device-specific ones (because it used ACPI_ALL_NOTIFY). We use the ACPI_DRIVER_ALL_NOTIFY_EVENTS driver flag to request all events. Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> CC: Alexey Starikovskiy <alexey.y.starikovskiy@linux.intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 12 4月, 2009 1 次提交
-
-
由 Linus Torvalds 提交于
This reverts commit 5d38258e, since the underlying problem got fixed properly in the previous commit ("async: Fix module loading async-work regression"). Cc: Arkadiusz Miskiewicz <a.miskiewicz@gmail.com> Cc: Vegard Nossum <vegard.nossum@gmail.com> Cc: Len Brown <len.brown@intel.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 08 4月, 2009 1 次提交
-
-
由 Vegard Nossum 提交于
> BUG: unable to handle kernel NULL pointer dereference at (null) What happens is that the battery module's init sections are being freed before the async callback (which was marked __init) has run. This theory is supported by the fact that the bad RIP value is a vmalloc address. The immediate fix is to make this a non-init call. (A better long-term fix is of course to wait with init-section unloading until a module's async initcalls have been run, which would allow us to discard this function which is still only run once, after all. Perhaps a new async_initcall() function for the async/module API, if this is needed for other modules in the future?) Reported-by: NArkadiusz Miskiewicz <a.miskiewicz@gmail.com> Signed-off-by: NVegard Nossum <vegard.nossum@gmail.com> Tested-by: NAlessandro Suardi <alessandro.suardi@gmail.com> Tested-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 05 4月, 2009 1 次提交
-
-
由 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>
-
- 04 4月, 2009 1 次提交
-
-
由 Jan Engelhardt 提交于
Signed-off-by: NJan Engelhardt <jengelh@medozas.de> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 31 3月, 2009 1 次提交
-
-
由 Alexey Dobriyan 提交于
Setting ->owner as done currently (pde->owner = THIS_MODULE) is racy as correctly noted at bug #12454. Someone can lookup entry with NULL ->owner, thus not pinning enything, and release it later resulting in module refcount underflow. We can keep ->owner and supply it at registration time like ->proc_fops and ->data. But this leaves ->owner as easy-manipulative field (just one C assignment) and somebody will forget to unpin previous/pin current module when switching ->owner. ->proc_fops is declared as "const" which should give some thoughts. ->read_proc/->write_proc were just fixed to not require ->owner for protection. rmmod'ed directories will be empty and return "." and ".." -- no harm. And directories with tricky enough readdir and lookup shouldn't be modular. We definitely don't want such modular code. Removing ->owner will also make PDE smaller. So, let's nuke it. Kudos to Jeff Layton for reminding about this, let's say, oversight. http://bugzilla.kernel.org/show_bug.cgi?id=12454Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
-
- 28 3月, 2009 1 次提交
-
-
由 Alexey Starikovskiy 提交于
ACPI has smart batteries, which work in units of energy and measure rate of (dis)charge as power, thus it is not appropriate to export it as a current_now. Current_now will still be exported to allow for userland applications to match. Signed-off-by: NAlexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: NLen Brown <len.brown@intel.com>
-