Only two bits (RX0OVR and RX1OVR) are writable in EFLG, write is useless
if these bits aren't set.
Signed-off-by: Ed Spiridonov <edo.rus@gmail.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
When the interface is opened (in be_open()) the routine
be_enable_if_filters() must be called to switch on the basic filtering
capabilities of an interface that are not changed at run-time.
These include the flags UNTAGGED, BROADCAST and PASS_L3L4_ERRORS.
Other flags such as MULTICAST and PROMISC must be enabled later by
be_set_rx_mode() based on the state in the netdev/adapter struct.
be_enable_if_filters() routine is wrongly trying to enable MULTICAST flag
without checking the current adapter state. This can cause the RX_FILTER
cmds to the FW to fail. This patch fixes this problem by only enabling
the basic filtering flags in be_enable_if_filters().
The VF must be able to issue RX_FILTER cmd with any filter flag, as long
as the PF allowed those flags (if_cap_flags) in the iface it provisioned
for the VF. This rule is applicable even when the VF doesn't have the
FILTMGMT privilege. There is a bug in BE3 FW that wrongly fails RX_FILTER
multicast programming cmds on VFs that don't have FILTMGMT privilege.
This patch also helps in insulating the VF driver from be_open failures due
to the FW bug. A fix for the BE3 FW issue will be available in
versions >= 11.0.283.0 and 10.6.334.0
Reported-by: Ivan Vecera <ivecera@redhat.com>
Signed-off-by: Venkat Duvvuru <venkatkumar.duvvuru@avagotech.com>
Signed-off-by: Sathya Perla <sathya.perla@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
We accidentally return IS_ERR(priv->base) which is 1 instead of
PTR_ERR(priv->base) which is the error code.
Fixes: 6c821bd9ed ('net: Add MOXA ART SoCs ethernet driver')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add a maintainer entry for FREESCALE FEC ethernet driver and add myself
as a maintainer.
Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
Acked-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When signalling to metadata consumers that the metadata_dst entry
carries additional GBP extension data for vxlan (TUNNEL_VXLAN_OPT),
the dst's vxlan_metadata information is populated, but options_len
is left to zero. F.e. in ovs, ovs_flow_key_extract() checks for
options_len before extracting the data through ip_tunnel_info_opts_get().
Geneve uses ip_tunnel_info_opts_set() helper in receive path, which
sets options_len internally, vxlan however uses ip_tunnel_info_opts(),
so when filling vxlan_metadata, we do need to update options_len.
Fixes: 4c22279848 ("ip-tunnel: Use API to access tunnel metadata options.")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Thomas Graf <tgraf@suug.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
This change will also make Coverity happy by avoiding a theoretical NULL
pointer dereference; yet another reason is to use the above helper function
to tighten the code and make it more readable.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
This change will also make Coverity happy by avoiding a theoretical NULL
pointer dereference; yet another reason is to use the above helper function
to tighten the code and make it more readable.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: David S. Miller <davem@davemloft.net>
The ibmvnic_capability struct was defined incorrectly. The last two
elements of the struct are in the wrong order. In addition, the number
element should be 64-bit. Byteswapping functions are updated
as well.
Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When ipv6_find_hdr is used to find a fragment header
(caller specifies target NEXTHDR_FRAGMENT) we erronously return
-ENOENT for all fragments with nonzero offset.
Before commit 9195bb8e38, when target was specified, we did not
enter the exthdr walk loop as nexthdr == target so this used to work.
Now we do (so we can skip empty route headers). When we then stumble upon
a frag with nonzero frag_off we must return -ENOENT ("header not found")
only if the caller did not specifically request NEXTHDR_FRAGMENT.
This allows nfables exthdr expression to match ipv6 fragments, e.g. via
nft add rule ip6 filter input frag frag-off gt 0
Fixes: 9195bb8e38 ("ipv6: improve ipv6_find_hdr() to skip empty routing headers")
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
The MC74xx and EM74xx modules use different IDs by default, according
to the Lenovo EM7455 driver for Windows.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
reverts commit 94153e36e7 ("tipc: use existing sk_write_queue for
outgoing packet chain")
In Commit 94153e36e7, we assume that we fill & empty the socket's
sk_write_queue within the same lock_sock() session.
This is not true if the link is congested. During congestion, the
socket lock is released while we wait for the congestion to cease.
This implementation causes a nullptr exception, if the user space
program has several threads accessing the same socket descriptor.
Consider two threads of the same program performing the following:
Thread1 Thread2
-------------------- ----------------------
Enter tipc_sendmsg() Enter tipc_sendmsg()
lock_sock() lock_sock()
Enter tipc_link_xmit(), ret=ELINKCONG spin on socket lock..
sk_wait_event() :
release_sock() grab socket lock
: Enter tipc_link_xmit(), ret=0
: release_sock()
Wakeup after congestion
lock_sock()
skb = skb_peek(pktchain);
!! TIPC_SKB_CB(skb)->wakeup_pending = tsk->link_cong;
In this case, the second thread transmits the buffers belonging to
both thread1 and thread2 successfully. When the first thread wakeup
after the congestion it assumes that the pktchain is intact and
operates on the skb's in it, which leads to the following exception:
[2102.439969] BUG: unable to handle kernel NULL pointer dereference at 00000000000000d0
[2102.440074] IP: [<ffffffffa005f330>] __tipc_link_xmit+0x2b0/0x4d0 [tipc]
[2102.440074] PGD 3fa3f067 PUD 3fa6b067 PMD 0
[2102.440074] Oops: 0000 [#1] SMP
[2102.440074] CPU: 2 PID: 244 Comm: sender Not tainted 3.12.28 #1
[2102.440074] RIP: 0010:[<ffffffffa005f330>] [<ffffffffa005f330>] __tipc_link_xmit+0x2b0/0x4d0 [tipc]
[...]
[2102.440074] Call Trace:
[2102.440074] [<ffffffff8163f0b9>] ? schedule+0x29/0x70
[2102.440074] [<ffffffffa006a756>] ? tipc_node_unlock+0x46/0x170 [tipc]
[2102.440074] [<ffffffffa005f761>] tipc_link_xmit+0x51/0xf0 [tipc]
[2102.440074] [<ffffffffa006d8ae>] tipc_send_stream+0x11e/0x4f0 [tipc]
[2102.440074] [<ffffffff8106b150>] ? __wake_up_sync+0x20/0x20
[2102.440074] [<ffffffffa006dc9c>] tipc_send_packet+0x1c/0x20 [tipc]
[2102.440074] [<ffffffff81502478>] sock_sendmsg+0xa8/0xd0
[2102.440074] [<ffffffff81507895>] ? release_sock+0x145/0x170
[2102.440074] [<ffffffff815030d8>] ___sys_sendmsg+0x3d8/0x3e0
[2102.440074] [<ffffffff816426ae>] ? _raw_spin_unlock+0xe/0x10
[2102.440074] [<ffffffff81115c2a>] ? handle_mm_fault+0x6ca/0x9d0
[2102.440074] [<ffffffff8107dd65>] ? set_next_entity+0x85/0xa0
[2102.440074] [<ffffffff816426de>] ? _raw_spin_unlock_irq+0xe/0x20
[2102.440074] [<ffffffff8107463c>] ? finish_task_switch+0x5c/0xc0
[2102.440074] [<ffffffff8163ea8c>] ? __schedule+0x34c/0x950
[2102.440074] [<ffffffff81504e12>] __sys_sendmsg+0x42/0x80
[2102.440074] [<ffffffff81504e62>] SyS_sendmsg+0x12/0x20
[2102.440074] [<ffffffff8164aed2>] system_call_fastpath+0x16/0x1b
In this commit, we maintain the skb list always in the stack.
Signed-off-by: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan@ericsson.com>
Acked-by: Ying Xue <ying.xue@windriver.com>
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The current reserved_tailroom calculation fails to take hlen and tlen into
account.
skb:
[__hlen__|__data____________|__tlen___|__extra__]
^ ^
head skb_end_offset
In this representation, hlen + data + tlen is the size passed to alloc_skb.
"extra" is the extra space made available in __alloc_skb because of
rounding up by kmalloc. We can reorder the representation like so:
[__hlen__|__data____________|__extra__|__tlen___]
^ ^
head skb_end_offset
The maximum space available for ip headers and payload without
fragmentation is min(mtu, data + extra). Therefore,
reserved_tailroom
= data + extra + tlen - min(mtu, data + extra)
= skb_end_offset - hlen - min(mtu, skb_end_offset - hlen - tlen)
= skb_tailroom - min(mtu, skb_tailroom - tlen) ; after skb_reserve(hlen)
Compare the second line to the current expression:
reserved_tailroom = skb_end_offset - min(mtu, skb_end_offset)
and we can see that hlen and tlen are not taken into account.
The min() in the third line can be expanded into:
if mtu < skb_tailroom - tlen:
reserved_tailroom = skb_tailroom - mtu
else:
reserved_tailroom = tlen
Depending on hlen, tlen, mtu and the number of multicast address records,
the current code may output skbs that have less tailroom than
dev->needed_tailroom or it may output more skbs than needed because not all
space available is used.
Fixes: 4c672e4b ("ipv6: mld: fix add_grhead skb_over_panic for devs with large MTUs")
Signed-off-by: Benjamin Poirier <bpoirier@suse.com>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Currently, in a case of error, dev_err is using fman->dev
before its initialization and "(NULL device *)" is printed.
This patch fixes this issue.
Signed-off-by: Igal Liberman <igal.liberman@freescale.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch manages the case when you have an Ethernet MAC with
a "fixed link", and not connected to a normal MDIO-managed PHY device.
The test of phy_bus_name was not helpful because it was never affected
and replaced by the mdio test node.
Signed-off-by: Gabriel Fernandez <gabriel.fernandez@linaro.org>
Acked-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Lars Persson says:
====================
dwc_eth_qos: stability fixes and support for CMA
This series has bug fixes for the dwc_eth_qos ethernet driver.
Mainly two stability fixes for problems found by Rabin Vincent:
- Successive starts and stops of the interface would trigger a DMA reset timeout.
- A race condition in the TX DMA handling could trigger a netdev watchdog
timeout.
The memory allocation was improved to support use of the CMA as DMA allocator
backend.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
This reverts the changed init order from commit 3647bc35bd
("dwc_eth_qos: Reset hardware before PHY start") and makes another fix
for the race.
It turned out that the reset state machine of the dwceqos hardware
requires PHY clocks to be present in order to complete the reset
cycle.
To plug the race with the phy state machine we defer link speed
setting until the hardware init has finished.
Signed-off-by: Lars Persson <larper@axis.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Since debug is hardcoded to 3, the defaults in the DWCEQOS_MSG_DEFAULT
macro are never used, which does not seem to be the intended behaviour
here. Set debug to -1 like other drivers so that DWCEQOS_MSG_DEFAULT is
actually used by default.
Signed-off-by: Rabin Vincent <rabinv@axis.com>
Signed-off-by: Lars Persson <larper@axis.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Since we are in non-atomic context here we can pass GFP_KERNEL to
dma_alloc_coherent(). This enables use of the CMA.
Signed-off-by: Rabin Vincent <rabinv@axis.com>
Signed-off-by: Lars Persson <larper@axis.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
To prepare for using the CMA, we can not be in atomic context when
de-allocating DMA buffers.
The tx lock was needed only to protect the hw reset against the xmit
handler. Now we briefly grab the tx lock while stopping the queue to
make sure no thread is inside or will enter the xmit handler.
Signed-off-by: Lars Persson <larper@axis.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The xmit handler and the tx_reclaim tasklet had a race on the tx_free
variable which could lead to a tx timeout if tx_free was updated after
the tx complete interrupt.
Signed-off-by: Rabin Vincent <rabinv@axis.com>
Signed-off-by: Lars Persson <larper@axis.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Or Gerlitz says:
====================
Mellanox 10/40G mlx4 driver fixes for 4.5-rc6
This series contains two fixes for the SRIOV HW LAG that was
introduced in 4.5-rc1 and one fix that allows to revoke the
administrative MAC that was assigned to VF through the PF.
The VF mac fix needs to go for stable too.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
The VF administrative mac addresses (stored in the PF driver) are
initialized to zero when the PF driver starts up.
These addresses may be modified in the PF driver through ndo calls
initiated by iproute2 or libvirt.
While we allow the PF/host to change the VF admin mac address from zero
to a valid unicast mac, we do not allow restoring the VF admin mac to
zero. We currently only allow changing this mac to a different unicast mac.
This leads to problems when libvirt scripts are used to deal with
VF mac addresses, and libvirt attempts to revoke the mac so this
host will not use it anymore.
Fix this by allowing resetting a VF administrative MAC back to zero.
Fixes: 8f7ba3ca12 ('net/mlx4: Add set VF mac address support')
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Reported-by: Moshe Levi <moshele@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The limit of 63 is only for virtual functions while the actual enforcement
was for VFs plus physical functions, fix that.
Fixes: e57968a10b ('net/mlx4_core: Support the HA mode for SRIOV VFs too')
Signed-off-by: Moni Shoua <monis@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In the mac and vlan register/unregister/replace functions, the driver locks
the mac table mutex (or vlan table mutex) on both ports.
We move to use mutex_lock_nested() to prevent warnings, such as the one below.
[ 101.828445] =============================================
[ 101.834820] [ INFO: possible recursive locking detected ]
[ 101.841199] 4.5.0-rc2+ #49 Not tainted
[ 101.850251] ---------------------------------------------
[ 101.856621] modprobe/3054 is trying to acquire lock:
[ 101.862514] (&table->mutex#2){+.+.+.}, at: [<ffffffffa079c10e>] __mlx4_register_mac+0x87e/0xa90 [mlx4_core]
[ 101.874598]
[ 101.874598] but task is already holding lock:
[ 101.881703] (&table->mutex#2){+.+.+.}, at: [<ffffffffa079c0f0>] __mlx4_register_mac+0x860/0xa90 [mlx4_core]
[ 101.893776]
[ 101.893776] other info that might help us debug this:
[ 101.901658] Possible unsafe locking scenario:
[ 101.901658]
[ 101.908859] CPU0
[ 101.911923] ----
[ 101.914985] lock(&table->mutex#2);
[ 101.919595] lock(&table->mutex#2);
[ 101.924199]
[ 101.924199] * DEADLOCK *
[ 101.924199]
[ 101.931643] May be due to missing lock nesting notation
Fixes: 5f61385d2e ('net/mlx4_core: Keep VLAN/MAC tables mirrored in multifunc HA mode')
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Suggested-by: Doron Tsur <doront@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Saeed Mahameed says:
====================
Mellanox 100G mlx5 driver fixes
This series has few bug fixes for the mlx5 Ethernet driver.
Eran fixed a locking issue with time-stamping that could cause a
soft-lockup when time-stamping is enabled.
Gal fixed the rx/tx packets/bytes counters returned by the driver to
actually went through the network stack.
Tariq removed a poll CQ optimization which could lead the driver to
stop getting interrupts for some of the rings, and a did also fix to
HW LRO which is currently broken.
He also provided RSS and RX hash fixes for the case of changing the
number of rx rings the RX hash/RSS configuration will be out of sync.
The time stamping fix from Eran is not for -stable as the feature was
only introduced in 4.5 but all of the others are.
Changes fro V0:
- Eran addressed the irqsave/restore comments from "Dave" and fixed them.
This series is generated against net commit 4c0b6eaf37 'net:
thunderx: Fix for Qset error due to CQ full'
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Using the HW VPort counters for traffic (rx/tx packets/bytes)
statistics is wrong. This is because frames dropped due to steering or
out of buffer will be counted as received. To fix that, we move to use
the packet/bytes accounting done by the driver for what the netdev
reports out.
Fixes: f62b8bb8f2 ('net/mlx5: Extend mlx5_core to support [...]')
Signed-off-by: Gal Pressman <galp@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Sum up rx/tx bytes in software as we do for rx/tx packets, to be reported
in upcoming statistics fix.
Signed-off-by: Gal Pressman <galp@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Upon changing num_channels, reset the RSS indirection table to
match the new value.
Fixes: 2d75b2bc8a ('net/mlx5e: Add ethtool RSS configuration options')
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
We should modify TIRs explicitly to apply the new RSS configuration.
The light ndo close/open calls do not "refresh" them.
Fixes: 2d75b2bc8a ('net/mlx5e: Add ethtool RSS configuration options')
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Readers/Writers lock for SW timecounter was acquired without disabling
interrupts on local CPU.
The problematic scenario:
* HW timestamping is enabled
* Timestamp overflow periodic service task is running on local CPU and
holding write_lock for SW timecounter
* Completion arrives, triggers interrupt for local CPU.
Interrupt routine calls napi_schedule(), which triggers rx/tx
skb process.
An attempt to read SW timecounter using read_lock is done, which is
already locked by a writer on the same CPU and cause soft lockup.
Add irqsave/irqrestore for when using the readers/writers lock for
writing.
Fixes: ef9814deaf ('net/mlx5e: Add HW timestamping (TS) support')
Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Ethtool LRO enable/disable is broken, as of today we only modify TCP
TIRs in order to apply the requested configuration.
Hardware requires that all TIRs pointing to the same RQ should share the
same LRO configuration. For that all other TIRs' LRO fields must be
modified as well.
Fixes: 5c50368f38 ('net/mlx5e: Light-weight netdev open/stop')
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
With the MLX5E_CQ_HAS_CQES optimization flag, the following buggy
flow might occur:
- Suppose RX is always busy, TX has a single packet every second.
- We poll a single TX cqe and clear its flag.
- We never arm it again as RX is always busy.
- TX CQ flag is never changed, and new TX cqes are not polled.
We revert this optimization.
Fixes: e586b3b0ba ('net/mlx5: Ethernet Datapath files')
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
For RTL8168G/RTL8168H/RTL8411B/RTL8107E, enable this flag to eliminate
message "AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0002
address=0x0000000000003000 flags=0x0050] in dmesg.
Signed-off-by: Chunhao Lin <hau@realtek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
* check GCMP encryption vs. fragmentation properly; we'd found
this problem quite a while ago but waited for the 802.11 spec
to be updated
* fix RTS/CTS logic in minstrel_ht
* fix RX of certain public action frames in AP mode
* add mac80211_hwsim to MAC80211 in MAINTAINERS, this helps
the kbuild robot pick up the right tree for it
-----BEGIN PGP SIGNATURE-----
iQIcBAABCgAGBQJW1u7EAAoJEGt7eEactAAdZXsP/il3dCxYtqYtBOzmR8OkDztn
yJiapt9aZ/u1a1mfDKfsJ2/8OLsE4pY/fp3G8TttURKNB/26sHWUEYSHWV2Ecfmi
4QFvAiUeO9Ue50ggASno239hp51KIKGcVF5flqKrCjTaSSyUm8YR78S1NlH2N+lT
i+i/AidHEdLnTgvYGOUhWu3QyL7Bm5t5wVZPivZUs0Zoos+tTokEj40eYmetQX27
lQMGa/xbvLHYeBcuLSgdQbzUR1jzOi70b9+QkjqhrYrlsc+MZE8ghwOgeAeQx56B
0sg0fZZVI8DIaCD5S3Pj8EP0WnP990DtM+4nSvtfFUYJxEM7LthEV+bs4Gr1MR2q
dZESMisKoRWBf2SyUhoVeUO6bV5kY+eTz/wyQCTdFsp9u6jzOgiY7y2aliqbJFgD
0Ydbyqq1dAeRqFaTg/46OAXkUxHW7/8hQC78Cmintevd1nHivZC3eevG6xj22G1N
eUvqy+OIv0d2Hg8+CL6oBsexQrKLg4bQFPR6s/doPnXtgsh5JccFYWujClsrNL26
kRb1kYrIqoVWXwnPp1dLF02s6Ny0+AW4xHLQIAwz5HACsJp+SjnpRP3WF9FTPs3V
T71dXQ48MLrQ/EVidCpMwJYoUnZ+BWeUf5hHpkxILIP1f0elx3i50eshlMNA/kwb
YzufoqiQhICciwEBAgBM
=2rZC
-----END PGP SIGNATURE-----
Merge tag 'mac80211-for-davem-2016-03-02' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
Johannes Berg says:
====================
Here are a few more fixes for the current cycle:
* check GCMP encryption vs. fragmentation properly; we'd found
this problem quite a while ago but waited for the 802.11 spec
to be updated
* fix RTS/CTS logic in minstrel_ht
* fix RX of certain public action frames in AP mode
* add mac80211_hwsim to MAC80211 in MAINTAINERS, this helps
the kbuild robot pick up the right tree for it
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Michal Schmidt says:
====================
bnx2x: endianness fixes
this fixes a VLAN crash and some SRIOV bugs in bnx2x observed on ppc64.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
For consistency with other event data structs and to lessen
the chance of a mistake should one of the reserved fields become
used in the future, define the reserved fields as little-endian.
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
There were no missing endianness conversions in this case, but the
fields of struct cfc_del_event_data should be defined as little-endian
to get rid of the ugly (__force __le32) casts.
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
It's not really a bug, but it was odd that bnx2x_eq_int() read the
message data as if it were a cfc_del_event regardless of the event type.
It's cleaner to access only the appropriate member of union event_data
after checking the event opcode.
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
On ppc64 the PF did not receive messages from VFs correctly.
Fields of struct vf_pf_event_data are little-endian.
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When a VF is sending a message to the PF, it needs to trigger the PF
to tell it the message is ready.
The trigger did not work on ppc64. No interrupt appeared in the PF.
The bug is due to confusion about the layout of struct trigger_vf_zone.
In bnx2x_send_msg2pf() the trigger is written using writeb(), not
writel(), so the attempt to define the struct with a reversed layout on
big-endian is counter-productive.
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
bnx2x crashes during the initialization of the 8021q module on ppc64.
The bug is a missing conversion from le32 in
bnx2x_handle_classification_eqe() when obtaining the cid value from
struct eth_event_data.
The fields in struct eth_event_data should all be declared as
little-endian and conversions added where missing.
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Since I maintain this driver as part of mac80211, add it to
the file list for mac80211; this helps submitters send it to
me instead of Kalle and also makes the build robot apply the
patches for it on the right tree for build attempts.
Acked-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The 'flags' parameter of the of_phy_connect() function wasn't described
in the kernel-doc comment...
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Now in sctp_remaddr_seq_show(), we use variable *tsp to get the param *v.
but *tsp is also used to traversal transport_addr_list, which will cover
the previous value, and make sctp_transport_put work on the wrong transport.
So fix it by adding a new variable to get the param *v.
Fixes: fba4c330c5 ("sctp: hold transport before we access t->asoc in sctp proc")
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
As the member .cmp_addr of sctp_af_inet6, sctp_v6_cmp_addr should also check
the port of addresses, just like sctp_v4_cmp_addr, cause it's invoked by
sctp_cmp_addr_exact().
Now sctp_v6_cmp_addr just check the port when two addresses have different
family, and lack the port check for two ipv6 addresses. that will make
sctp_hash_cmp() cannot work well.
so fix it by adding ports comparison in sctp_v6_cmp_addr().
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Alexandre Belloni says:
====================
phy: micrel: fix issues with interrupt on atmel boards
Since the phy is not polled anymore, there were issues getting a link on the
sama5d* xplained boards.
I'm not too sure about were those fixes should go and I'm wondering whether the
first one shoud be made generic.
For the second one, I found the PHY_HAS_MAGICANEG flag that is not used and I
wondering whether this is related to that kind of issue. I had a quick look at
the history and could'nt find its use.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Disable auto negotiation on init to properly detect an already plugged
cable at boot.
At boot, when the phy is started, it is in the PHY_UP state.
However, if a cable is plugged at boot, because auto negociation is already
enabled at the time we get the first interrupt, the phy is already running.
But the state machine then switches from PHY_UP to PHY_AN and calls
phy_start_aneg(). phy_start_aneg() will not do anything because aneg is
already enabled on the phy. It will then wait for a interrupt before going
further. This interrupt will never happen unless the cable is unplugged and
then replugged.
It was working properly before 321beec504 (net: phy: Use interrupts when
available in NOLINK state) because switching to NOLINK meant starting
polling the phy, even if IRQ were enabled.
Fixes: 321beec504 (net: phy: Use interrupts when available in NOLINK state)
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
At least on ksz8081, when getting back from power down, interrupts are
disabled. ensure they are reenabled if they were previously enabled.
This fixes resuming which is failing on the xplained boards from atmel
since 321beec504 (net: phy: Use interrupts when available in NOLINK
state)
Fixes: 321beec504 (net: phy: Use interrupts when available in NOLINK state)
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
ppp_read() and ppp_poll() can be called concurrently with ppp_ioctl().
In this case, ppp_ioctl() might call ppp_ccp_closed(), which may update
ppp->flags while ppp_read() or ppp_poll() is reading it.
The update done by ppp_ccp_closed() isn't atomic due to the bit mask
operation ('ppp->flags &= ~(SC_CCP_OPEN | SC_CCP_UP)'), so concurrent
readers might get transient values.
Reading incorrect ppp->flags may disturb the 'ppp->flags & SC_LOOP_TRAFFIC'
test in ppp_read() and ppp_poll(), which in turn can lead to improper
decision on whether the PPP unit file is ready for reading or not.
Since ppp_ccp_closed() is protected by the Rx and Tx locks (with
ppp_lock()), taking the Rx lock is enough for ppp_read() and ppp_poll()
to guarantee that ppp_ccp_closed() won't update ppp->flags
concurrently.
The same reasoning applies to ppp->n_channels. The 'n_channels' field
can also be written to concurrently by ppp_ioctl() (through
ppp_connect_channel() or ppp_disconnect_channel()). These writes aren't
atomic (simple increment/decrement), but are protected by both the Rx
and Tx locks (like in the ppp->flags case). So holding the Rx lock
before reading ppp->n_channels also prevents concurrent writes.
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
