aboutsummaryrefslogtreecommitdiff
path: root/drivers/i2c
AgeCommit message (Collapse)AuthorFilesLines
2018-10-05i2c: designware: Call i2c_dw_clk_rate() only when calculating timingsJarkko Nikula1-1/+3
There are platforms which don't provide input clock rate but provide I2C timing parameters. Commit 3bd4f277274b ("i2c: designware: Call i2c_dw_clk_rate() only once in i2c_dw_init_master()") causes needless warning during probe on those platforms since i2c_dw_clk_rate(), which causes the warning when input clock is unknown, is called even when there is no need to calculate timing parameters. Fixes: 3bd4f277274b ("i2c: designware: Call i2c_dw_clk_rate() only once in i2c_dw_init_master()") Reported-by: Ard Biesheuvel <[email protected]> Cc: <[email protected]> # 4.19 Signed-off-by: Jarkko Nikula <[email protected]> Tested-by: Ard Biesheuvel <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2018-10-01i2c: i2c-scmi: fix for i2c_smbus_write_block_dataEdgar Cherkasov1-0/+1
The i2c-scmi driver crashes when the SMBus Write Block transaction is executed: WARNING: CPU: 9 PID: 2194 at mm/page_alloc.c:3931 __alloc_pages_slowpath+0x9db/0xec0 Call Trace: ? get_page_from_freelist+0x49d/0x11f0 ? alloc_pages_current+0x6a/0xe0 ? new_slab+0x499/0x690 __alloc_pages_nodemask+0x265/0x280 alloc_pages_current+0x6a/0xe0 kmalloc_order+0x18/0x40 kmalloc_order_trace+0x24/0xb0 ? acpi_ut_allocate_object_desc_dbg+0x62/0x10c __kmalloc+0x203/0x220 acpi_os_allocate_zeroed+0x34/0x36 acpi_ut_copy_eobject_to_iobject+0x266/0x31e acpi_evaluate_object+0x166/0x3b2 acpi_smbus_cmi_access+0x144/0x530 [i2c_scmi] i2c_smbus_xfer+0xda/0x370 i2cdev_ioctl_smbus+0x1bd/0x270 i2cdev_ioctl+0xaa/0x250 do_vfs_ioctl+0xa4/0x600 SyS_ioctl+0x79/0x90 do_syscall_64+0x73/0x130 entry_SYSCALL_64_after_hwframe+0x3d/0xa2 ACPI Error: Evaluating _SBW: 4 (20170831/smbus_cmi-185) This problem occurs because the length of ACPI Buffer object is not defined/initialized in the code before a corresponding ACPI method is called. The obvious patch below fixes this issue. Signed-off-by: Edgar Cherkasov <[email protected]> Acked-by: Viktor Krasnov <[email protected]> Acked-by: Michael Brunner <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2018-09-25i2c: i2c-isch: fix spelling mistake "unitialized" -> "uninitialized"Colin Ian King1-1/+1
Trivial fix to spelling mistake in dev_notice message. Signed-off-by: Colin Ian King <[email protected]> Reviewed-by: Jean Delvare <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2018-09-25i2c: i2c-qcom-geni: Properly handle DMA safe buffersStephen Boyd1-4/+18
We shouldn't attempt to DMA map the message buffers passed into this driver from the i2c core unless the message we're mapping have been properly setup for DMA. The i2c core indicates such a situation by setting the I2C_M_DMA_SAFE flag, so check for that flag before using DMA mode. We can also bounce the buffer if it isn't already mapped properly by using the i2c_get_dma_safe_msg_buf() APIs, so do that when we want to use DMA for a message. This fixes a problem where the kernel oopses cleaning pages for a buffer that's mapped into the vmalloc space. The pages are returned from request_firmware() and passed down directly to the i2c master to write to the i2c touchscreen device. Mapping vmalloc buffers with dma_map_single() won't work reliably, causing an oops like below: Unable to handle kernel paging request at virtual address ffffffc01391d000 ... Reported-by: Philip Chen <[email protected]> Signed-off-by: Stephen Boyd <[email protected]> Reviewed-by: Douglas Anderson <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2018-09-06i2c: xiic: Make the start and the byte count write atomicShubhrajyoti Datta1-0/+4
Disable interrupts while configuring the transfer and enable them back. We have below as the programming sequence 1. start and slave address 2. byte count and stop In some customer platform there was a lot of interrupts between 1 and 2 and after slave address (around 7 clock cyles) if 2 is not executed then the transaction is nacked. To fix this case make the 2 writes atomic. Signed-off-by: Shubhrajyoti Datta <[email protected]> Signed-off-by: Michal Simek <[email protected]> [wsa: added a newline for better readability] Signed-off-by: Wolfram Sang <[email protected]> Cc: [email protected]
2018-09-04i2c: i801: fix DNV's SMBCTRL register offsetFelipe Balbi1-1/+6
DNV's iTCO is slightly different with SMBCTRL sitting at a different offset when compared to all other devices. Let's fix so that we can properly use iTCO watchdog. Fixes: 84d7f2ebd70d ("i2c: i801: Add support for Intel DNV") Cc: <[email protected]> # v4.4+ Signed-off-by: Felipe Balbi <[email protected]> Reviewed-by: Jean Delvare <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2018-09-02i2c: imx-lpi2c: Remove mx8dv compatible entryFabio Estevam1-1/+0
mx8dv never entered into production and there is no other place in the kernel referring to this SoC, so remove it from the driver's compatible entry. Signed-off-by: Fabio Estevam <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2018-09-02i2c: uniphier-f: issue STOP only for last message or I2C_M_STOPMasahiro Yamada1-5/+2
This driver currently emits a STOP if the next message is not I2C_MD_RD. It should not do it because it disturbs the I2C_RDWR ioctl, where read/write transactions are combined without STOP between. Issue STOP only when the message is the last one _or_ flagged with I2C_M_STOP. Fixes: 6a62974b667f ("i2c: uniphier_f: add UniPhier FIFO-builtin I2C driver") Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2018-09-02i2c: uniphier: issue STOP only for last message or I2C_M_STOPMasahiro Yamada1-5/+2
This driver currently emits a STOP if the next message is not I2C_MD_RD. It should not do it because it disturbs the I2C_RDWR ioctl, where read/write transactions are combined without STOP between. Issue STOP only when the message is the last one _or_ flagged with I2C_M_STOP. Fixes: dd6fd4a32793 ("i2c: uniphier: add UniPhier FIFO-less I2C driver") Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2018-08-30i2c: sh_mobile: fix leak when using DMA bounce bufferWolfram Sang1-2/+4
We only freed the bounce buffer after successful DMA, missing the cases where DMA setup may have gone wrong. Use a better location which always gets called after each message and use 'stop_after_dma' as a flag for a successful transfer. Signed-off-by: Wolfram Sang <[email protected]> Reviewed-by: Niklas Söderlund <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2018-08-30i2c: sh_mobile: define start_ch() void as it only returns 0 anyhowWolfram Sang1-6/+3
After various refactoring over the years, start_ch() doesn't return errno anymore, so make the function return void. This saves the error handling when calling it which in turn eases cleanup of resources of a future patch. Signed-off-by: Wolfram Sang <[email protected]> Reviewed-by: Niklas Söderlund <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2018-08-30i2c: refactor function to release a DMA safe bufferWolfram Sang2-6/+7
a) rename to 'put' instead of 'release' to match 'get' when obtaining the buffer b) change the argument order to have the buffer as first argument c) add a new argument telling the function if the message was transferred. This allows the function to be used also in cases where setting up DMA failed, so the buffer needs to be freed without syncing to the message buffer. Also convert the only user. Signed-off-by: Wolfram Sang <[email protected]> Reviewed-by: Niklas Söderlund <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2018-08-30i2c: algos: bit: make the error messages grepableJan Kundrát1-24/+31
Yep, I went looking for one of these, and I wasn't able to find it easily. That's worse than a line which is 82-chars long, IMHO. Signed-off-by: Jan Kundrát <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2018-08-30i2c: designware: Re-init controllers with pm_disabled set on resumeHans de Goede2-2/+6
On Bay Trail and Cherry Trail devices we set the pm_disabled flag for I2C busses which the OS shares with the PUNIT as these need special handling. Until now we called dev_pm_syscore_device(dev, true) for I2C controllers with this flag set to keep these I2C controllers always on. After commit 12864ff8545f ("ACPI / LPSS: Avoid PM quirks on suspend and resume from hibernation"), this no longer works. This commit modifies lpss_iosf_exit_d3_state() to only run if lpss_iosf_enter_d3_state() has ran before it, so that it does not run on a resume from hibernate (or from S3). On these systems the conditions for lpss_iosf_enter_d3_state() to run never become true, so lpss_iosf_exit_d3_state() never gets called and the 2 LPSS DMA controllers never get forced into D0 mode, instead they are left in their default automatic power-on when needed mode. The not forcing of D0 mode for the DMA controllers enables these systems to properly enter S0ix modes, which is a good thing. But after entering S0ix modes the I2C controller connected to the PMIC no longer works, leading to e.g. broken battery monitoring. The _PS3 method for this I2C controller looks like this: Method (_PS3, 0, NotSerialized) // _PS3: Power State 3 { If ((((PMID == 0x04) || (PMID == 0x05)) || (PMID == 0x06))) { Return (Zero) } PSAT |= 0x03 Local0 = PSAT /* \_SB_.I2C5.PSAT */ } Where PMID = 0x05, so we enter the Return (Zero) path on these systems. So even if we were to not call dev_pm_syscore_device(dev, true) the I2C controller will be left in D0 rather then be switched to D3. Yet on other Bay and Cherry Trail devices S0ix is not entered unless *all* I2C controllers are in D3 mode. This combined with the I2C controller no longer working now that we reach S0ix states on these systems leads to me believing that the PUNIT itself puts the I2C controller in D3 when all other conditions for entering S0ix states are true. Since now the I2C controller is put in D3 over a suspend/resume we must re-initialize it afterwards and that does indeed fix it no longer working. This commit implements this fix by: 1) Making the suspend_late callback a no-op if pm_disabled is set and making the resume_early callback skip the clock re-enable (since it now was not disabled) while still doing the necessary I2C controller re-init. 2) Removing the dev_pm_syscore_device(dev, true) call, so that the suspend and resume callbacks are actually called. Normally this would cause the ACPI pm code to call _PS3 putting the I2C controller in D3, wreaking havoc since it is shared with the PUNIT, but in this special case the _PS3 method is a no-op so we can safely allow a "fake" suspend / resume. Fixes: 12864ff8545f ("ACPI / LPSS: Avoid PM quirks on suspend and resume ...") Link: https://bugzilla.kernel.org/show_bug.cgi?id=200861 Cc: 4.15+ <[email protected]> # 4.15+ Signed-off-by: Hans de Goede <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Acked-by: Jarkko Nikula <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2018-08-30i2c: i801: Allow ACPI AML access I/O ports not reserved for SMBusMika Westerberg1-1/+8
Commit 7ae81952cda ("i2c: i801: Allow ACPI SystemIO OpRegion to conflict with PCI BAR") made it possible for AML code to access SMBus I/O ports by installing custom SystemIO OpRegion handler and blocking i80i driver access upon first AML read/write to this OpRegion. However, while ThinkPad T560 does have SystemIO OpRegion declared under the SMBus device, it does not access any of the SMBus registers: Device (SMBU) { ... OperationRegion (SMBP, PCI_Config, 0x50, 0x04) Field (SMBP, DWordAcc, NoLock, Preserve) { , 5, TCOB, 11, Offset (0x04) } Name (TCBV, 0x00) Method (TCBS, 0, NotSerialized) { If ((TCBV == 0x00)) { TCBV = (\_SB.PCI0.SMBU.TCOB << 0x05) } Return (TCBV) /* \_SB_.PCI0.SMBU.TCBV */ } OperationRegion (TCBA, SystemIO, TCBS (), 0x10) Field (TCBA, ByteAcc, NoLock, Preserve) { Offset (0x04), , 9, CPSC, 1 } } Problem with the current approach is that it blocks all I/O port access and because this system has touchpad connected to the SMBus controller after first AML access (happens during suspend/resume cycle) the touchpad fails to work anymore. Fix this so that we allow ACPI AML I/O port access if it does not touch the region reserved for the SMBus. Fixes: 7ae81952cda ("i2c: i801: Allow ACPI SystemIO OpRegion to conflict with PCI BAR") Link: https://bugzilla.kernel.org/show_bug.cgi?id=200737 Reported-by: Yussuf Khalil <[email protected]> Signed-off-by: Mika Westerberg <[email protected]> Reviewed-by: Jean Delvare <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2018-08-24i2c: don't use any __deprecated handling anymoreSedat Dilek1-1/+0
This can be dropped with commit 771c035372a036f83353eef46dbb829780330234 ("deprecate the '__deprecated' attribute warnings entirely and for good") now in upstream. And we got rid of the last __deprecated use, too. Signed-off-by: Sedat Dilek <[email protected]> [wsa: shortened commit message to reflect the current situation] Signed-off-by: Wolfram Sang <[email protected]>
2018-08-24i2c: use SPDX identifier for Renesas driversWolfram Sang5-30/+5
Signed-off-by: Wolfram Sang <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2018-08-24i2c: ocores: update my email addressPeter Korsgaard1-2/+2
The old @sunsite.dk address is no longer active, so update the references. Signed-off-by: Peter Korsgaard <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2018-08-24i2c: remove deprecated attach_adapter callbackWolfram Sang1-10/+1
There aren't any users left. Remove this callback from the 2.4 times. Phew, finally, that took years to reach... Signed-off-by: Wolfram Sang <[email protected]>
2018-08-21Merge branch 'i2c/for-4.19' of ↵Linus Torvalds37-593/+2572
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull i2c updates from Wolfram Sang: - the core has now a lockless variant of i2c_smbus_xfer. Some open coded versions of this got removed in drivers. This also enables proper SCCB support in regmap. - locking got a more precise naming. i2c_{un}lock_adapter() had to go, and we know use i2c_lock_bus() consistently with flags like I2C_LOCK_ROOT_ADAPTER and I2C_LOCK_SEGMENT to avoid ambiguity. - the gpio fault injector got a new delicate testcase - the bus recovery procedure got fixed to handle the new testcase correctly - a new quirk flag for controllers not able to handle zero length messages together with driver updates to use it - new drivers: FSI bus attached I2C masters, GENI I2C controller, Owl family S900 - and a good set of driver improvements and bugfixes * 'i2c/for-4.19' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: (77 commits) i2c: rcar: implement STOP and REP_START according to docs i2c: rcar: refactor private flags i2c: core: ACPI: Make acpi_gsb_i2c_read_bytes() check i2c_transfer return value i2c: core: ACPI: Properly set status byte to 0 for multi-byte writes dt-bindings: i2c: rcar: Add r8a774a1 support dt-bindings: i2c: sh_mobile: Add r8a774a1 support i2c: imx: Simplify stopped state tracking i2c: imx: Fix race condition in dma read i2c: pasemi: remove hardcoded bus numbers on smbus i2c: designware: Add SPDX license tag i2c: designware: Convert to use struct i2c_timings i2c: core: Parse SDA hold time from firmware i2c: designware-pcidrv: Mark expected switch fall-through i2c: amd8111: Mark expected switch fall-through i2c: sh_mobile: use core to detect 'no zero length read' quirk i2c: xlr: use core to detect 'no zero length' quirk i2c: rcar: use core to detect 'no zero length' quirk i2c: stu300: use core to detect 'no zero length' quirk i2c: pmcmsp: use core to detect 'no zero length' quirk i2c: mxs: use core to detect 'no zero length' quirk ...
2018-08-20i2c: rcar: implement STOP and REP_START according to docsWolfram Sang1-14/+20
When doing a REP_START after a read message, the driver used to trigger a STOP first which would then be overwritten by REP_START. This was the only stable method found when doing the last refactoring. However, this was not in accordance with the documentation. After research from our BSP team and myself, we now can implement a version which works and is according to the documentation. The new approach ensures the ICMCR register is only changed when really needed. Tested on a R-Car Gen2 (H2) and Gen3 with DMA (M3N). Signed-off-by: Hiromitsu Yamasaki <[email protected]> Signed-off-by: Wolfram Sang <[email protected]> Reviewed-by: Ulrich Hecht <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2018-08-20i2c: rcar: refactor private flagsWolfram Sang1-3/+4
Use BIT macro to avoid shift-31-problem, indent a little more and use GENMASK to make it easier to add new flags. Signed-off-by: Wolfram Sang <[email protected]> Reviewed-by: Ulrich Hecht <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2018-08-20i2c: core: ACPI: Make acpi_gsb_i2c_read_bytes() check i2c_transfer return valueHans de Goede1-3/+5
Currently acpi_gsb_i2c_read_bytes() directly returns i2c_transfer's return value. i2c_transfer returns a value < 0 on error and 2 (for 2 successfully executed transfers) on success. But the ACPI code expects 0 on success, so currently acpi_gsb_i2c_read_bytes()'s caller does: if (status > 0) status = 0; This commit makes acpi_gsb_i2c_read_bytes() return a value which can be directly consumed by the ACPI code, mirroring acpi_gsb_i2c_write_bytes(), this commit also makes acpi_gsb_i2c_read_bytes() explitcly check that i2c_transfer returns 2, rather then accepting any value > 0. Signed-off-by: Hans de Goede <[email protected]> Acked-by: Mika Westerberg <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2018-08-20i2c: core: ACPI: Properly set status byte to 0 for multi-byte writesHans de Goede1-3/+8
acpi_gsb_i2c_write_bytes() returns i2c_transfer()'s return value, which is the number of transfers executed on success, so 1. The ACPI code expects us to store 0 in gsb->status for success, not 1. Specifically this breaks the following code in the Thinkpad 8 DSDT: ECWR = I2CW = ECWR /* \_SB_.I2C1.BAT0.ECWR */ If ((ECST == Zero)) { ECRD = I2CR /* \_SB_.I2C1.I2CR */ } Before this commit we set ECST to 1, causing the read to never happen breaking battery monitoring on the Thinkpad 8. This commit makes acpi_gsb_i2c_write_bytes() return 0 when i2c_transfer() returns 1, so the single write transfer completed successfully, and makes it return -EIO on for other (unexpected) return values >= 0. Cc: [email protected] Signed-off-by: Hans de Goede <[email protected]> Acked-by: Mika Westerberg <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2018-08-20i2c: imx: Simplify stopped state trackingEsben Haabendal1-8/+7
Always update the stopped state when busy status have been checked. This is identical to what was done before, with the exception of error handling. Without this change, some errors cause the stopped state to be left in incorrect state in i2c_imx_stop(), i2c_imx_dma_read(), i2c_imx_read() and i2c_imx_xfer(). Signed-off-by: Esben Haabendal <[email protected]> Acked-by: Uwe Kleine-König <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2018-08-20i2c: imx: Fix race condition in dma readEsben Haabendal1-4/+4
This fixes a race condition, where the DMAEN bit ends up being set after I2C slave has transmitted a byte following the dummy read. When that happens, an interrupt is generated instead, and no DMA request is generated to kickstart the DMA read, and a timeout happens after DMA_TIMEOUT (1 sec). Fixed by setting the DMAEN bit before the dummy read. Signed-off-by: Esben Haabendal <[email protected]> Acked-by: Uwe Kleine-König <[email protected]> Signed-off-by: Wolfram Sang <[email protected]> Cc: [email protected]
2018-08-20i2c: pasemi: remove hardcoded bus numbers on smbusDarren Stevens1-2/+1
The pasemi smbus controller uses PCI_FUNC(dev->devfn) to define which number bus to attach to, however this fails when something else is probed first, for example an ATI Radeon graphics card will claim 9 or 10 busses, including the ones the pasemi wants. Patch the driver to call i2c_add_adapter rather than i2c_add_numbered_adapter. Signed-off-by: Darren Stevens <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2018-08-20i2c: designware: Add SPDX license tagAndy Shevchenko7-94/+7
Replace short statement in comment with proper SPDX license tag. Note, for i2c-desingware-slave.c the identifier is chosen in accordance with MODULE_LICENSE() macro since it is visible to user. Another point to this choice is that the header seems to be copy'n'paste from the other file of this very driver. Acked-by: Luis Oliveira <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Acked-by: Jarkko Nikula <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2018-08-14Merge tag 'regmap-v4.19' of ↵Linus Torvalds1-8/+20
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap Pull regmap updates from Mark Brown: "Several small new features for regmap this time around: - Support for SCCB, an I2C variant used on some media cards. This has also pulled in an I2C commit from Peter Rosin as a dependency. - Addition of an API for reading repeatedly from registers where the address doesn't automatically increment like some ADC outputs or GPIO status registers. - Support for bulk I/O on Slimbus" * tag 'regmap-v4.19' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap: regmap: Add regmap_noinc_read API regmap: sccb: fix typo and sort headers alphabetically i2c: smbus: add unlocked __i2c_smbus_xfer variant regmap: add SCCB support regmap: slimbus: add support to multi read/write
2018-08-09i2c: xlp9xx: Fix case where SSIF read transaction completes earlyGeorge Cherian1-13/+28
During ipmi stress tests we see occasional failure of transactions at the boot time. This happens in the case of a I2C_M_RECV_LEN transactions, when the read transfer completes (with the initial read length of 34) before the driver gets a chance to handle interrupts. The current driver code expects at least 2 interrupts for I2C_M_RECV_LEN transactions. The length is updated during the first interrupt, and the buffer contents are only copied during subsequent interrupts. In case of just one interrupt, we will complete the transaction without copying out the bytes from RX fifo. Update the code to drain the RX fifo after the length update, so that the transaction completes correctly in all cases. Signed-off-by: George Cherian <[email protected]> Signed-off-by: Wolfram Sang <[email protected]> Cc: [email protected]
2018-08-09Merge branch 'regmap-4.19' into regmap-nextMark Brown1-8/+20
2018-08-08i2c: designware: Convert to use struct i2c_timingsAndy Shevchenko3-34/+33
Instead of using custom variables and parser, convert the driver to use the ones provided by I2C core. No functional change intended. Signed-off-by: Andy Shevchenko <[email protected]> Reviewed-by: Alexandre Belloni <[email protected]> Tested-by: Alexandre Belloni <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2018-08-08i2c: core: Parse SDA hold time from firmwareAndy Shevchenko1-0/+2
There are two drivers already using the SDA hold time setting. It might be more in the future, thus, make I2C core to parse the setting for us if provided by firmware. Signed-off-by: Andy Shevchenko <[email protected]> Tested-by: Alexandre Belloni <[email protected]> Reviewed-by: Alexandre Belloni <[email protected]> Acked-by: Ludovic Desroches <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2018-08-08i2c: designware-pcidrv: Mark expected switch fall-throughGustavo A. R. Silva1-0/+1
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Signed-off-by: Gustavo A. R. Silva <[email protected]> Acked-by: Andy Shevchenko <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2018-08-08i2c: amd8111: Mark expected switch fall-throughGustavo A. R. Silva1-0/+1
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Signed-off-by: Gustavo A. R. Silva <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2018-08-04i2c: sh_mobile: use core to detect 'no zero length read' quirkWolfram Sang1-5/+5
And don't reimplement in the driver. Signed-off-by: Wolfram Sang <[email protected]> Reviewed-by: Niklas Söderlund <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2018-08-04i2c: xlr: use core to detect 'no zero length' quirkWolfram Sang1-6/+5
And don't reimplement in the driver. Signed-off-by: Wolfram Sang <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2018-08-04i2c: rcar: use core to detect 'no zero length' quirkWolfram Sang1-7/+6
And don't reimplement in the driver. Signed-off-by: Wolfram Sang <[email protected]> Reviewed-by: Niklas Söderlund <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2018-08-04i2c: stu300: use core to detect 'no zero length' quirkWolfram Sang1-6/+6
And don't reimplement in the driver. Signed-off-by: Wolfram Sang <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2018-08-04i2c: pmcmsp: use core to detect 'no zero length' quirkWolfram Sang1-16/+1
And don't reimplement in the driver. Signed-off-by: Wolfram Sang <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2018-08-04i2c: mxs: use core to detect 'no zero length' quirkWolfram Sang1-3/+5
And don't reimplement in the driver. Signed-off-by: Wolfram Sang <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2018-08-04i2c: designware-master: use core to detect 'no zero length' quirkWolfram Sang1-7/+5
And don't reimplement in the driver. Signed-off-by: Wolfram Sang <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Tested-by: Jarkko Nikula <[email protected]> Acked-by: Jarkko Nikula <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2018-08-04i2c: quirks: add zero length checksWolfram Sang1-0/+6
Some adapters do not support a message length of 0. Add this as a quirk so drivers don't have to open code it. Signed-off-by: Wolfram Sang <[email protected]> Reviewed-by: Niklas Söderlund <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Tested-by: Jarkko Nikula <[email protected]> Acked-by: Jarkko Nikula <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2018-08-04i2c: aspeed: Add an explicit type casting for *get_clk_reg_valJae Hyun Yoo1-1/+1
This commit fixes this sparse warning: drivers/i2c/busses/i2c-aspeed.c:875:38: warning: incorrect type in assignment (different modifiers) drivers/i2c/busses/i2c-aspeed.c:875:38: expected unsigned int ( *get_clk_reg_val )( ... ) drivers/i2c/busses/i2c-aspeed.c:875:38: got void const *const data Reported-by: Wolfram Sang <[email protected]> Signed-off-by: Jae Hyun Yoo <[email protected]> Reviewed-by: Brendan Higgins <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2018-08-04Merge branch 'i2c-mux/for-next' of https://github.com/peda-r/i2c-mux into ↵Wolfram Sang1-13/+11
i2c/for-4.19 Simplify the probe function of the pca954x driver
2018-08-04i2c: Add Actions Semiconductor Owl family S900 I2C driverManivannan Sadhasivam3-0/+503
Add Actions Semiconductor Owl family S900 I2C driver. Signed-off-by: Manivannan Sadhasivam <[email protected]> Acked-by: Peter Rosin <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2018-07-31i2c: i2c-qcom-geni: Add bus driver for the Qualcomm GENI I2C controllerKarthikeyan Ramasubramanian3-0/+687
This bus driver supports the GENI based i2c hardware controller in the Qualcomm SOCs. The Qualcomm Generic Interface (GENI) is a programmable module supporting a wide range of serial interfaces including I2C. The driver supports FIFO mode and DMA mode of transfer and switches modes dynamically depending on the size of the transfer. Signed-off-by: Karthikeyan Ramasubramanian <[email protected]> Signed-off-by: Sagar Dharia <[email protected]> Signed-off-by: Girish Mahadevan <[email protected]> Reviewed-by: Douglas Anderson <[email protected]> Reviewed-by: Stephen Boyd <[email protected]> Tested-by: Stephen Boyd <[email protected]> [wsa: squashed the MAINTAINER addition and a RPM fix by Evan Green] Signed-off-by: Wolfram Sang <[email protected]>
2018-07-30Merge branch 'locking-urgent-for-linus' of ↵Linus Torvalds2-3/+3
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull locking fixes from Ingo Molnar: "A paravirt UP-patching fix, and an I2C MUX driver lockdep warning fix" * 'locking-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: locking/pvqspinlock/x86: Use LOCK_PREFIX in __pv_queued_spin_unlock() assembly code i2c/mux, locking/core: Annotate the nested rt_mutex usage locking/rtmutex: Allow specifying a subclass for nested locking
2018-07-30i2c: mux: pca954x: use helper variable in probeLinus Walleij1-13/+11
This creates a struct device *dev helper variable in probe() which IMO makes the code less cluttered and easier to read. Also rename the of_node veriable to the common shortform "np" (node pointer). Signed-off-by: Linus Walleij <[email protected]> [peda: slightly edited commit message and removed some surplus newlines] Signed-off-by: Peter Rosin <[email protected]>
2018-07-25i2c/mux, locking/core: Annotate the nested rt_mutex usagePeter Rosin2-3/+3
If an i2c topology has instances of nested muxes, then a lockdep splat is produced when when i2c_parent_lock_bus() is called. Here is an example: ============================================ WARNING: possible recursive locking detected -------------------------------------------- insmod/68159 is trying to acquire lock: (i2c_register_adapter#2){+.+.}, at: i2c_parent_lock_bus+0x32/0x50 [i2c_mux] but task is already holding lock: (i2c_register_adapter#2){+.+.}, at: i2c_parent_lock_bus+0x32/0x50 [i2c_mux] other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(i2c_register_adapter#2); lock(i2c_register_adapter#2); *** DEADLOCK *** May be due to missing lock nesting notation 1 lock held by insmod/68159: #0: (i2c_register_adapter#2){+.+.}, at: i2c_parent_lock_bus+0x32/0x50 [i2c_mux] stack backtrace: CPU: 13 PID: 68159 Comm: insmod Tainted: G O Call Trace: dump_stack+0x67/0x98 __lock_acquire+0x162e/0x1780 lock_acquire+0xba/0x200 rt_mutex_lock+0x44/0x60 i2c_parent_lock_bus+0x32/0x50 [i2c_mux] i2c_parent_lock_bus+0x3e/0x50 [i2c_mux] i2c_smbus_xfer+0xf0/0x700 i2c_smbus_read_byte+0x42/0x70 my2c_init+0xa2/0x1000 [my2c] do_one_initcall+0x51/0x192 do_init_module+0x62/0x216 load_module+0x20f9/0x2b50 SYSC_init_module+0x19a/0x1c0 SyS_init_module+0xe/0x10 do_syscall_64+0x6c/0x1a0 entry_SYSCALL_64_after_hwframe+0x42/0xb7 Reported-by: John Sperbeck <[email protected]> Tested-by: John Sperbeck <[email protected]> Signed-off-by: Peter Rosin <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Cc: Davidlohr Bueso <[email protected]> Cc: Deepa Dinamani <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Chang <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Philippe Ombredanne <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Will Deacon <[email protected]> Cc: Wolfram Sang <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.