Eric Richter writes:
> From: Nayna Jain
>
> The keys used to verify the Host OS kernel are managed by firmware as
> secure variables. This patch loads the verification keys into the .platform
> keyring and revocation hashes into .blacklist keyring. This enables
> verification and loading of the k
On 08.11.19 08:14, David Hildenbrand wrote:
On 08.11.19 06:09, Dan Williams wrote:
On Thu, Nov 7, 2019 at 2:07 PM David Hildenbrand wrote:
On 07.11.19 19:22, David Hildenbrand wrote:
Am 07.11.2019 um 16:40 schrieb Dan Williams :
On Thu, Oct 24, 2019 at 5:12 AM David Hildenbrand wrote:
On (19/11/06 09:35), Petr Mladek wrote:
> I agree with all the other justification.
>
> I would add. The backtrace is really useful for debugging. It should
> be possible to print it even in less critical situations.
Hmm, I don't know.
Do we really need debug/info level backtraces? May be all bac
On Monday, October 21, 2019 4:51:48 PM CET Geert Uytterhoeven wrote:
> There is no need to cast a typed pointer to a void pointer when calling
> a function that accepts the latter. Remove it, as the cast prevents
> further compiler checks.
>
> Signed-off-by: Geert Uytterhoeven
Greg, have you ta
On Fri, Nov 08, 2019 at 12:24:42PM +0100, Rafael J. Wysocki wrote:
> On Monday, October 21, 2019 4:51:48 PM CET Geert Uytterhoeven wrote:
> > There is no need to cast a typed pointer to a void pointer when calling
> > a function that accepts the latter. Remove it, as the cast prevents
> > further
On 07/11/19 10:17 PM, Michal Suchanek wrote:
> Currently it is not possible to distinguish the case when fadump is
> supported by firmware and disabled in kernel and completely unsupported
> using the kernel sysfs interface. User can investigate the devicetree
> but it is more reasonable to prov
From: Alan Modra
[ Upstream commit 56d20861c027498b5a1112b4f9f05b56d906fdda ]
Call Frame Information is used by gdb for back-traces and inserting
breakpoints on function return for the "finish" command. This failed
when inside __kernel_clock_gettime. More concerning than difficulty
debugging i
From: Alan Modra
[ Upstream commit 56d20861c027498b5a1112b4f9f05b56d906fdda ]
Call Frame Information is used by gdb for back-traces and inserting
breakpoints on function return for the "finish" command. This failed
when inside __kernel_clock_gettime. More concerning than difficulty
debugging i
From: Alan Modra
[ Upstream commit 56d20861c027498b5a1112b4f9f05b56d906fdda ]
Call Frame Information is used by gdb for back-traces and inserting
breakpoints on function return for the "finish" command. This failed
when inside __kernel_clock_gettime. More concerning than difficulty
debugging i
From: Alan Modra
[ Upstream commit 56d20861c027498b5a1112b4f9f05b56d906fdda ]
Call Frame Information is used by gdb for back-traces and inserting
breakpoints on function return for the "finish" command. This failed
when inside __kernel_clock_gettime. More concerning than difficulty
debugging i
The actual io accessors (e.g. in_be32) implicitly add a volatile
qualifier to their address argument. Remove volatile from the struct
definition and the qe_ic_(read/write) helpers, in preparation for
switching from the ppc-specific io accessors to generic ones.
Signed-off-by: Rasmus Villemoes
---
Signed-off-by: Rasmus Villemoes
---
drivers/soc/fsl/qe/qe.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/fsl/qe/qe.c b/drivers/soc/fsl/qe/qe.c
index 417df7e19281..2a0e6e642776 100644
--- a/drivers/soc/fsl/qe/qe.c
+++ b/drivers/soc/fsl/qe/qe.c
@@ -378,8 +378,
Make it clear that these operate on big-endian registers (i.e. use the
iowrite*be primitives) before we introduce more uses of them and allow
the QE drivers to be built for platforms other than ppc32.
Signed-off-by: Rasmus Villemoes
---
drivers/net/wan/fsl_ucc_hdlc.c | 4 ++--
drivers/soc/fsl/q
The QUICC engine drivers use the powerpc-specific out_be32() etc. In
order to allow those drivers to build for other architectures, those
must be replaced by iowrite32be(). However, on powerpc, out_be32() is
a simple inline function while iowrite32be() is out-of-line. So in
order not to introduce a
There have been several attempts in the past few years to allow
building the QUICC engine drivers for platforms other than PPC. This
is yet another attempt.
v3 can be found here:
https://lore.kernel.org/lkml/20191101124210.14510-1-li...@rasmusvillemoes.dk/
v4 adds a some patches to fix (ab)use o
In preparation for allowing QE to be built for architectures other
than ppc, use the generic readx_poll_timeout_atomic() helper from
iopoll.h rather than the ppc-only spin_event_timeout().
Signed-off-by: Rasmus Villemoes
---
drivers/soc/fsl/qe/qe.c | 13 +++--
1 file changed, 7 insertion
In preparation for allowing to build QE support for architectures
other than PPC, replace the ppc-specific io accessors by the qe_io*
macros. Done via
$ spatch --sp-file io.cocci --in-place drivers/soc/fsl/qe/
where io.cocci is
@@
expression addr, val;
@@
- out_be32(addr, val)
+ qe_iowrite32be(v
Commit e5c5c8d23fef (soc/fsl/qe: only apply QE_General4 workaround on
affected SoCs) introduced use of pvr_version_is(), saying
The QE_General4 workaround is only valid for the MPC832x and MPC836x
SoCs. The other SoCs that embed a QUICC engine are not affected by this
hardware bug and
These includes are not actually needed, and asm/rheap.h and
sysdev/fsl_soc.h are PPC-specific, hence prevent compiling QE for
other architectures.
Signed-off-by: Rasmus Villemoes
---
drivers/soc/fsl/qe/qe.c| 5 -
drivers/soc/fsl/qe/qe_io.c | 2 --
2 files changed, 7 deletions(-)
diff --
high_active is only assigned to but never used. Remove it.
Signed-off-by: Rasmus Villemoes
---
drivers/soc/fsl/qe/qe_ic.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/soc/fsl/qe/qe_ic.c b/drivers/soc/fsl/qe/qe_ic.c
index 8c874372416b..4b03060d8079 100644
---
The *_ipic and *_mpic handlers are almost identical - the only
difference is that the latter end with an unconditional
chip->irq_eoi() call. Since IPIC does not have ->irq_eoi, we can
reduce some code duplication by calling irq_eoi conditionally.
This is similar to what is already done in mpc8xxx_
There's no point in registering with sysfs when that doesn't actually
allow any interaction with the device or driver (no uevents, no sysfs
files that provide information or allow configuration, no nothing).
Signed-off-by: Rasmus Villemoes
---
drivers/soc/fsl/qe/qe_ic.c | 31
Having to call qe_ic_init() from platform-specific code makes it
awkward to allow building the QE drivers for ARM. It's also a needless
duplication of code, and slightly error-prone: Instead of the caller
needing to know the details of whether the QUICC Engine High and QUICC
Engine Low are actually
This is now exactly the same as mpc83xx_ipic_init_IRQ, so just use
that directly.
Signed-off-by: Rasmus Villemoes
---
arch/powerpc/platforms/83xx/km83xx.c | 2 +-
arch/powerpc/platforms/83xx/misc.c| 7 ---
arch/powerpc/platforms/83xx/mpc832x_mds.c | 2 +-
arch/powerpc/platforms/
Since commit 302c059f2e7b (QE: use subsys_initcall to init qe),
mpc85xx_qe_init() has done nothing apart from possibly emitting a
pr_err(). As part of reducing the amount of QE-related code in
arch/powerpc/ (and eventually support QE on other architectures),
remove this low-hanging fruit.
Signed-o
These functions are only ever called through a function pointer, and
therefore it makes no sense for them to be "static inline" - gcc has
no choice but to emit a copy in each translation unit that takes the
address of one of these. Since they are now only referenced from
qe_ic.c, just make them loc
The qe_ic_cascade_{low,high}_mpic functions are now used as handlers
both when the interrupt parent is mpic as well as ipic, so remove the
_mpic suffix.
Signed-off-by: Rasmus Villemoes
---
drivers/soc/fsl/qe/qe_ic.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/driv
There are no current callers of these functions, and they use the
ppc-specific virq_to_hw(). So removing them gets us one step closer to
building QE support for ARM.
If the functionality is ever actually needed, the code can be dug out
of git and then adapted to work on all architectures, but for
This driver is currently PPC-only, and on powerpc, NO_IRQ is 0, so
this doesn't change functionality. However, not every architecture
defines NO_IRQ, and some define it as -1, so the detection of a failed
irq_of_parse_and_map() (which returns 0 on failure) would be wrong on
those. So to prepare for
These are only called from within qe_ic.c, so make them static.
Signed-off-by: Rasmus Villemoes
---
drivers/soc/fsl/qe/qe_ic.c | 4 ++--
include/soc/fsl/qe/qe_ic.h | 10 --
2 files changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/soc/fsl/qe/qe_ic.c b/drivers/soc/fsl/qe/qe
qe_ic_init() takes a flags parameter, but all callers (including the
sole remaining one) have always passed 0. So remove that parameter and
simplify the body accordingly. We still explicitly initialize the
Interrupt Configuration Register (CICR) to its reset value of
all-zeroes, just in case the bo
The public qe_ic.h header is no longer included by anything but
qe_ic.c. Merge both headers into qe_ic.c, and drop the unused
constants.
Signed-off-by: Rasmus Villemoes
---
drivers/soc/fsl/qe/qe_ic.c | 52 +++-
drivers/soc/fsl/qe/qe_ic.h | 99 -
Instead of manually doing of_get_property/of_find_property and reading
the value by assigning to a u32* or u64* and dereferencing, use the
of_property_read_* functions.
This make the code more readable, and more importantly, is required
for this to work correctly on little-endian platforms.
Signe
We need to apply be32_to_cpu to make this work correctly on
little-endian hosts.
Signed-off-by: Rasmus Villemoes
---
drivers/soc/fsl/qe/qe_io.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/soc/fsl/qe/qe_io.c b/drivers/soc/fsl/qe/qe_io.c
index 99aeb0
Signed-off-by: Rasmus Villemoes
---
drivers/soc/fsl/qe/qe_io.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/soc/fsl/qe/qe_io.c b/drivers/soc/fsl/qe/qe_io.c
index f6b10f38b2f4..99aeb01586bd 100644
--- a/drivers/soc/fsl/qe/qe_io.c
+++ b/drivers/soc/fsl/qe/qe_io
This is necessary for this to work on little-endian hosts.
Signed-off-by: Rasmus Villemoes
---
drivers/soc/fsl/qe/qe_io.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/soc/fsl/qe/qe_io.c b/drivers/soc/fsl/qe/qe_io.c
index 61dd8eb8c0fe..11ea08e97db7 100644
---
Some drivers, e.g. ucc_uart, need definitions from cpm.h. In order to
allow building those drivers for non-ppc based SOCs, move the header
to include/soc/fsl. For now, leave a trivial wrapper at the old
location so drivers can be updated one by one.
Signed-off-by: Rasmus Villemoes
---
arch/power
asm/cpm.h under arch/powerpc is now just a wrapper for including
soc/fsl/cpm.h. In order to make the qe.h header usable on other
architectures, use the latter path directly.
Signed-off-by: Rasmus Villemoes
---
include/soc/fsl/qe/qe.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --
This driver uses #defines from soc/fsl/cpm.h, so instead of relying on
some other header pulling that in, do that explicitly. This is
preparation for allowing this driver to build on ARM.
Signed-off-by: Rasmus Villemoes
---
drivers/tty/serial/ucc_uart.c | 1 +
1 file changed, 1 insertion(+)
dif
Some ARM-based SOCs (e.g. LS1021A) also have a QUICC engine. As
preparation for allowing this driver to build on ARM, replace the
ppc-specific in_be16() etc. by the qe_io* helpers. Done via
coccinelle.
Signed-off-by: Rasmus Villemoes
---
drivers/tty/serial/ucc_uart.c | 210 +-
The Soft UART hack is only needed for some PPC-based SOCs. To allow
building this driver for non-PPC, guard soft_uart_init() and its
helpers by CONFIG_PPC32, and use a no-op soft_uart_init() otherwise.
Signed-off-by: Rasmus Villemoes
---
drivers/tty/serial/ucc_uart.c | 17 -
1 fi
The "soft uart" mechanism is a workaround for a silicon bug which (as
far as I know) only affects some PPC-based SOCs.
The code that determines which microcode blob to request relies on
some powerpc-specific bits (e.g. the mfspr(SPRN_SVR) and hence also
the asm/reg.h header). This makes it a littl
For this to work correctly on little-endian hosts, don't access the
device-tree properties directly in native endianness, but use the
of_property_read_u32() helper.
Signed-off-by: Rasmus Villemoes
---
drivers/tty/serial/ucc_uart.c | 41 +++
1 file changed, 17 inse
The buf member of struct qe_bd is a __be32, so to make this work on
little-endian hosts, use be32_to_cpu when reading it.
Signed-off-by: Rasmus Villemoes
---
drivers/tty/serial/ucc_uart.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/ucc_uart.c b/dr
There are a number of problems with cpm_muram_alloc() and its
callers. Most callers assign the return value to some variable and
then use IS_ERR_VALUE to check for allocation failure. However, when
that variable is not sizeof(long), this leads to warnings - and it is
indeed broken to do e.g.
u32
Nobody uses the return value from cpm_muram_free, and functions that
free resources usually return void. One could imagine a use for a "how
much have I allocated" a la ksize(), but knowing how much one had
access to after the fact is useless.
Signed-off-by: Rasmus Villemoes
---
drivers/soc/fsl/q
This allows one to simplify callers since they can store a negative
value as a sentinel to indicate "this was never allocated" (or store
the -ENOMEM from an allocation failure) and then call cpm_muram_free()
unconditionally.
Signed-off-by: Rasmus Villemoes
---
drivers/soc/fsl/qe/qe_common.c | 3
cpm_muram_alloc_common() tries to support a kind of lazy
initialization - if the muram_pool has not been created yet, it calls
cpm_muram_init(). Now, cpm_muram_alloc_common() is always called under
spin_lock_irqsave(&cpm_muram_lock, flags);
and cpm_muram_init() does gen_pool_create() (whi
If the kmalloc() fails, we try to undo the gen_pool allocation we've
just done. Unfortunately, start has already been modified to subtract
the GENPOOL_OFFSET bias, so we're freeing something that very likely
doesn't exist in the gen_pool, meaning we hit the
kernel BUG at lib/genalloc.c:399!
Inte
When trying to build this for a 64-bit platform, one gets warnings
from using IS_ERR_VALUE on something which is not sizeof(long).
Instead, change the various *_offset fields to store a signed integer,
and simply check for a negative return from qe_muram_alloc(). Since
qe_muram_free() now accepts
Now that qe_muram_alloc() returns s32, adapt qe_sdma_init() and avoid
another few IS_ERR_VALUE() uses.
Signed-off-by: Rasmus Villemoes
---
drivers/soc/fsl/qe/qe.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/soc/fsl/qe/qe.c b/drivers/soc/fsl/qe/qe.c
index ec5
The sdma member of struct qe_immap is not at offset zero, so even if
qe_immr wasn't initialized yet (i.e. NULL), &qe_immr->sdma would not
be NULL.
Signed-off-by: Rasmus Villemoes
---
drivers/soc/fsl/qe/qe.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/soc/fsl/qe/qe.c b/drivers/s
When building this on a 64-bit platform gcc rightly warns that the
error checking is broken (-ENOMEM stored in an u32 does not compare
greater than (unsigned long)-MAX_ERRNO). Instead, change the
ucc_fast_[tr]x_virtual_fifo_base_offset members to s32 and use an
ordinary check-for-negative. Also, th
When building this on a 64-bit platform gcc rightly warns that the
error checking is broken (-ENOMEM stored in an u32 does not compare
greater than (unsigned long)-MAX_ERRNO). Instead, now that
qe_muram_alloc() returns s32, use that type to store the return value
and use standard kernel style "ret
When releasing the allocated muram resource, we rely on reading back
the offsets from the riptr/tiptr registers. But those registers are
__be16 (and we indeed write them using iowrite16be), so we can't just
read them back with a normal C dereference.
This is not currently a real problem, since for
Qiang Zhao points out that these offsets get written to 16-bit
registers, and there are some QE platforms with more than 64K
muram. So it is possible that qe_muram_alloc() gives us an allocation
that can't actually be used by the hardware, so detect and reject
that.
Reported-by: Qiang Zhao
Signed
Currently, QUICC_ENGINE depends on PPC32, so this in itself does not
change anything. In order to allow removing the PPC32 dependency from
QUICC_ENGINE and avoid allmodconfig build failures, add this explicit
dependency.
Signed-off-by: Rasmus Villemoes
---
drivers/net/ethernet/freescale/Kconfig
There are also ARM and ARM64 based SOCs with a QUICC Engine, and the
core QE code as well as net/wan/fsl_ucc_hdlc and tty/serial/ucc_uart
has now been modified to not rely on ppcisms.
So extend the architectures that can select QUICC_ENGINE, and add the
rather modest requirements of OF && HAS_IOME
When do COMPILE_TEST buiding for RTC_DRV_FSL_FTM_ALARM,
we get this warning:
WARNING: unmet direct dependencies detected for FSL_RCPM
Depends on [n]: PM_SLEEP [=y] && (ARM || ARM64)
Selected by [m]:
- RTC_DRV_FSL_FTM_ALARM [=m] && RTC_CLASS [=y] && (ARCH_LAYERSCAPE ||
SOC_LS1021A || COMPILE
Hi,
On 08/11/2019 21:02:13+0800, YueHaibing wrote:
> When do COMPILE_TEST buiding for RTC_DRV_FSL_FTM_ALARM,
> we get this warning:
>
> WARNING: unmet direct dependencies detected for FSL_RCPM
> Depends on [n]: PM_SLEEP [=y] && (ARM || ARM64)
> Selected by [m]:
> - RTC_DRV_FSL_FTM_ALARM [=m
This is a note to let you know that I've just added the patch titled
powerpc/book3s64/mm: Don't do tlbie fixup for some hardware revisions
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the
This is a note to let you know that I've just added the patch titled
powerpc/mm: Fixup tlbie vs mtpidr/mtlpidr ordering issue on POWER9
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the pa
This is a note to let you know that I've just added the patch titled
powerpc/mm: Fixup tlbie vs store ordering issue on POWER9
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
This is a note to let you know that I've just added the patch titled
selftests/powerpc: Add test case for tlbie vs mtpidr ordering issue
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the p
This is a note to let you know that I've just added the patch titled
selftests/powerpc: Fix compile error on tlbie_test due to newer gcc
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the p
This is a note to let you know that I've just added the patch titled
powerpc/book3s64/radix: Rename CPU_FTR_P9_TLBIE_BUG feature flag
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patc
From: Desnes A. Nunes do Rosario
commit 5b216ea1c40cf06eead15054c70e238c9bd4729e upstream.
Newer versions of GCC (>= 9) demand that the size of the string to be
copied must be explicitly smaller than the size of the destination.
Thus, the NULL char has to be taken into account on strncpy.
This
From: "Aneesh Kumar K.V"
commit a5d4b5891c2f1f865a2def1eb0030f534e77ff86 upstream.
On POWER9, under some circumstances, a broadcast TLB invalidation
might complete before all previous stores have drained, potentially
allowing stale stores from becoming visible after the invalidation.
This works
On little-endian 32-bit application running on 64-bit kernels,
the current vdso would read the wrong half of the xtime seconds
field. Change it to return the lower half like it does on
big-endian.
Signed-off-by: Arnd Bergmann
---
arch/powerpc/kernel/vdso32/gettimeofday.S | 2 +-
1 file changed,
I've gone through the remaining uses of time_t etc and come up with a
set of 90 patches of varying complexity and importance, to the point
of being able to remove the old time_t/timeval/timespec from the kernel
headers completely.
This set includes the eight patches that I think should be merged
r
On Fri, Nov 8, 2019 at 9:20 AM Alexandre Belloni
wrote:
>
> Hi,
>
> On 08/11/2019 21:02:13+0800, YueHaibing wrote:
> > When do COMPILE_TEST buiding for RTC_DRV_FSL_FTM_ALARM,
> > we get this warning:
> >
> > WARNING: unmet direct dependencies detected for FSL_RCPM
> > Depends on [n]: PM_SLEEP [=
This is a series of cleanups for the y2038 work, mostly intended
for namespace cleaning: the kernel defines the traditional
time_t, timeval and timespec types that often lead to y2038-unsafe
code. Even though the unsafe usage is mostly gone from the kernel,
having the types and associated functions
The gettimeofday() function in vdso uses the traditional 'timeval'
structure layout, which will be incompatible with future versions of
glibc on 32-bit architectures that use a 64-bit time_t.
This interface is problematic for y2038, when time_t overflows on 32-bit
architectures, but the plan so fa
As a preparation to stop using 'struct timespec' in the kernel,
change the powerpc vdso implementation:
- split up the vdso data definition to have equivalent members
for seconds and nanoseconds instead of an xtime structure
- use timespec64 as an intermediate for the xtime update
- change th
The time_t definition may differ between user space and kernel space,
so replace time_t with an unambiguous 'long' for the mips and sparc.
The same structures also contain 'off_t', which has the same problem,
so replace that as well on those two architectures and powerpc.
Signed-off-by: Arnd Berg
There are two structures based on time_t that conflict between libc and
kernel: timeval and timespec. Both are now renamed to __kernel_old_timeval
and __kernel_old_timespec.
For time_t, the old typedef is still __kernel_time_t. There is nothing
wrong with that name, but it would be nice to not use
All of the remaining syscalls that pass a timeval (gettimeofday, utime,
futimesat) can trivially be changed to pass a __kernel_old_timeval
instead, which has a compatible layout, but avoids ambiguity with
the timeval type in user space.
Signed-off-by: Arnd Bergmann
---
arch/powerpc/include/asm/a
On 10/31/19 12:39 PM, Daniel Axtens wrote:
> Daniel Axtens (4):
> kasan: support backing vmalloc space with real shadow memory
> kasan: add test for vmalloc
> fork: support VMAP_STACK with KASAN_VMALLOC
> x86/kasan: support KASAN_VMALLOC
>
> Documentation/dev-tools/kasan.rst | 63
The Flextimer alarm is primarily used as a wakeup source for system
power management. But it shouldn't select the power management driver
as they don't really have dependency of each other.
Also remove the default y as it is not a critical feature for the
systems.
Signed-off-by: Li Yang
---
dr
This patch series enables IOMMU support for pseries Secure VMs.
Tested using QEMU command line option:
"-device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x4,
iommu_platform=on,disable-modern=off,disable-legacy=on"
and
"-device virtio-blk-pci,scsi=off,bus=pci.0,
addr=0x5,drive=
The hypervisor needs to access the contents of the page holding the TCE
entries while setting up the TCE entries in the IOMMU's TCE table.
For SecureVMs, since this page is encrypted, the hypervisor cannot
access valid entries. Share the page with the hypervisor. This ensures
that the hypervisor s
Commit edea902c1c1e disabled dma_iommu_ops path, for secure VMs. The
rationale for disabling the dma_iommu_ops path, was to enable use of the
dma_direct path, which had inbuilt support for bounce-buffering through
SWIOTLB.
However dma_iommu_ops is functionally much richer. Depending on the
capabil
On Fri, Nov 8, 2019 at 7:05 AM Rasmus Villemoes
wrote:
>
> There are also ARM and ARM64 based SOCs with a QUICC Engine, and the
> core QE code as well as net/wan/fsl_ucc_hdlc and tty/serial/ucc_uart
> has now been modified to not rely on ppcisms.
>
> So extend the architectures that can select QUI
On Fri 2019-11-08 19:37:19, Sergey Senozhatsky wrote:
> On (19/11/06 09:35), Petr Mladek wrote:
> > I agree with all the other justification.
> >
> > I would add. The backtrace is really useful for debugging. It should
> > be possible to print it even in less critical situations.
>
> Hmm, I don't
On 11/6/19 8:34 PM, Peter Zijlstra wrote:
> On Wed, Nov 06, 2019 at 04:27:33PM +, Dmitry Safonov wrote:
[..]
>> Sorry, I should have tried to describe better.
>>
>> I'm trying to remove external users of console_loglevel by following
>> reasons:
>
> I suppose since all my machines have 'debug i
On 08.11.19 19:29, Dan Williams wrote:
On Fri, Nov 8, 2019 at 2:22 AM David Hildenbrand wrote:
On 08.11.19 08:14, David Hildenbrand wrote:
On 08.11.19 06:09, Dan Williams wrote:
On Thu, Nov 7, 2019 at 2:07 PM David Hildenbrand wrote:
On 07.11.19 19:22, David Hildenbrand wrote:
Am 07.1
On Fri, Nov 08, 2019 at 04:28:30PM +, Dmitry Safonov wrote:
> On 11/6/19 8:34 PM, Peter Zijlstra wrote:
> > On Wed, Nov 06, 2019 at 04:27:33PM +, Dmitry Safonov wrote:
> [..]
> >> Sorry, I should have tried to describe better.
> >>
> >> I'm trying to remove external users of console_logleve
On Fri, Nov 8, 2019 at 2:22 AM David Hildenbrand wrote:
>
> On 08.11.19 08:14, David Hildenbrand wrote:
> > On 08.11.19 06:09, Dan Williams wrote:
> >> On Thu, Nov 7, 2019 at 2:07 PM David Hildenbrand wrote:
> >>>
> >>> On 07.11.19 19:22, David Hildenbrand wrote:
>
>
> > Am 07.11.20
On 11/8/19 5:30 PM, Russell King - ARM Linux admin wrote:
> On Fri, Nov 08, 2019 at 04:28:30PM +, Dmitry Safonov wrote:
[..]
>>
>> Well, the use-case for lower log-level is that everything goes into logs
>> (/var/log/dmesg or /var/log/messages whatever rsyslog has settting).
>>
>> That has it
On Wed, Nov 06, 2019 at 03:27:45PM +0800, Shengjiu Wang wrote:
> Audmix support two substream, When two substream start
> to run, the trigger function may be called by two substream
> in same time, that the priv->tdms may be updated wrongly.
>
> The expected priv->tdms is 0x3, but sometimes the
>
90 matches
Mail list logo
