Hi Rajat,
> 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_timeou
Hi Rajat,
> USB devices permanently connected to USB ports may be described in ACPI
> tables and share ACPI devices with ports they are connected to. See [1]
> for details.
>
> This will allow us to describe sideband resources for devices, such as,
> for example, hard reset line for BT USB contro
Hi Rajat,
> 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
> Tested-by: Su
Hi Rajat,
> 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
Hi Rajat,
> 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
Hi Rajat,
> 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_
Hi Rajat,
> 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.
>
> Sig
Hi Rajat,
> Add a quirk and a hook to allow the HCI core to reset the BT chip
> if needed (after a number of timed out commands). Use that new hook to
> initiate BT chip reset if the controller fails to respond to certain
> number of commands (currently 5) including the HCI reset commands.
> This
Hi Rajat,
> USB devices permanently connected to USB ports may be described in ACPI
> tables and share ACPI devices with ports they are connected to. See [1]
> for details.
>
> This will allow us to describe sideband resources for devices, such as,
> for example, hard reset line for BT USB contro
Hi Rajat,
> 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
> Tested-by: Su
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.
>
> Signed-off-by: Rajat Jain
> ---
> v4: same as v1
> v3: same as v1
> v2: same as v1
>
> drivers/
Hi Rajat,
> 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.
>
> Sig
uiring the lock.
> The callback may be invoked either in IRQ or BH context depending on the
> USB host controller.
> Use the _irqsave variant of the locking primitives.
>
> Cc: Marcel Holtmann
> Cc: Johan Hedberg
> Cc: linux-blueto...@vger.kernel.org
> Signed-off-by: Seb
uiring the lock.
> The callback may be invoked either in IRQ or BH context depending on the
> USB host controller.
> Use the _irqsave variant of the locking primitives.
>
> Cc: Marcel Holtmann
> Cc: Johan Hedberg
> Cc: linux-blueto...@vger.kernel.org
> Signed-off-by: Seb
Hi Leif,
> This is a rework of reverted commit fd865802c66bc451dc515ed89360f84376ce1a56
> The issue is that some QCA Rome bluetooth controllers stop functioning upon
> resume from suspend.
> These devices seem to be losing power during suspend. This patch will enable
> reset_resume in usb core (i
Hi Kai-Heng,
> Commit ("fd865802c66bc451dc515ed89360f84376ce1a56 Bluetooth: btusb: fix
> QCA Rome suspend/resume") enables reset_resume in btusb_probe(). This
> makes the device resets during btusb_open(), firmware loading gets
> interrupted as a result.
>
> We still want to reset the device to s
Hi Greg,
> Commit ("fd865802c66bc451dc515ed89360f84376ce1a56 Bluetooth: btusb: fix
> QCA Rome suspend/resume") enables reset_resume in btusb_probe(). This
> makes the device resets during btusb_open(), firmware loading gets
> interrupted as a result.
>
> We still want to reset the device to solve
Hi Kai-Heng,
> This reverts commit fd865802c66bc451dc515ed89360f84376ce1a56.
>
> This commit causes a regression on some QCA ROME chips. The USB device
> reset happens in btusb_open(), hence firmware loading gets interrupted.
>
> Furthermore, this commit stops working after commit
> ("a0085f2510
Hi Wolfram,
> kmalloc will print enough information in case of failure.
>
> Signed-off-by: Wolfram Sang
> ---
> drivers/bluetooth/bcm203x.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
patch has been applied to bluetooth-next tree.
Regards
Marcel
--
To unsubscribe from this list
Hi Felipe,
>> I find that the developers often just specified the numeric value
>> when calling a macro which is defined with a parameter for access permission.
>> As we know, these numeric value for access permission have had the
>> corresponding macro,
>> and that using macro can improve the ro
Hi Felipe,
>> I find that the developers often just specified the numeric value
>> when calling a macro which is defined with a parameter for access permission.
>> As we know, these numeric value for access permission have had the
>> corresponding macro,
>> and that using macro can improve the ro
Hi Daniel,
> btusb currently has a generic match on USB device descriptors:
>{ USB_DEVICE_INFO(0xe0, 0x01, 0x01) },
>
> However, http://www.usb.org/developers/defined_class states:
>
> Base Class E0h (Wireless Controller)
> This base class is defined for devices that are Wireless contr
Hi Bjorn,
>> we introduced DEVTYPE in uevent a long time ago. That is what
>> userspace should be using and not second guessing on interface names.
>
> Yes, sorry for confusing this by mentioning the device name. This is
> really about DEVTYPE.
>
> usbnet minidrivers use FLAG_WWAN to set both t
Hi Bjorn,
>> Hmm. Oliver is marked as the maintainer of the USB CDC code, but
>> others have touched it more recently. So I'm just wildly adding people
>> to the cc to comment on this patch and maybe apply it.
>> Oliver/David/Ben/Bjørn?
>
> Adding Aleksander and Dan, too. The 'wwanX' vs 'usbX' d
Hi Josh,
>>> Bluetooth devices off of some buses such as USB may lose power across
>>> suspend/resume. When this happens, drivers may need to have the setup
>>> function called again and behave differently than a cold power on.
>>> Add a reset_resume function for drivers to call. During the
>>> re
Hi Laura,
> Some USB hubs may lose power across suspend/resume.
> Add a reset_resume callback to properly reset those bluetoot devices.
>
> Signed-off-by: Laura Abbott
> ---
> Now the setup function is called again with the HCI_RESET_RESUME
> flag set. The various functions could then use that R
Hi Laura,
> Bluetooth devices off of some buses such as USB may lose power across
> suspend/resume. When this happens, drivers may need to have the setup
> function called again and behave differently than a cold power on.
> Add a reset_resume function for drivers to call. During the
> reset_resum
Hi Laura,
> Then avoiding the failed firmware is no solution, indeed.
> If it's a new probe, it should be never executed during resume.
Can you expand this comment? What's wrong with probing during resume?
The USB stack does carry out probes during resume under certa
Hi Bastien,
Could you specify exactly the model?
>>>
>>> Onda v975w
>>>
If android is running fine on it you may check android kernel
config
for
this device and check which udc is enabled.
>>>
>>> No kernel sources from this Chinese vendor. But it looks like the
>>> US
Hi Alan,
>> Then avoiding the failed firmware is no solution, indeed.
>> If it's a new probe, it should be never executed during resume.
>
> Can you expand this comment? What's wrong with probing during resume?
>
> The USB stack does carry out probes during resume under certain
> circumstances.
Hi Takashi,
>> The data is cached in RAM. More specifically, the former loaded
>> firmware files are reloaded and saved at suspend for each device
>> object. See fw_pm_notify() in firmware_class.c.
>
> OK, this may be a stupid idea, but do we know the firmware
> was succ
Hi Oliver,
>> The data is cached in RAM. More specifically, the former loaded
>> firmware files are reloaded and saved at suspend for each device
>> object. See fw_pm_notify() in firmware_class.c.
>
> OK, this may be a stupid idea, but do we know the firmware
> was successfully loaded in the fi
Hi Alan,
I am not convinced. Now we are hacking the Bluetooth core layer
(which has nothing to do with the drivers suspend/resume or
probe) to do something different so that we do not see this
warning.
I can not do anything about the platform in question choosing a
>
Hi Gustavo,
>> Many btusb devices have 2 modes, a hid mode and a bluetooth hci mode. These
>> devices default to hid mode for BIOS use. This means that after having been
>> reset they will revert to HID mode, and are no longer usable as a HCI.
>>
>> Therefor it is a very bad idea to just blindly
Hi Markus,
>> Do you have a userspace test program that we can use to verify that this
>> does work, and that others can use to run on some different platforms to
>> verify that this is actually faster?
>>
>
> You will need one of our devices for testing I guess. Some sca
Hi Greg,
How can you achieve plug and play for a ft2232 based USB serial device
implementing 802.15.4 networking?
The device has a 802.15.4 SOC with a UART attached to a ft2232. With
firmware loaded the only thing it can do is talk the 802.15.4 tty line
discipline, i
Hi Thomas,
> Now I can confirm the device works via wwan-interface with ipv6 too.
>
> In detail: ipv6 works in 3G-mode. (umts/hspa)
>
> My problem was: I am more and more surrounded by LTE, and I was not able to
> force the device to register to the right network.
>
> LTE and IPv6 seems to be
Hi Thomas,
> The network connection is working via wwan1 , at least with IPv4.
> The LTE speed here with 8-16Mbit/s is limited by my contract, not the device.
>
> At the moment I have problems with IPv6, but I think this is not a problem of
> the device, more a problem of my apn, which may be on
Hi Gustavo,
> A lot of Broadcom Bluetooth devices provides vendor specific interface
> class and we are getting flooded by patches adding new device support.
> This change will help us enable support for any other Broadcom with vendor
> specific device that arrives in the future.
>
> Only the pro
Hi Greg,
> > > > I have no problem exporting a simple sysfs attribute showing if the
> > > > device is either CDMA or GSDM. I would think with that, HAL would not
> > > > need to keep any kind of tables at all, and then the device info only
> > > > has to stay in one place.
> > >
> > > This woul
Hi Greg,
> > > > > I have no problem exporting a simple sysfs attribute showing if the
> > > > > device is either CDMA or GSDM. I would think with that, HAL would not
> > > > > need to keep any kind of tables at all, and then the device info only
> > > > > has to stay in one place.
> > > >
> > >
Hi Dan,
> > > I have no problem exporting a simple sysfs attribute showing if the
> > > device is either CDMA or GSDM. I would think with that, HAL would not
> > > need to keep any kind of tables at all, and then the device info only
> > > has to stay in one place.
> >
> > This would be ideal. I
Hi Daniel,
> > > > It makes no difference if you
> > > > distribute the GPL library with it or not.
> > >
> > > If you do not distribute the GPL library, the library is simply being
> > > used in the intended, ordinary way. You do not need to agree to, nor can
> > > you violate, the GPL simply by
Hi David,
> > Lets phrase this in better words as Valdis pointed out: You can't
> > distribute an application (binary or source form) under anything else
> > than GPL if it uses a GPL library.
>
> This simply cannot be correct. The only way it could be true is if the work
> was a derivative work
Hi David,
> > Anyway you are still under the impression that a Linux kernel module can
> > be original work in the end. We keep telling you that could be a wrong
> > assumption which is based on the view of many of the kernel developers
> > and of most of the lawyers that looked at this specific t
Hi Valdis,
> > And while you are talking to a lawyer. Ask him/her if it is okay to
> > create a binary only application that uses a GPL library. Tell him/her
>
> It's perfectly legal to create such an application.
>
> It only gets interesting if you *distribute* it...
>
> (And yes, this is wher
Hi David,
> > I think you're missing my point: as long as the license stays the way
> > it is now, you can never distribute proprietary code unless you've
> > consulted a lawyer and even then you run the risk of being sued for
> > infringement if the copyright holder thinks what yo
Hi David,
> > I disagree here. They either play by the roles or they really do pay
> > Microsoft or go with BSD. I really couldn't care less.
> Then you should keep away from the kernel. The last thing that Linux
> needs is someone who doesn't care if Linux succeeds or fails. "I don't
> care" wi
Hi Diego,
> > I think it is perfectly within their rights to do so. I think it's
> > kind of silly to try to hide it, if someone wants to boost the maximum
> > transmit power, they're going to hack the firmware anyway. But if it
> > makes Intel happy, well... :-)
> And break the HW :-) Actually,
Hi David,
> >>> I think you're missing my point: as long as the license stays the way
> >>> it is now, you can never distribute proprietary code unless you've
> >>> consulted a lawyer and even then you run the risk of being sued for
> >>> infringement if the copyright holder thinks what you have i
Hi Christer,
> > while the HAL case of Atheros might be still true despite the fact
> > that an OpenHAL has been around for a long time now. The Intel
> > argument is out of the picture since quite some time. The regulatory
> > daemon was an interim solution and has been replaced by a proper
> > f
Hi Graeme,
> > if the overall intention is to write a Linux kernel module/driver then
> > it counts as derivative work for me. No matter how tricky you are and
> > much you try to circumvent or try to hide this fact. However that is my
> > personal opinion. You don't have to agree with me here. As
Hi Alan,
> > To put this in clear and understandable words. The end user has to break
> > the GPL license and thus violate the copyright of the kernel developers.
>
> Not quite - the GPL deals with distribution. You can put whatever you
> like in your own kernel if you don't ever distribute it. S
Hi Graeme,
> > how to do you wanna write a new original Linux driver (modular or
> > built-in) without creating derivative work. This is not possible and due
> > to the fact that it is derivative work the driver becomes automatically
> > licensed under GPL. This is not a gray area.
>
> By not usi
Hi Chris,
> > If the developers say that this symbol can only be used in GPL code (and
> > with EXPORT_SYMBOL_GPL it is quite clear) then you have to obey to that
> > license or don't use this symbol at all.
> >
> > If you use that symbol inside non-GPL (meaning you link at runtime) then
> > you
Hi David,
> > if a new drivers is originally written for Linux, then you are breaking
> > the GPL.
>
> Completely wrong. However if the driver is distributed as built-in, then it
> would need to be licensed under GPL. This means that a driver can be
> written and distributed as a module under
Hi David,
> > I think you're missing my point: as long as the license stays the way
> > it is now, you can never distribute proprietary code unless you've
> > consulted a lawyer and even then you run the risk of being sued for
> > infringement if the copyright holder thinks what you have is derive
Hi Christer,
> > In the cited example it's illegal to go outside certain parameters
> > SOMEWHERE (if it was illegal everywhere, the the hardware shouldn't
> > allow it and the sw could do nothing... not considering hw mods).
> > Another example is WiFi: USA, Europe and Japan allows a different
Hi David,
> > As there is some controversy over the definition of derived work
> > (think Linus' comments on porting a driver or a filesystem from
> > another operating system here), we use the EXPORT_SYMBOL_GPL
> > annotations as a big warning sign that what you're doing is likely to
> > be consi
Hi Dave,
> There's a lot of code motion in the first four patches
> (with no explanation) that seems to be greatly larger than
> the net effect of applying all four patches.
> I did so, just to see the end result, which was a lot more 'reviewable',
> ending up with this..
>
>
> diff --git a/driv
60 matches
Mail list logo