Re: [PATCH 6/6] arch/*/: remove CONFIG_VIRT_TO_BUS

I_DRAM_OFFSET) > - > #endif /* CONFIG_PPC32 */ Seems that's not used by any drivers, so fine to remove. Acked-by: Michael Ellerman (powerpc) cheers ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH kernel] powerpc/iommu: Report the correct most efficient DMA mask for PCI devices

On Thu, 30 Sep 2021 13:44:54 +1000, Alexey Kardashevskiy wrote: > According to dma-api.rst, the dma_get_required_mask() helper should return > "the mask that the platform requires to operate efficiently". Which in > the case of PPC64 means the bypass mask and not a mask from an IOMMU table > which

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

Christoph Hellwig writes: > On Wed, Sep 15, 2021 at 07:18:34PM +0200, Christophe Leroy wrote: >> Could you please provide more explicit explanation why inlining such an >> helper is considered as bad practice and messy ? > > Because now we get architectures to all subly differ. Look at the mess

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

nitially only support the CC_ATTR_MEM_ENCRYPT >> attribute. >> >> Cc: Michael Ellerman >> Cc: Benjamin Herrenschmidt >> Cc: Paul Mackerras >> Signed-off-by: Tom Lendacky >> --- >> arch/powerpc/platforms/pseries/Kconfig | 1 + >> arch/powerpc

Re: [PATCH v2 04/12] powerpc/pseries/svm: Add a powerpc version of prot_guest_has()

Tom Lendacky writes: > Introduce a powerpc version of the prot_guest_has() function. This will > be used to replace the powerpc mem_encrypt_active() implementation, so > the implementation will initially only support the PATTR_MEM_ENCRYPT > attribute. > > Cc: Michael Ellerm

Re: [PATCH] powerpc/svm: Don't issue ultracalls if !mem_encrypt_active()

gt; Signed-off-by: Will Deacon > --- > arch/powerpc/platforms/pseries/svm.c | 6 ++ > 1 file changed, 6 insertions(+) Thanks. Acked-by: Michael Ellerman I assume Konrad will take this via the swiotlb tree? cheers ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH kernel v4 2/2] powerpc/dma: Fallback to dma_ops when persistent memory present

ops. > > This should not change the existing behaviour when no persistent memory > as dev->dma_ops_bypass is expected to be set. > > Signed-off-by: Alexey Kardashevskiy Acked-by: Michael Ellerman cheers ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH kernel v3 2/2] powerpc/dma: Fallback to dma_ops when persistent memory present

Alexey Kardashevskiy writes: > On 29/10/2020 11:40, Michael Ellerman wrote: >> Alexey Kardashevskiy writes: >>> @@ -1126,7 +1129,7 @@ static u64 enable_ddw(struct pci_dev *dev, struct >>> device_node *pdn) >>> >>> mutex_lock

Re: [PATCH kernel v3 2/2] powerpc/dma: Fallback to dma_ops when persistent memory present

Alexey Kardashevskiy writes: > diff --git a/arch/powerpc/platforms/pseries/iommu.c > b/arch/powerpc/platforms/pseries/iommu.c > index e4198700ed1a..91112e748491 100644 > --- a/arch/powerpc/platforms/pseries/iommu.c > +++ b/arch/powerpc/platforms/pseries/iommu.c > @@ -,11 +1112,13 @@ static

Re: [PATCH v3] powerpc/pseries/svm: Allocate SWIOTLB buffer anywhere in memory

On Tue, 18 Aug 2020 19:11:26 -0300, Thiago Jung Bauermann wrote: > POWER secure guests (i.e., guests which use the Protection Execution > Facility) need to use SWIOTLB to be able to do I/O with the hypervisor, but > they don't need the SWIOTLB memory to be in low addresses since the > hypervisor

Re: [PATCH v3] powerpc/pseries/svm: Allocate SWIOTLB buffer anywhere in memory

Christoph Hellwig writes: > On Tue, Aug 18, 2020 at 07:11:26PM -0300, Thiago Jung Bauermann wrote: >> POWER secure guests (i.e., guests which use the Protection Execution >> Facility) need to use SWIOTLB to be able to do I/O with the hypervisor, but >> they don't need the SWIOTLB memory to be in

Re: [PATCH 06/15] powerpc: fadamp: simplify fadump_reserve_crash_area()

Mike Rapoport writes: > On Thu, Jul 30, 2020 at 10:15:13PM +1000, Michael Ellerman wrote: >> Mike Rapoport writes: >> > From: Mike Rapoport >> > >> > fadump_reserve_crash_area() reserves memory from a specified base address >> > till the end of

Re: [PATCH 06/15] powerpc: fadamp: simplify fadump_reserve_crash_area()

k this looks OK to me, but I don't have a setup to test it easily. I've added Hari to Cc who might be able to. But I'll give you an ack in the hope that it works :) Acked-by: Michael Ellerman > diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c > index 78ab9a6ee

Re: [PATCH 13/13] powerpc/dma: Remove dev->archdata.iommu_domain

e are no users left just with grep, but I think you've got them all, and the compiler should tell us if you've missed any. Acked-by: Michael Ellerman (powerpc) cheers > diff --git a/arch/powerpc/include/asm/device.h > b/arch/powerpc/include/asm/device.h > index 266542769e4b..1bc5952

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

Christophe Leroy writes: > 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

Re: [PATCH] powerpc: ensure that swiotlb buffer is allocated from low memory

On Wed, 2019-12-04 at 12:35:24 UTC, Mike Rapoport wrote: > From: Mike Rapoport > > Some powerpc platforms (e.g. 85xx) limit DMA-able memory way below 4G. If a > system has more physical memory than this limit, the swiotlb buffer is not > addressable because it is allocated from memblock using

Re: [PATCH] powerpc: ensure that swiotlb buffer is allocated from low memory

t caused it? Was it 25078dc1f74b ("powerpc: use mm zones more sensibly") ? Or was that a red herring? cheers > Reported-by: Christian Zigotzky > Signed-off-by: Mike Rapoport > Cc: Benjamin Herrenschmidt > Cc: Christoph Hellwig > Cc: Darren Stevens > Cc: mad skatema

Re: [PATCH 3/3] powerpc: remove support for NULL dev in __phys_to_dma / __dma_to_phys

h/powerpc/include/asm/dma-direct.h | 4 > 1 file changed, 4 deletions(-) Acked-by: Michael Ellerman cheers > diff --git a/arch/powerpc/include/asm/dma-direct.h > b/arch/powerpc/include/asm/dma-direct.h > index e29e8a236b8d..abc154d784b0 100644 > --- a/arch/powerpc/include/a

Re: [PATCH 1/3] dma-direct: unify the dma_capable definitions

direct.h| 8 > arch/powerpc/include/asm/dma-direct.h | 9 ----- Looks OK to me. Acked-by: Michael Ellerman (powerpc) cheers > diff --git a/arch/arm/include/asm/dma-direct.h > b/arch/arm/include/asm/dma-direct.h > index b67e5fc1fe43..7c3001a6a775 100644 > --- a/ar

Re: [GIT PULL] dma-mapping updates for 5.4

trivial >>functions added in powerpc and microblaze adding the calls >>need to be removed for the code to compile. This will not show up >>as a merge conflict and needs to be dealt with manually! > >So I haven't gotten the powerpc or microblaze pull requests yet, so &

Re: [PATCH v4 1/6] x86, s390: Move ARCH_HAS_MEM_ENCRYPT definition to arch/Kconfig

On Tue, 2019-08-06 at 04:49:14 UTC, Thiago Jung Bauermann wrote: > powerpc is also going to use this feature, so put it in a generic location. > > Signed-off-by: Thiago Jung Bauermann > Reviewed-by: Thomas Gleixner > Reviewed-by: Christoph Hellwig Series applied to powerpc topic/mem-encrypt,

Re: [PATCH v2 09/11] dma-direct: turn ARCH_ZONE_DMA_BITS into a variable

Nicolas Saenz Julienne writes: > diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h > index 0d52f57fca04..73668a21ae78 100644 > --- a/arch/powerpc/include/asm/page.h > +++ b/arch/powerpc/include/asm/page.h > @@ -319,13 +319,4 @@ struct vm_area_struct; > #endif /*

Re: [PATCH] powerpc/dma: Fix invalid DMA mmap behavior

Shawn Anastasio writes: > On 7/22/19 7:16 AM, Michael Ellerman wrote: >> Arnd Bergmann writes: >>> On Thu, Jul 18, 2019 at 11:52 AM Christoph Hellwig wrote: >>>> On Thu, Jul 18, 2019 at 10:49:34AM +0200, Christoph Hellwig wrote: >>>>> On Thu, Jul 18

Re: [PATCH] powerpc/dma: Fix invalid DMA mmap behavior

Arnd Bergmann writes: > On Thu, Jul 18, 2019 at 11:52 AM Christoph Hellwig wrote: >> On Thu, Jul 18, 2019 at 10:49:34AM +0200, Christoph Hellwig wrote: >> > On Thu, Jul 18, 2019 at 01:45:16PM +1000, Oliver O'Halloran wrote: >> > > > Other than m68k, mips, and arm64, everybody else that doesn't

Re: [01/32] net: pasemi: set a 64-bit DMA mask on the DMA device

On Wed, 2019-02-13 at 07:01:02 UTC, Christoph Hellwig wrote: > The pasemi driver never set a DMA mask, and given that the powerpc > DMA mapping routines never check it this worked ok so far. But the > generic dma-direct code which I plan to switch on for powerpc checks > the DMA mask and fails

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

Christophe Leroy writes: > 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.

Re: use generic DMA mapping code in powerpc V4

Christoph Hellwig writes: > FYI, given that we are one week before the expected 4.20 release > date and I haven't found the bug plaging Christians setups I think > we need to defer most of this to the next merge window. OK, sorry I couldn't help. I tried powering up my pasemi board last week

Re: [PATCH 12/34] powerpc/cell: move dma direct window setup out of dma_configure

Christoph Hellwig writes: > On Sun, Dec 09, 2018 at 09:23:39PM +1100, Michael Ellerman wrote: >> Christoph Hellwig writes: >> >> > Configure the dma settings at device setup time, and stop playing games >> > with get_pci_dma_ops. This prepares for using the com

Re: [PATCH 12/34] powerpc/cell: move dma direct window setup out of dma_configure

Christoph Hellwig writes: > Configure the dma settings at device setup time, and stop playing games > with get_pci_dma_ops. This prepares for using the common dma_configure > code later on. > > Signed-off-by: Christoph Hellwig > --- > arch/powerpc/platforms/cell/iommu.c | 20

Re: [PATCH 01/34] powerpc: use mm zones more sensibly

Christoph Hellwig writes: > Ben / Michael, > > can we get this one queued up for 4.21 to prepare for the DMA work later > on? I was hoping the PASEMI / NXP regressions could be solved before merging. My p5020ds is booting fine with this series, so I'm not sure why it's causing problems on

Re: use generic DMA mapping code in powerpc V4

Christoph Hellwig writes: > Any comments? I'd like to at least get the ball moving on the easy > bits. Nothing specific yet. I'm a bit worried it might break one of the many old obscure platforms we have that aren't well tested. There's not much we can do about that, but I'll just try and

Re: [PATCH V2] mm: Replace all open encodings for NUMA_NO_NODE

| 6 +++--- > arch/ia64/sn/kernel/io_common.c | 3 ++- > arch/powerpc/include/asm/pci-bridge.h | 3 ++- > arch/powerpc/kernel/paca.c| 3 ++- > arch/powerpc/kernel/pci-common.c | 3 ++- > arch/powerpc/mm/numa.c

Re: [PATCH 4/4] dma-mapping: clear dev->dma_ops in arch_teardown_dma_ops

Christoph Hellwig writes: > Looking at the code I think this commit is simply broken for > architectures not using arch_setup_dma_ops, but instead setting up > the dma ops through arch specific magic. I arch_setup_dma_ops() called from of_dma_configure(), but pci_dma_configure() doesn't call

Re: [PATCH 4/4] dma-mapping: clear dev->dma_ops in arch_teardown_dma_ops

Guenter Roeck writes: > Hi, > > On Mon, Aug 27, 2018 at 10:47:11AM +0200, Christoph Hellwig wrote: >> There is no reason to leave the per-device dma_ops around when >> deconfiguring a device, so move this code from arm64 into the >> common code. >> Signed-off-by: Christoph Hellwig >>

Re: powerpc: do not redefined NEED_DMA_MAP_STATE

On Mon, 2018-07-30 at 07:37:21 UTC, Christoph Hellwig wrote: > kernel/dma/Kconfig already defines NEED_DMA_MAP_STATE, just select it > from PPC64 and NOT_COHERENT_CACHE instead. > > Signed-off-by: Christoph Hellwig Applied to powerpc next, thanks.

Re: [PATCH] powerpc: do not redefined NEED_DMA_MAP_STATE

ype | 2 ++ > 2 files changed, 2 insertions(+), 3 deletions(-) Thanks. I did this instead: commit 870771ae76010c5e42ee8e0278f5823e46e96e3f (HEAD -> next-test) Author: Christoph Hellwig AuthorDate: Mon Jul 30 09:37:21 2018 +0200 Commit: Michael Ellerman CommitDate: Tue Jul 31 20:43

Re: [PATCH] PCI: call dma_debug_add_bus for pci_bus_type in common code

/arch/powerpc/kernel/dma.c > @@ -357,9 +357,6 @@ EXPORT_SYMBOL_GPL(dma_get_required_mask); > > static int __init dma_init(void) > { > -#ifdef CONFIG_PCI > - dma_debug_add_bus(_bus_type); > -#endif > #ifdef CONFIG_IBMVIO > dma_debug_add_

Re: [PATCH 01/12] iommu-common: move to arch/sparc

Anshuman Khandual writes: > On 04/16/2018 07:28 PM, David Miller wrote: >> From: Anshuman Khandual >> Date: Mon, 16 Apr 2018 14:26:07 +0530 >> >>> On 04/15/2018 08:29 PM, Christoph Hellwig wrote: This code is only used by sparc, and

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

Daniel Vetter writes: > On Sun, Feb 18, 2018 at 11:00:56AM +0100, Christophe LEROY wrote: >> 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

Re: [PATCH] headers: untangle kmemleak.h from mm.h

Randy Dunlap <rdun...@infradead.org> writes: > On 02/12/2018 04:28 AM, Michael Ellerman wrote: >> Randy Dunlap <rdun...@infradead.org> writes: >> >>> From: Randy Dunlap <rdun...@infradead.org> >>> >>> Currently #includes for no o

Re: [PATCH] headers: untangle kmemleak.h from mm.h

Randy Dunlap writes: > From: Randy Dunlap > > Currently #includes for no obvious > reason. It looks like it's only a convenience, so remove kmemleak.h > from slab.h and add to any users of kmemleak_* > that don't already #include it. > Also

Re: [PATCH 16/67] powerpc: rename dma_direct_ to dma_nommu_

Geert Uytterhoeven <ge...@linux-m68k.org> writes: > On Tue, Jan 2, 2018 at 10:45 AM, Michael Ellerman <m...@ellerman.id.au> wrote: >> Christoph Hellwig <h...@lst.de> writes: >> >>> We want to use the dma_direct_ namespace for a generic implementation

Re: [PATCH 16/67] powerpc: rename dma_direct_ to dma_nommu_

Christoph Hellwig writes: > We want to use the dma_direct_ namespace for a generic implementation, > so rename powerpc to the second best choice: dma_nommu_. I'm not a fan of "nommu". Some of the users of direct ops *are* using an IOMMU, they're just setting up a 1:1 mapping once

Re: [PATCH 4/4] iommu/pamu: Add support for generic iommu-device

Joerg Roedel <j...@8bytes.org> writes: > Hi Michael, > > On Thu, Aug 24, 2017 at 12:04:13PM +1000, Michael Ellerman wrote: >> Joerg Roedel <j...@8bytes.org> writes: >> > Can you please try the attached patch? >> >> Thanks, that works. > &

Re: [PATCH 4/4] iommu/pamu: Add support for generic iommu-device

Joerg Roedel <j...@8bytes.org> writes: > Hello Michael, > > On Wed, Aug 23, 2017 at 10:17:39PM +1000, Michael Ellerman wrote: > >> [0.358192] Call Trace: >> [0.360624] [c000f7173680] [c000f7173710] 0xc000f7173710 >> (unreliable)

Re: [PATCH 4/4] iommu/pamu: Add support for generic iommu-device

Joerg Roedel writes: > From: Joerg Roedel > > This patch adds a global iommu-handle to the pamu driver and > initializes it at probe time. Also link devices added to the > iommu to this handle. > > Signed-off-by: Joerg Roedel > --- >

Re: [PATCH 21/44] powerpc: implement ->mapping_error

, the ps3 code is probably better left alone these days. Acked-by: Michael Ellerman <m...@ellerman.id.au> cheers ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH] powerpc: Fix incorrect PPC32 PAMU dependency

On Thu, 2016-02-04 at 20:16 -0600, Andy Fleming wrote: > The Freescale PAMU can also be enabled on 64-bit power > chips. Commit 477ab7a19cec8409e4e2dd10e7348e4cac3c06e5 > (iommu: Make more drivers depend on COMPILE_TEST) > added this false dependency. Fixed it by allowing PPC64, too. > >

Re: [v7,58/60] PCI: Introduce resource_disabled()

S; i++) { > res = >resource[i + PCI_IOV_RESOURCES]; > - if (!res->flags || res->parent) > + if (resource_disabled(res) || res->parent) > continue; > if (!pnv_pci_is_mem_pref_64(res->flags)) { >

Re: [PATCH v1 15/21] Powerpc/MSI: Use MSI chip framework to configure MSI/MSI-X irq

-by: Michael Ellerman m...@ellerman.id.au (powerpc) cheers ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 1/3] PCI/MSI: Add pci_enable_msi_partial()

On Wed, 2014-07-02 at 14:22 -0600, Bjorn Helgaas wrote: On Tue, Jun 10, 2014 at 03:10:30PM +0200, Alexander Gordeev wrote: There are PCI devices that require a particular value written to the Multiple Message Enable (MME) register while aligned on power of 2 boundary value of actually used