The driver uses "u32" for alignment check and calculation which
works only on 32-bit system. It will crash the 64-bit system.
Replace "u32" with "unsigned long" to fix this issue.
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The Marvell Bluetooth driver is full of Enter/Leave debug statements and
all of them are really pointless and only clutter the code. Seems to be
some left-overs when they ported the driver from Windows. For the Linux
driver lets remove these.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
After fixing the driver to use skb_put properly for their HCI commands
only a few compiler warnings are left. Add proper casting for them.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The Marvell driver has some weird quirks on how to construct proper SKBs
with Bluetooth HCI commands. Fix it to use skb_put properly and also
use hci_opcode_pack instead of self-crafted macro.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
For some reason the btmrvl_device struct has a name field that the SDIO
fills in, but then never ever uses again. That is totally pointless and
so just remove it.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Make the module description entries for the core and also the Marvell
SDIO driver match common practive inside the Bluetooth subsystem.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The Marvell Bluetooth SDIO driver has a really complicated concept on how
firmware names are assigned to specific device ids. Fix that by doing a
proper structure and assign it to the module device table.
And while at it fix various coding style weirdness that is still present
in this driver.
Signed-off-by: Marcel Holtman <marcel@holtmann.org>
The Marvell core Bluetooth driver has various weird casting and unneeded
braces in its code that makes it hard to read. Remove all of these to
make the code a little bit simpler.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The Marvell Bluetooth driver has debugfs support and they are casting
like there is no tomorrow. Remove all of them and magically the code
becomes more readable.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Both header files of the Marvell Bluetooth driver are private anyway and
if the driver happens to include them twice or they create a circular
dependency then the driver needs fixing. So just remove both pointless
ifdefs.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The Makefile entry for the Marvell driver is broken when it comes to
handling the optional DEBUG_FS correctly. That must have been the reason
why they were using select in Kconfig in the first place. Fix this and
make it really optional.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The Marvell driver selects DEBUG_FS and FW_LOADER for its core driver
and that is pointless. Don't select DEBUG_FS since it is either enabled
or not and it is not for the driver to enable it. Also FW_LOADER is
only used within the SDIO driver and so just have that one select the
FW_LOADER option.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
add btmrvl.txt to Documentation/
This patch incorporates a lot of comments given by
Nicolas Pitre <nico@marvell.com>. Many thanks to Nicolas Pitre.
Signed-off-by: Rahul Tank <rahult@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
/debug/btmrvl/config/
/debug/btmrvl/status/
See Documentation/btmrvl.txt for details.
This patch incorporates a lot of comments given by
Nicolas Pitre <nico@marvell.com>. Many thanks to Nicolas Pitre.
Signed-off-by: Rahul Tank <rahult@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
This driver supports Marvell Bluetooth enabled devices with SDIO
interface. Currently only SD8688 chip is supported.
The helper/firmware images of SD8688 can be downloaded from this tree:
git://git.infradead.org/users/dwmw2/linux-firmware.git
This patch incorporates a lot of comments given by
Nicolas Pitre <nico@marvell.com>. Many thanks to Nicolas Pitre.
Signed-off-by: Rahul Tank <rahult@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
This driver provides basic definitions and library functions to
support Marvell Bluetooth enabled devices, such as 88W8688 WLAN/BT
combo chip.
This patch incorporates a lot of comments given by
Nicolas Pitre <nico@marvell.com>. Many thanks to Nicolas Pitre.
Signed-off-by: Rahul Tank <rahult@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The core exports the hci_conn_hold_device() and hci_conn_put_device()
functions for device reference of connections. Use this to ensure that
the uevents from the parent are send after the child ones.
Based on a report by Brian Rogers <brian@xyzw.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The device model itself has no real usable reference counting at the
moment and this causes problems if parents are deleted before their
children. The device model itself handles the memory details of this
correctly, but the uevent order is not consistent. This causes various
problems for systems like HAL or even X.
So until device_put() does a proper cleanup, the device for Bluetooth
connection will be protected with an extra reference counting to ensure
the correct order of uevents when connections are terminated.
This is not an automatic feature. Higher Bluetooth layers like HIDP or
BNEP should grab this new reference to ensure that their uevents are
send before the ones from the parent device.
Based on a report by Brian Rogers <brian@xyzw.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Currently the HID subsystem will create HIDRAW devices for the transport
driver, but it will not disconnect them. Until the HID subsytem gets
fixed, ensure that HIDRAW and HIDDEV devices are disconnected when the
Bluetooth HID device gets removed.
Based on a patch from Brian Rogers <brian@xyzw.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
This patch increases the receive buffer size to HCI_MAX_FRAME_SIZE
which improves the RX throughput considerably.
Tested against BRM/Atheros/CSR USB Dongles with PAN profile using
iperf and chariot. This gave significant (around 40%) increase
in performance (increased from 0.8 to 1.5 Mb/s in Sheld room)
Signed-off-by: Vikram Kandukuri <vikram.kandukuri@atheros.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
There is a test case in PTS tool; PTS will send the VIRTUAL_CABLE_UNPLUG
command to IUT. Then IUT should disconnect the channel and kill the HID
session when it receives the command. The VIRTUAL_CABLE_UNPLUG command
is parsed by HID transport, but it is not scheduled to do so. Add a
call to hidp_schedule() to kill the session.
Signed-off-by: Jothikumar Mothilal <jothikumar.mothilal@atheros.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The SCO sockets for Bluetooth audio setup and streaming are missing the
shutdown implementation. This hasn't been a problem so far, but with a
more deeper integration with PulseAudio it is important to shutdown SCO
sockets properly.
Also the Headset profile 1.2 has more detailed qualification tests that
require that SCO and RFCOMM channels are terminated in the right order. A
proper shutdown function is necessary for this.
Based on a report by Johan Hedberg <johan.hedberg@nokia.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Tested-by: Johan Hedberg <johan.hedberg@nokia.com>
* git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6:
[SCSI] mpt2sas: fix config request and diag reset deadlock
[SCSI] mpt2sas: Bump driver version 01.100.04.00
[SCSI] mpt2sas: fix oops because drv data points to NULL on resume from hibernate
[SCSI] mpt2sas: fix crash due to Watchdog is active while OS in standby mode
[SCSI] mpt2sas: fix infinite loop inside config request
[SCSI] mpt2sas: Excessive log info causes sas iounit page time out
[SCSI] mpt2sas: Raid 10 Value is showing as Raid 1E in /va/log/messages
[SCSI] mpt2sas: Expander fix oops saying "Already part of another port"
[SCSI] mpt2sas: Introduced check for enclosure_handle to avoid crash
The CIE and FDE structs are big enough and accessed regularly enough in
certain configurations to make cacheline alignment useful.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
This patch adds 'const' qualifier to UBIFS xattr inode and file
operations.
Pointed-out-by: Julia Lawall <julia@diku.dk>
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
In commit a8e7d49aa7 ("Fix race in
create_empty_buffers() vs __set_page_dirty_buffers()"), I removed a test
for a NULL page mapping unintentionally when some of the code inside
__set_page_dirty() was moved to the callers.
That removal generally didn't matter, since a filesystem would serialize
truncation (which clears the page mapping) against writing (which marks
the buffer dirty), so locking at a higher level (either per-page or an
inode at a time) should mean that the buffer page would be stable. And
indeed, nothing bad seemed to happen.
Except it turns out that apparently reiserfs does something odd when
under load and writing out the journal, and we have a number of bugzilla
entries that look similar:
http://bugzilla.kernel.org/show_bug.cgi?id=13556http://bugzilla.kernel.org/show_bug.cgi?id=13756http://bugzilla.kernel.org/show_bug.cgi?id=13876
and it looks like reiserfs depended on that check (the common theme
seems to be "data=journal", and a journal writeback during a truncate).
I suspect reiserfs should have some additional locking, but in the
meantime this should get us back to the pre-2.6.29 behavior.
Pattern-pointed-out-by: Roland Kletzing <devzero@web.de>
Cc: stable@kernel.org (2.6.29 and 2.6.30)
Cc: Jeff Mahoney <jeffm@suse.com>
Cc: Nick Piggin <npiggin@suse.de>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
mtr_aps_delayed_init was declared u32 and made global, but it only
ever takes boolean values and is only ever used in
arch/x86/kernel/cpu/mtrr/main.c. Declare it "static bool" and remove
external references.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Cc: Suresh Siddha <suresh.b.siddha@intel.com>
SDM Vol 3a section titled "MTRR considerations in MP systems" specifies
the need for synchronizing the logical cpu's while initializing/updating
MTRR.
Currently Linux kernel does the synchronization of all cpu's only when
a single MTRR register is programmed/updated. During an AP online
(during boot/cpu-online/resume) where we initialize all the MTRR/PAT registers,
we don't follow this synchronization algorithm.
This can lead to scenarios where during a dynamic cpu online, that logical cpu
is initializing MTRR/PAT with cache disabled (cr0.cd=1) etc while other logical
HT sibling continue to run (also with cache disabled because of cr0.cd=1
on its sibling).
Starting from Westmere, VMX transitions with cr0.cd=1 don't work properly
(because of some VMX performance optimizations) and the above scenario
(with one logical cpu doing VMX activity and another logical cpu coming online)
can result in system crash.
Fix the MTRR initialization by doing rendezvous of all the cpus. During
boot and resume, we delay the MTRR/PAT init for APs till all the
logical cpu's come online and the rendezvous process at the end of AP's bringup,
will initialize the MTRR/PAT for all AP's.
For dynamic single cpu online, we synchronize all the logical cpus and
do the MTRR/PAT init on the AP that is coming online.
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Because of deadlock possiblities smp_call_function() is not allowed to
be called with interrupts disabled. Add an exception for the cpu not
yet online, as no one else can send smp call function interrupt to this
cpu that is not yet online and as such deadlock condition is not possible.
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Acked-by: Nick Piggin <npiggin@suse.de>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Some of the NOPs tables aren't used on 64-bits, quite some code and
data is needed post-init for module loading only, and a couple of
functions aren't used outside that file (i.e. can be static, and don't
need to be exported).
The change to __INITDATA/__INITRODATA is needed to avoid an assembler
warning.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
LKML-Reference: <4A8BC8A00200007800010823@vpn.id2.novell.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
sh64 does not yet support GENERIC_BUG, but still wants unwinder support.
Alias UNWINDER_BUG and UNWINDER_BUG_ON to their BUG counterparts until
the conversion to GENERIC_BUG is completed.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
This simplifies the unwinder trap handling, dropping the use of the
special trapa vector and simply piggybacking on top of the BUG support. A
new BUGFLAG_UNWINDER is added for flagging the unwinder fault, before
continuing on with regular BUG dispatch.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
After talking with some application writers who want very fast, but not
fine-grained timestamps, I decided to try to implement new clock_ids
to clock_gettime(): CLOCK_REALTIME_COARSE and CLOCK_MONOTONIC_COARSE
which returns the time at the last tick. This is very fast as we don't
have to access any hardware (which can be very painful if you're using
something like the acpi_pm clocksource), and we can even use the vdso
clock_gettime() method to avoid the syscall. The only trade off is you
only get low-res tick grained time resolution.
This isn't a new idea, I know Ingo has a patch in the -rt tree that made
the vsyscall gettimeofday() return coarse grained time when the
vsyscall64 sysctrl was set to 2. However this affects all applications
on a system.
With this method, applications can choose the proper speed/granularity
trade-off for themselves.
Signed-off-by: John Stultz <johnstul@us.ibm.com>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: nikolag@ca.ibm.com
Cc: Darren Hart <dvhltc@us.ibm.com>
Cc: arjan@infradead.org
Cc: jonathan@jonmasters.org
LKML-Reference: <1250734414.6897.5.camel@localhost.localdomain>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
This basically reverts commit 1a0c009ac (x86: unregister PIT
clocksource when PIT is disabled) because the problem which was tried
to address with that patch has been solved by commit 3f68535ada
(clocksource: sanity check sysfs clocksource changes).
The problem addressed by the original patch is that PIT could be
selected as clocksource after the system switched the PIT off or set
the PIT into one shot mode which would result in complete timekeeping
wreckage.
Now with the sysfs sanity check in place PIT cannot be selected again
when the system is in oneshot mode. The system will not switch to one
shot mode as long as PIT is installed because PIT is not suitable for
one shot.
The shutdown case which happens when the lapic timer is installed is
covered by the fact that init_pit_clocksource() is called after the
lapic timer take over and then does not install the PIT clocksource
at all.
We should have done the sanity checks back then, but ...
This also solves the locking problem which was reported vs. the
clocksource rework.
LKML-Reference: <new-submission>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: john stultz <johnstul@us.ibm.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
If the oprofile code is built as a module, unwind_stack() as used by the
oprofile backtrace code is not available, causing build breakage.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
* 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6:
drm/radeon: add GET_PARAM/INFO support for Z pipes
drm/radeon/kms: add r100/r200 OQ support.
drm: Fix sysfs device confusion.
drm/radeon/kms: implement the bo busy ioctl properly.
As noted in 83d349f35e ("x86: don't send
an IPI to the empty set of CPU's"), some APIC's will be very unhappy
with an empty destination mask. That commit added a WARN_ON() for that
case, and avoided the resulting problem, but didn't fix the underlying
reason for why those empty mask cases happened.
This fixes that, by checking the result of 'cpumask_andnot()' of the
current CPU actually has any other CPU's left in the set of CPU's to be
sent a TLB flush, and not calling down to the IPI code if the mask is
empty.
The reason this started happening at all is that we started passing just
the CPU mask pointers around in commit 4595f9620 ("x86: change
flush_tlb_others to take a const struct cpumask"), and when we did that,
the cpumask was no longer thread-local.
Before that commit, flush_tlb_mm() used to create it's own copy of
'mm->cpu_vm_mask' and pass that copy down to the low-level flush
routines after having tested that it was not empty. But after changing
it to just pass down the CPU mask pointer, the lower level TLB flush
routines would now get a pointer to that 'mm->cpu_vm_mask', and that
could still change - and become empty - after the test due to other
CPU's having flushed their own TLB's.
See
http://bugzilla.kernel.org/show_bug.cgi?id=13933
for details.
Tested-by: Thomas Björnell <thomas.bjornell@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
RTL8187B always needs MSR_LINK_ENEDCA flag to be set even when it is in
no link mode, otherwise it'll not be able to associate when this flag is
not set after the change "mac80211: fix managed mode BSSID handling".
By accident, setting BSSID of AP before association makes 8187B to
successfuly associate even when ENEDCA flag isn't set, which was the
case before the mac80211 change. But now the BSSID of AP we are trying
to associate is only available after association is successful, and
any attempt to associate without the needed flag doesn't work.
Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
Acked-by: Hin-Tak Leung <htl10@users.sourceforge.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There's a dependency missing.
$ make localyesconfig
HOSTCC scripts/basic/fixdep
HOSTCC scripts/basic/docproc
HOSTCC scripts/basic/hash
using config: '/boot/config-2.6.27.25-78.2.56.fc9.x86_64'
/bin/sh: line 8: scripts/kconfig/conf: No such file or directory
make[1]: *** [localyesconfig] Error 127
make: *** [localyesconfig] Error 2
Thus the script failed to run. But the sed command that converts the '=m'
to '=y' still ran. This gives us a distro config with all modules
converted to built in!
The missing dependency was for conf for localyesconfig. This
dependency was already set for localmodconfig.
Reported-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
When 'and'ing two bitmasks (where 'andnot' is a variation on it), some
cases want to know whether the result is the empty set or not. In
particular, the TLB IPI sending code wants to do cpumask operations and
determine if there are any CPU's left in the final set.
So this just makes the bitmask (and cpumask) functions return a boolean
for whether the result has any bits set.
Cc: stable@kernel.org (2.6.30, needed by TLB shootdown fix)
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The default_send_IPI_mask_logical() function uses the "flat" APIC mode
to send an IPI to a set of CPU's at once, but if that set happens to be
empty, some older local APIC's will apparently be rather unhappy. So
just warn if a caller gives us an empty mask, and ignore it.
This fixes a regression in 2.6.30.x, due to commit 4595f9620 ("x86:
change flush_tlb_others to take a const struct cpumask"), documented
here:
http://bugzilla.kernel.org/show_bug.cgi?id=13933
which causes a silent lock-up. It only seems to happen on PPro, P2, P3
and Athlon XP cores. Most developers sadly (or not so sadly, if you're
a developer..) have more modern CPU's. Also, on x86-64 we don't use the
flat APIC mode, so it would never trigger there even if the APIC didn't
like sending an empty IPI mask.
Reported-by: Pavel Vilim <wylda@volny.cz>
Reported-and-tested-by: Thomas Björnell <thomas.bjornell@gmail.com>
Reported-and-tested-by: Martin Rogge <marogge@onlinehome.de>
Cc: Mike Travis <travis@sgi.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Currently when built with DEBUG DAPM will dump information about
the power state decisions it is taking for each widget to dmesg.
This isn't an ideal way of getting the information - it requires
a kernel build to turn it on and off and for large hub CODECs the
volume of information is so large as to be illegible. When the
output goes to the console it can also cause a noticable impact
on performance simply to print it out.
Improve the situation by adding a dapm directory to our debugfs
tree containing a file per widget with the same information in
it. This still requires a decision to build with debugfs support
but is easier to navigate and much less intrusive.
In addition to the previously displayed information active streams
are also shown in these files.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
