IGDNG mobile chip's LVDS data block removes panel fitting
register definition. So this fixes offset for LVDS timing
block parsing. Thanks for Michael Fu to catch this.
Signed-off-by: NZhenyu Wang <zhenyu.z.wang@intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

As of 52dc7d32, we could leave an old
linear GTT mapping in place, so that apps trying to GTT-mapped write in
tiled data wouldn't get the fence added, and garbage would get displayed.
Signed-off-by: NEric Anholt <eric@anholt.net>

As we call unmap_mapping_range() twice in identical fashion, refactor
and attempt to explain why we need to call unmap_mapping_range().
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>

In KMS mode we now use the normal mode-setting paths to set the modes
back to the current configuration, so we don't need to also run the more
limited non-KMS implementation of modesetting for resume.
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Acked-by: NDave Airlie <airlied@redhat.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Restore the modeset for every activated CRTC in course of resume.
This is realized by calling the function of drm_helper_resume_force_mode.
Note: it is meaningful only for the KMS mode.

https://bugs.freedesktop.org/show_bug.cgi?id=21719
https://bugs.freedesktop.org/show_bug.cgi?id=21708
https://bugs.freedesktop.org/show_bug.cgi?id=22285
https://bugs.freedesktop.org/show_bug.cgi?id=22263Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Signed-off-by: NEric Anholt <eric@anholt.net>

This is seen on some G41 systems, where the BIOS will consume all but
a few KB of the aperture.  This should be bad for all operating systems, as
it means that the OS can't dynamically manage memory between graphics and
the rest of the system, and OSes that did static memory management
statically add memory in addition to the BIOS allocation anyway.  So, instead
of working around it, just fail out verbosely.

fd.o bug #21574
Signed-off-by: NEric Anholt <eric@anholt.net>
Reviewed-by: NIan Romanick <ian.d.romanick@intel.com>

I overlooked SG_DXFER_TO_FROM_DEV support when I converted sg to use
the block layer mapping API (2.6.28).

Douglas Gilbert explained SG_DXFER_TO_FROM_DEV:

http://www.spinics.net/lists/linux-scsi/msg37135.html

=
The semantics of SG_DXFER_TO_FROM_DEV were:
   - copy user space buffer to kernel (LLD) buffer
   - do SCSI command which is assumed to be of the DATA_IN
     (data from device) variety. This would overwrite
     some or all of the kernel buffer
   - copy kernel (LLD) buffer back to the user space.

The idea was to detect short reads by filling the original
user space buffer with some marker bytes ("0xec" it would
seem in this report). The "resid" value is a better way
of detecting short reads but that was only added this century
and requires co-operation from the LLD.
=

This patch changes the block layer mapping API to support this
semantics. This simply adds another field to struct rq_map_data and
enables __bio_copy_iov() to copy data from user space even with READ
requests.

It's better to add the flags field and kills null_mapped and the new
from_user fields in struct rq_map_data but that approach makes it
difficult to send this patch to stable trees because st and osst
drivers use struct rq_map_data (they were converted to use the block
layer in 2.6.29 and 2.6.30). Well, I should clean up the block layer
mapping API.

zhou sf reported this regiression and tested this patch:

http://www.spinics.net/lists/linux-scsi/msg37128.html
http://www.spinics.net/lists/linux-scsi/msg37168.htmlReported-by: Nzhou sf <sxzzsf@gmail.com>
Tested-by: Nzhou sf <sxzzsf@gmail.com>
Cc: stable@kernel.org
Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Signed-off-by: NJens Axboe <jens.axboe@oracle.com>

Commit 1faa16d2 accidentally broke
the bdi congestion wait queue logic, causing us to wait on congestion
for WRITE (== 1) when we really wanted BLK_RW_ASYNC (== 0) instead.
Signed-off-by: NJens Axboe <jens.axboe@oracle.com>

The bt_lost_no_mapping is not getting reset at the start of a
profiling run, thus the oprofiled.log shows erroneous values for this
statistic. The attached patch fixes this problem.
Signed-off-by: NMaynard Johnson <maynardj@us.ibm.com>
Signed-off-by: NRobert Richter <robert.richter@amd.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Remove call to the mx3fb_set_par() and the mx3fb_blank() before the
register_framebuffer().

This fixes a problem with uninitialized the fb_info->mm_lock mutex
introduced by the commit 537a1bf0 " fbdev: add mutex for fb_mmap
locking"
Signed-off-by: NKrzysztof Helt <krzysztof.h1@wp.pl>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Remove call to the fb_set_par() before the register_framebuffer().

This fixes a problem with uninitialized the fb_info->mm_lock mutex
introduced by the commit 537a1bf0 " fbdev: add mutex for fb_mmap
locking"
Signed-off-by: NKrzysztof Helt <krzysztof.h1@wp.pl>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Looks like the change in ad361c98
wasn't compile tested.
Signed-off-by: NDave Jones <davej@redhat.com>
Acked-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Commit c3a8c5b6 ("cxgb3: move away from LLTX") exposed a bug in how
cxgb3 looks up the netdev_queue it stashes away in a qset during
initialization.  For multiport devices, the TX queue index it uses is
offset by the first_qset index of each port.  This leads to a crash
once LLTX is removed, since hard_start_xmit is called with one TX
queue lock held, while the TX reclaim timer task grabs a different
(wrong) TX queue lock when it frees skbs.

Fix this by removing the first_qset offset used to look up the TX
queue passed into t3_sge_alloc_qset() from setup_sge_qsets().
Signed-off-by: NRoland Dreier <rolandd@cisco.com>
Acked-by: NDivy Le Ray <divy@chelsio.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Fix coexistence of Fiber Channel over Ethernet (FCoE) and Flow Director (FDIR)
in 82599 and remove the disabling of FDIR when FCoE is enabled.

Currently, FDIR is turned off when FCoE is enabled under the assumption that
FCoE is always enabled with DCB being turned on. However, FDIR does not have
to be turned off all the time when FCoE is enabled since FCoE can be enabled
without DCB being turned on, e.g., use link pause only. This patch makes sure
that when DCB is turned on or off, FDIR is turned on or off correspondingly;
and when FCoE is enabled, it does not disable FDIR, rather, it will have FDIR
set up properly so FCoE and FDIR can coexist regardless of DCB being on or off.
Signed-off-by: NYi Zou <yi.zou@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

On some boxes the mobile chipset is used and there is no LVDS device. In such
case we had better not initialize the LVDS output device so that one pipe can
be used for other output device. For example: E-TOP.

But unfortunately the LVDS device is still initialized on the boxes based on
mobile chipset in KMS mode. It brings that this pipe occupied by LVDS can't be
used for other output device.

After checking the acpidump we find that there is no LID device on such boxes.
In such case we can use the LID device to decide whether the LVDS device should
be initialized.

If there is no LID device, we can think that there is no LVDS device. It is
unnecessary to initialize the LVDS output device.
If there exists the LID device, it will continue the current flowchart.

Maybe on some boxes there is no LVDS device but the LID device is found. In
such case it should be added to the quirk list.

http://bugs.freedesktop.org/show_bug.cgi?id=21496
http://bugs.freedesktop.org/show_bug.cgi?id=21856
http://bugs.freedesktop.org/show_bug.cgi?id=21127Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
[anholt: squashed in style fixups]
Signed-off-by: NEric Anholt <eric@anholt.net>

Add support for the W83627EHF/EF and W83627EHG/EG chipsets.
Signed-off-by: NSlobodan Tomić <stomic@gmail.com>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

This patch replaces the hardcoded 255 seconds limit for a real limit based on 
oscr_freq. 

Also, the 'firmware_version' field is changed to '1' to allow the user 
space application to easily detect that this driver supports a higher 
maximum timeout.
Signed-off-by: NRaphael Assenat <raph@8D.com>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

Don't forget to unlock io_lock when w83697ug_select_wd_register fails in
wdt_ctrl.
Signed-off-by: NJiri Slaby <jirislaby@gmail.com>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

Commit ad361c98 ("Remove multiple KERN_ prefixes from printk formats")
broke the build for fealnx because it added some "printk(PR_CONT ..."
calls, when PR_CONT doesn't exist; it should be "printk(KERN_CONT ..."
Signed-off-by: NRoland Dreier <rolandd@cisco.com>
Cc: Joe Perches <joe@perches.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

managed_policy is out of scope for the non-smp case.
Declare it locally where used (twice)
Signed-off-by: NDave Jones <davej@redhat.com>

Remove not needed locking of the fb_info->mm_lock mutex before a
frambuffer is registered.

This fixes a problem with uninitialized the fb_info->mm_lock mutex
introduced by the commit 537a1bf0 " fbdev: add mutex for fb_mmap
locking"
Signed-off-by: NKrzysztof Helt <krzysztof.h1@wp.pl>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Remove call to the fsl_diu_set_par before the register_framebuffer().

This fixes a problem with uninitialized the fb_info->mm_lock mutex
introduced by the commit 537a1bf0 " fbdev: add mutex for fb_mmap
locking"
Signed-off-by: NKrzysztof Helt <krzysztof.h1@wp.pl>
Tested-by: N"Kai Jiang" <b18973@freescale.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

In the mainline kernel, p54usb will fail because the TX queue length can
become < 0. This problem has been reported as Bugzilla #13725. The failure
is expressed by the following message in the logs:

WARNING: at net/mac80211/tx.c:1325 ieee80211_tx+0x23c/0x298 [mac80211]()
Hardware name: HP Pavilion dv2700 Notebook PC
tx refused but queue active

This problem has been recently observed in the wireless-testing tree, where
a full solution is being tested. That fix is too invasive for 2.6.31-rcX,
but the simple change supplied here will prevent the failure.
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Atheros top level menu needs a "depends WLAN_80211" to properly indent
within menuconfig and xconfig interfaces.

This is purely a visual issue but it effects all subsequent drivers.
The issue is the top level menu does not include a dependency on
WLAN_80211 so within the tree structure, Atheros is at the same level as
WLAN_80211 but when WLAN_80211 collapsed, the menu disappears along with
all subsequent drives, so it is really a subordinate.
Signed-off-by: NJay Sternberg <jay.e.sternberg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

There's a race condition -- started can be set to true
before channel is set due to the way mac80211 callbacks
currently work (->start should probably pass the channel
we would like to have initially). For now simply add a
check to hwsim to avoid dereferencing the NULL channel
pointer.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Added support for the Broadcom 4318E chipset on PCMCIA/CF cards. The
4318E can do 802.11A/B/G, only B and G mode are supported in b43.
Signed-off-by: NClyde McPherson <ccmcphe@verizon.net>
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Added support for the Broadcom 4318E chipset on PCMCIA/CF cards. The
4318E can do 802.11A/B/G, only B and G mode are supported in b43.
Signed-off-by: NClyde McPherson <ccmcphe@verizon.net>
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Yevgen Kotikov reported success on the sourceforge zd1211-devs list
with the following details:

Brand/retail: SONY IFU-WLM2
USB-IDs: Vendor: 0x054C Device: 0x0257
chip ID: zd1211b chip 054c:0257 v4802 high 00-0b-6b AL2230_RF pa0 -----
FCC ID: unknown
Signed-off-by: NHin-Tak Leung <htl10@users.sourceforge.net>
Tested-by: NYevgen Kotikov <yevgen.kotikov@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

On a shuttle machine here we got 07b8:6001 device, handled by zd1211rw, which does not work.
Scanning is OK but association does not work, we get "direct probe to AP xxx timed out"

It appears that this simple patch makes the device work perfectly.

This id was already there in initial import of the driver so I don't know if it has ever been
working as ZD1211 (which would mean they changed it and kept the id :( ).
Signed-off-by: NPascal Terjan <pterjan@mandriva.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NFlorian Fainelli <florian@openwrt.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When the r6040 device IRQ line is shared we will enter the driver
interrupt service routine, mask off the device interrupt enable
register (MIER) and return with IRQ_NONE, we would then leave the
device with interrupts disabled, this patch fixes that issue.
Reported-by: NSteve Holland <sdh4@iastate.edu>
Signed-off-by: NJoe Chou <joe.chou@rdc.com.tw>
Signed-off-by: NFlorian Fainelli <florian@openwrt.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Check that network interface is running before changing its MAC address.
Otherwise, rxch is accessed when it's NULL - causing a kernel oops.
Moreover, check that the new MAC address is valid.
Signed-off-by: NPablo Bitton <pablo.bitton@gmail.com>
Signed-off-by: NChaithrika U S <chaithrika@ti.com>
Tested-by: NChaithrika U S <chaithrika@ti.com>
[tested on DM6467 EVM]
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The igb driver was defaulting to using the lock for pci-e function 0 for
all of the phys due to the fact that the lan id was not being set prior to
initialization.  This change makes it so that the function id is set prior
to checking for the phy id.
Signed-off-by: NAlexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Commit 5fd29d6c ("printk: clean up
handling of log-levels and newlines") changed printk semantics.  printk
lines with multiple KERN_<level> prefixes are no longer emitted as
before the patch.

<level> is now included in the output on each additional use.

Remove all uses of multiple KERN_<level>s in formats.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This fixes the ppp problems and various other issues with call locking
caused by one side of a pty called in one locking context trying to match
another with differing rules on the other side. We also get a big slack
space to work with that means we can bury the flow control deadlock case
for any conceivable real world situation.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

After some API change, intel_iommu_unmap_range() introduced a assumption that
parameter size != 0, otherwise the dma_pte_clean_range() would have a
overflowed argument. But the user like KVM don't have this assumption before,
then some BUG() triggered.

Fix it by ignoring size = 0.
Signed-off-by: NSheng Yang <sheng@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The f_dev in _request_firmware() is allocated via the fw_setup_device()
and fw_register_device() calls and its class set to firmware_class (the
class release function is fw_dev_release).

Commit 6acf70f0 replaced the kfree(dev) in fw_dev_release() with a
put_device() call but my understanding is that the release function is
called via put_device -> kobject_put -> kref_put -> koject_release etc.
and it should call kfree since it's the last to see this device
structure alive.

Because of that, the _request_firmware() function on its -ENOENT error
path only calls device_unregister(f_dev) which would eventually call
fw_dev_release() but there is no kfree (the subsequent put_device call
would just make the kref negative).
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
Acked-by: NCornelia Huck <cornelia.huck@de.ibm.com>
Acked-by: NMing Lei <tom.leiming@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>