Porting a driver to powerpc using FDT

[Grant Likely]

On Tue, Jun 15, 2010 at 4:19 PM, Chris Alfred <c.alfred at internode.on.net> wrote:
> I am trying to port a DSA (Distributed Switch Architecture) driver for
> the Micrel KS8995M managed switch connected to a MPC5200. There is an
> SPI interface and MII interface managed by the DSA driver.
>
> I can't understand how probe gets called when the flatted device tree
> (FDT) system is used, and how to bind such a driver using the FDT (if
> you have to at all).
>
> The DSA driver is initialised via:
>
>    // net/dsa/dsa.c
>
>    static struct platform_driver dsa_driver = {
>     .probe  = dsa_probe,
>     .remove  = dsa_remove,
>     .shutdown = dsa_shutdown,
>     .driver = {
>      .name = "dsa",
>      .owner = THIS_MODULE,
>     },
>    };
>
>    static int __init dsa_init_module(void)
>    {
>     return platform_driver_register(&dsa_driver);
>    }
>
> dsa_init_module is being called; but how do I get the system to call
> .probe?

You need a platform device registered for the driver to bind against.
On a lot of systems, the machine setup code just registers a
statically allocated platform_device.  You can still do this on
powerpc if you create a new machine specific board file in
arch/powerpc/platforms/ (discouraged, but only mildly so for things
that are very board specific).

The "preferred" approach on device tree systems is to add device tree
hooks to the driver you want to use.  However, I'm not going to ask
you to do that since the current approach for doing so is in the
process of being removed (The current approach is to add a new
of_platform_driver registration for the device driver; but I've got
changes in my tree that will make regular old platform_drivers able to
bind against devices described in the device tree).

To avoid writing new machine-specific code in arch/powerpc/platforms,
then I recommend that you add a node to your .dts file to describe the
DSA complex and write a very simple of_platform_driver that binds
against it.  Then use the probe hook to extract data out of the device
tree node (if needed) and register the appropriate platform_device
(don't forget to make the of_device the parent of the
platform_device).  This can be considered a temporary solution, but it
will not break when I make the infrastructure changes, and then you
can migrate over to the new method at your leisure.

Cheers,
g.