This patch fix a following bug and does a cleanup.

bug:
	commit 5993760f
	had a wrong change (since is_64 is boolean[0|1]):

-               pci_write_config_dword(dev,
-                       msi_mask_bits_reg(pos, is_64bit_address(control)),
-                       maskbits);
+               pci_write_config_dword(dev, entry->msi_attrib.is_64, maskbits);

utilize:
	Unify separated if (entry->msi_attrib.maskbit) statements.
Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Acked-by: N"Jike Song" <albcamus@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

This reverts commit 98e6e286, as Yinghai
Lu reports that it breaks kexec with at least the e1000 and e1000e
drivers.  The reason is that the shutdown sequence puts the hardware
into D3 sleep, and the commit causes us to claim that it then is in D0
(running) state just because we don't understand the PM capabilities.

Which then later makes "pci_set_power_state()" not do anything, and the
device never wakes up properly and just returns 0xff to everything.
Reported-by: NYinghai Lu <yinghai@kernel.org>
Acked-by: NFrom: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Jesse Barnes <jesse.barnes@intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

while I was looking over kernel sources I've found this small bug.

Formerly, zero was returned even if an error happened.
Signed-off-by: NMichal Sojka <sojkam1@fel.cvut.cz>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

drivers/ata/pata_ali.c:44: error: static declaration of 'isa_bridge' follows non-static declaration
arch/alpha/include/asm/pci.h:274: error: previous declaration of 'isa_bridge' was here

Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Jeff Garzik <jeff@garzik.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

Cavium OCTEON processor support was recently merged, so now we have
this CF driver for your consideration.

Most OCTEON variants have *no* DMA or interrupt support on the CF
interface so for these, only PIO is supported.  Although if DMA is
available, we do take advantage of it.
Signed-off-by: NDavid Daney <ddaney@caviumnetworks.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

The forthcoming OCTEON SOC Compact Flash driver needs an additional
timing value that was not available in the ata_timing table.  I add a
new column for dmack_hold time.  The values were obtained from the
Compact Flash specification Rev 4.1.
Signed-off-by: NDavid Daney <ddaney@caviumnetworks.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

Signed-off-by: NJoseph Chan <josephchan@via.com.tw>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

Port enabledness test fits much better into init_one() instead of
pre_reset().  The reason why these tests are in pre_reset() is purely
historical at this point.  Move it to init_one().  This will help
further changes.
Signed-off-by: NTejun Heo <tj@kernel.org>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

for SAS drivers.

Caught by Ke Wei (and team?) at Marvell.

Also, move the ata_scsi_ioctl export to libata-scsi.c, as that seems to be the
general trend.
Acked-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

This makes sure the mutex is held around the unreference.
Signed-off-by: NDave Airlie <airlied@redhat.com>

This is an initial patch to do support for objects which needs physical
contiguous main ram, cursors and overlay registers on older chipsets.

These objects are bound on cursor bin, like pinning, and we copy
the data to/from the backing store object into the real one on attach/detach.

notes:
possible over the top in attach/detach operations.
no overlay support yet.
Signed-off-by: NDave Airlie <airlied@redhat.com>

The detected fixed panel mode really is preferred, so mark it as such and
add it to the LVDS connector mode list.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@linux.ie>

Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@linux.ie>

When mode setting is first initialized, the driver will call into
drm_helper_initial_config() to set up an initial output and framebuffer
configuration.  This routine is responsible for probing the available
connectors, encoders, and crtcs, looking for modes and putting together
something reasonable (where reasonable is defined as "allows kernel
messages to be visible on as many displays as possible").

However, the code was a bit too aggressive in setting default modes when
none were found on a given connector.  Even if some connectors had modes,
any connectors found lacking modes would have the default 800x600 mode added
to their mode list, which in some cases could cause problems later down the
line.  In my case, the LVDS was perfectly available, but the initial config
code added 800x600 modes to both of the detected but unavailable HDMI
connectors (which are on my non-existent docking station).  This ended up
preventing later code from setting a mode on my LVDS, which is bad.

This patch fixes that behavior by making the initial config code walk
through the connectors first, counting the available modes, before it decides
to add any default modes to a possibly connected output.  It also fixes the
logic in drm_target_preferred() that was causing zeroed out modes to be set
as the preferred mode for a given connector, even if no modes were available.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@linux.ie>

This patch adds support for "ns16850" as supported value
of the compatible node in flat device tree uart descriptions.

This is needed for example when you have a XR16C2850 uart
connected to a PPC405's external bus controller.
Signed-off-by: NMatthias Fuchs <mfuchs@ma-fu.de>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

This patch removes the tty->low_latency setting.

For irq based hvc_console backends the tty->low_latency must be set to 0,
because the tty_flip_buffer_push() function must not be called from IRQ context
(see drivers/char/tty_buffer.c).

For polled backends, the low_latency setting causes the bug trace below, because
tty_flip_buffer_push() is called within an atomic context and subsequent calls
might sleep due to mutex_lock.

BUG: sleeping function called from invalid context at /root/cvs/linux-2.6.git/kernel/mutex.c:207
in_atomic(): 1, irqs_disabled(): 0, pid: 748, name: khvcd
1 lock held by khvcd/748:
 #0:  (hvc_structs_lock){--..}, at: [<00000000002ceb50>] khvcd+0x58/0x12c
CPU: 0 Not tainted 2.6.29-rc1git #29
Process khvcd (pid: 748, task: 000000002fb9a480, ksp: 000000002f66bd78)
070000000000000a 000000002f66ba00 0000000000000002 (null)
       000000002f66baa0 000000002f66ba18 000000002f66ba18 0000000000104f08
       ffffffffffffc000 000000002f66bd78 (null) (null)
       000000002f66ba00 000000000000000c 000000002f66ba00 000000002f66ba70
       0000000000466af8 0000000000104f08 000000002f66ba00 000000002f66ba50
Call Trace:
([<0000000000104e7c>] show_trace+0x138/0x158)
 [<0000000000104f62>] show_stack+0xc6/0xf8
 [<0000000000105740>] dump_stack+0xb0/0xc0
 [<000000000013144a>] __might_sleep+0x14e/0x17c
 [<000000000045e226>] mutex_lock_nested+0x42/0x3b4
 [<00000000002c443e>] echo_char_raw+0x3a/0x9c
 [<00000000002c688c>] n_tty_receive_buf+0x1154/0x1208
 [<00000000002ca0a2>] flush_to_ldisc+0x152/0x220
 [<00000000002ca1da>] tty_flip_buffer_push+0x6a/0x90
 [<00000000002cea74>] hvc_poll+0x244/0x2c8
 [<00000000002ceb68>] khvcd+0x70/0x12c
 [<000000000015bbd0>] kthread+0x68/0xa0
 [<0000000000109d5a>] kernel_thread_starter+0x6/0xc
 [<0000000000109d54>] kernel_thread_starter+0x0/0xc
1 lock held by khvcd/748:
 #0:  (hvc_structs_lock){--..}, at: [<00000000002ceb50>] khvcd+0x58/0x12c
Signed-off-by: NHendrik Brueckner <brueckner@linux.vnet.ibm.com>
Acked-by: NChristian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Acked-by: NGeoff Levand <geoffrey.levand@am.sony.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Acked-by: NGeoff Levand <geoffrey.levand@am.sony.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Also some min -> mint_t conversion.
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Acked-by: NGeoff Levand <geoffrey.levand@am.sony.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Also a couple of min -> min_t changes.
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Acked-by: NGeoff Levand <geoffrey.levand@am.sony.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Acked-by: NGeoff Levand <geoffrey.levand@am.sony.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

We just fix up the reference parameters as the others are dealt with by
arithmetic promotion rules and don't cause warnings.

This removes warnings like this:

arch/powerpc/platforms/ps3/interrupt.c:327: warning: passing argument 1 of 'lv1_construct_event_receive_port' from incompatible pointer type

Also, these:

drivers/ps3/ps3-vuart.c:462: warning: passing argument 4 of 'ps3_vuart_raw_read' from incompatible pointer type
drivers/ps3/ps3-vuart.c:592: warning: passing argument 4 of 'ps3_vuart_raw_read' from incompatible pointer type
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Acked-by: NGeoff Levand <geoffrey.levand@am.sony.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

This is a powerpc specific driver.
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Carry out the PM-routine interface change in the USB OTG pathway.  This
was omitted from the earlier interface-change patch by mistake.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: Greg KH <greg@kroah.com>
Cc: Russell King <rmk@arm.linux.org.uk>
Cc: Felipe Balbi <felipe.balbi@nokia.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The LED on HP notebooks is connected through ACPI.  That unfortunately
means that it needs to be delayed by using schedule_work() to avoid
calling the ACPI interpreter from an invalid context.

[akpm@linux-foundation.org: use flush_work() rather than sort-of reimplementing it]
Signed-off-by: NPavel Machek <pavel@suse.cz>
Cc: Éric Piel <eric.piel@tremplin-utc.net>
Cc: Len Brown <lenb@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Move the second part of the HP laptop disk protection functionality (a red
led) to the same driver.  From a purely Linux developer's point of view,
the led and the accelerometer have nothing related.  However, they
correspond to the same ACPI functionality, and so will always be used
together, moreover as they share the same ACPI PNP alias, there is no
other simple to allow to have same loaded at the same time if they are not
in the same module.  Also make it requires the led class to compile and
update the Kconfig text.
Signed-off-by: NPavel Machek <pavel@suse.cz>
Signed-off-by: NEric Piel <eric.piel@tremplin-utc.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The light sensors ALV0 and ALV1 on newer MacBooks (early 2008 and later)
changed to report 10 bytes instead the earlier 6, and the sensor encoding
subsequently changed.  As a result, the reported light sensors readings
are much too low.

Via experiments leading up to this patch, it seems only the ALV0 is
reporting data, and the most useful value therein is a 10-bit big-endian
value at offset 6.  This suggests that a new protocol was added as a
backward-compatible replacement on top of the old one.

This patch makes applesmc report the improved light sensor reading for the
new machines, on a scale in conformance with earlier ones.
Signed-off-by: NAlex Murray <murray.alex@gmail.com>
Signed-off-by: NHenrik Rydberg <rydberg@euromail.se>
Cc: Nicolas Boichat <nicolas@boichat.ch>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Two nbd-clients at same time are bad idea, and cause WARN_ON from nbd in
2.6.28-rc7 from sysfs_add_one.  This simply prevents that from happening.

To reproduce:

 cat /dev/zero | head -c 10000000 > /tmp/delme.fstest.fs
 nbd-server 9100 -l /anyone.can.connect > /tmp/delme.fstest.fs &
 sleep 1
 nbd-client localhost 9100 /dev/nd0 &
 nbd-client localhost 9100 /dev/nd0 &
Signed-off-by: NPavel Machek <pavel@suse.cz>
Acked-by: NPaul Clements <paul.clements@steeleye.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

- Enable ring indicator interrupt.

- Remove vendor specific CVS version tags.
Signed-off-by: NPaul Fulghum <paulkf@microgate.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

After XPC has been up and running on multiple partitions for any length of
time, if XPC on one of the partitions is stopped and restarted (either by
a rmmod/insmod or a system restart), it is possible for the XPCs running
on the other partitions to falsely detect a lack of heartbeat from the XPC
that was just restarted.  This false detection will occur if the restarted
XPC comes up within the five-seconds preceding one of the other XPC's
heartbeat check (which occurs once every twenty seconds).

The detection of no heartbeat results in the detecting XPC deactivating
from the just restarted XPC.  The only remedy is to restart one of the
XPCs and hope that one doesn't hit this five-second window on any of the
other partitions.
Signed-off-by: NDean Nelson <dcn@sgi.com>
Signed-off-by: NRobin Holt <holt@sgi.com>
Cc: <stable@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

A triggering RTC alarm should be able to power on a device that has been
powered off. This patch enables that on twl4030 by not masking the alarm
interrupt at shutdown.
Signed-off-by: NMatti Halme <matti.halme@nokia.com>
Signed-off-by: NAlessandro Zummo <a.zummo@towertech.it>
Acked-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Samuel Ortiz <sameo@openedhand.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fix these build errors:

  CC      drivers/rtc/rtc-pxa.o
drivers/rtc/rtc-pxa.c: In function `pxa_rtc_init':
drivers/rtc/rtc-pxa.c:472: error: implicit declaration of function `cpu_is_pxa27x'
drivers/rtc/rtc-pxa.c:472: error: implicit declaration of function `cpu_is_pxa3xx'
Signed-off-by: NAntonio Ospite <ao2@openezx.org>
Signed-off-by: NAlessandro Zummo <a.zummo@towertech.it>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

- implement alarm_irq_enable
- return correct error code when registering fails

[dbrownell@users.sourceforge.net: build fixes, force 1/sec irqs]
Signed-off-by: NAlessandro Zummo <a.zummo@towertech.it>
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Samuel Ortiz <sameo@openedhand.com>
Cc: rtc-linux@googlegroups.com
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Add an explanitory comment as to why we modify the kernel console loglevel
rather than simply moving sysrq messages to KERN_EMERG level.
Signed-off-by: NAndy Whitcroft <apw@canonical.com>
Cc: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Force fb_var_screeninfo color format on all Blackfin Framebuffer Drivers.
Signed-off-by: NMichael Hennerich <michael.hennerich@analog.com>
Signed-off-by: NBryan Wu <cooloney@kernel.org>
Cc: Mike Frysinger <vapier.adi@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

A number of drivers in drivers/gpio return -ENODEV when confronted with
missing setup parameters such as the platform data.  However, returning
-ENODEV causes the driver layer to silently ignore the driver as it
assumes the probe did not find anything and was only speculative.

To make life easier to discern why a driver is not being attached, change
to returning -EINVAL, which is a better description of the fact that the
driver data was not valid.

Also add a set of dev_dbg() statements to the error paths to provide an
better explanation of the error as there may be more that one point in the
driver.
Signed-off-by: NBen Dooks <ben-linux@fluff.org>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

For some reason I have to slowdown clock to touchscreen device.

In atmel_spi_setup() there is comment that max_speed_hz == 0 means as slow
as possible and divider is set to maximum value.  But in
atmel_spi_transfer() function is check against not zero max_speed_hz with
EINVAL returned.

Probably driver should setup divider for each transfer based on
transfer->speed_hz value, but I think that would be not necessary overhead
as all used devices have constant clock.

Below patch works fine for me.
Signed-off-by: NStanislaw Gruszka <stf_xl@wp.pl>
Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fix the following problem, related to hardware flow control (CTS/RTS):
Transmitting while CTS line is asserted in DMA mode, due to not checking
for tx-stopped condition.

We found these problems while testing the UARTs with hardware
flow-control.
Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
Cc: "Andrew Victor" <avictor.za@gmail.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

b44 chip has some hardware limitations, that need GFP_DMA bounce
buffers in some situations.

In order to not deplete DMA zone, we should keep allocated GFP_DMA skb
only for driver use. At rx time, we copy such skb to newly allocated
skb, reusing existing copybreak infrastructure.

On machines with low amount of memory, all skb meet the hardware limitation,
so no copy is needed. We detect this situation using a new device flag, set
to one if one GFP_DMA skb was ever allocated by b44_alloc_rx_skb().

Previously allocated skb, even outside from DMA zone will then be recycled,
to have minimal impact on DMA zone use.
Signed-off-by: NEric Dumazet <dada1@cosmosbay.com>
Tested-by: NIonut Leonte <ionut.leonte@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When CONFIG_DMI is not enabled, dmi detection should flag that no board
could be detected (err=1) rather than another error condition (err<0).

This fixes the fallback to manual probing for all motherboards, even
those without DMI strings, when CONFIG_DMI=n.
Signed-off-by: NAlistair John Strachan <alistair@devzero.co.uk>
Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: NJean Delvare <khali@linux-fr.org>