Re: [PATCH/RFC] simple SPI controller on PXA2xx SSP port, refresh

[David Brownell <david-b@pacbell.net>]

On Friday 04 November 2005 6:28 pm, Stephen Street wrote:
> My understanding also.  Let's at least do the renames.

Consider it done.

I'll leave "controller_data" in board_info and spi_device too.
You're right ... plus, we need to let that be separate from the
controller platform_data for hotplugging usage, spi_new_device()
and such.


> Occupying some spare cycles is the idea that what we really need is the
> ability to sub-class spi_device and spi_master via structure embedding.
> This would be in the spirit of the 2.6 driver model and would map to the
> platform_device model better.  

Not really.  "Struture embedding" is used more by bus infrastruture than
by driver infrastructure ... and even there, it's more often done by
sharing storage.  And spi_master supports that usage:

	/* at the top of probe(dev) */
        struct spi_master       *master;
        struct MYSOC_DATA       *data;

        master = spi_alloc_master(dev, sizeof *data);
        if (!master)
                return -ENODEV;

        data = class_get_devdata(&master->cdev);

That's because spi_master is a class view of the underlying "dev",
used to access the controller hardware.  (Likely a platform_device
created as part of board setup.)

A difference for normal spi_device nodes is that the drivers you'd
presumably want to "subclass" spi_device isn't responsible for
creating the device note.  It might however create a class device
node, and that could end up looking much like that spi_master snippet.

- Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/