perf: Build libtraceevent.a

Have building perf also build libtraceevent.a. Currently, perf does
not use the code within libtraceevent.a, but it soon will.

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Arun Sharma <asharma@fb.com>
Cc: Namhyung Kim <namhyung.kim@lge.com>
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
perf tools: Let O= makes handle relative paths

When I did a compile of perf using a relative path for the output
directory, the build failed when it tried to compile libtraceevent. This
is because it continues to use the same relative path when the new
working directory is in a different path.

    SUBDIR ../lib/traceevent/
/bin/sh: line 0: cd: ../../../nobackup/perf/: No such file or directory
Makefile:74: *** output directory "../../../nobackup/perf/" does not exist.  Stop.
make: *** [../../../nobackup/perf///libtraceevent.a] Error 2

Make the path used an absolute path when building perf with O=.

Boris:

Teach Makefile to check whether the supplied O= directory exists and
bail out if not. Reportedly, kernel dudes are idiots and need to be
guarded so as not to shoot themselves in the foot when playing in the
sandbox.

Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Acked-by: Steven Rostedt <rostedt@goodmis.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Namhyung Kim <namhyung.kim@lge.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20120815163923.GD15989@aftab.osrc.amd.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
tools: Add a toplevel Makefile

Add a Makefile with all the targets under tools/.

Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Michal Marek <mmarek@suse.cz>
Cc: Sam Ravnborg <sam@ravnborg.org>
Link: http://lkml.kernel.org/r/1334162178-17152-4-git-send-email-bp@amd64.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
tools: Add a help target

... and make it the default one so that calling 'make' without arguments
in the tools/ directory gives you the possible targets to build along
with a short description of what they are.

Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Michal Marek <mmarek@suse.cz>
Cc: Sam Ravnborg <sam@ravnborg.org>
Link: http://lkml.kernel.org/r/1334162178-17152-5-git-send-email-bp@amd64.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
tools: Connect to the kernel build system

Now you can do

$ make tools/<toolname>

from the toplevel kernel directory and have the respective tool built.

If you want to build and install it, do

$ make tools/<toolname>_install

$ make tools/<toolname>_clean

should clean the respective tool directories.

If you want to clean all in tools, simply do

$ make tools/clean

Also, if you want to get what the possible targets are, simply calling

$ make tools/

should give you the short help.

$ make tools/install

installs all tools, of course. Doh.

Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Michal Marek <mmarek@suse.cz>
Cc: Sam Ravnborg <sam@ravnborg.org>
Link: http://lkml.kernel.org/r/1334162178-17152-6-git-send-email-bp@amd64.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
tools: Define a Makefile function to do subdir processing

Define a Makefile function that can be called with $(call ...) to wrap
the subdir make invocations in tools/Makefile.

This will allow us in the next patch to insert bits in there to honour
O= flags when called from the top-level Makefile.

Signed-off-by: David Howells <dhowells@redhat.com>
Cc: Borislav Petkov <bp@amd64.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Namhyung Kim <namhyung@gmail.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1378.1352379110@warthog.procyon.org.uk
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
tools: Honour the O= flag when tool build called from a higher Makefile

Honour the O= flag that was passed to a higher level Makefile and then passed
down as part of a tool build.

To make this work, the top-level Makefile passes the original O= flag and
subdir=tools to the tools/Makefile, and that in turn passes
subdir=$(O)/$(subdir)/foodir when building tool foo in directory
$(O)/$(subdir)/foodir (where the intervening slashes aren't added if an
element is missing).

For example, take perf.  This is found in tools/perf/.  Assume we're building
into directory ~/zebra/, so we pass O=~/zebra to make.  Dependening on where
we run the build from, we see:

	make run in dir		$(OUTPUT) dir
	=======================	==================
	linux			~/zebra/tools/perf/
	linux/tools		~/zebra/perf/
	linux/tools/perf	~/zebra/

and if O= is not set, we get:

	make run in dir		$(OUTPUT) dir
	=======================	==================
	linux			linux/tools/perf/
	linux/tools		linux/tools/perf/
	linux/tools/perf	linux/tools/perf/

The output directories are created by the descend function if they don't
already exist.

Signed-off-by: David Howells <dhowells@redhat.com>
Cc: Borislav Petkov <bp@amd64.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Namhyung Kim <namhyung@gmail.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1378.1352379110@warthog.procyon.org.uk
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
kbuild: Remove reference to uninitialised variable

Verbose output variable is unnecessary because the command's echo is
already surpressed. Additionally because the block defines skip-makefile
the variable Q is not defined within the makefile, which can cause
problems if Q is defined in the users environment.

Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
kbuild: Do not remove vmlinux when cleaning external module

Since commit 1f2bfbd00e466ff3489b2ca5cc75b1cccd14c123 "kbuild:
link of vmlinux moved to a script" make clean with M=<dir>
argument (so cleaning external module) removes vmlinux,
System.map and couple of other files from the *main* kernel
build directory! This not what was happening before and almost
certainly not what one would expect.

This patch moves makes the clean target of the script called
only when !KBUILD_EXTMOD.

Signed-off-by: Pawel Moll <pawel.moll@arm.com>
Cc: stable@vger.kernel.org [v3.5+]
Signed-off-by: Michal Marek <mmarek@suse.cz>
MODSIGN: Add modules_sign make target

If CONFIG_MODULE_SIG is set, and 'make modules_sign' is called then this
patch will cause the modules to get a signature appended.  The make target
is intended to be run after 'make modules_install', and will modify the
modules in-place in the installed location.  It can be used to produce
signed modules after they have been processed by distribution build
scripts.

Signed-off-by: Josh Boyer <jwboyer@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (minor typo fix)
x86: Default to ARCH=x86 to avoid overriding CONFIG_64BIT

It is easy to waste a bunch of time when one takes a 32-bit .config
from a test machine and try to build it on a faster 64-bit system, and
its existing setting of CONFIG_64BIT=n gets *changed* to match the
build host.  Similarly, if one has an existing build tree it is easy
to trash an entire build tree that way.

This is because the default setting for $ARCH when discovered from
'uname' is one of the legacy pre-x86-merge values (i386 or x86_64),
which effectively force the setting of CONFIG_64BIT to match. We should
default to ARCH=x86 instead, finally completing the merge that we
started so long ago.

This patch preserves the behaviour of the legacy ARCH settings for commands
such as:

   make ARCH=x86_64 randconfig
   make ARCH=i386 randconfig

... since making the value of CONFIG_64BIT actually random in that situation
is not desirable.

In time, perhaps we can retire this legacy use of the old ARCH= values.
We already have a way to override values for *any* config option, using
$KCONFIG_ALLCONFIG, so it could be argued that we don't necessarily need
to keep ARCH={i386,x86_64} around as a special case just for overriding
CONFIG_64BIT.

We'd probably at least want to add a way to override config options from
the command line ('make CONFIG_FOO=y oldconfig') before we talk about doing
that though.

Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Link: http://lkml.kernel.org/r/1356040315.3198.51.camel@shinybook.infradead.org
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
arm64: makefile: fix uname munging when setting ARCH on native machine

By popular demand, arch/aarch64 is now known as arch/arm64. However,
uname -m (and indeed the GNU triplet) still use aarch64 as the machine
string.

This patch fixes native builds of both the kernel and perf tools by
updating the relevant Makefiles to munge the output of uname -m and
set the ARCH variable appropriately.

Cc: <stable@vger.kernel.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Staging: hv: Add struct hv_vmbus_device_id to mod_devicetable.h

In preparation for implementing vmbus aliases for auto-loading
Hyper-V drivers, define vmbus specific device ID.

Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Staging: hv: add driver_data to hv_vmbus_device_id

This is going to be needed by some drivers that handle more than one
device, like all other bus types do, so prepare for that in advance
before the user/kernel api is used.

Cc:  K. Y. Srinivasan <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
ARM: amba: Move definition of struct amba_id to mod_devicetable.h

The general kernel infrastructure for adding module alises during
module post processing expects the affected device type
identification structures in a common header
<linux/mod_devicetable.h>.

This patch simple moves struct amba_id to the common header, and
adds the appropriate include in <linux/amba/bus.h>.

Signed-off-by: Dave Martin <dave.martin@linaro.org>
Staging: hv: Add code to parse struct hv_vmbus_device_id table

Add code to parse struct hv_vmbus_device_id table.

Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Staging: hv: file2alias: fix up alias creation logic for hv_vmbus_device_id

When I added the driver_data field to hv_vmbus_device_id, I forgot to
take into the account how the alias was created, so it would append the
kernel pointer to the end of the alias, which is not correct.

This changes how the hv_vmbus_device_id alias is created to proper
account for the driver_data field.  As no module yet uses this alias, it
is safe to fix this up at this point in the commit stream.

Cc: K. Y. Srinivasan <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
ARM: amba: Auto-generate AMBA driver module aliases during modpost

This patch adds the necessary support in file2alias.c to define
suitable aliases based on the amba_id table in AMBA driver modules.

This should be sufficient to allow such modules to be auto-loaded
via udev.  The AMBA bus driver's uevent hotplug code is also
modified to pass an approriate MODALIAS string in the event.

For simplicity, the AMBA ID is treated an an opaque 32-bit numeber.
Module alises use patterns as appropriate to describe the value-
mask pairs described in the driver's amba_id list.

The proposed alias format is (extended regex):

    ^amba:d(HEX){8}$

Where HEX is a single upper-case HEX digit or a pattern (? or []
expression) matching a single upper-case HEX digit, as expected by
udev.

"d" is short for "device", following existing alias naming
conventions for other device types.  This adds some flexibility for
unambiguously extending the alias format in the future by adding
additional leading and trailing fields, if this turns out to be
necessary.

Signed-off-by: Dave Martin <dave.martin@linaro.org>
Acked-by: Pawel Moll <pawel.moll@arm.com>