mirror of
https://github.com/edk2-porting/linux-next.git
synced 2024-11-19 08:05:27 +08:00
[PATCH] spi: misc fixes
This collects some small SPI patches that seem to be missing from the MM tree: - spi_butterfly kbuild hooks got dropped somehow; this restores them - quick fix for a (theoretical?) m25p80_write() oops noted by Andrew - quick fix for a potential config-specific oops for mtd_dataflash() - minor doc tweaks Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This commit is contained in:
parent
8275c642cc
commit
7111763d39
@ -115,6 +115,9 @@ shows up in sysfs in several locations:
|
||||
/sys/devices/.../CTLR/spiB.C ... spi_device for on bus "B",
|
||||
chipselect C, accessed through CTLR.
|
||||
|
||||
/sys/devices/.../CTLR/spiB.C/modalias ... identifies the driver
|
||||
that should be used with this device (for hotplug/coldplug)
|
||||
|
||||
/sys/bus/spi/devices/spiB.C ... symlink to the physical
|
||||
spiB-C device
|
||||
|
||||
@ -247,6 +250,12 @@ driver is registered:
|
||||
|
||||
Like with other static board-specific setup, you won't unregister those.
|
||||
|
||||
The widely used "card" style computers bundle memory, cpu, and little else
|
||||
onto a card that's maybe just thirty square centimeters. On such systems,
|
||||
your arch/.../mach-.../board-*.c file would primarily provide information
|
||||
about the devices on the mainboard into which such a card is plugged. That
|
||||
certainly includes SPI devices hooked up through the card connectors!
|
||||
|
||||
|
||||
NON-STATIC CONFIGURATIONS
|
||||
|
||||
@ -258,6 +267,10 @@ 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.
|
||||
|
||||
When Linux includes support for MMC/SD/SDIO/DataFlash cards through SPI, those
|
||||
configurations will also be dynamic. Fortunately, those devices all support
|
||||
basic device identification probes, so that support should hotplug normally.
|
||||
|
||||
|
||||
How do I write an "SPI Protocol Driver"?
|
||||
----------------------------------------
|
||||
|
@ -378,7 +378,9 @@ static int m25p80_write(struct mtd_info *mtd, loff_t to, size_t len,
|
||||
|
||||
spi_sync(flash->spi, &m);
|
||||
|
||||
*retlen += m.actual_length - sizeof(flash->command);
|
||||
if (retlen)
|
||||
*retlen += m.actual_length
|
||||
- sizeof(flash->command);
|
||||
}
|
||||
}
|
||||
|
||||
|
@ -508,7 +508,7 @@ add_dataflash(struct spi_device *spi, char *name,
|
||||
priv->partitioned = 1;
|
||||
return add_mtd_partitions(device, parts, nr_parts);
|
||||
}
|
||||
} else if (pdata->nr_parts)
|
||||
} else if (pdata && pdata->nr_parts)
|
||||
dev_warn(&spi->dev, "ignoring %d default partitions on %s\n",
|
||||
pdata->nr_parts, device->name);
|
||||
|
||||
|
@ -65,6 +65,16 @@ config SPI_BITBANG
|
||||
need it. You only need to select this explicitly to support driver
|
||||
modules that aren't part of this kernel tree.
|
||||
|
||||
config SPI_BUTTERFLY
|
||||
tristate "Parallel port adapter for AVR Butterfly (DEVELOPMENT)"
|
||||
depends on SPI_MASTER && PARPORT && EXPERIMENTAL
|
||||
select SPI_BITBANG
|
||||
help
|
||||
This uses a custom parallel port cable to connect to an AVR
|
||||
Butterfly <http://www.atmel.com/products/avr/butterfly>, an
|
||||
inexpensive battery powered microcontroller evaluation board.
|
||||
This same cable can be used to flash new firmware.
|
||||
|
||||
#
|
||||
# Add new SPI master controllers in alphabetical order above this line
|
||||
#
|
||||
|
@ -12,6 +12,7 @@ obj-$(CONFIG_SPI_MASTER) += spi.o
|
||||
|
||||
# SPI master controller drivers (bus)
|
||||
obj-$(CONFIG_SPI_BITBANG) += spi_bitbang.o
|
||||
obj-$(CONFIG_SPI_BUTTERFLY) += spi_butterfly.o
|
||||
# ... add above this line ...
|
||||
|
||||
# SPI protocol drivers (device/link on bus)
|
||||
|
Loading…
Reference in New Issue
Block a user