On Sun, Apr 21, 2019 at 01:04:39AM -0700, Nicolin Chen wrote:
> On Sun, Apr 21, 2019 at 10:26:40AM +0300, Daniel Baluta wrote:
> > > Firstly, according to your commit message, neither imx8qm nor
> > > imx6sx has an "mclk0" clock in the clock list. Either of them
> > > starts with "mclk1". So,
Hi Nicolin,
Thanks for review!
On Sun, Apr 21, 2019 at 8:39 AM Nicolin Chen wrote:
>
> By following the pattern of previous Subjects:
> ASoC: fsl_sai: Fix clock Source for mclk0
I see. Will fix in v2.
>
> On Sat, Apr 20, 2019 at 03:41:04PM +, Daniel Baluta wrote:
> > SAI provide multiple
On Wed, 2019-04-03 at 04:12:32 UTC, Alexey Kardashevskiy wrote:
> Currently mm_iommu_do_alloc() is called in 2 cases:
> - VFIO_IOMMU_SPAPR_REGISTER_MEMORY ioctl() for normal memory:
> this locks _list_mutex and then locks mm::mmap_sem
> several times when adjusting locked_vm or pinning
On Wed, 2019-04-03 at 04:12:33 UTC, Alexey Kardashevskiy wrote:
> When called with vmas_arg==NULL, get_user_pages_longterm() allocates
> an array of nr_pages*8 which can easily get greater that the max order,
> for example, registering memory for a 256GB guest does this and fails
> in
On Sun, Apr 21, 2019 at 11:26 AM Nicolin Chen wrote:
>
> On Sun, Apr 21, 2019 at 01:04:39AM -0700, Nicolin Chen wrote:
> > On Sun, Apr 21, 2019 at 10:26:40AM +0300, Daniel Baluta wrote:
> > > > Firstly, according to your commit message, neither imx8qm nor
> > > > imx6sx has an "mclk0" clock in
On Sun, Apr 21, 2019 at 10:26:40AM +0300, Daniel Baluta wrote:
> > Firstly, according to your commit message, neither imx8qm nor
> > imx6sx has an "mclk0" clock in the clock list. Either of them
> > starts with "mclk1". So, before you change the driver, I don't
> > think it's even a right thing to
On Wed, 2019-04-17 at 07:41:40 UTC, Michael Ellerman wrote:
> Joel reported weird crashes using skiroot_defconfig, in his case we
> jumped into an NX page:
>
> kernel tried to execute exec-protected page (c2bff4f0) - exploit
> attempt? (uid: 0)
> BUG: Unable to handle kernel
On Mon, 2019-03-11 at 08:30:30 UTC, Christophe Leroy wrote:
> syscalls are from user only, so we can account time without checking
> whether returning to kernel or user as it will only be user.
>
> Signed-off-by: Christophe Leroy
Patches 3-10 applied to powerpc next, thanks.
On Wed, 2019-03-13 at 10:25:28 UTC, Laurent Vivier wrote:
> resize_hpt_for_hotplug() reports a warning when it cannot
> resize the hash page table ("Unable to resize hash page
> table to target order") but in some cases it's not a problem
> and can make user thinks something has not worked
On Sat, 2019-03-23 at 12:50:55 UTC, jagdsh.li...@gmail.com wrote:
> From: Jagadeesh Pagadala
>
> Remove duplicate headers which are included twice.
>
> Signed-off-by: Jagadeesh Pagadala
> Reviewed-by: Mukesh Ojha
Applied to powerpc next, thanks.
On Tue, 2019-04-09 at 04:03:28 UTC, "Aneesh Kumar K.V" wrote:
> Add radix_enabled check to avoid slb preload with radix translation.
>
> Signed-off-by: Aneesh Kumar K.V
> Acked-by: Nicholas Piggin
Applied to powerpc next, thanks.
On Sun, 2019-04-07 at 02:48:08 UTC, Qian Cai wrote:
> The commit b7d6bf4fdd47 ("powerpc/pseries/pci: Remove obsolete SW
> invalidate") left 2 variables unused.
>
> arch/powerpc/platforms/pseries/iommu.c: In function 'tce_build_pSeries':
> arch/powerpc/platforms/pseries/iommu.c:108:17: warning:
On Wed, 2019-04-17 at 13:03:47 UTC, "Aneesh Kumar K.V" wrote:
> Book3s64 always have PPC_MM_SLICES enabled. So remove the unncessary #ifdef
>
> Signed-off-by: Aneesh Kumar K.V
Patches 2-6 applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/4f40b15f339d896f5726714842947c93
cheers
On Thu, 2019-04-18 at 18:56:57 UTC, Nathan Lynch wrote:
> When booted with "topology_updates=no", or when "off" is written to
> /proc/powerpc/topology_updates, NUMA reassignments are inhibited for
> PRRN and VPHN events. However, migration and suspend unconditionally
> re-enable reassignments via
commit 84749a58b6e382f109abf1e734bc4dd43c2c25bb upstream.
This ensures the fallback flush area is always allocated on pseries,
so in case a LPAR is migrated from a patched to an unpatched system,
it is possible to enable the fallback flush in the target system.
Signed-off-by: Michael Ellerman
commit abf110f3e1cea40f5ea15e85f5d67c39c14568a7 upstream.
For PowerVM migration we want to be able to call setup_rfi_flush()
again after we've migrated the partition.
To support that we need to check that we're not trying to allocate the
fallback flush area after memblock has gone away (i.e.,
commit 921bc6cf807ceb2ab8005319cf39f33494d6b100 upstream.
We might have migrated to a machine that uses a different flush type,
or doesn't need flushing at all.
Signed-off-by: Michael Ellerman
Signed-off-by: Mauricio Faria de Oliveira
Signed-off-by: Michael Ellerman
---
commit 9a868f634349e62922c226834aa23e3d1329ae7f upstream.
This commit adds security feature flags to reflect the settings we
receive from firmware regarding Spectre/Meltdown mitigations.
The feature names reflect the names we are given by firmware on bare
metal machines. See the hostboot source
From: Michal Suchanek
commit 815069ca57c142eb71d27439bc27f41a433a67b3 upstream.
Note that unlike RFI which is patched only in kernel the nospec state
reflects settings at the time the module was loaded.
Iterating all modules and re-patching every time the settings change
is not implemented.
From: Michal Suchanek
commit cb3d6759a93c6d0aea1c10deb6d00e111c29c19c upstream.
Check what firmware told us and enable/disable the barrier_nospec as
appropriate.
We err on the side of enabling the barrier, as it's no-op on older
systems, see the comment for more detail.
Signed-off-by: Michael
commit 51973a815c6b46d7b23b68d6af371ad1c9d503ca upstream.
Our syscall entry is done in assembly so patch in an explicit
barrier_nospec.
Based on a patch by Michal Suchanek.
Signed-off-by: Michal Suchanek
Signed-off-by: Michael Ellerman
---
arch/powerpc/kernel/entry_64.S | 10 ++
1
commit 179ab1cbf883575c3a585bcfc0f2160f1d22a149 upstream.
Add a config symbol to encode which platforms support the
barrier_nospec speculation barrier. Currently this is just Book3S 64
but we will add Book3E in a future patch.
Signed-off-by: Diana Craciun
Signed-off-by: Michael Ellerman
---
commit ba72dc171954b782a79d25e0f4b3ed91090c3b1e upstream.
Use the existing hypercall to determine the appropriate settings for
the count cache flush, and then call the generic powerpc code to set
it up based on the security feature flags.
Signed-off-by: Michael Ellerman
---
commit 99d54754d3d5f896a8f616b0b6520662bc99d66b upstream.
Look for fw-features properties to determine the appropriate settings
for the count cache flush, and then call the generic powerpc code to
set it up based on the security feature flags.
Signed-off-by: Michael Ellerman
---
From: Diana Craciun
commit dfa88658fb0583abb92e062c7a9cd5a5b94f2a46 upstream.
Report branch predictor state flush as a mitigation for
Spectre variant 2.
Signed-off-by: Diana Craciun
Signed-off-by: Michael Ellerman
---
arch/powerpc/kernel/security.c | 5 -
1 file changed, 4
From: Christophe Leroy
commit 27da80719ef132cf8c80eb406d5aeb37dddf78cc upstream.
The commit identified below adds MC_BTB_FLUSH macro only when
CONFIG_PPC_FSL_BOOK3E is defined. This results in the following error
on some configs (seen several times with kisskb randconfig_defconfig)
On Mon, 2019-02-11 at 11:37:12 UTC, Thomas Huth wrote:
> Recent versions of QEMU provide a XHCI device by default these
> days instead of an old-fashioned OHCI device:
>
> https://git.qemu.org/?p=qemu.git;a=commitdiff;h=57040d451315320b7d27
>
> So to get the keyboard working in the graphical
On Tue, 2019-03-26 at 20:47:18 UTC, Mathieu Malaterre wrote:
> In commit cb9e4d10c448 ("[POWERPC] Add support for 750CL Holly board")
> new functions were added. Since most of these functions can be made static,
> make it so.
>
> Both holly_power_off and holly_halt functions were not changed
On Wed, 2019-03-27 at 03:35:54 UTC, Russell Currey wrote:
> With STRICT_KERNEL_RWX enabled anything marked __init is placed at a 16M
> boundary. This is necessary so that it can be repurposed later with
> different permissions. However, in kernels with text larger than 16M,
> this pushes
On Wed, 2019-04-17 at 12:59:13 UTC, "Aneesh Kumar K.V" wrote:
> This makes it easy to update the region mapping in the later patch
>
> Signed-off-by: Aneesh Kumar K.V
Patches 1-7 applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/a35a3c6f60657812366fca86a9ce71df
cheers
From: Mauricio Faria de Oliveira
commit 0063d61ccfc011f379a31acaeba6de7c926fed2c upstream.
Currently the rfi-flush messages print 'Using flush' for all
enabled_flush_types, but that is not necessarily true -- as now the
fallback flush is always enabled on pseries, but the fixup function
commit c4bc36628d7f8b664657d8bd6ad1c44c177880b7 upstream.
Add some additional values which have been defined for the
H_GET_CPU_CHARACTERISTICS hypercall.
Signed-off-by: Michael Ellerman
---
arch/powerpc/include/asm/hvcall.h | 3 +++
1 file changed, 3 insertions(+)
diff --git
commit 37c0bdd00d3ae83369ab60a6712c28e11e6458d5 upstream.
Now that we have the security flags we can significantly simplify the
code in pnv_setup_rfi_flush(), because we can use the flags instead of
checking device tree properties and because the security flags have
pessimistic defaults.
commit 8ad33041563a10b34988800c682ada14b2612533 upstream.
This landed in setup_64.c for no good reason other than we had nowhere
else to put it. Now that we have a security-related file, that is a
better place for it so move it.
Signed-off-by: Michael Ellerman
---
commit 501a78cbc17c329fabf8e9750a1e9ab810c88a0e upstream.
The recent LPM changes to setup_rfi_flush() are causing some section
mismatch warnings because we removed the __init annotation on
setup_rfi_flush():
The function setup_rfi_flush() references
the function __init ppc64_bolted_size().
From: Mauricio Faria de Oliveira
commit 6232774f1599028a15418179d17f7df47ede770a upstream.
After migration the security feature flags might have changed (e.g.,
destination system with unpatched firmware), but some flags are not
set/clear again in init_cpu_char_feature_flags() because it assumes
From: Diana Craciun
commit cf175dc315f90185128fb061dc05b6fbb211aa2f upstream.
The speculation barrier can be disabled from the command line
with the parameter: "nospectre_v1".
Signed-off-by: Diana Craciun
Signed-off-by: Michael Ellerman
---
arch/powerpc/kernel/security.c | 12 +++-
commit 6d44acae1937b81cf8115ada8958e04f601f3f2e upstream.
When I added the spectre_v2 information in sysfs, I included the
availability of the ori31 speculation barrier.
Although the ori31 barrier can be used to mitigate v2, it's primarily
intended as a spectre v1 mitigation. Spectre v2 is
From: Diana Craciun
commit ebcd1bfc33c7a90df941df68a6e5d4018c022fba upstream.
Implement the barrier_nospec as a isync;sync instruction sequence.
The implementation uses the infrastructure built for BOOK3S 64.
Signed-off-by: Diana Craciun
[mpe: Add PPC_INST_ISYNC for backport]
Signed-off-by:
commit 06d0bbc6d0f56dacac3a79900e9a9a0d5972d818 upstream.
Add a macro and some helper C functions for patching single asm
instructions.
The gas macro means we can do something like:
1:nop
patch_site 1b, patch__foo
Which is less visually distracting than defining a GLOBAL symbol
commit 92edf8df0ff2ae86cc632eeca0e651fd8431d40d upstream.
When I updated the spectre_v2 reporting to handle software count cache
flush I got the logic wrong when there's no software count cache
enabled at all.
The result is that on systems with the software count cache flush
disabled we print:
On Mon, Apr 22, 2019 at 12:19:45AM +1000, Michael Ellerman wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi Greg/Sasha,
>
> Please queue up these powerpc patches for 4.4 if you have no objections.
why? Do you, or someone else, really care about spectre issues in 4.4?
Who is
On Thu, 2019-03-07 at 09:47:50 UTC, Christophe Leroy wrote:
> In arch/powerpc/mm/highmem.c, BUG_ON() is called only when
> CONFIG_DEBUG_HIGHMEM is selected, this means the BUG_ON() is
> not vital and can be replaced by a a WARN_ON
>
> At the sametime, use IS_ENABLED() instead of #ifdef to clean a
On Thu, 2019-03-28 at 11:40:33 UTC, Mahesh J Salgaonkar wrote:
> From: Mahesh Salgaonkar
>
> This is a follow up to the patch that fixed misleading print for TLB
> mutlihit due to wrongly populated mc_err_types[] array. Convert all the
> static array initialization to '[x] = val' style for
On Sat, 2019-03-30 at 05:43:45 UTC, "Aneesh Kumar K.V" wrote:
> This patch fix the below section mismatch warnings.
>
> WARNING: vmlinux.o(.text+0x2d1f44): Section mismatch in reference from the
> function devm_memremap_pages_release() to the function
> .meminit.text:arch_remove_memory()
>
On Thu, 2019-04-18 at 06:51:16 UTC, Michael Ellerman wrote:
> From: Russell Currey
>
> Without restoring the IAMR after idle, execution prevention on POWER9
> with Radix MMU is overwritten and the kernel can freely execute
> userspace without faulting.
>
> This is necessary when returning from
commit 77addf6e95c8689e478d607176b399a6242a777e upstream.
Now that we have feature flags for security related things, set or
clear them based on what we see in the device tree provided by
firmware.
Signed-off-by: Michael Ellerman
---
arch/powerpc/platforms/powernv/setup.c | 56
commit ff348355e9c72493947be337bb4fae4fc1a41eba upstream.
Now that we have the security feature flags we can make the
information displayed in the "meltdown" file more informative.
Signed-off-by: Michael Ellerman
---
arch/powerpc/include/asm/security_features.h | 1 +
From: Nicholas Piggin
commit a048a07d7f4535baa4cbad6bc024f175317ab938 upstream.
On some CPUs we can prevent a vulnerability related to store-to-load
forwarding by preventing store forwarding between privilege domains,
by inserting a barrier in kernel entry and exit paths.
This is known to be
commit ddf35cf3764b5a182b178105f57515b42e2634f8 upstream.
Based on the x86 commit doing the same.
See commit 304ec1b05031 ("x86/uaccess: Use __uaccess_begin_nospec()
and uaccess_try_nospec") and b3bbfb3fb5d2 ("x86: Introduce
__uaccess_begin_nospec() and uaccess_try_nospec") for more detail.
In
From: Michal Suchanek
commit a377514519b9a20fa1ea9adddbb4129573129cef upstream.
We now have barrier_nospec as mitigation so print it in
cpu_show_spectre_v1() when enabled.
Signed-off-by: Michal Suchanek
Signed-off-by: Michael Ellerman
---
arch/powerpc/kernel/security.c | 3 +++
1 file
From: Michael Neuling
commit 51c3c62b58b357e8d35e4cc32f7b4ec907426fe3 upstream.
This stops us from doing code patching in init sections after they've
been freed.
In this chain:
kvm_guest_init() ->
kvm_use_magic_page() ->
fault_in_pages_readable() ->
__get_user() ->
From: Diana Craciun
commit 76a5eaa38b15dda92cd6964248c39b5a6f3a4e9d upstream.
In order to protect against speculation attacks (Spectre
variant 2) on NXP PowerPC platforms, the branch predictor
should be flushed when the privillege level is changed.
This patch is adding the infrastructure to
tree: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
next-test
head: 26ad26718dfaa7cf49d106d212ebf2370076c253
commit: 06fbe81b5909847aa13f9c86c2b6f9bbc5c2795b [40/58] powerpc/8xx: Add
Kernel Userspace Execution Prevention
config: powerpc-mpc885_ads_defconfig (attached as
is_slave_mode defaults to false because sai structure
that contains it is kzalloc'ed.
Anyhow, if we decide to set the following configuration
SAI slave -> SAI master, is_slave_mode will remain set on true
although SAI being master it should be set to false.
Fix this by updating is_slave_mode for
First patch fixes a bug by correctly setting is_slave_mode, then
second patch adds support for runtime PM and finally 3rd patch moves
clock handling from startup/shtudown function to runtime PM handlers.
Changes since v1:
- added patch 1
- added fsl_sai_remove in order to call
On Thu, 2019-03-07 at 14:40:31 UTC, Qian Cai wrote:
> pte_unmap() compiles away on some powerpc platforms, so silence the
> warnings below by making it a static inline function.
>
> mm/memory.c: In function 'copy_pte_range':
> mm/memory.c:820:24: warning: variable 'orig_dst_pte' set but not used
On Tue, 2019-03-26 at 10:29:51 UTC, Peng Hao wrote:
> From: Wen Yang
>
> The call to of_find_compatible_node returns a node pointer with refcount
> incremented thus it must be explicitly decremented after the last
> usage.
> irq_domain_add_linear also calls of_node_get to increase refcount,
> so
On Thu, 2019-04-11 at 04:27:52 UTC, Lukas Bulwahn wrote:
> Paul McKenney attempted to update all email addresses @linux.vnet.ibm.com
> to @linux.ibm.com in commit 1dfddcdb95c4
> ("MAINTAINERS: Update from @linux.vnet.ibm.com to @linux.ibm.com"), but
> some still remained.
>
> We update the
On Mon, 2019-04-15 at 10:05:44 UTC, Ganesh Goudar wrote:
> Add support to hwpoison the pages upon hitting machine check
> exception.
>
> This patch queues the address where UE is hit to percpu array
> and schedules work to plumb it into memory poison infrastructure.
>
> Reviewed-by: Mahesh
commit eb0a2d2620ae431c543963c8c7f08f597366fc60 upstream.
Some versions of firmware will have a setting that can be configured
to disable the RFI flush, add support for it.
Fixes: 6e032b350cd1 ("powerpc/powernv: Check device-tree for RFI flush
settings")
Signed-off-by: Michael Ellerman
---
commit 1e2a9fc7496955faacbbed49461d611b704a7505 upstream.
rfi_flush_enable() includes a check to see if we're already
enabled (or disabled), and in that case does nothing.
But that means calling setup_rfi_flush() a 2nd time doesn't actually
work, which is a bit confusing.
Move that check into
commit f636c14790ead6cc22cf62279b1f8d7e11a67116 upstream.
Now that we have feature flags for security related things, set or
clear them based on what we receive from the hypercall.
Signed-off-by: Michael Ellerman
---
arch/powerpc/platforms/pseries/setup.c | 43 ++
1
From: Mauricio Faria de Oliveira
commit 0f9bdfe3c77091e8704d2e510eb7c2c2c6cde524 upstream.
The H_CPU_BEHAV_* flags should be checked for in the 'behaviour' field
of 'struct h_cpu_char_result' -- 'character' is for H_CPU_CHAR_*
flags.
Found by playing around with QEMU's implementation of the
From: Mauricio Faria de Oliveira
commit e7347a86830f38dc3e40c8f7e28c04412b12a2e7 upstream.
This moves the definition of the default security feature flags
(i.e., enabled by default) closer to the security feature flags.
This can be used to restore current flags to the default flags.
From: Diana Craciun
commit 6453b532f2c8856a80381e6b9a1f5ea2f12294df upstream.
NXP Book3E platforms are not vulnerable to speculative store
bypass, so make the mitigations PPC_BOOK3S_64 specific.
Signed-off-by: Diana Craciun
Signed-off-by: Michael Ellerman
---
arch/powerpc/kernel/security.c
commit dc8c6cce9a26a51fc19961accb978217a3ba8c75 upstream.
Add security feature flags to indicate the need for software to flush
the count cache on context switch, and for the presence of a hardware
assisted count cache flush.
Signed-off-by: Michael Ellerman
---
commit ee13cb249fabdff8b90aaff61add347749280087 upstream.
Some CPU revisions support a mode where the count cache needs to be
flushed by software on context switch. Additionally some revisions may
have a hardware accelerated flush, in which case the software flush
sequence can be shortened.
If
From: Diana Craciun
commit 10c5e83afd4a3f01712d97d3bb1ae34d5b74a185 upstream.
In order to protect against speculation attacks on
indirect branches, the branch predictor is flushed at
kernel entry to protect for the following situations:
- userspace process attacking another userspace process
-
From: Diana Craciun
commit f633a8ad636efb5d4bba1a047d4a0f1ef719aa06 upstream.
When the command line argument is present, the Spectre variant 2
mitigations are disabled.
Signed-off-by: Diana Craciun
Signed-off-by: Michael Ellerman
---
arch/powerpc/include/asm/setup.h | 5 +
tree: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
next-test
head: 26ad26718dfaa7cf49d106d212ebf2370076c253
commit: 2679f9bd0abafb3044bcbaac0600b32159ac8bf2 [41/58] powerpc/8xx: Add
Kernel Userspace Access Protection
config: powerpc-mpc885_ads_defconfig (attached as
On Thu, 2019-02-07 at 05:16:51 UTC, Michael Ellerman wrote:
> Add a generic 32-bit defconfig called ppc_defconfig. This means we'll
> have a defconfig matching "uname -m" for all cases.
>
> This config is mostly intended for build testing but if someone wants
> to tweak it to get it booting on
On Thu, 2019-03-21 at 10:42:22 UTC, George Spelvin wrote:
> This code was filling a 64K buffer from /dev/urandom in order to
> compute a CRC over (on average half of) it by two different methods,
> comparing the CRCs, and repeating.
>
> This is not a remotely security-critical application, so use
On Thu, 2019-03-14 at 04:27:27 UTC, Andrew Donnellan wrote:
> sparse complains a lot about opal-call.c:
>
> arch/powerpc/platforms/powernv/opal-call.c:128:1: warning: symbol
> 'opal_invalid_call' was not declared. Should it be static?
> arch/powerpc/platforms/powernv/opal-call.c:129:1:
On Wed, 2019-04-03 at 06:05:14 UTC, "Aneesh Kumar K.V" wrote:
> The current value of MAX_PHYSMEM_BITS cannot work with 32 bit configs.
> We used to have MAX_PHYSMEM_BITS not defined without SPARSEMEM and 32
> bit configs never expected a value to be set for MAX_PHYSMEM_BITS.
>
> Dependent code
On Thu, 2019-04-11 at 01:38:46 UTC, Sukadev Bhattiprolu wrote:
> The file arch/powerpc/include/uapi/asm/vas.h was considered but
> never merged and should be removed from the MAINTAINERS file.
>
> While here, add missing email address.
>
> Reported-by: Joe Perches
> Signed-off-by: Sukadev
From: Nicholas Piggin
commit bdcb1aefc5b3f7d0f1dc8b02673602bca2ff7a4b upstream.
The fallback RFI flush is used when firmware does not provide a way
to flush the cache. It's a "displacement flush" that evicts useful
data by displacing it with an uninteresting buffer.
The flush has to take care
commit 582605a429e20ae68fd0b041b2e840af296edd08 upstream.
Some versions of firmware will have a setting that can be configured
to disable the RFI flush, add support for it.
Fixes: 8989d56878a7 ("powerpc/pseries: Query hypervisor for RFI flush settings")
Signed-off-by: Michael Ellerman
---
commit 2e4a16161fcd324b1f9bf6cb6856529f7eaf0689 upstream.
Now that we have the security flags we can simplify the code in
pseries_setup_rfi_flush() because the security flags have pessimistic
defaults.
Signed-off-by: Michael Ellerman
---
arch/powerpc/platforms/pseries/setup.c | 27
commit 56986016cb8cd9050e601831fe89f332b4e3c46e upstream.
Add a definition for cpu_show_spectre_v1() to override the generic
version. Currently this just prints "Not affected" or "Vulnerable"
based on the firmware flag.
Although the kernel does have array_index_nospec() in a few places, we
commit d6fbe1c55c55c6937cbea3531af7da84ab7473c3 upstream.
Add a definition for cpu_show_spectre_v2() to override the generic
version. This has several permuations, though in practice some may not
occur we cater for any combination.
The most verbose is:
Mitigation: Indirect branch
From: Michal Suchanek
commit 2eea7f067f495e33b8b116b35b5988ab2b8aec55 upstream.
Based on the RFI patching. This is required to be able to disable the
speculation barrier.
Only one barrier type is supported and it does nothing when the
firmware does not enable it. Also re-patching modules is
From: Michal Suchanek
commit a6b3964ad71a61bb7c61d80a60bea7d42187b2eb upstream.
A no-op form of ori (or immediate of 0 into r31 and the result stored
in r31) has been re-tasked as a speculation barrier. The instruction
only acts as a barrier on newer machines with appropriate firmware
support.
From: Diana Craciun
commit 406d2b6ae3420f5bb2b3db6986dc6f0b6dbb637b upstream.
In a subsequent patch we will enable building security.c for Book3E.
However the NXP platforms are not vulnerable to Meltdown, so make the
Meltdown vulnerability reporting PPC_BOOK3S_64 specific.
Signed-off-by: Diana
commit af375eefbfb27cbb5b831984e66d724a40d26b5c upstream.
Currently we require platform code to call setup_barrier_nospec(). But
if we add an empty definition for the !CONFIG_PPC_BARRIER_NOSPEC case
then we can call it in setup_arch().
Signed-off-by: Diana Craciun
Signed-off-by: Michael
From: Diana Craciun
commit 1cbf8990d79ff69da8ad09e8a3df014e1494462b upstream.
The BUCSR register can be used to invalidate the entries in the
branch prediction mechanisms.
Signed-off-by: Diana Craciun
Signed-off-by: Michael Ellerman
---
arch/powerpc/include/asm/ppc_asm.h | 11 +++
1
From: Diana Craciun
commit 7d8bad99ba5a22892f0cad6881289fdc3875a930 upstream.
Currently for CONFIG_PPC_FSL_BOOK3E the spectre_v2 file is incorrect:
$ cat /sys/devices/system/cpu/vulnerabilities/spectre_v2
"Mitigation: Software count cache flush"
Which is wrong. Fix it to report vulnerable
On Sun, Apr 21, 2019 at 07:39:08PM +, Daniel Baluta wrote:
> is_slave_mode defaults to false because sai structure
> that contains it is kzalloc'ed.
>
> Anyhow, if we decide to set the following configuration
> SAI slave -> SAI master, is_slave_mode will remain set on true
> although SAI
On Sun, Apr 21, 2019 at 07:39:09PM +, Daniel Baluta wrote:
> Basically the same actions as for system PM, so make use
> of pm_runtime_force_suspend/pm_runtime_force_resume.
>
> Signed-off-by: Shengjiu Wang
> Signed-off-by: Daniel Baluta
Acked-by: Nicolin Chen
Thanks
> ---
>
On Sun, Apr 21, 2019 at 07:39:10PM +, Daniel Baluta wrote:
> From: Shengjiu Wang
>
> Turn off/on clocks when device enters suspend/resume. This
> can help saving power.
>
> As a further optimization, we turn off/on mclk only when SAI
> is in master mode because otherwise mclk is externally
Support more sample rate in asrc
Shengjiu Wang (3):
ASoC: fsl_asrc: Fix the issue about unsupported rate
ASoC: fsl_asrc: replace the process_option table with function
ASoC: fsl_asrc: Unify the supported input and output rate
Changes in v5
- fix the [1/24, 8]
- move fsl_asrc_sel_proc
On Mon, Apr 22, 2019 at 02:32:32AM +, S.j. Wang wrote:
> When the output sample rate is [8kHz, 30kHz], the limitation
> of the supported ratio range is (1/24, 8). In the driver
Should be [1/24, 8].
Otherwise,
Acked-by: Nicolin Chen
Thanks
> we use (8kHz, 30kHz) instead of [8kHz, 30kHz].
>
Hi
>
>
> On Mon, Apr 22, 2019 at 02:32:35AM +, S.j. Wang wrote:
> > When we want to support more sample rate, for example 12kHz/24kHz
> we
> > need update the process_option table, if we want to support more
> > sample rate next time, the table need to be updated again. which is
> > not
Unify the supported input and output rate, add the
12kHz/24kHz/128kHz to the support list
Signed-off-by: Shengjiu Wang
Acked-by: Nicolin Chen
---
sound/soc/fsl/fsl_asrc.c | 32 +++-
1 file changed, 19 insertions(+), 13 deletions(-)
diff --git
When we want to support more sample rate, for example 12kHz/24kHz
we need update the process_option table, if we want to support more
sample rate next time, the table need to be updated again. which
is not flexible.
We got a function fsl_asrc_sel_proc to replace the table, which can
give the
When the output sample rate is [8kHz, 30kHz], the limitation
of the supported ratio range is (1/24, 8). In the driver
we use (8kHz, 30kHz) instead of [8kHz, 30kHz].
So this patch is to fix this issue and the potential rounding
issue with divider.
Fixes: fff6e03c7b65 ("ASoC: fsl_asrc: add support
When we want to support more sample rate, for example 12kHz/24kHz
we need update the process_option table, if we want to support more
sample rate next time, the table need to be updated again. which
is not flexible.
We got a function fsl_asrc_sel_proc to replace the table, which can
give the
Unify the supported input and output rate, add the
12kHz/24kHz/128kHz to the support list
Signed-off-by: Shengjiu Wang
---
sound/soc/fsl/fsl_asrc.c | 32 +++-
1 file changed, 19 insertions(+), 13 deletions(-)
diff --git a/sound/soc/fsl/fsl_asrc.c
On Mon, Apr 22, 2019 at 02:32:35AM +, S.j. Wang wrote:
> When we want to support more sample rate, for example 12kHz/24kHz
> we need update the process_option table, if we want to support more
> sample rate next time, the table need to be updated again. which
> is not flexible.
>
> We got a
Support more sample rate in asrc
Shengjiu Wang (3):
ASoC: fsl_asrc: Fix the issue about unsupported rate
ASoC: fsl_asrc: replace the process_option table with function
ASoC: fsl_asrc: Unify the supported input and output rate
Changes in v6
- add acked-by
- fixed minor issue according to
1 - 100 of 113 matches
Mail list logo
