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.
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 done b
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 WARN_ON
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 patch
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
(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 non
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 di
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.
The
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
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
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,
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. Th
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 bus_to_virt(
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.
The
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
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
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
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 it
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 h
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.
> >
> >
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.
The
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
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
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 was
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
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
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
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). I
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 o
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
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
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 *addr
h Hellwig
Reviewed-by: Arnd Bergmann
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
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
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
; 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
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
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
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, 1
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
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 sym
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
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:
> > >
>
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
Kconfig symbol that is getting 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
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_avai
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
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:
> > > >
> >
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
>
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_avai
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:/
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
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_
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_avai
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 al
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.
>
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).
> >
>
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).
> >
>
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
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 worryin
fig
>
> Note: drivers/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
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 iomm
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" p
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 informa
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 tha
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:
> > >
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 thes
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 |
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:
>
>
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 @@ __SYSCALL(__NR_faccessa
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 'a
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 tha
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 'a
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: f8456690ba8eb18ea4714e68554e242
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 iommu_fwspec_init(stru
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 of
onvert to 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/iomm
zero(dma_limit, dev->bus_dma_limit);
^~~~
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/
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':
> > iomm
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
callbacks")
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
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
> > > > ARCH_NO_COHEREN
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
> > > off
o
'phys_addr_t' (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 in
wer type,
and use the same expression 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 pat
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 us
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
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
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
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 perfoms the sam
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
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
bled hardware platforms, while the physical
address space depends on 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&q
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).
>
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
> > s
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
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
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
> > fai
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 solution
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 pen
1 - 100 of 345 matches
Mail list logo
