On Mon, 2024-07-29 at 16:36 -0600, Rob Herring (Arm) wrote:
> There's little reason to dump DT property values when they can be
> read
> at any time from the DT in /proc/device-tree. If such a feature is
> needed, then it really should be implemented in the DT core such that
> any module/driver can
On Wed, Aug 28, 2024 at 07:46:52AM +0200, Christophe Leroy wrote:
> Hi,
>
> Le 28/08/2024 à 05:17, 虞陆铭 a écrit :
> > Hi,
> >
> > it appears the little feature might require a little bit more work to find
> > its value of the patch.
> >
> > Using the following debug module , some debugging show
Hi Charlie,
Le 28/08/2024 à 07:49, Charlie Jenkins a écrit :
Add support for MAP_BELOW_HINT to arch_get_mmap_base() and
arch_get_mmap_end().
Signed-off-by: Charlie Jenkins
---
arch/powerpc/include/asm/task_size_64.h | 36 +++--
1 file changed, 30 insertions(+), 6
DMA ops are a helper for architectures and not for drivers to override
the DMA implementation.
Unfortunately driver authors keep ignoring this. Make the fact more
clear by renaming the symbol to ARCH_HAS_DMA_OPS and having the two drivers
overriding their dma_ops depend on that. These drivers sh
vdpa_sim has been fixed to not override the dma_map_ops in commit
6c3d329e6486 ("vdpa_sim: get rid of DMA ops"), so don't select the
symbol and don't depend on HAS_DMA.
Signed-off-by: Christoph Hellwig
---
drivers/vdpa/Kconfig | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a
Hi all,
we've had a long standing problems where drivers try to hook into the
DMA_OPS mechanisms to override them for something that is not DMA, or
to introduce additional dispatching.
Now that we are not using DMA_OPS support for dma-iommu and can build
kernels without DMA_OPS support on many co
Hi,
Le 28/08/2024 à 05:17, 虞陆铭 a écrit :
Hi,
it appears the little feature might require a little bit more work to find its
value of the patch.
Using the following debug module , some debugging shows the
TIF_USER_RETURN_NOTIFY
bit is propagated in __switch_to among tasks , but USER_RETURN_N
On Wed, Aug 28, 2024 at 01:52:33PM GMT, Michael Ellerman wrote:
> "Nysal Jan K.A." writes:
> > If an interrupt occurs in queued_spin_lock_slowpath() after we increment
> > qnodesp->count and before node->lock is initialized, another CPU might
> > see stale lock values in get_tail_qnode(). If the s
On Wed, Aug 28, 2024 at 01:19:46PM GMT, Nicholas Piggin wrote:
> What probably makes it really difficult to hit is that I think both
> locks A and B need contention from other sources to push them into
> queueing slow path. I guess that's omitted for brevity in the flow
> above, which is fine.
>
"Nysal Jan K.A." writes:
> If an interrupt occurs in queued_spin_lock_slowpath() after we increment
> qnodesp->count and before node->lock is initialized, another CPU might
> see stale lock values in get_tail_qnode(). If the stale lock value happens
> to match the lock on that CPU, then we write t
Hey Nysal,
This is really good debugging, and a nice write up.
On Mon Aug 26, 2024 at 6:12 PM AEST, Nysal Jan K.A. wrote:
> If an interrupt occurs in queued_spin_lock_slowpath() after we increment
> qnodesp->count and before node->lock is initialized, another CPU might
> see stale lock values in
Hi,
it appears the little feature might require a little bit more work to find its
value of the patch.
Using the following debug module , some debugging shows the
TIF_USER_RETURN_NOTIFY
bit is propagated in __switch_to among tasks , but USER_RETURN_NOTIFY call back
seems to
be dropped somewh
On 2024/8/27 21:50, Krzysztof Kozlowski wrote:
> On 27/08/2024 13:46, Jinjie Ruan wrote:
>> Use the dev_err_probe() helper to simplify error handling during probe.
>> This also handle scenario, when EDEFER is returned and useless error
>> is printed.
>
> ? Sorry, this cannot happen. Please poin
On Tue, Aug 27, 2024 at 11:08:19AM -0700, Eric Biggers wrote:
> On Thu, Aug 22, 2024 at 09:13:13AM +0200, Christophe Leroy wrote:
> > With the current implementation, __cvdso_getrandom_data() calls
> > memset(), which is unexpected in the VDSO.
> >
> > Rewrite opaque data initialisation to avoid m
On Thu, Aug 22, 2024 at 09:13:13AM +0200, Christophe Leroy wrote:
> With the current implementation, __cvdso_getrandom_data() calls
> memset(), which is unexpected in the VDSO.
>
> Rewrite opaque data initialisation to avoid memset().
>
> Signed-off-by: Christophe Leroy
> ---
> lib/vdso/getrand
Commit 450be4960a0f ("powerpc/pci: Remove LSI mappings on device
teardown") frees irq descriptors on PCIe hotplug link change event
(Link Down), but the disposed mappings are not restored back on PCIe
hotplug link change event (Card present).
This change restores IRQ mappings disposed earlier when
Hi Christophe,
On 27/08/2024 11:49, Christophe Leroy wrote:
...
>>
>> These are still two headers outside of the vdso/ namespace. For arm64
>> we had concluded that this is never safe, and any vdso header should
>> only include other vdso headers so we never pull in anything that
>> e.g. depend
Hello Yicong,
IIUC we are looking for the maximum number of threads a CPU can have
in the platform. But is is actually possible to have a platform with
CPUs not having the same number of threads ?
For instance kernel/cpu.c::cpu_smt_num_threads_valid() will check
that the number of threads is eith
Hello Yicong,
Is it necessary to have an explicit dependency over SMP for arm64 ? Cf.
commit 4b3dc9679cf7 ("arm64: force CONFIG_SMP=y and remove redundant #ifdefs")
Regards,
Pierre
On 8/6/24 10:53, Yicong Yang wrote:
From: Yicong Yang
Enable HOTPLUG_SMT for SMT control.
Signed-off-by: Yic
On Mon, Aug 26, 2024 at 10:33 PM Kajol Jain wrote:
>
> Update JSON/events for power10 platform with additional events.
>
> Signed-off-by: Kajol Jain
For the series:
Reviewed-by: Ian Rogers
Just to note, the moving of events in patches 2 and 3 is necessary as
the filename sets the "topic" in pe
On Tue, Aug 27, 2024 at 11:08:19AM -0700, Eric Biggers wrote:
> On Thu, Aug 22, 2024 at 09:13:13AM +0200, Christophe Leroy wrote:
> > With the current implementation, __cvdso_getrandom_data() calls
> > memset(), which is unexpected in the VDSO.
> >
> > Rewrite opaque data initialisation to avoid m
On Mon, Aug 26, 2024 at 01:52:54PM -0700, Luis Chamberlain wrote:
> On Mon, Aug 26, 2024 at 07:43:20PM +0200, Christophe Leroy wrote:
> >
> >
> > Le 26/08/2024 à 17:48, Pankaj Raghav (Samsung) a écrit :
> > > On Mon, Aug 26, 2024 at 05:59:31PM +1000, Stephen Rothwell wrote:
> > > > Hi all,
> > >
Hi Vicenzo,
Le 27/08/2024 à 18:05, Vincenzo Frascino a écrit :
> Hi Christophe,
>
> On 27/08/2024 11:49, Christophe Leroy wrote:
>
> ...
>
>
>
> I agree with Arnd here. uapi/linux/mman.h can cause us problems in the long
> run.
>
> I am attaching a patch to provide my view on how to minimiz
Le 27/08/2024 à 18:05, Vincenzo Frascino a écrit :
Hi Christophe,
On 27/08/2024 11:49, Christophe Leroy wrote:
...
These are still two headers outside of the vdso/ namespace. For arm64
we had concluded that this is never safe, and any vdso header should
only include other vdso headers so
Christophe Leroy writes:
> Le 27/08/2024 à 11:12, Ritesh Harjani (IBM) a écrit :
>> [Vous ne recevez pas souvent de courriers de ritesh.l...@gmail.com.
>> Découvrez pourquoi ceci est important à
>> https://aka.ms/LearnAboutSenderIdentification ]
>>
>> Use pr_warn_once instead of WARN_ON_ONCE a
On Mon, Aug 26, 2024 at 01:29:09PM -0400, Steven Rostedt wrote:
> On Mon, 26 Aug 2024 09:55:29 +0300
> Mike Rapoport wrote:
>
> > From: Song Liu
> >
> > ftrace_process_locs sorts module mcount, which is inside RO memory. Add a
> > ftrace_swap_func so that archs can use RO-memory-poke function t
Le 27/08/2024 à 11:12, Ritesh Harjani (IBM) a écrit :
[Vous ne recevez pas souvent de courriers de ritesh.l...@gmail.com. Découvrez
pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ]
Use pr_warn_once instead of WARN_ON_ONCE as discussed here [1]
for printing possib
On 27/08/2024 13:46, Jinjie Ruan wrote:
> Use the dev_err_probe() helper to simplify error handling during probe.
> This also handle scenario, when EDEFER is returned and useless error
> is printed.
? Sorry, this cannot happen. Please point to below code which can defer.
>
> Signed-off-by: Jinji
On 24/08/2024 4:57 am, Christoph Hellwig wrote:
DMA ops are a helper for architectures and not for drivers to override
the DMA implementation. Unfortunately driver authors keep ignoring
this. Make this more clear by renaming the symbol to ARCH_DMA_OPS,
have the three drivers overriding it depen
On Sun, Jul 14, 2024 at 5:29 PM Naveen N Rao wrote:
>
> Function profile sequence on powerpc includes two instructions at the
> beginning of each function:
> mflrr0
> bl ftrace_caller
>
> The call to ftrace_caller() gets nop'ed out during kernel boot and is
> patched in wh
Use pr_warn_once instead of WARN_ON_ONCE as discussed here [1]
for printing possible use of set_memory_* on linear map on Hash.
[1]: https://lore.kernel.org/all/877cc2fpi2.fsf@mail.lhotse/#t
Signed-off-by: Ritesh Harjani (IBM)
---
arch/powerpc/mm/pageattr.c | 5 -
1 file changed, 4 insertio
Sean Christopherson writes:
> arm64 folks, the first two patches are bug fixes, but I have very low
> confidence that they are correct and/or desirable. If they are more or
> less correct, I can post them separately if that'd make life easier. I
> included them here to avoid conflicts, and beca
On Fri, Aug 23, 2024 at 07:40:52PM +0100, Catalin Marinas wrote:
> On Fri, Aug 23, 2024 at 06:08:36PM +0100, Will Deacon wrote:
> > On Fri, Aug 23, 2024 at 05:41:06PM +0100, Catalin Marinas wrote:
> > > On Fri, Aug 23, 2024 at 03:45:32PM +0100, Will Deacon wrote:
> > > > On Thu, Aug 22, 2024 at 04:
Use scoped for_each_child_of_node_scoped() when iterating over device
nodes to make code a bit simpler.
Signed-off-by: Jinjie Ruan
---
drivers/soc/tegra/pmc.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
index
Use for_each_child_of_node_scoped() to simplify code.
Jinjie Ruan (8):
soc: fsl: cpm1: Simplify with scoped for each OF child loop
soc: fsl: cpm1: Simplify with dev_err_probe()
soc: fsl: cpm1: qmc: Simplify with scoped for each OF child
soc: fsl: cpm1: qmc: Simplify with dev_err_probe()
Use scoped for_each_available_child_of_node_scoped when iterating
over device nodes to make code a bit simpler.
Signed-off-by: Jinjie Ruan
---
drivers/soc/fsl/qe/tsa.c | 28
1 file changed, 4 insertions(+), 24 deletions(-)
diff --git a/drivers/soc/fsl/qe/tsa.c b/dri
Use the dev_err_probe() helper to simplify error handling during probe.
This also handle scenario, when EDEFER is returned and useless error
is printed.
Signed-off-by: Jinjie Ruan
---
drivers/soc/fsl/qe/qmc.c | 53
1 file changed, 21 insertions(+), 32 del
Use the dev_err_probe() helper to simplify error handling during probe.
This also handle scenario, when EDEFER is returned and useless error
is printed.
Signed-off-by: Jinjie Ruan
---
drivers/soc/fsl/qe/tsa.c | 62 +++-
1 file changed, 23 insertions(+), 39 del
Use scoped for_each_child_of_node_scoped() when iterating over device
nodes to make code a bit simpler.
Signed-off-by: Jinjie Ruan
---
drivers/soc/dove/pmu.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/soc/dove/pmu.c b/drivers/soc/dove/pmu.c
index 6202dbc
Use scoped for_each_child_of_node_scoped() when iterating over device
nodes to make code a bit simpler.
And use the dev_err_probe() helper to simplify error handling during
probe. This also handle scenario, when EDEFER is returned and useless
error is printed.
Signed-off-by: Jinjie Ruan
---
dri
Use scoped for_each_available_child_of_node_scoped() when iterating
over device nodes to make code a bit simpler.
Signed-off-by: Jinjie Ruan
---
drivers/soc/fsl/qe/qmc.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/drivers/soc/fsl/qe/qmc.c b/drivers/soc/fsl/
Use scoped for_each_child_of_node_scoped() when iterating over device
nodes to make code a bit simpler.
And use the dev_err_probe() helper to simplify error handling during
probe. This also handle scenario, when EDEFER is returned and useless
error is printed.
Signed-off-by: Jinjie Ruan
---
dri
Le 27/08/2024 à 11:59, Arnd Bergmann a écrit :
On Tue, Aug 27, 2024, at 10:40, Jason A. Donenfeld wrote:
I don't love this, but it might be the lesser of evils, so sure, let's
do it.
I think I'll combine these header fixups so that the whole operation is
a bit more clear. The commit is still
On Tue, Aug 27, 2024, at 10:40, Jason A. Donenfeld wrote:
> I don't love this, but it might be the lesser of evils, so sure, let's
> do it.
>
> I think I'll combine these header fixups so that the whole operation is
> a bit more clear. The commit is still pretty small. Something like
> below:
>
> F
Hey again,
On Mon, Aug 26, 2024 at 09:19:22AM +0200, Jason A. Donenfeld wrote:
> Thanks for this series. There are quite a few preliminary patches in it,
> before you get to the PPC part, which fix up general build system or test
> harness correctness issues. Since some of those affect all archite
On 08/27/24 at 08:37am, John Paul Adrian Glaubitz wrote:
> On Tue, 2024-08-27 at 14:22 +0800, Baoquan He wrote:
> > About why it's enabled by default, as Michael has explained in another
> > thread, distros usualy needs to enable it by default because vmcore
> > dumping is a very important feature
Hi,
On Mon, Aug 26, 2024 at 06:17:22PM +, Bruno Faccini wrote:
> > On 7 Aug 2024, at 2:41, Mike Rapoport wrote:
> >
> > From: "Mike Rapoport (Microsoft)"
> >
> > Until now arch_numa was directly translating firmware NUMA information
> > to memblock.
> >
> > Using numa_memblks as an interme
Le 27/08/2024 à 10:40, Jason A. Donenfeld a écrit :
I don't love this, but it might be the lesser of evils, so sure, let's
do it.
I don't love it either but I still prefer it to:
#ifndef PAGE_SIZE
#define PAGE_SIZE
#define PAGE_MASK
#endif
At least we are sure that every architecture get t
Le 27/08/2024 à 09:49, Jason A. Donenfeld a écrit :
On Tue, Aug 27, 2024 at 09:31:48AM +0200, Christophe Leroy wrote:
- ssize_t ret = min_t(size_t, INT_MAX & PAGE_MASK /* = MAX_RW_COUNT */,
len);
+ const unsigned long page_size = 1UL << CONFIG_PAGE_SHIFT;
+ const unsigned l
I don't love this, but it might be the lesser of evils, so sure, let's
do it.
I think I'll combine these header fixups so that the whole operation is
a bit more clear. The commit is still pretty small. Something like
below:
>From 0d9a3d68cd6222395a605abd0ac625c41d4cabfa Mon Sep 17 00:00:00 2001
F
Using PAGE_SIZE and PAGE_MASK in VDSO requires inclusion of
page.h and it creates several problems, see
commit 8b3843ae3634 ("vdso/datapage: Quick fix - use asm/page-def.h
for ARM64") and commit cffaefd15a8f ("vdso: Use CONFIG_PAGE_SHIFT in
vdso/datapage.h").
Redefine PAGE_SIZE and PAGE_MASK based
On Tue, Aug 27, 2024 at 10:16:18AM +0200, Christophe Leroy wrote:
> tglx or yourself suggested to put in a one of the vdso headers instead
> of directly in getrandom.c. This is too fragile because PAGE_SIZE might
> be absent in that header but arrive in getrandom.c through another header.
Oh jee
On Tue, Aug 27, 2024 at 09:31:50AM +0200, Christophe Leroy wrote:
> Performing SMP atomic operations on u64 fails on powerpc32:
Thanks for this, and nice catch on the vDSO side checking on big endian.
I've applied this, fixing up the commit message and the comment,
maintaining the reverse christma
On 8/27/24 12:06 PM, Michael Ellerman wrote:
Maddy will be helping out with upstream maintenance, add him as a
reviewer.
Signed-off-by: Michael Ellerman
Acked-by: Madhavan Srinivasan
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 878d
On Tue, Aug 27, 2024 at 09:31:48AM +0200, Christophe Leroy wrote:
> - ssize_t ret = min_t(size_t, INT_MAX & PAGE_MASK /* = MAX_RW_COUNT */,
> len);
> + const unsigned long page_size = 1UL << CONFIG_PAGE_SHIFT;
> + const unsigned long page_mask = ~(page_size - 1);
> + ssize_t ret =
On 27.08.2024 09:03, Baruch Siach wrote:
> On Tue, Aug 27 2024, Marek Szyprowski wrote:
>> On 27.08.2024 06:52, Baruch Siach wrote:
>>> Hi Marek,
>>>
>>> Thanks for your report.
>>>
>>> On Mon, Aug 26 2024, Marek Szyprowski wrote:
On 11.08.2024 09:09, Baruch Siach wrote:
> From: Catalin Ma
Performing SMP atomic operations on u64 fails on powerpc32:
CC drivers/char/random.o
In file included from :
drivers/char/random.c: In function 'crng_reseed':
././include/linux/compiler_types.h:510:45: error: call to
'__compiletime_assert_391' declared with attribute error: Need na
Building a VDSO32 on a 64 bits kernel is problematic when some
system headers are included. See commit 8c59ab839f52 ("lib/vdso:
Enable common headers") for more details.
Minimise the amount of headers by moving needed items into
dedicated common headers.
Removing linux/time64.h leads to missing '
Using PAGE_SIZE and PAGE_MASK in VDSO requires inclusion of
page.h and it creates several problems, see
commit 8b3843ae3634 ("vdso/datapage: Quick fix - use asm/page-def.h
for ARM64") and commit cffaefd15a8f ("vdso: Use CONFIG_PAGE_SHIFT in
vdso/datapage.h").
An easy solution would be to define PA
getrandom vDSO implementation requires __put_unaligned_t() and
__put_unaligned_t() but including asm-generic/unaligned.h pulls
too many other headers.
Follow the same approach as for most things in include/vdso/,
see for instance commit 8165b57bca21 ("linux/const.h: Extract
common header for vDSO"
This small series is an extract of fixups for generic part of random vDSO in
preparation of implementing vDSO getrandom for powerpc.
See last version of full series at:
https://patchwork.ozlabs.org/project/linuxppc-dev/cover/cover.1724309198.git.christophe.le...@csgroup.eu/
This series is based o
On Sat, Aug 24, 2024 at 12:17:57PM -0500, Segher Boessenkool wrote:
> > Are these functions also used on DMA coherent memory ?
>
> Most won't show up high on most profiles, heh. Which you already
> can see from the problem not being attacked yet: if it was so obviously
> a problem, some people wo
On Thu, 22 Aug 2024 09:58:42 +0200, Christophe Leroy wrote:
> Commit 6b0e82791bd0 ("powerpc/e500: switch to 64 bits PGD on 85xx
> (32 bits)") switched PGD entries to 64 bits, but pgd_val() returns
> an unsigned long which is 32 bits on PPC32. This is not a problem
> for regular PMD entries because
On Tue, 20 Aug 2024 13:28:07 +0200, Christophe Leroy wrote:
> After building the VDSO, there is a verification that it contains
> no dynamic relocation, see commit aff69273af61 ("vdso: Improve
> cmd_vdso_check to check all dynamic relocations").
>
> This verification uses readelf -r and doesn't wo
On Tue, 20 Aug 2024 14:42:38 +0200, Christophe Leroy wrote:
> mmu_pte_psize is only used in the tlb_64e.c, define it static.
>
>
Applied to powerpc/fixes.
[1/1] powerpc/64e: Define mmu_pte_psize static
https://git.kernel.org/powerpc/c/d92b5cc29c792f1d3f0aaa3b29dddfe816c03e88
cheers
On Fri, 26 Jul 2024 22:33:21 +1000, Michael Ellerman wrote:
> Arnd is no longer actively maintaining Cell, mark it as orphan.
>
> Also drop the dead developerworks link.
>
>
Applied to powerpc/next.
[1/2] MAINTAINERS: Mark powerpc Cell as orphaned
https://git.kernel.org/powerpc/c/db9a639
On Wed, 15 May 2024 12:44:40 +1000, Benjamin Gray wrote:
> Currently patch_instruction() bases the write length on the value being
> written. If the value looks like a prefixed instruction it writes 8 bytes,
> otherwise it writes 4 bytes. This makes it potentially buggy to use for
> writing arbitra
On Wed, 21 Aug 2024 08:47:51 +0200, Christophe Leroy wrote:
> LHZX_BE has been unused since commit dbf44daf7c88 ("bpf, ppc64: remove
> ld_abs/ld_ind")
>
> Remove it.
>
>
Applied to powerpc/next.
[1/1] powerpc: Remove LHZX_BE macro
https://git.kernel.org/powerpc/c/a540ad3e386f8f84bc6d600b
Hi Marek,
On Tue, Aug 27 2024, Marek Szyprowski wrote:
> On 27.08.2024 06:52, Baruch Siach wrote:
>> Hi Marek,
>>
>> Thanks for your report.
>>
>> On Mon, Aug 26 2024, Marek Szyprowski wrote:
>>> On 11.08.2024 09:09, Baruch Siach wrote:
From: Catalin Marinas
Hardware DMA limit migh
69 matches
Mail list logo
