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