| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup
Pull cgroup fix from Tejun Heo:
"Fix leak of filesystem context root which is triggered by LTP.
Not too likely to be a problem in non-testing environments"
* 'for-5.14-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup:
cgroup1: fix leaked context root causing sporadic NULL deref in LTP
|
|
The arguments to the KVM_CLEAR_DIRTY_LOG ioctl include a pointer,
therefore it needs a compat ioctl implementation. Otherwise,
32-bit userspace fails to invoke it on 64-bit kernels; for x86
it might work fine by chance if the padding is zero, but not
on big-endian architectures.
Reported-by: Thomas Sattler
Cc: [email protected]
Fixes: 2a31b9db1535 ("kvm: introduce manual dirty log reprotect")
Reviewed-by: Peter Xu <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
|
|
SMT siblings share caches and other hardware, and busy halt polling
will degrade its sibling performance if its sibling is working
Sean Christopherson suggested as below:
"Rather than disallowing halt-polling entirely, on x86 it should be
sufficient to simply have the hardware thread yield to its sibling(s)
via PAUSE. It probably won't get back all performance, but I would
expect it to be close.
This compiles on all KVM architectures, and AFAICT the intended usage
of cpu_relax() is identical for all architectures."
Suggested-by: Sean Christopherson <[email protected]>
Signed-off-by: Li RongQing <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
|
|
Currently when SVM is enabled in guest CPUID, AVIC is inhibited as soon
as the guest CPUID is set.
AVIC happens to be fully disabled on all vCPUs by the time any guest
entry starts (if after migration the entry can be nested).
The reason is that currently we disable avic right away on vCPU from which
the kvm_request_apicv_update was called and for this case, it happens to be
called on all vCPUs (by svm_vcpu_after_set_cpuid).
After we stop doing this, AVIC will end up being disabled only when
KVM_REQ_APICV_UPDATE is processed which is after we done switching to the
nested guest.
Fix this by just using vmcb01 in svm_refresh_apicv_exec_ctrl for avic
(which is a right thing to do anyway).
Signed-off-by: Maxim Levitsky <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
|
|
It is possible that AVIC was requested to be disabled but
not yet disabled, e.g if the nested entry is done right
after svm_vcpu_after_set_cpuid.
Signed-off-by: Maxim Levitsky <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
|
|
deactivated
It is possible for AVIC inhibit and AVIC active state to be mismatched.
Currently we disable AVIC right away on vCPU which started the AVIC inhibit
request thus this warning doesn't trigger but at least in theory,
if svm_set_vintr is called at the same time on multiple vCPUs,
the warning can happen.
Signed-off-by: Maxim Levitsky <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
|
|
commit bc9e9e672df9 ("KVM: debugfs: Reuse binary stats descriptors")
did replace the old definitions with the binary ones. While doing that
it missed that some files are names different than the counters. This
is especially important for kvm_stat which does have special handling
for counters named instruction_*.
Fixes: commit bc9e9e672df9 ("KVM: debugfs: Reuse binary stats descriptors")
CC: Jing Zhang <[email protected]>
Signed-off-by: Christian Borntraeger <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
|
|
Right now, svm_hv_vmcb_dirty_nested_enlightenments has an incorrect
dereference of vmcb->control.reserved_sw before the vmcb is checked
for being non-NULL. The compiler is usually sinking the dereference
after the check; instead of doing this ourselves in the source,
ensure that svm_hv_vmcb_dirty_nested_enlightenments is only called
with a non-NULL VMCB.
Reported-by: Dan Carpenter <[email protected]>
Cc: Vineeth Pillai <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
[Untested for now due to issues with my AMD machine. - Paolo]
|
|
This test measures the performance effects of KVM's access tracking.
Access tracking is driven by the MMU notifiers test_young, clear_young,
and clear_flush_young. These notifiers do not have a direct userspace
API, however the clear_young notifier can be triggered by marking a
pages as idle in /sys/kernel/mm/page_idle/bitmap. This test leverages
that mechanism to enable access tracking on guest memory.
To measure performance this test runs a VM with a configurable number of
vCPUs that each touch every page in disjoint regions of memory.
Performance is measured in the time it takes all vCPUs to finish
touching their predefined region.
Example invocation:
$ ./access_tracking_perf_test -v 8
Testing guest mode: PA-bits:ANY, VA-bits:48, 4K pages
guest physical test memory offset: 0xffdfffff000
Populating memory : 1.337752570s
Writing to populated memory : 0.010177640s
Reading from populated memory : 0.009548239s
Mark memory idle : 23.973131748s
Writing to idle memory : 0.063584496s
Mark memory idle : 24.924652964s
Reading from idle memory : 0.062042814s
Breaking down the results:
* "Populating memory": The time it takes for all vCPUs to perform the
first write to every page in their region.
* "Writing to populated memory" / "Reading from populated memory": The
time it takes for all vCPUs to write and read to every page in their
region after it has been populated. This serves as a control for the
later results.
* "Mark memory idle": The time it takes for every vCPU to mark every
page in their region as idle through page_idle.
* "Writing to idle memory" / "Reading from idle memory": The time it
takes for all vCPUs to write and read to every page in their region
after it has been marked idle.
This test should be portable across architectures but it is only enabled
for x86_64 since that's all I have tested.
Reviewed-by: Ben Gardon <[email protected]>
Signed-off-by: David Matlack <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
|
|
There is a missing break statement which causes a fallthrough to the
next statement where optarg will be null and a segmentation fault will
be generated.
Fixes: 9e965bb75aae ("KVM: selftests: Add backing src parameter to dirty_log_perf_test")
Reviewed-by: Ben Gardon <[email protected]>
Signed-off-by: David Matlack <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
|
|
KVM_MAX_VCPU_ID is the maximum vcpu-id of a guest, and not the number
of vcpu-ids. Fix array indexed by vcpu-id to have KVM_MAX_VCPU_ID+1
elements.
Note that this is currently no real problem, as KVM_MAX_VCPU_ID is
an odd number, resulting in always enough padding being available at
the end of those arrays.
Nevertheless this should be fixed in order to avoid rare problems in
case someone is using an even number for KVM_MAX_VCPU_ID.
Signed-off-by: Juergen Gross <[email protected]>
Message-Id: <[email protected]>
Cc: [email protected]
Signed-off-by: Paolo Bonzini <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq
Pull workqueue fix from Tejun Heo:
"Fix a use-after-free in allocation failure handling path"
* 'for-5.14-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq:
workqueue: fix UAF in pwq_unbound_release_workfn()
|
|
The ptp cycle is related to the hardware, so it may cause compatibility
issues if a fixed value is used in driver. Therefore, the method of
obtaining this value is changed to read from the register rather than
use a fixed value in driver.
Fixes: 0bf5eb788512 ("net: hns3: add support for PTP")
Signed-off-by: Yufeng Mo <[email protected]>
Signed-off-by: Guangbin Huang <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
syzbot reported KCSAN data races vs. timer_base::timer_running being set to
NULL without holding base::lock in expire_timers().
This looks innocent and most reads are clearly not problematic, but
Frederic identified an issue which is:
int data = 0;
void timer_func(struct timer_list *t)
{
data = 1;
}
CPU 0 CPU 1
------------------------------ --------------------------
base = lock_timer_base(timer, &flags); raw_spin_unlock(&base->lock);
if (base->running_timer != timer) call_timer_fn(timer, fn, baseclk);
ret = detach_if_pending(timer, base, true); base->running_timer = NULL;
raw_spin_unlock_irqrestore(&base->lock, flags); raw_spin_lock(&base->lock);
x = data;
If the timer has previously executed on CPU 1 and then CPU 0 can observe
base->running_timer == NULL and returns, assuming the timer has completed,
but it's not guaranteed on all architectures. The comment for
del_timer_sync() makes that guarantee. Moving the assignment under
base->lock prevents this.
For non-RT kernel it's performance wise completely irrelevant whether the
store happens before or after taking the lock. For an RT kernel moving the
store under the lock requires an extra unlock/lock pair in the case that
there is a waiter for the timer, but that's not the end of the world.
Reported-by: [email protected]
Reported-by: [email protected]
Fixes: 030dcdd197d7 ("timers: Prepare support for PREEMPT_RT")
Signed-off-by: Thomas Gleixner <[email protected]>
Tested-by: Sebastian Andrzej Siewior <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Cc: [email protected]
|
|
Commit a0384ecfe2aa ("clk: qcom: smd-rpm: De-duplicate identical
entries") introduces the following regression on MSM8936/MSM8939, as
RPM_SMD_PCNOC_A_CLK gets pointed to pcnoc_clk by mistake. Fix it by
correcting the clock to pcnoc_a_clk.
[ 1.307363] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
[ 1.313593] Mem abort info:
[ 1.322512] ESR = 0x96000004
[ 1.325132] EC = 0x25: DABT (current EL), IL = 32 bits
[ 1.338872] SET = 0, FnV = 0
[ 1.355483] EA = 0, S1PTW = 0
[ 1.368702] FSC = 0x04: level 0 translation fault
[ 1.383294] Data abort info:
[ 1.398292] ISV = 0, ISS = 0x00000004
[ 1.398297] CM = 0, WnR = 0
[ 1.398301] [0000000000000000] user address but active_mm is swapper
[ 1.404193] Internal error: Oops: 96000004 [#1] PREEMPT SMP
[ 1.420596] Modules linked in:
[ 1.420604] CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.14.0-rc3+ #198
[ 1.441010] pc : __clk_register+0x48/0x780
[ 1.446045] lr : __clk_register+0x3c/0x780
[ 1.449953] sp : ffff800010063440
[ 1.454031] x29: ffff800010063440 x28: 0000000000000004 x27: 0000000000000066
[ 1.457423] x26: 0000000000000001 x25: 000000007fffffff x24: ffff800010f9f388
[ 1.464540] x23: ffff00007fc12a90 x22: ffff0000034b2010 x21: 0000000000000000
[ 1.471658] x20: ffff800010f9fff8 x19: ffff00000152a700 x18: 0000000000000001
[ 1.478778] x17: ffff00007fbd40c8 x16: 0000000000000460 x15: 0000000000000465
[ 1.485895] x14: ffffffffffffffff x13: 746e756f635f7265 x12: 696669746f6e5f6b
[ 1.493013] x11: 0000000000000006 x10: 0000000000000000 x9 : 0000000000000000
[ 1.500131] x8 : ffff00000152a800 x7 : 0000000000000000 x6 : 000000000000003f
[ 1.507249] x5 : 0000000000000040 x4 : 0000000000000000 x3 : 0000000000000004
[ 1.514367] x2 : 0000000000000000 x1 : 0000000000000cc0 x0 : ffff00000152a700
[ 1.521486] Call trace:
[ 1.528598] __clk_register+0x48/0x780
[ 1.530855] clk_hw_register+0x20/0x60
[ 1.534674] devm_clk_hw_register+0x50/0xa8
[ 1.538408] rpm_smd_clk_probe+0x1a4/0x260
[ 1.542488] platform_probe+0x68/0xd8
[ 1.546653] really_probe+0x140/0x2f8
[ 1.550386] __driver_probe_device+0x78/0xe0
[ 1.554033] driver_probe_device+0x80/0x110
[ 1.558373] __device_attach_driver+0x90/0xe0
[ 1.562280] bus_for_each_drv+0x78/0xc8
[ 1.566793] __device_attach+0xf0/0x150
[ 1.570438] device_initial_probe+0x14/0x20
[ 1.574259] bus_probe_device+0x9c/0xa8
[ 1.578425] device_add+0x378/0x870
[ 1.582243] of_device_add+0x44/0x60
[ 1.585716] of_platform_device_create_pdata+0xc0/0x110
[ 1.589538] of_platform_bus_create+0x17c/0x388
[ 1.594485] of_platform_populate+0x50/0xf0
[ 1.598998] qcom_smd_rpm_probe+0xd4/0x128
[ 1.603164] rpmsg_dev_probe+0xbc/0x1a8
[ 1.607330] really_probe+0x140/0x2f8
[ 1.611063] __driver_probe_device+0x78/0xe0
[ 1.614883] driver_probe_device+0x80/0x110
[ 1.619224] __device_attach_driver+0x90/0xe0
[ 1.623131] bus_for_each_drv+0x78/0xc8
[ 1.627643] __device_attach+0xf0/0x150
[ 1.631289] device_initial_probe+0x14/0x20
[ 1.635109] bus_probe_device+0x9c/0xa8
[ 1.639275] device_add+0x378/0x870
[ 1.643095] device_register+0x20/0x30
[ 1.646567] rpmsg_register_device+0x54/0x90
[ 1.650387] qcom_channel_state_worker+0x168/0x288
[ 1.654814] process_one_work+0x1a0/0x328
[ 1.659415] worker_thread+0x4c/0x420
[ 1.663494] kthread+0x150/0x160
[ 1.667138] ret_from_fork+0x10/0x18
[ 1.670442] Code: 97f56b92 b40034a0 aa0003f3 52819801 (f94002a0)
[ 1.674004] ---[ end trace 412fa6f47384cdfe ]---
Fixes: a0384ecfe2aa ("clk: qcom: smd-rpm: De-duplicate identical entries")
Signed-off-by: Shawn Guo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Stephen Boyd <[email protected]>
|
|
The performance reporting driver added cpu hotplug
feature but it didn't add pmu migration call in cpu
offline function.
This can create an issue incase the current designated
cpu being used to collect fme pmu data got offline,
as based on current code we are not migrating fme pmu to
new target cpu. Because of that perf will still try to
fetch data from that offline cpu and hence we will not
get counter data.
Patch fixed this issue by adding pmu_migrate_context call
in fme_perf_offline_cpu function.
Fixes: 724142f8c42a ("fpga: dfl: fme: add performance reporting support")
Cc: [email protected]
Tested-by: Xu Yilun <[email protected]>
Acked-by: Wu Hao <[email protected]>
Signed-off-by: Kajol Jain <[email protected]>
Signed-off-by: Moritz Fischer <[email protected]>
|
|
As a safeguard, if we're going to queue async work, do it from task_work
from the original task. This ensures that we can always sanely create
threads, regards of what the reissue context may be.
Signed-off-by: Jens Axboe <[email protected]>
|
|
Add links to the issue tracker and the IRC channel for the amdgpu
driver.
Signed-off-by: Simon Ser <[email protected]>
Cc: Alex Deucher <[email protected]>
Cc: Christian König <[email protected]>
Cc: Pan Xinhui <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
|
|
We've gotten a number of reports about backlight control not
working on panels which indicate that they use aux backlight
control. A recent patch:
commit 2d73eabe2984a435737498ab39bb1500a9ffe9a9
Author: Camille Cho <[email protected]>
Date: Thu Jul 8 18:28:37 2021 +0800
drm/amd/display: Only set default brightness for OLED
[Why]
We used to unconditionally set backlight path as AUX for panels capable
of backlight adjustment via DPCD in set default brightness.
[How]
This should be limited to OLED panel only since we control backlight via
PWM path for SDR mode in LCD HDR panel.
Reviewed-by: Krunoslav Kovac <[email protected]>
Acked-by: Rodrigo Siqueira <[email protected]>
Signed-off-by: Camille Cho <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Changes some other code to only use aux for backlight control on
OLED panels. The commit message seems to indicate that PWM should
be used for SDR mode on HDR panels. Do something similar for
backlight control in general. This may need to be revisited if and
when HDR started to get used.
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1438
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=213715
Reviewed-by: Roman Li <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
|
|
[Why]
We don't check DENTIST_DISPCLK_CHG_DONE to ensure dentist
display clockis updated to target value. In some scenarios with large
display clock margin, it will deliver unfinished display clock and cause
issues like display black screen.
[How]
Checking DENTIST_DISPCLK_CHG_DONE to ensure display clock
has been update to target value before driver do other clock related
actions.
Reviewed-by: Cyr Aric <[email protected]>
Acked-by: Solomon Chiu <[email protected]>
Signed-off-by: Dale Zhao <[email protected]>
Tested-by: Daniel Wheeler <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Cc: [email protected]
|
|
[why]
IP parameter min_meta_chunk_size_bytes is read for bandwidth
calculations but it was never defined.
[how]
Define min_meta_chunk_size_bytes and initialize value to 256.
Reviewed-by: Laktyushkin Dmytro <[email protected]>
Acked-by: Solomon Chiu <[email protected]>
Signed-off-by: Victor Lu <[email protected]>
Tested-by: Daniel Wheeler <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
|
|
[why]
DST_Y_PREFETCH can overflow when DestinationLinesForPrefetch values are
too large due to the former being limited to 8 bits.
[how]
Set the maximum value of DestinationLinesForPrefetch to be 255 * refclk
period.
Reviewed-by: Laktyushkin Dmytro <[email protected]>
Acked-by: Solomon Chiu <[email protected]>
Signed-off-by: Victor Lu <[email protected]>
Tested-by: Daniel Wheeler <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
|
|
[Why]
User might change the suspend behaviour from OS.
[How]
Check with pm for target suspend state and set s0ix
flag only for s2idle state.
v2: User might change default suspend state, use target state
v3: squash in build fix
Suggested-by: Lijo Lazar <[email protected]>
Signed-off-by: Pratik Vishwakarma <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Cc: [email protected]
|
|
Commit c47a5599eda324ba ("perf tools: Fix pattern matching for same
substring in different PMU type"), may have fixed some alias matching,
but has broken some others.
Firstly it cannot handle the simple scenario of PMU name in form
pmu_name{digits} - it can only handle pmu_name_{digits}.
Secondly it cannot handle more complex matching in the case where we
have multiple tokens. In this scenario, the code failed to realise that
we may examine multiple substrings in the PMU name.
Fix in two ways:
- Change perf_pmu__valid_suffix() to accept a PMU name without '_' in the
suffix
- Only pay attention to perf_pmu__valid_suffix() for the final token
Also add const qualifiers as necessary to avoid casting.
Fixes: c47a5599eda324ba ("perf tools: Fix pattern matching for same substring in different PMU type")
Signed-off-by: John Garry <[email protected]>
Tested-by: Jin Yao <[email protected]>
Cc: Alexander Shishkin <[email protected]>
Cc: Ian Rogers <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: Kajol Jain <[email protected]>
Cc: Mark Rutland <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
|
|
PCIe tunnels"
This reverts commit 6f3badead6a078cf3c71f381f9d84ac922984a00.
It turns out bolt depends on having authorized attribute visible under
each device. Hiding it makes bolt crash as several people have reported
on various bug trackers. For this reason revert the commit.
Link: https://gitlab.freedesktop.org/bolt/bolt/-/issues/174
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1979765
Link: https://bugs.archlinux.org/task/71569
Cc: [email protected]
Cc: Christian Kellner <[email protected]>
Fixes: 6f3badead6a0 ("thunderbolt: Hide authorized attribute if router does not support PCIe tunnels")
Signed-off-by: Mika Westerberg <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
Currently --dump-raw-trace skips queueing and splitting buffers because
of an early exit condition in cs_etm__process_auxtrace_info(). Once
that is removed we can print the split data by using the queues
and searching for split buffers with the same reference as the
one that is currently being processed.
This keeps the same behaviour of dumping in file order when an AUXTRACE
event appears, rather than moving trace dump to where AUX records are in
the file.
There will be a newline and size printout for each fragment. For example
this buffer is comprised of two AUX records, but was printed as one:
0 0 0x8098 [0x30]: PERF_RECORD_AUXTRACE size: 0xa0 offset: 0 ref: 0x491a4dfc52fc0e6e idx: 0 t
. ... CoreSight ETM Trace data: size 160 bytes
Idx:0; ID:10; I_ASYNC : Alignment Synchronisation.
Idx:12; ID:10; I_TRACE_INFO : Trace Info.; INFO=0x0 { CC.0 }
Idx:17; ID:10; I_ADDR_L_64IS0 : Address, Long, 64 bit, IS0.; Addr=0x0000000000000000;
Idx:80; ID:10; I_ASYNC : Alignment Synchronisation.
Idx:92; ID:10; I_TRACE_INFO : Trace Info.; INFO=0x0 { CC.0 }
Idx:97; ID:10; I_ADDR_L_64IS0 : Address, Long, 64 bit, IS0.; Addr=0xFFFFDE2AD3FD76D4;
But is now printed as two fragments:
0 0 0x8098 [0x30]: PERF_RECORD_AUXTRACE size: 0xa0 offset: 0 ref: 0x491a4dfc52fc0e6e idx: 0 t
. ... CoreSight ETM Trace data: size 80 bytes
Idx:0; ID:10; I_ASYNC : Alignment Synchronisation.
Idx:12; ID:10; I_TRACE_INFO : Trace Info.; INFO=0x0 { CC.0 }
Idx:17; ID:10; I_ADDR_L_64IS0 : Address, Long, 64 bit, IS0.; Addr=0x0000000000000000;
. ... CoreSight ETM Trace data: size 80 bytes
Idx:80; ID:10; I_ASYNC : Alignment Synchronisation.
Idx:92; ID:10; I_TRACE_INFO : Trace Info.; INFO=0x0 { CC.0 }
Idx:97; ID:10; I_ADDR_L_64IS0 : Address, Long, 64 bit, IS0.; Addr=0xFFFFDE2AD3FD76D4;
Decoding errors that appeared in problematic files are now not present,
for example:
Idx:808; ID:1c; I_BAD_SEQUENCE : Invalid Sequence in packet.[I_ASYNC]
...
PKTP_ETMV4I_0016 : 0x0014 (OCSD_ERR_INVALID_PCKT_HDR) [Invalid packet header]; TrcIdx=822
Signed-off-by: James Clark <[email protected]>
Reviewed-by: Mathieu Poirier <[email protected]>
Tested-by: Leo Yan <[email protected]>
Cc: Al Grant <[email protected]>
Cc: Alexander Shishkin <[email protected]>
Cc: Anshuman Khandual <[email protected]>
Cc: Branislav Rankov <[email protected]>
Cc: Denis Nikitin <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: John Garry <[email protected]>
Cc: Mark Rutland <[email protected]>
Cc: Mike Leach <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Suzuki Poulouse <[email protected]>
Cc: Will Deacon <[email protected]>
Cc: [email protected]
Cc: [email protected]
Link: http://lore.kernel.org/lkml/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
|
|
Avoids the following WARN:
[ 3.009556] ------------[ cut here ]------------
[ 3.014306] WARNING: CPU: 7 PID: 109 at
drivers/gpu/drm/drm_dp_helper.c:1796 drm_dp_aux_register+0xa4/0xac
[ 3.024209] Modules linked in:
[ 3.027351] CPU: 7 PID: 109 Comm: kworker/7:8 Not tainted 5.10.47 #69
[ 3.033958] Hardware name: Google Lazor (rev1 - 2) (DT)
[ 3.039323] Workqueue: events deferred_probe_work_func
[ 3.044596] pstate: 60c00009 (nZCv daif +PAN +UAO -TCO BTYPE=--)
[ 3.050761] pc : drm_dp_aux_register+0xa4/0xac
[ 3.055329] lr : dp_aux_register+0x40/0x88
[ 3.059538] sp : ffffffc010ad3920
[ 3.062948] x29: ffffffc010ad3920 x28: ffffffa64196ac70
[ 3.067239] mmc1: Command Queue Engine enabled
[ 3.068406] x27: ffffffa64196ac68 x26: 0000000000000001
[ 3.068407] x25: 0000000000000002 x24: 0000000000000060
[ 3.068409] x23: ffffffa642ab3400 x22: ffffffe126c10e5b
[ 3.068410] x21: ffffffa641dc3188 x20: ffffffa641963c10
[ 3.068412] x19: ffffffa642aba910 x18: 00000000ffff0a00
[ 3.068414] x17: 000000476f8e002a x16: 00000000000000b8
[ 3.073008] mmc1: new HS400 Enhanced strobe MMC card at address 0001
[ 3.078448] x15: ffffffffffffffff x14: ffffffffffffffff
[ 3.078450] x13: 0000000000000030 x12: 0000000000000030
[ 3.078452] x11: 0101010101010101 x10: ffffffe12647a914
[ 3.078453] x9 : ffffffe12647a8cc x8 : 0000000000000000
[ 3.084452] mmcblk1: mmc1:0001 DA4032 29.1 GiB
[ 3.089372]
[ 3.089372] x7 : 6c6064717372fefe x6 : ffffffa642b11494
[ 3.089374] x5 : 0000000000000000 x4 : 6d006c657869ffff
[ 3.089375] x3 : 000000006c657869 x2 : 000000000000000c
[ 3.089376] x1 : ffffffe126c3ae3c x0 : ffffffa642aba910
[ 3.089381] Call trace:
[ 3.094931] mmcblk1boot0: mmc1:0001 DA4032 partition 1 4.00 MiB
[ 3.100291] drm_dp_aux_register+0xa4/0xac
[ 3.100292] dp_aux_register+0x40/0x88
[ 3.100294] dp_display_bind+0x64/0xcc
[ 3.100295] component_bind_all+0xdc/0x210
[ 3.100298] msm_drm_bind+0x1e8/0x5d4
[ 3.100301] try_to_bring_up_master+0x168/0x1b0
[ 3.105861] mmcblk1boot1: mmc1:0001 DA4032 partition 2 4.00 MiB
[ 3.112282] __component_add+0xa0/0x158
[ 3.112283] component_add+0x1c/0x28
[ 3.112284] dp_display_probe+0x33c/0x380
[ 3.112286] platform_drv_probe+0x9c/0xbc
[ 3.112287] really_probe+0x140/0x35c
[ 3.112289] driver_probe_device+0x84/0xc0
[ 3.112292] __device_attach_driver+0x94/0xb0
[ 3.117967] mmcblk1rpmb: mmc1:0001 DA4032 partition 3 16.0 MiB,
chardev (239:0)
[ 3.123201] bus_for_each_drv+0x8c/0xd8
[ 3.123202] __device_attach+0xc4/0x150
[ 3.123204] device_initial_probe+0x1c/0x28
[ 3.123205] bus_probe_device+0x3c/0x9c
[ 3.123206] deferred_probe_work_func+0x90/0xcc
[ 3.123211] process_one_work+0x218/0x3ec
[ 3.131976] mmcblk1: p1 p2 p3 p4 p5 p6 p7 p8 p9 p10 p11 p12
[ 3.134123] worker_thread+0x288/0x3e8
[ 3.134124] kthread+0x148/0x1b0
[ 3.134127] ret_from_fork+0x10/0x30
[ 3.134128] ---[ end trace cfb9fce3f70f824d ]---
Signed-off-by: Sean Paul <[email protected]>
Reviewed-by: Abhinav Kumar <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Rob Clark <[email protected]>
|
|
There is a scenario that dp cable is unplugged from DUT during system
suspended will cause audio option state does not match real connection
state. Fix this problem by Signaling audio plugged change with realtime
connection status at dp_pm_resume() so that audio option will be in
correct state after system resumed.
Changes in V2:
-- correct Fixes tag commit id.
Fixes: f591dbb5fb8c ("drm/msm/dp: power off DP phy at suspend")
Signed-off-by: Kuogee Hsieh <[email protected]>
Reviewed-by: Stephen Boyd <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Rob Clark <[email protected]>
|
|
Some bootloaders set the widebus enable bit in the INTF_CONFIG register,
but configuration of widebus isn't yet supported ensure that the
register has a known value, with widebus disabled.
Fixes: c943b4948b58 ("drm/msm/dp: add displayPort driver support")
Signed-off-by: Bjorn Andersson <[email protected]>
Reviewed-by: Stephen Boyd <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Rob Clark <[email protected]>
|
|
DP cable should always connect to DPU during the entire PHY compliance
testing run. Since DP PHY compliance test is executed at irq_hpd event
context, dp_ctrl_off_link_stream() should be used instead of dp_ctrl_off().
dp_ctrl_off() is used for unplug event which is triggered when DP cable is
dis connected.
Changes in V2:
-- add fixes statement
Fixes: f21c8a276c2d ("drm/msm/dp: handle irq_hpd with sink_count = 0 correctly")
Signed-off-by: Kuogee Hsieh <[email protected]>
Reviewed-by: Stephen Boyd <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Rob Clark <[email protected]>
|
|
It turns out that when the display is enabled by the bootloader, we can
get some transient iommu faults from the display. Which doesn't go over
too well when we install a fault handler that is gpu specific. To avoid
this, defer installing the fault handler until we get around to setting
up per-process pgtables (which is adreno_smmu specific). The arm-smmu
fallback error reporting is sufficient for reporting display related
faults (and in fact was all we had prior to f8f934c180f629bb927a04fd90d)
Reported-by: Dmitry Baryshkov <[email protected]>
Reported-by: Yassine Oudjana <[email protected]>
Fixes: 2a574cc05d38 ("drm/msm: Improve the a6xx page fault handler")
Signed-off-by: Rob Clark <[email protected]>
Tested-by: John Stultz <[email protected]>
Tested-by: Yassine Oudjana <[email protected]>
Reviewed-by: Bjorn Andersson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Rob Clark <[email protected]>
|
|
The downstream dts lists this value as 0x494, and not
0x45c.
Fixes: af776a3e1c30 ("drm/msm/dpu: add SM8250 to hw catalog")
Signed-off-by: Robert Foss <[email protected]>
Reviewed-by: Dmitry Baryshkov <[email protected]>
Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Rob Clark <[email protected]>
|
|
The ACRN hypervisor has scenarios which could run a real-time guest VM.
The real-time guest VM occupies dedicated CPU cores, be assigned with
dedicated PCI devices. It can run without the Service VM after boot up.
hcall_destroy_vm() returns failure when a real-time guest VM refuses.
The clearing of flag ACRN_VM_FLAG_DESTROYED causes some kernel resource
double-freed in a later acrn_vm_destroy().
Do hcall_destroy_vm() before resource release to drop this chance to
destroy the VM if hypercall fails.
Fixes: 9c5137aedd11 ("virt: acrn: Introduce VM management interfaces")
Cc: stable <[email protected]>
Signed-off-by: Shuo Liu <[email protected]>
Signed-off-by: Fei Li <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
The HNP work can be re-scheduled while it's still in-fly. This results in
re-initialization of the busy work, resetting the hrtimer's list node of
the work and crashing kernel with null dereference within kernel/timer
once work's timer is expired. It's very easy to trigger this problem by
re-plugging USB cable quickly. Initialize HNP work only once to fix this
trouble.
Unable to handle kernel NULL pointer dereference at virtual address 00000126)
...
PC is at __run_timers.part.0+0x150/0x228
LR is at __next_timer_interrupt+0x51/0x9c
...
(__run_timers.part.0) from [<c0187a2b>] (run_timer_softirq+0x2f/0x50)
(run_timer_softirq) from [<c01013ad>] (__do_softirq+0xd5/0x2f0)
(__do_softirq) from [<c012589b>] (irq_exit+0xab/0xb8)
(irq_exit) from [<c0170341>] (handle_domain_irq+0x45/0x60)
(handle_domain_irq) from [<c04c4a43>] (gic_handle_irq+0x6b/0x7c)
(gic_handle_irq) from [<c0100b65>] (__irq_svc+0x65/0xac)
Cc: [email protected]
Acked-by: Peter Chen <[email protected]>
Signed-off-by: Dmitry Osipenko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
On SAMA7G5 suspending ports will cut the access to OHCI registers and
any subsequent access to them will lead to CPU being blocked trying to
access that memory. Same thing happens on resume: if OHCI memory is
accessed before resuming ports the CPU will block on that access. The
OCHI memory is accessed on suspend/resume though
ohci_suspend()/ohci_resume().
Acked-by: Alan Stern <[email protected]>
Signed-off-by: Claudiu Beznea <[email protected]>
Cc: stable <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
As the USB PHYs typically are on I2C or SPI bus for the 2430 glue layer,
we need configure the PHYs early for suspend.
The musb glue layer we need to suspend only after musb_suspend() in
suspend_late.
Fixes: 62d472d8ad88 ("usb: musb: Add missing PM suspend and resume functions for 2430 glue")
Reported-by: Andreas Kemnade <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
The USB HID standard declares mandatory support for GET_IDLE and SET_IDLE
requests for Boot Keyboard. Most hosts can handle their absence, but others
like some old/strange UEFIs and BIOSes consider this a critical error
and refuse to work with f_hid.
This primitive implementation of saving and returning idle is sufficient
to meet the requirements of the standard and these devices.
Acked-by: Felipe Balbi <[email protected]>
Cc: stable <[email protected]>
Signed-off-by: Maxim Devaev <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
Disconnecting and reconnecting the USB cable can lead to crashes
and a variety of kernel log spam.
The problem was found and reproduced on the Raspberry Pi [1]
and the original fix was created in Raspberry's own fork [2].
Link: https://github.com/raspberrypi/linux/issues/3870 [1]
Link: https://github.com/raspberrypi/linux/commit/a6e47d5f4efbd2ea6a0b6565cd2f9b7bb217ded5 [2]
Signed-off-by: Maxim Devaev <[email protected]>
Signed-off-by: Phil Elwell <[email protected]>
Cc: stable <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
The usb_add_gadget_udc will add a new gadget to the udc class
driver list. Not calling usb_del_gadget_udc in error branch
will result in residual gadget entry in the udc driver list.
We fix it by calling usb_del_gadget_udc to clean it when error
return.
Fixes: 48ba02b2e2b1 ("usb: gadget: add udc driver for max3420")
Acked-by: Felipe Balbi <[email protected]>
Signed-off-by: Zhang Qilong <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Cc: stable <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
rcu: INFO: rcu_preempt self-detected stall on CPU
rcu: 1-...!: (2 ticks this GP) idle=d92/1/0x4000000000000000
softirq=25390/25392 fqs=3
(t=12164 jiffies g=31645 q=43226)
rcu: rcu_preempt kthread starved for 12162 jiffies! g31645 f0x0
RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=0
rcu: Unless rcu_preempt kthread gets sufficient CPU time,
OOM is now expected behavior.
rcu: RCU grace-period kthread stack dump:
task:rcu_preempt state:R running task
...........
usbtmc 3-1:0.0: unknown status received: -71
usbtmc 3-1:0.0: unknown status received: -71
usbtmc 3-1:0.0: unknown status received: -71
usbtmc 3-1:0.0: unknown status received: -71
usbtmc 3-1:0.0: unknown status received: -71
usbtmc 3-1:0.0: unknown status received: -71
usbtmc 3-1:0.0: unknown status received: -71
usbtmc 3-1:0.0: unknown status received: -71
usbtmc 3-1:0.0: usb_submit_urb failed: -19
The function usbtmc_interrupt() resubmits urbs when the error status
of an urb is -EPROTO. In systems using the dummy_hcd usb controller
this can result in endless interrupt loops when the usbtmc device is
disconnected from the host system.
Since host controller drivers already try to recover from transmission
errors, there is no need to resubmit the urb or try other solutions
to repair the error situation.
In case of errors the INT pipe just stops to wait for further packets.
Fixes: dbf3e7f654c0 ("Implement an ioctl to support the USMTMC-USB488 READ_STATUS_BYTE operation")
Cc: [email protected]
Reported-by: [email protected]
Signed-off-by: Qiang.zhang <[email protected]>
Acked-by: Guido Kiener <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
Clock driver for this SoC is using some gates to properly enabling
and disabling the access to peripherals. Those gates that are not
in use are properly being automatically disabled by the kernel.
Pcie driver is explicitly doing a 'clk_disable_unprepare' call for
gates of those pcies that are not used. Since kernel has already
disabled them, the following warnings appear:
WARNING: CPU: 0 PID: 1 at drivers/clk/clk.c:952 clk_core_disable+0xe4/0x100
pcie2 already disabled
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.14.0 #0
Stack : 81661680 80082d00 807c0000 00000004 00000000
80a20000 80860000 80792380
814503d4 80862e83 00000000 1431b70 81454360
00000000 00000000 80792380
81431a08 ffffefff fffffea 00000000 81431a14
0000007b 80868820 ffffffff
80792380 1431c70 803d7a24 00000009 807f3a74
00000001 815df810 00000018 0000000 80a20000
...
Call Trace:
[<80007ed8>] show_stack+0x28/0xf0
[<80381e40>] dump_stack_lvl+0x60/0x80
[<8002cf90>] __warn+0xcc/0x140
[<8002d090>] warn_slowpath_fmt+0x8c/0xac
[<803d7a24>] clk_core_disable+0xe4/0x100
[<803da468>] clk_disable+0x38/0x58
[<804cb730>] mt7621_pci_probe+0x980/0xa50
[<8041e624>] platform_probe+0x50/0xbc
[<8041bfe4>] really_probe.part.0+0xa8/0x340
[<8041c3dc>] driver_probe_device+0x4c/0x154
[<8041cb88>] __driver_attach+0xb4/0x1b4
[<80419a38>] bus_for_each_dev+0x68/0xa4
[<8041b1e8>] bus_add_driver+0x134/0x214
[<8041d3bc>] driver_register+0x98/0x154
[<80001648>] do_one_initcall+0x50/0x1a8
[<808ea1fc>] kernel_init_freeable+0x270/0x30c
[<806dd9dc>] kernel_init+0x20/0x110
[<80002d98>] ret_from_kernel_thread+0x14/0x1c
WARNING: CPU: 0 PID: 1 at drivers/clk/clk.c:810 clk_core_unprepare+0xf4/0x194
pcie2 already unprepared
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 5.14.0 #0
Stack : 81661680 80082d00 807c0000 00000004 00000000
00000000 81431bc4 80a20000
80860000 80792380 814503d4 80862e83 00000000
00000001 81431b70 81454360
00000000 00000000 80792380 81431a08 ffffefff
00000000 ffffffea 00000000
81431a14 0000009b 80868820 ffffffff 80792380
00000001 81431c70 803d7764
00000009 807f3a74 00000001 815df810 00000018
8040b36c 00000000 80a20000
...
Call Trace:
[<80007ed8>] show_stack+0x28/0xf0
[<80381e40>] dump_stack_lvl+0x60/0x80
[<8002cf90>] __warn+0xcc/0x140
[<8002d090>] warn_slowpath_fmt+0x8c/0xac
[<803d7764>] clk_core_unprepare+0xf4/0x194
[<803d97c4>] clk_unprepare+0x30/0x48
[<804cb738>] mt7621_pci_probe+0x988/0xa50
[<8041e624>] platform_probe+0x50/0xbc
[<8041bfe4>] really_probe.part.0+0xa8/0x340
[<8041c3dc>] driver_probe_device+0x4c/0x154
[<8041cb88>] __driver_attach+0xb4/0x1b4
[<80419a38>] bus_for_each_dev+0x68/0xa4
[<8041b1e8>] bus_add_driver+0x134/0x214
[<8041d3bc>] driver_register+0x98/0x154
[<80001648>] do_one_initcall+0x50/0x1a8
[<808ea1fc>] kernel_init_freeable+0x270/0x30c
[<806dd9dc>] kernel_init+0x20/0x110
[<80002d98>] ret_from_kernel_thread+0x14/0x1c
Avoid to explicitly disable already disabled pcie gates
fixes the problem.
Fixes: cc4e864a5ce4 ("staging: mt7621-pci: make use of kernel clock apis")
Reported-by: DENG Qingfang <[email protected]>
Signed-off-by: Sergio Paracuellos <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
There was strange error handling logic in case of fw load failure. For
some reason fw loader callback was doing clean up stuff when fw is not
available. I don't see any reason behind doing this. Since this driver
doesn't have EEPROM firmware let's just disconnect it in case of fw load
failure. Doing clean up stuff in 2 different place which can run
concurently is not good idea and syzbot found 2 bugs related to this
strange approach.
So, in this pacth I deleted all clean up code from fw callback and made
a call to device_release_driver() under device_lock(parent) in case of fw
load failure. This approach is more generic and it defend driver from UAF
bugs, since all clean up code is moved to one place.
Fixes: e02a3b945816 ("staging: rtl8712: fix memory leak in rtl871x_load_fw_cb")
Fixes: 8c213fa59199 ("staging: r8712u: Use asynchronous firmware loading")
Cc: stable <[email protected]>
Reported-and-tested-by: [email protected]
Reported-and-tested-by: [email protected]
Signed-off-by: Pavel Skripkin <[email protected]>
Link: https://lore.kernel.org/r/d49ecc56e97c4df181d7bd4d240b031f315eacc3.1626895918.git.paskripkin@gmail.com
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
This patch is preparation for following patch for error handling
refactoring.
flush_scheduled_work() takes (wq_completion)events lock and
it can lead to deadlock when r871xu_dev_remove() is called from workqueue.
To avoid deadlock sutiation we can change flush_scheduled_work() call to
flush_work() call for all possibly scheduled works in this driver,
since next patch adds device_release_driver() in case of fw load failure.
Signed-off-by: Pavel Skripkin <[email protected]>
Cc: stable <[email protected]>
Link: https://lore.kernel.org/r/6e028b4c457eeb7156c76c6ea3cdb3cb0207c7e1.1626895918.git.paskripkin@gmail.com
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
In the function s3fwrn5_fw_download(), the 'ret' is not assigned,
so the correct value should be given in dev_err function.
Fixes: a0302ff5906a ("nfc: s3fwrn5: remove unnecessary label")
Signed-off-by: Zhang Shengju <[email protected]>
Signed-off-by: Tang Bin <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
The function uniphier_xdmac_chan_stop() is only called in atomic state.
Should use readl_poll_timeout_atomic() there instead of
readl_poll_timeout().
Reported-by: Dan Carpenter <[email protected]>
Fixes: 667b9251440b ("dmaengine: uniphier-xdmac: Add UniPhier external DMA controller driver")
Signed-off-by: Kunihiko Hayashi <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vinod Koul <[email protected]>
|
|
dma_range_map is freed to early, which might cause an oops when
a driver probe fails.
Call trace:
is_free_buddy_page+0xe4/0x1d4
__free_pages+0x2c/0x88
dma_free_contiguous+0x64/0x80
dma_direct_free+0x38/0xb4
dma_free_attrs+0x88/0xa0
dmam_release+0x28/0x34
release_nodes+0x78/0x8c
devres_release_all+0xa8/0x110
really_probe+0x118/0x2d0
__driver_probe_device+0xc8/0xe0
driver_probe_device+0x54/0xec
__driver_attach+0xe0/0xf0
bus_for_each_dev+0x7c/0xc8
driver_attach+0x30/0x3c
bus_add_driver+0x17c/0x1c4
driver_register+0xc0/0xf8
__platform_driver_register+0x34/0x40
...
This issue is introduced by commit d0243bbd5dd3 ("drivers core:
Free dma_range_map when driver probe failed"). It frees
dma_range_map before the call to devres_release_all, which is too
early. The solution is to free dma_range_map only after
devres_release_all.
Fixes: d0243bbd5dd3 ("drivers core: Free dma_range_map when driver probe failed")
Cc: stable <[email protected]>
Signed-off-by: Filip Schauer <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
Backmerging to get tree to v5.14-rc3, as requested by Daniel.
Signed-off-by: Thomas Zimmermann <[email protected]>
|
|
Syzbot reported skb_over_panic() in llc_pdu_init_as_xid_cmd(). The
problem was in wrong LCC header manipulations.
Syzbot's reproducer tries to send XID packet. llc_ui_sendmsg() is
doing following steps:
1. skb allocation with size = len + header size
len is passed from userpace and header size
is 3 since addr->sllc_xid is set.
2. skb_reserve() for header_len = 3
3. filling all other space with memcpy_from_msg()
Ok, at this moment we have fully loaded skb, only headers needs to be
filled.
Then code comes to llc_sap_action_send_xid_c(). This function pushes 3
bytes for LLC PDU header and initializes it. Then comes
llc_pdu_init_as_xid_cmd(). It initalizes next 3 bytes *AFTER* LLC PDU
header and call skb_push(skb, 3). This looks wrong for 2 reasons:
1. Bytes rigth after LLC header are user data, so this function
was overwriting payload.
2. skb_push(skb, 3) call can cause skb_over_panic() since
all free space was filled in llc_ui_sendmsg(). (This can
happen is user passed 686 len: 686 + 14 (eth header) + 3 (LLC
header) = 703. SKB_DATA_ALIGN(703) = 704)
So, in this patch I added 2 new private constansts: LLC_PDU_TYPE_U_XID
and LLC_PDU_LEN_U_XID. LLC_PDU_LEN_U_XID is used to correctly reserve
header size to handle LLC + XID case. LLC_PDU_TYPE_U_XID is used by
llc_pdu_header_init() function to push 6 bytes instead of 3. And finally
I removed skb_push() call from llc_pdu_init_as_xid_cmd().
This changes should not affect other parts of LLC, since after
all steps we just transmit buffer.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-and-tested-by: [email protected]
Signed-off-by: Pavel Skripkin <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
NIX_RX_SW_SYNC ensures all existing transactions are finished and
pkts are written to LLC/DRAM, queues should be teared down after
successful SW_SYNC. Due to a HW errata, in some rare scenarios
an existing transaction might end after SW_SYNC operation. To
ensure operation is fully done, do the SW_SYNC twice.
Signed-off-by: Sunil Goutham <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Apparently JBL Quantum 600 has multiple hardware revisions. Apply
registration quirk to another device id as well.
Signed-off-by: Alexander Tsoy <[email protected]>
Cc: <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
|