- Dec 08, 2022
-
-
Zheyu Ma authored
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: 13f35ac1 ("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>
-
Yang Yingliang authored
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: b3fdd327 ("i2c: mux: Add register-based mux i2c-mux-reg") Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
-
Uwe Kleine-König authored
If for whatever reasons pm_runtime_resume_and_get() failed, .remove() is exited early, the clock isn't freed and runtime PM state isn't reset. The right thing to do however is to free all resources that don't need HW access after a problem with runtime PM. Also issue a warning in that case and return 0 to suppress a less helpful warning by the driver core. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by:
Michal Simek <michal.simek@amd.com> Signed-off-by:
-
Weilong Chen authored
The clk_rate attribute is not generic device tree bindings for I2C busses described in Documentation/devicetree/bindings/i2c/i2c.txt. It can be managed by clock binding. Support the driver to obtain clock information by clk_rate or clock property. Find clock first, if not, fall back to clk_rate. Signed-off-by:
Weilong Chen <chenweilong@huawei.com> Acked-by:
Yicong Yang <yangyicong@hisilicon.com> Signed-off-by:
-
- Dec 05, 2022
-
-
Hui Tang authored
Using pcim_enable_device() to avoid missing pci_disable_device(). Fixes: 7e94dd15 ("i2c-pxa2xx: Add PCI support for PXA I2C controller") Signed-off-by:
Hui Tang <tanghui20@huawei.com> Signed-off-by:
-
Uwe Kleine-König authored
.probe_new() doesn't get the i2c_device_id * parameter, so determine that explicitly in the probe function. Signed-off-by:
-
Uwe Kleine-König authored
.probe_new() doesn't get the i2c_device_id * parameter, so determine that explicitly in the probe function. Signed-off-by:
Peter Rosin <peda@axentia.se> Signed-off-by:
-
Stephen Kitt authored
All these drivers have an i2c probe function which doesn't use the "struct i2c_device_id *id" parameter, so they can trivially be converted to the "probe_new" style of probe with a single argument. This is part of an ongoing transition to single-argument i2c probe functions. Old-style probe functions involve a call to i2c_match_id: in drivers/i2c/i2c-core-base.c, /* * When there are no more users of probe(), * rename probe_new to probe. */ if (driver->probe_new) status = driver->probe_new(client); else if (driver->probe) status = driver->probe(client, i2c_match_id(driver->id_table, client)); else status = -EINVAL; Drivers which don't need the second parameter can be declared using probe_new instead, avoiding the call to i2c_match_id. Drivers which do can still be converted to probe_new-style, calling i2c_match_id themselves (as is done currently for of_match_id). This change was done using the following Coccinelle script, and fixed up for whitespace changes: @ rule1 @ identifier fn; identifier client, id; @@ - static int fn(struct i2c_client *client, const struct i2c_device_id *id) + static int fn(struct i2c_client *client) { ...when != id } @ rule2 depends on rule1 @ identifier rule1.fn; identifier driver; @@ struct i2c_driver driver = { - .probe + .probe_new = ( fn | - &fn + fn ) , }; Signed-off-by:Stephen Kitt <steve@sk2.org> Signed-off-by:
-
Peter Rosin authored
Use the new probe style for i2c drivers. Signed-off-by:
-
Binbin Zhou authored
Dropping a matching #ifdef check along with dropping of_match_ptr() is just a cleanup, while dropping of_match_ptr() that has no corresponding #ifdef fixes an actual warning. Suggested-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Binbin Zhou <zhoubinbin@loongson.cn> Reviewed-by:
-
Neil Armstrong authored
The I2C Master Hub is a stripped down version of the GENI Serial Engine QUP Wrapper Controller but only supporting I2C serial engines without DMA support. Add the I2C Master Hub serial engine compatible along the specific requirements in a new desc struct passed through the device match data. Signed-off-by:
Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by:
-
Neil Armstrong authored
The I2C Master Hub is a stripped down version of the GENI Serial Engine QUP Wrapper Controller but only supporting I2C serial engines without DMA support. Those I2C serial engines variants have some requirements: - a separate "core" clock - doesn't support DMA, thus no memory interconnect path - fixed FIFO size not discoverable in the HW_PARAM_0 register Add a desc struct specifying all those requirements which will be used in a next change when adding the I2C Master Hub serial engine compatible. Signed-off-by:
-
Neil Armstrong authored
The I2C Master Hub is a stripped down version of the GENI Serial Engine QUP Wrapper Controller but only supporting I2C serial engines without DMA support. Add the clock list for the I2C Master Hub variant to a new desc struct then pass it through the I2C Master Hub compatible match data. Signed-off-by:
-
Neil Armstrong authored
The I2C Master Hub is a stripped down version of the GENI Serial Engine QUP Wrapper Controller but only supporting I2C serial engines without DMA support. Prepare support for the I2C Master Hub variant by moving the required clocks list to a new desc struct then passing it through the compatible match data. Signed-off-by:
-
Neil Armstrong authored
The I2C Master Hub is a stripped down version of the GENI Serial Engine QUP Wrapper Controller but only supporting I2C serial engines without DMA support. Document the I2C Serial Engine variant used within the I2C Master Hub Wrapper. This serial engine variant lacks DMA support, requires a core clock, and since DMA support is lacking the memory interconnect path isn't needed. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
Neil Armstrong authored
The I2C Master Hub is a stripped down version of the GENI Serial Engine QUP Wrapper Controller but only supporting I2C serial engines without DMA support. Document the variant compatible, forbid UART and SPI sub-nodes, and remove requirement for the Master AHB clock and iommu property. Signed-off-by:
-
- Dec 02, 2022
-
-
Lad Prabhakar authored
The RIIC block on the RZ/Five SoC is identical to one found on the RZ/G2UL SoC. "renesas,riic-r9a07g043" compatible string will be used on the RZ/Five SoC so to make this clear, update the comment to include RZ/Five SoC. No driver changes are required as generic compatible string "renesas,riic-rz" will be used as a fallback on RZ/Five SoC. Signed-off-by:
Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Akhil R authored
Set ACPI node as the primary fwnode of I2C adapter to allow enumeration of child devices from the ACPI table Signed-off-by:
Zubair Waheed <zwaheed@nvidia.com> Signed-off-by:
Akhil R <akhilrajeev@nvidia.com> Reviewed-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
Corentin Labbe authored
On my x05 laptop I got: Memory type 0x12 not supported yet, not instantiating SPD Adding the 0x12 case lead to a successful instantiated SPD AT24 EEPROM. i801_smbus 0000:00:1f.3: SMBus using polling i2c i2c-6: 2/2 memory slots populated (from DMI) at24 6-0050: 256 byte spd EEPROM, read-only i2c i2c-6: Successfully instantiated SPD at 0x50 at24 6-0051: 256 byte spd EEPROM, read-only And then, I decoded it successfully via decode-dimms. Signed-off-by:
Corentin Labbe <clabbe@baylibre.com> Reviewed-by:
Jean Delvare <jdelvare@suse.de> Signed-off-by:
-
- Nov 15, 2022
-
-
Wolfram Sang authored
-
Angel Iglesias authored
Introduces new helper function to aid in .probe_new() refactors. In order to use existing i2c_get_device_id() on the probe callback, the device match table needs to be accessible in that function, which would require bigger refactors in some drivers using the deprecated .probe callback. This issue was discussed in more detail in the IIO mailing list. Link: https://lore.kernel.org/all/20221023132302.911644-11-u.kleine-koenig@pengutronix.de/ Suggested-by:
Nuno Sá <noname.nuno@gmail.com> Suggested-by:
Jonathan Cameron <jic23@kernel.org> Signed-off-by:
Angel Iglesias <ang.iglesiasg@gmail.com> Reviewed-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
-
- Nov 13, 2022
-
-
Arminder Singh authored
This patch adds IRQ support to the PASemi I2C controller driver to increase the performace of I2C transactions on platforms with PASemi I2C controllers. While primarily intended for Apple silicon platforms, this patch should also help in enabling IRQ support for older PASemi hardware as well should the need arise. This version of the patch has been tested on an M1 Ultra Mac Studio, as well as an M1 MacBook Pro, and userspace launches successfully while using the IRQ path for I2C transactions. Signed-off-by:
Arminder Singh <arminders208@outlook.com> Reviewed-by:
Sven Peter <sven@svenpeter.dev> Reviewed-by:
Hector Martin <marcan@marcan.st> Signed-off-by:
-
Minghao Chi authored
Convert platform_get_resource(), devm_ioremap_resource() to a single call to devm_platform_get_and_ioremap_resource(), as this is exactly what this function does. Reported-by:
Zeal Robot <zealci@zte.com.cn> Signed-off-by:
Minghao Chi <chi.minghao@zte.com.cn> Reviewed-by:
Mukesh Ojha <quic_mojha@quicinc.com> Reviewed-by:
-
- Nov 12, 2022
-
-
Jarkko Nikula authored
DW_IC_COMP_VERSION register contains the ASCII representation of the Synopsys component version. Here 0x3131312A == "111*" means version 1.11* required for DW_IC_SDA_HOLD register availability where '*' means any letter starting from 'a'. DW_IC_COMP_TYPE is constant and is derived from two ASCII letters "DW" followed by a 16-bit unsigned number. Suggested-by:
Jarkko Nikula <jarkko.nikula@linux.intel.com> Reviewed-by:
-
Jarkko Nikula authored
Align all defines to the same column. Signed-off-by:
-
Jarkko Nikula authored
Commit 90312351 ("i2c: designware: MASTER mode as separated driver") introduced disable_int pointer but there is no real use for it. Both i2c-designware-master.c and i2c-designware-slave.c set it to the same i2c_dw_disable_int() and scope is inside the same kernel module. Since i2c_dw_disable_int() is just masking interrupts and the direct DW_IC_INTR_MASK register write looks more clear in the code use that and remove it from common code. Signed-off-by:
-
Jarkko Nikula authored
In my opinion a few lines of spurious interrupt detection code can be moved to the actual master interrupt handling function i2c_dw_isr() without hurting readability. Signed-off-by:
-
Jarkko Nikula authored
It is kind of needless to print interrupt status when code immediately after that finds interrupt was not originating from this device. Therefore move it after spurious interrupt detection. Signed-off-by:
-
Jarkko Nikula authored
Do not return with interrupt handled if host controller is off and thus interrupt is originating from other device or is spurious. Add a check to detect when controller is runtime suspended or transitioning/reset. In latter case all raw interrupt status register bits may read one. In both cases return IRQ_NONE to indicate interrupt was not from this device. Signed-off-by:
-
Jarkko Nikula authored
Interrupt processing code in i2c-designware-slave.c is bit more readable if not divided into another subroutine. Also explicit IRQ_NONE and IRQ_HANDLED return values are more obvious. Signed-off-by:
-
Jarkko Nikula authored
Remove unused completion code from i2c-designware-slave.c. Used only in i2c-designware-master.c. Signed-off-by:
-
Jarkko Nikula authored
These struct dw_i2c_dev members are not used in i2c-designware-slave.c so remove re-initialization of them from i2c_dw_reg_slave(). Signed-off-by:
-
Jarkko Nikula authored
Define software status flags with a BIT() macro. While at it remove STATUS_IDLE and replace its use with zero initialization and status flags clearing with a mask. Suggested-by:
-
Jarkko Nikula authored
Writes from I2C bus often fail when testing the i2c-designware-slave.c with the slave-eeprom backend. The same writes work correctly when testing with a real 24c02 EEPROM chip. In the tests below an i2c-designware-slave.c instance with the slave-eeprom backend is configured to act as a simulated 24c02 at address 0x65 on an I2C host bus 6. 1. i2cset -y 6 0x65 0x00 0x55 Single byte 0x55 write into address 0x00. No data goes into simulated EEPROM. Debug prints from the i2c_dw_irq_handler_slave(): 0x1 STATUS SLAVE_ACTIVITY=0x0 : RAW_INTR_STAT=0x714 : INTR_STAT=0x204 0x1 STATUS SLAVE_ACTIVITY=0x0 : RAW_INTR_STAT=0x514 : INTR_STAT=0x4 2. i2ctransfer -y 6 w9@0x65 0x00 0xff- Write 8 bytes with decrementing value starting from 0xff at address 0x00 and forward. Only some of the data goes into arbitrary addresses. Content is something like below but varies: 00000000 f9 f8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000050 00 00 00 00 00 00 ff fe 00 00 00 00 00 00 00 00 |................| 000000f0 00 00 00 00 00 00 00 00 00 00 00 00 00 fc fb fa |................| In this case debug prints were: 0x1 STATUS SLAVE_ACTIVITY=0x1 : RAW_INTR_STAT=0x514 : INTR_STAT=0x4 0x1 STATUS SLAVE_ACTIVITY=0x1 : RAW_INTR_STAT=0x514 : INTR_STAT=0x4 0x1 STATUS SLAVE_ACTIVITY=0x0 : RAW_INTR_STAT=0x714 : INTR_STAT=0x204 0x1 STATUS SLAVE_ACTIVITY=0x0 : RAW_INTR_STAT=0x514 : INTR_STAT=0x4 0x1 STATUS SLAVE_ACTIVITY=0x0 : RAW_INTR_STAT=0x514 : INTR_STAT=0x4 0x1 STATUS SLAVE_ACTIVITY=0x0 : RAW_INTR_STAT=0x514 : INTR_STAT=0x4 0x1 STATUS SLAVE_ACTIVITY=0x0 : RAW_INTR_STAT=0x514 : INTR_STAT=0x4 0x1 STATUS SLAVE_ACTIVITY=0x0 : RAW_INTR_STAT=0x514 : INTR_STAT=0x4 0x1 STATUS SLAVE_ACTIVITY=0x0 : RAW_INTR_STAT=0x514 : INTR_STAT=0x4 0x1 STATUS SLAVE_ACTIVITY=0x0 : RAW_INTR_STAT=0x510 : INTR_STAT=0x0 Both cases show there is more data coming from the receive FIFO still after detecting the STOP condition. This can be seen from interrupt status bits DW_IC_INTR_STOP_DET (0x200) and DW_IC_INTR_RX_FULL (0x4). Perhaps due interrupt latencies the receive FIFO is not read fast enough, STOP detection happens synchronously when it occurs on the I2C bus and the DW_IC_INTR_RX_FULL keeps coming as long as there are more bytes in the receive FIFO. Fix this by reading the receive FIFO completely empty whenever DW_IC_INTR_RX_FULL occurs. Use RFNE, Receive FIFO Not Empty bit in the DW_IC_STATUS register to loop through bytes in the FIFO. While at it do not test the return code from i2c_slave_event() for the I2C_SLAVE_WRITE_RECEIVED since to my understanding this hardware cannot generate NACK to incoming bytes and debug print itself does not have much value. Reported-by:
Tian Ye <tianye@sugon.com> Signed-off-by:
-
Jarkko Nikula authored
Some read types from I2C bus don't work correctly when testing the i2c-designware-slave.c with the slave-eeprom backend. The same reads work correctly when testing with a real 24c02 EEPROM chip. In the following tests an i2c-designware-slave.c instance with the slave-eeprom backend is configured to act as a simulated 24c02 at address 0x65 on an I2C host bus 6: 1. i2cdump -y 6 0x65 b (OK) Random read. Each byte are read using a byte address write with a current address read in a same message. 2. i2cdump -y 6 0x65 c (OK, was NOK before commit 3b5f7f10 when it was repeating the 1st byte) Repeated current address read. One byte address write message followed by repeated current address read messages. 3. i2cdump -y 6 0x65 i (NOK, each 32 byte block repeats the 1st byte of block) Sequential read using SMBus Block Read. For each 32 byte block a byte address write followed by 32 sequental reads in a same message. These findings are explained because the implementation has had a mismatch between hardware interrupts and what I2C slave events should be sent after those interrupts. Despite that the case 1 happened to have always the I2C slave events sent to a right order with a right data between backend and the I2C bus. Hardware generates the DW_IC_INTR_RD_REQ interrupt when another host is attempting to read and for sequential reads after. DW_IC_INTR_RX_DONE occurs when host does not acknowledge a transmitted byte which is an indication the end of transmission. Those interrupts do not match directly with I2C_SLAVE_READ_REQUESTED and I2C_SLAVE_READ_PROCESSED events which is how the code was and is practically using them. The slave-eeprom backend increases the buffer index with the I2C_SLAVE_READ_PROCESSED event and returns the data from current index when receiving only the I2C_SLAVE_READ_REQUESTED event. That explains the repeated bytes in case 3 and also case 2 before commit 3b5f7f10 ("i2c: designware: slave should do WRITE_REQUESTED before WRITE_RECEIVED"). Patch fixes the case 3 while keep cases 1 and 2 working with following changes: - First DW_IC_INTR_RD_REQ interrupt will change the state machine to read in progress state, send I2C_SLAVE_READ_REQUESTED event and transmit the first byte from backend - Subsequent DW_IC_INTR_RD_REQ interrupts will send I2C_SLAVE_READ_PROCESSED events and transmit next bytes from backend - STOP won't change the state machine. Otherwise case 2 won't work since we cannot distinguish current address read from sequentiel read - DW_IC_INTR_RX_DONE interrupt is needless since there is no mechanism to inform it to a backend. It cannot be used to change state machine at the end of read either due the same reason than above - Next host write to us will change the state machine from read to write in progress state - STATUS_WRITE_IN_PROGRESS and STATUS_READ_IN_PROGRESS are considered now to be status flags not the state of the driver. This is how we treat them in i2c-designware-master.c While at it do not test the return code from i2c_slave_event() for I2C_SLAVE_READ_REQUESTED and I2C_SLAVE_READ_PROCESSED since it returns always 0. Signed-off-by:
-
- Nov 03, 2022
-
-
Weilong Chen authored
Add the new compatible for HiSilicon i2c. Signed-off-by:
-
Weilong Chen authored
The HiSilicon I2C controller can be used on embedded platform, which boot from devicetree. Signed-off-by:
-
Andre Przywara authored
The I2C controller IP used in the Allwinner F1C100s series of SoCs is compatible with the ones used in the other Allwinner SoCs. Add an F1C100s specific compatible string to the list of existing names. Signed-off-by:
Andre Przywara <andre.przywara@arm.com> Acked-by:
-
- Nov 01, 2022
-
-
Jonathan Neuschäfer authored
To make the code easier to understand, add longer names to the definitions of register fields. These longer names are based on source code published by DELL/AESS for WPCM450, but should apply just as well to NPCM7xx and NPCM8xx. Signed-off-by:
Jonathan Neuschäfer <j.neuschaefer@gmx.net> Reviewed-by:
Tali Perry <tali.perry1@gmail.com> Signed-off-by:
-
Jonathan Neuschäfer authored
The unlabelled registers NPCM_I2CCTL4 to NPCM_I2CSCLHT overlap with the bank 1 registers below, and they are accessed after selecting bank 0, so they clearly belong to bank 0. Move them together with the other bank 0 registers, and move the unrelated definition of npcm_i2caddr down to keep the banked registers in one piece. Signed-off-by:
-
