linux-stable.git/drivers/base, branch v3.3.1 Linux kernel stable tree PM / Domains: Introduce "always on" device flag 2012-04-02T17:32:10+00:00 Rafael J. Wysocki rjw@sisk.pl 2012-03-26T21:25:24+00:00 166a1687a4d1ad2fa237452355a5ec018dc68cc5 This is a backport of mainline commit 1e78a0c7fc92aee076965d516cf54475c39e9894. The TMU device on the Mackerel board belongs to the A4R power domain and loses power when the domain is turned off. Unfortunately, the TMU driver is not prepared to cope with such situations and crashes the system when that happens. To work around this problem introduce a new helper function, pm_genpd_dev_always_on(), allowing a device driver to mark its device as "always on" in case it belongs to a PM domain, which will make the generic PM domains core code avoid powering off the domain containing the device, both at run time and during system suspend. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Tested-by: Simon Horman <horms@verge.net.au> Acked-by: Paul Mundt <lethal@linux-sh.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
This is a backport of mainline commit
1e78a0c7fc92aee076965d516cf54475c39e9894.

The TMU device on the Mackerel board belongs to the A4R power domain
and loses power when the domain is turned off.  Unfortunately, the
TMU driver is not prepared to cope with such situations and crashes
the system when that happens.  To work around this problem introduce
a new helper function, pm_genpd_dev_always_on(), allowing a device
driver to mark its device as "always on" in case it belongs to a PM
domain, which will make the generic PM domains core code avoid
powering off the domain containing the device, both at run time and
during system suspend.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Tested-by: Simon Horman <horms@verge.net.au>
Acked-by: Paul Mundt <lethal@linux-sh.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
PM / Domains: Check domain status during hibernation restore of devices 2012-04-02T17:32:10+00:00 Rafael J. Wysocki rjw@sisk.pl 2012-03-26T21:24:40+00:00 fd0682d1b4f47792cfe668c7979d73f168e9f1aa This is a backport of mainline commit 18dd2ece3cde14cfd42e95a89eb14016699a5f15. Power domains that were off before hibernation shouldn't be turned on during device restore, so prevent that from happening. This change fixed up mainline commit 65533bbf63b4f37723fdfedc73d0653958973323 PM / Domains: Fix hibernation restore of devices, v2 that didn't include it by mistake. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
This is a backport of mainline commit
18dd2ece3cde14cfd42e95a89eb14016699a5f15.

Power domains that were off before hibernation shouldn't be turned on
during device restore, so prevent that from happening.

This change fixed up mainline commit
65533bbf63b4f37723fdfedc73d0653958973323

    PM / Domains: Fix hibernation restore of devices, v2

that didn't include it by mistake.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
PM / Domains: Fix hibernation restore of devices, v2 2012-04-02T17:32:09+00:00 Rafael J. Wysocki rjw@sisk.pl 2012-03-26T21:23:59+00:00 8119557d5627c7a823641a7c5c307f709e2d5b04 This is a backport of mainline commit 65533bbf63b4f37723fdfedc73d0653958973323. During resume from hibernation pm_genpd_restore_noirq() should only power off domains whose suspend_power_off flags are set once and not every time it is called for a device in the given domain. Moreover, it shouldn't decrement genpd->suspended_count, because that field is not touched during device freezing and therefore it is always equal to 0 when pm_genpd_restore_noirq() runs for the first device in the given domain. This means pm_genpd_restore_noirq() may use genpd->suspended_count to determine whether or not it it has been called for the domain in question already in this cycle (it only needs to increment that field every time it runs for this purpose) and whether or not it should check if the domain needs to be powered off. For that to work, though, pm_genpd_prepare() has to clear genpd->suspended_count when it runs for the first device in the given domain (in which case that flag need not be cleared during domain initialization). Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
This is a backport of mainline commit
65533bbf63b4f37723fdfedc73d0653958973323.

During resume from hibernation pm_genpd_restore_noirq() should only
power off domains whose suspend_power_off flags are set once and
not every time it is called for a device in the given domain.
Moreover, it shouldn't decrement genpd->suspended_count, because
that field is not touched during device freezing and therefore it is
always equal to 0 when pm_genpd_restore_noirq() runs for the first
device in the given domain.

This means pm_genpd_restore_noirq() may use genpd->suspended_count
to determine whether or not it it has been called for the domain in
question already in this cycle (it only needs to increment that
field every time it runs for this purpose) and whether or not it
should check if the domain needs to be powered off.  For that to
work, though, pm_genpd_prepare() has to clear genpd->suspended_count
when it runs for the first device in the given domain (in which case
that flag need not be cleared during domain initialization).

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
PM / Domains: Fix handling of wakeup devices during system resume 2012-04-02T17:31:54+00:00 Rafael J. Wysocki rjw@sisk.pl 2012-03-13T21:39:31+00:00 a4538d45e9cae29742c27f6e83ddb1f209afea46 commit cc85b20780562d404e18a47b9b55b4a5102ae53e upstream. During system suspend pm_genpd_suspend_noirq() checks if the given device is in a wakeup path (i.e. it appears to be needed for one or more wakeup devices to work or is a wakeup device itself) and if it needs to be "active" for wakeup to work. If that is the case, the function returns 0 without incrementing the device domain's counter of suspended devices and without executing genpd_stop_dev() for the device. In consequence, the device is not stopped (e.g. its clock isn't disabled) and power is always supplied to its domain in the resulting system sleep state. However, pm_genpd_resume_noirq() doesn't repeat that check and it runs genpd_start_dev() and decrements the domain's counter of suspended devices even for the wakeup device that weren't stopped by pm_genpd_suspend_noirq(). As a result, the start callback may be run unnecessarily for them and their domains' counters of suspended devices may become negative. Both outcomes aren't desirable, so fix pm_genpd_resume_noirq() to look for wakeup devices that might not be stopped by during system suspend. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Tested-by: Simon Horman <horms@verge.net.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit cc85b20780562d404e18a47b9b55b4a5102ae53e upstream.

During system suspend pm_genpd_suspend_noirq() checks if the given
device is in a wakeup path (i.e. it appears to be needed for one or
more wakeup devices to work or is a wakeup device itself) and if it
needs to be "active" for wakeup to work.  If that is the case, the
function returns 0 without incrementing the device domain's counter
of suspended devices and without executing genpd_stop_dev() for the
device.  In consequence, the device is not stopped (e.g. its clock
isn't disabled) and power is always supplied to its domain in the
resulting system sleep state.

However, pm_genpd_resume_noirq() doesn't repeat that check and it
runs genpd_start_dev() and decrements the domain's counter of
suspended devices even for the wakeup device that weren't stopped by
pm_genpd_suspend_noirq().  As a result, the start callback may be run
unnecessarily for them and their domains' counters of suspended
devices may become negative.  Both outcomes aren't desirable, so fix
pm_genpd_resume_noirq() to look for wakeup devices that might not be
stopped by during system suspend.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Tested-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap 2012-02-18T23:37:25+00:00 Linus Torvalds torvalds@linux-foundation.org 2012-02-18T23:37:25+00:00 bff98bfcdb2124e4e640fa6d7c9c7c3d21362760 Fixes a bootstrapping issue for some registers when a less commonly used method for register cache initialisation is used. Only affects a fairly small proportion of users that both don't use explicit register defaults and do use the cache. * tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap: regmap: Fix cache defaults initialization from raw cache defaults 
Fixes a bootstrapping issue for some registers when a less commonly used
method for register cache initialisation is used.  Only affects a fairly
small proportion of users that both don't use explicit register defaults
and do use the cache.

* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap:
  regmap: Fix cache defaults initialization from raw cache defaults
regmap: Fix cache defaults initialization from raw cache defaults 2012-02-15T16:31:32+00:00 Lars-Peter Clausen lars@metafoo.de 2012-02-15T09:23:25+00:00 61cddc57dc14a5dffa0921d9a24fd68edbb374ac Currently registers with a value of 0 are ignored when initializing the register defaults from raw defaults. This worked in the past, because registers without a explicit default were assumed to have a default value of 0. This was changed in commit b03622a8 ("regmap: Ensure rbtree syncs registers set to zero properly"). As a result registers, which have a raw default value of 0 are now assumed to have no default. This again can result in unnecessary writes when syncing the cache. It will also result in unnecessary reads for e.g. the first update operation. In the case where readback is not possible this will even let the update operation fail, if the register has not been written to before. So this patch removes the check. Instead it adds a check to ignore raw defaults for registers which are volatile, since those registers are not cached. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: stable@vger.kernel.org 
Currently registers with a value of 0 are ignored when initializing the register
defaults from raw defaults. This worked in the past, because registers without a
explicit default were assumed to have a default value of 0. This was changed in
commit b03622a8 ("regmap: Ensure rbtree syncs registers set to zero properly").
As a result registers, which have a raw default value of 0 are now assumed to
have no default. This again can result in unnecessary writes when syncing the
cache. It will also result in unnecessary reads for e.g. the first update
operation. In the case where readback is not possible this will even let the
update operation fail, if the register has not been written to before.

So this patch removes the check. Instead it adds a check to ignore raw defaults
for registers which are volatile, since those registers are not cached.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@vger.kernel.org
driver-core: cpu: fix kobject warning when hotplugging a cpu 2012-02-08T23:11:17+00:00 Greg Kroah-Hartman gregkh@linuxfoundation.org 2012-02-08T23:11:17+00:00 29bb5d4fd3140a7d5d02d858118c74a45f15c296 Due to the sysdev conversion to struct device, the cpu objects get reused when adding a cpu after offlining it, which causes a big warning that the kobject portion is not properly initialized. So clear out the object before we register it again, so all is quiet. Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
Due to the sysdev conversion to struct device, the cpu objects get
reused when adding a cpu after offlining it, which causes a big warning
that the kobject portion is not properly initialized.

So clear out the object before we register it again, so all is quiet.

Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drivers/base/memory.c: fix memory_dev_init() long delay 2012-02-02T23:50:05+00:00 Yinghai Lu yinghai@kernel.org 2012-01-30T21:57:12+00:00 321bf4ed5ff5f7c62ef59f33b7eec5b154391f0a One system with 2048g ram, reported soft lockup on recent kernel. [ 34.426749] cpu_dev_init done [ 61.166399] BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:1] [ 61.166733] Modules linked in: [ 61.166904] irq event stamp: 1935610 [ 61.178431] hardirqs last enabled at (1935609): [<ffffffff81ce8c05>] mutex_lock_nested+0x299/0x2b4 [ 61.178923] hardirqs last disabled at (1935610): [<ffffffff81cf2bab>] apic_timer_interrupt+0x6b/0x80 [ 61.198767] softirqs last enabled at (1935476): [<ffffffff8106e59c>] __do_softirq+0x195/0x1ab [ 61.218604] softirqs last disabled at (1935471): [<ffffffff81cf359c>] call_softirq+0x1c/0x30 [ 61.238408] CPU 0 [ 61.238549] Modules linked in: [ 61.238744] [ 61.238825] Pid: 1, comm: swapper/0 Not tainted 3.3.0-rc1-tip-yh-02076-g962f689-dirty #171 [ 61.278212] RIP: 0010:[<ffffffff810b3e3a>] [<ffffffff810b3e3a>] lock_release+0x90/0x9c [ 61.278627] RSP: 0018:ffff883f64dbfd70 EFLAGS: 00000246 [ 61.298287] RAX: ffff883f64dc0000 RBX: 0000000000000000 RCX: 000000000000008b [ 61.298690] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 61.318383] RBP: ffff883f64dbfda0 R08: 0000000000000001 R09: 000000000000008b [ 61.338215] R10: 0000000000000000 R11: 0000000000000000 R12: ffff883f64dbfd10 [ 61.338610] R13: ffff883f64dc0708 R14: ffff883f64dc0708 R15: ffffffff81095657 [ 61.358299] FS: 0000000000000000(0000) GS:ffff883f7d600000(0000) knlGS:0000000000000000 [ 61.378118] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 61.378450] CR2: 0000000000000000 CR3: 00000000024af000 CR4: 00000000000007f0 [ 61.398144] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 61.417918] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 61.418260] Process swapper/0 (pid: 1, threadinfo ffff883f64dbe000, task ffff883f64dc0000) [ 61.445358] Stack: [ 61.445511] 0000000000000002 ffff897f649ba168 ffff883f64dbfe10 ffff88ff64bb57a8 [ 61.458040] 0000000000000000 0000000000000000 ffff883f64dbfdc0 ffffffff81ceb1b4 [ 61.458491] 000000000011608c ffff88ff64bb58a8 ffff883f64dbfdf0 ffffffff81c57638 [ 61.478215] Call Trace: [ 61.478367] [<ffffffff81ceb1b4>] _raw_spin_unlock+0x21/0x2e [ 61.497994] [<ffffffff81c57638>] klist_next+0x9e/0xbc [ 61.498264] [<ffffffff8148ba99>] next_device+0xe/0x1e [ 61.517867] [<ffffffff8148c0cc>] subsys_find_device_by_id+0xb7/0xd6 [ 61.518197] [<ffffffff81498846>] find_memory_block_hinted+0x3d/0x66 [ 61.537927] [<ffffffff8149887f>] find_memory_block+0x10/0x12 [ 61.538193] [<ffffffff814988b6>] add_memory_section+0x35/0x9e [ 61.557932] [<ffffffff827fecef>] memory_dev_init+0x68/0xda [ 61.558227] [<ffffffff827fec01>] driver_init+0x97/0xa7 [ 61.577853] [<ffffffff827cdf3c>] kernel_init+0xf6/0x1c0 [ 61.578140] [<ffffffff81cf34a4>] kernel_thread_helper+0x4/0x10 [ 61.597850] [<ffffffff81ceb59d>] ? retint_restore_args+0xe/0xe [ 61.598144] [<ffffffff827cde46>] ? start_kernel+0x3ab/0x3ab [ 61.617826] [<ffffffff81cf34a0>] ? gs_change+0xb/0xb [ 61.618060] Code: 10 48 83 3b 00 eb e8 4c 89 f2 44 89 fe 4c 89 ef e8 e1 fe ff ff 65 48 8b 04 25 40 bc 00 00 c7 80 cc 06 00 00 00 00 00 00 41 54 9d <5e> 5b 41 5c 41 5d 41 5e 41 5f 5d c3 55 48 89 e5 41 57 41 89 cf [ 89.285380] memory_dev_init done Finally it takes about 55s to create 16400 memory entries. Root cause: for x86_64, 2048g (with 2g hole at [2g,4g), and TOP2 will be 2050g), will have 16400 memory block. find_memory_block/subsys_find_device_by_id will be expensive with that many entries. Actually, we don't need to find that memory block for BOOT path. Skip that finding make it get back to normal. [ 34.466696] cpu_dev_init done [ 35.290080] memory_dev_init done Also solved the delay with topology_init when sections_per_block is not 1. Signed-off-by: Yinghai Lu <yinghai@kernel.org> Cc: Kay Sievers <kay.sievers@vrfy.org> Cc: Nathan Fontenot <nfont@austin.ibm.com> Cc: Robin Holt <holt@sgi.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
One system with 2048g ram, reported soft lockup on recent kernel.

[   34.426749] cpu_dev_init done
[   61.166399] BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:1]
[   61.166733] Modules linked in:
[   61.166904] irq event stamp: 1935610
[   61.178431] hardirqs last  enabled at (1935609): [<ffffffff81ce8c05>] mutex_lock_nested+0x299/0x2b4
[   61.178923] hardirqs last disabled at (1935610): [<ffffffff81cf2bab>] apic_timer_interrupt+0x6b/0x80
[   61.198767] softirqs last  enabled at (1935476): [<ffffffff8106e59c>] __do_softirq+0x195/0x1ab
[   61.218604] softirqs last disabled at (1935471): [<ffffffff81cf359c>] call_softirq+0x1c/0x30
[   61.238408] CPU 0
[   61.238549] Modules linked in:
[   61.238744]
[   61.238825] Pid: 1, comm: swapper/0 Not tainted 3.3.0-rc1-tip-yh-02076-g962f689-dirty #171
[   61.278212] RIP: 0010:[<ffffffff810b3e3a>]  [<ffffffff810b3e3a>] lock_release+0x90/0x9c
[   61.278627] RSP: 0018:ffff883f64dbfd70  EFLAGS: 00000246
[   61.298287] RAX: ffff883f64dc0000 RBX: 0000000000000000 RCX: 000000000000008b
[   61.298690] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
[   61.318383] RBP: ffff883f64dbfda0 R08: 0000000000000001 R09: 000000000000008b
[   61.338215] R10: 0000000000000000 R11: 0000000000000000 R12: ffff883f64dbfd10
[   61.338610] R13: ffff883f64dc0708 R14: ffff883f64dc0708 R15: ffffffff81095657
[   61.358299] FS:  0000000000000000(0000) GS:ffff883f7d600000(0000) knlGS:0000000000000000
[   61.378118] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[   61.378450] CR2: 0000000000000000 CR3: 00000000024af000 CR4: 00000000000007f0
[   61.398144] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   61.417918] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[   61.418260] Process swapper/0 (pid: 1, threadinfo ffff883f64dbe000, task ffff883f64dc0000)
[   61.445358] Stack:
[   61.445511]  0000000000000002 ffff897f649ba168 ffff883f64dbfe10 ffff88ff64bb57a8
[   61.458040]  0000000000000000 0000000000000000 ffff883f64dbfdc0 ffffffff81ceb1b4
[   61.458491]  000000000011608c ffff88ff64bb58a8 ffff883f64dbfdf0 ffffffff81c57638
[   61.478215] Call Trace:
[   61.478367]  [<ffffffff81ceb1b4>] _raw_spin_unlock+0x21/0x2e
[   61.497994]  [<ffffffff81c57638>] klist_next+0x9e/0xbc
[   61.498264]  [<ffffffff8148ba99>] next_device+0xe/0x1e
[   61.517867]  [<ffffffff8148c0cc>] subsys_find_device_by_id+0xb7/0xd6
[   61.518197]  [<ffffffff81498846>] find_memory_block_hinted+0x3d/0x66
[   61.537927]  [<ffffffff8149887f>] find_memory_block+0x10/0x12
[   61.538193]  [<ffffffff814988b6>] add_memory_section+0x35/0x9e
[   61.557932]  [<ffffffff827fecef>] memory_dev_init+0x68/0xda
[   61.558227]  [<ffffffff827fec01>] driver_init+0x97/0xa7
[   61.577853]  [<ffffffff827cdf3c>] kernel_init+0xf6/0x1c0
[   61.578140]  [<ffffffff81cf34a4>] kernel_thread_helper+0x4/0x10
[   61.597850]  [<ffffffff81ceb59d>] ? retint_restore_args+0xe/0xe
[   61.598144]  [<ffffffff827cde46>] ? start_kernel+0x3ab/0x3ab
[   61.617826]  [<ffffffff81cf34a0>] ? gs_change+0xb/0xb
[   61.618060] Code: 10 48 83 3b 00 eb e8 4c 89 f2 44 89 fe 4c 89 ef e8 e1 fe ff ff 65 48 8b 04 25 40 bc 00 00 c7 80 cc 06 00 00 00 00 00 00 41 54 9d <5e> 5b 41 5c 41 5d 41 5e 41 5f 5d c3 55 48 89 e5 41 57 41 89 cf
[   89.285380] memory_dev_init done

Finally it takes about 55s to create 16400 memory entries.

Root cause: for x86_64, 2048g (with 2g hole at [2g,4g), and TOP2 will be 2050g), will have 16400 memory block.

find_memory_block/subsys_find_device_by_id will be expensive with that many entries.

Actually, we don't need to find that memory block for BOOT path.

Skip that finding make it get back to normal.

[   34.466696] cpu_dev_init done
[   35.290080] memory_dev_init done

Also solved the delay with topology_init when sections_per_block is not 1.

Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Cc: Kay Sievers <kay.sievers@vrfy.org>
Cc: Nathan Fontenot <nfont@austin.ibm.com>
Cc: Robin Holt <holt@sgi.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
driver core: cpu: remove kernel warning when removing a cpu 2012-02-02T18:43:16+00:00 Greg Kroah-Hartman gregkh@linuxfoundation.org 2012-02-02T18:36:33+00:00 2885e25c422fb68208f677f944a45fce8eda2a3c With the movement of the cpu sysdev code to be real stuct devices, now when we remove a cpu from the system, the driver core rightfully complains that there is not a release method for this device. For now, paper over this issue by quieting the driver core, but comment this in detail. This will be resolved in future kernels to be solved properly. Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
With the movement of the cpu sysdev code to be real stuct devices, now
when we remove a cpu from the system, the driver core rightfully
complains that there is not a release method for this device.

For now, paper over this issue by quieting the driver core, but comment
this in detail.  This will be resolved in future kernels to be solved
properly.

Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Merge tag 'driver-core-3.3-rc1-bugfixes' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core 2012-01-29T02:20:48+00:00 Linus Torvalds torvalds@linux-foundation.org 2012-01-29T02:20:48+00:00 0a9626575400879d1d5e6bc8768188b938d7c501 Here are some patches for the 3.3-rc1 tree. It contains the removal of the sysdev code, now that all users of it are gone, as well as some sysfs bugfixes that have been reported by users. There are also some documentation updates here as well. * tag 'driver-core-3.3-rc1-bugfixes' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: sysfs: Complain bitterly about attempts to remove files from nonexistent directories. stable: update documentation to ask for kernel version base/core.c:fix typo in comment in function device_add Documentation: devres: add allocation functions to list of supported calls Documentation update for the driver model core kernel-doc: fix new warnings in driver-core kernel-doc: fix new warnings in debugfs kernel-doc: fix new warnings in device.h driver core: remove drivers/base/sys.c and include/linux/sysdev.h 
Here are some patches for the 3.3-rc1 tree.

It contains the removal of the sysdev code, now that all users of it are
gone, as well as some sysfs bugfixes that have been reported by users.
There are also some documentation updates here as well.

* tag 'driver-core-3.3-rc1-bugfixes' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core:
  sysfs: Complain bitterly about attempts to remove files from nonexistent directories.
  stable: update documentation to ask for kernel version
  base/core.c:fix typo in comment in function device_add
  Documentation: devres: add allocation functions to list of supported calls
  Documentation update for the driver model core
  kernel-doc: fix new warnings in driver-core
  kernel-doc: fix new warnings in debugfs
  kernel-doc: fix new warnings in device.h
  driver core: remove drivers/base/sys.c and include/linux/sysdev.h