- 12 Jun, 2021 16 commits
-
-
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:
Loic Poulain <loic.poulain@linaro.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
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 24 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 <elder@linaro.org> 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:
-
Vladimir Oltean authored
xpcs_get_id() searches multiple MMDs for a known PHY ID, starting with MDIO_MMD_PCS (3). However not all integrators might have implemented that MMD on their MDIO bus. For example, the NXP SJA1105 and SJA1110 switches only implement vendor-specific MMD 1 and 2. When there is nothing on an MDIO bus at a certain address, traditionally the bus returns 0xffff, which means that the bus remained in its default pull-up state for the duration of the MDIO transaction. The 0xffff value is widely used in drivers/net/phy/phy_device.c (see get_phy_c22_id for example) to denote a missing device. So it makes sense for the xpcs to ignore this value as well, and continue its search, eventually finding the proper PHY ID in the vendor-specific MMDs. Signed-off-by:
-
Vladimir Oltean authored
In fixed-link use cases, the XPCS can disable the clause 37 in-band autoneg process, disable the "Automatic Speed Mode Change after CL37 AN" setting, and force operation in a speed dictated by management. Add support for this operating mode. Signed-off-by:
-
Vladimir Oltean authored
Vendors which integrate the Designware XPCS might modify a few things here and there, and to support those, it's best to create separate C files in order to not clutter up the main pcs-xpcs.c. Because the vendor files might want to access the common xpcs registers too, let's move them in a header file which is local to this driver and can be included by vendor files as appropriate. Signed-off-by:
-
Vladimir Oltean authored
There is no reason to embed an if within an if, we can just logically AND the two conditions. Signed-off-by:
-
Vladimir Oltean authored
Reorder the variable declarations in descending line length order, according to the networking coding style. Signed-off-by:
-
Vladimir Oltean authored
The struct mdio_xpcs_args is reminiscent of when a similarly named struct mdio_xpcs_ops existed. Now that that is removed, we can shorten the name to dw_xpcs (dw for DesignWare). Signed-off-by:
-
David S. Miller authored
Alex Elder says: ==================== net: qualcomm: rmnet: MAPv4 download checksum cleanup, part 1 I'm posting a large series an two smaller parts; this is part 1. The RMNet driver handles MAP (or QMAP) protocol traffic. There are several versions of this protocol. Version 1 supports multiplexing, as well as aggregation of packets in a single buffer. Version 4 adds the ability to perform checksum offload. And version 5 implements checksum offload in a different way from version 4. This series involves only MAPv4 protocol checksum offload, and only in the download (RX) direction. It affects handling of checksums computed by hardware for UDP datagrams and TCP segments, carried over both IPv4 and IPv6. MAP packets arriving on an RMNet port implementing MAPv4 checksum offload are passed to rmnet_map_checksum_downlink_packet() for handling. The packet is then passed to rmnet_map_ipv4_dl_csum_trailer() or rmnet_map_ipv6_dl_csum_trailer(), depending contents of the MAP payload. These two functions interpret checksum metadata to determine whether the checksum in the received packet matches that calculated by the hardware. It is these two functions that are the subject of this series (parts 1 and 2). The bulk of these functions are transformed--in a lot of small steps--from an extremely difficult-to-follow block of checksum processing code into a fairly simple, heavily commented equivalent. ==================== Signed-off-by: -
Alex Elder authored
In the previous patch IPv4 download checksum offload code was updated to avoid unnecessary byte swapping, based on properties of the Internet checksum algorithm. This patch makes comparable changes to the IPv6 download checksum offload handling. Signed-off-by:
-
Alex Elder authored
Internet checksums are used for IPv4 header checksum, as well as TCP segment and UDP datagram checksums. Such a checksum represents the negated sum of adjacent pairs of bytes, using ones' complement arithmetic. One property of the Internet checkum is byte order independence [1]. Specifically, the sum of byte-swapped pairs is equal to the result of byte swapping the sum of those same pairs when not byte-swapped. So for example if a, b, c, d, y, and z are hexadecimal digits, and PLUS represents ones' complement addition: If: ab PLUS cd = yz Then: ba PLUS dc = zy For this reason, there is no need to swap the order of bytes in the checksum value held in a message header, nor the one in the QMAPv4 trailer, in order to operate on them. In other words, we can determine whether the hardware-computed checksum matches the one in the message header without any byte swaps. (This patch leaves in place all existing type casts.) [1] https://tools.ietf.org/html/rfc1071Signed-off-by: -
Alex Elder authored
In rmnet_map_ipv6_dl_csum_trailer() there is an especially involved line of code that determines the ones' complement sum of the IPv6 packet header (in host byte order). Simplify that by storing the result of computing just the header checksum in a local variable, then using that in the original assignment. Use the size of the IPv6 header structure as the number of bytes to checksum, rather than computing the offset to the transport header. And use ip_fast_csum() rather than ipa_compute_csum(), knowing that the size of an IPv6 header (40 bytes) is a multiple of 4 bytes greater than 16. Add some comments to match rmnet_map_ipv4_dl_csum_trailer(). Signed-off-by:
-
Alex Elder authored
In rmnet_map_ipv4_dl_csum_trailer(), an illegal checksum subtraction is done, subtracting hdr_csum (in host byte order) from csum_value (in network byte order). Despite being illegal, it generally works, because it turns out the value subtracted is (or should be) always 0, which has the same representation in either byte order. Doing illegal operations is not good form though, so fix this by verifying the IP header checksum early in that function. If its checksum is non-zero, the packet will be bad, so just return an error. This will cause the packet to passed to the IP layer where it can be dropped. Thereafter, there is no need subtract the IP header checksum from the checksum value in the trailer because we know it is zero. Add a comment explaining this. This type of packet error is different from other types, so add a new statistics counter to track this condition. Signed-off-by:
-
