Re: GPS driver for Linux - kernel or user-space driver?
Hi Greg, >> I've been approached by a developer at Sony who wants to publish an >> open source driver for a Sony GPS receiver module. > > What does the device look like? USB device? UART? Something else? > >> I've looked in the kernel source, and only see one standalone GPS >> driver, for Garmin. It appears that most GPS support in Linux is done >> via user-space drivers. Many GPS hardware modules appear to be >> accessed via a serial line, or USB/serial port. The Sony >> module is pretty much the same, accepting commands and delivering >> data via a uart from the chip. >> >> I planning to recommend writing a user-space driver (based on >> gpsd and/or the Android GPS HAL specification). But I'm worried >> I'm missing something. Is this the correct approach, or is there >> an established kernel API for GPS modules - such that I should >> recommend that this developer writes a kernel module instead >> of, or in addition to, the user-space support for the hardware? > > If it's just a uart-like device, just write a serial driver and drive it > from gpsd. That way seems to be the simplest and then the kernel just > becomes a dumb-pipe, which is fine. the one thing that still bugs me is that detecting an UART with GPS functionality behind it is extremely bad experience. If we could get something like DEVTYPE=gps support for the TTY layer, that would be helpful. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPS driver for Linux - kernel or user-space driver?
Hi Greg, I've been approached by a developer at Sony who wants to publish an open source driver for a Sony GPS receiver module. >>> >>> What does the device look like? USB device? UART? Something else? >>> I've looked in the kernel source, and only see one standalone GPS driver, for Garmin. It appears that most GPS support in Linux is done via user-space drivers. Many GPS hardware modules appear to be accessed via a serial line, or USB/serial port. The Sony module is pretty much the same, accepting commands and delivering data via a uart from the chip. I planning to recommend writing a user-space driver (based on gpsd and/or the Android GPS HAL specification). But I'm worried I'm missing something. Is this the correct approach, or is there an established kernel API for GPS modules - such that I should recommend that this developer writes a kernel module instead of, or in addition to, the user-space support for the hardware? >>> >>> If it's just a uart-like device, just write a serial driver and drive it >>> from gpsd. That way seems to be the simplest and then the kernel just >>> becomes a dumb-pipe, which is fine. >> >> the one thing that still bugs me is that detecting an UART with GPS >> functionality behind it is extremely bad experience. If we could get >> something like DEVTYPE=gps support for the TTY layer, that would be >> helpful. > > I would love that, but there's tons of USB gps devices that we don't > know if they are a USB serial device, or a GPS device as the device id > is the same (companies just embed a usb to serial chip in their > devices.) > > So, someone has to guess, right now it's userspace. > > Unless you have a better idea? we could at least try to fix the good ones where we have proper vendor and product IDs dedicated for these devices. Or where things can be labeled through device tree or some similar methods. The less guess work userspace has to do, the smooth the experience will be. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/7] net/bluetooth/rfcomm/core.c: fix error return code
Hi Julia,
> Initialize return variable before exiting on an error path.
>
> A simplified version of the semantic match that finds this problem is as
> follows: (http://coccinelle.lip6.fr/)
>
> //
> (
> if@p1 (\(ret < 0\|ret != 0\))
> { ... return ret; }
> |
> ret@p1 = 0
> )
> ... when != ret = e1
> when != &ret
> *if(...)
> {
> ... when != ret = e2
> when forall
> return ret;
> }
>
> //
>
> Signed-off-by: Julia Lawall
>
> ---
> net/bluetooth/rfcomm/core.c |4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
Acked-by: Marcel Holtmann
Regards
Marcel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Build error on PowerPC
Hi, I get the following build error on PowerPC: CC [M] sound/ppc/awacs.o In file included from sound/ppc/awacs.c:25: include/asm/nvram.h:62: error: field ‘partition’ has incomplete type make[2]: *** [sound/ppc/awacs.o] Error 1 make[1]: *** [sound/ppc] Error 2 make: *** [sound] Error 2 Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][v4] ipwireless: driver for 3G PC Card
Hi David,
> +irqreturn_t ipwireless_interrupt(int irq, void *dev_id, struct pt_regs *regs)
> +{
> + struct ipw_hardware *hw = dev_id;
> +
> + if (hw->hw_version == HW_VERSION_1)
> + return ipwireless_handle_v1_interrupt(irq, hw);
> + else
> + return ipwireless_handle_v2_v3_interrupt(irq, hw);
> +}
why is this not static? I think the interrupt routine should be in the
file where you actually claim the interrupt.
> +/*
> + * Associate the specified network with this hardware, so it will receive
> events
> + * from it.
> + */
> +void ipwireless_associate_network(struct ipw_hardware *hw,
> + struct ipw_network *network)
> +{
> + hw->network = network;
> +}
I think a #define would be simpler in this case.
> +module_param(tty_major, int, 0);
> +module_param_named(debug, ipwireless_debug, int, 0);
> +module_param_named(loopback, ipwireless_loopback, int, 0);
> +module_param_named(out_queue, ipwireless_out_queue, int, 0);
> +MODULE_PARM_DESC(tty_major, "ttyIPWp major number [0]");
Why is allowing to change the major still needed. I think we passed the
bridge of the need for static numbers a long long long time ago.
> +static const char drv_name[] = IPWIRELESS_PCCARD_NAME;
This looks useless to. Do we need that?
Regards
Marcel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Build error on PowerPC
Hi Olof, > Please define what kernel version and what config you're trying to > build. it is the latest kernel for Linus' git and the config is kinda obviously enabling the awacs.c driver. Anyway, the driver didn't make use of the NVRAM call and thus removing that include is perfectly fine. Attached patch fixes that issue. > Also, please cc [EMAIL PROTECTED] for powerpc issues. To be quite honest, it is highly likely that I forget the next time. Good that you read LKML :) Regards Marcel [PATCH] Fix compilation of sound/ppc/awacs.c Including of asm/nvram.h in the awacs.c driver is not needed and it fixes the following compilation error: CC [M] sound/ppc/awacs.o In file included from sound/ppc/awacs.c:25: include/asm/nvram.h:62: error: field ‘partition’ has incomplete type make[2]: *** [sound/ppc/awacs.o] Error 1 make[1]: *** [sound/ppc] Error 2 make: *** [sound] Error 2 Signed-off-by: Marcel Holtmann <[EMAIL PROTECTED]> --- commit 5613f9f9aa321cf59915137cc611aea9fd95ed75 tree 3c55137ccc3d16e49b757a0e6135f32fb2086ae3 parent aa6299926950c8dfe2fea638276cad6def092bc9 author Marcel Holtmann <[EMAIL PROTECTED]> Sat, 02 Feb 2008 03:52:23 +0100 committer Marcel Holtmann <[EMAIL PROTECTED]> Sat, 02 Feb 2008 03:52:23 +0100 sound/ppc/awacs.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/sound/ppc/awacs.c b/sound/ppc/awacs.c index 8441e78..149c4aa 100644 --- a/sound/ppc/awacs.c +++ b/sound/ppc/awacs.c @@ -21,7 +21,6 @@ #include -#include #include #include #include
ACPI problem on PowerPC
Hi Greg, the following happens with the latest ACPI and PCI merges on my Quad G5: CC drivers/pci/pcie/aspm.o In file included from include/acpi/platform/acenv.h:140, from include/acpi/acpi.h:54, from include/acpi/acpi_bus.h:31, from drivers/pci/pcie/aspm.c:20: include/acpi/platform/aclinux.h:59:22: error: asm/acpi.h: No such file or directory In file included from include/acpi/platform/aclinux.h:120, from include/acpi/platform/acenv.h:140, from include/acpi/acpi.h:54, from include/acpi/acpi_bus.h:31, from drivers/pci/pcie/aspm.c:20: include/acpi/actypes.h:130: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘UINT64’ include/acpi/actypes.h:131: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘INT64’ include/acpi/actypes.h:753: error: expected ‘)’ before ‘*’ token include/acpi/actypes.h:756: error: expected ‘)’ before ‘*’ token In file included from include/acpi/acpi.h:61, from include/acpi/acpi_bus.h:31, from drivers/pci/pcie/aspm.c:20: include/acpi/acpiosxf.h:178: error: expected declaration specifiers or ‘...’ before ‘acpi_osd_handler’ include/acpi/acpiosxf.h:182: error: expected declaration specifiers or ‘...’ before ‘acpi_osd_handler’ include/acpi/acpiosxf.h:191: error: expected declaration specifiers or ‘...’ before ‘acpi_osd_exec_callback’ make[3]: *** [drivers/pci/pcie/aspm.o] Error 1 make[2]: *** [drivers/pci/pcie] Error 2 make[1]: *** [drivers/pci] Error 2 make: *** [drivers] Error 2 The Quad G5 has PCI Express, but I am not sure about the ASPM support. Obviously I enabled CONFIG_PCIEASPM. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
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 considered as a derived work.
> Let's consider a totally original USB driver. There are an infinite
> number of them, some still to be written.
if a new drivers is originally written for Linux, then you are breaking
the GPL. There is no other way to name this. Using EXPORT_SYMBOL or
EXPORT_SYMBOL_GPL make no difference here. You driver was meant to be
running as Linux kernel module and thus it is derivative work. While
there is a gray area, but this case has always been pretty clear.
> > If the USB developers want to
> > annotate their code with EXPORT_SYMBOL_GPL, why the hell do you want
> > to argue about it?
> Have I the wrong end of the stick? Isn't that mark restricting an
> interface to GPL _callers_?Isn't it a technical switch that means,
> "Don't use my software if yours isn't (also) GPL"? As such it's mere
> political rhetoric, devoid of any binding power.
What are you arguing here. It makes no difference if it is technical or
not. The EXPORT_SYMBOL_GPL gives you a clear hint that when using this
symbol, you have to obey to the GPL. Even the EXPORT_SYMBOL is protected
by the same GPL license. And thus both has the same binding power to be
used from GPL modules only.
At this point I would strongly advise to talk to lawyer since you are
obvious missing the point here.
> > If you want to
> > develop for Linux, you're most certainly better off always
> > distributing your code under the GPLv2
>
> I agree; but let's not disadvantage applications where regulatory
> requirements prohibit GPL code, nor applications where the proprietor
> simply chooses to keep the work proprietary. A proprietary module is
> simply a piece of software. Many people couldn't use Linux if they
> couldn't run proprietary software on it.
First of all we are talking about kernel modules here. Not the
userspace. So stop this FUD.
> > But what I don't understand
> > is why people insist using the Linux kernel for something it clearly
> > can never really properly support (proprietary code)?
> >
>
> That's defeatist. Of course the Linux kernel can properly support
> ("run") proprietary code. It would be a miserable excuse for an
> operating system if it couldn't.
In userspace, yes, the kernel would "run" proprietary code fully legally
without any problem. As a kernel module, the only safe answer is no. And
in case of EXPORT_SYMBOL_GPL, it is pretty clear. You would obviously
violate the license.
Regards
Marcel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: What's about WiMAX?
Hi Marc, > i have here a few wimax 802.16e zyxel pcmcia cards, which only work on > windows. is anybody interrested in developing a driver for these wimax cards? are these PCMCIA or CardBus cards. Or do they actually end up exposing an USB host controller? Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Where to send new pcmcia driver?
Hi Kristoffer, > Im almost finished with my pcmcia driver for the h64461 chipset, it works > fine just need to clean it up. > > Now looking at the MAINTAINER list it doesn't reference anyone special as the > maintainer for pcmcia subsystem. > So in short where should I send the patch? > > Also, I've tried on numerous occasions to seek help on pcmcia list and > besides some helpful replies from Peter Stuge, it's been > silent. Perhaps linux-pcmcia mailinglist would be better off getting merged > into linux-main list? post it to LKML for review. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 > > of channels. But every AP I have had simply asks which country the user > > is in, then allows only a limited choice for the channel to use. > > If I'm in Europe but tell my AP that I'm in Japan, it lets me choose > > channel 13 (Europe allows up to ch 11). If the "cops" find it out, they > > prosecute ME, not my AP! It's not a TECHNICAL limit, it's a LEGAL one. > > So there's no point in keeping a driver closed *just* because else > > someone could hack it to make it work outside the allowed parameters: > > even a closed driver is hackable (just reverse engineer it...). > > > > Think about this scenario: a closed source driver contains: > > if(power<100) > > setpower(power); > > else > > setpower(100); > > to limit tx power and make it legal. Then the user finds this 100 and > > replaces it with 255 (inside the binary-only module), actually allowing > > for more than twice (if power is in mW) the legally permitted power. > > Is it legal? > > > I don't think so (and I doubt you can find any lawyer that does). But > > it's not THE DRIVER that's doing something illegal. It's THE USER. > > It would be equally illegal if the driver was open source. Simpler to > > do, but equally illegal. > > It isn't that easy. The "Tamper-Proof Torx" screws on a vacuum cleaner > or a toaster won't stop anybody from opening up the thing, I mean every > little hardware store stocks those Torx bits. But by using a slightly > odd screw, the company can say "look, we'we done all we can to stop > them, but the user bypassed our security device, and it's not our > fault". Apparently Intel and Atheros are trying to protect themselves > in a similar way, they Open Source everything except for the regulatory > daemon (Intel) or HAL object file (Atheros). Why? Because they belive > that if they give away the sources to those parts they do the software > equivalent of putting a normal Phillips screw in a home appliance. > (Personally I think what they are doing is ridiculous, but apparently > those companies' lawyers dont' agree). 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 solution. So please get your examples up-to-date. You might wanna now point to hiding something in firmware, but the hardware, firmware, driver separation (with being hardware and firmware closed source) is an accepted solution. It is a clean separation. Interface wise and license wise. Remember that nobody inside the community ever asked for any kind of IP or trade secrets. We only want specifications so we can write the drivers under an appropriate open source license. If the specification describes an API exposed via firmware then that is perfectly fine. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][BLUETOOTH] add HCI_BROKEN_ISOC for 0e5e:6622 (bugzilla #9027)
Hi, > This patch fix bugzilla #9027. > ``Syslog flooded with "hci_scodata_packet: hci0 SCO packet for unknown > connection handle 92" message" > > see http://bugzilla.kernel.org/show_bug.cgi?id=9027 when we get the content of /proc/bus/usb/devices for this one. Do you have the manufacturer name of it or at least an idea which kind of device this is. Check "hciconfig hci0 version". Dave, I don't think this is a broken dongle. I think he hits the case of eSCO versus SCO connection (the fallback to SCO case). I am working on the proper fix for that, but that is not as simple as it seems. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][BLUETOOTH] add HCI_BROKEN_ISOC for 0e5e:6622 (bugzilla #9027)
Hi, > >> This patch fix bugzilla #9027. > >> ``Syslog flooded with "hci_scodata_packet: hci0 SCO packet for unknown > >> connection handle 92" message" > >> > >> see http://bugzilla.kernel.org/show_bug.cgi?id=9027 > >> > > > > when we get the content of /proc/bus/usb/devices for this one. Do you > > have the manufacturer name of it or at least an idea which kind of > > device this is. Check "hciconfig hci0 version". > > > It have no text on the chips and package, so I don't know the > manufacturer name. and what about "hciconfig hci0 version"? > /proc/bus/usb/devices shows: > > > T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 > D: Ver= 1.10 Cls=e0(unk. ) Sub=01 Prot=01 MxPS=16 #Cfgs= 1 > P: Vendor=0e5e ProdID=6622 Rev= 1.34 > C:* #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=100mA > I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb > E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms > E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms > E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms > I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb > E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms > E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms > I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb > E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms > E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms > I:* If#= 1 Alt= 2 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb > E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms > E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms That is not all. Otherwise it is violating the Bluetooth HCI USB specification and we have bigger problems when switching USB alternate endpoints. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Bluez-devel] [PATCH 14/14] net/bluetooth/hci_core.c: Use time_* macros
Hi, > The functions time_before, time_before_eq, time_after, and time_after_eq are > more robust for comparing jiffies against other values. > > So following patch implements usage of the time_after() macro, defined at > linux/jiffies.h, which deals with wrapping correctly > > Cc: [EMAIL PROTECTED] > Signed-off-by: S.Çağlar Onur <[EMAIL PROTECTED]> since this is full serious of patches, I am not sure if it should go via the subsystem maintainers or better applied as whole. In case of Linus or Andrew decide to take them all at once and push them, this on is acked by me. Acked-by: Marcel Holtmann <[EMAIL PROTECTED]> Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Bluetooth: Another vendor specific ID for BCM20702A0 [0a5c:21f1]
Hi Michael, > Bus 002 Device 003: ID 0a5c:21f1 Broadcom Corp. > Device Descriptor: > bLength18 > bDescriptorType 1 > bcdUSB 2.00 > bDeviceClass 255 Vendor Specific Class > bDeviceSubClass 1 > bDeviceProtocol 1 > bMaxPacketSize064 > idVendor 0x0a5c Broadcom Corp. > idProduct 0x21f1 > bcdDevice1.12 > iManufacturer 1 Broadcom Corp > iProduct2 BCM20702A0 > iSerial 3 9CB70DCFF833 > bNumConfigurations 1 as usual include /sys/kernel/debug/usb/devices details for this device. I want the full set of endpoint descriptors in a simple compact format in the commit messages for reference. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Unable to Detect Bluetooth Device on Macbook Pro 9,2 (Mid-2012 13")
Hi Shea, > Please CC me on response, I am not subscribed to the list. > > hcitool is unable to detect my laptop's bluetooth device: > > $ lsusb > Bus 004 Device 009: ID 05ac:821d Apple, Inc. > Bus 004 Device 008: ID 05ac:820b Apple, Inc. > Bus 004 Device 007: ID 05ac:820a Apple, Inc. > Bus 004 Device 006: ID 05ac:0252 Apple, Inc. > Bus 004 Device 005: ID 05ac:8242 Apple, Inc. IR Receiver [built-in] > Bus 004 Device 004: ID 0a5c:4500 Broadcom Corp. BCM2046B1 USB 2.0 Hub > (part of BCM2046 Bluetooth) > Bus 004 Device 003: ID 0424:2513 Standard Microsystems Corp. > Bus 004 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub > Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > Bus 003 Device 003: ID 05ac:8509 Apple, Inc. > Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > Bus 003 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub > > $ dmesg > > [4.744248] usb 4-1.8.1.3: new full-speed USB device number 9 using > ehci_hcd > [4.822041] usb 4-1.8.1.3: New USB device found, idVendor=05ac, > idProduct=821d > [4.822830] usb 4-1.8.1.3: New USB device strings: Mfr=1, Product=2, > SerialNumber=0 > [4.823582] usb 4-1.8.1.3: Product: Bluetooth USB Host Controller > [4.824329] usb 4-1.8.1.3: Manufacturer: Apple Inc. > > > $ hciconfig -a > > $ hcitool dev > Devices: > > $ lsmod | grep bluetooth > bluetooth 187731 0 > rfkill 15546 2 bluetooth,cfg80211 > crc16 1311 2 bluetooth,ext4 > > Any ideas? include /sys/kernel/debug/usb/devices details for this device. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Unable to Detect Bluetooth Device on Macbook Pro 9,2 (Mid-2012 13")
Hi Shea, > > include /sys/kernel/debug/usb/devices details for this device. > > Not sure, which device it is, so here's all of bus 4: > T: Bus=04 Lev=04 Prnt=04 Port=02 Cnt=03 Dev#= 9 Spd=12 MxCh= 0 > D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 > P: Vendor=05ac ProdID=821d Rev= 0.86 > S: Manufacturer=Apple Inc. > S: Product=Bluetooth USB Host Controller > C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr= 0mA > I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none) > E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms > E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms > E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms > I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) > E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms > E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms > I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) > E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms > E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms > I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) > E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms > E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms > I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) > E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms > E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms > I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) > E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms > E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms > I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) > E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms > E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms > I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) > E: Ad=84(I) Atr=02(Bulk) MxPS= 32 Ivl=0ms > E: Ad=04(O) Atr=02(Bulk) MxPS= 32 Ivl=0ms > I:* If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none) lets take the one that says Bluetooth USB Host Controller ;) Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] btusb: fix overflow return values
Hi Adam, > PTR_ERR() returns a long type value, but btusb_setup_intel() and > btusb_setup_intel_patching() should return an int type value. > > This bug makes the judgement "if (ret < 0)" not working on x86_64 > architecture systems, leading to failure as below, even panic. > > [ 12.958920] Bluetooth: hci0 command 0xfc8e tx timeout > [ 14.961765] Bluetooth: hci0 command 0xfc8e tx timeout > [ 16.964688] Bluetooth: hci0 command 0xfc8e tx timeout > [ 20.954501] Bluetooth: hci0 sending Intel patch command (0xfc8e) failed > (-110) > [ 22.957358] Bluetooth: hci0 command 0xfc8e tx timeout > [ 30.948922] Bluetooth: hci0 sending Intel patch command (0xfc8e) failed > (-110) > [ 32.951780] Bluetooth: hci0 command 0xfc8e tx timeout > [ 40.943359] Bluetooth: hci0 sending Intel patch command (0xfc8e) failed > (-110) > [ 42.946219] Bluetooth: hci0 command 0xfc8e tx timeout > [ 50.937812] Bluetooth: hci0 sending Intel patch command (0xfc8e) failed > (-110) > [ 52.940670] Bluetooth: hci0 command 0xfc8e tx timeout > [ 60.932236] Bluetooth: hci0 sending Intel patch command (0xfc8e) failed > (-110) > [ 62.935092] Bluetooth: hci0 command 0xfc8e tx timeout > [ 70.926688] Bluetooth: hci0 sending Intel patch command (0xfc8e) failed > (-110) > [ 72.929545] Bluetooth: hci0 command 0xfc8e tx timeout > [ 80.92] Bluetooth: hci0 sending Intel patch command (0xfc8e) failed > (-110) > [ 82.923969] Bluetooth: hci0 command 0xfc2f tx timeout > [ 90.915542] Bluetooth: hci0 sending Intel patch command (0xfc2f) failed > (-110) > [ 92.918406] Bluetooth: hci0 command 0xfc11 tx timeout > [ 100.909955] Bluetooth: hci0 sending Intel patch command (0xfc11) failed > (-110) > [ 102.912858] Bluetooth: hci0 command 0xfc60 tx timeout > [ 110.904394] Bluetooth: hci0 sending Intel patch command (0xfc60) failed > (-110) > [ 112.907293] Bluetooth: hci0 command 0xfc11 tx timeout > [ 120.898831] Bluetooth: hci0 exiting Intel manufacturer mode failed (-110) > [ 120.904757] bluetoothd[1030]: segfault at 4 ip 7f8b2eb55236 sp > 7fff53ff6920 error 4 in bluetoothd[7f8b2eaff000+cb000] > > For not affecting other modules, I choose to modify the return values > but not extend btusb_setup_intel() and btusb_setup_intel_patching()'s > return types. This is harmless, because the return values were only > used to comparing number 0. there are tons of examples in various subsystems and drivers where we return PTR_ERR from a function calls returning int. So I wonder what is actually going wrong here. If this is x86_64 specific problem with PTR_ERR vs int, then we should have this problem everywhere in the kernel. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.11-final plan: unpriviledged user can crash the kernel (using bluetooth rfcomm)
Hi Pavel, >> . Python sources for client/server are at >> >> http://tui.cvs.sourceforge.net/viewvc/tui/tui/liveview/ >> >> . My kernels like to warn about > System is debian stable with gnome2. And no, it is not fixed in 3.11-rc7. >>> >>> 2.6.32-5-686 from debian seems to work. >> >> Could you try linux-next? We recently pushed a rework of the RFCOMM tty >> handling, it should fix this. The work was too big to be pushed to 3.11 > > So... In 3.11 unpriviledged user can crash the kernel, but the fix is > too big, so we release it without the fix? > > Somehow, I don't think that's good idea. can you boot a bluetooth-next kernel and see if the planned changes are fixing this or not. I would like to have that confirmed before we start any speculations here. If the RFCOMM TTY rework that we have in bluetooth-next fixes this issue, then we can have a look at if this can be patched for 3.11 or a stable kernel without having to include the whole patch series. Or if the TTY subsystem changed from 2.6.32 so much that we have to take the whole changes. However, please also note there is a different between RFCOMM sockets and RFCOMM TTYs. I would be curious if only the TTY part is affected or also the socket part. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers: bluetooth: btusb: Added support for Belkin F8065bf usb bluetooth device
Hi Ken,
> Belkin bluetooth device's usb device id added to generic usb bluetooth driver.
>
> It's another instance of Broadcom's BCM20702A0.
>
> Relevant section from /sys/kernel/debug/usb/devices:
>
> T: Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
> D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
> P: Vendor=050d ProdID=065a Rev= 1.12
> S: Manufacturer=Broadcom Corp
> S: Product=BCM20702A0
> S: SerialNumber=0002723E2D29
> C:* #Ifs= 4 Cfg#= 1 Atr=a0 MxPwr=100mA
> I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
> E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
> E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
> E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
we might consider a generic rule for this:
/* comment of the device vendor and type goes here */
{ USB_VENDOR_AND_INTERFACE_INFO(0x050d, 0xff, 0x01, 0x01) },
Regards
Marcel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers: bluetooth: btusb: Added support for Belkin F8065bf usb bluetooth device
Hi Ken,
> Adding generic rule for broadcom devices to generic usb bluetooth driver on
> encountering another instance of Broadcom's BCM20702A0.
>
> Relevant section from /sys/kernel/debug/usb/devices:
>
> T: Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
> D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
> P: Vendor=050d ProdID=065a Rev= 1.12
> S: Manufacturer=Broadcom Corp
> S: Product=BCM20702A0
> S: SerialNumber=0002723E2D29
> C:* #Ifs= 4 Cfg#= 1 Atr=a0 MxPwr=100mA
> I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
> E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
> E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
> E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
> I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
> E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
> E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
> I: If#= 1 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
> E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
> E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
> I: If#= 1 Alt= 2 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
> E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
> E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
> I: If#= 1 Alt= 3 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
> E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
> E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
> I: If#= 1 Alt= 4 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
> E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
> E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
> I: If#= 1 Alt= 5 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
> E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
> E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
> I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
> E: Ad=84(I) Atr=02(Bulk) MxPS= 32 Ivl=0ms
> E: Ad=04(O) Atr=02(Bulk) MxPS= 32 Ivl=0ms
> I:* If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)
>
> Signed-off-by: Ken O'Brien
> ---
> drivers/bluetooth/btusb.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> index 8e16f0a..6d33dca 100644
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -111,6 +111,7 @@ static struct usb_device_id btusb_table[] = {
>
> /*Broadcom devices with vendor specific id */
> { USB_VENDOR_AND_INTERFACE_INFO(0x0a5c, 0xff, 0x01, 0x01) },
> + { USB_VENDOR_AND_INTERFACE_INFO(0x050d, 0xff, 0x01, 0x01) },
this is not correct. These devices are Broadcom based, but they are actually
from Belkin. Same as the controllers from Apple. So it needs its own line and a
comment that mentions Belkin.
Regards
Marcel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/5] Bluetooth: Fix assignment of 0/1 to bool variables
Hi Peter, > Convert 0 to false and 1 to true when assigning values to bool > variables. Inspired by commit 3db1cd5c05f35fb43eb134df6f321de4e63141f2. > > The simplified semantic patch that find this problem is as > follows (http://coccinelle.lip6.fr/): > > @@ > bool b; > @@ > ( > -b = 0 > +b = false > | > -b = 1 > +b = true > ) > > Signed-off-by: Peter Senna Tschudin > > --- > net/bluetooth/l2cap_core.c | 16 ---- > 1 file changed, 8 insertions(+), 8 deletions(-) Acked-by: Marcel Holtmann Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/12] bluetooth: Remove extern from function prototypes
Hi Joe, > There are a mix of function prototypes with and without extern > in the kernel sources. Standardize on not using extern for > function prototypes. > > Function prototypes don't need to be written with extern. > extern is assumed by the compiler. Its use is as unnecessary as > using auto to declare automatic/local variables in a block. > > Signed-off-by: Joe Perches > --- > include/net/bluetooth/bluetooth.h | 16 > include/net/bluetooth/hci_core.h | 23 +++ > include/net/bluetooth/rfcomm.h| 4 ++-- > 3 files changed, 21 insertions(+), 22 deletions(-) Acked-by: Marcel Holtmann Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/10] drivers/bluetooth/bluecard_cs.c: removes unnecessary semicolon
Hi Peter, > removes unnecessary semicolon > > Found by Coccinelle: http://coccinelle.lip6.fr/ > > Signed-off-by: Peter Senna Tschudin > > --- > drivers/bluetooth/bluecard_cs.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Acked-by: Marcel Holtmann Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/10] drivers/bluetooth/hci_ldisc.c: removes unnecessary semicolon
Hi Peter, > removes unnecessary semicolon > > Found by Coccinelle: http://coccinelle.lip6.fr/ > > Signed-off-by: Peter Senna Tschudin > > --- > drivers/bluetooth/hci_ldisc.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Acked-by: Marcel Holtmann Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/10] drivers/bluetooth/hci_ll.c: removes unnecessary semicolon
Hi Peter, > removes unnecessary semicolon > > Found by Coccinelle: http://coccinelle.lip6.fr/ > > Signed-off-by: Peter Senna Tschudin > > --- > drivers/bluetooth/hci_ll.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Acked-by: Marcel Holtmann Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/10] drivers/bluetooth/hci_vhci.c: removes unnecessary semicolon
Hi Peter, > removes unnecessary semicolon > > Found by Coccinelle: http://coccinelle.lip6.fr/ > > Signed-off-by: Peter Senna Tschudin > > --- > drivers/bluetooth/hci_vhci.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Acked-by: Marcel Holtmann Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 10/10] drivers/bluetooth/btuart_cs.c: removes unnecessary semicolon
Hi Peter, > removes unnecessary semicolon > > Found by Coccinelle: http://coccinelle.lip6.fr/ > > Signed-off-by: Peter Senna Tschudin > > --- > drivers/bluetooth/btuart_cs.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Acked-by: Marcel Holtmann Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/21] TTY: hci_ldisc, remove invalid check in open
Hi Jiri, > hci_ldisc's open checks if tty_struct->disc_data is set. And if so it > returns with an error. But nothing ensures disc_data to be NULL. And > since ld->ops->open shall be called only once, we do not need the > check at all. So remove it. > > Note that this is not an issue now, but n_tty will start using the > disc_data pointer and this invalid 'if' would trigger then rendering > TTYs over BT unusable. > > Signed-off-by: Jiri Slaby > Cc: Marcel Holtmann > Cc: Gustavo Padovan > Cc: Johan Hedberg > Cc: linux-blueto...@vger.kernel.org > --- > drivers/bluetooth/hci_ldisc.c | 7 +------ > 1 file changed, 1 insertion(+), 6 deletions(-) Acked-by: Marcel Holtmann Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND net-next] bluetooth: hci_core: Replace list_for_each with list_for_each_entry() helper
Hi Denis, > Replace list_for_each with list_for_each_entry() helper > > Signed-off-by: Denis Kirjanov > --- > include/net/bluetooth/hci_core.h | 20 > 1 files changed, 8 insertions(+), 12 deletions(-) Acked-by: Marcel Holtmann Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net-sysfs: Add entry for nl80211 interface type
Hi Bing, > Add a "wireless/nl80211_iftype" entry in the net device sysfs > file structure to indicate the mode of the wireless device so > it can be discovered easily from userspace. I do question a little bit the usefulness for this one. It would only work on netdev and on wdev devices. Using nl80211 to discover this information seems a lot better approach. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net-sysfs: Add entry for nl80211 interface type
Hi Nicolas, >>> Add a "wireless/nl80211_iftype" entry in the net device sysfs >>> file structure to indicate the mode of the wireless device so >>> it can be discovered easily from userspace. >> >> What's wrong with "iw dev", i.e. netlink/nl80211? > > "Do NOT screenscrape this tool, we don't consider its output stable." > > So if you are in a shell script, you're basically screwed. if you are in a shell script, you are screwed no matter what. So what is your point? Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net-sysfs: Add entry for nl80211 interface type
Hi Paul, > The original reason to request this change was simple: to figure out > what type of interface we are looking at, since now some wireless > drivers can simultaneously create managed, p2p and ap interfaces. > Knowing that, from a simple front-end (let's even say a shell script) > we can decide what arguments to use with wpa_supplicant (or indeed if > we want to start it on this interface). wpa_supplicant, of course, > knows how to manipulate the device further using nl80211. I thought > it was a bit onerous to force userspace all the way through nl80211 > just to get this trivial piece of information, but apparently this > doesn't seem to be the common point of view. quite frankly this is a design issue with wpa_supplicant since it refuses to manage the wireless devices and interfaces. If you would have a real daemon that manages the wireless device via nl80211, then you would never ever have this problem. All the information are available via nl80211. However my point is that you can not just base this around netdev exposed interfaces. The netdev interface might not even be present. Especially when talking about P2P you might not have a netdev in the first place. You only have a wdev. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net-sysfs: Add entry for nl80211 interface type
Hi Bing, >>> Add a "wireless/nl80211_iftype" entry in the net device sysfs >>> file structure to indicate the mode of the wireless device so >>> it can be discovered easily from userspace. >> >> I do question a little bit the usefulness for this one. >> It would only work on netdev and on wdev devices. > > It's true. That's why the new sysfs entry is added in the 'wireless' > placeholder. > > /sys/class/net/ethX/wireless/ > > For non-wireless dev, this won't apply. I have to correct myself. I meant it does NOT work for wdev. Please just go with nl80211 for this kind of information. It is the right way to handle it. Not some sysfs file. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pull request: bluetooth 2013-06-23
Hi Pavel, >> Jaganath Kanakkassery (1): >> Bluetooth: Fix invalid length check in l2cap_information_rsp() > > Could we add the "3.10 vs. thinkpad x60" patch that fixes regression? > It is from Johan Hedberg… that one went into net-next tree. It is scheduled for 3.11 right now. After 3.10 is out, maybe it can go into -stable, but otherwise I think it is bit late now. Unless someone wants to cherry-pick it. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] bluetooth: remove wrong dependency for BT_ATH3K
Hi Hector, > The Atheros firmware download driver is not dependent on HCI > USB driver. This driver is needed to complement any Atheros > driver like BT_HCIUART_ATH3K. > > Signed-off-by: Hector Palacios > CC: Suraj Sumangala > CC: Vikram Kandukuri > --- > drivers/bluetooth/Kconfig | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig > index 11a6104..a1d482b 100644 > --- a/drivers/bluetooth/Kconfig > +++ b/drivers/bluetooth/Kconfig > @@ -222,7 +222,6 @@ config BT_MRVL_SDIO > > config BT_ATH3K > tristate "Atheros firmware download driver" > - depends on BT_HCIBTUSB > select FW_LOADER > help > Bluetooth firmware download driver. > I am confused now. How can an USB driver work with an UART driver? If you do not want to depend on BT_HCIBTUSB then that is fine, but at least you need to depend on USB. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Apr 26 (nfc)
Hi Randy, >> Hi all, >> >> Changes since 20130424: >> > > > on i386: > > net/built-in.o: In function `nfc_unregister_device': > (.text+0x6a36d): undefined reference to `rfkill_unregister' > net/built-in.o: In function `nfc_unregister_device': > (.text+0x6a378): undefined reference to `rfkill_destroy' > net/built-in.o: In function `nfc_register_device': > (.text+0x6a493): undefined reference to `rfkill_alloc' > net/built-in.o: In function `nfc_register_device': > (.text+0x6a4a4): undefined reference to `rfkill_register' > net/built-in.o: In function `nfc_register_device': > (.text+0x6a4b3): undefined reference to `rfkill_destroy' > net/built-in.o: In function `nfc_dev_up': > (.text+0x6a8e8): undefined reference to `rfkill_blocked' > > > when CONFIG_RFKILL=m but NFC is builtin. > > Full randconfig file is attached. it is missing the depends RFKILL || !RFKILL here. I send a patch for it. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Bluetooth: Add support for Apple vendor-specific devices
Hi Henrik, > As pointed out by Gustavo and Marcel, all Apple-specific Broadcom > devices seen so far have the same interface class, subclass and > protocol numbers. This patch adds an entry which matches all of them, > using the new USB_VENDOR_AND_INTERFACE_INFO() macro. > > In particular, this patch adds support for the MacBook Pro Retina > (05ac:8286), which is not in the present list. > > Signed-off-by: Henrik Rydberg > --- > Hi Gustavo, > > here is a patch for the Apple devices, utilizing commit d81a5d19, for > 3.6. Tested on the MacBookPro10,1 (Retina). If you want, I can > follow-up with a patch for 3.7 which removes the specific entries. I > have verified the lsusb output of all of them, except MacMini5,1. > > Thanks, > Henrik > > drivers/bluetooth/btusb.c | 3 +++ > 1 file changed, 3 insertions(+) Acked-by: Marcel Holtmann Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] add support bluetooth usb 0489:e046 Foxconn / Hon Hai
Hi, > $ usb-deveices > T: Bus=01 Lev=02 Prnt=02 Port=02 Cnt=03 Dev#= 5 Spd=12 MxCh= 0 > D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 > P: Vendor=0489 ProdID=e046 Rev=01.12 > S: Manufacturer=Broadcom Corp > S: Product=BCM20702A0 > S: SerialNumber=C01885F67F9E > C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA > I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none) > I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none) > I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) > I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none) > > $ lsusb > Bus 001 Device 005: ID 0489:e046 Foxconn / Hon Hai you need a Signed-off-by here. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Plans for mISDN? Was: [PATCH 00/14] [ISDN] ...
Hi Andi, If noone in the isdn community step up and take some responsibility for the current isdn drivers in Linux then we should just delete them. So you're saying anything that has no active maintainer should be immediately deleted? You do not recognize a provocation when you see it? I wanted a reaction from the isdn community - and I got so. So lets look forward. Well it was more a lie because you couldn't possibly make up to your threat anyways. I'm not sure either it's a good idea to try to merge mISDN if the maintainers don't think it is ready yet. you can't wait until it is perfect. Then it never gets merged. The out- of-tree ISDN stuff has always been painful. And that was already in the ISDN4Linux days which were Linux 2.2 days or even earlier. My proposal is to merge mISDN and then see what falls out. My guess it won't be that bad as everybody thinks and then we go from there. Next step is to remove ISDN4Linux since that should not be used at all anymore. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel oops with bluetooth usb dongle
Hi Thomas, Can you please enable CONFIG_SLUB_DEBUG=y and CONFIG_SLUB_DEBUG_ON=y and give it another try? If we can not catch it that way, I'll whip up a patch which points us to the code which added the offending timer. Hi, Note: I switched to 2.6.25-rc2. The only new thing I see is this message: hci_cmd_task: hci0 command tx timeout This comes from net/bluetooth/hci_core.c, line 1547 There is indeed a timeout message in the log (at the end of this email). I tried to boot with slub_debug but did not get anything more. slabinfo -v does not report anything either. Crash log: hci_cmd_task: hci0 command tx timeout BUG: unable to handle kernel paging request at 6b6b6b6b We got some more info --- #define POISON_FREE 0x6b/* for use-after-free poisoning */ So the timer is in an allocated data structure, which is freed without having removed the timer first. Sorry for the meager yield. Hey, we know already more :) Marcel, any idea on this one ? I don't really have any idea. Nothing has been changed in this area for a couple of years. The command TX timeout is the timeout that indicates a missing answer to a command sent down to the Bluetooth chip. However this involves some atomic and tasklet stuff. Did we have some changes that I missed and might now render this usage as broken. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][BLUETOOTH] add HCI_BROKEN_ISOC for 0e5e:6622 (bugzilla #9027)
Hi, This patch fix bugzilla #9027. ``Syslog flooded with "hci_scodata_packet: hci0 SCO packet for unknown connection handle 92" message" see http://bugzilla.kernel.org/show_bug.cgi?id=9027 when we get the content of /proc/bus/usb/devices for this one. Do you have the manufacturer name of it or at least an idea which kind of device this is. Check "hciconfig hci0 version". It have no text on the chips and package, so I don't know the manufacturer name. and what about "hciconfig hci0 version"? hci0: Type: USB BD Address: 11:11:11:11:11:11 ACL MTU: 672:3 SCO MTU: 48:1 HCI Ver: 2.0 (0x3) HCI Rev: 0x1f4 LMP Ver: 2.0 (0x3) LMP Subver: 0x1f4 Manufacturer: CONWISE Technology Corporation Ltd (66) this is really a broken device. Please update your comment in your patch and re-sent it. The comment should read /* CONWISE Technology based adapters with buggy SCO support */ And also put the entry right after the RTX Telecom one. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] firmware: move firmware_class from Documentation/ to samples/
Hi Randy, Move the firmware_class sample drivers to samples/ so that they are buildable and can be maintained. Add Kconfig entry for firmware_class. Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> this is a good idea. Acked-by: Marcel Holtmann <[EMAIL PROTECTED]> Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] firmware: fix a few build errors
Hi Randy, Fix one typo (comma to semi-colon). Fix sysfs externs (just use sysfs.h for prototypes). Documentation/firmware_class/firmware_sample_firmware_class.c:37: error: conflicting types for 'sysfs_remove_bin_file' include/linux/sysfs.h:100: error: previous declaration of 'sysfs_remove_bin_file' was here Still has a build error: ERROR: "firmware_class" [samples/firmware_class/ firmware_sample_firmware_class.ko] undefined! while you are at it, can you also fix the broken coding style in it? Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Plans for mISDN? Was: [PATCH 00/14] [ISDN] ...
Hi Simon, mISDN has two problems, which are of course interrelated: mISDN has one problem that is even bigger than these: the kernel oopses if modules aren't loaded in the right order. misdn-init works around that, but if it doesn't work for some reason (and I can think of multiple here), the user is left with a kernel that oopses during hardware discovery and never gets to a stage where this can be rectified, as almost all distributions now have hardware discovery before the first opportunity to get a shell. At least these were my experiences the last time I tried it on my test box. that is not a big problem at all. If you have to enforce a specific module load order then create some dummy exports like misdn_load() and use them from the module that depends on it. It is not beautiful, but sometimes you have to do it this way. So if that is stopping mainline inclusion it is a lame excuse. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 > > work. > > Yes I can, if the proprietary code is not linked with GPL code (and the > proprietary code is original). Loadable modules are not linked. This is a > very clear-cut case. that is not clear-cut case. You link at run-time. Otherwise the module would do nothing. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
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 any licence, proprietary or > otherwise, presumably with the restriction that it may NOT be built-in. 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. The gray area that exists if you have code that was written for some other operating system and licensed under some proprietary license in the first place. And now that code is used in conjunction with a glue layer to make it loadable as kernel module. > > You driver was meant to be > > running as Linux kernel module and thus it is derivative work. > > It is precisely the fact that it is a loadable module, and does not form > part of the kernel, that removes the requirement to distribute it under GPL. That is such a nonsense. Stop distributing FUD and start talking to a lawyer. You are clearly under some weird impression what the GPL means and what it implies. > > What are you arguing here. It makes no difference if it is technical or > > not. The EXPORT_SYMBOL_GPL gives you a clear hint that when using this > > symbol, you have to obey to the GPL. > > And that "hint" is a lie. 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 violation of the GPL license. We can't make it much clearer. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 violation of the GPL license. We can't make it much clearer. > > Not necessarily so. The developers feel that any code using that symbol > is necessarily a derivative work, but at the end of the day it would be > up to the legal system to decide whether it really is or not. > > If the courts decided that the symbol could be used and the driver > wouldn't be a derivative work, it would be perfectly legal to use a > GPL'd shim to "re-export" the symbol, essentially stripping off the > GPL-only protection for that symbol. I agree with you that a court can decide that the usage of a EXPORT_SYMBOL_GPL symbol is not derivative work, but I see the likelihood of this happening as almost non existent. And even if so then you still have to deal with the fact that the license of this symbol is clearly GPL. No questions asked about that, because it says so and due technical means you can't load a non-GPL kernel module that uses EXPORT_SYMBOL_GPL symbol without tainting the kernel. The same fact is valid in userspace where you can't link (not even runtime) a GPL library into a non-GPL program. However if anyone wants to fight the license, be my guest and do so :) > In our group all kernel modules that we write are GPL'd, as it lets us > sleep at night, simplifies our lives, and makes the lawyers much > happier. Other people may be willing to take more risks. All big companies are going this way. And licenses beside, there are valid technical points in making your driver open source and get it merged upstream. Just a hint for all these binary-only people :) Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][v4] ipwireless: driver for 3G PC Card
Hi Jiri, > > From: David Sterba <[EMAIL PROTECTED]> > > ipwireless: driver for PC Card, 3G internet connection > > Linus, as there is no PCMCIA maintainer and akpm apparently wants you to > merge this directly [1] -- what is your position on this one please? As > far as I can see all the major issues that were raised during review were > fixed by David, so there shouldn't be any obstacles to merging it. It > would be nice if this driver will make it for 2.6.25 merge window. I had some minor additional questions, but in general, I second that this driver should be merged for 2.6.25. The question of the PCMCIA maintainership came up on a different mailing list. Personally I think that PCMCIA is a dead technology, but in some industrial environments this will live longer than expected. I would simply propose that LKML is used for PCMCIA related review and -mm for testing. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 solution. So please get your examples up-to-date. > > So how does that invalidate my point? Intel did jump through a lot of > hoops to avoid giving away the code that controls their radio. When > the regulatory daemon stuff got too much complaints, they finally > redid their firmware to avoid the daemon. But they still have not > exposed the details on how to control their radio. find an Intel engineer that worked on it. There is a bigger story behind it and I am not telling it. And btw. it is perfectly fine that Intel is not giving full access to their radios. Why should they? > > You might wanna now point to hiding something in firmware, but the > > hardware, firmware, driver separation (with being hardware and > > firmware closed source) is an accepted solution. It is a clean > > separation. Interface wise and license wise. > > Yes, that is a nice solution. Provided that you have any firmware at > all. But price is everything, chips become dumber and dumber and more > control functions are pushed to the host. If you want to sell a device > in Korea, price is everything; if you can shave off 30 cents by putting > the firmware in ROM, or by using 1.5 mbits of flash instead of 2 mbits, > that means an increase in market share or profit margins. I heard this all before and I don't buy it anymore. At some point the companies in Asia will understand that the whole picture looks different and that not always cheap, cheap, cheap is best for their margins. And btw. the fully supported Linux hardware is in a lot of cases not more expensive than the other ones. > > Remember that nobody inside the community ever asked for any kind of > > IP or trade secrets. We only want specifications so we can write the > > drivers under an appropriate open source license. If the > > specification describes an API exposed via firmware then that is > > perfectly fine. > > I definitely agree. I think it's stupid of companies to hide away > their documentation out of fear of, well, something. I find it > extremely frustrating when I bought a device touted as "the first open > Linux mobile", just to find out that it used a binary-only kernel module > for the M-Systems DiskOnChip. A quite nice phone, but due to that one > module, it was completely impossible to use anything but the ancient > 2.4 kernel it came with. You got one of the Greenphones ;) > I also think that my customers, that decided to keep their kernel > modules binary only, made a big mistake and have told them so. But I > still think it's better for the Linux community to be a bit soft on > such companies for a while. It's better to let them get away with it > for a while, and slowly try to convince them about the error of their > ways, rather than see them go with Windows CE or a BSD. 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. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 to failure. I actually care about Linux certainly more than you do. I care about the copyright of my kernel contributions and the contributions of others. Not caring about these things is what is the worst. It means you disrespect all the work that a lot of people and companies have put into Linux. And don't quote we with "I don't care". Alan already complained about your quoting style. Don't put words in my mouth that I never said. The Linux kernel is licensed under GPL. If you don't like, go and play with someone else. You can quote me on that one. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 > >>> work. > >>> > >> Yes I can, if the proprietary code is not linked with GPL code (and the > >> proprietary code is original). Loadable modules are not linked. This is > >> a > >> very clear-cut case. > >> > > > > that is not clear-cut case. You link at run-time. Otherwise the module > > would do nothing. > > That's why it's allowed. The module isn't linked when it's distributed, > and the author doesn't do or cause the linking; the user does. And the > user never distributes in the linked state. Distribution is key to GPL. so how do you build this module that is not linked without using the Linux kernel. Hence derivative work. Hence dynamic linking at runtime of binary only code is violating the GPL. Same goes for dynamic linking at runtime against GPL libraries. Nobody thinks that is possible and ships binary applications that link against GPL libaries. So why do you think you can distribute a binary only kernel module. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 could be happier, since then you > have to buy another... > > [...] > > preliminary go ahead from the bosses to provide documentation under an > > NDA to Linux developers that would like to write GPL drivers for it. I > [...] > Urgh... I don't think NDAs and Open Source mix well... Are you sure your > bosses KNOW Linux and the OS in general? :-) talk to Greg KH about this. Have NDAs and open source work together is really simple. Have the NDA say that you can use all provided documentation to write an open source driver and publish it under GPL. A lot of companies are okay with this these days. The Linux Foundation should have NDA template texts for this. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 > > work. > > > > > Yes I can, if the proprietary code is not linked with GPL code (and the > proprietary code is original). Loadable modules are not linked. This > is a > very clear-cut case. > > > >>> that is not clear-cut case. You link at run-time. Otherwise the module > >>> would do nothing. > >>> > >> That's why it's allowed. The module isn't linked when it's distributed, > >> and the author doesn't do or cause the linking; the user does. And the > >> user never distributes in the linked state. Distribution is key to GPL. > >> > > > > so how do you build this module that is not linked without using the > > Linux kernel. > You could hand code in assembler, using Microsoft's assembler under > Windows. You could compile from C, using GCC on FreeBSD. But that's > immaterial. A module which is an original, non-derivative work, is, > well, original and non-derivative. Do you say that it must be > otherwise? Why would that be? since when does the language make any difference. 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. Let me repeat this. Ask a legal counsel before you go ahead with your assumption. You might get away with it or you might not. What Greg, Alan and I try to tell you is that using EXPORT_SYMBOL or EXPORT_SYMBOL_GPL will create derivative work, but if you don't wanna believe us, that is your prerogative. So go ahead, but don't complain if you actually get sued for copyright infringement at some point and tell the court you didn't know. 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 that it is original work. Good luck :) Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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. > > > Yes, I am of that view. I accept that I could be wrong, but that also > means that I could be right. We agree, so far. The important point is > that I could be right. What will be done when somebody brings forth such > an work? Will the restriction in EXPORT_SYMBOL_GPL be removed, or will > the driver be unfairly restricted from using those other modules? You > did agree I could be right, so positing such a driver, what happens? (I > predict nothing; the driver is unfairly restricted.) whatever you feel you get away with, but hey I am not a lawyer and my reading is that any kernel module is derivative work and thus has to be placed under GPL. Feel free to disagree with me. If you think you can convince me, than you are under the wrong impression. Since even if (and this is a big if) I am wrong, my action won't lead to a copyright violation. Yours however would if you are wrong. So pick your battle. > USB drivers must NOT be restricted to GPL-licence only; that would > damage Linux. Not writing and publishing GPL drivers damages Linux. Nothing else. > > 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 > > that it is original work. > > Where does this come from? It's right out of left field. Since I've > never suggested such a thing, could you please do me the courtesy of > retracting the suggestion that I have? 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. It makes no difference if you distribute the GPL library with it or not. But hey (again), feel free to disagree with me here. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 *have* to be pedantic about the wording used)... true, true and true. However I was under the impression we passed that discussion point, that you can do whatever inside your own walls :) Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] USB: mark USB drivers as being GPL only
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 of a GPL'd work. There is no other way it could become > subject to the GPL. > > So this argument reduces to -- any work that uses a library is a derivative > work of that library. But this is clearly wrong. For work X to be a > derivative work of work Y, it must contain substantial protected expression > from work Y, but an application need not have any expression from the > libraries it uses. > > > 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 ordinary intended way. > > If the application contains insufficient copyrightable expression from the > library to be considered a derivative work (and purely functional things do > not count), then it cannot be a derivative work. The library is not being > copied or distributed. So how can its copyright be infringed? go ahead and create an application that uses a GPL only library. Then ask a lawyer if it is okay to distribute your application in binary only form without making the source code available (according to the GPL). http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#IfLibraryIsGPL http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#LinkingWithGPL Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 ordinary intended way. > > > > > > If the application contains insufficient copyrightable expression from > > > the library to be considered a derivative work (and purely functional > > > things do not count), then it cannot be a derivative work. The library is > > > not being copied or distributed. So how can its copyright be infringed? > > > > go ahead and create an application that uses a GPL only library. Then > > ask a lawyer if it is okay to distribute your application in binary only > > form without making the source code available (according to the GPL). > > > > http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#IfLibraryIsGPL > > > > http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#LinkingWithGPL > > In the US, at least, the belief that "Linking", in *ANY* form, with a GPL > library creates a derivative work, is fallacious. that is how FSF states it and it seems that most legal departments of big companies (US and EU based) are not taking any risk on this. So it seems that someone actually has to prove in court that these assumptions for the GPL case are wrong. > Were I to create an > application that uses, say, GTK for the interface the protected expression is > my "unique and creative" use of the GTK API for creating the specific > interface and any other code I have written using the API. I hold sole > license to the copyright on that code and am able to license said code under > the specific license of my choice. Not even getting into this one since GTK+ is a LGPL based library. Get your examples straight. > Why? Because the pre-processor is what is including any GPL'd code in my > application and expanding any macros. That is a purely mechanical process and > hence the output is not able to be separately copyrighted - if it could be, > then the copyright would be held by the *COMPILER*, and I am *NOT* bound by > the license on that code. The same applies if GPL'd code is included in my > application during the linking process. QED: The "Linking" argument used by > most people is wholly fallacious in at least one major country - and if I'm > not mistaken, the output from an automated process is similarly not > considered as carrying a separate copyright in all nations that are > signatories of or follow the Bern Convention. The GPL is a license. Nobody is talking about the copyright of your code here. You always have the copyright on your code. The point is that you have to license your code under GPL (when using a GPL library) and you are distributing your code. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Bluetooth: Add MacBookPro10,1 support
Hi Henrik, > > > > I believe the requirement is to always include a usb-devices output in > > > > the commit message (to let maintainers confirm that no typo has occurred > > > > in the patch itself). > > > > If you don't have access to the device I can take it without usb-devices, > > otherwise just add it to the patch and then resend. > > I don't, but I trust that this patch is authentic. the requirement is to have either /sys/kernel/debug/usb/devices section or usb-devices output included in the commit message. No exceptions. I want to have this documented in case any questions about it ever arises. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] Bluetooth: Add MacBookPro10,1 support
Hi Henrik, > Add support for the 2012 15'' MacBook Pro Retina, also known as > MacBookPro10,1. The bluetooth device presents itself as > > Bus 002 Device 008: ID 05ac:8286 Apple, Inc. > Device Descriptor: > bLength18 > bDescriptorType 1 > bcdUSB 2.00 > bDeviceClass 255 Vendor Specific Class > bDeviceSubClass 1 > bDeviceProtocol 1 > bMaxPacketSize064 > idVendor 0x05ac Apple, Inc. > idProduct 0x8286 > bcdDevice0.74 > iManufacturer 1 Apple Inc. > iProduct2 Bluetooth USB Host Controller > iSerial 0 > bNumConfigurations 1 please use /sys/kernel/debug/usb/devices or usb-devices script so that we get a compact representation of all endpoints and their descriptors. I know that lsusb will contain the same information, but it just spams the commit message for no real reason. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 id changes for those devices, so this macro would be
> perfect for us:
>
> { USB_VENDOR_AND_INTERFACE_INFO(0x0a5c, 0xff, 0x01, 0x01) }
>
> Signed-off-by: Gustavo Padovan
> ---
> include/linux/usb.h | 21 +
> 1 file changed, 21 insertions(+)
>
> diff --git a/include/linux/usb.h b/include/linux/usb.h
> index dea39dc..dad156b 100644
> --- a/include/linux/usb.h
> +++ b/include/linux/usb.h
> @@ -829,6 +829,27 @@ static inline int usb_make_path(struct usb_device *dev,
> char *buf, size_t size)
> .bInterfaceSubClass = (sc), \
> .bInterfaceProtocol = (pr)
>
> +/**
> + * USB_VENDOR_AND_INTERFACE_INFO - describe a specific usb vendor with a
> class of usb interfaces
> + * @vend: the 16 bit USB Vendor ID
> + * @cl: bInterfaceClass value
> + * @sc: bInterfaceSubClass value
> + * @pr: bInterfaceProtocol value
> + *
> + * This macro is used to create a struct usb_device_id that matches a
> + * specific vendor with a specific class of interfaces.
> + *
> + * This is especially useful when explicitly matching devices that have
> + * vendor specific bDeviceClass values, but standards-compliant interfaces.
> + */
> +#define USB_VENDOR_AND_INTERFACE_INFO(vend, cl, sc, pr) \
> + .match_flags = USB_DEVICE_ID_MATCH_INT_INFO \
> + | USB_DEVICE_ID_MATCH_DEVICE, \
this should be USB_DEVICE_ID_MATCH_VENDOR.
> + .idVendor = (vend), \
> + .bInterfaceClass = (cl), \
> + .bInterfaceSubClass = (sc), \
> + .bInterfaceProtocol = (pr)
> +
> /* --- */
>
> /* Stuff for dynamic usb ids */
Regards
Marcel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] bluetooth: btmrvl_sdio: look for sd8688 firmware in proper location
Hi Lubomir, > The firmware images are shared with libertas_sdio WiFi chip and used to be in > libertas/ subtree in linux-firmware. As btmrvl_sdio used to look into the > linux-firmware root, it ended up being unsuccessful. Since the firmware files > are not specific to the libertas hardware, they're being moved into mrvl/ now. > > Signed-off-by: Lubomir Rintel > --- > drivers/bluetooth/btmrvl_sdio.c |8 > 1 files changed, 4 insertions(+), 4 deletions(-) Acked-by: Marcel Holtmann Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] bluetooth: btmrvl_sdio: look for sd8688 firmware in proper location
Hi Lubumir,
proper commit message with explanation here please.
> Signed-off-by: Lubomir Rintel
> ---
> drivers/bluetooth/btmrvl_sdio.c |8
> drivers/bluetooth/btmrvl_sdio.h |6 --
> 2 files changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/bluetooth/btmrvl_sdio.c b/drivers/bluetooth/btmrvl_sdio.c
> index 3f4bfc8..bc27d01 100644
> --- a/drivers/bluetooth/btmrvl_sdio.c
> +++ b/drivers/bluetooth/btmrvl_sdio.c
> @@ -83,8 +83,8 @@ static const struct btmrvl_sdio_card_reg btmrvl_reg_87xx = {
> };
>
> static const struct btmrvl_sdio_device btmrvl_sdio_sd8688 = {
> - .helper = "sd8688_helper.bin",
> - .firmware = "sd8688.bin",
> + .helper = "mrvl/sd8688_helper.bin",
> + .firmware = "mrvl/sd8688.bin",
> .reg= &btmrvl_reg_8688,
> .sd_blksz_fw_dl = 64,
> };
> @@ -1179,7 +1179,7 @@ MODULE_AUTHOR("Marvell International Ltd.");
> MODULE_DESCRIPTION("Marvell BT-over-SDIO driver ver " VERSION);
> MODULE_VERSION(VERSION);
> MODULE_LICENSE("GPL v2");
> -MODULE_FIRMWARE("sd8688_helper.bin");
> -MODULE_FIRMWARE("sd8688.bin");
> +MODULE_FIRMWARE("mrvl/sd8688_helper.bin");
> +MODULE_FIRMWARE("mrvl/sd8688.bin");
> MODULE_FIRMWARE("mrvl/sd8787_uapsta.bin");
> MODULE_FIRMWARE("mrvl/sd8797_uapsta.bin");
> diff --git a/drivers/bluetooth/btmrvl_sdio.h b/drivers/bluetooth/btmrvl_sdio.h
> index 43d35a6..4a5a019 100644
> --- a/drivers/bluetooth/btmrvl_sdio.h
> +++ b/drivers/bluetooth/btmrvl_sdio.h
> @@ -84,7 +84,9 @@ struct btmrvl_sdio_card {
> struct sdio_func *func;
> u32 ioport;
> const char *helper;
> + const char *helper2;
> const char *firmware;
> + const char *firmware2;
And please clear out the patch from left-overs.
> const struct btmrvl_sdio_card_reg *reg;
> u16 sd_blksz_fw_dl;
> u8 rx_unit;
> @@ -92,8 +94,8 @@ struct btmrvl_sdio_card {
> };
>
> struct btmrvl_sdio_device {
> - const char *helper;
> - const char *firmware;
> + const char *helper, *helper2;
> + const char *firmware, *firmware2;
And here as well.
Regards
Marcel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add SDIO 'type' parameter to sysfs
Hi Andy, Add 'type' attribute of the SDIO device to represent Standard Function interface code in the human readable form. these kind of things should not be part of the Linux kernel. A userspace tool (call it lssdio if you want) should handle it. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Bluez-devel] forcing SCO connection patch
Hi Louis,
I fixed all of errors except 80 characters warning.
Thanks
Louis JANG
Signed-off-by: Louis JANG <[EMAIL PROTECTED]>
--- linux-2.6.23/net/bluetooth/hci_event.c.orig 2008-02-25
17:17:11.0 +0900
+++ linux-2.6.23/net/bluetooth/hci_event.c 2008-02-25
17:30:23.0 +0900
@@ -1313,8 +1313,17 @@
hci_dev_lock(hdev);
conn = hci_conn_hash_lookup_ba(hdev, ev->link_type, &ev->bdaddr);
- if (!conn)
- goto unlock;
+ if (!conn) {
+ if (ev->link_type != ACL_LINK) {
+ __u8 link_type = (ev->link_type == ESCO_LINK) ? SCO_LINK :
ESCO_LINK;
+
+ conn = hci_conn_hash_lookup_ba(hdev, link_type,
&ev->bdaddr);
+ if (conn)
+ conn->type = ev->link_type;
+ }
+ if (!conn)
+ goto unlock;
+ }
NAK. There is no need to check for ACL_LINK. The sync_complete will
only be called for SCO or eSCO connections.
diff -uNr linux-2.6.23/include/net/bluetooth-orig/sco.h linux-2.6.23/
include/net/bluetooth/sco.h
--- linux-2.6.23/include/net/bluetooth-orig/sco.h 2007-10-10
05:31:38.0 +0900
+++ linux-2.6.23/include/net/bluetooth/sco.h 2008-02-25
18:04:20.0 +0900
@@ -51,6 +51,8 @@
__u8 dev_class[3];
};
+#define SCO_FORCESCO 0x03
+
NAK. We don't need this. And even if we really would want this, we
would do it via extra parameters inside sockaddr_sco. In that case we
would do it right and exposing eSCO settings and not some boolean
parameter.
Regards
Marcel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel oops with bluetooth usb dongle
Hi Quel, -- Original message -- From: Thomas Gleixner <[EMAIL PROTECTED]> On Fri, 22 Feb 2008, David Woodhouse wrote: On Fri, 2008-02-22 at 08:23 +0100, Thomas Gleixner wrote: + del_timer(&conn->info_timer); + hcon->l2cap_data = NULL; kfree(conn); Shouldn't that be del_timer_sync() ? Hmm, probably yes. Hi, Great news: only adding adding del_timer_sync() to 2.6.25-rc3 does prevent the crash. Bad news: I still cannot use the device. hcitool inq, hcitool scan, hcitool name and hcitool info commands work. hcitool cc , sdptool , rfcomm connect command fail, most of them with a 'Connection reset by peer' error. what does "hciconfig hci0 version" tell you about your device? Some of the none major based Bluetooth chips are broken and might need an extra tweak within the USB driver. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] bluetooth: delete timer in l2cap_conn_del()
Hi Quel, Delete a possibly armed timer before kfree'ing the connection object. Solves: http://lkml.org/lkml/2008/2/15/514 Reported-by:Quel Qun <[EMAIL PROTECTED]> Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]> --- net/bluetooth/l2cap.c |2 ++ 1 file changed, 2 insertions(+) Index: linux-2.6/net/bluetooth/l2cap.c === --- linux-2.6.orig/net/bluetooth/l2cap.c +++ linux-2.6/net/bluetooth/l2cap.c @@ -417,6 +417,8 @@ static void l2cap_conn_del(struct hci_co l2cap_sock_kill(sk); } + del_timer_sync(&conn->info_timer); + hcon->l2cap_data = NULL; kfree(conn); } can you confirm that this actually fixes the issue. Thomas, if confirmed, this is Acked-by me. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Bluez-devel] forcing SCO connection patch
Hi Loius,
--- linux-2.6.23/net/bluetooth/hci_event.c.orig 2008-02-25
17:17:11.0 +0900
+++ linux-2.6.23/net/bluetooth/hci_event.c 2008-02-25
17:30:23.0 +0900
@@ -1313,8 +1313,17 @@
hci_dev_lock(hdev);
conn = hci_conn_hash_lookup_ba(hdev, ev->link_type, &ev->bdaddr);
- if (!conn)
- goto unlock;
+ if (!conn) {
+ if (ev->link_type != ACL_LINK) {
+ __u8 link_type = (ev->link_type == ESCO_LINK) ? SCO_LINK :
ESCO_LINK;
+
+ conn = hci_conn_hash_lookup_ba(hdev, link_type, &ev->bdaddr);
+ if (conn)
+ conn->type = ev->link_type;
+ }
+ if (!conn)
+ goto unlock;
+ }
NAK. There is no need to check for ACL_LINK. The sync_complete will
only be called for SCO or eSCO connections.
I see. I removed this check line in the patch.
Thanks.
Louis JANG
Signed-off-by: Louis JANG <[EMAIL PROTECTED]>
--- linux-2.6.23/net/bluetooth/hci_event.c.orig 2008-02-26
12:46:36.0 +0900
+++ linux-2.6.23/net/bluetooth/hci_event.c 2008-02-26
12:47:23.0 +0900
@@ -1313,8 +1313,15 @@
hci_dev_lock(hdev);
conn = hci_conn_hash_lookup_ba(hdev, ev->link_type, &ev->bdaddr);
- if (!conn)
- goto unlock;
+ if (!conn) {
+ __u8 link_type = (ev->link_type == ESCO_LINK) ? SCO_LINK :
ESCO_LINK;
+
+ conn = hci_conn_hash_lookup_ba(hdev, link_type, &ev->bdaddr);
+ if (conn)
+ conn->type = ev->link_type;
+ else
+ goto unlock;
+ }
if (!ev->status) {
conn->handle = __le16_to_cpu(ev->handle);
do something like this:
if (!conn) {
conn =
if (!conn)
goto unlock;
conn->type = ev->link_type;
}
And include a description when submitting a patch.
Regards
Marcel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Bluetooth: btmrvl_sdio: look for sd8688 firmware in alternate place
Hi Lubomir, > linux-firmware ships the sd8688* firmware images that are shared with > libertas_sdio WiFi driver under libertas/. libertas_sdio looks in both places > and so should we. > > Signed-off-by: Lubomir Rintel > --- > drivers/bluetooth/btmrvl_sdio.c | 24 ++-- > drivers/bluetooth/btmrvl_sdio.h |6 -- > 2 files changed, 26 insertions(+), 4 deletions(-) NAK from me on this one. I do not want the driver to check two locations. That is what userspace can work around. If we want to unify the location between the WiFi driver and the Bluetooth driver, I am fine with that, but seriously, just pick one over the other. I do not care which one. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Bluetooth: btmrvl_sdio: look for sd8688 firmware in alternate place
Hi Lubomir, > > > > linux-firmware ships the sd8688* firmware images that are shared with > > > > libertas_sdio WiFi driver under libertas/. libertas_sdio looks in both > > > > places > > > > and so should we. > > > > > > > > Signed-off-by: Lubomir Rintel > > > > --- > > > > drivers/bluetooth/btmrvl_sdio.c | 24 ++-- > > > > drivers/bluetooth/btmrvl_sdio.h |6 -- > > > > 2 files changed, 26 insertions(+), 4 deletions(-) > > > > > > NAK from me on this one. I do not want the driver to check two > > > locations. That is what userspace can work around. > > > > > > If we want to unify the location between the WiFi driver and the > > > Bluetooth driver, I am fine with that, but seriously, just pick one over > > > the other. I do not care which one. > > > > The unified location is mrvl/ directory. > > > > We can probably move SD8688 firmware & helper binaries to mrvl/ and have > > both drivers grab the images there? > > That would break existing setups, wouldn't it? > > I was under impression (commit 3d32a58b) that we care about > compatibility here. Do we? that is what symlinks are for. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/04] Load keyspan firmware with hotplug
Hi Jan, > > > > Mmm, probably that 2001 discussion about the keyspan firmware, right ? > > > > > > > > http://lists.debian.org/debian-legal/2001/04/msg00145.html > > > > > > > > Can you summarize the conclusion of the thread, or what you did get > > > > from it, > > > > please ? > > > > > > That people didn't like the inclusion of firmware, I posted how you can > > > fix it by moving it outside of the kernel, and asked for patches. > > > > > > None have come. > > > > Didn't know you were waiting for it. How about something like the > > following series of patches? > > > > [01/04] - add simple Intel IHEX format parser to the firmware loader. > > Firmware loader is format-agnostic, I think having IHEX parser in a separate > file would be better... I agree with Dmitry on this point. The IHEX parser should not be inside firmware_class.c. What about using keyspan_ihex.[ch] for it? Regards Marcel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/04] Load keyspan firmware with hotplug
Hi Jan, > > I agree with Dmitry on this point. The IHEX parser should not be inside > > firmware_class.c. What about using keyspan_ihex.[ch] for it? > > That's what I had originally, actually called firmware_ihex.ko, since > the IHEX format parser is not in any way keyspan specific and there are > several usb-serial converters that seem to use the same IHEX->.h trick > which could trivially be modified to use this loader. > > But the compiled parser fairly small (< 2KB) and adding it to the > existing module didn't effectively add any size to the firmware_class > module since things are rounded to a page boundary anyways. so it seems that this is usb-serial specific at the moment. Then I would propose to add it to the core of the usb-serial driver. Unless no other driver in the kernel needs a IHEX parser, I think it is bad idea to mess it up at the moment. People are also working on a replacement for the current request_firmware(), because the needs are changing. Try to keep it close with the usb-serial for now. Regards Marcel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: debug: sleeping function...slab.c:2090
Hi Richard, > > I got the debug statement below during boot. > > > > Environment: > >Pentium M, Thinkpad R40 > >Debian unstable > >Linux 2.6.12-rc2 > >Gnu C 3.3.5 > >binutils 2.15 > > > > Debug: sleeping function called from invalid context at mm/slab.c:2090 > > in_atomic():1, irqs_disabled():0 > > [] dump_stack+0x17/0x20 > > [] __might_sleep+0xac/0xc0 > > [] kmem_cache_alloc+0x5e/0x60 > > [] kmem_cache_create+0xe3/0x570 > > [] proto_register+0x99/0xc0 > > [] inet6_init+0x16/0x1d0 [ipv6] > > [] sys_init_module+0x172/0x230 > > [] syscall_call+0x7/0xb > > > > What module was being loaded at the time? this is the ipv6 module and the unix module has the same problem. I posted this problem already to the netdev mailing list and it seems that Arnaldo is looking at it. Regards Marcel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/04] Load keyspan firmware with hotplug
Hi Dmitry, > > People are also working on a replacement for the > > current request_firmware(), because the needs are changing. Try to keep > > it close with the usb-serial for now. > > > > Could you elaborate on what do you think is needed? I have some of > patches to firmware loader and wondering if we should coordinate out > efforts. I have > > 1. convert from using a timer to wait_for_comletion_timeout which > simplifies logic > 2. tightening of state transition rules and removing possible memory > leak (very unlikely) > 3. converting firmware_priv to fw_class_dev to simplify memory management. > 4. removing request_firmware_nowait as noone seems to be using it - > and I doubt one would ever want to request firmware from an interrupt. > 5. Creating firmware class in a separate thread to work around selinux > (with prism54 firmware is loaded when interface is configured and thus > firware loader runs in context of /sbin/ip which may not have access > to sysfs. Having separate thread will ensure that firmware loader runs > in kernel context). > > And I was thinking about caching firmware (siomething like if you do > "echo 2 > /sys/class/firmware/blah/loading" instead of 0 it will keep > a copy of the firmware in memory. One could see all firmwares in > /sys/class/firmware/loaded/ and by erase cached firmware by > echoing 0 into it). > > What do you think? actually there is a thread about firmware loading rewrite and POST calling of programs. It must be on LKML or the hotplug mailing list. However my backlog for the interesting topics of these lists increased while I was traveling the last 5-6 weeks. I think you should simply start a new one on LKML. Regards Marcel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/04] Load keyspan firmware with hotplug
Hi Jan, > > > > I agree with Dmitry on this point. The IHEX parser should not be inside > > > > firmware_class.c. What about using keyspan_ihex.[ch] for it? > > > > > > That's what I had originally, actually called firmware_ihex.ko, since > > > the IHEX format parser is not in any way keyspan specific and there are > > > several usb-serial converters that seem to use the same IHEX->.h trick > > > which could trivially be modified to use this loader. > > > > > > But the compiled parser fairly small (< 2KB) and adding it to the > > > existing module didn't effectively add any size to the firmware_class > > > module since things are rounded to a page boundary anyways. > > > > so it seems that this is usb-serial specific at the moment. Then I would > > I really don't see the point you are trying to argue. I said, sure it is > possible to make it a separate module, that is what my initial > implementation was. Why do you want to pigeon-hole it with anything but > the existing firmware loading code? the existing request_firmware() has nothing in common with IHEX parser and such a parser should not belong there. So either make it a separate module or add it to the module that is using it. In this case this is the keyspan module or the usb-serial core. > It is _not_ usb-serial specific, in fact once the device is initialized > this isn't even needed. And the initialization as far as I can see uses > little or no usb-serial code. > > It happens that many usb-serial devices are built around the ezusb > chipset, which in turn seems to be a 8051-based microcontroller. The > compilers for such microcontrollers seem to generate IHEX formatted > output possibly because eprom burners generally support the format. Then make it at separate module. > > it up at the moment. People are also working on a replacement for the > > current request_firmware(), because the needs are changing. Try to keep > > it close with the usb-serial for now. > > What? I find the existing request_firmware fairly simple and > straightforward, it has a very KISS-like quality to it, it is nice and > small and even the userspace support is trivial. I only saw a mention > about 'replacing' it in the current thread which mostly involved > complaints but didn't actually see anyone volunteering to start working > on such a replacement. > > If a driver wants to load 5 different chunks, just call request_firmware > 5 times (i.e. drivers/bluetooth/bcm203x.c). If the data is a single > binary blob, just ask for the single binary blob. In this case there > seems to be some structure to the blob that I wanted to preserve, and > that would either be some custom binary format that contains > []... tuples, which ofcourse causes problems for > our big-endian brothers, or a similar ascii format, where the IHEX is > not only pretty much standardized, it is trivial to parse and even adds > checksum information. I am not going to repeat the current arguments and it is not about loading multiple firmware files (btw I wrote the bcm203x). Check the mailing list archives for the details. I still need to catch up with the discussion, but there is some ongoing work. > The only thing that I see missing right now is a change to the makefiles > to have in-tree firmware files get installed in /lib/modules/`uname > -r`/firmware or some similar place. Ideally people would add a line > like, > > fw-$(CONFIG_FOO) = foo-firmware-blob.fw > > And make install could drop it a place where hotplug can find it. This is another approach and if you want something like that, then send a patch for it and let Sam and others comment on it. Regards Marcel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.4] "Fix" introduced in 2.4.27pre2 for bluetooth hci_usb race causes kernel hang
Hi Tomas,
> I have noticed a problem with a race condition fix introduced in
> 2.4.27-pre2 that causes the kernel to hang when disconnecting a
> Bluetooth USB dongle or doing 'hciconfig hci0 down'. No message is
> printed, the kernel just doesn't respond anymore.
>
> Seen in Changelog:
> Marcel Holtmann:
> o [Bluetooth] Fix race in RX complete routine of the USB drivers
>
> Reversing the following patch to hci_usb_rx_complete() makes 2.4.27-pre2
> up until 2.4.30 happy and does not hang when removing the dongle
> anymore. (bfusb.c has the same patch applied)
>
> 2.6.11.7 does not show the same problem, but has similar code to the
> "fixed" (that hangs) code in 2.4, so the real problem is probably
> somewhere else.
does the attached patch makes any difference?
Regards
Marcel
= drivers/bluetooth/hci_usb.c 1.23 vs edited =
--- 1.23/drivers/bluetooth/hci_usb.c2004-07-31 13:02:43 +02:00
+++ edited/drivers/bluetooth/hci_usb.c 2005-04-09 15:37:12 +02:00
@@ -398,12 +398,12 @@
BT_DBG("%s", hdev->name);
+ /* Synchronize with completion handlers */
write_lock_irqsave(&husb->completion_lock, flags);
-
+ write_unlock_irqrestore(&husb->completion_lock, flags);
+
hci_usb_unlink_urbs(husb);
hci_usb_flush(hdev);
-
- write_unlock_irqrestore(&husb->completion_lock, flags);
MOD_DEC_USE_COUNT;
return 0;
Re: [2.4] "Fix" introduced in 2.4.27pre2 for bluetooth hci_usb race causes kernel hang
Hi Tomas,
> > > I have noticed a problem with a race condition fix introduced in
> > > 2.4.27-pre2 that causes the kernel to hang when disconnecting a
> > > Bluetooth USB dongle or doing 'hciconfig hci0 down'. No message is
> > > printed, the kernel just doesn't respond anymore.
> > >
> > > Seen in Changelog:
> > > Marcel Holtmann:
> > > o [Bluetooth] Fix race in RX complete routine of the USB drivers
> > >
> > > Reversing the following patch to hci_usb_rx_complete() makes 2.4.27-pre2
> > > up until 2.4.30 happy and does not hang when removing the dongle
> > > anymore. (bfusb.c has the same patch applied)
> > >
> > > 2.6.11.7 does not show the same problem, but has similar code to the
> > > "fixed" (that hangs) code in 2.4, so the real problem is probably
> > > somewhere else.
> >
> > does the attached patch makes any difference?
>
> It works just fine with pristine 2.4.30 and this patch. No deadlocks
> anymore.
if this works then we should do the same change in the bfusb driver. A
patch that fixes both drivers is attached.
Regards
Marcel
= drivers/bluetooth/bfusb.c 1.3 vs edited =
--- 1.3/drivers/bluetooth/bfusb.c 2004-04-16 14:01:40 +02:00
+++ edited/drivers/bluetooth/bfusb.c2005-04-13 12:49:55 +02:00
@@ -470,11 +470,10 @@
return 0;
write_lock_irqsave(&bfusb->lock, flags);
+ write_unlock_irqrestore(&bfusb->lock, flags);
bfusb_unlink_urbs(bfusb);
bfusb_flush(hdev);
-
- write_unlock_irqrestore(&bfusb->lock, flags);
MOD_DEC_USE_COUNT;
= drivers/bluetooth/hci_usb.c 1.23 vs edited =
--- 1.23/drivers/bluetooth/hci_usb.c2004-07-31 13:02:43 +02:00
+++ edited/drivers/bluetooth/hci_usb.c 2005-04-09 15:37:12 +02:00
@@ -398,12 +398,12 @@
BT_DBG("%s", hdev->name);
+ /* Synchronize with completion handlers */
write_lock_irqsave(&husb->completion_lock, flags);
-
+ write_unlock_irqrestore(&husb->completion_lock, flags);
+
hci_usb_unlink_urbs(husb);
hci_usb_flush(hdev);
-
- write_unlock_irqrestore(&husb->completion_lock, flags);
MOD_DEC_USE_COUNT;
return 0;
Re: [2.6 patch] net/bluetooth/: cleanups
Hi Adrian, > This patch contains the following cleanups: > - remove BT_DMP/bt_dump > - remove the following unneeded EXPORT_SYMBOL's: > - hci_core.c: hci_dev_get > - hci_core.c: hci_send_cmd > - hci_event.c: hci_si_event is this the same patch you sent me last time? I still have one of your cleanup patches in my queue. I simply was to lazy to get them back into mainline. Regards Marcel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
NULL pointer dereference at vt_ioctl()
Hi, with the latest 2.6.13-rc5-git kernel I see three weird oopses when I boot up my machine. All of refer to vt_ioctl(). Regards Marcel Unable to handle kernel NULL pointer dereference at virtual address printing eip: c022d1f5 *pde = Oops: [#1] SMP Modules linked in: rfcomm hidp l2cap af_packet tun irda crc_ccitt binfmt_misc ipv6 xfrm_user ipcomp esp4 ah4 pcmcia firmware_class ide_cd cdrom yenta_socket rsrc_nonstatic pcmcia_core ohci_hcd 8250_pci 8250 serial_core st sd_mod aic7xxx scsi_transport_spi scsi_mod skge snd_intel8x0 snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc tpm_atmel tpm_nsc tpm ehci_hcd evdev usbhid hci_usb bluetooth uhci_hcd usbcore intel_agp deflate zlib_deflate zlib_inflate twofish serpent aes_i586 blowfish des sha256 sha1 md5 crypto_null af_key nls_iso8859_1 nls_cp437 vfat fat nls_base mga drm agpgart w83627hf i2c_sensor i2c_isa i2c_i801 i2c_core sk98lin unix CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00010286 (2.6.13-rc5) EIP is at vt_ioctl+0x15/0x1948 eax: c022d1e0 ebx: f7468680 ecx: f7468680 edx: bf98f420 esi: edi: f5437000 ebp: 5401 esp: f55fdeb4 ds: 007b es: 007b ss: 0068 Process getty (pid: 7578, threadinfo=f55fc000 task=c223e020) Stack: c02363e1 f7468680 ffed f7468680 f55fc000 c0227a46 f5437000 f7468680 f55fdee4 8802e020 f55fc000 0002 f5437000 f7c41c04 c02277ba f7e8a444 c0169493 f7e8a444 f7468680 c0160a51 f7468680 f7468680 fff8 Call Trace: [] con_open+0x22/0x8e [] tty_open+0x28c/0x313 [] tty_open+0x0/0x313 [] chrdev_open+0xb2/0x184 [] get_empty_filp+0x6a/0x107 [] tty_ioctl+0x95/0x4ad [] do_ioctl+0x78/0x81 [] vfs_ioctl+0x5a/0x1ef [] sys_ioctl+0x6f/0x7d [] sysenter_past_esp+0x54/0x75 Code: 12 32 c0 e8 0e 12 0a 00 e9 1e ff ff ff 90 90 90 90 90 90 90 90 90 55 57 56 53 83 ec 58 8b 7c 24 6c 8b 6c 24 74 8b b7 9c 09 00 00 <0f> b7 1e 89 1c 24 e8 f8 62 00 00 85 c0 75 0f bb fd fd ff ff 89 <1>Unable to handle kernel NULL pointer dereference at virtual address printing eip: c022d1f5 *pde = Oops: [#2] SMP Modules linked in: rfcomm hidp l2cap af_packet tun irda crc_ccitt binfmt_misc ipv6 xfrm_user ipcomp esp4 ah4 pcmcia firmware_class ide_cd cdrom yenta_socket rsrc_nonstatic pcmcia_core ohci_hcd 8250_pci 8250 serial_core st sd_mod aic7xxx scsi_transport_spi scsi_mod skge snd_intel8x0 snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc tpm_atmel tpm_nsc tpm ehci_hcd evdev usbhid hci_usb bluetooth uhci_hcd usbcore intel_agp deflate zlib_deflate zlib_inflate twofish serpent aes_i586 blowfish des sha256 sha1 md5 crypto_null af_key nls_iso8859_1 nls_cp437 vfat fat nls_base mga drm agpgart w83627hf i2c_sensor i2c_isa i2c_i801 i2c_core sk98lin unix CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00010286 (2.6.13-rc5) EIP is at vt_ioctl+0x15/0x1948 eax: c022d1e0 ebx: f7468680 ecx: f7468680 edx: bf9b0860 esi: edi: f5437000 ebp: 5401 esp: f55fdeb4 ds: 007b es: 007b ss: 0068 Process getty (pid: 7615, threadinfo=f55fc000 task=c223e020) Stack: 0001 0001 f55fdee4 c0118c11 f7ec1a60 0003 c031a57c c031a56c c031a574 0282 f55fdf00 c0118ca8 c031a574 0003 0001 0282 c02ce263 0001 f7468680 fff8 Call Trace: [] __wake_up_common+0x43/0x65 [] __wake_up_locked+0x2a/0x2c [] __down+0xaf/0xf5 [] tty_ioctl+0x95/0x4ad [] do_ioctl+0x78/0x81 [] vfs_ioctl+0x5a/0x1ef [] sys_ioctl+0x6f/0x7d [] sysenter_past_esp+0x54/0x75 Code: 12 32 c0 e8 0e 12 0a 00 e9 1e ff ff ff 90 90 90 90 90 90 90 90 90 55 57 56 53 83 ec 58 8b 7c 24 6c 8b 6c 24 74 8b b7 9c 09 00 00 <0f> b7 1e 89 1c 24 e8 f8 62 00 00 85 c0 75 0f bb fd fd ff ff 89 <1>Unable to handle kernel NULL pointer dereference at virtual address printing eip: c022d1f5 *pde = Oops: [#3] SMP Modules linked in: rfcomm hidp l2cap af_packet tun irda crc_ccitt binfmt_misc ipv6 xfrm_user ipcomp esp4 ah4 pcmcia firmware_class ide_cd cdrom yenta_socket rsrc_nonstatic pcmcia_core ohci_hcd 8250_pci 8250 serial_core st sd_mod aic7xxx scsi_transport_spi scsi_mod skge snd_intel8x0 snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc tpm_atmel tpm_nsc tpm ehci_hcd evdev usbhid hci_usb bluetooth uhci_hcd usbcore intel_agp deflate zlib_deflate zlib_inflate twofish serpent aes_i586 blowfish des sha256 sha1 md5 crypto_null af_key nls_iso8859_1 nls_cp437 vfat fat nls_base mga drm agpgart w83627hf i2c_sensor i2c_isa i2c_i801 i2c_core sk98lin unix CPU:1 EIP:0060:[]Not tainted VLI EFLAGS: 00010286 (2.6.13-rc5) EIP is at vt_ioctl+0x15/0x1948 eax: c022d1e0 ebx: f7468680 ecx: f7468680 edx: bfeed250 esi: edi: f5437000 ebp: 5401 esp: f55fdeb4 ds: 007b es: 007b ss: 0068 Process getty (pid: 7618, threadinfo=f55fc000 task=c223e020) Stack
Re: [PATCH] spi
Hi Greg,
> No spaces after ( or before ) please. You do this all over the place in
> the code, please fix it up.
>
> > + if (NULL == dev || NULL == driver) {
>
> Put the variable on the left side, gcc will complain if you incorrectly
> put a "=" instead of a "==" here, which is all that you are defending
> against with this style.
I think in this case the preferred way is
if (!dev || !driver) {
Regards
Marcel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH ISDN] Fix capifs bug in initialization error path.
Hi Karsten, > > This patch fixes a bug in the capifs initialization code, where the > > filesystem is not unregistered if kern_mount() fails. > > > > Please apply. > > looks OK for me. and what about me idea to remove capifs completely? We have udev now and thus it is not needed anymore. I stopped compiling and using it a long time ago. Regards Marcel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] W1 patches for 2.6.13
Hi Greg, > Here are some w1 patches that have been in the -mm tree for a while. > They add a new driver, and fix up the netlink logic a lot. They also > add a crc16 implementation that is needed. adding the CRC-16 is very cool. I was just about to submit one by my own, because it is also needed for the Bluetooth L2CAP retransmission and flow control support. What about the 1-Wire notes inside the CRC-16 code. This suppose to be generic code and so this doesn't belong there. Regards Marcel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ipwireless_cs driver for 4G PC Card
Hi David, might it not make more sense to put all of that into a new subdirectory, say, /drivers/char/pcmcia/ipwireless_cs? that way, it's more modular and it will keep that higher-level directory from potentially getting cluttered with even more drivers. and it would let you drop the pointless "ipwireless_cs_" prefix from all of those files as well. ok, will put it into ipwireless, and the _cs suffix will go away as suggested elsewhere. The filenames will then get very generic names, do you have suggestion for better names? There are many drivers in own directory and files inside have the same prefix. Maybe we can use names like ipw- hw.c, etc. don't use "ipw" as prefix. It is too close to the Intel wireless drivers and will only create confusion. The generic filenames in a subdirectory don't matter. The module name is what counts. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc4: bluetooth device gone after suspend to ram
Hi Oliver, > > I noticed that on my macbook pro1,1 the bluetooth device is gone after > > suspend to ram, i.e. > > Is this a regression? > Does it work if you unload hci_usb before you suspend? > If so, please recompile with CONFIG_USB_DEBUG and provide > dmesg. sometimes ACPI is involved and will killswitch the Bluetooth device on suspend. Sometimes the distros to a manual killswitch. And in case of Bluetooth a killswitch means physically removing the power from the device. In case of a MacBook it can happen that this device goes back into HID mode and thus you need to call hid2hci. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] bluetooth : move children of connection device to NULL before connection down
Hi Dave, > > Add people missed in cc-list. > > Thanks Dave for your continued efforts on Bluetooth bugs like this. > > Marcel, are you going to review/ACK/integrate/push-upstream/whatever > any of these Bluetooth patches? > > It hasn't been getting much love from you as of late, you are one of > the listed maintainers, and I don't want to lose any of Dave's > valuable bug fixing work. I will be fully back in business next week. Just got stuck in a project that needed 200% of my time to get it going. > Or should I just handle it all directly? I followed the list only a little bit, but from what I have seen is that Dave is doing a great job in tracking all issues down to the real cause. I had a look at his last patch and after review, I agree that this is a possible solution. I only have two nitpicks about the coding style. So in del_conn the struct device declaration should be made after the struct hci_conn assignment from the container and I would put an extra empty line before the devel_del, put_device block. Nitpicks only. Right now I can't think of any side effects by this patch. Actually I only see an improvement with this patch. So please take it directly and starting with next week, I gonna make sure that they are handled again properly by me. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] bluetooth : move children of connection device to NULL before connection down
Hi Dave, > could you tell something more about your coding style? > I would like to submit patches about bluetooth according to your sytle > later If I have. > > Maybe you could put it on the bluez web site or anywhere. it follows closely the kernel coding style as layout within the kernel documentation. However there are some minor style things, that I am going to enforce from time to time. Like having the container_of or get_user_data calls at the top of the variable declaration. This has never formalized as far as I recall, but makes from my point of view the code clearer and easier to read. Some other times I like an extra empty line to more visual separate different code blocks. For this some people might agree with me others might disagree. It is fully a personal more liking one way over the other. When it comes to indentation and placement of braces etc. I is 100% the kernel coding style and nothing else. If not, then it needs fixing and is an oversight from the old days. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Bluez-users] Lost connections - mouse and keyboard
Hi Dave, apparently does manage bluetooth devices using bluetooth-input- service. I still have the problem of the devices disappearing if idle for too long such as when i lock the desktop or log out for a long period. Sometimes I can re-enable the devices, but sometimes I cannot. This is frustrating. I see a the following several times in the system log if i restart bluetooth: Nov 28 18:53:39 pico kernel: WARNING: at drivers/hid/hid-core.c:784 implement() (Tainted: P ) Nov 28 18:53:39 pico kernel: Nov 28 18:53:39 pico kernel: Call Trace: Nov 28 18:53:39 pico kernel: [] hid_output_report +0x1c5/0x232 Nov 28 18:53:39 pico kernel: [] hid_submit_ctrl +0x60/0x24b Nov 28 18:53:39 pico kernel: [] usbhid_submit_report +0x169/0x19e Nov 28 18:53:39 pico kernel: [] hiddev_ioctl +0x368/0x919 Nov 28 18:53:39 pico kernel: [] inode_has_perm +0x65/0x72 Nov 28 18:53:39 pico kernel: [] __up_read +0x19/0x7f Nov 28 18:53:39 pico kernel: [] do_page_fault +0x490/0x7e4 Nov 28 18:53:39 pico kernel: [] do_ioctl+0x55/0x6b Nov 28 18:53:39 pico kernel: [] vfs_ioctl +0x243/0x25c Nov 28 18:53:39 pico kernel: [] sys_ioctl +0x59/0x79 Nov 28 18:53:39 pico kernel: [] tracesys+0xd5/0xda Does bluetooth input devices have something to do with usbhid? I don't know, perhaps this is another problem in kernel. in case you have a HID proxy dongle the usbhid driver can be involved. And since this is hiddev, then it will be caused by the hid2hci program. Regards Marcel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ipwireless_cs driver for 4G PC Card
Hi David, > I'm submitting driver for IPWireless PC Card, used for 4G > internet connection. > The driver has been in -mm series as ipwireless_cs.git tree for > some time, is actively used and there are currently no > outstanding bugs. > > I'd like to let the driver pass through LKML and then let it > queue for 2.6.25. > > Driver is released under GPL, original authorship belongs to > Symmetric co. Jiri Kosina has fixed some bugs and made it work > with recent kernels, and I work on improving the code to > match linux kernel standards. > > When merged, please drop ipwireless_cs.git tree from -mm and > include the patch instead. Patches should be sent to me and I'll > push them to mainline via Jeff Garzik's driver tree, if there's > no objection. > > Driver lives in drivers/char/pcmcia directory, it's a serial > driver. I'm not sure if this is the right place, since it's a > networking driver too and therefore should be in > drivers/net/pcmcia. > > There will be a wiki with info for users and developers, todo etc. > > Regards, > David Sterba > > Rewieved-by: Jiri Slaby <[EMAIL PROTECTED]> > Signed-off-by: Ben Martel <[EMAIL PROTECTED]> > Signed-off-by: Stephen Blackheath <[EMAIL PROTECTED]> > Signed-off-by: David Sterba <[EMAIL PROTECTED]> > Signed-off-by: Jiri Kosina <[EMAIL PROTECTED]> > --- > MAINTAINERS|8 > drivers/char/pcmcia/Kconfig|8 > drivers/char/pcmcia/Makefile |4 > drivers/char/pcmcia/ipwireless_cs_hardware.c | 1728 > + > drivers/char/pcmcia/ipwireless_cs_hardware.h | 63 > drivers/char/pcmcia/ipwireless_cs_main.c | 479 + > drivers/char/pcmcia/ipwireless_cs_main.h | 70 > drivers/char/pcmcia/ipwireless_cs_network.c| 496 ++ > drivers/char/pcmcia/ipwireless_cs_network.h| 54 > drivers/char/pcmcia/ipwireless_cs_setup_protocol.h | 108 + > drivers/char/pcmcia/ipwireless_cs_tty.c| 779 + > drivers/char/pcmcia/ipwireless_cs_tty.h| 48 > 12 files changed, 3845 insertions(+) can we please drop the stupid "_cs" stuff. It is an old habit to have the shortcut for "Card Services" in the driver name, but that goes back to the time when the PCMCIA subsystem and its drivers were an external package. Especially in cases where only a PCMCIA card exists, it makes no sense anymore. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Bluez-devel] 2.6.23.8: kernel panic
Hi Dave, > This problem is caused by the workqueue in hci_sysfs.c, the del_conn is > scheduled after the add_conn with same bluetooth address. > > Please try this patch: > > > The bluetooth hci conn sysfs add/del executed in the default workqueue. If > the conn del function is executed after the new conn add function with same > bluetooth target address, the connection add will failed and warning about > same kobject name. > > Here add a btconn workqueue, and flush the workqueue in the add_conn function > to avoid the above issue. the patch looks good to me (except some style cleanups). Let me push it to one of my test machines and stress it a little bit. I give you feedback after my testing. Regards Marcel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH retry] bluetooth : add conn add/del workqueues to avoid connection fail
Hi Dave, > > The bluetooth hci_conn sysfs add/del executed in the default workqueue. > > If the del_conn is executed after the new add_conn with same target, > > add_conn will failed with warning of "same kobject name". > > > > Here add btaddconn & btdelconn workqueues, > > flush the btdelconn workqueue in the add_conn function to avoid the issue. > > > > Signed-off-by: Dave Young <[EMAIL PROTECTED]> > > This looks good, applied, thanks Dave. > > I've queued this up for 2.6.25 merging, if you want me to > schedule it for -stable, just let me know. don't include it. I first have to stress test it on one of my machines. Besides that I have to do some coding style cleanups. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.24] bcm203x bluetooth dongle does not work
Hi Florian, > after trying around with my ancient bcm2033 bluetooth dongle i found it > not working in 2.6.24 - I debugged udev and found it loading the > firmware correctly but the device seems to have problems disconnecting. > > I found an Ubuntu bug which mentions a patch which supposed to be > 2.6.20 material. It still applies and fixes my problem: > > Ubuntu Bug: > https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/85247 > > Patch: > http://launchpadlibrarian.net/7058766/bcm203x-2.6.20-backport.diff > > So it seems this patch never went in but most likely should. we moved away from using a timer and using a workqueue now. It wrote the patch to use a workqueue and tested that it works. Starting with 2.6.19 we the usage of a workqueue is default. Can you verify that non of the kernels 2.6.19-2.6.23 are working. We might have missed a change inside the USB subsystem within the 2.6.24 timeframe. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add missing refrigerator calls
Hi Nigel, > There are a number of threads that currently have no refrigerator > handling in Linus' tree. This patch addresses part of that issue. The > remainder will be addressed in other patches, following soon. > > Signed-off-by: Nigel Cunningham <[EMAIL PROTECTED]> I am fine with the net/bluetooth/rfcomm/ part, but what about the bnep/ and cmtp/ and hidp/ part of the Bluetooth subsystem? Do we need this there, too? Regards Marcel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bcm203x broadcom dongle firmware upload fails...
Hi Soeren, > I don't see why, it used to work reliably at some point but now it does > not. It even won't work without hotplug and then manually typing: > > echo 1 > /sys/class/firmware/2-1/loading > cat /lib/firmware/BCM2033-FW.bin >/sys/class/firmware/2-1/data > echo 0 > /sys/class/firmware/2-1/loading > > usb 2-1: new full speed USB device using ohci_hcd and address 2 > Bluetooth: Broadcom Blutonium firmware driver ver 1.0 > bcm203x_probe: Mini driver request failed > bcm203x: probe of 2-1:1.0 failed with error -5 > usbcore: registered new driver bcm203x > > It does not work with kernel 2.6.10/11 any ideas ? I think this is a general request_firmware() problem. Check the Hotplug mailing list archive. Hannes, Kay and Greg discussed problems with the firmware_class and udev. I haven't found the time to look at it. Regards Marcel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] net/bluetooth/rfcomm/core.: make a variable static
Hi Adrian, > This patch makes a needlessly global variable static. the patch is in my tree now. Thanks. Regards Marcel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to read file in kernel module?
Hi, > > I have written one /proc file creation kernel > > module. This module creates /proc/file and defied > > operations on it. Also i have written user program > > that will read & write to /proc files from user space. > > Now what i want is to use same bufproc_read & > > bufproc_write functions defined in /proc file > > handling kernel module to be used in another kernel > > module to read that /proc/file in kernel module.The > > second kernel module only used to read /proc file in > > kernel. I am not understanding how can i open that > > /proc/file in second kenrel module to read in kernel? > > regards, > > the answer really is that you should not read files from kernel > modules; /proc or otherwise. the only thing that is may needed by a kernel driver should be an external firmware file and for that we have request_firmware(). For everything else you are on the wrong track. Regards Marcel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
HID warning messages fills the logs
Hi, when running 2.6.11-rc2-bk6 with my USB HID v1.00 Mouse [Microsoft Microsoft Wheel Mouse Optical®] the logs get filled with this message: kernel: drivers/usb/input/hid-input.c: event field not found last message repeated 459 times last message repeated 1157 times Regards Marcel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: recent 2.6.x USB HID input weirdness
Hi Dave, > On sparc64 I just started getting this in my kernel logs > on 2.6.x-BK from hidinput_input_event: > > warning: event field not found > > I added some debugging: > > hidinput_input_event: type[4] code [4] value[458759] > hidinput_input_event: type[4] code [4] value[458761] > > This is on a Sun Type-6 USB keyboard. It does this for > every key I press. The keys work properly, just the > warning is printed (which makes the console kind of hard > to use :-) take a look at this patch: http://lkml.org/lkml/2005/1/29/111 Regards Marcel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Patch to add usbmon
Hi Pete, today I just thought to give usbmon a try. Previously I used a hacked devio thing around usbfs_snoop to monitor the USB communication between a VMware and the Linux host. Greg, will such patch accepted for inclusion or will usbfs_snoop go away when usbmon is included? > > First off, why make usbmon a module? You aren't allowing it to happen, > > so just take out the parts of the patch that allow it. > > No, I do allow it. This way I can load and unload it when debugging it. > Perhaps in the future we may simply link it with usbcore, but for now > it is a separate module. Also, I do not think it's possible not to build > it as a module when usbcore is a module. > > I do not think it's a good idea for most users to build it as a module, > but it's not prohibited. By accident I removed the debugfs option from my kernel config and this makes usbmon totally useless. So I think the module approach is wrong from my point of view. Why not compile it always and if debugfs is available, then enable it when the usbcore gets loaded? And btw don't you think that you split your code into too much separate files? I count less than 900 lines of code. However it works fine for me, but I can't find a document that describes the information (without looking at the code) you get, when running cat on a specific bus. I think for using cat this format should be a lot more easier to read by humans. With my devio patch I used something like: control urb endpoint 0x00 flags 0x00 buflen 3 actlen 0 bRequestType 0x20 bRequest 0x00 wValue 0 wIndex 0 wLength 3 pipe 0x80003900 flags 0x00 buffer f7f2e4e0 length 3 setup f64895a0 start 0 packets 0 interval 0 data 36 fc 00 Especially the information about endpoint, type of the URB and the data should be presented in a better way. I would insert a space after each byte of data to make it easier to read. Instead of using the URB pointer for the id, I think it makes sense to present the device number of that device. If you have multiple devices on the bus you can differ between them. Only my 2 cents. Keep on the good work. I really like it and it will become very handy to me, I think. Regards Marcel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Patch to add usbmon
Hi Pete, > > By accident I removed the debugfs option from my kernel config and this > > makes usbmon totally useless. So I think the module approach is wrong > > from my point of view. Why not compile it always and if debugfs is > > available, then enable it when the usbcore gets loaded? > > This may be a good idea, but I'm too lazy to think in trinary. Care to > send a patch? I can do this if you think that this is a good idea. Acutally I see usbmon as an option of the USB core. This will also reduce the code a little bit, because you don't need an registration interface. You can call the usbmon functions directly. > > And btw don't you think that you split your code into too much separate > > files? I count less than 900 lines of code. > > What does it hurt? I think the split was rather clean, along well defined > functional lines, with minimum dependencies. They may even be separate > modules later. I think that separation is a good idea, but dividing such a minimum code into four files didn't make it cleaner. Two much separation makes it even worse and sometimes harder to understand. I personally vote for having a single driver/usb/core/usbmon.c and link it into usbcore if selected. > > However it works fine for me, but I can't find a document that describes > > the information (without looking at the code) you get, when running cat > > on a specific bus. > > I'm sorry about that. I will add a file in Documentation/ . This would be great and btw the official mount point for debugfs should be /sys/kernel/debug as Greg posted some time ago. > > control urb endpoint 0x00 flags 0x00 buflen 3 actlen 0 > > bRequestType 0x20 bRequest 0x00 wValue 0 wIndex 0 wLength 3 > > pipe 0x80003900 flags 0x00 buffer f7f2e4e0 length 3 setup f64895a0 start 0 > > packets 0 interval 0 > > data 36 fc 00 > > You are right, the current text format (0t) is not easily readable. > > My plan calls for the parsing of control messages and things like SCSI > commands to be placed in user mode applications, like USBMon. This is how > tcpdump and Ethereal operate. I don't like to keep too much of this in > kernel. Do you think it's a wrong approach? I think if cat is the prefered tool for viewing this file then it should be more human readable. If not, then a binary format should be choosen. Maybe we can implement both. Is this possible? > > [...] I think it makes sense to present the device number of that device. > > When I read dumps, I mentally fetch the device number from the pipe. > Just use that for now, please. I don't, because I need to check the encoding in the kernel source to do that. I also think that we should abstract from the definition of pipe. >From my view this is a kernel encoding and should not be visible to the user. Maybe I am wrong, because I am not an expert of USB internals. > But if you or someone else were to hack on something like usbdump(1), > it would be peachy, I think. I can start with usbdump if we agree on an interface. I personally would prefer a binary interface for that. Regards Marcel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Patch to add usbmon
Hi Pete, > > I think if cat is the prefered tool for viewing this file then it should > > be more human readable. If not, then a binary format should be choosen. > > Maybe we can implement both. Is this possible? > > Yes. Now you know why files were split as they were. still no reason for me to split things up. > > > But if you or someone else were to hack on something like usbdump(1), > > > it would be peachy, I think. > > > > I can start with usbdump if we agree on an interface. I personally would > > prefer a binary interface for that. > > If you want to start scoping it, it's fine by me. I was going to concentrate > on fixing what's needed first, such as getting control setup packets captured > and things like that. While I am really thinking about starting usbdump, I may ask why you have choosen to use debugfs as interface. This will not be available in normal distribution kernels and I think a general USB monitoring ability would be great. For example like we have it for Ethernet, Bluetooth and IrDA. So my idea is to create some /dev/usbmonX (for each bus one) where usbdump can read its information from. What do you think? Regards Marcel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
