On Wednesday 22 February 2023 06:39:07 Christophe Leroy wrote:
> Hi,
>
> Le 21/02/2023 à 23:07, Pali Rohár a écrit :
> > Hello Christophe! Could you look at this v3 series?
> > I addressed those small issues and hopefully it should be ready.
> > It would be great to have this finally in v6.3
Le 22/02/2023 à 07:01, Kautuk Consul a écrit :
> A link from ibm.com states:
> "Ensures that all instructions preceding the call to __lwsync
> complete before any subsequent store instructions can be executed
> on the processor that executed the function. Also, it ensures that
> all load
For RISCV we always assume devices are DMA coherent.
Select ARCH_DMA_DEFAULT_COHERENT to ensure dev->dma_conherent
is always initialized to true.
Signed-off-by: Jiaxun Yang
---
arch/riscv/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index
Jiaxun Yang (7):
MIPS: Remove DMA_PERDEV_COHERENT
MIPS: Always select ARCH_HAS_SYNC_DMA_FOR_CPU for noncoherent
platforms
MIPS: c-r4k: Always install dma flush functions
dma-mapping: Always provide dma_default_coherent
dma-mapping: Provide CONFIG_ARCH_DMA_DEFAULT_COHERENT
riscv:
As now we are always managing DMA coherence on per dev bias,
there is no need to have such option. And it's not selected
by any platform.
Signed-off-by: Jiaxun Yang
---
arch/mips/Kconfig | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/arch/mips/Kconfig
dma_default_coherent can be useful for determine default coherency
even on arches without noncoherent support.
Signed-off-by: Jiaxun Yang
---
include/linux/dma-map-ops.h | 1 +
kernel/dma/mapping.c| 4
2 files changed, 5 insertions(+)
diff --git a/include/linux/dma-map-ops.h
On Tue, Feb 21, 2023 at 12:46:07PM +, Jiaxun Yang wrote:
> As now we are always managing DMA coherence on per dev bias,
> there is no need to have such option. And it's not selected
> by any platform.
I think the real point here is that this is dead code, so it can
obviously go away, but:
>
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.
This also fixes a case that for some MIPS platforms, coherency information
is not carried in devicetree and kernel will override
As nowadays DMA coherence is managed per device, it is possible
to have a system that is defaulted to coherent dma but still
have noncoherent device that needs to use those flush functions.
Just install them unconditionally.
Signed-off-by: Jiaxun Yang
---
arch/mips/mm/c-r4k.c | 12 +++-
On Tue, Feb 21, 2023 at 12:46:11PM +, Jiaxun Yang wrote:
> Provide a kconfig option to allow arches to manipulate default
> value of dma_default_coherent in Kconfig.
I don't see the win over just doing this by setting dma_default_coherent
in the early boot code.
On Tue, Feb 21, 2023 at 12:46:10PM +, Jiaxun Yang wrote:
> dma_default_coherent can be useful for determine default coherency
> even on arches without noncoherent support.
How?
As now we are telling the necessity of post DMA flush per CPU type,
there is no need to select ARCH_HAS_SYNC_DMA_FOR_CPU on per platform
bias, just select it unconditionally and we can sort it at runtime.
Signed-off-by: Jiaxun Yang
---
arch/mips/Kconfig | 9 +
1 file changed, 1
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
Can you explain the motivation here? Also why riscv patches are at
the end of a mips fіxes series?
> 2023年2月21日 17:54，Christoph Hellwig 写道：
>
> Can you explain the motivation here? Also why riscv patches are at
> the end of a mips fіxes series?
Ah sorry for any confusion.
So the main purpose of this patch is to fix MIPS’s broken per-device coherency.
To be more precise, we want to be
The MPC8568-MDS just might have been the 2nd last in the MDS line that
was similar to the MPC83xx-MDS in general form factor. However, as can
be seen in the 8568MDS User Guide picture, the PCI/PCI-X card edge has
been deleted.
A recent change in the Kconfig descriptions, in commit d20c96deb3e2
Based on the revision history in the manual(s), these e500-v1
platforms were first available around 2002.
Like a lot of evaluation boards, they attempted to provide break-out
connectors for all possible features, and that combined with four
PCI-X slots (and the age/era) meant for a considerably
Hello! I would like to let you know that I have there patch series which
creates one generic machine descriptor for all P2 boards:
https://lore.kernel.org/linuxppc-dev/20230218111405.27688-1-p...@kernel.org/
Basically it allows any P2 board to boot one universal kernel binary
just with correct
> 2023年2月21日 17:58，Christoph Hellwig 写道：
>
> On Tue, Feb 21, 2023 at 12:46:11PM +, Jiaxun Yang wrote:
>> Provide a kconfig option to allow arches to manipulate default
>> value of dma_default_coherent in Kconfig.
>
> I don't see the win over just doing this by setting
The MPC8541/8548/8555 Configurable Development System (CDS) were the
vehicle used to provide evaluation of the 1st e500-v2 CPUs around 2007.
Similar to the earlier MPC83xx-MDS systems we removed, the "brains"
exist on a PCI-X card, but additional connectors exist to the right of
the PCI-X slot,
[This RFC is proposed for v6.4 and hence is based off linux-next.]
In a similar theme to the e300/MPC83xx evaluation platform removal[1],
this targets removal of some 13 --> 21 year old e500/MPC85xx evaluation
boards that were produced in limited numbers and primarily made available
to
> 2023年2月21日 17:58，Christoph Hellwig 写道：
>
> On Tue, Feb 21, 2023 at 12:46:10PM +, Jiaxun Yang wrote:
>> dma_default_coherent can be useful for determine default coherency
>> even on arches without noncoherent support.
>
> How?
I just want to make this symbol always available so OF code
[Re: [PATCH 4/4] powerpc: remove orphaned MPC85xx kernel config fragments.] On
21/02/2023 (Tue 21:03) Pali Roh??r wrote:
> On Tuesday 21 February 2023 14:46:37 Paul Gortmaker wrote:
> > None of these have a reference anymore anywhere, such as like this:
> >
> > arch/powerpc/Makefile: $(call
[Re: [RFC PATCH 0/4] Remove some e500/MPC85xx evaluation platforms] On
21/02/2023 (Tue 21:13) Pali Roh??r wrote:
> Hello! I would like to let you know that I have there patch series which
> creates one generic machine descriptor for all P2 boards:
>
On Tuesday 21 February 2023 16:29:32 Paul Gortmaker wrote:
> [Re: [PATCH 4/4] powerpc: remove orphaned MPC85xx kernel config fragments.]
> On 21/02/2023 (Tue 21:03) Pali Roh??r wrote:
>
> > On Tuesday 21 February 2023 14:46:37 Paul Gortmaker wrote:
> > > None of these have a reference anymore
On Tuesday 21 February 2023 16:35:54 Paul Gortmaker wrote:
> [Re: [RFC PATCH 0/4] Remove some e500/MPC85xx evaluation platforms] On
> 21/02/2023 (Tue 21:13) Pali Roh??r wrote:
>
> > Hello! I would like to let you know that I have there patch series which
> > creates one generic machine
On Tue, Feb 21, 2023 at 12:46:12PM +, Jiaxun Yang wrote:
> For RISCV we always assume devices are DMA coherent.
"Always assume", I'm not keen on that wording as it is unclear as to
whether you are suggesting that a) we always take devices to be DMA
coherent, or b) unless a device states it is
> 2023年2月21日 18:14，Conor Dooley 写道：
>
> On Tue, Feb 21, 2023 at 12:46:12PM +, Jiaxun Yang wrote:
>> For RISCV we always assume devices are DMA coherent.
>
> "Always assume", I'm not keen on that wording as it is unclear as to
> whether you are suggesting that a) we always take devices to
On 2023-02-21 17:58, Christoph Hellwig wrote:
On Tue, Feb 21, 2023 at 12:46:10PM +, Jiaxun Yang wrote:
dma_default_coherent can be useful for determine default coherency
even on arches without noncoherent support.
How?
Indeed, "default" is conceptually meaningless when there is no
None of these have a reference anymore anywhere, such as like this:
arch/powerpc/Makefile: $(call merge_into_defconfig,mpc85xx_base.config,\
As such, we probably should just clean up and remove them.
Cc: Scott Wood
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
On 2023-02-21 18:15, Jiaxun Yang wrote:
2023年2月21日 17:54，Christoph Hellwig 写道：
Can you explain the motivation here? Also why riscv patches are at
the end of a mips fіxes series?
Ah sorry for any confusion.
So the main purpose of this patch is to fix MIPS’s broken per-device coherency.
> 2023年2月21日 19:46，Robin Murphy 写道：
>
> On 2023-02-21 18:15, Jiaxun Yang wrote:
>>> 2023年2月21日 17:54，Christoph Hellwig 写道：
>>>
>>> Can you explain the motivation here? Also why riscv patches are at
>>> the end of a mips fіxes series?
>> Ah sorry for any confusion.
>> So the main purpose of
On Tuesday 21 February 2023 14:46:37 Paul Gortmaker wrote:
> None of these have a reference anymore anywhere, such as like this:
>
> arch/powerpc/Makefile: $(call merge_into_defconfig,mpc85xx_base.config,\
>
> As such, we probably should just clean up and remove them.
>
> Cc: Scott Wood
>
The MAINTAINERS entry for VAS (Virtual Accelerator Switchboard) no
longer has any maintainers, it just points to linuxppc-dev, since commit
60496069d0ae ("powerpc: Update MAINTAINERS for ibmvnic and VAS").
So just drop the VAS entry, all the paths are already covered by the
main powerpc entry,
Amit Kumar Mahapatra writes:
> Supporting multi-cs in spi drivers would require the chip_select & cs_gpiod
> members of struct spi_device to be an array. But changing the type of these
> members to array would break the spi driver functionality. To make the
> transition smoother introduced four
sd_mod t10_pi
crc64_rocksoft_generic crc64_rocksoft crc64 sg i40e aacraid vmx_crypto
[ 59.558494] CPU: 29 PID: 6366 Comm: kexec Not tainted 6.2.0-next-20230221 #1
[ 59.558508] Hardware name: CSE-829U POWER9 0x4e1202
opal:skiboot-v6.0.7 PowerNV
[ 59.558521] NIP: c0031e4c LR
Hello Christophe! Could you look at this v3 series?
I addressed those small issues and hopefully it should be ready.
It would be great to have this finally in v6.3 release.
On Saturday 18 February 2023 12:13:57 Pali Rohár wrote:
> This patch series unifies all P2020 boards and machine
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.
Fixes: 119da30d037d ("powerpc/pseries: Expose PLPKS config values,
_i2c opal_prd ipmi_msghandler mtd ibmpowernv drm fuse
> drm_panel_orientation_quirks xfs libcrc32c sd_mod t10_pi
> crc64_rocksoft_generic crc64_rocksoft crc64 sg i40e aacraid vmx_crypto
> [ 59.558494] CPU: 29 PID: 6366 Comm: kexec Not tainted 6.2.0-next-20230221
> #1
> [ 59
Currently, to check if NUMA node has CPUs, one has to use the
nr_cpus_node() macro, which ends up with cpumask_weight. We can do it
better with cpumask_empty(), because the latter can potentially return
earlier - as soon as 1st set bit found.
This patch adds a node_has_cpus() macro to implement
Use node_has_cpus() as more efficient alternative to nr_cpus_node()
where possible.
Signed-off-by: Yury Norov
---
arch/powerpc/platforms/cell/spu_priv1_mmio.c | 2 +-
arch/powerpc/platforms/cell/spufs/sched.c| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git
When KASAN/KCSAN are enabled clang generates .text.asan/tsan sections.
Because they are not mentioned in the linker script warnings are
generated, and when orphan handling is set to error that becomes a build
error, eg:
ld.lld: error: vmlinux.a(init/main.o):(.text.tsan.module_ctor) is
being
A link from ibm.com states:
"Ensures that all instructions preceding the call to __lwsync
complete before any subsequent store instructions can be executed
on the processor that executed the function. Also, it ensures that
all load instructions preceding the call to __lwsync complete before
Hi All,
On Wed, Feb 22, 2023 at 11:31:07AM +0530, Kautuk Consul wrote:
> /* The sub-arch has lwsync */
> #if defined(CONFIG_PPC64) || defined(CONFIG_PPC_E500MC)
> -#define SMPWMB LWSYNC
> +#undef rmb
> +#undef wmb
> +/* Redefine rmb() to lwsync. */
> +#define rmb()({__asm__
Hi,
Le 21/02/2023 à 23:07, Pali Rohár a écrit :
> Hello Christophe! Could you look at this v3 series?
> I addressed those small issues and hopefully it should be ready.
> It would be great to have this finally in v6.3 release.
I started looking at your series and I will try to provide a feedback
Although powerpc now has objtool mcount support, it's not enabled in all
configurations due to dependencies.
On those configurations, with some linkers (binutils 2.37 at least),
it's still possible to hit the dreaded "recordmcount bug", eg. errors
such as:
CC kernel/kexec_file.o
46 matches
Mail list logo
