We should not zero out the multicast hash when configuring
the operating mode, since a zero value means all multicast
frames will get dropped. Also, ath5k_mode_setup() gets
called after any reset, so the hash already set up in
configure_filter() is lost.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Although I have always been the active maintainer of the rt2x00 drivers,
I was not mentioned explicitely in the MAINTAINERS file as such.
Update the rt2x00 entry in the MAINTAINERS file to add my name and
email address.
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
ops->set_tim() must be atomic, so b43 trying to acquire a mutex leads
to a kernel crash. This patch trades an easy to trigger crash in AP
mode for an unlikely race condition. According to Michael, the real
fix would be to allow set_tim() to sleep, since b43 is not the only
driver that needs to sleep in all callbacks.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The scan function was using 32 bit access which does not
work on 16bit CF cards.
This patch corrects this by doing two 16 bit reads like
ssb_pcmcia_read32 already does.
mb -- Removed locking. That early in init there's no need for locking.
Signed-off-by: Martin Fuzzey <mfuzzey@gmail.com>
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
From the code in rt_mutex_setprio(), it is evident that the
intention is that task's with a RT 'prio' value as a consequence
of receiving a PI boost also have their 'sched_class' field set
to '&rt_sched_class'.
However, Peter noticed that the code in __setscheduler() could
result in this intention being frustrated. Fix it.
Reported-by: Peter Williams <pwil3058@bigpond.net.au>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Mike Galbraith <efault@gmx.de>
LKML-Reference: <1257880321.4108.457.camel@laptop>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
The latest rev of Intel doc AP-485 details new cache descriptors
that we don't yet support. 12MB, 18MB and 24MB 24-way assoc L3
caches.
Signed-off-by: Dave Jones <davej@redhat.com>
LKML-Reference: <20091110184924.GA20337@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
This patch makes output of perf bench more friendly.
Current style of putput, keeping user wait
and printing everything suddenly when we finish,
may confuse users.
So I improved it:
| % perf bench sched messaging
| # Running sched/messaging benchmark... <- printed right after invocation
| # 20 sender and receiver processes per group
| # 10 groups == 400 processes run
|
| Total time: 1.476 [sec]
Signed-off-by: Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1257865442-20252-2-git-send-email-mitake@dcl.info.waseda.ac.jp>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Record the pid of the task that opened a RawMIDI substream.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Record the pid of the task that opened a PCM substream. For sound
cards with hardware mixing, this allows determining which process
is associated with a specific substream's volume control.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The substream_opened field is to count the number of opened substreams,
not the number of times that any substreams have been opened.
Furthermore, all substreams being opened does not imply that the next
open would fail, due to the possibility of O_APPEND. With this wrong
check, opening a substream multiple times would succeed only if the
device had more unopened substreams.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Commit 9a1b64caac in 2.6.30 broke the
error handling code in rawmidi_open_priv().
If only the output substream of a RawMIDI device has been opened and
if this device is then opened with O_RDWR | O_APPEND and if the
initialization of the input substream fails (either because of low
memory or because the device driver's open callback fails), then the
runtime structure of the already open output substream will be freed
and all following writes through the first handle will cause
snd_rawmidi_write() to use the NULL runtime pointer.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Cc: <stable@kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Commit 9a1b64caac in 2.6.30 dropped the
check that a substream must already have been opened with O_APPEND to be
able to open it a second time.
This would make it possible for a substream to be switched to append
mode, which would mean that non-atomic writes would fail unexpectedly.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Cc: <stable@kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Commit 9a1b64caac in 2.6.30 moved the
substream initialization code to where it would be executed every time
the substream is opened.
This had the consequence that any further opening would drop and leak
the data in the existing buffer, and that the device driver's open
callback would be called multiple times, unexpectedly.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Cc: <stable@kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The present quirk for HP dc5750 seems broken and maps the pins wrongly.
Since the auto-parser works well for this device, set the default entry
to use model=auto.
Reference: Novell bnc#552154
https://bugzilla.novell.com/show_bug.cgi?id=552154
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Add reboot notifier to each codec so that it can do some workarounds
needed for reboot.
So far, patch_sigmatel.c calls its shutup routine for avoiding noises
at reboot on some HP machines.
References: Novell bnc#544779
http://bugzilla.novell.com/show_bug.cgi?id=544779
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This patch modifies command-list.txt for the entry of
perf-bench. So perf will show 'bench' in command list.
Example:
% perf
usage: perf [--version] [--help] COMMAND [ARGS]
The most commonly used perf commands are:
annotate Read perf.data (created by perf record) and display annotated code
bench General framework for benchmark suites
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
list List all symbolic event types
probe Define new dynamic tracepoints
record Run a command and record its profile into perf.data
report Read perf.data (created by perf record) and display the profile
sched Tool to trace/measure scheduler properties (latencies)
stat Run a command and gather performance counter statistics
timechart Tool to visualize total system behavior during a workload
top System profiling tool.
trace Read perf.data (created by perf record) and display trace output
See 'perf help COMMAND' for more information on a specific command.
Signed-off-by: Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
LKML-Reference: <1257853855-28934-4-git-send-email-mitake@dcl.info.waseda.ac.jp>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
APLL_CTL register is configured by the twl4030-codec MFD
driver.
Remove code, which makes changes in the APLL_CTL register,
and replace those with checks against the configured
audio_mclk configuration done in the MFD driver.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@nokia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Configure the APLL_INFREQ field in the APLL_CTL register
based on the platform data.
Provide also a function for childs to query the audio_mclk
frequency.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@nokia.com>
Acked-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
audio_mclk value is going to be handled by the
twl4030-codec MFD driver, configure the correct
value for boards, which is using the twl4030 audio.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@nokia.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
If HW IOMMU initialization fails (Intel VT-d often does this,
typically due to BIOS bugs), we fall back to nommu. It doesn't
work for the majority since nowadays we have more than 4GB
memory so we must use swiotlb instead of nommu.
The problem is that it's too late to initialize swiotlb when HW
IOMMU initialization fails. We need to allocate swiotlb memory
earlier from bootmem allocator. Chris explained the issue in
detail:
http://marc.info/?l=linux-kernel&m=125657444317079&w=2
The current x86 IOMMU initialization sequence is too complicated
and handling the above issue makes it more hacky.
This patch changes x86 IOMMU initialization sequence to handle
the above issue cleanly.
The new x86 IOMMU initialization sequence are:
1. we initialize the swiotlb (and setting swiotlb to 1) in the case
of (max_pfn > MAX_DMA32_PFN && !no_iommu). dma_ops is set to
swiotlb_dma_ops or nommu_dma_ops. if swiotlb usage is forced by
the boot option, we finish here.
2. we call the detection functions of all the IOMMUs
3. the detection function sets x86_init.iommu.iommu_init to the
IOMMU initialization function (so we can avoid calling the
initialization functions of all the IOMMUs needlessly).
4. if the IOMMU initialization function doesn't need to swiotlb
then sets swiotlb to zero (e.g. the initialization is
sucessful).
5. if we find that swiotlb is set to zero, we free swiotlb
resource.
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: chrisw@sous-sol.org
Cc: dwmw2@infradead.org
Cc: joerg.roedel@amd.com
Cc: muli@il.ibm.com
LKML-Reference: <1257849980-22640-10-git-send-email-fujita.tomonori@lab.ntt.co.jp>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
There is no point in warning when there is no ucode available
for a specific CPU revision. Currently the container-file, which
provides the AMD ucode patches for OS load, contains only a few
ucode patches.
It's already clearly indicated by the printed patch_level
whenever new ucode was available and an update happened. So the
warning message is of no help but rather annoying on systems
with many CPUs.
Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com>
Cc: dimm <dmitry.adamushko@gmail.com>
LKML-Reference: <20091110110825.GI30802@alberich.amd.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
While SSDs track block usage on a per-sector basis, RAID arrays often
have allocation blocks that are bigger. Allow the discard granularity
and alignment to be set and teach the topology stacking logic how to
handle them.
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
Wrap in the cpu dr7 check that tells if we have active
breakpoints that need to be restored in the cpu.
This wrapper makes the check more self-explainable and also
reusable for any further other uses.
Reported-by: Jan Kiszka <jan.kiszka@web.de>
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Avi Kivity <avi@redhat.com>
Cc: "K. Prasad" <prasad@linux.vnet.ibm.com>
The hw-breakpoint sample module has been broken during the
hw-breakpoint internals refactoring. Propagate the changes
to it.
Reported-by: "K. Prasad" <prasad@linux.vnet.ibm.com>
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
