| Age | Commit message (Collapse) | Author |
|---|
|
Si-En Technology was acquired by ISSI in 2011, and it appears that
the IS31FL3218/IS31FL3216 are just rebranded SN3218/SN3216 devices.
Add the "si-en,sn3218" and "si-en,sn3216" compatible strings into the
IS31FL32XX driver as aliases for the issi equivalents, and update
binding documentation.
Datasheets:
IS31FL3218: http://www.issi.com/WW/pdf/31FL3218.pdf
SN3218: http://www.si-en.com/uploadpdf/s2011517171720.pdf
IS31FL3216: http://www.issi.com/WW/pdf/31FL3216.pdf
SN3216: http://www.si-en.com/uploadpdf/SN3216201152410148.pdf
Signed-off-by: David Rivshin <drivshin@allworx.com>
Acked-by: Rob Herring <robh@kernel.org>
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
|
|
Si-En Technology is a fabless design house which offers
audio amplifiers, LED drivers and sensors.
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
|
|
The IS31FL32xx family of LED controllers are I2C devices with multiple
constant-current channels, each with independent 256-level PWM control.
Datasheets: http://www.issi.com/US/product-analog-fxled-driver.shtml
This has been tested on the IS31FL3236 and IS31FL3216, on an ARM
(TI am335x) platform.
The programming paradigm of these devices is similar in the following
ways:
- All registers are 8 bit
- All LED control registers are write-only
- Each LED channel has a PWM register (0-255)
- PWM register writes are shadowed until an Update register is poked
- All have a concept of Software Shutdown, which disables output
However, there are some differences in devices:
- 3236/3235 have a separate Control register for each LED,
(3218/3216 pack the enable bits into fewer registers)
- 3236/3235 have a per-channel current divisor setting
- 3236/3235 have a Global Control register that can turn off all LEDs
- 3216 is unique in a number of ways
- OUT9-OUT16 can be configured as GPIOs instead of LED controls
- LEDs can be programmed with an 8-frame animation, with
programmable delay between frames
- LEDs can be modulated by an input audio signal
- Max output current can be adjusted from 1/4 to 2x globally
- Has a Configuration register instead of a Shutdown register
This driver currently only supports the base PWM control function
of these devices. The following features of these devices are not
implemented, although it should be possible to add them in the future:
- All devices are capable of going into a lower-power "software
shutdown" mode.
- The is31fl3236 and is31fl3235 can reduce the max output current
per-channel with a divisor of 1, 2, 3, or 4.
- The is31fl3216 can use some LED channels as GPIOs instead.
- The is31fl3216 can animate LEDs in hardware.
- The is31fl3216 can modulate LEDs according to an audio input.
- The is31fl3216 can reduce/increase max output current globally.
Signed-off-by: David Rivshin <drivshin@allworx.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
|
|
This adds a binding description for the is31fl3236/35/18/16 I2C LED
controllers.
Signed-off-by: David Rivshin <drivshin@allworx.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
|
|
ISSI is the stock ticker Integrated Silicon Solutions Inc.
Company website: http://www.issi.com
Signed-off-by: David Rivshin <drivshin@allworx.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
|
|
Switch to resource-managed function devm_led_classdev_register instead
of led_classdev_register and remove unneeded led_classdev_unregister.
To be compatible with this change, remove an unnecessary label by
replacing it with direct return statement.
The Coccinelle semantic patch used to make this change is as follows:
//<smpl>
@platform@
identifier p, probefn, removefn;
@@
struct platform_driver p = {
.probe = probefn,
.remove = removefn,
};
@prb@
identifier platform.probefn, pdev;
expression e;
@@
probefn(struct platform_device *pdev, ...) {
...
e =
- led_classdev_register
+ devm_led_classdev_register
(...);
...
?- led_classdev_unregister(...);
...
}
@remove depends on prb@
identifier platform.removefn;
@@
removefn(...) {
...
?- led_classdev_unregister(...);
...
}
//</smpl>
Signed-off-by: Amitoj Kaur Chawla <amitoj1606@gmail.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
|
|
Use the GPIO flag definition instead of a numeric literal, so the casual
reader grepping for GPIOF_ will find the GPIO flags used.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
|
|
Add helpers for calling brightness_set(_blocking) allowing to
simplify the code and make it better readable.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
|
|
In case of error, the function gpio_to_desc() returns NULL
pointer not ERR_PTR(). The IS_ERR() test in the return value
check should be replaced with NULL test.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
|
|
Improve the wording for the comment about the led status, and while at
it also use the standard formatting for multi-line comments.
Signed-off-by: Antonio Ospite <ao2@ao2.it>
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
|
|
When a USB LED device is unplugged the remove call chain calls
led_classdev_unregister which tries to switch the LED off.
As the device has been removed already this results in a ENODEV
error message in dmesg.
Avoid this error message by ignoring ENODEV in calls from
led_classdev_unregister if the LED device is flagged as pluggable.
Therefore a new flag LED_HW_PLUGGABLE was introduced which should be set by
all LED drivers handling pluggable LED devices (mainly USB LED devices).
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
|
|
Now that workqueues have been removed from individual drivers and
were replaced with a core-internal workqueue we shouldn't
encourage people to add new workqueues to drivers.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
|
|
git://git.infradead.org/users/jcooper/linux into irq/core
Pull irqchip core changes from Jason Cooper:
- mvebu: Update dt binding docs for new odmi driver
|
|
nvhdmi_chmap_cea_alloc_validate_get_type calls itself recursively
using chmap ops causing the double fault.
Fixed by adding the default validate_get_type handling inside nvdia
validate_get_type handler.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=114311
Fixes: 67b90cb ("ALSA: hda - Create common chmap object")
Reported-by: Andreas Reis <andreas.reis@gmail.com>
Signed-off-by: Subhransu S. Prusty <subhransu.s.prusty@intel.com>
Tested-by: Andreas Reis <andreas.reis@gmail.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The clock measurement on the AC'97 audio card found in the IBM ThinkPad X41
will often fail, so add a quirk entry to fix it.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=441087
Cc: <stable@vger.kernel.org>
Signed-off-by: Vittorio Gambaletta <linuxbugs@vittgam.net>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Vendor ID 0x10de0082 is used by a yet-to-be-named GPU chip.
This chip also has the 2-ch audio swapping bug, so patch_nvhdmi is
appropriate here.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Alexander Duyck says:
====================
Fix differences between IPv4 and IPv6 TCP/UDP checksum calculation
This patch series is meant to address the differences that exist between
IPv4 and IPv6 in terms of checksum calculation. Specifically the IPv6
function csum_ipv6_magic treated length as a value that could be greater
than 64K, while csum_tcpudp_magic was truncating the length at 16 bits.
After looking over the code and giving it some thought I decided it would
be best to update the IPv4 function so that it worked the same way the IPv6
one did. This allows us to get the same results given the same inputs for
both functions. As a result we can use the same processes to reverse the
calculation in the event we need to do something like remove the length of
the pseudo-header checksum.
I also took the opportunity to standardize things so that the parameters
for these functions all use the correct types. IPv4 addresses are __be32,
length should always be __u32, and protocol is a __u8.
With this change in place it corrects an issue with UDP tunnels in which we
were getting a checksum that was off by 1 when performing fragmentation on
inner UDP packets.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
It is possible for tunnels to end up generating IP or IPv6 datagrams that
are larger than 64K and expecting to be segmented. As such we need to deal
with length values greater than 64K. In order to accommodate this we need
to update the code to work with a 32b length value instead of a 16b one.
Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This patch updates csum_ipv6_magic so that it correctly recognizes that
protocol is a unsigned 8 bit value.
This will allow us to better understand what limitations may or may not be
present in how we handle the data. For example there are a number of
places that call htonl on the protocol value. This is likely not necessary
and can be replaced with a multiplication by ntohl(1) which will be
converted to a shift by the compiler.
Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This patch updates all instances of csum_tcpudp_magic and
csum_tcpudp_nofold to reflect the types that are usually used as the source
inputs. For example the protocol field is populated based on nexthdr which
is actually an unsigned 8 bit value. The length is usually populated based
on skb->len which is an unsigned integer.
This addresses an issue in which the IPv6 function csum_ipv6_magic was
generating a checksum using the full 32b of skb->len while
csum_tcpudp_magic was only using the lower 16 bits. As a result we could
run into issues when attempting to adjust the checksum as there was no
protocol agnostic way to update it.
With this change the value is still truncated as many architectures use
"(len + proto) << 8", however this truncation only occurs for values
greater than 16776960 in length and as such is unlikely to occur as we stop
the inner headers at ~64K in size.
I did have to make a few minor changes in the arm, mn10300, nios2, and
score versions of the function in order to support these changes as they
were either using things such as an OR to combine the protocol and length,
or were using ntohs to convert the length which would have truncated the
value.
I also updated a few spots in terms of whitespace and type differences for
the addresses. Most of this was just to make sure all of the definitions
were in sync going forward.
Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
When an inetdev is destroyed, every address assigned to the interface
is removed. And in this scenerio we do two pointless things which can
be very expensive if the number of assigned interfaces is large:
1) Address promotion. We are deleting all addresses, so there is no
point in doing this.
2) A full nf conntrack table purge for every address. We only need to
do this once, as is already caught by the existing
masq_dev_notifier so masq_inet_event() can skip this.
Reported-by: Solar Designer <solar@openwall.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Tested-by: Cyrill Gorcunov <gorcunov@openvz.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-next
Samuel Ortiz says:
====================
NFC 4.6 pull request
This is a very small one this time, with only 5 patches.
There are a couple of big items that could not be merged/finished
on time.
We have:
- 2 LLCP fixes for a race and a potential OOM.
- 2 cleanups for the pn544 and microread drivers.
- 1 Maintainer addition for the s3fwrn5 driver.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Sabrina Dubroca says:
====================
MACsec IEEE 802.1AE implementation
MACsec (IEEE 802.1AE [0]) is a protocol that provides security for
wired ethernet LANs. MACsec offers two protection modes:
authentication only, or authenticated encryption.
MACsec defines "secure channels" that allow transmission from one node
to one or more others. Communication on a channel is done over a
succession of "secure associations", that each use a specific key.
Secure associations are identified by their "association number" in
the range 0..3. A secure association is retired when its 32-bit
packet number would wrap, and the same association number can later be
reused with a new key and packet number.
The standard mode of encryption is GCM AES with 128 bits keys,
although an extension allows 256 bits keys [1] (not implemented in
this submission).
When using MACsec, an extra header, called "SecTAG", is added between
the ethernet header and the original payload:
+---------------------------------+----------------+----------------+
| (MACsec ethertype) | TCI_AN | SL |
+---------------------------------+----------------+----------------+
| Packet Number |
+-------------------------------------------------------------------+
| Secure Channel Identifier |
| (optional) |
+-------------------------------------------------------------------+
TCI_AN:
version
end_station
sci_present
scb
encrypted
changed_text
association_number (2 bits)
SL:
short_length (6 bits)
unused (2 bits)
The ethertype for the packet is set to 0x88E5, and the original
ethertype becomes part of the secure payload, which may be encrypted.
The ethernet header and the SecTAG are always transmitted in the
clear, but are integrity-protected.
MACsec supports optional replay protection with a configurable replay
window.
MACsec is designed to be used with the MKA extension to 802.1X (MACsec
Key Agreement protocol) [2], which provides channel attribution and
key distribution to the nodes, but can also be used with static keys
getting fed manually by an administrator.
Optional (not supported yet) features:
- confidentiality offset: in encryption mode, part of the payload may
be left unencrypted.
- choice of cipher suite: GCM AES with 256 bits has been standardised
[1].
Implementation
A netdevice is created on top of a real device for each TX secure
channel, like we do for VLANs. Multiple TX channels can be created on
top of the same underlying device.
Several other approaches were considered for the RX path:
- dev_add_pack: doesn't work, because we want to filter out
unprotected packets
- transparent mode: MACsec would be enabled directly on the real
netdevice. For this, we cannot use a rx_handler directly because
MACsec must be available for underlying devices enslaved in a
bridge or in a bond, so we need a hook directly in
__netif_receive_skb_core. This approach makes it harder to filter
non-encrypted packets on RX without forcing the user to setup some
rules, so the "transparent" mode is not so transparent after all.
It also makes TX more complex than with a dedicated netdevice.
One issue with the proposed implementation is that the qdisc layer for
the real device operates on already encrypted packets.
Netlink API
This is currently a mix of rtnetlink (to create the device and set up
the TX channel) and genl (for RX channels, secure associations and
their keys). genl provides clean demultiplexing of the {TX,RX}{SC,SA}
commands.
Use cases
The normal use case is wired LANs, including veth and slave devices
for bonding/teaming or bridges.
MACsec can also be used on any device that makes a full ethernet
header visible, for example VXLAN.
The VXLAN+MACsec setup would be:
hypervisor | virtual machine
<real_dev>---<VXLAN>---|---<dev>---<macsec_dev>
And the packets would look like this:
| eth | IP | UDP | VXLAN | eth | MACsec | IP | ... | MACsec ICV |
One benefit on this approach to encryption in the cloud is that the
payload is encrypted by the tenant, not by the tunnel provider, thus
the tenant has full control over the keys.
Changes from v1:
- rework netlink API after discussion with Johannes Berg
- nest attributes, rename
- export stats as separate attributes
- add some comments
- misc small fixes (rcu, constants, struct organization)
Changes from RFCv2:
- fix ENCODING_SA param validation
- add parent link to netlink ifdumps
Changes from RFCv1:
- addressed comments from Florian and Paolo + kbuild robot
- also perform post-decrypt handling after crypto callback
- fixed ->dellink behavior
Future plans:
- offload to hardware, on nics that support it
- implement optional features
[0] http://standards.ieee.org/getieee802/download/802.1AE-2006.pdf
[1] http://standards.ieee.org/getieee802/download/802.1AEbn-2011.pdf
[2] http://standards.ieee.org/getieee802/download/802.1X-2010.pdf
[3] RFCv1: http://www.spinics.net/lists/netdev/msg358151.html
[4] RFCv2: http://www.spinics.net/lists/netdev/msg362389.html
[5] v1: http://www.spinics.net/lists/netdev/msg367959.html
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This is an implementation of MACsec/IEEE 802.1AE. This driver
provides authentication and encryption of traffic in a LAN, typically
with GCM-AES-128, and optional replay protection.
http://standards.ieee.org/getieee802/download/802.1AE-2006.pdf
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Reviewed-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Reviewed-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Reviewed-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
There is no need to use the static variable here, pr_info_once is more
concise.
Signed-off-by: Liping Zhang <liping.zhang@spreadtrum.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
When operating the at803x in SGMII mode, resuming the chip
from power down brings up the copper-side link but leaves
the SGMII link in unconnected state (tested with at8031
attached to gianfar). In effect, this caused a permanent
link loss once the related interface was put down.
This patch ensures that power down handling in supspend()
and resume() is also applied to the SGMII link.
Signed-off-by: Zefir Kurtisi <zefir.kurtisi@neratec.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Jesper Dangaard Brouer says:
====================
net: bulk free adjustment and two driver use-cases
I've split out the bulk free adjustments, from the bulk alloc patches,
as I want the adjustment to napi_consume_skb be in same kernel cycle
the API was introduced.
Adjustments based on discussion:
Subj: "mlx4: use napi_consume_skb API to get bulk free operations"
http://thread.gmane.org/gmane.linux.network/402503/focus=403386
Patchset based on net-next at commit 3ebeac1d0295
V4: more nitpicks from Sergei
V3: spelling fixes from Sergei
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Bulk free of SKBs happen transparently by the API call napi_consume_skb().
The napi budget parameter is needed by napi_consume_skb() to detect
if called from netpoll.
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Bulk free of SKBs happen transparently by the API call napi_consume_skb().
The napi budget parameter is usually needed by napi_consume_skb()
to detect if called from netpoll. In this patch it has an extra meaning.
For mlx4 driver, the mlx4_en_stop_port() call is done outside
NAPI/softirq context, and cleanup the entire TX ring via
mlx4_en_free_tx_buf(). The code mlx4_en_free_tx_desc() for
freeing SKBs are shared with NAPI calls.
To handle this shared use the zero budget indication is reused,
and handled appropriately in napi_consume_skb(). To reflect this,
variable is called napi_mode for the function call that needed
this distinction.
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Some drivers reuse/share code paths that free SKBs between NAPI
and non-NAPI calls. Adjust napi_consume_skb to handle this
use-case.
Before, calls from netpoll (w/ IRQs disabled) was handled and
indicated with a budget zero indication. Use the same zero
indication to handle calls not originating from NAPI/softirq.
Simply handled by using dev_consume_skb_any().
This adds an extra branch+call for the netpoll case (checking
in_irq() + irqs_disabled()), but that is okay as this is a slowpath.
Suggested-by: Alexander Duyck <aduyck@mirantis.com>
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
For pcie nic, after setting link speed and there is no link driver does not need
to do phy reset until link up.
For some pcie nics, to do this will also reset phy speed down counter and prevent
phy from auto speed down.
This patch fix the issue reported in following link.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1547151
Signed-off-by: Chunhao Lin <hau@realtek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Firmware now tells us that the reset is done by passing a magic value
via register. Use it to shorten the wait in case this is supported.
With old firmware, we still wait until the timeout is reached.
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Currently sctp_sendmsg() triggers some calls that will allocate memory
with GFP_ATOMIC even when not necessary. In the case of
sctp_packet_transmit it will allocate a linear skb that will be used to
construct the packet and this may cause sends to fail due to ENOMEM more
often than anticipated specially with big MTUs.
This patch thus allows it to inherit gfp flags from upper calls so that
it can use GFP_KERNEL if it was triggered by a sctp_sendmsg call or
similar. All others, like retransmits or flushes started from BH, are
still allocated using GFP_ATOMIC.
In netperf tests this didn't result in any performance drawbacks when
memory is not too fragmented and made it trigger ENOMEM way less often.
Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
When we want to change a flow using netlink, we have to identify it to
be able to perform a lookup. Both the flow key and unique flow ID
(ufid) are valid identifiers, but we always have to specify the flow
key in the netlink message. When both attributes are there, the ufid
is used. The flow key is used to validate the actions provided by
the userland.
This commit allows to use the ufid without having to provide the flow
key, as it is already done in the netlink 'flow get' and 'flow del'
path. The flow key remains mandatory when an action is provided.
Signed-off-by: Samuel Gauthier <samuel.gauthier@6wind.com>
Reviewed-by: Simon Horman <simon.horman@netronome.com>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
On AT91 SoCs, the User Register (USRIO) exposes a switch to configure the
"Reduced" or "Traditional" version of the Media Independent Interface
(RMII vs. MII or RGMII vs. GMII).
As on the older EMAC version, on GMAC, this switch is set by default to the
non-reduced type of interface, so use the existing capability and extend it to
GMII as well. We then keep the current logic in the macb_init() function.
The capabilities of sama5d2, sama5d4 and sama5d3 GEM interface are updated in
the macb_config structure to be able to properly enable them with a traditional
interface (GMII or MII).
Reported-by: Romain HENRIET <romain.henriet@l-acoustics.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Commit e5a03bfd873c ("phy: Add an mdio_device structure") removed addr,
bus and dev member of the phy_device structure.
This patch remove the documentation about those members.
Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Paul Durrant says:
====================
xen-netback: fix multiple extra info handling
If a frontend passes multiple extra info fragments to netback on the guest
transmit side, because xen-netback does not account for this properly, only
a single ack response will be sent. This will eventually cause processing
of the shared ring to wedge.
This series re-imports the canonical netif.h from Xen, where the ring
protocol documentation has been updated, fixes this issue in xen-netback
and also adds a patch to reduce log spam.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
