From: Dean Matsen <hidden> Date: 2003-07-09 02:17:12
To whomever maintains the file arch/ppc/8xx_io/fec.c:
I note the following code in mii_discover_phy() :
fep = dev->priv;
if ((phytype = (mii_reg & 0xffff)) != 0xffff) {
/* Got first part of ID, now get remainder.
*/
In our devices, reading the first word with the wrong address yields the
value 0, not 0xFFFF. This happens even if we play with it by hand. The
search goes through address 0, 1, 2, .., and our chip is hard-coded at
address 1. What happens is the kernel panics with something like
"Don't know what chip ID 0000FFFF is". Anyway, I changed it to the
following, and it finds our PHY correctly now.
fep = dev->priv;
phytype = (mii_reg & 0xffff);
if (phytype != 0xffff && phytype != 0x0000) {
/* Got first part of ID, now get remainder.
*/
I am guessing that probably most devices have the PHY chip at address
zero, so nobody else has run into this problem because it finds their
chip in the first iteration.
You may also want to note in the file that it supports 972 chips (which
apparently look like 971 chips from the inside, 'cuz that's what the
kernel says it is). Perhaps the printk() should be updated to say
"971/972" instead of just "971"?
Thanks
Dean Matsen
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Dan Malek <hidden> Date: 2003-07-09 05:21:53
Eugene Surovegin wrote:
It usually means that your hw lacks pull-up on MII MDIO line.
Yep, and even when PHYs indicate they have internal pull-ups, either
they don't or they aren't sufficient.
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Dean Matsen <hidden> Date: 2003-07-09 05:50:49
Dan Malek wrote:
Eugene Surovegin wrote:
quoted
It usually means that your hw lacks pull-up on MII MDIO line.
Yep, and even when PHYs indicate they have internal pull-ups, either
they don't or they aren't sufficient.
-- Dan
Yes, I see we have no pullup on that line. We do dedicated HVAC
applications, so we
don't need to do this search. Our dedicated software wouldn't talk to
the chip
at the wrong address.
Don't you think the fix from my original message should still be
considered for
integration into the kernel? It will improve the odds that the kernel can
auto-detect someone's hardware....
Thanks
Dean
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Dan Malek <hidden> Date: 2003-07-09 14:37:12
Dean Matsen wrote:
Yes, I see we have no pullup on that line. We do dedicated HVAC
applications, so we
don't need to do this search.
But.......the hardware is broken. The MDIO is supposed to be
an open-drain with a pullup. I guess you may be lucky the
ends of the connection are driving the line proplerly, but it
could be luck that will run out someday.
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Dean Matsen <hidden> Date: 2003-07-09 16:39:40
Dan Malek wrote:
Dean Matsen wrote:
quoted
Yes, I see we have no pullup on that line. We do dedicated HVAC
applications, so we
don't need to do this search.
But.......the hardware is broken. The MDIO is supposed to be
an open-drain with a pullup. I guess you may be lucky the
ends of the connection are driving the line proplerly, but it
could be luck that will run out someday.
-- Dan
Well, I don't disagree there. We're going to investigate updating the
schematics for future products. Thanks for the input.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Dean Matsen <hidden> Date: 2003-07-09 20:54:42
Dan Malek wrote:
Dean Matsen wrote:
quoted
Yes, I see we have no pullup on that line. We do dedicated HVAC
applications, so we
don't need to do this search.
But.......the hardware is broken. The MDIO is supposed to be
an open-drain with a pullup. I guess you may be lucky the
ends of the connection are driving the line proplerly, but it
could be luck that will run out someday.
-- Dan
Actually, it turns out that this is not quite true. The MDIO line
is classified as an I/O line (on the same page where other lines
are classified as open drain). There are tons of application notes from
Motorola and Intel and none of them show a pullup. I think
this issue has more to do with talking to a device at the wrong address
and having the line float only in that case.
The actual problem I have is that the kernel panics before it even gets
to address 1 (which is where my PHY chip is in the first place). This
happens whenever it reads a value other than FFFF from the first word
of the ID. I see now that my first patch adds detection for the value
0000, but other people may have varying results (especially if they
follow the app notes and don't have a pullup, like we do).
I think the search should be made smarter (especially, keep going to
the next address until it has gone through ALL address w/o finding a
valid ID). The kernel could still panic if it can't find any PHY chip,
but not the first time it reads the floating line and can't find the
answer in its table. The odds of reading a valid PHY ID from the
floating line is phenominally low. I'd submit a proposed patch for
this, but it doesn't sound like anyone else thinks this is important
enough to warrant a change.
Those maintaining the official kernel repositories should consider whether
or not it's friendly to require the addition of a pullup resistor just so
the automatic PHY search will work. Unless the pullup is required for
non-search applications (which I assert it isn't), then I think the code
should be fixed, not the hardware.
Regards,
Dean
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/