arch/powerpc/Kconfig | 2 +- arch/riscv/Kconfig | 2 +- drivers/of/Kconfig | 4 ---- drivers/of/address.c | 2 +- include/linux/dma-map-ops.h | 2 ++ kernel/dma/Kconfig | 7 +++++++ kernel/dma/mapping.c | 6 +++++- 7 files changed, 17 insertions(+), 8 deletions(-)
Hi all, This series split out second half of my previous series "[PATCH 0/4] MIPS DMA coherence fixes". It intends to use dma_default_coherent to determine the default coherency of devicetree probed devices instead of hardcoding it with Kconfig options. For some MIPS systems, dma_default_coherent is determined with either bootloader or hardware registers in platform initilization code, and devicetree does not explicility specify the coherency of the device, so we need the ability to change the default coherency of devicetree probed devices. For other platforms that supports noncoherent, dma_default_coherent is a fixed value set by arch code. It's defaulted to false for most archs except RISC-V. Thanks - Jiaxun --- v2: - Add PATCH 1 to help with backporting - Use Kconfig option to set dma_default_coherent v3: - Style fixes - Squash setting ARCH_DMA_DEFAULT_COHERENT into PATCH 4 - Setting ARCH_DMA_DEFAULT_COHERENT for PowerPC Jiaxun Yang (4): of: address: Fix default coherency for MIPS dma-mapping: Provide a fallback dma_default_coherent dma-mapping: Provide CONFIG_ARCH_DMA_DEFAULT_COHERENT of: address: Always use dma_default_coherent for default coherency arch/powerpc/Kconfig | 2 +- arch/riscv/Kconfig | 2 +- drivers/of/Kconfig | 4 ---- drivers/of/address.c | 2 +- include/linux/dma-map-ops.h | 2 ++ kernel/dma/Kconfig | 7 +++++++ kernel/dma/mapping.c | 6 +++++- 7 files changed, 17 insertions(+), 8 deletions(-) -- 2.37.1 (Apple Git-137.1)
The series looks fine to me. How should we merge it?
> 2023年3月23日 07:29，Christoph Hellwig <hch@lst.de> 写道： > > The series looks fine to me. How should we merge it? Perhaps go through dma-mapping tree? Thanks - Jiaxun
On Thu, Mar 23, 2023 at 09:07:31PM +0000, Jiaxun Yang wrote: > > > > 2023年3月23日 07:29，Christoph Hellwig <hch@lst.de> 写道： > > > > The series looks fine to me. How should we merge it? > > Perhaps go through dma-mapping tree? Is patch a 6.3 candidate or should all of it go into 6.4?
> 2023年3月23日 21:39，Christoph Hellwig <hch@lst.de> 写道： > > On Thu, Mar 23, 2023 at 09:07:31PM +0000, Jiaxun Yang wrote: >> >> >>> 2023年3月23日 07:29，Christoph Hellwig <hch@lst.de> 写道： >>> >>> The series looks fine to me. How should we merge it? >> >> Perhaps go through dma-mapping tree? > > Is patch a 6.3 candidate or should all of it go into 6.4? Please leave it for 6.4, as corresponding MIPS arch part will be a part of 6.4. Thanks Jiaxun
On Fri, Mar 24, 2023 at 09:17:38AM +0000, Jiaxun Yang wrote: > > > > Is patch a 6.3 candidate or should all of it go into 6.4? > > Please leave it for 6.4, as corresponding MIPS arch part will be a part of 6.4. Ok. I'll really need review from the MIPS and drivers/of/ maintainers, through.
On Tue, Mar 28, 2023 at 03:18:12AM +0200, Christoph Hellwig wrote: > On Fri, Mar 24, 2023 at 09:17:38AM +0000, Jiaxun Yang wrote: > > > > > > Is patch a 6.3 candidate or should all of it go into 6.4? > > > > Please leave it for 6.4, as corresponding MIPS arch part will be a part of 6.4. > > Ok. I'll really need review from the MIPS and drivers/of/ maintainers, > through. I don't see any MIPS changes in the series besides the ifdef CONFIG_MIPS part in patch 1, which gets removed again in patch 4 (chance to drop that completely ?). I've merged the corresponding MIPS patches into mips-next last week. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea. [ RFC1925, 2.3 ]
> 2023年3月28日 08:45，Thomas Bogendoerfer <tsbogend@alpha.franken.de> 写道： > > On Tue, Mar 28, 2023 at 03:18:12AM +0200, Christoph Hellwig wrote: >> On Fri, Mar 24, 2023 at 09:17:38AM +0000, Jiaxun Yang wrote: >>>> >>>> Is patch a 6.3 candidate or should all of it go into 6.4? >>> >>> Please leave it for 6.4, as corresponding MIPS arch part will be a part of 6.4. >> >> Ok. I'll really need review from the MIPS and drivers/of/ maintainers, >> through. +cc devicetree foks. > > I don't see any MIPS changes in the series besides the ifdef CONFIG_MIPS > part in patch 1, which gets removed again in patch 4 (chance to drop > that completely ?). It was suggested by DMA folks to have that patch. > I've merged the corresponding MIPS patches into mips-next last week. Thanks - Jiaxun > > Thomas. > > -- > Crap can work. Given enough thrust pigs will fly, but it's not necessarily a > good idea. [ RFC1925, 2.3 ]
© 2016 - 2026 Red Hat, Inc.