netdev - RE: Questions about the sh_eth driver and hardware

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]

Date:	Thu, 19 Feb 2015 04:41:06 +0000
From:	yoshihiro shimoda <yoshihiro.shimoda.uh@...esas.com>
To:	Ben Hutchings <ben.hutchings@...ethink.co.uk>,
	Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@...esas.com>,
	MITSUHIRO KIMURA <mitsuhiro.kimura.kc@...esas.com>,
	"HISASHI NAKAMURA(Retired)" <a5077047@...esasgroup.onmicrosoft.com>,
	Yoshihiro Kaneko <ykaneko0929@...il.com>
CC:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	ct-linux-kernel <linux-kernel@...ethink.co.uk>
Subject: RE: Questions about the sh_eth driver and hardware

Hi Ben,

This is Shimoda of Renesas. I'm a software engineer.
I asked hardware team about your questions. So, I wrote some comments below.

> 1. When freeing packet buffers, we currently try to stop the DMA engines
> by clearing EDRRR and EDTRR but we *don't* wait after that.  This seems
> unsafe because in general register writes are not serialised with DMA.
> 
> The R8A7790 (R-Car H2) manual specifically says that the R bit of EDTRR
> (aka CXR2) cannot be cleared by writing to it.  I think that we could
> stop TX DMA by clearing the active flags of all the descriptors and then
> polling the R bit until it clears.  What do you think?
> 
> As for RX DMA, I think we should wait some time after clearing the R bit
> that we can be sure is long enough to transfer one packet.  Do you know
> how long that could be?

They said that a software should wait for "set amount of time" or RX interruption.
So, I think that your patch (commit id = 740c7f31c in net-next.git) is enough.

> 2. In case of a Receive Descriptor Empty error (RDE), we currently read
> the RDFAR register to find the next descriptor the DMA engine will use.
> But this register is not documented for the R8A7790 and the driver does
> not define an offset for it on R-Car chips.  The manual doesn't say how
> to set the address of the next descriptor to use.  Maybe we should
> assume that R-Car chips will never skip descriptors after RDE?

They said that software should find the next descriptor without RDFAR register somehow
after RDE. However, I checked this driver handling on the R-Car M2, and the following
code didn't run actually. So, we should assume the R-Car chips will never skip descriptors
after RDE.

< sh_eth.c: sh_eth_rx() >
	if (!(sh_eth_read(ndev, EDRRR) & EDRRR_R)) {
		/* fix the values for the next receiving if RDE is set */
		if (intr_status & EESR_RDE) {
/*vvvvvvv The code below didn't run on R-Car Gen2 vvvvvvv*/
			u32 count = (sh_eth_read(ndev, RDFAR) -
				     sh_eth_read(ndev, RDLAR)) >> 4;

			mdp->cur_rx = count;
			mdp->dirty_rx = count;
/*^^^^^^^ The code above didn't run on R-Car Gen2 ^^^^^^^*/
		}
		sh_eth_write(ndev, EDRRR_R, EDRRR);
	}

< Test method >
 Host PC $ sudo ping -f -l 128 <the board's ip address>

Best regards,
Yoshihiro Shimoda