summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2015-05-05drm/i915: Add missing MacBook Pro models with dual channel LVDSLukas Wunner
Single channel LVDS maxes out at 112 MHz. The 15" pre-retina models shipped with 1440x900 (106 MHz) by default or 1680x1050 (119 MHz) as a BTO option, both versions used dual channel LVDS even though the smaller one would have fit into a single channel. Notes: Bug report showing that the MacBookPro8,2 with 1440x900 uses dual channel LVDS (this lead to it being hardcoded in intel_lvds.c by Daniel Vetter with commit 618563e3945b9d0864154bab3c607865b557cecc): https://bugzilla.kernel.org/show_bug.cgi?id=42842 If i915.lvds_channel_mode=2 is missing even though the machine needs it, every other vertical line is white and consequently, only the left half of the screen is visible (verified by myself on a MacBookPro9,1). Forum posting concerning a MacBookPro6,2 with 1440x900, author is using i915.lvds_channel_mode=2 on the kernel command line, proving that the machine uses dual channels: https://bbs.archlinux.org/viewtopic.php?id=185770 Chi Mei N154C6-L04 with 1440x900 is a replacement panel for all MacBook Pro "A1286" models, and that model number encompasses the MacBookPro6,2 / 8,2 / 9,1. Page 17 of the panel's datasheet shows it's driven with dual channel LVDS: http://www.ebay.com/itm/-/400690878560 http://www.everymac.com/ultimate-mac-lookup/?search_keywords=A1286 http://www.taopanel.com/chimei/datasheet/N154C6-L04.pdf Those three 15" models, MacBookPro6,2 / 8,2 / 9,1, are the only ones with i915 graphics and dual channel LVDS, so that list should be complete. And the 8,2 is already in intel_lvds.c. Possible motivation to use dual channel LVDS even on the 1440x900 models: Reduce the number of different parts, i.e. use identical logic boards and display cabling on both versions and the only differing component is the panel. Signed-off-by: Lukas Wunner <lukas@wunner.de> Acked-by: Jani Nikula <jani.nikula@intel.com> Cc: stable@vger.kernel.org [Jani: included notes in the commit message for posterity] Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-05-05drm/i915: Assume dual channel LVDS if pixel clock necessitates itLukas Wunner
Single channel LVDS maxes out at 112 MHz, anything above must be dual channel. This avoids the need to specify i915.lvds_channel_mode=2 on all 17" MacBook Pro models with i915 graphics since they had 1920x1200 (193 MHz), plus those 15" pre-retina models which had a resolution of 1680x1050 (119 MHz) as a BTO option. Source for 112 MHz limit of single channel LVDS is section 2.3 of: https://01.org/linuxgraphics/sites/default/files/documentation/ivb_ihd_os_vol3_part4.pdf v2: Avoid hardcoding 17" models by assuming dual channel LVDS if the resolution necessitates it, suggested by Jani Nikula. v3: Fix typo, thanks Joonas Lahtinen. v4: Split commit in two, suggested by Ville Syrjälä. Signed-off-by: Lukas Wunner <lukas@wunner.de> Tested-by: Lukas Wunner <lukas@wunner.de> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: stable@vger.kernel.org [Jani: included spec reference into the commit message] Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-05-05ata: select DW_DMAC in case of SATA_DWCAndy Shevchenko
Since sata_dwc_460ex.c was moved to generic DMA driver we have to ensure that user can still compile it. Fixes: 8b3444852a2b (sata_dwc_460ex: move to generic DMA driver) Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2015-05-05drm/radeon: don't setup audio on asics that don't support itAlex Deucher
bug: https://bugzilla.kernel.org/show_bug.cgi?id=97701 Reported-by: Mikael Pettersson <mikpelinux@gmail.com> Tested-by: Mikael Pettersson <mikpelinux@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2015-05-05tick: hrtimer-broadcast: Prevent endless restarting when broadcast device is ↵Andreas Sandberg
unused The hrtimer callback in the hrtimer's tick broadcast code sometimes incorrectly ends up scheduling events at the current tick causing the kernel to hang servicing the same hrtimer forever. This typically happens when a device is swapped out by tick_install_broadcast_device(), which replaces the event handler with clock_events_handle_noop() and sets the device mode to CLOCK_EVT_MODE_UNUSED. If the timer is scheduled when this happens, the next_event field will not be updated and the hrtimer ends up being restarted at the current tick. To prevent this from happening, only try to restart the hrtimer if the broadcast clock event device is in one of the active modes and try to cancel the timer when entering the CLOCK_EVT_MODE_UNUSED mode. Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com> Tested-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Reviewed-by: Preeti U Murthy <preeti@linux.vnet.ibm.com> Link: http://lkml.kernel.org/r/1429880765-5558-1-git-send-email-andreas.sandberg@arm.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2015-05-05iommu/rockchip: Fix build without CONFIG_OFArnd Bergmann
The rockchip iommu driver references its of_device_id table from the init function, which fails to build when the table is undefined: iommu/rockchip-iommu.c: In function 'rk_iommu_init': iommu/rockchip-iommu.c:1029:35: error: 'rk_iommu_dt_ids' undeclared (first use in this function) np = of_find_matching_node(NULL, rk_iommu_dt_ids); This removes the #ifdef and the corresponding of_match_ptr wrapper to make it build both with CONFIG_OF enabled or disabled. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 425061b0f5074 ("iommu/rockchip: Play nice in multi-platform builds") Reviewed-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2015-05-05IB/qib: use arch_phys_wc_add()Luis R. Rodriguez
This driver already makes use of ioremap_wc() on PIO buffers, so convert it to use arch_phys_wc_add(). The qib driver uses a mmap() special case for when PAT is not used, this behaviour used to be determined with a module parameter but since we have been asked to just remove that module parameter this checks for the WC cookie, if not set we can assume PAT was used. If its set we do what we used to do for the mmap for when MTRR was enabled. The removal of the module parameter is OK given that Andy notes that even if users of module parameter are still around it will not prevent loading of the module on recent kernels. Cc: Doug Ledford <dledford@redhat.com> Cc: Toshi Kani <toshi.kani@hp.com> Cc: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se> Cc: Mike Marciniszyn <mike.marciniszyn@intel.com> Cc: Roland Dreier <roland@purestorage.com> Cc: Sean Hefty <sean.hefty@intel.com> Cc: Hal Rosenstock <hal.rosenstock@gmail.com> Cc: Dennis Dalessandro <dennis.dalessandro@intel.com> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Suresh Siddha <sbsiddha@gmail.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Juergen Gross <jgross@suse.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Dave Airlie <airlied@redhat.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Antonino Daplas <adaplas@gmail.com> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Stefan Bader <stefan.bader@canonical.com> Cc: konrad.wilk@oracle.com Cc: ville.syrjala@linux.intel.com Cc: david.vrabel@citrix.com Cc: jbeulich@suse.com Cc: Roger Pau Monné <roger.pau@citrix.com> Cc: infinipath@intel.com Cc: linux-rdma@vger.kernel.org Cc: linux-fbdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: xen-devel@lists.xensource.com Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com> Signed-off-by: Doug Ledford <dledford@redhat.com>
2015-05-05IB/qib: add acounting for MTRRLuis R. Rodriguez
There is no good reason not to, we eventually delete it as well. Cc: Toshi Kani <toshi.kani@hp.com> Cc: Suresh Siddha <sbsiddha@gmail.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Juergen Gross <jgross@suse.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Dave Airlie <airlied@redhat.com> Cc: Antonino Daplas <adaplas@gmail.com> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Mike Marciniszyn <infinipath@intel.com> Cc: Roland Dreier <roland@kernel.org> Cc: Sean Hefty <sean.hefty@intel.com> Cc: Hal Rosenstock <hal.rosenstock@gmail.com> Cc: linux-rdma@vger.kernel.org Cc: linux-fbdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com> Signed-off-by: Doug Ledford <dledford@redhat.com>
2015-05-05IB/core: dma unmap optimizationsGuy Shapiro
While unmapping an ODP writable page, the dirty bit of the page is set. In order to do so, the head of the compound page is found. Currently, the compound head is found even on non-writable pages, where it is never used, leading to unnecessary cpu barrier that impacts performance. This patch moves the search for the compound head to be done only when needed. Signed-off-by: Guy Shapiro <guysh@mellanox.com> Acked-by: Shachar Raindel <raindel@mellanox.com> Reviewed-by: Sagi Grimberg <sagig@mellanox.com> Signed-off-by: Doug Ledford <dledford@redhat.com>
2015-05-05IB/core: dma map/unmap locking optimizationsGuy Shapiro
Currently, while mapping or unmapping pages for ODP, the umem mutex is locked and unlocked once for each page. Such lock/unlock operation take few tens to hundreds of nsecs. This makes a significant impact when mapping or unmapping few MBs of memory. To avoid this, the mutex should be locked only once per operation, and not per page. Signed-off-by: Guy Shapiro <guysh@mellanox.com> Acked-by: Shachar Raindel <raindel@mellanox.com> Reviewed-by: Sagi Grimberg <sagig@mellanox.com> Signed-off-by: Doug Ledford <dledford@redhat.com>
2015-05-05RDMA/cxgb4: Report the actual address of the remote connecting peerSteve Wise
Get the actual (non-mapped) ip/tcp address of the connecting peer from the port mapper Also setup the passive side endpoint to correctly display the actual and mapped addresses for the new connection. Signed-off-by: Steve Wise <swise@opengridcomputing.com> Signed-off-by: Doug Ledford <dledford@redhat.com>
2015-05-05RDMA/nes: Report the actual address of the remote connecting peerTatyana Nikolova
Get the actual (non-mapped) ip/tcp address of the connecting peer from the port mapper and report the address info to the user space application at the time of connection establishment Signed-off-by: Tatyana Nikolova <tatyana.e.nikolova@intel.com> Signed-off-by: Doug Ledford <dledford@redhat.com>
2015-05-05RDMA/core: Enable the iWarp Port Mapper to provide the actual address of the ↵Tatyana Nikolova
connecting peer to its clients Add functionality to enable the port mapper on the passive side to provide to its clients the actual (non-mapped) ip/tcp address information of the connecting peer 1) Adding remote_info_cb() to process the address info of the connecting peer The address info is provided by the user space port mapper service when the connection is initiated by the peer 2) Adding a hash list to store the remote address info 3) Adding functionality to add/remove the remote address info After the info has been provided to the port mapper client, it is removed from the hash list Signed-off-by: Tatyana Nikolova <tatyana.e.nikolova@intel.com> Reviewed-by: Steve Wise <swise@opengridcomputing.com> Signed-off-by: Doug Ledford <dledford@redhat.com>
2015-05-05iw_cxgb4: enforce qp/cq id requirementsHariprasad S
Currently the iw_cxgb4 implementation requires the qp and cq qid densities to match as well as the qp and cq id ranges. So fail a device open if the device configuration doesn't meet the requirements. The reason for these restictions has to do with the fact that IQ qid X has a UGTS register in the same bar2 page as EQ qid X. Thus both qids need to be allocated to the same user process for security reasons. The logic that does this (the qpid allocator in iw_cxgb4/resource.c) handles this but requires the above restrictions. Signed-off-by: Steve Wise <swise@opengridcomputing.com> Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com> Signed-off-by: Doug Ledford <dledford@redhat.com>
2015-05-05iw_cxgb4: use BAR2 GTS register for T5 kernel mode CQsHariprasad S
For T5, we must not use the kdb/kgts registers, in order avoid db drops under extreme loads. Signed-off-by: Steve Wise <swise@opengridcomputing.com> Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com> Signed-off-by: Doug Ledford <dledford@redhat.com>
2015-05-05iw_cxgb4: 32b platform fixesHariprasad S
- get_dma_mr() was using ~0UL which is should be ~0ULL. This causes the DMA MR to get setup incorrectly in hardware. - wr_log_show() needed a 64b divide function div64_u64() instead of doing division directly. - fixed warnings about recasting a pointer to a u64 Signed-off-by: Steve Wise <swise@opengridcomputing.com> Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com> Signed-off-by: Doug Ledford <dledford@redhat.com>
2015-05-05iw_cxgb4: Cleanup register defines/MACROSHariprasad S
Cleanup macros and register defines for consistency Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com> Signed-off-by: Doug Ledford <dledford@redhat.com>
2015-05-05RDMA/CMA: Canonize IPv4 on IPV6 sockets properlyJason Gunthorpe
When accepting a new IPv4 connect to an IPv6 socket, the CMA tries to canonize the address family to IPv4, but does not properly process the listening sockaddr to get the listening port, and does not properly set the address family of the canonized sockaddr. Fixes: e51060f08a61 ("IB: IP address based RDMA connection manager") Cc: <stable@vger.kernel.org> Reported-By: Yotam Kenneth <yotamke@mellanox.com> Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Tested-by: Haggai Eran <haggaie@mellanox.com> Signed-off-by: Doug Ledford <dledford@redhat.com>
2015-05-05arm64: mm: Fix build error with CONFIG_SPARSEMEM_VMEMMAP disabledJungseung Lee
This fix the below build error: arch/arm64/mm/dump.c: In function ‘ptdump_init’: arch/arm64/mm/dump.c:331:18: error: ‘VMEMMAP_START_NR’ undeclared (first use in this function) address_markers[VMEMMAP_START_NR].start_address = ^ arch/arm64/mm/dump.c:331:18: note: each undeclared identifier is reported only once for each function it appears in arch/arm64/mm/dump.c:333:18: error: ‘VMEMMAP_END_NR’ undeclared (first use in this function) address_markers[VMEMMAP_END_NR].start_address = ^ Acked-by: Laura Abbott <labbott@redhat.com> Signed-off-by: Jungseung Lee <js07.lee@gmail.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2015-05-05Revert "arm64: alternative: Allow immediate branch as alternative instruction"Will Deacon
This reverts most of commit fef7f2b2010381c795ae43743ad31931cc58f5ad. It turns out that there are a couple of problems with the way we're fixing up branch instructions used as part of alternative instruction sequences: (1) If the branch target is also in the alternative sequence, we'll generate a branch into the .altinstructions section which actually gets freed. (2) The calls to aarch64_insn_{read,write} bring an awful lot more code into the patching path (e.g. taking locks, poking the fixmap, invalidating the TLB) which isn't actually needed for the early patching run under stop_machine, but makes the use of alternative sequences extremely fragile (as we can't patch code that could be used by the patching code). Given that no code actually requires alternative patching of immediate branches, let's remove this support for now and revisit it when we've got a user. We leave the updated size check, since we really do require the sequences to be the same length. Acked-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2015-05-05x86/spinlocks: Fix regression in spinlock contention detectionTahsin Erdogan
A spinlock is regarded as contended when there is at least one waiter. Currently, the code that checks whether there are any waiters rely on tail value being greater than head. However, this is not true if tail reaches the max value and wraps back to zero, so arch_spin_is_contended() incorrectly returns 0 (not contended) when tail is smaller than head. The original code (before regression) handled this case by casting the (tail - head) to an unsigned value. This change simply restores that behavior. Fixes: d6abfdb20223 ("x86/spinlocks/paravirt: Fix memory corruption on unlock") Signed-off-by: Tahsin Erdogan <tahsin@google.com> Cc: peterz@infradead.org Cc: Waiman.Long@hp.com Cc: borntraeger@de.ibm.com Cc: oleg@redhat.com Cc: raghavendra.kt@linux.vnet.ibm.com Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/1430799331-20445-1-git-send-email-tahsin@google.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2015-05-05timer: Use timer->base for flag checksJoonwoo Park
At present, internal_add_timer() examines flags with 'base' which doesn't contain flags. Examine with 'timer->base' to avoid unnecessary waking up of nohz CPU when timer base has TIMER_DEFERRABLE set. Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org> Cc: sboyd@codeaurora.org Cc: skannan@codeaurora.org Cc: John Stultz <john.stultz@linaro.org> Link: http://lkml.kernel.org/r/1430187709-21087-1-git-send-email-joonwoop@codeaurora.org Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2015-05-05clocksource: sun5i: Fix of_io_request_and_map error checkMaxime Ripard
of_io_request_and map returns an error pointer, but the current code assumes that on error the returned pointer will be NULL. Obviously, that makes the check completely useless. Change the test to actually check for the proper error code. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Link: http://lkml.kernel.org/r/1430579006-32702-6-git-send-email-maxime.ripard@free-electrons.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2015-05-05clocksource: integrator: Fix of_io_request_and_map error checkMaxime Ripard
of_io_request_and map returns an error pointer, but the current code assumes that on error the returned pointer will be NULL. Obviously, that makes the check completely useless. Change the test to actually check for the proper error code. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Link: http://lkml.kernel.org/r/1430579006-32702-5-git-send-email-maxime.ripard@free-electrons.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2015-05-05clocksource: asm9260: Fix of_io_request_and_map error checkMaxime Ripard
of_io_request_and map returns an error pointer, but the current code assumes that on error the returned pointer will be NULL. Obviously, that makes the check completely useless. Change the test to actually check for the proper error code. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Link: http://lkml.kernel.org/r/1430579006-32702-4-git-send-email-maxime.ripard@free-electrons.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2015-05-05tick-broadcast: Fix the printing of broadcast masksPreeti U Murthy
Today the number of bits of the broadcast masks that is output into /proc/timer_list is sizeof(unsigned long). This means that on machines with a larger number of CPUs, the bitmasks of CPUs beyond this range do not appear. Fix this by using bitmap printing through "%*pb" instead, so as to output the broadcast masks for the range of nr_cpu_ids into /proc/timer_list. Signed-off-by: Preeti U Murthy <preeti@linux.vnet.ibm.com> Cc: peterz@infradead.org Cc: linuxppc-dev@ozlabs.org Cc: john.stultz@linaro.org Link: http://lkml.kernel.org/r/20150428084520.3314.62668.stgit@preeti.in.ibm.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2015-05-05tick: broadcast: Simplify oneshot logic and shorten lock regionThomas Gleixner
Simplify the oneshot logic by avoiding the reprogramming loops. That also allows to call the cpu local handler outside of the broadcast_lock held region. Tested-by: Borislav Petkov <bp@alien8.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2015-05-05tick: broadcast: Prevent livelock from event handlerThomas Gleixner
With the removal of the hrtimer softirq the switch to highres/nohz mode happens in the tick interrupt. That leads to a livelock when the per cpu event handler is directly called from the broadcast handler under broadcast lock because broadcast lock needs to be taken for the highres/nohz switch as well. Solve this by calling the cpu local handler outside the broadcast_lock held region. Fixes: c6eb3f70d448 "hrtimer: Get rid of hrtimer softirq" Reported-and-tested-by: Borislav Petkov <bp@alien8.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2015-05-04f2fs: fix wrong error hanlder in f2fs_follow_linkJaegeuk Kim
The page_follow_link_light returns NULL and its error pointer was remained in nd->path. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Chao Yu <chao2.yu@samsung.com> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2015-05-04Revert "f2fs: enhance multi-threads performance"Jaegeuk Kim
This reports performance regression by Yuanhan Liu. The basic idea was to reduce one-point mutex, but it turns out this causes another contention like context swithes. https://lkml.org/lkml/2015/4/21/11 Until finishing the analysis on this issue, I'd like to revert this for a while. This reverts commit 78373b7319abdf15050af5b1632c4c8b8b398f33.
2015-05-04blk-mq: don't lose requests if a stopped queue restartsShaohua Li
Normally if driver is busy to dispatch a request the logic is like below: block layer: driver: __blk_mq_run_hw_queue a. blk_mq_stop_hw_queue b. rq add to ctx->dispatch later: 1. blk_mq_start_hw_queue 2. __blk_mq_run_hw_queue But it's possible step 1-2 runs between a and b. And since rq isn't in ctx->dispatch yet, step 2 will not run rq. The rq might get lost if there are no subsequent requests kick in. Signed-off-by: Shaohua Li <shli@fb.com> Signed-off-by: Jens Axboe <axboe@fb.com>
2015-05-04Merge tag 'mac80211-for-davem-2015-05-04' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211 Johannes Berg says: ==================== We have only a few fixes right now: * a fix for an issue with hash collision handling in the rhashtable conversion * a merge issue - rhashtable removed default shrinking just before mac80211 was converted, so enable it now * remove an invalid WARN that can trigger with legitimate userspace behaviour * add a struct member missing from kernel-doc that caused a lot of warnings ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2015-05-04bnx2x: Fix to prevent inner-reloadYuval Mintz
Submit 909d9faae2a44 ("bnx2x: Prevent inner-reload while VFs exist") contained a bug - MTU change was not prevented by it; Instead, it `randomally' prevented bnx2x_resume() from running [harmless yet wrong]. This moves the check to its correct spot. Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-05-04Merge branch 'for-upstream' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next Johan Hedberg says: ==================== pull request: bluetooth-next 2015-05-04 Here's the first bluetooth-next pull request for 4.2: - Various fixes for at86rf230 driver - ieee802154: trace events support for rdev->ops - HCI UART driver refactoring - New Realtek IDs added to btusb driver - Off-by-one fix for rtl8723b in btusb driver - Refactoring of btbcm driver for both UART & USB use Please let me know if there are any issues pulling. Thanks. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2015-05-04net/rds: Fix new sparse warningDavid Ahern
c0adf54a109 introduced new sparse warnings: CHECK /home/dahern/kernels/linux.git/net/rds/ib_cm.c net/rds/ib_cm.c:191:34: warning: incorrect type in initializer (different base types) net/rds/ib_cm.c:191:34: expected unsigned long long [unsigned] [usertype] dp_ack_seq net/rds/ib_cm.c:191:34: got restricted __be64 <noident> net/rds/ib_cm.c:194:51: warning: cast to restricted __be64 The temporary variable for sequence number should have been declared as __be64 rather than u64. Make it so. Signed-off-by: David Ahern <david.ahern@oracle.com> Cc: shamir rabinovitch <shamir.rabinovitch@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-05-04Revert "Revert "smc91x: retrieve IRQ and trigger flags in a modern way""David S. Miller
This reverts commit 8d7d9cca4390062ccd09ffd9fdb37d1c4eeea9ac. Now that the necessary infrastructure is really all there in the tree, we can put this change back in. Signed-off-by: David S. Miller <davem@davemloft.net>
2015-05-04net/smsc911x: fix irq resource allocation failureKamlakant Patel
When smsc911x uses GPIO as the interrupt controller, and if both are loaded as modules, we get following error: "smsc911x: Could not allocate irq resource" This issue is because of smsc911x using platform_get_resource to get device tree based irq resource. commit "9ec36ca (of/irq: do irq resolution in platform_get_irq)" and commit "7085a7 (drivers: platform: parse IRQ flags from resources)" add support in platform_get_irq to resolve irq and irq_flags respectively for both modern device tree and legacy static platform data platforms. Modify smsc911x driver to use platform_get_irq to pick up irq resource correctly and use irq_get_trigger_type to get the IRQ trigger flags. Signed-off-by: Kamlakant Patel <kamlakant.patel@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-05-04blk-mq: fix FUA request hangShaohua Li
When a FUA request enters its DATA stage of flush pipeline, the request is added to mq requeue list, the request will then be added to ctx->rq_list. blk_mq_attempt_merge() might merge the request with a bio. Later when the request is finished the flush pipeline, the request->__data_len is 0. Then I only saw the bio gets endio called, the original request never finish. Adding REQ_FLUSH_SEQ into REQ_NOMERGE_FLAGS looks an easy fix. stable: 3.15+ Signed-off-by: Shaohua Li <shli@fb.com> Signed-off-by: Jens Axboe <axboe@fb.com>
2015-05-04drm/radeon: disable semaphores for UVD V1 (v2)Christian König
Hardware doesn't seem to work correctly, just block userspace in this case. v2: add missing defines Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=85320 Signed-off-by: Christian König <christian.koenig@amd.com> CC: stable@vger.kernel.org Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-05-04net: core: Correct an over-stringent device loop detection.Vlad Yasevich
The code in __netdev_upper_dev_link() has an over-stringent loop detection logic that actually prevents valid configurations from working correctly. In particular, the logic returns an error if an upper device is already in the list of all upper devices for a given dev. This particular check seems to be a overzealous as it disallows perfectly valid configurations. For example: # ip l a link eth0 name eth0.10 type vlan id 10 # ip l a dev br0 typ bridge # ip l s eth0.10 master br0 # ip l s eth0 master br0 <--- Will fail If you switch the last two commands (add eth0 first), then both will succeed. If after that, you remove eth0 and try to re-add it, it will fail! It appears to be enough to simply check adj_list to keeps things safe. I've tried stacking multiple devices multiple times in all different combinations, and either rx_handler registration prevented the stacking of the device linking cought the error. Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com> Acked-by: Jiri Pirko <jiri@resnulli.us> Acked-by: Veaceslav Falico <vfalico@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-05-04isdn/gigaset: cede maintainershipTilman Schmidt
As German phone operators are discontinuing ISDN service, neither Hansjörg nor I will be able to maintain the Gigaset ISDN drivers any longer. Paul Bolle offered to step into the breach for odd fixes. Signed-off-by: Tilman Schmidt <tilman@imap.cc> Acked-by: Paul Bolle <pebolle@tiscali.nl> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-05-04bus: omap_l3_noc: Fix master id address decoding for OMAP5Suman Anna
The L3 Error handling on OMAP5 for the most part is very similar to that of OMAP4, and had leveraged common data structures and register layout definitions so far. Upon closer inspection, there are a few minor differences causing an incorrect decoding and reporting of the master NIU upon an error: 1. The L3_TARG_STDERRLOG_MSTADDR.STDERRLOG_MSTADDR occupies 11 bits on OMAP5 as against 8 bits on OMAP4, with the master NIU connID encoded in the 6 MSBs of the STDERRLOG_MSTADDR field. 2. The CLK3 FlagMux component has 1 input source on OMAP4 and 3 input sources on OMAP5. The common DEBUGSS source is at a different input on each SoC. Fix the above issues by using a OMAP5-specific compatible property and using SoC-specific data where there are differences. Signed-off-by: Suman Anna <s-anna@ti.com> Acked-by: Nishanth Menon <nm@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2015-05-04bus: omap_l3_noc: Fix offset for DRA7 CLK1_HOST_CLK1_2 instanceIllia Smyrnov
The base address for DRA7 CLK1_HOST_CLK1_2 host instance is 0x44800000, so correct offset is 0x800000. DRA7 TRM rev X(fewb 2015) has updates for this information. With wrong offset these errors are not correctly cleared by the L3 IRQ handler and cause an continuous interrupt scenario and system lockup. Signed-off-by: Illia Smyrnov <illia.smyrnov@globallogic.com> Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2015-05-04libata: Blacklist queued TRIM on all Samsung 800-seriesMartin K. Petersen
The queued TRIM problems appear to be generic to Samsung's firmware and not tied to a particular model. A recent update to the 840 EVO firmware introduced the same issue as we saw on 850 Pro. Blacklist queued TRIM on all 800-series drives while we work this issue with Samsung. Reported-by: Günter Waller <g.wal@web.de> Reported-by: Sven Köhler <sven.koehler@gmail.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Cc: stable@vger.kernel.org Signed-off-by: Tejun Heo <tj@kernel.org>
2015-05-04ARM: dts: dra7: Fix efuse register size for ABBNishanth Menon
Fix a typo in DRA7 dtsi where 12 bytes are needed for register description of ABB efuse registers, however only 8 bytes are provided to map. For some weird reason, this does not generate abort at offset 0x8, probably due to default maps already provided in io.c for the bus register ranges. Reported-by: Matt Gessner <Matt.Gessner@windriver.com> Reported-by: Suman Anna <s-anna@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2015-05-04ARM: dts: am57xx-beagle-x15: Switch GPIO fan numberNishanth Menon
BeagleBoard-X15 pre-production change includes switching the GPIO fan gpio over from 1 to 2 to allow for a potential fix at a later point in time for USB client VBUS detection using PMIC VBUS detect capability. Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2015-05-04ARM: dts: am57xx-beagle-x15: Switch UART mux pinsNishanth Menon
BeagleBoard-X15 pre-production change includes switching over to UART pins that now allow for UART download capability. All original boards should either have been returned for modifications or already modified for the required change and maintaining compatibility for older boards are no longer needed. Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2015-05-04ARM: dts: am437x-sk: reduce col-scan-delay-usFelipe Balbi
The new AM437x SK Beta boards have removed the large capacitors on the gpio-matrix column lines which means we can reduce col-scan-delay-us to 5us without loosing functionality. Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2015-05-04ARM: dts: am437x-sk: fix for new newhaven display module revisionFelipe Balbi
AM437x Starter Kit uses a NewHaven Display module with a 4.3" display and EDT FT5306 touchscreen On that module's new revision, NewHave decided to change the pinout on the 6 pin flat-pcb touchscreen connector so that instead of having WAKE pin, we now have RESETn. The new display module is available on AM437x SK Beta and all new revisions while the older revision is only available on AM437x SK Alpha which, unfortunately, can't be supported anymore in mainline without a revert of this patch. Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2015-05-04ARM: dts: am57xx-beagle-x15: Fix RTC aliasesNishanth Menon
With commit bc078316d86c ("ARM: dts: DRA7: Add node for RTC"), we now have AM57xx RTC register itself as alias 0 even before DS1307 or TPS rtc drivers are loaded up. However, since neither TPS, nor AM57xx RTC are capable of being backedup by battery, we would like to maintain the "primary" rtc as mcp79410 rtc device. This also generates the following warnings in the bootlog highlighting the issue: [ 5.895445] rtc-ds1307 2-006f: /aliases ID 0 not available ... [ 6.476285] palmas-rtc 48070000.i2c:tps659038@58:tps659038_rtc: /aliases ID 1 not available So, add proper aliases to ensure that RTC order is always consistent to userspace immaterial of probe order. Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
generated by cgit (git 2.34.1) at 2025-09-12 19:21:27 +0000