summaryrefslogtreecommitdiff
path: root/drivers/i2c
AgeCommit message (Collapse)AuthorFilesLines
2023-08-03i2c: nomadik: Remove a useless call in the remove functionChristophe JAILLET1-2/+0
[ Upstream commit 05f933d5f7318b03ff2028c1704dc867ac16f2c7 ] Since commit 235602146ec9 ("i2c-nomadik: turn the platform driver to an amba driver"), there is no more request_mem_region() call in this driver. So remove the release_mem_region() call from the remove function which is likely a left over. Fixes: 235602146ec9 ("i2c-nomadik: turn the platform driver to an amba driver") Cc: <stable@vger.kernel.org> # v3.6+ Acked-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-08-03i2c: nomadik: Use devm_clk_get_enabled()Andi Shyti1-15/+3
[ Upstream commit 9c7174db4cdd111e10d19eed5c36fd978a14c8a2 ] Replace the pair of functions, devm_clk_get() and clk_prepare_enable(), with a single function devm_clk_get_enabled(). Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Wolfram Sang <wsa@kernel.org> Stable-dep-of: 05f933d5f731 ("i2c: nomadik: Remove a useless call in the remove function") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-08-03i2c: nomadik: Remove unnecessary goto labelAndi Shyti1-13/+8
[ Upstream commit 1c5d33fff0d375e4ab7c4261dc62a286babbb4c6 ] The err_no_mem goto label doesn't do anything. Remove it. Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Wolfram Sang <wsa@kernel.org> Stable-dep-of: 05f933d5f731 ("i2c: nomadik: Remove a useless call in the remove function") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-08-03i2c: Improve size determinationsMarkus Elfring2-2/+2
[ Upstream commit 06e989578232da33a7fe96b04191b862af8b2cec ] Replace the specification of a data structure by a pointer dereference as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer according to the Linux coding style convention. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Wolfram Sang <wsa@kernel.org> Stable-dep-of: 05f933d5f731 ("i2c: nomadik: Remove a useless call in the remove function") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-08-03i2c: Delete error messages for failed memory allocationsMarkus Elfring4-8/+2
[ Upstream commit 6b3b21a8542fd2fb6ffc61bc13b9419f0c58ebad ] These issues were detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Wolfram Sang <wsa@kernel.org> Stable-dep-of: 05f933d5f731 ("i2c: nomadik: Remove a useless call in the remove function") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19usb: typec: ucsi: Mark dGPUs as DEVICE scopeMario Limonciello2-1/+15
commit a7fbfd44c0204f0629288edfd0d77829edb4a2f8 upstream. power_supply_is_system_supplied() checks whether any power supplies are present that aren't batteries to decide whether the system is running on DC or AC. Downstream drivers use this to make performance decisions. Navi dGPUs include an UCSI function that has been exported since commit 17631e8ca2d3 ("i2c: designware: Add driver support for AMD NAVI GPU"). This UCSI function registers a power supply since commit 992a60ed0d5e ("usb: typec: ucsi: register with power_supply class") but this is not a system power supply. As the power supply for a dGPU is only for powering devices connected to dGPU, create a device property to indicate that the UCSI endpoint is only for the scope of `POWER_SUPPLY_SCOPE_DEVICE`. Link: https://lore.kernel.org/lkml/20230516182541.5836-2-mario.limonciello@amd.com/ Reviewed-by: Evan Quan <evan.quan@amd.com> Tested-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Acked-by: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-07-19i2c: nvidia-gpu: Remove ccgx,firmware-build propertyWayne Chang1-2/+1
commit 430b38764fbb931c6dbd1af13c8b2e4508994662 upstream. Now the Cypress CCG driver has been updated to support the 'firmware-name' property to align with device-tree, remove the 'ccgx,firmware-build' property as this is no longer needed. Signed-off-by: Wayne Chang <waynec@nvidia.com> Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Acked-by: Ajay Gupta <ajayg@nvidia.com> Acked-by: Wolfram Sang <wsa@kernel.org> Link: https://lore.kernel.org/r/20230131175748.256423-5-jonathanh@nvidia.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-07-19i2c: nvidia-gpu: Add ACPI property to align with device-treeWayne Chang1-0/+1
commit f510b0a3565b9231e828e23a7e0f9790b97edf96 upstream. Device-tree uses the 'firmware-name' string property to pass a name of the firmware build to the Cypress CCGx driver. Add a new ACPI string property to the NVIDIA GPU I2C driver to align with device-tree so that we can migrate to using a common property name for both ACPI and device-tree. Signed-off-by: Wayne Chang <waynec@nvidia.com> Co-developed-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Ajay Gupta <ajayg@nvidia.com> Acked-by: Wolfram Sang <wsa@kernel.org> Link: https://lore.kernel.org/r/20230131175748.256423-3-jonathanh@nvidia.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-07-19i2c: qup: Add missing unwind goto in qup_i2c_probe()Shuai Jiang1-7/+14
commit cd9489623c29aa2f8cc07088168afb6e0d5ef06d upstream. Smatch Warns: drivers/i2c/busses/i2c-qup.c:1784 qup_i2c_probe() warn: missing unwind goto? The goto label "fail_runtime" and "fail" will disable qup->pclk, but here qup->pclk failed to obtain, in order to be consistent, change the direct return to goto label "fail_dma". Fixes: 9cedf3b2f099 ("i2c: qup: Add bam dma capabilities") Signed-off-by: Shuai Jiang <d202180596@hust.edu.cn> Reviewed-by: Dongliang Mu <dzm91@hust.edu.cn> Reviewed-by: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Wolfram Sang <wsa@kernel.org> Cc: <stable@vger.kernel.org> # v4.6+ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-07-19i2c: xiic: Don't try to handle more interrupt events after errorRobert Hancock1-0/+2
[ Upstream commit cb6e45c9a0ad9e0f8664fd06db0227d185dc76ab ] In xiic_process, it is possible that error events such as arbitration lost or TX error can be raised in conjunction with other interrupt flags such as TX FIFO empty or bus not busy. Error events result in the controller being reset and the error returned to the calling request, but the function could potentially try to keep handling the other events, such as by writing more messages into the TX FIFO. Since the transaction has already failed, this is not helpful and will just cause issues. This problem has been present ever since: commit 7f9906bd7f72 ("i2c: xiic: Service all interrupts in isr") which allowed non-error events to be handled after errors, but became more obvious after: commit 743e227a8959 ("i2c: xiic: Defer xiic_wakeup() and __xiic_start_xfer() in xiic_process()") which reworked the code to add a WARN_ON which triggers if both the xfer_more and wakeup_req flags were set, since this combination is not supposed to happen, but was occurring in this scenario. Skip further interrupt handling after error flags are detected to avoid this problem. Fixes: 7f9906bd7f72 ("i2c: xiic: Service all interrupts in isr") Signed-off-by: Robert Hancock <robert.hancock@calian.com> Acked-by: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-06-28i2c: imx-lpi2c: fix type char overflow issue when calculating the clock cycleClark Wang1-2/+2
[ Upstream commit e69b9bc170c6d93ee375a5cbfd15f74c0fb59bdd ] Claim clkhi and clklo as integer type to avoid possible calculation errors caused by data overflow. Fixes: a55fa9d0e42e ("i2c: imx-lpi2c: add low power i2c bus driver") Signed-off-by: Clark Wang <xiaoning.wang@nxp.com> Signed-off-by: Carlos Song <carlos.song@nxp.com> Reviewed-by: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-06-28i2c: mchp-pci1xxxx: Avoid cast to incompatible function typeSimon Horman1-2/+4
[ Upstream commit 7ebfd881abe9e0ea9557b29dab6aa28d294fabb4 ] Rather than casting pci1xxxx_i2c_shutdown to an incompatible function type, update the type to match that expected by __devm_add_action. Reported by clang-16 with W-1: .../i2c-mchp-pci1xxxx.c:1159:29: error: cast from 'void (*)(struct pci1xxxx_i2c *)' to 'void (*)(void *)' converts to incompatible function type [-Werror,-Wcast-function-type-strict] ret = devm_add_action(dev, (void (*)(void *))pci1xxxx_i2c_shutdown, i2c); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./include/linux/device.h:251:29: note: expanded from macro 'devm_add_action' __devm_add_action(release, action, data, #action) ^~~~~~ No functional change intended. Compile tested only. Signed-off-by: Simon Horman <horms@kernel.org> Reviewed-by: Horatiu Vultur <horatiu.vultur@microchip.com> Reviewed-by: Andi Shyti <andi.shyti@kernel.org> Reviewed-by: Tharun Kumar P<tharunkumar.pasumarthi@microchip.com> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-06-14i2c: sprd: Delete i2c adapter in .remove's error pathUwe Kleine-König1-3/+5
[ Upstream commit ca0aa17f2db3468fd017038d23a78e17388e2f67 ] If pm runtime resume fails the .remove callback used to exit early. This resulted in an error message by the driver core but the device gets removed anyhow. This lets the registered i2c adapter stay around with an unbound parent device. So only skip clk disabling if resume failed, but do delete the adapter. Fixes: 8b9ec0719834 ("i2c: Add Spreadtrum I2C controller driver") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-06-14i2c: mv64xxx: Fix reading invalid status value in atomic modeMarek Behún1-0/+11
[ Upstream commit 5578d0a79b6430fa1543640dd6f2d397d0886ce7 ] There seems to be a bug within the mv64xxx I2C controller, wherein the status register may not necessarily contain valid value immediately after the IFLG flag is set in the control register. My theory is that the controller: - first sets the IFLG in control register - then updates the status register - then raises an interrupt This may sometime cause weird bugs when in atomic mode, since in this mode we do not wait for an interrupt, but instead we poll the control register for IFLG and read status register immediately after. I encountered -ENXIO from mv64xxx_i2c_fsm() due to this issue when using this driver in atomic mode. Note that I've only seen this issue on Armada 385, I don't know whether other SOCs with this controller are also affected. Also note that this fix has been in U-Boot for over 4 years [1] without anybody complaining, so it should not cause regressions. [1] https://source.denx.de/u-boot/u-boot/-/commit/d50e29662f78 Fixes: 544a8d75f3d6 ("i2c: mv64xxx: Add atomic_xfer method to driver") Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-05-17i2c: tegra: Fix PEC support for SMBUS block readAkhil R1-13/+27
[ Upstream commit 9f855779a3874eee70e9f6be57b5f7774f14e510 ] Update the msg->len value correctly for SMBUS block read. The discrepancy went unnoticed as msg->len is used in SMBUS transfers only when a PEC byte is added. Fixes: d7583c8a5748 ("i2c: tegra: Add SMBus block read function") Signed-off-by: Akhil R <akhilrajeev@nvidia.com> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-05-11i2c: xiic: xiic_xfer(): Fix runtime PM leak on error pathLars-Peter Clausen1-1/+3
[ Upstream commit d663d93bb47e7ab45602b227701022d8aa16040a ] The xiic_xfer() function gets a runtime PM reference when the function is entered. This reference is released when the function is exited. There is currently one error path where the function exits directly, which leads to a leak of the runtime PM reference. Make sure that this error path also releases the runtime PM reference. Fixes: fdacc3c7405d ("i2c: xiic: Switch from waitqueue to completion") Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Reviewed-by: Michal Simek <michal.simek@amd.com> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-05-11i2c: cadence: cdns_i2c_master_xfer(): Fix runtime PM leak on error pathLars-Peter Clausen1-2/+4
[ Upstream commit ae1664f04f504a998737f5bb563f16b44357bcca ] The cdns_i2c_master_xfer() function gets a runtime PM reference when the function is entered. This reference is released when the function is exited. There is currently one error path where the function exits directly, which leads to a leak of the runtime PM reference. Make sure that this error path also releases the runtime PM reference. Fixes: 1a351b10b967 ("i2c: cadence: Added slave support") Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Reviewed-by: Michal Simek <michal.simek@amd.com> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-05-11i2c: omap: Fix standard mode false ACK readingsReid Tonking1-1/+1
commit c770657bd2611b077ec1e7b1fe6aa92f249399bd upstream. Using standard mode, rare false ACK responses were appearing with i2cdetect tool. This was happening due to NACK interrupt triggering ISR thread before register access interrupt was ready. Removing the NACK interrupt's ability to trigger ISR thread lets register access ready interrupt do this instead. Cc: <stable@vger.kernel.org> # v3.7+ Fixes: 3b2f8f82dad7 ("i2c: omap: switch to threaded IRQ support") Signed-off-by: Reid Tonking <reidt@ti.com> Acked-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20i2c: ocores: generate stop condition after timeout in polling modeGregor Herburger1-16/+19
[ Upstream commit f8160d3b35fc94491bb0cb974dbda310ef96c0e2 ] In polling mode, no stop condition is generated after a timeout. This causes SCL to remain low and thereby block the bus. If this happens during a transfer it can cause slaves to misinterpret the subsequent transfer and return wrong values. To solve this, pass the ETIMEDOUT error up from ocores_process_polling() instead of setting STATE_ERROR directly. The caller is adjusted to call ocores_process_timeout() on error both in polling and in IRQ mode, which will set STATE_ERROR and generate a stop condition. Fixes: 69c8c0c0efa8 ("i2c: ocores: add polling interface") Signed-off-by: Gregor Herburger <gregor.herburger@tq-group.com> Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Acked-by: Peter Korsgaard <peter@korsgaard.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Federico Vaga <federico.vaga@cern.ch> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-04-20i2c: mchp-pci1xxxx: Update Timing registersTharun Kumar P1-30/+30
[ Upstream commit aa874cdfec07d4dd9c6f0c356d65c609ba31a26f ] Update I2C timing registers based on latest hardware design. This fix does not break functionality of chips with older design and existing users will not be affected. Fixes: 361693697249 ("i2c: microchip: pci1xxxx: Add driver for I2C host controller in multifunction endpoint of pci1xxxx switch") Signed-off-by: Tharun Kumar P <tharunkumar.pasumarthi@microchip.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-04-20i2c: hisi: Avoid redundant interruptsYicong Yang1-0/+7
[ Upstream commit cc9812a3096d1986caca9a23bee99effc45c08df ] After issuing all the messages we can disable the TX_EMPTY interrupts to avoid handling redundant interrupts. For doing a sinlge bus detection (i2cdetect -y -r 0) we can reduce ~97% interrupts (before ~12000 after ~400). Signed-off-by: Sheng Feng <fengsheng5@huawei.com> Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-04-20i2c: imx-lpi2c: clean rx/tx buffers upon new messageAlexander Stein1-0/+2
[ Upstream commit 987dd36c0141f6ab9f0fbf14d6b2ec3342dedb2f ] When start sending a new message clear the Rx & Tx buffer pointers in order to avoid using stale pointers. Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Tested-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-30i2c: xgene-slimpro: Fix out-of-bounds bug in xgene_slimpro_i2c_xfer()Wei Chen1-0/+3
commit 92fbb6d1296f81f41f65effd7f5f8c0f74943d15 upstream. The data->block[0] variable comes from user and is a number between 0-255. Without proper check, the variable may be very large to cause an out-of-bounds when performing memcpy in slimpro_i2c_blkwr. Fix this bug by checking the value of writelen. Fixes: f6505fbabc42 ("i2c: add SLIMpro I2C device driver on APM X-Gene platform") Signed-off-by: Wei Chen <harperchen1110@gmail.com> Cc: stable@vger.kernel.org Reviewed-by: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-30i2c: hisi: Only use the completion interrupt to finish the transferYicong Yang1-1/+5
[ Upstream commit d98263512684a47e81bcb72a5408958ecd1e60b0 ] The controller will always generate a completion interrupt when the transfer is finished normally or not. Currently we use either error or completion interrupt to finish, this may result the completion interrupt unhandled and corrupt the next transfer, especially at low speed mode. Since on error case, the error interrupt will come first then is the completion interrupt. So only use the completion interrupt to finish the whole transfer process. Fixes: d62fbdb99a85 ("i2c: add support for HiSilicon I2C controller") Reported-by: Sheng Feng <fengsheng5@huawei.com> Signed-off-by: Sheng Feng <fengsheng5@huawei.com> Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-30i2c: mxs: ensure that DMA buffers are safe for DMAMatthias Schiffer1-5/+13
[ Upstream commit 5190417bdf72c71b65bd9892103c6186816a6e8b ] We found that after commit 9c46929e7989 ("ARM: implement THREAD_INFO_IN_TASK for uniprocessor systems"), the PCF85063 RTC driver stopped working on i.MX28 due to regmap_bulk_read() reading bogus data into a stack buffer. This is caused by the i2c-mxs driver using DMA transfers even for messages without the I2C_M_DMA_SAFE flag, and the aforementioned commit enabling vmapped stacks. As the MXS I2C controller requires DMA for reads of >4 bytes, DMA can't be disabled, so the issue is fixed by using i2c_get_dma_safe_msg_buf() to create a bounce buffer when needed. Fixes: 9c46929e7989 ("ARM: implement THREAD_INFO_IN_TASK for uniprocessor systems") Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-30i2c: imx-lpi2c: check only for enabled interrupt flagsAlexander Stein1-0/+4
[ Upstream commit 1c7885004567e8951d65a983be095f254dd20bef ] When reading from I2C, the Tx watermark is set to 0. Unfortunately the TDF (transmit data flag) is enabled when Tx FIFO entries is equal or less than watermark. So it is set in every case, hence the reset default of 1. This results in the MSR_RDF _and_ MSR_TDF flags to be set thus trying to send Tx data on a read message. Mask the IRQ status to filter for wanted flags only. Fixes: a55fa9d0e42e ("i2c: imx-lpi2c: add low power i2c bus driver") Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Tested-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10i2c: designware: fix i2c_dw_clk_rate() return size to be u32Hanna Hawa2-2/+2
[ Upstream commit f2e1fa99550dd7a882229e2c2cd9ecab4ce773d0 ] Make i2c_dw_clk_rate() to return u32 instead of unsigned long, as the function return the value of get_clk_rate_khz() which returns u32. Fixes: b33af11de236 ("i2c: designware: Do not require clock when SSCN and FFCN are provided") Signed-off-by: Hanna Hawa <hhhawa@amazon.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-02-09i2c: rk3x: fix a bunch of kernel-doc warningsRandy Dunlap1-22/+22
[ Upstream commit 0582d984793d30442da88fe458674502bad1ad29 ] Fix multiple W=1 kernel-doc warnings in i2c-rk3x.c: drivers/i2c/busses/i2c-rk3x.c:83: warning: missing initial short description on line: * struct i2c_spec_values: drivers/i2c/busses/i2c-rk3x.c:139: warning: missing initial short description on line: * struct rk3x_i2c_calced_timings: drivers/i2c/busses/i2c-rk3x.c:162: warning: missing initial short description on line: * struct rk3x_i2c_soc_data: drivers/i2c/busses/i2c-rk3x.c:242: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * Generate a START condition, which triggers a REG_INT_START interrupt. drivers/i2c/busses/i2c-rk3x.c:261: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * Generate a STOP condition, which triggers a REG_INT_STOP interrupt. drivers/i2c/busses/i2c-rk3x.c:304: warning: expecting prototype for Setup a read according to i2c(). Prototype was for rk3x_i2c_prepare_read() instead drivers/i2c/busses/i2c-rk3x.c:335: warning: expecting prototype for Fill the transmit buffer with data from i2c(). Prototype was for rk3x_i2c_fill_transmit_buf() instead drivers/i2c/busses/i2c-rk3x.c:535: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * Get timing values of I2C specification drivers/i2c/busses/i2c-rk3x.c:552: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * Calculate divider values for desired SCL frequency drivers/i2c/busses/i2c-rk3x.c:713: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * Calculate timing values for desired SCL frequency drivers/i2c/busses/i2c-rk3x.c:963: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * Setup I2C registers for an I2C operation specified by msgs, num. Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-02-09i2c: mxs: suppress probe-deferral error messageStefan Wahren1-2/+2
[ Upstream commit 78a4471fa1a76a8bef4919105de67660a89a1e9b ] During boot of I2SE Duckbill the kernel log contains a confusing error: Failed to request dma This is caused by i2c-mxs tries to request a not yet available DMA channel (-EPROBE_DEFER). So suppress this message by using dev_err_probe(). Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-02-09i2c: designware-pci: Add new PCI IDs for AMD NAVI GPUBasavaraj Natikar1-0/+2
[ Upstream commit 2ece0930ac5662bccce0ba4c59b84c98d2437200 ] Add additional supported PCI IDs for latest AMD NAVI GPU card which has an integrated Type-C controller and designware I2C with PCI interface. Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com> Tested-by: Sanath S <Sanath.S@amd.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-02-01i2c: designware: Fix unbalanced suspended flagRichard Fitzgerald1-18/+2
[ Upstream commit 75507a319876aba88932e2c7dab58b6c22d89f6b ] Ensure that i2c_mark_adapter_suspended() is always balanced by a call to i2c_mark_adapter_resumed(). dw_i2c_plat_resume() must always be called, so that i2c_mark_adapter_resumed() is called. This is not compatible with DPM_FLAG_MAY_SKIP_RESUME, so remove the flag. Since the controller is always resumed on system resume the dw_i2c_plat_complete() callback is redundant and has been removed. The unbalanced suspended flag was introduced by commit c57813b8b288 ("i2c: designware: Lock the adapter while setting the suspended flag") Before that commit, the system and runtime PM used the same functions. The DPM_FLAG_MAY_SKIP_RESUME was used to skip the system resume if the driver had been in runtime-suspend. If system resume was skipped, the suspended flag would be cleared by the next runtime resume. The check of the suspended flag was _after_ the call to pm_runtime_get_sync() in i2c_dw_xfer(). So either a system resume or a runtime resume would clear the flag before it was checked. Having introduced the unbalanced suspended flag with that commit, a further commit 80704a84a9f8 ("i2c: designware: Use the i2c_mark_adapter_suspended/resumed() helpers") changed from using a local suspended flag to using the i2c_mark_adapter_suspended/resumed() functions. These use a flag that is checked by I2C core code before issuing the transfer to the bus driver, so there was no opportunity for the bus driver to runtime resume itself before the flag check. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Fixes: c57813b8b288 ("i2c: designware: Lock the adapter while setting the suspended flag") Reviewed-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-02-01i2c: designware: use casting of u64 in clock multiplication to avoid overflowLareine Khawaly1-3/+6
[ Upstream commit c8c37bc514514999e62a17e95160ed9ebf75ca8d ] In functions i2c_dw_scl_lcnt() and i2c_dw_scl_hcnt() may have overflow by depending on the values of the given parameters including the ic_clk. For example in our use case where ic_clk is larger than one million, multiplication of ic_clk * 4700 will result in 32 bit overflow. Add cast of u64 to the calculation to avoid multiplication overflow, and use the corresponding define for divide. Fixes: 2373f6b9744d ("i2c-designware: split of i2c-designware.c into core and bus specific parts") Signed-off-by: Lareine Khawaly <lareine@amazon.com> Signed-off-by: Hanna Hawa <hhhawa@amazon.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31i2c: ismt: Fix an out-of-bounds bug in ismt_access()Zheyu Ma1-0/+3
[ Upstream commit 39244cc754829bf707dccd12e2ce37510f5b1f8d ] When the driver does not check the data from the user, the variable 'data->block[0]' may be very large to cause an out-of-bounds bug. The following log can reveal it: [ 33.995542] i2c i2c-1: ioctl, cmd=0x720, arg=0x7ffcb3dc3a20 [ 33.995978] ismt_smbus 0000:00:05.0: I2C_SMBUS_BLOCK_DATA: WRITE [ 33.996475] ================================================================== [ 33.996995] BUG: KASAN: out-of-bounds in ismt_access.cold+0x374/0x214b [ 33.997473] Read of size 18446744073709551615 at addr ffff88810efcfdb1 by task ismt_poc/485 [ 33.999450] Call Trace: [ 34.001849] memcpy+0x20/0x60 [ 34.002077] ismt_access.cold+0x374/0x214b [ 34.003382] __i2c_smbus_xfer+0x44f/0xfb0 [ 34.004007] i2c_smbus_xfer+0x10a/0x390 [ 34.004291] i2cdev_ioctl_smbus+0x2c8/0x710 [ 34.005196] i2cdev_ioctl+0x5ec/0x74c Fix this bug by checking the size of 'data->block[0]' first. Fixes: 13f35ac14cd0 ("i2c: Adding support for Intel iSMT SMBus 2.0 host controller") Signed-off-by: Zheyu Ma <zheyuma97@gmail.com> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31i2c: mux: reg: check return value after calling platform_get_resource()Yang Yingliang1-3/+2
[ Upstream commit 2d47b79d2bd39cc6369eccf94a06568d84c906ae ] It will cause null-ptr-deref in resource_size(), if platform_get_resource() returns NULL, move calling resource_size() after devm_ioremap_resource() that will check 'res' to avoid null-ptr-deref. And use devm_platform_get_and_ioremap_resource() to simplify code. Fixes: b3fdd32799d8 ("i2c: mux: Add register-based mux i2c-mux-reg") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31i2c: pxa-pci: fix missing pci_disable_device() on error in ce4100_i2c_probeHui Tang1-7/+3
[ Upstream commit d78a167332e1ca8113268ed922c1212fd71b73ad ] Using pcim_enable_device() to avoid missing pci_disable_device(). Fixes: 7e94dd154e93 ("i2c-pxa2xx: Add PCI support for PXA I2C controller") Signed-off-by: Hui Tang <tanghui20@huawei.com> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-02i2c: imx: Only DMA messages with I2C_M_DMA_SAFE flag setAndrew Lunn1-2/+4
Recent changes to the DMA code has resulting in the IMX driver failing I2C transfers when the buffer has been vmalloc. Only perform DMA transfers if the message has the I2C_M_DMA_SAFE flag set, indicating the client is providing a buffer which is DMA safe. This is a minimal fix for stable. The I2C core provides helpers to allocate a bounce buffer. For a fuller fix the master should make use of these helpers. Fixes: 4544b9f25e70 ("dma-mapping: Add vmap checks to dma_map_single()") Signed-off-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2022-12-02i2c: qcom-geni: fix error return code in geni_i2c_gpi_xferWang Yufen1-1/+0
Fix to return a negative error code from the gi2c->err instead of 0. Fixes: d8703554f4de ("i2c: qcom-geni: Add support for GPI DMA") Signed-off-by: Wang Yufen <wangyufen@huawei.com> Reviewed-by: Tommaso Merciai <tommaso.merciai@amarulasoluitons.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2022-12-02i2c: cadence: Fix regression with bus recoveryCarsten Haitzler1-3/+8
Commit "i2c: cadence: Add standard bus recovery support" breaks for i2c devices that have no pinctrl defined. There is no requirement for this to exist in the DT. This has worked perfectly well without this before in at least 1 real usage case on hardware (Mali Komeda DPU, Cadence i2c to talk to a tda99xx phy). Adding the requirement to have pinctrl set up in the device tree (or otherwise be found) is a regression where the whole i2c device is lost entirely (in this case dropping entire devices which then leads to the drm display stack unable to find the phy for display output, thus having no drm display device and so on down the chain). This converts the above commit to an enhancement if pinctrl can be found for the i2c device, providing a timeout on read with recovery, but if not, do what used to be done rather than a fatal loss of a device. This restores the mentioned display devices to their working state again. Fixes: 58b924241d0a ("i2c: cadence: Add standard bus recovery support") Signed-off-by: Carsten Haitzler <carsten.haitzler@arm.com> Reviewed-by: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com> Reviewed-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Acked-by: Michal Simek <michal.simek@amd.com> [wsa: added braces to else-branch] Signed-off-by: Wolfram Sang <wsa@kernel.org>
2022-11-14i2c: Restore initial power state if probe failsRicardo Ribalda1-4/+5
A driver that supports I2C_DRV_ACPI_WAIVE_D0_PROBE is not expected to power off a device that it has not powered on previously. For devices operating in "full_power" mode, the first call to `i2c_acpi_waive_d0_probe` will return 0, which means that the device will be turned on with `dev_pm_domain_attach`. If probe fails the second call to `i2c_acpi_waive_d0_probe` will return 1, which means that the device will not be turned off. This is, it will be left in a different power state. Lets fix it. Reviewed-by: Hidenori Kobayashi <hidenorik@chromium.org> Reviewed-by: Sergey Senozhatsky <senozhatsky@chromium.org> Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Cc: stable@vger.kernel.org Fixes: b18c1ad685d9 ("i2c: Allow an ACPI driver to manage the device's power state during probe") Signed-off-by: Ricardo Ribalda <ribalda@chromium.org> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2022-11-12i2c: npcm7xx: Fix error handling in npcm_i2c_init()Yuan Can1-1/+10
A problem about i2c-npcm7xx create debugfs failed is triggered with the following log given: [ 173.827310] debugfs: Directory 'npcm_i2c' with parent '/' already present! The reason is that npcm_i2c_init() returns platform_driver_register() directly without checking its return value, if platform_driver_register() failed, it returns without destroy the newly created debugfs, resulting the debugfs of npcm_i2c can never be created later. npcm_i2c_init() debugfs_create_dir() # create debugfs directory platform_driver_register() driver_register() bus_add_driver() priv = kzalloc(...) # OOM happened # return without destroy debugfs directory Fix by removing debugfs when platform_driver_register() returns error. Fixes: 56a1485b102e ("i2c: npcm7xx: Add Nuvoton NPCM I2C controller driver") Signed-off-by: Yuan Can <yuancan@huawei.com> Reviewed-by: Tali Perry <tali.perry@nuvoton.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2022-11-01i2c: i801: add lis3lv02d's I2C address for Vostro 5568Nam Cao1-0/+1
Dell Vostro 5568 laptop has lis3lv02d, but its i2c address is not known to the kernel. Add this address. Output of "cat /sys/devices/platform/lis3lv02d/position" on Dell Vostro 5568 laptop: - Horizontal: (-18,0,1044) - Front elevated: (522,-18,1080) - Left elevated: (-18,-360,1080) - Upside down: (36,108,-1134) Signed-off-by: Nam Cao <namcaov@gmail.com> Reviewed-by: Jean Delvare <jdelvare@suse.de> Reviewed-by: Pali Rohár <pali@kernel.org> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2022-11-01i2c: tegra: Allocate DMA memory for DMA engineThierry Reding1-6/+10
When the I2C controllers are running in DMA mode, it is the DMA engine that performs the memory accesses rather than the I2C controller. Pass the DMA engine's struct device pointer to the DMA API to make sure the correct DMA operations are used. This fixes an issue where the DMA engine's SMMU stream ID needs to be misleadingly set for the I2C controllers in device tree. Suggested-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2022-11-01i2c: piix4: Fix adapter not be removed in piix4_remove()Chen Zhongjin1-0/+1
In piix4_probe(), the piix4 adapter will be registered in: piix4_probe() piix4_add_adapters_sb800() / piix4_add_adapter() i2c_add_adapter() Based on the probed device type, piix4_add_adapters_sb800() or single piix4_add_adapter() will be called. For the former case, piix4_adapter_count is set as the number of adapters, while for antoher case it is not set and kept default *zero*. When piix4 is removed, piix4_remove() removes the adapters added in piix4_probe(), basing on the piix4_adapter_count value. Because the count is zero for the single adapter case, the adapter won't be removed and makes the sources allocated for adapter leaked, such as the i2c client and device. These sources can still be accessed by i2c or bus and cause problems. An easily reproduced case is that if a new adapter is registered, i2c will get the leaked adapter and try to call smbus_algorithm, which was already freed: Triggered by: rmmod i2c_piix4 && modprobe max31730 BUG: unable to handle page fault for address: ffffffffc053d860 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page Oops: 0000 [#1] PREEMPT SMP KASAN CPU: 0 PID: 3752 Comm: modprobe Tainted: G Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:i2c_default_probe (drivers/i2c/i2c-core-base.c:2259) i2c_core RSP: 0018:ffff888107477710 EFLAGS: 00000246 ... <TASK> i2c_detect (drivers/i2c/i2c-core-base.c:2302) i2c_core __process_new_driver (drivers/i2c/i2c-core-base.c:1336) i2c_core bus_for_each_dev (drivers/base/bus.c:301) i2c_for_each_dev (drivers/i2c/i2c-core-base.c:1823) i2c_core i2c_register_driver (drivers/i2c/i2c-core-base.c:1861) i2c_core do_one_initcall (init/main.c:1296) do_init_module (kernel/module/main.c:2455) ... </TASK> ---[ end trace 0000000000000000 ]--- Fix this problem by correctly set piix4_adapter_count as 1 for the single adapter so it can be normally removed. Fixes: 528d53a1592b ("i2c: piix4: Fix probing of reserved ports on AMD Family 16h Model 30h") Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com> Reviewed-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2022-10-21i2c: mlxbf: depend on ACPI; clean away ifdeffageAdam Borowski2-9/+1
This fixes maybe_unused warnings/errors. According to a comment during device tree removal, only ACPI is supported, thus let's actually require it. Fixes: be18c5ede25d ("i2c: mlxbf: remove device tree support") Signed-off-by: Adam Borowski <kilobyte@angband.pl> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2022-10-21i2c: fix spelling typos in commentsJiangshan Yi2-2/+2
Reported-by: k2ci <kernel-bot@kylinos.cn> Signed-off-by: Jiangshan Yi <yijiangshan@kylinos.cn> Reviewed-by: Jean Delvare <jdelvare@suse.de> # for sis630 Signed-off-by: Wolfram Sang <wsa@kernel.org>
2022-10-19i2c: qcom-cci: Fix ordering of pm_runtime_xx and i2c_add_adapterBryan O'Donoghue1-5/+8
When we compile-in the CCI along with the imx412 driver and run on the RB5 we see that i2c_add_adapter() causes the probe of the imx412 driver to happen. This probe tries to perform an i2c xfer() and the xfer() in i2c-qcom-cci.c fails on pm_runtime_get() because the i2c-qcom-cci.c::probe() function has not completed to pm_runtime_enable(dev). Fix this sequence by ensuring pm_runtime_xxx() calls happen prior to adding the i2c adapter. Fixes: e517526195de ("i2c: Add Qualcomm CCI I2C driver") Reported-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Tested-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Cc: <stable@vger.kernel.org> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Robert Foss <robert.foss@linaro.org> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2022-10-19i2c: xiic: Add platform module aliasMartin Tůma1-0/+1
The missing "platform" alias is required for the mgb4 v4l2 driver to load the i2c controller driver when probing the HW. Signed-off-by: Martin Tůma <martin.tuma@digiteqautomotive.com> Acked-by: Michal Simek <michal.simek@amd.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2022-10-11Merge tag 'i2c-for-6.1-rc1-batch2' of ↵Linus Torvalds5-4/+28
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull more i2c updates from Wolfram Sang: - correct a variable type in the new pci1xxxx driver - add a new SoC to the qcom-cci driver - fix an issue with the designware driver which now got enough testing - the aspeed driver now handles busy target backends better * tag 'i2c-for-6.1-rc1-batch2' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: aspeed: Assert NAK when slave is busy i2c: designware: Fix handling of real but unexpected device interrupts i2c: qcom-cci: Add MSM8226 compatible dt-bindings: i2c: qcom,i2c-cci: Document clocks for MSM8974 dt-bindings: i2c: qcom,i2c-cci: Document MSM8226 compatible i2c: microchip: pci1xxxx: Fix comparison of -EPERM against an unsigned variable
2022-10-10Merge tag 'acpi-6.1-rc1-2' of ↵Linus Torvalds3-13/+37
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull more ACPI updates from Rafael Wysocki: "These fix two issues, in APEI and in the int3472 driver, clean up the ACPI thermal driver, add ACPI support for non-GPE system wakeup events and make the system reboot code use the S5 (system off) state by default. Specifics: - Fix ACPI device object reference counting in (recently updated) skl_int3472_fill_clk_pdata() (Andy Shevchenko). - Fix a memory leak in APEI by avoiding to add a task_work to kernel threads running when an asynchronous error is detected (Shuai Xue). - Add ACPI support for handling system wakeups via GPIO wake capable IRQs in addition to GPEs (Raul E Rangel). - Make the system reboot code put ACPI-enabled systems into the S5 (system off) state which is necessary for some platforms to work as expected (Kai-Heng Feng). - Make the white space usage in the ACPI thermal driver more consistent and drop redundant code from it (Rafael Wysocki)" * tag 'acpi-6.1-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI: thermal: Drop some redundant code ACPI: thermal: Drop redundant parens from expressions ACPI: thermal: Use white space more consistently platform/x86: int3472: Don't leak reference on error ACPI: APEI: do not add task_work to kernel thread to avoid memory leak PM: ACPI: reboot: Reinstate S5 for reboot kernel/reboot: Add SYS_OFF_MODE_RESTART_PREPARE mode ACPI: PM: Take wake IRQ into consideration when entering suspend-to-idle i2c: acpi: Use ACPI wake capability bit to set wake_irq ACPI: resources: Add wake_capable parameter to acpi_dev_irq_flags gpiolib: acpi: Add wake_capable variants of acpi_dev_gpio_irq_get
2022-10-10Merge branches 'acpi-apei', 'acpi-wakeup', 'acpi-reboot' and 'acpi-thermal'Rafael J. Wysocki3-13/+37
Merge additional APEI changes, ACPI updates related to device wakeup and system restart and ACPI thermal driver cleanups for 6.1-rc1: - Fix a memory leak in APEI by avoiding to add do not add task_work to kernel threads running when an asynchronous error is detected (Shuai Xue). - Add ACPI support for handling system wakeups via GPIO wake capable IRQs in addition to GPEs (Raul E Rangel). - Make the system reboot code put ACPI-enabled systems into the S5 (system off) state which is necessary for some platforms to work as expected (Kai-Heng Feng). - Make the white space usage in the ACPI thermal driver more consistent and drop redundant code from it (Rafael Wysocki). * acpi-apei: ACPI: APEI: do not add task_work to kernel thread to avoid memory leak * acpi-wakeup: ACPI: PM: Take wake IRQ into consideration when entering suspend-to-idle i2c: acpi: Use ACPI wake capability bit to set wake_irq ACPI: resources: Add wake_capable parameter to acpi_dev_irq_flags gpiolib: acpi: Add wake_capable variants of acpi_dev_gpio_irq_get * acpi-reboot: PM: ACPI: reboot: Reinstate S5 for reboot kernel/reboot: Add SYS_OFF_MODE_RESTART_PREPARE mode * acpi-thermal: ACPI: thermal: Drop some redundant code ACPI: thermal: Drop redundant parens from expressions ACPI: thermal: Use white space more consistently
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-12 18:40:12 +0300