Re: [PATCH 2/2] powerpc/xmon: use KSYM_NAME_LEN in array size
On 30/5/23 10:54 pm, Miguel Ojeda wrote: Side-note: in `get_function_bounds()`, I see `kallsyms_lookup()` being used, but the name seems discarded? Can `kallsyms_lookup_size_offset()` be used instead, thus avoiding the usage of the buffer there to begin with? I'm not familiar with the kallsyms infrastructure, but looking over the implementations of kallsyms_lookup() and kallsyms_lookup_size_offset() it looks like the existing kallsyms_lookup() handles an extra case over kallsyms_lookup_size_offset()? kallsyms_lookup_buildid() (the implementation of kallsyms_lookup()) has /* See if it's in a module or a BPF JITed image. */ ret = module_address_lookup(addr, symbolsize, offset, modname, modbuildid, namebuf); if (!ret) ret = bpf_address_lookup(addr, symbolsize, offset, modname, namebuf); if (!ret) ret = ftrace_mod_address_lookup(addr, symbolsize, offset, modname, namebuf); while kallsyms_lookup_size_offset() is missing the ftrace case return !!module_address_lookup(addr, symbolsize, offset, NULL, NULL, namebuf) || !!__bpf_address_lookup(addr, symbolsize, offset, namebuf); Might this be a concern for xmon?
Re: [PATCH] powerpc: pmac32: enable serial options by default in defconfig
Hi Christophe On 8/2/2023 9:58 PM, Christophe Leroy wrote: Le 02/08/2023 à 15:41, Yuan Tan a écrit : [Vous ne recevez pas souvent de courriers de tany...@tinylab.org. Découvrez pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ] Serial is a critical feature for logging and debuging, and the other architectures enable serial by default. Let's enable CONFIG_SERIAL_PMACZILOG and CONFIG_SERIAL_PMACZILOG_CONSOLE by default. Signed-off-by: Yuan Tan Reviewed-by: Christophe Leroy Can this patch be merged into v6.6? There's another patch depends on it :) Best regards, Yuan Tan --- arch/powerpc/configs/pmac32_defconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/configs/pmac32_defconfig b/arch/powerpc/configs/pmac32_defconfig index 019163c2571e..3aae79afb9d9 100644 --- a/arch/powerpc/configs/pmac32_defconfig +++ b/arch/powerpc/configs/pmac32_defconfig @@ -176,8 +176,9 @@ CONFIG_MOUSE_APPLETOUCH=y # CONFIG_SERIO_I8042 is not set # CONFIG_SERIO_SERPORT is not set CONFIG_SERIAL_8250=m -CONFIG_SERIAL_PMACZILOG=m +CONFIG_SERIAL_PMACZILOG=y CONFIG_SERIAL_PMACZILOG_TTYS=y +CONFIG_SERIAL_PMACZILOG_CONSOLE=y CONFIG_NVRAM=y CONFIG_I2C_CHARDEV=m CONFIG_APM_POWER=y -- 2.34.1
[powerpc:topic/cpu-smt] BUILD SUCCESS d1099e2276df1d8dd4037552c2f34eb4c4df4a75
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git topic/cpu-smt branch HEAD: d1099e2276df1d8dd4037552c2f34eb4c4df4a75 powerpc/pseries: Honour current SMT state when DLPAR onlining CPUs elapsed time: 836m configs tested: 166 configs skipped: 4 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: alphaallyesconfig gcc alpha defconfig gcc alpharandconfig-r025-20230731 gcc alpharandconfig-r026-20230731 gcc arc allyesconfig gcc arc defconfig gcc arc randconfig-r033-20230731 gcc arc randconfig-r043-20230731 gcc arc randconfig-r043-20230802 gcc arm allmodconfig gcc arm allyesconfig gcc arm defconfig gcc arm gemini_defconfig gcc armmvebu_v5_defconfig clang arm pxa3xx_defconfig gcc arm randconfig-r024-20230731 gcc arm randconfig-r032-20230801 clang arm randconfig-r046-20230731 gcc armrealview_defconfig gcc arm versatile_defconfig clang arm64allyesconfig gcc arm64 defconfig gcc arm64randconfig-r014-20230731 clang arm64randconfig-r036-20230731 gcc cskydefconfig gcc csky randconfig-r006-20230801 gcc csky randconfig-r034-20230801 gcc hexagon randconfig-r004-20230801 clang hexagon randconfig-r012-20230731 clang hexagon randconfig-r015-20230731 clang hexagon randconfig-r041-20230731 clang hexagon randconfig-r045-20230731 clang i386 allyesconfig gcc i386 buildonly-randconfig-r004-20230731 gcc i386 buildonly-randconfig-r004-20230801 gcc i386 buildonly-randconfig-r005-20230731 gcc i386 buildonly-randconfig-r005-20230801 gcc i386 buildonly-randconfig-r006-20230731 gcc i386 buildonly-randconfig-r006-20230801 gcc i386 debian-10.3 gcc i386defconfig gcc i386 randconfig-i001-20230731 gcc i386 randconfig-i001-20230802 clang i386 randconfig-i002-20230731 gcc i386 randconfig-i002-20230802 clang i386 randconfig-i003-20230731 gcc i386 randconfig-i003-20230802 clang i386 randconfig-i004-20230731 gcc i386 randconfig-i004-20230802 clang i386 randconfig-i005-20230731 gcc i386 randconfig-i005-20230802 clang i386 randconfig-i006-20230731 gcc i386 randconfig-i006-20230802 clang i386 randconfig-i011-20230801 clang i386 randconfig-i011-20230802 gcc i386 randconfig-i012-20230801 clang i386 randconfig-i012-20230802 gcc i386 randconfig-i013-20230801 clang i386 randconfig-i013-20230802 gcc i386 randconfig-i014-20230801 clang i386 randconfig-i014-20230802 gcc i386 randconfig-i015-20230801 clang i386 randconfig-i015-20230802 gcc i386 randconfig-i016-20230801 clang i386 randconfig-i016-20230802 gcc i386 randconfig-r014-20230731 clang i386 randconfig-r025-20230731 clang i386 randconfig-r033-20230801 gcc loongarchallmodconfig gcc loongarch allnoconfig gcc loongarch defconfig gcc m68k allmodconfig gcc m68k allyesconfig gcc m68kdefconfig gcc m68kstmark2_defconfig gcc microblaze defconfig gcc microblaze randconfig-r002-20230801 gcc microblaze randconfig-r005-20230801 gcc mips allmodconfig gcc mips allyesconfig gcc mipsbcm47xx_defconfig gcc mips randconfig-r005-20230801 clang mips rb532_defconfig gcc nios2 defconfig gcc nios2randconfig-r011-20230731 gcc
Re: [PATCH 1/1] perf tests task_analyzer: Check perf build options for libtraceevent support
Hi Arnaldo, I am working on a patch for 'perf version --has', and will send a patch next week using that instead of 'perf version --build-options'. You can skip this patch if not needed. Thanks, - Aditya G
[PATCH v2 RESEND*3] ASoC: fsl MPC52xx drivers require PPC_BESTCOMM
Both SND_MPC52xx_SOC_PCM030 and SND_MPC52xx_SOC_EFIKA select
SND_SOC_MPC5200_AC97. The latter symbol depends on PPC_BESTCOMM,
so the 2 former symbols should also depend on PPC_BESTCOMM since
"select" does not follow any dependency chains.
This prevents a kconfig warning and build errors:
WARNING: unmet direct dependencies detected for SND_SOC_MPC5200_AC97
Depends on [n]: SOUND [=y] && !UML && SND [=m] && SND_SOC [=m] &&
SND_POWERPC_SOC [=m] && PPC_MPC52xx [=y] && PPC_BESTCOMM [=n]
Selected by [m]:
- SND_MPC52xx_SOC_PCM030 [=m] && SOUND [=y] && !UML && SND [=m] && SND_SOC
[=m] && SND_POWERPC_SOC [=m] && PPC_MPC5200_SIMPLE [=y]
- SND_MPC52xx_SOC_EFIKA [=m] && SOUND [=y] && !UML && SND [=m] && SND_SOC
[=m] && SND_POWERPC_SOC [=m] && PPC_EFIKA [=y]
ERROR: modpost: "mpc5200_audio_dma_destroy" [sound/soc/fsl/mpc5200_psc_ac97.ko]
undefined!
ERROR: modpost: "mpc5200_audio_dma_create" [sound/soc/fsl/mpc5200_psc_ac97.ko]
undefined!
Fixes: 40d9ec14e7e1 ("ASoC: remove BROKEN from Efika and pcm030 fabric drivers")
Signed-off-by: Randy Dunlap
Cc: Grant Likely
Cc: Mark Brown
Cc: Liam Girdwood
Cc: Shengjiu Wang
Cc: Xiubo Li
Cc: alsa-de...@alsa-project.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Jaroslav Kysela
Cc: Takashi Iwai
Acked-by: Shengjiu Wang
---
v2: use correct email address for Mark Brown.
sound/soc/fsl/Kconfig |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -- a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -243,7 +243,7 @@ config SND_SOC_MPC5200_AC97
config SND_MPC52xx_SOC_PCM030
tristate "SoC AC97 Audio support for Phytec pcm030 and WM9712"
- depends on PPC_MPC5200_SIMPLE
+ depends on PPC_MPC5200_SIMPLE && PPC_BESTCOMM
select SND_SOC_MPC5200_AC97
select SND_SOC_WM9712
help
@@ -252,7 +252,7 @@ config SND_MPC52xx_SOC_PCM030
config SND_MPC52xx_SOC_EFIKA
tristate "SoC AC97 Audio support for bbplan Efika and STAC9766"
- depends on PPC_EFIKA
+ depends on PPC_EFIKA && PPC_BESTCOMM
select SND_SOC_MPC5200_AC97
select SND_SOC_STAC9766
help
[powerpc:next] BUILD SUCCESS 7f96539437eafec8fd062fb13f31cf53251ea18d
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next branch HEAD: 7f96539437eafec8fd062fb13f31cf53251ea18d powerpc/kexec: fix minor typo elapsed time: 723m configs tested: 147 configs skipped: 11 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: alphaallyesconfig gcc alpha defconfig gcc alpharandconfig-r005-20230731 gcc alpharandconfig-r036-20230801 gcc arc allyesconfig gcc arc defconfig gcc arc randconfig-r004-20230801 gcc arc randconfig-r031-20230731 gcc arc randconfig-r033-20230731 gcc arc randconfig-r043-20230802 gcc arm allmodconfig gcc arm allyesconfig gcc arm defconfig gcc arm randconfig-r005-20230801 clang arm randconfig-r012-20230731 gcc arm randconfig-r046-20230802 clang armrealview_defconfig gcc arm64allyesconfig gcc arm64 defconfig gcc arm64randconfig-r013-20230731 clang arm64randconfig-r014-20230731 clang arm64randconfig-r036-20230731 gcc cskydefconfig gcc csky randconfig-r006-20230801 gcc hexagon randconfig-r014-20230731 clang hexagon randconfig-r041-20230802 clang hexagon randconfig-r045-20230802 clang i386 allyesconfig gcc i386 buildonly-randconfig-r004-20230731 gcc i386 buildonly-randconfig-r004-20230801 gcc i386 buildonly-randconfig-r005-20230731 gcc i386 buildonly-randconfig-r005-20230801 gcc i386 buildonly-randconfig-r006-20230731 gcc i386 buildonly-randconfig-r006-20230801 gcc i386 debian-10.3 gcc i386defconfig gcc i386 randconfig-i001-20230731 gcc i386 randconfig-i002-20230731 gcc i386 randconfig-i003-20230731 gcc i386 randconfig-i004-20230731 gcc i386 randconfig-i005-20230731 gcc i386 randconfig-i006-20230731 gcc i386 randconfig-i011-20230731 clang i386 randconfig-i012-20230731 clang i386 randconfig-i013-20230731 clang i386 randconfig-i014-20230731 clang i386 randconfig-i015-20230731 clang i386 randconfig-i016-20230731 clang i386 randconfig-r025-20230731 clang loongarchallmodconfig gcc loongarch allnoconfig gcc loongarch defconfig gcc loongarchrandconfig-r013-20230802 gcc loongarchrandconfig-r023-20230731 gcc m68k allmodconfig gcc m68k allyesconfig gcc m68kdefconfig gcc m68k randconfig-r026-20230731 gcc microblaze randconfig-r001-20230801 gcc microblaze randconfig-r003-20230801 gcc microblaze randconfig-r005-20230801 gcc microblaze randconfig-r006-20230731 gcc microblaze randconfig-r015-20230731 gcc microblaze randconfig-r025-20230731 gcc mips allmodconfig gcc mips allyesconfig gcc mips randconfig-r002-20230801 clang mips randconfig-r011-20230802 clang mips randconfig-r015-20230802 clang mips randconfig-r022-20230731 gcc mips randconfig-r026-20230801 gcc nios2 defconfig gcc nios2randconfig-r012-20230802 gcc nios2randconfig-r022-20230801 gcc openrisc randconfig-r001-20230731 gcc openrisc randconfig-r034-20230801 gcc openrisc randconfig-r036-20230731 gcc parisc allyesconfig gcc parisc defconfig gcc parisc randconfig-r006-20230801 gcc parisc randconfig-r021-20230801 gcc parisc64defconfig gcc powerpc allmodconfig gcc powerpc allnoconfig gcc powerpc randconfig-r003-20230801 gcc powerpc randconfig-r014-20230802
[powerpc:fixes-test] BUILD SUCCESS 86582e6189dd8f9f52c25d46c70fe5d111da6345
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git fixes-test branch HEAD: 86582e6189dd8f9f52c25d46c70fe5d111da6345 powerpc/powermac: Use early_* IO variants in via_calibrate_decr() elapsed time: 723m configs tested: 80 configs skipped: 134 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: alphaallyesconfig gcc alpha defconfig gcc arc defconfig gcc arc randconfig-r033-20230731 gcc arc randconfig-r043-20230802 gcc arm allyesconfig gcc arm defconfig gcc arm64allyesconfig gcc arm64 defconfig gcc arm64randconfig-r014-20230731 clang arm64randconfig-r036-20230731 gcc cskydefconfig gcc csky randconfig-r006-20230801 gcc i386 allyesconfig gcc i386 buildonly-randconfig-r004-20230801 gcc i386 buildonly-randconfig-r005-20230801 gcc i386 buildonly-randconfig-r006-20230801 gcc i386 debian-10.3 gcc i386defconfig gcc i386 randconfig-i001-20230731 gcc i386 randconfig-i002-20230731 gcc i386 randconfig-i003-20230731 gcc i386 randconfig-i004-20230731 gcc i386 randconfig-i005-20230731 gcc i386 randconfig-i006-20230731 gcc i386 randconfig-r025-20230731 clang loongarchallmodconfig gcc loongarch allnoconfig gcc loongarch defconfig gcc microblaze randconfig-r005-20230801 gcc mips allyesconfig gcc nios2 defconfig gcc parisc allyesconfig gcc parisc defconfig gcc parisc64defconfig gcc powerpc allmodconfig gcc powerpc allnoconfig gcc powerpc randconfig-r003-20230801 gcc powerpc randconfig-r022-20230731 clang powerpc randconfig-r026-20230731 clang riscvallmodconfig gcc riscv allnoconfig gcc riscvallyesconfig gcc riscv defconfig gcc riscvrandconfig-r042-20230802 gcc riscv rv32_defconfig gcc s390 allmodconfig gcc s390 allyesconfig gcc s390defconfig gcc s390 randconfig-r011-20230731 clang s390 randconfig-r044-20230802 gcc sh allmodconfig gcc sparcallyesconfig gcc sparc defconfig gcc sparc64 randconfig-r002-20230801 gcc sparc64 randconfig-r035-20230731 gcc um allmodconfig clang umallnoconfig clang um allyesconfig clang x86_64 allyesconfig gcc x86_64 buildonly-randconfig-r001-20230801 gcc x86_64 buildonly-randconfig-r002-20230801 gcc x86_64 buildonly-randconfig-r003-20230801 gcc x86_64 defconfig gcc x86_64 kexec gcc x86_64 randconfig-r012-20230731 clang x86_64 randconfig-x001-20230731 clang x86_64 randconfig-x002-20230731 clang x86_64 randconfig-x003-20230731 clang x86_64 randconfig-x004-20230731 clang x86_64 randconfig-x005-20230731 clang x86_64 randconfig-x006-20230731 clang x86_64 randconfig-x011-20230731 gcc x86_64 randconfig-x012-20230731 gcc x86_64 randconfig-x013-20230731 gcc x86_64 randconfig-x014-20230731 gcc x86_64 randconfig-x015-20230731 gcc x86_64 randconfig-x016-20230731 gcc x86_64 rhel-8.3-rust clang x86_64 rhel-8.3 gcc -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
Re: [PATCH v2 27/28] dt-bindings: net: fsl,qmc-hdlc: Add framer support
On Wed, Jul 26, 2023 at 05:02:23PM +0200, Herve Codina wrote: > A framer can be connected to the QMC HDLC. > If present, this framer is the interface between the TDM used by the QMC > HDLC and the E1/T1 line. > The QMC HDLC can use this framer to get information about the line and > configure the line. > > Add an optional framer property to reference the framer itself. > > Signed-off-by: Herve Codina > --- > Documentation/devicetree/bindings/net/fsl,qmc-hdlc.yaml | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/Documentation/devicetree/bindings/net/fsl,qmc-hdlc.yaml > b/Documentation/devicetree/bindings/net/fsl,qmc-hdlc.yaml > index 8bb6f34602d9..bf29863ab419 100644 > --- a/Documentation/devicetree/bindings/net/fsl,qmc-hdlc.yaml > +++ b/Documentation/devicetree/bindings/net/fsl,qmc-hdlc.yaml > @@ -27,6 +27,11 @@ properties: >Should be a phandle/number pair. The phandle to QMC node and the QMC >channel to use. > > + framer: > +$ref: /schemas/types.yaml#/definitions/phandle Now you've defined this property twice. Please avoid doing that. > +description: > + phandle to the framer node > + > required: >- compatible >- fsl,qmc-chan > -- > 2.41.0 >
Re: [PATCH v2 21/28] dt-bindings: net: Add the Lantiq PEF2256 E1/T1/J1 framer
On Wed, Jul 26, 2023 at 05:02:17PM +0200, Herve Codina wrote: > The Lantiq PEF2256 is a framer and line interface component designed to > fulfill all required interfacing between an analog E1/T1/J1 line and the > digital PCM system highway/H.100 bus. > > Signed-off-by: Herve Codina > --- > .../bindings/net/lantiq,pef2256.yaml | 226 ++ > 1 file changed, 226 insertions(+) > create mode 100644 Documentation/devicetree/bindings/net/lantiq,pef2256.yaml > > diff --git a/Documentation/devicetree/bindings/net/lantiq,pef2256.yaml > b/Documentation/devicetree/bindings/net/lantiq,pef2256.yaml > new file mode 100644 > index ..b369a20d61b1 > --- /dev/null > +++ b/Documentation/devicetree/bindings/net/lantiq,pef2256.yaml > @@ -0,0 +1,226 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/net/lantiq,pef2256.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Lantiq PEF2256 > + > +maintainers: > + - Herve Codina > + > +description: > + The Lantiq PEF2256, also known as Infineon PEF2256 or FALC56, is a framer > and > + line interface component designed to fulfill all required interfacing > between > + an analog E1/T1/J1 line and the digital PCM system highway/H.100 bus. > + > +properties: > + compatible: > +items: > + - const: lantiq,pef2256 > + > + reg: > +maxItems: 1 > + > + clocks: > +items: > + - description: Master clock > + - description: Receive System Clock > + - description: Transmit System Clock > + > + clock-names: > +items: > + - const: mclk > + - const: sclkr > + - const: sclkx > + > + interrupts: > +maxItems: 1 > + > + reset-gpios: > +description: > + GPIO used to reset the device. > +maxItems: 1 > + > + '#framer-cells': Looks generic, but no such property is defined. You don't need something like this unless there are multiple providers and you need each provider to define the number of cells. > +const: 0 > + > + pinctrl: > +$ref: /schemas/pinctrl/pinctrl.yaml# > +additionalProperties: false > + > +patternProperties: > + '-pins$': > +type: object > +$ref: /schemas/pinctrl/pincfg-node.yaml# > +additionalProperties: false > + > +properties: > + pins: > +enum: [ RPA, RPB, RPC, RPD, XPA, XPB, XPC, XPD ] > + > + function: > +enum: [ SYPR, RFM, RFMB, RSIGM, RSIG, DLR, FREEZE, RFSP, LOS, > +SYPX, XFMS, XSIG, TCLK, XMFB, XSIGM, DLX, XCLK, XLT, > +GPI, GPOH, GPOL ] > + > +required: > + - pins > + - function > + > + lantiq,data-rate-bps: > +$ref: /schemas/types.yaml#/definitions/uint32 > +enum: [2048000, 4096000, 8192000, 16384000] > +default: 2048000 > +description: > + Data rate (bit per seconds) on the system highway. > + > + lantiq,clock-falling-edge: > +$ref: /schemas/types.yaml#/definitions/flag > +description: > + Data is sent on falling edge of the clock (and received on the rising > + edge). If 'clock-falling-edge' is not present, data is sent on the > + rising edge (and received on the falling edge). > + > + lantiq,channel-phase: > +$ref: /schemas/types.yaml#/definitions/uint32 > +enum: [0, 1, 2, 3, 4, 5, 6, 7] > +default: 0 > +description: > + The pef2256 delivers a full frame (32 8bit time-slots in E1 and 24 8bit > + time-slots 8 8bit signaling in E1/J1) every 125us. This lead to a data > + rate of 2048000 bit/s. When lantiq,data-rate-bps is more than 2048000 > + bit/s, the data (all 32 8bit) present in the frame are interleave with > + unused time-slots. The lantiq,channel-phase property allows to set the > + correct alignment of the interleave mechanism. > + For instance, suppose lantiq,data-rate-bps = 8192000 (ie 4*2048000), > and > + lantiq,channel-phase = 2, the interleave schema with unused time-slots > + (nu) and used time-slots (XX) for TSi is > +nu nu XX nu nu nu XX nu nu nu XX nu > +<-- TSi --> <- TSi+1 -> <- TSi+2 -> > + With lantiq,data-rate-bps = 8192000, and lantiq,channel-phase = 1, the > + interleave schema is > +nu XX nu nu nu XX nu nu nu XX nu nu > +<-- TSi --> <- TSi+1 -> <- TSi+2 -> > + With lantiq,data-rate-bps = 4096000 (ie 2*2048000), and > + lantiq,channel-phase = 1, the interleave schema is > +nuXXnuXXnuXX > +<-- TSi --> <- TSi+1 -> <- TSi+2 -> > + > +patternProperties: > + '^codec(-([0-9]|[1-2][0-9]|3[0-1]))?$': > +type: object > +$ref: /schemas/sound/dai-common.yaml > +unevaluatedProperties: false > +description: > + Codec provided by the pef2256. This codec allows to use some of the PCM > + system highway time-slots as audio channels to transport audio data > over > +
[PATCH v6 10/25] iommu/exynos: Implement an IDENTITY domain
What exynos calls exynos_iommu_detach_device is actually putting the iommu
into identity mode.
Move to the new core support for ARM_DMA_USE_IOMMU by defining
ops->identity_domain.
Tested-by: Marek Szyprowski
Acked-by: Marek Szyprowski
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/exynos-iommu.c | 66 +---
1 file changed, 32 insertions(+), 34 deletions(-)
diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index c275fe71c4db32..5e12b85dfe8705 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -24,6 +24,7 @@
typedef u32 sysmmu_iova_t;
typedef u32 sysmmu_pte_t;
+static struct iommu_domain exynos_identity_domain;
/* We do not consider super section mapping (16MB) */
#define SECT_ORDER 20
@@ -829,7 +830,7 @@ static int __maybe_unused exynos_sysmmu_suspend(struct
device *dev)
struct exynos_iommu_owner *owner = dev_iommu_priv_get(master);
mutex_lock(>rpm_lock);
- if (data->domain) {
+ if (>domain->domain != _identity_domain) {
dev_dbg(data->sysmmu, "saving state\n");
__sysmmu_disable(data);
}
@@ -847,7 +848,7 @@ static int __maybe_unused exynos_sysmmu_resume(struct
device *dev)
struct exynos_iommu_owner *owner = dev_iommu_priv_get(master);
mutex_lock(>rpm_lock);
- if (data->domain) {
+ if (>domain->domain != _identity_domain) {
dev_dbg(data->sysmmu, "restoring state\n");
__sysmmu_enable(data);
}
@@ -980,17 +981,20 @@ static void exynos_iommu_domain_free(struct iommu_domain
*iommu_domain)
kfree(domain);
}
-static void exynos_iommu_detach_device(struct iommu_domain *iommu_domain,
- struct device *dev)
+static int exynos_iommu_identity_attach(struct iommu_domain *identity_domain,
+ struct device *dev)
{
- struct exynos_iommu_domain *domain = to_exynos_domain(iommu_domain);
struct exynos_iommu_owner *owner = dev_iommu_priv_get(dev);
- phys_addr_t pagetable = virt_to_phys(domain->pgtable);
+ struct exynos_iommu_domain *domain;
+ phys_addr_t pagetable;
struct sysmmu_drvdata *data, *next;
unsigned long flags;
- if (!has_sysmmu(dev) || owner->domain != iommu_domain)
- return;
+ if (owner->domain == identity_domain)
+ return 0;
+
+ domain = to_exynos_domain(owner->domain);
+ pagetable = virt_to_phys(domain->pgtable);
mutex_lock(>rpm_lock);
@@ -1009,15 +1013,25 @@ static void exynos_iommu_detach_device(struct
iommu_domain *iommu_domain,
list_del_init(>domain_node);
spin_unlock(>lock);
}
- owner->domain = NULL;
+ owner->domain = identity_domain;
spin_unlock_irqrestore(>lock, flags);
mutex_unlock(>rpm_lock);
- dev_dbg(dev, "%s: Detached IOMMU with pgtable %pa\n", __func__,
- );
+ dev_dbg(dev, "%s: Restored IOMMU to IDENTITY from pgtable %pa\n",
+ __func__, );
+ return 0;
}
+static struct iommu_domain_ops exynos_identity_ops = {
+ .attach_dev = exynos_iommu_identity_attach,
+};
+
+static struct iommu_domain exynos_identity_domain = {
+ .type = IOMMU_DOMAIN_IDENTITY,
+ .ops = _identity_ops,
+};
+
static int exynos_iommu_attach_device(struct iommu_domain *iommu_domain,
struct device *dev)
{
@@ -1026,12 +1040,11 @@ static int exynos_iommu_attach_device(struct
iommu_domain *iommu_domain,
struct sysmmu_drvdata *data;
phys_addr_t pagetable = virt_to_phys(domain->pgtable);
unsigned long flags;
+ int err;
- if (!has_sysmmu(dev))
- return -ENODEV;
-
- if (owner->domain)
- exynos_iommu_detach_device(owner->domain, dev);
+ err = exynos_iommu_identity_attach(_identity_domain, dev);
+ if (err)
+ return err;
mutex_lock(>rpm_lock);
@@ -1407,26 +1420,12 @@ static struct iommu_device
*exynos_iommu_probe_device(struct device *dev)
return >iommu;
}
-static void exynos_iommu_set_platform_dma(struct device *dev)
-{
- struct exynos_iommu_owner *owner = dev_iommu_priv_get(dev);
-
- if (owner->domain) {
- struct iommu_group *group = iommu_group_get(dev);
-
- if (group) {
- exynos_iommu_detach_device(owner->domain, dev);
- iommu_group_put(group);
- }
- }
-}
-
static void exynos_iommu_release_device(struct device *dev)
{
struct exynos_iommu_owner *owner = dev_iommu_priv_get(dev);
struct sysmmu_drvdata *data;
- exynos_iommu_set_platform_dma(dev);
+
[PATCH v6 09/25] iommu: Allow an IDENTITY domain as the default_domain in ARM32
Even though dma-iommu.c and CONFIG_ARM_DMA_USE_IOMMU do approximately the
same stuff, the way they relate to the IOMMU core is quiet different.
dma-iommu.c expects the core code to setup an UNMANAGED domain (of type
IOMMU_DOMAIN_DMA) and then configures itself to use that domain. This
becomes the default_domain for the group.
ARM_DMA_USE_IOMMU does not use the default_domain, instead it directly
allocates an UNMANAGED domain and operates it just like an external
driver. In this case group->default_domain is NULL.
If the driver provides a global static identity_domain then automatically
use it as the default_domain when in ARM_DMA_USE_IOMMU mode.
This allows drivers that implemented default_domain == NULL as an IDENTITY
translation to trivially get a properly labeled non-NULL default_domain on
ARM32 configs.
With this arrangment when ARM_DMA_USE_IOMMU wants to disconnect from the
device the normal detach_domain flow will restore the IDENTITY domain as
the default domain. Overall this makes attach_dev() of the IDENTITY domain
called in the same places as detach_dev().
This effectively migrates these drivers to default_domain mode. For
drivers that support ARM64 they will gain support for the IDENTITY
translation mode for the dma_api and behave in a uniform way.
Drivers use this by setting ops->identity_domain to a static singleton
iommu_domain that implements the identity attach. If the core detects
ARM_DMA_USE_IOMMU mode then it automatically attaches the IDENTITY domain
during probe.
Drivers can continue to prevent the use of DMA translation by returning
IOMMU_DOMAIN_IDENTITY from def_domain_type, this will completely prevent
IOMMU_DMA from running but will not impact ARM_DMA_USE_IOMMU.
This allows removing the set_platform_dma_ops() from every remaining
driver.
Remove the set_platform_dma_ops from rockchip and mkt_v1 as all it does
is set an existing global static identity domain. mkt_v1 does not support
IOMMU_DOMAIN_DMA and it does not compile on ARM64 so this transformation
is safe.
Tested-by: Steven Price
Tested-by: Marek Szyprowski
Tested-by: Nicolin Chen
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/iommu.c | 26 +++---
drivers/iommu/mtk_iommu_v1.c | 12
drivers/iommu/rockchip-iommu.c | 10 --
3 files changed, 23 insertions(+), 25 deletions(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 53174179102d17..a1a93990b3a211 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -1771,15 +1771,35 @@ static int iommu_get_default_domain_type(struct
iommu_group *group,
int type;
lockdep_assert_held(>mutex);
+
+ /*
+* ARM32 drivers supporting CONFIG_ARM_DMA_USE_IOMMU can declare an
+* identity_domain and it will automatically become their default
+* domain. Later on ARM_DMA_USE_IOMMU will install its UNMANAGED domain.
+* Override the selection to IDENTITY if we are sure the driver supports
+* it.
+*/
+ if (IS_ENABLED(CONFIG_ARM_DMA_USE_IOMMU) && ops->identity_domain) {
+ type = IOMMU_DOMAIN_IDENTITY;
+ if (best_type && type && best_type != type)
+ return -1;
+ best_type = target_type = IOMMU_DOMAIN_IDENTITY;
+ }
+
for_each_group_device(group, gdev) {
type = best_type;
if (ops->def_domain_type) {
type = ops->def_domain_type(gdev->dev);
- if (best_type && type && best_type != type)
+ if (best_type && type && best_type != type) {
+ /* Stick with the last driver override we saw */
+ best_type = type;
goto err;
+ }
}
- if (dev_is_pci(gdev->dev) && to_pci_dev(gdev->dev)->untrusted) {
+ /* No ARM32 using systems will set untrusted, it cannot work. */
+ if (dev_is_pci(gdev->dev) && to_pci_dev(gdev->dev)->untrusted &&
+ !WARN_ON(IS_ENABLED(CONFIG_ARM_DMA_USE_IOMMU))) {
type = IOMMU_DOMAIN_DMA;
if (best_type && type && best_type != type)
goto err;
@@ -1804,7 +1824,7 @@ static int iommu_get_default_domain_type(struct
iommu_group *group,
"Device needs domain type %s, but device %s in the same iommu
group requires type %s - using default\n",
iommu_domain_type_str(type), dev_name(last_dev),
iommu_domain_type_str(best_type));
- return 0;
+ return best_type;
}
static void iommu_group_do_probe_finalize(struct device *dev)
diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index cc3e7d53d33ad9..7c0c1d50df5f75 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -337,11 +337,6 @@ static struct
[PATCH v6 23/25] iommu: Add ops->domain_alloc_paging()
This callback requests the driver to create only a __IOMMU_DOMAIN_PAGING
domain, so it saves a few lines in a lot of drivers needlessly checking
the type.
More critically, this allows us to sweep out all the
IOMMU_DOMAIN_UNMANAGED and IOMMU_DOMAIN_DMA checks from a lot of the
drivers, simplifying what is going on in the code and ultimately removing
the now-unused special cases in drivers where they did not support
IOMMU_DOMAIN_DMA.
domain_alloc_paging() should return a struct iommu_domain that is
functionally compatible with ARM_DMA_USE_IOMMU, dma-iommu.c and iommufd.
Be forwards looking and pass in a 'struct device *' argument. We can
provide this when allocating the default_domain. No drivers will look at
this.
Tested-by: Steven Price
Tested-by: Marek Szyprowski
Tested-by: Nicolin Chen
Reviewed-by: Lu Baolu
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/iommu.c | 13 ++---
include/linux/iommu.h | 3 +++
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index bc8b35e31b5343..5b5cf74edc7e53 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -1999,6 +1999,7 @@ void iommu_set_fault_handler(struct iommu_domain *domain,
EXPORT_SYMBOL_GPL(iommu_set_fault_handler);
static struct iommu_domain *__iommu_domain_alloc(const struct iommu_ops *ops,
+struct device *dev,
unsigned int type)
{
struct iommu_domain *domain;
@@ -2006,8 +2007,13 @@ static struct iommu_domain *__iommu_domain_alloc(const
struct iommu_ops *ops,
if (alloc_type == IOMMU_DOMAIN_IDENTITY && ops->identity_domain)
return ops->identity_domain;
+ else if (type & __IOMMU_DOMAIN_PAGING && ops->domain_alloc_paging) {
+ domain = ops->domain_alloc_paging(dev);
+ } else if (ops->domain_alloc)
+ domain = ops->domain_alloc(alloc_type);
+ else
+ return NULL;
- domain = ops->domain_alloc(alloc_type);
if (!domain)
return NULL;
@@ -2038,14 +2044,15 @@ __iommu_group_domain_alloc(struct iommu_group *group,
unsigned int type)
lockdep_assert_held(>mutex);
- return __iommu_domain_alloc(dev_iommu_ops(dev), type);
+ return __iommu_domain_alloc(dev_iommu_ops(dev), dev, type);
}
struct iommu_domain *iommu_domain_alloc(const struct bus_type *bus)
{
if (bus == NULL || bus->iommu_ops == NULL)
return NULL;
- return __iommu_domain_alloc(bus->iommu_ops, IOMMU_DOMAIN_UNMANAGED);
+ return __iommu_domain_alloc(bus->iommu_ops, NULL,
+ IOMMU_DOMAIN_UNMANAGED);
}
EXPORT_SYMBOL_GPL(iommu_domain_alloc);
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index df54066c262db4..8f69866c868e04 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -233,6 +233,8 @@ struct iommu_iotlb_gather {
* struct iommu_ops - iommu ops and capabilities
* @capable: check capability
* @domain_alloc: allocate iommu domain
+ * @domain_alloc_paging: Allocate an iommu_domain that can be used for
+ * UNMANAGED, DMA, and DMA_FQ domain types.
* @probe_device: Add device to iommu driver handling
* @release_device: Remove device from iommu driver handling
* @probe_finalize: Do final setup work after the device is added to an IOMMU
@@ -264,6 +266,7 @@ struct iommu_ops {
/* Domain allocation and freeing by the iommu driver */
struct iommu_domain *(*domain_alloc)(unsigned iommu_domain_type);
+ struct iommu_domain *(*domain_alloc_paging)(struct device *dev);
struct iommu_device *(*probe_device)(struct device *dev);
void (*release_device)(struct device *dev);
--
2.41.0
[PATCH v6 01/25] iommu: Add iommu_ops->identity_domain
This allows a driver to set a global static to an IDENTITY domain and
the core code will automatically use it whenever an IDENTITY domain
is requested.
By making it always available it means the IDENTITY can be used in error
handling paths to force the iommu driver into a known state. Devices
implementing global static identity domains should avoid failing their
attach_dev ops.
Convert rockchip to use the new mechanism.
Tested-by: Steven Price
Tested-by: Marek Szyprowski
Tested-by: Nicolin Chen
Reviewed-by: Lu Baolu
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/iommu.c | 3 +++
drivers/iommu/rockchip-iommu.c | 9 +
include/linux/iommu.h | 3 +++
3 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 4352a149a935e8..5e3cdc9f3a9e78 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -1931,6 +1931,9 @@ static struct iommu_domain *__iommu_domain_alloc(const
struct bus_type *bus,
if (bus == NULL || bus->iommu_ops == NULL)
return NULL;
+ if (alloc_type == IOMMU_DOMAIN_IDENTITY &&
bus->iommu_ops->identity_domain)
+ return bus->iommu_ops->identity_domain;
+
domain = bus->iommu_ops->domain_alloc(alloc_type);
if (!domain)
return NULL;
diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
index 8ff69fbf9f65db..033678f2f8b3ab 100644
--- a/drivers/iommu/rockchip-iommu.c
+++ b/drivers/iommu/rockchip-iommu.c
@@ -989,13 +989,8 @@ static int rk_iommu_identity_attach(struct iommu_domain
*identity_domain,
return 0;
}
-static void rk_iommu_identity_free(struct iommu_domain *domain)
-{
-}
-
static struct iommu_domain_ops rk_identity_ops = {
.attach_dev = rk_iommu_identity_attach,
- .free = rk_iommu_identity_free,
};
static struct iommu_domain rk_identity_domain = {
@@ -1059,9 +1054,6 @@ static struct iommu_domain
*rk_iommu_domain_alloc(unsigned type)
{
struct rk_iommu_domain *rk_domain;
- if (type == IOMMU_DOMAIN_IDENTITY)
- return _identity_domain;
-
if (type != IOMMU_DOMAIN_UNMANAGED && type != IOMMU_DOMAIN_DMA)
return NULL;
@@ -1186,6 +1178,7 @@ static int rk_iommu_of_xlate(struct device *dev,
}
static const struct iommu_ops rk_iommu_ops = {
+ .identity_domain = _identity_domain,
.domain_alloc = rk_iommu_domain_alloc,
.probe_device = rk_iommu_probe_device,
.release_device = rk_iommu_release_device,
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index b1dcb1b9b17040..e05c93b6c37fba 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -254,6 +254,8 @@ struct iommu_iotlb_gather {
*will be blocked by the hardware.
* @pgsize_bitmap: bitmap of all possible supported page sizes
* @owner: Driver module providing these ops
+ * @identity_domain: An always available, always attachable identity
+ * translation.
*/
struct iommu_ops {
bool (*capable)(struct device *dev, enum iommu_cap);
@@ -287,6 +289,7 @@ struct iommu_ops {
const struct iommu_domain_ops *default_domain_ops;
unsigned long pgsize_bitmap;
struct module *owner;
+ struct iommu_domain *identity_domain;
};
/**
--
2.41.0
[PATCH v6 22/25] iommu: Add __iommu_group_domain_alloc()
Allocate a domain from a group. Automatically obtains the iommu_ops to use
from the device list of the group. Convert the internal callers to use it.
Tested-by: Steven Price
Tested-by: Marek Szyprowski
Tested-by: Nicolin Chen
Reviewed-by: Lu Baolu
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/iommu.c | 66 ---
1 file changed, 37 insertions(+), 29 deletions(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 1533e65d075bce..bc8b35e31b5343 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -94,8 +94,8 @@ static const char * const iommu_group_resv_type_string[] = {
static int iommu_bus_notifier(struct notifier_block *nb,
unsigned long action, void *data);
static void iommu_release_device(struct device *dev);
-static struct iommu_domain *__iommu_domain_alloc(const struct bus_type *bus,
-unsigned type);
+static struct iommu_domain *
+__iommu_group_domain_alloc(struct iommu_group *group, unsigned int type);
static int __iommu_attach_device(struct iommu_domain *domain,
struct device *dev);
static int __iommu_attach_group(struct iommu_domain *domain,
@@ -1713,12 +1713,11 @@ struct iommu_group *fsl_mc_device_group(struct device
*dev)
EXPORT_SYMBOL_GPL(fsl_mc_device_group);
static struct iommu_domain *
-__iommu_group_alloc_default_domain(const struct bus_type *bus,
- struct iommu_group *group, int req_type)
+__iommu_group_alloc_default_domain(struct iommu_group *group, int req_type)
{
if (group->default_domain && group->default_domain->type == req_type)
return group->default_domain;
- return __iommu_domain_alloc(bus, req_type);
+ return __iommu_group_domain_alloc(group, req_type);
}
/*
@@ -1728,9 +1727,10 @@ __iommu_group_alloc_default_domain(const struct bus_type
*bus,
static struct iommu_domain *
iommu_group_alloc_default_domain(struct iommu_group *group, int req_type)
{
- const struct bus_type *bus =
+ struct device *dev =
list_first_entry(>devices, struct group_device, list)
- ->dev->bus;
+ ->dev;
+ const struct iommu_ops *ops = dev_iommu_ops(dev);
struct iommu_domain *dom;
lockdep_assert_held(>mutex);
@@ -1740,24 +1740,24 @@ iommu_group_alloc_default_domain(struct iommu_group
*group, int req_type)
* domain. This should always be either an IDENTITY or PLATFORM domain.
* Do not use in new drivers.
*/
- if (bus->iommu_ops->default_domain) {
+ if (ops->default_domain) {
if (req_type)
return ERR_PTR(-EINVAL);
- return bus->iommu_ops->default_domain;
+ return ops->default_domain;
}
if (req_type)
- return __iommu_group_alloc_default_domain(bus, group, req_type);
+ return __iommu_group_alloc_default_domain(group, req_type);
/* The driver gave no guidance on what type to use, try the default */
- dom = __iommu_group_alloc_default_domain(bus, group,
iommu_def_domain_type);
+ dom = __iommu_group_alloc_default_domain(group, iommu_def_domain_type);
if (dom)
return dom;
/* Otherwise IDENTITY and DMA_FQ defaults will try DMA */
if (iommu_def_domain_type == IOMMU_DOMAIN_DMA)
return NULL;
- dom = __iommu_group_alloc_default_domain(bus, group, IOMMU_DOMAIN_DMA);
+ dom = __iommu_group_alloc_default_domain(group, IOMMU_DOMAIN_DMA);
if (!dom)
return NULL;
@@ -1998,19 +1998,16 @@ void iommu_set_fault_handler(struct iommu_domain
*domain,
}
EXPORT_SYMBOL_GPL(iommu_set_fault_handler);
-static struct iommu_domain *__iommu_domain_alloc(const struct bus_type *bus,
-unsigned type)
+static struct iommu_domain *__iommu_domain_alloc(const struct iommu_ops *ops,
+unsigned int type)
{
struct iommu_domain *domain;
unsigned int alloc_type = type & IOMMU_DOMAIN_ALLOC_FLAGS;
- if (bus == NULL || bus->iommu_ops == NULL)
- return NULL;
+ if (alloc_type == IOMMU_DOMAIN_IDENTITY && ops->identity_domain)
+ return ops->identity_domain;
- if (alloc_type == IOMMU_DOMAIN_IDENTITY &&
bus->iommu_ops->identity_domain)
- return bus->iommu_ops->identity_domain;
-
- domain = bus->iommu_ops->domain_alloc(alloc_type);
+ domain = ops->domain_alloc(alloc_type);
if (!domain)
return NULL;
@@ -2020,10 +2017,10 @@ static struct iommu_domain *__iommu_domain_alloc(const
struct bus_type *bus,
* may override this later
*/
if (!domain->pgsize_bitmap)
- domain->pgsize_bitmap =
[PATCH v6 13/25] iommu/omap: Implement an IDENTITY domain
What omap does during omap_iommu_set_platform_dma() is actually putting
the iommu into identity mode.
Move to the new core support for ARM_DMA_USE_IOMMU by defining
ops->identity_domain.
This driver does not support IOMMU_DOMAIN_DMA, however it cannot be
compiled on ARM64 either. Most likely it is fine to support dma-iommu.c
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/omap-iommu.c | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 537e402f9bba97..34340ef15241bc 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -1555,16 +1555,31 @@ static void _omap_iommu_detach_dev(struct
omap_iommu_domain *omap_domain,
omap_domain->dev = NULL;
}
-static void omap_iommu_set_platform_dma(struct device *dev)
+static int omap_iommu_identity_attach(struct iommu_domain *identity_domain,
+ struct device *dev)
{
struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
- struct omap_iommu_domain *omap_domain = to_omap_domain(domain);
+ struct omap_iommu_domain *omap_domain;
+ if (domain == identity_domain || !domain)
+ return 0;
+
+ omap_domain = to_omap_domain(domain);
spin_lock(_domain->lock);
_omap_iommu_detach_dev(omap_domain, dev);
spin_unlock(_domain->lock);
+ return 0;
}
+static struct iommu_domain_ops omap_iommu_identity_ops = {
+ .attach_dev = omap_iommu_identity_attach,
+};
+
+static struct iommu_domain omap_iommu_identity_domain = {
+ .type = IOMMU_DOMAIN_IDENTITY,
+ .ops = _iommu_identity_ops,
+};
+
static struct iommu_domain *omap_iommu_domain_alloc(unsigned type)
{
struct omap_iommu_domain *omap_domain;
@@ -1732,11 +1747,11 @@ static struct iommu_group
*omap_iommu_device_group(struct device *dev)
}
static const struct iommu_ops omap_iommu_ops = {
+ .identity_domain = _iommu_identity_domain,
.domain_alloc = omap_iommu_domain_alloc,
.probe_device = omap_iommu_probe_device,
.release_device = omap_iommu_release_device,
.device_group = omap_iommu_device_group,
- .set_platform_dma_ops = omap_iommu_set_platform_dma,
.pgsize_bitmap = OMAP_IOMMU_PGSIZES,
.default_domain_ops = &(const struct iommu_domain_ops) {
.attach_dev = omap_iommu_attach_dev,
--
2.41.0
[PATCH v6 21/25] iommu: Require a default_domain for all iommu drivers
At this point every iommu driver will cause a default_domain to be
selected, so we can finally remove this gap from the core code.
The following table explains what each driver supports and what the
resulting default_domain will be:
ops->defaut_domain
IDENTITY DMA PLATFORMv ARM32 dma-iommu
ARCH
amd/iommu.c Y Y N/A either
apple-dart.cY Y N/A either
arm-smmu.c Y Y IDENTITYeither
qcom_iommu.cG Y IDENTITYeither
arm-smmu-v3.c Y Y N/A either
exynos-iommu.c G Y IDENTITYeither
fsl_pamu_domain.c Y N/A N/A
PLATFORM
intel/iommu.c Y Y N/A either
ipmmu-vmsa.cG Y IDENTITYeither
msm_iommu.c G IDENTITYN/A
mtk_iommu.c G Y IDENTITYeither
mtk_iommu_v1.c G IDENTITYN/A
omap-iommu.cG IDENTITYN/A
rockchip-iommu.cG Y IDENTITYeither
s390-iommu.cY Y N/A N/A
PLATFORM
sprd-iommu.cY N/A DMA
sun50i-iommu.c G Y IDENTITYeither
tegra-smmu.cG Y IDENTITYIDENTITY
virtio-iommu.c Y Y N/A either
spapr Y Y N/A N/A
PLATFORM
* G means ops->identity_domain is used
* N/A means the driver will not compile in this configuration
ARM32 drivers select an IDENTITY default domain through either the
ops->identity_domain or directly requesting an IDENTIY domain through
alloc_domain().
In ARM64 mode tegra-smmu will still block the use of dma-iommu.c and
forces an IDENTITY domain.
S390 uses a PLATFORM domain to represent when the dma_ops are set to the
s390 iommu code.
fsl_pamu uses an IDENTITY domain.
POWER SPAPR uses PLATFORM and blocking to enable its weird VFIO mode.
The x86 drivers continue unchanged.
After this patch group->default_domain is only NULL for a short period
during bus iommu probing while all the groups are constituted. Otherwise
it is always !NULL.
This completes changing the iommu subsystem driver contract to a system
where the current iommu_domain always represents some form of translation
and the driver is continuously asserting a definable translation mode.
It resolves the confusion that the original ops->detach_dev() caused
around what translation, exactly, is the IOMMU performing after
detach. There were at least three different answers to that question in
the tree, they are all now clearly named with domain types.
Tested-by: Heiko Stuebner
Tested-by: Niklas Schnelle
Tested-by: Steven Price
Tested-by: Marek Szyprowski
Tested-by: Nicolin Chen
Reviewed-by: Lu Baolu
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/iommu.c | 21 +++--
1 file changed, 7 insertions(+), 14 deletions(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index dada2c00d78ca4..1533e65d075bce 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -1819,10 +1819,12 @@ static int iommu_get_default_domain_type(struct
iommu_group *group,
* ARM32 drivers supporting CONFIG_ARM_DMA_USE_IOMMU can declare an
* identity_domain and it will automatically become their default
* domain. Later on ARM_DMA_USE_IOMMU will install its UNMANAGED domain.
-* Override the selection to IDENTITY if we are sure the driver supports
-* it.
+* Override the selection to IDENTITY.
*/
- if (IS_ENABLED(CONFIG_ARM_DMA_USE_IOMMU) && ops->identity_domain) {
+ if (IS_ENABLED(CONFIG_ARM_DMA_USE_IOMMU)) {
+ static_assert(!(IS_ENABLED(CONFIG_ARM_DMA_USE_IOMMU) &&
+ IS_ENABLED(CONFIG_IOMMU_DMA)));
+
type = IOMMU_DOMAIN_IDENTITY;
if (best_type && type && best_type != type)
return -1;
@@ -2920,18 +2922,9 @@ static int iommu_setup_default_domain(struct iommu_group
*group,
if (req_type < 0)
return -EINVAL;
- /*
-* There are still some drivers which don't support default domains, so
-* we ignore the failure and leave group->default_domain NULL.
-*/
dom = iommu_group_alloc_default_domain(group, req_type);
- if (!dom) {
- /* Once in
[PATCH v6 15/25] iommufd/selftest: Make the mock iommu driver into a real driver
I've avoided doing this because there is no way to make this happen
without an intrusion into the core code. Up till now this has avoided
needing the core code's probe path with some hackery - but now that
default domains are becoming mandatory it is unavoidable. The core probe
path must be run to set the default_domain, only it can do it. Without
a default domain iommufd can't use the group.
Make it so that iommufd selftest can create a real iommu driver and bind
it only to is own private bus. Add iommu_device_register_bus() as a core
code helper to make this possible. It simply sets the right pointers and
registers the notifier block. The mock driver then works like any normal
driver should, with probe triggered by the bus ops
When the bus->iommu_ops stuff is fully unwound we can probably do better
here and remove this special case.
Remove set_platform_dma_ops from selftest and make it use a BLOCKED
default domain.
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/iommu-priv.h | 16 +++
drivers/iommu/iommu.c | 43 +++
drivers/iommu/iommufd/iommufd_private.h | 5 +-
drivers/iommu/iommufd/main.c| 8 +-
drivers/iommu/iommufd/selftest.c| 149 +---
5 files changed, 152 insertions(+), 69 deletions(-)
create mode 100644 drivers/iommu/iommu-priv.h
diff --git a/drivers/iommu/iommu-priv.h b/drivers/iommu/iommu-priv.h
new file mode 100644
index 00..1cbc04b9cf7297
--- /dev/null
+++ b/drivers/iommu/iommu-priv.h
@@ -0,0 +1,16 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* Copyright (c) 2023, NVIDIA CORPORATION & AFFILIATES.
+ */
+#ifndef __IOMMU_PRIV_H
+#define __IOMMU_PRIV_H
+
+#include
+
+int iommu_device_register_bus(struct iommu_device *iommu,
+ const struct iommu_ops *ops, struct bus_type *bus,
+ struct notifier_block *nb);
+void iommu_device_unregister_bus(struct iommu_device *iommu,
+struct bus_type *bus,
+struct notifier_block *nb);
+
+#endif
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index a1a93990b3a211..7fae866af0db7a 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -36,6 +36,7 @@
#include "dma-iommu.h"
#include "iommu-sva.h"
+#include "iommu-priv.h"
static struct kset *iommu_group_kset;
static DEFINE_IDA(iommu_group_ida);
@@ -290,6 +291,48 @@ void iommu_device_unregister(struct iommu_device *iommu)
}
EXPORT_SYMBOL_GPL(iommu_device_unregister);
+#if IS_ENABLED(CONFIG_IOMMUFD_TEST)
+void iommu_device_unregister_bus(struct iommu_device *iommu,
+struct bus_type *bus,
+struct notifier_block *nb)
+{
+ bus_unregister_notifier(bus, nb);
+ iommu_device_unregister(iommu);
+}
+EXPORT_SYMBOL_GPL(iommu_device_unregister_bus);
+
+/*
+ * Register an iommu driver against a single bus. This is only used by iommufd
+ * selftest to create a mock iommu driver. The caller must provide
+ * some memory to hold a notifier_block.
+ */
+int iommu_device_register_bus(struct iommu_device *iommu,
+ const struct iommu_ops *ops, struct bus_type *bus,
+ struct notifier_block *nb)
+{
+ int err;
+
+ iommu->ops = ops;
+ nb->notifier_call = iommu_bus_notifier;
+ err = bus_register_notifier(bus, nb);
+ if (err)
+ return err;
+
+ spin_lock(_device_lock);
+ list_add_tail(>list, _device_list);
+ spin_unlock(_device_lock);
+
+ bus->iommu_ops = ops;
+ err = bus_iommu_probe(bus);
+ if (err) {
+ iommu_device_unregister_bus(iommu, bus, nb);
+ return err;
+ }
+ return 0;
+}
+EXPORT_SYMBOL_GPL(iommu_device_register_bus);
+#endif
+
static struct dev_iommu *dev_iommu_get(struct device *dev)
{
struct dev_iommu *param = dev->iommu;
diff --git a/drivers/iommu/iommufd/iommufd_private.h
b/drivers/iommu/iommufd/iommufd_private.h
index b38e67d1988bdb..368f66c63a239a 100644
--- a/drivers/iommu/iommufd/iommufd_private.h
+++ b/drivers/iommu/iommufd/iommufd_private.h
@@ -303,7 +303,7 @@ extern size_t iommufd_test_memory_limit;
void iommufd_test_syz_conv_iova_id(struct iommufd_ucmd *ucmd,
unsigned int ioas_id, u64 *iova, u32 *flags);
bool iommufd_should_fail(void);
-void __init iommufd_test_init(void);
+int __init iommufd_test_init(void);
void iommufd_test_exit(void);
bool iommufd_selftest_is_mock_dev(struct device *dev);
#else
@@ -316,8 +316,9 @@ static inline bool iommufd_should_fail(void)
{
return false;
}
-static inline void __init iommufd_test_init(void)
+static inline int __init iommufd_test_init(void)
{
+ return 0;
}
static inline void iommufd_test_exit(void)
{
diff --git a/drivers/iommu/iommufd/main.c b/drivers/iommu/iommufd/main.c
index 3fbe636c3d8a69..042d45cc0b1c0d 100644
---
[PATCH v6 00/25] iommu: Make default_domain's mandatory
[ It would be good to get this in linux-next, we have some good test coverage on the ARM side already, thanks! ] It has been a long time coming, this series completes the default_domain transition and makes it so that the core IOMMU code will always have a non-NULL default_domain for every driver on every platform. set_platform_dma_ops() turned out to be a bad idea, and so completely remove it. This is achieved by changing each driver to either: 1 - Convert the existing (or deleted) ops->detach_dev() into an op->attach_dev() of an IDENTITY domain. This is based on the theory that the ARM32 HW is able to function when the iommu is turned off and so the turned off state is an IDENTITY translation. 2 - Use a new PLATFORM domain type. This is a hack to accommodate drivers that we don't really know WTF they do. S390 is legitimately using this to switch to it's platform dma_ops implementation, which is where the name comes from. 3 - Do #1 and force the default domain to be IDENTITY, this corrects the tegra-smmu case where even an ARM64 system would have a NULL default_domain. Using this we can apply the rules: a) ARM_DMA_USE_IOMMU mode always uses either the driver's ops->default_domain, ops->def_domain_type(), or an IDENTITY domain. All ARM32 drivers provide one of these three options. b) dma-iommu.c mode uses either the driver's ops->default_domain, ops->def_domain_type or the usual DMA API policy logic based on the command line/etc to pick IDENTITY/DMA domain types c) All other arch's (PPC/S390) use ops->default_domain always. See the patch "Require a default_domain for all iommu drivers" for a per-driver breakdown. The conversion broadly teaches a bunch of ARM32 drivers that they can do IDENTITY domains. There is some educated guessing involved that these are actual IDENTITY domains. If this turns out to be wrong the driver can be trivially changed to use a BLOCKING domain type instead. Further, the domain type only matters for drivers using ARM64's dma-iommu.c mode as it will select IDENTITY based on the command line and expect IDENTITY to work. For ARM32 and other arch cases it is purely documentation. Finally, based on all the analysis in this series, we can purge IOMMU_DOMAIN_UNMANAGED/DMA constants from most of the drivers. This greatly simplifies understanding the driver contract to the core code. IOMMU drivers should not be involved in policy for how the DMA API works, that should be a core core decision. The main gain from this work is to remove alot of ARM_DMA_USE_IOMMU specific code and behaviors from drivers. All that remains in iommu drivers after this series is the calls to arm_iommu_create_mapping(). This is a step toward removing ARM_DMA_USE_IOMMU. The IDENTITY domains added to the ARM64 supporting drivers can be tested by booting in ARM64 mode and enabling CONFIG_IOMMU_DEFAULT_PASSTHROUGH. If the system still boots then most likely the implementation is an IDENTITY domain. If not we can trivially change it to BLOCKING or at worst PLATFORM if there is no detail what is going on in the HW. I think this is pretty safe for the ARM32 drivers as they don't really change, the code that was in detach_dev continues to be called in the same places it was called before. This is on github: https://github.com/jgunthorpe/linux/commits/iommu_all_defdom v6: - Rebase on v6.5-rc1/Joerg's tree - Fix the iommufd self test missing the iommu_device_sysfs_add() - Update typo in msm commit message v5: https://lore.kernel.org/r/0-v5-d0a204c678c7+3d16a-iommu_all_defdom_...@nvidia.com - Rebase on v6.5-rc1/Joerg's tree - Fix Dan's remark about 'gdev uninitialized' in patch 9 v4: https://lore.kernel.org/r/0-v4-874277bde66e+1a9f6-iommu_all_defdom_...@nvidia.com - Fix rebasing typo missing ops->alloc_domain_paging check - Rebase on latest Joerg tree v3: https://lore.kernel.org/r/0-v3-89830a6c7841+43d-iommu_all_defdom_...@nvidia.com - FSL is back to a PLATFORM domain, with some fixing so it attach only does something when leaving an UNMANAGED domain like it always was - Rebase on Joerg's tree, adjust for "alloc_type" change - Change the ARM32 untrusted check to a WARN_ON since no ARM32 system can currently set trusted v2: https://lore.kernel.org/r/0-v2-8d1dc464eac9+10f-iommu_all_defdom_...@nvidia.com - FSL is an IDENTITY domain - Delete terga-gart instead of trying to carry it - Use the policy determination from iommu_get_default_domain_type() to drive the arm_iommu mode - Reorganize and introduce new patches to do the above: * Split the ops->identity_domain to an independent earlier patch * Remove the UNMANAGED return from def_domain_type in mtk_v1 earlier so the new iommu_get_default_domain_type() can work * Make the driver's def_domain_type have higher policy priority than untrusted * Merge the set_platfom_dma_ops hunk from mtk_v1 along with rockchip into the patch that forced IDENTITY on ARM32
[PATCH v6 18/25] iommu/ipmmu: Add an IOMMU_IDENTITIY_DOMAIN
This brings back the ops->detach_dev() code that commit
1b932ceddd19 ("iommu: Remove detach_dev callbacks") deleted and turns it
into an IDENTITY domain.
Also reverts commit 584d334b1393 ("iommu/ipmmu-vmsa: Remove
ipmmu_utlb_disable()")
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/ipmmu-vmsa.c | 43 ++
1 file changed, 43 insertions(+)
diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index 9f64c5c9f5b90a..de958e411a92e0 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -298,6 +298,18 @@ static void ipmmu_utlb_enable(struct ipmmu_vmsa_domain
*domain,
mmu->utlb_ctx[utlb] = domain->context_id;
}
+/*
+ * Disable MMU translation for the microTLB.
+ */
+static void ipmmu_utlb_disable(struct ipmmu_vmsa_domain *domain,
+ unsigned int utlb)
+{
+ struct ipmmu_vmsa_device *mmu = domain->mmu;
+
+ ipmmu_imuctr_write(mmu, utlb, 0);
+ mmu->utlb_ctx[utlb] = IPMMU_CTX_INVALID;
+}
+
static void ipmmu_tlb_flush_all(void *cookie)
{
struct ipmmu_vmsa_domain *domain = cookie;
@@ -630,6 +642,36 @@ static int ipmmu_attach_device(struct iommu_domain
*io_domain,
return 0;
}
+static int ipmmu_iommu_identity_attach(struct iommu_domain *identity_domain,
+ struct device *dev)
+{
+ struct iommu_domain *io_domain = iommu_get_domain_for_dev(dev);
+ struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
+ struct ipmmu_vmsa_domain *domain;
+ unsigned int i;
+
+ if (io_domain == identity_domain || !io_domain)
+ return 0;
+
+ domain = to_vmsa_domain(io_domain);
+ for (i = 0; i < fwspec->num_ids; ++i)
+ ipmmu_utlb_disable(domain, fwspec->ids[i]);
+
+ /*
+* TODO: Optimize by disabling the context when no device is attached.
+*/
+ return 0;
+}
+
+static struct iommu_domain_ops ipmmu_iommu_identity_ops = {
+ .attach_dev = ipmmu_iommu_identity_attach,
+};
+
+static struct iommu_domain ipmmu_iommu_identity_domain = {
+ .type = IOMMU_DOMAIN_IDENTITY,
+ .ops = _iommu_identity_ops,
+};
+
static int ipmmu_map(struct iommu_domain *io_domain, unsigned long iova,
phys_addr_t paddr, size_t pgsize, size_t pgcount,
int prot, gfp_t gfp, size_t *mapped)
@@ -848,6 +890,7 @@ static struct iommu_group *ipmmu_find_group(struct device
*dev)
}
static const struct iommu_ops ipmmu_ops = {
+ .identity_domain = _iommu_identity_domain,
.domain_alloc = ipmmu_domain_alloc,
.probe_device = ipmmu_probe_device,
.release_device = ipmmu_release_device,
--
2.41.0
[PATCH v6 08/25] iommu: Reorganize iommu_get_default_domain_type() to respect def_domain_type()
Except for dart every driver returns 0 or IDENTITY from def_domain_type().
The drivers that return IDENTITY have some kind of good reason, typically
that quirky hardware really can't support anything other than IDENTITY.
Arrange things so that if the driver says it needs IDENTITY then
iommu_get_default_domain_type() either fails or returns IDENTITY. It will
never reject the driver's override to IDENTITY.
The only real functional difference is that the PCI untrusted flag is now
ignored for quirky HW instead of overriding the IOMMU driver.
This makes the next patch cleaner that wants to force IDENTITY always for
ARM_IOMMU because there is no support for DMA.
Tested-by: Steven Price
Tested-by: Marek Szyprowski
Tested-by: Nicolin Chen
Reviewed-by: Lu Baolu
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/iommu.c | 66 +--
1 file changed, 33 insertions(+), 33 deletions(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index c64365169b678d..53174179102d17 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -1669,19 +1669,6 @@ struct iommu_group *fsl_mc_device_group(struct device
*dev)
}
EXPORT_SYMBOL_GPL(fsl_mc_device_group);
-static int iommu_get_def_domain_type(struct device *dev)
-{
- const struct iommu_ops *ops = dev_iommu_ops(dev);
-
- if (dev_is_pci(dev) && to_pci_dev(dev)->untrusted)
- return IOMMU_DOMAIN_DMA;
-
- if (ops->def_domain_type)
- return ops->def_domain_type(dev);
-
- return 0;
-}
-
static struct iommu_domain *
__iommu_group_alloc_default_domain(const struct bus_type *bus,
struct iommu_group *group, int req_type)
@@ -1775,36 +1762,49 @@ static int iommu_bus_notifier(struct notifier_block *nb,
static int iommu_get_default_domain_type(struct iommu_group *group,
int target_type)
{
+ const struct iommu_ops *ops = dev_iommu_ops(
+ list_first_entry(>devices, struct group_device, list)
+ ->dev);
int best_type = target_type;
struct group_device *gdev;
struct device *last_dev;
+ int type;
lockdep_assert_held(>mutex);
-
for_each_group_device(group, gdev) {
- unsigned int type = iommu_get_def_domain_type(gdev->dev);
-
- if (best_type && type && best_type != type) {
- if (target_type) {
- dev_err_ratelimited(
- gdev->dev,
- "Device cannot be in %s domain\n",
- iommu_domain_type_str(target_type));
- return -1;
- }
-
- dev_warn(
- gdev->dev,
- "Device needs domain type %s, but device %s in
the same iommu group requires type %s - using default\n",
- iommu_domain_type_str(type), dev_name(last_dev),
- iommu_domain_type_str(best_type));
- return 0;
+ type = best_type;
+ if (ops->def_domain_type) {
+ type = ops->def_domain_type(gdev->dev);
+ if (best_type && type && best_type != type)
+ goto err;
}
- if (!best_type)
- best_type = type;
+
+ if (dev_is_pci(gdev->dev) && to_pci_dev(gdev->dev)->untrusted) {
+ type = IOMMU_DOMAIN_DMA;
+ if (best_type && type && best_type != type)
+ goto err;
+ }
+ best_type = type;
last_dev = gdev->dev;
}
return best_type;
+
+err:
+ if (target_type) {
+ dev_err_ratelimited(
+ gdev->dev,
+ "Device cannot be in %s domain - it is forcing %s\n",
+ iommu_domain_type_str(target_type),
+ iommu_domain_type_str(type));
+ return -1;
+ }
+
+ dev_warn(
+ gdev->dev,
+ "Device needs domain type %s, but device %s in the same iommu
group requires type %s - using default\n",
+ iommu_domain_type_str(type), dev_name(last_dev),
+ iommu_domain_type_str(best_type));
+ return 0;
}
static void iommu_group_do_probe_finalize(struct device *dev)
--
2.41.0
[PATCH v6 14/25] iommu/msm: Implement an IDENTITY domain
What msm does during msm_iommu_set_platform_dma() is actually putting the
iommu into identity mode.
Move to the new core support for ARM_DMA_USE_IOMMU by defining
ops->identity_domain.
This driver does not support IOMMU_DOMAIN_DMA, however it cannot be
compiled on ARM64 either. Most likely it is fine to support dma-iommu.c
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/msm_iommu.c | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/msm_iommu.c b/drivers/iommu/msm_iommu.c
index 79d89bad5132b7..26ed81cfeee897 100644
--- a/drivers/iommu/msm_iommu.c
+++ b/drivers/iommu/msm_iommu.c
@@ -443,15 +443,20 @@ static int msm_iommu_attach_dev(struct iommu_domain
*domain, struct device *dev)
return ret;
}
-static void msm_iommu_set_platform_dma(struct device *dev)
+static int msm_iommu_identity_attach(struct iommu_domain *identity_domain,
+struct device *dev)
{
struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
- struct msm_priv *priv = to_msm_priv(domain);
+ struct msm_priv *priv;
unsigned long flags;
struct msm_iommu_dev *iommu;
struct msm_iommu_ctx_dev *master;
- int ret;
+ int ret = 0;
+ if (domain == identity_domain || !domain)
+ return 0;
+
+ priv = to_msm_priv(domain);
free_io_pgtable_ops(priv->iop);
spin_lock_irqsave(_iommu_lock, flags);
@@ -468,8 +473,18 @@ static void msm_iommu_set_platform_dma(struct device *dev)
}
fail:
spin_unlock_irqrestore(_iommu_lock, flags);
+ return ret;
}
+static struct iommu_domain_ops msm_iommu_identity_ops = {
+ .attach_dev = msm_iommu_identity_attach,
+};
+
+static struct iommu_domain msm_iommu_identity_domain = {
+ .type = IOMMU_DOMAIN_IDENTITY,
+ .ops = _iommu_identity_ops,
+};
+
static int msm_iommu_map(struct iommu_domain *domain, unsigned long iova,
phys_addr_t pa, size_t pgsize, size_t pgcount,
int prot, gfp_t gfp, size_t *mapped)
@@ -675,10 +690,10 @@ irqreturn_t msm_iommu_fault_handler(int irq, void *dev_id)
}
static struct iommu_ops msm_iommu_ops = {
+ .identity_domain = _iommu_identity_domain,
.domain_alloc = msm_iommu_domain_alloc,
.probe_device = msm_iommu_probe_device,
.device_group = generic_device_group,
- .set_platform_dma_ops = msm_iommu_set_platform_dma,
.pgsize_bitmap = MSM_IOMMU_PGSIZES,
.of_xlate = qcom_iommu_of_xlate,
.default_domain_ops = &(const struct iommu_domain_ops) {
--
2.41.0
[PATCH v6 20/25] iommu/sun50i: Add an IOMMU_IDENTITIY_DOMAIN
Prior to commit 1b932ceddd19 ("iommu: Remove detach_dev callbacks") the
sun50i_iommu_detach_device() function was being called by
ops->detach_dev().
This is an IDENTITY domain so convert sun50i_iommu_detach_device() into
sun50i_iommu_identity_attach() and a full IDENTITY domain and thus hook it
back up the same was as the old ops->detach_dev().
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/sun50i-iommu.c | 26 +++---
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/iommu/sun50i-iommu.c b/drivers/iommu/sun50i-iommu.c
index 74c5cb93e90027..0bf08b120cf105 100644
--- a/drivers/iommu/sun50i-iommu.c
+++ b/drivers/iommu/sun50i-iommu.c
@@ -757,21 +757,32 @@ static void sun50i_iommu_detach_domain(struct
sun50i_iommu *iommu,
iommu->domain = NULL;
}
-static void sun50i_iommu_detach_device(struct iommu_domain *domain,
- struct device *dev)
+static int sun50i_iommu_identity_attach(struct iommu_domain *identity_domain,
+ struct device *dev)
{
- struct sun50i_iommu_domain *sun50i_domain = to_sun50i_domain(domain);
struct sun50i_iommu *iommu = dev_iommu_priv_get(dev);
+ struct sun50i_iommu_domain *sun50i_domain;
dev_dbg(dev, "Detaching from IOMMU domain\n");
- if (iommu->domain != domain)
- return;
+ if (iommu->domain == identity_domain)
+ return 0;
+ sun50i_domain = to_sun50i_domain(iommu->domain);
if (refcount_dec_and_test(_domain->refcnt))
sun50i_iommu_detach_domain(iommu, sun50i_domain);
+ return 0;
}
+static struct iommu_domain_ops sun50i_iommu_identity_ops = {
+ .attach_dev = sun50i_iommu_identity_attach,
+};
+
+static struct iommu_domain sun50i_iommu_identity_domain = {
+ .type = IOMMU_DOMAIN_IDENTITY,
+ .ops = _iommu_identity_ops,
+};
+
static int sun50i_iommu_attach_device(struct iommu_domain *domain,
struct device *dev)
{
@@ -789,8 +800,7 @@ static int sun50i_iommu_attach_device(struct iommu_domain
*domain,
if (iommu->domain == domain)
return 0;
- if (iommu->domain)
- sun50i_iommu_detach_device(iommu->domain, dev);
+ sun50i_iommu_identity_attach(_iommu_identity_domain, dev);
sun50i_iommu_attach_domain(iommu, sun50i_domain);
@@ -827,6 +837,7 @@ static int sun50i_iommu_of_xlate(struct device *dev,
}
static const struct iommu_ops sun50i_iommu_ops = {
+ .identity_domain = _iommu_identity_domain,
.pgsize_bitmap = SZ_4K,
.device_group = sun50i_iommu_device_group,
.domain_alloc = sun50i_iommu_domain_alloc,
@@ -985,6 +996,7 @@ static int sun50i_iommu_probe(struct platform_device *pdev)
if (!iommu)
return -ENOMEM;
spin_lock_init(>iommu_lock);
+ iommu->domain = _iommu_identity_domain;
platform_set_drvdata(pdev, iommu);
iommu->dev = >dev;
--
2.41.0
[PATCH v6 03/25] powerpc/iommu: Setup a default domain and remove set_platform_dma_ops
POWER is using the set_platform_dma_ops() callback to hook up its private
dma_ops, but this is buired under some indirection and is weirdly
happening for a BLOCKED domain as well.
For better documentation create a PLATFORM domain to manage the dma_ops,
since that is what it is for, and make the BLOCKED domain an alias for
it. BLOCKED is required for VFIO.
Also removes the leaky allocation of the BLOCKED domain by using a global
static.
Signed-off-by: Jason Gunthorpe
---
arch/powerpc/kernel/iommu.c | 38 +
1 file changed, 17 insertions(+), 21 deletions(-)
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index c52449ae6936ad..ffe8d1411a9d56 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -1269,7 +1269,7 @@ struct iommu_table_group_ops spapr_tce_table_group_ops = {
/*
* A simple iommu_ops to allow less cruft in generic VFIO code.
*/
-static int spapr_tce_blocking_iommu_attach_dev(struct iommu_domain *dom,
+static int spapr_tce_platform_iommu_attach_dev(struct iommu_domain *dom,
struct device *dev)
{
struct iommu_group *grp = iommu_group_get(dev);
@@ -1286,17 +1286,22 @@ static int spapr_tce_blocking_iommu_attach_dev(struct
iommu_domain *dom,
return ret;
}
-static void spapr_tce_blocking_iommu_set_platform_dma(struct device *dev)
-{
- struct iommu_group *grp = iommu_group_get(dev);
- struct iommu_table_group *table_group;
+static const struct iommu_domain_ops spapr_tce_platform_domain_ops = {
+ .attach_dev = spapr_tce_platform_iommu_attach_dev,
+};
- table_group = iommu_group_get_iommudata(grp);
- table_group->ops->release_ownership(table_group);
-}
+static struct iommu_domain spapr_tce_platform_domain = {
+ .type = IOMMU_DOMAIN_PLATFORM,
+ .ops = _tce_platform_domain_ops,
+};
-static const struct iommu_domain_ops spapr_tce_blocking_domain_ops = {
- .attach_dev = spapr_tce_blocking_iommu_attach_dev,
+static struct iommu_domain spapr_tce_blocked_domain = {
+ .type = IOMMU_DOMAIN_BLOCKED,
+ /*
+* FIXME: SPAPR mixes blocked and platform behaviors, the blocked domain
+* also sets the dma_api ops
+*/
+ .ops = _tce_platform_domain_ops,
};
static bool spapr_tce_iommu_capable(struct device *dev, enum iommu_cap cap)
@@ -1313,18 +1318,9 @@ static bool spapr_tce_iommu_capable(struct device *dev,
enum iommu_cap cap)
static struct iommu_domain *spapr_tce_iommu_domain_alloc(unsigned int type)
{
- struct iommu_domain *dom;
-
if (type != IOMMU_DOMAIN_BLOCKED)
return NULL;
-
- dom = kzalloc(sizeof(*dom), GFP_KERNEL);
- if (!dom)
- return NULL;
-
- dom->ops = _tce_blocking_domain_ops;
-
- return dom;
+ return _tce_blocked_domain;
}
static struct iommu_device *spapr_tce_iommu_probe_device(struct device *dev)
@@ -1360,12 +1356,12 @@ static struct iommu_group
*spapr_tce_iommu_device_group(struct device *dev)
}
static const struct iommu_ops spapr_tce_iommu_ops = {
+ .default_domain = _tce_platform_domain,
.capable = spapr_tce_iommu_capable,
.domain_alloc = spapr_tce_iommu_domain_alloc,
.probe_device = spapr_tce_iommu_probe_device,
.release_device = spapr_tce_iommu_release_device,
.device_group = spapr_tce_iommu_device_group,
- .set_platform_dma_ops = spapr_tce_blocking_iommu_set_platform_dma,
};
static struct attribute *spapr_tce_iommu_attrs[] = {
--
2.41.0
[PATCH v6 12/25] iommu/tegra-smmu: Support DMA domains in tegra
All ARM64 iommu drivers should support IOMMU_DOMAIN_DMA to enable
dma-iommu.c.
tegra is blocking dma-iommu usage, and also default_domain's, because it
wants an identity translation. This is needed for some device quirk. The
correct way to do this is to support IDENTITY domains and use
ops->def_domain_type() to return IOMMU_DOMAIN_IDENTITY for only the quirky
devices.
Add support for IOMMU_DOMAIN_DMA and force IOMMU_DOMAIN_IDENTITY mode for
everything so no behavior changes.
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/tegra-smmu.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
index f63f1d4f0bd10f..6cba034905edbf 100644
--- a/drivers/iommu/tegra-smmu.c
+++ b/drivers/iommu/tegra-smmu.c
@@ -276,7 +276,7 @@ static struct iommu_domain
*tegra_smmu_domain_alloc(unsigned type)
{
struct tegra_smmu_as *as;
- if (type != IOMMU_DOMAIN_UNMANAGED)
+ if (type != IOMMU_DOMAIN_UNMANAGED && type != IOMMU_DOMAIN_DMA)
return NULL;
as = kzalloc(sizeof(*as), GFP_KERNEL);
@@ -989,6 +989,12 @@ static int tegra_smmu_def_domain_type(struct device *dev)
}
static const struct iommu_ops tegra_smmu_ops = {
+ /*
+* FIXME: For now we want to run all translation in IDENTITY mode,
+* better would be to have a def_domain_type op do this for just the
+* quirky device.
+*/
+ .default_domain = _smmu_identity_domain,
.identity_domain = _smmu_identity_domain,
.def_domain_type = _smmu_def_domain_type,
.domain_alloc = tegra_smmu_domain_alloc,
--
2.41.0
[PATCH v6 11/25] iommu/tegra-smmu: Implement an IDENTITY domain
What tegra-smmu does during tegra_smmu_set_platform_dma() is actually
putting the iommu into identity mode.
Move to the new core support for ARM_DMA_USE_IOMMU by defining
ops->identity_domain.
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/tegra-smmu.c | 37 -
1 file changed, 32 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
index 1cbf063ccf147a..f63f1d4f0bd10f 100644
--- a/drivers/iommu/tegra-smmu.c
+++ b/drivers/iommu/tegra-smmu.c
@@ -511,23 +511,39 @@ static int tegra_smmu_attach_dev(struct iommu_domain
*domain,
return err;
}
-static void tegra_smmu_set_platform_dma(struct device *dev)
+static int tegra_smmu_identity_attach(struct iommu_domain *identity_domain,
+ struct device *dev)
{
struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
- struct tegra_smmu_as *as = to_smmu_as(domain);
- struct tegra_smmu *smmu = as->smmu;
+ struct tegra_smmu_as *as;
+ struct tegra_smmu *smmu;
unsigned int index;
if (!fwspec)
- return;
+ return -ENODEV;
+ if (domain == identity_domain || !domain)
+ return 0;
+
+ as = to_smmu_as(domain);
+ smmu = as->smmu;
for (index = 0; index < fwspec->num_ids; index++) {
tegra_smmu_disable(smmu, fwspec->ids[index], as->id);
tegra_smmu_as_unprepare(smmu, as);
}
+ return 0;
}
+static struct iommu_domain_ops tegra_smmu_identity_ops = {
+ .attach_dev = tegra_smmu_identity_attach,
+};
+
+static struct iommu_domain tegra_smmu_identity_domain = {
+ .type = IOMMU_DOMAIN_IDENTITY,
+ .ops = _smmu_identity_ops,
+};
+
static void tegra_smmu_set_pde(struct tegra_smmu_as *as, unsigned long iova,
u32 value)
{
@@ -962,11 +978,22 @@ static int tegra_smmu_of_xlate(struct device *dev,
return iommu_fwspec_add_ids(dev, , 1);
}
+static int tegra_smmu_def_domain_type(struct device *dev)
+{
+ /*
+* FIXME: For now we want to run all translation in IDENTITY mode, due
+* to some device quirks. Better would be to just quirk the troubled
+* devices.
+*/
+ return IOMMU_DOMAIN_IDENTITY;
+}
+
static const struct iommu_ops tegra_smmu_ops = {
+ .identity_domain = _smmu_identity_domain,
+ .def_domain_type = _smmu_def_domain_type,
.domain_alloc = tegra_smmu_domain_alloc,
.probe_device = tegra_smmu_probe_device,
.device_group = tegra_smmu_device_group,
- .set_platform_dma_ops = tegra_smmu_set_platform_dma,
.of_xlate = tegra_smmu_of_xlate,
.pgsize_bitmap = SZ_4K,
.default_domain_ops = &(const struct iommu_domain_ops) {
--
2.41.0
[PATCH v6 16/25] iommu: Remove ops->set_platform_dma_ops()
All drivers are now using IDENTITY or PLATFORM domains for what this did,
we can remove it now. It is no longer possible to attach to a NULL domain.
Tested-by: Heiko Stuebner
Tested-by: Niklas Schnelle
Tested-by: Steven Price
Tested-by: Marek Szyprowski
Tested-by: Nicolin Chen
Reviewed-by: Lu Baolu
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/iommu.c | 30 +-
include/linux/iommu.h | 4
2 files changed, 5 insertions(+), 29 deletions(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 7fae866af0db7a..dada2c00d78ca4 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -2264,21 +2264,8 @@ static int __iommu_group_set_domain_internal(struct
iommu_group *group,
if (group->domain == new_domain)
return 0;
- /*
-* New drivers should support default domains, so set_platform_dma()
-* op will never be called. Otherwise the NULL domain represents some
-* platform specific behavior.
-*/
- if (!new_domain) {
- for_each_group_device(group, gdev) {
- const struct iommu_ops *ops = dev_iommu_ops(gdev->dev);
-
- if (!WARN_ON(!ops->set_platform_dma_ops))
- ops->set_platform_dma_ops(gdev->dev);
- }
- group->domain = NULL;
- return 0;
- }
+ if (WARN_ON(!new_domain))
+ return -EINVAL;
/*
* Changing the domain is done by calling attach_dev() on the new
@@ -2314,19 +2301,15 @@ static int __iommu_group_set_domain_internal(struct
iommu_group *group,
*/
last_gdev = gdev;
for_each_group_device(group, gdev) {
- const struct iommu_ops *ops = dev_iommu_ops(gdev->dev);
-
/*
-* If set_platform_dma_ops is not present a NULL domain can
-* happen only for first probe, in which case we leave
-* group->domain as NULL and let release clean everything up.
+* A NULL domain can happen only for first probe, in which case
+* we leave group->domain as NULL and let release clean
+* everything up.
*/
if (group->domain)
WARN_ON(__iommu_device_set_domain(
group, gdev->dev, group->domain,
IOMMU_SET_DOMAIN_MUST_SUCCEED));
- else if (ops->set_platform_dma_ops)
- ops->set_platform_dma_ops(gdev->dev);
if (gdev == last_gdev)
break;
}
@@ -2940,9 +2923,6 @@ static int iommu_setup_default_domain(struct iommu_group
*group,
/*
* There are still some drivers which don't support default domains, so
* we ignore the failure and leave group->default_domain NULL.
-*
-* We assume that the iommu driver starts up the device in
-* 'set_platform_dma_ops' mode if it does not support default domains.
*/
dom = iommu_group_alloc_default_domain(group, req_type);
if (!dom) {
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 87aebba474e093..df54066c262db4 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -237,9 +237,6 @@ struct iommu_iotlb_gather {
* @release_device: Remove device from iommu driver handling
* @probe_finalize: Do final setup work after the device is added to an IOMMU
* group and attached to the groups domain
- * @set_platform_dma_ops: Returning control back to the platform DMA ops. This
op
- *is to support old IOMMU drivers, new drivers should
use
- *default domains, and the common IOMMU DMA ops.
* @device_group: find iommu group for a particular device
* @get_resv_regions: Request list of reserved regions for a device
* @of_xlate: add OF master IDs to iommu grouping
@@ -271,7 +268,6 @@ struct iommu_ops {
struct iommu_device *(*probe_device)(struct device *dev);
void (*release_device)(struct device *dev);
void (*probe_finalize)(struct device *dev);
- void (*set_platform_dma_ops)(struct device *dev);
struct iommu_group *(*device_group)(struct device *dev);
/* Request/Free a list of reserved regions for a device */
--
2.41.0
[PATCH v6 17/25] iommu/qcom_iommu: Add an IOMMU_IDENTITIY_DOMAIN
This brings back the ops->detach_dev() code that commit
1b932ceddd19 ("iommu: Remove detach_dev callbacks") deleted and turns it
into an IDENTITY domain.
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/arm/arm-smmu/qcom_iommu.c | 39 +
1 file changed, 39 insertions(+)
diff --git a/drivers/iommu/arm/arm-smmu/qcom_iommu.c
b/drivers/iommu/arm/arm-smmu/qcom_iommu.c
index a503ed758ec302..9d7b9d8b4386d4 100644
--- a/drivers/iommu/arm/arm-smmu/qcom_iommu.c
+++ b/drivers/iommu/arm/arm-smmu/qcom_iommu.c
@@ -387,6 +387,44 @@ static int qcom_iommu_attach_dev(struct iommu_domain
*domain, struct device *dev
return 0;
}
+static int qcom_iommu_identity_attach(struct iommu_domain *identity_domain,
+ struct device *dev)
+{
+ struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
+ struct qcom_iommu_domain *qcom_domain;
+ struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
+ struct qcom_iommu_dev *qcom_iommu = to_iommu(dev);
+ unsigned int i;
+
+ if (domain == identity_domain || !domain)
+ return 0;
+
+ qcom_domain = to_qcom_iommu_domain(domain);
+ if (WARN_ON(!qcom_domain->iommu))
+ return -EINVAL;
+
+ pm_runtime_get_sync(qcom_iommu->dev);
+ for (i = 0; i < fwspec->num_ids; i++) {
+ struct qcom_iommu_ctx *ctx = to_ctx(qcom_domain,
fwspec->ids[i]);
+
+ /* Disable the context bank: */
+ iommu_writel(ctx, ARM_SMMU_CB_SCTLR, 0);
+
+ ctx->domain = NULL;
+ }
+ pm_runtime_put_sync(qcom_iommu->dev);
+ return 0;
+}
+
+static struct iommu_domain_ops qcom_iommu_identity_ops = {
+ .attach_dev = qcom_iommu_identity_attach,
+};
+
+static struct iommu_domain qcom_iommu_identity_domain = {
+ .type = IOMMU_DOMAIN_IDENTITY,
+ .ops = _iommu_identity_ops,
+};
+
static int qcom_iommu_map(struct iommu_domain *domain, unsigned long iova,
phys_addr_t paddr, size_t pgsize, size_t pgcount,
int prot, gfp_t gfp, size_t *mapped)
@@ -553,6 +591,7 @@ static int qcom_iommu_of_xlate(struct device *dev, struct
of_phandle_args *args)
}
static const struct iommu_ops qcom_iommu_ops = {
+ .identity_domain = _iommu_identity_domain,
.capable= qcom_iommu_capable,
.domain_alloc = qcom_iommu_domain_alloc,
.probe_device = qcom_iommu_probe_device,
--
2.41.0
[PATCH v6 02/25] iommu: Add IOMMU_DOMAIN_PLATFORM
This is used when the iommu driver is taking control of the dma_ops,
currently only on S390 and power spapr. It is designed to preserve the
original ops->detach_dev() semantic that these S390 was built around.
Provide an opaque domain type and a 'default_domain' ops value that allows
the driver to trivially force any single domain as the default domain.
Reviewed-by: Lu Baolu
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/iommu.c | 14 +-
include/linux/iommu.h | 6 ++
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 5e3cdc9f3a9e78..c64365169b678d 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -1705,6 +1705,17 @@ iommu_group_alloc_default_domain(struct iommu_group
*group, int req_type)
lockdep_assert_held(>mutex);
+ /*
+* Allow legacy drivers to specify the domain that will be the default
+* domain. This should always be either an IDENTITY or PLATFORM domain.
+* Do not use in new drivers.
+*/
+ if (bus->iommu_ops->default_domain) {
+ if (req_type)
+ return ERR_PTR(-EINVAL);
+ return bus->iommu_ops->default_domain;
+ }
+
if (req_type)
return __iommu_group_alloc_default_domain(bus, group, req_type);
@@ -1967,7 +1978,8 @@ void iommu_domain_free(struct iommu_domain *domain)
if (domain->type == IOMMU_DOMAIN_SVA)
mmdrop(domain->mm);
iommu_put_dma_cookie(domain);
- domain->ops->free(domain);
+ if (domain->ops->free)
+ domain->ops->free(domain);
}
EXPORT_SYMBOL_GPL(iommu_domain_free);
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index e05c93b6c37fba..87aebba474e093 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -64,6 +64,7 @@ struct iommu_domain_geometry {
#define __IOMMU_DOMAIN_DMA_FQ (1U << 3) /* DMA-API uses flush queue*/
#define __IOMMU_DOMAIN_SVA (1U << 4) /* Shared process address space */
+#define __IOMMU_DOMAIN_PLATFORM(1U << 5)
#define IOMMU_DOMAIN_ALLOC_FLAGS ~__IOMMU_DOMAIN_DMA_FQ
/*
@@ -81,6 +82,8 @@ struct iommu_domain_geometry {
* invalidation.
* IOMMU_DOMAIN_SVA- DMA addresses are shared process addresses
* represented by mm_struct's.
+ * IOMMU_DOMAIN_PLATFORM - Legacy domain for drivers that do their own
+ * dma_api stuff. Do not use in new drivers.
*/
#define IOMMU_DOMAIN_BLOCKED (0U)
#define IOMMU_DOMAIN_IDENTITY (__IOMMU_DOMAIN_PT)
@@ -91,6 +94,7 @@ struct iommu_domain_geometry {
__IOMMU_DOMAIN_DMA_API | \
__IOMMU_DOMAIN_DMA_FQ)
#define IOMMU_DOMAIN_SVA (__IOMMU_DOMAIN_SVA)
+#define IOMMU_DOMAIN_PLATFORM (__IOMMU_DOMAIN_PLATFORM)
struct iommu_domain {
unsigned type;
@@ -256,6 +260,7 @@ struct iommu_iotlb_gather {
* @owner: Driver module providing these ops
* @identity_domain: An always available, always attachable identity
* translation.
+ * @default_domain: If not NULL this will always be set as the default domain.
*/
struct iommu_ops {
bool (*capable)(struct device *dev, enum iommu_cap);
@@ -290,6 +295,7 @@ struct iommu_ops {
unsigned long pgsize_bitmap;
struct module *owner;
struct iommu_domain *identity_domain;
+ struct iommu_domain *default_domain;
};
/**
--
2.41.0
[PATCH v6 07/25] iommu/mtk_iommu_v1: Implement an IDENTITY domain
What mtk does during mtk_iommu_v1_set_platform_dma() is actually putting
the iommu into identity mode. Make this available as a proper IDENTITY
domain.
The mtk_iommu_v1_def_domain_type() from
commit 8bbe13f52cb7 ("iommu/mediatek-v1: Add def_domain_type") explains
this was needed to allow probe_finalize() to be called, but now the
IDENTITY domain will do the same job so change the returned
def_domain_type.
mkt_v1 is the only driver that returns IOMMU_DOMAIN_UNMANAGED from
def_domain_type(). This allows the next patch to enforce an IDENTITY
domain policy for this driver.
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/mtk_iommu_v1.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index 8a0a5e5d049f4a..cc3e7d53d33ad9 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -319,11 +319,27 @@ static int mtk_iommu_v1_attach_device(struct iommu_domain
*domain, struct device
return 0;
}
-static void mtk_iommu_v1_set_platform_dma(struct device *dev)
+static int mtk_iommu_v1_identity_attach(struct iommu_domain *identity_domain,
+ struct device *dev)
{
struct mtk_iommu_v1_data *data = dev_iommu_priv_get(dev);
mtk_iommu_v1_config(data, dev, false);
+ return 0;
+}
+
+static struct iommu_domain_ops mtk_iommu_v1_identity_ops = {
+ .attach_dev = mtk_iommu_v1_identity_attach,
+};
+
+static struct iommu_domain mtk_iommu_v1_identity_domain = {
+ .type = IOMMU_DOMAIN_IDENTITY,
+ .ops = _iommu_v1_identity_ops,
+};
+
+static void mtk_iommu_v1_set_platform_dma(struct device *dev)
+{
+ mtk_iommu_v1_identity_attach(_iommu_v1_identity_domain, dev);
}
static int mtk_iommu_v1_map(struct iommu_domain *domain, unsigned long iova,
@@ -443,7 +459,7 @@ static int mtk_iommu_v1_create_mapping(struct device *dev,
struct of_phandle_arg
static int mtk_iommu_v1_def_domain_type(struct device *dev)
{
- return IOMMU_DOMAIN_UNMANAGED;
+ return IOMMU_DOMAIN_IDENTITY;
}
static struct iommu_device *mtk_iommu_v1_probe_device(struct device *dev)
@@ -578,6 +594,7 @@ static int mtk_iommu_v1_hw_init(const struct
mtk_iommu_v1_data *data)
}
static const struct iommu_ops mtk_iommu_v1_ops = {
+ .identity_domain = _iommu_v1_identity_domain,
.domain_alloc = mtk_iommu_v1_domain_alloc,
.probe_device = mtk_iommu_v1_probe_device,
.probe_finalize = mtk_iommu_v1_probe_finalize,
--
2.41.0
[PATCH v6 05/25] iommu/fsl_pamu: Implement a PLATFORM domain
This driver is nonsensical. To not block migrating the core API away from
NULL default_domains give it a hacky of a PLATFORM domain that keeps it
working exactly as it always did.
Leave some comments around to warn away any future people looking at this.
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/fsl_pamu_domain.c | 41 ++---
1 file changed, 38 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/fsl_pamu_domain.c b/drivers/iommu/fsl_pamu_domain.c
index 4ac0e247ec2b51..e9d2bff4659b7c 100644
--- a/drivers/iommu/fsl_pamu_domain.c
+++ b/drivers/iommu/fsl_pamu_domain.c
@@ -196,6 +196,13 @@ static struct iommu_domain *fsl_pamu_domain_alloc(unsigned
type)
{
struct fsl_dma_domain *dma_domain;
+ /*
+* FIXME: This isn't creating an unmanaged domain since the
+* default_domain_ops do not have any map/unmap function it doesn't meet
+* the requirements for __IOMMU_DOMAIN_PAGING. The only purpose seems to
+* allow drivers/soc/fsl/qbman/qman_portal.c to do
+* fsl_pamu_configure_l1_stash()
+*/
if (type != IOMMU_DOMAIN_UNMANAGED)
return NULL;
@@ -283,15 +290,33 @@ static int fsl_pamu_attach_device(struct iommu_domain
*domain,
return ret;
}
-static void fsl_pamu_set_platform_dma(struct device *dev)
+/*
+ * FIXME: fsl/pamu is completely broken in terms of how it works with the iommu
+ * API. Immediately after probe the HW is left in an IDENTITY translation and
+ * the driver provides a non-working UNMANAGED domain that it can switch over
+ * to. However it cannot switch back to an IDENTITY translation, instead it
+ * switches to what looks like BLOCKING.
+ */
+static int fsl_pamu_platform_attach(struct iommu_domain *platform_domain,
+ struct device *dev)
{
struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
- struct fsl_dma_domain *dma_domain = to_fsl_dma_domain(domain);
+ struct fsl_dma_domain *dma_domain;
const u32 *prop;
int len;
struct pci_dev *pdev = NULL;
struct pci_controller *pci_ctl;
+ /*
+* Hack to keep things working as they always have, only leaving an
+* UNMANAGED domain makes it BLOCKING.
+*/
+ if (domain == platform_domain || !domain ||
+ domain->type != IOMMU_DOMAIN_UNMANAGED)
+ return 0;
+
+ dma_domain = to_fsl_dma_domain(domain);
+
/*
* Use LIODN of the PCI controller while detaching a
* PCI device.
@@ -312,8 +337,18 @@ static void fsl_pamu_set_platform_dma(struct device *dev)
detach_device(dev, dma_domain);
else
pr_debug("missing fsl,liodn property at %pOF\n", dev->of_node);
+ return 0;
}
+static struct iommu_domain_ops fsl_pamu_platform_ops = {
+ .attach_dev = fsl_pamu_platform_attach,
+};
+
+static struct iommu_domain fsl_pamu_platform_domain = {
+ .type = IOMMU_DOMAIN_PLATFORM,
+ .ops = _pamu_platform_ops,
+};
+
/* Set the domain stash attribute */
int fsl_pamu_configure_l1_stash(struct iommu_domain *domain, u32 cpu)
{
@@ -395,11 +430,11 @@ static struct iommu_device *fsl_pamu_probe_device(struct
device *dev)
}
static const struct iommu_ops fsl_pamu_ops = {
+ .default_domain = _pamu_platform_domain,
.capable= fsl_pamu_capable,
.domain_alloc = fsl_pamu_domain_alloc,
.probe_device = fsl_pamu_probe_device,
.device_group = fsl_pamu_device_group,
- .set_platform_dma_ops = fsl_pamu_set_platform_dma,
.default_domain_ops = &(const struct iommu_domain_ops) {
.attach_dev = fsl_pamu_attach_device,
.iova_to_phys = fsl_pamu_iova_to_phys,
--
2.41.0
[PATCH v6 25/25] iommu: Convert remaining simple drivers to domain_alloc_paging()
These drivers don't support IOMMU_DOMAIN_DMA, so this commit effectively
allows them to support that mode.
The prior work to require default_domains makes this safe because every
one of these drivers is either compilation incompatible with dma-iommu.c,
or already establishing a default_domain. In both cases alloc_domain()
will never be called with IOMMU_DOMAIN_DMA for these drivers so it is safe
to drop the test.
Removing these tests clarifies that the domain allocation path is only
about the functionality of a paging domain and has nothing to do with
policy of how the paging domain is used for UNMANAGED/DMA/DMA_FQ.
Tested-by: Niklas Schnelle
Tested-by: Steven Price
Tested-by: Marek Szyprowski
Tested-by: Nicolin Chen
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/msm_iommu.c| 7 ++-
drivers/iommu/mtk_iommu_v1.c | 7 ++-
drivers/iommu/omap-iommu.c | 7 ++-
drivers/iommu/s390-iommu.c | 7 ++-
4 files changed, 8 insertions(+), 20 deletions(-)
diff --git a/drivers/iommu/msm_iommu.c b/drivers/iommu/msm_iommu.c
index 26ed81cfeee897..a163cee0b7242d 100644
--- a/drivers/iommu/msm_iommu.c
+++ b/drivers/iommu/msm_iommu.c
@@ -302,13 +302,10 @@ static void __program_context(void __iomem *base, int ctx,
SET_M(base, ctx, 1);
}
-static struct iommu_domain *msm_iommu_domain_alloc(unsigned type)
+static struct iommu_domain *msm_iommu_domain_alloc_paging(struct device *dev)
{
struct msm_priv *priv;
- if (type != IOMMU_DOMAIN_UNMANAGED)
- return NULL;
-
priv = kzalloc(sizeof(*priv), GFP_KERNEL);
if (!priv)
goto fail_nomem;
@@ -691,7 +688,7 @@ irqreturn_t msm_iommu_fault_handler(int irq, void *dev_id)
static struct iommu_ops msm_iommu_ops = {
.identity_domain = _iommu_identity_domain,
- .domain_alloc = msm_iommu_domain_alloc,
+ .domain_alloc_paging = msm_iommu_domain_alloc_paging,
.probe_device = msm_iommu_probe_device,
.device_group = generic_device_group,
.pgsize_bitmap = MSM_IOMMU_PGSIZES,
diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index 7c0c1d50df5f75..67e044c1a7d93b 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -270,13 +270,10 @@ static int mtk_iommu_v1_domain_finalise(struct
mtk_iommu_v1_data *data)
return 0;
}
-static struct iommu_domain *mtk_iommu_v1_domain_alloc(unsigned type)
+static struct iommu_domain *mtk_iommu_v1_domain_alloc_paging(struct device
*dev)
{
struct mtk_iommu_v1_domain *dom;
- if (type != IOMMU_DOMAIN_UNMANAGED)
- return NULL;
-
dom = kzalloc(sizeof(*dom), GFP_KERNEL);
if (!dom)
return NULL;
@@ -585,7 +582,7 @@ static int mtk_iommu_v1_hw_init(const struct
mtk_iommu_v1_data *data)
static const struct iommu_ops mtk_iommu_v1_ops = {
.identity_domain = _iommu_v1_identity_domain,
- .domain_alloc = mtk_iommu_v1_domain_alloc,
+ .domain_alloc_paging = mtk_iommu_v1_domain_alloc_paging,
.probe_device = mtk_iommu_v1_probe_device,
.probe_finalize = mtk_iommu_v1_probe_finalize,
.release_device = mtk_iommu_v1_release_device,
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 34340ef15241bc..fcf99bd195b32e 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -1580,13 +1580,10 @@ static struct iommu_domain omap_iommu_identity_domain =
{
.ops = _iommu_identity_ops,
};
-static struct iommu_domain *omap_iommu_domain_alloc(unsigned type)
+static struct iommu_domain *omap_iommu_domain_alloc_paging(struct device *dev)
{
struct omap_iommu_domain *omap_domain;
- if (type != IOMMU_DOMAIN_UNMANAGED)
- return NULL;
-
omap_domain = kzalloc(sizeof(*omap_domain), GFP_KERNEL);
if (!omap_domain)
return NULL;
@@ -1748,7 +1745,7 @@ static struct iommu_group *omap_iommu_device_group(struct
device *dev)
static const struct iommu_ops omap_iommu_ops = {
.identity_domain = _iommu_identity_domain,
- .domain_alloc = omap_iommu_domain_alloc,
+ .domain_alloc_paging = omap_iommu_domain_alloc_paging,
.probe_device = omap_iommu_probe_device,
.release_device = omap_iommu_release_device,
.device_group = omap_iommu_device_group,
diff --git a/drivers/iommu/s390-iommu.c b/drivers/iommu/s390-iommu.c
index f0c867c57a5b9b..5695ad71d60e24 100644
--- a/drivers/iommu/s390-iommu.c
+++ b/drivers/iommu/s390-iommu.c
@@ -39,13 +39,10 @@ static bool s390_iommu_capable(struct device *dev, enum
iommu_cap cap)
}
}
-static struct iommu_domain *s390_domain_alloc(unsigned domain_type)
+static struct iommu_domain *s390_domain_alloc_paging(struct device *dev)
{
struct s390_domain *s390_domain;
- if (domain_type != IOMMU_DOMAIN_UNMANAGED)
- return NULL;
-
s390_domain = kzalloc(sizeof(*s390_domain),
[PATCH v6 24/25] iommu: Convert simple drivers with DOMAIN_DMA to domain_alloc_paging()
These drivers are all trivially converted since the function is only
called if the domain type is going to be
IOMMU_DOMAIN_UNMANAGED/DMA.
Tested-by: Heiko Stuebner
Tested-by: Steven Price
Tested-by: Marek Szyprowski
Tested-by: Nicolin Chen
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/arm/arm-smmu/qcom_iommu.c | 6 ++
drivers/iommu/exynos-iommu.c| 7 ++-
drivers/iommu/ipmmu-vmsa.c | 7 ++-
drivers/iommu/mtk_iommu.c | 7 ++-
drivers/iommu/rockchip-iommu.c | 7 ++-
drivers/iommu/sprd-iommu.c | 7 ++-
drivers/iommu/sun50i-iommu.c| 9 +++--
drivers/iommu/tegra-smmu.c | 7 ++-
8 files changed, 17 insertions(+), 40 deletions(-)
diff --git a/drivers/iommu/arm/arm-smmu/qcom_iommu.c
b/drivers/iommu/arm/arm-smmu/qcom_iommu.c
index 9d7b9d8b4386d4..a2140fdc65ed58 100644
--- a/drivers/iommu/arm/arm-smmu/qcom_iommu.c
+++ b/drivers/iommu/arm/arm-smmu/qcom_iommu.c
@@ -319,12 +319,10 @@ static int qcom_iommu_init_domain(struct iommu_domain
*domain,
return ret;
}
-static struct iommu_domain *qcom_iommu_domain_alloc(unsigned type)
+static struct iommu_domain *qcom_iommu_domain_alloc_paging(struct device *dev)
{
struct qcom_iommu_domain *qcom_domain;
- if (type != IOMMU_DOMAIN_UNMANAGED && type != IOMMU_DOMAIN_DMA)
- return NULL;
/*
* Allocate the domain and initialise some of its data structures.
* We can't really do anything meaningful until we've added a
@@ -593,7 +591,7 @@ static int qcom_iommu_of_xlate(struct device *dev, struct
of_phandle_args *args)
static const struct iommu_ops qcom_iommu_ops = {
.identity_domain = _iommu_identity_domain,
.capable= qcom_iommu_capable,
- .domain_alloc = qcom_iommu_domain_alloc,
+ .domain_alloc_paging = qcom_iommu_domain_alloc_paging,
.probe_device = qcom_iommu_probe_device,
.device_group = generic_device_group,
.of_xlate = qcom_iommu_of_xlate,
diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 5e12b85dfe8705..d6dead2ed10c11 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -887,7 +887,7 @@ static inline void exynos_iommu_set_pte(sysmmu_pte_t *ent,
sysmmu_pte_t val)
DMA_TO_DEVICE);
}
-static struct iommu_domain *exynos_iommu_domain_alloc(unsigned type)
+static struct iommu_domain *exynos_iommu_domain_alloc_paging(struct device
*dev)
{
struct exynos_iommu_domain *domain;
dma_addr_t handle;
@@ -896,9 +896,6 @@ static struct iommu_domain
*exynos_iommu_domain_alloc(unsigned type)
/* Check if correct PTE offsets are initialized */
BUG_ON(PG_ENT_SHIFT < 0 || !dma_dev);
- if (type != IOMMU_DOMAIN_DMA && type != IOMMU_DOMAIN_UNMANAGED)
- return NULL;
-
domain = kzalloc(sizeof(*domain), GFP_KERNEL);
if (!domain)
return NULL;
@@ -1472,7 +1469,7 @@ static int exynos_iommu_of_xlate(struct device *dev,
static const struct iommu_ops exynos_iommu_ops = {
.identity_domain = _identity_domain,
- .domain_alloc = exynos_iommu_domain_alloc,
+ .domain_alloc_paging = exynos_iommu_domain_alloc_paging,
.device_group = generic_device_group,
.probe_device = exynos_iommu_probe_device,
.release_device = exynos_iommu_release_device,
diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index de958e411a92e0..27d36347e0fced 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -566,13 +566,10 @@ static irqreturn_t ipmmu_irq(int irq, void *dev)
* IOMMU Operations
*/
-static struct iommu_domain *ipmmu_domain_alloc(unsigned type)
+static struct iommu_domain *ipmmu_domain_alloc_paging(struct device *dev)
{
struct ipmmu_vmsa_domain *domain;
- if (type != IOMMU_DOMAIN_UNMANAGED && type != IOMMU_DOMAIN_DMA)
- return NULL;
-
domain = kzalloc(sizeof(*domain), GFP_KERNEL);
if (!domain)
return NULL;
@@ -891,7 +888,7 @@ static struct iommu_group *ipmmu_find_group(struct device
*dev)
static const struct iommu_ops ipmmu_ops = {
.identity_domain = _iommu_identity_domain,
- .domain_alloc = ipmmu_domain_alloc,
+ .domain_alloc_paging = ipmmu_domain_alloc_paging,
.probe_device = ipmmu_probe_device,
.release_device = ipmmu_release_device,
.probe_finalize = ipmmu_probe_finalize,
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index fdb7f5162b1d64..3590d3399add32 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -667,13 +667,10 @@ static int mtk_iommu_domain_finalise(struct
mtk_iommu_domain *dom,
return 0;
}
-static struct iommu_domain *mtk_iommu_domain_alloc(unsigned type)
+static struct iommu_domain
[PATCH v6 06/25] iommu/tegra-gart: Remove tegra-gart
Thierry says this is not used anymore, and doesn't think it makes sense as
an iommu driver. The HW it supports is about 10 years old now and newer HW
uses different IOMMU drivers.
As this is the only driver with a GART approach, and it doesn't really
meet the driver expectations from the IOMMU core, let's just remove it
so we don't have to think about how to make it fit in.
It has a number of identified problems:
- The assignment of iommu_groups doesn't match the HW behavior
- It claims to have an UNMANAGED domain but it is really an IDENTITY
domain with a translation aperture. This is inconsistent with the core
expectation for security sensitive operations
- It doesn't implement a SW page table under struct iommu_domain so
* It can't accept a map until the domain is attached
* It forgets about all maps after the domain is detached
* It doesn't clear the HW of maps once the domain is detached
(made worse by having the wrong groups)
Cc: Thierry Reding
Cc: Dmitry Osipenko
Acked-by: Thierry Reding
Signed-off-by: Jason Gunthorpe
---
arch/arm/configs/multi_v7_defconfig | 1 -
arch/arm/configs/tegra_defconfig| 1 -
drivers/iommu/Kconfig | 11 -
drivers/iommu/Makefile | 1 -
drivers/iommu/tegra-gart.c | 371
drivers/memory/tegra/mc.c | 34 ---
drivers/memory/tegra/tegra20.c | 28 ---
include/soc/tegra/mc.h | 26 --
8 files changed, 473 deletions(-)
delete mode 100644 drivers/iommu/tegra-gart.c
diff --git a/arch/arm/configs/multi_v7_defconfig
b/arch/arm/configs/multi_v7_defconfig
index f0800f806b5f62..c7e63e54a400e9 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -1063,7 +1063,6 @@ CONFIG_BCM2835_MBOX=y
CONFIG_QCOM_APCS_IPC=y
CONFIG_QCOM_IPCC=y
CONFIG_ROCKCHIP_IOMMU=y
-CONFIG_TEGRA_IOMMU_GART=y
CONFIG_TEGRA_IOMMU_SMMU=y
CONFIG_EXYNOS_IOMMU=y
CONFIG_QCOM_IOMMU=y
diff --git a/arch/arm/configs/tegra_defconfig b/arch/arm/configs/tegra_defconfig
index 3c6af935e9328a..79141dddb037a9 100644
--- a/arch/arm/configs/tegra_defconfig
+++ b/arch/arm/configs/tegra_defconfig
@@ -292,7 +292,6 @@ CONFIG_CHROME_PLATFORMS=y
CONFIG_CROS_EC=y
CONFIG_CROS_EC_I2C=m
CONFIG_CROS_EC_SPI=m
-CONFIG_TEGRA_IOMMU_GART=y
CONFIG_TEGRA_IOMMU_SMMU=y
CONFIG_ARCH_TEGRA_2x_SOC=y
CONFIG_ARCH_TEGRA_3x_SOC=y
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 2b12b583ef4b1e..cd6727898b1175 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -236,17 +236,6 @@ config SUN50I_IOMMU
help
Support for the IOMMU introduced in the Allwinner H6 SoCs.
-config TEGRA_IOMMU_GART
- bool "Tegra GART IOMMU Support"
- depends on ARCH_TEGRA_2x_SOC
- depends on TEGRA_MC
- select IOMMU_API
- help
- Enables support for remapping discontiguous physical memory
- shared with the operating system into contiguous I/O virtual
- space through the GART (Graphics Address Relocation Table)
- hardware included on Tegra SoCs.
-
config TEGRA_IOMMU_SMMU
bool "NVIDIA Tegra SMMU Support"
depends on ARCH_TEGRA
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index 769e43d780ce89..95ad9dbfbda022 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -20,7 +20,6 @@ obj-$(CONFIG_OMAP_IOMMU) += omap-iommu.o
obj-$(CONFIG_OMAP_IOMMU_DEBUG) += omap-iommu-debug.o
obj-$(CONFIG_ROCKCHIP_IOMMU) += rockchip-iommu.o
obj-$(CONFIG_SUN50I_IOMMU) += sun50i-iommu.o
-obj-$(CONFIG_TEGRA_IOMMU_GART) += tegra-gart.o
obj-$(CONFIG_TEGRA_IOMMU_SMMU) += tegra-smmu.o
obj-$(CONFIG_EXYNOS_IOMMU) += exynos-iommu.o
obj-$(CONFIG_FSL_PAMU) += fsl_pamu.o fsl_pamu_domain.o
diff --git a/drivers/iommu/tegra-gart.c b/drivers/iommu/tegra-gart.c
deleted file mode 100644
index a482ff838b5331..00
--- a/drivers/iommu/tegra-gart.c
+++ /dev/null
@@ -1,371 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * IOMMU API for Graphics Address Relocation Table on Tegra20
- *
- * Copyright (c) 2010-2012, NVIDIA CORPORATION. All rights reserved.
- *
- * Author: Hiroshi DOYU
- */
-
-#define dev_fmt(fmt) "gart: " fmt
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include
-
-#define GART_REG_BASE 0x24
-#define GART_CONFIG(0x24 - GART_REG_BASE)
-#define GART_ENTRY_ADDR(0x28 - GART_REG_BASE)
-#define GART_ENTRY_DATA(0x2c - GART_REG_BASE)
-
-#define GART_ENTRY_PHYS_ADDR_VALID BIT(31)
-
-#define GART_PAGE_SHIFT12
-#define GART_PAGE_SIZE (1 << GART_PAGE_SHIFT)
-#define GART_PAGE_MASK GENMASK(30, GART_PAGE_SHIFT)
-
-/* bitmap of the page sizes currently supported */
-#define GART_IOMMU_PGSIZES (GART_PAGE_SIZE)
-
-struct gart_device {
- void __iomem*regs;
- u32 *savedata;
- unsigned long
[PATCH v6 19/25] iommu/mtk_iommu: Add an IOMMU_IDENTITIY_DOMAIN
This brings back the ops->detach_dev() code that commit
1b932ceddd19 ("iommu: Remove detach_dev callbacks") deleted and turns it
into an IDENTITY domain.
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/mtk_iommu.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index e93906d6e112e8..fdb7f5162b1d64 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -753,6 +753,28 @@ static int mtk_iommu_attach_device(struct iommu_domain
*domain,
return ret;
}
+static int mtk_iommu_identity_attach(struct iommu_domain *identity_domain,
+struct device *dev)
+{
+ struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
+ struct mtk_iommu_data *data = dev_iommu_priv_get(dev);
+
+ if (domain == identity_domain || !domain)
+ return 0;
+
+ mtk_iommu_config(data, dev, false, 0);
+ return 0;
+}
+
+static struct iommu_domain_ops mtk_iommu_identity_ops = {
+ .attach_dev = mtk_iommu_identity_attach,
+};
+
+static struct iommu_domain mtk_iommu_identity_domain = {
+ .type = IOMMU_DOMAIN_IDENTITY,
+ .ops = _iommu_identity_ops,
+};
+
static int mtk_iommu_map(struct iommu_domain *domain, unsigned long iova,
phys_addr_t paddr, size_t pgsize, size_t pgcount,
int prot, gfp_t gfp, size_t *mapped)
@@ -972,6 +994,7 @@ static void mtk_iommu_get_resv_regions(struct device *dev,
}
static const struct iommu_ops mtk_iommu_ops = {
+ .identity_domain = _iommu_identity_domain,
.domain_alloc = mtk_iommu_domain_alloc,
.probe_device = mtk_iommu_probe_device,
.release_device = mtk_iommu_release_device,
--
2.41.0
[PATCH v6 04/25] iommu: Add IOMMU_DOMAIN_PLATFORM for S390
The PLATFORM domain will be set as the default domain and attached as
normal during probe. The driver will ignore the initial attach from a NULL
domain to the PLATFORM domain.
After this, the PLATFORM domain's attach_dev will be called whenever we
detach from an UNMANAGED domain (eg for VFIO). This is the same time the
original design would have called op->detach_dev().
This is temporary until the S390 dma-iommu.c conversion is merged.
Tested-by: Heiko Stuebner
Tested-by: Niklas Schnelle
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/s390-iommu.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/s390-iommu.c b/drivers/iommu/s390-iommu.c
index fbf59a8db29b11..f0c867c57a5b9b 100644
--- a/drivers/iommu/s390-iommu.c
+++ b/drivers/iommu/s390-iommu.c
@@ -142,14 +142,31 @@ static int s390_iommu_attach_device(struct iommu_domain
*domain,
return 0;
}
-static void s390_iommu_set_platform_dma(struct device *dev)
+/*
+ * Switch control over the IOMMU to S390's internal dma_api ops
+ */
+static int s390_iommu_platform_attach(struct iommu_domain *platform_domain,
+ struct device *dev)
{
struct zpci_dev *zdev = to_zpci_dev(dev);
+ if (!zdev->s390_domain)
+ return 0;
+
__s390_iommu_detach_device(zdev);
zpci_dma_init_device(zdev);
+ return 0;
}
+static struct iommu_domain_ops s390_iommu_platform_ops = {
+ .attach_dev = s390_iommu_platform_attach,
+};
+
+static struct iommu_domain s390_iommu_platform_domain = {
+ .type = IOMMU_DOMAIN_PLATFORM,
+ .ops = _iommu_platform_ops,
+};
+
static void s390_iommu_get_resv_regions(struct device *dev,
struct list_head *list)
{
@@ -428,12 +445,12 @@ void zpci_destroy_iommu(struct zpci_dev *zdev)
}
static const struct iommu_ops s390_iommu_ops = {
+ .default_domain = _iommu_platform_domain,
.capable = s390_iommu_capable,
.domain_alloc = s390_domain_alloc,
.probe_device = s390_iommu_probe_device,
.release_device = s390_iommu_release_device,
.device_group = generic_device_group,
- .set_platform_dma_ops = s390_iommu_set_platform_dma,
.pgsize_bitmap = SZ_4K,
.get_resv_regions = s390_iommu_get_resv_regions,
.default_domain_ops = &(const struct iommu_domain_ops) {
--
2.41.0
Re: [PATCH v5 15/25] iommufd/selftest: Make the mock iommu driver into a real driver
On Mon, Jul 24, 2023 at 02:22:05PM -0300, Jason Gunthorpe wrote:
> -void __init iommufd_test_init(void)
> +int __init iommufd_test_init(void)
> {
> + struct platform_device_info pdevinfo = {
> + .name = "iommufd_selftest_iommu",
> + };
> + int rc;
> +
> dbgfs_root =
> fault_create_debugfs_attr("fail_iommufd", NULL, _iommufd);
> - WARN_ON(bus_register(_mock_bus_type));
> +
> + selftest_iommu_dev = platform_device_register_full();
> + if (IS_ERR(selftest_iommu_dev)) {
> + rc = PTR_ERR(selftest_iommu_dev);
> + goto err_dbgfs;
> + }
> +
> + rc = bus_register(_mock_bus_type.bus);
> + if (rc)
> + goto err_platform;
> +
> + mock_iommu_device.dev = _iommu_dev->dev;
> + rc = iommu_device_register_bus(_iommu_device, _ops,
> + _mock_bus_type.bus,
> + _mock_bus_type.nb);
> + if (rc)
> + goto err_bus;
> + return 0;
> +
> +err_bus:
> + bus_unregister(_mock_bus_type.bus);
> +err_platform:
> + platform_device_del(selftest_iommu_dev);
> +err_dbgfs:
> + debugfs_remove_recursive(dbgfs_root);
> + return rc;
> }
>
> void iommufd_test_exit(void)
> {
> + iommu_device_unregister_bus(_iommu_device,
> + _mock_bus_type.bus,
> + _mock_bus_type.nb);
> + bus_unregister(_mock_bus_type.bus);
> + platform_device_del(selftest_iommu_dev);
> debugfs_remove_recursive(dbgfs_root);
> - bus_unregister(_mock_bus_type);
> }
There is a mistake here that started to become visible after one of
the rebases, it needs to call iommu_device_sysfs_add() prior to
iommu_device_register_bus() otherwise the iommu core stuff does not
fully initialize and weird stuff starts happening.
So, it needs this:
diff --git a/drivers/iommu/iommufd/selftest.c b/drivers/iommu/iommufd/selftest.c
index 5433c9c545526d..d2b59a1157441c 100644
--- a/drivers/iommu/iommufd/selftest.c
+++ b/drivers/iommu/iommufd/selftest.c
@@ -987,14 +987,21 @@ int __init iommufd_test_init(void)
if (rc)
goto err_platform;
- mock_iommu_device.dev = _iommu_dev->dev;
+ rc = iommu_device_sysfs_add(_iommu_device,
+ _iommu_dev->dev, NULL, "%s",
+ dev_name(_iommu_dev->dev));
+ if (rc)
+ goto err_bus;
+
rc = iommu_device_register_bus(_iommu_device, _ops,
_mock_bus_type.bus,
_mock_bus_type.nb);
if (rc)
- goto err_bus;
+ goto err_sysfs;
return 0;
+err_sysfs:
+ iommu_device_sysfs_remove(_iommu_device);
err_bus:
bus_unregister(_mock_bus_type.bus);
err_platform:
@@ -1006,6 +1013,7 @@ int __init iommufd_test_init(void)
void iommufd_test_exit(void)
{
+ iommu_device_sysfs_remove(_iommu_device);
iommu_device_unregister_bus(_iommu_device,
_mock_bus_type.bus,
_mock_bus_type.nb);
[PATCH] powerpc: pmac32: enable serial options by default in defconfig
Serial is a critical feature for logging and debuging, and the other architectures enable serial by default. Let's enable CONFIG_SERIAL_PMACZILOG and CONFIG_SERIAL_PMACZILOG_CONSOLE by default. Signed-off-by: Yuan Tan --- arch/powerpc/configs/pmac32_defconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/configs/pmac32_defconfig b/arch/powerpc/configs/pmac32_defconfig index 019163c2571e..3aae79afb9d9 100644 --- a/arch/powerpc/configs/pmac32_defconfig +++ b/arch/powerpc/configs/pmac32_defconfig @@ -176,8 +176,9 @@ CONFIG_MOUSE_APPLETOUCH=y # CONFIG_SERIO_I8042 is not set # CONFIG_SERIO_SERPORT is not set CONFIG_SERIAL_8250=m -CONFIG_SERIAL_PMACZILOG=m +CONFIG_SERIAL_PMACZILOG=y CONFIG_SERIAL_PMACZILOG_TTYS=y +CONFIG_SERIAL_PMACZILOG_CONSOLE=y CONFIG_NVRAM=y CONFIG_I2C_CHARDEV=m CONFIG_APM_POWER=y -- 2.34.1
Re: [PATCH 5/6] integrity: PowerVM machine keyring enablement.
On Fri, 2023-07-14 at 11:34 -0400, Nayna Jain wrote: > Update Kconfig to enable machine keyring and limit to CA certificates > on PowerVM. > > Signed-off-by: Nayna Jain Reviewed-and-tested-by: Mimi Zohar
Re: [PATCH 4/6] integrity: check whether imputed trust is enabled
On Fri, 2023-07-14 at 11:34 -0400, Nayna Jain wrote: > trust_moklist() is specific to UEFI enabled systems. Other platforms > rely only on the Kconfig. > > Define a generic wrapper named imputed_trust_enabled(). > > Signed-off-by: Nayna Jain Reviewed-off-by: Mimi Zohar
Re: [PATCH 2/6] integrity: ignore keys failing CA restrictions on non-UEFI platform
On Fri, 2023-07-14 at 11:34 -0400, Nayna Jain wrote: > On non-UEFI platforms, handle restrict_link_by_ca failures differently. > > Certificates which do not satisfy CA restrictions on non-UEFI platforms > are ignored. > > Signed-off-by: Nayna Jain Reviewed-and-tested-by: Mimi Zohar
Re: [PATCH 3/6] integrity: remove global variable from machine_keyring.c
On Fri, 2023-07-14 at 11:34 -0400, Nayna Jain wrote: > trust_mok variable is accessed within a single function locally. > > Change trust_mok from global to local static variable. > > Signed-off-by: Nayna Jain Reviewed-and-tested-by: Mimi Zohar
Re: [PATCH 1/6] integrity: PowerVM support for loading CA keys on machine keyring
On Fri, 2023-07-14 at 11:34 -0400, Nayna Jain wrote: > Keys that derive their trust from an entity such as a security officer, > administrator, system owner, or machine owner are said to have "imputed > trust". CA keys with imputed trust can be loaded onto the machine keyring. > The mechanism for loading these keys onto the machine keyring is platform > dependent. > > Load keys stored in the variable trustedcadb onto the .machine keyring > on PowerVM platform. > > Signed-off-by: Nayna Jain Reviewed-and-tested-by: Mimi Zohar
Re: [PATCH 0/6] Enable loading local and third party keys on PowerVM guest
On Fri, 2023-07-14 at 11:34 -0400, Nayna Jain wrote: > On a secure boot enabled PowerVM guest, local and third party code signing > keys are needed to verify signed applications, configuration files, and > kernel modules. > > Loading these keys onto either the .secondary_trusted_keys or .ima > keyrings requires the certificates be signed by keys on the > .builtin_trusted_keys, .machine or .secondary_trusted_keys keyrings. > > Keys on the .builtin_trusted_keys keyring are trusted because of the chain > of trust from secure boot up to and including the linux kernel. Keys on > the .machine keyring that derive their trust from an entity such as a > security officer, administrator, system owner, or machine owner are said > to have "imputed trust." The type of certificates and the mechanism for > loading them onto the .machine keyring is platform dependent. > > Userspace may load certificates onto the .secondary_trusted_keys or .ima > keyrings. However, keys may also need to be loaded by the kernel if they > are needed for verification in early boot time. On PowerVM guest, third > party code signing keys are loaded from the moduledb variable in the > Platform KeyStore(PKS) onto the .secondary_trusted_keys. Thanks, Nayna. I've reviewed and done some initially testing up to 5/6. Mimi
Re: [PATCH v3 3/6] KVM: PPC: selftests: add support for powerpc
On Thu, Jun 08, 2023, Nicholas Piggin wrote:
> diff --git a/tools/testing/selftests/kvm/lib/powerpc/ucall.c
> b/tools/testing/selftests/kvm/lib/powerpc/ucall.c
> new file mode 100644
> index ..ce0ddde45fef
> --- /dev/null
> +++ b/tools/testing/selftests/kvm/lib/powerpc/ucall.c
> @@ -0,0 +1,30 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * ucall support. A ucall is a "hypercall to host userspace".
> + */
> +#include "kvm_util.h"
> +#include "hcall.h"
> +
> +void ucall_arch_init(struct kvm_vm *vm, vm_paddr_t mmio_gpa)
> +{
> +}
> +
> +void ucall_arch_do_ucall(vm_vaddr_t uc)
> +{
> + hcall2(H_UCALL, UCALL_R4_UCALL, (uintptr_t)(uc));
> +}
FYI, the ucall stuff will silently conflict with treewide (where KVM selftests
is
the treechanges that I've queued[*]. It probably makes sense for the initial
PPC
support to go through the KVM tree anyways, so I'd be more than happy to grab
this
series via kvm-x86/selftests if you're willing to do the code changes (should be
minor, knock wood). Alternatively, the immutable tag I'm planning on creating
could be merged into the PPC tree, but that seems like overkill.
Either way, please Cc me on the next version (assuming there is a next version),
if only so that I can give you an early heads up if/when the next treewide
change
alongs ;-)
[*]
https://lore.kernel.org/all/169101267140.1755771.17089576255751273053.b4...@google.com
Re: [RFC PATCH v11 08/29] KVM: Introduce per-page memory attributes
On Tue, Jul 18, 2023 at 04:44:51PM -0700,
Sean Christopherson wrote:
> From: Chao Peng
>
> In confidential computing usages, whether a page is private or shared is
> necessary information for KVM to perform operations like page fault
> handling, page zapping etc. There are other potential use cases for
> per-page memory attributes, e.g. to make memory read-only (or no-exec,
> or exec-only, etc.) without having to modify memslots.
>
> Introduce two ioctls (advertised by KVM_CAP_MEMORY_ATTRIBUTES) to allow
> userspace to operate on the per-page memory attributes.
> - KVM_SET_MEMORY_ATTRIBUTES to set the per-page memory attributes to
> a guest memory range.
> - KVM_GET_SUPPORTED_MEMORY_ATTRIBUTES to return the KVM supported
> memory attributes.
>
> Use an xarray to store the per-page attributes internally, with a naive,
> not fully optimized implementation, i.e. prioritize correctness over
> performance for the initial implementation.
>
> Because setting memory attributes is roughly analogous to mprotect() on
> memory that is mapped into the guest, zap existing mappings prior to
> updating the memory attributes. Opportunistically provide an arch hook
> for the post-set path (needed to complete invalidation anyways) in
> anticipation of x86 needing the hook to update metadata related to
> determining whether or not a given gfn can be backed with various sizes
> of hugepages.
>
> It's possible that future usages may not require an invalidation, e.g.
> if KVM ends up supporting RWX protections and userspace grants _more_
> protections, but again opt for simplicity and punt optimizations to
> if/when they are needed.
>
> Suggested-by: Sean Christopherson
> Link: https://lore.kernel.org/all/y2wb48kd0j4vg...@google.com
> Cc: Fuad Tabba
> Signed-off-by: Chao Peng
> Co-developed-by: Sean Christopherson
> Signed-off-by: Sean Christopherson
> ---
> Documentation/virt/kvm/api.rst | 60
> include/linux/kvm_host.h | 14 +++
> include/uapi/linux/kvm.h | 14 +++
> virt/kvm/Kconfig | 4 +
> virt/kvm/kvm_main.c| 170 +
> 5 files changed, 262 insertions(+)
>
> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> index 34d4ce66e0c8..0ca8561775ac 100644
> --- a/Documentation/virt/kvm/api.rst
> +++ b/Documentation/virt/kvm/api.rst
> @@ -6068,6 +6068,56 @@ writes to the CNTVCT_EL0 and CNTPCT_EL0 registers
> using the SET_ONE_REG
> interface. No error will be returned, but the resulting offset will not be
> applied.
>
> +4.139 KVM_GET_SUPPORTED_MEMORY_ATTRIBUTES
> +-
> +
> +:Capability: KVM_CAP_MEMORY_ATTRIBUTES
> +:Architectures: x86
> +:Type: vm ioctl
> +:Parameters: u64 memory attributes bitmask(out)
> +:Returns: 0 on success, <0 on error
> +
> +Returns supported memory attributes bitmask. Supported memory attributes will
> +have the corresponding bits set in u64 memory attributes bitmask.
> +
> +The following memory attributes are defined::
> +
> + #define KVM_MEMORY_ATTRIBUTE_PRIVATE (1ULL << 3)
> +
> +4.140 KVM_SET_MEMORY_ATTRIBUTES
> +-
> +
> +:Capability: KVM_CAP_MEMORY_ATTRIBUTES
> +:Architectures: x86
> +:Type: vm ioctl
> +:Parameters: struct kvm_memory_attributes(in/out)
> +:Returns: 0 on success, <0 on error
> +
> +Sets memory attributes for pages in a guest memory range. Parameters are
> +specified via the following structure::
> +
> + struct kvm_memory_attributes {
> + __u64 address;
> + __u64 size;
> + __u64 attributes;
> + __u64 flags;
> + };
> +
> +The user sets the per-page memory attributes to a guest memory range
> indicated
> +by address/size, and in return KVM adjusts address and size to reflect the
> +actual pages of the memory range have been successfully set to the
> attributes.
> +If the call returns 0, "address" is updated to the last successful address +
> 1
> +and "size" is updated to the remaining address size that has not been set
> +successfully. The user should check the return value as well as the size to
> +decide if the operation succeeded for the whole range or not. The user may
> want
> +to retry the operation with the returned address/size if the previous range
> was
> +partially successful.
> +
> +Both address and size should be page aligned and the supported attributes
> can be
> +retrieved with KVM_GET_SUPPORTED_MEMORY_ATTRIBUTES.
> +
> +The "flags" field may be used for future extensions and should be set to 0s.
> +
> 5. The kvm_run structure
>
>
> @@ -8494,6 +8544,16 @@ block sizes is exposed in
> KVM_CAP_ARM_SUPPORTED_BLOCK_SIZES as a
> 64-bit bitmap (each bit describing a block size). The default value is
> 0, to disable the eager page splitting.
>
> +8.41 KVM_CAP_MEMORY_ATTRIBUTES
> +--
> +
> +:Capability: KVM_CAP_MEMORY_ATTRIBUTES
> +:Architectures: x86
> +:Type:
Re: [PATCH] word-at-a-time: use the same return type for has_zero regardless of endianness
On Wed, Aug 2, 2023, at 19:37, Linus Torvalds wrote: > On Wed, 2 Aug 2023 at 09:16, Nathan Chancellor wrote: >> >> We see this warning with ARCH=arm64 defconfig + CONFIG_CPU_BIG_ENDIAN=y. > > Oh Christ. I didn't even realize that arm64 allowed a BE config. > > The config option goes back to 2013 - are there actually BE user space > implementations around? At least NXP's Layerscape and Huawei's SoCs ended up in big-endian appliances, running legacy software ported from mips or powerpc. I agree this was a mistake, but that wasn't nearly as obvious ten years ago when there were still new BE-only sparc, mips and powerpc put on the market -- that really only ended in 2017. > People, why do we do that? That's positively crazy. BE is dead and > should be relegated to legacy platforms. There are no advantages to > being different just for the sake of being different - any "security > by obscurity" argument would be far outweighed by the inconvenience to > actual users. > > Yes, yes, I know the aarch64 architecture technically allows BE > implementations - and apparently you can even do it by exception > level, which I had to look up. But do any actually exist? > > Does the kernel even work right in BE mode? It's really easy to miss > some endianness check when all the actual hardware and use is LE, and > when (for example) instruction encoding and IO is then always LE > anyway. This was always only done for compatibility with non-portable software when companies with large custom network stacks argued that it was cheaper to build the entire open source software to big-endian than port their own product to little-endian. ;-) We (Linaro) used to test all toolchain and kernel releases in big-endian mode as member companies had customers that asked for it, but that stopped a while ago as those legacy software stacks either got more portable or got replaced over time. Many Arm systems won't boot BE kernels any more because UEFI firmware only supports LE, or because of driver bugs. Virtual machines are still likely to work fine though. I'm fairly sure that all Arm Cortex and Neoverse cores still\ support BE mode in all exception levels, OTOH at least Apple's custom CPUs do not implement it at all. Arnd
Re: [PATCH] word-at-a-time: use the same return type for has_zero regardless of endianness
On Wed, 2 Aug 2023 at 09:16, Nathan Chancellor wrote: > > We see this warning with ARCH=arm64 defconfig + CONFIG_CPU_BIG_ENDIAN=y. Oh Christ. I didn't even realize that arm64 allowed a BE config. The config option goes back to 2013 - are there actually BE user space implementations around? People, why do we do that? That's positively crazy. BE is dead and should be relegated to legacy platforms. There are no advantages to being different just for the sake of being different - any "security by obscurity" argument would be far outweighed by the inconvenience to actual users. Yes, yes, I know the aarch64 architecture technically allows BE implementations - and apparently you can even do it by exception level, which I had to look up. But do any actually exist? Does the kernel even work right in BE mode? It's really easy to miss some endianness check when all the actual hardware and use is LE, and when (for example) instruction encoding and IO is then always LE anyway. > With both clang 18.0.0 (tip of tree) and GCC 13.1.0, I don't see any > actual code generation changes in fs/namei.o with this configuration. Ok, since the main legacy platform confirmed that, I'll just apply that patch directly. I'll also do the powerpc version that Arnd pointed to at the same time, since it seems silly to pick these off one at a time. It too should just be 'unsigned long', so that the two values can be bitwise or'ed together without any questions. Linus
Re: [PATCH v2 0/3] Update the register list of MICFIL
On Wed, 02 Aug 2023 13:21:14 +0800, Chancel Liu wrote: > MICFIL IP is upgraded on i.MX93 platform. Add new registers and new bit > definition. > > changes in v2: > - rename check_version to use_verid to make it more explicit > - rename fsl_micfil_check_version to fsl_micfil_use_verid > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/3] ASoC: fsl_micfil: Add new registers and new bit definition commit: 51d765f79c8d8016df906afd05410f8bc14167ac [2/3] ASoC: fsl_micfil: Add fsl_micfil_use_verid function commit: 367365051b06e172c91172e3273eea72988ce8f6 [3/3] ASoC: fsl_micfil: Use SET_SYSTEM_SLEEP_PM_OPS to simplify PM commit: a38a4090e2c400c6c49c584cda6f28c73c08f5f1 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [RFC PATCH v2 0/7] Add audio support in v4l2 framework
On Wed, Aug 02, 2023 at 10:41:43PM +0800, Shengjiu Wang wrote: > Currently the ASRC in ALSA is to connect to another I2S device as > a sound card. But we'd like to the ASRC can be used by user space directly > that user space application can get the output after conversion from ASRC. That sort of use case would be handled via DPCM at the minute, though persuading it to connect two front ends together might be fun (which is the sort of reason why we want to push digital information down into DAPM and make everything a component). signature.asc Description: PGP signature
Re: [PATCH v7 2/2] PCI: rpaphp: Error out on busy status from get-sensor-state
On 2023-08-01 16:38:08 Tue, Bjorn Helgaas wrote: > On Mon, Jul 24, 2023 at 02:25:19PM +0530, Mahesh Salgaonkar wrote: > > When certain PHB HW failure causes pHyp to recover PHB, it marks the PE > > state as temporarily unavailable until recovery is complete. This also > > triggers an EEH handler in Linux which needs to notify drivers, and perform > > recovery. But before notifying the driver about the PCI error it uses > > get_adapter_state()->get-sensor-state() operation of the hotplug_slot to > > determine if the slot contains a device or not. if the slot is empty, the > > recovery is skipped entirely. > > It's helpful to use the exact function name so it's greppable; I think > get_adapter_status() or rpaphp_get_sensor_state()? > > s/if the slot is empty,/If the slot is empty,/ Sure, will correct it in next revision. > > > However on certain PHB failures, the RTAS call get-sensor-state() returns > > extended busy error (9902) until PHB is recovered by pHyp. Once PHB is > > recovered, the get-sensor-state() returns success with correct presence > > status. The RTAS call interface rtas_get_sensor() loops over the RTAS call > > on extended delay return code (9902) until the return value is either > > success (0) or error (-1). This causes the EEH handler to get stuck for ~6 > > seconds before it could notify that the PCI error has been detected and > > stop any active operations. Hence with running I/O traffic, during this 6 > > seconds, the network driver continues its operation and hits a timeout > > (netdev watchdog). > > > > > > [52732.244731] DEBUG: ibm_read_slot_reset_state2() > > [52732.244762] DEBUG: ret = 0, rets[0]=5, rets[1]=1, rets[2]=4000, rets[3]=> > > [52732.244798] DEBUG: in eeh_slot_presence_check > > [52732.244804] DEBUG: error state check > > [52732.244807] DEBUG: Is slot hotpluggable > > [52732.244810] DEBUG: hotpluggable ops ? > > [52732.244953] DEBUG: Calling ops->get_adapter_status > > [52732.244958] DEBUG: calling rpaphp_get_sensor_state > > [52736.564262] [ cut here ] > > [52736.564299] NETDEV WATCHDOG: enP64p1s0f3 (tg3): transmit queue 0 timed o> > > [52736.564324] WARNING: CPU: 1442 PID: 0 at net/sched/sch_generic.c:478 dev> > > [...] > > [52736.564505] NIP [c0c32368] dev_watchdog+0x438/0x440 > > [52736.564513] LR [c0c32364] dev_watchdog+0x434/0x440 > > > > > > On timeouts, network driver starts dumping debug information to console > > (e.g bnx2 driver calls bnx2x_panic_dump()), and go into recovery path while > > pHyp is still recovering the PHB. As part of recovery, the driver tries to > > reset the device and it keeps failing since every PCI read/write returns > > ff's. And when EEH recovery kicks-in, the driver is unable to recover the > > device. This impacts the ssh connection and leads to the system being > > inaccessible. To get the NIC working again it needs a reboot or re-assign > > the I/O adapter from HMC. > > > > [ 9531.168587] EEH: Beginning: 'slot_reset' > > [ 9531.168601] PCI 0013:01:00.0#1: EEH: Invoking bnx2x->slot_reset() > > [...] > > [ 9614.110094] bnx2x: [bnx2x_func_stop:9129(enP19p1s0f0)]FUNC_STOP ramrod > > failed. Running a dry transaction > > [ 9614.110300] bnx2x: [bnx2x_igu_int_disable:902(enP19p1s0f0)]BUG! Proper > > val not read from IGU! > > [ 9629.178067] bnx2x: [bnx2x_fw_command:3055(enP19p1s0f0)]FW failed to > > respond! > > [ 9629.178085] bnx2x 0013:01:00.0 enP19p1s0f0: bc 7.10.4 > > [ 9629.178091] bnx2x: [bnx2x_fw_dump_lvl:789(enP19p1s0f0)]Cannot dump MCP > > info while in PCI error > > [ 9644.241813] bnx2x: [bnx2x_io_slot_reset:14245(enP19p1s0f0)]IO slot reset > > --> driver unload > > [...] > > [ 9644.241819] PCI 0013:01:00.0#1: EEH: bnx2x driver reports: > > 'disconnect' > > [ 9644.241823] PCI 0013:01:00.1#1: EEH: Invoking bnx2x->slot_reset() > > [ 9644.241827] bnx2x: [bnx2x_io_slot_reset:14229(enP19p1s0f1)]IO slot reset > > initializing... > > [ 9644.241916] bnx2x 0013:01:00.1: enabling device (0140 -> 0142) > > [ 9644.258604] bnx2x: [bnx2x_io_slot_reset:14245(enP19p1s0f1)]IO slot reset > > --> driver unload > > [ 9644.258612] PCI 0013:01:00.1#1: EEH: bnx2x driver reports: > > 'disconnect' > > [ 9644.258615] EEH: Finished:'slot_reset' with aggregate recovery > > state:'disconnect' > > [ 9644.258620] EEH: Unable to recover from failure from PHB#13-PE#1. > > [ 9644.261811] EEH: Beginning: 'error_detected(permanent failure)' > > [...] > > [ 9644.261823] EEH: Finished:'error_detected(permanent failure)' > > > > Hence, it becomes important to inform driver about the PCI error detection > > as early as possible, so that driver is aware of PCI error and waits for > > EEH handler's next action for successful recovery. > > I don't really understand the connection between EEH and > get_adapter_status(), but I guess this probably refers to > arch/powerpc/kernel/eeh_driver.c, not the PCI core aer.c and err.c? Yup, EEH is an I/O error recovery
Re: [PATCH v7 7/7] mm/memory_hotplug: Enable runtime update of memmap_on_memory parameter
On Wed 02-08-23 17:54:04, David Hildenbrand wrote: > On 02.08.23 17:50, Michal Hocko wrote: > > On Wed 02-08-23 10:15:04, Aneesh Kumar K V wrote: > > > On 8/1/23 4:20 PM, Michal Hocko wrote: > > > > On Tue 01-08-23 14:58:29, Aneesh Kumar K V wrote: > > > > > On 8/1/23 2:28 PM, Michal Hocko wrote: > > > > > > On Tue 01-08-23 10:11:16, Aneesh Kumar K.V wrote: > > > > > > > Allow updating memmap_on_memory mode after the kernel boot. Memory > > > > > > > hotplug done after the mode update will use the new > > > > > > > mmemap_on_memory > > > > > > > value. > > > > > > > > > > > > Well, this is a user space kABI extension and as such you should > > > > > > spend > > > > > > more words about the usecase. Why we could live with this static > > > > > > and now > > > > > > need dynamic? > > > > > > > > > > > > > > > > This enables easy testing of memmap_on_memory feature without a > > > > > kernel reboot. > > > > > > > > Testing alone is rather weak argument to be honest. > > > > > > > > > I also expect people wanting to use that when they find dax kmem > > > > > memory online > > > > > failing because of struct page allocation failures[1]. User could > > > > > reboot back with > > > > > memmap_on_memory=y kernel parameter. But being able to enable it via > > > > > sysfs makes > > > > > the feature much more useful. > > > > > > > > Sure it can be useful but that holds for any feature, right. The main > > > > question is whether this is worth maintaing. The current implementation > > > > seems rather trivial which is an argument to have it but are there any > > > > risks long term? Have you evaluated a potential long term maintenance > > > > cost? There is no easy way to go back and disable it later on without > > > > breaking some userspace. > > > > > > > > All that should be in the changelog! > > > > > > I updated it as below. > > > > > > mm/memory_hotplug: Enable runtime update of memmap_on_memory parameter > > > > > > Allow updating memmap_on_memory mode after the kernel boot. Memory > > > hotplug done after the mode update will use the new mmemap_on_memory > > > value. > > > > > > It is now possible to test the memmap_on_memory feature easily without > > > the need for a kernel reboot. Additionally, for those encountering > > > struct page allocation failures while using dax kmem memory online, this > > > feature may prove useful. Instead of rebooting with the > > > memmap_on_memory=y kernel parameter, users can now enable it via sysfs, > > > which greatly enhances its usefulness. > > > > > > I do not really see a solid argument why rebooting is really a problem > > TBH. Also is the global policy knob really the right fit for existing > > hotplug usecases? In other words, if we really want to make > > memmap_on_memory more flexible would it make more sense to have it per > > memory block property instead (the global knob being the default if > > admin doesn't specify it differently). > > Per memory block isn't possible, due to the creation order. I am not sure I follow. Could you elaborate more? > Also, I think it's not the right approach. > > I thought about driver toggles. At least for dax/kmem people are looking > into that: > > https://lkml.kernel.org/r/20230801-vv-kmem_memmap-v3-2-406e9aaf5...@intel.com > > Where that can also be toggled per device. Per device flag makes sense to me as well. But what we should do about hotplugged memory with a backing device (like regular RAM). I can see some reason to have large hotplugged memory ranges to be self vmemap hosted while smaller blocks to be backed by external vmemmaps. -- Michal Hocko SUSE Labs
Re: [PATCH] powerpc: Use shared font data
* Randy Dunlap (rdun...@infradead.org) wrote:
>
>
> On 8/2/23 05:19, Michael Ellerman wrote:
> > "Dr. David Alan Gilbert" writes:
> >> * Michael Ellerman (m...@ellerman.id.au) wrote:
> >>> li...@treblig.org writes:
> From: "Dr. David Alan Gilbert"
>
> PowerPC has a 'btext' font used for the console which is almost identical
> to the shared font_sun8x16, so use it rather than duplicating the data.
>
> They were actually identical until about a decade ago when
> commit bcfbeecea11c ("drivers: console: font_: Change a glyph from
> "broken bar" to "vertical line"")
>
> which changed the | in the shared font to be a solid
> bar rather than a broken bar. That's the only difference.
>
> This was originally spotted by PMD which noticed that sparc does
> >>>
> >>> PMD means "Page Middle Directory" to most Linux folks, I assume that's
> >>> not what you meant :)
> >>
> >> Ah, any good TLA is ripe for reuse:
> >>https://pmd.github.io/pmd/pmd_userdocs_cpd.html
> >
> > Thanks.
> >
> > Unfortunately this patch causes a warning:
> >
> > WARNING: unmet direct dependencies detected for FONT_SUN8x16
> > Depends on [n]: FONT_SUPPORT [=y] && FRAMEBUFFER_CONSOLE [=y] &&
> > (!SPARC && FONTS [=n] || SPARC)
> > Selected by [y]:
> > - BOOTX_TEXT [=y] && PPC_BOOK3S [=y]
> >
> > And breaks allmodconfig with:
> >
> > ld: arch/powerpc/kernel/btext.o:(.toc+0x0): undefined reference to
> > `font_sun_8x16'
> > make[3]: *** [../scripts/Makefile.vmlinux:36: vmlinux] Error 1
> >
> > I guess the Kconfig logic needs some more work.
>
> Also please see:
>
> https://lore.kernel.org/all/dd29e5f5-d9f7-0103-e602-b98f26c88...@infradead.org/
> for a similar problem on UML.
Thanks Michael, Randy.
Does anyone understand why the font_sun8x16 has any of those
'Depends on' ?
It's just a font structure definition.
Dave
> --
> ~Randy
--
-Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux | Happy \
\dave @ treblig.org | | In Hex /
\ _|_ http://www.treblig.org |___/
Re: [PATCH v7 7/7] mm/memory_hotplug: Enable runtime update of memmap_on_memory parameter
On Wed, 2023-08-02 at 21:27 +0530, Aneesh Kumar K V wrote: > On 8/2/23 9:24 PM, David Hildenbrand wrote: > > On 02.08.23 17:50, Michal Hocko wrote: > > > On Wed 02-08-23 10:15:04, Aneesh Kumar K V wrote: > > > > On 8/1/23 4:20 PM, Michal Hocko wrote: > > > > > On Tue 01-08-23 14:58:29, Aneesh Kumar K V wrote: > > > > > > On 8/1/23 2:28 PM, Michal Hocko wrote: > > > > > > > On Tue 01-08-23 10:11:16, Aneesh Kumar K.V wrote: > > > > > > > > Allow updating memmap_on_memory mode after the kernel boot. > > > > > > > > Memory > > > > > > > > hotplug done after the mode update will use the new > > > > > > > > mmemap_on_memory > > > > > > > > value. > > > > > > > > > > > > > > Well, this is a user space kABI extension and as such you should > > > > > > > spend > > > > > > > more words about the usecase. Why we could live with this static > > > > > > > and now > > > > > > > need dynamic? > > > > > > > > > > > > > > > > > > > This enables easy testing of memmap_on_memory feature without a > > > > > > kernel reboot. > > > > > > > > > > Testing alone is rather weak argument to be honest. > > > > > > > > > > > I also expect people wanting to use that when they find dax kmem > > > > > > memory online > > > > > > failing because of struct page allocation failures[1]. User could > > > > > > reboot back with > > > > > > memmap_on_memory=y kernel parameter. But being able to enable it > > > > > > via sysfs makes > > > > > > the feature much more useful. > > > > > > > > > > Sure it can be useful but that holds for any feature, right. The main > > > > > question is whether this is worth maintaing. The current > > > > > implementation > > > > > seems rather trivial which is an argument to have it but are there any > > > > > risks long term? Have you evaluated a potential long term maintenance > > > > > cost? There is no easy way to go back and disable it later on without > > > > > breaking some userspace. > > > > > > > > > > All that should be in the changelog! > > > > > > > > I updated it as below. > > > > > > > > mm/memory_hotplug: Enable runtime update of memmap_on_memory parameter > > > > > > > > Allow updating memmap_on_memory mode after the kernel boot. Memory > > > > hotplug done after the mode update will use the new mmemap_on_memory > > > > value. > > > > > > > > It is now possible to test the memmap_on_memory feature easily without > > > > the need for a kernel reboot. Additionally, for those encountering > > > > struct page allocation failures while using dax kmem memory online, this > > > > feature may prove useful. Instead of rebooting with the > > > > memmap_on_memory=y kernel parameter, users can now enable it via sysfs, > > > > which greatly enhances its usefulness. > > > > > > > > > I do not really see a solid argument why rebooting is really a problem > > > TBH. Also is the global policy knob really the right fit for existing > > > hotplug usecases? In other words, if we really want to make > > > memmap_on_memory more flexible would it make more sense to have it per > > > memory block property instead (the global knob being the default if > > > admin doesn't specify it differently). > > > > Per memory block isn't possible, due to the creation order. Also, I think > > it's not the right approach. > > > > I thought about driver toggles. At least for dax/kmem people are looking > > into that: > > > > https://lkml.kernel.org/r/20230801-vv-kmem_memmap-v3-2-406e9aaf5...@intel.com > > > > Where that can also be toggled per device. > > > > That still is dependent on the global memmap_on_memory enabled right? We > could make the dax facility independent of the > global feature toggle? Correct - the latest version of those David linked does depend on the global memmap_on_memory param. Since kmem's behavior for dax devices is set up to be turned on / off dynamically via sysfs, it would be nice to have a similar facility for this flag. I did try the making dax independent of memmap_on_memory approach in my first posting: https://lore.kernel.org/nvdimm/20230613-vv-kmem_memmap-v1-1-f6de9c6af...@intel.com/ We can certainly revisit that if it looks more suitable.
Re: [PATCH v7 7/7] mm/memory_hotplug: Enable runtime update of memmap_on_memory parameter
On 8/2/23 9:24 PM, David Hildenbrand wrote: > On 02.08.23 17:50, Michal Hocko wrote: >> On Wed 02-08-23 10:15:04, Aneesh Kumar K V wrote: >>> On 8/1/23 4:20 PM, Michal Hocko wrote: On Tue 01-08-23 14:58:29, Aneesh Kumar K V wrote: > On 8/1/23 2:28 PM, Michal Hocko wrote: >> On Tue 01-08-23 10:11:16, Aneesh Kumar K.V wrote: >>> Allow updating memmap_on_memory mode after the kernel boot. Memory >>> hotplug done after the mode update will use the new mmemap_on_memory >>> value. >> >> Well, this is a user space kABI extension and as such you should spend >> more words about the usecase. Why we could live with this static and now >> need dynamic? >> > > This enables easy testing of memmap_on_memory feature without a kernel > reboot. Testing alone is rather weak argument to be honest. > I also expect people wanting to use that when they find dax kmem memory > online > failing because of struct page allocation failures[1]. User could reboot > back with > memmap_on_memory=y kernel parameter. But being able to enable it via > sysfs makes > the feature much more useful. Sure it can be useful but that holds for any feature, right. The main question is whether this is worth maintaing. The current implementation seems rather trivial which is an argument to have it but are there any risks long term? Have you evaluated a potential long term maintenance cost? There is no easy way to go back and disable it later on without breaking some userspace. All that should be in the changelog! >>> >>> I updated it as below. >>> >>> mm/memory_hotplug: Enable runtime update of memmap_on_memory parameter >>> >>> Allow updating memmap_on_memory mode after the kernel boot. Memory >>> hotplug done after the mode update will use the new mmemap_on_memory >>> value. >>> >>> It is now possible to test the memmap_on_memory feature easily without >>> the need for a kernel reboot. Additionally, for those encountering >>> struct page allocation failures while using dax kmem memory online, this >>> feature may prove useful. Instead of rebooting with the >>> memmap_on_memory=y kernel parameter, users can now enable it via sysfs, >>> which greatly enhances its usefulness. >> >> >> I do not really see a solid argument why rebooting is really a problem >> TBH. Also is the global policy knob really the right fit for existing >> hotplug usecases? In other words, if we really want to make >> memmap_on_memory more flexible would it make more sense to have it per >> memory block property instead (the global knob being the default if >> admin doesn't specify it differently). > > Per memory block isn't possible, due to the creation order. Also, I think > it's not the right approach. > > I thought about driver toggles. At least for dax/kmem people are looking into > that: > > https://lkml.kernel.org/r/20230801-vv-kmem_memmap-v3-2-406e9aaf5...@intel.com > > Where that can also be toggled per device. > That still is dependent on the global memmap_on_memory enabled right? We could make the dax facility independent of the global feature toggle? -aneesh
Re: [PATCH v7 7/7] mm/memory_hotplug: Enable runtime update of memmap_on_memory parameter
On 02.08.23 17:50, Michal Hocko wrote: On Wed 02-08-23 10:15:04, Aneesh Kumar K V wrote: On 8/1/23 4:20 PM, Michal Hocko wrote: On Tue 01-08-23 14:58:29, Aneesh Kumar K V wrote: On 8/1/23 2:28 PM, Michal Hocko wrote: On Tue 01-08-23 10:11:16, Aneesh Kumar K.V wrote: Allow updating memmap_on_memory mode after the kernel boot. Memory hotplug done after the mode update will use the new mmemap_on_memory value. Well, this is a user space kABI extension and as such you should spend more words about the usecase. Why we could live with this static and now need dynamic? This enables easy testing of memmap_on_memory feature without a kernel reboot. Testing alone is rather weak argument to be honest. I also expect people wanting to use that when they find dax kmem memory online failing because of struct page allocation failures[1]. User could reboot back with memmap_on_memory=y kernel parameter. But being able to enable it via sysfs makes the feature much more useful. Sure it can be useful but that holds for any feature, right. The main question is whether this is worth maintaing. The current implementation seems rather trivial which is an argument to have it but are there any risks long term? Have you evaluated a potential long term maintenance cost? There is no easy way to go back and disable it later on without breaking some userspace. All that should be in the changelog! I updated it as below. mm/memory_hotplug: Enable runtime update of memmap_on_memory parameter Allow updating memmap_on_memory mode after the kernel boot. Memory hotplug done after the mode update will use the new mmemap_on_memory value. It is now possible to test the memmap_on_memory feature easily without the need for a kernel reboot. Additionally, for those encountering struct page allocation failures while using dax kmem memory online, this feature may prove useful. Instead of rebooting with the memmap_on_memory=y kernel parameter, users can now enable it via sysfs, which greatly enhances its usefulness. I do not really see a solid argument why rebooting is really a problem TBH. Also is the global policy knob really the right fit for existing hotplug usecases? In other words, if we really want to make memmap_on_memory more flexible would it make more sense to have it per memory block property instead (the global knob being the default if admin doesn't specify it differently). Per memory block isn't possible, due to the creation order. Also, I think it's not the right approach. I thought about driver toggles. At least for dax/kmem people are looking into that: https://lkml.kernel.org/r/20230801-vv-kmem_memmap-v3-2-406e9aaf5...@intel.com Where that can also be toggled per device. -- Cheers, David / dhildenb
Re: [PATCH v7 7/7] mm/memory_hotplug: Enable runtime update of memmap_on_memory parameter
On Wed 02-08-23 10:15:04, Aneesh Kumar K V wrote: > On 8/1/23 4:20 PM, Michal Hocko wrote: > > On Tue 01-08-23 14:58:29, Aneesh Kumar K V wrote: > >> On 8/1/23 2:28 PM, Michal Hocko wrote: > >>> On Tue 01-08-23 10:11:16, Aneesh Kumar K.V wrote: > Allow updating memmap_on_memory mode after the kernel boot. Memory > hotplug done after the mode update will use the new mmemap_on_memory > value. > >>> > >>> Well, this is a user space kABI extension and as such you should spend > >>> more words about the usecase. Why we could live with this static and now > >>> need dynamic? > >>> > >> > >> This enables easy testing of memmap_on_memory feature without a kernel > >> reboot. > > > > Testing alone is rather weak argument to be honest. > > > >> I also expect people wanting to use that when they find dax kmem memory > >> online > >> failing because of struct page allocation failures[1]. User could reboot > >> back with > >> memmap_on_memory=y kernel parameter. But being able to enable it via sysfs > >> makes > >> the feature much more useful. > > > > Sure it can be useful but that holds for any feature, right. The main > > question is whether this is worth maintaing. The current implementation > > seems rather trivial which is an argument to have it but are there any > > risks long term? Have you evaluated a potential long term maintenance > > cost? There is no easy way to go back and disable it later on without > > breaking some userspace. > > > > All that should be in the changelog! > > I updated it as below. > > mm/memory_hotplug: Enable runtime update of memmap_on_memory parameter > > Allow updating memmap_on_memory mode after the kernel boot. Memory > hotplug done after the mode update will use the new mmemap_on_memory > value. > > It is now possible to test the memmap_on_memory feature easily without > the need for a kernel reboot. Additionally, for those encountering > struct page allocation failures while using dax kmem memory online, this > feature may prove useful. Instead of rebooting with the > memmap_on_memory=y kernel parameter, users can now enable it via sysfs, > which greatly enhances its usefulness. I do not really see a solid argument why rebooting is really a problem TBH. Also is the global policy knob really the right fit for existing hotplug usecases? In other words, if we really want to make memmap_on_memory more flexible would it make more sense to have it per memory block property instead (the global knob being the default if admin doesn't specify it differently). -- Michal Hocko SUSE Labs
[PATCH v6 21/38] powerpc: Implement the new page table range API
Add set_ptes(), update_mmu_cache_range() and flush_dcache_folio().
Change the PG_arch_1 (aka PG_dcache_dirty) flag from being per-page to
per-folio.
Signed-off-by: Matthew Wilcox (Oracle)
Acked-by: Mike Rapoport (IBM)
Cc: Michael Ellerman
Cc: Nicholas Piggin
Cc: Christophe Leroy
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/include/asm/book3s/32/pgtable.h | 5 --
arch/powerpc/include/asm/book3s/64/pgtable.h | 6 +--
arch/powerpc/include/asm/book3s/pgtable.h| 11 ++--
arch/powerpc/include/asm/cacheflush.h| 14 --
arch/powerpc/include/asm/kvm_ppc.h | 10 ++--
arch/powerpc/include/asm/nohash/pgtable.h| 16 ++
arch/powerpc/include/asm/pgtable.h | 12 +
arch/powerpc/mm/book3s64/hash_utils.c| 11 ++--
arch/powerpc/mm/cacheflush.c | 40 +--
arch/powerpc/mm/nohash/e500_hugetlbpage.c| 3 +-
arch/powerpc/mm/pgtable.c| 53
11 files changed, 88 insertions(+), 93 deletions(-)
diff --git a/arch/powerpc/include/asm/book3s/32/pgtable.h
b/arch/powerpc/include/asm/book3s/32/pgtable.h
index 7bf1fe7297c6..5f12b9382909 100644
--- a/arch/powerpc/include/asm/book3s/32/pgtable.h
+++ b/arch/powerpc/include/asm/book3s/32/pgtable.h
@@ -462,11 +462,6 @@ static inline pte_t pfn_pte(unsigned long pfn, pgprot_t
pgprot)
pgprot_val(pgprot));
}
-static inline unsigned long pte_pfn(pte_t pte)
-{
- return pte_val(pte) >> PTE_RPN_SHIFT;
-}
-
/* Generic modifiers for PTE bits */
static inline pte_t pte_wrprotect(pte_t pte)
{
diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h
b/arch/powerpc/include/asm/book3s/64/pgtable.h
index a8204566cfd0..8269b231c533 100644
--- a/arch/powerpc/include/asm/book3s/64/pgtable.h
+++ b/arch/powerpc/include/asm/book3s/64/pgtable.h
@@ -104,6 +104,7 @@
* and every thing below PAGE_SHIFT;
*/
#define PTE_RPN_MASK (((1UL << _PAGE_PA_MAX) - 1) & (PAGE_MASK))
+#define PTE_RPN_SHIFT PAGE_SHIFT
/*
* set of bits not changed in pmd_modify. Even though we have hash specific
bits
* in here, on radix we expect them to be zero.
@@ -569,11 +570,6 @@ static inline pte_t pfn_pte(unsigned long pfn, pgprot_t
pgprot)
return __pte(((pte_basic_t)pfn << PAGE_SHIFT) | pgprot_val(pgprot) |
_PAGE_PTE);
}
-static inline unsigned long pte_pfn(pte_t pte)
-{
- return (pte_val(pte) & PTE_RPN_MASK) >> PAGE_SHIFT;
-}
-
/* Generic modifiers for PTE bits */
static inline pte_t pte_wrprotect(pte_t pte)
{
diff --git a/arch/powerpc/include/asm/book3s/pgtable.h
b/arch/powerpc/include/asm/book3s/pgtable.h
index d18b748ea3ae..3b7bd36a2321 100644
--- a/arch/powerpc/include/asm/book3s/pgtable.h
+++ b/arch/powerpc/include/asm/book3s/pgtable.h
@@ -9,13 +9,6 @@
#endif
#ifndef __ASSEMBLY__
-/* Insert a PTE, top-level function is out of line. It uses an inline
- * low level function in the respective pgtable-* files
- */
-extern void set_pte_at(struct mm_struct *mm, unsigned long addr, pte_t *ptep,
- pte_t pte);
-
-
#define __HAVE_ARCH_PTEP_SET_ACCESS_FLAGS
extern int ptep_set_access_flags(struct vm_area_struct *vma, unsigned long
address,
pte_t *ptep, pte_t entry, int dirty);
@@ -36,7 +29,9 @@ void __update_mmu_cache(struct vm_area_struct *vma, unsigned
long address, pte_t
* corresponding HPTE into the hash table ahead of time, instead of
* waiting for the inevitable extra hash-table miss exception.
*/
-static inline void update_mmu_cache(struct vm_area_struct *vma, unsigned long
address, pte_t *ptep)
+static inline void update_mmu_cache_range(struct vm_fault *vmf,
+ struct vm_area_struct *vma, unsigned long address,
+ pte_t *ptep, unsigned int nr)
{
if (IS_ENABLED(CONFIG_PPC32) && !mmu_has_feature(MMU_FTR_HPTE_TABLE))
return;
diff --git a/arch/powerpc/include/asm/cacheflush.h
b/arch/powerpc/include/asm/cacheflush.h
index 7564dd4fd12b..ef7d2de33b89 100644
--- a/arch/powerpc/include/asm/cacheflush.h
+++ b/arch/powerpc/include/asm/cacheflush.h
@@ -35,13 +35,19 @@ static inline void flush_cache_vmap(unsigned long start,
unsigned long end)
* It just marks the page as not i-cache clean. We do the i-cache
* flush later when the page is given to a user process, if necessary.
*/
-static inline void flush_dcache_page(struct page *page)
+static inline void flush_dcache_folio(struct folio *folio)
{
if (cpu_has_feature(CPU_FTR_COHERENT_ICACHE))
return;
/* avoid an atomic op if possible */
- if (test_bit(PG_dcache_clean, >flags))
- clear_bit(PG_dcache_clean, >flags);
+ if (test_bit(PG_dcache_clean, >flags))
+ clear_bit(PG_dcache_clean, >flags);
+}
+#define flush_dcache_folio flush_dcache_folio
+
+static inline void flush_dcache_page(struct page *page)
+{
+ flush_dcache_folio(page_folio(page));
}
void flush_icache_range(unsigned long start,
Re: [PATCH] powerpc: Use shared font data
On 8/2/23 05:19, Michael Ellerman wrote:
> "Dr. David Alan Gilbert" writes:
>> * Michael Ellerman (m...@ellerman.id.au) wrote:
>>> li...@treblig.org writes:
From: "Dr. David Alan Gilbert"
PowerPC has a 'btext' font used for the console which is almost identical
to the shared font_sun8x16, so use it rather than duplicating the data.
They were actually identical until about a decade ago when
commit bcfbeecea11c ("drivers: console: font_: Change a glyph from
"broken bar" to "vertical line"")
which changed the | in the shared font to be a solid
bar rather than a broken bar. That's the only difference.
This was originally spotted by PMD which noticed that sparc does
>>>
>>> PMD means "Page Middle Directory" to most Linux folks, I assume that's
>>> not what you meant :)
>>
>> Ah, any good TLA is ripe for reuse:
>>https://pmd.github.io/pmd/pmd_userdocs_cpd.html
>
> Thanks.
>
> Unfortunately this patch causes a warning:
>
> WARNING: unmet direct dependencies detected for FONT_SUN8x16
> Depends on [n]: FONT_SUPPORT [=y] && FRAMEBUFFER_CONSOLE [=y] && (!SPARC
> && FONTS [=n] || SPARC)
> Selected by [y]:
> - BOOTX_TEXT [=y] && PPC_BOOK3S [=y]
>
> And breaks allmodconfig with:
>
> ld: arch/powerpc/kernel/btext.o:(.toc+0x0): undefined reference to
> `font_sun_8x16'
> make[3]: *** [../scripts/Makefile.vmlinux:36: vmlinux] Error 1
>
> I guess the Kconfig logic needs some more work.
Also please see:
https://lore.kernel.org/all/dd29e5f5-d9f7-0103-e602-b98f26c88...@infradead.org/
for a similar problem on UML.
--
~Randy
Re: [RFC PATCH v2 0/7] Add audio support in v4l2 framework
On Wed, Aug 2, 2023 at 8:08 PM Takashi Iwai wrote: > > On Wed, 02 Aug 2023 14:02:29 +0200, > Shengjiu Wang wrote: > > > > On Wed, Aug 2, 2023 at 7:22 PM Takashi Iwai wrote: > > > > > > On Wed, 02 Aug 2023 09:32:37 +0200, > > > Hans Verkuil wrote: > > > > > > > > Hi all, > > > > > > > > On 25/07/2023 08:12, Shengjiu Wang wrote: > > > > > Audio signal processing has the requirement for memory to > > > > > memory similar as Video. > > > > > > > > > > This patch is to add this support in v4l2 framework, defined > > > > > new buffer type V4L2_BUF_TYPE_AUDIO_CAPTURE and > > > > > V4L2_BUF_TYPE_AUDIO_OUTPUT, defined new format v4l2_audio_format > > > > > for audio case usage. > > > > > > > > > > The created audio device is named "/dev/audioX". > > > > > > > > > > And add memory to memory support for two kinds of i.MX ASRC > > > > > module > > > > > > > > Before I spend time on this: are the audio maintainers OK with doing > > > > this in V4L2? > > > > > > > > I do want to have a clear statement on this as it is not something I > > > > can decide. > > > > > > Well, I personally don't mind to have some audio capability in v4l2 > > > layer. But, the only uncertain thing for now is whether this is a > > > must-have or not. > > > > > > > Thanks, I am also not sure about this. I am also confused that why > > there is no m2m implementation for audio in the kernel. Audio also > > has similar decoder encoder post-processing as video. > > > > > > > > IIRC, the implementation in the sound driver side was never done just > > > because there was no similar implementation? If so, and if the > > > extension to the v4l2 core layer is needed, shouldn't it be more > > > considered for the possible other route? > > > > > > > Actually I'd like someone could point me to the other route. I'd like to > > try. > > > > The reason why I select to extend v4l2 for such audio usage is that v4l2 > > looks best for this audio m2m implementation. v4l2 is designed for m2m > > usage. if we need implement another 'route', I don't think it can do > > better > > that v4l2. > > > > I appreciate that someone can share his ideas or doable solutions. > > And please don't ignore my request, ignore my patch. > > Can you explain a bit more details of your demand? > At least, a "big picture" showing how your hardware is implemented and > what is exactly necessary would be helpful for understanding the > problem. > We have the hardware IP: ASRC, asynchronous sample rate converter. Currently the ASRC in ALSA is to connect to another I2S device as a sound card. But we'd like to the ASRC can be used by user space directly that user space application can get the output after conversion from ASRC. The ASRC can be integrated into a multimedia framework (gstreamer) as a plugin. best regards wang shengjiu
Re: [PATCH] powerpc: pmac32: enable serial options by default in defconfig
Le 02/08/2023 à 15:41, Yuan Tan a écrit : > [Vous ne recevez pas souvent de courriers de tany...@tinylab.org. Découvrez > pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ] > > Serial is a critical feature for logging and debuging, and the other > architectures enable serial by default. > > Let's enable CONFIG_SERIAL_PMACZILOG and CONFIG_SERIAL_PMACZILOG_CONSOLE > by default. > > Signed-off-by: Yuan Tan Reviewed-by: Christophe Leroy > --- > arch/powerpc/configs/pmac32_defconfig | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/arch/powerpc/configs/pmac32_defconfig > b/arch/powerpc/configs/pmac32_defconfig > index 019163c2571e..3aae79afb9d9 100644 > --- a/arch/powerpc/configs/pmac32_defconfig > +++ b/arch/powerpc/configs/pmac32_defconfig > @@ -176,8 +176,9 @@ CONFIG_MOUSE_APPLETOUCH=y > # CONFIG_SERIO_I8042 is not set > # CONFIG_SERIO_SERPORT is not set > CONFIG_SERIAL_8250=m > -CONFIG_SERIAL_PMACZILOG=m > +CONFIG_SERIAL_PMACZILOG=y > CONFIG_SERIAL_PMACZILOG_TTYS=y > +CONFIG_SERIAL_PMACZILOG_CONSOLE=y > CONFIG_NVRAM=y > CONFIG_I2C_CHARDEV=m > CONFIG_APM_POWER=y > -- > 2.34.1 >
Re: [PATCH] powerpc/powermac: Use early_* IO variants in via_calibrate_decr
Benjamin Gray writes:
> On Thu, 2023-07-06 at 11:08 +1000, Benjamin Gray wrote:
>> The issue is pre-existing, but is surfaced by commit 721255b9826b
>> ("genirq: Use a maple tree for interrupt descriptor management").
>> It's not clear to me why this causes it to surface.
>
> From the thread chain in [1], it looks like the maple tree
> implementation just has different allocation behaviour, which follows a
> pre-existing code path to kmem_cache_alloc_bulk(), which
> unconditionally enables interrupts.
That was a bug that was fixed before the series was merged.
See:
f5451547b831 ("mm, slab/slub: Ensure kmem_cache_alloc_bulk() is available
early")
It looks like the trigger here is that the maple tree code uses
call_rcu() in ma_free_rcu(), and call_rcu() can cause TIF_NEED_RESCHED
to be set, which causes cond_resched() to actually reschedule, enabling
interrupts.
cheers
> (thanks Jordan Niethe for finding this thread)
>
> [1]: https://lore.kernel.org/all/87o7qdzfay.ffs@tglx/
Re: [RFC PATCH v2 0/7] Add audio support in v4l2 framework
On 02/08/2023 14:02, Shengjiu Wang wrote: > On Wed, Aug 2, 2023 at 7:22 PM Takashi Iwai wrote: >> >> On Wed, 02 Aug 2023 09:32:37 +0200, >> Hans Verkuil wrote: >>> >>> Hi all, >>> >>> On 25/07/2023 08:12, Shengjiu Wang wrote: Audio signal processing has the requirement for memory to memory similar as Video. This patch is to add this support in v4l2 framework, defined new buffer type V4L2_BUF_TYPE_AUDIO_CAPTURE and V4L2_BUF_TYPE_AUDIO_OUTPUT, defined new format v4l2_audio_format for audio case usage. The created audio device is named "/dev/audioX". And add memory to memory support for two kinds of i.MX ASRC module >>> >>> Before I spend time on this: are the audio maintainers OK with doing >>> this in V4L2? >>> >>> I do want to have a clear statement on this as it is not something I >>> can decide. >> >> Well, I personally don't mind to have some audio capability in v4l2 >> layer. But, the only uncertain thing for now is whether this is a >> must-have or not. >> > > Thanks, I am also not sure about this. I am also confused that why > there is no m2m implementation for audio in the kernel. Audio also > has similar decoder encoder post-processing as video. > >> >> IIRC, the implementation in the sound driver side was never done just >> because there was no similar implementation? If so, and if the >> extension to the v4l2 core layer is needed, shouldn't it be more >> considered for the possible other route? >> > > Actually I'd like someone could point me to the other route. I'd like to > try. > > The reason why I select to extend v4l2 for such audio usage is that v4l2 > looks best for this audio m2m implementation. v4l2 is designed for m2m > usage. if we need implement another 'route', I don't think it can do better > that v4l2. > > I appreciate that someone can share his ideas or doable solutions. > And please don't ignore my request, ignore my patch. To give a bit more background: if it is decided to use the v4l API for this (and I have no objection to this from my side since API/framework-wise it is a good fit for this), then there are a number of things that need to be done to get this into the media subsystem: - documentation for the new uAPI - add support for this to v4l2-ctl - add v4l2-compliance tests for the new device - highly desirable: have a virtual driver (similar to vim2m) that supports this: it could be as simple as just copy input to output. This helps regression testing. - it might need media controller support as well. TBD. None of this is particularly complex, but taken all together it is a fair amount of work that also needs a lot of review time from our side. I want to add one more option to the mix: drivers/media/core/v4l2-mem2mem.c is the main m2m framework, but it relies heavily on the videobuf2 framework for the capture and output queues. The core vb2 implementation in drivers/media/common/videobuf2/videobuf2-core.c is independent of V4L2 and can be used by other subsystems (in our case, it is also used by the DVB API). It is a possibility to create an alsa version of v4l2-mem2mem.c that uses the core vb2 code with an ALSA uAPI on top. So in drivers/media/common/videobuf2/ you would have a videobuf2-alsa.c besides the already existing videobuf2-v4l2.c and -dvb.c. Perhaps parts of v4l2-mem2mem.c can be reused as well in that case, but I am not sure if it is worth the effort. I suspect copying it to an alsa-mem2mem.c and adapting it for alsa is easiest if you want to go that way. Regards, Hans
Re: [PATCH] powerpc: Use shared font data
"Dr. David Alan Gilbert" writes:
> * Michael Ellerman (m...@ellerman.id.au) wrote:
>> li...@treblig.org writes:
>> > From: "Dr. David Alan Gilbert"
>> >
>> > PowerPC has a 'btext' font used for the console which is almost identical
>> > to the shared font_sun8x16, so use it rather than duplicating the data.
>> >
>> > They were actually identical until about a decade ago when
>> >commit bcfbeecea11c ("drivers: console: font_: Change a glyph from
>> > "broken bar" to "vertical line"")
>> >
>> > which changed the | in the shared font to be a solid
>> > bar rather than a broken bar. That's the only difference.
>> >
>> > This was originally spotted by PMD which noticed that sparc does
>>
>> PMD means "Page Middle Directory" to most Linux folks, I assume that's
>> not what you meant :)
>
> Ah, any good TLA is ripe for reuse:
>https://pmd.github.io/pmd/pmd_userdocs_cpd.html
Thanks.
Unfortunately this patch causes a warning:
WARNING: unmet direct dependencies detected for FONT_SUN8x16
Depends on [n]: FONT_SUPPORT [=y] && FRAMEBUFFER_CONSOLE [=y] && (!SPARC &&
FONTS [=n] || SPARC)
Selected by [y]:
- BOOTX_TEXT [=y] && PPC_BOOK3S [=y]
And breaks allmodconfig with:
ld: arch/powerpc/kernel/btext.o:(.toc+0x0): undefined reference to
`font_sun_8x16'
make[3]: *** [../scripts/Makefile.vmlinux:36: vmlinux] Error 1
I guess the Kconfig logic needs some more work.
cheers
Re: [RFC PATCH v2 0/7] Add audio support in v4l2 framework
On Wed, Aug 02, 2023 at 08:02:29PM +0800, Shengjiu Wang wrote: > On Wed, Aug 2, 2023 at 7:22 PM Takashi Iwai wrote: > > Well, I personally don't mind to have some audio capability in v4l2 > > layer. But, the only uncertain thing for now is whether this is a > > must-have or not. > Thanks, I am also not sure about this. I am also confused that why > there is no m2m implementation for audio in the kernel. Audio also > has similar decoder encoder post-processing as video. This is the thing where we've been trying to persuade people to work on replacing DPCM with full componentisation for about a decade now but nobody's had time other than Morimoto-san who's been chipping away at making everything component based for a good chunk of that time. One trick is that we don't just want this to work for things that are memory to memory, we also want things where there's a direct interconnect that bypasses memory for off-SoC case. > The reason why I select to extend v4l2 for such audio usage is that v4l2 > looks best for this audio m2m implementation. v4l2 is designed for m2m > usage. if we need implement another 'route', I don't think it can do better > that v4l2. > I appreciate that someone can share his ideas or doable solutions. > And please don't ignore my request, ignore my patch. There's a bunch of presentations Lars-Peter did at ELC some considerable time ago about this. signature.asc Description: PGP signature
Re: [RFC PATCH v2 0/7] Add audio support in v4l2 framework
On Wed, 02 Aug 2023 14:02:29 +0200, Shengjiu Wang wrote: > > On Wed, Aug 2, 2023 at 7:22 PM Takashi Iwai wrote: > > > > On Wed, 02 Aug 2023 09:32:37 +0200, > > Hans Verkuil wrote: > > > > > > Hi all, > > > > > > On 25/07/2023 08:12, Shengjiu Wang wrote: > > > > Audio signal processing has the requirement for memory to > > > > memory similar as Video. > > > > > > > > This patch is to add this support in v4l2 framework, defined > > > > new buffer type V4L2_BUF_TYPE_AUDIO_CAPTURE and > > > > V4L2_BUF_TYPE_AUDIO_OUTPUT, defined new format v4l2_audio_format > > > > for audio case usage. > > > > > > > > The created audio device is named "/dev/audioX". > > > > > > > > And add memory to memory support for two kinds of i.MX ASRC > > > > module > > > > > > Before I spend time on this: are the audio maintainers OK with doing > > > this in V4L2? > > > > > > I do want to have a clear statement on this as it is not something I > > > can decide. > > > > Well, I personally don't mind to have some audio capability in v4l2 > > layer. But, the only uncertain thing for now is whether this is a > > must-have or not. > > > > Thanks, I am also not sure about this. I am also confused that why > there is no m2m implementation for audio in the kernel. Audio also > has similar decoder encoder post-processing as video. > > > > > IIRC, the implementation in the sound driver side was never done just > > because there was no similar implementation? If so, and if the > > extension to the v4l2 core layer is needed, shouldn't it be more > > considered for the possible other route? > > > > Actually I'd like someone could point me to the other route. I'd like to > try. > > The reason why I select to extend v4l2 for such audio usage is that v4l2 > looks best for this audio m2m implementation. v4l2 is designed for m2m > usage. if we need implement another 'route', I don't think it can do better > that v4l2. > > I appreciate that someone can share his ideas or doable solutions. > And please don't ignore my request, ignore my patch. Can you explain a bit more details of your demand? At least, a "big picture" showing how your hardware is implemented and what is exactly necessary would be helpful for understanding the problem. thanks, Takashi
Re: [RFC PATCH v2 0/7] Add audio support in v4l2 framework
On Wed, Aug 2, 2023 at 7:22 PM Takashi Iwai wrote: > > On Wed, 02 Aug 2023 09:32:37 +0200, > Hans Verkuil wrote: > > > > Hi all, > > > > On 25/07/2023 08:12, Shengjiu Wang wrote: > > > Audio signal processing has the requirement for memory to > > > memory similar as Video. > > > > > > This patch is to add this support in v4l2 framework, defined > > > new buffer type V4L2_BUF_TYPE_AUDIO_CAPTURE and > > > V4L2_BUF_TYPE_AUDIO_OUTPUT, defined new format v4l2_audio_format > > > for audio case usage. > > > > > > The created audio device is named "/dev/audioX". > > > > > > And add memory to memory support for two kinds of i.MX ASRC > > > module > > > > Before I spend time on this: are the audio maintainers OK with doing > > this in V4L2? > > > > I do want to have a clear statement on this as it is not something I > > can decide. > > Well, I personally don't mind to have some audio capability in v4l2 > layer. But, the only uncertain thing for now is whether this is a > must-have or not. > Thanks, I am also not sure about this. I am also confused that why there is no m2m implementation for audio in the kernel. Audio also has similar decoder encoder post-processing as video. > > IIRC, the implementation in the sound driver side was never done just > because there was no similar implementation? If so, and if the > extension to the v4l2 core layer is needed, shouldn't it be more > considered for the possible other route? > Actually I'd like someone could point me to the other route. I'd like to try. The reason why I select to extend v4l2 for such audio usage is that v4l2 looks best for this audio m2m implementation. v4l2 is designed for m2m usage. if we need implement another 'route', I don't think it can do better that v4l2. I appreciate that someone can share his ideas or doable solutions. And please don't ignore my request, ignore my patch. Best regards Wang shengjiu
Re: [PATCH 0/7] Rework perf and ptrace watchpoint tracking
Christophe Leroy writes: > Le 01/08/2023 à 03:17, Benjamin Gray a écrit : >> Syzkaller triggered a null pointer dereference in the >> arch_unregister_hw_breakpoint() hook. This is due to accessing >> the bp->ctx->task field changing to -1 while we iterate the breakpoints. >> >> This series refactors the breakpoint tracking logic to remove the >> dependency on bp->ctx entirely. It also simplifies handling of ptrace and >> perf breakpoints, making insertion less restrictive. > > Is there any link between this series and the following issue: > https://github.com/linuxppc/issues/issues/38 AFAIK no, Ben started looking at the breakpoint code due to a syzkaller report of an oops. But this series would resolve that issue AFAICS, so I guess they are linked in that sense. cheers
Re: [RFC PATCH v2 0/7] Add audio support in v4l2 framework
On Wed, 02 Aug 2023 09:32:37 +0200, Hans Verkuil wrote: > > Hi all, > > On 25/07/2023 08:12, Shengjiu Wang wrote: > > Audio signal processing has the requirement for memory to > > memory similar as Video. > > > > This patch is to add this support in v4l2 framework, defined > > new buffer type V4L2_BUF_TYPE_AUDIO_CAPTURE and > > V4L2_BUF_TYPE_AUDIO_OUTPUT, defined new format v4l2_audio_format > > for audio case usage. > > > > The created audio device is named "/dev/audioX". > > > > And add memory to memory support for two kinds of i.MX ASRC > > module > > Before I spend time on this: are the audio maintainers OK with doing > this in V4L2? > > I do want to have a clear statement on this as it is not something I > can decide. Well, I personally don't mind to have some audio capability in v4l2 layer. But, the only uncertain thing for now is whether this is a must-have or not. IIRC, the implementation in the sound driver side was never done just because there was no similar implementation? If so, and if the extension to the v4l2 core layer is needed, shouldn't it be more considered for the possible other route? thanks, Takashi
Re: [next-20230731] Kdump fails to capture vmcore (powerpc)
On 31/07/23 7:39 pm, Sachin Sant wrote: Kernel Crash dump(kdump) and firmware assisted dump on powerpc fails to capture vmcore on recent linux-next builds. Starting Kdump Vmcore Save Service... systemd[1]: Starting Kdump Vmcore Save Service... kdump[599]: Kdump is using the default log level(3). kdump[635]: saving to /sysroot/var/crash/127.0.0.1-2023-07-31-09:01:28/ kdump[639]: Remounting the dump target in rw mode. kdump[643]: saving vmcore-dmesg.txt to /sysroot/var/crash/127.0.0.1-2023-07-31-09:01:28/ kdump[649]: saving vmcore-dmesg.txt complete kdump[651]: saving vmcore kdump.sh[652]: readpage_elf: Attempt to read non-existent page at 0x4000. kdump.sh[652]: readmem: type_addr: 0, addr:0, size:8 kdump.sh[652]: get_vmemmap_list_info: Can't get vmemmap region addresses kdump.sh[652]: get_machdep_info_ppc64: Can't get vmemmap list info. kdump.sh[652]: makedumpfile Failed. kdump[654]: saving vmcore failed, exitcode:1 kdump[656]: saving the /run/initramfs/kexec-dmesg.log to /sysroot/var/crash/127.0.0.1-2023-07-31-09:01:28// kdump[663]: saving vmcore failed systemd[1]: kdump-capture.service: Main process exited, code=exited, status=1/FAILURE systemd[1]: kdump-capture.service: Failed with result 'exit-code'. systemd[1]: Failed to start Kdump Vmcore Save Service. [FAILED] Failed to start Kdump Vmcore Save Service. Git bisect points to following patch: 8dc9a0ad0c3e7f43e4e091e4e24634e21ce17a54 is the first bad commit commit 8dc9a0ad0c3e7f43e4e091e4e24634e21ce17a54 powerpc/book3s64/vmemmap: switch radix to use a different vmemmap handling function Earlier, makedumpfile made use of vmemmap_list to populate all the vmemmap regions but that changed for radix. It uses the init_mm pgtable for vmemmap regions. A fix is needed in makedumpfile to catch up with the above change. Thanks Hari
Re: [RFC PATCH v2 0/7] Add audio support in v4l2 framework
Hi all,
On 25/07/2023 08:12, Shengjiu Wang wrote:
> Audio signal processing has the requirement for memory to
> memory similar as Video.
>
> This patch is to add this support in v4l2 framework, defined
> new buffer type V4L2_BUF_TYPE_AUDIO_CAPTURE and
> V4L2_BUF_TYPE_AUDIO_OUTPUT, defined new format v4l2_audio_format
> for audio case usage.
>
> The created audio device is named "/dev/audioX".
>
> And add memory to memory support for two kinds of i.MX ASRC
> module
Before I spend time on this: are the audio maintainers OK with doing
this in V4L2?
I do want to have a clear statement on this as it is not something I
can decide.
Regards,
Hans
>
> changes in v2:
> - decouple the implementation in v4l2 and ALSA
> - implement the memory to memory driver as a platfrom driver
> and move it to driver/media
> - move fsl_asrc_common.h to include/sound folder
>
> Shengjiu Wang (7):
> ASoC: fsl_asrc: define functions for memory to memory usage
> ASoC: fsl_easrc: define functions for memory to memory usage
> ASoC: fsl_asrc: move fsl_asrc_common.h to include/sound
> media: v4l2: Add audio capture and output support
> media: imx: fsl_asrc: Add memory to memory driver
> ASoC: fsl_asrc: register m2m platform device
> ASoC: fsl_easrc: register m2m platform device
>
> .../media/common/videobuf2/videobuf2-v4l2.c | 4 +
> drivers/media/platform/nxp/Kconfig| 12 +
> drivers/media/platform/nxp/Makefile | 1 +
> drivers/media/platform/nxp/fsl_asrc_m2m.c | 962 ++
> drivers/media/v4l2-core/v4l2-dev.c| 17 +
> drivers/media/v4l2-core/v4l2-ioctl.c | 52 +
> include/media/v4l2-dev.h | 2 +
> include/media/v4l2-ioctl.h| 34 +
> .../fsl => include/sound}/fsl_asrc_common.h | 48 +
> include/uapi/linux/videodev2.h| 19 +
> sound/soc/fsl/fsl_asrc.c | 150 +++
> sound/soc/fsl/fsl_asrc.h | 4 +-
> sound/soc/fsl/fsl_asrc_dma.c | 2 +-
> sound/soc/fsl/fsl_easrc.c | 227 +
> sound/soc/fsl/fsl_easrc.h | 8 +-
> 15 files changed, 1539 insertions(+), 3 deletions(-)
> create mode 100644 drivers/media/platform/nxp/fsl_asrc_m2m.c
> rename {sound/soc/fsl => include/sound}/fsl_asrc_common.h (63%)
>
Re: [RFC PATCH v2 4/7] media: v4l2: Add audio capture and output support
On Tue, Aug 1, 2023 at 6:47 PM Shengjiu Wang wrote:
>
> On Fri, Jul 28, 2023 at 3:59 PM Tomasz Figa wrote:
> >
> > Hi Shengjiu,
> >
> > On Tue, Jul 25, 2023 at 02:12:17PM +0800, Shengjiu Wang wrote:
> > > Audio signal processing has the requirement for memory to
> > > memory similar as Video.
> > >
> > > This patch is to add this support in v4l2 framework, defined
> > > new buffer type V4L2_BUF_TYPE_AUDIO_CAPTURE and
> > > V4L2_BUF_TYPE_AUDIO_OUTPUT, defined new format v4l2_audio_format
> > > for audio case usage.
> > >
> > > The created audio device is named "/dev/audioX".
> > >
> > > Signed-off-by: Shengjiu Wang
> > > ---
> > > .../media/common/videobuf2/videobuf2-v4l2.c | 4 ++
> > > drivers/media/v4l2-core/v4l2-dev.c| 17 ++
> > > drivers/media/v4l2-core/v4l2-ioctl.c | 52 +++
> > > include/media/v4l2-dev.h | 2 +
> > > include/media/v4l2-ioctl.h| 34
> > > include/uapi/linux/videodev2.h| 19 +++
> > > 6 files changed, 128 insertions(+)
> > >
> >
> > Thanks for the patch! Please check my comments inline.
>
> Thanks for reviewing.
>
> Sorry for sending again for using the plain text mode.
>
> >
> > > diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c
> > > b/drivers/media/common/videobuf2/videobuf2-v4l2.c
> > > index c7a54d82a55e..12f2be2773a2 100644
> > > --- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
> > > +++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
> > > @@ -785,6 +785,10 @@ int vb2_create_bufs(struct vb2_queue *q, struct
> > > v4l2_create_buffers *create)
> > > case V4L2_BUF_TYPE_META_OUTPUT:
> > > requested_sizes[0] = f->fmt.meta.buffersize;
> > > break;
> > > + case V4L2_BUF_TYPE_AUDIO_CAPTURE:
> > > + case V4L2_BUF_TYPE_AUDIO_OUTPUT:
> > > + requested_sizes[0] = f->fmt.audio.buffersize;
> > > + break;
> > > default:
> > > return -EINVAL;
> > > }
> > > diff --git a/drivers/media/v4l2-core/v4l2-dev.c
> > > b/drivers/media/v4l2-core/v4l2-dev.c
> > > index f81279492682..67484f4c6eaf 100644
> > > --- a/drivers/media/v4l2-core/v4l2-dev.c
> > > +++ b/drivers/media/v4l2-core/v4l2-dev.c
> > > @@ -553,6 +553,7 @@ static void determine_valid_ioctls(struct
> > > video_device *vdev)
> > > bool is_tch = vdev->vfl_type == VFL_TYPE_TOUCH;
> > > bool is_meta = vdev->vfl_type == VFL_TYPE_VIDEO &&
> > > (vdev->device_caps & meta_caps);
> > > + bool is_audio = vdev->vfl_type == VFL_TYPE_AUDIO;
> > > bool is_rx = vdev->vfl_dir != VFL_DIR_TX;
> > > bool is_tx = vdev->vfl_dir != VFL_DIR_RX;
> > > bool is_io_mc = vdev->device_caps & V4L2_CAP_IO_MC;
> > > @@ -664,6 +665,19 @@ static void determine_valid_ioctls(struct
> > > video_device *vdev)
> > > SET_VALID_IOCTL(ops, VIDIOC_S_FMT, vidioc_s_fmt_meta_out);
> > > SET_VALID_IOCTL(ops, VIDIOC_TRY_FMT,
> > > vidioc_try_fmt_meta_out);
> > > }
> > > + if (is_audio && is_rx) {
> > > + /* audio capture specific ioctls */
> > > + SET_VALID_IOCTL(ops, VIDIOC_ENUM_FMT,
> > > vidioc_enum_fmt_audio_cap);
> > > + SET_VALID_IOCTL(ops, VIDIOC_G_FMT, vidioc_g_fmt_audio_cap);
> > > + SET_VALID_IOCTL(ops, VIDIOC_S_FMT, vidioc_s_fmt_audio_cap);
> > > + SET_VALID_IOCTL(ops, VIDIOC_TRY_FMT,
> > > vidioc_try_fmt_audio_cap);
> > > + } else if (is_audio && is_tx) {
> > > + /* audio output specific ioctls */
> > > + SET_VALID_IOCTL(ops, VIDIOC_ENUM_FMT,
> > > vidioc_enum_fmt_audio_out);
> > > + SET_VALID_IOCTL(ops, VIDIOC_G_FMT, vidioc_g_fmt_audio_out);
> > > + SET_VALID_IOCTL(ops, VIDIOC_S_FMT, vidioc_s_fmt_audio_out);
> > > + SET_VALID_IOCTL(ops, VIDIOC_TRY_FMT,
> > > vidioc_try_fmt_audio_out);
> > > + }
> > > if (is_vbi) {
> > > /* vbi specific ioctls */
> > > if ((is_rx && (ops->vidioc_g_fmt_vbi_cap ||
> > > @@ -927,6 +941,9 @@ int __video_register_device(struct video_device *vdev,
> > > case VFL_TYPE_TOUCH:
> > > name_base = "v4l-touch";
> > > break;
> > > + case VFL_TYPE_AUDIO:
> > > + name_base = "audio";
> >
> > I think it was mentioned before that "audio" could be confusing. Wasn't
> > there actually some other kind of /dev/audio device long ago?
> >
> > Seems like for touch, "v4l-touch" was introduced. Maybe it would also
> > make sense to call it "v4l-audio" for audio?
>
> Ok, will change to use "v4l-audio".
>
> >
> > > + break;
> > > default:
> > > pr_err("%s called with unknown type: %d\n",
> > > __func__, type);
> > > diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
> > > b/drivers/media/v4l2-core/v4l2-ioctl.c
> > > index 01ba27f2ef87..aa9d872bba8d 100644
> > > ---
Re: [PATCH v2 0/3] Update the register list of MICFIL
On Wed, Aug 2, 2023 at 1:21 PM Chancel Liu wrote: > > MICFIL IP is upgraded on i.MX93 platform. Add new registers and new bit > definition. > > changes in v2: > - rename check_version to use_verid to make it more explicit > - rename fsl_micfil_check_version to fsl_micfil_use_verid > > > Chancel Liu (3): > ASoC: fsl_micfil: Add new registers and new bit definition > ASoC: fsl_micfil: Add fsl_micfil_use_verid function > ASoC: fsl_micfil: Use SET_SYSTEM_SLEEP_PM_OPS to simplify PM > Acked-by: Shengjiu Wang Best regards Wang Shengjiu > sound/soc/fsl/fsl_micfil.c | 100 ++--- > sound/soc/fsl/fsl_micfil.h | 64 > 2 files changed, 146 insertions(+), 18 deletions(-) > > -- > 2.25.1 >
