summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-07-27hwmon: (lm90) Only report alarms if driver is readyGuenter Roeck
Userspace can read sysfs attributes before driver registration is complete, immediately after devm_hwmon_device_register_with_info() has been called. At that time, data->hwmon_dev is not yet initialized. This can trigger a NULL pointer access since lm90_update_device() and with it lm90_update_alarms_locked() will be called. This call schedules report_work and lm90_report_alarms(), which passes the still-NULL data->hwmon_dev to hwmon_notify_event() and triggers a NULL pointer dereference. Fix the problem by only scheduling the report and alert workers data->hwmon_dev is set. Reported-by: Sashiko <sashiko-bot@kernel.org> Fixes: f6d0775119fb9 ("hwmon: (lm90) Rework alarm/status handling") Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-07-27hwmon: (sht3x) Fix unaligned accessesGuenter Roeck
Sashiko reports: In sht3x_update_client(), the 16-bit temperature and humidity values are extracted from a stack-allocated byte array using be16_to_cpup(). The pointers passed to this function are calculated as buf and buf + 3. Since the difference between the two pointers is an odd number of bytes, at least one of them is guaranteed to be at an unaligned offset. This will trigger an alignment fault on strict-alignment architectures such as ARMv5 or SPARC, resulting in a kernel panic. Fix the problem by using get_unaligned_be16() instead of be16_to_cpup(), and put_unaligned_be16() instead of cpu_to_be16(). Fixes: 7c84f7f80d6f ("hwmon: add support for Sensirion SHT3x sensors") Reported-by: Sashiko <sashiko-bot@kernel.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-07-27hwmon: (ltc4282) Fix reading the minimum alarm voltageGuenter Roeck
Coverity reports an out-of-bounds access when reading the minimum alarm voltage for the VGPIO channel. Add the missing return statement to fix the problem. Fixes: cbc29538dbf7 ("hwmon: Add driver for LTC4282") Cc: Nuno Sa <nuno.sa@analog.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-07-27hwmon: (ina2xx) Fix various overflow issuesGuenter Roeck
Sashiko reports several integer overflow problems in the ina2xx driver caused by unbounded multiplications and inadequate types for intermediate calculations. Specifically: - In ina2xx_get_value(), the return type is changed from int to long. Intermediate calculations for current are now performed using 64-bit types to prevent 32-bit integer overflow before the division by 1000. - When calculating power in ina2xx_get_value() and sy24655_average_power_read(), interim values are cast to u64 and clamped to LONG_MAX. This prevents overflow when regval or accumulator_24 is multiplied by power_lsb_uW. - In ina226_alert_to_reg(), the clamping logic is rewritten using min_t(). This safely avoids integer overflows when scaling user-provided values for shunt voltage, bus voltage, power, and current limits. Cc: Loic Poulain <loic.poulain@oss.qualcomm.com> Fixes: ab7fbee452be ("hwmon: (ina2xx) Fix various overflow issues") Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-07-27hwmon: (pmbus/core) notify on the hwmon device, not the i2c clientVincent Jardin
pmbus_notify() calls sysfs_notify() and kobject_uevent() on the i2c client's kobject, but the alarm attributes live on the hwmon class device registered by pmbus_do_probe(). Notifying the parent i2c device is a no-op for both poll(POLLPRI) waiters and udev listeners: the named attribute does not exist on that kobject. Notify the hwmon device instead, so poll() wakes up and "change" uevents fire on the inX_alarm/tempX_alarm attributes when SMBALERT# reports a fault. Fixes: f469bde9afd1 ("hwmon: (pmbus/core) Notify hwmon events") Cc: stable@vger.kernel.org # v6.4+ Signed-off-by: Vincent Jardin <vjardin@free.fr> Link: https://lore.kernel.org/r/20260723-fix_hwmon_notify_v1-v1-1-5a24c528686d@free.fr Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-07-27hwmon: (nct6775-core) Fix number of temperature registers for NCT6116Guenter Roeck
Unlike NCT6106, NCT6116 only has three temperature registers, and with it only three temperature source and temperature source configuration registers. The register addresses match those of NCT6106 and can be re-used. The code used a separate array to list the temperature source registers for NCT6116, but used the size of the NCT6106 register array to set the number of registers. The NCT6106 register array provides six addresses, while the temperature source register array for NCT6116 only provides three addresses. This causes a KASAN report. BUG: KASAN: global-out-of-bounds in nct6775_probe+0x936/0x46f0 [nct6775] Read of size 2 at addr ffffffffc19561a6 by task modprobe/954 ... Call Trace: dump_stack+0x7d/0xa7 print_address_description.constprop.0+0x1c/0x220 ? __kasan_kmalloc.constprop.0+0xc9/0xd0 ? __kmalloc_node_track_caller+0x194/0x5b0 ? nct6775_probe+0x936/0x46f0 [nct6775] ? nct6775_probe+0x936/0x46f0 [nct6775] ... Fix the problem by hard-coding the number of temperature and temperature configuration registers to three for NCT6116. Drop the unnecessary NCT6116_REG_TEMP_SOURCE array and re-use NCT6106_REG_TEMP_SOURCE. Reported-by: Florian Bezdeka <florian.bezdeka@siemens.com> Closes: https://lore.kernel.org/linux-hwmon/57cfc3fa-d4e9-4c10-8aa7-4ad0af7ebebe@roeck-us.net/T/#t Fixes: 29c7cb485b32 ("hwmon: (nct6775) Integrate new model nct6116") Cc: Björn Gerhart <gerhart@posteo.de> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2026-07-27dt-bindings: power: supply: max17042: Allow generic power-supply propertiesVincent Cloutier
The MAX17042 family binding references the generic power-supply schema, but additionalProperties only recognizes properties declared directly by this schema. Use unevaluatedProperties so generic properties such as monitored-battery are accepted while unknown properties remain rejected. Remove the local power-supplies declaration because it is already inherited from power-supply.yaml. Assisted-by: OpenCode:gpt-5.6-sol Signed-off-by: Vincent Cloutier <vincent@cloutier.co> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260727011319.621794-12-vincent.cloutier@icloud.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-07-27power: supply: max17042_battery: Honor MAX17055 charge voltageVincent Cloutier
MAX17055 ModelCfg.VChg selects the charge-voltage range used by EZ Config. Consume voltage-max-design-microvolt from monitored-battery and set VChg only when the value is strictly greater than 4.275 V. Reject an explicit zero voltage and preserve the register when the property is absent. Update only the VChg bit and verify its read-back so unrelated ModelCfg fields remain intact. Treat a VChg-only override as an accumulator change: read effective DesignCap and dQAcc, derive and verify the matching dPAcc, then request model refresh. This keeps voltage-only firmware descriptions coherent with the selected charge-voltage range. Assisted-by: OpenCode:gpt-5.6-sol Signed-off-by: Vincent Cloutier <vincent@cloutier.co> Link: https://patch.msgid.link/20260727011319.621794-11-vincent.cloutier@icloud.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-07-27power: supply: max17042_battery: Initialize MAX17055 from battery infoVincent Cloutier
Use charge-full-design-microamp-hours and charge-term-current-microamp from monitored-battery to prepare MAX17055 DesignCap, IChgTerm, and EZ Config dQAcc values in the power-supply registration callback. Apply positive battery values and treat zero like an absent property. Validate all supplied positive values before changing the sparse configuration. Reject values that quantize to zero, capacities that cannot produce dQAcc, and termination currents outside the signed register range. Limit this path to MAX17055 because the other supported gauges require complete characterization data. Assisted-by: OpenCode:gpt-5.6-sol Signed-off-by: Vincent Cloutier <vincent@cloutier.co> Link: https://patch.msgid.link/20260727011319.621794-10-vincent.cloutier@icloud.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-07-27power: supply: max17042_battery: Follow MAX17055 POR sequenceVincent Cloutier
Wait until the MAX17055 is ready, leave hibernate around EZ Config, and wait for ModelCfg.Refresh to clear as required by the power-on reset initialization flow. Restore HibCfg on every exit path. Keep failed restoration state so a retry restores hibernate before starting a new initialization transaction. Assisted-by: OpenCode:gpt-5.6-sol Signed-off-by: Vincent Cloutier <vincent@cloutier.co> Link: https://patch.msgid.link/20260727011319.621794-9-vincent.cloutier@icloud.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-07-27power: supply: max17042_battery: Program MAX17055 EZ Config valuesVincent Cloutier
MAX17055 EZ Config requires DesignCap, dQAcc, IChgTerm, and dPAcc to be programmed coherently. Write each supplied stable register once, wait 1 ms, and verify its read-back instead of relying on the unchecked generic POR override path. Derive dPAcc from the effective DesignCap, dQAcc, and ModelCfg values so the accumulator matches the selected charge-voltage range. Propagate all read, write, verification, and range errors to the retrying init worker. Assisted-by: OpenCode:gpt-5.6-sol Signed-off-by: Vincent Cloutier <vincent@cloutier.co> Link: https://patch.msgid.link/20260727011319.621794-8-vincent.cloutier@icloud.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-07-27power: supply: max17042_battery: Retry failed MAX17055 initializationVincent Cloutier
MAX17055 initialization can fail on register I/O. Propagate the ModelCfg Refresh command error and retry MAX17055 failures every 10 seconds so a transient startup error does not become permanent. Report failures for the other gauges without changing their one-shot behavior. Notify consumers whenever initialization succeeds, including on the first attempt. The core registration notification is deferred and can observe -EAGAIN while asynchronous gauge initialization is still running, so a new notification is needed when driver-backed properties become available. Assisted-by: OpenCode:gpt-5.6-sol Signed-off-by: Vincent Cloutier <vincent@cloutier.co> Link: https://patch.msgid.link/20260727011319.621794-7-vincent.cloutier@icloud.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-07-27power: supply: max17042_battery: Propagate status register errorsVincent Cloutier
The driver ignores errors from the initial STATUS read and final POR clear. A failed read can leave the POR decision based on an invalid value, while a failed clear can report initialization complete with POR still set. Check the probe-time read and return the POR-clear result from max17042_init_chip(). Keep this error handling separate from the retry policy added later. Assisted-by: OpenCode:gpt-5.6-sol Signed-off-by: Vincent Cloutier <vincent@cloutier.co> Link: https://patch.msgid.link/20260727011319.621794-6-vincent.cloutier@icloud.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-07-27power: supply: max17042_battery: Convert initialization to delayed workVincent Cloutier
Periodic MAX17055 retries need a delayed work item. Convert the existing initialization work in advance without adding retries or changing when the first attempt runs. Use schedule_delayed_work() with a zero delay so the work continues to run on system_wq, matching schedule_work() rather than introducing a separate workqueue policy change. Assisted-by: OpenCode:gpt-5.6-sol Signed-off-by: Vincent Cloutier <vincent@cloutier.co> Link: https://patch.msgid.link/20260727011319.621794-5-vincent.cloutier@icloud.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-07-27power: supply: max17042_battery: Use bool for init_completeVincent Cloutier
init_complete is a binary state. Change it from int to bool before adding retry support. The initialization worker and probe path update the flag while property reads sample it. Use READ_ONCE() and WRITE_ONCE() to make those lockless accesses explicit. Assisted-by: OpenCode:gpt-5.6-sol Signed-off-by: Vincent Cloutier <vincent@cloutier.co> Link: https://patch.msgid.link/20260727011319.621794-4-vincent.cloutier@icloud.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-07-27power: supply: max17042_battery: Separate MAX17055 initializationVincent Cloutier
MAX17055 uses ModelCfg.Refresh instead of the characterization-data flow used by the other supported gauges. Move its existing initialization steps into a dedicated helper without changing behavior. This isolates the chip-specific path for subsequent EZ Config changes. Assisted-by: OpenCode:gpt-5.6-sol Signed-off-by: Vincent Cloutier <vincent@cloutier.co> Link: https://patch.msgid.link/20260727011319.621794-3-vincent.cloutier@icloud.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-07-27power: supply: Add registration init callbackVincent Cloutier
Some battery drivers need to consume monitored-battery data before their power_supply is visible. That lets them prepare hardware configuration from parsed battery information without racing userspace exposure. power_supply_get_battery_info() already runs in __power_supply_register() for battery devices before device_add(). Add an optional descriptor init callback after driver data and battery info are available. The callback runs in sleepable process context while the power supply is still unpublished. Keep the callback synchronous: it must not publish changes or start asynchronous activity that can access the power supply before registration completes. Require callbacks to return zero or a negative errno. Defensively reject positive returns so registration cannot return an invalid error pointer. Assisted-by: OpenCode:gpt-5.6-sol Signed-off-by: Vincent Cloutier <vincent@cloutier.co> Link: https://patch.msgid.link/20260727011319.621794-2-vincent.cloutier@icloud.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-07-27spi: spi-cadence: Move TX FIFO full busy-wait into FIFOSrikanth Boyapally
SPI host transfers could intermittently stall with spi_transfer timeouts. The TXFULL condition was checked only once in cdns_transfer_one() before cdns_spi_process_fifo(), so if the FIFO became full again during refill, writes could be dropped and the transfer would never complete. Move the TXFULL busy-wait into the TX path of cdns_spi_process_fifo() so the 10µs back-off is applied per FIFO entry during filling, ensuring forward progress and eliminating spurious timeouts. Restrict the delay to host mode using spi_controller_is_target(), the controller is passed into cdns_spi_process_fifo() so the check is made at the point of use. In target mode this delay must not run as it causes the target to miss its transfer window and corrupt data. Fixes: 49530e641178 ("spi: cadence: Add usleep_range() for cdns_spi_fill_tx_fifo()") Signed-off-by: Srikanth Boyapally <srikanth.boyapally@amd.com> Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com> Link: https://patch.msgid.link/20260720125510.60166-1-srikanth.boyapally@amd.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-27ASoC: ti: omap-twl4030: drop support for platform dataMark Brown
Dmitry Torokhov <dmitry.torokhov@gmail.com> says: (nothing) Link: https://patch.msgid.link/20260724233432.31325-1-dmitry.torokhov@gmail.com
2026-07-27ASoC: ti: omap-twl4030: use per-device instance of headset jack gpioDmitry Torokhov
hs_jack_gpios is being potentially shared among several instances of the same device, and is being modified. This is not the best approach to structuring the code (even if the device is in fact a singleton). Change it to allocate a per-device instance. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Acked-by: Jarkko Nikula <jarkko.nikula@bitmer.com> Link: https://patch.msgid.link/20260724233432.31325-2-dmitry.torokhov@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-27ASoC: ti: omap-twl4030: drop support for platform dataDmitry Torokhov
There are no users of omap_tw4030_pdata in the mainline kernel so remove support for it from the driver. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Acked-by: Jarkko Nikula <jarkko.nikula@bitmer.com> Link: https://patch.msgid.link/20260724233432.31325-1-dmitry.torokhov@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-27ASoC: tas2781: Use correct calibration data for SINEGAIN2 registerwangdicheng
The SINEGAIN2_REG case in cali_reg_update() references t->sin_gn[] rather than t->sin_gn2[], causing the second pilot tone gain calibration to be programmed with the wrong register address. These are distinct fields in struct fct_param_address and are populated from separate firmware parameters by the parser in tas2781-fmwlib.c. Fixes: 84d6a465f211 ("ASoC: tas2781: Support dsp firmware Alpha and Beta seaies") Signed-off-by: wangdicheng <wangdicheng@kylinos.cn> Link: https://patch.msgid.link/20260720081616.631413-1-wangdich9700@163.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-27ASoC: Fix races on creation of SDCA jack detectionMark Brown
Charles Keepax <ckeepax@opensource.cirrus.com> says: Currently there exists a couple races that can result in the DAPM graph coming up in a state that doesn't match the hardware with respect to SDCA jack detection. This series fixes these up by adding a component level fixup_controls helper into the asoc core and shuffling around the IRQ requests from the SDCA side. The core creates DAPM widgets/routes quite a long time before it creates the associated ALSA control, and the jack detection IRQ is currently registered in component probe. At the time of component probe, the DAPM widgets exist, shortly after this the DAPM routes are added. At the time the DAPM routes are added the register value for the control is checked and the appropriate path is connected. The existing handling in the SDCA jack IRQ handles the case the control doesn't exist and updates the registers directly, which works until the DAPM routes are added. After the routes are added the DAPM graph has already set connected on a particular DAPM path, which will not be updated until an IRQ is received when the control is present. Thus those updates are usually not reflected in the resulting DAPM graph which can lead to the audio path being erroneously powered on/off. Link: https://patch.msgid.link/20260721143636.361814-1-ckeepax@opensource.cirrus.com
2026-07-27ASoC: SDCA: Move kcontrol search out of IRQCharles Keepax
Now that the IRQs are always registered after all the ALSA controls are created it is possible to search for the control at the point the IRQ is requested. Move the control search out of the IRQ handler and do it at IRQ request time. This also fixes a potential issue when the card was torn down and reprobed without destroying the codec device, the kctl pointer stored by the IRQ handler would not be updated to the new control on the second probe. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20260721143636.361814-8-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-27ASoC: SDCA: Switch to fixup_controls callback for IRQ registrationCharles Keepax
Currently there are some race conditions around the boot of SDCA jack detection. The core creates DAPM widgets/routes quite a long time before it creates the associated ALSA control, and the jack detection IRQ is currently registered in component probe. At the time of component probe, the DAPM widgets exist, shortly after this the DAPM routes are added. At the time the DAPM routes are added the register value for the control is checked and the appropriate path is connected. The existing handling in the SDCA jack IRQ handles the case the control doesn't exist and updates the registers directly, which works until the DAPM routes are added. After the routes are added the DAPM graph has already set connected on a particular DAPM path, which will not be updated until an IRQ is received when the control is present. Thus those updates are usually not reflected in the resulting DAPM graph which can lead to the audio path being erroneously powered on/off. Switch to the new fixup_controls callback to register the IRQs, this is guaranteed to run after all the controls have been created. Which means we can avoid the aforementioned race condition and as a bonus no longer need to concern ourselves with a case where the IRQ handler runs and the ALSA control is unavailable. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20260721143636.361814-7-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-27ASoC: Add a component fixup_controls callbackCharles Keepax
A card level fixup_controls callback was added in: commit df4d27b19b89 ("ASoC: Introduce 'fixup_controls' card method") This allowed the machine driver to take actions after all the card controls have been added. However, there are times when a codec driver would also want to do things like obtain references to controls for later use, which require all the controls to be present. Add a component level fixup_controls callback, echoing the card level option. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20260721143636.361814-6-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-27ASoC: SDCA: Populate IRQ data earlierCharles Keepax
Currently, the IRQ data (attached Entity/Control/etc) is populated as the IRQ is requested. However, this can cause issues as occasionally the setup process wants to access specifics of an IRQ before the IRQ is actually enabled. To facilitate this cache all the IRQ data during sdca_irq_populate_early() and make sdca_irq_populate() simply request the outstanding IRQs. This also has the advantage that sdca_irq_populate() can now just iterate through the IRQ array which is much smaller/faster than going through every Entity in the Function for Controls. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20260721143636.361814-5-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-27ASoC: SDCA: Remove devm from primary IRQ cleanupCharles Keepax
To provide greater flexibility on when the IRQs are requested for client drivers don't use devm for the primary IRQ request/cleanup helper functions. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20260721143636.361814-4-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-27ASoC: SDCA: Add sdca_irq_cleanup_late()Charles Keepax
The SDCA IRQs are split into two groups, those registered at bus probe time (basically just FDL) and those registered at component time. There currently exists only a single cleanup function, if the FDL IRQ is freed at component time, then nothing would re-register it if the component is probed again. But the IRQs depending on a component need to be freed if the card is destroyed so they can't use stale components. Split the clean up into two functions one for the component level and one for the bus level. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20260721143636.361814-3-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-27ASoC: SDCA: Rename sdca_irq_allocate() to include devmCharles Keepax
Make it more clear sdca_irq_allocate() uses devm allocations by adding it into the name. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20260721143636.361814-2-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-27spi: ppc4xx: devm-ify probe and drop manual resource managementRosen Penev
Replace open-coded resource handling with devm helpers: - spi_alloc_host -> devm_spi_alloc_host - of_address_to_resource + ioremap + request_mem_region -> devm_platform_ioremap_resource - request_irq -> devm_request_irq - remove now-unused mapbase/mapsize fields from struct ppc4xx_spi - move of_node_put(opbnp) earlier to simplify error paths - delete the entire error-unwinding goto chain Move devm_platform_ioremap_resource() and platform_get_irq() up in order to avoid doing work if -EPROBE_DEFER is returned. Assisted-by: opencode:big-pickle Signed-off-by: Rosen Penev <rosenp@gmail.com> Link: https://patch.msgid.link/20260720003043.1536358-1-rosenp@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-27spi: oc-tiny: switch to managed controller allocationFan Wu
The controller is allocated with the non-managed spi_alloc_host() while the interrupt is registered with devm_request_irq(). During removal, spi_bitbang_stop() only unregisters the controller; the subsequent spi_controller_put() then frees the controller together with its embedded driver-private devdata, which is the IRQ handler's dev_id. The devm_request_irq() release action (free_irq()), which drains the handler, does not run until after .remove() returns. A late or latched interrupt can therefore reach tiny_spi_irq() and dereference already-freed memory (e.g. hw->base). Switch to devm_spi_alloc_host() so that the devres LIFO order releases the controller only after free_irq() has drained the handler, and drop the now-redundant spi_controller_put() from .remove(). The probe error path is simplified to direct returns. This issue was found by an in-house static analysis tool. Fixes: ce792580ea2c ("spi: add OpenCores tiny SPI driver") Assisted-by: Codex:gpt-5.6 Signed-off-by: Fan Wu <fanwu01@zju.edu.cn> Link: https://patch.msgid.link/20260719010014.3163356-1-fanwu01@zju.edu.cn Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-27arm64: dts: qcom: mahua: Add QREF regulator supplies to TCSRQiang Yu
Mahua has a different QREF topology from Glymur. Override the TCSR compatible to qcom,mahua-tcsr in mahua.dtsi, and wire up the required LDO supplies on the CRD board. Unlike the other PCIe controllers, PCIe5 PHY on Mahua gets its refclk from the CXO0 pad directly and requires no QREF clkref_en voting. Hence, point its ref clock at RPMH_CXO_CLK. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260721-tcsr_qre_0721-v10-7-d2fa68c63b78@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-27arm64: dts: qcom: glymur: Add QREF regulator supplies to TCSRQiang Yu
The TCSR clkref_en clocks gate the QREF block which provides reference clocks to the PCIe PHYs. Wire up the LDO supplies required by the QREF and refgen blocks on the CRD board. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260721-tcsr_qre_0721-v10-6-d2fa68c63b78@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-27spi: spi-qpic-snand: Increase ECC strength for large OOB SPI-NAND devicesMd Sadre Alam
Some SPI-NAND devices with large OOB areas require a stronger ECC configuration than the default one provided through firmware description. For example, Macronix devices with a 256-byte OOB area report that 4-bit ECC is insufficient and trigger: nand: WARNING: the ECC used on your system is too weak compared to the one required by the NAND chip The QPIC SPI-NAND controller supports both 4-bit and 8-bit BCH ECC modes. When a device exposes an OOB area of at least 128 bytes, there is sufficient space to accommodate 8-bit ECC without exceeding the OOB layout constraints. Automatically increase the ECC strength to 8 bits when the detected OOB size is 128 bytes or larger and the current configuration requests a weaker ECC level. This avoids ECC capability mismatches on devices that require stronger error correction and improves reliability. Signed-off-by: Md Sadre Alam <md.alam@oss.qualcomm.com> Link: https://patch.msgid.link/20260716-8bitecc-v1-1-6eef4bcc3a14@oss.qualcomm.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-27spi: dt-bindings: qcom,sa8255p-geni-spi: Add compatible for Nord SA8797PShawn Guo
Document Nord SA8797P QUP GENI SPI controller, which is compatible with SA8255P controller. Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260714120226.1788391-1-shengchao.guo@oss.qualcomm.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-27ASoC: dt-bindings: qcom,sm8250: Add Hawi sound cardMark Brown
Prasad Kumpatla <prasad.kumpatla@oss.qualcomm.com> says: This series add support for sound card on Qualcomm Hawi boards. Link: https://patch.msgid.link/20260713180907.874954-1-prasad.kumpatla@oss.qualcomm.com
2026-07-27ASoC: qcom: sc8280xp: Add support for HawiPrasad Kumpatla
Add compatible for sound card on Qualcomm Hawi platform. Signed-off-by: Prasad Kumpatla <prasad.kumpatla@oss.qualcomm.com> Link: https://patch.msgid.link/20260713180907.874954-3-prasad.kumpatla@oss.qualcomm.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-27ASoC: dt-bindings: qcom,sm8250: Add Hawi sound cardPrasad Kumpatla
Add bindings for Hawi sound card, which is compatible with the existing SM8450. Signed-off-by: Prasad Kumpatla <prasad.kumpatla@oss.qualcomm.com> Link: https://patch.msgid.link/20260713180907.874954-2-prasad.kumpatla@oss.qualcomm.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-27clk: mediatek: mt6735: Unregister PLLs on probe failureMyeonghun Pak
mtk_clk_register_plls() registers the apmixedsys PLL clocks manually, while clk_mt6735_apmixed_remove() unregisters them on driver removal. If devm_of_clk_add_hw_provider() fails after the PLL registration succeeds, probe returns the error directly and the remove callback is not run. This leaves the registered PLL clocks behind on the probe failure path. Unregister the PLLs in that failure branch before returning the error. Fixes: 43c04ed79189 ("clk: mediatek: Add drivers for MediaTek MT6735 main clock and reset drivers") Co-developed-by: Ijae Kim <ae878000@gmail.com> Signed-off-by: Ijae Kim <ae878000@gmail.com> Signed-off-by: Myeonghun Pak <mhun512@gmail.com> Reviewed-by: Brian Masney <bmasney@redhat.com> Signed-off-by: Brian Masney <bmasney@redhat.com>
2026-07-27ublk: reset kernel-owned dev_info fields in ublk_ctrl_add_dev()Ming Lei
ublk_ctrl_add_dev() memcpy()s the userspace ublksrv_ctrl_dev_info into ub->dev_info and then fixes up the fields the driver owns, but misses ->state and ->ublksrv_pid. A device added with ->state = UBLK_S_DEV_LIVE passes the "->state != UBLK_S_DEV_DEAD" test that ublk_stop_dev_unlocked() uses as its proxy for "a disk is attached", while ->ub_disk is still NULL, so DEL_DEV right after ADD_DEV oopses in del_gendisk(). UBLK_S_DEV_QUIESCED plus UBLK_F_USER_RECOVERY dies one step earlier, in ublk_force_abort_dev(). A poisoned ->state also gets START_USER_RECOVERY and the char device read/write path onto a device that was never started, and wedges START_DEV at -EEXIST. A poisoned ->ublksrv_pid just makes GET_DEV_INFO report an unrelated task as the ublk server. Reset both after the memcpy(), as ublk_detach_disk() does. Userspace only ever reads these back, so correcting them silently breaks nothing. ADD_DEV has copied ->state in unsanitized since ublk was merged, but back then it was harmless: the gendisk was allocated during ADD_DEV, and both teardown and the START_DEV -EEXIST check keyed off disk_live() rather than ->state. The oops became reachable once the disk allocation moved to START_DEV and those checks switched to ->state. Fixes: 6d9e6dfdf3b2 ("ublk: defer disk allocation") Cc: stable@vger.kernel.org Signed-off-by: Ming Lei <tom.leiming@gmail.com> Reviewed-by: Caleb Sander Mateos <csander@purestorage.com> Link: https://patch.msgid.link/20260726145025.1507383-1-tom.leiming@gmail.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-07-27ASoC: atmel: atmel_wm8904: use dev in atmel_asoc_wm8904_dt_init()Kuninori Morimoto
atmel_asoc_wm8904_dt_init() will be updated when Card capsuling. To makes its review easy, use dev in this function and reduce un-related diff. No functional change, but is preparation for cleanup driver. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://patch.msgid.link/878q75jfny.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-27arm64: dts: imx8ulp-evk: Update rpmsg resource table addressBiwen Li
The MCU firmware copies the rsc table to a fixed address (0x1FFF8000) at startup. However, this address is occupied by variables used in the MCU firmware, so copying the rsc table there corrupts those variables. Move the rsc-table reserved memory region from 0x1FFF8000 to 0x20000000 to avoid the conflict. The M33 firmware linker script has been updated accordingly to place the rpmsg resource table at 0x20000000 (DTCM m_rsc_tbl region). Signed-off-by: Biwen Li <biwen.li@nxp.com> Signed-off-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-07-27arm64: dts: imx943-evk: Add CM7 and CM33S nodesPeng Fan
Add remoteproc nodes for the two Cortex-M7 cores (CM7-0, CM7-1) and the Cortex-M33S core, along with their respective reserved memory regions for firmware, virtio device vrings, resource tables and shared DMA pools. Enable the MU11, MU13 and MU15 mailbox units used for inter-processor communication with each remote processor. Signed-off-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-07-27arm64: dts: imx952-evk: Add CM7 node and related memory nodesPeng Fan
Add remoteproc CM7 node and reserved memory regions to enable the Cortex-M7 remote processor. The reserved memory includes firmware memory, virtio device vring buffers and a resource table for inter-processor communication via the MU7 mailbox. Signed-off-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-07-27arm64: dts: imx95-19x19-evk: Add CM7 node and related memory nodesPeng Fan
Add remoteproc CM7 node and reserved memory regions to enable the Cortex-M7 remote processor. The reserved memory includes firmware memory, virtio device vring buffers, a resource table and a shared DMA pool for inter-processor communication via the MU7 mailbox. Signed-off-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-07-27arm64: dts: imx8qm-var-som-symphony: enable expansion header UARTStefano Radaelli
Enable LPUART4 and configure its pin multiplexing to expose the UART interface on the Symphony expansion header. Signed-off-by: Stefano Radaelli <stefano.r@variscite.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-07-27KVM: guest_memfd: Make private exactly what can be mapped on page faultSean Christopherson
When calling into arch code to make the underlying memory private, i.e. to assign memory to the VM in SNP's RMP table, assign/convert *exactly* the range of memory that can be mapped into the guest for the current page fault, instead of aggressively converting/assigning the entire folio. For SNP, the mapping size in the stage-2 page tables (Nested Page Tables, NPT) must be at least the size of the corresponding RMP entry, e.g. assigning a 2MiB mapping in the RMP when it can only be mapped at 4KiB granualarity will ultimate result in another page fault (#NPF for SNP) to "smash" the RMP down to the correct mapping size. Assigning the entire folio was necessary back when guest_memfd tracked preparedness, which was done on a per-folio basis. At the time, it made sense to do per-folio tracking/preparation, because tracking per-folio meant guest_memfd didn't need to add a separate data structure to track that information, and doing per-folio tracking only works if the entire folio is prepared (or not). Now that guest_memfd no longer does preparation tracking (see commit 8622ef05709f ("KVM: guest_memfd: Remove preparation tracking")), in favor having SNP query the RMP, per-folio preparation, i.e. per-folio conversions to private, doesn't make any sense. *If* SNP allowed the RMP size to be greater than the NPT size, then per-folio conversion could theoretically provide marginal value, as it would allow KVM to assign a hugepage in the RMP even if it can only be mapped into the NPT with a smaller page, e.g. because of memslot alignment. The documentation of that reasoning would be something like this: /* * If the memory is private from KVM's perspective, and hardware tracks * VM-assigned private memory in a dedicated data structure, i.e. not * in the stage-2 page tables, then call into arch code to assign the * entire folio to the guest. Assigning the entire folio, e.g. instead * of only the memory being mapped into the guest, allows KVM to assign * an entire hugepage of memory in the out-of-band structure even if * KVM can only map a smaller page size into the MMU, e.g. because the * gmem hugepage is spread across multiple memslots. */ But even *if* a future SNP implementation supported that behavior, the value added would be dubious, as having a huge folio that is fully private, but can only be mapped at a smaller granularity, would be rare. E.g. maybe for memory at the top of lower DRAM that has holes for non-RAM assets? So, convert/assign exactly what guest_memfd allows the caller to map to simplify the guest_memfd code and provide a (super) minor performance optimization for SNP. E.g. once hugepage support comes along, guest_memfd will only need a single flow to compute "how much memory can be assigned and at what size". Reviewed-by: Ackerley Tng <ackerleytng@google.com> Link: https://patch.msgid.link/20260723210811.72720-10-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-27KVM: guest_memfd: Explicitly pass number of pages to make_private() hookSean Christopherson
Tweak the guest_memfd make_private() hook to explicitly pass the number of pages to align with the signature of the make_shared() hook, and because the existing code is outright broken if a guest_memfd folio is comprised of more than one page (which can't happen, yet). The SNP code *tries* to create a corresponding huge entry, but if the RMP must use 4KiB entries for whatever reason, KVM will only convert the first pfn, and not the entire range of pfns that will be mapped into the guest. Alternatively, @max_order could simply be repurposed as _the_ @order, but that will fall apart when in-place conversion comes along, at which point KVM will need to deal with conversions that aren't bound 1:1 to a folio. I.e. the number of pages to convert may not be exactly a power-of-2 (and folios don't strictly guarantee power-of-2 pages anyways). WARN in the SNP code if the number of pages to prepare is anything other than '1', i.e. if guest_memfd is trying to prepare/convert more than a single 4KiB page, as sev_gmem_prepare() doesn't actually handle conversion greater than order-0 folios. Opportunistically swap the ordering of @pfn and @gfn params for kvm_x86_ops.gmem_make_private() to match kvm_arch_gmem_make_private(). Fixes: b85524314a3d ("KVM: guest_memfd: delay kvm_gmem_prepare_folio() until the memory is passed to the guest") Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Reviewed-by: Ackerley Tng <ackerleytng@google.com> Link: https://patch.msgid.link/20260723210811.72720-9-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
2026-07-27KVM: guest_memfd: Rename prepare() hook and Kconfig to make_private() / CONVERTSean Christopherson
Rework guest_memfd's prepare() hook into a more accurate make_private(), and rework its Kconfig from PREPARE to a more generic CONVERT. This will allow x86 to share (pun intended) a kvm_x86_ops.gmem_make_shared() hook between the "convert to shared" and "reclaim" flows, which are one and the same for SNP. No functional change intended. Reviewed-by: Ackerley Tng <ackerleytng@google.com> Reviewed-by: Fuad Tabba <fuad.tabba@linux.dev> Link: https://patch.msgid.link/20260723210811.72720-8-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>