| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
virtio_gpu_free_vbufs() destroys the vbufs kmem_cache after the virtqueues
have already been released. Commands that were queued but never completed
by the device leave their vbuffers stranded in the virtqueue, so the cache
still holds live objects when virtio_gpu_deinit() tears everything down.
This triggers a WARNING in virtio_gpu_free_vbufs:
BUG virtio-gpu-vbufs (Not tainted): Objects remaining in cache
on __kmem_cache_shutdown()
Drain any buffers still sitting in the control and cursor virtqueues in
virtio_gpu_deinit() after the device has been reset and before the
virtqueues are deleted, following the same pattern used by virtio_console's
remove_vqs(). Each reclaimed buffer is released with free_vbuf(), dropping
the reference on any GEM objects it holds. Pending RESOURCE_UNREF
commands are handled as well: their resp_cb_data still references a GEM
object, so it is cleaned up with virtio_gpu_cleanup_object() to avoid
leaking it on teardown.
Reported-by: syzbot+06f9b2a53ba4a5a47644@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=06f9b2a53ba4a5a47644
Signed-off-by: Anuj Bolewar <bolewara@gmail.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Link: https://patch.msgid.link/20260802-virtio-gpu-reclaim-vbufs-v2-1-5767fb860691@gmail.com
|
|
The return value of vgdev_output_init(), called by
virtio_gpu_modeset_init(), is not checked. As a result, modeset
initialization continues even if an output fails to initialize.
check the return value and return the error to the caller.
Signed-off-by: shechenglong <shechenglong@xfusion.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Link: https://patch.msgid.link/20260811015624.830-1-shechenglong@xfusion.com
|
|
fill_effect_buf() initializes value only for the four haptic usages
handled by its switch, but writes it to field->value[] for every usage.
An unhandled usage can therefore receive either an uninitialized value
or one left over from the previous usage. hid_output_report() then
serializes that value into the effect's report buffer.
Skip unhandled usages instead. This also matches switch_mode(), which
only updates fields it recognizes.
Found with Clang's -Wconditional-uninitialized.
Fixes: 344ff3584957 ("HID: haptic: initialize haptic device")
Assisted-by: Claude:claude-fable-5
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
quickspi_probe() calls pm_runtime_use_autosuspend(), but
quickspi_remove() does not call the matching
pm_runtime_dont_use_autosuspend() during teardown.
If the autosuspend delay is set to a negative value while autosuspend
is enabled, the runtime PM core increments usage_count to prevent
runtime suspend. Without calling pm_runtime_dont_use_autosuspend()
during teardown, this reference is not dropped.
The documentation for pm_runtime_use_autosuspend() also notes that it
is important to undo it with pm_runtime_dont_use_autosuspend() at
driver exit time, unless runtime PM was initially enabled with
devm_pm_runtime_enable().
Add the missing pm_runtime_dont_use_autosuspend() call to the driver
remove path.
This issue was found by manual code inspection.
Fixes: 6912aaf3fd24 ("HID: intel-thc-hid: intel-quickspi: Add PM implementation")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
Reviewed-by: Even Xu <even.xu@intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
quicki2c_probe() calls pm_runtime_use_autosuspend(), but
quicki2c_remove() does not call the matching
pm_runtime_dont_use_autosuspend() during teardown.
If the autosuspend delay is set to a negative value while autosuspend
is enabled, the runtime PM core increments usage_count to prevent
runtime suspend. Without calling pm_runtime_dont_use_autosuspend()
during teardown, this reference is not dropped.
The documentation for pm_runtime_use_autosuspend() also notes that it
is important to undo it with pm_runtime_dont_use_autosuspend() at
driver exit time, unless runtime PM was initially enabled with
devm_pm_runtime_enable().
Add the missing pm_runtime_dont_use_autosuspend() call to the driver
remove path.
This issue was found by manual code inspection.
Fixes: 5f420e8215c6 ("HID: intel-thc-hid: intel-quicki2c: Add PM implementation")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
Reviewed-by: Even Xu <even.xu@intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
When gamepad mode is disabled the gamepad input devices will stop receiving
updates. However, in the case where there are buttons still pressed this
will appear as an indefinitely-held button. Instead we should zero out the
inputs to make it look like things are all released. We do the same thing
for gyroscope inputs to make sure it doesn't look like it's endlessly
rotating, but we freeze the accelerometer input since zero isn't a neutral
input on the surface of the Earth.
Signed-off-by: Vicki Pfau <vi@endrift.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
This cleans up several issues with locking behavior, including RCU accesses
not being guarded behind a lock.
Signed-off-by: Vicki Pfau <vi@endrift.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
When an input device is closed, we set a feature report to reset lizard
mode and IMU mode. However, if the input device is closed because it was
removed, then we will necessarily error out when sending this, resulting in
logged errors. Since an error here is expected, we should just fail
silently.
Signed-off-by: Vicki Pfau <vi@endrift.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
It always said Controller, even on Deck. Since we special-case other
instances of Controller vs. Deck in strings, let's be consistent here too.
Signed-off-by: Vicki Pfau <vi@endrift.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
This brings support for the 2026 Steam Controller, comparably featureful to
the existing support for the Steam Deck.
Signed-off-by: Vicki Pfau <vi@endrift.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
This refactors and simplifies the registration/unregistration flow. Since
we now only perform registration when the client isn't opened anymore, the
logic for handling that can be removed, and the rest of the function
streamlined.
We also remove the previous assumption that we have a serial number to show
we're registered, replacing it with a single purpose boolean.
In a previous refactor the code for unregistering a battery if later
registration steps failed was accidentally left out. As a result, a
lingering power_supply object could get left over after the steam object
was torn down. This is also fixed here.
Signed-off-by: Vicki Pfau <vi@endrift.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
Add Logitech Bolt receiver support to the Logitech HID receiver and
HID++ drivers.
Handle Bolt receiver notifications in hid-logitech-dj and add a
Bolt-specific initialization path in hid-logitech-hidpp, separate from
the existing Unifying receiver path.
This allows Bolt-connected HID++ devices to expose battery information
through the kernel power_supply path, so userspace tools can report
their battery status with the correct device model.
Also, treat HIDPP_ERROR_CONNECT_FAIL like other disconnected-device
errors when retrieving protocol version to avoid protocol error messages
when a Bolt device powers off.
Tested with:
- Logitech MX Keys for Business via Bolt receiver
Signed-off-by: Erik Håkansson <erikhakan@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
sensor_hub_get_feature() clamps its return value to the caller's buffer
size, but the copy loop still copies field->report_size / 8 bytes for
each report value. A malicious HID descriptor can advertise a large
feature field size while an IIO caller supplies a small stack buffer,
such as a single s32, causing an out-of-bounds write.
HID core stores parsed report values in __s32 slots and clamps extracted
values to 32 bits. Reject feature fields that require more than one slot
per value, guard the total byte count calculation, and clamp each
per-value copy to the remaining caller buffer.
Fixes: 5459ada2b3cd69 ("HID: sensor-hub: Fix packing of result buffer for feature report")
Cc: stable@kernel.org
Assisted-by: OpenAI:GPT-5.5-Cyber
Signed-off-by: Xingrui Li <baka9@bakabaka9.tech>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
Richard Fitzgerald <rf@opensource.cirrus.com> says:
At the time the cs35l56 driver was written the only way to get interrupts
from the SoundWire core was to implement a custom handler inside the
interrupt_callback() function.
The SoundWire core now provides a virtual IRQ for notifying ImpDef
interrupts, and switching to this simplifies the code and also makes it
more similar to the normal interrupt handling of I2C/SPI (though some
SoundWire specials are still needed).
Patches #1 and #2 do some preparatory code shuffling so that there is
less clutter in patch #4.
Patch #3 changes the SoundWire core code to create the virtual ImpDef IRQ
before calling the codec drive probe() so that the IRQ can be requested in
probe().
Link: https://patch.msgid.link/20260810104045.60701-1-rf@opensource.cirrus.com
|
|
Replace the custom SoundWire IRQ handling with the generic nested IRQ
provided by the SoundWire core. This removes the local IRQ work function
and the convoluted IRQ masking and pm_runtime management around it.
We still need the local functions to mask/disable and unmask/enable the
SoundWire interrupts because the devices handled by the cs35l56 driver
don't have the generic mask bit for the ImpDef1 interrupt so masking and
unmasking has to use a custom mask bit.
cs35l56_sdw_remove() doesn't need to call cs35l56_disable_sdw_interrupts()
now that there isn't a local work function to be flushed. It only masks
the custom interrupt mask bit and the rest of the handler cleanup will be
done the normal way by devm_free_irq() in cs35l56_remove().
Similar applies to cs35l56_sdw_system_suspend() - it is enough to write
the custom mask bits.
cs35l56_irq() doesn't need to be exported because cs35l56_sdw.c isn't
calling it.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20260810104045.60701-5-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Call sdw_irq_create_mapping() before calling the peripheral driver
probe() so that it is possible to request the IRQ during probe().
Previously creation of the mapping was conditional on the use_domain_irq
flag in the driver properties. But these are filled in after probe(),
which meant it wasn't possible to request the IRQ during probe(). This
was ok for MFD drivers where only children requested the IRQ. But for
normal drivers it led to the non-standard behavior of having to defer
requesting the IRQ until after probe().
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Acked-by: Vinod Koul <vkoul@kernel.org>
Link: https://patch.msgid.link/20260810104045.60701-4-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
cs35l56_irq_request() references cs35l56_irq() but was above it in the
source (although they are in the other order in the header file). Switch
to convertional C ordering.
This is preparation for a future patch that will stop exporting
cs35l56_irq() and make it static.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20260810104045.60701-3-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Call cs35l56_irq_request() in cs35l56_common_probe() instead of calling
it afterwards in the probe() for each bus type.
Calling cs35l56_irq_request() in each bus probe() is a legacy of dealing
with the oddities of the SoundWire framework. It's no longer serving any
useful purpose to do it outside of the main cs35l56_common_probe().
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20260810104045.60701-2-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The A733 has six SPI controllers with the same IP as the A523.
Like the A523, one of them (spi1) also supports DBI mode.
Add SoC specific compatible strings, falling back to the A523 ones.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://patch.msgid.link/20260812-allwinner-a733-spi-support-v2-1-937bff0fa78e@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
universal_pidff_probe() starts the device with hid_hw_start() and then, if
force-feedback initialisation fails, returns the error through a label that
only does "return error". The device is left started.
The HID core does not unwind on the driver's behalf. __hid_device_probe()
releases the devres group, closes the report and clears hdev->driver:
if (ret) {
devres_release_group(&hdev->dev, hdev->devres_group_id);
hid_close_report(hdev);
hdev->driver = NULL;
}
The hidraw character device that hid_hw_start() registered through
hid_connect() is allocated with kzalloc() and added with cdev_device_add(),
so it is not devres-managed and survives that. With hdev->driver NULL,
hid_device_remove() skips hid_hw_stop() as well, because it only unwinds
while a driver is still attached. The registration therefore outlives the
device on both paths.
Opening the surviving /dev/hidrawX writes into freed memory. KASAN reports
a use-after-free write from hidraw_open() -> hid_hw_open() -> the
transport's open callback, which takes a spinlock inside the freed object.
A descriptor that carries a PID usage page and no input reports is enough:
hidraw claims the device so hid_hw_start() succeeds, while hid->inputs
stays empty so force-feedback init fails. The other failure returns in
hid_pidff_init_with_quirks() - no output reports, an allocation failure,
pidff_init_fields(), pidff_check_autocenter(), an unusable effect count,
input_ff_create() - all reach the same label.
Stop the device on that path. hid-dr.c and hid-emsff.c, which start the
device with the same HID_CONNECT_DEFAULT & ~HID_CONNECT_FF mask, already do
this. The two earlier gotos must keep returning without hid_hw_stop(),
since neither has a started device, so give the path that fails after the
start its own label.
Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>
Fixes: f06bf8d94fff ("HID: Add hid-universal-pidff driver and supported device ids")
Cc: stable@vger.kernel.org
Signed-off-by: Baul Lee <baul.lee@xbow.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
Refactor hid_haptic_init() to take a direct pointer to input_dev and
integrate its invocation into hid_haptic_input_configured().
Update hid-multitouch to rely on the refactored callback to perform the
force-feedback initialization during the registration loop. This ensures
that force-feedback capabilities are set up before the input device is
registered and exposed to userspace, closing the registration race.
Assisted-by: Gemini:gemini-3.1-pro
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
The driver currently initializes force-feedback in its probe() function
after calling hid_connect(). This is racy as the input device is
already registered and visible to userspace at that point.
Move the FF initialization to the .input_configured() callback to ensure
the device is fully prepared before registration.
Assisted-by: Gemini:gemini-3.1-pro
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
The driver currently initializes force-feedback in its probe() function
after calling hid_hw_start(). This is racy as the input device is
already registered and visible to userspace at that point.
Move the FF initialization to the .input_configured() callback to ensure
the device is fully prepared before registration.
Assisted-by: Gemini:gemini-3.1-pro
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
The driver currently initializes force-feedback in its probe() function
after calling hid_hw_start(). This is racy as the input device is
already registered and visible to userspace at that point.
Move the FF initialization to the .input_configured() callback to ensure
the device is fully prepared before registration.
Assisted-by: Gemini:gemini-3.1-pro
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
The driver currently initializes force-feedback in its probe() function
after calling hid_hw_start(). This is racy as the input device is
already registered and visible to userspace at that point.
Move the FF initialization to the .input_configured() callback to ensure
the device is fully prepared before registration.
Assisted-by: Gemini:gemini-3.1-pro
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
The driver currently initializes force-feedback in its probe() function
after calling hid_hw_start(). This is racy as the input device is
already registered and visible to userspace at that point.
Move the FF initialization to the .input_configured() callback to ensure
the device is fully prepared before registration.
Assisted-by: Gemini:gemini-3.1-pro
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
The driver currently initializes force-feedback in its probe() function
after calling hid_hw_start(). This is racy as the input device is
already registered and visible to userspace at that point.
Move the FF initialization to the .input_configured() callback to ensure
the device is fully prepared before registration.
Assisted-by: Gemini:gemini-3.1-pro
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
The driver currently initializes force-feedback in its probe() function
after calling hid_hw_start(). This is racy as the input device is
already registered and visible to userspace at that point.
Move the FF initialization to the .input_configured() callback to ensure
the device is fully prepared before registration.
Assisted-by: Gemini:gemini-3.1-pro
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
The driver currently initializes force-feedback in its probe() function
after calling hid_hw_start(). This is racy as the input device is
already registered and visible to userspace at that point.
Move the FF initialization to the .input_configured() callback to ensure
the device is fully prepared before registration.
Assisted-by: Gemini:gemini-3.1-pro
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
Generic force-feedback initialization (pidff) currently happens in
hid_connect() after hidinput_connect() has already registered the input
devices. This is racy as the device is live and visible to userspace
before FF support is fully set up.
Move the call to hdev->ff_init() into hidinput_connect(), ensuring it
runs before input_register_device() is called. This closes the race
window for standard PID-capable devices.
The initialization now also checks (connect_mask & HID_CONNECT_FF) and
!hid_has_ff_input() to avoid conflicts with custom FF implementations
and respect driver opt-outs.
Assisted-by: Gemini:gemini-3.1-pro
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
The driver currently initializes force-feedback in its probe() function
after calling hid_hw_start() with HID_CONNECT_DEFAULT. This is racy as
the input device is already registered and visible to userspace at that
point.
Move the FF initialization to the .input_configured() callback to ensure
the device is fully prepared before registration.
Assisted-by: Gemini:gemini-3.1-pro
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
The driver currently initializes force-feedback in its probe() function
after calling hid_hw_start() with HID_CONNECT_DEFAULT. This is racy as
the input device is already registered and visible to userspace at that
point.
Move the FF initialization to the .input_configured() callback to ensure
the device is fully prepared before registration.
Assisted-by: Gemini:gemini-3.1-pro
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
Override input device open() and close() callbacks to enable and disable
the force-feedback workqueue item synchronously.
When the input device is opened by userspace, call hid_hw_open() and
enable_work(). When it is closed, disable_work_sync() ensures that any
pending or running work item is cancelled/flushed and no further work
items can be scheduled.
In close(), zero out magnitudes and issue a final report to turn off the
rumble motors on the physical controller before shutting down transport
I/O.
Pack strong and weak magnitudes into a single u32 integer using
WRITE_ONCE() and READ_ONCE() for atomic, lockless updates.
This allows eliminating the manual 'removed' boolean flag and spinlock
completely.
Assisted-by: Antigravity:gemini-3.6-flash
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
The driver currently initializes force-feedback in its probe() function
after calling hid_hw_start() with HID_CONNECT_DEFAULT. This is racy as
the input device is already registered and visible to userspace at that
point.
Move the FF initialization to the .input_configured() callback to ensure
the device is fully prepared before registration.
Assisted-by: Gemini:gemini-3.1-pro
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
The driver currently initializes force-feedback in its probe() function
after calling hid_hw_start() with HID_CONNECT_DEFAULT. This is racy as
the input device is already registered and visible to userspace at that
point.
Move the FF initialization to the .input_configured() callback to ensure
the device is fully prepared before registration.
Assisted-by: Gemini:gemini-3.1-pro
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
The driver currently initializes force-feedback in its probe() function
after calling hid_hw_start() with HID_CONNECT_DEFAULT. This is racy as
the input device is already registered and visible to userspace at that
point.
Move the FF initialization to the .input_configured() callback to ensure
the device is fully prepared before registration.
Assisted-by: Gemini:gemini-3.1-pro
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
The driver currently initializes force-feedback in its probe() function
after calling hid_hw_start() with HID_CONNECT_DEFAULT. This is racy as
the input device is already registered and visible to userspace at that
point.
Move the FF initialization to the .input_configured() callback to ensure
the device is fully prepared before registration.
Assisted-by: Gemini:gemini-3.1-pro
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
The driver currently initializes force-feedback in its probe() function
after calling hid_hw_start() with HID_CONNECT_DEFAULT. This is racy as
the input device is already registered and visible to userspace at that
point.
Move the FF initialization to the .input_configured() callback to ensure
the device is fully prepared before registration.
Assisted-by: Gemini:gemini-3.1-pro
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
The driver currently initializes force-feedback in its probe() function
after calling hid_hw_start() with HID_CONNECT_DEFAULT. This is racy as
the input device is already registered and visible to userspace at that
point.
Move the FF initialization to the .input_configured() callback to ensure
the device is fully prepared before registration.
Assisted-by: Gemini:gemini-3.1-pro
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
HID drivers that rely on the HID core to register input devices must
ensure that all private data and capabilities (like force-feedback) are
fully initialized before registration.
When hid_hw_start() is called with HID_CONNECT_HIDINPUT, the input
device is registered immediately. This is racy if the driver attempts to
augment the input device in probe() after starting the hardware.
The correct way to handle this is to use the .input_configured()
callback.
Add documentation and a Coccinelle script to detect and prevent this
anti-pattern.
Assisted-by: Gemini:gemini-3.1-pro
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
Some HID drivers initialize their own force-feedback support within
their .input_configured() callback. In such cases, we should skip
the generic PID force-feedback initialization to avoid conflicts and
redundant setup.
Add hid_has_ff_input() helper and use it to check for existing FF
capabilities before calling hdev->ff_init().
Since we now have a dynamic way to detect if force-feedback is needed,
the HID_CONNECT_FF flag is redundant for conflict resolution and can
be ignored in the core initialization logic. Generic PID support will
now be attempted by default for any claimed input device that doesn't
already have FF capabilities.
Assisted-by: Gemini:gemini-3.1-pro
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
Report whether an AMD convertible is in laptop or tablet mode using the
operating-mode sensor provided by the Sensor Fusion Hub, and expose it
to userspace as SW_TABLET_MODE, so userspace can react to the device
being folded into tablet posture.
Cc: Helge Bahmann <hcb@chaoticmind.net>
Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
Register an auxiliary device when the operating-mode sensor is present,
so a dedicated input driver can bind to it and report the device
posture. This keeps the input handling out of the sensor transport
driver.
Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
Allow other drivers to query the operating mode (laptop or tablet)
reported by the Sensor Fusion Hub. This is the interface used by the
tablet-mode switch driver to report the device posture to userspace.
Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
The SFH accessors reach the device through a file-global emp2 pointer
that is published at probe and cleared on remove. amd_get_sfh_info() is
exported and called from other modules on unrelated threads, so a reader
can observe a non-NULL emp2 and then race a concurrent unbind that clears
it and frees the device.
Serialize the emp2 publish/clear and all readers under a mutex, so a
reader either sees a live device for the whole access or sees NULL.
Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
The MP2 version is currently known only implicitly, from whether an ops
pointer was stored in the PCI driver_data. Subsequent changes need to
act on the MP2 version directly, for example to read the operating-mode
register only on confirmed MP2 v2.
Track the MP2 version explicitly so that version-specific behaviour can
be gated on it, and leave it unset for generations that do not require
such handling.
Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
|
|
Smatch complains that returning a NULL here will lead to a NULL pointer
dereference in drm_mode_addfb2(). Return an error pointer instead.
Fixes: dc5698e80cf7 ("Add virtio gpu driver.")
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Link: https://patch.msgid.link/an1tWfHIHwtXd9SO@stanley.mountain
|
|
Miquel Raynal <miquel.raynal@bootlin.com> says:
I am in possession of an MA35D1 NuMaker board. The SPI controller has
been contributed, but:
1- it lacks a DT descriptions [1]
2- it does not work with current clock driver [2]
3- it can be improved
Link: https://lore.kernel.org/linux-arm-kernel/20260813-perso-ma35d1-upstream-dts-v1-0-bb237fd7c3c2@bootlin.com [1]
Link: https://lore.kernel.org/linux-clk/20260813-perso-ma35d1-upstream-clk-v1-1-e78e5e6172ea@bootlin.com [2]
This series is addressing #3 by:
- reusing existing helpers
- refactoring a bit the code
- adding DTR support
Link: https://patch.msgid.link/20260813-perso-ma35d1-upstream-qspi-v1-0-b217b9870eb1@bootlin.com
|
|
Read modify writes are already covered by a local helper, so use it.
No functional change.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://patch.msgid.link/20260813-perso-ma35d1-upstream-qspi-v1-5-b217b9870eb1@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The controller has DTR support, a bit must be set for it. The behaviour
is interesting though, as the speed won't improve when enabled. This is
because there seems to be an internal divisor (/2) which keeps the rate
equal when DTR is enabled. As a result, this commit also doubles the
target bus speed, which in practice does not happen. This way, there is
a real gain:
Before:
$ flash_speed /dev/mtd0 -dc10
eraseblock write speed is 1000 KiB/s
[...]
eraseblock read speed is 1199 KiB/s
[...]
After:
$ flash_speed /dev/mtd0 -dc10
eraseblock write speed is 985 KiB/s
[...]
eraseblock read speed is 1540 KiB/s
[...]
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://patch.msgid.link/20260813-perso-ma35d1-upstream-qspi-v1-4-b217b9870eb1@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
