summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2013-04-05Merge tag 'dm-3.9-fixes-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-dm Pull device-mapper fixes from Alasdair Kergon: "A pair of patches to fix the writethrough mode of the device-mapper cache target when the device being cached is not itself wrapped with device-mapper." * tag 'dm-3.9-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-dm: dm cache: reduce bio front_pad size in writeback mode dm cache: fix writes to cache device in writethrough mode
2013-04-05Merge tag 'pci-v3.9-fixes-1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci Pull PCI fixes from Bjorn Helgaas: "PCI updates for v3.9: ASPM Revert "PCI/ACPI: Request _OSC control before scanning PCI root bus" kexec PCI: Don't try to disable Bus Master on disconnected PCI devices Platform ROM images PCI: Add PCI ROM helper for platform-provided ROM images nouveau: Attempt to use platform-provided ROM image radeon: Attempt to use platform-provided ROM image Hotplug PCI/ACPI: Always resume devices on ACPI wakeup notifications PCI/PM: Disable runtime PM of PCIe ports EISA EISA/PCI: Fix bus res reference EISA/PCI: Init EISA early, before PNP" * tag 'pci-v3.9-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci: PCI/PM: Disable runtime PM of PCIe ports PCI/ACPI: Always resume devices on ACPI wakeup notifications PCI: Don't try to disable Bus Master on disconnected PCI devices Revert "PCI/ACPI: Request _OSC control before scanning PCI root bus" radeon: Attempt to use platform-provided ROM image nouveau: Attempt to use platform-provided ROM image EISA/PCI: Init EISA early, before PNP EISA/PCI: Fix bus res reference PCI: Add PCI ROM helper for platform-provided ROM images
2013-04-05Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netLinus Torvalds
Pull networking fixes from David Miller: 1) Fix erroneous sock_orphan() leading to crashes and double kfree_skb() in NFC protocol. From Thierry Escande and Samuel Ortiz. 2) Fix use after free in remain-on-channel mac80211 code, from Johannes Berg. 3) nf_reset() needs to reset the NF tracing cookie, otherwise we can leak it from one namespace into another. Fix from Gao Feng and Patrick McHardy. 4) Fix overflow in channel scanning array of mwifiex driver, from Stone Piao. 5) Fix loss of link after suspend/shutdown in r8169, from Hayes Wang. 6) Synchronization of unicast address lists to the undelying device doesn't work because whether to sync is maintained as a boolean rather than a true count. Fix from Vlad Yasevich. 7) Fix corruption of TSO packets in atl1e by limiting the segmented packet length. From Hannes Frederic Sowa. 8) Revert bogus AF_UNIX credential passing change and fix the coalescing issue properly, from Eric W Biederman. 9) Changes of ipv4 address lifetime settings needs to generate a notification, from Jiri Pirko. * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (22 commits) netfilter: don't reset nf_trace in nf_reset() net: ipv4: notify when address lifetime changes ixgbe: fix registration order of driver and DCA nofitication af_unix: If we don't care about credentials coallesce all messages Revert "af_unix: dont send SCM_CREDENTIAL when dest socket is NULL" bonding: remove sysfs before removing devices atl1e: limit gso segment size to prevent generation of wrong ip length fields net: count hw_addr syncs so that unsync works properly. r8169: fix auto speed down issue netfilter: ip6t_NPT: Fix translation for non-multiple of 32 prefix lengths mwifiex: limit channel number not to overflow memory NFC: microread: Fix build failure due to a new MEI bus API iwlwifi: dvm: fix the passive-no-RX workaround netfilter: nf_conntrack: fix error return code NFC: llcp: Keep the connected socket parent pointer alive mac80211: fix idle handling sequence netfilter: nfnetlink_acct: return -EINVAL if object name is empty netfilter: nfnetlink_queue: fix error return code in nfnetlink_queue_init() netfilter: reset nf_trace in nf_reset mac80211: fix remain-on-channel cancel crash ...
2013-04-05firmware,IB/qib: revert firmware file moveMike Marciniszyn
Commit e2eed58b4fbf ("IB/qib: change QLogic to Intel") moved a firmware file potentially breaking the ABI. This patch reverts that aspect of the fix as well as reverting the firmware name as used in qib. Reported-by: David Woodhouse <dwmw2@infradead.org> Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-04-05Merge tag 'spi-fix-v3.9-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/misc Pull spi fixes from Mark Brown: "A bunch of small driver fixes plus a fix for error handling in the core - nothing too exciting overall." * tag 'spi-fix-v3.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/misc: spi/mpc512x-psc: optionally keep PSC SS asserted across xfer segmensts spi: Unlock a spinlock before calling into the controller driver. spi/s3c64xx: modified error interrupt handling and init spi/bcm63xx: don't disable non enabled clocks in probe error path spi/bcm63xx: Remove unused variable spi: slink-tegra20: move runtime pm calls to transfer_one_message
2013-04-05Revert "drivers/rtc/rtc-at91rm9200.c: use a variable for storing IMR"Johan Hovold
This reverts commit 0ef1594c017521ea89278e80fe3f80dafb17abde. This patch introduced a few races which cannot be easily fixed with a small follow-up patch. Furthermore, the SoC with the broken hardware register, which this patch intended to add support for, can only be used with device trees, which this driver currently does not support. [ Here is the discussion that led to this "revert" patch: https://lkml.org/lkml/2013/4/3/176 ] Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-04-05Merge tag 'fbdev-fixes-3.9-rc6' of git://gitorious.org/linux-omap-dss2/linuxLinus Torvalds
Pull fbdev fixes from Tomi Valkeinen: "Fix uvesafb crash bug and typoed flag name in fbmon's new videomode code" * tag 'fbdev-fixes-3.9-rc6' of git://gitorious.org/linux-omap-dss2/linux: video:uvesafb: Fix dereference NULL pointer code path fbmon: use VESA_DMT_VSYNC_HIGH to fix typo
2013-04-05dm cache: reduce bio front_pad size in writeback modeMike Snitzer
A recent patch to fix the dm cache target's writethrough mode extended the bio's front_pad to include a 1056-byte struct dm_bio_details. Writeback mode doesn't need this, so this patch reduces the per_bio_data_size to 16 bytes in this case instead of 1096. The dm_bio_details structure was added in "dm cache: fix writes to cache device in writethrough mode" which fixed commit e2e74d617e ("dm cache: fix race in writethrough implementation"). In writeback mode we avoid allocating the writethrough-specific members of the per_bio_data structure (the dm_bio_details structure included). Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2013-04-05dm cache: fix writes to cache device in writethrough modeDarrick J. Wong
The dm-cache writethrough strategy introduced by commit e2e74d617eadc15 ("dm cache: fix race in writethrough implementation") issues a bio to the origin device, remaps and then issues the bio to the cache device. This more conservative in-series approach was selected to favor correctness over performance (of the previous parallel writethrough). However, this in-series implementation that reuses the same bio to write both the origin and cache device didn't take into account that the block layer's req_bio_endio() modifies a completing bio's bi_sector and bi_size. So the new writethrough strategy needs to preserve these bio fields, and restore them before submission to the cache device, otherwise nothing gets written to the cache (because bi_size is 0). This patch adds a struct dm_bio_details field to struct per_bio_data, and uses dm_bio_record() and dm_bio_restore() to ensure the bio is restored before reissuing to the cache device. Adding such a large structure to the per_bio_data is not ideal but we can improve this later, for now correctness is the important thing. This problem initially went unnoticed because the dm-cache test-suite uses a linear DM device for the dm-cache device's origin device. Writethrough worked as expected because DM submits a *clone* of the original bio, so the original bio which was reused for the cache was never touched. Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by: Joe Thornber <ejt@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2013-04-05ixgbe: fix registration order of driver and DCA nofiticationJakub Kicinski
ixgbe_notify_dca cannot be called before driver registration because it expects driver's klist_devices to be allocated and initialized. While on it make sure debugfs files are removed when registration fails. Cc: stable <stable@vger.kernel.org> Signed-off-by: Jakub Kicinski <jakub.kicinski@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2013-04-05bonding: remove sysfs before removing devicesVeaceslav Falico
We have a race condition if we try to rmmod bonding and simultaneously add a bond master through sysfs. In bonding_exit() we first remove the devices (through rtnl_link_unregister() ) and only after that we remove the sysfs. If we manage to add a device through sysfs after that the devices were removed - we'll end up with that device/sysfs structure and with the module unloaded. Fix this by first removing the sysfs and only after that calling rtnl_link_unregister(). Signed-off-by: Veaceslav Falico <vfalico@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2013-04-05atl1e: limit gso segment size to prevent generation of wrong ip length fieldsHannes Frederic Sowa
The limit of 0x3c00 is taken from the windows driver. Suggested-by: Huang, Xiong <xiong@qca.qualcomm.com> Cc: Huang, Xiong <xiong@qca.qualcomm.com> Cc: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2013-04-04Merge tag 'pm+acpi-3.9-rc6' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPI and power management fixes from Rafael Wysocki: - Revert of a recent cpuidle change that caused Nehalem machines to hang on boot from Alex Shi. - USB power management fix addressing a crash in the port device object's release routine from Rafael J Wysocki. - Device PM QoS fix for a potential deadlock related to sysfs interface from Rafael J Wysocki. - Fix for a cpufreq crash when the /cpus Device Tree node is missing from Paolo Pisati. - Fix for a build issue on ia64 related to the Boot Graphics Resource Table (BGRT) from Tony Luck. - Two fixes for ACPI handles being set incorrectly for device objects that don't correspond to any ACPI namespace nodes in the I2C and SPI subsystems from Rafael J Wysocki. - Fix for compiler warnings related to CONFIG_PM_DEVFREQ being unset from Rajagopal Venkat. - Fix for a symbol definition typo in cpufreq_governor.h from Borislav Petkov. * tag 'pm+acpi-3.9-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI / BGRT: Don't let users configure BGRT on non X86 systems cpuidle / ACPI: recover percpu ACPI processor cstate ACPI / I2C: Use parent's ACPI_HANDLE() in acpi_i2c_register_devices() cpufreq: Correct header guards typo ACPI / SPI: Use parent's ACPI_HANDLE() in acpi_register_spi_devices() cpufreq: check OF node /cpus presence before dereferencing it PM / devfreq: Fix compiler warnings for CONFIG_PM_DEVFREQ unset PM / QoS: Avoid possible deadlock related to sysfs access USB / PM: Don't try to hide PM QoS flags from usb_port_device_release()
2013-04-04r8169: fix auto speed down issuehayeswang
It would cause no link after suspending or shutdowning when the nic changes the speed to 10M and connects to a link partner which forces the speed to 100M. Check the link partner ability to determine which speed to set. Signed-off-by: Hayes Wang <hayeswang@realtek.com> Acked-by: Francois Romieu <romieu@fr.zoreil.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2013-04-04Merge branch 'for-davem' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into wireless John W. Linville says: ==================== Here are some more fixes intended for the 3.9 stream... Regarding the mac80211 bits, Johannes says: "I had changed the idle handling to simplify it, but broken the sequencing of commands, at least for ath9k-htc, one patch restores the sequence. The other patch fixes a crash Jouni found while stress-testing the remain-on-channel code, when an item is deleted the work struct can run twice and crash the second time." As for the iwlwifi bits, Johannes says: "The only fix here is to the passive-no-RX firmware regulatory enforcement driver support code to not drop auth frames in quick succession, leading to not being able to connect to APs on passive channels in certain circumstances." Don't forget the NFC bits, about which Samuel says: "This time we have: - A crash fix for when a DGRAM LLCP socket is listening while the NFC adapter is physically removed. - A potential double skb free when the LLCP socket receive queue is full. - A fix for properly handling multiple and consecutive LLCP connections, and not trash the socket ack log. - A build failure for the MEI microread physical layer, now that the MEI bus APIs have been merged into char-misc-next." On top of that, Stone Piao provides an mwifiex fix to avoid accessing beyond the end of a buffer. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2013-04-04Merge branch 'pm-fixes' into fixesRafael J. Wysocki
* pm-fixes: cpufreq: Correct header guards typo cpufreq: check OF node /cpus presence before dereferencing it PM / devfreq: Fix compiler warnings for CONFIG_PM_DEVFREQ unset PM / QoS: Avoid possible deadlock related to sysfs access USB / PM: Don't try to hide PM QoS flags from usb_port_device_release()
2013-04-04Merge branch 'for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid Pull HID fixes from Jiri Kosina: - Workaround for device ID conflict between Masterkit MA901 usb radio device and Atmel V-USB devices, to avoid regressions from older kernels, by Alexey Klimov - fix for possible race during input device registration in magicmouse driver, by Benjamin Tissoires * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid: HID: magicmouse: fix race between input_register() and probe() media: radio-ma901: return ENODEV in probe if usb_device doesn't match HID: fix Masterkit MA901 hid quirks
2013-04-04Merge tag 'gpio-fixes-v3.9' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio Pull GPIO fixes from Linus Walleij: "Two GPIO fixes for the v3.9 series: - Fix erroneous return value in the ICH driver - Make the STMPE driver proper properly on device tree boots" * tag 'gpio-fixes-v3.9' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: gpio: stmpe: pass DT node to irqdomain gpio-ich: Fix value returned by ichx_gpio_request
2013-04-04HID: magicmouse: fix race between input_register() and probe()Benjamin Tissoires
Since kernel 3.7, it appears that the input registration occured before the end of magicmouse_setup_input(). This is shown by receiving a lot of "EV_SYN SYN_REPORT 1" instead of normal "EV_SYN SYN_REPORT 0". This value means that the output buffer is full, and the user space is loosing events. Using .input_configured guarantees that the race is not occuring, and that the call of "input_set_events_per_packet(input, 60)" is taken into account by input_register(). Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=908604 Cc: stable@vger.kernel.org Reported-and-Tested-By: Clarke Wixon <cwixon@usa.net> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-04-03PCI/PM: Disable runtime PM of PCIe portsRafael J. Wysocki
The runtime PM of PCIe ports turns out to be quite fragile, as in some cases things work while in some other cases they don't and we don't seem to have a good way to determine whether or not they are going to work in advance. For this reason, avoid enabling runtime PM for PCIe ports by keeping their runtime PM reference counters always above 0 for the time being. When a PCIe port is suspended, it can no longer report events like hotplug, so hotplug below the port may not work, as in the bug report below. [bhelgaas: changelog, stable] Reference: https://bugzilla.kernel.org/show_bug.cgi?id=53811 Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org # v3.6+
2013-04-03PCI/ACPI: Always resume devices on ACPI wakeup notificationsRafael J. Wysocki
It turns out that the _Lxx control methods provided by some BIOSes clear the PME Status bit of PCI devices they handle, which means that pci_acpi_wake_dev() cannot really use that bit to check whether or not the device has signalled wakeup. One symptom of the problem is, for example, that when an affected PCI USB controller is runtime-suspended, then plugging in a new USB device into one of the controller's ports will not wake up the controller, which should happen. For this reason, make pci_acpi_wake_dev() always attempt to resume the device it is called for regardless of the device's PME Status bit value (that bit still has to be cleared if set at this point, though). Reported-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Matthew Garrett <mjg59@srcf.ucam.org> CC: stable@vger.kernel.org # v3.7+
2013-04-03Merge branch 'master' of ↵John W. Linville
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem
2013-04-03Merge branch 'for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 fixes from Martin Schwidefsky: "Just a bunch of bugfixes" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390/mm: provide emtpy check_pgt_cache() function s390/uaccess: fix page table walk s390/3270: fix minor_start issue s390/uaccess: fix clear_user_pt() s390/scm_blk: fix error return code in scm_blk_init() s390/scm_block: fix printk format string drivers/Kconfig: add several missing GENERIC_HARDIRQS dependencies
2013-04-03ACPI / BGRT: Don't let users configure BGRT on non X86 systemsTony Luck
Fengguang Wu's 0-Day kernel build testing backend found the following build error for an allmodconfig build on ia64: drivers/built-in.o: In function `show_yoffset': >> bgrt.c:(.text+0xe5a71): undefined reference to `bgrt_tab' >> bgrt.c:(.text+0xe5a91): undefined reference to `bgrt_tab' drivers/built-in.o: In function `show_xoffset': >> bgrt.c:(.text+0xe5b51): undefined reference to `bgrt_tab' >> bgrt.c:(.text+0xe5b71): undefined reference to `bgrt_tab' drivers/built-in.o: In function `show_type': >> bgrt.c:(.text+0xe5c31): undefined reference to `bgrt_tab' drivers/built-in.o:bgrt.c:(.text+0xe5c51): more undefined references to `bgrt_tab' follow drivers/built-in.o: In function `bgrt_init': bgrt.c:(.init.text+0x8931): undefined reference to `bgrt_image' bgrt.c:(.init.text+0x8932): undefined reference to `bgrt_image_size' bgrt.c:(.init.text+0x8950): undefined reference to `bgrt_image' bgrt.c:(.init.text+0x8960): undefined reference to `bgrt_image_size' The problem is that all these undefined names are provided by arch/x86/platform/efi/efi-bgrt.c - which is obviously not available to the ia64 build. It doesn't seem useful to provide the BGRT support for Itanium (many systems are headless and have no graphics at all). So just don't let users configure this driver on non-X86 machines. Reported-by: Fengguang Wu <fengguang.wu@intel.com> Acked-by: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-04-02Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netLinus Torvalds
Pull networking fixes from David Miller: 1) Fix VSOCK layer handling of context ID changes, from Reilly Grant. 2) Now that we have a synchronize_net() in netdev_rx_handler_unregister(), we can't let any call sites hold locks. Unfortunately bonding does, so we have to drop the rwlock there a little bit earlier, fix from Veaceslav Falico. 3) MAC address setting loop exits one iteration too early in mlx4 driver, from Yan Burman. 4) Restore ipv6 routes properly upon ifdown/ifup of loopback, from Balakumaran Kannan. * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: VSOCK: Handle changes to the VMCI context ID. net IPv6 : Fix broken IPv6 routing table after loopback down-up cbq: incorrect processing of high limits net/mlx4_en: Fix setting initial MAC address bonding: get netdev_rx_handler_unregister out of locks
2013-04-02Merge tag 'regmap-v3.9-rc4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap Pull regmap fixes from Mark Brown: "A small collection of fixes. The most important ones are those from Stephen and Lars-Peter both of which fix cache issues that have been lurking for a while but not manifesting noticably enough for anyone to report them." * tag 'regmap-v3.9-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap: regmap: async: Add missing return regmap: don't corrupt work buffer in _regmap_raw_write() regmap: cache Fix regcache-rbtree sync regmap: Initialize `map->debugfs' before regcache
2013-04-02PCI: Don't try to disable Bus Master on disconnected PCI devicesKonstantin Khlebnikov
This is a fix for commit 7897e60227 ("PCI: Disable Bus Master unconditionally in pci_device_shutdown()"). Vivek reported that with this commit, kexec failed because none of his SATA disks came up. A ->shutdown() callback might put the device in D3cold, which means config space is no longer available. [bhelgaas: changelog] Link: https://lkml.org/lkml/2013/3/12/529 Reported-and-Tested-by: Vivek Goyal <vgoyal@redhat.com> Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-04-02Revert "PCI/ACPI: Request _OSC control before scanning PCI root bus"Bjorn Helgaas
This reverts commit 8c33f51df406e1a1f7fa4e9b244845b7ebd61fa6. Conflicts: drivers/acpi/pci_root.c This commit broke some pre-1.1 PCIe devices by leaving them with ASPM enabled. Previously, we had disabled ASPM on these devices because many of them don't implement it correctly (per 149e1637). Requesting _OSC control early means that aspm_disabled may be set before we scan the PCI bus and configure link ASPM state. But the ASPM configuration currently skips the check for pre-PCIe 1.1 devices when aspm_disabled is set, like this: acpi_pci_root_add acpi_pci_osc_support if (flags != base_flags) pcie_no_aspm aspm_disabled = 1 pci_acpi_scan_root ... pcie_aspm_init_link_state pcie_aspm_sanity_check if (!aspm_disabled) /* check for pre-PCIe 1.1 device */ Therefore, setting aspm_disabled early means that we leave ASPM enabled on these pre-PCIe 1.1 devices, which is a regression for some devices. The best fix would be to clean up the ASPM init so we can evaluate _OSC before scanning the bug (that way boot-time and hot-add discovery will work the same), but that requires significant rework. For now, we'll just revert the _OSC change as the lowest-risk fix. Reference: https://bugzilla.kernel.org/show_bug.cgi?id=55211 Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Yinghai Lu <yinghai@kernel.org> CC: stable@vger.kernel.org # v3.8+
2013-04-02Merge branch 'pci/yinghai-eisa' into for-linusBjorn Helgaas
* pci/yinghai-eisa: EISA/PCI: Init EISA early, before PNP EISA/PCI: Fix bus res reference
2013-04-03drm: correctly restore mappings if drm_open failsIlija Hadzic
If first drm_open fails, the error-handling path will incorrectly restore inode's mapping to NULL. This can cause the crash later on. Fix by separately storing away mapping pointers that drm_open can touch and restore each from its own respective variable if the call fails. Fixes: https://bugzilla.novell.com/show_bug.cgi?id=807850 (thanks to Michal Hocko for investigating investigating and finding the root cause of the bug) Reference: http://lists.freedesktop.org/archives/dri-devel/2013-March/036564.html v2: Use one variable to store file and inode mapping since they are the same at the function entry. Fix spelling mistakes in commit message. v3: Add reference to the original bug report. Reported-by: Marco Munderloh <munderl@tnt.uni-hannover.de> Tested-by: Marco Munderloh <munderl@tnt.uni-hannover.de> Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com> Cc: Michal Hocko <mhocko@suse.cz> Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-04-03Merge branch 'drm-nouveau-fixes-3.9' of ↵Dave Airlie
git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next Oops fixers. * 'drm-nouveau-fixes-3.9' of git://anongit.freedesktop.org/git/nouveau/linux-2.6: drm/nouveau: fix NULL ptr dereference from nv50_disp_intr() drm/nouveau: fix handling empty channel list in ioctl's
2013-04-03Merge branch 'drm-intel-fixes' of ↵Dave Airlie
git://people.freedesktop.org/~danvet/drm-intel into drm-next One locking regression fix, and a couple of other i915 ones. * 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel: drm: don't unlock in the addfb error paths drm/i915: Fix build failure drm/i915: Be sure to turn hsync/vsync back on at crt enable (v2) drm/i915: duct-tape locking when eDP init fails
2013-04-02net/mlx4_en: Fix setting initial MAC addressYan Burman
Commit 6bbb6d9 "net/mlx4_en: Optimize Rx fast path filter checks" introduced a regression under which the MAC address read from the card was not converted correctly (the most significant byte was not handled), fix that. Reviewed-by: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: Yan Burman <yanb@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2013-04-02bonding: get netdev_rx_handler_unregister out of locksVeaceslav Falico
Now that netdev_rx_handler_unregister contains synchronize_net(), we need to call it outside of bond->lock, cause it might sleep. Also, remove the already unneded synchronize_net(). Signed-off-by: Veaceslav Falico <vfalico@redhat.com> Acked-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2013-04-02Merge tag 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-socLinus Torvalds
Pull ARM SoC bug fixes from Arnd Bergmann: "After a quiet set of fixes for 3.9-rc4, a lot of people woke up and sent urgent fixes for 3.9. I pushed back on a number of them that got deferred to 3.10, but these are the ones that seemed important. Regression in 3.9: - Multiple regressions in OMAP2+ clock cleanup - SH-Mobile frame buffer bug fix that merged here because of maintainer MIA - ux500 prcmu changes broke DT booting - MMCI duplicated regulator setup on ux500 - New ux500 clock driver broke ethernet on snowball - Local interrupt driver for mvebu broke ethernet - MVEBU GPIO driver did not get set up right on Orion DT - incorrect interrupt number on Orion crypto for DT Long-standing bugs, including candidates for stable: - Kirkwood MMC needs to disable invalid card detect pins - MV SDIO pinmux was wrong on Mirabox - GoFlex Net board file needs to set NAND chip delay - MSM timer restart race - ep93xx early debug code broke in 3.7 - i.MX CPU hotplug race - Incorrect clock setup for OMAP1 USB - Workaround for bad clock setup by some old OMAP4 boot loaders - Static I/O mappings on cns3xxx since 3.2" * tag 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: ARM: cns3xxx: fix mapping of private memory region arm: mvebu: Fix pinctrl for Armada 370 Mirabox SDIO port. arm: orion5x: correct IRQ used in dtsi for mv_cesa arm: orion5x: fix orion5x.dtsi gpio parameters ARM: Kirkwood: fix unused mvsdio gpio pins arm: mvebu: Use local interrupt only for the timer 0 ARM: kirkwood: Fix chip-delay for GoFlex Net ARM: ux500: Enable the clock controlling Ethernet on Snowball ARM: ux500: Stop passing ios_handler() as an MMCI power controlling call-back ARM: ux500: Apply the TCPM and TCDM locations and sizes to dbx5x0 DT fbdev: sh_mobile_lcdc: fixup B side hsync adjust settings ARM: OMAP: clocks: Delay clk inits atleast until slab is initialized ARM: imx: fix sync issue between imx_cpu_die and imx_cpu_kill ARM: msm: Stop counting before reprogramming clockevent ARM: ep93xx: Fix wait for UART FIFO to be empty ARM: OMAP4: PM: fix PM regression introduced by recent clock cleanup ARM: OMAP3: hwmod data: keep MIDLEMODE in force-standby for musb ARM: OMAP4: clock data: lock USB DPLL on boot ARM: OMAP1: fix USB host on 1710
2013-04-02cpuidle / ACPI: recover percpu ACPI processor cstateAlex Shi
Commit ac3ebafa81af76d6 "ACPI / idle: remove usage of the statedata" changed the percpu processor cstate to a unified cstate in ACPI idle. That caused all our NHM boxes to boot hang or panic. 2178751 Task dump for CPU 1: 2178752 swapper/1 R running task 6736 0 1 0x00000000 2178753 ffff8801e8029dc8 ffffffff8101cf96 ffff8801e8029e28 ffffffff813d294b 2178754 0000000000000f99 0000000000000003 00000000003cf654 0000000025c17d03 2178755 ffff8801e8029e38 ffff8801e74fc000 00000002590dc5c4 ffffffff8163cdb0 2178756 Call Trace: 2178757 [<ffffffff8101cf96>] ? acpi_processor_ffh_cstate_enter+0x2d/0x2f 2178758 [<ffffffff813d294b>] acpi_idle_enter_bm+0x1b1/0x236 2178759 [<ffffffff8163cdb0>] ? disable_cpuidle+0x10/0x10 2178760 [<ffffffff8163cdc2>] cpuidle_enter+0x12/0x14 2178761 [<ffffffff8163d286>] cpuidle_wrap_enter+0x2f/0x6d 2178762 [<ffffffff8163d2d4>] cpuidle_enter_tk+0x10/0x12 2178763 [<ffffffff8163cdd6>] cpuidle_enter_state+0x12/0x3a 2178764 [<ffffffff8163d4a7>] cpuidle_idle_call+0xe8/0x161 2178765 [<ffffffff81008d99>] cpu_idle+0x5e/0xa4 2178766 [<ffffffff8174c6c1>] start_secondary+0x1a9/0x1ad 2178767 Task dump for CPU 2: In fact, the ACPI idle is based on the assumption of difference percpu cstate structures that are necessary for the implementation to work cprrectly. A unique acpi_processor_cx is not sifficient by far. This patch is just a quick fix re-introducing the percpu cstates. If someone really wants to unify the ACPI cstates, please make sure that the whole software infrastructure is changed and take hardware as well as many different kinds of BIOS settings into account. [rjw: Changelog] Reported-by: LKP project <lkp@linux.intel.com> Reported-by: Xie ChanglongX <changlongx.xie@intel.com> Tested-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Alex Shi <alex.shi@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-04-02ACPI / I2C: Use parent's ACPI_HANDLE() in acpi_i2c_register_devices()Rafael J. Wysocki
The ACPI handle of struct i2c_adapter's dev member should not be set, because this causes that struct i2c_adapter to be associated with the ACPI device node corresponding to its parent as the second "physical_device", which is incorrect (this happens during the registration of struct i2c_adapter). Consequently, acpi_i2c_register_devices() should use the ACPI handle of the parent of the struct i2c_adapter it is called for rather than the struct i2c_adapter's ACPI handle (which should be NULL). Make that happen and modify the i2c-designware-platdrv driver, which currently is the only driver for ACPI-enumerated I2C controller chips, not to set the ACPI handle for the struct i2c_adapter it creates. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Aaron Lu <aaron.lu@intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Wolfram Sang <wsa@the-dreams.de>
2013-04-02cpufreq: Correct header guards typoBorislav Petkov
It should be "governor". Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-04-02video:uvesafb: Fix dereference NULL pointer code pathWang YanQing
platform_device_alloc could failed and return NULL, we should check this before call platform_device_put. Signed-off-by: Wang YanQing <udknight@gmail.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-04-02fbmon: use VESA_DMT_VSYNC_HIGH to fix typoJingoo Han
VESA_DMT_VSYNC_HIGH should be used instead of VESA_DMT_HSYNC_HIGH, because FB_SYNC_VERT_HIGH_ACT is related to vsync, not to hsync. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Acked-by: Steffen Trumtrar <s.trumtrar@pengutronix.de> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-04-02ACPI / SPI: Use parent's ACPI_HANDLE() in acpi_register_spi_devices()Rafael J. Wysocki
The ACPI handle of struct spi_master's dev member should not be set, because this causes that struct spi_master to be associated with the ACPI device node corresponding to its parent as the second "physical_device", which is incorrect (this happens during the registration of struct spi_master). Consequently, acpi_register_spi_devices() should use the ACPI handle of the parent of the struct spi_master it is called for rather than that struct spi_master's ACPI handle (which should be NULL). Make that happen and modify the spi-pxa2xx driver, which currently is the only driver for ACPI-enumerated SPI controller chips, not to set the ACPI handle for the struct spi_master it creates. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
2013-04-02cpufreq: check OF node /cpus presence before dereferencing itPaolo Pisati
Check for the presence of the '/cpus' OF node before dereferencing it blindly: [ 4.181793] Unable to handle kernel NULL pointer dereference at virtual address 0000001c [ 4.181793] pgd = c0004000 [ 4.181823] [0000001c] *pgd=00000000 [ 4.181823] Internal error: Oops: 5 [#1] SMP ARM [ 4.181823] Modules linked in: [ 4.181823] CPU: 1 Tainted: G W (3.8.0-15-generic #25~hbankD) [ 4.181854] PC is at of_get_next_child+0x64/0x70 [ 4.181854] LR is at of_get_next_child+0x24/0x70 [ 4.181854] pc : [<c04fda18>] lr : [<c04fd9d8>] psr: 60000113 [ 4.181854] sp : ed891ec0 ip : ed891ec0 fp : ed891ed4 [ 4.181884] r10: c04dafd0 r9 : c098690c r8 : c0936208 [ 4.181884] r7 : ed890000 r6 : c0a63d00 r5 : 00000000 r4 : 00000000 [ 4.181884] r3 : 00000000 r2 : 00000000 r1 : 00000000 r0 : c0b2acc8 [ 4.181884] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [ 4.181884] Control: 10c5387d Table: adcb804a DAC: 00000015 [ 4.181915] Process swapper/0 (pid: 1, stack limit = 0xed890238) [ 4.181915] Stack: (0xed891ec0 to 0xed892000) [ 4.181915] 1ec0: c09b7b70 00000007 ed891efc ed891ed8 c04daff4 c04fd9c0 00000000 c09b7b70 [ 4.181915] 1ee0: 00000007 c0a63d00 ed890000 c0936208 ed891f54 ed891f00 c00088e0 c04dafdc [ 4.181945] 1f00: ed891f54 ed891f10 c006e940 00000000 00000000 00000007 00000007 c08a4914 [ 4.181945] 1f20: 00000000 c07dbd30 c0a63d00 c09b7b70 00000007 c0a63d00 000000bc c0936208 [ 4.181945] 1f40: c098690c c0986914 ed891f94 ed891f58 c0936a40 c00087bc 00000007 00000007 [ 4.181976] 1f60: c0936208 be8bda20 b6eea010 c0a63d00 c064547c 00000000 00000000 00000000 [ 4.181976] 1f80: 00000000 00000000 ed891fac ed891f98 c0645498 c09368c8 00000000 00000000 [ 4.181976] 1fa0: 00000000 ed891fb0 c0014658 c0645488 00000000 00000000 00000000 00000000 [ 4.182006] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 4.182006] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000 [ 4.182037] [<c04fda18>] (of_get_next_child+0x64/0x70) from [<c04daff4>] (cpu0_cpufreq_driver_init+0x24/0x284) [ 4.182067] [<c04daff4>] (cpu0_cpufreq_driver_init+0x24/0x284) from [<c00088e0>] (do_one_initcall+0x130/0x1b0) [ 4.182067] [<c00088e0>] (do_one_initcall+0x130/0x1b0) from [<c0936a40>] (kernel_init_freeable+0x184/0x24c) [ 4.182098] [<c0936a40>] (kernel_init_freeable+0x184/0x24c) from [<c0645498>] (kernel_init+0x1c/0xf4) [ 4.182128] [<c0645498>] (kernel_init+0x1c/0xf4) from [<c0014658>] (ret_from_fork+0x14/0x20) [ 4.182128] Code: f57ff04f e320f004 e89da830 e89da830 (e595001c) [ 4.182128] ---[ end trace 634903a22e8609cb ]--- [ 4.182189] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b [ 4.182189] [ 4.642395] CPU0: stopping [rjw: Changelog] Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-04-02PM / QoS: Avoid possible deadlock related to sysfs accessRafael J. Wysocki
Commit b81ea1b (PM / QoS: Fix concurrency issues and memory leaks in device PM QoS) put calls to pm_qos_sysfs_add_latency(), pm_qos_sysfs_add_flags(), pm_qos_sysfs_remove_latency(), and pm_qos_sysfs_remove_flags() under dev_pm_qos_mtx, which was a mistake, because it may lead to deadlocks in some situations. For example, if pm_qos_remote_wakeup_store() is run in parallel with dev_pm_qos_constraints_destroy(), they may deadlock in the following way: ====================================================== [ INFO: possible circular locking dependency detected ] 3.9.0-rc4-next-20130328-sasha-00014-g91a3267 #319 Tainted: G W ------------------------------------------------------- trinity-child6/12371 is trying to acquire lock: (s_active#54){++++.+}, at: [<ffffffff81301631>] sysfs_addrm_finish+0x31/0x60 but task is already holding lock: (dev_pm_qos_mtx){+.+.+.}, at: [<ffffffff81f07cc3>] dev_pm_qos_constraints_destroy+0x23/0x250 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (dev_pm_qos_mtx){+.+.+.}: [<ffffffff811811da>] lock_acquire+0x1aa/0x240 [<ffffffff83dab809>] __mutex_lock_common+0x59/0x5e0 [<ffffffff83dabebf>] mutex_lock_nested+0x3f/0x50 [<ffffffff81f07f2f>] dev_pm_qos_update_flags+0x3f/0xc0 [<ffffffff81f05f4f>] pm_qos_remote_wakeup_store+0x3f/0x70 [<ffffffff81efbb43>] dev_attr_store+0x13/0x20 [<ffffffff812ffdaa>] sysfs_write_file+0xfa/0x150 [<ffffffff8127f2c1>] __kernel_write+0x81/0x150 [<ffffffff812afc2d>] write_pipe_buf+0x4d/0x80 [<ffffffff812af57c>] splice_from_pipe_feed+0x7c/0x120 [<ffffffff812afa25>] __splice_from_pipe+0x45/0x80 [<ffffffff812b14fc>] splice_from_pipe+0x4c/0x70 [<ffffffff812b1538>] default_file_splice_write+0x18/0x30 [<ffffffff812afae3>] do_splice_from+0x83/0xb0 [<ffffffff812afb2e>] direct_splice_actor+0x1e/0x20 [<ffffffff812b0277>] splice_direct_to_actor+0xe7/0x200 [<ffffffff812b15bc>] do_splice_direct+0x4c/0x70 [<ffffffff8127eda9>] do_sendfile+0x169/0x300 [<ffffffff8127ff94>] SyS_sendfile64+0x64/0xb0 [<ffffffff83db7d18>] tracesys+0xe1/0xe6 -> #0 (s_active#54){++++.+}: [<ffffffff811800cf>] __lock_acquire+0x15bf/0x1e50 [<ffffffff811811da>] lock_acquire+0x1aa/0x240 [<ffffffff81300aa2>] sysfs_deactivate+0x122/0x1a0 [<ffffffff81301631>] sysfs_addrm_finish+0x31/0x60 [<ffffffff812ff77f>] sysfs_hash_and_remove+0x7f/0xb0 [<ffffffff813035a1>] sysfs_unmerge_group+0x51/0x70 [<ffffffff81f068f4>] pm_qos_sysfs_remove_flags+0x14/0x20 [<ffffffff81f07490>] __dev_pm_qos_hide_flags+0x30/0x70 [<ffffffff81f07cd5>] dev_pm_qos_constraints_destroy+0x35/0x250 [<ffffffff81f06931>] dpm_sysfs_remove+0x11/0x50 [<ffffffff81efcf6f>] device_del+0x3f/0x1b0 [<ffffffff81efd128>] device_unregister+0x48/0x60 [<ffffffff82d4083c>] usb_hub_remove_port_device+0x1c/0x20 [<ffffffff82d2a9cd>] hub_disconnect+0xdd/0x160 [<ffffffff82d36ab7>] usb_unbind_interface+0x67/0x170 [<ffffffff81f001a7>] __device_release_driver+0x87/0xe0 [<ffffffff81f00559>] device_release_driver+0x29/0x40 [<ffffffff81effc58>] bus_remove_device+0x148/0x160 [<ffffffff81efd07f>] device_del+0x14f/0x1b0 [<ffffffff82d344f9>] usb_disable_device+0xf9/0x280 [<ffffffff82d34ff8>] usb_set_configuration+0x268/0x840 [<ffffffff82d3a7fc>] usb_remove_store+0x4c/0x80 [<ffffffff81efbb43>] dev_attr_store+0x13/0x20 [<ffffffff812ffdaa>] sysfs_write_file+0xfa/0x150 [<ffffffff8127f71d>] do_loop_readv_writev+0x4d/0x90 [<ffffffff8127f999>] do_readv_writev+0xf9/0x1e0 [<ffffffff8127faba>] vfs_writev+0x3a/0x60 [<ffffffff8127fc60>] SyS_writev+0x50/0xd0 [<ffffffff83db7d18>] tracesys+0xe1/0xe6 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(dev_pm_qos_mtx); lock(s_active#54); lock(dev_pm_qos_mtx); lock(s_active#54); *** DEADLOCK *** To avoid that, remove the calls to functions mentioned above from under dev_pm_qos_mtx and introduce a separate lock to prevent races between functions that add or remove device PM QoS sysfs attributes from happening. Reported-by: Sasha Levin <sasha.levin@oracle.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-04-02USB / PM: Don't try to hide PM QoS flags from usb_port_device_release()Rafael J. Wysocki
Remove the call to dev_pm_qos_hide_flags(), added by commit 6e30d7cb "usb: Add driver/usb/core/(port.c,hub.h) files", from usb_port_device_release(), because (1) it is completely unnecessary (the flags have been removed already by the PM core during the unregistration of the device object) and (2) it triggers a NULL pointer dereference in sysfs_find_dirent() (dev->kobj.sd is NULL at this point). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-04-01Merge tag 'fixes-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux Pull virtio fixes from Rusty Russell: "One reversion, a tiny leak fix, and a cc:stable locking fix, in two parts" * tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux: virtio: console: add locking around c_ovq operations virtio: console: rename cvq_lock to c_ivq_lock hw_random: free rng_buffer at module exit Revert "virtio_console: Initialize guest_connected=true for rproc_serial"
2013-04-01loop: prevent bdev freeing while device in useAnatol Pomozov
struct block_device lifecycle is defined by its inode (see fs/block_dev.c) - block_device allocated first time we access /dev/loopXX and deallocated on bdev_destroy_inode. When we create the device "losetup /dev/loopXX afile" we want that block_device stay alive until we destroy the loop device with "losetup -d". But because we do not hold /dev/loopXX inode its counter goes 0, and inode/bdev can be destroyed at any moment. Usually it happens at memory pressure or when user drops inode cache (like in the test below). When later in loop_clr_fd() we want to use bdev we have use-after-free error with following stack: BUG: unable to handle kernel NULL pointer dereference at 0000000000000280 bd_set_size+0x10/0xa0 loop_clr_fd+0x1f8/0x420 [loop] lo_ioctl+0x200/0x7e0 [loop] lo_compat_ioctl+0x47/0xe0 [loop] compat_blkdev_ioctl+0x341/0x1290 do_filp_open+0x42/0xa0 compat_sys_ioctl+0xc1/0xf20 do_sys_open+0x16e/0x1d0 sysenter_dispatch+0x7/0x1a To prevent use-after-free we need to grab the device in loop_set_fd() and put it later in loop_clr_fd(). The issue is reprodusible on current Linus head and v3.3. Here is the test: dd if=/dev/zero of=loop.file bs=1M count=1 while [ true ]; do losetup /dev/loop0 loop.file echo 2 > /proc/sys/vm/drop_caches losetup -d /dev/loop0 done [ Doing bdgrab/bput in loop_set_fd/loop_clr_fd is safe, because every time we call loop_set_fd() we check that loop_device->lo_state is Lo_unbound and set it to Lo_bound If somebody will try to set_fd again it will get EBUSY. And if we try to loop_clr_fd() on unbound loop device we'll get ENXIO. loop_set_fd/loop_clr_fd (and any other loop ioctl) is called under loop_device->lo_ctl_mutex. ] Signed-off-by: Anatol Pomozov <anatol.pomozov@gmail.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-04-01Merge tag 'clk-fixes-for-linus' of git://git.linaro.org/people/mturquette/linuxLinus Torvalds
Pull tegra clock driver fix from Mike Turquette: "Missing base address in Tegra clock driver results in non-operational PCIe. On some devices this means that Ethernet will go uninitialized and other devices will fail. This pull request fixes it with a single patch to pass the proper base address in the Tegra clock driver." * tag 'clk-fixes-for-linus' of git://git.linaro.org/people/mturquette/linux: clk: tegra: Allow PLLE training to succeed
2013-04-01Merge tag 'for-3.9-rc' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rwlove/fcoe Pull FCoE fixes from Robert Love: "Critical patches to fix FCoE VN2VN mode with new interfaces targeting 3.9-rc" * tag 'for-3.9-rc' of git://git.kernel.org/pub/scm/linux/kernel/git/rwlove/fcoe: libfcoe: Fix fcoe_sysfs VN2VN mode libfc, fcoe, bnx2fc: Split fc_disc_init into fc_disc_{init, config} libfc, fcoe, bnx2fc: Always use fcoe_disc_init for discovery layer initialization fcoe: Fix deadlock between create and destroy paths bnx2fc: Make the fcoe_cltr the SCSI host parent
2013-04-01radeon: Attempt to use platform-provided ROM imageMatthew Garrett
Some platforms only provide their PCI ROM via a platform-specific interface. Fall back to attempting that if all other sources fail. Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-04-01nouveau: Attempt to use platform-provided ROM imageMatthew Garrett
Some platforms only provide their PCI ROM via a platform-specific interface. Fall back to attempting that if all other sources fail. Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>