summaryrefslogtreecommitdiff
path: root/drivers/i2c
AgeCommit message (Collapse)AuthorFilesLines
2022-07-29i2c: cadence: Change large transfer count reset logic to be unconditionalRobert Hancock1-25/+5
[ Upstream commit 4ca8ca873d454635c20d508261bfc0081af75cf8 ] Problems were observed on the Xilinx ZynqMP platform with large I2C reads. When a read of 277 bytes was performed, the controller NAKed the transfer after only 252 bytes were transferred and returned an ENXIO error on the transfer. There is some code in cdns_i2c_master_isr to handle this case by resetting the transfer count in the controller before it reaches 0, to allow larger transfers to work, but it was conditional on the CDNS_I2C_BROKEN_HOLD_BIT quirk being set on the controller, and ZynqMP uses the r1p14 version of the core where this quirk is not being set. The requirement to do this to support larger reads seems like an inherently required workaround due to the core only having an 8-bit transfer size register, so it does not appear that this should be conditional on the broken HOLD bit quirk which is used elsewhere in the driver. Remove the dependency on the CDNS_I2C_BROKEN_HOLD_BIT for this transfer size reset logic to fix this problem. Fixes: 63cab195bf49 ("i2c: removed work arounds in i2c driver for Zynq Ultrascale+ MPSoC") Signed-off-by: Robert Hancock <robert.hancock@calian.com> Reviewed-by: Shubhrajyoti Datta <Shubhrajyoti.datta@amd.com> Acked-by: Michal Simek <michal.simek@amd.com> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-07-12i2c: cadence: Unregister the clk notifier in error pathSatish Nagireddy1-0/+1
[ Upstream commit 3501f0c663063513ad604fb1b3f06af637d3396d ] This patch ensures that the clock notifier is unregistered when driver probe is returning error. Fixes: df8eb5691c48 ("i2c: Add driver for Cadence I2C controller") Signed-off-by: Satish Nagireddy <satish.nagireddy@getcruise.com> Tested-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>
2022-06-14i2c: cadence: Increase timeout per message if necessaryLucas Tanure1-2/+10
[ Upstream commit 96789dce043f5bff8b7d62aa28d52a7c59403a84 ] Timeout as 1 second sets an upper limit on the length of the transfer executed, but there is no maximum length of a write or read message set in i2c_adapter_quirks for this controller. This upper limit affects devices that require sending large firmware blobs over I2C. To remove that limitation, calculate the minimal time necessary, plus some wiggle room, for every message and use it instead of the default one second, if more than one second. Signed-off-by: Lucas Tanure <tanureal@opensource.cirrus.com> Acked-by: Michal Simek <michal.simek@xilinx.com> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-06-06drivers: i2c: thunderx: Allow driver to work with ACPI defined TWSI controllersPiyush Malgujar1-0/+1
[ Upstream commit 03a35bc856ddc09f2cc1f4701adecfbf3b464cb3 ] Due to i2c->adap.dev.fwnode not being set, ACPI_COMPANION() wasn't properly found for TWSI controllers. Signed-off-by: Szymon Balcerak <sbalcerak@marvell.com> Signed-off-by: Piyush Malgujar <pmalgujar@marvell.com> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-20i2c: pasemi: Wait for write xfers to finishMartin Povišer1-0/+6
commit bd8963e602c77adc76dbbbfc3417c3cf14fed76b upstream. Wait for completion of write transfers before returning from the driver. At first sight it may seem advantageous to leave write transfers queued for the controller to carry out on its own time, but there's a couple of issues with it: * Driver doesn't check for FIFO space. * The queued writes can complete while the driver is in its I2C read transfer path which means it will get confused by the raising of XEN (the 'transaction ended' signal). This can cause a spurious ENODATA error due to premature reading of the MRXFIFO register. Adding the wait fixes some unreliability issues with the driver. There's some efficiency cost to it (especially with pasemi_smb_waitready doing its polling), but that will be alleviated once the driver receives interrupt support. Fixes: beb58aa39e6e ("i2c: PA Semi SMBus driver") Signed-off-by: Martin Povišer <povik+lin@cutebit.org> Reviewed-by: Sven Peter <sven@svenpeter.dev> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-20i2c: mux: demux-pinctrl: do not deactivate a master that is not activePeter Rosin1-2/+3
[ Upstream commit 1a22aabf20adf89cb216f566913196128766f25b ] Attempting to rollback the activation of the current master when the current master has not been activated is bad. priv->cur_chan and priv->cur_adap are both still zeroed out and the rollback may result in attempts to revert an of changeset that has not been applied and do result in calls to both del and put the zeroed out i2c_adapter. Maybe it crashes, or whatever, but it's bad in any case. Fixes: e9d1a0a41d44 ("i2c: mux: demux-pinctrl: Fix an error handling path in 'i2c_demux_pinctrl_probe()'") Signed-off-by: Peter Rosin <peda@axentia.se> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-20i2c: xiic: Make bus names uniqueRobert Hancock1-1/+2
[ Upstream commit 1d366c2f9df8279df2adbb60471f86fc40a1c39e ] This driver is for an FPGA logic core, so there can be arbitrarily many instances of the bus on a given system. Previously all of the I2C bus names were "xiic-i2c" which caused issues with lm_sensors when trying to map human-readable names to sensor inputs because it could not properly distinguish the busses, for example. Append the platform device name to the I2C bus name so it is unique between different instances. Fixes: e1d5b6598cdc ("i2c: Add support for Xilinx XPS IIC Bus Interface") Signed-off-by: Robert Hancock <robert.hancock@calian.com> Tested-by: Michal Simek <michal.simek@xilinx.com> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-03-08i2c: qup: allow COMPILE_TESTWolfram Sang1-1/+1
[ Upstream commit 5de717974005fcad2502281e9f82e139ca91f4bb ] Driver builds fine with COMPILE_TEST. Enable it for wider test coverage and easier maintenance. Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-03-08i2c: cadence: allow COMPILE_TESTWolfram Sang1-1/+1
[ Upstream commit 0b0dcb3882c8f08bdeafa03adb4487e104d26050 ] Driver builds fine with COMPILE_TEST. Enable it for wider test coverage and easier maintenance. Signed-off-by: Wolfram Sang <wsa@kernel.org> Acked-by: Michal Simek <michal.simek@xilinx.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-03-08i2c: bcm2835: Avoid clock stretching timeoutsEric Anholt1-0/+11
[ Upstream commit 9495b9b31abe525ebd93da58de2c88b9f66d3a0e ] The CLKT register contains at poweron 0x40, which at our typical 100kHz bus rate means .64ms. But there is no specified limit to how long devices should be able to stretch the clocks, so just disable the timeout. We still have a timeout wrapping the entire transfer. Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> BugLink: https://github.com/raspberrypi/linux/issues/3064 Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-02-23i2c: brcmstb: fix support for DSL and CM variantsRafał Miłecki1-1/+1
commit 834cea3a252ed4847db076a769ad9efe06afe2d5 upstream. DSL and CM (Cable Modem) support 8 B max transfer size and have a custom DT binding for that reason. This driver was checking for a wrong "compatible" however which resulted in an incorrect setup. Fixes: e2e5a2c61837 ("i2c: brcmstb: Adding support for CM and DSL SoCs") Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-01-27i2c: designware-pci: Fix to change data types of hcnt and lcnt parametersLakshmi Sowjanya D1-4/+4
[ Upstream commit d52097010078c1844348dc0e467305e5f90fd317 ] The data type of hcnt and lcnt in the struct dw_i2c_dev is of type u16. It's better to have same data type in struct dw_scl_sda_cfg as well. Reported-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Lakshmi Sowjanya D <lakshmi.sowjanya.d@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-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-01-27i2c: mpc: Correct I2C reset procedureJoakim Tjernlund1-8/+15
[ Upstream commit ebe82cf92cd4825c3029434cabfcd2f1780e64be ] Current I2C reset procedure is broken in two ways: 1) It only generate 1 START instead of 9 STARTs and STOP. 2) It leaves the bus Busy so every I2C xfer after the first fixup calls the reset routine again, for every xfer there after. This fixes both errors. Signed-off-by: Joakim Tjernlund <joakim.tjernlund@infinera.com> Acked-by: Scott Wood <oss@buserror.net> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27i2c: i801: Don't silently correct invalid transfer sizeHeiner Kallweit1-10/+5
[ Upstream commit effa453168a7eeb8a562ff4edc1dbf9067360a61 ] If an invalid block size is provided, reject it instead of silently changing it to a supported value. Especially critical I see the case of a write transfer with block length 0. In this case we have no guarantee that the byte we would write is valid. When silently reducing a read to 32 bytes then we don't return an error and the caller may falsely assume that we returned the full requested data. If this change should break any (broken) caller, then I think we should fix the caller. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-12-22i2c: rk3x: Handle a spurious start completion interrupt flagOndrej Jirman1-2/+2
[ Upstream commit 02fe0fbd8a21e183687925c3a266ae27dda9840f ] In a typical read transfer, start completion flag is being set after read finishes (notice ipd bit 4 being set): trasnfer poll=0 i2c start rk3x-i2c fdd40000.i2c: IRQ: state 1, ipd: 10 i2c read rk3x-i2c fdd40000.i2c: IRQ: state 2, ipd: 1b i2c stop rk3x-i2c fdd40000.i2c: IRQ: state 4, ipd: 33 This causes I2C transfer being aborted in polled mode from a stop completion handler: trasnfer poll=1 i2c start rk3x-i2c fdd40000.i2c: IRQ: state 1, ipd: 10 i2c read rk3x-i2c fdd40000.i2c: IRQ: state 2, ipd: 0 rk3x-i2c fdd40000.i2c: IRQ: state 2, ipd: 1b i2c stop rk3x-i2c fdd40000.i2c: IRQ: state 4, ipd: 13 i2c stop rk3x-i2c fdd40000.i2c: unexpected irq in STOP: 0x10 Clearing the START flag after read fixes the issue without any obvious side effects. This issue was dicovered on RK3566 when adding support for powering off the RK817 PMIC. Signed-off-by: Ondrej Jirman <megous@megous.com> Reviewed-by: John Keeping <john@metanate.com> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-26i2c: xlr: Fix a resource leak in the error handling path of 'xlr_i2c_probe()'Christophe JAILLET1-1/+5
[ Upstream commit 7f98960c046ee1136e7096aee168eda03aef8a5d ] A successful 'clk_prepare()' call should be balanced by a corresponding 'clk_unprepare()' call in the error handling path of the probe, as already done in the remove function. More specifically, 'clk_prepare_enable()' is used, but 'clk_disable()' is also already called. So just the unprepare step has still to be done. Update the error handling path accordingly. Fixes: 75d31c2372e4 ("i2c: xlr: add support for Sigma Designs controller variant") 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>
2021-10-17i2c: acpi: fix resource leak in reconfiguration device additionJamie Iles1-0/+1
[ Upstream commit 6558b646ce1c2a872fe1c2c7cb116f05a2c1950f ] acpi_i2c_find_adapter_by_handle() calls bus_find_device() which takes a reference on the adapter which is never released which will result in a reference count leak and render the adapter unremovable. Make sure to put the adapter after creating the client in the same manner that we do for OF. Fixes: 525e6fabeae2 ("i2c / ACPI: add support for ACPI reconfigure notifications") Signed-off-by: Jamie Iles <quic_jiles@quicinc.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> [wsa: fixed title] Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-22i2c: mt65xx: fix IRQ checkSergey Shtylyov1-1/+1
[ Upstream commit 58fb7c643d346e2364404554f531cfa6a1a3917c ] Iff platform_get_irq() returns 0, the driver's probe() method will return 0 early (as if the method's call was successful). Let's consider IRQ0 valid for simplicity -- devm_request_irq() can always override that decision... Fixes: ce38815d39ea ("I2C: mediatek: Add driver for MediaTek I2C controller") Signed-off-by: Sergey Shtylyov <s.shtylyov@omprussia.ru> Reviewed-by: Qii Wang <qii.wang@mediatek.com> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-22i2c: s3c2410: fix IRQ checkSergey Shtylyov1-1/+1
[ Upstream commit d6840a5e370b7ea4fde16ce2caf431bcc87f9a75 ] Iff platform_get_irq() returns 0, the driver's probe() method will return 0 early (as if the method's call was successful). Let's consider IRQ0 valid for simplicity -- devm_request_irq() can always override that decision... Fixes: e0d1ec97853f ("i2c-s3c2410: Change IRQ to be plain integer.") Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-22i2c: iop3xx: fix deferred probingSergey Shtylyov1-4/+2
[ Upstream commit a1299505162ad00def3573260c2c68b9c8e8d697 ] When adding the code to handle platform_get_irq*() errors in the commit 489447380a29 ("handle errors returned by platform_get_irq*()"), the actual error code was enforced to be -ENXIO in the driver for some strange reason. This didn't matter much until the deferred probing was introduced -- which requires an actual error code to be propagated upstream from the failure site. While fixing this, also stop overriding the errors from request_irq() to -EIO (done since the pre-git era). Fixes: 489447380a29 ("[PATCH] handle errors returned by platform_get_irq*()") Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-22i2c: highlander: add IRQ checkSergey Shtylyov1-1/+1
[ Upstream commit f16a3bb69aa6baabf8f0aca982c8cf21e2a4f6bc ] The driver is written as if platform_get_irq() returns 0 on errors (while actually it returns a negative error code), blithely passing these error codes to request_irq() (which takes *unsigned* IRQ #) -- which fails with -EINVAL. Add the necessary error check to the pre-existing *if* statement forcing the driver into the polling mode... Fixes: 4ad48e6ab18c ("i2c: Renesas Highlander FPGA SMBus support") Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-08-26i2c: dev: zero out array used for i2c reads from userspaceGreg Kroah-Hartman1-2/+3
commit 86ff25ed6cd8240d18df58930bd8848b19fce308 upstream. If an i2c driver happens to not provide the full amount of data that a user asks for, it is possible that some uninitialized data could be sent to userspace. While all in-kernel drivers look to be safe, just be sure by initializing the buffer to zero before it is passed to the i2c driver so that any future drivers will not have this issue. Also properly copy the amount of data recvieved to the userspace buffer, as pointed out by Dan Carpenter. Reported-by: Eric Dumazet <edumazet@google.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-20i2c: core: Disable client irq on reboot/shutdownDmitry Torokhov1-0/+3
[ Upstream commit b64210f2f7c11c757432ba3701d88241b2b98fb1 ] If an i2c client receives an interrupt during reboot or shutdown it may be too late to service it by making an i2c transaction on the bus because the i2c controller has already been shutdown. This can lead to system hangs if the i2c controller tries to make a transfer that is doomed to fail because the access to the i2c pins is already shut down, or an iommu translation has been torn down so i2c controller register access doesn't work. Let's simply disable the irq if there isn't a shutdown callback for an i2c client when there is an irq associated with the device. This will make sure that irqs don't come in later than the time that we can handle it. We don't do this if the i2c client device already has a shutdown callback because presumably they're doing the right thing and quieting the device so irqs don't come in after the shutdown callback returns. Reported-by: kernel test robot <lkp@intel.com> [swboyd@chromium.org: Dropped newline, added commit text, added interrupt.h for robot build error] Signed-off-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-06-30i2c: robotfuzz-osif: fix control-request directionsJohan Hovold1-2/+2
commit 4ca070ef0dd885616ef294d269a9bf8e3b258e1a upstream. The direction of the pipe argument must match the request-type direction bit or control requests may fail depending on the host-controller-driver implementation. Control transfers without a data stage are treated as OUT requests by the USB stack and should be using usb_sndctrlpipe(). Failing to do so will now trigger a warning. Fix the OSIFI2C_SET_BIT_RATE and OSIFI2C_STOP requests which erroneously used the osif_usb_read() helper and set the IN direction bit. Reported-by: syzbot+9d7dadd15b8819d73f41@syzkaller.appspotmail.com Fixes: 83e53a8f120f ("i2c: Add bus driver for for OSIF USB i2c device.") Cc: stable@vger.kernel.org # 3.14 Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-16i2c: mpc: implement erratum A-004447 workaroundChris Packham1-1/+78
[ Upstream commit 8f0cdec8b5fd94135d643662506ee94ae9e98785 ] The P2040/P2041 has an erratum where the normal i2c recovery mechanism does not work. Implement the alternative recovery mechanism documented in the P2040 Chip Errata Rev Q. Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-06-16i2c: mpc: Make use of i2c_recover_bus()Chris Packham1-2/+16
[ Upstream commit 65171b2df15eb7545431d75c2729b5062da89b43 ] Move the existing calls of mpc_i2c_fixup() to a recovery function registered via bus_recovery_info. This makes it more obvious that recovery is supported and allows for a future where recovery is triggered by the i2c core. Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-06-03i2c: i801: Don't generate an interrupt on bus resetJean Delvare1-4/+2
commit e4d8716c3dcec47f1557024add24e1f3c09eb24b upstream. Now that the i2c-i801 driver supports interrupts, setting the KILL bit in a attempt to recover from a timed out transaction triggers an interrupt. Unfortunately, the interrupt handler (i801_isr) is not prepared for this situation and will try to process the interrupt as if it was signaling the end of a successful transaction. In the case of a block transaction, this can result in an out-of-range memory access. This condition was reproduced several times by syzbot: https://syzkaller.appspot.com/bug?extid=ed71512d469895b5b34e https://syzkaller.appspot.com/bug?extid=8c8dedc0ba9e03f6c79e https://syzkaller.appspot.com/bug?extid=c8ff0b6d6c73d81b610e https://syzkaller.appspot.com/bug?extid=33f6c360821c399d69eb https://syzkaller.appspot.com/bug?extid=be15dc0b1933f04b043a https://syzkaller.appspot.com/bug?extid=b4d3fd1dfd53e90afd79 So disable interrupts while trying to reset the bus. Interrupts will be enabled again for the following transaction. Fixes: 636752bcb517 ("i2c-i801: Enable IRQ for SMBus transactions") Reported-by: syzbot+b4d3fd1dfd53e90afd79@syzkaller.appspotmail.com Signed-off-by: Jean Delvare <jdelvare@suse.de> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Jarkko Nikula <jarkko.nikula@linux.intel.com> Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-03i2c: s3c2410: fix possible NULL pointer deref on read message after writeKrzysztof Kozlowski1-0/+3
commit 24990423267ec283b9d86f07f362b753eb9b0ed5 upstream. Interrupt handler processes multiple message write requests one after another, till the driver message queue is drained. However if driver encounters a read message without preceding START, it stops the I2C transfer as it is an invalid condition for the controller. At least the comment describes a requirement "the controller forces us to send a new START when we change direction". This stop results in clearing the message queue (i2c->msg = NULL). The code however immediately jumped back to label "retry_write" which dereferenced the "i2c->msg" making it a possible NULL pointer dereference. The Coverity analysis: 1. Condition !is_msgend(i2c), taking false branch. if (!is_msgend(i2c)) { 2. Condition !is_lastmsg(i2c), taking true branch. } else if (!is_lastmsg(i2c)) { 3. Condition i2c->msg->flags & 1, taking true branch. if (i2c->msg->flags & I2C_M_RD) { 4. write_zero_model: Passing i2c to s3c24xx_i2c_stop, which sets i2c->msg to NULL. s3c24xx_i2c_stop(i2c, -EINVAL); 5. Jumping to label retry_write. goto retry_write; 6. var_deref_model: Passing i2c to is_msgend, which dereferences null i2c->msg. if (!is_msgend(i2c)) {" All previous calls to s3c24xx_i2c_stop() in this interrupt service routine are followed by jumping to end of function (acknowledging the interrupt and returning). This seems a reasonable choice also here since message buffer was entirely emptied. Addresses-Coverity: Explicit null dereferenced Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-22i2c: sh7760: fix IRQ error pathSergey Shtylyov1-1/+1
[ Upstream commit 92dfb27240fea2776f61c5422472cb6defca7767 ] While adding the invalid IRQ check after calling platform_get_irq(), I managed to overlook that the driver has a complex error path in its probe() method, thus a simple *return* couldn't be used. Use a proper *goto* instead! Fixes: e5b2e3e74201 ("i2c: sh7760: add IRQ check") Signed-off-by: Sergey Shtylyov <s.shtylyov@omprussia.ru> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-22i2c: sh7760: add IRQ checkSergey Shtylyov1-1/+4
[ Upstream commit e5b2e3e742015dd2aa6bc7bcef2cb59b2de1221c ] The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to devm_request_irq() (which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding an original error code. Stop calling devm_request_irq() with invalid IRQ #s. Fixes: a26c20b1fa6d ("i2c: Renesas SH7760 I2C master driver") Signed-off-by: Sergey Shtylyov <s.shtylyov@omprussia.ru> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-22i2c: jz4780: add IRQ checkSergey Shtylyov1-1/+4
[ Upstream commit c5e5f7a8d931fb4beba245bdbc94734175fda9de ] The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to devm_request_irq() (which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding an original error code. Stop calling devm_request_irq() with invalid IRQ #s. Fixes: ba92222ed63a ("i2c: jz4780: Add i2c bus controller driver for Ingenic JZ4780") Signed-off-by: Sergey Shtylyov <s.shtylyov@omprussia.ru> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-22i2c: emev2: add IRQ checkSergey Shtylyov1-1/+4
[ Upstream commit bb6129c32867baa7988f7fd2066cf18ed662d240 ] The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to devm_request_irq() (which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding an original error code. Stop calling devm_request_irq() with invalid IRQ #s. Fixes: 5faf6e1f58b4 ("i2c: emev2: add driver") Signed-off-by: Sergey Shtylyov <s.shtylyov@omprussia.ru> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-22i2c: cadence: add IRQ checkSergey Shtylyov1-1/+4
[ Upstream commit 5581c2c5d02bc63a0edb53e061c8e97cd490646e ] The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to devm_request_irq() (which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding an original error code. Stop calling devm_request_irq() with invalid IRQ #s. Fixes: df8eb5691c48 ("i2c: Add driver for Cadence I2C controller") Signed-off-by: Sergey Shtylyov <s.shtylyov@omprussia.ru> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-04-16i2c: turn recovery error on init to debugWolfram Sang1-3/+4
commit e409a6a3e0690efdef9b8a96197bc61ff117cfaf upstream. In some configurations, recovery is optional. So, don't throw an error when it is not used because e.g. pinctrl settings for recovery are not provided. Reword the message and make it debug output. Reported-by: Klaus Kudielka <klaus.kudielka@gmail.com> Tested-by: Klaus Kudielka <klaus.kudielka@gmail.com> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Wolfram Sang <wsa@kernel.org> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-03i2c: brcmstb: Fix brcmstd_send_i2c_cmd conditionMaxime Ripard1-1/+1
[ Upstream commit a1858ce0cfe31368b23ba55794e409fb57ced4a4 ] The brcmstb_send_i2c_cmd currently has a condition that is (CMD_RD || CMD_WR) which always evaluates to true, while the obvious fix is to test whether the cmd variable passed as parameter holds one of these two values. Fixes: dd1aa2524bc5 ("i2c: brcmstb: Add Broadcom settop SoC i2c controller driver") Reported-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-02-23i2c: stm32f7: fix configuration of the digital filterAlain Volmat1-1/+10
[ Upstream commit 3d6a3d3a2a7a3a60a824e7c04e95fd50dec57812 ] The digital filter related computation are present in the driver however the programming of the filter within the IP is missing. The maximum value for the DNF is wrong and should be 15 instead of 16. Fixes: aeb068c57214 ("i2c: i2c-stm32f7: add driver") Signed-off-by: Alain Volmat <alain.volmat@foss.st.com> Signed-off-by: Pierre-Yves MORDRET <pierre-yves.mordret@foss.st.com> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-01-30i2c: octeon: check correct size of maximum RECV_LEN packetWolfram Sang1-1/+1
[ Upstream commit 1b2cfa2d1dbdcc3b6dba1ecb7026a537a1d7277f ] I2C_SMBUS_BLOCK_MAX defines already the maximum number as defined in the SMBus 2.0 specs. No reason to add one to it. Fixes: 886f6f8337dd ("i2c: octeon: Support I2C_M_RECV_LEN") Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Robert Richter <rric@kernel.org> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-01-30i2c: bpmp-tegra: Ignore unknown I2C_M flagsMikko Perttunen1-1/+1
commit bc1c2048abbe3c3074b4de91d213595c57741a6b upstream. In order to not to start returning errors when new I2C_M flags are added, change behavior to just ignore all flags that we don't know about. This includes the I2C_M_DMA_SAFE flag that already exists but causes -EINVAL to be returned for valid transactions. Cc: stable@vger.kernel.org # v4.19+ Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-01-17i2c: sprd: use a specific timeout to avoid system hang up issueChunyan Zhang1-1/+7
commit 0b884fe71f9ee6a5df35e677154256ea2099ebb8 upstream. If the i2c device SCL bus being pulled up due to some exception before message transfer done, the system cannot receive the completing interrupt signal any more, it would not exit waiting loop until MAX_SCHEDULE_TIMEOUT jiffies eclipse, that would make the system seemed hang up. To avoid that happen, this patch adds a specific timeout for message transfer. Fixes: 8b9ec0719834 ("i2c: Add Spreadtrum I2C controller driver") Signed-off-by: Linhua Xu <linhua.xu@unisoc.com> Signed-off-by: Chunyan Zhang <chunyan.zhang@unisoc.com> [wsa: changed errno to ETIMEDOUT] Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-11i2c: qup: Fix error return code in qup_i2c_bam_schedule_desc()Zhihao Cheng1-1/+2
commit e9acf0298c664f825e6f1158f2a97341bf9e03ca upstream. Fix to return the error code from qup_i2c_change_state() instaed of 0 in qup_i2c_bam_schedule_desc(). Fixes: fbf9921f8b35d9b2 ("i2c: qup: Fix error handling") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-11i2c: imx: Check for I2SR_IAL after every byteChristian Eggers1-0/+10
commit 1de67a3dee7a279ebe4d892b359fe3696938ec15 upstream. Arbitration Lost (IAL) can happen after every single byte transfer. If arbitration is lost, the I2C hardware will autonomously switch from master mode to slave. If a transfer is not aborted in this state, consecutive transfers will not be executed by the hardware and will timeout. Signed-off-by: Christian Eggers <ceggers@arri.de> Tested (not extensively) on Vybrid VF500 (Toradex VF50): Tested-by: Krzysztof Kozlowski <krzk@kernel.org> Acked-by: Oleksij Rempel <o.rempel@pengutronix.de> Cc: stable@vger.kernel.org Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-11i2c: imx: Fix reset of I2SR_IAL flagChristian Eggers1-5/+15
commit 384a9565f70a876c2e78e58c5ca0bbf0547e4f6d upstream. According to the "VFxxx Controller Reference Manual" (and the comment block starting at line 97), Vybrid requires writing a one for clearing an interrupt flag. Syncing the method for clearing I2SR_IIF in i2c_imx_isr(). Signed-off-by: Christian Eggers <ceggers@arri.de> Fixes: 4b775022f6fd ("i2c: imx: add struct to hold more configurable quirks") Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Oleksij Rempel <o.rempel@pengutronix.de> Cc: stable@vger.kernel.org Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-22i2c: imx: Fix external abort on interrupt in exit pathsKrzysztof Kozlowski1-11/+13
commit e50e4f0b85be308a01b830c5fbdffc657e1a6dd0 upstream If interrupt comes late, during probe error path or device remove (could be triggered with CONFIG_DEBUG_SHIRQ), the interrupt handler i2c_imx_isr() will access registers with the clock being disabled. This leads to external abort on non-linefetch on Toradex Colibri VF50 module (with Vybrid VF5xx): Unhandled fault: external abort on non-linefetch (0x1008) at 0x8882d003 Internal error: : 1008 [#1] ARM Modules linked in: CPU: 0 PID: 1 Comm: swapper Not tainted 5.7.0 #607 Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree) (i2c_imx_isr) from [<8017009c>] (free_irq+0x25c/0x3b0) (free_irq) from [<805844ec>] (release_nodes+0x178/0x284) (release_nodes) from [<80580030>] (really_probe+0x10c/0x348) (really_probe) from [<80580380>] (driver_probe_device+0x60/0x170) (driver_probe_device) from [<80580630>] (device_driver_attach+0x58/0x60) (device_driver_attach) from [<805806bc>] (__driver_attach+0x84/0xc0) (__driver_attach) from [<8057e228>] (bus_for_each_dev+0x68/0xb4) (bus_for_each_dev) from [<8057f3ec>] (bus_add_driver+0x144/0x1ec) (bus_add_driver) from [<80581320>] (driver_register+0x78/0x110) (driver_register) from [<8010213c>] (do_one_initcall+0xa8/0x2f4) (do_one_initcall) from [<80c0100c>] (kernel_init_freeable+0x178/0x1dc) (kernel_init_freeable) from [<80807048>] (kernel_init+0x8/0x110) (kernel_init) from [<80100114>] (ret_from_fork+0x14/0x20) Additionally, the i2c_imx_isr() could wake up the wait queue (imx_i2c_struct->queue) before its initialization happens. The resource-managed framework should not be used for interrupt handling, because the resource will be released too late - after disabling clocks. The interrupt handler is not prepared for such case. Fixes: 1c4b6c3bcf30 ("i2c: imx: implement bus recovery") Cc: <stable@vger.kernel.org> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Acked-by: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-22i2c: imx: use clk notifier for rate changesLucas Stach1-7/+25
commit 90ad2cbe88c22d0215225ab9594eeead0eb24fde upstream Instead of repeatedly calling clk_get_rate for each transfer, register a clock notifier to update the cached divider value each time the clock rate actually changes. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-10-29i2c: core: Restore acpi_walk_dep_device_list() getting called after ↵Hans de Goede1-1/+10
registering the ACPI i2c devs [ Upstream commit 8058d69905058ec8f467a120b5ec5bb831ea67f3 ] Commit 21653a4181ff ("i2c: core: Call i2c_acpi_install_space_handler() before i2c_acpi_register_devices()")'s intention was to only move the acpi_install_address_space_handler() call to the point before where the ACPI declared i2c-children of the adapter where instantiated by i2c_acpi_register_devices(). But i2c_acpi_install_space_handler() had a call to acpi_walk_dep_device_list() hidden (that is I missed it) at the end of it, so as an unwanted side-effect now acpi_walk_dep_device_list() was also being called before i2c_acpi_register_devices(). Move the acpi_walk_dep_device_list() call to the end of i2c_acpi_register_devices(), so that it is once again called *after* the i2c_client-s hanging of the adapter have been created. This fixes the Microsoft Surface Go 2 hanging at boot. Fixes: 21653a4181ff ("i2c: core: Call i2c_acpi_install_space_handler() before i2c_acpi_register_devices()") Link: https://bugzilla.kernel.org/show_bug.cgi?id=209627 Reported-by: Rainer Finke <rainer@finke.cc> Reported-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Suggested-by: Maximilian Luz <luzmaximilian@gmail.com> Tested-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29i2c: rcar: Auto select RESET_CONTROLLERDirk Behme1-0/+1
[ Upstream commit 5b9bacf28a973a6b16510493416baeefa2c06289 ] The i2c-rcar driver utilizes the Generic Reset Controller kernel feature, so select the RESET_CONTROLLER option when the I2C_RCAR option is selected with a Gen3 SoC. Fixes: 2b16fd63059ab9 ("i2c: rcar: handle RXDMA HW behaviour on Gen3") Signed-off-by: Dirk Behme <dirk.behme@de.bosch.com> Signed-off-by: Andy Lowe <andy_lowe@mentor.com> [erosca: Add "if ARCH_RCAR_GEN3" per Wolfram's request] Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-14i2c: meson: fix clock setting overwriteJerome Brunet1-1/+18
commit 28683e847e2f20eed22cdd24f185d7783db396d3 upstream. When the slave address is written in do_start(), SLAVE_ADDR is written completely. This may overwrite some setting related to the clock rate or signal filtering. Fix this by writing only the bits related to slave address. To avoid causing unexpected changed, explicitly disable filtering or high/low clock mode which may have been left over by the bootloader. Fixes: 30021e3707a7 ("i2c: add support for Amlogic Meson I2C controller") Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-10-14i2c: cpm: Fix i2c_ram structureNicolas VINCENT1-0/+3
[ Upstream commit a2bd970aa62f2f7f80fd0d212b1d4ccea5df4aed ] the i2c_ram structure is missing the sdmatmp field mentionned in datasheet for MPC8272 at paragraph 36.5. With this field missing, the hardware would write past the allocated memory done through cpm_muram_alloc for the i2c_ram structure and land in memory allocated for the buffers descriptors corrupting the cbd_bufaddr field. Since this field is only set during setup(), the first i2c transaction would work and the following would send data read from an arbitrary memory location. Fixes: 61045dbe9d8d ("i2c: Add support for I2C bus on Freescale CPM1/CPM2 controllers") Signed-off-by: Nicolas VINCENT <nicolas.vincent@vossloh.com> Acked-by: Jochen Friedrich <jochen@scram.de> Acked-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-01i2c: core: Call i2c_acpi_install_space_handler() before ↵Hans de Goede1-1/+1
i2c_acpi_register_devices() [ Upstream commit 21653a4181ff292480599dad996a2b759ccf050f ] Some ACPI i2c-devices _STA method (which is used to detect if the device is present) use autodetection code which probes which device is present over i2c. This requires the I2C ACPI OpRegion handler to be registered before we enumerate i2c-clients under the i2c-adapter. This fixes the i2c touchpad on the Lenovo ThinkBook 14-IIL and ThinkBook 15 IIL not getting an i2c-client instantiated and thus not working. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1842039 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-09-23i2c: i801: Fix resume bugVolker Rümelin1-7/+14
commit 66d402e2e9455cf0213c42b97f22a0493372d7cc upstream. On suspend the original host configuration gets restored. The resume routine has to undo this, otherwise the SMBus master may be left in disabled state or in i2c mode. [JD: Rebased on v5.8, moved the write into i801_setup_hstcfg.] Signed-off-by: Volker Rümelin <vr_qemu@t-online.de> Signed-off-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Wolfram Sang <wsa@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.39.0) at 2025-08-23 09:00:55 +0300