Inspiron 1525 Hardware
pyunyh at gmail.com
Mon Sep 8 04:26:17 UTC 2008
On Sat, Sep 06, 2008 at 06:06:55PM -0700, Jeremy Chadwick wrote:
> On Sat, Sep 06, 2008 at 05:50:36PM -0700, Jeremy Chadwick wrote:
> > It appears Linux got support for the 88E8040 in September 2007 (revision
> > 1.2.73). Support for the 88E8040T was added in June 2008 (revision
> > 1.330.1.3).
> > The 1.2.73 commit also added support for the 88E8048 and the 88E8070.
> > This might be of great help in tracking down just what register tweaks
> > they added to get support working:
> > http://linux.bkbits.net:8080/linux-2.6/drivers/net/sky2.c?PAGE=diffs&REV=46f2c896NoiOKP_Nx0TcSvNe1G-elw
> The Linux folks refer to these chips as "FE+". The below URL shows
> quite a lot of commits for FE+ stuff, as well as documentation of actual
> hardware bugs on some revisions of those chips.
> CSet revisions worth looking at (clicking the revision string will take
> you to a page allowing annotation and diffs, which is helpful):
Are you proposing to be a msk(4) maintainer? :-)
> CSet 1.6247.61.6 -- initial support for FE+ chips
> CSet 1.6247.61.21 -- fix for PHY initialisation in FE+ chips
> CSet 1.6247.96.1 -- fix for recv status hardware bug in FE+ chips
> CSet 1.6247.96.2 -- disable VLAN acceleration for FE+ chips (status reg. unreliable)
> CSet 1.7736 -- disable dynamic Tx watermark support on FE+ chips
Thanks for the valuable information. Due to the complexity of
Yukon II hardware and its bugs for each revision msk(4) still
requires lots of workaround code. The patch you've mentioned in
CSet 1.6247.61.21 might help for FE+ but the reason why it needed
that patch is not clear. Marvell released 88E8016 datasheet which
seem to be used on FE+. The datasheet just mentions that the
purpose of the bit of PHY specific control register II choose a
behavour(Class A or Class B). I have no idea why FE+ requires class
A configuration due to lack of errata information. Also datasheet
says that it is only for 100baseTX. I wonder what happens on
10baseT media. Anyway, this kind of testing requires hardware
access I guess.
Unlike Linux, e1000phy(4) is shared for all other drivers so it's
somewhat difficult to program as Linux did. As you might know the
PHY fix is only for FE+ A0 and it's hard to pass that information
to PHY driver without hack. Let's see what can be done...
> A lot of these commits are for hardware revision A0 of certain FE+
> chips; looks like rev. A0 has a lot of bugs. Yong-Hyeon might be
Yes, I have no idea how revision A0 could be released to customer.
This chip revision looks like worst one I ever seen on consumer
> interested in the PHY initialisation fix, since I can imagine that could
> affect link negotiation.
> The first CSet in the above list has the following comment. Note the
> part about "hardware evaluation boards":
> "Add support for newest Marvell chips. The Yukon FE plus chip is found
> in some not yet released laptops. Tested on hardware evaluation
> It appears to me even the Linux guys couldn't get hardware for these
> chips, without talking to Marvell directly.
More information about the freebsd-stable