- 12 Jun, 2021 27 commits
-
-
David S. Miller authored
Alex Elder says: ==================== net: qualcomm: rmnet: MAPv4 download checksum cleanup, part 2 This is part 2 of a large series that reworks some code that handles downloaded packets when MAPv4 checksum offload is enabled. The first part, which includes an overview, is here: https://lore.kernel.org/netdev/20210611190529.3085813-1-elder@linaro.org/ This second part of the series completes the simplification of this handling code, removing unnecessary byte swaps and bitwise inversions of checksum values, and along the way avoids the need for almost all of the forced type casts. The checksum field in an RMNet download trailer is given __sum16_t type to accurately reflect the meaning of that field. ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Alex Elder authored
We don't support any extension headers for IPv6 packets. Extension headers therefore contribute 0 bytes to the payload length. As a result we can just use the IPv6 payload length as the length used to compute the pseudo header checksum for both UDP and TCP messages. Signed-off-by:
Alex Elder <elder@linaro.org> Signed-off-by:
-
Alex Elder authored
We compare a payload checksum with a pseudo checksum value for equality in rmnet_map_ipv4_dl_csum_trailer(). Both of those values are computed with a unary NOT (~) operation. The result of the comparison is the same if we omit that NOT for both values. Remove these operations in rmnet_map_ipv6_dl_csum_trailer() also. Signed-off-by:
-
Alex Elder authored
The csum_value field in the rmnet_map_dl_csum_trailer structure is a "real" Internet checksum. It is a 16 bit value, in big endian format, which represents an inverted ones' complement sum over pairs of bytes. Make that clear by changing its type to __sum16. This makes a typecast in rmnet_map_ipv4_dl_csum_trailer() and another in rmnet_map_ipv6_dl_csum_trailer() unnecessary. Signed-off-by:
-
Alex Elder authored
The previous patch makes rmnet_map_ipv4_dl_csum_trailer() return early with an error if it is determined that the computed checksum for the IP payload does not match what was expected. If the computed checksum *does* match the expected value, the IP payload (i.e., the transport message), can be considered good. There is no need to do any further processing of the message. This means a big block of code is unnecessary for validating the transport checksum value, and can be removed. Make comparable changes in rmnet_map_ipv6_dl_csum_trailer(). Signed-off-by:
-
Alex Elder authored
In rmnet_map_ipv4_dl_csum_trailer(), if the sum of the trailer checksum and the pseudo checksum is non-zero, checksum validation has failed. We can return an error as soon as we know that. We can do the same thing in rmnet_map_ipv6_dl_csum_trailer(). Add some comments that explain where we're headed. Signed-off-by:
-
Alex Elder authored
This patch simply demonstrates that a checksum value computed when verifying an offloaded transport checksum value for both IPv4 and IPv6 is (normally) 0. It can be squashed into the next patch. Signed-off-by:
-
Alex Elder authored
With the ones' complement arithmetic, the sum of two negated values is equal to the negation of the sum of the two original values [1]. Rearrange the calculation ip6_payload_sum using this property. [1] https://tools.ietf.org/html/rfc1071Signed-off-by:
-
Alex Elder authored
In rmnet_map_ipv4_dl_csum_trailer(), remove the "csum_temp" and "addend" local variables, and simplify a few lines of code. Remove the "csum_temp", "csum_value", "ip6_hdr_csum", and "addend" local variables in rmnet_map_ipv6_dl_csum_trailer(), and simplify a few lines of code there as well. Signed-off-by:
-
David S. Miller authored
Loic Poulain says: ==================== net: Add WWAN link creation support Most of the modern WWAN modems are able to support multiple network contexts, allowing user to connect to different APNs (e.g. Internet, MMS, etc...). These contexts are usually dynamically configured via a control channel such as MBIM, QMI or AT. Each context is naturally represented as a network link/device, and the muxing of these links is usually vendor/bus specific (QMAP, MBIM, intel iosm...). Today some drivers create a static collection of netdevs at init time, some relies on VLAN link for associating a context (cdc-mbim), some exposes sysfs attribute for dynamically creating additional netdev (qmi_wwan add_mux attr) or relies on vendor specific link type (rmnet) for performing the muxing... so there is no generic way to handle WWAN links, making user side integration painful. This series introduces a generic WWAN link management interface to the WWAN framework, allowing user to dynamically create and remove WWAN links through rtnetlink ('wwan' type). The underlying 'muxing' vendor implementation is completely abstracted. The idea is to use this interface for upcoming WWAN drivers (intel iosm) and to progressively integrate support into existing ones (qmi_wwan, cdc-mbim, mhi_net, etc...). v2: - Squashed Johannes and Sergey changes - Added IFLA_PARENT_DEV_BUS_NAME attribute - reworded commit message + introduce Sergey's comment v3: - Added basic new interface user to this series (mhi_net) - Moved IFLA_PARENT_DEV_NAME nla_policy introduction to right patch - Added cover letter - moved kdoc to .c file ==================== Signed-off-by: -
Loic Poulain authored
Register wwan_ops for link management via wwan rtnetlink. This is only basic support for now, since we only support creating one single link (link-0), but is useful to validate new wwan rtnetlink interface. For backward compatibity support, we still register a default netdev at probe time, except if 'create_default_iface' module parameter is set to false. This has been tested with iproute2 and mbimcli: $ ip link add dev wwan0-0 parentdev-name wwan0 type wwan linkid 0 $ mbimcli -p -d /dev/wwan0p2MBIM --connect apn=free $ ip link set dev wwan0-0 up $ ip addr add dev wwan0 ${IP} $ ip route replace default via ${IP} $ ping 8.8.8.8 ... Signed-off-by:Loic Poulain <loic.poulain@linaro.org> Signed-off-by:
-
Johannes Berg authored
Add support to create (and destroy) interfaces via a new rtnetlink kind "wwan". The responsible driver has to use the new wwan_register_ops() to make this possible. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
Sergey Ryazanov <ryazanov.s.a@gmail.com> Signed-off-by:
-
Johannes Berg authored
In some cases, for example in the upcoming WWAN framework changes, there's no natural "parent netdev", so sometimes dummy netdevs are created or similar. IFLA_PARENT_DEV_NAME is a new attribute intended to contain a device (sysfs, struct device) name that can be used instead when creating a new netdev, if the rtnetlink family implements it. As suggested by Parav Pandit, we also introduce IFLA_PARENT_DEV_BUS_NAME attribute in order to uniquely identify a device on the system (with bus/name pair). ip-link(8) support for the generic parent device attributes will help us avoid code duplication, so no other link type will require a custom code to handle the parent name attribute. E.g. the WWAN interface creation command will looks like this: $ ip link add wwan0-1 parent-dev wwan0 type wwan channel-id 1 So, some future subsystem (or driver) FOO will have an interface creation command that looks like this: $ ip link add foo1-3 parent-dev foo1 type foo bar-id 3 baz-type Y Below is an example of dumping link info of a random device with these new attributes: $ ip --details link show wlp0s20f3 4: wlp0s20f3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DORMANT group default qlen 1000 ... parent_bus pci parent_dev 0000:00:14.3 Co-developed-by: -
Johannes Berg authored
In order to make rtnetlink ops that can create different kinds of devices, like what we want to add to the WWAN framework, the priv_size and setup parameters aren't quite sufficient. Make this easier to manage by allowing ops to allocate their own netdev via an @alloc method that gets the tb netlink data. Signed-off-by:
-
Lijun Pan authored
Fix the following kernel build warnings: drivers/net/ethernet/ibm/ibmvnic.c:1516: warning: Function parameter or member 'skb' not described in 'build_hdr_descs_arr' drivers/net/ethernet/ibm/ibmvnic.c:1516: warning: Function parameter or member 'indir_arr' not described in 'build_hdr_descs_arr' drivers/net/ethernet/ibm/ibmvnic.c:1516: warning: Excess function parameter 'txbuff' description in 'build_hdr_descs_arr' Signed-off-by:
Lijun Pan <lijunp213@gmail.com> Signed-off-by:
-
Lijun Pan authored
drivers/net/ethernet/ibm/ibmvnic.c: In function ‘adapter_state_to_string’: drivers/net/ethernet/ibm/ibmvnic.c:855:2: warning: enumeration value ‘VNIC_DOWN’ not handled in switch [-Wswitch] 855 | switch (state) { | ^~~~~~ drivers/net/ethernet/ibm/ibmvnic.c: In function ‘reset_reason_to_string’: drivers/net/ethernet/ibm/ibmvnic.c:1958:2: warning: enumeration value ‘VNIC_RESET_PASSIVE_INIT’ not handled in switch [-Wswitch] 1958 | switch (reason) { | ^~~~~~ Reported-by:kernel test robot <lkp@intel.com> Signed-off-by:
-
David S. Miller authored
Wong Vee Khee says: ==================== stmmac: intel: minor clean-up This patch series include two minor-cleanup patches: 1. Move all the hardcoded DEFINEs to dwmac-intel header file. 2. Fix the wrong kernel-doc on the intel_eth_pci_remove() function. Since the changes are minor, only basic sanity tests are done on a Intel TigerLake with Marvell88E2110 PHY:- - Link is up and able to perform ping. - phc2sys and ptp4l are running without errors. ==================== Signed-off-by: -
Wong Vee Khee authored
Kernel-doc for intel_eth_pci_remove is incorrect, pdev datatype is struct pci_dev. Changed it to the 'pci device pointer'. Signed-off-by:
Wong Vee Khee <vee.khee.wong@linux.intel.com> Signed-off-by:
-
Wong Vee Khee authored
Currently some of the dwmac-intel definitions are in the header file, while some are in the driver source file. Cleaning this by moving all the definitions to the header file. Signed-off-by:
-
David S. Miller authored
Steen Hegelund says: ==================== Add 25G BASE-R support This series add the 25G BASE-R mode to the set modes supported. This mode is used by the Sparx5 Switch for its 25G SerDes. ==================== Signed-off-by: -
Steen Hegelund authored
Add 25gbase-r interface type and speed to phylink. This is needed for the Sparx5 switch. Signed-off-by:
Steen Hegelund <steen.hegelund@microchip.com> Signed-off-by:
Bjarni Jonasson <bjarni.jonasson@microchip.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Reviewed-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Steen Hegelund authored
Add support for 25gbase-r modules. This is needed for the Sparx5 switch. Signed-off-by:
-
Steen Hegelund authored
Add 25gbase-r phy interface mode Signed-off-by:
-
Steen Hegelund authored
Add 25gbase-r PHY interface mode. Signed-off-by:
-
David S. Miller authored
Julian Wiedmann says: ==================== s390/iucv: updates 2021-06-11 please apply the following iucv patches to netdev's net-next tree. This cleans up a pattern of forward declarations in two iucv drivers, so that they stop causing compile warnings with gcc11. ==================== Signed-off-by: -
Heiko Carstens authored
Move netiucv_handler to get rid of forward declarations and gcc11 compile warnings: drivers/s390/net/netiucv.c:518:65: warning: argument 2 of type ‘u8[16]’ {aka ‘unsigned char[16]’} with mismatched bound [-Warray-parameter=] 518 | static void netiucv_callback_connack(struct iucv_path *path, u8 ipuser[16]) | ~~~^~~~~~~~~~ drivers/s390/net/netiucv.c:122:58: note: previously declared as ‘u8 *’ {aka ‘unsigned char *’} 122 | static void netiucv_callback_connack(struct iucv_path *, u8 *); Signed-off-by:Heiko Carstens <hca@linux.ibm.com> Signed-off-by:
Julian Wiedmann <jwi@linux.ibm.com> Signed-off-by:
-
Julian Wiedmann authored
The forward declarations for the iucv_handler callbacks are causing various compile warnings with gcc-11. Reshuffle the code to get rid of these prototypes. Reported-by:
Sven Schnelle <svens@linux.ibm.com> Signed-off-by:
-
- 11 Jun, 2021 13 commits
-
-
David S. Miller authored
Alex Elder says: ==================== net: ipa: introduce ipa_syfs.c This series (its last patch, actually) creates a new source file, "ipa_syfs.c", to contain functions and data that expose to user space information known by the IPA driver via device attributes. The directory containing these files on supported systems is: /sys/devices/platform/soc@0/1e40000.ipa And within that direcftory, the following files and directories are added: . |-- feature | |-- rx_offload Type of checksum offload supported | `-- tx_offload | . . . |-- modem | |-- rx_endpoint_id IPA endpoint IDs for the embedded modem | `-- tx_endpoint_id | . . . |-- version IPA hardware version (informational) . . . The first patch just makes endpoint validation unconditional, as suggested by Leon Romanovsky. The second just ensures the version defined in configuration data is valid, so the version attribute doesn't have to handle unrecognized version numbers. ==================== Signed-off-by: -
Alex Elder authored
Add IPA device attributes to expose information known by the IPA driver about the hardware and its configuration. All pointers used to display these attribute values (i.e., IPA pointer and endpoint pointers) will have been initialized by the time IPA probe has completed, so they may be safely dereferenced. Signed-off-by:
-
Alex Elder authored
Define and use a new function that just validates the version defined in configuration data. Signed-off-by:
-
Alex Elder authored
The cost of validating the endpoint configuration data is not all that high, so just do it unconditionally, rather than doing so only when IPA_VALIDATAION is defined. Suggested-by:
Leon Romanovsky <leon@kernel.org> Signed-off-by:
-
Lijun Pan authored
drivers/net/ethernet/ibm/ibmvnic.c: In function ‘handle_vpd_rsp’: drivers/net/ethernet/ibm/ibmvnic.c:4393:3: warning: ‘strncpy’ output truncated before terminating nul copying 3 bytes from a string of the same length [-Wstringop-truncation] 4393 | strncpy((char *)adapter->fw_version, "N/A", 3 * sizeof(char)); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Signed-off-by: -
David S. Miller authored
Vladimir Oltean says: ==================== Port the SJA1105 DSA driver to XPCS As requested when adding support for the NXP SJA1110, the SJA1105 driver could make use of the common XPCS driver, to eliminate some hardware specific code duplication. This series modifies the XPCS driver so that it can accommodate the XPCS instantiation from NXP switches, and the SJA1105 driver so it can expose what the XPCS driver expects. Tested on NXP SJA1105S and SJA1110A. Changes in v3: None. This is a resend of v2 which had "changes requested" even though there was no direct feedback. ==================== Signed-off-by: -
Vladimir Oltean authored
The MAC treats 2500base-x same as SGMII (yay for that) except that it must be set to a different speed. Extend all places that check for SGMII to also check for 2500base-x. Also add the missing 2500base-x compatibility matrix entry for SJA1110D. Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
-
Vladimir Oltean authored
For the xMII Mode Parameters Table to be properly configured for SGMII mode on SJA1110, we need to set the "special" bit, since SGMII is officially bitwise coded as 0b0011 in SJA1105 (decimal 3, equal to XMII_MODE_SGMII), and as 0b1011 in SJA1110 (decimal 11). Signed-off-by:
-
Vladimir Oltean authored
On the SJA1110, the PCS of each SERDES-capable port is accessed through a different memory window which is 0x100 bytes in size, denoted by "pcs_base". In each PCS register access window, the XPCS MMDs are accessed in an indirect way: in pages/banks of up to 0x100 addresses each. Changing the page/bank is done by writing to a special register at the end of the access window. The MDIO register map accessed indirectly through the indirect banked method described above is similar to what SJA1105 has: upper 5 bits are the MMD, lower 16 bits are the MDIO address within that MMD. Since the PHY ID reported by the XPCS inside SJA1110 is also all zeroes (like SJA1105), we need to trap those reads and return a fake PHY ID so that the xpcs driver can apply some specific fixups for our integration. Signed-off-by:
-
Vladimir Oltean authored
There is a desire to use the generic driver for the Synopsys XPCS located in drivers/net/pcs, and to achieve that, the sja1105 driver must expose an MDIO bus for the SGMII PCS, because the XPCS probes as an mdio_device. In preparation of the SJA1110 which in fact has a different access procedure for the SJA1105, we register this PCS MDIO bus once in the common code, but we implement function pointers for the read and write methods. In this patch there is a single implementation for them. There is exactly one MDIO bus for the PCS, this will contain all PCSes at MDIO addresses equal to the port number. We delete a bunch of hardware support code because the xpcs driver already does what we need. We need to hack up the MDIO reads for the PHY ID, since our XPCS instantiation returns zeroes and there are some specific fixups which need to be applied by the xpcs driver. Signed-off-by:
-
Vladimir Oltean authored
The sja1105 hardware has a quirk in that some changes require a switch reset, which loses all configuration. When the reset is initiated, everything needs to be reprogrammed, including the MACs and the PCS. This is currently done in sja1105_static_config_reload() - we manually call sja1105_adjust_port_config(), sja1105_sgmii_pcs_config() and sja1105_sgmii_pcs_force_speed() which are all internal functions. There is a desire for sja1105 to use the common xpcs driver, and that means that the equivalents of those functions, xpcs_do_config() and xpcs_link_up() respectively, will no longer be local functions. Forcing phylink to retrigger a resolve somehow, say by doing dev_close() followed by dev_open() is not really an option, because the CPU port might have a PCS as well, and there is no net device which we can close and reopen for that. Additionally, the dev_close/dev_open sequence might force a renegotiation of the copper-side link for SGMII ports connected to a PHY, and this is undesirable as well, because the switch reset is much quicker than a PHY autoneg, so we would have a lot more downtime. The only solution I see is for the sja1105 driver to keep doing what it's doing, and that means we need to export the equivalents from xpcs for sja1105_sgmii_pcs_config and sja1105_sgmii_pcs_force_speed, and call them directly in sja1105_static_config_reload(). This will be done during the conversion patch. Signed-off-by:
-
Vladimir Oltean authored
The NXP SJA1110 switch integrates its own, non-Synopsys PMA, but it manages it through the register space of the XPCS itself, in a small register window inside MDIO_MMD_VEND2 from address 0x8030 to 0x806e. This coincides with where the registers for the default Synopsys PMA are, but the register definitions are of course not the same. This situation is an odd hardware quirk, but the simplest way to manage it is to drive the SJA1110's PMA from within the XPCS driver. Signed-off-by:
-
Vladimir Oltean authored
The NXP SJA1105 DSA switch integrates a Synopsys SGMII XPCS on port 4. The generic code works fine, except there is an integration issue which needs to be dealt with: in this switch, the XPCS is integrated with a PMA that has the TX lane polarity inverted by default (PLUS is MINUS, MINUS is PLUS). To obtain normal non-inverted behavior, the TX lane polarity must be inverted in the PCS, via the DIGITAL_CONTROL_2 register. We introduce a pma_config() method in xpcs_compat which is called by the phylink_pcs_config() implementation. Also, the NXP SJA1105 returns all zeroes in the PHY ID registers 2 and 3. We need to hack up an ad-hoc PHY ID (OUI is zero, device ID is 1) in order for the XPCS driver to recognize it. This PHY ID is added to the public include/linux/pcs/pcs-xpcs.h for that reason (for the sja1105 driver to be able to use it in a later patch). Signed-off-by:
-
