OSDN Git Service
Jakub Kicinski [Thu, 26 Nov 2020 02:11:25 +0000 (18:11 -0800)]
Merge branch '40GbE' of git://git./linux/kernel/git/tnguy/next-queue
Tony Nguyen says:
====================
40GbE Intel Wired LAN Driver Updates 2020-11-24
This series contains updates to i40e and igbvf drivers.
Marek removes a redundant assignment for i40e.
Stefan Assmann corrects reporting of VF link speed for i40e.
Karen revises a couple of error messages to warnings for igbvf as they
could be misinterpreted as issues when they are not.
v2: Dropped PTP patch as it's being updated.
* '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue:
igbvf: Refactor traces
i40e: report correct VF link speed when link state is set to enable
i40e: remove redundant assignment
====================
Link: https://lore.kernel.org/r/20201124165245.2844118-1-anthony.l.nguyen@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jakub Kicinski [Thu, 26 Nov 2020 01:58:09 +0000 (17:58 -0800)]
Merge branch 'net-dsa-mv88e6xxx-serdes-link-without-phy'
Chris Packham says:
====================
net: dsa: mv88e6xxx: serdes link without phy
This small series gets my hardware into a working state. The key points are to
make sure we don't force the link and that we ask the MAC for the link status.
I also have updated my dts to say `phy-mode = "1000base-x";` and `managed =
"in-band-status";`
I've dropped the patch for the
88E6123 as it's a distraction and I lack
hardware to do any proper testing with it. Earlier versions are on the mailing
list if anyone wants to pick it up in the future.
I notice there's a series for mv88e6393x circulating on the netdev mailing
list. As patch #1 is adding a new device specific op either this series will
need updating to cover the mv88e6393x or the mv88e6393x series will need
updating for the new op depenting on which lands first.
====================
Link: https://lore.kernel.org/r/20201124043440.28400-1-chris.packham@alliedtelesis.co.nz
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Chris Packham [Tue, 24 Nov 2020 04:34:40 +0000 (17:34 +1300)]
net: dsa: mv88e6xxx: Handle error in serdes_get_regs
If the underlying read operation failed we would end up writing stale
data to the supplied buffer. This would end up with the last
successfully read value repeating. Fix this by only writing the data
when we know the read was good. This will mean that failed values will
return 0xffff.
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>
Chris Packham [Tue, 24 Nov 2020 04:34:39 +0000 (17:34 +1300)]
net: dsa: mv88e6xxx: Add serdes interrupt support for MV88E6097
The MV88E6097 presents the serdes interrupts for ports 8 and 9 via the
Switch Global 2 registers. There is no additional layer of
enablinh/disabling the serdes interrupts like other mv88e6xxx switches.
Even though most of the serdes behaviour is the same as the MV88E6185
that chip does not provide interrupts for serdes events so unlike
earlier commits the functions added here are specific to the MV88E6097.
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>
Chris Packham [Tue, 24 Nov 2020 04:34:38 +0000 (17:34 +1300)]
net: dsa: mv88e6xxx: Support serdes ports on MV88E6097/6095/6185
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>
Chris Packham [Tue, 24 Nov 2020 04:34:37 +0000 (17:34 +1300)]
net: dsa: mv88e6xxx: Don't force link when using in-band-status
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>
Jakub Kicinski [Thu, 26 Nov 2020 01:55:26 +0000 (17:55 -0800)]
Merge branch 'dt-bindings-net-dsa-microchip-convert-ksz-bindings-to-yaml'
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>
Christian Eggers [Fri, 20 Nov 2020 11:21:07 +0000 (12:21 +0100)]
net: dsa: microchip: ksz8795: setup SPI mode
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>
Christian Eggers [Fri, 20 Nov 2020 11:21:06 +0000 (12:21 +0100)]
net: dsa: microchip: ksz9477: setup SPI mode
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>
Christian Eggers [Fri, 20 Nov 2020 11:21:05 +0000 (12:21 +0100)]
net: dsa: microchip: support for "ethernet-ports" node
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>
Christian Eggers [Fri, 20 Nov 2020 11:21:04 +0000 (12:21 +0100)]
dt-bindings: net: dsa: convert ksz bindings document to yaml
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>
Jakub Kicinski [Wed, 25 Nov 2020 23:08:39 +0000 (15:08 -0800)]
Merge branch 'add-an-assert-in-napi_consume_skb'
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>
Yunsheng Lin [Tue, 24 Nov 2020 10:49:29 +0000 (18:49 +0800)]
net: Use lockdep_assert_in_softirq() in napi_consume_skb()
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>
Yunsheng Lin [Tue, 24 Nov 2020 10:49:28 +0000 (18:49 +0800)]
lockdep: Introduce in_softirq lockdep assert
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>
Rikard Falkeborn [Sun, 22 Nov 2020 23:40:30 +0000 (00:40 +0100)]
soc: qcom: ipa: Constify static qmi structs
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>
Paolo Abeni [Tue, 24 Nov 2020 21:51:24 +0000 (22:51 +0100)]
mptcp: be careful on MPTCP-level ack.
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>
Horatiu Vultur [Tue, 24 Nov 2020 08:25:25 +0000 (09:25 +0100)]
bridge: mrp: Implement LC mode for MRP
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>
Vlad Buslov [Tue, 24 Nov 2020 16:40:54 +0000 (18:40 +0200)]
net: sched: alias action flags with TCA_ACT_ prefix
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>
Florian Westphal [Tue, 24 Nov 2020 16:24:46 +0000 (17:24 +0100)]
mptcp: put reference in mptcp timeout timer
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>
Antonio Borneo [Tue, 24 Nov 2020 23:07:56 +0000 (00:07 +0100)]
net: phy: realtek: read actual speed on rtl8211f to detect downshift
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>
Jakub Kicinski [Wed, 25 Nov 2020 20:23:26 +0000 (12:23 -0800)]
Merge branch '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>
Christian Eggers [Tue, 24 Nov 2020 07:44:18 +0000 (08:44 +0100)]
net: phy: mscc: use new PTP_MSGTYPE_* defines
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>
Christian Eggers [Tue, 24 Nov 2020 07:44:17 +0000 (08:44 +0100)]
mlxsw: spectrum_ptp: use PTP wide message type definitions
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>
Christian Eggers [Tue, 24 Nov 2020 07:44:16 +0000 (08:44 +0100)]
net: phy: dp83640: use new PTP_MSGTYPE_SYNC define
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>
Jakub Kicinski [Wed, 25 Nov 2020 19:18:41 +0000 (11:18 -0800)]
Merge branch 'net-phy-add-support-for-shared-interrupts-part-3'
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>
Ioana Ciornei [Mon, 23 Nov 2020 15:38:17 +0000 (17:38 +0200)]
net: phy: remove the .did_interrupt() and .ack_interrupt() callback
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>
Ioana Ciornei [Mon, 23 Nov 2020 15:38:16 +0000 (17:38 +0200)]
net: phy: qsemi: remove the use of .ack_interrupt()
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>
Ioana Ciornei [Mon, 23 Nov 2020 15:38:15 +0000 (17:38 +0200)]
net: phy: qsemi: implement generic .handle_interrupt() callback
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>
Ioana Ciornei [Mon, 23 Nov 2020 15:38:14 +0000 (17:38 +0200)]
net: phy: ti: remove the use of .ack_interrupt()
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>
Ioana Ciornei [Mon, 23 Nov 2020 15:38:13 +0000 (17:38 +0200)]
net: phy: ti: implement generic .handle_interrupt() callback
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>
Ioana Ciornei [Mon, 23 Nov 2020 15:38:12 +0000 (17:38 +0200)]
net: phy: national: remove the use of the .ack_interrupt()
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>
Ioana Ciornei [Mon, 23 Nov 2020 15:38:11 +0000 (17:38 +0200)]
net: phy: national: implement generic .handle_interrupt() callback
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>
Ioana Ciornei [Mon, 23 Nov 2020 15:38:10 +0000 (17:38 +0200)]
net: phy: micrel: remove the use of .ack_interrupt()
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>
Ioana Ciornei [Mon, 23 Nov 2020 15:38:09 +0000 (17:38 +0200)]
net: phy: micrel: implement generic .handle_interrupt() callback
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>
Ioana Ciornei [Mon, 23 Nov 2020 15:38:08 +0000 (17:38 +0200)]
net: phy: meson-gxl: remove the use of .ack_callback()
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>
Ioana Ciornei [Mon, 23 Nov 2020 15:38:07 +0000 (17:38 +0200)]
net: phy: meson-gxl: implement generic .handle_interrupt() callback
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>
Ioana Ciornei [Mon, 23 Nov 2020 15:38:06 +0000 (17:38 +0200)]
net: phy: icplus: remove the use .ack_interrupt()
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>
Ioana Ciornei [Mon, 23 Nov 2020 15:38:05 +0000 (17:38 +0200)]
net: phy: icplus: implement generic .handle_interrupt() callback
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>
Ioana Ciornei [Mon, 23 Nov 2020 15:38:04 +0000 (17:38 +0200)]
net: phy: intel-xway: remove the use of .ack_interrupt()
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>
Ioana Ciornei [Mon, 23 Nov 2020 15:38:03 +0000 (17:38 +0200)]
net: phy: intel-xway: implement generic .handle_interrupt() callback
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>
Sven Van Asbroeck [Mon, 23 Nov 2020 19:15:29 +0000 (14:15 -0500)]
lan743x: replace polling loop by wait_event_timeout()
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>
Sven Van Asbroeck [Mon, 23 Nov 2020 19:15:28 +0000 (14:15 -0500)]
lan743x: clean up software_isr function
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>
Jakub Kicinski [Tue, 24 Nov 2020 23:09:48 +0000 (15:09 -0800)]
Merge branch 'mvneta-access-skb_shared_info-only-on-last-frag'
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>
Lorenzo Bianconi [Fri, 20 Nov 2020 17:05:44 +0000 (18:05 +0100)]
net: mvneta: alloc skb_shared_info on the mvneta_rx_swbm stack
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>
Lorenzo Bianconi [Fri, 20 Nov 2020 17:05:43 +0000 (18:05 +0100)]
net: mvneta: move skb_shared_info in mvneta_xdp_put_buff caller
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>
Lorenzo Bianconi [Fri, 20 Nov 2020 17:05:42 +0000 (18:05 +0100)]
net: mvneta: avoid unnecessary xdp_buff initialization
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>
Stefan Chulski [Mon, 23 Nov 2020 17:54:33 +0000 (19:54 +0200)]
net: mvpp2: divide fifo for dts-active ports only
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>
Lorenzo Bianconi [Mon, 23 Nov 2020 15:45:46 +0000 (16:45 +0100)]
net: page_pool: Add page_pool_put_page_bulk() to page_pool.rst
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>
Heiner Kallweit [Fri, 20 Nov 2020 23:22:20 +0000 (00:22 +0100)]
net: warn if gso_type isn't set for a GSO SKB
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>
Colin Ian King [Mon, 23 Nov 2020 10:34:52 +0000 (10:34 +0000)]
net: hns3: fix spelling mistake "memroy" -> "memory"
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>
Jakub Kicinski [Tue, 24 Nov 2020 20:15:00 +0000 (12:15 -0800)]
Merge branch 'mlxsw-add-support-for-blackhole-nexthops'
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>
Ido Schimmel [Mon, 23 Nov 2020 07:12:30 +0000 (09:12 +0200)]
selftests: mlxsw: Add blackhole_nexthop trap test
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>
Ido Schimmel [Mon, 23 Nov 2020 07:12:29 +0000 (09:12 +0200)]
mlxsw: spectrum_trap: Add blackhole_nexthop trap
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>
Ido Schimmel [Mon, 23 Nov 2020 07:12:28 +0000 (09:12 +0200)]
devlink: Add blackhole_nexthop trap
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>
Ido Schimmel [Mon, 23 Nov 2020 07:12:27 +0000 (09:12 +0200)]
selftests: forwarding: Add blackhole nexthops tests
Test that IPv4 and IPv6 ping fail when the route is using a blackhole
nexthop or a group with a blackhole nexthop. Test that ping passes when
the route starts using a valid nexthop.
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Ido Schimmel [Mon, 23 Nov 2020 07:12:26 +0000 (09:12 +0200)]
selftests: mlxsw: Add blackhole nexthop configuration tests
Test the mlxsw allows blackhole nexthops to be installed and that the
nexthops are marked as offloaded.
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Ido Schimmel [Mon, 23 Nov 2020 07:12:25 +0000 (09:12 +0200)]
mlxsw: spectrum_router: Add support for blackhole nexthops
Add support for blackhole nexthops by programming them to the adjacency
table with a discard action.
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Ido Schimmel [Mon, 23 Nov 2020 07:12:24 +0000 (09:12 +0200)]
mlxsw: spectrum_router: Resolve RIF from nexthop struct instead of neighbour
The two are the same, but for blackhole nexthops we will not have an
associated neighbour struct, so resolve the RIF from the nexthop struct
itself instead.
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Ido Schimmel [Mon, 23 Nov 2020 07:12:23 +0000 (09:12 +0200)]
mlxsw: spectrum_router: Use loopback RIF for unresolved nexthops
Now that the driver creates a loopback RIF during its initialization, it
can be used to program the adjacency entries for unresolved nexthops
instead of other RIFs. The loopback RIF is guaranteed to exist for the
entire life time of the driver, unlike other RIFs that come and go.
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Ido Schimmel [Mon, 23 Nov 2020 07:12:22 +0000 (09:12 +0200)]
mlxsw: spectrum_router: Use different trap identifier for unresolved nexthops
Unresolved nexthops are currently written to the adjacency table with a
discard action. Packets hitting such entries are trapped to the CPU via
the 'DISCARD_ROUTER3' trap which can be enabled or disabled on demand,
but is always enabled in order to ensure the kernel can resolve the
unresolved neighbours.
This trap will be needed for blackhole nexthops support. Therefore, move
unresolved nexthops to explicitly program the adjacency entries with a
trap action and a different trap identifier, 'RTR_EGRESS0'.
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Ido Schimmel [Mon, 23 Nov 2020 07:12:21 +0000 (09:12 +0200)]
mlxsw: spectrum_router: Create loopback RIF during initialization
Up until now RIFs (router interfaces) were created on demand (e.g.,
when an IP address was added to a netdev). However, sometimes the device
needs to be provided with a RIF when one might not be available.
For example, adjacency entries that drop packets need to be programmed
with an egress RIF despite the RIF not being used to forward packets.
Create such a RIF during initialization so that it could be used later
on to support blackhole nexthops.
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jakub Kicinski [Tue, 24 Nov 2020 20:05:58 +0000 (12:05 -0800)]
Merge tag 'rxrpc-next-
20201123' of git://git./linux/kernel/git/dhowells/linux-fs
David Howells says:
====================
rxrpc: Prelude to gssapi support
Here are some patches that do some reorganisation of the security class
handling in rxrpc to allow implementation of the RxGK security class that
will allow AF_RXRPC to use GSSAPI-negotiated tokens and better crypto. The
RxGK security class is not included in this patchset.
It does the following things:
(1) Add a keyrings patch to provide the original key description, as
provided to add_key(), to the payload preparser so that it can
interpret the content on that basis. Unfortunately, the rxrpc_s key
type wasn't written to interpret its payload as anything other than a
string of bytes comprising a key, but for RxGK, more information is
required as multiple Kerberos enctypes are supported.
(2) Remove the rxk5 security class key parsing. The rxk5 class never got
rolled out in OpenAFS and got replaced with rxgk.
(3) Support the creation of rxrpc keys with multiple tokens of different
types. If some types are not supported, the ENOPKG error is
suppressed if at least one other token's type is supported.
(4) Punt the handling of server keys (rxrpc_s type) to the appropriate
security class.
(5) Organise the security bits in the rxrpc_connection struct into a
union to make it easier to override for other classes.
(6) Move some bits from core code into rxkad that won't be appropriate to
rxgk.
* tag 'rxrpc-next-
20201123' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs:
rxrpc: Ask the security class how much space to allow in a packet
rxrpc: rxkad: Don't use pskb_pull() to advance through the response packet
rxrpc: Organise connection security to use a union
rxrpc: Don't reserve security header in Tx DATA skbuff
rxrpc: Merge prime_packet_security into init_connection_security
rxrpc: Fix example key name in a comment
rxrpc: Ignore unknown tokens in key payload unless no known tokens
rxrpc: Make the parsing of xdr payloads more coherent
rxrpc: Allow security classes to give more info on server keys
rxrpc: Don't leak the service-side session key to userspace
rxrpc: Hand server key parsing off to the security class
rxrpc: Split the server key type (rxrpc_s) into its own file
rxrpc: Don't retain the server key in the connection
rxrpc: Support keys with multiple authentication tokens
rxrpc: List the held token types in the key description in /proc/keys
rxrpc: Remove the rxk5 security class as it's now defunct
keys: Provide the original description to the key preparser
====================
Link: https://lore.kernel.org/r/160616220405.830164.2239716599743995145.stgit@warthog.procyon.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Vincent Whitchurch [Fri, 20 Nov 2020 15:02:08 +0000 (16:02 +0100)]
net: stmmac: Use hrtimer for TX coalescing
This driver uses a normal timer for TX coalescing, which means that the
with the default tx-usecs of 1000 microseconds the cleanups actually
happen 10 ms or more later with HZ=100. This leads to very low
througput with TCP when bridged to a slow link such as a 4G modem. Fix
this by using an hrtimer instead.
On my ARM platform with HZ=100 and the default TX coalescing settings
(tx-frames 25 tx-usecs 1000), with "tc qdisc add dev eth0 root netem
delay 60ms 40ms rate 50Mbit" run on the server, netperf's TCP_STREAM
improves from ~5.5 Mbps to ~100 Mbps.
Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
Link: https://lore.kernel.org/r/20201120150208.6838-1-vincent.whitchurch@axis.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Karen Sornek [Thu, 10 Sep 2020 10:36:19 +0000 (12:36 +0200)]
igbvf: Refactor traces
Refactoring "PF still resetting" and changing "Failed
to add vlan id" to "Vlan id is not added"
messages because previous version looked like a bug
- it informed about changes that worked as
designed but might confuse users
Signed-off-by: Karen Sornek <karen.sornek@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Stefan Assmann [Wed, 9 Sep 2020 08:22:12 +0000 (10:22 +0200)]
i40e: report correct VF link speed when link state is set to enable
When the virtual link state was set to "enable" ethtool would report
link speed as 40000Mb/s regardless of the underlying device.
Report the correct link speed.
Example from a XXV710 NIC.
Before:
$ ip link set ens3f0 vf 0 state auto
$ ethtool enp8s2 | grep Speed
Speed: 25000Mb/s
$ ip link set ens3f0 vf 0 state enable
$ ethtool enp8s2 | grep Speed
Speed: 40000Mb/s
After:
$ ip link set ens3f0 vf 0 state auto
$ ethtool enp8s2 | grep Speed
Speed: 25000Mb/s
$ ip link set ens3f0 vf 0 state enable
$ ethtool enp8s2 | grep Speed
Speed: 25000Mb/s
Signed-off-by: Stefan Assmann <sassmann@kpanic.de>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Marek Majtyka [Tue, 8 Sep 2020 12:34:40 +0000 (14:34 +0200)]
i40e: remove redundant assignment
Remove a redundant assignment of the software ring pointer in the i40e
driver. The variable is assigned twice with no use in between, so just
get rid of the first occurrence.
Fixes:
3b4f0b66c2b3 ("i40e, xsk: Migrate to new MEM_TYPE_XSK_BUFF_POOL")
Signed-off-by: Marek Majtyka <marekx.majtyka@intel.com>
Acked-by: Björn Töpel <bjorn.topel@intel.com>
Tested-by: George Kuruvinakunnel <george.kuruvinakunnel@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Christophe JAILLET [Sun, 22 Nov 2020 18:07:04 +0000 (19:07 +0100)]
sctp: Fix some typo
s/tranport/transport/
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/20201122180704.1366636-1-christophe.jaillet@wanadoo.fr
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jakub Kicinski [Fri, 20 Nov 2020 22:50:52 +0000 (14:50 -0800)]
net: don't include ethtool.h from netdevice.h
linux/netdevice.h is included in very many places, touching any
of its dependecies causes large incremental builds.
Drop the linux/ethtool.h include, linux/netdevice.h just needs
a forward declaration of struct ethtool_ops.
Fix all the places which made use of this implicit include.
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Acked-by: Shannon Nelson <snelson@pensando.io>
Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Link: https://lore.kernel.org/r/20201120225052.1427503-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Christophe JAILLET [Sat, 21 Nov 2020 09:03:30 +0000 (10:03 +0100)]
net: pch_gbe: Use 'dma_free_coherent()' to undo 'dma_alloc_coherent()'
Memory allocation are done with 'dma_alloc_coherent()'. Be consistent
and use 'dma_free_coherent()' to free the corresponding memory.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/20201121090330.1332543-1-christophe.jaillet@wanadoo.fr
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Christophe JAILLET [Sat, 21 Nov 2020 09:03:02 +0000 (10:03 +0100)]
net: pch_gbe: Use dma_set_mask_and_coherent to simplify code
'pci_set_dma_mask()' + 'pci_set_consistent_dma_mask()' can be replaced by
an equivalent 'dma_set_mask_and_coherent()' which is much less verbose.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/20201121090302.1332491-1-christophe.jaillet@wanadoo.fr
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jakub Kicinski [Tue, 24 Nov 2020 00:57:23 +0000 (16:57 -0800)]
Merge branch 'net-dsa-hellcreek-minor-cleanups'
Kurt Kanzenbach says:
====================
net: dsa: hellcreek: Minor cleanups
fix two minor issues in the hellcreek driver.
====================
Link: https://lore.kernel.org/r/20201121114455.22422-1-kurt@linutronix.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Kurt Kanzenbach [Sat, 21 Nov 2020 11:44:55 +0000 (12:44 +0100)]
net: dsa: hellcreek: Don't print error message on defer
When DSA is not loaded when the driver is probed an error message is
printed. But, that's not really an error, just a defer. Use dev_err_probe()
instead.
Signed-off-by: Kurt Kanzenbach <kurt@linutronix.de>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Kurt Kanzenbach [Sat, 21 Nov 2020 11:44:54 +0000 (12:44 +0100)]
net: dsa: tag_hellcreek: Cleanup includes
Remove unused and add needed includes. No functional change.
Suggested-by: Vladimir Oltean <olteanv@gmail.com>
Signed-off-by: Kurt Kanzenbach <kurt@linutronix.de>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jakub Kicinski [Mon, 23 Nov 2020 21:43:48 +0000 (13:43 -0800)]
Merge branch 'net-ptp-introduce-common-defines-for-ptp-message-types'
Christian Eggers says:
====================
net: ptp: introduce common defines for PTP message types
This series introduces commen defines for PTP event messages. Driver
internal defines are removed and some uses of magic numbers are replaced
by the new defines.
====================
Link: https://lore.kernel.org/r/20201120084106.10046-1-ceggers@arri.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Christian Eggers [Fri, 20 Nov 2020 08:41:06 +0000 (09:41 +0100)]
ptp: ptp_ines: use new PTP_MSGTYPE_* define(s)
Remove driver internal defines for this. Masking msgtype with 0xf is
already done within ptp_get_msgtype().
Signed-off-by: Christian Eggers <ceggers@arri.de>
Cc: Kurt Kanzenbach <kurt@linutronix.de>
Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
Reviewed-by: Richard Cochran <richardcochran@gmail.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Christian Eggers [Fri, 20 Nov 2020 08:41:05 +0000 (09:41 +0100)]
dpaa2-eth: use new PTP_MSGTYPE_* define(s)
Remove usage of magic numbers.
Signed-off-by: Christian Eggers <ceggers@arri.de>
Cc: Ioana Ciornei <ioana.ciornei@nxp.com>
Cc: Ioana Radulescu <ruxandra.radulescu@nxp.com>
Cc: Yangbo Lu <yangbo.lu@nxp.com>
Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
Reviewed-by: Richard Cochran <richardcochran@gmail.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Christian Eggers [Fri, 20 Nov 2020 08:41:04 +0000 (09:41 +0100)]
net: ptp: introduce common defines for PTP message types
Using PTP wide defines will obsolete different driver internal defines
and uses of magic numbers.
Signed-off-by: Christian Eggers <ceggers@arri.de>
Cc: Kurt Kanzenbach <kurt@linutronix.de>
Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
Reviewed-by: Richard Cochran <richardcochran@gmail.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jakub Kicinski [Sat, 21 Nov 2020 21:48:44 +0000 (13:48 -0800)]
compat: always include linux/compat.h from net/compat.h
We're about to do reshuffling in networking headers and
eliminate some implicit includes. This results in:
In file included from ../net/ipv4/netfilter/arp_tables.c:26:
include/net/compat.h:60:40: error: unknown type name ‘compat_uptr_t’; did you mean ‘compat_ptr_ioctl’?
struct sockaddr __user **save_addr, compat_uptr_t *ptr,
^~~~~~~~~~~~~
compat_ptr_ioctl
include/net/compat.h:61:4: error: unknown type name ‘compat_size_t’; did you mean ‘compat_sigset_t’?
compat_size_t *len);
^~~~~~~~~~~~~
compat_sigset_t
Currently net/compat.h depends on linux/compat.h being included
first. After the upcoming changes this would break the 32bit build.
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20201121214844.1488283-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
David Howells [Wed, 16 Sep 2020 00:34:39 +0000 (01:34 +0100)]
rxrpc: Ask the security class how much space to allow in a packet
Ask the security class how much header and trailer space to allow for when
allocating a packet, given how much data is remaining.
This will allow the rxgk security class to stick both a trailer in as well
as a header as appropriate in the future.
Signed-off-by: David Howells <dhowells@redhat.com>
Martin Schiller [Wed, 18 Nov 2020 06:39:19 +0000 (07:39 +0100)]
net/tun: Call type change netdev notifiers
Call netdev notifiers before and after changing the device type.
Signed-off-by: Martin Schiller <ms@dev.tdt.de>
Link: https://lore.kernel.org/r/20201118063919.29485-1-ms@dev.tdt.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
David Howells [Tue, 29 Sep 2020 20:48:50 +0000 (21:48 +0100)]
rxrpc: rxkad: Don't use pskb_pull() to advance through the response packet
In the rxkad security class, don't use pskb_pull() to advance through the
contents of the response packet. There's no point, especially as the next
and last access to the skbuff still has to allow for the wire header in the
offset (which we didn't advance over).
Better to just add the displacement to the next offset.
Signed-off-by: David Howells <dhowells@redhat.com>
David Howells [Tue, 22 Sep 2020 12:36:17 +0000 (13:36 +0100)]
rxrpc: Organise connection security to use a union
Organise the security information in the rxrpc_connection struct to use a
union to allow for different data for different security classes.
Signed-off-by: David Howells <dhowells@redhat.com>
David Howells [Thu, 17 Sep 2020 22:23:38 +0000 (23:23 +0100)]
rxrpc: Don't reserve security header in Tx DATA skbuff
Insert the security header into the skbuff representing a DATA packet to be
transmitted rather than using skb_reserve() when the packet is allocated.
This makes it easier to apply crypto that spans the security header and the
data, particularly in the upcoming RxGK class where we have a common
encrypt-and-checksum function that is used in a number of circumstances.
Signed-off-by: David Howells <dhowells@redhat.com>
David Howells [Wed, 16 Sep 2020 00:38:15 +0000 (01:38 +0100)]
rxrpc: Merge prime_packet_security into init_connection_security
Merge the ->prime_packet_security() into the ->init_connection_security()
hook as they're always called together.
Signed-off-by: David Howells <dhowells@redhat.com>
David Howells [Thu, 15 Oct 2020 14:47:45 +0000 (15:47 +0100)]
rxrpc: Fix example key name in a comment
Fix an example of an rxrpc key name in a comment.
Signed-off-by: David Howells <dhowells@redhat.com>
David Howells [Thu, 15 Oct 2020 14:59:36 +0000 (15:59 +0100)]
rxrpc: Ignore unknown tokens in key payload unless no known tokens
When parsing a payload for an rxrpc-type key, ignore any tokens that are
not of a known type and don't give an error for them - unless there are no
tokens of a known type.
Signed-off-by: David Howells <dhowells@redhat.com>
David Howells [Sun, 27 Sep 2020 10:17:03 +0000 (11:17 +0100)]
rxrpc: Make the parsing of xdr payloads more coherent
Make the parsing of xdr-encoded payloads, as passed to add_key, more
coherent. Shuttling back and forth between various variables was a bit
hard to follow.
Signed-off-by: David Howells <dhowells@redhat.com>
David Howells [Sun, 27 Sep 2020 10:13:04 +0000 (11:13 +0100)]
rxrpc: Allow security classes to give more info on server keys
Allow a security class to give more information on an rxrpc_s-type key when
it is viewed in /proc/keys. This will allow the upcoming RxGK security
class to show the enctype name here.
Signed-off-by: David Howells <dhowells@redhat.com>
David Howells [Sun, 27 Sep 2020 10:07:21 +0000 (11:07 +0100)]
rxrpc: Don't leak the service-side session key to userspace
Don't let someone reading a service-side rxrpc-type key get access to the
session key that was exchanged with the client. The server application
will, at some point, need to be able to read the information in the ticket,
but this probably shouldn't include the key material.
Signed-off-by: David Howells <dhowells@redhat.com>
David Howells [Wed, 16 Sep 2020 07:37:29 +0000 (08:37 +0100)]
rxrpc: Hand server key parsing off to the security class
Hand responsibility for parsing a server key off to the security class. We
can determine which class from the description. This is necessary as rxgk
server keys have different lookup requirements and different content
requirements (dependent on crypto type) to those of rxkad server keys.
Signed-off-by: David Howells <dhowells@redhat.com>
David Howells [Wed, 16 Sep 2020 07:25:08 +0000 (08:25 +0100)]
rxrpc: Split the server key type (rxrpc_s) into its own file
Split the server private key type (rxrpc_s) out into its own file rather
than mingling it with the authentication/client key type (rxrpc) since they
don't really bear any relation.
Signed-off-by: David Howells <dhowells@redhat.com>
David Howells [Wed, 16 Sep 2020 07:00:44 +0000 (08:00 +0100)]
rxrpc: Don't retain the server key in the connection
Don't retain a pointer to the server key in the connection, but rather get
it on demand when the server has to deal with a response packet.
This is necessary to implement RxGK (GSSAPI-mediated transport class),
where we can't know which key we'll need until we've challenged the client
and got back the response.
This also means that we don't need to do a key search in the accept path in
softirq mode.
Also, whilst we're at it, allow the security class to ask for a kvno and
encoding-type variant of a server key as RxGK needs different keys for
different encoding types. Keys of this type have an extra bit in the
description:
"<service-id>:<security-index>:<kvno>:<enctype>"
Signed-off-by: David Howells <dhowells@redhat.com>
David Howells [Wed, 16 Sep 2020 07:19:12 +0000 (08:19 +0100)]
rxrpc: Support keys with multiple authentication tokens
rxrpc-type keys can have multiple tokens attached for different security
classes. Currently, rxrpc always picks the first one, whether or not the
security class it indicates is supported.
Add preliminary support for choosing which security class will be used
(this will need to be directed from a higher layer) and go through the
tokens to find one that's supported.
Signed-off-by: David Howells <dhowells@redhat.com>
David Howells [Tue, 8 Sep 2020 21:30:52 +0000 (22:30 +0100)]
rxrpc: List the held token types in the key description in /proc/keys
When viewing an rxrpc-type key through /proc/keys, display a list of held
token types.
Signed-off-by: David Howells <dhowells@redhat.com>
David Howells [Thu, 3 Sep 2020 07:21:58 +0000 (08:21 +0100)]
rxrpc: Remove the rxk5 security class as it's now defunct
Remove the rxrpc rxk5 security class as it's now defunct and nothing uses
it anymore.
Signed-off-by: David Howells <dhowells@redhat.com>
David Howells [Wed, 16 Sep 2020 10:12:03 +0000 (11:12 +0100)]
keys: Provide the original description to the key preparser
Provide the proposed description (add key) or the original description
(update/instantiate key) when preparsing a key so that the key type can
validate it against the data.
This is important for rxrpc server keys as we need to check that they have
the right amount of key material present - and it's better to do that when
the key is loaded rather than deep in trying to process a response packet.
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
cc: keyrings@vger.kernel.org
George Cherian [Fri, 20 Nov 2020 09:39:06 +0000 (15:09 +0530)]
octeontx2-af: Add support for RSS hashing based on Transport protocol field
Add support to choose RSS flow key algorithm with IPv4 transport protocol
field included in hashing input data. This will be enabled by default.
There-by enabling 3/5 tuple hash
Signed-off-by: Sunil Kovvuri Goutham <sgoutham@marvell.com>
Signed-off-by: George Cherian <george.cherian@marvell.com>
Link: https://lore.kernel.org/r/20201120093906.2873616-1-george.cherian@marvell.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jakub Kicinski [Sat, 21 Nov 2020 22:58:11 +0000 (14:58 -0800)]
Merge tag 'linux-can-next-for-5.11-
20201120' of git://git./linux/kernel/git/mkl/linux-can-next
Marc Kleine-Budde says:
====================
pull-request: can-next 2020-11-20
The first patch is by Yegor Yefremov and he improves the j1939 documentaton by
adding tables for the CAN identifier and its fields.
Then there are 8 patches by Oliver Hartkopp targeting the CAN driver
infrastructure and drivers. These add support for optional DLC element to the
Classical CAN frame structure. See patch
ea7800565a12 ("can: add optional DLC
element to Classical CAN frame structure") for details. Oliver's last patch
adds len8_dlc support to several drivers. Stefan Mätje provides a patch to add
len8_dlc support to the esd_usb2 driver.
The next patch is by Oliver Hartkopp, too and adds support for modification of
Classical CAN DLCs to CAN GW sockets.
The next 3 patches target the nxp,flexcan DT bindings. One patch by my adds the
missing uint32 reference to the clock-frequency property. Joakim Zhang's
patches fix the fsl,clk-source property and add the IMX_SC_R_CAN() macro to the
imx firmware header file, which will be used in the flexcan driver later.
Another patch by Joakim Zhang prepares the flexcan driver for SCU based
stop-mode, by giving the existing, GPR based stop-mode, a _GPR postfix.
The next 5 patches are by me, target the flexcan driver, and clean up the
.ndo_open and .ndo_stop callbacks. These patches try to fix a sporadically
hanging flexcan_close() during simultanious ifdown, sending of CAN messages and
probably open CAN bus. I was never able to reproduce, but these seem to fix the
problem at the reporting user. As these changes are rather big, I'd like to
mainline them via net-next/master.
The next patches are by Jimmy Assarsson and Christer Beskow, they add support
for new USB devices to the existing kvaser_usb driver.
The last patch is by Kaixu Xia and simplifies the return in the
mcp251xfd_chip_softreset() function in the mcp251xfd driver.
* tag 'linux-can-next-for-5.11-
20201120' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next: (25 commits)
can: mcp251xfd: remove useless code in mcp251xfd_chip_softreset
can: kvaser_usb: Add new Kvaser hydra devices
can: kvaser_usb: kvaser_usb_hydra: Add support for new device variant
can: kvaser_usb: Add new Kvaser Leaf v2 devices
can: kvaser_usb: Add USB_{LEAF,HYDRA}_PRODUCT_ID_END defines
can: flexcan: flexcan_close(): change order if commands to properly shut down the controller
can: flexcan: flexcan_open(): completely initialize controller before requesting IRQ
can: flexcan: flexcan_rx_offload_setup(): factor out mailbox and rx-offload setup into separate function
can: flexcan: move enabling/disabling of interrupts from flexcan_chip_{start,stop}() to callers
can: flexcan: factor out enabling and disabling of interrupts into separate function
can: flexcan: rename macro FLEXCAN_QUIRK_SETUP_STOP_MODE -> FLEXCAN_QUIRK_SETUP_STOP_MODE_GPR
dt-bindings: firmware: add IMX_SC_R_CAN(x) macro for CAN
dt-bindings: can: fsl,flexcan: fix fsl,clk-source property
dt-bindings: can: fsl,flexcan: add uint32 reference to clock-frequency property
can: gw: support modification of Classical CAN DLCs
can: drivers: add len8_dlc support for esd_usb2 CAN adapter
can: drivers: add len8_dlc support for various CAN adapters
can: drivers: introduce helpers to access Classical CAN DLC values
can: update documentation for DLC usage in Classical CAN
can: rename CAN FD related can_len2dlc and can_dlc2len helpers
...
====================
Link: https://lore.kernel.org/r/20201120133318.3428231-1-mkl@pengutronix.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Heiner Kallweit [Fri, 20 Nov 2020 11:22:23 +0000 (12:22 +0100)]
net: bridge: switch to net core statistics counters handling
Use netdev->tstats instead of a member of net_bridge for storing
a pointer to the per-cpu counters. This allows us to use core
functionality for statistics handling.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Link: https://lore.kernel.org/r/9bad2be2-fd84-7c6e-912f-cee433787018@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jakub Kicinski [Sat, 21 Nov 2020 22:33:49 +0000 (14:33 -0800)]
Merge branch 'net-hns3-misc-updates-for-next'
Huazhong Tan says:
====================
net: hns3: misc updates for -next
This series includes some misc updates for the HNS3 ethernet driver.
#1 adds support for 1280 queues
#2 adds mapping for BAR45 which is needed by RoCE client.
#3 extend the interrupt resources.
#4 add support to query firmware's calculated shaping parameters.
====================
Link: https://lore.kernel.org/r/1605863783-36995-1-git-send-email-tanhuazhong@huawei.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>