Hi,
I have a system that has a card run by the DMFE driver (davicom
chip).
The driver has an ugly hack to check that the chip does "CRC checking"
correctly: Some versions of the chip have a hardware bug there.
However, as far as I can see, the logic behind the "check the chip"
variable is not correct. I'm not sure if that's related to the
failures I'm seeing....
I think that the dm910x_chk_mode variable was intended to
go through a bunch of "stages":
a) Checking is done, to determine if the chip is broken.
b) Determined that chip is broken, need to continue to check.
c) determined that chip is NOT broken, no longer need to check.
d) no check needed: chip version is always OK.
however, the numerical values are a bit botched, so that I think
that the driver will always move on to stage "c", no matter the result
of the "test" stage....
c and d are coded as dm910x_chk_mode == 4.
a is coded as "1".
stage b is coded as "3", but then:
1097:
/* Operating Mode Check */
if ( (db->dm910x_chk_mode & 0x1) &&
(db->stats.rx_packets > MAX_CHECK_PACKET) )
db->dm910x_chk_mode = 0x4;
will move it up to "4" regardless of wether it was 1 (just checking)
or 3 (determined that chip is buggy and that we need to keep doing
the software check).
Is there someone who is willing to dive into the code for half an
hour to see if (s)he agrees with me?
Roger.
--
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* The Worlds Ecosystem is a stable system. Stable systems may experience *
* excursions from the stable situation. We are currently in such an *
* excursion: The stable situation does not include humans. ***************
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
