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] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 12 Apr 2011 09:34:14 -0700
From:	David Daney <ddaney@...iumnetworks.com>
To:	Alex Dubov <oakad@...oo.com>
CC:	Andrew Morton <akpm@...ux-foundation.org>, netdev@...r.kernel.org,
	bugzilla-daemon@...zilla.kernel.org,
	bugme-daemon@...zilla.kernel.org,
	Grant Likely <grant.likely@...retlab.ca>,
	Andy Fleming <afleming@...escale.com>
Subject: Re: [Bugme-new] [Bug 33042] New: Marvell 88E1145 phy configured incorrectly
 in fiber mode

On 04/11/2011 08:45 PM, Alex Dubov wrote:
>>
>> How does your u-boot configure the part?  Does it
>> write any of the
>> configuration registers, or is it just the default
>> configuration set via
>> the strapping pins?
>
> U-boot configures this phy just like any other phy - by running a set of
> register assignments from phy_info_M88E1145.
>
> Unfortunately, I don't have a datasheet for this phy

I would guess that the people who designed your board have it.

You do seem to have the uboot code though, so you know which registers 
are being set.  Given this, you can fiddle around with the Linux driver 
until it works.  Then send a patch.

To me it looks like you need to set register 22 (Page Select) to the 
value of 1 to access the register sets associated with fiber.  I don't 
have any hardware with this PHY connected to fiber, so I can't really 
test it.

David Daney

> and kernel does
> quite a few things differently, so simply copying stuff from u-boot
> does not work well (in kernel, phy initialization is broken into 3
> functions, if I'm not mistaken).
>
> Otherwise, my problem seems to be identical to the one reported some
> time ago against 88E1111 phy (which resulted in the addition of
> "marvell_read_status" in the first place). The problem was, as it seems
> to be now, that phy is always configured in "copper" mode, instead of
> driver checking for the correct "fiber" mode bits.
>
>
>>
>> In any event, you will probably have to read the
>> configuration before
>> the drivers/net/phy/marvel.c changes them.  Then
>> compare that to what
>> the driver is trying to set.  Then you will either
>> have to override the
>> configuration with the device tree "marvell,reg-init"
>> property, or if
>> you are not using the device tree, add a 88e1145 specific
>> flag that you
>> set when calling phy_connect().
>>
>> David Daney
>>

--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ