- Jan 07, 2022
-
-
Wolfram Sang authored
This largely reverts commit 5a7b95fb. It breaks suspend with AMD GPUs, and we couldn't incrementally fix it. So, let's remove the code and go back to the drawing board. We keep the header extension to not break drivers already populating the regulator. We expect to re-add the code handling it soon. Fixes: 5a7b95fb ("i2c: core: support bus regulator controlling in adapter") Reported-by:
"Tareque Md.Hanif" <tarequemd.hanif@yahoo.com> Link: https://lore.kernel.org/r/1295184560.182511.1639075777725@mail.yahoo.com Reported-by:
Konstantin Kharlamov <hi-angel@yandex.ru> Link: https://lore.kernel.org/r/7143a7147978f4104171072d9f5225d2ce355ec1.camel@yandex.ru BugLink: drm/amd#1850 Tested-by:
Wolfram Sang <wsa@kernel.org> Cc: <stable@vger.kernel.org> # 5.14+
-
- Jan 06, 2022
-
-
Chris Packham authored
When performing an I2C transfer where the last message was a write KASAN would complain: BUG: KASAN: slab-out-of-bounds in mpc_i2c_do_action+0x154/0x630 Read of size 2 at addr c814e310 by task swapper/2/0 CPU: 2 PID: 0 Comm: swapper/2 Tainted: G B 5.16.0-rc8 #1 Call Trace: [e5ee9d50] [c08418e8] dump_stack_lvl+0x4c/0x6c (unreliable) [e5ee9d70] [c02f8a14] print_address_description.constprop.13+0x64/0x3b0 [e5ee9da0] [c02f9030] kasan_report+0x1f0/0x204 [e5ee9de0] [c0c76ee4] mpc_i2c_do_action+0x154/0x630 [e5ee9e30] [c0c782c4] mpc_i2c_isr+0x164/0x240 [e5ee9e60] [c00f3a04] __handle_irq_event_percpu+0xf4/0x3b0 [e5ee9ec0] [c00f3d40] handle_irq_event_percpu+0x80/0x110 [e5ee9f40] [c00f3e48] handle_irq_event+0x78/0xd0 [e5ee9f60] [c00fcfec] handle_fasteoi_irq+0x19c/0x370 [e5ee9fa0] [c00f1d84] generic_handle_irq+0x54/0x80 [e5ee9fc0] [c0006b54] __do_irq+0x64/0x200 [e5ee9ff0] [c0007958] __do_IRQ+0xe8/0x1c0 [c812dd50] [e3eaab20] 0xe3eaab20 [c812dd90] [c0007a4c] do_IRQ+0x1c/0x30 [c812dda0] [c0000c04] ExternalInput+0x144/0x160 --- interrupt: 500 at arch_cpu_idle+0x34/0x60 NIP: c000b684 LR: c000b684 CTR: c0019688 REGS: c812ddb0 TRAP: 0500 Tainted: G B (5.16.0-rc8) MSR: 00029002 <CE,EE,ME> CR: 22000488 XER: 20000000 GPR00: c10ef7fc c812de90 c80ff200 c2394718 00000001 00000001 c10e3f90 00000003 GPR08: 00000000 c0019688 c2394718 fc7d625b 22000484 00000000 21e17000 c208228c GPR16: e3e99284 00000000 ffffffff c2390000 c001bac0 c2082288 c812df60 c001ba60 GPR24: c23949c0 00000018 00080000 00000004 c80ff200 00000002 c2348ee4 c2394718 NIP [c000b684] arch_cpu_idle+0x34/0x60 LR [c000b684] arch_cpu_idle+0x34/0x60 --- interrupt: 500 [c812de90] [c10e3f90] rcu_eqs_enter.isra.60+0xc0/0x110 (unreliable) [c812deb0] [c10ef7fc] default_idle_call+0xbc/0x230 [c812dee0] [c00af0e8] do_idle+0x1c8/0x200 [c812df10] [c00af3c0] cpu_startup_entry+0x20/0x30 [c812df20] [c001e010] start_secondary+0x5d0/0xba0 [c812dff0] [c00028a0] __secondary_start+0x90/0xdc This happened because we would overrun the i2c->msgs array on the final interrupt for the I2C STOP. This didn't happen if the last message was a read because there is no interrupt in that case. Ensure that we only access the current message if we are not processing a I2C STOP condition. Fixes: 1538d82f ("i2c: mpc: Interrupt driven transfer") Reported-by:
Maxime Bizon <mbizon@freebox.fr> Signed-off-by:
Chris Packham <chris.packham@alliedtelesis.co.nz> Signed-off-by:
-
- Dec 31, 2021
-
-
Pavel Skripkin authored
Wrong user data may cause warning in i2c_transfer(), ex: zero msgs. Userspace should not be able to trigger warnings, so this patch adds validation checks for user data in compact ioctl to prevent reported warnings Reported-and-tested-by:
<syzbot+e417648b303855b91d8a@syzkaller.appspotmail.com> Fixes: 7d5cb456 ("i2c compat ioctls: move to ->compat_ioctl()") Signed-off-by:
Pavel Skripkin <paskripkin@gmail.com> Signed-off-by:
-
- Dec 10, 2021
-
-
Chris Packham authored
Maxime points out that the polling code in mpc_i2c_isr should use the _atomic API because it is called in an irq context and that the behaviour of the MCF bit is that it is 1 when the byte transfer is complete. All of this means the original code was effectively a udelay(100). Fix this by using readb_poll_timeout_atomic() and removing the negation of the break condition. Fixes: 4a8ac5e4 ("i2c: mpc: Poll for MCF") Reported-by:
-
- Dec 09, 2021
-
-
Vincent Whitchurch authored
The driver currently assumes that the notify callback is only received when the device is done with all the queued buffers. However, this is not true, since the notify callback could be called without any of the queued buffers being completed (for example, with virtio-pci and shared interrupts) or with only some of the buffers being completed (since the driver makes them available to the device in multiple separate virtqueue_add_sgs() calls). This can lead to incorrect data on the I2C bus or memory corruption in the guest if the device operates on buffers which are have been freed by the driver. (The WARN_ON in the driver is also triggered.) BUG kmalloc-128 (Tainted: G W ): Poison overwritten First byte 0x0 instead of 0x6b Allocated in i2cdev_ioctl_rdwr+0x9d/0x1de age=243 cpu=0 pid=28 memdup_user+0x2e/0xbd i2cdev_ioctl_rdwr+0x9d/0x1de i2cdev_ioctl+0x247/0x2ed vfs_ioctl+0x21/0x30 sys_ioctl+0xb18/0xb41 Freed in i2cdev_ioctl_rdwr+0x1bb/0x1de age=68 cpu=0 pid=28 kfree+0x1bd/0x1cc i2cdev_ioctl_rdwr+0x1bb/0x1de i2cdev_ioctl+0x247/0x2ed vfs_ioctl+0x21/0x30 sys_ioctl+0xb18/0xb41 Fix this by calling virtio_get_buf() from the notify handler like other virtio drivers and by actually waiting for all the buffers to be completed. Fixes: 3cfc8838 ("i2c: virtio: add a virtio i2c frontend driver") Acked-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
Vincent Whitchurch <vincent.whitchurch@axis.com> Acked-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
-
- Nov 30, 2021
-
-
Ondrej Jirman authored
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:
-
Alain Volmat authored
dmaengine_terminate_all() is deprecated in favor of explicitly saying if it should be sync or async. Here, we use dmaengine_terminate_sync in i2c_xfer and i2c_smbus_xfer handlers and rely on dmaengine_terminate_async within interrupt handlers (transmission error cases). dmaengine_synchronize is added within i2c_xfer and i2c_smbus_xfer handler to finalize terminate started in interrupt handlers. Signed-off-by:
Alain Volmat <alain.volmat@foss.st.com> Reviewed-by:
Pierre-Yves MORDRET <pierre-yves.mordret@foss.st.com> Signed-off-by:
-
Alain Volmat authored
In case of receiving a NACK, the dma transfer should be stopped to avoid feeding data into the FIFO. Also ensure to properly return the proper error code and avoid waiting for the end of the dma completion in case of error happening during the transmission. Fixes: 7ecc8cfd ("i2c: i2c-stm32f7: Add DMA support") Signed-off-by:
-
Alain Volmat authored
When getting an access timeout, ensure that the bus is in a proper state prior to returning the error. Fixes: aeb068c5 ("i2c: i2c-stm32f7: add driver") Signed-off-by:
-
- Nov 29, 2021
-
-
Alain Volmat authored
While handling an error during transfer (ex: NACK), it could happen that the driver has already written data into TXDR before the transfer get stopped. This commit add TXDR Flush after end of transfer in case of error to avoid sending a wrong data on any other slave upon next transfer. Fixes: aeb068c5 ("i2c: i2c-stm32f7: add driver") Signed-off-by:
-
Aaro Koskinen authored
CBUS transfers have always been atomic, but after commit 63b96983 ("i2c: core: introduce callbacks for atomic transfers") we started to see warnings during e.g. poweroff as the atomic callback is not explicitly set. Fix that. Fixes the following WARNING seen during Nokia N810 power down: [ 786.570617] reboot: Power down [ 786.573913] ------------[ cut here ]------------ [ 786.578826] WARNING: CPU: 0 PID: 672 at drivers/i2c/i2c-core.h:40 i2c_smbus_xfer+0x100/0x110 [ 786.587799] No atomic I2C transfer handler for 'i2c-2' Fixes: 63b96983 ("i2c: core: introduce callbacks for atomic transfers") Signed-off-by:
Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by:
-
- Nov 23, 2021
-
-
Vincent Whitchurch authored
If a timeout is hit, it can result is incorrect data on the I2C bus and/or memory corruptions in the guest since the device can still be operating on the buffers it was given while the guest has freed them. Here is, for example, the start of a slub_debug splat which was triggered on the next transfer after one transfer was forced to timeout by setting a breakpoint in the backend (rust-vmm/vhost-device): BUG kmalloc-1k (Not tainted): Poison overwritten First byte 0x1 instead of 0x6b Allocated in virtio_i2c_xfer+0x65/0x35c age=350 cpu=0 pid=29 __kmalloc+0xc2/0x1c9 virtio_i2c_xfer+0x65/0x35c __i2c_transfer+0x429/0x57d i2c_transfer+0x115/0x134 i2cdev_ioctl_rdwr+0x16a/0x1de i2cdev_ioctl+0x247/0x2ed vfs_ioctl+0x21/0x30 sys_ioctl+0xb18/0xb41 Freed in virtio_i2c_xfer+0x32e/0x35c age=244 cpu=0 pid=29 kfree+0x1bd/0x1cc virtio_i2c_xfer+0x32e/0x35c __i2c_transfer+0x429/0x57d i2c_transfer+0x115/0x134 i2cdev_ioctl_rdwr+0x16a/0x1de i2cdev_ioctl+0x247/0x2ed vfs_ioctl+0x21/0x30 sys_ioctl+0xb18/0xb41 There is no simple fix for this (the driver would have to always create bounce buffers and hold on to them until the device eventually returns the buffers), so just disable the timeout support for now. Fixes: 3cfc8838 ("i2c: virtio: add a virtio i2c frontend driver") Acked-by:
Jie Deng <jie.deng@intel.com> Signed-off-by:
-
Jarkko Nikula authored
Currently interrupt storm will occur from i2c-i801 after first transaction if SMB_ALERT signal is enabled and ever asserted. It is enough if the signal is asserted once even before the driver is loaded and does not recover because that interrupt is not acknowledged. This fix aims to fix it by two ways: - Add acknowledging for the SMB_ALERT interrupt status - Disable the SMB_ALERT interrupt on platforms where possible since the driver currently does not make use for it Acknowledging resets the SMB_ALERT interrupt status on all platforms and also should help to avoid interrupt storm on older platforms where the SMB_ALERT interrupt disabling is not available. For simplicity this fix reuses the host notify feature for disabling and restoring original register value. Link: https://bugzilla.kernel.org/show_bug.cgi?id=177311 Reported-by:
<ck+kernelbugzilla@bl4ckb0x.de> Reported-by:
<stephane.poignant@protonmail.com> Signed-off-by:
Jarkko Nikula <jarkko.nikula@linux.intel.com> Reviewed-by:
Jean Delvare <jdelvare@suse.de> Tested-by:
-
Jean DELVARE authored
If driver interrupts are enabled, SMBHSTCNT_INTREN will be 1 after the first transaction, and will stay to that value forever. This means that interrupts will be generated for both host-initiated transactions and also SMBus Alert events even after the driver is unloaded. To be on the safe side, we should restore the initial state of this bit at suspend and reboot time, as we do for several other configuration bits already and for the same reason: the BIOS should be handed the device in the same configuration state in which we received it. Otherwise interrupts may be generated which nobody will process. Signed-off-by:
-
- Nov 07, 2021
-
-
Rafael J. Wysocki authored
The ACPI_HANDLE() macro is a wrapper arond the ACPI_COMPANION() macro and the ACPI handle produced by the former comes from the ACPI device object produced by the latter, so it is way more straightforward to evaluate the latter directly instead of passing the handle produced by the former to acpi_bus_get_device(). Modify i2c_amd_probe() accordingly (no intentional functional impact). Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by:
Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Signed-off-by:
-
Andy Shevchenko authored
Add PCI ID of SMBus controller on Intel Ice Lake PCH-N. The device can be found on MacBookPro16,2 [1]. [1]: https://linux-hardware.org/?probe=f1c5cf0c43 Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by:
-
- Nov 06, 2021
-
-
Wei Yongjun authored
PTR_ERR should access the value just tested by IS_ERR, otherwise the wrong error code will be returned. Fixes: 7b6da7fe ("mailbox: pcc: Use PCC mailbox channel pointer instead of standard") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Reviewed-by:
Sudeep Holla <sudeep.holla@arm.com> Signed-off-by:
-
- Nov 03, 2021
-
-
Sakari Ailus authored
Enable drivers to tell ACPI that there's no need to power on a device for probe. Drivers should still perform this by themselves if there's a need to. In some cases powering on the device during probe is undesirable, and this change enables a driver to choose what fits best for it. Add a field called "flags" into struct i2c_driver for driver flags, and a flag I2C_DRV_ACPI_WAIVE_D0_PROBE to tell a driver supports probe in ACPI D states other than 0. Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by:
Tomasz Figa <tfiga@chromium.org> Acked-by:
-
- Nov 01, 2021
-
-
The virtio specification received a new mandatory feature (VIRTIO_I2C_F_ZERO_LENGTH_REQUEST) for zero length requests. Fail if the feature isn't offered by the device. For each read-request, set the VIRTIO_I2C_FLAGS_M_RD flag, as required by the VIRTIO_I2C_F_ZERO_LENGTH_REQUEST feature. This allows us to support zero length requests, like SMBUS Quick, where the buffer need not be sent anymore. Signed-off-by:
-
- Oct 30, 2021
-
-
Sudeep Holla authored
Now that we have all the shared memory region information populated in the pcc_mbox_chan, let us propagate the pointer to the same as the return value to pcc_mbox_request channel. This eliminates the need for the individual users of PCC mailbox to parse the PCCT subspace entries and fetch the shmem information. This also eliminates the need for PCC mailbox controller to set con_priv to PCCT subspace entries. This is required as con_priv is private to the controller driver to attach private data associated with the channel and not meant to be used by the mailbox client/users. Let us convert all the users of pcc_mbox_{request,free}_channel to use new interface. Cc: Jean Delvare <jdelvare@suse.com> Signed-off-by:Guenter Roeck <linux@roeck-us.net> Signed-off-by:
Jassi Brar <jaswinder.singh@linaro.org>
-
- Oct 29, 2021
-
-
Christophe JAILLET authored
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: 75d31c23 ("i2c: xlr: add support for Sigma Designs controller variant") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
-
Tian Tao authored
disable_irq() after request_irq() still has a time gap in which interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will disable IRQ auto-enable because of requesting. Signed-off-by:
Tian Tao <tiantao6@hisilicon.com> Signed-off-by:
-
Randy Dunlap authored
Correct the typo of "reamining" to "remaining". Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Suggested-by:
Matthew Wilcox <willy@infradead.org> Signed-off-by:
-
Dmitry Osipenko authored
Tegra I2C device isn't guaranteed to be suspended after removal of the driver since driver uses pm_runtime_put() that is asynchronous and pm_runtime_disable() cancels pending power-change requests. This means that potentially refcount of the clocks may become unbalanced after removal of the driver. This a very minor problem which unlikely to happen in practice and won't cause any visible problems, nevertheless let's replace pm_runtime_disable() with pm_runtime_force_suspend() and use pm_runtime_put_sync() which disables RPM of the device and puts it into suspend before driver is removed. Signed-off-by:
Dmitry Osipenko <digetx@gmail.com> Signed-off-by:
-
Jarkko Nikula authored
Commit a6b8bb6a ("i2c: i801: Fix handling SMBHSTCNT_PEC_EN") attempts to disable software PEC by clearing the SMBHSTCNT_PEC_EN (bit 7) in the SMBus Host Control register (I/O SMBHSTCNT) but incorrectly clears it in the PCI Host Configuration register (PCI SMBHSTCFG). This clearing is actually needless since after above commit the SMBHSTCNT_PEC_EN is never set and the register is initialized with known values. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by:
-
- Oct 20, 2021
-
-
Andy Shevchenko authored
Since driver core provides a generic device_match_acpi_handle() we may replace the custom one with it. This unifies code to find an adapter with the similar one which finds a client. Acked-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- Oct 11, 2021
-
-
Kewei Xu authored
When a timeout error occurs in i2c transter, it is usually related to the i2c/dma IP hardware configuration. Therefore, the purpose of this patch is to dump the key register values of i2c/dma when a timeout occurs in i2c for debugging. Signed-off-by:
Kewei Xu <kewei.xu@mediatek.com> Reviewed-by:
Qii Wang <qii.wang@mediatek.com> Signed-off-by:
-
Kewei Xu authored
Due to changes in the hardware design of the handshaking signal between i2c and dma, it is necessary to reset the handshaking signal before each transfer to ensure that the multi-msgs can be transferred correctly. Signed-off-by:
-
Vadim Pasternak authored
Allow polling time setting according to I2C frequency supported across the system. For base frequency 400 KHz and 1 MHz set polling time is set four times less than for system with base frequency 100KHz. Signed-off-by:
Vadim Pasternak <vadimp@nvidia.com> Signed-off-by:
-
Sven Peter authored
Some later revisions after the original PASemi I2C controller introduce what likely is an enable bit to the CTL register. Without setting it the actual i2c transmission is never started. Reviewed-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Sven Peter <sven@svenpeter.dev> Acked-by:
Olof Johansson <olof@lixom.net> Tested-by:
Christian Zigotzky <chzigotzky@xenosoft.de> Signed-off-by:
-
Sven Peter authored
With all the previous preparations we can now finally add the platform driver to support the PASemi-based controllers in Apple SoCs. This does not work on the M1 yet but should work on the early iPhones already. Reviewed-by:
-
Sven Peter authored
Using managed device resources means there's nothing left to be done in pasemi_smb_pci_remove and also allows to remove base and size from struct pasemi_smbus. Reviewed-by:
-
Sven Peter authored
Right now the bus frequency has always been hardcoded as 100 KHz with the specific reference clock used in the PASemi PCI controllers. Make this configurable to prepare for the platform driver. Reviewed-by:
-
Sven Peter authored
Split out common reset call to its own function so that we can later add support for selecting the clock frequency and an additional enable bit found in newer revisions. Reviewed-by:
-
Sven Peter authored
Split off the PCI driver so that we can reuse common code for the platform driver. Reviewed-by:
-
Sven Peter authored
Split off common probing code that will be used by both the PCI and the platform device. Reviewed-by:
-
Sven Peter authored
Prepare to create a platform driver by removing all usages of pci_dev we can. Reviewed-by:
-
Sven Peter authored
Right now the i2c adapter name includes the port number which can indirectly be used to identify the device. Replace that with dev_name to directly identify the device and to also allow this to work correctly once we add platform support. Signed-off-by:
-
Sven Peter authored
In preparation for splitting this driver up into a platform_driver and a pci_driver, replace outl/inl usage with pci_iomap and ioread32/iowrite32. Reviewed-by:
-
- Oct 04, 2021
-
-
Vadim Pasternak authored
Decrease polling time 'MLXCPLD_I2C_POLL_TIME' from 400 usec to 200 usec. It improves performance of I2C transactions. Reliability of setting polling time to 200 usec has been validated across all the supported systems. Signed-off-by:
-
