Re: [PATCH v4 13/18] memory: mtk-smi: Add bus_sel for mt8183
On Sat, Dec 8, 2018 at 4:43 PM Yong Wu wrote:
>
> There are 2 mmu cells in a M4U HW. we could adjust some larbs entering
> mmu0 or mmu1 to balance the bandwidth via the smi-common register
> SMI_BUS_SEL(0x220)(Each larb occupy 2 bits).
>
> In mt8183, For better performance, we switch larb1/2/5/7 to enter
> mmu1 while the others still keep enter mmu0.
>
> In mt8173 and mt2712, we don't get the performance issue,
> Keep its default value(0x0), that means all the larbs enter mmu0.
>
> Signed-off-by: Yong Wu
> ---
> drivers/memory/mtk-smi.c | 22 --
> 1 file changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
> index ee6165e..88eb61a 100644
> --- a/drivers/memory/mtk-smi.c
> +++ b/drivers/memory/mtk-smi.c
> @@ -49,6 +49,12 @@
> #define SMI_LARB_NONSEC_CON(id)(0x380 + ((id) * 4))
> #define F_MMU_EN BIT(0)
>
> +/* SMI COMMON */
> +#define SMI_BUS_SEL0x220
> +#define SMI_BUS_LARB_SHIFT(larbid) ((larbid) << 1)
> +/* All are MMU0 defaultly. Only specialize mmu1 here. */
> +#define F_MMU1_LARB(larbid)(0x1 << SMI_BUS_LARB_SHIFT(larbid))
> +
> enum mtk_smi_gen {
> MTK_SMI_GEN1,
> MTK_SMI_GEN2
> @@ -57,6 +63,7 @@ enum mtk_smi_gen {
> struct mtk_smi_common_plat {
> enum mtk_smi_gen gen;
> bool has_gals;
> + u32 bus_sel; /* Balance some larbs to enter mmu0 or mmu1
> */
> };
>
> struct mtk_smi_larb_gen {
> @@ -72,8 +79,8 @@ struct mtk_smi {
> struct clk *clk_apb, *clk_smi;
> struct clk *clk_gals0, *clk_gals1;
> struct clk *clk_async; /*only needed by mt2701*/
> - void __iomem*smi_ao_base;
> -
> + void __iomem*smi_ao_base; /* only for gen1 */
> + void __iomem*base;/* only for gen2 */
> const struct mtk_smi_common_plat *plat;
> };
>
> @@ -409,6 +416,8 @@ static int __maybe_unused mtk_smi_larb_suspend(struct
> device *dev)
> static const struct mtk_smi_common_plat mtk_smi_common_mt8183 = {
> .gen = MTK_SMI_GEN2,
> .has_gals = true,
> + .bus_sel = F_MMU1_LARB(1) | F_MMU1_LARB(2) | F_MMU1_LARB(5) |
> + F_MMU1_LARB(7),
Maybe it's ok for now, but I wonder if this is something that should
be specified in device tree? Maybe different applications will want
different larb split between MMU0 and MMU1?
> };
>
> static const struct of_device_id mtk_smi_common_of_ids[] = {
> @@ -481,6 +490,11 @@ static int mtk_smi_common_probe(struct platform_device
> *pdev)
> ret = clk_prepare_enable(common->clk_async);
> if (ret)
> return ret;
> + } else {
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + common->base = devm_ioremap_resource(dev, res);
> + if (IS_ERR(common->base))
> + return PTR_ERR(common->base);
> }
> pm_runtime_enable(dev);
> platform_set_drvdata(pdev, common);
> @@ -496,6 +510,7 @@ static int mtk_smi_common_remove(struct platform_device
> *pdev)
> static int __maybe_unused mtk_smi_common_resume(struct device *dev)
> {
> struct mtk_smi *common = dev_get_drvdata(dev);
> + u32 bus_sel = common->plat->bus_sel;
> int ret;
>
> ret = mtk_smi_clk_enable(common);
> @@ -503,6 +518,9 @@ static int __maybe_unused mtk_smi_common_resume(struct
> device *dev)
> dev_err(common->dev, "Failed to enable clock(%d).\n", ret);
> return ret;
> }
> +
> + if (common->plat->gen == MTK_SMI_GEN2 && bus_sel)
> + writel(bus_sel, common->base + SMI_BUS_SEL);
> return 0;
> }
>
> --
> 1.9.1
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v4 10/18] iommu/mediatek: Add mt8183 IOMMU support
On Sat, Dec 8, 2018 at 4:42 PM Yong Wu wrote:
>
> The M4U IP blocks in mt8183 is MediaTek's generation2 M4U which use
> the ARM Short-descriptor like mt8173, and most of the HW registers
> are the same.
>
> Here list main differences between mt8183 and mt8173/mt2712:
> 1) mt8183 has only one M4U HW like mt8173 while mt2712 has two.
> 2) mt8183 don't have the "bclk" clock, it use the EMI clock instead.
> 3) mt8183 can support the dram over 4GB, but it doesn't call this "4GB
> mode".
> 4) mt8183 pgtable base register(0x0) extend bit[1:0] which represent
> the bit[33:32] in the physical address of the pgtable base, But the
> standard ttbr0[1] means the S bit which is enabled defaultly, Hence,
> we add a mask.
> 5) mt8183 HW has a GALS modules, SMI should enable "has_gals" support.
> 6) the larb-id in smi-common is remapped. M4U should enable
> larbid_remapped support.
>
> Signed-off-by: Yong Wu
> ---
> drivers/iommu/mtk_iommu.c | 31 ++-
> drivers/iommu/mtk_iommu.h | 1 +
> drivers/memory/mtk-smi.c | 19 +++
> 3 files changed, 42 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 8ab3b69..d91a554 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -36,6 +36,7 @@
> #include "mtk_iommu.h"
>
> #define REG_MMU_PT_BASE_ADDR 0x000
> +#define MMU_PT_ADDR_MASK GENMASK(31, 7)
>
> #define REG_MMU_INVALIDATE 0x020
> #define F_ALL_INVLD0x2
> @@ -54,7 +55,7 @@
> #define REG_MMU_CTRL_REG 0x110
> #define F_MMU_PREFETCH_RT_REPLACE_MOD BIT(4)
> #define F_MMU_TF_PROTECT_SEL_SHIFT(data) \
> - ((data)->plat_data->m4u_plat == M4U_MT2712 ? 4 : 5)
> + ((data)->plat_data->m4u_plat == M4U_MT8173 ? 5 : 4)
Should the shift value be a member of plat_data instead?
> /* It's named by F_MMU_TF_PROT_SEL in mt2712. */
> #define F_MMU_TF_PROTECT_SEL(prot, data) \
> (((prot) & 0x3) << F_MMU_TF_PROTECT_SEL_SHIFT(data))
> @@ -347,7 +348,7 @@ static int mtk_iommu_attach_device(struct iommu_domain
> *domain,
> /* Update the pgtable base address register of the M4U HW */
> if (!data->m4u_dom) {
> data->m4u_dom = dom;
> - writel(dom->cfg.arm_v7s_cfg.ttbr[0],
> + writel(dom->cfg.arm_v7s_cfg.ttbr[0] & MMU_PT_ADDR_MASK,
>data->base + REG_MMU_PT_BASE_ADDR);
> }
>
> @@ -510,6 +511,7 @@ static int mtk_iommu_of_xlate(struct device *dev, struct
> of_phandle_args *args)
>
> static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
> {
> + enum mtk_iommu_plat m4u_plat = data->plat_data->m4u_plat;
> u32 regval;
> int ret;
>
> @@ -520,7 +522,7 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data
> *data)
> }
>
> regval = F_MMU_TF_PROTECT_SEL(2, data);
> - if (data->plat_data->m4u_plat == M4U_MT8173)
> + if (m4u_plat == M4U_MT8173)
> regval |= F_MMU_PREFETCH_RT_REPLACE_MOD;
> writel_relaxed(regval, data->base + REG_MMU_CTRL_REG);
>
> @@ -541,14 +543,14 @@ static int mtk_iommu_hw_init(const struct
> mtk_iommu_data *data)
> F_INT_PRETETCH_TRANSATION_FIFO_FAULT;
> writel_relaxed(regval, data->base + REG_MMU_INT_MAIN_CONTROL);
>
> - if (data->plat_data->m4u_plat == M4U_MT8173)
> + if (m4u_plat == M4U_MT8173)
> regval = (data->protect_base >> 1) | (data->enable_4GB << 31);
> else
> regval = lower_32_bits(data->protect_base) |
> upper_32_bits(data->protect_base);
> writel_relaxed(regval, data->base + REG_MMU_IVRP_PADDR);
>
> - if (data->enable_4GB && data->plat_data->m4u_plat != M4U_MT8173) {
> + if (data->enable_4GB && m4u_plat == M4U_MT2712) {
> /*
> * If 4GB mode is enabled, the validate PA range is from
> * 0x1__ to 0x1__. here record bit[32:30].
> @@ -558,8 +560,11 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data
> *data)
> }
> writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
>
> - /* It's MISC control register whose default value is ok except
> mt8173.*/
> - if (data->plat_data->m4u_plat == M4U_MT8173)
> + /*
> +* It's MISC control register whose default value is ok
> +* except mt8173 and mt8183.
> +*/
> + if (m4u_plat == M4U_MT8173 || m4u_plat == M4U_MT8183)
Again, should this be a field in plat_data?
> writel_relaxed(0, data->base + REG_MMU_STANDARD_AXI_MODE);
>
> if (devm_request_irq(data->dev, data->irq, mtk_iommu_isr, 0,
> @@ -713,6 +718,7 @@ static int __maybe_unused mtk_iommu_resume(struct device
> *dev)
> {
> struct mtk_iommu_data *data = dev_get_drvdata(dev);
> struct mtk_iommu_suspend_reg
Re: [PATCH v4 08/18] iommu/mediatek: Add larb-id remapped support
On Sat, Dec 8, 2018 at 4:42 PM Yong Wu wrote:
>
> The larb-id may be remapped in the smi-common, this means the
> larb-id reported in the mtk_iommu_isr isn't the real larb-id,
>
> Take mt8183 as a example:
>M4U
> |
> -
> | SMI common |
> -0-7-5-6-1-2--3-4- <- Id remapped
> | | | | | | | |
> larb0 larb1 IPU0 IPU1 larb4 larb5 larb6 CCU
> disp vdec img cam venc imgcam
> As above, larb0 connects with the id 0 in smi-common.
> larb1 connects with the id 7 in smi-common.
> ...
> If the larb-id reported in the isr is 7, actually it's larb1(vdec).
> In order to output the right larb-id in the isr, we add a larb-id
> remapping relationship in this patch.
>
> This also is a preparing patch for mt8183.
>
> Signed-off-by: Yong Wu
> ---
> drivers/iommu/mtk_iommu.c | 3 +++
> drivers/iommu/mtk_iommu.h | 4
> 2 files changed, 7 insertions(+)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index eda062a..8ab3b69 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -220,6 +220,9 @@ static irqreturn_t mtk_iommu_isr(int irq, void *dev_id)
> fault_larb = F_MMU0_INT_ID_LARB_ID(regval);
> fault_port = F_MMU0_INT_ID_PORT_ID(regval);
>
> + if (data->plat_data->larbid_remap_enable)
> + fault_larb = data->plat_data->larbid_remapped[fault_larb];
> +
> if (report_iommu_fault(>domain, data->dev, fault_iova,
>write ? IOMMU_FAULT_WRITE : IOMMU_FAULT_READ))
> {
> dev_err_ratelimited(
> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> index b8749ac..3877050 100644
> --- a/drivers/iommu/mtk_iommu.h
> +++ b/drivers/iommu/mtk_iommu.h
> @@ -47,6 +47,10 @@ struct mtk_iommu_plat_data {
>
> /* HW will use the EMI clock if there isn't the "bclk". */
> boolhas_bclk;
> +
> + /* The larb-id may be remapped in the smi-common. */
> + boollarbid_remap_enable;
> + unsigned intlarbid_remapped[MTK_LARB_NR_MAX];
Wouldn't it be a little simpler if you just had
larbid_remap[MTK_LARB_NR_MAX] (no larbid_remap_enable), and just set
it to {0, 1, 2, 3, 4, 5, 6, 7} in platforms that don't need
complicated remapping?
Also, unsigned char/u8 array would be enough.
> };
>
> struct mtk_iommu_domain;
> --
> 1.9.1
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v6 0/7] Add virtio-iommu driver
On Thu, Dec 20, 2018 at 05:59:46PM +, Jean-Philippe Brucker wrote: > On 19/12/2018 23:09, Michael S. Tsirkin wrote: > > On Thu, Dec 13, 2018 at 12:50:29PM +, Jean-Philippe Brucker wrote: > [3] git://linux-arm.org/linux-jpb.git virtio-iommu/v0.9.1 > git://linux-arm.org/kvmtool-jpb.git virtio-iommu/v0.9 > >>> > >>> Unfortunatly gitweb seems to be broken on linux-arm.org. What is missing > >>> in this patch-set to make this work on x86? > >> > >> You should be able to access it here: > >> http://www.linux-arm.org/git?p=linux-jpb.git;a=shortlog;h=refs/heads/virtio-iommu/devel > >> > >> That branch contains missing bits for x86 support: > >> > >> * ACPI support. We have the code but it's waiting for an IORT spec > >> update, to reserve the IORT node ID. I expect it to take a while, given > >> that I'm alone requesting a change for something that's not upstream or > >> in hardware. > > > > Frankly I think you should take a hard look at just getting the data > > needed from the PCI device itself. You don't need to depend on virtio, > > it can be a small driver that gets you that data from the device config > > space and then just goes away. > > > > If you want help with writing such a small driver let me know. > > > > If there's an advantage to virtio-iommu then that would be its > > portability, and it all goes out of the window because > > of dependencies on ACPI and DT and OF and the rest of the zoo. > > But the portable solutions are ACPI and DT. > > Describing the DMA dependency through a device would require the guest > to probe the device before all others. How do we communicate this? > * pass a kernel parameter saying something like "probe_first=00:01.0" > * make sure that the PCI root complex is probed before any other > platform device (since the IOMMU can manage DMA of platform devices). My idea was to just find and probe the specific device. > * change DT, ACPI and PCI core code to handle this probe_first kernel > parameter. > > Better go with something standard, that any OS and hypervisor knows how > to use, and that other IOMMU devices already use. > > >> * DMA ops for x86 (see "HACK" commit). I'd like to use dma-iommu but I'm > >> not sure how to implement the glue that sets dma_ops properly. > >> > >> Thanks, > >> Jean > > > > OK so IIUC you are looking into Christoph's suggestions to fix that up? > > Eventually yes. I'll give it a try next year, once the dma-iommu changes > are on the list. It's not a priority for me, given that x86 already has > a pvIOMMU with VT-d, and that Arm still needs one. Well that's a kind of a weak usecase, isn't it? Can we just build VTD on ARM? diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig index d9a25715650e..009fa98e9363 100644 --- a/drivers/iommu/Kconfig +++ b/drivers/iommu/Kconfig @@ -174,7 +174,7 @@ config DMAR_TABLE config INTEL_IOMMU bool "Support for Intel IOMMU using DMA Remapping Devices" - depends on PCI_MSI && ACPI && (X86 || IA64_GENERIC) + depends on PCI_MSI && ACPI && (X86 || IA64_GENERIC || ARM) select IOMMU_API select IOMMU_IOVA select NEED_DMA_MAP_STATE didn't try this one ... > It shouldn't block > this series. > > > There's still a bit of time left before the merge window, > > maybe you can make above changes. > > I'll wait to see if Joerg has other concerns about the design or the > code, and resend in January. I think that IOMMU driver changes should go > through his tree. > > Thanks, > Jean Sorry which changes do you mean? -- MST ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
next/master boot bisection: next-20181220 on tegra124-nyan-big
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This automated bisection report was sent to you on the basis *
* that you may be involved with the breaking commit it has *
* found. No manual investigation has been done to verify it, *
* and the root cause of the problem may be somewhere else. *
* Hope this helps! *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
next/master boot bisection: next-20181220 on tegra124-nyan-big
Summary:
Start: 1efde6eb1819 Add linux-next specific files for 20181220
Details:https://kernelci.org/boot/id/5c1b9ce459b514bfcd0a8184
Plain log:
https://storage.kernelci.org//next/master/next-20181220/arm/tegra_defconfig/lab-collabora/boot-tegra124-nyan-big.txt
HTML log:
https://storage.kernelci.org//next/master/next-20181220/arm/tegra_defconfig/lab-collabora/boot-tegra124-nyan-big.html
Result: 641fb0efbff0 iommu/of: Don't call iommu_ops->add_device directly
Checks:
revert: PASS
verify: PASS
Parameters:
Tree: next
URL:http://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
Branch: master
Target: tegra124-nyan-big
CPU arch: arm
Lab:lab-collabora
Config: tegra_defconfig
Test suite: boot
Breaking commit found:
---
commit 641fb0efbff063ed57f108c2eb4a4d26dbd5badd
Author: Joerg Roedel
Date: Wed Dec 5 14:39:45 2018 +0100
iommu/of: Don't call iommu_ops->add_device directly
Make sure to invoke this call-back through the proper
function of the IOMMU-API.
Signed-off-by: Joerg Roedel
diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index dbe73456f1a1..d8947b28db2d 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -222,10 +222,10 @@ const struct iommu_ops *of_iommu_configure(struct device
*dev,
}
/*
* If we have reason to believe the IOMMU driver missed the initial
-* add_device callback for dev, replay it to get things in order.
+* probe for dev, replay it to get things in order.
*/
- if (ops && ops->add_device && dev->bus && !device_iommu_mapped(dev))
- err = ops->add_device(dev);
+ if (dev->bus && !device_iommu_mapped(dev))
+ err = iommu_probe_device(dev);
/* Ignore all other errors apart from EPROBE_DEFER */
if (err == -EPROBE_DEFER) {
---
Git bisection log:
---
git bisect start
# good: [c5c08bed843c2b2c048c16d1296d7631d7c1620e] virtio: fix test build after
uio.h change
git bisect good c5c08bed843c2b2c048c16d1296d7631d7c1620e
# bad: [1efde6eb181908e1095b4a5db90af0c024016bec] Add linux-next specific files
for 20181220
git bisect bad 1efde6eb181908e1095b4a5db90af0c024016bec
# good: [6580aac4d9913a22e269d7df8db1f9efb8d7fe14] Merge remote-tracking branch
'crypto/master'
git bisect good 6580aac4d9913a22e269d7df8db1f9efb8d7fe14
# bad: [75f962d8fe5279ac9e64f3d411b8e38b84da8d6b] Merge remote-tracking branch
'spi/for-next'
git bisect bad 75f962d8fe5279ac9e64f3d411b8e38b84da8d6b
# good: [d675ba4b9e6ccd782e4db9109cbab708a85b8ff8] Merge tag
'drm-msm-next-2018-12-12' of git://people.freedesktop.org/~robclark/linux into
drm-next
git bisect good d675ba4b9e6ccd782e4db9109cbab708a85b8ff8
# good: [6173f57441f9c05050aad441a2188eaabbfea7a0] Merge remote-tracking branch
'block/for-next'
git bisect good 6173f57441f9c05050aad441a2188eaabbfea7a0
# good: [1531a9f0415ba8ea0f4e31d6f5a1ef059d19dc6d] Merge remote-tracking branch
'regulator/for-next'
git bisect good 1531a9f0415ba8ea0f4e31d6f5a1ef059d19dc6d
# bad: [e2267b2875b0798814d0a76a304318e0c6d60c3e] Merge remote-tracking branch
'vfio/next'
git bisect bad e2267b2875b0798814d0a76a304318e0c6d60c3e
# good: [96ae0a1f40d405f8f0221f4fa8b9b2ef4bbbc01e] Merge remote-tracking branch
'watchdog/master'
git bisect good 96ae0a1f40d405f8f0221f4fa8b9b2ef4bbbc01e
# bad: [d2e1a003af569e912d5f115a3c20b89a19f5caa0] ACPI/IORT: Don't call
iommu_ops->add_device directly
git bisect bad d2e1a003af569e912d5f115a3c20b89a19f5caa0
# good: [9b468f7d9cf1f089b7287865776eb100504681b7] iommu/arm-smmu: Use helper
functions to access dev->iommu_fwspec
git bisect good 9b468f7d9cf1f089b7287865776eb100504681b7
# good: [170ecbd5ff09aa9c8c1025a8563f76e01a24bb50] iommu/of: Use
device_iommu_mapped()
git bisect good 170ecbd5ff09aa9c8c1025a8563f76e01a24bb50
# good: [f884f6ee62604aec60fe1760f94724be192d97c0] dmaengine: sh: rcar-dmac:
Use device_iommu_mapped()
git bisect good f884f6ee62604aec60fe1760f94724be192d97c0
# good: [cc5aed44a3a8e4fca721636cf881a52f8d68a098] iommu: Consolitate
->add/remove_device() calls
git
Re: ensure dma_alloc_coherent always returns zeroed memory
Btw, can you try wit the very latests dma-mapping-for-next tree which has a new fix from Thierry Reding that might be related. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v6 0/7] Add virtio-iommu driver
On 19/12/2018 23:09, Michael S. Tsirkin wrote: > On Thu, Dec 13, 2018 at 12:50:29PM +, Jean-Philippe Brucker wrote: [3] git://linux-arm.org/linux-jpb.git virtio-iommu/v0.9.1 git://linux-arm.org/kvmtool-jpb.git virtio-iommu/v0.9 >>> >>> Unfortunatly gitweb seems to be broken on linux-arm.org. What is missing >>> in this patch-set to make this work on x86? >> >> You should be able to access it here: >> http://www.linux-arm.org/git?p=linux-jpb.git;a=shortlog;h=refs/heads/virtio-iommu/devel >> >> That branch contains missing bits for x86 support: >> >> * ACPI support. We have the code but it's waiting for an IORT spec >> update, to reserve the IORT node ID. I expect it to take a while, given >> that I'm alone requesting a change for something that's not upstream or >> in hardware. > > Frankly I think you should take a hard look at just getting the data > needed from the PCI device itself. You don't need to depend on virtio, > it can be a small driver that gets you that data from the device config > space and then just goes away. > > If you want help with writing such a small driver let me know. > > If there's an advantage to virtio-iommu then that would be its > portability, and it all goes out of the window because > of dependencies on ACPI and DT and OF and the rest of the zoo. But the portable solutions are ACPI and DT. Describing the DMA dependency through a device would require the guest to probe the device before all others. How do we communicate this? * pass a kernel parameter saying something like "probe_first=00:01.0" * make sure that the PCI root complex is probed before any other platform device (since the IOMMU can manage DMA of platform devices). * change DT, ACPI and PCI core code to handle this probe_first kernel parameter. Better go with something standard, that any OS and hypervisor knows how to use, and that other IOMMU devices already use. >> * DMA ops for x86 (see "HACK" commit). I'd like to use dma-iommu but I'm >> not sure how to implement the glue that sets dma_ops properly. >> >> Thanks, >> Jean > > OK so IIUC you are looking into Christoph's suggestions to fix that up? Eventually yes. I'll give it a try next year, once the dma-iommu changes are on the list. It's not a priority for me, given that x86 already has a pvIOMMU with VT-d, and that Arm still needs one. It shouldn't block this series. > There's still a bit of time left before the merge window, > maybe you can make above changes. I'll wait to see if Joerg has other concerns about the design or the code, and resend in January. I think that IOMMU driver changes should go through his tree. Thanks, Jean ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 15/15] dma-mapping: bypass indirect calls for dma-direct
On Thu, Dec 20, 2018 at 05:44:18PM +0100, Thierry Reding wrote:
> On Fri, Dec 07, 2018 at 11:07:20AM -0800, Christoph Hellwig wrote:
> [...]
> > diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
> > index 0b18cfbdde95..fc84c81029d9 100644
> > --- a/kernel/dma/mapping.c
> > +++ b/kernel/dma/mapping.c
> [...]
> > @@ -397,9 +404,9 @@ int dma_supported(struct device *dev, u64 mask)
> > {
> > const struct dma_map_ops *ops = get_dma_ops(dev);
> >
> > - if (!ops)
> > - return 0;
> > - if (!ops->dma_supported)
> > + if (dma_is_direct(ops))
> > + return dma_direct_supported(dev, mask);
> > + if (ops->dma_supported)
> > return 1;
> > return ops->dma_supported(dev, mask);
> > }
>
> Hi Christoph,
>
> This hunk causes a crash on boot for me. It looks like a ! got lost in
> the rework here. The following patch fixes the crash for me and restores
> the logic of the op->dma_supported check.
>
> Feel free to squash this patch into the above if you prefer that.
I don't want to rebase, so I'll pick this up ASAP.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 15/15] dma-mapping: bypass indirect calls for dma-direct
On Fri, Dec 07, 2018 at 11:07:20AM -0800, Christoph Hellwig wrote:
[...]
> diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
> index 0b18cfbdde95..fc84c81029d9 100644
> --- a/kernel/dma/mapping.c
> +++ b/kernel/dma/mapping.c
[...]
> @@ -397,9 +404,9 @@ int dma_supported(struct device *dev, u64 mask)
> {
> const struct dma_map_ops *ops = get_dma_ops(dev);
>
> - if (!ops)
> - return 0;
> - if (!ops->dma_supported)
> + if (dma_is_direct(ops))
> + return dma_direct_supported(dev, mask);
> + if (ops->dma_supported)
> return 1;
> return ops->dma_supported(dev, mask);
> }
Hi Christoph,
This hunk causes a crash on boot for me. It looks like a ! got lost in
the rework here. The following patch fixes the crash for me and restores
the logic of the op->dma_supported check.
Feel free to squash this patch into the above if you prefer that.
Thierry
--- >8 ---
From c502b29ab01fa857e81c78cd574d4d22d7d20e09 Mon Sep 17 00:00:00 2001
From: Thierry Reding
Date: Thu, 20 Dec 2018 17:35:47 +0100
Subject: [PATCH] dma-mapping: Fix inverted logic in dma_supported()
The cleanup in commit 356da6d0cde3 ("dma-mapping: bypass indirect calls
for dma-direct") accidentally inverted the logic in the check for the
presence of a ->dma_supported() callback. Switch this back to the way it
was to prevent a crash on boot.
Fixes: 356da6d0cde3 ("dma-mapping: bypass indirect calls for dma-direct")
Signed-off-by: Thierry Reding
---
kernel/dma/mapping.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index fc84c81029d9..d7c34d2d1ba5 100644
--- a/kernel/dma/mapping.c
+++ b/kernel/dma/mapping.c
@@ -406,7 +406,7 @@ int dma_supported(struct device *dev, u64 mask)
if (dma_is_direct(ops))
return dma_direct_supported(dev, mask);
- if (ops->dma_supported)
+ if (!ops->dma_supported)
return 1;
return ops->dma_supported(dev, mask);
}
--
2.19.1
signature.asc
Description: PGP signature
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] Fix typo. Change tlb_range_add to iotlb_range_add and tlb_sync to iotlb_sync
Ah shoot, it looks like I forgot to change flush_tlb_all -> flush_iotlb_all Should I submit another patch? On Wed, 5 Dec 2018 at 16:04, Joerg Roedel wrote: > > On Tue, Dec 04, 2018 at 06:27:34PM +, Tom Murphy wrote: > > From: tom > > > > Someone forgot to update this comment. > > > > Signed-off-by: Tom Murphy > > --- > > include/linux/iommu.h | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 3/4] iommu/of: Don't call iommu_ops->add_device directly
Hi Jörg,
On Wed, Dec 19, 2018 at 5:51 PM Joerg Roedel wrote:
> On Wed, Dec 19, 2018 at 10:54:18AM +0100, Marek Szyprowski wrote:
> > On 2018-12-11 16:05, Joerg Roedel wrote:
> > > From: Joerg Roedel
> > >
> > > Make sure to invoke this call-back through the proper
> > > function of the IOMMU-API.
> > >
> > > Signed-off-by: Joerg Roedel
> > > ---
> > > drivers/iommu/of_iommu.c | 6 +++---
> > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> > > index c5dd63072529..4d4847de727e 100644
> > > --- a/drivers/iommu/of_iommu.c
> > > +++ b/drivers/iommu/of_iommu.c
> > > @@ -218,10 +218,10 @@ const struct iommu_ops *of_iommu_configure(struct
> > > device *dev,
> > > ops = dev->iommu_fwspec->ops;
> > > /*
> > > * If we have reason to believe the IOMMU driver missed the initial
> > > -* add_device callback for dev, replay it to get things in order.
> > > +* probe for dev, replay it to get things in order.
> > > */
> > > - if (ops && ops->add_device && dev->bus && !dev->iommu_group)
> > > - err = ops->add_device(dev);
> > > + if (dev->bus && !dev->iommu_group)
> > > + err = iommu_probe_device(dev);
> >
> > This change removes a check for NULL ops, what causes NULL pointer
> > exception on first device without IOMMU.
>
> Bummer, this check was supposed to be in iommu_probe_device(), but
> apparently it got lost. Does the attached patch fix it?
>
> > I'm also not sure if this is a good idea to call iommu_probe_device(),
> > which comes from dev->bus->iommu_ops, which might be different from ops
> > from local variable.
>
> The local variable comes from dev->iommu_fwspec->ops, which should be
> exactly the same as dev->bus->iommu_ops. I'll leave that for now until
> it turns out to be a problem (which I don't expect).
>
>
> Regards,
>
> Joerg
>
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index a2131751dcff..3ed4db334341 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -114,10 +114,14 @@ void iommu_device_unregister(struct iommu_device *iommu)
> int iommu_probe_device(struct device *dev)
> {
> const struct iommu_ops *ops = dev->bus->iommu_ops;
> + int ret = -EINVAL;
>
> WARN_ON(dev->iommu_group);
>
> - return ops->add_device(dev);
> + if (ops)
Is this sufficient? The old code checked for ops->add_device != NULL,
too.
> + ret = ops->add_device(dev);
> +
> + return ret;
> }
>
> void iommu_release_device(struct device *dev)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 2/2] ACPI / scan: Refactor _CCA enforcement
On Fri, Dec 07, 2018 at 04:31:35PM +, Robin Murphy wrote:
> Rather than checking the DMA attribute at each callsite, just pass it
> through for acpi_dma_configure() to handle directly. That can then deal
> with the relatively exceptional DEV_DMA_NOT_SUPPORTED case by explicitly
> installing dummy DMA ops instead of just skipping setup entirely. This
> will then free up the dev->dma_ops == NULL case for some valuable
> fastpath optimisations.
>
> CC: Rafael J. Wysocki
> CC: Len Brown
> CC: Greg Kroah-Hartman
> CC: Bjorn Helgaas
> Signed-off-by: Robin Murphy
FWIW, if this hasn't been applied already (I think you targeted a DMA
tree):
Acked-by: Bjorn Helgaas
> ---
> drivers/acpi/scan.c | 5 +
> drivers/base/platform.c | 3 +--
> drivers/pci/pci-driver.c | 3 +--
> 3 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index bd1c59fb0e17..b75ae34ed188 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -1456,6 +1456,11 @@ int acpi_dma_configure(struct device *dev, enum
> dev_dma_attr attr)
> const struct iommu_ops *iommu;
> u64 dma_addr = 0, size = 0;
>
> + if (attr == DEV_DMA_NOT_SUPPORTED) {
> + set_dma_ops(dev, _dummy_ops);
> + return 0;
> + }
> +
> iort_dma_setup(dev, _addr, );
>
> iommu = iort_iommu_configure(dev);
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index 41b91af95afb..c6daca875c17 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -1138,8 +1138,7 @@ int platform_dma_configure(struct device *dev)
> ret = of_dma_configure(dev, dev->of_node, true);
> } else if (has_acpi_companion(dev)) {
> attr = acpi_get_dma_attr(to_acpi_device_node(dev->fwnode));
> - if (attr != DEV_DMA_NOT_SUPPORTED)
> - ret = acpi_dma_configure(dev, attr);
> + ret = acpi_dma_configure(dev, attr);
> }
>
> return ret;
> diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
> index bef17c3fca67..f899a28b90f8 100644
> --- a/drivers/pci/pci-driver.c
> +++ b/drivers/pci/pci-driver.c
> @@ -1602,8 +1602,7 @@ static int pci_dma_configure(struct device *dev)
> struct acpi_device *adev = to_acpi_device_node(bridge->fwnode);
> enum dev_dma_attr attr = acpi_get_dma_attr(adev);
>
> - if (attr != DEV_DMA_NOT_SUPPORTED)
> - ret = acpi_dma_configure(dev, attr);
> + ret = acpi_dma_configure(dev, attr);
> }
>
> pci_put_host_bridge_device(bridge);
> --
> 2.19.1.dirty
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: ensure dma_alloc_coherent always returns zeroed memory
On Thu, Dec 20, 2018 at 02:39:20PM +, Eugeniy Paltsev wrote: > > I would be really surprised if that is caused by the patch to add > > the zeroing. > Me too :) > > > Can you check which commit caused the issue by bisecting > > from a known good baseline? > > Yep. At least kernel build from v4.20-rc4 (which is base for your branch) > seems to work fine. Well, the branch has quite a few commits. Can you check the commit just before the zeroing to start, and if that is already broken (which I suspect) bisect the offending commit? ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: ensure dma_alloc_coherent always returns zeroed memory
Hi Christoph, I test kernel from your 'dma-alloc-always-zero' branch, and as I can see we have DMA peripherals (like USB) broken. There are the errors example I got during USB initializing: -->8 usb 1-1: device descriptor read/64, error -110 usb usb1-port1: attempt power cycle usb 1-1: new high-speed USB device number 4 using ehci-platform usb 1-1: device descriptor read/64, error -110 usb 1-1: device descriptor read/64, error -110 usb 1-1: new high-speed USB device number 5 using ehci-platform usb 1-1: device descriptor read/64, error -110 usb 1-1: device descriptor read/64, error -110 usb usb1-port1: unable to enumerate USB device usb 2-1: new full-speed USB device number 2 using ohci-platform usb 2-1: device descriptor read/all, error -84 usb 2-1: new full-speed USB device number 3 using ohci-platform usb 2-1: device descriptor read/all, error -84 usb usb2-port1: attempt power cycle usb 2-1: new full-speed USB device number 4 using ohci-platform usb 2-1: device descriptor read/8, error -62 usb 2-1: device descriptor read/8, error -62 usb 2-1: new full-speed USB device number 5 using ohci-platform usb 2-1: device descriptor read/8, error -84 usb 2-1: device descriptor read/8, error -84 usb usb2-port1: unable to enumerate USB device [snip] --8< On Wed, 2018-12-19 at 17:59 +0100, Christoph Hellwig wrote: > FYI, I've picked this up for dma-mapping for-next now. > > ___ > linux-snps-arc mailing list > linux-snps-...@lists.infradead.org > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_mailman_listinfo_linux-2Dsnps-2Darc=DwICAg=DPL6_X_6JkXFx7AXWqB0tg=ZlJN > 1MriPUTkBKCrPSx67GmaplEUGcAEk9yPtCLdUXI=naBCT96A4RSQJLzBWzuCcmptFGiQDfFTOWJpprqDIVk=cHF84va89ofP6VlrV683ewENUXdaLW7opamLZSkZBgk= -- Eugeniy Paltsev ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: ensure dma_alloc_coherent always returns zeroed memory
On Thu, 2018-12-20 at 15:34 +0100, h...@lst.de wrote: > On Thu, Dec 20, 2018 at 02:32:52PM +, Eugeniy Paltsev wrote: > > Hi Christoph, > > > > I test kernel from your 'dma-alloc-always-zero' branch, and as > > I can see we have DMA peripherals (like USB) broken. > > I would be really surprised if that is caused by the patch to add > the zeroing. Me too :) > Can you check which commit caused the issue by bisecting > from a known good baseline? Yep. At least kernel build from v4.20-rc4 (which is base for your branch) seems to work fine. -- Eugeniy Paltsev ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: ensure dma_alloc_coherent always returns zeroed memory
On Thu, Dec 20, 2018 at 02:32:52PM +, Eugeniy Paltsev wrote: > Hi Christoph, > > I test kernel from your 'dma-alloc-always-zero' branch, and as > I can see we have DMA peripherals (like USB) broken. I would be really surprised if that is caused by the patch to add the zeroing. Can you check which commit caused the issue by bisecting from a known good baseline? ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 3/4] iommu/of: Don't call iommu_ops->add_device directly
Hi Marek, On Wed, Dec 19, 2018 at 03:53:51PM +0100, Marek Szyprowski wrote: > Yes, it fixes this issue. Thanks a lot, patch is sent out and in iommu tree. Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH] iommu: Check for iommu_ops == NULL in iommu_probe_device()
From: Joerg Roedel
This check needs to be there and got lost at some point
during development. Add it again.
Fixes: 641fb0efbff0 ('iommu/of: Don't call iommu_ops->add_device directly')
Reported-by: Marek Szyprowski
Reported-by: kernelci.org bot
Signed-off-by: Joerg Roedel
---
drivers/iommu/iommu.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index a2131751dcff..3ed4db334341 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -114,10 +114,14 @@ void iommu_device_unregister(struct iommu_device *iommu)
int iommu_probe_device(struct device *dev)
{
const struct iommu_ops *ops = dev->bus->iommu_ops;
+ int ret = -EINVAL;
WARN_ON(dev->iommu_group);
- return ops->add_device(dev);
+ if (ops)
+ ret = ops->add_device(dev);
+
+ return ret;
}
void iommu_release_device(struct device *dev)
--
2.13.7
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next/master boot bisection: next-20181219 on r8a7796-m3ulcb
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This automated bisection report was sent to you on the basis *
* that you may be involved with the breaking commit it has *
* found. No manual investigation has been done to verify it, *
* and the root cause of the problem may be somewhere else. *
* Hope this helps! *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
next/master boot bisection: next-20181219 on r8a7796-m3ulcb
Summary:
Start: 02fc169594e9 Add linux-next specific files for 20181219
Details:https://kernelci.org/boot/id/5c1a262459b51498440a8181
Plain log:
https://storage.kernelci.org//next/master/next-20181219/arm64/defconfig/lab-baylibre/boot-r8a7796-m3ulcb.txt
HTML log:
https://storage.kernelci.org//next/master/next-20181219/arm64/defconfig/lab-baylibre/boot-r8a7796-m3ulcb.html
Result: 641fb0efbff0 iommu/of: Don't call iommu_ops->add_device directly
Checks:
revert: PASS
verify: PASS
Parameters:
Tree: next
URL:http://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
Branch: master
Target: r8a7796-m3ulcb
CPU arch: arm64
Lab:lab-baylibre
Config: defconfig
Test suite: boot
Breaking commit found:
---
commit 641fb0efbff063ed57f108c2eb4a4d26dbd5badd
Author: Joerg Roedel
Date: Wed Dec 5 14:39:45 2018 +0100
iommu/of: Don't call iommu_ops->add_device directly
Make sure to invoke this call-back through the proper
function of the IOMMU-API.
Signed-off-by: Joerg Roedel
diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index dbe73456f1a1..d8947b28db2d 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -222,10 +222,10 @@ const struct iommu_ops *of_iommu_configure(struct device
*dev,
}
/*
* If we have reason to believe the IOMMU driver missed the initial
-* add_device callback for dev, replay it to get things in order.
+* probe for dev, replay it to get things in order.
*/
- if (ops && ops->add_device && dev->bus && !device_iommu_mapped(dev))
- err = ops->add_device(dev);
+ if (dev->bus && !device_iommu_mapped(dev))
+ err = iommu_probe_device(dev);
/* Ignore all other errors apart from EPROBE_DEFER */
if (err == -EPROBE_DEFER) {
---
Git bisection log:
---
git bisect start
# good: [ddfbab46539f2d37a9e9d357b054486b51f7dc27] Merge tag 'scsi-fixes' of
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
git bisect good ddfbab46539f2d37a9e9d357b054486b51f7dc27
# bad: [02fc169594e96f7c51c4f23114e12b7a18e85a0a] Add linux-next specific files
for 20181219
git bisect bad 02fc169594e96f7c51c4f23114e12b7a18e85a0a
# good: [423ff56561dc1c3fdd7c51a6697cc30b8d18d49a] Merge remote-tracking branch
'mtd/mtd/next'
git bisect good 423ff56561dc1c3fdd7c51a6697cc30b8d18d49a
# bad: [232006e511f040f8089f6112916434b0de707c89] Merge remote-tracking branch
'audit/next'
git bisect bad 232006e511f040f8089f6112916434b0de707c89
# good: [02c4fb0210dc2773e0d7f0a5a1b866986f8edc40] Merge branch 'linux-4.21' of
git://github.com/skeggsb/linux into drm-next
git bisect good 02c4fb0210dc2773e0d7f0a5a1b866986f8edc40
# good: [7a934f6040a2002e0cbd5507b3b6608537344525] Merge remote-tracking branch
'input/next'
git bisect good 7a934f6040a2002e0cbd5507b3b6608537344525
# good: [36357a3d5a9be1fef1d7ede3bf90bf470bdbbf9f] Merge remote-tracking branch
'device-mapper/for-next'
git bisect good 36357a3d5a9be1fef1d7ede3bf90bf470bdbbf9f
# good: [a85d704d06d9643c5fb3a13744653d6b36c12f8b] Merge remote-tracking branch
'regulator/for-next'
git bisect good a85d704d06d9643c5fb3a13744653d6b36c12f8b
# good: [d5530f072a98f3956a1fc91d800ad85a27c4509b] Merge remote-tracking branch
'watchdog/master'
git bisect good d5530f072a98f3956a1fc91d800ad85a27c4509b
# bad: [d2e1a003af569e912d5f115a3c20b89a19f5caa0] ACPI/IORT: Don't call
iommu_ops->add_device directly
git bisect bad d2e1a003af569e912d5f115a3c20b89a19f5caa0
# good: [9b468f7d9cf1f089b7287865776eb100504681b7] iommu/arm-smmu: Use helper
functions to access dev->iommu_fwspec
git bisect good 9b468f7d9cf1f089b7287865776eb100504681b7
# good: [170ecbd5ff09aa9c8c1025a8563f76e01a24bb50] iommu/of: Use
device_iommu_mapped()
git bisect good 170ecbd5ff09aa9c8c1025a8563f76e01a24bb50
# good: [f884f6ee62604aec60fe1760f94724be192d97c0] dmaengine: sh: rcar-dmac:
Use device_iommu_mapped()
git bisect good f884f6ee62604aec60fe1760f94724be192d97c0
# good: [cc5aed44a3a8e4fca721636cf881a52f8d68a098] iommu: Consolitate
->add/remove_device() calls
git bisect good cc5aed44a3a8e4fca721636cf881a52f8d68a098
# bad:
next/master boot bisection: next-20181219 on synquacer-dtb
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This automated bisection report was sent to you on the basis *
* that you may be involved with the breaking commit it has *
* found. No manual investigation has been done to verify it, *
* and the root cause of the problem may be somewhere else. *
* Hope this helps! *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
next/master boot bisection: next-20181219 on synquacer-dtb
Summary:
Start: 02fc169594e9 Add linux-next specific files for 20181219
Details:https://kernelci.org/boot/id/5c1a268c59b51498440a81ae
Plain log:
https://storage.kernelci.org//next/master/next-20181219/arm64/defconfig/lab-mhart/boot-synquacer-dtb.txt
HTML log:
https://storage.kernelci.org//next/master/next-20181219/arm64/defconfig/lab-mhart/boot-synquacer-dtb.html
Result: 641fb0efbff0 iommu/of: Don't call iommu_ops->add_device directly
Checks:
revert: PASS
verify: PASS
Parameters:
Tree: next
URL:http://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
Branch: master
Target: synquacer-dtb
CPU arch: arm64
Lab:lab-mhart
Config: defconfig
Test suite: boot
Breaking commit found:
---
commit 641fb0efbff063ed57f108c2eb4a4d26dbd5badd
Author: Joerg Roedel
Date: Wed Dec 5 14:39:45 2018 +0100
iommu/of: Don't call iommu_ops->add_device directly
Make sure to invoke this call-back through the proper
function of the IOMMU-API.
Signed-off-by: Joerg Roedel
diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index dbe73456f1a1..d8947b28db2d 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -222,10 +222,10 @@ const struct iommu_ops *of_iommu_configure(struct device
*dev,
}
/*
* If we have reason to believe the IOMMU driver missed the initial
-* add_device callback for dev, replay it to get things in order.
+* probe for dev, replay it to get things in order.
*/
- if (ops && ops->add_device && dev->bus && !device_iommu_mapped(dev))
- err = ops->add_device(dev);
+ if (dev->bus && !device_iommu_mapped(dev))
+ err = iommu_probe_device(dev);
/* Ignore all other errors apart from EPROBE_DEFER */
if (err == -EPROBE_DEFER) {
---
Git bisection log:
---
git bisect start
# good: [ddfbab46539f2d37a9e9d357b054486b51f7dc27] Merge tag 'scsi-fixes' of
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
git bisect good ddfbab46539f2d37a9e9d357b054486b51f7dc27
# bad: [02fc169594e96f7c51c4f23114e12b7a18e85a0a] Add linux-next specific files
for 20181219
git bisect bad 02fc169594e96f7c51c4f23114e12b7a18e85a0a
# good: [423ff56561dc1c3fdd7c51a6697cc30b8d18d49a] Merge remote-tracking branch
'mtd/mtd/next'
git bisect good 423ff56561dc1c3fdd7c51a6697cc30b8d18d49a
# bad: [232006e511f040f8089f6112916434b0de707c89] Merge remote-tracking branch
'audit/next'
git bisect bad 232006e511f040f8089f6112916434b0de707c89
# good: [02c4fb0210dc2773e0d7f0a5a1b866986f8edc40] Merge branch 'linux-4.21' of
git://github.com/skeggsb/linux into drm-next
git bisect good 02c4fb0210dc2773e0d7f0a5a1b866986f8edc40
# good: [7a934f6040a2002e0cbd5507b3b6608537344525] Merge remote-tracking branch
'input/next'
git bisect good 7a934f6040a2002e0cbd5507b3b6608537344525
# good: [36357a3d5a9be1fef1d7ede3bf90bf470bdbbf9f] Merge remote-tracking branch
'device-mapper/for-next'
git bisect good 36357a3d5a9be1fef1d7ede3bf90bf470bdbbf9f
# good: [a85d704d06d9643c5fb3a13744653d6b36c12f8b] Merge remote-tracking branch
'regulator/for-next'
git bisect good a85d704d06d9643c5fb3a13744653d6b36c12f8b
# good: [d5530f072a98f3956a1fc91d800ad85a27c4509b] Merge remote-tracking branch
'watchdog/master'
git bisect good d5530f072a98f3956a1fc91d800ad85a27c4509b
# bad: [d2e1a003af569e912d5f115a3c20b89a19f5caa0] ACPI/IORT: Don't call
iommu_ops->add_device directly
git bisect bad d2e1a003af569e912d5f115a3c20b89a19f5caa0
# good: [9b468f7d9cf1f089b7287865776eb100504681b7] iommu/arm-smmu: Use helper
functions to access dev->iommu_fwspec
git bisect good 9b468f7d9cf1f089b7287865776eb100504681b7
# good: [170ecbd5ff09aa9c8c1025a8563f76e01a24bb50] iommu/of: Use
device_iommu_mapped()
git bisect good 170ecbd5ff09aa9c8c1025a8563f76e01a24bb50
# good: [f884f6ee62604aec60fe1760f94724be192d97c0] dmaengine: sh: rcar-dmac:
Use device_iommu_mapped()
git bisect good f884f6ee62604aec60fe1760f94724be192d97c0
# good: [cc5aed44a3a8e4fca721636cf881a52f8d68a098] iommu: Consolitate
->add/remove_device() calls
git bisect good cc5aed44a3a8e4fca721636cf881a52f8d68a098
# bad:
next/master boot bisection: next-20181219 on rk3399-gru-kevin
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This automated bisection report was sent to you on the basis *
* that you may be involved with the breaking commit it has *
* found. No manual investigation has been done to verify it, *
* and the root cause of the problem may be somewhere else. *
* Hope this helps! *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
next/master boot bisection: next-20181219 on rk3399-gru-kevin
Summary:
Start: 02fc169594e9 Add linux-next specific files for 20181219
Details:https://kernelci.org/boot/id/5c1a267359b51498440a81ab
Plain log:
https://storage.kernelci.org//next/master/next-20181219/arm64/defconfig/lab-collabora/boot-rk3399-gru-kevin.txt
HTML log:
https://storage.kernelci.org//next/master/next-20181219/arm64/defconfig/lab-collabora/boot-rk3399-gru-kevin.html
Result: 641fb0efbff0 iommu/of: Don't call iommu_ops->add_device directly
Checks:
revert: PASS
verify: PASS
Parameters:
Tree: next
URL:http://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
Branch: master
Target: rk3399-gru-kevin
CPU arch: arm64
Lab:lab-collabora
Config: defconfig
Test suite: boot
Breaking commit found:
---
commit 641fb0efbff063ed57f108c2eb4a4d26dbd5badd
Author: Joerg Roedel
Date: Wed Dec 5 14:39:45 2018 +0100
iommu/of: Don't call iommu_ops->add_device directly
Make sure to invoke this call-back through the proper
function of the IOMMU-API.
Signed-off-by: Joerg Roedel
diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index dbe73456f1a1..d8947b28db2d 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -222,10 +222,10 @@ const struct iommu_ops *of_iommu_configure(struct device
*dev,
}
/*
* If we have reason to believe the IOMMU driver missed the initial
-* add_device callback for dev, replay it to get things in order.
+* probe for dev, replay it to get things in order.
*/
- if (ops && ops->add_device && dev->bus && !device_iommu_mapped(dev))
- err = ops->add_device(dev);
+ if (dev->bus && !device_iommu_mapped(dev))
+ err = iommu_probe_device(dev);
/* Ignore all other errors apart from EPROBE_DEFER */
if (err == -EPROBE_DEFER) {
---
Git bisection log:
---
git bisect start
# good: [ddfbab46539f2d37a9e9d357b054486b51f7dc27] Merge tag 'scsi-fixes' of
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
git bisect good ddfbab46539f2d37a9e9d357b054486b51f7dc27
# bad: [02fc169594e96f7c51c4f23114e12b7a18e85a0a] Add linux-next specific files
for 20181219
git bisect bad 02fc169594e96f7c51c4f23114e12b7a18e85a0a
# good: [423ff56561dc1c3fdd7c51a6697cc30b8d18d49a] Merge remote-tracking branch
'mtd/mtd/next'
git bisect good 423ff56561dc1c3fdd7c51a6697cc30b8d18d49a
# bad: [232006e511f040f8089f6112916434b0de707c89] Merge remote-tracking branch
'audit/next'
git bisect bad 232006e511f040f8089f6112916434b0de707c89
# good: [02c4fb0210dc2773e0d7f0a5a1b866986f8edc40] Merge branch 'linux-4.21' of
git://github.com/skeggsb/linux into drm-next
git bisect good 02c4fb0210dc2773e0d7f0a5a1b866986f8edc40
# good: [7a934f6040a2002e0cbd5507b3b6608537344525] Merge remote-tracking branch
'input/next'
git bisect good 7a934f6040a2002e0cbd5507b3b6608537344525
# good: [36357a3d5a9be1fef1d7ede3bf90bf470bdbbf9f] Merge remote-tracking branch
'device-mapper/for-next'
git bisect good 36357a3d5a9be1fef1d7ede3bf90bf470bdbbf9f
# good: [a85d704d06d9643c5fb3a13744653d6b36c12f8b] Merge remote-tracking branch
'regulator/for-next'
git bisect good a85d704d06d9643c5fb3a13744653d6b36c12f8b
# good: [d5530f072a98f3956a1fc91d800ad85a27c4509b] Merge remote-tracking branch
'watchdog/master'
git bisect good d5530f072a98f3956a1fc91d800ad85a27c4509b
# bad: [d2e1a003af569e912d5f115a3c20b89a19f5caa0] ACPI/IORT: Don't call
iommu_ops->add_device directly
git bisect bad d2e1a003af569e912d5f115a3c20b89a19f5caa0
# good: [9b468f7d9cf1f089b7287865776eb100504681b7] iommu/arm-smmu: Use helper
functions to access dev->iommu_fwspec
git bisect good 9b468f7d9cf1f089b7287865776eb100504681b7
# good: [170ecbd5ff09aa9c8c1025a8563f76e01a24bb50] iommu/of: Use
device_iommu_mapped()
git bisect good 170ecbd5ff09aa9c8c1025a8563f76e01a24bb50
# good: [f884f6ee62604aec60fe1760f94724be192d97c0] dmaengine: sh: rcar-dmac:
Use device_iommu_mapped()
git bisect good f884f6ee62604aec60fe1760f94724be192d97c0
# good: [cc5aed44a3a8e4fca721636cf881a52f8d68a098] iommu: Consolitate
->add/remove_device() calls
git bisect good cc5aed44a3a8e4fca721636cf881a52f8d68a098
# bad:
