rdmsr() takes the lower 32 bits as a second argument and the high 32 as
a third. Fix the names accordingly since they were swapped.

There should be no functionality change resulting from this patch.
Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
Signed-off-by: Dave Jones <davej@redhat.com>

This patch converts pci_table entries, where .subvendor=PCI_ANY_ID and
.subdevice=PCI_ANY_ID, .class=0 and .class_mask=0, to use the
PCI_VDEVICE macro, and thus improves readability.
Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Signed-off-by: Dave Jones <davej@redhat.com>

Use for_each_pci_dev() to simplify the code.
Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
Signed-off-by: Dave Jones <davej@redhat.com>

This patch fixes up a brace warning found by the checkpatch.pl tool
Signed-off-by: Neal Buckendahl <nealb001@tbcnet.com>
Signed-off-by: Dave Jones <davej@redhat.com>

and fix the broken case if a core's frequency depends on others.

trace_power_frequency was only implemented in a rather ungeneric way
in acpi-cpufreq driver's target() function only.
-> Move the call to trace_power_frequency to
   cpufreq.c:cpufreq_notify_transition() where CPUFREQ_POSTCHANGE
   notifier is triggered.
   This will support power frequency tracing by all cpufreq drivers

trace_power_frequency did not trace frequency changes correctly when
the userspace governor was used or when CPU cores' frequency depend
on each other.
-> Moving this into the CPUFREQ_POSTCHANGE notifier and pass the cpu
   which gets switched automatically fixes this.

Robert Schoene provided some important fixes on top of my initial
quick shot version which are integrated in this patch:
- Forgot some changes in power_end trace (TP_printk/variable names)
- Variable dummy in power_end must now be cpu_id
- Use static 64 bit variable instead of unsigned int for cpu_id
Signed-off-by: Thomas Renninger <trenn@suse.de>
CC: davej@redhat.com
CC: arjan@infradead.org
CC: linux-kernel@vger.kernel.org
CC: robert.schoene@tu-dresden.de
Tested-by: robert.schoene@tu-dresden.de
Signed-off-by: Dave Jones <davej@redhat.com>

Signed-off-by: Thomas Renninger <trenn@suse.de>
CC: venki@google.com
CC: davej@redhat.com
CC: arjan@infradead.org
CC: linux-kernel@vger.kernel.org
Signed-off-by: Dave Jones <davej@redhat.com>

For UP systems this is not required, and results in a more consistent
sample interval.

[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Jocelyn Falempe <jocelyn.falempe@motorola.com>
Signed-off-by: Mike Chan <mike@android.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Dave Jones <davej@redhat.com>

lock_policy_rwsem_* and unlock_policy_rwsem_* functions are scheduled
to be unexported when 2.6.33. Now there are no other callers of them
out of cpufreq.c, unexport them and make them static.
Signed-off-by: WANG Cong <amwang@redhat.com>
Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Dave Jones <davej@redhat.com>

Make simpler to read and call.

*** v3 - Always call when powersave_bias is enabled.
Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Mike Chan <mike@android.com>
Signed-off-by: Dave Jones <davej@redhat.com>

On Wed, 2010-01-20 at 16:56 +0100, Thomas Renninger wrote:
> But most often this happens if people upgrade their CPU and do not
> update their BIOS.
> Or the vendor does not recognise the new CPU even if the BIOS got
> updated.

Maybe some of those people just didn't realize it was disabled in BIOS?
If you tell users that it's a firmware bug then they'll probably just
give up.

> The itself message might be an enhancment, IMO it's not worth a patch.

Why do you think so? I spent an hour on hunting down the BIOS upgrade,
only to find that it didn't improve anything. It was a day later that I
realized that it might be a BIOS option; and the option was literally
the _last_ option in the whole BIOS setup. :)

This message would have saved the day.

> But do not revert the FW_BUG part!

Sure, you have a point here.

How about this patch?

The Pstate transition latency check was added for broken F10h BIOSen
which wrongly contain a value of 0 for transition and bus master
latency. Fam11h and later, however, (will) have similar transition
latency so extend that behavior for them too.
Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
Signed-off-by: Dave Jones <davej@redhat.com>

The PCC cpufreq driver unmaps the mailbox address range if any CPUs fail to
initialise, but doesn't do anything to remove the registered CPUs from the
cpufreq core resulting in failures further down the line. We're better off
simply returning a failure - the cpufreq core will unregister us cleanly if
we end up with no successfully registered CPUs. Tidy up the failure path
and also add a sanity check to ensure that the firmware gives us a realistic
frequency - the core deals badly with that being set to 0.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Cc: Naga Chumbalkar <nagananda.chumbalkar@hp.com>
Signed-off-by: Dave Jones <davej@redhat.com>

Prevent double freeing on error path.
Signed-off-by: Daniel J Blueman <daniel.blueman@gmail.com>
Signed-off-by: Dave Jones <davej@redhat.com>

The pcc specification documents an _OSC method that's incompatible with the
one defined as part of the ACPI spec. This shouldn't be a problem as both
are supposed to be guarded with a UUID. Unfortunately approximately nobody
(including HP, who wrote this spec) properly check the UUID on entry to the
_OSC call. Right now this could result in surprising behaviour if the pcc
driver performs an _OSC call on a machine that doesn't implement the pcc
specification. Check whether the PCCH method exists first in order to reduce
this probability.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Cc: Naga Chumbalkar <nagananda.chumbalkar@hp.com>
Signed-off-by: Dave Jones <davej@redhat.com>

We didn't free policy->related_cpus in error path err_unlock_policy.
This is catched by following kmemleak report:

unreferenced object 0xffff88022a0b96d0 (size 512):
  comm "modprobe", pid 886, jiffies 4294689177 (age 780.694s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [<ffffffff8111ebe5>] create_object+0x186/0x281
    [<ffffffff814fad4f>] kmemleak_alloc+0x60/0xa7
    [<ffffffff8111127a>] kmem_cache_alloc_node_notrace+0x120/0x142
    [<ffffffff81262e4f>] alloc_cpumask_var_node+0x2c/0xd7
    [<ffffffff81262f0b>] alloc_cpumask_var+0x11/0x13
    [<ffffffff81262f1c>] zalloc_cpumask_var+0xf/0x11
    [<ffffffff8140fac0>] cpufreq_add_dev+0x11f/0x547
    [<ffffffff81334bda>] sysdev_driver_register+0xc2/0x11d
    [<ffffffff8140e334>] cpufreq_register_driver+0xcb/0x1b8
    [<ffffffffa032e040>] 0xffffffffa032e040
    [<ffffffff810021ba>] do_one_initcall+0x5e/0x15c
    [<ffffffff81087f94>] sys_init_module+0xa6/0x1e6
    [<ffffffff81009bc2>] system_call_fastpath+0x16/0x1b
    [<ffffffffffffffff>] 0xffffffffffffffff
Signed-off-by: Xiaotian Feng <dfeng@redhat.com>
Cc: Thomas Renninger <trenn@suse.de>
Cc: Prarit Bhargava <prarit@redhat.com>
Signed-off-by: Dave Jones <davej@redhat.com>

395913d0 ("[CPUFREQ] remove rwsem lock
from CPUFREQ_GOV_STOP call (second call site)") is not needed, because
there is no rwsem lock in cpufreq_ondemand and cpufreq_conservative
anymore.  Lock should not be released until the work done.

Addresses https://bugzilla.kernel.org/show_bug.cgi?id=1594Signed-off-by: Andrej Gelenberg <andrej.gelenberg@udo.edu>
Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Dave Jones <davej@redhat.com>

* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6:
  ACPI / Sleep: Allow the NVS saving to be skipped during suspend to RAM
  ACPI: create "processor.bm_check_disable" boot param
  ACPI: skip checking BM_STS if the BIOS doesn't ask for it
  ACPI: fix unused function warning
  ACPI: processor: fix processor_physically_present on UP
  ACPI video: fix string mismatch for Sony SR290 laptop
  ACPI battery: don't invoke power_supply_changed twice when battery is hot-added
  ACPI: handle systems which asynchoronously enable ACPI mode

This fixes the regression in 2.6.35-rcX where bluetooth network devices
would fail to be deleted from sysfs, causing their destruction and
recreation to fail.  In addition this fixes the mac80211_hwsim driver
where it would leave around sysfs files when the driver was removed.

This problem is discussed at
  https://bugzilla.kernel.org/show_bug.cgi?id=16257

The reason for the regression is that the network namespace support
added to sysfs expects and requires that network devices be put in
directories that can contain only network devices.

Today get_device_parent almost provides that guarantee for all class
devices, except for a specific exception when the parent of a class
devices is a class device.  It would be nice to simply remove that
arguably incorrect special case, but apparently the input devices depend
on it being there.  So I have only removed it for class devices with
network namespace support.  Which today are the network devices.

It has been suggested that a better fix would be to change the parent
device from a class device to a bus device, which in the case of the
bluetooth driver would change /sys/class/bluetooth to /sys/bus/bluetoth,
I can not see how we would avoid significant userspace breakage if we
were to make that change.

Adding an extra directory in the path to the device will also be
userspace visible but it is much less likely to break things.
Everything is still accessible from /sys/class (for example), and it
fixes two bugs.  Adding an extra directory fixes a 3 year old regression
introduced with the new sysfs layout that makes it impossible to rename
bnep0 network devices to names that conflict with hci device attributes
like hci_revsion.  Adding an additional directory removes the new
failure modes introduced by the network namespace code.

If it weren't for the regession in the renaming of network devices I
would figure out how to just make the sysfs code deal with this
configuration of devices.

In summary this patch fixes regressions by changing:
"/sys/class/bluetooth/hci0/bnep0" to "/sys/class/bluetooth/hci0/net/bnep0".
Reported-by: Johannes Berg <johannes@sipsolutions.net>
Reported-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

virtio ring was changed to return an error code on OOM,
but one caller was missed and still checks for vq->vring.num.
The fix is just to check for <0 error code.

Long term it might make sense to change goto add_head to
just return an error on oom instead, but let's apply
a minimal fix for 2.6.35.
Reported-by: Chris Mason <chris.mason@oracle.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Tested-by: Chris Mason <chris.mason@oracle.com>
Cc: stable@kernel.org # .34.x
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Commit 3fea6026 ("Input: twl40300-keypad - fix handling of "all
ground" rows") broke compilation as I managed to use non-existent
keycodes.
Reported-by: Arjan van de Ven <arjan@infradead.org>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Commit 2a6b6976
(ACPI: Store NVS state even when entering suspend to RAM) caused the
ACPI suspend code save the NVS area during suspend and restore it
during resume unconditionally, although it is known that some systems
need to use acpi_sleep=s4_nonvs for hibernation to work.  To allow
the affected systems to avoid saving and restoring the NVS area
during suspend to RAM and resume, introduce kernel command line
option acpi_sleep=nonvs and make acpi_sleep=s4_nonvs work as its
alias temporarily (add acpi_sleep=s4_nonvs to the feature removal
file).

Addresses https://bugzilla.kernel.org/show_bug.cgi?id=16396 .
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Reported-and-tested-by: tomas m <tmezzadra@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>

* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
  vmlinux.lds: fix .data..init_task output section (fix popwerpc boot)
  powerpc: Fix erroneous lmb->memblock conversions
  powerpc/mm: Add some debug output when hash insertion fails
  powerpc/mm: Fix bugs in huge page hashing
  powerpc/mm: Move around testing of _PAGE_PRESENT in hash code
  powerpc/mm: Handle hypervisor pte insert failure in __hash_page_huge
  powerpc/kexec: Fix boundary case for book-e kexec memory limits

* 'rc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild-2.6:
  nconfig: Fix segfault when help contains special characters
  kbuild: Fix make rpm
  kbuild: Make the setlocalversion script POSIX-compliant

Merge branch 'perf-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip

* 'perf-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
  perf tools: Fix fallback to cplus_demangle() when bfd_demangle() is not available
  perf annotate: Fix handling of goto labels that are valid hex numbers
  tracing: Properly align linker defined symbols
  perf symbols: Fix directory descriptor leaking
  perf: Fix various display bugs with parent filtering

nconfig segfaults when help text contains the character '%'. For a quick
example, navigate to the kernel compression options and get the help for
bzip2. Doing so triggers a call to mvwprintw() with a string containing
'%' and no extra arguments to fill in the specifier's value. Fix this
case by printing the literal string retrieved from the kconfig.

 #0  0x00002b52b6b11d83 in vfprintf () from /lib/libc.so.6
 #1  0x00002b52b6bad010 in __vsnprintf_chk () from /lib/libc.so.6
 #2  0x00002b52b623991b in _nc_printf_string () from
 /lib/libncursesw.so.5
 #3  0x00002b52b6234cff in vwprintw () from /lib/libncursesw.so.5
 #4  0x00002b52b6234db9 in mvwprintw () from /lib/libncursesw.so.5
 #5  0x00000000004151d8 in fill_window (win=0x21b64c0,
     text=0x21b62b0 "CONFIG_KERNEL_BZIP2:\n\nIts compression ratio and
     speed is intermediate.\nDecompression speed is slowest among the
     three.  The kernel\nsize is about 10% smaller with bzip2, in
     comparison to gzip.\nBzip2 us"...)
     at scripts/kconfig/nconf.gui.c:229
 #6  0x0000000000416335 in show_scroll_win (main_window=0x21a5630,
         title=0x157fa30 "Bzip2",
 	    text=0x21b62b0 "CONFIG_KERNEL_BZIP2:\n\nIts compression
 	    ratio and speed is intermediate.\nDecompression speed is
 	    slowest among the three.  The kernel\nsize is about 10%
 	    smaller with bzip2, in comparison to gzip.\nBzip2 us"...)
     at scripts/kconfig/nconf.gui.c:535
 #7  0x00000000004055b2 in show_help (menu=0x157f9d0)
         at scripts/kconfig/nconf.c:1257
 #8  0x0000000000405897 in conf_choice (menu=0x157f130)
 	    at scripts/kconfig/nconf.c:1321
 #9  0x0000000000405326 in conf (menu=0x157d130) at
 	    scripts/kconfig/nconf.c:1208
 #10 0x00000000004052e8 in conf (menu=0xb434a0) at
 	    scripts/kconfig/nconf.c:1203
 #11 0x0000000000406092 in main (ac=2, av=0x7fff96a93c38)

Cc: Michal Marek <mmarek@suse.cz>
Cc: Nir Tzachar <nir.tzachar@gmail.com>
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>

The .data..init_task output section was missing
a load offset causing a popwerpc target to fail to boot.

Sean MacLennan tracked it down to the definition of
INIT_TASK_DATA_SECTION().

There are only two users of INIT_TASK_DATA_SECTION()
in the kernel today: cris and popwerpc.
cris do not support relocatable kernels and is thus not
impacted by this change.

Fix INIT_TASK_DATA_SECTION() to specify load offset like
all other output sections.
Reported-by: Sean MacLennan <smaclennan@pikatech.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

Oooops... we missed these. We incorrectly converted strings
used when parsing the device-tree on pseries, thus breaking
access to drconf memory and hotplug memory.

While at it, also revert some variable names that represent
something the FW calls "lmb" and thus don't need to be converted
to "memblock".
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---

This adds some debug output to our MMU hash code to print out some
useful debug data if the hypervisor refuses the insertion (which
should normally never happen).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---

There's a couple of nasty bugs lurking in our huge page hashing code.

First, we don't check the access permission atomically with setting
the _PAGE_BUSY bit, which means that the PTE value we end up using
for the hashing might be different than the one we have checked
the access permissions for.

We've seen cases where that leads us to try to use an invalidated
PTE for hashing, causing all sort of "interesting" issues.

Then, we also failed to set _PAGE_DIRTY on a write access.

Finally, a minor tweak but we should return 0 when we find the
PTE busy, in order to just re-execute the access, rather than 1
which means going to do_page_fault().
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---

Instead of adding _PAGE_PRESENT to the access permission mask
in each low level routine independently, we add it once from
hash_page().

We also move the preliminary access check (the racy one before
the PTE is locked) up so it applies to the huge page case. This
duplicates code in __hash_page_huge() which we'll remove in a
subsequent patch to fix a race in there.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

If the hypervisor gives us an error on a hugepage insert we panic. The
normal page code already handles this by returning an error instead and we end
calling low_hash_fault which will just kill the task if possible.

The patch below does a similar thing for the hugepage case.
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

processor.bm_check_disable=1" prevents Linux from checking BM_STS
before entering C3-type cpu power states.

This may be useful for a system running acpi_idle
where the BIOS exports FADT C-states, _CST IO C-states,
or _CST FFH C-states with the BM_STS bit set;
while configuring the chipset to set BM_STS
more frequently than perhaps is optimal.

Note that such systems may have been developed
using a tickful OS that would quickly clear BM_STS,
rather than a tickless OS that may go for some time
between checking and clearing BM_STS.

Note also that an alternative for newer systems
is to use the intel_idle driver, which always
ignores BM_STS, relying Linux device drivers
to register constraints explicitly via PM_QOS.

https://bugzilla.kernel.org/show_bug.cgi?id=15886Signed-off-by: Len Brown <len.brown@intel.com>