Re: [PATCH] memory mapping for usbfs (v0.4)

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 scanners (which use USBFS) or other

Re: [PATCH] Regression fix revert: Bluetooth: Add missing reset_resume dev_pm_ops

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 make

Re: Plug and play for a tty line disciple networking device

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, it is not a general

Re: [PATCH] USB: mark USB drivers as being GPL only

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 number

Re: [PATCH] USB: mark USB drivers as being GPL only

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 are in

Re: [PATCH] USB: mark USB drivers as being GPL only

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.

Re: [PATCH] USB: mark USB drivers as being GPL only

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 firmware

Re: [PATCH] USB: mark USB drivers as being GPL only

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, they

Re: [PATCH] USB: mark USB drivers as being GPL only

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 will lead

Re: [PATCH] USB: mark USB drivers as being GPL only

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 derived

Re: [PATCH] USB: mark USB drivers as being GPL only

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 topic.

Re: [PATCH] USB: mark USB drivers as being GPL only

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 where you

Re: [PATCH] USB: mark USB drivers as being GPL only

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 using a work in its

Re: right place for CDMA / GSM modem IDs for usbserial autoloading?

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. IIRC the only

Re: right place for CDMA / GSM modem IDs for usbserial autoloading?

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 would be ideal.

Re: right place for CDMA / GSM modem IDs for usbserial autoloading?

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 would be ideal. IIRC the

Re: [PATCH] USB: add USB_VENDOR_AND_INTERFACE_INFO() macro

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 product

Re: new device for qmi_wwan and option Vodafone/ZTE K5006Z

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 only

Re: new device for qmi_wwan and option Vodafone/ZTE K5006Z

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 a new

Re: [RESEND][PATCH] Bluetooth: Make request workqueue freezable

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 unplug/replug for

Re: [RESEND][PATCH] Bluetooth: Make request workqueue freezable

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 first

Re: [PATCH] net:usb:cdc_ncm: fix that tag Huawei devices as wwan

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 the

Re: [PATCH] net:usb:cdc_ncm: fix that tag Huawei devices as wwan

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'

Re: [PATCH 1/2] Bluetooth: Add reset_resume function

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 reset_resume

Re: [PATCH 2/2] Bluetooth: btusb: Add reset_resume function

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 labb...@fedoraproject.org --- Now the setup function is called again with the HCI_RESET_RESUME flag set. The various functions

Re: [PATCH 1/2] Bluetooth: Add reset_resume function

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_resume

Re: [RESEND][PATCH] Bluetooth: Make request workqueue freezable

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 successfully loaded in the first

Re: [RESEND][PATCH] Bluetooth: Make request workqueue freezable

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. A

Re: [RESEND][PATCH] Bluetooth: Make request workqueue freezable

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 certain circumstances. A

Re: Running ADB on a stock distribution (g_ffs)

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 USB_DWC3 config is the one to enable.

Re: [PATCH] Bluetooth: btusb: match generic class code in interface descriptor

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

Re: [PATCH 0984/1285] Replace numeric parameter like 0444 with macro

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

Re: [PATCH 0984/1285] Replace numeric parameter like 0444 with macro

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

Re: [PATCH] bluetooth: bcm203x: don't print error when allocating urb fails

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

Re: [PATCH] usb: quirks: Add reset-resume quirk for QCA6174 Rome Bluetooth

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

Re: [PATCH 2/2] usb: quirks: Add reset-resume quirk for Dell DW1820 QCA Rome Bluetooth

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

Re: [PATCH 2/2] usb: quirks: Add reset-resume quirk for Dell DW1820 QCA Rome Bluetooth

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

Re: [PATCH 1/2] Revert "Bluetooth: btusb: fix QCA Rome suspend/resume"

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 >

Re: [PATCH] Bluetooth: btusb: use irqsave() in URB's complete callback

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

Re: [PATCH] Bluetooth: btusb: use irqsave() in URB's complete callback

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