1
0
Fork 0
Commit Graph

7 Commits (84404d5fd5858588bbf694b0300dbc6310d02737)

Author SHA1 Message Date
Linus Torvalds 7c0f6ba682 Replace <asm/uaccess.h> with <linux/uaccess.h> globally
This was entirely automated, using the script by Al:

  PATT='^[[:blank:]]*#[[:blank:]]*include[[:blank:]]*<asm/uaccess.h>'
  sed -i -e "s!$PATT!#include <linux/uaccess.h>!" \
        $(git grep -l "$PATT"|grep -v ^include/linux/uaccess.h)

to do the replacement at the end of the merge window.

Requested-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-12-24 11:46:01 -08:00
Thomas Horsten 90a95af85f [SCSI] MegaRAID driver management char device moved to misc
The MegaRAID driver's common management module (megaraid_mm.c) creates a
char device used by the management tool "megarc" from LSI Logic (and
possibly other management tools).

In 2.6 with udev, this device doesn't get created because it is not
registered in sysfs.

I first fixed this by registering a class "megaraid_mm", but realized that
this should probably be moved to misc devices, instead of taking up a char
major.  This is because only 1 device is used, even if there are multiple
adapters - the minor is never used (the adapter info is in the ioctl block
sent to the driver, not detected based on the minor number as one might
think).  So it is a complete waste to have an entire major taken by this.

So it now uses a misc device which I named "megadev0" (the name that megarc
expects), and has a dynamic minor (previoulsy a dynamic major was used).

I have tested this on my own system with the megarc tool, and it works just
as fine as before (only now the device gets created correctly by udev).

Acked-by: "Patro, Sumant" <Sumant.Patro@lsi.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
2008-02-11 10:20:53 -06:00
Ju, Seokmann 0b4972d591 [SCSI] megaraid_{mm,mbox}: a fix on "kernel unaligned access address" issue
There was an issue in the data structure defined by megaraid driver
casuing "kernel unaligned access.." messages to be displayed during
IOCTL on IA64 platform.

The issue has been reported/fixed by Sakurai Hiroomi
[sakurai_hiro@soft.fujitsu.com].

Signed-Off By: Seokmann Ju <seokmann.ju@lsil.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2006-07-28 13:19:12 -05:00
Christoph Hellwig 7ff92053dd [PATCH] don't include ioctl32.h in drivers
These days ioctl32.h is only used for communication of fs/compat.c and
fs/compat_ioctl.c and doesn't contain anything of interest to drivers.

Remove inclusion in various drivers.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-10 08:01:34 -08:00
Olaf Hering 733482e445 [PATCH] changing CONFIG_LOCALVERSION rebuilds too much, for no good reason
This patch removes almost all inclusions of linux/version.h.  The 3
#defines are unused in most of the touched files.

A few drivers use the simple KERNEL_VERSION(a,b,c) macro, which is
unfortunatly in linux/version.h.

There are also lots of #ifdef for long obsolete kernels, this was not
touched.  In a few places, the linux/version.h include was move to where
the LINUX_VERSION_CODE was used.

quilt vi `find * -type f -name "*.[ch]"|xargs grep -El '(UTS_RELEASE|LINUX_VERSION_CODE|KERNEL_VERSION|linux/version.h)'|grep -Ev '(/(boot|coda|drm)/|~$)'`

search pattern:
/UTS_RELEASE\|LINUX_VERSION_CODE\|KERNEL_VERSION\|linux\/\(utsname\|version\).h

Signed-off-by: Olaf Hering <olh@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-09 07:55:57 -08:00
Ju, Seokmann 672b2d38da [SCSI] megaraid version 2.20.4.6
Signed-off by: Seokmann Ju <sju@lsil.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2005-05-20 15:47:59 -05: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