netdev - Re: [PATCH] natsemi: make cable length magic configurable

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]

Message-ID: <1322162739.2784.26.camel@bwh-desktop>
Date:	Thu, 24 Nov 2011 19:25:39 +0000
From:	Ben Hutchings <bhutchings@...arflare.com>
To:	Jean Delvare <jdelvare@...e.de>
CC:	<netdev@...r.kernel.org>, Tim Hockin <thockin@...kin.org>,
	Olaf Kirch <okir@...e.de>
Subject: Re: [PATCH] natsemi: make cable length magic configurable

On Thu, 2011-11-24 at 14:43 +0100, Jean Delvare wrote:
> From: Olaf Kirch <okir@...e.de>
> 
> We had a customer report concerning problems with a Natsemi DP83815-D
> and long cables. With 100m cables, the network would be essentially dead,
> not a single packet would get through either way. We had to apply the
> patch below to make it work.
> 
> The patch adds a module parameter named "no_cable_magic" that does
> two things:
> 
>  -	Unconditionally set the DSPCFG register to the
> 	fixed value. Without this change, the chip apparently
> 	never completes autonegotiation in the tested configuration.
> 
> 	This has been an unconditional assignment for a long time,
> 	until this was changed in 2.6.11 (there's an interesting
> 	explanation in the ChangeLog, subject is
> 	"[PATCH] natsemi long cable fix", bk commit is
> 	5871b81bf2b5cf188deab0d414dce104fcb69ca6, git commit in
> 	tglx/history tree is c0d51c67f9c398279a95c5a7df387f2d9a586c98.
> 
>  -	Skip the bit banging in {,un}do_cable_magic. It seems that
> 	if we write the DSPCFG register as above, a rev D chip will report
> 	all cables as "short cables", which do_cable_magic detects, and
> 	trying to be helpful it will "fix" the attenuation coefficient.
> 
> I admit the use of a module parameter is ugly, but I didn't find a sane
> way to fix this - especially since the magic registers we're changing
> are undocumented.
[...]

This could be implemented as an ethtool 'private flag'.  However, the
ethtool utility currently does not provide an interface to them.
Perhaps you could implement both the private flag and the module
parameter for now, and then drop the module parameter some time after
the utility has been updated.

You would need to:
1. Number the flags starting from 0.  Well, that was easy.
2. Implement {get,set}_priv_flags() operations to access all flags as
   a bitmask.
3. Expose the flag names as string set ETH_SS_PRIV_FLAGS accessed by
   get_sset_count() and get_strings() operations.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

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