X86_PC is the only remaining 'sub' architecture, so we dont need
it anymore.
This also cleans up a few spurious references to X86_PC in the
driver space - those certainly should be X86.
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
ath5k_config updates the software context without taking sc->lock.
Changes-licensed-under: 3-Clause-BSD
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Acked-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When CONFIG_CFG80211_REG_DEBUG is enabled and an intersection
occurs we are printing the regulatory domain passed by CRDA
and indicating its the intersected regulatory domain. Lets fix
this and print the intersection as originally intended.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This fixes two issues with the sanity check loop when processing
the country IE:
1. Do not use frequency for the current subband channel check,
this was a big fat typo.
2. Apply the 5 GHz 4-channel steps when considering max channel
on each subband as was done with a recent patch.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The patch fixes memcpy to NULL address when the ucode DMA allocation failure.
This is a fix to bug
http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1861
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
After reports of poor performance, a review of the latest vendor driver
(rtl8187_linux_26.1025.0328.2007) for RTL8187L devices was undertaken.
A difference was found in the code used to index the OFDM power tables. When
the Linux driver was changed, my unit works at a much greater range than
before. I think this fixes Bugzilla #12380 and has been tested by at least
two other users.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Tested-by: Martín Ernesto Barreyro <barreyromartin@gmail.com>
Cc: Stable <stable@kernel.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
His email address keeps bouncing, and he's not interested in mac80211
patches etc. anyway.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In case of !CONFIG_X86_WP_WORKS_OK, __put_user_size_ex() is not defined.
Add macros for !CONFIG_X86_WP_WORKS_OK case.
Signed-off-by: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
xapic fix for 32bit platform with less than 8 cpu's.
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
as per https://bugs.launchpad.net/bugs/294391. These got one sample of
each iPod generation going. However there still occurred I/O stalls
with the 3rd generation iPod which remain undiagnosed at the time of
this writing.
Acked-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
According to https://bugs.launchpad.net/bugs/294391
- 3rd generation iPods need the "fix capacity" workaround after all
(apparently they crash after the last sector was accessed),
- 2nd generation iPods need the "128 kB maximum request size"
workaround.
Alas both iPod generations feature the same model ID in the config ROM,
hence we can only define a shared quirks list entry for them. Luckily
the fix capacity workaround did not show a negative effect in Jarod's
tests with 2nd gen. iPod.
A side note: Apple computers in target mode (or at least an x86 Mac
mini) don't have firmware_version and model_id, hence none of the iPod
quirks list entries is active for them.
Tested-by: Jarod Wilson <jarod@redhat.com>
Acked-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
In omap24xx_cpu_suspend assembly routine, the r2 register which holds
the address of the SDRC_POWER reg is set to zero before the value is
written back triggering a fault due to writing to address zero.
It's hard to tell where this change was introduced since this file
has been moved and merged.
While this fix prevents a crash, suspend on my n810 is broken with
current kernels. I never come out of suspend.
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
By Ingo Molnar, interrupts are not masked by default.
(refer to 76d2160147)
But if interrupts are not masked, the processor can wake up while in
Suspend-to-RAM state by an external interrupt. For example, if an
OMAP3 board is connected to Host PC by USB and entered to Suspend-to-RAM
state, it wake up automatically by M_IRQ_92. The disable_irq() function
can't disable the interrupt in H/W level, So I modified
arch/arm/mach-omap2/irq.c
Signed-off-by: Kim Kyuwon <chammoru@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
When 32 kHz timer is used the min_delta_ns should be initialized so
that it reflects the timer programming cost. A write to the timer
device will be usually posted, but it takes roughly 3 cycles before
it is effective. If the timer is reprogrammed before that, the CPU
will stall until the previous write completes. This was pointed out by
Richard Woodruff.
Since the lower bound for min_delta_ns is 1000, the change is visible
only with tick rates less than 3 MHz.
Also note that the old value is incorrect for 32 kHz also due to
a rounding error, and it can cause the timer queue to hang (due to
clockevent code trying to program the timer with zero ticks).
Signed-off-by: Aaro Koskinen <Aaro.Koskinen@nokia.com>
Reviewed-by: Richard Woodruff <r-woodruff2@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
The naming accidentally broke while changing the name for the
driver to not to conflict with the other mmc driver.
Signed-off-by: Tony Lindgren <tony@atomide.com>
This has similar symptoms than 66c23551b1
where just omap_request_dma, omap_dma_link_lch and omap_dma_unlink_lch
can cause incorrect dump_stack(). Here it can happen if channel has been
used before and the channel flags variable holds old status.
Signed-off-by: Jarkko Nikula <jarkko.nikula@nokia.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
CSR must be cleared before invoking the callback.
If the callback function starts a new, fast DMA transfer on the same
channel, the completion status might lost if CSR is cleared after
the callback invocation.
Signed-off-by: Juha Yrjola <juha.yrjola@solidboot.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
A spin_lock deadlock will occur when omap_mcbsp_request() is invoked.
omap_mcbsp_request()
\- clk_enable(mcbsp->clk) [takes and holds clockfw_lock]
\- omap2_clk_enable()
\- _omap2_clk_enable()
\- omap_mcbsp_clk_enable()
\- clk_enable(child clock) [tries for clockfw_lock again]
mcbsp_clk is a virtual clock and it comprises several child clocks. when
enable mcbsp_clk in omap_mcbsp_request(), the enable function of mcbsp_clk
will enable its child clocks, then the deadlock occurs.
The solution is to remove the virtual clock and enable these child clocks in
omap_mcbsp_request() directly.
Signed-off-by: Stanley.Miao <stanley.miao@windriver.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
This reverts commit 5a611268b6.
It is causing occasional boot crashes, caused by certain
linker versions (GNU ld version 2.18.50.0.6-2 20080403) messing up:
82dcc000 D __per_cpu_load
c16e6000 A __per_cpu_load_abs
The __per_cpu_load value is out of whack. Hpa noticed the following
detail:
* (gdb) p/x -(0xc16e6000-0x82dcc000)
* $2 = 0xc16e6000
* I.e. one is the other << 1
The two symbols should be equal.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Impact: widen debug checks
VirtualBox calls do_page_fault() from an atomic context but runs into a
might_sleep() way pas this point, cure that.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
This UBIFS feature has never worked properly, and it was a mistake
to add it because we simply have no use-cases. So, lets still accept
the fast_unmount mount option, but ignore it. This does not change
much, because UBIFS commit in sync_fs anyway, and sync_fs is called
while unmounting.
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
When mounting/re-mounting, UBIFS returns EINVAL even if the ENOSPC
or EROFS codes are are much better, just because we have not found
references to ENOSPC/EROFS in mount (2) man pages. This patch
changes this behaviour and makes UBIFS return real error code,
because:
1. It is just less confusing and more logical
2. mount is not described in SuSv3, so it seems to be not really
well-standartized
3. we do not cover all cases, and any random undocumented in man
pages error code may be returned anyway
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
- preserve the idx_gc list - it will be needed in the same
state, should UBIFS be remounted rw again
- prevent remounting ro if we have switched to read only
mode (due to a fatal error)
Signed-off-by: Adrian Hunter <ext-adrian.hunter@nokia.com>
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
All writes go through wbufs so they must be sync'd
after syncing inodes and pages.
Signed-off-by: Adrian Hunter <ext-adrian.hunter@nokia.com>
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Impact: cleanup
We may use macros from processor-flags.h instead
of hardcoding bits. Actually it's not direct mapping
of old instructions with new ones -- BTS does change
CF flag while MOV does not. But i didn't find any
dependency on CF in this code.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Acked-by: Alexander van Heukelum <heukelum@fastmail.fm>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
This patch explicitly initializes McBSP Transmit Configuration
Control Register (XCCR) and Receive Configuration Control
Register (RCCR) to their reset values. Reset values are 26 ns
of DX delay and Transmit DMA disabled for XCCR register;
receive full cycle mode enabled and Receive DMA disabled for
RCCR register.
This patch requires a counterpart in OMAP McBSP driver before
to apply it. The required changes in McBSP were sent and approved
in linux-omap mailing list and patch is going upstream
(commit 3127f8f859 from linux-omap-2.6
tree).
Signed-off-by: Misael Lopez Cruz <x0052729@ti.com>
[ jarkko.nikula@nokia.com: Commit id for counterpart patch corrected ]
Signed-off-by: Jarkko Nikula <jarkko.nikula@nokia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
X86_GENERICARCH is a misnomer - it contains non-PC 32-bit architectures
that are not included in the default build.
Rename it to X86_32_NON_STANDARD.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Move X86_VSMP out of the subarch menu - this way it can be enabled
together with standard PC support as well, in the same kernel.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
- make X86_GENERICARCH depend X86_NON_STANDARD
- move X86_SUMMIT, X86_ES7000 and X86_BIGSMP out of the subarchitecture
menu and under this option
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Move X86_ELAN (old, NCR hw platform built on Intel CPUs) from the
subarchitecture menu to the non-standard-platform section.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Move X86_ELAN (old, AMD based web-boxes) from the subarchitecture
menu to the non-standard-platform section.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Voyager has this ISA quirk (because Voyager has no ISA support):
config ISA
bool "ISA support"
depends on !X86_VOYAGER
There's a ton of x86 hardware that does not support ISA, and because
most ISA drivers cannot auto-detect in a safe way, the convention in
the kernel has always been to not enable ISA drivers if they are not
needed.
Voyager users can do likewise - no need for a Kconfig quirk.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Voyager has this PM/ACPI Kconfig quirk:
menu "Power management and ACPI options"
depends on !X86_VOYAGER
Most of the PM features are auto-detect so they should be safe to run
on just about any hardware. (If not, those instances need fixing.)
In any case, if a kernel is built for Voyager, the power management
options can be disabled.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Voyager has this Kconfig quirk:
config HOTPLUG_CPU
bool "Support for hot-pluggable CPUs"
depends on SMP && HOTPLUG && !X86_VOYAGER
But this exception will be moot once Voyager starts using the
generic x86 code.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
If no MCE code is desired on Voyager hw then the solution
is to turn them off in the .config - and to extend the MCE
code to not initialize on Voyager.
Remove the build-time quirk.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
The lapic/ioapic code properly auto-detects and is safe to run on CPUs that
have no local APIC. (or which have their lapic turned off in the hardware)
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Remove this Kconfig quirk:
config PARAVIRT
bool "Enable paravirtualization code"
depends on !X86_VOYAGER
help
Voyager support built into a kernel does not preclude paravirt support.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Voyager has this quirk currently:
config KVM_GUEST
bool "KVM Guest support"
select PARAVIRT
depends on !X86_VOYAGER
Voyager support built into a kernel image does not exclude
KVM paravirt guest support - so remove this quirk.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Voyager has this build-time quirk to exclude KVM_CLOCK:
bool "KVM paravirtualized clock"
select PARAVIRT
select PARAVIRT_CLOCK
depends on !X86_VOYAGER
Voyager support built into a kernel image does not exclude
KVM paravirt clock support - so remove this quirk.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
x86/Voyager has this build-time quirk:
bool "VMI Guest support"
select PARAVIRT
depends on X86_32
depends on !X86_VOYAGER
Since VMI is auto-detected (and Voyager will be auto-detected) there's no
reason for this quirk.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
x86/Voyager had this Kconfig quirk:
config X86_FIND_SMP_CONFIG
def_bool y
depends on X86_MPPARSE || X86_VOYAGER
Which splits off the find_smp_config() callback into a build-time quirk.
Voyager should use the existing x86_quirks.mach_find_smp_config() callback
to introduce SMP-config quirks. NUMAQ-32 and VISWS already use this.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
