- 06 Nov, 2020 31 commits
-
-
Ido Schimmel authored
Emit a notification in the nexthop notification chain when a new nexthop is added (not replaced). The nexthop can either be a new group or a single nexthop. The notification is sent after the nexthop is inserted into the red-black tree, as listeners might need to callback into the nexthop code with the nexthop ID in order to mark the nexthop as offloaded. A 'REPLACE' notification is emitted instead of 'ADD' as the distinction between the two is not important for in-kernel listeners. In case the listener is not familiar with the encoded nexthop ID, it can simply treat it as a new one. This is also consistent with the route offload API. Changes since RFC: * Reword commit message Signed-off-by:
Ido Schimmel <idosch@nvidia.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Ido Schimmel authored
Add a function that can be called by device drivers to set "offload" or "trap" indication on nexthops following nexthop notifications. Changes since RFC: * s/nexthop_hw_flags_set/nexthop_set_hw_flags/ Signed-off-by:
-
Ido Schimmel authored
The flag indicates to user space that the nexthop is not programmed to forward packets in hardware, but rather to trap them to the CPU. This is needed, for example, when the MAC of the nexthop neighbour is not resolved and packets should reach the CPU to trigger neighbour resolution. The flag will be used in subsequent patches by netdevsim to test nexthop objects programming to device drivers and in the future by mlxsw as well. Changes since RFC: * Reword commit message Signed-off-by:
David Ahern <dsahern@gmail.com> Signed-off-by:
-
Ido Schimmel authored
Convert the sole listener of the nexthop notification chain (the VXLAN driver) to the new notification info. Signed-off-by:
-
Ido Schimmel authored
Prepare the new notification information so that it could be passed to listeners in the new patch. Changes since RFC: * Add a blank line in __nh_notifier_single_info_init() Signed-off-by:
-
Ido Schimmel authored
The next patch will add extack to the notification info. This allows listeners to veto notifications and communicate the reason to user space. Signed-off-by:
-
Ido Schimmel authored
Add data structures that will be used for nexthop replace and delete notifications in the previously introduced nexthop notification chain. New data structures are added instead of passing the existing nexthop code structures directly for several reasons. First, the existing structures encode a lot of bookkeeping information which is irrelevant for listeners of the notification chain. Second, the existing structures can be changed without worrying about introducing regressions in listeners since they are not accessed directly by them. Third, listeners of the notification chain do not need to each parse the relatively complex nexthop code structures. They are passing the required information in a simplified way. Note that a single 'has_encap' bit is added instead of the actual encapsulation information since current listeners do not support such nexthops. Changes since RFC: * s/is_encap/has_encap/ Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linuxJakub Kicinski authored
Saeed Mahameed says: ==================== mlx5-updates-2020-11-03 This series includes updates to mlx5 software steering component. 1) Few improvements in the DR area, such as removing unneeded checks, renaming to better general names, refactor in some places, etc. 2) Software steering (DR) Memory management improvements This patch series contains SW Steering memory management improvements: using buddy allocator instead of an existing bucket allocator, and several other optimizations. The buddy system is a memory allocation and management algorithm that manages memory in power of two increments. The algorithm is well-known and well-described, such as here: https://en.wikipedia.org/wiki/Buddy_memory_allocation Linux uses this algorithm for managing and allocating physical pages, as described here: https://www.kernel.org/doc/gorman/html/understand/understand009.html In our case, although the algorithm in principal is similar to the Linux physical page allocator, the "building blocks" and the circumstances are different: in SW steering, buddy allocator doesn't really allocates a memory, but rather manages ICM (Interconnect Context Memory) that was previously allocated and registered. The ICM memory that is used in SW steering is always power of 2 (order), so buddy system is a good fit for this. Patches in this series: [PATH 4] net/mlx5: DR, Add buddy allocator utilities This patch adds a modified implementation of a well-known buddy allocator, adjusted for SW steering needs: the algorithm in principal is similar to the Linux physical page allocator, but in our case buddy allocator doesn't really allocate a memory, but rather manages ICM memory that was previously allocated and registered. [PATH 5] net/mlx5: DR, Handle ICM memory via buddy allocation instead of bucket management This patch changes ICM management of SW steering to use buddy-system mechanism Instead of the previous bucket management. [PATH 6] net/mlx5: DR, Sync chunks only during free This patch makes syncing happen only when freeing memory chunks. [PATH 7] net/mlx5: DR, ICM memory pools sync optimization This patch adds tracking of pool's "hot" memory and makes the check whether steering sync is required much shorter and faster. [PATH 8] net/mlx5: DR, Free buddy ICM memory if it is unused This patch adds tracking buddy's used ICM memory, and frees the buddy if all its memory becomes unused. 3) Misc code cleanups * tag 'mlx5-updates-2020-11-03' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux: net: mlx5: Replace in_irq() usage net/mlx5: Cleanup kernel-doc warnings net/mlx4: Cleanup kernel-doc warnings net/mlx5e: Validate stop_room size upon user input net/mlx5: DR, Free unused buddy ICM memory net/mlx5: DR, ICM memory pools sync optimization net/mlx5: DR, Sync chunks only during free net/mlx5: DR, Handle ICM memory via buddy allocation instead of buckets net/mlx5: DR, Add buddy allocator utilities net/mlx5: DR, Rename matcher functions to be more HW agnostic net/mlx5: DR, Rename builders HW specific names net/mlx5: DR, Remove unused member of action struct ==================== Link: https://lore.kernel.org/r/20201105201242.21716-1-saeedm@nvidia.comSigned-off-by:
-
Hayes Wang authored
Support ECM mode based on cdc_ether with relative mii functions, when CONFIG_USB_RTL8152 is not set, or the device is not supported by r8152 driver. Both r8152 and r8153_ecm would check the return value of rtl8152_get_version() in porbe(). If rtl8152_get_version() return none zero value, the r8152 is used for the device with vendor mode. Otherwise, the r8153_ecm is used for the device with ECM mode. Signed-off-by:
Hayes Wang <hayeswang@realtek.com> Link: https://lore.kernel.org/r/1394712342-15778-392-Taiwan-albertk@realtek.comSigned-off-by:
-
Loic Poulain authored
This patch adds a new network driver implementing MHI transport for network packets. Packets can be in any format, though QMAP (rmnet) is the usual protocol (flow control + PDN mux). It support two MHI devices, IP_HW0 which is, the path to the IPA (IP accelerator) on qcom modem, And IP_SW0 which is the software driven IP path (to modem CPU). Signed-off-by:
Loic Poulain <loic.poulain@linaro.org> Reviewed-by:
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Link: https://lore.kernel.org/r/1604424234-24446-2-git-send-email-loic.poulain@linaro.orgSigned-off-by:
-
Loic Poulain authored
This function can be used by client driver to determine whether it's possible to queue new elements in a channel ring. Signed-off-by:
-
Jakub Kicinski authored
Ioana Ciornei says: ==================== net: phy: add support for shared interrupts (part 1) This patch set aims to actually add support for shared interrupts in phylib and not only for multi-PHY devices. While we are at it, streamline the interrupt handling in phylib. For a bit of context, at the moment, there are multiple phy_driver ops that deal with this subject: - .config_intr() - Enable/disable the interrupt line. - .ack_interrupt() - Should quiesce any interrupts that may have been fired. It's also used by phylib in conjunction with .config_intr() to clear any pending interrupts after the line was disabled, and before it is going to be enabled. - .did_interrupt() - Intended for multi-PHY devices with a shared IRQ line and used by phylib to discern which PHY from the package was the one that actually fired the interrupt. - .handle_interrupt() - Completely overrides the default interrupt handling logic from phylib. The PHY driver is responsible for checking if any interrupt was fired by the respective PHY and choose accordingly if it's the one that should trigger the link state machine. From my point of view, the interrupt handling in phylib has become somewhat confusing with all these callbacks that actually read the same PHY register - the interrupt status. A more streamlined approach would be to just move the responsibility to write an interrupt handler to the driver (as any other device driver does) and make .handle_interrupt() the only way to deal with interrupts. Another advantage with this approach would be that phylib would gain support for shared IRQs between different PHY (not just multi-PHY devices), something which at the moment would require extending every PHY driver anyway in order to implement their .did_interrupt() callback and duplicate the same logic as in .ack_interrupt(). The disadvantage of making .did_interrupt() mandatory would be that we are slightly changing the semantics of the phylib API and that would increase confusion instead of reducing it. What I am proposing is the following: - As a first step, make the .ack_interrupt() callback optional so that we do not break any PHY driver amid the transition. - Every PHY driver gains a .handle_interrupt() implementation that, for the most part, would look like below: irq_status = phy_read(phydev, INTR_STATUS); if (irq_status < 0) { phy_error(phydev); return IRQ_NONE; } if (!(irq_status & irq_mask)) return IRQ_NONE; phy_trigger_machine(phydev); return IRQ_HANDLED; - Remove each PHY driver's implementation of the .ack_interrupt() by actually taking care of quiescing any pending interrupts before enabling/after disabling the interrupt line. - Finally, after all drivers have been ported, remove the .ack_interrupt() and .did_interrupt() callbacks from phy_driver. This patch set is part 1 and it addresses the changes needed in phylib and 7 PHY drivers. The rest can be found on my Github branch here: https://github.com/IoanaCiornei/linux/commits/phylib-shared-irq I do not have access to most of these PHY's, therefore I Cc-ed the latest contributors to the individual PHY drivers in order to have access, hopefully, to more regression testing. Changes in v2: - Rework the .handle_interrupt() implementation for each driver so that only the enabled interrupts are taken into account when IRQ_NONE/IRQ_HANDLED it returned. The main idea is so that we avoid falsely blaming a device for triggering an interrupt when this is not the case. The only devices for which I was unable to make this adjustment were the BCM8706, BCM8727, BCMAC131 and BCM5241 since I do not have access to their datasheets. - I also updated the pseudo-code added in the cover-letter so that it's more clear how a .handle_interrupt() callback should look like. ==================== Tested-by:Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20201101125114.1316879-1-ciorneiioana@gmail.comSigned-off-by:
-
Ioana Ciornei authored
In preparation of removing the .ack_interrupt() callback, we must replace its occurrences (aka phy_clear_interrupt), from the 2 places where it is called from (phy_enable_interrupts and phy_disable_interrupts), with equivalent functionality. This means that clearing interrupts now becomes something that the PHY driver is responsible of doing, before enabling interrupts and after clearing them. Make this driver follow the new contract. Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Cc: Willy Liu <willy.liu@realtek.com> Signed-off-by:
Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by:
-
Ioana Ciornei authored
In an attempt to actually support shared IRQs in phylib, we now move the responsibility of triggering the phylib state machine or just returning IRQ_NONE, based on the IRQ status register, to the PHY driver. Having 3 different IRQ handling callbacks (.handle_interrupt(), .did_interrupt() and .ack_interrupt() ) is confusing so let the PHY driver implement directly an IRQ handler like any other device driver. Make this driver follow the new convention. Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Cc: Willy Liu <willy.liu@realtek.com> Signed-off-by:
-
Ioana Ciornei authored
It seems there are cases where the interrupts are handled by another entity (ie an IRQ controller embedded inside the PHY) and do not need any other interraction from phylib. For this kind of PHYs, like the RTL8366RB, add the genphy_handle_interrupt_no_ack() function which just triggers the link state machine. Signed-off-by:
-
Ioana Ciornei authored
In preparation of removing the .ack_interrupt() callback, we must replace its occurrences (aka phy_clear_interrupt), from the 2 places where it is called from (phy_enable_interrupts and phy_disable_interrupts), with equivalent functionality. This means that clearing interrupts now becomes something that the PHY driver is responsible of doing, before enabling interrupts and after clearing them. Make this driver follow the new contract. Signed-off-by:
-
Ioana Ciornei authored
In an attempt to actually support shared IRQs in phylib, we now move the responsibility of triggering the phylib state machine or just returning IRQ_NONE, based on the IRQ status register, to the PHY driver. Having 3 different IRQ handling callbacks (.handle_interrupt(), .did_interrupt() and .ack_interrupt() ) is confusing so let the PHY driver implement directly an IRQ handler like any other device driver. Make this driver follow the new convention. Signed-off-by:
-
Ioana Ciornei authored
In preparation of removing the .ack_interrupt() callback, we must replace its occurrences (aka phy_clear_interrupt), from the 2 places where it is called from (phy_enable_interrupts and phy_disable_interrupts), with equivalent functionality. This means that clearing interrupts now becomes something that the PHY driver is responsible of doing, before enabling interrupts and after clearing them. Make this driver follow the new contract. Signed-off-by:
-
Ioana Ciornei authored
In an attempt to actually support shared IRQs in phylib, we now move the responsibility of triggering the phylib state machine or just returning IRQ_NONE, based on the IRQ status register, to the PHY driver. Having 3 different IRQ handling callbacks (.handle_interrupt(), .did_interrupt() and .ack_interrupt() ) is confusing so let the PHY driver implement directly an IRQ handler like any other device driver. Make this driver follow the new convention. Signed-off-by:
-
Ioana Ciornei authored
In preparation of removing the .ack_interrupt() callback, we must replace its occurrences (aka phy_clear_interrupt), from the 2 places where it is called from (phy_enable_interrupts and phy_disable_interrupts), with equivalent functionality. This means that clearing interrupts now becomes something that the PHY driver is responsible of doing, before enabling interrupts and after clearing them. Make this driver follow the new contract. Cc: Michael Walle <michael@walle.cc> Cc: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Ioana Ciornei authored
In an attempt to actually support shared IRQs in phylib, we now move the responsibility of triggering the phylib state machine or just returning IRQ_NONE, based on the IRQ status register, to the PHY driver. Having 3 different IRQ handling callbacks (.handle_interrupt(), .did_interrupt() and .ack_interrupt() ) is confusing so let the PHY driver implement directly an IRQ handler like any other device driver. Make this driver follow the new convention. Cc: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
Michael Walle <michael@walle.cc> Signed-off-by:
-
Ioana Ciornei authored
In preparation of removing the .ack_interrupt() callback, we must replace its occurrences (aka phy_clear_interrupt), from the 2 places where it is called from (phy_enable_interrupts and phy_disable_interrupts), with equivalent functionality. This means that clearing interrupts now becomes something that the PHY driver is responsible of doing, before enabling interrupts and after clearing them. Make this driver follow the new contract. Cc: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
-
Ioana Ciornei authored
In an attempt to actually support shared IRQs in phylib, we now move the responsibility of triggering the phylib state machine or just returning IRQ_NONE, based on the IRQ status register, to the PHY driver. Having 3 different IRQ handling callbacks (.handle_interrupt(), .did_interrupt() and .ack_interrupt() ) is confusing so let the PHY driver implement directly an IRQ handler like any other device driver. Make this driver follow the new convention. Cc: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
-
Ioana Ciornei authored
In preparation of removing the .ack_interrupt() callback, we must replace its occurrences (aka phy_clear_interrupt), from the 2 places where it is called from (phy_enable_interrupts and phy_disable_interrupts), with equivalent functionality. This means that clearing interrupts now becomes something that the PHY driver is responsible of doing, before enabling interrupts and after clearing them. Make this driver follow the new contract. Cc: Antoine Tenart <atenart@kernel.org> Signed-off-by:
-
Ioana Ciornei authored
In an attempt to actually support shared IRQs in phylib, we now move the responsibility of triggering the phylib state machine or just returning IRQ_NONE, based on the IRQ status register, to the PHY driver. Having 3 different IRQ handling callbacks (.handle_interrupt(), .did_interrupt() and .ack_interrupt() ) is confusing so let the PHY driver implement directly an IRQ handler like any other device driver. Make this driver follow the new convention. Also, remove the .did_interrupt() callback since it's not anymore used. Signed-off-by:
-
Ioana Ciornei authored
According to the comment describing the phy_mac_interrupt() function, it it intended to be used by MAC drivers which have noticed a link change thus its use in the mscc PHY driver is improper and, most probably, was added just because phy_trigger_machine() was not exported. Now that we have acces to trigger the link state machine, use directly the phy_trigger_machine() function to notify a link change detected by the PHY driver. Signed-off-by:
Vladimir Oltean <olteanv@gmail.com> Signed-off-by:
-
Ioana Ciornei authored
In preparation of removing the .ack_interrupt() callback, we must replace its occurrences (aka phy_clear_interrupt), from the 2 places where it is called from (phy_enable_interrupts and phy_disable_interrupts), with equivalent functionality. This means that clearing interrupts now becomes something that the PHY driver is responsible of doing, before enabling interrupts and after clearing them. Make this driver follow the new contract. Cc: Oleksij Rempel <o.rempel@pengutronix.de> Cc: Michael Walle <michael@walle.cc> Signed-off-by:
Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by:
-
Ioana Ciornei authored
In an attempt to actually support shared IRQs in phylib, we now move the responsibility of triggering the phylib state machine or just returning IRQ_NONE, based on the IRQ status register, to the PHY driver. Having 3 different IRQ handling callbacks (.handle_interrupt(), .did_interrupt() and .ack_interrupt() ) is confusing so let the PHY driver implement directly an IRQ handler like any other device driver. Make this driver follow the new convention. Cc: Oleksij Rempel <o.rempel@pengutronix.de> Cc: Michael Walle <michael@walle.cc> Signed-off-by:
-
Ioana Ciornei authored
As a first step into making phylib and all PHY drivers to actually have support for shared IRQs, make the .ack_interrupt() callback optional. After all drivers have been moved to implement the generic interrupt handle, the phy_drv_supports_irq() check will be changed again to only require the .handle_interrupts() callback. Cc: Alexandru Ardelean <alexandru.ardelean@analog.com> Cc: Andre Edich <andre.edich@microchip.com> Cc: Antoine Tenart <atenart@kernel.org> Cc: Baruch Siach <baruch@tkos.co.il> Cc: Christophe Leroy <christophe.leroy@c-s.fr> Cc: Dan Murphy <dmurphy@ti.com> Cc: Divya Koppera <Divya.Koppera@microchip.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: Hauke Mehrtens <hauke@hauke-m.de> Cc: Heiner Kallweit <hkallweit1@gmail.com> Cc: Jerome Brunet <jbrunet@baylibre.com> Cc: Kavya Sree Kotagiri <kavyasree.kotagiri@microchip.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Marco Felsch <m.felsch@pengutronix.de> Cc: Marek Vasut <marex@denx.de> Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Cc: Mathias Kresin <dev@kresin.me> Cc: Maxim Kochetkov <fido_max@inbox.ru> Cc: Michael Walle <michael@walle.cc> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Nisar Sayed <Nisar.Sayed@microchip.com> Cc: Oleksij Rempel <o.rempel@pengutronix.de> Cc: Philippe Schenker <philippe.schenker@toradex.com> Cc: Willy Liu <willy.liu@realtek.com> Cc: Yuiko Oshino <yuiko.oshino@microchip.com> Signed-off-by:
-
Ioana Ciornei authored
In case of a board which uses a shared IRQ we can easily end up with an IRQ storm after a forced reboot. For example, a 'reboot -f' will trigger a call to the .shutdown() callbacks of all devices. Because phylib does not implement that hook, the PHY is not quiesced, thus it can very well leave its IRQ enabled. At the next boot, if that IRQ line is found asserted by the first PHY driver that uses it, but _before_ the driver that is _actually_ keeping the shared IRQ asserted is probed, the IRQ is not going to be acknowledged, thus it will keep being fired preventing the boot process of the kernel to continue. This is even worse when the second PHY driver is a module. To fix this, implement the .shutdown() callback and disable the interrupts if these are used. Note that we are still susceptible to IRQ storms if the previous kernel exited with a panic or if the bootloader left the shared IRQ active, but there is absolutely nothing we can do about these cases. Cc: Alexandru Ardelean <alexandru.ardelean@analog.com> Cc: Andre Edich <andre.edich@microchip.com> Cc: Antoine Tenart <atenart@kernel.org> Cc: Baruch Siach <baruch@tkos.co.il> Cc: Christophe Leroy <christophe.leroy@c-s.fr> Cc: Dan Murphy <dmurphy@ti.com> Cc: Divya Koppera <Divya.Koppera@microchip.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: Hauke Mehrtens <hauke@hauke-m.de> Cc: Heiner Kallweit <hkallweit1@gmail.com> Cc: Jerome Brunet <jbrunet@baylibre.com> Cc: Kavya Sree Kotagiri <kavyasree.kotagiri@microchip.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Marco Felsch <m.felsch@pengutronix.de> Cc: Marek Vasut <marex@denx.de> Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Cc: Mathias Kresin <dev@kresin.me> Cc: Maxim Kochetkov <fido_max@inbox.ru> Cc: Michael Walle <michael@walle.cc> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Nisar Sayed <Nisar.Sayed@microchip.com> Cc: Oleksij Rempel <o.rempel@pengutronix.de> Cc: Philippe Schenker <philippe.schenker@toradex.com> Cc: Willy Liu <willy.liu@realtek.com> Cc: Yuiko Oshino <yuiko.oshino@microchip.com> Signed-off-by:
-
Ioana Ciornei authored
These functions are currently used by phy_interrupt() to either signal an error condition or to trigger the link state machine. In an attempt to actually support shared PHY IRQs, export these two functions so that the actual PHY drivers can use them. Cc: Alexandru Ardelean <alexandru.ardelean@analog.com> Cc: Andre Edich <andre.edich@microchip.com> Cc: Antoine Tenart <atenart@kernel.org> Cc: Baruch Siach <baruch@tkos.co.il> Cc: Christophe Leroy <christophe.leroy@c-s.fr> Cc: Dan Murphy <dmurphy@ti.com> Cc: Divya Koppera <Divya.Koppera@microchip.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: Hauke Mehrtens <hauke@hauke-m.de> Cc: Heiner Kallweit <hkallweit1@gmail.com> Cc: Jerome Brunet <jbrunet@baylibre.com> Cc: Kavya Sree Kotagiri <kavyasree.kotagiri@microchip.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Marco Felsch <m.felsch@pengutronix.de> Cc: Marek Vasut <marex@denx.de> Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Cc: Mathias Kresin <dev@kresin.me> Cc: Maxim Kochetkov <fido_max@inbox.ru> Cc: Michael Walle <michael@walle.cc> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Nisar Sayed <Nisar.Sayed@microchip.com> Cc: Oleksij Rempel <o.rempel@pengutronix.de> Cc: Philippe Schenker <philippe.schenker@toradex.com> Cc: Willy Liu <willy.liu@realtek.com> Cc: Yuiko Oshino <yuiko.oshino@microchip.com> Signed-off-by:
-
- 05 Nov, 2020 9 commits
-
-
Xin Long authored
inet(6)_skb_parm was removed from sctp_input_cb by Commit a1dd2cf2 ("sctp: allow changing transport encap_port by peer packets"), as it thought sctp_input_cb->header is not used any more in SCTP. syzbot reported a crash: [ ] BUG: KASAN: use-after-free in decode_session6+0xe7c/0x1580 [ ] [ ] Call Trace: [ ] <IRQ> [ ] dump_stack+0x107/0x163 [ ] kasan_report.cold+0x1f/0x37 [ ] decode_session6+0xe7c/0x1580 [ ] __xfrm_policy_check+0x2fa/0x2850 [ ] sctp_rcv+0x12b0/0x2e30 [ ] sctp6_rcv+0x22/0x40 [ ] ip6_protocol_deliver_rcu+0x2e8/0x1680 [ ] ip6_input_finish+0x7f/0x160 [ ] ip6_input+0x9c/0xd0 [ ] ipv6_rcv+0x28e/0x3c0 It was caused by sctp_input_cb->header/IP6CB(skb) still used in sctp rx path decode_session6() but some members overwritten by sctp6_rcv(). This patch is to fix it by bring inet(6)_skb_parm back to sctp_input_cb and not overwriting it in sctp4/6_rcv() and sctp_udp_rcv(). Reported-by: syzbot+5be8aebb1b7dfa90ef31@syzkaller.appspotmail.com Fixes: a1dd2cf2 ("sctp: allow changing transport encap_port by peer packets") Signed-off-by:
Xin Long <lucien.xin@gmail.com> Acked-by:
Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Link: https://lore.kernel.org/r/136c1a7a419341487c504be6d1996928d9d16e02.1604472932.git.lucien.xin@gmail.comSigned-off-by:
-
Jakub Kicinski authored
Kurt Kanzenbach says: ==================== Hirschmann Hellcreek DSA driver this series adds a DSA driver for the Hirschmann Hellcreek TSN switch IP. Characteristics of that IP: * Full duplex Ethernet interface at 100/1000 Mbps on three ports * IEEE 802.1Q-compliant Ethernet Switch * IEEE 802.1Qbv Time-Aware scheduling support * IEEE 1588 and IEEE 802.1AS support That IP is used e.g. in https://www.arrow.com/en/campaigns/arrow-kairos Due to the hardware setup the switch driver is implemented using DSA. A special tagging protocol is leveraged. Furthermore, this driver supports PTP and hardware timestamping. This work is part of the AccessTSN project: https://www.accesstsn.com/ The previous versions can be found here: * https://lkml.kernel.org/netdev/20200618064029.32168-1-kurt@linutronix.de/ * https://lkml.kernel.org/netdev/20200710113611.3398-1-kurt@linutronix.de/ * https://lkml.kernel.org/netdev/20200723081714.16005-1-kurt@linutronix.de/ * https://lkml.kernel.org/netdev/20200820081118.10105-1-kurt@linutronix.de/ * https://lkml.kernel.org/netdev/20200901125014.17801-1-kurt@linutronix.de/ * https://lkml.kernel.org/netdev/20200904062739.3540-1-kurt@linutronix.de/ * https://lkml.kernel.org/netdev/20201004112911.25085-1-kurt@linutronix.de/ * https://lkml.kernel.org/netdev/20201028074221.29326-1-kurt@linutronix.de/ Changes since v7: * Simplify tagging code (rebase to net-next) * Pass info instead of ptr (Florian Fainelli) * Fix yamllint warnings (Rob Herring) Changes since v6: * Add .tail_tag = true (Vladimir Oltean) * Fix vlan_filtering=0 bridges (Vladimir Oltean) * Enforce restrictions (Vladimir Oltean) * Sort stuff alphabetically (Vladimir Oltean) * Rename hellcreek.yaml to hirschmann,hellcreek.yaml * Typo fixes Changes since v5: * Implement configure_vlan_while_not_filtering behavior (Vladimir Oltean) * Minor cleanups Changes since v4: * Fix W=1 compiler warnings (kernel test robot) * Add tags Changes since v3: * Drop TAPRIO support (David Miller) => Switch to mutexes due to the lack of hrtimers * Use more specific compatible strings and add platform data (Andrew Lunn) * Fix Kconfig ordering (Andrew Lunn) Changes since v2: * Make it compile by getting all requirements merged first (Jakub Kicinski, David Miller) * Use "tsn" for TSN register set (Rob Herring) * Fix DT binding issues (Rob Herring) Changes since v1: * Code simplifications (Florian Fainelli, Vladimir Oltean) * Fix issues with hellcreek.yaml bindings (Florian Fainelli) * Clear reserved field in ptp v2 event messages (Richard Cochran) * Make use of generic ptp parsing function (Richard Cochran, Vladimir Oltean) * Fix Kconfig (Florian Fainelli) * Add tags (Florian Fainelli, Rob Herring, Richard Cochran) Changes since RFC ordered by reviewers: * Andrew Lunn * Use dev_dbg for debug messages * Get rid of __ function names where possible * Use reverse xmas tree variable ordering * Remove redundant/useless checks * Improve comments e.g. for PTP * Fix Kconfig ordering * Make LED handling more generic and provide info via DT * Setup advertisement of PHYs according to hardware * Drop debugfs patch * Jakub Kicinski * Fix compiler warnings * Florian Fainelli * Switch to YAML DT bindings * Richard Cochran * Fix typo * Add missing NULL checks ==================== Link: https://lore.kernel.org/r/20201103071101.3222-1-kurt@linutronix.deSigned-off-by:
-
Kurt Kanzenbach authored
Add basic documentation and example. Signed-off-by:
Kurt Kanzenbach <kurt@linutronix.de> Reviewed-by:
Rob Herring <robh@kernel.org> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Kurt Kanzenbach authored
Hirschmann is building devices for automation and networking. Add them to the vendor prefixes. Signed-off-by:
-
Kurt Kanzenbach authored
The switch has two controllable I/Os which are usually connected to LEDs. This is useful to immediately visually see the PTP status. These provide two signals: * is_gm This LED can be activated if the current device is the grand master in that PTP domain. * sync_good This LED can be activated if the current device is in sync with the network time. Expose these via the LED framework to be controlled via user space e.g. linuxptp. Signed-off-by:
-
Kamil Alkhouri authored
The switch has the ability to take hardware generated time stamps per port for PTPv2 event messages in Rx and Tx direction. That is useful for achieving needed time synchronization precision for TSN devices/switches. So add support for it. There are two directions: * RX The switch has a single register per port to capture a timestamp. That mechanism is not used due to correlation problems. If the software processing is too slow and a PTPv2 event message is received before the previous one has been processed, false timestamps will be captured. Therefore, the switch can do "inline" timestamping which means it can insert the nanoseconds part of the timestamp directly into the PTPv2 event message. The reserved field (4 bytes) is leveraged for that. This might not be in accordance with (older) PTP standards, but is the only way to get reliable results. * TX In Tx direction there is no correlation problem, because the software and the driver has to ensure that only one event message is "on the fly". However, the switch provides also a mechanism to check whether a timestamp is lost. That can only happen when a timestamp is read and at this point another message is timestamped. So, that lost bit is checked just in case to indicate to the user that the driver or the software is somewhat buggy. Signed-off-by:
Kamil Alkhouri <kamil.alkhouri@hs-offenburg.de> Signed-off-by:
Richard Cochran <richardcochran@gmail.com> Signed-off-by:
-
Kamil Alkhouri authored
The switch has internal PTP hardware clocks. Add support for it. There are three clocks: * Synchronized * Syntonized * Free running Currently the synchronized clock is exported to user space which is a good default for the beginning. The free running clock might be exported later e.g. for implementing 802.1AS-2011/2020 Time Aware Bridges (TAB). The switch also supports cross time stamping for that purpose. The implementation adds support setting/getting the time as well as offset and frequency adjustments. However, the clock only holds a partial timeofday timestamp. This is why we track the seconds completely in software (see overflow work and last_ts). Furthermore, add the PTP multicast addresses into the FDB to forward that packages only to the CPU port where they are processed by a PTP program. Signed-off-by:
-
Kurt Kanzenbach authored
Add a basic DSA driver for Hirschmann Hellcreek switches. Those switches are implementing features needed for Time Sensitive Networking (TSN) such as support for the Time Precision Protocol and various shapers like the Time Aware Shaper. This driver includes basic support for networking: * VLAN handling * FDB handling * Port statistics * STP * Phylink Signed-off-by:
-
Vladimir Oltean authored
Some switches rely on unique pvids to ensure port separation in standalone mode, because they don't have a port forwarding matrix configurable in hardware. So, setups like a group of 2 uppers with the same VLAN, swp0.100 and swp1.100, will cause traffic tagged with VLAN 100 to be autonomously forwarded between these switch ports, in spite of there being no bridge between swp0 and swp1. These drivers need to prevent this from happening. They need to have VLAN filtering enabled in standalone mode (so they'll drop frames tagged with unknown VLANs) and they can only accept an 8021q upper on a port as long as it isn't installed on any other port too. So give them the chance to veto bad user requests. Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> [Kurt: Pass info instead of ptr] Signed-off-by:
-
