summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2016-01-29drm/i915: refine qemu south bridge detectionGerd Hoffmann
The test for the qemu q35 south bridge added by commit "39bfcd52 drm/i915: more virtual south bridge detection" also matches on real hardware. Having the check for virtual systems last in the list is not enough to avoid that ... Refine the check by additionally verifying the pci subsystem id to see whenever it *really* is qemu. [ v2: fix subvendor tyops ] Reported-and-tested-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Tested-by: Bruno Wolff III <bruno@wolff.to> Cc: drm-intel-fixes@lists.freedesktop.org Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1453719748-10944-1-git-send-email-kraxel@redhat.com (cherry picked from commit 1e859111c128265f8d62b39ff322e42b1ddb5a20)
2016-01-29drm/i915: Remove select to deleted STOP_MACHINE from KconfigAndreas Ziegler
Commit 5bab6f60cb4d ("drm/i915: Serialise updates to GGTT with access through GGTT on Braswell") depended upon a working stop_machine() and so forced the selection of STOP_MACHINE. However, commit 86fffe4a61dd ("kernel: remove stop_machine() Kconfig dependency") removed the option STOP_MACHINE from init/Kconfig and ensured that stop_machine() universally works. Due to the order in which the patches were applied, removing the select from DRM_I915 got lost during merging. Remove the now obsolete select statement. Signed-off-by: Andreas Ziegler <andreas.ziegler@fau.de> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1453722079-2604-1-git-send-email-andreas.ziegler@fau.de Cc: drm-intel-fixes@lists.freedesktop.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> (cherry picked from commit 21fabbebff0e17c7698ed399cae23958c214cc82) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-01-29drm/i915: Fix NULL plane->fb oops on SKLVille Syrjälä
In this atomic age, we can't trust the plane->fb pointer anymore. It might get update too late. Instead we are supposed to use the plane_state->fb pointer instead. Let's do that in intel_plane_obj_offset() and avoid problems from dereferencing the potentially stale plane->fb pointer. Paulo found this with 'kms_frontbuffer_tracking --show-hidden --run-subtest nop-1p-rte' but it can be reproduced with just plain old kms_setplane. I was too lazy to bisect this, so not sure exactly when it broke. The most obvious candidate commit ce7f17285639 ("drm/i915: Fix i915_ggtt_view_equal to handle rotation correctly") was actually still fine, so it must have broken some time after that. Here's the resulting fireworks: BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffffa02d2d9a>] intel_fill_fb_ggtt_view+0x1b/0x15a [i915] PGD 8a5f6067 PUD 8a5f5067 PMD 0 Oops: 0000 [#1] PREEMPT SMP Modules linked in: i915 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm intel_gtt agpgart netconsole mousedev hid_generic psmouse usbhid atkbd libps2 coretemp hwmon efi_pstore intel_rapl iosf_mbi x86_pkg_temp_thermal efivars pcspkr e1000e sdhci_pci ptp pps_core sdhci i2c_i801 mmc_core i2c_hid hid i8042 serio evdev sch_fq_codel ip_tables x_tables ipv6 autofs4 CPU: 1 PID: 260 Comm: kms_plane Not tainted 4.4.0-skl+ #171 Hardware name: Intel Corporation Skylake Client platform/Skylake Y LPDDR3 RVP3, BIOS SKLSE2R1.R00.B104.B00.1511030553 11/03/2015 task: ffff88008bde2d80 ti: ffff88008a6ec000 task.ti: ffff88008a6ec000 RIP: 0010:[<ffffffffa02d2d9a>] [<ffffffffa02d2d9a>] intel_fill_fb_ggtt_view+0x1b/0x15a [i915] RSP: 0018:ffff88008a6efa10 EFLAGS: 00010086 RAX: 0000000000000001 RBX: ffff8801674f4240 RCX: 0000000000000014 RDX: ffff88008a7440c0 RSI: 0000000000000000 RDI: ffff88008a6efa40 RBP: ffff88008a6efa30 R08: ffff88008bde3598 R09: 0000000000000001 R10: ffff88008b782000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff88008a7440c0 R14: 0000000000000000 R15: ffff88008a7449c0 FS: 00007fa0c07a28c0(0000) GS:ffff88016ec40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000008a6ff000 CR4: 00000000003406e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Stack: ffff8801674f4240 0000000000000000 ffff88008a7440c0 0000000000000000 ffff88008a6efaa0 ffffffffa02daf25 ffffffff814ec80e 0000000000070298 ffff8800850d0000 ffff88008a6efaa0 ffffffffa02c49c2 0000000000000002 Call Trace: [<ffffffffa02daf25>] intel_plane_obj_offset+0x2d/0xa9 [i915] [<ffffffff814ec80e>] ? _raw_spin_unlock_irqrestore+0x4b/0x60 [<ffffffffa02c49c2>] ? gen9_write32+0x2e8/0x3b8 [i915] [<ffffffffa02eecfc>] skl_update_plane+0x203/0x4c5 [i915] [<ffffffffa02ca1ab>] intel_plane_atomic_update+0x53/0x6a [i915] [<ffffffffa02494a4>] drm_atomic_helper_commit_planes_on_crtc+0x142/0x1d5 [drm_kms_helper] [<ffffffffa02de44b>] intel_atomic_commit+0x1262/0x1350 [i915] [<ffffffffa024a0ee>] ? __drm_atomic_helper_crtc_duplicate_state+0x2f/0x41 [drm_kms_helper] [<ffffffffa01ef089>] ? drm_atomic_check_only+0x3e3/0x552 [drm] [<ffffffffa01ef245>] drm_atomic_commit+0x4d/0x52 [drm] [<ffffffffa024996b>] drm_atomic_helper_update_plane+0xcb/0x118 [drm_kms_helper] [<ffffffffa01e42e8>] __setplane_internal+0x1c8/0x224 [drm] [<ffffffffa01e477f>] drm_mode_setplane+0x14e/0x172 [drm] [<ffffffffa01d8117>] drm_ioctl+0x265/0x3ad [drm] [<ffffffffa01e4631>] ? drm_mode_cursor_common+0x158/0x158 [drm] [<ffffffff810d00ab>] ? current_kernel_time64+0x5e/0x98 [<ffffffff810a76ea>] ? trace_hardirqs_on_caller+0x17a/0x196 [<ffffffff8119880f>] do_vfs_ioctl+0x42b/0x4ea [<ffffffff811a2b72>] ? __fget_light+0x4d/0x71 [<ffffffff81198911>] SyS_ioctl+0x43/0x61 [<ffffffff814ed057>] entry_SYSCALL_64_fastpath+0x12/0x6f Cc: drm-intel-fixes@lists.freedesktop.org Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Testcase: igt/kms_plane Reported-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1453220597-28973-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> (cherry picked from commit e794129444aba459e9bedf5080bfb4605f933c32) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-01-29drm/i915: Don't reject primary plane windowing with color keying enabled on SKL+Ville Syrjälä
On SKL+ plane scaling is mutually exclusive with color keying. The code check for this, but during some refactoring the code got changed to also reject primary plane windowing when color keying is used. There is no such restriction in the hardware, so restore the original logic. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: 061e4b8d650a ("drm/i915: clean up atomic plane check functions, v2.") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1452883613-28549-1-git-send-email-ville.syrjala@linux.intel.com Cc: stable@vger.kernel.org Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> (cherry picked from commit 693bdc28a733dba68b86af295e7509812fec35d9) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-01-29drm/i915/dp: fall back to 18 bpp when sink capability is unknownJani Nikula
Per DP spec, the source device should fall back to 18 bpp, VESA range RGB when the sink capability is unknown. Fix the color depth clamping. 18 bpp color depth should ensure full color range in automatic mode. The clamping has been HDMI specific since its introduction in commit 996a2239f93b03c5972923f04b097f65565c5bed Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Apr 19 11:24:34 2013 +0200 drm/i915: Disable high-bpc on pre-1.4 EDID screens Cc: stable@vger.kernel.org Reported-and-tested-by: Dihan Wickremasuriya <nayomal@gmail.com> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=105331 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1452695720-7076-1-git-send-email-jani.nikula@intel.com (cherry picked from commit 013dd9e038723bbd2aa67be51847384b75be8253)
2016-01-29drm/i915: Make sure DC writes are coherent on flush.Francisco Jerez
We need to set the DC FLUSH PIPE_CONTROL bit on Gen7+ to guarantee that writes performed via the HDC are visible in memory. Fixes an intermittent failure in a Piglit test that writes to a BO from a shader using GL atomic counters (implemented as HDC untyped atomics) and then expects the memory to read back the same value after mapping it on the CPU. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91298 Tested-by: Mark Janes <mark.a.janes@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Francisco Jerez <currojerez@riseup.net> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1452740379-3194-1-git-send-email-currojerez@riseup.net (cherry picked from commit 965fd602a6436f689f4f2fe40a6789582778ccd5) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-01-28Staging: speakup: fix read scrolled-back VTSamuel Thibault
Previously, speakup would always read the non-scrolled part of the VT, even when the VT is scrolled back with shift-page. This patch makes vt.c export screen_pos so that speakup can use it to properly access the content of the scrolled-back VT. This was tested with both vgacon and fbcon. Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Reviewed-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-01-28Staging: speakup: Fix getting port informationSamuel Thibault
Commit f79b0d9c223c ("staging: speakup: Fixed warning <linux/serial.h> instead of <asm/serial.h>") broke the port information in the speakup driver: SERIAL_PORT_DFNS only gets defined if asm/serial.h is included, and no other header includes asm/serial.h. We here make sure serialio.c does get the arch-specific definition of SERIAL_PORT_DFNS from asm/serial.h, if any. Along the way, this makes sure that we do have information for the requested serial port number (index) Fixes: f79b0d9c223c ("staging: speakup: Fixed warning <linux/serial.h> instead of <asm/serial.h>") Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Cc: stable <stable@vger.kernel.org> # 3.18 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-01-28of: of_mdio: Add a whitelist of PHY compatibilities.Andrew Lunn
Some phy nodes list a compatible value indicating the PHY make/model. This is never used to match the device to the driver. However it does confuse the code to separate a PHY from a generic MDIO device like a switch. Generic MDIO devices must have a compatible value, PHYs can list clause 22 or 45, but nothing else. Issue a warning if we find a compatible value known on the whitelist, and say it is a PHY. Fixes: a9049e0c513c ("mdio: Add support for mdio drivers.") Reported-by: Aaro Koskinen <aaro.koskinen@nokia.com> Reported-by: Olof Johansson <olof@lixom.net> Tested-by: Aaro Koskinen <aaro.koskinen@nokia.com> Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-01-28lan78xx: throttle TX path at slower than SuperSpeed USBWoojung.Huh@microchip.com
Throttle TX path only at slower than SuperSpeed USB. SuperSpeed USB has enough bandwidth to maintain GigE. Signed-off-by: Woojung Huh <woojung.huh@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-01-28lan78xx: Add to handle mux control per chip idWoojung.Huh@microchip.com
Depends on chip, some EEPROM pins are muxed with LED function. Disable & restore LED function to access EEPROM. Signed-off-by: Woojung Huh <woojung.huh@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-01-28lan78xx: change to use updated phy-ignore-interruptsWoojung.Huh@microchip.com
Update lan78xx to use patch of commit 4f2aaf7dd95b ("Merge branch 'fix-phy-ignore-interrupts'"). Signed-off-by: Woojung Huh <woojung.huh@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-01-28Revert "Staging: panel: usleep_range is preferred over udelay"Sudip Mukherjee
This reverts commit ebd43516d3879f882a403836bba8bc5791f26a28. We should not be sleeping inside spin_lock. Fixes: ebd43516d387 ("Staging: panel: usleep_range is preferred over udelay") Cc: Sirnam Swetha <theonly.ultimate@gmail.com> Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org> Reported-by: Huang, Ying <ying.huang@intel.com> Tested-by: Huang, Ying <ying.huang@intel.com> Cc: stable <stable@vger.kernel.org> # 4.4 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-01-28switchdev: Require RTNL mutex to be held when sending FDB notificationsIdo Schimmel
When switchdev drivers process FDB notifications from the underlying device they resolve the netdev to which the entry points to and notify the bridge using the switchdev notifier. However, since the RTNL mutex is not held there is nothing preventing the netdev from disappearing in the middle, which will cause br_switchdev_event() to dereference a non-existing netdev. Make switchdev drivers hold the lock at the beginning of the notification processing session and release it once it ends, after notifying the bridge. Also, remove switchdev_mutex and fdb_lock, as they are no longer needed when RTNL mutex is held. Fixes: 03bf0c281234 ("switchdev: introduce switchdev notifier") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-01-28xen-netfront: request Tx response events more oftenMalcolm Crossley
Trying to batch Tx response events results in poor performance because this delays freeing the transmitted skbs. Instead use the standard RING_FINAL_CHECK_FOR_RESPONSES() macro to be notified once the next Tx response is placed on the ring. Signed-off-by: Malcolm Crossley <malcolm.crossley@citrix.com> Signed-off-by: David Vrabel <david.vrabel@citrix.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-01-28net: mv643xx_eth: fix packet corruption with TSO and tiny unaligned packets.Nicolas Schichan
The code in txq_put_data() would use txq->tx_curr_desc to index the tso_hdrs/tso_hdrs_dma buffers, for less than 8 bytes unaligned fragments, which is already moved to the next descriptor at the beginning of the function. If that fragment was the last of the the skb, the next skb would use that same space to place the ip headers, overwritting that small fragment data. Fixes: 91986fd3d335 (net: mv643xx_eth: Ensure proper data alignment in TSO TX path) Signed-off-by: Nicolas Schichan <nschichan@freebox.fr> Reviewed-by: Philipp Kirchhofer <philipp@familie-kirchhofer.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-01-28of: of_mdio: Ensure mdio device is a PHYAndrew Lunn
of_phy_find_device() is used to find the phy device associated with a device node. It is expected the node is for a PHY device, but in fact it could of been probed as a generic MDIO device. Ensure the device is a PHY before returning it. Fixes: a9049e0c513c ("mdio: Add support for mdio drivers.") Reported-by: Aaro Koskinen <aaro.koskinen@nokia.com> Reported-by: Olof Johansson <olof@lixom.net> Signed-off-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Aaro Koskinen <aaro.koskinen@nokia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-01-28Merge tag 'mac80211-for-davem-2016-01-26' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211 Johannes Berg says: ==================== Here's a first set of fixes for the 4.5-rc cycle: * make regulatory messages much less verbose by default * various remain-on-channel fixes * scheduled scanning fixes with hardware restart * a PS-Poll handling fix; was broken just recently * bugfix to avoid buffering non-bufferable MMPDUs * world regulatory domain data fix * a fix for scanning causing other work to get stuck * hwsim: revert an older problematic patch that caused some userspace tools to have issues - not that big a deal as it's a debug only driver though ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2016-01-29Merge branch 'drm-rockchip-next-fixes-2016-01-22' of ↵Dave Airlie
https://github.com/markyzq/kernel-drm-rockchip into drm-fixes Here are some fixes for drm/rockchip, these fixes base on drm-next. These fixes works on my popmetal(rk3288) board. About patch: drm/atomic-helper: Export framebuffer_changed() Daniel Vetter ack for merging it through rockchip git trees, so framebuffer_changed() can be reused by drm/rockchip. All others looks good, so I'd like you can land them. * 'drm-rockchip-next-fixes-2016-01-22' of https://github.com/markyzq/kernel-drm-rockchip: drm/rockchip: respect CONFIG_DRM_FBDEV_EMULATION drm/rockchip: fix wrong pitch/size using on gem drm/rockchip: explain why we can't wait_for_vblanks drm/rockchip: don't wait for vblank if fb hasn't changed drm/atomic-helper: Export framebuffer_changed() drm/rockchip/dsi: fix handling mipi_dsi_pixel_format_to_bpp result drm/rockchip: vop: fix mask when updating interrupts drm/rockchip: cleanup unnecessary export symbol drm/rockchip: Don't build rockchip_drm_vop as modules
2016-01-29drm/vmwgfx: respect 'nomodeset'Rob Clark
Signed-off-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>. Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
2016-01-28net: Fix dependencies for !HAS_IOMEM archsRichard Weinberger
Not every arch has io memory. So, unbreak the build by fixing the dependencies. Signed-off-by: Richard Weinberger <richard@nod.at> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-01-29Merge tag 'drm-vc4-fixes-2015-01-19' of http://github.com/anholt/linux into ↵Dave Airlie
drm-fixes This pull request just includes the !CONFIG_PM_SLEEP build fix for vc4. * tag 'drm-vc4-fixes-2015-01-19' of http://github.com/anholt/linux: drm/vc4: Remove broken attempt at GPU reset using genpd.
2016-01-29Merge branch 'drm-etnaviv-fixes' of git://git.pengutronix.de/git/lst/linux ↵Dave Airlie
into drm-fixes A bunch of etnaviv fixes for 4.5-rc. Most of them are fixing things in code paths that will only be hit if something goes wrong, which have been unearthed by more extensive testing. The only thing that doesn't really qualify as fixes is an UAPI extension that userspace wants to rely on being present, so I want to fast-track this into 4.5 before etnaviv ends up in a released kernel. * 'drm-etnaviv-fixes' of git://git.pengutronix.de/git/lst/linux: drm/etnaviv: call correct function when trying to vmap a DMABUF drm/etnaviv: rename etnaviv_gem_vaddr to etnaviv_gem_vmap drm/etnaviv: fix get pages error path in etnaviv_gem_vaddr drm/etnaviv: fix memory leak in IOMMU init path drm/etnaviv: add further minor features and varyings count drm/etnaviv: add helper for comparing model/revision IDs drm/etnaviv: add helper to extract bitfields drm/etnaviv: use defined constants for the chip model drm/etnaviv: update common and state_hi xml.h files drm/etnaviv: ignore VG GPUs with FE2.0 drm/etnaviv: fix failure path if model is zero drm/etnaviv: hold object lock while getting pages for coredump drm/etnaviv: remove owner assignment from platform_driver
2016-01-29Merge branch 'drm-fixes-4.5' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie
into drm-fixes Misc radeon and amdgpu fixes: - SMU firmware loading fix for Stoney - DP audio fixes for DCE4.1 - Don't expose fbdev device if no connectors - fix page table LRU list update handling * 'drm-fixes-4.5' of git://people.freedesktop.org/~agd5f/linux: drm/amdgpu: only move pt bos in LRU list on success drm/radeon: fix DP audio support for APU with DCE4.1 display engine drm/radeon: Add a common function for DFS handling drm/radeon: cleaned up VCO output settings for DP audio drm/amd/powerplay: Update SMU firmware loading for Stoney drm/amdgpu: don't init fbdev if we don't have any connectors drm/radeon: only init fbdev if we have connectors drm/radeon: Ensure radeon bo is unreserved in radeon_gem_va_ioctl drm/amdgpu: fix next_rptr handling for debugfs drm/radeon: properly byte swap vce firmware setup drm/amdgpu: add a message to indicate when powerplay is enabled (v2) drm/amdgpu: fix amdgpu_bo_pin_restricted VRAM placing v2 drm/amd/amdgpu: Improve amdgpu_dpm* macros to avoid unexpected result (v2) drm/amdgpu: Allow the driver to load if amdgpu.powerplay=1 on asics without powerplay support drm/amdgpu: Use drm_calloc_large for VM page_tables array drm/amdgpu: Add some tweaks to gfx 8 soft reset drm/amdgpu: fix tonga smu resume
2016-01-28mlxsw: reg: Use correct offset in field definitonIdo Schimmel
The rx_lane, tx_lane and module fields in the PMLP register don't have an additional offset besides the base one (0x04), so set it to 0x00. Fixes: 4ec14b7634b2 ("mlxsw: Add interface to access registers and process events") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-01-28mlxsw: spectrum: Compare local ports instead of pointersIdo Schimmel
When dumping the FDB we can't compare the actual pointers of the ports structs, as it's possible the struct represents a vPort instead of the underlying physical port. Solve this by comparing the local port number instead, as it's shared between the physical ports and all the vPorts on top of him. Fixes: 54a732018d8e ("mlxsw: spectrum: Adjust switchdev ops for VLAN devices") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-01-28mlxsw: spectrum: Dump LAG FDB records only onceIdo Schimmel
LAG FDB records can only point to LAG devices or VLAN devices configured on top of them. Therefore, when dumping the FDB we shouldn't associate these records with the underlying physical ports. Fixes: 8a1ab5d76639 ("mlxsw: spectrum: Implement FDB add/remove/dump for LAG") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-01-28mlxsw: spectrum: Use correct netdev when notifying bridgeIdo Schimmel
LAG FDB entries pointing to VLAN devices should be reported to the bridge with the matching VLAN device and not the underlying LAG device. Fixes: aac78a440887 ("mlxsw: spectrum: Adjust FDB notifications for VLAN devices") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-01-28mlxsw: spectrum: Don't report VLAN for 802.1D FDB entriesIdo Schimmel
When dumping the hardware FDB we should report entries pointing to VLAN devices with VLAN 0, as packets coming into the bridge are untagged. Likewise, pass FDB_{ADD,DEL} notifications with VLAN 0 for these devices. Fixes: 54a732018d8e ("mlxsw: spectrum: Adjust switchdev ops for VLAN devices") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-01-28mlxsw: spectrum: Notify bridge's FDB only based on learning_syncIdo Schimmel
When we disable learning on bridge port we should still update the software bridge's FDB when entry pointing to this bridge port is aged-out. We can otherwise have an inconsistency between software and hardware tables. Fixes: 8a1ab5d76639 ("mlxsw: spectrum: Implement FDB add/remove/dump for LAG") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-01-28mlxsw: spectrum: Disable learning according to STP stateIdo Schimmel
When port is put into LISTENING state it shouldn't populate the FDB, so set the port's STP state in hardware to DISCARDING instead of LEARNING. It will therefore keep listening to BPDU packets, but discard other non-control packets and won't perform any learning. Fixes: 56ade8fe3fe1 ("mlxsw: spectrum: Add initial support for Spectrum ASIC") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-01-28mlxsw: spectrum: Don't forward packets when STP state is DISABLEDIdo Schimmel
When STP state is set to DISABLED the port is assumed to be inactive, but currently we forward packets ingressing through it. Instead, set the port's STP state in hardware to DISCARDING, which means it doesn't forward packets or perform any learning, but it does trap control packets. However, these packets will be dropped by bridge code, which results in the expected behavior. Fixes: 56ade8fe3fe1 ("mlxsw: spectrum: Add initial support for Spectrum ASIC") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-01-28mlxsw: spectrum: Flush FDB when leaving bridgeIdo Schimmel
As explained in previous commit, we should always take care of flushing the FDB in the driver and not rely on bridge code. We need to distinguish between two cases with regards to LAG: 1) Port is leaving LAG while LAG is bridged (or VLAN devices on top of it). In this case don't flush the FDB entries pointing to the LAG ID, as this will affect other ports still member in the LAG. Only flush the FDB when the last port in the LAG is leaving the bridge. 2) LAG device is leaving the bridge. In this case the CHANGEUPPER event is simply propagated to each member port, so make each port flush the FDB in its turn. Note that emptying a bridged LAG from ports creates an inconsistency between hardware and software. A user who later (< ageing_time) re-populates the LAG won't have any FDB entries pointing to the LAG ID in hardware, but they will be present in the software bridge's FDB. Currently there is no good solution to this problem, but this will be addressed by us in the future. In order to optimize the flushing process, flush by port or LAG ID if there are no VLAN interfaces on top of the port. Otherwise, flush using (Port / LAG ID, FID=VID} for each of the lower 4K FIDs. In the case of VLAN device simply flush using {Port / LAG ID, vFID} with the vFID to which the VLAN device is mapped to. Fixes: 56ade8fe3fe1 ("mlxsw: spectrum: Add initial support for Spectrum ASIC") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-01-28mlxsw: reg: Add the Switch Filtering DB Flush registerIdo Schimmel
When removing a net device from a bridge we should flush the FDB entries associated with this net device. Up until now, we relied upon bridge code to do that for us, but it is possible for user to prevent hardware from syncing with the software bridge (learning_sync=0), so we need to flush overselves. Add the Switch Filtering DB Flush (SFDF) register that is used to flush FDB entries according to different parameters (per-port, per-FID etc). Fixes: 56ade8fe3fe1 ("mlxsw: spectrum: Add initial support for Spectrum ASIC") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-01-28mlxsw: spectrum: Handle port leaving LAG while bridgedIdo Schimmel
It is possible for a user to remove a port from a LAG device, while the LAG device or VLAN devices on top of it are bridged. In these cases, bridge's teardown sequence is never issued, so we need to take care of it ourselves. When LAG's unlinking event is received by port netdev: 1) Traverse its vPorts list and make those member in a bridge leave it. They will be deleted later by LAG code. 2) Make the port netdev itself leave its bridge if member in one. Fixes: 0d65fc13042f ("mlxsw: spectrum: Implement LAG port join/leave") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-01-28drm/amdgpu: only move pt bos in LRU list on successNicolai Hähnle
This fixes a race condition in the error case: since the pt bos have not necessarily been reserved in case of an error, we could move a pt bo that is currently in the middle of being evicted/moved by another process, which then resulted in a BUG_ON in ttm_bo_add_to_lru. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Nicolai Hähnle <nicolai.haehnle@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2016-01-28Merge tag 'usb-serial-4.5-rc2' of ↵Greg Kroah-Hartman
git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus Johan writes: USB-serial fixes for v4.5-rc2 Here are two fixes of crashes in the visor driver that could be triggered using bad (malicious) descriptors, a fix for two memory leaks in the new mxu11x0 driver, and an interface-blacklist fix for the option driver. Included are also some new device ids. Signed-off-by: Johan Hovold <johan@kernel.org>
2016-01-28drm/amdkfd: Remove unnecessary cast in kfreeAmitoj Kaur Chawla
Remove an unnecassary cast in the argument to kfree. Found using Coccinelle. The semantic patch used to find this is as follows: //<smpl> @@ type T; expression *f; @@ - kfree((T *)(f)); + kfree(f); //</smpl> Signed-off-by: Amitoj Kaur Chawla <amitoj1606@gmail.com> Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
2016-01-28drm/amdgpu: fix non-ANSI declaration of amdgpu_amdkfd_gfx_*_get_functions()Colin Ian King
amdgpu_amdkfd_gfx_7_get_functions and amdgpu_amdkfd_gfx_8_0_get_functions have no parameters, so use the normal void parameter convention to make them match their prototypes in the header file drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
2016-01-27hwmon: (fam15h_power) Add bit masking for tdp_limitGioh Kim
Add bit masking to read ApmTdpLimit precisely Signed-off-by: Gioh Kim <gi-oh.kim@profitbricks.com> Acked-by: Borislav Petkov <bp@suse.de> Acked-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2016-01-27cpufreq: cpufreq-dt: avoid uninitialized variable warnings:Arnd Bergmann
gcc warns quite a bit about values returned from allocate_resources() in cpufreq-dt.c: cpufreq-dt.c: In function 'cpufreq_init': cpufreq-dt.c:327:6: error: 'cpu_dev' may be used uninitialized in this function [-Werror=maybe-uninitialized] cpufreq-dt.c:197:17: note: 'cpu_dev' was declared here cpufreq-dt.c:376:2: error: 'cpu_clk' may be used uninitialized in this function [-Werror=maybe-uninitialized] cpufreq-dt.c:199:14: note: 'cpu_clk' was declared here cpufreq-dt.c: In function 'dt_cpufreq_probe': cpufreq-dt.c:461:2: error: 'cpu_clk' may be used uninitialized in this function [-Werror=maybe-uninitialized] cpufreq-dt.c:447:14: note: 'cpu_clk' was declared here The problem is that it's slightly hard for gcc to follow return codes across PTR_ERR() calls. This patch uses explicit assignments to the "ret" variable to make it easier for gcc to verify that the code is actually correct, without the need to add a bogus initialization. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-01-27cpufreq: pxa2xx: fix pxa_cpufreq_change_voltage prototypeArnd Bergmann
There are two definitions of pxa_cpufreq_change_voltage, with slightly different prototypes after one of them had its argument marked 'const'. Now the other one (for !CONFIG_REGULATOR) produces a harmless warning: drivers/cpufreq/pxa2xx-cpufreq.c: In function 'pxa_set_target': drivers/cpufreq/pxa2xx-cpufreq.c:291:36: warning: passing argument 1 of 'pxa_cpufreq_change_voltage' discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers] ret = pxa_cpufreq_change_voltage(&pxa_freq_settings[idx]); ^ drivers/cpufreq/pxa2xx-cpufreq.c:205:12: note: expected 'struct pxa_freqs *' but argument is of type 'const struct pxa_freqs *' static int pxa_cpufreq_change_voltage(struct pxa_freqs *pxa_freq) ^ This changes the prototype in the same way as the other, which avoids the warning. Fixes: 03c229906311 (cpufreq: pxa: make pxa_freqs arrays const) Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Cc: 4.2+ <stable@vger.kernel.org> # 4.2+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-01-27cpufreq: Use list_is_last() to check last entry of the policy listGautham R Shenoy
Currently next_policy() explicitly checks if a policy is the last policy in the cpufreq_policy_list. Use the standard list_is_last primitive instead. Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-01-27cpufreq: Fix NULL reference crash while accessing policy->governor_dataViresh Kumar
There is a race discovered by Juri, where we are able to: - create and read a sysfs file before policy->governor_data is being set to a non NULL value. OR - set policy->governor_data to NULL, and reading a file before being destroyed. And so such a crash is reported: Unable to handle kernel NULL pointer dereference at virtual address 0000000c pgd = edfc8000 [0000000c] *pgd=bfc8c835 Internal error: Oops: 17 [#1] SMP ARM Modules linked in: CPU: 4 PID: 1730 Comm: cat Not tainted 4.5.0-rc1+ #463 Hardware name: ARM-Versatile Express task: ee8e8480 ti: ee930000 task.ti: ee930000 PC is at show_ignore_nice_load_gov_pol+0x24/0x34 LR is at show+0x4c/0x60 pc : [<c058f1bc>] lr : [<c058ae88>] psr: a0070013 sp : ee931dd0 ip : ee931de0 fp : ee931ddc r10: ee4bc290 r9 : 00001000 r8 : ef2cb000 r7 : ee4bc200 r6 : ef2cb000 r5 : c0af57b0 r4 : ee4bc2e0 r3 : 00000000 r2 : 00000000 r1 : c0928df4 r0 : ef2cb000 Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: adfc806a DAC: 00000051 Process cat (pid: 1730, stack limit = 0xee930210) Stack: (0xee931dd0 to 0xee932000) 1dc0: ee931dfc ee931de0 c058ae88 c058f1a4 1de0: edce3bc0 c07bfca4 edce3ac0 00001000 ee931e24 ee931e00 c01fcb90 c058ae48 1e00: 00000001 edce3bc0 00000000 00000001 ee931e50 ee8ff480 ee931e34 ee931e28 1e20: c01fb33c c01fcb0c ee931e8c ee931e38 c01a5210 c01fb314 ee931e9c ee931e48 1e40: 00000000 edce3bf0 befe4a00 ee931f78 00000000 00000000 000001e4 00000000 1e60: c00545a8 edce3ac0 00001000 00001000 befe4a00 ee931f78 00000000 00001000 1e80: ee931ed4 ee931e90 c01fbed8 c01a5038 ed085a58 00020000 00000000 00000000 1ea0: c0ad72e4 ee931f78 ee8ff488 ee8ff480 c077f3fc 00001000 befe4a00 ee931f78 1ec0: 00000000 00001000 ee931f44 ee931ed8 c017c328 c01fbdc4 00001000 00000000 1ee0: ee8ff480 00001000 ee931f44 ee931ef8 c017c65c c03deb10 ee931fac ee931f08 1f00: c0009270 c001f290 c0a8d968 ef2cb000 ef2cb000 ee8ff480 00000020 ee8ff480 1f20: ee8ff480 befe4a00 00001000 ee931f78 00000000 00000000 ee931f74 ee931f48 1f40: c017d1ec c017c2f8 c019c724 c019c684 ee8ff480 ee8ff480 00001000 befe4a00 1f60: 00000000 00000000 ee931fa4 ee931f78 c017d2a8 c017d160 00000000 00000000 1f80: 000a9f20 00001000 befe4a00 00000003 c000ffe4 ee930000 00000000 ee931fa8 1fa0: c000fe40 c017d264 000a9f20 00001000 00000003 befe4a00 00001000 00000000 Unable to handle kernel NULL pointer dereference at virtual address 0000000c 1fc0: 000a9f20 00001000 befe4a00 00000003 00000000 00000000 00000003 00000001 pgd = edfc4000 [0000000c] *pgd=bfcac835 1fe0: 00000000 befe49dc 000197f8 b6e35dfc 60070010 00000003 3065b49d 134ac2c9 [<c058f1bc>] (show_ignore_nice_load_gov_pol) from [<c058ae88>] (show+0x4c/0x60) [<c058ae88>] (show) from [<c01fcb90>] (sysfs_kf_seq_show+0x90/0xfc) [<c01fcb90>] (sysfs_kf_seq_show) from [<c01fb33c>] (kernfs_seq_show+0x34/0x38) [<c01fb33c>] (kernfs_seq_show) from [<c01a5210>] (seq_read+0x1e4/0x4e4) [<c01a5210>] (seq_read) from [<c01fbed8>] (kernfs_fop_read+0x120/0x1a0) [<c01fbed8>] (kernfs_fop_read) from [<c017c328>] (__vfs_read+0x3c/0xe0) [<c017c328>] (__vfs_read) from [<c017d1ec>] (vfs_read+0x98/0x104) [<c017d1ec>] (vfs_read) from [<c017d2a8>] (SyS_read+0x50/0x90) [<c017d2a8>] (SyS_read) from [<c000fe40>] (ret_fast_syscall+0x0/0x1c) Code: e5903044 e1a00001 e3081df4 e34c1092 (e593300c) ---[ end trace 5994b9a5111f35ee ]--- Fix that by making sure, policy->governor_data is updated at the right places only. Cc: 4.2+ <stable@vger.kernel.org> # 4.2+ Reported-and-tested-by: Juri Lelli <juri.lelli@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-01-27cpuidle: coupled: remove unused define cpuidle_coupled_lockAnders Roxell
This was found with the -RT patch enabled, but the fix should apply to non-RT also. Used multi_v7_defconfig+PREEMPT_RT_FULL=y and this caused a compilation warning without this fix: ../drivers/cpuidle/coupled.c:122:21: warning: 'cpuidle_coupled_lock' defined but not used [-Wunused-variable] Signed-off-by: Anders Roxell <anders.roxell@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-01-27PM / Domains: Fix typo in commentMoritz Fischer
Acked-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Moritz Fischer <moritz.fischer@ettus.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-01-27PM / Domains: Fix potential deadlock while adding/removing subdomainsUlf Hansson
We must preserve the same order of how we acquire and release the lock for genpd, as otherwise we may encounter deadlocks. The power on phase of a genpd starts by acquiring its lock. Then it walks the hierarchy of its parent domains to be able to power on these first, as per design of genpd. From a locking perspective this means the locks of the parents becomes acquired after the lock of the subdomain. Let's fix pm_genpd_add|remove_subdomain() to maintain the same order of acquiring/releasing the genpd lock as being applied in the power on/off sequence. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-01-27vfio/noiommu: Don't use iommu_present() to track fake groupsAlex Williamson
Using iommu_present() to determine whether an IOMMU group is real or fake has some problems. First, apparently Power systems don't register an IOMMU on the device bus, so the groups and containers get marked as noiommu and then won't bind to their actual IOMMU driver. Second, I expect we'll run into the same issue as we try to support vGPUs through vfio, since they're likely to emulate this behavior of creating an IOMMU group on a virtual device and then providing a vfio IOMMU backend tailored to the sort of isolation they provide, which won't necessarily be fully compatible with the IOMMU API. The solution here is to use the existing iommudata interface to IOMMU groups, which allows us to easily identify the fake groups we've created for noiommu purposes. The iommudata we set is purely arbitrary since we're only comparing the address, so we use the address of the noiommu switch itself. Reported-by: Alexey Kardashevskiy <aik@ozlabs.ru> Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru> Tested-by: Alexey Kardashevskiy <aik@ozlabs.ru> Tested-by: Anatoly Burakov <anatoly.burakov@intel.com> Tested-by: Santosh Shukla <sshukla@mvista.com> Fixes: 03a76b60f8ba ("vfio: Include No-IOMMU mode") Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2016-01-27drm/radeon: fix DP audio support for APU with DCE4.1 display engineSlava Grigorev
Properly setup the DFS divider for DP audio for DCE4.1. Signed-off-by: Slava Grigorev <slava.grigorev@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2016-01-27drm/radeon: Add a common function for DFS handlingSlava Grigorev
Move encoding of DFS (digital frequency synthesizer) divider into a separate function and improve calculation precision. Signed-off-by: Slava Grigorev <slava.grigorev@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
generated by cgit (git 2.34.1) at 2025-09-16 22:43:43 +0000