BMC/Intel-BMC/linux.git/scripts, branch v2.6.26-rc5

Merge git://git.kernel.org/pub/scm/linux/kernel/git/sam/kbuild-fixes

2008-06-02T22:26:02+00:00

* git://git.kernel.org/pub/scm/linux/kernel/git/sam/kbuild-fixes: kbuild: fix $(src) assignmnet with external modules

kbuild: fix $(src) assignmnet with external modules

2008-05-31T20:28:40+00:00

When we introduced support for KBUILD_EXTRA_SYMBOLS we started to include the externam module's kbuild file when doing the final modpost step. As external modules often do: ccflags-y := -I$(src) We had problems because $(src) was unassinged and gcc then used the next parameter for -I resulting in strange build failures. Fix is to assign $(src) and $(obj) when building external modules. This fixes: http://bugzilla.kernel.org/show_bug.cgi?id=10798 Signed-off-by: Sam Ravnborg Cc: Tvrtko Cc: Andrea Arcangeli Cc: "Rafael J. Wysocki"

Mark 'scripts/decodecode' executable

2008-05-30T21:02:21+00:00

.. because it is. Signed-off-by: Linus Torvalds

scripts/ver_linux use 'gcc -dumpversion'

2008-05-25T21:02:43+00:00

These magic greps and hacks in ver_linux to get the gcc version always break after some gcc releases. Since now gcc >4.3 allows compiling with '--with-pkgversion' ( which can be everything 'My Cool Gcc' or something ) ver_linux will report random junk for these. Simply use 'gcc -dumpversion' to get the gcc version which should always work. Signed-off-by: Gabriel C Signed-off-by: Andrew Morton Signed-off-by: Sam Ravnborg

kconfig: incorrect 'len' field initialisation ?

2008-05-19T18:14:49+00:00

1) The field 'len' of the 'gstr' structure seems to track the size of the memory already allocated for the "growable string". So the value of this field should be the same as the 'malloc()' just above, shouldn't it ? Signed-off-by: Christophe Jaillet Signed-off-by: Sam Ravnborg

kernel-doc: allow unnamed bit-fields

2008-05-19T18:12:40+00:00

Allow for unnamed bit-fields and skip them instead of printing an erroneous warning message for them, such as: Warning(include/asm-s390/cio.h:103): No description found for parameter 'u32' which contains: struct tm_scsw { u32 :1; Signed-off-by: Randy Dunlap Signed-off-by: Sam Ravnborg

kbuild: filter away debug symbols from kernel symbols

2008-05-19T18:07:58+00:00

Andi Kleen reported that he saw a lot of symbols like this: 0000000000000b24 N DW.aio.h.903a6d92.2 0000000000000bce N DW.task_io_accounting.h.8d8de327.0 0000000000000bec N DW.hrtimer.h.c23659c6.0 in his System.map / kallsyms output. Simple solution is to skip all debugging symbols (they are marked 'N'). Signed-off-by: Sam Ravnborg Cc: Paulo Marques

kbuild: disable modpost warnings for linkonce sections

2008-05-11T08:10:51+00:00

Disable modpost warnings for linkonce sections My build gives lots of warnings like WARNING: sound/core/snd.o (.gnu.linkonce.wi.mpspec_def.h.30779716): unexpected section name. The (.[number]+) following section name are ld generated and not expected. Did you forget to use "ax"/"aw" in a .S file? Note that for example contains section definitions for use in .S files. But for .linkonce. duplicated sections are actually ok and expected. So just disable the warning for this case. Signed-off-by: Andi Kleen Signed-off-by: Sam Ravnborg

kconfig: fix MAC OS X warnings in menuconfig

2008-05-04T19:03:20+00:00

Signed-off-by: Sam Ravnborg Acked-by: Timur Tabi

modpost: i2c aliases need no trailing wildcard

2008-05-04T07:24:47+00:00

Not all device types need a wildcard at the end of their module aliases. In particular, for i2c module aliases, the trailing wildcard is not only unneeded, it could also cause the wrong driver to be loaded. As I2C devices have no IDs, i2c module aliases are simple, arbitrary device names. For example: $ /sbin/modinfo lm90 filename: /lib/modules/2.6.25-git18/kernel/drivers/hwmon/lm90.ko author: Jean Delvare description: LM90/ADM1032 driver license: GPL vermagic: 2.6.25-git18 mod_unload depends: hwmon alias: i2c:lm90* alias: i2c:adm1032* alias: i2c:lm99* alias: i2c:lm86* alias: i2c:max6657* alias: i2c:adt7461* alias: i2c:max6680* $ This would cause trouble if one I2C chip name matches the beginning of another I2C chip name and both chips are supported by different drivers. For example, an i2c device named lm9042 would cause the lm90 driver to be loaded, while it doesn't support that device. This case has yet to be seen in practice, but still, I'd like to fix it now. The cleanest fix is to remove the trailing wildcard from i2c module aliases. Here's a patch doing this. Not all device type aliases need a trailing wildcard, in particular the i2c aliases don't. Don't add a wildcard by default in do_table(), instead let each device type handler add it if needed. I have tested types acpi, dmi, eisa, i2c, ide, ieee1394, input, pci, pcmcia, platform, pnp, scsi, serio, ssb and usb. Other types (ccw, of, vio, parisc, sdio and virtio) are untested. Signed-off-by: Jean Delvare Acked-by: Jochen Friedrich Signed-off-by: Sam Ravnborg