linux/scripts/mod, branch v2.6.28

kbuild: prevent modpost from looking for a .cmd file for a static library linked into a module

2008-10-29T21:02:10Z

This fixes a compile time warning which occurs whenever a static library is linked into a kernel module. MODPOST tries to look for a "..cmd" file to look for its dependencies, but that file doesn't exist or get generated for static libraries. This patch prevents modpost from looking for a .cmd file when a module is linked with a static library [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Ashutosh Naik Cc: Rusty Russell Signed-off-by: Andrew Morton Signed-off-by: Sam Ravnborg

Merge git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-2.6

2008-10-17T16:50:12Z

* git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-2.6: (25 commits) staging: at76_usb wireless driver Staging: workaround build system bug Staging: Lindent sxg.c Staging: SLICOSS: Call pci_release_regions at driver exit Staging: SLICOSS: Fix remaining type names Staging: SLICOSS: Fix warnings due to static usage Staging: SLICOSS: lots of checkpatch fixes Staging: go7007 v4l fixes Staging: Fix gcc warnings in sxg Staging: add echo cancelation module Staging: add wlan-ng prism2 usb driver Staging: add w35und wifi driver Staging: USB/IP: add host driver Staging: USB/IP: add client driver Staging: USB/IP: add common functions needed Staging: add the go7007 video driver Staging: add me4000 pci data collection driver Staging: add me4000 firmware files Staging: add sxg network driver Staging: add Alacritech slicoss network driver ... Fixed up conflicts due to taint flags changes and MAINTAINERS cleanup in MAINTAINERS, include/linux/kernel.h and kernel/panic.c.

modpost: add support for hid

2008-10-14T21:50:47Z

Generate aliases for hid device modules to support autoloading. Signed-off-by: Jiri Slaby Signed-off-by: Jiri Kosina

Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6

2008-10-13T16:13:56Z

Conflicts: include/asm-x86/statfs.h

Automatic MODULE_ALIAS() for DMI match tables.

2008-10-13T15:05:06Z

This makes modpost handle MODULE_DEVICE_TABLE(dmi, xxxx). I had to change the string pointers in the match table to char arrays, and picked a size of 79 bytes almost at random -- do we need to make it bigger than that? I was a bit concerned about the 'bloat' this introduces into the match tables, but they should all be __initdata so it shouldn't matter too much. (Actually, modpost does go through the relocations and look at most of them; it wouldn't be impossible to make it handle string pointers -- but doesn't seem to be worth the effort, since they're __initdata). Signed-off-by: David Woodhouse

Staging: add TAINT_CRAP flag to drivers/staging modules

2008-10-10T22:31:06Z

We need to add a flag for all code that is in the drivers/staging/ directory to prevent all other kernel developers from worrying about issues here, and to notify users that the drivers might not be as good as they are normally used to. Based on code from Andreas Gruenbacher and Jeff Mahoney to provide a TAINT flag for the support level of a kernel module in the Novell enterprise kernel release. This is the code that actually modifies the modules, adding the flag to any files in the drivers/staging directory. Cc: Andreas Gruenbacher Cc: Jeff Mahoney Signed-off-by: Greg Kroah-Hartman

Marker depmod fix core kernel list

2008-10-06T23:34:19Z

* Theodore Ts'o (tytso@mit.edu) wrote: > > I've been playing with adding some markers into ext4 to see if they > could be useful in solving some problems along with Systemtap. It > appears, though, that as of 2.6.27-rc8, markers defined in code which is > compiled directly into the kernel (i.e., not as modules) don't show up > in Module.markers: > > kvm_trace_entryexit arch/x86/kvm/kvm-intel %u %p %u %u %u %u %u %u > kvm_trace_handler arch/x86/kvm/kvm-intel %u %p %u %u %u %u %u %u > kvm_trace_entryexit arch/x86/kvm/kvm-amd %u %p %u %u %u %u %u %u > kvm_trace_handler arch/x86/kvm/kvm-amd %u %p %u %u %u %u %u %u > > (Note the lack of any of the kernel_sched_* markers, and the markers I > added for ext4_* and jbd2_* are missing as wel.) > > Systemtap apparently depends on in-kernel trace_mark being recorded in > Module.markers, and apparently it's been claimed that it used to be > there. Is this a bug in systemtap, or in how Module.markers is getting > built? And is there a file that contains the equivalent information > for markers located in non-modules code? I think the problem comes from "markers: fix duplicate modpost entry" (commit d35cb360c29956510b2fe1a953bd4968536f7216) Especially : - add_marker(mod, marker, fmt); + if (!mod->skip) + add_marker(mod, marker, fmt); } return; fail: Here is a fix that should take care if this problem. Thanks for the bug report! Signed-off-by: Mathieu Desnoyers Tested-by: "Theodore Ts'o" CC: Greg KH CC: David Smith CC: Roland McGrath CC: Sam Ravnborg CC: Wenji Huang CC: Takashi Nishiie Signed-off-by: Linus Torvalds

pnp: fix "add acpi:* modalias entries"

2008-08-21T17:15:39Z

With 22454cb99fc39f2629ad06a7eccb3df312f8830e we added only the first entry of the device table. We need to loop over the whole device list. Signed-off-by: Kay Sievers Signed-off-by: Greg Kroah-Hartman

scripts/mod/modpost.c: fix spelling of module and happens

2008-07-30T16:41:46Z

Spelling fixes in scripts/mod/modpost.c Signed-off-by: Ben Dooks Cc: Rusty Russell Cc: Sam Ravnborg Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

remove the v850 port

2008-07-24T17:47:24Z

Trying to compile the v850 port brings many compile errors, one of them exists since at least kernel 2.6.19. There also seems to be noone willing to bring this port back into a usable state. This patch therefore removes the v850 port. If anyone ever decides to revive the v850 port the code will still be available from older kernels, and it wouldn't be impossible for the port to reenter the kernel if it would become actively maintained again. Signed-off-by: Adrian Bunk Acked-by: Greg Ungerer Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds