IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The PCM rates bit field may have been changed by the codec open callback.
In that case, we need to reset rate_min and rate_max. So, simply call
snd_pcm_lib_hw_rates() again after the codec open callback.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Check whether formats and rates don't result in zero due to the
restriction of SPDIF sharing. If any of them can be zero, disable
the SPDIF sharing mode instead. Otherwise it will lead to a PCM
configuration error.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Block layer used to merge requests and bios with different failfast
settings. This caused regular IOs to fail prematurely when they were
merged into failfast requests for readahead.
Niel Lambrechts could trigger the problem semi-reliably on ext4 when
resuming from STR. ext4 uses readahead when reading inodes and
combined with the deterministic extra SATA PHY exception cycle during
resume on the specific configuration, non-readahead inode read would
fail causing ext4 errors. Please read the following thread for
details.
http://lkml.org/lkml/2009/5/23/21
This patch makes block layer reject merging if the failfast settings
don't match. This is correct but likely to lower IO performance by
preventing regular IOs from mingling into surrounding readahead
requests. Changes to allow such mixed merges and handle errors
correctly will be added later.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Niel Lambrechts <niel.lambrechts@gmail.com>
Cc: Theodore Tso <tytso@mit.edu>
Signed-off-by: Jens Axboe <axboe@carl.(none)>
When doing an unexpected shutdown like kexec the cciss
firmware might still have some commands in flight, which
it is trying to complete.
The driver is doing it's best on resetting the HBA,
but sadly there's a firmware issue causing the firmware
_not_ to abort or drop old commands.
So the firmware will send us commands which we haven't
accounted for, causing the driver to panic.
With this patch we're just ignoring these commands as
there is nothing we could be doing with them anyway.
Signed-off-by: Hannes Reinecke <hare@suse.de>
Acked-by: Mike Miller <mike.miller@hp.com>
Signed-off-by: Jens Axboe <axboe@carl.(none)>
For systems which do not define PHYS_OFFSET as 0 pfn_valid() may falsely
have returned 0 on most configurations. Bug introduced by commit
752fbeb2e3555c0d236e992f1195fd7ce30e728d (linux-mips.org) rsp.
6f284a2ce7 (kernel.org) titled "[MIPS]
FLATMEM: introduce PHYS_OFFSET."
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Move the cavium PCI files to the arch/mips/pci directory. Also cleanup
comment formatting and code layout. Code from pci-common.c, was moved
into other files.
Signed-off-by: David Daney <ddaney@caviumnetworks.com>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
If an o32 process generates a core dump on a 64 bit kernel, the core file
will not be correctly recognized. This is because ELF_CORE_COPY_REGS and
ELF_CORE_COPY_TASK_REGS are not correctly defined for o32 and will use
the default register set which would be CONFIG_64BIT in asm/elf.h.
So we'll switch to use the right register defines in this situation by
checking for WANT_COMPAT_REG_H and use the right defines of
ELF_CORE_COPY_REGS and ELF_CORE_COPY_TASK_REGS.
[Ralf: made ELF_CORE_COPY_TASK_REGS() bullet-proof against funny arguments.]
Signed-off-by: Yong Zhang <yong.zhang@windriver.com>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The current ssb irq setup in ssb_mipscore_init has the problem that it
configures some device on some irq without checking that the irq is not
taken by an other device.
For example in my case PCI host is on irq 0 and IPSEC on irq 3.
The current code:
- store in dev->irq that IPSEC irq is 3 + 2
- do a set_irq 0->3 on PCI host
But now IPSEC irq is not routed anymore to the mips code and dev->irq is
wrong. This causes a problem described in [1].
This patch tries to solve the problem by making set_irq configure the
device we want to take the irq on the shared irq0. The previous example
becomes:
- store in dev->irq that IPSEC irq is 3 + 2
- do a set_irq 0->3 on PCI host:
- irq 3 is already taken by IPSEC. do a set_irq 3->0 on IPSEC
I also added some code to print the irq configuration after irq setup to
allow easier debugging. And I add extra checking in ssb_mips_irq to report
device without irq or device with not routed irq.
[1] http://www.danm.de/files/src/bcm5365p/REPORTED_DEVICES
Signed-off-by: Matthieu CASTET <castet.matthieu@free.fr>
Acked-by : Michael Buesch <mb@bu3sch.de>
Tested-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
This revises the sync-4k so it will boot and operate since the removal of
expirelo from the timer code.
Signed-off-by: Tim Anderson <tanderson@mvista.com>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
This is to move the gcmp_probe call to before the use of and selection of
the smp_ops functions. This allows malta with 1004K to work.
Signed-off-by: Tim Anderson <tanderson@mvista.com>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Most of the CMP support was added before, this mostly correct compile
problems but adds a platform specific translation for the interrupt number
based on cpu number.
Signed-off-by: Tim Anderson <tanderson@mvista.com>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
This takes the current IPI interrupt assignment from the fix number of 4
to the number of CPUs defined in the system.
Signed-off-by: Tim Anderson <tanderson@mvista.com>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
This patch extends the GIC interrupt handling beyond the current 32 bit
range as well as extending the number of interrupts based on the number
of CPUs.
Signed-off-by: Tim Anderson <tanderson@mvista.com>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Some CPUs implement mipsr2, but because they are a super-set of mips64r2 do
not define CONFIG_CPU_MIPS64_R2. Cavium OCTEON falls into this category.
We would still like to use the optimized implementation, so since we have
already checked for CONFIG_CPU_MIPSR2, checking for CONFIG_64BIT instead of
CONFIG_CPU_MIPS64_R2 is sufficient.
Signed-off-by: David Daney <ddaney@caviumnetworks.com>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
[Ralf: I fixed up the numbering in the comment in scall64-n32.S.]
Signed-off-by: David Daney <ddaney@caviumnetworks.com>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
This patch adds support for the Texas Instruments AR7 System-on-a-Chip.
It supports the TNETD7100, 7200 and 7300 versions of the SoC.
Signed-off-by: Matteo Croce <matteo@openwrt.org>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Eugene Konev <ejka@openwrt.org>
Signed-off-by: Nicolas Thill <nico@openwrt.org>
Signed-off-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
nfsd_open() gets an unrefcounted pointer to the current process's effective
credentials at the top of the function, then calls nfsd_setuser() via
fh_verify() - which may replace and destroy the current process's effective
credentials - and then passes the unrefcounted pointer to dentry_open() - but
the credentials may have been destroyed by this point.
Instead, the value from current_cred() should be passed directly to
dentry_open() as one of its arguments, rather than being cached in a variable.
Possibly fh_verify() should return the creds to use.
This is a regression introduced by
745ca2475a "CRED: Pass credentials through
dentry_open()".
Signed-off-by: David Howells <dhowells@redhat.com>
Tested-and-Verified-By: Steve Dickson <steved@redhat.com>
Cc: stable@kernel.org
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
The mixer elements created for ASUS eeePC 1000 with ALC269 aren't
standard but strange words like "LineOut". Rename the element names
to follow the standard one like "Headphone" and "Speaker".
Also, split the volumes to each so that the virtual master can control
them.
The alc269_fujitsu_mixer is removed because it's now identical with
the new eeepc mixer.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
HP laptops with AD1984A codecs (at least mobile models) need to set
GPIO1 appropriately to indicate the mute state. The BIOS checks this
bit to judge whether the mute on or off is sent via F8 key.
Without changing this bit, the BIOS can be confused and may toggle
the mute wrongly.
Reference: Novell bnc#515266
https://bugzilla.novell.com/show_bug.cgi?id=515266
Signed-off-by: Takashi Iwai <tiwai@suse.de>
lapic_watchdog_ok() is a global function but no one is using it.
Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Yinghai Lu <yinghai@kernel.org>
LKML-Reference: <1246554335.2242.29.camel@jaswinder.satnam>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
setup_nox2apic() is writing 1 to disable_x2apic but no one is reading it.
Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Cyrill Gorcunov <gorcunov@gmail.com>
LKML-Reference: <1246554239.2242.27.camel@jaswinder.satnam>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
The function paravirt_ops_setup() has been refering the
variable no_timer_check, which is a __initdata. Thus generates
the following warning. paravirt_ops_setup() function is called
from kvm_guest_init() which is a __init function. So to fix
this we mark paravirt_ops_setup as __init.
The sections-check output that warned us about this was:
LD arch/x86/built-in.o
WARNING: arch/x86/built-in.o(.text+0x166ce): Section mismatch in
reference from the function paravirt_ops_setup() to the variable
.init.data:no_timer_check
The function paravirt_ops_setup() references
the variable __initdata no_timer_check.
This is often because paravirt_ops_setup lacks a __initdata
annotation or the annotation of no_timer_check is wrong.
Signed-off-by: Rakib Mullick <rakib.mullick@gmail.com>
Acked-by: Avi Kivity <avi@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
LKML-Reference: <b9df5fa10907012240y356427b8ta4bd07f0efc6a049@mail.gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
While examining symbol generation in perf_counter tools, I
noticed that copy_to_user() had no size in vmlinux's symtab.
Signed-off-by: Mike Galbraith <efault@gmx.de>
Acked-by: Alexander van Heukelum <heukelum@fastmail.fm>
Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
LKML-Reference: <1246512440.13293.3.camel@marge.simson.net>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Masami reported:
> Since the fixmap pages are assigned higher address to lower,
> text_poke() has to use it with inverted order (FIX_TEXT_POKE1
> to FIX_TEXT_POKE0).
I prefer to just invert the order of the fixmap declaration.
It's simpler and more straightforward.
Backward fixmaps seems to be used by both x86 32 and 64.
It's really rare but a nasty bug, because it only hurts when
instructions to patch are crossing a page boundary. If this
happens, the fixmap write accesses will spill on the following
fixmap, which may very well crash the system. And this does not
crash the system, it could leave illegal instructions in place.
Thanks Masami for finding this.
It seems to have crept into the 2.6.30-rc series, so this calls
for a -stable inclusion.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Acked-by: Masami Hiramatsu <mhiramat@redhat.com>
Cc: <stable@kernel.org>
LKML-Reference: <20090701213722.GH19926@Krystal>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
This patch updates the receive error code for muxed
interrupts in the sh-sci driver.
Receive error interrupts may be generated by the hardware
if RE or REIE bits in SCSCR are set. Update the muxed
interrupt handling code to acknowledge error interrupts
if RE or REIE is set, instead of only acknowledging if
REIE is set.
Without this patch error interrupts may be generated but
never acked resulting in a "nobody cared" crash.
Signed-off-by: Magnus Damm <damm@igel.co.jp>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Somewhat redundant since our atomic_t uses hashed-locks on 32-bit
anyway... Maybe we can clean those up to be generic too someday.
Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
Usage of parport_pc_probe_port was changed in 28783eb52
(parport: Fix various uses of parport_pc).
It introduced this build error:
drivers/parisc/superio.c: In function 'superio_parport_init':
drivers/parisc/superio.c:437: error: too few arguments to function
'parport_pc_probe_port'
Fix it.
Signed-off-by: Alexander Beregalov <a.beregalov@gmail.com>
Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
We weren't marking the resources as memory resources, so they weren't
being found by pci_claim_resource().
Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
Reviewed-by: Grant Grundler <grundler@parisc-linux.org>
Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
arch/parisc/mm/init.c: In function 'free_initmem':
381: warning: passing argument 1 of 'memset' makes pointer from integer without a cast
Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
The TLB flushing functions on hppa, which causes PxTLB broadcasts on the system
bus, needs to be protected by irq-safe spinlocks to avoid irq handlers to deadlock
the kernel. The deadlocks only happened during I/O intensive loads and triggered
pretty seldom, which is why this bug went so long unnoticed.
Signed-off-by: Helge Deller <deller@gmx.de>
[edited to use spin_lock_irqsave on UP as well since we'd been locking there
all this time anyway, --kyle]
Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
Rewrote timer_interrupt() to properly handle the "delayed!" case.
If we used floating point math to compute the number of ticks that had
elapsed since the last timer interrupt, it could take up to 12K cycles
(emperical!) to handle the interrupt. Existing code assumed it would
never take more than 8k cycles. We end up programming Interval Timer
to a value less than "current" cycle counter. Thus have to wait until
Interval Timer "wrapped" and would then get the "delayed!" printk that
I moved below.
Since we don't really know what the upper limit is, I prefer to read
CR16 again after we've programmed it to make sure we won't have to
wait for CR16 to wrap.
Further, the printk was between reading CR16 (cycle couner) and writing CR16
(the interval timer). This would cause us to continue to set the interval
timer to a value that was "behind" the cycle counter. Rinse and repeat.
So no printk's between reading CR16 and setting next interval timer.
Tested on A500 (550 Mhz PA8600).
Signed-off-by: Grant Grundler <grundler@parisc-linux.org>
Tested-by: Kyle McMartin <kyle@mcmartin.ca>
Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
----
Kyle, Helge, and other parisc's,
Please test on 32-bit before committing.
I think I have it right but recognize I might not.
TODO: I wanted to use "do_div()" in order to get both remainder
and value back with one division op. That should help with the
latency alot but can be applied seperately from this patch.
thanks,
grant
>>>> I think this is what was intended? Note that this patch may affect
>>>> profiling.
>>> it really should be
>>>
>>> - if (likely(t1 & (sizeof(unsigned int)-1)) == 0) {
>>> + if (likely((t1 & (sizeof(unsigned int)-1)) == 0)) {
>>>
>>> randolph
Reported-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: Randolph Chung <tausq@parisc-linux.org>
Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
gcc 4.4 warns about:
drivers/parisc/lba_pci.c: In function 'lba_pat_resources':
drivers/parisc/lba_pci.c:1099: warning: the frame size of 8280 bytes is larger than 4096 bytes
The problem is we declare two large structures on the stack. They don't need
to be on the stack since they are only used during LBA initialization (which
is serialized). Moving to be "static".
Signed-off-by: Grant Grundler <grundler@parisc-linux.org>
Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
