Skip to content

Commit 28ab1bb

Browse files
jgunthorpejgunthorpe
committed
Merge tag 'v4.20-rc6' into rdma.git for-next
For dependencies in following patches.
2 parents b874155 + 40e020c commit 28ab1bb

File tree

1,305 files changed

+15702
-7795
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

1,305 files changed

+15702
-7795
lines changed

‎.mailmap

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -159,6 +159,7 @@ Peter Oruba <peter@oruba.de>
159159
Peter Oruba <peter.oruba@amd.com>
160160
Pratyush Anand <pratyush.anand@gmail.com> <pratyush.anand@st.com>
161161
Praveen BP <praveenbp@ti.com>
162+
Punit Agrawal <punitagrawal@gmail.com> <punit.agrawal@arm.com>
162163
Qais Yousef <qsyousef@gmail.com> <qais.yousef@imgtec.com>
163164
Oleksij Rempel <linux@rempel-privat.de> <bug-track@fisher-privat.net>
164165
Oleksij Rempel <linux@rempel-privat.de> <external.Oleksij.Rempel@de.bosch.com>

‎CREDITS

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -2138,6 +2138,10 @@ E: paul@laufernet.com
21382138
D: Soundblaster driver fixes, ISAPnP quirk
21392139
S: California, USA
21402140

2141+
N: Jarkko Lavinen
2142+
E: jarkko.lavinen@nokia.com
2143+
D: OMAP MMC support
2144+
21412145
N: Jonathan Layes
21422146
D: ARPD support
21432147

@@ -2200,6 +2204,10 @@ S: Post Office Box 371
22002204
S: North Little Rock, Arkansas 72115
22012205
S: USA
22022206

2207+
N: Christopher Li
2208+
E: sparse@chrisli.org
2209+
D: Sparse maintainer 2009 - 2018
2210+
22032211
N: Stephan Linz
22042212
E: linz@mazet.de
22052213
E: Stephan.Linz@gmx.de

‎Documentation/ABI/testing/sysfs-class-led-trigger-pattern

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -37,8 +37,8 @@ Description:
3737
0-| / \/ \/
3838
+---0----1----2----3----4----5----6------------> time (s)
3939

40-
2. To make the LED go instantly from one brigntess value to another,
41-
we should use use zero-time lengths (the brightness must be same as
40+
2. To make the LED go instantly from one brightness value to another,
41+
we should use zero-time lengths (the brightness must be same as
4242
the previous tuple's). So the format should be:
4343
"brightness_1 duration_1 brightness_1 0 brightness_2 duration_2
4444
brightness_2 0 ...". For example:

‎Documentation/ABI/testing/sysfs-class-net-dsa

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
What: /sys/class/net/<iface>/tagging
1+
What: /sys/class/net/<iface>/dsa/tagging
22
Date: August 2018
33
KernelVersion: 4.20
44
Contact: netdev@vger.kernel.org

‎Documentation/admin-guide/kernel-parameters.txt

Lines changed: 62 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -856,7 +856,8 @@
856856
causing system reset or hang due to sending
857857
INIT from AP to BSP.
858858

859-
disable_counter_freezing [HW]
859+
perf_v4_pmi= [X86,INTEL]
860+
Format: <bool>
860861
Disable Intel PMU counter freezing feature.
861862
The feature only exists starting from
862863
Arch Perfmon v4 (Skylake and newer).
@@ -3504,6 +3505,10 @@
35043505
before loading.
35053506
See Documentation/blockdev/ramdisk.txt.
35063507

3508+
psi= [KNL] Enable or disable pressure stall information
3509+
tracking.
3510+
Format: <bool>
3511+
35073512
psmouse.proto= [HW,MOUSE] Highest PS2 mouse protocol extension to
35083513
probe for; one of (bare|imps|exps|lifebook|any).
35093514
psmouse.rate= [HW,MOUSE] Set desired mouse report rate, in reports
@@ -4194,9 +4199,13 @@
41944199

41954200
spectre_v2= [X86] Control mitigation of Spectre variant 2
41964201
(indirect branch speculation) vulnerability.
4202+
The default operation protects the kernel from
4203+
user space attacks.
41974204

4198-
on - unconditionally enable
4199-
off - unconditionally disable
4205+
on - unconditionally enable, implies
4206+
spectre_v2_user=on
4207+
off - unconditionally disable, implies
4208+
spectre_v2_user=off
42004209
auto - kernel detects whether your CPU model is
42014210
vulnerable
42024211

@@ -4206,6 +4215,12 @@
42064215
CONFIG_RETPOLINE configuration option, and the
42074216
compiler with which the kernel was built.
42084217

4218+
Selecting 'on' will also enable the mitigation
4219+
against user space to user space task attacks.
4220+
4221+
Selecting 'off' will disable both the kernel and
4222+
the user space protections.
4223+
42094224
Specific mitigations can also be selected manually:
42104225

42114226
retpoline - replace indirect branches
@@ -4215,6 +4230,48 @@
42154230
Not specifying this option is equivalent to
42164231
spectre_v2=auto.
42174232

4233+
spectre_v2_user=
4234+
[X86] Control mitigation of Spectre variant 2
4235+
(indirect branch speculation) vulnerability between
4236+
user space tasks
4237+
4238+
on - Unconditionally enable mitigations. Is
4239+
enforced by spectre_v2=on
4240+
4241+
off - Unconditionally disable mitigations. Is
4242+
enforced by spectre_v2=off
4243+
4244+
prctl - Indirect branch speculation is enabled,
4245+
but mitigation can be enabled via prctl
4246+
per thread. The mitigation control state
4247+
is inherited on fork.
4248+
4249+
prctl,ibpb
4250+
- Like "prctl" above, but only STIBP is
4251+
controlled per thread. IBPB is issued
4252+
always when switching between different user
4253+
space processes.
4254+
4255+
seccomp
4256+
- Same as "prctl" above, but all seccomp
4257+
threads will enable the mitigation unless
4258+
they explicitly opt out.
4259+
4260+
seccomp,ibpb
4261+
- Like "seccomp" above, but only STIBP is
4262+
controlled per thread. IBPB is issued
4263+
always when switching between different
4264+
user space processes.
4265+
4266+
auto - Kernel selects the mitigation depending on
4267+
the available CPU features and vulnerability.
4268+
4269+
Default mitigation:
4270+
If CONFIG_SECCOMP=y then "seccomp", otherwise "prctl"
4271+
4272+
Not specifying this option is equivalent to
4273+
spectre_v2_user=auto.
4274+
42184275
spec_store_bypass_disable=
42194276
[HW] Control Speculative Store Bypass (SSB) Disable mitigation
42204277
(Speculative Store Bypass vulnerability)
@@ -4713,6 +4770,8 @@
47134770
prevent spurious wakeup);
47144771
n = USB_QUIRK_DELAY_CTRL_MSG (Device needs a
47154772
pause after every control message);
4773+
o = USB_QUIRK_HUB_SLOW_RESET (Hub needs extra
4774+
delay after resetting its port);
47164775
Example: quirks=0781:5580:bk,0a5c:5834:gij
47174776

47184777
usbhid.mousepoll=

‎Documentation/admin-guide/pm/cpufreq.rst

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -150,7 +150,7 @@ data structures necessary to handle the given policy and, possibly, to add
150150
a governor ``sysfs`` interface to it. Next, the governor is started by
151151
invoking its ``->start()`` callback.
152152

153-
That callback it expected to register per-CPU utilization update callbacks for
153+
That callback is expected to register per-CPU utilization update callbacks for
154154
all of the online CPUs belonging to the given policy with the CPU scheduler.
155155
The utilization update callbacks will be invoked by the CPU scheduler on
156156
important events, like task enqueue and dequeue, on every iteration of the

‎Documentation/admin-guide/security-bugs.rst

Lines changed: 11 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -32,16 +32,17 @@ Disclosure and embargoed information
3232
The security list is not a disclosure channel. For that, see Coordination
3333
below.
3434

35-
Once a robust fix has been developed, our preference is to release the
36-
fix in a timely fashion, treating it no differently than any of the other
37-
thousands of changes and fixes the Linux kernel project releases every
38-
month.
39-
40-
However, at the request of the reporter, we will postpone releasing the
41-
fix for up to 5 business days after the date of the report or after the
42-
embargo has lifted; whichever comes first. The only exception to that
43-
rule is if the bug is publicly known, in which case the preference is to
44-
release the fix as soon as it's available.
35+
Once a robust fix has been developed, the release process starts. Fixes
36+
for publicly known bugs are released immediately.
37+
38+
Although our preference is to release fixes for publicly undisclosed bugs
39+
as soon as they become available, this may be postponed at the request of
40+
the reporter or an affected party for up to 7 calendar days from the start
41+
of the release process, with an exceptional extension to 14 calendar days
42+
if it is agreed that the criticality of the bug requires more time. The
43+
only valid reason for deferring the publication of a fix is to accommodate
44+
the logistics of QA and large scale rollouts which require release
45+
coordination.
4546

4647
Whilst embargoed information may be shared with trusted individuals in
4748
order to develop a fix, such information will not be published alongside

‎Documentation/arm64/silicon-errata.txt

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -57,6 +57,7 @@ stable kernels.
5757
| ARM | Cortex-A73 | #858921 | ARM64_ERRATUM_858921 |
5858
| ARM | Cortex-A55 | #1024718 | ARM64_ERRATUM_1024718 |
5959
| ARM | Cortex-A76 | #1188873 | ARM64_ERRATUM_1188873 |
60+
| ARM | Cortex-A76 | #1286807 | ARM64_ERRATUM_1286807 |
6061
| ARM | MMU-500 | #841119,#826419 | N/A |
6162
| | | | |
6263
| Cavium | ThunderX ITS | #22375, #24313 | CAVIUM_ERRATUM_22375 |

‎Documentation/core-api/xarray.rst

Lines changed: 41 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -74,7 +74,8 @@ using :c:func:`xa_load`. xa_store will overwrite any entry with the
7474
new entry and return the previous entry stored at that index. You can
7575
use :c:func:`xa_erase` instead of calling :c:func:`xa_store` with a
7676
``NULL`` entry. There is no difference between an entry that has never
77-
been stored to and one that has most recently had ``NULL`` stored to it.
77+
been stored to, one that has been erased and one that has most recently
78+
had ``NULL`` stored to it.
7879

7980
You can conditionally replace an entry at an index by using
8081
:c:func:`xa_cmpxchg`. Like :c:func:`cmpxchg`, it will only succeed if
@@ -105,23 +106,44 @@ may result in the entry being marked at some, but not all of the other
105106
indices. Storing into one index may result in the entry retrieved by
106107
some, but not all of the other indices changing.
107108

109+
Sometimes you need to ensure that a subsequent call to :c:func:`xa_store`
110+
will not need to allocate memory. The :c:func:`xa_reserve` function
111+
will store a reserved entry at the indicated index. Users of the normal
112+
API will see this entry as containing ``NULL``. If you do not need to
113+
use the reserved entry, you can call :c:func:`xa_release` to remove the
114+
unused entry. If another user has stored to the entry in the meantime,
115+
:c:func:`xa_release` will do nothing; if instead you want the entry to
116+
become ``NULL``, you should use :c:func:`xa_erase`.
117+
118+
If all entries in the array are ``NULL``, the :c:func:`xa_empty` function
119+
will return ``true``.
120+
108121
Finally, you can remove all entries from an XArray by calling
109122
:c:func:`xa_destroy`. If the XArray entries are pointers, you may wish
110123
to free the entries first. You can do this by iterating over all present
111124
entries in the XArray using the :c:func:`xa_for_each` iterator.
112125

113-
ID assignment
114-
-------------
126+
Allocating XArrays
127+
------------------
128+
129+
If you use :c:func:`DEFINE_XARRAY_ALLOC` to define the XArray, or
130+
initialise it by passing ``XA_FLAGS_ALLOC`` to :c:func:`xa_init_flags`,
131+
the XArray changes to track whether entries are in use or not.
115132

116133
You can call :c:func:`xa_alloc` to store the entry at any unused index
117134
in the XArray. If you need to modify the array from interrupt context,
118135
you can use :c:func:`xa_alloc_bh` or :c:func:`xa_alloc_irq` to disable
119-
interrupts while allocating the ID. Unlike :c:func:`xa_store`, allocating
120-
a ``NULL`` pointer does not delete an entry. Instead it reserves an
121-
entry like :c:func:`xa_reserve` and you can release it using either
122-
:c:func:`xa_erase` or :c:func:`xa_release`. To use ID assignment, the
123-
XArray must be defined with :c:func:`DEFINE_XARRAY_ALLOC`, or initialised
124-
by passing ``XA_FLAGS_ALLOC`` to :c:func:`xa_init_flags`,
136+
interrupts while allocating the ID.
137+
138+
Using :c:func:`xa_store`, :c:func:`xa_cmpxchg` or :c:func:`xa_insert`
139+
will mark the entry as being allocated. Unlike a normal XArray, storing
140+
``NULL`` will mark the entry as being in use, like :c:func:`xa_reserve`.
141+
To free an entry, use :c:func:`xa_erase` (or :c:func:`xa_release` if
142+
you only want to free the entry if it's ``NULL``).
143+
144+
You cannot use ``XA_MARK_0`` with an allocating XArray as this mark
145+
is used to track whether an entry is free or not. The other marks are
146+
available for your use.
125147

126148
Memory allocation
127149
-----------------
@@ -158,6 +180,8 @@ Takes RCU read lock:
158180

159181
Takes xa_lock internally:
160182
* :c:func:`xa_store`
183+
* :c:func:`xa_store_bh`
184+
* :c:func:`xa_store_irq`
161185
* :c:func:`xa_insert`
162186
* :c:func:`xa_erase`
163187
* :c:func:`xa_erase_bh`
@@ -167,6 +191,9 @@ Takes xa_lock internally:
167191
* :c:func:`xa_alloc`
168192
* :c:func:`xa_alloc_bh`
169193
* :c:func:`xa_alloc_irq`
194+
* :c:func:`xa_reserve`
195+
* :c:func:`xa_reserve_bh`
196+
* :c:func:`xa_reserve_irq`
170197
* :c:func:`xa_destroy`
171198
* :c:func:`xa_set_mark`
172199
* :c:func:`xa_clear_mark`
@@ -177,6 +204,7 @@ Assumes xa_lock held on entry:
177204
* :c:func:`__xa_erase`
178205
* :c:func:`__xa_cmpxchg`
179206
* :c:func:`__xa_alloc`
207+
* :c:func:`__xa_reserve`
180208
* :c:func:`__xa_set_mark`
181209
* :c:func:`__xa_clear_mark`
182210

@@ -234,7 +262,8 @@ Sharing the XArray with interrupt context is also possible, either
234262
using :c:func:`xa_lock_irqsave` in both the interrupt handler and process
235263
context, or :c:func:`xa_lock_irq` in process context and :c:func:`xa_lock`
236264
in the interrupt handler. Some of the more common patterns have helper
237-
functions such as :c:func:`xa_erase_bh` and :c:func:`xa_erase_irq`.
265+
functions such as :c:func:`xa_store_bh`, :c:func:`xa_store_irq`,
266+
:c:func:`xa_erase_bh` and :c:func:`xa_erase_irq`.
238267

239268
Sometimes you need to protect access to the XArray with a mutex because
240269
that lock sits above another mutex in the locking hierarchy. That does
@@ -322,7 +351,8 @@ to :c:func:`xas_retry`, and retry the operation if it returns ``true``.
322351
- :c:func:`xa_is_zero`
323352
- Zero entries appear as ``NULL`` through the Normal API, but occupy
324353
an entry in the XArray which can be used to reserve the index for
325-
future use.
354+
future use. This is used by allocating XArrays for allocated entries
355+
which are ``NULL``.
326356

327357
Other internal entries may be added in the future. As far as possible, they
328358
will be handled by :c:func:`xas_retry`.

‎Documentation/cpu-freq/cpufreq-stats.txt

Lines changed: 5 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -86,9 +86,11 @@ transitions.
8686
This will give a fine grained information about all the CPU frequency
8787
transitions. The cat output here is a two dimensional matrix, where an entry
8888
<i,j> (row i, column j) represents the count of number of transitions from
89-
Freq_i to Freq_j. Freq_i is in descending order with increasing rows and
90-
Freq_j is in descending order with increasing columns. The output here also
91-
contains the actual freq values for each row and column for better readability.
89+
Freq_i to Freq_j. Freq_i rows and Freq_j columns follow the sorting order in
90+
which the driver has provided the frequency table initially to the cpufreq core
91+
and so can be sorted (ascending or descending) or unsorted. The output here
92+
also contains the actual freq values for each row and column for better
93+
readability.
9294

9395
If the transition table is bigger than PAGE_SIZE, reading this will
9496
return an -EFBIG error.

‎Documentation/devicetree/bindings/arm/shmobile.txt

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -27,7 +27,7 @@ SoCs:
2727
compatible = "renesas,r8a77470"
2828
- RZ/G2M (R8A774A1)
2929
compatible = "renesas,r8a774a1"
30-
- RZ/G2E (RA8774C0)
30+
- RZ/G2E (R8A774C0)
3131
compatible = "renesas,r8a774c0"
3232
- R-Car M1A (R8A77781)
3333
compatible = "renesas,r8a7778"

‎Documentation/devicetree/bindings/clock/clock-bindings.txt

Lines changed: 16 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -168,3 +168,19 @@ a shared clock is forbidden.
168168

169169
Configuration of common clocks, which affect multiple consumer devices can
170170
be similarly specified in the clock provider node.
171+
172+
==Protected clocks==
173+
174+
Some platforms or firmwares may not fully expose all the clocks to the OS, such
175+
as in situations where those clks are used by drivers running in ARM secure
176+
execution levels. Such a configuration can be specified in device tree with the
177+
protected-clocks property in the form of a clock specifier list. This property should
178+
only be specified in the node that is providing the clocks being protected:
179+
180+
clock-controller@a000f000 {
181+
compatible = "vendor,clk95;
182+
reg = <0xa000f000 0x1000>
183+
#clocks-cells = <1>;
184+
...
185+
protected-clocks = <UART3_CLK>, <SPI5_CLK>;
186+
};

0 commit comments

Comments
 (0)