aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2015-07-14drm/i915: Always force a modeset in intel_crtc_restore_mode, v2.Maarten Lankhorst1-42/+16
And get rid of things that are no longer true. This function is only used for forcing a modeset when encoder properties are changed. Because this is not yet done atomically, assume a full modeset is needed and force a modeset on the crtc. Changes since v1: - s/reset/force modeset/ Signed-off-by: Maarten Lankhorst <[email protected]> Reviewed-by: Daniel Stone <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-07-14drm/i915: Update power domains on readout.Maarten Lankhorst1-26/+50
This allows us to get rid of the set_init_power in modeset_update_crtc_domains. The state should be sanitized enough after setup_hw_state to not need the init power. Signed-off-by: Maarten Lankhorst <[email protected]> Reviewed-by: Daniel Stone <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-07-14drm/i915: Get rid of unused transitional members.Maarten Lankhorst2-74/+18
The previous commit converted hw readout to atomic, all the new_* members were used for restoring the old state, but with the conversion of suspend to atomic there's no use left for them. Signed-off-by: Maarten Lankhorst <[email protected]> Reviewed-by: Daniel Stone <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-07-14drm/i915: Convert resume to atomic.Maarten Lankhorst4-24/+60
Instead of all the ad-hoc updating, duplicate the old state first before reading out the hw state, then restore it. intel_display_resume is a new function that duplicates the sw state, then reads out the hw state, and commits the old state. intel_display_setup_hw_state now only reads out the atomic state. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90396 Signed-off-by: Maarten Lankhorst <[email protected]> Reviewed-by: Daniel Stone <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-07-14drm/i915: Readout initial hw mode.Maarten Lankhorst2-29/+44
drm/i915: Readout initial hw mode, v2. Atomic requires a mode blob when crtc_state->enable is true, or you get a huge warn_on. With a few tweaks the mode we read out from hardware could be used as the real mode without a modeset, but this requires too much testing, so for now force a modeset the first time the mode blob's updated. This preserves the old behavior, because previously we never set the initial mode, which always meant that a modeset happened when the mode was first set. Changes since v1: - Add a description in intel_modeset_readout_hw_state of how the recalculation is done. Signed-off-by: Maarten Lankhorst <[email protected]> Reviewed-by: Daniel Stone <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-07-14drm/i915: Calculate vblank timestamping constants before enabling vblank.Maarten Lankhorst1-0/+1
This is required to properly initialize vblanks on the active crtc. Without it drm_calc_vbltimestamp_from_scanoutpos can fail with crtc 0: Noop due to uninitialized mode. Signed-off-by: Maarten Lankhorst <[email protected]> Reviewed-by: Daniel Stone <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-07-14drm/i915: Zero the mode in intel_sanitize_crtc when force disabling.Maarten Lankhorst1-1/+1
There is a WARN_ON in drm_atomic_crtc_check for this when exposing the atomic property. If the mode_blob still exists, but enable = false then all updates are rejected with -EINVAL. Signed-off-by: Maarten Lankhorst <[email protected]> Reviewed-by: Daniel Stone <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-07-14drm/i915: Fix reference leak in intel_modeset_readout_hw_state.Maarten Lankhorst1-0/+1
Unreference the old mode_blob by calling the crtc_destroy_state helper before zeroing the crtc_state. Signed-off-by: Maarten Lankhorst <[email protected]> Reviewed-by: Daniel Stone <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-07-14drm/i915: Rework plane readout.Maarten Lankhorst3-86/+8
All non-primary planes get disabled during hw readout, this reduces complexity and means not having to do some plane visibility checks during the first commit. Signed-off-by: Maarten Lankhorst <[email protected]> Reviewed-by: Daniel Stone <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-07-14drm/i915: Added Programming of the MOCSPeter Antoine6-2/+413
This change adds the programming of the MOCS registers to the gen 9+ platforms. The set of MOCS configuration entries introduced by this patch is intended to be minimal but sufficient to cover the needs of current userspace - i.e. a good set of defaults. It is expected to be extended in the future to provide further default values or to allow userspace to redefine its private MOCS tables based on its demand for additional caching configurations. In this setup, userspace should only utilize the first N entries, higher entries are reserved for future use. It creates a fixed register set that is programmed across the different engines so that all engines have the same table. This is done as the main RCS context only holds the registers for itself and the shared L3 values. By trying to keep the registers consistent across the different engines it should make the programming for the registers consistent. v2: -'static const' for private data structures and style changes.(Matt Turner) v3: - Make the tables "slightly" more readable. (Damien Lespiau) - Updated tables fix performance regression. v4: - Code formatting. (Chris Wilson) - re-privatised mocs code. (Daniel Vetter) v5: - Changed the name of a function. (Chris Wilson) v6: - re-based - Added Mesa table entry (skylake & broxton) (Francisco Jerez) - Tidied up the readability defines (Francisco Jerez) - NUMBER of entries defines wrong. (Jim Bish) - Added comments to clear up the meaning of the tables (Jim Bish) Signed-off-by: Peter Antoine <[email protected]> v7 (Francisco Jerez): - Don't write L3-specific MOCS_ESC/SCC values into the e/LLC control tables. Prefix L3-specific defines consistently with L3_ and e/LLC-specific defines with LE_ to avoid this kind of confusion in the future. - Change L3CC WT define back to RESERVED (matches my hardware documentation and the original patch, probably a misunderstanding of my own previous comment). - Drop Android tables, define new minimal tables more suitable for the open source stack. - Add comment that the MOCS tables are part of the kernel ABI. - Move intel_logical_ring_begin() and _advance() calls one level down (Chris Wilson). - Minor formatting and style fixes. v8 (Francisco Jerez): - Add table size sanity check to emit_mocs_control/l3cc_table() (Chris Wilson). - Add comment about undefined entries being implicitly set to uncached for forwards compatibility. v9 (Francisco Jerez): - Minor style fixes. Signed-off-by: Francisco Jerez <[email protected]> Acked-by: Damien Lespiau <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-07-14Btrfs: fix file corruption after cloning inline extentsFilipe Manana1-0/+14
Using the clone ioctl (or extent_same ioctl, which calls the same extent cloning function as well) we end up allowing copy an inline extent from the source file into a non-zero offset of the destination file. This is something not expected and that the btrfs code is not prepared to deal with - all inline extents must be at a file offset equals to 0. For example, the following excerpt of a test case for fstests triggers a crash/BUG_ON() on a write operation after an inline extent is cloned into a non-zero offset: _scratch_mkfs >>$seqres.full 2>&1 _scratch_mount # Create our test files. File foo has the same 2K of data at offset 4K # as file bar has at its offset 0. $XFS_IO_PROG -f -s -c "pwrite -S 0xaa 0 4K" \ -c "pwrite -S 0xbb 4k 2K" \ -c "pwrite -S 0xcc 8K 4K" \ $SCRATCH_MNT/foo | _filter_xfs_io # File bar consists of a single inline extent (2K size). $XFS_IO_PROG -f -s -c "pwrite -S 0xbb 0 2K" \ $SCRATCH_MNT/bar | _filter_xfs_io # Now call the clone ioctl to clone the extent of file bar into file # foo at its offset 4K. This made file foo have an inline extent at # offset 4K, something which the btrfs code can not deal with in future # IO operations because all inline extents are supposed to start at an # offset of 0, resulting in all sorts of chaos. # So here we validate that clone ioctl returns an EOPNOTSUPP, which is # what it returns for other cases dealing with inlined extents. $CLONER_PROG -s 0 -d $((4 * 1024)) -l $((2 * 1024)) \ $SCRATCH_MNT/bar $SCRATCH_MNT/foo # Because of the inline extent at offset 4K, the following write made # the kernel crash with a BUG_ON(). $XFS_IO_PROG -c "pwrite -S 0xdd 6K 2K" $SCRATCH_MNT/foo | _filter_xfs_io status=0 exit The stack trace of the BUG_ON() triggered by the last write is: [152154.035903] ------------[ cut here ]------------ [152154.036424] kernel BUG at mm/page-writeback.c:2286! [152154.036424] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC [152154.036424] Modules linked in: btrfs dm_flakey dm_mod crc32c_generic xor raid6_pq nfsd auth_rpcgss oid_registry nfs_acl nfs lockd grace fscache sunrpc loop fuse parport_pc acpi_cpu$ [152154.036424] CPU: 2 PID: 17873 Comm: xfs_io Tainted: G W 4.1.0-rc6-btrfs-next-11+ #2 [152154.036424] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.1-0-g4adadbd-20150316_085822-nilsson.home.kraxel.org 04/01/2014 [152154.036424] task: ffff880429f70990 ti: ffff880429efc000 task.ti: ffff880429efc000 [152154.036424] RIP: 0010:[<ffffffff8111a9d5>] [<ffffffff8111a9d5>] clear_page_dirty_for_io+0x1e/0x90 [152154.036424] RSP: 0018:ffff880429effc68 EFLAGS: 00010246 [152154.036424] RAX: 0200000000000806 RBX: ffffea0006a6d8f0 RCX: 0000000000000001 [152154.036424] RDX: 0000000000000000 RSI: ffffffff81155d1b RDI: ffffea0006a6d8f0 [152154.036424] RBP: ffff880429effc78 R08: ffff8801ce389fe0 R09: 0000000000000001 [152154.036424] R10: 0000000000002000 R11: ffffffffffffffff R12: ffff8800200dce68 [152154.036424] R13: 0000000000000000 R14: ffff8800200dcc88 R15: ffff8803d5736d80 [152154.036424] FS: 00007fbf119f6700(0000) GS:ffff88043d280000(0000) knlGS:0000000000000000 [152154.036424] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [152154.036424] CR2: 0000000001bdc000 CR3: 00000003aa555000 CR4: 00000000000006e0 [152154.036424] Stack: [152154.036424] ffff8803d5736d80 0000000000000001 ffff880429effcd8 ffffffffa04e97c1 [152154.036424] ffff880429effd68 ffff880429effd60 0000000000000001 ffff8800200dc9c8 [152154.036424] 0000000000000001 ffff8800200dcc88 0000000000000000 0000000000001000 [152154.036424] Call Trace: [152154.036424] [<ffffffffa04e97c1>] lock_and_cleanup_extent_if_need+0x147/0x18d [btrfs] [152154.036424] [<ffffffffa04ea82c>] __btrfs_buffered_write+0x245/0x4c8 [btrfs] [152154.036424] [<ffffffffa04ed14b>] ? btrfs_file_write_iter+0x150/0x3e0 [btrfs] [152154.036424] [<ffffffffa04ed15a>] ? btrfs_file_write_iter+0x15f/0x3e0 [btrfs] [152154.036424] [<ffffffffa04ed2c7>] btrfs_file_write_iter+0x2cc/0x3e0 [btrfs] [152154.036424] [<ffffffff81165a4a>] __vfs_write+0x7c/0xa5 [152154.036424] [<ffffffff81165f89>] vfs_write+0xa0/0xe4 [152154.036424] [<ffffffff81166855>] SyS_pwrite64+0x64/0x82 [152154.036424] [<ffffffff81465197>] system_call_fastpath+0x12/0x6f [152154.036424] Code: 48 89 c7 e8 0f ff ff ff 5b 41 5c 5d c3 0f 1f 44 00 00 55 48 89 e5 41 54 53 48 89 fb e8 ae ef 00 00 49 89 c4 48 8b 03 a8 01 75 02 <0f> 0b 4d 85 e4 74 59 49 8b 3c 2$ [152154.036424] RIP [<ffffffff8111a9d5>] clear_page_dirty_for_io+0x1e/0x90 [152154.036424] RSP <ffff880429effc68> [152154.242621] ---[ end trace e3d3376b23a57041 ]--- Fix this by returning the error EOPNOTSUPP if an attempt to copy an inline extent into a non-zero offset happens, just like what is done for other scenarios that would require copying/splitting inline extents, which were introduced by the following commits: 00fdf13a2e9f ("Btrfs: fix a crash of clone with inline extents's split") 3f9e3df8da3c ("btrfs: replace error code from btrfs_drop_extents") Cc: [email protected] Signed-off-by: Filipe Manana <[email protected]>
2015-07-14MIPS: Require O32 FP64 support for MIPS64 with O32 compatPaul Burton1-0/+1
MIPS32r6 code requires FP64 (ie. FR=1) support. Building a kernel with support for MIPS32r6 binaries but without support for O32 with FP64 is therefore a problem which can lead to incorrectly executed userland. CONFIG_MIPS_O32_FP64_SUPPORT is already selected when the kernel is configured for MIPS32r6, but not when the kernel is configured for MIPS64r6 with O32 compat support. Select CONFIG_MIPS_O32_FP64_SUPPORT in such configurations to prevent building kernels which execute MIPS32r6 userland incorrectly. Signed-off-by: Paul Burton <[email protected]> Cc: Markos Chandras <[email protected]> Cc: <[email protected]> # v4.0- Cc: [email protected] Cc: Matthew Fortune <[email protected]> Cc: [email protected] Cc: [email protected] Patchwork: https://patchwork.linux-mips.org/patch/10674/ Signed-off-by: Ralf Baechle <[email protected]>
2015-07-14MIPS: asm-offset.c: Patch up various comments refering to the old filename.Ralf Baechle2-3/+3
arch/mips/tools/offset.c was renamed to arch/mips/kernel/asm-offsets.c for v2.6.14. Signed-off-by: Ralf Baechle <[email protected]>
2015-07-14drm/i915: Remove unused compat32 codeDaniel Vetter1-125/+0
Totatlly forgotten that we have these when nuking all the UMS code. Signed-off-by: Daniel Vetter <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-07-14ALSA: line6: Fix -EBUSY error during active monitoringTakashi Iwai1-7/+2
When a monitor stream is active, the next PCM stream access results in EBUSY error because of the check in line6_stream_start(). Fix this by just skipping the submission of pending URBs when the stream is already running instead. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=101431 Cc: <[email protected]> # v4.0+ Signed-off-by: Takashi Iwai <[email protected]>
2015-07-14drm/i915: Remove plane_config from struct intel_crtc, v2.Maarten Lankhorst2-10/+10
Nothing depends on this outside initial hw readout, so keep this struct on the stack instead. Changes since v1: - Remove unrelated changes. Signed-off-by: Maarten Lankhorst <[email protected]> Reviewed-by: Daniel Stone <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-07-14drm/i915: Update missing properties in find_initial_plane_objMaarten Lankhorst1-2/+11
The src and crtc rectangles were never set, resulting in the primary plane being made invisible on first atomic update. Signed-off-by: Maarten Lankhorst <[email protected]> Reviewed-by: Daniel Stone <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-07-14drm/i915: Allow fuzzy matching in pipe_config_compare, v2.Maarten Lankhorst1-61/+157
Instead of doing ad-hoc checks we already have a way of checking if the state is compatible or not. Use this to force a modeset. Only during modesets, or with PIPE_CONFIG_QUIRK_INHERITED_MODE we should check if a full modeset is really needed. Fastboot will allow the adjust parameter to ignore some stuff too, and it will fix up differences in state that are ignored by the compare function. Changes since v1: - Increase the value of the lowest m/n to prevent truncation. - Dump pipe config when fastboot's used, without a modeset. - Add adjust parameter to intel_compare_link_m_n, which is used to adjust m2_n2 if it's a multiple of m_n. - Add exact parameter intel_compare_m_n. Signed-off-by: Maarten Lankhorst <[email protected]> Reviewed-by: Daniel Stone <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-07-14drm/i915: Do not use plane_config in intel_fbdev.cMaarten Lankhorst1-8/+6
Use the atomic state instead, this allows removing plane_config from the crtc after the full hw readout is completed. The size can be found in the fb, no need for the plane_config. Signed-off-by: Maarten Lankhorst <[email protected]> Reviewed-by: Daniel Stone <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-07-14drm/i915: Do not update pfit state when toggling crtc enabled.Maarten Lankhorst4-38/+48
There's not much point for calculating the changes for the old state. Instead just disable all scalers when disabling. It's probably good enough to just disable the crtc_scaler, but just in case there's a bug disable all scalers. This means intel_atomic_setup_scalers is only called in the crtc check function now, so all the transitional code can be removed. Signed-off-by: Maarten Lankhorst <[email protected]> Reviewed-by: Daniel Stone <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-07-14drm/i915: Only update state on crtc's that are part of the atomic state.Maarten Lankhorst1-1/+2
This is probably hard to hit right now because in most cases all atomic locks are taken, but after conversion to atomic this will make it more likely to corrupt the crtc->config pointer, resulting in hard to find bugs. Signed-off-by: Maarten Lankhorst <[email protected]> Reviewed-by: Daniel Stone <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-07-14drm/i915: Do not call intel_crtc_disable if the crtc is already disabled.Maarten Lankhorst1-4/+2
When resuming with dpms off, the following warn can happen: [ 118.334082] ------------[ cut here ]------------ [ 118.334105] WARNING: CPU: 2 PID: 2274 at drivers/gpu/drm/i915/intel_display.c:6319 __intel_set_mode+0xae5/0xb90 [i915]() [ 118.334106] WARN_ON(!crtc->state->enable) [ 118.334137] Modules linked in: i915 [ 118.334139] CPU: 2 PID: 2274 Comm: kworker/u16:117 Not tainted 4.2.0-rc2-fixes+ #4148 [ 118.334140] Hardware name: LENOVO 2349AV8/2349AV8, BIOS G1ETA5WW (2.65 ) 04/15/2014 [ 118.334144] Workqueue: events_unbound async_run_entry_fn [ 118.334147] ffffffffc017eef0 ffff8800ada93998 ffffffff817aa62a 0000000080000001 [ 118.334149] ffff8800ada939e8 ffff8800ada939d8 ffffffff810807e1 ffff8800ada939c8 [ 118.334151] ffff8800cea3b3d8 0000000000000000 ffff8800ad86b008 ffff880117705668 [ 118.334151] Call Trace: [ 118.334155] [<ffffffff817aa62a>] dump_stack+0x4f/0x7b [ 118.334157] [<ffffffff810807e1>] warn_slowpath_common+0x81/0xc0 [ 118.334158] [<ffffffff81080861>] warn_slowpath_fmt+0x41/0x50 [ 118.334173] [<ffffffffc0120375>] __intel_set_mode+0xae5/0xb90 [i915] [ 118.334188] [<ffffffffc0121312>] ? intel_modeset_compute_config+0x52/0xb40 [i915] [ 118.334191] [<ffffffff8144de53>] ? drm_atomic_set_fb_for_plane+0x63/0x80 [ 118.334205] [<ffffffffc01269d9>] intel_set_mode+0x29/0x60 [i915] [ 118.334219] [<ffffffffc012730a>] intel_crtc_restore_mode+0x13a/0x1f0 [i915] [ 118.334232] [<ffffffffc0101160>] ? gen6_write16+0x250/0x250 [i915] [ 118.334246] [<ffffffffc01283ec>] intel_modeset_setup_hw_state+0x89c/0xcd0 [i915] [ 118.334248] [<ffffffff8137d260>] ? pci_pm_thaw+0x90/0x90 [ 118.334255] [<ffffffffc00ac11b>] i915_drm_resume+0xcb/0x160 [i915] [ 118.334262] [<ffffffffc00ac1d2>] i915_pm_resume+0x22/0x30 [i915] [ 118.334263] [<ffffffff8137d2c3>] pci_pm_resume+0x63/0xa0 [ 118.334266] [<ffffffff81467550>] dpm_run_callback+0x70/0x420 [ 118.334267] [<ffffffff81467cbd>] device_resume+0x9d/0x1c0 [ 118.334269] [<ffffffff814673d0>] ? initcall_debug_start+0x60/0x60 [ 118.334270] [<ffffffff81467dfc>] async_resume+0x1c/0x50 [ 118.334271] [<ffffffff810a6a94>] async_run_entry_fn+0x34/0xd0 [ 118.334273] [<ffffffff8109d4ad>] process_one_work+0x1dd/0x7e0 [ 118.334275] [<ffffffff8109d41a>] ? process_one_work+0x14a/0x7e0 [ 118.334276] [<ffffffff8109daf9>] worker_thread+0x49/0x450 [ 118.334278] [<ffffffff8109dab0>] ? process_one_work+0x7e0/0x7e0 [ 118.334280] [<ffffffff810a3cb9>] kthread+0xf9/0x110 [ 118.334282] [<ffffffff810a3bc0>] ? insert_kthread_work+0x90/0x90 [ 118.334284] [<ffffffff817b414f>] ret_from_fork+0x3f/0x70 [ 118.334286] [<ffffffff810a3bc0>] ? insert_kthread_work+0x90/0x90 [ 118.334287] ---[ end trace 01f2cf6371b82d7a ]--- This warn is harmless, and can be fixed by not calling intel_crtc_disable when the crtc is already disabled. Reported-and-Tested-by: Jörg Otte <[email protected]> Signed-off-by: Maarten Lankhorst <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-07-14Revert "drm/i915: Declare the swizzling unknown for L-shaped configurations"Daniel Vetter1-11/+1
This reverts commit 19ee835cdb0b5a8eb11a68f25a51b8039d564488. It breaks existing old userspace which doesn't handle UNKNOWN swizzling correct. Yes UNKNOWN was a thing back in 2009 and probably still is on some other platforms, but it still pretty clearly broke the testers machine. If we want this we need to extend the ioctl with new paramters that only new userspace looks at. Cc: Harald Arnesen <[email protected]> Cc: Chris Wilson <[email protected]> Reported-by: Harald Arnesen <[email protected]> Cc: [email protected] Signed-off-by: Daniel Vetter <[email protected]>
2015-07-14drm/gem: rip out drm vma accounting for gem mmapsDaniel Vetter1-10/+1
Doesn't really add anything which can't be figured out through proc files. And more clearly separates the new gem mmap handling code from the old drm maps mmap handling code, which is surely a good thing. Cc: Martin Peres <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-07-14tick: Move the export of tick_broadcast_oneshot_control to the proper placeThomas Gleixner2-1/+1
tick_broadcast_oneshot_control got moved from tick-broadcast to tick-common, but the export stayed in the old place. Fix it up. Fixes: f32dd1170511 'tick/broadcast: Make idle check independent from mode and config' Reported-by: Ingo Molnar <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]>
2015-07-14drm/i915/skl: Restrict the ring frequency table programming to SKLAkash Goel1-1/+2
Ring frequency table programming is not required on BXT. Added separate checks to enable the programming only for SKL & skip for BXT. v2: Removed the BXT check from gen6_update_ring_freq function Issue: VIZ-5144 Signed-off-by: Akash Goel <[email protected]> Reviewed-by: Rodrigo Vivi <rodrigo.vivi at intel.com> Signed-off-by: Daniel Vetter <[email protected]>
2015-07-14MAINTAINERS: digicolor: add dts filesBaruch Siach1-0/+1
The 'digicolor' regexp doesn't cover the dts files. Add a glob pattern for them. Signed-off-by: Baruch Siach <[email protected]> Signed-off-by: Olof Johansson <[email protected]>
2015-07-14Merge tag 'socfpga_fixes_for_v4.2-rc1' of ↵Olof Johansson1-13/+13
git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux into fixes Merge "SoCFPGA fixes for v4.2-rc1" from Dinh Nguyen: SoCFPGA fixes against v4.2-rc1 - Update compatible "adxl345x" compatible string - Alphabetize the DTS nodes for the C5 sockit board file * tag 'socfpga_fixes_for_v4.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux: ARM: socfpga: dts: Fix entries order ARM: socfpga: dts: Fix adxl34x formating and compatible string
2015-07-14ARM: ux500: fix MMC/SD card regressionLinus Walleij4-5/+45
Ux500 is regressing due to commit a21763a0b1e5a5ab8310f581886d04beadc16616 "pinctrl: nomadik: activate strict mux mode" which disallows Nomadik GPIO 5 to be muxed in as a level shifter voltage select pin, as it is currently described as being used for RX on UART1. The behaviour is correct, instead the hardware config has been incorrecly specified: UART1 is indeed unused on HREFv60plus and Snowball and that is why HREFv60plus can use the pins it would normally occupy as the voltage select line for the MMC/SD levelshifter (Snowball uses it for I2C4). The reason UART1 was anyway enabled on these platforms was probably to secure the port enumeration to userspace. This can be solved by using aliases (done in a separate patch) so we can now deactivate UART1 and let MMC/SD use it properly on HREFv60plus. We explicitly activate it only for the older HREFprev60 board. To complete, we set up the pin configuration for these pins properly in the sdi0 node. Cc: Ulf Hansson <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Olof Johansson <[email protected]>
2015-07-14ARM: ux500: define serial port aliasesLinus Walleij8-3/+52
This enumerates the PL011 serial ports on the Ux500. This is necessary to do if we want to remove one of the serial ports, since userspace depends on console to be present on ttyAMA2 and we must not break userspace. Cc: Ulf Hansson <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Olof Johansson <[email protected]>
2015-07-14drm/i915: Forward all core DRM ioctls to core compat handlingTvrtko Ursulin1-1/+1
Previously only core DRM ioctls under the DRM_COMMAND_BASE were being forwarded, but the drm.h header suggests (and reality confirms) ones after (and including) DRM_COMMAND_END should be forwarded as well. We need this to correctly forward the compat ioctl for the botched-up addfb2.1 extension. Signed-off-by: Tvrtko Ursulin <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: [email protected] # 4.1+ [danvet: Explain why this is suddenly needed and add cc: stable.] Signed-off-by: Daniel Vetter <[email protected]>
2015-07-14ARM: dts: OMAP5: Add #iommu-cells property to IOMMUsSuman Anna1-0/+2
Add missing #iommu-cells property to the DSP and IPU IOMMU nodes for OMAP5 platforms. This property is required as per the generic iommu binding. Signed-off-by: Suman Anna <[email protected]> Signed-off-by: Tony Lindgren <[email protected]>
2015-07-14ARM: dts: OMAP4: Add #iommu-cells property to IOMMUsSuman Anna1-0/+2
Add missing #iommu-cells property to the DSP and IPU IOMMU nodes for OMAP4 platforms. This property is required as per the generic iommu binding. Signed-off-by: Suman Anna <[email protected]> Signed-off-by: Tony Lindgren <[email protected]>
2015-07-14ARM: dts: Fix frequency scaling on Gumstix PepperArun Bharadwaj1-2/+2
The device tree for Gumstix Pepper has DCDC2 and DCDC3 correctly labelled but the upper limit values are wrong. The confusion is due to the hardware quirk where the DCDC2 and DCDC3 wires are flipped in Pepper. Signed-off-by: Arun Bharadwaj <[email protected]> Tested-by: Ash Charles <[email protected]> Signed-off-by: Tony Lindgren <[email protected]>
2015-07-14ARM: dts: configure regulators for Gumstix PepperAdam YH Lee1-0/+9
Boot process is halting in midway because some of the necessary voltage regulators are deemed unused and subsequently powered off, leading to a completely unresponsive system. Most of the device nodes had correct voltage regulator attachments. Yet these nodes had to set stricter enforcement on them through 'regulator-boot-on' and 'regulator-always-on' to function correctly. The consumers of the regulators this commit affect are the followings: DCDC1: vdd_1v8 system supply, USB-PHY, and ADC DCDC2: Core domain DCDC3: MPU core domain LDO1: RTC LDO2: 3v3 IO domain LDO3: USB-PHY; not a boot-time requirement LDO4: LCD [16:23] All but LDO3 need to be always-on for the system to be functional. Additionally regulator-name properties have been added for the kernel to display the name from the schematic. This will improve diagnostics. Signed-off-by: Adam YH Lee <[email protected]> Signed-off-by: Tony Lindgren <[email protected]>
2015-07-13ARM: dts: omap3: overo: Update LCD panel namesAdam YH Lee2-2/+2
For Gumstix Overo COMs, the u-boot bootloader typically passes an argument specifying the default display via the omapdss.def_disp parameter. When a default display is specified, DSS2 tries to match this name with either the device tree label (e.g. label=dvi) or, failing this, the device tree alias (e.g. label=display0). Update the panel names for the 'lcd43' and 'lcd35' displays in the device tree such that they match the names passed by u-boot. Signed-off-by: Ash Charles <[email protected]> Signed-off-by: Tony Lindgren <[email protected]>
2015-07-13ARM: dts: cros-ec-keyboard: Add support for some Japanese keysChris Zhong1-0/+4
Add support for 4 Japanese keys Signed-off-by: Chris Zhong <[email protected]> Reviewed-by: Doug Anderson <[email protected]> Signed-off-by: Olof Johansson <[email protected]>
2015-07-13tpm, tpm_crb: fail when TPM2 ACPI table contents look corruptedJarkko Sakkinen1-0/+8
At least some versions of AMI BIOS have corrupted contents in the TPM2 ACPI table and namely the physical address of the control area is set to zero. This patch changes the driver to fail gracefully when we observe a zero address instead of continuing to ioremap. Cc: <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]> Reviewed-by: Peter Huewe <[email protected]> Signed-off-by: Peter Huewe <[email protected]>
2015-07-13tpm: Fix initialization of the cdevJason Gunthorpe1-1/+2
When a cdev is contained in a dynamic structure the cdev parent kobj should be set to the kobj that controls the lifetime of the enclosing structure. In TPM's case this is the embedded struct device. Also, cdev_init 0's the whole structure, so all sets must be after, not before. This fixes module ref counting and cdev. Cc: <[email protected]> Fixes: 313d21eeab92 ("tpm: device class for tpm") Signed-off-by: Jason Gunthorpe <[email protected]> Reviewed-by: Dmitry Torokhov <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Tested-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Peter Huewe <[email protected]>
2015-07-13gpio/davinci: Fix race in installing chained irq handlerThomas Gleixner1-4/+2
Fix a race where a pending interrupt could be received and the handler called before the handler's data has been setup, by converting to irq_set_chained_handler_and_data(). Search and conversion was done with coccinelle. Reported-by: Russell King <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Cc: Julia Lawall <[email protected]> Cc: Linus Walleij <[email protected]> Cc: Alexandre Courbot <[email protected]>
2015-07-13Merge tag 'iio-fixes-for-4.2b' of ↵Greg Kroah-Hartman6-63/+58
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus Jonathan writes: Second set of IIO fixes for the 4.2 cycle. Note these depend (mostly) on material in the recent merge window, hence their separation from set (a) as the fixes-togreg branch predated the merge window. I am running rather later with these than I would have liked hence the large set. * stk3310 fixes from Hartmut's review that came in post merge - fix direction of proximity inline with recent documentation clarification. - fix missing REGMAP_I2C dependency - rework the error handling for raw readings to fix an failure to power down in the event of a raw reading failing. - fix a bug in the compensation code which was toggling an extra bit in the register. * mmc35240 - reported samplign frequencies were wrong. * ltr501 fixes - fix a case of returning the return value of a regmap_read instead of the value read. - fix missing regmap dependency * sx9500 - fix missing default values for ret in a couple of places to handle the case of no enabled channels. * tmp006 - check that writes to info_mask elements are actually to writable ones. Otherwise, writing to any of them will change the sampling frequency.
2015-07-13Merge tag 'iio-fixes-for-4.2a' of ↵Greg Kroah-Hartman13-18/+48
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus Jonathan writes: First set of IIO fixes for the 4.2 cycle. * Fix a regression in hid sensors suspend time as a result of adding runtime pm. The normal flow of waking up devices in order to go into suspend (given the devices are normally suspended when not reading) to a regression in suspend time on some laptops (reports of an additional 8 seconds). Fix this by checking to see if a user action resulting in the wake up, and make it a null operation if it didn't. Note that for hid sensors, there is nothing useful to be done when moving into a full suspend from a runtime suspend so they might as well be left alone. * rochip_saradc: fix some missing MODULE_* data including the licence so that the driver does not taint the kernel incorrectly and can build as a module. * twl4030 - mark irq as oneshot as it always should have been. * inv-mpu - write formats for attributes not specified, leading to miss interpretation of the gyro scale channel when written. * Proximity ABI clarification. This had snuck through as a mess. Some drivers thought proximity went in one direction, some the other. We went with the most common option, documented it and fixed up the drivers going the other way. Fix for sx9500 included in this set. * ad624r - fix a wrong shift in the output data. * at91_adc - remove a false limit on the value of the STARTUP register applied by too small a type for the device tree parameter. * cm3323 - clear the bits when setting the integration time (otherwise we can only ever set more bits in the relevant field). * bmc150-accel - multiple triggers are registered, but on error were not being unwound in the opposite order leading to removal of triggers that had not yet successfully been registered (count down instead of up when unwinding). * tcs3414 - ensure right part of val / val2 pair read so that the integration time is not always 0. * cc10001_adc - bug in kconfig dependency. Use of OR when AND was intended.
2015-07-13drm/i915: fix oops in primary_check_planeDaniel Vetter1-1/+1
On Sun, Jul 12, 2015 at 09:52:51AM -0700, Linus Torvalds wrote: > On Sun, Jul 12, 2015 at 1:03 AM, Jörg Otte <[email protected]> wrote: > > BUG: unable to handle kernel NULL pointer dereference at 0000000000000009 > > IP: [<ffffffffbd3447bb>] 0xffffffffbd3447bb > > Ugh. Please enable KALLSYMS to get sane symbols. > > But yes, "crtc_state->base.active" is at offset 9 from "crtc_state", > so it's pretty clearly just that change frm > > - if (intel_crtc->active) { > + if (crtc_state->base.active) { > > and "crtc_state" is NULL. > > And the code very much knows that crtc_state can be NULL, since it's > initialized with > > crtc_state = state->base.state ? > intel_atomic_get_crtc_state(state->base.state, > intel_crtc) : NULL; > > Tssk. Daniel? Should I just revert that commit dec4f799d0a4 > ("drm/i915: Use crtc_state->active in primary check_plane func") for > now, or is there a better fix? Like just checking crtc_state for NULL? Indeed embarrassing. I've missed that we still have 1 caller left that's using the transitional helpers, and those don't fill out plane_state->state backpointers to the global atomic update since there is no global atomic update for transitional helpers. Below diff should fix this - we need to preferentially check crts_state->active and if that's not set intel_crtc->active should yield the right result for the one remaining caller (it's in the crtc_disable paths). This fixes a regression introduced in commit dec4f799d0a4c9edae20512fa60b0a36f3299ca2 Author: Daniel Vetter <[email protected]> Date: Tue Jul 7 11:15:47 2015 +0200 drm/i915: Use crtc_state->active in primary check_plane func which was quickly reverted in commit 01e2d0627a9a6edb24c37db45db5ecb31e9de808 Author: Linus Torvalds <[email protected]> Date: Sun Jul 12 15:00:20 2015 -0700 Revert "drm/i915: Use crtc_state->active in primary check_plane func" Cc: Linus Torvalds <[email protected]> Cc: Jörg Otte <[email protected]> Reported-and-tested-by: Jörg Otte <[email protected]> Reviewed-by: Maarten Lankhorst <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-07-13drm/i915: remove unused has_dma_mapping flagImre Deak5-15/+2
After the previous patch this flag will check always clear, as it's never set for shmem backed and userptr objects, so we can remove it. Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Chris Wilson <[email protected]> [danvet: Yeah this isn't really fixes but it's a nice cleanup to clarify the code but not really worth the hassle of backmerging. So just add to -fixes, we're still early in -rc.] Signed-off-by: Daniel Vetter <[email protected]>
2015-07-13drm/i915: Fix missing return warning for !CONFIG_DEBUGFSDaniel Vetter1-1/+2
This broken code was introduced in commit aa7471d228eb6dfddd0d201ea9746d6a2020972a Author: Jani Nikula <[email protected]> Date: Wed Apr 1 11:15:21 2015 +0300 drm/i915: add i915 specific connector debugfs file for DPCD v2: Drop hunk that accidentally crept in. Cc: Jani Nikula <[email protected]> Cc: Bob Paauwe <[email protected]> Cc: François Valenduc <[email protected]> Reported-by: François Valenduc <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-07-13drm/i915: avoid leaking DMA mappingsImre Deak2-17/+43
We have 3 types of DMA mappings for GEM objects: 1. physically contiguous for stolen and for objects needing contiguous memory 2. DMA-buf mappings imported via a DMA-buf attach operation 3. SG DMA mappings for shmem backed and userptr objects For 1. and 2. the lifetime of the DMA mapping matches the lifetime of the corresponding backing pages and so in practice we create/release the mapping in the object's get_pages/put_pages callback. For 3. the lifetime of the mapping matches that of any existing GPU binding of the object, so we'll create the mapping when the object is bound to the first vma and release the mapping when the object is unbound from its last vma. Since the object can be bound to multiple vmas, we can end up creating a new DMA mapping in the 3. case even if the object already had one. This is not allowed by the DMA API and can lead to leaked mapping data and IOMMU memory space starvation in certain cases. For example HW IOMMU drivers (intel_iommu) allocate a new range from their memory space whenever a mapping is created, silently overriding a pre-existing mapping. Fix this by moving the creation/removal of DMA mappings to the object's get_pages/put_pages callbacks. These callbacks already check for and do an early return in case of any nested calls. This way objects of the 3. case also become more like the other object types. I noticed this issue by enabling DMA debugging, which got disabled after a while due to its internal mapping tables getting full. It also reported errors in connection to random other drivers that did a DMA mapping for an address that was previously mapped by i915 but was never released. Besides these diagnostic messages and the memory space starvation problem for IOMMUs, I'm not aware of this causing a real issue. The fix is based on a patch from Chris. v2: - move the DMA mapping create/remove calls to the get_pages/put_pages callbacks instead of adding new callbacks for these (Chris) v3: - also fix the get_page cache logic on the userptr async path (Chris) Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Cc: [email protected] Signed-off-by: Daniel Vetter <[email protected]>
2015-07-13drm/i915: Snapshot seqno of most recently submitted request.Tomas Elf3-10/+11
The hang checker needs to inspect whether or not the ring request list is empty as well as if the given engine has reached or passed the most recently submitted request. The problem with this is that the hang checker cannot grab the struct_mutex, which is required in order to safely inspect requests since requests might be deallocated during inspection. In the past we've had kernel panics due to this very unsynchronized access in the hang checker. One solution to this problem is to not inspect the requests directly since we're only interested in the seqno of the most recently submitted request - not the request itself. Instead the seqno of the most recently submitted request is stored separately, which the hang checker then inspects, circumventing the issue of synchronization from the hang checker entirely. This fixes a regression introduced in commit 44cdd6d219bc64f6810b8ed0023a4d4db9e0fe68 Author: John Harrison <[email protected]> Date: Mon Nov 24 18:49:40 2014 +0000 drm/i915: Convert 'ring_idle()' to use requests not seqnos v2 (Chris Wilson): - Pass current engine seqno to ring_idle() from i915_hangcheck_elapsed() rather than compute it over again. - Remove extra whitespace. Issue: VIZ-5998 Signed-off-by: Tomas Elf <[email protected]> Cc: [email protected] Reviewed-by: Chris Wilson <[email protected]> [danvet: Add regressing commit citation provided by Chris.] Signed-off-by: Daniel Vetter <[email protected]>
2015-07-13drm/i915: Store device pointer in contexts for late tracepoint usafeChris Wilson3-3/+4
[ 1572.417121] BUG: unable to handle kernel NULL pointer dereference at (null) [ 1572.421010] IP: [<ffffffffa00b2514>] ftrace_raw_event_i915_context+0x5d/0x70 [i915] [ 1572.424970] PGD 1766a3067 PUD 1767a2067 PMD 0 [ 1572.428892] Oops: 0000 [#1] SMP [ 1572.432787] Modules linked in: ipv6 dm_mod iTCO_wdt iTCO_vendor_support snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_controller snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_timer snd soundcore serio_raw pcspkr lpc_ich i2c_i801 mfd_core battery ac acpi_cpufreq i915 button video drm_kms_helper drm [ 1572.441720] CPU: 2 PID: 18853 Comm: kworker/u8:0 Not tainted 4.0.0_kcloud_3f0360_20150429+ #588 [ 1572.446298] Workqueue: i915 i915_gem_retire_work_handler [i915] [ 1572.450876] task: ffff880002f428f0 ti: ffff880035724000 task.ti: ffff880035724000 [ 1572.455557] RIP: 0010:[<ffffffffa00b2514>] [<ffffffffa00b2514>] ftrace_raw_event_i915_context+0x5d/0x70 [i915] [ 1572.460423] RSP: 0018:ffff880035727ce8 EFLAGS: 00010286 [ 1572.465262] RAX: ffff880073f1643c RBX: ffff880002da9058 RCX: ffff880073e5db40 [ 1572.470179] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff880035727ce8 [ 1572.475107] RBP: ffff88007bb11a00 R08: 0000000000000000 R09: 0000000000000000 [ 1572.480034] R10: 0000000000362200 R11: 0000000000000008 R12: 0000000000000000 [ 1572.484952] R13: ffff880035727d78 R14: ffff880002dc1c98 R15: ffff880002dc1dc8 [ 1572.489886] FS: 0000000000000000(0000) GS:ffff88017fd00000(0000) knlGS:0000000000000000 [ 1572.494883] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 1572.499859] CR2: 0000000000000000 CR3: 000000017572a000 CR4: 00000000001006e0 [ 1572.504842] Stack: [ 1572.509834] ffff88017b0090c0 ffff880073f16438 ffff880002da9058 ffff880073f1643c [ 1572.514904] 0000000000000246 ffff880100000000 ffff88007bb11a00 ffff880002ddeb10 [ 1572.519985] ffff8801759f79c0 ffffffffa0092ff0 0000000000000000 ffff88007bb11a00 [ 1572.525049] Call Trace: [ 1572.530093] [<ffffffffa0092ff0>] ? i915_gem_context_free+0xa8/0xc1 [i915] [ 1572.535227] [<ffffffffa009b969>] ? i915_gem_request_free+0x4e/0x50 [i915] [ 1572.540347] [<ffffffffa00b5533>] ? intel_execlists_retire_requests+0x14c/0x159 [i915] [ 1572.545500] [<ffffffffa009d9ea>] ? i915_gem_retire_requests+0x9d/0xeb [i915] [ 1572.550664] [<ffffffffa009dd8c>] ? i915_gem_retire_work_handler+0x4c/0x61 [i915] [ 1572.555825] [<ffffffff8104ca7f>] ? process_one_work+0x1b2/0x31d [ 1572.560951] [<ffffffff8104d278>] ? worker_thread+0x24d/0x339 [ 1572.566033] [<ffffffff8104d02b>] ? cancel_delayed_work_sync+0xa/0xa [ 1572.571140] [<ffffffff81050b25>] ? kthread+0xce/0xd6 [ 1572.576191] [<ffffffff81050a57>] ? kthread_create_on_node+0x162/0x162 [ 1572.581228] [<ffffffff8179b3c8>] ? ret_from_fork+0x58/0x90 [ 1572.586259] [<ffffffff81050a57>] ? kthread_create_on_node+0x162/0x162 [ 1572.591318] Code: de 48 89 e7 e8 09 4d 00 e1 48 85 c0 74 27 48 89 68 10 48 8b 55 38 48 89 e7 48 89 50 18 48 8b 55 10 48 8b 12 48 8b 12 48 8b 52 38 <8b> 12 89 50 08 e8 95 4d 00 e1 48 83 c4 30 5b 5d 41 5c c3 41 55 [ 1572.596981] RIP [<ffffffffa00b2514>] ftrace_raw_event_i915_context+0x5d/0x70 [i915] [ 1572.602464] RSP <ffff880035727ce8> [ 1572.607911] CR2: 0000000000000000 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90112#c23 Signed-off-by: Chris Wilson <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2015-07-13perf hists browser: Take the --comm, --dsos, etc filters into accountArnaldo Carvalho de Melo1-1/+1
At some point: commit 2c86c7ca7606 Author: Namhyung Kim <[email protected]> Date: Mon Mar 17 18:18:54 2014 -0300 perf report: Merge al->filtered with hist_entry->filtered We stopped dropping samples for things filtered via the --comms, --dsos, --symbols, etc, i.e. things marked as filtered in the symbol resolution routines (thread__find_addr_map(), perf_event__preprocess_sample(), etc). But then, in: commit 268397cb2a47 Author: Namhyung Kim <[email protected]> Date: Tue Apr 22 14:49:31 2014 +0900 perf top/tui: Update nr_entries properly after a filter is applied We don't take into account entries that were filtered in perf_event__preprocess_sample() and friends, which leads to inconsistency in the browser seek routines, that expects the number of hist_entry->filtered entries to match what it thinks is the number of unfiltered, browsable entries. So, for instance, when we do: perf top --symbols ___non_existent_symbol___ the hist_browser__nr_entries() routine thinks there are no filters in place, uses the hists->nr_entries but all entries are filtered, leading to a segfault. Tested with: perf top --symbols malloc,free --percentage=relative Freezing, by pressing 'f', at any time and doing the math on the percentages ends up with 100%, ditto for: perf top --dsos libpthread-2.20.so,libxul.so --percentage=relative Both were segfaulting, all fixed now. More work needed to do away with checking if filters are in place, we should just use the nr_non_filtered_samples counter, no need to conditionally use it or hists.nr_filter, as what the browser does is just show unfiltered stuff. An audit of how it is being accounted is needed, this is the minimal fix. Reported-by: Michael Petlan <[email protected]> Fixes: 268397cb2a47 ("perf top/tui: Update nr_entries properly after a filter is applied") Cc: Adrian Hunter <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: David Ahern <[email protected]> Cc: Frederic Weisbecker <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Stephane Eranian <[email protected]> Link: http://lkml.kernel.org/n/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2015-07-13Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netLinus Torvalds66-394/+702
Pull networking fixes from David Miller: 1) Missing list head init in bluetooth hidp session creation, from Tedd Ho-Jeong An. 2) Don't leak SKB in bridge netfilter error paths, from Florian Westphal. 3) ipv6 netdevice private leak in netfilter bridging, fixed by Julien Grall. 4) Fix regression in IP over hamradio bpq encapsulation, from Ralf Baechle. 5) Fix race between rhashtable resize events and table walks, from Phil Sutter. 6) Missing validation of IFLA_VF_INFO netlink attributes, fix from Daniel Borkmann. 7) Missing security layer socket state initialization in tipc code, from Stephen Smalley. 8) Fix shared IRQ handling in boomerang 3c59x interrupt handler, from Denys Vlasenko. 9) Missing minor_idr destroy on module unload on macvtap driver, from Johannes Thumshirn. 10) Various pktgen kernel thread races, from Oleg Nesterov. 11) Fix races that can cause packets to be processed in the backlog even after a device attached to that SKB has been fully unregistered. From Julian Anastasov. 12) bcmgenet driver doesn't account packet drops vs. errors properly, fix from Petri Gynther. 13) Array index validation and off by one fix in DSA layer from Florian Fainelli * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (66 commits) can: replace timestamp as unique skb attribute ARM: dts: dra7x-evm: Prevent glitch on DCAN1 pinmux can: c_can: Fix default pinmux glitch at init can: rcar_can: unify error messages can: rcar_can: print request_irq() error code can: rcar_can: fix typo in error message can: rcar_can: print signed IRQ # can: rcar_can: fix IRQ check net: dsa: Fix off-by-one in switch address parsing net: dsa: Test array index before use net: switchdev: don't abort unsupported operations net: bcmgenet: fix accounting of packet drops vs errors cdc_ncm: update specs URL Doc: z8530book: Fix typo in API-z8530-sync-txdma-open.html net: inet_diag: always export IPV6_V6ONLY sockopt for listening sockets bridge: mdb: allow the user to delete mdb entry if there's a querier net: call rcu_read_lock early in process_backlog net: do not process device backlog during unregistration bridge: fix potential crash in __netdev_pick_tx() net: axienet: Fix devm_ioremap_resource return value check ...
Powered by cgit, Gruvboxed by Blaster4385.