- 15 Nov, 2017 4 commits
-
-
Peter Zijlstra authored
[ Upstream commit 1b1d6225 ] Bug was noticed via this warning: WARNING: CPU: 6 PID: 1 at kernel/sched/sched.h:804 detach_task_cfs_rq+0x8e8/0xb80 rq->clock_update_flags < RQCF_ACT_SKIP Modules linked in: CPU: 6 PID: 1 Comm: systemd Not tainted 4.10.0-rc5-00140-g0874170baf55-dirty #1 Hardware name: Supermicro SYS-4048B-TRFT/X10QBi, BIOS 1.0 04/11/2014 Call Trace: dump_stack+0x4d/0x65 __warn+0xcb/0xf0 warn_slowpath_fmt+0x5f/0x80 detach_task_cfs_rq+0x8e8/0xb80 ? allocate_cgrp_cset_links+0x59/0x80 task_change_group_fair+0x27/0x150 sched_change_group+0x48/0xf0 sched_move_task+0x53/0x150 cpu_cgroup_attach+0x36/0x70 cgroup_taskset_migrate+0x175/0x300 cgroup_migrate+0xab/0xd0 cgroup_attach_task+0xf0/0x190 __cgroup_procs_write+0x1ed/0x2f0 cgroup_procs_write+0x14/0x20 cgroup_file_write+0x3f/0x100 kernfs_fop_write+0x104/0x180 __vfs_write+0x37/0x140 vfs_write+0xb8/0x1b0 SyS_write+0x55/0xc0 do_syscall_64+0x61/0x170 entry_SYSCALL64_slow_path+0x25/0x25 Reported-by:
Ingo Molnar <mingo@kernel.org> Reported-by:
Borislav Petkov <bp@alien8.de> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mike Galbraith <efault@gmx.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Sasha Levin <alexander.levin@verizon.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jason Gunthorpe authored
[ Upstream commit d9bf28e2 ] The PCI core will write to the bridge window config multiple times while they are enabled. This can lead to mbus failures like this: mvebu_mbus: cannot add window '4:e8', conflicts with another window mvebu-pcie mbus:pex@e0000000: Could not create MBus window at [mem 0xe0000000-0xe00fffff]: -22 For me this is happening during a hotplug cycle. The PCI core is not changing the values, just writing them twice while active. The patch addresses the general case of any change to an active window, but not atomically. The code is slightly refactored so io and mem can share more of the window logic. Signed-off-by:
Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Acked-by:
Jason Cooper <jason@lakedaemon.net> Signed-off-by:
-
Maciej W. Rozycki authored
[ Upstream commit 879e5a0d ] Fix: WARNING: drivers/video/fbdev/pmag-ba-fb.o(.text+0x308): Section mismatch in reference from the function pmagbafb_probe() to the function .init.text:pmagbafb_erase_cursor() The function pmagbafb_probe() references the function __init pmagbafb_erase_cursor(). This is often because pmagbafb_probe lacks a __init annotation or the annotation of pmagbafb_erase_cursor is wrong. -- a fallout from a missed update from commit 9625b513 ("VIDEO: PMAG-BA: Fix section mismatch") and then commit 48c68c4f ("Drivers: video: remove __dev* attributes.") Signed-off-by:
Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by:
-
Lars-Peter Clausen authored
[ Upstream commit da8892d4 ] The adv7604 driver platform data contains fields for configuring the drive strength of the output pins. When probing the driver through DT these fields are not explicitly initialized, which means they are left at 0. This is a reserved setting for the drive strength configuration though and can cause signal integrity issues. Whether these signal integrity issues are visible depends on the PCB specifics (e.g. the higher the load capacitance for the output the more visible the issue). But it has been observed on existing solutions at high pixel clock rates. Initialize the drive strength settings to the power-on-reset value of the device when probing through devicetree to avoid this issue. Fixes: 0e158be0162b ("adv7604: Add DT support") Signed-off-by:
Lars-Peter Clausen <lars@metafoo.de> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com> Signed-off-by:
-
- 08 Nov, 2017 36 commits
-
-
Greg Kroah-Hartman authored
-
Yan Markman authored
commit cda80a82 upstream. Under heavy system stress mvebu SoC using Cortex A9 sporadically encountered instability issues. The "double linefill" feature of L2 cache was identified as causing dependency between read and write which lead to the deadlock. Especially, it was the cause of deadlock seen under heavy PCIe traffic, as this dependency violates PCIE overtaking rule. Fixes: c8f5a878 ("ARM: mvebu: use DT properties to fine-tune the L2 configuration") Signed-off-by:
Yan Markman <ymarkman@marvell.com> Signed-off-by:
Igal Liberman <igall@marvell.com> Signed-off-by:
Nadav Haklai <nadavh@marvell.com> [gregory.clement@free-electrons.com: reformulate commit log, add Armada 375 and add Fixes tag] Signed-off-by:
Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by:
-
Larry Finger authored
[ Upstream commit 07222e53 ] Sparse reports the following: CHECK drivers/staging/rtl8712/rtl871x_xmit.c drivers/staging/rtl8712/rtl871x_xmit.c:350:44: warning: restricted __le32 degrades to integer drivers/staging/rtl8712/rtl871x_xmit.c:491:23: warning: incorrect type in initializer (different base types) drivers/staging/rtl8712/rtl871x_xmit.c:491:23: expected unsigned short [usertype] *fctrl drivers/staging/rtl8712/rtl871x_xmit.c:491:23: got restricted __le16 *<noident> drivers/staging/rtl8712/rtl871x_xmit.c:580:36: warning: incorrect type in assignment (different base types) drivers/staging/rtl8712/rtl871x_xmit.c:580:36: expected unsigned short [unsigned] [short] [usertype] <noident> drivers/staging/rtl8712/rtl871x_xmit.c:580:36: got restricted __be16 [usertype] <noident> Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
Juergen Gross authored
[ Upstream commit 4e93b648 ] When registering for the Xenstore watch of the node control/sysrq the handler will be called at once. Don't issue an error message if the Xenstore node isn't there, as it will be created only when an event is being triggered. Signed-off-by:
Juergen Gross <jgross@suse.com> Reviewed-by:
Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by:
-
Paul Mackerras authored
[ Upstream commit 18569c1f ] Currently, if the kernel is running on a POWER9 processor under a hypervisor, it will try to use the radix MMU even though it doesn't have the necessary code to use radix under a hypervisor (it doesn't negotiate use of radix, and it doesn't do the H_REGISTER_PROC_TBL hcall). The result is that the guest kernel will crash when it tries to turn on the MMU. This fixes it by looking for the /chosen/ibm,architecture-vec-5 property, and if it exists, clears the radix MMU feature bit, before we decide whether to initialize for radix or HPT. This property is created by the hypervisor as a result of the guest calling the ibm,client-architecture-support method to indicate its capabilities, so it will indicate whether the hypervisor agreed to us using radix. Systems without a hypervisor may have this property also (for example, skiboot creates it), so we check the HV bit in the MSR to see whether we are running as a guest or not. If we are in hypervisor mode, then we can do whatever we like including using the radix MMU. The reason for using this property is that in future, when we have support for using radix under a hypervisor, we will need to check this property to see whether the hypervisor agreed to us using radix. Fixes: 2bfd65e4 ("powerpc/mm/radix: Add radix callbacks for early init routines") Cc: stable@vger.kernel.org # v4.7+ Signed-off-by:
Paul Mackerras <paulus@ozlabs.org> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Bjorn Helgaas authored
[ Upstream commit cdcb33f9 ] pci_lock is an IRQ-safe spinlock that protects all accesses to PCI configuration space (see PCI_OP_READ() and PCI_OP_WRITE() in pci/access.c). The pci_cfg_access_unlock() path acquires pci_lock, then p->pi_lock (inside wake_up_all()). According to lockdep, there is a possible path involving snbep_uncore_pci_read_counter() that could acquire them in the reverse order: acquiring p->pi_lock, then pci_lock, which could result in a deadlock. Lockdep details are in the bugzilla below. Avoid the possible deadlock by dropping pci_lock before waking up any config access waiters. Link: https://bugzilla.kernel.org/show_bug.cgi?id=192901Signed-off-by:
-
Joonyoung Shim authored
[ Upstream commit e41456bf ] The size computations done in the ioctl function use an integer. If userspace submits a request with req->cmd_nr or req->cmd_buf_nr set to INT_MAX, the integer computations overflow later, leading to potential (kernel) memory corruption. Prevent this issue by enforcing a limit on the number of submitted commands, so that we have enough headroom later for the size computations. Note that this change has no impact on the currently available users in userspace, like e.g. libdrm/exynos. While at it, also make a comment about the size computation more detailed. Signed-off-by:
Joonyoung Shim <jy0922.shim@samsung.com> Signed-off-by:
Tobias Jakobi <tjakobi@math.uni-bielefeld.de> Signed-off-by:
Inki Dae <inki.dae@samsung.com> Signed-off-by:
-
Sudip Mukherjee authored
[ Upstream commit 6792eb0c ] If dvb_attach() fails then we were just printing an error message and exiting but the memory allocated to state was not released. Signed-off-by:
Sudip Mukherjee <sudip.mukherjee@codethink.co.uk> Signed-off-by:
-
Harald Freudenberger authored
[ Upstream commit a4f2779e ] In fips mode only xts keys with 128 bit or 125 bit are allowed. This fix extends the xts_aes_set_key function to check for these valid key lengths in fips mode. Signed-off-by:
Harald Freudenberger <freude@linux.vnet.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Harald Freudenberger authored
[ Upstream commit d34b1acb ] The generate_entropy function used a sha256 for compacting together 256 bits of entropy into 32 bytes hash. However, it is questionable if a sha256 can really be used here, as potential collisions may reduce the max entropy fitting into a 32 byte hash value. So this batch introduces the use of sha512 instead and the required buffer adjustments for the calling functions. Further more the working buffer for the generate_entropy function has been widened from one page to two pages. So now 1024 stckf invocations are used to gather 256 bits of entropy. This has been done to be on the save side if the jitters of stckf values isn't as good as supposed. Signed-off-by:
-
Stefan Haberland authored
[ Upstream commit 2202134e ] Check if the device pointer is valid. Just a sanity check since we already are in the int handler of the device. Signed-off-by:
Stefan Haberland <sth@linux.vnet.ibm.com> Signed-off-by:
-
Alexander Usyskin authored
[ Upstream commit 7c47d2ca ] Request for a notification from a disconnected client will be ignored silently by the FW but the caller should know that the operation hasn't succeeded. Signed-off-by:
Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by:
Tomas Winkler <tomas.winkler@intel.com> Signed-off-by:
-
Arvind Yadav authored
[ Upstream commit 4742575c ] Free memory mapping, if fimc_is_probe is not successful. Signed-off-by:
Arvind Yadav <arvind.yadav.cs@gmail.com> Signed-off-by:
Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by:
-
Pierre-Louis Bossart authored
[ Upstream commit 3639ac1c ] This patch corrects an omission in bytcr_rt5640 and bytcr_rt5651. All existing machine drivers shall not use .pm_ops to avoid a double suspend, as initially implemented by 3f2dcbea ("ASoC: Intel: Remove soc pm handling to allow platform driver handle it"). Reported-by:
Shrirang Bagul <shrirang.bagul@canonical.com> Signed-off-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Seth Forshee authored
[ Upstream commit 1328c727 ] may_create() rejects creation of inodes with ids which lack a mapping into s_user_ns. However for O_CREAT may_o_create() is is used instead. Add a similar check there. Fixes: 036d5236 ("vfs: Don't create inodes with a uid or gid unknown to the vfs") Signed-off-by:
Seth Forshee <seth.forshee@canonical.com> Signed-off-by:
"Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by:
-
Rafał Miłecki authored
[ Upstream commit f4737a62 ] This method may be unsupported (see: USB bus) or may just fail (see: SDIO bus). While at it rework logic in brcmf_sdio_bus_get_memdump function to avoid too many conditional code nesting levels. Signed-off-by:
Rafał Miłecki <rafal@milecki.pl> Acked-by:
Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Ulka Vaze authored
[ Upstream commit 30af99db ] This issue is found by smatch; has been reported as- Unchecked usage of potential ERR_PTR result in lmv_hsm_req_count and lmv_hsm_req_build. Added ERR_PTR in both functions and also return value check added. Signed-off-by:
Ulka Vaze <ulka.vaze@yahoo.in> Signed-off-by:
Aditya Pandit <panditadityashreesh@yahoo.com> Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6523 Reviewed-on: http://review.whamcloud.com/14918Reviewed-by:
Dmitry Eremin <dmitry.eremin@intel.com> Reviewed-by:
Andreas Dilger <andreas.dilger@intel.com> Reviewed-by:
Oleg Drokin <oleg.drokin@intel.com> Signed-off-by:
James Simmons <jsimmons@infradead.org> Signed-off-by:
-
Alexander Boyko authored
[ Upstream commit 4c43c27d ] This patch resolves IO vs eviction race. After eviction failed export stayed at stale list, a client had IO processing and reconnected during it. A client sent brw rpc with last lock cookie and new connection. The lock with failed export was found and assert was happened. (ost_handler.c:1812:ost_prolong_lock_one()) ASSERTION( lock->l_export == opd->opd_exp ) failed: 1. Skip the lock at ldlm_handle2lock if lock export failed. 2. Validation of lock for IO was added at hpreq_check(). The lock searching is based on granted interval tree. If server doesn`t have a valid lock, it reply to client with ESTALE. Signed-off-by:
Alexander Boyko <alexander.boyko@seagate.com> Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-7702 Seagate-bug-id: MRP-2787 Reviewed-on: http://review.whamcloud.com/18120Reviewed-by:
Fan Yong <fan.yong@intel.com> Reviewed-by:
Vitaly Fertman <vitaly.fertman@seagate.com> Reviewed-by:
-
frank zago authored
[ Upstream commit 22aadb91 ] The function hai_dump_data_field will do a stack buffer overrun when cat'ing /sys/fs/lustre/.../hsm/actions if an action has some data in it. hai_dump_data_field uses snprintf. But there is no check for truncation, and the value returned by snprintf is used as-is. The coordinator code calls hai_dump_data_field with 12 bytes in the buffer. The 6th byte of data is printed incompletely to make room for the terminating NUL. However snprintf still returns 2, so when hai_dump_data_field writes the final NUL, it does it outside the reserved buffer, in the 13th byte of the buffer. This stack buffer overrun hangs my VM. Fix by checking that there is enough room for the next 2 characters plus the NUL terminator. Don't print half bytes. Change the format to 02X instead of .2X, which makes more sense. Signed-off-by:
frank zago <fzago@cray.com> Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8171 Reviewed-on: http://review.whamcloud.com/20338Reviewed-by:
John L. Hammond <john.hammond@intel.com> Reviewed-by:
Jean-Baptiste Riaux <riaux.jb@intel.com> Reviewed-by:
-
Yang Sheng authored
[ Upstream commit 77759771 ] The function generic_file_read_iter() does not check EOF before invoke direct_IO callback. So we have to check it ourselves. Signed-off-by:
Yang Sheng <yang.sheng@intel.com> Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8969 Reviewed-on: https://review.whamcloud.com/24552Reviewed-by:
Bob Glossman <bob.glossman@intel.com> Reviewed-by:
Bobi Jam <bobijam@hotmail.com> Reviewed-by:
-
Javier Martinez Canillas authored
[ Upstream commit a93151a7 ] If the driver is built as a module, autoload won't work because the module alias information is not filled. So user-space can't match the registered device with the corresponding module. Export the module alias information using the MODULE_DEVICE_TABLE() macro. Before this patch: $ modinfo drivers/platform/x86/intel_mid_thermal.ko | grep alias $ After this patch: $ modinfo drivers/platform/x86/intel_mid_thermal.ko | grep alias alias: platform:msic_thermal Signed-off-by:
Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Raghava Aditya Renukunta authored
[ Upstream commit 4ec57fb4 ] Make sure that the driver processes error conditions even in the fast response path for response from the adapter. Signed-off-by:
Raghava Aditya Renukunta <RaghavaAditya.Renukunta@microsemi.com> Signed-off-by:
Dave Carroll <David.Carroll@microsemi.com> Reviewed-by:
Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Jan Beulich authored
[ Upstream commit 4fed1b12 ] A negative return value indicates an error; in fact the function at present won't ever return zero. Signed-off-by:
Jan Beulich <jbeulich@suse.com> Reviewed-by:
-
Axel Lin authored
[ Upstream commit e8e1a5b5 ] This driver now using devm_regmap_init/devm_regmap_init_i2c, so it needs to select REGMAP/REGMAP_I2C accordingly. Fixes: ("3d84fdb3 gpio: mcp23s08: use regmap") Signed-off-by:
Axel Lin <axel.lin@ingics.com> Acked-By:
Sebastian Reichel <sre@kernel.org> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Boris Brezillon authored
[ Upstream commit 19649e2c ] wait_for_completion_timeout() returns 0 if a timeout occurred, 1 otherwise. Fix the sunxi_nfc_wait_events() accordingly. Signed-off-by:
Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by:
-
Stephen Boyd authored
[ Upstream commit 5d806f9f ] This kzalloc() could fail. Let's bail out with -ENOMEM here instead of NULL dereferencing. That silences static checkers. We should also cleanup on the error path even though this function returning an error probably means the system won't boot. Cc: Chen-Yu Tsai <wens@csie.org> Acked-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by:
Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
-
Ashok Raj Nagarajan authored
[ Upstream commit 7f622593 ] With QCA4019 platform, SRAM address can be accessed directly from host but currently, we are assuming sram addresses cannot be accessed directly and hence we convert the addresses. While there, clean up growing hw checks during conversion of target CPU address to CE address. Now we have function pointer pertaining to different chips. Signed-off-by:
Ashok Raj Nagarajan <arnagara@qti.qualcomm.com> Signed-off-by:
Kalle Valo <kvalo@qca.qualcomm.com> Signed-off-by:
-
Oleh Kravchenko authored
[ Upstream commit 6c5da803 ] Internal Master 3 Bus can send and receive only 4 bytes per time. Signed-off-by:
Oleh Kravchenko <oleg@kaa.org.ua> Signed-off-by:
-
Lukasz Majewski authored
[ Upstream commit ac6e058b ] The DP83867 when not properly bootstrapped - especially with LED_0 pin - can enter N/A MODE4 for "port mirroring" feature. To provide normal operation of the PHY, one needs not only to explicitly disable the port mirroring feature, but as well stop some IC internal testing (which disables RGMII communication). To do that the STRAP_STS1 (0x006E) register must be read and RESERVED bit 11 examined. When it is set, the another RESERVED bit (11) at PHYCR (0x0010) register must be clear to disable testing mode and enable RGMII communication. Thorough explanation of the problem can be found at following e2e thread: "DP83867IR: Problem with RESERVED bits in PHY Control Register (PHYCR) - Linux driver" https://e2e.ti.com/support/interface/ethernet/f/903/p/571313/2096954#2096954Signed-off-by:
Lukasz Majewski <lukma@denx.de> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Ding Tianhong authored
[ Upstream commit 729e5522 ] This erratum describes a bug in logic outside the core, so MIDR can't be used to identify its presence, and reading an SoC-specific revision register from common arch timer code would be awkward. So, describe it in the device tree. Signed-off-by:
Ding Tianhong <dingtianhong@huawei.com> Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Mark Rutland <mark.rutland@arm.com> Signed-off-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by:
-
Fabio Estevam authored
[ Upstream commit ef15d361 ] clk_prepare_enable() may fail, so we should better check its return value. Also place the of_node_put() function right after clk_prepare_enable(), in order to avoid calling of_node_put() twice in case clk_prepare_enable() fails. Signed-off-by:
Fabio Estevam <fabio.estevam@nxp.com> Signed-off-by:
Stefan Agner <stefan@agner.ch> Signed-off-by:
-
Emmanuel Grumbach authored
[ Upstream commit d45cb20e ] When we send a deauth to a station we don't know about, we need to use the PROBE_RESP queue. This can happen when we send a deauth to a station that is not associated to us. Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Signed-off-by:
-
Taeung Song authored
[ Upstream commit 75fc5ae5 ] Signed-off-by:
Taeung Song <treeze.taeung@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/r/1485952447-7013-2-git-send-email-treeze.taeung@gmail.comSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Rex Zhu authored
[ Upstream commit 28ed5504 ] Signed-off-by:
Rex Zhu <Rex.Zhu@amd.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Acked-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Chris Brandt authored
[ Upstream commit 71ccea09 ] This fixes the condition where the controller has not fully completed its final transfer and leaves the bus and controller in a undesirable state. At the end of the last transmitted byte, the existing driver would just signal for a STOP condition to be transmitted then immediately signal completion. However, the full STOP procedure might not have fully taken place by the time the runtime PM shuts off the peripheral clock, leaving the bus in a suspended state. Alternatively, the STOP condition on the bus may have completed, but when the next transaction is requested by the upper layer, not all the necessary register cleanup was finished from the last transfer which made the driver return BUS BUSY when it really wasn't. This patch now makes all transmit and receive transactions wait for the STOP condition to fully complete before signaling a completed transaction. With this new method, runtime PM no longer seems to be an issue. Fixes: 310c18a4 ("i2c: riic: add driver") Signed-off-by:
Chris Brandt <chris.brandt@renesas.com> Reviewed-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
Netanel Belgazal authored
[ Upstream commit 7102a18a ] The timeouts were too agressive and sometimes cause false alarms. Signed-off-by:
Netanel Belgazal <netanel@annapurnalabs.com> Signed-off-by:
-
