* Re: [PATCH] Add support for the ESTeem 195E (PPC405EP) SBC
From: Josh Boyer @ 2009-07-31 2:38 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Solomon Peachy
In-Reply-To: <20090731004524.GA10243@yookeroo.seuss>
On Fri, Jul 31, 2009 at 10:45:24AM +1000, David Gibson wrote:
>On Thu, Jul 30, 2009 at 04:08:49PM -0400, Josh Boyer wrote:
>> On Thu, Jul 30, 2009 at 03:45:06PM -0400, Solomon Peachy wrote:
>> >On Thu, Jul 30, 2009 at 10:06:30AM -0400, Josh Boyer wrote:
>[snip]
>> >> >+ UART0: serial@ef600400 {
>> >> >+ device_type = "serial";
>> >> >+ compatible = "ns16550";
>> >> >+ reg = <0xef600400 0x00000008>;
>> >> >+ virtual-reg = <0xef600400>;
>> >> >+ clock-frequency = <0>; /* Filled in by zImage */
>> >> >+ current-speed = <0x9600>;
>> >>
>> >> Just a question, but is the baud supposed to be 38400 or 9600? At first glance
>> >> it almost seems like a typo :).
>> >
>> >It's supposed to be 38400 baud, hence the explicit 0x in front. (I lost
>> >count of the number of times I saw '38400' listed in various dts
>> >files...)
>>
>> Cool. Just checking.
>
>Um.. except, surely it's clearer to just list 38400 in decimal, rather
>than 0x9600 which people are very likely to misread as 9600.
That was my point, yes. It is clearer, yes. It's his board though, so I'm
not going to nit-pick about it.
josh
^ permalink raw reply
* Re: Help, please... Multi-Media Distro for PPC?
From: Josh Boyer @ 2009-07-31 1:30 UTC (permalink / raw)
To: skateaboard; +Cc: linuxppc-dev
In-Reply-To: <24628615.post@talk.nabble.com>
On Thu, Jul 30, 2009 at 07:33:24AM -0700, skateaboard wrote:
>
>Ok so I'm really new to this but a single line answer will do, like "One of
>the best and noob friendly PPC Multi media distributors would be _________."
>
>What I have:
>A PPC ibook G3 laptop
>
>What I need help with:
>Finding a linux based multi-media workstation
>
>Why:
>I really want to become more savvy with linux and I need this element added
>to my physical studio's repertoire. My artist studio needs a computer
>workstation and linux seems the best way for me to go.
>
>Specifically:
>I've been searching around the web for a while now and have not yet found a
>PPC optimized(or even kind-of) distro for a multi-media studio for PPC based
>macs. I need some sort of:
>-image, video, audio editing and layering software package.
>
>So, Does this even exist? I've seen "Umbutu Studio"; that seems to do the
I don't think you are going to find any distro that will work sufficiently
well on that class of hardware to do what you are attempting. A G3 is pretty
old...
I don't know how much RAM and what CPU you have, but the only base distros I
know of that would work there are probably gentoo, debian, or for a long shot
Fedora.
josh
^ permalink raw reply
* Re: [PATCH] Add support for the ESTeem 195E (PPC405EP) SBC
From: David Gibson @ 2009-07-31 0:45 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Solomon Peachy
In-Reply-To: <20090730200848.GF10244@zod.rchland.ibm.com>
On Thu, Jul 30, 2009 at 04:08:49PM -0400, Josh Boyer wrote:
> On Thu, Jul 30, 2009 at 03:45:06PM -0400, Solomon Peachy wrote:
> >On Thu, Jul 30, 2009 at 10:06:30AM -0400, Josh Boyer wrote:
[snip]
> >> >+ UART0: serial@ef600400 {
> >> >+ device_type = "serial";
> >> >+ compatible = "ns16550";
> >> >+ reg = <0xef600400 0x00000008>;
> >> >+ virtual-reg = <0xef600400>;
> >> >+ clock-frequency = <0>; /* Filled in by zImage */
> >> >+ current-speed = <0x9600>;
> >>
> >> Just a question, but is the baud supposed to be 38400 or 9600? At first glance
> >> it almost seems like a typo :).
> >
> >It's supposed to be 38400 baud, hence the explicit 0x in front. (I lost
> >count of the number of times I saw '38400' listed in various dts
> >files...)
>
> Cool. Just checking.
Um.. except, surely it's clearer to just list 38400 in decimal, rather
than 0x9600 which people are very likely to misread as 9600.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* [PATCH 6/6] spi: Prefix modalias with "spi:"
From: Anton Vorontsov @ 2009-07-31 0:41 UTC (permalink / raw)
To: Andrew Morton
Cc: Ben Dooks, David Brownell, linux-kernel, lm-sensors, linuxppc-dev,
linux-mtd, Jean Delvare, David Woodhouse
In-Reply-To: <20090731003957.GA23982@oksana.dev.rtsoft.ru>
This makes it consistent with other buses (platform, i2c, vio, ...).
I'm not sure why we use the prefixes, but there must be a reason.
This was easy enough to do it, and I did it.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/gpio/max7301.c | 1 +
drivers/gpio/mcp23s08.c | 1 +
drivers/hwmon/lis3lv02d_spi.c | 2 +-
drivers/hwmon/max1111.c | 1 +
drivers/input/touchscreen/ad7877.c | 1 +
drivers/input/touchscreen/ad7879.c | 1 +
drivers/input/touchscreen/ads7846.c | 1 +
drivers/leds/leds-dac124s085.c | 1 +
drivers/mfd/ezx-pcap.c | 1 +
drivers/misc/eeprom/at25.c | 2 +-
drivers/mmc/host/mmc_spi.c | 1 +
drivers/mtd/devices/mtd_dataflash.c | 1 +
drivers/net/enc28j60.c | 1 +
drivers/net/ks8851.c | 1 +
drivers/net/wireless/libertas/if_spi.c | 1 +
drivers/net/wireless/p54/p54spi.c | 1 +
drivers/net/wireless/wl12xx/main.c | 1 +
drivers/rtc/rtc-ds1305.c | 1 +
drivers/rtc/rtc-ds1390.c | 1 +
drivers/rtc/rtc-ds3234.c | 1 +
drivers/rtc/rtc-m41t94.c | 1 +
drivers/rtc/rtc-max6902.c | 1 +
drivers/rtc/rtc-r9701.c | 1 +
drivers/rtc/rtc-rs5c348.c | 1 +
drivers/serial/max3100.c | 1 +
drivers/spi/spi.c | 3 ++-
drivers/spi/spidev.c | 1 +
drivers/spi/tle62x0.c | 1 +
drivers/staging/stlc45xx/stlc45xx.c | 1 +
drivers/video/backlight/corgi_lcd.c | 1 +
drivers/video/backlight/ltv350qv.c | 1 +
drivers/video/backlight/tdo24m.c | 1 +
drivers/video/backlight/tosa_lcd.c | 2 +-
drivers/video/backlight/vgg2432a4.c | 3 +--
include/linux/mod_devicetable.h | 1 +
scripts/mod/file2alias.c | 4 ++--
36 files changed, 38 insertions(+), 8 deletions(-)
diff --git a/drivers/gpio/max7301.c b/drivers/gpio/max7301.c
index 7b82eaa..480956f 100644
--- a/drivers/gpio/max7301.c
+++ b/drivers/gpio/max7301.c
@@ -339,3 +339,4 @@ module_exit(max7301_exit);
MODULE_AUTHOR("Juergen Beisert");
MODULE_LICENSE("GPL v2");
MODULE_DESCRIPTION("MAX7301 SPI based GPIO-Expander");
+MODULE_ALIAS("spi:" DRIVER_NAME);
diff --git a/drivers/gpio/mcp23s08.c b/drivers/gpio/mcp23s08.c
index f6fae0e..c6c7aa1 100644
--- a/drivers/gpio/mcp23s08.c
+++ b/drivers/gpio/mcp23s08.c
@@ -433,3 +433,4 @@ static void __exit mcp23s08_exit(void)
module_exit(mcp23s08_exit);
MODULE_LICENSE("GPL");
+MODULE_ALIAS("spi:mcp23s08");
diff --git a/drivers/hwmon/lis3lv02d_spi.c b/drivers/hwmon/lis3lv02d_spi.c
index 3827ff0..b7aed07 100644
--- a/drivers/hwmon/lis3lv02d_spi.c
+++ b/drivers/hwmon/lis3lv02d_spi.c
@@ -112,4 +112,4 @@ module_exit(lis302dl_exit);
MODULE_AUTHOR("Daniel Mack <daniel@caiaq.de>");
MODULE_DESCRIPTION("lis3lv02d SPI glue layer");
MODULE_LICENSE("GPL");
-
+MODULE_ALIAS("spi:" DRV_NAME);
diff --git a/drivers/hwmon/max1111.c b/drivers/hwmon/max1111.c
index bfaa665..9ac4972 100644
--- a/drivers/hwmon/max1111.c
+++ b/drivers/hwmon/max1111.c
@@ -242,3 +242,4 @@ module_exit(max1111_exit);
MODULE_AUTHOR("Eric Miao <eric.miao@marvell.com>");
MODULE_DESCRIPTION("MAX1111 ADC Driver");
MODULE_LICENSE("GPL");
+MODULE_ALIAS("spi:max1111");
diff --git a/drivers/input/touchscreen/ad7877.c b/drivers/input/touchscreen/ad7877.c
index ecaeb7e..eb83939 100644
--- a/drivers/input/touchscreen/ad7877.c
+++ b/drivers/input/touchscreen/ad7877.c
@@ -842,3 +842,4 @@ module_exit(ad7877_exit);
MODULE_AUTHOR("Michael Hennerich <hennerich@blackfin.uclinux.org>");
MODULE_DESCRIPTION("AD7877 touchscreen Driver");
MODULE_LICENSE("GPL");
+MODULE_ALIAS("spi:ad7877");
diff --git a/drivers/input/touchscreen/ad7879.c b/drivers/input/touchscreen/ad7879.c
index 5d8a703..19b4db7 100644
--- a/drivers/input/touchscreen/ad7879.c
+++ b/drivers/input/touchscreen/ad7879.c
@@ -779,3 +779,4 @@ module_exit(ad7879_exit);
MODULE_AUTHOR("Michael Hennerich <hennerich@blackfin.uclinux.org>");
MODULE_DESCRIPTION("AD7879(-1) touchscreen Driver");
MODULE_LICENSE("GPL");
+MODULE_ALIAS("spi:ad7879");
diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c
index ba9d38c..09c8109 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -1256,3 +1256,4 @@ module_exit(ads7846_exit);
MODULE_DESCRIPTION("ADS7846 TouchScreen Driver");
MODULE_LICENSE("GPL");
+MODULE_ALIAS("spi:ads7846");
diff --git a/drivers/leds/leds-dac124s085.c b/drivers/leds/leds-dac124s085.c
index 098d9aa..2913d76 100644
--- a/drivers/leds/leds-dac124s085.c
+++ b/drivers/leds/leds-dac124s085.c
@@ -148,3 +148,4 @@ module_exit(dac124s085_leds_exit);
MODULE_AUTHOR("Guennadi Liakhovetski <lg@denx.de>");
MODULE_DESCRIPTION("DAC124S085 LED driver");
MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("spi:dac124s085");
diff --git a/drivers/mfd/ezx-pcap.c b/drivers/mfd/ezx-pcap.c
index c1de4af..1672f30 100644
--- a/drivers/mfd/ezx-pcap.c
+++ b/drivers/mfd/ezx-pcap.c
@@ -505,3 +505,4 @@ module_exit(ezx_pcap_exit);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Daniel Ribeiro / Harald Welte");
MODULE_DESCRIPTION("Motorola PCAP2 ASIC Driver");
+MODULE_ALIAS("spi:ezx-pcap");
diff --git a/drivers/misc/eeprom/at25.c b/drivers/misc/eeprom/at25.c
index b34cb5f..d564de0 100644
--- a/drivers/misc/eeprom/at25.c
+++ b/drivers/misc/eeprom/at25.c
@@ -417,4 +417,4 @@ module_exit(at25_exit);
MODULE_DESCRIPTION("Driver for most SPI EEPROMs");
MODULE_AUTHOR("David Brownell");
MODULE_LICENSE("GPL");
-
+MODULE_ALIAS("spi:at25");
diff --git a/drivers/mmc/host/mmc_spi.c b/drivers/mmc/host/mmc_spi.c
index a461017..d55fe4f 100644
--- a/drivers/mmc/host/mmc_spi.c
+++ b/drivers/mmc/host/mmc_spi.c
@@ -1562,3 +1562,4 @@ MODULE_AUTHOR("Mike Lavender, David Brownell, "
"Hans-Peter Nilsson, Jan Nikitenko");
MODULE_DESCRIPTION("SPI SD/MMC host driver");
MODULE_LICENSE("GPL");
+MODULE_ALIAS("spi:mmc_spi");
diff --git a/drivers/mtd/devices/mtd_dataflash.c b/drivers/mtd/devices/mtd_dataflash.c
index 43976aa..211c27a 100644
--- a/drivers/mtd/devices/mtd_dataflash.c
+++ b/drivers/mtd/devices/mtd_dataflash.c
@@ -966,3 +966,4 @@ module_exit(dataflash_exit);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Andrew Victor, David Brownell");
MODULE_DESCRIPTION("MTD DataFlash driver");
+MODULE_ALIAS("spi:mtd_dataflash");
diff --git a/drivers/net/enc28j60.c b/drivers/net/enc28j60.c
index fc6cc03..c709571 100644
--- a/drivers/net/enc28j60.c
+++ b/drivers/net/enc28j60.c
@@ -1665,3 +1665,4 @@ MODULE_AUTHOR("Claudio Lanconelli <lanconelli.claudio@eptar.com>");
MODULE_LICENSE("GPL");
module_param_named(debug, debug.msg_enable, int, 0);
MODULE_PARM_DESC(debug, "Debug verbosity level (0=none, ..., ffff=all)");
+MODULE_ALIAS("spi:" DRV_NAME);
diff --git a/drivers/net/ks8851.c b/drivers/net/ks8851.c
index 9a1dea6..fe7cf4f 100644
--- a/drivers/net/ks8851.c
+++ b/drivers/net/ks8851.c
@@ -1320,3 +1320,4 @@ MODULE_LICENSE("GPL");
module_param_named(message, msg_enable, int, 0);
MODULE_PARM_DESC(message, "Message verbosity level (0=none, 31=all)");
+MODULE_ALIAS("spi:ks8851");
diff --git a/drivers/net/wireless/libertas/if_spi.c b/drivers/net/wireless/libertas/if_spi.c
index 6564282..ea45765 100644
--- a/drivers/net/wireless/libertas/if_spi.c
+++ b/drivers/net/wireless/libertas/if_spi.c
@@ -1222,3 +1222,4 @@ MODULE_DESCRIPTION("Libertas SPI WLAN Driver");
MODULE_AUTHOR("Andrey Yurovsky <andrey@cozybit.com>, "
"Colin McCabe <colin@cozybit.com>");
MODULE_LICENSE("GPL");
+MODULE_ALIAS("spi:libertas_spi");
diff --git a/drivers/net/wireless/p54/p54spi.c b/drivers/net/wireless/p54/p54spi.c
index 72c7dbd..63bcdd1 100644
--- a/drivers/net/wireless/p54/p54spi.c
+++ b/drivers/net/wireless/p54/p54spi.c
@@ -767,3 +767,4 @@ module_exit(p54spi_exit);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Christian Lamparter <chunkeey@web.de>");
+MODULE_ALIAS("spi:cx3110x");
diff --git a/drivers/net/wireless/wl12xx/main.c b/drivers/net/wireless/wl12xx/main.c
index 603d611..6416406 100644
--- a/drivers/net/wireless/wl12xx/main.c
+++ b/drivers/net/wireless/wl12xx/main.c
@@ -1356,3 +1356,4 @@ module_exit(wl12xx_exit);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Kalle Valo <Kalle.Valo@nokia.com>, "
"Luciano Coelho <luciano.coelho@nokia.com>");
+MODULE_ALIAS("spi:wl12xx");
diff --git a/drivers/rtc/rtc-ds1305.c b/drivers/rtc/rtc-ds1305.c
index 8f410e5..2736b11 100644
--- a/drivers/rtc/rtc-ds1305.c
+++ b/drivers/rtc/rtc-ds1305.c
@@ -841,3 +841,4 @@ module_exit(ds1305_exit);
MODULE_DESCRIPTION("RTC driver for DS1305 and DS1306 chips");
MODULE_LICENSE("GPL");
+MODULE_ALIAS("spi:rtc-ds1305");
diff --git a/drivers/rtc/rtc-ds1390.c b/drivers/rtc/rtc-ds1390.c
index e01b955..cdb7050 100644
--- a/drivers/rtc/rtc-ds1390.c
+++ b/drivers/rtc/rtc-ds1390.c
@@ -189,3 +189,4 @@ module_exit(ds1390_exit);
MODULE_DESCRIPTION("Dallas/Maxim DS1390/93/94 SPI RTC driver");
MODULE_AUTHOR("Mark Jackson <mpfj@mimc.co.uk>");
MODULE_LICENSE("GPL");
+MODULE_ALIAS("spi:rtc-ds1390");
diff --git a/drivers/rtc/rtc-ds3234.c b/drivers/rtc/rtc-ds3234.c
index c51589e..a774ca3 100644
--- a/drivers/rtc/rtc-ds3234.c
+++ b/drivers/rtc/rtc-ds3234.c
@@ -188,3 +188,4 @@ module_exit(ds3234_exit);
MODULE_DESCRIPTION("DS3234 SPI RTC driver");
MODULE_AUTHOR("Dennis Aberilla <denzzzhome@yahoo.com>");
MODULE_LICENSE("GPL");
+MODULE_ALIAS("spi:ds3234");
diff --git a/drivers/rtc/rtc-m41t94.c b/drivers/rtc/rtc-m41t94.c
index c3a18c5..c8c97a4 100644
--- a/drivers/rtc/rtc-m41t94.c
+++ b/drivers/rtc/rtc-m41t94.c
@@ -171,3 +171,4 @@ module_exit(m41t94_exit);
MODULE_AUTHOR("Kim B. Heino <Kim.Heino@bluegiga.com>");
MODULE_DESCRIPTION("Driver for ST M41T94 SPI RTC");
MODULE_LICENSE("GPL");
+MODULE_ALIAS("spi:rtc-m41t94");
diff --git a/drivers/rtc/rtc-max6902.c b/drivers/rtc/rtc-max6902.c
index 36a8ea9..657403e 100644
--- a/drivers/rtc/rtc-max6902.c
+++ b/drivers/rtc/rtc-max6902.c
@@ -175,3 +175,4 @@ module_exit(max6902_exit);
MODULE_DESCRIPTION ("max6902 spi RTC driver");
MODULE_AUTHOR ("Raphael Assenat");
MODULE_LICENSE ("GPL");
+MODULE_ALIAS("spi:rtc-max6902");
diff --git a/drivers/rtc/rtc-r9701.c b/drivers/rtc/rtc-r9701.c
index 42028f2..9beba49 100644
--- a/drivers/rtc/rtc-r9701.c
+++ b/drivers/rtc/rtc-r9701.c
@@ -174,3 +174,4 @@ module_exit(r9701_exit);
MODULE_DESCRIPTION("r9701 spi RTC driver");
MODULE_AUTHOR("Magnus Damm <damm@opensource.se>");
MODULE_LICENSE("GPL");
+MODULE_ALIAS("spi:rtc-r9701");
diff --git a/drivers/rtc/rtc-rs5c348.c b/drivers/rtc/rtc-rs5c348.c
index dd1e2bc..2099037 100644
--- a/drivers/rtc/rtc-rs5c348.c
+++ b/drivers/rtc/rtc-rs5c348.c
@@ -251,3 +251,4 @@ MODULE_AUTHOR("Atsushi Nemoto <anemo@mba.ocn.ne.jp>");
MODULE_DESCRIPTION("Ricoh RS5C348 RTC driver");
MODULE_LICENSE("GPL");
MODULE_VERSION(DRV_VERSION);
+MODULE_ALIAS("spi:rtc-rs5c348");
diff --git a/drivers/serial/max3100.c b/drivers/serial/max3100.c
index 9fd33e5..05d36e2 100644
--- a/drivers/serial/max3100.c
+++ b/drivers/serial/max3100.c
@@ -925,3 +925,4 @@ module_exit(max3100_exit);
MODULE_DESCRIPTION("MAX3100 driver");
MODULE_AUTHOR("Christian Pellegrin <chripell@evolware.org>");
MODULE_LICENSE("GPL");
+MODULE_ALIAS("spi:max3100");
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 8518a6e..49e8486 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -23,6 +23,7 @@
#include <linux/init.h>
#include <linux/cache.h>
#include <linux/mutex.h>
+#include <linux/mod_devicetable.h>
#include <linux/spi/spi.h>
@@ -93,7 +94,7 @@ static int spi_uevent(struct device *dev, struct kobj_uevent_env *env)
{
const struct spi_device *spi = to_spi_device(dev);
- add_uevent_var(env, "MODALIAS=%s", spi->modalias);
+ add_uevent_var(env, "MODALIAS=%s%s", SPI_MODULE_PREFIX, spi->modalias);
return 0;
}
diff --git a/drivers/spi/spidev.c b/drivers/spi/spidev.c
index 606e7a4..f921bd1 100644
--- a/drivers/spi/spidev.c
+++ b/drivers/spi/spidev.c
@@ -688,3 +688,4 @@ module_exit(spidev_exit);
MODULE_AUTHOR("Andrea Paterniani, <a.paterniani@swapp-eng.it>");
MODULE_DESCRIPTION("User mode SPI device interface");
MODULE_LICENSE("GPL");
+MODULE_ALIAS("spi:spidev");
diff --git a/drivers/spi/tle62x0.c b/drivers/spi/tle62x0.c
index 455991f..bf9540f 100644
--- a/drivers/spi/tle62x0.c
+++ b/drivers/spi/tle62x0.c
@@ -329,3 +329,4 @@ module_exit(tle62x0_exit);
MODULE_AUTHOR("Ben Dooks <ben@simtec.co.uk>");
MODULE_DESCRIPTION("TLE62x0 SPI driver");
MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("spi:tle62x0");
diff --git a/drivers/staging/stlc45xx/stlc45xx.c b/drivers/staging/stlc45xx/stlc45xx.c
index a137c78..38d0b24 100644
--- a/drivers/staging/stlc45xx/stlc45xx.c
+++ b/drivers/staging/stlc45xx/stlc45xx.c
@@ -2590,3 +2590,4 @@ module_exit(stlc45xx_exit);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Kalle Valo <kalle.valo@nokia.com>");
+MODULE_ALIAS("spi:cx3110x");
diff --git a/drivers/video/backlight/corgi_lcd.c b/drivers/video/backlight/corgi_lcd.c
index f8a4bb2..2211a85 100644
--- a/drivers/video/backlight/corgi_lcd.c
+++ b/drivers/video/backlight/corgi_lcd.c
@@ -639,3 +639,4 @@ module_exit(corgi_lcd_exit);
MODULE_DESCRIPTION("LCD and backlight driver for SHARP C7x0/Cxx00");
MODULE_AUTHOR("Eric Miao <eric.miao@marvell.com>");
MODULE_LICENSE("GPL");
+MODULE_ALIAS("spi:corgi-lcd");
diff --git a/drivers/video/backlight/ltv350qv.c b/drivers/video/backlight/ltv350qv.c
index 2eb206b..4631ca8 100644
--- a/drivers/video/backlight/ltv350qv.c
+++ b/drivers/video/backlight/ltv350qv.c
@@ -328,3 +328,4 @@ module_exit(ltv350qv_exit);
MODULE_AUTHOR("Haavard Skinnemoen <hskinnemoen@atmel.com>");
MODULE_DESCRIPTION("Samsung LTV350QV LCD Driver");
MODULE_LICENSE("GPL");
+MODULE_ALIAS("spi:ltv350qv");
diff --git a/drivers/video/backlight/tdo24m.c b/drivers/video/backlight/tdo24m.c
index 51422fc..bbfb502 100644
--- a/drivers/video/backlight/tdo24m.c
+++ b/drivers/video/backlight/tdo24m.c
@@ -472,3 +472,4 @@ module_exit(tdo24m_exit);
MODULE_AUTHOR("Eric Miao <eric.miao@marvell.com>");
MODULE_DESCRIPTION("Driver for Toppoly TDO24M LCD Panel");
MODULE_LICENSE("GPL");
+MODULE_ALIAS("spi:tdo24m");
diff --git a/drivers/video/backlight/tosa_lcd.c b/drivers/video/backlight/tosa_lcd.c
index b7fbc75..50ec17d 100644
--- a/drivers/video/backlight/tosa_lcd.c
+++ b/drivers/video/backlight/tosa_lcd.c
@@ -300,4 +300,4 @@ module_exit(tosa_lcd_exit);
MODULE_AUTHOR("Dmitry Baryshkov");
MODULE_LICENSE("GPL v2");
MODULE_DESCRIPTION("LCD/Backlight control for Sharp SL-6000 PDA");
-
+MODULE_ALIAS("spi:tosa-lcd");
diff --git a/drivers/video/backlight/vgg2432a4.c b/drivers/video/backlight/vgg2432a4.c
index 8e653b8..b49063c 100644
--- a/drivers/video/backlight/vgg2432a4.c
+++ b/drivers/video/backlight/vgg2432a4.c
@@ -280,5 +280,4 @@ module_exit(vgg2432a4_exit);
MODULE_AUTHOR("Ben Dooks <ben-linux@fluff.org>");
MODULE_DESCRIPTION("VGG2432A4 LCD Driver");
MODULE_LICENSE("GPL v2");
-
-
+MODULE_ALIAS("spi:VGG2432A4");
diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index b34f1ef..f58e9d8 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -402,6 +402,7 @@ struct i2c_device_id {
/* spi */
#define SPI_NAME_SIZE 32
+#define SPI_MODULE_PREFIX "spi:"
struct spi_device_id {
char name[SPI_NAME_SIZE];
diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
index 9d446e3..62a9025 100644
--- a/scripts/mod/file2alias.c
+++ b/scripts/mod/file2alias.c
@@ -657,11 +657,11 @@ static int do_i2c_entry(const char *filename, struct i2c_device_id *id,
return 1;
}
-/* Looks like: S */
+/* Looks like: spi:S */
static int do_spi_entry(const char *filename, struct spi_device_id *id,
char *alias)
{
- sprintf(alias, "%s", id->name);
+ sprintf(alias, SPI_MODULE_PREFIX "%s", id->name);
return 1;
}
--
1.6.3.3
^ permalink raw reply related
* [PATCH 5/6] hwmon: lm70: Convert to device table matching
From: Anton Vorontsov @ 2009-07-31 0:41 UTC (permalink / raw)
To: Andrew Morton
Cc: Ben Dooks, David Brownell, linux-kernel, lm-sensors, linuxppc-dev,
linux-mtd, Jean Delvare, David Woodhouse
In-Reply-To: <20090731003957.GA23982@oksana.dev.rtsoft.ru>
This patch makes the code a little bit nicer, and shorter.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/hwmon/lm70.c | 55 +++++++++++++++++--------------------------------
1 files changed, 19 insertions(+), 36 deletions(-)
diff --git a/drivers/hwmon/lm70.c b/drivers/hwmon/lm70.c
index ae6204f..ab8a5d3 100644
--- a/drivers/hwmon/lm70.c
+++ b/drivers/hwmon/lm70.c
@@ -32,6 +32,7 @@
#include <linux/sysfs.h>
#include <linux/hwmon.h>
#include <linux/mutex.h>
+#include <linux/mod_devicetable.h>
#include <linux/spi/spi.h>
@@ -130,11 +131,20 @@ static DEVICE_ATTR(name, S_IRUGO, lm70_show_name, NULL);
/*----------------------------------------------------------------------*/
-static int __devinit common_probe(struct spi_device *spi, int chip)
+static int __devinit lm70_probe(struct spi_device *spi)
{
+ int chip = spi_get_device_id(spi)->driver_data;
struct lm70 *p_lm70;
int status;
+ /* signaling is SPI_MODE_0 for both LM70 and TMP121 */
+ if (spi->mode & (SPI_CPOL | SPI_CPHA))
+ return -EINVAL;
+
+ /* 3-wire link (shared SI/SO) for LM70 */
+ if (chip == LM70_CHIP_LM70 && !(spi->mode & SPI_3WIRE))
+ return -EINVAL;
+
/* NOTE: we assume 8-bit words, and convert to 16 bits manually */
p_lm70 = kzalloc(sizeof *p_lm70, GFP_KERNEL);
@@ -170,24 +180,6 @@ out_dev_reg_failed:
return status;
}
-static int __devinit lm70_probe(struct spi_device *spi)
-{
- /* signaling is SPI_MODE_0 on a 3-wire link (shared SI/SO) */
- if ((spi->mode & (SPI_CPOL | SPI_CPHA)) || !(spi->mode & SPI_3WIRE))
- return -EINVAL;
-
- return common_probe(spi, LM70_CHIP_LM70);
-}
-
-static int __devinit tmp121_probe(struct spi_device *spi)
-{
- /* signaling is SPI_MODE_0 with only MISO connected */
- if (spi->mode & (SPI_CPOL | SPI_CPHA))
- return -EINVAL;
-
- return common_probe(spi, LM70_CHIP_TMP121);
-}
-
static int __devexit lm70_remove(struct spi_device *spi)
{
struct lm70 *p_lm70 = dev_get_drvdata(&spi->dev);
@@ -201,41 +193,32 @@ static int __devexit lm70_remove(struct spi_device *spi)
return 0;
}
-static struct spi_driver tmp121_driver = {
- .driver = {
- .name = "tmp121",
- .owner = THIS_MODULE,
- },
- .probe = tmp121_probe,
- .remove = __devexit_p(lm70_remove),
+
+static const struct spi_device_id lm70_ids[] = {
+ { "lm70", LM70_CHIP_LM70 },
+ { "tmp121", LM70_CHIP_TMP121 },
+ { },
};
+MODULE_DEVICE_TABLE(spi, lm70_ids);
static struct spi_driver lm70_driver = {
.driver = {
.name = "lm70",
.owner = THIS_MODULE,
},
+ .id_table = lm70_ids,
.probe = lm70_probe,
.remove = __devexit_p(lm70_remove),
};
static int __init init_lm70(void)
{
- int ret = spi_register_driver(&lm70_driver);
- if (ret)
- return ret;
-
- ret = spi_register_driver(&tmp121_driver);
- if (ret)
- spi_unregister_driver(&lm70_driver);
-
- return ret;
+ return spi_register_driver(&lm70_driver);
}
static void __exit cleanup_lm70(void)
{
spi_unregister_driver(&lm70_driver);
- spi_unregister_driver(&tmp121_driver);
}
module_init(init_lm70);
--
1.6.3.3
^ permalink raw reply related
* [PATCH 4/6] hwmon: adxx: Convert to device table matching
From: Anton Vorontsov @ 2009-07-31 0:41 UTC (permalink / raw)
To: Andrew Morton
Cc: Ben Dooks, David Brownell, linux-kernel, lm-sensors, linuxppc-dev,
linux-mtd, Jean Delvare, David Woodhouse
In-Reply-To: <20090731003957.GA23982@oksana.dev.rtsoft.ru>
This patch makes the code a little bit nicer, and shorter.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/hwmon/adcxx.c | 101 ++++++++-----------------------------------------
1 files changed, 16 insertions(+), 85 deletions(-)
diff --git a/drivers/hwmon/adcxx.c b/drivers/hwmon/adcxx.c
index 242294d..5e9e095 100644
--- a/drivers/hwmon/adcxx.c
+++ b/drivers/hwmon/adcxx.c
@@ -43,6 +43,7 @@
#include <linux/hwmon.h>
#include <linux/hwmon-sysfs.h>
#include <linux/mutex.h>
+#include <linux/mod_devicetable.h>
#include <linux/spi/spi.h>
#define DRVNAME "adcxx"
@@ -157,8 +158,9 @@ static struct sensor_device_attribute ad_input[] = {
/*----------------------------------------------------------------------*/
-static int __devinit adcxx_probe(struct spi_device *spi, int channels)
+static int __devinit adcxx_probe(struct spi_device *spi)
{
+ int channels = spi_get_device_id(spi)->driver_data;
struct adcxx *adc;
int status;
int i;
@@ -204,26 +206,6 @@ out_err:
return status;
}
-static int __devinit adcxx1s_probe(struct spi_device *spi)
-{
- return adcxx_probe(spi, 1);
-}
-
-static int __devinit adcxx2s_probe(struct spi_device *spi)
-{
- return adcxx_probe(spi, 2);
-}
-
-static int __devinit adcxx4s_probe(struct spi_device *spi)
-{
- return adcxx_probe(spi, 4);
-}
-
-static int __devinit adcxx8s_probe(struct spi_device *spi)
-{
- return adcxx_probe(spi, 8);
-}
-
static int __devexit adcxx_remove(struct spi_device *spi)
{
struct adcxx *adc = dev_get_drvdata(&spi->dev);
@@ -241,79 +223,33 @@ static int __devexit adcxx_remove(struct spi_device *spi)
return 0;
}
-static struct spi_driver adcxx1s_driver = {
- .driver = {
- .name = "adcxx1s",
- .owner = THIS_MODULE,
- },
- .probe = adcxx1s_probe,
- .remove = __devexit_p(adcxx_remove),
+static const struct spi_device_id adcxx_ids[] = {
+ { "adcxx1s", 1 },
+ { "adcxx2s", 2 },
+ { "adcxx4s", 4 },
+ { "adcxx8s", 8 },
+ { },
};
+MODULE_DEVICE_TABLE(spi, adcxx_ids);
-static struct spi_driver adcxx2s_driver = {
+static struct spi_driver adcxx_driver = {
.driver = {
- .name = "adcxx2s",
+ .name = "adcxx",
.owner = THIS_MODULE,
},
- .probe = adcxx2s_probe,
- .remove = __devexit_p(adcxx_remove),
-};
-
-static struct spi_driver adcxx4s_driver = {
- .driver = {
- .name = "adcxx4s",
- .owner = THIS_MODULE,
- },
- .probe = adcxx4s_probe,
- .remove = __devexit_p(adcxx_remove),
-};
-
-static struct spi_driver adcxx8s_driver = {
- .driver = {
- .name = "adcxx8s",
- .owner = THIS_MODULE,
- },
- .probe = adcxx8s_probe,
+ .id_table = adcxx_ids,
+ .probe = adcxx_probe,
.remove = __devexit_p(adcxx_remove),
};
static int __init init_adcxx(void)
{
- int status;
- status = spi_register_driver(&adcxx1s_driver);
- if (status)
- goto reg_1_failed;
-
- status = spi_register_driver(&adcxx2s_driver);
- if (status)
- goto reg_2_failed;
-
- status = spi_register_driver(&adcxx4s_driver);
- if (status)
- goto reg_4_failed;
-
- status = spi_register_driver(&adcxx8s_driver);
- if (status)
- goto reg_8_failed;
-
- return status;
-
-reg_8_failed:
- spi_unregister_driver(&adcxx4s_driver);
-reg_4_failed:
- spi_unregister_driver(&adcxx2s_driver);
-reg_2_failed:
- spi_unregister_driver(&adcxx1s_driver);
-reg_1_failed:
- return status;
+ return spi_register_driver(&adcxx_driver);
}
static void __exit exit_adcxx(void)
{
- spi_unregister_driver(&adcxx1s_driver);
- spi_unregister_driver(&adcxx2s_driver);
- spi_unregister_driver(&adcxx4s_driver);
- spi_unregister_driver(&adcxx8s_driver);
+ spi_unregister_driver(&adcxx_driver);
}
module_init(init_adcxx);
@@ -322,8 +258,3 @@ module_exit(exit_adcxx);
MODULE_AUTHOR("Marc Pignat");
MODULE_DESCRIPTION("National Semiconductor adcxx8sxxx Linux driver");
MODULE_LICENSE("GPL");
-
-MODULE_ALIAS("adcxx1s");
-MODULE_ALIAS("adcxx2s");
-MODULE_ALIAS("adcxx4s");
-MODULE_ALIAS("adcxx8s");
--
1.6.3.3
^ permalink raw reply related
* [PATCH 2/6] mtd: m25p80: Convert to device table matching
From: Anton Vorontsov @ 2009-07-31 0:41 UTC (permalink / raw)
To: Andrew Morton
Cc: Ben Dooks, David Brownell, linux-kernel, lm-sensors, linuxppc-dev,
linux-mtd, Jean Delvare, David Woodhouse
In-Reply-To: <20090731003957.GA23982@oksana.dev.rtsoft.ru>
This patch converts the m25p80 driver so that now it uses .id_table
for device matching, making it properly detect devices on OpenFirmware
platforms (prior to this patch the driver misdetected non-JEDEC chips,
seeing all chips as "m25p80").
Also, now jedec_probe() only does jedec probing, nothing else. If it
is not able to detect a chip, NULL is returned and the driver fall
backs to the information specified by the platform (platform_data, or
exact ID).
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/mtd/devices/m25p80.c | 146 +++++++++++++++++++++++-------------------
1 files changed, 80 insertions(+), 66 deletions(-)
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index 10ed195..0d74b38 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -21,6 +21,7 @@
#include <linux/interrupt.h>
#include <linux/mutex.h>
#include <linux/math64.h>
+#include <linux/mod_devicetable.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/partitions.h>
@@ -462,8 +463,6 @@ static int m25p80_write(struct mtd_info *mtd, loff_t to, size_t len,
*/
struct flash_info {
- char *name;
-
/* JEDEC id zero means "no ID" (most older chips); otherwise it has
* a high byte of zero plus three data bytes: the manufacturer id,
* then a two byte device id.
@@ -481,74 +480,83 @@ struct flash_info {
#define SECT_4K 0x01 /* OPCODE_BE_4K works uniformly */
};
+#define INFO(_jedec_id, _ext_id, _sector_size, _n_sectors, _flags) \
+ ((kernel_ulong_t)&(struct flash_info) { \
+ .jedec_id = (_jedec_id), \
+ .ext_id = (_ext_id), \
+ .sector_size = (_sector_size), \
+ .n_sectors = (_n_sectors), \
+ .flags = (_flags), \
+ })
/* NOTE: double check command sets and memory organization when you add
* more flash chips. This current list focusses on newer chips, which
* have been converging on command sets which including JEDEC ID.
*/
-static struct flash_info __devinitdata m25p_data [] = {
-
+static const struct spi_device_id m25p_ids[] = {
/* Atmel -- some are (confusingly) marketed as "DataFlash" */
- { "at25fs010", 0x1f6601, 0, 32 * 1024, 4, SECT_4K, },
- { "at25fs040", 0x1f6604, 0, 64 * 1024, 8, SECT_4K, },
+ { "at25fs010", INFO(0x1f6601, 0, 32 * 1024, 4, SECT_4K) },
+ { "at25fs040", INFO(0x1f6604, 0, 64 * 1024, 8, SECT_4K) },
- { "at25df041a", 0x1f4401, 0, 64 * 1024, 8, SECT_4K, },
- { "at25df641", 0x1f4800, 0, 64 * 1024, 128, SECT_4K, },
+ { "at25df041a", INFO(0x1f4401, 0, 64 * 1024, 8, SECT_4K) },
+ { "at25df641", INFO(0x1f4800, 0, 64 * 1024, 128, SECT_4K) },
- { "at26f004", 0x1f0400, 0, 64 * 1024, 8, SECT_4K, },
- { "at26df081a", 0x1f4501, 0, 64 * 1024, 16, SECT_4K, },
- { "at26df161a", 0x1f4601, 0, 64 * 1024, 32, SECT_4K, },
- { "at26df321", 0x1f4701, 0, 64 * 1024, 64, SECT_4K, },
+ { "at26f004", INFO(0x1f0400, 0, 64 * 1024, 8, SECT_4K) },
+ { "at26df081a", INFO(0x1f4501, 0, 64 * 1024, 16, SECT_4K) },
+ { "at26df161a", INFO(0x1f4601, 0, 64 * 1024, 32, SECT_4K) },
+ { "at26df321", INFO(0x1f4701, 0, 64 * 1024, 64, SECT_4K) },
/* Macronix */
- { "mx25l12805d", 0xc22018, 0, 64 * 1024, 256, },
+ { "mx25l12805d", INFO(0xc22018, 0, 64 * 1024, 256, 0) },
/* Spansion -- single (large) sector size only, at least
* for the chips listed here (without boot sectors).
*/
- { "s25sl004a", 0x010212, 0, 64 * 1024, 8, },
- { "s25sl008a", 0x010213, 0, 64 * 1024, 16, },
- { "s25sl016a", 0x010214, 0, 64 * 1024, 32, },
- { "s25sl032a", 0x010215, 0, 64 * 1024, 64, },
- { "s25sl064a", 0x010216, 0, 64 * 1024, 128, },
- { "s25sl12800", 0x012018, 0x0300, 256 * 1024, 64, },
- { "s25sl12801", 0x012018, 0x0301, 64 * 1024, 256, },
+ { "s25sl004a", INFO(0x010212, 0, 64 * 1024, 8, 0) },
+ { "s25sl008a", INFO(0x010213, 0, 64 * 1024, 16, 0) },
+ { "s25sl016a", INFO(0x010214, 0, 64 * 1024, 32, 0) },
+ { "s25sl032a", INFO(0x010215, 0, 64 * 1024, 64, 0) },
+ { "s25sl064a", INFO(0x010216, 0, 64 * 1024, 128, 0) },
+ { "s25sl12800", INFO(0x012018, 0x0300, 256 * 1024, 64, 0) },
+ { "s25sl12801", INFO(0x012018, 0x0301, 64 * 1024, 256, 0) },
/* SST -- large erase sizes are "overlays", "sectors" are 4K */
- { "sst25vf040b", 0xbf258d, 0, 64 * 1024, 8, SECT_4K, },
- { "sst25vf080b", 0xbf258e, 0, 64 * 1024, 16, SECT_4K, },
- { "sst25vf016b", 0xbf2541, 0, 64 * 1024, 32, SECT_4K, },
- { "sst25vf032b", 0xbf254a, 0, 64 * 1024, 64, SECT_4K, },
+ { "sst25vf040b", INFO(0xbf258d, 0, 64 * 1024, 8, SECT_4K) },
+ { "sst25vf080b", INFO(0xbf258e, 0, 64 * 1024, 16, SECT_4K) },
+ { "sst25vf016b", INFO(0xbf2541, 0, 64 * 1024, 32, SECT_4K) },
+ { "sst25vf032b", INFO(0xbf254a, 0, 64 * 1024, 64, SECT_4K) },
/* ST Microelectronics -- newer production may have feature updates */
- { "m25p05", 0x202010, 0, 32 * 1024, 2, },
- { "m25p10", 0x202011, 0, 32 * 1024, 4, },
- { "m25p20", 0x202012, 0, 64 * 1024, 4, },
- { "m25p40", 0x202013, 0, 64 * 1024, 8, },
- { "m25p80", 0, 0, 64 * 1024, 16, },
- { "m25p16", 0x202015, 0, 64 * 1024, 32, },
- { "m25p32", 0x202016, 0, 64 * 1024, 64, },
- { "m25p64", 0x202017, 0, 64 * 1024, 128, },
- { "m25p128", 0x202018, 0, 256 * 1024, 64, },
-
- { "m45pe10", 0x204011, 0, 64 * 1024, 2, },
- { "m45pe80", 0x204014, 0, 64 * 1024, 16, },
- { "m45pe16", 0x204015, 0, 64 * 1024, 32, },
-
- { "m25pe80", 0x208014, 0, 64 * 1024, 16, },
- { "m25pe16", 0x208015, 0, 64 * 1024, 32, SECT_4K, },
+ { "m25p05", INFO(0x202010, 0, 32 * 1024, 2, 0) },
+ { "m25p10", INFO(0x202011, 0, 32 * 1024, 4, 0) },
+ { "m25p20", INFO(0x202012, 0, 64 * 1024, 4, 0) },
+ { "m25p40", INFO(0x202013, 0, 64 * 1024, 8, 0) },
+ { "m25p80", INFO(0x202014, 0, 64 * 1024, 16, 0) },
+ { "m25p16", INFO(0x202015, 0, 64 * 1024, 32, 0) },
+ { "m25p32", INFO(0x202016, 0, 64 * 1024, 64, 0) },
+ { "m25p64", INFO(0x202017, 0, 64 * 1024, 128, 0) },
+ { "m25p128", INFO(0x202018, 0, 256 * 1024, 64, 0) },
+
+ { "m45pe10", INFO(0x204011, 0, 64 * 1024, 2, 0) },
+ { "m45pe80", INFO(0x204014, 0, 64 * 1024, 16, 0) },
+ { "m45pe16", INFO(0x204015, 0, 64 * 1024, 32, 0) },
+
+ { "m25pe80", INFO(0x208014, 0, 64 * 1024, 16, 0) },
+ { "m25pe16", INFO(0x208015, 0, 64 * 1024, 32, SECT_4K) },
/* Winbond -- w25x "blocks" are 64K, "sectors" are 4KiB */
- { "w25x10", 0xef3011, 0, 64 * 1024, 2, SECT_4K, },
- { "w25x20", 0xef3012, 0, 64 * 1024, 4, SECT_4K, },
- { "w25x40", 0xef3013, 0, 64 * 1024, 8, SECT_4K, },
- { "w25x80", 0xef3014, 0, 64 * 1024, 16, SECT_4K, },
- { "w25x16", 0xef3015, 0, 64 * 1024, 32, SECT_4K, },
- { "w25x32", 0xef3016, 0, 64 * 1024, 64, SECT_4K, },
- { "w25x64", 0xef3017, 0, 64 * 1024, 128, SECT_4K, },
+ { "w25x10", INFO(0xef3011, 0, 64 * 1024, 2, SECT_4K) },
+ { "w25x20", INFO(0xef3012, 0, 64 * 1024, 4, SECT_4K) },
+ { "w25x40", INFO(0xef3013, 0, 64 * 1024, 8, SECT_4K) },
+ { "w25x80", INFO(0xef3014, 0, 64 * 1024, 16, SECT_4K) },
+ { "w25x16", INFO(0xef3015, 0, 64 * 1024, 32, SECT_4K) },
+ { "w25x32", INFO(0xef3016, 0, 64 * 1024, 64, SECT_4K) },
+ { "w25x64", INFO(0xef3017, 0, 64 * 1024, 128, SECT_4K) },
+ { },
};
+MODULE_DEVICE_TABLE(spi, m25p_ids);
-static struct flash_info *__devinit jedec_probe(struct spi_device *spi)
+static const struct spi_device_id *__devinit jedec_probe(struct spi_device *spi)
{
int tmp;
u8 code = OPCODE_RDID;
@@ -575,16 +583,14 @@ static struct flash_info *__devinit jedec_probe(struct spi_device *spi)
ext_jedec = id[3] << 8 | id[4];
- for (tmp = 0, info = m25p_data;
- tmp < ARRAY_SIZE(m25p_data);
- tmp++, info++) {
+ for (tmp = 0; tmp < ARRAY_SIZE(m25p_ids) - 1; tmp++) {
+ info = (void *)m25p_ids[tmp].driver_data;
if (info->jedec_id == jedec) {
if (info->ext_id != 0 && info->ext_id != ext_jedec)
continue;
- return info;
+ return &m25p_ids[tmp];
}
}
- dev_err(&spi->dev, "unrecognized JEDEC id %06x\n", jedec);
return NULL;
}
@@ -596,6 +602,7 @@ static struct flash_info *__devinit jedec_probe(struct spi_device *spi)
*/
static int __devinit m25p_probe(struct spi_device *spi)
{
+ const struct spi_device_id *id;
struct flash_platform_data *data;
struct m25p *flash;
struct flash_info *info;
@@ -608,32 +615,38 @@ static int __devinit m25p_probe(struct spi_device *spi)
*/
data = spi->dev.platform_data;
if (data && data->type) {
- for (i = 0, info = m25p_data;
- i < ARRAY_SIZE(m25p_data);
- i++, info++) {
- if (strcmp(data->type, info->name) == 0)
- break;
+ for (i = 0; i < ARRAY_SIZE(m25p_ids) - 1; i++) {
+ id = &m25p_ids[i];
+ info = (void *)m25p_ids[i].driver_data;
+ if (strcmp(data->type, id->name))
+ continue;
+ break;
}
/* unrecognized chip? */
- if (i == ARRAY_SIZE(m25p_data)) {
+ if (i == ARRAY_SIZE(m25p_ids) - 1) {
DEBUG(MTD_DEBUG_LEVEL0, "%s: unrecognized id %s\n",
dev_name(&spi->dev), data->type);
info = NULL;
/* recognized; is that chip really what's there? */
} else if (info->jedec_id) {
- struct flash_info *chip = jedec_probe(spi);
+ id = jedec_probe(spi);
- if (!chip || chip != info) {
+ if (id != &m25p_ids[i]) {
dev_warn(&spi->dev, "found %s, expected %s\n",
- chip ? chip->name : "UNKNOWN",
- info->name);
+ id ? id->name : "UNKNOWN",
+ m25p_ids[i].name);
info = NULL;
}
}
- } else
- info = jedec_probe(spi);
+ } else {
+ id = jedec_probe(spi);
+ if (!id)
+ id = spi_get_device_id(spi);
+
+ info = (void *)id->driver_data;
+ }
if (!info)
return -ENODEV;
@@ -680,7 +693,7 @@ static int __devinit m25p_probe(struct spi_device *spi)
flash->mtd.dev.parent = &spi->dev;
- dev_info(&spi->dev, "%s (%lld Kbytes)\n", info->name,
+ dev_info(&spi->dev, "%s (%lld Kbytes)\n", id->name,
(long long)flash->mtd.size >> 10);
DEBUG(MTD_DEBUG_LEVEL2,
@@ -766,6 +779,7 @@ static struct spi_driver m25p80_driver = {
.bus = &spi_bus_type,
.owner = THIS_MODULE,
},
+ .id_table = m25p_ids,
.probe = m25p_probe,
.remove = __devexit_p(m25p_remove),
--
1.6.3.3
^ permalink raw reply related
* [PATCH 3/6] of: Remove "stm,m25p40" alias
From: Anton Vorontsov @ 2009-07-31 0:41 UTC (permalink / raw)
To: Andrew Morton
Cc: Ben Dooks, David Brownell, linux-kernel, lm-sensors, linuxppc-dev,
linux-mtd, Jean Delvare, David Woodhouse
In-Reply-To: <20090731003957.GA23982@oksana.dev.rtsoft.ru>
The alias isn't needed any longer since the m25p80 driver converted
to the module device table matching.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/of/base.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 69f85c0..ddf224d 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -447,7 +447,6 @@ struct of_modalias_table {
static struct of_modalias_table of_modalias_table[] = {
{ "fsl,mcu-mpc8349emitx", "mcu-mpc8349emitx" },
{ "mmc-spi-slot", "mmc_spi" },
- { "stm,m25p40", "m25p80" },
};
/**
--
1.6.3.3
^ permalink raw reply related
* [PATCH 1/6] spi: Add support for device table matching
From: Anton Vorontsov @ 2009-07-31 0:40 UTC (permalink / raw)
To: Andrew Morton
Cc: Ben Dooks, David Brownell, linux-kernel, lm-sensors, linuxppc-dev,
linux-mtd, Jean Delvare, David Woodhouse
In-Reply-To: <20090731003957.GA23982@oksana.dev.rtsoft.ru>
With this patch spi drivers can use standard spi_driver.id_table and
MODULE_DEVICE_TABLE() mechanisms to bind against the devices. Just
like we do with I2C drivers.
This is useful when a single driver supports several variants of
devices but it is not possible to detect them in run-time (like
non-JEDEC chips probing in drivers/mtd/devices/m25p80.c), and
when platform_data usage is overkill.
This patch also makes life a lot easier on OpenFirmware platforms,
since with OF we extensively use proper device IDs in modaliases.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/spi/spi.c | 23 +++++++++++++++++++++++
include/linux/mod_devicetable.h | 10 ++++++++++
include/linux/spi/spi.h | 10 ++++++++--
scripts/mod/file2alias.c | 13 +++++++++++++
4 files changed, 54 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 70845cc..8518a6e 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -59,9 +59,32 @@ static struct device_attribute spi_dev_attrs[] = {
* and the sysfs version makes coldplug work too.
*/
+static const struct spi_device_id *spi_match_id(const struct spi_device_id *id,
+ const struct spi_device *sdev)
+{
+ while (id->name[0]) {
+ if (!strcmp(sdev->modalias, id->name))
+ return id;
+ id++;
+ }
+ return NULL;
+}
+
+const struct spi_device_id *spi_get_device_id(const struct spi_device *sdev)
+{
+ const struct spi_driver *sdrv = to_spi_driver(sdev->dev.driver);
+
+ return spi_match_id(sdrv->id_table, sdev);
+}
+EXPORT_SYMBOL_GPL(spi_get_device_id);
+
static int spi_match_device(struct device *dev, struct device_driver *drv)
{
const struct spi_device *spi = to_spi_device(dev);
+ const struct spi_driver *sdrv = to_spi_driver(drv);
+
+ if (sdrv->id_table)
+ return !!spi_match_id(sdrv->id_table, spi);
return strcmp(spi->modalias, drv->name) == 0;
}
diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index 1bf5900..b34f1ef 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -399,6 +399,16 @@ struct i2c_device_id {
__attribute__((aligned(sizeof(kernel_ulong_t))));
};
+/* spi */
+
+#define SPI_NAME_SIZE 32
+
+struct spi_device_id {
+ char name[SPI_NAME_SIZE];
+ kernel_ulong_t driver_data /* Data private to the driver */
+ __attribute__((aligned(sizeof(kernel_ulong_t))));
+};
+
/* dmi */
enum dmi_field {
DMI_NONE,
diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
index c47c4b4..2b444df 100644
--- a/include/linux/spi/spi.h
+++ b/include/linux/spi/spi.h
@@ -20,6 +20,7 @@
#define __LINUX_SPI_H
#include <linux/device.h>
+#include <linux/mod_devicetable.h>
/*
* INTERFACES between SPI master-side drivers and SPI infrastructure.
@@ -86,7 +87,7 @@ struct spi_device {
int irq;
void *controller_state;
void *controller_data;
- char modalias[32];
+ char modalias[SPI_NAME_SIZE];
/*
* likely need more hooks for more protocol options affecting how
@@ -145,6 +146,7 @@ struct spi_message;
/**
* struct spi_driver - Host side "protocol" driver
+ * @id_table: List of SPI devices supported by this driver
* @probe: Binds this driver to the spi device. Drivers can verify
* that the device is actually present, and may need to configure
* characteristics (such as bits_per_word) which weren't needed for
@@ -170,6 +172,7 @@ struct spi_message;
* MMC, RTC, filesystem character device nodes, and hardware monitoring.
*/
struct spi_driver {
+ const struct spi_device_id *id_table;
int (*probe)(struct spi_device *spi);
int (*remove)(struct spi_device *spi);
void (*shutdown)(struct spi_device *spi);
@@ -732,7 +735,7 @@ struct spi_board_info {
* controller_data goes to spi_device.controller_data,
* irq is copied too
*/
- char modalias[32];
+ char modalias[SPI_NAME_SIZE];
const void *platform_data;
void *controller_data;
int irq;
@@ -800,4 +803,7 @@ spi_unregister_device(struct spi_device *spi)
device_unregister(&spi->dev);
}
+extern const struct spi_device_id *
+spi_get_device_id(const struct spi_device *sdev);
+
#endif /* __LINUX_SPI_H */
diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
index 40e0045..9d446e3 100644
--- a/scripts/mod/file2alias.c
+++ b/scripts/mod/file2alias.c
@@ -657,6 +657,15 @@ static int do_i2c_entry(const char *filename, struct i2c_device_id *id,
return 1;
}
+/* Looks like: S */
+static int do_spi_entry(const char *filename, struct spi_device_id *id,
+ char *alias)
+{
+ sprintf(alias, "%s", id->name);
+
+ return 1;
+}
+
static const struct dmifield {
const char *prefix;
int field;
@@ -853,6 +862,10 @@ void handle_moddevtable(struct module *mod, struct elf_info *info,
do_table(symval, sym->st_size,
sizeof(struct i2c_device_id), "i2c",
do_i2c_entry, mod);
+ else if (sym_is(symname, "__mod_spi_device_table"))
+ do_table(symval, sym->st_size,
+ sizeof(struct spi_device_id), "spi",
+ do_spi_entry, mod);
else if (sym_is(symname, "__mod_dmi_device_table"))
do_table(symval, sym->st_size,
sizeof(struct dmi_system_id), "dmi",
--
1.6.3.3
^ permalink raw reply related
* [PATCH v2 0/6] Device table matching for SPI subsystem
From: Anton Vorontsov @ 2009-07-31 0:39 UTC (permalink / raw)
To: Andrew Morton
Cc: Ben Dooks, David Brownell, linux-kernel, lm-sensors, linuxppc-dev,
linux-mtd, Jean Delvare, David Woodhouse
Andrew,
This new patch set overwrites following patches:
hwmon-lm70-convert-to-device-table-matching.patch
hwmon-adxx-convert-to-device-table-matching.patch
spi-merge-probe-and-probe_id-callbacks.patch
spi-prefix-modalias-with-spi.patch
of-remove-stmm25p40-alias.patch
mtd-m25p80-convert-to-device-table-matching.patch
spi-add-support-for-device-table-matching.patch
Changes since v1:
- Implemented Ben Dooks' idea of spi_get_device_id(), so we won't
call spi_match_id() twice for drivers that don't need the id.
- "spi: Merge probe and probe_id callbacks" patch no longer needed
as we don't change probe()'s arguments;
- Rename spi_device_id->data to driver_data, and turn it into
kernel_ulong_t to match majority of subsystems. Most drivers
don't need a pointer type anyway (e.g. m25p80 needs it, but
lm70 and adcxx don't);
- SPI_NAME_SIZE now defined to 32 (as it should be, using 20
for name size was a cut-n-paste typo from I2C defines).
Thanks!
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* [PATCH 3/3] Support for PCI Express reset type
From: Mike Mason @ 2009-07-30 22:42 UTC (permalink / raw)
To: linuxppc-dev, linux-pci, linasvepstas, benh, Paul Mackerras; +Cc: Richard Lary
In-Reply-To: <4A722121.4010307@us.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 772 bytes --]
This is the third of three patches that implement a bit field that PCI Express device drivers can use to indicate they need a fundamental reset during error recovery.
By default, the EEH framework on powerpc does what's known as a "hot reset" during recovery of a PCI Express device. We've found a case where the device needs a "fundamental reset" to recover properly. The current PCI error recovery and EEH frameworks do not support this distinction.
The attached patch makes changes to EEH to utilize the new bit field.
These patches supersede the previously submitted patch that implemented a fundamental reset bit field.
Please review and let me know of any concerns.
Signed-off-by: Mike Mason <mmlnx@us.ibm.com>
Signed-off-by: Richard Lary <rlary@us.ibm.com>
[-- Attachment #2: eeh_fundamental_reset.patch --]
[-- Type: text/plain, Size: 1360 bytes --]
diff -uNrp a/arch/powerpc/kernel/pci_64.c b/arch/powerpc/kernel/pci_64.c
--- a/arch/powerpc/kernel/pci_64.c 2009-07-13 14:25:24.000000000 -0700
+++ b/arch/powerpc/kernel/pci_64.c 2009-07-15 10:26:26.000000000 -0700
@@ -143,6 +143,7 @@ struct pci_dev *of_create_pci_dev(struct
dev->dev.bus = &pci_bus_type;
dev->devfn = devfn;
dev->multifunction = 0; /* maybe a lie? */
+ dev->needs_freset = 0; /* pcie fundamental reset required */
dev->vendor = get_int_prop(node, "vendor-id", 0xffff);
dev->device = get_int_prop(node, "device-id", 0xffff);
diff -uNrp a/arch/powerpc/platforms/pseries/eeh.c b/arch/powerpc/platforms/pseries/eeh.c
--- a/arch/powerpc/platforms/pseries/eeh.c 2009-06-09 20:05:27.000000000 -0700
+++ b/arch/powerpc/platforms/pseries/eeh.c 2009-07-15 10:29:04.000000000 -0700
@@ -744,7 +744,15 @@ int pcibios_set_pcie_reset_state(struct
static void __rtas_set_slot_reset(struct pci_dn *pdn)
{
- rtas_pci_slot_reset (pdn, 1);
+ struct pci_dev *dev = pdn->pcidev;
+
+ /* Determine type of EEH reset required by device,
+ * default hot reset or fundamental reset
+ */
+ if (dev->needs_freset)
+ rtas_pci_slot_reset(pdn, 3);
+ else
+ rtas_pci_slot_reset(pdn, 1);
/* The PCI bus requires that the reset be held high for at least
* a 100 milliseconds. We wait a bit longer 'just in case'. */
^ permalink raw reply
* [PATCH 2/3] Support for PCI Express reset type
From: Mike Mason @ 2009-07-30 22:39 UTC (permalink / raw)
To: linuxppc-dev, linux-pci, linasvepstas, benh, Paul Mackerras; +Cc: Richard Lary
[-- Attachment #1: Type: text/plain, Size: 860 bytes --]
This is the second of three patches that implement a bit field that PCI Express device drivers can use to indicate they need a fundamental reset during error recovery.
By default, the EEH framework on powerpc does what's known as a "hot reset" during recovery of a PCI Express device. We've found a case where the device needs a "fundamental reset" to recover properly. The current PCI error recovery and EEH frameworks do not support this distinction.
The attached patch updates the Documentation/PCI/pci-error-recovery.txt file with changes related to this new bit field, as well a few unrelated updates.
These patches supersede the previously submitted patch that implemented a fundamental reset bit field.
Please review and let me know of any concerns.
Signed-off-by: Mike Mason <mmlnx@us.ibm.com>
Signed-off-by: Richard Lary <rlary@us.ibm.com>
[-- Attachment #2: doc-pci-error-recovery.txt.patch --]
[-- Type: text/plain, Size: 11408 bytes --]
--- a/Documentation/PCI/pci-error-recovery.txt 2009-06-09 20:05:27.000000000 -0700
+++ b/Documentation/PCI/pci-error-recovery.txt 2009-07-30 13:57:15.000000000 -0700
@@ -4,15 +4,17 @@
February 2, 2006
Current document maintainer:
- Linas Vepstas <linas@austin.ibm.com>
+ Linas Vepstas <linasvepstas@gmail.com>
+ updated by Richard Lary <rlary@us.ibm.com>
+ and Mike Mason <mmlnx@us.ibm.com> on 27-Jul-2009
Many PCI bus controllers are able to detect a variety of hardware
PCI errors on the bus, such as parity errors on the data and address
busses, as well as SERR and PERR errors. Some of the more advanced
chipsets are able to deal with these errors; these include PCI-E chipsets,
-and the PCI-host bridges found on IBM Power4 and Power5-based pSeries
-boxes. A typical action taken is to disconnect the affected device,
+and the PCI-host bridges found on IBM Power4, Power5 and Power6-based
+pSeries boxes. A typical action taken is to disconnect the affected device,
halting all I/O to it. The goal of a disconnection is to avoid system
corruption; for example, to halt system memory corruption due to DMA's
to "wild" addresses. Typically, a reconnection mechanism is also
@@ -37,10 +39,11 @@ is forced by the need to handle multi-fu
devices that have multiple device drivers associated with them.
In the first stage, each driver is allowed to indicate what type
of reset it desires, the choices being a simple re-enabling of I/O
-or requesting a hard reset (a full electrical #RST of the PCI card).
-If any driver requests a full reset, that is what will be done.
+or requesting a slot reset.
-After a full reset and/or a re-enabling of I/O, all drivers are
+If any driver requests a slot reset, that is what will be done.
+
+After a reset and/or a re-enabling of I/O, all drivers are
again notified, so that they may then perform any device setup/config
that may be required. After these have all completed, a final
"resume normal operations" event is sent out.
@@ -101,7 +104,7 @@ if it implements any, it must implement
is not implemented, the corresponding feature is considered unsupported.
For example, if mmio_enabled() and resume() aren't there, then it
is assumed that the driver is not doing any direct recovery and requires
-a reset. If link_reset() is not implemented, the card is assumed as
+a slot reset. If link_reset() is not implemented, the card is assumed to
not care about link resets. Typically a driver will want to know about
a slot_reset().
@@ -111,7 +114,7 @@ sequence described below.
STEP 0: Error Event
-------------------
-PCI bus error is detect by the PCI hardware. On powerpc, the slot
+A PCI bus error is detected by the PCI hardware. On powerpc, the slot
is isolated, in that all I/O is blocked: all reads return 0xffffffff,
all writes are ignored.
@@ -139,7 +142,7 @@ The driver must return one of the follow
a chance to extract some diagnostic information (see
mmio_enable, below).
- PCI_ERS_RESULT_NEED_RESET:
- Driver returns this if it can't recover without a hard
+ Driver returns this if it can't recover without a
slot reset.
- PCI_ERS_RESULT_DISCONNECT:
Driver returns this if it doesn't want to recover at all.
@@ -169,11 +172,11 @@ is STEP 6 (Permanent Failure).
>>> The current powerpc implementation doesn't much care if the device
>>> attempts I/O at this point, or not. I/O's will fail, returning
->>> a value of 0xff on read, and writes will be dropped. If the device
->>> driver attempts more than 10K I/O's to a frozen adapter, it will
->>> assume that the device driver has gone into an infinite loop, and
->>> it will panic the kernel. There doesn't seem to be any other
->>> way of stopping a device driver that insists on spinning on I/O.
+>>> a value of 0xff on read, and writes will be dropped. If more than
+>>> EEH_MAX_FAILS I/O's are attempted to a frozen adapter, EEH
+>>> assumes that the device driver has gone into an infinite loop
+>>> and prints an error to syslog. A reboot is then required to
+>>> get the device working again.
STEP 2: MMIO Enabled
-------------------
@@ -182,15 +185,14 @@ DMA), and then calls the mmio_enabled()
device drivers.
This is the "early recovery" call. IOs are allowed again, but DMA is
-not (hrm... to be discussed, I prefer not), with some restrictions. This
-is NOT a callback for the driver to start operations again, only to
-peek/poke at the device, extract diagnostic information, if any, and
-eventually do things like trigger a device local reset or some such,
-but not restart operations. This is callback is made if all drivers on
-a segment agree that they can try to recover and if no automatic link reset
-was performed by the HW. If the platform can't just re-enable IOs without
-a slot reset or a link reset, it wont call this callback, and instead
-will have gone directly to STEP 3 (Link Reset) or STEP 4 (Slot Reset)
+not, with some restrictions. This is NOT a callback for the driver to
+start operations again, only to peek/poke at the device, extract diagnostic
+information, if any, and eventually do things like trigger a device local
+reset or some such, but not restart operations. This callback is made if
+all drivers on a segment agree that they can try to recover and if no automatic
+link reset was performed by the HW. If the platform can't just re-enable IOs
+without a slot reset or a link reset, it will not call this callback, and
+instead will have gone directly to STEP 3 (Link Reset) or STEP 4 (Slot Reset)
>>> The following is proposed; no platform implements this yet:
>>> Proposal: All I/O's should be done _synchronously_ from within
@@ -228,9 +230,6 @@ proceeds to either STEP3 (Link Reset) or
If any driver returned PCI_ERS_RESULT_NEED_RESET, then the platform
proceeds to STEP 4 (Slot Reset)
->>> The current powerpc implementation does not implement this callback.
-
-
STEP 3: Link Reset
------------------
The platform resets the link, and then calls the link_reset() callback
@@ -253,16 +252,33 @@ The platform then proceeds to either STE
>>> The current powerpc implementation does not implement this callback.
-
STEP 4: Slot Reset
------------------
-The platform performs a soft or hard reset of the device, and then
-calls the slot_reset() callback.
-A soft reset consists of asserting the adapter #RST line and then
+In response to a return value of PCI_ERS_RESULT_NEED_RESET, the
+the platform will peform a slot reset on the requesting PCI device(s).
+The actual steps taken by a platform to perform a slot reset
+will be platform-dependent. Upon completion of slot reset, the
+platform will call the device slot_reset() callback.
+
+Powerpc platforms implement two levels of slot reset:
+soft reset(default) and fundamental(optional) reset.
+
+Powerpc soft reset consists of asserting the adapter #RST line and then
restoring the PCI BAR's and PCI configuration header to a state
that is equivalent to what it would be after a fresh system
power-on followed by power-on BIOS/system firmware initialization.
+Soft reset is also known as hot-reset.
+
+Powerpc fundamental reset is supported by PCI Express cards only
+and results in device's state machines, hardware logic, port states and
+configuration registers to initialize to their default conditions.
+
+For most PCI devices, a soft reset will be sufficient for recovery.
+Optional fundamental reset is provided to support a limited number
+of PCI Express PCI devices for which a soft reset is not sufficient
+for recovery.
+
If the platform supports PCI hotplug, then the reset might be
performed by toggling the slot electrical power off/on.
@@ -274,10 +290,12 @@ may result in hung devices, kernel panic
This call gives drivers the chance to re-initialize the hardware
(re-download firmware, etc.). At this point, the driver may assume
-that he card is in a fresh state and is fully functional. In
-particular, interrupt generation should work normally.
+that the card is in a fresh state and is fully functional. The slot
+is unfrozen and the driver has full access to PCI config space,
+memory mapped I/O space and DMA. Interrupts (Legacy, MSI, or MSI-X)
+will also be available.
-Drivers should not yet restart normal I/O processing operations
+Drivers should not restart normal I/O processing operations
at this point. If all device drivers report success on this
callback, the platform will call resume() to complete the sequence,
and let the driver restart normal I/O processing.
@@ -302,11 +320,21 @@ driver performs device init only from PC
- PCI_ERS_RESULT_DISCONNECT
Same as above.
+Drivers for PCI Express cards that require a fundamental reset must
+set the needs_freset bit in the pci_dev structure in their probe function.
+For example, the QLogic qla2xxx driver sets the needs_freset bit for certain
+PCI card types:
+
++ /* Set EEH reset type to fundamental if required by hba */
++ if (IS_QLA24XX(ha) || IS_QLA25XX(ha) || IS_QLA81XX(ha))
++ pdev->needs_freset = 1;
++
+
Platform proceeds either to STEP 5 (Resume Operations) or STEP 6 (Permanent
Failure).
->>> The current powerpc implementation does not currently try a
->>> power-cycle reset if the driver returned PCI_ERS_RESULT_DISCONNECT.
+>>> The current powerpc implementation does not try a power-cycle
+>>> reset if the driver returned PCI_ERS_RESULT_DISCONNECT.
>>> However, it probably should.
@@ -348,7 +376,7 @@ software errors.
Conclusion; General Remarks
---------------------------
-The way those callbacks are called is platform policy. A platform with
+The way the callbacks are called is platform policy. A platform with
no slot reset capability may want to just "ignore" drivers that can't
recover (disconnect them) and try to let other cards on the same segment
recover. Keep in mind that in most real life cases, though, there will
@@ -361,8 +389,8 @@ That is, the recovery API only requires
- There is no guarantee that interrupt delivery can proceed from any
device on the segment starting from the error detection and until the
-resume callback is sent, at which point interrupts are expected to be
-fully operational.
+slot_reset callback is called, at which point interrupts are expected
+to be fully operational.
- There is no guarantee that interrupt delivery is stopped, that is,
a driver that gets an interrupt after detecting an error, or that detects
@@ -381,16 +409,23 @@ anyway :)
>>> Implementation details for the powerpc platform are discussed in
>>> the file Documentation/powerpc/eeh-pci-error-recovery.txt
->>> As of this writing, there are six device drivers with patches
->>> implementing error recovery. Not all of these patches are in
+>>> As of this writing, there is a growing list of device drivers with
+>>> patches implementing error recovery. Not all of these patches are in
>>> mainline yet. These may be used as "examples":
>>>
->>> drivers/scsi/ipr.c
->>> drivers/scsi/sym53cxx_2
+>>> drivers/scsi/ipr
+>>> drivers/scsi/sym53c8xx_2
+>>> drivers/scsi/qla2xxx
+>>> drivers/scsi/lpfc
+>>> drivers/next/bnx2.c
>>> drivers/next/e100.c
>>> drivers/net/e1000
+>>> drivers/net/e1000e
>>> drivers/net/ixgb
+>>> drivers/net/ixgbe
+>>> drivers/net/cxgb3
>>> drivers/net/s2io.c
+>>> drivers/net/qlge
The End
-------
^ permalink raw reply
* [PATCH 1/3] Support for PCI Express reset type
From: Mike Mason @ 2009-07-30 22:33 UTC (permalink / raw)
To: linuxppc-dev, linux-pci, linasvepstas, benh, Paul Mackerras; +Cc: Richard Lary
[-- Attachment #1: Type: text/plain, Size: 859 bytes --]
This is the first of three patches that implement a bit field that PCI Express device drivers can use to indicate they need a fundamental reset during error recovery.
By default, the EEH framework on powerpc does what's known as a "hot reset" during recovery of a PCI Express device. We've found a case where the device needs a "fundamental reset" to recover properly. The current PCI error recovery and EEH frameworks do not support this distinction.
The attached patch (courtesy of Richard Lary) adds a bit field to pci_dev that indicates whether the device requires a fundamental reset during recovery.
These patches supersede the previously submitted patch that implemented a fundamental reset bit field.
Please review and let me know of any concerns.
Signed-off-by: Mike Mason <mmlnx@us.ibm.com>
Signed-off-by: Richard Lary <rlary@us.ibm.com>
[-- Attachment #2: pci_fundamental_reset.patch --]
[-- Type: text/plain, Size: 490 bytes --]
diff -uNrp a/include/linux/pci.h b/include/linux/pci.h
--- a/include/linux/pci.h 2009-07-13 14:25:37.000000000 -0700
+++ b/include/linux/pci.h 2009-07-15 10:25:37.000000000 -0700
@@ -273,6 +273,7 @@ struct pci_dev {
unsigned int ari_enabled:1; /* ARI forwarding */
unsigned int is_managed:1;
unsigned int is_pcie:1;
+ unsigned int needs_freset:1; /* Dev requires fundamental reset */
unsigned int state_saved:1;
unsigned int is_physfn:1;
unsigned int is_virtfn:1;
^ permalink raw reply
* Re: [PATCH] gianfar: fix coalescing setup in ethtool support
From: David Miller @ 2009-07-30 21:21 UTC (permalink / raw)
To: leoli; +Cc: netdev, b06378, linuxppc-dev
In-Reply-To: <1248857517-8270-1-git-send-email-leoli@freescale.com>
From: Li Yang <leoli@freescale.com>
Date: Wed, 29 Jul 2009 16:51:57 +0800
> Parameter order for using mk_ic_value(count, time) was reversed,
> the patch fixes this.
>
> Signed-off-by: Jiajun Wu <b06378@freescale.com>
> Signed-off-by: Li Yang <leoli@freescale.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] Add support for the ESTeem 195E (PPC405EP) SBC
From: Josh Boyer @ 2009-07-30 20:08 UTC (permalink / raw)
To: Solomon Peachy; +Cc: linuxppc-dev
In-Reply-To: <20090730194506.GA30066@linux-wlan.com>
On Thu, Jul 30, 2009 at 03:45:06PM -0400, Solomon Peachy wrote:
>On Thu, Jul 30, 2009 at 10:06:30AM -0400, Josh Boyer wrote:
>> >+ devp = finddevice("/plb/opb/serial@ef600300");
>> >+ if (!devp)
>> >+ fatal("Can't find node for /plb/opb/serial@ef600300");
>> >+ del_node(devp);
>>
>> Slightly confused here. You delete the first serial node in the single eth
>> case?
>
>The board is actually single eth/serial or dual eth/serial. And strictly
>speaking, this serial port is the second one in the devicetree...
Maybe a brief comment in the code explaining that would help. Also, I did
notice the DTS had them in the order you mention, and I forgot to come back
and correct my question there.
>> >+
>> >+ devp = finddevice("/plb/opb/ethernet@ef600900");
>> >+ if (!devp)
>> >+ fatal("Can't find node for /plb/opb/ethernet@ef600900");
>> >+ del_node(devp);
>> >+ }
>> >+
>> >+ ibm4xx_quiesce_eth((u32 *)0xef600800, (u32 *)0xef600900);
>>
>> Shouldn't you do the quiesce conditionally if the other eth port doesn't
>> exist?
>
>I don't know if this is strictly necessary with the modern ibm_emac
>driver, but it's certainly safe to call because all 405EPs have dual
>ethernet controllers.
>
>From the (pre-dts) driver perspecive, the only way to tell if the
>hotfoot had one ethernet port or two was that the second PHY failed to
>initialize.
>
>Additionally, the production bootloader (u-boot 1.2.0.x) isn't terribly
>smart and tries to drive the second controller if the first one doesn't
>have a cable plugged in, so it's possible the second controller is
>running when control is handed over to Linux, even on single ethernet
>boards.
OK, that makes sense.
>
>> >+ UART0: serial@ef600400 {
>> >+ device_type = "serial";
>> >+ compatible = "ns16550";
>> >+ reg = <0xef600400 0x00000008>;
>> >+ virtual-reg = <0xef600400>;
>> >+ clock-frequency = <0>; /* Filled in by zImage */
>> >+ current-speed = <0x9600>;
>>
>> Just a question, but is the baud supposed to be 38400 or 9600? At first glance
>> it almost seems like a typo :).
>
>It's supposed to be 38400 baud, hence the explicit 0x in front. (I lost
>count of the number of times I saw '38400' listed in various dts
>files...)
Cool. Just checking.
>> >+ gpio-leds {
>> >+ compatible = "gpio-leds";
>> >+ status {
>> >+ label = "Status";
>> >+ gpios = <&GPIO 1 0>;
>> >+ /* linux,default=trigger = ".."; */
>> >+ };
>>
>> What does that comment mean?
>
>Whoops, it's supposed to read 'linux,default-trigger', but the LEDs are
>manually twiddled for the time being. I'd forgotten to strip that out.
>
>(see linux/Documentation/powerpc/dts-bindings/gpio/led.txt)
OK. If it's not needed just yank it.
>
>> Ok. So I'm not really all that thrilled with changes to ppcboot.h.
>> We try to keep this file as much in-sync with U-Boot as we can. Did
>> your HOTFOOT changes get pulled into upstream U-Boot?
>
>Yeah, I thought this may be a problem, but I didn't know a better way to
>go about this and still maintain compatibility with the many thousands
>of boards already in the field. I mean, I could strip out the ppcboot.h
>changes and maintain that as an out-of-tree patch, but without that
>patch, the kernel won't boot on in-the-field boards, rendering the
>upstreaming of support for this board kinda pointless.
>
>I haven't tried to push anything to upstream u-boot, given how ancient
>the in-production bootloader is. The guy who originally mangled u-boot
>for this board did so before the "standard" 405EP dual ethernet layout
>was added, and never tried to push it upstream. Any upstream uboot work
>will take the form of a native dts/fdt port that probably won't use
>ppcboot.h anyway, which brings us full circle...
There is another way. Perhaps you could just copy ppcboot.h to a new file
called "hotfoot.h" and just use that. It's a duplication of ppcboot.h to
some degree, but it seems to make sense for your board and it helps preserve
the "stock" ppcboot.h for other boards.
josh
^ permalink raw reply
* Re: [PATCH] Add support for the ESTeem 195E (PPC405EP) SBC
From: Solomon Peachy @ 2009-07-30 19:45 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20090730140630.GD10244@zod.rchland.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 3996 bytes --]
On Thu, Jul 30, 2009 at 10:06:30AM -0400, Josh Boyer wrote:
> >+ devp = finddevice("/plb/opb/serial@ef600300");
> >+ if (!devp)
> >+ fatal("Can't find node for /plb/opb/serial@ef600300");
> >+ del_node(devp);
>
> Slightly confused here. You delete the first serial node in the single eth
> case?
The board is actually single eth/serial or dual eth/serial. And strictly
speaking, this serial port is the second one in the devicetree...
(The PPC405EP's serial boards aren't created equally; the first is a
dumb tx/rx-only port while the second has a full set of signals.
The hotfoot is wired such that the second, full-featured port is the
primary/console/boot port)
> >+
> >+ devp = finddevice("/plb/opb/ethernet@ef600900");
> >+ if (!devp)
> >+ fatal("Can't find node for /plb/opb/ethernet@ef600900");
> >+ del_node(devp);
> >+ }
> >+
> >+ ibm4xx_quiesce_eth((u32 *)0xef600800, (u32 *)0xef600900);
>
> Shouldn't you do the quiesce conditionally if the other eth port doesn't
> exist?
I don't know if this is strictly necessary with the modern ibm_emac
driver, but it's certainly safe to call because all 405EPs have dual
ethernet controllers.
From the (pre-dts) driver perspecive, the only way to tell if the
hotfoot had one ethernet port or two was that the second PHY failed to
initialize.
Additionally, the production bootloader (u-boot 1.2.0.x) isn't terribly
smart and tries to drive the second controller if the first one doesn't
have a cable plugged in, so it's possible the second controller is
running when control is handed over to Linux, even on single ethernet
boards.
> >+ UART0: serial@ef600400 {
> >+ device_type = "serial";
> >+ compatible = "ns16550";
> >+ reg = <0xef600400 0x00000008>;
> >+ virtual-reg = <0xef600400>;
> >+ clock-frequency = <0>; /* Filled in by zImage */
> >+ current-speed = <0x9600>;
>
> Just a question, but is the baud supposed to be 38400 or 9600? At first glance
> it almost seems like a typo :).
It's supposed to be 38400 baud, hence the explicit 0x in front. (I lost
count of the number of times I saw '38400' listed in various dts
files...)
> >+ gpio-leds {
> >+ compatible = "gpio-leds";
> >+ status {
> >+ label = "Status";
> >+ gpios = <&GPIO 1 0>;
> >+ /* linux,default=trigger = ".."; */
> >+ };
>
> What does that comment mean?
Whoops, it's supposed to read 'linux,default-trigger', but the LEDs are
manually twiddled for the time being. I'd forgotten to strip that out.
(see linux/Documentation/powerpc/dts-bindings/gpio/led.txt)
> Ok. So I'm not really all that thrilled with changes to ppcboot.h.
> We try to keep this file as much in-sync with U-Boot as we can. Did
> your HOTFOOT changes get pulled into upstream U-Boot?
Yeah, I thought this may be a problem, but I didn't know a better way to
go about this and still maintain compatibility with the many thousands
of boards already in the field. I mean, I could strip out the ppcboot.h
changes and maintain that as an out-of-tree patch, but without that
patch, the kernel won't boot on in-the-field boards, rendering the
upstreaming of support for this board kinda pointless.
I haven't tried to push anything to upstream u-boot, given how ancient
the in-production bootloader is. The guy who originally mangled u-boot
for this board did so before the "standard" 405EP dual ethernet layout
was added, and never tried to push it upstream. Any upstream uboot work
will take the form of a native dts/fdt port that probably won't use
ppcboot.h anyway, which brings us full circle...
- Solomon
--
Solomon Peachy solomon@linux-wlan.com
AbsoluteValue Systems http://www.linux-wlan.com
721-D North Drive +1 (321) 259-0737 (office)
Melbourne, FL 32934 +1 (321) 259-0286 (fax)
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: fsldma patches?
From: Dan Williams @ 2009-07-30 17:41 UTC (permalink / raw)
To: Kumar Gala; +Cc: Linuxppc-dev Development, Ira W. Snyder
In-Reply-To: <97CDF92A-2FAF-445D-B5B0-1D06884F8259@freescale.com>
Kumar Gala wrote:
> Dan,
>
> What happened with the set of patches that Ira posted for fsldma?
I have just sent a pull request with the pending backlog of dmaengine
fixes. Our discussion of the fsldma slave implementation did not
conclude in time for me to get a pull request out before the close of
the 2.6.31 merge window. I have queued it up for 2.6.32.
--
Dan
^ permalink raw reply
* Re: can the kernel show user task stack backtrace ?
From: Nicholas Mc Guire @ 2009-07-30 16:55 UTC (permalink / raw)
To: Alessandro Rubini; +Cc: linuxppc-dev, nvbolhuis
In-Reply-To: <20090730161941.GA14988@mail.gnudd.com>
On Thu, 30 Jul 2009, Alessandro Rubini wrote:
> > We're dealing with some complex (3rd party) applications and I like to see a
> > user task stack backtrace.
> >
> > (Of course the way to go here is to use a debugger (gdb) and
> > do a backtrace (with the coredump file).
>
> Actually, you can intercept SIGSEGV and print your own stack from within
> the signal handler. You can also open /proc/self/maps and print it, to
> ease understanding the various pointers in there, especially if the
> application is using a number of shared libs.
>
> This is usually easier than getting to a core dump, although there is
> less information than what the core offers.
>
> I have the code for ARM and I've it on ppc once, but I must dig for the actual
> code.
>
I think libSegFault.so (part of glibc) can do that by simply preloading it
LD_PRELOAD=/lib/libSegFault.so ./your_segfaulting_app
should do the trick.
hofrat
^ permalink raw reply
* Re: can the kernel show user task stack backtrace ?
From: Alessandro Rubini @ 2009-07-30 16:19 UTC (permalink / raw)
To: nvbolhuis; +Cc: linuxppc-dev
In-Reply-To: <4A71C04E.6060506@aimvalley.nl>
> We're dealing with some complex (3rd party) applications and I like to see a
> user task stack backtrace.
>
> (Of course the way to go here is to use a debugger (gdb) and
> do a backtrace (with the coredump file).
Actually, you can intercept SIGSEGV and print your own stack from within
the signal handler. You can also open /proc/self/maps and print it, to
ease understanding the various pointers in there, especially if the
application is using a number of shared libs.
This is usually easier than getting to a core dump, although there is
less information than what the core offers.
I have the code for ARM and I've it on ppc once, but I must dig for the actual
code.
/alessandro
^ permalink raw reply
* [PATCH] powerpc: missing tests after ioremap()?
From: Roel Kluin @ 2009-07-30 16:02 UTC (permalink / raw)
To: benh, linuxppc-dev, Andrew Morton
Missing tests after ioremap()
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
Shouldn't we test whether ioremaps fail?
diff --git a/arch/powerpc/platforms/powermac/feature.c b/arch/powerpc/platforms/powermac/feature.c
index e6c0040..3a4ebd3 100644
--- a/arch/powerpc/platforms/powermac/feature.c
+++ b/arch/powerpc/platforms/powermac/feature.c
@@ -2589,9 +2589,16 @@ static void __init probe_uninorth(void)
if (address == 0)
return;
uninorth_base = ioremap(address, 0x40000);
+ if (uninorth_base == NULL)
+ return;
uninorth_rev = in_be32(UN_REG(UNI_N_VERSION));
- if (uninorth_maj == 3 || uninorth_maj == 4)
+ if (uninorth_maj == 3 || uninorth_maj == 4) {
u3_ht_base = ioremap(address + U3_HT_CONFIG_BASE, 0x1000);
+ if (u3_ht_base == NULL) {
+ iounmap(uninorth_base);
+ return;
+ }
+ }
printk(KERN_INFO "Found %s memory controller & host bridge"
" @ 0x%08x revision: 0x%02x\n", uninorth_maj == 3 ? "U3" :
^ permalink raw reply related
* can the kernel show user task stack backtrace ?
From: Norbert van Bolhuis @ 2009-07-30 15:46 UTC (permalink / raw)
To: linuxppc-dev
Afaik the kernel only shows the stack backtrace of the kernel stack
(of a task).
I wonder if there would be anything wrong with letting it show
the user task stack backtrace in certain cases.
Read the rest to see what I mean.
If kernel.print-fatal-signals has been enabled a crashing
application makes the kernel show this:
ca2/943: potentially unexpected fatal signal 11.
NIP: 1000044c LR: 10000444 CTR: 00000000
REGS: ce73df50 TRAP: 0300 Not tainted (2.6.28)
MSR: 0000d032 <EE,PR,ME,IR,DR> CR: 22000422 XER: 20000000
DAR: d0000003, DSISR: 22000000
TASK = ceb7a3e0[943] 'ca2' THREAD: ce73c000
GPR00: 0000000e bf963b30 48025450 0000000a 0ff0ac2c 22000422 00000001 0ff5e6b0
GPR08: 00000001 d0000003 00001032 00000000 ffffffff 1001896c 0ffe9000 00000000
GPR16: 0ffca59c 00000000 1009b940 100a8b6a 100bf234 bfea22b8 100bf224 00000000
GPR24: 100bf008 1009b960 4801e858 4802dd34 4802e7e0 00000000 0ffec8d8 bf963b30
Call Trace:
Segmentation fault
#
It's a real pity the user task stack backtrace isn't shown.
We're dealing with some complex (3rd party) applications and I like to see a
user task stack backtrace.
(Of course the way to go here is to use a debugger (gdb) and
do a backtrace (with the coredump file).
However, debugging takes some time. Besides the info is there
it only needs to be shown. Often just this info is enough to
pinpoint the problem)
Obviously the arch/powerpc/kernel/process.c:show_stack function
isn't meant for doing this. It only shows the kernel stack.
Btw. this doesn't work in my case since validate_sp returns 0 (because
sp is assigned the user-space stack (bf963b30) while kernel stack starts at ce73c000).
Though if it would work it isn't very usefull I guess since the crashing app
not enters kernel-mode (via sys-calls).
If I change arch/powerpc/kernel/process.c:show_stack (of kernel 2.6.28) like this:
do {
#if 0
if (!validate_sp(sp, tsk, STACK_FRAME_OVERHEAD))
return;
#endif
.
.
.
} while ((count++ < kstack_depth_to_print) && (sp != 0));
the following is shown:
ca2/943: potentially unexpected fatal signal 11.
NIP: 1000044c LR: 10000444 CTR: c001fd7c
REGS: ce73df50 TRAP: 0300 Not tainted (2.6.28)
MSR: 0000f932 <EE,PR,FP,ME,IR,DR> CR: 22000422 XER: 20000000
DAR: d0000003, DSISR: 22000000
TASK = cf09b340[943] 'ca2' THREAD: ce73c000
GPR00: 0000000e bfd65b30 48025450 0000000a 0ff0ac2c 22000422 00000001 0ff5e6b0
GPR08: 00000001 d0000003 00001032 00000000 ffffffff 1001896c 0ffe9000 00000000
GPR16: 0ffca59c 00000000 1009b940 100a8b6a 100bf234 bfb532b8 100bf224 00000000
GPR24: 100bf008 1009b960 4801e858 4802dd34 4802e7e0 00000000 0ffec8d8 bfd65b30
Call Trace:
[bfd65b30] [10000444] 0x10000444 (unreliable)
[bfd65b60] [10000490] 0x10000490
[bfd65b90] [100004cc] 0x100004cc
[bfd65ba0] [0feb39c8] 0xfeb39c8
[bfd65dd0] [0feb3ad4] 0xfeb3ad4
[bfd65de0] [00000000] 0x000000
Segmentation fault
#
which is what I want.
^ permalink raw reply
* Re: [PATCH 5/5] sound/aoa: Add kmalloc NULL tests
From: Johannes Berg @ 2009-07-30 14:17 UTC (permalink / raw)
To: Julia Lawall; +Cc: linuxppc-dev, alsa-devel, kernel-janitors, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0907301610550.8734@ask.diku.dk>
[-- Attachment #1: Type: text/plain, Size: 578 bytes --]
On Thu, 2009-07-30 at 16:11 +0200, Julia Lawall wrote:
> From: Julia Lawall <julia@diku.dk>
>
> Check that the result of kzalloc is not NULL before a dereference.
> irq_client = kzalloc(sizeof(struct pmf_irq_client),
> GFP_KERNEL);
> + if (!irq_client) {
> + err = -ENOMEM;
> + printk(KERN_ERR "snd-aoa: gpio layer failed to"
> + " register %s irq (%d)\n", name, err);
> + goto out_unlock;
> + }
Looks good, thanks, but I'd really drop the printk if only to not have
the string there, that doesn't really seem interesting.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Help, please... Multi-Media Distro for PPC?
From: skateaboard @ 2009-07-30 14:33 UTC (permalink / raw)
To: linuxppc-dev
Ok so I'm really new to this but a single line answer will do, like "One of
the best and noob friendly PPC Multi media distributors would be _________."
What I have:
A PPC ibook G3 laptop
What I need help with:
Finding a linux based multi-media workstation
Why:
I really want to become more savvy with linux and I need this element added
to my physical studio's repertoire. My artist studio needs a computer
workstation and linux seems the best way for me to go.
Specifically:
I've been searching around the web for a while now and have not yet found a
PPC optimized(or even kind-of) distro for a multi-media studio for PPC based
macs. I need some sort of:
-image, video, audio editing and layering software package.
So, Does this even exist? I've seen "Umbutu Studio"; that seems to do the
job, however I've read that it would not work with my hardware, true? or is
there a similar type package for PPC?
Thank you all so much and any input is much appreciated!
-Andrew
--
View this message in context: http://www.nabble.com/Help%2C-please...-Multi-Media-Distro-for-PPC--tp24628615p24628615.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 5/5] sound/aoa: Add kmalloc NULL tests
From: Julia Lawall @ 2009-07-30 14:29 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev, alsa-devel, kernel-janitors, linux-kernel
In-Reply-To: <1248963420.16129.0.camel@johannes.local>
On Thu, 30 Jul 2009, Johannes Berg wrote:
> On Thu, 2009-07-30 at 16:11 +0200, Julia Lawall wrote:
> > From: Julia Lawall <julia@diku.dk>
> >
> > Check that the result of kzalloc is not NULL before a dereference.
>
> > irq_client = kzalloc(sizeof(struct pmf_irq_client),
> > GFP_KERNEL);
> > + if (!irq_client) {
> > + err = -ENOMEM;
> > + printk(KERN_ERR "snd-aoa: gpio layer failed to"
> > + " register %s irq (%d)\n", name, err);
> > + goto out_unlock;
> > + }
>
> Looks good, thanks, but I'd really drop the printk if only to not have
> the string there, that doesn't really seem interesting.
The printk is based on similar error handling code a few lines later:
if (err) {
printk(KERN_ERR "snd-aoa: gpio layer failed to"
" register %s irq (%d)\n", name,
err);
kfree(irq_client);
goto out_unlock;
}
Should the printk be removed in this case as well? Or is it ok to fail
silently in one case and not in the other?
julia
^ permalink raw reply
* [PATCH 5/5] sound/aoa: Add kmalloc NULL tests
From: Julia Lawall @ 2009-07-30 14:11 UTC (permalink / raw)
To: johannes, linuxppc-dev, alsa-devel, linux-kernel, kernel-janitors
From: Julia Lawall <julia@diku.dk>
Check that the result of kzalloc is not NULL before a dereference.
The semantic match that finds this problem is as follows:
(http://www.emn.fr/x-info/coccinelle/)
// <smpl>
@@
expression *x;
identifier f;
constant char *C;
@@
x = \(kmalloc\|kcalloc\|kzalloc\)(...);
... when != x == NULL
when != x != NULL
when != (x || ...)
(
kfree(x)
|
f(...,C,...,x,...)
|
*f(...,x,...)
|
*x->f
)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
sound/aoa/core/gpio-pmf.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/sound/aoa/core/gpio-pmf.c b/sound/aoa/core/gpio-pmf.c
index 5ca2220..b4439ce 100644
--- a/sound/aoa/core/gpio-pmf.c
+++ b/sound/aoa/core/gpio-pmf.c
@@ -182,6 +182,12 @@ static int pmf_set_notify(struct gpio_runtime *rt,
if (!old && notify) {
irq_client = kzalloc(sizeof(struct pmf_irq_client),
GFP_KERNEL);
+ if (!irq_client) {
+ err = -ENOMEM;
+ printk(KERN_ERR "snd-aoa: gpio layer failed to"
+ " register %s irq (%d)\n", name, err);
+ goto out_unlock;
+ }
irq_client->data = notif;
irq_client->handler = pmf_handle_notify_irq;
irq_client->owner = THIS_MODULE;
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox