summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-05-14Merge branch 'net-qed-qede-critical-hw-error-handling'David S. Miller
Igor Russkikh says: ==================== net: qed/qede: critical hw error handling FastLinQ devices as a complex systems may observe various hardware level error conditions, both severe and recoverable. Driver is able to detect and report this, but so far it only did trace/dmesg based reporting. Here we implement an extended hw error detection, service task handler captures a dump for the later analysis. I also resubmit a patch from Denis Bolotin on tx timeout handler, addressing David's comment regarding recovery procedure as an extra reaction on this event. v2: Removing the patch with ethtool dump and udev magic. Its quite isolated, I'm working on devlink based logic for this separately. v1: https://patchwork.ozlabs.org/project/netdev/cover/cover.1588758463.git.irusskikh@marvell.com/ ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-14net: qed: fix bad formattingIgor Russkikh
On some adjacent code, fix bad code formatting Signed-off-by: Ariel Elior <ariel.elior@marvell.com> Signed-off-by: Michal Kalderon <michal.kalderon@marvell.com> Signed-off-by: Igor Russkikh <irusskikh@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-14net: qed: introduce critical hardware error handlerIgor Russkikh
MCP may signal driver about generic critical failure. Driver has to collect mdump information (get_retain), it pushes that to logs and triggers generic notification on "hardware attention" event. Signed-off-by: Ariel Elior <ariel.elior@marvell.com> Signed-off-by: Michal Kalderon <michal.kalderon@marvell.com> Signed-off-by: Igor Russkikh <irusskikh@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-14net: qed: introduce critical fan failure handlerIgor Russkikh
Fan failure is sent by firmware, driver reacts on this error with newly introduced notification path. It will collect dump and shut down the device to prevent physical breakage Signed-off-by: Ariel Elior <ariel.elior@marvell.com> Signed-off-by: Michal Kalderon <michal.kalderon@marvell.com> Signed-off-by: Igor Russkikh <irusskikh@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-14net: qede: Implement ndo_tx_timeoutDenis Bolotin
Upon tx timeout detection we do disable carrier and print TX queue info on TX timeout. We then raise hw error condition and trigger service task to handle this. This handler will capture extra debug info and then optionally trigger recovery procedure to try restore function. Signed-off-by: Denis Bolotin <dbolotin@marvell.com> Signed-off-by: Ariel Elior <aelior@marvell.com> Signed-off-by: Igor Russkikh <irusskikh@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-14net: qede: optional hw recovery procedureIgor Russkikh
Driver has an ability to initiate a recovery process as a reaction to detected errors. But the codepath (recovery_process) was disabled and never active. Here we add ethtool private flag to allow user have the recovery procedure activated. We still do not enable this by default though, since in some configurations this is not desirable. E.g. this may impact other PFs/VFs. Signed-off-by: Ariel Elior <ariel.elior@marvell.com> Signed-off-by: Michal Kalderon <michal.kalderon@marvell.com> Signed-off-by: Igor Russkikh <irusskikh@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-14net: qed: attention clearing propertiesIgor Russkikh
On different hardware events we have to respond differently, on some of hardware indications hw attention (error condition) should be cleared by the driver to continue normal functioning. Here we introduce attention clear flags, and put them on some important events (in aeu_descs). Signed-off-by: Ariel Elior <ariel.elior@marvell.com> Signed-off-by: Michal Kalderon <michal.kalderon@marvell.com> Signed-off-by: Igor Russkikh <irusskikh@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-14net: qed: cleanup debug related declarationsIgor Russkikh
Thats probably a legacy code had double declaration of some fields. Cleanup this, removing copy and fixing references. Signed-off-by: Ariel Elior <ariel.elior@marvell.com> Signed-off-by: Michal Kalderon <michal.kalderon@marvell.com> Signed-off-by: Igor Russkikh <irusskikh@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-14net: qed: critical err reporting to management firmwareIgor Russkikh
On various critical errors, notification handler should also report the err information into the management firmware. MFW can interact with server/motherboard backend agents - these are used by server manufacturers to monitor server HW health. Thus, it is important for driver to report on any faulty conditions Signed-off-by: Ariel Elior <ariel.elior@marvell.com> Signed-off-by: Michal Kalderon <michal.kalderon@marvell.com> Signed-off-by: Igor Russkikh <irusskikh@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-14net: qed: invoke err notify on critical areasIgor Russkikh
In a number of critical places not only debug trace should be printed, but the appropriate hw error condition should be raised and error handling/recovery should start. Introduce our new qed_hw_err_notify invocation in these places to record and indicate critical error conditions in hardware. Signed-off-by: Ariel Elior <ariel.elior@marvell.com> Signed-off-by: Michal Kalderon <michal.kalderon@marvell.com> Signed-off-by: Igor Russkikh <irusskikh@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-14net: qede: add hw err scheduled handlerIgor Russkikh
qede (ethernet level driver) registers a callback handler. This handler maintains eth dev state flags/bits to track error processing. It implements in place processing part for nonsleeping context (WARN_ON trigger), and a deferred (delayed work) part which triggers recovery process for recoverable errors. In later patches this atomic handler will come with more meat. We introduce err_flags on ethdevice structure, its being used to record error handling properties. Signed-off-by: Ariel Elior <ariel.elior@marvell.com> Signed-off-by: Michal Kalderon <michal.kalderon@marvell.com> Signed-off-by: Igor Russkikh <irusskikh@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-14net: qed: adding hw_err states and handlingIgor Russkikh
Here we introduce qed device error tracking flags and error types. qed_hw_err_notify is an entrace point to report errors. It'll notify higher level drivers (qede/qedr/etc) to handle and recover the error. List of posible errors comes from hardware interfaces, but could be extended in future. Signed-off-by: Ariel Elior <ariel.elior@marvell.com> Signed-off-by: Michal Kalderon <michal.kalderon@marvell.com> Signed-off-by: Igor Russkikh <irusskikh@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-14Merge branch 'net-hns3-add-some-cleanups-for-next'David S. Miller
Huazhong Tan says: ==================== net: hns3: add some cleanups for -next This patchset adds some cleanups for the HNS3 ethernet driver. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-14net: hns3: remove unnecessary frag list checking in hns3_nic_net_xmit()Huazhong Tan
The skb_has_frag_list() in hns3_nic_net_xmit() is redundant, since skb_walk_frags() includes this checking implicitly. Reported-by: Yunsheng Lin <linyunsheng@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-14net: hns3: remove some unused macrosHuazhong Tan
There are some macros defined in hns3_enet.h, but not used in anywhere. Reported-by: Yonglong Liu <liuyonglong@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-14net: hns3: modify an incorrect error log in hclge_mbx_handler()Huazhong Tan
When handling HCLGE_MBX_GET_LINK_STATUS, PF will return the link status to the VF, so the error log of hclge_get_link_info() is incorrect. Reported-by: Jian Shen <shenjian15@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-14net: hns3: remove a duplicated printing in hclge_configure()Huazhong Tan
Since hclge_get_cfg() already has error print, so hclge_configure() should not print error when calling hclge_get_cfg() fail. Reported-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-14net: hns3: modify some incorrect spellingHuazhong Tan
This patch modifies some incorrect spelling. Reported-by: Jian Shen <shenjian15@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-14r8152: Use MAC address from device tree if availableThierry Reding
If a MAC address was passed via the device tree node for the r8152 device, use it and fall back to reading from EEPROM otherwise. This is useful for devices where the r8152 EEPROM was not programmed with a valid MAC address, or if users want to explicitly set a MAC address in the bootloader and pass that to the kernel. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-14selftests: fix flower parent qdiscVlad Buslov
Flower tests used to create ingress filter with specified parent qdisc "parent ffff:" but dump them on "ingress". With recent commit that fixed tcm_parent handling in dump those are not considered same parent anymore, which causes iproute2 tc to emit additional "parent ffff:" in first line of filter dump output. The change in output causes filter match in tests to fail. Prevent parent qdisc output when dumping filters in flower tests by always correctly specifying "ingress" parent both when creating and dumping filters. Fixes: a7df4870d79b ("net_sched: fix tcm_parent in tc filter dump") Signed-off-by: Vlad Buslov <vladbu@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-13net: dsa: mt7530: set CPU port to fallback modeDENG Qingfang
Currently, setting a bridge's self PVID to other value and deleting the default VID 1 renders untagged ports of that VLAN unable to talk to the CPU port: bridge vlan add dev br0 vid 2 pvid untagged self bridge vlan del dev br0 vid 1 self bridge vlan add dev sw0p0 vid 2 pvid untagged bridge vlan del dev sw0p0 vid 1 # br0 cannot send untagged frames out of sw0p0 anymore That is because the CPU port is set to security mode and its PVID is still 1, and untagged frames are dropped due to VLAN member violation. Set the CPU port to fallback mode so untagged frames can pass through. Fixes: 83163f7dca56 ("net: dsa: mediatek: add VLAN support for MT7530") Signed-off-by: DENG Qingfang <dqfext@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-13net: mvneta: speed down the PHY, if WoL used, to save energyDaniel González Cabanelas
Some PHYs connected to this ethernet hardware support the WoL feature. But when WoL is enabled and the machine is powered off, the PHY remains waiting for a magic packet at max speed (i.e. 1Gbps), which is a waste of energy. Slow down the PHY speed before stopping the ethernet if WoL is enabled, and save some energy while the machine is powered off or sleeping. Tested using an Armada 370 based board (LS421DE) equipped with a Marvell 88E1518 PHY. Signed-off-by: Daniel González Cabanelas <dgcbueu@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-13sfc: fix dereference of table before it is null checkedColin Ian King
Currently pointer table is being dereferenced on a null check of table->must_restore_filters before it is being null checked, leading to a potential null pointer dereference issue. Fix this by null checking table before dereferencing it when checking for a null table->must_restore_filters. Addresses-Coverity: ("Dereference before null check") Fixes: e4fe938cff04 ("sfc: move 'must restore' flags out of ef10-specific nic_data") Signed-off-by: Colin Ian King <colin.king@canonical.com> Acked-by: Edward Cree <ecree@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-13net: phy: at803x: add cable diagnostics supportMichael Walle
The AR8031/AR8033 and the AR8035 support cable diagnostics. Adding driver support is straightforward, so lets add it. The PHY just do one pair at a time, so we have to start the test four times. The cable_test_get_status() can block and therefore we can just busy poll the test completion and continue with the next pair until we are done. The time delta counter seems to run at 125MHz which just gives us a resolution of about 82.4cm per tick. 100m cable, A/B/C/D open: Cable test started for device eth0. Cable test completed for device eth0. Pair: Pair A, result: Open Circuit Pair: Pair A, fault length: 107.94m Pair: Pair B, result: Open Circuit Pair: Pair B, fault length: 104.64m Pair: Pair C, result: Open Circuit Pair: Pair C, fault length: 105.47m Pair: Pair D, result: Open Circuit Pair: Pair D, fault length: 107.94m 1m cable, A/B connected, C shorted, D open: Cable test started for device eth0. Cable test completed for device eth0. Pair: Pair A, result: OK Pair: Pair B, result: OK Pair: Pair C, result: Short within Pair Pair: Pair C, fault length: 0.82m Pair: Pair D, result: Open Circuit Pair: Pair D, fault length: 0.82m Signed-off-by: Michael Walle <michael@walle.cc> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-13ipv6: set msg_control_is_user in do_ipv6_getsockoptChristoph Hellwig
While do_ipv6_getsockopt does not call the high-level recvmsg helper, the msghdr eventually ends up being passed to put_cmsg anyway, and thus needs msg_control_is_user set to the proper value. Fixes: 1f466e1f15cf ("net: cleanly handle kernel vs user buffers for ->msg_control") Reported-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-13Merge branch 'net-phy-broadcom-cable-tester-support'David S. Miller
Michael Walle says: ==================== net: phy: broadcom: cable tester support Add cable tester support for the Broadcom PHYs. Support for it was developed on a BCM54140 Quad PHY which RDB register access. If there is a link partner the results are not as good as with an open cable. I guess we could retry if the measurement until all pairs had at least one valid result. changes since v1: - added Reviewed-by: tags - removed "div by 2" for cross shorts, just mention it in the commit message. The results are inconclusive if the tests are repeated. So just report the length as is for now. - fixed typo in commit message ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-13net: phy: bcm54140: add cable diagnostics supportMichael Walle
Use the generic cable tester functions from bcm-phy-lib to add cable tester support. 100m cable, A/B/C/D open: Cable test started for device eth0. Cable test completed for device eth0. Pair: Pair A, result: Open Circuit Pair: Pair B, result: Open Circuit Pair: Pair C, result: Open Circuit Pair: Pair D, result: Open Circuit Pair: Pair A, fault length: 106.60m Pair: Pair B, fault length: 103.32m Pair: Pair C, fault length: 104.96m Pair: Pair D, fault length: 106.60m 1m cable, A/B connected, pair C shorted, D open: Cable test started for device eth0. Cable test completed for device eth0. Pair: Pair A, result: OK Pair: Pair B, result: OK Pair: Pair C, result: Short within Pair Pair: Pair D, result: Open Circuit Pair: Pair C, fault length: 0.82m Pair: Pair D, fault length: 1.64m 1m cable, A/B connected, pair C shorted with D: Cable test started for device eth0. Cable test completed for device eth0. Pair: Pair A, result: OK Pair: Pair B, result: OK Pair: Pair C, result: Short to another pair Pair: Pair D, result: Short to another pair Pair: Pair C, fault length: 1.64m Pair: Pair D, fault length: 1.64m The granularity of the length measurement seems to be 82cm. Signed-off-by: Michael Walle <michael@walle.cc> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-13net: phy: broadcom: add cable test supportMichael Walle
Most modern broadcom PHYs support ECD (enhanced cable diagnostics). Add support for it in the bcm-phy-lib so they can easily be used in the PHY driver. There are two access methods for ECD: legacy by expansion registers and via the new RDB registers which are exclusive. Provide functions in two variants where the PHY driver can choose from. To keep things simple for now, we just switch the register access to expansion registers in the RDB variant for now. On the flipside, we have to keep a bus lock to prevent any other non-legacy access on the PHY. The results of the intra-pair tests are inconclusive (at least for the BCM54140). Most of the times half the length is reported but sometimes the length is correct. Signed-off-by: Michael Walle <michael@walle.cc> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-13net: phy: broadcom: add bcm_phy_modify_exp()Michael Walle
Add the convenience function to do a read-modify-write. This has the additional benefit of saving one write to the selection register. Signed-off-by: Michael Walle <michael@walle.cc> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-13net: phy: broadcom: add exp register access methods without buslockMichael Walle
Add helper to read and write expansion registers without taking the mdio lock. Please note, that this changes the semantics of the read and write. Before there was no lock between selecting the expansion register and the actual read/write. This may lead to access failures if there are parallel accesses. Instead take the bus lock during the whole access cycle. Signed-off-by: Michael Walle <michael@walle.cc> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-13net: phy: tja11xx: add cable-test supportOleksij Rempel
Add initial cable testing support. This PHY needs only 100usec for this test and it is recommended to run it before the link is up. For now, provide at least ethtool support, so it can be tested by more developers. This patch was tested with TJA1102 PHY with following results: - No cable, is detected as open - 1m cable, with no connected other end and detected as open - a 40m cable (out of spec, max lenght should be 15m) is detected as OK. Current patch do not provide polarity test support. This test would indicate not proper wire connection, where "+" wire of main phy is connected to the "-" wire of the link partner. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-13Merge branch 'bpf_iter-fixes'Alexei Starovoitov
Yonghong Song says: ==================== Commit ae24345da54e ("bpf: Implement an interface to register bpf_iter targets") and its subsequent commits in the same patch set introduced bpf iterator, a way to run bpf program when iterating kernel data structures. This patch set addressed some followup issues. One big change is to allow target to pass ctx arg register types to verifier for verification purpose. Please see individual patch for details. Changelogs: v1 -> v2: . add "const" qualifier to struct bpf_iter_reg for bpf_iter_[un]reg_target, and this results in additional "const" qualifiers in some other places . drop the patch which will issue WARN_ONCE if seq_ops->show() returns a positive value. If this does happen, code review should spot this or author does know what he is doing. In the future, we do want to implement a mechanism to find out all registered targets so we will be aware of new additions. ==================== Acked-by: Andrii Nakryiko <andriin@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2020-05-13net: ignore sock_from_file errors in __scm_install_fdChristoph Hellwig
The code had historically been ignoring these errors, and my recent refactoring changed that, which broke ssh in some setups. Fixes: 2618d530dd8b ("net/scm: cleanup scm_detach_fds") Reported-by: Ido Schimmel <idosch@idosch.org> Signed-off-by: Christoph Hellwig <hch@lst.de> Tested-by: Ido Schimmel <idosch@mellanox.com> Tested-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-13samples/bpf: Remove compiler warningsYonghong Song
Commit 5fbc220862fc ("tools/libpf: Add offsetof/container_of macro in bpf_helpers.h") added macros offsetof/container_of to bpf_helpers.h. Unfortunately, it caused compilation warnings below for a few samples/bpf programs: In file included from /data/users/yhs/work/net-next/samples/bpf/sockex2_kern.c:4: In file included from /data/users/yhs/work/net-next/include/uapi/linux/in.h:24: In file included from /data/users/yhs/work/net-next/include/linux/socket.h:8: In file included from /data/users/yhs/work/net-next/include/linux/uio.h:8: /data/users/yhs/work/net-next/include/linux/kernel.h:992:9: warning: 'container_of' macro redefined [-Wmacro-redefined] ^ /data/users/yhs/work/net-next/tools/lib/bpf/bpf_helpers.h:46:9: note: previous definition is here ^ 1 warning generated. CLANG-bpf samples/bpf/sockex3_kern.o In all these cases, bpf_helpers.h is included first, followed by other standard headers. The macro container_of is defined unconditionally in kernel.h, causing the compiler warning. The fix is to move bpf_helpers.h after standard headers. Signed-off-by: Yonghong Song <yhs@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Andrii Nakryiko <andriin@fb.com> Link: https://lore.kernel.org/bpf/20200513180223.2949987-1-yhs@fb.com
2020-05-13bpf: Enable bpf_iter targets registering ctx argument typesYonghong Song
Commit b121b341e598 ("bpf: Add PTR_TO_BTF_ID_OR_NULL support") adds a field btf_id_or_null_non0_off to bpf_prog->aux structure to indicate that the first ctx argument is PTR_TO_BTF_ID reg_type and all others are PTR_TO_BTF_ID_OR_NULL. This approach does not really scale if we have other different reg types in the future, e.g., a pointer to a buffer. This patch enables bpf_iter targets registering ctx argument reg types which may be different from the default one. For example, for pointers to structures, the default reg_type is PTR_TO_BTF_ID for tracing program. The target can register a particular pointer type as PTR_TO_BTF_ID_OR_NULL which can be used by the verifier to enforce accesses. Signed-off-by: Yonghong Song <yhs@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Andrii Nakryiko <andriin@fb.com> Link: https://lore.kernel.org/bpf/20200513180221.2949882-1-yhs@fb.com
2020-05-13bpf: Change func bpf_iter_unreg_target() signatureYonghong Song
Change func bpf_iter_unreg_target() parameter from target name to target reg_info, similar to bpf_iter_reg_target(). Signed-off-by: Yonghong Song <yhs@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Andrii Nakryiko <andriin@fb.com> Link: https://lore.kernel.org/bpf/20200513180220.2949737-1-yhs@fb.com
2020-05-13bpf: net: Refactor bpf_iter target registrationYonghong Song
Currently bpf_iter_reg_target takes parameters from target and allocates memory to save them. This is really not necessary, esp. in the future we may grow information passed from targets to bpf_iter manager. The patch refactors the code so target reg_info becomes static and bpf_iter manager can just take a reference to it. Signed-off-by: Yonghong Song <yhs@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20200513180219.2949605-1-yhs@fb.com
2020-05-13bpf: Add comments to interpret bpf_prog return valuesYonghong Song
Add a short comment in bpf_iter_run_prog() function to explain how bpf_prog return value is converted to seq_ops->show() return value: bpf_prog return seq_ops()->show() return 0 0 1 -EAGAIN When show() return value is -EAGAIN, the current bpf_seq_read() will end. If the current seq_file buffer is empty, -EAGAIN will return to user space. Otherwise, the buffer will be copied to user space. In both cases, the next bpf_seq_read() call will try to show the same object which returned -EAGAIN previously. Signed-off-by: Yonghong Song <yhs@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Andrii Nakryiko <andriin@fb.com> Link: https://lore.kernel.org/bpf/20200513180218.2949517-1-yhs@fb.com
2020-05-13bpf: Change btf_iter func proto prefix to "bpf_iter_"Yonghong Song
This is to be consistent with tracing and lsm programs which have prefix "bpf_trace_" and "bpf_lsm_" respectively. Suggested-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Yonghong Song <yhs@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Andrii Nakryiko <andriin@fb.com> Link: https://lore.kernel.org/bpf/20200513180216.2949387-1-yhs@fb.com
2020-05-13tools/bpf: selftests : Explain bpf_iter test failures with llvm 10.0.0Yonghong Song
Commit 6879c042e105 ("tools/bpf: selftests: Add bpf_iter selftests") added self tests for bpf_iter feature. But two subtests ipv6_route and netlink needs llvm latest 10.x release branch or trunk due to a bug in llvm BPF backend. This patch added the file README.rst to document these two failures so people using llvm 10.0.0 can be aware of them. Suggested-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Yonghong Song <yhs@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20200513180215.2949237-1-yhs@fb.com
2020-05-13Merge branch 'dwmac-meson8b-Ethernet-RX-delay-configuration'David S. Miller
Martin Blumenstingl says: ==================== dwmac-meson8b Ethernet RX delay configuration The Ethernet TX performance has been historically bad on Meson8b and Meson8m2 SoCs because high packet loss was seen. I found out that this was related (yet again) to the RGMII TX delay configuration. In the process of discussing the big picture (and not just a single patch) [0] with Andrew I discovered that the IP block behind the dwmac-meson8b driver actually seems to support the configuration of the RGMII RX delay (at least on the Meson8b SoC generation). Since I sent the first RFC I got additional documentation from Jianxin (many thanks!). Also I have discovered some more interesting details: - Meson8b Odroid-C1 requires an RX delay (by either the PHY or the MAC) Based on the vendor u-boot code (not upstream) I assume that it will be the same for all Meson8b and Meson8m2 boards - Khadas VIM2 seems to have the RX delay built into the PCB trace length. When I enable the RX delay on the PHY or MAC I can't get any data through. I expect that we will have the same situation on all GXBB, GXM, AXG, G12A, G12B and SM1 boards. Further clarification is needed here though (since I can't visually see these lengthened traces on the PCB). This will be done before sending patches for these boards. Dependencies for this series: There is a soft dependency for patch #2 on commit f22531438ff42c "dt-bindings: net: dwmac: increase 'maxItems' for 'clocks', 'clock-names' properties" which is currently in Rob's -next tree. That commit is needed to make the dt-bindings schema validation pass for patch #2. That patch has been for ~4 weeks in Robs tree, so I assume that is not going to be dropped. Changes since RFC v2 at [2]: - dropped $ref: /schemas/types.yaml#definitions/uint32 from the "amlogic,rx-delay-ns" in patch #1 ("Don't need to define the type when in standard units." says Rob - thanks, I learned something new). Also use "default: 0" for for this property instead of explaining it in the description text. - added a note to the cover-letter about a hidden dependency for dt-binding schema validation in patch #2 - Added Andrew's Reviewed-by to patches 1-7. Thank you again for the quick and detailed reviews, I appreciate this! - error out if the (optional) timing-adjustment clock is missing but we're asked to enable the RGMII RX delay. The MAC won't work in this specific case and either the RX delay has to be provided by the PHY or the timing-adjustment clock has to be added. - dropped the dts patches (#9-11) which were only added to give an overview how this is going to be used. those will be sent separately - dropped the RFC prefix Changes since RFC v1 at [1]: - add support for the timing adjustment clock input (dt-bindings and in the driver) thanks to the input from the unnamed Ethernet engineer at Amlogic. This is the missing link between the fclk_div2 clock and the Ethernet controller on Meson8b (no traffic would flow if that clock was disabled) - add support fot the amlogic,rx-delay-ns property. The only supported values so far are 0ns and 2ns. The registers seem to allow more precise timing adjustments, but I could not make that work so far. - add more register documentation (for the new RX delay bits) and unified the placement of existing register documentation. Again, thanks to Jianxin and the unnamed Ethernet engineer at Amlogic - DO NOT MERGE: .dts patches to show the conversion of the Meson8b and Meson8m2 boards to "rgmii-id". I didn't have time for all arm64 patches yet, but these will switch to phy-mode = "rgmii-txid" with amlogic,rx-delay-ns = <0> (because the delay seems to be provided by the PCB trace length). [0] https://patchwork.kernel.org/patch/11309891/ [1] https://patchwork.kernel.org/cover/11310719/ [2] https://patchwork.kernel.org/cover/11518257/ ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-13net: stmmac: dwmac-meson8b: add support for the RX delay configurationMartin Blumenstingl
Configure the PRG_ETH0_ADJ_* bits to enable or disable the RX delay based on the various RGMII PHY modes. For now the only supported RX delay settings are: - disabled, use for example for phy-mode "rgmii-id" - 0ns - this is treated identical to "disabled", used for example on boards where the PHY provides 2ns TX delay and the PCB trace length already adds 2ns RX delay - 2ns - for whenever the PHY cannot add the RX delay and the traces on the PCB don't add any RX delay Disabling the RX delay (in case u-boot enables it, which is the case for example on Meson8b Odroid-C1) simply means that PRG_ETH0_ADJ_ENABLE, PRG_ETH0_ADJ_SETUP, PRG_ETH0_ADJ_DELAY and PRG_ETH0_ADJ_SKEW should be disabled (just disabling PRG_ETH0_ADJ_ENABLE may be enough, since that disables the whole re-timing logic - but I find it makes more sense to clear the other bits as well since they depend on that setting). u-boot on Odroid-C1 uses the following steps to enable a 2ns RX delay: - enabling enabling the timing adjustment clock - enabling the timing adjustment logic by setting PRG_ETH0_ADJ_ENABLE - setting the PRG_ETH0_ADJ_SETUP bit The documentation for the PRG_ETH0_ADJ_DELAY and PRG_ETH0_ADJ_SKEW registers indicates that we can even set different RX delays. However, I could not find out how this works exactly, so for now we only support a 2ns RX delay using the exact same way that Odroid-C1's u-boot does. Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-13net: stmmac: dwmac-meson8b: Make the clock enabling code re-usableMartin Blumenstingl
The timing adjustment clock will need similar logic as the RGMII clock: It has to be enabled in the driver conditionally and when the driver is unloaded it should be disabled again. Extract the existing code for the RGMII clock into a new function so it can be re-used. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-13net: stmmac: dwmac-meson8b: Fetch the "timing-adjustment" clockMartin Blumenstingl
The PRG_ETHERNET registers have a built-in timing adjustment circuit which can provide the RX delay in RGMII mode. This is driven by an external (to this IP, but internal to the SoC) clock input. Fetch this clock as optional (even though it's there on all supported SoCs) since we just learned about it and existing .dtbs don't specify it. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-13net: stmmac: dwmac-meson8b: Add the PRG_ETH0_ADJ_* bitsMartin Blumenstingl
The PRG_ETH0_ADJ_* are used for applying the RGMII RX delay. The public datasheets only have very limited description for these registers, but Jianxin Pan provided more detailed documentation from an (unnamed) Amlogic engineer. Add the PRG_ETH0_ADJ_* bits along with the improved description. Suggested-by: Jianxin Pan <jianxin.pan@amlogic.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-13net: stmmac: dwmac-meson8b: Move the documentation for the TX delayMartin Blumenstingl
Move the documentation for the TX delay above the PRG_ETH0_TXDLY_MASK definition. Future commits will add more registers also with documentation above their register bit definitions. Move the existing comment so it will be consistent with the upcoming changes. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-13net: stmmac: dwmac-meson8b: use FIELD_PREP instead of open-coding itMartin Blumenstingl
Use FIELD_PREP() to shift a value to the correct offset based on a bitmask instead of open-coding the logic. No functional changes. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-13dt-bindings: net: dwmac-meson: Document the "timing-adjustment" clockMartin Blumenstingl
The PRG_ETHERNET registers can add an RX delay in RGMII mode. This requires an internal re-timing circuit whose input clock is called "timing adjustment clock". Document this clock input so the clock can be enabled as needed. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-13dt-bindings: net: meson-dwmac: Add the amlogic,rx-delay-ns propertyMartin Blumenstingl
The PRG_ETHERNET registers on Meson8b and newer SoCs can add an RX delay. Add a property with the known supported values so it can be configured according to the board layout. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-05-13Merge branch 'for-upstream' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next Johan Hedberg says: ==================== pull request: bluetooth-next 2020-05-13 Here's a second attempt at a bluetooth-next pull request which supercedes the one dated 2020-05-09. This should have the issues discovered by Jakub fixed. - Add support for Intel Typhoon Peak device (8087:0032) - Add device tree bindings for Realtek RTL8723BS device - Add device tree bindings for Qualcomm QCA9377 device - Add support for experimental features configuration through mgmt - Add driver hook to prevent wake from suspend - Add support for waiting for L2CAP disconnection response - Multiple fixes & cleanups to the btbcm driver - Add support for LE scatternet topology for selected devices - A few other smaller fixes & cleanups Please let me know if there are any issues pulling. Thanks. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
generated by cgit v1.2.3 (git 2.25.1) at 2024-10-23 07:23:00 +0000