| Age | Commit message (Collapse) | Author |
|---|
|
When no RSSI value is available then make sure that the result is
filtered out when the RSSI threshold filter is active.
This means that all Bluetooth 1.1 or earlier devices will not
report any results when using a RSSI threshold filter.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
The mgmt.c file already has a bluetooth_base_uuid variable which has the
exact same value as the reverse_base_uuid one. This patch removes the
redundant variable.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
This patch fixes the Get Connection Information mgmt command to take
advantage of the new cmd_complete callback. This allows for great
simplifications in the logic for constructing the cmd_complete event.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
When we create the hci_conn object we should properly initialize the
RSSI to HCI_RSSI_INVALID.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
This patch converts the Get Clock Information mgmt command to take
advantage of the new cmd_complete callback for pending commands.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
This patch converts the Start/Stop Discovery mgmt commands to use the
cmd_complete callback of struct pending_cmd. Since both of these
commands return the same parameters as they take as input we can use the
existing generic_cmd_complete() helper for this.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
This patch updates the Unpair Device code to take advantage of the
cmd_complete callback of struct pending_cmd.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
This patch converts the Pair Device mgmt command to use the new
cmd_complete callback for pending mgmt commands. The already existing
pairing_complete() function is exactly what's needed and doesn't need
changing.
In addition to getting the return parameters always right this patch
actually fixes a reference counting bug and memory leak with the
hci_conn that's attached to the pending mgmt command - something that
would occur when powering off or unplugging the adapter while pairing is
in progress.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
This patch converts the user confirmation & PIN code mgmt commands to
take advantage of the new cmd_complete callback for pending mgmt
commands. The patch also adds a new generic addr_cmd_complete() helper
function to be used with commands that send a mgmt_addr_info response
based on a mgmt_addr_info in the beginning of the command parameters.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
This patch converts the Disconnect mgmt command to take advantage of the
new cmd_complete callback that's part of the pending_cmd struct. There
are many commands whose response parameters map 1:1 to the command
parameters and Disconnect is one of them. This patch adds a
generic_cmd_complete() function for such commands that can be reused in
subsequent patches.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
As preparation for making generic cmd_complete responses possible we'll
need to track the parameter length in addition to just a pointer to
them. This patch adds the necessary variable to the pending_cmd struct.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
We've got a couple of generic scenarios where all pending mgmt commands
are processed and responses are sent to them. These scenarios are
powering off the adapter and removing the adapter. So far the code has
been generating cmd_status responses with NOT_POWERED and INVALID_INDEX
resposes respectively, but this violates the mgmt specification for
commands that should always generate a cmd_complete.
This patch adds support for specifying a callback for the pending_cmd
context that each command handler can use for command-specific
cmd_complete event generation. The actual per-command event generators
will come in subsequent patches.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
Coding style cleanup.
Signed-off-by: Stefan Schmidt <s.schmidt@samsung.com>
Acked-by: Alexander Aring <alex.aring@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
Signed-off-by: Stefan Schmidt <s.schmidt@samsung.com>
Acked-by: Alexander Aring <alex.aring@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
Some have been missing and some have been needed. Just cosmetics.
Signed-off-by: Stefan Schmidt <s.schmidt@samsung.com>
Acked-by: Alexander Aring <alex.aring@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
Follow coding style of the kernel.
Signed-off-by: Stefan Schmidt <s.schmidt@samsung.com>
Acked-by: Alexander Aring <alex.aring@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
This might change and we already deliver a copy of the license with
the kernel. This was already removed form the ieee802154 code but
missed here.
Signed-off-by: Stefan Schmidt <s.schmidt@samsung.com>
Acked-by: Alexander Aring <alex.aring@gmail.com>
Acked-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
'regulator/topic/stub' into regulator-next
|
|
'regulator/topic/rpm', 'regulator/topic/rt5033', 'regulator/topic/s2mpa01' and 'regulator/topic/s2mps11' into regulator-next
|
|
'regulator/topic/max77693', 'regulator/topic/max77802', 'regulator/topic/power-off' and 'regulator/topic/rk808' into regulator-next
|
|
'regulator/topic/disable', 'regulator/topic/dummy' and 'regulator/topic/gpio' into regulator-next
|
|
|
|
|
|
Currently the discovery filter information are only cleared when the
actual discovery procedure has been stopped. To make sure that none
of the filters interfere with the background scanning and its device
found event reporting, clear the filter before starting background
scanning.
This means that the discovery filter is now cleared before either
Start Discovery, Start Service Discovery or background scanning.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
In case of failure or when unplugging a controller, the allocated
memory for the UUID list of the discovery filter is not freed. Use
the newly introduced helper for reset the discovery filter and with
that also freeing existing memory.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
The discovery filter allocates memory for its UUID list. So use
a helper function to free it and reset it to default states.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
The volume blocks have an step of 0.375dB, but TLV uses 0.01dB for
units. Only use the resolution supported, ignoring the LSB of the
volume register. This results in half the steps and 0.75dB per step,
but reports accurate levels through TLV. Update the masks to reflect
that these are registers have the LSB ignored.
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator into regulator-sky81452
Conflicts:
drivers/regulator/sky81452-regulator.c
|
|
This patch adds support for the Start Service Discovery command. It
does all the checks for command parameters and configured the discovery
filter settings correctly. However the actual support for filtering
will be added with another patch.
Signed-off-by: Jakub Pawlowski <jpawlowski@google.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
The previous patch provided the framework for integrating the UUID
filtering into the service discovery. This patch now provides the
actual filter logic.
Signed-off-by: Jakub Pawlowski <jpawlowski@google.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
Using Start Service Discovery provides the option to specifiy a list
of UUID that are used to filter out device found events. This patch
provides the framework for hooking up the UUID filter.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
Using Start Service Discovery allows to provide a RSSI threshold. This
patch implements support for filtering out device found events based
on the provided value.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
With the upcoming addition of support for Start Service Discovery, the
discovery handling needs to filter on RSSI and UUID values. For that
they need to be stored in the discovery handling. This patch adds the
appropiate fields and also make sure they are reset when discovery
has been stopped.
Signed-off-by: Jakub Pawlowski <jpawlowski@google.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
This patch adds the opcode and structure for Start Service Discovery
operation.
Signed-off-by: Jakub Pawlowski <jpawlowski@google.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
The Bluetooth core specification defines the value 127 as invalid for
RSSI values. So instead of hard coding it, lets add a constant for it.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
Allocation of previous bounce buffer in mmc_init_queue when the current
bounce buffer allocation fails was leading to a crash later in
__blk_segment_map_sg. Error handling is improved by allocating previous
bounce buffer only if the current bounce buffer allocation succeeds.
Signed-off-by: Bhuvanesh Surachari <bhuvanesh_surachari@mentor.com>
Signed-off-by: Harish Jenny K N <harish_kandiga@mentor.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
We now have the physical-timers patches lined up as a dependency in this same
branch, so we can revert the temporary disablement.
This reverts commit b77d43943ea83997c6c37b8831d1561981d499c5.
Signed-off-by: Olof Johansson <olof@lixom.net>
|
|
These are a pre-req to get rk3288 SMP to work with some firmwares, so merge
it in here as well as in next/drivers.
* clocksource/physical-timers:
clocksource: arch_timer: Allow the device tree to specify uninitialized timer registers
clocksource: arch_timer: Fix code to use physical timers when requested
|
|
* clocksource/physical-timers:
clocksource: arch_timer: Allow the device tree to specify uninitialized timer registers
clocksource: arch_timer: Fix code to use physical timers when requested
|
|
timer registers
Some 32-bit (ARMv7) systems are architected like this:
* The firmware doesn't know and doesn't care about hypervisor mode and
we don't want to add the complexity of hypervisor there.
* The firmware isn't involved in SMP bringup or resume.
* The ARCH timer come up with an uninitialized offset (CNTVOFF)
between the virtual and physical counters. Each core gets a
different random offset.
* The device boots in "Secure SVC" mode.
* Nothing has touched the reset value of CNTHCTL.PL1PCEN or
CNTHCTL.PL1PCTEN (both default to 1 at reset)
On systems like the above, it doesn't make sense to use the virtual
counter. There's nobody managing the offset and each time a core goes
down and comes back up it will get reinitialized to some other random
value.
This adds an optional property which can inform the kernel of this
situation, and firmware is free to remove the property if it is going
to initialize the CNTVOFF registers when each CPU comes out of reset.
Currently, the best course of action in this case is to use the
physical timer, which is why it is important that CNTHCTL hasn't been
changed from its reset value and it's a reasonable assumption given
that the firmware has never entered HYP mode.
Note that it's been said that on ARMv8 systems the firmware and
kernel really can't be architected as described above. That means
using the physical timer like this really only makes sense for ARMv7
systems.
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
|
|
This is a bug fix for using physical arch timers when
the arch_timer_use_virtual boolean is false. It restores the
arch_counter_get_cntpct() function after removal in
0d651e4e "clocksource: arch_timer: use virtual counters"
We need this on certain ARMv7 systems which are architected like this:
* The firmware doesn't know and doesn't care about hypervisor mode and
we don't want to add the complexity of hypervisor there.
* The firmware isn't involved in SMP bringup or resume.
* The ARCH timer come up with an uninitialized offset between the
virtual and physical counters. Each core gets a different random
offset.
* The device boots in "Secure SVC" mode.
* Nothing has touched the reset value of CNTHCTL.PL1PCEN or
CNTHCTL.PL1PCTEN (both default to 1 at reset)
One example of such as system is RK3288 where it is much simpler to
use the physical counter since there's nobody managing the offset and
each time a core goes down and comes back up it will get reinitialized
to some other random value.
Fixes: 0d651e4e65e9 ("clocksource: arch_timer: use virtual counters")
Cc: stable@vger.kernel.org
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
|
|
The imx6 PM code seems to be quite creative in its use of irq_data,
using something that is very much a hardware interrupt number where
we expect a virtual one. Yes, it worked so far, but that's only
luck, and it will definitely explode in 3.19.
Fix it by using a pair of helper functions that deal with the
actual hardware.
Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
|
|
mach-imx directly references to the irq field in
struct irq_data, and uses this to directly poke hardware register.
But irq is the *virtual* irq number, something that has nothing
to do with the actual HW irq (stored in the hwirq field). And once
we put the stacked domain code in action, the whole thing explodes,
as these two values are *very* different.
Just replacing all instances of irq with hwirq fixes the issue.
Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
|
|
next/dt
Merge "ARM: BCM5301X: DT changes for v3.19 #2" from Hauke Mehrtens:
ARM: BCM5301X: dts updates
This adds the IRQ number to the main dts file and some new dts files
for newly added devices.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
* tag 'bcm5301x-dt-2014-12-04' of https://github.com/hauke/linux:
ARM: BCM5301X: Add DT for Buffalo WZR-600DHP2
ARM: BCM5301X: Add DT for Asus RT-N18U
ARM: BCM5301X: Add DT for Buffalo WZR-1750DHP
ARM: BCM5301X: Add DT for Netgear R6300 V2
ARM: BCM5301X: Add buttons for Netgear R6250
ARM: BCM5301X: Add IRQs to Broadcom's bus-axi in DTS file
Signed-off-by: Olof Johansson <olof@lixom.net>
|
|
based SoCs
This patch enables the MAX77686 PMIC drivers in the multi_v7_defconfig used
on exynos4412-prime family of SoCs [1]. The exynos4412-prime based boards
are producing the following runtime errors only on the multi_v7_defconfig [2]:
kern.err: deviceless supply vdd_arm not found, using dummy regulator
kern.err: exynos-cpufreq exynos-cpufreq: failed to set cpu voltage to 1287500
kern.err: cpufreq: __target_index: Failed to change cpu frequency: -22
I reviewed the exynos_defconfig, which does not produce these runtime
errors. It was obvious that the exynos_defconfig has the PMIC drivers
enabled, whereas the multi_v7_defconfig does not. This patch has been tested
on a odroid-u2 and a odroid-u3 board. It has resolved the runtime errors.
Therefore, I purpose we enabled these drivers in the multi_v7_defconfig.
[1] http://www.hardkernel.com/main/products/prdt_info.php?g_code=G135270682824
[2] http://storage.armcloud.us/kernel-ci/mainline/v3.18-rc7-48-g7cc78f8/arm-multi_v7_defconfig/lab-tbaker-00/boot-exynos4412-odroidu3.html
Signed-off-by: Tyler Baker <tyler.baker@linaro.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
|
|
Pull drm intel fixes from Dave Airlie:
"Two intel stable fixes, that should be it from me for this round"
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
drm/i915: Unlock panel even when LVDS is disabled
drm/i915: More cautious with pch fifo underruns
|
|
The existing MCE code calls flush_tlb hook with IS=0 (single page) resulting
in partial invalidation of TLBs which is not right. This patch fixes
that by passing IS=0xc00 to invalidate whole TLB for successful recovery
from TLB and ERAT errors.
Cc: stable@vger.kernel.org
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
|
upatepp can get called for a nohpte fault when we find from the linux
page table that the translation was hashed before. In that case
we are sure that there is no existing translation, hence we could
avoid doing tlbie.
We could possibly race with a parallel fault filling the TLB. But
that should be ok because updatepp is only ever relaxing permissions.
We also look at linux pte permission bits when filling hash pte
permission bits. We also hold the linux pte busy bits while
inserting/updating a hashpte entry, hence a paralle update of
linux pte is not possible. On the other hand mprotect involves
ptep_modify_prot_start which cause a hpte invalidate and not updatepp.
Performance number:
We use randbox_access_bench written by Anton.
Kernel with THP disabled and smaller hash page table size.
86.60% random_access_b [kernel.kallsyms] [k] .native_hpte_updatepp
2.10% random_access_b random_access_bench [.] doit
1.99% random_access_b [kernel.kallsyms] [k] .do_raw_spin_lock
1.85% random_access_b [kernel.kallsyms] [k] .native_hpte_insert
1.26% random_access_b [kernel.kallsyms] [k] .native_flush_hash_range
1.18% random_access_b [kernel.kallsyms] [k] .__delay
0.69% random_access_b [kernel.kallsyms] [k] .native_hpte_remove
0.37% random_access_b [kernel.kallsyms] [k] .clear_user_page
0.34% random_access_b [kernel.kallsyms] [k] .__hash_page_64K
0.32% random_access_b [kernel.kallsyms] [k] fast_exception_return
0.30% random_access_b [kernel.kallsyms] [k] .hash_page_mm
With Fix:
27.54% random_access_b random_access_bench [.] doit
22.90% random_access_b [kernel.kallsyms] [k] .native_hpte_insert
5.76% random_access_b [kernel.kallsyms] [k] .native_hpte_remove
5.20% random_access_b [kernel.kallsyms] [k] fast_exception_return
5.12% random_access_b [kernel.kallsyms] [k] .__hash_page_64K
4.80% random_access_b [kernel.kallsyms] [k] .hash_page_mm
3.31% random_access_b [kernel.kallsyms] [k] data_access_common
1.84% random_access_b [kernel.kallsyms] [k] .trace_hardirqs_on_caller
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
|
Red Hat and Fedora use a bug reporting tool that gathers data about
"broken" systems called sosreport. Among other things, it includes the
output of 'cpupower idle-info'. Executing 'cpupower idle-info' on a
system that has cpuidle disabled via 'cpuidle.off=1' results in a 300
second hang in the cpupower application.
ie)
[root@intel-brickland-05]# cpupower idle-info
Could not determine cpuidle driver
Analyzing CPU 0:
Number of idle states: -19
[hang]
The problem is that the cpupower code only checks for a zero return from
sysfs_get_idlestate_count(). The function can return -ENODEV (-19) as
above. This patch fixes callers to sysfs_get_idlestate_count() to check
the right return values.
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
selected) PM_RUNTIME is always set if PM is set, so #ifdef blocks
depending on CONFIG_PM_RUNTIME may now be changed to depend on
CONFIG_PM.
Replace CONFIG_PM_RUNTIME with CONFIG_PM in drivers/sh/pm_runtime.c.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
