Re: [PATCH v2 3/3] arch/*/: remove CONFIG_VIRT_TO_BUS

Le 30/06/2022 à 10:04, David Laight a écrit : > From: Michael Schmitz >> Sent: 29 June 2022 00:09 >> >> Hi Arnd, >> >> On 29/06/22 09:50, Arnd Bergmann wrote: >>> On Tue, Jun 28, 2022 at 11:03 PM Michael Schmitz >>> wrote: On 28/06/22 19:03, Geert Uytterhoeven wrote: >> The driver

[PATCH] iommu/fsl_pamu: Prepare cleanup of powerpc's asm/prom.h

powerpc's asm/prom.h brings some headers that it doesn't need itself. In order to clean it up, first add missing headers in users of asm/prom.h Signed-off-by: Christophe Leroy --- drivers/iommu/fsl_pamu.c| 3 +++ drivers/iommu/fsl_pamu_domain.c | 1 + 2 files changed, 4 insertions

Re: [PATCH 08/11] swiotlb: make the swiotlb_init interface more useful

Le 27/02/2022 à 15:30, Christoph Hellwig a écrit : > Pass a bool to pass if swiotlb needs to be enabled based on the > addressing needs and replace the verbose argument with a set of > flags, including one to force enable bounce buffering. > > Note that this patch removes the possibility to

Re: [PATCH v5 3/6] mm: make alloc_contig_range work at pageblock granularity

Le 11/02/2022 à 17:41, Zi Yan a écrit : > From: Zi Yan > > alloc_contig_range() worked at MAX_ORDER-1 granularity to avoid merging > pageblocks with different migratetypes. It might unnecessarily convert > extra pageblocks at the beginning and at the end of the range. Change >

Re: [PATCH 3/3] memblock: cleanup memblock_free interface

Le 23/09/2021 à 14:01, Mike Rapoport a écrit : On Thu, Sep 23, 2021 at 11:47:48AM +0200, Christophe Leroy wrote: Le 23/09/2021 à 09:43, Mike Rapoport a écrit : From: Mike Rapoport For ages memblock_free() interface dealt with physical addresses even despite the existence

Re: [PATCH 3/3] memblock: cleanup memblock_free interface

Le 23/09/2021 à 09:43, Mike Rapoport a écrit : From: Mike Rapoport For ages memblock_free() interface dealt with physical addresses even despite the existence of memblock_alloc_xx() functions that return a virtual pointer. Introduce memblock_phys_free() for freeing physical ranges and

Re: [PATCH v3 4/8] powerpc/pseries/svm: Add a powerpc version of cc_platform_has()

Le 15/09/2021 à 12:08, Borislav Petkov a écrit : On Wed, Sep 15, 2021 at 10:28:59AM +1000, Michael Ellerman wrote: I don't love it, a new C file and an out-of-line call to then call back to a static inline that for most configuration will return false ... but whatever :) Yeah, hch thinks

Re: [PATCH v3 4/8] powerpc/pseries/svm: Add a powerpc version of cc_platform_has()

Le 14/09/2021 à 13:58, Borislav Petkov a écrit : On Wed, Sep 08, 2021 at 05:58:35PM -0500, Tom Lendacky wrote: Introduce a powerpc version of the cc_platform_has() function. This will be used to replace the powerpc mem_encrypt_active() implementation, so the implementation will initially only

Re: [PATCH v3 4/8] powerpc/pseries/svm: Add a powerpc version of cc_platform_has()

On 9/8/21 10:58 PM, Tom Lendacky wrote: Introduce a powerpc version of the cc_platform_has() function. This will be used to replace the powerpc mem_encrypt_active() implementation, so the implementation will initially only support the CC_ATTR_MEM_ENCRYPT attribute. Cc: Michael Ellerman Cc:

Re: [PATCH v3 2/8] mm: Introduce a function to check for confidential computing features

On 9/8/21 10:58 PM, Tom Lendacky wrote: In prep for other confidential computing technologies, introduce a generic helper function, cc_platform_has(), that can be used to check for specific I have little problem with that naming. For me CC has always meant Compiler Collection. active

Re: [PATCH v3 8/8] treewide: Replace the use of mem_encrypt_active() with cc_platform_has()

On 9/8/21 10:58 PM, Tom Lendacky wrote: diff --git a/arch/powerpc/include/asm/mem_encrypt.h b/arch/powerpc/include/asm/mem_encrypt.h index ba9dab07c1be..2f26b8fc8d29 100644 --- a/arch/powerpc/include/asm/mem_encrypt.h +++ b/arch/powerpc/include/asm/mem_encrypt.h @@ -10,11 +10,6 @@

Re: [PATCH 07/11] treewide: Replace the use of mem_encrypt_active() with prot_guest_has()

Le 28/07/2021 à 00:26, Tom Lendacky a écrit : Replace occurrences of mem_encrypt_active() with calls to prot_guest_has() with the PATTR_MEM_ENCRYPT attribute. What about https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20210730114231.23445-1-w...@kernel.org/ ? Christophe Cc:

Re: [PATCH] iommu: spapr_tce: Disable compile testing to fix build on book3s_32 config

On 04/14/2020 02:26 PM, Krzysztof Kozlowski wrote: Although SPAPR_TCE_IOMMU itself can be compile tested on certain PowerPC configurations, its presence makes arch/powerpc/kvm/Makefile to select modules which do not build in such configuration. The arch/powerpc/kvm/ modules use

Re: [PATCH v3] crypto: talitos - fix ablkcipher for CONFIG_VMAP_STACK

Le 04/01/2019 à 16:24, Horia Geanta a écrit : On 1/4/2019 5:17 PM, Horia Geanta wrote: On 12/21/2018 10:07 AM, Christophe Leroy wrote: [snip] IV cannot be on stack when CONFIG_VMAP_STACK is selected because the stack cannot be DMA mapped anymore. This looks better, thanks. This patch

Re: [PATCH] fix double ;;s in code

Le 17/02/2018 à 22:19, Pavel Machek a écrit : Fix double ;;'s in code. Signed-off-by: Pavel Machek A summary of the files modified on top of the patch would help understand the impact. A maybe there should be one patch by area, eg one for each arch specific modif and one

Re: [PATCH 07/11] powerpc: make dma_cache_sync a no-op

Le 03/10/2017 à 13:43, Christoph Hellwig a écrit : On Tue, Oct 03, 2017 at 01:24:57PM +0200, Christophe LEROY wrote: powerpc does not implement DMA_ATTR_NON_CONSISTENT allocations, so it doesn't make any sense to do any work in dma_cache_sync given that it must be a no-op when dma_alloc_attrs

Re: [PATCH 07/11] powerpc: make dma_cache_sync a no-op

Le 03/10/2017 à 12:43, Christoph Hellwig a écrit : powerpc does not implement DMA_ATTR_NON_CONSISTENT allocations, so it doesn't make any sense to do any work in dma_cache_sync given that it must be a no-op when dma_alloc_attrs returns coherent memory. What about