- 20 Jan, 2017 40 commits
-
-
Shrirang Bagul authored
BugLink: http://bugs.launchpad.net/bugs/1657674 Dell Caracalla IoT gateways sport an RT5660 codec with HID 10EC3277. This patch adds the machine driver required to support RT5660 codec on Baytrail based systems. Signed-off-by:
Shrirang Bagul <shrirang.bagul@canonical.com> Acked-by:
Tim Gardner <tim.gardner@canonical.com> Acked-by:
Brad Figg <brad.figg@canonical.com> Signed-off-by:
Luis Henriques <luis.henriques@canonical.com>
-
Shrirang Bagul authored
BugLink: http://bugs.launchpad.net/bugs/1657674 On Dell IoT Gateways, RT5660 codec is available with ACPI ID 10EC3277. Also, GPIO's are only available by index, so we register mappings to allow machine drivers to access them by name. Signed-off-by:
-
Pierre-Louis Bossart authored
BugLink: http://bugs.launchpad.net/bugs/1657674 The upstreamed code modified the control names from Mute to Switch without changing the logic. To get audio working the Switch needs to be off which isn't aligned with normal ALSA conventions. Inverting the logic now so that Switch Off means mute and Switch On means active audio using the specific volume setting. Signed-off-by:
Sebastien Guiriec <sebastien.guiriec@intel.com> Signed-off-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by:
Mark Brown <broonie@kernel.org> (cherry picked from commit 940a5a01) Signed-off-by:
-
Bard Liao authored
BugLink: http://bugs.launchpad.net/bugs/1657674 There is a power saving mechanism in rt5660. It will turn off some unused power when MCLK is not present. We call that "MCLK detection" and it should be enabled by default. Signed-off-by:
Bard Liao <bardliao@realtek.com> Signed-off-by:
-
Oder Chiou authored
BugLink: http://bugs.launchpad.net/bugs/1657674 This is the initial codec driver for rt5660 Signed-off-by:
Oder Chiou <oder_chiou@realtek.com> Signed-off-by:
-
Luis Henriques authored
BugLink: http://bugs.launchpad.net/bugs/1657682Signed-off-by:
-
Luis Henriques authored
BugLink: http://bugs.launchpad.net/bugs/1657682Signed-off-by:
-
Shrirang Bagul authored
BugLink: http://bugs.launchpad.net/bugs/1657682 This patch limits the RS9113 driver from vendor to be used for the WLAN/BT card mounted on Dell Caracalla IoT gateways. Signed-off-by:
-
Darren Wu authored
BugLink: http://bugs.launchpad.net/bugs/1657682 This is the beta2 release for RS9113 driver from Redpine Signed-off-by:
Darren Wu <darren.wu@canonical.com> Signed-off-by:
-
Shrirang Bagul authored
BugLink: http://bugs.launchpad.net/bugs/1657682 The driver submitted by vendor Redpine for RS9113 WLAN/BT exports same symbols as their existing old driver in the kernel. This patch tries to resolve this conflict. Signed-off-by:
-
Shrirang Bagul authored
BugLink: http://bugs.launchpad.net/bugs/1657682 This patch adds support for RS9113 WLAN-BT cards found on Dell Caracalla IoT gateways. Vendor release: RS9113.NB0.NL.GNU.LNX.0.9.3 on 12/01/2016 Signed-off-by:
-
stephen hemminger authored
BugLink: http://bugs.launchpad.net/bugs/1657540 The receive callback (in tasklet context) is using RCU to get reference to associated VF network device but this is not safe. RCU read lock needs to be held. Found by running with full lockdep debugging enabled. Fixes: f207c10d ("hv_netvsc: use RCU to protect vf_netdev") Signed-off-by:
Stephen Hemminger <sthemmin@microsoft.com> Signed-off-by:
David S. Miller <davem@davemloft.net> (cherry picked from commit 0719e72c) Signed-off-by:
Seth Forshee <seth.forshee@canonical.com> Signed-off-by:
-
Haiyang Zhang authored
BugLink: http://bugs.launchpad.net/bugs/1650059 This script helps to create bonding network devices based on synthetic NIC (the virtual network adapter usually provided by Hyper-V) and the matching VF NIC (SRIOV virtual function). So the synthetic NIC and VF NIC can function as one network device, and fail over to the synthetic NIC if VF is down. Mayjor distros (RHEL, Ubuntu, SLES) supported by Hyper-V are supported by this script. Signed-off-by:
Haiyang Zhang <haiyangz@microsoft.com> Reviewed-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
-
K. Y. Srinivasan authored
BugLink: http://bugs.launchpad.net/bugs/1650059 One of the factors that can result in the host concluding that a given guest in mounting a DOS attack is if the guest generates interrupts to the host when the host is not expecting it. If these "spurious" interrupts reach a certain rate, the host can throttle the guest to minimize the impact. The host computation of the "expected number of interrupts" is strictly based on the ring transitions. Until the host logic is fixed, base the guest logic to interrupt solely on the ring state. Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 74198eb4) Signed-off-by:
-
stephen hemminger authored
BugLink: http://bugs.launchpad.net/bugs/1650059 Hyper-V (and Azure) support using NVGRE which requires some extra space for encapsulation headers. Because of this the largest allowed TSO packet is reduced. For older releases, hard code a fixed reduced value. For next release, there is a better solution which uses result of host offload negotiation. Signed-off-by:
-
Stephen Hemminger authored
BugLink: http://bugs.launchpad.net/bugs/1650059 In commit 9a56e5d6a0ba ("Drivers: hv: make VMBus bus ids persistent") the name of vmbus devices in sysfs changed to be (in 4.9-rc1): /sys/bus/vmbus/vmbus-6aebe374-9ba0-11e6-933c-00259086b36b The prefix ("vmbus-") is redundant and differs from how PCI is represented in sysfs. Therefore simplify to: /sys/bus/vmbus/6aebe374-9ba0-11e6-933c-00259086b36b Please merge this before 4.9 is released and the old format has to live forever. Signed-off-by:
-
Stephen Hemminger authored
BugLink: http://bugs.launchpad.net/bugs/1650059 This reverts commit e3f74b84 ("hv_netvsc: report vmbus name in ethtool")' because of problem introduced by commit f9a56e5d6a0ba ("Drivers: hv: make VMBus bus ids persistent"). This changed the format of the vmbus name and this new format is too long to fit in the bus_info field of ethtool. Signed-off-by:
-
Arnd Bergmann authored
BugLink: http://bugs.launchpad.net/bugs/1650059 The hdr_offset variable is only if we deal with a TCP or UDP packet, but as the check surrounding its usage tests for skb_is_gso() instead, the compiler has no idea if the variable is initialized or not at that point: drivers/net/hyperv/netvsc_drv.c: In function ‘netvsc_start_xmit’: drivers/net/hyperv/netvsc_drv.c:494:42: error: ‘hdr_offset’ may be used uninitialized in this function [-Werror=maybe-uninitialized] This adds an additional check for the transport type, which tells the compiler that this path cannot happen. Since the get_net_transport_info() function should always be inlined here, I don't expect this to result in additional runtime checks. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
David S. Miller authored
BugLink: http://bugs.launchpad.net/bugs/1650059 Based upon v2 of Stephen's patch. Signed-off-by:
-
stephen hemminger authored
BugLink: http://bugs.launchpad.net/bugs/1650059 The software calculation of UDP checksum in Netvsc driver was only handling IPv4 case. By using skb_checksum_help() instead all protocols can be handled. Rearrange code to eliminate goto and look like other drivers. This is a temporary solution; recent versions of Window Server etc do support UDP checksum offload, just need to do the appropriate negotiation with host to validate before using. This will be done in later patch. Please queue this for -stable as well. Signed-off-by:
-
Vitaly Kuznetsov authored
BugLink: http://bugs.launchpad.net/bugs/1650059 The auto incremented counter is not being used anymore, get rid of it. Signed-off-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by:
-
Vitaly Kuznetsov authored
BugLink: http://bugs.launchpad.net/bugs/1650059 Some tools use bus ids to identify devices and they count on the fact that these ids are persistent across reboot. This may be not true for VMBus as we use auto incremented counter from alloc_channel() as such id. Switch to using if_instance from channel offer, this id is supposed to be persistent. Signed-off-by:
-
Stephen Hemminger authored
BugLink: http://bugs.launchpad.net/bugs/1650059 Typo's and spelling errors. Also remove old comment from staging era. Signed-off-by:
-
Stephen Hemminger authored
BugLink: http://bugs.launchpad.net/bugs/1650059 Useful for debugging issues with multicast and SR-IOV to keep track of number of received multicast packets. Signed-off-by:
-
Stephen Hemminger authored
BugLink: http://bugs.launchpad.net/bugs/1650059 Since VF reference is now protected by RCU, no longer need the VF usage counter and can use device flags to see whether to inject or not. Signed-off-by:
-
Stephen Hemminger authored
BugLink: http://bugs.launchpad.net/bugs/1650059 The vf_netdev pointer in the netvsc device context can simply be protected by RCU because network device destruction is already RCU synchronized. Signed-off-by:
-
Stephen Hemminger authored
BugLink: http://bugs.launchpad.net/bugs/1650059 The code to associate netvsc and VF devices can be made less error prone by using a better matching algorithms. On registration, use the permanent address which avoids any possible issues caused by device MAC address being changed. For all other callbacks, search by the netdevice pointer value to ensure getting the correct network device. Signed-off-by:
-
Stephen Hemminger authored
BugLink: http://bugs.launchpad.net/bugs/1650059 The callback handler for netlink events can be simplified: * Consolidate check for netlink callback events about this driver itself. * Ignore non-Ethernet devices. Signed-off-by:
-
Stephen Hemminger authored
BugLink: http://bugs.launchpad.net/bugs/1650059 The netvsc driver holds a pointer to the virtual function network device if managing SR-IOV association. In order to ensure that the VF network device does not disappear, it should be using dev_hold/dev_put to get a reference count. Signed-off-by:
-
Stephen Hemminger authored
BugLink: http://bugs.launchpad.net/bugs/1650059 Packets that are transmitted in normal path should use consume_skb instead of kfree_skb. This allows for better tracing of packet drops. Signed-off-by:
-
Stephen Hemminger authored
BugLink: http://bugs.launchpad.net/bugs/1650059 These functions are used by other code misc-next tree. This reverts commit 30d1de08. Signed-off-by:
-
Vivek yadav authored
BugLink: http://bugs.launchpad.net/bugs/1650059 Under stress, we have seen allocation failure in time synch code. Avoid this dynamic allocation. Signed-off-by:
Vivek Yadav <vyadav@microsoft.com> Signed-off-by:
-
Alex Ng authored
BugLink: http://bugs.launchpad.net/bugs/1650059 This enables support for more accurate TimeSync v4 samples when hosted under Windows Server 2016 and newer hosts. The new time samples include a "vmreferencetime" field that represents the guest's TSC value when the host generated its time sample. This value lets the guest calculate the latency in receiving the time sample. The latency is added to the sample host time prior to updating the clock. Signed-off-by:
Alex Ng <alexng@messages.microsoft.com> Signed-off-by:
-
Alex Ng authored
BugLink: http://bugs.launchpad.net/bugs/1650059 Only the first 50 samples after boot were being used to discipline the clock. After the first 50 samples, any samples from the host were ignored and the guest clock would eventually drift from the host clock. This patch allows TimeSync-enabled guests to continuously synchronize the clock with the host clock, even after the first 50 samples. Signed-off-by:
-
Alex Ng authored
BugLink: http://bugs.launchpad.net/bugs/1650059 Different Windows host versions may reuse the same protocol version when negotiating the TimeSync, Shutdown, and Heartbeat protocols. We should only refer to the protocol version to avoid conflating the two concepts. Signed-off-by:
-
Dexuan Cui authored
BugLink: http://bugs.launchpad.net/bugs/1650059 Some VMBus devices are not needed by Linux guest[1][2], and, VMBus channels of Hyper-V Sockets don't really mean usual synthetic devices, so let's suppress the warnings for them. [1] https://support.microsoft.com/en-us/kb/2925727 [2] https://msdn.microsoft.com/en-us/library/jj980180(v=winembedded.81).aspxSigned-off-by:
Dexuan Cui <decui@microsoft.com> Signed-off-by:
-
Stephen Hemminger authored
BugLink: http://bugs.launchpad.net/bugs/1650059 This fixes a sparse warning because hyperv_mmio resources are only used in this one file and should be static. Signed-off-by:
-
K. Y. Srinivasan authored
BugLink: http://bugs.launchpad.net/bugs/1650059 To deal with the merge conflict between net-next and char-misc trees, revert commit bb08d431 from char-misc tree. This commit can be rebased and applied once net-next picks up char-misc changes. Here is the commit log of the reverted patch: "With wrap around mappings in place we can always provide drivers with direct links to packets on the ring buffer, even when they wrap around. Do the required updates to get_next_pkt_raw()/put_pkt_raw()" Signed-off-by:
-
Dexuan Cui authored
BugLink: http://bugs.launchpad.net/bugs/1650059 'completion_status' is used in some places, e.g., hv_pci_protocol_negotiation(), so we should make sure it's initialized in error case too, though the error is unlikely here. [bhelgaas: fix changelog typo and nearby whitespace] Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Acked-by:
-
Dexuan Cui authored
BugLink: http://bugs.launchpad.net/bugs/1650059 Handle vmbus_sendpacket() failure in hv_compose_msi_msg(). I happened to find this when reading the code. I didn't get a real issue however. Signed-off-by:
-
