Re: [linux-next:master] BUILD REGRESSION 088b9c375534d905a4d337c78db3b3bfbb52c4a0
On Thu, Jul 07, 2022 at 10:08:33AM +0200, Greg KH wrote: [ ... ] > > > > Unverified Error/Warning (likely false positive, please contact us if > > interested): > > > > arch/x86/events/core.c:2114 init_hw_perf_events() warn: missing error code > > 'err' > > drivers/android/binder.c:1481:19-23: ERROR: from is NULL but dereferenced. > > drivers/android/binder.c:2920:29-33: ERROR: target_thread is NULL but > > dereferenced. > > drivers/android/binder.c:353:25-35: ERROR: node -> proc is NULL but > > dereferenced. > > drivers/android/binder.c:4888:16-20: ERROR: t is NULL but dereferenced. > > drivers/base/regmap/regmap.c:1996:1: internal compiler error: in arc_ifcvt, > > at config/arc/arc.c:9637 > > drivers/char/random.c:869:1: internal compiler error: in arc_ifcvt, at > > config/arc/arc.c:9637 > > drivers/firmware/arm_scmi/clock.c:394:1: internal compiler error: in > > arc_ifcvt, at config/arc/arc.c:9637 > > drivers/firmware/arm_scmi/powercap.c:376:1: internal compiler error: in > > arc_ifcvt, at config/arc/arc.c:9637 > > drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_powertune.c:1214:1: > > internal compiler error: in arc_ifcvt, at config/arc/arc.c:9637 > > drivers/gpu/drm/amd/display/dc/os_types.h: drm/drm_print.h is included more > > than once. > > drivers/gpu/drm/bridge/ite-it66121.c:1398:1: internal compiler error: in > > arc_ifcvt, at config/arc/arc.c:9637 > > drivers/greybus/operation.c:617:1: internal compiler error: in arc_ifcvt, > > at config/arc/arc.c:9637 > > > > When the compiler crashes, why are you blaming all of these different > mailing lists? Perhaps you need to fix your compiler :) > To be fair, it says above "likely false positive, please contact us if interested". Also, the 32-bit build errors _are_ real, and the NULL dereferences in the binder driver are at the very least suspicious. Guenter ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 7/7] dt-bindings: watchdog: renesas,wdt: R-Car V3U is R-Car Gen4
On Mon, May 02, 2022 at 03:34:59PM +0200, Geert Uytterhoeven wrote: > Despite the name, R-Car V3U is the first member of the R-Car Gen4 > family. Hence move its compatible value to the R-Car Gen4 section. > > Signed-off-by: Geert Uytterhoeven > Acked-by: Krzysztof Kozlowski > Reviewed-by: Wolfram Sang Reviewed-by: Guenter Roeck > --- > Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml > b/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml > index 77ee7c4b8067f506..1fa243052327bffe 100644 > --- a/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml > +++ b/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml > @@ -59,11 +59,11 @@ properties: >- renesas,r8a77980-wdt # R-Car V3H >- renesas,r8a77990-wdt # R-Car E3 >- renesas,r8a77995-wdt # R-Car D3 > - - renesas,r8a779a0-wdt # R-Car V3U >- const: renesas,rcar-gen3-wdt # R-Car Gen3 and RZ/G2 > >- items: >- enum: > + - renesas,r8a779a0-wdt # R-Car V3U >- renesas,r8a779f0-wdt # R-Car S4-8 >- const: renesas,rcar-gen4-wdt # R-Car Gen4 > ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 1/4] iommu/mediatek: Use dev_err_probe to mute probe_defer err log
On Tue, May 10, 2022 at 11:49 PM Yong Wu wrote:
>
> Mute the probe defer log:
>
> [2.654806] mtk-iommu 14018000.iommu: mm dts parse fail(-517).
> [2.656168] mtk-iommu 1c01f000.iommu: mm dts parse fail(-517).
>
> Fixes: d2e9a1102cfc ("iommu/mediatek: Contain MM IOMMU flow with the MM TYPE")
> Signed-off-by: Yong Wu
Reviewed-by: Guenter Roeck
> ---
> The Fixes tag commit-id is from linux-next.
> ---
> drivers/iommu/mtk_iommu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 71b2ace74cd6..0f6ec4a4d9d4 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -1198,7 +1198,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
> if (MTK_IOMMU_IS_TYPE(data->plat_data, MTK_IOMMU_TYPE_MM)) {
> ret = mtk_iommu_mm_dts_parse(dev, &match, data);
> if (ret) {
> - dev_err(dev, "mm dts parse fail(%d).", ret);
> + dev_err_probe(dev, ret, "mm dts parse fail.");
> goto out_runtime_disable;
> }
> } else if (MTK_IOMMU_IS_TYPE(data->plat_data, MTK_IOMMU_TYPE_INFRA) &&
> --
> 2.18.0
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [patch V3 28/35] PCI/MSI: Simplify pci_irq_get_affinity()
On Mon, Jan 31, 2022 at 10:16:41PM +0100, Thomas Gleixner wrote:
> Guenter,
>
> On Mon, Jan 31 2022 at 07:21, Guenter Roeck wrote:
> > Sure. Please see http://server.roeck-us.net/qemu/x86/.
> > The logs are generated with with v5.16.4.
>
> thanks for providing the data. It definitely helped me to leave the
> state of not seeing the wood for the trees. Fix below.
>
> Thanks,
>
> tglx
> ---
> Subject: PCI/MSI: Remove bogus warning in pci_irq_get_affinity()
> From: Thomas Gleixner
> Date: Mon, 31 Jan 2022 22:02:46 +0100
>
> The recent overhaul of pci_irq_get_affinity() introduced a regression when
> pci_irq_get_affinity() is called for an MSI-X interrupt which was not
> allocated with affinity descriptor information.
>
> The original code just returned a NULL pointer in that case, but the rework
> added a WARN_ON() under the assumption that the corresponding WARN_ON() in
> the MSI case can be applied to MSI-X as well.
>
> In fact the MSI warning in the original code does not make sense either
> because it's legitimate to invoke pci_irq_get_affinity() for a MSI
> interrupt which was not allocated with affinity descriptor information.
>
> Remove it and just return NULL as the original code did.
>
> Fixes: f48235900182 ("PCI/MSI: Simplify pci_irq_get_affinity()")
> Reported-by: Guenter Roeck
> Signed-off-by: Thomas Gleixner
Tested-by: Guenter Roeck
Guenter
> ---
> drivers/pci/msi/msi.c |3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> --- a/drivers/pci/msi/msi.c
> +++ b/drivers/pci/msi/msi.c
> @@ -,7 +,8 @@ const struct cpumask *pci_irq_get_affini
> if (!desc)
> return cpu_possible_mask;
>
> - if (WARN_ON_ONCE(!desc->affinity))
> + /* MSI[X] interrupts can be allocated without affinity descriptor */
> + if (!desc->affinity)
> return NULL;
>
> /*
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [patch V3 28/35] PCI/MSI: Simplify pci_irq_get_affinity()
On 1/31/22 03:27, Thomas Gleixner wrote: On Sun, Jan 30 2022 at 09:12, Guenter Roeck wrote: On Fri, Dec 10, 2021 at 11:19:26PM +0100, Thomas Gleixner wrote: This patch results in the following runtime warning when booting x86 (32 bit) nosmp images from NVME in qemu. [ 14.825482] nvme nvme0: 1/0/0 default/read/poll queues ILLOPC: ca7c6d10: 0f 0b [ 14.826188] [ cut here ] [ 14.826307] WARNING: CPU: 0 PID: 7 at drivers/pci/msi/msi.c:1114 pci_irq_get_affinity+0x80/0x90 This complains about msi_desc->affinity being NULL. git bisect bad f48235900182d64537c6e8f8dc0932b57a1a0638 # first bad commit: [f48235900182d64537c6e8f8dc0932b57a1a0638] PCI/MSI: Simplify pci_irq_get_affinity() Hrm. Can you please provide dmesg and /proc/interrupts from a kernel before that commit? Sure. Please see http://server.roeck-us.net/qemu/x86/. The logs are generated with with v5.16.4. Guenter ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [patch V3 28/35] PCI/MSI: Simplify pci_irq_get_affinity()
On Fri, Dec 10, 2021 at 11:19:26PM +0100, Thomas Gleixner wrote: > From: Thomas Gleixner > > Replace open coded MSI descriptor chasing and use the proper accessor > functions instead. > > Signed-off-by: Thomas Gleixner > Reviewed-by: Greg Kroah-Hartman > Reviewed-by: Jason Gunthorpe This patch results in the following runtime warning when booting x86 (32 bit) nosmp images from NVME in qemu. [ 14.825482] nvme nvme0: 1/0/0 default/read/poll queues ILLOPC: ca7c6d10: 0f 0b [ 14.826188] [ cut here ] [ 14.826307] WARNING: CPU: 0 PID: 7 at drivers/pci/msi/msi.c:1114 pci_irq_get_affinity+0x80/0x90 [ 14.826455] Modules linked in: [ 14.826640] CPU: 0 PID: 7 Comm: kworker/u2:0 Not tainted 5.17.0-rc1-00419-g1d2d8baaf053 #1 [ 14.826797] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 [ 14.827132] Workqueue: nvme-reset-wq nvme_reset_work [ 14.827336] EIP: pci_irq_get_affinity+0x80/0x90 [ 14.827452] Code: e8 d5 30 af ff 85 c0 75 bd 90 0f 0b 31 c0 5b 5e 5d c3 8d b4 26 00 00 00 00 90 5b b8 24 32 7e cb 5e 5d c3 8d b4 26 00 00 00 00 <0f> 0b eb e0 8d b4 26 00 00 00 00 8d 74 26 00 90 55 89 e5 57 56 53 [ 14.827717] EAX: EBX: c18ba000 ECX: EDX: c297c210 [ 14.827816] ESI: 0001 EDI: c18ba000 EBP: c1247e24 ESP: c1247e1c [ 14.827924] DS: 007b ES: 007b FS: GS: SS: 0068 EFLAGS: 0246 [ 14.828110] CR0: 80050033 CR2: ffda9000 CR3: 0b8ad000 CR4: 06d0 [ 14.828268] Call Trace: [ 14.828554] blk_mq_pci_map_queues+0x26/0x70 [ 14.828710] nvme_pci_map_queues+0x75/0xc0 [ 14.828808] blk_mq_update_queue_map+0x86/0xa0 [ 14.828891] blk_mq_alloc_tag_set+0xf3/0x390 [ 14.828965] ? nvme_wait_freeze+0x3d/0x50 [ 14.829137] nvme_reset_work+0xd02/0x1120 [ 14.829269] ? lock_acquire+0xc3/0x290 [ 14.829435] process_one_work+0x1ed/0x490 [ 14.829569] worker_thread+0x15e/0x3c0 [ 14.829665] kthread+0xd3/0x100 [ 14.829729] ? process_one_work+0x490/0x490 [ 14.829799] ? kthread_complete_and_exit+0x20/0x20 [ 14.829890] ret_from_fork+0x1c/0x28 Bisect results below. #regzbot introduced: f48235900182d6 Guenter --- # bad: [e783362eb54cd99b2cac8b3a9aeac942e6f6ac07] Linux 5.17-rc1 # good: [df0cc57e057f18e44dac8e6c18aba47ab53202f9] Linux 5.16 git bisect start 'v5.17-rc1' 'v5.16' # good: [fef8dfaea9d6c444b6c2174b3a2b0fca4d226c5e] Merge tag 'regulator-v5.17' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator git bisect good fef8dfaea9d6c444b6c2174b3a2b0fca4d226c5e # bad: [3ceff4ea07410763d5d4cccd60349bf7691e7e61] Merge tag 'sound-5.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound git bisect bad 3ceff4ea07410763d5d4cccd60349bf7691e7e61 # good: [57ea81971b7296b42fc77424af44c5915d3d4ae2] Merge tag 'usb-5.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb git bisect good 57ea81971b7296b42fc77424af44c5915d3d4ae2 # bad: [feb7a43de5ef625ad74097d8fd3481d5dbc06a59] Merge tag 'irq-msi-2022-01-13' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip git bisect bad feb7a43de5ef625ad74097d8fd3481d5dbc06a59 # good: [ce990f1de0bc6ff3de43d385e0985efa980fba24] Merge tag 'for-linus-5.17-rc1-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip git bisect good ce990f1de0bc6ff3de43d385e0985efa980fba24 # good: [4afd2a9355a9deb16ea42b896820dacf49843a8f] Merge branches 'clk-ingenic' and 'clk-mediatek' into clk-next git bisect good 4afd2a9355a9deb16ea42b896820dacf49843a8f # good: [455e73a07f6e288b0061dfcf4fcf54fa9fe06458] Merge tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux git bisect good 455e73a07f6e288b0061dfcf4fcf54fa9fe06458 # bad: [f2948df5f87a722591499da60ab91c611422f755] x86/pci/xen: Use msi_for_each_desc() git bisect bad f2948df5f87a722591499da60ab91c611422f755 # good: [93296cd1325d1d9afede60202d8833011c9001f2] PCI/MSI: Allocate MSI device data on first use git bisect good 93296cd1325d1d9afede60202d8833011c9001f2 # good: [82ff8e6b78fc4587a4255301f0a283506daf11b6] PCI/MSI: Use msi_get_virq() in pci_get_vector() git bisect good 82ff8e6b78fc4587a4255301f0a283506daf11b6 # bad: [125282cd4f33ecd53a24ae4807409da0e5e90fd4] genirq/msi: Move descriptor list to struct msi_device_data git bisect bad 125282cd4f33ecd53a24ae4807409da0e5e90fd4 # bad: [065afdc9c521f05c53f226dabe5dda2d30294d65] iommu/arm-smmu-v3: Use msi_get_virq() git bisect bad 065afdc9c521f05c53f226dabe5dda2d30294d65 # bad: [f6632bb2c1454b857adcd131320379ec16fd8666] dmaengine: mv_xor_v2: Get rid of msi_desc abuse git bisect bad f6632bb2c1454b857adcd131320379ec16fd8666 # bad: [f48235900182d64537c6e8f8dc0932b57a1a0638] PCI/MSI: Simplify pci_irq_get_affinity() git bisect bad f48235900182d64537c6e8f8dc0932b57a1a0638 # first bad commit: [f48235900182d64537c6e8f8dc0932b57a1a0638] PCI/MSI: Simplify pci_irq_get_affinity() ___ iommu mailing list iommu@lists.linux-foundation.org https://
Re: [SPAM][PATCH] iommu/mediatek: Validate number of phandles associated with "mediatek,larbs"
On Wed, Dec 15, 2021 at 01:30:45PM +0800, Yong Wu wrote:
> On Tue, 2021-12-14 at 07:02 -0800, Guenter Roeck wrote:
> > On 12/13/21 11:31 PM, Yong Wu wrote:
> > > On Fri, 2021-12-10 at 12:57 -0800, Guenter Roeck wrote:
> > > > Since commit baf94e6ebff9 ("iommu/mediatek: Add device link for
> > > > smi-
> > > > common
> > > > and m4u"), the driver assumes that at least one phandle
> > > > associated
> > > > with
> > > > "mediatek,larbs" exists. If that is not the case, for example if
> > > > reason
> > > > "mediatek,larbs" is provided as boolean property, the code will
> > > > use
> > > > an
> > > > uninitialized pointer and may crash. To fix the problem, ensure
> > > > that
> > > > the
> > > > number of phandles associated with "mediatek,larbs" is at least 1
> > > > and
> > > > bail out immediately if that is not the case.
> > >
> > > From the dt-binding, "mediatek,larbs" always is a phandle-array. I
> > > assumed the dts should conform to the dt-binding before. Then the
> > > problem is that if we should cover the case that someone
> > > abuses/attacks
> > > the dts. Could you help add more comment in the commit message?
> > > something like: this is for avoid abuse the dt-binding.
> > >
> >
> > This doesn't have to be an abuse or attack. It can simply be an error
> > by the person who wrote the devicetree file. Sure, bugs or lack of
>
> A minor question: If someone wrote error data that don't conform to the
> dtbinding, the error result is expected. He should fix that problem,
> right? If we could avoid abort and show error message at the beginning,
> it's better of course.
>
Sure. However, such an error should not result in a crash but should be
caught in an error handler.
> > error checking can often be used for attacks, but that doesn't mean
> > that all bad data is an exploit or attack.
> >
> > > >
> > > > Cc: Yong Wu
> > > > Cc: Tomasz Figa
> > > > Fixes: baf94e6ebff9 ("iommu/mediatek: Add device link for smi-
> > > > common
> > > > and m4u")
> > > > Reported-by: kernel test robot
> > > > Reported-by: Dan Carpenter
> > > > Signed-off-by: Guenter Roeck
> > > > ---
> > > > drivers/iommu/mtk_iommu.c | 2 ++
> > > > 1 file changed, 2 insertions(+)
> > > >
> > > > diff --git a/drivers/iommu/mtk_iommu.c
> > > > b/drivers/iommu/mtk_iommu.c
> > > > index 25b834104790..0bbe32d0a2a6 100644
> > > > --- a/drivers/iommu/mtk_iommu.c
> > > > +++ b/drivers/iommu/mtk_iommu.c
> > > > @@ -828,6 +828,8 @@ static int mtk_iommu_probe(struct
> > > > platform_device
> > > > *pdev)
> > > > "mediatek,larbs",
> > > > NULL);
> > > > if (larb_nr < 0)
> > > > return larb_nr;
> > > > + if (larb_nr == 0)
> > > > + return -EINVAL;
> > >
> > > Just assigning the larbnode to NULL may be simpler. In this case,
> > > it
> > > won't enter the loop below, and return 0 in the
> > > of_parse_phandle(larbnode, "mediatek,smi", 0).
> > >
> > > - struct device_node *larbnode, *smicomm_node;
> > > + struct device_node *larbnode = NULL, *smicomm_node;
> > >
> >
> > It is an option, but it would need to be explained and would not be
> > as simple as it looks. And, yes, it would result in unnecessary code
> > execution.
> >
> > Why does it need to be explained ? I spent quite some additional
> > time with the code trying to understand _why_ it works, and we should
> > make sure that others don't have to spend that time.
> >
> > Anyway, that additional time made me find additional problems with
> > the code.
> >
> > The for loop below assigns larbnode to the last node it finds.
> > However, that node can be disabled.
> >
> > if (!of_device_is_available(larbnode)) {
> > of_node_put(larbnode);
> > continue;
> > }
> >
> > Is such a disabled larbnode, if it is the last one, the node to use
> > when looking for "mediatek,smi" ?
> >
> > Al
Re: [SPAM][PATCH] iommu/mediatek: Validate number of phandles associated with "mediatek,larbs"
On 12/13/21 11:31 PM, Yong Wu wrote:
On Fri, 2021-12-10 at 12:57 -0800, Guenter Roeck wrote:
Since commit baf94e6ebff9 ("iommu/mediatek: Add device link for smi-
common
and m4u"), the driver assumes that at least one phandle associated
with
"mediatek,larbs" exists. If that is not the case, for example if
reason
"mediatek,larbs" is provided as boolean property, the code will use
an
uninitialized pointer and may crash. To fix the problem, ensure that
the
number of phandles associated with "mediatek,larbs" is at least 1 and
bail out immediately if that is not the case.
From the dt-binding, "mediatek,larbs" always is a phandle-array. I
assumed the dts should conform to the dt-binding before. Then the
problem is that if we should cover the case that someone abuses/attacks
the dts. Could you help add more comment in the commit message?
something like: this is for avoid abuse the dt-binding.
This doesn't have to be an abuse or attack. It can simply be an error
by the person who wrote the devicetree file. Sure, bugs or lack of
error checking can often be used for attacks, but that doesn't mean
that all bad data is an exploit or attack.
Cc: Yong Wu
Cc: Tomasz Figa
Fixes: baf94e6ebff9 ("iommu/mediatek: Add device link for smi-common
and m4u")
Reported-by: kernel test robot
Reported-by: Dan Carpenter
Signed-off-by: Guenter Roeck
---
drivers/iommu/mtk_iommu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 25b834104790..0bbe32d0a2a6 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -828,6 +828,8 @@ static int mtk_iommu_probe(struct platform_device
*pdev)
"mediatek,larbs", NULL);
if (larb_nr < 0)
return larb_nr;
+ if (larb_nr == 0)
+ return -EINVAL;
Just assigning the larbnode to NULL may be simpler. In this case, it
won't enter the loop below, and return 0 in the
of_parse_phandle(larbnode, "mediatek,smi", 0).
- struct device_node *larbnode, *smicomm_node;
+ struct device_node *larbnode = NULL, *smicomm_node;
It is an option, but it would need to be explained and would not be
as simple as it looks. And, yes, it would result in unnecessary code
execution.
Why does it need to be explained ? I spent quite some additional
time with the code trying to understand _why_ it works, and we should
make sure that others don't have to spend that time.
Anyway, that additional time made me find additional problems with
the code.
The for loop below assigns larbnode to the last node it finds.
However, that node can be disabled.
if (!of_device_is_available(larbnode)) {
of_node_put(larbnode);
continue;
}
Is such a disabled larbnode, if it is the last one, the node to use
when looking for "mediatek,smi" ?
Also, there is
ret = of_property_read_u32(larbnode, "mediatek,larb-id", &id);
if (ret)/* The id is consecutive if there is no this property */
id = i;
There are two problems with this code. First, neither i nor id are range
checked, but used later in
data->larb_imu[id].dev = &plarbdev->dev;
That means a devicetree with a bad value for "mediatek,larb-id"
or more than MTK_LARB_NR_MAX larb nodes will result in writes after
the end of struct mtk_iommu_data.
On top of that, the comment states that the nodes are consecutive if there
is no "mediatek,larb-id". However, that isn't really the case if there
are disabled nodes. If there are disabled nodes, there will be a gap in
larb_imu[]. I don't know if that matters; if it doesn't, there should be
a comment about it in the code.
Last but not least, it would probably make sense to explain what the "last"
larb node is expected to be in more detail. It is the last larb node in
the devicetree file, but not the one with the highest id, and not
(necessarily) an enabled one. For example, in
arch/arm64/boot/dts/mediatek/mt2712e.dtsi, the code would pick
<&smi_common0> even though <&smi_common1> is associated with a higher
larb id.
One could of course argue that this all doesn't matter because it would
suggest that the devicetree data is bad, but it is common practice to validate
devicetree data and not just blindly accept it. One could also argue
that such bad data would be an "attack", but, again, we don't know that.
In summary,
- The check I introduced should probably be something like
if (larb_nr == 0 || larb_nr > MTK_LARB_NR_MAX)
return -EINVAL;
- It needs to be clarified if larbnode to use for finding "mediatek,smi"
is indeed always the last one, even if it is disabled. If so, we shoul
[PATCH] iommu/mediatek: Validate number of phandles associated with "mediatek, larbs"
Since commit baf94e6ebff9 ("iommu/mediatek: Add device link for smi-common
and m4u"), the driver assumes that at least one phandle associated with
"mediatek,larbs" exists. If that is not the case, for example if reason
"mediatek,larbs" is provided as boolean property, the code will use an
uninitialized pointer and may crash. To fix the problem, ensure that the
number of phandles associated with "mediatek,larbs" is at least 1 and
bail out immediately if that is not the case.
Cc: Yong Wu
Cc: Tomasz Figa
Fixes: baf94e6ebff9 ("iommu/mediatek: Add device link for smi-common and m4u")
Reported-by: kernel test robot
Reported-by: Dan Carpenter
Signed-off-by: Guenter Roeck
---
drivers/iommu/mtk_iommu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 25b834104790..0bbe32d0a2a6 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -828,6 +828,8 @@ static int mtk_iommu_probe(struct platform_device *pdev)
"mediatek,larbs", NULL);
if (larb_nr < 0)
return larb_nr;
+ if (larb_nr == 0)
+ return -EINVAL;
for (i = 0; i < larb_nr; i++) {
u32 id;
--
2.33.0
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v15 10/12] swiotlb: Add restricted DMA pool initialization
Hi Claire, On Thu, Jun 24, 2021 at 11:55:24PM +0800, Claire Chang wrote: > Add the initialization function to create restricted DMA pools from > matching reserved-memory nodes. > > Regardless of swiotlb setting, the restricted DMA pool is preferred if > available. > > The restricted DMA pools provide a basic level of protection against the > DMA overwriting buffer contents at unexpected times. However, to protect > against general data leakage and system memory corruption, the system > needs to provide a way to lock down the memory access, e.g., MPU. > > Signed-off-by: Claire Chang > Reviewed-by: Christoph Hellwig > Tested-by: Stefano Stabellini > Tested-by: Will Deacon > --- > include/linux/swiotlb.h | 3 +- > kernel/dma/Kconfig | 14 > kernel/dma/swiotlb.c| 76 + > 3 files changed, 92 insertions(+), 1 deletion(-) > > diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h > index 3b9454d1e498..39284ff2a6cd 100644 > --- a/include/linux/swiotlb.h > +++ b/include/linux/swiotlb.h > @@ -73,7 +73,8 @@ extern enum swiotlb_force swiotlb_force; > * range check to see if the memory was in fact allocated by this > * API. > * @nslabs: The number of IO TLB blocks (in groups of 64) between @start and > - * @end. This is command line adjustable via setup_io_tlb_npages. > + * @end. For default swiotlb, this is command line adjustable via > + * setup_io_tlb_npages. > * @used:The number of used IO TLB block. > * @list:The free list describing the number of free entries available > * from each index. > diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig > index 77b405508743..3e961dc39634 100644 > --- a/kernel/dma/Kconfig > +++ b/kernel/dma/Kconfig > @@ -80,6 +80,20 @@ config SWIOTLB > bool > select NEED_DMA_MAP_STATE > > +config DMA_RESTRICTED_POOL > + bool "DMA Restricted Pool" > + depends on OF && OF_RESERVED_MEM > + select SWIOTLB This makes SWIOTLB user configurable, which in turn results in mips64-linux-ld: arch/mips/kernel/setup.o: in function `arch_mem_init': setup.c:(.init.text+0x19c8): undefined reference to `plat_swiotlb_setup' make[1]: *** [Makefile:1280: vmlinux] Error 1 when building mips:allmodconfig. Should this possibly be "depends on SWIOTLB" ? Thanks, Guenter ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 4/4] swiotlb: Free tbl memory in swiotlb_exit()
On 7/31/21 7:29 PM, Konrad Rzeszutek Wilk wrote:
On Sat, Jul 31, 2021 at 11:26:11AM -0700, Guenter Roeck wrote:
Hi,
On Tue, Jul 20, 2021 at 02:38:26PM +0100, Will Deacon wrote:
Although swiotlb_exit() frees the 'slots' metadata array referenced by
'io_tlb_default_mem', it leaves the underlying buffer pages allocated
despite no longer being usable.
Extend swiotlb_exit() to free the buffer pages as well as the slots
array.
This patch causes qemu pseries emulations to crash. Backtrace and bisect
log see below. Reverting it fixes the problem.
I am 99% sure it is fixed by this patch (which should be in linux-next
in 5 minutes):
Yes, it does.
FWIW:
Tested-by: Guenter Roeck
Thanks!
Guenter
From a449ffaf9181b5a2dc705d8a06b13e0068207fd4 Mon Sep 17 00:00:00 2001
From: Will Deacon
Date: Fri, 30 Jul 2021 12:42:31 +0100
Subject: [PATCH] powerpc/svm: Don't issue ultracalls if !mem_encrypt_active()
Commit ad6c00283163 ("swiotlb: Free tbl memory in swiotlb_exit()")
introduced a set_memory_encrypted() call to swiotlb_exit() so that the
buffer pages are returned to an encrypted state prior to being freed.
Sachin reports that this leads to the following crash on a Power server:
[0.010799] software IO TLB: tearing down default memory pool
[0.010805] [ cut here ]
[0.010808] kernel BUG at arch/powerpc/kernel/interrupt.c:98!
Nick spotted that this is because set_memory_encrypted() is issuing an
ultracall which doesn't exist for the processor, and should therefore
be gated by mem_encrypt_active() to mirror the x86 implementation.
Cc: Konrad Rzeszutek Wilk
Cc: Claire Chang
Cc: Christoph Hellwig
Cc: Robin Murphy
Fixes: ad6c00283163 ("swiotlb: Free tbl memory in swiotlb_exit()")
Suggested-by: Nicholas Piggin
Reported-by: Sachin Sant
Tested-by: Sachin Sant
Tested-by: Nathan Chancellor
Link:
https://lore.kernel.org/r/1905cd70-7656-42ae-99e2-a31fc3812...@linux.vnet.ibm.com/
Signed-off-by: Will Deacon
Signed-off-by: Konrad Rzeszutek Wilk
---
arch/powerpc/platforms/pseries/svm.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/powerpc/platforms/pseries/svm.c
b/arch/powerpc/platforms/pseries/svm.c
index 1d829e257996..87f001b4c4e4 100644
--- a/arch/powerpc/platforms/pseries/svm.c
+++ b/arch/powerpc/platforms/pseries/svm.c
@@ -63,6 +63,9 @@ void __init svm_swiotlb_init(void)
int set_memory_encrypted(unsigned long addr, int numpages)
{
+ if (!mem_encrypt_active())
+ return 0;
+
if (!PAGE_ALIGNED(addr))
return -EINVAL;
@@ -73,6 +76,9 @@ int set_memory_encrypted(unsigned long addr, int numpages)
int set_memory_decrypted(unsigned long addr, int numpages)
{
+ if (!mem_encrypt_active())
+ return 0;
+
if (!PAGE_ALIGNED(addr))
return -EINVAL;
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 4/4] swiotlb: Free tbl memory in swiotlb_exit()
Hi, On Tue, Jul 20, 2021 at 02:38:26PM +0100, Will Deacon wrote: > Although swiotlb_exit() frees the 'slots' metadata array referenced by > 'io_tlb_default_mem', it leaves the underlying buffer pages allocated > despite no longer being usable. > > Extend swiotlb_exit() to free the buffer pages as well as the slots > array. > This patch causes qemu pseries emulations to crash. Backtrace and bisect log see below. Reverting it fixes the problem. Guenter --- Crash log: ... [0.937801][T1] software IO TLB: tearing down default memory pool [0.938939][T1] [ cut here ] [0.940331][T1] kernel BUG at arch/powerpc/kernel/interrupt.c:98! [0.940787][T1] Oops: Exception in kernel mode, sig: 5 [#1] [0.940883][T1] BE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries [0.940999][T1] Modules linked in: [0.941240][T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.14.0-rc3-next-20210729 #1 [0.941523][T1] NIP: c0031310 LR: c00312f4 CTR: c000c5f0 [0.941608][T1] REGS: c8687ac0 TRAP: 0700 Not tainted (5.14.0-rc3-next-20210729) [0.941795][T1] MSR: 80029032 CR: 2400 XER: [0.942031][T1] CFAR: c0300360 IRQMASK: 3 [0.942031][T1] GPR00: c00312f4 c8687d60 c22ee300 0003 [0.942031][T1] GPR04: 033f 0400 3e5a [0.942031][T1] GPR08: 3e5a 0001 0003 [0.942031][T1] GPR12: c2fb c00129c0 [0.942031][T1] GPR16: [0.942031][T1] GPR20: c21d8b00 [0.942031][T1] GPR24: 0400 [0.942031][T1] GPR28: 033f f134 c176c068 c8687e80 [0.942884][T1] NIP [c0031310] .system_call_exception+0x70/0x2d0 [0.943399][T1] LR [c00312f4] .system_call_exception+0x54/0x2d0 [0.943594][T1] Call Trace: [0.943667][T1] [c8687d60] [c00312f4] .system_call_exception+0x54/0x2d0 (unreliable) [0.943919][T1] [c8687e10] [c000c6e4] system_call_common+0xf4/0x258 [0.944066][T1] --- interrupt: c00 at .ucall_norets+0x4/0x14 [0.944172][T1] NIP: c0079ce0 LR: c00fa274 CTR: [0.944245][T1] REGS: c8687e80 TRAP: 0c00 Not tainted (5.14.0-rc3-next-20210729) [0.944323][T1] MSR: 82009032 CR: 2400 XER: [0.944463][T1] IRQMASK: 0 [0.944463][T1] GPR00: c176c068 c8687a30 c22ee300 f134 [0.944463][T1] GPR04: 033f 0400 [0.944463][T1] GPR08: [0.944463][T1] GPR12: c2fb c00129c0 [0.944463][T1] GPR16: [0.944463][T1] GPR20: c21d8b00 [0.944463][T1] GPR24: c17c1088 0004 c171c450 c2338e40 [0.944463][T1] GPR28: c17c10b0 c33f 0400 c33f [0.945188][T1] NIP [c0079ce0] .ucall_norets+0x4/0x14 [0.945285][T1] LR [c00fa274] .set_memory_encrypted+0x44/0x80 [0.945375][T1] --- interrupt: c00 [0.945419][T1] [c8687a30] [c176c068] .swiotlb_exit+0xbc/0x180 (unreliable) [0.945612][T1] Instruction dump: [0.945745][T1] 7cbb2b78 7cda3378 7cf93b78 7d184378 482cefd1 6000 e93f0108 692a0002 [0.945883][T1] 794affe2 0b0a 69294000 792997e2 <0b09> e93f0138 792907e0 0b09 [0.946751][T1] ---[ end trace 600e218cfc83c24b ]--- [0.955185][T1] [1.955805][T1] BUG: sleeping function called from invalid context at ./include/linux/percpu-rwsem.h:49 [1.955918][T1] in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 1, name: swapper/0 [1.956024][T1] INFO: lockdep is turned off. [1.956094][T1] irq event stamp: 14792 [1.956142][T1] hardirqs last enabled at (14791): [] .__up_console_sem+0xc8/0x110 [1.956269][T1] hardirqs last disabled at (14792): [] .system_call_exception+0x54/0x2d0 [1.956384][T1] softirqs last enabled at (10586): [] .release_sock+0xb4/0x100 [1.956497][T1] softirqs last disabled at (10584): [] .release_sock+0x34/0x100 [1.956726][T1] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G D
Re: [PATCH v15 12/12] of: Add plumbing for restricted DMA pool
On 7/2/21 6:18 AM, Will Deacon wrote:
On Fri, Jul 02, 2021 at 12:39:41PM +0100, Robin Murphy wrote:
On 2021-07-02 04:08, Guenter Roeck wrote:
On Thu, Jun 24, 2021 at 11:55:26PM +0800, Claire Chang wrote:
If a device is not behind an IOMMU, we look up the device node and set
up the restricted DMA when the restricted-dma-pool is presented.
Signed-off-by: Claire Chang
Tested-by: Stefano Stabellini
Tested-by: Will Deacon
With this patch in place, all sparc and sparc64 qemu emulations
fail to boot. Symptom is that the root file system is not found.
Reverting this patch fixes the problem. Bisect log is attached.
Ah, OF_ADDRESS depends on !SPARC, so of_dma_configure_id() is presumably
returning an unexpected -ENODEV from the of_dma_set_restricted_buffer()
stub. That should probably be returning 0 instead, since either way it's not
an error condition for it to simply do nothing.
Something like below?
Yes, that does the trick.
Will
--->8
From 4d9dcb9210c1f37435b6088284e04b6b36ee8c4d Mon Sep 17 00:00:00 2001
From: Will Deacon
Date: Fri, 2 Jul 2021 14:13:28 +0100
Subject: [PATCH] of: Return success from of_dma_set_restricted_buffer() when
!OF_ADDRESS
When CONFIG_OF_ADDRESS=n, of_dma_set_restricted_buffer() returns -ENODEV
and breaks the boot for sparc[64] machines. Return 0 instead, since the
function is essentially a glorified NOP in this configuration.
Cc: Claire Chang
Cc: Konrad Rzeszutek Wilk
Reported-by: Guenter Roeck
Suggested-by: Robin Murphy
Link: https://lore.kernel.org/r/20210702030807.ga2685...@roeck-us.net
Signed-off-by: Will Deacon
Tested-by: Guenter Roeck
---
drivers/of/of_private.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/of/of_private.h b/drivers/of/of_private.h
index 8fde97565d11..34dd548c5eac 100644
--- a/drivers/of/of_private.h
+++ b/drivers/of/of_private.h
@@ -173,7 +173,8 @@ static inline int of_dma_get_range(struct device_node *np,
static inline int of_dma_set_restricted_buffer(struct device *dev,
struct device_node *np)
{
- return -ENODEV;
+ /* Do nothing, successfully. */
+ return 0;
}
#endif
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v15 12/12] of: Add plumbing for restricted DMA pool
Hi, On Thu, Jun 24, 2021 at 11:55:26PM +0800, Claire Chang wrote: > If a device is not behind an IOMMU, we look up the device node and set > up the restricted DMA when the restricted-dma-pool is presented. > > Signed-off-by: Claire Chang > Tested-by: Stefano Stabellini > Tested-by: Will Deacon With this patch in place, all sparc and sparc64 qemu emulations fail to boot. Symptom is that the root file system is not found. Reverting this patch fixes the problem. Bisect log is attached. Guenter --- # bad: [fb0ca446157a86b75502c1636b0d81e642fe6bf1] Add linux-next specific files for 20210701 # good: [62fb9874f5da54fdb243003b386128037319b219] Linux 5.13 git bisect start 'HEAD' 'v5.13' # bad: [f63c4fda987a19b1194cc45cb72fd5bf968d9d90] Merge remote-tracking branch 'rdma/for-next' git bisect bad f63c4fda987a19b1194cc45cb72fd5bf968d9d90 # good: [46bb5dd1d2a63e906e374e97dfd4a5e33934b1c4] Merge remote-tracking branch 'ipsec/master' git bisect good 46bb5dd1d2a63e906e374e97dfd4a5e33934b1c4 # good: [43ba6969cfb8185353a7a6fc79070f13b9e3d6d3] Merge remote-tracking branch 'clk/clk-next' git bisect good 43ba6969cfb8185353a7a6fc79070f13b9e3d6d3 # good: [1ca5eddcf8dca1d6345471c6404e7364af0d7019] Merge remote-tracking branch 'fuse/for-next' git bisect good 1ca5eddcf8dca1d6345471c6404e7364af0d7019 # good: [8f6d7b3248705920187263a4e7147b0752ec7dcf] Merge remote-tracking branch 'pci/next' git bisect good 8f6d7b3248705920187263a4e7147b0752ec7dcf # good: [df1885a755784da3ef285f36d9230c1d090ef186] RDMA/rtrs_clt: Alloc less memory with write path fast memory registration git bisect good df1885a755784da3ef285f36d9230c1d090ef186 # good: [93d31efb58c8ad4a66bbedbc2d082df458c04e45] Merge remote-tracking branch 'cpufreq-arm/cpufreq/arm/linux-next' git bisect good 93d31efb58c8ad4a66bbedbc2d082df458c04e45 # good: [46308965ae6fdc7c25deb2e8c048510ae51bbe66] RDMA/irdma: Check contents of user-space irdma_mem_reg_req object git bisect good 46308965ae6fdc7c25deb2e8c048510ae51bbe66 # good: [6de7a1d006ea9db235492b288312838d6878385f] thermal/drivers/int340x/processor_thermal: Split enumeration and processing part git bisect good 6de7a1d006ea9db235492b288312838d6878385f # good: [081bec2577cda3d04f6559c60b6f4e2242853520] dt-bindings: of: Add restricted DMA pool git bisect good 081bec2577cda3d04f6559c60b6f4e2242853520 # good: [bf95ac0bcd69979af146852f6a617a60285ebbc1] Merge remote-tracking branch 'thermal/thermal/linux-next' git bisect good bf95ac0bcd69979af146852f6a617a60285ebbc1 # good: [3d8287544223a3d2f37981c1f9ffd94d0b5e9ffc] RDMA/core: Always release restrack object git bisect good 3d8287544223a3d2f37981c1f9ffd94d0b5e9ffc # bad: [cff1f23fad6e0bd7d671acce0d15285c709f259c] Merge remote-tracking branch 'swiotlb/linux-next' git bisect bad cff1f23fad6e0bd7d671acce0d15285c709f259c # bad: [b655006619b7bccd0dc1e055bd72de5d613e7b5c] of: Add plumbing for restricted DMA pool git bisect bad b655006619b7bccd0dc1e055bd72de5d613e7b5c # first bad commit: [b655006619b7bccd0dc1e055bd72de5d613e7b5c] of: Add plumbing for restricted DMA pool ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC v1 PATCH 3/3] driver: update all the code that use soc_device_match
On 4/18/21 9:27 PM, Alice Guo (OSS) wrote:
> From: Alice Guo
>
> Update all the code that use soc_device_match because add support for
> soc_device_match returning -EPROBE_DEFER.
>
> Signed-off-by: Alice Guo
> ---
[ ... ]
> drivers/watchdog/renesas_wdt.c| 2 +-
> 48 files changed, 131 insertions(+), 52 deletions(-)
>
[ ... ]
> diff --git a/drivers/watchdog/renesas_wdt.c b/drivers/watchdog/renesas_wdt.c
> index 5791198960e6..fdc534dc4024 100644
> --- a/drivers/watchdog/renesas_wdt.c
> +++ b/drivers/watchdog/renesas_wdt.c
> @@ -197,7 +197,7 @@ static bool rwdt_blacklisted(struct device *dev)
> const struct soc_device_attribute *attr;
>
> attr = soc_device_match(rwdt_quirks_match);
> - if (attr && setup_max_cpus > (uintptr_t)attr->data) {
> + if (!IS_ERR(attr) && attr && setup_max_cpus > (uintptr_t)attr->data) {
This is wrong. We can not make the decision below without having access
to attr. The function may wrongly return false if soc_device_match()
returns an error.
Guenter
> dev_info(dev, "Watchdog blacklisted on %s %s\n", attr->soc_id,
>attr->revision);
> return true;
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 1/4] iommu/vt-d: Enable write protect for supervisor SVM
On 3/30/21 10:52 AM, Jacob Pan wrote: > Hi Guenter, > > On Mon, 22 Mar 2021 10:53:38 -0700, Guenter Roeck > wrote: > >> On Tue, Mar 02, 2021 at 02:13:57AM -0800, Jacob Pan wrote: >>> Write protect bit, when set, inhibits supervisor writes to the read-only >>> pages. In supervisor shared virtual addressing (SVA), where page tables >>> are shared between CPU and DMA, IOMMU PASID entry WPE bit should match >>> CR0.WP bit in the CPU. >>> This patch sets WPE bit for supervisor PASIDs if CR0.WP is set. >>> >>> Signed-off-by: Sanjay Kumar >>> Signed-off-by: Jacob Pan >>> --- >> >> ia64:defconfig: >> >> drivers/iommu/intel/pasid.c: In function 'pasid_enable_wpe': >> drivers/iommu/intel/pasid.c:536:22: error: implicit declaration of >> function 'read_cr0' drivers/iommu/intel/pasid.c:539:23: error: >> 'X86_CR0_WP' undeclared >> >> Maybe it _is_ time to retire ia64 ? > > Good catch, sorry for the late reply. I guess otherwise I will have to do > some #ifdef? > I really can't tell you how to resolve this. > There are many basic x86 helpers are missing in ia64. > I'd say that Intel needs to decide what to do with the ia64 architecture. Guenter > +Tony > > Thanks, > > Jacob > ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 1/4] iommu/vt-d: Enable write protect for supervisor SVM
On Tue, Mar 02, 2021 at 02:13:57AM -0800, Jacob Pan wrote: > Write protect bit, when set, inhibits supervisor writes to the read-only > pages. In supervisor shared virtual addressing (SVA), where page tables > are shared between CPU and DMA, IOMMU PASID entry WPE bit should match > CR0.WP bit in the CPU. > This patch sets WPE bit for supervisor PASIDs if CR0.WP is set. > > Signed-off-by: Sanjay Kumar > Signed-off-by: Jacob Pan > --- ia64:defconfig: drivers/iommu/intel/pasid.c: In function 'pasid_enable_wpe': drivers/iommu/intel/pasid.c:536:22: error: implicit declaration of function 'read_cr0' drivers/iommu/intel/pasid.c:539:23: error: 'X86_CR0_WP' undeclared Maybe it _is_ time to retire ia64 ? Guenter ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 1/3] dt-bindings: Fix undocumented compatible strings in examples
On 2/2/21 12:55 PM, Rob Herring wrote:
> Running 'dt-validate -m' will flag any compatible strings missing a schema.
> Fix all the errors found in DT binding examples. Most of these are just
> typos.
>
> Cc: Stephen Boyd
> Cc: Maxime Ripard
> Cc: Chen-Yu Tsai
> Cc: Linus Walleij
> Cc: Herbert Xu
> Cc: "David S. Miller"
> Cc: Daniel Palmer
> Cc: Bartosz Golaszewski
> Cc: Avi Fishman
> Cc: Tomer Maimon
> Cc: Tali Perry
> Cc: Joerg Roedel
> Cc: Will Deacon
> Cc: Andrew Jeffery
> Cc: Joel Stanley
> Cc: Wim Van Sebroeck
> Cc: Guenter Roeck
> Cc: Yoshihiro Shimoda
> Cc: Vincent Cheng
> Cc: linux-...@vger.kernel.org
> Cc: linux-cry...@vger.kernel.org
> Cc: linux-g...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: iommu@lists.linux-foundation.org
> Cc: linux-watch...@vger.kernel.org
Reviewed-by: Guenter Roeck
> Signed-off-by: Rob Herring
> ---
> .../bindings/clock/allwinner,sun9i-a80-usb-clocks.yaml| 2 +-
> Documentation/devicetree/bindings/clock/arm,syscon-icst.yaml | 4 ++--
> Documentation/devicetree/bindings/crypto/ti,sa2ul.yaml| 2 +-
> Documentation/devicetree/bindings/gpio/mstar,msc313-gpio.yaml | 2 +-
> .../devicetree/bindings/i2c/nuvoton,npcm7xx-i2c.yaml | 2 +-
> .../devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml | 2 +-
> .../devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml | 2 +-
> .../devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml | 2 +-
> .../devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml | 2 +-
> Documentation/devicetree/bindings/ptp/ptp-idtcm.yaml | 4 +---
> Documentation/devicetree/bindings/watchdog/ti,rti-wdt.yaml| 4 ++--
> 11 files changed, 13 insertions(+), 15 deletions(-)
>
> diff --git
> a/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-usb-clocks.yaml
> b/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-usb-clocks.yaml
> index fa0ee03a527f..53cc6df0df96 100644
> ---
> a/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-usb-clocks.yaml
> +++
> b/Documentation/devicetree/bindings/clock/allwinner,sun9i-a80-usb-clocks.yaml
> @@ -18,7 +18,7 @@ properties:
> const: 1
>
>compatible:
> -const: allwinner,sun9i-a80-usb-clocks
> +const: allwinner,sun9i-a80-usb-clks
>
>reg:
> maxItems: 1
> diff --git a/Documentation/devicetree/bindings/clock/arm,syscon-icst.yaml
> b/Documentation/devicetree/bindings/clock/arm,syscon-icst.yaml
> index eb241587efd1..118c5543e037 100644
> --- a/Documentation/devicetree/bindings/clock/arm,syscon-icst.yaml
> +++ b/Documentation/devicetree/bindings/clock/arm,syscon-icst.yaml
> @@ -66,8 +66,8 @@ properties:
>- arm,syscon-icst525-integratorcp-cm-mem
>- arm,integrator-cm-auxosc
>- arm,versatile-cm-auxosc
> - - arm,impd-vco1
> - - arm,impd-vco2
> + - arm,impd1-vco1
> + - arm,impd1-vco2
>
>clocks:
> description: Parent clock for the ICST VCO
> diff --git a/Documentation/devicetree/bindings/crypto/ti,sa2ul.yaml
> b/Documentation/devicetree/bindings/crypto/ti,sa2ul.yaml
> index 1465c9ebaf93..1d48ac712b23 100644
> --- a/Documentation/devicetree/bindings/crypto/ti,sa2ul.yaml
> +++ b/Documentation/devicetree/bindings/crypto/ti,sa2ul.yaml
> @@ -66,7 +66,7 @@ examples:
> #include
>
> main_crypto: crypto@4e0 {
> -compatible = "ti,j721-sa2ul";
> +compatible = "ti,j721e-sa2ul";
> reg = <0x4e0 0x1200>;
> power-domains = <&k3_pds 264 TI_SCI_PD_EXCLUSIVE>;
> dmas = <&main_udmap 0xc000>, <&main_udmap 0x4000>,
> diff --git a/Documentation/devicetree/bindings/gpio/mstar,msc313-gpio.yaml
> b/Documentation/devicetree/bindings/gpio/mstar,msc313-gpio.yaml
> index 1f2ef408bb43..fe1e1c63ffe3 100644
> --- a/Documentation/devicetree/bindings/gpio/mstar,msc313-gpio.yaml
> +++ b/Documentation/devicetree/bindings/gpio/mstar,msc313-gpio.yaml
> @@ -46,7 +46,7 @@ examples:
> #include
>
> gpio: gpio@207800 {
> - compatible = "mstar,msc313e-gpio";
> + compatible = "mstar,msc313-gpio";
>#gpio-cells = <2>;
>reg = <0x207800 0x200>;
>gpio-controller;
> diff --git a/Documentation/devicetree/bindings/i2c/nuvoton,npcm7xx-i2c.yaml
> b/Documentation/devicetree/bindings/i2c/nuvoton,npcm7xx-i2c.yaml
> index e3ef2d36f372..128444942aec 100644
> --- a/Documentation/devicetree/bindings/i2c/nuvoton,npcm7xx-i2c.yaml
> +++ b/Documentation/devicetree/bindings/i2c/nuvoton,npcm7xx-i2c.yaml
> @@ -17,7 +17,7 @@ maintainers:
>
> proper
Re: [PATCH 1/9] dma-mapping: split
On Wed, Sep 30, 2020 at 10:55:40AM +0200, Christoph Hellwig wrote: > Split out all the bits that are purely for dma_map_ops implementations > and related code into a new header so that they > don't get pulled into all the drivers. That also means the architecture > specific is not pulled in by > any more, which leads to a missing includes that were pulled in by the > x86 or arm versions in a few not overly portable drivers. > > Signed-off-by: Christoph Hellwig This patch results in the following build error. Building arm:ixp4xx_defconfig ... failed -- Error log: arch/arm/mach-ixp4xx/common.c: In function 'ixp4xx_platform_notify_remove': arch/arm/mach-ixp4xx/common.c:291:3: error: implicit declaration of function 'dmabounce_unregister_dev' [-Werror=implicit-function-declaration] 291 | dmabounce_unregister_dev(dev); | ^~~~ arch/arm/mach-ixp4xx/common.c: In function 'ixp4xx_platform_notify': arch/arm/mach-ixp4xx/common.c:307:3: error: implicit declaration of function 'dmabounce_register_dev' [-Werror=implicit-function-declaration] 307 | dmabounce_register_dev(dev, 2048, 4096, ixp4xx_needs_bounce); Bisect log attached. Guenter --- # bad: [d67bc7812221606e1886620a357b13f906814af7] Add linux-next specific files for 20201009 # good: [549738f15da0e5a00275977623be199fbbf7df50] Linux 5.9-rc8 git bisect start 'HEAD' 'v5.9-rc8' # bad: [b71be15b496cc71a3434a198fc1a1b9e08af6c57] Merge remote-tracking branch 'bpf-next/master' into master git bisect bad b71be15b496cc71a3434a198fc1a1b9e08af6c57 # bad: [6be11f939f380ef14bc94242cb0262197ce2a054] Merge remote-tracking branch 'i2c/i2c/for-next' into master git bisect bad 6be11f939f380ef14bc94242cb0262197ce2a054 # bad: [c03a115d8ad8a87b6d275c3c91c13bc111217bf6] Merge remote-tracking branch 'samsung-krzk/for-next' into master git bisect bad c03a115d8ad8a87b6d275c3c91c13bc111217bf6 # good: [4f7233567480421eab9c622f395854bfd925f9f2] Merge branch 'arm/dt' into for-next git bisect good 4f7233567480421eab9c622f395854bfd925f9f2 # bad: [0fa3d3941f0f9fc9b39621af3309b5fdf0c1a6cb] Merge remote-tracking branch 'arm/for-next' into master git bisect bad 0fa3d3941f0f9fc9b39621af3309b5fdf0c1a6cb # good: [1357d119df6c359a2903a46522c2511d990db9bb] Merge remote-tracking branch 'sound-current/for-linus' into master git bisect good 1357d119df6c359a2903a46522c2511d990db9bb # good: [bd02811392faa248d95f8559498c03933eb7d78b] Merge remote-tracking branch 'kspp-gustavo/for-next/kspp' into master git bisect good bd02811392faa248d95f8559498c03933eb7d78b # bad: [0b1abd1fb7efafc25231c54a67c6fbb3d3127efd] dma-mapping: merge into git bisect bad 0b1abd1fb7efafc25231c54a67c6fbb3d3127efd # good: [b9bb694b9f62f4b31652223ed3ca38cf98bbb370] iommu/io-pgtable-arm: Clean up faulty sanity check git bisect good b9bb694b9f62f4b31652223ed3ca38cf98bbb370 # good: [ed4bc1890b4984d0af447ad3cc1f93541623f8f3] hal2: convert to dma_alloc_noncoherent git bisect good ed4bc1890b4984d0af447ad3cc1f93541623f8f3 # good: [e8d39a903cc680c8c1ab5e528428f182f42b8a35] dma-iommu: implement ->alloc_noncoherent git bisect good e8d39a903cc680c8c1ab5e528428f182f42b8a35 # bad: [0a0f0d8be76dcd4390ff538e7060fda34db79717] dma-mapping: split git bisect bad 0a0f0d8be76dcd4390ff538e7060fda34db79717 # good: [0de327969b61a245e3a47b60009eae73fe513cef] cma: decrease CMA_ALIGNMENT lower limit to 2 git bisect good 0de327969b61a245e3a47b60009eae73fe513cef # first bad commit: [0a0f0d8be76dcd4390ff538e7060fda34db79717] dma-mapping: split ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v12 09/13] drm/msm: Add support to create a local pagetable
On Mon, Aug 10, 2020 at 04:26:53PM -0600, Jordan Crouse wrote:
> Add support to create a io-pgtable for use by targets that support
> per-instance pagetables. In order to support per-instance pagetables the
> GPU SMMU device needs to have the qcom,adreno-smmu compatible string and
> split pagetables enabled.
>
> Signed-off-by: Jordan Crouse
This patch adds a hard dependency on IOMMU_IO_PGTABLE (for
alloc_io_pgtable_ops and free_io_pgtable_ops).
Guenter
> ---
>
> drivers/gpu/drm/msm/msm_gpummu.c | 2 +-
> drivers/gpu/drm/msm/msm_iommu.c | 190 ++-
> drivers/gpu/drm/msm/msm_mmu.h| 16 ++-
> 3 files changed, 205 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_gpummu.c
> b/drivers/gpu/drm/msm/msm_gpummu.c
> index 310a31b05faa..aab121f4beb7 100644
> --- a/drivers/gpu/drm/msm/msm_gpummu.c
> +++ b/drivers/gpu/drm/msm/msm_gpummu.c
> @@ -102,7 +102,7 @@ struct msm_mmu *msm_gpummu_new(struct device *dev, struct
> msm_gpu *gpu)
> }
>
> gpummu->gpu = gpu;
> - msm_mmu_init(&gpummu->base, dev, &funcs);
> + msm_mmu_init(&gpummu->base, dev, &funcs, MSM_MMU_GPUMMU);
>
> return &gpummu->base;
> }
> diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c
> index 1b6635504069..bc04dda8a198 100644
> --- a/drivers/gpu/drm/msm/msm_iommu.c
> +++ b/drivers/gpu/drm/msm/msm_iommu.c
> @@ -4,15 +4,201 @@
> * Author: Rob Clark
> */
>
> +#include
> #include "msm_drv.h"
> #include "msm_mmu.h"
>
> struct msm_iommu {
> struct msm_mmu base;
> struct iommu_domain *domain;
> + atomic_t pagetables;
> };
> +
> #define to_msm_iommu(x) container_of(x, struct msm_iommu, base)
>
> +struct msm_iommu_pagetable {
> + struct msm_mmu base;
> + struct msm_mmu *parent;
> + struct io_pgtable_ops *pgtbl_ops;
> + phys_addr_t ttbr;
> + u32 asid;
> +};
> +static struct msm_iommu_pagetable *to_pagetable(struct msm_mmu *mmu)
> +{
> + return container_of(mmu, struct msm_iommu_pagetable, base);
> +}
> +
> +static int msm_iommu_pagetable_unmap(struct msm_mmu *mmu, u64 iova,
> + size_t size)
> +{
> + struct msm_iommu_pagetable *pagetable = to_pagetable(mmu);
> + struct io_pgtable_ops *ops = pagetable->pgtbl_ops;
> + size_t unmapped = 0;
> +
> + /* Unmap the block one page at a time */
> + while (size) {
> + unmapped += ops->unmap(ops, iova, 4096, NULL);
> + iova += 4096;
> + size -= 4096;
> + }
> +
> + iommu_flush_tlb_all(to_msm_iommu(pagetable->parent)->domain);
> +
> + return (unmapped == size) ? 0 : -EINVAL;
> +}
> +
> +static int msm_iommu_pagetable_map(struct msm_mmu *mmu, u64 iova,
> + struct sg_table *sgt, size_t len, int prot)
> +{
> + struct msm_iommu_pagetable *pagetable = to_pagetable(mmu);
> + struct io_pgtable_ops *ops = pagetable->pgtbl_ops;
> + struct scatterlist *sg;
> + size_t mapped = 0;
> + u64 addr = iova;
> + unsigned int i;
> +
> + for_each_sg(sgt->sgl, sg, sgt->nents, i) {
> + size_t size = sg->length;
> + phys_addr_t phys = sg_phys(sg);
> +
> + /* Map the block one page at a time */
> + while (size) {
> + if (ops->map(ops, addr, phys, 4096, prot, GFP_KERNEL)) {
> + msm_iommu_pagetable_unmap(mmu, iova, mapped);
> + return -EINVAL;
> + }
> +
> + phys += 4096;
> + addr += 4096;
> + size -= 4096;
> + mapped += 4096;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static void msm_iommu_pagetable_destroy(struct msm_mmu *mmu)
> +{
> + struct msm_iommu_pagetable *pagetable = to_pagetable(mmu);
> + struct msm_iommu *iommu = to_msm_iommu(pagetable->parent);
> +
> + /*
> + * If this is the last attached pagetable for the parent,
> + * disable TTBR0 in the arm-smmu driver
> + */
> + if (atomic_dec_return(&iommu->pagetables) == 0)
> + iommu_domain_set_attr(iommu->domain,
> + DOMAIN_ATTR_PGTABLE_CFG, NULL);
> +
> + free_io_pgtable_ops(pagetable->pgtbl_ops);
> + kfree(pagetable);
> +}
> +
> +int msm_iommu_pagetable_params(struct msm_mmu *mmu,
> + phys_addr_t *ttbr, int *asid)
> +{
> + struct msm_iommu_pagetable *pagetable;
> +
> + if (mmu->type != MSM_MMU_IOMMU_PAGETABLE)
> + return -EINVAL;
> +
> + pagetable = to_pagetable(mmu);
> +
> + if (ttbr)
> + *ttbr = pagetable->ttbr;
> +
> + if (asid)
> + *asid = pagetable->asid;
> +
> + return 0;
> +}
> +
> +static const struct msm_mmu_funcs pagetable_funcs = {
> + .map = msm_iommu_pagetable_map,
> + .unmap = msm_iommu_pagetable_unmap,
> + .destroy = msm_iommu_pagetable_destroy,
> +};
> +
> +static void msm_iom
Re: [PATCH 3/5] dma-mapping: make support for dma ops optional
On Wed, Jul 08, 2020 at 05:24:47PM +0200, Christoph Hellwig wrote: > Avoid the overhead of the dma ops support for tiny builds that only > use the direct mapping. > > Signed-off-by: Christoph Hellwig For ppc:pmac32_defconfig and other configurations, this patch results in: Error log: drivers/macintosh/macio_asic.c: In function 'macio_add_one_device': drivers/macintosh/macio_asic.c:393:16: error: 'struct device' has no member named 'dma_ops' 393 | dev->ofdev.dev.dma_ops = chip->lbus.pdev->dev.dma_ops; |^ drivers/macintosh/macio_asic.c:393:47: error: 'struct device' has no member named 'dma_ops' 393 | dev->ofdev.dev.dma_ops = chip->lbus.pdev->dev.dma_ops; | ^ Bisect log attached. Guenter --- # bad: [aab7ee9f8ff0110bfcd594b33dc33748dc1baf46] Add linux-next specific files for 20200717 # good: [11ba468877bb23f28956a35e896356252d63c983] Linux 5.8-rc5 git bisect start 'HEAD' 'v5.8-rc5' # bad: [4d55a7a1298d197755c1a0f4512f56917e938a83] Merge remote-tracking branch 'crypto/master' git bisect bad 4d55a7a1298d197755c1a0f4512f56917e938a83 # bad: [49485850238eb3fc72aac951e47e33e367aafbab] Merge remote-tracking branch 'hid/for-next' git bisect bad 49485850238eb3fc72aac951e47e33e367aafbab # bad: [4406fe306759d700f2b2aa8adf890a7d7ef064ae] Merge remote-tracking branch 'tegra/for-next' git bisect bad 4406fe306759d700f2b2aa8adf890a7d7ef064ae # bad: [27f18f0e00ed1f15ee55d479216c874561b6b70a] Merge remote-tracking branch 'arm-soc/for-next' git bisect bad 27f18f0e00ed1f15ee55d479216c874561b6b70a # good: [a23a793b03f465cffa29e7f81d732a6f6fdf] Merge remote-tracking branch 'usb-chipidea-fixes/ci-for-usb-stable' git bisect good a23a793b03f465cffa29e7f81d732a6f6fdf # good: [05d94a2de41e8d9840d9749d553febdcf99cb0e5] Merge branch 'arm/drivers' into for-next git bisect good 05d94a2de41e8d9840d9749d553febdcf99cb0e5 # good: [5fef5dc17f097794288acb098ccc80eb91142bf4] Merge branch 'for-next/mte' into for-next/core git bisect good 5fef5dc17f097794288acb098ccc80eb91142bf4 # good: [3c7f84b2248457030a903813e4af71d80141d663] Merge remote-tracking branch 'fpga-fixes/fixes' git bisect good 3c7f84b2248457030a903813e4af71d80141d663 # bad: [88ff79e455afa3ac90739da27e24f655a965e3cf] Merge remote-tracking branch 'dma-mapping/for-next' git bisect bad 88ff79e455afa3ac90739da27e24f655a965e3cf # good: [7c4d50d4973b40c53ef6c592b41b0473127e6762] kbuild: do not export LDFLAGS_vmlinux git bisect good 7c4d50d4973b40c53ef6c592b41b0473127e6762 # good: [c45db534668104ed5112ed371526db6096ac5742] Merge remote-tracking branch 'kbuild/for-next' git bisect good c45db534668104ed5112ed371526db6096ac5742 # bad: [249542813648f7a278895ad25674d3e147f49ad6] dma-mapping: make support for dma ops optional git bisect bad 249542813648f7a278895ad25674d3e147f49ad6 # good: [b4174173005972f8f6497883d08d87e0aba1b604] dma-mapping: inline the fast path dma-direct calls git bisect good b4174173005972f8f6497883d08d87e0aba1b604 # first bad commit: [249542813648f7a278895ad25674d3e147f49ad6] dma-mapping: make support for dma ops optional ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2] dma-pool: Fix too large DMA pools on medium systems
On Wed, Jun 24, 2020 at 09:38:15AM +0200, Christoph Hellwig wrote:
> Hi Guenter,
>
> can you try the patch below? This just converts the huge allocations
> in mptbase to use GFP_KERNEL. Christophe (added to Cc) actually has
> a scripted conversion for the rest that he hasn't posted yet, so I'll
> aim for the minimal version here.
>
The previously failing test passes with this patch applied on top of the
mainline kernel.
Guenter
>
> diff --git a/drivers/message/fusion/mptbase.c
> b/drivers/message/fusion/mptbase.c
> index 68aea22f2b8978..5216487db4fbea 100644
> --- a/drivers/message/fusion/mptbase.c
> +++ b/drivers/message/fusion/mptbase.c
> @@ -1324,13 +1324,13 @@ mpt_host_page_alloc(MPT_ADAPTER *ioc, pIOCInit_t
> ioc_init)
> return 0; /* fw doesn't need any host buffers */
>
> /* spin till we get enough memory */
> - while(host_page_buffer_sz > 0) {
> -
> - if((ioc->HostPageBuffer = pci_alloc_consistent(
> - ioc->pcidev,
> - host_page_buffer_sz,
> - &ioc->HostPageBuffer_dma)) != NULL) {
> -
> + while (host_page_buffer_sz > 0) {
> + ioc->HostPageBuffer =
> + dma_alloc_coherent(&ioc->pcidev->dev,
> + host_page_buffer_sz,
> + &ioc->HostPageBuffer_dma,
> + GFP_KERNEL);
> + if (ioc->HostPageBuffer) {
> dinitprintk(ioc, printk(MYIOC_s_DEBUG_FMT
> "host_page_buffer @ %p, dma @ %x, sz=%d
> bytes\n",
> ioc->name, ioc->HostPageBuffer,
> @@ -2741,8 +2741,8 @@ mpt_adapter_disable(MPT_ADAPTER *ioc)
> sz = ioc->alloc_sz;
> dexitprintk(ioc, printk(MYIOC_s_INFO_FMT "free @ %p, sz=%d
> bytes\n",
> ioc->name, ioc->alloc, ioc->alloc_sz));
> - pci_free_consistent(ioc->pcidev, sz,
> - ioc->alloc, ioc->alloc_dma);
> + dma_free_coherent(&ioc->pcidev->dev, sz, ioc->alloc,
> + ioc->alloc_dma);
> ioc->reply_frames = NULL;
> ioc->req_frames = NULL;
> ioc->alloc = NULL;
> @@ -2751,8 +2751,8 @@ mpt_adapter_disable(MPT_ADAPTER *ioc)
>
> if (ioc->sense_buf_pool != NULL) {
> sz = (ioc->req_depth * MPT_SENSE_BUFFER_ALLOC);
> - pci_free_consistent(ioc->pcidev, sz,
> - ioc->sense_buf_pool, ioc->sense_buf_pool_dma);
> + dma_free_coherent(&ioc->pcidev->dev, sz, ioc->sense_buf_pool,
> + ioc->sense_buf_pool_dma);
> ioc->sense_buf_pool = NULL;
> ioc->alloc_total -= sz;
> }
> @@ -2802,7 +2802,7 @@ mpt_adapter_disable(MPT_ADAPTER *ioc)
> "HostPageBuffer free @ %p, sz=%d bytes\n",
> ioc->name, ioc->HostPageBuffer,
> ioc->HostPageBuffer_sz));
> - pci_free_consistent(ioc->pcidev, ioc->HostPageBuffer_sz,
> + dma_free_coherent(&ioc->pcidev->dev, ioc->HostPageBuffer_sz,
> ioc->HostPageBuffer, ioc->HostPageBuffer_dma);
> ioc->HostPageBuffer = NULL;
> ioc->HostPageBuffer_sz = 0;
> @@ -4497,7 +4497,8 @@ PrimeIocFifos(MPT_ADAPTER *ioc)
> ioc->name, sz, sz, num_chain));
>
> total_size += sz;
> - mem = pci_alloc_consistent(ioc->pcidev, total_size, &alloc_dma);
> + mem = dma_alloc_coherent(&ioc->pcidev->dev, total_size,
> + &alloc_dma, GFP_KERNEL);
> if (mem == NULL) {
> printk(MYIOC_s_ERR_FMT "Unable to allocate Reply,
> Request, Chain Buffers!\n",
> ioc->name);
> @@ -4574,8 +4575,8 @@ PrimeIocFifos(MPT_ADAPTER *ioc)
> spin_unlock_irqrestore(&ioc->FreeQlock, flags);
>
> sz = (ioc->req_depth * MPT_SENSE_BUFFER_ALLOC);
> - ioc->sense_buf_pool =
> - pci_alloc_consistent(ioc->pcidev, sz,
> &ioc->sense_buf_pool_dma);
> + ioc->sense_buf_pool = dma_alloc_coherent(&ioc->pcidev->dev, sz,
> + &ioc->sense_buf_pool_dma, GFP_KERNEL);
> if (ioc->sense_buf_pool == NULL) {
> printk(MYIOC_s_ERR_FMT "Unable to allocate Sense
> Buffers!\n",
> ioc->name);
> @@ -4613,18 +4614,16 @@ PrimeIocFifos(MPT_ADAPTER *ioc)
>
> if (ioc->alloc != NULL) {
> sz = ioc->alloc_sz;
> - pci_free_consistent(ioc->pcidev,
> - sz,
> - ioc->alloc, ioc->alloc_dma);
> + dma_free_coherent
Re: [patch] dma-pool: warn when coherent pool is depleted
On Sun, Jun 21, 2020 at 01:43:02PM -0700, David Rientjes wrote:
> When a DMA coherent pool is depleted, allocation failures may or may not
> get reported in the kernel log depending on the allocator.
>
> The admin does have a workaround, however, by using coherent_pool= on the
> kernel command line.
>
> Provide some guidance on the failure and a recommended minimum size for
> the pools (double the size).
>
> Signed-off-by: David Rientjes
Tested-by: Guenter Roeck
Also confirmed that coherent_pool=256k works around the crash
I had observed.
Guenter
> ---
> kernel/dma/pool.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/dma/pool.c b/kernel/dma/pool.c
> --- a/kernel/dma/pool.c
> +++ b/kernel/dma/pool.c
> @@ -239,12 +239,16 @@ void *dma_alloc_from_pool(struct device *dev, size_t
> size,
> }
>
> val = gen_pool_alloc(pool, size);
> - if (val) {
> + if (likely(val)) {
> phys_addr_t phys = gen_pool_virt_to_phys(pool, val);
>
> *ret_page = pfn_to_page(__phys_to_pfn(phys));
> ptr = (void *)val;
> memset(ptr, 0, size);
> + } else {
> + WARN_ONCE(1, "DMA coherent pool depleted, increase size "
> + "(recommended min coherent_pool=%zuK)\n",
> + gen_pool_size(pool) >> 9);
> }
> if (gen_pool_avail(pool) < atomic_pool_size)
> schedule_work(&atomic_pool_work);
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2] dma-pool: Fix too large DMA pools on medium systems
On 6/21/20 1:35 AM, Geert Uytterhoeven wrote:
> Hi Günter,
>
> On Sat, Jun 20, 2020 at 10:09 PM Guenter Roeck wrote:
>> On Mon, Jun 08, 2020 at 03:22:17PM +0200, Geert Uytterhoeven wrote:
>>> On systems with at least 32 MiB, but less than 32 GiB of RAM, the DMA
>>> memory pools are much larger than intended (e.g. 2 MiB instead of 128
>>> KiB on a 256 MiB system).
>>>
>>> Fix this by correcting the calculation of the number of GiBs of RAM in
>>> the system. Invert the order of the min/max operations, to keep on
>>> calculating in pages until the last step, which aids readability.
>>>
>>> Fixes: 1d659236fb43c4d2 ("dma-pool: scale the default DMA coherent pool
>>> size with memory capacity")
>>> Signed-off-by: Geert Uytterhoeven
>>> Acked-by: David Rientjes
>>
>> This patch results in a boot failure in some of my powerpc boot tests,
>> specifically those testing boots from mptsas1068 devices. Error message:
>>
>> mptsas :00:02.0: enabling device ( -> 0002)
>> mptbase: ioc0: Initiating bringup
>> ioc0: LSISAS1068 A0: Capabilities={Initiator}
>> mptbase: ioc0: ERROR - Unable to allocate Reply, Request, Chain Buffers!
>> mptbase: ioc0: ERROR - didn't initialize properly! (-3)
>> mptsas: probe of :00:02.0 failed with error -3
>>
>> Configuration is bamboo:44x/bamboo_defconfig plus various added drivers.
>> Qemu command line is
>>
>> qemu-system-ppc -kernel vmlinux -M bamboo \
>> -m 256 -no-reboot -snapshot -device mptsas1068,id=scsi \
>> -device scsi-hd,bus=scsi.0,drive=d0,wwn=0x5000c50015ea71ac -drive \
>> file=rootfs.ext2,format=raw,if=none,id=d0 \
>> --append "panic=-1 slub_debug=FZPUA root=/dev/sda mem=256M
>> console=ttyS0" \
>> -monitor none -nographic
>>
>> canyonlands_defconfig with sam460ex machine and otherwise similar command
>> line
>> fails as well.
>>
>> Reverting this patch fixes the problem.
>
> This looks like the minimum value of 128 KiB is not sufficient, and the
> bug is in the intention of 1d659236fb43c4d2 ("dma-pool: scale the
> default DMA coherent pool size with memory capacity")?
> Before, there was a single pool of (fixed) 256 KiB size, now there are
> up to three coherent pools (DMA, DMA32, and kernel), albeit of smaller
> size (128 KiB each).
>
> Can you print the requested size in drivers/message/fusion/mptbase.c:
> PrimeIocFifos()?
172928 bytes
> Does replacing all SZ_128K by SZ_256K in my patch help?
Yes, it does.
Guenter
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2] dma-pool: Fix too large DMA pools on medium systems
On Mon, Jun 08, 2020 at 03:22:17PM +0200, Geert Uytterhoeven wrote:
> On systems with at least 32 MiB, but less than 32 GiB of RAM, the DMA
> memory pools are much larger than intended (e.g. 2 MiB instead of 128
> KiB on a 256 MiB system).
>
> Fix this by correcting the calculation of the number of GiBs of RAM in
> the system. Invert the order of the min/max operations, to keep on
> calculating in pages until the last step, which aids readability.
>
> Fixes: 1d659236fb43c4d2 ("dma-pool: scale the default DMA coherent pool size
> with memory capacity")
> Signed-off-by: Geert Uytterhoeven
> Acked-by: David Rientjes
This patch results in a boot failure in some of my powerpc boot tests,
specifically those testing boots from mptsas1068 devices. Error message:
mptsas :00:02.0: enabling device ( -> 0002)
mptbase: ioc0: Initiating bringup
ioc0: LSISAS1068 A0: Capabilities={Initiator}
mptbase: ioc0: ERROR - Unable to allocate Reply, Request, Chain Buffers!
mptbase: ioc0: ERROR - didn't initialize properly! (-3)
mptsas: probe of :00:02.0 failed with error -3
Configuration is bamboo:44x/bamboo_defconfig plus various added drivers.
Qemu command line is
qemu-system-ppc -kernel vmlinux -M bamboo \
-m 256 -no-reboot -snapshot -device mptsas1068,id=scsi \
-device scsi-hd,bus=scsi.0,drive=d0,wwn=0x5000c50015ea71ac -drive \
file=rootfs.ext2,format=raw,if=none,id=d0 \
--append "panic=-1 slub_debug=FZPUA root=/dev/sda mem=256M console=ttyS0"
\
-monitor none -nographic
canyonlands_defconfig with sam460ex machine and otherwise similar command line
fails as well.
Reverting this patch fixes the problem.
Guenter
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] MIPS: only select ARCH_HAS_UNCACHED_SEGMENT for non-coherent platforms
On 6/30/19 9:48 AM, Christoph Hellwig wrote:
While mips might architecturally have the uncached segment all the time,
the infrastructure to use it is only need on platforms where DMA is
at least partially incoherent. Only select it for those configuration
to fix a build failure as the arch_dma_prep_coherent symbol is also only
provided for non-coherent platforms.
Fixes: 2e96e04d25 ("MIPS: use the generic uncached segment support in
dma-direct")
Reported-by: Guenter Roeck
Signed-off-by: Christoph Hellwig
---
This patch fixes
kernel/dma/direct.c:144: undefined reference to `arch_dma_prep_coherent'
Tested-by: Guenter Roeck
Mips images still don't boot in -next after this patch is applied, so
"Tested-by:" only means that affected configurations now build without
link error, not that they actually work.
Guenter
arch/mips/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 61a390c2f2c1..caf480275a31 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -8,7 +8,6 @@ config MIPS
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
select ARCH_HAS_UBSAN_SANITIZE_ALL
- select ARCH_HAS_UNCACHED_SEGMENT
select ARCH_SUPPORTS_UPROBES
select ARCH_USE_BUILTIN_BSWAP
select ARCH_USE_CMPXCHG_LOCKREF if 64BIT
@@ -1120,6 +1119,7 @@ config DMA_NONCOHERENT
bool
select ARCH_HAS_DMA_MMAP_PGPROT
select ARCH_HAS_SYNC_DMA_FOR_DEVICE
+ select ARCH_HAS_UNCACHED_SEGMENT
select NEED_DMA_MAP_STATE
select ARCH_HAS_DMA_COHERENT_TO_PFN
select DMA_NONCOHERENT_CACHE_SYNC
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 6/7] dma-direct: handle DMA_ATTR_NO_KERNEL_MAPPING in common code
On Fri, Jun 14, 2019 at 04:44:30PM +0200, Christoph Hellwig wrote: > DMA_ATTR_NO_KERNEL_MAPPING is generally implemented by allocating > normal cacheable pages or CMA memory, and then returning the page > pointer as the opaque handle. Lift that code from the xtensa and > generic dma remapping implementations into the generic dma-direct > code so that we don't even call arch_dma_alloc for these allocations. > > Signed-off-by: Christoph Hellwig This patch results in build failures for mips:nlm_xlp_defconfig and mips:cavium_octeon_defconfig. kernel/dma/direct.c:144: undefined reference to `arch_dma_prep_coherent' Reverting the patch fixes the problem. Guenter ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [15/15] dma-mapping: bypass indirect calls for dma-direct
Hi, On Fri, Dec 07, 2018 at 11:07:20AM -0800, Christoph Hellwig wrote: > Avoid expensive indirect calls in the fast path DMA mapping > operations by directly calling the dma_direct_* ops if we are using > the directly mapped DMA operations. > This patch results in arm64 boot failures. Reverting the patch fixes the problem. Bisect results are attached. Per logs, the system fails to instantiate the root device. Examples from two logs: [ 22.843080] nvme nvme0: pci function :00:02.0 [ 22.853820] nvme :00:02.0: enabling device ( -> 0002) [ 22.884178] nvme nvme0: Removing after probe failure status: -12 [ 15.451963] xhci_hcd :00:02.0: xHCI Host Controller [ 15.453294] xhci_hcd :00:02.0: new USB bus registered, assigned bus number 1 [ 15.456042] xhci_hcd :00:02.0: can't setup: -12 [ 15.457003] xhci_hcd :00:02.0: USB bus 1 deregistered [ 15.458340] xhci_hcd :00:02.0: init :00:02.0 fail, -12 [ 15.458825] xhci_hcd: probe of :00:02.0 failed with error -12 Guenter --- # bad: [d14b746c6c1ca310f679ef13f661587454e2c588] Add linux-next specific files for 20181214 # good: [40e020c129cfc991e8ab4736d2665351ffd1468d] Linux 4.20-rc6 git bisect start 'HEAD' 'v4.20-rc6' # bad: [ddfdda7f7d1ebdca0851f30a814e76749f08be99] Merge remote-tracking branch 'spi-nor/spi-nor/next' git bisect bad ddfdda7f7d1ebdca0851f30a814e76749f08be99 # bad: [466d2f8b964745cc8db7f126607e19526385f2d5] Merge remote-tracking branch 'file-locks/locks-next' git bisect bad 466d2f8b964745cc8db7f126607e19526385f2d5 # bad: [c43abf670f074a3eba2eebf9568ba95b2fe57f00] Merge remote-tracking branch 'arm-soc/for-next' git bisect bad c43abf670f074a3eba2eebf9568ba95b2fe57f00 # good: [e4337d9d50eb940a25d3808ef76bb0eaa61a0146] Merge branch 'next/dt' into for-next git bisect good e4337d9d50eb940a25d3808ef76bb0eaa61a0146 # bad: [32d851d8e81b1152d3e663b6c0b318474d649098] Merge remote-tracking branch 'dma-mapping/for-next' git bisect bad 32d851d8e81b1152d3e663b6c0b318474d649098 # good: [32550839013d8e72d35c1cc0a756c818d7f9ae32] Merge remote-tracking branch 'scsi-fixes/fixes' git bisect good 32550839013d8e72d35c1cc0a756c818d7f9ae32 # good: [8ea3ac17b6557f30697c624d1cd4ff2b30af82e1] Merge remote-tracking branch 'kbuild/for-next' git bisect good 8ea3ac17b6557f30697c624d1cd4ff2b30af82e1 # good: [ad78dee0b630527bdfed809d1f5ed95c601886ae] dma-debug: Batch dma_debug_entry allocation git bisect good ad78dee0b630527bdfed809d1f5ed95c601886ae # good: [55897af63091ebc2c3f239c6af748113ac50] dma-direct: merge swiotlb_dma_ops into the dma_direct code git bisect good 55897af63091ebc2c3f239c6af748113ac50 # good: [7d32be2e5abb2d88cf321357178d05c461b1cc83] leaking_addresses: do not parse binary files git bisect good 7d32be2e5abb2d88cf321357178d05c461b1cc83 # good: [9db33987ee2e5abb32a40dca44a2953391786833] leaking_addresses: remove version number git bisect good 9db33987ee2e5abb32a40dca44a2953391786833 # good: [7fd0d1346c1f96371a9a4996a590b86d570098f9] Merge remote-tracking branch 'leaks/leaks-next' git bisect good 7fd0d1346c1f96371a9a4996a590b86d570098f9 # bad: [356da6d0cde3323236977fce54c1f9612a742036] dma-mapping: bypass indirect calls for dma-direct git bisect bad 356da6d0cde3323236977fce54c1f9612a742036 # good: [190d4e5916a2d70a11009022b968fca948fb5dc7] vmd: use the proper dma_* APIs instead of direct methods calls git bisect good 190d4e5916a2d70a11009022b968fca948fb5dc7 # first bad commit: [356da6d0cde3323236977fce54c1f9612a742036] dma-mapping: bypass indirect calls for dma-direct ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 3/6] sparc: remove the sparc32_dma_ops indirection
On 12/15/18 2:47 AM, Christoph Hellwig wrote: On Fri, Dec 14, 2018 at 10:30:18PM -0800, Guenter Roeck wrote: and so on, until qemu is terminated. This is seen with all sparc32 qemu emulations. Reverting the patch fixes the problem. Hi Guenter, can you check which of the three new ops is used in this case? Or provide the qemu config and rootfs? sparc32 defconfig+CONFIG_SQUASHFS=y+CONFIG_DEVTMPFS=y, and: qemu-system-sparc -M SPARCClassic -kernel arch/sparc/boot/image \ -no-reboot -snapshot -drive file=/var/cache/buildbot/sparc/hda.sqf,if=scsi,format=raw \ -append 'root=/dev/sda rw init=/sbin/init.sh panic=1 console=ttyS0' \ -nographic qemu version doesn't seem to matter. I used gcc-7.3.0 using the toolchain from kernel.org to build the image. Root file system is at https://github.com/groeck/linux-build-test/tree/master/rootfs/sparc/. Guenter ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 3/6] sparc: remove the sparc32_dma_ops indirection
On Sat, Dec 08, 2018 at 09:41:12AM -0800, Christoph Hellwig wrote: > There is no good reason to have a double indirection for the sparc32 > dma ops, so remove the sparc32_dma_ops and define separate dma_map_ops > instance for the different IOMMU types. > Except maybe this: scsi host0: esp scsi host0: Data transfer overflow. scsi host0: cur_residue[0] tot_residue[-36] len[36] scsi 0:0:0:0: Direct-Access QEMU QEMU HARDDISK2.5+ PQ: 0 ANSI: 5 scsi target0:0:0: Beginning Domain Validation scsi host0: Data transfer overflow. scsi host0: cur_residue[0] tot_residue[-36] len[36] scsi host0: Data transfer overflow. scsi host0: cur_residue[0] tot_residue[-36] len[36] scsi host0: Data transfer overflow. scsi host0: cur_residue[0] tot_residue[-36] len[36] scsi host0: Data transfer overflow. scsi host0: cur_residue[0] tot_residue[-36] len[36] and so on, until qemu is terminated. This is seen with all sparc32 qemu emulations. Reverting the patch fixes the problem. Guenter ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] dma-direct: always allow dma mask <= physiscal memory size
On Fri, Sep 07, 2018 at 09:31:58AM +0200, Christoph Hellwig wrote: > This way an architecture with less than 4G of RAM can support dma_mask > smaller than 32-bit without a ZONE_DMA. Apparently that is a common > case on powerpc. > > Signed-off-by: Christoph Hellwig > Reviewed-by: Robin Murphy This patch causes widespread boot failures on mips and x86_64. Common denominators: ahci 0002:01:00.0: 32-bit DMA enable failed ahci: probe of 0002:01:00.0 failed with error -5 sym0: No suitable DMA available sym0: giving up ... pcnet32 :00:0b.0: enabling device ( -> 0003) pcnet32: architecture does not support 32bit PCI busmaster DMA pcnet32: probe of :00:0b.0 failed with error -5 There may be others; I didn't check all the logs. Sample bisect log is attached (from mips64). Bisect on x86_64 points to the same patch as culprit. Guenter --- # bad: [8f84a21675f06c8aea55148ce37a618c6fe52a0b] Add linux-next specific files for 20181003 # good: [17b57b1883c1285f3d0dc2266e8f79286a7bef38] Linux 4.19-rc6 git bisect start 'HEAD' 'v4.19-rc6' # bad: [ab92e1776a64d9894166e771faaaeecff890ec6e] Merge remote-tracking branch 'crypto/master' git bisect bad ab92e1776a64d9894166e771faaaeecff890ec6e # bad: [c850e425cfa466e5ce1d59dd3aad73ae4fd52ba9] Merge remote-tracking branch 'xfs/for-next' git bisect bad c850e425cfa466e5ce1d59dd3aad73ae4fd52ba9 # good: [56fc7d0094442afc18b5106b8df7c59a3c36869d] arm-soc: document merges git bisect good 56fc7d0094442afc18b5106b8df7c59a3c36869d # bad: [4a83c1f489745f8e520a0686235f3a95b9374aab] Merge remote-tracking branch 'arm64/for-next/core' git bisect bad 4a83c1f489745f8e520a0686235f3a95b9374aab # bad: [6de4dcae0d1577efb3a551c7933945da033e9717] Merge remote-tracking branch 'dma-mapping/for-next' git bisect bad 6de4dcae0d1577efb3a551c7933945da033e9717 # good: [ce41c6b97f00e24bb23412e17eb0d992a97ffb48] Merge remote-tracking branch 'net/master' git bisect good ce41c6b97f00e24bb23412e17eb0d992a97ffb48 # good: [06f60b8cb4f884ae0c37b8f7095e021a7531cb87] Merge remote-tracking branch 'scsi-fixes/fixes' git bisect good 06f60b8cb4f884ae0c37b8f7095e021a7531cb87 # good: [f9d39ce558b1455f8f91387d7238eb837735e325] Merge remote-tracking branch 'leaks/leaks-next' git bisect good f9d39ce558b1455f8f91387d7238eb837735e325 # good: [f3ecc0ff0457eae93503792c6fc35921fa8a6204] dma-mapping: move the dma_coherent flag to struct device git bisect good f3ecc0ff0457eae93503792c6fc35921fa8a6204 # good: [c6d4381220a0087ce19dbf6984d92c451bd6b364] dma-mapping: make the get_required_mask method available unconditionally git bisect good c6d4381220a0087ce19dbf6984d92c451bd6b364 # good: [b4ebe6063204da58e48600b810a97c29ae9e5d12] dma-direct: implement complete bus_dma_mask handling git bisect good b4ebe6063204da58e48600b810a97c29ae9e5d12 # bad: [6db37ad7c27bda2f62d1ef6ad0496e359c562c1a] dma-mapping: move dma_default_get_required_mask under ifdef git bisect bad 6db37ad7c27bda2f62d1ef6ad0496e359c562c1a # bad: [9d7a224b463e1cf1178570b57b6497240fd79bc3] dma-direct: always allow dma mask <= physiscal memory size git bisect bad 9d7a224b463e1cf1178570b57b6497240fd79bc3 # first bad commit: [9d7a224b463e1cf1178570b57b6497240fd79bc3] dma-direct: always allow dma mask <= physiscal memory size ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 4/4] dma-mapping: clear dev->dma_ops in arch_teardown_dma_ops
Hi, On Mon, Aug 27, 2018 at 10:47:11AM +0200, Christoph Hellwig wrote: > There is no reason to leave the per-device dma_ops around when > deconfiguring a device, so move this code from arm64 into the > common code. > Signed-off-by: Christoph Hellwig > Reviewed-by: Robin Murphy This patch causes various ppc images to crash in -next due to NULL DMA ops in dma_alloc_attrs(). Looking into the code, the macio driver tries to instantiate on the :f0:0d.0 PCI address (the driver maps to all Apple PCI IDs) and fails. This results in a call to arch_teardown_dma_ops(). Later, the same device pointer is used to instantiate ohci-pci, which crashes in probe because the dma_ops pointer has been cleared. I don't claim to fully understand the code, but to me it looks like the pci device is allocated and waiting for a driver to attach to. See arch/powerpc/kernel/pci_of_scan.c:of_create_pci_dev(). If attaching a driver (here: macio) fails, the same device pointer is then reused for the next matching driver until a match is found and the device is successfully instantiated. Of course this fails quite badly if the device pointer has been scrubbed after the first failure. I don't know if this is generic PCI behavior or ppc specific. I am copying pci and ppc maintainers for additional input. Either case, reverting the patch fixes the problem. Guenter --- ohci-pci :f0:0d.0: OHCI PCI host controller ohci-pci :f0:0d.0: new USB bus registered, assigned bus number 1 [ cut here ] kernel BUG at ./include/linux/dma-mapping.h:516! Oops: Exception in kernel mode, sig: 5 [#1] BE PREEMPT SMP NR_CPUS=4 NUMA PowerMac Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW 4.19.0-rc4-next-20180921-dirty #1 NIP: c086b824 LR: c086b5dc CTR: c086dd70 REGS: c0003d30f0b0 TRAP: 0700 Tainted: GW (4.19.0-rc4-next-20180921-dirty) MSR: 8002b032 CR: 28008842 XER: IRQMASK: 0 GPR00: c086b5dc c0003d30f330 c1199900 c0003d3ce898 GPR04: c115b798 c0003d8c3a48 GPR08: ff00 0020 GPR12: 24008442 c1299000 c000f720 GPR16: GPR20: GPR24: c10452e8 c1045420 0080 GPR28: 001c c1045408 c0003d3ce898 c0003d8c3a30 NIP [c086b824] .ohci_init+0x564/0x570 LR [c086b5dc] .ohci_init+0x31c/0x570 Call Trace: [c0003d30f330] [c086b5dc] .ohci_init+0x31c/0x570 (unreliable) [c0003d30f3c0] [c086de58] .ohci_pci_reset+0xa8/0xb0 [c0003d30f440] [c08335ec] .usb_add_hcd+0x35c/0x9b0 [c0003d30f510] [c084ea90] .usb_hcd_pci_probe+0x320/0x510 [c0003d30f5c0] [c06c7df8] .local_pci_probe+0x68/0x140 [c0003d30f660] [c06c92a4] .pci_device_probe+0x144/0x210 [c0003d30f710] [c074cd48] .really_probe+0x2a8/0x3c0 [c0003d30f7b0] [c074d100] .driver_probe_device+0x80/0x170 [c0003d30f840] [c074d33c] .__driver_attach+0x14c/0x150 [c0003d30f8d0] [c0749c6c] .bus_for_each_dev+0xac/0x100 [c0003d30f970] [c074c334] .driver_attach+0x34/0x50 [c0003d30f9f0] [c074b9b8] .bus_add_driver+0x178/0x2f0 [c0003d30fa90] [c074e560] .driver_register+0x90/0x1a0 [c0003d30fb10] [c06c707c] .__pci_register_driver+0x6c/0x90 [c0003d30fba0] [c0f39f14] .ohci_pci_init+0x90/0xac [c0003d30fc10] [c000f380] .do_one_initcall+0x70/0x2d0 [c0003d30fce0] [c0edfca4] .kernel_init_freeable+0x3b8/0x4b0 [c0003d30fdb0] [c000f744] .kernel_init+0x24/0x160 [c0003d30fe30] [c000b7a4] .ret_from_kernel_thread+0x58/0x74 --- # bad: [46c163a036b41a29b0ec3c475bf97515d755ff41] Add linux-next specific files for 20180921 # good: [7876320f88802b22d4e2daf7eb027dd14175a0f8] Linux 4.19-rc4 git bisect start 'HEAD' 'v4.19-rc4' # bad: [03b5533c4d89cc558063a98fa4201a5d2b4eb1f7] Merge remote-tracking branch 'crypto/master' git bisect bad 03b5533c4d89cc558063a98fa4201a5d2b4eb1f7 # bad: [62c54071a46255d59e26e95528b80bf432796cb4] Merge remote-tracking branch 'v9fs/9p-next' git bisect bad 62c54071a46255d59e26e95528b80bf432796cb4 # bad: [1eee72bfcf0977daca74e9f902956adbb4f38847] Merge remote-tracking branch 'realtek/for-next' git bisect bad 1eee72bfcf0977daca74e9f902956adbb4f38847 # good: [30d3220045f49c707bbeec1d35423bd60488c433] Merge remote-tracking branch 'scsi-fixes/fixes' git bisect good 30d3220045f49c707bbeec1d35423bd60488c433 # bad: [a31a9772a2aa569dc279468da4be555b737e51f8] Merge remote-tracking branch 'at91/at91-next' git bisect bad a31a9772a2aa569dc279468da4be555b737e51f8 # bad: [3f52a0ad91857e78a5feed28327eafa11c44412c] Merge remote-tracki
Re: [PATCH v3] sparc: set a default 32-bit dma mask for OF devices
On 09/01/2018 06:49 AM, Christoph Hellwig wrote:
This keeps the historic default behavior for devices without a DMA mask,
but removes the warning about a lacking DMA mask for doing DMA without
a mask.
Reported-by: Meelis Roos
Signed-off-by: Christoph Hellwig
Tested-by: Guenter Roeck
---
Had to redo this because the platform_device patch that the previous
version dependend on had to be dropped.
arch/sparc/kernel/of_device_32.c | 4
arch/sparc/kernel/of_device_64.c | 3 +++
2 files changed, 7 insertions(+)
diff --git a/arch/sparc/kernel/of_device_32.c b/arch/sparc/kernel/of_device_32.c
index 3641a294ed54..e4abe9b8f97a 100644
--- a/arch/sparc/kernel/of_device_32.c
+++ b/arch/sparc/kernel/of_device_32.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
@@ -381,6 +382,9 @@ static struct platform_device * __init scan_one_device(struct device_node *dp,
else
dev_set_name(&op->dev, "%08x", dp->phandle);
+ op->dev.coherent_dma_mask = DMA_BIT_MASK(32);
+ op->dev.dma_mask = &op->dev.coherent_dma_mask;
+
if (of_device_register(op)) {
printk("%s: Could not register of device.\n",
dp->full_name);
diff --git a/arch/sparc/kernel/of_device_64.c b/arch/sparc/kernel/of_device_64.c
index 44e4d4435bed..6df6086968c6 100644
--- a/arch/sparc/kernel/of_device_64.c
+++ b/arch/sparc/kernel/of_device_64.c
@@ -2,6 +2,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -675,6 +676,8 @@ static struct platform_device * __init
scan_one_device(struct device_node *dp,
dev_set_name(&op->dev, "root");
else
dev_set_name(&op->dev, "%08x", dp->phandle);
+ op->dev.coherent_dma_mask = DMA_BIT_MASK(32);
+ op->dev.dma_mask = &op->dev.coherent_dma_mask;
if (of_device_register(op)) {
printk("%s: Could not register of device.\n",
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: various dma_mask fixups
On Wed, Aug 29, 2018 at 03:38:21PM -0700, Guenter Roeck wrote:
> On Wed, Aug 29, 2018 at 08:23:58AM +0200, Christoph Hellwig wrote:
> > Fix warnings and regressions from requiring a dma mask.
>
> With this series applied, I see the following in my sh4 boot tests.
>
> sb 1-1: new full-speed USB device number 2 using sm501-usb
> sm501-usb sm501-usb: OHCI Unrecoverable Error, disabled
> sm501-usb sm501-usb: HC died; cleaning up
>
> This is a persistent problem. Reverting upstream commit 2f606da7823
> ("mfd: sm501: Set coherent_dma_mask when creating subdevices") does not
> make a difference.
>
This failure is now seen in -next.
Guenter
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: various dma_mask fixups
On Wed, Aug 29, 2018 at 08:23:58AM +0200, Christoph Hellwig wrote:
> Fix warnings and regressions from requiring a dma mask.
With this series applied, I see the following in my sh4 boot tests.
sb 1-1: new full-speed USB device number 2 using sm501-usb
sm501-usb sm501-usb: OHCI Unrecoverable Error, disabled
sm501-usb sm501-usb: HC died; cleaning up
This is a persistent problem. Reverting upstream commit 2f606da7823
("mfd: sm501: Set coherent_dma_mask when creating subdevices") does not
make a difference.
The problem is gone if I do not apply 'driver core: initialize a default
DMA mask for platform device'.
On the plus side, the sparc warnings are gone.
Guenter
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC PATCH] m68k: set dma and coherent masks for Macintosh SONIC based ethernet
Hi,
On Sun, May 27, 2018 at 01:01:11PM +1000, Finn Thain wrote:
> On Sat, 26 May 2018, Guenter Roeck wrote:
>
> > As of commit 205e1b7f51e4 ("dma-mapping: warn when there is no
> > coherent_dma_mask") the NatSemi SONIC Ethernet driver is issuing the
> > following warning on driver initialization on Macintosh q800 systems.
> >
> > SONIC ethernet @50f0a000, MAC 08:00:07:12:34:56, IRQ 3
> > [ cut here ]
> > WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516
> > macsonic_init+0x6a/0x15a
> > Modules linked in:
> > CPU: 0 PID: 1 Comm: swapper Not tainted 4.17.0-rc6-mac-00286-g527f47c #1
> > Stack from 0781fdd8:
> > 0781fdd8 003615b3 000181ba 05c4 07a24cbc
> > 20e8
> > 07a24800 002c196c 0001824e 00334c06 0204 001f782a 0009
> > 003358d9 001f782a 00334c06 0204 0003 07a24800
> > 002b5cb6 000372ec 001f8b1a 07a24800 00359203 50f0a000 07a14a48 0003
> > 07845c0a 0039dcca 003c835c 003c835c 0035b924 001c19de 07845c00
> > 07845c0a 0039dcca 001c06dc 07845c0a 0781fed8 0007 0054d040 07845c0a
> > Call Trace: [<000181ba>] __warn+0xc0/0xc2
> > [<20e8>] do_one_initcall+0x0/0x140
> > [<0001824e>] warn_slowpath_null+0x26/0x2c
> > [<001f782a>] macsonic_init+0x6a/0x15a
> > [<001f782a>] macsonic_init+0x6a/0x15a
> > [<002b5cb6>] memcmp+0x0/0x2a
> > [<000372ec>] printk+0x0/0x18
> > [<001f8b1a>] mac_sonic_platform_probe+0x380/0x404
> >
> > As per the warning the coherent_dma_mask is not set on this device.
> > There is nothing special about the DMA memory coherency on this hardware
> > so we can just set the mask to 32bits in the platform data for the FEC
> > ethernet devices.
> >
> > Signed-off-by: Guenter Roeck
>
> Acked-by: Finn Thain
>
> Geert, assuming that Guenter's patch is acceptable, would you also accept
> a similar patch for the "macmace" platform device?
>
> > ---
> > Modeled after f61e64310b75 ("m68k: set dma and coherent masks for platform
> > FEC ethernets").
> >
> > RFC: Is "nothing special about the DMA memory coherency" correect ?
> >
>
> As I understand it, "cache-coherence" is meaningless unless you have
> multiple CPU cores and caches. If there's only one CPU core, its cache
Good point. Maybe it would be better to limit the warning to SMP systems
instead of (unnecessarily) fixing drivers all over the place ?
Guenter
---
>From 9eea0e1b609b69094682757285fd7f89d3930a8e Mon Sep 17 00:00:00 2001
From: Guenter Roeck
Date: Sat, 26 May 2018 21:08:39 -0700
Subject: [PATCH] dma-mapping: Warn about coherent_dma_mask only for SMP
As of commit 205e1b7f51e4 ("dma-mapping: warn when there is no
coherent_dma_mask") is unconditional, even if the affected system
is a single-CPU system where coherence is irrelevant. Limit the
warning to SMP configurations to reduce the noise.
Fixes: 205e1b7f51e4 ("dma-mapping: warn when there is no coherent_dma_mask")
Signed-off-by: Guenter Roeck
---
include/linux/dma-mapping.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index f8ab1c0f589e..ffbb39d84797 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -513,7 +513,7 @@ static inline void *dma_alloc_attrs(struct device *dev,
size_t size,
void *cpu_addr;
BUG_ON(!ops);
- WARN_ON_ONCE(dev && !dev->coherent_dma_mask);
+ WARN_ON_ONCE(IS_ENABLED(CONFIG_SMP) && dev && !dev->coherent_dma_mask);
if (dma_alloc_from_dev_coherent(dev, size, dma_handle, &cpu_addr))
return cpu_addr;
--
2.7.4
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH] iommu: Add missing dependencies
parisc:allmodconfig, xtensa:allmodconfig, and possibly others generate the following Kconfig warning. warning: (IPMMU_VMSA && ARM_SMMU && ARM_SMMU_V3 && QCOM_IOMMU) selects IOMMU_IO_PGTABLE_LPAE which has unmet direct dependencies (IOMMU_SUPPORT && HAS_DMA && (ARM || ARM64 || COMPILE_TEST && !GENERIC_ATOMIC64)) IOMMU_IO_PGTABLE_LPAE depends on (COMPILE_TEST && !GENERIC_ATOMIC64), so any configuration option selecting it needs to have the same dependencies. Signed-off-by: Guenter Roeck --- drivers/iommu/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig index 49bd2ab8c507..8530ef78925d 100644 --- a/drivers/iommu/Kconfig +++ b/drivers/iommu/Kconfig @@ -278,7 +278,7 @@ config EXYNOS_IOMMU_DEBUG config IPMMU_VMSA bool "Renesas VMSA-compatible IPMMU" depends on ARM || IOMMU_DMA - depends on ARCH_RENESAS || COMPILE_TEST + depends on ARCH_RENESAS || (COMPILE_TEST && !GENERIC_ATOMIC64) select IOMMU_API select IOMMU_IO_PGTABLE_LPAE select ARM_DMA_USE_IOMMU @@ -373,7 +373,7 @@ config MTK_IOMMU_V1 config QCOM_IOMMU # Note: iommu drivers cannot (yet?) be built as modules bool "Qualcomm IOMMU Support" - depends on ARCH_QCOM || COMPILE_TEST + depends on ARCH_QCOM || (COMPILE_TEST && !GENERIC_ATOMIC64) select IOMMU_API select IOMMU_IO_PGTABLE_LPAE select ARM_DMA_USE_IOMMU -- 2.7.4 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [v9,4/5] iommu/mediatek: Add mt8173 IOMMU driver
On Wed, Feb 17, 2016 at 08:46:13AM +0800, Yong Wu wrote: > This patch adds support for mediatek m4u (MultiMedia Memory Management > Unit). > > Signed-off-by: Yong Wu > Reviewed-by: Robin Murphy > > --- > drivers/iommu/Kconfig | 16 + > drivers/iommu/Makefile| 1 + > drivers/iommu/mtk_iommu.c | 732 > ++ > 3 files changed, 749 insertions(+) > create mode 100644 drivers/iommu/mtk_iommu.c > > diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig > index a1e75cb..4922aa8 100644 > --- a/drivers/iommu/Kconfig > +++ b/drivers/iommu/Kconfig > @@ -318,4 +318,20 @@ config S390_IOMMU > help > Support for the IOMMU API for s390 PCI devices. > > +config MTK_IOMMU > + bool "MTK IOMMU Support" > + depends on ARM || ARM64 > + depends on ARCH_MEDIATEK || COMPILE_TEST > + select IOMMU_API > + select IOMMU_DMA > + select IOMMU_IO_PGTABLE_ARMV7S > + select MEMORY > + select MTK_SMI > + help > + Support for the M4U on certain Mediatek SOCs. M4U is MultiMedia > + Memory Management Unit. This option enables remapping of DMA memory > + accesses for the multimedia subsystem. > + > + If unsure, say N here. > + > endif # IOMMU_SUPPORT > diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile > index 42fc0c2..44ae2e0 100644 > --- a/drivers/iommu/Makefile > +++ b/drivers/iommu/Makefile > @@ -16,6 +16,7 @@ obj-$(CONFIG_INTEL_IOMMU) += intel-iommu.o > obj-$(CONFIG_INTEL_IOMMU_SVM) += intel-svm.o > obj-$(CONFIG_IPMMU_VMSA) += ipmmu-vmsa.o > obj-$(CONFIG_IRQ_REMAP) += intel_irq_remapping.o irq_remapping.o > +obj-$(CONFIG_MTK_IOMMU) += mtk_iommu.o > obj-$(CONFIG_OMAP_IOMMU) += omap-iommu.o > obj-$(CONFIG_OMAP_IOMMU_DEBUG) += omap-iommu-debug.o > obj-$(CONFIG_ROCKCHIP_IOMMU) += rockchip-iommu.o > diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c > new file mode 100644 > index 000..60fe97b > --- /dev/null > +++ b/drivers/iommu/mtk_iommu.c > @@ -0,0 +1,732 @@ > +/* > + * Copyright (c) 2015-2016 MediaTek Inc. > + * Author: Yong Wu > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 as > + * published by the Free Software Foundation. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + */ > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + Some missing includes: linux/bug.h for WARN_ON() linux/device.h for dev_xxx() error messages, dev_get_drvdata(), etc. linux/err.h for error functions (IS_ERR, error definitions) linux/slab.h for kzalloc() etc. linux/spinlock.h for spinlock functions asm/barrier.h for wmb() Guenter ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC PATCH] PCI: Introduce new device binding path using pci_dev.driver_override
On 04/04/2014 06:35 PM, Kim Phillips wrote:
Needed by platform device drivers, such as the vfio-platform driver [1],
in order to bypass the existing OF, ACPI, id_table and name string matches,
and successfully be able to be bound to any device, like so:
echo vfio-platform > /sys/bus/platform/devices/fff51000.ethernet/driver_override
echo fff51000.ethernet >
/sys/bus/platform/devices/fff51000.ethernet/driver/unbind
echo fff51000.ethernet > /sys/bus/platform/drivers_probe
This mimics "PCI: Introduce new device binding path using
pci_dev.driver_override" [2], which is an interface enhancement
for more deterministic PCI device binding, e.g., when in the
presence of hotplug.
[1] http://lkml.iu.edu/hypermail/linux/kernel/1402.1/00177.html
[2] http://thread.gmane.org/gmane.linux.kernel.iommu/4605
Signed-off-by: Kim Phillips
---
if this looks ok, should it be included in the next version of the
vfio-platform submission series, like last time ([1] above)?
Documentation/ABI/testing/sysfs-bus-platform | 17 ++
drivers/base/platform.c | 46
include/linux/platform_device.h | 1 +
3 files changed, 64 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-bus-platform
diff --git a/Documentation/ABI/testing/sysfs-bus-platform
b/Documentation/ABI/testing/sysfs-bus-platform
new file mode 100644
index 000..6b14a6a
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-platform
@@ -0,0 +1,17 @@
+What: /sys/bus/platform/devices/.../driver_override
+Date: April 2014
+Contact: Kim Phillips
+Description:
+ This file allows the driver for a device to be specified
+ which will override standard OF, ACPI, ID table, and name
+ matching. When specified, only a driver with a name matching
+ the value written to driver_override will have an opportunity
+ to bind to the device. The override may be cleared by
+ writing an empty string (ex. echo > driver_override), returning
+ the device to standard matching rules binding. Writing to
+ driver_override does not automatically unbind the device from
+ its current driver or make any attempt to automatically load
+ the specified driver name. If no driver with a matching name
+ is currently loaded in the kernel, no match will be found.
+ This also allows devices to opt-out of driver binding using
+ a driver_override name such as "none".
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index e714709..ded1db1 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include "base.h"
#include "power/power.h"
@@ -690,8 +691,49 @@ static ssize_t modalias_show(struct device *dev, struct
device_attribute *a,
}
static DEVICE_ATTR_RO(modalias);
+static ssize_t driver_override_store(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t count)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ char *driver_override, *old = pdev->driver_override;
+
+ if (count > PATH_MAX)
+ return -EINVAL;
+
+ driver_override = kstrndup(buf, count, GFP_KERNEL);
+ if (!driver_override)
+ return -ENOMEM;
+
+ while (strlen(driver_override) &&
+ driver_override[strlen(driver_override) - 1] == '\n')
+ driver_override[strlen(driver_override) - 1] = '\0';
+
Seems to me that something like
cp = strchr(driver_override, '\n');
if (cp)
*cp = '\0';
would be much simpler.
Guenter
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
