3.2.36-stable review
Subsystems (104)
cover 3.2.36-stable review
This is the start of the stable review cycle for the 3.2.36 release. There are 173 patches in this series, which will be posted as responses to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed Jan 2 20:00:00 GMT 2013. Anything received after that time might be too late.
A combined patch relative to 3.2.35 will be posted as an additional response to this. A shortlog and diffstat can be found below.
Ben.
-------------
Aaron Lu (1):
libata: set dma_mode to 0xff in reset
[5416912af75de9cba5d1c75b99a7888b0bbbd2fb]Al Viro (1):
ARM: missing ->mmap_sem around find_vma() in swp_emulate.c
[7bf9b7bef881aac820bf1f2e9951a17b09bd7e04]Alan Cox (3):
ACPI: missing break
[879dca019dc43a1622edca3e7dde644b14b5acc5]
ne2000: add the right platform device
[da9da01d9199b5bb15289d0859053c9aa3a34ac0]
pnpacpi: fix incorrect TEST_ALPHA() test
[cdc87c5a30f407ed1ce43d8a22261116873d5ef1]
Alan Stern (3):
USB: EHCI: bugfix: urb->hcpriv should not be NULL
[2656a9abcf1ec8dd5fee6a75d6997a0f2fa0094e]
USB: OHCI: workaround for hardware bug: retired TDs not added to the Done Queue
[50ce5c0683aa83eb161624ea89daa5a9eee0c2ce]
USB: fix endpoint-disabling for failed config changes
[36caff5d795429c572443894e8789c2150dd796b]Alasdair G Kergon (1):
dm ioctl: prevent unsafe change to dm_ioctl data_size
[e910d7ebecd1aac43125944a8641b6cb1a0dfabe]
Alex Deucher (4):
drm/radeon/dce32+: use fractional fb dividers for high clocks
[a02dc74b317d78298cb0587b9b1f6f741fd5c139]
drm/radeon/kms: use frac fb div on APUs
[37d4174d2d252c37dcb3d88cafae488542087848]
drm/radeon: fix eDP clk and lane setup for scaled modes
[93927f9c1db5f55085457e820f0631064c7bfa34]
drm: fix documentation for drm_crtc_set_mode()
[4c9287c6009b37754c42e0ba73a4cc79de92d8f8]
Alexander Graf (1):
KVM: PPC: 44x: fix DCR read/write
[e43a028752fed049e4bd94ef895542f96d79fa74]
Alexander Shiyan (1):
irda: sir_dev: Fix copy/paste typo
[2355a62bcbdcc4b567425bab036bfab6ade87eed]
Alexander Stein (1):
can: Do not call dev_put if restart timer is running upon close
[ab48b03ec9ae1840a1e427e2375bd0d9d554b4ed]
Alexey Kaminsky (1):
HID: apple: Add Apple wireless keyboard 2011 ANSI PID
[0a97e1e9f9a6765e6243030ac42b04694f3f3647]
Alexis R. Cortes (1):
usb: host: xhci: Stricter conditional for Z1 system models for Compliance Mode Patch
[b0e4e606ff6ff26da0f60826e75577b56ba4e463]
Andreas Hartmann (1):
rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails
[be03d4a45c09ee5100d3aaaedd087f19bc20d01f]
Anton Blanchard (1):
powerpc: Fix CONFIG_RELOCATABLE=y CONFIG_CRASH_DUMP=n build
[11ee7e99f35ecb15f59b21da6a82d96d2cd3fcc8]
Artem Bityutskiy (1):
proc: pid/status: show all supplementary groups
[8d238027b87e654be552eabdf492042a34c5c300]
Ben Hutchings (4):
HID: Add Apple wireless keyboard 2011 ANSI to special driver list
[f9af7b9edccb87d4d80b58687ab63e58f3b64c4c]
Revert "device_cgroup: fix RCU usage"
[not upstream; change was correct for mainline but not 3.2]
Revert "mm: vmscan: fix endless loop in kswapd balancing"
[not upstream; change was correct for mainline but not 3.2]
mm: add kmap_to_page()
[part of 5a178119b0fbe37f7dfb602b37df9cc4b1dc9d71]
Bjørn Mork (1):
USB: option: blacklist network interface on Huawei E173
[f36446cf9bbebaa03a80d95cfeeafbaf68218249]
Boris Ostrovsky (1):
x86,AMD: Power driver support for AMD's family 16h processors
[22e32f4f57778ebc6e17812fa3008361c05d64f9]
Bryan Schumaker (1):
NFS: Add sequence_priviliged_ops for nfs4_proc_sequence()
[6bdb5f213c4344324f600dde885f25768fbd14db]
Calvin Walton (1):
i915: Quirk no_lvds on Gigabyte GA-D525TUD ITX motherboard
[a51d4ed01e5bb39d2cf36a12f9976ab08872c192]
Charles Keepax (1):
mfd: Only unregister platform devices allocated by the mfd core
[b9fbb62eb61452d728c39b2e5020739c575aac53]
Chase Douglas (1):
HID: hid-magicmouse: Add pointer and buttonpad properties for Magic Trackpad
[503f7d53b368c8e4e13a7756220c0536fcf1a034]
Chris Ball (1):
Revert misapplied "mmc: sh-mmcif: avoid oops on spurious interrupts"
[6984f3c31bb57cb7491dbec1be44b74bd00f4648]
Chris Wilson (2):
drm/i915: Add no-lvds quirk for Supermicro X7SPA-H
[c31407a3672aaebb4acddf90944a114fa5c8af7b]
drm/i915: Close race between processing unpin task and queueing the flip
[e7d841ca03b7ab668620045cd7b428eda9f41601]
Christian Borntraeger (1):
s390/kvm: dont announce RRBM support
[87cac8f879a5ecd7109dbe688087e8810b3364eb]
Corentin Chary (1):
acpi/video_detect: blacklist samsung x360
[084940d5b101e9ca91a689eb5048151b14076839]
Corey Minyard (1):
CRIS: fix I/O macros
[c24bf9b4cc6a0f330ea355d73bfdf1dae7e63a05]
Dan Carpenter (3):
drivers/leds/leds-lp5521.c: fix lp5521_read() error handling
[5bc9ad774c063f6b41965e7314f2c26aa5e465a0]
ftrace: Clear bits properly in reset_iter_read()
[70f77b3f7ec010ff9624c1f2e39a81babc9e2429]
telephony: ijx: buffer overflow in ixj_write_cid()
[not upstream; driver has been removed]
Dan Williams (1):
i2400m: add Intel 6150 device IDs
[999a7c5776a0ed2133645fa7e008bec05bda9254]Daniel Vetter (2):
drm/i915: disable cpt phase pointer fdi rx workaround
[539526b4137bc0e7a8806c38c8522f226814a0e6]
drm/i915: drop unnecessary check from fdi_link_train code
[8f5718a6d9a29bf1f51910c6b32bd0244f905303]
David Jeffery (1):
[SCSI] qla2xxx: Test and clear FCPORT_UPDATE_NEEDED atomically.
[a394aac88506159e047630fc90dc2242568382d8]
David Milburn (1):
sata_svw: check DMA start bit before reset
[b03e66a6be91f8389fcd902ab6c1563db1c9c06b]
David Rientjes (1):
thp, memcg: split hugepage for memcg oom on cow
[1f1d06c34f7675026326cd9f39ff91e4555cf355]
David Woodhouse (2):
intel-iommu: Free old page tables before creating superpage
[6491d4d02893d9787ba67279595990217177b351]
solos-pci: fix double-free of TX skb in DMA mode
[cae49ede00ec3d0cda290b03fee55b72b49efc11]
Dmitry Rogozhkin (1):
drm/i915: EBUSY status handling added to i915_gem_fault().
[e79e0fe380847493266fba557217e2773c61bd1b]
Duncan Roe (1):
ALSA: hda - Fix missing beep on ASUS X43U notebook
[7110005e8d5c3cd418fc4b64f9f124f004422a9a]
Emmanuel Grumbach (1):
iwlwifi: don't handle masked interrupt
[25a172655f837bdb032e451f95441bb4acec51bb]
Eric Dumazet (1):
rcu: Fix batch-limit size problem
[878d7439d0f45a95869e417576774673d1fa243f]
Eric Sandeen (1):
ext4: init pagevec in ext4_da_block_invalidatepages
[66bea92c69477a75a5d37b9bfed5773c92a3c4b4]
Eugene Shatokhin (1):
ext4: fix memory leak in ext4_xattr_set_acl()'s error path
[24ec19b0ae83a385ad9c55520716da671274b96c]
Eugeni Dodonov (2):
drm/i915: add Ivy Bridge GT2 Server entries
[cc22a938fc1db0c8ef5e693a69b159c4b851dab3]
drm: give up on edid retries when i2c bus is not responding
[9292f37e1f5c79400254dca46f83313488093825]
Felix Fietkau (2):
Revert "ath9k_hw: Update AR9003 high_power tx gain table"
[9c170e068636deb3e3f96114034bb711675f0faa]
ath9k_hw: Fix signal strength / channel noise reporting
[b7c0c238898d200e80487516e2b67aba2a522cc0]
Gabor Juhos (1):
ath9k: ar9003: fix OTP register offsets for AR9340
[b3cd8021379306c0be6932e4d3b4b01efc681769]
Greg KH (1):
USB: mark uas driver as BROKEN
[fb37ef98015f864d22be223a0e0d93547cd1d4ef]
Guenter Roeck (3):
hwmon: (coretemp) Add support for Atom CE4110/4150/4170
[1102dcab849313bd5a340b299b5cf61b518fbc0f]
hwmon: (coretemp) Add support for Atom D2000 and N2000 series CPU models
[5592906f8b01282ea3c2acaf641fd067ad4bb3dc]
hwmon: (coretemp) Improve support for TjMax detection on Atom CPUs
[41e58a1f2b90c88d94b4bd84beb9927a4c2704e9]Gustavo Padovan (1):
Bluetooth: Add missing lock nesting notation
[dc2a0e20fbc85a71c63aa4330b496fda33f6bf80]
Herton Ronaldo Krzesinski (1):
USB: cdc-wdm: fix regression on buffer deallocation
[not upstream; code has been removed]
Huacai Chen (1):
MIPS: Fix poweroff failure when HOTPLUG_CPU configured.
[8add1ecb81f541ef2fcb0b85a5470ad9ecfb4a84]
J. Bruce Fields (2):
nfsd4: fix oops on unusual readlike compound
[d5f50b0c290431c65377c4afa1c764e2c3fe5305]
nfsd: fix v4 reply caching
[57d276d71aef7d8305ff002a070cb98deb2edced]
Jan Beulich (1):
x86: hpet: Fix masking of MSI interrupts
[6acf5a8c931da9d26c8dd77d784daaf07fa2bff0]
Jani Nikula (2):
drm/i915: do not default to 18 bpp for eDP if missing from VBT
[9a30a61f3516871c5c638fd7c025fbaa11ddf7fe]
drm/i915: do not ignore eDP bpc settings from vbt
[2f4f649a69a9eb51f6e98130e19dd90a260a4145]
Jaroslav Resler (1):
Bluetooth: Add support for BCM20702A0 [04ca, 2003]
[0c1abbd1aa0416258881c303a88e618cbca0759c]Jay Purohit (1):
usb/ipheth: Add iPhone 5 support
[af1b85e49089f945deb46258b0fc4bc9910afb22]
Jean Delvare (2):
hwmon: (coretemp) Improve support of recent Atom CPU models
[fcc14ac1a86931f38da047cf8fb634c6db7b58bc]
i7300_edac: Fix error flag testing
[7e06b7a3333f5c7a0cec12aff20d39c5c87c0795]
Jeff Cook (1):
Bluetooth: Add support for BCM20702A0 [0b05, 17b5]
[1ee3ff6110c16acfc915a79b1e3feb5013c41e75]Jerome Glisse (1):
drm/radeon: fix amd afusion gpu setup aka sumo v2
[bd25f0783dc3fb72e1e2779c2b99b2d34b67fa8a]
Jiri Slaby (1):
MISC: hpilo, remove pci_disable_device
[bcdee04ea7ae0406ae69094f6df1aacb66a69a0b]
Johannes Berg (2):
ipv4: ip_check_defrag must not modify skb before unsharing
[1bf3751ec90cc3174e01f0d701e8449ce163d113]
iwlwifi: handle DMA mapping failures
[7c34158231b2eda8dcbd297be2bb1559e69cb433]
Julius Werner (1):
xhci: fix null-pointer dereference when destroying half-built segment rings
[68e5254adb88bede68285f11fb442a4d34fb550c]
Kamil Iskra (1):
ACPI / battery: Correct battery capacity values on Thinkpads
[4000e626156935dfb626321ce09cae2c833eabbb]
Kees Cook (2):
exec: do not leave bprm->interp on stack
[b66c5984017533316fd1951770302649baf1aa33]
use clamp_t in UNAME26 fix
[31fd84b95eb211d5db460a1dda85e004800a7b52]Kevin McKinney (2):
Staging: bcm: Add two products and remove an existing product.
[4f29ef050848245f7c180b95ccf67dfcd76b1fd8]
Staging: bcm: Create and initialize new device id in InterfaceInit
[e66fc1fba248738d32f3b64508f9ef1176d9e767]
Krzysztof Wilczynski (1):
scsi: aha152x: Fix sparse warning and make printing pointer address more portable.
[b631cf1f899f9d2e449884dbccc34940637c639f]
Lan Tianyu (2):
ACPI / PM: Add Sony Vaio VPCEB1S1E to nonvs blacklist.
[876ab79055019e248508cfd0dee7caa3c0c831ed]
ACPI / video: Add "Asus UL30VT" to ACPI video detect blacklist
[d0c2ce16bec0afa6013b4c5220ca4c9c67210215]
[email protected] (1):
USB: add new zte 3g-dongle's pid to option.c
[31b6a1048b7292efff8b5b53ae3d9d29adde385e]
Malcolm Priestley (6):
staging: vt6656: 64 bit fixes : correct all type sizes
[7730492855a2f9c828599bcd8d62760f96d319e4]
staging: vt6656: 64 bit fixes: fix long warning messages.
[b4dc03af5513774277c9c36b12a25cd3f25f4404]
staging: vt6656: 64 bit fixes: use u32 for QWORD definition.
[a552397d5e4ef0cc0bd3e9595d6acc9a3b381171]
staging: vt6656: 64bit fixes: key.c/h change unsigned long to u32
[c0d05b305b00c698b0a8c1b3d46c9380bce9db45]
staging: vt6656: 64bit fixes: vCommandTimerWait change calculation of timer.
[70e227790d4ee4590023d8041a3485f8053593fc]
staging: vt6656: [BUG] out of bound array reference in RFbSetPower.
[ab1dd9963137a1e122004d5378a581bf16ae9bc8]
Marco Stornelli (1):
ramoops: fix use of rounddown_pow_of_two()
[fdb5950754eb3dedb9fea7c8828d3e51d9dbc3f7]
Marcos Chaparro (1):
Bluetooth: ath3k: Add support for VAIO VPCEH [0489:e027]
[acd9454433e28c1a365d8b069813c35c1c3a8ac3]
Marek Szyprowski (1):
mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
[387870f2d6d679746020fa8e25ef786ff338dc98]
Mark Brown (2):
regmap: debugfs: Avoid overflows for very small reads
[db04328c167ff8e7c57f4a3532214aeada3a82fd]
regulator: wm831x: Set the new rather than old value for DVS VSEL
[13ae633cf729b0ecb677b75b04886ff8fada8fad]
Markus Becker (1):
USB: cp210x: add Virtenio Preon32 device id
[356fe44f4b8ece867bdb9876b1854d7adbef9de2]Martin Teichmann (1):
USB: ftdi_sio: Add support for Newport AGILIS motor drivers
[d7e14b375b40c04cd735b115713043b69a2c68ac]
Masanari Iida (1):
drivers/leds/leds-lp5521.c: fix typo
[3a2fd4a14112452eb5c1a079ac8b3f4842762afe]
Mauro Carvalho Chehab (1):
i82975x_edac: Fix dimm label initialization
[479696840239e0cc43efb3c917bdcad2174d2215]
Mel Gorman (1):
tmpfs: fix shared mempolicy leak
[18a2f371f5edf41810f6469cb9be39931ef9deb9]
Mikael Pettersson (1):
sata_promise: fix hardreset lockdep error
[3100d49d3cd236443faae9d81137c81b22d36003]
Mike Galbraith (1):
Revert "sched, autogroup: Stop going ahead if autogroup is disabled"
[fd8ef11730f1d03d5d6555aa53126e9e34f52f12]
Mike Miller (1):
[SCSI] hpsa: gen8plus Smart Array IDs
[fe0c9610bb68dd0aad1017456f5e3c31264d70c2]
Mikulas Patocka (1):
dm persistent data: rename node to btree_node
[550929faf89e2e2cdb3e9945ea87d383989274cf]
Namjae Jeon (1):
udf: fix memory leak while allocating blocks during write
[2fb7d99d0de3fd8ae869f35ab682581d8455887a]
Neil Brown (1):
nfsd: avoid permission checks on EXCLUSIVE_CREATE replay
[7007c90fb9fef593b4aeaeee57e6a6754276c97c]
NeilBrown (2):
NFS: avoid NULL dereference in nfs_destroy_server
[f259613a1e4b44a0cf85a5dafd931be96ee7c9e5]
vfs: d_obtain_alias() needs to use "/" as default name.
[b911a6bdeef5848c468597d040e3407e0aee04ce]
[email protected] (1):
bonding: fix race condition in bonding_store_slaves_active
[e196c0e579902f42cf72414461fb034e5a1ffbf7]
Oleg Nesterov (1):
freezer: PF_FREEZER_NOSIG should be cleared along with PF_NOFREEZE
[not upstream; flag has been removed]
Ondrej Zary (1):
x86, 8042: Enable A20 using KBC to fix S3 resume on some MSI laptops
[ad68652412276f68ad4fe3e1ecf5ee6880876783]
Paul Walmsley (1):
ARM: 7566/1: vfp: fix save and restore when running on pre-VFPv3 and CONFIG_VFPv3 set
[39141ddfb63a664f26d3f42f64ee386e879b492c]
Paulo Zanoni (1):
drm/i915: make the panel fitter work on pipes B and C on IVB
[13888d78c664a1f61d7b09d282f5916993827a40]
Peter Korsgaard (1):
usb: ftdi_sio: fixup BeagleBone A5+ quirk
[1a88d5eee2ef2ad1d3c4e32043e9c4c5347d4fc1]
Peter Popovec (1):
Input: walkera0701 - fix crash on startup
[a455e2985f57e2a71566bb8850094af38b2c932d]
Petr Matousek (1):
KVM: x86: invalid opcode oops on SET_SREGS with OSXSAVE bit set (CVE-2012-4461)
[6d1068b3a98519247d8ba4ec85cd40ac136dbdf9]
Rafael J. Wysocki (1):
ACPI / PNP: Do not crash due to stale pointer use during system resume
[a6b5e88c0e42093b9057856f35770966c8c591e3]
Rafał Miłecki (1):
bcma: mips: fix clearing device IRQ
[cbbc0138efe1dcd5426b8fc5d87741f5057aee72]
Rajkumar Manoharan (1):
ath9k_hw: Enable hw PLL power save for AR9462
[1680260226a8fd2aab590319da83ad8e610da9bd]
Robin Holt (1):
SGI-XP: handle non-fatal traps
[891348ca0f66206f1dc0e30d63757e3df1ae2d15]
Roland Dreier (1):
iscsi-target: Always send a response before terminating iSCSI connection
[1c5c12c666fda27c7c494b34934a0a0631a48130]
Russell Webb (1):
xhci: Add Lynx Point LP to list of Intel switchable hosts
[bb1e5dd7113d2fd178d3af9aca8f480ae0468edf]
Sarah Sharp (3):
xHCI: Fix TD Size calculation on 1.0 hosts.
[4525c0a10dff7ad3669763c28016c7daffc3900e]
xhci: Extend Fresco Logic MSI quirk.
[bba18e33f25072ebf70fd8f7f0cdbf8cdb59a746]
xhci: Fix conditional check in bandwidth calculation.
[392a07ae3316f2b90b39ce41e66d6f6b5c95de90]
Sarveshwar Bandi (1):
bonding: Bonding driver does not consider the gso_max_size/gso_max_segs setting of slave devices.
[0e376bd0b791ac6ac6bdb051492df0769c840848]
Sasha Levin (1):
[SCSI] prevent stack buffer overflow in host_reset
[072f19b4bea31cdd482d79f805413f2f9ac9e233]
Sebastian Andrzej Siewior (5):
target/file: Fix 32-bit highmem breakage for SGL -> iovec mapping
[40ff2c3b3da35dd3a00ac6722056a59b4b3f2caf]
usb: gadget: midi: free hs descriptors
[d185039f7982eb82cf8d03b6fb6689587ca5af24]
usb: gadget: network: fix bind() error path
[e79cc615a9bb44da72c499ccfa2c9c4bbea3aa84]
usb: gadget: phonet: free requests in pn_bind()'s error path
[d0eca719dd11ad0619e8dd6a1f3eceb95b0216dd]
usb: gadget: uvc: fix error path in uvc_function_bind()
[0f9df939385527049c8062a099fbfa1479fe7ce0]Sebastian Ott (1):
s390/cio: fix pgid reserved check
[d99e79ec5574fc556c988f613ed6175f6de66f4a]
Sergei Shtylyov (1):
usb: musb: cppi_dma: export cppi_interrupt()
[8b416b0b25d5d8ddb3a91c1d20e1373582c50405]
Seth Heasley (1):
ALSA: hda - Add Lynx Point HD Audio Controller DeviceIDs
[8bc039a1e15a72da8426b84293723fb7181f0b5e]
Shuah Khan (1):
powerpc: fix wii_memory_fixups() compile error on 3.0.y tree
[not upstream; code has been removed]
Srinidhi KASAGAR (1):
drivers/leds/leds-lp5521.c: ret may be uninitialized
[42960b76d2c6a44d7e8000f4eb9a4ca1780059ff]
Stanislaw Gruszka (2):
Revert: "rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails"
[ab9d6e4ffe192427ce9e93d4f927b0faaa8a941e]
mac80211: introduce IEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAIL
[5b632fe85ec82e5c43740b52e74c66df50a37db3]Stephan Gatzka (1):
firewire: net: Fix handling of fragmented multicast/broadcast packets.
[9d2373420900a39f5212a3b289331aa3535b1000]
Steven Rostedt (1):
ring-buffer: Fix NULL pointer if rb_set_head_page() fails
[54f7be5b831254199522523ccab4c3d954bbf576]
Takashi Iwai (6):
ALSA: hda - Add stereo-dmic fixup for Acer Aspire One 522
[63a077e27648b4043b1ca1b4e29f0c42d99616b6]
ALSA: hda - Always turn on pins for HDMI/DP
[6169b673618bf0b2518ce413b54925782a603f06]
ALSA: hda - Fix pin configuration of HP Pavilion dv7
[8ae5865ec77c22462c736846a0679947a6953548]
ALSA: hda - Fix the wrong pincaps set in ALC861VD dallas/hp fixup
[b78562b10fa66175e30b76073e32a0ad8d92aa83]
ALSA: usb-audio: Avoid autopm calls after disconnection
[59866da9e4ae54819e3c4e0a8f426bdb0c2ef993]
ALSA: usb-audio: Fix missing autopm for MIDI input
[f5f165418cabf2218eb466c0e94693b8b1aee88b]
Tejun Heo (4):
cgroup: cgroup_subsys->fork() should be called after the task is added to css_set
[5edee61edeaaebafe584f8fb7074c1ef4658596b]
cgroup: remove incorrect dget/dput() pair in cgroup_create_dir()
[175431635ec09b1d1bba04979b006b99e8305a83]
freezer: add missing mb's to freezer_count() and freezer_should_skip()
[dd67d32dbc5de299d70cc9e10c6c1e29ffa56b92]
workqueue: convert BUG_ON()s in __queue_delayed_work() to WARN_ON_ONCE()s
[fc4b514f2727f74a4587c31db87e0e93465518c3]Thomas Gleixner (1):
genirq: Always force thread affinity
[04aa530ec04f61875b99c12721162e2964e3318c]
Tommi Rantala (2):
sctp: fix -ENOMEM result with invalid user space pointer in sendto() syscall
[6e51fe7572590d8d86e93b547fab6693d305fd0d]
sctp: fix memory leak in sctp_datamsg_from_user() when copy from user space fails
[be364c8c0f17a3dd42707b5a090b318028538eb9]
Wei Yongjun (1):
iscsit: use GFP_ATOMIC under spin lock
[3c989d7603872bf878840f7ce3ea49b73bea4c6c]
Will Deacon (4):
ARM: mm: use pteval_t to represent page protection values
[864aa04cd02979c2c755cb28b5f4fe56039171c0]
mm: highmem: export kmap_to_page for modules
[f0263d2d222e9e25f2587e51a9dc58c6fb2a9352]
virtio: 9p: correctly pass physical address to userspace for high pages
[b9cdc88df8e63e81c723b82c286fc97f5d0dc325]
virtio: force vring descriptors to be allocated from lowmem
[b92b1b89a33c172c075edccf6afb0edc41d851fd]
Wolfram Sang (1):
mtd: nand: gpmi: reset BCH earlier, too, to avoid NAND startup problems
[6f2a6a52560ad8d85710aabd92b7a3239b3a6b07]
Wu Fengguang (1):
ALSA: hda - add id for Atom Cedar Trail HDMI codec
[6edc59e602b36cd3c95a426ef6e8cad0344af8c7]
Xi Wang (1):
[SCSI] mvsas: fix undefined bit shift
[beecadea1b8d67f591b13f7099559f32f3fd601d]
Xiaotian Feng (1):
[libata] fix Null pointer dereference on disk error
[26cd4d65deba587f3cf2329b6869ce02bcbe68ec]
Yanchuan Nian (1):
nfs: fix wrong object type in lockowner_slab
[3c40794b2dd0f355ef4e6bf8d85af5dcd7da7ece]
Yi Zou (1):
target/tcm_fc: fix the lockdep warning due to inconsistent lock state
[9f4ad44b264f8bb61ffdd607148215566568430d]
Zhang Rui (2):
ACPI / video: ignore BIOS initial backlight value for HP Folio 13-2000
[129ff8f8d58297b04f47b5d6fad81aa2d08404e1]
ACPI: do acpisleep dmi check when CONFIG_ACPI_SLEEP is set
[0ac1b1d7b7424cd6f129b5454b504b3cae746f0e]
Documentation/hwmon/coretemp | 12 +- Makefile | 4 +- arch/arm/include/asm/hwcap.h | 3 +- arch/arm/include/asm/vfpmacros.h | 12 +- arch/arm/kernel/swp_emulate.c | 2 + arch/arm/mm/mmu.c | 2 +- arch/arm/vfp/vfpmodule.c | 9 +- arch/cris/include/asm/io.h | 39 ++- arch/mips/kernel/process.c | 4 +- arch/powerpc/kernel/head_64.S | 2 +- arch/powerpc/kvm/44x_emulate.c | 2 + arch/powerpc/platforms/embedded6xx/wii.c | 6 +- arch/s390/kvm/kvm-s390.c | 2 +- arch/x86/kernel/hpet.c | 4 +- arch/x86/kvm/x86.c | 6 + drivers/acpi/battery.c | 77 +++++ drivers/acpi/processor_driver.c | 1 + drivers/acpi/sleep.c | 340 ++++++++++---------- drivers/acpi/video.c | 14 + drivers/acpi/video_detect.c | 37 +++ drivers/ata/libata-core.c | 1 + drivers/ata/libata-eh.c | 1 + drivers/ata/libata-scsi.c | 6 +- drivers/ata/sata_promise.c | 15 +- drivers/ata/sata_svw.c | 35 ++ drivers/atm/solos-pci.c | 5 +- drivers/base/regmap/regmap-debugfs.c | 2 +- drivers/bcma/driver_mips.c | 2 +- drivers/bluetooth/ath3k.c | 1 + drivers/bluetooth/btusb.c | 3 + drivers/char/agp/intel-agp.h | 1 + drivers/char/agp/intel-gtt.c | 2 + drivers/char/ramoops.c | 4 +- drivers/edac/i7300_edac.c | 8 +- drivers/edac/i82975x_edac.c | 11 +- drivers/firewire/net.c | 13 +- drivers/gpu/drm/drm_crtc_helper.c | 4 +- drivers/gpu/drm/drm_edid.c | 5 + drivers/gpu/drm/i915/i915_debugfs.c | 4 +- drivers/gpu/drm/i915/i915_drv.c | 1 + drivers/gpu/drm/i915/i915_gem.c | 5 + drivers/gpu/drm/i915/i915_irq.c | 4 +- drivers/gpu/drm/i915/i915_reg.h | 2 + drivers/gpu/drm/i915/intel_bios.c | 11 +- drivers/gpu/drm/i915/intel_display.c | 95 +++--- drivers/gpu/drm/i915/intel_drv.h | 5 +- drivers/gpu/drm/i915/intel_lvds.c | 16 + drivers/gpu/drm/radeon/atombios_crtc.c | 5 + drivers/gpu/drm/radeon/atombios_encoders.c | 2 +- drivers/gpu/drm/radeon/evergreen.c | 4 +- drivers/hid/hid-apple.c | 3 + drivers/hid/hid-core.c | 1 + drivers/hid/hid-ids.h | 1 + drivers/hid/hid-magicmouse.c | 2 + drivers/hwmon/coretemp.c | 34 +- drivers/hwmon/fam15h_power.c | 4 + drivers/input/joystick/walkera0701.c | 7 +- drivers/input/serio/i8042-x86ia64io.h | 9 + drivers/iommu/intel-iommu.c | 11 +- drivers/leds/leds-lp5521.c | 16 +- drivers/md/dm-ioctl.c | 8 + drivers/md/persistent-data/dm-btree-internal.h | 16 +- drivers/md/persistent-data/dm-btree-remove.c | 50 +-- drivers/md/persistent-data/dm-btree-spine.c | 6 +- drivers/md/persistent-data/dm-btree.c | 22 +- drivers/mfd/mfd-core.c | 15 +- drivers/misc/hpilo.c | 11 +- drivers/misc/sgi-xp/xpc_main.c | 34 +- drivers/mmc/host/sh_mmcif.c | 4 - drivers/mtd/nand/gpmi-nand/gpmi-lib.c | 9 + drivers/net/bonding/bond_main.c | 7 + drivers/net/bonding/bond_sysfs.c | 2 + drivers/net/can/dev.c | 3 +- drivers/net/ethernet/8390/ne.c | 1 + drivers/net/irda/sir_dev.c | 2 +- drivers/net/usb/ipheth.c | 5 + drivers/net/wimax/i2400m/i2400m-usb.h | 3 + drivers/net/wimax/i2400m/usb.c | 6 + .../net/wireless/ath/ath9k/ar9003_2p2_initvals.h | 172 +++++----- drivers/net/wireless/ath/ath9k/ar9003_eeprom.h | 6 +- drivers/net/wireless/ath/ath9k/ar9003_hw.c | 11 +- drivers/net/wireless/ath/ath9k/calib.c | 1 + drivers/net/wireless/ath/ath9k/calib.h | 3 + drivers/net/wireless/iwlwifi/iwl-trans-pcie-rx.c | 35 +- drivers/net/wireless/rt2x00/rt2800lib.c | 3 +- drivers/pnp/pnpacpi/core.c | 5 +- drivers/regulator/wm831x-dcdc.c | 2 +- drivers/s390/cio/device_pgid.c | 10 +- drivers/scsi/aha152x.c | 4 +- drivers/scsi/hpsa.c | 32 +- drivers/scsi/mvsas/mv_94xx.h | 14 +- drivers/scsi/mvsas/mv_sas.h | 2 +- drivers/scsi/qla2xxx/qla_os.c | 4 +- drivers/scsi/scsi_sysfs.c | 11 +- drivers/staging/bcm/InterfaceInit.c | 4 +- drivers/staging/bcm/InterfaceInit.h | 5 +- drivers/staging/vt6656/dpc.c | 4 +- drivers/staging/vt6656/key.c | 53 ++- drivers/staging/vt6656/key.h | 8 +- drivers/staging/vt6656/mac.c | 6 +- drivers/staging/vt6656/rf.c | 3 + drivers/staging/vt6656/rxtx.c | 18 +- drivers/staging/vt6656/ttype.h | 16 +- drivers/staging/vt6656/wcmd.c | 20 +- drivers/staging/vt6656/wpa2.h | 4 +- drivers/target/iscsi/iscsi_target.c | 2 +- drivers/target/iscsi/iscsi_target_login.c | 8 +- drivers/target/iscsi/iscsi_target_nego.c | 10 +- drivers/target/target_core_file.c | 9 +- drivers/target/tcm_fc/tfc_sess.c | 2 +- drivers/telephony/ixj.c | 24 +- drivers/usb/class/cdc-wdm.c | 4 +- drivers/usb/core/message.c | 53 +-- drivers/usb/gadget/f_ecm.c | 4 +- drivers/usb/gadget/f_eem.c | 5 +- drivers/usb/gadget/f_midi.c | 1 + drivers/usb/gadget/f_ncm.c | 4 +- drivers/usb/gadget/f_phonet.c | 8 +- drivers/usb/gadget/f_rndis.c | 4 +- drivers/usb/gadget/f_subset.c | 4 +- drivers/usb/gadget/f_uvc.c | 39 +-- drivers/usb/host/ehci-pci.c | 3 +- drivers/usb/host/ehci-q.c | 16 +- drivers/usb/host/ehci-sched.c | 4 +- drivers/usb/host/ohci-q.c | 19 ++ drivers/usb/host/pci-quirks.c | 4 +- drivers/usb/host/xhci-mem.c | 11 +- drivers/usb/host/xhci-pci.c | 7 +- drivers/usb/host/xhci-ring.c | 32 +- drivers/usb/host/xhci.c | 4 +- drivers/usb/musb/cppi_dma.c | 1 + drivers/usb/serial/cp210x.c | 1 + drivers/usb/serial/ftdi_sio.c | 3 +- drivers/usb/serial/ftdi_sio_ids.h | 6 + drivers/usb/serial/option.c | 25 ++ drivers/usb/storage/Kconfig | 2 +- drivers/virtio/virtio_ring.c | 7 + fs/binfmt_misc.c | 5 +- fs/binfmt_script.c | 4 +- fs/dcache.c | 2 +- fs/exec.c | 18 +- fs/ext4/acl.c | 6 +- fs/ext4/inode.c | 1 + fs/nfs/client.c | 3 +- fs/nfs/nfs4proc.c | 21 +- fs/nfsd/nfs4proc.c | 8 +- fs/nfsd/nfs4state.c | 2 +- fs/nfsd/nfs4xdr.c | 11 +- fs/nfsd/nfssvc.c | 2 +- fs/nfsd/vfs.c | 10 +- fs/proc/array.c | 2 +- fs/udf/inode.c | 4 + include/linux/binfmts.h | 1 + include/linux/cgroup.h | 1 - include/linux/freezer.h | 51 ++- include/linux/highmem.h | 7 + include/linux/mempolicy.h | 16 - include/linux/pci_ids.h | 1 + include/net/mac80211.h | 5 + kernel/cgroup.c | 52 ++- kernel/cgroup_freezer.c | 13 +- kernel/fork.c | 9 +- kernel/irq/manage.c | 23 +- kernel/rcutree.c | 14 +- kernel/sched_autogroup.c | 4 - kernel/sched_autogroup.h | 5 - kernel/sys.c | 2 +- kernel/trace/ftrace.c | 2 +- kernel/trace/ring_buffer.c | 7 +- kernel/workqueue.c | 4 +- mm/dmapool.c | 31 +- mm/highmem.c | 13 + mm/huge_memory.c | 3 + mm/memory.c | 18 +- mm/mempolicy.c | 22 -- mm/shmem.c | 26 +- mm/vmscan.c | 27 +- net/9p/trans_virtio.c | 3 +- net/bluetooth/rfcomm/sock.c | 4 +- net/ipv4/ip_fragment.c | 19 +- net/mac80211/status.c | 6 +- net/sctp/chunk.c | 20 +- net/sctp/socket.c | 4 +- security/device_cgroup.c | 6 +- sound/pci/hda/hda_intel.c | 5 + sound/pci/hda/patch_conexant.c | 1 + sound/pci/hda/patch_hdmi.c | 20 +- sound/pci/hda/patch_realtek.c | 5 +- sound/pci/hda/patch_sigmatel.c | 2 +- sound/usb/midi.c | 91 ++++-- 190 files changed, 1641 insertions(+), 926 deletions(-)
Signature · 2 lines
Ben Hutchings The world is coming to an end. Please log off.
PATCH 1/173 Revert "device_cgroup: fix RCU usage"
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ben Hutchings <[email protected]>
This reverts commit c5ee58688baa98bc3a4f6095a1acf6fd7fd9e967, which was commit 201e72acb2d3821e2de9ce6091e98859c316b29a upstream.
Herton Ronaldo Krzesinski pointed out that the race condition this dealt with does not exist in 3.2.y.
--- security/device_cgroup.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
security/device_cgroup.c +3 -3
@@ -202,8 +202,8 @@ static void devcgroup_destroy(struct cgroup_subsys *ss, dev_cgroup =cgroup_to_devcgroup (cgroup);list_for_each_entry_safe (wh, tmp, &dev_cgroup->whitelist, list) { -list_del_rcu (&wh->list); -kfree_rcu (wh, rcu); +list_del (&wh->list); +kfree (wh); }kfree (dev_cgroup); }
@@ -278,7 +278,7 @@ static int may_access_whitelist(struct dev_cgroup *c, {struct dev_whitelist_item *whitem; -list_for_each_entry_rcu (whitem, &c->whitelist, list) { +list_for_each_entry (whitem, &c->whitelist, list) {if (whitem->type &DEV_ALL )return 1 ;if ((refwh->type &DEV_BLOCK ) && !(whitem->type &DEV_BLOCK ))
PATCH 2/173 freezer: PF_FREEZER_NOSIG should be cleared along with PF_NOFREEZE
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Oleg Nesterov <[email protected]>
This patch is only for pre-v3.3 stable trees which backported b40a7959 "freezer: exec should clear PF_NOFREEZE along with PF_KTHREAD". v3.3+ doesn't need this fix.
b40a7959 is the trivial bugfix, but unfortunately I forgot that until 34b087e4 "freezer: kill unused set_freezable_with_signal()" there were another only-for-kernel-threads flag, PF_FREEZER_NOSIG, which should be cleared as well.
See https://bugs.launchpad.net/ubuntu/+source/v86d/+bug/1080530
The freezer fails because it expects that a PF_FREEZER_NOSIG task doesn't need a signal. Before b40a7959 it wrongly succeeds leaving the PF_NOFREEZE | PF_FREEZER_NOSIG task unfrozen.
fs/exec.c +2 -1
@@ -1095,7 +1095,8 @@ int flush_old_exec(struct linux_binprm * bprm->mm =NULL ;/* We're using it now */ set_fs (USER_DS ); - current->flags &= ~(PF_RANDOMIZE |PF_KTHREAD |PF_NOFREEZE ); + current->flags &= + ~(PF_RANDOMIZE |PF_KTHREAD |PF_NOFREEZE |PF_FREEZER_NOSIG );flush_thread (); current->personality &= ~bprm->per_clear;
PATCH 3/173 KVM: x86: invalid opcode oops on SET_SREGS with OSXSAVE bit set (CVE-2012-4461)
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Petr Matousek <[email protected]>
commit 6d1068b3a98519247d8ba4ec85cd40ac136dbdf9 upstream.
On hosts without the XSAVE support unprivileged local user can trigger oops similar to the one below by setting X86_CR4_OSXSAVE bit in guest cr4 register using KVM_SET_SREGS ioctl and later issuing KVM_RUN ioctl.
invalid opcode: 0000 [#2] SMP
Modules linked in: tun ip6table_filter ip6_tables ebtable_nat ebtables
...
Pid: 24935, comm: zoog_kvm_monito Tainted: G D 3.2.0-3-686-pae
EIP: 0060:[<f8b9550c>] EFLAGS: 00210246 CPU: 0
EIP is at kvm_arch_vcpu_ioctl_run+0x92a/0xd13 [kvm]
EAX: 00000001 EBX: 000f387e ECX: 00000000 EDX: 00000000
ESI: 00000000 EDI: 00000000 EBP: ef5a0060 ESP: d7c63e70
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Process zoog_kvm_monito (pid: 24935, ti=d7c62000 task=ed84a0c0 task.ti=d7c62000)
Stack: 00000001 f70a1200 f8b940a9 ef5a0060 00000000 00200202 f8769009 00000000 ef5a0060 000f387e eda5c020 8722f9c8 00015bae 00000000 ed84a0c0 ed84a0c0 c12bf02d 0000ae80 ef7f8740 fffffffb f359b740 ef5a0060 f8b85dc1 0000ae80 Call Trace: [<f8b940a9>] ? kvm_arch_vcpu_ioctl_set_sregs+0x2fe/0x308 [kvm] ... [<c12bfb44>] ? syscall_call+0x7/0xb Code: 89 e8 e8 14 ee ff ff ba 00 00 04 00 89 e8 e8 98 48 ff ff 85 c0 74
1e 83 7d 48 00 75 18 8b 85 08 07 00 00 31 c9 8b 95 0c 07 00 00 <0f> 01 d1 c7 45 48 01 00 00 00 c7 45 1c 01 00 00 00 0f ae f0 89
EIP: [<f8b9550c>] kvm_arch_vcpu_ioctl_run+0x92a/0xd13 [kvm] SS:ESP 0068:d7c63e70
QEMU first retrieves the supported features via KVM_GET_SUPPORTED_CPUID and then sets them later. So guest's X86_FEATURE_XSAVE should be masked out on hosts without X86_FEATURE_XSAVE, making kvm_set_cr4 with X86_CR4_OSXSAVE fail. Userspaces that allow specifying guest cpuid with X86_FEATURE_XSAVE even on hosts that do not support it, might be susceptible to this attack from inside the guest as well.
Allow setting X86_CR4_OSXSAVE bit only if host has XSAVE support.
---
arch/x86/kvm/x86.c +6 -0
@@ -578,6 +578,9 @@ static bool guest_cpuid_has_xsave(struct {struct kvm_cpuid_entry2 *best; +if (!static_cpu_has (X86_FEATURE_XSAVE )) +return 0 ; + best =kvm_find_cpuid_entry (vcpu,1 ,0 );return best && (best->ecx &bit (X86_FEATURE_XSAVE )); }
@@ -6149,6 +6152,9 @@ int kvm_arch_vcpu_ioctl_set_sregs(structint pending_vec, max_bits, idx;struct desc_ptr dt; +if (!guest_cpuid_has_xsave (vcpu) && (sregs->cr4 &X86_CR4_OSXSAVE )) +return -EINVAL ; + dt.size = sregs->idt.limit; dt.address = sregs->idt.base; kvm_x86_ops->set_idt (vcpu, &dt);
PATCH 4/173 HID: hid-magicmouse: Add pointer and buttonpad properties for Magic Trackpad
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chase Douglas <[email protected]>
commit 503f7d53b368c8e4e13a7756220c0536fcf1a034 upstream.
--- drivers/hid/hid-magicmouse.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/hid/hid-magicmouse.c +2 -0
@@ -418,6 +418,8 @@ static void magicmouse_setup_input(struct input_dev *input, struct hid_device *h__set_bit (BTN_TOOL_TRIPLETAP , input->keybit);__set_bit (BTN_TOOL_QUADTAP , input->keybit);__set_bit (BTN_TOUCH , input->keybit); +__set_bit (INPUT_PROP_POINTER , input->propbit); +__set_bit (INPUT_PROP_BUTTONPAD , input->propbit); }if (report_touches) {
PATCH 5/173 ALSA: hda - Add Lynx Point HD Audio Controller DeviceIDs
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Seth Heasley <[email protected]>
commit 8bc039a1e15a72da8426b84293723fb7181f0b5e upstream.
This patch adds the HD Audio DeviceIDs for the Intel Lynx Point PCH.
--- sound/pci/hda/hda_intel.c | 5 +++++ 1 file changed, 5 insertions(+)
sound/pci/hda/hda_intel.c +5 -0
@@ -148,6 +148,7 @@ MODULE_SUPPORTED_DEVICE("{{Intel, ICH6},""{Intel, PCH}," "{Intel, CPT}," "{Intel, PPT}," +"{Intel, LPT}," "{Intel, PBG}," "{Intel, SCH}," "{ATI, SB450},"
@@ -3001,6 +3002,10 @@ static DEFINE_PCI_DEVICE_TABLE(azx_ids) = { { PCI_DEVICE(0x8086, 0x1e20), .driver_data =AZX_DRIVER_PCH |AZX_DCAPS_SCH_SNOOP | AZX_DCAPS_BUFSIZE}, + /* Lynx Point */ + { PCI_DEVICE(0x8086, 0x8c20), + .driver_data =AZX_DRIVER_PCH |AZX_DCAPS_SCH_SNOOP | + AZX_DCAPS_BUFSIZE}, /* SCH */ { PCI_DEVICE(0x8086, 0x811b), .driver_data = AZX_DRIVER_SCH | AZX_DCAPS_SCH_SNOOP |
PATCH 6/173 drm: give up on edid retries when i2c bus is not responding
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eugeni Dodonov <[email protected]>
commit 9292f37e1f5c79400254dca46f83313488093825 upstream.
This allows to avoid talking to a non-responding bus repeatedly until we finally timeout after 15 attempts. We can do this by catching the -ENXIO error, provided by i2c_algo_bit:bit_doAddress call.
Within the bit_doAddress we already try 3 times to get the edid data, so if the routine tells us that bus is not responding, it is mostly pointless to keep re-trying those attempts over and over again until we reach final number of retries.
This change should fix https://bugs.freedesktop.org/show_bug.cgi?id=41059
and improve overall edid detection timing by 10-30% in most cases, and by a much larger margin in case of phantom outputs (up to 30x in one worst case).
Timing results for i915-powered machines for 'time xrandr' command:
Machine 1: from 0.840s to 0.290s
Machine 2: from 0.315s to 0.280s
Machine 3: from +/- 4s to 0.184s
Timing results for HD5770 with 'time xrandr' command:
Machine 4: from 3.210s to 1.060s
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41059
--- drivers/gpu/drm/drm_edid.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/gpu/drm/drm_edid.c +5 -0
@@ -266,6 +266,11 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, unsigned char *buf, } }; ret =i2c_transfer (adapter, msgs,2 ); +if (ret == -ENXIO ) { +DRM_DEBUG_KMS ("drm: skipping non-existent adapter %s\n" , + adapter->name); +break ; + } }while (ret !=2 && --retries);return ret ==2 ?0 :-1 ;
PATCH 7/173 ALSA: hda - add id for Atom Cedar Trail HDMI codec
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wu Fengguang <[email protected]>
commit 6edc59e602b36cd3c95a426ef6e8cad0344af8c7 upstream.
[the order sorted by tiwai]
--- sound/pci/hda/patch_hdmi.c | 2 ++ 1 file changed, 2 insertions(+)
sound/pci/hda/patch_hdmi.c +2 -0
@@ -1912,6 +1912,7 @@ static const struct hda_codec_preset snd_hda_preset_hdmi[] = { { .id = 0x80862804, .name = "IbexPeak HDMI", .patch = patch_generic_hdmi }, { .id = 0x80862805, .name = "CougarPoint HDMI", .patch = patch_generic_hdmi }, { .id = 0x80862806, .name = "PantherPoint HDMI", .patch = patch_generic_hdmi }, +{ .id = 0x80862880, .name = "CedarTrail HDMI", .patch = patch_generic_hdmi }, { .id = 0x808629fb, .name = "Crestline HDMI", .patch = patch_generic_hdmi }, {}/* terminator */ };
@@ -1958,6 +1959,7 @@ MODULE_ALIAS("snd-hda-codec-id:80862803");MODULE_ALIAS ("snd-hda-codec-id:80862804" );MODULE_ALIAS ("snd-hda-codec-id:80862805" );MODULE_ALIAS ("snd-hda-codec-id:80862806" ); +MODULE_ALIAS ("snd-hda-codec-id:80862880" );MODULE_ALIAS ("snd-hda-codec-id:808629fb" );MODULE_LICENSE ("GPL" );
PATCH 8/173 i915: Quirk no_lvds on Gigabyte GA-D525TUD ITX motherboard
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Calvin Walton <[email protected]>
commit a51d4ed01e5bb39d2cf36a12f9976ab08872c192 upstream.
This board is incorrectly detected as having an LVDS connector, resulting in the VGA output (the only available output on the board) showing the console only in the top-left 1024x768 pixels, and an extra LVDS connector appearing in X.
It's a desktop Mini-ITX board using an Atom D525 CPU with an NM10 chipset.
I've had this board for about a year, but this is the first time I noticed the issue because I've been running it headless for most of its life.
--- drivers/gpu/drm/i915/intel_lvds.c | 8 ++++++++ 1 file changed, 8 insertions(+)
drivers/gpu/drm/i915/intel_lvds.c +8 -0
@@ -780,6 +780,14 @@ static const struct dmi_system_id intel_no_lvds[] = { DMI_MATCH(DMI_BOARD_NAME, "ZBOXSD-ID12/ID13"), }, }, + { + .callback = intel_no_lvds_dmi_callback, + .ident = "Gigabyte GA-D525TUD", + .matches = { + DMI_MATCH(DMI_BOARD_VENDOR, "Gigabyte Technology Co., Ltd."), + DMI_MATCH(DMI_BOARD_NAME, "D525TUD"), + }, + }, { }/* terminating entry */ };
PATCH 9/173 drm/i915: Add no-lvds quirk for Supermicro X7SPA-H
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chris Wilson <[email protected]>
commit c31407a3672aaebb4acddf90944a114fa5c8af7b upstream.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55375
--- drivers/gpu/drm/i915/intel_lvds.c | 8 ++++++++ 1 file changed, 8 insertions(+)
drivers/gpu/drm/i915/intel_lvds.c +8 -0
@@ -778,6 +778,14 @@ static const struct dmi_system_id intel_no_lvds[] = { DMI_MATCH(DMI_BOARD_NAME, "D525TUD"), }, }, + { + .callback = intel_no_lvds_dmi_callback, + .ident = "Supermicro X7SPA-H", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Supermicro"), + DMI_MATCH(DMI_PRODUCT_NAME, "X7SPA-H"), + }, + }, { }/* terminating entry */ };
PATCH 10/173 ACPI: missing break
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alan Cox <[email protected]>
commit 879dca019dc43a1622edca3e7dde644b14b5acc5 upstream.
We handle NOTIFY_THROTTLING so don't then fall through to unsupported event.
--- drivers/acpi/processor_driver.c | 1 + 1 file changed, 1 insertion(+)
drivers/acpi/processor_driver.c +1 -0
@@ -409,6 +409,7 @@ static void acpi_processor_notify(struct acpi_device *device, u32 event)acpi_bus_generate_proc_event (device, event,0 );acpi_bus_generate_netlink_event (device->pnp.device_class,dev_name (&device->dev), event,0 ); +break ;default :ACPI_DEBUG_PRINT ((ACPI_DB_INFO ,"Unsupported event [0x%x]\n" , event));
PATCH 11/173 workqueue: convert BUG_ON()s in __queue_delayed_work() to WARN_ON_ONCE()s
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tejun Heo <[email protected]>
commit fc4b514f2727f74a4587c31db87e0e93465518c3 upstream.
8852aac25e ("workqueue: mod_delayed_work_on() shouldn't queue timer on 0 delay") unexpectedly uncovered a very nasty abuse of delayed_work in megaraid - it allocated work_struct, casted it to delayed_work and then pass that into queue_delayed_work().
Previously, this was okay because 0 @delay short-circuited to queue_work() before doing anything with delayed_work. 8852aac25e moved 0 @delay test into __queue_delayed_work() after sanity check on delayed_work making megaraid trigger BUG_ON().
Although megaraid is already fixed by c1d390d8e6 ("megaraid: fix BUG_ON() from incorrect use of delayed work"), this patch converts BUG_ON()s in __queue_delayed_work() to WARN_ON_ONCE()s so that such abusers, if there are more, trigger warning but don't crash the machine.
[Shuah Khan: This change is back-ported from upstream change that
converted BUG_ON()s in __queue_delayed_work() to WARN_ON_ONCE()s.]
Tested on Stable Trees: 3.0.x, 3.4.x, 3.6.x
--- kernel/workqueue.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
kernel/workqueue.c +2 -2
@@ -1146,8 +1146,8 @@ int queue_delayed_work_on(int cpu, strucif (!test_and_set_bit (WORK_STRUCT_PENDING_BIT ,work_data_bits (work))) {unsigned int lcpu; -BUG_ON (timer_pending (timer)); -BUG_ON (!list_empty (&work->entry)); +WARN_ON_ONCE (timer_pending (timer)); +WARN_ON_ONCE (!list_empty (&work->entry));timer_stats_timer_set_start_info (&dwork->timer);
PATCH 12/173 hwmon: (coretemp) Improve support of recent Atom CPU models
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jean Delvare <[email protected]>
commit fcc14ac1a86931f38da047cf8fb634c6db7b58bc upstream.
Document the new Atom series (Tunnel Creek and Medfield) as being supported, and list TjMax for the Atom E600 series.
Also enable the Atom tjmax heuristic for these Atom CPU models.
--- Documentation/hwmon/coretemp | 8 +++++++- drivers/hwmon/coretemp.c | 3 ++- 2 files changed, 9 insertions(+), 2 deletions(-)
Documentation/hwmon/coretemp +7 -1
@@ -6,7 +6,8 @@ Supported chips: Prefix: 'coretemp' CPUID: family 0x6, models 0xe (Pentium M DC), 0xf (Core 2 DC 65nm), 0x16 (Core 2 SC 65nm), 0x17 (Penryn 45nm), - 0x1a (Nehalem), 0x1c (Atom), 0x1e (Lynnfield) + 0x1a (Nehalem), 0x1c (Atom), 0x1e (Lynnfield), + 0x26 (Tunnel Creek Atom), 0x27 (Medfield Atom) Datasheet: Intel 64 and IA-32 Architectures Software Developer's Manual Volume 3A: System Programming Guide http://softwarecommunity.intel.com/Wiki/Mobility/720.htm
@@ -65,6 +66,9 @@ Process Processor TjMax(C) U3400 105 P4505/P4500 90 +32nm Atom Processors + Z2460 90 + 45nm Xeon Processors 5400 Quad-Core X5492, X5482, X5472, X5470, X5460, X5450 85 E5472, E5462, E5450/40/30/20/10/05 85
@@ -85,6 +89,8 @@ Process Processor TjMax(C) N475/470/455/450 100 N280/270 90 330/230 125 + E680/660/640/620 90 + E680T/660T/640T/620T 110 45nm Core2 Processors Solo ULV SU3500/3300 100
drivers/hwmon/coretemp.c +2 -1
@@ -210,7 +210,8 @@ static int __cpuinit adjust_tjmax(struct cpuinfo_x86 *c, u32 id,/* Atom CPUs */ -if (c->x86_model ==0x1c ) { +if (c->x86_model ==0x1c || c->x86_model ==0x26 + || c->x86_model ==0x27 ) { usemsr_ee =0 ; host_bridge =pci_get_bus_and_slot (0 ,PCI_DEVFN (0 ,0 ));
PATCH 13/173 hwmon: (coretemp) Add support for Atom D2000 and N2000 series CPU models
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Guenter Roeck <[email protected]>
commit 5592906f8b01282ea3c2acaf641fd067ad4bb3dc upstream.
Document the Atom series D2000 and N2000 (Cedar Trail) as being supported. List and set TjMax for those series.
--- Documentation/hwmon/coretemp | 5 ++++- drivers/hwmon/coretemp.c | 3 +++ 2 files changed, 7 insertions(+), 1 deletion(-)
Documentation/hwmon/coretemp +4 -1
@@ -7,7 +7,8 @@ Supported chips: CPUID: family 0x6, models 0xe (Pentium M DC), 0xf (Core 2 DC 65nm), 0x16 (Core 2 SC 65nm), 0x17 (Penryn 45nm), 0x1a (Nehalem), 0x1c (Atom), 0x1e (Lynnfield), - 0x26 (Tunnel Creek Atom), 0x27 (Medfield Atom) + 0x26 (Tunnel Creek Atom), 0x27 (Medfield Atom), + 0x36 (Cedar Trail Atom) Datasheet: Intel 64 and IA-32 Architectures Software Developer's Manual Volume 3A: System Programming Guide http://softwarecommunity.intel.com/Wiki/Mobility/720.htm
@@ -68,6 +69,8 @@ Process Processor TjMax(C) 32nm Atom Processors Z2460 90 + D2700/2550/2500 100 + N2850/2800/2650/2600 100 45nm Xeon Processors 5400 Quad-Core X5492, X5482, X5472, X5470, X5460, X5450 85
drivers/hwmon/coretemp.c +3 -0
@@ -224,6 +224,9 @@ static int __cpuinit adjust_tjmax(struct cpuinfo_x86 *c, u32 id, tjmax =90000 ;pci_dev_put (host_bridge); + }else if (c->x86_model ==0x36 ) { + usemsr_ee =0 ; + tjmax =100000 ; }if (c->x86_model >0xe && usemsr_ee) {
PATCH 14/173 hwmon: (coretemp) Improve support for TjMax detection on Atom CPUs
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Guenter Roeck <[email protected]>
commit 41e58a1f2b90c88d94b4bd84beb9927a4c2704e9 upstream.
Atom CPUs don't have a register to retrieve TjMax. Detection so far was incomplete. Use the X86 model ID to improve it.
--- drivers/hwmon/coretemp.c | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+)
drivers/hwmon/coretemp.c +25 -0
@@ -190,6 +190,24 @@ static ssize_t show_temp(struct device *return tdata->valid ?sprintf (buf,"%d\n" , tdata->temp) : -EAGAIN ; } +struct tjmax { +char const *id; +int tjmax; +}; + +static struct tjmax __cpuinitconst tjmax_table[] = { + {"CPU D410" ,100000 }, + {"CPU D425" ,100000 }, + {"CPU D510" ,100000 }, + {"CPU D525" ,100000 }, + {"CPU N450" ,100000 }, + {"CPU N455" ,100000 }, + {"CPU N470" ,100000 }, + {"CPU N475" ,100000 }, + {"CPU 230" ,100000 }, + {"CPU 330" ,125000 }, +}; +static int adjust_tjmax (struct cpuinfo_x86 *c,u32 id,struct device *dev) {/* The 100C is default for both mobile and non mobile CPUs */
@@ -200,6 +218,13 @@ static int adjust_tjmax(struct cpuinfo_xint err;u32 eax, edx;struct pci_dev *host_bridge; +int i; + +/* explicit tjmax table entries override heuristics */ +for (i =0 ; i <ARRAY_SIZE (tjmax_table); i++) { +if (strstr (c->x86_model_id, tjmax_table[i].id)) +return tjmax_table[i].tjmax; + }/* Early chips have no MSR for TjMax */
PATCH 15/173 hwmon: (coretemp) Add support for Atom CE4110/4150/4170
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Guenter Roeck <[email protected]>
commit 1102dcab849313bd5a340b299b5cf61b518fbc0f upstream.
TjMax for the CE4100 series of Atom CPUs was previously reported to be 110 degrees C.
cpuinfo logs on the web show existing CPU types CE4110, CE4150, and CE4170, reported as "model name : Intel(R) Atom(TM) CPU CE41{1|5|7}0 @ 1.{2|6}0GHz" with model 28 (0x1c) and stepping 10 (0x0a). Add the three known variants to the tjmax table.
--- Documentation/hwmon/coretemp | 1 + drivers/hwmon/coretemp.c | 7 +++++-- 2 files changed, 6 insertions(+), 2 deletions(-)
Documentation/hwmon/coretemp +1 -0
@@ -94,6 +94,7 @@ Process Processor TjMax(C) 330/230 125 E680/660/640/620 90 E680T/660T/640T/620T 110 + CE4170/4150/4110 110 45nm Core2 Processors Solo ULV SU3500/3300 100
drivers/hwmon/coretemp.c +5 -2
@@ -204,8 +204,11 @@ static struct tjmax __cpuinitconst tjmax { "CPU N455", 100000 }, { "CPU N470", 100000 }, { "CPU N475", 100000 }, - { "CPU 230", 100000 }, - { "CPU 330", 125000 }, + { "CPU 230", 100000 }, /* Model 0x1c, stepping 2 */ + { "CPU 330", 125000 }, /* Model 0x1c, stepping 2 */ + { "CPU CE4110", 110000 }, /* Model 0x1c, stepping 10 */ + { "CPU CE4150", 110000 }, /* Model 0x1c, stepping 10 */ + { "CPU CE4170", 110000 }, /* Model 0x1c, stepping 10 */ };static int adjust_tjmax (struct cpuinfo_x86 *c,u32 id,struct device *dev)
PATCH 16/173 use clamp_t in UNAME26 fix
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kees Cook <[email protected]>
commit 31fd84b95eb211d5db460a1dda85e004800a7b52 upstream.
The min/max call needed to have explicit types on some architectures (e.g. mn10300). Use clamp_t instead to avoid the warning:
kernel/sys.c: In function 'override_release':
kernel/sys.c:1287:10: warning: comparison of distinct pointer types lacks a cast [enabled by default]
--- kernel/sys.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/sys.c +1 -1
@@ -1284,7 +1284,7 @@ static int override_release(char __user *release, size_t len) rest++; } v = ((LINUX_VERSION_CODE >>8 ) &0xff ) +40 ; - copy =min (sizeof (buf),max_t (size_t,1 , len)); + copy =clamp_t (size_t, len,1 ,sizeof (buf)); copy =scnprintf (buf, copy,"2.6.%u%s" , v, rest); ret =copy_to_user (release, buf, copy +1 ); }
Re: [ 016/173] use clamp_t in UNAME26 fix
Quoted 7 lines · Ben Hutchings
The min/max call needed to have explicit types on some architectures (e.g. mn10300). Use
clamp_tinstead to avoid the warning:
kernel/sys.c: In function 'override_release':
kernel/sys.c:1287:10: warning: comparison of distinct pointer types lacks a cast [enabled by default]Reported-by Fengguang Wu <[email protected]>
[...]
kernel/sys.c static int override_release(char __user *release, size_t len) · line 1287
Quoted 1 line
kernel/sys.c +0
-1- copy =min (sizeof (buf),max_t (size_t,1 , len));
I don't understand how this happens given that v2.6.36-rc1~68 (MN10300: Fix size_t and ssize_t, 2010-08-12) was supposed to fix this kind of thing. Doesn't sizeof(buf) have type size_t already (C99 §6.5.3.4 "the sizeof operator" ¶4)?
What version of gcc produces this warning?
Puzzled,
Jonathan
Re: [ 016/173] use clamp_t in UNAME26 fix
Quoted 8 lines · Jonathan Nieder
Quoted 6 lines · Ben Hutchings
The min/max call needed to have explicit types on some architectures (e.g. mn10300). Use
clamp_tinstead to avoid the warning:
kernel/sys.c: In function 'override_release':
kernel/sys.c:1287:10: warning: comparison of distinct pointer types lacks a cast [enabled by default]
Quoted 7 lines
Quoted 1 line
Reported-by Fengguang Wu <[email protected]>[...]
kernel/sys.c static int override_release(char __user *release, size_t len) · line 1287
Quoted 1 line
kernel/sys.c +0
-1- copy =min (sizeof (buf),max_t (size_t,1 , len));I don't understand how this happens given that v2.6.36-rc1~68 (MN10300: Fix
size_tandssize_t, 2010-08-12) was supposed to fix this kind of thing.
[...]
Neither do I, but I'm including it now just to be consistent with other stable series.
Ben.
Signature · 2 lines
Ben Hutchings It is easier to change the specification to fit the program than vice versa.
Re: [ 016/173] use clamp_t in UNAME26 fix
Quoted 16 lines · Ben Hutchings
Quoted 8 lines · Jonathan Nieder
Quoted 6 lines · Ben Hutchings
The min/max call needed to have explicit types on some architectures (e.g. mn10300). Use
clamp_tinstead to avoid the warning:
kernel/sys.c: In function 'override_release':
kernel/sys.c:1287:10: warning: comparison of distinct pointer types lacks a cast [enabled by default]Quoted 7 lines
Quoted 1 line
Reported-by Fengguang Wu <[email protected]>[...]
kernel/sys.c static int override_release(char __user *release, size_t len) · line 1287
Quoted 1 line
kernel/sys.c +0
-1- copy =min (sizeof (buf),max_t (size_t,1 , len));I don't understand how this happens given that v2.6.36-rc1~68 (MN10300: Fix
size_tandssize_t, 2010-08-12) was supposed to fix this kind of thing.
Quoted 4 lines
[...]
Neither do I, but I'm including it now just to be consistent with other stable series.
Thanks for explaining. That makes sense and the patch is harmless, so why not.
The patch still leaves me worried that there might be more problems lurking on mn10300, but that's more of a question for upstream.
PATCH 17/173 ARM: 7566/1: vfp: fix save and restore when running on pre-VFPv3 and CONFIG_VFPv3 set
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paul Walmsley <[email protected]>
commit 39141ddfb63a664f26d3f42f64ee386e879b492c upstream.
After commit 846a136881b8f73c1f74250bf6acfaa309cab1f2 ("ARM: vfp: fix saving d16-d31 vfp registers on v6+ kernels"), the OMAP 2430SDP board started crashing during boot with omap2plus_defconfig:
[ 3.875122] mmcblk0: mmc0:e624 SD04G 3.69 GiB [ 3.915954] mmcblk0: p1 [ 4.086639] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM [ 4.093719] Modules linked in: [ 4.096954] CPU: 0 Not tainted (3.6.0-02232-g759e00b #570) [ 4.103149] PC is at vfp_reload_hw+0x1c/0x44 [ 4.107666] LR is at __und_usr_fault_32+0x0/0x8
It turns out that the context save/restore fix unmasked a latent bug in commit 5aaf254409f8d58229107b59507a8235b715a960 ("ARM: 6203/1: Make VFPv3 usable on ARMv6"). When CONFIG_VFPv3 is set, but the kernel is booted on a pre-VFPv3 core, the code attempts to save and restore the d16-d31 VFP registers. These are only present on non-D16 VFPv3+, so this results in an undefined instruction exception. The code didn't crash before commit 846a136 because the save and restore code was only touching d0-d15, present on all VFP.
Fix by implementing a request from Russell King to add a new HWCAP flag that affirmatively indicates the presence of the d16-d31 registers:
http://marc.info/?l=linux-arm-kernel&m=135013547905283&w=2
and some feedback from Måns to clarify the name of the HWCAP flag.
---
arch/arm/include/asm/vfpmacros.h +6 -6
@@ -27,9 +27,9 @@#if __LINUX_ARM_ARCH__ <=6 ldr \tmp, =elf_hwcap @ may not have MVFR regs ldr \tmp, [\tmp, #0] - tst \tmp, #HWCAP_VFPv3D16 - ldceql p11, cr0, [\base],#32*4 @ FLDMIAD \base!, {d16-d31} - addne \base, \base, #32*4 @ step over unused register space + tst \tmp, #HWCAP_VFPD32 + ldcnel p11, cr0, [\base],#32*4 @ FLDMIAD \base!, {d16-d31} + addeq \base, \base, #32*4 @ step over unused register space#else VFPFMRX \tmp, MVFR0 @ Media and VFP Feature Register 0 and \tmp, \tmp, #MVFR0_A_SIMD_MASK @ A_SIMD field
@@ -51,9 +51,9 @@#if __LINUX_ARM_ARCH__ <=6 ldr \tmp, =elf_hwcap @ may not have MVFR regs ldr \tmp, [\tmp, #0] - tst \tmp, #HWCAP_VFPv3D16 - stceql p11, cr0, [\base],#32*4 @ FSTMIAD \base!, {d16-d31} - addne \base, \base, #32*4 @ step over unused register space + tst \tmp, #HWCAP_VFPD32 + stcnel p11, cr0, [\base],#32*4 @ FSTMIAD \base!, {d16-d31} + addeq \base, \base, #32*4 @ step over unused register space#else VFPFMRX \tmp, MVFR0 @ Media and VFP Feature Register 0 and \tmp, \tmp, #MVFR0_A_SIMD_MASK @ A_SIMD field
arch/arm/include/asm/hwcap.h +2 -1
@@ -18,11 +18,12 @@#define HWCAP_THUMBEE (1 << 11)#define HWCAP_NEON (1 << 12)#define HWCAP_VFPv3 (1 << 13) -#define HWCAP_VFPv3D16 (1 << 14) +#define HWCAP_VFPv3D16 (1 << 14)/* also set for VFPv4-D16 */ #define HWCAP_TLS (1 << 15)#define HWCAP_VFPv4 (1 << 16)#define HWCAP_IDIVA (1 << 17)#define HWCAP_IDIVT (1 << 18) +#define HWCAP_VFPD32 (1 << 19)/* set if VFP has 32 regs (not 16) */ #define HWCAP_IDIV (HWCAP_IDIVA | HWCAP_IDIVT)#if defined(__KERNEL__) && !defined(__ASSEMBLY__)
arch/arm/vfp/vfpmodule.c +6 -3
@@ -610,11 +610,14 @@ static int __init vfp_init(void) elf_hwcap |= HWCAP_VFPv3;/* -* Check for VFPv3 D16. CPUs in this configuration -* only have 16 x 64bit registers. +* Check for VFPv3 D16 and VFPv4 D16. CPUs in +* this configuration only have 16 x 64bit +* registers. */ if (((fmrx (MVFR0 ) &MVFR0_A_SIMD_MASK )) ==1 ) - elf_hwcap |= HWCAP_VFPv3D16; + elf_hwcap |= HWCAP_VFPv3D16;/* also v4-D16 */ +else + elf_hwcap |= HWCAP_VFPD32; }#endif /*
PATCH 18/173 sata_svw: check DMA start bit before reset
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Milburn <[email protected]>
commit b03e66a6be91f8389fcd902ab6c1563db1c9c06b upstream.
If kdump is triggered with pending IO, controller may not respond causing kdump to fail.
http://marc.info/?l=linux-ide&m=133032255424658&w=2
During error recovery ata_do_dev_read_id never completes due hang in mmio_insw.
ata_do_dev_read_id
ata_sff_data_xfer
ioread16_rep
mmio_insw
if DMA start bit is cleared before reset, PIO command is successful and kdump succeeds.
--- drivers/ata/sata_svw.c | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+)
drivers/ata/sata_svw.c +35 -0
@@ -142,6 +142,39 @@ static int k2_sata_scr_write(struct ata_link *link,return 0 ; } +static int k2_sata_softreset (struct ata_link *link, +unsigned int *class,unsigned long deadline) +{ +u8 dmactl; +void __iomem *mmio = link->ap->ioaddr.bmdma_addr; + + dmactl =readb (mmio +ATA_DMA_CMD ); + +/* Clear the start bit */ +if (dmactl &ATA_DMA_START ) { + dmactl &= ~ATA_DMA_START ; +writeb (dmactl, mmio +ATA_DMA_CMD ); + } + +return ata_sff_softreset (link, class, deadline); +} + +static int k2_sata_hardreset (struct ata_link *link, +unsigned int *class,unsigned long deadline) +{ +u8 dmactl; +void __iomem *mmio = link->ap->ioaddr.bmdma_addr; + + dmactl =readb (mmio +ATA_DMA_CMD ); + +/* Clear the start bit */ +if (dmactl &ATA_DMA_START ) { + dmactl &= ~ATA_DMA_START ; +writeb (dmactl, mmio +ATA_DMA_CMD ); + } + +return sata_sff_hardreset (link, class, deadline); +}static void k2_sata_tf_load (struct ata_port *ap,const struct ata_taskfile *tf) {
@@ -346,6 +379,8 @@ static struct scsi_host_template k2_sata_sht = {static struct ata_port_operations k2_sata_ops = { .inherits = &ata_bmdma_port_ops, + .softreset = k2_sata_softreset, + .hardreset = k2_sata_hardreset, .sff_tf_load = k2_sata_tf_load, .sff_tf_read = k2_sata_tf_read, .sff_check_status = k2_stat_check_status,
PATCH 19/173 drivers/leds/leds-lp5521.c: fix typo
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Masanari Iida <[email protected]>
commit 3a2fd4a14112452eb5c1a079ac8b3f4842762afe upstream.
"reseting" -> "resetting"
--- drivers/leds/leds-lp5521.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/leds/leds-lp5521.c +1 -1
@@ -694,7 +694,7 @@ static int __devinit lp5521_probe(struct i2c_client *client,*/ lp5521_read (client,LP5521_REG_R_CURRENT , &buf);if (buf !=LP5521_REG_R_CURR_DEFAULT ) { -dev_err (&client->dev,"error in reseting chip\n" ); +dev_err (&client->dev,"error in resetting chip\n" ); goto fail2; }usleep_range (10000 ,20000 );
PATCH 20/173 drivers/leds/leds-lp5521.c: ret may be uninitialized
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Srinidhi KASAGAR <[email protected]>
commit 42960b76d2c6a44d7e8000f4eb9a4ca1780059ff upstream.
Fix it by assigning the lp5521_read return value.
--- drivers/leds/leds-lp5521.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/leds/leds-lp5521.c +1 -1
@@ -784,7 +784,7 @@ static int __devinit lp5521_probe(struct i2c_client *client,* otherwise further access to the R G B channels in the * LP5521_REG_ENABLE register will not have any effect - strange! */ -lp5521_read (client,LP5521_REG_R_CURRENT , &buf); + ret =lp5521_read (client,LP5521_REG_R_CURRENT , &buf);if (buf !=LP5521_REG_R_CURR_DEFAULT ) {dev_err (&client->dev,"error in resetting chip\n" ); goto fail2;
PATCH 21/173 drivers/leds/leds-lp5521.c: fix lp5521_read() error handling
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <[email protected]>
commit 5bc9ad774c063f6b41965e7314f2c26aa5e465a0 upstream.
Gcc 4.6.2 complains that:
drivers/leds/leds-lp5521.c: In function `lp5521_load_program':
drivers/leds/leds-lp5521.c:214:21: warning: mode' may be used uninitialized in this function [-Wuninitialized] drivers/leds/leds-lp5521.c: In function lp5521_probe':
drivers/leds/leds-lp5521.c:788:5: warning: buf' may be used uninitialized in this function [-Wuninitialized] drivers/leds/leds-lp5521.c:740:6: warning: ret' may be used uninitialized in this function [-Wuninitialized]
These are real problems if lp5521_read() returns an error. When that happens we should handle it, instead of ignoring it or doing a bitwise OR with all the other error codes and continuing.
--- drivers/leds/leds-lp5521.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-)
drivers/leds/leds-lp5521.c +8 -4
@@ -193,9 +193,14 @@ static int lp5521_load_program(struct lp5521_engine *eng, const u8 *pattern)/* move current engine to direct mode and remember the state */ ret =lp5521_set_engine_mode (eng,LP5521_CMD_DIRECT ); +if (ret) +return ret; +/* Mode change requires min 500 us delay. 1 - 2 ms with margin */ usleep_range (1000 ,2000 ); - ret |=lp5521_read (client,LP5521_REG_OP_MODE , &mode); + ret =lp5521_read (client,LP5521_REG_OP_MODE , &mode); +if (ret) +return ret;/* For loading, all the engines to load mode */ lp5521_write (client,LP5521_REG_OP_MODE ,LP5521_CMD_DIRECT );
@@ -211,8 +216,7 @@ static int lp5521_load_program(struct lp5521_engine *eng, const u8 *pattern)LP5521_PROG_MEM_SIZE , pattern); - ret |=lp5521_write (client,LP5521_REG_OP_MODE , mode); -return ret; +return lp5521_write (client,LP5521_REG_OP_MODE , mode); }static int lp5521_set_led_current (struct lp5521_chip *chip,int led,u8 curr)
@@ -785,7 +789,7 @@ static int __devinit lp5521_probe(struct i2c_client *client,* LP5521_REG_ENABLE register will not have any effect - strange! */ ret =lp5521_read (client,LP5521_REG_R_CURRENT , &buf); -if (buf !=LP5521_REG_R_CURR_DEFAULT ) { +if (ret || buf !=LP5521_REG_R_CURR_DEFAULT ) {dev_err (&client->dev,"error in resetting chip\n" ); goto fail2; }
PATCH 22/173 scsi: aha152x: Fix sparse warning and make printing pointer address more portable.
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Krzysztof Wilczynski <[email protected]>
commit b631cf1f899f9d2e449884dbccc34940637c639f upstream.
This is to change use of "0x%08x" in favour of "%p" as per ../Documentation/printk-formats.txt, which also takes care about the following warning during compilation time:
drivers/scsi/aha152x.c: In function ‘get_command’:
drivers/scsi/aha152x.c:2987: warning: cast from pointer to integer of different size
--- drivers/scsi/aha152x.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/scsi/aha152x.c +2 -2
@@ -2984,8 +2984,8 @@ static int get_command(char *pos, Scsi_Cmnd * ptr)char *start = pos;int i; -SPRINTF ("0x%08x: target=%d; lun=%d; cmnd=( " , - (unsigned int ) ptr, ptr->device->id, ptr->device->lun); +SPRINTF ("%p: target=%d; lun=%d; cmnd=( " , + ptr, ptr->device->id, ptr->device->lun);for (i =0 ; i <COMMAND_SIZE (ptr->cmnd[0 ]); i++)SPRINTF ("0x%02x " , ptr->cmnd[i]);
PATCH 23/173 ALSA: hda - Fix missing beep on ASUS X43U notebook
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Duncan Roe <[email protected]>
commit 7110005e8d5c3cd418fc4b64f9f124f004422a9a upstream.
--- sound/pci/hda/patch_realtek.c | 1 + 1 file changed, 1 insertion(+)
sound/pci/hda/patch_realtek.c +1 -0
@@ -4245,6 +4245,7 @@ static void alc_auto_init_std(struct hda_codec *codec) ((spec)->beep_amp = HDA_COMPOSE_AMP_VAL(nid, 3, idx, dir))static const struct snd_pci_quirk beep_white_list[] = { +SND_PCI_QUIRK (0x1043 ,0x103c ,"ASUS" ,1 ),SND_PCI_QUIRK (0x1043 ,0x829f ,"ASUS" ,1 ),SND_PCI_QUIRK (0x1043 ,0x83ce ,"EeePC" ,1 ),SND_PCI_QUIRK (0x1043 ,0x831a ,"EeePC" ,1 ),
PATCH 24/173 drm/i915: add Ivy Bridge GT2 Server entries
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eugeni Dodonov <[email protected]>
commit cc22a938fc1db0c8ef5e693a69b159c4b851dab3 upstream.
This adds PCI ID for IVB GT2 server variant which we were missing.
--- drivers/char/agp/intel-agp.h | 1 + drivers/char/agp/intel-gtt.c | 2 ++ drivers/gpu/drm/i915/i915_drv.c | 1 + 3 files changed, 4 insertions(+)
drivers/char/agp/intel-agp.h +1 -0
@@ -234,6 +234,7 @@#define PCI_DEVICE_ID_INTEL_IVYBRIDGE_M_GT2_IG 0x0166#define PCI_DEVICE_ID_INTEL_IVYBRIDGE_S_HB 0x0158/* Server */ #define PCI_DEVICE_ID_INTEL_IVYBRIDGE_S_GT1_IG 0x015A +#define PCI_DEVICE_ID_INTEL_IVYBRIDGE_S_GT2_IG 0x016Aint intel_gmch_probe (struct pci_dev *pdev,struct agp_bridge_data *bridge);
drivers/char/agp/intel-gtt.c +2 -0
@@ -1459,6 +1459,8 @@ static const struct intel_gtt_driver_description { "Ivybridge", &sandybridge_gtt_driver }, {PCI_DEVICE_ID_INTEL_IVYBRIDGE_S_GT1_IG , "Ivybridge", &sandybridge_gtt_driver }, + { PCI_DEVICE_ID_INTEL_IVYBRIDGE_S_GT2_IG, + "Ivybridge", &sandybridge_gtt_driver }, { 0, NULL, NULL } };
drivers/gpu/drm/i915/i915_drv.c +1 -0
@@ -296,6 +296,7 @@ static const struct pci_device_id pciidlist[] = { /* aka */INTEL_VGA_DEVICE (0x0152 , &intel_ivybridge_d_info),/* GT1 desktop */ INTEL_VGA_DEVICE (0x0162 , &intel_ivybridge_d_info),/* GT2 desktop */ INTEL_VGA_DEVICE (0x015a , &intel_ivybridge_d_info),/* GT1 server */ +INTEL_VGA_DEVICE (0x016a , &intel_ivybridge_d_info),/* GT2 server */ {0, 0, 0} };
Re: [ 024/173] drm/i915: add Ivy Bridge GT2 Server entries
Quoted 1 line · Ben Hutchings
This adds PCI ID for IVB GT2 server variant which we were missing.
As discussed at [1], this triggers a small regression with Debian wheezy userspace (X freezing instead of erroring out). libdrm hasn't been updated in wheezy since then, and I wouldn't be surprised if other distros were affected, too. Has there been a kernel patch since then to avoid that?
Though I wouldn't mind seeing this applied anyway, FWIW, as long as the announcement mentions the userspace bugfix needed.
Thanks,
Jonathan
[1] http://thread.gmane.org/gmane.linux.debian.devel.bugs.general/978320/focus=74843
Re: [ 024/173] drm/i915: add Ivy Bridge GT2 Server entries
Quoted 10 lines · Jonathan Nieder
Quoted 1 line · Ben Hutchings
This adds PCI ID for IVB GT2 server variant which we were missing.
As discussed at [1], this triggers a small regression with Debian wheezy userspace (X freezing instead of erroring out). libdrm hasn't been updated in wheezy since then, and I wouldn't be surprised if other distros were affected, too. Has there been a kernel patch since then to avoid that?
Quoted 4 lines
Though I wouldn't mind seeing this applied anyway, FWIW, as long as the announcement mentions the userspace bugfix needed.
[1] http://thread.gmane.org/gmane.linux.debian.devel.bugs.general/978320/focus=74843
Sorry, forgot we'd discussed this before. Thinking over this again, I'm not convinced that X freezing at startup is a significant regression from X failing to start. Either way, it's unusable unless you explicitly configure it to use vesa.
Ben.
Signature · 2 lines
Ben Hutchings It is easier to change the specification to fit the program than vice versa.
PATCH 25/173 drm/i915: EBUSY status handling added to i915_gem_fault().
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dmitry Rogozhkin <[email protected]>
commit e79e0fe380847493266fba557217e2773c61bd1b upstream.
Subsequent threads returning EBUSY from vm_insert_pfn() was not handled correctly. As a result concurrent access from new threads to mmapped data caused SIGBUS.
Note that this fixes i-g-t/tests/gem_threaded_tiled_access.
--- drivers/gpu/drm/i915/i915_gem.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/gpu/drm/i915/i915_gem.c +5 -0
@@ -1400,6 +1400,11 @@ out:case 0 :case -ERESTARTSYS :case -EINTR : +case -EBUSY : +/* +* EBUSY is ok: this just means that another thread +* already did the job. +*/ return VM_FAULT_NOPAGE ;case -ENOMEM :return VM_FAULT_OOM ;
PATCH 26/173 i7300_edac: Fix error flag testing
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jean Delvare <[email protected]>
commit 7e06b7a3333f5c7a0cec12aff20d39c5c87c0795 upstream.
* Right-shift the values in GET_FBD_FAT_IDX and GET_FBD_NF_IDX, so that the callers get the result they expect.
* Fix definition of FERR_FAT_FBD_ERR_MASK.
* Call GET_FBD_NF_IDX, not GET_FBD_FAT_IDX, when operating on register FERR_NF_FBD. We were lucky they have the same definition.
This fixes kernel bug #44131:
https://bugzilla.kernel.org/show_bug.cgi?id=44131
--- drivers/edac/i7300_edac.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/edac/i7300_edac.c +4 -4
@@ -197,8 +197,8 @@ static const char *ferr_fat_fbd_name[] = { [0 ] ="Memory Write error on non-redundant retry or " "FBD configuration Write error on retry", }; -#define GET_FBD_FAT_IDX (fbderr) (fbderr & (3 << 28)) -#define FERR_FAT_FBD_ERR_MASK ((1 << 0) | (1 << 1) | (1 << 2) | (1 << 3)) +#define GET_FBD_FAT_IDX (fbderr) (((fbderr) >> 28) & 3) +#define FERR_FAT_FBD_ERR_MASK ((1 << 0) | (1 << 1) | (1 << 2) | (1 << 22))#define FERR_NF_FBD 0xa0static const char *ferr_nf_fbd_name[] = {
@@ -225,7 +225,7 @@ static const char *ferr_nf_fbd_name[] = { [1] = "Aliased Uncorrectable Non-Mirrored Demand Data ECC", [0] = "Uncorrectable Data ECC on Replay", }; -#define GET_FBD_NF_IDX (fbderr) (fbderr & (3 << 28)) +#define GET_FBD_NF_IDX (fbderr) (((fbderr) >> 28) & 3)#define FERR_NF_FBD_ERR_MASK ((1 << 24) | (1 << 23) | (1 << 22) | (1 << 21) |\ (1 << 18) | (1 << 17) | (1 << 16) | (1 << 15) |\ (1 << 14) | (1 << 13) | (1 << 11) | (1 << 10) |\
@@ -464,7 +464,7 @@ static void i7300_process_fbd_error(struct mem_ctl_info *mci) errnum =find_first_bit (&errors,ARRAY_SIZE (ferr_nf_fbd_name)); specific =GET_ERR_FROM_TABLE (ferr_nf_fbd_name, errnum); - branch = (GET_FBD_FAT_IDX (error_reg) ==2 ) ?1 :0 ; + branch = (GET_FBD_NF_IDX (error_reg) ==2 ) ?1 :0 ;pci_read_config_dword (pvt->pci_dev_16_1_fsb_addr_map,REDMEMA , &syndrome);
PATCH 27/173 Revert "sched, autogroup: Stop going ahead if autogroup is disabled"
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mike Galbraith <[email protected]>
commit fd8ef11730f1d03d5d6555aa53126e9e34f52f12 upstream.
This reverts commit 800d4d30c8f20bd728e5741a3b77c4859a613f7c.
Between commits 8323f26ce342 ("sched: Fix race in task_group()") and 800d4d30c8f2 ("sched, autogroup: Stop going ahead if autogroup is disabled"), autogroup is a wreck.
With both applied, all you have to do to crash a box is disable autogroup during boot up, then reboot.. boom, NULL pointer dereference due to commit 800d4d30c8f2 not allowing autogroup to move things, and commit 8323f26ce342 making that the only way to switch runqueues:
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [<ffffffff81063ac0>] effective_load.isra.43+0x50/0x90
Pid: 7047, comm: systemd-user-se Not tainted 3.6.8-smp #7 MEDIONPC MS-7502/MS-7502
RIP: effective_load.isra.43+0x50/0x90
Process systemd-user-se (pid: 7047, threadinfo ffff880221dde000, task ffff88022618b3a0)
Call Trace:
select_task_rq_fair+0x255/0x780
try_to_wake_up+0x156/0x2c0
wake_up_state+0xb/0x10
signal_wake_up+0x28/0x40
complete_signal+0x1d6/0x250
__send_signal+0x170/0x310
send_signal+0x40/0x80
do_send_sig_info+0x47/0x90
group_send_sig_info+0x4a/0x70
kill_pid_info+0x3a/0x60
sys_kill+0x97/0x1a0
? vfs_read+0x120/0x160
? sys_read+0x45/0x90
system_call_fastpath+0x16/0x1b
Code: 49 0f af 41 50 31 d2 49 f7 f0 48 83 f8 01 48 0f 46 c6 48 2b 07 48 8b bf 40 01 00 00 48 85 ff 74 3a 45 31 c0 48 8b 8f 50 01 00 00 <48> 8b 11 4c 8b 89 80 00 00 00 49 89 d2 48 01 d0 45 8b 59 58 4c
RIP [<ffffffff81063ac0>] effective_load.isra.43+0x50/0x90
RSP <ffff880221ddfbd8>
CR2: 0000000000000000---
kernel/sched_autogroup.c +0 -4
@@ -160,15 +160,11 @@ autogroup_move_group(struct task_struct p->signal->autogroup =autogroup_kref_get (ag); -if (!ACCESS_ONCE (sysctl_sched_autogroup_enabled)) - goto out; - t = p; do { sched_move_task(t); } while_each_thread(p, t); -out: unlock_task_sighand(p, &flags); autogroup_kref_put(prev); }
kernel/sched_autogroup.h +0 -5
@@ -1,11 +1,6 @@ #ifdef CONFIG_SCHED_AUTOGROUP struct autogroup { - /* - * reference doesn't mean how many thread attach to this - * autogroup now. It just stands for the number of task - * could use this autogroup. - */ struct kref kref; struct task_group *tg; struct rw_semaphore lock;
PATCH 28/173 Revert misapplied "mmc: sh-mmcif: avoid oops on spurious interrupts"
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chris Ball <[email protected]>
commit 6984f3c31bb57cb7491dbec1be44b74bd00f4648 upstream.
This reverts commit 8464dd52d3198dd05, which was a misapplied debugging version of the patch, not the final patch itself.
--- drivers/mmc/host/sh_mmcif.c | 4 ---- 1 file changed, 4 deletions(-)
drivers/mmc/host/sh_mmcif.c +0 -4
@@ -1003,10 +1003,6 @@ static irqreturn_t sh_mmcif_intr(int irq host->sd_error = true;dev_dbg (&host->pd->dev,"int err state = %08x\n" , state); } -if (host->state ==STATE_IDLE ) { -dev_info (&host->pd->dev,"Spurious IRQ status 0x%x" , state); -return IRQ_HANDLED ; - }if (state & ~(INT_CMD12RBE |INT_CMD12CRE ))complete (&host->intr_wait);else
PATCH 29/173 tmpfs: fix shared mempolicy leak
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mel Gorman <[email protected]>
commit 18a2f371f5edf41810f6469cb9be39931ef9deb9 upstream.
This fixes a regression in 3.7-rc, which has since gone into stable.
Commit 00442ad04a5e ("mempolicy: fix a memory corruption by refcount imbalance in alloc_pages_vma()") changed get_vma_policy() to raise the refcount on a shmem shared mempolicy; whereas shmem_alloc_page() went on expecting alloc_page_vma() to drop the refcount it had acquired. This deserves a rework: but for now fix the leak in shmem_alloc_page().
Hugh: shmem_swapin() did not need a fix, but surely it's clearer to use the same refcounting there as in shmem_alloc_page(), delete its onstack mempolicy, and the strange mpol_cond_copy() and __mpol_cond_copy() - those were invented to let swapin_readahead() make an unknown number of calls to alloc_pages_vma() with one mempolicy; but since 00442ad04a5e, alloc_pages_vma() has kept refcount in balance, so now no problem.
--- include/linux/mempolicy.h | 16 ---------------- mm/mempolicy.c | 22 ---------------------- mm/shmem.c | 26 ++++++++++++++++---------- 3 files changed, 16 insertions(+), 48 deletions(-)
include/linux/mempolicy.h +0 -16
@@ -137,16 +137,6 @@ static inline void mpol_cond_put(struct__mpol_put (pol); } -extern struct mempolicy *__mpol_cond_copy (struct mempolicy *tompol, -struct mempolicy *frompol); -static inline struct mempolicy *mpol_cond_copy (struct mempolicy *tompol, -struct mempolicy *frompol) -{ -if (!frompol) -return frompol; -return __mpol_cond_copy (tompol, frompol); -} -extern struct mempolicy *__mpol_dup (struct mempolicy *pol);static inline struct mempolicy *mpol_dup (struct mempolicy *pol) {
@@ -270,12 +260,6 @@ static inline void mpol_cond_put(struct { } -static inline struct mempolicy *mpol_cond_copy (struct mempolicy *to, -struct mempolicy *from) -{ -return from; -} -static inline void mpol_get (struct mempolicy *pol) { }
mm/mempolicy.c +0 -22
@@ -1999,28 +1999,6 @@ struct mempolicy *__mpol_dup(struct mempreturn new; } -/* -* If *frompol needs [has] an extra ref, copy *frompol to *tompol , -* eliminate the * MPOL_F_* flags that require conditional ref and -* [NOTE!!!] drop the extra ref. Not safe to reference *frompol directly -* after return. Use the returned value. -* -* Allows use of a mempolicy for, e.g., multiple allocations with a single -* policy lookup, even if the policy needs/has extra ref on lookup. -* shmem_readahead needs this. -*/ -struct mempolicy *__mpol_cond_copy (struct mempolicy *tompol, -struct mempolicy *frompol) -{ -if (!mpol_needs_cond_ref (frompol)) -return frompol; - - *tompol = *frompol; - tompol->flags &= ~MPOL_F_SHARED ;/* copy doesn't need unref */ -__mpol_put (frompol); -return tompol; -} -/* Slow path of a mempolicy comparison */ int __mpol_equal (struct mempolicy *a,struct mempolicy *b) {
mm/shmem.c +16 -10
@@ -798,24 +798,28 @@ static struct mempolicy *shmem_get_sbmpostatic struct page *shmem_swapin (swp_entry_t swap,gfp_t gfp,struct shmem_inode_info *info,pgoff_t index) { -struct mempolicy mpol, *spol;struct vm_area_struct pvma; - - spol =mpol_cond_copy (&mpol, -mpol_shared_policy_lookup (&info->policy, index)); +struct page *page;/* Create a pseudo vma that just contains the policy */ pvma.vm_start =0 ; pvma.vm_pgoff = index; pvma.vm_ops =NULL ; - pvma.vm_policy = spol; -return swapin_readahead (swap, gfp, &pvma,0 ); + pvma.vm_policy =mpol_shared_policy_lookup (&info->policy, index); + + page =swapin_readahead (swap, gfp, &pvma,0 ); + +/* Drop reference taken by mpol_shared_policy_lookup() */ +mpol_cond_put (pvma.vm_policy); + +return page; }static struct page *shmem_alloc_page (gfp_t gfp,struct shmem_inode_info *info,pgoff_t index) {struct vm_area_struct pvma; +struct page *page;/* Create a pseudo vma that just contains the policy */ pvma.vm_start =0 ;
@@ -823,10 +827,12 @@ static struct page *shmem_alloc_page(gfp pvma.vm_ops =NULL ; pvma.vm_policy =mpol_shared_policy_lookup (&info->policy, index); -/* -* alloc_page_vma() will drop the shared policy reference -*/ - return alloc_page_vma(gfp, &pvma, 0); + page =alloc_page_vma (gfp, &pvma,0 ); + +/* Drop reference taken by mpol_shared_policy_lookup() */ +mpol_cond_put (pvma.vm_policy); + + return page; }#else /* !CONFIG_NUMA */ #ifdef CONFIG_TMPFS
PATCH 30/173 powerpc: fix wii_memory_fixups() compile error on 3.0.y tree
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shuah Khan <[email protected]>
Fix wii_memory_fixups() the following compile error on 3.0.y tree with wii_defconfig on 3.0.y tree.
CC arch/powerpc/platforms/embedded6xx/wii.oarch/powerpc/platforms/embedded6xx/wii.c: In function ‘wii_memory_fixups’:arch/powerpc/platforms/embedded6xx/wii.c:88:2: error: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 2 has type ‘phys_addr_t’ [-Werror=format] arch/powerpc/platforms/embedded6xx/wii.c:88:2: error: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 3 has type ‘phys_addr_t’ [-Werror=format] arch/powerpc/platforms/embedded6xx/wii.c:90:2: error: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 2 has type ‘phys_addr_t’ [-Werror=format] arch/powerpc/platforms/embedded6xx/wii.c:90:2: error: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 3 has type ‘phys_addr_t’ [-Werror=format]
cc1: all warnings being treated as errors
make[2]: *** [arch/powerpc/platforms/embedded6xx/wii.o] Error 1
make[1]: *** [arch/powerpc/platforms/embedded6xx] Error 2
make: *** [arch/powerpc/platforms] Error 2
--- arch/powerpc/platforms/embedded6xx/wii.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
arch/powerpc/platforms/embedded6xx/wii.c +4 -2
@@ -85,9 +85,11 @@ void __init wii_memory_fixups(void) wii_hole_start = p[0 ].base + p[0 ].size; wii_hole_size = p[1 ].base - wii_hole_start; -pr_info ("MEM1: <%08llx %08llx>\n" , p[0 ].base, p[0 ].size); +pr_info ("MEM1: <%08llx %08llx>\n" , + (unsigned long long ) p[0 ].base, (unsigned long long ) p[0 ].size);pr_info ("HOLE: <%08lx %08lx>\n" , wii_hole_start, wii_hole_size); -pr_info ("MEM2: <%08llx %08llx>\n" , p[1 ].base, p[1 ].size); +pr_info ("MEM2: <%08llx %08llx>\n" , + (unsigned long long ) p[1 ].base, (unsigned long long ) p[1 ].size); p[0 ].size += wii_hole_size + p[1 ].size;
PATCH 31/173 s390/kvm: dont announce RRBM support
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christian Borntraeger <[email protected]>
commit 87cac8f879a5ecd7109dbe688087e8810b3364eb upstream.
Newer kernels (linux-next with the transparent huge page patches) use rrbm if the feature is announced via feature bit 66. RRBM will cause intercepts, so KVM does not handle it right now, causing an illegal instruction in the guest.
The easy solution is to disable the feature bit for the guest.
This fixes bugs like:
Kernel BUG at 0000000000124c2a [verbose debug info unavailable]
illegal operation: 0001 [#1] SMP
Modules linked in: virtio_balloon virtio_net ipv6 autofs4
CPU: 0 Not tainted 3.5.4 #1
Process fmempig (pid: 659, task: 000000007b712fd0, ksp: 000000007bed3670)
Krnl PSW : 0704d00180000000 0000000000124c2a (pmdp_clear_flush_young+0x5e/0x80)
R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 EA:3
00000000003cc000 0000000000000004 0000000000000000 0000000079800000
0000000000040000 0000000000000000 000000007bed3918 000000007cf40000
0000000000000001 000003fff7f00000 000003d281a94000 000000007bed383c
000000007bed3918 00000000005ecbf8 00000000002314a6 000000007bed36e0
Krnl Code:>0000000000124c2a: b9810025 ogr %r2,%r5
0000000000124c2e: 41343000 la %r3,0(%r4,%r3)
0000000000124c32: a716fffa brct %r1,124c26
0000000000124c36: b9010022 lngr %r2,%r2
0000000000124c3a: e3d0f0800004 lg %r13,128(%r15)
0000000000124c40: eb22003f000c srlg %r2,%r2,63
[ 2150.713198] Call Trace:
[ 2150.713223] ([<00000000002312c4>] page_referenced_one+0x6c/0x27c)
[ 2150.713749] [<0000000000233812>] page_referenced+0x32a/0x410[...]
--- arch/s390/kvm/kvm-s390.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/s390/kvm/kvm-s390.c +1 -1
@@ -997,7 +997,7 @@ static int __init kvm_s390_init(void) }memcpy (facilities, S390_lowcore.stfle_fac_list,16 ); facilities[0 ] &=0xff00fff3f47c0000ULL ; - facilities[1 ] &=0x201c000000000000ULL ; + facilities[1 ] &=0x001c000000000000ULL ;return 0 ; }
PATCH 32/173 cgroup: cgroup_subsys->fork() should be called after the task is added to css_set
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tejun Heo <[email protected]>
commit 5edee61edeaaebafe584f8fb7074c1ef4658596b upstream.
cgroup core has a bug which violates a basic rule about event notifications - when a new entity needs to be added, you add that to the notification list first and then make the new entity conform to the current state. If done in the reverse order, an event happening inbetween will be lost.
cgroup_subsys->fork() is invoked way before the new task is added to the css_set. Currently, cgroup_freezer is the only user of ->fork() and uses it to make new tasks conform to the current state of the freezer. If FROZEN state is requested while fork is in progress between cgroup_fork_callbacks() and cgroup_post_fork(), the child could escape freezing - the cgroup isn't frozen when ->fork() is called and the freezer couldn't see the new task on the css_set.
This patch moves cgroup_subsys->fork() invocation to cgroup_post_fork() after the new task is added to the css_set. cgroup_fork_callbacks() is removed.
Because now a task may be migrated during cgroup_subsys->fork(), freezer_fork() is updated so that it adheres to the usual RCU locking and the rather pointless comment on why locking can be different there is removed (if it doesn't make anything simpler, why even bother?).
[bwh: Backported to 3.2:
- Adjust context
- Iterate over first CGROUP_BUILTIN_SUBSYS_COUNT elements of subsys
- cgroup_subsys::fork takes cgroup_subsys pointer as first parameter]
--- include/linux/cgroup.h | 1 - kernel/cgroup.c | 62 +++++++++++++++++++++++------------------------ kernel/cgroup_freezer.c | 13 +++------- kernel/fork.c | 9 +------ 4 files changed, 35 insertions(+), 50 deletions(-)
include/linux/cgroup.h +0 -1
@@ -32,7 +32,6 @@ extern int cgroup_lock_is_held(void);extern bool cgroup_lock_live_group (struct cgroup *cgrp);extern void cgroup_unlock (void );extern void cgroup_fork (struct task_struct *p); -extern void cgroup_fork_callbacks (struct task_struct *p);extern void cgroup_post_fork (struct task_struct *p);extern void cgroup_exit (struct task_struct *p,int run_callbacks); extern int cgroupstats_build(struct cgroupstats *stats,
kernel/cgroup.c +21 -29
69 lines not on this page · raw message
kernel/cgroup_freezer.c +4 -9
@@ -197,23 +197,15 @@ static void freezer_fork(struct cgroup_s {struct freezer *freezer; -/* -* No lock is needed, since the task isn't on tasklist yet, -* so it can't be moved to another cgroup, which means the -* freezer won't be removed and will be valid during this -* function call. Nevertheless, apply RCU read-side critical -* section to suppress RCU lockdep false positives. -*/ rcu_read_lock (); freezer =task_freezer (task); -rcu_read_unlock ();/* * The root cgroup is non-freezable, so we can skip the * following check. */ if (!freezer->css.cgroup->parent) -return ; + goto out;spin_lock_irq (&freezer->lock);BUG_ON (freezer->state ==CGROUP_FROZEN );
@@ -221,7 +213,10 @@ static void freezer_fork(struct cgroup_s/* Locking avoids race with FREEZING -> THAWED transitions. */ if (freezer->state ==CGROUP_FREEZING )freeze_task (task, true); +spin_unlock_irq (&freezer->lock); +out: +rcu_read_unlock (); }/*
kernel/fork.c +1 -8
@@ -1057,7 +1057,6 @@ static struct task_struct *copy_process( {int retval;struct task_struct *p; -int cgroup_callbacks_done =0 ;if ((clone_flags & (CLONE_NEWNS |CLONE_FS )) == (CLONE_NEWNS |CLONE_FS ))return ERR_PTR (-EINVAL );
@@ -1312,12 +1311,6 @@ static struct task_struct *copy_process( p->group_leader = p;INIT_LIST_HEAD (&p->thread_group); -/* Now that the task is set up, run cgroup callbacks if -* necessary. We need to run them before the task is visible -* on the tasklist. */ -cgroup_fork_callbacks (p); - cgroup_callbacks_done =1 ; -/* Need tasklist lock for parent etc handling! */ write_lock_irq (&tasklist_lock);
@@ -1419,7 +1412,7 @@ bad_fork_cleanup_cgroup:#endif if (clone_flags &CLONE_THREAD )threadgroup_fork_read_unlock (current); -cgroup_exit (p, cgroup_callbacks_done); +cgroup_exit (p,0 );delayacct_tsk_free (p);module_put (task_thread_info (p)->exec_domain->module); bad_fork_cleanup_count:
Re: [ 032/173] cgroup: cgroup_subsys->fork() should be called after the task is added to css_set
Hi Ben,
At Fri, 28 Dec 2012 20:04:02 +0100,
Quoted 32 lines · Ben Hutchings
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tejun Heo <[email protected]>
commit
5edee61edeaaebafe584f8fb7074c1ef4658596bupstream.cgroup core has a bug which violates a basic rule about event notifications - when a new entity needs to be added, you add that to the notification list first and then make the new entity conform to the current state. If done in the reverse order, an event happening inbetween will be lost.
cgroup_subsys->fork()is invoked way before the new task is added to thecss_set. Currently,cgroup_freezeris the only user of ->fork() and uses it to make new tasks conform to the current state of the freezer. If FROZEN state is requested while fork is in progress betweencgroup_fork_callbacks()andcgroup_post_fork(), the child could escape freezing - the cgroup isn't frozen when ->fork() is called and the freezer couldn't see the new task on thecss_set.This patch moves
cgroup_subsys->fork()invocation tocgroup_post_fork()after the new task is added to thecss_set.cgroup_fork_callbacks()is removed.Because now a task may be migrated during
cgroup_subsys->fork(),freezer_fork()is updated so that it adheres to the usual RCU locking and the rather pointless comment on why locking can be different there is removed (if it doesn't make anything simpler, why even bother?).
Quoted 8 lines
Signed-off-by Tejun Heo <[email protected]>Cc Oleg Nesterov <[email protected]>Cc Rafael J. Wysocki <[email protected]>[bwh: Backported to 3.2:
- Adjust context
- Iterate over firstCGROUP_BUILTIN_SUBSYS_COUNTelements of subsys
-cgroup_subsys::forktakescgroup_subsyspointer as first parameter]Signed-off-by Ben Hutchings <[email protected]>
I failed to compile 3.2.36-rc1 with my x86_64 box with enabling cgroup.
build log:
===============================================================================
...
CC kernel/cgroup.okernel/cgroup.c: In function ‘cgroup_post_fork’:kernel/cgroup.c:4540:5: warning: passing argument 1 of ‘ss->fork’ from incompatible pointer type [enabled by default] kernel/cgroup.c:4540:5: note: expected ‘struct cgroup_subsys *’ but argument is of type ‘struct task_struct *’ kernel/cgroup.c:4540:5: error: too few arguments to function ‘ss->fork’
make[2]: *** [kernel/cgroup.o] Error 1
make[1]: *** [kernel] Error 2
make[1]: Leaving directory `/home/sat/src/linux-stable'
make: *** [debian/stamp/build/kernel] Error 2
===============================================================================
It comes from the ss->fork()'s API change introduced by commit 761b3ef50e1c2.
Quoted 5 lines
(quoted diff) +1
-0@@ -4551,7 +4529,21 @@ void cgroup_post_fork(struct task_struct task_unlock(child); write_unlock(&css_set_lock); } +
Review void cgroup_post_fork(struct task_struct · line 4542
Quoted 10 lines
(quoted diff) +10
-0+ /* + * Call ss->fork(). This must happen after @child is linked on + * css_set; otherwise, @child might change state between ->fork() + * and addition to css_set. + */ + if (need_forkexit_callback) { + for (i = 0; i < CGROUP_BUILTIN_SUBSYS_COUNT; i++) { + struct cgroup_subsys *ss = subsys[i]; + if (ss->fork) + ss->fork(child);
I found you mentioned this difference in the desctiption as follows.
Review void cgroup_post_fork(struct task_struct · line 4543
Quoted 1 line
(quoted diff) +0
-0- cgroup_subsys::fork takes cgroup_subsys pointer as first parameter]
I guess you attached the wrong patch, or you forgot to modify the original patch. Here is the correct patch for the latter case. It just change "ss->fork(child)" to "ss->fork(ss, child)" as your description.
Thanks,
Satoru
---
From: Tejun Heo <[email protected]>
Date: Tue, 16 Oct 2012 15:03:14 -0700
Subject: cgroup: cgroup_subsys->fork() should be called after the task is
added to css_set
commit 5edee61edeaaebafe584f8fb7074c1ef4658596b upstream.
cgroup core has a bug which violates a basic rule about event notifications - when a new entity needs to be added, you add that to the notification list first and then make the new entity conform to the current state. If done in the reverse order, an event happening inbetween will be lost.
cgroup_subsys->fork() is invoked way before the new task is added to the css_set. Currently, cgroup_freezer is the only user of ->fork() and uses it to make new tasks conform to the current state of the freezer. If FROZEN state is requested while fork is in progress between cgroup_fork_callbacks() and cgroup_post_fork(), the child could escape freezing - the cgroup isn't frozen when ->fork() is called and the freezer couldn't see the new task on the css_set.
This patch moves cgroup_subsys->fork() invocation to cgroup_post_fork() after the new task is added to the css_set. cgroup_fork_callbacks() is removed.
Because now a task may be migrated during cgroup_subsys->fork(), freezer_fork() is updated so that it adheres to the usual RCU locking and the rather pointless comment on why locking can be different there is removed (if it doesn't make anything simpler, why even bother?).
[bwh: Backported to 3.2:
- Adjust context
- Iterate over first CGROUP_BUILTIN_SUBSYS_COUNT elements of subsys
- cgroup_subsys::fork takes cgroup_subsys pointer as first parameter]
--- include/linux/cgroup.h | 1 - kernel/cgroup.c | 62 +++++++++++++++++++++++------------------------ kernel/cgroup_freezer.c | 13 +++------- kernel/fork.c | 9 +------ 4 files changed, 35 insertions(+), 50 deletions(-)
include/linux/cgroup.h +0 -1
@@ -32,7 +32,6 @@ extern int cgroup_lock_is_held(void);extern bool cgroup_lock_live_group (struct cgroup *cgrp);extern void cgroup_unlock (void );extern void cgroup_fork (struct task_struct *p); -extern void cgroup_fork_callbacks (struct task_struct *p);extern void cgroup_post_fork (struct task_struct *p);extern void cgroup_exit (struct task_struct *p,int run_callbacks); extern int cgroupstats_build(struct cgroupstats *stats,
kernel/cgroup.c +21 -29
69 lines not on this page · raw message
kernel/cgroup_freezer.c +4 -9
@@ -197,23 +197,15 @@ static void freezer_fork(struct cgroup_s {struct freezer *freezer; -/* -* No lock is needed, since the task isn't on tasklist yet, -* so it can't be moved to another cgroup, which means the -* freezer won't be removed and will be valid during this -* function call. Nevertheless, apply RCU read-side critical -* section to suppress RCU lockdep false positives. -*/ rcu_read_lock (); freezer =task_freezer (task); -rcu_read_unlock ();/* * The root cgroup is non-freezable, so we can skip the * following check. */ if (!freezer->css.cgroup->parent) -return ; + goto out;spin_lock_irq (&freezer->lock);BUG_ON (freezer->state ==CGROUP_FROZEN );
@@ -221,7 +213,10 @@ static void freezer_fork(struct cgroup_s/* Locking avoids race with FREEZING -> THAWED transitions. */ if (freezer->state ==CGROUP_FREEZING )freeze_task (task, true); +spin_unlock_irq (&freezer->lock); +out: +rcu_read_unlock (); }/*
kernel/fork.c +1 -8
@@ -1057,7 +1057,6 @@ static struct task_struct *copy_process( {int retval;struct task_struct *p; -int cgroup_callbacks_done =0 ;if ((clone_flags & (CLONE_NEWNS |CLONE_FS )) == (CLONE_NEWNS |CLONE_FS ))return ERR_PTR (-EINVAL );
@@ -1312,12 +1311,6 @@ static struct task_struct *copy_process( p->group_leader = p;INIT_LIST_HEAD (&p->thread_group); -/* Now that the task is set up, run cgroup callbacks if -* necessary. We need to run them before the task is visible -* on the tasklist. */ -cgroup_fork_callbacks (p); - cgroup_callbacks_done =1 ; -/* Need tasklist lock for parent etc handling! */ write_lock_irq (&tasklist_lock);
@@ -1419,7 +1412,7 @@ bad_fork_cleanup_cgroup:#endif if (clone_flags &CLONE_THREAD )threadgroup_fork_read_unlock (current); -cgroup_exit (p, cgroup_callbacks_done); +cgroup_exit (p,0 );delayacct_tsk_free (p);module_put (task_thread_info (p)->exec_domain->module); bad_fork_cleanup_count:
Re: [ 032/173] cgroup: cgroup_subsys->fork() should be called after the task is added to css_set
Quoted 12 lines · Satoru Takeuchi
Hi Ben,
At Fri, 28 Dec 2012 20:04:02 +0100,
Quoted 8 lines · Ben Hutchings
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tejun Heo <[email protected]>
commit
5edee61edeaaebafe584f8fb7074c1ef4658596bupstream.
[...]
Quoted 17 lines
I failed to compile 3.2.36-rc1 with my
x86_64box with enabling cgroup.build log:
===============================================================================
...
CCkernel/cgroup.okernel/cgroup.c: In function ‘cgroup_post_fork’:kernel/cgroup.c:4540:5: warning: passing argument 1 of ‘ss->fork’ from incompatible pointer type [enabled by default]kernel/cgroup.c:4540:5: note: expected ‘structcgroup_subsys*’ but argument is of type ‘structtask_struct*’kernel/cgroup.c:4540:5: error: too few arguments to function ‘ss->fork’
make[2]: *** [kernel/cgroup.o] Error 1
make[1]: *** [kernel] Error 2
make[1]: Leaving directory `/home/sat/src/linux-stable'
make: *** [debian/stamp/build/kernel] Error 2
===============================================================================It comes from the ss->fork()'s API change introduced by commit
761b3ef50e1c2.
[...]
Quoted 7 lines
I found you mentioned this difference in the desctiption as follows.
Quoted 1 line
-
cgroup_subsys::forktakescgroup_subsyspointer as first parameter]I guess you attached the wrong patch, or you forgot to modify the original patch. Here is the correct patch for the latter case. It just change "
ss->fork(child)" to "ss->fork(ss, child)" as your description.
[...]
The correct version is in the combined patch, but I somehow missed refreshing this individual patch. Thanks for pointing this out.
Ben.
Signature · 2 lines
Ben Hutchings It is easier to change the specification to fit the program than vice versa.
Re: [ 032/173] cgroup: cgroup_subsys->fork() should be called after the task is added to css_set
At Tue, 01 Jan 2013 14:20:56 +0000,
Ben Hutchings wrote:
...
Quoted 33 lines
Quoted 10 lines
At Fri, 28 Dec 2012 20:04:02 +0100,
Quoted 8 lines · Ben Hutchings
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tejun Heo <[email protected]>
commit
5edee61edeaaebafe584f8fb7074c1ef4658596bupstream.[...]
Quoted 17 lines
I failed to compile 3.2.36-rc1 with my
x86_64box with enabling cgroup.build log:
===============================================================================
...
CCkernel/cgroup.okernel/cgroup.c: In function ‘cgroup_post_fork’:kernel/cgroup.c:4540:5: warning: passing argument 1 of ‘ss->fork’ from incompatible pointer type [enabled by default]kernel/cgroup.c:4540:5: note: expected ‘structcgroup_subsys*’ but argument is of type ‘structtask_struct*’kernel/cgroup.c:4540:5: error: too few arguments to function ‘ss->fork’
make[2]: *** [kernel/cgroup.o] Error 1
make[1]: *** [kernel] Error 2
make[1]: Leaving directory `/home/sat/src/linux-stable'
make: *** [debian/stamp/build/kernel] Error 2
===============================================================================It comes from the ss->fork()'s API change introduced by commit
761b3ef50e1c2.[...]
Quoted 4 lines
I found you mentioned this difference in the desctiption as follows.
Quoted 1 line
-
cgroup_subsys::forktakescgroup_subsyspointer as first parameter]
Quoted 7 lines
Quoted 3 lines
I guess you attached the wrong patch, or you forgot to modify the original patch. Here is the correct patch for the latter case. It just change "
ss->fork(child)" to "ss->fork(ss, child)" as your description.[...]
The correct version is in the combined patch, but I somehow missed refreshing this individual patch. Thanks for pointing this out.
Ah, I got your patches from your git tree instead of combined patch since I lost that patch's mail. Anyway, this kernel can be built and boot without any problem. Building a kernel with this kernel also works fine.
- Build Machine: debian wheezy x86_64
CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4
memory: 8GB
- Test machine: debian wheezy x86_64(KVM guest on the Build Machine)
vCPU: x2
memory: 2GB
I reviewed the following patches and it looks good to me.
Quoted 7 lines
Al Viro (1):
ARM: missing ->mmap_sem around find_vma() in swp_emulate.c [7bf9b7bef881aac820bf1f2e9951a17b09bd7e04]Alan Cox (3):
ACPI: missing break
[879dca019dc43a1622edca3e7dde644b14b5acc5]
...
Quoted 5 lines
Artem Bityutskiy (1):
proc: pid/status: show all supplementary groups
[8d238027b87e654be552eabdf492042a34c5c300]Ben Hutchings (4):
...
Quoted 6 lines
Revert "
device_cgroup: fix RCU usage"
[not upstream; change was correct for mainline but not 3.2]
Revert "mm: vmscan: fix endless loop in kswapd balancing"
[not upstream; change was correct for mainline but not 3.2]
mm: addkmap_to_page()
[part of5a178119b0fbe37f7dfb602b37df9cc4b1dc9d71]
...
Quoted 1 line
Dan Carpenter (3):
...
Quoted 2 lines
ftrace: Clear bits properly in
reset_iter_read()
[70f77b3f7ec010ff9624c1f2e39a81babc9e2429]
...
Quoted 9 lines
David Rientjes (1):
thp, memcg: split hugepage for memcg oom on cow
[1f1d06c34f7675026326cd9f39ff91e4555cf355]David Woodhouse (2):
intel-iommu: Free old page tables before creating superpage
[6491d4d02893d9787ba67279595990217177b351]
solos-pci: fix double-free of TX skb in DMA mode
[cae49ede00ec3d0cda290b03fee55b72b49efc11]
...
Quoted 11 lines
Eric Dumazet (1):
rcu: Fix batch-limit size problem
[878d7439d0f45a95869e417576774673d1fa243f]Eric Sandeen (1):
ext4: init pagevec inext4_da_block_invalidatepages
[66bea92c69477a75a5d37b9bfed5773c92a3c4b4]Eugene Shatokhin (1):
ext4: fix memory leak in ext4_xattr_set_acl()'s error path
[24ec19b0ae83a385ad9c55520716da671274b96c]
...
Quoted 2 lines
x86: hpet: Fix masking of MSI interrupts
[6acf5a8c931da9d26c8dd77d784daaf07fa2bff0]
...
Quoted 3 lines
Kees Cook (2):
exec: do not leave bprm->interp on stack [b66c5984017533316fd1951770302649baf1aa33]
...
Quoted 4 lines
Marek Szyprowski (1):
mm: dmapool: use provided gfp flags for alldma_alloc_coherent()calls
[387870f2d6d679746020fa8e25ef786ff338dc98]
...
Quoted 3 lines
Mel Gorman (1):
tmpfs: fix shared mempolicy leak
[18a2f371f5edf41810f6469cb9be39931ef9deb9]
...
Quoted 3 lines
Mike Galbraith (1):
Revert "sched, autogroup: Stop going ahead if autogroup is disabled"
[fd8ef11730f1d03d5d6555aa53126e9e34f52f12]
...
Quoted 3 lines
Steven Rostedt (1):
ring-buffer: Fix NULL pointer ifrb_set_head_page()fails
[54f7be5b831254199522523ccab4c3d954bbf576]
...
Quoted 13 lines
Tejun Heo (4):
cgroup: cgroup_subsys->fork() should be called after the task is added to css_set [5edee61edeaaebafe584f8fb7074c1ef4658596b] cgroup: remove incorrect dget/dput() pair in cgroup_create_dir() [175431635ec09b1d1bba04979b006b99e8305a83] freezer: add missing mb's to freezer_count() and freezer_should_skip() [dd67d32dbc5de299d70cc9e10c6c1e29ffa56b92] workqueue: convert BUG_ON()s in __queue_delayed_work() to WARN_ON_ONCE()s [fc4b514f2727f74a4587c31db87e0e93465518c3]Thomas Gleixner (1):
genirq: Always force thread affinity
[04aa530ec04f61875b99c12721162e2964e3318c]
...
Quoted 1 line
Will Deacon (4):
...
Quoted 6 lines
mm: highmem: export
kmap_to_pagefor modules
[f0263d2d222e9e25f2587e51a9dc58c6fb2a9352]
virtio: 9p: correctly pass physical address to userspace for high pages
[b9cdc88df8e63e81c723b82c286fc97f5d0dc325]
virtio: force vring descriptors to be allocated from lowmem
[b92b1b89a33c172c075edccf6afb0edc41d851fd]
...
Quoted 3 lines
Xiaotian Feng (1):
[libata] fix Null pointer dereference on disk error
[26cd4d65deba587f3cf2329b6869ce02bcbe68ec]
Thanks,
Satoru
PATCH 33/173 freezer: add missing mbs to freezer_count() and freezer_should_skip()
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tejun Heo <[email protected]>
commit dd67d32dbc5de299d70cc9e10c6c1e29ffa56b92 upstream.
A task is considered frozen enough between freezer_do_not_count() and freezer_count() and freezers use freezer_should_skip() to test this condition. This supposedly works because freezer_count() always calls try_to_freezer() after clearing %PF_FREEZER_SKIP.
However, there currently is nothing which guarantees that freezer_count() sees %true freezing() after clearing %PF_FREEZER_SKIP when freezing is in progress, and vice-versa. A task can escape the freezing condition in effect by freezer_count() seeing !freezing() and freezer_should_skip() seeing %PF_FREEZER_SKIP.
This patch adds smp_mb()'s to freezer_count() and freezer_should_skip() such that either %true freezing() is visible to freezer_count() or !PF_FREEZER_SKIP is visible to freezer_should_skip().
[bwh: Backported to 3.2:
- Adjust context and indentation
- freezer_do_not_count() and freezer_count() are no-ops for kernel tasks]
--- include/linux/freezer.h | 50 +++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 42 insertions(+), 8 deletions(-)
include/linux/freezer.h +41 -10
@@ -88,9 +88,16 @@ static inline int cgroup_freezing_or_fro* parent. */ -/* -* If the current task is a user space one, tell the freezer not to count it as -* freezable. +/** +* freezer_do_not_count - tell freezer to ignore %current if a user space task +* +* Tell freezers to ignore the current task when determining whether the +* target frozen state is reached. IOW, the current task will be +* considered frozen enough by freezers. +* +* The caller shouldn't do anything which isn't allowed for a frozen task +* until freezer_cont() is called. Usually, freezer[_do_not]_count() pair +* wrap a scheduling operation and nothing much else. */ static inline void freezer_do_not_count (void ) {
@@ -98,24 +105,48 @@ static inline void freezer_do_not_count( current->flags |=PF_FREEZER_SKIP ; } -/* -* If the current task is a user space one, tell the freezer to count it as -* freezable again and try to freeze it. +/** +* freezer_count - tell freezer to stop ignoring %current if a user space task +* +* Undo freezer_do_not_count(). It tells freezers that %current should be +* considered again and tries to freeze if freezing condition is already in +* effect. */ static inline void freezer_count (void ) {if (current->mm) { current->flags &= ~PF_FREEZER_SKIP ; +/* +* If freezing is in progress, the following paired with smp_mb() +* in freezer_should_skip() ensures that either we see %true +* freezing() or freezer_should_skip() sees !PF_FREEZER_SKIP. +*/ +smp_mb ();try_to_freeze (); } } -/* -* Check if the task should be counted as freezable by the freezer +/** +* freezer_should_skip - whether to skip a task when determining frozen +* state is reached +* @p: task in quesion +* +* This function is used by freezers after establishing %true freezing() to +* test whether a task should be skipped when determining the target frozen +* state is reached. IOW, if this function returns %true, @p is considered +* frozen enough. */ -static inline int freezer_should_skip (struct task_struct *p) +static inline bool freezer_should_skip (struct task_struct *p) { -return !!(p->flags &PF_FREEZER_SKIP ); +/* +* The following smp_mb() paired with the one in freezer_count() +* ensures that either freezer_count() sees %true freezing() or we +* see cleared %PF_FREEZER_SKIP and return %false. This makes it +* impossible for a task to slip frozen state testing after +* clearing %PF_FREEZER_SKIP. +*/ +smp_mb (); +return p->flags &PF_FREEZER_SKIP ; }/*
PATCH 34/173 mm: add kmap_to_page()
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ben Hutchings <[email protected]>
This is extracted from Mel Gorman's commit 5a178119b0fb ('mm: add support for direct_IO to highmem pages') upstream.
Required to backport commit b9cdc88df8e6 ('virtio: 9p: correctly pass physical address to userspace for high pages').
--- include/linux/highmem.h | 7 +++++++ mm/highmem.c | 12 ++++++++++++ mm/page_io.c | 3 ++- mm/swap.c | 3 +-- 4 files changed, 22 insertions(+), 3 deletions(-)
include/linux/highmem.h +7 -0
@@ -38,10 +38,17 @@ extern unsigned long totalhigh_pages;void kmap_flush_unused (void ); +struct page *kmap_to_page (void *addr); +#else /* CONFIG_HIGHMEM */ static inline unsigned int nr_free_highpages (void ) {return 0 ; } +static inline struct page *kmap_to_page (void *addr) +{ +return virt_to_page (addr); +} +#define totalhigh_pages 0UL#ifndef ARCH_HAS_KMAP
mm/highmem.c +12 -0
@@ -94,6 +94,18 @@ static DECLARE_WAIT_QUEUE_HEAD(pkmap_map do { spin_unlock(&kmap_lock); (void)(flags); } while (0)#endif +struct page *kmap_to_page (void *vaddr) +{ +unsigned long addr = (unsigned long )vaddr; + +if (addr >=PKMAP_ADDR (0 ) && addr <=PKMAP_ADDR (LAST_PKMAP )) { +int i = (addr -PKMAP_ADDR (0 )) >>PAGE_SHIFT ; +return pte_page (pkmap_page_table[i]); + } + +return virt_to_page (addr); +} +static void flush_all_zero_pkmaps (void ) {int i;
PATCH 35/173 mm: highmem: export kmap_to_page for modules
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Will Deacon <[email protected]>
commit f0263d2d222e9e25f2587e51a9dc58c6fb2a9352 upstream.
Some virtio device drivers (9p) need to translate high virtual addresses to physical addresses, which are inserted into the virtqueue for processing by userspace.
This patch exports the kmap_to_page symbol, so that the affected drivers can be compiled as modules.
--- mm/highmem.c | 1 + 1 file changed, 1 insertion(+)
mm/highmem.c +1 -0
@@ -105,6 +105,7 @@ struct page *kmap_to_page(void *vaddr)return virt_to_page (addr); } +EXPORT_SYMBOL (kmap_to_page);static void flush_all_zero_pkmaps (void ) {
PATCH 36/173 virtio: 9p: correctly pass physical address to userspace for high pages
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Will Deacon <[email protected]>
commit b9cdc88df8e63e81c723b82c286fc97f5d0dc325 upstream.
When using a virtio transport, the 9p net device may pass the physical address of a kernel buffer to userspace via a scatterlist inside a virtqueue. If the kernel buffer is mapped outside of the linear mapping (e.g. highmem), then virt_to_page will return a bogus value and we will populate the scatterlist with junk.
This patch uses kmap_to_page when populating the page array for a kernel buffer.
--- net/9p/trans_virtio.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
net/9p/trans_virtio.c +2 -1
@@ -39,6 +39,7 @@#include <linux/inet.h> #include <linux/idr.h> #include <linux/file.h> +#include <linux/highmem.h> #include <linux/slab.h> #include <net/9p/9p.h> #include <linux/parser.h>
@@ -325,7 +326,7 @@ static int p9_get_mapped_pages(struct virtio_chan *chan,int count = nr_pages;while (nr_pages) { s =rest_of_page (data); - pages[index++] =virt_to_page (data); + pages[index++] =kmap_to_page (data); data += s; nr_pages--; }
PATCH 37/173 virtio: force vring descriptors to be allocated from lowmem
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Will Deacon <[email protected]>
commit b92b1b89a33c172c075edccf6afb0edc41d851fd upstream.
Virtio devices may attempt to add descriptors to a virtqueue from atomic context using GFP_ATOMIC allocation. This is problematic because such allocations can fall outside of the lowmem mapping, causing virt_to_phys to report bogus physical addresses which are subsequently passed to userspace via the buffers for the virtual device.
This patch masks out __GFP_HIGH and __GFP_HIGHMEM from the requested flags when allocating descriptors for a virtqueue. If an atomic allocation is requested and later fails, we will return -ENOSPC which will be handled by the driver.
--- drivers/virtio/virtio_ring.c | 7 +++++++ 1 file changed, 7 insertions(+)
drivers/virtio/virtio_ring.c +7 -0
@@ -135,6 +135,13 @@ static int vring_add_indirect(struct vring_virtqueue *vq,unsigned head;int i; +/* +* We require lowmem mappings for the descriptors because +* otherwise virt_to_phys will give us bogus addresses in the +* virtqueue. +*/ + gfp &= ~(__GFP_HIGHMEM | __GFP_HIGH); + desc =kmalloc ((out + in) *sizeof (struct vring_desc ), gfp);if (!desc)return -ENOMEM ;
PATCH 38/173 ath9k_hw: Enable hw PLL power save for AR9462
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rajkumar Manoharan <[email protected]>
commit 1680260226a8fd2aab590319da83ad8e610da9bd upstream.
This reduced the power consumption to half in full and network sleep.
[bwh: Backported to 3.2:
- INIT_INI_ARRAY macro requires an explicit size argument
- Remove the now-redundant macro PCIE_PLL_ON_CREQ_DIS_L1_2P0]
--- drivers/net/wireless/ath/ath9k/ar9003_hw.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/net/wireless/ath/ath9k/ar9003_hw.c +4 -7
@@ -34,9 +34,6 @@*/ static void ar9003_hw_init_mode_regs (struct ath_hw *ah) { -#define PCIE_PLL_ON_CREQ_DIS_L1_2P0 \ - ar9462_pciephy_pll_on_clkreq_disable_L1_2p0 -#define AR9462_BB_CTX_COEFJ (x) \ ar9462_##x##_baseband_core_txfir_coeff_japan_2484
@@ -369,13 +366,13 @@ static void ar9003_hw_init_mode_regs(str/* Awake -> Sleep Setting */ INIT_INI_ARRAY (&ah->iniPcieSerdes, -PCIE_PLL_ON_CREQ_DIS_L1_2P0 , -ARRAY_SIZE (PCIE_PLL_ON_CREQ_DIS_L1_2P0 ), + ar9462_pciephy_clkreq_disable_L1_2p0, +ARRAY_SIZE (ar9462_pciephy_clkreq_disable_L1_2p0),2 );/* Sleep -> Awake Setting */ INIT_INI_ARRAY (&ah->iniPcieSerdesLowPower, -PCIE_PLL_ON_CREQ_DIS_L1_2P0 , -ARRAY_SIZE (PCIE_PLL_ON_CREQ_DIS_L1_2P0 ), + ar9462_pciephy_clkreq_disable_L1_2p0, +ARRAY_SIZE (ar9462_pciephy_clkreq_disable_L1_2p0),2 );/* Fast clock modal settings */
PATCH 39/173 KVM: PPC: 44x: fix DCR read/write
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexander Graf <[email protected]>
commit e43a028752fed049e4bd94ef895542f96d79fa74 upstream.
When remembering the direction of a DCR transaction, we should write to the same variable that we interpret on later when doing vcpu_run again.
--- arch/powerpc/kvm/44x_emulate.c | 2 ++ 1 file changed, 2 insertions(+)
arch/powerpc/kvm/44x_emulate.c +2 -0
@@ -79,6 +79,7 @@ int kvmppc_core_emulate_op(struct kvm_ru run->dcr.dcrn = dcrn; run->dcr.data =0 ; run->dcr.is_write =0 ; + vcpu->arch.dcr_is_write =0 ; vcpu->arch.io_gpr = rt; vcpu->arch.dcr_needed =1 ;kvmppc_account_exit (vcpu,DCR_EXITS );
@@ -100,6 +101,7 @@ int kvmppc_core_emulate_op(struct kvm_ru run->dcr.dcrn = dcrn; run->dcr.data =kvmppc_get_gpr (vcpu, rs); run->dcr.is_write =1 ; + vcpu->arch.dcr_is_write =1 ; vcpu->arch.dcr_needed =1 ;kvmppc_account_exit (vcpu,DCR_EXITS ); emulated =EMULATE_DO_DCR ;
PATCH 40/173 usb: gadget: network: fix bind() error path
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sebastian Andrzej Siewior <[email protected]>
commit e79cc615a9bb44da72c499ccfa2c9c4bbea3aa84 upstream.
I think this is wrong since 72c973dd ("usb: gadget: add usb_endpoint_descriptor to struct usb_ep"). If we fail to allocate an ep or bail out early we shouldn't check for the descriptor which is assigned at ep_enable() time.
--- drivers/usb/gadget/f_ecm.c | 4 ++-- drivers/usb/gadget/f_eem.c | 5 ++--- drivers/usb/gadget/f_ncm.c | 4 ++-- drivers/usb/gadget/f_rndis.c | 4 ++-- drivers/usb/gadget/f_subset.c | 4 ++-- 5 files changed, 10 insertions(+), 11 deletions(-)
drivers/usb/gadget/f_ecm.c +2 -2
@@ -809,9 +809,9 @@ fail:/* we might as well release our claims on endpoints */ if (ecm->notify) ecm->notify->driver_data =NULL ; -if (ecm->port.out_ep->desc) +if (ecm->port.out_ep) ecm->port.out_ep->driver_data =NULL ; -if (ecm->port.in_ep->desc) +if (ecm->port.in_ep) ecm->port.in_ep->driver_data =NULL ;ERROR (cdev,"%s: can't bind, err %d\n" , f->name, status);
drivers/usb/gadget/f_eem.c +2 -3
@@ -319,10 +319,9 @@ fail:if (f->hs_descriptors)usb_free_descriptors (f->hs_descriptors); -/* we might as well release our claims on endpoints */ -if (eem->port.out_ep->desc) +if (eem->port.out_ep) eem->port.out_ep->driver_data =NULL ; -if (eem->port.in_ep->desc) +if (eem->port.in_ep) eem->port.in_ep->driver_data =NULL ;ERROR (cdev,"%s: can't bind, err %d\n" , f->name, status);
drivers/usb/gadget/f_ncm.c +2 -2
@@ -1259,9 +1259,9 @@ fail:/* we might as well release our claims on endpoints */ if (ncm->notify) ncm->notify->driver_data =NULL ; -if (ncm->port.out_ep->desc) +if (ncm->port.out_ep) ncm->port.out_ep->driver_data =NULL ; -if (ncm->port.in_ep->desc) +if (ncm->port.in_ep) ncm->port.in_ep->driver_data =NULL ;ERROR (cdev,"%s: can't bind, err %d\n" , f->name, status);
drivers/usb/gadget/f_rndis.c +2 -2
@@ -803,9 +803,9 @@ fail:/* we might as well release our claims on endpoints */ if (rndis->notify) rndis->notify->driver_data =NULL ; -if (rndis->port.out_ep->desc) +if (rndis->port.out_ep) rndis->port.out_ep->driver_data =NULL ; -if (rndis->port.in_ep->desc) +if (rndis->port.in_ep) rndis->port.in_ep->driver_data =NULL ;ERROR (cdev,"%s: can't bind, err %d\n" , f->name, status);
drivers/usb/gadget/f_subset.c +2 -2
@@ -370,9 +370,9 @@ fail:usb_free_descriptors (f->hs_descriptors);/* we might as well release our claims on endpoints */ -if (geth->port.out_ep->desc) +if (geth->port.out_ep) geth->port.out_ep->driver_data =NULL ; -if (geth->port.in_ep->desc) +if (geth->port.in_ep) geth->port.in_ep->driver_data =NULL ;ERROR (cdev,"%s: can't bind, err %d\n" , f->name, status);
PATCH 41/173 usb: gadget: midi: free hs descriptors
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sebastian Andrzej Siewior <[email protected]>
commit d185039f7982eb82cf8d03b6fb6689587ca5af24 upstream.
The HS descriptors are only created if HS is supported by the UDC but we never free them.
--- drivers/usb/gadget/f_midi.c | 1 + 1 file changed, 1 insertion(+)
drivers/usb/gadget/f_midi.c +1 -0
@@ -415,6 +415,7 @@ static void f_midi_unbind(struct usb_configuration *c, struct usb_function *f) midi->id =NULL ;usb_free_descriptors (f->descriptors); +usb_free_descriptors (f->hs_descriptors);kfree (midi); }
PATCH 42/173 usb: gadget: phonet: free requests in pn_bind()s error path
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sebastian Andrzej Siewior <[email protected]>
commit d0eca719dd11ad0619e8dd6a1f3eceb95b0216dd upstream.
--- drivers/usb/gadget/f_phonet.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
drivers/usb/gadget/f_phonet.c +6 -2
@@ -531,7 +531,7 @@ int pn_bind(struct usb_configuration *c, struct usb_function *f) req =usb_ep_alloc_request (fp->out_ep,GFP_KERNEL );if (!req) - goto err; + goto err_req; req->complete = pn_rx_complete; fp->out_reqv[i] = req;
@@ -540,14 +540,18 @@ int pn_bind(struct usb_configuration *c, struct usb_function *f)/* Outgoing USB requests */ fp->in_req =usb_ep_alloc_request (fp->in_ep,GFP_KERNEL );if (!fp->in_req) - goto err; + goto err_req;INFO (cdev,"USB CDC Phonet function\n" );INFO (cdev,"using %s, OUT %s, IN %s\n" , cdev->gadget->name, fp->out_ep->name, fp->in_ep->name);return 0 ; +err_req: +for (i =0 ; i < phonet_rxq_size && fp->out_reqv[i]; i++) +usb_ep_free_request (fp->out_ep, fp->out_reqv[i]); err: +if (fp->out_ep) fp->out_ep->driver_data =NULL ;if (fp->in_ep)
PATCH 43/173 usb: gadget: uvc: fix error path in uvc_function_bind()
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sebastian Andrzej Siewior <[email protected]>
commit 0f9df939385527049c8062a099fbfa1479fe7ce0 upstream.
The "video->minor = -1" assigment is done in V4L2 by video_register_device() so it is removed here.
Now. uvc_function_bind() calls in error case uvc_function_unbind() for cleanup. The problem is that uvc_function_unbind() frees the uvc struct and uvc_bind_config() does as well in error case of usb_add_function(). Removing kfree() in usb_add_function() would make the patch smaller but it would look odd because the new allocated memory is not cleaned up. However it is not guaranteed that if we call usb_add_function() we also get to the bind function.
Therefore the patch extracts the conditional cleanup from uvc_function_unbind() applies to uvc_function_bind(). uvc_function_unbind() now contains only the complete cleanup which is required once everything has been registrated.
--- drivers/usb/gadget/f_uvc.c | 39 +++++++++++++++++++++------------------ 1 file changed, 21 insertions(+), 18 deletions(-)
drivers/usb/gadget/f_uvc.c +21 -18
@@ -417,7 +417,6 @@ uvc_register_video(struct uvc_device *uvc)return -ENOMEM ; video->parent = &cdev->gadget->dev; - video->minor =-1 ; video->fops = &uvc_v4l2_fops; video->release = video_device_release;strncpy (video->name, cdev->gadget->name,sizeof (video->name));
@@ -577,23 +576,12 @@ uvc_function_unbind(struct usb_configuration *c, struct usb_function *f)INFO (cdev,"uvc_function_unbind\n" ); -if (uvc->vdev) { -if (uvc->vdev->minor ==-1 ) -video_device_release (uvc->vdev); -else -video_unregister_device (uvc->vdev); - uvc->vdev =NULL ; - } - -if (uvc->control_ep) - uvc->control_ep->driver_data =NULL ; -if (uvc->video.ep) - uvc->video.ep->driver_data =NULL ; +video_unregister_device (uvc->vdev); + uvc->control_ep->driver_data =NULL ; + uvc->video.ep->driver_data =NULL ; -if (uvc->control_req) { -usb_ep_free_request (cdev->gadget->ep0, uvc->control_req); -kfree (uvc->control_buf); - } +usb_ep_free_request (cdev->gadget->ep0, uvc->control_req); +kfree (uvc->control_buf);kfree (f->descriptors);kfree (f->hs_descriptors);
@@ -740,7 +728,22 @@ uvc_function_bind(struct usb_configuration *c, struct usb_function *f)return 0 ; error: -uvc_function_unbind (c, f); +if (uvc->vdev) +video_device_release (uvc->vdev); + +if (uvc->control_ep) + uvc->control_ep->driver_data =NULL ; +if (uvc->video.ep) + uvc->video.ep->driver_data =NULL ; + +if (uvc->control_req) { +usb_ep_free_request (cdev->gadget->ep0, uvc->control_req); +kfree (uvc->control_buf); + } + +kfree (f->descriptors); +kfree (f->hs_descriptors); +kfree (f->ss_descriptors);return ret; }
PATCH 44/173 x86: hpet: Fix masking of MSI interrupts
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jan Beulich <[email protected]>
commit 6acf5a8c931da9d26c8dd77d784daaf07fa2bff0 upstream.
HPET_TN_FSB is not a proper mask bit; it merely toggles between MSI and legacy interrupt delivery. The proper mask bit is HPET_TN_ENABLE, so use both bits when (un)masking the interrupt.
--- arch/x86/kernel/hpet.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/x86/kernel/hpet.c +2 -2
@@ -434,7 +434,7 @@ void hpet_msi_unmask(struct irq_data *data)/* unmask it */ cfg =hpet_readl (HPET_Tn_CFG (hdev->num)); - cfg |=HPET_TN_FSB ; + cfg |=HPET_TN_ENABLE |HPET_TN_FSB ;hpet_writel (cfg,HPET_Tn_CFG (hdev->num)); }
@@ -445,7 +445,7 @@ void hpet_msi_mask(struct irq_data *data)/* mask it */ cfg =hpet_readl (HPET_Tn_CFG (hdev->num)); - cfg &= ~HPET_TN_FSB ; + cfg &= ~(HPET_TN_ENABLE |HPET_TN_FSB );hpet_writel (cfg,HPET_Tn_CFG (hdev->num)); }
PATCH 45/173 usb: musb: cppi_dma: export cppi_interrupt()
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sergei Shtylyov <[email protected]>
commit 8b416b0b25d5d8ddb3a91c1d20e1373582c50405 upstream.
Now that DaVinci glue layer can be modular, we must export cppi_interrupt() that it may call...
--- drivers/usb/musb/cppi_dma.c | 1 + 1 file changed, 1 insertion(+)
drivers/usb/musb/cppi_dma.c +1 -0
@@ -1313,6 +1313,7 @@ irqreturn_t cppi_interrupt(int irq, voidreturn IRQ_HANDLED ; } +EXPORT_SYMBOL_GPL (cppi_interrupt);/* Instantiate a software object representing a DMA controller. */ struct dma_controller *__init
PATCH 46/173 nfs: fix wrong object type in lockowner_slab
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yanchuan Nian <[email protected]>
commit 3c40794b2dd0f355ef4e6bf8d85af5dcd7da7ece upstream.
The object type in the cache of lockowner_slab is wrong, and it is better to fix it.
--- fs/nfsd/nfs4state.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/nfsd/nfs4state.c +1 -1
@@ -2340,7 +2340,7 @@ nfsd4_init_slabs(void)if (openowner_slab ==NULL ) goto out_nomem; lockowner_slab =kmem_cache_create ("nfsd4_lockowners" , -sizeof (struct nfs4_openowner ),0 ,0 ,NULL ); +sizeof (struct nfs4_lockowner ),0 ,0 ,NULL );if (lockowner_slab ==NULL ) goto out_nomem; file_slab = kmem_cache_create("nfsd4_files",
PATCH 47/173 iscsi-target: Always send a response before terminating iSCSI connection
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Roland Dreier <[email protected]>
commit 1c5c12c666fda27c7c494b34934a0a0631a48130 upstream.
There are some cases, for example when the initiator sends an out-of-bounds ErrorRecoveryLevel value, where the iSCSI target terminates the connection without sending back any error. Audit the login path and add appropriate iscsit_tx_login_rsp() calls to make sure this doesn't happen.
--- drivers/target/iscsi/iscsi_target_login.c | 8 ++++---- drivers/target/iscsi/iscsi_target_nego.c | 10 ++++++++-- 2 files changed, 12 insertions(+), 6 deletions(-)
drivers/target/iscsi/iscsi_target_login.c +4 -4
@@ -130,13 +130,13 @@ int iscsi_check_for_session_reinstatemen initiatorname_param =iscsi_find_param_from_key (INITIATORNAME , conn->param_list); -if (!initiatorname_param) -return -1 ; - sessiontype_param =iscsi_find_param_from_key (SESSIONTYPE , conn->param_list); -if (!sessiontype_param) +if (!initiatorname_param || !sessiontype_param) { +iscsit_tx_login_rsp (conn,ISCSI_STATUS_CLS_INITIATOR_ERR , +ISCSI_LOGIN_STATUS_MISSING_FIELDS );return -1 ; + } sessiontype = (strncmp (sessiontype_param->value,NORMAL ,6 )) ?1 :0 ;
drivers/target/iscsi/iscsi_target_nego.c +8 -2
@@ -632,8 +632,11 @@ static int iscsi_target_handle_csg_one(s login->req_buf, payload_length, conn->param_list); -if (ret <0 ) +if (ret <0 ) { +iscsit_tx_login_rsp (conn,ISCSI_STATUS_CLS_INITIATOR_ERR , +ISCSI_LOGIN_STATUS_INIT_ERR );return -1 ; + }if (login->first_request)if (iscsi_target_check_first_request (conn, login) <0 )
@@ -648,8 +651,11 @@ static int iscsi_target_handle_csg_one(s login->rsp_buf, &login->rsp_length, conn->param_list); -if (ret <0 ) +if (ret <0 ) { +iscsit_tx_login_rsp (conn,ISCSI_STATUS_CLS_INITIATOR_ERR , +ISCSI_LOGIN_STATUS_INIT_ERR );return -1 ; + }if (!login->auth_complete &&ISCSI_TPG_ATTRIB (ISCSI_TPG_C (conn))->authentication) {
PATCH 48/173 ext4: fix memory leak in ext4_xattr_set_acl()s error path
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eugene Shatokhin <[email protected]>
commit 24ec19b0ae83a385ad9c55520716da671274b96c upstream.
In ext4_xattr_set_acl(), if ext4_journal_start() returns an error, posix_acl_release() will not be called for 'acl' which may result in a memory leak.
This patch fixes that.
--- fs/ext4/acl.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
fs/ext4/acl.c +4 -2
@@ -423,8 +423,10 @@ ext4_xattr_set_acl(struct dentry *dentry, const char *name, const void *value, retry: handle =ext4_journal_start (inode,EXT4_DATA_TRANS_BLOCKS (inode->i_sb)); -if (IS_ERR (handle)) -return PTR_ERR (handle); +if (IS_ERR (handle)) { + error =PTR_ERR (handle); + goto release_and_out; + } error =ext4_set_acl (handle, inode, type, acl);ext4_journal_stop (handle);if (error == -ENOSPC &&ext4_should_retry_alloc (inode->i_sb, &retries))
PATCH 49/173 ARM: mm: use pteval_t to represent page protection values
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Will Deacon <[email protected]>
commit 864aa04cd02979c2c755cb28b5f4fe56039171c0 upstream.
When updating the page protection map after calculating the user_pgprot value, the base protection map is temporarily stored in an unsigned long type, causing truncation of the protection bits when LPAE is enabled. This effectively means that calls to mprotect() will corrupt the upper page attributes, clearing the XN bit unconditionally.
This patch uses pteval_t to store the intermediate protection values, preserving the upper bits for 64-bit descriptors.
--- arch/arm/mm/mmu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/mm/mmu.c +1 -1
@@ -475,7 +475,7 @@ static void __init build_mem_type_table( }for (i =0 ; i <16 ; i++) { -unsigned long v =pgprot_val (protection_map[i]); +pteval_t v =pgprot_val (protection_map[i]); protection_map[i] =__pgprot (v | user_pgprot); }
PATCH 50/173 USB: fix endpoint-disabling for failed config changes
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alan Stern <[email protected]>
commit 36caff5d795429c572443894e8789c2150dd796b upstream.
This patch (as1631) fixes a bug that shows up when a config change fails for a device under an xHCI controller. The controller needs to be told to disable the endpoints that have been enabled for the new config. The existing code does this, but before storing the information about which endpoints were enabled! As a result, any second attempt to install the new config is doomed to fail because xhci-hcd will refuse to enable an endpoint that is already enabled.
The patch optimistically initializes the new endpoints' device structures before asking the device to switch to the new config. If the request fails then the endpoint information is already stored, so we can use usb_hcd_alloc_bandwidth() to disable the endpoints with no trouble. The rest of the error path is slightly more complex now; we have to disable the new interfaces and call put_device() rather than simply deallocating them.
--- drivers/usb/core/message.c | 54 +++++++++++++++++++++++++------------------- 1 file changed, 31 insertions(+), 23 deletions(-)
drivers/usb/core/message.c +31 -22
@@ -1770,28 +1770,8 @@ free_interfaces: goto free_interfaces; } - ret =usb_control_msg (dev,usb_sndctrlpipe (dev,0 ), -USB_REQ_SET_CONFIGURATION ,0 , configuration,0 , -NULL ,0 ,USB_CTRL_SET_TIMEOUT ); -if (ret <0 ) { -/* All the old state is gone, so what else can we do? -* The device is probably useless now anyway. -*/ - cp =NULL ; - } - - dev->actconfig = cp; -if (!cp) { -usb_set_device_state (dev,USB_STATE_ADDRESS ); -usb_hcd_alloc_bandwidth (dev,NULL ,NULL ,NULL ); -mutex_unlock (hcd->bandwidth_mutex); -usb_autosuspend_device (dev); - goto free_interfaces; - } -mutex_unlock (hcd->bandwidth_mutex); -usb_set_device_state (dev,USB_STATE_CONFIGURED ); - -/* Initialize the new interface structures and the +/* +* Initialize the new interface structures and the * hc/hcd/usbcore interface/endpoint state. */ for (i =0 ; i < nintf; ++i) {
@@ -1835,6 +1815,35 @@ free_interfaces: }kfree (new_interfaces); + ret =usb_control_msg (dev,usb_sndctrlpipe (dev,0 ), +USB_REQ_SET_CONFIGURATION ,0 , configuration,0 , +NULL ,0 ,USB_CTRL_SET_TIMEOUT ); +if (ret <0 && cp) { +/* +* All the old state is gone, so what else can we do? +* The device is probably useless now anyway. +*/ +usb_hcd_alloc_bandwidth (dev,NULL ,NULL ,NULL ); +for (i =0 ; i < nintf; ++i) { +usb_disable_interface (dev, cp->interface[i], true); +put_device (&cp->interface[i]->dev); + cp->interface[i] =NULL ; + } + cp =NULL ; + } + + dev->actconfig = cp; +mutex_unlock (hcd->bandwidth_mutex); + +if (!cp) { +usb_set_device_state (dev,USB_STATE_ADDRESS ); + +/* Leave LPM disabled while the device is unconfigured. */ +usb_autosuspend_device (dev); +return ret; + } +usb_set_device_state (dev,USB_STATE_CONFIGURED ); +if (cp->string ==NULL && !(dev->quirks &USB_QUIRK_CONFIG_INTF_STRINGS )) cp->string =usb_cache_string (dev, cp->desc.iConfiguration);
PATCH 51/173 USB: EHCI: bugfix: urb->hcpriv should not be NULL
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alan Stern <[email protected]>
commit 2656a9abcf1ec8dd5fee6a75d6997a0f2fa0094e upstream.
This patch (as1632b) fixes a bug in ehci-hcd. The USB core uses urb->hcpriv to determine whether or not an URB is active; host controller drivers are supposed to set this pointer to a non-NULL value when an URB is queued. However ehci-hcd sets it to NULL for isochronous URBs, which defeats the check in usbcore.
In itself this isn't a big deal. But people have recently found that certain sequences of actions will cause the snd-usb-audio driver to reuse URBs without waiting for them to complete. In the absence of proper checking by usbcore, the URBs get added to their endpoint list twice. This leads to list corruption and a system freeze.
The patch makes ehci-hcd assign a meaningful value to urb->hcpriv for isochronous URBs. Improving robustness always helps.
[bwh: Backported to 3.2:
- Adjust context
- Also use usb_pipetype() to work out whether we should call qh_put()]
--- drivers/usb/host/ehci-q.c | 12 +++--------- drivers/usb/host/ehci-sched.c | 4 ++-- 2 files changed, 5 insertions(+), 11 deletions(-)
drivers/usb/host/ehci-q.c +6 -10
@@ -264,18 +264,14 @@ ehci_urb_done(struct ehci_hcd *ehci, str __releases(ehci->lock) __acquires(ehci->lock) { -if (likely (urb->hcpriv !=NULL )) { -struct ehci_qh *qh = (struct ehci_qh *) urb->hcpriv; - -/* S-mask in a QH means it's an interrupt urb */ -if ((qh->hw->hw_info2 &cpu_to_hc32 (ehci,QH_SMASK )) !=0 ) { - -/* ... update hc-wide periodic stats (for usbfs) */ -ehci_to_hcd (ehci)->self.bandwidth_int_reqs--; - } -qh_put (qh); +if (usb_pipetype (urb->pipe) ==PIPE_INTERRUPT ) { +/* ... update hc-wide periodic stats */ +ehci_to_hcd (ehci)->self.bandwidth_int_reqs--; } +if (usb_pipetype (urb->pipe) !=PIPE_ISOCHRONOUS ) +qh_put ((struct ehci_qh *) urb->hcpriv); +if (unlikely (urb->unlinked)) {COUNT (ehci->stats.unlink); }else {
drivers/usb/host/ehci-sched.c +2 -2
@@ -1684,7 +1684,7 @@ itd_link_urb (/* don't need that schedule data any more */ iso_sched_free (stream, iso_sched); - urb->hcpriv =NULL ; + urb->hcpriv = stream;timer_action (ehci,TIMER_IO_WATCHDOG );return enable_periodic (ehci);
@@ -2094,7 +2094,7 @@ sitd_link_urb (/* don't need that schedule data any more */ iso_sched_free (stream, sched); - urb->hcpriv =NULL ; + urb->hcpriv = stream;timer_action (ehci,TIMER_IO_WATCHDOG );return enable_periodic (ehci);
PATCH 52/173 genirq: Always force thread affinity
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Gleixner <[email protected]>
commit 04aa530ec04f61875b99c12721162e2964e3318c upstream.
Sankara reported that the genirq core code fails to adjust the affinity of an interrupt thread in several cases:
1) On request/setup_irq() the call to setup_affinity() happens before the new action is registered, so the new thread is not notified.
2) For secondary shared interrupts nothing notifies the new thread to change its affinity.
3) Interrupts which have the IRQ_NO_BALANCE flag set are not moving the thread either.
Fix this by setting the thread affinity flag right on thread creation time. This ensures that under all circumstances the thread moves to the right place. Requires a check in irq_thread_check_affinity for an existing affinity mask (CONFIG_CPU_MASK_OFFSTACK=y)
--- kernel/irq/manage.c | 23 +++++++++++++++++++++-- 1 file changed, 21 insertions(+), 2 deletions(-)
kernel/irq/manage.c +21 -2
@@ -732,6 +732,7 @@ static void irq_thread_check_affinity(struct irq_desc *desc, struct irqaction *action) { cpumask_var_t mask; +bool valid = true;if (!test_and_clear_bit (IRQTF_AFFINITY , &action->thread_flags))return ;
@@ -746,10 +747,18 @@ irq_thread_check_affinity(struct irq_desc *desc, struct irqaction *action) }raw_spin_lock_irq (&desc->lock); -cpumask_copy (mask, desc->irq_data.affinity); +/* +* This code is triggered unconditionally. Check the affinity +* mask pointer. For CPU_MASK_OFFSTACK=n this is optimized out. +*/ +if (desc->irq_data.affinity) +cpumask_copy (mask, desc->irq_data.affinity); +else + valid = false;raw_spin_unlock_irq (&desc->lock); -set_cpus_allowed_ptr (current, mask); +if (valid) +set_cpus_allowed_ptr (current, mask);free_cpumask_var (mask); }#else
@@ -954,6 +963,16 @@ __setup_irq(unsigned int irq, struct irq_desc *desc, struct irqaction *new)*/ get_task_struct (t); new->thread = t; +/* +* Tell the thread to set its affinity. This is +* important for shared interrupt handlers as we do +* not invoke setup_affinity() for the secondary +* handlers as everything is already set up. Even for +* interrupts marked with IRQF_NO_BALANCE this is +* correct as we want the thread to move to the cpu(s) +* on which the requesting code placed the interrupt. +*/ +set_bit (IRQTF_AFFINITY , &new->thread_flags); }if (!alloc_cpumask_var (&mask,GFP_KERNEL )) {
PATCH 53/173 xhci: Fix conditional check in bandwidth calculation.
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sarah Sharp <[email protected]>
commit 392a07ae3316f2b90b39ce41e66d6f6b5c95de90 upstream.
David reports that at drivers/usb/host/xhci.c:2257:
static bool xhci_is_sync_in_ep(unsigned int ep_type)
{
return (ep_type == ISOC_IN_EP || ep_type != INT_IN_EP);
}The static analyser cppcheck says
[linux-3.7-rc2/drivers/usb/host/xhci.c:2257]: (style) Redundant condition: If ep_type == 5, the comparison ep_type != 7 is always true.
Maybe the original programmer intention was something like
static bool xhci_is_sync_in_ep(unsigned int ep_type)
{
return (ep_type == ISOC_IN_EP || ep_type == INT_IN_EP);
}Fix this.
This patch should be backported to stable kernels as old as 3.2, that contain the commit 2b69899934c63b7b9432568584fb4c4a2924f40c "xhci: USB 3.0 BW checking."
--- drivers/usb/host/xhci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/host/xhci.c +1 -1
@@ -2255,7 +2255,7 @@ static bool xhci_is_async_ep(unsigned int ep_type)static bool xhci_is_sync_in_ep (unsigned int ep_type) { -return (ep_type ==ISOC_IN_EP || ep_type !=INT_IN_EP ); +return (ep_type ==ISOC_IN_EP || ep_type ==INT_IN_EP ); }static unsigned int xhci_get_ss_bw_consumed (struct xhci_bw_info *ep_bw)
PATCH 54/173 xHCI: Fix TD Size calculation on 1.0 hosts.
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sarah Sharp <[email protected]>
commit 4525c0a10dff7ad3669763c28016c7daffc3900e upstream.
The xHCI 1.0 specification made a change to the TD Size field in TRBs. The value is now the number of packets that remain to be sent in the TD, not including this TRB. The TD Size value for the last TRB in a TD must always be zero.
The xHCI function xhci_v1_0_td_remainder() attempts to calculate this, but it gets it wrong. First, it erroneously reuses the old xhci_td_remainder function, which will right shift the value by 10. The xHCI 1.0 spec as of June 2011 says nothing about right shifting by 10. Second, it does not set the TD size for the last TRB in a TD to zero.
Third, it uses roundup instead of DIV_ROUND_UP. The total packet count is supposed to be the total number of bytes in this TD, divided by the max packet size, rounded up. DIV_ROUND_UP is the right function to use in that case.
With the old code, a TD on an endpoint with max packet size 1024 would be set up like so:
TRB 1, TRB length = 600 bytes, TD size = 0
TRB 1, TRB length = 200 bytes, TD size = 0
TRB 1, TRB length = 100 bytes, TD size = 0
With the new code, the TD would be set up like this:
TRB 1, TRB length = 600 bytes, TD size = 1 TRB 1, TRB length = 200 bytes, TD size = 1 TRB 1, TRB length = 100 bytes, TD size = 0
This commit should be backported to kernels as old as 3.0, that contain the commit 4da6e6f247a2601ab9f1e63424e4d944ed4124f3 "xhci 1.0: Update TD size field format."
--- drivers/usb/host/xhci-ring.c | 32 +++++++++++++++++++------------- 1 file changed, 19 insertions(+), 13 deletions(-)
drivers/usb/host/xhci-ring.c +19 -13
@@ -3071,11 +3071,11 @@ static u32 xhci_td_remainder(unsigned int remainder) }/* -* For xHCI 1.0 host controllers, TD size is the number of packets remaining in -* the TD (*not* including this TRB). +* For xHCI 1.0 host controllers, TD size is the number of max packet sized +* packets remaining in the TD (*not* including this TRB). * * Total TD packet count = total_packet_count = -* roundup(TD size in bytes / wMaxPacketSize) +* DIV_ROUND_UP(TD size in bytes / wMaxPacketSize) * * Packets transferred up to and including this TRB = packets_transferred = * rounddown(total bytes transferred including this TRB / wMaxPacketSize)
@@ -3083,15 +3083,16 @@ static u32 xhci_td_remainder(unsigned int remainder)* TD size = total_packet_count - packets_transferred * * It must fit in bits 21:17, so it can't be bigger than 31. +* The last TRB in a TD must have the TD size set to zero. */ -static u32 xhci_v1_0_td_remainder (int running_total,int trb_buff_len, -unsigned int total_packet_count,struct urb *urb) +unsigned int total_packet_count,struct urb *urb, +unsigned int num_trbs_left) {int packets_transferred;/* One TRB with a zero-length data packet. */ -if (running_total ==0 && trb_buff_len ==0 ) +if (num_trbs_left ==0 || (running_total ==0 && trb_buff_len ==0 ))return 0 ;/* All the TRB queueing functions don't count the current TRB in
@@ -3100,7 +3101,9 @@ static u32 xhci_v1_0_td_remainder(int running_total, int trb_buff_len, packets_transferred = (running_total + trb_buff_len) /usb_endpoint_maxp (&urb->ep->desc); -return xhci_td_remainder (total_packet_count - packets_transferred); +if ((total_packet_count - packets_transferred) >31 ) +return 31 <<17 ; +return (total_packet_count - packets_transferred) <<17 ; } static int queue_bulk_sg_tx(struct xhci_hcd *xhci, gfp_t mem_flags,
@@ -3127,7 +3130,7 @@ static int queue_bulk_sg_tx(struct xhci_hcd *xhci, gfp_t mem_flags, num_trbs =count_sg_trbs_needed (xhci, urb); num_sgs = urb->num_mapped_sgs; - total_packet_count =roundup (urb->transfer_buffer_length, + total_packet_count =DIV_ROUND_UP (urb->transfer_buffer_length,usb_endpoint_maxp (&urb->ep->desc)); trb_buff_len = prepare_transfer(xhci, xhci->devs[slot_id],
@@ -3210,7 +3213,8 @@ static int queue_bulk_sg_tx(struct xhci_hcd *xhci, gfp_t mem_flags, running_total); }else { remainder =xhci_v1_0_td_remainder (running_total, - trb_buff_len, total_packet_count, urb); + trb_buff_len, total_packet_count, urb, + num_trbs -1 ); } length_field =TRB_LEN (trb_buff_len) | remainder |
@@ -3318,7 +3322,7 @@ int xhci_queue_bulk_tx(struct xhci_hcd *xhci, gfp_t mem_flags, start_cycle = ep_ring->cycle_state; running_total =0 ; - total_packet_count =roundup (urb->transfer_buffer_length, + total_packet_count =DIV_ROUND_UP (urb->transfer_buffer_length,usb_endpoint_maxp (&urb->ep->desc));/* How much data is in the first TRB? */ addr = (u64 ) urb->transfer_dma;
@@ -3364,7 +3368,8 @@ int xhci_queue_bulk_tx(struct xhci_hcd *xhci, gfp_t mem_flags, running_total); }else { remainder =xhci_v1_0_td_remainder (running_total, - trb_buff_len, total_packet_count, urb); + trb_buff_len, total_packet_count, urb, + num_trbs -1 ); } length_field =TRB_LEN (trb_buff_len) | remainder |
@@ -3627,7 +3632,7 @@ static int xhci_queue_isoc_tx(struct xhci_hcd *xhci, gfp_t mem_flags, addr = start_addr + urb->iso_frame_desc[i].offset; td_len = urb->iso_frame_desc[i].length; td_remain_len = td_len; - total_packet_count =roundup (td_len, + total_packet_count =DIV_ROUND_UP (td_len,usb_endpoint_maxp (&urb->ep->desc));/* A zero-length transfer still involves at least one packet. */ if (total_packet_count ==0 )
@@ -3706,7 +3711,8 @@ static int xhci_queue_isoc_tx(struct xhci_hcd *xhci, gfp_t mem_flags, }else { remainder =xhci_v1_0_td_remainder ( running_total, trb_buff_len, - total_packet_count, urb); + total_packet_count, urb, + (trbs_per_td - j -1 )); } length_field =TRB_LEN (trb_buff_len) | remainder |
PATCH 55/173 xhci: fix null-pointer dereference when destroying half-built segment rings
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Julius Werner <[email protected]>
commit 68e5254adb88bede68285f11fb442a4d34fb550c upstream.
xhci_alloc_segments_for_ring() builds a list of xhci_segments and links the tail to head at the end (forming a ring). When it bails out for OOM reasons half-way through, it tries to destroy its half-built list with xhci_free_segments_for_ring(), even though it is not a ring yet. This causes a null-pointer dereference upon hitting the last element.
Furthermore, one of its callers (xhci_ring_alloc()) mistakenly believes the output parameters to be valid upon this kind of OOM failure, and calls xhci_ring_free() on them. Since the (incomplete) list/ring should already be destroyed in that case, this would lead to a use after free.
This patch fixes those issues by having xhci_alloc_segments_for_ring() destroy its half-built, non-circular list manually and destroying the invalid struct xhci_ring in xhci_ring_alloc() with a plain kfree().
This patch should be backported to kernels as old as 2.6.31, that contains the commit 0ebbab37422315a5d0cb29792271085bafdf38c0 "USB: xhci:
Ring allocation and initialization."
A separate patch will need to be developed for kernels older than 3.4, since the ring allocation code was refactored in that kernel.
[bwh: Backported to 3.2:
- Adjust context
- Since segment allocation is done directly in xhci_ring_alloc(), walk the list starting from ring->first_seg when freeing]
---
drivers/usb/host/xhci-mem.c +9 -2
@@ -178,8 +178,15 @@ static struct xhci_ring *xhci_ring_allocstruct xhci_segment *next; next =xhci_segment_alloc (xhci, flags); -if (!next) +if (!next) { + prev = ring->first_seg; +while (prev) { + next = prev->next; +xhci_segment_free (xhci, prev); + prev = next; + } goto fail; + }xhci_link_segments (xhci, prev, next, link_trbs, isoc); prev = next;
@@ -199,7 +206,7 @@ static struct xhci_ring *xhci_ring_allocreturn ring; fail: -xhci_ring_free (xhci, ring); +kfree (ring);return NULL ; }
PATCH 56/173 xhci: Extend Fresco Logic MSI quirk.
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sarah Sharp <[email protected]>
commit bba18e33f25072ebf70fd8f7f0cdbf8cdb59a746 upstream.
Ali reports that plugging a device into the Fresco Logic xHCI host with PCI device ID 1400 produces an IRQ error:
do_IRQ: 3.176 No irq handler for vector (irq -1)
Other early Fresco Logic host revisions don't support MSI, even though their PCI config space claims they do. Extend the quirk to disabling MSI to this chipset revision. Also enable the short transfer quirk, since it's likely this revision also has that quirk, and it should be harmless to enable.
04:00.0 0c03: 1b73:1400 (rev 01) (prog-if 30 [XHCI])
Subsystem: 1d5c:1000
Physical Slot: 3
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 51
Region 0: Memory at d4600000 (32-bit, non-prefetchable) [size=64K]
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [68] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000feeff00c Data: 41b1
Capabilities: [80] Express (v1) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <2us, L1 <32us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 unlimited, L1 unlimited
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
Kernel driver in use: xhci_hcd
This patch should be backported to stable kernels as old as 2.6.36, that contain the commit f5182b4155b9d686c5540a6822486400e34ddd98 "xhci:
Disable MSI for some Fresco Logic hosts."
--- drivers/usb/host/xhci-pci.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
drivers/usb/host/xhci-pci.c +5 -2
@@ -29,6 +29,7 @@/* Device for a quirk */ #define PCI_VENDOR_ID_FRESCO_LOGIC 0x1b73#define PCI_DEVICE_ID_FRESCO_LOGIC_PDK 0x1000 +#define PCI_DEVICE_ID_FRESCO_LOGIC_FL1400 0x1400#define PCI_VENDOR_ID_ETRON 0x1b6f#define PCI_DEVICE_ID_ASROCK_P67 0x7023
@@ -58,8 +59,10 @@ static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci)/* Look for vendor-specific quirks */ if (pdev->vendor ==PCI_VENDOR_ID_FRESCO_LOGIC && - pdev->device ==PCI_DEVICE_ID_FRESCO_LOGIC_PDK ) { -if (pdev->revision ==0x0 ) { + (pdev->device ==PCI_DEVICE_ID_FRESCO_LOGIC_PDK || + pdev->device ==PCI_DEVICE_ID_FRESCO_LOGIC_FL1400 )) { +if (pdev->device ==PCI_DEVICE_ID_FRESCO_LOGIC_PDK && + pdev->revision ==0x0 ) { xhci->quirks |=XHCI_RESET_EP_QUIRK ;xhci_dbg (xhci,"QUIRK: Fresco Logic xHC needs configure" " endpoint cmd after reset endpoint\n" );
PATCH 57/173 usb: host: xhci: Stricter conditional for Z1 system models for Compliance Mode Patch
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Alexis R. Cortes" <[email protected]>
commit b0e4e606ff6ff26da0f60826e75577b56ba4e463 upstream.
This minor patch creates a more stricter conditional for the Z1 sytems for applying the Compliance Mode Patch, this to avoid the quirk to be applied to models that contain a "Z1" in their dmi product string but are different from Z1 systems.
This patch should be backported to stable kernels as old as 3.2, that contain the commit 71c731a296f1b08a3724bd1b514b64f1bda87a23 "usb: host:
xhci: Fix Compliance Mode on SN65LVPE502CP Hardware"
--- drivers/usb/host/xhci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/host/xhci.c +1 -1
@@ -480,7 +480,7 @@ static bool compliance_mode_recovery_timer_quirk_check(void)if (strstr (dmi_product_name,"Z420" ) ||strstr (dmi_product_name,"Z620" ) ||strstr (dmi_product_name,"Z820" ) || -strstr (dmi_product_name,"Z1" )) +strstr (dmi_product_name,"Z1 Workstation" ))return true;return false;
PATCH 58/173 Staging: bcm: Create and initialize new device id in InterfaceInit
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kevin McKinney <[email protected]>
commit e66fc1fba248738d32f3b64508f9ef1176d9e767 upstream.
This patch create and initalizes a new device
id of 0x172 as reported by Rinat Camalov
<[email protected]>. In addition, a
comment is added to the potential invalid
existing device id.
--- drivers/staging/bcm/InterfaceInit.c | 1 + drivers/staging/bcm/InterfaceInit.h | 3 ++- 2 files changed, 3 insertions(+), 1 deletion(-)
drivers/staging/bcm/InterfaceInit.c +1 -0
@@ -8,6 +8,7 @@ static struct usb_device_id InterfaceUsb { USB_DEVICE(BCM_USB_VENDOR_ID_ZTE, BCM_USB_PRODUCT_ID_226) }, { USB_DEVICE(BCM_USB_VENDOR_ID_FOXCONN, BCM_USB_PRODUCT_ID_1901) }, { USB_DEVICE(BCM_USB_VENDOR_ID_ZTE, BCM_USB_PRODUCT_ID_ZTE_TU25) }, + { USB_DEVICE(BCM_USB_VENDOR_ID_ZTE, BCM_USB_PRODUCT_ID_ZTE_226) }, { } };MODULE_DEVICE_TABLE (usb, InterfaceUsbtable);
drivers/staging/bcm/InterfaceInit.h +2 -1
@@ -11,7 +11,8 @@#define BCM_USB_PRODUCT_ID_SM250 0xbccd#define BCM_USB_PRODUCT_ID_SYM 0x15E#define BCM_USB_PRODUCT_ID_1901 0xe017 -#define BCM_USB_PRODUCT_ID_226 0x0132 +#define BCM_USB_PRODUCT_ID_226 0x0132/* not sure if this is valid */ +#define BCM_USB_PRODUCT_ID_ZTE_226 0x172#define BCM_USB_PRODUCT_ID_ZTE_TU25 0x0007#define BCM_USB_MINOR_BASE 192
PATCH 59/173 Staging: bcm: Add two products and remove an existing product.
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kevin McKinney <[email protected]>
commit 4f29ef050848245f7c180b95ccf67dfcd76b1fd8 upstream.
This patch adds two new products and modifies
the device id table to include them. In addition,
product of 0xbccd - BCM_USB_PRODUCT_ID_SM250 is
removed because Beceem, ZTE, Sprint use this id
for block devices.
--- drivers/staging/bcm/InterfaceInit.c | 3 ++- drivers/staging/bcm/InterfaceInit.h | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-)
drivers/staging/bcm/InterfaceInit.c +2 -1
@@ -4,11 +4,12 @@ static struct usb_device_id InterfaceUsb { USB_DEVICE(BCM_USB_VENDOR_ID_T3, BCM_USB_PRODUCT_ID_T3) }, { USB_DEVICE(BCM_USB_VENDOR_ID_T3, BCM_USB_PRODUCT_ID_T3B) }, { USB_DEVICE(BCM_USB_VENDOR_ID_T3, BCM_USB_PRODUCT_ID_T3L) }, - { USB_DEVICE(BCM_USB_VENDOR_ID_T3, BCM_USB_PRODUCT_ID_SM250) }, + { USB_DEVICE(BCM_USB_VENDOR_ID_T3, BCM_USB_PRODUCT_ID_SYM) }, { USB_DEVICE(BCM_USB_VENDOR_ID_ZTE, BCM_USB_PRODUCT_ID_226) }, { USB_DEVICE(BCM_USB_VENDOR_ID_FOXCONN, BCM_USB_PRODUCT_ID_1901) }, { USB_DEVICE(BCM_USB_VENDOR_ID_ZTE, BCM_USB_PRODUCT_ID_ZTE_TU25) }, { USB_DEVICE(BCM_USB_VENDOR_ID_ZTE, BCM_USB_PRODUCT_ID_ZTE_226) }, + { USB_DEVICE(BCM_USB_VENDOR_ID_ZTE, BCM_USB_PRODUCT_ID_ZTE_326) }, { } };MODULE_DEVICE_TABLE (usb, InterfaceUsbtable);
drivers/staging/bcm/InterfaceInit.h +1 -1
@@ -8,11 +8,11 @@#define BCM_USB_PRODUCT_ID_T3 0x0300#define BCM_USB_PRODUCT_ID_T3B 0x0210#define BCM_USB_PRODUCT_ID_T3L 0x0220 -#define BCM_USB_PRODUCT_ID_SM250 0xbccd#define BCM_USB_PRODUCT_ID_SYM 0x15E#define BCM_USB_PRODUCT_ID_1901 0xe017#define BCM_USB_PRODUCT_ID_226 0x0132/* not sure if this is valid */ #define BCM_USB_PRODUCT_ID_ZTE_226 0x172 +#define BCM_USB_PRODUCT_ID_ZTE_326 0x173/* ZTE AX326 */ #define BCM_USB_PRODUCT_ID_ZTE_TU25 0x0007#define BCM_USB_MINOR_BASE 192
PATCH 60/173 rcu: Fix batch-limit size problem
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
commit 878d7439d0f45a95869e417576774673d1fa243f upstream.
Commit 29c00b4a1d9e27 (rcu: Add event-tracing for RCU callback invocation) added a regression in rcu_do_batch()
Under stress, RCU is supposed to allow to process all items in queue, instead of a batch of 10 items (blimit), but an integer overflow makes the effective limit being 1. So, unless there is frequent idle periods (during which RCU ignores batch limits), RCU can be forced into a state where it cannot keep up with the callback-generation rate, eventually resulting in OOM.
This commit therefore converts a few variables in rcu_do_batch() from int to long to fix this problem, along with the module parameters controlling the batch limits.
[bwh: Backported to 3.2:
- Adjust context
- Module parameters remain hidden from sysfs]
--- kernel/rcutree.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-)
kernel/rcutree.c +8 -8
@@ -202,13 +202,13 @@ DEFINE_PER_CPU(struct rcu_dynticks, rcu_ };#endif /* #ifdef CONFIG_NO_HZ */ -static int blimit =10 ;/* Maximum callbacks per rcu_do_batch. */ -static int qhimark =10000 ;/* If this many pending, ignore blimit. */ -static int qlowmark =100 ;/* Once only this many pending, use blimit. */ - -module_param (blimit, int,0 ); -module_param (qhimark, int,0 ); -module_param (qlowmark, int,0 ); +static long blimit =10 ;/* Maximum callbacks per rcu_do_batch. */ +static long qhimark =10000 ;/* If this many pending, ignore blimit. */ +static long qlowmark =100 ;/* Once only this many pending, use blimit. */ + +module_param (blimit, long,0 ); +module_param (qhimark, long,0 ); +module_param (qlowmark, long,0 );int rcu_cpu_stall_suppress__read_mostly ;module_param (rcu_cpu_stall_suppress, int,0644 );
@@ -1260,7 +1260,7 @@ static void rcu_do_batch(struct rcu_stat {unsigned long flags;struct rcu_head *next, *list, **tail; -int bl, count; +long bl, count;/* If no callbacks are ready, just return.*/ if (!cpu_has_callbacks_ready_to_invoke (rdp)) {
PATCH 61/173 ext4: init pagevec in ext4_da_block_invalidatepages
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Sandeen <[email protected]>
commit 66bea92c69477a75a5d37b9bfed5773c92a3c4b4 upstream.
ext4_da_block_invalidatepages is missing a pagevec_init(), which means that pvec->cold contains random garbage.
This affects whether the page goes to the front or back of the LRU when ->cold makes it to free_hot_cold_page()
--- fs/ext4/inode.c | 1 + 1 file changed, 1 insertion(+)
fs/ext4/inode.c +1 -0
@@ -1422,6 +1422,7 @@ static void ext4_da_block_invalidatepage index = mpd->first_page; end = mpd->next_page -1 ; +pagevec_init (&pvec,0 );while (index <= end) { nr_pages =pagevec_lookup (&pvec, mapping, index,PAGEVEC_SIZE );if (nr_pages ==0 )
PATCH 62/173 powerpc: Fix CONFIG_RELOCATABLE=y CONFIG_CRASH_DUMP=n build
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Anton Blanchard <[email protected]>
commit 11ee7e99f35ecb15f59b21da6a82d96d2cd3fcc8 upstream.
If we build a kernel with CONFIG_RELOCATABLE=y CONFIG_CRASH_DUMP=n, the kernel fails when we run at a non zero offset. It turns out we were incorrectly wrapping some of the relocatable kernel code with CONFIG_CRASH_DUMP.
--- arch/powerpc/kernel/head_64.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/powerpc/kernel/head_64.S +1 -1
@@ -422,7 +422,7 @@ _STATIC(__after_prom_start) tovirt(r6,r6) /* on booke, we already run at PAGE_OFFSET */ #endif -#ifdef CONFIG_CRASH_DUMP +#ifdef CONFIG_RELOCATABLE /* * Check if the kernel has to be running as relocatable kernel based on the * variable __run_at_load, if it is set the kernel is treated as relocatable
PATCH 63/173 ftrace: Clear bits properly in reset_iter_read()
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <[email protected]>
commit 70f77b3f7ec010ff9624c1f2e39a81babc9e2429 upstream.
There is a typo here where '&' is used instead of '|' and it turns the statement into a noop. The original code is equivalent to:
iter->flags &= ~((1 << 2) & (1 << 4));
--- kernel/trace/ftrace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/trace/ftrace.c +1 -1
@@ -2437,7 +2437,7 @@ static void reset_iter_read(struct ftrace_iterator *iter) { iter->pos =0 ; iter->func_pos =0 ; - iter->flags &= ~(FTRACE_ITER_PRINTALL &FTRACE_ITER_HASH ); + iter->flags &= ~(FTRACE_ITER_PRINTALL |FTRACE_ITER_HASH ); }static void *t_start (struct seq_file *m,loff_t *pos)
PATCH 64/173 ACPI / battery: Correct battery capacity values on Thinkpads
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kamil Iskra <[email protected]>
commit 4000e626156935dfb626321ce09cae2c833eabbb upstream.
Add a quirk to correctly report battery capacity on 2010 and 2011 Lenovo Thinkpad models.
The affected models that I tested (x201, t410, t410s, and x220) exhibit a problem where, when battery capacity reporting unit is mAh, the values being reported are wrong. Pre-2010 and 2012 models appear to always report in mWh and are thus unaffected. Also, in mid-2012 Lenovo issued a BIOS update for the 2011 models that fixes the issue (tested on x220 with a post-1.29 BIOS). No such update is available for the 2010 models, so those still need this patch.
Problem description: for some reason, the affected Thinkpads switch the reporting unit between mAh and mWh; generally, mAh is used when a laptop is plugged in and mWh when it's unplugged, although a suspend/resume or rmmod/modprobe is needed for the switch to take effect. The values reported in mAh are *always* wrong. This does not appear to be a kernel regression; I believe that the values were never reported correctly. I tested back to kernel 2.6.34, with multiple machines and BIOS versions.
Simply plugging a laptop into mains before turning it on is enough to reproduce the problem. Here's a sample /proc/acpi/battery/BAT0/info from Thinkpad x220 (before a BIOS update) with a 4-cell battery:
present: yes design capacity: 2886 mAh last full capacity: 2909 mAh battery technology: rechargeable design voltage: 14800 mV design capacity warning: 145 mAh design capacity low: 13 mAh cycle count: 0 capacity granularity 1: 1 mAh capacity granularity 2: 1 mAh model number: 42T4899 serial number: 21064 battery type: LION OEM info: SANYO
Once the laptop switches the unit to mWh (unplug from mains, suspend, resume), the output changes to:
present: yes design capacity: 28860 mWh last full capacity: 29090 mWh battery technology: rechargeable design voltage: 14800 mV design capacity warning: 1454 mWh design capacity low: 200 mWh cycle count: 0 capacity granularity 1: 1 mWh capacity granularity 2: 1 mWh model number: 42T4899 serial number: 21064 battery type: LION OEM info: SANYO
Can you see how the values for "design capacity", etc., differ by a factor of 10 instead of 14.8 (the design voltage of this battery)? On the battery itself it says: 14.8V, 1.95Ah, 29Wh, so clearly the values reported in mWh are correct and the ones in mAh are not.
My guess is that this problem has been around ever since those machines were released, but because the most common Thinkpad batteries are rated at 10.8V, the error (8%) is small enough that it simply hasn't been noticed or at least nobody could be bothered to look into it.
My patch works around the problem by adjusting the incorrectly reported mAh values by "10000 / design_voltage". The patch also has code to figure out if it should be activated or not. It only activates on Lenovo Thinkpads, only when the unit is mAh, and, as an extra precaution, only when the battery capacity reported through ACPI does not match what is reported through DMI (I've never encountered a machine where the first two conditions would be true but the last would not, but better safe than sorry).
I've been using this patch for close to a year on several systems without any problems.
References: https://bugzilla.kernel.org/show_bug.cgi?id=41062
--- drivers/acpi/battery.c | 77 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 77 insertions(+)
drivers/acpi/battery.c +77 -0
@@ -34,6 +34,7 @@#include <linux/dmi.h> #include <linux/slab.h> #include <linux/suspend.h> +#include <asm/unaligned.h> #ifdef CONFIG_ACPI_PROCFS_POWER #include <linux/proc_fs.h>
@@ -95,6 +96,18 @@ enum {ACPI_BATTERY_ALARM_PRESENT ,ACPI_BATTERY_XINFO_PRESENT ,ACPI_BATTERY_QUIRK_PERCENTAGE_CAPACITY , +/* On Lenovo Thinkpad models from 2010 and 2011, the power unit +switches between mWh and mAh depending on whether the system +is running on battery or not. When mAh is the unit, most +reported values are incorrect and need to be adjusted by +10000/design_voltage. Verified on x201, t410, t410s, and x220. +Pre-2010 and 2012 models appear to always report in mWh and +are thus unaffected (tested with t42, t61, t500, x200, x300, +and x230). Also, in mid-2012 Lenovo issued a BIOS update for +the 2011 models that fixes the issue (tested on x220 with a +post-1.29 BIOS), but as of Nov. 2012, no such update is +available for the 2010 models. */ + ACPI_BATTERY_QUIRK_THINKPAD_MAH, }; struct acpi_battery {
@@ -438,6 +451,21 @@ static int acpi_battery_get_info(struct acpi_battery *battery)kfree (buffer.pointer);if (test_bit (ACPI_BATTERY_QUIRK_PERCENTAGE_CAPACITY , &battery->flags)) battery->full_charge_capacity = battery->design_capacity; +if (test_bit (ACPI_BATTERY_QUIRK_THINKPAD_MAH , &battery->flags) && + battery->power_unit && battery->design_voltage) { + battery->design_capacity = battery->design_capacity * +10000 / battery->design_voltage; + battery->full_charge_capacity = battery->full_charge_capacity * +10000 / battery->design_voltage; + battery->design_capacity_warning = + battery->design_capacity_warning * +10000 / battery->design_voltage; +/* Curiously, design_capacity_low, unlike the rest of them, +is correct. */ +/* capacity_granularity_* equal 1 on the systems tested, so +it's impossible to tell if they would need an adjustment +or not if their values were higher. */ + }return result; }
@@ -486,6 +514,11 @@ static int acpi_battery_get_state(struct acpi_battery *battery) && battery->capacity_now >= 0 && battery->capacity_now <= 100) battery->capacity_now = (battery->capacity_now * battery->full_charge_capacity) /100 ; +if (test_bit (ACPI_BATTERY_QUIRK_THINKPAD_MAH , &battery->flags) && + battery->power_unit && battery->design_voltage) { + battery->capacity_now = battery->capacity_now * +10000 / battery->design_voltage; + }return result; }
@@ -595,6 +628,24 @@ static void sysfs_remove_battery(struct acpi_battery *battery)mutex_unlock (&battery->sysfs_lock); } +static void find_battery (const struct dmi_header *dm,void *private) +{ +struct acpi_battery *battery = (struct acpi_battery *)private; +/* Note: the hardcoded offsets below have been extracted from +the source code of dmidecode. */ +if (dm->type ==DMI_ENTRY_PORTABLE_BATTERY && dm->length >=8 ) { +const u8 *dmi_data = (const u8 *)(dm +1 ); +int dmi_capacity =get_unaligned ((const u16 *)(dmi_data +6 )); +if (dm->length >=18 ) + dmi_capacity *= dmi_data[17 ]; +if (battery->design_capacity * battery->design_voltage /1000 + != dmi_capacity && + battery->design_capacity *10 == dmi_capacity) +set_bit (ACPI_BATTERY_QUIRK_THINKPAD_MAH , + &battery->flags); + } +} +/* * According to the ACPI spec, some kinds of primary batteries can * report percentage battery remaining capacity directly to OS.
@@ -620,6 +671,32 @@ static void acpi_battery_quirks(struct acpi_battery *battery) battery->capacity_now = (battery->capacity_now * battery->full_charge_capacity) /100 ; } + +if (test_bit (ACPI_BATTERY_QUIRK_THINKPAD_MAH , &battery->flags)) +return ; + +if (battery->power_unit &&dmi_name_in_vendors ("LENOVO" )) { +const char *s; + s =dmi_get_system_info (DMI_PRODUCT_VERSION ); +if (s && !strnicmp (s,"ThinkPad" ,8 )) { +dmi_walk (find_battery, battery); +if (test_bit (ACPI_BATTERY_QUIRK_THINKPAD_MAH , + &battery->flags) && + battery->design_voltage) { + battery->design_capacity = + battery->design_capacity * +10000 / battery->design_voltage; + battery->full_charge_capacity = + battery->full_charge_capacity * +10000 / battery->design_voltage; + battery->design_capacity_warning = + battery->design_capacity_warning * +10000 / battery->design_voltage; + battery->capacity_now = battery->capacity_now * +10000 / battery->design_voltage; + } + } + } }static int acpi_battery_update (struct acpi_battery *battery)
PATCH 65/173 cgroup: remove incorrect dget/dput() pair in cgroup_create_dir()
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tejun Heo <[email protected]>
commit 175431635ec09b1d1bba04979b006b99e8305a83 upstream.
cgroup_create_dir() does weird dancing with dentry refcnt. On success, it gets and then puts it achieving nothing. On failure, it puts but there isn't no matching get anywhere leading to the following oops if cgroup_create_file() fails for whatever reason.
------------[ cut here ]------------ kernel BUG at /work/os/work/fs/dcache.c:552! invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC Modules linked in: CPU 2 Pid: 697, comm: mkdir Not tainted 3.7.0-rc4-work+ #3 Bochs Bochs RIP: 0010:[<ffffffff811d9c0c>] [<ffffffff811d9c0c>] dput+0x1dc/0x1e0 RSP: 0018:ffff88001a3ebef8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88000e5b1ef8 RCX: 0000000000000403 RDX: 0000000000000303 RSI: 2000000000000000 RDI: ffff88000e5b1f58 RBP: ffff88001a3ebf18 R08: ffffffff82c76960 R09: 0000000000000001 R10: ffff880015022080 R11: ffd9bed70f48a041 R12: 00000000ffffffea R13: 0000000000000001 R14: ffff88000e5b1f58 R15: 00007fff57656d60 FS: 00007ff05fcb3800(0000) GS:ffff88001fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000004046f0 CR3: 000000001315f000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process mkdir (pid: 697, threadinfo ffff88001a3ea000, task ffff880015022080) Stack: ffff88001a3ebf48 00000000ffffffea 0000000000000001 0000000000000000 ffff88001a3ebf38 ffffffff811cc889 0000000000000001 ffff88000e5b1ef8 ffff88001a3ebf68 ffffffff811d1fc9 ffff8800198d7f18 ffff880019106ef8 Call Trace: [<ffffffff811cc889>] done_path_create+0x19/0x50 [<ffffffff811d1fc9>] sys_mkdirat+0x59/0x80 [<ffffffff811d2009>] sys_mkdir+0x19/0x20 [<ffffffff81be1e02>] system_call_fastpath+0x16/0x1b Code: 00 48 8d 90 18 01 00 00 48 89 93 c0 00 00 00 4c 89 a0 18 01 00 00 48 8b 83 a0 00 00 00 83 80 28 01 00 00 01 e8 e6 6f a0 00 eb 92 <0f> 0b 66 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 49 89 fe 41 RIP [<ffffffff811d9c0c>] dput+0x1dc/0x1e0 RSP <ffff88001a3ebef8> ---[ end trace 1277bcfd9561ddb0 ]---
Fix it by dropping the unnecessary dget/dput() pair.
--- kernel/cgroup.c | 2 -- 1 file changed, 2 deletions(-)
kernel/cgroup.c +0 -2
@@ -2684,9 +2684,7 @@ static int cgroup_create_dir(struct cgroup *cgrp, struct dentry *dentry, dentry->d_fsdata = cgrp;inc_nlink (parent->d_inode);rcu_assign_pointer (cgrp->dentry, dentry); -dget (dentry); } -dput (dentry);return error; }
PATCH 66/173 Bluetooth: Add support for BCM20702A0 [04ca, 2003]
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jaroslav Resler <[email protected]>
commit 0c1abbd1aa0416258881c303a88e618cbca0759c upstream.
Add another vendor specific ID for BCM20702A0.
output of usb-devices:
T: Bus=01 Lev=02 Prnt=02 Port=03 Cnt=02 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=04ca ProdID=2003 Rev= 1.12 S: Manufacturer=Broadcom Corp S: Product=BCM20702A0 S: SerialNumber=446D57861623 C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=84(I) Atr=02(Bulk) MxPS= 32 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 32 Ivl=0ms
I:* If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)
--- drivers/bluetooth/btusb.c | 1 + 1 file changed, 1 insertion(+)
drivers/bluetooth/btusb.c +1 -0
@@ -104,6 +104,7 @@ static struct usb_device_id btusb_table[ { USB_DEVICE(0x0c10, 0x0000) },/* Broadcom BCM20702A0 */ + { USB_DEVICE(0x04ca, 0x2003) }, { USB_DEVICE(0x0489, 0xe042) }, { USB_DEVICE(0x413c, 0x8197) },
PATCH 67/173 Bluetooth: ath3k: Add support for VAIO VPCEH [0489:e027]
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marcos Chaparro <[email protected]>
commit acd9454433e28c1a365d8b069813c35c1c3a8ac3 upstream.
Added Atheros AR3011 internal bluetooth device found in Sony VAIO VPCEH to the devices list.
Before this, the bluetooth module was identified as an Foxconn / Hai bluetooth device [0489:e027], now it claims to be an AtherosAR3011 Bluetooth [0cf3:3005].
T: Bus=01 Lev=02 Prnt=02 Port=04 Cnt=02 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0489 ProdID=e027 Rev= 0.01 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
--- drivers/bluetooth/ath3k.c | 1 + drivers/bluetooth/btusb.c | 1 + 2 files changed, 2 insertions(+)
drivers/bluetooth/ath3k.c +1 -0
@@ -67,6 +67,7 @@ static struct usb_device_id ath3k_table[] = { { USB_DEVICE(0x13d3, 0x3304) }, { USB_DEVICE(0x0930, 0x0215) }, { USB_DEVICE(0x0489, 0xE03D) }, + { USB_DEVICE(0x0489, 0xE027) },/* Atheros AR9285 Malbec with sflash firmware */ { USB_DEVICE(0x03F0, 0x311D) },
drivers/bluetooth/btusb.c +1 -0
@@ -124,6 +124,7 @@ static struct usb_device_id blacklist_table[] = { { USB_DEVICE(0x13d3, 0x3304), .driver_info = BTUSB_IGNORE }, { USB_DEVICE(0x0930, 0x0215), .driver_info = BTUSB_IGNORE }, { USB_DEVICE(0x0489, 0xe03d), .driver_info = BTUSB_IGNORE }, + { USB_DEVICE(0x0489, 0xe027), .driver_info = BTUSB_IGNORE }, /* Atheros AR9285 Malbec with sflash firmware */ { USB_DEVICE(0x03f0, 0x311d), .driver_info = BTUSB_IGNORE },
PATCH 68/173 Bluetooth: Add support for BCM20702A0 [0b05, 17b5]
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jeff Cook <[email protected]>
commit 1ee3ff6110c16acfc915a79b1e3feb5013c41e75 upstream.
Vendor-specific ID for BCM20702A0.
Support for bluetooth over Asus Wi-Fi GO!, included with Asus P8Z77-V Deluxe.
T: Bus=07 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0b05 ProdID=17b5 Rev=01.12 S: Manufacturer=Broadcom Corp S: Product=BCM20702A0 S: SerialNumber=94DBC98AC113 C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none) I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none) I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)
--- drivers/bluetooth/btusb.c | 1 + 1 file changed, 1 insertion(+)
drivers/bluetooth/btusb.c +1 -0
@@ -96,6 +96,7 @@ static struct usb_device_id btusb_table[] = { { USB_DEVICE(0x0c10, 0x0000) },/* Broadcom BCM20702A0 */ + { USB_DEVICE(0x0b05, 0x17b5) }, { USB_DEVICE(0x04ca, 0x2003) }, { USB_DEVICE(0x0489, 0xe042) }, { USB_DEVICE(0x413c, 0x8197) },
PATCH 69/173 regulator: wm831x: Set the new rather than old value for DVS VSEL
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mark Brown <[email protected]>
commit 13ae633cf729b0ecb677b75b04886ff8fada8fad upstream.
--- drivers/regulator/wm831x-dcdc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/regulator/wm831x-dcdc.c +1 -1
@@ -290,7 +290,7 @@ static int wm831x_buckv_set_voltage_sel(struct regulator_dev *rdev,if (vsel > dcdc->dvs_vsel) { ret =wm831x_set_bits (wm831x, dvs_reg,WM831X_DC1_DVS_VSEL_MASK , - dcdc->dvs_vsel); + vsel);if (ret ==0 ) dcdc->dvs_vsel = vsel;else
PATCH 70/173 drm: fix documentation for drm_crtc_set_mode()
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <[email protected]>
commit 4c9287c6009b37754c42e0ba73a4cc79de92d8f8 upstream.
x and y parameters are offsets, not width/height
--- drivers/gpu/drm/drm_crtc_helper.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/gpu/drm/drm_crtc_helper.c +2 -2
@@ -346,8 +346,8 @@ drm_crtc_prepare_encoders(struct drm_device *dev)* drm_crtc_set_mode - set a mode * @crtc: CRTC to program * @mode: mode to use -* @x: width of mode -* @y: height of mode +* @x: horizontal offset into the surface +* @y: vertical offset into the surface * * LOCKING: * Caller must hold mode config lock.
PATCH 71/173 mfd: Only unregister platform devices allocated by the mfd core
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Charles Keepax <[email protected]>
commit b9fbb62eb61452d728c39b2e5020739c575aac53 upstream.
mfd_remove_devices would iterate over all devices sharing a parent with an mfd device regardless of whether they were allocated by the mfd core or not. This especially caused problems when the device structure was not contained within a platform_device, because to_platform_device is used on each device pointer.
This patch defines a device_type for mfd devices and checks this is present from mfd_remove_devices_fn before processing the device.
--- drivers/mfd/mfd-core.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-)
drivers/mfd/mfd-core.c +13 -2
@@ -19,6 +19,10 @@#include <linux/slab.h> #include <linux/module.h> +static struct device_type mfd_dev_type = { + .name ="mfd_device" , +}; +int mfd_cell_enable (struct platform_device *pdev) {const struct mfd_cell *cell =mfd_get_cell (pdev);
@@ -88,6 +92,7 @@ static int mfd_add_device(struct device goto fail_device; pdev->dev.parent = parent; + pdev->dev.type = &mfd_dev_type;if (cell->pdata_size) { ret = platform_device_add_data(pdev,
@@ -183,10 +188,16 @@ EXPORT_SYMBOL(mfd_add_devices);static int mfd_remove_devices_fn (struct device *dev,void *c) { -struct platform_device *pdev =to_platform_device (dev); -const struct mfd_cell *cell =mfd_get_cell (pdev); +struct platform_device *pdev; +const struct mfd_cell *cell;atomic_t **usage_count = c; +if (dev->type != &mfd_dev_type) +return 0 ; + + pdev =to_platform_device (dev); + cell =mfd_get_cell (pdev); +/* find the base address of usage_count pointers (for freeing) */ if (!*usage_count || (cell->usage_count < *usage_count)) *usage_count = cell->usage_count;
PATCH 72/173 NFS: Add sequence_priviliged_ops for nfs4_proc_sequence()
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bryan Schumaker <[email protected]>
commit 6bdb5f213c4344324f600dde885f25768fbd14db upstream.
If I mount an NFS v4.1 server to a single client multiple times and then run xfstests over each mountpoint I usually get the client into a state where recovery deadlocks. The server informs the client of a cb_path_down sequence error, the client then does a bind_connection_to_session and checks the status of the lease.
I found that bind_connection_to_session sets the NFS4_SESSION_DRAINING flag on the client, but this flag is never unset before nfs4_check_lease() reaches nfs4_proc_sequence(). This causes the client to deadlock, halting all NFS activity to the server. nfs4_proc_sequence() is only called by the state manager, so I can change it to run in privileged mode to bypass the NFS4_SESSION_DRAINING check and avoid the deadlock.
--- fs/nfs/nfs4proc.c | 21 +++++++++++++++++---- 1 file changed, 17 insertions(+), 4 deletions(-)
fs/nfs/nfs4proc.c +17 -4
@@ -6136,13 +6136,26 @@ static void nfs41_sequence_prepare(struct rpc_task *task, void *data)rpc_call_start (task); } +static void nfs41_sequence_prepare_privileged (struct rpc_task *task,void *data) +{ +rpc_task_set_priority (task,RPC_PRIORITY_PRIVILEGED ); +nfs41_sequence_prepare (task, data); +} +static const struct rpc_call_ops nfs41_sequence_ops = { .rpc_call_done = nfs41_sequence_call_done, .rpc_call_prepare = nfs41_sequence_prepare, .rpc_release = nfs41_sequence_release, }; -static struct rpc_task *_nfs41_proc_sequence (struct nfs_client *clp,struct rpc_cred *cred) +static const struct rpc_call_ops nfs41_sequence_privileged_ops = { + .rpc_call_done = nfs41_sequence_call_done, + .rpc_call_prepare = nfs41_sequence_prepare_privileged, + .rpc_release = nfs41_sequence_release, +}; + +static struct rpc_task *_nfs41_proc_sequence (struct nfs_client *clp,struct rpc_cred *cred, +const struct rpc_call_ops *seq_ops) {struct nfs4_sequence_data *calldata;struct rpc_message msg = {
@@ -6152,7 +6165,7 @@ static struct rpc_task *_nfs41_proc_sequence(struct nfs_client *clp, struct rpc_struct rpc_task_setup task_setup_data = { .rpc_client = clp->cl_rpcclient, .rpc_message = &msg, - .callback_ops = &nfs41_sequence_ops, + .callback_ops = seq_ops, .flags =RPC_TASK_ASYNC |RPC_TASK_SOFT , };
@@ -6179,7 +6192,7 @@ static int nfs41_proc_async_sequence(struct nfs_client *clp, struct rpc_cred *crif ((renew_flags &NFS4_RENEW_TIMEOUT ) ==0 )return 0 ; - task =_nfs41_proc_sequence (clp, cred); + task =_nfs41_proc_sequence (clp, cred, &nfs41_sequence_ops);if (IS_ERR (task)) ret =PTR_ERR (task);else
@@ -6193,7 +6206,7 @@ static int nfs4_proc_sequence(struct nfs_client *clp, struct rpc_cred *cred)struct rpc_task *task;int ret; - task =_nfs41_proc_sequence (clp, cred); + task =_nfs41_proc_sequence (clp, cred, &nfs41_sequence_privileged_ops);if (IS_ERR (task)) { ret =PTR_ERR (task); goto out;
PATCH 73/173 drm/i915: make the panel fitter work on pipes B and C on IVB
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paulo Zanoni <[email protected]>
commit 13888d78c664a1f61d7b09d282f5916993827a40 upstream.
I actually found this problem on Haswell, but then discovered Ivy Bridge also has it by reading the spec.
I don't have the hardware to test this.
--- drivers/gpu/drm/i915/i915_reg.h | 2 ++ drivers/gpu/drm/i915/intel_display.c | 6 +++++- 2 files changed, 7 insertions(+), 1 deletion(-)
drivers/gpu/drm/i915/i915_reg.h +2 -0
@@ -3339,6 +3339,8 @@#define _PFA_CTL_1 0x68080#define _PFB_CTL_1 0x68880#define PF_ENABLE (1<<31) +#define PF_PIPE_SEL_MASK_IVB (3<<29) +#define PF_PIPE_SEL_IVB (pipe) ((pipe)<<29)#define PF_FILTER_MASK (3<<23)#define PF_FILTER_PROGRAMMED (0<<23)#define PF_FILTER_MED_3x3 (1<<23)
drivers/gpu/drm/i915/intel_display.c +5 -1
@@ -3387,7 +3387,11 @@ static void ironlake_crtc_enable(struct drm_crtc *crtc)* as some pre-programmed values are broken, * e.g. x201. */ -I915_WRITE (PF_CTL (pipe),PF_ENABLE | PF_FILTER_MED_3x3); +if (IS_IVYBRIDGE (dev)) +I915_WRITE (PF_CTL (pipe),PF_ENABLE | PF_FILTER_MED_3x3 | +PF_PIPE_SEL_IVB (pipe)); +else +I915_WRITE (PF_CTL (pipe),PF_ENABLE | PF_FILTER_MED_3x3);I915_WRITE (PF_WIN_POS (pipe), dev_priv->pch_pf_pos);I915_WRITE (PF_WIN_SZ (pipe), dev_priv->pch_pf_size); }
PATCH 74/173 USB: add new zte 3g-dongles pid to option.c
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: "[email protected]" <[email protected]>
commit 31b6a1048b7292efff8b5b53ae3d9d29adde385e upstream.
--- drivers/usb/serial/option.c | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+)
drivers/usb/serial/option.c +22 -0
@@ -883,6 +883,10 @@ static const struct usb_device_id option_ids[] = { { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0126, 0xff, 0xff, 0xff), .driver_info = (kernel_ulong_t)&net_intf5_blacklist }, { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0128, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0135, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0136, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0137, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0139, 0xff, 0xff, 0xff) }, { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0142, 0xff, 0xff, 0xff) }, { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0143, 0xff, 0xff, 0xff) }, { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0144, 0xff, 0xff, 0xff) },
@@ -903,20 +907,34 @@ static const struct usb_device_id option_ids[] = { { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0165, 0xff, 0xff, 0xff) }, { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0167, 0xff, 0xff, 0xff), .driver_info = (kernel_ulong_t)&net_intf4_blacklist }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0189, 0xff, 0xff, 0xff) }, { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0191, 0xff, 0xff, 0xff), /* ZTE EuFi890 */ .driver_info = (kernel_ulong_t)&net_intf4_blacklist }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0196, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0197, 0xff, 0xff, 0xff) }, { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0199, 0xff, 0xff, 0xff), /* ZTE MF820S */ .driver_info = (kernel_ulong_t)&net_intf1_blacklist }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0200, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0201, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0254, 0xff, 0xff, 0xff) }, { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0257, 0xff, 0xff, 0xff), /* ZTE MF821 */ .driver_info = (kernel_ulong_t)&net_intf3_blacklist }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0265, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0284, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0317, 0xff, 0xff, 0xff) }, { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0326, 0xff, 0xff, 0xff), .driver_info = (kernel_ulong_t)&net_intf4_blacklist }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0330, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0395, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0414, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0417, 0xff, 0xff, 0xff) }, { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1008, 0xff, 0xff, 0xff), .driver_info = (kernel_ulong_t)&net_intf4_blacklist }, { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1010, 0xff, 0xff, 0xff), .driver_info = (kernel_ulong_t)&net_intf4_blacklist }, { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1012, 0xff, 0xff, 0xff), .driver_info = (kernel_ulong_t)&net_intf4_blacklist }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1018, 0xff, 0xff, 0xff) }, { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1021, 0xff, 0xff, 0xff), .driver_info = (kernel_ulong_t)&net_intf2_blacklist }, { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1057, 0xff, 0xff, 0xff) },
@@ -1096,6 +1114,10 @@ static const struct usb_device_id option_ids[] = { { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1298, 0xff, 0xff, 0xff) }, { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1299, 0xff, 0xff, 0xff) }, { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1300, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1301, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1302, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1303, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1333, 0xff, 0xff, 0xff) }, { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1401, 0xff, 0xff, 0xff), .driver_info = (kernel_ulong_t)&net_intf2_blacklist }, { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1402, 0xff, 0xff, 0xff),
PATCH 75/173 ACPI / PM: Add Sony Vaio VPCEB1S1E to nonvs blacklist.
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lan Tianyu <[email protected]>
commit 876ab79055019e248508cfd0dee7caa3c0c831ed upstream.
Sony Vaio VPCEB1S1E does not resume correctly without acpi_sleep=nonvs, so add it to the ACPI sleep blacklist.
References: https://bugzilla.kernel.org/show_bug.cgi?id=48781
--- drivers/acpi/sleep.c | 8 ++++++++ 1 file changed, 8 insertions(+)
drivers/acpi/sleep.c +8 -0
@@ -534,6 +534,14 @@ static struct dmi_system_id __initdata acpisleep_dmi_table[] = { }, { .callback = init_nvs_nosave, + .ident = "Sony Vaio VPCEB1S1E", + .matches = { +DMI_MATCH (DMI_SYS_VENDOR ,"Sony Corporation" ), + DMI_MATCH(DMI_PRODUCT_NAME, "VPCEB1S1E"), + }, + }, + { + .callback = init_nvs_nosave, .ident = "Sony Vaio VGN-FW520F", .matches = { DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"),
PATCH 76/173 nfsd: fix v4 reply caching
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: "J. Bruce Fields" <[email protected]>
commit 57d276d71aef7d8305ff002a070cb98deb2edced upstream.
Very embarassing: 1091006c5eb15cba56785bd5b498a8d0b9546903 "nfsd: turn on reply cache for NFSv4" missed a line, effectively leaving the reply cache off in the v4 case. I thought I'd tested that, but I guess not.
This time, wrote a pynfs test to confirm it works.
--- fs/nfsd/nfssvc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/nfsd/nfssvc.c +1 -1
@@ -640,7 +640,7 @@ nfsd_dispatch(struct svc_rqst *rqstp, __be32 *statp) }/* Store reply in cache. */ -nfsd_cache_update (rqstp, proc->pc_cachetype, statp +1 ); +nfsd_cache_update (rqstp, rqstp->rq_cachetype, statp +1 );return 1 ; }
PATCH 77/173 USB: OHCI: workaround for hardware bug: retired TDs not added to the Done Queue
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alan Stern <[email protected]>
commit 50ce5c0683aa83eb161624ea89daa5a9eee0c2ce upstream.
This patch (as1636) is a partial workaround for a hardware bug affecting OHCI controllers by NVIDIA at least, maybe others too. When the controller retires a Transfer Descriptor, it is supposed to add the TD onto the Done Queue. But sometimes this doesn't happen, with the result that ohci-hcd never realizes the corresponding transfer has finished. Symptoms can vary; a typical result is that USB audio stops working after a while.
The patch works around the problem by recognizing that TDs are always processed in order. Therefore, if a later TD is found on the Done Queue than all the earlier TDs for the same endpoint must be finished as well.
Unfortunately this won't solve the problem in cases where the missing TD is the last one in the endpoint's queue. A complete fix would require a signficant amount of change to the driver.
--- drivers/usb/host/ohci-q.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+)
drivers/usb/host/ohci-q.c +19 -0
@@ -1128,6 +1128,25 @@ dl_done_list (struct ohci_hcd *ohci)while (td) {struct td *td_next = td->next_dl_td; +struct ed *ed = td->ed; + +/* +* Some OHCI controllers (NVIDIA for sure, maybe others) +* occasionally forget to add TDs to the done queue. Since +* TDs for a given endpoint are always processed in order, +* if we find a TD on the donelist then all of its +* predecessors must be finished as well. +*/ +for (;;) { +struct td *td2; + + td2 = list_first_entry(&ed->td_list, struct td, + td_list); +if (td2 == td) +break ; +takeback_td (ohci, td2); + } +takeback_td (ohci, td); td = td_next; }
PATCH 78/173 USB: option: blacklist network interface on Huawei E173
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bjørn Mork <[email protected]>
commit f36446cf9bbebaa03a80d95cfeeafbaf68218249 upstream.
The Huawei E173 will normally appear as 12d1:1436 in Linux. But the modem has another mode with different device ID and a slightly different set of descriptors. This is the mode used by Windows like this:
3Modem: USB\VID_12D1&PID_140C&MI_00\6&3A1D2012&0&0000
Networkcard: USB\VID_12D1&PID_140C&MI_01\6&3A1D2012&0&0001 Appli.Inter: USB\VID_12D1&PID_140C&MI_02\6&3A1D2012&0&0002 PC UI Inter: USB\VID_12D1&PID_140C&MI_03\6&3A1D2012&0&0003
All interfaces have the same ff/ff/ff class codes in this mode. Blacklisting the network interface to allow it to be picked up by the network driver.
--- drivers/usb/serial/option.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/usb/serial/option.c +3 -0
@@ -80,6 +80,7 @@ static void option_instat_callback(struct urb *urb);#define OPTION_PRODUCT_GTM380_MODEM 0x7201#define HUAWEI_VENDOR_ID 0x12D1 +#define HUAWEI_PRODUCT_E173 0x140C#define HUAWEI_PRODUCT_K4505 0x1464#define HUAWEI_PRODUCT_K3765 0x1465#define HUAWEI_PRODUCT_K4605 0x14C6
@@ -552,6 +553,8 @@ static const struct usb_device_id option_ids[] = { { USB_DEVICE(QUANTA_VENDOR_ID, QUANTA_PRODUCT_GLX) }, { USB_DEVICE(QUANTA_VENDOR_ID, QUANTA_PRODUCT_GKE) }, { USB_DEVICE(QUANTA_VENDOR_ID, QUANTA_PRODUCT_GLE) }, + { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E173, 0xff, 0xff, 0xff), + .driver_info = (kernel_ulong_t) &net_intf1_blacklist }, { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K4505, 0xff, 0xff, 0xff), .driver_info = (kernel_ulong_t) &huawei_cdc12_blacklist }, { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K3765, 0xff, 0xff, 0xff),
PATCH 79/173 USB: cp210x: add Virtenio Preon32 device id
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Markus Becker <[email protected]>
commit 356fe44f4b8ece867bdb9876b1854d7adbef9de2 upstream.
--- drivers/usb/serial/cp210x.c | 1 + 1 file changed, 1 insertion(+)
drivers/usb/serial/cp210x.c +1 -0
@@ -113,6 +113,7 @@ static const struct usb_device_id id_table[] = { { USB_DEVICE(0x10C4, 0x8477) }, /* Balluff RFID */ { USB_DEVICE(0x10C4, 0x85EA) }, /* AC-Services IBUS-IF */ { USB_DEVICE(0x10C4, 0x85EB) }, /* AC-Services CIS-IBUS */ + { USB_DEVICE(0x10C4, 0x85F8) }, /* Virtenio Preon32 */ { USB_DEVICE(0x10C4, 0x8664) }, /* AC-Services CAN-IF */ { USB_DEVICE(0x10C4, 0x8665) }, /* AC-Services OBD-IF */ { USB_DEVICE(0x10C4, 0xEA60) }, /* Silicon Labs factory default */
PATCH 80/173 usb: ftdi_sio: fixup BeagleBone A5+ quirk
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peter Korsgaard <[email protected]>
commit 1a88d5eee2ef2ad1d3c4e32043e9c4c5347d4fc1 upstream.
BeagleBone A5+ devices ended up getting shipped with the 'BeagleBone/XDS100V2' product string, and not XDS100 like it was agreed, so adjust the quirk to match.
For details, see the thread on the beagle list:
https://groups.google.com/forum/#!msg/beagleboard/zrFPew9_Wvo/ibWr1-eE8JwJ
--- drivers/usb/serial/ftdi_sio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/serial/ftdi_sio.c +1 -1
@@ -1807,7 +1807,7 @@ static int ftdi_8u2232c_probe(struct usbdbg ("%s" , __func__);if ((udev->manufacturer && !strcmp (udev->manufacturer,"CALAO Systems" )) || - (udev->product && !strcmp (udev->product,"BeagleBone/XDS100" ))) + (udev->product && !strcmp (udev->product,"BeagleBone/XDS100V2" )))return ftdi_jtag_probe (serial);return 0 ;
PATCH 81/173 USB: ftdi_sio: Add support for Newport AGILIS motor drivers
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Martin Teichmann <[email protected]>
commit d7e14b375b40c04cd735b115713043b69a2c68ac upstream.
The Newport AGILIS model AG-UC8 compact piezo motor controller
(http://search.newport.com/?q=*&x2=sku&q2=AG-UC8)
is yet another device using an FTDI USB-to-serial chip. It works fine with the ftdi_sio driver when adding
options ftdi-sio product=0x3000 vendor=0x104d
to modprobe.d. udevadm reports "Newport" as the manufacturer, and "Agilis" as the product name.
--- drivers/usb/serial/ftdi_sio.c | 1 + drivers/usb/serial/ftdi_sio_ids.h | 6 ++++++ 2 files changed, 7 insertions(+)
drivers/usb/serial/ftdi_sio.c +1 -0
@@ -191,6 +191,7 @@ static struct usb_device_id id_table_combined [] = { { USB_DEVICE(FTDI_VID, FTDI_OPENDCC_THROTTLE_PID) }, { USB_DEVICE(FTDI_VID, FTDI_OPENDCC_GATEWAY_PID) }, { USB_DEVICE(FTDI_VID, FTDI_OPENDCC_GBM_PID) }, + { USB_DEVICE(NEWPORT_VID, NEWPORT_AGILIS_PID) }, { USB_DEVICE(INTERBIOMETRICS_VID, INTERBIOMETRICS_IOBOARD_PID) }, { USB_DEVICE(INTERBIOMETRICS_VID, INTERBIOMETRICS_MINI_IOBOARD_PID) }, { USB_DEVICE(FTDI_VID, FTDI_SPROG_II) },
drivers/usb/serial/ftdi_sio_ids.h +6 -0
@@ -752,6 +752,12 @@#define TTI_VID 0x103E/* Vendor Id */ #define TTI_QL355P_PID 0x03E8/* TTi QL355P power supply */ +/* +* Newport Cooperation (www.newport.com) +*/ +#define NEWPORT_VID 0x104D +#define NEWPORT_AGILIS_PID 0x3000 +/* Interbiometrics USB I/O Board */ /* Developed for Interbiometrics by Rudolf Gugler */ #define INTERBIOMETRICS_VID 0x1209
PATCH 82/173 iscsit: use GFP_ATOMIC under spin lock
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wei Yongjun <[email protected]>
commit 3c989d7603872bf878840f7ce3ea49b73bea4c6c upstream.
The function iscsit_build_conn_drop_async_message() is called from iscsit_close_connection() with spin lock 'sess->conn_lock' held, so we should use GFP_ATOMIC instead of GFP_KERNEL.
--- drivers/target/iscsi/iscsi_target.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/target/iscsi/iscsi_target.c +1 -1
@@ -2336,7 +2336,7 @@ static void iscsit_build_conn_drop_async_message(struct iscsi_conn *conn)if (!conn_p)return ; - cmd =iscsit_allocate_cmd (conn_p,GFP_KERNEL ); + cmd =iscsit_allocate_cmd (conn_p,GFP_ATOMIC );if (!cmd) {iscsit_dec_conn_usage_count (conn_p);return ;
PATCH 83/173 sata_promise: fix hardreset lockdep error
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mikael Pettersson <[email protected]>
commit 3100d49d3cd236443faae9d81137c81b22d36003 upstream.
sata_promise's pdc_hard_reset_port() needs to serialize because it flips a port-specific bit in controller register that's shared by all ports. The code takes the ata host lock for this, but that's broken because an interrupt may arrive on our irq during the hard reset sequence, and that too will take the ata host lock. With lockdep enabled a big nasty warning is seen.
Fixed by adding private state to the ata host structure, containing a second lock used only for serializing the hard reset sequences. This eliminated the lockdep warnings both on my test rig and on the original reporter's machine.
--- drivers/ata/sata_promise.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-)
drivers/ata/sata_promise.c +13 -2
@@ -147,6 +147,10 @@ struct pdc_port_priv {dma_addr_t pkt_dma; }; +struct pdc_host_priv { +spinlock_t hard_reset_lock; +}; +static int pdc_sata_scr_read (struct ata_link *link,unsigned int sc_reg,u32 *val);static int pdc_sata_scr_write (struct ata_link *link,unsigned int sc_reg,u32 val);static int pdc_ata_init_one (struct pci_dev *pdev,const struct pci_device_id *ent);
@@ -801,9 +805,10 @@ static void pdc_hard_reset_port(struct ata_port *ap)void __iomem *host_mmio = ap->host->iomap[PDC_MMIO_BAR ];void __iomem *pcictl_b1_mmio = host_mmio +PDC_PCI_CTL +1 ;unsigned int ata_no =pdc_ata_port_to_ata_no (ap); +struct pdc_host_priv *hpriv = ap->host->private_data;u8 tmp; -spin_lock (&ap->host->lock); +spin_lock (&hpriv->hard_reset_lock); tmp =readb (pcictl_b1_mmio); tmp &= ~(0x10 << ata_no);
@@ -814,7 +819,7 @@ static void pdc_hard_reset_port(struct ata_port *ap)writeb (tmp, pcictl_b1_mmio);readb (pcictl_b1_mmio);/* flush */ -spin_unlock (&ap->host->lock); +spin_unlock (&hpriv->hard_reset_lock); } static int pdc_sata_hardreset(struct ata_link *link, unsigned int *class,
@@ -1182,6 +1187,7 @@ static int pdc_ata_init_one(struct pci_dev *pdev,const struct ata_port_info *pi = &pdc_port_info[ent->driver_data];const struct ata_port_info *ppi[PDC_MAX_PORTS ];struct ata_host *host; +struct pdc_host_priv *hpriv;void __iomem *host_mmio;int n_ports, i, rc;int is_sataii_tx4;
@@ -1218,6 +1224,11 @@ static int pdc_ata_init_one(struct pci_dev *pdev,dev_err (&pdev->dev,"failed to allocate host\n" );return -ENOMEM ; } + hpriv =devm_kzalloc (&pdev->dev,sizeof *hpriv,GFP_KERNEL ); +if (!hpriv) +return -ENOMEM ; +spin_lock_init (&hpriv->hard_reset_lock); + host->private_data = hpriv; host->iomap =pcim_iomap_table (pdev); is_sataii_tx4 =pdc_is_sataii_tx4 (pi->flags);
PATCH 84/173 xhci: Add Lynx Point LP to list of Intel switchable hosts
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Russell Webb <[email protected]>
commit bb1e5dd7113d2fd178d3af9aca8f480ae0468edf upstream.
Like Lynx Point, Lynx Point LP is also switchable. See 1c12443ab8eba71a658fae4572147e56d1f84f66 for more details.
This patch should be backported to stable kernels as old as 3.0, that contain commit 69e848c2090aebba5698a1620604c7dccb448684 "Intel xhci: Support EHCI/xHCI port switching."
--- drivers/usb/host/ehci-pci.c | 3 ++- drivers/usb/host/pci-quirks.c | 4 +++- 2 files changed, 5 insertions(+), 2 deletions(-)
drivers/usb/host/ehci-pci.c +2 -1
@@ -330,7 +330,8 @@ static bool usb_is_intel_switchable_ehci(struct pci_dev *pdev) pdev->vendor ==PCI_VENDOR_ID_INTEL && (pdev->device ==0x1E26 || pdev->device ==0x8C2D || - pdev->device ==0x8C26 ); + pdev->device ==0x8C26 || + pdev->device ==0x9C26 ); }static void ehci_enable_xhci_companion (void )
drivers/usb/host/pci-quirks.c +3 -1
@@ -723,6 +723,7 @@ static int handshake(void __iomem *ptr, u32 mask, u32 done, }#define PCI_DEVICE_ID_INTEL_LYNX_POINT_XHCI 0x8C31 +#define PCI_DEVICE_ID_INTEL_LYNX_POINT_LP_XHCI 0x9C31bool usb_is_intel_ppt_switchable_xhci (struct pci_dev *pdev) {
@@ -736,7 +737,8 @@ bool usb_is_intel_lpt_switchable_xhci(struct pci_dev *pdev) {return pdev->class ==PCI_CLASS_SERIAL_USB_XHCI && pdev->vendor ==PCI_VENDOR_ID_INTEL && - pdev->device ==PCI_DEVICE_ID_INTEL_LYNX_POINT_XHCI ; + (pdev->device ==PCI_DEVICE_ID_INTEL_LYNX_POINT_XHCI || + pdev->device ==PCI_DEVICE_ID_INTEL_LYNX_POINT_LP_XHCI ); }bool usb_is_intel_switchable_xhci (struct pci_dev *pdev)
PATCH 85/173 USB: mark uas driver as BROKEN
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Greg KH <[email protected]>
commit fb37ef98015f864d22be223a0e0d93547cd1d4ef upstream.
As reported https://bugzilla.kernel.org/show_bug.cgi?id=51031, the UAS driver causes problems and has been asked to be not built into any of the major distributions. To prevent users from running into problems with it, and for distros that were not notified, just mark the whole thing as broken.
--- drivers/usb/storage/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/storage/Kconfig +1 -1
@@ -203,7 +203,7 @@ config USB_STORAGE_ENE_UB6250 config USB_UAS tristate "USB Attached SCSI" - depends on USB && SCSI + depends on USB && SCSI && BROKEN help The USB Attached SCSI protocol is supported by some USB storage devices. It permits higher performance by supporting
PATCH 86/173 can: Do not call dev_put if restart timer is running upon close
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexander Stein <[email protected]>
commit ab48b03ec9ae1840a1e427e2375bd0d9d554b4ed upstream.
If the restart timer is running due to BUS-OFF and the device is disconnected an dev_put will decrease the usage counter to -1 thus blocking the interface removal, resulting in the following dmesg lines repeating every 10s:
can: notifier: receive list not found for dev can0
can: notifier: receive list not found for dev can0
can: notifier: receive list not found for dev can0unregister_netdevice: waiting for can0 to become free. Usage count = -1
--- drivers/net/can/dev.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/net/can/dev.c +1 -2
@@ -609,8 +609,7 @@ void close_candev(struct net_device *dev) {struct can_priv *priv =netdev_priv (dev); -if (del_timer_sync (&priv->restart_timer)) -dev_put (dev); +del_timer_sync (&priv->restart_timer);can_flush_echo_skb (dev); }EXPORT_SYMBOL_GPL (close_candev);
PATCH 87/173 prevent stack buffer overflow in host_reset
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sasha Levin <[email protected]>
commit 072f19b4bea31cdd482d79f805413f2f9ac9e233 upstream.
store_host_reset() has tried to re-invent the wheel to compare sysfs strings. Unfortunately it did so poorly and never bothered to check the input from userspace before overwriting stack with it, so something simple as:
echo "WoopsieWoopsie" > /sys/devices/pseudo_0/adapter0/host0/scsi_host/host0/host_reset
would result in:
[ 316.310101] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffff81f5bac7 [ 316.310101] [ 316.320051] Pid: 6655, comm: sh Tainted: G W 3.7.0-rc5-next-20121114-sasha-00016-g5c9d68d-dirty #129 [ 316.320051] Call Trace: [ 316.340058] pps pps0: PPS event at 1352918752.620355751 [ 316.340062] pps pps0: capture assert seq #303 [ 316.320051] [<ffffffff83b3856b>] panic+0xcd/0x1f4 [ 316.320051] [<ffffffff81f5bac7>] ? store_host_reset+0xd7/0x100 [ 316.320051] [<ffffffff8110b996>] __stack_chk_fail+0x16/0x20 [ 316.320051] [<ffffffff81f5bac7>] store_host_reset+0xd7/0x100 [ 316.320051] [<ffffffff81e55bb3>] dev_attr_store+0x13/0x30 [ 316.320051] [<ffffffff812f7db1>] sysfs_write_file+0x101/0x170 [ 316.320051] [<ffffffff8127acc8>] vfs_write+0xb8/0x180 [ 316.320051] [<ffffffff8127ae80>] sys_write+0x50/0xa0 [ 316.320051] [<ffffffff83c03418>] tracesys+0xe1/0xe6
Fix this by uninventing whatever was going on there and just use sysfs_streq.
Bug introduced by 29443691 ("[SCSI] scsi: Added support for adapter and firmware reset").
--- drivers/scsi/scsi_sysfs.c | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-)
drivers/scsi/scsi_sysfs.c +4 -7
@@ -247,11 +247,11 @@ show_shost_active_mode(struct device *dev, static DEVICE_ATTR(active_mode, S_IRUGO | S_IWUSR, show_shost_active_mode, NULL); -static int check_reset_type (char *str) +static int check_reset_type (const char *str) { -if (strncmp (str,"adapter" ,10 ) ==0 ) +if (sysfs_streq (str,"adapter" ))return SCSI_ADAPTER_RESET ; -else if (strncmp (str,"firmware" ,10 ) ==0 ) +else if (sysfs_streq (str,"firmware" ))return SCSI_FIRMWARE_RESET ;else return 0 ;
@@ -264,12 +264,9 @@ store_host_reset(struct device *dev, struct device_attribute *attr,struct Scsi_Host *shost =class_to_shost (dev);struct scsi_host_template *sht = shost->hostt;int ret = -EINVAL ; -char str[10 ];int type; -sscanf (buf,"%s" , str); - type =check_reset_type (str); - + type =check_reset_type (buf);if (!type) goto exit_store_host_reset;
PATCH 88/173 mvsas: fix undefined bit shift
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Xi Wang <[email protected]>
commit beecadea1b8d67f591b13f7099559f32f3fd601d upstream.
The macro bit(n) is defined as ((u32)1 << n), and thus it doesn't work with n >= 32, such as in mvs_94xx_assign_reg_set():
if (i >= 32) {
mvi->sata_reg_set |= bit(i);
...
}The shift ((u32)1 << n) with n >= 32 also leads to undefined behavior. The result varies depending on the architecture.
This patch changes bit(n) to do a 64-bit shift. It also simplifies mv_ffc64() using __ffs64(), since invoking ffz() with ~0 is undefined.
--- drivers/scsi/mvsas/mv_94xx.h | 14 ++------------ drivers/scsi/mvsas/mv_sas.h | 2 +- 2 files changed, 3 insertions(+), 13 deletions(-)
drivers/scsi/mvsas/mv_94xx.h +2 -12
@@ -258,21 +258,11 @@ enum sas_sata_phy_regs {#define SPI_ADDR_VLD_94XX (1U << 1)#define SPI_CTRL_SpiStart_94XX (1U << 0) -#define mv_ffc (x) ffz(x) -static inline int mv_ffc64 (u64 v) { -int i; - i =mv_ffc ((u32 )v); -if (i >=0 ) -return i; - i =mv_ffc ((u32)(v>>32 )); - -if (i !=0 ) -return 32 + i; - -return -1 ; +u64 x = ~v; +return x ?__ffs64 (x) :-1 ; }#define r_reg_set_enable (i) \
drivers/scsi/mvsas/mv_sas.h +1 -1
@@ -69,7 +69,7 @@ extern struct kmem_cache *mvs_task_list_cache;#define DEV_IS_EXPANDER (type) \ ((type == EDGE_DEV) || (type == FANOUT_DEV)) -#define bit (n) ((u32)1 << n) +#define bit (n) ((u64)1 << n)#define for_each_phy (__lseq_mask, __mc, __lseq) \ for ((__mc) = (__lseq_mask), (__lseq) = 0; \
PATCH 89/173 qla2xxx: Test and clear FCPORT_UPDATE_NEEDED atomically.
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Jeffery <[email protected]>
commit a394aac88506159e047630fc90dc2242568382d8 upstream.
When the qla2xxx driver loses access to multiple, remote ports, there is a race condition which can occur which will keep the request stuck on a scsi request queue indefinitely.
This bad state occurred do to a race condition with how the FCPORT_UPDATE_NEEDED bit is set in qla2x00_schedule_rport_del(), and how it is cleared in qla2x00_do_dpc(). The problem port has its drport pointer set, but it has never been processed by the driver to inform the fc transport that the port has been lost. qla2x00_schedule_rport_del() sets drport, and then sets the FCPORT_UPDATE_NEEDED bit. In qla2x00_do_dpc(), the port lists are walked and any drport pointer is handled and the fc transport informed of the port loss, then the FCPORT_UPDATE_NEEDED bit is cleared. This leaves a race where the dpc thread is processing one port removal, another port removal is marked with a call to qla2x00_schedule_rport_del(), and the dpc thread clears the bit for both removals, even though only the first removal was actually handled. Until another event occurs to set FCPORT_UPDATE_NEEDED, the later port removal is never finished and qla2xxx stays in a bad state which causes requests to become stuck on request queues.
This patch updates the driver to test and clear FCPORT_UPDATE_NEEDED atomically. This ensures the port state changes are processed and not lost.
--- drivers/scsi/qla2xxx/qla_os.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/scsi/qla2xxx/qla_os.c +2 -2
@@ -3541,9 +3541,9 @@ qla2x00_do_dpc(void *data) "ISP abort end.\n"); } -if (test_bit (FCPORT_UPDATE_NEEDED , &base_vha->dpc_flags)) { +if (test_and_clear_bit (FCPORT_UPDATE_NEEDED , + &base_vha->dpc_flags)) {qla2x00_update_fcports (base_vha); -clear_bit (FCPORT_UPDATE_NEEDED , &base_vha->dpc_flags); }if (test_bit (ISP_QUIESCE_NEEDED , &base_vha->dpc_flags)) {
PATCH 90/173 ACPI: do acpisleep dmi check when CONFIG_ACPI_SLEEP is set
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zhang Rui <[email protected]>
commit 0ac1b1d7b7424cd6f129b5454b504b3cae746f0e upstream.
The current acpisleep DMI checks only run when CONFIG_SUSPEND is set. And this may break hibernation on some platforms when CONFIG_SUSPEND is cleared.
Move acpisleep DMI check into #ifdef CONFIG_ACPI_SLEEP instead.
[rjw: Added acpi_sleep_dmi_check() and rebased on top of earlier
patches adding entries to acpisleep_dmi_table[].]
References: https://bugzilla.kernel.org/show_bug.cgi?id=45921
--- drivers/acpi/sleep.c | 348 +++++++++++++++++++++++++------------------------- 1 file changed, 177 insertions(+), 171 deletions(-)
drivers/acpi/sleep.c +177 -171
@@ -124,6 +124,180 @@ void __init acpi_old_suspend_ordering(void) old_suspend_ordering = true; } +static int __init init_old_suspend_ordering (const struct dmi_system_id *d) +{ +acpi_old_suspend_ordering (); +return 0 ; +} + +static int __init init_nvs_nosave (const struct dmi_system_id *d) +{ +acpi_nvs_nosave (); +return 0 ; +} + +static struct dmi_system_id __initdata acpisleep_dmi_table[] = { + { + .callback = init_old_suspend_ordering, + .ident ="Abit KN9 (nForce4 variant)" , + .matches = { +DMI_MATCH (DMI_BOARD_VENDOR ,"http://www.abit.com.tw/" ), +DMI_MATCH (DMI_BOARD_NAME ,"KN9 Series(NF-CK804)" ), + }, + }, + { + .callback = init_old_suspend_ordering, + .ident ="HP xw4600 Workstation" , + .matches = { +DMI_MATCH (DMI_SYS_VENDOR ,"Hewlett-Packard" ), +DMI_MATCH (DMI_PRODUCT_NAME ,"HP xw4600 Workstation" ), + }, + }, + { + .callback = init_old_suspend_ordering, + .ident ="Asus Pundit P1-AH2 (M2N8L motherboard)" , + .matches = { +DMI_MATCH (DMI_BOARD_VENDOR ,"ASUSTek Computer INC." ), +DMI_MATCH (DMI_BOARD_NAME ,"M2N8L" ), + }, + }, + { + .callback = init_old_suspend_ordering, + .ident ="Panasonic CF51-2L" , + .matches = { +DMI_MATCH (DMI_BOARD_VENDOR , +"Matsushita Electric Industrial Co.,Ltd." ), +DMI_MATCH (DMI_BOARD_NAME ,"CF51-2L" ), + }, + }, + { + .callback = init_nvs_nosave, + .ident ="Sony Vaio VGN-FW21E" , + .matches = { +DMI_MATCH (DMI_SYS_VENDOR ,"Sony Corporation" ), +DMI_MATCH (DMI_PRODUCT_NAME ,"VGN-FW21E" ), + }, + }, + { + .callback = init_nvs_nosave, + .ident ="Sony Vaio VPCEB17FX" , + .matches = { +DMI_MATCH (DMI_SYS_VENDOR ,"Sony Corporation" ), +DMI_MATCH (DMI_PRODUCT_NAME ,"VPCEB17FX" ), + }, + }, + { + .callback = init_nvs_nosave, + .ident ="Sony Vaio VGN-SR11M" , + .matches = { +DMI_MATCH (DMI_SYS_VENDOR ,"Sony Corporation" ), +DMI_MATCH (DMI_PRODUCT_NAME ,"VGN-SR11M" ), + }, + }, + { + .callback = init_nvs_nosave, + .ident ="Everex StepNote Series" , + .matches = { +DMI_MATCH (DMI_SYS_VENDOR ,"Everex Systems, Inc." ), +DMI_MATCH (DMI_PRODUCT_NAME ,"Everex StepNote Series" ), + }, + }, + { + .callback = init_nvs_nosave, + .ident ="Sony Vaio VPCEB1Z1E" , + .matches = { +DMI_MATCH (DMI_SYS_VENDOR ,"Sony Corporation" ), +DMI_MATCH (DMI_PRODUCT_NAME ,"VPCEB1Z1E" ), + }, + }, + { + .callback = init_nvs_nosave, + .ident ="Sony Vaio VGN-NW130D" , + .matches = { +DMI_MATCH (DMI_SYS_VENDOR ,"Sony Corporation" ), +DMI_MATCH (DMI_PRODUCT_NAME ,"VGN-NW130D" ), + }, + }, + { + .callback = init_nvs_nosave, + .ident ="Sony Vaio VPCCW29FX" , + .matches = { +DMI_MATCH (DMI_SYS_VENDOR ,"Sony Corporation" ), +DMI_MATCH (DMI_PRODUCT_NAME ,"VPCCW29FX" ), + }, + }, + { + .callback = init_nvs_nosave, + .ident ="Averatec AV1020-ED2" , + .matches = { +DMI_MATCH (DMI_SYS_VENDOR ,"AVERATEC" ), +DMI_MATCH (DMI_PRODUCT_NAME ,"1000 Series" ), + }, + }, + { + .callback = init_old_suspend_ordering, + .ident ="Asus A8N-SLI DELUXE" , + .matches = { +DMI_MATCH (DMI_BOARD_VENDOR ,"ASUSTeK Computer INC." ), +DMI_MATCH (DMI_BOARD_NAME ,"A8N-SLI DELUXE" ), + }, + }, + { + .callback = init_old_suspend_ordering, + .ident ="Asus A8N-SLI Premium" , + .matches = { +DMI_MATCH (DMI_BOARD_VENDOR ,"ASUSTeK Computer INC." ), +DMI_MATCH (DMI_BOARD_NAME ,"A8N-SLI Premium" ), + }, + }, + { + .callback = init_nvs_nosave, + .ident ="Sony Vaio VGN-SR26GN_P" , + .matches = { +DMI_MATCH (DMI_SYS_VENDOR ,"Sony Corporation" ), +DMI_MATCH (DMI_PRODUCT_NAME ,"VGN-SR26GN_P" ), + }, + }, + { + .callback = init_nvs_nosave, + .ident ="Sony Vaio VPCEB1S1E" , + .matches = { +DMI_MATCH (DMI_SYS_VENDOR ,"Sony Corporation" ), +DMI_MATCH (DMI_PRODUCT_NAME ,"VPCEB1S1E" ), + }, + }, + { + .callback = init_nvs_nosave, + .ident ="Sony Vaio VGN-FW520F" , + .matches = { +DMI_MATCH (DMI_SYS_VENDOR ,"Sony Corporation" ), +DMI_MATCH (DMI_PRODUCT_NAME ,"VGN-FW520F" ), + }, + }, + { + .callback = init_nvs_nosave, + .ident ="Asus K54C" , + .matches = { +DMI_MATCH (DMI_SYS_VENDOR ,"ASUSTeK Computer Inc." ), +DMI_MATCH (DMI_PRODUCT_NAME ,"K54C" ), + }, + }, + { + .callback = init_nvs_nosave, + .ident ="Asus K54HR" , + .matches = { +DMI_MATCH (DMI_SYS_VENDOR ,"ASUSTeK Computer Inc." ), +DMI_MATCH (DMI_PRODUCT_NAME ,"K54HR" ), + }, + }, + {}, +}; + +static void acpi_sleep_dmi_check (void ) +{ +dmi_check_system (acpisleep_dmi_table); +} +/** * acpi_pm_freeze - Disable the GPEs and suspend EC transactions. */
@@ -239,6 +413,7 @@ static void acpi_pm_end(void) }#else /* !CONFIG_ACPI_SLEEP */ #define acpi_target_sleep_state ACPI_STATE_S0 +static inline void acpi_sleep_dmi_check (void ) {}#endif /* CONFIG_ACPI_SLEEP */ #ifdef CONFIG_SUSPEND
@@ -397,175 +572,6 @@ static const struct platform_suspend_ops acpi_suspend_ops_old = { .end = acpi_pm_end, .recover = acpi_pm_finish, }; - -static int __init init_old_suspend_ordering (const struct dmi_system_id *d) -{ - old_suspend_ordering = true; -return 0 ; -} - -static int __init init_nvs_nosave (const struct dmi_system_id *d) -{ -acpi_nvs_nosave (); -return 0 ; -} - -static struct dmi_system_id __initdata acpisleep_dmi_table[] = { - { - .callback = init_old_suspend_ordering, - .ident ="Abit KN9 (nForce4 variant)" , - .matches = { -DMI_MATCH (DMI_BOARD_VENDOR ,"http://www.abit.com.tw/" ), -DMI_MATCH (DMI_BOARD_NAME ,"KN9 Series(NF-CK804)" ), - }, - }, - { - .callback = init_old_suspend_ordering, - .ident ="HP xw4600 Workstation" , - .matches = { -DMI_MATCH (DMI_SYS_VENDOR ,"Hewlett-Packard" ), -DMI_MATCH (DMI_PRODUCT_NAME ,"HP xw4600 Workstation" ), - }, - }, - { - .callback = init_old_suspend_ordering, - .ident ="Asus Pundit P1-AH2 (M2N8L motherboard)" , - .matches = { -DMI_MATCH (DMI_BOARD_VENDOR ,"ASUSTek Computer INC." ), -DMI_MATCH (DMI_BOARD_NAME ,"M2N8L" ), - }, - }, - { - .callback = init_old_suspend_ordering, - .ident ="Panasonic CF51-2L" , - .matches = { -DMI_MATCH (DMI_BOARD_VENDOR , -"Matsushita Electric Industrial Co.,Ltd." ), -DMI_MATCH (DMI_BOARD_NAME ,"CF51-2L" ), - }, - }, - { - .callback = init_nvs_nosave, - .ident ="Sony Vaio VGN-FW21E" , - .matches = { -DMI_MATCH (DMI_SYS_VENDOR ,"Sony Corporation" ), -DMI_MATCH (DMI_PRODUCT_NAME ,"VGN-FW21E" ), - }, - }, - { - .callback = init_nvs_nosave, - .ident ="Sony Vaio VPCEB17FX" , - .matches = { -DMI_MATCH (DMI_SYS_VENDOR ,"Sony Corporation" ), -DMI_MATCH (DMI_PRODUCT_NAME ,"VPCEB17FX" ), - }, - }, - { - .callback = init_nvs_nosave, - .ident ="Sony Vaio VGN-SR11M" , - .matches = { -DMI_MATCH (DMI_SYS_VENDOR ,"Sony Corporation" ), -DMI_MATCH (DMI_PRODUCT_NAME ,"VGN-SR11M" ), - }, - }, - { - .callback = init_nvs_nosave, - .ident ="Everex StepNote Series" , - .matches = { -DMI_MATCH (DMI_SYS_VENDOR ,"Everex Systems, Inc." ), -DMI_MATCH (DMI_PRODUCT_NAME ,"Everex StepNote Series" ), - }, - }, - { - .callback = init_nvs_nosave, - .ident ="Sony Vaio VPCEB1Z1E" , - .matches = { -DMI_MATCH (DMI_SYS_VENDOR ,"Sony Corporation" ), -DMI_MATCH (DMI_PRODUCT_NAME ,"VPCEB1Z1E" ), - }, - }, - { - .callback = init_nvs_nosave, - .ident ="Sony Vaio VGN-NW130D" , - .matches = { -DMI_MATCH (DMI_SYS_VENDOR ,"Sony Corporation" ), -DMI_MATCH (DMI_PRODUCT_NAME ,"VGN-NW130D" ), - }, - }, - { - .callback = init_nvs_nosave, - .ident ="Sony Vaio VPCCW29FX" , - .matches = { -DMI_MATCH (DMI_SYS_VENDOR ,"Sony Corporation" ), -DMI_MATCH (DMI_PRODUCT_NAME ,"VPCCW29FX" ), - }, - }, - { - .callback = init_nvs_nosave, - .ident ="Averatec AV1020-ED2" , - .matches = { -DMI_MATCH (DMI_SYS_VENDOR ,"AVERATEC" ), -DMI_MATCH (DMI_PRODUCT_NAME ,"1000 Series" ), - }, - }, - { - .callback = init_old_suspend_ordering, - .ident ="Asus A8N-SLI DELUXE" , - .matches = { -DMI_MATCH (DMI_BOARD_VENDOR ,"ASUSTeK Computer INC." ), -DMI_MATCH (DMI_BOARD_NAME ,"A8N-SLI DELUXE" ), - }, - }, - { - .callback = init_old_suspend_ordering, - .ident ="Asus A8N-SLI Premium" , - .matches = { -DMI_MATCH (DMI_BOARD_VENDOR ,"ASUSTeK Computer INC." ), -DMI_MATCH (DMI_BOARD_NAME ,"A8N-SLI Premium" ), - }, - }, - { - .callback = init_nvs_nosave, - .ident ="Sony Vaio VGN-SR26GN_P" , - .matches = { -DMI_MATCH (DMI_SYS_VENDOR ,"Sony Corporation" ), -DMI_MATCH (DMI_PRODUCT_NAME ,"VGN-SR26GN_P" ), - }, - }, - { - .callback = init_nvs_nosave, - .ident ="Sony Vaio VPCEB1S1E" , - .matches = { -DMI_MATCH (DMI_SYS_VENDOR ,"Sony Corporation" ), -DMI_MATCH (DMI_PRODUCT_NAME ,"VPCEB1S1E" ), - }, - }, - { - .callback = init_nvs_nosave, - .ident ="Sony Vaio VGN-FW520F" , - .matches = { -DMI_MATCH (DMI_SYS_VENDOR ,"Sony Corporation" ), -DMI_MATCH (DMI_PRODUCT_NAME ,"VGN-FW520F" ), - }, - }, - { - .callback = init_nvs_nosave, - .ident ="Asus K54C" , - .matches = { -DMI_MATCH (DMI_SYS_VENDOR ,"ASUSTeK Computer Inc." ), -DMI_MATCH (DMI_PRODUCT_NAME ,"K54C" ), - }, - }, - { - .callback = init_nvs_nosave, - .ident ="Asus K54HR" , - .matches = { -DMI_MATCH (DMI_SYS_VENDOR ,"ASUSTeK Computer Inc." ), -DMI_MATCH (DMI_PRODUCT_NAME ,"K54HR" ), - }, - }, - {}, -};#endif /* CONFIG_SUSPEND */ #ifdef CONFIG_HIBERNATION
@@ -896,13 +902,13 @@ int __init acpi_sleep_init(void)u8 type_a, type_b;#ifdef CONFIG_SUSPEND int i =0 ; - -dmi_check_system (acpisleep_dmi_table);#endif if (acpi_disabled)return 0 ; +acpi_sleep_dmi_check (); + sleep_states[ACPI_STATE_S0 ] =1 ; printk(KERN_INFO PREFIX "(supports S0");
PATCH 91/173 acpi/video_detect: blacklist samsung x360
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Corentin Chary <[email protected]>
commit 084940d5b101e9ca91a689eb5048151b14076839 upstream.
On Samsung X360, the BIOS will set a flag (VDRV) if the generic ACPI backlight device is used. This flag will definitively break the backlight interface (even the vendor interface) untill next reboot. It's why we should prevent video.ko from being used here and we can't rely on a later call to acpi_video_unregister().
--- drivers/acpi/video_detect.c | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+)
drivers/acpi/video_detect.c +29 -0
@@ -132,6 +132,33 @@ find_video(acpi_handle handle, u32 lvl, void *context, void **rv)return AE_OK ; } +/* Force to use vendor driver when the ACPI device is known to be +* buggy */ +static int video_detect_force_vendor (const struct dmi_system_id *d) +{ + acpi_video_support |=ACPI_VIDEO_BACKLIGHT_DMI_VENDOR ; +return 0 ; +} + +static struct dmi_system_id video_detect_dmi_table[] = { +/* On Samsung X360, the BIOS will set a flag (VDRV) if generic +* ACPI backlight device is used. This flag will definitively break +* the backlight interface (even the vendor interface) untill next +* reboot. It's why we should prevent video.ko from being used here +* and we can't rely on a later call to acpi_video_unregister(). +*/ + { + .callback = video_detect_force_vendor, + .ident ="X360" , + .matches = { +DMI_MATCH (DMI_SYS_VENDOR ,"SAMSUNG ELECTRONICS CO., LTD." ), +DMI_MATCH (DMI_PRODUCT_NAME ,"X360" ), +DMI_MATCH (DMI_BOARD_NAME ,"X360" ), + }, + }, + { }, +}; +/* * Returns the video capabilities of a specific ACPI graphics device *
@@ -164,6 +191,8 @@ long acpi_video_get_capabilities(acpi_handle graphics_handle)* ACPI_VIDEO_BACKLIGHT_DMI_VENDOR; *} */ + +dmi_check_system (video_detect_dmi_table); }else { status =acpi_bus_get_device (graphics_handle, &tmp_dev);if (ACPI_FAILURE (status)) {
PATCH 92/173 ACPI / video: Add "Asus UL30VT" to ACPI video detect blacklist
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lan Tianyu <[email protected]>
commit d0c2ce16bec0afa6013b4c5220ca4c9c67210215 upstream.
The ACPI video driver can't control backlight correctly on Asus UL30VT. Vendor driver (asus-laptop) can work. This patch is to add "Asus UL30VT" to ACPI video detect blacklist in order to use asus-laptop for video control on the "Asus UL30VT" rather than ACPI video driver.
References: https://bugzilla.kernel.org/show_bug.cgi?id=32592
--- drivers/acpi/video_detect.c | 8 ++++++++ 1 file changed, 8 insertions(+)
drivers/acpi/video_detect.c +8 -0
@@ -156,6 +156,14 @@ static struct dmi_system_id video_detect_dmi_table[] = { DMI_MATCH(DMI_BOARD_NAME, "X360"), }, }, + { + .callback = video_detect_force_vendor, + .ident = "Asus UL30VT", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK Computer Inc."), + DMI_MATCH(DMI_PRODUCT_NAME, "UL30VT"), + }, + }, { }, };
PATCH 93/173 ACPI / PNP: Do not crash due to stale pointer use during system resume
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Rafael J. Wysocki" <[email protected]>
commit a6b5e88c0e42093b9057856f35770966c8c591e3 upstream.
During resume from system suspend the 'data' field of struct pnp_dev in pnpacpi_set_resources() may be a stale pointer, due to removal of the associated ACPI device node object in the previous suspend-resume cycle. This happens, for example, if a dockable machine is booted in the docking station and then suspended and resumed and suspended again. If that happens, pnpacpi_build_resource_template() called from pnpacpi_set_resources() attempts to use that pointer and crashes.
However, pnpacpi_set_resources() actually checks the device's ACPI handle, attempts to find the ACPI device node object attached to it and returns an error code if that fails, so in fact it knows what the correct value of dev->data should be. Use this observation to update dev->data with the correct value if necessary and dump a call trace if that's the case (once).
We still need to fix the root cause of this issue, but preventing systems from crashing because of it is an improvement too.
References: https://bugzilla.kernel.org/show_bug.cgi?id=51071
--- drivers/pnp/pnpacpi/core.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/pnp/pnpacpi/core.c +3 -0
@@ -95,6 +95,9 @@ static int pnpacpi_set_resources(struct pnp_dev *dev)return -ENODEV ; } +if (WARN_ON_ONCE (acpi_dev != dev->data)) + dev->data = acpi_dev; + ret =pnpacpi_build_resource_template (dev, &buffer);if (ret)return ret;
PATCH 94/173 ring-buffer: Fix NULL pointer if rb_set_head_page() fails
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Steven Rostedt <[email protected]>
commit 54f7be5b831254199522523ccab4c3d954bbf576 upstream.
The function rb_set_head_page() searches the list of ring buffer pages for a the page that has the HEAD page flag set. If it does not find it, it will do a WARN_ON(), disable the ring buffer and return NULL, as this should never happen.
But if this bug happens to happen, not all callers of this function can handle a NULL pointer being returned from it. That needs to be fixed.
--- kernel/trace/ring_buffer.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
kernel/trace/ring_buffer.c +5 -2
@@ -2683,7 +2683,7 @@ unsigned long ring_buffer_oldest_event_tunsigned long flags;struct ring_buffer_per_cpu *cpu_buffer;struct buffer_page *bpage; -unsigned long ret; +unsigned long ret =0 ;if (!cpumask_test_cpu (cpu, buffer->cpumask))return 0 ;
@@ -2698,7 +2698,8 @@ unsigned long ring_buffer_oldest_event_t bpage = cpu_buffer->reader_page; else bpage =rb_set_head_page (cpu_buffer); - ret = bpage->page->time_stamp; +if (bpage) + ret = bpage->page->time_stamp;raw_spin_unlock_irqrestore (&cpu_buffer->reader_lock, flags);return ret;
@@ -3005,6 +3006,8 @@ rb_get_reader_page(struct ring_buffer_pe* Splice the empty reader page into the list around the head. */ reader =rb_set_head_page (cpu_buffer); +if (!reader) + goto out; cpu_buffer->reader_page->list.next =rb_list_head (reader->list.next); cpu_buffer->reader_page->list.prev = reader->list.prev;
PATCH 95/173 firewire: net: Fix handling of fragmented multicast/broadcast packets.
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stephan Gatzka <[email protected]>
commit 9d2373420900a39f5212a3b289331aa3535b1000 upstream.
This patch fixes both the transmit and receive portion of sending fragmented mutlicast and broadcast packets.
The transmit section was broken because the offset for INTFRAG and LASTFRAG packets were just miscalculated by IEEE1394_GASP_HDR_SIZE (which was reserved with skb_push() in fwnet_send_packet).
The receive section was broken because in fwnet_incoming_packet is a call to fwnet_peer_find_by_node_id(). Called with generation == -1 it will not find a peer and the partial datagrams are associated to a peer.
[Stefan R: The fix to use context->card->generation is not perfect. It relies on the IR tasklet which processes packets from the prior bus generation to run before the self-ID-complete worklet which sets the current card generation. Alas, there is no simple way of a race-free implementation. Let's do it this way for now.]
--- drivers/firewire/net.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-)
drivers/firewire/net.c +9 -4
@@ -861,8 +861,8 @@ static void fwnet_receive_broadcast(struct fw_iso_context *context,if (specifier_id ==IANA_SPECIFIER_ID && ver ==RFC2734_SW_VERSION ) { buf_ptr +=2 ; length -=IEEE1394_GASP_HDR_SIZE ; -fwnet_incoming_packet (dev, buf_ptr, length, - source_node_id,-1 , true); +fwnet_incoming_packet (dev, buf_ptr, length, source_node_id, + context->card->generation, true); } packet.payload_length = dev->rcv_buffer_size;
@@ -958,7 +958,12 @@ static void fwnet_transmit_packet_done(struct fwnet_packet_task *ptask)break ; } -skb_pull (skb, ptask->max_payload); +if (ptask->dest_node ==IEEE1394_ALL_NODES ) { +skb_pull (skb, + ptask->max_payload +IEEE1394_GASP_HDR_SIZE ); + }else { +skb_pull (skb, ptask->max_payload); + }if (ptask->outstanding_pkts >1 ) {fwnet_make_sf_hdr (&ptask->hdr,RFC2374_HDR_INTFRAG , dg_size, fg_off, datagram_label);
@@ -1062,7 +1067,7 @@ static int fwnet_send_packet(struct fwnet_packet_task *ptask)smp_rmb (); node_id = dev->card->node_id; - p =skb_push (ptask->skb,8 ); + p =skb_push (ptask->skb,IEEE1394_GASP_HDR_SIZE );put_unaligned_be32 (node_id <<16 |IANA_SPECIFIER_ID >>8 , p);put_unaligned_be32 ((IANA_SPECIFIER_ID &0xff ) <<24 |RFC2734_SW_VERSION , &p[4 ]);
PATCH 96/173 HID: apple: Add Apple wireless keyboard 2011 ANSI PID
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexey Kaminsky <[email protected]>
commit 0a97e1e9f9a6765e6243030ac42b04694f3f3647 upstream.
--- drivers/hid/hid-apple.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/hid/hid-apple.c +3 -0
@@ -458,6 +458,9 @@ static const struct hid_device_id apple_ { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_2011_ISO), .driver_data =APPLE_NUMLOCK_EMULATION |APPLE_HAS_FN | APPLE_ISO_KEYBOARD }, + { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, + USB_DEVICE_ID_APPLE_ALU_WIRELESS_2011_ANSI), + .driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN }, { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_JIS), .driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN }, { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING_ANSI),
drivers/hid/hid-ids.h +1 -0
@@ -131,6 +131,7 @@#define USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_ANSI 0x0239#define USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_ISO 0x023a#define USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_JIS 0x023b +#define USB_DEVICE_ID_APPLE_ALU_WIRELESS_2011_ANSI 0x0255#define USB_DEVICE_ID_APPLE_ALU_WIRELESS_2011_ISO 0x0256#define USB_DEVICE_ID_APPLE_FOUNTAIN_TP_ONLY 0x030a#define USB_DEVICE_ID_APPLE_GEYSER1_TP_ONLY 0x030b
PATCH 97/173 HID: Add Apple wireless keyboard 2011 ANSI to special driver list
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ben Hutchings <[email protected]>
commit f9af7b9edccb87d4d80b58687ab63e58f3b64c4c upstream.
Commit 0a97e1e9f9a6 ('HID: apple: Add Apple wireless keyboard 2011 ANSI PID') did not update the special driver list in hid-core.c, so hid-generic may still bind to this device.
References: http://bugs.debian.org/694546
--- drivers/hid/hid-core.c | 1 + 1 file changed, 1 insertion(+)
drivers/hid/hid-core.c +1 -0
@@ -1538,6 +1538,7 @@ static const struct hid_device_id hid_have_special_driver[] = { { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_ANSI) }, { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_ISO) }, { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_JIS) }, + { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_2011_ANSI) }, { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_2011_ISO) }, { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_FOUNTAIN_TP_ONLY) }, { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER1_TP_ONLY) },
PATCH 98/173 libata: set dma_mode to 0xff in reset
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Aaron Lu <[email protected]>
commit 5416912af75de9cba5d1c75b99a7888b0bbbd2fb upstream.
ata_device->dma_mode's initial value is zero, which is not a valid dma mode, but ata_dma_enabled will return true for this value. This patch sets dma_mode to 0xff in reset function, so that ata_dma_enabled will not return true for this case, or it will cause problem for pata_acpi.
The corrsponding bugzilla page is at:
https://bugzilla.kernel.org/show_bug.cgi?id=49151
--- drivers/ata/libata-core.c | 1 + drivers/ata/libata-eh.c | 1 + 2 files changed, 2 insertions(+)
drivers/ata/libata-core.c +1 -0
@@ -2559,6 +2559,7 @@ int ata_bus_probe(struct ata_port *ap)* bus as we may be talking too fast. */ dev->pio_mode =XFER_PIO_0 ; + dev->dma_mode =0xff ;/* If the controller has a pio mode setup function * then use it to set the chipset to rights. Don't
drivers/ata/libata-eh.c +1 -0
@@ -2657,6 +2657,7 @@ int ata_eh_reset(struct ata_link *link, int classify,* bus as we may be talking too fast. */ dev->pio_mode =XFER_PIO_0 ; + dev->dma_mode =0xff ;/* If the controller has a pio mode setup function * then use it to set the chipset to rights. Don't
PATCH 99/173 s390/cio: fix pgid reserved check
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sebastian Ott <[email protected]>
commit d99e79ec5574fc556c988f613ed6175f6de66f4a upstream.
The check to whom a device is reserved is done by checking the path state of the affected channel paths. If it turns out that one path is flagged as reserved by someone else the whole device is marked as such.
However the meaning of the RESVD_ELSE bit is that the addressed device is reserved to a different pathgroup (and not reserved to a different LPAR). If we do this test on a path which is currently not a member of the pathgroup we could erroneously mark the device as reserved to someone else.
To fix this collect the reserved state for all potential members of the pathgroup and only mark the device as reserved if all of those potential members have the RESVD_ELSE bit set.
--- drivers/s390/cio/device_pgid.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
drivers/s390/cio/device_pgid.c +5 -5
@@ -234,7 +234,7 @@ static int pgid_cmp(struct pgid *p1, struct pgid *p2)* Determine pathgroup state from PGID data. */ static void pgid_analyze (struct ccw_device *cdev,struct pgid **p, -int *mismatch,int *reserved,u8 *reset) +int *mismatch,u8 *reserved,u8 *reset) {struct pgid *pgid = &cdev->private->pgid[0 ];struct pgid *first =NULL ;
@@ -248,7 +248,7 @@ static void pgid_analyze(struct ccw_device *cdev, struct pgid **p,if ((cdev->private->pgid_valid_mask & lpm) ==0 )continue ;if (pgid->inf.ps.state2 ==SNID_STATE2_RESVD_ELSE ) - *reserved =1 ; + *reserved |= lpm;if (pgid_is_reset (pgid)) { *reset |= lpm;continue ;
@@ -316,14 +316,14 @@ static void snid_done(struct ccw_device *cdev, int rc)struct subchannel *sch =to_subchannel (cdev->dev.parent);struct pgid *pgid;int mismatch =0 ; -int reserved =0 ; +u8 reserved =0 ;u8 reset =0 ;u8 donepm;if (rc) goto out;pgid_analyze (cdev, &pgid, &mismatch, &reserved, &reset); -if (reserved) +if (reserved == cdev->private->pgid_valid_mask) rc = -EUSERS ;else if (mismatch) rc = -EOPNOTSUPP ;
@@ -336,7 +336,7 @@ static void snid_done(struct ccw_device *cdev, int rc) } out:CIO_MSG_EVENT (2 ,"snid: device 0.%x.%04x: rc=%d pvm=%02x vpm=%02x " -"todo=%02x mism=%d rsvd=%d reset=%02x\n" , id->ssid, +"todo=%02x mism=%d rsvd=%02x reset=%02x\n" , id->ssid, id->devno, rc, cdev->private->pgid_valid_mask, sch->vpm, cdev->private->pgid_todo_mask, mismatch, reserved, reset);switch (rc) {
PATCH 100/173 Bluetooth: Add missing lock nesting notation
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gustavo Padovan <[email protected]>
commit dc2a0e20fbc85a71c63aa4330b496fda33f6bf80 upstream.
This patch fixes the following report, it happens when accepting rfcomm connections:
[ 228.165378] =============================================
[ 228.165378] [ INFO: possible recursive locking detected ]
[ 228.165378] 3.7.0-rc1-00536-gc1d5dc4 #120 Tainted: G W
[ 228.165378] ---------------------------------------------
[ 228.165378] bluetoothd/1341 is trying to acquire lock:
[ 228.165378] (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+...}, at:
[<ffffffffa0000aa0>] bt_accept_dequeue+0xa0/0x180 [bluetooth]
[ 228.165378]
[ 228.165378] but task is already holding lock:
[ 228.165378] (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+...}, at:
[<ffffffffa0205118>] rfcomm_sock_accept+0x58/0x2d0 [rfcomm]
[ 228.165378]
[ 228.165378] other info that might help us debug this:
[ 228.165378] Possible unsafe locking scenario:
[ 228.165378]
[ 228.165378] CPU0
[ 228.165378] ----
[ 228.165378] lock(sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM);
[ 228.165378] lock(sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM);
[ 228.165378]
[ 228.165378] *** DEADLOCK ***
[ 228.165378]
[ 228.165378] May be due to missing lock nesting notation--- net/bluetooth/rfcomm/sock.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
net/bluetooth/rfcomm/sock.c +2 -2
@@ -467,7 +467,7 @@ static int rfcomm_sock_accept(struct socket *sock, struct socket *newsock, int flong timeo;int err =0 ; -lock_sock (sk); +lock_sock_nested (sk,SINGLE_DEPTH_NESTING );if (sk->sk_type !=SOCK_STREAM ) { err = -EINVAL ;
@@ -504,7 +504,7 @@ static int rfcomm_sock_accept(struct socket *sock, struct socket *newsock, int frelease_sock (sk); timeo =schedule_timeout (timeo); -lock_sock (sk); +lock_sock_nested (sk,SINGLE_DEPTH_NESTING ); }__set_current_state (TASK_RUNNING );remove_wait_queue (sk_sleep (sk), &wait);
PATCH 101/173 ALSA: usb-audio: Avoid autopm calls after disconnection
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <[email protected]>
commit 59866da9e4ae54819e3c4e0a8f426bdb0c2ef993 upstream.
Add a similar protection against the disconnection race and the invalid use of usb instance after disconnection, as well as we've done for the USB audio PCM.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=51201
--- sound/usb/midi.c | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-)
sound/usb/midi.c +22 -1
@@ -116,6 +116,7 @@ struct snd_usb_midi {struct list_head list;struct timer_list error_timer;spinlock_t disc_lock; +struct rw_semaphore disc_rwsem;struct mutex mutex;u32 usb_id;int next_midi_device;
@@ -1038,6 +1039,12 @@ static void substream_open(struct snd_rawmidi_substream *substream, int open)struct snd_usb_midi * umidi = substream->rmidi->private_data;struct snd_kcontrol *ctl; +down_read (&umidi->disc_rwsem); +if (umidi->disconnected) { +up_read (&umidi->disc_rwsem); +return ; + } +mutex_lock (&umidi->mutex);if (open) {if (umidi->opened++ ==0 && umidi->roland_load_ctl) {
@@ -1056,6 +1063,7 @@ static void substream_open(struct snd_rawmidi_substream *substream, int open) } }mutex_unlock (&umidi->mutex); +up_read (&umidi->disc_rwsem); }static int snd_usbmidi_output_open (struct snd_rawmidi_substream *substream)
@@ -1076,8 +1084,15 @@ static int snd_usbmidi_output_open(struct snd_rawmidi_substream *substream)snd_BUG ();return -ENXIO ; } + +down_read (&umidi->disc_rwsem); +if (umidi->disconnected) { +up_read (&umidi->disc_rwsem); +return -ENODEV ; + } err =usb_autopm_get_interface (umidi->iface); port->autopm_reference = err >=0 ; +up_read (&umidi->disc_rwsem);if (err <0 && err != -EACCES )return -EIO ; substream->runtime->private_data = port;
@@ -1092,8 +1107,10 @@ static int snd_usbmidi_output_close(struct snd_rawmidi_substream *substream)struct usbmidi_out_port *port = substream->runtime->private_data;substream_open (substream,0 ); -if (port->autopm_reference) +down_read (&umidi->disc_rwsem); +if (!umidi->disconnected && port->autopm_reference)usb_autopm_put_interface (umidi->iface); +up_read (&umidi->disc_rwsem);return 0 ; }
@@ -1403,9 +1420,12 @@ void snd_usbmidi_disconnect(struct list_head* p)* a timer may submit an URB. To reliably break the cycle * a flag under lock must be used */ +down_write (&umidi->disc_rwsem);spin_lock_irq (&umidi->disc_lock); umidi->disconnected =1 ;spin_unlock_irq (&umidi->disc_lock); +up_write (&umidi->disc_rwsem); +for (i =0 ; i <MIDI_MAX_ENDPOINTS ; ++i) {struct snd_usb_midi_endpoint * ep = &umidi->endpoints[i];if (ep->out)
@@ -2117,6 +2137,7 @@ int snd_usbmidi_create(struct snd_card *card, umidi->usb_protocol_ops = &snd_usbmidi_standard_ops;init_timer (&umidi->error_timer);spin_lock_init (&umidi->disc_lock); +init_rwsem (&umidi->disc_rwsem);mutex_init (&umidi->mutex); umidi->usb_id =USB_ID (le16_to_cpu (umidi->dev->descriptor.idVendor),le16_to_cpu (umidi->dev->descriptor.idProduct));
PATCH 102/173 ALSA: usb-audio: Fix missing autopm for MIDI input
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <[email protected]>
commit f5f165418cabf2218eb466c0e94693b8b1aee88b upstream.
The commit [88a8516a: ALSA: usbaudio: implement USB autosuspend] added the support of autopm for USB MIDI output, but it didn't take the MIDI input into account.
This patch adds the following for fixing the autopm:
- Manage the URB start at the first MIDI input stream open, instead of the time of instance creation
- Move autopm code to the common substream_open()
- Make snd_usbmidi_input_start/_stop() more robust and add the running state check
--- sound/usb/midi.c | 88 ++++++++++++++++++++++++++++-------------------------- 1 file changed, 46 insertions(+), 42 deletions(-)
sound/usb/midi.c +46 -42
@@ -126,8 +126,10 @@ struct snd_usb_midi {struct snd_usb_midi_in_endpoint *in; } endpoints[MIDI_MAX_ENDPOINTS ];unsigned long input_triggered; -unsigned int opened; +bool autopm_reference; +unsigned int opened[2 ];unsigned char disconnected; +unsigned char input_running;struct snd_kcontrol *roland_load_ctl; };
@@ -149,7 +151,6 @@ struct snd_usb_midi_out_endpoint {struct snd_usb_midi_out_endpoint * ep;struct snd_rawmidi_substream *substream;int active; -bool autopm_reference;uint8_t cable;/* cable number << 4 */ uint8_t state;#define STATE_UNKNOWN 0
@@ -1034,36 +1035,58 @@ static void update_roland_altsetting(struct snd_usb_midi* umidi)snd_usbmidi_input_start (&umidi->list); } -static void substream_open (struct snd_rawmidi_substream *substream,int open) +static int substream_open (struct snd_rawmidi_substream *substream,int dir, +int open) {struct snd_usb_midi * umidi = substream->rmidi->private_data;struct snd_kcontrol *ctl; +int err;down_read (&umidi->disc_rwsem);if (umidi->disconnected) {up_read (&umidi->disc_rwsem); -return ; +return open ? -ENODEV :0 ; }mutex_lock (&umidi->mutex);if (open) { -if (umidi->opened++ ==0 && umidi->roland_load_ctl) { - ctl = umidi->roland_load_ctl; - ctl->vd[0 ].access |=SNDRV_CTL_ELEM_ACCESS_INACTIVE ; -snd_ctl_notify (umidi->card, +if (!umidi->opened[0 ] && !umidi->opened[1 ]) { + err =usb_autopm_get_interface (umidi->iface); + umidi->autopm_reference = err >=0 ; +if (err <0 && err != -EACCES ) { +mutex_unlock (&umidi->mutex); +up_read (&umidi->disc_rwsem); +return -EIO ; + } +if (umidi->roland_load_ctl) { + ctl = umidi->roland_load_ctl; + ctl->vd[0 ].access |=SNDRV_CTL_ELEM_ACCESS_INACTIVE ; +snd_ctl_notify (umidi->card,SNDRV_CTL_EVENT_MASK_INFO , &ctl->id); -update_roland_altsetting (umidi); +update_roland_altsetting (umidi); + } } + umidi->opened[dir]++; +if (umidi->opened[1 ]) +snd_usbmidi_input_start (&umidi->list); }else { -if (--umidi->opened ==0 && umidi->roland_load_ctl) { - ctl = umidi->roland_load_ctl; - ctl->vd[0 ].access &= ~SNDRV_CTL_ELEM_ACCESS_INACTIVE ; -snd_ctl_notify (umidi->card, + umidi->opened[dir]--; +if (!umidi->opened[1 ]) +snd_usbmidi_input_stop (&umidi->list); +if (!umidi->opened[0 ] && !umidi->opened[1 ]) { +if (umidi->roland_load_ctl) { + ctl = umidi->roland_load_ctl; + ctl->vd[0 ].access &= ~SNDRV_CTL_ELEM_ACCESS_INACTIVE ; +snd_ctl_notify (umidi->card,SNDRV_CTL_EVENT_MASK_INFO , &ctl->id); + } +if (umidi->autopm_reference) +usb_autopm_put_interface (umidi->iface); } }mutex_unlock (&umidi->mutex);up_read (&umidi->disc_rwsem); +return 0 ; }static int snd_usbmidi_output_open (struct snd_rawmidi_substream *substream)
@@ -1071,7 +1094,6 @@ static int snd_usbmidi_output_open(struct snd_rawmidi_substream *substream)struct snd_usb_midi * umidi = substream->rmidi->private_data;struct usbmidi_out_port * port =NULL ;int i, j; -int err;for (i =0 ; i <MIDI_MAX_ENDPOINTS ; ++i)if (umidi->endpoints[i].out)
@@ -1085,33 +1107,14 @@ static int snd_usbmidi_output_open(struct snd_rawmidi_substream *substream)return -ENXIO ; } -down_read (&umidi->disc_rwsem); -if (umidi->disconnected) { -up_read (&umidi->disc_rwsem); -return -ENODEV ; - } - err =usb_autopm_get_interface (umidi->iface); - port->autopm_reference = err >=0 ; -up_read (&umidi->disc_rwsem); -if (err <0 && err != -EACCES ) -return -EIO ; substream->runtime->private_data = port; port->state =STATE_UNKNOWN ; -substream_open (substream,1 ); -return 0 ; +return substream_open (substream,0 ,1 ); }static int snd_usbmidi_output_close (struct snd_rawmidi_substream *substream) { -struct snd_usb_midi * umidi = substream->rmidi->private_data; -struct usbmidi_out_port *port = substream->runtime->private_data; - -substream_open (substream,0 ); -down_read (&umidi->disc_rwsem); -if (!umidi->disconnected && port->autopm_reference) -usb_autopm_put_interface (umidi->iface); -up_read (&umidi->disc_rwsem); -return 0 ; +return substream_open (substream,0 ,0 ); }static void snd_usbmidi_output_trigger (struct snd_rawmidi_substream *substream,int up)
@@ -1164,14 +1167,12 @@ static void snd_usbmidi_output_drain(struct snd_rawmidi_substream *substream)static int snd_usbmidi_input_open (struct snd_rawmidi_substream *substream) { -substream_open (substream,1 ); -return 0 ; +return substream_open (substream,1 ,1 ); }static int snd_usbmidi_input_close (struct snd_rawmidi_substream *substream) { -substream_open (substream,0 ); -return 0 ; +return substream_open (substream,1 ,0 ); }static void snd_usbmidi_input_trigger (struct snd_rawmidi_substream *substream,int up)
@@ -2080,12 +2081,15 @@ void snd_usbmidi_input_stop(struct list_head* p)unsigned int i, j; umidi = list_entry(p, struct snd_usb_midi, list); +if (!umidi->input_running) +return ;for (i =0 ; i <MIDI_MAX_ENDPOINTS ; ++i) {struct snd_usb_midi_endpoint * ep = &umidi->endpoints[i];if (ep->in)for (j =0 ; j <INPUT_URBS ; ++j)usb_kill_urb (ep->in->urbs[j]); } + umidi->input_running =0 ; }static void snd_usbmidi_input_start_ep (struct snd_usb_midi_in_endpoint * ep)
@@ -2110,8 +2114,11 @@ void snd_usbmidi_input_start(struct list_head* p)int i; umidi = list_entry(p, struct snd_usb_midi, list); +if (umidi->input_running || !umidi->opened[1 ]) +return ;for (i =0 ; i <MIDI_MAX_ENDPOINTS ; ++i)snd_usbmidi_input_start_ep (umidi->endpoints[i].in); + umidi->input_running =1 ; }/*
@@ -2250,9 +2257,6 @@ int snd_usbmidi_create(struct snd_card *card, }list_add_tail (&umidi->list, midi_list); - -for (i =0 ; i <MIDI_MAX_ENDPOINTS ; ++i) -snd_usbmidi_input_start_ep (umidi->endpoints[i].in);return 0 ; }
PATCH 103/173 ACPI / video: ignore BIOS initial backlight value for HP Folio 13-2000
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zhang Rui <[email protected]>
commit 129ff8f8d58297b04f47b5d6fad81aa2d08404e1 upstream.
Or else the laptop will boot with a dimmed screen.
References: https://bugzilla.kernel.org/show_bug.cgi?id=51141
--- drivers/acpi/video.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)
drivers/acpi/video.c +14 -0
@@ -389,6 +389,12 @@ static int __init video_set_bqc_offset(const struct dmi_system_id *d)return 0 ; } +static int video_ignore_initial_backlight (const struct dmi_system_id *d) +{ + use_bios_initial_backlight =0 ; +return 0 ; +} +static struct dmi_system_id video_dmi_table[]__initdata = {/* * Broken _BQC workaround http://bugzilla.kernel.org/show_bug.cgi?id=13121
@@ -433,6 +439,14 @@ static struct dmi_system_id video_dmi_table[] __initdata = { DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 7720"), }, }, + { + .callback = video_ignore_initial_backlight, + .ident = "HP Folio 13-2000", + .matches = { + DMI_MATCH(DMI_BOARD_VENDOR, "Hewlett-Packard"), + DMI_MATCH(DMI_PRODUCT_NAME, "HP Folio 13 - 2000 Notebook PC"), + }, + }, {} };
PATCH 104/173 rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andreas Hartmann <[email protected]>
commit be03d4a45c09ee5100d3aaaedd087f19bc20d01f upstream.
There are connection stalls or very poor throughputs with rt2800 hardware using 802.11n in AP mode since patch "mac80211: retry sending failed BAR frames later instead of tearing down aggr"[1][2].
Since rt2800 hardware is not able to correctly report the tx status of BAR frames, this patch removes as workaround the existing error handling on AP side, which lets mac80211 send a BAR when an AMPDU subframe fails.
As a result, most wifi clients (aside from Intel STAs on Windows) instead will timeout now the reorder buffer and request the lost frame again.
The correct solution would be, to tear down BA session on AP side.
This patch was born on the basis of "[RFT] rt2x00: Tear down BA session on QoS frame failure"[3].
Thanks to Helmut Schaa for his support!
[1] http://thread.gmane.org/gmane.linux.kernel.wireless.general/83297/focus=83304
[2] http://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=commit;h=f0425beda4d404a6e751439b562100b902ba9c98
[3] http://thread.gmane.org/gmane.linux.drivers.rt2x00.user/569
--- drivers/net/wireless/rt2x00/rt2x00dev.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/net/wireless/rt2x00/rt2x00dev.c +4 -3
@@ -391,9 +391,10 @@ void rt2x00lib_txdone(struct queue_entry *entry, tx_info->flags |=IEEE80211_TX_STAT_AMPDU ; tx_info->status.ampdu_len =1 ; tx_info->status.ampdu_ack_len = success ?1 :0 ; - -if (!success) - tx_info->flags |=IEEE80211_TX_STAT_AMPDU_NO_BACK ; +/* +* TODO: Need to tear down BA session here +* if not successful. +*/ }if (rate_flags &IEEE80211_TX_RC_USE_RTS_CTS ) {
Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails
Quoted 7 lines · Ben Hutchings
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andreas Hartmann <[email protected]>
commit
be03d4a45c09ee5100d3aaaedd087f19bc20d01fupstream.
[...]
This patch is a workaround for
mac80211: retry sending failed BAR frames later instead of tearing down aggr (http://www.spinics.net/lists/linux-wireless/msg76379.html - f0425beda4d404a6e751439b562100b902ba9c98)
See:
http://thread.gmane.org/gmane.linux.kernel.wireless.general/83297/focus=83304
Meanwhile there was a bug report complaining about problems with be03d4a45 when used as STA:
http://thread.gmane.org/gmane.linux.drivers.rt2x00.user/1257
You can find there a few other workaround proposals.
Stanislaw Gruszka proposed here a final(?) workaround, which refines workaround be03d4a45c by shrinking it to AP function:
http://thread.gmane.org/gmane.linux.kernel.wireless.general/100793
carl9170 had the same problem with f0425beda. There it was fixed like this:
http://thread.gmane.org/gmane.linux.kernel.wireless.general/100793/focus=1405
This approach fixes the real problem (no aggregation handling by the firmware / hardware) by implementing it into the driver.
Unfortunately, I didn't see any implementation of c9122c0d63a50 for rt2x00 until now.
Kind regards,
Andreas Hartmann
Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails
Quoted 20 lines · Andreas Hartmann
Quoted 7 lines · Ben Hutchings
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andreas Hartmann <[email protected]>
commit
be03d4a45c09ee5100d3aaaedd087f19bc20d01fupstream.[...]
This patch is a workaround for
mac80211: retry sending failed BAR frames later instead of tearing down aggr (http://www.spinics.net/lists/linux-wireless/msg76379.html -
f0425beda4d404a6e751439b562100b902ba9c98)
See:
http://thread.gmane.org/gmane.linux.kernel.wireless.general/83297/focus=83304
Quoted 4 lines
Meanwhile there was a bug report complaining about problems with
be03d4a45when used as STA:
http://thread.gmane.org/gmane.linux.drivers.rt2x00.user/1257
You can find there a few other workaround proposals.
[...]
OK, I'll drop this for now. Once this is sorted out, please send to stable a complete list of fixes that are needed.
Ben.
Signature · 2 lines
Ben Hutchings It is easier to change the specification to fit the program than vice versa.
Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails
Quoted 21 lines · Ben Hutchings
Quoted 20 lines · Andreas Hartmann
Quoted 7 lines · Ben Hutchings
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andreas Hartmann <[email protected]>
commit
be03d4a45c09ee5100d3aaaedd087f19bc20d01fupstream.[...]
This patch is a workaround for
mac80211: retry sending failed BAR frames later instead of tearing down aggr (http://www.spinics.net/lists/linux-wireless/msg76379.html -
f0425beda4d404a6e751439b562100b902ba9c98)
See:
http://thread.gmane.org/gmane.linux.kernel.wireless.general/83297/focus=83304
Quoted 8 lines
Quoted 4 lines
Meanwhile there was a bug report complaining about problems with
be03d4a45when used as STA:
http://thread.gmane.org/gmane.linux.drivers.rt2x00.user/1257
You can find there a few other workaround proposals.[...]
OK, I'll drop this for now. Once this is sorted out, please send to stable a complete list of fixes that are needed.
To be clear, I have all of these in the queue:
be03d4a45c09 rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails 5b632fe85ec8 mac80211: introduce IEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAIL ab9d6e4ffe19 Revert: "rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails"
and I'm intending to drop/defer them all.
Ben.
Signature · 2 lines
Ben Hutchings It is easier to change the specification to fit the program than vice versa.
Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails
Quoted 31 lines · Ben Hutchings
Quoted 21 lines · Ben Hutchings
Quoted 20 lines · Andreas Hartmann
Quoted 7 lines · Ben Hutchings
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andreas Hartmann <[email protected]>
commit
be03d4a45c09ee5100d3aaaedd087f19bc20d01fupstream.[...]
This patch is a workaround for
mac80211: retry sending failed BAR frames later instead of tearing down aggr (http://www.spinics.net/lists/linux-wireless/msg76379.html -
f0425beda4d404a6e751439b562100b902ba9c98)
See:
http://thread.gmane.org/gmane.linux.kernel.wireless.general/83297/focus=83304Quoted 8 lines
Quoted 4 lines
Meanwhile there was a bug report complaining about problems with
be03d4a45when used as STA:
http://thread.gmane.org/gmane.linux.drivers.rt2x00.user/1257
You can find there a few other workaround proposals.[...]
OK, I'll drop this for now. Once this is sorted out, please send to stable a complete list of fixes that are needed.
Quoted 7 lines
To be clear, I have all of these in the queue:
be03d4a45c09rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails5b632fe85ec8mac80211: introduceIEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAILab9d6e4ffe19Revert: "rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails"and I'm intending to drop/defer them all.
Patch 3 is a revert of patch 1 (questioned patch). Please apply all 3 patches, or only patch 2.
Stanislaw
Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails
Quoted 10 lines · Stanislaw Gruszka
Quoted 7 lines
To be clear, I have all of these in the queue:
be03d4a45c09rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails5b632fe85ec8mac80211: introduceIEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAILab9d6e4ffe19Revert: "rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails"and I'm intending to drop/defer them all.
Patch 3 is a revert of patch 1 (questioned patch). Please apply all 3 patches, or only patch 2.
No, actually all 3 patches have to be applied. Because last one, except revert, include flag IEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAIL setting in rt2x00 driver, which make patch 2 work.
Stanislaw
Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails
Quoted 7 lines · Stanislaw Gruszka
Quoted 6 lines · Stanislaw Gruszka
Quoted 6 lines
To be clear, I have all of these in the queue:
be03d4a45c09rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails5b632fe85ec8mac80211: introduceIEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAILab9d6e4ffe19Revert: "rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails"
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
and I'm intending to drop/defer them all.
Patch 3 is a revert of patch 1 (questioned patch). Please apply all 3 patches, or only patch 2.
No, actually all 3 patches have to be applied. Because last one, except revert, include flag
IEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAILsetting in rt2x00 driver, which make patch 2 work.
Andreas said that that after ab9d6e4ffe19 there was still a regression. But maybe he was confused. I know I'm confused.
Ben.
Signature · 2 lines
Ben Hutchings If you seem to know what you are doing, you'll be given more to do.
Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails
Quoted 13 lines · Ben Hutchings
Quoted 12 lines · Stanislaw Gruszka
Quoted 10 lines · Stanislaw Gruszka
Quoted 7 lines
To be clear, I have all of these in the queue:
be03d4a45c09rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails5b632fe85ec8mac80211: introduceIEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAILab9d6e4ffe19Revert: "rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails"and I'm intending to drop/defer them all.
Patch 3 is a revert of patch 1 (questioned patch). Please apply all 3 patches, or only patch 2.
Quoted 6 lines
Quoted 3 lines
No, actually all 3 patches have to be applied. Because last one, except revert, include flag
IEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAILsetting in rt2x00 driver, which make patch 2 work.Andreas said that that after
ab9d6e4ffe19there was still a regression. But maybe he was confused. I know I'm confused.
:-))
No, the thing is:
rt2800pci misses an appropriate handling of aggregation (which meets the requirements of mac80211).
Both workarounds, mine and the new workaround from Stanislaw (which is nothing more than a restricted version of my initial workaround), work like this:
Let the peer do the aggregation handling. If it's not done by the peer, the connection will break down.
Therefore:
The solution would be IMHO, to implement an own aggregation handling, maybe the same way as it was done for carl9170, which had the same problem:
http://thread.gmane.org/gmane.linux.kernel.wireless.general/100793/focus=1405
I prefer to have solutions (if one is known) instead of another workaround. If I use my device as STA instead of an AP, it even works fine w/o Stanislaws patch. Do you understand what I'm trying to say?
Thanks,
kind regards,
Andreas
Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails
Quoted 6 lines · Andreas Hartmann
The solution would be IMHO, to implement an own aggregation handling, maybe the same way as it was done for carl9170, which had the same problem:
http://thread.gmane.org/gmane.linux.kernel.wireless.general/100793/focus=1405
I prefer to have solutions (if one is known) instead of another workaround.
JFI, I'm just working on exactly that (handling BAR TX status in driver to implement
proper RX reorder window flushing at the peer). I'll post it for further testing to the
rt2x00 list once I'm done.
Helmut
Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails
Hello Helmut!
Quoted 5 lines · Helmut Schaa
Quoted 3 lines · Andreas Hartmann
The solution would be IMHO, to implement an own aggregation handling, maybe the same way as it was done for carl9170, which had the same problem:
Quoted 7 lines
Quoted 3 lines
http://thread.gmane.org/gmane.linux.kernel.wireless.general/100793/focus=1405
I prefer to have solutions (if one is known) instead of another workaround.
JFI, I'm just working on exactly that (handling BAR TX status in driver to implement proper RX reorder window flushing at the peer). I'll post it for further testing to the rt2x00 list once I'm done.
Thank you for your time spent on this problem! I really appreciate it!
Kind regards!
Andreas
Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails
In reply to Andreas HartmannQuoted 11 lines · Andreas Hartmann
Quoted 10 lines · Ben Hutchings
Quoted 9 lines · Stanislaw Gruszka
Quoted 8 lines · Stanislaw Gruszka
Quoted 7 lines
To be clear, I have all of these in the queue:
be03d4a45c09rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails5b632fe85ec8mac80211: introduceIEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAILab9d6e4ffe19Revert: "rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails"and I'm intending to drop/defer them all.
Quoted 8 lines
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
Patch 3 is a revert of patch 1 (questioned patch). Please apply all 3 patches, or only patch 2.
No, actually all 3 patches have to be applied. Because last one, except revert, include flag
IEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAILsetting in rt2x00 driver, which make patch 2 work.Andreas said that that after
ab9d6e4ffe19there was still a regression.
That's not true. There will be no regression after ab9d6e4ffe20. The only thing is that solution is not perfect. But perfect solution require lot of changes i.e. is not -stable appropriate (and does not exist currently).
Quoted 9 lines
Quoted 1 line
But maybe he was confused. I know I'm confused.
:-))
No, the thing is:
rt2800pci misses an appropriate handling of aggregation (which meets the requirements of mac80211).Both workarounds, mine and the new workaround from Stanislaw (which is nothing more than a restricted version of my initial workaround), work
Your workaround broke STA mode on some environment.
Stanislaw
Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails
Quoted 28 lines · Stanislaw Gruszka
Quoted 11 lines · Andreas Hartmann
Quoted 10 lines · Ben Hutchings
Quoted 9 lines · Stanislaw Gruszka
Quoted 8 lines · Stanislaw Gruszka
Quoted 7 lines
To be clear, I have all of these in the queue:
be03d4a45c09rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails5b632fe85ec8mac80211: introduceIEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAILab9d6e4ffe19Revert: "rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails"and I'm intending to drop/defer them all.
Quoted 8 lines
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
Patch 3 is a revert of patch 1 (questioned patch). Please apply all 3 patches, or only patch 2.
No, actually all 3 patches have to be applied. Because last one, except revert, include flag
IEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAILsetting in rt2x00 driver, which make patch 2 work.Andreas said that that after
ab9d6e4ffe19there was still a regression.That's not true. There will be no regression after
ab9d6e4ffe20. The only thing is that solution is not perfect. But perfect solution require lot of changes i.e. is not -stable appropriate (and does not exist currently).Quoted 3 lines
Quoted 1 line
But maybe he was confused. I know I'm confused.
:-))
Quoted 8 lines
Quoted 6 lines
No, the thing is:
rt2800pci misses an appropriate handling of aggregation (which meets the requirements of mac80211).Both workarounds, mine and the new workaround from Stanislaw (which is nothing more than a restricted version of my initial workaround), work
Your workaround broke STA mode on some environment.
Why are you sure, that this workaround doesn't break some other devices running in AP mode? We believed at that time too, it wouldn't harm even STA. But this was wrong for some (which?) devices.
Anyway: As Helmut meanwhile mentioned that he thankfully works on a solution now, I'm fine with the second round of workaround.
Kind regards,
Andreas
Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails
Quoted 33 lines · Andreas Hartmann
Quoted 32 lines · Stanislaw Gruszka
Quoted 11 lines · Andreas Hartmann
Quoted 10 lines · Ben Hutchings
Quoted 9 lines · Stanislaw Gruszka
Quoted 8 lines · Stanislaw Gruszka
Quoted 7 lines
To be clear, I have all of these in the queue:
be03d4a45c09rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails5b632fe85ec8mac80211: introduceIEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAILab9d6e4ffe19Revert: "rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails"and I'm intending to drop/defer them all.
Quoted 8 lines
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
Patch 3 is a revert of patch 1 (questioned patch). Please apply all 3 patches, or only patch 2.
No, actually all 3 patches have to be applied. Because last one, except revert, include flag
IEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAILsetting in rt2x00 driver, which make patch 2 work.Andreas said that that after
ab9d6e4ffe19there was still a regression.That's not true. There will be no regression after
ab9d6e4ffe20. The only thing is that solution is not perfect. But perfect solution require lot of changes i.e. is not -stable appropriate (and does not exist currently).Quoted 7 lines
Quoted 1 line
But maybe he was confused. I know I'm confused.
:-))
No, the thing is:
rt2800pci misses an appropriate handling of aggregation (which meets the requirements of mac80211).
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
Both workarounds, mine and the new workaround from Stanislaw (which is nothing more than a restricted version of my initial workaround), work
Your workaround broke STA mode on some environment.
Why are you sure, that this workaround doesn't break some other devices running in AP mode? We believed at that time too, it wouldn't harm even STA. But this was wrong for some (which?) devices.
Because it make behaviour the same as it was before 3.2, which introduce those issues.
Stanislaw
Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails
Hello Stanislaw!
Quoted 37 lines · Stanislaw Gruszka
Quoted 36 lines · Andreas Hartmann
Quoted 35 lines · Stanislaw Gruszka
Quoted 11 lines · Andreas Hartmann
Quoted 10 lines · Ben Hutchings
Quoted 9 lines · Stanislaw Gruszka
Quoted 8 lines · Stanislaw Gruszka
Quoted 7 lines
To be clear, I have all of these in the queue:
be03d4a45c09rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails5b632fe85ec8mac80211: introduceIEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAILab9d6e4ffe19Revert: "rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails"and I'm intending to drop/defer them all.
Quoted 8 lines
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
Patch 3 is a revert of patch 1 (questioned patch). Please apply all 3 patches, or only patch 2.
No, actually all 3 patches have to be applied. Because last one, except revert, include flag
IEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAILsetting in rt2x00 driver, which make patch 2 work.Andreas said that that after
ab9d6e4ffe19there was still a regression.That's not true. There will be no regression after
ab9d6e4ffe20. The only thing is that solution is not perfect. But perfect solution require lot of changes i.e. is not -stable appropriate (and does not exist currently).Quoted 9 lines
Quoted 1 line
But maybe he was confused. I know I'm confused.
:-))
No, the thing is:
rt2800pci misses an appropriate handling of aggregation (which meets the requirements of mac80211).Both workarounds, mine and the new workaround from Stanislaw (which is nothing more than a restricted version of my initial workaround), work
Quoted 8 lines
Quoted 5 lines
Quoted 1 line
Your workaround broke STA mode on some environment.
Why are you sure, that this workaround doesn't break some other devices running in AP mode? We believed at that time too, it wouldn't harm even STA. But this was wrong for some (which?) devices.
Because it make behaviour the same as it was before 3.2, which introduce those issues.
You're so right, Stanislaw! I should have better looked again at your patch before writing those stupid lines about differentiation between STA and AP.
Please apologize!
Kind regards,
Andreas
Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails
In reply to Stanislaw GruszkaQuoted 37 lines · Stanislaw Gruszka
Quoted 36 lines · Andreas Hartmann
Quoted 35 lines · Stanislaw Gruszka
Quoted 11 lines · Andreas Hartmann
Quoted 10 lines · Ben Hutchings
Quoted 9 lines · Stanislaw Gruszka
Quoted 8 lines · Stanislaw Gruszka
Quoted 7 lines
To be clear, I have all of these in the queue:
be03d4a45c09rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails5b632fe85ec8mac80211: introduceIEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAILab9d6e4ffe19Revert: "rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails"and I'm intending to drop/defer them all.
Quoted 8 lines
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
Patch 3 is a revert of patch 1 (questioned patch). Please apply all 3 patches, or only patch 2.
No, actually all 3 patches have to be applied. Because last one, except revert, include flag
IEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAILsetting in rt2x00 driver, which make patch 2 work.Andreas said that that after
ab9d6e4ffe19there was still a regression.That's not true. There will be no regression after
ab9d6e4ffe20. The only thing is that solution is not perfect. But perfect solution require lot of changes i.e. is not -stable appropriate (and does not exist currently).Quoted 9 lines
Quoted 1 line
But maybe he was confused. I know I'm confused.
:-))
No, the thing is:
rt2800pci misses an appropriate handling of aggregation (which meets the requirements of mac80211).Both workarounds, mine and the new workaround from Stanislaw (which is nothing more than a restricted version of my initial workaround), work
Quoted 8 lines
Quoted 5 lines
Quoted 1 line
Your workaround broke STA mode on some environment.
Why are you sure, that this workaround doesn't break some other devices running in AP mode? We believed at that time too, it wouldn't harm even STA. But this was wrong for some (which?) devices.
Because it make behaviour the same as it was before 3.2, which introduce those issues.
After reviewing the various changes, I agree that applying the three patches looks like it will restore the old (3.1) behaviour of rt2x00. I have reinstated them in the queue for the next 3.2 update.
Ben.
Signature · 3 lines
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
A fail-safe circuit will destroy others.Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails
In reply to Stanislaw GruszkaQuoted 4 lines · Stanislaw Gruszka
Quoted 2 lines · Ben Hutchings
To be clear, I have all of these in the queue:
Quoted 8 lines
Quoted 5 lines
be03d4a45c09rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails5b632fe85ec8mac80211: introduceIEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAILab9d6e4ffe19Revert: "rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails"and I'm intending to drop/defer them all.
Patch 3 is a revert of patch 1 (questioned patch). Please apply all 3 patches, or only patch 2.
Despite its title, isn't patch 3 not exactly a revert? It includes a change that depends on patch 2. I don't think patch 2 alone would have any effect.
Jonathan
Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails
Quoted 9 lines · Jonathan Nieder
Quoted 8 lines · Stanislaw Gruszka
Quoted 6 lines · Ben Hutchings
To be clear, I have all of these in the queue:
be03d4a45c09rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails5b632fe85ec8mac80211: introduceIEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAILab9d6e4ffe19Revert: "rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails"
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
and I'm intending to drop/defer them all.
Patch 3 is a revert of patch 1 (questioned patch). Please apply all 3 patches, or only patch 2.
Despite its title, isn't patch 3 not exactly a revert? It includes a change that depends on patch 2. I don't think patch 2 alone would have any effect.
Yes, all 3 patches should go in.
Stanislaw
PATCH 105/173 mac80211: introduce IEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAIL
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stanislaw Gruszka <[email protected]>
commit 5b632fe85ec82e5c43740b52e74c66df50a37db3 upstream.
Commit f0425beda4d404a6e751439b562100b902ba9c98 "mac80211: retry sending failed BAR frames later instead of tearing down aggr" caused regression on rt2x00 hardware (connection hangs). This regression was fixed by commit be03d4a45c09ee5100d3aaaedd087f19bc20d01 "rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails". But the latter commit caused yet another problem reported in
https://bugzilla.kernel.org/show_bug.cgi?id=42828#c22
After long discussion in this thread:
http://mid.gmane.org/[email protected]
and testing various alternative solutions, which failed on one or other setup, we have no other good fix for the issues like just revert both mentioned earlier commits.
To do not affect other hardware which benefit from commit f0425beda4d404a6e751439b562100b902ba9c98, instead of reverting it, introduce flag that when used will restore mac80211 behaviour before the commit.
--- include/net/mac80211.h | 5 +++++ net/mac80211/status.c | 6 +++++- 2 files changed, 10 insertions(+), 1 deletion(-)
include/net/mac80211.h +5 -0
@@ -1128,6 +1128,10 @@ enum sta_notify_cmd {* @IEEE80211_HW_TX_AMPDU_SETUP_IN_HW: The device handles TX A-MPDU session * setup strictly in HW. mac80211 should not attempt to do this in * software. +* +* @IEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAIL: On this hardware TX BA session +* should be tear down once BAR frame will not be acked. +* */ enum ieee80211_hw_flags {IEEE80211_HW_HAS_RATE_CONTROL =1 <<0 ,
@@ -1154,6 +1158,7 @@ enum ieee80211_hw_flags {IEEE80211_HW_SUPPORTS_PER_STA_GTK =1 <<21 ,IEEE80211_HW_AP_LINK_PS =1 <<22 ,IEEE80211_HW_TX_AMPDU_SETUP_IN_HW =1 <<23 , + IEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAIL = 1<<26, };/**
net/mac80211/status.c +5 -1
@@ -429,7 +429,11 @@ void ieee80211_tx_status(struct ieee8021 IEEE80211_BAR_CTRL_TID_INFO_MASK) >>IEEE80211_BAR_CTRL_TID_INFO_SHIFT ; -ieee80211_set_bar_pending (sta, tid, ssn); +if (local->hw.flags & +IEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAIL ) +ieee80211_stop_tx_ba_session (&sta->sta, tid); +else +ieee80211_set_bar_pending (sta, tid, ssn); } }
PATCH 106/173 Revert: "rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails"
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stanislaw Gruszka <[email protected]>
commit ab9d6e4ffe192427ce9e93d4f927b0faaa8a941e upstream.
This revert:
commit be03d4a45c09ee5100d3aaaedd087f19bc20d01f
Author: Andreas Hartmann <[email protected]> Date: Tue Apr 17 00:25:28 2012 +0200
rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails
To fix problem workaround by above commit use IEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAIL flag (see change log for "mac80211: introduce IEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAIL" patch).
Resolve: https://bugzilla.kernel.org/show_bug.cgi?id=42828
--- drivers/net/wireless/rt2x00/rt2800lib.c | 3 ++- drivers/net/wireless/rt2x00/rt2x00dev.c | 7 +++---- 2 files changed, 5 insertions(+), 5 deletions(-)
drivers/net/wireless/rt2x00/rt2800lib.c +2 -1
@@ -4208,7 +4208,8 @@ int rt2800_probe_hw_mode(struct rt2x00_dIEEE80211_HW_SIGNAL_DBM |IEEE80211_HW_SUPPORTS_PS |IEEE80211_HW_PS_NULLFUNC_STACK | -IEEE80211_HW_AMPDU_AGGREGATION ; +IEEE80211_HW_AMPDU_AGGREGATION | +IEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAIL ;/* * Don't set IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING for USB devices * unless we are capable of sending the buffered frames out after the
drivers/net/wireless/rt2x00/rt2x00dev.c +3 -4
@@ -387,10 +387,9 @@ void rt2x00lib_txdone(struct queue_entry tx_info->flags |=IEEE80211_TX_STAT_AMPDU ; tx_info->status.ampdu_len =1 ; tx_info->status.ampdu_ack_len = success ?1 :0 ; -/* -* TODO: Need to tear down BA session here -* if not successful. -*/ + +if (!success) + tx_info->flags |=IEEE80211_TX_STAT_AMPDU_NO_BACK ; }if (rate_flags &IEEE80211_TX_RC_USE_RTS_CTS ) {
PATCH 107/173 x86,AMD: Power driver support for AMDs family 16h processors
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Boris Ostrovsky <[email protected]>
commit 22e32f4f57778ebc6e17812fa3008361c05d64f9 upstream.
Add family 16h PCI ID to AMD's power driver to allow it report power consumption on these processors.
--- drivers/hwmon/fam15h_power.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/hwmon/fam15h_power.c +4 -0
@@ -31,6 +31,9 @@ MODULE_DESCRIPTION("AMD Family 15h CPU pMODULE_AUTHOR ("Andreas Herrmann <[email protected]>" );MODULE_LICENSE ("GPL" ); +/* Family 16h Northbridge's function 4 PCI ID */ +#define PCI_DEVICE_ID_AMD_16H_NB_F4 0x1534 +/* D18F3 */ #define REG_NORTHBRIDGE_CAP 0xe8
@@ -256,6 +259,7 @@ static void __devexit fam15h_power_removstatic DEFINE_PCI_DEVICE_TABLE (fam15h_power_id_table) = { {PCI_VDEVICE (AMD ,PCI_DEVICE_ID_AMD_15H_NB_F4 ) }, + {PCI_VDEVICE (AMD ,PCI_DEVICE_ID_AMD_16H_NB_F4 ) }, {} };MODULE_DEVICE_TABLE (pci, fam15h_power_id_table);
PATCH 108/173 target/file: Fix 32-bit highmem breakage for SGL -> iovec mapping
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sebastian Andrzej Siewior <[email protected]>
commit 40ff2c3b3da35dd3a00ac6722056a59b4b3f2caf upstream.
This patch changes vectored file I/O to use kmap + kunmap when mapping incoming SGL memory -> struct iovec in order to properly support 32-bit highmem configurations. This is because an extra bounce buffer may be required when processing scatterlist pages allocated with GFP_KERNEL.
--- drivers/target/target_core_file.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
drivers/target/target_core_file.c +7 -2
@@ -300,7 +300,7 @@ static int fd_do_readv(struct se_task *tfor_each_sg (task->task_sg, sg, task->task_sg_nents, i) { iov[i].iov_len = sg->length; - iov[i].iov_base =sg_virt (sg); + iov[i].iov_base =kmap (sg_page (sg)) + sg->offset; } old_fs =get_fs ();
@@ -308,6 +308,8 @@ static int fd_do_readv(struct se_task *t ret =vfs_readv (fd, &iov[0 ], task->task_sg_nents, &pos);set_fs (old_fs); +for_each_sg (task->task_sg, sg, task->task_sg_nents, i) +kunmap (sg_page (sg));kfree (iov);/* * Return zeros and GOOD status even if the READ did not return
@@ -353,7 +355,7 @@ static int fd_do_writev(struct se_task *for_each_sg (task->task_sg, sg, task->task_sg_nents, i) { iov[i].iov_len = sg->length; - iov[i].iov_base =sg_virt (sg); + iov[i].iov_base =kmap (sg_page (sg)) + sg->offset; } old_fs =get_fs ();
@@ -361,6 +363,9 @@ static int fd_do_writev(struct se_task * ret =vfs_writev (fd, &iov[0 ], task->task_sg_nents, &pos);set_fs (old_fs); +for_each_sg (task->task_sg, sg, task->task_sg_nents, i) +kunmap (sg_page (sg)); +kfree (iov);if (ret <0 || ret != task->task_size) {
PATCH 109/173 drm/i915: Close race between processing unpin task and queueing the flip
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chris Wilson <[email protected]>
commit e7d841ca03b7ab668620045cd7b428eda9f41601 upstream.
Before queuing the flip but crucially after attaching the unpin-work to the crtc, we continue to setup the unpin-work. However, should the hardware fire early, we see the connected unpin-work and queue the task. The task then promptly runs and unpins the fb before we finish taking the required references or even pinning it... Havoc.
To close the race, we use the flip-pending atomic to indicate when the flip is finally setup and enqueued. So during the flip-done processing, we can check more accurately whether the flip was expected.
v2: Add the appropriate mb() to ensure that the writes to the page-flip worker are complete prior to marking it active and emitting the MI_FLIP. On the read side, the mb should be enforced by the spinlocks.
[danvet: Review the barriers a bit, we need a write barrier both before and after updating ->pending. Similarly we need a read barrier in the interrupt handler both before and after reading ->pending. With well-ordered irqs only one barrier in each place should be required, but since this patch explicitly sets out to combat spurious interrupts with is staged activation of the unpin work we need to go full-bore on the barriers, too. Discussed with Chris Wilson on irc and changes acked by him.]
--- drivers/gpu/drm/i915/i915_debugfs.c | 4 ++-- drivers/gpu/drm/i915/i915_irq.c | 4 +++- drivers/gpu/drm/i915/intel_display.c | 39 ++++++++++++++++++++++++++++------ drivers/gpu/drm/i915/intel_drv.h | 5 ++++- 4 files changed, 41 insertions(+), 11 deletions(-)
drivers/gpu/drm/i915/i915_debugfs.c +2 -2
@@ -339,7 +339,7 @@ static int i915_gem_pageflip_info(structseq_printf (m,"No flip due on pipe %c (plane %c)\n" , pipe, plane); }else { -if (!work->pending) { +if (atomic_read (&work->pending) <INTEL_FLIP_COMPLETE ) {seq_printf (m,"Flip queued on pipe %c (plane %c)\n" , pipe, plane); }else {
@@ -350,7 +350,7 @@ static int i915_gem_pageflip_info(structseq_printf (m,"Stall check enabled, " ); else seq_printf(m, "Stall check waiting for page flip ioctl, "); -seq_printf (m,"%d prepares\n" , work->pending); +seq_printf (m,"%d prepares\n" ,atomic_read (&work->pending));if (work->old_fb_obj) {struct drm_i915_gem_object *obj = work->old_fb_obj;
drivers/gpu/drm/i915/i915_irq.c +3 -1
@@ -1187,7 +1187,9 @@ static void i915_pageflip_stall_check(stspin_lock_irqsave (&dev->event_lock, flags); work = intel_crtc->unpin_work; -if (work ==NULL || work->pending || !work->enable_stall_check) { +if (work ==NULL || +atomic_read (&work->pending) >=INTEL_FLIP_COMPLETE || + !work->enable_stall_check) {/* Either the pending flip IRQ arrived, or we're too early. Don't check */ spin_unlock_irqrestore (&dev->event_lock, flags);return ;
drivers/gpu/drm/i915/intel_display.c +32 -7
@@ -6949,11 +6949,18 @@ static void do_intel_finish_page_flip(stspin_lock_irqsave (&dev->event_lock, flags); work = intel_crtc->unpin_work; -if (work ==NULL || !work->pending) { + +/* Ensure we don't miss a work->pending update ... */ +smp_rmb (); + +if (work ==NULL ||atomic_read (&work->pending) <INTEL_FLIP_COMPLETE ) {spin_unlock_irqrestore (&dev->event_lock, flags);return ; } +/* and that the unpin work is consistent wrt ->pending. */ +smp_rmb (); + intel_crtc->unpin_work =NULL ;if (work->event) {
@@ -7025,16 +7032,25 @@ void intel_prepare_page_flip(struct drm_to_intel_crtc (dev_priv->plane_to_crtc_mapping[plane]);unsigned long flags; +/* NB: An MMIO update of the plane base pointer will also +* generate a page-flip completion irq, i.e. every modeset +* is also accompanied by a spurious intel_prepare_page_flip(). +*/ spin_lock_irqsave (&dev->event_lock, flags); -if (intel_crtc->unpin_work) { -if ((++intel_crtc->unpin_work->pending) >1 ) -DRM_ERROR ("Prepared flip multiple times\n" ); - }else { -DRM_DEBUG_DRIVER ("preparing flip with no unpin work?\n" ); - } +if (intel_crtc->unpin_work) +atomic_inc_not_zero (&intel_crtc->unpin_work->pending);spin_unlock_irqrestore (&dev->event_lock, flags); } +inline static void intel_mark_page_flip_active (struct intel_crtc *intel_crtc) +{ +/* Ensure that the work item is consistent when activating it ... */ +smp_wmb (); +atomic_set (&intel_crtc->unpin_work->pending,INTEL_FLIP_PENDING ); +/* and that it is marked active as soon as the irq could fire. */ +smp_wmb (); +} + static int intel_gen2_queue_flip(struct drm_device *dev, struct drm_crtc *crtc, struct drm_framebuffer *fb,
@@ -7071,6 +7087,8 @@ static int intel_gen2_queue_flip(structOUT_RING (fb->pitch);OUT_RING (obj->gtt_offset + offset);OUT_RING (MI_NOOP ); + +intel_mark_page_flip_active (intel_crtc);ADVANCE_LP_RING ();return 0 ;
@@ -7114,6 +7132,7 @@ static int intel_gen3_queue_flip(structOUT_RING (obj->gtt_offset + offset);OUT_RING (MI_NOOP ); +intel_mark_page_flip_active (intel_crtc);ADVANCE_LP_RING ();return 0 ;
@@ -7157,6 +7176,10 @@ static int intel_gen4_queue_flip(struct pf =0 ; pipesrc =I915_READ (PIPESRC (intel_crtc->pipe)) &0x0fff0fff ;OUT_RING (pf | pipesrc); + +intel_mark_page_flip_active (intel_crtc); + +intel_mark_page_flip_active (intel_crtc);ADVANCE_LP_RING ();return 0 ;
@@ -7246,6 +7269,8 @@ static int intel_gen7_queue_flip(structintel_ring_emit (ring, (fb->pitch | obj->tiling_mode));intel_ring_emit (ring, (obj->gtt_offset));intel_ring_emit (ring, (MI_NOOP )); + +intel_mark_page_flip_active (intel_crtc);intel_ring_advance (ring);return 0 ;
drivers/gpu/drm/i915/intel_drv.h +4 -1
@@ -257,7 +257,10 @@ struct intel_unpin_work {struct drm_i915_gem_object *old_fb_obj;struct drm_i915_gem_object *pending_flip_obj;struct drm_pending_vblank_event *event; -int pending; +atomic_t pending; +#define INTEL_FLIP_INACTIVE 0 +#define INTEL_FLIP_PENDING 1 +#define INTEL_FLIP_COMPLETE 2bool enable_stall_check; };
Re: [ 109/173] drm/i915: Close race between processing unpin task and queueing the flip
Quoted 8 lines · Ben Hutchings
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chris Wilson <[email protected]>
commit
e7d841ca03b7ab668620045cd7b428eda9f41601upstream.
[...]
Review static int intel_gen4_queue_flip(struct · line 7185
Quoted 11 lines
(quoted diff) +4
-0@@ -7157,6 +7176,10 @@ static int intel_gen4_queue_flip(struct pf = 0; pipesrc = I915_READ(PIPESRC(intel_crtc->pipe)) & 0x0fff0fff; OUT_RING(pf | pipesrc); + + intel_mark_page_flip_active(intel_crtc); + + intel_mark_page_flip_active(intel_crtc); ADVANCE_LP_RING(); return 0;
There is a problem with this patch on 3.2. First we have intel_mark_page_flip_active duplicated on intel_gen4_queue_flip here (harmless), but one missing call for it in intel_gen6_queue_flip
Reached to this after reproducing which is probably the same problem people are reporting here: http://bugs.launchpad.net/bugs/1119809
A bisect pointed to this change, and the following diff fixed the issue on the i915 based machine I used to reproduce:
drivers/gpu/drm/i915/intel_display.c +2 -2
@@ -7155,8 +7155,6 @@ static int intel_gen4_queue_flip(struct drm_device *dev,OUT_RING (pf | pipesrc);intel_mark_page_flip_active (intel_crtc); - -intel_mark_page_flip_active (intel_crtc);ADVANCE_LP_RING ();return 0 ;
@@ -7192,6 +7190,8 @@ static int intel_gen6_queue_flip(struct drm_device *dev, pf =I915_READ (PF_CTL (intel_crtc->pipe)) &PF_ENABLE ; pipesrc =I915_READ (PIPESRC (intel_crtc->pipe)) &0x0fff0fff ;OUT_RING (pf | pipesrc); + +intel_mark_page_flip_active (intel_crtc);ADVANCE_LP_RING ();return 0 ;
Signature · 2 lines
[]'s Herton
Re: [ 109/173] drm/i915: Close race between processing unpin task and queueing the flip
Quoted 10 lines · Herton Ronaldo Krzesinski
Quoted 8 lines · Ben Hutchings
3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chris Wilson <[email protected]>
commit
e7d841ca03b7ab668620045cd7b428eda9f41601upstream.[...]
Quoted 15 lines
drivers/gpu/drm/i915/intel_display.c static int intel_gen4_queue_flip(struct · line 7185
Quoted 11 lines
drivers/gpu/drm/i915/intel_display.c +4
-0@@ -7157,6 +7176,10 @@ static int intel_gen4_queue_flip(struct pf =0 ; pipesrc =I915_READ (PIPESRC (intel_crtc->pipe)) &0x0fff0fff ;OUT_RING (pf | pipesrc); + +intel_mark_page_flip_active (intel_crtc); + +intel_mark_page_flip_active (intel_crtc);ADVANCE_LP_RING ();return 0 ;There is a problem with this patch on 3.2. First we have
intel_mark_page_flip_activeduplicated onintel_gen4_queue_fliphere (harmless), but one missing call for it inintel_gen6_queue_flip
Yes, Julien Cristau also pointed this out. I'm not sure how this happened.
It does seem that quilt (presumably calling GNU patch?) can sometimes apply two hunks that overlap, and maybe that's part of the explanation for this. In 3.2.38 there was one patch where a blank line was the last line of context in one hunk and also the first line of context for the next hunk. (Upstream, there was an extra statement in between, but this was not present in 3.2.y.) quilt applied the patch without complaint (with --fuzz=0) but git am rejected it.
Quoted 19 lines
Reached to this after reproducing which is probably the same problem people are reporting here: http://bugs.launchpad.net/bugs/1119809
A bisect pointed to this change, and the following diff fixed the issue on the i915 based machine I used to reproduce:drivers/gpu/drm/i915/intel_display.c +0
-2@@ -7155,8 +7155,6 @@ static int intel_gen4_queue_flip(struct drm_device *dev,OUT_RING (pf | pipesrc);intel_mark_page_flip_active (intel_crtc); - -intel_mark_page_flip_active (intel_crtc);ADVANCE_LP_RING ();return 0 ;
drivers/gpu/drm/i915/intel_display.c static int intel_gen6_queue_flip(struct drm_device *dev, · line 7197
Quoted 8 lines
drivers/gpu/drm/i915/intel_display.c +2
-0@@ -7192,6 +7190,8 @@ static int intel_gen6_queue_flip(struct drm_device *dev, pf =I915_READ (PF_CTL (intel_crtc->pipe)) &PF_ENABLE ; pipesrc =I915_READ (PIPESRC (intel_crtc->pipe)) &0x0fff0fff ;OUT_RING (pf | pipesrc); + +intel_mark_page_flip_active (intel_crtc);ADVANCE_LP_RING ();return 0 ;
Thanks, but I have the same fix in the patch queue already.
Ben.
Signature · 3 lines
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert CamusPATCH 110/173 pnpacpi: fix incorrect TEST_ALPHA() test
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alan Cox <[email protected]>
commit cdc87c5a30f407ed1ce43d8a22261116873d5ef1 upstream.
TEST_ALPHA() is broken and always returns 0.
--- drivers/pnp/pnpacpi/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/pnp/pnpacpi/core.c +1 -1
@@ -58,7 +58,7 @@ static inline int __init is_exclusive_device(struct acpi_device *dev)if (!(('0' <= (c ) && (c) <='9' ) || ('A' <= (c ) && (c) <='F' ))) \ return 0#define TEST_ALPHA (c) \ - if (!('@' <= (c) || (c) <= 'Z')) \ + if (!('A' <= (c) && (c) <= 'Z')) \ return 0static int __init ispnpidacpi (const char *id) {
PATCH 111/173 drm/radeon/kms: use frac fb div on APUs
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <[email protected]>
commit 37d4174d2d252c37dcb3d88cafae488542087848 upstream.
Seems to be more stable on certain monitors.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=48880
--- drivers/gpu/drm/radeon/atombios_crtc.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/gpu/drm/radeon/atombios_crtc.c +3 -0
@@ -575,6 +575,9 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,if (rdev->family <CHIP_RV770 ) pll->flags |=RADEON_PLL_PREFER_MINM_OVER_MAXP ; +/* use frac fb div on APUs */ +if (ASIC_IS_DCE41 (rdev)) + pll->flags |=RADEON_PLL_USE_FRAC_FB_DIV ; }else { pll->flags |=RADEON_PLL_LEGACY ;
PATCH 112/173 drm/radeon/dce32+: use fractional fb dividers for high clocks
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <[email protected]>
commit a02dc74b317d78298cb0587b9b1f6f741fd5c139 upstream.
Fixes flickering with some high res montiors.
--- drivers/gpu/drm/radeon/atombios_crtc.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/gpu/drm/radeon/atombios_crtc.c +2 -0
@@ -544,6 +544,8 @@ static u32 atombios_adjust_pll(struct dr/* use frac fb div on APUs */ if (ASIC_IS_DCE41 (rdev)) pll->flags |=RADEON_PLL_USE_FRAC_FB_DIV ; +if (ASIC_IS_DCE32 (rdev) && mode->clock >165000 ) + pll->flags |=RADEON_PLL_USE_FRAC_FB_DIV ; }else { pll->flags |=RADEON_PLL_LEGACY ;
PATCH 113/173 drm/radeon: fix eDP clk and lane setup for scaled modes
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <[email protected]>
commit 93927f9c1db5f55085457e820f0631064c7bfa34 upstream.
Need to use the adjusted mode since we are sending native timing and using the scaler for non-native modes.
--- drivers/gpu/drm/radeon/atombios_encoders.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/radeon/atombios_encoders.c +1 -1
@@ -340,7 +340,7 @@ static bool radeon_atom_mode_fixup(struct drm_encoder *encoder, ((radeon_encoder->active_device & (ATOM_DEVICE_DFP_SUPPORT | ATOM_DEVICE_LCD_SUPPORT)) || (radeon_encoder_get_dp_bridge_encoder_id(encoder) != ENCODER_OBJECT_ID_NONE))) {struct drm_connector *connector =radeon_get_connector_for_encoder (encoder); -radeon_dp_set_link_config (connector, mode); +radeon_dp_set_link_config (connector, adjusted_mode); }return true;
PATCH 114/173 regmap: debugfs: Avoid overflows for very small reads
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mark Brown <[email protected]>
commit db04328c167ff8e7c57f4a3532214aeada3a82fd upstream.
If count is less than the size of a register then we may hit integer wraparound when trying to move backwards to check if we're still in the buffer. Instead move the position forwards to check if it's still in the buffer, we are unlikely to be able to allocate a buffer sufficiently big to overflow here.
--- drivers/base/regmap/regmap-debugfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/base/regmap/regmap-debugfs.c +1 -1
@@ -67,7 +67,7 @@ static ssize_t regmap_map_read_file(stru/* If we're in the region the user is trying to read */ if (p >= *ppos) {/* ...but not beyond it */ -if (buf_pos >= count -1 - tot_len) +if (buf_pos +1 + tot_len >= count)break ;/* Format the register */
PATCH 115/173 Revert "ath9k_hw: Update AR9003 high_power tx gain table"
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Felix Fietkau <[email protected]>
commit 9c170e068636deb3e3f96114034bb711675f0faa upstream.
This reverts commit f74b9d365ddd33a375802b064f96a5d0e99af7c0.
Turns out reverting commit a240dc7b3c7463bd60cf0a9b2a90f52f78aae0fd "ath9k_hw: Updated AR9003 tx gain table for 5GHz" was not enough to bring the tx power back to normal levels on devices like the Buffalo WZR-HP-G450H, this one needs to be reverted as well.
This revert improves tx power by ~10 db on that device
--- .../net/wireless/ath/ath9k/ar9003_2p2_initvals.h | 172 ++++++++++---------- 1 file changed, 86 insertions(+), 86 deletions(-)
drivers/net/wireless/ath/ath9k/ar9003_2p2_initvals.h +86 -86
@@ -534,98 +534,98 @@ static const u32 ar9300_2p2_baseband_core[][2] = {static const u32 ar9300Modes_high_power_tx_gain_table_2p2[][5 ] = {/* Addr 5G_HT20 5G_HT40 2G_HT40 2G_HT20 */ - {0x0000a2dc ,0x00033800 ,0x00033800 ,0x03aaa352 ,0x03aaa352 }, - {0x0000a2e0 ,0x0003c000 ,0x0003c000 ,0x03ccc584 ,0x03ccc584 }, - {0x0000a2e4 ,0x03fc0000 ,0x03fc0000 ,0x03f0f800 ,0x03f0f800 }, + {0x0000a2dc ,0x0380c7fc ,0x0380c7fc ,0x03aaa352 ,0x03aaa352 }, + {0x0000a2e0 ,0x0000f800 ,0x0000f800 ,0x03ccc584 ,0x03ccc584 }, + {0x0000a2e4 ,0x03ff0000 ,0x03ff0000 ,0x03f0f800 ,0x03f0f800 }, {0x0000a2e8 ,0x00000000 ,0x00000000 ,0x03ff0000 ,0x03ff0000 }, - {0x0000a410 ,0x000050d9 ,0x000050d9 ,0x000050d9 ,0x000050d9 }, - {0x0000a500 ,0x00000000 ,0x00000000 ,0x00000000 ,0x00000000 }, - {0x0000a504 ,0x06000003 ,0x06000003 ,0x04000002 ,0x04000002 }, - {0x0000a508 ,0x0a000020 ,0x0a000020 ,0x08000004 ,0x08000004 }, - {0x0000a50c ,0x10000023 ,0x10000023 ,0x0b000200 ,0x0b000200 }, - {0x0000a510 ,0x16000220 ,0x16000220 ,0x0f000202 ,0x0f000202 }, - {0x0000a514 ,0x1c000223 ,0x1c000223 ,0x12000400 ,0x12000400 }, - {0x0000a518 ,0x21002220 ,0x21002220 ,0x16000402 ,0x16000402 }, - {0x0000a51c ,0x27002223 ,0x27002223 ,0x19000404 ,0x19000404 }, - {0x0000a520 ,0x2b022220 ,0x2b022220 ,0x1c000603 ,0x1c000603 }, - {0x0000a524 ,0x2f022222 ,0x2f022222 ,0x21000a02 ,0x21000a02 }, - {0x0000a528 ,0x34022225 ,0x34022225 ,0x25000a04 ,0x25000a04 }, - {0x0000a52c ,0x3a02222a ,0x3a02222a ,0x28000a20 ,0x28000a20 }, - {0x0000a530 ,0x3e02222c ,0x3e02222c ,0x2c000e20 ,0x2c000e20 }, - {0x0000a534 ,0x4202242a ,0x4202242a ,0x30000e22 ,0x30000e22 }, - {0x0000a538 ,0x4702244a ,0x4702244a ,0x34000e24 ,0x34000e24 }, - {0x0000a53c ,0x4b02244c ,0x4b02244c ,0x38001640 ,0x38001640 }, - {0x0000a540 ,0x4e02246c ,0x4e02246c ,0x3c001660 ,0x3c001660 }, - {0x0000a544 ,0x52022470 ,0x52022470 ,0x3f001861 ,0x3f001861 }, - {0x0000a548 ,0x55022490 ,0x55022490 ,0x43001a81 ,0x43001a81 }, - {0x0000a54c ,0x59022492 ,0x59022492 ,0x47001a83 ,0x47001a83 }, - {0x0000a550 ,0x5d022692 ,0x5d022692 ,0x4a001c84 ,0x4a001c84 }, - {0x0000a554 ,0x61022892 ,0x61022892 ,0x4e001ce3 ,0x4e001ce3 }, - {0x0000a558 ,0x65024890 ,0x65024890 ,0x52001ce5 ,0x52001ce5 }, - {0x0000a55c ,0x69024892 ,0x69024892 ,0x56001ce9 ,0x56001ce9 }, - {0x0000a560 ,0x6e024c92 ,0x6e024c92 ,0x5a001ceb ,0x5a001ceb }, - {0x0000a564 ,0x74026e92 ,0x74026e92 ,0x5d001eec ,0x5d001eec }, - {0x0000a568 ,0x74026e92 ,0x74026e92 ,0x5d001eec ,0x5d001eec }, - {0x0000a56c ,0x74026e92 ,0x74026e92 ,0x5d001eec ,0x5d001eec }, - {0x0000a570 ,0x74026e92 ,0x74026e92 ,0x5d001eec ,0x5d001eec }, - {0x0000a574 ,0x74026e92 ,0x74026e92 ,0x5d001eec ,0x5d001eec }, - {0x0000a578 ,0x74026e92 ,0x74026e92 ,0x5d001eec ,0x5d001eec }, - {0x0000a57c ,0x74026e92 ,0x74026e92 ,0x5d001eec ,0x5d001eec }, - {0x0000a580 ,0x00800000 ,0x00800000 ,0x00800000 ,0x00800000 }, - {0x0000a584 ,0x06800003 ,0x06800003 ,0x04800002 ,0x04800002 }, - {0x0000a588 ,0x0a800020 ,0x0a800020 ,0x08800004 ,0x08800004 }, - {0x0000a58c ,0x10800023 ,0x10800023 ,0x0b800200 ,0x0b800200 }, - {0x0000a590 ,0x16800220 ,0x16800220 ,0x0f800202 ,0x0f800202 }, - {0x0000a594 ,0x1c800223 ,0x1c800223 ,0x12800400 ,0x12800400 }, - {0x0000a598 ,0x21802220 ,0x21802220 ,0x16800402 ,0x16800402 }, - {0x0000a59c ,0x27802223 ,0x27802223 ,0x19800404 ,0x19800404 }, - {0x0000a5a0 ,0x2b822220 ,0x2b822220 ,0x1c800603 ,0x1c800603 }, - {0x0000a5a4 ,0x2f822222 ,0x2f822222 ,0x21800a02 ,0x21800a02 }, - {0x0000a5a8 ,0x34822225 ,0x34822225 ,0x25800a04 ,0x25800a04 }, - {0x0000a5ac ,0x3a82222a ,0x3a82222a ,0x28800a20 ,0x28800a20 }, - {0x0000a5b0 ,0x3e82222c ,0x3e82222c ,0x2c800e20 ,0x2c800e20 }, - {0x0000a5b4 ,0x4282242a ,0x4282242a ,0x30800e22 ,0x30800e22 }, - {0x0000a5b8 ,0x4782244a ,0x4782244a ,0x34800e24 ,0x34800e24 }, - {0x0000a5bc ,0x4b82244c ,0x4b82244c ,0x38801640 ,0x38801640 }, - {0x0000a5c0 ,0x4e82246c ,0x4e82246c ,0x3c801660 ,0x3c801660 }, - {0x0000a5c4 ,0x52822470 ,0x52822470 ,0x3f801861 ,0x3f801861 }, - {0x0000a5c8 ,0x55822490 ,0x55822490 ,0x43801a81 ,0x43801a81 }, - {0x0000a5cc ,0x59822492 ,0x59822492 ,0x47801a83 ,0x47801a83 }, - {0x0000a5d0 ,0x5d822692 ,0x5d822692 ,0x4a801c84 ,0x4a801c84 }, - {0x0000a5d4 ,0x61822892 ,0x61822892 ,0x4e801ce3 ,0x4e801ce3 }, - {0x0000a5d8 ,0x65824890 ,0x65824890 ,0x52801ce5 ,0x52801ce5 }, - {0x0000a5dc ,0x69824892 ,0x69824892 ,0x56801ce9 ,0x56801ce9 }, - {0x0000a5e0 ,0x6e824c92 ,0x6e824c92 ,0x5a801ceb ,0x5a801ceb }, - {0x0000a5e4 ,0x74826e92 ,0x74826e92 ,0x5d801eec ,0x5d801eec }, - {0x0000a5e8 ,0x74826e92 ,0x74826e92 ,0x5d801eec ,0x5d801eec }, - {0x0000a5ec ,0x74826e92 ,0x74826e92 ,0x5d801eec ,0x5d801eec }, - {0x0000a5f0 ,0x74826e92 ,0x74826e92 ,0x5d801eec ,0x5d801eec }, - {0x0000a5f4 ,0x74826e92 ,0x74826e92 ,0x5d801eec ,0x5d801eec }, - {0x0000a5f8 ,0x74826e92 ,0x74826e92 ,0x5d801eec ,0x5d801eec }, - {0x0000a5fc ,0x74826e92 ,0x74826e92 ,0x5d801eec ,0x5d801eec }, + {0x0000a410 ,0x000050d8 ,0x000050d8 ,0x000050d9 ,0x000050d9 }, + {0x0000a500 ,0x00002220 ,0x00002220 ,0x00000000 ,0x00000000 }, + {0x0000a504 ,0x04002222 ,0x04002222 ,0x04000002 ,0x04000002 }, + {0x0000a508 ,0x09002421 ,0x09002421 ,0x08000004 ,0x08000004 }, + {0x0000a50c ,0x0d002621 ,0x0d002621 ,0x0b000200 ,0x0b000200 }, + {0x0000a510 ,0x13004620 ,0x13004620 ,0x0f000202 ,0x0f000202 }, + {0x0000a514 ,0x19004a20 ,0x19004a20 ,0x11000400 ,0x11000400 }, + {0x0000a518 ,0x1d004e20 ,0x1d004e20 ,0x15000402 ,0x15000402 }, + {0x0000a51c ,0x21005420 ,0x21005420 ,0x19000404 ,0x19000404 }, + {0x0000a520 ,0x26005e20 ,0x26005e20 ,0x1b000603 ,0x1b000603 }, + {0x0000a524 ,0x2b005e40 ,0x2b005e40 ,0x1f000a02 ,0x1f000a02 }, + {0x0000a528 ,0x2f005e42 ,0x2f005e42 ,0x23000a04 ,0x23000a04 }, + {0x0000a52c ,0x33005e44 ,0x33005e44 ,0x26000a20 ,0x26000a20 }, + {0x0000a530 ,0x38005e65 ,0x38005e65 ,0x2a000e20 ,0x2a000e20 }, + {0x0000a534 ,0x3c005e69 ,0x3c005e69 ,0x2e000e22 ,0x2e000e22 }, + {0x0000a538 ,0x40005e6b ,0x40005e6b ,0x31000e24 ,0x31000e24 }, + {0x0000a53c ,0x44005e6d ,0x44005e6d ,0x34001640 ,0x34001640 }, + {0x0000a540 ,0x49005e72 ,0x49005e72 ,0x38001660 ,0x38001660 }, + {0x0000a544 ,0x4e005eb2 ,0x4e005eb2 ,0x3b001861 ,0x3b001861 }, + {0x0000a548 ,0x53005f12 ,0x53005f12 ,0x3e001a81 ,0x3e001a81 }, + {0x0000a54c ,0x59025eb2 ,0x59025eb2 ,0x42001a83 ,0x42001a83 }, + {0x0000a550 ,0x5e025f12 ,0x5e025f12 ,0x44001c84 ,0x44001c84 }, + {0x0000a554 ,0x61027f12 ,0x61027f12 ,0x48001ce3 ,0x48001ce3 }, + {0x0000a558 ,0x6702bf12 ,0x6702bf12 ,0x4c001ce5 ,0x4c001ce5 }, + {0x0000a55c ,0x6b02bf14 ,0x6b02bf14 ,0x50001ce9 ,0x50001ce9 }, + {0x0000a560 ,0x6f02bf16 ,0x6f02bf16 ,0x54001ceb ,0x54001ceb }, + {0x0000a564 ,0x6f02bf16 ,0x6f02bf16 ,0x56001eec ,0x56001eec }, + {0x0000a568 ,0x6f02bf16 ,0x6f02bf16 ,0x56001eec ,0x56001eec }, + {0x0000a56c ,0x6f02bf16 ,0x6f02bf16 ,0x56001eec ,0x56001eec }, + {0x0000a570 ,0x6f02bf16 ,0x6f02bf16 ,0x56001eec ,0x56001eec }, + {0x0000a574 ,0x6f02bf16 ,0x6f02bf16 ,0x56001eec ,0x56001eec }, + {0x0000a578 ,0x6f02bf16 ,0x6f02bf16 ,0x56001eec ,0x56001eec }, + {0x0000a57c ,0x6f02bf16 ,0x6f02bf16 ,0x56001eec ,0x56001eec }, + {0x0000a580 ,0x00802220 ,0x00802220 ,0x00800000 ,0x00800000 }, + {0x0000a584 ,0x04802222 ,0x04802222 ,0x04800002 ,0x04800002 }, + {0x0000a588 ,0x09802421 ,0x09802421 ,0x08800004 ,0x08800004 }, + {0x0000a58c ,0x0d802621 ,0x0d802621 ,0x0b800200 ,0x0b800200 }, + {0x0000a590 ,0x13804620 ,0x13804620 ,0x0f800202 ,0x0f800202 }, + {0x0000a594 ,0x19804a20 ,0x19804a20 ,0x11800400 ,0x11800400 }, + {0x0000a598 ,0x1d804e20 ,0x1d804e20 ,0x15800402 ,0x15800402 }, + {0x0000a59c ,0x21805420 ,0x21805420 ,0x19800404 ,0x19800404 }, + {0x0000a5a0 ,0x26805e20 ,0x26805e20 ,0x1b800603 ,0x1b800603 }, + {0x0000a5a4 ,0x2b805e40 ,0x2b805e40 ,0x1f800a02 ,0x1f800a02 }, + {0x0000a5a8 ,0x2f805e42 ,0x2f805e42 ,0x23800a04 ,0x23800a04 }, + {0x0000a5ac ,0x33805e44 ,0x33805e44 ,0x26800a20 ,0x26800a20 }, + {0x0000a5b0 ,0x38805e65 ,0x38805e65 ,0x2a800e20 ,0x2a800e20 }, + {0x0000a5b4 ,0x3c805e69 ,0x3c805e69 ,0x2e800e22 ,0x2e800e22 }, + {0x0000a5b8 ,0x40805e6b ,0x40805e6b ,0x31800e24 ,0x31800e24 }, + {0x0000a5bc ,0x44805e6d ,0x44805e6d ,0x34801640 ,0x34801640 }, + {0x0000a5c0 ,0x49805e72 ,0x49805e72 ,0x38801660 ,0x38801660 }, + {0x0000a5c4 ,0x4e805eb2 ,0x4e805eb2 ,0x3b801861 ,0x3b801861 }, + {0x0000a5c8 ,0x53805f12 ,0x53805f12 ,0x3e801a81 ,0x3e801a81 }, + {0x0000a5cc ,0x59825eb2 ,0x59825eb2 ,0x42801a83 ,0x42801a83 }, + {0x0000a5d0 ,0x5e825f12 ,0x5e825f12 ,0x44801c84 ,0x44801c84 }, + {0x0000a5d4 ,0x61827f12 ,0x61827f12 ,0x48801ce3 ,0x48801ce3 }, + {0x0000a5d8 ,0x6782bf12 ,0x6782bf12 ,0x4c801ce5 ,0x4c801ce5 }, + {0x0000a5dc ,0x6b82bf14 ,0x6b82bf14 ,0x50801ce9 ,0x50801ce9 }, + {0x0000a5e0 ,0x6f82bf16 ,0x6f82bf16 ,0x54801ceb ,0x54801ceb }, + {0x0000a5e4 ,0x6f82bf16 ,0x6f82bf16 ,0x56801eec ,0x56801eec }, + {0x0000a5e8 ,0x6f82bf16 ,0x6f82bf16 ,0x56801eec ,0x56801eec }, + {0x0000a5ec ,0x6f82bf16 ,0x6f82bf16 ,0x56801eec ,0x56801eec }, + {0x0000a5f0 ,0x6f82bf16 ,0x6f82bf16 ,0x56801eec ,0x56801eec }, + {0x0000a5f4 ,0x6f82bf16 ,0x6f82bf16 ,0x56801eec ,0x56801eec }, + {0x0000a5f8 ,0x6f82bf16 ,0x6f82bf16 ,0x56801eec ,0x56801eec }, + {0x0000a5fc ,0x6f82bf16 ,0x6f82bf16 ,0x56801eec ,0x56801eec }, {0x0000a600 ,0x00000000 ,0x00000000 ,0x00000000 ,0x00000000 }, {0x0000a604 ,0x00000000 ,0x00000000 ,0x00000000 ,0x00000000 }, {0x0000a608 ,0x00000000 ,0x00000000 ,0x00000000 ,0x00000000 }, {0x0000a60c ,0x00000000 ,0x00000000 ,0x00000000 ,0x00000000 }, - {0x0000a610 ,0x00000000 ,0x00000000 ,0x00000000 ,0x00000000 }, - {0x0000a614 ,0x02004000 ,0x02004000 ,0x01404000 ,0x01404000 }, - {0x0000a618 ,0x02004801 ,0x02004801 ,0x01404501 ,0x01404501 }, - {0x0000a61c ,0x02808a02 ,0x02808a02 ,0x02008501 ,0x02008501 }, - {0x0000a620 ,0x0380ce03 ,0x0380ce03 ,0x0280ca03 ,0x0280ca03 }, - {0x0000a624 ,0x04411104 ,0x04411104 ,0x03010c04 ,0x03010c04 }, - {0x0000a628 ,0x04411104 ,0x04411104 ,0x04014c04 ,0x04014c04 }, - {0x0000a62c ,0x04411104 ,0x04411104 ,0x04015005 ,0x04015005 }, - {0x0000a630 ,0x04411104 ,0x04411104 ,0x04015005 ,0x04015005 }, - {0x0000a634 ,0x04411104 ,0x04411104 ,0x04015005 ,0x04015005 }, - {0x0000a638 ,0x04411104 ,0x04411104 ,0x04015005 ,0x04015005 }, - {0x0000a63c ,0x04411104 ,0x04411104 ,0x04015005 ,0x04015005 }, - {0x0000b2dc ,0x00033800 ,0x00033800 ,0x03aaa352 ,0x03aaa352 }, - {0x0000b2e0 ,0x0003c000 ,0x0003c000 ,0x03ccc584 ,0x03ccc584 }, - {0x0000b2e4 ,0x03fc0000 ,0x03fc0000 ,0x03f0f800 ,0x03f0f800 }, + {0x0000a610 ,0x00804000 ,0x00804000 ,0x00000000 ,0x00000000 }, + {0x0000a614 ,0x00804201 ,0x00804201 ,0x01404000 ,0x01404000 }, + {0x0000a618 ,0x0280c802 ,0x0280c802 ,0x01404501 ,0x01404501 }, + {0x0000a61c ,0x0280ca03 ,0x0280ca03 ,0x02008501 ,0x02008501 }, + {0x0000a620 ,0x04c15104 ,0x04c15104 ,0x0280ca03 ,0x0280ca03 }, + {0x0000a624 ,0x04c15305 ,0x04c15305 ,0x03010c04 ,0x03010c04 }, + {0x0000a628 ,0x04c15305 ,0x04c15305 ,0x04014c04 ,0x04014c04 }, + {0x0000a62c ,0x04c15305 ,0x04c15305 ,0x04015005 ,0x04015005 }, + {0x0000a630 ,0x04c15305 ,0x04c15305 ,0x04015005 ,0x04015005 }, + {0x0000a634 ,0x04c15305 ,0x04c15305 ,0x04015005 ,0x04015005 }, + {0x0000a638 ,0x04c15305 ,0x04c15305 ,0x04015005 ,0x04015005 }, + {0x0000a63c ,0x04c15305 ,0x04c15305 ,0x04015005 ,0x04015005 }, + {0x0000b2dc ,0x0380c7fc ,0x0380c7fc ,0x03aaa352 ,0x03aaa352 }, + {0x0000b2e0 ,0x0000f800 ,0x0000f800 ,0x03ccc584 ,0x03ccc584 }, + {0x0000b2e4 ,0x03ff0000 ,0x03ff0000 ,0x03f0f800 ,0x03f0f800 }, {0x0000b2e8 ,0x00000000 ,0x00000000 ,0x03ff0000 ,0x03ff0000 }, - {0x0000c2dc ,0x00033800 ,0x00033800 ,0x03aaa352 ,0x03aaa352 }, - {0x0000c2e0 ,0x0003c000 ,0x0003c000 ,0x03ccc584 ,0x03ccc584 }, - {0x0000c2e4 ,0x03fc0000 ,0x03fc0000 ,0x03f0f800 ,0x03f0f800 }, + {0x0000c2dc ,0x0380c7fc ,0x0380c7fc ,0x03aaa352 ,0x03aaa352 }, + {0x0000c2e0 ,0x0000f800 ,0x0000f800 ,0x03ccc584 ,0x03ccc584 }, + {0x0000c2e4 ,0x03ff0000 ,0x03ff0000 ,0x03f0f800 ,0x03f0f800 }, {0x0000c2e8 ,0x00000000 ,0x00000000 ,0x03ff0000 ,0x03ff0000 }, {0x00016044 ,0x012492d4 ,0x012492d4 ,0x012492d4 ,0x012492d4 }, {0x00016048 ,0x66480001 ,0x66480001 ,0x66480001 ,0x66480001 },
PATCH 116/173 ath9k: ar9003: fix OTP register offsets for AR9340
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gabor Juhos <[email protected]>
commit b3cd8021379306c0be6932e4d3b4b01efc681769 upstream.
Trying to access the OTP memory on the AR9340 causes a data bus error like this:
Data bus error, epc == 86e84164, ra == 86e84164 Oops[#1]:
Cpu 0
$ 0 : 00000000 00000061 deadc0de 00000000
$ 4 : b8115f18 00015f18 00000007 00000004
$ 8 : 00000001 7c7c3c7c 7c7c7c7c 7c7c7c7c
$12 : 7c7c3c7c 001f0041 00000000 7c7c7c3c
$16 : 86ee0000 00015f18 00000000 00000007
$20 : 00000004 00000064 00000004 86d71c44
$24 : 00000000 86e6ca00
$28 : 86d70000 86d71b20 86ece0c0 86e84164
Hi : 00000000
Lo : 00000064
epc : 86e84164 ath9k_hw_wait+0x58/0xb0 [ath9k_hw]
Tainted: G O
ra : 86e84164 ath9k_hw_wait+0x58/0xb0 [ath9k_hw]
Status: 1100d403 KERNEL EXL IE
Cause : 4080801c
PrId : 0001974c (MIPS 74Kc)
Modules linked in: ath9k(O+) ath9k_common(O) ath9k_hw(O) ath(O) ar934x_nfc
mac80211(O) usbcore usb_common scsi_mod nls_base nand nand_ecc nand_ids
crc_ccitt cfg80211(O) compat(O) arc4 aes_generic crypto_blkcipher cryptomgr
aead crypto_hash crypto_algapi ledtrig_timer ledtrig_default_on leds_gpio
Process insmod (pid: 459, threadinfo=86d70000, task=87942140, tls=779ac440)
Stack : 802fb500 000200da 804db150 804e0000 87816130 86ee0000 00010000 86d71b88
86d71bc0 00000004 00000003 86e9fcd0 80305300 0002c0d0 86e74c50 800b4c20
000003e8 00000001 00000000 86ee0000 000003ff 86e9fd64 80305300 80123938
fffffffc 00000004 000058bc 00000000 86ea0000 86ee0000 000001ff 878d6000
99999999 86e9fdc0 86ee0fcc 86e9e664 0000c0d0 86ee0000 0000700000007000
...
Call Trace:
[<86e84164>] ath9k_hw_wait+0x58/0xb0 [ath9k_hw]
[<86e9fcd0>] ath9k_hw_setup_statusring+0x16b8/0x1c7c [ath9k_hw]Code: 0000a812 0040f809 00000000 <00531024> 1054000b 24020001 0c05b5dc 2404000a 26520001
The cause of the error is that the OTP register offsets are different on the AR9340 than the actually used values.
--- drivers/net/wireless/ath/ath9k/ar9003_eeprom.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/net/wireless/ath/ath9k/ar9003_eeprom.h +3 -3
@@ -68,13 +68,13 @@#define AR9300_BASE_ADDR 0x3ff#define AR9300_BASE_ADDR_512 0x1ff -#define AR9300_OTP_BASE 0x14000 -#define AR9300_OTP_STATUS 0x15f18 +#define AR9300_OTP_BASE (AR_SREV_9340(ah) ? 0x30000 : 0x14000) +#define AR9300_OTP_STATUS (AR_SREV_9340(ah) ? 0x30018 : 0x15f18)#define AR9300_OTP_STATUS_TYPE 0x7#define AR9300_OTP_STATUS_VALID 0x4#define AR9300_OTP_STATUS_ACCESS_BUSY 0x2#define AR9300_OTP_STATUS_SM_BUSY 0x1 -#define AR9300_OTP_READ_DATA 0x15f1c +#define AR9300_OTP_READ_DATA (AR_SREV_9340(ah) ? 0x3001c : 0x15f1c)enum targetPowerHTRates {HT_TARGET_RATE_0_8_16 ,
PATCH 117/173 bcma: mips: fix clearing device IRQ
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rafał Miłecki <[email protected]>
commit cbbc0138efe1dcd5426b8fc5d87741f5057aee72 upstream.
We were using wrong IRQ number so clearing wasn't working at all. Depending on a platform this could result in a one device having two interrupts assigned. On BCM4706 this resulted in all IRQs being broken.
--- drivers/bcma/driver_mips.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/bcma/driver_mips.c +1 -1
@@ -115,7 +115,7 @@ static void bcma_core_mips_set_irq(struct bcma_device *dev, unsigned int irq)bcma_read32 (mdev,BCMA_MIPS_MIPS74K_INTMASK (0 )) & ~(1 << irqflag)); else - bcma_write32(mdev, BCMA_MIPS_MIPS74K_INTMASK(irq), 0); + bcma_write32(mdev, BCMA_MIPS_MIPS74K_INTMASK(oldirq), 0);/* assign the new one */ if (irq ==0 ) {
PATCH 118/173 ath9k_hw: Fix signal strength / channel noise reporting
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Felix Fietkau <[email protected]>
commit b7c0c238898d200e80487516e2b67aba2a522cc0 upstream.
While AR_PHY_CCA_NOM_VAL_* does contain the expected internal noise floor for a chip measured in clean air, it refers to the lowest expected reading.
Depending on the frequency, this measurement can vary by about 6db, thus causing a higher reported channel noise and signal strength.
Factor in the 6db offset when converting internal noisefloor to channel noise.
This patch makes the reported values more accurate for all chips without affecting NF calibration behavior.
--- drivers/net/wireless/ath/ath9k/calib.c | 1 + drivers/net/wireless/ath/ath9k/calib.h | 3 +++ 2 files changed, 4 insertions(+)
drivers/net/wireless/ath/ath9k/calib.c +1 -0
@@ -69,6 +69,7 @@ s16 ath9k_hw_getchan_noise(struct ath_hwif (chan && chan->noisefloor) {s8 delta = chan->noisefloor - +ATH9K_NF_CAL_NOISE_THRESH -ath9k_hw_get_default_nf (ah, chan);if (delta >0 ) noise += delta;
drivers/net/wireless/ath/ath9k/calib.h +3 -0
@@ -22,6 +22,9 @@#define AR_PHY_CCA_FILTERWINDOW_LENGTH_INIT 3#define AR_PHY_CCA_FILTERWINDOW_LENGTH 5 +/* Internal noise floor can vary by about 6db depending on the frequency */ +#define ATH9K_NF_CAL_NOISE_THRESH 6 +#define NUM_NF_READINGS 6#define ATH9K_NF_CAL_HIST_MAX 5
PATCH 119/173 drm/i915: drop unnecessary check from fdi_link_train code
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Vetter <[email protected]>
commit 8f5718a6d9a29bf1f51910c6b32bd0244f905303 upstream.
They are all written for a specific north disaplay->pch combination. So stop pretending otherwise.
--- drivers/gpu/drm/i915/intel_display.c | 14 +++++--------- 1 file changed, 5 insertions(+), 9 deletions(-)
drivers/gpu/drm/i915/intel_display.c +5 -9
@@ -2490,11 +2490,9 @@ static void ironlake_fdi_link_train(struct drm_crtc *crtc)udelay (150 );/* Ironlake workaround, enable clock pointer after FDI enable*/ -if (HAS_PCH_IBX (dev)) { -I915_WRITE (FDI_RX_CHICKEN (pipe),FDI_RX_PHASE_SYNC_POINTER_OVR ); -I915_WRITE (FDI_RX_CHICKEN (pipe),FDI_RX_PHASE_SYNC_POINTER_OVR | -FDI_RX_PHASE_SYNC_POINTER_EN ); - } +I915_WRITE (FDI_RX_CHICKEN (pipe),FDI_RX_PHASE_SYNC_POINTER_OVR ); +I915_WRITE (FDI_RX_CHICKEN (pipe),FDI_RX_PHASE_SYNC_POINTER_OVR | +FDI_RX_PHASE_SYNC_POINTER_EN ); reg =FDI_RX_IIR (pipe);for (tries =0 ; tries <5 ; tries++) {
@@ -2600,8 +2598,7 @@ static void gen6_fdi_link_train(struct drm_crtc *crtc)POSTING_READ (reg);udelay (150 ); -if (HAS_PCH_CPT (dev)) -cpt_phase_pointer_enable (dev, pipe); +cpt_phase_pointer_enable (dev, pipe);for (i =0 ; i <4 ; i++) { reg =FDI_TX_CTL (pipe);
@@ -2735,8 +2732,7 @@ static void ivb_manual_fdi_link_train(struct drm_crtc *crtc)POSTING_READ (reg);udelay (150 ); -if (HAS_PCH_CPT (dev)) -cpt_phase_pointer_enable (dev, pipe); +cpt_phase_pointer_enable (dev, pipe);for (i =0 ; i <4 ; i++) { reg =FDI_TX_CTL (pipe);
PATCH 120/173 drm/i915: disable cpt phase pointer fdi rx workaround
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Vetter <[email protected]>
commit 539526b4137bc0e7a8806c38c8522f226814a0e6 upstream.
We've originally added this in
commit 291427f5fdadec6e4be2924172e83588880e1539
Author: Jesse Barnes <[email protected]> Date: Fri Jul 29 12:42:37 2011 -0700
drm/i915: apply phase pointer override on SNB+ too
and then copy-pasted it over to ivb/ppt. The w/a was originally added for ilk/ibx in
commit 5b2adf897146edeac6a1e438fb67b5a53dbbdf34
Author: Jesse Barnes <[email protected]> Date: Thu Oct 7 16:01:15 2010 -0700
drm/i915: add Ironlake clock gating workaround for FDI link training
and fixed up a bit in
commit 6f06ce184c765fd8d50669a8d12fdd566c920859
Author: Jesse Barnes <[email protected]> Date: Tue Jan 4 15:09:38 2011 -0800
drm/i915: set phase sync pointer override enable before setting phase sync pointer
It turns out that this w/a isn't actually required on cpt/ppt and positively harmful on ivb/ppt when using fdi B/C links - it results in a black screen occasionally, with seemingfully everything working as it should. The only failure indication I've found in the hw is that eventually (but not right after the modeset completes) a pipe underrun is signalled.
Big thanks to Arthur Runyan for all the ideas for registers to check and changes to test, otherwise I couldn't ever have tracked this down!
--- drivers/gpu/drm/i915/intel_display.c | 29 ----------------------------- 1 file changed, 29 deletions(-)
drivers/gpu/drm/i915/intel_display.c +0 -29
@@ -2384,18 +2384,6 @@ static void intel_fdi_normal_train(struc FDI_FE_ERRC_ENABLE); } -static void cpt_phase_pointer_enable (struct drm_device *dev,int pipe) -{ -struct drm_i915_private *dev_priv = dev->dev_private; -u32 flags =I915_READ (SOUTH_CHICKEN1 ); - - flags |=FDI_PHASE_SYNC_OVR (pipe); -I915_WRITE (SOUTH_CHICKEN1 , flags);/* once to unlock... */ - flags |=FDI_PHASE_SYNC_EN (pipe); -I915_WRITE (SOUTH_CHICKEN1 , flags);/* then again to enable */ -POSTING_READ (SOUTH_CHICKEN1 ); -} -/* The FDI link training functions for ILK/Ibexpeak. */ static void ironlake_fdi_link_train (struct drm_crtc *crtc) {
@@ -2544,8 +2532,6 @@ static void gen6_fdi_link_train(struct dPOSTING_READ (reg);udelay (150 ); -cpt_phase_pointer_enable (dev, pipe); -for (i =0 ; i <4 ; i++) { reg =FDI_TX_CTL (pipe); temp =I915_READ (reg);
@@ -2664,8 +2650,6 @@ static void ivb_manual_fdi_link_train(stPOSTING_READ (reg);udelay (150 ); -cpt_phase_pointer_enable (dev, pipe); -for (i =0 ; i <4 ; i++) { reg =FDI_TX_CTL (pipe); temp =I915_READ (reg);
@@ -2775,17 +2759,6 @@ static void ironlake_fdi_pll_enable(stru } } -static void cpt_phase_pointer_disable (struct drm_device *dev,int pipe) -{ -struct drm_i915_private *dev_priv = dev->dev_private; -u32 flags =I915_READ (SOUTH_CHICKEN1 ); - - flags &= ~(FDI_PHASE_SYNC_EN (pipe)); -I915_WRITE (SOUTH_CHICKEN1 , flags);/* once to disable... */ - flags &= ~(FDI_PHASE_SYNC_OVR (pipe)); -I915_WRITE (SOUTH_CHICKEN1 , flags);/* then again to lock */ -POSTING_READ (SOUTH_CHICKEN1 ); -}static void ironlake_fdi_disable (struct drm_crtc *crtc) {struct drm_device *dev = crtc->dev;
@@ -2815,8 +2788,6 @@ static void ironlake_fdi_disable(structI915_WRITE (FDI_RX_CHICKEN (pipe),I915_READ (FDI_RX_CHICKEN (pipe) & ~FDI_RX_PHASE_SYNC_POINTER_EN )); - }else if (HAS_PCH_CPT (dev)) { -cpt_phase_pointer_disable (dev, pipe); }/* still set train pattern 1 */
PATCH 121/173 nfsd: avoid permission checks on EXCLUSIVE_CREATE replay
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Neil Brown <[email protected]>
commit 7007c90fb9fef593b4aeaeee57e6a6754276c97c upstream.
With NFSv4, if we create a file then open it we explicit avoid checking the permissions on the file during the open because the fact that we created it ensures we should be allow to open it (the create and the open should appear to be a single operation).
However if the reply to an EXCLUSIVE create gets lots and the client resends the create, the current code will perform the permission check - because it doesn't realise that it did the open already..
This patch should fix this.
Note that I haven't actually seen this cause a problem. I was just looking at the code trying to figure out a different EXCLUSIVE open related issue, and this looked wrong.
(Fix confirmed with pynfs 4.0 test OPEN4--bfields)
[bwh: Backported to 3.2:
- Adjust context
- Use current_fh as file handle in do_open_lookup()]
--- fs/nfsd/nfs4proc.c | 8 +++++--- fs/nfsd/vfs.c | 10 ++++++++-- 2 files changed, 13 insertions(+), 5 deletions(-)
fs/nfsd/nfs4proc.c +5 -3
@@ -193,6 +193,7 @@ static __be32 do_open_lookup(struct svc_rqst *rqstp, struct svc_fh *current_fh, struct nfsd4_open *open) { struct svc_fh resfh; +int accmode;__be32 status;fh_init (&resfh,NFS4_FHSIZE );
@@ -252,9 +253,10 @@ do_open_lookup(struct svc_rqst *rqstp, s/* set reply cache */ fh_copy_shallow (&open->op_openowner->oo_owner.so_replay.rp_openfh, &resfh.fh_handle); -if (!open->op_created) - status =do_open_permission (rqstp, current_fh, open, -NFSD_MAY_NOP ); + accmode =NFSD_MAY_NOP ; +if (open->op_created) + accmode |=NFSD_MAY_OWNER_OVERRIDE ; + status =do_open_permission (rqstp, current_fh, open, accmode); out:fh_put (&resfh);
fs/nfsd/vfs.c +8 -2
@@ -1458,13 +1458,19 @@ do_nfsd_create(struct svc_rqst *rqstp, scase NFS3_CREATE_EXCLUSIVE :if ( dchild->d_inode->i_mtime.tv_sec == v_mtime && dchild->d_inode->i_atime.tv_sec == v_atime - && dchild->d_inode->i_size ==0 ) + && dchild->d_inode->i_size ==0 ) { +if (created) + *created =1 ;break ; + }case NFS4_CREATE_EXCLUSIVE4_1 :if ( dchild->d_inode->i_mtime.tv_sec == v_mtime && dchild->d_inode->i_atime.tv_sec == v_atime - && dchild->d_inode->i_size ==0 ) + && dchild->d_inode->i_size ==0 ) { +if (created) + *created =1 ; goto set_attr; + }/* fallthru */ case NFS3_CREATE_GUARDED : err = nfserr_exist;
PATCH 122/173 iwlwifi: dont handle masked interrupt
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Emmanuel Grumbach <[email protected]>
commit 25a172655f837bdb032e451f95441bb4acec51bb upstream.
This can lead to a panic if the driver isn't ready to handle them. Since our interrupt line is shared, we can get an interrupt at any time (and CONFIG_DEBUG_SHIRQ checks that even when the interrupt is being freed).
If the op_mode has gone away, we musn't call it. To avoid this the transport disables the interrupts when the hw is stopped and the op_mode is leaving.
If there is an event that would cause an interrupt the INTA register is updated regardless of the enablement of the
interrupts: even if the interrupts are disabled, the INTA will be changed, but the device won't issue an interrupt. But the ISR can be called at any time, so we ought ignore the value in the INTA otherwise we can call the op_mode after it was freed.
I found this bug when the op_mode_start failed, and called iwl_trans_stop_hw(trans, true). Then I played with the RFKILL button, and removed the module.
While removing the module, the IRQ is freed, and the ISR is called (CONFIG_DEBUG_SHIRQ enabled). Panic.
[bwh: Backported to 3.2:
- Adjust context
- Pass bus(trans), not trans, to iwl_{read,write}32()]
--- drivers/net/wireless/iwlwifi/iwl-trans-pcie-rx.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-)
drivers/net/wireless/iwlwifi/iwl-trans-pcie-rx.c +10 -2
@@ -1263,12 +1263,20 @@ static irqreturn_t iwl_isr(int irq, void* back-to-back ISRs and sporadic interrupts from our NIC. * If we have something to service, the tasklet will re-enable ints. * If we *don't* have something, we'll re-enable before leaving here. */ - inta_mask =iwl_read32 (bus (trans),CSR_INT_MASK );/* just for debug */ + inta_mask =iwl_read32 (bus (trans),CSR_INT_MASK );iwl_write32 (bus (trans),CSR_INT_MASK ,0x00000000 );/* Discover which interrupts are active/pending */ inta =iwl_read32 (bus (trans),CSR_INT ); +if (inta & (~inta_mask)) { +IWL_DEBUG_ISR (trans, +"We got a masked interrupt (0x%08x)...Ack and ignore\n" , + inta & (~inta_mask)); +iwl_write32 (bus (trans),CSR_INT , inta & (~inta_mask)); + inta &= inta_mask; + } +/* Ignore interrupt if there's nothing in NIC to service. * This may be due to IRQ shared with another device, * or due to sporadic interrupts thrown from our NIC. */
@@ -1349,7 +1357,7 @@ irqreturn_t iwl_isr_ict(int irq, void *d* If we have something to service, the tasklet will re-enable ints. * If we *don't* have something, we'll re-enable before leaving here. */ - inta_mask =iwl_read32 (bus (trans),CSR_INT_MASK );/* just for debug */ + inta_mask =iwl_read32 (bus (trans),CSR_INT_MASK );iwl_write32 (bus (trans),CSR_INT_MASK ,0x00000000 );
PATCH 123/173 mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marek Szyprowski <[email protected]>
commit 387870f2d6d679746020fa8e25ef786ff338dc98 upstream.
dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag, regardless the flags provided by the caller. This causes excessive pruning of emergency memory pools without any good reason. Additionaly, on ARM architecture any driver which is using dmapools will sooner or later trigger the following error:
"ERROR: 256 KiB atomic DMA coherent pool is too small! Please increase it with coherent_pool= kernel parameter!". Increasing the coherent pool size usually doesn't help much and only delays such error, because all GFP_ATOMIC DMA allocations are always served from the special, very limited memory pool.
This patch changes the dmapool code to correctly use gfp flags provided by the dmapool caller.
--- mm/dmapool.c | 31 +++++++------------------------ 1 file changed, 7 insertions(+), 24 deletions(-)
mm/dmapool.c +7 -24
@@ -50,7 +50,6 @@ struct dma_pool { /* the pool */size_t allocation;size_t boundary;char name[32 ]; -wait_queue_head_t waitq;struct list_head pools; };
@@ -62,8 +61,6 @@ struct dma_page { /* cacheable header for 'allocation' bytes */unsigned int offset; }; -#define POOL_TIMEOUT_JIFFIES ((100 /* msec */ * HZ) / 1000) -static DEFINE_MUTEX (pools_lock); static ssize_t
@@ -172,7 +169,6 @@ struct dma_pool *dma_pool_create(const char *name, struct device *dev, retval->size = size; retval->boundary = boundary; retval->allocation = allocation; -init_waitqueue_head (&retval->waitq);if (dev) {int ret;
@@ -227,7 +223,6 @@ static struct dma_page *pool_alloc_page(struct dma_pool *pool, gfp_t mem_flags)memset (page->vaddr,POOL_POISON_FREED , pool->allocation);#endif pool_initialise_page (pool, page); -list_add (&page->page_list, &pool->page_list); page->in_use =0 ; page->offset =0 ; }else {
@@ -315,30 +310,21 @@ void *dma_pool_alloc(struct dma_pool *pool, gfp_t mem_flags,might_sleep_if (mem_flags & __GFP_WAIT);spin_lock_irqsave (&pool->lock, flags); - restart:list_for_each_entry (page, &pool->page_list, page_list) {if (page->offset < pool->allocation) goto ready; } - page =pool_alloc_page (pool,GFP_ATOMIC ); -if (!page) { -if (mem_flags & __GFP_WAIT) { -DECLARE_WAITQUEUE (wait, current); -__set_current_state (TASK_UNINTERRUPTIBLE ); -__add_wait_queue (&pool->waitq, &wait); -spin_unlock_irqrestore (&pool->lock, flags); +/* pool_alloc_page() might sleep, so temporarily drop &pool->lock */ +spin_unlock_irqrestore (&pool->lock, flags); -schedule_timeout (POOL_TIMEOUT_JIFFIES ); + page =pool_alloc_page (pool, mem_flags); +if (!page) +return NULL ; -spin_lock_irqsave (&pool->lock, flags); -__remove_wait_queue (&pool->waitq, &wait); - goto restart; - } - retval =NULL ; - goto done; - } +spin_lock_irqsave (&pool->lock, flags); +list_add (&page->page_list, &pool->page_list); ready: page->in_use++; offset = page->offset;
@@ -348,7 +334,6 @@ void *dma_pool_alloc(struct dma_pool *pool, gfp_t mem_flags,#ifdef DMAPOOL_DEBUG memset (retval,POOL_POISON_ALLOCATED , pool->size);#endif - done:spin_unlock_irqrestore (&pool->lock, flags);return retval; }
@@ -435,8 +420,6 @@ void dma_pool_free(struct dma_pool *pool, void *vaddr, dma_addr_t dma) page->in_use--; *(int *)vaddr = page->offset; page->offset = offset; -if (waitqueue_active (&pool->waitq)) -wake_up_locked (&pool->waitq);/* * Resist a temptation to do * if (!is_page_busy(page)) pool_free_page(pool, page);
PATCH 124/173 x86, 8042: Enable A20 using KBC to fix S3 resume on some MSI laptops
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ondrej Zary <[email protected]>
commit ad68652412276f68ad4fe3e1ecf5ee6880876783 upstream.
Some MSI laptop BIOSes are broken - INT 15h code uses port 92h to enable A20 line but resume code assumes that KBC was used.
The laptop will not resume from S3 otherwise but powers off after a while and then powers on again stuck with a blank screen.
Fix it by enabling A20 using KBC in i8042_platform_init for x86.
Fixes https://bugzilla.kernel.org/show_bug.cgi?id=12878
--- drivers/input/serio/i8042-x86ia64io.h | 9 +++++++++ 1 file changed, 9 insertions(+)
drivers/input/serio/i8042-x86ia64io.h +9 -0
@@ -921,6 +921,7 @@ static int __init i8042_platform_init(void)int retval;#ifdef CONFIG_X86 +u8 a20_on =0xdf ;/* Just return if pre-detection shows no i8042 controller exist */ if (!x86_platform.i8042_detect ())return -ENODEV ;
@@ -960,6 +961,14 @@ static int __init i8042_platform_init(void)if (dmi_check_system (i8042_dmi_dritek_table)) i8042_dritek = true; + +/* +* A20 was already enabled during early kernel init. But some buggy +* BIOSes (in MSI Laptops) require A20 to be enabled using 8042 to +* resume from S3. So we do it here and hope that nothing breaks. +*/ +i8042_command (&a20_on,0x10d1 ); +i8042_command (NULL ,0x00ff );/* Null command for SMM firmware */ #endif /* CONFIG_X86 */ return retval;
PATCH 125/173 solos-pci: fix double-free of TX skb in DMA mode
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Woodhouse <[email protected]>
commit cae49ede00ec3d0cda290b03fee55b72b49efc11 upstream.
We weren't clearing card->tx_skb[port] when processing the TX done interrupt. If there wasn't another skb ready to transmit immediately, this led to a double-free because we'd free it *again* next time we did have a packet to send.
--- drivers/atm/solos-pci.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/atm/solos-pci.c +3 -2
@@ -945,10 +945,11 @@ static uint32_t fpga_tx(struct solos_card *card)for (port =0 ; tx_pending; tx_pending >>=1 , port++) {if (tx_pending &1 ) {struct sk_buff *oldskb = card->tx_skb[port]; -if (oldskb) +if (oldskb) {pci_unmap_single (card->dev,SKB_CB (oldskb)->dma_addr, oldskb->len,PCI_DMA_TODEVICE ); - + card->tx_skb[port] =NULL ; + }spin_lock (&card->tx_queue_lock); skb =skb_dequeue (&card->tx_queue[port]);if (!skb)
PATCH 126/173 ALSA: hda - Add stereo-dmic fixup for Acer Aspire One 522
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <[email protected]>
commit 63a077e27648b4043b1ca1b4e29f0c42d99616b6 upstream.
Acer Aspire One 522 has the infamous digital mic unit that needs the phase inversion fixup for stereo.
Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=715737
--- sound/pci/hda/patch_conexant.c | 1 + 1 file changed, 1 insertion(+)
sound/pci/hda/patch_conexant.c +1 -0
@@ -4507,6 +4507,7 @@ static const struct snd_pci_quirk cxt5051_fixups[] = { };static const struct snd_pci_quirk cxt5066_fixups[] = { +SND_PCI_QUIRK (0x1025 ,0x0543 ,"Acer Aspire One 522" ,CXT_FIXUP_STEREO_DMIC ),SND_PCI_QUIRK (0x17aa ,0x20f2 ,"Lenovo T400" ,CXT_PINCFG_LENOVO_TP410 ),SND_PCI_QUIRK (0x17aa ,0x215e ,"Lenovo T410" ,CXT_PINCFG_LENOVO_TP410 ),SND_PCI_QUIRK (0x17aa ,0x215f ,"Lenovo T510" ,CXT_PINCFG_LENOVO_TP410 ),
PATCH 127/173 drm/radeon: fix amd afusion gpu setup aka sumo v2
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jerome Glisse <[email protected]>
commit bd25f0783dc3fb72e1e2779c2b99b2d34b67fa8a upstream.
Set the proper number of tile pipe that should be a multiple of pipe depending on the number of se engine.
Fix:
https://bugs.freedesktop.org/show_bug.cgi?id=56405
https://bugs.freedesktop.org/show_bug.cgi?id=56720
v2: Don't change sumo2
--- drivers/gpu/drm/radeon/evergreen.c | 8 ++++---- drivers/gpu/drm/radeon/evergreend.h | 2 ++ 2 files changed, 6 insertions(+), 4 deletions(-)
drivers/gpu/drm/radeon/evergreen.c +2 -2
@@ -1730,7 +1730,7 @@ static void evergreen_gpu_init(struct racase CHIP_SUMO : rdev->config.evergreen.num_ses =1 ; rdev->config.evergreen.max_pipes =4 ; - rdev->config.evergreen.max_tile_pipes =2 ; + rdev->config.evergreen.max_tile_pipes =4 ;if (rdev->pdev->device ==0x9648 ) rdev->config.evergreen.max_simds =3 ; else if ((rdev->pdev->device == 0x9647) ||
@@ -1819,7 +1819,7 @@ static void evergreen_gpu_init(struct rabreak ;case CHIP_CAICOS : rdev->config.evergreen.num_ses =1 ; - rdev->config.evergreen.max_pipes =4 ; + rdev->config.evergreen.max_pipes =2 ; rdev->config.evergreen.max_tile_pipes =2 ; rdev->config.evergreen.max_simds =2 ; rdev->config.evergreen.max_backends =1 * rdev->config.evergreen.num_ses;
PATCH 128/173 NFS: avoid NULL dereference in nfs_destroy_server
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: NeilBrown <[email protected]>
commit f259613a1e4b44a0cf85a5dafd931be96ee7c9e5 upstream.
In rare circumstances, nfs_clone_server() of a v2 or v3 server can get an error between setting server->destory (to nfs_destroy_server), and calling nfs_start_lockd (which will set server->nlm_host).
If this happens, nfs_clone_server will call nfs_free_server which will call nfs_destroy_server and thence nlmclnt_done(NULL). This causes the NULL to be dereferenced.
So add a guard to only call nlmclnt_done() if ->nlm_host is not NULL.
The other guards there are irrelevant as nlm_host can only be non-NULL if one of these flags are set - so remove those tests. (Thanks to Trond for this suggestion).
This is suitable for any stable kernel since 2.6.25.
--- fs/nfs/client.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
fs/nfs/client.c +1 -2
@@ -615,8 +615,7 @@ EXPORT_SYMBOL_GPL(nfs_create_rpc_client);*/ static void nfs_destroy_server (struct nfs_server *server) { -if (!(server->flags &NFS_MOUNT_LOCAL_FLOCK ) || - !(server->flags &NFS_MOUNT_LOCAL_FCNTL )) +if (server->nlm_host)nlmclnt_done (server->nlm_host); }
PATCH 129/173 target/tcm_fc: fix the lockdep warning due to inconsistent lock state
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yi Zou <[email protected]>
commit 9f4ad44b264f8bb61ffdd607148215566568430d upstream.
The lockdep warning below is in theory correct but it will be in really weird rare situation that ends up that deadlock since the tcm fc session is hashed based the rport id. Nonetheless, the complaining below is about rcu callback that does the transport_deregister_session() is happening in softirq, where transport_register_session() that happens earlier is not. This triggers the lockdep warning below. So, just fix this to make lockdep happy by disabling the soft irq before calling transport_register_session() in ft_prli.
BTW, this was found in FCoE VN2VN over two VMs, couple of create and destroy would get this triggered.
v1: was enforcing register to be in softirq context which was not righ. See,
http://www.spinics.net/lists/target-devel/msg03614.html
v2: following comments from Roland&Nick (thanks), it seems we don't have to do transport_deregister_session() in rcu callback, so move it into ft_sess_free() but still do kfree() of the corresponding ft_sess struct in rcu callback to make sure the ft_sess is not freed till the rcu callback.
...
[ 1328.370592] scsi2 : FCoE Driver
[ 1328.383429] fcoe: No FDMI support.
[ 1328.384509] host2: libfc: Link up on port (000000)
[ 1328.934229] host2: Assigned Port ID 00a292
[ 1357.232132] host2: rport 00a393: Remove port
[ 1357.232568] host2: rport 00a393: Port sending LOGO from Ready state
[ 1357.233692] host2: rport 00a393: Delete port
[ 1357.234472] host2: rport 00a393: work event 3
[ 1357.234969] host2: rport 00a393: callback ev 3
[ 1357.235979] host2: rport 00a393: Received a LOGO response closed
[ 1357.236706] host2: rport 00a393: work delete
[ 1357.237481]
[ 1357.237631] =================================
[ 1357.238064] [ INFO: inconsistent lock state ]
[ 1357.238450] 3.7.0-rc7-yikvm+ #3 Tainted: G O
[ 1357.238450] ---------------------------------
[ 1357.238450] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
[ 1357.238450] ksoftirqd/0/3 [HC0[0]:SC1[1]:HE0:SE0] takes:
[ 1357.238450] (&(&se_tpg->session_lock)->rlock){+.?...}, at: [<ffffffffa01eacd4>] transport_deregister_session+0x41/0x148 [target_core_mod]
[ 1357.238450] {SOFTIRQ-ON-W} state was registered at:
[ 1357.238450] [<ffffffff810834f5>] mark_held_locks+0x6d/0x95
[ 1357.238450] [<ffffffff8108364a>] trace_hardirqs_on_caller+0x12d/0x197
[ 1357.238450] [<ffffffff810836c1>] trace_hardirqs_on+0xd/0xf
[ 1357.238450] [<ffffffff8149caba>] _raw_spin_unlock_irq+0x2d/0x45
[ 1357.238450] [<ffffffffa01e8d10>] __transport_register_session+0xb8/0x122 [target_core_mod]
[ 1357.238450] [<ffffffffa01e8dbe>] transport_register_session+0x44/0x5a [target_core_mod]
[ 1357.238450] [<ffffffffa018e32c>] ft_prli+0x1e3/0x275 [tcm_fc]
[ 1357.238450] [<ffffffffa0160e8d>] fc_rport_recv_req+0x95e/0xdc5 [libfc]
[ 1357.238450] [<ffffffffa015be88>] fc_lport_recv_els_req+0xc4/0xd5 [libfc]
[ 1357.238450] [<ffffffffa015c778>] fc_lport_recv_req+0x12f/0x18f [libfc]
[ 1357.238450] [<ffffffffa015a6d7>] fc_exch_recv+0x8ba/0x981 [libfc]
[ 1357.238450] [<ffffffffa0176d7a>] fcoe_percpu_receive_thread+0x47a/0x4e2 [fcoe]
[ 1357.238450] [<ffffffff810549f1>] kthread+0xb1/0xb9
[ 1357.238450] [<ffffffff814a40ec>] ret_from_fork+0x7c/0xb0
[ 1357.238450] irq event stamp: 275411
[ 1357.238450] hardirqs last enabled at (275410): [<ffffffff810bb6a0>] rcu_process_callbacks+0x229/0x42a
[ 1357.238450] hardirqs last disabled at (275411): [<ffffffff8149c2f7>] _raw_spin_lock_irqsave+0x22/0x8e
[ 1357.238450] softirqs last enabled at (275394): [<ffffffff8103d669>] __do_softirq+0x246/0x26f
[ 1357.238450] softirqs last disabled at (275399): [<ffffffff8103d6bb>] run_ksoftirqd+0x29/0x62
[ 1357.238450]
[ 1357.238450] other info that might help us debug this:
[ 1357.238450] Possible unsafe locking scenario:
[ 1357.238450]
[ 1357.238450] CPU0
[ 1357.238450] ----
[ 1357.238450] lock(&(&se_tpg->session_lock)->rlock);
[ 1357.238450] <Interrupt>
[ 1357.238450] lock(&(&se_tpg->session_lock)->rlock);
[ 1357.238450]
[ 1357.238450] *** DEADLOCK ***
[ 1357.238450]
[ 1357.238450] no locks held by ksoftirqd/0/3.
[ 1357.238450]
[ 1357.238450] stack backtrace:
[ 1357.238450] Pid: 3, comm: ksoftirqd/0 Tainted: G O 3.7.0-rc7-yikvm+ #3
[ 1357.238450] Call Trace:
[ 1357.238450] [<ffffffff8149399a>] print_usage_bug+0x1f5/0x206
[ 1357.238450] [<ffffffff8100da59>] ? save_stack_trace+0x2c/0x49
[ 1357.238450] [<ffffffff81082aae>] ? print_irq_inversion_bug.part.14+0x1ae/0x1ae
[ 1357.238450] [<ffffffff81083336>] mark_lock+0x106/0x258
[ 1357.238450] [<ffffffff81084e34>] __lock_acquire+0x2e7/0xe53
[ 1357.238450] [<ffffffff8102903d>] ? pvclock_clocksource_read+0x48/0xb4
[ 1357.238450] [<ffffffff810ba6a3>] ? rcu_process_gp_end+0xc0/0xc9
[ 1357.238450] [<ffffffffa01eacd4>] ? transport_deregister_session+0x41/0x148 [target_core_mod]
[ 1357.238450] [<ffffffff81085ef1>] lock_acquire+0x119/0x143
[ 1357.238450] [<ffffffffa01eacd4>] ? transport_deregister_session+0x41/0x148 [target_core_mod]
[ 1357.238450] [<ffffffff8149c329>] _raw_spin_lock_irqsave+0x54/0x8e
[ 1357.238450] [<ffffffffa01eacd4>] ? transport_deregister_session+0x41/0x148 [target_core_mod]
[ 1357.238450] [<ffffffffa01eacd4>] transport_deregister_session+0x41/0x148 [target_core_mod]
[ 1357.238450] [<ffffffff810bb6a0>] ? rcu_process_callbacks+0x229/0x42a
[ 1357.238450] [<ffffffffa018ddc5>] ft_sess_rcu_free+0x17/0x24 [tcm_fc]
[ 1357.238450] [<ffffffffa018ddae>] ? ft_sess_free+0x1b/0x1b [tcm_fc]
[ 1357.238450] [<ffffffff810bb6d7>] rcu_process_callbacks+0x260/0x42a
[ 1357.238450] [<ffffffff8103d55d>] __do_softirq+0x13a/0x26f
[ 1357.238450] [<ffffffff8149b34e>] ? __schedule+0x65f/0x68e
[ 1357.238450] [<ffffffff8103d6bb>] run_ksoftirqd+0x29/0x62
[ 1357.238450] [<ffffffff8105c83c>] smpboot_thread_fn+0x1a5/0x1aa
[ 1357.238450] [<ffffffff8105c697>] ? smpboot_unregister_percpu_thread+0x47/0x47
[ 1357.238450] [<ffffffff810549f1>] kthread+0xb1/0xb9
[ 1357.238450] [<ffffffff8149b49d>] ? wait_for_common+0xbb/0x10a
[ 1357.238450] [<ffffffff81054940>] ? __init_kthread_worker+0x59/0x59
[ 1357.238450] [<ffffffff814a40ec>] ret_from_fork+0x7c/0xb0
[ 1357.238450] [<ffffffff81054940>] ? __init_kthread_worker+0x59/0x59
[ 1417.440099] rport-2:0-0: blocked FC remote port time out: removing rport--- drivers/target/tcm_fc/tfc_sess.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/target/tcm_fc/tfc_sess.c +1 -1
@@ -430,7 +430,6 @@ static void ft_sess_rcu_free(struct rcu_head *rcu) { struct ft_sess *sess = container_of(rcu, struct ft_sess, rcu); -transport_deregister_session (sess->se_sess);kfree (sess); }
@@ -438,6 +437,7 @@ static void ft_sess_free(struct kref *kref) { struct ft_sess *sess = container_of(kref, struct ft_sess, kref); +transport_deregister_session (sess->se_sess);call_rcu (&sess->rcu, ft_sess_rcu_free); }
PATCH 130/173 mtd: nand: gpmi: reset BCH earlier, too, to avoid NAND startup problems
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wolfram Sang <[email protected]>
commit 6f2a6a52560ad8d85710aabd92b7a3239b3a6b07 upstream.
It could happen (1 out of 100 times) that NAND did not start up correctly after warm rebooting, so the kernel could not find the UBI or DMA timed out due to a stalled BCH. When resetting BCH together with GPMI, the issue could not be observed anymore (after 10000+ reboots). We probably need the consistent state already before sending any command to NAND, even when no ECC is needed. I chose to keep the extra reset for BCH when changing the flash layout to be on the safe side.
--- drivers/mtd/nand/gpmi-nand/gpmi-lib.c | 9 +++++++++ 1 file changed, 9 insertions(+)
drivers/mtd/nand/gpmi-nand/gpmi-lib.c +9 -0
@@ -165,6 +165,15 @@ int gpmi_init(struct gpmi_nand_data *this)if (ret) goto err_out; +/* +* Reset BCH here, too. We got failures otherwise :( +* See later BCH reset for explanation of MX23 handling +*/ + ret =gpmi_reset_block (r->bch_regs,GPMI_IS_MX23 (this)); +if (ret) + goto err_out; + +/* Choose NAND mode. */ writel (BM_GPMI_CTRL1_GPMI_MODE , r->gpmi_regs +HW_GPMI_CTRL1_CLR );
PATCH 131/173 ALSA: hda - Fix pin configuration of HP Pavilion dv7
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <[email protected]>
commit 8ae5865ec77c22462c736846a0679947a6953548 upstream.
Fix the quirk entry for HP Pavilion dv7 in order to make the bass speaker working.
--- sound/pci/hda/patch_sigmatel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
sound/pci/hda/patch_sigmatel.c +1 -1
@@ -1725,7 +1725,7 @@ static const struct snd_pci_quirk stac92hd83xxx_cfg_tbl[] = {SND_PCI_QUIRK (PCI_VENDOR_ID_HP ,0x1658 ,"HP" , STAC_92HD83XXX_HP_cNB11_INTQUAD),SND_PCI_QUIRK (PCI_VENDOR_ID_HP ,0x1659 , -"HP" , STAC_92HD83XXX_HP_cNB11_INTQUAD), +"HP Pavilion dv7" ,STAC_HP_DV7_4000 ),SND_PCI_QUIRK (PCI_VENDOR_ID_HP ,0x165A ,"HP" , STAC_92HD83XXX_HP_cNB11_INTQUAD), SND_PCI_QUIRK(PCI_VENDOR_ID_HP, 0x165B,
PATCH 132/173 MIPS: Fix poweroff failure when HOTPLUG_CPU configured.
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Huacai Chen <[email protected]>
commit 8add1ecb81f541ef2fcb0b85a5470ad9ecfb4a84 upstream.
When poweroff machine, kernel_power_off() call disable_nonboot_cpus(). And if we have HOTPLUG_CPU configured, disable_nonboot_cpus() is not an empty function but attempt to actually disable the nonboot cpus. Since system state is SYSTEM_POWER_OFF, play_dead() won't be called and thus disable_nonboot_cpus() hangs. Therefore, we make this patch to avoid poweroff failure.
Patchwork: https://patchwork.linux-mips.org/patch/4211/
--- arch/mips/kernel/process.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
arch/mips/kernel/process.c +1 -3
@@ -72,9 +72,7 @@ void __noreturn cpu_idle(void) } }#ifdef CONFIG_HOTPLUG_CPU -if (!cpu_online (cpu) && !cpu_isset (cpu, cpu_callin_map) && - (system_state ==SYSTEM_RUNNING || - system_state ==SYSTEM_BOOTING )) +if (!cpu_online (cpu) && !cpu_isset (cpu, cpu_callin_map))play_dead ();#endif tick_nohz_restart_sched_tick ();
PATCH 133/173 ALSA: hda - Always turn on pins for HDMI/DP
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <[email protected]>
commit 6169b673618bf0b2518ce413b54925782a603f06 upstream.
We've seen the broken HDMI *video* output on some machines with GM965, and the debugging session pointed that the culprit is the disabled audio output pins. Toggling these pins dynamically on demand caused flickering of HDMI TV.
This patch changes the behavior to keep the pin ON constantly.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=51421
--- sound/pci/hda/patch_hdmi.c | 18 ++++-------------- 1 file changed, 4 insertions(+), 14 deletions(-)
sound/pci/hda/patch_hdmi.c +4 -14
@@ -424,9 +424,11 @@ static void hdmi_init_pin(struct hda_codif (get_wcaps (codec, pin_nid) &AC_WCAP_OUT_AMP )snd_hda_codec_write (codec, pin_nid,0 ,AC_VERB_SET_AMP_GAIN_MUTE ,AMP_OUT_UNMUTE ); -/* Disable pin out until stream is active*/ +/* Enable pin out: some machines with GM965 gets broken output when +* the pin is disabled or changed while using with HDMI +*/ snd_hda_codec_write (codec, pin_nid,0 , -AC_VERB_SET_PIN_WIDGET_CONTROL ,0 ); +AC_VERB_SET_PIN_WIDGET_CONTROL ,PIN_OUT ); }static int hdmi_get_channel_count (struct hda_codec *codec,hda_nid_t cvt_nid)
@@ -1141,17 +1143,11 @@ static int generic_hdmi_playback_pcm_prestruct hdmi_spec *spec = codec->spec;int pin_idx =hinfo_to_pin_index (spec, hinfo);hda_nid_t pin_nid = spec->pins[pin_idx].pin_nid; -int pinctl;hdmi_set_channel_count (codec, cvt_nid, substream->runtime->channels);hdmi_setup_audio_infoframe (codec, pin_idx, substream); - pinctl =snd_hda_codec_read (codec, pin_nid,0 , -AC_VERB_GET_PIN_WIDGET_CONTROL ,0 ); -snd_hda_codec_write (codec, pin_nid,0 , -AC_VERB_SET_PIN_WIDGET_CONTROL , pinctl |PIN_OUT ); -return hdmi_setup_stream (codec, cvt_nid, pin_nid, stream_tag, format); }
@@ -1163,7 +1159,6 @@ static int generic_hdmi_playback_pcm_cleint cvt_idx, pin_idx;struct hdmi_spec_per_cvt *per_cvt;struct hdmi_spec_per_pin *per_pin; -int pinctl;snd_hda_codec_cleanup_stream (codec, hinfo->nid);
@@ -1182,11 +1177,6 @@ static int generic_hdmi_playback_pcm_clereturn -EINVAL ; per_pin = &spec->pins[pin_idx]; - pinctl =snd_hda_codec_read (codec, per_pin->pin_nid,0 , -AC_VERB_GET_PIN_WIDGET_CONTROL ,0 ); -snd_hda_codec_write (codec, per_pin->pin_nid,0 , -AC_VERB_SET_PIN_WIDGET_CONTROL , - pinctl & ~PIN_OUT );snd_hda_spdif_ctls_unassign (codec, pin_idx); }
PATCH 134/173 fix Null pointer dereference on disk error
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Xiaotian Feng <[email protected]>
commit 26cd4d65deba587f3cf2329b6869ce02bcbe68ec upstream.
Following oops were observed when disk error happened:
[ 4272.896937] sd 0:0:0:0: [sda] Unhandled error code [ 4272.896939] sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK [ 4272.896942] sd 0:0:0:0: [sda] CDB: Read(10): 28 00 00 5a de a7 00 00 08 00 [ 4272.896951] end_request: I/O error, dev sda, sector 5955239 [ 4291.574947] BUG: unable to handle kernel NULL pointer dereference at (null) [ 4291.658305] IP: [] ahci_activity_show+0x1/0x40 [ 4291.730090] PGD 76dbbc067 PUD 6c4fba067 PMD 0 [ 4291.783408] Oops: 0000 [#1] SMP [ 4291.822100] last sysfs file: /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/sw_activity [ 4291.934235] CPU 9 [ 4291.958301] Pid: 27942, comm: hwinfo ......
ata_scsi_find_dev could return NULL, so ata_scsi_activity_{show,store} should check if atadev is NULL.
--- drivers/ata/libata-scsi.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/ata/libata-scsi.c +4 -2
@@ -309,7 +309,8 @@ ata_scsi_activity_show(struct device *dev, struct device_attribute *attr,struct ata_port *ap =ata_shost_to_port (sdev->host);struct ata_device *atadev =ata_scsi_find_dev (ap, sdev); -if (ap->ops->sw_activity_show && (ap->flags &ATA_FLAG_SW_ACTIVITY )) +if (atadev && ap->ops->sw_activity_show && + (ap->flags &ATA_FLAG_SW_ACTIVITY ))return ap->ops->sw_activity_show (atadev, buf);return -EINVAL ; }
@@ -324,7 +325,8 @@ ata_scsi_activity_store(struct device *dev, struct device_attribute *attr,enum sw_activity val;int rc; -if (ap->ops->sw_activity_store && (ap->flags &ATA_FLAG_SW_ACTIVITY )) { +if (atadev && ap->ops->sw_activity_store && + (ap->flags &ATA_FLAG_SW_ACTIVITY )) { val =simple_strtoul (buf,NULL ,0 );switch (val) {case OFF :case BLINK_ON :case BLINK_OFF :
PATCH 135/173 i2400m: add Intel 6150 device IDs
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Williams <[email protected]>
commit 999a7c5776a0ed2133645fa7e008bec05bda9254 upstream.
Add device IDs for WiMAX function of Intel 6150 cards.
--- drivers/net/wimax/i2400m/i2400m-usb.h | 3 +++ drivers/net/wimax/i2400m/usb.c | 6 ++++++ 2 files changed, 9 insertions(+)
drivers/net/wimax/i2400m/i2400m-usb.h +3 -0
@@ -152,6 +152,9 @@ enum {/* Device IDs */ USB_DEVICE_ID_I6050 =0x0186 ,USB_DEVICE_ID_I6050_2 =0x0188 , +USB_DEVICE_ID_I6150 =0x07d6 , +USB_DEVICE_ID_I6150_2 =0x07d7 , +USB_DEVICE_ID_I6150_3 =0x07d9 , USB_DEVICE_ID_I6250 = 0x0187, };
drivers/net/wimax/i2400m/usb.c +6 -0
@@ -510,6 +510,9 @@ int i2400mu_probe(struct usb_interface *iface,switch (id->idProduct) {case USB_DEVICE_ID_I6050 :case USB_DEVICE_ID_I6050_2 : +case USB_DEVICE_ID_I6150 : +case USB_DEVICE_ID_I6150_2 : +case USB_DEVICE_ID_I6150_3 :case USB_DEVICE_ID_I6250 : i2400mu->i6050 =1 ;break ;
@@ -759,6 +762,9 @@ staticstruct usb_device_id i2400mu_id_table[] = { {USB_DEVICE (0x8086 ,USB_DEVICE_ID_I6050 ) }, {USB_DEVICE (0x8086 ,USB_DEVICE_ID_I6050_2 ) }, + {USB_DEVICE (0x8087 ,USB_DEVICE_ID_I6150 ) }, + {USB_DEVICE (0x8087 ,USB_DEVICE_ID_I6150_2 ) }, + {USB_DEVICE (0x8087 ,USB_DEVICE_ID_I6150_3 ) }, {USB_DEVICE (0x8086 ,USB_DEVICE_ID_I6250 ) }, {USB_DEVICE (0x8086 ,0x0181 ) }, {USB_DEVICE (0x8086 ,0x1403 ) },
PATCH 136/173 Input: walkera0701 - fix crash on startup
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peter Popovec <[email protected]>
commit a455e2985f57e2a71566bb8850094af38b2c932d upstream.
The driver's timer must be set up before enabling IRQ handler, otherwise bad things may happen.
--- drivers/input/joystick/walkera0701.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/input/joystick/walkera0701.c +4 -3
@@ -196,6 +196,7 @@ static void walkera0701_close(struct input_dev *dev)struct walkera_dev *w =input_get_drvdata (dev);parport_disable_irq (w->parport); +hrtimer_cancel (&w->timer); }static int walkera0701_connect (struct walkera_dev *w,int parport)
@@ -224,6 +225,9 @@ static int walkera0701_connect(struct walkera_dev *w, int parport)if (parport_claim (w->pardevice)) goto init_err1; +hrtimer_init (&w->timer,CLOCK_MONOTONIC ,HRTIMER_MODE_REL ); + w->timer.function = timer_handler; + w->input_dev =input_allocate_device ();if (!w->input_dev) goto init_err2;
@@ -254,8 +258,6 @@ static int walkera0701_connect(struct walkera_dev *w, int parport)if (err) goto init_err3; -hrtimer_init (&w->timer,CLOCK_MONOTONIC ,HRTIMER_MODE_REL ); - w->timer.function = timer_handler;return 0 ; init_err3:
@@ -271,7 +273,6 @@ static int walkera0701_connect(struct walkera_dev *w, int parport)static void walkera0701_disconnect (struct walkera_dev *w) { -hrtimer_cancel (&w->timer);input_unregister_device (w->input_dev);parport_release (w->pardevice);parport_unregister_device (w->pardevice);
PATCH 137/173 ALSA: hda - Fix the wrong pincaps set in ALC861VD dallas/hp fixup
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <[email protected]>
commit b78562b10fa66175e30b76073e32a0ad8d92aa83 upstream.
The workaround to force VREF50 for dallas/hp model with ALC861VD was introduced in commit 8fdcb6fe4204bdb4c6991652717ab5063751414e, but it contained wrong pincap override bits.
This patch fixes to exclude VREF80 pincap bit correctly.
--- sound/pci/hda/patch_realtek.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
sound/pci/hda/patch_realtek.c +2 -2
@@ -6570,8 +6570,8 @@ static void alc861vd_fixup_dallas(struct hda_codec *codec, const struct alc_fixup *fix, int action) { if (action == ALC_FIXUP_ACT_PRE_PROBE) { - snd_hda_override_pin_caps(codec, 0x18, 0x00001714); -snd_hda_override_pin_caps (codec,0x19 ,0x0000171c ); + snd_hda_override_pin_caps(codec, 0x18, 0x00000734); +snd_hda_override_pin_caps (codec,0x19 ,0x0000073c ); } }
PATCH 138/173 proc: pid/status: show all supplementary groups
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Artem Bityutskiy <[email protected]>
commit 8d238027b87e654be552eabdf492042a34c5c300 upstream.
We display a list of supplementary group for each process in /proc/<pid>/status. However, we show only the first 32 groups, not all of them.
Although this is rare, but sometimes processes do have more than 32 supplementary groups, and this kernel limitation breaks user-space apps that rely on the group list in /proc/<pid>/status.
Number 32 comes from the internal NGROUPS_SMALL macro which defines the length for the internal kernel "small" groups buffer. There is no apparent reason to limit to this value.
This patch removes the 32 groups printing limit.
The Linux kernel limits the amount of supplementary groups by NGROUPS_MAX, which is currently set to 65536. And this is the maximum count of groups we may possibly print.
--- fs/proc/array.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/proc/array.c +1 -1
@@ -204,7 +204,7 @@ static inline void task_state(struct seq group_info = cred->group_info;task_unlock (p); -for (g =0 ; g <min (group_info->ngroups,NGROUPS_SMALL ); g++) +for (g =0 ; g < group_info->ngroups; g++)seq_printf (m,"%d " ,GROUP_AT (group_info, g));put_cred (cred);
PATCH 139/173 nfsd4: fix oops on unusual readlike compound
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: "J. Bruce Fields" <[email protected]>
commit d5f50b0c290431c65377c4afa1c764e2c3fe5305 upstream.
If the argument and reply together exceed the maximum payload size, then a reply with a read-like operation can overlow the rq_pages array.
--- fs/nfsd/nfs4xdr.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-)
fs/nfsd/nfs4xdr.c +10 -1
@@ -2909,11 +2909,16 @@ nfsd4_encode_read(struct nfsd4_compoundr len = maxcount; v =0 ;while (len >0 ) { - pn = resp->rqstp->rq_resused++; + pn = resp->rqstp->rq_resused; +if (!resp->rqstp->rq_respages[pn]) {/* ran out of pages */ + maxcount -= len; +break ; + } resp->rqstp->rq_vec[v].iov_base =page_address (resp->rqstp->rq_respages[pn]); resp->rqstp->rq_vec[v].iov_len = len <PAGE_SIZE ? len :PAGE_SIZE ; + resp->rqstp->rq_resused++; v++; len -=PAGE_SIZE ; }
@@ -2959,6 +2964,8 @@ nfsd4_encode_readlink(struct nfsd4_comporeturn nfserr;if (resp->xbuf->page_len)return nfserr_resource; +if (!resp->rqstp->rq_respages[resp->rqstp->rq_resused]) +return nfserr_resource; page =page_address (resp->rqstp->rq_respages[resp->rqstp->rq_resused++]);
@@ -3008,6 +3015,8 @@ nfsd4_encode_readdir(struct nfsd4_compoureturn nfserr;if (resp->xbuf->page_len)return nfserr_resource; +if (!resp->rqstp->rq_respages[resp->rqstp->rq_resused]) +return nfserr_resource;RESERVE_SPACE (8 );/* verifier */ savep = p;
PATCH 140/173 CRIS: fix I/O macros
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Corey Minyard <[email protected]>
commit c24bf9b4cc6a0f330ea355d73bfdf1dae7e63a05 upstream.
The inb/outb macros for CRIS are broken from a number of points of view, missing () around parameters and they have an unprotected if statement in them. This was breaking the compile of IPMI on CRIS and thus I was being annoyed by build regressions, so I fixed them.
Plus I don't think they would have worked at all, since the data values were missing "&" and the outsl had a "3" instead of a "4" for the size.
Quoted 1 line
Quoted 1 line
From what I can tell, this stuff is not used at all, so this can't be
any more broken than it was before, anyway.
--- arch/cris/include/asm/io.h | 39 +++++++++++++++++++++++++++++++++------ 1 file changed, 33 insertions(+), 6 deletions(-)
arch/cris/include/asm/io.h +33 -6
@@ -133,12 +133,39 @@ static inline void writel(unsigned int b, volatile void __iomem *addr)#define insb (port,addr,count) (cris_iops ? cris_iops->read_io(port,addr,1,count) : 0)#define insw (port,addr,count) (cris_iops ? cris_iops->read_io(port,addr,2,count) : 0)#define insl (port,addr,count) (cris_iops ? cris_iops->read_io(port,addr,4,count) : 0) -#define outb (data,port) if (cris_iops) cris_iops->write_io(port,(void*)(unsigned)data,1,1) -#define outw (data,port) if (cris_iops) cris_iops->write_io(port,(void*)(unsigned)data,2,1) -#define outl (data,port) if (cris_iops) cris_iops->write_io(port,(void*)(unsigned)data,4,1) -#define outsb (port,addr,count) if(cris_iops) cris_iops->write_io(port,(void*)addr,1,count) -#define outsw (port,addr,count) if(cris_iops) cris_iops->write_io(port,(void*)addr,2,count) -#define outsl (port,addr,count) if(cris_iops) cris_iops->write_io(port,(void*)addr,3,count) +static inline void outb (unsigned char data,unsigned int port) +{ +if (cris_iops) + cris_iops->write_io (port, (void *) &data,1 ,1 ); +} +static inline void outw (unsigned short data,unsigned int port) +{ +if (cris_iops) + cris_iops->write_io (port, (void *) &data,2 ,1 ); +} +static inline void outl (unsigned int data,unsigned int port) +{ +if (cris_iops) + cris_iops->write_io (port, (void *) &data,4 ,1 ); +} +static inline void outsb (unsigned int port,const void *addr, +unsigned long count) +{ +if (cris_iops) + cris_iops->write_io (port, (void *)addr,1 , count); +} +static inline void outsw (unsigned int port,const void *addr, +unsigned long count) +{ +if (cris_iops) + cris_iops->write_io (port, (void *)addr,2 , count); +} +static inline void outsl (unsigned int port,const void *addr, +unsigned long count) +{ +if (cris_iops) + cris_iops->write_io (port, (void *)addr,4 , count); +}/* * Convert a physical pointer to a virtual kernel pointer for /dev/mem
PATCH 141/173 ARM: missing ->mmap_sem around find_vma() in swp_emulate.c
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Al Viro <[email protected]>
commit 7bf9b7bef881aac820bf1f2e9951a17b09bd7e04 upstream.
find_vma() is *not* safe when somebody else is removing vmas. Not just the return value might get bogus just as you are getting it (this instance doesn't try to dereference the resulting vma), the search itself can get buggered in rather spectacular ways. IOW, ->mmap_sem really, really is not optional here.
--- arch/arm/kernel/swp_emulate.c | 2 ++ 1 file changed, 2 insertions(+)
arch/arm/kernel/swp_emulate.c +2 -0
@@ -109,10 +109,12 @@ static void set_segfault(struct pt_regs *regs, unsigned long addr) {siginfo_t info; +down_read (¤t->mm->mmap_sem);if (find_vma (current->mm, addr) ==NULL ) info.si_code =SEGV_MAPERR ;else info.si_code =SEGV_ACCERR ; +up_read (¤t->mm->mmap_sem); info.si_signo =SIGSEGV ; info.si_errno =0 ;
PATCH 142/173 intel-iommu: Free old page tables before creating superpage
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Woodhouse, David" <[email protected]>
commit 6491d4d02893d9787ba67279595990217177b351 upstream.
The dma_pte_free_pagetable() function will only free a page table page if it is asked to free the *entire* 2MiB range that it covers. So if a page table page was used for one or more small mappings, it's likely to end up still present in the page tables... but with no valid PTEs.
This was fine when we'd only be repopulating it with 4KiB PTEs anyway but the same virtual address range can end up being reused for a *large-page* mapping. And in that case were were trying to insert the large page into the second-level page table, and getting a complaint from the sanity check in __domain_mapping() because there was already a corresponding entry. This was *relatively* harmless; it led to a memory leak of the old page table page, but no other ill-effects.
Fix it by calling dma_pte_clear_range (hopefully redundant) and dma_pte_free_pagetable() before setting up the new large page.
--- drivers/iommu/intel-iommu.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-)
drivers/iommu/intel-iommu.c +9 -2
@@ -1827,10 +1827,17 @@ static int __domain_mapping(struct dmar_domain *domain, unsigned long iov_pfn,if (!pte)return -ENOMEM ;/* It is large page*/ -if (largepage_lvl >1 ) +if (largepage_lvl >1 ) { pteval |=DMA_PTE_LARGE_PAGE ; -else +/* Ensure that old small page tables are removed to make room +for superpage, if they exist. */ +dma_pte_clear_range (domain, iov_pfn, + iov_pfn +lvl_to_nr_pages (largepage_lvl) -1 ); +dma_pte_free_pagetable (domain, iov_pfn, + iov_pfn +lvl_to_nr_pages (largepage_lvl) -1 ); + }else { pteval &= ~(uint64_t )DMA_PTE_LARGE_PAGE ; + } }/* We don't need lock here, nobody else
PATCH 143/173 vfs: d_obtain_alias() needs to use "/" as default name.
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: NeilBrown <[email protected]>
commit b911a6bdeef5848c468597d040e3407e0aee04ce upstream.
NFS appears to use d_obtain_alias() to create the root dentry rather than d_make_root. This can cause 'prepend_path()' to complain that the root has a weird name if an NFS filesystem is lazily unmounted. e.g. if "/mnt" is an NFS mount then
{ cd /mnt; umount -l /mnt ; ls -l /proc/self/cwd; }
will cause a WARN message like
WARNING: at /home/git/linux/fs/dcache.c:2624 prepend_path+0x1d7/0x1e0() ... Root dentry has weird name <>
to appear in kernel logs.
So change d_obtain_alias() to use "/" rather than "" as the anonymous name.
--- fs/dcache.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/dcache.c +1 -1
@@ -1492,7 +1492,7 @@ static struct dentry * d_find_any_alias(*/ struct dentry *d_obtain_alias (struct inode *inode) { -static const struct qstr anonstring = { .name ="" }; +static const struct qstr anonstring = { .name ="/" , .len =1 };struct dentry *tmp;struct dentry *res;
PATCH 144/173 exec: do not leave bprm->interp on stack
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kees Cook <[email protected]>
commit b66c5984017533316fd1951770302649baf1aa33 upstream.
If a series of scripts are executed, each triggering module loading via unprintable bytes in the script header, kernel stack contents can leak into the command line.
Normally execution of binfmt_script and binfmt_misc happens recursively. However, when modules are enabled, and unprintable bytes exist in the bprm->buf, execution will restart after attempting to load matching binfmt modules. Unfortunately, the logic in binfmt_script and binfmt_misc does not expect to get restarted. They leave bprm->interp pointing to their local stack. This means on restart bprm->interp is left pointing into unused stack memory which can then be copied into the userspace argv areas.
After additional study, it seems that both recursion and restart remains the desirable way to handle exec with scripts, misc, and modules. As such, we need to protect the changes to interp.
This changes the logic to require allocation for any changes to the bprm->interp. To avoid adding a new kmalloc to every exec, the default value is left as-is. Only when passing through binfmt_script or binfmt_misc does an allocation take place.
For a proof of concept, see DoTest.sh from:
http://www.halfdog.net/Security/2012/LinuxKernelBinfmtScriptStackDataDisclosure/
--- fs/binfmt_misc.c | 5 ++++- fs/binfmt_script.c | 4 +++- fs/exec.c | 15 +++++++++++++++ include/linux/binfmts.h | 1 + 4 files changed, 23 insertions(+), 2 deletions(-)
fs/binfmt_misc.c +4 -1
@@ -172,7 +172,10 @@ static int load_misc_binary(struct linux_binprm *bprm) goto _error; bprm->argc ++; - bprm->interp = iname;/* for binfmt_script */ +/* Update interp in case binfmt_script needs it. */ + retval =bprm_change_interp (iname, bprm); +if (retval <0 ) + goto _error; interp_file =open_exec (iname); retval =PTR_ERR (interp_file);
fs/binfmt_script.c +3 -1
@@ -80,7 +80,9 @@ static int load_script(struct linux_binprm *bprm) retval =copy_strings_kernel (1 , &i_name, bprm);if (retval)return retval; bprm->argc++; - bprm->interp = interp; + retval =bprm_change_interp (interp, bprm); +if (retval <0 ) +return retval;/* * OK, now restart the process with the interpreter's dentry.
fs/exec.c +15 -0
@@ -1175,9 +1175,24 @@ void free_bprm(struct linux_binprm *bprm)mutex_unlock (¤t->signal->cred_guard_mutex);abort_creds (bprm->cred); } +/* If a binfmt changed the interp, free it. */ +if (bprm->interp != bprm->filename) +kfree (bprm->interp);kfree (bprm); } +int bprm_change_interp (char *interp,struct linux_binprm *bprm) +{ +/* If a binfmt changed the interp, free it first. */ +if (bprm->interp != bprm->filename) +kfree (bprm->interp); + bprm->interp =kstrdup (interp,GFP_KERNEL ); +if (!bprm->interp) +return -ENOMEM ; +return 0 ; +} +EXPORT_SYMBOL (bprm_change_interp); +/* * install the new credentials for this executable */
include/linux/binfmts.h +1 -0
@@ -112,6 +112,7 @@ extern int setup_arg_pages(struct linux_binprm * bprm,unsigned long stack_top, int executable_stack);extern int bprm_mm_init (struct linux_binprm *bprm); +extern int bprm_change_interp (char *interp,struct linux_binprm *bprm);extern int copy_strings_kernel (int argc,const char *const *argv,struct linux_binprm *bprm);extern int prepare_bprm_creds (struct linux_binprm *bprm);
PATCH 145/173 SGI-XP: handle non-fatal traps
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Robin Holt <[email protected]>
commit 891348ca0f66206f1dc0e30d63757e3df1ae2d15 upstream.
We found a user code which was raising a divide-by-zero trap. That trap would lead to XPC connections between system-partitions being torn down due to the die_chain notifier callouts it received.
This also revealed a different issue where multiple callers into xpc_die_deactivate() would all attempt to do the disconnect in parallel which would sometimes lock up but often overwhelm the console on very large machines as each would print at least one line of output at the end of the deactivate.
I reviewed all the users of the die_chain notifier and changed the code to ignore the notifier callouts for reasons which will not actually lead to a system to continue on to call die().
--- drivers/misc/sgi-xp/xpc_main.c | 34 ++++++++++++++++++++++++++++++++-- 1 file changed, 32 insertions(+), 2 deletions(-)
drivers/misc/sgi-xp/xpc_main.c +32 -2
@@ -53,6 +53,10 @@#include <linux/kthread.h> #include "xpc.h" +#ifdef CONFIG_X86_64 +#include <asm/traps.h> +#endif +/* define two XPC debug device structures to be used with dev_dbg() et al */ struct device_driver xpc_dbg_name = {
@@ -1079,6 +1083,9 @@ xpc_system_reboot(struct notifier_block *nb, unsigned long event, void *unused)return NOTIFY_DONE ; } +/* Used to only allow one cpu to complete disconnect */ +static unsigned int xpc_die_disconnecting; +/* * Notify other partitions to deactivate from us by first disengaging from all * references to our memory.
@@ -1092,6 +1099,9 @@ xpc_die_deactivate(void)long keep_waiting;long wait_to_print; +if (cmpxchg (&xpc_die_disconnecting,0 ,1 )) +return ; +/* keep xpc_hb_checker thread from doing anything (just in case) */ xpc_exiting =1 ;
@@ -1159,7 +1169,7 @@ xpc_die_deactivate(void)* about the lack of a heartbeat. */ static int -xpc_system_die (struct notifier_block *nb,unsigned long event,void *unused) +xpc_system_die (struct notifier_block *nb,unsigned long event,void *_die_args) {#ifdef CONFIG_IA64 /* !!! temporary kludge */ switch (event) {
@@ -1191,7 +1201,27 @@ xpc_system_die(struct notifier_block *nb, unsigned long event, void *unused) break; }#else -xpc_die_deactivate (); +struct die_args *die_args = _die_args; + +switch (event) { +case DIE_TRAP : +if (die_args->trapnr ==X86_TRAP_DF ) +xpc_die_deactivate (); + +if (((die_args->trapnr ==X86_TRAP_MF ) || + (die_args->trapnr ==X86_TRAP_XF )) && + !user_mode_vm (die_args->regs)) +xpc_die_deactivate (); + +break ; +case DIE_INT3 : +case DIE_DEBUG : +break ; +case DIE_OOPS : +case DIE_GPF : +default : +xpc_die_deactivate (); + }#endif return NOTIFY_DONE ;
PATCH 146/173 dm persistent data: rename node to btree_node
In reply to Ben Hutchings3.2-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mikulas Patocka <[email protected]>
commit 550929faf89e2e2cdb3e9945ea87d383989274cf upstream.
This patch fixes a compilation failure on sparc32 by renaming struct node.
struct node is already defined in include/linux/node.h. On sparc32, it happens to be included through other dependencies and persistent-data doesn't compile because of conflicting declarations.
--- drivers/md/persistent-data/dm-btree-internal.h | 16 ++++---- drivers/md/persistent-data/dm-btree-remove.c | 50 ++++++++++++------------ drivers/md/persistent-data/dm-btree-spine.c | 6 +-- drivers/md/persistent-data/dm-btree.c | 22 +++++------ 4 files changed, 47 insertions(+), 47 deletions(-)
drivers/md/persistent-data/dm-btree-internal.h +8 -8
@@ -36,13 +36,13 @@ struct node_header {__le32 padding; } __packed; -struct node { +struct btree_node {struct node_header header;__le64 keys[0 ]; } __packed; -void inc_children (struct dm_transaction_manager *tm,struct node *n, +void inc_children (struct dm_transaction_manager *tm,struct btree_node *n,struct dm_btree_value_type *vt);int new_block (struct dm_btree_info *info,struct dm_block **result);
@@ -64,7 +64,7 @@ struct ro_spine {void init_ro_spine (struct ro_spine *s,struct dm_btree_info *info);int exit_ro_spine (struct ro_spine *s);int ro_step (struct ro_spine *s,dm_block_t new_child); -struct node *ro_node (struct ro_spine *s); +struct btree_node *ro_node (struct ro_spine *s);struct shadow_spine {struct dm_btree_info *info;
@@ -98,12 +98,12 @@ int shadow_root(struct shadow_spine *s);/* * Some inlines. */ -static inline __le64 *key_ptr (struct node *n,uint32_t index) +static inline __le64 *key_ptr (struct btree_node *n,uint32_t index) {return n->keys + index; } -static inline void *value_base (struct node *n) +static inline void *value_base (struct btree_node *n) {return &n->keys[le32_to_cpu (n->header.max_entries)]; }
@@ -111,7 +111,7 @@ static inline void *value_base(struct no/* * FIXME: Now that value size is stored in node we don't need the third parm. */ -static inline void *value_ptr (struct node *n,uint32_t index,size_t value_size) +static inline void *value_ptr (struct btree_node *n,uint32_t index,size_t value_size) {BUG_ON (value_size !=le32_to_cpu (n->header.value_size));return value_base (n) + (value_size * index);
@@ -120,7 +120,7 @@ static inline void *value_ptr(struct nod/* * Assumes the values are suitably-aligned and converts to core format. */ -static inline uint64_t value64 (struct node *n,uint32_t index) +static inline uint64_t value64 (struct btree_node *n,uint32_t index) {__le64 *values_le =value_base (n);
@@ -130,7 +130,7 @@ static inline uint64_t value64(struct no/* * Searching for a key within a single node. */ -int lower_bound (struct node *n,uint64_t key); +int lower_bound (struct btree_node *n,uint64_t key);extern struct dm_block_validator btree_node_validator;
drivers/md/persistent-data/dm-btree-remove.c +25 -25
164 lines not on this page · raw message
drivers/md/persistent-data/dm-btree-spine.c +3 -3
@@ -23,7 +23,7 @@ static void node_prepare_for_write(struc struct dm_block *b, size_t block_size) { -struct node *n =dm_block_data (b); +struct btree_node *n =dm_block_data (b);struct node_header *h = &n->header; h->blocknr =cpu_to_le64 (dm_block_location (b));
@@ -38,7 +38,7 @@ static int node_check(struct dm_block_va struct dm_block *b, size_t block_size) { -struct node *n =dm_block_data (b); +struct btree_node *n =dm_block_data (b);struct node_header *h = &n->header;size_t value_size;__le32 csum_disk;
@@ -164,7 +164,7 @@ int ro_step(struct ro_spine *s, dm_blockreturn r; } -struct node *ro_node (struct ro_spine *s) +struct btree_node *ro_node (struct ro_spine *s) {struct dm_block *block;
drivers/md/persistent-data/dm-btree.c +11 -11
@@ -38,7 +38,7 @@ static void array_insert(void *base, siz/*----------------------------------------------------------------*/ /* makes the assumption that no two keys are the same. */ -static int bsearch (struct node *n,uint64_t key,int want_hi) +static int bsearch (struct btree_node *n,uint64_t key,int want_hi) {int lo =-1 , hi =le32_to_cpu (n->header.nr_entries);
@@ -58,12 +58,12 @@ static int bsearch(struct node *n, uint6return want_hi ? hi : lo; } -int lower_bound (struct node *n,uint64_t key) +int lower_bound (struct btree_node *n,uint64_t key) {return bsearch (n, key,0 ); } -void inc_children (struct dm_transaction_manager *tm,struct node *n, +void inc_children (struct dm_transaction_manager *tm,struct btree_node *n,struct dm_btree_value_type *vt) {unsigned i;
@@ -78,7 +78,7 @@ void inc_children(struct dm_transaction_ value_ptr(n, i, vt->size)); } -static int insert_at (size_t value_size,struct node *node,unsigned index, +static int insert_at (size_t value_size,struct btree_node *node,unsigned index,uint64_t key,void *value)__dm_written_to_disk (value) {
@@ -123,7 +123,7 @@ int dm_btree_empty(struct dm_btree_info {int r;struct dm_block *b; -struct node *n; +struct btree_node *n;size_t block_size;uint32_t max_entries;
@@ -155,7 +155,7 @@ EXPORT_SYMBOL_GPL(dm_btree_empty);#define MAX_SPINE_DEPTH 64struct frame {struct dm_block *b; -struct node *n; +struct btree_node *n;unsigned level;unsigned nr_children;unsigned current_child;
@@ -296,7 +296,7 @@ EXPORT_SYMBOL_GPL(dm_btree_del);/*----------------------------------------------------------------*/ static int btree_lookup_raw (struct ro_spine *s,dm_block_t block,uint64_t key, -int (*search_fn)(struct node *,uint64_t ), +int (*search_fn)(struct btree_node *,uint64_t ),uint64_t *result_key,void *v,size_t value_size) {int i, r;
@@ -407,7 +407,7 @@ static int btree_split_sibling(struct shsize_t size;unsigned nr_left, nr_right;struct dm_block *left, *right, *parent; -struct node *ln, *rn, *pn; +struct btree_node *ln, *rn, *pn;__le64 location; left =shadow_current (s);
@@ -492,7 +492,7 @@ static int btree_split_beneath(struct shsize_t size;unsigned nr_left, nr_right;struct dm_block *left, *right, *new_parent; -struct node *pn, *ln, *rn; +struct btree_node *pn, *ln, *rn;__le64 val; new_parent =shadow_current (s);
@@ -577,7 +577,7 @@ static int btree_insert_raw(struct shado uint64_t key, unsigned *index) { int r, i = *index, top = 1; -struct node *node; +struct btree_node *node;for (;;) { r =shadow_step (s, root, vt);
@@ -644,7 +644,7 @@ static int insert(struct dm_btree_info *unsigned level, index =-1 , last_level = info->levels -1 ;dm_block_t block = root;struct shadow_spine spine; -struct node *n; +struct btree_node *n;struct dm_btree_value_type le64_type; le64_type.context =NULL ;