Smatch complains that the call to snd_soc_component_get_drvdata(component)
will dereference "component" so this NULL check is too late. The probe()
function will never be called with a NULL component pointer so just
delete the check.
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Link: https://patch.msgid.link/aScUKqCEhSIZoOmg@stanley.mountain
Signed-off-by: Mark Brown <broonie@kernel.org>
Now that cs_dsp uses regmap_raw_write() instead of regmap_raw_write_async()
it doesn't need to keep multiple DMA-safe buffers of every chunk of data
it wrote.
See commit fe08b7d508 ("firmware: cs_dsp: Remove async regmap writes")
Only one write can be in progress at a time, so one DMA-safe buffer can be
re-used. The single DMA-safe buffer is reallocated if the next write chunk
is larger. Reallocation size is rounded up to reduce the amount of churn.
PAGE_SIZE is used as a convenient size multiple. Typically for .wmfw files
the first chunk is the largest.
A DMA-safe intermediate buffer is used because we can't assume that the
bus underlying regmap can accept non-DMA-safe buffers.
Note that a chunk from the firmware file cannot simply be split into
arbitrarily-sized chunks to avoid buffer reallocation. The data in the
firmware file is preformatted to be written directly to the device as one
block. It already takes account of alignment, write-bursts and write
length requirements of the target hardware, so that the cs_dsp driver can
treat it as an opaque blob.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20251126131501.884188-1-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The power requirements for the CDSP instances on SC8280XP aren't fully
described, with only one of the three present. Fix that.
Fixes: ee651cd1e9 ("dt-bindings: remoteproc: qcom: pas: Add sc8280xp adsp and nsp pair")
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20251104-topic-8280_mxc-v1-2-df545af0ef94@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
pm_runtime_put_autosuspend(), pm_runtime_put_sync_autosuspend(),
pm_runtime_autosuspend() and pm_request_autosuspend() now include a call
to pm_runtime_mark_last_busy(). Remove the now-reduntant explicit call to
pm_runtime_mark_last_busy().
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Link: https://lore.kernel.org/r/20250704075445.3221481-1-sakari.ailus@linux.intel.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
If the board supports IP discovery, we don't need to
parse the gpu info firmware.
Backport to 6.18.
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4721
Fixes: fa819e3a7c ("drm/amdgpu: add support for cyan skillfish gpu_info")
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 5427e32fa3)
Ensure the userq TLB flush is emitted only after
the VM update finishes and the PT BOs have been
annotated with bookkeeping fences.
Suggested-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Prike Liang <Prike.Liang@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit f3854e04b7)
Cc: stable@vger.kernel.org
[WHY]
When monitor is still booting EDID read can fail while DPCD read
is successful. In this case no EDID data will be returned, and this
could happen for a while.
[HOW]
Increase number of attempts to read EDID in dm_helpers_read_local_edid()
to 25.
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4672
Cc: Mario Limonciello <mario.limonciello@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
Signed-off-by: Alex Hung <alex.hung@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit a76d6f2c76)
Cc: stable@vger.kernel.org
[WHY]
When a laptop lid is closed the connector is disabled but userspace
can still try to change brightness. This doesn't work because the
panel is turned off. It will eventually time out, but there is a lot
of stutter along the way.
[How]
Iterate all connectors to check whether the matching one for the backlight
index is enabled.
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4675
Cc: Mario Limonciello <mario.limonciello@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Ray Wu <ray.wu@amd.com>
Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
Signed-off-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit f6eeab3032)
Cc: stable@vger.kernel.org
Use scnprintf() instead of sprintf() for those cases where the
destination is an array and the size of the array is known at compile
time.
This prevents theoretical buffer overflows, but also avoids that people
again and again spend time to figure out if the code is actually safe.
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
The device name formatting can be generalized and made more readable
compared to the current state. SCSI already provides a generalized way
to format many devices in the same naming scheme as DASD does, which was
introduced with commit 3e1a7ff8a0 ("block: allow disk to have extended
device number").
Use this much cleaner code from drivers/scsi/sd.c to handle the legacy
naming scheme in DASD as a replacement for the current implementation.
For easier error handling for the new function, move the gendisk free
portion of dasd_gendisk_free() out into a new function dasd_gd_free().
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
The DASD driver only uses the dentry pointers when removing debugfs
entries, and debugfs_remove() can safely handle both NULL and ERR_PTR.
There is therefore no need to check debugfs_create() return values.
This simplifies the debugfs setup code without changing functionality.
Suggested-by: Heiko Carstens <hca@linux.ibm.com>
Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com>
Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
After a copy pair swap the block device's "device" symlink points to
the secondary CCW device, but the gendisk's parent remained the
primary, leaving /sys/block/<dasdx> under the wrong parent.
Move the gendisk to the secondary's device with device_move(), keeping
the sysfs topology consistent after the swap.
Fixes: 413862caad ("s390/dasd: add copy pair swap capability")
Cc: stable@vger.kernel.org #6.1
Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com>
Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
On all AMD AM4 systems I have seen, e.g ASUS X470-i, Pro WS X570 Ace
and equivalent Gigabyte, amd-pstate does not initialize when the
x2apic is enabled in the BIOS. Kernel debug messages include:
[ 0.315438] acpi LNXCPU:00: Failed to get CPU physical ID.
[ 0.354756] ACPI CPPC: No CPC descriptor for CPU:0
[ 0.714951] amd_pstate: the _CPC object is not present in SBIOS or ACPI disabled
I tracked this down to map_x2apic_id() checking device_declaration
passed in via the type argument of acpi_get_phys_id() via
map_madt_entry() while map_lapic_id() does not.
It appears these BIOSes use Processor statements for declaring the CPUs
in the ACPI namespace instead of processor device objects (which should
have been used). CPU declarations via Processor statements were
deprecated in ACPI 6.0 that was released 10 years ago. They should not
be used any more in any contemporary platform firmware.
I tried to contact Asus support multiple times, but never received a
reply nor did any BIOS update ever change this.
Fix amd-pstate w/ x2apic on am4 by allowing map_x2apic_id() to work with
CPUs declared via Processor statements for IDs less than 255, which is
consistent with ACPI 5.0 that still allowed Processor statements to be
used for declaring CPUs.
Fixes: 7237d3de78 ("x86, ACPI: add support for x2apic ACPI extensions")
Signed-off-by: René Rebe <rene@exactco.de>
[ rjw: Changelog edits ]
Link: https://patch.msgid.link/20251126.165513.1373131139292726554.rene@exactco.de
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
In w83781d_isa_found() there is REALLY_SLOW_IO defined around some port
accesses, probably in order to wait between multiple accesses.
Unfortunately this isn't making any difference compared to not having
this define since more than a decade, as REALLY_SLOW_IO needs to be
defined while "#include <asm/io.h>" is called to have an effect.
As there seem not to be any outstanding issues in spite of this having
no effect, just drop the "#define" and add a remark to the related
comment.
Signed-off-by: Juergen Gross <jgross@suse.com>
Link: https://lore.kernel.org/r/20251126162018.5676-4-jgross@suse.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
In lm78_isa_found() there is REALLY_SLOW_IO defined around some port
accesses, probably in order to wait between multiple accesses.
Unfortunately this isn't making any difference compared to not having
this define since more than a decade, as REALLY_SLOW_IO needs to be
defined while "#include <asm/io.h>" is called to have an effect.
As there seem not to be any outstanding issues in spite of this having
no effect, just drop the "#define" and add a remark to the related
comment.
Signed-off-by: Juergen Gross <jgross@suse.com>
Link: https://lore.kernel.org/r/20251126162018.5676-3-jgross@suse.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
In sy7636a_sensor_probe(), regulator_enable() is called but if
devm_hwmon_device_register_with_info() fails, the function returns
without calling regulator_disable(), leaving the regulator enabled
and leaking the reference count.
Switch to devm_regulator_get_enable() to automatically
manage the regulator resource.
Fixes: de34a40532 ("hwmon: sy7636a: Add temperature driver for sy7636a")
Suggested-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Haotian Zhang <vulab@iscas.ac.cn>
Link: https://lore.kernel.org/r/20251126162602.2086-1-vulab@iscas.ac.cn
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The "cmd->in_offset" variable comes from the user via the __nd_ioctl()
function. The problem is that the "cmd->in_offset + cmd->in_length"
addition could have an integer wrapping issue if cmd->in_offset is close
to UINT_MAX . Both "cmd->in_offset" and "cmd->in_length" are u32
variables.
Fixes: 43bc0aa19a ("nvdimm: allow exposing RAM carveouts as NVDIMM DIMM devices")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Link: https://patch.msgid.link/aSbuiYCznEIZDa02@stanley.mountain
Signed-off-by: Ira Weiny <ira.weiny@intel.com>
If the board supports IP discovery, we don't need to
parse the gpu info firmware.
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4721
Fixes: fa819e3a7c ("drm/amdgpu: add support for cyan skillfish gpu_info")
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The CPER ring debugfs read code always writes a 12-byte header when the
file is read for the first time (*offset == 0):
copy_to_user(buf, ring_header, 12);
But the code never checks whether the user buffer (@size) is at least
12 bytes long. After writing the 12-byte header, the code then gives the
full original @size to the CPER payload handler:
record_req->buf_size = size;
This means the function can write:
12 bytes (header) + payload bytes (up to @size)
into a buffer that is only @size bytes big. In other words, the kernel
may write more data than the user asked for. This can overflow the user
buffer.
The fix is:
- If the user buffer is smaller than 12 bytes on the first read,
return -EINVAL instead of copying the header.
- After writing the 12-byte header, subtract 12 from @size and pass
the reduced size to record_req->buf_size. This ensures the CPER
payload only uses the remaining free space in the buffer.
Reads after the first one (*offset != 0) do not write the header, so
their behavior stays exactly the same. The only user-visible change is
that tiny buffers now fail safely instead of risking an overflow.
Fixes:
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:523
amdgpu_ras_cper_debugfs_read()
warn: userbuf overflow? is 'ring_header_size' <= 'size'
Fixes: 527e3d4033 ("drm/amd/ras: Add CPER ring read for uniras")
Reported by: Dan Carpenter <dan.carpenter@linaro.org>
Cc: Xiang Liu <xiang.liu@amd.com>
Cc: Tao Zhou <tao.zhou1@amd.com>
Cc: Yang Wang <kevinyang.wang@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
Reviewed-by: Tao Zhou <tao.zhou1@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Ensure the userq TLB flush is emitted only after
the VM update finishes and the PT BOs have been
annotated with bookkeeping fences.
Suggested-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Prike Liang <Prike.Liang@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
io_handle_query_entry() doesn't use its struct io_ring_ctx *ctx
argument. So remove it from the function and its callers.
Signed-off-by: Caleb Sander Mateos <csander@purestorage.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
XCD id is assigned to uuid, which causes some performance
drop in SPX mode, assigning AID back will resolve the
issue.
Fixes: 3a75edf93a ("drm/amdkfd: set uuid for each partition in topology")
Signed-off-by: Eric Huang <jinhuieric.huang@amd.com>
Reviewed-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[WHY & HOW]
Fix the typo of the else-if condition from ATOM_DEVICE_CRT1_SUPPORT to
ATOM_DEVICE_CRT2_SUPPORT.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Ivan Lipski <ivan.lipski@amd.com>
Signed-off-by: Alex Hung <alex.hung@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The KMSG_COMPONENT macro is a leftover of the s390 specific "kernel message
catalog" from 2008 [1] which never made it upstream.
The macro was added to s390 code to allow for an out-of-tree patch which
used this to generate unique message ids. Also this out-of-tree doesn't
exist anymore.
Remove the macro in order to get rid of a pointless indirection.
[1] https://lwn.net/Articles/292650/
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
[HOW]
If cursor attributes or position are passed into DC via a stream update
and we take the newer HWSS paths then it's possible that the update
races with cursor offloading if it's enabled.
This can cause the cursor to remain on the screen if no further updates
come in if it results in HW cursor support being disabled.
[HOW]
Add the abort into the HWSS path so that cursor offloading doesn't
attempt to reprogram the cursor with outdated params.
Cc: Mario Limonciello <mario.limonciello@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Dillon Varone <dillon.varone@amd.com>
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Alex Hung <alex.hung@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[WHY]
When monitor is still booting EDID read can fail while DPCD read
is successful. In this case no EDID data will be returned, and this
could happen for a while.
[HOW]
Increase number of attempts to read EDID in dm_helpers_read_local_edid()
to 25.
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4672
Cc: Mario Limonciello <mario.limonciello@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
Signed-off-by: Alex Hung <alex.hung@amd.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The function dereferences amdgpu_dm_connector->dc_link early to
initialize verified_link_cap and dc, but later still checks
amdgpu_dm_connector->dc_link for NULL in the analog path.
This late NULL check is redundant, introduce a local dc_link pointer,
use it consistently, and drop the superfluous NULL check while using
dc_link->link_id.id instead.
The function uses dc_link at the very beginning without checking if it
is NULL. But later in the code, it suddenly checks if dc_link is NULL.
This check is too late to be useful, because the code has already used
dc_link earlier. So this NULL check does nothing.
We simplify the code by storing amdgpu_dm_connector->dc_link in a local
dc_link variable and using it throughout the function. Since dc_link is
already dereferenced early, the later NULL check is unnecessary and is
removed.
Fixes the below:
amdgpu_dm_connector_get_modes():
variable dereferenced before check 'amdgpu_dm_connector->dc_link'
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c
8845 &amdgpu_dm_connector->dc_link->verified_link_cap;
8846 const struct dc *dc = amdgpu_dm_connector->dc_link->dc;
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Dereference
...
8856
8857 if (amdgpu_dm_connector->dc_sink &&
8858 amdgpu_dm_connector->dc_link &&
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Checked too late.
Presumably this NULL check could be removed?
...
Fixes: d46e422f65 ("drm/amd/display: Cleanup uses of the analog flag")
Reported by: Dan Carpenter <dan.carpenter@linaro.org>
Cc: Timur Kristóf <timur.kristof@gmail.com>
Cc: Aurabindo Pillai <aurabindo.pillai@amd.com>
Cc: Roman Li <roman.li@amd.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Tom Chung <chiahsuan.chung@amd.com>
Cc: Alex Hung <alex.hung@amd.com>
Cc: Ivan Lipski <ivan.lipski@amd.com>
Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[WHY]
When a laptop lid is closed the connector is disabled but userspace
can still try to change brightness. This doesn't work because the
panel is turned off. It will eventually time out, but there is a lot
of stutter along the way.
[How]
Iterate all connectors to check whether the matching one for the backlight
index is enabled.
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4675
Cc: Mario Limonciello <mario.limonciello@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Ray Wu <ray.wu@amd.com>
Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
Signed-off-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The .H_SYNC_POLARITY and .V_SYNC_POLARITY variables are 1 bit bitfields
of a u32. The ATOM_HSYNC_POLARITY define is 0x2 and the
ATOM_VSYNC_POLARITY is 0x4. When we do a bitwise negate of 0, 2, or 4
then the last bit is always 1 so this code always sets .H_SYNC_POLARITY
and .V_SYNC_POLARITY to true.
This code is instead intended to check if the ATOM_HSYNC_POLARITY or
ATOM_VSYNC_POLARITY flags are set and reverse the result. In other
words, it's supposed to be a logical negate instead of a bitwise negate.
Fixes: ae79c310b1 ("drm/amd/display: Add DCE12 bios parser support")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Use the newly added of_reserved_mem_region_to_resource() and
of_reserved_mem_region_count() functions to handle "memory-region"
properties.
The error handling is a bit different in some cases. Often
"memory-region" is optional, so failed lookup is not an error. But then
an error in of_reserved_mem_lookup() is treated as an error. However,
that distinction is not really important. Either the region is available
and usable or it is not. So now, it is just
of_reserved_mem_region_to_resource() which is checked for an error.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20251124182751.507624-2-robh@kernel.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Otherwise we're leaking memory.
Fixes: db36632ea5 ("drm/amdgpu: clean up and unify hw fence handling")
Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
We want to change ::new() to take no parameters and produce a pool that
is as large as possible while also being inline because that is the
constructor that Rust Binder actually needs.
However, to avoid complications in examples, we still need the current
constructor. So rename it to with_capacity(), which is the idiomatic
Rust name for this kind constructor.
Reviewed-by: Burak Emir <bqe@google.com>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
This constructor is useful when you just want to create a BitmapVec
without allocating but don't care how large it is.
Acked-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
Reviewed-by: Burak Emir <bqe@google.com>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
To avoid hard-coding these values in drivers, define constants for them
that drivers can reference. Also, update all instances in bitmap.rs and
id_pool.rs that use these values to use the new constants.
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Burak Emir <bqe@google.com>
Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
If memory is freed we need to nullify the pointer or the caller
might call kfree again (eg: amdgpu_cs_parser_fini calls kfree on
all non-null job pointers).
Fixes: db36632ea5 ("drm/amdgpu: clean up and unify hw fence handling")
Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The scroll resolution multipliers are set in the context of
hidinput_connect(), which is only called at probe time: when the host
changes the value on the device with a SET_REPORT(FEATURE), and the device
accepts it, these multipliers are stored on the host side, and used to
calculate the final scroll event values sent to userspace.
After a USB suspend, the resume operation on many hubs and chipsets
involve a USB reset signal as well. A reset on the device side clears all
previous state information, including the value of the multiplier report.
This reset is not handled by the multiplier handling logic, so what ends up
happening is the host is still expecting high-resolution scroll events,
but the device is reset to default resolution, making the effective,
user-perceived scroll speed incredibly slow.
The solution is to renegotiate the multiplier selection after each reset.
This is not the only bug related to the high-resolution scrolling
implementation in the kernel (the other one is
https://bugzilla.kernel.org/show_bug.cgi?id=220144), but for this one,
there is no device side workaround for, leading to poor user experience with our product:
https://github.com/UltimateHackingKeyboard/firmware/issues/1155https://github.com/UltimateHackingKeyboard/firmware/issues/1261https://github.com/UltimateHackingKeyboard/firmware/pull/1355
This patch was tested by an affected user and has been reported to
fix the issue (see discussion in 1355).
Signed-off-by: Benedek Kupper <kupper.benedek@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
The mouse portion of the device's Report Descriptor declares 5 buttons but only
declares 3 usages (Button 1 through Button 3). As a result events for the 2
side buttons are not generated.
Detect and repair the Report Descriptor if necessary by changing the Usage
Maximum value from Button 3 to Button 5.
[jkosina@suse.com: standardize changelog a little bit]
Reported-by: Artem <temabiill@gmail.com>
Closes: https://lore.kernel.org/all/CADYkRmrfhRf6VmQjc+su+mepyv=TsHc+aMcL6ryRZ5HTZ8pyFg@mail.gmail.com/
Signed-off-by: Terry Junge <linuxhid@cosmicgizmosystems.com>
Tested-by: Artem <temabiill@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
While testing rpmsg-char interface it was noticed that duplicate sysfs
entries are getting created and below warning is noticed.
Reason for this is that we are leaking rpmsg device pointer, setting it
null without actually unregistering device.
Any further attempts to unregister fail because rpdev is NULL,
resulting in a leak.
Fix this by unregistering rpmsg device before removing its reference
from rpmsg channel.
sysfs: cannot create duplicate filename '/devices/platform/soc@0/3700000.remot
eproc/remoteproc/remoteproc1/3700000.remoteproc:glink-edge/3700000.remoteproc:
glink-edge.adsp_apps.-1.-1'
[ 114.115347] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:0 Not
tainted 6.16.0-rc4 #7 PREEMPT
[ 114.115355] Hardware name: Qualcomm Technologies, Inc. Robotics RB3gen2 (DT)
[ 114.115358] Workqueue: events qcom_glink_work
[ 114.115371] Call trace:8
[ 114.115374] show_stack+0x18/0x24 (C)
[ 114.115382] dump_stack_lvl+0x60/0x80
[ 114.115388] dump_stack+0x18/0x24
[ 114.115393] sysfs_warn_dup+0x64/0x80
[ 114.115402] sysfs_create_dir_ns+0xf4/0x120
[ 114.115409] kobject_add_internal+0x98/0x260
[ 114.115416] kobject_add+0x9c/0x108
[ 114.115421] device_add+0xc4/0x7a0
[ 114.115429] rpmsg_register_device+0x5c/0xb0
[ 114.115434] qcom_glink_work+0x4bc/0x820
[ 114.115438] process_one_work+0x148/0x284
[ 114.115446] worker_thread+0x2c4/0x3e0
[ 114.115452] kthread+0x12c/0x204
[ 114.115457] ret_from_fork+0x10/0x20
[ 114.115464] kobject: kobject_add_internal failed for 3700000.remoteproc:
glink-edge.adsp_apps.-1.-1 with -EEXIST, don't try to register things with
the same name in the same directory.
[ 114.250045] rpmsg 3700000.remoteproc:glink-edge.adsp_apps.-1.-1:
device_add failed: -17
Fixes: 835764ddd9 ("rpmsg: glink: Move the common glink protocol implementation to glink_native.c")
Cc: Stable@vger.kernel.org
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250822100043.2604794-2-srinivas.kandagatla@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
MSM8974 requires the CX power domain, so use the msm8996_adsp_resource
which has cx under proxy_pd_names and is otherwise equivalent.
Signed-off-by: Luca Weiss <luca@lucaweiss.eu>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250621-msm8974-rpmpd-switch-v1-2-0a2cb303c446@lucaweiss.eu
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Using CX as a regulator is an artifact of earlier times. Instead use CX
power rail as power domain from rpmpd.
Signed-off-by: Luca Weiss <luca@lucaweiss.eu>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250621-msm8974-rpmpd-switch-v1-1-0a2cb303c446@lucaweiss.eu
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Move Telit 0x10c7 composition right after 0x10c6 composition and
before 0x10c8 composition.
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <johan@kernel.org>
