netdev - Re: [PATCH v5 1/1] Driver for Beckhoff CX5020 EtherCAT master module.

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:	Sun, 4 May 2014 21:46:24 +0200
From:	Darek Marcinkiewicz <reksio@...term.pl>
To:	Francois Romieu <romieu@...zoreil.com>
Cc:	davem@...emloft.net, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 1/1] Driver for Beckhoff CX5020 EtherCAT master module.

On Sun, May 04, 2014 at 08:43:51PM +0200, Francois Romieu wrote:
> Darek Marcinkiewicz <reksio@...term.pl> :
> > On Sat, May 03, 2014 at 01:40:29PM +0200, Francois Romieu wrote:
> [...]
> > Thank you. I am attaching 2 of thse to this repsonse - the other two 
> > are no longer relevant due to the changes I made into the driver.
> > One of the attached patches is slightly modfied by simply having one hunk
> > removed (that hunk was applying to the code that was removed in next rev 
> > of the driver). Not sure how to proceed with those patches, shall I simply
> > sent out these patches to this list as a separate messages?
> 
> You should submit a complete series if you want them separated - git
> format-patch does wonders here - or include these directly in your own
> patch as I don't really care for the credit.
> 
Ok. I've coalesced them into single patch. Thanks.

> [...]
> > I have changed the code to use much modest value - it is set to be of the
> > size of the fifo now. I think that this value is much better, but of course
> > having this configurable would be even better.
> 
> (see ethtool_ops.[gs]et_ringparam)
> 
After giving it a little though I came to the consclusion that in reality it won't
bring much value. So, if it is a showstopper, I would leave it at that.


> [...]
> > No, there is really no interrupt, hence the timer. Also on this device I wouldn't 
> > expect any bursts of data. What happens here, during regular operation of the 
> > device, is a periodic exchange of (few) ethernet packets between host cpu and
> > terminals attached to the EtherCAT bus. As for the locking on the tx path,
> > I have removed that completely on receiving path. I simply didn't know 
> > that it is such a big no-no here :)
> 
> Ok.
> 
> Regarding tx_dnext updates, you may add a short notice in ec_bhf_start_xmit
> and ec_bhf_process_tx explaining that the periodic poller will somehow end
> working with the right value, whence no (smp_)barrier at all.
> 
Hmm, good point. I am not really sure that it is not a race. So, I've added
memory barriers for the case when the tx ring becomes full.

About to send out new patch revison.

-- 
DM

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html