Pull sony into release branch

[pandora-kernel.git] / Documentation / spi / spi-summary

diff --git a/Documentation/spi/spi-summary b/Documentation/spi/spi-summary
index 068732d..ecc7c9e 100644 (file)
--- a/Documentation/spi/spi-summary
+++ b/Documentation/spi/spi-summary
@@ -262,7 +262,7 @@ NON-STATIC CONFIGURATIONS
 Developer boards often play by different rules than product boards, and one
 example is the potential need to hotplug SPI devices and/or controllers.
 
-For those cases you might need to use use spi_busnum_to_master() to look
+For those cases you might need to use spi_busnum_to_master() to look
 up the spi bus master, and will likely need spi_new_device() to provide the
 board info based on the board that was hotplugged.  Of course, you'd later
 call at least spi_unregister_device() when that board is removed.
@@ -284,7 +284,6 @@ SPI protocol drivers somewhat resemble platform device drivers:
        static struct spi_driver CHIP_driver = {
                .driver = {
                        .name           = "CHIP",
-                       .bus            = &spi_bus_type,
                        .owner          = THIS_MODULE,
                },
 
@@ -312,7 +311,7 @@ might look like this unless you're creating a class_device:
                chip = kzalloc(sizeof *chip, GFP_KERNEL);
                if (!chip)
                        return -ENOMEM;
-               dev_set_drvdata(&spi->dev, chip);
+               spi_set_drvdata(spi, chip);
 
                ... etc
                return 0;
@@ -322,7 +321,7 @@ As soon as it enters probe(), the driver may issue I/O requests to
 the SPI device using "struct spi_message".  When remove() returns,
 the driver guarantees that it won't submit any more such messages.
 
-  - An spi_message is a sequence of of protocol operations, executed
+  - An spi_message is a sequence of protocol operations, executed
     as one atomic sequence.  SPI driver controls include:
 
       + when bidirectional reads and writes start ... by how its