X-Git-Url: https://git.openpandora.org/cgi-bin/gitweb.cgi?a=blobdiff_plain;f=Documentation%2Fspi%2Fspi-summary;h=ecc7c9eb9f2938ee00b38aa30863050c3ac01c0d;hb=9cdd79c9b99873d600d397fda012fc3f57cc2776;hp=068732d32276b1f32bf285c10522b7e103e781e4;hpb=4e8f10b7ccf1c3c53a818a157962074a7340732e;p=pandora-kernel.git

diff --git a/Documentation/spi/spi-summary b/Documentation/spi/spi-summary
index 068732d32276..ecc7c9eb9f29 100644
--- 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