netdev - Re: Porting the ibm_newemac driver to use phylib (and other PHY/MAC questions)

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:	Thu, 30 Apr 2009 11:33:31 -0400
From:	Kyle Moffett <kyle@...fetthome.net>
To:	Grant Likely <grant.likely@...retlab.ca>
Cc:	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Josh Boyer <jwboyer@...ux.vnet.ibm.com>,
	netdev <netdev@...r.kernel.org>,
	"Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>,
	linuxppc-dev@...abs.org
Subject: Re: Porting the ibm_newemac driver to use phylib (and other PHY/MAC 
	questions)

On Thu, Apr 30, 2009 at 11:11 AM, Grant Likely
<grant.likely@...retlab.ca> wrote:
> Just a heads up Kyle; there are changes queued in the netdev tree
> which add OF helpers for MDIO bus drivers and MAC drivers.  See here:
>
> http://git.kernel.org/?p=linux/kernel/git/davem/net-next-2.6.git;a=commit;h=8bc487d150b939e69830c39322df4ee486efe381
>
> and here is an example of a driver change:
>
> http://git.kernel.org/?p=linux/kernel/git/davem/net-next-2.6.git;a=commit;h=1dd2d06c0459a2f1bffc56765e3cc57427818867

Hmm, very interesting!  Thanks!  Although I'm not sure that those OF
helpers are entirely usable for the emac driver at the moment, as the
device trees for the existing boards simply don't have PHYs present in
them.  Most of the ibm_newemac board device-trees just have one of:
"phy-address = <4>", "phy-mask = <0xffff0000>", or nothing at all (for
autodetection).  I will probably need to leave in support for the old
PHY mask parsing to preserve backwards compatibility.

My main concern at the moment is cleaning up the driver's general PHY
handling.  I got started on this whole mess when I was trying to write
some hackish PHY drivers for a weird custom board I've got here.  I
couldn't figure out why the hell all my PHY register changes in the
phy_ops->init function kept getting cleared, until I noticed 2 things:
 The emac_reset_phy() function gets called occasionally and does not
call the ->init() function again afterwards.  The
genmii_setup_forced() function (in the EMAC driver) unconditionally
ORs the BCMR_RESET flag into the MII_BCMR register.  Both of those
meant that any early setup I did for my PHY was getting completely
cleared on a regular basis, with no decent way for me to patch it back
up again.

Cheers,
Kyle Moffett
--
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