The mute led on this laptop is using ALC245 but requires a quirk to work
This patch enables the existing quirk for the device.
Tested on Victus 16-r0xxx Laptop. The LED behaviour works
as intended.
Cc: <stable@vger.kernel.org>
Signed-off-by: Edip Hazuri <edip@medip.dev>
Link: https://patch.msgid.link/20250710131812.27509-1-edip@medip.dev
Signed-off-by: Takashi Iwai <tiwai@suse.de>
hid-tools 0.10 fixes one inconvenience introduced by
commit 6a9e76f75c ("HID: multitouch: Disable touchpad
on firmware level while not in use")
This change added a new callback when a hid-nultitouch device is opened
or closed to put the underlying device into a given operating mode.
However, in the test cases, that means that while the single threaded
test is run, it opens the device but has to react to the device while
the open() is still running. hid-tools now implements a minimal thread
to circumvent this.
This makes the HID kernel tests in sync with hid-tools 0.10.
This has the net effect of running the full HID python testsuite in 6
minutes instead of 1 hour.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Link: https://patch.msgid.link/20250709-wip-fix-ci-v1-3-b7df4c271cf8@kernel.org
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Instead of backporting one by one each commits, let's pull them in bulk
and refer to the hid-tools project for a detailed history.
The short summary is:
- make use of dataclass when possible, to avoid tuples
- wacom: remove unused uhdev parameter
- various small fixes not worth mentioning
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Link: https://patch.msgid.link/20250709-wip-fix-ci-v1-2-b7df4c271cf8@kernel.org
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
We aim at syncing with the hid-tools repo on
gitlab.freedesktop.org/libevdev/hid-tools. One of the commits is this
mechanical formatting, so pull it over here so changes are not hidden by
those.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Link: https://patch.msgid.link/20250709-wip-fix-ci-v1-1-b7df4c271cf8@kernel.org
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Wire up suspend/resume handles for I2C controller to match its power
state with SGUnit.
Signed-off-by: Raag Jadav <raag.jadav@intel.com>
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Karthik Poosa <karthik.poosa@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://lore.kernel.org/r/20250701122252.2590230-5-heikki.krogerus@linux.intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Adding adaption/glue layer where the I2C host adapter
(Synopsys DesignWare I2C adapter) and the I2C clients (the
microcontroller units) are enumerated.
The microcontroller units (MCU) that are attached to the GPU
depend on the OEM. The initially supported MCU will be the
Add-In Management Controller (AMC).
Co-developed-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
Signed-off-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://lore.kernel.org/r/20250701122252.2590230-4-heikki.krogerus@linux.intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
[Rodrigo fixed the co-developed tags and SPDX format in the .c file]
The regmap is coming from the parent also in case of Xe
GPUs. Reusing the Wangxun quirk for that.
Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Co-developed-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
Signed-off-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Andi Shyti <andi.shyti@kernel.org>
Link: https://lore.kernel.org/r/20250701122252.2590230-3-heikki.krogerus@linux.intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
[Rodrigo fixed the co-developed tags while merging]
The irq resource itself can be used as a generic way to
determine when polling is needed.
This not only removes the need for special additional device
properties that would soon be needed when the platform may
or may not have the irq, but it also removes the need to
check the platform in the first place in order to determine
is polling needed or not.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Andi Shyti <andi.shyti@kernel.org>
Link: https://lore.kernel.org/r/20250701122252.2590230-2-heikki.krogerus@linux.intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
NDI (Northern Digital Inc.) is introducing a new product called the
EMGUIDE GEMINI that will use an FTDI chip for USB serial communications.
Add the NDI EMGUIDE GEMINI product ID that uses the NDI Vendor ID
rather than the FTDI Vendor ID, unlike older products.
Signed-off-by: Ryan Mann <rmann@ndigital.com>
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <johan@kernel.org>
Since we are already using reusable buffer objects from the GuC
buffer cache, we can directly write into their CPU pointers and
spare unnecessary temporary allocation.
While around, also make sure to clear obtained buffer, to avoid
sending some stale data.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://lore.kernel.org/r/20250702142504.1656-1-michal.wajdeczko@intel.com
Rosen Penev says:
====================
net: dsa: rzn1_a5psw: add COMPILE_TEST
Allows the various bots to test compilation. Also threw in a small devm
conversion for enabling clocks.
====================
Link: https://patch.msgid.link/20250708014144.2514-1-rosenp@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The remove function has these in the wrong order. The switch should be
unregistered last. Simpler to use devm so that the right thing is done.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://patch.msgid.link/20250708014144.2514-3-rosenp@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
There's no architecture specific requirement for it to compile. Allows
the bots to test compilation properly.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20250708014144.2514-2-rosenp@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
In 7e9b231c40 ("KVM: selftests: Add a KVM_IRQFD test to verify
uniqueness requirements") we added a test for the newly added irqfd
support but since this feature works with eventfds it won't work unless
the kernel has been built wth eventfd support. Add CONFIG_EVENTFD to
the list of required options for the KVM selftests.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20250710-kvm-selftests-eventfd-config-v1-1-78c276e4b80f@kernel.org
Signed-off-by: Sean Christopherson <seanjc@google.com>
During BMC firmware upgrades on live systems, the ipmi_msghandler
generates excessive "BMC returned incorrect response" warnings
while the BMC is temporarily offline. This can flood system logs
in large deployments.
Replace dev_warn() with dev_warn_ratelimited() to throttle these
warnings and prevent log spam during BMC maintenance operations.
Signed-off-by: Breno Leitao <leitao@debian.org>
Message-ID: <20250710-ipmi_ratelimit-v1-1-6d417015ebe9@debian.org>
Signed-off-by: Corey Minyard <corey@minyard.net>
The function opencodes the for_each_cpu_from() by using an open for-loop.
Fix that in sake of readability.
While there, drop the 'valid' variable as it's pretty useless here.
Signed-off-by: Yury Norov [NVIDIA] <yury.norov@gmail.com>
Link: https://patch.msgid.link/20250604213908.27819-1-yury.norov@gmail.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Commit fbfb649870 ("dt-bindings: firmware: stratix10: Convert to
json-schema") renames intel,stratix10-svc.txt to intel,stratix10-svc.yaml
in Documentation/devicetree/bindings/firmware/ as part of this dt-binding
conversion, but misses to adjust the file entry in INTEL STRATIX10 FIRMWARE
DRIVERS.
Adjust the file entry after the conversion.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@redhat.com>
Acked-by: Dinh Nguyen <dinguyen@kernel.org>
Link: https://lore.kernel.org/r/20250512134332.36366-1-lukas.bulwahn@redhat.com
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
This patch provides a setsockopt method to let applications leverage to
adjust how many descs to be handled at most in one send syscall. It
mitigates the situation where the default value (32) that is too small
leads to higher frequency of triggering send syscall.
Considering the prosperity/complexity the applications have, there is no
absolutely ideal suggestion fitting all cases. So keep 32 as its default
value like before.
The patch does the following things:
- Add XDP_MAX_TX_SKB_BUDGET socket option.
- Set max_tx_budget to 32 by default in the initialization phase as a
per-socket granular control.
- Set the range of max_tx_budget as [32, xs->tx->nentries].
The idea behind this comes out of real workloads in production. We use a
user-level stack with xsk support to accelerate sending packets and
minimize triggering syscalls. When the packets are aggregated, it's not
hard to hit the upper bound (namely, 32). The moment user-space stack
fetches the -EAGAIN error number passed from sendto(), it will loop to try
again until all the expected descs from tx ring are sent out to the driver.
Enlarging the XDP_MAX_TX_SKB_BUDGET value contributes to less frequency of
sendto() and higher throughput/PPS.
Here is what I did in production, along with some numbers as follows:
For one application I saw lately, I suggested using 128 as max_tx_budget
because I saw two limitations without changing any default configuration:
1) XDP_MAX_TX_SKB_BUDGET, 2) socket sndbuf which is 212992 decided by
net.core.wmem_default. As to XDP_MAX_TX_SKB_BUDGET, the scenario behind
this was I counted how many descs are transmitted to the driver at one
time of sendto() based on [1] patch and then I calculated the
possibility of hitting the upper bound. Finally I chose 128 as a
suitable value because 1) it covers most of the cases, 2) a higher
number would not bring evident results. After twisting the parameters,
a stable improvement of around 4% for both PPS and throughput and less
resources consumption were found to be observed by strace -c -p xxx:
1) %time was decreased by 7.8%
2) error counter was decreased from 18367 to 572
[1]: https://lore.kernel.org/all/20250619093641.70700-1-kerneljasonxing@gmail.com/
Signed-off-by: Jason Xing <kernelxing@tencent.com>
Acked-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Link: https://patch.msgid.link/20250704160138.48677-1-kerneljasonxing@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
When one starts QEMU with the -S flag and attaches GDB, the kernel is
not yet loaded, and the current instruction is an entry point to the
decompressor. In case the intention is to debug the early kernel boot,
and not the decompressor, e.g., put a breakpoint on some kernel
function and see all the invocations, one has to skip the decompressor.
There are many ways to do this, and so far people wrote private scripts
or memorized certain command sequences.
Make it work out of the box like this:
$ gdb -ex 'target remote :6812' -ex 'source vmlinux-gdb.py' vmlinux
Remote debugging using :6812
0x0000000000010000 in ?? ()
(gdb) lx-symbols
loading vmlinux
(gdb) x/i $pc
=> 0x3ffe0100000 <startup_continue>: lghi %r2,0
Implement this by reading the address of the jump_to_kernel() function
from the lowcore, and step until DAT is turned on.
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Acked-by: Jan Kiszka <jan.kiszka@siemens.com>
Tested-by: Alexander Gordeev <agordeev@linux.ibm.com>
Link: https://lore.kernel.org/r/20250625154220.75300-3-iii@linux.ibm.com
Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
Introduce a global function that jumps from the decompressor to the
decompressed kernel. Put its address into svc_old_psw, from where GDB
can take it without loading decompressor symbols. It should be
available throughout the entire decompressor execution, because it's
placed there statically, and nothing in the decompressor uses the SVC
instruction.
Acked-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Tested-by: Alexander Gordeev <agordeev@linux.ibm.com>
Link: https://lore.kernel.org/r/20250625154220.75300-2-iii@linux.ibm.com
Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
When an stp sync check is handled on a system with multiple
cpus each cpu gets a machine check but only the first one
actually handles the sync operation. All other CPUs spin
waiting for the first one to finish with a short udelay().
But udelay can't be used here as the first CPU modifies tod_clock_base
before performing the sync op. During this timeframe
get_tod_clock_monotonic() might return a non-monotonic time.
The time spent waiting should be very short and udelay is a busy loop
anyways, therefore simply remove the udelay.
Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Sven Schnelle <svens@linux.ibm.com>
Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
On some platforms, device dependencies are not properly represented by
device links, which can cause issues when asynchronous power management
is enabled. While it is possible to disable this via sysfs, doing so
at runtime can race with the first system suspend event.
This patch introduces a kernel command-line parameter, "pm_async", which
can be set to "off" to globally disable asynchronous suspend and resume
operations from early boot. It effectively provides a way to set the
initial value of the existing pm_async sysfs knob at boot time. This
offers a robust method to fall back to synchronous (sequential)
operation, which can stabilize platforms with problematic dependencies
and also serve as a useful debugging tool.
The default behavior remains unchanged (asynchronous enabled). To
disable it, boot the kernel with the "pm_async=off" parameter.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://patch.msgid.link/20250709-pm-async-off-v3-1-cb69a6fc8d04@linaro.org
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
While we print VF's configuration KLVs only under DEBUG_SRIOV
config, we should be doing it at debug level, not info level.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Lukasz Laguna <lukasz.laguna@intel.com>
Reviewed-by: Lukasz Laguna <lukasz.laguna@intel.com>
Link: https://lore.kernel.org/r/20250703145709.1832-1-michal.wajdeczko@intel.com
While we already print VF's runtime registers only under DEBUG_SRIOV
config, we should be still doing it at debug level, not info.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Lukasz Laguna <lukasz.laguna@intel.com>
Link: https://lore.kernel.org/r/20250604190021.725-2-michal.wajdeczko@intel.com
cpu_latency_qos_add|remove_notifier() doesn't exist, hence let's drop
the documentation of them.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Link: https://patch.msgid.link/20250710102656.127654-1-ulf.hansson@linaro.org
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Add PLL rate for 132 MHz to allow raydium-rm67200 panel with
1080x1920 resolution to run at 60 fps that driven by VPLL.
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
Link: https://lore.kernel.org/r/20250615123922.661998-1-andyshrk@163.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
This was returning IS_ERR() where PTR_ERR() was intended.
Fixes: 642b70d526 ("media: imx8mq-mipi-csi2: Add support for i.MX8QXP")
Cc: stable@vger.kernel.org
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Rui Miguel Silva <rui.silva@linaro.org>
Link: https://lore.kernel.org/r/9b6c7925-c9c4-44bd-acd5-1ef0e698eb87@sabinyo.mountain
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
There are no consumers or implementations left in tree for the subdevice
operation g_pixelaspect, delete it.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Link: https://lore.kernel.org/r/20250705083741.77517-4-niklas.soderlund+renesas@ragnatech.se
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
There are no consumer left of g_pixelaspect in the tree, remove the
implementation from the adv748x driver in preparation of removing it
from struct v4l2_subdev_video_ops all together.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Link: https://lore.kernel.org/r/20250705083741.77517-3-niklas.soderlund+renesas@ragnatech.se
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
There are no consumer left of g_pixelaspect in the tree, remove the
implementation from the adv7180 driver in preparation of removing it
from struct v4l2_subdev_video_ops all together.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Link: https://lore.kernel.org/r/20250705083741.77517-2-niklas.soderlund+renesas@ragnatech.se
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
The pad-aware version of v4l2_get_link_freq() tries to retrieve the link
frequency from the media bus configuration using the get_mbus_config
operation, and only if the subdevice does not implement this operation
falls back to the old method of getting it using the V4L2_CID_LINK_FREQ
or V4L2_CID_PIXEL_RATE control.
Update the VIN driver to use the pad-aware version to be able to support
subdevices that only provides the link frequency in the media bus
configuration. As the implementation falls back to the old method if the
subdevice doesn't support get_mbus_config, or doesn't provide a link
frequency in the v4l2_mbus_config struct, this is fully backward
compatible.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Link: https://lore.kernel.org/r/20250530-rcar-streams-v3-1-026655df7138@ideasonboard.com
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Extract KVM's open-coded calls to do writeback caches on multiple CPUs to
common library helpers for both WBINVD and WBNOINVD (KVM will use both).
Put the onus on the caller to check for a non-empty mask to simplify the
SMP=n implementation, e.g. so that it doesn't need to check that the one
and only CPU in the system is present in the mask.
[sean: move to lib, add SMP=n helpers, clarify usage]
Signed-off-by: Zheyun Shen <szy0127@sjtu.edu.cn>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Kai Huang <kai.huang@intel.com>
Link: https://lore.kernel.org/r/20250128015345.7929-2-szy0127@sjtu.edu.cn
Link: https://lore.kernel.org/20250522233733.3176144-5-seanjc@google.com
In reconfig we add the virtual monitor in 2 cases:
1. If we are resuming (it was deleted on suspend)
2. If it was added after an error but before the reconfig
(due to the last non-monitor interface removal).
In the second case, the removal of the non-monitor interface will succeed
but the addition of the virtual monitor will fail, so we add it in the
reconfig.
The problem is that we mislead the driver to think that this is an existing
interface that is getting re-added - while it is actually a completely new
interface from the drivers' point of view.
Some drivers act differently when a interface is re-added. For example, it
might not initialize things because they were already initialized.
Such drivers will - in this case - be left with a partialy initialized vif.
To fix it, add the virtual monitor after reconfig_complete, so the
driver will know that this is a completely new interface.
Fixes: 3c3e21e744 ("mac80211: destroy virtual monitor interface across suspend")
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250709233451.648d39b041e8.I2e37b68375278987e303d6c00cc5f3d8334d2f96@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This is currently not initialized for a virtual monitor, leading to a
NULL pointer dereference when - for example - iterating over all the
keys of all the vifs.
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250709233400.8dcefe578497.I4c90a00ae3256520e063199d7f6f2580d5451acf@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In line with WBINVD usage, add WBNOINVD helper functions. Explicitly fall
back to WBINVD (via alternative()) if WBNOINVD isn't supported even though
the instruction itself is backwards compatible (WBNOINVD is WBINVD with an
ignored REP prefix), so that disabling X86_FEATURE_WBNOINVD behaves as one
would expect, e.g. in case there's a hardware issue that affects WBNOINVD.
Opportunistically, add comments explaining the architectural behavior of
WBINVD and WBNOINVD, and provide hints and pointers to uarch-specific
behavior.
Note, alternative() ensures compatibility with early boot code as needed.
[ bp: Massage, fix typos, make export _GPL. ]
Signed-off-by: Kevin Loughlin <kevinloughlin@google.com>
Co-developed-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Kai Huang <kai.huang@intel.com>
Acked-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/20250522233733.3176144-4-seanjc@google.com
Drop wbinvd_on_all_cpus()'s return value; both the "real" version and the
stub always return '0', and none of the callers check the return.
Signed-off-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/20250522233733.3176144-3-seanjc@google.com
The TI TPS652G1 is a stripped down version of the TPS65224 PMIC. It
doesn't feature the multiphase buck converter nor any voltage
monitoring. Due to the latter there are no interrupts serviced. In case
of the TPS652G1 any interrupt related setup is just skipped.
Signed-off-by: Michael Walle <mwalle@kernel.org>
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://patch.msgid.link/20250703113153.2447110-9-mwalle@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Instead of using conditionals or tri state operators throughout the
.probe() provide a description per variant. This will make it much
easier to add new variants later.
While at it, make the variable naming more consistent.
This patch is only compile-time tested.
Signed-off-by: Michael Walle <mwalle@kernel.org>
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://patch.msgid.link/20250703113153.2447110-8-mwalle@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit 00c826525f ("regulator: tps6594-regulator: Add TI TPS65224 PMIC
regulators") added support for the TPS65224 and made the description of
the multi-phase buck converter variable depending on the variant of the
PMIC. But this was just done for MUTLI_BUCK12 and MULTI_BUCK12_34
configs probably because this variant only supports a multi-phase
configuration on buck 1 and 2. Remove the hardcoded value for the
remaining two configs, too as future PMIC variants might also support
these.
This is a preparation patch to refactor the regulator description and
is compile-time only tested.
Signed-off-by: Michael Walle <mwalle@kernel.org>
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://patch.msgid.link/20250703113153.2447110-7-mwalle@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
In .probe() interrupt_count and nr_types is essentially the same. It
contains the number of different interrupt per LDO or buck converter.
Drop one. This is a preparation patch to further simplify the handling
of different variants of this PMIC.
This patch is only compile-time tested.
Signed-off-by: Michael Walle <mwalle@kernel.org>
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://patch.msgid.link/20250703113153.2447110-6-mwalle@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Remove the checks and associated pr_err() on wbinvd_on_all_cpus() failure,
as the helper has unconditionally returned 0/success since commit
caa759323c ("smp: Remove smp_call_function() and on_each_cpu() return values").
Signed-off-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/20250522233733.3176144-2-seanjc@google.com
BTN_WHEEL is duplicated (by value) and compiler is not happy about that:
drivers/hid/hid-debug.c:3302:16: error: initializer overrides prior initialization of this subobject [-Werror,-Winitializer-overrides]
3302 | [BTN_WHEEL] = "BtnWheel", [KEY_OK] = "Ok",
| ^~~~~~~~~~
drivers/hid/hid-debug.c:3301:20: note: previous initialization is here
3301 | [BTN_GEAR_DOWN] = "BtnGearDown", [BTN_GEAR_UP] = "BtnGearUp",
| ^~~~~~~~~~~~~
Remove it again, as the commit 7b2daa648e ("HID: debug: Remove duplicates
from 'keys'") already did this once in the past.
Fixes: 194808a1ea ("HID: Fix debug name for BTN_GEAR_DOWN, BTN_GEAR_UP, BTN_WHEEL")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20250710094120.753358-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Two patches here, one quirk for an AMD system and a fix for an issue on
remove of the AVS driver.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmhvf0AACgkQJNaLcl1U
h9BVfgf/VP/sVlMY+hiGvCT80Kj/nGsc/mdjWLLuCCHYpadyPUP8xJQTh/B/4w/x
737pRbcQo1jlPVEani9/FDmtqtNRL/wg3g8mgSvyVaui5AXL3LZD8zxk7bobFTwz
S+LhDQCZlN0tcn24qitsRe7U1uJcQ4WllApgHrlcsKWKONZydOjzKRv2d6wt5kY6
mEOQTN8fY5Fvqia5psZxwA7WtZTYQyS7Q6o+83ncE2Rf00KM9X2bdoYtZ5ZsAtG0
whve+VwXMq2MBpCzdEAb/CCATQ0SAXSlSKHyKAKi1C8lFuWeciNk4AAMmffaukn/
kIPs75PvczIHuTIc7OBgxBiWNF1bMg==
=dXN7
-----END PGP SIGNATURE-----
Merge tag 'asoc-fix-v6.16-rc5' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Fixes for v6.16
Two patches here, one quirk for an AMD system and a fix for an issue on
remove of the AVS driver.
Before each I2C transfer using DMA, the I2C buffer is DMA'pped to make
sure the memory buffer is DMA'able. This is handle in the function
`stm32_i2c_prep_dma_xfer()`.
If the transfer fails for any reason the I2C buffer must be unmap.
Use the dma_callback to factorize the code and fix this issue.
Note that the `stm32f7_i2c_dma_callback()` is now called in case of DMA
transfer success and error and that the `complete()` on the dma_complete
completion structure is done inconditionnally in case of transfer
success or error as well as the `dmaengine_terminate_async()`.
This is allowed as a `complete()` in case transfer error has no effect
as well as a `dmaengine_terminate_async()` on a transfer success.
Also fix the unneeded cast and remove not more needed variables.
Fixes: 7ecc8cfde5 ("i2c: i2c-stm32f7: Add DMA support")
Signed-off-by: Clément Le Goffic <clement.legoffic@foss.st.com>
Cc: <stable@vger.kernel.org> # v4.18+
Acked-by: Alain Volmat <alain.volmat@foss.st.com>
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Link: https://lore.kernel.org/r/20250704-i2c-upstream-v4-2-84a095a2c728@foss.st.com
If the DMA mapping failed, it produced an error log with the wrong
device name:
"stm32-dma3 40400000.dma-controller: rejecting DMA map of vmalloc memory"
Fix this issue by replacing the dev with the I2C dev.
Fixes: bb8822cbbc ("i2c: i2c-stm32: Add generic DMA API")
Signed-off-by: Clément Le Goffic <clement.legoffic@foss.st.com>
Cc: <stable@vger.kernel.org> # v4.18+
Acked-by: Alain Volmat <alain.volmat@foss.st.com>
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Link: https://lore.kernel.org/r/20250704-i2c-upstream-v4-1-84a095a2c728@foss.st.com
If an error occurs after pm_runtime_use_autosuspend(), a corresponding
pm_runtime_dont_use_autosuspend() should be called.
In case of error in pm_runtime_resume_and_get(), it is not the case because
the error handling path is wrongly ordered.
Fix it.
Fixes: 780f629741 ("i2c: omap: fix reference leak when pm_runtime_get_sync fails")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Cc: <stable@vger.kernel.org> # v5.13+
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Link: https://lore.kernel.org/r/af8a9b62996bebbaaa7c02986aa2a8325ef11596.1751701715.git.christophe.jaillet@wanadoo.fr
