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

ASoC: SOF: skl Topic/sof dev enable skl #128

Closed
wants to merge 2 commits into from
Closed

ASoC: SOF: skl Topic/sof dev enable skl #128

wants to merge 2 commits into from

Conversation

zhuyingjiang
Copy link

enable the skl/kbl ops, instead of using apl_ops

@zhuyingjiang zhuyingjiang changed the title Topic/sof dev enable skl ASoC: SOF: skl Topic/sof dev enable skl Sep 12, 2018
lgirdwood
lgirdwood reviewed Sep 12, 2018
View reviewed changes
Copy link
Member

@lgirdwood lgirdwood left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I'm not sure of the overall differences between this PR and the other one. Should one PR be closed ?

sound/soc/sof/intel/hda-dsp.c
@@ -208,6 +208,21 @@ bool hda_dsp_core_is_enabled(struct snd_sof_dev *sdev,
return is_enable;
}

int hda_dsp_enable_core(struct snd_sof_dev *sdev, unsigned int core_mask)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally f you have to number features in a patch commit message it means the patch needs split into more smaller patches

@zhuyingjiang
Copy link
Author

@lgirdwood is it OK for merge the first two patch?

lgirdwood
lgirdwood requested changes Sep 13, 2018
View reviewed changes
Copy link
Member

@lgirdwood lgirdwood left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The commit message needs updated. e.g.
This patch enables the SKL DSP core and waits for the ROM init code.

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

static int cl_copy_fw_skl(struct snd_sof_dev *sdev)
{
return -1;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This needs removed for merge

sound/soc/sof/intel/hda-loader.c
goto out;
}

ret = -EIO;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't we return 0 here for success ?

@lgirdwood
Copy link
Member

@zhuyingjiang generally all debug must be removed before merge. Two other comments.

@zhuyingjiang zhuyingjiang deleted the topic/sof-dev-enable-skl branch September 14, 2018 07:28
cujomalainey pushed a commit to cujomalainey/linux that referenced this pull request Apr 23, 2020
@kvaneesh @gregkh
powerpc/hash64/devmap: Use H_PAGE_THP_HUGE when setting up huge devma…
bd0fa14 
…p PTE entries

commit 36b7840 upstream.

H_PAGE_THP_HUGE is used to differentiate between a THP hugepage and
hugetlb hugepage entries. The difference is WRT how we handle hash
fault on these address. THP address enables MPSS in segments. We want
to manage devmap hugepage entries similar to THP pt entries. Hence use
H_PAGE_THP_HUGE for devmap huge PTE entries.

With current code while handling hash PTE fault, we do set is_thp =
true when finding devmap PTE huge PTE entries.

Current code also does the below sequence we setting up huge devmap
entries.

	entry = pmd_mkhuge(pfn_t_pmd(pfn, prot));
	if (pfn_t_devmap(pfn))
		entry = pmd_mkdevmap(entry);

In that case we would find both H_PAGE_THP_HUGE and PAGE_DEVMAP set
for huge devmap PTE entries. This results in false positive error like
below.

  kernel BUG at /home/kvaneesh/src/linux/mm/memory.c:4321!
  Oops: Exception in kernel mode, sig: 5 [#1]
  LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
  Modules linked in:
  CPU: 56 PID: 67996 Comm: t_mmap_dio Not tainted 5.6.0-rc4-59640-g371c804dedbc thesofproject#128
  ....
  NIP [c00000000044c9e4] __follow_pte_pmd+0x264/0x900
  LR [c0000000005d45f8] dax_writeback_one+0x1a8/0x740
  Call Trace:
    str_spec.74809+0x22ffb4/0x2d116c (unreliable)
    dax_writeback_one+0x1a8/0x740
    dax_writeback_mapping_range+0x26c/0x700
    ext4_dax_writepages+0x150/0x5a0
    do_writepages+0x68/0x180
    __filemap_fdatawrite_range+0x138/0x180
    file_write_and_wait_range+0xa4/0x110
    ext4_sync_file+0x370/0x6e0
    vfs_fsync_range+0x70/0xf0
    sys_msync+0x220/0x2e0
    system_call+0x5c/0x68

This is because our pmd_trans_huge check doesn't exclude _PAGE_DEVMAP.

To make this all consistent, update pmd_mkdevmap to set
H_PAGE_THP_HUGE and pmd_trans_huge check now excludes _PAGE_DEVMAP
correctly.

Fixes: ebd3119 ("powerpc/mm: Add devmap support for ppc64")
Cc: [email protected] # v4.13+
Signed-off-by: Aneesh Kumar K.V <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
cujomalainey pushed a commit to cujomalainey/linux that referenced this pull request Sep 17, 2020
@bebarino
FROMGIT: drm/msm: Avoid div-by-zero in dpu_crtc_atomic_check()
969c48d 
The cstate->num_mixers member is only set to a non-zero value once
dpu_encoder_virt_mode_set() is called, but the atomic check function can
be called by userspace before that. Let's avoid the div-by-zero here and
inside _dpu_crtc_setup_lm_bounds() by skipping this part of the atomic
check if dpu_encoder_virt_mode_set() hasn't been called yet. This fixes
an UBSAN warning:

 UBSAN: Undefined behaviour in drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c:860:31
 division by zero
 CPU: 7 PID: 409 Comm: frecon Tainted: G S                5.4.31 thesofproject#128
 Hardware name: Google Trogdor (rev0) (DT)
 Call trace:
  dump_backtrace+0x0/0x14c
  show_stack+0x20/0x2c
  dump_stack+0xa0/0xd8
  __ubsan_handle_divrem_overflow+0xec/0x110
  dpu_crtc_atomic_check+0x97c/0x9d4
  drm_atomic_helper_check_planes+0x160/0x1c8
  drm_atomic_helper_check+0x54/0xbc
  drm_atomic_check_only+0x6a8/0x880
  drm_atomic_commit+0x20/0x5c
  drm_atomic_helper_set_config+0x98/0xa0
  drm_mode_setcrtc+0x308/0x5dc
  drm_ioctl_kernel+0x9c/0x114
  drm_ioctl+0x2ac/0x4b0
  drm_compat_ioctl+0xe8/0x13c
  __arm64_compat_sys_ioctl+0x184/0x324
  el0_svc_common+0xa4/0x154
  el0_svc_compat_handler+0x

Cc: Abhinav Kumar <[email protected]>
Cc: Jeykumar Sankaran <[email protected]>
Cc: Jordan Crouse <[email protected]>
Cc: Sean Paul <[email protected]>
Fixes: 25fdd59 ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Stephen Boyd <[email protected]>
Reviewed-by: Abhinav Kumar <[email protected]>
Tested-by: Sai Prakash Ranjan <[email protected]>
Signed-off-by: Rob Clark <[email protected]>
(cherry picked from commit 22f7609
 https://gitlab.freedesktop.org/drm/msm.git msm-next)

BUG=b:150574895, b:147659448
TEST=boot, verify flicker is gone in bt/wifi tray

Signed-off-by: Rob Clark <[email protected]>
Change-Id: I85af0f8078b1b0182062f6e3caddcd54748a26f5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2406420
Reviewed-by: Sean Paul <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
aiChaoSONG pushed a commit to aiChaoSONG/linux that referenced this pull request May 6, 2021
@alex
Merge pull request thesofproject#128 from Rust-for-Linux/alex-patch-1
891b952 
fixes thesofproject#127 -- added a comment to clarify an example
vijendarmukunda pushed a commit to vijendarmukunda/linux that referenced this pull request Feb 13, 2024
@chenhengqi @chenhuacai
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 <[email protected]>
Signed-off-by: Hengqi Chen <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>
bardliao pushed a commit to bardliao/linux that referenced this pull request Aug 22, 2024
fix bitmap corruption on close_range() with CLOSE_RANGE_UNSHARE
9a2fa14 
copy_fd_bitmaps(new, old, count) is expected to copy the first
count/BITS_PER_LONG bits from old->full_fds_bits[] and fill
the rest with zeroes.  What it does is copying enough words
(BITS_TO_LONGS(count/BITS_PER_LONG)), then memsets the rest.
That works fine, *if* all bits past the cutoff point are
clear.  Otherwise we are risking garbage from the last word
we'd copied.

For most of the callers that is true - expand_fdtable() has
count equal to old->max_fds, so there's no open descriptors
past count, let alone fully occupied words in ->open_fds[],
which is what bits in ->full_fds_bits[] correspond to.

The other caller (dup_fd()) passes sane_fdtable_size(old_fdt, max_fds),
which is the smallest multiple of BITS_PER_LONG that covers all
opened descriptors below max_fds.  In the common case (copying on
fork()) max_fds is ~0U, so all opened descriptors will be below
it and we are fine, by the same reasons why the call in expand_fdtable()
is safe.

Unfortunately, there is a case where max_fds is less than that
and where we might, indeed, end up with junk in ->full_fds_bits[] -
close_range(from, to, CLOSE_RANGE_UNSHARE) with
	* descriptor table being currently shared
	* 'to' being above the current capacity of descriptor table
	* 'from' being just under some chunk of opened descriptors.
In that case we end up with observably wrong behaviour - e.g. spawn
a child with CLONE_FILES, get all descriptors in range 0..127 open,
then close_range(64, ~0U, CLOSE_RANGE_UNSHARE) and watch dup(0) ending
up with descriptor thesofproject#128, despite thesofproject#64 being observably not open.

The minimally invasive fix would be to deal with that in dup_fd().
If this proves to add measurable overhead, we can go that way, but
let's try to fix copy_fd_bitmaps() first.

* new helper: bitmap_copy_and_expand(to, from, bits_to_copy, size).
* make copy_fd_bitmaps() take the bitmap size in words, rather than
bits; it's 'count' argument is always a multiple of BITS_PER_LONG,
so we are not losing any information, and that way we can use the
same helper for all three bitmaps - compiler will see that count
is a multiple of BITS_PER_LONG for the large ones, so it'll generate
plain memcpy()+memset().

Reproducer added to tools/testing/selftests/core/close_range_test.c

Cc: [email protected]
Signed-off-by: Al Viro <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@lgirdwood lgirdwood lgirdwood requested changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@zhuyingjiang @lgirdwood