netdev - RE: [PATCH net-next 5/6] dpaa

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <VI1PR04MB55676CC59282130611BA3675EC680@VI1PR04MB5567.eurprd04.prod.outlook.com>
Date:   Tue, 22 Oct 2019 06:47:14 +0000
From:   Madalin-cristian Bucur <madalin.bucur@....com>
To:     Jakub Kicinski <jakub.kicinski@...ronome.com>
CC:     "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Roy Pledge <roy.pledge@....com>,
        Laurentiu Tudor <laurentiu.tudor@....com>
Subject: RE: [PATCH net-next 5/6] dpaa_eth: change DMA device

> -----Original Message-----
> From: Jakub Kicinski <jakub.kicinski@...ronome.com>
> Sent: Tuesday, October 22, 2019 7:23 AM
> To: Madalin-cristian Bucur <madalin.bucur@....com>
> Cc: davem@...emloft.net; netdev@...r.kernel.org; Roy Pledge
> <roy.pledge@....com>; Laurentiu Tudor <laurentiu.tudor@....com>
> Subject: Re: [PATCH net-next 5/6] dpaa_eth: change DMA device
> 
> On Mon, 21 Oct 2019 12:28:02 +0000, Madalin-cristian Bucur wrote:
> > The DPAA Ethernet driver is using the FMan MAC as the device for DMA
> > mapping. This is not actually correct, as the real DMA device is the
> > FMan port (the FMan Rx port for reception and the FMan Tx port for
> > transmission). Changing the device used for DMA mapping to the Fman
> > Rx and Tx port devices.
> >
> > Signed-off-by: Madalin Bucur <madalin.bucur@....com>
> > Signed-off-by: Laurentiu Tudor <laurentiu.tudor@....com>
> 
> Curious, we also have a patch for fixing this for IXP400.
> Is there something in recent kernels that uncovers this bug?

Hi Jakub, it's related to the IOMMU on ARM64, this change is just one
of the many required to get IOMMU working on DPAA 1 platforms. The
device used for DMA mapping was the MAC but in the DPAA it's another
HW block that is actually doing the DMA transfers, the port (be it Rx
or Tx). This fix just makes the code correct, to actually enable IOMMU
there are some more changes and some are under discussion on other
threads [1]. I'm pushing these changes so I can make other modifications
to the DPAA driver while the IOMMU related open items are solved.

Regards,
Madalin

1. Laurentiu's IOMMU related changes:
https://lkml.org/lkml/2019/4/22/357
https://lore.kernel.org/patchwork/cover/997994/
https://lore.kernel.org/patchwork/project/lkml/list/?series=396215