[U-Boot] [PATCH 1/1] ppc4xx: Add support for GPCS, SGMII and M88E1112 PHY

[Ben Warren]

Hi Stefan,

On Sat, Aug 30, 2008 at 10:56 AM, Stefan Roese <sr at denx.de> wrote:
> Ben,
>
> On Saturday 30 August 2008, Ben Warren wrote:
>> > +#if !defined(CONFIG_PHY_LESS)
>> > +#define CONFIG_PHY_LESS        0xFFFFFFFF /* PHY-less mode */
>> > +#define CONFIG_PHY_LESS_SPEED  1000
>> > +#define CONFIG_PHY_LESS_DUPLEX FULL
>> > +#endif
>> > +
>>
>> Sorry, but this is not scalable.  There are many real-world examples
>> of boards where one controller is connected to a PHY, and another has
>> a FIXED link to a switch or something else.  This driver is already an
>> unwieldy mess and adding this sort of thing only makes it worse.  If
>> you want to add fixed-link capabilities, please re-direct your efforts
>> towards a more generic, scalable solution.
>
> Yes, this was my first fear too. But take a look at the commet Victor added in
> his 2nd patch version (I asked specifically for this comment to learn how
> this should work):
>
> +/*
> + * Some boards do not have a PHY for each ethernet port.
> + * For example on Arches board (2 CPU system) eth0 does not have
> + * a PHY, both CPU's are wired directly together (AC coupled)
> + * using SGMII0. In these cases set the appropriate
> + * CONFIG_PHY_ADDR equal to CONFIG_PHY_LESS to detect that
> + * the specified ethernet port does not have a PHY.
> + */
> +#if !defined(CONFIG_PHY_LESS)
> +#define CONFIG_PHY_LESS        0xFFFFFFFF /* PHY-less mode */
> +#define CONFIG_PHY_LESS_SPEED  1000
> +#define CONFIG_PHY_LESS_DUPLEX FULL
> +#endif
>
> So it's a per ethernet-interface selectable define of the CONFIG_PHY_ADDR and
> it kind of scales. It's not perfect but at least it's a way to support boards
> with interfaces connected to PHY's and other without PHY connection.
>
> What do you think? Is this acceptable? Or what other solution would be
> acceptable?
>
I guess this falls into the category of one of those things that's
probably OK for now but is ripe for being gutted at a later date.  The
right solution is to find a way to pass parametric information on a
per-controller basis, but we're a long way from that now.

If you're OK with the understanding that this is temporary, let's pull
it in.  I don't want to stand in the way of being able to support a
major eval board.

regards,
Ben