netdev - RE: bonding with 3c59x driver

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <AE90C24D6B3A694183C094C60CF0A2F6026B6E6F@saturn3.aculab.com>
Date:	Tue, 14 Feb 2012 10:44:40 -0000
From:	"David Laight" <David.Laight@...LAB.COM>
To:	"Jean Delvare" <jdelvare@...e.de>,
	"Jay Vosburgh" <fubar@...ibm.com>
Cc:	"Steffen Klassert" <klassert@...hematik.tu-chemnitz.de>,
	<netdev@...r.kernel.org>
Subject: RE: bonding with 3c59x driver

> Well I am still curious why the 3c59x driver has such slow 
> polling when 
> other drivers I have been testing are able to report almost instantly 
> when I remove a network cable. Could it be that other network chips 
> generate an interrupt on cable removal and the 3com chips do not?

Not sure about those specific cards, but detecting the
link state might require software bit-banging of an MII
(or similar) interface.

Since this needs delays between all the edges it can
end up spinning the cpu for a noticable time, especially
if the resolution (and minimim delay) of the delay()
function used is significantly longer than the delays
actually required - which might only be a few 100ns.

Using a cpu spin for the delays is also slightly
problematical because the writes might get 'posted'
and delayed further - so the writes have to be forced
out to the device itself (eg by a readback) prior to
the delay() being requested.

If the driver is polling the link status it might
be valid to do one bit-bang transition on each timer
interrupt. This would separate the edges without
spinning the cpu - provided there is a fast method
for being called on every timer tick.

Another scheme I have used is to write each value
to the bit-bang register multiple times - using
the maximum speed of the IO writes to generate the
required delays.

	David

--
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