netdev - Re: spidernet: dynamic phy setup code

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <1170634087.2620.69.camel@localhost.localdomain>
Date:	Mon, 05 Feb 2007 11:08:07 +1100
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Ishizaki Kou <kou.ishizaki@...hiba.co.jp>
Cc:	jens@...ibm.com, linuxppc-dev@...abs.org, jgarzik@...ox.com,
	jim@...ewis.com, netdev@...r.kernel.org
Subject: Re: spidernet: dynamic phy setup code

> We use bcm5461. There is a possibility that we don't know the appropriate
> setting which is applicable for both type of switches.

Have you tested the existing 54xx code in sungem_phy.c ? We use that
with 5462 at least in K2 and all sorts of 54xx chips and it works
fine... Just setup the right advertisement bits and call setup_aneg in
the PHY ops. You don't even need to implement the "forced" fallback code
that is in sungem. It's not necessary with most broadcom PHYs as they do
that themselves, just setup aneg and poll the link from a timer, that's
it. Once you get a link, then setup your GMACMODE based on the link
speed.

I don't have the datasheet of the 5461 at hand but I doubt it's any
different... Like other Broadcom 54xx PHYs, it might need some special
initialization code to work around firmware bugs though...

> We didn't investigate for the detail, but we met the following phenomena.
> 1. When auto-neg starts with Gbps setting and ethernet card is connected to
>    a 100Mbps switch, LINK is not detected.
> 2. When auto-neg starts with 100/10Mbps setting and ethernet card is 
>    connected to Gbps switch, LINK is detected (poll_link() succeeds), but
>    the network is not available.

That is very strange... I would need to review your code in more details
or eventually have HW access to run my own experiments, but none of this
should happen if things are setup properly. Also avoid relying on the
link interrupt, it's a known cause of trouble. Just poll.

Ben.

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html