aboutsummaryrefslogtreecommitdiffstats
path: root/drivers (follow)
AgeCommit message (Collapse)AuthorFilesLines
2022-02-23mlxsw: core: Add support for OSFP transceiver modulesDanielle Ratson2-0/+3
The driver can already dump the EEPROM contents of QSFP-DD transceiver modules via its ethtool_ops::get_module_info() and ethtool_ops::get_module_eeprom() callbacks. Add support for OSFP transceiver modules by adding their SFF-8024 Identifier Value (0x19). This is required for future NVIDIA Spectrum-4 based systems that will be equipped with OSFP transceivers. Signed-off-by: Danielle Ratson <danieller@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-23mlxsw: Remove resource query checkIdo Schimmel4-12/+2
Since SwitchX-2 support was removed in commit b0d80c013b04 ("mlxsw: Remove Mellanox SwitchX-2 ASIC support"), all the ASICs supported by mlxsw support the resource query command. Therefore, remove the resource query check and always query resources from the device. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-23mlxsw: core: Unify method of trap support validationVadim Pasternak4-31/+2
Currently there are several different features defined in 'mlxsw_driver' for trap support validation. There is no reason to have dedicated features for specific traps. Perform validation of all of them by testing feature 'MLXSW_BUS_F_TXRX'. Remove trap capability validation from 'core_env.c' which is redundant after validation has been added to mlxsw_core_trap_register(). Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-23mlxsw: spectrum: Remove SP{1,2,3} defines for FW minor and subminorJiri Pirko1-18/+15
The FW minor and subminor versions are the same for all generations of Spectrum ASICs. Unify them into a single set of defines. Signed-off-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-23mlxsw: core: Remove unnecessary assertsVadim Pasternak1-24/+0
Remove unnecessary asserts for module index validation. Leave only one that is actually necessary in mlxsw_env_pmpe_listener_func() where the module index is directly read from the firmware event. Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-23mlxsw: reg: Add "mgpir_" prefix to MGPIR fields commentsVadim Pasternak1-4/+4
Do the same as for other registers and have "mgpir_" prefix for the MGPIR fields. Signed-off-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-23mlxsw: core_thermal: Remove obsolete API for query resourceVadim Pasternak4-23/+0
Remove obsolete API mlxsw_core_res_query_enabled(), which is only relevant for end-of-life SwitchX-2 ASICs. Support for these ASICs was removed in commit b0d80c013b04 ("mlxsw: Remove Mellanox SwitchX-2 ASIC support"). Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-23mlxsw: core_thermal: Rename labels according to naming conventionVadim Pasternak1-20/+23
Rename labels for error flow handling in order to align with naming convention used in rest of 'mlxsw' code. Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-23mlxsw: core_hwmon: Fix variable names for hwmon attributesVadim Pasternak1-38/+38
Replace all local variables 'mlwsw_hwmon_attr' by 'mlxsw_hwmon_attr'. All variable prefixes should start with 'mlxsw' according to the naming convention, so 'mlwsw' is changed to 'mlxsw'. Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-23mlxsw: core_thermal: Avoid creation of virtual hwmon objects by thermal moduleVadim Pasternak1-3/+8
The driver registers with both the hwmon and thermal subsystems. Therefore, there is no need for the thermal subsystem to automatically create hwmon entries upon registration of a thermal zone, as this results in duplicate information. Avoid creation of virtual hwmon objects by thermal subsystem by registering a thermal zone with 'no_hwmon' set to 'true'. Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-23mlxsw: spectrum_span: Ignore VLAN entries not used by the bridge in mirroringIdo Schimmel1-1/+2
Only VLAN entries installed on the bridge device itself should be considered when checking whether a packet with a specific VLAN can be mirrored via a bridge device. VLAN entries only used to keep context (i.e., entries with 'BRIDGE_VLAN_INFO_BRENTRY' unset) should be ignored. Fix this by preventing mirroring when the VLAN entry does not have the 'BRIDGE_VLAN_INFO_BRENTRY' flag set. Fixes: ddaff5047003 ("mlxsw: spectrum: remove guards against !BRIDGE_VLAN_INFO_BRENTRY") Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-23mlxsw: core: Prevent trap group setting if driver does not support EMADVadim Pasternak1-0/+9
Avoid trap group setting if driver is not capable of EMAD support. For example, "mlxsw_minimal" driver works over I2C bus, overs which EMADs cannot be sent. Validation is performed by testing feature 'MLXSW_BUS_F_TXRX'. Fixes: 74e0494d35ac ("mlxsw: core: Move basic_trap_groups_set() call out of EMAD init code") Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-23net: dsa: realtek: rtl8365mb: serialize indirect PHY register accessAlvin Šipraga1-21/+33
Realtek switches in the rtl8365mb family can access the PHY registers of the internal PHYs via the switch registers. This method is called indirect access. At a high level, the indirect PHY register access method involves reading and writing some special switch registers in a particular sequence. This works for both SMI and MDIO connected switches. Currently the rtl8365mb driver does not take any care to serialize the aforementioned access to the switch registers. In particular, it is permitted for other driver code to access other switch registers while the indirect PHY register access is ongoing. Locking is only done at the regmap level. This, however, is a bug: concurrent register access, even to unrelated switch registers, risks corrupting the PHY register value read back via the indirect access method described above. Arınç reported that the switch sometimes returns nonsense data when reading the PHY registers. In particular, a value of 0 causes the kernel's PHY subsystem to think that the link is down, but since most reads return correct data, the link then flip-flops between up and down over a period of time. The aforementioned bug can be readily observed by: 1. Enabling ftrace events for regmap and mdio 2. Polling BSMR PHY register for a connected port; it should always read the same (e.g. 0x79ed) 3. Wait for step 2 to give a different value Example command for step 2: while true; do phytool read swp2/2/0x01; done On my i.MX8MM, the above steps will yield a bogus value for the BSMR PHY register within a matter of seconds. The interleaved register access it then evident in the trace log: kworker/3:4-70 [003] ....... 1927.139849: regmap_reg_write: ethernet-switch reg=1004 val=bd phytool-16816 [002] ....... 1927.139979: regmap_reg_read: ethernet-switch reg=1f01 val=0 kworker/3:4-70 [003] ....... 1927.140381: regmap_reg_read: ethernet-switch reg=1005 val=0 phytool-16816 [002] ....... 1927.140468: regmap_reg_read: ethernet-switch reg=1d15 val=a69 kworker/3:4-70 [003] ....... 1927.140864: regmap_reg_read: ethernet-switch reg=1003 val=0 phytool-16816 [002] ....... 1927.140955: regmap_reg_write: ethernet-switch reg=1f02 val=2041 kworker/3:4-70 [003] ....... 1927.141390: regmap_reg_read: ethernet-switch reg=1002 val=0 phytool-16816 [002] ....... 1927.141479: regmap_reg_write: ethernet-switch reg=1f00 val=1 kworker/3:4-70 [003] ....... 1927.142311: regmap_reg_write: ethernet-switch reg=1004 val=be phytool-16816 [002] ....... 1927.142410: regmap_reg_read: ethernet-switch reg=1f01 val=0 kworker/3:4-70 [003] ....... 1927.142534: regmap_reg_read: ethernet-switch reg=1005 val=0 phytool-16816 [002] ....... 1927.142618: regmap_reg_read: ethernet-switch reg=1f04 val=0 phytool-16816 [002] ....... 1927.142641: mdio_access: SMI-0 read phy:0x02 reg:0x01 val:0x0000 <- ?! kworker/3:4-70 [003] ....... 1927.143037: regmap_reg_read: ethernet-switch reg=1001 val=0 kworker/3:4-70 [003] ....... 1927.143133: regmap_reg_read: ethernet-switch reg=1000 val=2d89 kworker/3:4-70 [003] ....... 1927.143213: regmap_reg_write: ethernet-switch reg=1004 val=be kworker/3:4-70 [003] ....... 1927.143291: regmap_reg_read: ethernet-switch reg=1005 val=0 kworker/3:4-70 [003] ....... 1927.143368: regmap_reg_read: ethernet-switch reg=1003 val=0 kworker/3:4-70 [003] ....... 1927.143443: regmap_reg_read: ethernet-switch reg=1002 val=6 The kworker here is polling MIB counters for stats, as evidenced by the register 0x1004 that we are writing to (RTL8365MB_MIB_ADDRESS_REG). This polling is performed every 3 seconds, but is just one example of such unsynchronized access. In Arınç's case, the driver was not using the switch IRQ, so the PHY subsystem was itself doing polling analogous to phytool in the above example. A test module was created [see second Link] to simulate such spurious switch register accesses while performing indirect PHY register reads and writes. Realtek was also consulted to confirm whether this is a known issue or not. The conclusion of these lines of inquiry is as follows: 1. Reading of PHY registers via indirect access will be aborted if, after executing the read operation (via a write to the INDIRECT_ACCESS_CTRL_REG), any register is accessed, other than INDIRECT_ACCESS_STATUS_REG. 2. The PHY register indirect read is only complete when INDIRECT_ACCESS_STATUS_REG reads zero. 3. The INDIRECT_ACCESS_DATA_REG, which is read to get the result of the PHY read, will contain the result of the last successful read operation. If there was spurious register access and the indirect read was aborted, then this register is not guaranteed to hold anything meaningful and the PHY read will silently fail. 4. PHY writes do not appear to be affected by this mechanism. 5. Other similar access routines, such as for MIB counters, although similar to the PHY indirect access method, are actually table access. Table access is not affected by spurious reads or writes of other registers. However, concurrent table access is not allowed. Currently this is protected via mib_lock, so there is nothing to fix. The above statements are corroborated both via the test module and through consultation with Realtek. In particular, Realtek states that this is simply a property of the hardware design and is not a hardware bug. To fix this problem, one must guard against regmap access while the PHY indirect register read is executing. Fix this by using the newly introduced "nolock" regmap in all PHY-related functions, and by aquiring the regmap mutex at the top level of the PHY register access callbacks. Although no issue has been observed with PHY register _writes_, this change also serializes the indirect access method there. This is done purely as a matter of convenience and for reasons of symmetry. Fixes: 4af2950c50c8 ("net: dsa: realtek-smi: add rtl8365mb subdriver for RTL8365MB-VC") Link: https://lore.kernel.org/netdev/CAJq09z5FCgG-+jVT7uxh1a-0CiiFsoKoHYsAWJtiKwv7LXKofQ@mail.gmail.com/ Link: https://lore.kernel.org/netdev/871qzwjmtv.fsf@bang-olufsen.dk/ Reported-by: Arınç ÜNAL <arinc.unal@arinc9.com> Reported-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-23net: dsa: realtek: allow subdrivers to externally lock regmapAlvin Šipraga3-5/+91
Currently there is no way for Realtek DSA subdrivers to serialize consecutive regmap accesses. In preparation for a bugfix relating to indirect PHY register access - which involves a series of regmap reads and writes - add a facility for subdrivers to serialize their regmap access. Specifically, a mutex is added to the driver private data structure and the standard regmap is initialized with custom lock/unlock ops which use this mutex. Then, a "nolock" variant of the regmap is added, which is functionally equivalent to the existing regmap except that regmap locking is disabled. Functions that wish to serialize a sequence of regmap accesses may then lock the newly introduced driver-owned mutex before using the nolock regmap. Doing things this way means that subdriver code that doesn't care about serialized register access - i.e. the vast majority of code - needn't worry about synchronizing register access with an external lock: it can just continue to use the original regmap. Another advantage of this design is that, while regmaps with locking disabled do not expose a debugfs interface for obvious reasons, there still exists the original regmap which does expose this interface. This interface remains safe to use even combined with driver codepaths that use the nolock regmap, because said codepaths will use the same mutex to synchronize access. With respect to disadvantages, it can be argued that having near-duplicate regmaps is confusing. However, the naming is rather explicit, and examples will abound. Finally, while we are at it, rename realtek_smi_mdio_regmap_config to realtek_smi_regmap_config. This makes it consistent with the naming realtek_mdio_regmap_config in realtek-mdio.c. Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-22ionic: use vmalloc includeShannon Nelson1-0/+1
The ever-vigilant Linux kernel test robot reminded us that we need to use the correct include files to be sure that all the build variations will work correctly. Adding the vmalloc.h include takes care of declaring our use of vzalloc() and vfree(). drivers/net/ethernet/pensando/ionic/ionic_lif.c:396:17: error: implicit declaration of function 'vfree'; did you mean 'kvfree'? drivers/net/ethernet/pensando/ionic/ionic_lif.c:531:21: warning: assignment to 'struct ionic_desc_info *' from 'int' makes pointer from integer without a cast Fixes: 116dce0ff047 ("ionic: Use vzalloc for large per-queue related buffers") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Shannon Nelson <snelson@pensando.io> Link: https://lore.kernel.org/r/20220223015731.22025-1-snelson@pensando.io Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-02-22usbnet: gl620a: Replace one-element array with flexible-array memberGustavo A. R. Silva1-1/+1
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. This helps with the ongoing efforts to globally enable -Warray-bounds and get us closer to being able to tighten the FORTIFY_SOURCE routines on memcpy(). This issue was found with the help of Coccinelle and audited and fixed, manually. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.16/process/deprecated.html#zero-length-and-one-element-arrays Link: https://github.com/KSPP/linux/issues/79 Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://lore.kernel.org/r/20220221173415.GA1149599@embeddedor Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-02-22net: phy: phylink: fix DSA mac_select_pcs() introductionRussell King (Oracle)1-3/+11
Vladimir Oltean reports that probing on DSA drivers that aren't yet populating supported_interfaces now fails. Fix this by allowing phylink to detect whether DSA actually provides an underlying mac_select_pcs() implementation. Reported-by: Vladimir Oltean <olteanv@gmail.com> Fixes: bde018222c6b ("net: dsa: add support for phylink mac_select_pcs()") Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Tested-by: Vladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/E1nMCD6-00A0wC-FG@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-02-22net: dsa: microchip: ksz9477: reduce polling interval for statisticsOleksij Rempel1-1/+1
30 seconds is too long interval especially if it used with ip -s l. Reduce polling interval to 5 sec. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Link: https://lore.kernel.org/r/20220221084129.3660124-1-o.rempel@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-02-22s390/net: sort out physical vs virtual pointers usageAlexander Gordeev2-5/+5
Fix virtual vs physical address confusion (which currently are the same). Reviewed-by: Alexandra Winter <wintera@linux.ibm.com> Reviewed-by: Wenjia Zhang <wenjia@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Alexandra Winter <wintera@linux.ibm.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-02-22net: dsa: b53: mark as non-legacyRussell King (Oracle)1-0/+6
The B53 driver does not make use of the speed, duplex, pause or advertisement in its phylink_mac_config() implementation, so it can be marked as a non-legacy driver. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-22net: dsa: b53: switch to using phylink_generic_validate()Russell King (Oracle)5-76/+13
Switch the Broadcom b53 driver to using the phylink_generic_validate() implementation by removing its own .phylink_validate method and associated code. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-22net: dsa: b53: drop use of phylink_helper_basex_speed()Russell King (Oracle)1-2/+0
Now that we have a better method to select SFP interface modes, we no longer need to use phylink_helper_basex_speed() in a driver's validation function. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-22net: dsa: b53: populate supported_interfaces and mac_capabilitiesRussell King (Oracle)5-0/+95
Populate the supported interfaces and MAC capabilities for the Broadcom B53 DSA switches in preparation to using these for the generic validation functionality. The interface modes are derived from: - b53_serdes_phylink_validate() - SRAB mux configuration Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-22net: dsa: b53: clean up if() condition to be more readableRussell King (Oracle)1-4/+7
I've stared at this if() statement for a while trying to work out if it really does correspond with the comment above, and it does seem to. However, let's make it more readable and phrase it in the same way as the comment. Also add a FIXME into the comment - we appear to deny Gigabit modes for 802.3z interface modes, but 802.3z interface modes only operate at gigabit and above. Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-21net: dm9051: Fix use after free in dm9051_loop_tx()Dan Carpenter1-1/+3
This code dereferences "skb" after calling dev_kfree_skb(). Fixes: 2dc95a4d30ed ("net: Add dm9051 driver") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20220221105440.GA10045@kili Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-02-21octeontx2-af: cn10k: add workaround for ptp errataNaveen Mamindlapalli1-7/+80
This patch adds workaround for PTP errata given below. 1. At the time of 1 sec rollover of nano-second counter, the nano-second counter is set to 0. However, it should be set to (existing counter_value - 10^9). This leads to an accumulating error in the timestamp value with each sec rollover. 2. Additionally, the nano-second counter currently is rolling over at 'h3B9A_C9FF. It should roll over at 'h3B9A_CA00. The workaround for issue #1 is to speed up the ptp clock by adjusting PTP_CLOCK_COMP register to the desired value to compensate for the nanoseconds lost per each second. The workaround for issue #2 is to slow down the ptp clock such that the rollover occurs at ~1sec. Signed-off-by: Naveen Mamindlapalli <naveenm@marvell.com> Signed-off-by: Sunil Kovvuri Goutham <sgoutham@marvell.com> Signed-off-by: Rakesh Babu Saladi <rsaladi2@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-21octeontx2-pf: cn10k: add support for new ptp timestamp formatNaveen Mamindlapalli6-3/+75
The cn10k hardware ptp timestamp format has been modified primarily to support 1-step ptp clock. The 64-bit timestamp used by hardware is split into two 32-bit fields, the upper one holds seconds, the lower one nanoseconds. A new register (PTP_CLOCK_SEC) has been added that returns the current seconds value. The nanoseconds register PTP_CLOCK_HI resets after every second. The cn10k RPM block provides Rx/Tx timestamps to the NIX block using the new timestamp format. The software can read the current timestamp in nanoseconds by reading both PTP_CLOCK_SEC & PTP_CLOCK_HI registers. This patch provides support for new timestamp format. Signed-off-by: Naveen Mamindlapalli <naveenm@marvell.com> Signed-off-by: Sunil Kovvuri Goutham <sgoutham@marvell.com> Signed-off-by: Rakesh Babu Saladi <rsaladi2@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-21bonding: add new option ns_ip6_targetHangbin Liu2-0/+131
This patch add a new bonding option ns_ip6_target, which correspond to the arp_ip_target. With this we set IPv6 targets and send IPv6 NS request to determine the health of the link. For other related options like the validation, we still use arp_validate, and will change to ns_validate later. Note: the sysfs configuration support was removed based on https://lore.kernel.org/netdev/8863.1645071997@famine Signed-off-by: Hangbin Liu <liuhangbin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-21bonding: add new parameter ns_targetsHangbin Liu2-20/+219
Add a new bonding parameter ns_targets to store IPv6 address. Add required bond_ns_send/rcv functions first before adding IPv6 address option setting. Add two functions bond_send/rcv_validate so we can send/recv ARP and NS at the same time. Signed-off-by: Hangbin Liu <liuhangbin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-21Bonding: split bond_handle_vlan from bond_arp_sendHangbin Liu1-24/+34
Function bond_handle_vlan() is split from bond_arp_send() for later IPv6 usage. Signed-off-by: Hangbin Liu <liuhangbin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-21ravb: Use GFP_KERNEL instead of GFP_ATOMIC when possibleChristophe JAILLET1-1/+1
'max_rx_len' can be up to GBETH_RX_BUFF_MAX (i.e. 8192) (see 'gbeth_hw_info'). The default value of 'num_rx_ring' can be BE_RX_RING_SIZE (i.e. 1024). So this loop can allocate 8 Mo of memory. Previous memory allocations in this function already use GFP_KERNEL, so use __netdev_alloc_skb() and an explicit GFP_KERNEL instead of a implicit GFP_ATOMIC. This gives more opportunities of successful allocation. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Sergey Shtylyov <s.shtylyov@omp.ru> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-21net: qualcomm: rmnet: Use skb_put_zero() to simplify codeChristophe JAILLET1-3/+1
Use skb_put_zero() instead of hand-writing it. This saves a few lines of code and is more readable. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-19net: prestera: acl: fix 'client_map' buff overflowVolodymyr Mytnyk1-1/+1
smatch warnings: drivers/net/ethernet/marvell/prestera/prestera_acl.c:103 prestera_acl_chain_to_client() error: buffer overflow 'client_map' 3 <= 3 prestera_acl_chain_to_client(u32 chain_index, ...) ... u32 client_map[] = { PRESTERA_HW_COUNTER_CLIENT_LOOKUP_0, PRESTERA_HW_COUNTER_CLIENT_LOOKUP_1, PRESTERA_HW_COUNTER_CLIENT_LOOKUP_2 }; if (chain_index > ARRAY_SIZE(client_map)) ... Fixes: fa5d824ce5dd ("net: prestera: acl: add multi-chain support offload") Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Volodymyr Mytnyk <vmytnyk@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-19net: dsa: microchip: add ksz8563 to ksz9477 I2C driverAhmad Fatoum1-0/+1
The KSZ9477 SPI driver already has support for the KSZ8563. The same switch chip can also be managed via i2c and we have an KSZ9477 I2C driver, but that one lacks the relevant compatible entry. Add it. DT bindings already describe this compatible. Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-19net: dsa: microchip: ksz9477: export HW stats over stats64 interfaceOleksij Rempel3-0/+104
Provide access to HW offloaded packets over stats64 interface. The rx/tx_bytes values needed some fixing since HW is accounting size of the Ethernet frame together with FCS. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-19net: phylink: remove phylink_config's pcs_pollRussell King (Oracle)1-2/+1
phylink_config's pcs_poll is no longer used, let's get rid of it. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-19atm: nicstar: Use kcalloc() to simplify codeChristophe JAILLET1-8/+2
Use kcalloc() instead of kmalloc_array() and a loop to set all the values of the array to NULL. While at it, remove a duplicated assignment to 'scq->num_entries'. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-19dpaa2-eth: Update SINGLE_STEP register accessRadu Bulie2-10/+93
DPAA2 MAC supports 1588 one step timestamping. If this option is enabled then for each transmitted PTP event packet, the 1588 SINGLE_STEP register is accessed to modify the following fields: -offset of the correction field inside the PTP packet -UDP checksum update bit, in case the PTP event packet has UDP encapsulation These values can change any time, because there may be multiple PTP clients connected, that receive various 1588 frame types: - L2 only frame - UDP / Ipv4 - UDP / Ipv6 - other The current implementation uses dpni_set_single_step_cfg to update the SINLGE_STEP register. Using an MC command on the Tx datapath for each transmitted 1588 message introduces high delays, leading to low throughput and consequently to a small number of supported PTP clients. Besides these, the nanosecond correction field from the PTP packet will contain the high delay from the driver which together with the originTimestamp will render timestamp values that are unacceptable in a GM clock implementation. This patch updates the Tx datapath for 1588 messages when single step timestamp is enabled and provides direct access to SINGLE_STEP register, eliminating the overhead caused by the dpni_set_single_step_cfg MC command. MC version >= 10.32 implements this functionality. If the MC version does not have support for returning the single step register base address, the driver will use dpni_set_single_step_cfg command for updates operations. All the delay introduced by dpni_set_single_step_cfg function will be eliminated (if MC version has support for returning the base address of the single step register), improving the egress driver performance for PTP packets when single step timestamping is enabled. Before these changes the maximum throughput for 1588 messages with single step hardware timestamp enabled was around 2000pps. After the updates the throughput increased up to 32.82 Mbps / 46631.02 pps. Signed-off-by: Radu Bulie <radu-andrei.bulie@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-19dpaa2-eth: Update dpni_get_single_step_cfg commandRadu Bulie3-1/+13
dpni_get_single_step_cfg is an MC firmware command used for retrieving the contents of SINGLE_STEP 1588 register available in a DPMAC. This patch adds a new version of this command that returns as an extra argument the physical base address of the aforementioned register. The address will be used to directly modify the contents of the SINGLE_STEP register instead of invoking the MC command dpni_set_single_step_cgf. The former approach introduced huge delays on the TX datapath when one step PTP events were transmitted. This led to low throughput and high latencies observed in the PTP correction field. Signed-off-by: Radu Bulie <radu-andrei.bulie@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-19net: prestera: flower: fix destroy tmpl in chainVolodymyr Mytnyk1-9/+19
Fix flower destroy template callback to release template only for specific tc chain instead of all chain tempaltes. The issue was intruduced by previous commit that introduced multi-chain support. Fixes: fa5d824ce5dd ("net: prestera: acl: add multi-chain support offload") Signed-off-by: Volodymyr Mytnyk <vmytnyk@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-19mctp i2c: MCTP I2C binding driverMatt Johnston3-0/+1094
Provides MCTP network transport over an I2C bus, as specified in DMTF DSP0237. All messages between nodes are sent as SMBus Block Writes. Each I2C bus to be used for MCTP is flagged in devicetree by a 'mctp-controller' property on the bus node. Each flagged bus gets a mctpi2cX net device created based on the bus number. A 'mctp-i2c-controller' I2C client needs to be added under the adapter. In an I2C mux situation the mctp-i2c-controller node must be attached only to the root I2C bus. The I2C client will handle incoming I2C slave block write data for subordinate busses as well as its own bus. In configurations without devicetree a driver instance can be attached to a bus using the I2C slave new_device mechanism. The MCTP core will hold/release the MCTP I2C device while responses are pending (a 6 second timeout or once a socket is closed, response received etc). While held the MCTP I2C driver will lock the I2C bus so that the correct I2C mux remains selected while responses are received. (Ideally we would just lock the mux to keep the current bus selected for the response rather than a full I2C bus lock, but that isn't exposed in the I2C mux API) Signed-off-by: Matt Johnston <matt@codeconstruct.com.au> Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Reviewed-by: Wolfram Sang <wsa@kernel.org> # I2C transport parts Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-19i40e: remove dead stores on XSK hotpathAlexander Lobakin1-2/+1
The 'if (ntu == rx_ring->count)' block in i40e_alloc_rx_buffers_zc() was previously residing in the loop, but after introducing the batched interface it is used only to wrap-around the NTU descriptor, thus no more need to assign 'xdp'. 'cleaned_count' in i40e_clean_rx_irq_zc() was previously being incremented in the loop, but after commit f12738b6ec06 ("i40e: remove unnecessary cleaned_count updates") it gets assigned only once after it, so the initialization can be dropped. Fixes: 6aab0bb0c5cd ("i40e: Use the xsk batched rx allocation interface") Fixes: f12738b6ec06 ("i40e: remove unnecessary cleaned_count updates") Signed-off-by: Alexander Lobakin <alexandr.lobakin@intel.com> Acked-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Tested-by: George Kuruvinakunnel <george.kuruvinakunnel@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-18ionic: clean up comments and whitespaceShannon Nelson3-5/+3
Fix up some checkpatch complaints that have crept in: doubled words words, mispellled words, doubled lines. Signed-off-by: Shannon Nelson <snelson@pensando.io> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-02-18ionic: prefer strscpy over strlcpyShannon Nelson2-4/+4
Replace strlcpy with strscpy to clean up a checkpatch complaint. Signed-off-by: Shannon Nelson <snelson@pensando.io> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-02-18ionic: Use vzalloc for large per-queue related buffersBrett Creeley1-8/+6
Use vzalloc for per-queue info structs that don't need any DMA mapping to help relieve memory pressure found when used in our limited SOC environment. Signed-off-by: Brett Creeley <brett@pensando.io> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-02-18ionic: catch transition back to RUNNING with fw_generation 0Shannon Nelson1-2/+2
In some graceful updates that get initially triggered by the RESET event, especially with older firmware, the fw_generation bits don't change but the fw_status is seen to go to 0 then back to 1. However, the driver didn't perform the restart, remained waiting for fw_generation to change, and got left in limbo. This is because the clearing of idev->fw_status_ready to 0 didn't happen correctly as it was buried in the transition trigger: since the transition down was triggered not here but in the RESET event handler, the clear to 0 didn't happen, so the transition back to 1 wasn't detected. Fix this particular case by bringing the setting of idev->fw_status_ready back out to where it was before. Fixes: 398d1e37f960 ("ionic: add FW_STOPPING state") Signed-off-by: Shannon Nelson <snelson@pensando.io> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-02-18net/ibmvnic: Cleanup workaround doing an EOI after partition migrationCédric Le Goater1-9/+26
There were a fair amount of changes to workaround a firmware bug leaving a pending interrupt after migration of the ibmvnic device : commit 2df5c60e198c ("net/ibmvnic: Ignore H_FUNCTION return from H_EOI to tolerate XIVE mode") commit 284f87d2f387 ("Revert "net/ibmvnic: Fix EOI when running in XIVE mode"") commit 11d49ce9f794 ("net/ibmvnic: Fix EOI when running in XIVE mode.") commit f23e0643cd0b ("ibmvnic: Clear pending interrupt after device reset") Here is the final one taking into account the XIVE interrupt mode. Cc: Sukadev Bhattiprolu <sukadev@linux.ibm.com> Cc: Dany Madden <drt@linux.ibm.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-18teaming: deliver link-local packets with the link they arrive onjeffreyji1-0/+5
skb is ignored if team port is disabled. We want the skb to be delivered if it's an link layer packet. Issue is already fixed for bonding in commit b89f04c61efe ("bonding: deliver link-local packets with skb->dev set to link that packets arrived on") changelog: v2: change LLDP -> link layer in comments/commit descrip, comment format Signed-off-by: jeffreyji <jeffreyji@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-18net: dsa: qca8k: mark as non-legacyRussell King (Oracle)1-0/+2
The qca8k driver does not make use of the speed, duplex, pause or advertisement in its phylink_mac_config() implementation, so it can be marked as a non-legacy driver. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-18net: dsa: qca8k: move pcs configurationRussell King (Oracle)1-66/+84
Move the PCS configuration to qca8k_pcs_config(). Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.