From: Ben Hutchings <bhutchings@solarflare.com>
To: Jean Delvare <jdelvare@suse.de>
Cc: <netdev@vger.kernel.org>, Tim Hockin <thockin@hockin.org>,
Olaf Kirch <okir@suse.de>
Subject: Re: [PATCH] natsemi: make cable length magic configurable
Date: Thu, 24 Nov 2011 19:25:39 +0000 [thread overview]
Message-ID: <1322162739.2784.26.camel@bwh-desktop> (raw)
In-Reply-To: <201111241443.59191.jdelvare@suse.de>
On Thu, 2011-11-24 at 14:43 +0100, Jean Delvare wrote:
> From: Olaf Kirch <okir@suse.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.
next prev parent reply other threads:[~2011-11-24 19:25 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-24 13:43 [PATCH] natsemi: make cable length magic configurable Jean Delvare
2011-11-24 19:25 ` Ben Hutchings [this message]
2012-07-16 12:26 ` Jean Delvare
2012-07-16 13:08 ` Ben Hutchings
2012-07-16 13:57 ` Mark Brown
2012-07-17 5:22 ` David Miller
2011-11-25 6:37 ` David Miller
2011-11-28 17:51 ` Ben Hutchings
2011-11-28 21:45 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1322162739.2784.26.camel@bwh-desktop \
--to=bhutchings@solarflare.com \
--cc=jdelvare@suse.de \
--cc=netdev@vger.kernel.org \
--cc=okir@suse.de \
--cc=thockin@hockin.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox