These counter registers are part of register list,
add them to complete the register map
- DMAC counter control registers
- Data path Timestamp counter register
- Data path bit counter register
- Data path bit count timestamp register
- Data path bit read timestamp register
Signed-off-by: Shengji
On Thu, Oct 27, 2022 at 04:07:18PM -0700, Palmer Dabbelt wrote:
> On Fri, 14 Oct 2022 08:58:43 PDT (-0700), ajo...@ventanamicro.com wrote:
> > Commit 78e5a3399421 ("cpumask: fix checking valid cpu range") has
> > started issuing warnings[*] when cpu indices equal to nr_cpu_ids - 1
> > are passed to
On Fri, Oct 14, 2022 at 05:58:45PM +0200, Andrew Jones wrote:
> Commit 78e5a3399421 ("cpumask: fix checking valid cpu range") has
> started issuing warnings[*] when cpu indices equal to nr_cpu_ids - 1
> are passed to cpumask_next* functions. seq_read_iter() and cpuinfo's
> start and next seq operat
From: Anshuman Khandual
The entire scheme of deferred TLB flush in reclaim path rests on the
fact that the cost to refill TLB entries is less than flushing out
individual entries by sending IPI to remote CPUs. But architecture
can have different ways to evaluate that. Hence apart from checking
TT
From: Barry Song
on x86, batched and deferred tlb shootdown has lead to 90%
performance increase on tlb shootdown. on arm64, HW can do
tlb shootdown without software IPI. But sync tlbi is still
quite expensive.
Even running a simplest program which requires swapout can
prove this is true,
#incl
From: Yicong Yang
Though ARM64 has the hardware to do tlb shootdown, the hardware
broadcasting is not free.
A simplest micro benchmark shows even on snapdragon 888 with only
8 cores, the overhead for ptep_clear_flush is huge even for paging
out one page mapped by only one process:
5.36% a.out
This patchset supports MICFIL on i.MX93 platform.
Chancel Liu (3):
ASoC: dt-bindings: fsl,micfil: Add compatible string for i.MX93
platform
ASoC: fsl_micfil: Add support for i.MX93 platform
ASoC: fsl_micfil: Add support when using eDMA
.../devicetree/bindings/sound/fsl,micfil.yaml
Add compatible string "fsl,imx93-micfil" for i.MX93 platform
Signed-off-by: Chancel Liu
---
Documentation/devicetree/bindings/sound/fsl,micfil.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/sound/fsl,micfil.yaml
b/Documentation/devicetree/bindings/sou
Add compatible string and specific soc data to support MICFIL on i.MX93
platform.
Signed-off-by: Chancel Liu
---
sound/soc/fsl/fsl_micfil.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/sound/soc/fsl/fsl_micfil.c b/sound/soc/fsl/fsl_micfil.c
index eeaa75fb9196..b8a9504441df 100644
On i.MX93 platform MICFIL uses eDMA. The maxburst should be set to the
number of channels in eDMA multiple FIFO mode.
Signed-off-by: Chancel Liu
---
sound/soc/fsl/fsl_micfil.c | 4
1 file changed, 4 insertions(+)
diff --git a/sound/soc/fsl/fsl_micfil.c b/sound/soc/fsl/fsl_micfil.c
index b8
On Fri, 7 Oct 2022 00:04:09 +1000, Nicholas Piggin wrote:
> These are several fixes for regressions and bugs that can crash
> the host.
>
> Thanks,
> Nick
>
> Nicholas Piggin (4):
> KVM: PPC: BookS PR-KVM and BookE do not support context tracking
> powerpc/64s/interrupt: Perf NMI should not t
On Fri, 14 Oct 2022 09:07:08 +1000, Nicholas Piggin wrote:
> Add lockdep annotation for the HPTE bit-spinlock. Modern systems don't
> take the tlbie lock, so this shows up some of the same lockdep warnings
> that were being reported by the ppc970. And they're not taken in exactly
> the same places
On Sat, 22 Oct 2022 15:22:07 +1000, Nicholas Piggin wrote:
> Commit a4cb3651a1743 ("powerpc/64s/interrupt: Fix lost interrupts when
> returning to soft-masked context") fixed the problem of pending irqs
> pending cleared when clearing the HARD_DIS bit, but then it didn't clear
> the bit at all. Thi
On Fri, 14 Oct 2022 13:07:27 +1000, Nicholas Piggin wrote:
> These are several fixes for regressions and crash bugs. Since v1
> I cut down the fixes to a minimum.
>
> Thanks,
> Nick
>
> Nicholas Piggin (2):
> KVM: PPC: BookS PR-KVM and BookE do not support context tracking
> powerpc/64/interr
On Fri, 14 Oct 2022 01:16:45 +1000, Nicholas Piggin wrote:
> apply_to_page_range on kernel pages does not disable preemption, which
> is a requirement for hash's lazy mmu mode, which keeps track of the
> TLBs to flush with a per-cpu array.
>
>
Applied to powerpc/fixes.
[1/3] powerpc/64s: Disabl
Yicong Yang writes:
> On 2022/10/27 22:19, Punit Agrawal wrote:
>>
>> [ Apologies for chiming in late in the conversation ]
>>
>> Anshuman Khandual writes:
>>
>>> On 9/28/22 05:53, Barry Song wrote:
On Tue, Sep 27, 2022 at 10:15 PM Yicong Yang wrote:
>
> On 2022/9/27 14:16, Ansh
Anshuman Khandual writes:
> On 10/28/22 03:25, Barry Song wrote:
>> On Fri, Oct 28, 2022 at 3:19 AM Punit Agrawal
>> wrote:
>>>
>>> [ Apologies for chiming in late in the conversation ]
>>>
>>> Anshuman Khandual writes:
>>>
On 9/28/22 05:53, Barry Song wrote:
> On Tue, Sep 27, 2022 at
Commit 1e688dd2a3d675 ("powerpc/bug: Provide better flexibility to
WARN_ON/__WARN_FLAGS() with asm goto") updated __WARN_FLAGS() to use asm
goto, and added a call to 'unreachable()' after the asm goto for optimal
code generation. With CONFIG_OBJTOOL enabled, 'annotate_unreachable()'
statement in 'u
This patchset enables and implements objtool --mcount
option on powerpc. This applies atop powerpc/merge branch.
Changelog:
v5:
* Patch 02/16 - Add Reviewed-by tag from Christophe Leroy
* Patch 03/16 - Fix merge conflicts with latest powerpc/merge branch
* Patch 06/16 - Files arch/powerpc
In a subsequent patch, we would want to annotate powerpc assembly functions
with SYM_FUNC_START_LOCAL macro. This macro depends on __ALIGN macro.
The default expansion of __ALIGN macro is:
#define __ALIGN .align 4,0x90
So, override __ALIGN and __ALIGN_STR macros to use the same align
Objtool throws unannotated intra-function call warnings in the following
assembly files:
arch/powerpc/kernel/vector.o: warning: objtool: .text+0x53c: unannotated
intra-function call
arch/powerpc/kvm/book3s_hv_rmhandlers.o: warning: objtool: .text+0x60:
unannotated intra-function call
arch/power
objtool throws the following unannotated intra-function call warnings:
arch/powerpc/kernel/entry_64.o: warning: objtool: .text+0x4: unannotated
intra-function call
arch/powerpc/kvm/book3s_hv_rmhandlers.o: warning: objtool: .text+0xe64:
unannotated intra-function call
arch/powerpc/kvm/book3s_hv_rm
With objtool enabled, below warnings are seen when trying to build:
drivers/crypto/vmx/aesp8-ppc.o: warning: objtool: aes_p8_set_encrypt_key+0x44:
unannotated intra-function call
drivers/crypto/vmx/aesp8-ppc.o: warning: objtool: .text+0x2448: unannotated
intra-function call
drivers/crypto/vmx/aes
From: Christophe Leroy
Fix several annotations in assembly files on PPC32.
Tested-by: Naveen N. Rao
Reviewed-by: Naveen N. Rao
Acked-by: Josh Poimboeuf
Signed-off-by: Christophe Leroy
[Sathvika Vasireddy: Changed subject line from "objtool/powerpc: Activate
objtool on PPC32" to "powerpc: Fix
Do not run objtool on VDSO files, by using OBJECT_FILES_NON_STANDARD.
Suggested-by: Christophe Leroy
Tested-by: Naveen N. Rao
Reviewed-by: Naveen N. Rao
Reviewed-by: Christophe Leroy
Acked-by: Josh Poimboeuf
Signed-off-by: Sathvika Vasireddy
---
arch/powerpc/kernel/vdso/Makefile | 2 ++
1 f
From: Christophe Leroy
find_insn() will return NULL in case of failure. Check insn in order
to avoid a kernel Oops for NULL pointer dereference.
Tested-by: Naveen N. Rao
Reviewed-by: Naveen N. Rao
Acked-by: Josh Poimboeuf
Acked-by: Peter Zijlstra (Intel)
Signed-off-by: Christophe Leroy
---
From: Christophe Leroy
Some architectures like powerpc support both endianness, it's
therefore not possible to fix the endianness via arch/endianness.h
because there is no easy way to get the target endianness at
build time.
Use the endianness recorded in the file objtool is working on.
Tested-
From: Christophe Leroy
In order to allow using objtool on cross-built kernels,
determine size of long from elf data instead of using
sizeof(long) at build time.
For the time being this covers only mcount.
Tested-by: Naveen N. Rao
Reviewed-by: Naveen N. Rao
Acked-by: Josh Poimboeuf
Acked-by:
Some architectures (powerpc) may not support ftrace locations being nop'ed
out at build time. Introduce CONFIG_HAVE_OBJTOOL_NOP_MCOUNT for objtool, as
a means for architectures to enable nop'ing of ftrace locations. Add --mnop
as an option to objtool --mcount, to indicate support for the same.
Als
Call add_special_section_alts() only when stackval or orc or uaccess or
noinstr options are passed to objtool.
Tested-by: Naveen N. Rao
Reviewed-by: Naveen N. Rao
Reviewed-by: Christophe Leroy
Acked-by: Josh Poimboeuf
Signed-off-by: Sathvika Vasireddy
---
tools/objtool/check.c | 8 +---
Make relocation types architecture specific.
Tested-by: Naveen N. Rao
Reviewed-by: Naveen N. Rao
Reviewed-by: Christophe Leroy
Acked-by: Peter Zijlstra (Intel)
Acked-by: Josh Poimboeuf
Signed-off-by: Sathvika Vasireddy
---
tools/objtool/arch/x86/include/arch/elf.h | 2 ++
tools/objtool/chec
Add architecture specific function to look for relocation records
pointing to architecture specific symbols.
Suggested-by: Christophe Leroy
Tested-by: Naveen N. Rao
Reviewed-by: Naveen N. Rao
Reviewed-by: Christophe Leroy
Acked-by: Josh Poimboeuf
Signed-off-by: Sathvika Vasireddy
---
tools/
This patch adds [stub] implementations for required functions, inorder
to enable objtool build on powerpc.
Tested-by: Naveen N. Rao
Reviewed-by: Naveen N. Rao
Acked-by: Josh Poimboeuf
Signed-off-by: Sathvika Vasireddy
[Christophe Leroy: powerpc: Add missing asm/asm.h for objtool,
Use local var
This patch enables objtool --mcount on powerpc, and adds implementation
specific to powerpc.
Tested-by: Naveen N. Rao
Reviewed-by: Naveen N. Rao
Reviewed-by: Christophe Leroy
Acked-by: Josh Poimboeuf
Signed-off-by: Sathvika Vasireddy
---
arch/powerpc/Kconfig | 1 +
On Fri, Oct 28, 2022 at 09:48:28AM +0200, Andrew Jones wrote:
> Hi x86 maintainers,
>
> I realize 78e5a3399421 has now been reverted, so this fix is no longer
> urgent. I don't believe it's wrong, though, so if it's still of interest,
> then please consider this a friendly ping.
>
> Thanks,
> dre
On Fri, Oct 28, 2022 at 5:37 PM Maarten Zanders wrote:
>
> When CONFIG_PM=N, pm_runtime_put_sync() returns -ENOSYS
> which breaks the probe function of these drivers.
>
> Other users of pm_runtime_put_sync() typically don't check
> the return value. In order to keep the program flow as
> intended,
On Fri, Oct 28, 2022 at 07:46:08AM -0700, Yury Norov wrote:
> I'll take it in bitmap-for-next this weekend.
Why?
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Fri, Oct 28, 2022 at 04:11:28PM +0200, Maarten Zanders wrote:
> This commit fixes:
> cab04ab (ASoC: fsl_asrc: Don't use devm_regmap_init_mmio_clk)
> 203773e (ASoC: fsl_esai: Don't use devm_regmap_init_mmio_clk)
> 2277e7e (ASoC: fsl_sai: Don't use devm_regmap_init_mmio_clk)
Please use 12 charac
On 10/27/22 15:34, Peter Xu wrote:
> On Wed, Oct 26, 2022 at 05:34:04PM -0700, Mike Kravetz wrote:
> > On 10/26/22 17:59, Peter Xu wrote:
>
> If we want to use the vma read lock to protect here as the slow gup path,
> then please check again with below [1] - I think we'll also need to protect
> it
Perf BPF filter test fails in environment where "kernel-debuginfo"
is not installed.
Test failure logs:
<<>>
42: BPF filter:
42.1: Basic BPF filtering : Ok
42.2: BPF pinning : Ok
42.3: BPF prologue generation : FAI
Based on getPerfCountInfo v1.018 documentation, some of the
hv_gpci events got deprecated for platforms firmware that
supports counter_info_version 0x8 or above.
Patch fixes the hv_gpci event list by adding a new attribute
group called "hv_gpci_event_attrs_v6" and a "EVENT_ENABLE"
macro to enable
On Fri, Oct 28, 2022 at 05:45:34PM +0200, Maarten Zanders wrote:
> commit 203773e39347 ("ASoC: fsl_esai: Don't use devm_regmap_init_mmio_clk")
> commit 2277e7e36b4b ("ASoC: fsl_sai: Don't use devm_regmap_init_mmio_clk")
>
> Signed-off-by: Maarten Zanders
If people send tags like Reviewed-by ple
On Fri, Oct 28, 2022 at 08:27:57AM -0700, Mike Kravetz wrote:
> On 10/27/22 15:34, Peter Xu wrote:
> > On Wed, Oct 26, 2022 at 05:34:04PM -0700, Mike Kravetz wrote:
> > > On 10/26/22 17:59, Peter Xu wrote:
> >
> > If we want to use the vma read lock to protect here as the slow gup path,
> > then p
When adding CPUs to an already big system (test show it seems to start with
more than 256 CPUs), the kernel is showing error messages when building the
FDT for the kexec kernel (kdump or kexec).
It's worth to mention that the kdump kernel is reloaded after a CPU add
operation.
The messages look l
On Thu, 27 Oct 2022 14:03:08 +0800, Chancel Liu wrote:
> This patchset supports SAI on i.MX93 platform.
>
> Chancel Liu (3):
> ASoC: dt-bindings: fsl,sai: Add compatible string for i.MX93 platform
> ASoC: fsl_sai: Add support for i.MX93 platform
> ASoC: fsl_sai: Specify the maxburst to 8 on
On Fri, 28 Oct 2022 15:03:47 +0800, Shengjiu Wang wrote:
> These counter registers are part of register list,
> add them to complete the register map
>
> - DMAC counter control registers
> - Data path Timestamp counter register
> - Data path bit counter register
> - Data path bit count timestamp r
At boot time, the FDT is parsed to compute the number of CPUs.
In addition count the number of CPU nodes and export it.
This is useful when building the FDT for a kexeced kernel since we need to
take in account the CPU node added since the boot time during CPU hotplug
operations.
Signed-off-by: L
On a system with a large number of CPUs, the creation of the FDT for a
kexec kernel may fail because the allocated FDT is not large enough.
When this happens, such a message is displayed on the console:
Unable to add ibm,processor-vadd-size property: FDT_ERR_NOSPACE
The property's name may chang
On Fri, Oct 28, 2022 at 10:13:28AM -0500, Yury Norov wrote:
> Because it's related to bitmap API usage and has been revealed after
> some work in bitmaps.
So first of all, that "fix" needs to explain what exactly it is fixing.
Not "it fixes this and that warning" but why the input arg to
cpumask_n
>> +vfrom = kmap_local_page(from);
>> +vto = kmap_local_page(to);
>> +ret = copy_mc_to_kernel(vto, vfrom, PAGE_SIZE);
>
> In copy_user_highpage(), kmsan_unpoison_memory(page_address(to), PAGE_SIZE)
> is done after the copy when
> __HAVE_ARCH_COPY_USER_HIGHPAGE isn't defined. Do we need
>> Cannot call memory_failure() directly from the fault handler because
>> mmap_lock (and others) are held.
>
> Could you please explain which lock makes it unfeasible to call
> memory_failure() directly and
> why? I'm somewhat confused. But I agree using memory_failure_queue() should
> be a good
On 10/27/22 19:03, Stephen Boyd wrote:
Quoting Sean Anderson (2022-10-27 12:11:08)
diff --git a/drivers/phy/freescale/Kconfig b/drivers/phy/freescale/Kconfig
index 853958fb2c06..a6f9e39b 100644
--- a/drivers/phy/freescale/Kconfig
+++ b/drivers/phy/freescale/Kconfig
@@ -47,3 +47,25 @@ config
> -Original Message-
> From: Sean Anderson
> Sent: Monday, October 17, 2022 23:23
> To: David S . Miller ; Jakub Kicinski
> ; Madalin Bucur ; Camelia
> Alexandra Groza ; net...@vger.kernel.org
> Cc: Eric Dumazet ; linuxppc-dev @ lists . ozlabs .
> org ; linux-arm-ker...@lists.infradead.org
On 10/28/22 12:13, Sean Anderson wrote:
On 10/27/22 19:03, Stephen Boyd wrote:
Quoting Sean Anderson (2022-10-27 12:11:08)
diff --git a/drivers/phy/freescale/Kconfig b/drivers/phy/freescale/Kconfig
index 853958fb2c06..a6f9e39b 100644
--- a/drivers/phy/freescale/Kconfig
+++ b/drivers/phy/fre
On 10/28/22 12:30, Camelia Alexandra Groza wrote:
-Original Message-
From: Sean Anderson
Sent: Monday, October 17, 2022 23:23
To: David S . Miller ; Jakub Kicinski
; Madalin Bucur ; Camelia
Alexandra Groza ; net...@vger.kernel.org
Cc: Eric Dumazet ; linuxppc-dev @ lists . ozlabs .
org ;
During discussions of this series [1], it was suggested that hugetlb
handling code in follow_page_mask could be simplified. At the beginning
of follow_page_mask, there currently is a call to follow_huge_addr which
'may' handle hugetlb pages. ia64 is the only architecture which provides
a follow_h
On Fri, 28 Oct 2022 16:11:28 +0200, Maarten Zanders wrote:
> When CONFIG_PM=N, pm_runtime_put_sync() returns -ENOSYS
> which breaks the probe function of these drivers.
>
> Other users of pm_runtime_put_sync() typically don't check
> the return value. In order to keep the program flow as
> intende
On Sat, Oct 29, 2022 at 2:11 AM Punit Agrawal
wrote:
>
> Yicong Yang writes:
>
> > On 2022/10/27 22:19, Punit Agrawal wrote:
> >>
> >> [ Apologies for chiming in late in the conversation ]
> >>
> >> Anshuman Khandual writes:
> >>
> >>> On 9/28/22 05:53, Barry Song wrote:
> On Tue, Sep 27, 2
On Fri, Oct 28, 2022 at 11:11:08AM -0700, Mike Kravetz wrote:
> v4 -Remove vma (pmd sharing) locking as this can be called with
> FOLL_NOWAIT. Peter
Thanks, Mike. For the gup safety on pmd unshare, I'll prepare a few small
patches and post hopefully early next week (will be off-work on
Ping.
On 2022/10/19 14:34, ruanjinjie wrote:
> When build Linux kernel, encounter the following warnings:
>
> ./arch/powerpc/sysdev/mpic_msgr.c:230:38: warning: cast removes address space
> '__iomem' of expression
> ./arch/powerpc/sysdev/mpic_msgr.c:230:27: warning: incorrect type in
> assignme
The header is a random.c private detail, not
something to be called by other code. As such, don't make it
automatically available by way of random.h.
Cc: Michael Ellerman
Cc: Heiko Carstens
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-s...@vger.kernel.org
Signed-off-by: Jason A. Donenfeld
---
On 2022/10/29 0:13, Luck, Tony wrote:
>>> Cannot call memory_failure() directly from the fault handler because
>>> mmap_lock (and others) are held.
>>
>> Could you please explain which lock makes it unfeasible to call
>> memory_failure() directly and
>> why? I'm somewhat confused. But I agree usin
62 matches
Mail list logo
