summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-11-25net: dsa: mv88e6xxx: Support serdes ports on MV88E6097/6095/6185Chris Packham
Implement serdes_power, serdes_get_lane and serdes_pcs_get_state ops for the MV88E6097/6095/6185 so that ports 8 & 9 can be supported as serdes ports and directly connected to other network interfaces or to SFPs without a PHY. Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-25net: dsa: mv88e6xxx: Don't force link when using in-band-statusChris Packham
When a port is configured with 'managed = "in-band-status"' switch chips like the 88E6390 need to propagate the SERDES link state to the MAC because the link state is not correctly detected. This causes problems on the 88E6185/88E6097 where the link partner won't see link state changes because we're forcing the link. To address this introduce a new device specific op port_sync_link() and push the logic from mv88e6xxx_mac_link_up() into that. Provide an implementation for the 88E6185 like devices which doesn't force the link. Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-25Merge branch 'dt-bindings-net-dsa-microchip-convert-ksz-bindings-to-yaml'Jakub Kicinski
Christian Eggers says: ==================== dt-bindings: net: dsa: microchip: convert KSZ bindings to yaml These patches are orginally from the series "net: dsa: microchip: PTP support for KSZ956x" As the the device tree conversion to yaml is not really related to the PTP patches and the original series is going to take more time than I expected, I would like to split this. Changes (original series -> v1) -------------------------------- - dts: moved "allOf" below "maintainers" - dts: use "unevaluatedProperties" instead of "additionalProperties" - dts: removed "spi-cpha" and "spi-cpol" flags as the hardware is fixed - ksz8795: setup SPI for mode 3 - ksz9477: dito ==================== Link: https://lore.kernel.org/r/20201120112107.16334-1-ceggers@arri.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-25net: dsa: microchip: ksz8795: setup SPI modeChristian Eggers
This should be done in the device driver instead of the device tree. Signed-off-by: Christian Eggers <ceggers@arri.de> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-25net: dsa: microchip: ksz9477: setup SPI modeChristian Eggers
This should be done in the device driver instead of the device tree. Signed-off-by: Christian Eggers <ceggers@arri.de> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-25net: dsa: microchip: support for "ethernet-ports" nodeChristian Eggers
The dsa.yaml device tree binding allows "ethernet-ports" (preferred) and "ports". Signed-off-by: Christian Eggers <ceggers@arri.de> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-25dt-bindings: net: dsa: convert ksz bindings document to yamlChristian Eggers
Convert the bindings document for Microchip KSZ Series Ethernet switches from txt to yaml. Removed spi-cpha and spi-cpol flags is this should be handled by the device driver. Signed-off-by: Christian Eggers <ceggers@arri.de> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-25Merge branch 'add-an-assert-in-napi_consume_skb'Jakub Kicinski
Yunsheng Lin says: ==================== Add an assert in napi_consume_skb() This patch introduces a lockdep_assert_in_softirq() interface and uses it to assert the case when napi_consume_skb() is not called in the softirq context. ==================== Link: https://lore.kernel.org/r/1606214969-97849-1-git-send-email-linyunsheng@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-25net: Use lockdep_assert_in_softirq() in napi_consume_skb()Yunsheng Lin
Use napi_consume_skb() to assert the case when it is not called in a atomic softirq context. Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-25lockdep: Introduce in_softirq lockdep assertYunsheng Lin
The current semantic for napi_consume_skb() is that caller need to provide non-zero budget when calling from NAPI context, and breaking this semantic will cause hard to debug problem, because _kfree_skb_defer() need to run in atomic context in order to push the skb to the particular cpu' napi_alloc_cache atomically. So add the lockdep_assert_in_softirq() to assert when the running context is not in_softirq, in_softirq means softirq is serving or BH is disabled, which has a ambiguous semantics due to the BH disabled confusion, so add a comment to emphasize that. And the softirq context can be interrupted by hard IRQ or NMI context, lockdep_assert_in_softirq() need to assert about hard IRQ or NMI context too. Suggested-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-25soc: qcom: ipa: Constify static qmi structsRikard Falkeborn
These are only used as input arguments to qmi_handle_init() which accepts const pointers to both qmi_ops and qmi_msg_handler. Make them const to allow the compiler to put them in read-only memory. Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Acked-by: Alex Elder <elder@linaro.org> Link: https://lore.kernel.org/r/20201122234031.33432-2-rikard.falkeborn@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-25mptcp: be careful on MPTCP-level ack.Paolo Abeni
We can enter the main mptcp_recvmsg() loop even when no subflows are connected. As note by Eric, that would result in a divide by zero oops on ack generation. Address the issue by checking the subflow status before sending the ack. Additionally protect mptcp_recvmsg() against invocation with weird socket states. v1 -> v2: - removed unneeded inline keyword - Jakub Reported-and-suggested-by: Eric Dumazet <eric.dumazet@gmail.com> Fixes: ea4ca586b16f ("mptcp: refine MPTCP-level ack scheduling") Signed-off-by: Paolo Abeni <pabeni@redhat.com> Link: https://lore.kernel.org/r/5370c0ae03449239e3d1674ddcfb090cf6f20abe.1606253206.git.pabeni@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-25bridge: mrp: Implement LC mode for MRPHoratiu Vultur
Extend MRP to support LC mode(link check) for the interconnect port. This applies only to the interconnect ring. Opposite to RC mode(ring check) the LC mode is using CFM frames to detect when the link goes up or down and based on that the userspace will need to react. One advantage of the LC mode over RC mode is that there will be fewer frames in the normal rings. Because RC mode generates InTest on all ports while LC mode sends CFM frame only on the interconnect port. All 4 nodes part of the interconnect ring needs to have the same mode. And it is not possible to have running LC and RC mode at the same time on a node. Whenever the MIM starts it needs to detect the status of the other 3 nodes in the interconnect ring so it would send a frame called InLinkStatus, on which the clients needs to reply with their link status. This patch adds InLinkStatus frame type and extends existing rules on how to forward this frame. Acked-by: Nikolay Aleksandrov <nikolay@nvidia.com> Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> Link: https://lore.kernel.org/r/20201124082525.273820-1-horatiu.vultur@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-25net: sched: alias action flags with TCA_ACT_ prefixVlad Buslov
Currently both filter and action flags use same "TCA_" prefix which makes them hard to distinguish to code and confusing for users. Create aliases for existing action flags constants with "TCA_ACT_" prefix. Signed-off-by: Vlad Buslov <vlad@buslov.dev> Link: https://lore.kernel.org/r/20201124164054.893168-1-vlad@buslov.dev Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-25mptcp: put reference in mptcp timeout timerFlorian Westphal
On close this timer might be scheduled. mptcp uses sk_reset_timer for this, so the a reference on the mptcp socket is taken. This causes a refcount leak which can for example be reproduced with 'mp_join_server_v4.pkt' from the mptcp-packetdrill repo. The leak has nothing to do with join requests, v1_mp_capable_bind_no_cs.pkt works too when replacing the last ack mpcapable to v1 instead of v0. unreferenced object 0xffff888109bba040 (size 2744): comm "packetdrill", [..] backtrace: [..] sk_prot_alloc.isra.0+0x2b/0xc0 [..] sk_clone_lock+0x2f/0x740 [..] mptcp_sk_clone+0x33/0x1a0 [..] subflow_syn_recv_sock+0x2b1/0x690 [..] Fixes: e16163b6e2b7 ("mptcp: refactor shutdown and close") Cc: Davide Caratti <dcaratti@redhat.com> Signed-off-by: Florian Westphal <fw@strlen.de> Acked-by: Paolo Abeni <pabeni@redhat.com> Link: https://lore.kernel.org/r/20201124162446.11448-1-fw@strlen.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-25net: phy: realtek: read actual speed on rtl8211f to detect downshiftAntonio Borneo
The rtl8211f supports downshift and before commit 5502b218e001 ("net: phy: use phy_resolve_aneg_linkmode in genphy_read_status") the read-back of register MII_CTRL1000 was used to detect the negotiated link speed. The code added in commit d445dff2df60 ("net: phy: realtek: read actual speed to detect downshift") is working fine also for this phy and it's trivial re-using it to restore the downshift detection on rtl8211f. Add the phy specific read_status() pointing to the existing function rtlgen_read_status(). Signed-off-by: Antonio Borneo <antonio.borneo@st.com> Link: https://lore.kernel.org/r/478f871a-583d-01f1-9cc5-2eea56d8c2a7@huawei.com Tested-by: Yonglong Liu <liuyonglong@huawei.com> Link: https://lore.kernel.org/r/20201124230756.887925-1-antonio.borneo@st.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-25Merge branch ↵Jakub Kicinski
'net-ptp-use-common-defines-for-ptp-message-types-in-further-drivers' Christian Eggers says: ==================== net: ptp: use common defines for PTP message types in further drivers This series replaces further driver internal enumeration / uses of magic numbers with the newly introduced PTP_MSGTYPE_* defines. ==================== Link: https://lore.kernel.org/r/20201124074418.2609-1-ceggers@arri.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-25net: phy: mscc: use new PTP_MSGTYPE_* definesChristian Eggers
Use recently introduced PTP_MSGTYPE_SYNC and PTP_MSGTYPE_DELAY_REQ defines instead of a driver internal enumeration. Signed-off-by: Christian Eggers <ceggers@arri.de> Reviewed-by: Antoine Tenart <atenart@kernel.org> Acked-by: Richard Cochran <richardcochran@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-25mlxsw: spectrum_ptp: use PTP wide message type definitionsChristian Eggers
Use recently introduced PTP wide defines instead of a driver internal enumeration. Signed-off-by: Christian Eggers <ceggers@arri.de> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Cc: Petr Machata <petrm@mellanox.com> Cc: Jiri Pirko <jiri@nvidia.com> Acked-by: Richard Cochran <richardcochran@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-25net: phy: dp83640: use new PTP_MSGTYPE_SYNC defineChristian Eggers
Replace use of magic number with recently introduced define. Signed-off-by: Christian Eggers <ceggers@arri.de> Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de> Acked-by: Richard Cochran <richardcochran@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-25Merge branch 'net-phy-add-support-for-shared-interrupts-part-3'Jakub Kicinski
Ioana Ciornei says: ==================== net: phy: add support for shared interrupts (part 3) 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 3 (and final) of the entire change set and it addresses the remaining PHY drivers that have not been migrated previosly. Also, it finally removed the .did_interrupt() and .ack_interrupt() callbacks since they are of no use anymore. 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. ==================== Link: https://lore.kernel.org/r/20201123153817.1616814-1-ciorneiioana@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-25net: phy: remove the .did_interrupt() and .ack_interrupt() callbackIoana Ciornei
Now that all the PHY drivers have been migrated to directly implement the generic .handle_interrupt() callback for a seamless support of shared IRQs and all the .config_inter() implementations clear any pending interrupts, we can safely remove the two callbacks. With this patch, phylib has a proper support for shared IRQs (and not just for multi-PHY devices. A PHY driver must implement both the .handle_interrupt() and .config_intr() callbacks for the IRQs to be actually used. Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-25net: phy: qsemi: remove the use of .ack_interrupt()Ioana Ciornei
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. Also, add a comment describing the multiple step interrupt acknoledgement process. Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-25net: phy: qsemi: implement generic .handle_interrupt() callbackIoana Ciornei
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 <ioana.ciornei@nxp.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-25net: phy: ti: remove the use of .ack_interrupt()Ioana Ciornei
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: Dan Murphy <dmurphy@ti.com> Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-25net: phy: ti: implement generic .handle_interrupt() callbackIoana Ciornei
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: Dan Murphy <dmurphy@ti.com> Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-25net: phy: national: remove the use of the .ack_interrupt()Ioana Ciornei
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 <ioana.ciornei@nxp.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-25net: phy: national: implement generic .handle_interrupt() callbackIoana Ciornei
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 <ioana.ciornei@nxp.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-25net: phy: micrel: remove the use of .ack_interrupt()Ioana Ciornei
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: Divya Koppera <Divya.Koppera@microchip.com> Cc: Oleksij Rempel <o.rempel@pengutronix.de> Cc: Philippe Schenker <philippe.schenker@toradex.com> Cc: Marek Vasut <marex@denx.de> Cc: Antoine Tenart <atenart@kernel.org> Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-25net: phy: micrel: implement generic .handle_interrupt() callbackIoana Ciornei
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: Divya Koppera <Divya.Koppera@microchip.com> Cc: Oleksij Rempel <o.rempel@pengutronix.de> Cc: Philippe Schenker <philippe.schenker@toradex.com> Cc: Marek Vasut <marex@denx.de> Cc: Antoine Tenart <atenart@kernel.org> Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-25net: phy: meson-gxl: remove the use of .ack_callback()Ioana Ciornei
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: Jerome Brunet <jbrunet@baylibre.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-25net: phy: meson-gxl: implement generic .handle_interrupt() callbackIoana Ciornei
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: Jerome Brunet <jbrunet@baylibre.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-25net: phy: icplus: remove the use .ack_interrupt()Ioana Ciornei
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> Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-25net: phy: icplus: implement generic .handle_interrupt() callbackIoana Ciornei
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> Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-25net: phy: intel-xway: remove the use of .ack_interrupt()Ioana Ciornei
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: Mathias Kresin <dev@kresin.me> Cc: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-25net: phy: intel-xway: implement generic .handle_interrupt() callbackIoana Ciornei
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: Mathias Kresin <dev@kresin.me> Cc: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-24lan743x: replace polling loop by wait_event_timeout()Sven Van Asbroeck
The driver's ISR sends a 'software interrupt' event to the probe() thread using the following method: - probe(): write 0 to flag, enable s/w interrupt - probe(): poll on flag, relax using usleep_range() - ISR : write 1 to flag Replace with wake_up() / wait_event_timeout(). Besides being easier to get right, this abstraction has better timing and memory consistency properties. Tested-by: Sven Van Asbroeck <thesven73@gmail.com> # lan7430 Signed-off-by: Sven Van Asbroeck <thesven73@gmail.com> Link: https://lore.kernel.org/r/20201123191529.14908-2-TheSven73@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-24lan743x: clean up software_isr functionSven Van Asbroeck
For no apparent reason, this function reads the INT_STS register, and checks if the software interrupt bit is set. These things have already been carried out by this function's only caller. Clean up by removing the redundant code. Tested-by: Sven Van Asbroeck <thesven73@gmail.com> # lan7430 Signed-off-by: Sven Van Asbroeck <thesven73@gmail.com> Link: https://lore.kernel.org/r/20201123191529.14908-1-TheSven73@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-24Merge branch 'mvneta-access-skb_shared_info-only-on-last-frag'Jakub Kicinski
Lorenzo Bianconi says: ==================== mvneta: access skb_shared_info only on last frag Build skb_shared_info on mvneta_rx_swbm stack and sync it to xdp_buff skb_shared_info area only on the last fragment. Avoid avoid unnecessary xdp_buff initialization in mvneta_rx_swbm routine. This a preliminary series to complete xdp multi-buff in mvneta driver. ==================== Link: https://lore.kernel.org/r/cover.1605889258.git.lorenzo@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-24net: mvneta: alloc skb_shared_info on the mvneta_rx_swbm stackLorenzo Bianconi
Build skb_shared_info on mvneta_rx_swbm stack and sync it to xdp_buff skb_shared_info area only on the last fragment. Leftover cache miss in mvneta_swbm_rx_frame will be addressed introducing mb bit in xdp_buff/xdp_frame struct Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-24net: mvneta: move skb_shared_info in mvneta_xdp_put_buff callerLorenzo Bianconi
Pass skb_shared_info pointer from mvneta_xdp_put_buff caller. This is a preliminary patch to reduce accesses to skb_shared_info area and reduce cache misses. Remove napi parameter in mvneta_xdp_put_buff signature since it is always run in NAPI context Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-24net: mvneta: avoid unnecessary xdp_buff initializationLorenzo Bianconi
Explicitly initialize mandatory fields defining xdp_buff struct in mvneta_rx_swbm routine Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-24net: mvpp2: divide fifo for dts-active ports onlyStefan Chulski
Tx/Rx FIFO is a HW resource limited by total size, but shared by all ports of same CP110 and impacting port-performance. Do not divide the FIFO for ports which are not enabled in DTS, so active ports could have more FIFO. No change in FIFO allocation if all 3 ports on the communication processor enabled in DTS. The active port mapping should be done in probe before FIFO-init. Signed-off-by: Stefan Chulski <stefanc@marvell.com> Reviewed-by: Russell King <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/1606154073-28267-1-git-send-email-stefanc@marvell.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-24net: page_pool: Add page_pool_put_page_bulk() to page_pool.rstLorenzo Bianconi
Introduce page_pool_put_page_bulk() entry into the API section of page_pool.rst Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://lore.kernel.org/r/a6a5141b4d7b7b71fa7778b16b48f80095dd3233.1606146163.git.lorenzo@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-24net: warn if gso_type isn't set for a GSO SKBHeiner Kallweit
In bug report [0] a warning in r8169 driver was reported that was caused by an invalid GSO SKB (gso_type was 0). See [1] for a discussion about this issue. Still the origin of the invalid GSO SKB isn't clear. It shouldn't be a network drivers task to check for invalid GSO SKB's. Also, even if issue [0] can be fixed, we can't be sure that a similar issue doesn't pop up again at another place. Therefore let gso_features_check() check for such invalid GSO SKB's. [0] https://bugzilla.kernel.org/show_bug.cgi?id=209423 [1] https://www.spinics.net/lists/netdev/msg690794.html Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/r/97c78d21-7f0b-d843-df17-3589f224d2cf@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-24net: hns3: fix spelling mistake "memroy" -> "memory"Colin Ian King
There are spelling mistakes in two dev_err messages. Fix them. Signed-off-by: Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20201123103452.197708-1-colin.king@canonical.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-24Merge branch 'mlxsw-add-support-for-blackhole-nexthops'Jakub Kicinski
Ido Schimmel says: ==================== mlxsw: Add support for blackhole nexthops This patch set adds support for blackhole nexthops in mlxsw. These nexthops are exactly the same as other nexthops, but instead of forwarding packets to an egress router interface (RIF), they are programmed to silently drop them. Patches #1-#4 are preparations. Patch #5 adds support for blackhole nexthops and removes the check that prevented them from being programmed. Patch #6 adds a selftests over mlxsw which tests that blackhole nexthops can be programmed and are marked as offloaded. Patch #7 extends the existing nexthop forwarding test to also test blackhole functionality. Patches #8-#10 add support for a new packet trap ('blackhole_nexthop') which should be triggered whenever packets are dropped by a blackhole nexthop. Obviously, by default, the trap action is set to 'drop' so that dropped packets will not be reported. ==================== Link: https://lore.kernel.org/r/20201123071230.676469-1-idosch@idosch.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-24selftests: mlxsw: Add blackhole_nexthop trap testIdo Schimmel
Test that packets hitting a blackhole nexthop are trapped to the CPU when the trap is enabled. Test that packets are not reported when the trap is disabled. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-24mlxsw: spectrum_trap: Add blackhole_nexthop trapIdo Schimmel
Register with devlink the blackhole_nexthop trap so that mlxsw will be able to report packets dropped due to a blackhole nexthop. The internal trap identifier is "DISCARD_ROUTER3", which traps packets dropped in the adjacency table. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-24devlink: Add blackhole_nexthop trapIdo Schimmel
Add a packet trap to report packets that were dropped due to a blackhole nexthop. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>