- 20 Jun, 2017 40 commits
-
-
Jan Glauber authored
BugLink: https://bugs.launchpad.net/bugs/1688132 I've seen i2c recovery reporting long loops of: [ 1035.887818] i2c i2c-4: SCL is stuck low, exit recovery [ 1037.999748] i2c i2c-4: SCL is stuck low, exit recovery [ 1040.111694] i2c i2c-4: SCL is stuck low, exit recovery ... Add a TWSI software reset which clears the status and STA,STP,IFLG in SW_TWSI_EOP_TWSI_CTL. With this the recovery works fine and above message is not seen. Signed-off-by:
Jan Glauber <jglauber@cavium.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> (cherry picked from commit ccee1a4c) Signed-off-by:
dann frazier <dann.frazier@canonical.com> Acked-by:
Colin King <colin.king@canonical.com> Acked-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-
Jan Glauber authored
BugLink: https://bugs.launchpad.net/bugs/1688132 In case the high-level controller (HLC) is used the status code is reported at a different location. Check that location after HLC write operations if the ready bit is not set and return an appropriate error code instead of always returning -EAGAIN. Signed-off-by:
-
Dmitry Bazhenov authored
BugLink: https://bugs.launchpad.net/bugs/1688132 Due to a bug in the ThunderX I2C hardware sending STOP during a recovery attempt could lock up the hardware. To work around this problem do not send STOP at the beginning of the recovery but use the override registers to bring the TWSI including the high-level controller out of the bad state. Signed-off-by:
Dmitry Bazhenov <dmitry.bazhenov@auriga.com> Signed-off-by:
-
Dmitry Bazhenov authored
BugLink: https://bugs.launchpad.net/bugs/1688132 The set SCL recovery function unconditionally pulls the SCL line low. Only pull SCL line low according to val parameter. Signed-off-by:
-
Jan Glauber authored
BugLink: https://bugs.launchpad.net/bugs/1688132 The i2c Octeon and ThunderX drivers are maintained by Cavium. While at it fix the whitespace errors of the next entry. Signed-off-by:
David Daney <david.daney@cavium.com> Signed-off-by:
-
Jan Glauber authored
BugLink: https://bugs.launchpad.net/bugs/1688132 Initialize booleon values with true instead of 1. Signed-off-by:
-
Jan Glauber authored
BugLink: https://bugs.launchpad.net/bugs/1688132 Sort include files alphabetically to reduce probability of merge conflicts. Signed-off-by:
-
Jan Glauber authored
BugLink: https://bugs.launchpad.net/bugs/1688132 The register offsets are different between Octeon and ThunderX so move them into the algorithm struct and get rid of the define. Signed-off-by:
-
Jan Glauber authored
BugLink: https://bugs.launchpad.net/bugs/1688132 Add SMBUS alert interrupt support. For now only device tree is supported for specifying the alert. In case of ACPI an error is returned. Signed-off-by:
-
Jan Glauber authored
BugLink: https://bugs.launchpad.net/bugs/1688132 The ThunderX SOC uses the same i2c block as the Octeon SOC. The main difference is that on ThunderX the device is a PCI device so device probing is done via PCI, interrupts are MSI-X. The clock rates can be set via device tree or ACPI. Signed-off-by:
-
dann frazier authored
BugLink: https://bugs.launchpad.net/bugs/1688132Signed-off-by:
-
Jan Glauber authored
BugLink: https://bugs.launchpad.net/bugs/1688132 Move common functionality into a separate file in preparation of the re-use from the ThunderX i2c driver. Functions are slightly re-ordered but no other changes are included. Signed-off-by:
-
Jan Glauber authored
BugLink: https://bugs.launchpad.net/bugs/1688132 This is an intermediate commit in preparation of the driver split. The module rename in this commit will be reverted in the next patch, this is just done to make the series bisectible. Signed-off-by:
-
Jan Glauber authored
BugLink: https://bugs.launchpad.net/bugs/1688132 Remove the warning about a too long SMBUS message because the ipmi_ssif driver triggers this warning too frequently so it spams the message log. Signed-off-by:
-
Jan Glauber authored
BugLink: https://bugs.launchpad.net/bugs/1688132 During receive the controller requires the AAK flag for all bytes but the final one. This was wrong in case of I2C_M_RECV_LEN, where the decision if the final byte is to be transmitted happened before adding the additional received length byte. Set the AAK flag if additional bytes are to be received. Signed-off-by:
-
David Daney authored
BugLink: https://bugs.launchpad.net/bugs/1688132 CN3860 does not interrupt the CPU when the i2c status changes. If we get a timeout, and see the status has in fact changed, we know we have this problem, and drop back to polling. Signed-off-by:
David Daney <ddaney@caviumnetworks.com> Signed-off-by:
-
Peter Swain authored
BugLink: https://bugs.launchpad.net/bugs/1688132 There is a race between the TWSI interrupt and the condition that is required before proceeding: Low-level: interrupt flag bit must be set High-level controller: valid bit must be clear If the interrupt comes too early and the condition is not met the wait will time out, and the transfer is aborted leading to very poor performance. To avoid this race retry for the condition ~80 µs later. The retry is avoided on the very first invocation of wait_event_timeout() (which tests the condition before entering the wait and is therefore always wrong in this case). EEPROM reads on 100kHz i2c now measure ~5.2kB/s, about 1/2 what's achievable, and much better than the worst-case 100 bytes/sec before. While at it remove the debug print from the low-level wait function. Signed-off-by:
Peter Swain <pswain@cavium.com> Signed-off-by:
-
Jan Glauber authored
BugLink: https://bugs.launchpad.net/bugs/1688132 Zero-length message support (SMBUS QUICK or i2c) never worked with the Octeon hardware. Disable SMBUS QUICK support and bail out in case of a zero-length i2c request. After this change 'i2c-detect -q' will return an error on Octeon but the previously reported results were wrong anyway. Signed-off-by:
-
Jan Glauber authored
BugLink: https://bugs.launchpad.net/bugs/1688132 cn78xx has a different interrupt architecture, so we have to manage the interrupts differently. Signed-off-by:
-
David Daney authored
BugLink: https://bugs.launchpad.net/bugs/1688132 Use High-Level Controller (HLC) when possible. The HLC can read/write up to 8 bytes and is completely optional. The most important difference of the HLC is that it only requires one interrupt for a transfer (up to 8 bytes) where the low-level read/write requires 2 interrupts plus one interrupt per transferred byte. Since the interrupts are costly using the HLC improves the performance. Also, the HLC provides improved error handling. Signed-off-by:
-
Peter Swain authored
BugLink: https://bugs.launchpad.net/bugs/1688132 Add helper function that reads back a value after writing to make sure the write is finished and use it in octeon_i2c_write_int(). Signed-off-by:
-
Jan Glauber authored
BugLink: https://bugs.launchpad.net/bugs/1688132 Switch to the i2c bus recovery framework using generic SCL recovery. If this fails try to reset the hardware. The recovery is triggered during START on timeout of the interrupt or failure to reach the START / repeated-START condition. The START function is moved to xfer and while at it remove the xfer debug message (i2c core already provides a debug message for this). Signed-off-by:
-
Jan Glauber authored
BugLink: https://bugs.launchpad.net/bugs/1688132 Introduce a function that checks for valid status codes depending on the phase of a transmit or receive. Also add all existing status codes and improve error handling for various states. The Octeon TWSI has an "assert acknowledge" bit (TWSI_CTL_AAK) that is required to be set in master receive mode until the last byte is requested. The state check needs to consider if this bit was set. Signed-off-by:
-
Jan Glauber authored
BugLink: https://bugs.launchpad.net/bugs/1688132 Remove superfluous check and stray newline. Signed-off-by:
-
Jan Glauber authored
BugLink: https://bugs.launchpad.net/bugs/1688132 Add helper functions for control, data and status register access. This simplifies the code and makes the purpose of the register access clearer. Signed-off-by:
-
Jan Glauber authored
BugLink: https://bugs.launchpad.net/bugs/1688132 Rename the [read|write]_sw functions to make it clearer they access the TWSI registers. Signed-off-by:
-
Jan Glauber authored
BugLink: https://bugs.launchpad.net/bugs/1688132 No functional change, just moving the functions upward in preparation of improving the recovery. Signed-off-by:
-
Jan Glauber authored
BugLink: https://bugs.launchpad.net/bugs/1688132 Convert the adapter timeout to 2 ms independently of depending on CONFIG_HZ. CONFIG_HZ is 100 for MIPS Cavium-Octeon so the timeout value is not changed. Also set retries to 5 to improve robustness. Signed-off-by:
-
David Daney authored
BugLink: https://bugs.launchpad.net/bugs/1688132 If I2C_M_RECV_LEN is set consider the length byte. Signed-off-by:
-
Jan Glauber authored
BugLink: https://bugs.launchpad.net/bugs/1688132 Remove resource values from struct i2c_octeon and use devm_ioremap_resource helper. Signed-off-by:
-
Jan Glauber authored
BugLink: https://bugs.launchpad.net/bugs/1688132 Cleanup only without functional change. - removed DRV_VERSION - defines: use defines instead of plain values, use BIT_ULL macro, add comments - rename waitqueue return value to time_left - sort local variables by length - fix indentation and whitespace errors - make function return void if the result is not used (octeon_i2c_stop, octeon_i2c_set_clock) - remove debug code from octeon_i2c_stop - renamed some functions for readability - update copyright Signed-off-by:
-
Jan Glauber authored
BugLink: https://bugs.launchpad.net/bugs/1688132 Remove point after parameter description and replace kerneldoc by a comment if it has no additional no value. Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: http://bugs.launchpad.net/bugs/1691418Signed-off-by:
-
Ilya Dryomov authored
BugLink: http://bugs.launchpad.net/bugs/1691418 commit 19b7ccf8 upstream. Commit 25520d55 ("block: Inline blk_integrity in struct gendisk") introduced blk_integrity_revalidate(), which seems to assume ownership of the stable pages flag and unilaterally clears it if no blk_integrity profile is registered: if (bi->profile) disk->queue->backing_dev_info->capabilities |= BDI_CAP_STABLE_WRITES; else disk->queue->backing_dev_info->capabilities &= ~BDI_CAP_STABLE_WRITES; It's called from revalidate_disk() and rescan_partitions(), making it impossible to enable stable pages for drivers that support partitions and don't use blk_integrity: while the call in revalidate_disk() can be trivially worked around (see zram, which doesn't support partitions and hence gets away with zram_revalidate_disk()), rescan_partitions() can be triggered from userspace at any time. This breaks rbd, where the ceph messenger is responsible for generating/verifying CRCs. Since blk_integrity_{un,}register() "must" be used for (un)registering the integrity profile with the block layer, move BDI_CAP_STABLE_WRITES setting there. This way drivers that call blk_integrity_register() and use integrity infrastructure won't interfere with drivers that don't but still want stable pages. Fixes: 25520d55 ("block: Inline blk_integrity in struct gendisk") Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Mike Snitzer <snitzer@redhat.com> Tested-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
Ilya Dryomov <idryomov@gmail.com> [idryomov@gmail.com: backport to < 4.11: bdi is embedded in queue] Signed-off-by:
Jens Axboe <axboe@fb.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Nicolai Hähnle authored
BugLink: http://bugs.launchpad.net/bugs/1691418 commit 3089c1df upstream. The vm fault handler relies on the fact that the VMA owns a reference to the BO. However, once mmap_sem is released, other tasks are free to destroy the VMA, which can lead to the BO being freed. Fix two code paths where that can happen, both related to vm fault retries. Found via a lock debugging warning which flagged &bo->wu_mutex as locked while being destroyed. Fixes: cbe12e74 ("drm/ttm: Allow vm fault retries") Signed-off-by:
Nicolai Hähnle <nicolai.haehnle@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Jin Qian authored
BugLink: http://bugs.launchpad.net/bugs/1691418 commit b9dd4618 upstream. F2FS uses 4 bytes to represent block address. As a result, supported size of disk is 16 TB and it equals to 16 * 1024 * 1024 / 2 segments. Signed-off-by:
Jin Qian <jinqian@google.com> Signed-off-by:
Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by:
-
Dan Carpenter authored
BugLink: http://bugs.launchpad.net/bugs/1691418 [ Upstream commit ac45bd93 ] We have the number of longs, but we need to calculate the number of bytes required. Fixes: c0c050c5 ("bnxt_en: New Broadcom ethernet driver.") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
Michael Chan <michael.chan@broadcom.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
WANG Cong authored
BugLink: http://bugs.launchpad.net/bugs/1691418 [ Upstream commit 242d3a49 ] For each netns (except init_net), we initialize its null entry in 3 places: 1) The template itself, as we use kmemdup() 2) Code around dst_init_metrics() in ip6_route_net_init() 3) ip6_route_dev_notify(), which is supposed to initialize it after loopback registers Unfortunately the last one still happens in a wrong order because we expect to initialize net->ipv6.ip6_null_entry->rt6i_idev to net->loopback_dev's idev, thus we have to do that after we add idev to loopback. However, this notifier has priority == 0 same as ipv6_dev_notf, and ipv6_dev_notf is registered after ip6_route_dev_notifier so it is called actually after ip6_route_dev_notifier. This is similar to commit 2f460933 ("ipv6: initialize route null entry in addrconf_init()") which fixes init_net. Fix it by picking a smaller priority for ip6_route_dev_notifier. Also, we have to release the refcnt accordingly when unregistering loopback_dev because device exit functions are called before subsys exit functions. Acked-by:
David Ahern <dsahern@gmail.com> Tested-by:
Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by:
-
WANG Cong authored
BugLink: http://bugs.launchpad.net/bugs/1691418 [ Upstream commit 2f460933 ] Andrey reported a crash on init_net.ipv6.ip6_null_entry->rt6i_idev since it is always NULL. This is clearly wrong, we have code to initialize it to loopback_dev, unfortunately the order is still not correct. loopback_dev is registered very early during boot, we lose a chance to re-initialize it in notifier. addrconf_init() is called after ip6_route_init(), which means we have no chance to correct it. Fix it by moving this initialization explicitly after ipv6_add_dev(init_net.loopback_dev) in addrconf_init(). Reported-by:
Andrey Konovalov <andreyknvl@google.com> Signed-off-by:
-
Michal Schmidt authored
BugLink: http://bugs.launchpad.net/bugs/1691418 [ Upstream commit 77ef033b ] IFLA_PHYS_PORT_NAME is a string attribute, so terminate it with \0. Otherwise libnl3 fails to validate netlink messages with this attribute. "ip -detail a" assumes too that the attribute is NUL-terminated when printing it. It often was, due to padding. I noticed this as libvirtd failing to start on a system with sfc driver after upgrading it to Linux 4.11, i.e. when sfc added support for phys_port_name. Signed-off-by:
Michal Schmidt <mschmidt@redhat.com> Signed-off-by:
-
