Age | Commit message (Collapse) | Author | Files | Lines |
|
Properly double the hdisplay/vdisplay timings that we use as the primary
plane size with stereo doubled modes. Otherwise the modeset gets
rejected on machines where the primary plane must be fullscreen, and on
the rest only the first eye would get a visible plane.
Cc: Daniel Vetter <[email protected]>
Cc: [email protected] #v3.19+
Fixes: 042652ed9599 ("drm/atomic-helper: implementatations for legacy interfaces")
Signed-off-by: Ville Syrjälä <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Testcase: igt/kms_3d
Signed-off-by: Daniel Vetter <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
|
|
If an atomic update fails intel_crtc->atomic may have have some values left
from the last atomic check. One example is atomic->wait_for_vblank,
which results in spurious errors in kms_flip.
[ 1551.892708] ------------[ cut here ]------------
[ 1551.892721] WARNING: CPU: 3 PID: 4179 at ../drivers/gpu/drm/drm_irq.c:1199 drm_wait_one_vblank+0x197/0x1a0 [drm]()
[ 1551.892722] vblank not available on crtc 2, ret=-22
[ 1551.892751] Modules linked in: snd_hda_intel i915 drm_kms_helper drm
intel_gtt i2c_algo_bit cfbfillrect syscopyarea cfbimgblt sysfillrect
sysimgblt fb_sys_fops cfbcopyarea agpgart cfg80211 binfmt_misc
snd_hda_codec_hdmi intel_rapl iosf_mbi x86_pkg_temp_thermal coretemp
kvm_intel snd_hda_codec_realtek kvm snd_hda_codec_generic iTCO_wdt
aesni_intel aes_x86_64 glue_helper lrw snd_hda_codec gf128mul
ablk_helper cryptd snd_hwdep psmouse snd_hda_core pcspkr snd_pcm
snd_timer snd lpc_ich i2c_i801 mfd_core soundcore wmi evdev [last
unloaded: drm]
[ 1551.892753] CPU: 3 PID: 4179 Comm: kms_pipe_crc_ba Tainted: G U W 4.3.0-reg+ #6
[ 1551.892754] Hardware name: /DZ77BH-55K, BIOS BHZ7710H.86A.0100.2013.0517.0942 05/17/2013
[ 1551.892758] ffffffffa03128d8 ffff8800cec73890 ffffffff812c0f3c ffff8800cec738d8
[ 1551.892760] ffff8800cec738c8 ffffffff8104ff36 ffff880116ae2290 0000000000000002
[ 1551.892762] ffff8800d39fcda0 ffff8800d038b4d0 ffff8800d42b5550 ffff8800cec73928
[ 1551.892763] Call Trace:
[ 1551.892768] [<ffffffff812c0f3c>] dump_stack+0x4e/0x82
[ 1551.892771] [<ffffffff8104ff36>] warn_slowpath_common+0x86/0xc0
[ 1551.892773] [<ffffffff8104ffbc>] warn_slowpath_fmt+0x4c/0x50
[ 1551.892781] [<ffffffffa02e6708>] ? drm_vblank_get+0x78/0xd0 [drm]
[ 1551.892787] [<ffffffffa02e6d47>] drm_wait_one_vblank+0x197/0x1a0 [drm]
[ 1551.892813] [<ffffffffa03d052f>] intel_post_plane_update+0xef/0x120 [i915]
[ 1551.892832] [<ffffffffa03d11d2>] intel_atomic_commit+0x4c2/0x1600 [i915]
[ 1551.892862] [<ffffffffa02ff0c7>] ? drm_atomic_check_only+0x147/0x5e0 [drm]
[ 1551.892872] [<ffffffffa02feeb7>] ? drm_atomic_add_affected_connectors+0x27/0xf0 [drm]
[ 1551.892881] [<ffffffffa02ff597>] drm_atomic_commit+0x37/0x60 [drm]
[ 1551.892887] [<ffffffffa034301a>] restore_fbdev_mode+0x28a/0x2c0 [drm_kms_helper]
[ 1551.892895] [<ffffffffa0345253>] drm_fb_helper_restore_fbdev_mode_unlocked+0x33/0x80 [drm_kms_helper]
[ 1551.892900] [<ffffffffa03452cd>] drm_fb_helper_set_par+0x2d/0x50 [drm_kms_helper]
[ 1551.892920] [<ffffffffa03e7a9a>] intel_fbdev_set_par+0x1a/0x60 [i915]
[ 1551.892923] [<ffffffff8131a5a7>] fb_set_var+0x1a7/0x3f0
[ 1551.892927] [<ffffffff8109732f>] ? trace_hardirqs_on_caller+0x12f/0x1c0
[ 1551.892931] [<ffffffff81314f32>] fbcon_blank+0x212/0x2f0
[ 1551.892935] [<ffffffff81373f4a>] do_unblank_screen+0xba/0x1d0
[ 1551.892937] [<ffffffff8136b725>] vt_ioctl+0x13d5/0x1450
[ 1551.892940] [<ffffffff8107cdd1>] ? preempt_count_sub+0x41/0x50
[ 1551.892943] [<ffffffff8135d8a3>] tty_ioctl+0x423/0xe30
[ 1551.892947] [<ffffffff8119f721>] do_vfs_ioctl+0x301/0x560
[ 1551.892949] [<ffffffff8119b1e3>] ? putname+0x53/0x60
[ 1551.892952] [<ffffffff811ab376>] ? __fget_light+0x66/0x90
[ 1551.892955] [<ffffffff8119f9f9>] SyS_ioctl+0x79/0x90
[ 1551.892958] [<ffffffff81552e97>] entry_SYSCALL_64_fastpath+0x12/0x6f
[ 1551.892961] ---[ end trace 3e764d4b6628c91c ]---
Testcase: kms_flip
Reported-and-tested-by: Ville Syrjälä <[email protected]>
Cc: [email protected] #v4.3
Signed-off-by: Maarten Lankhorst <[email protected]>
Reviewed-by: Daniel Stone <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
When using EOImode==1, we may mark interrupts as being forwarded
to a virtual machine. In that case, the interrupt is left active
while being passed to the VM.
If we suspend the system before the VM has deactivated the interrupt,
the active state will be lost (which may be very annoying, as this
may result in spurious interrupts and a confused guest).
To avoid this, save and restore the active state together with the
rest of the GIC registers.
Signed-off-by: Marc Zyngier <[email protected]>
Cc: <[email protected]>
Cc: Jason Cooper <[email protected]>
Cc: Russell King <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Thomas Gleixner <[email protected]>
|
|
When restoring the GIC state (after a suspend/resume cycle,
for example), the driver directly writes the 'enabled' state
it has saved by accessing GICD_ISENABLERn, which performs
an OR operation between the value present in the register
and the value we write.
If whatever code that has run before we reentered the kernel
has enabled an interrupt that was previously disabled, we won't
restore that disabled state.
Making sure we first clear the register (by writting to
GICD_ICENABLERn) before restoring the enabled state.
Signed-off-by: Marc Zyngier <[email protected]>
Cc: <[email protected]>
Cc: Jason Cooper <[email protected]>
Cc: Russell King <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Thomas Gleixner <[email protected]>
|
|
When booting a GIC/GICv3 based system, we have no idea what
state the firmware (or previous kernel in the case of kexec)
has left the GIC, and some interrupts may still be active.
In order to garantee that we have a clean state, make sure
the active bits are cleared at init time.
Signed-off-by: Marc Zyngier <[email protected]>
Cc: <[email protected]>
Cc: Jason Cooper <[email protected]>
Cc: Russell King <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Thomas Gleixner <[email protected]>
|
|
including ptrace.h brings a definition of BITS_PER_PAGE into device
drivers and cause a build warning in allmodconfig builds:
drivers/block/drbd/drbd_bitmap.c:482:0: warning: "BITS_PER_PAGE" redefined
#define BITS_PER_PAGE (1UL << (PAGE_SHIFT + 3))
This uses a slightly different way to express current_pt_regs()
that avoids the use of the header and gets away with the already
included asm/ptrace.h.
Signed-off-by: Arnd Bergmann <[email protected]>
Signed-off-by: Catalin Marinas <[email protected]>
|
|
Including linux/acpi.h from asm/dma-mapping.h causes tons of compile-time
warnings, e.g.
drivers/isdn/mISDN/dsp_ecdis.h:43:0: warning: "FALSE" redefined
drivers/isdn/mISDN/dsp_ecdis.h:44:0: warning: "TRUE" redefined
drivers/net/fddi/skfp/h/targetos.h:62:0: warning: "TRUE" redefined
drivers/net/fddi/skfp/h/targetos.h:63:0: warning: "FALSE" redefined
However, it looks like the dependency should not even there as
I do not see why __generic_dma_ops() cares about whether we have
an ACPI based system or not.
The current behavior is to fall back to the global dma_ops when
a device has not set its own dma_ops, but only for DT based systems.
This seems dangerous, as a random device might have different
requirements regarding IOMMU or coherency, so we should really
never have that fallback and just forbid DMA when we have not
initialized DMA for a device.
This removes the global dma_ops variable and the special-casing
for ACPI, and just returns the dma ops that got set for the
device, or the dummy_dma_ops if none were present.
The original code has apparently been copied from arm32 where we
rely on it for ISA devices things like the floppy controller, but
we should have no such devices on ARM64.
Signed-off-by: Arnd Bergmann <[email protected]>
[[email protected]: removed acpi_disabled check in arch_setup_dma_ops()]
Signed-off-by: Catalin Marinas <[email protected]>
|
|
When booting a 64k pages kernel that is built with CONFIG_DEBUG_RODATA
and resides at an offset that is not a multiple of 512 MB, the rounding
that occurs in __map_memblock() and fixup_executable() results in
incorrect regions being mapped.
The following snippet from /sys/kernel/debug/kernel_page_tables shows
how, when the kernel is loaded 2 MB above the base of DRAM at 0x40000000,
the first 2 MB of memory (which may be inaccessible from non-secure EL1
or just reserved by the firmware) is inadvertently mapped into the end of
the module region.
---[ Modules start ]---
0xfffffdffffe00000-0xfffffe0000000000 2M RW NX ... UXN MEM/NORMAL
---[ Modules end ]---
---[ Kernel Mapping ]---
0xfffffe0000000000-0xfffffe0000090000 576K RW NX ... UXN MEM/NORMAL
0xfffffe0000090000-0xfffffe0000200000 1472K ro x ... UXN MEM/NORMAL
0xfffffe0000200000-0xfffffe0000800000 6M ro x ... UXN MEM/NORMAL
0xfffffe0000800000-0xfffffe0000810000 64K ro x ... UXN MEM/NORMAL
0xfffffe0000810000-0xfffffe0000a00000 1984K RW NX ... UXN MEM/NORMAL
0xfffffe0000a00000-0xfffffe00ffe00000 4084M RW NX ... UXN MEM/NORMAL
The same issue is likely to occur on 16k pages kernels whose load
address is not a multiple of 32 MB (i.e., SECTION_SIZE). So round to
SWAPPER_BLOCK_SIZE instead of SECTION_SIZE.
Fixes: da141706aea5 ("arm64: add better page protections to arm64")
Signed-off-by: Ard Biesheuvel <[email protected]>
Acked-by: Mark Rutland <[email protected]>
Acked-by: Laura Abbott <[email protected]>
Cc: <[email protected]> # 4.0+
Signed-off-by: Catalin Marinas <[email protected]>
|
|
Don't touch plane->old_fb/fb without having the right locks held.
Signed-off-by: Maarten Lankhorst <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Don't touch plane->old_fb/fb without having the right locks held.
Signed-off-by: Maarten Lankhorst <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
This is useful for all the boilerplate code about cleaning old_fb.
Signed-off-by: Maarten Lankhorst <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
plane_mask should be cleared inside the retry loop, because it gets
reset on every retry. Without this fix the plane->fb refcounting might
get out of sync on retries, resulting in either leaked memory or
use-after-free.
Signed-off-by: Maarten Lankhorst <[email protected]>
Cc: [email protected] #v4.3
Reviewed-by: Daniel Vetter <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
legacy_cursor_update was being set in restore_fbdev_mode_atomic which was
probably unintended. Fix this by only setting it in the function that needs it.
This oversight was introduced in
commit bbb1e52402b2a288b09ae37e8182599931c7e9df
Author: Rob Clark <[email protected]>
Date: Tue Aug 25 15:35:58 2015 -0400
drm/fb-helper: atomic restore_fbdev_mode()...
Signed-off-by: Maarten Lankhorst <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
[Jani: checkpatch fix]
Signed-off-by: Jani Nikula <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
While dax pmd mappings are functional in the nominal path they trigger
kernel crashes in the following paths:
BUG: unable to handle kernel paging request at ffffea0004098000
IP: [<ffffffff812362f7>] follow_trans_huge_pmd+0x117/0x3b0
[..]
Call Trace:
[<ffffffff811f6573>] follow_page_mask+0x2d3/0x380
[<ffffffff811f6708>] __get_user_pages+0xe8/0x6f0
[<ffffffff811f7045>] get_user_pages_unlocked+0x165/0x1e0
[<ffffffff8106f5b1>] get_user_pages_fast+0xa1/0x1b0
kernel BUG at arch/x86/mm/gup.c:131!
[..]
Call Trace:
[<ffffffff8106f34c>] gup_pud_range+0x1bc/0x220
[<ffffffff8106f634>] get_user_pages_fast+0x124/0x1b0
BUG: unable to handle kernel paging request at ffffea0004088000
IP: [<ffffffff81235f49>] copy_huge_pmd+0x159/0x350
[..]
Call Trace:
[<ffffffff811fad3c>] copy_page_range+0x34c/0x9f0
[<ffffffff810a0daf>] copy_process+0x1b7f/0x1e10
[<ffffffff810a11c1>] _do_fork+0x91/0x590
All of these paths are interpreting a dax pmd mapping as a transparent
huge page and making the assumption that the pfn is covered by the
memmap, i.e. that the pfn has an associated struct page. PTE mappings
do not suffer the same fate since they have the _PAGE_SPECIAL flag to
cause the gup path to fault. We can do something similar for the PMD
path, or otherwise defer pmd support for cases where a struct page is
available. For now, 4.4-rc and -stable need to disable dax pmd support
by default.
For development the "depends on BROKEN" line can be removed from
CONFIG_FS_DAX_PMD.
Cc: <[email protected]>
Cc: Jan Kara <[email protected]>
Cc: Dave Chinner <[email protected]>
Cc: Matthew Wilcox <[email protected]>
Cc: Kirill A. Shutemov <[email protected]>
Reported-by: Ross Zwisler <[email protected]>
Signed-off-by: Dan Williams <[email protected]>
|
|
Signed-off-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: David Howells <[email protected]>
Signed-off-by: Al Viro <[email protected]>
|
|
fs/cachefiles/rdwr.c: In function ‘cachefiles_write_page’:
fs/cachefiles/rdwr.c:882: warning: ‘ret’ may be used uninitialized in
this function
If the jump to label "error" is taken, "ret" will indeed be
uninitialized, and random stack data may be printed by the debug code.
Fixes: 102f4d900c9c8f5e ("FS-Cache: Handle a write to the page immediately beyond the EOF marker")
Signed-off-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: David Howells <[email protected]>
Signed-off-by: Al Viro <[email protected]>
|
|
The Broadcom NAND driver is used by many different groups at Broadcom
now, so use the same mailing-list we use for other areas of the kernel.
Signed-off-by: Florian Fainelli <[email protected]>
Signed-off-by: Brian Norris <[email protected]>
|
|
Given that INTUOSHT < BAMBOO_PT
features->type >= INTUOSHT || features->type <= BAMBOO_PT
condition is always true, and therefore device_type is under certain
circumstances wrongly set with WACOM_DEVICETYPE_PAD bit set.
Fix the condition so that it actually represents the range as intended.
Reported-by: David Binderman <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>
|
|
The acpi_ec_delete_query() function tests whether its argument is NULL
and then returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <[email protected]>
[ rjw: Subject ]
Signed-off-by: Rafael J. Wysocki <[email protected]>
|
|
Revert commit 3349fb64b292 (ACPI / SBS: Add 5 us delay to fix SBS
hangs on MacBook), since the delay introduced by it is not necessary
any more after commit add68d6aa9e2 (ACPI / SMBus: Fix boot stalls /
high CPU caused by reentrant code).
Signed-off-by: Chris Bainbridge <[email protected]>
[ rjw: Changelog ]
Signed-off-by: Rafael J. Wysocki <[email protected]>
|
|
In the SBS initialisation, a reentrant call to wait_event_timeout()
causes an intermittent boot stall of several minutes usually following
the "Switching to clocksource tsc" message. Another symptom of this bug
is high CPU usage from programs (Firefox, upowerd) querying the battery
state. This is caused by:
1. drivers/acpi/sbshc.c wait_transaction_complete() calls
wait_event_timeout():
if (wait_event_timeout(hc->wait, smb_check_done(hc),
msecs_to_jiffies(timeout)))
2. ___wait_event sets task state to uninterruptible
3. ___wait_event calls the "condition" smb_check_done()
4. smb_check_done (sbshc.c) calls through to ec_read() in
drivers/acpi/ec.c
5. ec_guard() is reached which calls wait_event_timeout()
if (wait_event_timeout(ec->wait,
ec_transaction_completed(ec),
guard))
ie. wait_event_timeout() is being called again inside evaluation of
the previous wait_event_timeout() condition
5. The EC IRQ handler calls wake_up() and wakes up the sleeping task in
ec_guard()
6. The task is now in state running even though the wait "condition" is
still being evaluated
7. The "condition" check returns false so ___wait_event calls
schedule_timeout()
8. Since the task state is running, the scheduler immediately schedules
it again
9. This loop usually repeats for around 250 seconds even though the
original wait_event_timeout was only 1000ms.
The timeout is incorrect because each call to schedule_timeout()
usually returns immediately, taking less than 1ms, so the jiffies
timeout counter is not decremented. The task is now stuck in a
running state, and so is highly likely to be immediately
rescheduled, which takes less than a jiffy. The loop will never exit
if all schedule_timeout() calls take less than a jiffy.
Fix this by replacing SMBus reads in the wait_event_timeout condition
with checks of a boolean value that is updated by the EC query handler.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=107191
Link: https://lkml.org/lkml/2015/11/6/776
Signed-off-by: Chris Bainbridge <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
|
|
Now that IP1000A chips are supported by dl2k driver, the buggy ipg
driver can be removed.
Signed-off-by: Ondrej Zary <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Add support for IP1000A chips to dl2k driver.
IP1000A chip looks like a TC9020 with integrated PHY.
This allows IP1000A chips to work reliably because the ipg driver is
buggy - it loses packets under load and then completely stops
transmitting data.
Tested with Asus NX1101 v2.0 at 10, 100 and 1000Mbps:
vendor=0x13f0 device=0x1023 (rev 0x41)
subsystem vendor=0x1043 device=0x8180
MAC address registers access needed to be changed from 8-bit to 16-bit
because 8-bit does not work on IP1000A. 8-bit access is not even
allowed in the TC9020 datasheet (although it worked). 16-bit access
works on both.
Tested that it does not break D-Link DGE-550T (DL-2000 chip, probably
a rebranded TC9020):
vendor=0x1186 device=0x4000 (rev 0x0c)
subsystem vendor=0x1186 device=0x4000
Signed-off-by: Ondrej Zary <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Check that IRQ number passed to dev_pm_set_wake_irq() and
dev_pm_set_dedicated_wake_irq() is valid (not negative) before
accepting it.
Signed-off-by: Dmitry Torokhov <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
|
|
Signed-off-by: Junwei Zhang <[email protected]>
Reviewed-by: Christian König <[email protected]>
|
|
Otherwise debugging locked up processes isn't possible.
v2: rebased
Signed-off-by: Christian König <[email protected]>
Reviewed-by: Alex Deucher <[email protected]> (v1)
|
|
* pm-tools:
x86: remove unused definition of MSR_NHM_PLATFORM_INFO
tools/power turbostat: use new name for MSR_PLATFORM_INFO
|
|
the OUTMCAST stat is double incremented, getting bumped once in the mcast code
itself, and again in the common ip output path. Remove the mcast bump, as its
not needed
Validated by the reporter, with good results
Signed-off-by: Neil Horman <[email protected]>
Reported-by: Claus Jensen <[email protected]>
CC: Claus Jensen <[email protected]>
CC: David Miller <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
In some cases the crash is caused by nicvf_remove() being called from
outside. For example, if we try to feed the device to vfio after the
probe has failed for some reason. So, move the check to better place.
Signed-off-by: Pavel Fedin <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
A recent flaw in the netdev feature setting resulted in warnings
like this one from VLAN interfaces:
WARNING: CPU: 1 PID: 4975 at net/core/dev.c:2419 skb_warn_bad_offload+0xbc/0xcb()
: caps=(0x00000000001b5820, 0x00000000001b5829) len=2782 data_len=0 gso_size=1348 gso_type=16 ip_summed=3
The ":" is supposed to be preceded by a driver name, but in this
case it is an empty string since the device has no parent.
There are many types of network devices without a parent. The
anonymous warnings for these devices can be hard to debug. Log
the network device name instead in these cases to assist further
debugging.
This is mostly similar to how __netdev_printk() handles orphan
devices.
Signed-off-by: Bjørn Mork <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
In case multiple writes to a unix stream socket race we could end up in a
situation where we pre-allocate a new skb for use in unix_stream_sendpage
but have to free it again in the locked section because another skb
has been appended meanwhile, which we must use. Accidentally we didn't
clear the pointer after consuming it and so we touched freed memory
while appending it to the sk_receive_queue. So, clear the pointer after
consuming the skb.
This bug has been found with syzkaller
(http://github.com/google/syzkaller) by Dmitry Vyukov.
Fixes: 869e7c62486e ("net: af_unix: implement stream sendpage support")
Reported-by: Dmitry Vyukov <[email protected]>
Cc: Dmitry Vyukov <[email protected]>
Cc: Eric Dumazet <[email protected]>
Signed-off-by: Hannes Frederic Sowa <[email protected]>
Acked-by: Eric Dumazet <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
rtnl_fdb_dump always expects an index to be returned by the ndo_fdb_dump op,
but when CONFIG_NET_SWITCHDEV is off, it returns an error.
Fix that by returning the given unmodified idx.
A similar fix was 0890cf6cb6ab ("switchdev: fix return value of
switchdev_port_fdb_dump in case of error") but for the CONFIG_NET_SWITCHDEV=y
case.
Fixes: 45d4122ca7cd ("switchdev: add support for fdb add/del/dump via switchdev_port_obj ops.")
Signed-off-by: Dragos Tatulea <[email protected]>
Acked-by: Jiri Pirko <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Commit 05cc5a39ddb7 "bnx2x: add vlan filtering offload" introduced
a regression in regard for vlans for 57710, 57711 adapters -
Loading 8021q module on a machine with such an adapter would cause
a null pointer dereference, as the driver mistakenly publishes it
has capabilities for vlan CTAG filtering.
Reported-by: Otto Sabart <[email protected]>
Signed-off-by: Yuval Mintz <[email protected]>
Signed-off-by: Ariel Elior <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
This driver does not handle the AVB-DMAC Receive FIFO Warning interrupt
now, so the interrupt should not be enabled.
Signed-off-by: Masaru Nagai <[email protected]>
Signed-off-by: Yoshihiro Kaneko <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Sending ICMP packets with raw sockets ends up in the SNMP counters
logging the type as the first byte of the IPv4 header rather than
the ICMP header. This is fixed by adding the IP Header Length to
the casting into a icmphdr struct.
Signed-off-by: Ben Cartwright-Cox <[email protected]>
Acked-by: Eric Dumazet <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
This pci_error_handlers structure is never modified, like all the other
pci_error_handlers structures, so declare it as const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
This pci_error_handlers structure is never modified, like all the other
pci_error_handlers structures, so declare it as const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Signed-off-by: Shrikrishna Khare <[email protected]>
Reported-by: Masao Uebayashi <[email protected]>
Signed-off-by: Bhavesh Davda <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Since Dell DW5580 is a 3G modem, this patch adds the device as a
mobile broadband adapter
Signed-off-by: Daniele Palmas <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
If ndo_set_features fails __netdev_update_features() will return -1 but
this is wrong because it is expected to return 0 if no features were
changed (see netdev_update_features()), which will cause a netdev
notifier to be called without any actual changes. Fix this by returning
0 if ndo_set_features fails.
Fixes: 6cb6a27c45ce ("net: Call netdev_features_change() from netdev_update_features()")
CC: Michał Mirosław <[email protected]>
Signed-off-by: Nikolay Aleksandrov <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
When __netdev_update_features() was updated to ensure some features are
disabled on new lower devices, an error was introduced for devices which
don't have the ndo_set_features() method set. Before we'll just set the
new features, but now we return an error and don't set them. Fix this by
returning the old behaviour and setting err to 0 when ndo_set_features
is not present.
Fixes: e7868a85e1b2 ("net/core: ensure features get disabled on new lower devs")
CC: Jarod Wilson <[email protected]>
CC: Jiri Pirko <[email protected]>
CC: Ido Schimmel <[email protected]>
CC: Sander Eikelenboom <[email protected]>
CC: Andy Gospodarek <[email protected]>
CC: Florian Fainelli <[email protected]>
Signed-off-by: Nikolay Aleksandrov <[email protected]>
Reviewed-by: Jiri Pirko <[email protected]>
Reviewed-by: Andy Gospodarek <[email protected]>
Reviewed-by: Jarod Wilson <[email protected]>
Tested-by: Florian Fainelli <[email protected]>
Tested-by: Dave Young <[email protected]>
Tested-by: Christian Borntraeger <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
When NET_SWITCHDEV=n, switchdev_port_attr_set simply returns EOPNOTSUPP.
In this case we should not emit errors and warnings to the kernel log.
Reported-by: Sander Eikelenboom <[email protected]>
Tested-by: Christian Borntraeger <[email protected]>
Fixes: 0bc05d585d38 ("switchdev: allow caller to explicitly request
attr_set as deferred")
Fixes: 6ac311ae8bfb ("Adding switchdev ageing notification on port
bridged")
Signed-off-by: Ido Schimmel <[email protected]>
Signed-off-by: Jiri Pirko <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Signed-off-by: Ivan Vecera <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Remove rsstable array and its initialization from be_set_rss_hash_opts().
The array became unused after "e255787 be2net: Support for configurable
RSS hash key". The initial RSS table is now filled and stored for later
usage during Rx queue creation.
Signed-off-by: Ivan Vecera <[email protected]>
Acked-by: Sathya Perla <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
When RX/TX interrupt for Network Control queue and Best Effort queue
is issued at the same time, the interrupt mask of Network Control
queue will be reset when the mask of Best Effort queue is set.
This patch fixes this problem.
Signed-off-by: Masaru Nagai <[email protected]>
Signed-off-by: Yoshihiro Kaneko <[email protected]>
Acked-by: Geert Uytterhoeven <[email protected]>
Acked-by: Simon Horman <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
On certain hardware after software reboot the chip may get stuck and fail
to reinitialize during reset. This can be fixed by ensuring that PHY is
reset too.
Old PHY resetting method required operational MDIO interface, therefore
the chip should have been already set up. In order to be able to function
during probe, it is changed to use PMT_CTRL register.
The problem could be observed on SMDK5410 board.
Signed-off-by: Pavel Fedin <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
While recently going over ARM64's BPF code, I noticed that the icache
range we're flushing should start at header already and not at ctx.image.
Reason is that after b569c1c622c5 ("net: bpf: arm64: address randomize
and write protect JIT code"), we also want to make sure to flush the
random-sized trap in front of the start of the actual program (analogous
to x86). No operational differences from user side.
Signed-off-by: Daniel Borkmann <[email protected]>
Acked-by: Zi Shen Lim <[email protected]>
Cc: Alexei Starovoitov <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
During review I noticed that the icache range we're flushing should
start at header already and not at ctx.image.
Reason is that after 55309dd3d4cd ("net: bpf: arm: address randomize
and write protect JIT code"), we also want to make sure to flush the
random-sized trap in front of the start of the actual program (analogous
to x86). No operational differences from user side.
Signed-off-by: Daniel Borkmann <[email protected]>
Tested-by: Nicolas Schichan <[email protected]>
Cc: Alexei Starovoitov <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
commit 338d4f49d6f7114a017d294ccf7374df4f998edc
("arm64: kernel: Add support for Privileged Access Never") includes sysreg.h
into futex.h and uaccess.h. But, the inline assembly used by asm/sysreg.h is
incompatible with llvm so it will cause BPF samples build failure for ARM64.
Since sysreg.h is useless for BPF samples, just exclude it from Makefile via
defining __ASM_SYSREG_H.
Signed-off-by: Yang Shi <[email protected]>
Acked-by: Alexei Starovoitov <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
BPF fp should point to the top of the BPF prog stack. The original
implementation made it point to the bottom incorrectly.
Move A64_SP to fp before reserve BPF prog stack space.
CC: Zi Shen Lim <[email protected]>
CC: Xi Wang <[email protected]>
Signed-off-by: Yang Shi <[email protected]>
Reviewed-by: Zi Shen Lim <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|