Re: fully convert arm to use dma-direct v3

2022-07-07 Thread Arnd Bergmann
On Thu, Jul 7, 2022 at 6:58 AM Christoph Hellwig wrote: > On Wed, Jun 29, 2022 at 08:41:32AM +0200, Greg Kroah-Hartman wrote: > > On Wed, Jun 29, 2022 at 08:28:37AM +0200, Christoph Hellwig wrote: > > > Any comments or additional testing? It would be really great to get > > > this off the table.

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

2022-06-28 Thread Arnd Bergmann
On Tue, Jun 28, 2022 at 11:38 PM Michael Schmitz wrote: > On 28/06/22 19:08, Arnd Bergmann wrote: > > I see two other problems with your patch though: > > > > a) you still duplicate the cache handling: the cache_clear()/cache_push() > > is supposed to already be do

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

2022-06-28 Thread Arnd Bergmann
On Tue, Jun 28, 2022 at 11:03 PM Michael Schmitz wrote: > On 28/06/22 19:03, Geert Uytterhoeven wrote: > >> The driver allocates bounce buffers using kmalloc if it hits an > >> unaligned data buffer - can such buffers still even happen these days? > > No idea. > Hmmm - I think I'll stick a

Re: [PATCH v3 0/3] phase out CONFIG_VIRT_TO_BUS

2022-06-28 Thread Arnd Bergmann
On Tue, Jun 28, 2022 at 4:59 AM Martin K. Petersen wrote: > Hi Arnd! > > > If there are no more issues identified with this series, I'll merge it > > through the asm-generic tree. The SCSI patches can also get merged > > separately through the SCSI maintainers' tree if they prefer. > > I put

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

2022-06-28 Thread Arnd Bergmann
On Tue, Jun 28, 2022 at 5:25 AM Michael Schmitz wrote: > Am 28.06.2022 um 09:12 schrieb Michael Schmitz: > > Leaving the bounce buffer handling in place, and taking a few other > liberties - this is what converting the easiest case (a3000 SCSI) might > look like. Any obvious mistakes? The mvme147

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

2022-06-26 Thread Arnd Bergmann
(On Sun, Jun 26, 2022 at 7:21 AM Michael Schmitz wrote: > > The same could be done for the two vme drivers (scsi/mvme147.c > > and ethernet/82596.c), which do the cache management but > > apparently don't need swiotlb bounce buffering. > > > > Rewriting the drivers to modern APIs is of course

Re: [PATCH v3 0/3] phase out CONFIG_VIRT_TO_BUS

2022-06-24 Thread Arnd Bergmann
On Fri, Jun 24, 2022 at 5:52 PM Arnd Bergmann wrote: > Arnd Bergmann (3): > scsi: BusLogic remove bus_to_virt > scsi: dpt_i2o: remove obsolete driver The dpt_i2o removal is overly large and got dropped by some of the mailing lists, if anyone wants to see the full patch, it

[PATCH v3 3/3] arch/*/: remove CONFIG_VIRT_TO_BUS

2022-06-24 Thread Arnd Bergmann
From: Arnd Bergmann All architecture-independent users of virt_to_bus() and bus_to_virt() have been fixed to use the dma mapping interfaces or have been removed now. This means the definitions on most architectures, and the CONFIG_VIRT_TO_BUS symbol are now obsolete and can be removed

[PATCH v3 1/3] scsi: BusLogic remove bus_to_virt

2022-06-24 Thread Arnd Bergmann
From: Arnd Bergmann The BusLogic driver is the last remaining driver that relies on the deprecated bus_to_virt() function, which in turn only works on a few architectures, and is incompatible with both swiotlb and iommu support. Before commit 391e2f25601e ("[SCSI] BusLogic: Port driver

[PATCH v3 0/3] phase out CONFIG_VIRT_TO_BUS

2022-06-24 Thread Arnd Bergmann
From: Arnd Bergmann The virt_to_bus/bus_to_virt interface has been deprecated for decades. After Jakub Kicinski put a lot of work into cleaning out the network drivers using them, there are only a couple of other drivers left, which can all be removed or otherwise cleaned up, to remove the old

Re: [PATCH v2 2/3] scsi: BusLogic remove bus_to_virt

2022-06-24 Thread Arnd Bergmann
On Fri, Jun 24, 2022 at 5:38 PM Khalid Aziz wrote: > On 6/23/22 08:47, Arnd Bergmann wrote: > > Driver works with this change. next_inbox is the correct pointer to pass. Ok, great! I'll add a 'Tested-by' line then. I was already in the process of preparing a v3 patch set, will send out

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

2022-06-24 Thread Arnd Bergmann
On Sat, Jun 18, 2022 at 3:06 AM Michael Schmitz wrote: > Am 18.06.2022 um 00:57 schrieb Arnd Bergmann: > > > > All architecture-independent users of virt_to_bus() and bus_to_virt() > > have been fixed to use the dma mapping interfaces or have been > > removed now.

Re: [PATCH v2 2/3] scsi: BusLogic remove bus_to_virt

2022-06-23 Thread Arnd Bergmann
On Tue, Jun 21, 2022 at 11:56 PM Khalid Aziz wrote: > > while ((comp_code = next_inbox->comp_code) != BLOGIC_INBOX_FREE) { > > - /* > > -We are only allowed to do this because we limit our > > -architectures we run on to machines where

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

2022-06-17 Thread Arnd Bergmann
From: Arnd Bergmann All architecture-independent users of virt_to_bus() and bus_to_virt() have been fixed to use the dma mapping interfaces or have been removed now. This means the definitions on most architectures, and the CONFIG_VIRT_TO_BUS symbol are now obsolete and can be removed

[PATCH v2 2/3] scsi: BusLogic remove bus_to_virt

2022-06-17 Thread Arnd Bergmann
From: Arnd Bergmann The BusLogic driver is the last remaining driver that relies on the deprecated bus_to_virt() function, which in turn only works on a few architectures, and is incompatible with both swiotlb and iommu support. Before commit 391e2f25601e ("[SCSI] BusLogic: Port driver

[PATCH v2 0/3] phase out CONFIG_VIRT_TO_BUS

2022-06-17 Thread Arnd Bergmann
From: Arnd Bergmann The virt_to_bus/bus_to_virt interface has been deprecated for decades. After Jakub Kicinski put a lot of work into cleaning out the network drivers using them, there are only a couple of other drivers left, which can all be removed or otherwise cleaned up, to remove the old

[PATCH v2 1/3] scsi: dpt_i2o: drop stale VIRT_TO_BUS dependency

2022-06-17 Thread Arnd Bergmann
From: Arnd Bergmann The dpt_i2o driver was fixed to stop using virt_to_bus() in 2008, but it still has a stale reference in an error handling code path that could never work. Fix it up to build without VIRT_TO_BUS and remove the Kconfig dependency. The alternative to this would be to just

Re: [PATCH 5/6] scsi: remove stale BusLogic driver

2022-06-08 Thread Arnd Bergmann
On Mon, Jun 6, 2022 at 6:35 PM Khalid Aziz wrote: > On 6/6/22 02:41, Arnd Bergmann wrote: From: Arnd Bergmann > > I would say no to removing BusLogic driver. Virtualbox is another > consumer of this driver. This driver is very old but I would rather fix > the issues than remove

Re: [PATCH 0/6] phase out CONFIG_VIRT_TO_BUS

2022-06-06 Thread Arnd Bergmann
On Mon, Jun 6, 2022 at 11:25 AM Greg Kroah-Hartman wrote: > > I'll take patches 1 and 2 right now through my staging tree if that's > ok. Yes, that's perfect, as there are no actual interdependencies with the other drivers -- applying the last patch first would just hide the driver I'm removing

Re: [PATCH 5/6] scsi: remove stale BusLogic driver

2022-06-06 Thread Arnd Bergmann
On Mon, Jun 6, 2022 at 12:40 PM Maciej W. Rozycki wrote: > > On Mon, 6 Jun 2022, Arnd Bergmann wrote: > > > This was in turn fixed in commit 56f396146af2 ("scsi: BusLogic: Fix > > 64-bit system enumeration error for Buslogic"), 8 years later. > > &g

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

2022-06-06 Thread Arnd Bergmann
From: Arnd Bergmann All architecture-independent users of virt_to_bus() and bus_to_virt() have been fixed to use the dma mapping interfaces or have been removed now. This means the definitions on most architectures, and the CONFIG_VIRT_TO_BUS symbol are now obsolete and can be removed

[PATCH 4/6] scsi: dpt_i2o: drop stale VIRT_TO_BUS dependency

2022-06-06 Thread Arnd Bergmann
From: Arnd Bergmann The dpt_i2o driver was fixed to stop using virt_to_bus() in 2008 but it a stale reference in a broken error handling code path that could never work. Fix it up to build without VIRT_TO_BUS and remove the Kconfig dependency. The alternative to this would be to just remove

[PATCH 3/6] media: sta2x11: remove VIRT_TO_BUS dependency

2022-06-06 Thread Arnd Bergmann
From: Arnd Bergmann This driver does not use the virt_to_bus() function, though it depends on x86 specific fixups in the swiotlb code, which was last rewritten in commit e380a0394c36 ("x86/PCI: sta2x11: use default DMA address translation"). It is possible that the driver still fail

[PATCH 1/6] vme: remove ca91cx42 Universe-II support

2022-06-06 Thread Arnd Bergmann
From: Arnd Bergmann This is one of four remaining drivers using the ancient virt_to_bus() interface instead of the dma-mapping interface, making it incompatible with most modern machines. As nobody has cleaned this up, there is a high chance that this driver has no actual users. The chip

[PATCH 2/6] vme: move back to staging

2022-06-06 Thread Arnd Bergmann
From: Arnd Bergmann The VME subsystem graduated from staging into a top-level subsystem in 2012, with commit db3b9e990e75 ("Staging: VME: move VME drivers out of staging") stating: The VME device drivers have not moved out yet due to some API questions they are still worki

[PATCH 0/6] phase out CONFIG_VIRT_TO_BUS

2022-06-06 Thread Arnd Bergmann
From: Arnd Bergmann The virt_to_bus/bus_to_virt interface has been deprecated for decades. After Jakub Kicinski put a lot of work into cleaning out the network drivers using them, there are only a couple of other drivers left, which can all be removed or otherwise cleaned up, to remove the old

Re: [PATCH 04/10] ARM/dma-mapping: remove the unused virt_to_dma helper

2022-05-02 Thread Arnd Bergmann
On Mon, May 2, 2022 at 6:43 PM Christoph Hellwig wrote: > > virt_to_dma was only used by the now removed dmabounce code. > > Signed-off-by: Christoph Hellwig Reviewed-by: Arnd Bergmann ___ iommu mailing list iommu@lists.linux-foundati

Re: fully convert arm to use dma-direct

2022-04-21 Thread Arnd Bergmann
On Thu, Apr 21, 2022 at 9:41 AM Christoph Hellwig wrote: > > Hi all, > > arm is the last platform not using the dma-direct code for directly > mapped DMA. With the dmaboune removal from Arnd we can easily switch > arm to always use dma-direct now (it already does for LPAE configs > and nommu).

Re: [PATCH 7/7] ARM: use dma-direct unconditionally

2022-04-21 Thread Arnd Bergmann
arch/arm/include/asm/dma-mapping.h The diffstat looks really nice! I can't really tell from looking at the code if this is an equivalent conversion, so I have to trust you on that. I did make sure this passes the basic tests on kernelci.org, which tests a large number of mac

Re: [PATCH 6/7] ARM: use the common dma_to_phys/phys_to_dma implementation where possible

2022-04-21 Thread Arnd Bergmann
gt; indirection. > > Signed-off-by: Christoph Hellwig Reviewed-by: Arnd Bergmann > --- > @@ -335,17 +336,19 @@ unsigned long __bus_to_virt(unsigned long res) > return res; > } > EXPORT_SYMBOL(__bus_to_virt); > - > -unsigned long __pfn_to_bus(unsigned long pf

Re: [PATCH 5/7] ARM: use dma_to_phys/phys_to_dma in the dma-mapping code

2022-04-21 Thread Arnd Bergmann
On Thu, Apr 21, 2022 at 9:42 AM Christoph Hellwig wrote: > > Use the helpers as expected by the dma-direct code in the old arm > dma-mapping code to ease a gradual switch to the common DMA code. > > Signed-off-by: Christoph Hellwig Reviewed-by

Re: [PATCH 4/7] ARM: remove the unused virt_to_dma helper

2022-04-21 Thread Arnd Bergmann
On Thu, Apr 21, 2022 at 9:42 AM Christoph Hellwig wrote: > > Signed-off-by: Christoph Hellwig I generally prefer to have at least something useful in the description, e.g. why it's now unused and what it was used for before. > -static inline dma_addr_t virt_to_dma(struct device *dev, void

Re: [PATCH 3/7] ARM: mark various dma-mapping routines static in dma-mapping.c

2022-04-21 Thread Arnd Bergmann
Hellwig Reviewed-by: Arnd Bergmann ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 2/7] ARM: remove dmabounce

2022-04-21 Thread Arnd Bergmann
On Thu, Apr 21, 2022 at 9:41 AM Christoph Hellwig wrote: > > Remove the now unused dmabounce code. > > Signed-off-by: Christoph Hellwig Reviewed-by: Arnd Bergmann ___ iommu mailing list iommu@lists.linux-foundati

Re: [patch V3 12/35] soc: ti: ti_sci_inta_msi: Allocate MSI device data on first use

2021-12-11 Thread Arnd Bergmann
t; Cc: Nishanth Menon > Cc: Tero Kristo > Cc: Santosh Shilimkar > Cc: linux-arm-ker...@lists.infradead.org Acked-by: Arnd Bergmann ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [patch V3 34/35] soc: ti: ti_sci_inta_msi: Get rid of ti_sci_inta_msi_get_virq()

2021-12-11 Thread Arnd Bergmann
; Cc: Vinod Koul > Cc: dmaeng...@vger.kernel.org Acked-by: Arnd Bergmann ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [patch V3 07/35] device: Move MSI related data into a struct

2021-12-11 Thread Arnd Bergmann
it. The other MSI specific > parts are going to be removed from struct device in later steps. > > Signed-off-by: Thomas Gleixner > Reviewed-by: Greg Kroah-Hartman > Reviewed-by: Jason Gunthorpe Acked-by: Arnd Bergmann ___ iom

Re: [patch V3 05/35] powerpc/cell/axon_msi: Use PCI device property

2021-12-11 Thread Arnd Bergmann
On Fri, Dec 10, 2021 at 11:18 PM Thomas Gleixner wrote: > > From: Thomas Gleixner > > instead of fiddling with MSI descriptors. > > Signed-off-by: Thomas Gleixner > Cc: Arnd Bergmann > Cc: Michael Ellerman > Cc: Benjamin Herrenschmidt > Cc: linuxppc-...@lists.oz

Re: [RFC 2/2] drm/msm/gem: Make use of the system cache

2021-11-16 Thread Arnd Bergmann
On Wed, Nov 17, 2021 at 12:16 AM Georgi Djakov wrote: > > Instead of writing to WC cmdstream buffers that go all the way to the main > memory, let's use the system cache to improve the performance. > > Signed-off-by: Georgi Djakov > --- > drivers/gpu/drm/msm/msm_gem.c | 2 +- > 1 file changed,

Re: [PATCH] iommu/arm: fix ARM_SMMU_QCOM compilation

2021-10-13 Thread Arnd Bergmann
On Wed, Oct 13, 2021 at 6:20 PM Will Deacon wrote: > On Wed, Oct 13, 2021 at 10:33:55AM +0200, Arnd Bergmann wrote: > > On Wed, Oct 13, 2021 at 9:58 AM Will Deacon wrote: > > > On Tue, Oct 12, 2021 at 05:18:00PM +0200, Arnd Bergmann wrote: > > I was hoping you and Jo

Re: [PATCH] iommu/arm: fix ARM_SMMU_QCOM compilation

2021-10-13 Thread Arnd Bergmann
On Wed, Oct 13, 2021 at 9:58 AM Will Deacon wrote: > On Tue, Oct 12, 2021 at 05:18:00PM +0200, Arnd Bergmann wrote: > > From: Arnd Bergmann > > > > My previous bugfix ended up making things worse for the QCOM IOMMU > > driver when it forgot to add the Kconfig

[PATCH] iommu/arm: fix ARM_SMMU_QCOM compilation

2021-10-12 Thread Arnd Bergmann
From: Arnd Bergmann My previous bugfix ended up making things worse for the QCOM IOMMU driver when it forgot to add the Kconfig symbol that is getting used to control the compilation of the SMMU implementation specific code for Qualcomm. Fixes: 424953cf3c66 ("qcom_scm: hide Kconfig s

Re: [PATCH] iommu: fix ARM_SMMU vs QCOM_SCM compilation

2021-10-11 Thread Arnd Bergmann
On Mon, Oct 11, 2021 at 11:10 AM Dmitry Baryshkov wrote: > > On Mon, 11 Oct 2021 at 09:09, Arnd Bergmann wrote: > > > > On Mon, Oct 11, 2021 at 6:11 AM Dmitry Baryshkov > > wrote: > > > On Sun, 10 Oct 2021 at 20:42, Arnd Bergmann wrote: > > > >

Re: [PATCH] iommu: fix ARM_SMMU vs QCOM_SCM compilation

2021-10-11 Thread Arnd Bergmann
On Mon, Oct 11, 2021 at 6:11 AM Dmitry Baryshkov wrote: > On Sun, 10 Oct 2021 at 20:42, Arnd Bergmann wrote: > > The patch seems correct, but it becomes overcomplicated. What about: > - restoring QCOM_SCM stubs The stubs are what has led to the previous bugs in this area to often

Re: [PATCH] iommu: fix ARM_SMMU vs QCOM_SCM compilation

2021-10-10 Thread Arnd Bergmann
tting used to control the compilation of the SMMU implementation specific code for Qualcomm. Fixes: 424953cf3c66 ("qcom_scm: hide Kconfig symbol") Reported-by: Daniel Lezcano Reported-by: Dmitry Baryshkov Signed-off-by: Arnd Bergmann diff --git a/drivers/iommu/Kconfig b/drivers/

[PATCH v2 2/2] qcom_scm: hide Kconfig symbol

2021-10-07 Thread Arnd Bergmann
From: Arnd Bergmann Now that SCM can be a loadable module, we have to add another dependency to avoid link failures when ipa or adreno-gpu are built-in: aarch64-linux-ld: drivers/net/ipa/ipa_main.o: in function `ipa_probe': ipa_main.c:(.text+0xfc4): undefined reference to `qcom_scm_is_available

[PATCH v2 1/2] firmware: include drivers/firmware/Kconfig unconditionally

2021-10-07 Thread Arnd Bergmann
From: Arnd Bergmann Compile-testing drivers that require access to a firmware layer fails when that firmware symbol is unavailable. This happened twice this week: - My proposed to change to rework the QCOM_SCM firmware symbol broke on ppc64 and others. - The cs_dsp firmware patch added

Re: [PATCH] [RFC] qcom_scm: hide Kconfig symbol

2021-09-29 Thread Arnd Bergmann
On Wed, Sep 29, 2021 at 4:46 PM Bjorn Andersson wrote: > > On Wed 29 Sep 05:04 CDT 2021, Arnd Bergmann wrote: > > > On Wed, Sep 29, 2021 at 11:51 AM Will Deacon wrote: > > > On Mon, Sep 27, 2021 at 05:22:13PM +0200, Arnd Bergmann wrote: > > > > > >

Re: [PATCH] [RFC] qcom_scm: hide Kconfig symbol

2021-09-29 Thread Arnd Bergmann
On Wed, Sep 29, 2021 at 11:51 AM Will Deacon wrote: > On Mon, Sep 27, 2021 at 05:22:13PM +0200, Arnd Bergmann wrote: > > > > diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig > > index 124c41adeca1..989c83acbfee 100644 > > --- a/drivers/iommu/Kconfig >

[PATCH 2/2] [v2] qcom_scm: hide Kconfig symbol

2021-09-28 Thread Arnd Bergmann
From: Arnd Bergmann Now that SCM can be a loadable module, we have to add another dependency to avoid link failures when ipa or adreno-gpu are built-in: aarch64-linux-ld: drivers/net/ipa/ipa_main.o: in function `ipa_probe': ipa_main.c:(.text+0xfc4): undefined reference to `qcom_scm_is_available

Re: [PATCH] [RFC] qcom_scm: hide Kconfig symbol

2021-09-28 Thread Arnd Bergmann
On Tue, Sep 28, 2021 at 9:05 AM Kalle Valo wrote: > Arnd Bergmann writes: > > From: Arnd Bergmann > I assume I can continue to build test ATH10K_SNOC with x86 as before? > That's important for me. If yes, then: > > Acked-by: Kalle Valo > > -- > https://patc

Re: [PATCH] [RFC] qcom_scm: hide Kconfig symbol

2021-09-27 Thread Arnd Bergmann
On Mon, Sep 27, 2021 at 10:42 PM Bjorn Andersson wrote: > On Mon 27 Sep 13:15 PDT 2021, Arnd Bergmann wrote: > > On Mon, Sep 27, 2021 at 9:52 PM Bjorn Andersson > > wrote: > > > > An easier option might be to find a way to build QCOM_SCM without > > RESET_CONTRO

Re: [PATCH] [RFC] qcom_scm: hide Kconfig symbol

2021-09-27 Thread Arnd Bergmann
On Mon, Sep 27, 2021 at 9:52 PM Bjorn Andersson wrote: > On Mon 27 Sep 08:22 PDT 2021, Arnd Bergmann wrote: > > From: Arnd Bergmann > > > > - To avoid a circular dependency chain involving RESET_CONTROLLER > >and PINCTRL_SUNXI, change the 'depends on RESET_CONTR

[PATCH] [RFC] qcom_scm: hide Kconfig symbol

2021-09-27 Thread Arnd Bergmann
From: Arnd Bergmann Now that SCM can be a loadable module, we have to add another dependency to avoid link failures when ipa or adreno-gpu are built-in: aarch64-linux-ld: drivers/net/ipa/ipa_main.o: in function `ipa_probe': ipa_main.c:(.text+0xfc4): undefined reference to `qcom_scm_is_available

[PATCH] iommu/mediatek: fix out-of-range warning with clang

2021-09-27 Thread Arnd Bergmann
From: Arnd Bergmann clang-14 notices that a comparison is never true when CONFIG_PHYS_ADDR_T_64BIT is disabled: drivers/iommu/mtk_iommu.c:553:34: error: result of comparison of constant 5368709120 with expression of type 'phys_addr_t' (aka 'unsigned int') is always false [-Werror

Re: [PATCH v4 0/3] Apple M1 DART IOMMU driver

2021-07-14 Thread Arnd Bergmann
On Wed, Jul 14, 2021 at 8:21 PM Robin Murphy wrote: > > On 2021-06-27 15:34, Sven Peter wrote: > [...] > > In the long term, I'd like to extend the dma-iommu framework itself to > > support iommu pagesizes with a larger granule than the CPU pagesize if that > > is > > something you agree with. >

Re: [RFC v1 PATCH 3/3] driver: update all the code that use soc_device_match

2021-04-20 Thread Arnd Bergmann
On Tue, Apr 20, 2021 at 1:44 AM Dominique MARTINET wrote: > Arnd Bergmann wrote on Mon, Apr 19, 2021 at 02:16:36PM +0200: > > For built-in drivers, load order depends on the initcall level and > > link order (how things are lined listed in the Makefile hierarchy). > > >

Re: [RFC v1 PATCH 3/3] driver: update all the code that use soc_device_match

2021-04-20 Thread Arnd Bergmann
On Tue, Apr 20, 2021 at 1:44 AM Dominique MARTINET wrote: > Arnd Bergmann wrote on Mon, Apr 19, 2021 at 02:16:36PM +0200: > > For built-in drivers, load order depends on the initcall level and > > link order (how things are lined listed in the Makefile hierarchy). > > >

Re: [RFC v1 PATCH 3/3] driver: update all the code that use soc_device_match

2021-04-19 Thread Arnd Bergmann
On Mon, Apr 19, 2021 at 11:33 AM Dominique MARTINET wrote: > Geert Uytterhoeven wrote on Mon, Apr 19, 2021 at 11:03:24AM +0200: > > > soc_device_match() should only be used as a last resort, to identify > > systems that cannot be identified otherwise. Typically this is used for > > quirks, which

Re: [PATCH v2 1/3] iommu: io-pgtable: add DART pagetable format

2021-04-09 Thread Arnd Bergmann
On Fri, Apr 9, 2021 at 6:56 PM Sven Peter wrote: > On Wed, Apr 7, 2021, at 12:44, Will Deacon wrote: > > On Sun, Mar 28, 2021 at 09:40:07AM +0200, Sven Peter wrote: > > > > > + cfg->pgsize_bitmap &= SZ_16K; > > > + if (!cfg->pgsize_bitmap) > > > + return NULL; > > > > This is

Re: [PATCH v3] drivers: introduce and use WANT_DMA_CMA for soft dependencies on DMA_CMA

2021-04-09 Thread Arnd Bergmann
rivers/remoteproc seems to be special; commit c51e882cd711 > ("remoteproc/davinci: Update Kconfig to depend on DMA_CMA") explains that > there is a real dependency to DMA_CMA for it to work; leave that dependency > in place and don't convert it to a soft dependency. I do

Re: [PATCH v2 2/3] dt-bindings: iommu: add DART iommu bindings

2021-03-28 Thread Arnd Bergmann
On Sun, Mar 28, 2021 at 9:40 AM Sven Peter wrote: I noticed only one detail here: > + - |+ > +dart2a: dart2a@82f0 { > + compatible = "apple,t8103-dart"; > + reg = <0x82f0 0x4000>; > + interrupts = <1 781 4>; > + #iommu-cells = <1>; > +}; The name of the

Re: [PATCH 0/3] Apple M1 DART IOMMU driver

2021-03-26 Thread Arnd Bergmann
On Fri, Mar 26, 2021 at 6:28 PM Mark Kettenis wrote: > I haven't figured out how the bypass stuff really works. Corellium > added support for it in their codebase when they added support for > Thunderbolt, and some of the DARTs that seem to be related to > Thunderbolt do indeed have a "bypass"

Re: [PATCH 0/3] Apple M1 DART IOMMU driver

2021-03-26 Thread Arnd Bergmann
On Fri, Mar 26, 2021 at 6:51 PM Sven Peter wrote: > On Fri, Mar 26, 2021, at 18:34, Robin Murphy wrote: > > On 2021-03-26 17:26, Mark Kettenis wrote: > > > > > > Anyway, from my viewpoint having the information about the IOVA > > > address space sit on the devices makes little sense. This

Re: [PATCH 0/3] Apple M1 DART IOMMU driver

2021-03-26 Thread Arnd Bergmann
On Fri, Mar 26, 2021 at 5:10 PM Sven Peter wrote: > On Fri, Mar 26, 2021, at 16:59, Mark Kettenis wrote: > > Some of the DARTs provide a bypass facility. That code make using the > > standard "dma-ranges" property tricky. That property would need to > > contain the bypass address range. But

Re: [PATCH 0/3] Apple M1 DART IOMMU driver

2021-03-26 Thread Arnd Bergmann
On Fri, Mar 26, 2021 at 4:59 PM Mark Kettenis wrote: > > > From: Arnd Bergmann > > Date: Thu, 25 Mar 2021 22:41:09 +0100 > > > > On Thu, Mar 25, 2021 at 8:53 AM Sven Peter wrote: > > > On Tue, Mar 23, 2021, at 21:53, Rob Herring wrote: > > &

Re: [PATCH 0/3] Apple M1 DART IOMMU driver

2021-03-25 Thread Arnd Bergmann
On Thu, Mar 25, 2021 at 8:53 AM Sven Peter wrote: > On Tue, Mar 23, 2021, at 21:53, Rob Herring wrote: > > I'm probably just confused or maybe the documentation is outdated but I don't > see how I could specify "this device can only use DMA addresses from > 0x0010...0x3ff0 but can map

Re: [PATCH 1/1] drm/amdkfd: fix build error with AMD_IOMMU_V2=m

2021-03-11 Thread Arnd Bergmann
On Tue, Mar 9, 2021 at 7:34 PM Christian König wrote: > Am 09.03.21 um 18:59 schrieb Alex Deucher: > > There has been quite some effort for this already for generic PASID > interface etc.. But it looks like that effort is stalled by now. > > Anyway at least I'm perfectly fine to have the IOMMUv2

Re: [PATCH 1/1] drm/amdkfd: fix build error with AMD_IOMMU_V2=m

2021-03-09 Thread Arnd Bergmann
On Tue, Mar 9, 2021 at 4:23 AM Felix Kuehling wrote: > > Using 'imply AMD_IOMMU_V2' does not guarantee that the driver can link > against the exported functions. If the GPU driver is built-in but the > IOMMU driver is a loadable module, the kfd_iommu.c file is indeed > built but does not work: >

Re: [RFC PATCH v3 1/2] mempinfd: Add new syscall to provide memory pin

2021-02-07 Thread Arnd Bergmann
On Sun, Feb 7, 2021 at 9:18 AM Zhou Wang wrote: > diff --git a/arch/arm64/include/asm/unistd32.h > b/arch/arm64/include/asm/unistd32.h > index cccfbbe..3f49529 100644 > --- a/arch/arm64/include/asm/unistd32.h > +++ b/arch/arm64/include/asm/unistd32.h > @@ -891,6 +891,8 @@

[PATCH] [v3] x86: apic: avoid -Wshadow warning in header

2020-10-30 Thread Arnd Bergmann
From: Arnd Bergmann There are hundreds of warnings in a W=2 build about a local variable shadowing the global 'apic' definition: arch/x86/kvm/lapic.h:149:65: warning: declaration of 'apic' shadows a global declaration [-Wshadow] Avoid this by renaming the global 'apic' variable to the more

Re: [PATCH] [v2] x86: apic: avoid -Wshadow warning in header

2020-10-29 Thread Arnd Bergmann
On Thu, Oct 29, 2020 at 8:04 AM Paolo Bonzini wrote: > > On 28/10/20 22:20, Arnd Bergmann wrote: > > Avoid this by renaming the global 'apic' variable to the more descriptive > > 'x86_system_apic'. It was originally called 'genapic', but both that > > and the current 'a

[PATCH] [v2] x86: apic: avoid -Wshadow warning in header

2020-10-28 Thread Arnd Bergmann
From: Arnd Bergmann There are hundreds of warnings in a W=2 build about a local variable shadowing the global 'apic' definition: arch/x86/kvm/lapic.h:149:65: warning: declaration of 'apic' shadows a global declaration [-Wshadow] Avoid this by renaming the global 'apic' variable to the more

Re: arm64: Internal error: Oops: qcom_iommu_tlb_inv_context free_io_pgtable_ops on db410c

2020-07-20 Thread Arnd Bergmann
On Mon, Jul 20, 2020 at 8:36 AM Naresh Kamboju wrote: > > This kernel oops while boot linux mainline kernel on arm64 db410c device. > > metadata: > git branch: master > git repo: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > git commit:

Re: [PATCH 0/2] Introduce PCI_FIXUP_IOMMU

2020-06-09 Thread Arnd Bergmann
On Tue, Jun 9, 2020 at 6:02 AM Zhangfei Gao wrote: > On 2020/6/9 上午12:41, Bjorn Helgaas wrote: > > On Mon, Jun 08, 2020 at 10:54:15AM +0800, Zhangfei Gao wrote: > >> On 2020/6/6 上午7:19, Bjorn Helgaas wrote: > +++ b/drivers/iommu/iommu.c > @@ -2418,6 +2418,10 @@ int

Re: [PATCH 0/2] Introduce PCI_FIXUP_IOMMU

2020-05-27 Thread Arnd Bergmann
On Wed, May 27, 2020 at 11:00 AM Greg Kroah-Hartman wrote: > > On Tue, May 26, 2020 at 07:49:07PM +0800, Zhangfei Gao wrote: > > Some platform devices appear as PCI but are actually on the AMBA bus, > > Why would these devices not just show up on the AMBA bus and use all of > that logic instead

[PATCH] iommu/renesas: fix unused-function warning

2020-05-08 Thread Arnd Bergmann
probe/release_device() call-backs") Signed-off-by: Arnd Bergmann --- drivers/iommu/ipmmu-vmsa.c | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c index fb7e702dee23..4c2972f3153b 100644 --- a/drivers/iommu/ipmmu-vm

[PATCH] iommu: fix min_not_zero() type mismatch warning

2019-12-10 Thread Arnd Bergmann
~ Add an explicit cast to work around it, as there is no min_not_zero_t() equivalent of min_t(). Fixes: a7ba70f1787f ("dma-mapping: treat dev->bus_dma_mask as a DMA limit") Signed-off-by: Arnd Bergmann --- drivers/iommu/dma-iommu.c | 2 +- 1 file changed, 1 insertion(+), 1 deleti

Re: [PATCH] media: staging: tegra-vde: Fix build error

2019-09-20 Thread Arnd Bergmann
On Thu, Jul 25, 2019 at 2:24 PM Dmitry Osipenko wrote: > > 25.07.2019 5:41, YueHaibing пишет: > > If IOMMU_SUPPORT is not set, and COMPILE_TEST is y, > > IOMMU_IOVA may be set to m. So building will fails: > > > > drivers/staging/media/tegra-vde/iommu.o: In function `tegra_vde_iommu_map': > >

Re: [PATCH] iommu: omap: mark pm functions __maybe_unused

2019-09-06 Thread Arnd Bergmann
On Fri, Sep 6, 2019 at 5:24 PM Suman Anna wrote: > > Hi Arnd, > > On 9/6/19 10:15 AM, Arnd Bergmann wrote: > > The runtime_pm functions are unused when CONFIG_PM is disabled: > > > > drivers/iommu/omap-iommu.c:1022:12: error: unused function > > 'omap_iomm

[PATCH] iommu: omap: mark pm functions __maybe_unused

2019-09-06 Thread Arnd Bergmann
Signed-off-by: Arnd Bergmann --- drivers/iommu/omap-iommu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c index 451e3c98ab2d..09c6e1c680db 100644 --- a/drivers/iommu/omap-iommu.c +++ b/drivers/iommu/omap-iommu.c

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

2019-07-19 Thread Arnd Bergmann
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 have > > > >

Re: [PATCH 5/7 v2] MIPS: use the generic uncached segment support in dma-direct

2019-07-03 Thread Arnd Bergmann
On Mon, Jun 3, 2019 at 8:50 AM Christoph Hellwig wrote: > > On Wed, May 01, 2019 at 05:13:57PM +, Paul Burton wrote: > > Hi Christoph, > > > > On Wed, May 01, 2019 at 03:13:39PM +0200, Christoph Hellwig wrote: > > > Stop providing our arch alloc/free hooks and just expose the segment > > >

[PATCH] iommu: fix integer truncation

2019-06-17 Thread Arnd Bergmann
' (aka 'unsigned int') changes value from 18446744073709551615 to 4294967295 [-Werror,-Wconstant-conversion] Use phys_addr_t here because that is the type that the variable was declared as. Fixes: aadad097cd46 ("iommu/dma: Reserve IOVA for PCIe inaccessible DMA address") Signed-of

[PATCH] swiotlb: fix phys_addr_t overflow warning

2019-06-17 Thread Arnd Bergmann
in the error handling later. Fixes: b907e20508d0 ("swiotlb: remove SWIOTLB_MAP_ERROR") Signed-off-by: Arnd Bergmann --- I still think that reverting the original commit would have provided clearer semantics for this corner case, but at least this patch restores the correct behavior. --- d

Re: [Xen-devel] [PATCH] Revert "swiotlb: remove SWIOTLB_MAP_ERROR"

2019-03-13 Thread Arnd Bergmann
On Wed, Mar 13, 2019 at 7:33 PM Christoph Hellwig wrote: > On Fri, Mar 08, 2019 at 05:25:57PM +, Julien Grall wrote: > > In the common case, Dom0 also contains the PV backend drivers. Those > > drivers may directly use the guest buffer in the DMA request (so a copy is > > avoided). To avoid

[PATCH] [v3] dma-mapping: work around clang bug

2019-03-07 Thread Arnd Bergmann
org/show_bug.cgi?id=38789 Reviewed-by: Geert Uytterhoeven Reviewed-by: Robin Murphy Signed-off-by: Arnd Bergmann --- v3: use (2ull << n-1) instead of ((1ull << n-1) << 1) special-case 0 instead of 64 v2: fix off-by-one error --- include/linux/dma-mapping.h | 6 +- 1 file

Re: [PATCH] [v2] dma-mapping: work around clang bug

2019-03-07 Thread Arnd Bergmann
On Thu, Mar 7, 2019 at 10:17 AM Robin Murphy wrote: > On 2019-03-07 8:52 am, Arnd Bergmann wrote: > > > > -#define DMA_BIT_MASK(n) (((n) == 64) ? ~0ULL : ((1ULL<<(n))-1)) > > +/* double shift to work around https://bugs.llvm.org/show_bug.cgi?id=38789 > &g

[PATCH] [v2] dma-mapping: work around clang bug

2019-03-07 Thread Arnd Bergmann
org/show_bug.cgi?id=38789 Signed-off-by: Arnd Bergmann --- v2: fix off-by-one error --- include/linux/dma-mapping.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h index 75e60be91e5f..9e438fe6b130 100644 --- a/include/li

Re: [PATCH] dma-mapping: work around clang bug

2019-03-07 Thread Arnd Bergmann
On Thu, Mar 7, 2019 at 9:28 AM Geert Uytterhoeven wrote: > On Thu, Mar 7, 2019 at 9:01 AM Arnd Bergmann wrote: > > Clang has a rather annoying behavior of checking for integer > > arithmetic problems in code paths that are discarded by gcc > > before that pe

[PATCH] dma-mapping: work around clang bug

2019-03-07 Thread Arnd Bergmann
org/show_bug.cgi?id=38789 Signed-off-by: Arnd Bergmann --- include/linux/dma-mapping.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h index 75e60be91e5f..380d3a95d02e 100644 --- a/include/linux/dma-mapping.h +++ b/incl

Re: [PATCH] Revert "swiotlb: remove SWIOTLB_MAP_ERROR"

2019-03-05 Thread Arnd Bergmann
On Tue, Mar 5, 2019 at 12:56 AM Robin Murphy wrote: > On 2019-03-04 7:59 pm, Arnd Bergmann wrote: > > This reverts commit b907e20508d0 ("swiotlb: remove SWIOTLB_MAP_ERROR"), > > which > > introduced an overflow warning in configurations that have a larger

[PATCH] Revert "swiotlb: remove SWIOTLB_MAP_ERROR"

2019-03-04 Thread Arnd Bergmann
n the type of MMU chosen (classic vs LPAE). I tried a couple of alternative approaches, but the previous version seems as good as any other, so I went back to that. Fixes: b907e20508d0 ("swiotlb: remove SWIOTLB_MAP_ERROR") Signed-off-by: Arnd Bergmann --- drivers/xen/swiotlb-xen.c | 4

Re: remove block layer bounce buffering for MMC

2019-01-16 Thread Arnd Bergmann
On Wed, Jan 16, 2019 at 2:51 PM Linus Walleij wrote: > > On Wed, Jan 16, 2019 at 11:25 AM Arnd Bergmann wrote: > > On Mon, Jan 14, 2019 at 11:27 AM Ulf Hansson wrote: > > > > > > +Linus Walleij (recently made a cleanup of the mmc bounce buffering code). >

Re: remove block layer bounce buffering for MMC

2019-01-16 Thread Arnd Bergmann
On Mon, Jan 14, 2019 at 11:27 AM Ulf Hansson wrote: > > +Linus Walleij (recently made a cleanup of the mmc bounce buffering code). > > On Mon, 14 Jan 2019 at 10:58, Christoph Hellwig wrote: > > > > Hi everyone, > > > > this series converts the remaining MMC host drivers to properly kmap the > >

Re: dmaengine for sh7760 (was Re: use the generic dma-noncoherent code for sh V2)

2018-08-20 Thread Arnd Bergmann
On Sun, Aug 19, 2018 at 7:38 AM Rob Landley wrote: > > On 08/17/2018 03:23 PM, Arnd Bergmann wrote: > > On Fri, Aug 17, 2018 at 7:04 PM Rob Landley wrote: > >> On 07/31/2018 07:56 AM, Arnd Bergmann wrote: > >>> On Fri, Jul 27, 2018 at 6:20 PM, Rob Landley wro

Re: dmaengine for sh7760 (was Re: use the generic dma-noncoherent code for sh V2)

2018-08-17 Thread Arnd Bergmann
On Fri, Aug 17, 2018 at 7:04 PM Rob Landley wrote: > On 07/31/2018 07:56 AM, Arnd Bergmann wrote: > > On Fri, Jul 27, 2018 at 6:20 PM, Rob Landley wrote: > >> On 07/24/2018 03:21 PM, Christoph Hellwig wrote: > >>> On Tue, Jul 24, 2018 at 02:01:42PM +0200, Christop

Re: [PATCH v2 0/7] Stop losing firmware-set DMA masks

2018-08-06 Thread Arnd Bergmann
On Mon, Aug 6, 2018 at 2:08 PM Christoph Hellwig wrote: > > On Mon, Aug 06, 2018 at 12:01:34PM +0200, Arnd Bergmann wrote: > > There are a few subtle corner cases here, in particular in which cases > > the new dma_set_mask() behavior on arm64 reports success or > >

Re: [PATCH v2 0/7] Stop losing firmware-set DMA masks

2018-08-06 Thread Arnd Bergmann
On Tue, Jul 31, 2018 at 1:30 PM Robin Murphy wrote: > On 29/07/18 13:32, Arnd Bergmann wrote: > > On Tue, Jul 24, 2018 at 12:16 AM, Robin Murphy wrote: > > Thanks a lot for working on this, this has bugged me for many years, > > and I've discussed possible solutions wit

Re: use the generic dma-noncoherent code for sh V2

2018-07-31 Thread Arnd Bergmann
On Mon, Jul 30, 2018 at 11:06 AM, Christoph Hellwig wrote: > On Fri, Jul 27, 2018 at 11:20:21AM -0500, Rob Landley wrote: >> Speaking of DMA: > > Which really has nothing to do with the dma mapping code, which > also means I can't help you much unfortunately. > > That being said sh is the last

  1   2   3   >