netdev - RE: [PATCH v3 0/2] net: stmmac: Enhanced addressing mode for DWMAC 4.10

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 for Android: free password hash cracker in your pocket

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

Message-ID: <BN8PR12MB32669DDC64861CE11CA66474D3860@BN8PR12MB3266.namprd12.prod.outlook.com>
Date:   Thu, 26 Sep 2019 08:22:25 +0000
From:   Jose Abreu <Jose.Abreu@...opsys.com>
To:     Thierry Reding <thierry.reding@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>
CC:     Jose Abreu <Jose.Abreu@...opsys.com>,
        David Miller <davem@...emloft.net>,
        "peppe.cavallaro@...com" <peppe.cavallaro@...com>,
        "alexandre.torgue@...com" <alexandre.torgue@...com>,
        "jonathanh@...dia.com" <jonathanh@...dia.com>,
        "bbiswas@...dia.com" <bbiswas@...dia.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>
Subject: RE: [PATCH v3 0/2] net: stmmac: Enhanced addressing mode for DWMAC
 4.10

From: Thierry Reding <thierry.reding@...il.com>
Date: Sep/25/2019, 23:46:20 (UTC+00:00)

> On Wed, Sep 25, 2019 at 10:31:13AM -0700, Florian Fainelli wrote:
> > The way I would approach it (as done in bcmgenet.c) is that if the
> > platform both has CONFIG_PHYS_ADDR_T_64BIT=y and supports > 32-bits
> > addresses, then you write the upper 32-bits otherwise, you do not. Given
> > you indicate that the registers are safe to write regardless, then maybe
> > just the check on CONFIG_PHYS_ADDR_T_64BIT is enough for your case. The
> > rationale in my case is that register writes to on-chip descriptors are
> > fairly expensive (~200ns per operation) and get in the hot-path.
> > 
> > The CONFIG_PHYS_ADDR_T_64BIT check addresses both native 64-bit
> > platforms (e.g.: ARM64) and those that do support LPAE (ARM LPAE for
> > instance).
> 
> I think we actually want CONFIG_DMA_ADDR_T_64BIT here because we're
> dealing with addresses returned from the DMA API here.
> 
> I can add an additional condition for the upper 32-bit register writes,
> something like:
> 
> 	if (IS_ENABLED(CONFIG_DMA_ADDR_T_64BIT) && priv->dma_cfg->eame)
> 		...
> 
> The compiler should be able to eliminate that as dead code on platforms
> that don't support 64-bit DMA addresses, but the code should still be
> compiler regardless of the setting, thus increasing the compile
> coverage.

I'm fine with this. Some notes:
a) Do not try to enable dma_cfg->eame if CONFIG_DMA_ADDR_T_64BIT is not 
enabled;
b) You can even add a likely() around priv->dma_cfg->eame check because 
if a given SoC supports 64 bit addressing then its highly probable that 
the IP will also support EAME.

---
Thanks,
Jose Miguel Abreu