Current code copies _all_ entries from the event into a worker, when we
later only need specific data from the first entry.
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
Reviewed-by: Alexandra Winter <wintera@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The only time that our Bridgeport role should change is when we change
the configuration ourselves. In which case we also adjust our internal
state tracking, no need to do it again when we receive the corresponding
event.
Removing the locked section helps a subsequent patch that needs to flush
the workqueue while under sbp_lock.
It would be nice to raise a warning here in case HW does weird things
after all, but this could end up generating false-positives when we
change the configuration ourselves.
Suggested-by: Alexandra Winter <wintera@linux.ibm.com>
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
Reviewed-by: Alexandra Winter <wintera@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
A newly initialized device is disabled for address events, there's no
need to explicitly disable them.
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
Reviewed-by: Alexandra Winter <wintera@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
queue->state is a ternary spinlock in disguise, used by
OSA's TX completion path to lock the Output Queue and flush any pending
packets on it to the device. If the Queue is already locked by our TX
code, setting the lock word to QETH_OUT_Q_LOCKED_FLUSH lets the TX
completion code move on - the TX path will later take care of things
when it unlocks the Queue.
This sort of DIY locking is a non-starter of course, just let the
TX completion path block on the spinlock when necessary. If that ends up
causing additional latency due to lock contention, then converting
the OSA path to use xmit_more is the right way to go forward.
Also slightly expand the locked section and capture all of
qeth_do_send_packet(), so that the update for the 'bufs_pack' statistics
is done race-free.
While reworking the TX completion path's code, remove a barrier() that
doesn't make any sense.
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Avoid poking around in the delayed_work struct's internals.
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Clarify that the 'ipacmd' parameter is an enum, and thus compatible to
what qeth_ipa_alloc_cmd() expects as input.
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Andrew Lunn says:
====================
Move MDIO drivers into their own directory
The phy subdirectory is getting cluttered. It has both PHY drivers and
MDIO drivers, plus a stray switch driver. Soon more PCS drivers are
likely to appear.
Move MDIO and PCS drivers into new directories. This requires fixing
up the xgene driver which uses a relative include path.
v2:
Move the subdirs to drivers/net, rather than drivers/net/phy.
v3:
Add subdirectories under include/linux for mdio and pcs
v4:
there->their
include path fix
No new kconfig prompts
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Sort the Kconfig based on the text shown in make menuconfig and sort
the Makefile by CONFIG symbol.
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Move all the MDIO drivers and multiplexers into drivers/net/mdio. The
mdio core is however left in the phy directory, due to mutual
dependencies between the MDIO core and the PHY core.
Take this opportunity to sort the Kconfig based on the menuconfig
strings, and move the multiplexers to the end with a separating
comment.
v2:
Fix typo in commit message
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
This header file is currently included into the ethernet driver via a
relative path into the PHY subsystem. This is bad practice, and causes
issues for the upcoming move of the MDIO driver. Move the header file
into include/linux to clean this up.
v2:
Move header to include/linux/mdio
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
In preparation for moving all MDIO drivers into drivers/net/mdio, move
the mdio-i2c header file into include/linux/mdio so it can be used by
both the MDIO driver and the SFP code which instantiates I2C MDIO
busses.
v2:
Add include/linux/mdio
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Create drivers/net/pcs and move the Synopsys DesignWare XPCS into the
new directory. Move the header file into a subdirectory
include/linux/pcs
Start a naming convention of all PCS files use the prefix pcs-, and
rename the XPCS files to fit.
v2:
Add include/linux/pcs
v4:
Fix include path in stmmac.
Remove PCS_DEVICES to avoid new prompts
Cc: Jose Abreu <Jose.Abreu@synopsys.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Let drivers advertise support for AP-mode SAE authentication offload
with a new NL80211_EXT_FEATURE_SAE_OFFLOAD_AP flag.
Signed-off-by: Chung-Hsien Hsu <stanley.hsu@cypress.com>
Signed-off-by: Chi-Hsien Lin <chi-hsien.lin@cypress.com>
Link: https://lore.kernel.org/r/20200817073316.33402-4-stanley.hsu@cypress.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
We want to reuse the functions and structs for other counters such as BSS
color change. Rename them to more generic names.
Signed-off-by: John Crispin <john@phrozen.org>
Link: https://lore.kernel.org/r/20200811080107.3615705-2-john@phrozen.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
We want to reuse the attributes for other counters such as BSS color
change. Rename them to more generic names.
Signed-off-by: John Crispin <john@phrozen.org>
Link: https://lore.kernel.org/r/20200811080107.3615705-1-john@phrozen.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This patch adds the nl80211 structs, definitions, policies and parsing
code required to pass fixed HE rate, GI and LTF settings.
Signed-off-by: Miles Hu <milehu@codeaurora.org>
Signed-off-by: John Crispin <john@phrozen.org>
Link: https://lore.kernel.org/r/20200804081630.2013619-1-john@phrozen.org
[fix comment]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The CMD_PORT_AUTHORIZED event was described as an event which indicated
a successfully completed 4-way handshake. But the behavior was
not as advertized. The only driver which uses this is brcmfmac, and
this driver only sends the event after a successful 802.1X-FT roam.
This prevents userspace applications from knowing if the 4-way completed
on:
1. Normal 802.1X connects
2. Normal PSK connections
3. FT-PSK roams
wpa_supplicant handles this incorrect behavior by just completing
the connection after association, before the 4-way has completed.
If the 4-way ends up failing it disconnects at that point.
Since this behavior appears to be expected (wpa_s handles it this
way) I have changed the wording in the API description to reflect the
actual behavior.
Signed-off-by: James Prestwood <prestwoj@gmail.com>
Link: https://lore.kernel.org/r/20200413162053.3711-1-prestwoj@gmail.com
[fix spelling of 802.1X throughout ...]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Some usable channels are located in the union of adjacent
regulatory rules, for example channel 144 in Germany.
Enable them, by also checking if a channel spans two adjacent
regulatory rules/frequency ranges.
All flags involved are disabling things, therefore we can build
the maximum by or-ing them together. Furthermore, take the maximum
of DFS CAC time values and the minimum of allowed power of both
adjacent channels in order to comply with both regulatory rules at
the same time.
Signed-off-by: Markus Theil <markus.theil@tu-ilmenau.de>
Link: https://lore.kernel.org/r/20200803144353.305538-2-markus.theil@tu-ilmenau.de
[remove unrelated comment changes]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
As a preparation to handle adjacent rule channels,
factor out handling channels located in a single
regulatory rule.
Signed-off-by: Markus Theil <markus.theil@tu-ilmenau.de>
Link: https://lore.kernel.org/r/20200803144353.305538-1-markus.theil@tu-ilmenau.de
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
We have a few attributes with minimum and maximum lengths that are
not the same, use the new feature of being able to specify both in
the policy to validate them, removing code and allowing this to be
advertised to userspace in the policy export.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://lore.kernel.org/r/20200819085642.8f12ffa14f33.I9d948d59870e521febcd79bb4a986b1de1dca47b@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Fix compilation warnings due to __u64 defined differently as `unsigned long`
or `unsigned long long` on different architectures (e.g., ppc64le differs from
x86-64). Also cast one argument to size_t to fix printf warning of similar
nature.
Fixes: eacaaed784 ("libbpf: Implement enum value-based CO-RE relocations")
Fixes: 50e09460d9 ("libbpf: Skip well-known ELF sections when iterating ELF")
Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/20200827041109.3613090-1-andriin@fb.com
bpf selftest test_progs/test_sk_assign failed with llvm 11 and llvm 12.
Compared to llvm 10, llvm 11 and 12 generates xor instruction which
is not handled properly in verifier. The following illustrates the
problem:
16: (b4) w5 = 0
17: ... R5_w=inv0 ...
...
132: (a4) w5 ^= 1
133: ... R5_w=inv(id=0,umax_value=4294967295,var_off=(0x0; 0xffffffff)) ...
...
37: (bc) w8 = w5
38: ... R5=inv(id=0,umax_value=4294967295,var_off=(0x0; 0xffffffff))
R8_w=inv(id=0,umax_value=4294967295,var_off=(0x0; 0xffffffff)) ...
...
41: (bc) w3 = w8
42: ... R3_w=inv(id=0,umax_value=4294967295,var_off=(0x0; 0xffffffff)) ...
45: (56) if w3 != 0x0 goto pc+1
... R3_w=inv0 ...
46: (b7) r1 = 34
47: R1_w=inv34 R7=pkt(id=0,off=26,r=38,imm=0)
47: (0f) r7 += r1
48: R1_w=invP34 R3_w=inv0 R7_w=pkt(id=0,off=60,r=38,imm=0)
48: (b4) w9 = 0
49: R1_w=invP34 R3_w=inv0 R7_w=pkt(id=0,off=60,r=38,imm=0)
49: (69) r1 = *(u16 *)(r7 +0)
invalid access to packet, off=60 size=2, R7(id=0,off=60,r=38)
R7 offset is outside of the packet
At above insn 132, w5 = 0, but after w5 ^= 1, we give a really conservative
value of w5. At insn 45, in reality the condition should be always false.
But due to conservative value for w3, the verifier evaluates it could be
true and this later leads to verifier failure complaining potential
packet out-of-bound access.
This patch implemented proper XOR support in verifier.
In the above example, we have:
132: R5=invP0
132: (a4) w5 ^= 1
133: R5_w=invP1
...
37: (bc) w8 = w5
...
41: (bc) w3 = w8
42: R3_w=invP1
...
45: (56) if w3 != 0x0 goto pc+1
47: R3_w=invP1
...
processed 353 insns ...
and the verifier can verify the program successfully.
Signed-off-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: John Fastabend <john.fastabend@gmail.com>
Link: https://lore.kernel.org/bpf/20200825064608.2017937-1-yhs@fb.com
Rikard Falkeborn says:
====================
drivers/net: constify static ops-variables
This series constifies a number of static ops variables, to allow the
compiler to put them in read-only memory. Compile-tested only.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
The only usage of ath11k_thermal_ops is to pass its address to
thermal_cooling_device_register() which takes a const pointer. Make it
const to allow the compiler to put it in read-only memory.
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The only usage of vsc8584_macsec_ops is to assign its address to the
macsec_ops field in the phydev struct, which is a const pointer. Make it
const to allow the compiler to put it in read-only memory.
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The only usage of vddio_regulator_ops and vddh_regulator_ops is to
assign their address to the ops field in the regulator_desc struct,
which is a const pointer. Make them const to allow the compiler to
put them in read-only memory.
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The only usage of bb_ops is to assign its address to the ops field in
the mdiobb_ctrl struct, which is a const pointer. Make it const to allow
the compiler to put it in read-only memory.
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The only usage of bb_ops is to assign its address to the ops field in
the mdiobb_ctrl struct, which is a const pointer. Make it const to allow
the compiler to put it in read-only memory.
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The only usage of qca_serdev_ops is to pass its address to
serdev_device_set_client_ops() which takes a const pointer. Make it
const to allow the compiler to put it in read-only memory.
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Remove linux/notifier.h which is included more than once
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Wang Hai <wanghai38@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Lijun Pan says:
====================
refactoring of ibmvnic code
This patch series refactor reset_init and init functions,
and make some other cosmetic changes to make the code
easier to read and debug. v2 removes __func__ and v1's 1/5.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
These two functions share the majority of the code, hence merge
them together. In the meanwhile, add a reset pass-in parameter
to differentiate them. Thus, the code is easier to read and to tell
the difference between reset_init and regular init.
Signed-off-by: Lijun Pan <ljp@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
At the beginning of the function, from_passive_init is set false by
"adapter->from_passive_init = false;",
hence the if statement will never run.
Signed-off-by: Lijun Pan <ljp@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When H_SEND_CRQ command returns with H_CLOSED, it means the
server's CRQ is not ready yet. Instead of resetting immediately,
we wait for the server to launch passive init.
ibmvnic_init() and ibmvnic_reset_init() should also return the
error code from ibmvnic_send_crq_init() call.
Signed-off-by: Lijun Pan <ljp@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Instead of comparing (adapter->init_done_rc == 1), let it
be (adapter->init_done_rc == PARTIALSUCCESS).
Signed-off-by: Lijun Pan <ljp@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Ido Schimmel says:
====================
ipv4: nexthop: Various improvements
This patch set contains various improvements that I made to the nexthop
object code while studying it towards my upcoming changes.
While patches #4 and #6 fix bugs, they are not regressions (never
worked). They also do not occur to me as critical issues, which is why I
am targeting them at net-next.
Tested with fib_nexthops.sh:
Tests passed: 134
Tests failed: 0
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Test that an IPv6 route can not use a nexthop group with mixed IPv4 and
IPv6 nexthops, but can use it after replacing the IPv4 nexthops with
IPv6 nexthops.
Output without previous patch:
# ./fib_nexthops.sh -t ipv6_fcnal_runtime
IPv6 functional runtime
-----------------------
TEST: Route add [ OK ]
TEST: Route delete [ OK ]
TEST: Ping with nexthop [ OK ]
TEST: Ping - multipath [ OK ]
TEST: Ping - blackhole [ OK ]
TEST: Ping - blackhole replaced with gateway [ OK ]
TEST: Ping - gateway replaced by blackhole [ OK ]
TEST: Ping - group with blackhole [ OK ]
TEST: Ping - group blackhole replaced with gateways [ OK ]
TEST: IPv6 route with device only nexthop [ OK ]
TEST: IPv6 multipath route with nexthop mix - dev only + gw [ OK ]
TEST: IPv6 route can not have a v4 gateway [ OK ]
TEST: Nexthop replace - v6 route, v4 nexthop [ OK ]
TEST: Nexthop replace of group entry - v6 route, v4 nexthop [ OK ]
TEST: IPv6 route can not have a group with v4 and v6 gateways [ OK ]
TEST: IPv6 route can not have a group with v4 and v6 gateways [ OK ]
TEST: IPv6 route using a group after removing v4 gateways [ OK ]
TEST: IPv6 route can not have a group with v4 and v6 gateways [ OK ]
TEST: IPv6 route can not have a group with v4 and v6 gateways [ OK ]
TEST: IPv6 route using a group after replacing v4 gateways [FAIL]
TEST: Nexthop with default route and rpfilter [ OK ]
TEST: Nexthop with multipath default route and rpfilter [ OK ]
Tests passed: 21
Tests failed: 1
Output with previous patch:
# ./fib_nexthops.sh -t ipv6_fcnal_runtime
IPv6 functional runtime
-----------------------
TEST: Route add [ OK ]
TEST: Route delete [ OK ]
TEST: Ping with nexthop [ OK ]
TEST: Ping - multipath [ OK ]
TEST: Ping - blackhole [ OK ]
TEST: Ping - blackhole replaced with gateway [ OK ]
TEST: Ping - gateway replaced by blackhole [ OK ]
TEST: Ping - group with blackhole [ OK ]
TEST: Ping - group blackhole replaced with gateways [ OK ]
TEST: IPv6 route with device only nexthop [ OK ]
TEST: IPv6 multipath route with nexthop mix - dev only + gw [ OK ]
TEST: IPv6 route can not have a v4 gateway [ OK ]
TEST: Nexthop replace - v6 route, v4 nexthop [ OK ]
TEST: Nexthop replace of group entry - v6 route, v4 nexthop [ OK ]
TEST: IPv6 route can not have a group with v4 and v6 gateways [ OK ]
TEST: IPv6 route can not have a group with v4 and v6 gateways [ OK ]
TEST: IPv6 route using a group after removing v4 gateways [ OK ]
TEST: IPv6 route can not have a group with v4 and v6 gateways [ OK ]
TEST: IPv6 route can not have a group with v4 and v6 gateways [ OK ]
TEST: IPv6 route using a group after replacing v4 gateways [ OK ]
TEST: Nexthop with default route and rpfilter [ OK ]
TEST: Nexthop with multipath default route and rpfilter [ OK ]
Tests passed: 22
Tests failed: 0
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: David Ahern <dsahern@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Each nexthop group contains an indication if it has IPv4 nexthops
('has_v4'). Its purpose is to prevent IPv6 routes from using groups with
IPv4 nexthops.
However, the indication is not updated when a nexthop is replaced. This
results in the kernel wrongly rejecting IPv6 routes from pointing to
groups that only contain IPv6 nexthops. Example:
# ip nexthop replace id 1 via 192.0.2.2 dev dummy10
# ip nexthop replace id 10 group 1
# ip nexthop replace id 1 via 2001:db8:1::2 dev dummy10
# ip route replace 2001:db8:10::/64 nhid 10
Error: IPv6 routes can not use an IPv4 nexthop.
Solve this by iterating over all the nexthop groups that the replaced
nexthop is a member of and potentially update their IPv4 indication
according to the new set of member nexthops.
Avoid wasting cycles by only performing the update in case an IPv4
nexthop is replaced by an IPv6 nexthop.
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: David Ahern <dsahern@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Test that an IPv6 route can not use a nexthop group with mixed IPv4 and
IPv6 nexthops, but can use it after deleting the IPv4 nexthops.
Output without previous patch:
# ./fib_nexthops.sh -t ipv6_fcnal_runtime
IPv6 functional runtime
-----------------------
TEST: Route add [ OK ]
TEST: Route delete [ OK ]
TEST: Ping with nexthop [ OK ]
TEST: Ping - multipath [ OK ]
TEST: Ping - blackhole [ OK ]
TEST: Ping - blackhole replaced with gateway [ OK ]
TEST: Ping - gateway replaced by blackhole [ OK ]
TEST: Ping - group with blackhole [ OK ]
TEST: Ping - group blackhole replaced with gateways [ OK ]
TEST: IPv6 route with device only nexthop [ OK ]
TEST: IPv6 multipath route with nexthop mix - dev only + gw [ OK ]
TEST: IPv6 route can not have a v4 gateway [ OK ]
TEST: Nexthop replace - v6 route, v4 nexthop [ OK ]
TEST: Nexthop replace of group entry - v6 route, v4 nexthop [ OK ]
TEST: IPv6 route can not have a group with v4 and v6 gateways [ OK ]
TEST: IPv6 route can not have a group with v4 and v6 gateways [ OK ]
TEST: IPv6 route using a group after deleting v4 gateways [FAIL]
TEST: Nexthop with default route and rpfilter [ OK ]
TEST: Nexthop with multipath default route and rpfilter [ OK ]
Tests passed: 18
Tests failed: 1
Output with previous patch:
bash-5.0# ./fib_nexthops.sh -t ipv6_fcnal_runtime
IPv6 functional runtime
-----------------------
TEST: Route add [ OK ]
TEST: Route delete [ OK ]
TEST: Ping with nexthop [ OK ]
TEST: Ping - multipath [ OK ]
TEST: Ping - blackhole [ OK ]
TEST: Ping - blackhole replaced with gateway [ OK ]
TEST: Ping - gateway replaced by blackhole [ OK ]
TEST: Ping - group with blackhole [ OK ]
TEST: Ping - group blackhole replaced with gateways [ OK ]
TEST: IPv6 route with device only nexthop [ OK ]
TEST: IPv6 multipath route with nexthop mix - dev only + gw [ OK ]
TEST: IPv6 route can not have a v4 gateway [ OK ]
TEST: Nexthop replace - v6 route, v4 nexthop [ OK ]
TEST: Nexthop replace of group entry - v6 route, v4 nexthop [ OK ]
TEST: IPv6 route can not have a group with v4 and v6 gateways [ OK ]
TEST: IPv6 route can not have a group with v4 and v6 gateways [ OK ]
TEST: IPv6 route using a group after deleting v4 gateways [ OK ]
TEST: Nexthop with default route and rpfilter [ OK ]
TEST: Nexthop with multipath default route and rpfilter [ OK ]
Tests passed: 19
Tests failed: 0
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: David Ahern <dsahern@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Julian Wiedmann