Check whether there is any hwaccel VLAN tag on RX, and if there is,
treat it as the tag_8021q header.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The whole purpose of tag_8021q is to send VLAN-tagged traffic to the
CPU, from which the driver can decode the source port and switch id.
Currently this only works if the VLAN filtering on the master is
disabled. Change that by explicitly adding code to tag_8021q.c to add
the VLANs corresponding to the tags to the filter of the master
interface.
Because we now need to call vlan_vid_add, then we also need to hold the
RTNL mutex. Propagate that requirement to the callers of dsa_8021q_setup
and modify the existing call sites as appropriate. Note that one call
path, sja1105_best_effort_vlan_filtering_set -> sja1105_vlan_filtering
-> sja1105_setup_8021q_tagging, was already holding this lock.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Most DSA switch tags shift the EtherType to the right, causing the
master to not parse the VLAN as VLAN.
However, not all switches do that (example: tail tags, tag_8021q etc),
and if the DSA master has "rx-vlan-filter: on" in ethtool -k, then we
have a problem.
Therefore, we could populate the VLAN table of the master, just in case
(for some switches it will not make a difference), so that network I/O
can work even with a VLAN filtering master.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When the bridge has VLAN awareness disabled there isn't any duplication
of functionality, since the bridge does not process VLAN. Don't deny
adding 8021q uppers to DSA switch ports in that case. The switch is
supposed to simply pass traffic leaving the VLAN tag as-is, and the
stack will happily strip the VLAN tag for all 8021q uppers that exist.
We need to ensure that there are no 8021q uppers when the user attempts
to enable bridge vlan_filtering.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The current logic beats me a little bit. The comment that "bridge skips
-EOPNOTSUPP, so skip the prepare phase" was introduced in commit
fb2dabad69 ("net: dsa: support VLAN filtering switchdev attr").
I'm not sure:
(a) ok, the bridge skips -EOPNOTSUPP, but, so what, where are we
returning -EOPNOTSUPP?
(b) even if we are, and I'm just not seeing it, what is the causality
relationship between the bridge skipping -EOPNOTSUPP and DSA
skipping the prepare phase, and just returning zero?
One thing is certain beyond doubt though, and that is that DSA currently
refuses VLAN filtering from the "commit" phase instead of "prepare", and
that this is not a good thing:
ip link add br0 type bridge
ip link add br1 type bridge vlan_filtering 1
ip link set swp2 master br0
ip link set swp3 master br1
[ 3790.379389] 001: sja1105 spi0.1: VLAN filtering is a global setting
[ 3790.379399] 001: ------------[ cut here ]------------
[ 3790.379403] 001: WARNING: CPU: 1 PID: 515 at net/switchdev/switchdev.c:157 switchdev_port_attr_set_now+0x9c/0xa4
[ 3790.379420] 001: swp3: Commit of attribute (id=6) failed.
[ 3790.379533] 001: [<c11ff588>] (switchdev_port_attr_set_now) from [<c11b62e4>] (nbp_vlan_init+0x84/0x148)
[ 3790.379544] 001: [<c11b62e4>] (nbp_vlan_init) from [<c11a2ff0>] (br_add_if+0x514/0x670)
[ 3790.379554] 001: [<c11a2ff0>] (br_add_if) from [<c1031b5c>] (do_setlink+0x38c/0xab0)
[ 3790.379565] 001: [<c1031b5c>] (do_setlink) from [<c1036fe8>] (__rtnl_newlink+0x44c/0x748)
[ 3790.379573] 001: [<c1036fe8>] (__rtnl_newlink) from [<c1037328>] (rtnl_newlink+0x44/0x60)
[ 3790.379580] 001: [<c1037328>] (rtnl_newlink) from [<c10315fc>] (rtnetlink_rcv_msg+0x124/0x2f8)
[ 3790.379590] 001: [<c10315fc>] (rtnetlink_rcv_msg) from [<c10926b8>] (netlink_rcv_skb+0xb8/0x110)
[ 3790.379806] 001: ---[ end trace 0000000000000002 ]---
[ 3790.379819] 001: sja1105 spi0.1 swp3: failed to initialize vlan filtering on this port
So move the current logic that may fail (except ds->ops->port_vlan_filtering,
that is way harder) into the prepare stage of the switchdev transaction.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This is checking for the following order of operations, and makes sure
to deny that configuration:
ip link add link swp2 name swp2.100 type vlan id 100
ip link add br0 type bridge vlan_filtering 1
ip link set swp2 master br0
bridge vlan add dev swp2 vid 100
Instead of using vlan_for_each(), which looks at the VLAN filters
installed with vlan_vid_add(), just track the 8021q uppers. This has the
advantage of freeing up the vlan_vid_add() call for actual VLAN
filtering.
There is another change in this patch. The check is moved in slave.c,
from switch.c. I don't think it makes sense to have this 8021q upper
check for each switch port that gets notified of that VLAN addition
(these include DSA links and CPU ports, we know those can't have 8021q
uppers because they don't have a net_device registered for them), so
just do it in slave.c, for that one slave interface.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
DSA tries to prevent having a VLAN added by a bridge and by an 802.1Q
upper at the same time. It does that by checking the VID in
.ndo_vlan_rx_add_vid(), since that's something that the 8021q module
calls, via vlan_vid_add(). When a VLAN matches in both subsystems, this
check returns -EBUSY.
However the vlan_vid_add() function isn't specific to the 8021q module
in any way at all. It is simply the kernel's way to tell an interface to
add a VLAN to its RX filter and not drop that VLAN. So there's no reason
to return -EBUSY when somebody tries to call vlan_vid_add() for a VLAN
that was installed by the bridge. The proper behavior is to accept that
configuration.
So what's wrong is how DSA checks that it has an 8021q upper. It should
look at the actual uppers for that, not just assume that the 8021q
module was somewhere in the call stack of .ndo_vlan_rx_add_vid().
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
We'll be adding a new check in the PRECHANGEUPPER notifier, where we'll
need to check some VLAN uppers. It is hard to do that when there is
already a function named dsa_slave_upper_vlan_check. So rename this one.
Not to mention that this function probably shouldn't have started with
"dsa_slave_" in the first place, since the struct net_device argument
isn't a DSA slave, but an 8021q upper of one.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
There doesn't seem to be any strong technical reason for doing it this
way, but we'll be adding more checks for invalid upper device
configurations, and it will be easier to have them all grouped under
PRECHANGEUPPER.
Tested that it still works:
ip link set br0 type bridge vlan_filtering 1
ip link add link swp2 name swp2.100 type vlan id 100
ip link set swp2.100 master br0
[ 20.321312] br0: port 5(swp2.100) entered blocking state
[ 20.326711] br0: port 5(swp2.100) entered disabled state
Error: dsa_core: Cannot enslave VLAN device into VLAN aware bridge.
[ 20.346549] br0: port 5(swp2.100) entered blocking state
[ 20.351957] br0: port 5(swp2.100) entered disabled state
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Common pattern of handling deferred probe can be simplified with
dev_err_probe(). Less code and also it prints the error value.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
rewritten syscall number, from Kees Cook.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEzv7L6UO9uDPlPSfHEsHwGGHeVUoFAl9ntRoACgkQEsHwGGHe
VUojcQ//SuRLaKH0JSSfMCKWtnqfhE4bhExaQyj9hqwDI60mdbnm+uTCI5+mWUPr
B2C5+wxBJ+wHKZgPHOHP5ZW2h9bEkHVBtTjLAJv3VdCNtckANZJDyVe7b91kG0Ku
+qHKtQU5zkVjAWo6BNBG84SpDBFDZP7E2Dk/085QwLHdJfYlXB2KlpsP3QAovYq7
abj0C9OxZKABhfuf/bOXHF3aJ/3Yq+HHiqP+GLFjzlGj82uuAMQwwSyUw3Qj8Mb2
J9XXI+7U11EBDEeedT3+YLtp0qqLz4v0Ijg3EQS3Pii7fwpeI/Cz23dbv1gLkqUY
qv/uY/Lbr4UplL09P4MFXH98cfjqutC7phNlhrpQqckNzNcVUxBPEGN87nW4KE46
wKYP7I0Os1KogqVvxTmz3FWzYl1ciUHBaINFzto/8EZXLuX89w1ASmuTzS6qP2EW
w7IvvJNVaQNui6Vfk8EOJ7HKudoMHIQb3Y4XmJpM1/CdaPW1dt/9ZG1llt1n716r
5v3SkAGRQgZcbyQQgDeAd6KgDsWhPINmCpaUaLytZLuQRTMc9R06dkvOMIKoq3gY
vEKSO9jAQnVqJSr5WYYJxYbecjcVIQ4+HSqGU+4Tt0J/CkJ4cIlgzHv33B8OSJEH
xrdn3oUXZl02jImRyljZCL5ZnQ9fVFs2XrCFC7ygE5VBesTV2VQ=
=qMUA
-----END PGP SIGNATURE-----
Merge tag 'core_urgent_for_v5.9_rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull syscall tracing fix from Borislav Petkov:
"Fix the seccomp syscall rewriting so that trace and audit see the
rewritten syscall number, from Kees Cook"
* tag 'core_urgent_for_v5.9_rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
core/entry: Report syscall correctly for trace and audit
Zijlstra.
* Make percpu-rwsem operations on the semaphore's ->read_count IRQ-safe
because it can be used in an IRQ context, from Hou Tao.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEzv7L6UO9uDPlPSfHEsHwGGHeVUoFAl9nsLQACgkQEsHwGGHe
VUo0+g/7B9JzDtRSgchT095VcD8w+YcZTyiJM58q9I9OZMxi1zdJZPyoQZ2xZjnG
aczDJN5H6P6OcBm949EUCHhmDEDfoZpC7Y5FEHe9dJitPmC7rRilGJuz4Im8td3N
DsLhpFe8KUSqRVyygjvjM393md8tw+m4Jq+syjWri4/1wj1Fs4jHdhKWgz6b2cup
JXbfjgVOkHVOTloMHnmgdHOPvkh60/LoG8r/5gzLbD8Z/FTD3BSOCTgw+8L8EB+b
yiWWuEcR5LDjy7sNY2xVhTB+nkHJXe4o+HVufZoAzd1j7FDLfDVSNaZHJVp2m7Gp
W47xRrzIKIJl6DUp5E4TGi9aZvkO/h5kqSOZ4MhfaeEqw9DLW/KxbherJjzVY3bb
Nt74N+N+WOq6riTVx5wJkDRmtT5RaeW1kKJUaSeGMl3fxCken5CKE1WyBbae0GiU
kq3tCn4t0OKCWhuiixFNg6RxuXokjfzXDiHr9aUt3x5musc9P+5YUIdOMsaHwoAH
0YrAZoRCPyE2ABUgKC8hoTc3Y+TIwji7c0B9S2GoHRTm1LZTRURlLOUQyJ4oU9Ez
Vt5TILwre9lX9tTW7BlxlOCYkgRQn78vLBSOy1CEUTsORbdYnv/kCy5S5yHEILpT
f3E345wzdd8zrXGQfX2jsVgNAx0F+81Fb9H9FMJSCFgjIya+SRM=
=70QQ
-----END PGP SIGNATURE-----
Merge tag 'locking_urgent_for_v5.9_rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull locking fixes from Borislav Petkov:
"Two fixes from the locking/urgent pile:
- Fix lockdep's detection of "USED" <- "IN-NMI" inversions (Peter
Zijlstra)
- Make percpu-rwsem operations on the semaphore's ->read_count
IRQ-safe because it can be used in an IRQ context (Hou Tao)"
* tag 'locking_urgent_for_v5.9_rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
locking/percpu-rwsem: Use this_cpu_{inc,dec}() for read_count
locking/lockdep: Fix "USED" <- "IN-NMI" inversions
- ensure that the EFI bootloader control module only probes successfully
on systems that support the EFI SetVariable runtime service
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEnNKg2mrY9zMBdeK7wjcgfpV0+n0FAl9iCawACgkQwjcgfpV0
+n1h9Af/RQakIL5DStaEsG4Z5F91nU2EFn7U3nM+A5qCKfNhBNPvtVWWG+nJPnv1
PmNbbpREWojBjXlztJLwoqssZz20/sIVEo9w8uuiFN1CAKIWgKf4DtqA+Y1+PSWX
XU1hmq4oJZ1oJha0c9SZJAt9dmiLUO/oXSpUab9qQIUyHSZdE6wbdhMHeLj7EJkm
e12HepVaEDePYnUsEuAKAhNYL8gFs6mL13KSw94S0/ds0lTMp3cfFHr11ec2BOtn
RO2AFQBTfVW0ApGk0o+NNoeQJVnDoZ/+RFkvpuSdSTf25zGMT01Y8IFVfvfm7i4y
SwrDlFJRa5F4SmJ7l4Kj3H4op+73Fw==
=VoAH
-----END PGP SIGNATURE-----
Merge tag 'efi-urgent-for-v5.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull EFI fix from Borislav Petkov:
"Ensure that the EFI bootloader control module only probes successfully
on systems that support the EFI SetVariable runtime service"
[ Tag and commit from Ard Biesheuvel, forwarded by Borislav ]
* tag 'efi-urgent-for-v5.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
efi: efibc: check for efivars write capability
* Disable relocation relaxation for the compressed kernel when not built
as -pie as in that case kernels built with clang and linked with LLD
fail to boot due to the linker optimizing some instructions in non-PIE
form; the gory details in the commit message, from Arvind Sankar.
* A fix for the "bad bp value" warning issued by the frame-pointer
unwinder, from Josh Poimboeuf.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEzv7L6UO9uDPlPSfHEsHwGGHeVUoFAl9nqkgACgkQEsHwGGHe
VUo+IQ/+LkX6IfkBmNmyq2+XB7tzCFltBd5F1zTsJXYESPakQRQg085joHvqRAsY
uhxGiLHv4IcyReccshV8TsPYBuocFv4ULPw1VG8xxEUmUvs325USMTZH0rV/JkuF
px/S77IrjIrDsoHv5di2nhjoIRYQbzuKdNKRYvaBPgprhE8odbViVU4swNLRa2VN
jJ4JXva27ZqIIq6EPRnE8vHAk60MlzVhyutFi6YpiM/xvLkVAyQI97r6Pbk4gXVi
SPMS3y4uAb6BJ7kwp1ieFwK499hyCnXyQyn7bcmX/kBV8Br7T3Fhzw5Qrt7SFk2e
AG03DIf5beOoxpXE7GoPsAafeB6GIk8mSEeSoIlY+dnb6GZgksUK9uW2MMuKahxS
uIHjCMvlSs7R6FPw24clqzdYhKOIMnXrCMarrS7lit61dZqkoCEdKJEAsJ9+5Mz/
A+VWfFv6IzNm7xkgtV6yxNisK53k6DL67rf3ULxPOPLERUP2TZDtDEyhoShne5ok
41TJXDs8Ag5pcR1gpsE/vZDKT1ohO7DoYZCR3kJh5u/HT6nXPmoKx4ppi8aiUXUC
bg8lUevFX80rgrEgQA3v53DurZPxBAWx8EFAEuV5DSfb32D7NDwlPwbYVQuS6Un7
rZrnEhIIMVdlhCfqdnmVBt5PcN1fjQ0G2cdK36DSS6c2j5ZYSJw=
=og1U
-----END PGP SIGNATURE-----
Merge tag 'x86_urgent_for_v5.9_rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fixes from Borislav Petkov:
- A defconfig fix (Daniel Díaz)
- Disable relocation relaxation for the compressed kernel when not
built as -pie as in that case kernels built with clang and linked
with LLD fail to boot due to the linker optimizing some instructions
in non-PIE form; the gory details in the commit message (Arvind
Sankar)
- A fix for the "bad bp value" warning issued by the frame-pointer
unwinder (Josh Poimboeuf)
* tag 'x86_urgent_for_v5.9_rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/unwind/fp: Fix FP unwinding in ret_from_fork
x86/boot/compressed: Disable relocation relaxation
x86/defconfigs: Explicitly unset CONFIG_64BIT in i386_defconfig
- Fix an original bug in device-mapper table reference counting when
interrogating dax capability in the component device. This bug was
hidden by the following bug.
- Fix device-mapper to use the proper helper (dax_supported() instead of
the leaf helper generic_fsdax_supported()) to determine dax operation
of a stacked block device configuration. The original implementation
is only valid for one level of dax-capable block device stacking. This
bug was discovered while fixing the below regression.
- Fix an infinite recursion regression introduced by broken attempts to
quiet the generic_fsdax_supported() path and make it bail out before
logging "dax capability not found" errors.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEf41QbsdZzFdA8EfZHtKRamZ9iAIFAl9noTYACgkQHtKRamZ9
iAJuNBAAkuj1C5287OfKLmJGnnPy+MPRaQEkFczsIwmno7qdv7IoUxFnbsd1vnlK
5RlpsmFNu+NDGQ74cZZHFT8pSaOc/6sgchcmGNBdbAaV6uerHlsojMb6YmLASogF
0WIi+0m8i5/zXXFUalAcWGfxNRYwVbfH/wdiu7+ZNvbvQ577nOHU4jgMX/nUbvQq
dXF6T4BOFqSfXO0xPenCWP27SDBRWkztXQMdWh+mcayiIvXf/l9/Ir1jx0hpM5zb
Bdllpn/BMcvqzKjGAbhGuRgEPQHWaRoaCSg0Evb60e3lNxh75JL6Wj1xRmkTt3HG
B4YJ0Jkm0vENxi8dUvolX3s6nd/rdbtgzKQZbPh/+xVZQBzLm07VUMNKgD+mFGuQ
OHj9njHuRGk+rMgjJFD5TBUkNZwK9s0y0iB+aeIo9WPcBwFZAir3NOEJ8kXoo6vZ
LuvukOHmf8+7agPEZuhVymruP+Sc3c03SIHk8HJfn9DWUtD9IXUuvb0BIho2h0nE
9PLYt95bQF4yxYP0N2BYxpVxcoByXcbwDzBCUIOnIbu11hLuQ/ZKfV4CP8cDj646
ZTHA7rArJs5NyIoRBGs6rtkc2fSt1uG2nm65zNLvx0KV/rqhYFWX26ZX7u0WFrFa
yhtx1hVk5/RRdU3p9e595rZDjXHK0YbK8XAMI2Dp702zvVgykN4=
=dSAf
-----END PGP SIGNATURE-----
Merge tag 'libnvdimm-fixes-5.9-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm
Pull libnvdimm fixes from Dan Williams:
"A handful of fixes to address a string of mistakes in the mechanism
for device-mapper to determine if its component devices are dax
capable.
- Fix an original bug in device-mapper table reference counting when
interrogating dax capability in the component device. This bug was
hidden by the following bug.
- Fix device-mapper to use the proper helper (dax_supported() instead
of the leaf helper generic_fsdax_supported()) to determine dax
operation of a stacked block device configuration. The original
implementation is only valid for one level of dax-capable block
device stacking. This bug was discovered while fixing the below
regression.
- Fix an infinite recursion regression introduced by broken attempts
to quiet the generic_fsdax_supported() path and make it bail out
before logging "dax capability not found" errors"
* tag 'libnvdimm-fixes-5.9-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm:
dax: Fix stack overflow when mounting fsdax pmem device
dm: Call proper helper to determine dax support
dm/dax: Fix table reference counts
diag318 code was merged in 5.9-rc1, let us add some
missing documentation
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABAgAGBQJfXxjIAAoJEBF7vIC1phx8nvQP/jN1mdF8h18ylQjSyY+e4ZS0
yogItIlHUSFAAVesLe1NiKZWi7gYj6ZkN4E5qaze2NX4+YgM5raqb25p6K0in4b5
PARFOCQeRO9BmT+VhGJBoJplfSIbqwche0A5606/0jYtakRv3ZJh+gMZGR8Tk5u9
nZgvJ/6jD8sPQ/pyZGr6L1UgHD661UZ8U/E3qfMYGyLpRzQiKaiGQNVCvWdMdXL1
M0XvCati9BRIvZtuqSUzLJVGf14ca2UH6eTOZkp0BpR+dckHPaocgyqpougR21Ht
u1x6VBIKDCAy/EYs7Rmk2PBwY64Ym155m9yYHuuNPmm+ruPaz/A0YJJ25bhK1J+S
hirc4EVaCASwpeYuvcRDY9SyspSxLFkU0GXAj6GqLPlM/w2BgWU0oBENNGZe0Ayt
whdQjFZGNqlHucgO7HkVYbAHkCxHlfnK2Osfs1apzppfpwrjtTs6LvPpGCXYInWx
lOAd9OUk7K6wmC1WktvXV+HMsTB4/ko1pwRcsBiga7hTtawT/xI3W0TtpzrbPwIP
0bpxmC+D+dAZjj7FbXXpyuxMsotoWIEttdBajuTYHeiQQq+Q/4BMDaHMA5n1Vk0F
gq5wAZZUplkeCWXsjNm3EPnBMyCl5CQee+vns7mD0Hx/IjqoZShXSzYvVyP25MYb
w22dAOEiEl0fq54yxE3p
=y7Nx
-----END PGP SIGNATURE-----
Merge tag 'kvm-s390-master-5.9-1' of git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux into kvm-master
KVM: s390: add documentation for KVM_CAP_S390_DIAG318
diag318 code was merged in 5.9-rc1, let us add some
missing documentation
The commit 0f99022210 ("KVM: Check the allocation of pv cpu mask") we
have in 5.9-rc5 has two issue:
1) Compilation fails for !CONFIG_SMP, see:
https://bugzilla.kernel.org/show_bug.cgi?id=209285
2) This commit completely disables PV TLB flush, see
https://lore.kernel.org/kvm/87y2lrnnyf.fsf@vitty.brq.redhat.com/
The allocation problem is likely a theoretical one, if we don't
have memory that early in boot process we're likely doomed anyway.
Let's solve it properly later.
This reverts commit 0f99022210.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Fixes the following W=1 kernel build warning(s):
drivers/net/ethernet/marvell/mvneta.c:754:6: warning:
variable 'dummy' set but not used [-Wunused-but-set-variable]
754 | u32 dummy;
| ^~~~~
This variable is not used in function mvneta_mib_counters_clear(), so
remove it to avoid build warning.
Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When budget is non-zero, skb_unref() has already handled the
NULL checking.
When budget is zero, the dev_consume_skb_any() has handled NULL
checking in __dev_kfree_skb_irq(), or dev_kfree_skb() which also
ultimately call skb_unref().
So remove the unnecessary checking in napi_consume_skb().
Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When calculating ancestor_size with IPv6 enabled, simply using
sizeof(struct ipv6_pinfo) doesn't account for extra bytes needed for
alignment in the struct sctp6_sock. On x86, there aren't any extra
bytes, but on ARM the ipv6_pinfo structure is aligned on an 8-byte
boundary so there were 4 pad bytes that were omitted from the
ancestor_size calculation. This would lead to corruption of the
pd_lobby pointers, causing an oops when trying to free the sctp
structure on socket close.
Fixes: 636d25d557 ("sctp: not copy sctp_sock pd_lobby in sctp_copy_descendant")
Signed-off-by: Henry Ptasinski <hptasinski@google.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Avoid copying skb_shared_info frags array in mvneta_swbm_build_skb() since
__build_skb_around() does not overwrite it
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Recycle the received page into the page_pool cache if the dma descriptors
arrived in a wrong order
Fixes: ca0e014609 ("net: mvneta: move skb build after descriptors processing")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
We go to lengths to determine whether the PVID should be set
for this port or not, and then fail to take it into account.
Fix this oversight.
Fixes: d8652956cf ("net: dsa: realtek-smi: Add Realtek SMI driver")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
A continue statement is indented incorrectly, add in the missing
tab.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
* A fix for a lockdep issue to avoid an asserting triggering during early boot.
There shouldn't be any incorrect behavior as the system isn't concurrent at
the time.
* The addition of a missing fence when installing early fixmap mappings.
* A corretion to the K210 device tree's interrupt map.
* A fix for M-mode timer handling on the K210.
I know it's a it of an odd time, so if these don't make rc6 it's not a big
deal, but I thought I'd just send it out now rather that waiting as these are
ready to go.
-----BEGIN PGP SIGNATURE-----
iQJHBAABCgAxFiEEKzw3R0RoQ7JKlDp6LhMZ81+7GIkFAl9njyYTHHBhbG1lckBk
YWJiZWx0LmNvbQAKCRAuExnzX7sYidxhD/4+33HfWLsTefvjiuEIW9W7FvhL+fcm
7X87nirNVsfSVk/jOmQZV1yLZPleT8NA4uXz/nPV5WZ5OGMWBGnKYO3Eza1BPr8o
SMuta4ow19hRhWzaz5DWU/vueEjKgIJesFxLt/bc5qS6pbDVKpkOwjoAu3KdWknP
gFwk5lWZGubNPXlyNTRtirwMtUwPLBFSjJrfgLMpvDHcXc56sF0Rs8JAQcA2vniJ
WudGBzAhYNWJAxBUF+4tLEMXWSp3M2Tl3rnqroJ8dw+OuNO70LcjdLlDwHjNtnN4
mPYdc5YjnFUdGfgyiFfO1s3Y6dp2ypfBKMHkU05yLAjcXI1/lctaIddzsmYka9o2
LXpudzCvsOuRXQpHgwESumfDrpRpzFP7pxeqopxkfRP0DIUWrQtUbnwAHCnuVNWk
ua9InAQ5ew3XmuS5+tz8lnjbH80pvmT5RdUZBdKek9STJYwzf2snGtNXsK8Bw35d
3taPHzJwlBRhItEGhulP/+eM3FjnMiK54dI0UvrIV/eKSICvf6qc7gyOrb7YgztN
9oITrtDgsi0s8BqwpuuKZIwMSiaoafxQrmz0JDFRj6Z9x3FJkjS98oFYYiL/X/QJ
pLRlioaXc2IocEo5+eDYw+E4hR9wxppiCw+BanXxXTx79omt/I3BI8ClIJN7MCdX
TMPXrBmGZV/ovQ==
=eGo8
-----END PGP SIGNATURE-----
Merge tag 'riscv-for-linus-5.9-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux
Pull RISC-V fixes from Palmer Dabbelt:
- A fix for a lockdep issue to avoid an asserting triggering during
early boot. There shouldn't be any incorrect behavior as the system
isn't concurrent at the time.
- The addition of a missing fence when installing early fixmap
mappings.
- A corretion to the K210 device tree's interrupt map.
- A fix for M-mode timer handling on the K210.
* tag 'riscv-for-linus-5.9-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
RISC-V: Resurrect the MMIO timer implementation for M-mode systems
riscv: Fix Kendryte K210 device tree
riscv: Add sfence.vma after early page table changes
RISC-V: Take text_mutex in ftrace_init_nop()
Here are some small USB and one Thunderbolt driver fixes for 5.9-rc6.
Nothing major at all, just some fixes for reported issues, and a quirk
addition:
- typec fixes
- UAS disconnect fix
- usblp race fix
- ehci-hcd modversions build fix
- ignore wakeup quirk table addition
- thunderbolt DROM read fix
All of these have been in linux-next with no reported issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCX2dYBQ8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ynDcwCaAnv7/ntiSeWCAKo5cJr6XKy6DxoAoI3kqe6h
N4a7uHFiAVtNvtvqNr6Q
=iwyf
-----END PGP SIGNATURE-----
Merge tag 'usb-5.9-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB/Thunderbolt fixes from Greg KH:
"Here are some small USB and one Thunderbolt driver fixes.
Nothing major at all, just some fixes for reported issues, and a quirk
addition:
- typec fixes
- UAS disconnect fix
- usblp race fix
- ehci-hcd modversions build fix
- ignore wakeup quirk table addition
- thunderbolt DROM read fix
All of these have been in linux-next with no reported issues"
* tag 'usb-5.9-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
usblp: fix race between disconnect() and read()
ehci-hcd: Move include to keep CRC stable
usb: typec: intel_pmc_mux: Handle SCU IPC error conditions
USB: quirks: Add USB_QUIRK_IGNORE_REMOTE_WAKEUP quirk for BYD zhaoxin notebook
USB: UAS: fix disconnect by unplugging a hub
usb: typec: ucsi: Prevent mode overrun
usb: typec: ucsi: acpi: Increase command completion timeout value
thunderbolt: Retry DROM read once if parsing fails
The dependency on interconnect in the Kconfig was introduced to avoid
the case of interconnect=m and driver=y, but the interconnect framework
has been converted from tristate to bool now. Remove the dependency as
the framework can't be a module anymore.
Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
Here are some small TTY/Serial and one more fbcon fix for 5.9-rc6
They include:
- serial core locking regression fixes
- new device ids for 8250_pci driver
- fbcon fix for syzbot found issue
All have been in linux-next with no reported issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCX2dYjA8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ynbqQCgvYtuyYtnmQcLCwq/SM3gRF1NlMoAn3MXqtea
3cRoC8/q0tOp2SxgPnaY
=YRtI
-----END PGP SIGNATURE-----
Merge tag 'tty-5.9-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
Pull tty/serial/fbcon fixes from Greg KH:
"Here are some small tty/serial and one more fbcon fix.
They include:
- serial core locking regression fixes
- new device ids for 8250_pci driver
- fbcon fix for syzbot found issue
All have been in linux-next with no reported issues"
* tag 'tty-5.9-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
fbcon: Fix user font detection test at fbcon_resize().
serial: 8250_pci: Add Realtek 816a and 816b
serial: core: fix console port-lock regression
serial: core: fix port-lock initialisation
* The first one completes a previous fix to reset a local structure
containing scanned system data properly so that the driver rescans, as
it should, on a second load.
* The second one addresses a refcount underflow due to not paying
attention to the driver whitelest on unregister.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEzv7L6UO9uDPlPSfHEsHwGGHeVUoFAl9nHkgACgkQEsHwGGHe
VUoTsw/+NU2Gga9O+m3jKS8TMpfc+bHpyi0W1wRKS1PCY2NuFagac6jLfhXyIPM+
+flO2uB3y6QfLALV8/XiDxX4yDdIIszyz6tfdavDpcp0W5Pi2zCM8oqvhhAC3ROu
epshWN8NnBKjzw4oDWVH9pT3p/B+2227p/rvmwfCYDw3EA/R09AdJsKT5EYEatvd
Qpq4aPYkfdBP1W70+kaJWSKOBGPtkqsDXgFzLYlFLfX7kysWCHUG9H+g/p3IYdWh
FhXAWsmlXly1gGCksPEmBbuH1ZuJlk4bQw54J7G1svL32Zx4jEdbmtUoo97gJRCT
02eo2G0WHL0LQNfAtAYXMQmxRCjpJFgOQOr5Vxv1CCFEKTPaVgRroyvZoruyESHM
1HLD8YjVqiUAYC23uCb8UFOB/yDxj4F06+zJ0HQZXlULjcGnIXkEsHSjOJszo0Su
Vq6dSVhqBlo+Ap/pmWwdziHOwBakdLxUDF3LXHNXJP+IKW9ansN6179qWZn5fOvG
Slfx2UV7o1tspkBObaQ5S91yNpwFAdUYti9RxcELe6nHHL726kyStfi4ib7yd1pd
qsypIqL0T3qaD1kqAW7MEzD402IydxOa4SyHt+aGLuIJHC3mt1Z8ywJtx3/DtOzn
WBNw6UilkqyoSLRrrfltE2bJ7IJQChP45FqiCRvifnt+lmrcWRU=
=rrjR
-----END PGP SIGNATURE-----
Merge tag 'edac_urgent_for_v5.9_rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras
Pull EDAC fixes from Borislav Petkov:
"Two fixes for resulting from CONFIG_DEBUG_TEST_DRIVER_REMOVE=y
experiments:
- complete a previous fix to reset a local structure containing
scanned system data properly so that the driver rescans, as it
should, on a second load.
- address a refcount underflow due to not paying attention to the
driver whitelest on unregister"
* tag 'edac_urgent_for_v5.9_rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras:
EDAC/ghes: Check whether the driver is on the safe list correctly
EDAC/ghes: Clear scanned data on unload
Commit 604234f336 ("drm/msm: Enable expanded apriv support for a650")
was checking the result of adreno_is_a650() before the gpu revision
got probed in adreno_gpu_init() so it was always coming across as
false. Snoop into the revision ID ahead of time to correctly set the
hw_apriv flag so that it can be used by msm_gpu to properly setup
global buffers.
Fixes: 604234f336 ("drm/msm: Enable expanded apriv support for a650")
Reported-by: Jonathan Marek <jonathan@marek.ca>
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Tested-by: Jonathan Marek <jonathan@marek.ca>
Signed-off-by: Rob Clark <robdclark@chromium.org>
This patch fixes the device name typo.
Fixes: 951ad47003 ("iio: adc: ad7124: move chip ID & name on the chip_info table")
Signed-off-by: Mircea Caprioru <mircea.caprioru@analog.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20200902134222.28357-1-mircea.caprioru@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
We shouldn't be waiting for an event here with a timeout of 100ms when
we're not in the 'timeout' arm of the if condition. Instead we should be
sleeping in the interruptible state (S) until something happens and we
need to wakeup. Right now this kthread is running almost all the time
because it sleeps for 100ms, wakes up, sees there's nothing to do, and
then starts the process all over again. Looking at top it shows up in
the D state (uninterruptible) because it uses wait_event_timeout(). FIx
this up.
Cc: Tanmay Shah <tanmay@codeaurora.org>
Cc: Kuogee Hsieh <khsieh@codeaurora.org>
Reported-by: Douglas Anderson <dianders@chromium.org>
Fixes: 8ede2ecc3e ("drm/msm/dp: Add DP compliance tests on Snapdragon Chipsets")
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Kuogee Hsieh <khsieh@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
- fix qconf warnings and revive help message
-----BEGIN PGP SIGNATURE-----
iQJJBAABCgAzFiEEbmPs18K1szRHjPqEPYsBB53g2wYFAl9m060VHG1hc2FoaXJv
eUBrZXJuZWwub3JnAAoJED2LAQed4NsGDdgP+wR3mDhtgnSr5FVNPBrBhB+MnHo5
cyvfwipYZQKju18CXF4p5/BvXalZZueEzn889vqXpuYC9ZDs7nkU9h4iEspQhuND
AbfpOIo7DV0assbVo6ieZz03lJMqRQ+M4jjyMBf1DGmRvmVZ2EXSasA1239AvCPY
X1Xw/bJ+Mbn2FpP+4t0GXANH6lJlZumGvqcI53nzdIoqU4XL4LON7YX/EfTyGVXX
smSgOQ2v3DyASVu9sTg4RgWmwTfPcaO3UE6Z4uIoJR58dlcfiTEJr5jdLILoXVPd
b+S2kilUJ5arUpBbIVXkqkRxddV/cNA1gQoDe1OAfSqnhA2QaWGsKS6F9aZP8oq5
afcvJKp0pS6z9ZC7mmstS0GtgdwZqDYXaNCNRxTRORJz7+24twqe/m+sPVoYb71c
Bw2aC6IXwGWfQFAYJzMZutz5O8MkQzPhq359zpG5k7XTuGGuxzTQmtNjvaiQszUn
boSdYxEzoLtBNNh70i0vxBJybws3c8/m7Qjq1b76t/Y8HGcDHIU2pCRhKjHkghsP
e+ot4UNl0uj/ulb5F88G5Qu6mYqys5ioGgr2qhxbdj8MubNmxWuf4SukD5luWjqg
G+M2MXQ6JmVOYZ49MlNZUAw7SiMejtQrp/RuI0zUxFK1t823g8QrOE4zUih9DA5V
TQaCGSHGlPsgcceg
=OOQ1
-----END PGP SIGNATURE-----
Merge tag 'kbuild-fixes-v5.9-3' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild
Pull Kbuild fixes from Masahiro Yamada:
"Fix qconf warnings and revive help message"
* tag 'kbuild-fixes-v5.9-3' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild:
kconfig: qconf: revive help message in the info view
kconfig: qconf: fix incomplete type 'struct gstr' warning
kconfig: qconf: use delete[] instead of delete to free array (again)
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
Along with this change, we get additionally:
.owner = THIS_MODULE,
.llseek = seq_lseek,
1. The llseek method is used to change the current read/write position
in a file which can be ignored if you don't use it.
2. The owner is not even a method. Instead, it is a pointer to the
module that “owns” this structure; it is used by the kernel to maintain
the module's usage count which can be ignored.
Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com>
Link: https://lore.kernel.org/r/20200917125113.103550-1-miaoqinglang@huawei.com
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
DM was calling generic_fsdax_supported() to determine whether a device
referenced in the DM table supports DAX. However this is a helper for "leaf" device drivers so that
they don't have to duplicate common generic checks. High level code
should call dax_supported() helper which that calls into appropriate
helper for the particular device. This problem manifested itself as
kernel messages:
dm-3: error: dax access failed (-95)
when lvm2-testsuite run in cases where a DM device was stacked on top of
another DM device.
Fixes: 7bf7eac8d6 ("dax: Arrange for dax_supported check to span multiple devices")
Cc: <stable@vger.kernel.org>
Tested-by: Adrian Huang <ahuang12@lenovo.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Acked-by: Mike Snitzer <snitzer@redhat.com>
Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/r/160061715195.13131.5503173247632041975.stgit@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
A recent fix to the dm_dax_supported() flow uncovered a latent bug. When
dm_get_live_table() fails it is still required to drop the
srcu_read_lock(). Without this change the lvm2 test-suite triggers this
warning:
# lvm2-testsuite --only pvmove-abort-all.sh
WARNING: lock held when returning to user space!
5.9.0-rc5+ #251 Tainted: G OE
------------------------------------------------
lvm/1318 is leaving the kernel with locks still held!
1 lock held by lvm/1318:
#0: ffff9372abb5a340 (&md->io_barrier){....}-{0:0}, at: dm_get_live_table+0x5/0xb0 [dm_mod]
...and later on this hang signature:
INFO: task lvm:1344 blocked for more than 122 seconds.
Tainted: G OE 5.9.0-rc5+ #251
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:lvm state:D stack: 0 pid: 1344 ppid: 1 flags:0x00004000
Call Trace:
__schedule+0x45f/0xa80
? finish_task_switch+0x249/0x2c0
? wait_for_completion+0x86/0x110
schedule+0x5f/0xd0
schedule_timeout+0x212/0x2a0
? __schedule+0x467/0xa80
? wait_for_completion+0x86/0x110
wait_for_completion+0xb0/0x110
__synchronize_srcu+0xd1/0x160
? __bpf_trace_rcu_utilization+0x10/0x10
__dm_suspend+0x6d/0x210 [dm_mod]
dm_suspend+0xf6/0x140 [dm_mod]
Fixes: 7bf7eac8d6 ("dax: Arrange for dax_supported check to span multiple devices")
Cc: <stable@vger.kernel.org>
Cc: Jan Kara <jack@suse.cz>
Cc: Alasdair Kergon <agk@redhat.com>
Cc: Mike Snitzer <snitzer@redhat.com>
Reported-by: Adrian Huang <ahuang12@lenovo.com>
Reviewed-by: Ira Weiny <ira.weiny@intel.com>
Tested-by: Adrian Huang <ahuang12@lenovo.com>
Link: https://lore.kernel.org/r/160045867590.25663.7548541079217827340.stgit@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
To show the trb ring of streams, use the exsiting ring files of bulk ep
to show trb ring of one specific stream ID, which stream ID's trb ring
will be shown, is controlled by a new debugfs file stream_id, this is to
avoid to create a large number of dir for every allocate stream IDs,
another debugfs file stream_context_array is created to show all the
allocated stream context array entries.
Signed-off-by: Li Jun <jun.li@nxp.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20200918131752.16488-11-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Make sure xHC completes the configure endpoint command and xhci driver
sets the ring pointers correctly before we create the user readable
debugfs file.
In theory there was a small gap where a user could have read the
debugfs file and cause a NULL pointer dereference error as ring
pointer was not yet set, in practise we want this change to simplify
the upcoming streams debugfs support.
Fixes: 02b6fdc2a1 ("usb: xhci: Add debugfs interface for xHCI driver")
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20200918131752.16488-10-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
controllers with XHCI_AVOID_BEI quirk cause too frequent interrupts
and affect power management.
To avoid interrupting on every isochronous interval the BEI (Block
Event Interrupt) flag is set for all except the last Isoch TRB in a URB.
This lead to event ring filling up in case several isoc URB were
queued and cancelled rapidly, which some controllers didn't
handle well, and thus the XHCI_AVOID_BEI quirk was introduced.
see commit 227a4fd801 ("usb: xhci: apply XHCI_AVOID_BEI quirk to all
Intel xHCI controllers")
With the XHCI_AVOID_BEI quirk each Isoch TRB will trigger an interrupt.
This can cause up to 8000 interrupts per second for isochronous transfers
with HD USB3 cameras, affecting power saving.
The event ring fits 256 events, instead of interrupting on every
isochronous TRB if XHCI_AVOID_BEI is set we make sure at least every
8th Isochronous TRB asserts an interrupt, clearing the event ring.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20200918131752.16488-9-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If the xhci-plat.c is the platform driver, after the runtime pm is
enabled, the xhci_suspend is called if nothing is connected on
the port. When the system goes to suspend, it will call xhci_suspend again
if USB wakeup is enabled.
Since the runtime suspend wakeup setting is not always the same as
system suspend wakeup setting, eg, at runtime suspend we always need
wakeup if the controller is in low power mode; but at system suspend,
we may not need wakeup. So, we move the judgement after changing
wakeup setting.
[commit message rewording -Mathias]
Reviewed-by: Jun Li <jun.li@nxp.com>
Signed-off-by: Peter Chen <peter.chen@nxp.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20200918131752.16488-8-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
With this change, there will be a wakeup entry at /sys/../power/wakeup,
and the user could use this entry to choose whether enable xhci wakeup
features (wake up system from suspend) or not.
Tested-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Peter Chen <peter.chen@nxp.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20200918131752.16488-6-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
