Pablo Neira Ayuso says:
====================
Netfilter fixes for net
The following patchset contains Netfilter fixes for net:
1) Spurious warning when loading rules using the physdev match,
from Todd Seidelmann.
2) Fix FTP conntrack helper debugging output, from Thomas Jarosch.
3) Restore per-netns nf_conntrack_{acct,helper,timeout} sysctl knobs,
from Florian Westphal.
4) Clear skbuff timestamp from the flowtable datapath, also from Florian.
5) Fix incorrect byteorder of NFT_META_BRI_IIFVPROTO, from wenxu.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Daniel Borkmann says:
====================
pull-request: bpf 2019-08-31
The following pull-request contains BPF updates for your *net* tree.
The main changes are:
1) Fix 32-bit zero-extension during constant blinding which
has been causing a regression on ppc64, from Naveen.
2) Fix a latency bug in nfp driver when updating stack index
register, from Jiong.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
When a local endpoint is ceases to be in use, such as when the kafs module
is unloaded, the kernel will emit an assertion failure if there are any
outstanding client connections:
rxrpc: Assertion failed
------------[ cut here ]------------
kernel BUG at net/rxrpc/local_object.c:433!
and even beyond that, will evince other oopses if there are service
connections still present.
Fix this by:
(1) Removing the triggering of connection reaping when an rxrpc socket is
released. These don't actually clean up the connections anyway - and
further, the local endpoint may still be in use through another
socket.
(2) Mark the local endpoint as dead when we start the process of tearing
it down.
(3) When destroying a local endpoint, strip all of its client connections
from the idle list and discard the ref on each that the list was
holding.
(4) When destroying a local endpoint, call the service connection reaper
directly (rather than through a workqueue) to immediately kill off all
outstanding service connections.
(5) Make the service connection reaper reap connections for which the
local endpoint is marked dead.
Only after destroying the connections can we close the socket lest we get
an oops in a workqueue that's looking at a connection or a peer.
Fixes: 3d18cbb7fd ("rxrpc: Fix conn expiry timers")
Signed-off-by: David Howells <dhowells@redhat.com>
Tested-by: Marc Dionne <marc.dionne@auristor.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEqG5UsNXhtOCrfGQP+7dXa6fLC2sFAl1nyGUACgkQ+7dXa6fL
C2v8zhAAlJvZ3DQJLnGiXFdBzGLEWP/TtVBHOjXjAVPB/nGUy9VZ8eCx6jgIDOUj
79jFqrO0zoNkdVVmhml8bTt4hl4MlaZbKM5/yz5wg7I3RfAss5cOJyNx4eULYhQQ
V+QPn4uUj7jR/2KBYf+AasFUx4NZVQIeyo3H5mOmi3gatDIR3sqskx48mdSJSR2f
nuila/WE+g/iEygw9TwaqdrfR+4E94Sw4FoHIVy2rIlLWeuOfVInFAn7Tw9CsnZN
nTy+KBiYgJsO5f5bqaoKC7Ku4cmHD+Gy+AciETlvjk5Gjent5V7dHvnSL14pC7jD
WoOXMq+V93uzCHRz2iSHrj0FZJH5k7Q8OlioNr7u4FHdOBqZc1eJvGR6KHcGTOcU
RZGlSwal1+FQ66LY1OIf0EjBYcYOkSB3hZJhTwwMOm1ZWiPdTq/J3FIN+f6POWLL
djd4NVhlYTz8zaDoMIA+iWlGrR3IMy3+uH91CNMJnTRIb4l0wg2As61ffEixD69L
wW7C3VD1ZbFrlEv/33/a9dn0HzEfBrbMCkuKz/IqPj4W4yZNczb+6WOTkIN/nGFE
9u1Pok2W32QeOBxDysQqJa/zT/5suSbhleMRAiGVj78yhKaK340IEmd13a0ihw7m
blw09an6VG9DGFjvy5fFmpmELFw/zXwPhUSZLTWeZy7HQBIdEyU=
=1xih
-----END PGP SIGNATURE-----
Merge tag 'rxrpc-fixes-20190827' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs
David Howells says:
====================
rxrpc: Fix use of skb_cow_data()
Here's a series of patches that replaces the use of skb_cow_data() in rxrpc
with skb_unshare() early on in the input process. The problem that is
being seen is that skb_cow_data() indirectly requires that the maximum
usage count on an sk_buff be 1, and it may generate an assertion failure in
pskb_expand_head() if not.
This can occur because rxrpc_input_data() may be still holding a ref when
it has just attached the sk_buff to the rx ring and given that attachment
its own ref. If recvmsg happens fast enough, skb_cow_data() can see the
ref still held by the softirq handler.
Further, a packet may contain multiple subpackets, each of which gets its
own attachment to the ring and its own ref - also making skb_cow_data() go
bang.
Fix this by:
(1) The DATA packet is currently parsed for subpackets twice by the input
routines. Parse it just once instead and make notes in the sk_buff
private data.
(2) Use the notes from (1) when attaching the packet to the ring multiple
times. Once the packet is attached to the ring, recvmsg can see it
and start modifying it, so the softirq handler is not permitted to
look inside it from that point.
(3) Pass the ref from the input code to the ring rather than getting an
extra ref. rxrpc_input_data() uses a ref on the second refcount to
prevent the packet from evaporating under it.
(4) Call skb_unshare() on secured DATA packets in rxrpc_input_packet()
before we take call->input_lock. Other sorts of packets don't get
modified and so can be left.
A trace is emitted if skb_unshare() eats the skb. Note that
skb_share() for our accounting in this regard as we can't see the
parameters in the packet to log in a trace line if it releases it.
(5) Remove the calls to skb_cow_data(). These are then no longer
necessary.
There are also patches to improve the rxrpc_skb tracepoint to make sure
that Tx-derived buffers are identified separately from Rx-derived buffers
in the trace.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
The devicetree binding lists the phy phy as optional. As such, the
driver should not bail out if it can't find a regulator. Instead it
should just skip the remaining regulator related code and continue
on normally.
Skip the remainder of phy_power_on() if a regulator supply isn't
available. This also gets rid of the bogus return code.
Fixes: 2e12f53663 ("net: stmmac: dwmac-rk: Use standard devicetree property for phy regulator")
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
In xgbe_mod_init(), we should do cleanup if some error occurs
Reported-by: Hulk Robot <hulkci@huawei.com>
Fixes: efbaa82833 ("amd-xgbe: Add support to handle device renaming")
Fixes: 47f164deab ("amd-xgbe: Add PCI device support")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In register_ftrace_function_probe(), we are not checking the return
value of alloc_and_copy_ftrace_hash(). The subsequent call to
ftrace_match_records() may end up dereferencing the same. Add a check to
ensure this doesn't happen.
Link: http://lkml.kernel.org/r/26e92574f25ad23e7cafa3cf5f7a819de1832cbe.1562249521.git.naveen.n.rao@linux.vnet.ibm.com
Cc: stable@vger.kernel.org
Fixes: 1ec3a81a0c ("ftrace: Have each function probe use its own ftrace_ops")
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
The race between adding a function probe and reading the probes that exist
is very subtle. It needs a comment. Also, the issue can also happen if the
probe has has the EMPTY_HASH as its func_hash.
Cc: stable@vger.kernel.org
Fixes: 7b60f3d876 ("ftrace: Dynamically create the probe ftrace_ops for the trace_array")
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
LTP testsuite on powerpc results in the below crash:
Unable to handle kernel paging request for data at address 0x00000000
Faulting instruction address: 0xc00000000029d800
Oops: Kernel access of bad area, sig: 11 [#1]
LE SMP NR_CPUS=2048 NUMA PowerNV
...
CPU: 68 PID: 96584 Comm: cat Kdump: loaded Tainted: G W
NIP: c00000000029d800 LR: c00000000029dac4 CTR: c0000000001e6ad0
REGS: c0002017fae8ba10 TRAP: 0300 Tainted: G W
MSR: 9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 28022422 XER: 20040000
CFAR: c00000000029d90c DAR: 0000000000000000 DSISR: 40000000 IRQMASK: 0
...
NIP [c00000000029d800] t_probe_next+0x60/0x180
LR [c00000000029dac4] t_mod_start+0x1a4/0x1f0
Call Trace:
[c0002017fae8bc90] [c000000000cdbc40] _cond_resched+0x10/0xb0 (unreliable)
[c0002017fae8bce0] [c0000000002a15b0] t_start+0xf0/0x1c0
[c0002017fae8bd30] [c0000000004ec2b4] seq_read+0x184/0x640
[c0002017fae8bdd0] [c0000000004a57bc] sys_read+0x10c/0x300
[c0002017fae8be30] [c00000000000b388] system_call+0x5c/0x70
The test (ftrace_set_ftrace_filter.sh) is part of ftrace stress tests
and the crash happens when the test does 'cat
$TRACING_PATH/set_ftrace_filter'.
The address points to the second line below, in t_probe_next(), where
filter_hash is dereferenced:
hash = iter->probe->ops.func_hash->filter_hash;
size = 1 << hash->size_bits;
This happens due to a race with register_ftrace_function_probe(). A new
ftrace_func_probe is created and added into the func_probes list in
trace_array under ftrace_lock. However, before initializing the filter,
we drop ftrace_lock, and re-acquire it after acquiring regex_lock. If
another process is trying to read set_ftrace_filter, it will be able to
acquire ftrace_lock during this window and it will end up seeing a NULL
filter_hash.
Fix this by just checking for a NULL filter_hash in t_probe_next(). If
the filter_hash is NULL, then this probe is just being added and we can
simply return from here.
Link: http://lkml.kernel.org/r/05e021f757625cbbb006fad41380323dbe4e3b43.1562249521.git.naveen.n.rao@linux.vnet.ibm.com
Cc: stable@vger.kernel.org
Fixes: 7b60f3d876 ("ftrace: Dynamically create the probe ftrace_ops for the trace_array")
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
- A fix for update_sections_early() to cope with NULL ->mm pointers.
- A correction to the backtrace code to allow proper backtraces.
- Reinforcement of pfn_valid() with PFNs >= 4GiB.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIVAwUAXWljsvTnkBvkraxkAQKsqxAApF0asWjoPHZaA2rS7h0GWVV5290bluy1
LcT9MyKPNc8K0AyOAhj6m9OnBlzbYOlERklDNrV5uHEprJYjzI5Mp9t5cmwqBOne
hzD9rrFAdhkGP4A0WXeTIPREDIzxMZUgurTwt/zVdm2V5UcwOdrybj4+F7gQGxFl
A1URkGFV3ZqOpSl02t9gV5hyqtzry95qRWgL0JQAlSHnbKcDpoiUvoC7ayAKXKRR
VT9lD/KfuGFSaxi436L8p/TcPlluY+zpTzs+Eambd7Z13kkRB/NlVEBEpvNMnelu
ORZMNSmQp7mnWMfSlJoYV1wCVSIIyf+BNZ4keTTecppOTawph41keDqF6YCTT+sB
yqtKbWgP50ElRZhalHcH2K8jPrQASwZBkQJ0xtT0NecrFJA9AMegege1Jt+54RyZ
X7yfIVt+/T/cYsCJDiPQVgqS/994kz9ifShl8nmQEE9Qg61zh6hFEOkL5/eMt82s
KxSM+jyoPJYrSuuTi7jIQvWLnz+gJ4bo3FpHH+vkvWUDrImi9J4hzhvvakCxAV0U
tudCRLSM3J/gM/zIEJFvMxM1ejC08EbJZWToZ/0/MwvejVSDAgVXEB1/27TTnM6q
6pru83LjQpsKODO3pHQjrwoGByisNeZ0oyaWCL4T0FgwuZ4IXSidgWB4VXpXZnO+
MuK9qjwvYac=
=ec12
-----END PGP SIGNATURE-----
Merge tag 'for-linus' of git://git.armlinux.org.uk/~rmk/linux-arm
Pull ARM fixes from Russell King:
"Three fixes for ARM this time around:
- A fix for update_sections_early() to cope with NULL ->mm pointers.
- A correction to the backtrace code to allow proper backtraces.
- Reinforcement of pfn_valid() with PFNs >= 4GiB"
* tag 'for-linus' of git://git.armlinux.org.uk/~rmk/linux-arm:
ARM: 8901/1: add a criteria for pfn_valid of arm
ARM: 8897/1: check stmfd instruction using right shift
ARM: 8874/1: mm: only adjust sections of valid mm structures
If check_cached_key() returns a non-NULL value, we still need to call
key_type::match_free() to undo key_type::match_preparse().
Fixes: 7743c48e54 ("keys: Cache result of request_key*() temporarily in task_struct")
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The majority of the fixes this time are for OMAP hardware,
here is a breakdown of the significant changes:
Various device tree bug fixes:
- TI am57xx boards need a voltage level fix to avoid damaging SD cards
- vf610-bk4 fails to detect its flash due to an incorrect description
- meson-g12a USB phy configuration fails
- meson-g12b reboot should not power off the SD card
- Some corrections for apparently harmless differences from the
documentation.
Regression fixes:
- ams-delta FIQ interrupts broke in 5.3
- TI am3/am4 mmc controllers broke in 5.2
The logic_pio driver (used on some Huawei ARM servers) needs a few
bug fixes for reliability.
A couple of compile-time warning fixes
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJdaUf1AAoJEJpsee/mABjZ+7YQALOXvCCfmYKkOSflNKEVXuiZ
tL7uj5PT2E136JoAoyEs8pqXLSpFnC/PxZ7GuN3+ZD0lqVz8PbIn5MhJ9KRrRzSF
lazjW++VQcFt1KR77l2umVi9/KiYD7UXU1HHmWN8+D/PX6EM+Gv1j65Ve8oTRn76
kfsq58y2YC6Rqv9dkiK91mteQ2bdA9b4O33V5M+Idq3aBwyNr5KKihDsNKPSvKl9
ibGmfGnukVcrVtU2reaUxNp2G1OsIKswq2bB0VwUlFMipPxML6rv94dJxDblb2Ns
nq3LeG+1TF9mbAxya2sWaF6fIBpxdEU5llFYRoIknSS+F9qM/nSVsi5WsyJJnCxk
mEvJLhhtt4gH2TZmPvZ6sPWFSVBHDnr8V3F4c0//aTRCN+tV7BCYbf8f3rv/CRNq
MLRsw8gHVPZyUUK9M4afeR3PqEx4/hbU9mpCtduAsiudnA1gtDBfQp8ODMop8aJ1
tCCdbFPoZIKKU/yhUm0OAbykPLVGb9zWGBNwYWuNs6IZFkyksGoFg1AspzKGvrcD
Knywz9dSmiDxRi3qDjVEd/9Rr/CtvUHmbaGq8RlTHmbB7WYoW84UPSD419V4j9vd
eIn4ScejKJCZUDACQsQXh7nnbg+QtnMq+3ODzvjsax2FAEKd8xtaZElSs8OA0U6b
xdqEuHPNY8VWBFXwAfdp
=mV+7
-----END PGP SIGNATURE-----
Merge tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
Pull ARM SoC fixes from Arnd Bergmann:
"The majority of the fixes this time are for OMAP hardware, here is a
breakdown of the significant changes:
Various device tree bug fixes:
- TI am57xx boards need a voltage level fix to avoid damaging SD
cards
- vf610-bk4 fails to detect its flash due to an incorrect description
- meson-g12a USB phy configuration fails
- meson-g12b reboot should not power off the SD card
- Some corrections for apparently harmless differences from the
documentation.
Regression fixes:
- ams-delta FIQ interrupts broke in 5.3
- TI am3/am4 mmc controllers broke in 5.2
The logic_pio driver (used on some Huawei ARM servers) got a few bug
fixes for reliability.
And a couple of compile-time warning fixes"
* tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (26 commits)
soc: ixp4xx: Protect IXP4xx SoC drivers by ARCH_IXP4XX || COMPILE_TEST
soc: ti: pm33xx: Make two symbols static
soc: ti: pm33xx: Fix static checker warnings
ARM: OMAP: dma: Mark expected switch fall-throughs
ARM: dts: Fix incomplete dts data for am3 and am4 mmc
bus: ti-sysc: Simplify cleanup upon failures in sysc_probe()
ARM: OMAP1: ams-delta-fiq: Fix missing irq_ack
ARM: dts: dra74x: Fix iodelay configuration for mmc3
ARM: dts: am335x: Fix UARTs length
ARM: OMAP2+: Fix omap4 errata warning on other SoCs
bus: hisi_lpc: Add .remove method to avoid driver unbind crash
bus: hisi_lpc: Unregister logical PIO range to avoid potential use-after-free
lib: logic_pio: Add logic_pio_unregister_range()
lib: logic_pio: Avoid possible overlap for unregistering regions
lib: logic_pio: Fix RCU usage
arm64: dts: amlogic: odroid-n2: keep SD card regulator always on
arm64: dts: meson-g12a-sei510: enable IR controller
arm64: dts: meson-g12a: add missing dwc2 phy-names
ARM: dts: vf610-bk4: Fix qspi node description
ARM: dts: Fix incorrect dcan register mapping for am3, am4 and dra7
...
- Fix locking on list traversal (siw)
Signed-off-by: Doug Ledford <dledford@redhat.com>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEErmsb2hIrI7QmWxJ0uCajMw5XL90FAl1pQsMACgkQuCajMw5X
L92NqBAAjgG/rV9RuUjxr4+tBkyp2OIDCma0bP8q5x5g6jBaaxgzrzZjwYf4W5ae
MVbj7DIf+toAXm19+O5Kh+SjVKcCh0zcRlBbjqn8ZUtONFE4Dx2OsbYyPGA8SMP/
n+J5O7GtjuPSH+lF0IsrzO9dm4v2RLtL2iE9ryxvEjKWXqe/sxzBKgk3sMmYfKqZ
eJQIcmDqdFjmmbrSTRKqPoHdGCAe1y9xDvo4FNr1Yv2Rk8ZSkL1J48QY7Cv6i9uU
Z28VaMJRhh+qNalYV49yvwuwsvsNZpOlQv1/p/BK59TbfZCYa2/X9oTWLZO45nGE
fD193+SEsBWE7x2nPRlBL1cGAojkgMi84O7thyngZP5z5W6etp9/LgYlDYo6NCBy
FmBGAbt4dYEGChx8fIwoe6cDgEQLJL6NYu4GP/dkSW16WQB6c9DVE5+vyAe9idp+
f+Ou866LzHCSA3Fv4fOnf7ak3Q27s9QWu+zTBNH2BWGOCOQufExpIo0p8yskEhcJ
n7n9XduRlnDAvgcACSlUGtoI4+cjLawF5RdDD5T5bMDj0RNc4gzcBwD8w6rHeET1
zitzS6C50+VFfF+GK/Bd8jL4kl0jb314fECOmJVilIY7rzlv/NSsKDbahr3v4qdn
T8DkNT9ctRm4evP6XQdPQYlbHRkgBckN5HD/0VvLDckIpyHhzg8=
=T0bq
-----END PGP SIGNATURE-----
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma
Pull rdma fix from Doug Ledford:
"Much calmer week this week. Just one patch queued up:
The way the siw driver was locking around the traversal of the list of
ipv6 addresses on a device was causing a scheduling while atomic
issue. Bernard straightened it out by using the rtnl_lock"
* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma:
RDMA/siw: Fix IPv6 addr_list locking
-----BEGIN PGP SIGNATURE-----
iQFHBAABCAAxFiEEydHwtzie9C7TfviiSn/eOAIR84sFAl1pLO8THGlkcnlvbW92
QGdtYWlsLmNvbQAKCRBKf944AhHzi8ceB/4qXnsvkIfB7XMxg8KUXOtJiJPJX+j2
H8yFESAL7Qof3mJVmsnVREW0LBECxJbipSkFmsJtFgLMlGLAkGMvJQjrmp4EWlc7
OIMWirTkZHLUgWV485EXDerlL9XSyiTxQ3ccKLwQSSxeN+EBU8CnzYzw5rUy2pJl
n1RheF+nRn4sLeOggnXPbEEYHqyDcgOzVVBbP7dq0om8H8KV/1jz4w12Ybpm4BSb
s/3Sp9kSeT0VySlmoeSYly5/rNnYHgHzV5/qjEbzugVnqPrLTC+j9t3vJTpMoH7T
zum6Y41mxWLdXiiYAdccOmGEKXDXk2yxFEIVKwYBnsvLS1A11cXpuPdL
=3uNw
-----END PGP SIGNATURE-----
Merge tag 'ceph-for-5.3-rc7' of git://github.com/ceph/ceph-client
Pull two ceph fixes from Ilya Dryomov:
"A fix for a -rc1 regression in rbd and a trivial static checker fix"
* tag 'ceph-for-5.3-rc7' of git://github.com/ceph/ceph-client:
rbd: restore zeroing past the overlap when reading from parent
libceph: don't call crypto_free_sync_skcipher() on a NULL tfm
amdgpu:
- Fix GFXOFF regression for PCO and RV2
- Fix missing fence reference
- Fix VG20 power readings on certain SMU firmware versions
- Fix dpm level setup for VG20
- Add an ATPX laptop quirk
i915:
- Fix DP MST max BPC property creation after DRM register
- Fix unused ggtt deballooning and NULL dereference in guest
- Fix DSC eDP transcoder identification
- Fix WARN from DMA API debug by setting DMA max segment size
qxl:
- Make qxl reservel the vga ports using vgaargb to prevent switching to vga compatibility mode.
omap:
- Fix omap port lookup for SDI output
virtio:
- Use virtio_max_dma_size to fix an issue with swiotlb.
komeda:
- Compiler fixes to komeda.
- Add missing of_node_get() call in komeda.
- Reorder the komeda de-init functions.
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJdaIIyAAoJEAx081l5xIa+3l0QAIe8d+rN8YdSMoVMlh/GlPGG
fHW7y2zAQyMyeOJs6dBhzUB1vO+aPF8+czplmbYU1optKj+XIdT6osqmdoeUBVrK
0mSRjEQrEwMXKTnFWxyOMnFVGC84DW7pR8U6QiyEkXECThccoGaD0cKM5vFyOQr6
ALuzxJUW/1LNO2795ebVytqG4oq934NxeqFIG9f6Axa9VGLUG9Leq8hMQKXVvQbP
AkHg2m+96MIHSXponYuZkxr8A9E261Sr5lX0ZsEPgoZwqKXr7n92uinfOPhClAlH
u9ArBqHgL/YgncpXnAlOUybrP35e7GLMUZTuGGJtL2lcNVH3T6zqzPovFX880sNL
1r6LkrxyEY8Y6GgNeHowQZFtC4LECyl8njLHyEvBD4zsxtLAPnpM9uZQXLu/iB8c
9wX5Fby+LZbfMGyH8touv2MNPBglDntV1SRj/FSZnuxI8eUGNbL4wIJMibwOT+kS
Zg/60IPVIQYz9mmAuJqCtjy7xCl/MQDSzhp9aZqkB1i6CAIfnRhVaSgOTOgYFPC6
K/x7Mo8dc048h5Ud7t9FbxFR0d3509oOEWlu0dFthOdmnyO7MA+utX/3/pdhY17q
ATbEAhmt7EB2llSNKUII46CH/Z+gTv9E/wauXyqH0+m52HZntWPZDBkiOnMUGZsk
5gW5OoAOZ4WUGQ9ts5qc
=4KLA
-----END PGP SIGNATURE-----
Merge tag 'drm-fixes-2019-08-30' of git://anongit.freedesktop.org/drm/drm
Pull drm fixes from Dave Airlie:
"Nothing too crazy, there's probably more patches than I'd like at this
stage, but they are all pretty self contained:
amdgpu:
- Fix GFXOFF regression for PCO and RV2
- Fix missing fence reference
- Fix VG20 power readings on certain SMU firmware versions
- Fix dpm level setup for VG20
- Add an ATPX laptop quirk
i915:
- Fix DP MST max BPC property creation after DRM register
- Fix unused ggtt deballooning and NULL dereference in guest
- Fix DSC eDP transcoder identification
- Fix WARN from DMA API debug by setting DMA max segment size
qxl:
- Make qxl reservel the vga ports using vgaargb to prevent switching to vga compatibility mode.
omap:
- Fix omap port lookup for SDI output
virtio:
- Use virtio_max_dma_size to fix an issue with swiotlb.
komeda:
- Compiler fixes to komeda.
- Add missing of_node_get() call in komeda.
- Reorder the komeda de-init functions"
* tag 'drm-fixes-2019-08-30' of git://anongit.freedesktop.org/drm/drm:
drm/komeda: Reordered the komeda's de-init functions
drm/amdgpu: fix GFXOFF on Picasso and Raven2
drm/amdgpu: Add APTX quirk for Dell Latitude 5495
drm/amd/powerplay: correct Vega20 dpm level related settings
drm/i915: Call dma_set_max_seg_size() in i915_driver_hw_probe()
drm/i915/dp: Fix DSC enable code to use cpu_transcoder instead of encoder->type
drm/i915: Don't deballoon unused ggtt drm_mm_node in linux guest
drm/i915: Do not create a new max_bpc prop for MST connectors
drm/powerplay: Fix Vega20 power reading again
drm/powerplay: Fix Vega20 Average Power value v4
drm/amdgpu: fix dma_fence_wait without reference
drm/komeda: Add missing of_node_get() call
drm/komeda: Clean warning 'komeda_component_add' might be a candidate for 'gnu_printf'
drm/komeda: Fix warning -Wunused-but-set-variable
drm/komeda: Fix error: not allocating enough data 1592 vs 1584
drm/virtio: use virtio_max_dma_size
drm/omap: Fix port lookup for SDI output
drm/qxl: get vga ioports
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct qcom_iommu_dev {
...
struct qcom_iommu_ctx *ctxs[0]; /* indexed by asid-1 */
};
Make use of the struct_size() helper instead of an open-coded version
in order to avoid any potential type mistakes.
So, replace the following form:
sizeof(*qcom_iommu) + (max_asid * sizeof(qcom_iommu->ctxs[0]))
with:
struct_size(qcom_iommu, ctxs, max_asid)
Also, notice that, in this case, variable sz is not necessary,
hence it is removed.
This code was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
These comments are wrong. request_default_domain_for_dev doesn't just
handle direct mapped domains.
Signed-off-by: Tom Murphy <murphyt7@tcd.ie>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
This reverts commit 557529494d.
Commit 557529494d ("iommu/vt-d: Avoid duplicated pci dma alias
consideration") aimed to address a NULL pointer deference issue
happened when a thunderbolt device driver returned unexpectedly.
Unfortunately, this change breaks a previous pci quirk added by
commit cc346a4714 ("PCI: Add function 1 DMA alias quirk for
Marvell devices"), as the result, devices like Marvell 88SE9128
SATA controller doesn't work anymore.
We will continue to try to find the real culprit mentioned in
557529494d, but for now we should revert it to fix current
breakage.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204627
Cc: Stijn Tintel <stijn@linux-ipv6.be>
Cc: Petr Vandrovec <petr@vandrovec.name>
Reported-by: Stijn Tintel <stijn@linux-ipv6.be>
Reported-by: Petr Vandrovec <petr@vandrovec.name>
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
The cookie is dereferenced before null checking in the function
iommu_dma_init_domain.
This patch moves the dereferencing after the null checking.
Fixes: fdbe574eb6 ("iommu/dma: Allow MSI-only cookies")
Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Remove the "struct mtk_smi_iommu" to simplify the code since it has only
one item in it right now.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
The "mediatek,larb-id" has already been parsed in MTK IOMMU driver.
It's no need to parse it again in SMI driver. Only clean some codes.
This patch is fit for all the current mt2701, mt2712, mt7623, mt8173
and mt8183.
After this patch, the "mediatek,larb-id" only be needed for mt2712
which have 2 M4Us. In the other SoCs, we can get the larb-id from M4U
in which the larbs in the "mediatek,larbs" always are ordered.
Correspondingly, the larb_nr in the "struct mtk_smi_iommu" could also
be deleted.
CC: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Evan Green <evgreen@chromium.org>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
The register VLD_PA_RNG(0x118) was forgot to backup while adding 4GB
mode support for mt2712. this patch add it.
Fixes: 30e2fccf95 ("iommu/mediatek: Enlarge the validate PA range
for 4GB mode")
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Evan Green <evgreen@chromium.org>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
There are 2 mmu cells in a M4U HW. we could adjust some larbs entering
mmu0 or mmu1 to balance the bandwidth via the smi-common register
SMI_BUS_SEL(0x220)(Each larb occupy 2 bits).
In mt8183, For better performance, we switch larb1/2/5/7 to enter
mmu1 while the others still keep enter mmu0.
In mt8173 and mt2712, we don't get the performance issue,
Keep its default value(0x0), that means all the larbs enter mmu0.
Note: smi gen1(mt2701/mt7623) don't have this bus_sel.
And, the base of smi-common is completely different with smi_ao_base
of gen1, thus I add new variable for that.
CC: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Evan Green <evgreen@chromium.org>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
This patch only move the clk_prepare_enable and config_port into the
runtime suspend/resume callback. It doesn't change the code content
and sequence.
This is a preparing patch for adjusting SMI_BUS_SEL for mt8183.
(SMI_BUS_SEL need to be restored after smi-common resume every time.)
Also it gives a chance to get rid of mtk_smi_larb_get/put which could
be a next topic.
CC: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Evan Green <evgreen@chromium.org>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Normally the M4U HW connect EMI with smi. the diagram is like below:
EMI
|
M4U
|
smi-common
|
-----------------
| | | | ...
larb0 larb1 larb2 larb3
Actually there are 2 mmu cells in the M4U HW, like this diagram:
EMI
---------
| |
mmu0 mmu1 <- M4U
| |
---------
|
smi-common
|
-----------------
| | | | ...
larb0 larb1 larb2 larb3
This patch add support for mmu1. In order to get better performance,
we could adjust some larbs go to mmu1 while the others still go to
mmu0. This is controlled by a SMI COMMON register SMI_BUS_SEL(0x220).
mt2712, mt8173 and mt8183 M4U HW all have 2 mmu cells. the default
value of that register is 0 which means all the larbs go to mmu0
defaultly.
This is a preparing patch for adjusting SMI_BUS_SEL for mt8183.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Evan Green <evgreen@chromium.org>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
The M4U IP blocks in mt8183 is MediaTek's generation2 M4U which use
the ARM Short-descriptor like mt8173, and most of the HW registers
are the same.
Here list main differences between mt8183 and mt8173/mt2712:
1) mt8183 has only one M4U HW like mt8173 while mt2712 has two.
2) mt8183 don't have the "bclk" clock, it use the EMI clock instead.
3) mt8183 can support the dram over 4GB, but it doesn't call this "4GB
mode".
4) mt8183 pgtable base register(0x0) extend bit[1:0] which represent
the bit[33:32] in the physical address of the pgtable base, But the
standard ttbr0[1] means the S bit which is enabled defaultly, Hence,
we add a mask.
5) mt8183 HW has a GALS modules, SMI should enable "has_gals" support.
6) mt8183 need reset_axi like mt8173.
7) the larb-id in smi-common is remapped. M4U should add its larbid_remap.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Evan Green <evgreen@chromium.org>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
In some SoCs like mt8183, SMI add GALS(Global Async Local Sync) module
which can help synchronize for the modules in different clock frequency.
It can be seen as a "asynchronous fifo". This is a example diagram:
M4U
|
----------
| |
gals0-rx gals1-rx
| |
| |
gals0-tx gals1-tx
| |
------------
SMI Common
------------
|
+-----+--------+-----+- ...
| | | |
| gals-rx gals-rx |
| | | |
| | | |
| gals-tx gals-tx |
| | | |
larb1 larb2 larb3 larb4
GALS only help transfer the command/data while it doesn't have the
configuring register, thus it has the special "smi" clock and doesn't
have the "apb" clock. From the diagram above, we add "gals0" and
"gals1" clocks for smi-common and add a "gals" clock for smi-larb.
This patch adds gals clock supporting in the SMI. Note that some larbs
may still don't have the "gals" clock like larb1 and larb4 above.
This is also a preparing patch for mt8183 which has GALS.
CC: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Evan Green <evgreen@chromium.org>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Both mt8173 and mt8183 don't have this vld_pa_rng(valid physical address
range) register while mt2712 have. Move it into the plat_data.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Evan Green <evgreen@chromium.org>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
In mt8173 and mt8183, 0x48 is REG_MMU_STANDARD_AXI_MODE while it is
REG_MMU_CTRL in the other SoCs, and the bits meaning is completely
different with the REG_MMU_STANDARD_AXI_MODE.
This patch moves this property to plat_data, it's also a preparing
patch for mt8183.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Evan Green <evgreen@chromium.org>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
The protect memory setting is a little different in the different SoCs.
In the register REG_MMU_CTRL_REG(0x110), the TF_PROT(translation fault
protect) shift bit is normally 4 while it shift 5 bits only in the
mt8173. This patch delete the complex MACRO and use a common if-else
instead.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Evan Green <evgreen@chromium.org>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
The larb-id may be remapped in the smi-common, this means the
larb-id reported in the mtk_iommu_isr isn't the real larb-id,
Take mt8183 as a example:
M4U
|
---------------------------------------------
| SMI common |
-0-----7-----5-----6-----1-----2------3-----4- <- Id remapped
| | | | | | | |
larb0 larb1 IPU0 IPU1 larb4 larb5 larb6 CCU
disp vdec img cam venc img cam
As above, larb0 connects with the id 0 in smi-common.
larb1 connects with the id 7 in smi-common.
...
If the larb-id reported in the isr is 7, actually it's larb1(vdec).
In order to output the right larb-id in the isr, we add a larb-id
remapping relationship in this patch.
If there is no this larb-id remapping in some SoCs, use the linear
mapping array instead.
This also is a preparing patch for mt8183.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Evan Green <evgreen@chromium.org>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
In some SoCs, M4U doesn't have its "bclk", it will use the EMI
clock instead which has always been enabled when entering kernel.
Currently mt2712 and mt8173 have this bclk while mt8183 doesn't.
This also is a preparing patch for mt8183.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Evan Green <evgreen@chromium.org>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
After extending the v7s support PA[33:32] for MediaTek, we have to adjust
the PA ourself for the 4GB mode.
In the 4GB Mode, the PA will remap like this:
CPU PA -> M4U output PA
0x4000_0000 0x1_4000_0000 (Add bit32)
0x8000_0000 0x1_8000_0000 ...
0xc000_0000 0x1_c000_0000 ...
0x1_0000_0000 0x1_0000_0000 (No change)
1) Always add bit32 for CPU PA in ->map.
2) Discard the bit32 in iova_to_phys if PA > 0x1_4000_0000 since the
iommu consumer always use the CPU PA.
Besides, the "oas" always is set to 34 since v7s has already supported our
case.
Both mt2712 and mt8173 support this "4GB mode" while the mt8183 don't.
The PA in mt8183 won't remap.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
MediaTek extend the arm v7s descriptor to support up to 34 bits PA where
the bit32 and bit33 are encoded in the bit9 and bit4 of the PTE
respectively. Meanwhile the iova still is 32bits.
Regarding whether the pagetable address could be over 4GB, the mt8183
support it while the previous mt8173 don't, thus keep it as is.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Acked-by: Will Deacon <will@kernel.org>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
In previous mt2712/mt8173, MediaTek extend the v7s to support 4GB dram.
But in the latest mt8183, We extend it to support the PA up to 34bit.
Then the "MTK_4GB" name is not so fit, This patch only change the quirk
name to "MTK_EXT".
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Acked-by: Will Deacon <will@kernel.org>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Use ias/oas to check the valid iova/pa. Synchronize this checking with
io-pgtable-arm.c.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Acked-by: Will Deacon <will@kernel.org>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
In M4U 4GB mode, the physical address is remapped as below:
CPU Physical address:
====================
0 1G 2G 3G 4G 5G
|---A---|---B---|---C---|---D---|---E---|
+--I/O--+------------Memory-------------+
IOMMU output physical address:
=============================
4G 5G 6G 7G 8G
|---E---|---B---|---C---|---D---|
+------------Memory-------------+
The Region 'A'(I/O) can not be mapped by M4U; For Region 'B'/'C'/'D', the
bit32 of the CPU physical address always is needed to set, and for Region
'E', the CPU physical address keep as is. something looks like this:
CPU PA -> M4U OUTPUT PA
0x4000_0000 0x1_4000_0000 (Add bit32)
0x8000_0000 0x1_8000_0000 ...
0xc000_0000 0x1_c000_0000 ...
0x1_0000_0000 0x1_0000_0000 (No change)
Additionally, the iommu consumers always use the CPU phyiscal address.
The PA in the iova_to_phys that is got from v7s always is u32, But
from the CPU point of view, PA only need add BIT(32) when PA < 0x4000_0000.
Fixes: 30e2fccf95 ("iommu/mediatek: Enlarge the validate PA range
for 4GB mode")
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Use a struct as the platform special data instead of the enumeration.
Also there is a minor change that moving the position of
"enum mtk_smi_gen" definition, this is because we expect define
"struct mtk_smi_common_plat" before it is referred.
This is a preparing patch for mt8183.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Reviewed-by: Evan Green <evgreen@chromium.org>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
The config_port of mt2712 and mt8183 are the same. Use a general
config_port interface instead.
In addition, in mt2712, larb8 and larb9 are the bdpsys larbs which
are not the normal larb, their register space are different from the
normal one. thus, we can not call the general config_port. In mt8183,
IPU0/1 and CCU connect with smi-common directly, they also are not
the normal larb. Hence, we add a "larb_direct_to_common_mask" for these
larbs which connect to smi-commmon directly.
This is also a preparing patch for adding mt8183 SMI support.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Reviewed-by: Evan Green <evgreen@chromium.org>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Use a struct as the platform special data instead of the enumeration.
This is a prepare patch for adding mt8183 iommu support.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Reviewed-by: Evan Green <evgreen@chromium.org>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
This patch adds decriptions for mt8183 IOMMU and SMI.
mt8183 has only one M4U like mt8173 and is also MTK IOMMU gen2 which
uses ARM Short-Descriptor translation table format.
The mt8183 M4U-SMI HW diagram is as below:
EMI
|
M4U
|
----------
| |
gals0-rx gals1-rx
| |
| |
gals0-tx gals1-tx
| |
------------
SMI Common
------------
|
+-----+-----+--------+-----+-----+-------+-------+
| | | | | | | |
| | gals-rx gals-rx | gals-rx gals-rx gals-rx
| | | | | | | |
| | | | | | | |
| | gals-tx gals-tx | gals-tx gals-tx gals-tx
| | | | | | | |
larb0 larb1 IPU0 IPU1 larb4 larb5 larb6 CCU
disp vdec img cam venc img cam
All the connections are HW fixed, SW can NOT adjust it.
Compared with mt8173, we add a GALS(Global Async Local Sync) module
between SMI-common and M4U, and additional GALS between larb2/3/5/6
and SMI-common. GALS can help synchronize for the modules in different
clock frequency, it can be seen as a "asynchronous fifo".
GALS can only help transfer the command/data while it doesn't have
the configuring register, thus it has the special "smi" clock and it
doesn't have the "apb" clock. From the diagram above, we add "gals0"
and "gals1" clocks for smi-common and add a "gals" clock for smi-larb.
>From the diagram above, IPU0/IPU1(Image Processor Unit) and CCU(Camera
Control Unit) is connected with smi-common directly, we can take them
as "larb2", "larb3" and "larb7", and their register spaces are
different with the normal larb.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Evan Green <evgreen@chromium.org>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Current implementation is recursive and in case of allocation
failure the existing @regions list is altered. A non recursive
version looks better for maintainability and simplifies the
error handling. We use a separate stack for overlapping segment
merging. The elements are sorted by start address and then by
type, if their start address match.
Note this new implementation may change the region order of
appearance in /sys/kernel/iommu_groups/<n>/reserved_regions
files but this order has never been documented, see
commit bc7d12b91b ("iommu: Implement reserved_regions
iommu-group sysfs file").
Signed-off-by: Eric Auger <eric.auger@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
set_msi_sid_cb() is used to determine whether device aliases share the
same bus, but it can provide false indications that aliases use the same
bus when in fact they do not. The reason is that set_msi_sid_cb()
assumes that pdev is fixed, while actually pci_for_each_dma_alias() can
call fn() when pdev is set to a subordinate device.
As a result, running an VM on ESX with VT-d emulation enabled can
results in the log warning such as:
DMAR: [INTR-REMAP] Request device [00:11.0] fault index 3b [fault reason 38] Blocked an interrupt request due to source-id verification failure
This seems to cause additional ata errors such as:
ata3.00: qc timeout (cmd 0xa1)
ata3.00: failed to IDENTIFY (I/O error, err_mask=0x4)
These timeouts also cause boot to be much longer and other errors.
Fix it by checking comparing the alias with the previous one instead.
Fixes: 3f0c625c6a ("iommu/vt-d: Allow interrupts from the entire bus for aliased devices")
Cc: stable@vger.kernel.org
Cc: Logan Gunthorpe <logang@deltatee.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
Signed-off-by: Nadav Amit <namit@vmware.com>
Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
- two patches fixing a regression in the pca953x driver
-----BEGIN PGP SIGNATURE-----
iQIxBAABCAAdFiEEFp3rbAvDxGAT0sefEacuoBRx13IFAl1o1kYACgkQEacuoBRx
13Iyng/veISNldGEnLRalWG4bZWVamCdwMpd/x3Xa/TJkfjkae2hA2616ybjcy/P
5LztWRVTuwBDBUtUnhsPFtWoJ4LFEhPPgSgr6ZkcbObVB+4ppt8JqAWt8nDKVakJ
Yjl5nhXKvaE9bPWZAGXWxng+4kvomyF36XC26Tf7bP3zzYVZnmSIoWeVjG9iQBsm
7vTrpC0ptjL0WzJPHKlb77qOYJgugMF8oG3CckAqcIrUHT2wFL3pOEmECik0eyEH
DTde5H+J+Srb1HSSb3E8QInjCPfSEcBN0DndaB5sKuWIcYg3vYqKaho+5Gjpudoa
bcxF7uDLg84Pg+0ksnLUl1AhCqyAzfj57+OIogOOqe4Yq2Ma431K1te19Ijh6fZ8
XQDtvNsWsld3lZM9SAq+Mhq5J3fQUG09FvxDDMN//g0yK9Mf4HmmMej+uczD1a/g
0ppaijslVdFOhOMamyiNirasKVmPkJ45kKta0xTaf/1g2MQFNhmOmQxByYHDvBwt
VK8gli8q3FjM/69QIIQ7WNqlkQubClPs2r4ROv269Nog5eBK1ckA0lGnkC0TjXCC
stiZAw/lBl0QzhGax7cM7zJbw9yozkaMb4BlEA6mBD56YSBdOB80o5cLI1p69f/S
wSUdQLj7YXxPrDkIjGnFeavEXgOdR5Pp6BIg315yFrinMnLf
=EARz
-----END PGP SIGNATURE-----
Merge tag 'gpio-v5.3-rc7-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux into fixes
gpio fixes for v5.3-rc7
- two patches fixing a regression in the pca953x driver
In commit 14bd9a607f ("iommu/iova: Separate atomic variables
to improve performance") Jinyu Qi identified that the atomic_cmpxchg()
in queue_iova() was causing a performance loss and moved critical fields
so that the false sharing would not impact them.
However, avoiding the false sharing in the first place seems easy.
We should attempt the atomic_cmpxchg() no more than 100 times
per second. Adding an atomic_read() will keep the cache
line mostly shared.
This false sharing came with commit 9a005a800a
("iommu/iova: Add flush timer").
Signed-off-by: Eric Dumazet <edumazet@google.com>
Fixes: 9a005a800a ('iommu/iova: Add flush timer')
Cc: Jinyu Qi <jinyuqi@huawei.com>
Cc: Joerg Roedel <jroedel@suse.de>
Acked-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Quoting from mt8183 datasheet, the number of transfers to be
transferred in one transaction should be set to bigger than 1,
so we should forbid zero-length transfer and update functionality.
Reported-by: Alexandru M Stan <amstan@chromium.org>
Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Reviewed-by: Qii Wang <qii.wang@mediatek.com>
[wsa: shortened commit message a little]
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
The driver does not support the SMBUS Quick command so remove the
flag that indicates that level of support.
By default the i2c_detect tool uses the quick command to try and
detect devices at some bus addresses. If the quick command is used
then we will not detect the device, even though it is present.
Fixes: e6e5dd3566 (i2c: iproc: Add Broadcom iProc I2C Driver)
Signed-off-by: Lori Hikichi <lori.hikichi@broadcom.com>
Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
Reviewed-by: Ray Jui <ray.jui@broadcom.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
David S. Miller