* git://git.kernel.org/pub/scm/linux/kernel/git/hirofumi/fatfs-2.6:
fat: Check s_dirt in fat_sync_fs()
vfat: change the default from shortname=lower to shortname=mixed
fat/nls: Fix handling of utf8 invalid char
* 'pm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/suspend-2.6:
PM / yenta: Fix cardbus suspend/resume regression
PM / PCMCIA: Drop second argument of pcmcia_socket_dev_suspend()
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: (33 commits)
sony-laptop: re-read the rfkill state when resuming from suspend
sony-laptop: check for rfkill hard block at load time
wext: add back wireless/ dir in sysfs for cfg80211 interfaces
wext: Add bound checks for copy_from_user
mac80211: improve/fix mlme messages
cfg80211: always get BSS
iwlwifi: fix 3945 ucode info retrieval after failure
iwlwifi: fix memory leak in command queue handling
iwlwifi: fix debugfs buffer handling
cfg80211: don't set privacy w/o key
cfg80211: wext: don't display BSSID unless associated
net: Add explicit bound checks in net/socket.c
bridge: Fix double-free in br_add_if.
isdn: fix netjet/isdnhdlc build errors
atm: dereference of he_dev->rbps_virt in he_init_group()
ax25: Add missing dev_put in ax25_setsockopt
Revert "sit: stateless autoconf for isatap"
net: fix double skb free in dcbnl
net: fix nlmsg len size for skb when error bit is set.
net: fix vlan_get_size to include vlan_flags size
...
* 'drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6: (25 commits)
drm/radeon/kms: Convert R520 to new init path and associated cleanup
drm/radeon/kms: Convert RV515 to new init path and associated cleanup
drm: fix radeon DRM warnings when !CONFIG_DEBUG_FS
drm: fix drm_fb_helper warning when !CONFIG_MAGIC_SYSRQ
drm/r600: fix memory leak introduced with 64k malloc avoidance fix.
drm/kms: make fb helper work for all drivers.
drm/radeon/r600: fix offset handling in CS parser
drm/radeon/kms/r600: fix forcing pci mode on agp cards
drm/radeon/kms: fix for the extra pages copying.
drm/radeon/kms/r600: add support for vline relocs
drm/radeon/kms: fix some bugs in vline reloc
drm/radeon/kms/r600: clamp vram to aperture size
drm/kms: protect against fb helper not being created.
drm/r600: get values from the passed in IB not the copy.
drm: create gitignore file for radeon
drm/radeon/kms: remove unneeded master create/destroy functions.
drm/kms: start adding command line interface using fb.
fb: change rules for global rules match.
drm/radeon/kms: don't require up to 64k allocations. (v2)
drm/radeon/kms: enable dac load detection by default.
...
Trivial conflicts in drivers/gpu/drm/radeon/radeon_asic.h due to adding
'->vga_set_state' function pointers.
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu:
percpu: make allocation failures more verbose
percpu: make pcpu_setup_first_chunk() failures more verbose
percpu: make embedding first chunk allocator check vmalloc space size
sparc64: implement page mapping percpu first chunk allocator
percpu: make pcpu_build_alloc_info() clear static buffers
percpu: fix unit_map[] verification in pcpu_setup_first_chunk()
David Howells noticed (due to the compiler warning about an unused
'pty_ops_bsd' variable) that we haven't actually been using the code
that implements TIOCSPTLCK for legacy pty handling. It's been that way
since 2.6.26, commit 3e8e88ca05 to be
exact ("pty: prepare for tty->ops changes").
DavidH initially submitted a patch just removing the dead code entirely,
and since nobody has apparently ever complained, I'm not entirely sure
that wouldn't be the right thing to do. But since the whole and only
point of the legacy pty code is to be compatible with legacy distros
that don't use the new unix98 pty model, let's just wire it up again.
And clean it up a bit while we're at it.
Acked-by: David Howells <dhowells@redhat.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This reverts commit 22223c9b41, as
requested by Andi Kleen:
"Obviously kernels compiled with AMD support can still run on non AMD
systems, so messages like this can never be removed at compile time."
Requsted-by: Andi Kleen <andi@firstfloor.org>
Cc: Borislav Petkov <borislav.petkov@amd.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Convert the r520 asic support to new init path, change are smaller than
previous one as most of the architecture is now in place and more code
sharing can happen btw various asics.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@linux.ie>
Convert the rv515 asic support to new init path also add an explanation
in radeon.h about the new init path. There is also few cleanups
associated with this change (others asic calling rv515 helper
functions).
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@linux.ie>
Compiling the radeon DRM driver with !CONFIG_DEBUG_FS
throws the following warnings:
drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_ttm_debugfs_init':
drivers/gpu/drm/radeon/radeon_ttm.c:714: warning: unused variable 'i'
drivers/gpu/drm/radeon/radeon_ttm.c: At top level:
drivers/gpu/drm/radeon/radeon_ttm.c:692: warning: 'radeon_mem_types_list' defined but not used
drivers/gpu/drm/radeon/radeon_ttm.c:693: warning: 'radeon_mem_types_names' defined but not used
Fix: move these variables inside the #if defined(CONFIG_DEBUG_FS)
block in radeon_ttm_debugsfs_init(), which is the only place using them.
Signed-off-by: Mikael Pettersson <mikpe@it.uu.se>
Signed-off-by: Dave Airlie <airlied@linux.ie>
Compiling DRM throws the following warning if MAGIC_SYSRQ is disabled:
drivers/gpu/drm/drm_fb_helper.c:101: warning: 'sysrq_drm_fb_helper_restore_op' defined but not used
Fix: place sysrq_drm_fb_helper_restore_op and associated
definitions inside #ifdef CONFIG_MAGIC_SYSRQ.
Signed-off-by: Mikael Pettersson <mikpe@it.uu.se>
Signed-off-by: Dave Airlie <airlied@linux.ie>
Warn and dump stack when percpu allocation fails. percpu allocator is
still young and unchecked NULL percpu pointer usage can result in
random memory corruption when combined with the pointer shifting in
access macros. Allocation failures should be rare and the warning
message will be disabled after certain times.
Signed-off-by: Tejun Heo <tj@kernel.org>
The parameters to pcpu_setup_first_chunk() come from different sources
depending on architecture and can be quite complex. The function runs
various sanity checks on the parameters and triggers BUG() if
something isn't right. However, this is very early during the boot
and not reporting exactly what the problem is makes debugging even
harder.
Add PCPU_SETUP_BUG() macro which prints out enough information about
the parameters. As the macro still puts separate BUG() for each
check, it won't lose any information even on the situations where only
the program counter can be retrieved.
While at it, also bump pcpu_dump_alloc_info() message to KERN_INFO so
that it's visible on the console if boot fails to complete.
Signed-off-by: Tejun Heo <tj@kernel.org>
Embedding first chunk allocator maintains the distances between units
in the vmalloc area and thus needs vmalloc space to be larger than the
maximum distances between units; otherwise, it wouldn't be able to
create any dynamic chunks. This patch makes the embedding first chunk
allocator check vmalloc space size and if the maximum distance between
units is larger than 75% of it, print warning and, if page mapping
allocator is available, fail initialization so that the system falls
back onto it.
This should work around percpu allocation failure problems on certain
sparc64 configurations where distances between NUMA nodes are larger
than the vmalloc area and makes percpu allocator more robust for
future configurations.
Signed-off-by: Tejun Heo <tj@kernel.org>
Implement page mapping percpu first chunk allocator as a fallback to
the embedding allocator. The next patch will make the embedding
allocator check distances between units to determine whether it fits
within the vmalloc area so that this fallback can be used on such
cases.
sparc64 currently has relatively small vmalloc area which makes it
impossible to create any dynamic chunks on certain configurations
leading to percpu allocation failures. This and the next patch should
allow those configurations to keep working until proper solution is
found.
While at it, mark pcpu_cpu_distance() with __init.
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: David S. Miller <davem@davemloft.net>
pcpu_build_alloc_info() may be called multiple times when percpu is
falling back to different first chunk allocator. Make it clear static
buffers so that they don't contain values from previous runs.
Signed-off-by: Tejun Heo <tj@kernel.org>
pcpu_setup_first_chunk() incorrectly used NR_CPUS as the impossible
unit number while unit number can equal and go over NR_CPUS with
sparse unit map. This triggers BUG_ON() spuriously on machines which
have non-power-of-two number of cpus. Use UINT_MAX instead.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-and-tested-by: Tony Vroon <tony@linx.net>
Since 2.6.29 the PCI PM core have been restoring the standard
configuration registers of PCI devices in the early phase of
resume. In particular, PCI devices without drivers have been handled
this way since commit 355a72d75b
(PCI: Rework default handling of suspend and resume). Unfortunately,
this leads to post-resume problems with CardBus devices which cannot
be accessed in the early phase of resume, because the sockets they
are on have not been woken up yet at that point.
To solve this problem, move the yenta socket resume to the early
phase of resume and, analogously, move the suspend of it to the late
phase of suspend. Additionally, remove some unnecessary PCI code
from the yenta socket's resume routine.
Fixes http://bugzilla.kernel.org/show_bug.cgi?id=13092, which is a
post-2.6.28 regression.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Reported-by: Florian <fs-kernelbugzilla@spline.de>
Cc: stable@kernel.org
pcmcia_socket_dev_suspend() doesn't use its second argument, so it
may be dropped safely.
This change is necessary for the subsequent yenta suspend/resume fix.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Cc: stable@kernel.org
Without this, the hard-blocked state will be reported incorrectly if
the hardware switch is changed while the laptop is suspended.
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Tested-by: Norbert Preining <preining@logic.at>
Acked-by: Mattia Dongili <malattia@linux.it>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
"I recently (on a flight) I found out that when I boot with the hard-switch
activated, so turning off all wireless activity on my laptop, the state
is not correctly announced in /dev/rfkill (reading it with rfkill command,
or my own gnome applet)...
After turning off and on again the hard-switch the events were right."
We can fix this by querying the firmware at load time and calling
rfkill_set_hw_state().
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Tested-by: Norbert Preining <preining@logic.at>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Acked-by: Mattia Dongili <malattia@linux.it>
CC: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The move away from having drivers assign wireless handlers,
in favour of making cfg80211 assign them, broke the sysfs
registration (the wireless/ dir went missing) because the
handlers are now assigned only after registration, which is
too late.
Fix this by special-casing cfg80211-based devices, all
of which are required to have an ieee80211_ptr, in the
sysfs code, and also using get_wireless_stats() to have
the same values reported as in procfs.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Reported-by: Hugh Dickins <hugh.dickins@tiscali.co.uk>
Tested-by: Hugh Dickins <hugh.dickins@tiscali.co.uk>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The wireless extensions have a copy_from_user to a local stack
array "essid", but both me and gcc have failed to find where
the bounds for this copy are located in the code.
This patch adds some basic sanity checks for the copy length
to make sure that we don't overflow the stack buffer.
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Cc: linux-wireless@vger.kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
It's useful to know the MAC address when being
disassociated; fix a typo (missing colon) and
move some messages so we get them only when they
are actually taking effect.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Multiple problems were reported due to interaction
between wpa_supplicant and the wext compat code in
cfg80211, which appear to be due to it not getting
any bss pointer here when wpa_supplicant sets all
parameters -- do that now. We should still get the
bss after doing an extra scan, but that appears to
increase the time we need for connecting enough to
sometimes cause timeouts.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Tested-by: Hin-Tak Leung <hintak.leung@gmail.com>,
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When hardware or uCode problem occurs driver captures significant
information from device to enable debugging. The format of this information
is different between 3945 and 4965 and later devices, yet currently the
3945 uses the 4965 and later format. Fix this by adding a new library call
that is initialized to the correct formatting routine based on device.
This moves the iwlagn event and error log handling back to iwl-agn.c to
make it part of iwlagn module.
Also remove the 3945 sysfs file that triggers dump of event log - there is
already a debugfs file that can do it for all drivers.
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Also free the array of command pointers and meta data of each
command buffer when command queue is freed.
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We keep track of where to write into a buffer by keeping a count of how
much has been written so far. When writing to the buffer we thus take the
buffer pointer and adding the count of what has been written so far.
Keeping track of what has been written so far is done by incrementing
this number every time something is written to the buffer with how much has
been written at that time.
Currently this number is incremented incorrectly when using the
"hex_dump_to_buffer" call to add data to the buffer. Fix this by only
adding what has been added to the buffer in that call instead of what has
been added since beginning of buffer.
Issue was discovered and discussed during testing of
https://bugzilla.redhat.com/show_bug.cgi?id=464598 .
When a user views any of these files they will see something like:
[ 179.355202] ------------[ cut here ]------------
[ 179.355209] WARNING: at ../lib/vsprintf.c:989 vsnprintf+0x5ec/0x5f0()
[ 179.355212] Hardware name: VGN-Z540N
[ 179.355213] Modules linked in: i915 drm i2c_algo_bit i2c_core ipv6 acpi_cpufreq cpufreq_userspace cpufreq_powersave cpufreq_ondemand cpufreq_conservative cpufreq_stats freq_table container sbs sbshc arc4 ecb iwlagn iwlcore joydev led_class mac80211 af_packet pcmcia psmouse sony_laptop cfg80211 iTCO_wdt iTCO_vendor_support pcspkr serio_raw rfkill intel_agp video output tpm_infineon tpm tpm_bios button battery yenta_socket rsrc_nonstatic pcmcia_core processor ac evdev ext3 jbd mbcache sr_mod sg cdrom sd_mod ahci libata scsi_mod ehci_hcd uhci_hcd usbcore thermal fan thermal_sys
[ 179.355262] Pid: 5449, comm: cat Not tainted 2.6.31-wl-54419-ge881071 #62
[ 179.355264] Call Trace:
[ 179.355267] [<ffffffff811ad14c>] ? vsnprintf+0x5ec/0x5f0
[ 179.355271] [<ffffffff81041348>] warn_slowpath_common+0x78/0xd0
[ 179.355275] [<ffffffff810413af>] warn_slowpath_null+0xf/0x20
[ 179.355277] [<ffffffff811ad14c>] vsnprintf+0x5ec/0x5f0
[ 179.355280] [<ffffffff811ad23d>] ? scnprintf+0x5d/0x80
[ 179.355283] [<ffffffff811ad23d>] scnprintf+0x5d/0x80
[ 179.355286] [<ffffffff811aed29>] ? hex_dump_to_buffer+0x189/0x340
[ 179.355290] [<ffffffff810e91d7>] ? __kmalloc+0x207/0x260
[ 179.355303] [<ffffffffa02a02f8>] iwl_dbgfs_nvm_read+0xe8/0x220 [iwlcore]
[ 179.355306] [<ffffffff811a9b62>] ? __up_read+0x92/0xb0
[ 179.355310] [<ffffffff810f0988>] vfs_read+0xc8/0x1a0
[ 179.355313] [<ffffffff810f0b50>] sys_read+0x50/0x90
[ 179.355316] [<ffffffff8100bd6b>] system_call_fastpath+0x16/0x1b
[ 179.355319] ---[ end trace 2383d0d5e0752ca0 ]---
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When wpa_supplicant is used to connect to open networks,
it causes the wdev->wext.keys to point to key memory, but
that key memory is all empty. Only use privacy when there
is a default key to be used.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Tested-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Tested-by: Kalle Valo <kalle.valo@iki.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Currently, cfg80211's SIOCGIWAP implementation returns
the BSSID that the user set, even if the connection has
since been dropped due to other changes. It only should
return the current BSSID when actually connected.
Also do a small code cleanup.
Reported-by: Thomas H. Guenther <thomas.h.guenther@intel.com>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Tested-by: Thomas H. Guenther <thomas.h.guenther@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The sys_socketcall() function has a very clever system for the copy
size of its arguments. Unfortunately, gcc cannot deal with this in
terms of proving that the copy_from_user() is then always in bounds.
This is the last (well 9th of this series, but last in the kernel) such
case around.
With this patch, we can turn on code to make having the boundary provably
right for the whole kernel, and detect introduction of new security
accidents of this type early on.
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
There is a potential double-kfree in net/bridge/br_if.c. If br_fdb_insert
fails, then the kobject is put back (which calls kfree due to the kobject
release), and then kfree is called again on the net_bridge_port. This
patch fixes the crash.
Thanks to Stephen Hemminger for the one-line fix.
Signed-off-by: Jeff Hansen <x@jeffhansen.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Commit cb3824bade didn't fix this problem.
Fix build errors in netjet, using isdnhdlc module:
drivers/built-in.o: In function `mode_tiger':
netjet.c:(.text+0x1ca0c7): undefined reference to `isdnhdlc_rcv_init'
netjet.c:(.text+0x1ca0d4): undefined reference to `isdnhdlc_out_init'
drivers/built-in.o: In function `fill_dma':
netjet.c:(.text+0x1ca2bd): undefined reference to `isdnhdlc_encode'
drivers/built-in.o: In function `read_dma':
netjet.c:(.text+0x1ca614): undefined reference to `isdnhdlc_decode'
drivers/built-in.o: In function `nj_irq':
netjet.c:(.text+0x1cb07a): undefined reference to `isdnhdlc_encode'
drivers/built-in.o: In function `isdnhdlc_decode':
(.text+0x1c2088): undefined reference to `crc_ccitt_table'
drivers/built-in.o: In function `isdnhdlc_encode':
(.text+0x1c2339): undefined reference to `crc_ccitt_table'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The prefix decrement causes a very long loop if pci_pool_alloc() failed
in the first iteration. Also I swapped rbps and rbpl arguments.
Reported-by: Juha Leppanen <juha_motorsportcom@luukku.com>
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
ax25_setsockopt SO_BINDTODEVICE is missing a dev_put call in case of
success. Re-order code to fix this bug. While at it also reformat two
lines of code to comply with the Linux coding style.
Initial patch by Jarek Poplawski <jarkao2@gmail.com>.
Reported-by: Bernard Pidoux F6BVP <f6bvp@free.fr>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
It's worked fine so far since reset is done for the first time.
Reported-by: Juha Leppanen <juha_motorsportcom@luukku.com>
Signed-off-by: Hiroshi DOYU <Hiroshi.DOYU@nokia.com>
Signed-off-by: Juha Leppanen <juha_motorsportcom@luukku.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
The legacy r600 path shares code, but doesn't share quite enough
to get the freeing correct. Free the pages here also.
Signed-off-by: Dave Airlie <airlied@redhat.com>
This initialises the fb helper with the connector helper,
so that the fb cmdline code works for intel as well.
Signed-off-by: Dave Airlie <airlied@redhat.com>
.. duplicated by merging the same fix twice, for details see commit
0d9df2515d ("Merge
git://git.kernel.org/pub/scm/linux/kernel/git/sam/kbuild-fixes")
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The following commit made console open fails while booting:
commit b50989dc44
Author: Alan Cox <alan@linux.intel.com>
Date: Sat Sep 19 13:13:22 2009 -0700
tty: make the kref destructor occur asynchronously
Due to tty release routines run in a workqueue now, error like the
following will be reported while booting:
INIT open /dev/console Input/output error
It also causes hibernation regression to appear as reported at
http://bugzilla.kernel.org/show_bug.cgi?id=14229
The reason is that now there's latency issue with closing, but when
we open a "closing not finished" tty, -EIO will be returned.
Fix it as per the following Alan's suggestion:
Fun but it's actually not a bug and the fix is wrong in itself as
the port may be closing but not yet being destructed, in which case
it seems to do the wrong thing. Opening a tty that is closing (and
could be closing for long periods) is supposed to return -EIO.
I suspect a better way to deal with this and keep the old console
timing is to split tty->shutdown into two functions.
tty->shutdown() - called synchronously just before we dump the tty
onto the waitqueue for destruction
tty->cleanup() - called when the destructor runs.
We would then do the shutdown part which can occur in IRQ context
fine, before queueing the rest of the release (from tty->magic = 0
... the end) to occur asynchronously
The USB update in -next would then need a call like
if (tty->cleanup)
tty->cleanup(tty);
at the top of the async function and the USB shutdown to be split
between shutdown and cleanup as the USB resource cleanup and final
tidy cannot occur synchronously as it needs to sleep.
In other words the logic becomes
final kref put
make object unfindable
async
clean it up
Signed-off-by: Dave Young <hidave.darkstar@gmail.com>
[ rjw: Rebased on top of 2.6.31-git, reworked the changelog. ]
Signed-off-by: "Rafael J. Wysocki" <rjw@sisk.pl>
[ Changed serial naming to match new rules, dropped tty_shutdown as per
comments from Alan Stern - Linus ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Commit 3d5b6fb47a ("ACPI: Kill overly
verbose "power state" log messages") removed the actual use of this
variable, but didn't remove the variable itself, resulting in build
warnings like
drivers/acpi/processor_idle.c: In function ‘acpi_processor_power_init’:
drivers/acpi/processor_idle.c:1169: warning: unused variable ‘i’
Just get rid of the now unused variable.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* mark struct vm_area_struct::vm_ops as const
* mark vm_ops in AGP code
But leave TTM code alone, something is fishy there with global vm_ops
being used.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
x86: Fix hwpoison code related build failure on 32-bit NUMAQ
ia64's sim_defconfig uses CONFIG_ACPI=n
which now #define's acpi_disabled in <linux/acpi.h>
So we shouldn't re-define it here in <asm/acpi.h>
Signed-off-by: Len Brown <len.brown@intel.com>
I was recently lucky enough to get a 64-CPU system, so my kernel log
ends up with 64 lines like:
ACPI: CPU0 (power states: C1[C1] C2[C3])
This is pretty useless clutter because this info is already available
after boot from both /sys/devices/system/cpu/cpu*/cpuidle/state?/ as
well as /proc/acpi/processor/CPU*/power.
So just delete the code that prints the C-states in processor_idle.c.
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Signed-off-by: Len Brown <len.brown@intel.com>
