netdev - RE: [PATCH net-next v2 2/2] net: stmmac: Support 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <BN8PR12MB3266FC9B7C984F875A920D3ED3B10@BN8PR12MB3266.namprd12.prod.outlook.com>
Date:   Wed, 11 Sep 2019 09:15:10 +0000
From:   Jose Abreu <Jose.Abreu@...opsys.com>
To:     Florian Fainelli <f.fainelli@...il.com>,
        Jose Abreu <Jose.Abreu@...opsys.com>,
        Thierry Reding <thierry.reding@...il.com>
CC:     "David S . Miller" <davem@...emloft.net>,
        Giuseppe Cavallaro <peppe.cavallaro@...com>,
        Alexandre Torgue <alexandre.torgue@...com>,
        "Jon Hunter" <jonathanh@...dia.com>,
        Bitan Biswas <bbiswas@...dia.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>
Subject: RE: [PATCH net-next v2 2/2] net: stmmac: Support enhanced addressing
 mode for DWMAC 4.10

From: Florian Fainelli <f.fainelli@...il.com>
Date: Sep/10/2019, 20:01:01 (UTC+00:00)

> On 9/10/19 1:35 AM, Jose Abreu wrote:
> > From: Thierry Reding <thierry.reding@...il.com>
> > Date: Sep/09/2019, 20:13:29 (UTC+00:00)
> > 
> >> On Mon, Sep 09, 2019 at 04:05:52PM +0000, Jose Abreu wrote:
> >>> From: Thierry Reding <thierry.reding@...il.com>
> >>> Date: Sep/09/2019, 16:25:46 (UTC+00:00)
> >>>
> >>>> @@ -79,6 +79,10 @@ static void dwmac4_dma_init_rx_chan(void __iomem *ioaddr,
> >>>>  	value = value | (rxpbl << DMA_BUS_MODE_RPBL_SHIFT);
> >>>>  	writel(value, ioaddr + DMA_CHAN_RX_CONTROL(chan));
> >>>>  
> >>>> +	if (dma_cfg->eame)
> >>>
> >>> There is no need for this check. If EAME is not enabled then upper 32 
> >>> bits will be zero.
> >>
> >> The idea here was to potentially guard against this register not being
> >> available on some revisions. Having the check here would avoid access to
> >> the register if the device doesn't support enhanced addressing.
> > 
> > I see your point but I don't think there will be any problems unless you 
> > have some strange system that doesn't handle the write accesses to 
> > unimplemented features properly ...
> 
> Is not it then just safer to not do the write to a register that you do
> not know how the implementation is going to respond to with one of a
> target abort, timeout, decoding error, just dead lock?

I don't think any of these will ever happen. Notice that this is already 
been done for a long time in some registers that may not exist in some 
random HW config and there is also the point that this is a write 
operation so Slave Error would only get triggered if we did a read.

> Also, would it make sense to consider adding an #ifdef
> CONFIG_PHYS_ADDR_T_64BIT plus the conditional check so that you can be
> slightly more optimal in the hot-path here?

Well, this is not hot-path. It's only done in HW open sequence. The 
hot-path would be set_{rx/tx}_tail_ptr() but that's 32 bits only. 

---
Thanks,
Jose Miguel Abreu