Aw: Re: helping with remapping vmem for dma
> Gesendet: Freitag, 17. Juni 2022 um 19:22 Uhr > Von: "Robin Murphy" > An: "Frank Wunderlich" , "Christoph Hellwig" > > Cc: linux-ker...@vger.kernel.org, iommu@lists.linux-foundation.org, "Marek > Szyprowski" > Betreff: Re: helping with remapping vmem for dma > > On 2022-06-17 17:17, Frank Wunderlich wrote: > > Am 15. Juni 2022 15:17:00 MESZ schrieb Christoph Hellwig : > >> On Wed, Jun 15, 2022 at 02:15:33PM +0100, Robin Murphy wrote: > >>> Put simply, if you want to call dma_map_single() on a buffer, then that > >>> buffer needs to be allocated with kmalloc() (or technically alloc_pages(), > >>> but then dma_map_page() would make more sense when dealing with entire > >>> pages. > >> > >> Yes. It sounds like the memory here comes from the dma coherent > >> allocator, in which case the code need to use the address returned > >> by that and not create another mapping. > > > > Hi > > > > traced it to buffer allocated as simple uint8-array [1]: > > > > UINT_8 aucBuffer[sizeof(INIT_HIF_RX_HEADER_T) + > > sizeof(INIT_EVENT_CMD_RESULT)]; > > Ah, so it's trying to do DMA with a stack variable? CONFIG_DMA_API_DEBUG > is your friend; it should have screamed about that specifically. > Allocate this buffer properly to begin with, and free it again on the > way out of the function (it's surely not worth having to make a > temporary copy further down the callchain). The kmalloc flags can > probably be regular GFP_KERNEL, unless this can be called from more > restrictive contexts like an IRQ handler - the fact that it might be > mapped for DMA later is essentially irrelevant in that respect. Hi, simply replaced the stack-vars to uint_8-pointers and using kmalloc/kfree for memory handling (needed to replace some returns to goto to always free memory). Thanks very much for support, driver is now working again :) https://github.com/frank-w/BPI-R2-4.14/commit/7f3a721d5b0d8ca44935c23d5513a19cc57786c0 > Thanks, > Robin. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: helping with remapping vmem for dma
Am 15. Juni 2022 15:17:00 MESZ schrieb Christoph Hellwig :
>On Wed, Jun 15, 2022 at 02:15:33PM +0100, Robin Murphy wrote:
>> Put simply, if you want to call dma_map_single() on a buffer, then that
>> buffer needs to be allocated with kmalloc() (or technically alloc_pages(),
>> but then dma_map_page() would make more sense when dealing with entire
>> pages.
>
>Yes. It sounds like the memory here comes from the dma coherent
>allocator, in which case the code need to use the address returned
>by that and not create another mapping.
Hi
traced it to buffer allocated as simple uint8-array [1]:
UINT_8 aucBuffer[sizeof(INIT_HIF_RX_HEADER_T) + sizeof(INIT_EVENT_CMD_RESULT)];
and then called as
nicRxWaitResponse(prAdapter,0,aucBuffer,sizeof(INIT_HIF_RX_HEADER_T) +
sizeof(INIT_EVENT_CMD_RESULT),/* 4B + 4B */
)
this calls [2]:
WLAN_STATUS
nicRxWaitResponse(IN P_ADAPTER_T prAdapter,
IN UINT_8 ucPortIdx, OUT PUINT_8 pucRspBuffer, IN UINT_32
u4MaxRespBufferLen, OUT PUINT_32 pu4Length)
{
...
HAL_PORT_RD(prAdapter,ucPortIdx == 0 ? MCR_WRDR0 : MCR_WRDR1, u4PktLen,
pucRspBuffer, u4MaxRespBufferLen);
}
nicRxWaitResponse contains a do-while(true)-loop, but it looks like this is
failing on first call (i see my debug before call of HAL_PORT_RD only once)...
do i need kmalloc before call of nicRxWaitResponse and if yes which flags are
right here?
https://www.kernel.org/doc/htmldocs/kernel-api/API-kmalloc.html
callstack is like this:
[ 126.919569] __dma_page_dev_to_cpu from kalDevPortRead+0x3a0/0x6b4
[wlan_gen2]
[ 126.928643] kalDevPortRead [wlan_gen2] from nicRxWaitResponse+0x4c0/0x61c
[wlan_gen2]
[ 126.939752] nicRxWaitResponse [wlan_gen2] from
wlanImageSectionDownloadStatus.part.0+0xd0/0x26c [wlan_gen2]
[ 126.952783] wlanImageSectionDownloadStatus.part.0 [wlan_gen2] from
wlanImageSectionDownload+0x168/0x36c [wlan_gen2]
[ 126.966511] wlanImageSectionDownload [wlan_gen2] from
wlanAdapterStart+0x674/0xf94 [wlan_gen2]
[ 126.978367] wlanAdapterStart [wlan_gen2] from wlanProbe+0x318/0xbe8
[wlan_gen2]
[ 126.988951] wlanProbe [wlan_gen2] from HifAhbProbe+0x54/0x88 [wlan_gen2]
[ 126.998905] HifAhbProbe [wlan_gen2] from wmt_func_wifi_on+0x4c/0x150
regards Frank
[1]
https://github.com/frank-w/BPI-R2-4.14/blob/5.18-main/drivers/misc/mediatek/connectivity/wlan/gen2/common/wlan_lib.c#L3046
[2]
https://github.com/frank-w/BPI-R2-4.14/blob/5.18-main/drivers/misc/mediatek/connectivity/wlan/gen2/nic/nic_rx.c#L3604
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: helping with remapping vmem for dma
Am 15. Juni 2022 15:17:00 MESZ schrieb Christoph Hellwig : >On Wed, Jun 15, 2022 at 02:15:33PM +0100, Robin Murphy wrote: >> Put simply, if you want to call dma_map_single() on a buffer, then that >> buffer needs to be allocated with kmalloc() (or technically alloc_pages(), >> but then dma_map_page() would make more sense when dealing with entire >> pages. > >Yes. It sounds like the memory here comes from the dma coherent >allocator, in which case the code need to use the address returned >by that and not create another mapping. As i have not found position where memory is allocated (this is a very huge and dirty driver) is it maybe possible to check if buf is such "allready dma" memory (maybe is_vmalloc_addr) and call dma_single_map only if not (using original buf if yes)? But i guess it should map only a part of available (pre-allocated) memory and other parts of this are used somewhere else. So i can ran into some issues caused by sharing this full block in different functions. Hi, Thanks for first suggestions. regards Frank ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
helping with remapping vmem for dma
Hi,
i have upported a wifi-driver (mt6625l for armhf) for some time and fall now
(at least 5.18) in the
"rejecting DMA map of vmalloc memory" error [1].
maybe anybody here can guide me on how to nail it down and maybe fix it.
as far as i have debugged it, it uses dma_map_single [2] to get dma memory from
a previous
allocated memory region.
this function "kalDevPortRead" in [2] is used via macro HAL_PORT_RD [3] (used
in HAL_READ_RX_PORT
and HAL_READ_INTR_STATUS in same hal.h file)
HAL_READ_INTR_STATUS is always called with an empty int array as buf which i
guess is not the problem.
I think the issue is using the use with an preallocated prSDIOCtrl struct (have
not completely traced
it back where it is allocated).
calls of HAL_PORT_RD/HAL_READ_RX_PORT are in nic{,_rx}.c (with sdio-struct)
([4] as example)
maybe there is a simple way to get an address in preallocated memory as
replacement for the dma_map_simple call (and the unmap of course).
regards Frank
[1]
https://elixir.bootlin.com/linux/latest/source/include/linux/dma-mapping.h#L327
[2]
https://github.com/frank-w/BPI-R2-4.14/blob/5.18-main/drivers/misc/mediatek/connectivity/wlan/gen2/os/linux/hif/ahb/ahb.c#L940
[3]
https://github.com/frank-w/BPI-R2-4.14/blob/5.18-main/drivers/misc/mediatek/connectivity/wlan/gen2/include/nic/hal.h#L176
[4]
https://github.com/frank-w/BPI-R2-4.14/blob/5.18-main/drivers/misc/mediatek/connectivity/wlan/gen2/nic/nic_rx.c#L3604
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v2] iommu: Check if group is NULL before remove device
From: Frank Wunderlich
If probe_device is failing, iommu_group is not initialized because
iommu_group_add_device is not reached, so freeing it will result
in NULL pointer access.
iommu_bus_init
->bus_iommu_probe
->probe_iommu_group in for each:/* return -22 in fail case */
->iommu_probe_device
->__iommu_probe_device /* return -22 here.*/
-> ops->probe_device /* return -22 here.*/
-> iommu_group_get_for_dev
-> ops->device_group
-> iommu_group_add_device //good case
->remove_iommu_group //in fail case, it will remove group
->iommu_release_device
->iommu_group_remove_device // here we don't have group
In my case ops->probe_device (mtk_iommu_probe_device from
mtk_iommu_v1.c) is due to failing fwspec->ops mismatch.
Fixes: d72e31c93746 ("iommu: IOMMU Groups")
Signed-off-by: Frank Wunderlich
---
v2:
- commit-message with captial letters on beginning of sentenence
- added more information, many thanks to Yong Wu
---
drivers/iommu/iommu.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 5419c4b9f27a..63f0af10c403 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -924,6 +924,9 @@ void iommu_group_remove_device(struct device *dev)
struct iommu_group *group = dev->iommu_group;
struct group_device *tmp_device, *device = NULL;
+ if (!group)
+ return;
+
dev_info(dev, "Removing from iommu group %d\n", group->id);
/* Pre-notify listeners that a device is being removed. */
--
2.25.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu: check if group is NULL before remove device
Am 2021-07-15 09:20, schrieb Joerg Roedel:
On Thu, Jul 15, 2021 at 09:11:50AM +0200, Frank Wunderlich wrote:
From: Frank Wunderlich
if probe is failing, iommu_group may be not initialized,
Sentences start with capital letters.
IOMMU patch subjects too, after the 'iommu:' prefix.
so freeing it will result in NULL pointer access
Please describe in more detail how this NULL-ptr dereference is
triggered.
in my case probe (mtk_iommu_probe_device called from
__iommu_probe_device) is failing due to fwspec missing and then
dev_iommu_free/iommu_fwspec_free is called, later
iommu_group_remove_device with group=NULL
i think i've found problem:
iommu_probe_device:
group = iommu_group_get(dev);
if (!group) { //group is checked here for NULL but accessed later
ret = -ENODEV;
goto err_release; <<<
}
err_release:<<<
iommu_release_device(dev);
--
void iommu_release_device(struct device *dev)
{
...
iommu_group_remove_device(dev);
--
void iommu_group_remove_device(struct device *dev)
{
struct iommu_group *group = dev->iommu_group;
struct group_device *tmp_device, *device = NULL;
...
dev_info(dev, "Removing from iommu group %d\n", group->id); //crash
as group is NULL and not checked
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Aw: [PATCH v7 00/12] Clean up "mediatek,larb"
Full Series tested on BPI-R2/MT7623 Tested-By: Frank Wunderlich regards Frank ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu: check if group is NULL before remove device
Hi Joerg, Sorry for late reply, somehow i marked message as read without answering it. Am 15. Juli 2021 09:20:04 MESZ schrieb Joerg Roedel : >On Thu, Jul 15, 2021 at 09:11:50AM +0200, Frank Wunderlich wrote: >> From: Frank Wunderlich >> >> if probe is failing, iommu_group may be not initialized, > >Sentences start with capital letters. > >IOMMU patch subjects too, after the 'iommu:' prefix. Will fix these in v2 >> so freeing it will result in NULL pointer access > >Please describe in more detail how this NULL-ptr dereference is >triggered. I had this by testing this series: https://patchwork.kernel.org/project/linux-mediatek/list/?series=515129 Initialization in mtk driver was failed (i guess the iommu group was not yet created), cleanup was started and so this function is called with a NULL group pointer. I can try to find my debug-trace if you need a kind of backtrace. regards Frank ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH] iommu: check if group is NULL before remove device
From: Frank Wunderlich
if probe is failing, iommu_group may be not initialized,
so freeing it will result in NULL pointer access
Fixes: d72e31c93746 ("iommu: IOMMU Groups")
Signed-off-by: Frank Wunderlich
---
drivers/iommu/iommu.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 5419c4b9f27a..63f0af10c403 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -924,6 +924,9 @@ void iommu_group_remove_device(struct device *dev)
struct iommu_group *group = dev->iommu_group;
struct group_device *tmp_device, *device = NULL;
+ if (!group)
+ return;
+
dev_info(dev, "Removing from iommu group %d\n", group->id);
/* Pre-notify listeners that a device is being removed. */
--
2.25.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH] iommu: check if group is NULL before remove device
From: Frank Wunderlich
if probe is failing, iommu_group may be not initialized,
so freeing it will result in NULL pointer access
Fixes: d72e31c93746 ("iommu: IOMMU Groups")
Signed-off-by: Frank Wunderlich
---
drivers/iommu/iommu.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 5419c4b9f27a..63f0af10c403 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -924,6 +924,9 @@ void iommu_group_remove_device(struct device *dev)
struct iommu_group *group = dev->iommu_group;
struct group_device *tmp_device, *device = NULL;
+ if (!group)
+ return;
+
dev_info(dev, "Removing from iommu group %d\n", group->id);
/* Pre-notify listeners that a device is being removed. */
--
2.25.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Aw: Re: [PATCH v6 00/11] Clean up "mediatek,larb"
> Gesendet: Mittwoch, 14. Juli 2021 um 13:18 Uhr
> Von: "Yong Wu"
> Hi Frank,
>
> Thanks for your report. mt7623 use mtk_iommu_v1.c.
>
> I will try to reproduce this locally.
Hi,
as far as i have debugged it dev->iommu_group is NULL, so it crashes on first
access (dev_info)
drivers/iommu/iommu.c:
923 void iommu_group_remove_device(struct device *dev)
924 {
925 printk(KERN_ALERT "DEBUG: Passed %s %d \n",__FUNCTION__,__LINE__);
926 struct iommu_group *group = dev->iommu_group;
927 struct group_device *tmp_device, *device = NULL;
928
929 printk(KERN_ALERT "DEBUG: Passed %s %d
0x%08x\n",__FUNCTION__,__LINE__,(unsigned int)group);
930 dev_info(dev, "Removing from iommu group %d\n", group->id);
regards Frank
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Aw: [PATCH v6 00/11] Clean up "mediatek,larb"
Hi, sorry this (or the 2 depency-series) cause a NULL Pointer deref in iommu_group_remove_device on mt7623/bpi-r2 i wonder why on bootup a cleanup is run, but have no hint about this. since "dts: mtk-mdp: remove mediatek, vpu property from primary MDP device" all is good, i guess problem comes up while removing larb with DT this is backtrace [6.274465] PC is at iommu_group_remove_device+0x28/0x148 [6.279877] LR is at iommu_release_device+0x4c/0x70 [6.674347] Backtrace: [6.676797] [] (iommu_group_remove_device) from [] (iomm) [6.686221] r7: r6:c06bf04c r5:c0d7a1ac r4:c21fc010 [6.691883] [] (iommu_release_device) from [] (remove_io) [6.700689] r5: r4: [6.704265] [] (remove_iommu_group) from [] (bus_for_eac) [6.712725] [] (bus_for_each_dev) from [] (bus_set_iommu) [6.720753] r6:c331f440 r5:c1406f58 r4:ffea [6.725370] [] (bus_set_iommu) from [] (mtk_iommu_probe+) [6.733484] r7:c32db0b8 r6:c21f9c00 r5:c331f1c0 r4: [6.739145] [] (mtk_iommu_probe) from [] (platform_probe) [6.747176] r10:c21f9c10 r9:c2496f54 r8:c14623b8 r7:c14623b8 r6:c1405b90 r50 [6.755012] r4: [6.757544] [] (platform_probe) from [] (really_probe.pa) [6.766006] r7:c14623b8 r6:c1405b90 r5: r4:c21f9c10 [6.771667] [] (really_probe.part.0) from [] (really_pro) [6.779866] r7:c21f9c10 r6:c2549e74 r5:c1405b90 r4:c21f9c10 [6.785527] [] (really_probe) from [] (__driver_probe_de) [6.793984] r5:c1405b90 r4:c21f9c10 [6.797560] [] (__driver_probe_device) from [] (driver_p) [6.806543] r9:c2496f54 r8:0008 r7:c21f9c10 r6:c2549e74 r5:c14c6ec8 r4:4 [6.814291] [] (driver_probe_device) from [] (__device_a) [6.823448] r9:c2496f54 r8: r7:c21f9c10 r6:c2549e74 r5:c1405b90 r4:1 [6.831196] [] (__device_attach_driver) from [] (bus_for) [6.840007] r7:c14623b8 r6:c073635c r5:c2549e74 r4: [6.845669] [] (bus_for_each_drv) from [] (__device_atta) [6.854044] r6:0001 r5:c21f9c54 r4:c21f9c10 [6.858662] [] (__device_attach) from [] (device_initial) [6.867207] r6:c21f9c10 r5:c1406f58 r4:c1406ca0 [6.871825] [] (device_initial_probe) from [] (bus_probe) [6.880454] [] (bus_probe_device) from [] (deferred_prob) bisect shows this commit as breaking: Author: Yong Wu Date: Wed Jul 14 10:56:17 2021 +0800 iommu/mediatek: Add probe_defer for smi-larb Prepare for adding device_link. regards Frank ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Aw: [PATCH 00/18] Convert arch/arm to use iommu-dma
Tested full series on bananapi r2 (mt7623/mt2701, 5.9-rc1 + hdmi-patches), works so far fbcon+x without issues Tested-by: Frank Wunderlich regards Frank ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/mediatek: Use correct fwspec in mtk_iommu_add_device()
Tested-by: Frank Wunderlich ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Aw: Re: [BUG] "access dev->iommu_fwspec" cause crash on BPI-R2
Hi, thanks for quick reply, this seems to fix it no crash, xserver works, like revert of the commit...pushed the fix to below github-repo regards Frank > Gesendet: Dienstag, 22. Januar 2019 um 17:49 Uhr > Von: "Joerg Roedel" > An: "Frank Wunderlich" > Cc: "Matthias Brugger" , > iommu@lists.linux-foundation.org, linux-arm-ker...@lists.infradead.org, > linux-media...@lists.infradead.org, linux-ker...@vger.kernel.org, "Ryder Lee" > > Betreff: Re: [BUG] "access dev->iommu_fwspec" cause crash on BPI-R2 > > Hi Frank, > > thanks for the report! > > On Tue, Jan 22, 2019 at 05:09:09PM +0100, Frank Wunderlich wrote: > > Hi, > > > > the following Patch breaks hdmi (at least) on Bananapi R2 (mt7623): > > > > a9bf2eec5a6fc01a0a5250eaf0bf61dfd382a78a "iommu/mediatek: Use helper > > functions to access dev->iommu_fwspec" > > Does the attached diff fix the issue for you? > > Thanks, > > Joerg > > diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c > index 6ede4286b835..f60bdb85c4c0 100644 > --- a/drivers/iommu/mtk_iommu_v1.c > +++ b/drivers/iommu/mtk_iommu_v1.c > @@ -442,6 +442,10 @@ static int mtk_iommu_add_device(struct device *dev) > iommu_spec.args_count = count; > > mtk_iommu_create_mapping(dev, _spec); > + > + /* dev->iommu_fwspec might have changed */ > + fwspec = dev_iommu_fwspec_get(dev); > + > of_node_put(iommu_spec.np); > } > > ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[BUG] "access dev->iommu_fwspec" cause crash on BPI-R2
Hi, the following Patch breaks hdmi (at least) on Bananapi R2 (mt7623): a9bf2eec5a6fc01a0a5250eaf0bf61dfd382a78a "iommu/mediatek: Use helper functions to access dev->iommu_fwspec" https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/iommu/mtk_iommu_v1.c?id=a9bf2eec5a6fc01a0a5250eaf0bf61dfd382a78a [5.363509] Backtrace: [5.365946] [] (mtk_iommu_domain_free) from [] (iommu_domain_free+0x20/) [5.374670] r4:decd57a0 [5.377192] [] (iommu_domain_free) from [] (release_iommu_mapping+0x24/) [5.385922] [] (release_iommu_mapping) from [] (arm_iommu_release_mappi) [5.395943] r7: r6:decd5780 r5: r4:decd57a0 [5.401567] [] (arm_iommu_release_mapping.part.0) from [] (arch_setup_d) [5.411412] r5: r4:dead1410 [5.414968] [] (arch_setup_dma_ops) from [] (of_dma_configure+0x27c/0x3) [5.423521] r6:c0b58e20 r5: r4: [5.428109] [] (of_dma_configure) from [] (platform_dma_configure+0x28/) [5.436838] r10:c107efdc r9: r8:c10c0008 r7: r6:c1117b34 r5:dead1410 [5.444612] r4:c1117b30 [5.447131] [] (platform_dma_configure) from [] (really_probe+0xc4/0x42) [5.455602] [] (really_probe) from [] (driver_probe_device+0x88/0x1e0) [5.463814] r10: r9:c060a25c r8: r7:c1008c48 r6:c107efdc r5:c107efdc [5.471588] r4:dead1410 [5.474107] [] (driver_probe_device) from [] (__driver_attach+0x134/0x1) [5.482663] r9:c060a25c r8: r7:c1008c48 r6:c107efdc r5:dead1444 r4:dead1410 [5.490358] [] (__driver_attach) from [] (bus_for_each_dev+0x84/0xc4) [5.498480] r7:c1008c48 r6:c06080c8 r5:c107efdc r4: [5.504102] [] (bus_for_each_dev) from [] (driver_attach+0x2c/0x30) [5.512052] r7:c10bff30 r6:c107fad8 r5:decde780 r4:c107efdc [5.517675] [] (driver_attach) from [] (bus_add_driver+0x1d0/0x274) [5.525629] [] (bus_add_driver) from [] (driver_register+0x84/0x118) [5.533666] r8:c060a20c r7:c0609c60 r6:c10c0230 r5:0002 r4:c107efdc [5.540323] [] (driver_register) from [] (__platform_register_drivers+0) after reverting it i can boot without crash and start x-server my repo just for reference (revert not pushed yet): https://github.com/frank-w/BPI-R2-4.14/tree/5.0-hdmi i hope i had chosen the right way to report this... regards Frank ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
