summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/bin/stackcollapse-report
diff options
context:
space:
mode:
authorMasahiro Yamada <yamada.masahiro@socionext.com>2019-01-21 22:05:34 +0900
committerMiquel Raynal <miquel.raynal@bootlin.com>2019-02-05 16:56:11 +0100
commitf9ffb406d35b38e026acf56f39efcefede1f232e (patch)
tree9d80a9357d6a824ad79e8c9572d25ff4156ea481 /tools/perf/scripts/python/bin/stackcollapse-report
parent2d73f3d66b7052c0175f9f33d271ae50826c222e (diff)
downloadkernel-f9ffb406d35b38e026acf56f39efcefede1f232e.tar.gz
mtd: rawnand: check return code of nand_reset() and nand_readid_op()
nand_scan_ident() iterates over maxchips to find as many homogeneous chips as possible. Since commit 2d472aba15ff ("mtd: nand: document the NAND controller/NAND chip DT representation"), new drivers should pass in the exact number of CS lines instead of possible max, but old platforms may still rely on nand_scan_ident() to detect the actual number of connected CS lines. In that case, this loop bails out when manufacturer or device ID unmatches. The reason of unmatch is most likely no chip is connected to that CS line. If so, nand_reset() should already have failed, and the following nand_readid_op() is pointless. Before ->exec_op hook was introduced, drivers had no way to tell the failure of NAND_CMD_RESET to the framework because the legacy ->cmdfunc() has void return type. Now drivers implementing ->exec_op hook can return the error code. You can save nand_readid_op() by checking the return value of nand_reset(). The return value of nand_readid_op() should be checked as well. If it fails, probably id[0] and id[1] are undefined values. Just for consistency, it should be sensible to check the return code in nand_do_write_oob() as well. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Boris Brezillon <bbrezillon@kernel.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Diffstat (limited to 'tools/perf/scripts/python/bin/stackcollapse-report')
0 files changed, 0 insertions, 0 deletions
arsMauro Carvalho Chehab Probably because the original file was pre-processed by some tool, both i40e.rst and iavf.rst files are using this character: - U+2013 ('–'): EN DASH meaning an hyphen when calling a command line application, which is obviously wrong. So, replace them by an hyphen, ensuring that it will be properly displayed as literals when building the documentation. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/95eb2a48d0ca3528780ce0dfce64359977fa8cb3.1620744606.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet <corbet@lwn.net> 2020-06-26docs: networking: reorganize driver documentation againJakub Kicinski Organize driver documentation by device type. Most documents have fairly verbose yet uninformative names, so let users first select a well defined device type, and then search for a particular driver. While at it rename the section from Vendor drivers to Hardware drivers. This seems more accurate, besides people sometimes refer to out-of-tree drivers as vendor drivers. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Acked-by: Shannon Nelson <snelson@pensando.io> Signed-off-by: David S. Miller <davem@davemloft.net>