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.

Sign up for GitHub

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

Jump to bottom

Update quirks.c for Native DSD Support with XMOS U208 USB Interface #5

Open
wants to merge 1 commit into
base: sunxi-4.x.y
Choose a base branch
from
Open

Update quirks.c for Native DSD Support with XMOS U208 USB Interface #5

wants to merge 1 commit into from

Conversation

tapairmax
Copy link

@tapairmax tapairmax commented Oct 23, 2018 •
edited
Loading

Add support for Native DSD format to Armature HECATE USB interface device. This card is similar to the Singxer F1 device, both use the same XMOS U208 chipset with the same 'chip->usb_id' tag.
This modification has been tested successfully with the Armature Hecate board.

@tapairmax
Update quirks.c
097d5c2 
Add support for Native DSD format to Armature HECATE USB interface card. This card is similar to the Singxer F1 car, both use the same XMOS U208 chipset with the same 'chip->usb_id' tag.
@tapairmax tapairmax changed the title Update quirks.c Update quirks.c for Native DSD Support with XMOS U208 USB Interface Oct 25, 2018
@tapairmax
Copy link
Author

diff --git a/sound/usb/quirks.c b/sound/usb/quirks.c
index ad14d6b78bdcf..8f236a489933c 100644
--- a/sound/usb/quirks.c
+++ b/sound/usb/quirks.c
@@ -1368,6 +1368,7 @@ u64 snd_usb_interface_dsd_format_quirks(struct snd_usb_audio chip,
case USB_ID(0x20b1, 0x2009): / DIYINHK DSD DXD 384kHz USB to I2S/DSD /
case USB_ID(0x20b1, 0x2023): / JLsounds I2SoverUSB /
case USB_ID(0x20b1, 0x3023): / Aune X1S 32BIT/384 DSD DAC */

  • case USB_ID(0x20b1, 0x3086): /* ARMATURE Hecate /
    case USB_ID(0x2616, 0x0106): /     PS Audio NuWave DAC */
    if (fp->altsetting == 3)
    return SNDRV_PCM_FMTBIT_DSD_U32_BE;

pikatenor pushed a commit to pikatenor/linux that referenced this pull request Apr 11, 2023
@gregkh
net/smc: fix potential panic dues to unprotected smc_llc_srv_add_link()
0c764cc 
[ Upstream commit e40b801 ]

There is a certain chance to trigger the following panic:

PID: 5900   TASK: ffff88c1c8af4100  CPU: 1   COMMAND: "kworker/1:48"
 #0 [ffff9456c1cc79a0] machine_kexec at ffffffff870665b7
 friendlyarm#1 [ffff9456c1cc79f0] __crash_kexec at ffffffff871b4c7a
 friendlyarm#2 [ffff9456c1cc7ab0] crash_kexec at ffffffff871b5b60
 friendlyarm#3 [ffff9456c1cc7ac0] oops_end at ffffffff87026ce7
 friendlyarm#4 [ffff9456c1cc7ae0] page_fault_oops at ffffffff87075715
 friendlyarm#5 [ffff9456c1cc7b58] exc_page_fault at ffffffff87ad0654
 friendlyarm#6 [ffff9456c1cc7b80] asm_exc_page_fault at ffffffff87c00b62
    [exception RIP: ib_alloc_mr+19]
    RIP: ffffffffc0c9cce3  RSP: ffff9456c1cc7c38  RFLAGS: 00010202
    RAX: 0000000000000000  RBX: 0000000000000002  RCX: 0000000000000004
    RDX: 0000000000000010  RSI: 0000000000000000  RDI: 0000000000000000
    RBP: ffff88c1ea281d00   R8: 000000020a34ffff   R9: ffff88c1350bbb20
    R10: 0000000000000000  R11: 0000000000000001  R12: 0000000000000000
    R13: 0000000000000010  R14: ffff88c1ab040a50  R15: ffff88c1ea281d00
    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
 friendlyarm#7 [ffff9456c1cc7c60] smc_ib_get_memory_region at ffffffffc0aff6df [smc]
 friendlyarm#8 [ffff9456c1cc7c88] smcr_buf_map_link at ffffffffc0b0278c [smc]
 friendlyarm#9 [ffff9456c1cc7ce0] __smc_buf_create at ffffffffc0b03586 [smc]

The reason here is that when the server tries to create a second link,
smc_llc_srv_add_link() has no protection and may add a new link to
link group. This breaks the security environment protected by
llc_conf_mutex.

Fixes: 2d2209f ("net/smc: first part of add link processing as SMC server")
Signed-off-by: D. Wythe <[email protected]>
Reviewed-by: Larysa Zaremba <[email protected]>
Reviewed-by: Wenjia Zhang <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
pikatenor pushed a commit to pikatenor/linux that referenced this pull request Apr 11, 2023
@gregkh
perf record: Fix segfault with --overwrite and --max-size
476ffae 
[ Upstream commit 91621be ]

When --overwrite and --max-size options of perf record are used
together, a segmentation fault occurs. The following is an example:

  # perf record -e sched:sched* --overwrite --max-size 1K -a -- sleep 1
  [ perf record: Woken up 1 times to write data ]
  perf: Segmentation fault
  Obtained 12 stack frames.
  ./perf/perf(+0x197673) [0x55f99710b673]
  /lib/x86_64-linux-gnu/libc.so.6(+0x3ef0f) [0x7fa45f3cff0f]
  ./perf/perf(+0x8eb40) [0x55f997002b40]
  ./perf/perf(+0x1f6882) [0x55f99716a882]
  ./perf/perf(+0x794c2) [0x55f996fed4c2]
  ./perf/perf(+0x7b7c7) [0x55f996fef7c7]
  ./perf/perf(+0x9074b) [0x55f99700474b]
  ./perf/perf(+0x12e23c) [0x55f9970a223c]
  ./perf/perf(+0x12e54a) [0x55f9970a254a]
  ./perf/perf(+0x7db60) [0x55f996ff1b60]
  /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe6) [0x7fa45f3b2c86]
  ./perf/perf(+0x7dfe9) [0x55f996ff1fe9]
  Segmentation fault (core dumped)

backtrace of the core file is as follows:

  (gdb) bt
  #0  record__bytes_written (rec=0x55f99755a200 <record>) at builtin-record.c:234
  friendlyarm#1  record__output_max_size_exceeded (rec=0x55f99755a200 <record>) at builtin-record.c:242
  friendlyarm#2  record__write (map=0x0, size=12816, bf=0x55f9978da2e0, rec=0x55f99755a200 <record>) at builtin-record.c:263
  friendlyarm#3  process_synthesized_event (tool=tool@entry=0x55f99755a200 <record>, event=event@entry=0x55f9978da2e0, sample=sample@entry=0x0, machine=machine@entry=0x55f997893658) at builtin-record.c:618
  friendlyarm#4  0x000055f99716a883 in __perf_event__synthesize_id_index (tool=tool@entry=0x55f99755a200 <record>, process=process@entry=0x55f997002aa0 <process_synthesized_event>, evlist=0x55f9978928b0, machine=machine@entry=0x55f997893658,
      from=from@entry=0) at util/synthetic-events.c:1895
  friendlyarm#5  0x000055f99716a91f in perf_event__synthesize_id_index (tool=tool@entry=0x55f99755a200 <record>, process=process@entry=0x55f997002aa0 <process_synthesized_event>, evlist=<optimized out>, machine=machine@entry=0x55f997893658)
      at util/synthetic-events.c:1905
  friendlyarm#6  0x000055f996fed4c3 in record__synthesize (tail=tail@entry=true, rec=0x55f99755a200 <record>) at builtin-record.c:1997
  friendlyarm#7  0x000055f996fef7c8 in __cmd_record (argc=argc@entry=2, argv=argv@entry=0x7ffc67551260, rec=0x55f99755a200 <record>) at builtin-record.c:2802
  friendlyarm#8  0x000055f99700474c in cmd_record (argc=<optimized out>, argv=0x7ffc67551260) at builtin-record.c:4258
  friendlyarm#9  0x000055f9970a223d in run_builtin (p=0x55f997564d88 <commands+264>, argc=10, argv=0x7ffc67551260) at perf.c:330
  torvalds#10 0x000055f9970a254b in handle_internal_command (argc=10, argv=0x7ffc67551260) at perf.c:384
  torvalds#11 0x000055f996ff1b61 in run_argv (argcp=<synthetic pointer>, argv=<synthetic pointer>) at perf.c:428
  torvalds#12 main (argc=<optimized out>, argv=0x7ffc67551260) at perf.c:562

The reason is that record__bytes_written accesses the freed memory rec->thread_data,
The process is as follows:
  __cmd_record
    -> record__free_thread_data
      -> zfree(&rec->thread_data)         // free rec->thread_data
    -> record__synthesize
      -> perf_event__synthesize_id_index
        -> process_synthesized_event
          -> record__write
            -> record__bytes_written      // access rec->thread_data

We add a member variable "thread_bytes_written" in the struct "record"
to save the data size written by the threads.

Fixes: 6d57581 ("perf record: Add support for limit perf output file size")
Signed-off-by: Yang Jihong <[email protected]>
Acked-by: Namhyung Kim <[email protected]>
Cc: Alexander Shishkin <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: Jiwei Sun <[email protected]>
Cc: Mark Rutland <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Link: https://lore.kernel.org/r/CAM9d7ci_TRrqBQVQNW8=GwakUr7SsZpYxaaty-S4bxF8zJWyqw@mail.gmail.com
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
pikatenor pushed a commit to pikatenor/linux that referenced this pull request Apr 11, 2023
@gregkh
ocfs2: fix defrag path triggering jbd2 ASSERT
590507e 
commit 60eed1e upstream.

code path:

ocfs2_ioctl_move_extents
 ocfs2_move_extents
  ocfs2_defrag_extent
   __ocfs2_move_extent
    + ocfs2_journal_access_di
    + ocfs2_split_extent  //sub-paths call jbd2_journal_restart
    + ocfs2_journal_dirty //crash by jbs2 ASSERT

crash stacks:

PID: 11297  TASK: ffff974a676dcd00  CPU: 67  COMMAND: "defragfs.ocfs2"
 #0 [ffffb25d8dad3900] machine_kexec at ffffffff8386fe01
 friendlyarm#1 [ffffb25d8dad3958] __crash_kexec at ffffffff8395959d
 friendlyarm#2 [ffffb25d8dad3a20] crash_kexec at ffffffff8395a45d
 friendlyarm#3 [ffffb25d8dad3a38] oops_end at ffffffff83836d3f
 friendlyarm#4 [ffffb25d8dad3a58] do_trap at ffffffff83833205
 friendlyarm#5 [ffffb25d8dad3aa0] do_invalid_op at ffffffff83833aa6
 friendlyarm#6 [ffffb25d8dad3ac0] invalid_op at ffffffff84200d18
    [exception RIP: jbd2_journal_dirty_metadata+0x2ba]
    RIP: ffffffffc09ca54a  RSP: ffffb25d8dad3b70  RFLAGS: 00010207
    RAX: 0000000000000000  RBX: ffff9706eedc5248  RCX: 0000000000000000
    RDX: 0000000000000001  RSI: ffff97337029ea28  RDI: ffff9706eedc5250
    RBP: ffff9703c3520200   R8: 000000000f46b0b2   R9: 0000000000000000
    R10: 0000000000000001  R11: 00000001000000fe  R12: ffff97337029ea28
    R13: 0000000000000000  R14: ffff9703de59bf60  R15: ffff9706eedc5250
    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
 friendlyarm#7 [ffffb25d8dad3ba8] ocfs2_journal_dirty at ffffffffc137fb95 [ocfs2]
 friendlyarm#8 [ffffb25d8dad3be8] __ocfs2_move_extent at ffffffffc139a950 [ocfs2]
 friendlyarm#9 [ffffb25d8dad3c80] ocfs2_defrag_extent at ffffffffc139b2d2 [ocfs2]

Analysis

This bug has the same root cause of 'commit 7f27ec9 ("ocfs2: call
ocfs2_journal_access_di() before ocfs2_journal_dirty() in
ocfs2_write_end_nolock()")'.  For this bug, jbd2_journal_restart() is
called by ocfs2_split_extent() during defragmenting.

How to fix

For ocfs2_split_extent() can handle journal operations totally by itself.
Caller doesn't need to call journal access/dirty pair, and caller only
needs to call journal start/stop pair.  The fix method is to remove
journal access/dirty from __ocfs2_move_extent().

The discussion for this patch:
https://oss.oracle.com/pipermail/ocfs2-devel/2023-February/000647.html

Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Heming Zhao <[email protected]>
Reviewed-by: Joseph Qi <[email protected]>
Cc: Mark Fasheh <[email protected]>
Cc: Joel Becker <[email protected]>
Cc: Junxiao Bi <[email protected]>
Cc: Changwei Ge <[email protected]>
Cc: Gang He <[email protected]>
Cc: Jun Piao <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
pikatenor pushed a commit to pikatenor/linux that referenced this pull request Apr 11, 2023
@sassmann @gregkh
iavf: fix hang on reboot with ice
f752ace 
[ Upstream commit 4e264be ]

When a system with E810 with existing VFs gets rebooted the following
hang may be observed.

 Pid 1 is hung in iavf_remove(), part of a network driver:
 PID: 1        TASK: ffff965400e5a340  CPU: 24   COMMAND: "systemd-shutdow"
  #0 [ffffaad04005fa50] __schedule at ffffffff8b3239cb
  friendlyarm#1 [ffffaad04005fae8] schedule at ffffffff8b323e2d
  friendlyarm#2 [ffffaad04005fb00] schedule_hrtimeout_range_clock at ffffffff8b32cebc
  friendlyarm#3 [ffffaad04005fb80] usleep_range_state at ffffffff8b32c930
  friendlyarm#4 [ffffaad04005fbb0] iavf_remove at ffffffffc12b9b4c [iavf]
  friendlyarm#5 [ffffaad04005fbf0] pci_device_remove at ffffffff8add7513
  friendlyarm#6 [ffffaad04005fc10] device_release_driver_internal at ffffffff8af08baa
  friendlyarm#7 [ffffaad04005fc40] pci_stop_bus_device at ffffffff8adcc5fc
  friendlyarm#8 [ffffaad04005fc60] pci_stop_and_remove_bus_device at ffffffff8adcc81e
  friendlyarm#9 [ffffaad04005fc70] pci_iov_remove_virtfn at ffffffff8adf9429
 torvalds#10 [ffffaad04005fca8] sriov_disable at ffffffff8adf98e4
 torvalds#11 [ffffaad04005fcc8] ice_free_vfs at ffffffffc04bb2c8 [ice]
 torvalds#12 [ffffaad04005fd10] ice_remove at ffffffffc04778fe [ice]
 torvalds#13 [ffffaad04005fd38] ice_shutdown at ffffffffc0477946 [ice]
 torvalds#14 [ffffaad04005fd50] pci_device_shutdown at ffffffff8add58f1
 torvalds#15 [ffffaad04005fd70] device_shutdown at ffffffff8af05386
 torvalds#16 [ffffaad04005fd98] kernel_restart at ffffffff8a92a870
 torvalds#17 [ffffaad04005fda8] __do_sys_reboot at ffffffff8a92abd6
 torvalds#18 [ffffaad04005fee0] do_syscall_64 at ffffffff8b317159
 torvalds#19 [ffffaad04005ff08] __context_tracking_enter at ffffffff8b31b6fc
 torvalds#20 [ffffaad04005ff18] syscall_exit_to_user_mode at ffffffff8b31b50d
 torvalds#21 [ffffaad04005ff28] do_syscall_64 at ffffffff8b317169
 torvalds#22 [ffffaad04005ff50] entry_SYSCALL_64_after_hwframe at ffffffff8b40009b
     RIP: 00007f1baa5c13d7  RSP: 00007fffbcc55a98  RFLAGS: 00000202
     RAX: ffffffffffffffda  RBX: 0000000000000000  RCX: 00007f1baa5c13d7
     RDX: 0000000001234567  RSI: 0000000028121969  RDI: 00000000fee1dead
     RBP: 00007fffbcc55ca0   R8: 0000000000000000   R9: 00007fffbcc54e90
     R10: 00007fffbcc55050  R11: 0000000000000202  R12: 0000000000000005
     R13: 0000000000000000  R14: 00007fffbcc55af0  R15: 0000000000000000
     ORIG_RAX: 00000000000000a9  CS: 0033  SS: 002b

During reboot all drivers PM shutdown callbacks are invoked.
In iavf_shutdown() the adapter state is changed to __IAVF_REMOVE.
In ice_shutdown() the call chain above is executed, which at some point
calls iavf_remove(). However iavf_remove() expects the VF to be in one
of the states __IAVF_RUNNING, __IAVF_DOWN or __IAVF_INIT_FAILED. If
that's not the case it sleeps forever.
So if iavf_shutdown() gets invoked before iavf_remove() the system will
hang indefinitely because the adapter is already in state __IAVF_REMOVE.

Fix this by returning from iavf_remove() if the state is __IAVF_REMOVE,
as we already went through iavf_shutdown().

Fixes: 9745780 ("iavf: Add waiting so the port is initialized in remove")
Fixes: a841733 ("iavf: Fix race condition between iavf_shutdown and iavf_remove")
Reported-by: Marius Cornea <[email protected]>
Signed-off-by: Stefan Assmann <[email protected]>
Reviewed-by: Michal Kubiak <[email protected]>
Tested-by: Rafal Romanowski <[email protected]>
Signed-off-by: Tony Nguyen <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
1 participant
@tapairmax