ocp emac phy wierdness

ocp emac phy wierdness

[David Gibson]

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/

Re: ocp emac phy wierdness

[Armin Kuster]

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. :)

Armin


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


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

Re: ocp emac phy wierdness

[David Gibson]

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/