The drivers do not require their own error messages for error
-ENOMEM, memory allocation failures. So remove the dev_err()
messages from the probe().
Signed-off-by: Dixit Parmar <dixitparmar19@gmail.com>
Link: https://patch.msgid.link/20250822-enomam_logs-v1-4-db87f2974552@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The drivers do not require their own error messages for error
-ENOMEM, memory allocation failures. So remove the dev_err()
messages from the probe().
Signed-off-by: Dixit Parmar <dixitparmar19@gmail.com>
Link: https://patch.msgid.link/20250822-enomam_logs-v1-3-db87f2974552@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The drivers do not require their own error messages for error
-ENOMEM, memory allocation failures. So remove the dev_err()
messages from the probe().
Signed-off-by: Dixit Parmar <dixitparmar19@gmail.com>
Link: https://patch.msgid.link/20250822-enomam_logs-v1-2-db87f2974552@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The drivers do not require their own error messages for error
-ENOMEM, memory allocation failures. So remove the dev_err()
messages from the probe().
Signed-off-by: Dixit Parmar <dixitparmar19@gmail.com>
Link: https://patch.msgid.link/20250822-enomam_logs-v1-1-db87f2974552@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
AMS_ALARM_THR_DIRECT_MASK should be bit 0, not bit 1. This would cause
hysteresis to be enabled with a lower threshold of -28C. The temperature
alarm would never deassert even if the temperature dropped below the
upper threshold.
Fixes: d5c70627a7 ("iio: adc: Add Xilinx AMS driver")
Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
Reviewed-by: O'Griofa, Conall <conall.ogriofa@amd.com>
Tested-by: Erim, Salih <Salih.Erim@amd.com>
Acked-by: Erim, Salih <Salih.Erim@amd.com>
Link: https://patch.msgid.link/20250715003058.2035656-1-sean.anderson@linux.dev
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
To convert level-triggered alarms into edge-triggered IIO events, alarms
are masked when they are triggered. To ensure we catch subsequent
alarms, we then periodically poll to see if the alarm is still active.
If it isn't, we unmask it. Active but masked alarms are stored in
current_masked_alarm.
If an active alarm is disabled, it will remain set in
current_masked_alarm until ams_unmask_worker clears it. If the alarm is
re-enabled before ams_unmask_worker runs, then it will never be cleared
from current_masked_alarm. This will prevent the alarm event from being
pushed even if the alarm is still active.
Fix this by recalculating current_masked_alarm immediately when enabling
or disabling alarms.
Fixes: d5c70627a7 ("iio: adc: Add Xilinx AMS driver")
Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
Reviewed-by: O'Griofa, Conall <conall.ogriofa@amd.com>
Tested-by: Erim, Salih <Salih.Erim@amd.com>
Acked-by: Erim, Salih <Salih.Erim@amd.com>
Link: https://patch.msgid.link/20250715002847.2035228-1-sean.anderson@linux.dev
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
On commit 9286dfd573 ("platform/x86: asus-wmi: Fix spurious rfkill on
UX8406MA"), Mathieu adds a quirk for the Zenbook Duo to ignore the code
0x5f (WLAN button disable). On that laptop, this code is triggered when
the device keyboard is attached.
On the ASUS ROG Z13 2025, this code is triggered when pressing the side
button of the device, which is used to open Armoury Crate in Windows.
As this is becoming a pattern, where newer Asus laptops use this keycode
for emitting events, let's convert the wlan ignore quirk to instead
allow emitting codes, so that userspace programs can listen to it and
so that it does not interfere with the rfkill state.
With this patch, the Z13 wil emit KEY_PROG3 and the Duo will remain
unchanged and emit no event. While at it, add a quirk for the Z13 to
switch into tablet mode when removing the keyboard.
Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
Link: https://lore.kernel.org/r/20250808154710.8981-2-lkml@antheas.dev
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Currently, the ignore_key_wlan quirk applies to keycodes 0x5D, 0x5E, and
0x5F. However, the relevant code for the Asus Zenbook Duo is only 0x5F.
Since this code is emitted by other Asus devices, such as from the Z13
for its ROG button, remove the extra codes before expanding the quirk.
For the Duo devices, which are the only ones that use this quirk, there
should be no effect.
Fixes: 9286dfd573 ("platform/x86: asus-wmi: Fix spurious rfkill on UX8406MA")
Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
Link: https://lore.kernel.org/r/20250808154710.8981-1-lkml@antheas.dev
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Fix a permanent ACPI table memory leak when amd_hfi_metadata_parser()
fails due to invalid PCCT table length or memory allocation errors.
Fixes: d4e95ea7a7 ("platform/x86: hfi: Parse CPU core ranking data from shared memory")
Cc: stable@vger.kernel.org
Signed-off-by: Zhen Ni <zhen.ni@easystack.cn>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Link: https://lore.kernel.org/r/20250822083329.710857-1-zhen.ni@easystack.cn
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
The DTS code coding style expects exactly one space around '='
character.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20250821083150.46554-2-krzysztof.kozlowski@linaro.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
On nios2, with CONFIG_FLATMEM set, the kernel relies on
memblock_get_current_limit() to determine the limits of mem_map, in
particular for max_low_pfn.
Unfortunately, memblock.current_limit is only default initialized to
MEMBLOCK_ALLOC_ANYWHERE at this point of the bootup, potentially leading
to situations where max_low_pfn can erroneously exceed the value of
max_pfn and, thus, the valid range of available DRAM.
This can in turn cause kernel-level paging failures, e.g.:
[ 76.900000] Unable to handle kernel paging request at virtual address 20303000
[ 76.900000] ea = c0080890, ra = c000462c, cause = 14
[ 76.900000] Kernel panic - not syncing: Oops
[ 76.900000] ---[ end Kernel panic - not syncing: Oops ]---
This patch fixes this by pre-calculating memblock.current_limit
based on the upper limits of the available memory ranges via
adjust_lowmem_bounds, a simplified version of the equivalent
implementation within the arm architecture.
Signed-off-by: Simon Schuster <schuster.simon@siemens-energy.com>
Signed-off-by: Andreas Oetken <andreas.oetken@siemens-energy.com>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
While the GCC and Clang compilers already define __ASSEMBLER__
automatically when compiling assembly code, __ASSEMBLY__ is a
macro that only gets defined by the Makefiles in the kernel.
This can be very confusing when switching between userspace
and kernelspace coding, or when dealing with uapi headers that
rather should use __ASSEMBLER__ instead. So let's standardize on
the __ASSEMBLER__ macro that is provided by the compilers now.
This is a completely mechanical patch (done with a simple "sed -i"
statement).
Cc: Dinh Nguyen <dinguyen@kernel.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
__ASSEMBLY__ is only defined by the Makefile of the kernel, so
this is not really useful for uapi headers (unless the userspace
Makefile defines it, too). Let's switch to __ASSEMBLER__ which
gets set automatically by the compiler when compiling assembly
code.
This is a completely mechanical patch (done with a simple "sed -i"
statement).
Cc: Dinh Nguyen <dinguyen@kernel.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
for_each_set_bit()/find_*_bit() expect arrays of unsigned long (see
include/linux/find.h), but industrialio-core passed const long * into
iio_device_add_info_mask_type{,_avail}().
These masks are used purely as bit arrays and are populated via BIT()
(1UL << n). Switch the info_mask_* fields and the corresponding function
parameters to unsigned long so the types match the helpers. This removes
sparse warnings about signedness mismatches (seen with 'make C=1'
CF='-Wsparse-all') without changing behavior or struct layout.
No functional change intended.
Suggested-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Junjie Cao <junjie.cao@intel.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://patch.msgid.link/20250820004755.69627-1-junjie.cao@intel.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
There's no corresponding call to platform_get_drvdata() or
dev_get_drvdata(). Remove the call to platform_set_drvdata() from
.probe().
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20250825-gpio-mmio-gpio-conv-v1-4-356b4b1d5110@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
There's no reason for this driver to touch the gpio-mmio internals, we
have a dedicated flag passed to bgpio_init() indicating to the module
that the DIR register is unreadable.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20250825-gpio-mmio-gpio-conv-v1-3-356b4b1d5110@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Provide helpers wrapping the read_reg() and write_reg() callbacks of the
generic GPIO API that are called directly by many users. This is done to
hide their implementation ahead of moving them into the separate generic
GPIO struct.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20250825-gpio-mmio-gpio-conv-v1-2-356b4b1d5110@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Add #io-channel-cells property with a constant value of 1 because it is
multi-channel ADC.
Fix below CHECK_DTBS warnings:
arch/arm/boot/dts/nxp/ls/ls1021a-iot.dtb: adc@35 (maxim,max1239): '#io-channel-cells' does not match any of the regexes: '^pinctrl-[0-9]+$'
from schema $id: http://devicetree.org/schemas/iio/adc/maxim,max1238.yaml#
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20250818200014.3700738-1-Frank.Li@nxp.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
GPD devices originally used BMI160 sensors with the "BMI0160" PNP ID.
When they switched to BMI260 sensors in newer hardware, they reused
the existing Windows driver which accepts both "BMI0160" and "BMI0260"
IDs. Consequently, they kept "BMI0160" in DSDT tables for new BMI260
devices, causing driver mismatches in Linux.
1. GPD updated BIOS v0.40+[1] for newer devices to report "BMI0260" for
BMI260 sensors to avoid loading the bmi160 driver on Linux. While this
isn't Bosch's VID;
2. Bosch's official Windows driver uses "BMI0260" as a compatible ID
3. We're seeing real devices shipping with "BMI0260" in DSDT
The DSDT excerpt of GPD G1619-04 with BIOS v0.40:
Scope (_SB.I2CC)
{
Device (BMA2)
{
Name (_ADR, Zero) // _ADR: Address
Name (_HID, "BMI0260") // _HID: Hardware ID
Name (_CID, "BMI0260") // _CID: Compatible ID
Name (_DDN, "Accelerometer") // _DDN: DOS Device Name
Name (_UID, One) // _UID: Unique ID
Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
{
Name (RBUF, ResourceTemplate ()
{
I2cSerialBusV2 (0x0069, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.I2CC",
0x00, ResourceConsumer, , Exclusive,
)
})
Return (RBUF) /* \_SB_.I2CC.BMA2._CRS.RBUF */
}
# omit some noise
}
}
Link: http://download.softwincn.com/WIN%20Max%202024/Max2-7840-BIOS-V0.41.zip#1
Signed-off-by: Cryolitia PukNgae <cryolitia@uniontech.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Acked-by: Alex Lanzano <lanzano.alex@gmail.com>
Link: https://patch.msgid.link/20250821-bmi270-gpd-acpi-v4-1-5279b471d749@uniontech.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
There are two problems with the chip configuration in this driver:
- First, is that writing 12 bytes (ARRAY_SIZE(regs)) would anyhow
lead to a config overflow due to HW auto increment implementation
in the chip.
- Second, the i2c_smbus_write_block_data write ends up in writing
unexpected value to the channel_dis register, this is because
the smbus size that is 0x03 in this case gets written to the
register. The PAC1931/2/3/4 data sheet does not really specify
that block write is indeed supported.
This problem is probably not visible on PAC1934 version where all
channels are used as the chip is properly configured by luck,
but in our case whenusing PAC1931 this leads to nonfunctional device.
Fixes: 0fb528c825 (iio: adc: adding support for PAC193x)
Suggested-by: Rene Straub <mailto:rene.straub@belden.com>
Signed-off-by: Aleksandar Gerasimovski <aleksandar.gerasimovski@belden.com>
Reviewed-by: Marius Cristea <marius.cristea@microchip.com>
Link: https://patch.msgid.link/20250811130904.2481790-1-aleksandar.gerasimovski@belden.com
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Replace calls of devm_kzalloc() with devm_kcalloc() in scmi_alloc_iiodev()
and scmi_iio_set_sampling_freq_avail() for safer memory allocation with
built-in overflow protection.
Similarly, use array_size() instead of explicit multiplication for
'sensor->sensor_info->intervals.count * 2'.
Signed-off-by: Qianfeng Rong <rongqianfeng@vivo.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://patch.msgid.link/20250819125017.635182-1-rongqianfeng@vivo.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
dt-bindings documentation for this driver claims to support
thermocouple-type, but the driver does not actually make use of
the property.
Implement usage of the property to configure the chip for the
selected thermocouple-type.
Signed-off-by: Ben Collins <bcollins@watter.com>
Reviewed-by: David Lechner <dlechner@baylibre.com>
Link: https://patch.msgid.link/20250822-upstream-changes-v8-5-40bb1739e3e2@watter.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The current driver works with mcp9601, but emits a warning because it
does not recognize the chip id.
MCP9601 is a superset of MCP9600. The drivers works without changes
on this chipset.
However, the 9601 chip supports open/closed-circuit detection if wired
properly, so we'll need to be able to differentiate between them.
Moved "struct mcp9600_data" up in the file since a later patch will
need it and chip_info before the declarations.
Signed-off-by: Ben Collins <bcollins@watter.com>
Reviewed-by: David Lechner <dlechner@baylibre.com>
Link: https://patch.msgid.link/20250822-upstream-changes-v8-4-40bb1739e3e2@watter.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Make tabs consistent for register definitions and also fix width
to byte size.
Signed-off-by: Ben Collins <bcollins@watter.com>
Reviewed-by: David Lechner <dlechner@baylibre.com>
Reviewed-by: Andy Shevchenko <abdy@kernel.org>
Reviewed-by: David Lechner <dlechner@baylibrc.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Link: https://patch.msgid.link/20250822-upstream-changes-v8-3-40bb1739e3e2@watter.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add microchip,mcp9601 compatible in addition to the original
microchip,mcp9600 to designate support between these two chips.
The current dt-binding has open-circuit and short-circuit as interrupt
names, but these are only supported in mcp9601.
The OC and SC detection requires that mcp9601 VSENSE be wired up, which
not only enables the OC SC interrupts, but also the OC and SC status
register bits.
Add a microchip,vsense boolean to show the chip is wired for this
support.
Add constraints so this feature only applies if the mcp9601 compatible
is selected.
Signed-off-by: Ben Collins <bcollins@watter.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: David Lechner <dlechner@baylibre.com>
Link: https://patch.msgid.link/20250822-upstream-changes-v8-2-40bb1739e3e2@watter.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Document the clock property in sc7280 LPASS LPI pinctrl node.
Clock settings required for Audioreach solution.
The existing SC7280 platform only supports non-ADSP audio solutions.
To enable audio functionality on ADSP with the AudioReach solution.
additional core and audio hardware clocks must be configured.
Without these clocks, the ADSP will crash.
Signed-off-by: Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com>
Co-developed-by: Prasad Kumpatla <quic_pkumpatl@quicinc.com>
Signed-off-by: Prasad Kumpatla <quic_pkumpatl@quicinc.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/20250821044914.710044-3-quic_pkumpatl@quicinc.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
apic_pending_intr_clear() is fundamentally voodoo programming. It's primary
purpose is to clear stale ISR bits in the local APIC, which would otherwise
lock the corresponding interrupt priority level.
The comments and the implementation claim falsely that after clearing the
stale ISR bits, eventually stale IRR bits would be turned into ISR bits and
can be cleared as well. That's just wishful thinking because:
1) If interrupts are disabled, the APIC does not propagate an IRR bit to
the ISR.
2) If interrupts are enabled, then the APIC propagates the IRR bit to the
ISR and raises the interrupt in the CPU, which means that code _cannot_
observe the ISR bit for any of those IRR bits.
Rename the function to reflect the purpose and make exactly _one_ attempt
to EOI the pending ISR bits and add comments why traversing the pending bit
map in low to high priority order is correct.
Instead of trying to "clear" IRR bits, simply print a warning message when
the IRR is not empty.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/871ppwih4s.ffs@tglx
Introduce virt/ directory to collect virtchnl files.
We are going to implement a few sizable extensions soon, each of them
increasing virt/ size, so it looks sensible to introduce a new dir.
Suggested-by: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
As is already documented in this file, Type-K is the default, so make
that explicit in the dt-bindings.
Signed-off-by: Ben Collins <bcollins@watter.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: David Lechner <dlechner@baylibre.com>
Link: https://patch.msgid.link/20250822-upstream-changes-v8-1-40bb1739e3e2@watter.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The dev_err_probe() doesn't do anything when the error is '-ENOMEM'.
Therefore, remove the useless call to dev_err_probe(), and just return the
value instead.
Signed-off-by: Xichao Zhao <zhao.xichao@vivo.com>
Acked-by: Crt Mori <cmo@melexis.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://patch.msgid.link/20250821080723.525379-8-zhao.xichao@vivo.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The dev_err_probe() doesn't do anything when the error is '-ENOMEM'.
Therefore, remove the useless call to dev_err_probe(), and just return the
value instead.
Signed-off-by: Xichao Zhao <zhao.xichao@vivo.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://patch.msgid.link/20250821080723.525379-7-zhao.xichao@vivo.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The dev_err_probe() doesn't do anything when the error is '-ENOMEM'.
Therefore, remove the useless call to dev_err_probe(), and just return the
value instead.
Signed-off-by: Xichao Zhao <zhao.xichao@vivo.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://patch.msgid.link/20250821080723.525379-6-zhao.xichao@vivo.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The dev_err_probe() doesn't do anything when the error is '-ENOMEM'.
Therefore, remove the useless call to dev_err_probe(), and just return the
value instead.
Signed-off-by: Xichao Zhao <zhao.xichao@vivo.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://patch.msgid.link/20250821080723.525379-5-zhao.xichao@vivo.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The dev_err_probe() doesn't do anything when the error is '-ENOMEM'.
Therefore, remove the useless call to dev_err_probe(), and just return the
value instead.
Signed-off-by: Xichao Zhao <zhao.xichao@vivo.com>
Reviewed-by: Gustavo Silva <gustavograzs@gmail.com> # for ens160
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://patch.msgid.link/20250821080723.525379-4-zhao.xichao@vivo.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The dev_err_probe() doesn't do anything when the error is '-ENOMEM'.
Therefore, remove the useless call to dev_err_probe(), and just return the
value instead.
Signed-off-by: Xichao Zhao <zhao.xichao@vivo.com>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> # meson_saradc
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://patch.msgid.link/20250821080723.525379-3-zhao.xichao@vivo.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The dev_err_probe() doesn't do anything when the error is '-ENOMEM'.
Therefore, remove the useless call to dev_err_probe(), and just return the
value instead.
Signed-off-by: Xichao Zhao <zhao.xichao@vivo.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://patch.msgid.link/20250821080723.525379-2-zhao.xichao@vivo.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Anand left AMD/Xilinx some time ago. Salih and Connall are new
maintainers of xilinx-ams driver.
Signed-off-by: Salih Erim <salih.erim@amd.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Acked-by: Michal Simek <michal.simek@amd.com>
Acked-by: O'Griofa, Conall <conall.ogriofa@amd.com>
Link: https://patch.msgid.link/20250820100519.2272509-1-salih.erim@amd.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
