Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dsi #17

Open
wants to merge 26 commits into
base: main
Choose a base branch
from
Open

Dsi #17

wants to merge 26 commits into from

Conversation

ljia5
Copy link

@ljia5 ljia5 commented Aug 25, 2023

No description provided.

zjin7 and others added 26 commits July 15, 2023 15:49
Change-Id: I6a89e81ca93cabd8a35848ebe61c2a29ad928738
Tracked-On:
Signed-off-by: Zhi Jin <[email protected]>
Remove Android.mk as redefine errors are seen when multiple
kernels projects are used in the Android build.

Signed-off-by: Jeevaka Prabu Badrappan <[email protected]>
This driver is required if you want to use Bluetooth devices
with USB interface to support SCO.

Tracked-On: OAM-91225
Signed-off-by: Aiswarya Cyriac <[email protected]>
In some of the C922 camera devices, we find that
GET_DEF request is not implemented for video probe
and commit controls. These cameras crash when this
request is received. Hence, add this quirk for C922
cameras.

Tracked-On: OAM-91289
Signed-off-by: saranya <[email protected]>
removing the duplicacy of snd_card_free_when_closed()
function which is called inside btusb_sco_disconnect()
function.

Tracked-On: OAM-95334
Signed-off-by: Prabhat Chand Pandey [email protected]
Intel Bluetooth adapter is not exiting the loopback mode on bluetooth
socket closure. So, when bluetooth socket is opened again, bluetooth is
not working.

As per Bluetooth core specification, bluetooth adapter should exit loop
back mode on hci reset. Add HCI quirk reset to make sure adapter exits
loopback mode on bluetooth socket closure.

Tracked-On: OAM-96067
Signed-off-by: Jeevaka Prabu Badrappan <[email protected]>
Signed-off-by: Amrita Raju <[email protected]>
Freezing of process abort when a client is waiting uninterruptibly
for a response. This happens when system is entering to suspend and
trying to freeze all the processes and at that moment freezing aborts
which leads to suspend failure. So instead of wait_event_killable()
use wait_event_freezable()

Signed-off-by: Kaushlendra Kumar <[email protected]>
Adding vendor command support for querying driver & firmware
version.

Tracked-On: OAM-94267
Signed-off-by: Jeevaka Prabu Badrappan <[email protected]>
Signed-off-by: Amrita Raju <[email protected]>
L4_PAGE_OFFSET is a constant value, so don't warn about absolute
relocations.

Tracked-On: OAM-95581
Signed-off-by: Sami Tolvanen <[email protected]>
Signed-off-by: Jeevaka Prabu Badrappan <[email protected]>
Found the deadlock issue most likely caused by thread scheduling, the
problem is like:
1, thread a call i915_active_acquire_barrier function, and will call
take_preallocated_barriers which is used to delete all list nodes with
llist_del_all
2, hw irq is raised up, thread a is scheduled out
3, thread b seems has higher priority and is scheduled in,
i915_gem_do_execbuffer->i915_active_acquire_preallocate_barrier function
is called, there is following code:
while (!llist_empty(&ref->preallocated_barriers))
    cond_resched();
ref->preallocated_barriers is not empty, then will call cond_resched.
While due to CONFIG_PREEMPT is defined, cond_resched is defined as
"return 0;" It means thread b will busy wait and will not relinquish
CPU. From log, we didn't see thread a get chance to be scheduled in.
The result is thread b is busy waiting on ref->preallocated_barriers,
dead-lock happened. At end, when rcu_cpu_stall_timeout is reached, rcu
stall is detected and pop up the kernel error.
Fix this issue by replacing cond_resched with usleep_range, to let
thread b relinquished CPU on its own.

Signed-off-by: feijiang1 <[email protected]>
Tracked-On: OAM-99194
Signed-off-by: Aiswarya Cyriac <[email protected]>
Tracked-On: OAM-100635
Signed-off-by: Aiswarya Cyriac <[email protected]>
Sometimes power button does not wake up the systemm, we get suspends
event
right after that. here Android needs to see KEY_POWER at resume.
Otherwise, its
opportunistic suspend will kick in shortly.

However, other OS such as Ubuntu doesn't like KEY_POWER at resume. So
add a knob "/sys/module/button/parameters/key_power_at_resume" for users
to select.

Tracked-On: OAM-101964
Signed-off-by: Kaushlendra Kumar <[email protected]>
Whenever VM goes for suspend if there are any
active VSOCK connections used to communicate with host
respective vsock connections were unable to resume as
freeze and restore functionality was not implemented i
virtio driver.
This change will fix VSOCK reconnect in case
of Suspend and Resume

In freeze case:
Change will reset all connected sockets when the devic
disappears and flush all device writes and interrupts
and also delete virtqueues and flush outstanding
callbacks if any.

In Restore case:
Change will initialize all the necessary parameter to
make the virtio device ready

Tracked-On: OAM-100107
Signed-off-by: Stefano Garzarella <[email protected]
Signed-off-by: Vilas R K <[email protected]>
Signed-off-by: Bharat Panda <[email protected]>
Intel Bluetooth adapter is not exiting the loopback mode on bluetooth
socket closure. So, when bluetooth socket is opened again, bluetooth is
not working.

As per Bluetooth core specification, bluetooth adapter should exit loop
back mode on hci reset. Add HCI quirk reset to make sure adapter exits
loopback mode on bluetooth socket closure.

Tracked-On: OAM-102732
Signed-off-by: Suresh, Prashanth <[email protected]>
add intel ipu6 driver
revert old virtual channel api in v4l2
add sensor driver for IVI

Change-Id: Ia1d3f444ffebfa8925131e54405c088a9989c0d9
Tracked-On: OAM-104898
Signed-off-by: Wang Yating <[email protected]>
Disable instruction prefetch for performance improvement
on kernel 5.15.71.

Change-Id: I11e1a50412fa9d27cab635c79da1ee1ab2059022
Tracked-On: OAM-105269
Signed-off-by: Ben Lin <[email protected]>
Add hkr camera driver

Tracked-On: OAM-104898
Signed-off-by: Wang Yating <[email protected]>
[Changes]
Fix HKR capture fps issue
remove unused IPU driver files
upgrade isx031 sensor driver

Tracked-On: OAM-105409
Signed-off-by: Wang Yating <[email protected]>
[Changes]
use ktime_get_ns() mark stream timestamp

Tracked-On: OAM-105432
Signed-off-by: Wang Yating <[email protected]>
Change-Id: I516132585bab97d74ec3893f83382da7e246745c
Tracked-On: OAM-104032
Signed-off-by: Jeevaka Prabu Badrappan <[email protected]>
GuC provides engine_id and last_switch_in ticks for an active context in the
pphwsp. The context image provides a 32 bit total ticks which is the accumulated
by the context (a.k.a. context[CTX_TIMESTAMP]). This information is used to
calculate the context busyness as follows:

If the engine_id is valid, then busyness is the sum of accumulated total ticks
and active ticks. Active ticks is calculated with current gt time as reference.

If engine_id is invalid, busyness is equal to accumulated total ticks.

Since KMD (CPU) retrieves busyness data from 2 sources - GPU and GuC, a
potential race was highlighted in an earlier review that can lead to double
accounting of busyness. While the solution to this is a wip, busyness is still
usable for platforms running GuC submission.

Signed-off-by: John Harrison <[email protected]>
Signed-off-by: Umesh Nerlige Ramappa <[email protected]>
sysopenci pushed a commit that referenced this pull request Dec 6, 2023
commit 0b0747d507bffb827e40fc0f9fb5883fffc23477 upstream.

The following processes run into a deadlock. CPU 41 was waiting for CPU 29
to handle a CSD request while holding spinlock "crashdump_lock", but CPU 29
was hung by that spinlock with IRQs disabled.

  PID: 17360    TASK: ffff95c1090c5c40  CPU: 41  COMMAND: "mrdiagd"
  !# 0 [ffffb80edbf37b58] __read_once_size at ffffffff9b871a40 include/linux/compiler.h:185:0
  !# 1 [ffffb80edbf37b58] atomic_read at ffffffff9b871a40 arch/x86/include/asm/atomic.h:27:0
  !# 2 [ffffb80edbf37b58] dump_stack at ffffffff9b871a40 lib/dump_stack.c:54:0
   # 3 [ffffb80edbf37b78] csd_lock_wait_toolong at ffffffff9b131ad5 kernel/smp.c:364:0
   # 4 [ffffb80edbf37b78] __csd_lock_wait at ffffffff9b131ad5 kernel/smp.c:384:0
   # 5 [ffffb80edbf37bf8] csd_lock_wait at ffffffff9b13267a kernel/smp.c:394:0
   # 6 [ffffb80edbf37bf8] smp_call_function_many at ffffffff9b13267a kernel/smp.c:843:0
   # 7 [ffffb80edbf37c50] smp_call_function at ffffffff9b13279d kernel/smp.c:867:0
   # 8 [ffffb80edbf37c50] on_each_cpu at ffffffff9b13279d kernel/smp.c:976:0
   # 9 [ffffb80edbf37c78] flush_tlb_kernel_range at ffffffff9b085c4b arch/x86/mm/tlb.c:742:0
   #10 [ffffb80edbf37cb8] __purge_vmap_area_lazy at ffffffff9b23a1e0 mm/vmalloc.c:701:0
   #11 [ffffb80edbf37ce0] try_purge_vmap_area_lazy at ffffffff9b23a2cc mm/vmalloc.c:722:0
   #12 [ffffb80edbf37ce0] free_vmap_area_noflush at ffffffff9b23a2cc mm/vmalloc.c:754:0
   #13 [ffffb80edbf37cf8] free_unmap_vmap_area at ffffffff9b23bb3b mm/vmalloc.c:764:0
   #14 [ffffb80edbf37cf8] remove_vm_area at ffffffff9b23bb3b mm/vmalloc.c:1509:0
   #15 [ffffb80edbf37d18] __vunmap at ffffffff9b23bb8a mm/vmalloc.c:1537:0
   #16 [ffffb80edbf37d40] vfree at ffffffff9b23bc85 mm/vmalloc.c:1612:0
   #17 [ffffb80edbf37d58] megasas_free_host_crash_buffer [megaraid_sas] at ffffffffc020b7f2 drivers/scsi/megaraid/megaraid_sas_fusion.c:3932:0
   #18 [ffffb80edbf37d80] fw_crash_state_store [megaraid_sas] at ffffffffc01f804d drivers/scsi/megaraid/megaraid_sas_base.c:3291:0
   #19 [ffffb80edbf37dc0] dev_attr_store at ffffffff9b56dd7b drivers/base/core.c:758:0
   #20 [ffffb80edbf37dd0] sysfs_kf_write at ffffffff9b326acf fs/sysfs/file.c:144:0
   #21 [ffffb80edbf37de0] kernfs_fop_write at ffffffff9b325fd4 fs/kernfs/file.c:316:0
   #22 [ffffb80edbf37e20] __vfs_write at ffffffff9b29418a fs/read_write.c:480:0
   #23 [ffffb80edbf37ea8] vfs_write at ffffffff9b294462 fs/read_write.c:544:0
   #24 [ffffb80edbf37ee8] SYSC_write at ffffffff9b2946ec fs/read_write.c:590:0
   #25 [ffffb80edbf37ee8] SyS_write at ffffffff9b2946ec fs/read_write.c:582:0
   #26 [ffffb80edbf37f30] do_syscall_64 at ffffffff9b003ca9 arch/x86/entry/common.c:298:0
   #27 [ffffb80edbf37f58] entry_SYSCALL_64 at ffffffff9ba001b1 arch/x86/entry/entry_64.S:238:0

  PID: 17355    TASK: ffff95c1090c3d80  CPU: 29  COMMAND: "mrdiagd"
  !# 0 [ffffb80f2d3c7d30] __read_once_size at ffffffff9b0f2ab0 include/linux/compiler.h:185:0
  !# 1 [ffffb80f2d3c7d30] native_queued_spin_lock_slowpath at ffffffff9b0f2ab0 kernel/locking/qspinlock.c:368:0
   # 2 [ffffb80f2d3c7d58] pv_queued_spin_lock_slowpath at ffffffff9b0f244b arch/x86/include/asm/paravirt.h:674:0
   # 3 [ffffb80f2d3c7d58] queued_spin_lock_slowpath at ffffffff9b0f244b arch/x86/include/asm/qspinlock.h:53:0
   # 4 [ffffb80f2d3c7d68] queued_spin_lock at ffffffff9b8961a6 include/asm-generic/qspinlock.h:90:0
   # 5 [ffffb80f2d3c7d68] do_raw_spin_lock_flags at ffffffff9b8961a6 include/linux/spinlock.h:173:0
   # 6 [ffffb80f2d3c7d68] __raw_spin_lock_irqsave at ffffffff9b8961a6 include/linux/spinlock_api_smp.h:122:0
   # 7 [ffffb80f2d3c7d68] _raw_spin_lock_irqsave at ffffffff9b8961a6 kernel/locking/spinlock.c:160:0
   # 8 [ffffb80f2d3c7d88] fw_crash_buffer_store [megaraid_sas] at ffffffffc01f8129 drivers/scsi/megaraid/megaraid_sas_base.c:3205:0
   # 9 [ffffb80f2d3c7dc0] dev_attr_store at ffffffff9b56dd7b drivers/base/core.c:758:0
   #10 [ffffb80f2d3c7dd0] sysfs_kf_write at ffffffff9b326acf fs/sysfs/file.c:144:0
   #11 [ffffb80f2d3c7de0] kernfs_fop_write at ffffffff9b325fd4 fs/kernfs/file.c:316:0
   #12 [ffffb80f2d3c7e20] __vfs_write at ffffffff9b29418a fs/read_write.c:480:0
   #13 [ffffb80f2d3c7ea8] vfs_write at ffffffff9b294462 fs/read_write.c:544:0
   #14 [ffffb80f2d3c7ee8] SYSC_write at ffffffff9b2946ec fs/read_write.c:590:0
   #15 [ffffb80f2d3c7ee8] SyS_write at ffffffff9b2946ec fs/read_write.c:582:0
   #16 [ffffb80f2d3c7f30] do_syscall_64 at ffffffff9b003ca9 arch/x86/entry/common.c:298:0
   #17 [ffffb80f2d3c7f58] entry_SYSCALL_64 at ffffffff9ba001b1 arch/x86/entry/entry_64.S:238:0

The lock is used to synchronize different sysfs operations, it doesn't
protect any resource that will be touched by an interrupt. Consequently
it's not required to disable IRQs. Replace the spinlock with a mutex to fix
the deadlock.

Signed-off-by: Junxiao Bi <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Mike Christie <[email protected]>
Cc: [email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
sysopenci pushed a commit that referenced this pull request Dec 6, 2023
[ Upstream commit a154f5f643c6ecddd44847217a7a3845b4350003 ]

The following call trace shows a deadlock issue due to recursive locking of
mutex "device_mutex". First lock acquire is in target_for_each_device() and
second in target_free_device().

 PID: 148266   TASK: ffff8be21ffb5d00  CPU: 10   COMMAND: "iscsi_ttx"
  #0 [ffffa2bfc9ec3b18] __schedule at ffffffffa8060e7f
  #1 [ffffa2bfc9ec3ba0] schedule at ffffffffa8061224
  #2 [ffffa2bfc9ec3bb8] schedule_preempt_disabled at ffffffffa80615ee
  #3 [ffffa2bfc9ec3bc8] __mutex_lock at ffffffffa8062fd7
  #4 [ffffa2bfc9ec3c40] __mutex_lock_slowpath at ffffffffa80631d3
  #5 [ffffa2bfc9ec3c50] mutex_lock at ffffffffa806320c
  #6 [ffffa2bfc9ec3c68] target_free_device at ffffffffc0935998 [target_core_mod]
  #7 [ffffa2bfc9ec3c90] target_core_dev_release at ffffffffc092f975 [target_core_mod]
  #8 [ffffa2bfc9ec3ca0] config_item_put at ffffffffa79d250f
  #9 [ffffa2bfc9ec3cd0] config_item_put at ffffffffa79d2583
 #10 [ffffa2bfc9ec3ce0] target_devices_idr_iter at ffffffffc0933f3a [target_core_mod]
 #11 [ffffa2bfc9ec3d00] idr_for_each at ffffffffa803f6fc
 #12 [ffffa2bfc9ec3d60] target_for_each_device at ffffffffc0935670 [target_core_mod]
 #13 [ffffa2bfc9ec3d98] transport_deregister_session at ffffffffc0946408 [target_core_mod]
 #14 [ffffa2bfc9ec3dc8] iscsit_close_session at ffffffffc09a44a6 [iscsi_target_mod]
 #15 [ffffa2bfc9ec3df0] iscsit_close_connection at ffffffffc09a4a88 [iscsi_target_mod]
 #16 [ffffa2bfc9ec3df8] finish_task_switch at ffffffffa76e5d07
 #17 [ffffa2bfc9ec3e78] iscsit_take_action_for_connection_exit at ffffffffc0991c23 [iscsi_target_mod]
 #18 [ffffa2bfc9ec3ea0] iscsi_target_tx_thread at ffffffffc09a403b [iscsi_target_mod]
 #19 [ffffa2bfc9ec3f08] kthread at ffffffffa76d8080
 #20 [ffffa2bfc9ec3f50] ret_from_fork at ffffffffa8200364

Fixes: 36d4cb4 ("scsi: target: Avoid that EXTENDED COPY commands trigger lock inversion")
Signed-off-by: Junxiao Bi <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Mike Christie <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
JeevakaPrabu pushed a commit that referenced this pull request Jun 20, 2024
[ Upstream commit f8bbc07ac535593139c875ffa19af924b1084540 ]

vhost_worker will call tun call backs to receive packets. If too many
illegal packets arrives, tun_do_read will keep dumping packet contents.
When console is enabled, it will costs much more cpu time to dump
packet and soft lockup will be detected.

net_ratelimit mechanism can be used to limit the dumping rate.

PID: 33036    TASK: ffff949da6f20000  CPU: 23   COMMAND: "vhost-32980"
 #0 [fffffe00003fce50] crash_nmi_callback at ffffffff89249253
 #1 [fffffe00003fce58] nmi_handle at ffffffff89225fa3
 #2 [fffffe00003fceb0] default_do_nmi at ffffffff8922642e
 #3 [fffffe00003fced0] do_nmi at ffffffff8922660d
 #4 [fffffe00003fcef0] end_repeat_nmi at ffffffff89c01663
    [exception RIP: io_serial_in+20]
    RIP: ffffffff89792594  RSP: ffffa655314979e8  RFLAGS: 00000002
    RAX: ffffffff89792500  RBX: ffffffff8af428a0  RCX: 0000000000000000
    RDX: 00000000000003fd  RSI: 0000000000000005  RDI: ffffffff8af428a0
    RBP: 0000000000002710   R8: 0000000000000004   R9: 000000000000000f
    R10: 0000000000000000  R11: ffffffff8acbf64f  R12: 0000000000000020
    R13: ffffffff8acbf698  R14: 0000000000000058  R15: 0000000000000000
    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
 #5 [ffffa655314979e8] io_serial_in at ffffffff89792594
 #6 [ffffa655314979e8] wait_for_xmitr at ffffffff89793470
 #7 [ffffa65531497a08] serial8250_console_putchar at ffffffff897934f6
 #8 [ffffa65531497a20] uart_console_write at ffffffff8978b605
 #9 [ffffa65531497a48] serial8250_console_write at ffffffff89796558
 #10 [ffffa65531497ac8] console_unlock at ffffffff89316124
 #11 [ffffa65531497b10] vprintk_emit at ffffffff89317c07
 #12 [ffffa65531497b68] printk at ffffffff89318306
 #13 [ffffa65531497bc8] print_hex_dump at ffffffff89650765
 #14 [ffffa65531497ca8] tun_do_read at ffffffffc0b06c27 [tun]
 #15 [ffffa65531497d38] tun_recvmsg at ffffffffc0b06e34 [tun]
 #16 [ffffa65531497d68] handle_rx at ffffffffc0c5d682 [vhost_net]
 #17 [ffffa65531497ed0] vhost_worker at ffffffffc0c644dc [vhost]
 #18 [ffffa65531497f10] kthread at ffffffff892d2e72
 #19 [ffffa65531497f50] ret_from_fork at ffffffff89c0022f

Fixes: ef3db4a ("tun: avoid BUG, dump packet on GSO errors")
Signed-off-by: Lei Chen <[email protected]>
Reviewed-by: Willem de Bruijn <[email protected]>
Acked-by: Jason Wang <[email protected]>
Reviewed-by: Eric Dumazet <[email protected]>
Acked-by: Michael S. Tsirkin <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
@sysopenci sysopenci added the Stale Stale label for inactive open prs label Sep 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Stale Stale label for inactive open prs
Projects
None yet
Development

Successfully merging this pull request may close these issues.