Wong Vee Khee [Tue, 1 Jun 2021 13:52:35 +0000 (21:52 +0800)]
net: stmmac: enable platform specific safety features
On Intel platforms, not all safety features are enabled on the hardware.
The current implementation enable all safety features by default. This
will cause mass error and warning printouts after the module is loaded.
Introduce platform specific safety features flag to enable or disable
each safety features.
Nigel Christian [Tue, 1 Jun 2021 13:35:33 +0000 (09:35 -0400)]
NFC: microread: Remove redundant assignment to variable err
In the case MICROREAD_CB_TYPE_READER_ALL clang reports a dead code
warning. The error code assigned to variable err is already passed
to async_cb(). The assignment is redundant and can be removed.
David S. Miller [Tue, 1 Jun 2021 23:54:42 +0000 (16:54 -0700)]
Merge branch 'act_vlan-allow-modify-zero'
Boris Sukholitko says:
====================
net/sched: act_vlan: Fix modify to allow 0
Currently vlan modification action checks existence of vlan priority by
comparing it to 0. Therefore it is impossible to modify existing vlan
tag to have priority 0.
For example, the following tc command will change the vlan id but will
not affect vlan priority:
tc filter add dev eth1 ingress matchall action vlan modify id 300 \
priority 0 pipe mirred egress redirect dev eth2
The incoming packet on eth1:
ethertype 802.1Q (0x8100), vlan 200, p 4, ethertype IPv4
will be changed to:
ethertype 802.1Q (0x8100), vlan 300, p 4, ethertype IPv4
although the user has intended to have p == 0.
The fix is to add tcfv_push_prio_exists flag to struct tcf_vlan_params
and rely on it when deciding to set the priority.
The same flag is used to avoid dumping unset vlan priority.
Change Log:
v3 -> v4:
- revert tcf_vlan_get_fill_size change: total size calculation may race vs dump
v2 -> v3:
- Push assumes that the priority is being set
- tcf_vlan_get_fill_size accounts for priority existence
v1 -> v2:
- Do not dump unset priority and fix tests accordingly
- Test for priority 0 modification
====================
Currently vlan modification action checks existence of vlan priority by
comparing it to 0. Therefore it is impossible to modify existing vlan
tag to have priority 0.
For example, the following tc command will change the vlan id but will
not affect vlan priority:
tc filter add dev eth1 ingress matchall action vlan modify id 300 \
priority 0 pipe mirred egress redirect dev eth2
The incoming packet on eth1:
ethertype 802.1Q (0x8100), vlan 200, p 4, ethertype IPv4
will be changed to:
ethertype 802.1Q (0x8100), vlan 300, p 4, ethertype IPv4
although the user has intended to have p == 0.
The fix is to add tcfv_push_prio_exists flag to struct tcf_vlan_params
and rely on it when deciding to set the priority.
Fixes: 45a497f2d149a4a8061c (net/sched: act_vlan: Introduce TCA_VLAN_ACT_MODIFY vlan action) Signed-off-by: Boris Sukholitko <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Yang Li [Tue, 1 Jun 2021 09:49:50 +0000 (17:49 +0800)]
NFC: nci: Remove redundant assignment to len
Variable 'len' is set to conn_info->max_pkt_payload_len but this
value is never read as it is overwritten with a new value later on,
hence it is a redundant assignment and can be removed.
Clean up the following clang-analyzer warning:
net/nfc/nci/hci.c:164:3: warning: Value stored to 'len' is never read
[clang-analyzer-deadcode.DeadStores]
Vladimir Oltean [Mon, 31 May 2021 16:17:07 +0000 (19:17 +0300)]
net: enetc: catch negative return code from enetc_pf_to_port()
After the refactoring introduced in commit 87614b931c24 ("net: enetc:
create a common enetc_pf_to_port helper"), enetc_pf_to_port was coded up
to return -1 in case the passed PCIe device does not have a recognized
BDF.
Make sure the -1 value is checked by the callers, to appease static
checkers.
netpoll: don't require irqs disabled in rt kernels
write_msg(netconsole.c:836) calls netpoll_send_udp after a call to
spin_lock_irqsave, which normally disables interrupts; but in PREEMPT_RT
this call just locks an rt_mutex without disabling irqs. In this case,
netpoll_send_udp is called with interrupts enabled.
Vadym Kochan [Mon, 31 May 2021 14:32:43 +0000 (17:32 +0300)]
net: marvell: prestera: disable events interrupt while handling
There are change in firmware which requires that receiver will
disable event interrupts before handling them and enable them
after finish with handling. Events still may come into the queue
but without receiver interruption.
Yang Yingliang [Mon, 31 May 2021 12:48:59 +0000 (20:48 +0800)]
net: neterion: fix doc warnings in s2io.c
Add description for may_sleep to fix the W=1 warnings:
drivers/net/ethernet/neterion/s2io.c:1110: warning: Function parameter or member 'may_sleep' not described in 'init_tti'
drivers/net/ethernet/neterion/s2io.c:3335: warning: Function parameter or member 'may_sleep' not described in 'wait_for_cmd_complete'
drivers/net/ethernet/neterion/s2io.c:4881: warning: Function parameter or member 'may_sleep' not described in 's2io_set_multicast'
Jian Shen [Mon, 31 May 2021 02:38:45 +0000 (10:38 +0800)]
net: hns3: add debugfs support for vlan configuration
Add debugfs support for vlan configuraion. create a single file
"vlan_config" for it, and query it by command "cat vlan_config",
return the result to userspace.
The new display style is below:
$ cat vlan_config
I_PORT_VLAN_FILTER: on
E_PORT_VLAN_FILTER: off
FUNC_ID I_VF_VLAN_FILTER E_VF_VLAN_FILTER PORT_VLAN_FILTER_BYPASS
pf off on off
vf0 off on off
FUNC_ID PVID ACCEPT_TAG1 ACCEPT_TAG2 ACCEPT_UNTAG1 ACCEPT_UNTAG2
pf 0 on on on on
vf0 0 on on on on
Jian Shen [Mon, 31 May 2021 02:38:44 +0000 (10:38 +0800)]
net: hns3: add support for VF modify VLAN filter state
Previously, there is hardware limitation for VF to modify
the VLAN filter state, and the VLAN filter state is default
enabled. Now the limitation has been removed in some device,
so add capability flag to check whether the device supports
modify VLAN filter state. If flag on, user will be able to
modify the VLAN filter state by ethtool -K.
VF needs to send mailbox to request the PF to modify the VLAN
filter state for it.
Jian Shen [Mon, 31 May 2021 02:38:43 +0000 (10:38 +0800)]
net: hns3: add query basic info support for VF
There are some features of VF depend on PF, so it's necessary
for VF to know whether PF supports. For compatibility, modify
the mailbox HCLGE_MBX_GET_TCINFO, extend its function, use to
get the basic information of PF, including mailbox api version
and PF capabilities.
Jian Shen [Mon, 31 May 2021 02:38:42 +0000 (10:38 +0800)]
net: hns3: add support for modify VLAN filter state
Previously, with hardware limitation, the port VLAN filter are
effective for both PF and its VFs simultaneously, so a single
function is not able to enable/disable separately, and the VLAN
filter state is default enabled. Now some device supports each
function to bypass port VLAN filter, then each function can
switch VLAN filter separately. Add capability flag to check
whether the device supports modify VLAN filter state. If flag
on, user will be able to modify the VLAN filter state by ethtool
-K.
Furtherly, the default VLAN filter state is also changed
according to whether non-zero VLAN used. Then the device can
receive packet with any VLAN tag if only VLAN 0 used.
The function hclge_need_enable_vport_vlan_filter() is used to
help implement above changes. And the VLAN filter handle for
promisc mode can also be simplified by this function.
Jian Shen [Mon, 31 May 2021 02:38:41 +0000 (10:38 +0800)]
net: hns3: refine function hclge_set_vf_vlan_cfg()
The struct hclge_vf_vlan_cfg is firstly designed for setting
VLAN filter tag. And it's reused for enable RX VLAN offload
later. It's strange to use member "is_kill" to indicate "enable".
So redefine the struct hclge_vf_vlan_cfg to adapt it.
For there are already 3 subcodes being used in function
hclge_set_vf_vlan_cfg(), use "switch-case" style for each
branch, rather than "if-else". Also simplify the assignment for
each branch to make it more clearly.
Jian Shen [Mon, 31 May 2021 02:38:40 +0000 (10:38 +0800)]
net: hns3: remove unnecessary updating port based VLAN
For the PF have called hclge_update_port_base_vlan_cfg() already
before notify VF, it's unnecessary to update port based VLAN again
when received mailbox request from VF.
even though it isn't the first time these patches are submitted (they
were part of the group previously called "Add NXP SJA1110 support to the
sja1105 DSA driver"):
https://patchwork.kernel.org/project/netdevbpf/cover/20210526135535.2515123[email protected]/
but I broke that up again since these patches are already reviewed, for
the most part. There are no changes compared to v2 and v1.
This series of patches contains:
- an adaptation of the driver to the new "ethernet-ports" OF node name
- an adaptation of the driver to support more than 1 SGMII port
- a generalization of the supported phy_interface_t values per port
- an adaptation to encode SPEED_10, SPEED_100, SPEED_1000 into the
hardware registers differently depending on switch revision
- a consolidation of the PHY interface type used for RGMII and another
one for the API exposed for sja1105_dynamic_config_read()
====================
Vladimir Oltean [Sun, 30 May 2021 22:59:39 +0000 (01:59 +0300)]
net: dsa: sja1105: some table entries are always present when read dynamically
The SJA1105 has a static configuration comprised of a number of tables
with entries. Some of these can be read and modified at runtime as well,
through the dynamic configuration interface.
As a careful reader can notice from the comments in this file, the
software interface for accessing a table entry through the dynamic
reconfiguration is a bit of a no man's land, and varies wildly across
switch generations and even from one kind of table to another.
I have tried my best to come up with a software representation of a
'common denominator' SPI command to access a table entry through the
dynamic configuration interface:
struct sja1105_dyn_cmd {
bool search;
u64 valid; /* must be set to 1 */
u64 rdwrset; /* 0 to read, 1 to write */
u64 errors;
u64 valident; /* 0 if entry is invalid, 1 if valid */
u64 index;
};
Relevant to this patch is the VALIDENT bit, which for READ commands is
populated by the switch and lets us know if we're looking at junk or at
a real table entry.
In SJA1105, the dynamic reconfiguration interface for management routes
has notably not implemented the VALIDENT bit, leading to a workaround to
ignore this field in sja1105_dynamic_config_read(), as it will be set to
zero, but the data is valid nonetheless.
In SJA1110, this pattern has sadly been abused to death, and while there
are many more tables which can be read back over the dynamic config
interface compared to SJA1105, their handling isn't in any way more
uniform. Generally speaking, if there is a single possible entry in a
given table, and loading that table in the static config is mandatory as
per the documentation, then the VALIDENT bit is deemed as redundant and
more than likely not implemented.
So it is time to make the workaround more official, and add a bit to the
flags implemented by dynamic config tables. It will be used by more
tables when SJA1110 support arrives.
Vladimir Oltean [Sun, 30 May 2021 22:59:38 +0000 (01:59 +0300)]
net: dsa: sja1105: always keep RGMII ports in the MAC role
In SJA1105, the xMII Mode Parameters Table field called PHY_MAC denotes
the 'role' of the port, be it a PHY or a MAC. This makes a difference in
the MII and RMII protocols, but RGMII is symmetric, so either PHY or MAC
settings result in the same hardware behavior.
The SJA1110 is different, and the RGMII ports only work when configured
in MAC mode, so keep the port roles in MAC mode unconditionally.
Why we had an RGMII port in the PHY role in the first place was because
we wanted to have a way in the driver to denote whether RGMII delays
should be applied based on the phy-mode property or not. This is already
done in sja1105_parse_rgmii_delays() based on an intermediary
struct sja1105_dt_port (which contains the port role). So it is a
logical fallacy to use the hardware configuration as a scratchpad for
driver data, it isn't necessary.
We can also remove the gating condition for applying RGMII delays only
for ports in the PHY role. The .setup_rgmii_delay() method looks at
the priv->rgmii_rx_delay[port] and priv->rgmii_tx_delay[port] properties
which are already populated properly (in the case of a port in the MAC
role they are false). Removing this condition generates a few more SPI
writes for these ports (clearing the RGMII delays) which are perhaps
useless for SJA1105P/Q/R/S, where we know that the delays are disabled
by default. But for SJA1110, the firmware on the embedded microcontroller
might have done something funny, so it's always a good idea to clear the
RGMII delays if that's what Linux expects.
Vladimir Oltean [Sun, 30 May 2021 22:59:37 +0000 (01:59 +0300)]
net: dsa: sja1105: add a translation table for port speeds
In order to support the new speed of 2500Mbps, the SJA1110 has achieved
the great performance of changing the encoding in the MAC Configuration
Table for the port speeds of 10, 100, 1000 compared to SJA1105.
Because this is a common driver, we need a layer of indirection in order
to program the hardware with the right values irrespective of switch
generation.
Vladimir Oltean [Sun, 30 May 2021 22:59:36 +0000 (01:59 +0300)]
net: dsa: sja1105: add a PHY interface type compatibility matrix
On the SJA1105, all ports support the parallel "xMII" protocols (MII,
RMII, RGMII) except for port 4 on SJA1105R/S which supports only SGMII.
This was relatively easy to model, by special-casing the SGMII port.
On the SJA1110, certain ports can be pinmuxed between SGMII and xMII, or
between SGMII and an internal 100base-TX PHY. This creates problems,
because the driver's assumption so far was that if a port supports
SGMII, it uses SGMII.
We allow the device tree to tell us how the port pinmuxing is done, and
check that against a PHY interface type compatibility matrix for
plausibility.
The other big change is that instead of doing SGMII configuration based
on what the port supports, we do it based on what is the configured
phy_mode of the port.
The 2500base-x support added in this patch is not complete.
Vladimir Oltean [Sun, 30 May 2021 22:59:35 +0000 (01:59 +0300)]
net: dsa: sja1105: cache the phy-mode port property
So far we've succeeded in operating without keeping a copy of the
phy-mode in the driver, since we already have the static config and we
can look at the xMII Mode Parameters Table which already holds that
information.
But with the SJA1110, we cannot make the distinction between sgmii and
2500base-x, because to the hardware's static config, it's all SGMII.
So add a phy_mode property per port inside struct sja1105_private.
Vladimir Oltean [Sun, 30 May 2021 22:59:34 +0000 (01:59 +0300)]
net: dsa: sja1105: the 0x1F0000 SGMII "base address" is actually MDIO_MMD_VEND2
Looking at the SGMII PCS from SJA1110, which is accessed indirectly
through a different base address as can be seen in the next patch, it
appears odd that the address accessed through indirection still
references the base address from the SJA1105S register map (first MDIO
register is at 0x1f0000), when it could index the SGMII registers
starting from zero.
Except that the 0x1f0000 is not a base address at all, it seems. It is
0x1f << 16 | 0x0000, and 0x1f is coding for the vendor-specific MMD2.
So, it turns out, the Synopsys PCS implements all its registers inside
the vendor-specific MMDs 1 and 2 (0x1e and 0x1f). This explains why the
PCS has no overlaps (for the other MMDs) with other register regions of
the switch (because no other MMDs are implemented).
Change the code to remove the SGMII "base address" and explicitly encode
the MMD for reads/writes. This will become necessary for SJA1110 support.
Vladimir Oltean [Sun, 30 May 2021 22:59:33 +0000 (01:59 +0300)]
net: dsa: sja1105: allow SGMII PCS configuration to be per port
The SJA1105 R and S switches have 1 SGMII port (port 4). Because there
is only one such port, there is no "port" parameter in the configuration
code for the SGMII PCS.
However, the SJA1110 can have up to 4 SGMII ports, each with its own
SGMII register map. So we need to generalize the logic.
Vladimir Oltean [Sun, 30 May 2021 22:59:32 +0000 (01:59 +0300)]
net: dsa: sja1105: be compatible with "ethernet-ports" OF node name
Since commit f2f3e09396be ("net: dsa: sja1105: be compatible with
"ethernet-ports" OF node name"), DSA supports the "ethernet-ports" name
for the container node of the ports, but the sja1105 driver doesn't,
because it handles some device tree parsing of its own.
Willy Tarreau [Sat, 29 May 2021 11:07:46 +0000 (13:07 +0200)]
ipv6: use prandom_u32() for ID generation
This is a complement to commit aa6dd211e4b1 ("inet: use bigger hash
table for IP ID generation"), but focusing on some specific aspects
of IPv6.
Contary to IPv4, IPv6 only uses packet IDs with fragments, and with a
minimum MTU of 1280, it's much less easy to force a remote peer to
produce many fragments to explore its ID sequence. In addition packet
IDs are 32-bit in IPv6, which further complicates their analysis. On
the other hand, it is often easier to choose among plenty of possible
source addresses and partially work around the bigger hash table the
commit above permits, which leaves IPv6 partially exposed to some
possibilities of remote analysis at the risk of weakening some
protocols like DNS if some IDs can be predicted with a good enough
probability.
Given the wide range of permitted IDs, the risk of collision is extremely
low so there's no need to rely on the positive increment algorithm that
is shared with the IPv4 code via ip_idents_reserve(). We have a fast
PRNG, so let's simply call prandom_u32() and be done with it.
Performance measurements at 10 Gbps couldn't show any difference with
the previous code, even when using a single core, because due to the
large fragments, we're limited to only ~930 kpps at 10 Gbps and the cost
of the random generation is completely offset by other operations and by
the network transfer time. In addition, this change removes the need to
update a shared entry in the idents table so it may even end up being
slightly faster on large scale systems where this matters.
The risk of at least one collision here is about 1/80 million among
10 IDs, 1/850k among 100 IDs, and still only 1/8.5k among 1000 IDs,
which remains very low compared to IPv4 where all IDs are reused
every 4 to 80ms on a 10 Gbps flow depending on packet sizes.
Now that the kernel has ftrace, any debugging calls that just do "made
it to this function!" and "leaving this function!" can be removed.
Better to use standard debugging tools.
nfc: st21nfca: drop ftrace-like debugging messages
Now that the kernel has ftrace, any debugging calls that just do "made
it to this function!" and "leaving this function!" can be removed.
Better to use standard debugging tools.
Now that the kernel has ftrace, any debugging calls that just do "made
it to this function!" and "leaving this function!" can be removed.
Better to use standard debugging tools.
Now that the kernel has ftrace, any debugging calls that just do "made
it to this function!" and "leaving this function!" can be removed.
Better to use standard debugging tools.
Now that the kernel has ftrace, any debugging calls that just do "made
it to this function!" and "leaving this function!" can be removed.
Better to use standard debugging tools.
Now that the kernel has ftrace, any debugging calls that just do "made
it to this function!" and "leaving this function!" can be removed.
Better to use standard debugging tools.
This allows also to remove several local variables and entire
fdp_nci_recv_frame() function (whose purpose was only to log).
Jakub Kicinski [Sun, 30 May 2021 21:24:40 +0000 (14:24 -0700)]
Merge branch 'fixes-for-yt8511-phy-driver'
Peter Geis says:
====================
fixes for yt8511 phy driver
The Intel clang bot caught a few uninitialized variables in the new
Motorcomm driver. While investigating the issue, it was found that the
driver would have unintended effects when used in an unsupported mode.
Fixed the uninitialized ret variable and abort loading the driver in
unsupported modes.
====================
Peter Geis [Sat, 29 May 2021 11:05:56 +0000 (07:05 -0400)]
net: phy: abort loading yt8511 driver in unsupported modes
While investigating the clang `ge` uninitialized variable report, it was
discovered the default switch would have unintended consequences. Due to
the switch to __phy_modify, the driver would modify the ID values in the
default scenario.
Fix this by promoting the interface mode switch and aborting when the
mode is not a supported RGMII mode.
This prevents the `ge` and `fe` variables from ever being used
uninitialized.
clang doesn't preinitialize variables. If phy_select_page failed and
returned an error, phy_restore_page would be called with `ret` being
uninitialized.
Even though phy_restore_page won't use `ret` in this scenario,
initialize `ret` to silence the warning.
Yang Yingliang [Sat, 29 May 2021 03:04:38 +0000 (11:04 +0800)]
net: dsa: qca8k: check return value of read functions correctly
Current return type of qca8k_mii_read32() and qca8k_read() are
unsigned, it can't be negative, so the return value check is
unuseful. For check the return value correctly, change return
type of the read functions and add a output parameter to store
the read value.
In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.
In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding a fallthrough statement instead of just
letting the code fall through to the next case.
Jakub Kicinski [Sat, 29 May 2021 21:16:24 +0000 (14:16 -0700)]
Merge branch 'npc-kpu-updates'
George Cherian says:
====================
NPC KPU updates
Add support for
- Loading Custom KPU profile entries
- Add NPC profile Load from System Firmware DB
- Add Support fo Coalescing KPU profiles
- General Updates/Fixes to default KPU profile
====================
Harman Kalra [Thu, 27 May 2021 09:44:38 +0000 (15:14 +0530)]
octeontx2-af: support for coalescing KPU profiles
Adding support to load a new type of KPU image, known as coalesced/
consolidated KPU image via firmware database. This image is a
consolidation of multiple KPU profiles into a single image.
During kernel bootup this coalesced image will be read via
firmware database and only the relevant KPU profile will be loaded.
Existing functionality of loading single KPU/MKEX profile
is intact as the images are differentiated based on the image signature.
Harman Kalra [Thu, 27 May 2021 09:44:37 +0000 (15:14 +0530)]
octeontx2-af: adding new lt def registers support
CN10k introduces following new LT DEF registers:
1. APAD (alignment padding) LT DEF registers are
enhancement to existing apad calculation algorithm
where not just ipv4 and ipv6 but also other protocols
can be matched and required alignment can be added by NIX.
2. ET LT DEF register defines layer information in NPC_RESULT_S
to identify the Ethertype location in L2 header. Used for
Ethertype overwriting in inline IPsec flow.
This patch adds required structures and some header changes. Also
strict version check (based on minor field) is imposed to highlight
version mismatch between the kernel headers and KPU profile.
Harman Kalra [Thu, 27 May 2021 09:44:36 +0000 (15:14 +0530)]
octeontx2-af: load NPC profile via firmware database
Currently NPC profile (KPU + MKEX) can be loaded using firmware
binary in filesystem scheme. Enhancing the functionality to load
NPC profile image from system firmware database. It uses the same
technique as used for loading MKEX profile. Firstly firmware binary
in kernel is checked for a valid image else tries to load NPC profile
from firmware database and at last uses default profile if no proper
image found.
Add ability to load a set of custom KPU entries. This
allows for flexible support for custom protocol parsing.
AF driver will attempt to load the profile and verify if it can fit
hardware capabilities. If not, it will revert to the built-in profile.
Next it will replace the first KPU_MAX_CST_LT (2) entries in each KPU
in default profile with entries read from the profile image.
The built-in profile should always contain KPU_MAX_CSR_LT first no-match
entries and AF driver will disable those in the KPU unless custom
profile is loaded.
Profile file contains also a list of default protocol overrides to
allow for custom protocols to be used there.
In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.
Vladimir Oltean [Thu, 27 May 2021 15:59:59 +0000 (18:59 +0300)]
net: stmmac: the XPCS obscures a potential "PHY not found" error
stmmac_mdio_register() has logic to search for PHYs on the MDIO bus and
assign them IRQ lines, as well as to set priv->plat->phy_addr.
If no PHY is found, the "found" variable remains set to 0 and the
function errors out.
After the introduction of commit f213bbe8a9d6 ("net: stmmac: Integrate
it with DesignWare XPCS"), the "found" variable was immediately reused
for searching for a PCS on the same MDIO bus.
This can result in 2 types of potential problems (none of them seems to
be seen on the only Intel system that sets has_xpcs = true, otherwise it
would have been reported):
1. If a PCS is found but a PHY is not, then the code happily exits with
no error. One might say "yes, but this is not possible, because
of_mdiobus_register will probe a PHY for all MDIO addresses,
including for the XPCS, so if an XPCS exists, then a PHY certainly
exists too". Well, that is not true, see intel_mgbe_common_data():
projects / linux.git / log