- 30 Apr, 2022 19 commits
-
-
Michael Walle authored
The PHY subsystem as well as the MIIM mdio driver (in case of the integrated PHYs) will take care of the resets. A separate reset driver isn't needed. There is no in-tree user of this feature. Remove the support. Signed-off-by:
Michael Walle <michael@walle.cc> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Michael Walle authored
The PHY reset was intended to be a phandle for a special PHY reset driver for the integrated PHYs as well as any external PHYs. It turns out, that the culprit is how the reset of the switch device is done. In particular, the switch reset also affects other subsystems like the GPIO and the SGPIO block and it happens to be the case that the reset lines of the external PHYs are connected to a common GPIO line. Thus as soon as the switch issues a reset during probe time, all the external PHYs will go into reset because all the GPIO lines will switch to input and the pull-down on that signal will take effect. So even if there was a special PHY reset driver, it (1) won't fix the root cause of the problem and (2) it won't fix all the other consumers of GPIO lines which will also be reset. It turns out, the Ocelot SoC has the same weird behavior (or the lack of a dedicated switch reset) and there the problem is already solved and all the bits and pieces are already there and this PHY reset property isn't not needed at all. There are no users of this binding. Just remove it. Signed-off-by:
-
David S. Miller authored
Pavel Begunkov says: ==================== generic net and ipv6 minor optimisations 1-3 inline simple functions that only reshuffle arguments possibly adding extra zero args, and call another function. It was benchmarked before with a bunch of extra patches, see for details https://lore.kernel.org/netdev/cover.1648981570.git.asml.silence@gmail.com/ It may increase the binary size, but it's the right thing to do and at least without modules it actually sheds some bytes for some standard-ish config. text data bss dec hex filename 9627200 0 0 9627200 92e640 ./arch/x86_64/boot/bzImage text data bss dec hex filename 9627104 0 0 9627104 92e5e0 ./arch/x86_64/boot/bzImage ==================== Signed-off-by:
-
Pavel Begunkov authored
Throw neigh checks in ip6_finish_output2() under a single slow path if, so we don't have the overhead in the hot path. Signed-off-by:
Pavel Begunkov <asml.silence@gmail.com> Signed-off-by:
-
Pavel Begunkov authored
There are two callers of __ip6_finish_output(), both are in ip6_finish_output(). We can combine the call sites into one and handle return code after, that will inline __ip6_finish_output(). Note, error handling under NET_XMIT_CN will only return 0 if __ip6_finish_output() succeded, and in this case it return 0. Considering that NET_XMIT_SUCCESS is 0, it'll be returning exactly the same result for it as before. Signed-off-by:
-
Pavel Begunkov authored
Inline dev_queue_xmit() and dev_queue_xmit_accel(), they both are small proxy functions doing nothing but redirecting the control flow to __dev_queue_xmit(). Signed-off-by:
-
Pavel Begunkov authored
skb_zerocopy_iter_dgram() is a small proxy function, inline it. For that, move __zerocopy_sg_from_iter into linux/skbuff.h Signed-off-by:
-
Pavel Begunkov authored
sock_alloc_send_skb() is simple and just proxying to another function, so we can inline it and cut associated overhead. Signed-off-by:
-
Jakub Kicinski authored
Merge branch 'tcp-pass-back-data-left-in-socket-after-receive' of git://git.kernel.org/pub/scm/linux/kernel/git/kuba/linuxSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jens Axboe authored
This is currently done for CMSG_INQ, add an ability to do so via struct msghdr as well and have CMSG_INQ use that too. If the caller sets msghdr->msg_get_inq, then we'll pass back the hint in msghdr->msg_inq. Rearrange struct msghdr a bit so we can add this member while shrinking it at the same time. On a 64-bit build, it was 96 bytes before this change and 88 bytes afterwards. Reviewed-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Link: https://lore.kernel.org/r/650c22ca-cffc-0255-9a05-2413a1e20826@kernel.dkSigned-off-by:
-
Yinjun Zhang authored
The device info from which conntrack originates is stored in metadata field of the ct flow to offload now, driver can utilize it to reduce the number of offloaded flows. v2: Drop inline keyword from get_netdev_from_rule() signature. The compiler can decide. Signed-off-by:Yinjun Zhang <yinjun.zhang@corigine.com> Signed-off-by:
Louis Peens <louis.peens@corigine.com> Signed-off-by:
Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/20220429075124.128589-1-simon.horman@corigine.comSigned-off-by:
-
Pieter Jansen van Vuuren authored
This patch extends the EF100 PF driver by adding .sriov_configure() which would allow users to enable and disable virtual functions using the sriov sysfs. Signed-off-by:
Pieter Jansen van Vuuren <pieter.jansen-van-vuuren@amd.com> Signed-off-by:
Edward Cree <ecree.xilinx@gmail.com> Link: https://lore.kernel.org/r/75e74d9e-14ce-0524-9668-5ab735a7cf62@gmail.comSigned-off-by:
-
Jakub Kicinski authored
Mat Martineau says: ==================== mptcp: Path manager mode selection MPTCP already has an in-kernel path manager (PM) to add and remove TCP subflows associated with a given MPTCP connection. This in-kernel PM has been designed to handle typical server-side use cases, but is not very flexible or configurable for client devices that may have more complicated policies to implement. This patch series from the MPTCP tree is the first step toward adding a generic-netlink-based API for MPTCP path management, which a privileged userspace daemon will be able to use to control subflow establishment. These patches add a per-namespace sysctl to select the default PM type (in-kernel or userspace) for new MPTCP sockets. New self-tests confirm expected behavior when userspace PM is selected but there is no daemon available to handle existing MPTCP PM events. Subsequent patch series (already staged in the MPTCP tree) will add the generic netlink path management API. ==================== Link: https://lore.kernel.org/r/20220427225002.231996-1-mathew.j.martineau@linux.intel.comSigned-off-by:
-
Mat Martineau authored
These tests ensure that the in-kernel path manager is bypassed when the userspace path manager is configured. Kernel code is still responsible for ADD_ADDR echo, so also make sure that's working. Tested-by:
Geliang Tang <geliang.tang@suse.com> Acked-by:
Paolo Abeni <pabeni@redhat.com> Co-developed-by:
Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by:
Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by:
-
Mat Martineau authored
The new net.mptcp.pm_type sysctl determines which path manager will be used by each newly-created MPTCP socket. v2: Handle builds without CONFIG_SYSCTL v3: Clarify logic for type-specific PM init (Geliang Tang and Paolo Abeni) Acked-by:
-
Mat Martineau authored
Userspace-managed sockets should not have their subflows or advertisements changed by the kernel path manager. v3: Use helper function for PM mode (Paolo Abeni) Acked-by:
-
Mat Martineau authored
When a MPTCP connection is managed by a userspace PM, bypass the kernel PM for incoming advertisements and subflow events. Netlink events are still sent to userspace. v2: Remove unneeded check in mptcp_pm_rm_addr_received() (Kishen Maloor) v3: Add and use helper function for PM mode (Paolo Abeni) Acked-by:
Kishen Maloor <kishen.maloor@intel.com> Signed-off-by:
-
Mat Martineau authored
When adding support for netlink path management commands, the kernel needs to know whether paths are being controlled by the in-kernel path manager or a userspace PM. Acked-by:
-
Mat Martineau authored
A few members of the mptcp_pm_data struct were assigned to hard-coded values in mptcp_pm_data_reset(), and then immediately changed in mptcp_pm_nl_data_init(). Instead, flatten all the assignments in to mptcp_pm_data_reset(). v2: Resolve conflicts due to rename of mptcp_pm_data_reset() v4: Resolve conflict in mptcp_pm_data_reset() Acked-by:
-
- 29 Apr, 2022 21 commits
-
-
Jakub Kicinski authored
Michael Walle says: ==================== net: phy: micrel: add coma mode support Add support to disable coma mode by a GPIO line. ==================== Link: https://lore.kernel.org/r/20220427214406.1348872-1-michael@walle.ccSigned-off-by:
-
Michael Walle authored
The LAN8814 has a coma mode pin which puts the PHY into isolate and power-dowm mode. Unfortunately, the mode cannot be disabled by a register. Usually, the input pin has a pull-up and connected to a GPIO which can then be used to disable the mode. Try to get the GPIO and deassert it. Signed-off-by:
-
Michael Walle authored
Both lan8814_ptp_init() and lan8814_ptp_probe_once() are only used if PTP and PHY timestamping is enabed. Up until now the probe function just returns early, if they are not needed. But we need the phy_package_init_once() functionality for the coma mode GPIO setup. Move the check into the functions itself. Signed-off-by:
-
Michael Walle authored
The LAN8814 has a coma mode pin which is used to put the PHY into isolate and power-down mode. Usually strapped to be asserted by default. A GPIO is then used to take the PHY out of this mode. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
David S. Miller authored
Merge branch 'remove-NAPI_POLL_WEIGHT-copies' Jakub Kicinski says: ==================== remove copies of the NAPI_POLL_WEIGHT define netif_napi_add() takes weight as the last argument. The value of that parameter is hard to come up with and depends on many factors, so driver authors are encouraged to use NAPI_POLL_WEIGHT. We should probably move weight to an "advanced" version of the API (__netif_napi_add()?) and simplify the life of most driver authors. In preparation for such API changes this series removes local defines equivalent to NAPI_POLL_WEIGHT from drivers, so that a simple coccinelle / spatch script does not get thrown off by them. v2: - drop staging bits (patch 2) - fix subject (patch 8) - add qeth change (patch 15) ==================== Signed-off-by: -
Jakub Kicinski authored
Defining local versions of NAPI_POLL_WEIGHT with the same values in the drivers just makes refactoring harder. Signed-off-by:
Alexandra Winter <wintera@linux.ibm.com> Signed-off-by:
-
Jakub Kicinski authored
Defining local versions of NAPI_POLL_WEIGHT with the same values in the drivers just makes refactoring harder. Signed-off-by:
-
Jakub Kicinski authored
Defining local versions of NAPI_POLL_WEIGHT with the same values in the drivers just makes refactoring harder. Acked-by:
Geoff Levand <geoff@infradead.org> Signed-off-by:
-
Jakub Kicinski authored
Defining local versions of NAPI_POLL_WEIGHT with the same values in the drivers just makes refactoring harder. Signed-off-by:
-
Jakub Kicinski authored
Defining local versions of NAPI_POLL_WEIGHT with the same values in the drivers just makes refactoring harder. Signed-off-by:
-
Jakub Kicinski authored
Defining local versions of NAPI_POLL_WEIGHT with the same values in the drivers just makes refactoring harder. Signed-off-by:
-
Jakub Kicinski authored
Defining local versions of NAPI_POLL_WEIGHT with the same values in the drivers just makes refactoring harder. Signed-off-by:
-
Jakub Kicinski authored
Defining local versions of NAPI_POLL_WEIGHT with the same values in the drivers just makes refactoring harder. Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Jakub Kicinski authored
Defining local versions of NAPI_POLL_WEIGHT with the same values in the drivers just makes refactoring harder. Signed-off-by:
Lino Sanfilippo <LinoSanfilippo@gmx.de> Signed-off-by:
-
Jakub Kicinski authored
Defining local versions of NAPI_POLL_WEIGHT with the same values in the drivers just makes refactoring harder. Signed-off-by:
-
Jakub Kicinski authored
Defining local versions of NAPI_POLL_WEIGHT with the same values in the drivers just makes refactoring harder. Signed-off-by:
-
Jakub Kicinski authored
Defining local versions of NAPI_POLL_WEIGHT with the same values in the drivers just makes refactoring harder. Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Jakub Kicinski authored
Defining local versions of NAPI_POLL_WEIGHT with the same values in the drivers just makes refactoring harder. Signed-off-by:
-
Jakub Kicinski authored
Defining local versions of NAPI_POLL_WEIGHT with the same values in the drivers just makes refactoring harder. Signed-off-by:
-
Jakub Kicinski authored
Defining local versions of NAPI_POLL_WEIGHT with the same values in the drivers just makes refactoring harder. Drop the special defines in a bunch of drivers where the removal is relatively simple so grouping into one patch does not impact reviewability. Signed-off-by:
Paul Durrant <paul@xen.org> Signed-off-by:
-
Nathan Rossi authored
The mv88e6xxx driver expects switches that are configured in single chip addressing mode to have the MDIO address configured as 0. This is due to the switch ADDR pins representing the single chip addressing mode as 0. However depending on the device (e.g. MV88E6*41) the switch does not respond on address 0 or any other address below 16 (the first port address) in single chip addressing mode. This allows for other devices to be on the same shared MDIO bus despite the switch being in single chip addressing mode. When using a switch that works this way it is not possible to configure switch driver as single chip addressing via device tree, along with another MDIO device on the same bus with address 0, as both devices would have the same address of 0 resulting in mdiobus_register_device -EBUSY errors for one of the devices with address 0. In order to support this configuration the switch node can have its MDIO address configured as 16 (the first address that the device responds to). During initialization the driver will treat this address similar to how address 0 is, however because this address is also a valid multi-chip address (in certain switch models, but not all) the driver will configure the SMI in single chip addressing mode and attempt to detect the switch model. If the device is configured in single chip addressing mode this will succeed and the initialization process can continue. If it fails to detect a valid model this is because the switch model register is not a valid register when in multi-chip mode, it will then fall back to the existing SMI initialization process using the MDIO address as the multi-chip mode address. This detection method is safe if the device is in either mode because the single chip addressing mode read is a direct SMI/MDIO read operation and has no side effects compared to the SMI writes required for the multi-chip addressing mode. In order to implement this change, the reset gpio configuration is moved to occur before any SMI initialization. This ensures that the device has the same/correct reset gpio state for both mv88e6xxx_smi_init calls. Signed-off-by:
Nathan Rossi <nathan@nathanrossi.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20220427130928.540007-1-nathan@nathanrossi.comSigned-off-by:
-
