| Age | Commit message (Collapse) | Author |
|---|
|
The clear and set masks in the call to phy_set_clr_bits() called from
bcm7xxx_config_init() are inverted. We need to fix this by swapping the two
arguments, that is, set 0 bits, but clear the shade mode 2 enable bit.
Fixes: b560a58c45c66 ("net: phy: add Broadcom BCM7xxx internal PHY driver")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Sergei Shtylyov says:
====================
ravb: fix the fallout of R-Car gen3 gPTP support
Here's a set of 2 patches against DaveM's 'net.git' repo fixing up the
incomplete commit f5d7837f96e5 ("ravb: ptp: Add CONFIG mode support").
I'm proposing these as fixes but they can be merged as cleanups as well...
[1/2] ravb: kill duplicate setting of CCC.CSEL
[2/2] ravb: skip gPTP start/stop on R-Car gen3
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
When adding support for the R-Car gen3 gPTP active in configuration mode,
some call sites of ravb_ptp_{init|stop}() were missed due to an oversight.
Add checks for the R-Car gen2 SoCs around these...
Fixes: f5d7837f96e5 ("ravb: ptp: Add CONFIG mode support")
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
When adding support for the R-Car gen3 gPTP active in configuration mode,
the code setting the CCC.CSEL field was duplicated due to an oversight.
For R-Car gen 2 it's just redundant and for R-Car gen3 the write at this
time is probably ignored due to CCC.GAC bit being already set...
Fixes: f5d7837f96e5 ("ravb: ptp: Add CONFIG mode support")
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This supports 420 and 422 subsampling with 2 or 3 planes, tested with
modetest. It doesn't set up chroma subsampling position (which it
appears KMS doesn't deal with yet).
The LBM memory is overallocated in many cases, but apparently the docs
aren't quite correct and I'll probably need to look at the hardware
source to really figure it out.
Signed-off-by: Eric Anholt <eric@anholt.net>
|
|
These were all touch-tested with modetest.
Signed-off-by: Eric Anholt <eric@anholt.net>
|
|
This implements a simple policy for choosing scaling modes
(trapezoidal for decimation, PPF for magnification), and a single PPF
filter (Mitchell/Netravali's recommendation).
Signed-off-by: Eric Anholt <eric@anholt.net>
|
|
This doesn't matter yet since we only allow 1:1 scaling, but the
comment clearly says we should be using the source size.
Signed-off-by: Eric Anholt <eric@anholt.net>
|
|
Previously we only did the primary and cursor plane, but overlay
planes are useful and just require this setup to add, since all planes
go into the HVS display list in the same way.
Signed-off-by: Eric Anholt <eric@anholt.net>
|
|
So far, we've only ever lit up one CRTC, so this has been fine. To
extend to more displays or more planes, we need to make sure we don't
run our display lists into each other.
Signed-off-by: Eric Anholt <eric@anholt.net>
|
|
Previously, on every modeset we would allocate new display list
memory, recompute changed planes, write all of them to the new memory,
and pointed scanout at the new list (which will latch approximately at
the next line of scanout). We let
drm_atomic_helper_wait_for_vblanks() decide whether we needed to wait
for a vblank after a modeset before cleaning up the old state and
letting the next modeset proceed, and on legacy cursor updates we
wouldn't wait. If you moved the cursor fast enough, we could
potentially wrap around the display list memory area and overwrite the
existing display list while it was still being scanned out, resulting
in the HVS scanning out garbage or just halting.
Instead of making cursor updates wait for scanout to move to the new
display list area (which introduces significant cursor lag in X), we
just rewrite our current display list.
Signed-off-by: Eric Anholt <eric@anholt.net>
|
|
As we add actual scaling, this is going to get way more complicated.
Signed-off-by: Eric Anholt <eric@anholt.net>
|
|
This is the pointer to the HVS device's memory where we stored the
contents of *dlist.
Signed-off-by: Eric Anholt <eric@anholt.net>
|
|
Signed-off-by: Eric Anholt <eric@anholt.net>
|
|
Pull cifs fixes from Steve French:
"A small set of cifs fixes.
I am still reviewing some more, recently submitted SMB3 fixes, but
these three are small and safe and ready now"
* 'for-next' of git://git.samba.org/sfrench/cifs-2.6:
cifs: fix erroneous return value
cifs: fix potential overflow in cifs_compose_mount_options
cifs: remove redundant check for null string pointer
|
|
Pull ARM KVM fixes from Paolo Bonzini:
- Fix for an unpleasant crash when the VM is created without a timer
- Allow HYP mode to access the full PA space, and not only 40bit
* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
arm64: KVM: Configure TCR_EL2.PS at runtime
KVM: arm/arm64: Fix reference to uninitialised VGIC
|
|
If cgroup writeback is in use, an inode is associated with a cgroup
for writeback. If the inode's main dirtier changes to another cgroup,
the association gets updated asynchronously. Nothing was pinning the
superblock while such switches are in progress and superblock could go
away while async switching is pending or in progress leading to
crashes like the following.
kernel BUG at fs/jbd2/transaction.c:319!
invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC
CPU: 1 PID: 29158 Comm: kworker/1:10 Not tainted 4.5.0-rc3 #51
Hardware name: Google Google, BIOS Google 01/01/2011
Workqueue: events inode_switch_wbs_work_fn
task: ffff880213dbbd40 ti: ffff880209264000 task.ti: ffff880209264000
RIP: 0010:[<ffffffff803e6922>] [<ffffffff803e6922>] start_this_handle+0x382/0x3e0
RSP: 0018:ffff880209267c30 EFLAGS: 00010202
...
Call Trace:
[<ffffffff803e6be4>] jbd2__journal_start+0xf4/0x190
[<ffffffff803cfc7e>] __ext4_journal_start_sb+0x4e/0x70
[<ffffffff803b31ec>] ext4_evict_inode+0x12c/0x3d0
[<ffffffff8035338b>] evict+0xbb/0x190
[<ffffffff80354190>] iput+0x130/0x190
[<ffffffff80360223>] inode_switch_wbs_work_fn+0x343/0x4c0
[<ffffffff80279819>] process_one_work+0x129/0x300
[<ffffffff80279b16>] worker_thread+0x126/0x480
[<ffffffff8027ed14>] kthread+0xc4/0xe0
[<ffffffff809771df>] ret_from_fork+0x3f/0x70
Fix it by bumping s_active while cgroup association switching is in
flight.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-and-tested-by: Tahsin Erdogan <tahsin@google.com>
Link: http://lkml.kernel.org/g/CAAeU0aNCq7LGODvVGRU-oU_o-6enii5ey0p1c26D1ZzYwkDc5A@mail.gmail.com
Fixes: d10c80955265 ("writeback: implement foreign cgroup inode bdi_writeback switching")
Cc: stable@vger.kernel.org #v4.5+
Signed-off-by: Jens Axboe <axboe@fb.com>
|
|
Pablo Neira Ayuso says:
====================
Netfilter fixes for net
The following patchset contain a rather large batch for your net that
includes accumulated bugfixes, they are:
1) Run conntrack cleanup from workqueue process context to avoid hitting
soft lockup via watchdog for large tables. This is required by the
IPv6 masquerading extension. From Florian Westphal.
2) Use original skbuff from nfnetlink batch when calling netlink_ack()
on error since this needs to access the skb->sk pointer.
3) Incremental fix on top of recent Sasha Levin's lock fix for conntrack
resizing.
4) Fix several problems in nfnetlink batch message header sanitization
and error handling, from Phil Turnbull.
5) Select NF_DUP_IPV6 based on CONFIG_IPV6, from Arnd Bergmann.
6) Fix wrong signess in return values on nf_tables counter expression,
from Anton Protopopov.
Due to the NetDev 1.1 organization burden, I had no chance to pass up
this to you any sooner in this release cycle, sorry about that.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The unix_dgram_sendmsg routine use the following test
if (unlikely(unix_peer(other) != sk && unix_recvq_full(other))) {
to determine if sk and other are in an n:1 association (either
established via connect or by using sendto to send messages to an
unrelated socket identified by address). This isn't correct as the
specified address could have been bound to the sending socket itself or
because this socket could have been connected to itself by the time of
the unix_peer_get but disconnected before the unix_state_lock(other). In
both cases, the if-block would be entered despite other == sk which
might either block the sender unintentionally or lead to trying to unlock
the same spin lock twice for a non-blocking send. Add a other != sk
check to guard against this.
Fixes: 7d267278a9ec ("unix: avoid use-after-free in ep_remove_wait_queue")
Reported-By: Philipp Hahn <pmhahn@pmhahn.de>
Signed-off-by: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Tested-by: Philipp Hahn <pmhahn@pmhahn.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into kvm-master
KVM/ARM fixes for 4.5-rc4
- Fix for an unpleasant crash when the VM is created without a timer
- Allow HYP mode to access the full PA space, and not only 40bit
|
|
Unfortunately i915 is still not fully atomic, and expects mode_config.mutex
to be held during modeset until we finally fix it.
This fixes the following WARN when resuming:
[ 425.208983] ------------[ cut here ]------------
[ 425.208990] WARNING: CPU: 0 PID: 6828 at drivers/gpu/drm/drm_edid.c:3555 drm_select_eld+0xa5/0xd0()
[ 425.209015] Modules linked in: pl2303 usbserial snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic intel_powerclamp coretemp i915 crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_intel snd_hda_codec snd_hwdep lpc_ich snd_hda_core snd_pcm i2c_hid i2c_designware_platform i2c_designware_core r8169 mii sdhci_acpi sdhci mmc_core
[ 425.209018] CPU: 0 PID: 6828 Comm: kworker/u4:5 Tainted: G U W 4.5.0-rc4-gfxbench+ #1
[ 425.209020] Hardware name: \xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff \xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff/DN2820FYK, BIOS FYBYT10H.86A.0038.2014.0717.1455 07/17/2014
[ 425.209027] Workqueue: events_unbound async_run_entry_fn
[ 425.209032] 0000000000000000 ffff880072433958 ffffffff813f6b05 0000000000000000
[ 425.209036] ffffffff81aaef2d ffff880072433990 ffffffff81078291 ffff880036b933d8
[ 425.209039] ffff88006d528000 ffff88006d52b3d8 ffff88006d52b3d8 ffff88007315b6f8
[ 425.209040] Call Trace:
[ 425.209045] [<ffffffff813f6b05>] dump_stack+0x67/0x92
[ 425.209049] [<ffffffff81078291>] warn_slowpath_common+0x81/0xc0
[ 425.209052] [<ffffffff81078385>] warn_slowpath_null+0x15/0x20
[ 425.209054] [<ffffffff8151e195>] drm_select_eld+0xa5/0xd0
[ 425.209101] [<ffffffffa01f34f4>] intel_audio_codec_enable+0x44/0x160 [i915]
[ 425.209135] [<ffffffffa023eac7>] intel_enable_hdmi_audio+0x87/0x90 [i915]
[ 425.209169] [<ffffffffa023eb5a>] g4x_enable_hdmi+0x8a/0xa0 [i915]
[ 425.209202] [<ffffffffa023f41b>] vlv_hdmi_pre_enable+0x1cb/0x240 [i915]
[ 425.209236] [<ffffffffa020edcf>] valleyview_crtc_enable+0x10f/0x290 [i915]
[ 425.209270] [<ffffffffa020ba49>] intel_atomic_commit+0x769/0x17a0 [i915]
[ 425.209274] [<ffffffff81526ad5>] ? drm_atomic_check_only+0x145/0x660
[ 425.209276] [<ffffffff81527022>] drm_atomic_commit+0x32/0x50
[ 425.209310] [<ffffffffa0215fa0>] intel_display_resume+0xa0/0x130 [i915]
[ 425.209338] [<ffffffffa018c1bb>] i915_drm_resume+0xcb/0x160 [i915]
[ 425.209366] [<ffffffffa018c272>] i915_pm_resume+0x22/0x30 [i915]
[ 425.209370] [<ffffffff8143d91e>] pci_pm_resume+0x6e/0xe0
[ 425.209373] [<ffffffff8143d8b0>] ? pci_pm_resume_noirq+0xa0/0xa0
[ 425.209375] [<ffffffff815409ae>] dpm_run_callback+0x6e/0x280
[ 425.209378] [<ffffffff815410b2>] device_resume+0x92/0x250
[ 425.209380] [<ffffffff81541288>] async_resume+0x18/0x40
[ 425.209382] [<ffffffff8109c7a5>] async_run_entry_fn+0x45/0x140
[ 425.209386] [<ffffffff81093293>] process_one_work+0x1e3/0x620
[ 425.209388] [<ffffffff810931f7>] ? process_one_work+0x147/0x620
[ 425.209391] [<ffffffff81093719>] worker_thread+0x49/0x490
[ 425.209393] [<ffffffff810936d0>] ? process_one_work+0x620/0x620
[ 425.209396] [<ffffffff81099e0a>] kthread+0xea/0x100
[ 425.209400] [<ffffffff81099d20>] ? kthread_create_on_node+0x1f0/0x1f0
[ 425.209404] [<ffffffff817ba03f>] ret_from_fork+0x3f/0x70
[ 425.209407] [<ffffffff81099d20>] ? kthread_create_on_node+0x1f0/0x1f0
[ 425.209409] ---[ end trace d1b247107f34a8b2 ]---
Fixes: e2c8b8701e2d ("drm/i915: Use atomic helpers for suspend, v2.")
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1455632862-18557-1-git-send-email-maarten.lankhorst@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
The present unix_stream_read_generic contains various code sequences of
the form
err = -EDISASTER;
if (<test>)
goto out;
This has the unfortunate side effect of possibly causing the error code
to bleed through to the final
out:
return copied ? : err;
and then to be wrongly returned if no data was copied because the caller
didn't supply a data buffer, as demonstrated by the program available at
http://pad.lv/1540731
Change it such that err is only set if an error condition was detected.
Fixes: 3822b5c2fc62 ("af_unix: Revert 'lock_interruptible' in stream receive code")
Reported-by: Joseph Salisbury <joseph.salisbury@canonical.com>
Signed-off-by: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Pull IOMMU SVM fixes from David Woodhouse:
"Minor register size and interrupt acknowledgement fixes which only
showed up in testing on newer hardware, but mostly a fix to the MM
refcount handling to prevent a recursive refcount issue when mmap() is
used on the file descriptor associated with a bound PASID"
* tag 'for-linus-20160216' of git://git.infradead.org/intel-iommu:
iommu/vt-d: Clear PPR bit to ensure we get more page request interrupts
iommu/vt-d: Fix 64-bit accesses to 32-bit DMAR_GSTS_REG
iommu/vt-d: Fix mm refcounting to hold mm_count not mm_users
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes
These are a few fixes for the current cycle.
3 out of the 5 patches fix a bugzilla.
* fix a race that users reported when we try to load the firmware
and the hardware rfkill interrupt triggers at the same time.
* Luca fixes a very visible bug in scheduled scan: our firmware
doesn't support scheduled scan with no profile configured and
the supplicant sometimes requests such scheduled scans.
* build system fix
* firmware name update for 8265
* typo fix in return value
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi into x86/urgent
Pull EFI bug fixes from Matt Fleming:
* Fix bugs in our code that converts ucs2 strings to utf8 where we
unintentionally drop bits from the original string (Jason Andryuk)
* Add the efi-pstore variables to the variable whitelist so that
users can continue to delete them via efivarfs without needing to
manipulate the immutable flag (Matt Fleming)
Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
Pull spi fixes from Mark Brown:
"A small clutch of driver specific fixes.
The OMAP one is a bit worrying since it seems to be triggered by some
changes in the runtime PM core code and I suspect there's other
drivers across that are going to be using the same pattern outside of
OMAP but nothing seems to be coming up in the testing people are
doing"
* tag 'spi-fix-v4.5-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
spi: omap2-mcspi: Fix PM regression with deferred probe for pm_runtime_reinit
spi: bcm2835aux: fix bitmask defines
spi: atmel: fix gpio chip-select in case of non-DT platform
spi/fsl-espi: Correct the maximum transaction length
spi: imx: fix spi resource leak with dma transfer
spi: fix counting in spi-loopback-test code
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k
Pull m68k fixes from Geert Uytterhoeven:
"Summary:
- Wire up new copy_file_range syscall
- Update defconfigs"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k:
m68k/defconfig: Update defconfigs for v4.5-rc1
m68k: Wire up copy_file_range
|
|
We need to use post-decrement to get the pci_map_page undone also for
i==0, and to avoid some very unpleasant behaviour if pci_map_page
failed already at i==0.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
|
|
We need to use post-decrement to get the pci_map_page undone also for
i==0, and to avoid some very unpleasant behaviour if pci_map_page
failed already at i==0.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
|
|
This patch set nukes all the dummy crtc mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by: Carlos Palminha <palminha@synopsys.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/9d41105dee6632b4bb50e9555f2196ac249b9fce.1455630967.git.palminha@synopsys.com
|
|
mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha@synopsys.com
This patch set nukes all the dummy mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by: Carlos Palminha <palminha@synopsys.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/4d838f580cf81068a4df2500a096d66f06f3ad37.1455540137.git.palminha@synopsys.com
|
|
mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha@synopsys.com
This patch set nukes all the dummy mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by: Carlos Palminha <palminha@synopsys.com>
Acked-by: Vincent Abriou <vincent.abriou@st.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/7f47c6a7b00e4f16af672ebf3a277e31ad117e21.1455540137.git.palminha@synopsys.com
|
|
mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha@synopsys.com
This patch set nukes all the dummy mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by: Carlos Palminha <palminha@synopsys.com>
Acked-by: Mark Yao <mark.yao@rock-chips.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/cae559aa2c04a906c21ed5ebe4861f92440e6910.1455540137.git.palminha@synopsys.com
|
|
mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha@synopsys.com
This patch set nukes all the dummy mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by: Carlos Palminha <palminha@synopsys.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/f35bc322f7af69ba0fea734d58b4daf5e0cd9786.1455540137.git.palminha@synopsys.com
|
|
mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha@synopsys.com
This patch set nukes all the dummy mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by: Carlos Palminha <palminha@synopsys.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/c5852d59a8890c3570ce97d16c0714a71eb61651.1455540137.git.palminha@synopsys.com
|
|
mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha@synopsys.com
This patch set nukes all the dummy mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by: Carlos Palminha <palminha@synopsys.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/77692d9d34c2ed6a035f36d377d3544dbe100114.1455540137.git.palminha@synopsys.com
|
|
mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha@synopsys.com
This patch set nukes all the dummy mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by: Carlos Palminha <palminha@synopsys.com>
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/8bf274e8f6908142a9f940d3f2913e4a735e0caa.1455540137.git.palminha@synopsys.com
|
|
mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha@synopsys.com
This patch set nukes all the dummy mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by: Carlos Palminha <palminha@synopsys.com>
Reviewed-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/b704458dc68a73cfb5507933c1df0c2a79e186eb.1455540137.git.palminha@synopsys.com
|
|
mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha@synopsys.com
This patch set nukes all the dummy mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by: Carlos Palminha <palminha@synopsys.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1b99680b8cf81977597dec5daedff9b684d3ed19.1455540137.git.palminha@synopsys.com
|
|
mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha@synopsys.com
This patch set nukes all the dummy mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by: Carlos Palminha <palminha@synopsys.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/a53767402bd4a69c3d2a546b7f4d4d122134b545.1455540137.git.palminha@synopsys.com
|
|
mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha@synopsys.com
This patch set nukes all the dummy mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by: Carlos Palminha <palminha@synopsys.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/d8b87edea28c8211e1711348143e4c355764a8c4.1455540137.git.palminha@synopsys.com
|
|
mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha@synopsys.com
This patch set nukes all the dummy mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by: Carlos Palminha <palminha@synopsys.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/12e1e900724c890166b88b0f4d67baba387482af.1455540137.git.palminha@synopsys.com
|
|
mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha@synopsys.com
This patch set nukes all the dummy mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by: Carlos Palminha <palminha@synopsys.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/8c4710ee930d2ab3a505b8d3cd724f4f4c79b3df.1455540137.git.palminha@synopsys.com
|
|
mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha@synopsys.com
This patch set nukes all the dummy mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by: Carlos Palminha <palminha@synopsys.com>
[danvet: Squash in 2nd exynos patch.]
Link: http://patchwork.freedesktop.org/patch/msgid/3768b670931572de51fca1102efa18d20dd770ee.1455540137.git.palminha@synopsys.com
Link: http://patchwork.freedesktop.org/patch/msgid/4906a9925eebbe55489b1005c449b426a61c09bd.1455540137.git.palminha@synopsys.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha@synopsys.com
This patch set nukes all the dummy mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by: Carlos Palminha <palminha@synopsys.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/a7ebfb6c6c333056d0a77d2684c539107ee63589.1455540137.git.palminha@synopsys.com
|
|
mode_fixup function for encoder drivers became optional with patch
http://patchwork.freedesktop.org/patch/msgid/1455106522-32307-1-git-send-email-palminha@synopsys.com
This patch set nukes all the dummy mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by: Carlos Palminha <palminha@synopsys.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/85230bc1356eb52257aaa1e1965adae2f00db5cd.1455540137.git.palminha@synopsys.com
|
|
batman-adv checks in different situation if a new device is already on top
of a different batman-adv device. This is done by getting the iflink of a
device and all its parent. It assumes that this iflink is always a parent
device in an acyclic graph. But this assumption is broken by devices like
veth which are actually a pair of two devices linked to each other. The
recursive check would therefore get veth0 when calling dev_get_iflink on
veth1. And it gets veth0 when calling dev_get_iflink with veth1.
Creating a veth pair and loading batman-adv freezes parts of the system
ip link add veth0 type veth peer name veth1
modprobe batman-adv
An RCU stall will be detected on the system which cannot be fixed.
INFO: rcu_sched self-detected stall on CPU
1: (5264 ticks this GP) idle=3e9/140000000000001/0
softirq=144683/144686 fqs=5249
(t=5250 jiffies g=46 c=45 q=43)
Task dump for CPU 1:
insmod R running task 0 247 245 0x00000008
ffffffff8151f140 ffffffff8107888e ffff88000fd141c0 ffffffff8151f140
0000000000000000 ffffffff81552df0 ffffffff8107b420 0000000000000001
ffff88000e3fa700 ffffffff81540b00 ffffffff8107d667 0000000000000001
Call Trace:
<IRQ> [<ffffffff8107888e>] ? rcu_dump_cpu_stacks+0x7e/0xd0
[<ffffffff8107b420>] ? rcu_check_callbacks+0x3f0/0x6b0
[<ffffffff8107d667>] ? hrtimer_run_queues+0x47/0x180
[<ffffffff8107cf9d>] ? update_process_times+0x2d/0x50
[<ffffffff810873fb>] ? tick_handle_periodic+0x1b/0x60
[<ffffffff810290ae>] ? smp_trace_apic_timer_interrupt+0x5e/0x90
[<ffffffff813bbae2>] ? apic_timer_interrupt+0x82/0x90
<EOI> [<ffffffff812c3fd7>] ? __dev_get_by_index+0x37/0x40
[<ffffffffa0031f3e>] ? batadv_hard_if_event+0xee/0x3a0 [batman_adv]
[<ffffffff812c5801>] ? register_netdevice_notifier+0x81/0x1a0
[...]
This can be avoided by checking if two devices are each others parent and
stopping the check in this situation.
Fixes: b7eddd0b3950 ("batman-adv: prevent using any virtual device created on batman-adv as hard-interface")
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
[sven@narfation.org: rewritten description, extracted fix]
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
Signed-off-by: Antonio Quartulli <a@unstable.cc>
|
|
The commit [7f0973e973cd: ALSA: seq: Fix lockdep warnings due to
double mutex locks] split the management of two linked lists (source
and destination) into two individual calls for avoiding the AB/BA
deadlock. However, this may leave the possible double deletion of one
of two lists when the counterpart is being deleted concurrently.
It ends up with a list corruption, as revealed by syzkaller fuzzer.
This patch fixes it by checking the list emptiness and skipping the
deletion and the following process.
BugLink: http://lkml.kernel.org/r/CACT4Y+bay9qsrz6dQu31EcGaH9XwfW7o3oBzSQUG9fMszoh=Sg@mail.gmail.com
Fixes: 7f0973e973cd ('ALSA: seq: Fix lockdep warnings due to 'double mutex locks)
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Tested-by: Dmitry Vyukov <dvyukov@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The comparisons should be >= since 0x800 and 0x80 require an additional bit
to store.
For the 3 byte case, the existing shift would drop off 2 more bits than
intended.
For the 2 byte case, there should be 5 bits bits in byte 1, and 6 bits in
byte 2.
Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Cc: Peter Jones <pjones@redhat.com>
Cc: Matthew Garrett <mjg59@coreos.com>
Cc: "Lee, Chun-Yi" <jlee@suse.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
|
|
Laszlo explains why this is a good idea,
'This is because the pstore filesystem can be backed by UEFI variables,
and (for example) a crash might dump the last kilobytes of the dmesg
into a number of pstore entries, each entry backed by a separate UEFI
variable in the above GUID namespace, and with a variable name
according to the above pattern.
Please see "drivers/firmware/efi/efi-pstore.c".
While this patch series will not prevent the user from deleting those
UEFI variables via the pstore filesystem (i.e., deleting a pstore fs
entry will continue to delete the backing UEFI variable), I think it
would be nice to preserve the possibility for the sysadmin to delete
Linux-created UEFI variables that carry portions of the crash log,
*without* having to mount the pstore filesystem.'
There's also no chance of causing machines to become bricked by
deleting these variables, which is the whole purpose of excluding
things from the whitelist.
Use the LINUX_EFI_CRASH_GUID guid and a wildcard '*' for the match so
that we don't have to update the string in the future if new variable
name formats are created for crash dump variables.
Reported-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Peter Jones <pjones@redhat.com>
Tested-by: Peter Jones <pjones@redhat.com>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: "Lee, Chun-Yi" <jlee@suse.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
|
