In KUNIT_EXPECT_MEMEQ and KUNIT_EXPECT_MEMNEQ, add check if one of the
inputs is NULL and fail if this is the case.
Currently, the kernel crashes if one of the inputs is NULL. Instead,
fail the test and add an appropriate error message.
Fixes: b8a926bea8 ("kunit: Introduce KUNIT_EXPECT_MEMEQ and KUNIT_EXPECT_MEMNEQ macros")
This was found by the kernel test robot:
https://lore.kernel.org/all/202212191448.D6EDPdOh-lkp@intel.com/
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Rae Moar <rmoar@google.com>
Reviewed-by: David Gow <davidgow@google.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Selecting CONFIG_PM_GENERIC_DOMAINS without CONFIG_PM leads to a
build failure:
WARNING: unmet direct dependencies detected for PM_GENERIC_DOMAINS
Depends on [n]: PM [=n]
Selected by [y]:
- SUN20I_PPU [=y] && (ARCH_SUNXI [=n] || COMPILE_TEST [=y])
drivers/base/power/domain_governor.c: In function 'default_suspend_ok':
drivers/base/power/domain_governor.c:85:24: error: 'struct dev_pm_info' has no member named 'ignore_children'
85 | if (!dev->power.ignore_children)
| ^
drivers/base/power/domain.c: In function 'genpd_queue_power_off_work':
drivers/base/power/domain.c:657:20: error: 'pm_wq' undeclared (first use in this function)
657 | queue_work(pm_wq, &genpd->power_off_work);
| ^~~~~
Unfortunately platforms are inconsistent between using 'select PM'
and 'depends on PM' here. CONFIG_PM is a user-visible symbol, so
in principle we should be using 'depends on', but on the other hand
using 'select' here is more common among drivers/soc. Go with the
majority for now, as this has a smaller risk of introducing circular
dependencies. We may need to clean this up for consistency later.
Fixes: 0e30ca5ab0 ("soc: sunxi: Add Allwinner D1 PPU driver")
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The current discard_io_aware_gran is a fixed value, change it to be
configurable through the sys node.
Signed-off-by: Yangtao Li <frank.li@vivo.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
No need to initialize idx twice. BTW, remove the unnecessary cnt variable.
Signed-off-by: Yangtao Li <frank.li@vivo.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Merge series from Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>:
Following is series of fixes and cleanups for core topology code. Few
patches fixing various problems all around and few fixing function
names.
A userspace with multiple threads racing I915_GEM_SET_TILING to set the
tiling to I915_TILING_NONE could trigger a double free of the bit_17
bitmask. (Or conversely leak memory on the transition to tiled.) Move
allocation/free'ing of the bitmask within the section protected by the
obj lock.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Fixes: 2850748ef8 ("drm/i915: Pull i915_vma_pin under the vm->mutex")
Cc: <stable@vger.kernel.org> # v5.5+
[tursulin: Correct fixes tag and added cc stable.]
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230127200550.3531984-1-robdclark@gmail.com
(cherry picked from commit 10e0cbaaf1)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
The debugfs dump of requests was confused about what state requires
the execlist lock versus the GuC lock. There was also a bunch of
duplicated messy code between it and the error capture code.
So refactor the hung request search into a re-usable function. And
reduce the span of the execlist state lock to only the execlist
specific code paths. In order to do that, also move the report of hold
count (which is an execlist only concept) from the top level dump
function to the lower level execlist specific function. Also, move the
execlist specific code into the execlist source file.
v2: Rename some functions and move to more appropriate files (Daniele).
v3: Rename new execlist dump function (Daniele)
Fixes: dc0dad365c ("drm/i915/guc: Fix for error capture after full GPU reset with GuC")
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Cc: Michael Cheng <michael.cheng@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Bruce Chang <yu.bruce.chang@intel.com>
Cc: Alan Previn <alan.previn.teres.alexis@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230127002842.3169194-4-John.C.Harrison@Intel.com
(cherry picked from commit a4be3dca53)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
When GuC support was added to error capture, the reference counting
around the request object was broken. Fix it up.
The context based search manages the spinlocking around the search
internally. So it needs to grab the reference count internally as
well. The execlist only request based search relies on external
locking, so it needs an external reference count but within the
spinlock not outside it.
The only other caller of the context based search is the code for
dumping engine state to debugfs. That code wasn't previously getting
an explicit reference at all as it does everything while holding the
execlist specific spinlock. So, that needs updaing as well as that
spinlock doesn't help when using GuC submission. Rather than trying to
conditionally get/put depending on submission model, just change it to
always do the get/put.
v2: Explicitly document adding an extra blank line in some dense code
(Andy Shevchenko). Fix multiple potential null pointer derefs in case
of no request found (some spotted by Tvrtko, but there was more!).
Also fix a leaked request in case of !started and another in
__guc_reset_context now that intel_context_find_active_request is
actually reference counting the returned request.
v3: Add a _get suffix to intel_context_find_active_request now that it
grabs a reference (Daniele).
v4: Split the intel_guc_find_hung_context change to a separate patch
and rename intel_context_find_active_request_get to
intel_context_get_active_request (Tvrtko).
v5: s/locking/reference counting/ in commit message (Tvrtko)
Fixes: dc0dad365c ("drm/i915/guc: Fix for error capture after full GPU reset with GuC")
Fixes: 573ba126ae ("drm/i915/guc: Capture error state on context reset")
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Andrzej Hajda <andrzej.hajda@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Cc: Michael Cheng <michael.cheng@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Aravind Iddamsetty <aravind.iddamsetty@intel.com>
Cc: Alan Previn <alan.previn.teres.alexis@intel.com>
Cc: Bruce Chang <yu.bruce.chang@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230127002842.3169194-3-John.C.Harrison@Intel.com
(cherry picked from commit 3700e35378)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
intel_guc_find_hung_context() was not acquiring the correct spinlock
before searching the request list. So fix that up. While at it, add
some extra whitespace padding for readability.
Fixes: dc0dad365c ("drm/i915/guc: Fix for error capture after full GPU reset with GuC")
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Cc: Michael Cheng <michael.cheng@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com>
Cc: Chris Wilson <chris.p.wilson@intel.com>
Cc: Bruce Chang <yu.bruce.chang@intel.com>
Cc: Alan Previn <alan.previn.teres.alexis@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230127002842.3169194-2-John.C.Harrison@Intel.com
(cherry picked from commit d1c3717501)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Adding the vm to the vm_xa table makes it visible to userspace, which
could try to race with us to close the vm. So we need to take our extra
reference before putting it in the table.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Fixes: 9ec8795e7d ("drm/i915: Drop __rcu from gem_context->vm")
Cc: <stable@vger.kernel.org> # v5.16+
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230119173321.2825472-1-robdclark@gmail.com
(cherry picked from commit 99343c46d4)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Merge series from Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>:
Audio-Graph-Card and Simple-Audio-Card are similar Card
and are sharing same utils. Thus we can also sharing same schema.
This patch-set fixup some Renesas's "make dtbs_check".
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEqG5UsNXhtOCrfGQP+7dXa6fLC2sFAmPXvZYACgkQ+7dXa6fL
C2vJAA//b5ApjHLzYq8rOh0aYEXaG7WAebrLOgc67TYALQFEVfXyNY6OAV+5ELbQ
3mOyuPMnt2rQc20RmTw3LzS8qSXe1+aNR76uTyNSJ3+04p4bdzkxj7wz9uSkyato
bCeJCwUIL/AcMv4HDlvM/+b7XvCY1tMAtnZqRLw4IXtw+6ZjPhXmf+NhLNY1iJ/2
pL4wijtMmg/auAB6bvZlQeBelgCp+N5mqb473cuTKibYFMoe7JG2dESdC7rUqVpH
dH1r9IHirkP0WS3eQnOqt0nhHRSvQZhtRzAszGTzBUc6knZ7GFs27JVfuJXeEmoh
YubJjGrY3yRF3T8VK3eI44imu3/Yb66bC2+Ykk8nHs8q4PpaQ//QWfN2ff8eXtlf
DGjRaD1abRBIPrFW2FujV4v8R7G0x0gnCrpJaoiOwn2pzwgu8XTC35MGFtd2yv19
WAsGMyzPrdfCWieiQ3WnQNy5F5MENPrXxVemi+cPlIuSfuPy9U67san/TpfCv3t9
hnv2BnIGcjy5xaayMHSKpO263J7PpX6vAlIXnDlurqYNNxjIbQkfAOz24Da3qHLE
jx4vkh5R8dgLoM3LLjOwv+AbyAAudfhYBemLBt0itmQuKerYWfQ+xjsgGMETQfPe
GrZtdEjceFpoy5yVBnFuBgv3m8q1pgWZ0LkPdKhjgFPW2bCVAgI=
=+bON
-----END PGP SIGNATURE-----
Merge tag 'fscache-fixes-20230130' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs
Pull fscache fixes from David Howells:
"Fix two problems in fscache volume handling:
- wake_up_bit() is incorrectly paired with wait_var_event(). The
latter selects the waitqueue to use differently.
- Missing barriers ordering between state bit and task state"
* tag 'fscache-fixes-20230130' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs:
fscache: Use clear_and_wake_up_bit() in fscache_create_volume_work()
fscache: Use wait_on_bit() to wait for the freeing of relinquished volume
Add a DT schema for describing Awinic AW88395 audio amplifiers. They are
controlled using I2C.
Signed-off-by: Weidong Wang <wangweidong.a@awinic.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230113055301.189541-6-wangweidong.a@awinic.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The Awinic AW88395 is an I2S/TDM input, high efficiency
digital Smart K audio amplifier with an integrated 10.25V
smart boost convert
Signed-off-by: Nick Li <liweilei@awinic.com>
Signed-off-by: Bruce zhao <zhaolei@awinic.com>
Signed-off-by: Weidong Wang <wangweidong.a@awinic.com>
Link: https://lore.kernel.org/r/20230113055301.189541-5-wangweidong.a@awinic.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The Awinic AW88395 is an I2S/TDM input, high efficiency
digital Smart K audio amplifier with an integrated 10.25V
smart boost convert
Signed-off-by: Nick Li <liweilei@awinic.com>
Signed-off-by: Bruce zhao <zhaolei@awinic.com>
Signed-off-by: Ben Yi <yijiangtao@awinic.com>
Signed-off-by: Weidong Wang <wangweidong.a@awinic.com>
Link: https://lore.kernel.org/r/20230113055301.189541-4-wangweidong.a@awinic.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The Awinic AW88395 is an I2S/TDM input, high efficiency
digital Smart K audio amplifier with an integrated 10.25V
smart boost convert
Signed-off-by: Nick Li <liweilei@awinic.com>
Signed-off-by: Bruce zhao <zhaolei@awinic.com>
Signed-off-by: Weidong Wang <wangweidong.a@awinic.com>
Link: https://lore.kernel.org/r/20230113055301.189541-3-wangweidong.a@awinic.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The Awinic AW88395 is an I2S/TDM input, high efficiency
digital Smart K audio amplifier with an integrated 10.25V
smart boost convert
Signed-off-by: Nick Li <liweilei@awinic.com>
Signed-off-by: Bruce zhao <zhaolei@awinic.com>
Signed-off-by: Weidong Wang <wangweidong.a@awinic.com>
Link: https://lore.kernel.org/r/20230113055301.189541-2-wangweidong.a@awinic.com
Signed-off-by: Mark Brown <broonie@kernel.org>
CXL r3.0 section 8.2.9.4.2 "Set Timestamp" recommends that the host sets
the timestamp after every Conventional or CXL Reset to ensure accurate
timestamps. This should include on initial boot up. The time base that
is being set is used by a device for the poison list overflow timestamp
and all event timestamps. Note that the command is optional and if
not supported and the device cannot return accurate timestamps it will
fill the fields in with an appropriate marker (see the specification
description of each timestamp).
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20230130151327.32415-1-Jonathan.Cameron@huawei.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Kernel-doc should be complete, so add documentation for the status
parameter.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Link: https://lore.kernel.org/r/20230130153437.3153-1-Jonathan.Cameron@huawei.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Commit e33c267ab7 ("mm: shrinkers: provide shrinkers with names")
chose some fairly bad names for DM's shrinkers.
Fixes: e33c267ab7 ("mm: shrinkers: provide shrinkers with names")
Signed-off-by : Mike Snitzer <snitzer@kernel.org>
Improve the target side flow to reduce downtime as of below.
- Support reading an optional record which includes the expected
stop_copy size.
- Once the source sends this record data, which expects to be sent as
part of the pre_copy flow, prepare the data buffers that may be large
enough to hold the final stop_copy data.
The above reduces the migration downtime as the relevant stuff that is
needed to load the image data is prepared ahead as part of pre_copy.
Signed-off-by: Yishai Hadas <yishaih@nvidia.com>
Link: https://lore.kernel.org/r/20230124144955.139901-4-yishaih@nvidia.com
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Improve the source side flow upon pre_copy as of below.
- Prepare the stop_copy buffers as part of moving to pre_copy.
- Send to the target a record that includes the expected
stop_copy size to let it optimize its stop_copy flow as well.
As for sending the target this new record type (i.e.
MLX5_MIGF_HEADER_TAG_STOP_COPY_SIZE) we split the current 64 header
flags bits into 32 flags bits and another 32 tag bits, each record may
have a tag and a flag whether it's optional or mandatory. Optional
records will be ignored in the target.
The above reduces the downtime upon stop_copy as the relevant data stuff
is prepared ahead as part of pre_copy.
Signed-off-by: Yishai Hadas <yishaih@nvidia.com>
Link: https://lore.kernel.org/r/20230124144955.139901-3-yishaih@nvidia.com
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Add a check whether VF is migratable. Only if VF is migratable, mark the
VFIO device as migration capable.
Signed-off-by: Shay Drory <shayd@nvidia.com>
Signed-off-by: Yishai Hadas <yishaih@nvidia.com>
Link: https://lore.kernel.org/r/20230124144955.139901-2-yishaih@nvidia.com
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Change the prompt about SAMPLE_VFIO_MDEV_MBOCHS as
'Build VFIO mbochs example mediated device sample code'.
Signed-off-by: ye xingchen <ye.xingchen@zte.com.cn>
Link: https://lore.kernel.org/r/202301301013518438986@zte.com.cn
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Follow the advice of the Documentation/filesystems/sysfs.rst and show()
should only use sysfs_emit() or sysfs_emit_at() when formatting the
value to be returned to user space.
Signed-off-by: Bo Liu <liubo03@inspur.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Link: https://lore.kernel.org/r/20230129084117.2384-1-liubo03@inspur.com
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
The Renesas IDT821034 codec is four channel PCM codec with on-chip
filters and programmable gain setting.
It also provides SLIC (Subscriber Line Interface Circuit) signals as
GPIOs.
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Link: https://lore.kernel.org/r/20230126085137.375814-3-herve.codina@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The Renesas IDT821034 codec is a quad PCM codec with programmable
gain.
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230126085137.375814-2-herve.codina@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add runtime PM support for Microchip SPDIFRX driver. On runtime suspend
the clocks are disabled and regmap is set in caching mode. On runtime
resume the clocks are enabled and regmap is synced with the device.
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Link: https://lore.kernel.org/r/20230130120647.638049-8-claudiu.beznea@microchip.com
Signed-off-by: Mark Brown <broonie@kernel.org>
CSC interrupts which might be used in controls are on bits 8 and 9 of
SPDIFRX_IDR register. Thus disable all the interrupts that are exported
by driver.
Fixes: ef265c55c1 ("ASoC: mchp-spdifrx: add driver for SPDIF RX")
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Link: https://lore.kernel.org/r/20230130120647.638049-5-claudiu.beznea@microchip.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Channel status get and channel subcode get controls relies on data
returned by controls when certain IRQs are raised. To achieve that
completions are used b/w controls and interrupt service routine. The
concurrent accesses to these controls are protected by
struct snd_card::controls_rwsem.
Issues identified:
- reinit_completion() may be called while waiting for completion
which should be avoided
- in case of multiple threads waiting, the complete() call in interrupt
will signal only one waiting thread per interrupt which may lead to
timeout for the others
- in case of channel status get as the CSC interrupt is not refcounted
ISR may disable interrupt for threads that were just enabled it.
To solve these the access to controls were protected by a mutex. Along
with this there is no need for spinlock to protect the software cache
reads/updates b/w controls and ISR as the update is happening only when
requested from control, and only one reader can reach the control.
Fixes: ef265c55c1 ("ASoC: mchp-spdifrx: add driver for SPDIF RX")
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Link: https://lore.kernel.org/r/20230130120647.638049-4-claudiu.beznea@microchip.com
Signed-off-by: Mark Brown <broonie@kernel.org>
wait_for_completion_interruptible_timeout() returns 0 in case of
timeout. Check this into account when returning from function.
Fixes: ef265c55c1 ("ASoC: mchp-spdifrx: add driver for SPDIF RX")
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Link: https://lore.kernel.org/r/20230130120647.638049-3-claudiu.beznea@microchip.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The SPDIFRX block is clocked by 2 clocks: peripheral and generic clocks.
Peripheral clock feeds user interface (registers) and generic clock feeds
the receiver.
To enable the receiver the generic clock needs to be enabled and also the
ENABLE bit of MCHP_SPDIFRX_MR register need to be set.
The signal control exported by mchp-spdifrx driver reports wrong status
when the receiver is disabled. This can happen when requesting the signal
and the capture was not previously started. To solve this the receiver
needs to be enabled (by enabling generic clock and setting ENABLE bit of
MR register) before reading the signal status.
As with this fix there are 2 paths now that need to control the generic
clock and ENABLE bit of SPDIFRX_MR register (one path though controls, one
path though configuration) a mutex has been introduced. We can't rely on
subsystem locking as the controls are protected by
struct snd_card::controls_rwsem semaphore and configuration is protected
by a different lock (embedded in snd_pcm_stream_lock_irq()).
The introduction of mutex is also extended to other controls which rely on
SPDIFRX_RSR.ULOCK bit as it has been discovered experimentally that having
both clocks enabled but not the receiver (through ENABLE bit of SPDIFRX.MR)
leads to inconsistent values of SPDIFRX_RSR.ULOCK. Thus on some controls we
rely on software state (dev->trigger_enabled protected by mutex) to
retrieve proper values.
Fixes: ef265c55c1 ("ASoC: mchp-spdifrx: add driver for SPDIF RX")
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Link: https://lore.kernel.org/r/20230130120647.638049-2-claudiu.beznea@microchip.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Correct spelling problems for Documentation/power/ as reported
by codespell.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
All production DG1 hardware has graphics stepping B0; there is no such
thing as C0. As such, we can simplify
IS_DG1_GRAPHICS_STEP(uncore->i915, STEP_A0, STEP_C0)
to just match DG1 in general.
Bspec: 44463
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230127224313.4042331-4-matthew.d.roper@intel.com
Several post-DG1 platforms have been brought up now, so we're well past
the point where we usually drop the workarounds that are only applicable
to internal/pre-production hardware.
Production DG1 hardware always has a B0 stepping for both display and
GT.
Bspec: 44463
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230127224313.4042331-3-matthew.d.roper@intel.com
Several post-TGL platforms have been brought up now, so we're well past
the point where we usually drop the workarounds that are only applicable
to internal/pre-production hardware.
Production TGL hardware always has display stepping C0 or later and GT
stepping B0 or later (this is true for both the original TGL and the U/Y
subplatform).
Bspec 44455
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230127224313.4042331-2-matthew.d.roper@intel.com
Jason Gunthorpe says:
====================
iommufd follows the same design as KVM and uses memory cgroups to limit
the amount of kernel memory a iommufd file descriptor can pin down. The
various internal data structures already use GFP_KERNEL_ACCOUNT to charge
its own memory.
However, one of the biggest consumers of kernel memory is the IOPTEs
stored under the iommu_domain and these allocations are not tracked.
This series is the first step in fixing it.
The iommu driver contract already includes a 'gfp' argument to the
map_pages op, allowing iommufd to specify GFP_KERNEL_ACCOUNT and then
having the driver allocate the IOPTE tables with that flag will capture a
significant amount of the allocations.
Update the iommu_map() API to pass in the GFP argument, and fix all call
sites. Replace iommu_map_atomic().
Audit the "enterprise" iommu drivers to make sure they do the right thing.
Intel and S390 ignore the GFP argument and always use GFP_ATOMIC. This is
problematic for iommufd anyhow, so fix it. AMD and ARM SMMUv2/3 are
already correct.
A follow up series will be needed to capture the allocations made when the
iommu_domain itself is allocated, which will complete the job.
====================
* 'iommu-memory-accounting' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/joro/iommu:
iommu/s390: Use GFP_KERNEL in sleepable contexts
iommu/s390: Push the gfp parameter to the kmem_cache_alloc()'s
iommu/intel: Use GFP_KERNEL in sleepable contexts
iommu/intel: Support the gfp argument to the map_pages op
iommu/intel: Add a gfp parameter to alloc_pgtable_page()
iommufd: Use GFP_KERNEL_ACCOUNT for iommu_map()
iommu/dma: Use the gfp parameter in __iommu_dma_alloc_noncontiguous()
iommu: Add a gfp parameter to iommu_map_sg()
iommu: Remove iommu_map_atomic()
iommu: Add a gfp parameter to iommu_map()
Link: https://lore.kernel.org/linux-iommu/0-v3-76b587fe28df+6e3-iommu_map_gfp_jgg@nvidia.com
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
OpenCSD version 1.4 is released with support for FEAT_ITE.
This adds a new packet type, with associated output element ID in the
packet type enum - OCSD_GEN_TRC_ELEM_INSTRUMENTATION.
As we just ignore this packet in perf, add to the switch statement to
avoid the "enum not handled in switch error", but conditionally so as
not to break the perf build for older OpenCSD installations.
Reviewed-by: James Clark <james.clark@arm.com>
Signed-off-by: Mike Leach <mike.leach@linaro.org>
Acked-by: Ian Rogers <irogers@google.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Leo Yan <leo.yan@linaro.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Suzuki Poulouse <suzuki.poulose@arm.com>
Cc: coresight@lists.linaro.org
Cc: linux-arm-kernel@lists.infradead.org
Link: https://lore.kernel.org/r/20230120153706.20388-1-mike.leach@linaro.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
'DWARF unwind' 'perf test' can sometimes fail:
$ perf test -v 74
Couldn't bump rlimit(MEMLOCK), failures may take place when creating BPF maps, etc
74: Test dwarf unwind :
--- start ---
test child forked, pid 3785254
Problems creating module maps, continuing anyway...
Problems creating module maps, continuing anyway...
unwind: test__arch_unwind_sample:ip = 0x102d0ad4c (0x36ad4c)
unwind: access_mem addr 0x7fffc33128c8, val 1031c3228, offset 120
unwind: access_mem addr 0x7fffc33128d0, val 12427cc70, offset 128
<snip>
unwind: test_dwarf_unwind__krava_3:ip = 0x102b8768b (0x1e768b)
unwind: access_mem addr 0x7fffc3313048, val 7fffc3313050, offset 2040
unwind: access_mem addr 0x7fffc3313060, val 102b8777c, offset 2064
unwind: test_dwarf_unwind__krava_2:ip = 0x102b8770b (0x1e770b)
unwind: access_mem addr 0x7fffc3313088, val 7fffc3313090, offset 2104
unwind: access_mem addr 0x7fffc33130a0, val 102b87890, offset 2128
unwind: test_dwarf_unwind__krava_1:ip = 0x102b8777b (0x1e777b)
unwind: access_mem addr 0x7fffc3313108, val 10323a274, offset 2232
unwind: access_mem addr 0x7fffc3313110, val ffffffffffffffff, offset 2240
unwind: access_mem addr 0x7fffc3313118, val 102c08ed0, offset 2248
unwind: access_mem addr 0x7fffc3313120, val 1031db000, offset 2256
unwind: access_mem addr 0x7fffc3313128, val 7fffc3313130, offset 2264
unwind: access_mem addr 0x7fffc3313140, val 102b45ee8, offset 2288
unwind: '':ip = 0x102b8788f (0x1e788f)
failed: got unresolved address 0x102b8788f
unwind: failed with 'no error'
got wrong number of stack entries 0 != 8
test child finished with -1
---- end ----
Test dwarf unwind: FAILED!
We expect to resolve test__dwarf_unwind as the last symbol, but that
function can be optimized away:
$ objdump -tT /usr/bin/perf | grep dwarf_unwind
000000000083b018 g DO .data 0000000000000040 Base tests__dwarf_unwind
00000000001e7750 g DF .text 0000000000000068 Base 0x60 test_dwarf_unwind__krava_1
00000000001e76e0 g DF .text 0000000000000068 Base 0x60 test_dwarf_unwind__krava_2
00000000001e7620 g DF .text 00000000000000b4 Base 0x60 test_dwarf_unwind__krava_3
00000000001e74f0 g DF .text 0000000000000128 Base 0x60 test_dwarf_unwind__compare
00000000001e7350 g DF .text 000000000000019c Base 0x60 test_dwarf_unwind__thread
000000000083b000 g DO .data 0000000000000018 Base suite__dwarf_unwind
Fix this similar to commit fdf7c49c20 ("perf tests: Fix dwarf
unwind for stripped binaries") by marking the function as a global and
adding the 'noinline' attribute to it.
With this patch:
$ objdump -tT perf | grep dwarf_unwind
000000000083b018 g DO .data 0000000000000040 Base tests__dwarf_unwind
00000000001e80f0 g DF .text 0000000000000068 Base 0x60 test_dwarf_unwind__krava_1
00000000001e8080 g DF .text 0000000000000068 Base 0x60 test_dwarf_unwind__krava_2
00000000001e7fc0 g DF .text 00000000000000b4 Base 0x60 test_dwarf_unwind__krava_3
00000000001e7e90 g DF .text 0000000000000128 Base 0x60 test_dwarf_unwind__compare
00000000001e7cf0 g DF .text 000000000000019c Base 0x60 test_dwarf_unwind__thread
00000000001e8160 g DF .text 0000000000000248 Base 0x60 test__dwarf_unwind
000000000083b000 g DO .data 0000000000000018 Base suite__dwarf_unwind
$ ./perf test 74
74: Test dwarf unwind : Ok
Reported-by: Disha Goel <disgoel@linux.vnet.ibm.com>
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Link: http://lore.kernel.org/lkml/20230125123442.107156-1-naveen.n.rao@linux.vnet.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
pci_enable_pcie_error_reporting() enables the device to send ERR_*
Messages. Since f26e58bf6f ("PCI/AER: Enable error reporting when AER is
native"), the PCI core does this for all devices during enumeration.
Remove the redundant pci_enable_pcie_error_reporting() call from the
driver. Also remove the corresponding pci_disable_pcie_error_reporting()
from the driver .remove() path.
Note that this doesn't control interrupt generation by the Root Port; that
is controlled by the AER Root Error Command register, which is managed by
the AER service driver.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
Cc: Tony Nguyen <anthony.l.nguyen@intel.com>
Cc: intel-wired-lan@lists.osuosl.org
Cc: netdev@vger.kernel.org
Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
pci_enable_pcie_error_reporting() enables the device to send ERR_*
Messages. Since f26e58bf6f ("PCI/AER: Enable error reporting when AER is
native"), the PCI core does this for all devices during enumeration.
Remove the redundant pci_enable_pcie_error_reporting() call from the
driver. Also remove the corresponding pci_disable_pcie_error_reporting()
from the driver .remove() path.
Note that this doesn't control interrupt generation by the Root Port; that
is controlled by the AER Root Error Command register, which is managed by
the AER service driver.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
Cc: Tony Nguyen <anthony.l.nguyen@intel.com>
Cc: intel-wired-lan@lists.osuosl.org
Cc: netdev@vger.kernel.org
Tested-by: Naama Meir <naamax.meir@linux.intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>