]> Git Repo - linux.git/log
linux.git
4 years agoio_uring: move cred assignment into io_issue_sqe()
Jens Axboe [Sat, 27 Feb 2021 22:57:30 +0000 (15:57 -0700)]
io_uring: move cred assignment into io_issue_sqe()

If we move it in there, then we no longer have to care about it in io-wq.
This means we can drop the cred handling in io-wq, and we can drop the
REQ_F_WORK_INITIALIZED flag and async init functions as that was the last
user of it since we moved to the new workers. Then we can also drop
io_wq_work->creds, and just hold the personality u16 in there instead.

Suggested-by: Pavel Begunkov <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
4 years agoio_uring: kill unnecessary REQ_F_WORK_INITIALIZED checks
Jens Axboe [Sat, 27 Feb 2021 22:20:49 +0000 (15:20 -0700)]
io_uring: kill unnecessary REQ_F_WORK_INITIALIZED checks

We're no longer checking anything that requires the work item to be
initialized, as we're not carrying any file related state there.

Signed-off-by: Jens Axboe <[email protected]>
4 years agoio_uring: remove unused argument 'tsk' from io_req_caches_free()
Jens Axboe [Sat, 27 Feb 2021 22:04:18 +0000 (15:04 -0700)]
io_uring: remove unused argument 'tsk' from io_req_caches_free()

We prune the full cache regardless, get rid of the dead argument.

Signed-off-by: Jens Axboe <[email protected]>
4 years agoio_uring: destroy io-wq on exec
Pavel Begunkov [Sat, 27 Feb 2021 11:16:46 +0000 (11:16 +0000)]
io_uring: destroy io-wq on exec

Destroy current's io-wq backend and tctx on __io_uring_task_cancel(),
aka exec(). Looks it's not strictly necessary, because it will be done
at some point when the task dies and changes of creds/files/etc. are
handled, but better to do that earlier to free io-wq and not potentially
lock previous mm and other resources for the time being.

It's safe to do because we wait for all requests of the current task to
complete, so no request will use tctx afterwards. Note, that
io_uring_files_cancel() may leave some requests for later reaping, so it
leaves tctx intact, that's ok as the task is dying anyway.

Signed-off-by: Pavel Begunkov <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
4 years agoio_uring: warn on not destroyed io-wq
Pavel Begunkov [Sat, 27 Feb 2021 11:16:45 +0000 (11:16 +0000)]
io_uring: warn on not destroyed io-wq

Make sure that we killed an io-wq by the time a task is dead.

Signed-off-by: Pavel Begunkov <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
4 years agoio_uring: fix race condition in task_work add and clear
Jens Axboe [Fri, 26 Feb 2021 21:54:16 +0000 (14:54 -0700)]
io_uring: fix race condition in task_work add and clear

We clear the bit marking the ctx task_work as active after having run
the queued work, but we really should be clearing it before. Otherwise
we can hit a tiny race ala:

CPU0 CPU1
io_task_work_add() tctx_task_work()
run_work
add_to_list
test_and_set_bit
clear_bit
already set

and CPU0 will return thinking the task_work is queued, while in reality
it's already being run. If we hit the condition after __tctx_task_work()
found no more work, but before we've cleared the bit, then we'll end up
thinking it's queued and will be run. In reality it is queued, but we
didn't queue the ctx task_work to ensure that it gets run.

Fixes: 7cbf1722d5fc ("io_uring: provide FIFO ordering for task_work")
Signed-off-by: Jens Axboe <[email protected]>
4 years agoio-wq: provide an io_wq_put_and_exit() helper
Jens Axboe [Fri, 26 Feb 2021 20:48:19 +0000 (13:48 -0700)]
io-wq: provide an io_wq_put_and_exit() helper

If we put the io-wq from io_uring, we really want it to exit. Provide
a helper that does that for us. Couple that with not having the manager
hold a reference to the 'wq' and the normal SQPOLL exit will tear down
the io-wq context appropriate.

On the io-wq side, our wq context is per task, so only the task itself
is manipulating ->manager and hence it's safe to check and clear without
any extra locking. We just need to ensure that the manager task stays
around, in case it exits.

Signed-off-by: Jens Axboe <[email protected]>
4 years agoio_uring: don't use complete_all() on SQPOLL thread exit
Jens Axboe [Fri, 26 Feb 2021 20:46:49 +0000 (13:46 -0700)]
io_uring: don't use complete_all() on SQPOLL thread exit

We want to reuse this completion, and a single complete should do just
fine. Ensure that we park ourselves first if requested, as that is what
lead to the initial deadlock in this area. If we've got someone attempting
to park us, then we can't proceed without having them finish first.

Fixes: 37d1e2e3642e ("io_uring: move SQPOLL thread io-wq forked worker")
Signed-off-by: Jens Axboe <[email protected]>
4 years agoio_uring: run fallback on cancellation
Pavel Begunkov [Fri, 26 Feb 2021 15:47:56 +0000 (15:47 +0000)]
io_uring: run fallback on cancellation

io_uring_try_cancel_requests() matches not only current's requests, but
also of other exiting tasks, so we need to actively cancel them and not
just wait, especially since the function can be called on flush during
do_exit() -> exit_files().
Even if it's not a problem for now, it's much nicer to know that the
function tries to cancel everything it can.

Signed-off-by: Pavel Begunkov <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
4 years agoio_uring: SQPOLL stop error handling fixes
Jens Axboe [Fri, 26 Feb 2021 18:27:15 +0000 (11:27 -0700)]
io_uring: SQPOLL stop error handling fixes

If we fail to fork an SQPOLL worker, we can hit cancel, and hence
attempted thread stop, with the thread already being stopped. Ensure
we check for that.

Also guard thread stop fully by the sqd mutex, just like we do for
park.

Signed-off-by: Jens Axboe <[email protected]>
4 years agoio-wq: fix double put of 'wq' in error path
Jens Axboe [Fri, 26 Feb 2021 17:20:34 +0000 (10:20 -0700)]
io-wq: fix double put of 'wq' in error path

We are already freeing the wq struct in both spots, so don't put it and
get it freed twice.

Reported-by: [email protected]
Fixes: 4fb6ac326204 ("io-wq: improve manager/worker handling over exec")
Signed-off-by: Jens Axboe <[email protected]>
4 years agoio-wq: wait for manager exit on wq destroy
Jens Axboe [Fri, 26 Feb 2021 16:56:32 +0000 (09:56 -0700)]
io-wq: wait for manager exit on wq destroy

The manager waits for the workers, hence the manager is always valid if
workers are running. Now also have wq destroy wait for the manager on
exit, so we now everything is gone.

Signed-off-by: Jens Axboe <[email protected]>
4 years agoio-wq: rename wq->done completion to wq->started
Jens Axboe [Fri, 26 Feb 2021 16:53:17 +0000 (09:53 -0700)]
io-wq: rename wq->done completion to wq->started

This is a leftover from a different use cases, it's used to wait for
the manager to startup. Rename it as such.

Signed-off-by: Jens Axboe <[email protected]>
4 years agoio-wq: don't ask for a new worker if we're exiting
Jens Axboe [Fri, 26 Feb 2021 16:52:02 +0000 (09:52 -0700)]
io-wq: don't ask for a new worker if we're exiting

If we're in the process of shutting down the async context, then don't
create new workers if we already have at least the fixed one.

Signed-off-by: Jens Axboe <[email protected]>
4 years agoio-wq: have manager wait for all workers to exit
Jens Axboe [Fri, 26 Feb 2021 16:47:20 +0000 (09:47 -0700)]
io-wq: have manager wait for all workers to exit

Instead of having to wait separately on workers and manager, just have
the manager wait on the workers. We use an atomic_t for the reference
here, as we need to start at 0 and allow increment from that. Since the
number of workers is naturally capped by the allowed nr of processes,
and that uses an int, there is no risk of overflow.

Signed-off-by: Jens Axboe <[email protected]>
4 years agoiommu/vt-d: Fix status code for Allocate/Free PASID command
Zenghui Yu [Sat, 27 Feb 2021 07:39:09 +0000 (15:39 +0800)]
iommu/vt-d: Fix status code for Allocate/Free PASID command

As per Intel vt-d spec, Rev 3.0 (section 10.4.45 "Virtual Command Response
Register"), the status code of "No PASID available" error in response to
the Allocate PASID command is 2, not 1. The same for "Invalid PASID" error
in response to the Free PASID command.

We will otherwise see confusing kernel log under the command failure from
guest side. Fix it.

Fixes: 24f27d32ab6b ("iommu/vt-d: Enlightened PASID allocation")
Signed-off-by: Zenghui Yu <[email protected]>
Acked-by: Lu Baolu <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Joerg Roedel <[email protected]>
4 years agoiommu: Don't use lazy flush for untrusted device
Lu Baolu [Thu, 25 Feb 2021 06:14:54 +0000 (14:14 +0800)]
iommu: Don't use lazy flush for untrusted device

The lazy IOTLB flushing setup leaves a time window, in which the device
can still access some system memory, which has already been unmapped by
the device driver. It's not suitable for untrusted devices. A malicious
device might use this to attack the system by obtaining data that it
shouldn't obtain.

Fixes: c588072bba6b5 ("iommu/vt-d: Convert intel iommu driver to the iommu ops")
Signed-off-by: Lu Baolu <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Joerg Roedel <[email protected]>
4 years agoiommu/tegra-smmu: Fix mc errors on tegra124-nyan
Nicolin Chen [Thu, 18 Feb 2021 22:07:02 +0000 (14:07 -0800)]
iommu/tegra-smmu: Fix mc errors on tegra124-nyan

Commit 25938c73cd79 ("iommu/tegra-smmu: Rework tegra_smmu_probe_device()")
removed certain hack in the tegra_smmu_probe() by relying on IOMMU core to
of_xlate SMMU's SID per device, so as to get rid of tegra_smmu_find() and
tegra_smmu_configure() that are typically done in the IOMMU core also.

This approach works for both existing devices that have DT nodes and other
devices (like PCI device) that don't exist in DT, on Tegra210 and Tegra3
upon testing. However, Page Fault errors are reported on tegra124-Nyan:

  tegra-mc 70019000.memory-controller: display0a: read @0xfe056b40:
 EMEM address decode error (SMMU translation error [--S])
  tegra-mc 70019000.memory-controller: display0a: read @0xfe056b40:
 Page fault (SMMU translation error [--S])

After debugging, I found that the mentioned commit changed some function
callback sequence of tegra-smmu's, resulting in enabling SMMU for display
client before display driver gets initialized. I couldn't reproduce exact
same issue on Tegra210 as Tegra124 (arm-32) differs at arch-level code.

Actually this Page Fault is a known issue, as on most of Tegra platforms,
display gets enabled by the bootloader for the splash screen feature, so
it keeps filling the framebuffer memory. A proper fix to this issue is to
1:1 linear map the framebuffer memory to IOVA space so the SMMU will have
the same address as the physical address in its page table. Yet, Thierry
has been working on the solution above for a year, and it hasn't merged.

Therefore, let's partially revert the mentioned commit to fix the errors.

The reason why we do a partial revert here is that we can still set priv
in ->of_xlate() callback for PCI devices. Meanwhile, devices existing in
DT, like display, will go through tegra_smmu_configure() at the stage of
bus_set_iommu() when SMMU gets probed(), as what it did before we merged
the mentioned commit.

Once we have the linear map solution for framebuffer memory, this change
can be cleaned away.

[Big thank to Guillaume who reported and helped debugging/verification]

Fixes: 25938c73cd79 ("iommu/tegra-smmu: Rework tegra_smmu_probe_device()")
Reported-by: Guillaume Tucker <[email protected]>
Signed-off-by: Nicolin Chen <[email protected]>
Tested-by: Guillaume Tucker <[email protected]>
Acked-by: Thierry Reding <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Joerg Roedel <[email protected]>
4 years agoiommu/amd: Fix sleeping in atomic in increase_address_space()
Andrey Ryabinin [Wed, 17 Feb 2021 14:30:04 +0000 (17:30 +0300)]
iommu/amd: Fix sleeping in atomic in increase_address_space()

increase_address_space() calls get_zeroed_page(gfp) under spin_lock with
disabled interrupts. gfp flags passed to increase_address_space() may allow
sleeping, so it comes to this:

 BUG: sleeping function called from invalid context at mm/page_alloc.c:4342
 in_atomic(): 1, irqs_disabled(): 1, pid: 21555, name: epdcbbf1qnhbsd8

 Call Trace:
  dump_stack+0x66/0x8b
  ___might_sleep+0xec/0x110
  __alloc_pages_nodemask+0x104/0x300
  get_zeroed_page+0x15/0x40
  iommu_map_page+0xdd/0x3e0
  amd_iommu_map+0x50/0x70
  iommu_map+0x106/0x220
  vfio_iommu_type1_ioctl+0x76e/0x950 [vfio_iommu_type1]
  do_vfs_ioctl+0xa3/0x6f0
  ksys_ioctl+0x66/0x70
  __x64_sys_ioctl+0x16/0x20
  do_syscall_64+0x4e/0x100
  entry_SYSCALL_64_after_hwframe+0x44/0xa9

Fix this by moving get_zeroed_page() out of spin_lock/unlock section.

Fixes: 754265bcab ("iommu/amd: Fix race in increase_address_space()")
Signed-off-by: Andrey Ryabinin <[email protected]>
Acked-by: Will Deacon <[email protected]>
Cc: <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Joerg Roedel <[email protected]>
4 years agodrm/i915/edp: enable eDP MSO during link training
Jani Nikula [Tue, 2 Mar 2021 11:03:02 +0000 (13:03 +0200)]
drm/i915/edp: enable eDP MSO during link training

If the source and sink support MSO, enable it during link training.

v4: Divide DRRS pixel clock by link count before M/N calculation

v3: Adjust timings, refer to splitter

v2: Limit MSO to pipe A using ->pipe_mask

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2711
Cc: Nischal Varide <[email protected]>
Reviewed-by: Uma Shankar <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/66da48b4b3c5ccffaac7989097cd96d6c6af8243.1614682842.git.jani.nikula@intel.com
4 years agodrm/i915/edp: modify fixed and downclock modes for MSO
Jani Nikula [Tue, 2 Mar 2021 11:03:01 +0000 (13:03 +0200)]
drm/i915/edp: modify fixed and downclock modes for MSO

In the case of MSO (Multi-SST Operation), the EDID contains the timings
for a single panel segment. We'll want to hide the fact from userspace,
and expose modes that span the entire display.

Don't modify the EDID, as the userspace should not use that for
modesetting, only modify the actual modes.

v3: Use pixel overlap if available.

v2: Rename intel_dp_mso_mode_fixup -> intel_edp_mso_mode_fixup

Cc: Nischal Varide <[email protected]>
Reviewed-by: Uma Shankar <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/2862284eb033bb0ffc96134b7d5b11bf29e4587f.1614682842.git.jani.nikula@intel.com
4 years agodrm/i915/mso: add splitter state check
Jani Nikula [Tue, 2 Mar 2021 11:03:00 +0000 (13:03 +0200)]
drm/i915/mso: add splitter state check

For starters, we expect the state to be zero, as we don't enable MSO
anywhere.

v2: Refer to splitter.

Cc: Nischal Varide <[email protected]>
Reviewed-by: Uma Shankar <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/459a332f3cdce941c57312150872559db68f88c1.1614682842.git.jani.nikula@intel.com
4 years agodrm/i915/mso: add splitter state readout for platforms that support it
Jani Nikula [Tue, 2 Mar 2021 11:02:59 +0000 (13:02 +0200)]
drm/i915/mso: add splitter state readout for platforms that support it

Add splitter configuration to crtc state, and read it where
supported. Also add splitter state dumping. The stream splitter will be
required for eDP MSO.

v4:
- Catch invalid splitter configuration (Uma)

v3:
- Convert segment timings to full panel timings.
- Refer to splitter instead of mso in crtc state.
- Dump splitter state.

v2: Add warning for mso being enabled on pipes other than A.

Cc: Nischal Varide <[email protected]>
Cc: Uma Shankar <[email protected]>
Reviewed-by: Uma Shankar <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/95cbe1c9d45edf3e3ec252e49fb49055def98155.1614682842.git.jani.nikula@intel.com
4 years agodrm/amdgpu: fix parameter error of RREG32_PCIE() in amdgpu_regs_pcie
Kevin Wang [Tue, 2 Mar 2021 07:54:00 +0000 (15:54 +0800)]
drm/amdgpu: fix parameter error of RREG32_PCIE() in amdgpu_regs_pcie

the register offset isn't needed division by 4 to pass RREG32_PCIE()

Signed-off-by: Kevin Wang <[email protected]>
Reviewed-by: Lijo Lazar <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Cc: [email protected]
4 years agodrm/amd/display: fix the return of the uninitialized value in ret
Colin Ian King [Tue, 2 Mar 2021 14:05:09 +0000 (14:05 +0000)]
drm/amd/display: fix the return of the uninitialized value in ret

Currently if stream->signal is neither SIGNAL_TYPE_DISPLAY_PORT_MST or
SIGNAL_TYPE_DISPLAY_PORT then variable ret is uninitialized and this is
checked for > 0 at the end of the function.  Ret should be initialized,
I believe setting it to zero is a correct default.

Addresses-Coverity: ("Uninitialized scalar variable")
Fixes: bd0c064c161c ("drm/amd/display: Add return code instead of boolean for future use")
Reviewed-by: Harry Wentland <[email protected]>
Signed-off-by: Colin Ian King <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
4 years agodrm/amdgpu: enable BACO runpm by default on sienna cichlid and navy flounder
Alex Deucher [Mon, 1 Mar 2021 15:42:50 +0000 (10:42 -0500)]
drm/amdgpu: enable BACO runpm by default on sienna cichlid and navy flounder

It works fine and was only disabled because primary GPUs
don't enter runpm if there is a console bound to the fbdev due
to the kmap.  This will at least allow runpm on secondary cards.

Reviewed-by: Evan Quan <[email protected]>
Reviewed-by: Rajneesh Bhardwaj <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
4 years agodrm/amd/pm: correct Arcturus mmTHM_BACO_CNTL register address
Evan Quan [Fri, 19 Feb 2021 08:18:47 +0000 (16:18 +0800)]
drm/amd/pm: correct Arcturus mmTHM_BACO_CNTL register address

Arcturus has a different register address from other SMU V11
ASICs.

Signed-off-by: Evan Quan <[email protected]>
Acked-by: Guchun Chen <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Cc: [email protected]
4 years agodrm/amdgpu/swsmu/vangogh: Only use RLCPowerNotify msg for disable
Alex Deucher [Wed, 24 Feb 2021 20:46:59 +0000 (15:46 -0500)]
drm/amdgpu/swsmu/vangogh: Only use RLCPowerNotify msg for disable

Per discussions with PMFW team, the driver only needs to
notify the PMFW when the RLC is disabled.  The RLC FW will notify
the PMFW directly when it's enabled.

Acked-by: Evan Quan <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
4 years agodrm/amdgpu/pm: make unsupported power profile messages debug
Alex Deucher [Wed, 24 Feb 2021 17:21:07 +0000 (12:21 -0500)]
drm/amdgpu/pm: make unsupported power profile messages debug

Making them an error confuses users and the errors are harmless
as not all asics support all profiles.

Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1488
Acked-by: Nirmoy Das <[email protected]>
Reviewed-by: Evan Quan <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
4 years agodrm/amdgpu:disable VCN for Navi12 SKU
Asher.Song [Wed, 24 Feb 2021 10:41:34 +0000 (18:41 +0800)]
drm/amdgpu:disable VCN for Navi12 SKU

Navi12 0x7360/C7 SKU has no video support, so remove it.

Reviewed-by: Guchun Chen <[email protected]>
Signed-off-by: Asher.Song <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Cc: [email protected]
4 years agodrm/amdgpu: Only check for S0ix if AMD_PMC is configured
Alex Deucher [Thu, 25 Feb 2021 15:21:49 +0000 (10:21 -0500)]
drm/amdgpu: Only check for S0ix if AMD_PMC is configured

The S0ix check only makes sense if the AMD PMC driver is
present.  We need to use the legacy S3 pathes when the
PMC driver is not present.

Reviewed-by: Prike Liang <[email protected]>
Reviewed-by: Rajneesh Bhardwaj <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Cc: [email protected]
4 years agoACPI: bus: Constify is_acpi_node() and friends (part 2)
Andy Shevchenko [Tue, 2 Mar 2021 13:35:48 +0000 (15:35 +0200)]
ACPI: bus: Constify is_acpi_node() and friends (part 2)

Commit 8b9d6802583a ("ACPI: Constify acpi_bus helper functions,
switch to macros") only changed functions for CONFIG_ACPI=y case.
This part adjusts the rest.

Fixes: 8b9d6802583a ("ACPI: Constify acpi_bus helper functions, switch to macros")
Signed-off-by: Andy Shevchenko <[email protected]>
Reviewed-by: Sakari Ailus <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
4 years agoRDMA/uverbs: Fix kernel-doc warning of _uverbs_alloc
Leon Romanovsky [Tue, 2 Mar 2021 07:42:14 +0000 (09:42 +0200)]
RDMA/uverbs: Fix kernel-doc warning of _uverbs_alloc

Fix the following W=1 compilation warning:

drivers/infiniband/core/uverbs_ioctl.c:108: warning: expecting prototype for uverbs_alloc(). Prototype was for _uverbs_alloc() instead

Fixes: 461bb2eee4e1 ("IB/uverbs: Add a simple allocator to uverbs_attr_bundle")
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Leon Romanovsky <[email protected]>
Signed-off-by: Jason Gunthorpe <[email protected]>
4 years agoRDMA/mlx5: Set correct kernel-doc identifier
Leon Romanovsky [Tue, 2 Mar 2021 07:42:13 +0000 (09:42 +0200)]
RDMA/mlx5: Set correct kernel-doc identifier

The W=1 allmodconfig build produces the following warning:

drivers/infiniband/hw/mlx5/odp.c:1086: warning: wrong kernel-doc identifier on line:
  * Parse a series of data segments for page fault handling.

Fix it by changing /** to be /* as it is written in kernel-doc
documentation.

Fixes: 5e769e444d26 ("RDMA/hw/mlx5/odp: Fix formatting and add missing descriptions in 'pagefault_data_segments()'")
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Leon Romanovsky <[email protected]>
Signed-off-by: Jason Gunthorpe <[email protected]>
4 years agotpm: Remove unintentional dump_stack() call
Jarkko Sakkinen [Mon, 1 Mar 2021 21:24:16 +0000 (23:24 +0200)]
tpm: Remove unintentional dump_stack() call

Somewhere along the line, probably during a rebase, an unintentional
dump_stack() got included. Revert this change.

Reported-by: Rikard Falkeborn <[email protected]>
Fixes: 90cba8d20f8b ("tpm/ppi: Constify static struct attribute_group")
Signed-off-by: Jarkko Sakkinen <[email protected]>
4 years agoALSA: hda/realtek: Apply dual codec quirks for MSI Godlike X570 board
Takashi Iwai [Wed, 3 Mar 2021 14:23:46 +0000 (15:23 +0100)]
ALSA: hda/realtek: Apply dual codec quirks for MSI Godlike X570 board

There is another MSI board (1462:cc34) that has dual Realtek codecs,
and we need to apply the existing quirk for fixing the conflicts of
Master control.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=211743
Cc: <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
4 years agorsxx: Return -EFAULT if copy_to_user() fails
Dan Carpenter [Wed, 3 Mar 2021 10:59:12 +0000 (13:59 +0300)]
rsxx: Return -EFAULT if copy_to_user() fails

The copy_to_user() function returns the number of bytes remaining but
we want to return -EFAULT to the user if it can't complete the copy.
The "st" variable only holds zero on success or negative error codes on
failure so the type should be int.

Fixes: 36f988e978f8 ("rsxx: Adding in debugfs entries.")
Signed-off-by: Dan Carpenter <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
4 years agodrm/i915: Clean up verify_wm_state()
Ville Syrjälä [Fri, 26 Feb 2021 15:32:04 +0000 (17:32 +0200)]
drm/i915: Clean up verify_wm_state()

Get rid of the nonsense cursor special case in verify_wm_state()
by just iterating through all the planes. And let's use the
canonical [PLANE:..] style in the debug prints while at it.

Cc: Stanislav Lisovskiy <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Stanislav Lisovskiy <[email protected]>
4 years agodrm/i915: Check tgl+ SAGV watermarks properly
Ville Syrjälä [Fri, 26 Feb 2021 15:32:03 +0000 (17:32 +0200)]
drm/i915: Check tgl+ SAGV watermarks properly

We know which WM0 (normal vs. SAGV) we supposedly programmed
into the hardware, so just check against that instead of accepting
either watermark as valid.

Cc: Stanislav Lisovskiy <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Stanislav Lisovskiy <[email protected]>
4 years agodrm/i915: Introduce SAGV transtion watermark
Ville Syrjälä [Fri, 26 Feb 2021 15:32:02 +0000 (17:32 +0200)]
drm/i915: Introduce SAGV transtion watermark

Seems to me that if we calculate WM0 using the bumped up SAGV latency
we need to calculate the transition watermark accordingly. Track it
alongside the other watermarks.

Cc: Stanislav Lisovskiy <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Stanislav Lisovskiy <[email protected]>
4 years agodrm/i915: Stuff SAGV watermark into a sub-structure
Ville Syrjälä [Fri, 26 Feb 2021 15:32:01 +0000 (17:32 +0200)]
drm/i915: Stuff SAGV watermark into a sub-structure

We'll want a SAGV transition watermark as well. Prepare
for that by collecting SAGV wm0 into a sub-strcture.

Cc: Stanislav Lisovskiy <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Stanislav Lisovskiy <[email protected]>
4 years agodrm/i915: Print wm changes if sagv_wm0 changes
Ville Syrjälä [Fri, 26 Feb 2021 15:32:00 +0000 (17:32 +0200)]
drm/i915: Print wm changes if sagv_wm0 changes

Let's consider sagv_wm0 as well when deciding whether to dump
out the watermark changes.

Cc: Stanislav Lisovskiy <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Stanislav Lisovskiy <[email protected]>
4 years agodrm/i915: Zero out SAGV wm when we don't have enough DDB for it
Ville Syrjälä [Fri, 26 Feb 2021 15:31:59 +0000 (17:31 +0200)]
drm/i915: Zero out SAGV wm when we don't have enough DDB for it

Let's handle the SAGV WM0 more like the other wm levels and just
totally zero it out when we don't have the DDB space to back it
up.

Cc: Stanislav Lisovskiy <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Stanislav Lisovskiy <[email protected]>
4 years agodrm/i915: Fix TGL+ plane SAGV watermark programming
Ville Syrjälä [Fri, 26 Feb 2021 15:31:58 +0000 (17:31 +0200)]
drm/i915: Fix TGL+ plane SAGV watermark programming

When we switch between SAGV on vs. off we need to reprogram all
plane wateramrks accordingly. Currently skl_wm_add_affected_planes()
totally ignores the SAGV watermark and just assumes we will use
the normal WM0.

Fix this by utilizing skl_plane_wm_level() which picks the
correct watermark based on use_sagv_wm. Thus we will force
an update on all the planes whose watermark registers need
to be reprogrammed.

Cc: Stanislav Lisovskiy <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Stanislav Lisovskiy <[email protected]>
4 years agodrm/i915: Readout conn_state->max_bpc
Ville Syrjälä [Tue, 16 Feb 2021 16:00:35 +0000 (18:00 +0200)]
drm/i915: Readout conn_state->max_bpc

Populate conn_state->max_bpc with something sensible from the start.
Otherwise it's possible that we get to compute_sink_pipe_bpp() with
max_bpc==0.

The specific scenario goes as follows:
1. Initial connector state allocated with max_bpc==0
2. Trigger a modeset on the crtc feeding the connector, without
   actually adding the connector to the commit
3. drm_atomic_connector_check() is skipped because the
   connector has not yet been added, hence conn_state->max_bpc
   retains its current value
4. drm_atomic_helper_check_modeset() ->
   drm_atomic_add_affected_connectors() -> the connector
   is now part of the commit
5. compute_baseline_pipe_bpp() -> MISSING_CASE(max_bpc==0)

Note that pipe_bpp itself may not be populated on pre-g4x machines,
in which case we just fall back to max_bpc==8 and let .compute_config()
limit the resulting pipe_bpp further if necessary.

Cc: Daniel Vetter <[email protected]>
Reported-by: Chris Wilson <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Tested-by: Chris Wilson <[email protected]>
Reviewed-by: José Roberto de Souza <[email protected]>
4 years agoALSA: hda/realtek: Add quirk for Intel NUC 10
Werner Sembach [Tue, 2 Mar 2021 18:04:14 +0000 (19:04 +0100)]
ALSA: hda/realtek: Add quirk for Intel NUC 10

This adds a new SND_PCI_QUIRK(...) and applies it to the Intel NUC 10
devices. This fixes the issue of the devices not having audio input and
output on the headset jack because the kernel does not recognize when
something is plugged in.

The new quirk was inspired by the quirk for the Intel NUC 8 devices, but
it turned out that the NUC 10 uses another pin. This information was
acquired by black box testing likely pins.

Co-developed-by: Eckhart Mohr <[email protected]>
Signed-off-by: Eckhart Mohr <[email protected]>
Signed-off-by: Werner Sembach <[email protected]>
Cc: <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
4 years agoxen: fix p2m size in dom0 for disabled memory hotplug case
Juergen Gross [Wed, 24 Feb 2021 15:03:08 +0000 (16:03 +0100)]
xen: fix p2m size in dom0 for disabled memory hotplug case

Since commit 9e2369c06c8a18 ("xen: add helpers to allocate unpopulated
memory") foreign mappings are using guest physical addresses allocated
via ZONE_DEVICE functionality.

This will result in problems for the case of no balloon memory hotplug
being configured, as the p2m list will only cover the initial memory
size of the domain. Any ZONE_DEVICE allocated address will be outside
the p2m range and thus a mapping can't be established with that memory
address.

Fix that by extending the p2m size for that case. At the same time add
a check for a to be created mapping to be within the p2m limits in
order to detect errors early.

While changing a comment, remove some 32-bit leftovers.

This is XSA-369.

Fixes: 9e2369c06c8a18 ("xen: add helpers to allocate unpopulated memory")
Cc: <[email protected]> # 5.9
Reported-by: Marek Marczykowski-Górecki <[email protected]>
Signed-off-by: Juergen Gross <[email protected]>
Reviewed-by: Jan Beulich <[email protected]>
Signed-off-by: Juergen Gross <[email protected]>
4 years agoxen-netback: respect gnttab_map_refs()'s return value
Jan Beulich [Thu, 25 Feb 2021 15:35:15 +0000 (16:35 +0100)]
xen-netback: respect gnttab_map_refs()'s return value

Commit 3194a1746e8a ("xen-netback: don't "handle" error by BUG()")
dropped respective a BUG_ON() without noticing that with this the
variable's value wouldn't be consumed anymore. With gnttab_set_map_op()
setting all status fields to a non-zero value, in case of an error no
slot should have a status of GNTST_okay (zero).

This is part of XSA-367.

Cc: <[email protected]>
Reported-by: kernel test robot <[email protected]>
Signed-off-by: Jan Beulich <[email protected]>
Reviewed-by: Juergen Gross <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Juergen Gross <[email protected]>
4 years agoXen/gnttab: handle p2m update errors on a per-slot basis
Jan Beulich [Thu, 25 Feb 2021 15:34:43 +0000 (16:34 +0100)]
Xen/gnttab: handle p2m update errors on a per-slot basis

Bailing immediately from set_foreign_p2m_mapping() upon a p2m updating
error leaves the full batch in an ambiguous state as far as the caller
is concerned. Instead flags respective slots as bad, unmapping what
was mapped there right away.

HYPERVISOR_grant_table_op()'s return value and the individual unmap
slots' status fields get used only for a one-time - there's not much we
can do in case of a failure.

Note that there's no GNTST_enomem or alike, so GNTST_general_error gets
used.

The map ops' handle fields get overwritten just to be on the safe side.

This is part of XSA-367.

Cc: <[email protected]>
Signed-off-by: Jan Beulich <[email protected]>
Reviewed-by: Juergen Gross <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Juergen Gross <[email protected]>
4 years agoMerge tag 'misc-5.12-2021-03-02' of git://git.kernel.dk/linux-block
Linus Torvalds [Wed, 3 Mar 2021 02:18:17 +0000 (18:18 -0800)]
Merge tag 'misc-5.12-2021-03-02' of git://git.kernel.dk/linux-block

Pull misc fixes from Jens Axboe:
 "Two misc fixes that don't belong in other branches:

   - Fix a regression with ia64 signals, introduced by the
     TIF_NOTIFY_SIGNAL change in 5.11.

   - Fix the current swapfile regression from this merge window"

* tag 'misc-5.12-2021-03-02' of git://git.kernel.dk/linux-block:
  swap: fix swapfile read/write offset
  ia64: don't call handle_signal() unless there's actually a signal queued

4 years agoswap: fix swapfile read/write offset
Jens Axboe [Tue, 2 Mar 2021 21:53:21 +0000 (14:53 -0700)]
swap: fix swapfile read/write offset

We're not factoring in the start of the file for where to write and
read the swapfile, which leads to very unfortunate side effects of
writing where we should not be...

Fixes: 48d15436fde6 ("mm: remove get_swap_bio")
Signed-off-by: Jens Axboe <[email protected]>
4 years agoia64: don't call handle_signal() unless there's actually a signal queued
Jens Axboe [Wed, 3 Mar 2021 00:22:11 +0000 (17:22 -0700)]
ia64: don't call handle_signal() unless there's actually a signal queued

Sergei and John both reported that ia64 failed to boot in 5.11, and it
was related to signals. Turns out the ia64 signal handling is a bit odd,
it doesn't check the return value of get_signal() for whether there's a
signal to deliver or not. With the introduction of TIF_NOTIFY_SIGNAL,
then task_work could trigger it.

Fix it by only calling handle_signal() if we actually have a real signal
to deliver. This brings it in line with all other archs, too.

Fixes: b269c229b0e8 ("ia64: add support for TIF_NOTIFY_SIGNAL")
Reported-by: Sergei Trofimovich <[email protected]>
Reported-by: John Paul Adrian Glaubitz <[email protected]>
Tested-by: Sergei Trofimovich <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
4 years agoftrace: Have recordmcount use w8 to read relp->r_info in arm64_is_fake_mcount
Chen Jun [Mon, 22 Feb 2021 13:58:40 +0000 (13:58 +0000)]
ftrace: Have recordmcount use w8 to read relp->r_info in arm64_is_fake_mcount

On little endian system, Use aarch64_be(gcc v7.3) downloaded from
linaro.org to build image with CONFIG_CPU_BIG_ENDIAN = y,
CONFIG_FTRACE = y, CONFIG_DYNAMIC_FTRACE = y.

gcc will create symbols of _mcount but recordmcount can not create
mcount_loc for *.o.
aarch64_be-linux-gnu-objdump -r fs/namei.o | grep mcount
00000000000000d0 R_AARCH64_CALL26  _mcount
...
0000000000007190 R_AARCH64_CALL26  _mcount

The reason is than funciton arm64_is_fake_mcount can not work correctly.
A symbol of _mcount in *.o compiled with big endian compiler likes:
00 00 00 2d 00 00 01 1b
w(rp->r_info) will return 0x2d instead of 0x011b. Because w() takes
uint32_t as parameter, which truncates rp->r_info.

Use w8() instead w() to read relp->r_info

Link: https://lkml.kernel.org/r/[email protected]
Fixes: ea0eada45632 ("recordmcount: only record relocation of type R_AARCH64_CALL26 on arm64.")
Acked-by: Will Deacon <[email protected]>
Signed-off-by: Chen Jun <[email protected]>
Signed-off-by: Steven Rostedt (VMware) <[email protected]>
4 years agodrm/i915/icp+: Use icp_hpd_irq_setup() instead of spt_hpd_irq_setup()
Lyude Paul [Wed, 17 Feb 2021 02:53:37 +0000 (21:53 -0500)]
drm/i915/icp+: Use icp_hpd_irq_setup() instead of spt_hpd_irq_setup()

While reviewing patches for handling workarounds related to gen9 bc, Imre
from Intel discovered that we're using spt_hpd_irq_setup() on ICP+ PCHs
despite it being almost the same as icp_hpd_irq_setup(). Since we need to
be calling icp_hpd_irq_setup() to ensure that CML-S/TGP platforms function
correctly anyway, let's move platforms using PCH_ICP which aren't handled
by gen11_hpd_irq_setup() over to icp_hpd_irq_setup().

Cc: Tejas Upadhyay <[email protected]>
Signed-off-by: Lyude Paul <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
4 years agodrm/i915/gen9bc: Handle TGP PCH during suspend/resume
Tejas Upadhyay [Wed, 17 Feb 2021 18:00:16 +0000 (13:00 -0500)]
drm/i915/gen9bc: Handle TGP PCH during suspend/resume

For Legacy S3 suspend/resume GEN9 BC needs to enable and
setup TGP PCH.

v2:
* Move Wa_14010685332 into it's own function - vsyrjala
* Add TODO comment about figuring out if we can move this workaround - imre
v3:
* Rename cnp_irq_post_reset() to cnp_display_clock_wa()
* Add TODO item mentioning we need to clarify which platforms this
  workaround applies to
* Just use ibx_irq_reset() in gen8_irq_reset(). This code should be
  functionally equivalent on gen9 bc to the code v2 added
* Drop icp_hpd_irq_setup() call in spt_hpd_irq_setup(), this looks to be
  more or less identical to spt_hpd_irq_setup() minus additionally enabling
  one port. Will update i915 to use icp_hpd_irq_setup() for ICP in a
  separate patch.
v4:
* Revert Wa_14010685332 system list in comments to how it was before
* Add back HAS_PCH_SPLIT() check before calling ibx_irq_reset()

Cc: Matt Roper <[email protected]>
Signed-off-by: Tejas Upadhyay <[email protected]>
Signed-off-by: Lyude Paul <[email protected]>
Reviewed-by: Imre Deak <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
4 years agopstore/ram: Rate-limit "uncorrectable error in header" message
Dmitry Osipenko [Tue, 2 Mar 2021 09:58:50 +0000 (12:58 +0300)]
pstore/ram: Rate-limit "uncorrectable error in header" message

There is a quite huge "uncorrectable error in header" flood in KMSG
on a clean system boot since there is no pstore buffer saved in RAM.
Let's silence the redundant noisy messages by rate-limiting the printk
message. Now there are maximum 10 messages printed repeatedly instead
of 35+.

Signed-off-by: Dmitry Osipenko <[email protected]>
Signed-off-by: Kees Cook <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
4 years agoKVM: SVM: Clear the CR4 register on reset
Babu Moger [Tue, 2 Mar 2021 18:51:31 +0000 (12:51 -0600)]
KVM: SVM: Clear the CR4 register on reset

This problem was reported on a SVM guest while executing kexec.
Kexec fails to load the new kernel when the PCID feature is enabled.

When kexec starts loading the new kernel, it starts the process by
resetting the vCPU's and then bringing each vCPU online one by one.
The vCPU reset is supposed to reset all the register states before the
vCPUs are brought online. However, the CR4 register is not reset during
this process. If this register is already setup during the last boot,
all the flags can remain intact. The X86_CR4_PCIDE bit can only be
enabled in long mode. So, it must be enabled much later in SMP
initialization.  Having the X86_CR4_PCIDE bit set during SMP boot can
cause a boot failures.

Fix the issue by resetting the CR4 register in init_vmcb().

Signed-off-by: Babu Moger <[email protected]>
Message-Id: <161471109108.30811.6392805173629704166.stgit@bmoger-ubuntu>
Signed-off-by: Paolo Bonzini <[email protected]>
4 years agoKVM: x86/xen: Add support for vCPU runstate information
David Woodhouse [Mon, 1 Mar 2021 12:53:09 +0000 (12:53 +0000)]
KVM: x86/xen: Add support for vCPU runstate information

This is how Xen guests do steal time accounting. The hypervisor records
the amount of time spent in each of running/runnable/blocked/offline
states.

In the Xen accounting, a vCPU is still in state RUNSTATE_running while
in Xen for a hypercall or I/O trap, etc. Only if Xen explicitly schedules
does the state become RUNSTATE_blocked. In KVM this means that even when
the vCPU exits the kvm_run loop, the state remains RUNSTATE_running.

The VMM can explicitly set the vCPU to RUNSTATE_blocked by using the
KVM_XEN_VCPU_ATTR_TYPE_RUNSTATE_CURRENT attribute, and can also use
KVM_XEN_VCPU_ATTR_TYPE_RUNSTATE_ADJUST to retrospectively add a given
amount of time to the blocked state and subtract it from the running
state.

The state_entry_time corresponds to get_kvmclock_ns() at the time the
vCPU entered the current state, and the total times of all four states
should always add up to state_entry_time.

Co-developed-by: Joao Martins <[email protected]>
Signed-off-by: Joao Martins <[email protected]>
Signed-off-by: David Woodhouse <[email protected]>
Message-Id: <20210301125309[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
4 years agoKVM: x86/xen: Fix return code when clearing vcpu_info and vcpu_time_info
David Woodhouse [Mon, 1 Mar 2021 12:53:08 +0000 (12:53 +0000)]
KVM: x86/xen: Fix return code when clearing vcpu_info and vcpu_time_info

When clearing the per-vCPU shared regions, set the return value to zero
to indicate success. This was causing spurious errors to be returned to
userspace on soft reset.

Also add a paranoid BUILD_BUG_ON() for compat structure compatibility.

Fixes: 0c165b3c01fe ("KVM: x86/xen: Allow reset of Xen attributes")
Signed-off-by: David Woodhouse <[email protected]>
Message-Id: <20210301125309[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
4 years agoselftests: kvm: Mmap the entire vcpu mmap area
Aaron Lewis [Wed, 10 Feb 2021 16:50:36 +0000 (08:50 -0800)]
selftests: kvm: Mmap the entire vcpu mmap area

The vcpu mmap area may consist of more than just the kvm_run struct.
Allocate enough space for the entire vcpu mmap area. Without this, on
x86, the PIO page, for example, will be missing.  This is problematic
when dealing with an unhandled exception from the guest as the exception
vector will be incorrectly reported as 0x0.

Message-Id: <20210210165035.3712489[email protected]>
Reviewed-by: Andrew Jones <[email protected]>
Co-developed-by: Steve Rutherford <[email protected]>
Signed-off-by: Aaron Lewis <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
4 years agoKVM: Documentation: Fix index for KVM_CAP_PPC_DAWR1
Kai Huang [Fri, 26 Feb 2021 09:48:32 +0000 (22:48 +1300)]
KVM: Documentation: Fix index for KVM_CAP_PPC_DAWR1

It should be 7.23 instead of 7.22, which has already been taken by
KVM_CAP_X86_BUS_LOCK_EXIT.

Signed-off-by: Kai Huang <[email protected]>
Message-Id: <20210226094832[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
4 years agoKVM: x86: allow compiling out the Xen hypercall interface
Paolo Bonzini [Fri, 26 Feb 2021 09:54:45 +0000 (04:54 -0500)]
KVM: x86: allow compiling out the Xen hypercall interface

The Xen hypercall interface adds to the attack surface of the hypervisor
and will be used quite rarely.  Allow compiling it out.

Suggested-by: Christoph Hellwig <[email protected]>
Reviewed-by: David Woodhouse <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
4 years agoblock/bfq: update comments and default value in docs for fifo_expire
Joseph Qi [Tue, 23 Feb 2021 01:55:28 +0000 (09:55 +0800)]
block/bfq: update comments and default value in docs for fifo_expire

Correct the comments since bfq_fifo_expire[0] is for async request,
while bfq_fifo_expire[1] is for sync request.
Also update docs, according the source code, the default
fifo_expire_async is 250ms, and fifo_expire_sync is 125ms.

Signed-off-by: Joseph Qi <[email protected]>
Acked-by: Paolo Valente <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
4 years agorsxx: remove unused including <linux/version.h>
Tian Tao [Tue, 2 Mar 2021 01:53:39 +0000 (09:53 +0800)]
rsxx: remove unused including <linux/version.h>

Remove including <linux/version.h> that don't need it.

Signed-off-by: Tian Tao <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
4 years agoALSA: hda/hdmi: let new platforms assign the pcm slot dynamically
Hui Wang [Mon, 1 Mar 2021 11:12:02 +0000 (19:12 +0800)]
ALSA: hda/hdmi: let new platforms assign the pcm slot dynamically

If the platform set the dyn_pcm_assign to true, it will call
hdmi_find_pcm_slot() to find a pcm slot when hdmi/dp monitor is
connected and need to create a pcm.

So far only intel_hsw_common_init() and patch_nvhdmi() set the
dyn_pcm_assign to true, here we let tgl platforms assign the pcm slot
dynamically first, if the driver runs for a period of time and there
is no regression reported, we could set no_fixed_assgin to true in
the intel_hsw_common_init(), and then set it to true in the
patch_nvhdmi().

This change comes from the discussion between Takashi and
Kai Vehmanen. Please refer to:
https://github.com/alsa-project/alsa-lib/pull/118

Suggested-and-reviewed-by: Takashi Iwai <[email protected]>
Suggested-and-reviewed-by: Kai Vehmanen <[email protected]>
Signed-off-by: Hui Wang <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
4 years agoALSA: hda/realtek: Add quirk for Clevo NH55RZQ
Eckhart Mohr [Tue, 2 Mar 2021 16:25:22 +0000 (17:25 +0100)]
ALSA: hda/realtek: Add quirk for Clevo NH55RZQ

This applies a SND_PCI_QUIRK(...) to the Clevo NH55RZQ barebone. This
fixes the issue of the device not recognizing a pluged in microphone.

The device has both, a microphone only jack, and a speaker + microphone
combo jack. The combo jack already works. The microphone-only jack does
not recognize when a device is pluged in without this patch.

Signed-off-by: Eckhart Mohr <[email protected]>
Co-developed-by: Werner Sembach <[email protected]>
Signed-off-by: Werner Sembach <[email protected]>
Cc: <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
4 years agoMerge tag 'tags/sound-sdw-kconfig-fixes' into for-linus
Takashi Iwai [Tue, 2 Mar 2021 17:30:07 +0000 (18:30 +0100)]
Merge tag 'tags/sound-sdw-kconfig-fixes' into for-linus

ALSA/ASoC/SOF/SoundWire: fix Kconfig issues

In January, Intel kbuild bot and Arnd Bergmann reported multiple
issues with randconfig. This patchset builds on Arnd's suggestions to

a) expose ACPI and PCI devices in separate modules, while sof-acpi-dev
and sof-pci-dev become helpers. This will result in minor changes
required for developers/testers, i.e. modprobe snd-sof-pci will no
longer result in a probe. The SOF CI was already updated to deal with
this module dependency change and introduction of new modules.

b) Fix SOF/SoundWire/DSP_config dependencies by moving the code
required to detect SoundWire presence in ACPI tables to sound/hda.

Link: https://lore.kernel.org/r/[email protected]
4 years agobtrfs: subpage: fix the false data csum mismatch error
Qu Wenruo [Mon, 1 Mar 2021 08:44:22 +0000 (16:44 +0800)]
btrfs: subpage: fix the false data csum mismatch error

[BUG]
When running fstresss, we can hit strange data csum mismatch where the
on-disk data is in fact correct (passes scrub).

With some extra debug info added, we have the following traces:

  0482us: btrfs_do_readpage: root=5 ino=284 offset=393216, submit force=0 pgoff=0 iosize=8192
  0494us: btrfs_do_readpage: root=5 ino=284 offset=401408, submit force=0 pgoff=8192 iosize=4096
  0498us: btrfs_submit_data_bio: root=5 ino=284 bio first bvec=393216 len=8192
  0591us: btrfs_do_readpage: root=5 ino=284 offset=405504, submit force=0 pgoff=12288 iosize=36864
  0594us: btrfs_submit_data_bio: root=5 ino=284 bio first bvec=401408 len=4096
  0863us: btrfs_submit_data_bio: root=5 ino=284 bio first bvec=405504 len=36864
  0933us: btrfs_verify_data_csum: root=5 ino=284 offset=393216 len=8192
  0967us: btrfs_do_readpage: root=5 ino=284 offset=442368, skip beyond isize pgoff=49152 iosize=16384
  1047us: btrfs_verify_data_csum: root=5 ino=284 offset=401408 len=4096
  1163us: btrfs_verify_data_csum: root=5 ino=284 offset=405504 len=36864
  1290us: check_data_csum: !!! root=5 ino=284 offset=438272 pg_off=45056 !!!
  7387us: end_bio_extent_readpage: root=5 ino=284 before pending_read_bios=0

[CAUSE]
Normally we expect all submitted bio reads to only touch the range we
specified, and under subpage context, it means we should only touch the
range specified in each bvec.

But in data read path, inside end_bio_extent_readpage(), we have page
zeroing which only takes regular page size into consideration.

This means for subpage if we have an inode whose content looks like below:

  0       16K     32K     48K     64K
  |///////|       |///////|       |

  |//| = data needs to be read from disk
  |  | = hole

And i_size is 64K initially.

Then the following race can happen:

T1 | T2
--------------------------------+--------------------------------
btrfs_do_readpage() |
|- isize = 64K; |
|  At this time, the isize is  |
|  64K |
| |
|- submit_extent_page() |
|  submit previous assembled bio|
|  assemble bio for [0, 16K) |
| |
|- submit_extent_page() |
   submit read bio for [0, 16K) |
   assemble read bio for |
   [32K, 48K) |
  |
| btrfs_setsize()
| |- i_size_write(, 16K);
|    Now i_size is only 16K
end_io() for [0K, 16K) |
|- end_bio_extent_readpage() |
   |- btrfs_verify_data_csum()  |
   |  No csum error |
   |- i_size = 16K; |
   |- zero_user_segment(16K, |
      PAGE_SIZE); |
      !!! We zeroed range |
      !!! [32K, 48K) |
| end_io for [32K, 48K)
| |- end_bio_extent_readpage()
|    |- btrfs_verify_data_csum()
|       ! CSUM MISMATCH !
|       ! As the range is zeroed now !

[FIX]
To fix the problem, make end_bio_extent_readpage() to only zero the
range of bvec.

The bug only affects subpage read-write support, as for full read-only
mount we can't change i_size thus won't hit the race condition.

Signed-off-by: Qu Wenruo <[email protected]>
Reviewed-by: David Sterba <[email protected]>
Signed-off-by: David Sterba <[email protected]>
4 years agobtrfs: fix warning when creating a directory with smack enabled
Filipe Manana [Fri, 26 Feb 2021 17:51:44 +0000 (17:51 +0000)]
btrfs: fix warning when creating a directory with smack enabled

When we have smack enabled, during the creation of a directory smack may
attempt to add a "smack transmute" xattr on the inode, which results in
the following warning and trace:

  WARNING: CPU: 3 PID: 2548 at fs/btrfs/transaction.c:537 start_transaction+0x489/0x4f0
  Modules linked in: nft_objref nf_conntrack_netbios_ns (...)
  CPU: 3 PID: 2548 Comm: mkdir Not tainted 5.9.0-rc2smack+ #81
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014
  RIP: 0010:start_transaction+0x489/0x4f0
  Code: e9 be fc ff ff (...)
  RSP: 0018:ffffc90001887d10 EFLAGS: 00010202
  RAX: ffff88816f1e0000 RBX: 0000000000000201 RCX: 0000000000000003
  RDX: 0000000000000201 RSI: 0000000000000002 RDI: ffff888177849000
  RBP: ffff888177849000 R08: 0000000000000001 R09: 0000000000000004
  R10: ffffffff825e8f7a R11: 0000000000000003 R12: ffffffffffffffe2
  R13: 0000000000000000 R14: ffff88803d884270 R15: ffff8881680d8000
  FS:  00007f67317b8440(0000) GS:ffff88817bcc0000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007f67247a22a8 CR3: 000000004bfbc002 CR4: 0000000000370ee0
  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
  Call Trace:
   ? slab_free_freelist_hook+0xea/0x1b0
   ? trace_hardirqs_on+0x1c/0xe0
   btrfs_setxattr_trans+0x3c/0xf0
   __vfs_setxattr+0x63/0x80
   smack_d_instantiate+0x2d3/0x360
   security_d_instantiate+0x29/0x40
   d_instantiate_new+0x38/0x90
   btrfs_mkdir+0x1cf/0x1e0
   vfs_mkdir+0x14f/0x200
   do_mkdirat+0x6d/0x110
   do_syscall_64+0x2d/0x40
   entry_SYSCALL_64_after_hwframe+0x44/0xa9
  RIP: 0033:0x7f673196ae6b
  Code: 8b 05 11 (...)
  RSP: 002b:00007ffc3c679b18 EFLAGS: 00000246 ORIG_RAX: 0000000000000053
  RAX: ffffffffffffffda RBX: 00000000000001ff RCX: 00007f673196ae6b
  RDX: 0000000000000000 RSI: 00000000000001ff RDI: 00007ffc3c67a30d
  RBP: 00007ffc3c67a30d R08: 00000000000001ff R09: 0000000000000000
  R10: 000055d3e39fe930 R11: 0000000000000246 R12: 0000000000000000
  R13: 00007ffc3c679cd8 R14: 00007ffc3c67a30d R15: 00007ffc3c679ce0
  irq event stamp: 11029
  hardirqs last  enabled at (11037): [<ffffffff81153fe6>] console_unlock+0x486/0x670
  hardirqs last disabled at (11044): [<ffffffff81153c01>] console_unlock+0xa1/0x670
  softirqs last  enabled at (8864): [<ffffffff81e0102f>] asm_call_on_stack+0xf/0x20
  softirqs last disabled at (8851): [<ffffffff81e0102f>] asm_call_on_stack+0xf/0x20

This happens because at btrfs_mkdir() we call d_instantiate_new() while
holding a transaction handle, which results in the following call chain:

  btrfs_mkdir()
     trans = btrfs_start_transaction(root, 5);

     d_instantiate_new()
        smack_d_instantiate()
            __vfs_setxattr()
                btrfs_setxattr_trans()
                   btrfs_start_transaction()
                      start_transaction()
                         WARN_ON()
                           --> a tansaction start has TRANS_EXTWRITERS
                               set in its type
                         h->orig_rsv = h->block_rsv
                         h->block_rsv = NULL

     btrfs_end_transaction(trans)

Besides the warning triggered at start_transaction, we set the handle's
block_rsv to NULL which may cause some surprises later on.

So fix this by making btrfs_setxattr_trans() not start a transaction when
we already have a handle on one, stored in current->journal_info, and use
that handle. We are good to use the handle because at btrfs_mkdir() we did
reserve space for the xattr and the inode item.

Reported-by: Casey Schaufler <[email protected]>
CC: [email protected] # 5.4+
Acked-by: Casey Schaufler <[email protected]>
Tested-by: Casey Schaufler <[email protected]>
Link: https://lore.kernel.org/linux-btrfs/[email protected]/
Signed-off-by: Filipe Manana <[email protected]>
Signed-off-by: David Sterba <[email protected]>
4 years agobtrfs: don't flush from btrfs_delayed_inode_reserve_metadata
Nikolay Borisov [Mon, 22 Feb 2021 16:40:44 +0000 (18:40 +0200)]
btrfs: don't flush from btrfs_delayed_inode_reserve_metadata

Calling btrfs_qgroup_reserve_meta_prealloc from
btrfs_delayed_inode_reserve_metadata can result in flushing delalloc
while holding a transaction and delayed node locks. This is deadlock
prone. In the past multiple commits:

 * ae5e070eaca9 ("btrfs: qgroup: don't try to wait flushing if we're
already holding a transaction")

 * 6f23277a49e6 ("btrfs: qgroup: don't commit transaction when we already
 hold the handle")

Tried to solve various aspects of this but this was always a
whack-a-mole game. Unfortunately those 2 fixes don't solve a deadlock
scenario involving btrfs_delayed_node::mutex. Namely, one thread
can call btrfs_dirty_inode as a result of reading a file and modifying
its atime:

  PID: 6963   TASK: ffff8c7f3f94c000  CPU: 2   COMMAND: "test"
  #0  __schedule at ffffffffa529e07d
  #1  schedule at ffffffffa529e4ff
  #2  schedule_timeout at ffffffffa52a1bdd
  #3  wait_for_completion at ffffffffa529eeea             <-- sleeps with delayed node mutex held
  #4  start_delalloc_inodes at ffffffffc0380db5
  #5  btrfs_start_delalloc_snapshot at ffffffffc0393836
  #6  try_flush_qgroup at ffffffffc03f04b2
  #7  __btrfs_qgroup_reserve_meta at ffffffffc03f5bb6     <-- tries to reserve space and starts delalloc inodes.
  #8  btrfs_delayed_update_inode at ffffffffc03e31aa      <-- acquires delayed node mutex
  #9  btrfs_update_inode at ffffffffc0385ba8
 #10  btrfs_dirty_inode at ffffffffc038627b               <-- TRANSACTIION OPENED
 #11  touch_atime at ffffffffa4cf0000
 #12  generic_file_read_iter at ffffffffa4c1f123
 #13  new_sync_read at ffffffffa4ccdc8a
 #14  vfs_read at ffffffffa4cd0849
 #15  ksys_read at ffffffffa4cd0bd1
 #16  do_syscall_64 at ffffffffa4a052eb
 #17  entry_SYSCALL_64_after_hwframe at ffffffffa540008c

This will cause an asynchronous work to flush the delalloc inodes to
happen which can try to acquire the same delayed_node mutex:

  PID: 455    TASK: ffff8c8085fa4000  CPU: 5   COMMAND: "kworker/u16:30"
  #0  __schedule at ffffffffa529e07d
  #1  schedule at ffffffffa529e4ff
  #2  schedule_preempt_disabled at ffffffffa529e80a
  #3  __mutex_lock at ffffffffa529fdcb                    <-- goes to sleep, never wakes up.
  #4  btrfs_delayed_update_inode at ffffffffc03e3143      <-- tries to acquire the mutex
  #5  btrfs_update_inode at ffffffffc0385ba8              <-- this is the same inode that pid 6963 is holding
  #6  cow_file_range_inline.constprop.78 at ffffffffc0386be7
  #7  cow_file_range at ffffffffc03879c1
  #8  btrfs_run_delalloc_range at ffffffffc038894c
  #9  writepage_delalloc at ffffffffc03a3c8f
 #10  __extent_writepage at ffffffffc03a4c01
 #11  extent_write_cache_pages at ffffffffc03a500b
 #12  extent_writepages at ffffffffc03a6de2
 #13  do_writepages at ffffffffa4c277eb
 #14  __filemap_fdatawrite_range at ffffffffa4c1e5bb
 #15  btrfs_run_delalloc_work at ffffffffc0380987         <-- starts running delayed nodes
 #16  normal_work_helper at ffffffffc03b706c
 #17  process_one_work at ffffffffa4aba4e4
 #18  worker_thread at ffffffffa4aba6fd
 #19  kthread at ffffffffa4ac0a3d
 #20  ret_from_fork at ffffffffa54001ff

To fully address those cases the complete fix is to never issue any
flushing while holding the transaction or the delayed node lock. This
patch achieves it by calling qgroup_reserve_meta directly which will
either succeed without flushing or will fail and return -EDQUOT. In the
latter case that return value is going to be propagated to
btrfs_dirty_inode which will fallback to start a new transaction. That's
fine as the majority of time we expect the inode will have
BTRFS_DELAYED_NODE_INODE_DIRTY flag set which will result in directly
copying the in-memory state.

Fixes: c53e9653605d ("btrfs: qgroup: try to flush qgroup space when we get -EDQUOT")
CC: [email protected] # 5.10+
Reviewed-by: Qu Wenruo <[email protected]>
Signed-off-by: Nikolay Borisov <[email protected]>
Signed-off-by: David Sterba <[email protected]>
4 years agobtrfs: export and rename qgroup_reserve_meta
Nikolay Borisov [Mon, 22 Feb 2021 16:40:43 +0000 (18:40 +0200)]
btrfs: export and rename qgroup_reserve_meta

Signed-off-by: Nikolay Borisov <[email protected]>
Reviewed-by: David Sterba <[email protected]>
Signed-off-by: David Sterba <[email protected]>
4 years agobtrfs: free correct amount of space in btrfs_delayed_inode_reserve_metadata
Nikolay Borisov [Mon, 22 Feb 2021 16:40:42 +0000 (18:40 +0200)]
btrfs: free correct amount of space in btrfs_delayed_inode_reserve_metadata

Following commit f218ea6c4792 ("btrfs: delayed-inode: Remove wrong
qgroup meta reservation calls") this function now reserves num_bytes,
rather than the fixed amount of nodesize. As such this requires the
same amount to be freed in case of failure. Fix this by adjusting
the amount we are freeing.

Fixes: f218ea6c4792 ("btrfs: delayed-inode: Remove wrong qgroup meta reservation calls")
CC: [email protected] # 4.19+
Reviewed-by: Qu Wenruo <[email protected]>
Signed-off-by: Nikolay Borisov <[email protected]>
Reviewed-by: David Sterba <[email protected]>
Signed-off-by: David Sterba <[email protected]>
4 years agobtrfs: fix spurious free_space_tree remount warning
Boris Burkov [Tue, 23 Feb 2021 18:22:32 +0000 (10:22 -0800)]
btrfs: fix spurious free_space_tree remount warning

The intended logic of the check is to catch cases where the desired
free_space_tree setting doesn't match the mounted setting, and the
remount is anything but ro->rw. However, it makes the mistake of
checking equality on a masked integer (btrfs_test_opt) against a boolean
(btrfs_fs_compat_ro).

If you run the reproducer:
  $ mount -o space_cache=v2 dev mnt
  $ mount -o remount,ro mnt

you would expect no warning, because the remount is not attempting to
change the free space tree setting, but we do see the warning.

To fix this, add explicit bool type casts to the condition.

I tested a variety of transitions:
sudo mount -o space_cache=v2 /dev/vg0/lv0 mnt/lol
(fst enabled)
mount -o remount,ro mnt/lol
(no warning, no fst change)
sudo mount -o remount,rw,space_cache=v1,clear_cache
(no warning, ro->rw)
sudo mount -o remount,rw,space_cache=v2 mnt
(warning, rw->rw with change)
sudo mount -o remount,ro mnt
(no warning, no fst change)
sudo mount -o remount,rw,space_cache=v2 mnt
(no warning, no fst change)

Reported-by: Chris Murphy <[email protected]>
CC: [email protected] # 5.11
Signed-off-by: Boris Burkov <[email protected]>
Reviewed-by: David Sterba <[email protected]>
Signed-off-by: David Sterba <[email protected]>
4 years agobtrfs: validate qgroup inherit for SNAP_CREATE_V2 ioctl
Dan Carpenter [Wed, 17 Feb 2021 06:04:34 +0000 (09:04 +0300)]
btrfs: validate qgroup inherit for SNAP_CREATE_V2 ioctl

The problem is we're copying "inherit" from user space but we don't
necessarily know that we're copying enough data for a 64 byte
struct.  Then the next problem is that 'inherit' has a variable size
array at the end, and we have to verify that array is the size we
expected.

Fixes: 6f72c7e20dba ("Btrfs: add qgroup inheritance")
CC: [email protected] # 4.4+
Signed-off-by: Dan Carpenter <[email protected]>
Reviewed-by: David Sterba <[email protected]>
Signed-off-by: David Sterba <[email protected]>
4 years agobtrfs: unlock extents in btrfs_zero_range in case of quota reservation errors
Nikolay Borisov [Tue, 23 Feb 2021 13:20:42 +0000 (15:20 +0200)]
btrfs: unlock extents in btrfs_zero_range in case of quota reservation errors

If btrfs_qgroup_reserve_data returns an error (i.e quota limit reached)
the handling logic directly goes to the 'out' label without first
unlocking the extent range between lockstart, lockend. This results in
deadlocks as other processes try to lock the same extent.

Fixes: a7f8b1c2ac21 ("btrfs: file: reserve qgroup space after the hole punch range is locked")
CC: [email protected] # 5.10+
Reviewed-by: Qu Wenruo <[email protected]>
Signed-off-by: Nikolay Borisov <[email protected]>
Reviewed-by: David Sterba <[email protected]>
Signed-off-by: David Sterba <[email protected]>
4 years agobtrfs: ref-verify: use 'inline void' keyword ordering
Randy Dunlap [Fri, 19 Feb 2021 06:54:17 +0000 (22:54 -0800)]
btrfs: ref-verify: use 'inline void' keyword ordering

Fix build warnings of function signature when CONFIG_STACKTRACE is not
enabled by reordering the 'inline' and 'void' keywords.

../fs/btrfs/ref-verify.c:221:1: warning: â€˜inline’ is not at beginning of declaration [-Wold-style-declaration]
 static void inline __save_stack_trace(struct ref_action *ra)
../fs/btrfs/ref-verify.c:225:1: warning: â€˜inline’ is not at beginning of declaration [-Wold-style-declaration]
 static void inline __print_stack_trace(struct btrfs_fs_info *fs_info,

Signed-off-by: Randy Dunlap <[email protected]>
Reviewed-by: David Sterba <[email protected]>
Signed-off-by: David Sterba <[email protected]>
4 years agoALSA: hda: intel-sdw-acpi: add missing include files
Pierre-Louis Bossart [Tue, 2 Mar 2021 00:31:25 +0000 (18:31 -0600)]
ALSA: hda: intel-sdw-acpi: add missing include files

We rely on implicit includes, list out explicitly what this code
relies on.

Suggested-by: Guennadi Liakhovetski <[email protected]>
Signed-off-by: Pierre-Louis Bossart <[email protected]>
Reviewed-by: Kai Vehmanen <[email protected]>
Reviewed-by: Guennadi Liakhovetski <[email protected]>
Reviewed-by: Bard Liao <[email protected]>
Acked-by: Mark Brown <[email protected]>
Acked-by: Vinod Koul <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
4 years agoALSA: hda: move Intel SoundWire ACPI scan to dedicated module
Pierre-Louis Bossart [Tue, 2 Mar 2021 00:31:24 +0000 (18:31 -0600)]
ALSA: hda: move Intel SoundWire ACPI scan to dedicated module

The ACPI scan capabilities is called from the intel-dspconfig as well
as the SOF/HDaudio drivers. This creates dependencies and randconfig issues
when HDaudio and SOF/SoundWire are not all configured as modules.

To simplify Kconfig dependencies between HDAudio, SoundWire, SOF and
intel-dspconfig, move the ACPI scan helpers to a dedicated
module. This follows the same idea as NHLT helpers which are already
handled as a dedicated module.

The only functional change is that the kernel parameter to filter
links is now handled by a different module, but that was only provided
for developers needing work-arounds for early BIOS releases.

Reported-by: Arnd Bergmann <[email protected]>
Signed-off-by: Pierre-Louis Bossart <[email protected]>
Reviewed-by: Kai Vehmanen <[email protected]>
Reviewed-by: Guennadi Liakhovetski <[email protected]>
Reviewed-by: Bard Liao <[email protected]>
Acked-by: Mark Brown <[email protected]>
Acked-by: Vinod Koul <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
4 years agoASoC: SOF: Intel: SoundWire: simplify Kconfig
Pierre-Louis Bossart [Tue, 2 Mar 2021 00:31:23 +0000 (18:31 -0600)]
ASoC: SOF: Intel: SoundWire: simplify Kconfig

The Kconfig file is way too convoluted. Track platforms where
SoundWire is supported, and add simpler conditions to make sure there
is no module/built-in issue.

The use of 'depends on' is less intuitive if a required 'depend' is
missing, but that's a small price to pay for clarity and simplicity.

Suggested-by: Arnd Bergmann <[email protected]>
Signed-off-by: Pierre-Louis Bossart <[email protected]>
Reviewed-by: Kai Vehmanen <[email protected]>
Reviewed-by: Guennadi Liakhovetski <[email protected]>
Reviewed-by: Bard Liao <[email protected]>
Acked-by: Mark Brown <[email protected]>
Acked-by: Vinod Koul <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
4 years agoASoC: SOF: pci: move DSP_CONFIG use to platform-specific drivers
Pierre-Louis Bossart [Tue, 2 Mar 2021 00:31:22 +0000 (18:31 -0600)]
ASoC: SOF: pci: move DSP_CONFIG use to platform-specific drivers

There is no reason why we should call the intel_dspcfg helpers from
common code, this should be moved in Intel-specific code and only
called from platforms where a conflict may occur with the HDaudio or
SST/Skylake driver.

Suggested-by: Arnd Bergmann <[email protected]>
Signed-off-by: Pierre-Louis Bossart <[email protected]>
Reviewed-by: Kai Vehmanen <[email protected]>
Reviewed-by: Guennadi Liakhovetski <[email protected]>
Reviewed-by: Bard Liao <[email protected]>
Acked-by: Mark Brown <[email protected]>
Acked-by: Vinod Koul <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
4 years agoASoC: SOF: pci: split PCI into different drivers
Pierre-Louis Bossart [Tue, 2 Mar 2021 00:31:21 +0000 (18:31 -0600)]
ASoC: SOF: pci: split PCI into different drivers

Move PCI IDs and device-specific definitions out of common code. No
functionality change for now, just code split and removal of
IF_ENABLED() which made the configurations too complicated in case of
reuse of IP across generations.

Additional changes to address the DSP_CONFIG case and SoundWire
depends/select confusions are provided in follow-up patches.

Suggested-by: Arnd Bergmann <[email protected]>
Signed-off-by: Pierre-Louis Bossart <[email protected]>
Reviewed-by: Kai Vehmanen <[email protected]>
Reviewed-by: Guennadi Liakhovetski <[email protected]>
Reviewed-by: Bard Liao <[email protected]>
Acked-by: Mark Brown <[email protected]>
Acked-by: Vinod Koul <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
4 years agoASoC: SOF: ACPI: avoid reverse module dependency
Arnd Bergmann [Tue, 2 Mar 2021 00:31:20 +0000 (18:31 -0600)]
ASoC: SOF: ACPI: avoid reverse module dependency

The SOF-ACPI driver is backwards from the normal Linux model, it has a
generic driver that knows about all the specific drivers, as opposed to
having hardware specific drivers that link against a common framework.

This requires ugly Kconfig magic and leads to missed dependencies as
seen in this link error:

arm-linux-gnueabi-ld: sound/soc/sof/sof-pci-dev.o: in function `sof_acpi_probe':
sof-pci-dev.c:(.text+0x1c): undefined reference to `snd_intel_dsp_driver_probe'

Change it to use the normal probe order of starting with a specific
device in a driver, turning the sof-acpi-dev.c driver into a
library (exported symbols are name-spaced to avoid symbol pollution).

For backwards-compatibility with previous Kconfigs, the default values
for platform drivers uses the top-level ACPI configurations. The
modules were also renamed to allow for gradual transitions in test
scripts.

Co-developed-by: Pierre-Louis Bossart <[email protected]>
Signed-off-by: Pierre-Louis Bossart <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
Reviewed-by: Kai Vehmanen <[email protected]>
Reviewed-by: Guennadi Liakhovetski <[email protected]>
Reviewed-by: Bard Liao <[email protected]>
Acked-by: Mark Brown <[email protected]>
Acked-by: Vinod Koul <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
4 years agoASoC: soc-acpi: allow for partial match in parent name
Pierre-Louis Bossart [Tue, 2 Mar 2021 00:31:19 +0000 (18:31 -0600)]
ASoC: soc-acpi: allow for partial match in parent name

To change the module dependencies and simplify Kconfigs, we need to
introduce new driver names (sof-audio-acpi-intel-byt and
sof-audio-acpi-intel-bdw), and move from an exact string match to a
partial one.

Signed-off-by: Pierre-Louis Bossart <[email protected]>
Reviewed-by: Kai Vehmanen <[email protected]>
Reviewed-by: Guennadi Liakhovetski <[email protected]>
Reviewed-by: Bard Liao <[email protected]>
Acked-by: Mark Brown <[email protected]>
Acked-by: Vinod Koul <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
4 years agodrm/nouveau/fifo/gk104-gp1xx: fix creation of sw class
Ben Skeggs [Tue, 2 Mar 2021 11:36:14 +0000 (21:36 +1000)]
drm/nouveau/fifo/gk104-gp1xx: fix creation of sw class

Fixes: 496162037cd24191 ("drm/nouveau/fifo: add id_engine hook")
Signed-off-by: Ben Skeggs <[email protected]>
4 years agoALSA: hda: intel-nhlt: verify config type
Pierre-Louis Bossart [Tue, 2 Mar 2021 00:01:46 +0000 (18:01 -0600)]
ALSA: hda: intel-nhlt: verify config type

Multiple bug reports report issues with the SOF and SST drivers when
dealing with single microphone cases.

We currently read the DMIC array information unconditionally but we
don't check that the configuration type is actually a mic array.

When the DMIC link does not rely on a mic array configuration, the
recommendation is to check the format information to infer the maximum
number of channels, and map this to the number of microphones.

This leaves a potential for a mismatch between actual microphones
available in hardware and what the ACPI table contains, but we have no
other source of information.

Note that single microphone configurations can alternatively be
handled with a 'mic array' configuration along with a 'vendor-defined'
geometry.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=201251
BugLink: https://github.com/thesofproject/linux/issues/2725
Fixes: 7a33ea70e1868 ('ALSA: hda: intel-nhlt: handle NHLT VENDOR_DEFINED DMIC geometry')
Signed-off-by: Pierre-Louis Bossart <[email protected]>
Reviewed-by: Guennadi Liakhovetski <[email protected]>
Reviewed-by: Rander Wang <[email protected]>
Reviewed-by: Kai Vehmanen <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
4 years agoALSA: hda: fix kernel-doc warnings
Pierre-Louis Bossart [Mon, 1 Mar 2021 17:46:17 +0000 (11:46 -0600)]
ALSA: hda: fix kernel-doc warnings

v5.12-rc1 flags new warnings with make W=1, fix missing or broken
function descriptors.

sound/pci/hda/hda_codec.c:3492: warning: expecting prototype for
snd_hda_input_mux_info_info(). Prototype was for
snd_hda_input_mux_info() instead

sound/pci/hda/hda_codec.c:3521: warning: expecting prototype for
snd_hda_input_mux_info_put(). Prototype was for
snd_hda_input_mux_put() instead

sound/pci/hda/hda_codec.c:3958: warning: expecting prototype for
_snd_hda_pin_ctl(). Prototype was for _snd_hda_set_pin_ctl() instead

sound/pci/hda/hda_jack.c:223: warning: expecting prototype for
snd_hda_set_dirty_all(). Prototype was for
snd_hda_jack_set_dirty_all() instead

sound/pci/hda/hda_jack.c:309: warning: expecting prototype for
snd_hda_jack_detect_enable_mst(). Prototype was for
snd_hda_jack_detect_enable_callback_mst() instead

sound/pci/hda/hda_generic.c:3933: warning: expecting prototype for
snd_dha_gen_add_mute_led_cdev(). Prototype was for
snd_hda_gen_add_mute_led_cdev() instead

sound/pci/hda/hda_generic.c:4093: warning: expecting prototype for
snd_dha_gen_add_micmute_led_cdev(). Prototype was for
snd_hda_gen_add_micmute_led_cdev() instead

sound/pci/hda/patch_ca0132.c:2357: warning: expecting prototype for
Prepare and send the SCP message to DSP(). Prototype was for
dspio_scp() instead

sound/pci/hda/patch_ca0132.c:2883: warning: expecting prototype for
Allocate router ports(). Prototype was for dsp_allocate_router_ports()
instead

sound/pci/hda/patch_ca0132.c:3202: warning: expecting prototype for
Write a block of data into DSP code or data RAM using pre(). Prototype
was for dspxfr_one_seg() instead

sound/pci/hda/patch_ca0132.c:3397: warning: expecting prototype for
data overlay to DSP memories(). Prototype was for dspxfr_image()
instead

sound/hda/hdac_regmap.c:393: warning: expecting prototype for
snd_hdac_regmap_init(). Prototype was for snd_hdac_regmap_exit()
instead

sound/hda/ext/hdac_ext_controller.c:142: warning: expecting prototype
for snd_hdac_ext_bus_get_link_index(). Prototype was for
snd_hdac_ext_bus_get_link() instead

sound/hda/ext/hdac_ext_stream.c:140: warning: expecting prototype for
snd_hdac_ext_linkstream_start(). Prototype was for
snd_hdac_ext_link_stream_start() instead

Signed-off-by: Pierre-Louis Bossart <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
4 years agogcc-plugins: latent_entropy: remove unneeded semicolon
Jason Yan [Sat, 18 Apr 2020 07:05:21 +0000 (15:05 +0800)]
gcc-plugins: latent_entropy: remove unneeded semicolon

Fix the following coccicheck warning:

scripts/gcc-plugins/latent_entropy_plugin.c:539:2-3: Unneeded semicolon

Reported-by: Hulk Robot <[email protected]>
Signed-off-by: Jason Yan <[email protected]>
Signed-off-by: Kees Cook <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
4 years agogcc-plugins: structleak: remove unneeded variable 'ret'
Jason Yan [Sat, 18 Apr 2020 07:05:05 +0000 (15:05 +0800)]
gcc-plugins: structleak: remove unneeded variable 'ret'

Fix the following coccicheck warning:

scripts/gcc-plugins/structleak_plugin.c:177:14-17: Unneeded variable:
"ret". Return "0" on line 207

Reported-by: Hulk Robot <[email protected]>
Signed-off-by: Jason Yan <[email protected]>
Signed-off-by: Kees Cook <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
4 years agoMerge branch 'kmap-conversion-for-5.12' of git://git.kernel.org/pub/scm/linux/kernel...
Linus Torvalds [Mon, 1 Mar 2021 19:24:18 +0000 (11:24 -0800)]
Merge branch 'kmap-conversion-for-5.12' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux

Pull kmap conversion updates from David Sterba:
 "This contains changes regarding kmap API use and eg conversion from
  kmap_atomic to kmap_local_page.

  The API belongs to memory management but to save cross-tree
  dependency headaches we've agreed to take it through the btrfs tree
  because there are some trivial conversions possible, while the rest
  will need some time and getting the easy cases out of the way would be
  convenient.

  The changes can be grouped:

   - function exports, new helpers

   - new VM_BUG_ON for additional verification; it's been discussed if
     it should be VM_BUG_ON or BUG_ON, the former was chosen due to
     performance reasons

   - code replaced by relevant helpers"

[ This is an updated version of a request that originally came in during
  the merge window, but I asked for some updates:

    https://lore.kernel.org/lkml/cover.1614090658[email protected]/

  which is why this got merge after the merge window closed.  - Linus ]

* 'kmap-conversion-for-5.12' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux:
  btrfs: use copy_highpage() instead of 2 kmaps()
  btrfs: use memcpy_[to|from]_page() and kmap_local_page()
  mm/highmem: Add VM_BUG_ON() to mem*_page() calls
  mm/highmem: Introduce memcpy_page(), memmove_page(), and memset_page()
  mm/highmem: Convert memcpy_[to|from]_page() to kmap_local_page()
  mm/highmem: Lift memcpy_[to|from]_page to core

4 years agoMerge tag 'for-5.12-rc1-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave...
Linus Torvalds [Mon, 1 Mar 2021 19:17:37 +0000 (11:17 -0800)]
Merge tag 'for-5.12-rc1-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux

Pull btrfs fixes from David Sterba:
 "This is the first batch of fixes that usually arrive during the merge
  window code freeze. Regressions and stable material.

  Regressions:

   - fix deadlock in log sync in zoned mode

   - fix bugs in subpage mode still wrongly assuming sectorsize == page
     size

  Fixes:

   - fix missing kunmap of the Q stripe in RAID6

   - block group fixes:
      - fix race between extent freeing/allocation when using bitmaps
      - avoid double put of block group when emptying cluster

   - swapfile fixes:
      - fix swapfile writes vs running scrub
      - fix swapfile activation vs snapshot creation

   - fix stale data exposure after cloning a hole with NO_HOLES enabled

   - remove tree-checker check that does not work in case information
     from other leaves is necessary"

* tag 'for-5.12-rc1-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux:
  btrfs: zoned: fix deadlock on log sync
  btrfs: avoid double put of block group when emptying cluster
  btrfs: fix stale data exposure after cloning a hole with NO_HOLES enabled
  btrfs: tree-checker: do not error out if extent ref hash doesn't match
  btrfs: fix race between swap file activation and snapshot creation
  btrfs: fix race between writes to swap files and scrub
  btrfs: avoid checking for RO block group twice during nocow writeback
  btrfs: fix race between extent freeing/allocation when using bitmaps
  btrfs: make check_compressed_csum() to be subpage compatible
  btrfs: make btrfs_submit_compressed_read() subpage compatible
  btrfs: fix raid6 qstripe kmap

4 years agoIB/mlx5: Add missing error code
YueHaibing [Mon, 22 Feb 2021 12:23:43 +0000 (20:23 +0800)]
IB/mlx5: Add missing error code

Set err to -ENOMEM if kzalloc fails instead of 0.

Fixes: 759738537142 ("IB/mlx5: Enable subscription for device events over DEVX")
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: YueHaibing <[email protected]>
Acked-by: Leon Romanovsky <[email protected]>
Signed-off-by: Jason Gunthorpe <[email protected]>
4 years agoRDMA/rxe: Fix missing kconfig dependency on CRYPTO
Julian Braha [Fri, 19 Feb 2021 23:32:26 +0000 (18:32 -0500)]
RDMA/rxe: Fix missing kconfig dependency on CRYPTO

When RDMA_RXE is enabled and CRYPTO is disabled, Kbuild gives the
following warning:

 WARNING: unmet direct dependencies detected for CRYPTO_CRC32
   Depends on [n]: CRYPTO [=n]
   Selected by [y]:
   - RDMA_RXE [=y] && (INFINIBAND_USER_ACCESS [=y] || !INFINIBAND_USER_ACCESS [=y]) && INET [=y] && PCI [=y] && INFINIBAND [=y] && INFINIBAND_VIRT_DMA [=y]

This is because RDMA_RXE selects CRYPTO_CRC32, without depending on or
selecting CRYPTO, despite that config option being subordinate to CRYPTO.

Fixes: cee2688e3cd6 ("IB/rxe: Offload CRC calculation when possible")
Signed-off-by: Julian Braha <[email protected]>
Link: https://lore.kernel.org/r/21525878.NYvzQUHefP@ubuntu-mate-laptop
Signed-off-by: Jason Gunthorpe <[email protected]>
4 years agoRDMA/cm: Fix IRQ restore in ib_send_cm_sidr_rep
Saeed Mahameed [Mon, 1 Mar 2021 08:18:44 +0000 (10:18 +0200)]
RDMA/cm: Fix IRQ restore in ib_send_cm_sidr_rep

ib_send_cm_sidr_rep() {
spin_lock_irqsave()
        cm_send_sidr_rep_locked() {
                ...
         spin_lock_irq()
                ....
                spin_unlock_irq() <--- this will enable interrupts
        }
        spin_unlock_irqrestore()
}

spin_unlock_irqrestore() expects interrupts to be disabled but the
internal spin_unlock_irq() will always enable hard interrupts.

Fix this by replacing the internal spin_{lock,unlock}_irq() with
irqsave/restore variants.

It fixes the following kernel trace:

 raw_local_irq_restore() called with IRQs enabled
 WARNING: CPU: 2 PID: 20001 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x1d/0x20

 Call Trace:
  _raw_spin_unlock_irqrestore+0x4e/0x50
  ib_send_cm_sidr_rep+0x3a/0x50 [ib_cm]
  cma_send_sidr_rep+0xa1/0x160 [rdma_cm]
  rdma_accept+0x25e/0x350 [rdma_cm]
  ucma_accept+0x132/0x1cc [rdma_ucm]
  ucma_write+0xbf/0x140 [rdma_ucm]
  vfs_write+0xc1/0x340
  ksys_write+0xb3/0xe0
  do_syscall_64+0x2d/0x40
  entry_SYSCALL_64_after_hwframe+0x44/0xae

Fixes: 87c4c774cbef ("RDMA/cm: Protect access to remote_sidr_table")
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Saeed Mahameed <[email protected]>
Reviewed-by: Jason Gunthorpe <[email protected]>
Signed-off-by: Leon Romanovsky <[email protected]>
Signed-off-by: Jason Gunthorpe <[email protected]>
4 years agodt-bindings: media: Use graph and video-interfaces schemas, round 2
Rob Herring [Tue, 23 Feb 2021 21:01:27 +0000 (15:01 -0600)]
dt-bindings: media: Use graph and video-interfaces schemas, round 2

A couple of media schemas got applied without using or incorrectly
using the video-interfaces.yaml and graph.yaml schemas. Fix them up
before we have more copy-n-paste errors.

Fixes: 41b3e23376e9 ("media: dt-bindings: media: Add bindings for imx334")
Fixes: d899e5f1db7a ("media: dt-bindings: media: imx258: add bindings for IMX258 sensor")
Fixes: 918b866edfec ("media: dt-bindings: Remove old ov5647.yaml file, update ovti,ov5647.yaml")
Fixes: 22f2b47517a6 ("media: dt-bindings: media: i2c: Add OV8865 bindings documentation")
Fixes: 29a202fa7acc ("media: dt-bindings: media: i2c: Add OV5648 bindings documentation")
Cc: Sakari Ailus <[email protected]>
Cc: Mauro Carvalho Chehab <[email protected]>
Cc: Dave Stevenson <[email protected]>
Cc: Jacopo Mondi <[email protected]>
Cc: "Paul J. Murphy" <[email protected]>
Cc: Daniele Alessandrelli <[email protected]>
Cc: Krzysztof Kozlowski <[email protected]>
Cc: Paul Kocialkowski <[email protected]>
Cc: [email protected]
Signed-off-by: Rob Herring <[email protected]>
Acked-by: Sakari Ailus <[email protected]>
Acked-by: Krzysztof Kozlowski <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
4 years agoio-wq: wait for worker startup when forking a new one
Jens Axboe [Fri, 26 Feb 2021 16:50:55 +0000 (09:50 -0700)]
io-wq: wait for worker startup when forking a new one

We need to have our worker count updated before continuing, to avoid
cases where we repeatedly think we need a new worker, but a fork is
already in progress.

Signed-off-by: Jens Axboe <[email protected]>
4 years agoblock: Drop leftover references to RQF_SORTED
Jean Delvare [Mon, 1 Mar 2021 16:23:25 +0000 (17:23 +0100)]
block: Drop leftover references to RQF_SORTED

Commit a1ce35fa49852db60fc6e268038530be533c5b15 ("block: remove dead
elevator code") removed all users of RQF_SORTED. However it is still
defined, and there is one reference left to it (which in effect is
dead code). Clear it all up.

Signed-off-by: Jean Delvare <[email protected]>
Cc: Jens Axboe <[email protected]>
Cc: Ming Lei <[email protected]>
Cc: Omar Sandoval <[email protected]>
Cc: Hannes Reinecke <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
4 years agopowercap/drivers/dtpm: Add the experimental label to the option description
Daniel Lezcano [Wed, 24 Feb 2021 18:30:22 +0000 (19:30 +0100)]
powercap/drivers/dtpm: Add the experimental label to the option description

The DTPM framework will evolve in the next cycles. Let's add a
temporary EXPERIMENTAL tag to the option so users will be aware
the API may change over time.

Signed-off-by: Daniel Lezcano <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
4 years agopowercap/drivers/dtpm: Fix root node initialization
Daniel Lezcano [Wed, 24 Feb 2021 18:30:21 +0000 (19:30 +0100)]
powercap/drivers/dtpm: Fix root node initialization

The root node is not set to NULL when the dtpm root node is
removed. Consequently, it is not possible to create a new root
as it is already set.

Set the root node to NULL when the last node is removed.

Signed-off-by: Daniel Lezcano <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
4 years agoPM: runtime: Update device status before letting suppliers suspend
Rafael J. Wysocki [Thu, 25 Feb 2021 18:23:27 +0000 (19:23 +0100)]
PM: runtime: Update device status before letting suppliers suspend

Because the PM-runtime status of the device is not updated in
__rpm_callback(), attempts to suspend the suppliers of the given
device triggered by rpm_put_suppliers() called by it may fail.

Fix this by making __rpm_callback() update the device's status to
RPM_SUSPENDED before calling rpm_put_suppliers() if the current
status of the device is RPM_SUSPENDING and the callback just invoked
by it has returned 0 (success).

While at it, modify the code in __rpm_callback() to always check
the device's PM-runtime status under its PM lock.

Link: https://lore.kernel.org/linux-pm/CAPDyKFqm06KDw_p8WXsM4dijDbho4bb6T4k50UqqvR1_COsp8g@mail.gmail.com/
Fixes: 21d5c57b3726 ("PM / runtime: Use device links")
Reported-by: Elaine Zhang <[email protected]>
Diagnosed-by: Ulf Hansson <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Tested-by: Elaine Zhang <[email protected]>
Reviewed-by: Ulf Hansson <[email protected]>
Cc: 4.10+ <[email protected]> # 4.10+
Signed-off-by: Rafael J. Wysocki <[email protected]>
4 years agoALSA: usb-audio: Fix Pioneer DJM devices URB_CONTROL request direction to set samplerate
Nicolas MURE [Mon, 1 Mar 2021 14:29:27 +0000 (15:29 +0100)]
ALSA: usb-audio: Fix Pioneer DJM devices URB_CONTROL request direction to set samplerate

This commit only contains the fix about the `URB_CONTROL` request
direction to set the samplerate of Pioneer DJM devices (`URB_CONTROL out`).

Fixes: 3b85f5fc75d5 ("ALSA: usb-audio: Add DJM450 to Pioneer format quirk")
Signed-off-by: Nicolas MURE <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
This page took 0.135537 seconds and 4 git commands to generate.