- 27 Jan, 2021 12 commits
-
-
Praveen Chaudhary authored
For IPv4, default route is learned via DHCPv4 and user is allowed to change metric using config etc/network/interfaces. But for IPv6, default route can be learned via RA, for which, currently a fixed metric value 1024 is used. Ideally, user should be able to configure metric on default route for IPv6 similar to IPv4. This patch adds sysctl for the same. Logs: For IPv4: Config in etc/network/interfaces: auto eth0 iface eth0 inet dhcp metric 4261413864 IPv4 Kernel Route Table: $ ip route list default via 172.21.47.1 dev eth0 metric 4261413864 FRR Table, if a static route is configured: [In real scenario, it is useful to prefer BGP learned default route over DHCPv4 default route.] Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - IS-IS, B - BGP, P - PIM, E - EIGRP, N - NHRP, T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP, > - selected route, * - FIB route S>* 0.0.0.0/0 [20/0] is directly connected, eth0, 00:00:03 K 0.0.0.0/0 [254/1000] via 172.21.47.1, eth0, 6d08h51m i.e. User can prefer Default Router learned via Routing Protocol in IPv4. Similar behavior is not possible for IPv6, without this fix. After fix [for IPv6]: sudo sysctl -w net.ipv6.conf.eth0.net.ipv6.conf.eth0.ra_defrtr_metric=1996489705 IP monitor: [When IPv6 RA is received] default via fe80::xx16:xxxx:feb3:ce8e dev eth0 proto ra metric 1996489705 pref high Kernel IPv6 routing table $ ip -6 route list default via fe80::be16:65ff:feb3:ce8e dev eth0 proto ra metric 1996489705 expires 21sec hoplimit 64 pref high FRR Table, if a static route is configured: [In real scenario, it is useful to prefer BGP learned default route over IPv6 RA default route.] Codes: K - kernel route, C - connected, S - static, R - RIPng, O - OSPFv3, I - IS-IS, B - BGP, N - NHRP, T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP, > - selected route, * - FIB route S>* ::/0 [20/0] is directly connected, eth0, 00:00:06 K ::/0 [119/1001] via fe80::xx16:xxxx:feb3:ce8e, eth0, 6d07h43m If the metric is changed later, the effect will be seen only when next IPv6 RA is received, because the default route must be fully controlled by RA msg. Below metric is changed from 1996489705 to 1996489704. $ sudo sysctl -w net.ipv6.conf.eth0.ra_defrtr_metric=1996489704 net.ipv6.conf.eth0.ra_defrtr_metric = 1996489704 IP monitor: [On next IPv6 RA msg, Kernel deletes prev route and installs new route with updated metric] Deleted default via fe80::xx16:xxxx:feb3:ce8e dev eth0 proto ra metric 1996489705 expires 3sec hoplimit 64 pref high default via fe80::xx16:xxxx:feb3:ce8e dev eth0 proto ra metric 1996489704 pref high Signed-off-by:Praveen Chaudhary <pchaudhary@linkedin.com> Signed-off-by:
Zhenggen Xu <zxu@linkedin.com> Reviewed-by:
David Ahern <dsahern@kernel.org> Link: https://lore.kernel.org/r/20210125214430.24079-1-pchaudhary@linkedin.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Emil Renner Berthing says: ==================== net: usbnet: convert to new tasklet API This converts the usbnet driver to use the new tasklet API introduced in commit 12cc923f ("tasklet: Introduce new initialization API") It is split into two commits for ease of reviewing. ==================== Link: https://lore.kernel.org/r/20210123173221.5855-1-esmil@mailme.dkSigned-off-by:
-
Emil Renner Berthing authored
This converts the driver to use the new tasklet API introduced in commit 12cc923f ("tasklet: Introduce new initialization API") Signed-off-by:
Emil Renner Berthing <kernel@esmil.dk> Signed-off-by:
-
Emil Renner Berthing authored
Initialize tasklet using tasklet_init() rather than open-coding it. Signed-off-by:
-
Jakub Kicinski authored
Rasmus Villemoes says: ==================== net: dsa: mv88e6xxx: remove some 6250-specific methods v2: - resend now that the bug-fix patch (87fe0436, "net: dsa: mv88e6xxx: also read STU state in mv88e6250_g1_vtu_getnext") is in net and also merged to net-next. - include various tags in patch 1. - add second similar patch for loadpurge. ==================== Link: https://lore.kernel.org/r/20210125150449.115032-1-rasmus.villemoes@prevas.dkSigned-off-by:
-
Rasmus Villemoes authored
Apart from the mask used to get the high bits of the fid, mv88e6185_g1_vtu_loadpurge() and mv88e6250_g1_vtu_loadpurge() are identical. Since the entry->fid passed in should never exceed the number of databases, we can simply use the former as-is as replacement for the latter. Suggested-by:
Tobias Waldekranz <tobias@waldekranz.com> Signed-off-by:
Rasmus Villemoes <rasmus.villemoes@prevas.dk> Reviewed-by:
Vladimir Oltean <olteanv@gmail.com> Signed-off-by:
-
Rasmus Villemoes authored
mv88e6250_g1_vtu_getnext is almost identical to mv88e6185_g1_vtu_getnext, except for the 6250 only having 64 databases instead of 256. We can reduce code duplication by simply masking off the extra two garbage bits when assembling the fid from VTU op [3:0] and [11:8]. Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Seth David Schoen authored
Add selftests for kernel behavior with regard to various classes of unallocated/reserved IPv4 addresses, checking whether or not these addresses can be assigned as unicast addresses on links and used in routing. Expect the current kernel behavior at the time of this patch. That is: * 0/8 and 240/4 may be used as unicast, with the exceptions of 0.0.0.0 and 255.255.255.255; * the lowest address in a subnet may only be used as a broadcast address; * 127/8 may not be used as unicast (the route_localnet option, which is disabled by default, still leaves it treated slightly specially); * 224/4 may not be used as unicast. Signed-off-by:
Seth David Schoen <schoen@loyalty.org> Suggested-by:
John Gilmore <gnu@toad.com> Acked-by:
Dave Taht <dave.taht@gmail.com> Reviewed-by:
-
Arnd Bergmann authored
When TLS is a module, the built-in bonding driver may cause a link error: x86_64-linux-ld: drivers/net/bonding/bond_main.o: in function `bond_start_xmit': bond_main.c:(.text+0xc451): undefined reference to `tls_validate_xmit_skb' Add a dependency to avoid the problem. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20210125113209.2248522-1-arnd@kernel.orgSigned-off-by:
-
Michael Chan authored
Use the various netif_level() helpers to simplify the C code. This was suggested by Joe Perches. Cc: Joe Perches <joe@perches.com> Signed-off-by:
Michael Chan <michael.chan@broadcom.com> Link: https://lore.kernel.org/r/1611642024-3166-1-git-send-email-michael.chan@broadcom.comSigned-off-by:
-
Dongliang Mu authored
Every line of code should start with tab (8 characters) Signed-off-by:
Dongliang Mu <mudongliangabcd@gmail.com> Link: https://lore.kernel.org/r/20210123051102.1091541-1-mudongliangabcd@gmail.comSigned-off-by:
-
Nikolay Aleksandrov authored
Fix the messed up indentation in br_multicast_eht_set_entry_lookup(). Fixes: baa74d39 ("net: bridge: multicast: add EHT source set handling functions") Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Nikolay Aleksandrov <nikolay@nvidia.com> Link: https://lore.kernel.org/r/20210125082040.13022-1-razor@blackwall.orgSigned-off-by:
-
- 26 Jan, 2021 24 commits
-
-
wengjianfeng authored
change 'regster' to 'register' Signed-off-by:
wengjianfeng <wengjianfeng@yulong.com> Acked-by:
Mark Greer <mgreer@animalcreek.com> Link: https://lore.kernel.org/r/20210123082550.3748-1-samirweng1979@163.comSigned-off-by:
-
wengjianfeng authored
change 'paquet' to 'packet' Signed-off-by:
-
Jakub Kicinski authored
Michael Chan says: ==================== bnxt_en: Error recovery improvements. This series contains a number of improvements in the area of error recovery. Most error recovery scenarios are tightly coordinated with the firmware. A number of patches add retry logic to establish connection with the firmware if there are indications that the firmware is still alive and will likely transition back to the normal state. Some patches speed up the recovery process and make it more reliable. There are some cleanup patches as well. ==================== Link: https://lore.kernel.org/r/1611558501-11022-1-git-send-email-michael.chan@broadcom.comSigned-off-by:
-
Michael Chan authored
Once the firmware fatal condition is detected, we should cease comminication with the firmware and hardware quickly even if there are many completion entries in the completion rings. This will speed up the recovery process and prevent further I/Os that may cause further exceptions. Do not proceed in the NAPI poll function if fatal condition is detected. Call napi_complete() and return without arming interrupts. Cleanup of all rings and reset are imminent. Reviewed-by:
Pavan Chebbi <pavan.chebbi@broadcom.com> Reviewed-by:
Vasundhara Volam <vasundhara-v.volam@broadcom.com> Reviewed-by:
Edwin Peer <edwin.peer@broadcom.com> Signed-off-by:
Willem de Bruijn <willemb@google.com> Signed-off-by:
-
Michael Chan authored
Combine the three netdev_warn() calls into a single call, printed at the NETIF_MSG_HW log level. Reviewed-by:
-
Michael Chan authored
In the event of a fatal firmware error, firmware will notify the host and then it will proceed to do core reset when it sees that all functions have disabled Bus Master. To prevent Master Aborts and other hard errors, we need to quiesce all activities in addition to disabling Bus Master before the chip goes into core reset. Reviewed-by:
-
Michael Chan authored
In the event of a fatal firmware error, we want to disable IRQ early in the recovery sequence. This change will allow it to be called safely again as part of the normal shutdown sequence. Reviewed-by:
-
Michael Chan authored
Up until now, we don't need to keep track of this state because NAPI is always enabled once and disabled once during bring up and shutdown. For better error recovery in subsequent patches, we want to quiesce the device earlier during fatal error conditions. The normal shutdown sequence will disable NAPI again and the flag will prevent disabling NAPI twice. Reviewed-by:
Andy Gospodarek <gospo@broadcom.com> Reviewed-by:
-
Michael Chan authored
This code to check if we have reached the maximum wait time after firmware reset is used multiple times. Add a helper function to do this. Reviewed-by:
-
Vasundhara Volam authored
Firmware may be in the middle of reset when the driver tries to do ifup. In that case, firmware will return a special error code and the driver will retry 10 times with 50 msecs delay after each retry. Signed-off-by:
-
Edwin Peer authored
Drawing a hard line on aborted resets prevents a NIC open in some scenarios that may otherwise be recoverable. For example, if a firmware recovery happened while a PF was down and an attempt was made to bring up an associated VF in this state, then it was impossible to ever bring up this VF without a rebind or reload of its driver. Attempt to reinitialize the firmware when an aborted reset (or failed init after a reset) is discovered during open - it may succeed. Also take care to allow the user to retry opening the NIC even after an aborted reset. Signed-off-by:
-
Edwin Peer authored
Firmware is capable of generating asynchronous debug notifications. The event data is opaque to the driver and is simply logged. Debug notifications can be enabled by turning on hardware status messages using the ethtool msglvl interface. Reviewed-by:
-
Vasundhara Volam authored
The timeout period for firmware messages is passed to the driver from the firmware in the response of the first command. This timeout period is multiplied by a factor for certain long running commands such as NVRAM commands. In some cases, the timeout period can become really long and it can cause hung task warnings if firmware has crashed or is not responding. To avoid such long delays, cap all firmware commands to a max timeout value of 40 seconds. Reviewed-by:
-
Vasundhara Volam authored
If firmware is in reset or in bad state, it won't be able to return VPD data. Move bnxt_vpd_read_info() until after bnxt_fw_init_one_p1() successfully returns. By then we would have established proper communications with the firmware. Reviewed-by:
-
Michael Chan authored
The first HWRM_VER_GET message to firmware during probe may timeout if firmware is under reset. This can happen during hot-plug for example. On P5 and newer chips, we can check if firmware is in the boot stage by reading a status register. Retry 5 times if the status register shows that firmware is not ready and not in error state. Reviewed-by:
-
Edwin Peer authored
Add missing support for handling NO_MASTER crashes while ports are administratively down (ifdown). On some SoC platforms, the driver needs to assist the firmware to recover from a crash via OP-TEE. This is performed in a similar fashion to what is done during driver probe. Signed-off-by:
-
Michael Chan authored
Define macros to check for the various states in the lower 16 bits of the health register. Replace the C code that checks for these values with the newly defined macros. Reviewed-by:
-
Michael Chan authored
Updates to backing store APIs, QoS profiles, and push buffer initial index support. Since the new HWRM_FUNC_BACKING_STORE_CFG message size has increased, we need to add some compat. logic to fall back to the smaller legacy size if firmware cannot accept the larger message size. The new fields added to the structure are not used yet. Signed-off-by:
-
Jakub Kicinski authored
DENG Qingfang says: ==================== dsa: add MT7530 GPIO support MT7530's LED controller can be used as GPIO controller. Add support for it. ==================== Link: https://lore.kernel.org/r/20210125044322.6280-1-dqfext@gmail.comSigned-off-by:
-
DENG Qingfang authored
MT7530's LED controller can drive up to 15 LED/GPIOs. Add support for GPIO control and allow users to use its GPIOs by setting gpio-controller property in device tree. Signed-off-by:
DENG Qingfang <dqfext@gmail.com> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
DENG Qingfang authored
Add device tree binding to support MT7530 GPIO controller. Signed-off-by:
Rob Herring <robh@kernel.org> Reviewed-by:
-
DENG Qingfang authored
MT762x HW, except for MT7628, supports frame length up to 2048 (maximum length on GDM), so allow setting MTU up to 2030. Also set the default frame length to the hardware default 1518. Signed-off-by:
-
Jiapeng Zhong authored
coccicheck suggested using PTR_ERR_OR_ZERO() and looking at the code. Fix the following coccicheck warnings: ./net/bridge/br_multicast.c:1295:7-13: WARNING: PTR_ERR_OR_ZERO can be used. Reported-by:
Abaci <abaci@linux.alibaba.com> Signed-off-by:
Jiapeng Zhong <abaci-bugfix@linux.alibaba.com> Acked-by:
-
Subbaraya Sundeep authored
Support SPI and sequence number fields of ESP/AH header to be hashed for RSS. By default ESP/AH fields are not considered for RSS and needs to be set explicitly as below: ethtool -U eth0 rx-flow-hash esp4 sdfn or ethtool -U eth0 rx-flow-hash ah4 sdfn or ethtool -U eth0 rx-flow-hash esp6 sdfn or ethtool -U eth0 rx-flow-hash ah6 sdfn To disable hashing of ESP fields: ethtool -U eth0 rx-flow-hash esp4 sd or ethtool -U eth0 rx-flow-hash ah4 sd or ethtool -U eth0 rx-flow-hash esp6 sd or ethtool -U eth0 rx-flow-hash ah6 sd Signed-off-by:
Subbaraya Sundeep <sbhatta@marvell.com> Signed-off-by:
Sunil Kovvuri Goutham <sgoutham@marvell.com> Link: https://lore.kernel.org/r/1611378552-13288-1-git-send-email-sundeep.lkml@gmail.comSigned-off-by:
-
- 25 Jan, 2021 1 commit
-
-
Heiner Kallweit authored
When working on the PCI VPD code I also tested with a Broadcom BCM95719 card. tg3 uses internal NVRAM access with this card, so I forced it to PCI VPD mode for testing. PCI VPD access fails (i + PCI_VPD_LRDT_TAG_SIZE + j > len) because only TG3_NVM_VPD_LEN (256) bytes are read, but PCI VPD has 400 bytes on this card. So add a constant TG3_NVM_PCI_VPD_MAX_LEN that defines the maximum PCI VPD size. The actual VPD size is returned by pci_read_vpd(). In addition it's not worth looping over pci_read_vpd(). If we miss the 125ms timeout per VPD dword read then definitely something is wrong, and if the tg3 module loading is killed then there's also not much benefit in retrying the VPD read. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by:
-
- 24 Jan, 2021 3 commits
-
-
Jakub Kicinski authored
Kurt Kanzenbach says: ==================== net: dsa: hellcreek: Add TAPRIO offloading The switch has support for the 802.1Qbv Time Aware Shaper (TAS). Traffic schedules may be configured individually on each front port. Each port has eight egress queues. The traffic is mapped to a traffic class respectively via the PCP field of a VLAN tagged frame. Previous attempts: * https://lkml.kernel.org/netdev/20201121115703.23221-1-kurt@linutronix.de/ * https://lkml.kernel.org/netdev/20210116124922.32356-1-kurt@linutronix.de/ ==================== Link: https://lore.kernel.org/r/20210123105633.16753-1-kurt@linutronix.deSigned-off-by:
-
Kurt Kanzenbach authored
The switch has support for the 802.1Qbv Time Aware Shaper (TAS). Traffic schedules may be configured individually on each front port. Each port has eight egress queues. The traffic is mapped to a traffic class respectively via the PCP field of a VLAN tagged frame. The TAPRIO Qdisc already implements that. Therefore, this interface can simply be reused. Add .port_setup_tc() accordingly. The activation of a schedule on a port is split into two parts: * Programming the necessary gate control list (GCL) * Setup delayed work for starting the schedule The hardware supports starting a schedule up to eight seconds in the future. The TAPRIO interface provides an absolute base time. Therefore, periodic delayed work is leveraged to check whether a schedule may be started or not. Signed-off-by:
Kurt Kanzenbach <kurt@linutronix.de> Reviewed-by:
-
Loic Poulain authored
The 'wwan' devtype is meant for devices that require additional configuration to be used, like WWAN specific APN setup over AT/QMI commands, rmnet link creation, etc. This is the case for MHI (Modem host Interface) netdev which targets modem/WWAN endpoints. Signed-off-by:
Loic Poulain <loic.poulain@linaro.org> Link: https://lore.kernel.org/r/1611328554-1414-1-git-send-email-loic.poulain@linaro.orgSigned-off-by:
-
