- 15 Jan, 2021 28 commits
-
-
Alex Elder authored
The GSI command timeout is currently 5 seconds, which is much higher than it should be. Express the timeout in milliseconds rather than seconds, and reduce it to 50 milliseconds. Signed-off-by:
Alex Elder <elder@linaro.org> Reviewed-by:
Saeed Mahameed <saeedm@nvidia.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Alex Elder authored
65;6003;1c The use of msleep() for small periods (less than 20 milliseconds) is not recommended because the actual delay can be much different than expected. We use msleep(1) in several places in the IPA driver to insert short delays. Replace them with usleep_range calls, which should reliably delay a period in the range requested. Signed-off-by:
-
Alex Elder authored
Create a new function gsi_irq_ev_ctrl_enable() that encapsulates enabling the event ring control GSI interrupt type, and enables a single event ring to signal that interrupt. When an event ring changes state as a result of an event ring command, it triggers this interrupt. Create an inverse function gsi_irq_ev_ctrl_disable() as well. Because only one event ring at a time is enabled for this interrupt, we can simply disable the interrupt for *all* channels. Create a pair of helpers that serve the same purpose for channel commands. Signed-off-by:
-
Alex Elder authored
The return value of gsi_command() is true if successful or false if we time out waiting for a completion interrupt. Rename the variables in the three callers of gsi_command() to be "timeout", to make it more obvious that's the only reason for failure. In addition, add a "gsi_" prefix to evt_ring_command() so its name is consistent with the convention used for GSI channel and generic commands. Signed-off-by:
-
Jakub Kicinski authored
Merge tag 'linux-can-next-for-5.12-20210114' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next Marc Kleine-Budde says: ==================== pull-request: can-next 2021-01-14 The first two patches update the MAINTAINERS file, Lukas Bulwahn's patch fixes the files entry for the tcan4x5x driver, which was broken by me in net-next. A patch by me adds the a missing header file to the CAN Networking Layer. The next 5 patches are by me and split the the CAN driver related infrastructure code into more files in a separate subdir. The next two patches by me clean up the CAN length related code. This is followed by 6 patches by Vincent Mailhol and me, they add helper code for for CAN frame length calculation neede for BQL support. A patch by Vincent Mailhol adds software TX timestamp support. The last patch is by me, targets the tcan4x5x driver, and removes the unneeded __packed attribute from the struct tcan4x5x_map_buf. * tag 'linux-can-next-for-5.12-20210114' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next: can: tcan4x5x: remove __packed attribute from struct tcan4x5x_map_buf can: dev: can_put_echo_skb(): add software tx timestamps can: dev: can_rx_offload_get_echo_skb(): extend to return can frame length can: dev: can_get_echo_skb(): extend to return can frame length can: dev: can_put_echo_skb(): extend to handle frame_len can: dev: extend struct can_skb_priv to hold CAN frame length can: length: can_skb_get_frame_len(): introduce function to get data length of frame in data link layer can: length: canfd_sanitize_len(): add function to sanitize CAN-FD data length can: length: can_fd_len2dlc(): simplify length calculcation can: length: convert to kernel coding style can: dev: move netlink related code into seperate file can: dev: move skb related into seperate file can: dev: move length related code into seperate file can: dev: move bittiming related code into seperate file can: dev: move driver related infrastructure into separate subdir MAINTAINERS: CAN network layer: add missing header file can-ml.h MAINTAINERS: adjust entry to tcan4x5x file split ==================== Link: https://lore.kernel.org/r/20210114075617.1402597-1-mkl@pengutronix.deSigned-off-by:
-
Jakub Kicinski authored
Tobias Waldekranz says: ==================== net: dsa: Link aggregation support Start of by adding an extra notification when adding a port to a bond, this allows static LAGs to be offloaded using the bonding driver. Then add the generic support required to offload link aggregates to drivers built on top of the DSA subsystem. Finally, implement offloading for the mv88e6xxx driver, i.e. Marvell's LinkStreet family. Supported LAG implementations: - Bonding - Team Supported modes: - Isolated. The LAG may be used as a regular interface outside of any bridge. - Bridged. The LAG may be added to a bridge, in which case switching is offloaded between the LAG and any other switch ports. I.e. the LAG behaves just like a port from this perspective. In bridged mode, the following is supported: - STP filtering. - VLAN filtering. - Multicast filtering. The bridge correctly snoops IGMP and configures the proper groups if snooping is enabled. Static groups can also be configured. MLD seems to work, but has not been extensively tested. - Unicast filtering. Automatic learning works. Static entries are _not_ supported. This will be added in a later series as it requires some more general refactoring in mv88e6xxx before I can test it. v4 -> v5: - Cleanup PVT configuration for LAGed ports in mv88e6xxx (Vladimir) - Document dsa_lag_{map,unmap} (Vladimir) ==================== Link: https://lore.kernel.org/r/20210113084255.22675-1-tobias@waldekranz.comSigned-off-by: -
Tobias Waldekranz authored
Packets ingressing on a LAG that egress on the CPU port, which are not classified as management, will have a FORWARD tag that does not contain the normal source device/port tuple. Instead the trunk bit will be set, and the port field holds the LAG id. Since the exact source port information is not available in the tag, frames are injected directly on the LAG interface and thus do never pass through any DSA port interface on ingress. Management frames (TO_CPU) are not affected and will pass through the DSA port interface as usual. Signed-off-by:
Tobias Waldekranz <tobias@waldekranz.com> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Reviewed-by:
Vladimir Oltean <olteanv@gmail.com> Signed-off-by:
-
Tobias Waldekranz authored
Support offloading of LAGs to hardware. LAGs may be attached to a bridge in which case VLANs, multicast groups, etc. are also offloaded as usual. Signed-off-by:
-
Tobias Waldekranz authored
Monitor the following events and notify the driver when: - A DSA port joins/leaves a LAG. - A LAG, made up of DSA ports, joins/leaves a bridge. - A DSA port in a LAG is enabled/disabled (enabled meaning "distributing" in 802.3ad LACP terms). When a LAG joins a bridge, the DSA subsystem will treat that as each individual port joining the bridge. The driver may look at the port's LAG device pointer to see if it is associated with any LAG, if that is required. This is analogue to how switchdev events are replicated out to all lower devices when reaching e.g. a LAG. Drivers can optionally request that DSA maintain a linear mapping from a LAG ID to the corresponding netdev by setting ds->num_lag_ids to the desired size. In the event that the hardware is not capable of offloading a particular LAG for any reason (the typical case being use of exotic modes like broadcast), DSA will take a hands-off approach, allowing the LAG to be formed as a pure software construct. This is reported back through the extended ACK, but is otherwise transparent to the user. Signed-off-by:
-
Tobias Waldekranz authored
In a situation where a standalone port is indirectly attached to a bridge (e.g. via a LAG) which is not offloaded, do not offload any port attributes either. The port should behave as a standard NIC. Previously, on mv88e6xxx, this meant that in the following setup: br0 / team0 / \ swp0 swp1 If vlan filtering was enabled on br0, swp0's and swp1's QMode was set to "secure". This caused all untagged packets to be dropped, as their default VID (0) was not loaded into the VTU. Signed-off-by: -
Tobias Waldekranz authored
When creating a static bond (e.g. balance-xor), all ports will always be enabled. This is set, and the corresponding notification is sent out, before the port is linked to the bond upper. In the offloaded case, this ordering is hard to deal with. The lower will first see a notification that it can not associate with any bond. Then the bond is joined. After that point no more notifications are sent, so all ports remain disabled. This change simply sends an extra notification once the port has been linked to the upper to synchronize the initial state. Signed-off-by:
Jay Vosburgh <jay.vosburgh@canonical.com> Tested-by:
-
Christophe JAILLET authored
The wrappers in include/linux/pci-dma-compat.h should go away. The patch has been generated with the coccinelle script below and has been hand modified to replace GFP_ with a correct flag. It has been compile tested. When memory is allocated in 'mlxsw_pci_queue_init()' and 'mlxsw_pci_fw_area_init()' GFP_KERNEL can be used because both functions are already using this flag and no lock is acquired. When memory is allocated in 'mlxsw_pci_mbox_alloc()' GFP_KERNEL can be used because it is only called from the probe function and no lock is acquired in the between. The call chain is: --> mlxsw_pci_probe() --> mlxsw_pci_cmd_init() --> mlxsw_pci_mbox_alloc() While at it, also replace the 'dma_set_mask/dma_set_coherent_mask' sequence by a less verbose 'dma_set_mask_and_coherent() call. @@ @@ - PCI_DMA_BIDIRECTIONAL + DMA_BIDIRECTIONAL @@ @@ - PCI_DMA_TODEVICE + DMA_TO_DEVICE @@ @@ - PCI_DMA_FROMDEVICE + DMA_FROM_DEVICE @@ @@ - PCI_DMA_NONE + DMA_NONE @@ expression e1, e2, e3; @@ - pci_alloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3; @@ - pci_zalloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3, e4; @@ - pci_free_consistent(e1, e2, e3, e4) + dma_free_coherent(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_single(e1, e2, e3, e4) + dma_map_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_single(e1, e2, e3, e4) + dma_unmap_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4, e5; @@ - pci_map_page(e1, e2, e3, e4, e5) + dma_map_page(&e1->dev, e2, e3, e4, e5) @@ expression e1, e2, e3, e4; @@ - pci_unmap_page(e1, e2, e3, e4) + dma_unmap_page(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_sg(e1, e2, e3, e4) + dma_map_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_sg(e1, e2, e3, e4) + dma_unmap_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_cpu(e1, e2, e3, e4) + dma_sync_single_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_device(e1, e2, e3, e4) + dma_sync_single_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_cpu(e1, e2, e3, e4) + dma_sync_sg_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_device(e1, e2, e3, e4) + dma_sync_sg_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2; @@ - pci_dma_mapping_error(e1, e2) + dma_mapping_error(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_dma_mask(e1, e2) + dma_set_mask(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_consistent_dma_mask(e1, e2) + dma_set_coherent_mask(&e1->dev, e2) Signed-off-by:Christophe JAILLET <christophe.jaillet@wanadoo.fr> Tested-by:
Ido Schimmel <idosch@nvidia.com> Link: https://lore.kernel.org/r/20210114084757.490540-1-christophe.jaillet@wanadoo.frSigned-off-by:
-
Vladimir Oltean authored
prestera_bridge_port_vlan_add should have been called with vlan->vid, however this was masked by the presence of the local vid variable and I did not notice the build warning. Reported-by:
kernel test robot <lkp@intel.com> Fixes: b7a9e0da ("net: switchdev: remove vid_begin -> vid_end range from VLAN objects") Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by:
Taras Chornyi <tchornyi@marvell.com> Link: https://lore.kernel.org/r/20210114083556.2274440-1-olteanv@gmail.comSigned-off-by:
-
Eelco Chaudron authored
As requested by upstream OVS, added some error messages in the validate_and_copy_dec_ttl function. Includes a small cleanup, which removes an unnecessary parameter from the dec_ttl_exception_handler() function. Reported-by:
Flavio Leitner <fbl@sysclose.org> Signed-off-by:
Eelco Chaudron <echaudro@redhat.com> Acked-by:
-
Jakub Kicinski authored
David Ahern says: ==================== selftests: Updates to allow single instance of nettest for client and server Update nettest to handle namespace change internally to allow a single instance to run both client and server modes. Device validation needs to be moved after the namespace change and a few run time options need to be split to allow values for client and server. v4 - really fix the memory leak with stdout/stderr buffers v3 - send proper status in do_server for UDP sockets - fix memory leak with stdout/stderr buffers - new patch with separate option for address binding - new patch to remove unnecessary newline v2 - fix checkpath warnings ==================== Link: https://lore.kernel.org/r/20210114030949.54425-1-dsahern@kernel.orgSigned-off-by:
-
David Ahern authored
Add separate option to nettest to specify local address binding in client mode. Signed-off-by:
David Ahern <dsahern@kernel.org> Signed-off-by:
-
David Ahern authored
Signed-off-by:
-
David Ahern authored
Add new options to nettest to specify device binding and expected device binding for server mode, and update fcnal-test script. This is needed to allow a single instance of nettest running both server and client modes to use different device bindings. Signed-off-by:
David Ahern <dsahern@gmail.com> Signed-off-by:
-
David Ahern authored
Add new option to nettest to specify MD5 password to use for client side. Update fcnal-test script. This is needed for a single instance running both server and client modes to test password mismatches. Signed-off-by:
-
David Ahern authored
nettest started with -r as the remote address for MD5 passwords. The -m argument was added to use prefixes with a length when that feature was added to the kernel. Since -r is used to specify remote address for client mode, change nettest to only use -m for MD5 passwords and update fcnal-test script. Signed-off-by:
-
David Ahern authored
When a single instance of nettest is used for client and server make sure address validation is only done for client mode. Signed-off-by:
-
David Ahern authored
A few logging lines are missing the newline, or need it moved up for cleaner logging. Signed-off-by:
-
David Ahern authored
When a single instance of nettest is doing both client and server modes, stdout and stderr messages can get interlaced and become unreadable. Allocate a new set of buffers for the child process handling server mode. Signed-off-by:
-
David Ahern authored
Add option to nettest to run both client and server within a single instance. Client forks a child process to run the server code. A pipe is used for the server to tell the client it has initialized and is ready or had an error. This avoid unnecessary sleeps to handle such race when the commands are separately launched. Signed-off-by:
Seth David Schoen <schoen@loyalty.org> Signed-off-by:
-
David Ahern authored
Add options to specify server and client network namespace to use before running respective functions. Signed-off-by:
-
David Ahern authored
IPv6 addresses can have a device name to declare a scope (e.g., fe80::5054:ff:fe12:3456%eth0). The next patch adds support to switch network namespace before running client or server code (or both), so move the address validation to the server and client functions. IPv4 multicast groups do not have the device scope in the address specification, so they can be validated inline with option parsing. Signed-off-by:
-
David Ahern authored
convert_addr needs to be invoked in a different location. Move the code up to avoid a forward declaration. Code move only. Signed-off-by:
-
David Ahern authored
Later patch adds support for switching network namespaces before running client, server or both. Device validations need to be done after the network namespace switch, so add a helper to do it and invoke in server and client code versus inline with argument parsing. Move related argument checks as well. Signed-off-by:
-
- 14 Jan, 2021 12 commits
-
-
Jakub Kicinski authored
Bjarni Jonasson says: ==================== Add 100 base-x mode Adding support for 100 base-x in phylink. The Sparx5 switch supports 100 base-x pcs (IEEE 802.3 Clause 24) 4b5b encoded. These patches adds phylink support for that mode. Tested in Sparx5, using sfp modules: Axcen 100fx AXFE-1314-0521 (base-fx) Axcen 100lx AXFE-1314-0551 (base-lx) HP SFP 100FX J9054C (bx-10) Excom SFP-SX-M1002 (base-lx) v1 -> v2: Added description to Documentation/networking/phy.rst Moved PHY_INTERFACE_MODE_100BASEX to above 1000BASEX Patching against net-next ==================== Link: https://lore.kernel.org/r/20210113115626.17381-1-bjarni.jonasson@microchip.comSigned-off-by:
-
Bjarni Jonasson authored
Add support for 100Base-FX, 100Base-LX, 100Base-PX and 100Base-BX10 modules This is needed for Sparx-5 switch. Signed-off-by:
Bjarni Jonasson <bjarni.jonasson@microchip.com> Reviewed-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Bjarni Jonasson authored
Sparx-5 supports this mode and it is missing in the PHY core. Signed-off-by:
-
Russell King authored
This bit is enabled by default and advertises support for extended next page support. XNP is only needed for 10GBase-T and MultiGig support which is not supported. Additionally, Cisco MultiGig switches will read this bit and attempt 10Gb negotiation even though Next Page support is disabled. This will cause timeouts when the interface is forced to 100Mbps and auto-negotiation will fail. The interfaces are only 1000Base-T and supporting auto-negotiation for this only requires the Next Page bit to be set. Taken from: https://github.com/SolidRun/linux-stable/commit/7406c5244b7ea6bc17a2afe8568277a8c4b126a9 and adapted to mainline kernels by rmk. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/E1kzSdb-000417-FJ@rmk-PC.armlinux.org.ukSigned-off-by:
-
Marc Kleine-Budde authored
The first member of struct tcan4x5x_map_buf is the struct tcan4x5x_buf_cmd, which has a size of 4 bytes. It's followed by an array of u8. The compiler places the array directly after the struct tcan4x5x_buf_cmd. This patch removes the not needed attribute __packed from the struct tcan4x5x_map_buf. Suggested-by:
Marc Kleine-Budde <mkl@pengutronix.de>
-
Vincent Mailhol authored
Call skb_tx_timestamp() within can_put_echo_skb() so that a software tx timestamp gets attached to the skb. There two main reasons to include this call in can_put_echo_skb(): * It easily allow to enable the tx timestamp on all devices with just one small change. * According to Documentation/networking/timestamping.rst, the tx timestamps should be generated in the device driver as close as possible, but always prior to passing the packet to the network interface. During the call to can_put_echo_skb(), the skb gets cloned meaning that the driver should not dereference the skb variable anymore after can_put_echo_skb() returns. This makes can_put_echo_skb() the very last place we can use the skb without having to access the echo_skb[] array. Remark: by default, skb_tx_timestamp() does nothing. It needs to be activated by passing the SOF_TIMESTAMPING_TX_SOFTWARE flag either through socket options or control messages. References: * Support for the error queue in CAN RAW sockets (which is needed for tx timestamps) was introduced in: https://git.kernel.org//torvalds/c/eb88531bdbfaafb827192d1fc6c5a3fcc4fadd96 * Put the call to skb_tx_timestamp() just before adding it to the array: https://lore.kernel.org/r/043c3ea1-6bdd-59c0-0269-27b2b5b36cec@victronenergy.com * About Tx hardware timestamps https://lore.kernel.org/r/20210111171152.GB11715@hoboy.vegasvil.orgSigned-off-by:Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://lore.kernel.org/r/20210112095437.6488-2-mailhol.vincent@wanadoo.frSigned-off-by:
-
Marc Kleine-Budde authored
In order to implement byte queue limits (bql) in CAN drivers, the length of the CAN frame needs to be passed into the networking stack after queueing and after transmission completion. To avoid to calculate this length twice, extend can_rx_offload_get_echo_skb() to return that value. Convert all users of this function, too. Reviewed-by:
-
Marc Kleine-Budde authored
In order to implement byte queue limits (bql) in CAN drivers, the length of the CAN frame needs to be passed into the networking stack after queueing and after transmission completion. To avoid to calculate this length twice, extend can_get_echo_skb() to return that value. Convert all users of this function, too. Reviewed-by:
-
Vincent Mailhol authored
Add a frame_len argument to can_put_echo_skb() which is used to save length of the CAN frame into field frame_len of struct can_skb_priv so that it can be later used after transmission completion. Convert all users of this function, too. Drivers which implement BQL call can_put_echo_skb() with the output of can_skb_get_frame_len(skb) and drivers which do not simply pass zero as an input (in the same way that NULL would be given to can_get_echo_skb()). This way, we have a nice symmetry between the two echo functions. Link: https://lore.kernel.org/r/20210111061335.39983-1-mailhol.vincent@wanadoo.frSigned-off-by:
-
Marc Kleine-Budde authored
In order to implement byte queue limits (bql) in CAN drivers, the length of the CAN frame needs to be passed into the networking stack after queueing and after transmission completion. To avoid to calculate this length twice, extend the struct can_skb_priv to hold the length of the CAN frame and extend __can_get_echo_skb() to return that value. Reviewed-by:
-
Vincent Mailhol authored
can: length: can_skb_get_frame_len(): introduce function to get data length of frame in data link layer This patch adds the function can_skb_get_frame_len() which returns the length of a CAN frame on the data link layer, including Start-of-frame, Identifier, various other bits, the actual data, the CRC, the End-of-frame, the Inter frame spacing. Co-developed-by:
Arunachalam Santhanam <arunachalam.santhanam@in.bosch.com> Signed-off-by:
-
Marc Kleine-Budde authored
The data field in CAN-FD frames have specifig frame length (0, 1, 2, 3, 4, 5, 6, 7, 8, 12, 16, 20, 24, 32, 48, 64). This function "rounds" up a given length to the next valid CAN-FD frame length. Reviewed-by:
-
