2
0
mirror of https://github.com/edk2-porting/linux-next.git synced 2024-12-21 03:33:59 +08:00
Commit Graph

3 Commits

Author SHA1 Message Date
Jesper Juhl
6044ec8882 [PATCH] kfree cleanup: misc remaining drivers
This is the remaining misc drivers/ part of the big kfree cleanup patch.

Remove pointless checks for NULL prior to calling kfree() in misc files in
drivers/.

Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
Acked-by: Aristeu Sergio Rozanski Filho <aris@cathedrallabs.org>
Acked-by: Roland Dreier <rolandd@cisco.com>
Acked-by: Pierre Ossman <drzeus@drzeus.cx>
Acked-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Acked-by: Len Brown <len.brown@intel.com>
Acked-by: "Antonino A. Daplas" <adaplas@gmail.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-07 07:54:05 -08:00
Christoph Hellwig
5b76ffd5d9 [PATCH] DAC960: add support for Mylex AcceleRAID 4/5/600
This patch adds support for a new class of DAC960 controllers.  It's based
on the GPLed idac320 driver from IBM for Linux 2.4.18.  That driver is a
fork of the 2.4.18 version of DAC960 that adds support for this new type of
controllers (internally called "GEM Series"), that differ from other DAC960
V2 firmware controllers only in the register offsets and removes support
for all others.

This patch instead integrates support for these controllers into the DAC960
driver.

Thanks to Anders Norrbring for pointing me to the idac320 driver and
testing this patch.

No Signed-Off: line because all code is either copy & pasted from IBM's
idac320 driver or support for other controllers in the 2.6 DAC960 driver.

Note: the really odd formating matches the rest of the DAC960 driver.

Cc: Dave Olien <dmo@osdl.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-05 16:36:43 -07:00
Linus Torvalds
1da177e4c3 Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
2005-04-16 15:20:36 -07:00