On Tue, Apr 2, 2019 at 1:41 PM Heiner Kallweit wrote:
>
> On 02.04.2019 22:16, Florian Fainelli wrote:
> > On 4/2/19 12:55 PM, Heiner Kallweit wrote:
> >> There are numerous reports about different problems caused by ASPM
> >> incompatibilities between certain network chip versions and board
> >>
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
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
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
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
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
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
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
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
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
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
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
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
> >
&
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
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
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
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
Acked-by: Greg Kroah-Hartman
Test
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
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
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 Marvell devices may have many gpio pins, and hence for wakeup
on these out-of-band pins, the chip needs to be told which pin is
to be used for wakeup, using an hci command.
Thus, we read the pin number etc from the device tree node and send
a command to the chip.
Signed-off-by: Rajat Jain
compatible string is in compliance with
Documentation/devicetree/bindings/usb/usb-device.txt
Signed-off-by: Rajat Jain
Reviewed-by: Brian Norris
Acked-by: Rob Herring
---
v7: Change the BTUSB_OOB_WAKE_DISABLED flag to BTUSB_OOB_WAKE_ENABLED
v6: Remove the newlines in error statements ("\n"
Use a label to remove the repetetive cleanup, for error cases.
Signed-off-by: Rajat Jain
Reviewed-by: Brian Norris
---
v7: same as v6
v6: same as v5
v5: same as v4
v4: same as v3
v3: Added Brian's "Reviewed-by"
v2: same as v1
drivers/bluetooth/btusb.c | 19 +--
Use a label to remove the repetetive cleanup, for error cases.
Signed-off-by: Rajat Jain
Reviewed-by: Brian Norris
---
v6: same as v5
v5: same as v4
v4: same as v3
v3: Added Brian's "Reviewed-by"
v2: same as v1
drivers/bluetooth/btusb.c | 19 +--
1 file change
compatible string is in compliance with
Documentation/devicetree/bindings/usb/usb-device.txt
Signed-off-by: Rajat Jain
Reviewed-by: Brian Norris
Acked-by: Rob Herring
---
v6: Remove the newlines in error statements ("\n")
v5: Move the call to pm_wakeup_event() to the begining of irq h
The Marvell devices may have many gpio pins, and hence for wakeup
on these out-of-band pins, the chip needs to be told which pin is
to be used for wakeup, using an hci command.
Thus, we read the pin number etc from the device tree node and send
a command to the chip.
Signed-off-by: Rajat Jain
The Marvell devices may have many gpio pins, and hence for wakeup
on these out-of-band pins, the chip needs to be told which pin is
to be used for wakeup, using an hci command.
Thus, we read the pin number etc from the device tree node and send
a command to the chip.
Signed-off-by: Rajat Jain
compatible string is in compliance with
Documentation/devicetree/bindings/usb/usb-device.txt
Signed-off-by: Rajat Jain
Reviewed-by: Brian Norris
Acked-by: Rob Herring
---
v5: Move the call to pm_wakeup_event() to the begining of irq handler.
v4: Move the set_bit(BTUSB_OOB_WAKE_DISABLED,..) call to
Use a label to remove the repetetive cleanup, for error cases.
Signed-off-by: Rajat Jain
Reviewed-by: Brian Norris
---
v5: same as v4
v4: same as v3
v3: Added Brian's "Reviewed-by"
v2: same as v1
drivers/bluetooth/btusb.c | 19 +--
1 file changed, 9 insertions(+
The Marvell devices may have many gpio pins, and hence for wakeup
on these out-of-band pins, the chip needs to be told which pin is
to be used for wakeup, using an hci command.
Thus, we read the pin number etc from the device tree node and send
a command to the chip.
Signed-off-by: Rajat Jain
Use a label to remove the repetetive cleanup, for error cases.
Signed-off-by: Rajat Jain
Reviewed-by: Brian Norris
---
v4: same as v3
v3: Added Brian's "Reviewed-by"
v2: same as v1
drivers/bluetooth/btusb.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions
compatible string is in compliance with
Documentation/devicetree/bindings/usb/usb-device.txt
Signed-off-by: Rajat Jain
Reviewed-by: Brian Norris
---
v4: Move the set_bit(BTUSB_OOB_WAKE_DISABLED,..) call to the beginning of
btusb_config_oob_wake() - caught by Brian.
v3: Add Brian's "R
Use a label to remove the repetetive cleanup, for error cases.
Signed-off-by: Rajat Jain
Reviewed-by: Brian Norris
---
v3: Added Brian's "Reviewed-by"
v2: same as v1
drivers/bluetooth/btusb.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff
The Marvell devices may have many gpio pins, and hence for wakeup
on these out-of-band pins, the chip needs to be told which pin is
to be used for wakeup, using an hci command.
Thus, we read the pin number etc from the device tree node and send
a command to the chip.
Signed-off-by: Rajat Jain
compatible string is in compliance with
Documentation/devicetree/bindings/usb/usb-device.txt
Signed-off-by: Rajat Jain
Reviewed-by: Brian Norris
---
v3: Add Brian's "Reviewed-by"
v2: * Use interrupt-names ("wakeup") instead of assuming first interrupt.
* Leave it on d
Hi Brian,
On Mon, Dec 19, 2016 at 3:10 PM, Brian Norris wrote:
> Hi Rajat,
>
> On Fri, Dec 16, 2016 at 11:30:03AM -0800, Rajat Jain wrote:
>> Some onboard BT chips (e.g. Marvell 8997) contain a wakeup pin that
>> can be connected to a gpio on the CPU side, and can be used
Hi Brian,
I've just posted a v2 patchset after taking care of your your
comments. Please see inline below.
On Wed, Dec 14, 2016 at 7:21 PM, Brian Norris wrote:
> Hi,
>
> On Wed, Dec 14, 2016 at 11:12:58AM -0800, Rajat Jain wrote:
>> Some BT chips (e.g. Marvell 8997) conta
compatible string is in compliance with
Documentation/devicetree/bindings/usb/usb-device.txt
Signed-off-by: Rajat Jain
---
v2: * Use interrupt-names ("wakeup") instead of assuming first interrupt.
* Leave it on device tree to specify IRQ flags (level /edge triggered)
* Mark the dev
The Marvell devices may have many gpio pins, and hence for wakeup
on these out-of-band pins, the chip needs to be told which pin is
to be used for wakeup, using an hci command.
Thus, we read the pin number etc from the device tree node and send
a command to the chip.
Signed-off-by: Rajat Jain
Use a label to remove the repetetive cleanup, for error cases.
Signed-off-by: Rajat Jain
---
v2: same as v1
drivers/bluetooth/btusb.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 2f633df
: Rajat Jain
---
Documentation/devicetree/bindings/net/btusb.txt | 38
drivers/bluetooth/btusb.c | 82 +
2 files changed, 120 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/btusb.txt
diff --git a/Documentation
Use a label to remove the repetetive cleanup, for error cases.
(This label will also be used in subsequent patches).
Signed-off-by: Rajat Jain
---
drivers/bluetooth/btusb.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/bluetooth/btusb.c b
The Marvell devices may have many gpio pins, and hence for wakeup
on these out-of-band pins, the chip needs to be told which pin is
to be used for wakeup, using an hci command.
Thus, we read the pin number etc from the device tree node and send
a command to the chip.
Signed-off-by: Rajat Jain
.
The function mwifiex_probe_of()nodetself is currently only a place
holder with the next patch adding content to it.
Signed-off-by: Rajat Jain
---
drivers/net/wireless/marvell/mwifiex/main.c| 15 ++-
drivers/net/wireless/marvell/mwifiex/main.h| 2 +-
drivers/net/wireless
if needed.
This is needed for subsequent patches in this patchset that
intend to unify and consolidate some of the code that would
otherwise have to be duplicated among the interface drivers
(sdio, pcie, usb).
Signed-off-by: Rajat Jain
---
drivers/net/wireless/marvell/mwifiex/main.c | 4 +++-
driv
Commit ce4f6f0c353b ("mwifiex: add platform specific wakeup interrupt
support") added WoWLAN feature only for sdio. This patch moves that
code to the common module so that all the interface drivers can use
it for free. It enables pcie and sdio for its use currently.
Signed-off-by:
wing 2 patches applied:
https://patchwork.kernel.org/patch/9362275/
https://patchwork.kernel.org/patch/9390225/
Rajat Jain (3):
mwifiex: Allow mwifiex early access to device structure
mwifiex: Introduce mwifiex_probe_of() to parse common properties
mwifiex: Enable WoWLAN for both sdio and pcie
the system was
apparently confused about the wakeup source.
Signed-off-by: Wei-Ning Huang
Signed-off-by: Rajat Jain
Tested-by: Wei-Ning Huang
Reviewed-by: Eric Caruso
Acked-by: Amitkumar Karwar
---
v3: Fix the commit log
v2: Fix the commit log
drivers/net/wireless/marvell/mwifiex/sdio.c | 8
Hello Kalie,
On Mon, Oct 3, 2016 at 6:04 AM, Kalle Valo wrote:
> Rajat Jain wrote:
>> Enable notifying wakeup source to the PM core in case of
>> a wake on wireless LAN event.
>>
>> Signed-off-by: Wei-Ning Huang
>> Signed-off-by: Rajat Jain
>> Tested-b
Enable notifying wakeup source to the PM core. This allow darkresume to
correctly track wakeup source and mark mwifiex_plt as 'automatic' wakeup
source.
Signed-off-by: Wei-Ning Huang
Signed-off-by: Rajat Jain
Tested-by: Wei-Ning Huang
Reviewed-by: Eric Caruso
---
drivers/net/wirele
Enable notifying wakeup source to the PM core in case of
a wake on wireless LAN event.
Signed-off-by: Wei-Ning Huang
Signed-off-by: Rajat Jain
Tested-by: Wei-Ning Huang
Reviewed-by: Eric Caruso
---
v2: Fix the commit log
drivers/net/wireless/marvell/mwifiex/sdio.c | 8
drivers/net
Please ignore, not sure why this landed without a subject.
On Tue, Sep 27, 2016 at 9:50 AM, Rajat Jain wrote:
> From: Wei-Ning Huang
>
> Date: Thu, 17 Mar 2016 11:43:16 +0800
> Subject: [PATCH] mwifiex: report wakeup for wowlan
>
> Enable notifying wakeup source to the P
Ning Huang
Signed-off-by: Rajat Jain
Tested-by: Wei-Ning Huang
Reviewed-by: Eric Caruso
---
drivers/net/wireless/marvell/mwifiex/sdio.c | 8
drivers/net/wireless/marvell/mwifiex/sdio.h | 1 +
2 files changed, 9 insertions(+)
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c
b/d
Enable notifying wakeup source to the PM core. This allow darkresume to
correctly track wakeup source and mark mwifiex_plt as 'automatic' wakeup
source.
Signed-off-by: Wei-Ning Huang
Signed-off-by: Rajat Jain
Tested-by: Wei-Ning Huang
Reviewed-by: Eric Caruso
---
drivers/net/wirele
59 matches
Mail list logo
