Re: ocp emac phy wierdness

[David Gibson <david@gibson.dropbear.id.au>]

On Thu, Aug 22, 2002 at 11:09:19AM -0700, Armin Kuster wrote:
>
> David,
>
> The whole phy idea back when I did it was modeled after the fec.c driver
> with the thought that at some point we could merge all phy_info structs
> into a common file.  The same idea was applied to the mii routines.  I
> noticed that code/information is duplicated in a few ethernet drivers in
> ppc.  Some of the what you see will be used when we add link support
> driver, some of the 4xx boards with zmii bridges have interrupt
> capability.  The phy implementation is a project that is not completed. :)

By all means share the phy_info structures between ethernet drivers.
That doesn't explain why:
	a) We queue the various phy operations, then process the
queue, rather than just stepping through the commands as soon as
requested.
	b) Why the queue is processed with schedule_task(), rather
than directly inline.

> David Gibson wrote:
>
> >There seems to be a whole lot of stuff related to phy handling with no
> >clear purpose to it.  The table phy_cmd_config appears to be unused,
> >as are the functions mii_queue_config, mii_display_config.
> >
> >Furthermore process_mii_queue() is dispatched through schedule_task(),
> >from mii_queue_schedule().  But the only place that is called is in
> >ppc405_enet_open(), which immediately calls schedule() to wait for the
> >job to be completed.  So what the hell is the point of the
> >schedule_task() rigmarole?

--
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.
http://www.ozlabs.org/people/dgibson

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/