See also: http://bugzilla.redhat.com/514600Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Without an allocated colormap, FBIOGETCMAP fails.  This would make
programs restore an all-black colormap ("links -g") or fail to work
altogether ("mplayer -vo fbdev2").
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NDave Airlie <airlied@redhat.com>

When the framebuffer driver does not publish detailed timing information
for the current video mode, the correct value for the pixclock field is
zero, not -1.

Since pixclock is actually unsigned, the value -1 would be interpreted
as 4294967295 picoseconds (i.e., about 4 milliseconds) by
register_framebuffer() and userspace programs.

This patch allows X.org's fbdev driver to work.
Signed-off-by: NClemens Ladisch <clemens@ladisch.de>
Signed-off-by: NDave Airlie <airlied@redhat.com>

I examined several fbdev drivers and foudn the blanking code in
drm_fb_helper to be wrong. This patch fixes the fbdev blanking to behave
like other fbdev drivers.
Signed-off-by: NDave Airlie <airlied@redhat.com>

This adds a page flipping ioctl to the KMS API.  The ioctl takes an fb ID
and a ctrc ID and flips the crtc to the given fb at the next vblank.
The ioctl returns immediately but the flip doesn't happen until after
any rendering that's currently queued up against the new framebuffer
is done.  After submitting a page flip, any execbuffer involving the
old front buffer will block until the flip is completed.

Optionally, a vblank event can be generated when the swap eventually
happens.
Signed-off-by: NKristian Høgsberg <krh@bitplanet.net>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

In drm_version, actually check the results from function calls so that
we're not potentially passing garbage back to userspace.
Signed-off-by: NAndres Salomon <dilinger@collabora.co.uk>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Don't inline it; the compiler can figure it out.  Comments added that are
based upon my interpretation of the code.  Hopefully they're correct. :)
Signed-off-by: NAndres Salomon <dilinger@collabora.co.uk>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

There are a few more macros in drmP.h that are unused; DRM_GET_PRIV_SAREA,
DRM_ARRAY_SIZE, and DRM_WAITCOUNT can go away completely.

Unfortunately, DRM_COPY is still used in one place, but we can at least
move it to where it's used.  It's an awful looking macro..

[akpm: fix overeagerness]
Signed-off-by: NAndres Salomon <dilinger@collabora.co.uk>
Cc: Dave Airlie <airlied@linux.ie>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

If we queue a vblank event but miss it, we should return the actual
sequence number we queued to userspace, so its event handling function
will know which event to look for.
Acked-by: NKristian Høgsberg <krh@bitplanet.net>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This patch adds a new flag to the drmWaitVblank ioctl, which asks the drm
to return immediately and notify userspace when the specified vblank sequence
happens by sending an event back on the drm fd.

The event mechanism works with the other flags supported by the ioctls,
specifically, the vblank sequence can be specified relatively or absolutely,
and works for primary and seconday crtc.

The signal field of the vblank request is used to provide user data,
which will be sent back to user space in the vblank event.
Signed-off-by: NKristian Høgsberg <krh@redhat.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

or it will taint the kernel and fail to load becuase
of_address_to_resource() is GPL only.
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

On older kernels, e.g. 2.6.27, a WARN_ON dump in rtmsg_ifinfo()
is thrown when the CAN device is registered due to insufficient
skb space, as reported by various users. This patch adds the
rtnl_link_ops "get_size" to fix the problem. I think this patch
is required for more recent kernels as well, even if no WARN_ON
dumps are triggered. Maybe we also need "get_xstats_size" for
the CAN xstats.
Signed-off-by: NWolfgang Grandegger <wg@grandegger.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Some drivers need to be able to prevent access to an I2C bus segment
for a specific period of time. Add an interface for them to do so
without twiddling with i2c-core internals.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Acked-by: NBen Hutchings <bhutchings@solarflare.com>

Change SB900 to its formal code name Hudson-2.
Signed-off-by: NCrane Cai <crane.cai@amd.com>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

The hisax ISDN driver fails to build on ARM with CONFIG_HISAX_ELSA:

| drivers/built-in.o: In function `modem_set_dial':
| drivers/isdn/hisax/elsa_ser.c:535: undefined reference to `__bad_udelay'
| drivers/isdn/hisax/elsa_ser.c:544: undefined reference to `__bad_udelay'
| drivers/built-in.o: In function `modem_set_init':
| drivers/isdn/hisax/elsa_ser.c:486: undefined reference to `__bad_udelay'
| [...]

According to the comment in arch/arm/include/asm/delay.h, __bad_udelay
is specifically designed on ARM to produce a build failure when udelay
is called with a value > 2000.
Signed-off-by: NMartin Michlmayr <tbm@cyrius.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This device requires a fundamental reset when recovering from EEH.
Signed-off-by: NRon Mercer <ron.mercer@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This line was accidentally left out of the previous commit #
da039451 ("qlge: Fix firmware mailbox
command timeout.").
Signed-off-by: NRon Mercer <ron.mercer@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When ioatdma was loaded we we were unable to transmit traffic.  We weren't
using the correct registers in ixgbe_update_tx_dca for 82599 systems.
Likewise in ixgbe_configure_tx() we weren't disabling the arbiter before
modifying MTQC.
Signed-off-by: NDon Skidmore <donald.c.skidmore@intel.com>
Acked-by: NPeter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When DCB is enabled, the ixgbe_check_tx_hang() should check the corresponding
TC's TXOFF in TFCS based on the TC that the tx ring belongs to. Adds a
function to map from the tx_ring hw reg_idx to the correspodning TC and read
TFCS accordingly.
Signed-off-by: NYi Zou <yi.zou@intel.com>
Acked-by: NPeter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The 32k gso_max_size when DCB is enabled is for 82598 only, not for 82599.
Signed-off-by: NYi Zou <yi.zou@intel.com>
Acked-by: NPeter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

No-one seems to know where the PowerBook 500 series store their ethernet
MAC addresses. So, rather than crash, use a MAC address from the SONIC
CAM. Failing that, generate a random one.
Signed-off-by: NFinn Thain <fthain@telegraphics.com.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Stanse found that one error path in cas_open omits to unlock pm_mutex.
Fix that.
Signed-off-by: NJiri Slaby <jirislaby@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

CPC-USB is using a ARM7 core with little endian byte order. The "id" field
in can_msg needs byte order conversion from/to CPU byte order.
Signed-off-by: NSebastian Haas <haas@ems-wuensche.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Sending config commands to be2 hardware before netdev_register is
completed, is sometimes causing the async link notification to arrive
even before the driver is ready to handle it. The commands for vlan
config and flow control settings can infact wait till be_open.
This patch takes care of that.
Signed-off-by: NAjit Khaparde <ajitk@serverengines.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If be2 goes into suspend after a user changes the flow control settings,
we are not programming them back after resume. This patch takes care of it.
We now get the flow control settings before going to suspend mode and
then apply them during resume.
Signed-off-by: NAjit Khaparde <ajitk@serverengines.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This prevents the rt2x00 driver from queueing ieee80211 work after the  
USB card has been removed, preventing a kernel panic.
Signed-off-by: NSean Cross <sean@chumby.com>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This reverts commit e6c5fc53.

Based on this regression report:

Date: Thu, 05 Nov 2009 15:59:16 +0100
From: Holger Schurig <holgerschurig@gmail.com>
To: linux-wireless@vger.kernel.org
Subject: BUG: oops when "rmmod ipw2200"

This happened on wireless-testing v2.6.32-rc6-41575-g5e68bfb. I
modprobed ipw2200, put it into monitor mode, used tshark a while to
monitor, then I stopped tshark, "ifconfig eth2 down" and finally
"rmmod ipw2200", and voila:

[  917.189620] ------------[ cut here ]------------
[  917.189717] kernel BUG at net/wireless/core.c:543!
[  917.189805] invalid opcode: 0000 [#1] PREEMPT SMP
[  917.190002] last sysfs file: /sys/devices/pci0000:00/0000:00:1e.0/0000:02:0d.0/firmware/0000:02:0d.0/loading
[  917.190136] Modules linked in: lib80211_crypt_wep ipw2200(-) libipw lib80211 ath5k mac80211 ath cfg80211 psmouse uhci_hcd
[  917.190680]
[  917.190759] Pid: 1763, comm: rmmod Not tainted (2.6.32-rc6-wl #26) Amilo M1425
[  917.190886] EIP: 0060:[<f8accf34>] EFLAGS: 00010202 CPU: 0
[  917.190992] EIP is at wiphy_unregister+0xd3/0x175 [cfg80211]
[  917.191083] EAX: f601d4c4 EBX: 00000000 ECX: 00000000 EDX: f79e8600
[  917.191176] ESI: f601d400 EDI: f95b4350 EBP: f6009eb4 ESP: f6009e8c
[  917.191269]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[  917.191360] Process rmmod (pid: 1763, ti=f6008000 task=f79e8130 task.ti=f6008000)
[  917.191486] Stack:
[  917.191562]  f601d5a0 f601d484 f6460e98 f6009ea0 c01407ee f6009eb8 00000246 f64604c0
[  917.191916] <0> f6460e5c f95b4350 f6009ec0 f94fd030 f6460e98 f6009edc f95a9d4f f787bc00
[  917.192100] <0> f787bc58 f787bc00 f95b4350 f95b4350 f6009ee8 c0207fca f787bc58 f6009ef8
[  917.192100] Call Trace:
[  917.192100]  [<c01407ee>] ? trace_hardirqs_on+0xb/0xd
[  917.192100]  [<f94fd030>] ? unregister_ieee80211+0xe/0x27 [libipw]
[  917.192100]  [<f95a9d4f>] ? ipw_pci_remove+0x59/0x227 [ipw2200]
[  917.192100]  [<c0207fca>] ? pci_device_remove+0x19/0x39
[  917.192100]  [<c02b93a4>] ? __device_release_driver+0x59/0x9d
[  917.192100]  [<c02b944f>] ? driver_detach+0x67/0x85
[  917.192100]  [<c02b88d6>] ? bus_remove_driver+0x69/0x85
[  917.192100]  [<c02b9878>] ? driver_unregister+0x4d/0x54
[  917.192100]  [<c02081c3>] ? pci_unregister_driver+0x28/0x71
[  917.192100]  [<f95a9cf4>] ? ipw_exit+0x1c/0x1e [ipw2200]
[  917.192100]  [<c0148e2b>] ? sys_delete_module+0x192/0x1ef
[  917.192100]  [<c0162cdb>] ? remove_vma+0x52/0x58
[  917.192100]  [<c01028bb>] ? sysenter_exit+0xf/0x18
[  917.192100]  [<c0102888>] ? sysenter_do_call+0x12/0x36
[  917.192100] Code: 74 07 e8 81 bc 8c c7 eb c8 8d 55 e0 89 f8 e8 d6 6d 66 c7 8b 45 dc 31 d2 e8 81 cc 8c c7 8d 86 c4 00 00 00 39 86 c4 00 00 00 74 04 <0f> 0b eb fe 8b 45 dc 8d 5e 0c e8 5a cc 8c c7 8b 86 94 03 00 00
[  917.192100] EIP: [<f8accf34>] wiphy_unregister+0xd3/0x175 [cfg80211] SS:ESP 0068:f6009e8c
[  917.203718] ---[ end trace bcaaf449945a5100 ]---
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This reverts commit 60293364.

Ok, we really do need to revert this, even with Bart's sis5513.c
fix in there.

The problem is that several driver's ->set_pio_mode() method
depends upon the drive->media type being set properly.  Most
of them use this to enable prefetching, which can only be done
for disk media.

But the commit being reverted here calls ->set_pio_mode() before
it's setup.  Actually it considers everything disk because that
is the default media type set by ide_port_init_devices_data().

The set of drivers that depend upon the media type in their
->set_pio_method() are:

drivers/ide/alim15x3.c
drivers/ide/it8172.c
drivers/ide/it8213.c
drivers/ide/pdc202xx_old.c
drivers/ide/piix.c
drivers/ide/qd65xx.c
drivers/ide/sis5513.c
drivers/ide/slc90e66.c

And it is possible that we could fix this by guarding the prefetching
and other media dependent setting changes with a test on
IDE_PFLAG_PROBING in hwif->port_flags, that's simply too risky for
2.6.32-rcX and -stable.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NSathya Perla <sathyap@serverengines.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Avoid invoking the disable callback in case of NULL.
Signed-off-by: NMagnus Damm <damm@opensource.se>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

http://bugzilla.kernel.org/show_bug.cgi?id=13745Signed-off-by: NLen Brown <len.brown@intel.com>

Fixes the missing battery on sleep problem for yet another HP laptop
("HP Pavilion dv4").

Fixes:
	http://bugzilla.kernel.org/show_bug.cgi?id=13449Signed-off-by: NGustavo Maciel Dias Vieira <gustavo@sagui.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

This value is visible through sysfs and is used by mdadm
when it manages a reshape (backing up data that is about to be
rearranged).  So it is important that it is always correct.
Current it does not get updated properly when a reshape
starts which can cause problems when assembling an array
that is in the middle of being reshaped.

This is suitable for 2.6.31.y stable kernels.

Cc: stable@kernel.org
Signed-off-by: NNeilBrown <neilb@suse.de>

If a 'sync_max' has been set (via sysfs), it is wrong to clear it
until a resync (or reshape or recovery ...) actually reached that
point.
So if a resync is interrupted (e.g. by device failure),
leave 'resync_max' unchanged.

This is particularly important for 'reshape' operations that do not
change the size of the array.  For such operations mdadm needs to
monitor the reshape taking rolling backups of the section being
reshaped.  If resync_max gets cleared, the reshape can get ahead of
mdadm and then the backups that mdadm creates are useless.

This is suitable for 2.6.31.y stable kernels.
Cc: stable@kernel.org
Signed-off-by: NNeilBrown <neilb@suse.de>

Make the trip_point_N_type sysfs files return a string ending in EOL for
consistency with other sysfs files.
Signed-off-by: NAmit Kucheria <amit.kucheria@canonical.com>
Acked-by: NZhang Rui <rui.zhang@intel.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

If the NULL test on pr is needed, then the dereference should be after the
NULL test.

A simplified version of the semantic match that detects this problem is as
follows (http://coccinelle.lip6.fr/):

// <smpl>
@match exists@
expression x, E;
identifier fld;
@@

* x->fld
  ... when != \(x = E\|&x\)
* x == NULL
// </smpl>
Signed-off-by: NJulia Lawall <julia@diku.dk>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

Ensure that memory mappings created for operation regions
do not cross page boundaries.  Crossing a page boundary
while mapping regions can cause warnings if the pages have different attributes.

Such regions are probably BIOS bugs, and this is the workaround.

http://bugzilla.kernel.org/show_bug.cgi?id=14445

[Kernel summit hacking hour]
Signed-off-by: NBob Moore <robert.moore@intel.com>
Acked-by: NSuresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: NLin Ming <ming.m.lin@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Annote acpi_processor_add with cpuinit since it calls a cpuinit function
acpi_processor_power_init and fixes a section mismatch warning.

 We were warned by the following warning:

 LD      drivers/acpi/processor.o
WARNING: drivers/acpi/processor.o(.text+0x1829): Section mismatch in
reference from the function acpi_processor_add() to the function
.cpuinit.text:acpi_processor_power_init()
The function acpi_processor_add() references
the function __cpuinit acpi_processor_power_init().
This is often because acpi_processor_add lacks a __cpuinit
annotation or the annotation of acpi_processor_power_init is wrong.
Signed-off-by: NRakib Mullick <rakib.mullick@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

Not a single line of actual code in the function was really
fundamentally correct.

Problems ranged from lack of proper range checking, to removing the last
character written (which admittedly is usually '\n'), to not accepting
hex numbers even though the 'show' routine would show the data in that
format.

This tries to do better.
Acked-by: NMichael Buesch <mb@bu3sch.de>
Tested-and-acked-by: NJack Steiner <steiner@sgi.com>
Cc: stable@kernel.org
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Michael Gilbert <michael.s.gilbert@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

If the ACPI methods return an error code, we must return -EINVAL to userspace
to flag the error.  Right now we pass the (positive) number right through,
which causes echo to keep writing bogus values.
Signed-off-by: NDarrick J. Wong <djwong@us.ibm.com>
Acked-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLen Brown <len.brown@intel.com>