Daniel Borkmann says:
====================
pull-request: bpf 2020-03-27
The following pull-request contains BPF updates for your *net* tree.
We've added 3 non-merge commits during the last 4 day(s) which contain
a total of 4 files changed, 25 insertions(+), 20 deletions(-).
The main changes are:
1) Explicitly memset the bpf_attr structure on bpf() syscall to avoid
having to rely on compiler to do so. Issues have been noticed on
some compilers with padding and other oddities where the request was
then unexpectedly rejected, from Greg Kroah-Hartman.
2) Sanitize the bpf_struct_ops TCP congestion control name in order to
avoid problematic characters such as whitespaces, from Martin KaFai Lau.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Vladimir Oltean says:
====================
Configure the MTU on DSA switches
This series adds support for configuring the MTU on front-panel switch
ports, while seamlessly adapting the CPU port and the DSA master to the
largest value plus the tagger overhead.
It also implements bridge MTU auto-normalization within the DSA core, as
resulted after the feedback of the implementation of this feature inside
the bridge driver in v2.
Support was added for quite a number of switches, in the hope that this
series would gain some traction:
- sja1105
- felix
- vsc73xx
- b53 and rest of the platform
V3 of this series was submitted here:
https://patchwork.ozlabs.org/cover/1262394/
V2 of this series was submitted here:
https://patchwork.ozlabs.org/cover/1261471/
V1 of this series was submitted here:
https://patchwork.ozlabs.org/cover/1199868/
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Changing the MTU for this switch means altering the
DEV_GMII:MAC_CFG_STATUS:MAC_MAXLEN_CFG field MAX_LEN, which in turn
limits the size of frames that can be received.
Special accounting needs to be done for the DSA CPU port (NPI port in
hardware terms). The NPI port configuration needs to be held inside the
private ocelot structure, since it is now accessed from multiple places.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Instead of hardcoding the MTU to the maximum value allowed by the
hardware, obey the value known by the operating system.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
On this switch, the frame length enforcements are performed by the
ingress policers. There are 2 types of those: regular L2 (also called
best-effort) and Virtual Link policers (an ARINC664/AFDX concept for
defining L2 streams with certain QoS abilities). To avoid future
confusion, I prefer to call the reset reason "Best-effort policers",
even though the VL policers are not yet supported.
We also need to change the setup of the initial static config, such that
DSA calls to .change_mtu (which are expensive) become no-ops and don't
reset the switch 5 times.
A driver-level decision is to unconditionally allow single VLAN-tagged
traffic on all ports. The CPU port must accept an additional VLAN header
for the DSA tag, which is again a driver-level decision.
The policers actually count bytes not only from the SDU, but also from
the Ethernet header and FCS, so those need to be accounted for as well.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
It looks like the Broadcom switches supported by the b53 driver don't
support precise configuration of the MTU, but just a mumbo-jumbo boolean
flag. Set that.
Also configure BCM583XX devices to send and receive jumbo frames when
ports are configured with 10/100 Mbps speed.
Signed-off-by: Murali Krishna Policharla <murali.policharla@broadcom.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Many switches don't have an explicit knob for configuring the MTU
(maximum transmission unit per interface). Instead, they do the
length-based packet admission checks on the ingress interface, for
reasons that are easy to understand (why would you accept a packet in
the queuing subsystem if you know you're going to drop it anyway).
So it is actually the MRU that these switches permit configuring.
In Linux there only exists the IFLA_MTU netlink attribute and the
associated dev_set_mtu function. The comments like to play blind and say
that it's changing the "maximum transfer unit", which is to say that
there isn't any directionality in the meaning of the MTU word. So that
is the interpretation that this patch is giving to things: MTU == MRU.
When 2 interfaces having different MTUs are bridged, the bridge driver
MTU auto-adjustment logic kicks in: what br_mtu_auto_adjust() does is it
adjusts the MTU of the bridge net device itself (and not that of the
slave net devices) to the minimum value of all slave interfaces, in
order for forwarded packets to not exceed the MTU regardless of the
interface they are received and send on.
The idea behind this behavior, and why the slave MTUs are not adjusted,
is that normal termination from Linux over the L2 forwarding domain
should happen over the bridge net device, which _is_ properly limited by
the minimum MTU. And termination over individual slave devices is
possible even if those are bridged. But that is not "forwarding", so
there's no reason to do normalization there, since only a single
interface sees that packet.
The problem with those switches that can only control the MRU is with
the offloaded data path, where a packet received on an interface with
MRU 9000 would still be forwarded to an interface with MRU 1500. And the
br_mtu_auto_adjust() function does not really help, since the MTU
configured on the bridge net device is ignored.
In order to enforce the de-facto MTU == MRU rule for these switches, we
need to do MTU normalization, which means: in order for no packet larger
than the MTU configured on this port to be sent, then we need to limit
the MRU on all ports that this packet could possibly come from. AKA
since we are configuring the MRU via MTU, it means that all ports within
a bridge forwarding domain should have the same MTU.
And that is exactly what this patch is trying to do.
>From an implementation perspective, we try to follow the intent of the
user, otherwise there is a risk that we might livelock them (they try to
change the MTU on an already-bridged interface, but we just keep
changing it back in an attempt to keep the MTU normalized). So the MTU
that the bridge is normalized to is either:
- The most recently changed one:
ip link set dev swp0 master br0
ip link set dev swp1 master br0
ip link set dev swp0 mtu 1400
This sequence will make swp1 inherit MTU 1400 from swp0.
- The one of the most recently added interface to the bridge:
ip link set dev swp0 master br0
ip link set dev swp1 mtu 1400
ip link set dev swp1 master br0
The above sequence will make swp0 inherit MTU 1400 as well.
Suggested-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
It is useful be able to configure port policers on a switch to accept
frames of various sizes:
- Increase the MTU for better throughput from the default of 1500 if it
is known that there is no 10/100 Mbps device in the network.
- Decrease the MTU to limit the latency of high-priority frames under
congestion, or work around various network segments that add extra
headers to packets which can't be fragmented.
For DSA slave ports, this is mostly a pass-through callback, called
through the regular ndo ops and at probe time (to ensure consistency
across all supported switches).
The CPU port is called with an MTU equal to the largest configured MTU
of the slave ports. The assumption is that the user might want to
sustain a bidirectional conversation with a partner over any switch
port.
The DSA master is configured the same as the CPU port, plus the tagger
overhead. Since the MTU is by definition L2 payload (sans Ethernet
header), it is up to each individual driver to figure out if it needs to
do anything special for its frame tags on the CPU port (it shouldn't
except in special cases). So the MTU does not contain the tagger
overhead on the CPU port.
However the MTU of the DSA master, minus the tagger overhead, is used as
a proxy for the MTU of the CPU port, which does not have a net device.
This is to avoid uselessly calling the .change_mtu function on the CPU
port when nothing should change.
So it is safe to assume that the DSA master and the CPU port MTUs are
apart by exactly the tagger's overhead in bytes.
Some changes were made around dsa_master_set_mtu(), function which was
now removed, for 2 reasons:
- dev_set_mtu() already calls dev_validate_mtu(), so it's redundant to
do the same thing in DSA
- __dev_set_mtu() returns 0 if ops->ndo_change_mtu is an absent method
That is to say, there's no need for this function in DSA, we can safely
call dev_set_mtu() directly, take the rtnl lock when necessary, and just
propagate whatever errors get reported (since the user probably wants to
be informed).
Some inspiration (mainly in the MTU DSA notifier) was taken from a
vaguely similar patch from Murali and Florian, who are credited as
co-developers down below.
Co-developed-by: Murali Krishna Policharla <murali.policharla@broadcom.com>
Signed-off-by: Murali Krishna Policharla <murali.policharla@broadcom.com>
Co-developed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Change DMA descriptor length to handle jumbo frames beyond 8192 bytes.
Also update jumbo frame max size to include FCS, the DMA packet length
received includes FCS.
Signed-off-by: Murali Krishna Policharla <murali.policharla@broadcom.com>
Reviewed-by: Arun Parameswaran <arun.parameswaran@broadcom.com>
Reviewed-by: Ray Jui <ray.jui@broadcom.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The BCM7XX PHY family requires special configuration to pass jumbo
frames. Do that during initial PHY setup.
Signed-off-by: Murali Krishna Policharla <murali.policharla@broadcom.com>
Reviewed-by: Scott Branden <scott.branden@broadcom.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
On Android/x86 the module loading infrastructure can't deal with
softdeps. Therefore the check for presence of the Realtek PHY driver
module fails. mdiobus_register() will try to load the PHY driver
module, therefore move the check to after this call and explicitly
check that a dedicated PHY driver is bound to the PHY device.
Fixes: f325937735 ("r8169: check that Realtek PHY driver module is loaded")
Reported-by: Chih-Wei Huang <cwhuang@android-x86.org>
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Third set of patches for v5.7. Nothing really special this time,
business as usual.
When pulling this to net-next there's again a conflict in:
drivers/net/wireless/intel/iwlwifi/pcie/drv.c
To solve this drop these three lines from the conflict (the first hunk
from "HEAD") as the whole AX200 block was moved above in the same
file:
IWL_DEV_INFO(0x2723, 0x1653, iwl_ax200_cfg_cc, iwl_ax200_killer_1650w_name),
IWL_DEV_INFO(0x2723, 0x1654, iwl_ax200_cfg_cc, iwl_ax200_killer_1650x_name),
IWL_DEV_INFO(0x2723, IWL_CFG_ANY, iwl_ax200_cfg_cc, iwl_ax200_name),
And keep all the __IWL_DEV_INFO() entries (the second hunk). In other
words, take everything from wireless-drivers-next. When running 'git
diff' after the resolution the output should be empty.
Major changes:
brcmfmac
* add USB autosuspend support
ath11k
* handle RX fragments
* enable PN offload
* add support for HE BSS color
iwlwifi
* support new FW API version
* support for EDCA measurements
* new scan API features
* enable new firmware debugging code
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJefdsZAAoJEG4XJFUm622blekH/2fIoUtl8Kdih38hNjz63PLD
x+LCPjZdRjrmFGTSxnS1rZiIM7v2yXyLGiyq+yr2ltzkpTi8xWOkKL6US8RCew9R
otRtZyLrhgMLG2ExDna1fI5ZJAtLnxV31TCy6yrSUDZ8t4VxMNIB4si3WRzKvAfU
c+cQcsnWr+pCDnbxh53BcYIyiEqKlttw/fGuIKchKuYMQy7DV6nxMdTaAym5Szzi
Nlb8fhXWFaPrPQ6NtHb5WWm4Er3wtMzN/AG8aFVxjrik07vTxQKWamdT9CeK2tDT
iDbx2HaNCWFMulXeZMrc9+inoAzj3UjbPqH3OTUk9iHbVA0unc3CdEBFD9h928Q=
=D/FA
-----END PGP SIGNATURE-----
Merge tag 'wireless-drivers-next-2020-03-27' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
Kalle Valo says:
====================
wireless-drivers-next patches for v5.7
Third set of patches for v5.7. Nothing really special this time,
business as usual.
When pulling this to net-next there's again a conflict in:
drivers/net/wireless/intel/iwlwifi/pcie/drv.c
To solve this drop these three lines from the conflict (the first hunk
from "HEAD") as the whole AX200 block was moved above in the same
file:
IWL_DEV_INFO(0x2723, 0x1653, iwl_ax200_cfg_cc, iwl_ax200_killer_1650w_name),
IWL_DEV_INFO(0x2723, 0x1654, iwl_ax200_cfg_cc, iwl_ax200_killer_1650x_name),
IWL_DEV_INFO(0x2723, IWL_CFG_ANY, iwl_ax200_cfg_cc, iwl_ax200_name),
And keep all the __IWL_DEV_INFO() entries (the second hunk). In other
words, take everything from wireless-drivers-next. When running 'git
diff' after the resolution the output should be empty.
Major changes:
brcmfmac
* add USB autosuspend support
ath11k
* handle RX fragments
* enable PN offload
* add support for HE BSS color
iwlwifi
* support new FW API version
* support for EDCA measurements
* new scan API features
* enable new firmware debugging code
====================
Kalle gave me directions on how to resolve the iwlwifi conflict
as follows:
====================
When pulling this to net-next there's again a conflict in:
drivers/net/wireless/intel/iwlwifi/pcie/drv.c
To solve this drop these three lines from the conflict (the first hunk
from "HEAD") as the whole AX200 block was moved above in the same
file:
IWL_DEV_INFO(0x2723, 0x1653, iwl_ax200_cfg_cc, iwl_ax200_killer_1650w_name),
IWL_DEV_INFO(0x2723, 0x1654, iwl_ax200_cfg_cc, iwl_ax200_killer_1650x_name),
IWL_DEV_INFO(0x2723, IWL_CFG_ANY, iwl_ax200_cfg_cc, iwl_ax200_name),
And keep all the __IWL_DEV_INFO() entries (the second hunk). In other
words, take everything from wireless-drivers-next. When running 'git
diff' after the resolution the output should be empty.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Julian Wiedmann says:
====================
s390/qeth: updates 2020-03-27
please apply the following patch series for qeth to netdev's net-next
tree.
Spring clean edition:
- remove one sysfs attribute that was never put in use,
- make support for OSN and OSX devices optional, and
- probe for removal of the obsolete OSN support.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
OSN devices currently spend an awful long time in qeth_l2_set_online()
until various unsupported HW cmds time out. This has been broken for
over two years, ever since
commit d22ffb5a71 ("s390/qeth: fix IPA command submission race")
triggered a FW bug in cmd processing.
Prior to commit 782e4a7921 ("s390/qeth: don't poll for cmd IO completion"),
this wait for timeout would have even been spent busy-polling.
The offending patch was picked up by stable and all relevant distros,
and yet noone noticed.
OSN setups only ever worked in combination with an out-of-tree blob, and
the last machine that even offered HW with OSN support was released back
in 2015.
Rather than attempting to work-around this FW issue for no actual gain,
add a deprecation warning so anyone who still wants to maintain this
part of the code can speak up. Else rip it all out in 2021.
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The last machine generation that supports OSN is z13, and OSX is only
supported up to z14. Allow users and distros to decide whether they
still need support for these device types.
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Ever since commit 4a71df5004 ("qeth: new qeth device driver") introduced
this attribute, it can be read & written but has no actual effect.
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Vasundhara Volam says:
====================
bnxt_en: Updates to devlink info_get cb
This series adds support for a generic macro to devlink info_get cb.
Adds support for fw.mgmt.api and board.id info to bnxt_en driver info_get
cb. Also, updates the devlink-info.rst and bnxt.rst documentation
accordingly.
This series adds a patch to fix few macro names that maps to bnxt_en
firmware versions.
v1->v2: Remove ECN dev param, base_mh_addr and serial number info support
in this series.
Rename drv.spec macro to fw.api.
---
v2->v3: Remove hw.addr info as it is per netdev but not per device info.
---
v3->v4: Rename "fw.api" to "fw.mgmt.api".
Also, add a patch that modifies few macro names in info_get command,
to match the devlink documentation.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Fix macro names to report fw.mgmt and fw.ncsi versions to match the
devlink documentation.
Example display after fixes:
$ devlink dev info pci/0000:af:00.0
pci/0000:af:00.0:
driver bnxt_en
serial_number B0-26-28-FF-FE-25-84-20
versions:
fixed:
board.id BCM957454A4540
asic.id C454
asic.rev 1
running:
fw 216.1.154.0
fw.psid 0.0.0
fw.mgmt 216.1.146.0
fw.mgmt.api 1.10.1
fw.ncsi 864.0.44.0
fw.roce 216.1.16.0
Fixes: 9599e036b1 ("bnxt_en: Add support for devlink info command")
Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add part number info from the vital product data to info_get command
via devlink tool. Update bnxt.rst documentation as well.
Cc: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Store the part number and serial number information from VPD in
the bnxt structure. Follow up patch will add the support to display
the information via devlink command.
Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch adds a new macro for serial number keyword.
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Display the minimum version of firmware interface spec supported
between driver and firmware. Also update bnxt.rst documentation file.
Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add definition and documentation for the new generic info
"fw.mgmt.api". This macro specifies the version of the software
interfaces between driver and firmware.
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Jacob Keller <jacob.e.keller@intel.com>
Cc: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Ido Schimmel says:
====================
mlxsw: Various static checkers fixes
Jakub told me he gets some warnings with W=1, so I decided to check with
sparse, smatch and coccinelle as well. This patch set fixes all the
issues found. None are actual bugs / regressions and therefore not
targeted at net.
Patches #1-#2 add missing kernel-doc comments.
Patch #3 removes dead code.
Patch #4 reworks the ACL code to avoid defining a static variable in a
header file.
Patch #5 removes unnecessary conversion to bool that coccinelle warns
about.
Patch #6 avoids false-positive uninitialized symbol errors emitted by
smatch.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Suppress the following smatch errors. None of these are actually
possible with current code paths.
drivers/net/ethernet/mellanox/mlxsw//spectrum_router.c:1220
mlxsw_sp_ipip_entry_find_decap() error: uninitialized symbol 'saddrp'.
drivers/net/ethernet/mellanox/mlxsw//spectrum_router.c:1220
mlxsw_sp_ipip_entry_find_decap() error: uninitialized symbol
'saddr_len'.
drivers/net/ethernet/mellanox/mlxsw//spectrum_router.c:1221
mlxsw_sp_ipip_entry_find_decap() error: uninitialized symbol
'saddr_prefix_len'.
drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:1390
mlxsw_sp_netdevice_ipip_ol_reg_event() error: uninitialized symbol
'ipipt'.
drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:3255
mlxsw_sp_nexthop_group_update() error: uninitialized symbol 'err'.
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Suppress following warning from coccinelle:
drivers/net/ethernet/mellanox/mlxsw//switchx2.c:183:63-68: WARNING:
conversion to bool not needed here
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The static array 'mlxsw_afk_element_infos' in 'core_acl_flex_keys.h' is
copied to each file that includes the header, but not all use it. This
results in the following warnings when compiling with W=1:
drivers/net/ethernet/mellanox/mlxsw//core_acl_flex_keys.h:76:44:
warning: ‘mlxsw_afk_element_infos’ defined but not used
[-Wunused-const-variable=]
One way to suppress the warning is to mark the array with
'__maybe_unused', but another option is to remove it from the header
file entirely.
Change 'struct mlxsw_afk_element_inst' to store the key to the array
('element') instead of the array value keyed by 'element'. Adjust the
different users accordingly.
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In merge commit 50853808ff ("Merge branch
'mlxsw-Prepare-for-VLAN-aware-bridge-w-VxLAN'") I flipped mlxsw to use
emulated 802.1Q FIDs and correspondingly emulated VLAN RIFs. This means
that the non-emulated variants are no longer used. Remove them and
suppress the following warnings when compiling with W=1:
drivers/net/ethernet/mellanox/mlxsw//spectrum_router.c:7572:38: warning:
‘mlxsw_sp_rif_vlan_ops’ defined but not used [-Wunused-const-variable=]
drivers/net/ethernet/mellanox/mlxsw//spectrum_fid.c:584:41: warning:
‘mlxsw_sp_fid_8021q_family’ defined but not used
[-Wunused-const-variable=]
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Suppress following warnings when compiling with W=1:
drivers/net/ethernet/mellanox/mlxsw//spectrum_router.c:1552: warning:
Function parameter or member 'mlxsw_sp' not described in
'__mlxsw_sp_ipip_entry_update_tunnel'
drivers/net/ethernet/mellanox/mlxsw//spectrum_router.c:1552: warning:
Function parameter or member 'ipip_entry' not described in
'__mlxsw_sp_ipip_entry_update_tunnel'
drivers/net/ethernet/mellanox/mlxsw//spectrum_router.c:1552: warning:
Function parameter or member 'extack' not described in
'__mlxsw_sp_ipip_entry_update_tunnel'
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Suppress following warning when compiling with W=1:
drivers/net/ethernet/mellanox/mlxsw//i2c.c:78: warning: Function
parameter or member 'cmd' not described in 'mlxsw_i2c'
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Steffen Klassert says:
====================
pull request (net): ipsec 2020-03-27
1) Handle NETDEV_UNREGISTER for xfrm device to handle asynchronous
unregister events cleanly. From Raed Salem.
2) Fix vti6 tunnel inter address family TX through bpf_redirect().
From Nicolas Dichtel.
3) Fix lenght check in verify_sec_ctx_len() to avoid a
slab-out-of-bounds. From Xin Long.
4) Add a missing verify_sec_ctx_len check in xfrm_add_acquire
to avoid a possible out-of-bounds to access. From Xin Long.
5) Use built-in RCU list checking of hlist_for_each_entry_rcu
to silence false lockdep warning in __xfrm6_tunnel_spi_lookup
when CONFIG_PROVE_RCU_LIST is enabled. From Madhuparna Bhowmik.
6) Fix a panic on esp offload when crypto is done asynchronously.
From Xin Long.
7) Fix a skb memory leak in an error path of vti6_rcv.
From Torsten Hilbrich.
8) Fix a race that can lead to a doulbe free in xfrm_policy_timer.
From Xin Long.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
All callers of gpio_set_config() have to convert a gpio_desc to a
gpio_chip and offset. Avoid these duplicated conversion steps by
letting gpio_set_config() take a gpio_desc pointer directly.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20200325100439.14000-2-geert+renesas@glider.be
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The GPIO Aggregator will need a method to forward a .set_config() call
to its parent gpiochip. This requires obtaining the gpio_chip and
offset for a given gpio_desc. While gpiod_to_chip() is public,
gpio_chip_hwgpio() is not, so there is currently no method to obtain the
needed GPIO offset parameter.
Hence introduce a public gpiod_set_config() helper, which invokes the
.set_config() callback through a gpio_desc pointer, like is done for
most other gpio_chip callbacks.
Rewrite the existing gpiod_set_debounce() helper as a wrapper around
gpiod_set_config(), to avoid duplication.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20200324135653.6676-5-geert+renesas@glider.be
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Commit 0161a94e2d ("tools: gpio: Correctly add make dependencies for
gpio_utils") added a make rule for gpio-utils-in.o but used $(output)
instead of the correct $(OUTPUT) for the output directory, breaking
out-of-tree build (O=xx) with the following error:
No rule to make target 'out/tools/gpio/gpio-utils-in.o', needed by 'out/tools/gpio/lsgpio-in.o'. Stop.
Fix that.
Fixes: 0161a94e2d ("tools: gpio: Correctly add make dependencies for gpio_utils")
Cc: <stable@vger.kernel.org>
Cc: Laura Abbott <labbott@redhat.com>
Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi>
Link: https://lore.kernel.org/r/20200325103154.32235-1-anssi.hannula@bitwise.fi
Reviewed-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
For Spreadtrum pin controller, it will be the high impedance
mode if disable input and output mode for a pin. Thus add
PIN_CONFIG_BIAS_HIGH_IMPEDANCE configuration to support it.
Signed-off-by: Linhua Xu <linhua.xu@unisoc.com>
Signed-off-by: Baolin Wang <baolin.wang7@gmail.com>
Link: https://lore.kernel.org/r/3bdac4c2673b54c940e511f3fa569ee33b87b8d5.1585124562.git.baolin.wang7@gmail.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The Spreadtrum pin controller did not supply registers to set high level
or low level for output mode, instead we should let the pin controller
current configuration drive values on the line. So we should use the
PIN_CONFIG_OUTPUT_ENABLE configuration to enable or disable the output
mode.
[Baolin Wang changes the commit message]
Fixes: 41d32cfce1 ("pinctrl: sprd: Add Spreadtrum pin control driver")
Signed-off-by: Linhua Xu <linhua.xu@unisoc.com>
Signed-off-by: Baolin Wang <baolin.wang7@gmail.com>
Link: https://lore.kernel.org/r/8a6f91b49c17beb218e46b23084f59a7c7260f86.1585124562.git.baolin.wang7@gmail.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
For the devicetree files, there are a total of 20 patches, almost
entirely for 32-bit machines:
- The Allwinner/sun9i r40 SoC dtsi file contains a number of issues,
both for correctness and for style that are addressed in separate
patches. This causes most of the changed lines of the DT updates
this time.
- More Allwinner updates fixing the identification of the security
system on sun8i/A33, a recent regression of the A83t ethernet, and a
few board specific issues on the TBS-A711 macine.
- Several bug fixes for OMAP dts files, most notably fixing the timings
for the NAND flash on the Nokia N900 that regressed a while ago after
the move to configuring them from DT. Some other OMAPs now set the
correct dma limits on the L3 bus, and a regression fix addresses lost
Ethernet on dm814x
- One incorrect setting in the newly added Raspberry Pi Zero W that
may cause issues with the SD card controller.
- A missing property on the bcm2835 firmware node caused incorrect
DMA settings.
- An old bug on the oxnas platform causing spurious interrupts is
finally addressed.
- A regression on the Exynos Midas board broke the OLED panel
power supply.
- The i.MX6 phycore SoM specified the wrong voltage for the SoC,
this is now set to the values from the datasheet.
- Some 64-bit machines use a deprecated string to identify the PSCI
firmware.
There are also several small code fixes addressing mostly serious
issues:
- Fix the sunxi rsb bus access to no longer return incorrect data when
mixing 8 and 16 bit I/O.
- Fix a suspend/resume regression on the OMAP2+ lcdc from a missing
quirk in the ti-sysc driver
- Fix a NULL pointer access from a race in the fsl dpio driver
- Fix a v5.5 regression in the exynos-chipid driver that caused an
invalid error code probing the device on non-exynos platforms
- Fix an out-of-bounds access in the AMD TEE driver
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAl5+LG0ACgkQmmx57+YA
GNkZhhAAtWTv4sRf2faVzjAngWTs1LXuVpoX8UT2JXOMvY20Y1tQ6YzH8bkJahIr
oqPsEFOANkDGON+72+7YCFUVuT2rle9xPLUpdCv3F1Q3TAP8jslkvI/7tK21UKnG
OAsMaJdKeKg4yK+KJnh7OtOBvSJzJ0YUU8BCFs8rsSeTkMdPDz74YbC+jV974SVD
eCYj/Nih/wt1tG+q/W0tk0LdUtAsgQWbn3WFOrbQ0SSu8i+SVbulBc2oLsltO7VX
TFhSRimPAhxGcHJcCoD/enNuHGwKWFkGdQ7jGU3138ZP4PUztNMYKVgZmeUAH1m1
HXlZkpCSIDUjydEAPFJPJMGJumoKvPIf9kwq9f0ceukR8DKWW3suq/gl6C/AJcHE
K21ofuYftFZ13QXI3khv9SaBKSesEZ1qCVOj4jHNwunAjOc2+sNHdceO4rlD+N5M
xyIG/U3rO/6VOO7ex32q39x8vCDu2TFi4nxTPQTKIslKj55DgWLayhIyBPiEyo0R
UMopcoBOrw9LL2AA+ugTHU9CyXW1G3CMsUY/V+i2sZLElsJuVL3kvWaudttXzjei
O3yV9J8MNTTCPyN981nu+iBAoanqbRP+JZJf0dC2kj+fjB3N9Q8Bziy6XmN3P9Kv
7qvuSmG5YN3bc3oQKlaUPUWJVqYnsYVEjWh2SqhOmLn5WhK6F5c=
=31+Z
-----END PGP SIGNATURE-----
Merge tag 'arm-soc-fixes-5.6' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
Pull ARM DT and driver fixes from Arnd Bergmann:
"For the devicetree files, there are a total of 20 patches, almost
entirely for 32-bit machines:
- The Allwinner/sun9i r40 SoC dtsi file contains a number of issues,
both for correctness and for style that are addressed in separate
patches. This causes most of the changed lines of the DT updates
this time.
- More Allwinner updates fixing the identification of the security
system on sun8i/A33, a recent regression of the A83t ethernet, and
a few board specific issues on the TBS-A711 macine.
- Several bug fixes for OMAP dts files, most notably fixing the
timings for the NAND flash on the Nokia N900 that regressed a while
ago after the move to configuring them from DT. Some other OMAPs
now set the correct dma limits on the L3 bus, and a regression fix
addresses lost Ethernet on dm814x
- One incorrect setting in the newly added Raspberry Pi Zero W that
may cause issues with the SD card controller.
- A missing property on the bcm2835 firmware node caused incorrect
DMA settings.
- An old bug on the oxnas platform causing spurious interrupts is
finally addressed.
- A regression on the Exynos Midas board broke the OLED panel power
supply.
- The i.MX6 phycore SoM specified the wrong voltage for the SoC, this
is now set to the values from the datasheet.
- Some 64-bit machines use a deprecated string to identify the PSCI
firmware.
There are also several small code fixes addressing mostly serious
issues:
- Fix the sunxi rsb bus access to no longer return incorrect data
when mixing 8 and 16 bit I/O.
- Fix a suspend/resume regression on the OMAP2+ lcdc from a missing
quirk in the ti-sysc driver
- Fix a NULL pointer access from a race in the fsl dpio driver
- Fix a v5.5 regression in the exynos-chipid driver that caused an
invalid error code probing the device on non-exynos platforms
- Fix an out-of-bounds access in the AMD TEE driver"
* tag 'arm-soc-fixes-5.6' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (24 commits)
soc: samsung: chipid: Fix return value on non-Exynos platforms
arm64: dts: Fix leftover entry-methods for PSCI
ARM: dts: exynos: Fix regulator node aliasing on Midas-based boards
ARM: dts: oxnas: Fix clear-mask property
ARM: dts: bcm283x: Fix vc4's firmware bus DMA limitations
ARM: dts: omap5: Add bus_dma_limit for L3 bus
ARM: dts: omap4-droid4: Fix lost touchscreen interrupts
ARM: dts: dra7: Add bus_dma_limit for L3 bus
ARM: bcm2835-rpi-zero-w: Add missing pinctrl name
ARM: dts: sun8i: a33: add the new SS compatible
dt-bindings: crypto: add new compatible for A33 SS
ARM: dts: sun8i: r40: Move SPI device nodes based on address order
ARM: dts: sun8i: r40: Fix register base address for SPI2 and SPI3
ARM: dts: sun8i: r40: Move AHCI device node based on address order
ARM: dts: imx6: phycore-som: fix arm and soc minimum voltage
soc: fsl: dpio: register dpio irq handlers after dpio create
tee: amdtee: out of bounds read in find_session()
ARM: dts: N900: fix onenand timings
bus: ti-sysc: Fix quirk flags for lcdc on am335x
ARM: dts: Fix dm814x Ethernet by changing to use rgmii-id mode
...
A new file was added to the tracing directory that will allow a user to
place a PID into it and the task associated to that PID will not have its
events traced. If the event-fork option is enabled, then neither will the
children of that task have its events traced.
Cc: linux-kselftest@vger.kernel.org
Cc: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
A new file was added to the tracing directory that will allow a user to
place a PID into it and the task associated to that PID will not be traced
by the function tracer. If the function-fork option is enabled, then neither
will the children of that task be traced by the function tracer.
Cc: linux-kselftest@vger.kernel.org
Cc: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
There's currently a way to select a task that should only have its events
traced, but there's no way to select a task not to have itsevents traced.
Add a set_event_notrace_pid file that acts the same as set_event_pid (and is
also affected by event-fork), but the task pids in this file will not be
traced even if they are listed in the set_event_pid file. This makes it easy
for tools like trace-cmd to "hide" itself from beint traced by events when
it is recording other tasks.
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
There's currently a way to select a task that should only be traced by
functions, but there's no way to select a task not to be traced by the
function tracer. Add a set_ftrace_notrace_pid file that acts the same as
set_ftrace_pid (and is also affected by function-fork), but the task pids in
this file will not be traced even if they are listed in the set_ftrace_pid
file. This makes it easy for tools like trace-cmd to "hide" itself from the
function tracer when it is recording other tasks.
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
The set_ftrace_pid file is used to filter function tracing to only trace
tasks that are listed in that file. Instead of testing the pids listed in
that file (it's a bitmask) at each function trace event, the logic is done
via a sched_switch hook. A flag is set when the next task to run is in the
list of pids in the set_ftrace_pid file. But the sched_switch hook is not at
the exact location of when the task switches, and the flag gets set before
the task to be traced actually runs. This leaves a residue of traced
functions that do not belong to the pid that should be filtered on.
By changing the logic slightly, where instead of having a boolean flag to
test, record the pid that should be traced, with special values for not to
trace and always trace. Then at each function call, a check will be made to
see if the function should be ignored, or if the current pid matches the
function that should be traced, and only trace if it matches (or if it has
the special value to always trace).
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Now that reading the trace file does not temporarly stop tracing while it is
open, update the document to reflect this fact.
Link: http://lkml.kernel.org/r/20200317213417.209675068@goodmis.org
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Have the ring_buffer_iterator set a flag if events were dropped as it were
to go and peek at the next event. Have the trace file display this fact if
it happened with a "LOST EVENTS" message.
Link: http://lkml.kernel.org/r/20200317213417.045858900@goodmis.org
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
When opening the "trace" file, it is no longer necessary to disable tracing.
Note, a new option is created called "pause-on-trace", when set, will cause
the trace file to emulate its original behavior.
Link: http://lkml.kernel.org/r/20200317213416.903351225@goodmis.org
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
