Add a hook to allow the BT driver to do device or command specific
handling in case of timeouts. This is to be used by Intel driver to
reset the device after certain number of timeouts.
Signed-off-by: Rajat Jain
---
v6: Dropped the "sent command" parameter from cmd_timeout()
v5: Drop
controllers.
[1]
https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/other-acpi-namespace-objects#acpi-namespace-hierarchy-and-adr-for-embedded-usb-devices
Signed-off-by: Dmitry Torokhov
Signed-off-by: Rajat Jain (changed how we get the usb_port)
Acked-by: Greg Kroah-Hartman
Tested
If the platform provides it, use the reset gpio to reset the Intel BT
chip, as part of cmd_timeout handling. This has been found helpful on
Intel bluetooth controllers where the firmware gets stuck and the only
way out is a hard reset pin provided by the platform.
Signed-off-by: Rajat Jain
From: Dmitry Torokhov
In preparation for handling embedded USB devices let's split
usb_acpi_find_companion() into usb_acpi_find_companion_for_device() and
usb_acpi_find_companion_for_port().
Signed-off-by: Dmitry Torokhov
Signed-off-by: Rajat Jain
Acked-by: Greg Kroah-Hartman
Test
of timeouts.
> >
> > Signed-off-by: Rajat Jain
> > ---
> > v5: Drop the quirk, and rename the hook function to cmd_timeout()
> > v4: same as v1
> > v3: same as v1
> > v2: same as v1
> >
> > include/net/bluetooth/hci_core.h | 1 +
> > n
are gets stuck and the only
> > way out is a hard reset pin provided by the platform.
> >
> > Signed-off-by: Rajat Jain
> > ---
> > v5: Rename the hook to cmd_timeout, and wait for 5 timeouts before
> >resetting the device.
> > v4: Use data->flag
If the platform provides it, use the reset gpio to reset the Intel BT
chip, as part of cmd_timeout handling. This has been found helpful on
Intel bluetooth controllers where the firmware gets stuck and the only
way out is a hard reset pin provided by the platform.
Signed-off-by: Rajat Jain
Add a hook to allow the BT driver to do device or command specific
handling in case of timeouts. This is to be used by Intel driver to
reset the device after certain number of timeouts.
Signed-off-by: Rajat Jain
---
v5: Drop the quirk, and rename the hook function to cmd_timeout()
v4: same as v1
From: Dmitry Torokhov
In preparation for handling embedded USB devices let's split
usb_acpi_find_companion() into usb_acpi_find_companion_for_device() and
usb_acpi_find_companion_for_port().
Signed-off-by: Dmitry Torokhov
Signed-off-by: Rajat Jain
Acked-by: Greg Kroah-Hartman
Test
controllers.
[1]
https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/other-acpi-namespace-objects#acpi-namespace-hierarchy-and-adr-for-embedded-usb-devices
Signed-off-by: Dmitry Torokhov
Signed-off-by: Rajat Jain (changed how we get the usb_port)
Acked-by: Greg Kroah-Hartman
Tested
the firmware gets stuck and
> > the only way out is a hard reset pin provided by the platform.
> >
> > Signed-off-by: Rajat Jain
> > ---
> > v4: Use data->flags instead of clearing the quirk in btusb_hw_reset()
> > v3: Better error handling for gpiod_get_optional
On Sat, Jan 19, 2019 at 11:51 AM Marcel Holtmann wrote:
>
> Hi Rajat,
>
> > The BTUSB_INTEL and BTUSB_INTEL_NEW have common functions & quirks are
> > assigned to hdev structure. Lets collect them together instead of
> > repeating them in different code branches.
&g
fails to respond to certain
> > number of commands (currently 5) including the HCI reset commands.
> > This is done based on a newly introduced quirk. This is done based
> > on some initial work by Intel.
> >
> > Signed-off-by: Rajat Jain
> > ---
> > v4: same as v
for-embedded-usb-devices
> >
> > Signed-off-by: Dmitry Torokhov
> > Signed-off-by: Rajat Jain (changed how we get the
> > usb_port)
> > Acked-by: Greg Kroah-Hartman
> > Tested-by: Sukumar Ghorai
> > ---
> > v4: Add Acked
).
> >
> > Signed-off-by: Dmitry Torokhov
> > Signed-off-by: Rajat Jain
> > Acked-by: Greg Kroah-Hartman
> > Tested-by: Sukumar Ghorai
> > ---
> > v4: Add Acked-by and Tested-by in signatures.
> > v3: same as v1
> > v2: same as v1
> >
&
From: Dmitry Torokhov
In preparation for handling embedded USB devices let's split
usb_acpi_find_companion() into usb_acpi_find_companion_for_device() and
usb_acpi_find_companion_for_port().
Signed-off-by: Dmitry Torokhov
Signed-off-by: Rajat Jain
Acked-by: Greg Kroah-Hartman
Test
controllers.
[1]
https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/other-acpi-namespace-objects#acpi-namespace-hierarchy-and-adr-for-embedded-usb-devices
Signed-off-by: Dmitry Torokhov
Signed-off-by: Rajat Jain (changed how we get the usb_port)
Acked-by: Greg Kroah-Hartman
Tested
The BTUSB_INTEL and BTUSB_INTEL_NEW have common functions & quirks are
assigned to hdev structure. Lets collect them together instead of
repeating them in different code branches.
Signed-off-by: Rajat Jain
---
v4: same as v1
v3: same as v1
v2: same as v1
drivers/bluetooth/btusb.c
newly introduced quirk. This is done based
on some initial work by Intel.
Signed-off-by: Rajat Jain
---
v4: same as v1
v3: same as v1
v2: same as v1
include/net/bluetooth/hci.h | 8
include/net/bluetooth/hci_core.h | 2 ++
net/bluetooth/hci_core.c | 15 +--
3
If the platform provides it, use the reset gpio to reset the BT
chip (requested by the HCI core if needed). This has been found helpful
on some of Intel bluetooth controllers where the firmware gets stuck and
the only way out is a hard reset pin provided by the platform.
Signed-off-by: Rajat Jain
Intel bluetooth controllers where the firmware gets stuck and
> > the only way out is a hard reset pin provided by the platform.
> >
> > Signed-off-by: Rajat Jain
> > ---
> > v3: Better error handling for gpiod_get_optional()
> > v2: Handl
On Wed, Nov 21, 2018 at 3:50 PM Rajat Jain wrote:
>
> If the platform provides it, use the reset gpio to reset the BT
> chip (requested by the HCI core if needed). This has been found helpful
> on some of Intel bluetooth controllers where the firmware gets stuck and
> the only wa
controllers.
[1]
https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/other-acpi-namespace-objects#acpi-namespace-hierarchy-and-adr-for-embedded-usb-devices
Signed-off-by: Dmitry Torokhov
Signed-off-by: Rajat Jain (changed how we get the usb_port)
---
v3: same as v1
v2: same as v1
If the platform provides it, use the reset gpio to reset the BT
chip (requested by the HCI core if needed). This has been found helpful
on some of Intel bluetooth controllers where the firmware gets stuck and
the only way out is a hard reset pin provided by the platform.
Signed-off-by: Rajat Jain
The BTUSB_INTEL and BTUSB_INTEL_NEW have common functions & quirks are
assigned to hdev structure. Lets collect them together instead of
repeating them in different code branches.
Signed-off-by: Rajat Jain
---
v3: same as v1
v2: same as v1
drivers/bluetooth/btusb.c
From: Dmitry Torokhov
In preparation for handling embedded USB devices let's split
usb_acpi_find_companion() into usb_acpi_find_companion_for_device() and
usb_acpi_find_companion_for_port().
Signed-off-by: Dmitry Torokhov
Signed-off-by: Rajat Jain
---
v3: same as v1
v2: same as v1
dr
newly introduced quirk. This is done based
on some initial work by Intel.
Signed-off-by: Rajat Jain
---
v3: same as v1
v2: same as v1
include/net/bluetooth/hci.h | 8
include/net/bluetooth/hci_core.h | 2 ++
net/bluetooth/hci_core.c | 15 +--
3 files changed
The BTUSB_INTEL and BTUSB_INTEL_NEW have common functions & quirks are
assigned to hdev structure. Lets collect them together instead of
repeating them in different code branches.
Signed-off-by: Rajat Jain
---
v2: same as v1
drivers/bluetooth/btusb.c | 27 ---
1
newly introduced quirk. This is done based
on some initial work by Intel.
Signed-off-by: Rajat Jain
---
v2: same as v1
include/net/bluetooth/hci.h | 8
include/net/bluetooth/hci_core.h | 2 ++
net/bluetooth/hci_core.c | 15 +--
3 files changed, 23 insertions
controllers.
[1]
https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/other-acpi-namespace-objects#acpi-namespace-hierarchy-and-adr-for-embedded-usb-devices
Signed-off-by: Dmitry Torokhov
Signed-off-by: Rajat Jain (changed how we get the usb_port)
---
v2: same as v1
drivers/usb/core
If the platform provides it, use the reset gpio to reset the BT
chip (requested by the HCI core if needed). This has been found helpful
on some of Intel bluetooth controllers where the firmware gets stuck and
the only way out is a hard reset pin provided by the platform.
Signed-off-by: Rajat Jain
From: Dmitry Torokhov
In preparation for handling embedded USB devices let's split
usb_acpi_find_companion() into usb_acpi_find_companion_for_device() and
usb_acpi_find_companion_for_port().
Signed-off-by: Dmitry Torokhov
Signed-off-by: Rajat Jain
---
v2: same as v1
drivers/usb/cor
From: Dmitry Torokhov
In preparation for handling embedded USB devices let's split
usb_acpi_find_companion() into usb_acpi_find_companion_for_device() and
usb_acpi_find_companion_for_port().
Signed-off-by: Dmitry Torokhov
Signed-off-by: Rajat Jain
---
drivers/usb/core/usb-acpi.c
companions for embedded USB devices
(This basically allows ACPI nodes to be attached to the USB devices,
thus useful for any onboard / embedded USB devices that wants to get
some info from the ACPI).
Rajat Jain (3):
Bluetooth: Reset Bluetooth chip after multiple command timeouts
Bluetooth
newly introduced quirk. This is done based
on some initial work by Intel.
Signed-off-by: Rajat Jain
---
include/net/bluetooth/hci.h | 8
include/net/bluetooth/hci_core.h | 2 ++
net/bluetooth/hci_core.c | 15 +--
3 files changed, 23 insertions(+), 2 deletions
controllers.
[1]
https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/other-acpi-namespace-objects#acpi-namespace-hierarchy-and-adr-for-embedded-usb-devices
Signed-off-by: Dmitry Torokhov
Signed-off-by: Rajat Jain (changed how we get the usb_port)
---
drivers/usb/core/usb-acpi.c | 44
If the platform provides it, use the reset gpio to reset the BT
chip (requested by the HCI core if needed). This has been found helpful
on some of Intel bluetooth controllers where the firmware gets stuck and
the only way out is a hard reset pin provided by the platform.
Signed-off-by: Rajat Jain
The BTUSB_INTEL and BTUSB_INTEL_NEW have common functions & quirks are
assigned to hdev structure. Lets collect them together instead of
repeating them in different code branches.
Signed-off-by: Rajat Jain
---
drivers/bluetooth/btusb.c | 27 ---
1 file changed
On Thu, Apr 19, 2018 at 8:01 AM, Alan Stern wrote:
> On Wed, 18 Apr 2018, Ravi Chandra Sadineni wrote:
>
>> On chromebooks we depend on wakeup count to identify the wakeup source.
>> But currently USB devices do not increment the wakeup count when they
>> trigger the remote wake. This patch addres
Hi usbhid folks,
I'd like to identify after a wakeup from suspend, that my USB HID
keyboard was used to wake up the system.
I'm trying to understand why don't I see "wakeup_count" increase for
my USB keyboard or trackpad in /sys/kernel/debug/wakeup_sources, when
I indeed woke up the system using
40 matches
Mail list logo
