| Age | Commit message (Collapse) | Author |
|---|
|
Make sure we're using the new macro, so our
resume signaling will always pass certification.
Cc: <stable@vger.kernel.org> # v3.10+
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Make sure we're using the new macro, so our
resume signaling will always pass certification.
Cc: <stable@vger.kernel.org> # v3.10+
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Make sure we're using the new macro, so our
resume signaling will always pass certification.
Cc: <stable@vger.kernel.org> # v3.10+
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Make sure we're using the new macro, so our
resume signaling will always pass certification.
Cc: <stable@vger.kernel.org> # v3.10+
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
While this driver was already using a 50ms resume
timeout, let's make sure everybody uses the same
macro so it's easy to fix later should anything
go wrong.
It also gives a more "stable" expectation to Linux
users.
Cc: <stable@vger.kernel.org> # v3.10+
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Make sure we're using the new macro, so our
resume signaling will always pass certification.
Cc: <stable@vger.kernel.org> # v3.10+
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Make sure we're using the new macro, so our
resume signaling will always pass certification.
Cc: <stable@vger.kernel.org> # v3.10+
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Make sure we're using the new macro, so our
resume signaling will always pass certification.
Cc: <stable@vger.kernel.org> # v3.10+
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Make sure we're using the new macro, so our
resume signaling will always pass certification.
Cc: <stable@vger.kernel.org> # v3.10+
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Make sure we're using the new macro, so our
resume signaling will always pass certification.
Based on original work by Bin Liu <Bin Liu <b-liu@ti.com>>
Cc: Bin Liu <b-liu@ti.com>
Cc: <stable@vger.kernel.org> # v3.10+
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Make sure we're using the new macro, so our
resume signaling will always pass certification.
Cc: <stable@vger.kernel.org> # v3.10+
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Make sure we're using the new macro, so our
resume signaling will always pass certification.
Cc: <stable@vger.kernel.org> # v3.10+
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Make sure we're using the new macro, so our
resume signaling will always pass certification.
Cc: <stable@vger.kernel.org> # v3.10+
Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Every USB Host controller should use this new
macro to define for how long resume signalling
should be driven on the bus.
Currently, almost every single USB controller
is using a 20ms timeout for resume signalling.
That's problematic for two reasons:
a) sometimes that 20ms timer expires a little
before 20ms, which makes us fail certification
b) some (many) devices actually need more than
20ms resume signalling.
Sure, in case of (b) we can state that the device
is against the USB spec, but the fact is that
we have no control over which device the certification
lab will use. We also have no control over which host
they will use. Most likely they'll be using a Windows
PC which, again, we have no control over how that
USB stack is written and how long resume signalling
they are using.
At the end of the day, we must make sure Linux passes
electrical compliance when working as Host or as Device
and currently we don't pass compliance as host because
we're driving resume signallig for exactly 20ms and
that confuses certification test setup resulting in
Certification failure.
Cc: <stable@vger.kernel.org> # v3.10+
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
ar9550 or later chips, the AR_GPIO_IN_OUT register only can
control GPIO[0:3]. For the extra GPIO, use standard GPIO calls
instead of WMAC internal registers.
Signed-off-by: Miaoqing Pan <miaoqing@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
We can save some power by putting devices that are bound to vfio-pci
but not in use by the user in the D3hot power state. Devices get
woken into D0 when opened by the user. Resets return the device to
D0, so we need to re-apply the low power state after a bus reset.
It's tempting to try to use D3cold, but we have no reason to inhibit
hotplug of idle devices and we might get into a loop of having the
device disappear before we have a chance to try to use it.
A new module parameter allows this feature to be disabled if there are
devices that misbehave as a result of this change.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
|
|
As indicated in the comment, this is not entirely uncommon and
causes user concern for no reason.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
|
|
This copies the same support from pci-stub for exactly the same
purpose, enabling a set of PCI IDs to be automatically added to the
driver's dynamic ID table at module load time. The code here is
pretty simple and both vfio-pci and pci-stub are fairly unique in
being meta drivers, capable of attaching to any device, so there's no
attempt made to generalize the code into pci-core.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
|
|
If VFIO VGA access is disabled for the user, either by CONFIG option
or module parameter, we can often opt-out of VGA arbitration. We can
do this when PCI bridge control of VGA routing is possible. This
means that we must have a parent bridge and there must only be a
single VGA device below that bridge. Fortunately this is the typical
case for discrete GPUs.
Doing this allows us to minimize the impact of additional GPUs, in
terms of VGA arbitration, when they are only used via vfio-pci for
non-VGA applications.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
|
|
Add a module option so that we don't require a CONFIG change and
kernel rebuild to disable VGA support. Not only can VGA support be
troublesome in itself, but by disabling it we can reduce the impact
to host devices by doing a VGA arbitration opt-out.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
|
|
vga_set_legacy_decoding() is defined in drivers/gpu/vga/vgaarb.c,
which is only compiled with CONFIG_VGA_ARB. A caller would
therefore get an undefined symbol if the VGA arbiter is not
enabled.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Acked-by: Dave Airlie <airlied@redhat.com>
|
|
This patch fix a spelling typo in MODULE_DESCRIPTION in
wl1251/main.c
Signed-off-by: Masanari Iida <standby24x7@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
Use bool constants as the return values instead of 1 and 0.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
packet.
rtl8192cu can't connect to AP after physical reconnect.
according to dmesg, that problem's cause was DHCP timeout.
rtl_is_special_data function checks packet type for adjusting rate.
when that function is called from _rtl_rc_get_highest_rix, it can not
calculate offset correctly. so i add argument is_encn in rtl_is_special_data.
is_enc variable mean that iv header is added in skb parameter.
i test only rtl8192cu chipset. because i doesn't have other rtlwifi chipsets.
Signed-off-by: Taehee Yoo <ap420073@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
As the driver may send multiple wmi commands with identical cmd id,
it is more robust to check seq number for timeout instead.
Signed-off-by: Fred Chou <fred.chou.nd@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next
* some more work on LAR
* fixes for UMAC scan
* more work on debugging framework
* more work for 8000 devices
* cleanups and small bugfixes
|
|
The Bluetooth address setting for Intel devices is provided by a generic
module now. Start using that module instead of relying it being included
in the driver.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
Since the Intel Bluetooth support has its own header, it makes sense
to move all command structs into it.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
The Bluetooth address handling for Intel devices is provided by a generic
module now. Start using that module instead of relying it being included
in the driver.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
The majority of Intel Bluetooth vendor commands are shared between USB
and UART transports. This creates a separate module that eventually
will hold all Intel specific commands, but for now just start with the
commands to change the Bluetooth public address and check for the
default address.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
Future H:4 based UART drivers require custom packet types and custom
receive functions. To support this, extended the h4_recv_buf function
with a packet definition table.
For the default H:4 packets types of ACL data, SCO data and events,
provide helpers to reduce the amount of code duplication.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
The Broadcom UART based devices seem to use a little bit different
firmare naming prefix. So add a separate table for these devices.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
This adds the protocol support for Broadcom based UART devices to
enable firmware and patchram download procedure. It is a pretty
straight forward H:4 driver with the exception of actually having
its own setup and address configuration callbacks.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
The setup callback got wrongly inserted between the enqueue and dequeue
callbacks. Move it to a better location.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
The version number is cosmetic, but pretty handy for debugging purposes
and since the Broadcom protocol support is now optional, just increase
it to indicate the difference.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
The quirks for Broadcom devices can be set from the setup function and
to keep the code simple, just move them into Broadcom support module.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
With the generic Broadcom Bluetooth support module, it is possible to
turn support for firmware and patchram download into an optional
feature.
To keep backwards compatibility with previous kernel configurations,
the new option defaults to enabled.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
To unify the controller setup of Broadcom devices between USB and UART
transport, add the patchram download support into the Broadcom module.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
The new Broadcom Bluetooth support module provides generic functionality
for changing and checking the Bluetooth device address. Use these new
features instead of keeping a duplicate in the driver.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
The new Broadcom Bluetooth support module provides generic functionality
for changing and checking the Bluetooth device address. Use these new
features instead of keeping a duplicate in the driver.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
The majority of Broadcom Bluetooth vendor commands are shared between
USB and UART transports. This creates a separate module that eventually
will hold all Broadcom specific commands, but for now just start with
the commands to change the Bluetooth public address and check for the
default address.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
This version number is more cosmetic and for debugging purposes, but
since there has been a few changes lately, increase it now.
Two left-over and not used version constants that were never exposed
anywhere are removed since they have no actual value.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
The init function for each HCI UART protocol prints the same on success
and failure. This information is so generic, remove it and let the main
HCI UART handling print it instead.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
This adds an extra name field to the hci_uart_proto struct that provides
a simple way of adding a string identifier to the protocol.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
The usage of struct hci_uart_proto should always be const. Change the
function headers and individual protocol drivers.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
The hci_recv_stream_fragment function should have never been introduced
in the first place. The Bluetooth core does not need to know anything
about the HCI transport protocol.
With all transport protocol specific detailed moved back into the
drivers where they belong (mainly generic USB and UART drivers), this
function can now be removed.
This reduces the size of hci_dev structure and also removes an exported
symbol from the Bluetooth core module.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
Instead of using hci_recv_stream_fragment, use the local available
h4_recv_buf helper function.
To ensure that the function is available select BT_HCIUART_H4.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
Instead of using hci_recv_stream_fragment, use the local available
h4_recv_buf helper function.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
The h4_recv_buf helper function can be used for receiving H:4 packets
out of a TTY stream. It is self-contained and allows for reuse by all
HCI UART protocols.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
