summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* mctp: Add device handling and netlink interfaceJeremy Kerr2021-07-2910-1/+491
| | | | | | | | | | | This change adds the infrastructure for managing MCTP netdevices; we add a pointer to the AF_MCTP-specific data to struct netdevice, and hook up the rtnetlink operations for adding and removing addresses. Includes changes from Matt Johnston <matt@codeconstruct.com.au>. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Signed-off-by: David S. Miller <davem@davemloft.net>
* mctp: Add initial driver infrastructureJeremy Kerr2021-07-296-0/+13
| | | | | | | Add an empty drivers/net/mctp/, for future interface drivers. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Signed-off-by: David S. Miller <davem@davemloft.net>
* mctp: Add sockaddr_mctp to uapiJeremy Kerr2021-07-291-0/+21
| | | | | | | | This change introduces the user-visible MCTP header, containing the protocol-specific addressing definitions. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Signed-off-by: David S. Miller <davem@davemloft.net>
* mctp: Add base packet definitionsJeremy Kerr2021-07-292-0/+36
| | | | | | | Simple packet header format as defined by DMTF DSP0236. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Signed-off-by: David S. Miller <davem@davemloft.net>
* mctp: Add base socket/protocol definitionsJeremy Kerr2021-07-291-0/+163
| | | | | | | | Add an empty socket implementation, plus initialisation/destruction handlers. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Signed-off-by: David S. Miller <davem@davemloft.net>
* mctp: Add MCTP baseJeremy Kerr2021-07-2912-3/+66
| | | | | | | | | Add basic Kconfig, an initial (empty) af_mctp source object, and {AF,PF}_MCTP definitions, and the required definitions for a new protocol type. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge branch 'nfc-const'David S. Miller2021-07-2919-71/+78
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | Krzysztof Kozlowski says: ==================== nfc: constify, continued (part 2) On top of: nfc: constify pointed data https://lore.kernel.org/lkml/20210726145224.146006-1-krzysztof.kozlowski@canonical.com/ ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * nfc: mrvl: constify static nfcmrvl_if_opsKrzysztof Kozlowski2021-07-296-7/+7
| | | | | | | | | | | | | | File-scope struct nfcmrvl_if_ops is not modified so can be made const. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * nfc: mrvl: constify several pointersKrzysztof Kozlowski2021-07-296-13/+15
| | | | | | | | | | | | | | | | Several functions do not modify pointed data so arguments and local variables can be const for correctness and safety. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * nfc: microread: constify several pointersKrzysztof Kozlowski2021-07-293-4/+4
| | | | | | | | | | | | | | | | Several functions do not modify pointed data so arguments and local variables can be const for correctness and safety. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * nfc: fdp: constify several pointersKrzysztof Kozlowski2021-07-293-13/+13
| | | | | | | | | | | | | | | | | | Several functions do not modify pointed data so arguments and local variables can be const for correctness and safety. This allows also making file-scope nci_core_get_config_otp_ram_version array const. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * nfc: fdp: use unsigned int as loop iteratorKrzysztof Kozlowski2021-07-291-1/+2
| | | | | | | | | | | | | | | | | | Loop iterators are simple integers, no point to optimize the size and use u8. It only raises the question whether the variable is used in some other context. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * nfc: fdp: drop unneeded cast for printing firmware size in dev_dbg()Krzysztof Kozlowski2021-07-291-4/+4
| | | | | | | | | | | | | | | | Size of firmware is a type of size_t, so print it directly instead of casting to int. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * nfc: nfcsim: constify drvdata (struct nfcsim)Krzysztof Kozlowski2021-07-291-1/+1
| | | | | | | | | | | | | | | | nfcsim_abort_cmd() does not modify struct nfcsim, so local variable can be a pointer to const. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * nfc: virtual_ncidev: constify pointer to nfc_devKrzysztof Kozlowski2021-07-291-1/+1
| | | | | | | | | | | | | | | | virtual_ncidev_ioctl() does not modify struct nfc_dev, so local variable can be a pointer to const. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * nfc: trf7970a: constify several pointersKrzysztof Kozlowski2021-07-291-8/+9
| | | | | | | | | | | | | | | | Several functions do not modify pointed data so arguments and local variables can be const for correctness and safety. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * nfc: port100: constify several pointersKrzysztof Kozlowski2021-07-291-17/+20
| | | | | | | | | | | | | | | | Several functions do not modify pointed data so arguments and local variables can be const for correctness and safety. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * nfc: mei_phy: constify buffer passed to mei_nfc_send()Krzysztof Kozlowski2021-07-291-1/+1
| | | | | | | | | | | | | | | | The buffer passed to mei_nfc_send() can be const for correctness and safety. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * nfc: constify passed nfc_devKrzysztof Kozlowski2021-07-291-2/+2
|/ | | | | | | | The struct nfc_dev is not modified by nfc_get_drvdata() and nfc_device_name() so it can be made a const. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge branch 'skb-gro-optimize'David S. Miller2021-07-296-16/+62
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Paolo Abeni says: ==================== sk_buff: optimize GRO for the common case This is a trimmed down revision of "sk_buff: optimize layout for GRO", specifically dropping the changes to the sk_buff layout[1]. This series tries to accomplish 2 goals: - optimize the GRO stage for the most common scenario, avoiding a bunch of conditional and some more code - let owned skbs entering the GRO engine, allowing backpressure in the veth GRO forward path. A new sk_buff flag (!!!) is introduced and maintained for GRO's sake. Such field uses an existing hole, so there is no change to the sk_buff size. [1] two main reasons: - move skb->inner_ field requires some extra care, as some in kernel users access and the fields regardless of skb->encapsulation. - extending secmark size clash with ct and nft uAPIs address the all above is possible, I think, but for sure not in a single series. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * veth: use skb_prepare_for_gro()Paolo Abeni2021-07-291-1/+1
| | | | | | | | | | | | | | | | Leveraging the previous patch we can now avoid orphaning the skb in the veth gro path, allowing correct backpressure. Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * skbuff: allow 'slow_gro' for skb carring sock referencePaolo Abeni2021-07-293-4/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change leverages the infrastructure introduced by the previous patches to allow soft devices passing to the GRO engine owned skbs without impacting the fast-path. It's up to the GRO caller ensuring the slow_gro bit validity before invoking the GRO engine. The new helper skb_prepare_for_gro() is introduced for that goal. On slow_gro, skbs are aggregated only with equal sk. Additionally, skb truesize on GRO recycle and free is correctly updated so that sk wmem is not changed by the GRO processing. rfc-> v1: - fixed bad truesize on dev_gro_receive NAPI_FREE - use the existing state bit Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: optimize GRO for the common case.Paolo Abeni2021-07-292-11/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | After the previous patches, at GRO time, skb->slow_gro is usually 0, unless the packets comes from some H/W offload slowpath or tunnel. We can optimize the GRO code assuming !skb->slow_gro is likely. This remove multiple conditionals in the most common path, at the price of an additional one when we hit the above "slow-paths". Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * sk_buff: track extension status in slow_groPaolo Abeni2021-07-291-0/+1
| | | | | | | | | | | | | | | | Similar to the previous one, but tracking the active_extensions field status. Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * sk_buff: track dst status in slow_groPaolo Abeni2021-07-292-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | Similar to the previous patch, but covering the dst field: the slow_gro flag is additionally set when a dst is attached to the skb RFC -> v1: - use the existing flag instead of adding a new one Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * sk_buff: introduce 'slow_gro' flagsPaolo Abeni2021-07-291-0/+4
|/ | | | | | | | | | | | | | | | | The new flag tracks if any state field is set, so that GRO requires 'unusual'/slow prepare steps. Set such flag when a ct entry is attached to the skb, and never clear it. The new bit uses an existing hole into the sk_buff struct RFC -> v1: - use a single state bit, never clear it - avoid moving the _nfct field Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* Documentation: networking: add ioam6-sysctl into indexHu Haowen2021-07-281-0/+1
| | | | | | | Append ioam6-sysctl to toctree in order to get rid of building warnings. Signed-off-by: Hu Haowen <src.res@email.cn> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: dsa: sja1105: be stateless when installing FDB entriesVladimir Oltean2021-07-282-18/+3
| | | | | | | | | | | | | | | Currently there are issues when adding a bridge FDB entry as VLAN-aware and deleting it as VLAN-unaware, or vice versa. However this is an unneeded complication, since the bridge always installs its default FDB entries in VLAN 0 to match on VLAN-unaware ports, and in the default_pvid (VLAN 1) to match on VLAN-aware ports. So instead of trying to outsmart the bridge, just install all entries it gives us, and they will start matching packets when the vlan_filtering mode changes. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge branch 'switchdev-notifiers'David S. Miller2021-07-283-32/+12
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Vladimir Oltean says: ==================== Plug the last 2 holes in the switchdev notifiers for local FDB entries The work for trapping local FDB entries to the CPU in switchdev/DSA started with the "RX filtering in DSA" series: https://patchwork.kernel.org/project/netdevbpf/cover/20210629140658.2510288-1-olteanv@gmail.com/ and was continued with further improvements such as "Fan out FDB entries pointing towards the bridge to all switchdev member ports": https://patchwork.kernel.org/project/netdevbpf/cover/20210719135140.278938-1-vladimir.oltean@nxp.com/ https://patchwork.kernel.org/project/netdevbpf/cover/20210720173557.999534-1-vladimir.oltean@nxp.com/ There are only 2 more issues left to be addressed (famous last words), and these are: - dynamically learned FDB entries towards interfaces foreign to DSA need to be replayed too - adding/deleting a VLAN on a port causes the local FDB entries in that VLAN to be prematurely deleted This patch series addresses both, and patch 2 depends on 1 to work properly. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: bridge: switchdev: treat local FDBs the same as entries towards the bridgeVladimir Oltean2021-07-282-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently the following script: 1. ip link add br0 type bridge vlan_filtering 1 && ip link set br0 up 2. ip link set swp2 up && ip link set swp2 master br0 3. ip link set swp3 up && ip link set swp3 master br0 4. ip link set swp4 up && ip link set swp4 master br0 5. bridge vlan del dev swp2 vid 1 6. bridge vlan del dev swp3 vid 1 7. ip link set swp4 nomaster 8. ip link set swp3 nomaster produces the following output: [ 641.010738] sja1105 spi0.1: port 2 failed to delete 00:1f:7b:63:02:48 vid 1 from fdb: -2 [ swp2, swp3 and br0 all have the same MAC address, the one listed above ] In short, this happens because the number of FDB entry additions notified to switchdev is unbalanced with the number of deletions. At step 1, the bridge has a random MAC address. At step 2, the br_fdb_replay of swp2 receives this initial MAC address. Then the bridge inherits the MAC address of swp2 via br_fdb_change_mac_address(), and it notifies switchdev (only swp2 at this point) of the deletion of the random MAC address and the addition of 00:1f:7b:63:02:48 as a local FDB entry with fdb->dst == swp2, in VLANs 0 and the default_pvid (1). During step 7: del_nbp -> br_fdb_delete_by_port(br, p, vid=0, do_all=1); -> fdb_delete_local(br, p, f); br_fdb_delete_by_port() deletes all entries towards the ports, regardless of vid, because do_all is 1. fdb_delete_local() has logic to migrate local FDB entries deleted from one port to another port which shares the same MAC address and is in the same VLAN, or to the bridge device itself. This migration happens without notifying switchdev of the deletion on the old port and the addition on the new one, just fdb->dst is changed and the added_by_user flag is cleared. In the example above, the del_nbp(swp4) causes the "addr 00:1f:7b:63:02:48 vid 1" local FDB entry with fdb->dst == swp4 that existed up until then to be migrated directly towards the bridge (fdb->dst == NULL). This is because it cannot be migrated to any of the other ports (swp2 and swp3 are not in VLAN 1). After the migration to br0 takes place, swp4 requests a deletion replay of all FDB entries. Since the "addr 00:1f:7b:63:02:48 vid 1" entry now point towards the bridge, a deletion of it is replayed. There was just a prior addition of this address, so the switchdev driver deletes this entry. Then, the del_nbp(swp3) at step 8 triggers another br_fdb_replay, and switchdev is notified again to delete "addr 00:1f:7b:63:02:48 vid 1". But it can't because it no longer has it, so it returns -ENOENT. There are other possibilities to trigger this issue, but this is by far the simplest to explain. To fix this, we must avoid the situation where the addition of an FDB entry is notified to switchdev as a local entry on a port, and the deletion is notified on the bridge itself. Considering that the 2 types of FDB entries are completely equivalent and we cannot have the same MAC address as a local entry on 2 bridge ports, or on a bridge port and pointing towards the bridge at the same time, it makes sense to hide away from switchdev completely the fact that a local FDB entry is associated with a given bridge port at all. Just say that it points towards the bridge, it should make no difference whatsoever to the switchdev driver and should even lead to a simpler overall implementation, will less cases to handle. This also avoids any modification at all to the core bridge driver, just what is reported to switchdev changes. With the local/permanent entries on bridge ports being already reported to user space, it is hard to believe that the bridge behavior can change in any backwards-incompatible way such as making all local FDB entries point towards the bridge. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: bridge: switchdev: replay the entire FDB for each portVladimir Oltean2021-07-283-30/+11
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently when a switchdev port joins a bridge, we replay all FDB entries pointing towards that port or towards the bridge. However, this is insufficient in certain situations: (a) DSA, through its assisted_learning_on_cpu_port logic, snoops dynamically learned FDB entries on foreign interfaces. These are FDB entries that are pointing neither towards the newly joined switchdev port, nor towards the bridge. So these addresses would be missed when joining a bridge where a foreign interface has already learned some addresses, and they would also linger on if the DSA port leaves the bridge before the foreign interface forgets them. None of this happens if we replay the entire FDB when the port joins. (b) There is a desire to treat local FDB entries on a port (i.e. the port's termination MAC address) identically to FDB entries pointing towards the bridge itself. More details on the reason behind this in the next patch. The point is that this cannot be done given the current structure of br_fdb_replay() in this situation: ip link set swp0 master br0 # br0 inherits its MAC address from swp0 ip link set swp1 master br0 What is desirable is that when swp1 joins the bridge, br_fdb_replay() also notifies swp1 of br0's MAC address, but this won't in fact happen because the MAC address of br0 does not have fdb->dst == NULL (it doesn't point towards the bridge), but it has fdb->dst == swp0. So our current logic makes it impossible for that address to be replayed. But if we dump the entire FDB instead of just the entries with fdb->dst == swp1 and fdb->dst == NULL, then the inherited MAC address of br0 will be replayed too, which is what we need. A natural question arises: say there is an FDB entry to be replayed, like a MAC address dynamically learned on a foreign interface that belongs to a bridge where no switchdev port has joined yet. If 10 switchdev ports belonging to the same driver join this bridge, one by one, won't every port get notified 10 times of the foreign FDB entry, amounting to a total of 100 notifications for this FDB entry in the switchdev driver? Well, yes, but this is where the "void *ctx" argument for br_fdb_replay is useful: every port of the switchdev driver is notified whenever any other port requests an FDB replay, but because the replay was initiated by a different port, its context is different from the initiating port's context, so it ignores those replays. So the foreign FDB entry will be installed only 10 times, once per port. This is done so that the following 4 code paths are always well balanced: (a) addition of foreign FDB entry is replayed when port joins bridge (b) deletion of foreign FDB entry is replayed when port leaves bridge (c) addition of foreign FDB entry is notified to all ports currently in bridge (c) deletion of foreign FDB entry is notified to all ports currently in bridge Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge branch 'bnxt_en-ptp'David S. Miller2021-07-284-22/+423
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Michael Chan says: ==================== bnxt_en: PTP enhancements This series adds two PTP enhancements. This first one is to register the PHC during probe time and keep it registered whether it is in ifup or ifdown state. It will get unregistered and possibly reregistered if the firmware PTP capability changes after firmware reset. The second one is to add the 1PPS (one pulse per second) feature to support input/output of the 1PPS signal. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * bnxt_en: Log if an invalid signal detected on TSIO pinPavan Chebbi2021-07-282-0/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | FW can report to driver via ASYNC event if it encountered an invalid signal on any TSIO PIN. Driver will log this event for the user to take corrective action. Reviewed-by: Somnath Kotur <somnath.kotur@broadcom.com> Reviewed-by: Arvind Susarla <arvind.susarla@broadcom.com> Reviewed-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * bnxt_en: Event handler for PPS eventsPavan Chebbi2021-07-283-0/+58
| | | | | | | | | | | | | | | | | | | | | | Once the PPS pins are configured, the FW can report PPS values using ASYNC event. This patch adds the ASYNC event handler and subsequent reporting of the events to kernel. Signed-off-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * bnxt_en: 1PPS functions to configure TSIO pinsPavan Chebbi2021-07-283-2/+178
| | | | | | | | | | | | | | | | | | | | | | | | | | Application will send ioctls to set/clear PPS pin functions based on user input. This patch implements the driver callbacks that will configure the TSIO pins using firmware commands. After firmware reset, the TSIO pins will be reconfigured again. Reviewed-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * bnxt_en: 1PPS support for 5750X family chipsPavan Chebbi2021-07-284-1/+113
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1PPS (One Pulse Per Second) is a signal generated either by the NIC PHC or an external timing source. Integrating the support to configure and use 1PPS using the TSIO pins along with PTP timestamps will add Grand Master capability to the 5750X family chipsets. This patch initializes the driver data structures and registers the 1PPS with kernel, based on the TSIO pins' capability in the hardware. This will create a /dev/ppsX device which applications can use to receive PPS events. Later patches will define functions to configure and use the pins. Reviewed-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * bnxt_en: Do not read the PTP PHC during chip resetMichael Chan2021-07-282-11/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During error recovery or hot firmware upgrade, the chip may be under reset and the PHC register read cycles may cause completion timeouts. Check that the chip is not under reset condition before proceeding to read the PHC by checking the flag BNXT_STATE_IN_FW_RESET. We also need to take the ptp_lock before we set this flag to prevent race conditions. We need this logic because the PHC now will stay registered after bnxt_close(). Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * bnxt_en: Move bnxt_ptp_init() from bnxt_open() back to bnxt_init_one()Michael Chan2021-07-282-9/+12
|/ | | | | | | | | | | | | | | | | It was pointed out by Richard Cochran that registering the PHC during probe is better than during ifup, so move bnxt_ptp_init() back to bnxt_init_one(). In order to work correctly after firmware reset which may result in PTP config. changes, we modify bnxt_ptp_init() to return if the PHC has been registered earlier. If PTP is no longer supported by the new firmware, we will unregister the PHC and clean up. This partially reverts: d7859afb6880 ("bnxt_en: Move bnxt_ptp_init() to bnxt_open()") Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge branch 'fec-next'David S. Miller2021-07-286-4/+202
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Joakim Zhang says: ==================== net: fec: add support for i.MX8MQ and i.MX8QM This patch set adds supports for i.MX8MQ and i.MX8QM, both of them extend new features. ChangeLogs: V1->V2: * rebase on schema binding, and update dts compatible string. * use generic ethernet controller property for MAC internal RGMII clock delay rx-internal-delay-ps and tx-internal-delay-ps ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * arm64: dts: imx8qxp: add "fsl,imx8qm-fec" compatible string for FECJoakim Zhang2021-07-281-2/+2
| | | | | | | | | | | | | | | | Add "fsl,imx8qm-fec" compatible string for FEC to support new feature (RGMII delayed clock). Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * arm64: dts: imx8m: add "fsl,imx8mq-fec" compatible string for FECJoakim Zhang2021-07-282-2/+2
| | | | | | | | | | | | | | | | Add "fsl,imx8mq-fec" compatible string for FEC to support new feature (IEEE 802.3az EEE standard). Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: fec: add MAC internal delayed clock feature supportFugang Duan2021-07-282-0/+33
| | | | | | | | | | | | | | | | | | | | i.MX8QM ENET IP version support timing specification that MAC integrate clock delay in RGMII mode, the delayed TXC/RXC as an alternative option to work well with various PHYs. Signed-off-by: Fugang Duan <fugang.duan@nxp.com> Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: fec: add eee mode tx lpi supportFugang Duan2021-07-282-0/+95
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The i.MX8MQ ENET version support IEEE802.3az eee mode, add eee mode tx lpi enable to support ethtool interface. usage: 1. set sleep and wake timer to 5ms: ethtool --set-eee eth0 eee on tx-lpi on tx-timer 5000 2. check the eee mode: ~# ethtool --show-eee eth0 EEE Settings for eth0: EEE status: enabled - active Tx LPI: 5000 (us) Supported EEE link modes: 100baseT/Full 1000baseT/Full Advertised EEE link modes: 100baseT/Full 1000baseT/Full Link partner advertised EEE link modes: 100baseT/Full Note: For realtime case and IEEE1588 ptp case, it should disable EEE mode. Signed-off-by: Fugang Duan <fugang.duan@nxp.com> Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: fec: add imx8mq and imx8qm new versions supportFugang Duan2021-07-282-0/+43
| | | | | | | | | | | | | | | | | | | | | | The ENET of imx8mq and imx8qm are basically the same as imx6sx, but they have new features support based on imx6sx, like: - imx8mq: supports IEEE 802.3az EEE standard. - imx8qm: supports RGMII mode delayed clock. Signed-off-by: Fugang Duan <fugang.duan@nxp.com> Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * dt-bindings: net: fsl,fec: add RGMII internal clock delayJoakim Zhang2021-07-281-0/+9
| | | | | | | | | | | | | | Add RGMII internal clock delay for FEC controller. Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * dt-bindings: net: fsl,fec: update compatible itemsJoakim Zhang2021-07-281-0/+18
|/ | | | | | | Add more compatible items for i.MX8/8M platforms. Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* tc-testing: Add control-plane selftest for skbmod SKBMOD_F_ECN optionPeilin Ye2021-07-281-0/+24
| | | | | | | | | | | | | Recently we added a new option, SKBMOD_F_ECN, to tc-skbmod(8). Add a control-plane selftest for it. Depends on kernel patch "net/sched: act_skbmod: Add SKBMOD_F_ECN option support", as well as iproute2 patch "tc/skbmod: Introduce SKBMOD_F_ECN option". Reviewed-by: Cong Wang <cong.wang@bytedance.com> Signed-off-by: Peilin Ye <peilin.ye@bytedance.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net/sched: act_skbmod: Add SKBMOD_F_ECN option supportPeilin Ye2021-07-282-12/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, when doing rate limiting using the tc-police(8) action, the easiest way is to simply drop the packets which exceed or conform the configured bandwidth limit. Add a new option to tc-skbmod(8), so that users may use the ECN [1] extension to explicitly inform the receiver about the congestion instead of dropping packets "on the floor". The 2 least significant bits of the Traffic Class field in IPv4 and IPv6 headers are used to represent different ECN states [2]: 0b00: "Non ECN-Capable Transport", Non-ECT 0b10: "ECN Capable Transport", ECT(0) 0b01: "ECN Capable Transport", ECT(1) 0b11: "Congestion Encountered", CE As an example: $ tc filter add dev eth0 parent 1: protocol ip prio 10 \ matchall action skbmod ecn Doing the above marks all ECT(0) and ECT(1) packets as CE. It does NOT affect Non-ECT or non-IP packets. In the tc-police scenario mentioned above, users may pipe a tc-police action and a tc-skbmod "ecn" action together to achieve ECN-based rate limiting. For TCP connections, upon receiving a CE packet, the receiver will respond with an ECE packet, asking the sender to reduce their congestion window. However ECN also works with other L4 protocols e.g. DCCP and SCTP [2], and our implementation does not touch or care about L4 headers. The updated tc-skbmod SYNOPSIS looks like the following: tc ... action skbmod { set SETTABLE | swap SWAPPABLE | ecn } ... Only one of "set", "swap" or "ecn" shall be used in a single tc-skbmod command. Trying to use more than one of them at a time is considered undefined behavior; pipe multiple tc-skbmod commands together instead. "set" and "swap" only affect Ethernet packets, while "ecn" only affects IPv{4,6} packets. It is also worth mentioning that, in theory, the same effect could be achieved by piping a "police" action and a "bpf" action using the bpf_skb_ecn_set_ce() helper, but this requires eBPF programming from the user, thus impractical. Depends on patch "net/sched: act_skbmod: Skip non-Ethernet packets". [1] https://datatracker.ietf.org/doc/html/rfc3168 [2] https://en.wikipedia.org/wiki/Explicit_Congestion_Notification Reviewed-by: Cong Wang <cong.wang@bytedance.com> Signed-off-by: Peilin Ye <peilin.ye@bytedance.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* nfp: flower-ct: fix error return code in nfp_fl_ct_add_offload()Yang Yingliang2021-07-281-2/+6
| | | | | | | | | | | | If nfp_tunnel_add_ipv6_off() fails, it should return error code in nfp_fl_ct_add_offload(). Fixes: 5a2b93041646 ("nfp: flower-ct: compile match sections of flow_payload") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: Louis Peens <louis.peens@corigine.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge branch 'devlink-register'David S. Miller2021-07-285-45/+33
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Leon Romanovsky says: ==================== Remove duplicated devlink registration check Changelog: v1: * Added two new patches that remove registration field from mlx5 and ti drivers. v0: https://lore.kernel.org/lkml/ed7bbb1e4c51dd58e6035a058e93d16f883b09ce.1627215829.git.leonro@nvidia.com -------------------------------------------------------------------- Both registered flag and devlink pointer are set at the same time and indicate the same thing - devlink/devlink_port are ready. Instead of checking ->registered use devlink pointer as an indication. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-29 21:08:57 +0100