08 Oct, 2020
1 commit
-
* tag 'v5.4.70': (3051 commits)
Linux 5.4.70
netfilter: ctnetlink: add a range check for l3/l4 protonum
ep_create_wakeup_source(): dentry name can change under you...
...Conflicts:
arch/arm/mach-imx/pm-imx6.c
arch/arm64/boot/dts/freescale/imx8mm-evk.dts
arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
drivers/crypto/caam/caamalg.c
drivers/gpu/drm/imx/dw_hdmi-imx.c
drivers/gpu/drm/imx/imx-ldb.c
drivers/gpu/drm/imx/ipuv3/ipuv3-crtc.c
drivers/mmc/host/sdhci-esdhc-imx.c
drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
drivers/net/ethernet/freescale/enetc/enetc.c
drivers/net/ethernet/freescale/enetc/enetc_pf.c
drivers/thermal/imx_thermal.c
drivers/usb/cdns3/ep0.c
drivers/xen/swiotlb-xen.c
sound/soc/fsl/fsl_esai.c
sound/soc/fsl/fsl_sai.cSigned-off-by: Jason Liu
07 Oct, 2020
1 commit
-
[ 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
Acked-by: Jochen Friedrich
Acked-by: Christophe Leroy
Signed-off-by: Wolfram Sang
Signed-off-by: Sasha Levin
01 Oct, 2020
4 commits
-
[ 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
Reviewed-by: Mika Westerberg
Signed-off-by: Wolfram Sang
Signed-off-by: Sasha Levin -
[ Upstream commit 1a1d6db23ddacde0b15ea589e9103373e05af8de ]
Mask the IRQ status to only the bits that the driver checks. This
prevents excessive driver warnings when operating in slave mode
when additional bits are set that the driver doesn't handle.Signed-off-by: Eddie James
Reviewed-by: Tao Ren
Signed-off-by: Wolfram Sang
Signed-off-by: Sasha Levin -
[ Upstream commit 44c99904cf61f945d02ac9976ab10dd5ccaea393 ]
Depending on the board design, the I2C controllers found on Tegra SoCs
may require pinmuxing in order to function. This is done as part of the
driver's runtime suspend/resume operations. However, the PM core does
not allow devices to go into runtime suspend during system sleep to
avoid potential races with the suspend/resume of their parents.As a result of this, when Tegra SoCs resume from system suspend, their
I2C controllers may have lost the pinmux state in hardware, whereas the
pinctrl subsystem is not aware of this. To fix this, make sure that if
the I2C controller is not runtime suspended, the runtime suspend code is
still executed in order to disable the module clock (which we don't need
to be enabled during sleep) and set the pinmux to the idle state.Conversely, make sure that the I2C controller is properly resumed when
waking up from sleep so that pinmux settings are properly restored.This fixes a bug seen with DDC transactions to an HDMI monitor timing
out when resuming from system suspend.Signed-off-by: Thierry Reding
Signed-off-by: Sasha Levin -
[ Upstream commit b5d5605ca3cebb9b16c4f251635ef171ad18b80d ]
Potentially it is possible that interrupt may fire after transfer timeout.
That may not end up well for the next transfer because interrupt handling
may race with hardware resetting.This is very unlikely to happen in practice, but anyway let's prevent the
potential problem by enabling interrupt only at the moments when it is
actually necessary to get some interrupt event.Tested-by: Thierry Reding
Signed-off-by: Dmitry Osipenko
Signed-off-by: Wolfram Sang
Signed-off-by: Sasha Levin
23 Sep, 2020
3 commits
-
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
Signed-off-by: Jean Delvare
Signed-off-by: Wolfram Sang
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 6eb158ec0a45dbfd98bc6971c461b7d4d5bf61b3 ]
The driver-specific usage of the DMA_CTRL_ACK flag was replaced with a
custom flag in commit ceeeb99cd821 ("dmaengine: mxs: rename custom flag"),
but i2c-mxs was not updated to use the new flag, completely breaking I2C
transactions using DMA.Fixes: ceeeb99cd821 ("dmaengine: mxs: rename custom flag")
Signed-off-by: Matthias Schiffer
Reviewed-by: Fabio Estevam
Signed-off-by: Wolfram Sang
Signed-off-by: Sasha Levin -
[ Upstream commit 0a355aeb24081e4538d4d424cd189f16c0bbd983 ]
If something goes wrong (such as the SCL being stuck low) then we need
to reset the PCA chip. The issue with this is that on reset we lose all
config settings and the chip ends up in a disabled state which results
in a lock up/high CPU usage. We need to re-apply any configuration that
had previously been set and re-enable the chip.Signed-off-by: Evan Nimmo
Reviewed-by: Chris Packham
Reviewed-by: Andy Shevchenko
Signed-off-by: Wolfram Sang
Signed-off-by: Sasha Levin
03 Sep, 2020
2 commits
-
[ Upstream commit 914a7b3563b8fb92f976619bbd0fa3a4a708baae ]
Currently, a NACK in slave mode is set/cleared when SCL is held low by
the IP core right before the bit is about to be pushed out. This is too
late for clearing and then a NACK from the previous byte is still used
for the current one. Now, let's clear the NACK right after we detected
the STOP condition following the NACK.Fixes: de20d1857dd6 ("i2c: rcar: add slave support")
Signed-off-by: Wolfram Sang
Signed-off-by: Wolfram Sang
Signed-off-by: Sasha Levin -
[ Upstream commit e3cb82c6d6f6c27ab754e13ae29bdd6b949982e2 ]
When commit c64ffff7a9d1 ("i2c: core: Allow empty id_table in ACPI case
as well") fixed the enumeration of I²C devices on ACPI enabled platforms
when driver has no ID table, it missed the PRP0001 support.i2c_device_match() and i2c_acpi_match_device() differently match
driver against given device. Use acpi_driver_match_device(), that is used
in the former, in i2c_device_probe() and don't fail PRP0001 enumeration
when no ID table exist.Fixes: c64ffff7a9d1 ("i2c: core: Allow empty id_table in ACPI case as well")
BugLink: https://stackoverflow.com/q/63519678/2511795
Signed-off-by: Andy Shevchenko
Reviewed-by: Mika Westerberg
Signed-off-by: Wolfram Sang
Signed-off-by: Sasha Levin
27 Aug, 2020
1 commit
-
Claim clkhi and clklo as integer type to avoid possible calculation
errors caused by data overflow.Reviewed-by: Fugang Duan
Signed-off-by: Clark Wang
21 Aug, 2020
3 commits
-
[ Upstream commit b1eef236f50ba6afea680da039ef3a2ca9c43d11 ]
When i2c client unregisters, synchronize irq before setting
iproc_i2c->slave to NULL.(1) disable_irq()
(2) Mask event enable bits in control reg
(3) Erase slave address (avoid further writes to rx fifo)
(4) Flush tx and rx FIFOs
(5) Clear pending event (interrupt) bits in status reg
(6) enable_irq()
(7) Set client pointer to NULLUnable to handle kernel NULL pointer dereference at virtual address 0000000000000318
[ 371.020421] pc : bcm_iproc_i2c_isr+0x530/0x11f0
[ 371.025098] lr : __handle_irq_event_percpu+0x6c/0x170
[ 371.030309] sp : ffff800010003e40
[ 371.033727] x29: ffff800010003e40 x28: 0000000000000060
[ 371.039206] x27: ffff800010ca9de0 x26: ffff800010f895df
[ 371.044686] x25: ffff800010f18888 x24: ffff0008f7ff3600
[ 371.050165] x23: 0000000000000003 x22: 0000000001600000
[ 371.055645] x21: ffff800010f18888 x20: 0000000001600000
[ 371.061124] x19: ffff0008f726f080 x18: 0000000000000000
[ 371.066603] x17: 0000000000000000 x16: 0000000000000000
[ 371.072082] x15: 0000000000000000 x14: 0000000000000000
[ 371.077561] x13: 0000000000000000 x12: 0000000000000001
[ 371.083040] x11: 0000000000000000 x10: 0000000000000040
[ 371.088519] x9 : ffff800010f317c8 x8 : ffff800010f317c0
[ 371.093999] x7 : ffff0008f805b3b0 x6 : 0000000000000000
[ 371.099478] x5 : ffff0008f7ff36a4 x4 : ffff8008ee43d000
[ 371.104957] x3 : 0000000000000000 x2 : ffff8000107d64c0
[ 371.110436] x1 : 00000000c00000af x0 : 0000000000000000[ 371.115916] Call trace:
[ 371.118439] bcm_iproc_i2c_isr+0x530/0x11f0
[ 371.122754] __handle_irq_event_percpu+0x6c/0x170
[ 371.127606] handle_irq_event_percpu+0x34/0x88
[ 371.132189] handle_irq_event+0x40/0x120
[ 371.136234] handle_fasteoi_irq+0xcc/0x1a0
[ 371.140459] generic_handle_irq+0x24/0x38
[ 371.144594] __handle_domain_irq+0x60/0xb8
[ 371.148820] gic_handle_irq+0xc0/0x158
[ 371.152687] el1_irq+0xb8/0x140
[ 371.155927] arch_cpu_idle+0x10/0x18
[ 371.159615] do_idle+0x204/0x290
[ 371.162943] cpu_startup_entry+0x24/0x60
[ 371.166990] rest_init+0xb0/0xbc
[ 371.170322] arch_call_rest_init+0xc/0x14
[ 371.174458] start_kernel+0x404/0x430Fixes: c245d94ed106 ("i2c: iproc: Add multi byte read-write support for slave mode")
Signed-off-by: Dhananjay Phadke
Reviewed-by: Florian Fainelli
Acked-by: Ray Jui
Signed-off-by: Wolfram Sang
Signed-off-by: Sasha Levin -
[ Upstream commit c7c9e914f9a0478fba4dc6f227cfd69cf84a4063 ]
Due to the lockless design of the driver, it is theoretically possible
to access a NULL pointer, if a slave interrupt was running while we were
unregistering the slave. To make this rock solid, disable the interrupt
for a short time while we are clearing the interrupt_enable register.
This patch is purely based on code inspection. The OOPS is super-hard to
trigger because clearing SAR (the address) makes interrupts even more
unlikely to happen as well. While here, reinit SCR to SDBS because this
bit should always be set according to documentation. There is no effect,
though, because the interface is disabled.Fixes: 7b814d852af6 ("i2c: rcar: avoid race when unregistering slave client")
Signed-off-by: Wolfram Sang
Reviewed-by: Niklas Söderlund
Signed-off-by: Wolfram Sang
Signed-off-by: Sasha Levin -
[ Upstream commit 314139f9f0abdba61ed9a8463bbcb0bf900ac5a2 ]
When the SSR interrupt is activated, it will detect every STOP condition
on the bus, not only the ones after we have been addressed. So, enable
this interrupt only after we have been addressed, and disable it
otherwise.Fixes: de20d1857dd6 ("i2c: rcar: add slave support")
Signed-off-by: Wolfram Sang
Signed-off-by: Wolfram Sang
Signed-off-by: Sasha Levin
20 Aug, 2020
1 commit
-
The clkhi and clklo ratio was not very precise before that can make the
time of START/STOP/HIGH LEVEL out of specification.Therefore, the calculation of these times has been modified in this patch.
At the same time, the mode rate definition of i2c is corrected.Signed-off-by: Clark Wang
11 Aug, 2020
2 commits
-
[ Upstream commit 8808981baf96e1b3dea1f08461e4d958aa0dbde1 ]
Signed-off-by: Wolfram Sang
Reviewed-by: Alain Volmat
Signed-off-by: Wolfram Sang
Signed-off-by: Sasha Levin -
[ Upstream commit 1b1be3bf27b62f5abcf85c6f3214bdb9c7526685 ]
Add check for ERR_PTR and simplify code while here.
Signed-off-by: Wolfram Sang
Reviewed-by: Alain Volmat
Signed-off-by: Wolfram Sang
Signed-off-by: Sasha Levin
05 Aug, 2020
1 commit
-
[ Upstream commit 0db9254d6b896b587759e2c844c277fb1a6da5b9 ]
This reverts commit d358def706880defa4c9e87381c5bf086a97d5f9.
There are two issues with "i2c: cadence: Fix the hold bit setting" commit.
1. In case of combined message request from user space, when the HOLD
bit is cleared in cdns_i2c_mrecv function, a STOP condition is sent
on the bus even before the last message is started. This is because when
the HOLD bit is cleared, the FIFOS are empty and there is no pending
transfer. The STOP condition should occur only after the last message
is completed.2. The code added by the commit is redundant. Driver is handling the
setting/clearing of HOLD bit in right way before the commit.The setting of HOLD bit based on 'bus_hold_flag' is taken care in
cdns_i2c_master_xfer function even before cdns_i2c_msend/cdns_i2c_recv
functions.The clearing of HOLD bit is taken care at the end of cdns_i2c_msend and
cdns_i2c_recv functions based on bus_hold_flag and byte count.
Since clearing of HOLD bit is done after the slave address is written to
the register (writing to address register triggers the message transfer),
it is ensured that STOP condition occurs at the right time after
completion of the pending transfer (last message).Signed-off-by: Raviteja Narayanam
Acked-by: Michal Simek
Signed-off-by: Wolfram Sang
Signed-off-by: Sasha Levin
29 Jul, 2020
2 commits
-
[ Upstream commit 02b9aec59243c6240fc42884acc958602146ddf6 ]
When I have KASAN enabled on my kernel and I start stressing the
touchscreen my system tends to hang. The touchscreen is one of the
only things that does a lot of big i2c transfers and ends up hitting
the DMA paths in the geni i2c driver. It appears that KASAN adds
enough delay in my system to tickle a race condition in the DMA setup
code.When the system hangs, I found that it was running the geni_i2c_irq()
over and over again. It had these:m_stat = 0x04000080
rx_st = 0x30000011
dm_tx_st = 0x00000000
dm_rx_st = 0x00000000
dma = 0x00000001Notably we're in DMA mode but are getting M_RX_IRQ_EN and
M_RX_FIFO_WATERMARK_EN over and over again.Putting some traces in geni_i2c_rx_one_msg() showed that when we
failed we were getting to the start of geni_i2c_rx_one_msg() but were
never executing geni_se_rx_dma_prep().I believe that the problem here is that we are starting the geni
command before we run geni_se_rx_dma_prep(). If a transfer makes it
far enough before we do that then we get into the state I have
observed. Let's change the order, which seems to work fine.Although problems were seen on the RX path, code inspection suggests
that the TX should be changed too. Change it as well.Fixes: 37692de5d523 ("i2c: i2c-qcom-geni: Add bus driver for the Qualcomm GENI I2C controller")
Signed-off-by: Douglas Anderson
Tested-by: Sai Prakash Ranjan
Reviewed-by: Akash Asthana
Reviewed-by: Stephen Boyd
Reviewed-by: Mukesh Kumar Savaliya
Signed-off-by: Wolfram Sang
Signed-off-by: Sasha Levin -
[ Upstream commit eb01597158ffb1853a7a7fc2c57d4c844640f75e ]
On R-Car Gen2, we get a timeout when reading from the address set in
ICSAR, even though the slave interface is disabled. Clearing it fixes
this situation. Note that Gen3 is not affected.To reproduce: bind and undbind an I2C slave on some bus, run
'i2cdetect' on that bus.Fixes: de20d1857dd6 ("i2c: rcar: add slave support")
Signed-off-by: Wolfram Sang
Signed-off-by: Wolfram Sang
Signed-off-by: Sasha Levin
22 Jul, 2020
1 commit
-
[ Upstream commit 5f90786b31fb7d1e199a8999d46c4e3aea672e11 ]
The driver can't be loaded automatically because it misses
module alias to be provided. Add corresponding MODULE_DEVICE_TABLE()
call to the driver.Signed-off-by: Andy Shevchenko
Signed-off-by: Wolfram Sang
Signed-off-by: Sasha Levin
09 Jul, 2020
2 commits
-
[ Upstream commit 597911287fcd13c3a4b4aa3e0a52b33d431e0a8e ]
I2C_SMBUS_BLOCK_MAX defines already the maximum number as defined in the
SMBus 2.0 specs. I don't see a reason to add 1 here. Also, fix the errno
to what is suggested for this error.Fixes: c9bfdc7c16cb ("i2c: mlxcpld: Add support for smbus block read transaction")
Signed-off-by: Wolfram Sang
Reviewed-by: Michael Shych
Tested-by: Michael Shych
Signed-off-by: Wolfram Sang
Signed-off-by: Sasha Levin -
[ Upstream commit cd217f2300793a106b49c7dfcbfb26e348bc7593 ]
The PCA9665 datasheet says that I2CSTA = 78h indicates that SCL is stuck
low, this differs to the PCA9564 which uses 90h for this indication.
Treat either 0x78 or 0x90 as an indication that the SCL line is stuck.Based on looking through the PCA9564 and PCA9665 datasheets this should
be safe for both chips. The PCA9564 should not return 0x78 for any valid
state and the PCA9665 should not return 0x90.Fixes: eff9ec95efaa ("i2c-algo-pca: Add PCA9665 support")
Signed-off-by: Chris Packham
Reviewed-by: Andy Shevchenko
Signed-off-by: Wolfram Sang
Signed-off-by: Sasha Levin
01 Jul, 2020
3 commits
-
[ Upstream commit 40e05200593af06633f64ab0effff052eee6f076 ]
If the i2c bus driver ignores the I2C_M_RECV_LEN flag (as some of
them do), it is possible for an I2C_SMBUS_BLOCK_DATA read issued
on some random device to return an arbitrary value in the first
byte (and nothing else). When this happens, i2c_smbus_xfer_emulated()
will happily write past the end of the supplied data buffer, thus
causing Bad Things to happen. To prevent this, check the size
before copying the data block and return an error if it is too large.Fixes: 209d27c3b167 ("i2c: Emulate SMBus block read over I2C")
Signed-off-by: Mans Rullgard
[wsa: use better errno]
Signed-off-by: Wolfram Sang
Signed-off-by: Sasha Levin -
[ Upstream commit 502035e284cc7e9efef22b01771d822d49698ab9 ]
The port number field in the status register was not correct, so fix it.
Fixes: d6ffb6300116 ("i2c: Add FSI-attached I2C master algorithm")
Signed-off-by: Eddie James
Signed-off-by: Joel Stanley
Signed-off-by: Wolfram Sang
Signed-off-by: Sasha Levin -
[ Upstream commit 78ad73421831247e46c31899a7bead02740e4bef ]
This reverts commit 9f42de8d4ec2304f10bbc51dc0484f3503d61196.
It's not safe to use pm_runtime_force_{suspend,resume}(), especially
during the noirq phase of suspend. See also the guidance provided in
commit 1e2ef05bb8cf ("PM: Limit race conditions between runtime PM
and system sleep (v2)").Signed-off-by: Thierry Reding
Signed-off-by: Sasha Levin
24 Jun, 2020
4 commits
-
[ Upstream commit cdb555397f438592bab00599037c347b700cf397 ]
This has been found by the Kernel Test Robot:
http://lkml.iu.edu/hypermail/linux/kernel/2006.0/06862.htmlWith CONFIG_AMIGA_PCMCIA=n, io_mm.h does not pull in amigahw.h and
ZTWO_VADDR is undefined. Add forgotten include to i2c-icy.cFixes: 4768e90ecaec ("i2c: Add i2c-icy for I2C on m68k/Amiga")
Reported-by: kernel test robot
Signed-off-by: Max Staudt
Signed-off-by: Wolfram Sang
Signed-off-by: Sasha Levin -
[ Upstream commit 88b73ee7ca4c90baf136ed5a8377fc5a9b73ac08 ]
The IRQ log output is supposed to appear on a single line. However,
commit 3a2dc1677b60 ("i2c: pxa: Update debug function to dump more info
on error") resulted in it being printed one-entry-per-line, which is
excessively long.Fixing this is not a trivial matter; using pr_cont() doesn't work as
the previous dev_dbg() may not have been compiled in, or may be
dynamic.Since the rest of this function output is at error level, and is also
debug output, promote this to error level as well to avoid this
problem.Reduce the number of always zero prefix digits to save screen real-
estate.Signed-off-by: Russell King
Signed-off-by: Wolfram Sang
Signed-off-by: Sasha Levin -
[ Upstream commit e81c979f4e071d516aa27cf5a0c3939da00dc1ca ]
If we timeout during a message transfer, the control register may
contain bits that cause an action to be set. Read-modify-writing the
register leaving these bits set may trigger the hardware to attempt
one of these actions unintentionally.Always clear these bits when cleaning up after a message or after
a timeout.Signed-off-by: Russell King
Signed-off-by: Wolfram Sang
Signed-off-by: Sasha Levin -
[ Upstream commit f27237c174fd9653033330e4e532cd9d153ce824 ]
The AMD X370 and other AM4 chipsets (A/B/X 3/4/5 parts) and Threadripper
equivalents have a secondary SMBus controller at I/O port address
0x0B20. This bus is used by several manufacturers to control
motherboard RGB lighting via embedded controllers. I have been using
this bus in my OpenRGB project to control the Aura RGB on many
motherboards and ASRock also uses this bus for their Polychrome RGB
controller.I am not aware of any CZ-compatible platforms which do not have the
second SMBus channel. All of AMD's AM4- and Threadripper- series
chipsets that OpenRGB users have tested appear to have this secondary
bus. I also noticed this secondary bus is present on older AMD
platforms including my FM1 home server.Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202587
Signed-off-by: Adam Honse
Reviewed-by: Jean Delvare
Reviewed-by: Sebastian Reichel
Tested-by: Sebastian Reichel
Signed-off-by: Wolfram Sang
Signed-off-by: Sasha Levin
19 Jun, 2020
1 commit
-
* tag 'v5.4.47': (2193 commits)
Linux 5.4.47
KVM: arm64: Save the host's PtrAuth keys in non-preemptible context
KVM: arm64: Synchronize sysreg state on injecting an AArch32 exception
...Conflicts:
arch/arm/boot/dts/imx6qdl.dtsi
arch/arm/mach-imx/Kconfig
arch/arm/mach-imx/common.h
arch/arm/mach-imx/suspend-imx6.S
arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
arch/powerpc/include/asm/cacheflush.h
drivers/cpufreq/imx6q-cpufreq.c
drivers/dma/imx-sdma.c
drivers/edac/synopsys_edac.c
drivers/firmware/imx/imx-scu.c
drivers/net/ethernet/freescale/fec.h
drivers/net/ethernet/freescale/fec_main.c
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
drivers/net/phy/phy_device.c
drivers/perf/fsl_imx8_ddr_perf.c
drivers/usb/cdns3/gadget.c
drivers/usb/dwc3/gadget.c
include/uapi/linux/dma-buf.hSigned-off-by: Jason Liu
07 Jun, 2020
1 commit
-
[ Upstream commit 5d4c7977499a736f3f80826bdc9744344ad55589 ]
Use a mutex to protect access to idev->msg_len, idev->buf, etc. which
are modified by both altr_i2c_xfer_msg() and altr_i2c_isr().This is the minimal fix for easy backporting. A cleanup to remove the
spinlock will be added later.Signed-off-by: Atsushi Nemoto
Acked-by: Thor Thayer
[wsa: updated commit message]
Signed-off-by: Wolfram Sang
Signed-off-by: Sasha Levin
27 May, 2020
3 commits
-
[ Upstream commit e9d1a0a41d4486955e96552293c1fcf1fce61602 ]
A call to 'i2c_demux_deactivate_master()' is missing in the error handling
path, as already done in the remove function.Fixes: 50a5ba876908 ("i2c: mux: demux-pinctrl: add driver")
Signed-off-by: Christophe JAILLET
Signed-off-by: Wolfram Sang
Signed-off-by: Sasha Levin -
[ Upstream commit 3c3dd56f760da056e821ac177e3ad0de4209a435 ]
In case of the I2C client exposes the flag I2C_CLIENT_HOST_NOTIFY,
pm_runtime_get_sync is called in order to always keep active the
adapter. However later on, pm_runtime_put_sync is never called
within the function in case of an error. This commit add this
error handling.Fixes: 72bfcee11cf8 ("i2c: Prevent runtime suspend of adapter when Host Notify is required")
Signed-off-by: Alain Volmat
Reviewed-by: Jarkko Nikula
Signed-off-by: Wolfram Sang
Signed-off-by: Sasha Levin -
commit 1413ef638abae4ab5621901cf4d8ef08a4a48ba6 upstream.
The struct cdev is embedded in the struct i2c_dev. In the current code,
we would free the i2c_dev struct directly in put_i2c_dev(), but the
cdev is manged by a kobject, and the release of it is not predictable.
So it is very possible that the i2c_dev is freed before the cdev is
entirely released. We can easily get the following call trace with
CONFIG_DEBUG_KOBJECT_RELEASE and CONFIG_DEBUG_OBJECTS_TIMERS enabled.
ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x38
WARNING: CPU: 19 PID: 1 at lib/debugobjects.c:325 debug_print_object+0xb0/0xf0
Modules linked in:
CPU: 19 PID: 1 Comm: swapper/0 Tainted: G W 5.2.20-yocto-standard+ #120
Hardware name: Marvell OcteonTX CN96XX board (DT)
pstate: 80c00089 (Nzcv daIf +PAN +UAO)
pc : debug_print_object+0xb0/0xf0
lr : debug_print_object+0xb0/0xf0
sp : ffff00001292f7d0
x29: ffff00001292f7d0 x28: ffff800b82151788
x27: 0000000000000001 x26: ffff800b892c0000
x25: ffff0000124a2558 x24: 0000000000000000
x23: ffff00001107a1d8 x22: ffff0000116b5088
x21: ffff800bdc6afca8 x20: ffff000012471ae8
x19: ffff00001168f2c8 x18: 0000000000000010
x17: 00000000fd6f304b x16: 00000000ee79de43
x15: ffff800bc0e80568 x14: 79616c6564203a74
x13: 6e6968207473696c x12: 5f72656d6974203a
x11: ffff0000113f0018 x10: 0000000000000000
x9 : 000000000000001f x8 : 0000000000000000
x7 : ffff0000101294cc x6 : 0000000000000000
x5 : 0000000000000000 x4 : 0000000000000001
x3 : 00000000ffffffff x2 : 0000000000000000
x1 : 387fc15c8ec0f200 x0 : 0000000000000000
Call trace:
debug_print_object+0xb0/0xf0
__debug_check_no_obj_freed+0x19c/0x228
debug_check_no_obj_freed+0x1c/0x28
kfree+0x250/0x440
put_i2c_dev+0x68/0x78
i2cdev_detach_adapter+0x60/0xc8
i2cdev_notifier_call+0x3c/0x70
notifier_call_chain+0x8c/0xe8
blocking_notifier_call_chain+0x64/0x88
device_del+0x74/0x380
device_unregister+0x54/0x78
i2c_del_adapter+0x278/0x2d0
unittest_i2c_bus_remove+0x3c/0x80
platform_drv_remove+0x30/0x50
device_release_driver_internal+0xf4/0x1c0
driver_detach+0x58/0xa0
bus_remove_driver+0x84/0xd8
driver_unregister+0x34/0x60
platform_driver_unregister+0x20/0x30
of_unittest_overlay+0x8d4/0xbe0
of_unittest+0xae8/0xb3c
do_one_initcall+0xac/0x450
do_initcall_level+0x208/0x224
kernel_init_freeable+0x2d8/0x36c
kernel_init+0x18/0x108
ret_from_fork+0x10/0x1c
irq event stamp: 3934661
hardirqs last enabled at (3934661): [] debug_exception_exit+0x4c/0x58
hardirqs last disabled at (3934660): [] debug_exception_enter+0xa4/0xe0
softirqs last enabled at (3934654): [] __do_softirq+0x46c/0x628
softirqs last disabled at (3934649): [] irq_exit+0x104/0x118This is a common issue when using cdev embedded in a struct.
Fortunately, we already have a mechanism to solve this kind of issue.
Please see commit 233ed09d7fda ("chardev: add helper function to
register char devs with a struct device") for more detail.In this patch, we choose to embed the struct device into the i2c_dev,
and use the API provided by the commit 233ed09d7fda to make sure that
the release of i2c_dev and cdev are in sequence.Signed-off-by: Kevin Hao
Signed-off-by: Wolfram Sang
Cc: Ben Hutchings
Signed-off-by: Greg Kroah-Hartman
06 May, 2020
3 commits
-
commit c926c87b8e36dcc0ea5c2a0a0227ed4f32d0516a upstream.
In AST2600 there have a slow peripheral bus between CPU and i2c
controller. Therefore GIC i2c interrupt status clear have delay timing,
when CPU issue write clear i2c controller interrupt status. To avoid
this issue, the driver need have read after write clear at i2c ISR.Fixes: f327c686d3ba ("i2c: aspeed: added driver for Aspeed I2C")
Signed-off-by: ryan_chen
Acked-by: Benjamin Herrenschmidt
[wsa: added Fixes tag]
Signed-off-by: Wolfram Sang
Signed-off-by: Greg Kroah-Hartman -
commit 068143a8195fb0fdeea1f3ca430b3db0f6d04a53 upstream.
When slave status is I2C_SLAVE_RX_END, generate I2C_SLAVE_STOP
event to i2c_client.Fixes: c245d94ed106 ("i2c: iproc: Add multi byte read-write support for slave mode")
Signed-off-by: Rayagonda Kokatanur
Signed-off-by: Wolfram Sang
Signed-off-by: Greg Kroah-Hartman -
commit ac2b0813fceaf7cb3d8d46c7b33c90bae9fa49db upstream.
The problem is that we dereference "privdata->pci_dev" when we print
the error messages in amd_mp2_pci_init():dev_err(ndev_dev(privdata), "Failed to enable MP2 PCI device\n");
^^^^^^^^^^^^^^^^^Fixes: 529766e0a011 ("i2c: Add drivers for the AMD PCIe MP2 I2C controller")
Signed-off-by: Dan Carpenter
Signed-off-by: Wolfram Sang
Cc: stable@kernel.org
Signed-off-by: Greg Kroah-Hartman
02 May, 2020
1 commit
-
commit edb2c9dd3948738ef030c32b948543e84f4d3f81 upstream.
device_property_read_u32() returns errno or 0, so we should use the
integer variable 'ret' and not the u32 'val' to hold the retval.Fixes: 0560ad576268 ("i2c: altera: Add Altera I2C Controller driver")
Signed-off-by: Wolfram Sang
Reviewed-by: Thor Thayer
Signed-off-by: Wolfram Sang
Signed-off-by: Greg Kroah-Hartman