from the archives + questions about fec.c: Re: [uClinux-dev] coldfire fec.c ethernet driver

Stuart MacDonald stuartm at connecttech.com
Fri Mar 7 15:21:19 EST 2003


From: "Richard Klingler" <richard.klingler at violasystems.com>
Sent: October 4, 2002 1:07 a
> > Richard Klingler wrote:
> > > The coldfire ethernet driver registers the PHY interrupt before
> > > it detects a valid PHY (o;
> > >
> > > So IRQ66 (INT2) is always bound to fec.c even the PHY is of type
> > "unknown".
> > >
> > > What you think Greg? Is it safe to just enable the IRQ66
> > > inside "mii_discover_phy3" ?
> >
> > I think that is good. (In fact it is definately better to not
> > enable the IRQ until then :-)
>
> Here is the patch against the latest CVS source (o;
> It moves the IRQ registering (M5272) into "mii_discover_phy3".
> I don't know about the other supported CPU's (o;

The M5272 user manual states that it's best to use the mii interrupt
to ensure that the mii interface doesn't munge itself. Since the phy
detection uses the interface, shouldn't the interrupt be enabled
first? OTOH, even with it enabled I don't see any interrupts happening
as a result of the phy detection, so I guess it's not necessary.

I'm having problems getting the phy detection code to recognise our
LXT972A. I've moved the interrupt and icrp references (we've got the
mii interrupt on INT3 instead of INT2). I've checked that the mii
commands are built properly. What seems to happen is that garbage is
read from the phy. If anyone has any insight, I'd appreciate it.

Using 20020927, and tools 20020410. Searched the list archive, found
nothing relevant, except the thread I'm replying to.

One question: apparently our phy is phy # 0xb. Neither the phy data
sheet or the CPU data sheet states how a phy's "address" is
determined. Is that a funtion of the hardwiring?

..Stu





More information about the uClinux-dev mailing list