On 2023-02-16 13:38:57 Thu, Athira Rajeev wrote:
> Add a function dt_find_by_name_substr() that returns the child node if
> it matches till first occurence at "@" of a given name, otherwise NULL.
> This is helpful for cases with node name like: "name@addr". In
> scenarios where nodes are added with
Le 22/02/2023 à 19:22, Pali Rohár a écrit :
> On Wednesday 22 February 2023 15:42:47 Christophe Leroy wrote:
>> This patch series unifies all P2020 boards and machine descriptions into
>> one generic unified P2020 machine description. With this generic machine
>> description, kernel can boot on a
Randy Dunlap writes:
> LEDS_TRIGGER_DISK depends on ATA, so selecting LEDS_TRIGGER_DISK
> when ATA is not set/enabled causes a Kconfig warning:
>
> WARNING: unmet direct dependencies detected for LEDS_TRIGGER_DISK
> Depends on [n]: NEW_LEDS [=y] && LEDS_TRIGGERS [=y] && ATA [=n]
> Selected by
Christophe Leroy writes:
> Le 22/02/2023 à 19:22, Pali Rohár a écrit :
>> On Wednesday 22 February 2023 15:42:47 Christophe Leroy wrote:
>>> This patch series unifies all P2020 boards and machine descriptions into
>>> one generic unified P2020 machine description. With this generic machine
>>> des
On Thu, 23 Feb 2023 03:58:47 +,
Yu Zhao wrote:
>
> On Fri, Feb 17, 2023 at 2:00 AM Marc Zyngier wrote:
> >
> > On Fri, 17 Feb 2023 04:21:28 +,
> > Yu Zhao wrote:
> > >
> > > On Thu, Feb 16, 2023 at 9:12 PM Yu Zhao wrote:
> > > >
> > > > This patch adds kvm_arch_test_clear_young() for t
On Thu, Feb 23, 2023 at 2:03 AM Marc Zyngier wrote:
>
> On Thu, 23 Feb 2023 03:58:47 +,
> Yu Zhao wrote:
> >
> > On Fri, Feb 17, 2023 at 2:00 AM Marc Zyngier wrote:
> > >
> > > On Fri, 17 Feb 2023 04:21:28 +,
> > > Yu Zhao wrote:
> > > >
> > > > On Thu, Feb 16, 2023 at 9:12 PM Yu Zhao
Kautuk Consul writes:
>
>> You are correct, the patch is wrong because it fails to account for IO
>> accesses.
>
> Okay, I looked at the PowerPC ISA and found:
> "The memory barrier provides an ordering function for the storage accesses
> caused by Load, Store,and dcbz instructions that are exec
On Fri, Feb 10, 2023 at 01:20:22PM -0700, Tom Saeger wrote:
> From: "H.J. Lu"
>
> commit 84d5f77fc2ee4e010c2c037750e32f06e55224b0 upstream.
>
> In the x86 kernel, .exit.text and .exit.data sections are discarded at
> runtime, not by the linker. Add RUNTIME_DISCARD_EXIT to generic DISCARDS
> and
On Fri, Feb 10, 2023 at 01:18:40PM -0700, Tom Saeger wrote:
> From: Masahiro Yamada
>
> commit 99cb0d917ffa1ab628bb67364ca9b162c07699b1 upstream.
>
> Dennis Gilmore reports that the BuildID is missing in the arm64 vmlinux
> since commit 994b7ac1697b ("arm64: remove special treatment for the
> li
Hi Arnd,
On Wed, Feb 15, 2023 at 2:05 PM Arnd Bergmann wrote:
>
> On Wed, Feb 15, 2023, at 13:59, Russell King (Oracle) wrote:
> > On Tue, Feb 14, 2023 at 08:49:04AM +0100, Alexandre Ghiti wrote:
> >> From: Palmer Dabbelt
> >>
> >> As far as I can tell this is not used by userspace and thus shou
On Fri, Feb 10, 2023 at 01:17:15PM -0700, Tom Saeger wrote:
> Keep 6.1 in-sync with Build ID fixes.
>
> I've build tested this on {x86_64, arm64, riscv, powerpc, s390, sh}.
>
> Changes for v2:
> - include 1/7 2348e6bf4421 ("riscv: remove special treatment for the link
> order of head.o")
> - inc
On Fri, Feb 10, 2023 at 01:18:39PM -0700, Tom Saeger wrote:
> Build ID is missing for arm64 with CONFIG_MODVERSIONS=y using ld >= 2.36
> on 5.4, 5.10, and 5.15
>
> Backport BuildID fixes.
I do not understand why you are applying patches from 6.2 that "fix"
something that is not in this kernel (or
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
merge
branch HEAD: cf67b423ea80af8345efb51db9738f170955ce06 Automatic merge of
'next' into merge (2023-02-22 23:05)
elapsed time: 1319m
configs tested: 84
configs skipped: 3
The following configs have been built su
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
next
branch HEAD: f82cdc37c4bd4ba905bf99ade9782a639b5c12e9 powerpc/pseries: Avoid
hcall in plpks_is_available() on non-pseries
elapsed time: 1370m
configs tested: 73
configs skipped: 3
The following configs have be
Hi all,
This series split out second half of my previous series
"[PATCH 0/4] MIPS DMA coherence fixes".
It intends to use dma_default_coherent to determine the default coherency of
devicetree probed devices instead of hardcoding it with Kconfig options.
For some MIPS systems, dma_default_coheren
DT-based MIPS doesn't use OF_DMA_DEFAULT_COHERENT, but
might override the system-wide default at runtime.
Use dma_default_coherent to override default coherence for
MIPS.
Signed-off-by: Jiaxun Yang
---
drivers/of/address.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/of/a
dma_default_coherent was decleared unconditionally at kernel/dma/mapping.c
but only decleared when any of non-coherent options is enabled in dma-map-ops.h.
Guard the declaration in mapping.c with non-coherent options and provide
a fallback definition.
Signed-off-by: Jiaxun Yang
---
include/linu
Provide a kconfig option to allow arches to manipulate default
value of dma_default_coherent in Kconfig.
Signed-off-by: Jiaxun Yang
---
kernel/dma/Kconfig | 3 +++
kernel/dma/mapping.c | 2 +-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
For riscv our assumption is unless a device states it is non-coherent,
we take it to be DMA coherent.
Select ARCH_DMA_DEFAULT_COHERENT to ensure dma_default_coherent
is always initialized to true.
Signed-off-by: Jiaxun Yang
---
arch/riscv/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --gi
As for now all arches have dma_default_coherent matched with default
DMA coherency for of devices, so there is no need to have a standalone
config option.
Note for PowerPC: CONFIG_OF_DMA_DEFUALT_COHERENT was only selected when
CONFIG_NOT_COHERENT_CACHE is false, in this case dma_default_coherent w
On Thu, Feb 23, 2023, at 10:54, Alexandre Ghiti wrote:
> On Wed, Feb 15, 2023 at 2:05 PM Arnd Bergmann wrote:
>>
>> On Wed, Feb 15, 2023, at 13:59, Russell King (Oracle) wrote:
>> > On Tue, Feb 14, 2023 at 08:49:04AM +0100, Alexandre Ghiti wrote:
>> >> From: Palmer Dabbelt
>> >>
>> >> As far as I
On Thu, Feb 23, 2023 at 2:09 PM Arnd Bergmann wrote:
>
> On Thu, Feb 23, 2023, at 10:54, Alexandre Ghiti wrote:
> > On Wed, Feb 15, 2023 at 2:05 PM Arnd Bergmann wrote:
> >>
> >> On Wed, Feb 15, 2023, at 13:59, Russell King (Oracle) wrote:
> >> > On Tue, Feb 14, 2023 at 08:49:04AM +0100, Alexandr
On Wed, Feb 15, 2023 at 09:17:31PM -0800, Suren Baghdasaryan wrote:
> Decisions about whether VMAs can be merged, split or expanded must be
> made while VMAs are protected from the changes which can affect that
> decision. For example, merge_vma uses vma->anon_vma in its decision
Did you mean vma_
On Thu, Feb 23, 2023 at 02:51:27PM +, Hyeonggon Yoo wrote:
> On Wed, Feb 15, 2023 at 09:17:31PM -0800, Suren Baghdasaryan wrote:
> > Decisions about whether VMAs can be merged, split or expanded must be
> > made while VMAs are protected from the changes which can affect that
> > decision. For e
Randy Dunlap writes:
> The RTAS work area allocator uses code that is built by
> GENERIC_ALLOCATOR, so the PSERIES Kconfig should select the
> required Kconfig symbol to fix multiple build errors.
>
> powerpc64-linux-ld: arch/powerpc/platforms/pseries/rtas-work-area.o: in
> function `.rtas_work_a
https://bugzilla.kernel.org/show_bug.cgi?id=216095
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Status|NEW |RESOLVED
Resol
On 2/23/23 00:56, Michael Ellerman wrote:
> Randy Dunlap writes:
>> LEDS_TRIGGER_DISK depends on ATA, so selecting LEDS_TRIGGER_DISK
>> when ATA is not set/enabled causes a Kconfig warning:
>>
>> WARNING: unmet direct dependencies detected for LEDS_TRIGGER_DISK
>> Depends on [n]: NEW_LEDS [=y
On Wed, Feb 22, 2023, Yu Zhao wrote:
> On Fri, Feb 17, 2023 at 9:27 AM Sean Christopherson wrote:
> >
> > On Thu, Feb 16, 2023, Yu Zhao wrote:
> > > diff --git a/arch/x86/include/asm/kvm_host.h
> > > b/arch/x86/include/asm/kvm_host.h
> > > index 6aaae18f1854..d2995c9e8f07 100644
> > > --- a/arch/
On Thu, Feb 16, 2023, Yu Zhao wrote:
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 9c60384b5ae0..1b465df4a93d 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -875,6 +875,63 @@ static int kvm_mmu_notifier_clear_young(struct
> mmu_notifier *mn,
> return k
LEDS_TRIGGER_DISK depends on ATA, so selecting LEDS_TRIGGER_DISK
when ATA is not set/enabled causes a Kconfig warning:
WARNING: unmet direct dependencies detected for LEDS_TRIGGER_DISK
Depends on [n]: NEW_LEDS [=y] && LEDS_TRIGGERS [=y] && ATA [=n]
Selected by [y]:
- ADB_PMU_LED_DISK [=y] &&
On Thu, Feb 23, 2023 at 10:09 AM Sean Christopherson wrote:
>
> On Wed, Feb 22, 2023, Yu Zhao wrote:
> > On Fri, Feb 17, 2023 at 9:27 AM Sean Christopherson
> > wrote:
> > >
> > > On Thu, Feb 16, 2023, Yu Zhao wrote:
> > > > diff --git a/arch/x86/include/asm/kvm_host.h
> > > > b/arch/x86/includ
On Thu, Feb 16, 2023, Yu Zhao wrote:
> +static bool kvm_mmu_notifier_test_clear_young(struct mmu_notifier *mn,
> struct mm_struct *mm,
> + unsigned long start, unsigned
> long end,
> + unsigned long *bitmap)
> +{
On Thu, Feb 23, 2023 at 10:14 AM Sean Christopherson wrote:
>
> On Thu, Feb 16, 2023, Yu Zhao wrote:
> > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> > index 9c60384b5ae0..1b465df4a93d 100644
> > --- a/virt/kvm/kvm_main.c
> > +++ b/virt/kvm/kvm_main.c
> > @@ -875,6 +875,63 @@ static in
On Thu, Feb 16, 2023, Yu Zhao wrote:
> An existing selftest can quickly demonstrate the effectiveness of this
> patch. On a generic workstation equipped with 128 CPUs and 256GB DRAM:
Not my area of maintenance, but a non-existent changelog (for all intents and
purposes) for a change of this size a
On Thu, Feb 23, 2023 at 10:51:45AM +0100, Greg Kroah-Hartman wrote:
> On Fri, Feb 10, 2023 at 01:18:40PM -0700, Tom Saeger wrote:
> > From: Masahiro Yamada
> >
> > commit 99cb0d917ffa1ab628bb67364ca9b162c07699b1 upstream.
> >
> > Dennis Gilmore reports that the BuildID is missing in the arm64 vm
On Thu, Feb 23, 2023 at 10:55:39AM +0100, Greg Kroah-Hartman wrote:
> On Fri, Feb 10, 2023 at 01:18:39PM -0700, Tom Saeger wrote:
> > Build ID is missing for arm64 with CONFIG_MODVERSIONS=y using ld >= 2.36
> > on 5.4, 5.10, and 5.15
> >
> > Backport BuildID fixes.
>
> I do not understand why you
On Thu, Feb 23, 2023 at 10:43 AM Sean Christopherson wrote:
>
> On Thu, Feb 16, 2023, Yu Zhao wrote:
> > An existing selftest can quickly demonstrate the effectiveness of this
> > patch. On a generic workstation equipped with 128 CPUs and 256GB DRAM:
>
> Not my area of maintenance, but a non-exist
On Thu, Feb 23, 2023, Yu Zhao wrote:
> On Thu, Feb 23, 2023 at 10:09 AM Sean Christopherson
> wrote:
> > > I'll take a look at that series. clear_bit() probably won't cause any
> > > practical damage but is technically wrong because, for example, it can
> > > end up clearing the A-bit in a non-le
On Thu, Feb 23, 2023 at 11:24 AM Sean Christopherson wrote:
>
> On Thu, Feb 23, 2023, Yu Zhao wrote:
> > On Thu, Feb 23, 2023 at 10:09 AM Sean Christopherson
> > wrote:
> > > > I'll take a look at that series. clear_bit() probably won't cause any
> > > > practical damage but is technically wrong
On Thu, Feb 23, 2023, Yu Zhao wrote:
> On Thu, Feb 23, 2023 at 11:24 AM Sean Christopherson
> wrote:
> >
> > On Thu, Feb 23, 2023, Yu Zhao wrote:
> > > On Thu, Feb 23, 2023 at 10:09 AM Sean Christopherson
> > > wrote:
> > > > > I'll take a look at that series. clear_bit() probably won't cause a
On Thu, Feb 23, 2023 at 11:47 AM Sean Christopherson wrote:
>
> On Thu, Feb 23, 2023, Yu Zhao wrote:
> > On Thu, Feb 23, 2023 at 11:24 AM Sean Christopherson
> > wrote:
> > >
> > > On Thu, Feb 23, 2023, Yu Zhao wrote:
> > > > On Thu, Feb 23, 2023 at 10:09 AM Sean Christopherson
> > > > wrote:
On Thu, Feb 23, 2023 at 10:50:22AM +0100, Greg Kroah-Hartman wrote:
> On Fri, Feb 10, 2023 at 01:20:22PM -0700, Tom Saeger wrote:
> > From: "H.J. Lu"
> >
> > commit 84d5f77fc2ee4e010c2c037750e32f06e55224b0 upstream.
> >
> > In the x86 kernel, .exit.text and .exit.data sections are discarded at
>
On Thu, Feb 23, 2023, Yu Zhao wrote:
> On Thu, Feb 23, 2023 at 10:43 AM Sean Christopherson
> wrote:
> >
> > On Thu, Feb 16, 2023, Yu Zhao wrote:
> > > kswapd (MGLRU before)
> > > 100.00% balance_pgdat
> > > 100.00% shrink_node
> > > 100.00% shrink_one
> > > 99.97
On Thu, Feb 23, 2023, Yu Zhao wrote:
> On Thu, Feb 23, 2023 at 11:47 AM Sean Christopherson
> wrote:
> >
> > On Thu, Feb 23, 2023, Yu Zhao wrote:
> > > On Thu, Feb 23, 2023 at 11:24 AM Sean Christopherson
> > > wrote:
> > > >
> > > > On Thu, Feb 23, 2023, Yu Zhao wrote:
> > > > > On Thu, Feb 23
On Thu, Feb 23, 2023 at 12:21 PM Sean Christopherson wrote:
>
> On Thu, Feb 23, 2023, Yu Zhao wrote:
> > On Thu, Feb 23, 2023 at 11:47 AM Sean Christopherson
> > wrote:
> > >
> > > On Thu, Feb 23, 2023, Yu Zhao wrote:
> > > > On Thu, Feb 23, 2023 at 11:24 AM Sean Christopherson
> > > > wrote:
On Thu, Feb 23, 2023 at 12:11 PM Sean Christopherson wrote:
>
> On Thu, Feb 23, 2023, Yu Zhao wrote:
> > On Thu, Feb 23, 2023 at 10:43 AM Sean Christopherson
> > wrote:
> > >
> > > On Thu, Feb 16, 2023, Yu Zhao wrote:
> > > > kswapd (MGLRU before)
> > > > 100.00% balance_pgdat
> > > >
On Thu, Feb 23, 2023, Yu Zhao wrote:
> On Thu, Feb 23, 2023 at 12:11 PM Sean Christopherson
> wrote:
> >
> > On Thu, Feb 23, 2023, Yu Zhao wrote:
> > > > As alluded to in patch 1, unless batching the walks even if KVM does
> > > > _not_ support
> > > > a lockless walk is somehow _worse_ than usi
* Suren Baghdasaryan [230216 00:18]:
> Page fault handlers might need to fire MMU notifications while a new
> notifier is being registered. Modify mm_take_all_locks to write-lock all
> VMAs and prevent this race with page fault handlers that would hold VMA
> locks. VMAs are locked before i_mmap_rw
Can we change this to active/inactive? I think there is potential for
reusing this functionality to even larger degrees and that name would
fit better and would still make sense in this context.
ie: vma_mark_active() and vma_mark_inactive() ?
* Suren Baghdasaryan [230216 00:18]:
> Per-vma loc
On Thu, Feb 23, 2023 at 12:58 PM Sean Christopherson wrote:
>
> On Thu, Feb 23, 2023, Yu Zhao wrote:
> > On Thu, Feb 23, 2023 at 12:11 PM Sean Christopherson
> > wrote:
> > >
> > > On Thu, Feb 23, 2023, Yu Zhao wrote:
> > > > > As alluded to in patch 1, unless batching the walks even if KVM does
Reviewed-by: Liam R. Howlett
* Suren Baghdasaryan [230216 00:18]:
> vma_expand and vma_shrink change VMA boundaries. Expansion might also
> result in freeing of an adjacent VMA. Write-lock affected VMAs to prevent
> concurrent page faults.
>
> Signed-off-by: Suren Baghdasaryan
> ---
> mm/mmap
On Thu, Feb 23, 2023, Yu Zhao wrote:
> On Thu, Feb 23, 2023 at 12:58 PM Sean Christopherson
> wrote:
> >
> > On Thu, Feb 23, 2023, Yu Zhao wrote:
> > > On Thu, Feb 23, 2023 at 12:11 PM Sean Christopherson
> > > wrote:
> > > >
> > > > On Thu, Feb 23, 2023, Yu Zhao wrote:
> > > > > > As alluded t
Wait, I figured a better place to do this.
init_multi_vma_prep() should vma_start_write() on any VMA that is passed
in.. that we we catch any modifications here & in vma_merge(), which I
think is missed in this patch set?
* Liam R. Howlett [230223 15:20]:
> Reviewed-by: Liam R. Howlett
>
>
On Thu, Feb 23, 2023 at 12:06 PM Liam R. Howlett
wrote:
>
> * Suren Baghdasaryan [230216 00:18]:
> > Page fault handlers might need to fire MMU notifications while a new
> > notifier is being registered. Modify mm_take_all_locks to write-lock all
> > VMAs and prevent this race with page fault han
On Thu, Feb 23, 2023 at 12:08 PM Liam R. Howlett
wrote:
>
>
> Can we change this to active/inactive? I think there is potential for
> reusing this functionality to even larger degrees and that name would
> fit better and would still make sense in this context.
>
> ie: vma_mark_active() and vma_ma
On Thu, Feb 23, 2023 at 1:29 PM Sean Christopherson wrote:
>
> On Thu, Feb 23, 2023, Yu Zhao wrote:
> > On Thu, Feb 23, 2023 at 12:58 PM Sean Christopherson
> > wrote:
> > >
> > > On Thu, Feb 23, 2023, Yu Zhao wrote:
> > > > On Thu, Feb 23, 2023 at 12:11 PM Sean Christopherson
> > > > wrote:
>
On Thu, Feb 23, 2023, Yu Zhao wrote:
> On Thu, Feb 23, 2023 at 10:14 AM Sean Christopherson
> wrote:
> >
> > On Thu, Feb 16, 2023, Yu Zhao wrote:
> > > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> > > index 9c60384b5ae0..1b465df4a93d 100644
> > > --- a/virt/kvm/kvm_main.c
> > > +++ b/
On Thu, Feb 23, 2023 at 12:28 PM Liam R. Howlett
wrote:
>
>
> Wait, I figured a better place to do this.
>
> init_multi_vma_prep() should vma_start_write() on any VMA that is passed
> in.. that we we catch any modifications here & in vma_merge(), which I
> think is missed in this patch set?
Hmm.
On 22.02.2023 18:04, Peter Zijlstra wrote:
On Wed, Jan 18, 2023 at 04:35:22PM +0100, Andrzej Hajda wrote:
Andrzej Hajda (7):
arch: rename all internal names __xchg to __arch_xchg
linux/include: add non-atomic version of xchg
arch/*/uprobes: simplify arch_uretprobe_hijack_return_addr
On Thu, Feb 23, 2023 at 11:36:43AM +, Jiaxun Yang wrote:
> For riscv our assumption is unless a device states it is non-coherent,
> we take it to be DMA coherent.
>
> Select ARCH_DMA_DEFAULT_COHERENT to ensure dma_default_coherent
> is always initialized to true.
>
> Signed-off-by: Jiaxun Yan
* Suren Baghdasaryan [230223 16:16]:
> On Thu, Feb 23, 2023 at 12:28 PM Liam R. Howlett
> wrote:
> >
> >
> > Wait, I figured a better place to do this.
> >
> > init_multi_vma_prep() should vma_start_write() on any VMA that is passed
> > in.. that we we catch any modifications here & in vma_merge(
On Thu, Feb 23, 2023 at 5:46 PM Liam R. Howlett wrote:
>
> * Suren Baghdasaryan [230223 16:16]:
> > On Thu, Feb 23, 2023 at 12:28 PM Liam R. Howlett
> > wrote:
> > >
> > >
> > > Wait, I figured a better place to do this.
> > >
> > > init_multi_vma_prep() should vma_start_write() on any VMA that
On Mon, 20 Feb 2023 09:04:35 +0100, Pali Rohár wrote:
> Due to CPLD firmware bugs, set CPLD syscon-reboot priority level to 64
> (between rstcr and watchdog) to ensure that rstcr's global-utilities reset
> method which is preferred stay as default one, and to ensure that CPLD
> syscon-reboot is mor
On Wed, 22 Feb 2023 13:17:08 +1100, Russell Currey wrote:
> plpks_is_available() can be called on any platform via kexec but calls
> _plpks_get_config() which makes a hcall, which will only work on pseries.
> Fix this by returning early in plpks_is_available() if hcalls aren't
> possible.
>
>
Ap
On Sat, 18 Feb 2023 10:28:50 +0100, Christophe Leroy wrote:
> Kernel test robot reports:
>
> arch/powerpc/mm/nohash/e500.c:314:21: warning: no previous prototype for
> 'relocate_init' [-Wmissing-prototypes]
> 314 | notrace void __init relocate_init(u64 dt_ptr, phys_addr_t start)
>
On Thu, Feb 23, 2023 at 11:53:42AM -0600, Tom Saeger wrote:
> On Thu, Feb 23, 2023 at 10:51:45AM +0100, Greg Kroah-Hartman wrote:
> > On Fri, Feb 10, 2023 at 01:18:40PM -0700, Tom Saeger wrote:
> > > From: Masahiro Yamada
> > >
> > > commit 99cb0d917ffa1ab628bb67364ca9b162c07699b1 upstream.
> > >
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi Linus,
Please pull powerpc updates for 6.3:
The following changes since commit 88603b6dc419445847923fcb7fe5080067a30f98:
Linux 6.2-rc2 (2023-01-01 13:53:16 -0800)
are available in the git repository at:
https://git.kernel.org/pub/scm/linu
There's code in prom_instantiate_sml() to do a "SML handover" (Stored
Measurement Log) from OF to Linux, before Linux shuts down Open
Firmware.
This involves creating a buffer to hold the SML, and creating two device
tree properties to record its base address and size. The kernel then
later reads
The TPM code in prom_init.c creates a small buffer of memory to store
the TPM's SML (Stored Measurement Log). It's communicated to Linux via
the linux,sml-base/size device tree properties of the TPM node.
When kexec'ing that buffer can be overwritten, or when kdump'ing it may
not be mapped by the
Add a firmware feature flag, FW_FEATURE_PLPKS, to indicate availability of
Platform KeyStore related hcalls.
Check this flag in plpks_is_available() and pseries_plpks_init() before
trying to make an hcall.
Suggested-by: Michael Ellerman
Signed-off-by: Andrew Donnellan
---
arch/powerpc/include/
70 matches
Mail list logo
