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  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 <>
To:	Francois Romieu <>
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 <> :
> > 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.


To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists