| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
We want seq num (freed_pkts) to be initialized
on each new connection, but keep persistent
between recoveries/suspends.
Save the freed_pkts in the private block of the
sta struct (we already do a similar thing for
AP's stations).
However, keep the old wlvif->total_freed_pkts
in order to avoid too intrusive change.
Signed-off-by: Eliad Peller <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
|
|
This could be a bit confusing to see warning about lacking support for
5 GHz band if your device supports 2.4 GHz only.
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
|
|
Support for N-PHY rev 8 with 0x2057 rev 5 is almost ready, but we still
need to figure out how to handle rev 9 first.
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
|
|
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
|
|
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
|
|
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
|
|
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
|
|
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
|
|
Initialization of N-PHY radio revs 5 and 7 requires writing to 0x1.
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
|
|
Type of radio has a major meaning for the driver. There is quite some
code that does initialization/calibration depending on the radio rev.
Knowing radio params is quite important to provide help to users, so
print it even with debugging disabled.
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
|
|
The tx ring index was immediately trimmed with a
bitmask. This discarded the 0xFFFFFFFF error case
(which theoretically can happen when a device is
abruptly disconnected) and led to using an invalid
tx ring index. This could lead to memory
corruption.
Signed-off-by: Michal Kazior <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
|
|
It was possible for tx completion not to be
processed. In that case an old stack pointer was
left on copy engine tx ring. Next bmi exchange
would immediately pop it and use complete() on the
completion struct there causing corruption.
Make sure to wait for both tx and rx completions
properly.
Signed-off-by: Michal Kazior <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
|
|
SJA1000 has a self test mode (STM) which does not require
acknowledgement for the successful message transmission. In this mode a
node test is possible without any other active node on the bus.
This patch adds a possibility to set STM for SJA1000 controller through
specifying the corresponding CAN_CTRLMODE_PRESUME_ACK netlink flag.
Signed-off-by: Nikita Edward Baruzdin <[email protected]>
Acked-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
|
|
This adds support for hardware loopback in SJA1000 by utilising its self
reception request (SRR) feature. Upon SRR the message is transmitted and
received simultaneously, meaning you can't have hardware loopback
without actually sending a message to the CAN bus in case of SJA1000.
Signed-off-by: Nikita Edward Baruzdin <[email protected]>
Acked-by: Oliver Hartkopp <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
|
|
This patch uses devm_* APIs as they are device managed and make code simpler.
Signed-off-by: Lad, Prabhakar <[email protected]>
Signed-off-by: Marc Kleine-Budde <[email protected]>
|
|
When the module sends bursts of data, sometimes a deadlock happens in
the hso driver when the tty buffer doesn't get the chance to be flushed
quickly enough.
Remove the endless while loop in function put_rxbuf_data() which is
called by the urb completion handler.
If there isn't enough room in the tty buffer, discards all the data
received in the URB.
Cc: David Miller <[email protected]>
Cc: David Laight <[email protected]>
Cc: One Thousand Gnomes <[email protected]>
Cc: Dan Williams <[email protected]>
Cc: Jan Dumon <[email protected]>
Signed-off-by: Olivier Sobrie <[email protected]>
Acked-by: Alan Cox <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
The workqueue "retry_unthrottle_workqueue" is not scheduled anywhere
in the code. So, remove it.
Signed-off-by: Olivier Sobrie <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
This patch fix the 'foo*' bar with 'foo *bar' and (foo*) with (foo *).
Signed-off-by: Varka Bhadram <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Normally any device ids will be above the corresponding device driver
structure. This patch moves the pci device ids and MODULE_DEVICE_TABLE()
above the pci driver structure.
Signed-off-by: Varka Bhadram <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
This patch fixes the comment style issues
Signed-off-by: Varka Bhadram <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
This patch convert printk() to netdev_dbg/info/err or dev_info/err/dbg
Signed-off-by: Varka Bhadram <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
This patch replace ioremap() with the devm_ioremap() so that
the resource will be freed automatically with the probe failed.
Signed-off-by: Varka Bhadram <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
This patch moves the remove functionalities after the probe
so that we can see the registered and released resources properly.
Every driver follows the same concept.
Signed-off-by: Varka Bhadram <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Needed to select 40G mode on a 10G/40G capable card.
Signed-off-by: Shradha Shah <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Signed-off-by: Shradha Shah <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Commit 568f194e8bd16c353ad50f9ab95d98b20578a39d ("net: ppp: use
sk_unattached_filter api") causes sk_chk_filter() to be called twice when
setting a PPP pass or active filter. This applies to both the generic PPP
subsystem implemented by drivers/net/ppp/ppp_generic.c and the ISDN PPP
subsystem implemented by drivers/isdn/i4l/isdn_ppp.c. The first call is from
within get_filter(). The second one is through the call chain
ppp_ioctl() or isdn_ppp_ioctl()
--> sk_unattached_filter_create()
--> __sk_prepare_filter()
--> sk_chk_filter()
The first call from within get_filter() should be deleted as get_filter() is
called just before calling sk_unattached_filter_create() later on, which
eventually calls sk_chk_filter() anyway.
For 3.15.x, this proposed change is a bugfix rather than a pure optimization as
in that branch, sk_chk_filter() may replace filter codes by other codes which
are not recognized when executing sk_chk_filter() a second time. So with
3.15.x, if sk_chk_filter() is called twice, the second invocation may yield
EINVAL (this depends on the filter codes found in the filter to be set, but
because the replacement is done for frequently used codes, this is almost
always the case). The net effect is that setting pass and/or active PPP filters
does not work anymore, since sk_unattached_filter_create() always returns
EINVAL due to the second call to sk_chk_filter(), regardless whether the filter
was originally sane or not.
Signed-off-by: Christoph Schulz <[email protected]>
Acked-by: Daniel Borkmann <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Napi id was not marked for gro_skb, this will lead rx busy loop won't
work correctly since they stack never try to call low latency receive
method because of a zero socket napi id. Fix this by marking napi id
for gro_skb.
The transaction rate of 1 byte netperf tcp_rr gets about 50% increased
(from 20531.68 to 30610.88).
Cc: Amir Vadai <[email protected]>
Signed-off-by: Jason Wang <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
In vxlan driver call common function udp_sock_create to create the
listener UDP port.
Signed-off-by: Tom Herbert <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Obvious copy/paste error when I converted the ad_select to the new
option API. "lacp_rate" there should be "ad_select" so we can get the
proper value.
CC: Jay Vosburgh <[email protected]>
CC: Veaceslav Falico <[email protected]>
CC: Andy Gospodarek <[email protected]>
CC: David S. Miller <[email protected]>
Fixes: 9e5f5eebe765 ("bonding: convert ad_select to use the new option
API")
Reported-by: Karim Scheik <[email protected]>
Signed-off-by: Nikolay Aleksandrov <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
The PPP channel MTU is used with Multilink PPP when ppp_mp_explode() (see
ppp_generic module) tries to determine how big a fragment might be. According
to RFC 1661, the MTU excludes the 2-byte PPP protocol field, see the
corresponding comment and code in ppp_mp_explode():
/*
* hdrlen includes the 2-byte PPP protocol field, but the
* MTU counts only the payload excluding the protocol field.
* (RFC1661 Section 2)
*/
mtu = pch->chan->mtu - (hdrlen - 2);
However, the pppoe module *does* include the PPP protocol field in the channel
MTU, which is wrong as it causes the PPP payload to be 1-2 bytes too big under
certain circumstances (one byte if PPP protocol compression is used, two
otherwise), causing the generated Ethernet packets to be dropped. So the pppoe
module has to subtract two bytes from the channel MTU. This error only
manifests itself when using Multilink PPP, as otherwise the channel MTU is not
used anywhere.
In the following, I will describe how to reproduce this bug. We configure two
pppd instances for multilink PPP over two PPPoE links, say eth2 and eth3, with
a MTU of 1492 bytes for each link and a MRRU of 2976 bytes. (This MRRU is
computed by adding the two link MTUs and subtracting the MP header twice, which
is 4 bytes long.) The necessary pppd statements on both sides are "multilink
mtu 1492 mru 1492 mrru 2976". On the client side, we additionally need "plugin
rp-pppoe.so eth2" and "plugin rp-pppoe.so eth3", respectively; on the server
side, we additionally need to start two pppoe-server instances to be able to
establish two PPPoE sessions, one over eth2 and one over eth3. We set the MTU
of the PPP network interface to the MRRU (2976) on both sides of the connection
in order to make use of the higher bandwidth. (If we didn't do that, IP
fragmentation would kick in, which we want to avoid.)
Now we send a ICMPv4 echo request with a payload of 2948 bytes from client to
server over the PPP link. This results in the following network packet:
2948 (echo payload)
+ 8 (ICMPv4 header)
+ 20 (IPv4 header)
---------------------
2976 (PPP payload)
These 2976 bytes do not exceed the MTU of the PPP network interface, so the
IP packet is not fragmented. Now the multilink PPP code in ppp_mp_explode()
prepends one protocol byte (0x21 for IPv4), making the packet one byte bigger
than the negotiated MRRU. So this packet would have to be divided in three
fragments. But this does not happen as each link MTU is assumed to be two bytes
larger. So this packet is diveded into two fragments only, one of size 1489 and
one of size 1488. Now we have for that bigger fragment:
1489 (PPP payload)
+ 4 (MP header)
+ 2 (PPP protocol field for the MP payload (0x3d))
+ 6 (PPPoE header)
--------------------------
1501 (Ethernet payload)
This packet exceeds the link MTU and is discarded.
If one configures the link MTU on the client side to 1501, one can see the
discarded Ethernet frames with tcpdump running on the client. A
ping -s 2948 -c 1 192.168.15.254
leads to the smaller fragment that is correctly received on the server side:
(tcpdump -vvvne -i eth3 pppoes and ppp proto 0x3d)
52:54:00:ad:87:fd > 52:54:00:79:5c:d0, ethertype PPPoE S (0x8864),
length 1514: PPPoE [ses 0x3] MLPPP (0x003d), length 1494: seq 0x000,
Flags [end], length 1492
and to the bigger fragment that is not received on the server side:
(tcpdump -vvvne -i eth2 pppoes and ppp proto 0x3d)
52:54:00:70:9e:89 > 52:54:00:5d:6f:b0, ethertype PPPoE S (0x8864),
length 1515: PPPoE [ses 0x5] MLPPP (0x003d), length 1495: seq 0x000,
Flags [begin], length 1493
With the patch below, we correctly obtain three fragments:
52:54:00:ad:87:fd > 52:54:00:79:5c:d0, ethertype PPPoE S (0x8864),
length 1514: PPPoE [ses 0x1] MLPPP (0x003d), length 1494: seq 0x000,
Flags [begin], length 1492
52:54:00:70:9e:89 > 52:54:00:5d:6f:b0, ethertype PPPoE S (0x8864),
length 1514: PPPoE [ses 0x1] MLPPP (0x003d), length 1494: seq 0x000,
Flags [none], length 1492
52:54:00:ad:87:fd > 52:54:00:79:5c:d0, ethertype PPPoE S (0x8864),
length 27: PPPoE [ses 0x1] MLPPP (0x003d), length 7: seq 0x000,
Flags [end], length 5
And the ICMPv4 echo request is successfully received at the server side:
IP (tos 0x0, ttl 64, id 21925, offset 0, flags [DF], proto ICMP (1),
length 2976)
192.168.222.2 > 192.168.15.254: ICMP echo request, id 30530, seq 0,
length 2956
The bug was introduced in commit c9aa6895371b2a257401f59d3393c9f7ac5a8698
("[PPPOE]: Advertise PPPoE MTU") from the very beginning. This patch applies
to 3.10 upwards but the fix can be applied (with minor modifications) to
kernels as old as 2.6.32.
Signed-off-by: Christoph Schulz <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
If firmware probing worker failed it called
device_release_driver() which synchronously called
remove() pci callback. The callback in turn waited
for the worker that called it to finish resulting
in a deadlock.
Waiting for a completion instead of a worker, like
some other drivers do, doesn't seem like the best
idea either:
Syscall Worker
probe_fw()
rmmod
dev_lock()
pci->remove()
wait_for_completion()
complete_all()
device_release_driver()
dev_lock()
[sleep]
free(ar)
dev_unlock()
[resume]
There's no guarantee that Worker upon resuming can
still access any data/code of the module.
Leaving device bound to a driver is not as harmful
as deadlocking so remove the call to
device_release_driver() while a proper solution is
figured out.
Signed-off-by: Michal Kazior <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
|
|
This change enables ath6kl driver to support ar6004 hw3.0. At the same time do
some fixes in firmware initialisation which applies to ar6004 hw1.3 as well.
Signed-off-by: Jessica Wu <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
|
|
Some of the firmware versions support rate tables up to mcs15, add support for
that.
Signed-off-by: Jessica Wu <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
|
|
Needed for ar6004 hw3.0 support.
Signed-off-by: Kalle Valo <[email protected]>
|
|
rx flush was not implemented for htc pipe, add that now. Doesn't fix any known
issues.
Also free the skb if htc control messages get canceled.
Signed-off-by: Jessica Wu <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
|
|
The functionality defined through these flags were actually firmware features
which can change between firmware versions. To make it possible to support
different firmware versions with the same driver, convert the flags to firmware
feature flags.
For backwards compatibility support for old ar6004 firmware FW
API 3 or smaller images we forcefully set the feature bits in the driver.
Starting from FW API 5 the firmware image needs to set them.
Signed-off-by: Kalle Valo <[email protected]>
|
|
tmp may be used uninitialized if ath6kl_bmi_read() returns an error.
Signed-off-by: Frederic Danis <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
|
|
Allow to setup maximum subframes for AMSDU and AMPDU aggregation
via debugfs htt_max_amsdu_ampdu file.
Eg.
echo "2 64" > htt_max_amsdu_ampdu
will setup maximum amsdu subframes equal 2 and
maximum ampdu subframes equal to 64.
Signed-off-by: Janusz Dziedzic <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
|
|
Signed-off-by: Fabian Frederick <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Signed-off-by: Fabian Frederick <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Signed-off-by: Fabian Frederick <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Signed-off-by: Fabian Frederick <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Signed-off-by: Fabian Frederick <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Signed-off-by: Fabian Frederick <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Signed-off-by: Fabian Frederick <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Signed-off-by: Fabian Frederick <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Signed-off-by: Fabian Frederick <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
RGMII_MODE_EN bit was defined to 0, while it is actually 6. It was not
much of a problem on older designs where this was a no-op, and the RGMII
data-path would always be enabled, but newer GENET controllers need to
explicitely enable their RGMII data-pad using this bit.
Signed-off-by: Florian Fainelli <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next
John W. Linville says:
====================
Please pull this batch of updates intended for the 3.17 stream...
This is primarily a Bluetooth pull. Gustavo says:
"A lot of patches to 3.17. The bulk of changes here are for LE support.
The 6loWPAN over Bluetooth now has it own module, we also have support for
background auto-connection and passive scanning, Bluetooth device address
provisioning, support for reading Bluetooth clock values and LE connection
parameters plus many many fixes."
The balance is just a pull of the wireless.git tree, to avoid some
pending merge problems.
====================
Signed-off-by: David S. Miller <[email protected]>
|
|
The transport offset of the IPv4 packet should be fixed and wouldn't
be out of the hw limitation, so the r8152_csum_workaround() should
be used for IPv6 packets.
Signed-off-by: Hayes Wang <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|