pci: debug extra pci resources range

Signed-off-by: Ingo Molnar <mingo@elte.hu>
pci: debug extra pci bus resources

Signed-off-by: Ingo Molnar <mingo@elte.hu>
[ARM] S3C24XX: s3c243xx_clock_register() data can be __initdata

Any data being passed to s3c243xx_clock_register() can be
marked as __initdata as it is an array of pointers to
'struct clk' that are to be registered on initialisation.

The s3c243xx_clock_register function uses this array to
register clocks and does not require it to stay around
after exit.

Signed-off-by: Ben Dooks <ben-linux@fluff.org>
[ARM] S3C24XX: Fix SERIAL_SAMSUNG entry

The SERIAL_SAMSUNG needs SERIAL_CORE but doesn't select it, leading to a
build failure. Adding a 'select SERIAL_CORE' cure the trouble.

Signed-off-by: Arnaud Patard <arnaud.patard@rtp-net.org>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6 into for-rmk
Merge branch 'linus' into pci-for-jesse
x86, pci: detect end_bus_number according to acpi/e820 reserved, v2

Jack Howarth reported that 2.6.26-rc9-git9 doesn't boot on MacBookPro2.

the reason is a faulty BIOS update that reportes faulty resources.

Nevertheless it's possible for Linux to be more resolent about this
situation (and similar situations) and work around this bug, by
cross-checking the mmconf range against the e820 table and ACPI resources.

Change the mconf bus range from [0,0xff] to to [0, 0x3f]
to match range [0xf0000000, 0xf4000000) in e820 tables.

[ v2, yhlu.kernel@gmail.com:
  x86, pci: detect end_bus_number according to acpi/e820 reserved - fix ]

Reported-by: Jack Howarth <howarth@bromo.msbb.uc.edu>
Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
Cc: jbarnes@virtuousgeek.org
Cc: Jack Howarth <howarth@bromo.msbb.uc.edu>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
lockd: trivial sparse endian annotations

fs/lockd/svcproc.c:115:11: warning: incorrect type in initializer (different base types)
fs/lockd/svcproc.c:115:11:    expected int [signed] rc
fs/lockd/svcproc.c:115:11:    got restricted __be32 [usertype] <noident>
... and so on...

Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
MAINTAINERS: mention lockd and sunrpc in nfs entries

The actual division of labor is a little vague in some of the common
code, but if the patches get to one of us then we can sort it out.

Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
x64, fpu: fix possible FPU leakage in error conditions

On Thu, Jul 24, 2008 at 03:43:44PM -0700, Linus Torvalds wrote:
> So how about this patch as a starting point? This is the RightThing(tm) to
> do regardless, and if it then makes it easier to do some other cleanups,
> we should do it first. What do you think?

restore_fpu_checking() calls init_fpu() in error conditions.

While this is wrong(as our main intention is to clear the fpu state of
the thread), this was benign before commit 92d140e21f1 ("x86: fix taking
DNA during 64bit sigreturn").

Post commit 92d140e21f1, live FPU registers may not belong to this
process at this error scenario.

In the error condition for restore_fpu_checking() (especially during the
64bit signal return), we are doing init_fpu(), which saves the live FPU
register state (possibly belonging to some other process context) into
the thread struct (through unlazy_fpu() in init_fpu()). This is wrong
and can leak the FPU data.

For the signal handler restore error condition in restore_i387(), clear
the fpu state present in the thread struct(before ultimately sending a
SIGSEGV for badframe).

For the paranoid error condition check in math_state_restore(), send a
SIGSEGV, if we fail to restore the state.

Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: <stable@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Input: wm97xx - enable sub-drivers by default

Currently the support for each WM97xx touchscreen model is compiled out
by default, meaning that the default configuration when the driver is
built is for it to support no hardware.  This is suboptimal and leads to
problems like distribution kernels shipping a non-functional driver.

Change the default to support all controllers and update the help text
to reflect this.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Input: gpio-keys - fix possible NULL pointer dereference

bdata->button is used in gpio_check_button but never initialized.  Having a
device with debounce_interval != 0 without this patch resulted on an oops on
my machine.

Signed-off-by: Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Input: gpio-keys - make gpio_keys_device_driver static

This fixes the sparse warning

	symbol 'gpio_keys_device_driver' was not declared. Should it be static?

Signed-off-by: Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
fs/nfsd/export.c: Adjust error handling code involving auth_domain_put

Once clp is assigned, it never becomes NULL, so we can make a label for it
in the error handling code.  Because the call to path_lookup follows the
call to auth_domain_find, its error handling code should jump to this new
label.

The semantic match that finds this problem is as follows:
(http://www.emn.fr/x-info/coccinelle/)

// <smpl>
@r@
expression x,E;
statement S;
position p1,p2,p3;
@@

(
if ((x = auth_domain_find@p1(...)) == NULL || ...) S
|
x = auth_domain_find@p1(...)
... when != x
if (x == NULL || ...) S
)
<...
if@p3 (...) { ... when != auth_domain_put(x)
                  when != if (x) { ... auth_domain_put(x); ...}
    return@p2 ...;
}
...>
(
return x;
|
return 0;
|
x = E
|
E = x
|
auth_domain_put(x)
)

@exists@
position r.p1,r.p2,r.p3;
expression x;
int ret != 0;
statement S;
@@

* x = auth_domain_find@p1(...)
  <...
* if@p3 (...)
  S
  ...>
* return@p2 \(NULL\|ret\);
// </smpl>

Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Input: xpad - add Pelican Eclipse D-Pad to the list of devices

Signed-off-by: Harley Laue <losinggeneration@gmail.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Make writes to md/safe_mode_delay immediately effective.

If we reduce the 'safe_mode_delay', it could still wait for the old
delay to completely expire before doing anything about safe_mode.
Thus the effect if the change is delayed.

To make the effect more immediate, run the timeout function
immediately if the delay was reduced.  This may cause it to run
slightly earlier that required, but that is the safer option.

Signed-off-by: NeilBrown <neilb@suse.de>
Restore force switch of md array to readonly at reboot time.

A recent patch allowed do_md_stop to know whether it was being called
via an ioctl or not, and thus where to allow for an extra open file
descriptor when checking if it is in use.
This broke then switch to readonly performed by the shutdown notifier,
which needs to work even when the array is still (apparently) active
(as md doesn't get told when the filesystem becomes readonly).

So restore this feature by pretending that there can be lots of
file descriptors open, but we still want do_md_stop to switch to
readonly.

Signed-off-by: NeilBrown <neilb@suse.de>
Fail safely when trying to grow an array with a write-intent bitmap.

We cannot currently change the size of a write-intent bitmap.
So if we change the size of an array which has such a bitmap, it
tries to set bits beyond the end of the bitmap.

For now, simply reject any request to change the size of an array
which has a bitmap.  mdadm can remove the bitmap and add a new one
after the array has changed size.

Signed-off-by: NeilBrown <neilb@suse.de>
Don't let a blocked_rdev interfere with read request in raid5/6

When we have externally managed metadata, we need to mark a failed
device as 'Blocked' and not allow any writes until that device
have been marked as faulty in the metadata and the Blocked flag has
been removed.

However it is perfectly OK to allow read requests when there is a
Blocked device, and with a readonly array, there may not be any
metadata-handler watching for blocked devices.

So in raid5/raid6 only allow a Blocked device to interfere with
Write request or resync.  Read requests go through untouched.

raid1 and raid10 already differentiate between read and write
properly.

Signed-off-by: NeilBrown <neilb@suse.de>
Allow faulty devices to be removed from a readonly array.

Removing faulty devices from an array is a two stage process.
First the device is moved from being a part of the active array
to being similar to a spare device.  Then it can be removed
by a request from user space.

The first step is currently not performed for read-only arrays,
so the second step can never succeed.

So allow readonly arrays to remove failed devices (which aren't
blocked).

Signed-off-by: NeilBrown <neilb@suse.de>