ASoC: SOF: skl add cl_stream_prepare_skl #129

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

Closed

zhuyingjiang wants to merge 3 commits into thesofproject:topic/sof-dev from zhuyingjiang:topic/sof-dev-add-prepare

zhuyingjiang commented Sep 12, 2018

add the cl_stream_prepare_skl to alloc the DMA buffer and init the DMA

zhuyingjiang added 2 commits

September 12, 2018 09:59


          ASoC:SOF:skl:enable the core and get the ROM init

1. enable the skl core
2. get the ROM int

Signed-off-by: Zhu Yingjiang <yingjiang.zhu@linux.intel.com>


          ASoC: SOF: skl enable the skl/kbl ops, instead of using apl_ops

b0c3460

Signed-off-by: Zhu Yingjiang <yingjiang.zhu@linux.intel.com>

zhuyingjiang force-pushed the topic/sof-dev-add-prepare branch from bd8dcb7 to c1b3d70 Compare

September 12, 2018 11:24


          SoC: SOF: skl add the cl_stream_prepare_skl API

81b2f48

Signed-off-by: Zhu Yingjiang <yingjiang.zhu@linux.intel.com>

zhuyingjiang requested a review from lgirdwood

September 12, 2018 13:20

zhuyingjiang force-pushed the topic/sof-dev-add-prepare branch from c1b3d70 to 81b2f48 Compare

September 12, 2018 13:37

lgirdwood reviewed

View reviewed changes

Member

lgirdwood left a comment

Looking better, but can it load any code yet ?

sound/soc/sof/intel/hda-loader.c Outdated

    
              	}

              	/* prepare DMA for code loader stream */

              	ret = cl_stream_prepare_skl(sdev, 0x40, fwsize, &sdev->dmab,

Member

lgirdwood Sep 12, 2018

where does 0x40 come from ? this should probably be a macro

sound/soc/sof/intel/hda-loader.c

    
              #include "../ops.h"

              #include "hda.h"

              #include "../../intel/skylake/skl-sst-cldma.h"

Member

lgirdwood Sep 12, 2018

If we need any macros we should define locally.

Author

zhuyingjiang Sep 13, 2018

OK, my question is to create a new head file like hda-skl.h, or just define it in hda-loader.c now? For there are too much defines for the registers, I prefer using a new head file..

Member

lgirdwood Sep 13, 2018

The registers should mostly be the same as existing ones for APL, you may need to check each one being used.

sound/soc/sof/intel/hda-loader.c

    
              }

              /* Code loader helper APIs */

              static int cl_skl_cldma_setup_bdle(struct snd_sof_dev *sdev,

Member

lgirdwood Sep 12, 2018

We already have a function for creating BDLE and should reuse it.

Author

zhuyingjiang Sep 13, 2018

OK, I will check if it can be reused.

sound/soc/sof/intel/hda-loader.c

    
              		struct snd_dma_buffer *dmab_bdl, unsigned int max_size,

              		u32 count)

              {

              	/* make sure Run bit is cleared before setting stream register */

Member

lgirdwood Sep 12, 2018

ok, so I guess this is where we differ from APL, if so is it all the register write below or only some ?

sound/soc/sof/intel/hda-loader.c

    
              				CL_SD_CTL_FEIE_MASK, CL_SD_CTL_FEIE(0));

              	snd_sof_dsp_update_bits(sdev, HDA_DSP_HDA_BAR, SKL_ADSP_REG_CL_SD_CTL,

              				CL_SD_CTL_DEIE_MASK, CL_SD_CTL_DEIE(0));

              	snd_sof_dsp_update_bits(sdev, HDA_DSP_HDA_BAR, SKL_ADSP_REG_CL_SD_CTL,

Member

lgirdwood Sep 12, 2018

These 4 writes are to same register, cant they be done as one write ?

sound/soc/sof/intel/hda-loader.c

    
              				CL_SD_CTL_DEIE_MASK, CL_SD_CTL_DEIE(1));

              	snd_sof_dsp_update_bits(sdev, HDA_DSP_HDA_BAR, SKL_ADSP_REG_CL_SD_CTL,

              				CL_SD_CTL_STRM_MASK,

              				CL_SD_CTL_STRM(FW_CL_STREAM_NUMBER));

Member

lgirdwood Sep 12, 2018

ditto, we also need comments here.

sound/soc/sof/sof-priv.h

    
              	/* firmware loader */

              	int cl_bar;

              	struct snd_dma_buffer dmab;

              	struct snd_dma_buffer dmab_bdl;

Member

lgirdwood Sep 12, 2018

do we really need this since we already have some existing bdl logic

Author

zhuyingjiang commented Sep 13, 2018

Sorry, I use the error branch to push another PR, and now I update it.
WIth this PR 2310452 is to enable the core, and I think it is OK to merge now with some comments added.
The second is b0c3460 and is only to change the old ops from apl to skl, this is also ok to merge
The third is to alloc the dma buffer, 81b2f48 , I will do change with your comments.

Author

zhuyingjiang commented Sep 13, 2018

zhuyingjiang requested a review from lgirdwood

September 13, 2018 03:49

zhuyingjiang closed this

plbossart pushed a commit that referenced this pull request


          USB: Fix invalid-free bug in port_over_current_notify()

d81bb01

Syzbot and KASAN found the following invalid-free bug in
port_over_current_notify():

--------------------------------------------------------------------------
BUG: KASAN: double-free or invalid-free in port_over_current_notify
drivers/usb/core/hub.c:5192 [inline]
BUG: KASAN: double-free or invalid-free in port_event
drivers/usb/core/hub.c:5241 [inline]
BUG: KASAN: double-free or invalid-free in hub_event+0xd97/0x4140
drivers/usb/core/hub.c:5384

CPU: 1 PID: 32710 Comm: kworker/1:3 Not tainted 4.20.0-rc3+ #129
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
  __dump_stack lib/dump_stack.c:77 [inline]
  dump_stack+0x244/0x39d lib/dump_stack.c:113
  print_address_description.cold.7+0x9/0x1ff mm/kasan/report.c:256
  kasan_report_invalid_free+0x64/0xa0 mm/kasan/report.c:336
  __kasan_slab_free+0x13a/0x150 mm/kasan/kasan.c:501
  kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
  __cache_free mm/slab.c:3498 [inline]
  kfree+0xcf/0x230 mm/slab.c:3817
  port_over_current_notify drivers/usb/core/hub.c:5192 [inline]
  port_event drivers/usb/core/hub.c:5241 [inline]
  hub_event+0xd97/0x4140 drivers/usb/core/hub.c:5384
  process_one_work+0xc90/0x1c40 kernel/workqueue.c:2153
  worker_thread+0x17f/0x1390 kernel/workqueue.c:2296
  kthread+0x35a/0x440 kernel/kthread.c:246
  ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
--------------------------------------------------------------------------

The problem is caused by use of a static array to store
environment-string pointers.  When the routine is called by multiple
threads concurrently, the pointers from one thread can overwrite those
from another.

The solution is to use an ordinary automatic array instead of a static
array.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: syzbot+98881958e1410ec7e53c@syzkaller.appspotmail.com
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

paulstelian97 pushed a commit to paulstelian97/linux that referenced this pull request


          Merge pull request thesofproject#129 from Sergiu121/labs/networking

b1c42b8

Documentation: teaching: labs: networking: Minor content fixes

kv2019i pushed a commit that referenced this pull request


          ipv4: Silence suspicious RCU usage warning

7f6f32b

fib_info_notify_update() is always called with RTNL held, but not from
an RCU read-side critical section. This leads to the following warning
[1] when the FIB table list is traversed with
hlist_for_each_entry_rcu(), but without a proper lockdep expression.

Since modification of the list is protected by RTNL, silence the warning
by adding a lockdep expression which verifies RTNL is held.

[1]
 =============================
 WARNING: suspicious RCU usage
 5.9.0-rc1-custom-14233-g2f26e122d62f #129 Not tainted
 -----------------------------
 net/ipv4/fib_trie.c:2124 RCU-list traversed in non-reader section!!

 other info that might help us debug this:

 rcu_scheduler_active = 2, debug_locks = 1
 1 lock held by ip/834:
  #0: ffffffff85a3b6b0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x49a/0xbd0

 stack backtrace:
 CPU: 0 PID: 834 Comm: ip Not tainted 5.9.0-rc1-custom-14233-g2f26e122d62f #129
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-2.fc32 04/01/2014
 Call Trace:
  dump_stack+0x100/0x184
  lockdep_rcu_suspicious+0x143/0x14d
  fib_info_notify_update+0x8d1/0xa60
  __nexthop_replace_notify+0xd2/0x290
  rtm_new_nexthop+0x35e2/0x5946
  rtnetlink_rcv_msg+0x4f7/0xbd0
  netlink_rcv_skb+0x17a/0x480
  rtnetlink_rcv+0x22/0x30
  netlink_unicast+0x5ae/0x890
  netlink_sendmsg+0x98a/0xf40
  ____sys_sendmsg+0x879/0xa00
  ___sys_sendmsg+0x122/0x190
  __sys_sendmsg+0x103/0x1d0
  __x64_sys_sendmsg+0x7d/0xb0
  do_syscall_64+0x32/0x50
  entry_SYSCALL_64_after_hwframe+0x44/0xa9
 RIP: 0033:0x7fde28c3be57
 Code: 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51
c3 48 83 ec 28 89 54 24 1c 48 89 74 24 10
RSP: 002b:00007ffc09330028 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fde28c3be57
RDX: 0000000000000000 RSI: 00007ffc09330090 RDI: 0000000000000003
RBP: 000000005f45f911 R08: 0000000000000001 R09: 00007ffc0933012c
R10: 0000000000000076 R11: 0000000000000246 R12: 0000000000000001
R13: 00007ffc09330290 R14: 00007ffc09330eee R15: 00005610e48ed020

Fixes: 1bff1a0 ("ipv4: Add function to send route updates")
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: David Ahern <dsahern@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

cujomalainey pushed a commit to cujomalainey/linux that referenced this pull request


          ipv4: Silence suspicious RCU usage warning

263e463

[ Upstream commit 7f6f32b ]

fib_info_notify_update() is always called with RTNL held, but not from
an RCU read-side critical section. This leads to the following warning
[1] when the FIB table list is traversed with
hlist_for_each_entry_rcu(), but without a proper lockdep expression.

Since modification of the list is protected by RTNL, silence the warning
by adding a lockdep expression which verifies RTNL is held.

[1]
 =============================
 WARNING: suspicious RCU usage
 5.9.0-rc1-custom-14233-g2f26e122d62f thesofproject#129 Not tainted
 -----------------------------
 net/ipv4/fib_trie.c:2124 RCU-list traversed in non-reader section!!

 other info that might help us debug this:

 rcu_scheduler_active = 2, debug_locks = 1
 1 lock held by ip/834:
  #0: ffffffff85a3b6b0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x49a/0xbd0

 stack backtrace:
 CPU: 0 PID: 834 Comm: ip Not tainted 5.9.0-rc1-custom-14233-g2f26e122d62f thesofproject#129
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-2.fc32 04/01/2014
 Call Trace:
  dump_stack+0x100/0x184
  lockdep_rcu_suspicious+0x143/0x14d
  fib_info_notify_update+0x8d1/0xa60
  __nexthop_replace_notify+0xd2/0x290
  rtm_new_nexthop+0x35e2/0x5946
  rtnetlink_rcv_msg+0x4f7/0xbd0
  netlink_rcv_skb+0x17a/0x480
  rtnetlink_rcv+0x22/0x30
  netlink_unicast+0x5ae/0x890
  netlink_sendmsg+0x98a/0xf40
  ____sys_sendmsg+0x879/0xa00
  ___sys_sendmsg+0x122/0x190
  __sys_sendmsg+0x103/0x1d0
  __x64_sys_sendmsg+0x7d/0xb0
  do_syscall_64+0x32/0x50
  entry_SYSCALL_64_after_hwframe+0x44/0xa9
 RIP: 0033:0x7fde28c3be57
 Code: 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51
c3 48 83 ec 28 89 54 24 1c 48 89 74 24 10
RSP: 002b:00007ffc09330028 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fde28c3be57
RDX: 0000000000000000 RSI: 00007ffc09330090 RDI: 0000000000000003
RBP: 000000005f45f911 R08: 0000000000000001 R09: 00007ffc0933012c
R10: 0000000000000076 R11: 0000000000000246 R12: 0000000000000001
R13: 00007ffc09330290 R14: 00007ffc09330eee R15: 00005610e48ed020

Fixes: 1bff1a0 ("ipv4: Add function to send route updates")
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: David Ahern <dsahern@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

vijendarmukunda pushed a commit to vijendarmukunda/linux that referenced this pull request


          LoongArch: BPF: Support 64-bit pointers to kfuncs

21c5ae5

Like commit 1cf3bfc ("bpf: Support 64-bit pointers to kfuncs")
for s390x, add support for 64-bit pointers to kfuncs for LoongArch.
Since the infrastructure is already implemented in BPF core, the only
thing need to be done is to override bpf_jit_supports_far_kfunc_call().

Before this change, several test_verifier tests failed:

  # ./test_verifier | grep # | grep FAIL
  thesofproject#119/p calls: invalid kfunc call: ptr_to_mem to struct with non-scalar FAIL
  thesofproject#120/p calls: invalid kfunc call: ptr_to_mem to struct with nesting depth > 4 FAIL
  thesofproject#121/p calls: invalid kfunc call: ptr_to_mem to struct with FAM FAIL
  thesofproject#122/p calls: invalid kfunc call: reg->type != PTR_TO_CTX FAIL
  thesofproject#123/p calls: invalid kfunc call: void * not allowed in func proto without mem size arg FAIL
  thesofproject#124/p calls: trigger reg2btf_ids[reg->type] for reg->type > __BPF_REG_TYPE_MAX FAIL
  thesofproject#125/p calls: invalid kfunc call: reg->off must be zero when passed to release kfunc FAIL
  thesofproject#126/p calls: invalid kfunc call: don't match first member type when passed to release kfunc FAIL
  thesofproject#127/p calls: invalid kfunc call: PTR_TO_BTF_ID with negative offset FAIL
  thesofproject#128/p calls: invalid kfunc call: PTR_TO_BTF_ID with variable offset FAIL
  thesofproject#129/p calls: invalid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL
  thesofproject#130/p calls: valid kfunc call: referenced arg needs refcounted PTR_TO_BTF_ID FAIL
  thesofproject#486/p map_kptr: ref: reference state created and released on xchg FAIL

This is because the kfuncs in the loaded module are far away from
__bpf_call_base:

  ffff800002009440 t bpf_kfunc_call_test_fail1    [bpf_testmod]
  9000000002e128d8 T __bpf_call_base

The offset relative to __bpf_call_base does NOT fit in s32, which breaks
the assumption in BPF core. Enable bpf_jit_supports_far_kfunc_call() lifts
this limit.

Note that to reproduce the above result, tools/testing/selftests/bpf/config
should be applied, and run the test with JIT enabled, unpriv BPF enabled.

With this change, the test_verifier tests now all passed:

  # ./test_verifier
  ...
  Summary: 777 PASSED, 0 SKIPPED, 0 FAILED

Tested-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet