PHY not found after migration of gianfar driver to an of_platform_driver

[Grant Likely]

I'm posting this back on the mailing list.  You're not being dense and
there are good questions here which others might elaborate more on.

On Tue, Mar 3, 2009 at 2:56 PM, Michael Guntsche <mike at it-loops.com> wrote:
> The routeboard is already providing a device-tree albeit not a very good
> one, otherwise the board would not boot in the first please if I just use a
> plain kernel

I need more information here.  What do you mean when you say "plain
kernel".  What file from the build process do you use, and how do you
boot it?

> without an embedded tree. I need to fix this device tree since the new
> gianfar network code is expecting
>
> tbi-handle = <&tbi1>;
>
> Entries in the ethernet nodes to find the PHY devices. I do not know if you
> looked at the source of rbppc.c in detail. There is already code in there to
> init the PCI bus
> since the tree is missing data for this.

I don't see a file named rbppc.c in the current kernel tree.

> * Why can't I just add those missing values in the setup-arch section of the
> code?

You might be able to use of_attach_node() & prom_add_property() to
modify the tree, but I've never done it myself.  Give it a try and
tell me if it works.  :-)

>  They are needed to init the NICs correctly so I can fix this here before
> the driver is loaded

Another option is to add a workaround to the driver.  This isn't
ideal, but driver authors aren't supposed to break device tree
bindings either.  Drivers are supposed to remain backwards compatible
with older device trees (either by patching the device tree or with
explicit workarounds).  Downside is that this type of change may be
harder to get merged.  And it's just plain not very pretty.

> * How could I add those information?
>  Can't I just do something similar to platforms/iseries/vio.c
>  (add_string_property and do_device_node)?

Maybe.  I don't know why those functions are tucked away in vio.c
instead of being common code.  If you go that approach, refactor the
functions you use to be shared.

> This wold have the benefit of getting the rest of the data from the board
> and just patch it with the needed values.

This is definitely preferred to wholesale replacement of the available tree.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.