This reverts commit f125452fcb.
We want to back-out the eas-dev merge that happened in the tree after
5.3-rc1 as those patches "should" all be in Linus's tree now.
This is done to handle the merge conflicts with 5.4-rc1.
Cc: Todd Kjos <tkjos@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I1ecea74dbe14b3ce717ce6727eebf3171fdfa2ba
This reverts commit 3dfddd5691.
We want to back-out the eas-dev merge that happened in the tree after
5.3-rc1 as those patches "should" all be in Linus's tree now.
This is done to handle the merge conflicts with 5.4-rc1.
Cc: Todd Kjos <tkjos@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I7f33f5bbd0b8fd25e648a6ac0bd8ee9bcdc8de16
This reverts commit bfc73d1830.
We want to back-out the eas-dev merge that happened in the tree after
5.3-rc1 as those patches "should" all be in Linus's tree now.
This is done to handle the merge conflicts with 5.4-rc1.
Cc: Todd Kjos <tkjos@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I6e5f8f45be6a2ea01446dd2cea0e3da1fa839404
This reverts commit 7846cccba0.
We want to back-out the eas-dev merge that happened in the tree after
5.3-rc1 as those patches "should" all be in Linus's tree now.
This is done to handle the merge conflicts with 5.4-rc1.
Cc: Todd Kjos <tkjos@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Idb2a1eeb907c2ecbf29c71462594f5966a268a5a
This reverts commit f2fce2f48c.
We want to back-out the eas-dev merge that happened in the tree after
5.3-rc1 as those patches "should" all be in Linus's tree now.
This is done to handle the merge conflicts with 5.4-rc1.
Cc: Todd Kjos <tkjos@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: If826caad4ed3ffb42e9401ba8863669b999bbffb
This reverts commit 1a1d22a3d8.
We want to back-out the eas-dev merge that happened in the tree after
5.3-rc1 as those patches "should" all be in Linus's tree now.
This is done to handle the merge conflicts with 5.4-rc1.
Cc: Todd Kjos <tkjos@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I4f3a3b047d2c81f2f6de6da633964f009717a1cf
This reverts commit 67de53b177.
We want to back-out the eas-dev merge that happened in the tree after
5.3-rc1 as those patches "should" all be in Linus's tree now.
This is done to handle the merge conflicts with 5.4-rc1.
Cc: Todd Kjos <tkjos@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I8b1a8909ce8d5eb8d1660586a8706fb6a674d751
This reverts commit c3a40105da.
We want to back-out the eas-dev merge that happened in the tree after
5.3-rc1 as those patches "should" all be in Linus's tree now.
This is done to handle the merge conflicts with 5.4-rc1.
Cc: Todd Kjos <tkjos@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I12de178caa24b1b3b8158c7c466a0110b03c234a
This reverts commit 3a77694caa.
We want to back-out the eas-dev merge that happened in the tree after
5.3-rc1 as those patches "should" all be in Linus's tree now.
This is done to handle the merge conflicts with 5.4-rc1.
Cc: Todd Kjos <tkjos@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I07388b025db5a256d463c535adc7df5d79c4ed5d
This reverts commit e5c4fc9d50.
We want to back-out the eas-dev merge that happened in the tree after
5.3-rc1 as those patches "should" all be in Linus's tree now.
This is done to handle the merge conflicts with 5.4-rc1.
Cc: Todd Kjos <tkjos@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I601699aa4165dfe927b024c022fae72223f34d4a
This reverts commit f3e9811919.
We want to back-out the eas-dev merge that happened in the tree after
5.3-rc1 as those patches "should" all be in Linus's tree now.
This is done to handle the merge conflicts with 5.4-rc1.
Cc: Todd Kjos <tkjos@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I5afe7d731264b20090a3c8a2237ba5c45ba01716
In embedded environments the requirements are to be able to pick and
chose which features one requires built into the kernel. If an
embedded environment wants to supports loading modules that have been
kbuilt out of tree, there is a need to enable hidden configurations
for legacy wireless core features to provide the API surface for
them to load.
Introduce CONFIG_GKI_LEGACY_WEXT_ALLCONFIG to select all legacy wireless
extension core features by activating in turn all the associated
hidden configuration options, without having to specifically select
any wireless module(s).
(rejected upstream commit url https://lkml.org/lkml/2019/9/6/878)
Signed-off-by: Mark Salyzyn <salyzyn@google.com>
Bug: 140250271
Change-Id: Ie40e656d87ce21ae82f04ffe8dae2f0efab88a2e
Enable config which selects a number of non-module
options which are usually selected by drivers built
as modules
Bug: 141266428
Change-Id: I8d95c96b74b2cfd861d68573135455a3392ff522
Signed-off-by: Todd Kjos <tkjos@google.com>
Add hidden configs to GKI_HACKS_TO_FIX so they are
enabled for loadable GPIO modules built out-of-tree
Bug: 141266428
Change-Id: Ie6e79921df67e86783f04cb869604c988656a034
Signed-off-by: Todd Kjos <tkjos@google.com>
Add hidden configs to GKI_HACKS_TO_FIX so they are
enabled for loadable SND_SOC modules built out-of-tree
Bug: 141266428
Change-Id: I4782b5bb401a76c647bac41258c1371762dace1c
Signed-off-by: Todd Kjos <tkjos@google.com>
Add hidden configs to GKI_HACKS_TO_FIX so they are
enabled for loadable regmap modules built out-of-tree.
Bug: 141266428
Change-Id: I1dedb1fd6e26e36c12b28fcbbf0302f074547101
Signed-off-by: Todd Kjos <tkjos@google.com>
Add hidden configs to GKI_HACKS_TO_FIX so they
are enabled for loadable DRM modules built
out-of-tree.
Bug: 141266428
Change-Id: Ibeda203afa54edc4f9a1daec9b4e8a928eb934fb
Signed-off-by: Todd Kjos <tkjos@google.com>
Add CONFIG_GKI_HACKS_TO_FIX as a mechanism to force
hidden configs to be selected for modules that will be built
separately. Also used to select drivers that need to be
modularized.
As these issues are resolved upstream, the configs should
be removed from GKI_HACKS_TO_FIX
Bug: 141266428
Change-Id: Ic8b2a17cd3a389ac5ef999c8c79b5b5dfee73c8a
Signed-off-by: Todd Kjos <tkjos@google.com>
Problem background: In the process of suspend, maybe some device suspend
callback failed in dpm_suspend_start()/dpm_prepare()/dpm_suspend().
Because it's after suspend_console(), so printf() is disabled now.
Currently we can see "Some devices failed to suspend, or early wake
event detected" by log_suspend_abort_reason() in bugreport. There are
many devices but we don't know which exactly device failed. So we
want to do a little change to record which device failed.
Note: I checked upstream LTS kernel, then I found the
patch can not be sent upstream, because it uses function
log_suspend_abort_reason() in wakeup_reason.c, the initial
patch(https://patchwork.kernel.org/patch/3827331/) for adding
/kernel/power/wakeup_reason.c is not accepted by upstream which
was merged in AOSP common kernels. So maybe the patch could
only be sent to AOSP common kernels.
Test: manual - Use modified version for daily use two days, from
bugreport we can see which device failed.
Bug: 120445600
Change-Id: I326c87ca1263496db79d08ec615f12fc22452d7a
Signed-off-by: zhuguangqing <zhuguangqing@xiaomi.com>
Signed-off-by: Ram Muthiah <rammuthiah@google.com>
Test: Local Boot of cuttlefish with this kernel
Bug: 132629930
Change-Id: I12afb2b95105bfdbaa81cc51367664fa36a4f60c
Leaf changes summary: 4 artifacts changed
Changed leaf types summary: 2 leaf types changed
Removed/Changed/Added functions summary: 0 Removed, 2 Changed, 0 Added function
Removed/Changed/Added variables summary: 0 Removed, 0 Changed, 0 Added variable
2 functions with some sub-type change:
[C]'function int fib_add_nexthop(sk_buff*, const fib_nh_common*, int)' at fib_semantics.c:1656:1 has some sub-type changes:
parameter 4 of type 'typedef u8' was added
[C]'function int fib_nexthop_info(sk_buff*, const fib_nh_common*, unsigned char*, bool)' at fib_semantics.c:1584:1 has some sub-type changes:
parameter 5 of type 'typedef bool' was added
parameter 4 of type 'typedef bool' changed:
entity changed from 'typedef bool' to 'unsigned char*'
type size changed from 8 to 64 (in bits)
'struct xfrm_if at xfrm.h:991:1' changed:
type size changed from 512 to 320 (in bits)
1 data member deletion:
'net_device* xfrm_if::phydev', at offset 128 (in bits) at xfrm.h:994:1
there are data member changes:
'net* xfrm_if::net' offset changed from 192 to 128 (in bits) (by -64 bits)
type 'struct xfrm_if_parms' of 'xfrm_if::p' changed:
type size changed from 192 to 64 (in bits)
1 data member deletion:
'char xfrm_if_parms::name[16]', at offset 0 (in bits) at xfrm.h:986:1
there are data member changes:
'int xfrm_if_parms::link' offset changed from 128 to 0 (in bits) (by -128 bits)
'u32 xfrm_if_parms::if_id' offset changed from 160 to 32 (in bits) (by -128 bits)
one impacted interface:
function void xfrm_if_register_cb(const xfrm_if_cb*), offset changed from 256 to 192 (in bits) (by -64 bits), size changed from 192 to 64 (in bits) (by -128 bits)
'gro_cells xfrm_if::gro_cells' offset changed from 448 to 256 (in bits) (by -192 bits)
one impacted interface:
function void xfrm_if_register_cb(const xfrm_if_cb*)
'struct xfrm_if_parms at xfrm.h:985:1' changed:
details were reported earlier
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: If6b58c75efce9cec5d43b5e57c4bbe4f2ca85729
This reverts commit b03755ad6f.
This is sad, and done for all the wrong reasons. Because that commit is
good, and does exactly what it says: avoids a lot of small disk requests
for the inode table read-ahead.
However, it turns out that it causes an entirely unrelated problem: the
getrandom() system call was introduced back in 2014 by commit
c6e9d6f388 ("random: introduce getrandom(2) system call"), and people
use it as a convenient source of good random numbers.
But part of the current semantics for getrandom() is that it waits for
the entropy pool to fill at least partially (unlike /dev/urandom). And
at least ArchLinux apparently has a systemd that uses getrandom() at
boot time, and the improvements in IO patterns means that existing
installations suddenly start hanging, waiting for entropy that will
never happen.
It seems to be an unlucky combination of not _quite_ enough entropy,
together with a particular systemd version and configuration. Lennart
says that the systemd-random-seed process (which is what does this early
access) is supposed to not block any other boot activity, but sadly that
doesn't actually seem to be the case (possibly due bogus dependencies on
cryptsetup for encrypted swapspace).
The correct fix is to fix getrandom() to not block when it's not
appropriate, but that fix is going to take a lot more discussion. Do we
just make it act like /dev/urandom by default, and add a new flag for
"wait for entropy"? Do we add a boot-time option? Or do we just limit
the amount of time it will wait for entropy?
So in the meantime, we do the revert to give us time to discuss the
eventual fix for the fundamental problem, at which point we can re-apply
the ext4 inode table access optimization.
Reported-by: Ahmed S. Darwish <darwish.07@gmail.com>
Cc: Ted Ts'o <tytso@mit.edu>
Cc: Willy Tarreau <w@1wt.eu>
Cc: Alexander E. Patrakov <patrakov@gmail.com>
Cc: Lennart Poettering <mzxreary@0pointer.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Pull kvm fixes from Paolo Bonzini:
"The main change here is a revert of reverts. We recently simplified
some code that was thought unnecessary; however, since then KVM has
grown quite a few cond_resched()s and for that reason the simplified
code is prone to livelocks---one CPUs tries to empty a list of guest
page tables while the others keep adding to them. This adds back the
generation-based zapping of guest page tables, which was not
unnecessary after all.
On top of this, there is a fix for a kernel memory leak and a couple
of s390 fixlets as well"
* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
KVM: x86/mmu: Reintroduce fast invalidate/zap for flushing memslot
KVM: x86: work around leak of uninitialized stack contents
KVM: nVMX: handle page fault in vmread
KVM: s390: Do not leak kernel stack data in the KVM_S390_INTERRUPT ioctl
KVM: s390: kvm_s390_vm_start_migration: check dirty_bitmap before using it as target for memset()
Pull virtio fix from Michael Tsirkin:
"A last minute revert
The 32-bit build got broken by the latest defence in depth patch.
Revert and we'll try again in the next cycle"
* tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost:
Revert "vhost: block speculation of translated descriptors"
Pull RISC-V fix from Paul Walmsley:
"Last week, Palmer and I learned that there was an error in the RISC-V
kernel image header format that could make it less compatible with the
ARM64 kernel image header format. I had missed this error during my
original reviews of the patch.
The kernel image header format is an interface that impacts
bootloaders, QEMU, and other user tools. Those packages must be
updated to align with whatever is merged in the kernel. We would like
to avoid proliferating these image formats by keeping the RISC-V
header as close as possible to the existing ARM64 header. Since the
arch/riscv patch that adds support for the image header was merged
with our v5.3-rc1 pull request as commit 0f327f2aaa ("RISC-V: Add
an Image header that boot loader can parse."), we think it wise to try
to fix this error before v5.3 is released.
The fix itself should be backwards-compatible with any project that
has already merged support for premature versions of this interface.
It primarily involves ensuring that the RISC-V image header has
something useful in the same field as the ARM64 image header"
* tag 'riscv/for-v5.3' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
riscv: modify the Image header to improve compatibility with the ARM64 header
This reverts commit a89db445fb.
I was hasty to include this patch, and it breaks the build on 32 bit.
Defence in depth is good but let's do it properly.
Cc: stable@vger.kernel.org
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Pull networking fixes from David Miller:
1) Don't corrupt xfrm_interface parms before validation, from Nicolas
Dichtel.
2) Revert use of usb-wakeup in btusb, from Mario Limonciello.
3) Block ipv6 packets in bridge netfilter if ipv6 is disabled, from
Leonardo Bras.
4) IPS_OFFLOAD not honored in ctnetlink, from Pablo Neira Ayuso.
5) Missing ULP check in sock_map, from John Fastabend.
6) Fix receive statistic handling in forcedeth, from Zhu Yanjun.
7) Fix length of SKB allocated in 6pack driver, from Christophe
JAILLET.
8) ip6_route_info_create() returns an error pointer, not NULL. From
Maciej Żenczykowski.
9) Only add RDS sock to the hashes after rs_transport is set, from
Ka-Cheong Poon.
10) Don't double clean TX descriptors in ixgbe, from Ilya Maximets.
11) Presence of transmit IPSEC offload in an SKB is not tested for
correctly in ixgbe and ixgbevf. From Steffen Klassert and Jeff
Kirsher.
12) Need rcu_barrier() when register_netdevice() takes one of the
notifier based failure paths, from Subash Abhinov Kasiviswanathan.
13) Fix leak in sctp_do_bind(), from Mao Wenan.
* git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (72 commits)
cdc_ether: fix rndis support for Mediatek based smartphones
sctp: destroy bucket if failed to bind addr
sctp: remove redundant assignment when call sctp_get_port_local
sctp: change return type of sctp_get_port_local
ixgbevf: Fix secpath usage for IPsec Tx offload
sctp: Fix the link time qualifier of 'sctp_ctrlsock_exit()'
ixgbe: Fix secpath usage for IPsec TX offload.
net: qrtr: fix memort leak in qrtr_tun_write_iter
net: Fix null de-reference of device refcount
ipv6: Fix the link time qualifier of 'ping_v6_proc_exit_net()'
tun: fix use-after-free when register netdev failed
tcp: fix tcp_ecn_withdraw_cwr() to clear TCP_ECN_QUEUE_CWR
ixgbe: fix double clean of Tx descriptors with xdp
ixgbe: Prevent u8 wrapping of ITR value to something less than 10us
mlx4: fix spelling mistake "veify" -> "verify"
net: hns3: fix spelling mistake "undeflow" -> "underflow"
net: lmc: fix spelling mistake "runnin" -> "running"
NFC: st95hf: fix spelling mistake "receieve" -> "receive"
net/rds: An rds_sock is added too early to the hash table
mac80211: Do not send Layer 2 Update frame before authorization
...
Pull drm fixes from Dave Airlie:
"From the maintainer summit, just some last minute fixes for final:
lima:
- fix gem_wait ioctl
core:
- constify modes list
i915:
- DP MST high color depth regression
- GPU hangs on vulkan compute workloads"
* tag 'drm-fixes-2019-09-13' of git://anongit.freedesktop.org/drm/drm:
drm/lima: fix lima_gem_wait() return value
drm/i915: Restore relaxed padding (OCL_OOB_SUPPRES_ENABLE) for skl+
drm/i915: Limit MST to <= 8bpc once again
drm/modes: Make the whitelist more const
James Harvey reported a livelock that was introduced by commit
d012a06ab1 ("Revert "KVM: x86/mmu: Zap only the relevant pages when
removing a memslot"").
The livelock occurs because kvm_mmu_zap_all() as it exists today will
voluntarily reschedule and drop KVM's mmu_lock, which allows other vCPUs
to add shadow pages. With enough vCPUs, kvm_mmu_zap_all() can get stuck
in an infinite loop as it can never zap all pages before observing lock
contention or the need to reschedule. The equivalent of kvm_mmu_zap_all()
that was in use at the time of the reverted commit (4e103134b8, "KVM:
x86/mmu: Zap only the relevant pages when removing a memslot") employed
a fast invalidate mechanism and was not susceptible to the above livelock.
There are three ways to fix the livelock:
- Reverting the revert (commit d012a06ab1) is not a viable option as
the revert is needed to fix a regression that occurs when the guest has
one or more assigned devices. It's unlikely we'll root cause the device
assignment regression soon enough to fix the regression timely.
- Remove the conditional reschedule from kvm_mmu_zap_all(). However, although
removing the reschedule would be a smaller code change, it's less safe
in the sense that the resulting kvm_mmu_zap_all() hasn't been used in
the wild for flushing memslots since the fast invalidate mechanism was
introduced by commit 6ca18b6950 ("KVM: x86: use the fast way to
invalidate all pages"), back in 2013.
- Reintroduce the fast invalidate mechanism and use it when zapping shadow
pages in response to a memslot being deleted/moved, which is what this
patch does.
For all intents and purposes, this is a revert of commit ea145aacf4
("Revert "KVM: MMU: fast invalidate all pages"") and a partial revert of
commit 7390de1e99 ("Revert "KVM: x86: use the fast way to invalidate
all pages""), i.e. restores the behavior of commit 5304b8d37c ("KVM:
MMU: fast invalidate all pages") and commit 6ca18b6950 ("KVM: x86:
use the fast way to invalidate all pages") respectively.
Fixes: d012a06ab1 ("Revert "KVM: x86/mmu: Zap only the relevant pages when removing a memslot"")
Reported-by: James Harvey <jamespharvey20@gmail.com>
Cc: Alex Willamson <alex.williamson@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Emulation of VMPTRST can incorrectly inject a page fault
when passed an operand that points to an MMIO address.
The page fault will use uninitialized kernel stack memory
as the CR2 and error code.
The right behavior would be to abort the VM with a KVM_EXIT_INTERNAL_ERROR
exit to userspace; however, it is not an easy fix, so for now just ensure
that the error code and CR2 are zero.
Signed-off-by: Fuqian Huang <huangfq.daxian@gmail.com>
Cc: stable@vger.kernel.org
[add comment]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The implementation of vmread to memory is still incomplete, as it
lacks the ability to do vmread to I/O memory just like vmptrst.
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Part of the intention during the definition of the RISC-V kernel image
header was to lay the groundwork for a future merge with the ARM64
image header. One error during my original review was not noticing
that the RISC-V header's "magic" field was at a different size and
position than the ARM64's "magic" field. If the existing ARM64 Image
header parsing code were to attempt to parse an existing RISC-V kernel
image header format, it would see a magic number 0. This is
undesirable, since it's our intention to align as closely as possible
with the ARM64 header format. Another problem was that the original
"res3" field was not being initialized correctly to zero.
Address these issues by creating a 32-bit "magic2" field in the RISC-V
header which matches the ARM64 "magic" field. RISC-V binaries will
store "RSC\x05" in this field. The intention is that the use of the
existing 64-bit "magic" field in the RISC-V header will be deprecated
over time. Increment the minor version number of the file format to
indicate this change, and update the documentation accordingly. Fix
the assembler directives in head.S to ensure that reserved fields are
properly zero-initialized.
Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
Reported-by: Palmer Dabbelt <palmer@sifive.com>
Reviewed-by: Palmer Dabbelt <palmer@sifive.com>
Cc: Atish Patra <atish.patra@wdc.com>
Cc: Karsten Merker <merker@debian.org>
Link: https://lore.kernel.org/linux-riscv/194c2f10c9806720623430dbf0cc59a965e50448.camel@wdc.com/T/#u
Link: https://lore.kernel.org/linux-riscv/mhng-755b14c4-8f35-4079-a7ff-e421fd1b02bc@palmer-si-x1e/T/#t
A Mediatek based smartphone owner reports problems with USB
tethering in Linux. The verbose USB listing shows a rndis_host
interface pair (e0/01/03 + 10/00/00), but the driver fails to
bind with
[ 355.960428] usb 1-4: bad CDC descriptors
The problem is a failsafe test intended to filter out ACM serial
functions using the same 02/02/ff class/subclass/protocol as RNDIS.
The serial functions are recognized by their non-zero bmCapabilities.
No RNDIS function with non-zero bmCapabilities were known at the time
this failsafe was added. But it turns out that some Wireless class
RNDIS functions are using the bmCapabilities field. These functions
are uniquely identified as RNDIS by their class/subclass/protocol, so
the failing test can safely be disabled. The same applies to the two
types of Misc class RNDIS functions.
Applying the failsafe to Communication class functions only retains
the original functionality, and fixes the problem for the Mediatek based
smartphone.
Tow examples of CDC functional descriptors with non-zero bmCapabilities
from Wireless class RNDIS functions are:
0e8d:000a Mediatek Crosscall Spider X5 3G Phone
CDC Header:
bcdCDC 1.10
CDC ACM:
bmCapabilities 0x0f
connection notifications
sends break
line coding and serial state
get/set/clear comm features
CDC Union:
bMasterInterface 0
bSlaveInterface 1
CDC Call Management:
bmCapabilities 0x03
call management
use DataInterface
bDataInterface 1
and
19d2:1023 ZTE K4201-z
CDC Header:
bcdCDC 1.10
CDC ACM:
bmCapabilities 0x02
line coding and serial state
CDC Call Management:
bmCapabilities 0x03
call management
use DataInterface
bDataInterface 1
CDC Union:
bMasterInterface 0
bSlaveInterface 1
The Mediatek example is believed to apply to most smartphones with
Mediatek firmware. The ZTE example is most likely also part of a larger
family of devices/firmwares.
Suggested-by: Lars Melin <larsm17@gmail.com>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
Mao Wenan says:
====================
fix memory leak for sctp_do_bind
First two patches are to do cleanup, remove redundant assignment,
and change return type of sctp_get_port_local.
Third patch is to fix memory leak for sctp_do_bind if failed
to bind address.
v2: add one patch to change return type of sctp_get_port_local.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
There are more parentheses in if clause when call sctp_get_port_local
in sctp_do_bind, and redundant assignment to 'ret'. This patch is to
do cleanup.
Signed-off-by: Mao Wenan <maowenan@huawei.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Currently sctp_get_port_local() returns a long
which is either 0,1 or a pointer casted to long.
It's neither of the callers use the return value since
commit 62208f1245 ("net: sctp: simplify sctp_get_port").
Now two callers are sctp_get_port and sctp_do_bind,
they actually assumend a casted to an int was the same as
a pointer casted to a long, and they don't save the return
value just check whether it is zero or non-zero, so
it would better change return type from long to int for
sctp_get_port_local.
Signed-off-by: Mao Wenan <maowenan@huawei.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Port the same fix for ixgbe to ixgbevf.
The ixgbevf driver currently does IPsec Tx offloading
based on an existing secpath. However, the secpath
can also come from the Rx side, in this case it is
misinterpreted for Tx offload and the packets are
dropped with a "bad sa_idx" error. Fix this by using
the xfrm_offload() function to test for Tx offload.
CC: Shannon Nelson <snelson@pensando.io>
Fixes: 7f68d43067 ("ixgbevf: enable VF IPsec offload operations")
Reported-by: Jonathan Tooker <jonathan@reliablehosting.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Acked-by: Shannon Nelson <snelson@pensando.io>
Signed-off-by: David S. Miller <davem@davemloft.net>
