Hi,
Attached please find the diff output of the fcc_enet.c that I am running with
and the original 2.6.10 version of it.
There are 3 category of differences:
1. The fix for Bug 4310 that I reported: these are the last 6 lines of the
diffout file.
2. The fcc_enet.c, as distributed in 2.6.10, does not compile. Evidently the
2.6 kernel no longer supports the schedule_task() and "struct tq_struct" to go
with it. Lines 73 through and including 96 of the diffout file show the changes
I made to port schedule_task() into tasklet_schedule(). I should have reported
this as a bug too but I forgot about it.
3. The rest of the lines in the diffout file are for the purpose of customizing
fcc_enet.c to work with my custom board. These changes are conditional on
CONFIG_EON8260 being defined.
Oray Balasaygun
-----Original Message-----
From: Andrew Morton [mailto:akpm@xxxxxxxx]
Sent: Tuesday, March 08, 2005 2:49 PM
To: oray@xxxxxxxxxx
Cc: linuxppc-dev@xxxxxxxxxx; netdev@xxxxxxxxxxx
Subject: Re: [Bugme-new] [Bug 4310] New: ppc 8260 fcc ethernet driver
cannot read LXT971 PHY id
I'm not sure that we have a maintainer for fcc_enet.c. Could you
please send in a tested diff?
bugme-daemon@xxxxxxxx wrote:
>
> http://bugme.osdl.org/show_bug.cgi?id=4310
>
> Summary: ppc 8260 fcc ethernet driver cannot read LXT971 PHY id
> Kernel Version: 2.6.10
> Status: NEW
> Severity: normal
> Owner: platform_ppc-32@xxxxxxxxxxxxxxxxxxxx
> Submitter: oray@xxxxxxxxxx
>
>
> Distribution: www.kernel.org
> Hardware Environment: Target: PowerPC 8260 custom board
> Software Environment: Red Hat 9 cross development using ELDK 3.1 distribution.
> Problem Description: Fast ethernet driver (fcc_enet.c) initialization fails to
> read a valid id from registers 2 and 3 of the LXT971 PHY device and calls the
> panic routine. The bug is in the mii_send_receive() function. During the read
> phase, per LXT971 data sheet, the device starts driving the MDIO line after
> the
> rising edge of the MDC clock and it could take up to 150ns before the data
> settles. The driver reads the MDIO line before waiting for the data to settle
> down and thus reads in garbage. I fixed the problem by moving the sampling of
> the MDIO line to after the MDC clock is taken low. The code snippet follows:
>
>
>
> for (i = 0, off = 15; i < 16; i++, off--)
> {
> #define FCC_8260_BUG
> FCC_PDATC_MDC(1);
> retval <<= 1;
> #ifndef FCC_8260_BUG
> if (io->iop_pdatc & fip->fc_mdio)
> retval++;
> udelay(1);
> FCC_PDATC_MDC(0);
> #else
> udelay(1);
> FCC_PDATC_MDC(0);
> if (io->iop_pdatc & fip->fc_mdio)
> retval++;
> #endif
> udelay(1);
> #undef FCC_8260_BUG
> }
>
>
> Steps to reproduce: Is likely to happen on an 8260 target with any kind of
> PHY,
> not just the LXT971, hooked up to the FCC port.
>
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug, or are watching someone who is.
diffout
Description: Binary data
|