add phy-handle property for fec_mpc52xx

[Matt Sealey]

Sven Luther wrote:
> 
> Let's just fix this in the kernel, until we get a fixed efika firmware,
> then we can drop it easily enough. But until this happens, we need to be
> able to boot the kernel without any extra work on the users part.

That is exactly why I don't like the idea. Yes, it makes it easier for users
and easier for distro managers to say "it supports the Efika" but it makes
the Forth fixing, and any further firmware development (ignore the lack of
releases, it means nothing) much harder.

It should not be a function of Linux to fix firmware problems. This was
the FIRM line by Ben, Segher and the rest of the LinuxPPC guys when we
released the Efika - fix the firmware, not Linux, don't hack drivers, don't
rely on fixups. I disagreed at the time due to the urgency to release the
board, but now, we have the luxury of not having to rush it through to get
a product on sale.

I would much rather the Linux kernel did not implement fixups for firmware
which we can fix. The phy-handle part that Olaf specifies in his patch
can be added by a user to nvramrc, BY HAND, in around 10 lines of Forth
code. Those 6 lines are in the efika.forth script, and in fact Olaf is
simply running "interpret" over an encoded version of this! (I say 10 lines
because the efika.forth script is needlessly verbose for the purpose of
being readable by humans).

It is not scary or difficult to do this if you need ethernet to work, and
not beyond the scope of the installation documentation or an Efika wiki
page. The Forth stuff will work fine for *all* operating systems.

If you don't like not having your Linux distro or a default kernel working
on our default firmware, PLEASE FEEL FREE TO BLAME US. PROFUSELY.

Alternatively I'd love to work with people to create a comprehensive
pre-update binary fix (not a boot loader but an installer) for the Forth
script so that users can run it before they boot any distro disk, and then
the kernel on the CD, the kernel in the distro repositories, will not have
the burden of tracking firmware releases, and the Linux team will not have
the burden of maintaining tiny fixes for things which may always be fixed.

After all, there is no profit or benefit in fixing something 5 times just
in case the user only has 4 of them installed.

-- 
Matt Sealey <matt at genesi-usa.com>
Genesi, Manager, Developer Relations