Daniel Vetter writes:
3 regression fixes:
- disable gmbus again, too broken for 3.4, we'll try again for 3.5
- dp bandwidth computation fix, we've lost the 6bpc dithering flag
sometimes, this is a 3.3 regression (maybe even earlier for some
configurations).
- fix resume regression caused by the gen2/3 fencing fix merged into -rc2.
And a few other fixes:
- gpu hang fix for i845 (Chris)
- sprite fix (Armin Reese)
- crtc disable vs. scanlinewait race fix (Chris)
- rc6 module option read-only, it confused testers (Jesse)
- fbc related blitter death hw workaround, note that we disable fbc on snb
by default anyway.
With these fixes we have one 3.4 regression outstanding: One of the
cleanup patches for the interlaced support managed to confuse the lvds
panel fitter when upscaling. The root-cause is still unclear, but test
patches are awaiting feedback from the reporter.
* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel:
drm/i915: clear fencing tracking state when retiring requests
drm/i915: make rc6 module parameter read-only
drm/i915: implement ColorBlt w/a
drm/i915/ringbuffer: Exclude last 2 cachlines of ring on 845g
Revert "drm/i915: reenable gmbus on gen3+ again"
drm/i915: properly compute dp dithering for user-created modes
drm/i915: Finish any pending operations on the framebuffer before disabling
drm/i915: Removed IVB forced enable of sprite dest key.
Correct path names in API documentation for usbtmc
Signed-off-by: Stephen Lewis <lewis@sdf.lonestar.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Here's 11 xHCI bug fixes for 3.4.
Some of the patches fix issues with crashes on system resume related to
VIA xHCI host controllers accessing bad memory addresses. The patches
change the register restore ordering, so I had several vendors confirm
that the patches don't break their xHCI hosts.
Elric Fu confirms this patchset fixes the VIA issue, Alex He confirms
the changes does not break suspend/resume on AMD xHCI systems, and I've
made sure it doesn't break Intel host controllers. I have not heard
back from Felipe about the TI host, so at this point, I'm just going to
send them off.
Several of the patches are marked for stable. Please pull.
Sarah Sharp
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJPhfEEAAoJEBMGWMLi1Gc5JFAQAJv2SSrLqEem7OX1srAIPFjs
NjO2hQQ090syGQcWU4pa7PSY85iWt4/1dzvE5l1R7yH1bYhP8fvhFtcsbVQguHPJ
4pDpLN5w2GMbEEjeWBrAjYOuIrF72kvxY5IeHglqTGBrIt2ELJENYIxKa84jmA6g
B1iSZYgN3RGh/T1Fr0DvyUB3fXUvTzeY48hesel2ITbxjQGZ/NKBcf6SObH/D0Sq
d7HxFp3YNYV4+y/Agex9CEUpTv7t8Pf0WX8O6OmLlr57Lo43Hh7iEWu8d7NL1DVL
gQENBLbsjWSWDwU7mUQc2tHIH0t7ji+agFWGMv9m9YaThX44sg9JD/jdpcjIQ6TQ
cbJdUVpVHR5D2pXw1MM9Rsd5st2adPbJO1UfQiTm7IKmrkXOQvbfqfvUisjIY1nY
Ohbk+Q1bd0Q/lY3iOR63VtKEBlRqOazaHXQx8lGG5UahwwQgVmc8zzdCAcqxyDPN
xFYZWfmPDarQ5h3rU4dugzZR7alEsaO+uTX4pN9ZVrY5f1NRruRpHroqWkQtpWVL
XnHHkU1CNFG61UgupM35C2Y9cBQ5tfEud7YYUMzVqPE7HSYzXtA8HtnilQL0fd3z
34LdR10rG9z9/Li1khYpe4wwF47FUHLpLo+/CyEv+Czr0gSyMhBT9nhm8+SQdac3
ywr5U0BmWTTrabNe5PQx
=LRhW
-----END PGP SIGNATURE-----
Merge tag 'for-usb-linus-2012-04-11' of git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci into usb-linus
Hi Greg,
Here's 11 xHCI bug fixes for 3.4.
Some of the patches fix issues with crashes on system resume related to
VIA xHCI host controllers accessing bad memory addresses. The patches
change the register restore ordering, so I had several vendors confirm
that the patches don't break their xHCI hosts.
Elric Fu confirms this patchset fixes the VIA issue, Alex He confirms
the changes does not break suspend/resume on AMD xHCI systems, and I've
made sure it doesn't break Intel host controllers. I have not heard
back from Felipe about the TI host, so at this point, I'm just going to
send them off.
Several of the patches are marked for stable. Please pull.
Sarah Sharp
Since commit 96104eda01 ("RDMA/core: Add SRQ type field"), kernel
users of SRQs need to specify srq_type = IB_SRQT_BASIC in struct
ib_srq_init_attr, or else most low-level drivers will fail in
when srpt_add_one() calls ib_create_srq() and gets -ENOSYS.
(mlx4_ib works OK nearly all of the time, because it just needs
srq_type != IB_SRQT_XRC. And apparently nearly everyone using
ib_srpt is using mlx4 hardware)
Reported-by: Alexey Shvetsov <alexxy@gentoo.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Roland Dreier <roland@purestorage.com>
this patch removes the pointer of uint64_t *edid. it should be just
a uint64_t.
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
This fixes a resume regression introduced in
commit 7dd4906586
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Wed Mar 21 10:48:18 2012 +0000
drm/i915: Mark untiled BLT commands as fenced on gen2/3
which fixed fencing tracking for untiled blt commands.
A side effect of that patch was that now also untiled objects have a
non-zero obj->last_fenced_seqno to track when a fence can be set up
after a pipelined tiling change. Unfortunately this was only cleared
by the fence setup and teardown code, resulting in tons of untiled but
inactive objects with non-zero last_fenced_seqno.
Now after resume we completely reset the seqno tracking, both on the
driver side (by setting dev_priv->next_seqno = 1) and on the hw side
(by allocating a new hws page, which contains the seqnos). Hilarity
and indefinite waits ensued from the stale seqnos in
obj->last_fenced_seqno from before the suspend.
The fix is to properly clear the fencing tracking state like we
already do for the normal gpu rendering while moving objects off the
active list.
Reported-and-tested-by: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Jiri Slaby <jslaby@suse.cz>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This removes the HOTPLUG_PCI_PCIE dependency on the driver and makes it
depend on PCI.
Cc: Sam Bradshaw <sbradshaw@micron.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Asai Thambi S P <asamymuthupa@micron.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
This patch replaces the old global setting of irq_virq_count that is only
used by the NOMAP mapping and instead uses a revmap_data property so that
the maximum NOMAP allocation can be set per NOMAP irq_domain.
There is exactly one user of irq_virq_count in-tree right now: PS3.
Also, irq_virq_count is only useful for the NOMAP mapping. So,
instead of having a single global irq_virq_count values, this change
drops it entirely and added a max_irq argument to irq_domain_add_nomap().
That makes it a property of an individual nomap irq domain instead of
a global system settting.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Tested-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Milton Miller <miltonm@bga.com>
If a bitmap is added while the array is active, it is possible
for bitmap_daemon_work to run while the bitmap is being
initialised.
This is particularly a problem if bitmap_daemon_work sees
bitmap->filemap as non-NULL before it has been filled in properly.
So hold bitmap_info.mutex while filling in ->filemap
to prevent problems.
This patch is suitable for any -stable kernel, though it might not
apply cleanly before about 3.1.
Cc: stable@vger.kernel.org
Signed-off-by: NeilBrown <neilb@suse.de>
If r1bio->sectors % 8 != 0,then the memcmp and a later
memcpy will omit the last bio_vec.
This is suitable for any stable kernel since 3.1 when bad-block
management was introduced.
Cc: stable@vger.kernel.org
Signed-off-by: majianpeng <majianpeng@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Add GPIO1 setup explicitly for Acer Aspire 493x & co.
This could be set by alc_auto_init_amp(), but it's safer to set it
more explicitly in the fixup table.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
bitmap_new_disk_sb() would still create V3 bitmap superblock
with host-endian layout.
Perhaps I'm confused, but shouldn't bitmap_new_disk_sb() be
creating a V4 bitmap superblock instead, that is portable,
as per comment in bitmap.h?
Signed-off-by: Andrei Warkentin <andrey.warkentin@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.de>
The struct exynos_drm_manager has to exist for exynos drm sub driver
using encoder and connector. If it isn't NULL to member of struct
exynos_drm_subdrv, will create encoder and connector else will not. And
the is_local member also doesn't need.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
The mixer driver and hdmi driver have each operation callback functions
and they is registered to hdmi common driver. Their struct names in hdmi
common driver include display, manager and overlay. It confuses to
appear whose operation and two driver cannot register same operation
callback functions at the same time. Use their struct names to driver
name.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
The default_win member in struct mixer_context isn't change its value
after initialized to 0, so it's better using to define.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
HDMI_OVERLAY_NUMBER is specific of mixer driver and be used "windows
layer" term in exynos user manaual, so rename it.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Some members in struct mixer_context aren't used and the define
HDMI_OVERLAY_NUMBER is unused in hdmi driver, remove them.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
When the void pointer type variable is assigned to the specific pointer
type variable, don't need to do type conversion.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
If, in drivers/input/misc/da9052_onkey.c::da9052_onkey_probe(), the
call to either kzalloc() or input_allocate_device() fails then we will
return -ENOMEM from the function without freeing the other allocation
that may have succeeded, thus we leak either the memory allocated for
'onkey' or the memory allocated for 'input_dev' if one succeeds and
the other fails.
Fix that by jumping to the 'err_free_mem' label at the end of the
function that properly cleans up rather than returning directly.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Pull powerpc fixes from Benjamin Herrenschmidt:
"Fixes for two nasty regression affecting powerpc in 3.4."
* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
powerpc: Fix typo in runlatch code
powerpc: Fix page fault with lockdep regression
This reverts commit b519508298.
The reason for this revert is that making the frequency verification
preemptible and interruptible is not working reliably. Michaels
machine failed to use PM-timer with the message:
PM-Timer running at invalid rate: 113% of normal - aborting.
That's not a surprise as the frequency verification does rely on
interrupts being disabled. With a async scheduled thread there is no
guarantee to achieve the same result. Also some driver might fiddle
with the CTC channel 2 during the verification period, which makes the
result even more random and unpredictable.
This can be solved by using the same mechanism as we use in the
deferred TSC validation code, but that only will work if we verified a
working HPET _BEFORE_ trying to do the PM-Timer lazy validation.
So for now reverting is the safe option.
Bisected-by: Michael Witten <mfwitten@gmail.com>
Cc: Arjan van de Ven <arjanvandeven@gmail.com>
Cc: Arjan van de Ven <arjan@infradead.org>
Cc: John Stultz <johnstul@us.ibm.com>
Cc: Len Brown <lenb@kernel.org>
LKML-Reference: <alpine.LFD.2.02.1204112303270.2542@ionos>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
kernels used to just return something, even if the underlying value was
out-of-bounds, while 3.4-rc1 returned EINVAL to userspace. This breaks
some applications that check for the error, so go back to the old
behavior.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABCAAGBQJPhb1PAAoJEENa44ZhAt0heLgQAI8qrLIBUyHzzfmwMYE7c+fq
PWnXo4ZT6YLht2l7PPxZOGUYtW2FSR9uneuTRozCAyLWmMNvfHNQTIXZQpP7N4zA
Ql3SkI08962Hhdgrd3pF9/Qv5BWrUgOEfpts4kJ3uIafG/gNCAwuEUOjFl7N9FYA
6sGsa9uEm1KgYzH97Kn79z9qnbZYNdwsiuuwvG9gpNaW5m0zdysowheC+JMGDld/
1Y4fMGbv3AO4K+vv8jFtkVvd2F6fa2qDlZ3cP0+o+EfQGWzdpf/BL+sK5j6R0gAw
OFByHvZTXMK9daMOueG+s+4teYe85PFgriugA++UCTb/JAIqfQi4bwcFm3Iv1uCL
zfIsmo6Q15KXda3xp/sUUcI97/IMFz82f8ow9LwjcfPxz1+F/OjKA/jdCw1LX7h/
LizVLdvNp/IoQ76/0jfV0isf4BZbT1OaheMM0vDW9yTGbelNwds1KbrYyhe1IQwV
Zjv183BLytoEzfP/1bD3y88nsgxWwqoekZ6QDca/zq4nYyf1TPerOL+wESOqsNha
K5JtnZWFllf6dYSyLNlysfIC4RlBc/6dhJQYaCvVbI1/I3a+zLsnuFJDlGLlxyf7
G2OedlXLggcb9RSiJxb31aQ4BS7nOVEBvnjIIo8hz31xD2Gz9PGuTdl/HOdtpr/k
5l2bgFfrtmeClzhVjhHq
=xYF8
-----END PGP SIGNATURE-----
Merge tag 'rdma-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband
Pull infiniband fixes from Roland Dreier:
"Fix a regression in the /sys/class/infiniband/.../rate attribute --
old kernels used to just return something, even if the underlying
value was out-of-bounds, while 3.4-rc1 returned EINVAL to userspace.
This breaks some applications that check for the error, so go back to
the old behavior."
* tag 'rdma-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband:
IB/core: Don't return EINVAL from sysfs rate attribute for invalid speeds
IB/mlx4: Don't return an invalid speed when a port is down
People have been getting confused and thinking this is a runtime control.
Cc: stable@vger.kernel.org
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In https://bugzilla.kernel.org/show_bug.cgi?id=42976, a system with driver
rtl8192se used as an AP suffers from "Out of SW-IOMMU space" errors. These
are caused by the DMA buffers used for beacons never being unmapped.
This bug was also reported at
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/961618
Reported-and-Tested-by: Da Xue <da@lessconfused.com>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The current version of rtlwifi for USB operations uses kmalloc to
acquire a 32-bit buffer for each read of the device. When
_usb_read_sync() is called with the rcu_lock held, the result is
a "sleeping function called from invalid context" BUG. This is
reported for two cases in https://bugzilla.kernel.org/show_bug.cgi?id=42775.
The first case has the lock originating from within rtlwifi and could
be fixed by rearranging the locking; however, the second originates from
within mac80211. The kmalloc() call is removed from _usb_read_sync()
by creating a ring buffer pointer in the private area and
allocating the buffer data in the probe routine.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org> [This version good for 3.3+ - different patch for 3.2 - 2.6.39]
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Pull arch/tile fixes from Chris Metcalf:
"This is one important change from Srivatsa Bhat that got dropped when
I put together my pull request for -rc2, plus a trivial change to
remove a compiler warning."
* 'stable' of git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile:
arch/tile: avoid unused variable warning in proc.c for tilegx
tile/CPU hotplug: Add missing call to notify_cpu_starting()
- A series of fixes for Conexant 20549 HD-audio codec chip
- A workaround for HDMI hotplug debug prints that annoyed people
- A fix for the new support of platform DAPM contexts
- Many driver-specific minor fixes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iQIcBAABAgAGBQJPhWH/AAoJEGwxgFQ9KSmk0KoP+gNjARkNkiTh7rnQN+x0y8+O
ejv13pUlfSA+KLYNQtBAq21t5JCZfoelcJ0Yt5Dbq79/XK/jzQog8wcp0obLzdVt
WiWbkUVTN1udjlGUfjpCaIvtXG7dnxysYTeO+4ajOqs87hnoJLmRzw2EnD1dtqt+
rkdySKbrE2tSmgIQwZDaeo2UFiyRavpFnKOOjTXKIiWlDIiMYKjCtOnMd2uyoDDU
hTNUXocpHL27uuSgDgS4jGoWTldd4rgDwcQ1dSDYxdqkaWjqnimFCXJUcZeLkx6G
eb0Plk58ceka/hKa8DFIbOjs14hy5lZvc8bALPldCAbvG+/IQTg0ucS4DFIHq962
LvG5kQ9aHl7cMVz1ZjcEbRQ5Y2qbb5bwmIFQZIiAy7B8JeZs9sZPeOt242teUUjw
ijSpE3R/cv/jvSUr1if26PcpVZA+BmEUUThCpvPw9X83lEdlb9n9EjrAUfi46+LT
fpfc76+II6K86jtRaU+qnadSO3AZ5ji7o06CuoBgoCbxjKz1iIRjxMKgvdZw0pmp
RAwqcPL8G2AOSJqQi8wJhqi+/Cx0VGcwIQQKuHMNg9AJDruUFQzERozl6O7MV4b6
hF80VXIkkTU6cSfB5CrksPy5OX4v0ruYbqygKf2X4Wnq17TKeZHzATQi+WiWEY/P
CAx2WuIIN6GWWEhqvrkK
=HeDy
-----END PGP SIGNATURE-----
Merge tag 'sound-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
- A series of fixes for Conexant 20549 HD-audio codec chip
- A workaround for HDMI hotplug debug prints that annoyed people
- A fix for the new support of platform DAPM contexts
- Many driver-specific minor fixes
* tag 'sound-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ALSA: hda - hide HDMI/ELD printks unless snd.debug=2
ALSA: sound/isa/sscape.c: add missing resource-release code
sound: sound/oss/msnd_pinnacle.c: add vfrees
ALSA: hda - clean up CX20549 test mixer setup
ALSA: hda - CX20549 doesn't need pin_amp_workaround.
ALSA: hda - Remove CD control from model=benq for CX20549
ALSA: hda - fix record volume controls of CX20459 ("Venice")
ALSA: hda - Rename capture sources of CX20549 to match common conventions
ALSA: hda - Fix proc output for ADC amp values of CX20549
ASoC: tegra: fix i2s compilation when !CONFIG_DEBUG_FS
ASoC: set idle_bias_off=1 for all platform DAPM contexts
ASoC: imx-audmux: Check for NULL pointer
ASoC: imx-audmux: Fix ssi port numbers in sysfs
ASoC: ak4642: fixup: mute needs +1 step
MAINTAINERS: Don't list everyone working on Wolfson drivers
MAINTAINERS: Add missing ASoC OMAP co-maintainer
ASoC: pxa: pxa2xx-i2s: add io.h for IOMEM macro
ASoC: tegra: ensure clocks are enabled when touching registers
ASoC: sgtl5000: Enable VAG when DAC/ADC up
ALSA: asihpi - fix return value of hpios_locked_mem_alloc()
Pull media fixes from Mauro Carvalho Chehab:
- dvb core: there is a regression found when used with xine. For
whatever unknown reason, xine (and xine-lib clients) wants that the
frontend to tell what frequency he is using even before the PLL lock
(or at least, it expects a non-zero frequency).
On DVB, the frequency is only actually known after a frequency
zig-zag seek, done by the DVB core. Anyway, the fix was trivial.
That solves Fedora BZ#808871.
- ivtv: fix a regression when selecting the language channel
- uvc: fix a race-related crash
- it913x: fixes firmware loading
- two trivial patches (a dependency issue at a radio driver at sound
Kconfig, and a warning fix on dvb).
* 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media:
[media] uvcvideo: Fix race-related crash in uvc_video_clock_update()
[media] Drivers/media/radio: Fix build error
[media] dvb_frontend: fix compiler warning
[media] it913x: fix firmware loading errors
[media] ivtv: Fix AUDIO_(BILINGUAL_)CHANNEL_SELECT regression
[media] dvb_frontend: regression fix: userspace ABI broken for xine
Pull GFS2 fixes from Steven Whitehouse
* git://git.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-3.0-fixes:
GFS2: Allow caching of rindex glock
GFS2: Make sure rindex is uptodate before starting transactions
GFS2: use depends instead of select in kconfig
GFS2: put glock reference in error patch of read_rindex_entry
Until we push the unaligned access support for tilegx, it's silly
to have arch/tile/kernel/proc.c generate a warning about an unused
variable. Extend the #ifdef to cover all the code and data for now.
Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
This merges the 32- and 64-bit versions of the x86 strncpy_from_user()
by just rewriting it in C rather than the ancient inline asm versions
that used lodsb/stosb and had been duplicated for (trivial) differences
between the 32-bit and 64-bit versions.
While doing that, it also speeds them up by doing the accesses a word at
a time. Finally, the new routines also properly handle the case of
hitting the end of the address space, which we have never done correctly
before (fs/namei.c has a hack around it for that reason).
Despite all these improvements, it actually removes more lines than it
adds, due to the de-duplication. Also, we no longer export (or define)
the legacy __strncpy_from_user() function (that was defined to not do
the user permission checks), since it's not actually used anywhere, and
the user address space checks are built in to the new code.
Other architecture maintainers have been notified that the old hack in
fs/namei.c will be going away in the 3.5 merge window, in case they
copied the x86 approach of being a bit cavalier about the end of the
address space.
Cc: linux-arch@vger.kernel.org
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Peter Anvin" <hpa@zytor.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Re-define XHCI_LEGACY_DISABLE_SMI and used it in right way. All SMI enable
bits will be cleared to zero and flag bits 29:31 are also cleared to zero.
Other bits should be presvered as Table 146.
This patch should be backported to kernels as old as 2.6.31.
Signed-off-by: Alex He <alex.he@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
The caller is allowed to specify the GFP flags for these functions.
We should prefer their flags unless we have good reason. For
example, if we take a spin_lock ourselves we'd need to use
GFP_ATOMIC. But in this case it's safe to use the callers GFP
flags.
The callers all pass GFP_ATOMIC here, so this change doesn't affect
how the kernel behaves but we may add other callers later and this
is a cleanup.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The suspend operation of VIA xHCI host have some issues and
hibernate operation works fine, so The XHCI_RESET_ON_RESUME
quirk is added for it.
This patch should base on "xHCI: Don't write zeroed pointer
to xHC registers" that is released by Sarah. Otherwise, the
host system error will ocurr in the hibernate operation
process.
This should be backported to stable kernels as old as 2.6.37,
that contain the commit c877b3b2ad
"xhci: Add reset on resume quirk for asrock p67 host".
Signed-off-by: Elric Fu <elricfu1@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
When the Seagate Goflex USB3.0 device is attached to VIA xHCI
host, sometimes the device will downgrade mode to high speed.
By the USB analyzer, I found the device finished the link
training process and worked at superspeed mode. But the device
descriptor got from the device shows the device works at 2.1.
It is very strange and seems like the device controller of
Seagate Goflex has a little confusion.
The first 8 bytes of device descriptor should be:
12 01 00 03 00 00 00 09
But the first 8 bytes of wrong device descriptor are:
12 01 10 02 00 00 00 40
The wrong device descriptor caused the initialization of mass
storage failed. After a while, the device would be recognized
as a high speed device and works fine.
This patch will warm reset the device to fix the issue after
finding the bcdUSB field of device descriptor isn't 0x0300
but the speed mode of device is superspeed.
This patch should be backported to kernels as old as 3.2, or ones that
contain the commit 75d7cf72ab "usbcore:
refine warm reset logic".
Signed-off-by: Elric Fu <elricfu1@gmail.com>
Acked-by: Andiry Xu <Andiry.Xu@amd.com>
Acked-by: Sergei Shtylyov <sshtylyov@mvista.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
The xHCI 1.0 spec errata released on June 13, 2011, changes the ordering
that the xHCI registers are saved and restored in. It moves the
interrupt pending (IMAN) and interrupt control (IMOD) registers to be
saved and restored last. I believe that's because the host controller
may attempt to fetch the event ring table when interrupts are
re-enabled. Therefore we need to restore the event ring registers
before we re-enable interrupts.
This should be backported to kernels as old as 2.6.37, that contain the
commit 5535b1d5f8 "USB: xHCI: PCI power
management implementation"
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Elric Fu <elricfu1@gmail.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: stable@vger.kernel.org
The xhci_save_registers() function saved the event ring dequeue pointer
in the s3 register structure, but xhci_restore_registers() never
restored it. No other code in the xHCI successful resume path would
ever restore it either. Fix that.
This should be backported to kernels as old as 2.6.37, that contain the
commit 5535b1d5f8 "USB: xHCI: PCI power
management implementation".
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Elric Fu <elricfu1@gmail.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: stable@vger.kernel.org
When xhci_mem_cleanup() is called, we can't be sure if the xHC is
actually halted. We can ask the xHC to halt by writing to the RUN bit
in the command register, but that might timeout due to a HW hang.
If the host controller is still running, we should not write zeroed
values to the event ring dequeue pointers or base tables, the DCBAA
pointers, or the command ring pointers. Eric Fu reports his VIA VL800
host accesses the event ring pointers after a failed register restore on
resume from suspend. The hypothesis is that the host never actually
halted before the register write to change the event ring pointer to
zero.
Remove all writes of zeroed values to pointer registers in
xhci_mem_cleanup(). Instead, make all callers of the function reset the
host controller first, which will reset those registers to zero.
xhci_mem_init() is the only caller that doesn't first halt and reset the
host controller before calling xhci_mem_cleanup().
This should be backported to kernels as old as 2.6.32.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Elric Fu <elricfu1@gmail.com>
Cc: stable@vger.kernel.org
Eric Fu reports a problem with his VIA host controller fetching a zeroed
event ring pointer on resume from suspend. The host should have been
halted, but we can't be sure because that code ignores the return value
from xhci_halt(). Print a warning when the host controller refuses to
halt within XHCI_MAX_HALT_USEC (currently 16 seconds).
(Update: it turns out that the VIA host controller is reporting a halted
state when it fetches the zeroed event ring pointer. However, we still
need this warning for other host controllers.)
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
While we're at that, define IMAN bitfield to aid readability.
The interrupt enable bit should be set once on driver init, and we
shouldn't need to continually re-enable it. Commit c21599a3 introduced
a read of the irq_pending register, and that allows us to preserve the
state of the IE bit. Before that commit, we were blindly writing 0x3 to
the register.
This patch should be backported to kernels as old as 2.6.36, or ones
that contain the commit c21599a361 "USB:
xhci: Reduce reads and writes of interrupter registers".
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
keyctl_session_to_parent(task) sets ->replacement_session_keyring,
it should be processed and cleared by key_replace_session_keyring().
However, this task can fork before it notices TIF_NOTIFY_RESUME and
the new child gets the bogus ->replacement_session_keyring copied by
dup_task_struct(). This is obviously wrong and, if nothing else, this
leads to put_cred(already_freed_cred).
change copy_creds() to clear this member. If copy_process() fails
before this point the wrong ->replacement_session_keyring doesn't
matter, exit_creds() won't be called.
Cc: <stable@vger.kernel.org>
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Running 'perf kvm --host --guest --guestmount /tmp/guestmount record -a -g -- sleep 2'
Was resulting in a segfault. For event type PERF_RECORD_MMAP,
event->ip.pid is being used in perf_session__find_machine_for_cpumode,
which is not correct.
The event->ip.pid field happens to be 0 in this case and results in
returning a NULL machine object. Finally, access to self->pid in
machine__mmap_name, results in a segfault later.
For PERF_RECORD_MMAP type, pass event->mmap.pid.
Signed-off-by: Nikunj A. Dadhania <nikunj@linux.vnet.ibm.com>
Reviewed-by: David Ahern <dsahern@gmail.com>
Tested-by: David Ahern <dsahern@gmail.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Stephane Eranian <eranian@google.com>
Cc: Nikunj A. Dadhania <nikunj@linux.vnet.ibm.com>
Link: http://lkml.kernel.org/r/20120409081835.10576.22018.stgit@abhimanyu.in.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Marc Merlin reported many order-1 allocations failures in TX path on its
wireless setup, that dont make any sense with MTU=1500 network, and non
SG capable hardware.
After investigation, it turns out TCP uses sk_stream_alloc_skb() and
used as a convention skb_tailroom(skb) to know how many bytes of data
payload could be put in this skb (for non SG capable devices)
Note : these skb used kmalloc-4096 (MTU=1500 + MAX_HEADER +
sizeof(struct skb_shared_info) being above 2048)
Later, mac80211 layer need to add some bytes at the tail of skb
(IEEE80211_ENCRYPT_TAILROOM = 18 bytes) and since no more tailroom is
available has to call pskb_expand_head() and request order-1
allocations.
This patch changes sk_stream_alloc_skb() so that only
sk->sk_prot->max_header bytes of headroom are reserved, and use a new
skb field, avail_size to hold the data payload limit.
This way, order-0 allocations done by TCP stack can leave more than 2 KB
of tailroom and no more allocation is performed in mac80211 layer (or
any layer needing some tailroom)
avail_size is unioned with mark/dropcount, since mark will be set later
in IP stack for output packets. Therefore, skb size is unchanged.
Reported-by: Marc MERLIN <marc@merlins.org>
Tested-by: Marc MERLIN <marc@merlins.org>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Marc Merlin reported many order-1 allocations failures in TX path on its
wireless setup, that dont make any sense with MTU=1500 network, and non
SG capable hardware.
Turns out part of the problem comes from pskb_expand_head() not using
ksize() to get exact head size given by kmalloc(). Doing the same thing
than __alloc_skb() allows more tailroom in skb and can prevent future
reallocations.
As a bonus, struct skb_shared_info becomes cache line aligned.
Reported-by: Marc MERLIN <marc@merlins.org>
Tested-by: Marc MERLIN <marc@merlins.org>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
As it stands the bridge IGMP snooping system will respond to
group leave messages with queries for remaining membership.
This is both unnecessary and undesirable. First of all any
multicast routers present should be doing this rather than us.
What's more the queries that we send may end up upsetting other
multicast snooping swithces in the system that are buggy.
In fact, we can simply remove the code that send these queries
because the existing membership expiry mechanism doesn't rely
on them anyway.
So this patch simply removes all code associated with group
queries in response to group leave messages.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Since there are still many Acer models that might not be covered by
the current fixup table, let's add back a few typical model names so
that user can test the fixup without recompiling.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
According to an internal workaround master list, we need to set bit 5
of register 9400 to avoid issues with color blits.
Testing shows that this seems to fix the blitter hangs when fbc is
enabled on snb, thanks to Chris Wilson for figuring this out.
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Michael "brot" Groh <michael.groh@minad.de>
Acked-by: Ben Widawsky <ben@bwidawsk.net>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The 845g shares the errata with i830 whereby executing a command
within 2 cachelines of the end of the ringbuffer may cause a GPU hang.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
