On Fri, 16 Feb 2018, Akira Yokosawa wrote:
> So, I attempted to rebase the patch to current (somewhat old) master of
> https://github.com/aparri/memory-model. Why? Because the lkmm branch
> in Paul's -rcu tree doesn't have linux-kernel-hardware.cat.
>
> However, after this change, Z6.0+pooncelock
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Will Deacon
Commit 376133b7edc2 upstream.
We're about to rework the way ASIDs are allocated, switch_mm is
implemented and low-level kernel entry/exit is handled, so keep the
ARM64_SW_TTBR0_PA
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Will Deacon
Commit 85d13c001497 upstream.
The pre_ttbr0_update_workaround hook is called prior to context-switching
TTBR0 because Falkor erratum E1003 can cause TLB allocation with the wrong
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Will Deacon
Commit 7655abb95386 upstream.
In preparation for mapping kernelspace and userspace with different
ASIDs, move the ASID to TTBR1 and update switch_mm to context-switch
TTBR0 via an
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Will Deacon
Commit 158d495899ce upstream.
The post_ttbr0_update_workaround hook applies to any change to TTBRx_EL1.
Since we're using TTBR1 for the ASID, rename the hook to make it clearer
as
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Rasmus Villemoes
commit bc137dfdbec27c0ec5731a89002daded4a4aa1ea upstream.
The first patch above (https://patchwork.kernel.org/patch/9970181/)
makes the oops go away, but it just papers over t
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Will Deacon
Commit 0c8ea531b774 upstream.
In preparation for separate kernel/user ASIDs, allocate them in pairs
for each mm_struct. The bottom bit distinguishes the two: if it is set,
then th
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Will Deacon
Commit 27a921e75711 upstream.
With the ASID now installed in TTBR1, we can re-enable ARM64_SW_TTBR0_PAN
by ensuring that we switch to a reserved ASID of zero when disabling
user a
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Will Deacon
Commit c7b9adaf85f8 upstream.
To allow unmapping of the kernel whilst running at EL0, we need to
point the exception vectors at an entry trampoline that can map/unmap
the kernel o
On 02/15/2018 07:43 AM, Christopher Diaz Riveros wrote:
> Trivial clean up making comments fit in 80 columns and keeping the same
> comment style.
Why change the /** (indicates kernel-doc notation) to just /* ?
Is scripts/kernel-doc complaining with warnings or errors?
> Signed-off-by: Christ
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Will Deacon
Commit 5b1f7fe41909 upstream.
We will need to treat exceptions from EL0 differently in kernel_ventry,
so rework the macro to take the exception level as an argument and
construct
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Will Deacon
Commit 51a0048beb44 upstream.
The exception entry trampoline needs to be mapped at the same virtual
address in both the trampoline page table (which maps nothing else)
and also th
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Will Deacon
Commit d1777e686ad1 upstream.
We rely on an atomic swizzling of TTBR1 when transitioning from the entry
trampoline to the kernel proper on an exception. We can't rely on this
atom
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Stephen Boyd
Commit bb48711800e6 upstream.
The Kryo CPUs are also affected by the Falkor 1003 errata, so
we need to do the same workaround on Kryo CPUs. The MIDR is
slightly more complicated
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Will Deacon
Commit 18011eac28c7 upstream.
When unmapping the kernel at EL0, we use tpidrro_el0 as a scratch register
during exception entry from native tasks and subsequently zero it in
the k
On Tue, Feb 13, 2018 at 10:45:49AM +0100, Jacopo Mondi wrote:
> Initial support for R-Car M3-N (r8a77965), including core and module
> clocks.
>
> Signed-off-by: Jacopo Mondi
> ---
> .../devicetree/bindings/clock/renesas,cpg-mssr.txt | 1 +
> drivers/clk/renesas/Kconfig
Dave Hansen wrote:
>> diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
>> index c67ef3fb4f35..979c7ec6baab 100644
>> --- a/arch/x86/mm/tlb.c
>> +++ b/arch/x86/mm/tlb.c
>> @@ -74,7 +74,8 @@ static void choose_new_asid(struct mm_struct *next, u64
>> next_tlb_gen,
>> return;
>>
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Will Deacon
Commit 6c27c4082f4f upstream.
The literal pool entry for identifying the vectors base is the only piece
of information in the trampoline page that identifies the true location
of
On Thu, Feb 15, 2018 at 5:20 AM, Dave Hansen
wrote:
>
> During the switch over to PTI, we seem to have lost our ability to have
> GLOBAL mappings.
Oops. Odd, I have this distinct memory of somebody even _testing_ the
global bit performance when I pointed out that we shouldn't just make
the bit go
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Will Deacon
Commit ea1e3de85e94 upstream.
Allow explicit disabling of the entry trampoline on the kernel command
line (kpti=off) by adding a fake CPU feature (ARM64_UNMAP_KERNEL_AT_EL0)
that
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Will Deacon
Commit be04a6d1126b upstream.
Speculation attacks against the entry trampoline can potentially resteer
the speculative instruction stream through the indirect branch and into
arbi
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Will Deacon
Commit 0617052ddde3 upstream.
Although CONFIG_UNMAP_KERNEL_AT_EL0 does make KASLR more robust, it's
actually more useful as a mitigation against speculation attacks that
can leak
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Suzuki K Poulose
Commit 67948af41f2e upstream.
Sometimes a single capability could be listed multiple times with
differing matches(), e.g, CPU errata for different MIDR versions.
This breaks
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Shanker Donthineni
commit 932b50c7c1c65e6f23002e075b97ee083c4a9e71 upstream.
The ARM architecture defines the memory locations that are permitted
to be accessed as the result of a speculative
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Haozhong Zhang
commit 2a266f23550be997d783f27e704b9b40c4010292 upstream.
For example, when two APF's for page ready happen after one exit and
the first one becomes pending, the second one will
On Thu, Feb 15, 2018 at 12:17:04AM +0100, Ingo Molnar wrote:
>
> * Jerry Hoemann wrote:
>
> >
> > Ingo,
> >
> > I have a patch set under review that brings hpwdt into compliance
> > with the watchdog core.
> >
> > One of the changes removes the callback into firmware in hpwdt_pretimeout
> > a
It seems this is a copy-paste error and that the proper variable to use
in this particular case is _src_ instead of _dst_.
Addresses-Coverity-ID: 1465282 ("Copy-paste error")
Fixes: 0075fa0fadd0 ("i40evf: Add support to apply cloud filters")
Signed-off-by: Gustavo A. R. Silva
---
drivers/net/eth
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Yang Shunyong
commit 66b3bd2356e0a1531c71a3dcf96944621e25c17c upstream.
The type of arg passed to dmatest_callback is struct dmatest_done.
It refers to test_done in struct dmatest_thread, not
On Thu, Feb 15, 2018 at 9:16 AM, Hans Verkuil wrote:
> On 15/02/18 17:39, Tim Harvey wrote:
>> Add support for the TDA1997x HDMI receivers.
>>
>> Cc: Hans Verkuil
>> Signed-off-by: Tim Harvey
>> ---
>> v12:
>> - fix coccinelle warnings
>
> Did you post the right version? I still see the owner b
On Thu, 2018-02-15 at 09:24 -0800, Eric Dumazet wrote:
>
> I will send something more suited to original intent of these commits :
>
> 90e33d45940793def6f773b2d528e9f3c84ffdc7 tun: enable napi_gro_frags()
> for TUN/TAP driver
> 943170998b200190f99d3fe7e771437e2c51f319 tun: enable NAPI for TUN/TAP
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Will Deacon
Commit 6314d90e6493 upstream.
In a similar manner to array_index_mask_nospec, this patch introduces an
assembly macro (mask_nospec64) which can be used to bound a value under
spec
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Robin Murphy
Commit 51369e398d0d upstream.
Currently, USER_DS represents an exclusive limit while KERNEL_DS is
inclusive. In order to do some clever trickery for speculation-safe
masking, we
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Will Deacon
Commit c2f0ad4fc089 upstream.
A mispredicted conditional call to set_fs could result in the wrong
addr_limit being forwarded under speculation to a subsequent access_ok
check, pot
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Will Deacon
Commit f71c2ffcb20d upstream.
Like we've done for get_user and put_user, ensure that user pointers
are masked before invoking the underlying __arch_{clear,copy_*}_user
operations.
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Suzuki K Poulose
Commit 55b35d070c25 upstream.
When a CPU is brought up after we have finalised the system
wide capabilities (i.e, features and errata), we make sure the
new CPU doesn't need
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Jayachandran C
Commit 0ba2e29c7fc1 upstream.
Whitelist Broadcom Vulcan/Cavium ThunderX2 processors in
unmap_kernel_at_el0(). These CPUs are not vulnerable to
CVE-2017-5754 and do not need KPT
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Will Deacon
Commit d68e3ba5303f upstream.
Entry into recent versions of ARM Trusted Firmware will invalidate the CPU
branch predictor state in order to protect against aliasing attacks.
This
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Marc Zyngier
Commit 95e3de3590e3 upstream.
We will soon need to invoke a CPU-specific function pointer after changing
page tables, so move post_ttbr_update_workaround out into C code to make
t
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Marc Zyngier
Commit 6840bdd73d07 upstream.
Now that we have per-CPU vectors, let's plug then in the KVM/arm64 code.
Signed-off-by: Marc Zyngier
Signed-off-by: Will Deacon
Signed-off-by: Ca
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Marc Zyngier
Commit a8e4c0a919ae upstream.
We call arm64_apply_bp_hardening() from post_ttbr_update_workaround,
which has the unexpected consequence of being triggered on every
exception retu
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Will Deacon
Commit 0f15adbb2861 upstream.
Aliasing attacks against CPU branch predictors can allow an attacker to
redirect speculative control flow on some CPUs and potentially divulge
inform
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Will Deacon
Commit 30d88c0e3ace upstream.
It is possible to take an IRQ from EL0 following a branch to a kernel
address in such a way that the IRQ is prioritised over the instruction
abort. W
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Will Deacon
Commit a65d219fe5dc upstream.
Hook up MIDR values for the Cortex-A72 and Cortex-A75 CPUs, since they
will soon need MIDR matches for hardening the branch predictor.
Signed-off-by
Sleep and wake requests are sent when the application processor
subsystem of the SoC is entering deep sleep states like in suspend.
These requests help lower the system power requirements when the
resources are not in use.
Sleep and wake requests are written to the TCS slots but are not
triggered
Sending RPMH requests and waiting for response from the controller
through a callback is common functionality across all platform drivers.
To simplify drivers, add a library functions to create RPMH client and
send resource state requests.
rpmh_write() is a synchronous blocking call that can be us
Add controller driver for QCOM SoCs that have hardware based shared
resource management. The hardware IP known as RSC (Resource State
Coordinator) houses multiple Direct Resource Voter (DRV) for different
execution levels. A DRV is a unique voter on the state of a shared
resource. A Trigger Control
Add device binding documentation for Qualcomm Technology Inc's RPMH RSC
driver. The hardware block is used for communicating resource state
requests for shared resources.
Cc: devicet...@vger.kernel.org
Signed-off-by: Lina Iyer
---
.../devicetree/bindings/arm/msm/rpmh-rsc.txt | 146
Acked-by: Steve Longerbeam
On 02/15/2018 01:25 AM, Parthiban Nallathambi wrote:
This is a cleanup patch to fix line length issue found
by checkpatch.pl script.
In this patch, line 144 have been wrapped.
Signed-off-by: Parthiban Nallathambi
---
Changes in v2:
- Changed commit message
driv
On Mon, Feb 12, 2018 at 12:15:03PM -0800,
sathyanarayan.kuppusw...@linux.intel.com wrote:
> From: Dominik Bozek
>
> ACM driver may accept data to transmit while system is not fully
> resumed. In this case ACM driver buffers data and prepare URBs
> on usb anchor list.
> There is a little chance t
Active state requests are sent immediately to the mailbox controller,
while sleep and wake state requests are cached in this driver to avoid
taxing the mailbox controller repeatedly. The cached values will be sent
to the controller when the rpmh_flush() is called.
Generally, flushing is a system P
On Wed, Feb 14, 2018 at 07:40:50PM -0800, Matthew Wilcox wrote:
> > a_foo = kvzalloc_struct_buf(struct foo, struct bar, nr_bars);
> >
> > or, of course.
> >
> > a_foo = kvzalloc_struct_buf(typeof(*a_foo), typeof(a_foo->bar[0]),
> > nr_bars);
> >
> > or wha
Platform drivers that want to send a request but do not want to block
until the RPMH request completes have now a new API -
rpmh_write_async().
The API allocates memory and send the requests and returns the control
back to the platform driver. The tx_done callback from the controller is
handled in
Dave Hansen wrote:
> On 02/15/2018 08:36 AM, Nadav Amit wrote:
>> As long as PTI is disabled, it is possible to use global pages, as long
>> as we remove them once PTI is enabled again. To do so, return the global
>> bit to __supported_pte_mask and disable global pages using CR4.
>>
>> Signed-of
Log sent RPMH requests and interrupt responses in FTRACE.
Cc: Steven Rostedt
Signed-off-by: Lina Iyer
---
drivers/soc/qcom/Makefile | 1 +
drivers/soc/qcom/rpmh-rsc.c | 6 +++
drivers/soc/qcom/trace-rpmh.h | 89 +++
3 files changed, 96 insertions(
Some RSCs may only have sleep and wake TCS, i.e, there is no dedicated
TCS for active mode request, but drivers may still want to make active
requests from these RSCs. In such cases re-purpose the wake TCS to send
active state requests.
The requirement for this is that the driver is aware that the
Platform drivers need make a lot of resource state requests at the same
time, say, at the start or end of an usecase. It can be quite
inefficient to send each request separately. Instead they can give the
RPMH library a batch of requests to be sent and wait on the whole
transaction to be complete.
Allow sleep and wake commands to be cleared from the respective TCSes,
so that they can be re-populated.
Signed-off-by: Lina Iyer
---
drivers/soc/qcom/rpmh-internal.h | 1 +
drivers/soc/qcom/rpmh-rsc.c | 46
2 files changed, 47 insertions(+)
diff -
Changes in v2:
- Added sleep/wake, async and batch requests support
- Addressed Bjorn's comments
- Private FTRACE for drivers/soc/qcom as suggested by Steven
- Sparse checked on these patches
- Use SPDX license commenting sytle
This set of patches add the ability for platform drivers to make use o
On Sun, Feb 04, 2018 at 04:50:58PM +, JackStocker wrote:
> Following on from this patch: https://lkml.org/lkml/2017/11/3/516,
> Corsair K70 RGB keyboards also require the DELAY_INIT quirk to
> start correctly at boot.
>
> Device ids found here:
> usb 3-3: New USB device found, idVendor=1b1c, i
On Thu, Feb 15, 2018 at 02:22:39PM +, Will Deacon wrote:
> Assuming others agree with this diagnosis, I'm not sure how to fix it.
> It's basically not safe to set current->mm = NULL with preemption enabled.
One thing we could try would be to leave current->mm alone and just do the
mmdrop in fi
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Will Deacon
Commit 41acec624087 upstream.
To allow systems which do not require kpti to continue running with
global kernel mappings (which appears to be a requirement for Cavium
ThunderX due
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Shanker Donthineni
Commit ec82b567a74f upstream.
Falkor is susceptible to branch predictor aliasing and can
theoretically be attacked by malicious code. This patch
implements a mitigation for
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Jayachandran C
Commit f3d795d9b360 upstream.
Use PSCI based mitigation for speculative execution attacks targeting
the branch predictor. We use the same mechanism as the one used for
Cortex-A
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Marc Zyngier
Commit 58e0b2239a4d upstream.
PSCI 1.0 can be trivially implemented by providing the FEATURES
call on top of PSCI 0.2 and returning 1.0 as the PSCI version.
We happily ignore ev
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Marc Zyngier
Commit f5115e8869e1 upstream.
When handling an SMC trap, the "preferred return address" is set
to that of the SMC, and not the next PC (which is a departure from
the behaviour of
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Will Deacon
Commit f992b4dfd58b upstream.
Defaulting to global mappings for kernel space is generally good for
performance and appears to be necessary for Cavium ThunderX. If we
subsequently
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Marc Zyngier
Commit 84684fecd7ea upstream.
Instead of open coding the accesses to the various registers,
let's add explicit SMCCC accessors.
Reviewed-by: Christoffer Dall
Tested-by: Ard Bie
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Marc Zyngier
Commit 90348689d500 upstream.
For those CPUs that require PSCI to perform a BP invalidation,
going all the way to the PSCI code for not much is a waste of
precious cycles. Let's
On Thu, Feb 15, 2018 at 09:24:36AM -0800, Eric Dumazet wrote:
> On Thu, Feb 15, 2018 at 9:20 AM, Eric Dumazet wrote:
> >
> > Yes, it seems tun.c breaks the assumptions.
> >
> > If it really wants to provide arbitrary fragments and alignments, it
> > should use a separate
>
> Sorry, I have sent th
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Marc Zyngier
Commit 6dc52b15c4a4 upstream.
Cavium ThunderX's erratum 27456 results in a corruption of icache
entries that are loaded from memory that is mapped as non-global
(i.e. ASID-tagged
On Thu, Feb 15, 2018 at 02:49:44AM +, Kuninori Morimoto wrote:
>
> Hi Stephen
>
> Thank you for reporting.
> It is my fault, this patch might cause other issue.
> I'm asking to Mark to remove it from his branch.
Dropped.
signature.asc
Description: PGP signature
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Will Deacon
Commit f167211a93ac upstream.
We don't fully understand the Cavium ThunderX erratum, but it appears
that mapping the kernel as nG can lead to horrible consequences such as
attempt
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Will Deacon
Commit 4e6020565596 upstream.
Break-before-make is not needed when transitioning from Global to
Non-Global mappings, provided that the contiguous hint is not being used.
Signed-o
On Thu, Feb 15, 2018 at 07:22:46AM -0800, Tejun Heo wrote:
> On Wed, Feb 14, 2018 at 10:40:43AM -0600, Josh Poimboeuf wrote:
> > The jump_label code doesn't patch init code, so this tracepoint can
> > never be enabled. Remove it.
> >
> > Cc: Tejun Heo
> > Signed-off-by: Josh Poimboeuf
>
> Appl
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Will Deacon
Commit 669474e772b9 upstream.
For CPUs capable of data value prediction, CSDB waits for any outstanding
predictions to architecturally resolve before allowing speculative executio
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Marc Zyngier
Commit 6167ec5c9145 upstream.
A new feature of SMCCC 1.1 is that it offers firmware-based CPU
workarounds. In particular, SMCCC_ARCH_WORKAROUND_1 provides
BP hardening for CVE-20
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Kamal Dasu
commit f953f0f89663c39f08f4baaa8a4a881401b65654 upstream.
Brcm nand controller prefetch feature needs to be disabled
by default. Enabling affects performance on random reads as
well
On 15/02/18 16:08, Lukas Senger wrote:
@@ -20,18 +21,20 @@
target = <&gpio>;
__overlay__ {
pps_pins: pps_pins@12 {
- brcm,pins = <18>;
- brcm,function = <0>;// in
-
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Miquel Raynal
commit 87e89ce8d0d14f573c068c61bec2117751fb5103 upstream.
Starting from commit 041e4575f034 ("mtd: nand: handle ECC errors in
OOB"), nand_do_read_oob() (from the NAND core) did r
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Clay McClure
commit a51a0c8d213594bc094cb8e54aad0cb6d7f7b9a6 upstream.
Similar to commit 714fb87e8bc0 ("ubi: Fix race condition between ubi
device creation and udev"), we should make the volum
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Miquel Raynal
commit f4c6cd1a7f2275d5bc0e494b21fff26f8dde80f0 upstream.
When the requested ECC strength does not exactly match the strengths
supported by the ECC engine, the driver is selectin
On 14/02/18 19:26, Stefano Stabellini wrote:
> Hi all,
>
> this small series introduces a per socket refcount to increase the
> efficiency on socket release operations, and makes releasing passive
> sockets safe.
>
> Cheers,
>
> Stefano
>
>
> Changes in v3:
> - remove pointless initializers
>
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Bradley Bolen
commit 7f29ae9f977bcdc3654e68bc36d170223c52fd48 upstream.
This fixes a race with idr_alloc where gd->first_minor can be set to the
same value for two simultaneous calls to ubiblo
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Scott Mayhew
commit ba4a76f703ab7eb72941fdaac848502073d6e9ee upstream.
Currently when falling back to doing I/O through the MDS (via
pnfs_{read|write}_through_mds), the client frees the nfs_pg
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Trond Myklebust
commit 7f1bda447c9bd48b415acedba6b830f61591601f upstream.
The commit list can get very large, and so we need a cond_resched()
in nfs_commit_release_pages() in order to ensure w
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Trond Myklebust
commit 8634ef5e05311f32d7f2aee06f6b27a8834a3bd6 upstream.
The LOOKUPP operation was inserted into the nfs4_procedures array
rather than being appended, which put /proc/net/rpc/
The patch
ASoC: TSCS42xx: make const array norm_addrs static, reduces object code size
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Eric Biggers
commit 49686cbbb3ebafe42e63868222f269d8053ead00 upstream.
nfs_idmap_legacy_upcall() is supposed to be called with 'aux' pointing
to a 'struct idmap', via the call to request_key_w
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Hans de Goede
commit 998008b779e424bd7513c434d0ab9c1268459009 upstream.
Add PCI ids for Intel Bay Trail, Cherry Trail and Apollo Lake AHCI
SATA controllers. This commit is a preparation patch
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Ivan Vecera
commit ba87977a49913129962af8ac35b0e13e0fa4382d upstream.
Commit b7ce40cff0b9 ("kernfs: cache atomic_write_len in
kernfs_open_file") changes type of local variable 'len' from ssize
On Wed, Feb 14, 2018 at 01:48:27PM +0100, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> Thanks for your patch!
>
> On Tue, Feb 13, 2018 at 10:45 AM, Jacopo Mondi
> wrote:
> > Add support for R-Car M3-N (r8a77965) power areas and reset.
> > M3-N power areas are identical to M3-W ones, so just copy a
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Marc Zyngier
Commit 09a8d6d48499 upstream.
In order to call into the firmware to apply workarounds, it is
useful to find out whether we're using HVC or SMC. Let's expose
this through the psci
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Eric Biggers
commit cd6ed77ad5d223dc6299fb58f62e0f5267f7e2ba upstream.
Templates that use an shash spawn can use crypto_shash_alg_has_setkey()
to determine whether the underlying algorithm req
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Eric Biggers
commit 841a3ff329713f796a63356fef6e2f72e4a3f6a3 upstream.
When the cryptd template is used to wrap an unkeyed hash algorithm,
don't install a ->setkey() method to the cryptd insta
On Thu, Feb 15, 2018 at 9:20 AM, Eric Dumazet wrote:
>
> Yes, it seems tun.c breaks the assumptions.
>
> If it really wants to provide arbitrary fragments and alignments, it
> should use a separate
Sorry, I have sent the message to soon.
tun.c should use a private 'struct page_frag_cache' to del
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Eric Biggers
commit fa59b92d299f2787e6bae1ff078ee0982e80211f upstream.
When the mcryptd template is used to wrap an unkeyed hash algorithm,
don't install a ->setkey() method to the mcryptd ins
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Eric Biggers
commit a208fa8f33031b9e0aba44c7d1b7e68eb0cbd29e upstream.
We need to consistently enforce that keyed hashes cannot be used without
setting the key. To do this we need a reliable
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Marc Zyngier
Commit e78eef554a91 upstream.
Since PSCI 1.0 allows the SMCCC version to be (indirectly) probed,
let's do that at boot time, and expose the version of the calling
convention as p
The patch
ASoC: uniphier: remove redundant check of blk_id
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Eric Biggers
commit 9fa68f620041be04720d0cbfb1bd3ddfc6310b24 upstream.
Currently, almost none of the keyed hash algorithms check whether a key
has been set before proceeding. Some algorithms
501 - 600 of 1436 matches
Mail list logo
